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 »

This week I had to create a sequence diagram. In the past, I’ve used MagicDraw, my favorite UML tool. However, I do not personally own a license to it, and was only fortunate to use it at a company that did. I have used ArgoUML for Use Case and Activity diagrams, but have not attempted a sequence diagram with it until this week, and found it to be difficult and limited in functionality.

So the search began for an alternative, and I was fortunate to find Sequence. Sequence is a Java GUI, which allows you type in a notation for a sequence diagram and then it creates the diagram as you type. You can save the notation as a text file, and export the diagram as a graphic.

There was a mild learning curve for the notation, but once I learned it, creating the diagram was almost as easy as just thinking about it. In the past, sequence diagrams were always difficult to create, because they were so time consuming if you had to make a correction, like adding a bunch of new classes and method calls at the top of your diagram, which causes you to have to move diagram objects around.

With this tool, you don’t even have to consider what it looks like, or where you place any of the diagram objects, or moving them around if you left something out.
You can download the jar file here, and read back to the beginning of the tool’s history. When you start the GUI, there are several examples under the Help menu to teach you the notation.

Brad Neuberg has a good post that discusses further the pros and cons of returning data to your Ajax requests, with out without markup.

This is a good post on The Ajax Response, discussing if it should be XML, HTML, or JSON. I personally think under no circumstances should it be HTML, or anything that includes markup. That violates the principle of separating the content from the style and it prevents reuse, by yourself and others.

I think deciding between JSON and XML is going to depend on your situation. XML is much more universal. With XML, you can create Web Services from your back end, and call them for display in PHP, JSP, and with Ajax. That Ajax call you are making today maybe a non-Ajax call you make later.

Google Suggest is a prime example of silliness. That data response is completely unusable in any other scenario. Perhaps, knowing Google, they have done this on purpose to prevent others from using that feed as freely, but it could be a handy service to offer and implement in other locations. The way Google has chosen to implement it, would require Google to have many versions of that response, for multiple uses.

With the rare exception, when you serve up data from your back end, think in big picture terms of making that data available to all your front end applications, and then apply style (HTML, CSS, etc) to it, once the data is in the front end.

UPDATE: Ignore my reservations about HTML in AJAX responses and see my followup post: AJAX Returning HTML (change of opinion).

Ironically, the very existence of an Enterprise Architect may result in your company’s IT system being anything but innovative and simple. Is it innovative to use AJAX because it’s cool? Is it simple to use EJB’s because your IDE has a nifty wizard for them?

I’m not down on the need for an Enterprise Architect – that is how I would describe myself. Yet, companies need to be really careful when they hire one of these that they don’t end up with architects who are so up with the latest technologies, that they become consumed with using them at every turn, even when not necessary (and I would classify most of the new technologies as unnecessary for the vast majority of projects.)

See my post on the costs and overhead of adopting new technologies. Far too many companies have had their software over architected, never benefiting from it, and in many cases having it re-designed when the next architect is hired.

I don’t disagree with anything in the original post, but I’ve seen this technology abuse so much in this field, and seen first hand how much it costs companies, that I also have to add my word of warning.

So the answer to the question of this post, is most definitely yes, that’s the entire reason for hiring one, however, with a big condition added, which is, the company should not qualify the candidate simply for their knowledge of all the technologies out there. There needs to be a sound and conservative approach to software architecture that will prevent the architect from over complicating the solution.