January 2008 - Posts

• The Monolith

  The Monolith is probably one of the most common ways people structure systems these days. While this is probably a valid way to build a large majority of small systems, for others, it causes quite a bit of pain.  I would imagine a large number of people don't realize that it's not the only way to build systems. Your typical n-tier or client/server system is a monolith. Let's look at a few characteristics of the Monolith: Is hard to integrate.  The Monolith prefers to be an island of data.  When the technical problems of integration are solved, you still have data ownership issues. Is a poor base for a product line.  Putting pebbles on top does not result in a system with a Cohesive View. Is hard to scale.  This usually isn't an issue until it's already too late. Is easy to grasp mentally.  This is a positive aspect of the monolith.  Developers are inherently familiar with it. Is cheaper and faster to build initially than its non-monolith counterparts Large changes must be made at design time by a developer Reusing internal assets is tedious and requires much effort Will succeed or fail as a single unit Can not be used to mitigate against a risky language or runtime platform Platform or language migrations must happen all at once.  Rewrites are all or nothing. Must be versioned and deployed as a whole If selling or deploying for multiple user bases, it represents a one-size fits all solution May exhibit design-time modularity, but not runtime modularity Is either fully available (up) or completely unavailable (down) In terms of business concerns, we can characterize the monolith as: Quicker to market (than it's non-monolith counterparts) Targeting related markets is slow and/or hard as it requires building new monoliths Acquiring new monoliths often results in a non-cohesive mess Will likely require a full rewrite at a point in its future (even in an Agile team).  This means a shorter lifetime.  A shorter lifetime means the costs must be recouped over a shorter period of time. Tied to a particular customer size.  If the monolith targets the large customer base, it will likely be unwieldy and/or too costly for small customers.  If targeted at small customers, the reverse is true.  One size fits all. If I had to guess, I would say that monoliths are often built even when they do not provide a good fit for the System, Product, or Business Needs.  Building a non-monolith system requires a shift in thinking--a shift that's not always quite so obvious at first. Posted Jan 09 2008, 08:29 PM by hoffe with 3 comment(s)

• Language Roots

  Where does C# get its roots? Most C# developers would say it's a descendant of C++, but is that the case?  Did we really get our heritage from C and C++? Here's a comparison for you:   C++ C# Modula-3 Single Inheritance   X X Multiple Inheritance X     Interfaces   X X Safe/Unsafe Code   X X Generics   X X Templates X     Garbage Collection   X X Exceptions   X X While some of the features above are more runtime features than language features (say, garbage collection), I think they are valid for the comparison.  The choice to exclude memory management features from the language dictates (to an extent) the runtime environment.  I'll save that for another post sometime I suppose. Oh, and Modula-3 also shipped with an AST (Abstract Syntax Tree) implementation.  CodeDOM anyone? For the interested, you can take a quick glance at the following language families: BCPL (Basic Combined Programming Language)- The family to which C and C++ belong ALGOL - The family to which Modula-3 and C# belong (along with its .NET siblings) The mathematics based languages, such as Lisp It seems that a large portion of what we think of as Microsoft's .NET was really designed by Digital (later to become Compaq, later to become HP). An interesting side note of Modula-3 is that simplicity was a major goal of the language.  The designers gave themselves a mandate to produce a language which could adequately be described in 50 pages or less. Posted Jan 07 2008, 11:54 PM by hoffe with 9 comment(s)

• Running Microsoft Excel on a Scalable Computing Grid

  Sorry, I had to post this one. Ever written an Excel application which was both data and cpu intensive?  Maybe you work for a financial company and want to run your realtime risk analysis off your current trusty Excel spreadsheet.   By now, you've probably realized that Excel isn't the quickest thing for pulling 800k records from the database and running the numbers *in real time*, so what do you do? Enter GigaSpaces... GigaSpaces provides a grid-based middleware stack built on a unified messaging, distributed datacaching and parallel-processing engine. GigaSpaces leverages Space-Based technology and shares a single, common runtime clustering model. Apparently, the whole process involves only two steps: Use GigaSpaces’ In-Memory-Data-Grid to store and access the data Move the logic from the worksheets to run (in parallel) close to the data What kind of work is involved? Leverage GigaSpaces’ robust Excel integration and .NET support to connect Excel to the data center Initial Effort is Minimal Replace Excel calls to existing data source(s) with calls to GigaSpaces In-Memory-Data-Grid The next step is to migrate the algorithms from the Excel client to the servers (running close to the data) GigaSpaces’ Microsoft Certified partners are able to assist in this task Gotcha! lol And no, this wasn't a joke.  I did get a good laugh out of it though. Excel that Scales Presentation 1 Sheet If I had to guess, they are probably laughing as well.  All the way to the bank.  I'm sure some people are buying this stuff. GigaSpaces, btw, has some really cool looking stuff.  One of these days, I will take the time to dig into it deeper. Posted Jan 01 2008, 05:07 PM by hoffe with 2 comment(s)

• Speaking in 2007

  What a whirlwind!  I wanted to put together a few notes from my speaking engagements this year.  I'm hoping they might be of use to any of you trying to do the same. Compuware Thought Leadership I gave my first public presentation this past July to our local Compuware office (Thought Leadership).  Needless to say, I overshot the amount of material I could pack into one session.  I had previously decided that I wanted the talk to be on Dependency Injection, but I knew that without a healthy dose of OO, the material on DI wouldn't be all that valuable. I ended up spending most of the time explaining some OO concepts with DI as a segway at the end. I was very well prepared (with a stack of Powerpoint slides), but didn't do a good job packaging my sample code for the people who attended (and wanted a copy). Looking back, I'm ok with the fact that I didn't get too deep into DI.  I think I did the right thing for the situation.  I do think, however, I tried to pack too much information into one session.  Some presenters have the Information Overload style, which I think accurately reflects that talk. Lessons Learned: Avoid Information Overload, Less is More with Powerpoint, Make sure to have a good ratio of Visual Studio to Powerpoint time Nashville BarCamp For my second talk, I did a last minute entry over at the Nashville BarCamp in August.  The talk was on Agile Development, and felt pretty much the opposite of my first.  If my first talk was characterized by being overprepared and overstuffed with information, my second talk was quite the opposite.  I spent a lot of time deciding on what I wanted to communicate, but I wanted to pull back on the reins a bit.  While I do think I said a lot of what I wanted to say, I don't think I effectively communicated it to the audience.  While I successfully avoided the slide-per-minute logjam, I didn't have anything to communicate to my audience visibly. It was an interesting experience.  The BarCamp had a decidely marketing feel to it, so I wasn't speaking to a good target audience for Development Methodology. Lessons Learned:  Some Visual Aid is Necessary, Double Check Conference Agendas to get a feel for the target audience Nashville Agile Users Group A few days following the Nashville BarCamp, I spoke at the Nashville Agile Users Group.  The title of the presentation was "Agile in the Enterprise".  Given that our Agile group was really small, I felt comfortable giving a talk about a topic I have spent quite a bit of time studying this past year: messaging and event-driven systems. I had a fairly decent amount of powerpoint, and spent some time whiteboarding.  By the end, the presentation had drifted into a full-fledged discussion.  When it was over, I had several people tell me they greatly enjoyed the presentation.  I, too, had learned some new things from those around me.  Win/Win Looking back, I should have spaced those two talks apart more.  I would have done better on each if I had.  I was happy with the result I got from speaking at the User Group, but I think it could have been even better, with a bit of polishing. Lessons Learned:  You need several weeks between new presentations,  Don't read from Powerpoint, Engaging the audience is a good thing Tulsa Tech Fest I was very happy to be given the chance to speak at Tulsa Tech Fest 2007 in October.  I think, by far, it was my best presentation.  The talk was entitled "A Beginners Introduction to TDD".  You might notice the emphasis on the introductory nature of the talk ("beginners introduction"), and that was on purpose.  Prior to the talk, I spent time crafting only a handful of slides with meaningful or catchy photos (hat tip to Dave Laribee for help with the slides).  I also took the time to do a screencast of my code demo the week before. Needless to say, I think the presentation delivered the correct balance of Visual Studio time and Powerpoint time.  And it didn't hurt when JetBrains gave me a free license of ReSharper to give away at the end. ;-) Lessons Learned: Giveaways Rock, Screencasting the Code Demo beforehand make you uber confident, Well prepared Powerpoint presentations are an asset, Delivering a well-crafted presentation can be a very satisfying activity Looking Into 2008 In 2008 I hope to replicate the balance I found giving my presentation in Tulsa, while trying to improve it even more.  Having given 4 presentations in the past 6 months, I'm going to give myself the goal of giving 6 well-crafted presentations in 2008.  I'll be starting the year off right with another presentation to our local Compuware office this month. Posted Jan 01 2008, 02:52 PM by hoffe with 1 comment(s)