max.lueb.be

It continues to elude the top brass at Microsoft that the world has changed and Windows 7 manager Steven Sinofsky is doing his best to ensure that the next offering of their desktop operating system will be just as big of a commercial flop as the version that preceded it. In an interview with Ina Fried of CNET’s Crave blog posted yesterday, Sinofsky was asked some very broad questions about the next version of Windows and basically refused to elaborate on anything other than the fact that it will be the successor to Vista. He then goes on to mention that a classic closed-doors development model is not outdated for the production of software.

In the age of Web 2.0 and agile software development this is quite possibly the stupidest thing someone could say, and further proof that Microsoft is on an express train to irrelevance. Rule #1 of business is “give the customer what they want”, and the gurus in Redmond haven’t learned yet that it might be beneficial to ask. Imagine all of the often complained about “features” present in Vista that might have been refined to a level of acceptability or removed if the Windows team had set up something like Dell’s Ideastorm? Windows users would be able to gripe about things that they don’t like, and ask for things that Microsoft committee groupthink hasn’t imagined – so that by the time the product actually ships… people might actually want to buy it! This is underscored by the philosophies of agile development where you are constantly in contact with your customer and making incremental refinements towards exactly what the customer wants.

Also one might wonder what point there is to all the secrecy, when Microsoft holds a defacto monopoly on desktop operating systems – it’s not like IBM is waiting in the wings to unleash OS/3 and steal their feature set, offering it on a line of PC’s that they don’t even make anymore. This point is underscored when the Linux and Mac developers have already branched off in entirely different directions and would probably rather die than admit imitating anything that came from Windows.

Amazon, Google, Dell and countless others have harnessed the wisdom of crowds to refine their business models and it seems that Microsoft thinks that their insulated community knows best, and would rather pretend that its still the 80’s where market will love anything that they send to production. Much of the techworld as of late has become defined by transparency, and one must wonder if the lack of discussion on Windows 7 specifics is because of the lack of innovation, or insecurity regarding their ability to deliver on anything they promise. (WinFS, anyone?) With a release date still years away, there’s still plenty of time for the development team to throw together a webapp that would take less than a day to write, and that will save millions of users all over the planet from Windows ME v2.0. I wouldn’t hold your breath though.

The good folks at O’Reilly were kind enough to send me a copy of Beautiful Code to review. I really enjoyed this book and highly recommend it to anyone who spends any significant amount of time in front of a screen cutting code. The following is my review on what I’m sure is a classic in the making:

A frequent topic of discussion among those in any technical field is for a short list of essential books that anyone worth their salt has read. With regards to software engineering, two classics quickly come to mind: Code Complete, and Design Patterns, as well as a recent publication joining the ranks of these epics, Beautiful Code by O’Reilly Media.

What makes Beautiful Code stand apart from the rest, is that it’s format is so unconventional when compared to most other programming texts. The book is comprised of 33 Chapters, each written by a different author about a particular bit of code they had written and thought to be particularly eloquent. The best way to explain why this book is so wonderful is to make an analogy about the differences between learning something via a lecture as opposed to a private lesson. Most instructional books will take the lecture approach, where the author shows you one correct way to solve a problem, or complete a certain task and the reader must then digest that as best as possible. Beautiful Code is more like a private lesson in which the author of each chapter is giving the reader personalized attention by explaining their thought processes, how they arrived at each step, and occasionally showing some dead ends that didn’t work out. Now consider that these private lessons are being given by such legendary names as Brian Kernighan, Charles Petzold, and Yukihiro Matsumoto – and it becomes obvious why this is a must-have addition to any serious software engineer’s bookshelf. Some particularly memorable sections include Karl Fogel’s discussion on the origins and implementation of the Subversion Delta Editor and the look inside Google’s MapReduce technology by Jeffrey Dean and Sanjay Ghemawat.

As stated earlier, one of the best strengths of this book is that it is language neutral. In each chapter, as the author is speaking from experience on a particular project, rather than writing a chapter for a hypothetical “Better Programming in Language XYZ”, you will see code snippets in C#, MSIL, Python, Ruby, and several other languages (There’s even one chapter with Emacs Lisp!). This is important because the insight gained from this book will not be diluted from one language falling out of favor or into obsolescence, and allows for the possibility of this title being just as valuable ten years from now.

Many books will teach you how to solve a problem, but rare are those to teach you how to think. Beautiful Code is one of those select few, and will keep you coming back from project to project to consult its veteran sages of computer science. A worthy edition to any serious programmer’s library, and hopefully a second volume is not far off.

A while ago, I wrote a post about how I think that programming is really difficult to get into these days without a ton of effort on the learner’s part due to varying factors such as language complexity and operating system api’s. I then proceeded to discuss a product by MIT Media Labs called Scratch that was designed to teach children programming by addressing these issues. In case you don’t remember, I wasn’t too fond of Scratch.

Last night at the Chicago Ruby Users Group, there was a presentation on Shoes, which is another project in this vein that uses Ruby as its underlying language. Shoes addresses all of the complaints I had with Scratch, and lets you write code instead of relying on a mouse/GUI driven interface. Writing a program in Shoes is very straightforward, and you can do a lot of neat stuff in a very few, simple, straightforward lines of code. I was pretty impressed. This is exactly the type of thing we need in a world that is devoid of QBasic.

Here’s a screenshot of a sample program called follow.rb that draws circles depending on the position of the mouse cursor: (the sourcecode is in the terminal to the right of the demo)

This screenshot doesn’t really do it justice though – because Shoes is built on top of Cairo and Pango, the demo runs very smoothly and doesn’t reek of jittery animation like so many other sandbox programming environs.

While it’s definitely not a finished product ( 1 or 2 of the demos segfaulted on me due to some C code in the Shoes app) – it runs on Windows, OS X   AND   Linux. I had no problems checking out the source from subversion and building Shoes on my Ubuntu 7.04 laptop. Shoes is a huge step in the right direction with regards to addressing the issue of getting kids into programming by making it less of an impossible task. I look forward to watching this project develop, and really hope that it catches on.

After overcoming the FS key bug a few months ago, my latest efforts have been on increasing performance while running Linux on my Sony Vaio FS760/W .

Strangely, when my laptop was plugged into the wall via the AC adapter – Gnome System Monitor would indicate that my CPU usage (while idle) hovered around 20% utilization, and would erratically spike up past 60% for seemingly no reason. Performance was laggy, but unplugging the ac adapter would bring everything back to a normal state.

A really simple test to try if you are experiencing similar trouble on your Vaio running Linux is to open up a terminal and hold down a key. Whatever letter you are holding down will slowly creep across the terminal – now unplug the power while still holding down the key. You should see things smooth out drastically.

Doing some additional research around the Ubuntu Linux bugtracker – I realized that this may not be a Vaio compatibility problem as much as it is a bug with Centrino chipsets in the Ubuntu Generic kernel. As an experiment I installed the i386 architecture kernel, and the difference was night and day. While idle, cpu usage in Gnome is less than 2% and the system is running smoother than I ever remember it being. Shortly after, I removed all references to the generic kernel from my system and haven’t looked back.

Making this change did prompt me to redo my graphics and FS key settings, as the functionality of both is directly linked to kernel modules. My Geforce 6250GO was brought back online via the Envy script (which is awesome, and incredibly simple if you haven’t tried it) and I brought my FS key support back via my feisty-fsfn script previously published. However, changing the architecture to i386 caused my original script as written to fail due to a typo. I’ve fixed this and uploaded a correct copy.

Please let me know if you have any additional insight or experiences with this issue regarding Linux on Vaio laptops!

Recently read Soul of a New Machine which is a great read for any engineer, especially a Computer Engineer as the plot revolves around Data General’s battle to create a 16/32 bit hybrid computer in the late seventies.

One passage in particular stuck out to me, regarding a team member talking about their college experience:

It was an IBM Machine, archaic now but gaudy then. The university owned it, in effect, and it lay inside a room that none but the machine’s professional caretakers could enter during the day. But Alsing found that a student could just walk into that room at night and play with the computer. Alsing didn’t drink much and he never took any other drugs. “I was a midnight programmer,” he confessed…
…About ten other young undergraduates regularly attended these sessions of midnight programming. “It was a whole subculture. It’s been popularized now, but it was a secret cult in my days,” said Alsing. “The game of programming – and it is a game – was so fascinating. We’d stay up all night and experience it. It really is like a drug, I think.” A few of his fellow midnight programmers began to ignore their girlfriends and eventually lost them for the sake of playing with the machine all night. Some started sleeping days and missed all of their classes, thereby ruining their grades. Alsing and a few others flunked out of school.

As I read this – it was all too eerie and familiar. The allure of technology. When I first started undergrad, we didn’t have a computer in some obscure closet – but we did form our own nerd subcultures around certain projects and places. For the Computer Science students at the University of Arizona it was the Harvill Lab then later after Harvill was closed, the Gould-Simpson lab aka “GS228″ aka “The Human Fishtank”. The Human Fishtank was room that had been designed for big iron when the building was designed – air-conditioning coming out of the floors, and plexiglass walls for people to marvel at the latest room-filling mainframe industry had produced. Later when big iron fell out of style, they crammed the room full of cheap pcs and desks – and it was guaranteed that given any day of the year, any time of day (thanks to the 24 hour access), you could go in there, cut some code and find a person or two to talk shop with.

Or if you went over to the Aerospace and Mechanical Engineering building after 5pm – there was an entirely different, yet similar subculture that came out of the woodwork after dark. The SAE kids would work all night on their Formula car, occasionally sleeping under tables or in their 3rd floor office. The asian grad students had apparently evolved to a state in which they required no sleep and would be hard at work advancing the state of the art in fluids or rocket design. There wasn’t more than a handful of rooms in the 9 floor building that were uninhabited or let alone had the lights off. I would generally be in the Aerial Robotics lab working on code for Machine Vision or AI for our UAV, or sometimes on the other side of the building actually wrenching on an aircraft with some fellow students. On a slight tangent, I think a defining moment in my life was the night I turned 21. Popular tradition in college, is on this special occasion for your friends to take you to a bar for the first time to get you monumentally drunk. I spent my last night being 20 in a laboratory prepping a UAV for a maiden flight that ended in a spectacular crash.

In one way or another, like a drug – each one of us Midnight Engineers paid for our addiction in one way or another. Just like the book says, some lost their grades, some also flunked out of school. Myself, I lost my girlfriend – this caused me in the months that followed to look deeply into what else I had lost in this pursuit. I was no longer playing music, I spent most of my time alone debugging programs and hardware, I had lost touch with many of the people who cared about me, I no longer had a girlfriend that loved me.

What was the point?
Was I an addict?
This realization made these engineering pursuits less and less gratifying, until I lacked all interest and figured that some serious reevaluation of my current life was in order. Within a week, I had dropped out of school and was packing my belongings to head back to the Midwest to sort my life out.

That was about a year and a half ago, and I think that in the time I’ve learned a lot about life. Dropping out of college was probably the best thing that ever happened to me.