4/29/2005

NASA Open Sources PathFinder

According to the JDJ, NASA is open sourcing their PathFinder application which finds bugs in Java programs. PathFinder is a JVM that traces through Java programs and looks for things like deadlocks and unhandled exceptions.

I think this looks really cool. I imagine this would fit well with Cleanroom Software Engineering practices - you want to guarantee reliability. This would definitely help you do that.

4/26/2005

onfocus.com | PGP-signed posts for weblog comments

It just occurred to me how cool it would be to use GPG to sign your blog posts or comments. This guy had the idea back in 2002.

Making Software Design More Like Architecture: Renderings

It occurs to me that there's another way that software design is not like architecture. Architects typically create a rendering of their design. This is a model or picture(s) used to convey to lay people what the design will look like when the construction is complete. I don't believe that many software design projects produce a complete rendering of the system as part of their deliverables.

How do we create renderings of a design during software design? Does UML count? I don't think so. That's more like the building plans that an architect draws. What about user interface mock-ups that a user interface architect creates? This may be more analogous. However, not every project has the luxury of having a interface architect on it (much less during design).

Should this be part of software architecture? It seems like business users need renderings to understand what we are designing. Often I hear business users asking, "What would that LOOK like?"

How do you get this into your development methodology? Sometimes architects spend alot of time modeling or drawing sketches of their designs. It seems that we would need similar time to mock-up our interfaces.

Thinking along these lines makes me think that user interface architects need to be in on the design from the very beginning. This would give them the time they need to create these renderings at the beginning of the project.

This means that they need to come in and design in conjunction (or possibly even before) the software architect. (Well, only if the software architect is not an all-in-one wonder kid.) So, this means that the interface architect should be part of the design team.

It would be interesting to research how design teams that include an interface architect prevent stepping on each other and what their methodology looks like.

4/22/2005

IBM Addresses SMBs with Latest WebSphere Integration Software @ JDJ

IBM Addresses SMBs with Latest WebSphere Integration Software. JDJ reports that IBM has a new version of WebSphere MQ and WebSphere Business Integration Server for small and mid-sized businesses.

Java: Meta-Frameworks

Duncan Mills recently posted an excellent article on the JDJ website titled "J2EE vs .NET: Where Is Application Development Going?". In the article he talks about the rise of meta-frameworks (frameworks that pull together individual frameworks into a single API/model) as the next trend in application development. The Spring Framework gets some good press here since it matches Duncan's definition of meta-framework to a tee.

Why meta-frameworks? Duncan has some great points including this:
This then is the major carrot that meta-frameworks can offer to enterprise development shops - stability, but without stagnation. A meta-framework has to evolve and offer it's consumers the latest and greatest whilst at the same time maintaining a rock solid foundation for existing applications.
I think the isolation from the underlying APIs is a nice benefit of meta-frameworks. However, I also think that after the associated learning curve, a good meta-framework can speed development of good development practices. In fact, sometimes they encapsulate best practices. For example, with Spring you don't have to write Factory classes/methods any more. So, it makes it easier and faster to write loosely coupled code with all the benefits of the Factory pattern.

As I mentioned in my previous post, I just finished the design phase of a new project. On this project, I'm specifying that we use Spring. I'm excited to start the development phase and experience a real world example of a clean architecture built around Spring.

4/21/2005

Metawriting

For the past week, I've been spending the majority of my time writing a design document for my current project. The document has been challenging for me to write because there was alot of material to cover and I wanted to communicate the design in a "low tech" way. The low tech requirement was driven by the amount of experience the client has with the technologies we'll employ in the project.

While I was writing this document, something struck me. I was writing about writing. I was writing a document about writing software. In effect, I was "metawriting". The concept struck me as funny and I wondered why it had never occurred to me before.

So, I started thinking more about that. It got me thinking. Do authors write formal documentation detailing the novel they are writing? Nope. Do painters write a formal specification for their next painting. Never. What gives?

I'm thinking that writing software is not an act of intensely personal expression that writing novels and painting are. Sure, writing chunks of code can be. But, in most cases, the process of writing an application is not.

Writing software is much more like architecture where you create a design specification (sometimes in concert with others) that details how something will be constructed. The architect exhibits personal expression in the beauty of the design. The builder can exhibit personal expression in the craftsmanship and interpretation of the design.

However, how much beauty and art do you typically find in a software architecture document. If you read mine, very little. I typically bang out a document following as many best practices as I can. I also try to leverage work that I've done or seen before and steal ideas and pieces of design from other places. In fact, I'll copy the format of the specification document or even large paragraphs from other documents.

Am I really practicing an art like architecture? I don't know. I don't think I've ever designed the software equivalent of the Eiffel Tower, New York's Guggenheim Museum, London's Tower Bridge, or even the Leaning Tower of Pisa. Sure, I've had leaning designs, but not with such style.

I feel like I'm missing something. Everyone wants to compare software design to architecture. On the one hand, I agree - you create a formal specification that details how something should be built. On the other hand, I'm missing the beauty - and believe me, I LOVE writing software.

I am sure that some of it has to do with either my level of talent or my skill level. I can think of some examples of beautiful software designs: Common Lisp, Emacs, the Apple/Next Cocoa Framework, and more recently Ruby on Rails. Perhaps the best thing I could do, just like apprentice architects, is study great software designs to understand what makes them great.

I'm well aware that software patterns are an attempt to do the same thing. However, I think there's more there. It's not just the classic design elements, it's how those elements come together to create something beautiful. That's what's missing from a pure pattern study.

So, perhaps the realization I've been metawriting and what that means has given me a new direction. Wouldn't that be cool?

4/13/2005

Jakarta Commons Online Bookshelf

Jakarta Commons Online Bookshelf is a collection of PDFs that detail each of the pieces of the Apache Jakarta Commons components. You can purchase them individually for $4 - $7 each or you can purchase the whole set for $39.95.

I'm strongly considering purchasing some or all of these. I have used Apache Commons components on my projects for the last few years. I've struggled along with the "thin" documentation and information from mailing lists. This set of PDFs may save my sanity.

Best Practices for Java Logging

Today I've been looking into best practices for Java logging. There's alot of information out there, but I was looking for something very tangible - what to log at what level (Apache Commons Logging with Log4j) and when. I found what I was looking for in the Best Practices section of the Apache Commons Logging User Guide.

I'm starting a new project, and I'm going to adopt the recommendations in this guide. I've been logging some things, specifically exceptions, at inappropriate levels. I've been logging too many exceptions at the "debug" level. This causes the administrator to run the application with the "debug" level of logging turned on so that there is traceable information when something goes wrong. In addition, I've been logging too many exceptions at "error".

Hopefully, by following the Commons Logging practices, I'll get a log file with more valuable information.

eWeek: Browsers Get Ready for Graphics Boost

eWeek reports that Opera and Mozilla are going to incorporate SVG support instead requiring you to use the Adobe plug-in. VERY nice. Hopefully this will increase the adoption rate of SVG.