Chris Johnston

I blogged the other day about the problems I encountered trying to put NetBeans project directories under version control. One problem was that NetBeans uses absolute paths to determine project dependencies and AccuRev, using exlusive locking, makes all files read only. I tried to solve these problems by setting up all project dependencies ahead of time. Apparently, NetBeans needs the ability to modify its project files, regardless of whether it actually modifies those files. So, back to square one.

In the end, the only solution was to completely separate out the Ant build scripts from the NetBeans project folders. This meant recreating build scripts across 7 projects. Fun stuff. Unfortunately, this lost me a day. In the end though the result was a much better project base from which to code and the complete separation of IDE from build script. This means that if developers want to use Eclipse, JEdit, IDEA, JBuilder, or NetBeans to work on the project, they can.

I definitely think this is the better way to go. I am not sure that I feel comfortable dictating what IDE developers should be using. I definitely think that the your build process should be completely independent of the app you use to create your software. This has other benefits as well. We also have build scripts that are now a lot easier to understand and a lot easier to modify and maintain. Yes, a lot of the magic that NetBeans provides is gone, but at least we understand every aspect of the build process and can modify or change any part of it. The NetBeans build scripts have to be among some of the most confusing scripts I have ever seen (although that may not be saying too much).

We also have a process now that is guaranteed to work outside of NetBeans. We can now take our code base and put it under continous integration using CruiseControl without any problems. And if something goes wrong, we can easily and quickly fix the problem.

In the end I agree with the statement that putting the NetBeans project folders under version control is a bad thing. Yes it takes a little longer to get a new developer up and running, but on the other hand the advantages out weigh that one negative.

Asa Dotzler, of firefox fame, has written an article on why linux is not ready for the desktop. In the article, he touches on four points that, in his opinion, are keeping Linux from being adopted by the “Regular People”.

So what’s wrong with Linux that makes it not ready for the desktop. I’ve tried KDE and Gnome desktops but my latest is FC4 so my criticism is focused on that (and Gnome) but I think KDE distros suffer just as bad if not worse. The issues fall into four basic categories, migration, stability, simplicity, and comfort. These issues each cover both technical capability shortcomings as well as usability failings.

I find myself agreeing with him on every single one of his points. In addition, it is nice that he is able to back each point up using his experiences of working on Firefox. At each point he shows why Firefox has been accepted by 65 million downloads where other products have failed (i.e., Mozilla).

Regular People may be willing to take a look at Linux, but as long as all of their data and settings still lives in Windows, they’re not going to stay very long — no matter how appealing it might be. We learned this lesson in the Mozilla world. It wasn’t until we implemented a very capable migration system in Firefox, which carried over the user’s IE favorites, cookies, history, passwords, etc. that Regular People started moving over in serious numbers

People do not adjust to things that are new for them. Before my Dad bought MS Office for himself, I gave him a copy of OpenOffice.org 1.0 to try out. He rejected it and spent the $700 CAD it took to buy Office. Why? Because after using Word for 10+ years, he could not adjust to something different. There were too many things that he had to relearn to use OOo. This is the same with Linux.

One task that I have had to do for work is to come up with the directory structure for our new software. In doing this, I had two goals in mind:

1. Keep the opening of projects as simple as possible in NetBeans
2. Make sure that however the projects got into NetBeans, they could still use the full power that the IDE offers. This means making sure that I kept the full J2EE capabilities built into NetBeans.

In order to do this, I started with a nice little project structure in NetBeans. Then I made sure that the project structure compiled on my computer and someone else’s computer. So far so good.

For an SCM product we use the world’s least known application—AccuRev. In addition, we are using Exclusive Locking on our project’s depot. This means that only one developer can edit a file at a time. And then I checked in the file structure, project structure and all the NetBeans project files.

Apparently this is not something one should do (although I am still a little confused as to why).

Anyway, when trying to setup project dependencies in NetBeans, it requires write access to the private.properties file. Something that can not be done when using exclusive locking.

So, in the end, I had to go in to the project, setup all the dependencies and then go in and edit each project’s private.properties file to use relative paths instead of absolute ones. See, that was the problem all along. NetBeans uses absolute paths when referencing other projects. Why it does not use relative paths is beyond me.

The amazing thing is that this little change worked. I made all the changes and NetBeans didn’t complain once. Very cool.

The more I work with NetBeans, the more I like it.

It is amazing how many of these comes from digg.com each day. Anyway, here is what I liked today:

TTW (”Through the Web”) WYSIWYG Web Editors - The List
This is a list of probably all open and closed source WYSIWYG style html editors. These are the editors that can be embedded into a webpage and CMS to allow clients to edit pages.

Beginner’s Guide to Podcast Creation
Want to get into Podcasting, then check out this excellent introductory article on the subject. it contains everything a beginners needs to know to launch their own podcast.

Modafinil - the Scary Time-Shifting Drug
This is just scary. It is a drug that allows you to stay up for 40 hours straight with little to no side effects except having to catch up on a lot of sleep.

Pocket PC Vs Palm: What to Choose
This is an interesting, if not a little biased, comparison between Palm and Pocket PC. Having done my own comparison, I tend to agree that currently Pocket PC devices lead the way.

Default Password List
This is a list of default password for things like routers, firewalls, etc.

Chainsaw v2
This is a very cool looking Java GUI app that displays Log4j files in a manageable way.

Really Slick Screensavers
OpenGL screensavers for Windows that are similar to the ones found on Linux and OS X.

Create a Simple IoC Container Using Annotations
A tutorial on creating a simple Inversion of Control container using Java 5 annotations.

If you are thinking of trying Ruby on Rails, then check out the New Rails movie. This is a 15 minute demonstration on how to “build a blog engine … with Ruby on Rails”.

THE.SCENE is an online video show that follows the exploits of a group of movie pirates as they practise their craft. I have not watched any of the episodes yet, but everything I have heard about it is good.

Update: I have now watched the first episode and I’m hooked. The show consists of looking at someones computer screen with video showing in the upper left corner showing the computer user—and main character. You definitely have to be a computer geek/hacker to get into these. However, they have a definite story line and the end leaves you wanting to view the next installment.