Technical Ramblings

Matt Croyden mentioned the other day that there is a new Python for Series 60 Alpha release. Reading through Erik Smartt’s post on the topic, I realized that this offers a number of the features that I had wanted built in in the original release: Camera access, Address Book and Contact APIs, and other similar things.

I had put off working on Symbian Python work for a while, but with the new release, I think I’m going to put some more effort into it: use of the new APIs will make things easier (like automatically uploading pictures taken to flickr, one of my original goals) and makes me want to get hacking again.

Congratulations to the Python-on-Symbian team, and I’m looking forward to starting work with the new alpha release.

Since I’ve gotten a couple people asking about it – my application for my phone to post to flickr has a basic shell built, and works, but I’m llooking to add a few more features and make it more user friendly before I post the code for you all to use.

Featureset right now:
* Ability to store options, including default tags, username, password, and security
* Browsing through filesystem in a filebrowser and selecting a photo to upload
* Uploading a photo, and adding additional tags to the defaults

Other Features that I want to implement:
* Actually respecting the security that’s stored.
* Uploading more than one image at a time
* Less confusing interface.

So, it’s still on my todo list, and I’m going to continue to work on it, it just hasn’t gotten done yet. Mostly because I’ve been too busy reading Snow Crash.

One thing I’m not sure if people want to do is type in a title and description for the image while uploading the image. I don’t have any t9 enabled input boxes that are easy to use. So, it’s a question of whether I want to use the more difficult (and possibly confusing) Form box, or if I want to just skip it for the time being.

Actually, now that I think about it, the appuifw.Form wouldn’t be as bad of a way to go as I thought it would be… Hm. Will have to check that out.

Wombat takes charge : learning how easy it is to work with location stuff in Python, he starts work on a project that sounds a lot like the work I’ve started on locative stuff. Looks like I need to get back to that…

As FrankK reports, Darla will record an orgasm ringtone if she gets requests on her blog for one. Think she’ll follow through? I’m interested in finding out.

Flickr stuff is close to done. I’ve got a user interface put together, using code stolen from the included file browser provided by Nokia. You can browse through, select a picture to upload, and upload it, using the given tags, security, and stored username/password. It’s not ready for prime time yet, because I want to set up a way to do multiple uploads at once. I’d also like to be able to type in titles/descriptions, but the limitations of the UI widgets available blocked me there. I don’t have anything that I can type t9 into with ease, so getting the data out would be a pain. Is it so much to ask for a t9 enabled appuifw.query window?

Jess asked me yesterday if I’ll ever make any money hacking these things together. My answer is probably not: I don’t like the idea of charging people money for something. I’ve never even asked for donations, because I just think it’s not fair to expect people to pay me for the work I do. Despite this, if anyone wants to offer me money to do what I’m doing, I’d be glad to take it. I really need to move this stuff to a server that isn’t hosted in a house with four cats running around: they have a tendancy to pull out the ethernet cable nightly, which means downtime for everyone.

I’m looking to move stuff soon, I’ve had my eyes on one of the Sagonet bargain servers for a while. (The reason I’m going for my own box rather than a virtual box type solution is memory based: I want to run julie off a different machine than my own, and that requires me to use a hell of a lot more memory than any virtual hosting solution I’ve yet found.) The price is good, it’s just that initial extra setup fee that’s putting me off.

However, every day that goes by is another day that I realize I really just need to move stuff and be done with it. Waking up every morning and having to restart my menagerie of bots is getting old. I want something stable.

Is anyone looking for hosting? $10/ a month, and I’ll do all the work to install anything you want! 🙂

I’ve worked out how to post images to flickr using HTTPlib and Python from the flickrup source code. I have no idea if this is the best way to do it, but it seems to work, so I’m writing an application to surround it in a UI. In the process, I’m creating a pretty generalized application framework that I should be able to use on some of my other applications. So, I’m enjoying that.

Some things that it’s done so far:
* Established a couple generalized option configuration methods, which let me load and save from a file
* Created what i hope is a UI for changing those options (which will change per-app)
* Added in some general stuff to make sure the UI works, like locks to make sure the application doesn’t just quit

I’m probably not going to release the framework on its own, at least not until I come out with the Flickr app that I’m writing it for, simply because I’m writing the functions as I go along. If it ends up being worthwhile and reusable enough, I may list it seperately on my page of Symbian Projects.

I think that this could be really fun for me to play with, and I hope I get it working soon, because it seems like a cool application idea. The basic idea behind it is to combine the filebrowser code that is included with the examples in the distribution with a flickr uploading option, as well as the option to view the images. Granted, I can’t do anything other than open them in the default viewer right now, but then at least people can see what they’re getting into.

I’m starting to get to the point where I could see how having a bit more advanced symbian UI widgets would be helpful: something like Putty’s menu, where things can actually be in submenus and the like. I can also see how it’d be way more difficult to code, so I’m not lamenting the lack, just noticing it more than I used to as I get into more and more complex applications. One thing that I have learned is that the Text widget makes a really good way to keep messages and so on on the screen without any complex threading or anything, which is nice. Little things like a progress bar (which seems to be underway) might still be nice though.

Just some random meandering thoughts while I’m writing. Hopefully by the end of the week I’ll have an app at least starting to take shape for Flickr, and maybe I can devote some more time to the traffic cam project too.

When I got back into the mobile world recently, with a couple of apps I wrote and hanging out in the #mobitopia IRC channel again, I wondered why there wasn’t any central aggregation for the mobile world. The Semantic Web has PlanetRDF, and there are more than a dozen other similar aggregation services for different portions of the web, from Apache to Gnome to Adium. Despite the large weblogging community surrounding the Mobile world, however, there was no similar aggregation.

I say was, because there is now. PlanetMobile is an aggregator for all things mobile related. It features posts from a variety of sources, from Engadget to the mobile platform category on my weblog. It also shows the recent flickr images tagged with “mobile”, as well as the latest posts from both del.icio.us and Technorati, all aggregated in a handy little sidebar.

The CSS is taken in large part from PlanetRDF, which has already gotten me some compliments (which I’ve suggested be forwarded onto the chaps). The Planet aggregator is running the whole shebang behind the show, along with the Magpie RSS Aggregator for the sidebar.

If you can think of another Mobile feed that should be added, I’d be interested in hearing from you. If you think that it’s a cool idea, and want one for your own specialty interest, also feel free to let me know. If you think that I’ve somehow impeded upon your copyright, also feel free to let me know. If you just think I’m a weirdo, I’m always open to that too.

Apparently, when the TrafficCam flash program was released, Justin was opening a can of worms that was bigger than I could have imagined.

After my example of quick development on the Python app, I got a lot of interest in my own TrafficCam application. Suddenly, there was a London version. And a Dubai version. And every time I mentioned it, someone else wanted to create their own version and load it in so that they could use the same nifty features. If there’s one thing that I do right, it’s listen to what my users are telling me. So, this afternoon, upon the arrival about my new Nokia 6600, I got to work.

First step: Build a file loader. This function should take a file of predefined format and read it in over the web, letting you specify some parameters to the program. This data should then be returned in a way that the application can use. We can’t make the file format too complex: the default Python install comes with no XML support, remember, so we’re using a very basic, tab delimited layout for this. The format is pretty simple: It’s described in the TrafficCam Format Documentation, for those of you who may want to use it.

Step two: Build the app around the data. Given a specific URL, construct the entire application setup, from the tabs to the title to listings, from that returned data. Not too hard: required a little bit of changing how I did things so that it could be reloaded easily, but as always, Python was cooperative.

Step Three: Build a frontend to choosing URLs to load data from. Store a title an a URI, and let people choose which to load. Not too bad: using the popup_menu that symbian provides, can easily associate the resulting choice with your earlier list.

Step Four: Add support for reloading. Once I’m done with one set of cameras, I want to view another without having to exit and restart. This is a bit more complex: it requires me to move some of the logic around so that the application flow stays mostly the same. In the end, I ended up cleaning up some ugly repetition of the code this way, which was useful.

Step Five: Make it more user friendly. Add an “Other” for choosing their own URLs, add progress meters and information boxes, put in exception support for when a URI doesn’t load correctly, and in general, make the app work better.

All in all, I spent six hours yesterday working on the application, and basically rewrote it from top to bottom. It’s now easy to use, and extendable to do whatever people want. I can admit that it’s probably the single most user-friendly application I’ve ever written: almost all my work in the past has been command line based, but this is truly a cool application.

If you have a phone which supports Python, I highly recommend this application. Although I’m sure there are better apps out there, this one is my personal favorite: lets you get a glimpse of the world through your phone. Of course, you should be aware that this is not a low bandwidth application: the camera listings are only about 3-4k apiece, but each camera image can be anywhere from 10-15k, sometimes more depending on the cameras you’re using. Yesterday, while doing development, I used up a megabyte of GPRS bandwidth – luckily, I have unlimited GPRS through my provider.

If you live in an area where there are traffic cameras, and you’d like to see them added, simply construct a file according to the format documentation, and drop me a line.

Have I mentioned lately that I love Python?

Now, to get working on that contact database export I had in mind…

Russ posted about a pretty cool Flash Lite application that was developed: a way to look at the NYC traffic cameras using your phone. It’s an extremely cool app – if I lived in New York, I’d buy Flash Lite just to be able to use that application. One thing that Russ mentioned was the development time for the project: 20 hours of development time, when something in Java would have been way larger.

Well, I’m a Python man, not a Flash man, so I can’t get much out of this yet. However, I do think it’s a cool use case: so I did a little research, found out where the data that the Flash app uses was coming from, and did a little hacking. The result? TrafficCam version 0.1, in Python. This little app took me 45 minutes to develop a fully functional prototype: this included taking the HTML from the NY Transportation site, building it into a Python file, creating a user interface, and downloading and displaying the image in the built in phone image viewer.

Not only did I do all this in 45 minutes, I did it without even having a phone to test with. Passing it off to the owner of a 6600 and a 6630, both say it works just fine, as is.

(Note that I think it probably doesn’t, but in ways that aren’t visible: There has been no testing done yet.)

So, although Flash is great for pretty apps – the Python app is *nothing* like the Flash app, which is a great user interface and something that’s really fun to use, even in a browser – but Python can be really great for *quick* apps, especially on the phone.

Update: With another 35 minutes of work, I now have fully functioning tabbed lists, one for each borough. So, with a total of less than an hour and a half of development, I have an application which allows you to download any of the traffic cam images and view them on your phone. It’s no flash, but I call that pretty damn impressive.

Around the time that Nokia Python was released, someone mentioned that it would be very interestig to see a replacement for the built in Nokia Notepad program. The Notepad program has many limitations: you can’t fit much text on a screen, there’s no easy way to browse or link notes you’ve written, all the typical limitations that you see when writing in a small paper notepad.

It was discussed that a small, wiki-like implementation might be a way to improve the usability of the notepad. Allow people to link between pages or nodes, let them type what they want and link it together. This would greatly improve the usability of having a phone along with you: if you can take notes on it that you can actually usee, there’s less chance you’ll lose them than paper, and you’re far more likely to be able to use something that’s connected than just write one note to yourself.

For a while, I didn’t develop anything on the phone, mostly due to technical issues related to my development process. However, after the recent Python SIG meeting, I decided that the next time I saw people, I wanted the phone to do something useful. So, I took on the challenge: a wiki-like scratchpad.

I started last night, and didn’t get too far before I ran into some symbian related problems: I couldn’t get anydbm to save anything. The file would open, it would stay open, but it wouldn’t sync, and it wouldn’t close. This morning, I finally looked at some code, and realized – wait. I need a full path. And once I got that far, things started looking up. In the hour I had this morning before work, I hacked out the basics: open a node, write to it, save, exit. Paavo on #mobitopia pointed out some other issues: the exit key handler, for one.

Then, over lunch, I created a webpage, and fleshed it out a bit more: adding a feature such that when you hit the action button, the word underneath the cursor is opened as a new node. This was about another two hours of work, spread over lunch and 10 minute breaks from work throughout the day. This included writing a program that catches keypresses and displays their associated keycodes, including learning a bit more about lambdas than I used to. I then had a working wikipad, and have since been adding minor cleanup tweaks.

In the past hour, I’ve created a beta, which allows uploading the wiki database to a webpage as POST data, from which it can be done with what you wish. (I’m currently storing the data in print_r() form, just for the sake of doing so.) From here, it’s pretty easy to imagine how this could allow reimporting the data.

So, the next step is, of course, making this work in a collaborative sense: allowing multiple people to edit one wiki via their phones. However, for the time being, it’s a great little scratchpad app, that’s only likely to get greater. You can get the code from the WikiPad Homepage.

Recently, a number of local Python users have assembled some form of organization, to the point that there is actually now relatively regular meetings of these groups of people (before other Linux Users Group gatherings, thus far). With the recent Nokia Python announcement, there’s been some renewed interest in my mobile python work, so I’m hopefully going to get some of that into shape over the weekend for a demonstration to the group on Monday, assuming I can make the meeting.

For those of you who have an interest in Python: What do you think would be interesting to a bunch of Python coders as a demonstration? Is there something that’s particularly spiffy that I could show off, or convert from being a command line application to being a cell phone application? Note thave I’m thinking relatively simply here: I only have a relatively limited memory space to work in, and I only have a small subset of modules to work with, and I’m in Python 2.2.

So, what do you see as being interesting topics/programs to demonstrate to the world the power of Python on the cell phone?

I’m really looking forward to getting together with a bunch of like-minded hackers, and racking their brains on what I can do better. I’ve never really had a good development process before, but Python developers seem to have one, especially the ones that I’ve seen discussing things on the mailing list. I’m used to LiveJournal’s spaghetti code, or writing in PHP which is typically not so well tested. It’ll be interesting to enter conversations with a group of more “formal” developers than myself.

Just looking for thoughts on what I should be working on.

Geolocation is the technique of determining a user’s geographic latitude, longitude and, by inference, city, region and nation. There are a number of ways to do this: one of the common ones discussed on the internet (according to a Google search for “geolocation”, as we all know Google is the Answer) is geolocation via IP address. The kind I’m interested in is much more accurate: geolocation via GPS device.

I want to be able to know where I am. I want this for a lot of reasons, most of them geeky rather than actually reasonable. However, it would be nice to offer more specific statistics on where my pictures are actually taken with fine grain granularity that a GPS can offer. Additionally, some of my alternative projects – cell based geolocation and the like – could benefit from actual coordinates on which to base everything from restaurant locations to searches. Openguides is, in particular, one area that could benefit from this.

I want something that works over bluetooth. My laptop and phone both speak bluetooth, and something with an actual display is out of my price range, for the most part, so I want something I can use my phone to get data out of. (USB / serial obviously doesn’t work for that.) From what I understand, most GPS devices which support NMEA are going to work okay for communication, as there are tools out there which support them. (Whether I can get the thing to talk over bluetooth is a different concern, but one I’m becoming more proficient at every day.)

For a long time, all I could find for Bluetooth GPS devices were 200-250 USD and up. However, while discussing it with someone in #mobitopia on Freenode, I found the Delorme Bluelogger, a Bluetooth GPS device for $150. Matt already posted about our discussion, but I hadn’t yet.

I have some cash left over from Christmas, and I know that I almost never actually buy anything for myself. So, I’m going to splurge, and I’m going to get it. I’m going to learn to use it, and I’m going to do all kinds of neat things with it. Plans include:

• GPS Annotation of Photos – This rolls into my photo annotation project, and is part of the reason I was keen to get it done: I want to actual have some fun queries for normal people (rather than just RDQL-aware people) over my photos.
• Location Based Description of things for Openguides – Describing where things are with GPS coordinates allows searches by distance. Once I have that, the guide allows more niftyness.
• Association of Cell IDs to Geo locations – Tied to the previous, this allows me to know where I am based on a Cell ID: Useful for “what’s nearby”, as well as useful for the general “where are you” that I like to be able to do – with just my cell phone.

All in all, some of the apps I have in mind seem nifty, some geeky, some just demonstrative of something bigger. Some are RDF related, some are just fun. The Bluelogger seems like a decent tool to achieve everything I need to.