Technical Ramblings

This weekend, I built a moderately functional web app. I’ve done this before, of course — I used to work in web development back in The Before Times — but this is only the second app I’ve built in 5-6 years, and it included some new things I haven’t done before! So, in no particular order, here are some things I learned. (Many of these things may have been true for a decade or more; that doesn’t mean that I didn’t just learn them!)

• If you intend to do anything with media queries, it seems that the common knowledge is that you *must* include a specific viewport meta tag: <meta name="viewport" content="width=device-width, initial-scale=1.0"/>. Without this, things work fine on desktop browsers, but fail on mobile browsers. This does not make sense to me, but there it is. (Thankfully, they at least also fail in Chrome’s mobile device inspector mode, so it’s actually possible to debug.)
• mod_wsgi has a python-home directive that allows you to specify the virtualenv that you would like to use to run your particular application. This is useful if you are using virtualenv to package up your dependencies; it means that you don’t have to mess about with weird path includes in order to get your virtualenv working in your Apache webserver.
• localStorage seems to work by default across major browsers at this point. This means that I was able to store information locally without any magical … anything. For minimizing server-side storage entirely, this seems cool and good to know. localStorage is available in the default Javascript scope, and has two functions: getItem('key') and setItem('key', 'value').
• If you have a div with contenteditable set, by default it appears to have a height in Safari and Chrome, but not in Firefox; so make sure you set a min-height on the element in Firefox.
• CSS flexbox support has been available in every major browser for years. This means that you can actually horizontally and vertically position elements without using tables. This is amazing to me. (In fact, out of desparation, I briefly attempted to use a <table>, only to find it screwed up my layout more — and that CSS flexbox was *easier* than using a table for what I wanted.) This is pretty amazing to me.
• If you are using a contenteditable field, then the following will ensure that when you paste into the field, it is pasted using plain text. (This is necessary in Safari; not in Chrome, not sure about other browsers.) I haven’t thoroughly tested how cross-platform this snippet is.
  

  document.getElementById('input').addEventListener("paste", function(e) {
// cancel paste
e.preventDefault();

  // get text representation of clipboard
  var text = (event.originalEvent || event).clipboardData.getData('text/plain');

  // insert text manually
document.execCommand("insertHTML", false, text);
});

• pusher.com is a quick way to get support for a moderate size of websocket connections (100 active connections; 200,000 daily messages) supported by a wide variety of push + receive client libraries, with almost no work. It honestly feels a little bit like magic; as someone who had been putting things off specifically because of the pain that is *either* polling or running a websocket service, this was really quite nice to see. Also supports posting out received messages via webhooks for clients that might want that instead of websockets. I expect that if I ever reach that level of scale, I’ll probably just set up my own websocket server rather than pay the $50/month for the next tier, but for a getting started, this was really useful. I started with this guide on building a chat app in Javascript and found that it was easy to get started with and to modify, since it only has around 30-50 lines of code.
• I probably need to bite the bullet and start moving towards Python3, even though I don’t really care about it. This is annoying as my gap of 3-5 years since I built new apps has left my server environments atrophied and weak.
• People really prefer a “dark” theme to a light theme in the social spaces that I run in. (I’m surprised that Facebook doesn’t have a dark mode yet.)
• Modern browsers continue to change constraints — on things like autoplaying videos, third-party cookie restrictions — in ways that are likely good for privacy and user experience, but break older apps without much way to fix it and with user control over those changes minimized. Old apps that worked fine are now non-functional because of these restrictions.
• If you try to copy a virtualenv from a different machine, you get *weird* behaviors. Also, if you’re creating a virtualenv, the first thing you want to do is probably upgrade pip. (Turns out that when the pip you’re using doesn’t support modern dependency descriptors, you also get really weird failure modes!)
• I really miss the handiness of Google’s auto-formatting facilities when writing code. Everything I’ve written this weekend is indented poorly, and it’s frustrating.

Anyway, starting around midnight on Sunday until early Monday morning, I built myself an app; it includes synchronized viewing of YouTube playlists, plus a completely built-from-scratch chat app that is moderately functional and improves in a lot of ways over YouTube chat for the use case I have. I built media queries that let the UI actually work on a mobile device, and it actually looks halfway decent. I didn’t have to use much in the way of browser-specific hacks (modulo comment on min-height in Firefox).

That’s a pretty cool experience.

I made a post over on the MetaCarta Labs blog about doing geographic queries on App Engine:

???????? ????? ????????In this way, I was able to put together a geographic bounding box query, on top of Google App Engine, using a Geohash-like algorithm as a storage format, and use that query to power a FeatureServer Demo App Engine application, doing geographic queries of non-point features on top of App Engine/BigTable. Simply create a Geoindex object of the bounding box of your feature, and then use lower-left/upper-right points as bounds for your Geohash when querying.

— Geographic Queries on Google App Engine

Probably of interest to some of the people who read this.

My first attempt to do something useful with IronPython:

>>> import urllib
>>> urllib.urlopen("http://crschmidt.net/")
Traceback (most recent call last):
  File httplib, line unknown, in getreply
  File httplib, line unknown, in getresponse
  File httplib, line unknown, in __init__
  File System, line unknown, in set_ReceiveBufferSize
  File System, line unknown, in SetSocketOption
WindowsError: Invalid arguments

Note that I’m working on OS X, and my exception is a WindowsError. Fancy.

(I was inspired by Bill Thorp’s efforts to get TileCache working on IronPython: Round 1, Round 2. However, I’m not all that inspired now.)

Still, it is kind of cool that IronPython just ran — I didn’t expect that to work. Maybe there’s something to this mono business after all.

It’s cool when software works.

So, I needed to test the latest TileCache in Windows. I’ve got a relatively clean Windows laptop I keep around for this. None of the niceties that I would typically want on a machine I used full time — no Firefox, no cygwin, no vim, etc. Just a straight up Windows install, with things like Google Earth installed.

So, starting from that, I started by downloading Apache from the Apache Download Page. I downloaded “Win32 Binary (MSI Installer): apache_2.2.4-win32-x86-no_ssl.msi“, and ran the installer directly. This got http://localhost/ serving a page that says “It works!”.

Next, I downloaded the Python 2.5 Windows installer , and again selected all the defaults.

Next, I downloaded TileCache 1.4, as a .zip file, since I know how well Windows supports .tar.gz files. I extracted the zip file into C:\Program Files\Apache Software Foundation\Apache2.2\cgi-bin.

Lastly, I edited C:\Program Files\Apache Software Foundation\Apache2.2\cgi-bin\tilecache-1.4\tilecache.cgi so that the first line of the file read “#!C:/Python25/python.exe -u”, and visited http://localhost/cgi-bin/tilecache-1.4/tilecache.cgi/1.0.0/basic/0/0/0.png …

And it worked! I got an image. I never expected setting up Apache, Python, and TileCache to just… well… work.

Wow, I’d never used the optparse module before. That’s pretty damn cool. (And to think I came close to writing my own option parser for a bit before I looked up the documentation.) The automatic addition of –help output is super-cool too. I definitely need to start using this in more of my code.

Hooray for Python!

Whenever I’m about to do something with the Python Regular Expression module, I immediately google “amk python re”, which leads me to A.M. Kuchling’s RE HOWTO. I can’t think of anything that I would find useful with regular expressions that is not covered in this document, and I highly encourage you to use it as a reference when you think you might find it handy.

Julie’s at home these days – since we found out she’s deaf in one ear, we pulled her out of school to do more one-on-one learning at home.

She’s good at associating words with the visual representation of the letter – she’ll see “S”, and say “That’s what Sienna’s name starts with!” – but bad at names of letters. So, I hacked up a quick wxPython script from the wxPython samples that will just show an uppercase and lowercase letter, which she can click through. It’s basically a quick-and-dirty flashcard program: source available, of course.

Because I wanted to track her progress, I hacked up a little Ning App to track her learning. As of today, she only recognizes J (for Julie) and X on the first try. So, we’ll track it and see how she does. LearningLetters. 20 minute app, probably less. It’s crude, but it works.

It’s easy to make this work for just about anything you want to track. Just modify the ‘choices’ array.

I said a while ago that the coolest part of Ning was the content store. I’m now working on a proof of concept to prove it.

So, there’s a bunch of Roshambo (Rock Scissors Paper) apps. Or at least a couple. Or at least two: Roshambo and Fifteen, my personal 15-option version.

So, I know that I’ve played a handful of games, and don’t want to scroll back through them. The app itself doesn’t offer an API itself, so there’s no easy way to get the data out, and I hate screenscraping.

So, I built a query app. XQuery. The homepage kind of documents what it can do so far, but it’s nowhere near done. It was just a one hour hack. Then I built the Roshambo Results Viewer. I also then extracted the logic into a simple Roshambo Python Script — usage ‘python roshambo.py crschmidt’.

Expect more to come of this.

Today, there are a large number of cheap bluetooth GPS devices on the market. These devices allow you to connect to the device wirelessly, which is great for when you’re driving and don’t want cables draped all over the car.

However, what happens when you can’t drag your computer out to act as a display of your position? No bluetooth GPS on the market today for under $500 has a display of any kind. When you consider that these things can be had for $70, that makes purchasing one go from likely, to ridiculous. What’s the point of a handheld, easy to use GPS if you can’t use it to see where you are?

If you’ve been asking this question, I’ve got software which has an answer for you. GPSDisplay will allow you to connect to NMEA compatible Bluetooth GPS devices and display your position fix. It is written entirely in Python, using NMEA code from Forum Nokia. It requires only that you first install Python for Series 60 on your device, and should work on all first and second generation Series 60 phones. Simply download the .sis file, send it to your phone, and you’ll be all set to go — you can use your phone as a display for that new cheap Bluetooth GPS you bought, and stop dragging your laptop out into the woods to go Geocaching.

In my spare time (hah!) I’ve been hacking on an app on Ning, called PeopleFinder. The goal is to be a geolocation app, supporting a variety of things social. One of my many goals for a long time has been to create and use some kind of tool which allows me to generate MeNow data with no effort.

I’ve finally got it.

With the help of Geocoder, I can now type in an address, and have it automatically update my location on the website, including showing my position on a GMaps interface. The PeopleFinder API is still a bit weak, but using it, I can write a Client for Series 60 Python, which allows you to update via a GPS lat and long, or via an address.

I’ve created a token system for authentication via the API — when logged in, you simply hit the token link, grab the token, and put it into the client (in the “token” variable).

Eventually, once I write the functionality, it is my hope that I will be able to provide more features via this API — the ability to look for people nearby you, get their information, send them messages, and so on. However, right now this is just a 2-3 hour hack, and I’ve got piles of work to do – but this is so cool I had to share it.

As far as I know, this is the first example of a Ning App exporting a semi-usable API to remote clients. In part, this may be due to previous limitations on Ning’s end which have recently been resolved: looking at the phone client code, you’ll see the ?xn_auth=no parameter, which allows you to skip cookie authentication. It’s a pretty nice solution to the problem in my opinion — it solves what I need while not interfering with the rest of Ning.

So grab your phone, grab a client, and update your address on the go — then, the next time I see you in the neighborhood, I’ll drop by and give you a wave.