Archive for June, 2008

Today we’re releasing version 1.1.9 of our WordPress table of contents plugin into the wild.

Download this release:

• wptoc-1.1.9.zip
• wptoc-1.1.9.tgz

This release is production-ready and has been in use on our own WordPress installations for a while now.

For more information on the plugin, including documentation, FAQs and examples, take a look at the main WordPress Table of Contents Plugin page.

We’re always interested in hearing about how people use our software and what their impressions are. That feedback helps us become a better company. It also helps us come up with new ideas. So, if you’re using the plugin, take a second to drop us a line or leave a comment to tell us what you think.

Happy Blogging!

Every day it seems I read an announcement of the release of a new Java framework, or an upgrade release for an older framework.

Three facts should tip you off to a problem with using Java for web projects:

1. There are a lot of Java frameworks for building web-apps.
2. Many of these frameworks try to solve the same set of problems.
3. Many frameworks are built just to improve upon weaknesses in other frameworks.

The third point causes the most concern. If every framework needs yet another framework to make it complete, then you’re never going to end up with a complete solution. You’re going to be passing the buck endlessly, and forever looking for a solution to your immediate problem.

Next question is, why are there so many of them? Surely if someone could build the perfect Java framework for building web-apps someone would have over the last ten years.

This leads me to think that:

“You can only put so much lipstick on a pig.”

Java is just the wrong tool for building web-apps. Scripting languages are far superior. The main reason for this is the statically compiled nature of Java. Interpreted languages will give you a much faster and continuous development cycle.

I welcome your comments on this topic. If you think I’m wrong, show me how and why. In particular, tell me what combinations of frameworks work best for you.

When all you have is a hammer, every problem looks like a nail.

IT organizations often identify with one technology stack or another. They consider themselves “a Microsoft shop” or “a Java shop”, etc. They tend to stick with a narrow set of tools for all of their needs.

Who can blame them though? Who has time to learn every tool out there?

The ability to leverage many different technology stacks isn’t something that can be accomplished overnight. It takes a long time to build enough familiarity with a technology to be productive using it. The hardest part of learning a new technology however is deciding what to focus on next?

The fact of the matter is that every technology is better suited to some problems than others. You’ll get a better finished product and a smoother development process when using a tool that’s well-matched to the problem at hand.

One of the many wonderful things about working for as many different organizations as we do here at the Codeworks is that we get to work on a regular basis with a broad set of tools and technologies. We have the luxury of keeping our skills fresh. And this translates into more options for our clients.

When you hire us you will get an honest, unbiased opinion on how to get to the finish line in the fastest, simplest way possible. You will also be able to leverage the technology flexibility that our broad skills set provides. What this ultimately means to you is that your projects will get done faster and with fewer hassles when you outsource them to us.

Contact us for a free consultation on how we can help you get more mileage out of your technology investment and the agility your organization needs to be successful.

I regularly come in contact with business owners, marketers and other non-technologists who are right at the beginning of a new venture. Money is tight, and in an effort to get the ball rolling they suggest bartering services. While some of these projects sound exciting, things I’d really like to be able to contribute to, a straight service barter arrangement is a recipe for disaster. Here’s why.

Leverage is a key ingredient to making projects work. When it comes down to it, we each have needs, and the whole point of working together is that we can more effectively meet those needs as partners than we can as individuals. Leverage is the catalyst that makes partnership work.

In every project there will come a time when you need to be able to steer a deliverable or a design in one direction or another. This is one of many examples of why leverage is so important. Sometimes you’ll need to enforce a deadline. Whatever the case may be, being able to get what you need comes down to having leverage over your partners, vendors and yes, even your customers.

The idea of receiving service without letting go of cash is appealing to many. But cash is the fulcrum that gives each party the leverage they need to keep a project on course. Without this leverage projects will invariably lose momentum, stray off track, and fail to meet expectations. It’s a straight-up recipe for disaster.

I’ll continue to be wary of service bartering arrangements. I just don’t see any way for them to work to everyone’s advantage. One side or the other will always feel that they’re getting the short end of the stick.