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.)

The gPowered blog has a solution for creating RSS feeds of sites that don't already have them - Dapper + Yahoo Pipes.

(I'm experimenting with this currently, since Google Sites doesn't provide an RSS feed for site news items.)

UPDATE: Dapper has turned out to be disappointingly broken, and Google is apparently shutting down their Mashup Editor. Anyone with suggestions for a better solution?

Ever accidentally saved a typo into Firefox's dictionary instead of correcting it? Caveman50.com has the answer on how to fix it.

Over the weekend I started building some basic animation into Faultline, and I hit the classic problem of maintain state for multiple animation effects, while also trying to provide a responsive GUI. A neat solution is available in Greenlets - a lightweight tasklet library that came out of the work done on the Stackless Python project.

Greenlets are like threads, but without the locking problems (since only one is ever running at any time.) They allow you to freeze methods at any point and switch between them, allowing the creation of co-routines and more elegantly structured code. In Faultline I switch to each animation effect greenlet once per frame - they each complete one frame's worth of changes and then switch back to the main task. As a result each effect is a very simple method wrapped in a greenlet - something like this:




So each time we switch to the g_tile greenlet, it runs through one iteration of the animation and switches back to it's parent.

This is a pretty trivial example, but as the animation effects get more complicated the advantages of wrapping them in greenlets will get steadily greater. This style of programming also has the potential to make network and UI code more elegant too. I'm pretty excited about how handy this library is - we'll see if it introduces any interesting coding problems...