It’s been running…
So for the curious, FoodTruckYP has actually been up and running for “public site tests” much like one might take a new food truck off external power and let it run self-contained while you make some food and drink and whatnot.
Guess what. We found some bugs here and there. That’s what that’s for.
Couple things got sorted out:
- Cookies, SSL, and logging in and out seem to work properly when switching between https and http versions of the site
- The twitter robot login stuff seems to work (OAuth is not my favorite thing in the world, as it turns out)
- Grabbing twitter images, there’s a small issue with blocked access to profiles when we grab the profile icon (this enables cross-branding easily without having to go find that image file when signing up from your mobile device).
- Short URLs… after some pondering, the short url is to be composed of the business name, the twitter handle, the facebook name, and the company name in url-friendly form (in other words, if the business name is “this is a food truck” then we would support “this-is-a-food-truck” and “thisisafoodtruck” which are basically identical. We lowercase-shift and punctuation-remove the shortened url part anyway.
- Found a DST issue that was just plain dumb. For the curious, we’ve gone with storing non-naive timestamps localized to UTC, along with the timezone (not the offset!. This way we can always account for DST and present localized times, but we can treat everything as UTC internally for things like the FoodTruckYP Robot to go wandering through timeslots and whatnot. Well, generating timeslots based on a recurrence rule that crossed over a DST boundary left the stored UTC timestamp off by that delta. Freshman mistake, really.
- Added titles for schedules and timeslots. This will make more sense in context.
- We’re going to support a cool thing that I will go into more detail about later, but let’s just say it’s icon-related.
- On the fence about whether OpenGraph meta headers should be a show-stopper for 0.9. I say no, can add them as we start getting some schedule data in. These will be most interesting, though, when people decide to share a timeslot on Facebook. Basically, each timeslot (that is, a mobile food vendor at a location during a window of time) will have a universally-unique URL to a page that can be shared, bookmarked, tweeted, and liked on Facebook. The Open Graph headers will make that work better for the Facebook part. This goes for business profile pages as well.
- Place pages… for now we’re only going to support display of food trucks that have indicated that they are at a particular place (venue) as well as those who are nearby. In other words, we’re aiming for discovery of nearby food trucks and carts. If this is not what people want we can tune things down to show only the vendors specifically at a place.
- Those are list-based considerations. When viewing a map, the map edges are a natural and visually-clear search boundary.
- Added support for geohash-based searches (in fact, that’s how generation of Place page lists work for the moment) so that it should be pretty easy to make an RSS feed or similar by trimming letters off of a geohash key. Experimental.
- Right now we have Menu Item support all good, but we still need to implement Menu Support. In other words, if somebody has 50 menu items, we don’t have the Menu grouping feature implemented yet. Well, not in the UI…
- Fuzzy Search works nicely, but still need to have the index writer running off on its own. We’re starting with Whoosh, for the curious, and the index writer isn’t thread safe. Weighing the use of the Async wrapper or just having a periodic indexer job run through updates. The goal here is to make all mobile food vendors findable by misspelled names (that’s for you, O Mi Ninja, nay Oh My Ninja, nay OMiNinja… and there are many others with similar non-obvious names). This will also apply to menu items and places as we get some input records.
There’s probably more. Pondering whether KML should be the publication format of choice. Sure, GeoRSS works as well and is basically a subset, but KML already supports timestamps and timespans, in addition to precise location information. Embedding a structured PostalAddress is easy… would others consume such data? Or are we just looking at Google Earth and Google Maps to consume these? (Well, we’re going to use the KML output for display on our maps, too…)
That’s all for the moment. It’s taken a while to get here, but things are really, really coming together now. Pretty exciting, actually.
