A few weeks ago HP/Palm began a free developer device program for developers with apps in their catalog. I figured that I might as well apply since I have an app, ‘grpn’, in their catalog. Who knew, maybe I would get lucky and get another free device (I am previewing a ChromeOS netbook as well). A few weeks (and forms) later, a brand new developer unlocked Pre2 showed up at my door.
Hardware
At first glance the Pre2 is a lot like the original Pre, but a few things are definitely improved. First up the screen is now glass instead of plastic, this not only feels better to the touch, but looks much sleeker too. Second, the sliding mechanism feels much improved, it slides quite effortlessly without the feeling like I’m going to break something. Finally the keyboard is feels improved as well, it feels a bit more ‘clicky’ than the original Pre. The only real downside that I see to the hardware is that it just feels outdated. The internals on the phone are last years’ specs and the phone feels quite ‘thick’. I actually think it is thicker than my original Pre (not by much).
Setup
The Pre2 came with WebOS 2.0 on it, before even turning the device on I made sure to use a WebOS 2.1 doctor to update it. This went along fine without any hitches, just plugged in the phone and ran the doctor. It should be noted that I did have some problems getting the device up and running once WebOS 2.1 was installed. The device is looking for a sim card and HP/Palms instructions on how to get around this problem, while good, did not work exactly as instructed. The instructions ask you to run a tool called “devicetool.jar” which unfortunately does not work out of the box for WebOS 2.1. It is missing a file which you have to manually append to the .jar file from the last 2.1 doctor. Instructions for how to do this can be found here.
Software
After finally getting the device up and running, I am now in WebOS 2.1 and it looks pretty great. The launcher is much improved, you can now have more than 3 pages of app screens as well as the ability to name them. Card stacks are pretty cool, and the device itself just feels zippy. I haven’t had a chance to try out much, and because the device is developer unlocked I cannot get access to the app catalog. I did install Preware ASAP to get some additional software on the device. I will try out exhibition mode on my touchstone later today and maybe the voice features as well.
Conclusion
The Pre2 is a pretty nice device, it probably should have been released a year ago (on Sprint where most Pre users are, like me). Had they done this I totally would have upgraded. Alas, I don’t think it is that great a device for “today”. The Pre 3, with an increased screen size, faster processor, and hopefully overall thinner device will make a competitive phone for HP/Palm (if they ever release it).
One of the problems that I hit with django-piston recently was that I needed to support more than a single type of authentication for my REST API. In one case I needed an authentication handler that authenticated against the the Django auth system itself so that I could use the API to dynamically populate choice fields on the fly using the currently logged in website user. An implementation of a DjangoAuthentication piston module can be found here. The other type of auth handler I needed was the HttpBasicAuthentication (built into piston) handler so that 3rd party tools could access the exact same API that the website was using.
Django-Piston does not by default allow more than one authentication system to work together out of the box, so the following is a quick and dirty implementation of piston authentication handler that authenticates using a list of different auth modules:
class MultiAuthentication(object):
""" Authenticated Django-Piston against multiple types of authentication """
def __init__(self, auth_types):
""" Takes a list of authenication objects to try against, the default
authentication type to try is the first in the list. """
self.auth_types = auth_types
self.selected_auth = auth_types[0]
def is_authenticated(self, request):
""" Try each authentication type in order and use the first that succeeds """
authenticated = False
for auth in self.auth_types:
authenticated = auth.is_authenticated(request)
if authenticated:
selected_auth = auth
break
return authenticated
def challenge(self):
""" Return the challenge for whatever the selected auth type is (or the default
auth type which is the first in the list)"""
return self.selected_auth.challenge()
The way this works is that you pass in a list of different authentication types to the MultiAuthentication constructor which you want to test against. The first item in the list is considered the ‘default’. When authentication each auth module in the list is tried in order until one succeeds or they all fail. If each method fails then the ‘default’ challenge will be returned to the user. Example usage:
from piston.authentication import HttpBasicAuthentication
from somewhere.else import DjangoAuthentication
# Authenticate against HttpBasic and then Django if basic fails. If both
# methods fail, ask the user for username/password via HttpBasic
basicAuth = HttpBasicAuthentication(realm="Test")
djangoAuth = DjangoAuthentication()
auth = MultiAuthentication([basicAuth, djangoAuth])
This is available in gist form at https://gist.github.com/790222
And here we are again, a new year, a new website. I have always been terrible about keeping my website up to date so this year I have tried to simplify things a bit. For starters I have ditched my old Django-powered website which, while fun to build, can be a bit annoying to maintain. I had to keep up with the code, the hosting, backups, and content.
Since I have been moving more and more of my personal code to GitHub, I figured that I should try out GitHub Pages and Jekyll for my website. After about 24 hours I can say that I’m pretty happy with GitHub Pages and the Jekyll website engine. The thing that I like the most is that all of the posts are version controlled on GitHub itself, no mucking around with a database… very nice.
Eventually I plan on building a feed aggregator which will combine my Twitter, GitHub, and other feeds into one convenient location. We’ll see if I can do this using nothing but JavaScript. Such is the price paid for hosting the site on GitHub pages which doesn’t provide much in the way of server side programming. I also wanted to give a shout out to HTML5 Boilerplate, a very cool foundation for starting out a HTML5 website (oh yeah, giving HTML5 a try here).
