Actually, now is a really good time to have this conversation because with the work I am doing on the Exchange Web Service code, I have just finished revamping my internal infrastructure to support the equipment and software I need to do the job. So this is going to be a two-part article. In this part, I'll tell you about the software development components that I use. In the next part, I'll tell you about the infrastructure components. The problem is that you need to understand some of the details of why, so I'm going to start with a little background.

Background

There are a few basic facts about me that effect everything else:

1. I am not rich. I have to rely on the most cost-efficient solutions I can. That means that I prefer open source/free software where it makes sense.
2. I am not cheap. I recognize that building software that is commercial grade requires a serious commitment to quality. That means a serious commitment to the development process, which, in turn, requires things like solid designs, automated builds and testing, and extremely good discipline.
3. I am the worst perfectionist. A gentleman I used to work for back in South Africa, Jan Fernhout, used to tell me that I would way over-engineer things because I wanted a perfect design. That is true. I have to be very disciplined about remembering that I need to deliver something.
4. I hate mundane work. If at all possible, someone else is going to do the work for me, and I there is no way that I am going to manually do something that can be completely automated. If you make me do it, I will bleat like a sheep until you fix the problem – just ask some of my co-workers.

There are also a few facts about the development work that I do that affect everything, too:

1. I believe that Windows is for the desktop or as a departmental product and Unix is what the enterprise needs. No one has proven me wrong on this. For every example of a large Windows product installation, I can point you at hundreds of more successful, more cost-efficient, more stable, less administered Unix installations that just run.
2. I do a lot of work with both Unix and Windows.
3. Java is the most platform-independent language for back-end work.
4. .NET is the richest GUI experience you can have outside the browser on the Windows platform.
5. OpenEdge is a fact of my life. I have used it more than any other development platform. I have made a good living off it, and I love the product, warts (many of them) and all. OpenEdge is kinda like an old pair of shoes that fits your feet a certain way and you're always most comfortable wearing them, no matter how ugly they are.

Machines and Operating Systems

My desktop machine – and primary development workstation – is a Windows 7-based HP Pavilion Entertainment 64-bit laptop with 6GB of RAM and 450GB of disk space. It runs nothing but Windows, and I have a ton of software on it.

My primary server machine is a  Dell PowerEdge T710 with 2 4-Core Intel Xeon processors, 16GB of RAM and 2 500GB drives. It runs VMWare ESXi (see screenshot at right) with 20 different virtual machines on it, some constantly running and some not. I'll tell you more about this in the next post on infrastructure. There are 6 VMs, though, that are important to this discussion:

• A Windows Server 2008R2 primary domain controller (pdc);
• A Windows Server 2008R2 build server (winbuild);
• A Windows 7 32-bit build machine (clientbuild);
• A CentOS-64 development server that hosts a whole lot of stuff (develop);
• A CentOS-64 build server (build64); and
• A CentOS-32 build server (build32) .

I then have 2 other machines that are both older machines that I use for various things. I'll talk about these in my infrastructure post, too.

Components of a Development Environment

As I said, I'm the worst perfectionist. So development starts with an idea, and ends when the code has been packaged, deployed, and installed on the end-user's machine, and they have completed user acceptance testing. In other words, it not only spans the entire Enterprise Architecture stack, but it also spans the Software Development Life-Cycle (SDLC). 

Now as much as I said I am not rich, there are two very expensive tool-sets that I have to buy:

1. Visual Studio Premium with MSDN. This one sticks in my throat every time I pay for it. The only reason I need the Premium subscription is for the Windows Server and Microsoft Exchange Server licenses. The more than $5500 that this product costs is very hard to justify, and the $2300 a year charge for renewing the subscription is as bad as paying tax to the IRS. I am a firm believer that development tools should be free. If you want me to develop products for your platform, give me the tools I need to do it.
2. PSDN Professional. Although I also believe that Progress should provide its tools for free, I am less resentful about it, probably because I used to work for the company. I still think the $3,000 that we pay for PSDN is excessive, but there you have it. My guess is there would be more people developing Progress-based applications if the development tools were given away free.

I need the MSDN license for the operating system and server licenses that I am using for Exchange Server. For my non-Microsoft-based development, I rely heavily on the Java and LAMP (Linux-Apache-MySQL-PHP) stack. Because I have some experience with PHP, I try as far as possible to use Open Source tools that are based on PHP rather than Perl. I don't know Perl and I don't particularly want to spend the time on it.

So starting from concept, here are the tools that I use to get my stuff done:

•  Sparx System's Enterprise Architect (EA) for all my modeling (not just diagrams, models). The product cost me about $300 for the original license, which included the MDG technology for Eclipse integration, and I use it as a design tool from the conception of an idea all the way through delivery. It contains the business process models, the requirements, and all the UML diagrams and test cases. I am not a fan of model-to-code driven development. I think the fact that we have been looking at the equivalent of CASE tools for the last 20 years shows that there will always be those cases where the code cannot be automatically generated for you. Two of EA's strongest suites are the traceability it provides from requirements to test case, and the incredibly powerful document generation facility. I literally generate all my documents from Enterprise Architect.
• Collabnet Subversion is used as my Source Code Control System. Everything goes into Subversion, including my models, source code, document artifacts, and even my research code. Subversion runs on my development server (develop) on CentOS. Subversion has clients for all kinds of platforms, so I have AnkhSVN plugged into Visual Studio to control my .NET code, I have Subclipse plugged into Eclipse for all my Java code, and I use TortoiseSVN at the operating system level to control documents and stuff that are outside of either development environment.
• Mantis is used as my issue tracking system. There is an Eclipse plugin for Mantis so I can get at it directly from my project workspaces in Eclipse.
• Hudson CI is used as my automated build and test environment. It runs on develop, but starts builds on build64, build32, winbuild, and clientbuild. I use both Apache Ant and Apache Maven to build Java code, and I use PCT to build OpenEdge code in Hudson. I use Nant to build .NET code.
• Unit testing is the scope of JUnit and NUnit although I am vehemently opposed to test-driven development. I think it is flawed and creates really lousy software.
• Eclipse is my Integrated Development Environment of choice. I have at least two installations of Eclipse at any one time. One is for non-Enterprise development (stuff that does not require Java EE) and the other is for Enterprise development (Java EE). The Eclipse screenshot at the top of this post shows my working environment for non-JavaEE work. From the screenshot, you will notice that I have OpenEdge running inside the Eclipse environmnent (Database Explorer is at the bottom, and there is an OpenEdge Editor open above it. You can also see an Enterprise Architect model in the right-hand pane, and my Hudson build status is in the left-hand pane. In the Eclipse screenshot at the bottom of this post that shows my working environment for JavaEE work, you will see the Mylyn task list at the bottom on the left, with the Mantis task repository open in the pane on the bottom right and a Mantis task open on the right. All of the tools that I have highlighted are integrated right into my Eclipse IDE in both environments. 
• Visual Studio is used only for development work that doesn't work in Eclipse. So most .NET/Windows-based development is done in Visual Studio. I have both Visual Studio 2008 and 2010 installed. 

All the tools I have discussed so far have plugins for Eclipse and, as the screenshots show, that is the configuration in which I use them.

A couple of other products that I use extensively that are not really integrated into the development environment per se, are:

• Beyond Compare is one of those tools that I just cannot imagine not having. It is a tool for doing advanced 3-way compares of files and it is, without reservation, the best diff tool that I know. It runs on both Windows and Linux, and I use it on both.
• WinZip is another tool that I use so much, I cannot imagine being without it. It is used for creating zip archives, but it can just as easily read and understand Linux tarballs and .jar and .war files.
• Nero is an outstanding tool for burning media, especially CD or DVD burning.

Most of my publishing stuff is done with either WordPress or Drupal. Like most of the other stuff I use that is web-based, these two are both PHP-based solutions. PHP is not a hard language to learn and it is very good at getting pretty sophisticated web apps up and running relatively quickly. WordPress and Drupal both have extension APIs that make it possible to build pretty sophisticated plugins for both in PHP – something I have done reasonably effectively.

Conclusion

Most of the tools I have mentioned above are freeware or open source or really, really cost-effective, and the good thing about them is that they lead you to build much better quality code than would otherwise be the case. If you are not looking at tools like these, I would highly recommend giving them a try.

A number of people have pitched Drupal to me as a competitor to Joomla. One person wrote:

“When we surveyed content management systems …, Joomla was one of the ones we looked at, but on balance Drupal won out. I recently converted my … site to Drupal and brought up two other sites … on the same code base, but with very different appearance and different features on each. I am very impressed.”

I have spent some time evaluating both of these content management systems and while I have chosen to go with Joomla myself, Drupal could probably have done the job I wanted to get done. My initial post was in no way meant to imply that Drupal was not equaly as capable. There were a couple of things that swayed my vote to Joomla.

1. By the time I looked into Drupal, I already understood how Joomla worked. The argument that Drupal is easier to use therefore did not carry the water for me that it would for others and I felt like Joomla’s flexibility was probably better than Drupal’s provided I was willing to make the investment;
2. I am not scared of getting my hands dirty with PHP, MySQL, CSS and XHTML. That means that if I find an obstacle with Joomla, I have the flexibility to get into it with these technologies if I need to; and
3. I like what Joomla has done to address and caution against security issues within Joomla itself. Security is a very real consideration for any web-site and I think the Joomla team understand this. They may not have all the answers but they definitely understand the issues. You should at least look at the Joomla security site and their security forum before you implement a site using Joomla.

In fact, it is the latter point that made me realize I needed to take down my family site while I work on making sure that I have dealt with any potential security threats. It will be back up in a couple of weeks. 

In a discussion on the issue, someone I was talking to made the statement that they did not want a content management system that required a database because of the administration issues associated with it. To me, that argument does not make any sense because if you go with static HTML instead, you still have the complexity of managing the content and determining what the broken links are. With a good content management system, that process can be easily automated. So although you may not have the expense of the database maintenance, you do have the expense of the static HTML management. Most of the maintenance stuff around my 4 Joomla installations is all automated anyway and I simply check the e-mail that I get on a nightly basis to verify that the backup verification process worked. Moreover, there is so much functionality that you simply get for free that I would hate to have to write manually.

Finally, a gentleman by the name of Jeff Pilant pointed me at a web site that is absolutely invaluable on the security side of things. The site calls itself “Common Weakness Enumeration – A Community-Developed Dictionary of Software Weakness Types” and it enumerates 25 of the most dangerous mistakes that developers make that can create serious security threats in their code. This is a highly recommended read. The information is also available in PDF form and although a lot of this information is available in a number of the security books that are already out there, this is a very valuable and concise reminder.