Microsoft Hates Testing … Um, No Surprise There

Posted in: Software Development Best Practices

A colleague of mine forwarded an article to me during this last week, which he prefaced with the following statement …

guys, I’ll write it in all caps and bold:

I AM NOT PROMOTING OR IN AGREEMENT OF ANY OF THE POINTS THE ARTICLE MAKES.

… which begs the question, why did he send it not only to me, but an entire team of people? I choose to believe it was because he is an enlightened soul that understands that the best way to reinforce your own beliefs is to read more of the opposing point of view, not more of the view you already have. I am lucky to have a few of these souls working for me right now.
Continue reading »

O.C. the Rodney Dangerfield of LinkedIn?

Posted in: Social Networking

… LinkedIn, the business-oriented social networking site, groups Orange County not just with Los Angeles but Riverside, San Bernardino and Ventura counties, under the umbrella of “Greater Los Angeles.”

A group of Orange County business people recently hollered, “Enough!” … 2,500 have joined the We Are Orange County group on LinkedIn to persuade LinkedIn to use Orange County as a member geographic designation.

Read more in this OC Register Article.

10 HTML Tag Crimes You Really Shouldn’t Commit

Posted in: Software Development Best Practices

You better watch out, because the HTML police are about. They scour your code and pick out the most unspeakable crimes against HTML markup. This handy list of ten HTML tag crimes sheds some light on some of the most common coding mistakes and helps provide an alternate solution. Tips include writing valid markup, making semantic choices, avoiding deprecated tags and more!

http://line25.com/articles/10-html-tag-crimes-you-really-shouldnt-commit

The Subversion Chronicles – Repositories and Projects

Posted in: Software Development Best Practices

Repositories
A repository is normally hosted on a remote server and cared for by an administrator. It should contain all of the revisions of all of the artifacts that a development team produces. Therefore the repository is probably the single most important physical asset a development team has. As a result, access to the host machine is usually limited to the administrators only and it is normally backed up on a daily basis for disaster recovery purposes.

Under normal circumstances developers never need access to the host machine directly (e.g. through ssh). Instead developers make use of a client program that talks to the repository on their behalf and are authenticated through the server process related to Subversion and do not need local OS accounts on the sever at all.

Repository URLs
Access to a Subversion repository is achieved via a standard and familiar HTTP URL. For example, from a command-line you can checkout the trunk of the Example project, using the following command:
~/dev/test $ svn checkout https://svn.mydomain.com/repos/test/exampleproject/trunk

Projects
A single development effort involves the creation of resources like source code, images and build-scripts. In Subversion, this group of related resources is usually called a project.

There can be (and often are) multiple projects hosted in the same Subversion repository. Alternatively, a one project per repository approach is also possible.The Subversion Chronicles will deal exclusively with this multi-project repository layout option.

Multi-Project Repository Layout
When hosting multiple projects in the same repository, there is a generally accepted way to lay the repository out. The root of the repository will contain one directory per project and for ease of use, the names of these directories should relate to the name of the project.

For the examples in this series of articles, the URL to the root of the repository is:
https://svn.mydomain.com/repos/test

So, if we had a project called Example Project, then the URL to the project would be:
https://svn.mydomain.com/repos/test/exampleproject

Project Layout
Within each project, there is also a recommended layout. The main line of development is known as the trunk, and it (not surprisingly) should live in a directory called trunk, directly under the project directory.

All of the tags related to a project should be placed under the tags directory which is also directly under the project directory.

All of the branches related to a project should be placed under the branches directory which is also directly under the project directory.

The Subversion Chronicles

Posted in: Software Development Best Practices

This is the first of a planned series of posts capturing the information needed to interact with a Subversion repository as a client. These posts are based on my experience working currently with a large team moving from a CVS repository over to Subversion and all of the lessons learned during that process.

I intend to capture the details related to one Subversion concept or command in each post. At the end I will detail my recommended overall development process using Subversion that will leverage each of the concepts and/or commands I cover.

Currently, it is not my intention to cover the details of administrating a Subversion server as part of this series of articles.

For the examples I will be using version 1.5.5 of the command line client, running on a Mac OSX 10.5.6 machine. The server is a CentOS 5.2 machine, running 1.5.6 of the Subversion server. The client will access the server over https using WebDAV. There is a repository set up on the server, called test and it is accessible via the following URL – https://svn.mydomain.com/repos/test.

Upgrades, upgrades, upgrades everywhere

Posted in: Enterprise Java

We are bombarded with hype about new versions of tools (like IDEs), or new libraries (like a new JDK), or a new software package (like a new object-relational mapper) all day long. But do we even need them? Can’t we basically create what we need to complete these mundane everyday tasks with the tools we already have? Aren’t most of these new releases just a way to sell new software licenses? Even when it comes to opensource software, upgrading to a new release has an inherent cost that needs to be weighed.

Here is a real world example. I am currently invovled in a project that involves upgrading the code base from JDK 1.4 to JDK 5 as part of the scope. My Engineer brain says that this upgrade is not only necessary, but just a plain good idea. There are some new language features in JDK 5 that we can take advantage of, so there is a benefit. But what are the costs? There is definitely a cost involved in doing an audit of the existing code and seeing if there is any code that is incompatible with the new JDK and putting together a plan and effort estimate to address those issues. There is also a optional cost of retrofitting the existing code to take advantage of the new language features (like enums for example). There is a learning curve cost. Perhaps there is a confusion cost for some junior engineers (I am thinking of the autoboxing feature). There is a cascading cost that we now also have to consider upgrading our application server environment to support the JDK 5 code.

So is all of this cost worth it? Will the benefits outweigh the risk and give the company some kind of ROI? I think in most cases, the answer is actually a defiinite yes.

Take the Java 5 upgrade example. Apart from the obvious technical benefits, there are a whole host of trickle down posiitve benefits. For starters, I think many companies underestimate the importance of keeping the geeks happy. Engineers like to use new tools and stay on the cutting edge. They like to be able to read articles in the latest journals and be able to apply the lessons learned straight away. Happy Engineers are good employees. They are more productive. They are more collaborative. They tend to not be looking quite so hard for that next dream job. They tend to be more forgiving of working conditions that might not be ideal. Engineers are creatures who like to learn and keep learning. Working on the same code and project and tools for year after year will be the death of an Engineer and you will end up with just mediocre Coders left on your team as the Engineers will be long gone.

So before you decide on your next upgrade, think about all of the costs involved, there are many hidden ones you may overlook at first glance. But then make sure you also think about all of the benefits (both short and long term). Not every upgrade will make sense, but I bet that a majority of them will.

Are our tools built for problems most people don’t need to solve?

Posted in: Enterprise Java

Not everyone is working on projects for the Defense Department where milliseconds could mean the loss of thousands of lives.

And not everyone is working on the backend for the stock exchange.

And most people are not writing their own application servers from scratch.

What are most people working on? Well that is a little hard to quantify, but it is a pretty safe bet that it is not a sexy application that they are bragging to their friends about. If you believe the 80/20 rule (and I do), most people are actually working on maintenance activities more than inventing something new from the ground up. Those who are inventing things from the ground up are more likely to be building a .com site for their company to show off their wares – it might even have an element of ecommerce to it, but then again, probably not.

So we are bombarded with hype about new versions of tools (like IDEs), or new libraries (like a new JDK), or a new software package (like a new object-relational mapper). But do we even need them? Can’t we basically create what we need to complete these mundane everyday tasks with the tools we already have? Aren’t most of these new releases just a way to sell new software licenses? Even when it comes to open-source software, upgrading to a new release has an inherent cost that needs to be weighed.

Here is a real world example. I am currently invovled in a project that involves upgrading the code base from JDK 1.4 to JDK 5 as part of the scope. My engineer brain says that this upgrade is not only necessary, but just a plain good idea. There are some new language features in JDK 5 that we can take advantage of, so there is a benefit. But what are the costs? There is definitely a cost involved in doing an audit of the existing code and seeing if there is any code that is incompatible for the new JDK and putting together a plan and effort estimate to address those issues. There is also a optional cost of retrofitting the existing code to take advantage of the new language features (like enums for example). There is a learning curve cost. Perhaps there is a confusion cost for some junior engineers (I am thinking of the autoboxing feature). There is a cascading cost that we now also have to consider upgrading our application server environment to support the JDK 5 code.

So is all of this cost worth it? Will the benefits outweigh the risk and give the company some kind of ROI? I think in most cases, the answer is actually a defiinite yes.

Take the Java 5 upgrade example. Apart from the obvious technical benefits, there are a whole host of trickle down positive benefits. For starters, I think many companies underestimate the importance of keeping the geeks happy. Engineers like to use new tools and stay on the cutting edge. They like to be able to read articles in the latest journals and be able to apply the lessons learned straight away. Happy engineers are good employees. They are more productive. They are more collaborative. They tend to not be looking quite so hard for that next dream job. They tend to be more forgiving of working conditions that might not be ideal. Engineers are creatures who like to learn and keep learning. Working on the same code and project and tools for year after year will be the death of an engineer and you will end up with just mediocre hackers left on your team as the engineers will be long gone.

So before you decide on your next upgrade, think about all of the costs involved, there are many hidden ones you may overlook at first glance. But then make sure you also think about all of the benefits (both short and long term). Not every upgrade will make sense, but I bet that a majority of them will.

What Drives Successful Technology CEOs?

Posted in: Software Development Team Leadership

What Drives Successful Technology CEOs? An Informal SYS-CON Survey
— What drives a technology CEO or CTO to success in today’s constantly changing technology ecosystem? We look at the question through the lens of the many interviews and articles we have published at SYS-CON.com which deal, sometimes only in passing, with exactly this issue. Executives quoted include Appcelerator CEO Jeff Haynie, Nexaweb Co-Founder & CTO Coach Wei, the founder of Internet.com Alan Meckler, and the Chairman & CEO of Parasoft Dr Adam Kolawa.