The Noisy Desktop

Desktops as of late have been getting noisier and noisier. From cartoonish callouts (Windows and Gnome) to sliding dialogs (KDE), the Desktop as of late seems bound and determined to tell us things. I really wish it would just shut up. We have Windows telling us (and, especially in Vista, selling us) everything under the sun. KDE is telling me things about its Phonon backends. Who cares? Unlike the typical user (who is supposed to be the audience in usability), I actually know what Phonon is and what its backens are–and I STILL DON’T CARE! How much less would someone who doesn’t know? The Desktop needs to be a little less interesting. Appealing and functional, yes, but it should not be trying to draw attention to itself. It should fade softly into the background unless I ask it for something. It should always be supporting, but never running the show.

The Desktop should be seen and never heard.

Regarding “Dreaming in Code”

I just finished reading “Dreaming in code” by Scott Rosenberg and I must say that it was an interesting read. Rosenberg writes as one who is clearly technically savvy, in the sense that he can get around his computer proficiently, but is a clear outsider to the field of software engineering. This externalness is actually refreshing, giving an interesting perspective as an outsider looking in. This is interesting precisely because it is rare: most of those outside of programming would rather look away than in. I get the feeling most would rather swim in raw sewage than in code. The book follows the journey of Mitch Kapor and his team in the early days of the Open Source Applications Foundation (OSAF) and the creation of its first application, Chandler. Along the way, Rosenberg makes user-friendly detours into programming history and concepts.

The amateurism showed through in a few parts. For example, there was Rosenberg’s description of object oriented programming. The description sounded like the author had a Java programmer whispering in one ear and a Smalltalk-school professor whispering in the other. The result is some text that isn’t entirely wrong, but doesn’t describe object oriented programming, either as it is in theory (Smalltalk and academia) or as it is in practice (Java). Ironically, Rosenberg should have picked up on this as he later quotes Alan Kay, the father of object oriented programming as saying “Actually I made up the term “object-oriented”, and I can tell you I did not have C++ in mind.” That should have given him the clue that he needed to probe a little deeper.

Of particular interest were the chronic problems that Chandler had while getting up and running. The usual problems that software encounters were discussed. Things like an uncertain design, personnel changes, technology changes, the uncertainty of estimates, the fact that software is not infinitely malleable were all addressed as general problems for software slippage and even for some of Chandler’s problems. Interestingly, I thought that the most important problem with Chandler’s development (as portrayed in the book, which is my only real source on the matter) was the dream man himself: Mitch Kapor.

It seems like an odd charge to bring, given some of Kapor’s other successes, from the design of Lotus 1-2-3 to the chairing of the Mozilla board. Kapor seems like the kind of man who would know his way about software development. The problem seemed to lie in his style of leadership or, sometimes, his lack thereof. For example, there are several large sections show technical debates in which Kapor himself took a side role and basically waited to see what consensus would arise. Indeed, Kapor himself lauds the project’s democratic style. Somehow, we programmers have an almost endless capacity for debate, even pointless debate. Most leaders or managers are too heavy handed, not letting good people get work done, but bogging them down in red tape and superfluous micromanagement. Kapor was too light handed. He did not step in to push the project along, but let it languish.

Another problem you see (which may have even been acknowledged by one of the departed developers) was that during the timeframe given, Chandler refused to be either a Cathedral or a Bazaar. The book discusses Eric Raymond’s famous essay and Kapor’s interest in it. However, when OSAF began work on Chandler, the code was released, but the real work, especially design work, was taking place in a meeting room in California. Even after a wiki was added, the book mentions one of the team members entering notes from the meeting into the wiki. The problem with doing this is that it takes the weaknesses of both approaches: you neither have the protective wall of the Cathedral nor the open marketplace of the Bazaar.

Ideally, Kapor would not have hired anyone up front, but would have sat down with Python and wxWidgets (the selected technologies) and banged out a simple version himself. Then, released it on the web in true open source mode. Then, if he felt it necessary to move the vision along, hired developers. The ironic thing is that, at the beginning, the project received a lot of Slashdot attention. It is entirely possible that, had Kapor taken this route, he could have had his dream and perhaps without hiring anyone or taking out a bunch of space.

Overall, it was an interesting read there. Reading the history of a software project is kind of like reading folklore from the land of Geekdom. It was also of interest to see how the whole thing looked when watched and researched by an outsider to the field.

Grokking IIF

Sometimes, the best way to integrate to applications is to give up on automatic interfacing and just dump out some common data that can be imported/exported as needed. Recently, an application I was working on reached this point with the QuickBooks API. So, I implemented the relevant exports from the primary application to IIF (Intuit Import Format) and I thought I would go ahead and post some notes on using it. IIF is a tab (hard tabs, not spaces) delimited format that is, in its evil heart, a hybrid approach between EDI and CSV.

An IIF file basically comes down to two components, repeated endlessly (well, almost; the QuickBooks KB has some notes on the process and gives the transaction limit as being at 10,000):

  1. A specification section (which, as its ad-hoc name implies, specifies the format to be used)
  2. A data section

In the specification section, we basically tell the importer what format is going to be used for the transaction. It is really just a list of fields and in which order they will occur. The data section, on the other hand, follows the template specified by the specification section, providing data in the order in which it was specified. So, to take apart one of the examples:

TRNS        BILL    7/16/98    Accounts Payable    Bayshore Water        -59.25            N    N        8/15/98    Net 30
SPL        BILL    7/16/98    Utilities:Water            59.25            N        NOTHING    0/0/0

For emphasis sake: this is a hard tab delimited format, so the spacing shown by this page is a little deceptive. Using C-style escapes (\t for tab, in case you were wondering), the file looks like:

TRNS\t\tBILL\t7/16/98\tAccounts Payable\tBayshore Water\t\t-59.25\t\t\tN\tN\t\t8/15/98\tNet 30

Which is a lot denser, but also a lot more precise. Any line beginning with an exclamation point (!) is one of the specification lines.


So, this line is specifying that the data to be imported is a transaction (which includes bills, invoices, and several other items), which has the following fields in order: transaction ID (I’ve never used this in my imports; your mileage may vary, though), transaction type (BILL in the case above), date (which will be the bill date here; in other places it has slightly different meanings; check the docs), account (AP), name (name of the entity sending the bill; more on this in a moment), class, the total amount of the bill, document number (reference number, for a bill), memo, whether or not it has cleared, whether or not this bill needs to be printed, an address, due date and terms.

A note on names: these names must match exactly what QuickBooks has on file. If it does not, the IIF importer will create the value automatically. So, if you want to import a bill from “Somecorp”, but type it in “Somecorp, Ltd.” a new vendor “Somecorp, Ltd.” will be created with the bill. This applies to all name-based items in the file, making the IIF import a little tricky and fairly dangerous. Many entities in QuickBooks are hierarchichal, so if you want, for example, a class of “bar” which is a subclass of “foo”, you would specify it as “foo:bar”. Excluding quotation marks, with the colon, and no spaces between the colon and either “foo” or “bar”.

The source listed below links a zip file with information on the IIF format. It is sparse, but enough to get going. It has some example IIF files (including the one dissected above) and some HTML files specifying which fields are available and/or required for each type of data to import. It is also important to realize that IIF imports are officially deprecated, so be aware of this when writing your own importer/exporter.


Life is Good!

I have full suspend/resume working, with binary nvidia drivers, and the ath5k driver for my wireless! Running on Fedora 11 Rawhide (11.90, according to my new boot screens). My /etc/pm/config.d/suspend_modules includes a line unloading ath5k. Other than that, it all works.

So, to summarize: I have an HP/Compaq Presario F756NR laptop, with an Atheros wireless card, an nvidia GeForce 7-series card (I forget the details) with an AMD Turion 64 X2 processor, with 2GB RAM. (Why do I have the feeling that, someday, I will read this article and feel like a dinosaur?)

To get it all running beautifully, I:

* Installed Fedora 11.
* Added hpet=disable and pci=nomsi to the kernel options
* Enabled the Rawhide repo
* Updated everything
* Added ath5k to the list of modules to be unloaded on suspend and reload on resume.

And it works. Wireless. Accelerated graphics. Power management. WHOOHOOOO!!!

ADDENDUM: Once I updated the kernel to 2.6.30, the pci=nomsi parameter had to be removed.

Gentoo is calling…

I bit again. Despite warning myself otherwise, I did it again. I installed Fedora 11. Hibernation works most of the time, suspend works, but the computer fails to wake up. This happens with either the lousy nouveau driver (hey, how about using the manufacturer’s drivers by default? or at least, making them easy to setup ala Ubuntu?) or the binary nvidia one. I’ve trolled the forums. Plenty of people with HP/Compaq machines report the same issue and many recommend cures–none of which has had the slightest effect for me. I could downgrade to Ubuntu 8.04–again, but I kind of like having slightly newer userland apps.

But Gentoo sounds alluring. No, I don’t really have the time to compile my system from scratch, but the nice thing about Gentoo was that I always figured stuff out. I didn’t have this junk to put up with. If something broke, I got my hands dirty and fixed it. With Fedora and Ubuntu, that is a great deal harder. The tools want to make it easy, not transparent.

I probably shouldn’t, but it sounds good anyway. I am once again thinking that I might like a Mac after all…

Building Chrome on Linux

After blogging about Chrome yesterday, I just read that Chrome will arrive for Linux soon. Google has posted a development version of Chrome for both Linux and Mac (

Like any good hacker, after reading this piece of news, I moseyed on down to the dev site and pulled the latest and greatest code. It is a little odd (but not really surprising) that Google has its own set of wrapper scripts (depot_tools) that you need to use in order to get the code. Yeah, they have other purposes (code review, they say; I haven’t checked it out), but it still seems odd to instruct people to:

$ gclient config
$ gclient sync

instead of

svn co chromium

The latter is familiar. The former is not. But I digress.

It took a while to pull down the full code base the tarball for which weighs in at an impressive 713MBm including platform specific code for all three platforms, sounds, textures, third party code, and tests. I built under Fedora 11 and had little difficulty. Here was the process I used (streamlined from the bumbling experimental style in which it was worked out):

  • Installed prerequisites as per the wiki article. The only way in which I differed from their instructions, was that I removed all of the architecture extensions from the arguments. So, glib2-devel.i386 became glib2-devel. This was because my computer is running as an i586 architecture with the repos set up to go to the architecture. Dropping the extensions installed the proper packages.
  • Installed depot_tools. I just downloaded it to a location in my home directory, unpacked, and added it to the path.
  • Installed gyp. Google is in the process of migrating  the build over to gyp.
  • Downloaded and unpacked the source tarball.
  • Navigated to the chromium/src/build directory
  • Ran gyp All.gyp
  • Ran hammer

This built a binary under chromium/src/sconsbuild/Debug. First impressions:

In all fairness, this is an incomplete developmental release. So Google protests about a thousand times before you get it up and running. Flash doesn’t work. Don’t know if Java works. Overall, things seem to work fairly well though. The most obvious, annoying thing is having the whole window flash green when opening up a new tab. It is nice to have it to play with, though. Watching pages and pages of compiler messages flow through my terminal made me vaguely nostalgic for Gentoo, where every single application had to be installed in like manner.

Fun project.

Some thoughts on Google Chrome

I have been, once again, doing some more work in Windows Vista than usual as of late and so I took the opportunity to set up and use Google Chrome for most of my online activities. First, I would like to list my reservations, so that this does not turn into too much of a schmooze fest. What I do not like about Chrome:

  • It is from Google. I love Google’s products, which almost irks me at times, because I do not like the idea of a Google monopoly or lock-in any better than I do a Microsoft one. Microsoft was not always the evil empire that it is now and we may assume that, given enough time, Google will become truly evil.
  • Privacy concerns. To some extent, this is related to the above, but there was actually an interesting bru-haha about this browser in particular. Please see the Ars Technica article regarding the Chrome Eula controversy. Interestingly, a friend and I noticed this and held off using the browser earlier. This is all on top of the history and key stroke tie-ins that Google has.
  • It is not cross platform. One thing you have got to love about Firefox is that it is more or less the same on any operating system. You can count on it being present and on the vast majority of the add-ons working, as well. Chrome, however, is Windows only for the time being. No, Wine does not count.

Now, for what I like. The good in Chrome comes in the UI, which is not surprising given that they used an existing rendering engine (I would have done the same; a new rendering kit is a great way of spending a lot of time and effort on creating a toolkit that, if it is of any use, is also incompatible with the rest of the world).

  • All of Chrome has a smooth, easy appearance which is very pleasant on the eyes.
  • Chrome feels fast. How much of this is the actual engine, I do not know, but it is a pleasant experience none the less.
  • The search dialog is smaller and less intrusive than Firefox’s or IE’s dreadful popup box. Because of the way it tucks away into the upper corner, it stays out of the way better on average.
  • The ability to use the address bar as either an address bar or a search engine is very, very nice.
  • I like what they have done with Opera’s speed dial page. the addition of a search engine and history are useful additions.
  • I am glad to see them getting rid of the menubar. Firefox really ought to do this as well.

In conclusion, Google’s browser offers some nice UI improvements to the browser. It will be interesting to see how Firefox and Opera react. Safari is unlikely to take much, for good or ill. Apple marches to the beat of a different drum.

Playing Devil’s Advocate

In all the cool geek sites, you hear PHP put down as a matter of course. Its inferiority goes assumed by most of the audience. Every once in a while, you see someone decide to defend it, which leads to a nice old flame war, but that’s about it. The irony I find is that few of PHP’s defenders really do a good job defending the language. The extreme is this one guy, whose defense of PHP runs: “I like it. It does everything I’ve ever wanted it to do.” Not much of a defense. Leaving Turing Completeness aside, the defense says nothing. Anyone can say that about any number of languages and you could never prove them right or wrong. If PHP can do everything you ever wanted to do, then at least half a dozen other languages can (C#, Java, Perl, Python, Ruby, C++). Why PHP? What you usually find with this kind of defender is that it was a language that they picked up at some point, for some reason and they do not know enough about other programming languages or even PHP itself to be able to give an adequate reason.

The charges against PHP are that it is sloppy, inconsistent, encourages laziness (and not the Larry Wall variety), and lacks some of the cooler features of other languages. Guilty as charged. All of those things are true and have been rehashed many times. As a disclaimer, let me say that I agree with this point of view. For web programming, you are better off with Python than PHP. But, let me play devil’s advocate for a moment. If I were going to argue for the use of PHP, what would I say? Well, I would begin by pointing out that PHP is fast. Maybe not out of this world, I funrolled my own loops, and wrote my web framework in assembly fast, but it is fast. PHP is also very easy to deploy. If you set up a Python WSGI application or a Rails application on Phusion Passenger, there is a fair amount to set up in the web server and get running. Not unbearably so, but PHP wins as, in most cases, you copy over the source and you are good to go. There is a ton of library code available and many fine, large applications (obligatory Drupal and WordPress references here) written in PHP. There is an abundance of cheap hosting that has PHP set up by default (Python is starting to gain traction as GoDaddy has started offering Python over CGI in their deluxe Linux packages), which, in many cases is important. Sure, if you are personally developing a large Enterprise application, it seems reasonable to expect someone to be able to configure a server for it. On the other hand, if you are running a small business and just want a CMS to run your web site on, you do not need anything more than cheap, low-level hosting. In this case, the business is not the developer and does not hire the developer, but if you are writing the software and want this small business owner to use it, than there is a definite advantage here. WordPress would probably never have caught on if it were not written in PHP because it would be too much work for a lot of people to set up and too much work for most hosting services to support.

There are some notable, often-cited reasons to use PHP left out. For example, many have argued in PHP’s favor because there are many developers which means that it should be easier to fill any new positions in the case of departures (an obvious concern for open source and closed source teams alike). The problem with this argument is that, while it is true that there are a very high number of PHP developers, the problem here is that a very high percentage of them simply are not any good. They picked up a bit of PHP and HTML, but were too lazy to learn enough to be truly excellent developers. The end result is that this is more a problem than it is a solution, because there is a lot more chaff to sift through in the hiring process. It certainly is not obvious that you are better off this way than, say, Lisp. There are few Lisp coders on the market, but, as a rule, they are better coders. The very bottom of the barrel have not even heard of Lisp and, if you try to get them interested, you encounter the Blub phenomenon: they cannot comprehend what a more powerful language would even look like.