The Grubbsian

Folks, I think the time is nearing…may it come quickly.  I just loaded up IE8 beta 2 in a VM and I just realized that by the time IE8 is released, IE6 will be 8 years old and two whole versions behind.  The thought of trying to write rich-Internet applications for a browser that was released in mid-2001 is becoming more and more frightening.  

An interesting experiment going on over at 37 Signals: http://www.37signals.com/svn/posts/966-urgency-is-poisonous.  I think they might be on to something.  I know that my current project would have benefited greatly from this kind of freedom from urgency.  I can attest first hand that extreme urgency does not elicit the best code or the best mental attitudes from a team.

So I've been looking at some new languages recently, particularly dynamic languages like Ruby and Python.  One of the first things I noticed about their syntax was the lack of access modifiers.  I suppose the assumption could be made that since C# is type-enforced that it lends itself to access modifiers but I also wonder if maybe it's just a case of programmer mistrust.

If I'm writing an API that's going to be consumed by other developers, am I really so paranoid that I need to lock things away into isolated boxes to prevent misuse?  No, I think I fairly well trust consumers of my code to understand my code prior to using it or do so at thier own peril.

I can see the argument being made that it makes the API cleaner if implementation code is hidden from the consumer.  I don't disagree, but I think that problem is better solved by encapsulating implementation logic into a lower level class.  This has the added benefit of making the implementation available for anyone that wants to take a look under the covers, but still providing a clean API layer.

So what am I really proposing here?  Should we just mark everything public everywhere?  No, I don't think that's really what I'm saying.  What I am saying, is that it's interesting that a number of dynamic languages have decided to trust thier developers more than C# and I just think that's interesting.

I recently moved over to a MacBook Pro as my primary laptop and development machine.  With the recent advances in virtualization on that platform (namely VMware Fusion) it's become possible to run both Mac OS X and Windows (XP/Vista/Server) in a VM quite happily.  So when my new laptop arrived the first thing I did after watching the cool intro video, was install VMware Fusion Beta 2. 

This newest version adds some exciting features and improved stability so its a good choice if you're moving to Mac.  Despite how good Fusion is, there are some things you can do to tweak Windows to play a little nicer in a virtual environment.  I'm using Windows Vista but these tips will apply to Windows XP as well.

5 Ways to Improve Windows Performance in VMWare Fusion

1. Turn off all non-essential services.  There are a lot of services that Windows enables by default a number of which are totally unnecessary for day-to-day use.  By going through your running services list (run: services.msc) you can trim quite a bit of memory use.
2. Ditch the screen saver.  Because you're running in a VM in an OS that already has a screen saver, you can turn the Windows one off.  If it kicks in while your not paying attention it will start to eat up additional resources while you're trying to do other Mac OS work.
3. Do you really need 3D acceleration?  Chances are you're not going to be playing games in the VM so you can safely turn off the 3D acceleration option in VMware preferences.  This may not actually eat up resources in the VM but it will add some overhead to the VMware container.
4. Areo is pretty but slow.  Just resort to the Windows Classic or Windows Vista Basic theme and just deal with it.  You should get your "Ooh that's pretty" vibe from Mac OS X anyway.
5. Turn off system protection.  Since you'll be backing up your Mac OS X machine (and you will be backing up right?) you don't need the added protection of using system restore on the guest machine and it just eats up virtual hard-disk cycles.

So there you have it, a few quick ways to speed up the performance of Windows on Mac…friends at last.

The jury is still out on Google Chrome…most likely since no one has really been able to get their hands on it yet.  The browser is set to ship in beta sometime today.  But even before its release the very idea of a new browser begs the question… "Do we need another browser?"

Like most philosophical questions of this depth (mind you not very deep at all) the answer is varied.  Some say, "Yes, more browsers equals more choice equals more competition equals better features, blah blah balh."  Others say, "Are you crazy?  I just got over IE6!"  In my opinion, it’s not really about the browser it’s about the engines. 

I don’t care if the title bar of my browser says Microsoft, is a drab 1940′s post-ware gray (ala Safari), or has a little curled up fox gently engulfing the globe.  What I do care about is how the thing works.  As a developer, I crave consistency.  When I write a piece of code I want it to function precisely as I expect it to, and I want it to do that in every environment that calls it.  In this vein the nice thing about Google Chrome is that it’s built with open source pieces…it’s the Frankenstein of browsers really.  It has WebKit’s rendering engine, parts of the plug-in architecture are ripped off from FireFox, and I suspect that a its new JavaScript engine is built on concepts from a whole realm of different open source projects.

So, we’ll have to wait and see what comes of it.  If it runs Firebug, and is really as fast as they say, then it’ll probably be a good browser for developers, if not it will just be another "Oh that’s kinda cool", and then we’ll all go back to FireFox.