Always read.

Always be reading. It is the single most important thing you can do to both and improve your game and improve your income.

In 1996 when I graduated from college and got my first salaried job, I met a contractor named Scott. For whatever reason, he took interest in me and among other gems, gave me the above advice. We were on a DoD project coding a large system in C++. Scott had referred me to nearly a dozen books that were "must reads" in the field. Here's a sample of them (I still remember these to this day):

• Code Complete by Steve McConnell
• OO Analysis and Design by Grady Booch
• Design Patterns by GoF
• Effective C++ / More Effective C++ by Scott Meyers
• C++ How to Program by Harvey & Paul Deitel
  

I'm not going to go on about how I became the project architect overnight. What I will say is that I bought and read all of the above books. In just a few months I went from a "new grad" to hanging in there with contractors who had been in the game a while. My stock went way up. Management wanted to keep me around. Because of my 140 I.Q.? Hardly. More becasue I gave a damn about what I was doing, and it showed through my personal growth.

Read good books.
I'm not talking about how books - the 900 page tomes addressing Ruby on Rails. I am talking more about why books. Books such as these have really made a huge difference in the quality of my code.

• Any of Martin Fower's Signature Series books


• Object-Oriented Software Construction by Bertrand Meyer


• Software Project Survival Guide by Steve McConnell

These are not "new" books. These are especially good to reference when prepping for interviews. There is just so much good material in there.

Do I practice what I preach? I sure do. My current deskside reference is from the Fowler signature series - "Refactoring to Patterns". It's great stuff.

Analizing technology pairings - Ajax and JMS

I recently read this proposal for Ajax/JMS event queueing and I have to say I initially like the idea of the technology pairing. So how would I evaluate it?

As the author has responded in the TSS blogs, this does not necessarily need to be JMS. The undelying thought is still sound - to combine AJAX communication events to another publisher-subscriber framework where others subscribe. It's a great way to decouple the UI from the middle tier. It actually decouples the middle tier API from the requests.

Would it be performant? That seems to be a chief concern, especially when bundling with JMS. However, I really think it could be, if you set it up correctly. Thoughts that come to mind are having prioritized messages - one for things that need to be snappy, and another for longer running asynchronous requests. I'm sure there are tons of strategies in the JMS community to get the performance that is required.

But why do it? Is there a better way? Where is the "win"?

Pros

Well, any time you introduce an event queue, you tend to get a defacto throttling mechanism built in. Your even queue simply expands if the server falls behind, rather than performance being killed across the board.
Adding an event queue also makes it very flexible to add event consumers, in that you just register other interested parties in the topic. I can see the utility in this too.
If you already have JMS messaging in place - that would certainly leverage existing JMS expertise and codebase, which itself has a very simple and natural API.

Cons

It seems like utilizing AJAX to call web services directly could be just as flexible. This would allow both the UI and third parties to exercise the same API. A limitation to calling web services is the security issue where you can only communicate with your request's originating domain. Therefore, if your services client is external to you, then you need to proxy the service request on your server.

If you don't have JMS in place, then there will certainly be some care and feeding of those components as technology moves forward. And there will be development costs to getting familiar with the framework.



This bumps Ajax in Action to the top of my reading queue.