My favourite podcast has announced something exciting to celebrate reaching a landmark one hundred episodes: an anthology!

In a few weeks when StarShipSofa reaches one hundred episodes of it's Aural Delights show, a compilation of some of the great stories broadcast so far on the show will be made available as both a free e-book (PDF) and also as a print-on-demand (via Lulu) paperback.

I'm looking forward to picking up a copy - for the new artwork, to support a great show and as a way to easily return to some terrific stories.

Check out episode 98 for the official announcement, and take a look at the cover art preview.

UPDATE: My copies have arrived, but instead of Lulu mine come from here, the alternate PoD publisher Blurb. Behold the unboxing.

SofaStream beta is finally out on the Android Market! Load up the market app, search for 'SofaStream', download it and take it for a spin - I'm looking forward to all the feedback. :)

Notes:

• This is beta. I've been hammering it over the last week or so and I think it's pretty stable, but I (like all of my kind) suffer from Developer Syndrome - I don't use my software the same as someone who doesn't know how it works under the hood. If it breaks, or even just does something unexpected, I'd appreciate knowing about it.
• This is a work in progress. And I mean from both sides - I'm working with everyone over at the StarShipSofa to make the RSS data I'm drawing from as rich as possible, so SofaStream is as appealing as possible. The file sizes on the Sanatorium feed are an example of things we hope to improve in the future. If you have ideas for new features, again, let me know.
• The icon. The default icon on this SofaStream release is no accident - we're running a competition over at the StarShipSofa to create one. If you can build something in a 48 by 48 pixel PNG that you think captures SSS and SofaStream, send it over to Tony via starshipsofa@gmail.com - you might win some tasty fiction.
  

Thanks to Tony at SSS for the help and encouragement, and to my lovely fiance Mandy for her support and patience during "the project that ate my weekends".

Starting with a new IDE, a new SDK and a new language is in intimidating project, and despite having done some mobile, Eclipse and Java development before there's still lots for me to trip over. Case in point: I tried to clean up SofaStream's codebase to check it into source control on it's Google Code project, and somehow upset my Eclipse project. I seem to do this once every few months using Eclipse - making some code or configuration change gets the project into an unusable, irrecoverable state and hours of research offers no solution for correcting it. In my case nuking some of the generated directories - 'gen', or possibly 'bin' - caused the 'src' directory to be marked as having errors, but with no source code was highlighted as being the cause of the errors. I was also seeing 'no classfiles specified' errors in the console, but couldn't see any clear way to correct this either.

Extensive Googling revealed a lot of similarly frustrated people, but no solution that worked for me - refreshing, double-checking the SDK path, I still couldn't build 'cause my source code was "broken". So I did what seems to be a recurring solution - I nuked (leaving source intact) and reconstructed the Eclipse project. This worked like a charm, even though I actually re-imported the same project files from the "broken" project - strongly suggesting that there was nothing wrong with my project at all, Eclipse was just having a deranged moment.

So if you see something similar in your own project (or you're using Eclipse regularly) - get comfortable with separating your codebase from your Eclipse project... and remember that throwing away the later is an option, if it seems irrecoverably broken.

While discussing volunteering as a narrator on the excellent StarShipSofa podcast, I happened to mention my enthusiasm for my new G1 and the Android platform. SSS editor Tony C. Smith is apparently also a G1 owner and we were soon throwing around ideas for a SSS-specific app - long story short, I have a new project.

After a weekend or so of hacking I have a rough mockup of the interface. I've also drawn inspiration some very handy RSS parsing code and am now exploring Android's Handler class to spin the hard work off into a separate thread. The learning curve has been steep (I'm learning a lot of Java at the same time as learning a lot of Android concepts) but Google's documentation is pretty strong and the ApiDemos package is also a great place to see this stuff in action.

Mostly it feels quite like the GTK development I've previously done (particularly for my N800) - nice background adapter classes to map from data sources to list views, etc. I was particularly impressed with 'linkify', though - it's a flag on the basic text view widget that automagically converts all URLs in the text into clickable, browser-launching links. For more control you can always break out the embedded webkit view, but for basic marked-up text (like the summary text from an RSS feed) this was awesome.

More information coming as this moves into beta - stay tuned.

Seems like a simple request, doesn't it? "How can I share my phone's internet connection with my computer?" Well for G1 users it's a little more complicated than it seems...

1. T-Mobile US doesn't permit it. According to developers creating tethering apps, the Open Handset Alliance is removing apps from the Android App Market, arguing that said apps breach T-Mobile's US terms of service.
2. Many tethering solutions require root access. Tools like tether Blu require non-trivial modification of the device, something that can cause problems with updates later, as users of jail-broken iPhones can attest.

Luckily the European T-Mobile TOS don't aren't similarly crippled, and I found some solutions that don't require root access - but I spent quite a few hours wrestling with this, so I thought I'd post a few notes about my experiences.

PDANet looked nicest, initially - a simple client on the PC side that could install and then connect to a little phone-side app. Problems cropped up pretty fast, though - I had trouble finding help on their site, and once I was up and running, well, I wasn't up and running very long... the connection dropped regularly. Also they only provide clients for different versions of Windows, leaving Mac and Linux users out in the cold.

Tetherbot turned out to be the best solution for me. It involved a little more tweaking, but as a developer working on multiple OSes it delivered what I needed - reliable connectivity. it works by providing a SOCKS proxy on your machine, connecting via the Android debugging tools to an app on the phone. That might sound complicated, but if you've already got the Android SDK installed (as I have) the remaining steps are simple. (And if you don't, you can get just the bits you need from a link on the Tetherbot site.) From that point on my real stumbling block turned out to be Firefox - SOCKS proxying just wouldn't work for me. Safari was quite happy to connect, though, and current advice is that the FoxyProxy Firefox add-on is all things to all SOCKS users. :)

Mucking around with SOCKS settings and dealing with T-Mobile's uneven connectivity in my area means that this isn't a permanent solution. But hopefully it'll get me through the 4 to 6 week lead time currently suffered by those of us in the Netherlands trying to get ADSL...

There's always something new around the corner - you can wait forever for the perfect gadget to be released. But sometimes you just have to throw your economic support behind the best thing available now - take a risk on whoever is going in the direction that excites you.

For me the best compromise was HTC's G1. Sure (as previously noted) the chassis is a little dinky and plasticy, and the touch screen isn't all it could be - and the lack of a regular earphone jack is frustrating. But I think Android as a platform is pointed in the right direction, and I needed a phone sooner rather than later - the G1 was my only choice when it actually came time to choose.

The purchasing process was typically awful - the staff in my local T-Mobile store (Leiden) actually didn't know how to dial a number on one of their own display phones. My ignorance of European phone configurations also led to me locking myself out of my handset until the store staff explained the PUK system (something not used in Australia) to me. Between ignorance of the rules relating to internet connection tethering (something I'll write more about soon) overcrowded stores and trying to pressure me into upping my connection speed, I can't recommend T-Mobile's stores less.

On the plus side, though, the phone is actually quite nice to use. The pluggable 'intent' system makes getting stuff done really easy - snap a photo and send it via gmail with just a few easy commands, for instance. And while the initial set of applications is a little minimalist, the developer community has really stepped up with some great games and tools. For instance:

• InfiniMusic - slick music and podcatcher. short a few features and a little processor intensive, but clear and very usable. 
• NewsRob - Full-featured Google Reader client. Undergoing continuous improvement, Mariano Kamp makes taking your feeds with you easy.
• Battle For Mars - Larva Labs' pixel-art-style turn-based strategy game wowed me with the free version - can't wait to grab the full one.

The battery life, unfortunately, sucks - mainly because I use it like a PDA instead of a phone. I download podcasts, fiddle with maps and do a heap of 'net traffic - all of which meaning that the radio, CPU, GPS and screen are active for long periods. As a result I have to charge it everywhere - home and work - everyday. There's bigger batteries available, apparently - something I'd look into if charging everywhere wasn't viable.

I've been thinking recently about creating a timeline of my life, a visualisation of people, places and events that have been significant to me. I decided to try and feed it using the data I have sprinkled around in various systems - events from Google Calendar, contacts from Gmail, pictures from Google Web Albums - and started searching for tools to tie them all together with.

MIT's Timeline immediately caught my eye. Part of their SIMILE visualisation project, Timeline provides a very slick data-driven DHTML toolkit for smoothly scrolling timelines - provide it a DIV and some JSON-formatted data and Timeline does the rest. (SIMILE also has some other great visualisation tools - check out Timeplot or Exhibit for more examples.)

jsViz is also pertinent, although I'm less certain how I'll use it. This last.fm mashup certainly grabbed my interest, though.

This is an ongoing experiment, so I'll be updating as I explore the possibilities. Ultimately, I'd love for this to end up as a web service - feed it your syndicated life data and scroll through a visualisation of your life...

This Slashdot article gives a good run-down on Palm's new iPhone (and G1) 'killer' - the Pre. Like the G1 it's a smartphone with a slide that reveals a QWERTY keyboard - the main differences are that it's a vertical slide, and seems more nicely built (brighter screen, etc.)

The 'completely new OS' is Linux with a Webkit-based browser in front of it - apparently regular developers will write their apps in HTML, CSS and JavaScript (and only 'special Palm partners' will be allowed access to the underlying system.) In a former life I was a Palm OS developer - it would be a little like time travel to return to this context with my current web developer skillset.

This is yet another 'new OS' which is actually a VM running on Linux - Android has Java, WebOS has JS, even the iPhone SDK forces you to write some objC. This is what frustrates me about these phones - each is still just a little too restrictive for me to really lust after one. At least with Nokia's Maemo (which I've had great fun developing Python/GTK apps for on my N800) you get a proper Linux stack and can write applications in anything, including C - but unfortunately none of Nokia's phones run Maemo, only their internet tablets. So out of the three platforms, I'd have to go for the Pre - the UI looks incredible, and I like JavaScript a lot more than Java or objC.

I was very excited to be at the Android Dev Camp - I've been very excited about Android since it was first announced. But in both cases I feel let down by something that was rushed out too fast, without sufficient thought.

The highlights

Christine Karman and Alexander Muse were really enjoyable. Christine was refreshingly honest about the platform, Alexander about the mobile application ecosystem. I'd like to applaud both presenters for the quality and professionalism of their presentations.

Regarding the phone, the design has some pleasant suprises - the mini-trackball being high on my list. The browser also has some neat tricks like the iPhone, and like with the iPhone these tricks will only be apparent to power users.

The disappointments

Java developers complaining that Android isn't 'proper' Java. Google has always said that Android *isn't* Java - time to deal with it.
T-Mobile should have sent an engineer, not a sales exec - the same goes for Google. Both of them blithered about the mobile business instead of saying anything concrete about Android, and what it means to their businesses. (On a side note - am I the only one who remembers that T-Mobile tried to copyright a *colour* not too long ago?)

For the phone - it feels plasticy and cheap. Every single person who demonstrated the phone had trouble getting the touchscreen to respond, and there's a lot of reports from technical people that it feels dumbed down. And where's the earphone jack?

Conclusion

I so wanted to like the them, the camp and the device. The only thing I'm really excited about now, though, is that Android has finally driven a real, mainstream open handset to market - now if I can just find a decent OS for it...

I couldn't find a decent solar calendar on Google calendar (one that tracks the yearly solar cycle of equinoxes and solstices) so I decided to create one.

The data is in a table on the Solstice Wikipedia page - the lxml.html module for Python should be able to extract it.

Google's Calendar API gives us the means to pour the extracted data into a Google calendar.

And here's the result (and the final script.) A few hours productive work on a quiet Saturday morning. :)

(Thanks to Ian Bicking for this blog post on replacing (the excellent) Beautiful Soup with lxml.html - it worked extremely well.)