I’ve recently finished writing an article for Free Software Magazine, who, as part of sponsorship deals, are able to distribute a free book to their authors.

I thought that that would be easy enough, but on second thought, I’m actually not sure… These days I’m reticent to get books on things that are documented on the web – those sorts of books tend to get stale pretty quickly. I think I’m more in the market for a ‘classic’, but even there, I’m not really sure. I have a lot of good ones already (scroll down on this page: http://www.welton.it/freesoftware/), and as you can see from that list, “documentation” style books quickly become dated. To tell the truth, I haven’t actually bought any computer books in a while, having focused more on marketing, business, economics and the like, which aren’t “documented” online as thoroughly as most programming topics are.

So, I’m lookng for suggestions. One possibility is the recent Erlang book by Joe Armstrong, but even that is mostly covered by docs on the erlang.org web site.

Free Software Magazine’s publishing sponsors are: Apress, Addison-Wesley/Prentice Hall, O’Reilly, No Starch and Packt – and I can select any book from them, to my knowledge.

Suggestions? Thanks!

http://www.google.com/search?q=211.46.221.34

Yuck… look at all the damage one idiot with some scripts can do. I wish there were a way to make people like this pay.

A while ago I wrote about the idea of “playing fetch” – meaning chasing after programming “sticks” that are basically makework. I am starting to get the feeling that the documentation system that I chose for Hecl is one such stick. I’ve been trying to document that lcdui commands that Wolfgang created last year. They’re really cool, and give you access to pretty much everything you can do from Java, but cranking out these docs is sure time-consuming. Here’s an example:

<refentry id="lcdui_date">
  <refnamediv>
<refname>lcdui.date</refname>
<refpurpose>Date/Time widget for lcdui forms</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
<cmdsynopsis>
  <command>lcdui.date</command>

  <arg choice="opt">
    -date
    <replaceable>date/time in seconds</replaceable>
  </arg>

  <arg choice="opt">
    -label
    <replaceable>label</replaceable>
  </arg>

Once you finally slog through and create the documentation, it’s very flexible, because you have not created just formatting instructions, but actually described each piece of the text.

But… look at how often things get repeated. Aside from the repetitive XML tags, lcdui.date is more or less there three times. Ugh. Emacs + psgml mode helps some, but I still get the feeling I got suckered into doing something that should only be attempted by Big Corporations or at least large, well established projects that can afford to send people off to spend lots of time producing this kind of documentation.

Roger Binkley, leader of Sun’s Mobile and Embedded community, interviewed me after my talk at OSCON. It went ok, given how tired I was:

http://today.java.net/pub/a/today/2007/08/20/javamobility-podcast16.html

I had a pretty good week last week in terms of doing some open source work. I had the opportunity to do some consulting regarding Hecl, which was pretty cool. Some of the work was fed back into Hecl itself, including the beginnings of a “media” API (video streams, taking pictures with the camera), and some other fixes and updates. I’ve also been working on it a bit on my own time, adding a Canvas demo to the MIDP2.0 demo application (works in the emulator, haven’t tried it on a phone yet), and today I’m going to look at updating some of the documentation that’s been lagging the code. In the course of my work, I also happened on a cool idea to speed up the launch of Hecl applications: by creating the widgets as regular widgets in Java, right away, in the startApp MIDlet method, it’s possible to get them on the screen quickly. At that point, you can start loading Hecl, and create some Hecl objects to hold the already created Java widgets. It goes something like this:

Form mainform = new Form("Initial Form");
TextField search = new TextField("search:", "", 30, 0);
... load script ...
interp.setVar("mainform", ObjectThing.create(mainform));
interp.setVar("searchwidget", ObjectThing.create(search));
... evaluate script ...

This is a good tradeoff, because it gets something in front of the user right away, and it’s not a throwaway like a splash screen.

On another front, I’ve updated some of the code in DedaWiki, to enable email notifications in the comment system, which has percolated into the Linux Incompatibility List, and, with a bit of tweaking, into Squeezed Books. I don’t think the code is quite ready for a real release, but by running the incompatibility list on it, it’s a great way to give it a thorough shakedown, and I’ll attempt to release it sooner or later. Of course, in the meantime, interested parties can get the code out of subversion on rubyforge.

Growing up in Eugene, Oregon, which like Berkeley or Boulder could have the label “People’s Republic of” applied to it, I always thought of “business friendly”, as something along the lines of helping huge corporations avoid laws against pollution, or other antisocial behavior. Only after moving to Europe did I begin to get an idea of what the very positive side of “business friendly” is in the US.

Truth be told, all countries tend to protect their ‘big players’ to some degree, be it the US propping up creaking airlines after September 11th, Italy finding various clever ways to get around rules about funding Fiat and Alitalia, or France finding it in their ‘national interests’ to discourage a potential bid for Danone (yogurt!) by PepsiCo. Some are better or worse (the UK has been pretty good about not interfering), but there is a tendency to want to intervene.

Leaving be the discussion over whether those sorts of policies are good, bad, or ugly, the biggest difference between continental Europe and the US is the ease with which new companies – ‘startups’ can be created and enter a market.

As a first hand example, I decided this summer to create DedaSys as a real company in order to better separate my business and personal financial dealings. Were I to do that in Italy or Austria, we would be talking about fees upwards of 3000 Euros (about 4000 dollars at market rates), which is a great deal of money for something that is not making a lot of it at this point in time.

Contrast this with what it took to create a Limited Liability Company (LLC) in Oregon, my home state. To have things done up professionally, it’s certainly possible to lay down a bit of cash there too, but by trading my time for money, and with the assistance of some nolo.com books about the creation and maintenance of an LLC, I was able to register DedaSys with the state of Oregon for the grand total of 55 dollars, and was actually able to complete the process remotely from Austria prior to going home on vacation, where I did the only thing I needed to do in person: open a bank account.

So it costs 1% of what it costs in Italy or Austria to open a company that provides limited liability… a very impressive difference, especially to a small, new company that does not have the connections a Ford or a Fiat will likely have to enable it to deal with all the other paperwork, rules, and regulations to deal with.

Add to that a culture of greater risk taking (meaning also more acceptance of failure), better funding opportunities, and… one comes to the conclusion that Paul Graham is right. It’s a pity, because the people in Europe are top notch. In Italy alone, I know a bunch of really bright hackers. Granted, some of them aren’t interested, and are probably better off not starting a company or otherwise dealing with the business side of the equation, but it’s always nice to have that opportunity.

In closing, here is another example of bureaucracy in action, from my personal on line journal about life in Italy, and now Austria, which I recently revamped by moving it to the Typo platform:

Confronting the bureaucratic beast – registering an Italian domain

Two months to accomplish what can be done in ten minutes with a .com!

At some point in the past, Steve Yegge had his “drunken blog rants”, now sanitized to “Random whining and stuff“, so I guess after one beer I ought to be allowed to rant a bit about what is, according to him, the “Next Big Language”. He comes right out and says it in this video:

http://blip.tv/file/319044/ (skip to the end if you want to hear it from the horse’s mouth).

What he gets right in his talk is that Javascript does not have a good brand due to inconsistent and troublesome implementations in browsers. Actually he gets a lot of things right – more geeks should pay attention to having a basic knowledge of marketing, because it’s a reality that isn’t going to go away just because you don’t like it. Leaving that discussion for another time, though, what brought this to mind was this cleverly worded error message in an application I’m trying to stich together:

Object cannot be created in this context" code: "9

To borrow a line, “Note the consistent user interface and error reportage. EdJavascript is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.” Indeed, I don’t have a clue as to what it’s complaining about. Naturally, I had a look on Google with the error message, and found a few other individuals suffering from the same symptoms, and checked, and rechecked that I was indeed including prototype.js prior to including the file causing the error, but all to no avail.

After an hour or so of googling and fiddling with firebug, and reloading, the problem seems to have “just gone away” (I wouldn’t believe me either, but there it is…).

Let’s hope that if Javascript does become ‘the next big thing’, that even more effort is put into making it a pleasant experience for developers.

Given my desire to see the community around Squeezed Books grow, I went ahead and added a creative commons ‘attribution/share alike’ license to it. I also did this in the spirit of reciprocity towards other people pursuing similar initiatives and using similar licensing. The goal really is to give people an idea of what some of these well known business books are about. Even though the book in question may present a unique and interesting idea, many of them can be summed up pretty quickly. As Phil Greenspun says:

This book illustrates a fault in the publishing industry. If you have
a 50-page idea it is too long for a magazine. But it is too short for
a book. So if you wanted to get it distributed before the Web came
along, you had to drop in words until you reached 200 pages.

I don’t really think the web has changed things that much, either. Who wants to simply put up a web page when they could publish a book?

The idea isn’t necessarily to avoid buying books, either – some of the good ones are really good reads, and a summary just isn’t the same thing as the book itself.