Internet Software Development: Choosing the Right Tool for the Job
Be the 1st to comment!

Rarely does a day go by, that I do not receive an article in my email or among the many RSS feeds I monitor, that compares various Internet software development tools and frameworks. Inevitability, the comments following the comparison turn into a war of words between the two camps compared. Each believes its framework or tool is the best. What strikes me is that rarely are the project requirements included in the discussion. It always seems to be based on the concept that there is one right framework for everything, and I cannot disagree with that more. Over my thirteen years of developing Internet applications I’ve used Perl, PHP, ASP, Javascript, XML, XSL, and Java (using JSPs, Servlets, Struts, WebWork). Now I’m learning and writing a applications with Ruby on Rails. Though Java has been my focus for the last nine years, I recently changed the title I prefer to use. No longer do I refer to myself as a Java Developer/Architect. Instead, I identify myself as being in the industry of Internet Software Development and Design. While the difference in the terms may seem insignificant, it is actually quite substantial.

There was a time when I believed Java was the only language anyone should use to write Internet software, but eventually I realized you can’t make that claim for any development framework. They all have their pros and they all have their cons. I don’t pick what is latest and greatest, because the latest is never guaranteed to be the greatest. Neither do I ignore the latest in defense of what I currently feel comfortable with. I do choose what fits my personality, what I enjoy working with, and what is best for the project at hand, including the ability to meet very tight deadlines. The key is: matching the language and the framework to the project. Many factors contribute to this selection. Here are some situations and the frameworks I generally use for each.

Read More »

Seth Godin's How to Create a Great Web Site
Be the 1st to comment!

Seth Godin is a best-selling author and entrepreneur and writes very insightful books on the topics of marketing, entrepreneurs, and personal success. In this article Seth outlines ten very simple components of a great web site. The list is well thought out and what amazes me is how many of these items I routinely see ignored on the Internet and how many of these points have been ignored by clients and/or companies I’ve worked with in developing web sites over the years.
The good news is that while there are over 50 million new web sites every year, the majority of them are the exact opposite of this list and become complete failures. You can still stand out in the crowd by creating a truly great web site.

Read Seth Godin’s, How to create a great website.

Writing code to be readable over time
Be the 1st to comment!

At the Rails Way blog, Koz has posted an example of refactoring Ruby code to make it more “human” readable. He states this opinion:

It’s far more important for code to be human readable than incredibly concise.

I agree with the statement, but think its important to define “human readable”. In the example, both the before and after are clearly human readable by the human developer who wrote it. In fact, at the time of writing any piece of code the developer clearly is able to read it, or would not be able complete it.

The reason to create more readable code is not for the benefit of reading it easier at the time of development, it is so you can more easily dive back into it six months later, after you’ve forgotten why you did it the way you did it. There are so many solutions to every development situation, and six months from now you might not being using the same patterns for your development as you were then. Or, a different developer, with different preferences for coding style and patterns, may need to read your code and understand it very quickly.

It’s not that the future developer can’t understand it either way, but simply the reduced time to jump right to the matter at hand and focus in on the solution. As I said in the comment on the post, this particular example shows how to break up the various tasks of the activity of validating this Expense object, so that you can jump right to the validation issue that may be causing the problem. You don’t have to weed through a possibly very lengthy validate method, reading every single line until you find the one that might be at issue. Instead, you can read the descriptions of each validation step at the top (the pseudo code method names serve as descriptions) and thin pinpoint the validation step or steps that need a fix or expansion.

Taking the time to do this type of code refactoring at the point of original development, when you understand what is going on because you are fully involved in it, will save you and/or other future developers massive amounts of time and grief when readdressing the code months from now.

JVM Garbage Collection presentation from IBM
Be the 1st to comment!

The ServerSide has posted an interview with Dr. Holly Cummins from IBM who recently gave a presentation on Garbage Collection. She expresses her disagreement with some common beliefs about GC, and gives some recommendations for understanding your verbose GC and using it to tune the GC.

Some quotes from her presentation are highlighted below.

In response to the claim:

Garbage collection does work and causes pauses and the pauses prevent my application from doing work so the shorter the pause the better.

Dr. Cummins answers:

Not true! Even when a garbage collector spends a lot of time paused, application performance may be better.

Dr. Cummins also disagrees with the claim:

OK, I get that the application would go faster if I could tolerate long pauses, but response times are critical for my application so the shorter the pause times, the better off I will be”

She goes on to give some recommendations on adjusting heap size, choosing the right GC policy, and using a toolkit from IBM.

The slides are provided online in a PDF.

The video can be seen, along with accompanying discussion on the Server Side (once everyone gets over her appearance).

Focused Problem Solving
Be the 1st to comment!

My favorite web development company, 37 Signals, recently added a post by one of their team members, Jason. He discussed some of the decisions and process that went into a recent functionality addition to their product Highrise. They set out to provide import functionality that their customers were asking for, but in their pursuit of a solution they got off track due to thinking too large.

Sometimes development and design teams can think too small, and not see the forest through the trees, but at other times, and I see this a lot in the IT industry, development teams think way too big. They see a problem and instead of focusing on the important issue, they attempt to provide functionality just in case they might need it some time down the road. But just in case development is very costly, and from my experience, most times that “case” never actually occurs.

The point of Jason’s post is that in this instance, not only did they waste time, but they also didn’t even provide the needed functionality, because they lost focus on the particular problem that really needed the must urgent solution.

In Jason’s words:

…don’t lump a bunch of related small problems together—it just makes one big problem. One big problem requires one big solution, and big solutions take a long time (and often don’t go right). You’re better off chopping big lumps of problems into smaller chunks until you’re able to knock them off one at a time.

Read the entire post, “Design Decisions: Highrise import“.

Page 3 of 612345...Last »