Friday, May 25, 2007

Too Much Code

With the numerous software frameworks in existence today, it is easy to question yourself as soon as you associate copying and pasting with software reuse. I use to think that developing user-interfaces for desktop applications involved a lot of redundant (redundant is a technical term for boring) code but had to correct myself the minute I started working with web applications. Instinctively the copying and pasting felt wrong and started searching for more "clever" development practices to apply to a somewhat daunting code base.

With Struts, a developer creates JSP pages, maps the functionality found in the JSP page to an Action via the struts-config file, then implements the Action to execute the desired functionality. You wash, rinse, and repeat for every single JSP page and watch the amount of code pile up even when implementing the simplest of web applications. A developer could spend more time on consolidating the code but runs the risk of decreasing the site's maintainability if the code becomes too generic. Sometimes people forget how clever they really are until they have to revisit a project where everything is handled with general terms. For me, it has been easier to focus on developing maintainable code through refactoring and documentation then worry about the number of files a web application contains.

Until I investigate more, I found a way to optimize the annoying "copying and pasting" design pattern by using code templates in your favorite IDE (my favorite is Eclipse). With Eclipse a user can make use of a number of built-in code templates and can add their own pretty easily. This is a pretty simple utility that can save a developer time but is often overlooked. I found two articles (part 1 and part 2) that go through the basics of using and creating code templates within Eclipse.

Friday, May 18, 2007

Mock Objects

Obviously testing software before it is released to the masses is important. Testing is also a great way to verify project requirements and in some extreme cases, drive the entire development of an application. When you start thinking about large web applications that operate in a distributed environment and service a large number of clients - testing should be the first thing that comes to mind. However, it seems that in certain cases, the size and complexity of enterprise applications make testing a resource intensive, daunting task that gets ignored. As a naive enterprise developer, I set out this past week to investigate the various testing strategies and break the testing stigma that plagues smaller enterprise development boutiques.

From the research I conducted, the most popular approach seems to be making use of mock objects during development. Since most web applications require interaction between multiple components or services it is often hard to write a test case for an individual component without first implementing all collaborating components. The basic principal behind mock objects is to provide basic, functional collaborating objects without disrupting the task at hand. Aside from being useful during development of an individual component, using mock objects also allows you to perform additional testing on the component without impacting live data or configurations (this is handy for verifying requirements). The mock objects approach promotes the use of a factory design pattern to provide a single point of entry for "mock" components. As someone who is new to the enterprise scene, this concept took a while to understand. I hope that all the work I spent digesting this information pays off when I take my very first web app from soup to nuts.

Friday, May 11, 2007

Enterprise impressions from a desktop perspective

Up until this point in my career I have only dealt with client (or desktop) programming. My initial, albeit overly optimistic, impression was that web programming was a simple enough technology that I could pick it up in a matter of hours if need be. Before I go any further let me give you a little background, I graduated college 3 years ago and started my professional career working for a research and development company that helped clients transform theoretical knowledge into software prototypes. Most of the development was done in Java with the occasional performance-centric work being completed in C. Towards the end of my time at my previous company I began to get curious about object relational mapping frameworks (a la Hibernate). After working with Hibernate for a few months I quickly began to appreciate the amount of work that goes into building enterprise systems. Coincidentally I had also started hunting for a new job so I thought it was an excellent opportunity to broaden my horizons and dive into enterprise development.

The choices for a web programmer (web programming does not include design related tasks) are limitless. Speaking from a Java perspective alone, there are a wide variety of frameworks and configurations to choose from when developing a new web application. In my new job I will initially be working with the Struts framework and the common controls presentation framework all running inside of the Tomcat web container. I spent the first few days sifting through the different point releases of the servlet specification and the struts framework trying to figure out how everything fit together. Needless to say it was overwhelming but the exploration quickly changed to challenging and enjoyable. So far the only real frustration I have encountered is there seems to be a serious gap in unit-testing solutions for struts based applications. Sure, a few exist but none seem to be as complete as I'd like.

I would encourage you to take the time to at least survey the enterprise landscape if you haven't done so already. Over the next few months I intend to update this blog with my impressions based on my journey and hope it will be useful information for developers following a similar path.