The list of my favorite Eclipse plugins is not that long.

CFEclipse

This is a no-brainer. I do ColdFusion all the time, and I use Eclipse. Of course CFEclipse is on my list.

Subclipse

I am a revision control fanatic, so I have TortoiseSVN on my Windows machines and Subclipse on all Eclipse installations to connect to my Subversion repositories. It is so awesome to have Subversion functionality built into the IDE. In fact, it was this ability, even more so than the CFEclipse plugin, that finally tore me away from Dreamweaver in code view (yuck, did I really use to do that?).

JSEclipse

Originally developed by the guys at Interakt (who were enveloped by Adobe because they were so awesome), this plugin provides awesome JavaScript insight.

Aptana

The IDE itself is nice, but then lacking some features I need (like ColdFusion insight). Aptana is so cool, they even made it into an Eclipse plugin! First, it is a great editor for HTML, JavaScript, and XML. Secondly, it gives you an opportunity to abandon Eclipse’s project-oriented approach and edit files from any context: your local filesystem, an FTP connection, a network share!

XMLBuddy

Great for XML editing, specifically.

There are more plugins I use, but these are the must-haves.

Steve Jobs has revealed that nearly 50% of all Mac sales are from “Switchers”, individuals who did not previously own a Mac. So it isn’t news to hear about someone getting fed up with Windows and having that epiphany that opens their heart to Apple and OS X.

Nevertheless, in her review entitled Uninspiring Vista, Erika Jonietz explains how Windows Vista, as nifty as it is in many ways, was the straw that broke the camel’s back and caused her to appreciate how awesome OS X is and the entire Macintosh experience can be.

A great read for any Mac fan!

For the life of me, I couldn’t figure out why I was unable to checkout from my Subversion repository while I was at work. It worked while I was at home (where my Subversion server is) just a few days ago, and I can view the repository using Subversion’s built-in web page functionality, but if I tried to access the repository from the command-line client or TortoiseSVN, I would get an error message.

C:>svn co http://MyServer/Path/To/Proj/ MyProj
svn: REPORT request failed on ‘/Proj/!svn/vcc/default’
svn: REPORT of ‘/Proj/!svn/vcc/default’: 400 Bad Request (http://MyServer)

Yeah, that’s not cryptic. Fortunately, the solution is simple. Sander Striker explained in a thread REPORT request failed … 400 Bad Request that if you’re behind a proxy at work, and the proxy isn’t configured to support the necessary Subversion calls REPORT, your request will fail.

Like he says in his message, you could request that the proxy be configured to allow the necessary requests, but you could just as well configure your server to work on a different port. Now, I like the fact that my Subversion calls can work on port 80, and I don’t want to change that. So, I configured Apache to have my Subversion sites work on an additional port.

In the following example, let’s use port 81 as the additional port. So my example URL http://MyServer/Path/To/Proj/ would become http://MyServer:81/Path/To/Proj/.

At the following spots in your httpd.conf file, make the one-time additions as marked in bold italics:

Listen 80
Listen 81

And…

NameVirtualHost *:80
NameVirtualHost *:81

And for every virtual host entry you have for a Subversion site (I host a couple different Subversion sites), add *:81 in the VirtualHost header:

< VirtualHost *:80 *:81 >

After restarting Apache, you will now be able to continue to use the URLs you normally use, but anytime you need to checkout from the repository while at work behind a proxy, you can use port 81 to do so successfully.

I don’t mean to add to the blog echo chamber, but I read Simon Horwith’s blog post Online Diagramming and had to share the love on my own blog. I love the concept of diagramming but unfortunately have always done my diagramming with a pencil and paper because available software was either incompatible with my work process or too expensive.

On the other hand, I have managed to make an entirely paperless documentation process, but this naturally never included any visually stimulating diagrams to document project logic or organization.

Welcome to Gliffy. It’s simply a Flash-based app that covers just the basics of diagramming, and like many apps, it is the absence of feature bloat that makes this app so nice. It allows you to print or save your diagrams in several image formats, or it will even host the file for you so that all you have to do is link to the generated image. The process is pleasantly simple.

It even has some simple revision control. And when you make a new revision by saving the document, any links to the hosted file are automatically updated with the latest version. Nice!

Don’t be dissuaded by the pricing page on Gliffy’s website! The pricing is just for hosting the app on your own server (which I think is a worthwhile consideration for any business who is serious about documentation). For us poor folk, the Gliffy service on their website is free of charge.