Recent blog entries for davidw

Android marches on

This was unexpected, but very welcome: a new Android SDK, with a bunch of updates, and a "roadmap".

http://android-developers.blogspot.com/2008/08/announcing-beta-release-of-android-sdk.html

It also looks as if we may see some phones right when they were supposed to be available:

http://www.alleyinsider.com/2008/8/gphone-on-its-way-fcc-approves-htc-dream

Of course, there is no source code, yet, but it's still good to see things kicked into gear and running again.

Syndicated 2008-08-18 19:38:00 (Updated 2008-08-18 19:41:38) from David's Computer Stuff Journal

Job search sites, Java and Ruby

I occasionally like to fool around with statistics gathered from the Internet. Sometimes, to produce something like langpop.com, which, even if it's unscientific, I feel is useful, and more or less reflects my gut feeling about which way the wind is blowing. Other times, it's fun just to grab some numbers, add them up, and not worry too much if they really have any validity or meaning. In this case, I suspect there's something to them. What do you think?

The technique: take different job search sites, like monster.com, craigslist, and so on, search them for various languages (with Yahoo's search API), count the hits, and then look at the ratios. For instance, Java jobs to Ruby jobs, with the idea that, painting with very broad brush strokes, the Java jobs are going to be more "enterprisy", and the Ruby jobs hipper, cooler, and maybe gone six months from now as the economy tanks and funding dries up. Rough techniques notwithstanding, there do seem to be two distinct groups of sites, one with lower rations, the other with higher ratios (more Ruby jobs compared to Java jobs). For fun, I also included Python and Erlang, although there are very few Erlang jobs out there.

Of course, it's also true that the bigger sites, like dice.com, had more jobs total. Indeed, dice.com has more hits for Erlang than CrunchBoard does for Java!

Syndicated 2008-08-13 20:22:00 (Updated 2008-08-13 20:58:25) from David's Computer Stuff Journal

Hecl Syntax: A Survey

[ Taken and modified from a post to the hecl-devel mailing list ]

I've been talking with a company about a consulting job regarding a programming language for mobile apps. Sounds familiar, right?

There is, however, a bit of discussion regarding the syntax - my contact at said company maintains that Hecl's syntax is unfamiliar to many programmers, and I think on the face of it, I'd have to agree. Of course, Hecl's syntax is like it is because when I started the project, being very small was a necessity, and a very simple syntax facilitated that goal nicely. Additionally, the syntax allows for extreme flexibility, letting you create new control commands, and "DSL's" (domain specific languages) easily. Also, sticking with small/simple means that the interpreter and parser can both reside on the phone, instead of doing some kind of solution where the development/host computer compiles the scripting language to byte code, and the interpreter on the phone runs the byte code. That sort of strategy has some advantages, but has disadvantages too: if you don't have an on-board parser, you don't get "eval".

---

<h4>A quick Hecl syntax refresher:</h4>

In Hecl, everything is a command, seperated by spaces, and grouped with {}:

if { ... } { ... }

Is a command that takes two arguments. It evaluates the first one, and if it's true, evaluates the second one. This is different from languages like C, Python or Ruby, where 'if' is part of the language. For those unfamiliar with languages like Lisp, where this looks strangest is probably in conditions or other expressions:

if { = $foo 10 } { puts "foo is ten" }

Or

set foo [+ [* $bar 10] [- $beebop $doowah]]

Which is certainly a different take on things than most 'mainstream' languages. That radical simplification is, however, one of the ways that I used to save space in the interpreter.

---

Personally, I'm pretty happy with how Hecl looks, but I am sensitive to the 'marketing' argument: popularity helps, and this isn't the first time I've heard complaints about Hecl looking "funny" to people.

What do you think?

A) "I like Hecl just the way it is and wouldn't want to change it!"

B) "Hecl is quite useful, but I just want a mobile scripting language, the syntax doesn't matter much."

C) "I think the syntax is ugly, but I use it because I need an interpreter."

Also related:

1) "I don't care too much about code size. My current apps target N kb as an acceptable size."

2) "Small is really important. The smaller the better."

And:

I) "I don't care about eval, or being able to run human readable code on the phone."

II) "I really like the fact that you can download or even write code directly on the phone."

And finally:

X) "I don't care about midp1.0"

Y) "The fact that Hecl runs on midp1.0/cldc1.0 is important to me."

Now, I am not going to run off and change Hecl! Code that currently runs ought to continue to run, modulo some tweaks here and there, api changes, and the normal stuff. If I do something 'new', it would probably be a clean break (although of course code that could be reused would be), and will be in addition to Hecl, rather than instead of Hecl, because I would be working on the 'new' language as a day job. I do that with Hecl too, but not all the time, as I often have consulting/contracting work.

Syndicated 2008-08-12 18:59:00 (Updated 2008-08-12 19:19:19) from David's Computer Stuff Journal

langpop.com in Tim Bray's OSCON keynote

It was neat to see "langpop.com" on the screeen during Tim Bray's talk at OSCON (contains a link to the video):

http://www.tbray.org/ongoing/When/200x/2008/08/05/Annotated-OSCON-Keynote

The talk itself was an overview of the state of programming languages. However, 15 minutes is not enough time to do the topic justice, but if you're not a language geek, it's not a bad survey, and I really like his style: he's fair when he points out the good and the bad. Like him, I am sick of PHP and do not care to use it any time in the near future, but that doesn't mean there aren't a lot of good things to be said about it. In any case, I'm honored that Tim used langpop.com as a source for his talk.

Syndicated 2008-08-06 16:38:00 (Updated 2008-08-06 17:03:48) from David's Computer Stuff Journal

New Hecl Release

I've added a new Hecl release to the sourceforge site:

http://sourceforge.net/project/showfiles.php?group_id=122383

Although, as always, you're probably better off checking it out of subversion. We mainly do releases in order to focus on polishing things up just a bit, and as a way to promote Hecl by creating a reasonably stable release.

Some of the things that we've got working pretty well for this release include:

• Google Android support.

• Java reflection/integration - call Java directly from Hecl.

• And of course a lot of numerous other little tweaks and fixes that crop up over time.

Syndicated 2008-07-31 09:37:00 (Updated 2008-07-31 11:35:08) from David's Computer Stuff Journal

Startups and the role of capital and investments

One of the most exciting things about the computer industry these days is the ease with which can get started. Decent computers can be had for well south of $1000, hosting is cheap, services like Amazon EC2 make it ever easier to scale rapidly should the need arise, and the only other things you need are an internet connection and a place to sit. This is leading to more people, like 37 Signals to question the need for investment entirely and others, like YCombinator to successfully make very small investments (thousands of dollars, rather than millions).

Sometimes, however, I wonder - is it just a passing moment in time, a window of opportunity, or is it a long term trend? Historically, to set up something like a factory required a great deal of money, putting it beyond the reach of anyone unable to obtain financing. Even in this day and age, there are plenty of endeavors that require large amounts of capital, and a lot of time, prior to seeing returns: that's how things work in my wife's field, biotech. Some fields have even become more expensive with time. High end computer games are very expensive propositions in this day and age, compared to the low budget stuff typical of, say, the Commodore 64 era, although it's also true that the market has also grown a lot, and that there is still space for smaller-budget operations.

How does all this look historically? Have there been industries in the past where it was so easy to get started? Anything that was able to scale? By which I mean: it might have been relatively easy to start some kind of small business, but it would most likely always stay small, whereas things like Craigslist or 37Signals have the means to grow a great deal without adding lots of people. Will things change in the future so that one or a few programmers can't compete with a big team? Or perhaps things will go in the other direction and more industries will become like computing is today and it will be possible to a biotech startup in your home office?

Syndicated 2008-07-18 11:43:00 (Updated 2008-07-18 12:33:24) from David's Computer Stuff Journal

Misquoted

Well, to be charitable, it was a bit late and so perhaps what I said came out wrong, but in this article:

http://www.theregister.co.uk/2008/07/14/android_developer_unrest/

I'm quoted as saying the problem is with "upper management", which I don't really believe to be the case, going by snippets of conversations and things I've read. Frankly, at this point in time, I have no idea why Google can't talk about Android.

Also, I had several other positive things to say to the reporter, but I guess the 'focus' of the piece was about the problems that Android is currently experiencing. Notwithstanding the recent weirdness, I'm quite happy that someone with a lot of money and muscle is going to be backing an open source mobile phone system, and hope that the current troubles are merely a small speed bump.

Syndicated 2008-07-15 18:53:00 (Updated 2008-07-15 19:09:25) from David's Computer Stuff Journal

Squeezed Books Contest

I'd like to announce a modest contest on the Squeezed Books web site: the person who contributes the most to existing or new summaries wins a free business book + shipping, from Amazon, courtesy of Squeezed Books.

Yeah, I know that it doesn't really compare with the millions that big companies can give away, but I thought it would be a nice way to reward people who work on the site. If it works out well, we'll repeat it every month.

So, if you're the kind of person who already takes notes when you read a book, or you've read a lot of business books and can distill their key points, this might be a good opportunity to take a chance at a free book, and share your knowledge with others (summaries, unless otherwise noted, are under a Creative Commons license).

Questions and comments welcome: it's an experiment, so ideas on how to improve it are welcome too.

Syndicated 2008-07-11 12:07:00 (Updated 2008-07-11 12:30:07) from David's Computer Stuff Journal

Google, Android, and the case of the missing communication

Like many people, I participated in the Google Android contest this spring, and like most of them, I didn't win, but I did enjoy working with the platform, and am very excited about the idea of an open source mobile platform that's relatively powerful.

From the outset, due to the lack of actual source code for a lot of the system, there have been "doubters" about what Google is really up to. I'm not one of them, and am largely ok with their reasons for holding back: I buy their reasoning that the long term benefits of a strong, properly QA'ed launch probably outweigh the possibility of failure that might come from the press and the public at large that doesn't care much about software freedom seeing phones come out with half-baked, early implementations. I think most of us working with Android were ok with that strategy, and the ones who weren't self-selected out of the platform, most likely.

However, lately Google has made something of a mess of their communications regarding Android. The problem stems from the fact that they gave an updated version of the SDK only to the winners of the competition, which for a lot of people felt like a bit of a slap in the face: they helped popularize the platform by participating in the contest and writing applications for it, and in return got excluded from the upgrade path. Personally, it's not really any skin off my nose, as I'm sanguine about the Hecl port proceeding apace when the new SDK is public, but I can see that if you were, say, a company porting your app to the platform and now are left behind the competition winners, you might be a bit irritated.

The biggest mistake they've made though, is a big lack of communication regarding this business. As I said, I don't really have that much skin in the game, and if they explained in a convincing way why they needed to do things that way, they would go a long ways to allaying the frustrations felt by many.

I'm not much of a believer in conspiracy theories and plots, especially where companies are concerned. Inept bumbling is a far more likely explanation in most cases, including this one. What is odd, though, is that Google has a lot of people who "get it". I met Dan Morrill at the Munich Android event, and he definitely gets it. He writes about his frustrations as a developer advocate and all the crazy things people say. Well, one way to reduce the number of batty internet theories (eliminating them is clearly impossible due to the alien mind control rays) is to consistently communicate quality information about what's really going on, something that has been lacking with regards to the SDK question. Here's another Google employee who understands this need to communicate, and apparently does so despite being worried about being "slapped for talking publicy about all this":

http://groups.google.com/group/android-developers/msg/244edfad99870c63

But the root of the problem is certainly not licensing but that there hasn't been a new public SDK release since M5, while at the same time a small group of people received updated versions privately.

I really don't know precisely why this happened; but I'm sure it has more to do with logistics and reducing the burden of support while we shift priorities (to shipping real devices) rather than politics or any will of our part to "hurt the community" (come one guys, we are not that stupid... !)

While others in the team may disagree, I think it was very very unfortunate; some of us are trying to prepare a new SDK release, but it's a lot harder than I can comment on here, so don't hold your breath because it might not happen that soon.

This explains things in part, but still leaves us in the dark, and leaves me with the feeling that someone in power, somewhere at Google, despite his or her clued in colleagues, really doesn't get it with regards to open source.

I'm still unconcerned about the Android source code: I think we'll see it, but to be a true open source project, Android will need an open community as well, not one where decisions are taken exclusively at Google, and not even communicated to the development community at large. All in all, this mistake is more molehill than mountain, but however you look at it, in terms of open source, it is a step backwards.

Syndicated 2008-07-09 12:11:00 (Updated 2008-07-09 12:58:43) from David's Computer Stuff Journal

Cache it all

I recently redid my personal web site, at welton.it. Wanting to be quick about it, and make the look and feel a bit more uniform than it has been in the past, I hacked together some pages in Rails. Despite this being sort of a "killing a fly with a bazooka" situation, I've been doing lots with Rails, so it was quick to use. Here's the thing, though: Rails is definitely overkill, as the site is basically static. I don't need to calculate anything or fetch stuff from a database - I just wanted a reasonably good template system, and I am quite comfortable with Rails these days.

But the idea of leaving Rails running for a static site was of course no good: I basically need to cache the entire thing, so that Rails is simply not involved. How to do this as quick as possible (in between diaper changing and other baby duties!) ? Ideally, it would be possible to introspect Rails in order to know exactly which pages are present, then cache those, and avoid Rails on the server entirely (just generate them locally and put them in subversion), but that proved to be fairly hacky, so I settled for this code, which simply caches all pages which comes across, when caches_pages is placed in application.rb:

class CacheFileName
  include ActionController::Caching::Pages
  include ActionController::Caching::Pages::ClassMethods

  def cachedname(path)
    page_cache_file(path)
  end
end

def caches_pages()
  return unless perform_caching
  after_filter do |c|
    res = c.cache_page
    cfn = CacheFileName.new
    cf = Cachedfile.new :filename => cfn.cachedname(c.request.path)
    cf.save!
  end
end

It simply caches everything. To be able to easily clear out the cache if there are any changes to the site, we record the changes in the Cachedfile model, which is defined like this:

create_table "cachedfiles", :force => true do |t|
  t.string   "filename"
  t.datetime "created_at"
  t.datetime "updated_at"
end

with this model:

class Cachedfile < ActiveRecord::Base

  def Cachedfile.clean_cache
    Cachedfile.find(:all).each do |cf|
      begin
        fn = ActionController::Base.page_cache_directory + cf.filename
        File.delete fn
      rescue => e
        logger.error "Error deleting #{fn}: #{e.inspect}"
      ensure
        cf.destroy
      end
    end
  end

end

which has a class method to go through and clean out all the cached files. I call it manually from ./script/clean_cache:

#!/usr/bin/env ruby

ENV['RAILS_ENV'] = ARGV.first || ENV['RAILS_ENV'] || 'development'

require File.dirname(__FILE__) + '/../config/boot'
require "#{RAILS_ROOT}/config/environment"
require 'console_app'

Cachedfile.clean_cache

It's not a beautiful system, but it gets the job done.

Syndicated 2008-06-13 21:21:00 (Updated 2008-06-13 21:45:08) from David's Computer Stuff Journal