Choosing an operating system

It's the first time I had to choose between 3 operating system for new development machine! I would gladly choose OSX (no brainer), but I don't have Mac :). That's basically narrows down the choice to the Linux and Windows. I've got latest Fedora 5 and Vista Beta 2. I have been using Linux exclusively for development for something like 10 years now. Lately however I found myself editing documents more often then developing code. I'm using XP on my laptop mostly because this is a convenient choice for "operating" Outlook and the Microsoft Office suite. A friend of mine bite the bullet and got the Apple laptop. I would probably get it too if I could get it for the office. At the time it doesn't seems to be the option so the choice then boils down to the two mentioned above.

Windows Vista Beta 2.

For two days I was trying to download the Vista DVD iso image from MS site. The site was on and off for couple of days coping with demand. Once I was able to download 3+ Gigs and then download had died. I had to start again next day only after burning corrupted image and finding out at the office that downloaded image was not complete. Wasting so much time and bandwidth is really unfortunate and I have hoped it would be worth the wait and time... Tip to Microsoft - post the torrent file next time - it will save you hundred of thousands in bandwidth and you wont have to take your site down.

Installation took about 3 hours to complete with several reboots etc. Sound card was not detected right away, but lately it did miraculously started to work. I sort of liked the look and feel of the operating system, but it seems to be very slow to respond. My system had 1 gig of ram and there seems to be no swapping, but the system scratching the disk all the time and also appears to be slow to respond. The security dialog that pops up all the time is really annoying and I'm sure not improving security or awareness of the risks. You learn automatically say yes or allow. How the hell I supposed to know whether or not it's OK for certain executable do certain things when I'm not even downloading anything.

Linux:

Installing Fedora Core 3 was a breeze - you can download the DVD image using bit torrent. Unity image contains all the patches up to date. Very cool idea and thanks a million to the unity team. Get Unity torrents here . If you rather prefer the official release you can get it from here.

Installation will take only half an hour and with a few very clear and "right to the point" directions you can get everything else you''ll need which is not on the DVD, you will get it up and running in no time.

In an hour you will be all set with the fantastic operating system! Vista Beta 2 sucks big time if you ask me. The new interface is the only good thing to mention, but it doesn't even come close to OSX. The only other thing that I've liked is the built-in speach recongnition.

Seven Habits of Highly Successful Software Architects

Interesting quote:

The ideal architect should be a person of letters, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations. —From Vitruvius, circa 25 BC

From Software Architect Bootcamp, Second Edition by Raphael Malveau, Thomas J. Mowbray, - Ph.D.:

Keep it simple. When communicating various architectural concepts or software mechanisms to team members, resist the temptation to provide a complete and detailed explanation of how things work or a detailed comparison against all the alternatives in front of a group. Instead, the software architect should say enough to communicate the idea at a level that is high enough to be generalizable but just low enough to be understood in principle, so that the individual team members can do their own homework or meet separately with the architect to address their specific concerns.

Let others defend the architecture. It is always preferable to have someone else respond to a technical concern rather than have the software architect appear to be the sole source of knowledge. It reinforces teamwork, provides the architect with insights from people who agree as well as disagree, and is a key aspect in mentoring others, among other benefits.

Act, don't argue. Arguing technical points in a meeting wastes time, hurts feelings, and seldom if ever fully resolves any technical issues. When such an argument starts, the software architect must act—by assigning people to get or verify the relevant information, setting up a meeting specifically for resolving the debated topic, or, if time requires an immediate course of action, laying down the law by explaining why the time constraints force an end to the matter.

Keep an eye on the prize. Software architects must always be aware of the end goal. It is easy to be distracted by tasks and smaller technical issues, and frequently other team members will succumb to one form of tunnel vision or the other. However, it is vital that the architect always be focused on the overall vision of the system and relate every task or technology to how it contributes to the end goal.

Be willing to change, but never too much at once. After the initial bootstrapping of a software development effort, the architect should be wary of implementing too many process improvements all at once because there is a risk of compromising the effective parts of the process.

Learn where to stop. Software architects must resist the temptation to go into too many details and to micromanage design decisions. For example, it would typically be enough to specify that caching is required in client applications and that the caching code should be reused throughout the application. However, detailing the specific caching algorithm used or writing the caching pseudocode is probably overkill. Learning to trust other team members to provide design and implementation details and letting them ask for help is essential.

Know how to follow. No matter who is in charge, software architects should avoid publicly confronting others on major design issues. This can be accomplished by knowing ahead of time what is going to be discussed and the reasons for the various decisions. This is a key aspect to developing a focused, high-performance team.

JavaOne sessions are available!

The wait is over, all the slides and hands-on sessions are finally posted on-line.

Select session

Download all sessions in bundles

Hands-On Labs