There is no such thing as perfect code

The title alone may offend some folks that read this post, but, please, hear me out before you close the browser window and go away muttering “this guy has no idea what he’s talking about”. I was talking to a developer friend of mine today and he made the statement “there is no such thing as perfect code”. The statement kind of took me by surprise but as we talked through it, I came to see his particular point.

How many times have you written an application or feature that solved a particular problem and then gone back to look at it later and thought to yourself “this is some really crappy code that I wrote–I wish I could redo this and do it ‘right'”? I know I have had that thought countless times looking at things I’ve written over the last 11 years of my professional development career. Did we think the code was “crappy” when we launched the application? Chances are the answer at that time was no. So, what changed?

Read More

ModelGlue 3 first impressions from an MG newbie

For the last 5 weeks, I’ve been working on a proof-of-concept application for a client using ModelGlue Gesture. This was my first “real” experience with ModelGlue. My only other exposure to ModelGlue came from watching a Breeze (as it was called then) session from Joe Rinehart where he built an entire blogging application in 7 minutes (or some equally ridiculously short amount of time). At the time, frameworks and design patterns hadn’t “clicked” with me and I struggled mightily trying to understand the concepts of what was going on under the hood. Needless to say, I didn’t pursue ModelGlue for very long due to my lack of understanding and the usual pressing project schedules.

Since that time, I’ve had the opportunity to get some formal training in MVC frameworks (specifically MachII) and have built a few applications using MachII. Along the way, the reasons for using an MVC design pattern have become much clearer and I’m now comfortable thinking about applications in the respective tiers that MVC frameworks encourage you to develop with. Having all my MVC experience in MachII up to now, I was really excited to have the chance to build an application in ModelGlue, and be able to work alongside Dan Wilson as we built it. It’s not often that you get the chance to learn a technology by working with one of the folks primarily responsible for the technology.

Read More

What’s your favorite Subversion repository organization scheme?

I use Subversion for my source code management needs. Every project that I work on gets put into my Subversion account at my hosting provider even if I’m the only one that will ever work on it. Using Subversion has saved me from significant loss of work on a number of occasions, so there’s no way that I’d consider not using it. I’m considering bringing my Subversion hosting in-house to a VPS that I control and have been thinking about how I want to organize my repository.

I’ve seen two different methods of organizing the repository–having a separate repository for each project, and having one, master repository with separate directory for each project. I can see advantages and disadvantages for each. Separate repositories allow individual access controls and maps directly one to one with Trac projects. One consolidated repository makes administration easier by putting everything under one repository.

So, my question to you folks, is what organization method do you prefer and why? If you’d like to share your opinions, success/failure stories or other relevant info, please feel free to leave a comment below. Thanks in advance for your input.

What I’ve Learned: MVC frameworks are worth it

Most of us that have been around programming for a while have heard the arguments for separating content and layout in our applications numerous times. Likewise, most of us have nodded our heads and generally acknowledged that it’s a “good idea” or something similar. Over the last few days, it’s really hit home for me why this is such a good idea.

Two of the projects I’m working on at the moment have had complete user interface updates in the last two weeks. One is a MachII project I’m working on with my brother. The other is a ModelGlue project I’m working on with another client. In each instance, the decision was made that the template that we were using just wasn’t flexible enough to allow us to easily do what we wanted to so the decision was made to replace it. I’m not talking about a simple color scheme change–both these were radical template changes that changed overall layout containers and content containers as well as the styles for the content elements themselves.

In a traditional, “spaghetti” ColdFusion site like we all wrote back in the early days (what I like to call the “Bad Ole Days”), this would have been a nightmare to do on a site of any size. Granted, these two applications were both small- to mid-sized at the moment, but the amount of work and testing required would still have been significant.

Here’s the real kicker though. Each of these were done in less than 1 man day’s worth of effort due to the way MachII and ModelGlue separate the different parts of the process of generating the final HTML page! That’s just awesome as far as I’m concerned!

So, for those people that use the argument that MVC frameworks are more work than they’re worth except in large, enterprise-class applications, I submit that the first time you encounter this situation, you just might change your mind.

*Disclaimer: I know that there are other MVC frameworks out there for ColdFusion and they solve a lot of the same problems that MachII and ModelGlue do. I only mention these two here because they’re the ones that I worked with directly.

Configure FusionDebug 3 Beta for use with Railo 3.1 on Tomcat

For the past couple of months, I’ve been running my CFML server engines (yes engines, plural) on top of Tomcat on my local development environment. This offers me, as an independent developer that works on a number of different client projects, a great deal of flexibility in matching a particular client’s production configuration. Also lately, I’ve been working on a couple of projects using Railo 3.1 as well as a project for a client that still uses CFMX 7. One of the things that I really missed when not developing with ColdFusion 8 is the step debugger that ships with CF8. I’d used FusionDebug some time ago with CFMX 7 when I was running it on top of JRun 4 but had never gotten around to getting it configured under my current, Tomcat-based setup. Until tonight that is.

I ran into a situation while working on a MachII application running on Railo 3.1 where I REALLY need to see what was going on with the various variable scopes during the request cycle, so I decided tonight to see if I could get FusionDebug 3 Beta up and running with Railo and Tomcat.

Read More