Thursday, September 27, 2007

Rails

So I've been trying to be more open minded lately, especially when it comes to web development. I decided a few weekends back to take a serious look at RoR and I can easily say it was time well spent. Once you get over the initial setup, you can see how easy it is to develop a web application in a fraction of the time it would take if you were using a competing technology (OK, Java Web Development is the only comparison I really have...).

It has been tough for me to get excited about web development because, to me, a simple task becomes overwhelming due to the amount of code and configuration one must perform. Ruby on Rails has me excited in a big way...And yes I have done my fair share of reading about scalability issues. Captain Obvious says, scalability is always an issue regardless of the underlying technology! Yay for Moore's law (you better appreciate it while it's still around).

Tuesday, August 21, 2007

Restarting

The title of this post is multi-purpose. This blog has been desolate all summer so I am "restarting" this blog as we move into the fall. I have been busy learning all about the wonderful technologies that make Java web applications run and can't wait to forcefully share my wisdom to my loyal reader(s).

One thing I have decided about Java web apps is restarting your web container of choice is a real pain if its done as often as one would build a Java desktop app. You see, everytime a change is made, the new class files must be deployed to the web container and the web container must be restarted. Restarting a web container can take anywhere from 1 to 30 seconds depending on the size of your web application. At the time of this post most restarts of my web container take 25 seconds plus giving me an opportunity to break away from work, surf unproductive web sites, and totally forget what I was doing by the time the web container comes back online. Fabulous.

Wednesday, June 20, 2007

Java User's Group

Being new to the Albany area (and a quasi urban surrounding in general), I recently had the opportunity to attend my very first Java User's Group (http://www.cdjdn.com). There were two presentations, the first was from the creator of Sleep an open source scripting language loosely based on Perl with an Objective C-like syntax and the second was from the author of Netbeans 5.5 Enterprise Edition. I was lucky enough to win a free copy of the netbeans book which rounded out my experience with the folks from CDJDN. If you are in the Albany area or know of a local JUG in your hometown, I highly recommend attending a meeting or two.

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.