max.lueb.be

Thrift is a efficient framework for cross-language serialization and RPC that recently became an Apache Incubator project. It’s definately a cool project to check out if you are building a high traffic web application or are writing distributed computing code. Installing the framework on OS X isn’t currently totally straightforward, provided below is a guide to get Thrift built on OS X Leopard.

First, gather required sources – Thrift depends on the Boost and libevent libraries, grab the latest revisions of each and then download the latest Thrift snapshot.

Build Boost first:

cd [boost root]
./configure
sudo make install

This takes a while, go make a cup of coffee – and when it finishes build libevent, which takes much less time:

cd [libevent root]
./configure
make
sudo make install

At this point is where most Thrift builds will run into trouble, as the pkg.m4 file required by autoconf in upcoming steps does not get correctly found.The following error will be encountered when trying to configure the package:

./configure: line 21183: syntax error near
unexpected token `MONO,'
./configure: line 21183: `  PKG_CHECK_MODULES(MONO, mono >= 1.2.6,
have_mono=yes, have_mono=no)'

The official faq says that in order to get this file, one should install macports, and then use it to install pkg-config – but as macports is a colossal pain in the ass, we’ll do something else.  The pkg.m4 file is also installed when X11 is installed off the OS install disc, and since X11 is something you can’t live without if you’re working on or with mainstream open source software, that is the route we will take. After installing X11 (not shown here, because it just consists of running the installer package on the OS X disc), do the following to get pkg.m4 where it needs to be:

cd [thrift root]
cp /usr/X11/share/aclocal/pkg.m4 aclocal/

After doing this, Thrift can build without issues, which will take some time, but not nearly as long as Boost did:

./bootstrap.sh
./configure
make
sudo make install

Hope this helps anyone trying to write Thrift code on OS X!

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!