There used to be a television commercial for some candy that had chocolate and peanut butter. In it, there would be one person walking around with an open jar of peanut butter and another walking around with a chocolate bar. They would bump into each other and the chocolate would end up in the peanut butter. The peanut butter owner would exclaim, “You got your chocolate in my peanut butter!” While the chocolate bar owner would shout, “You got your peanut butter on my chocolate!” They’d both try this new concoction, declare it an amazing snack, and all of us viewing would go out to buy the candy.
What does all this have to do with programming? While thinking about how to develop a good framework for the suite of apps I work with, I’ve been looking at what I’ve seen that works and what doesn’t work. One thing that I see a lot of is procedural code written in object-oriented languages. We’ve all seen (and probably created) classes with a method that is hundreds, if not thousands, of lines long. You got you procedure in my object! But I think the opposite problem can also occur. When working towards an “ideal” application, you can try forcing procedural processes into objects, handling them with massive event raising or forcing them into place with an implementation of the Chain of Responsibility pattern. You got your object in my procedure!
One of my thoughts when creating this framework is to have objects (Customers, Jobs, etc.) represented by objects, and have processes handled in procedural methods. I’ll still be following the SOLID principles, especially Single Responsibility and Dependency Inversion. However, I won’t be forcing things to use styles that don’t seem to be appropriate. My next post will go into some detail of how (and why) I’ve set up the projects for the framework.
BTW, as I started writing this, a friend of mine sent me an e-mail with a link to a funny history of computer languages, complete with a reference to the chocolate/peanut butter commercial. Check out this Brief, Incomplete, and Mostly Wrong History of Programming Languages for a laugh.
It’s been quite a while since I last posted, but I’ve been keeping extremely busy. Since my last post, I started a new job, in a new industry, writing a [mostly] new to me type of application. Add in moving and all the other things that life entails, and it’s been hectic. But sanity is slowly starting to return.
The job I’m at now is full-time, heads-down development. However, it’s Windows Forms applications instead of the web services, Windows services, and back-end business processing that I’ve been doing for most of the last several years. I finally get to spend my days writing programs that users can actually see! After years of staring at XML all day, it’s cool to work on something that shows graphs of data … in different colors, even. Without going into more detail than my boss probably wants me to, the programming team I’m working on produces a suite of dozens of individual applications that all go against the same database. “My” application parses files in numerous formats, displaying the data in graphs and reports. It also needs to send the parsed data to the database and be able to output it in a couple of other formats.
My current focus (and what I’ll be posting about) is building a high-performance framework that can be used by all the applications in our suite. I’m not building the framework from an ivory tower. Instead, I’m writing a stripped-down version of the application I work on, and building it in a way that will make it highly re-usable and improve the performance. At work, there’s a definite C++ bias for anything that needs to be high-performance, but I think I can do just as well in plain-old C# (plus avoid the overhead of COM interop or P/Invoke). So, whenever I build part of the framework, I write a mini-load test app to see how well it works. I’ll eventually start doing some more serious profiling of the throughput, CPU load, and memory usage.
Another thing on my research list is F#. In order to get a further performance boost, I’ll also be looking at using F# to create code to take advantage of multi-core processors. I haven’t even written a Hello World program in F# yet, but what I’ve been reading about it has impacted how I’m writing code. I’m focusing more on separating my “state” from my “process”. I’ve noticed that I’m starting to write more static methods, which isn’t helping with testability.
I ran into an extremely frustrating problem with GridViewCommandEventArgs.CommandName this weekend.
While working with the OnRowCommand event on a GridView object in ASP.Net, the code in my code-behind page was not doing what it should have for the asp:ButtonField that I had in the grid. So, I set a breakpoint and watched what was happening. When the code got to the line “if ( e.CommandName == “RaiseStoryInPriority” )”, it never executed the code within the “if” statement, even though hovering over “e.CommandName” showed that the value was equal. After trying several different things (and beating my head against the wall for far too long) I tried running the code through IIS, instead of the Cassini web server that runs your code when you press F5 in Visual Studio.Net. The code worked perfectly in IIS.
I also ran into a different problem with Cassini a while back. I was using a cache object and tried to clear out a value by assigning “null” to it. That worked in Cassini, but not in IIS. In IIS, I had to use the Remove() method.
So, if you see something that looks like it should be working, but isn’t, it might be worthwhile to run it your application through IIS and see if you still have the problem. That might save you from an hour of frustration.