Entries from 2010
Requiring SSL Using Route Constraints in Rails 3
The new router in Rails 3 makes it super easy to require SSL for certain routes. Just use the following in your config/routes.rb:
MyApp::Application.routes.draw do
class SslConstraint
def self.matches?(request)
request.ssl?
end
end
scope :constraints => SslConstraint do
resources :payments
# Other SSL routes go in here
end
end
Now, this is a pretty simple example–you’ll likely want to also have routes to redirect if a user tries to access without SSL, but it definitely shows off the power of the new router.
Using Git Branches as Patches
At Viddler, we’re now using Git for projects, and it’s going really well so far. While we haven’t figured out the perfect workflow just yet, we’re doing some things I really like, and one of them is treating branches like patches.
Often, people think of Git branches as a full copy of the parent branch, but it’s better to treat them as a simple collection of new commits, to be applied to the parent branch later. This might not seem too revolutionary, but this small change in thinking can really improve your workflow.
For example, at Viddler we use Trac to manage tickets, and in Git. For each ticket in Trac, we create a branch, called something like 3241-fix-embed-codes. We have two permanent branches: dev, which reflects current development, and master, which is considered always production-ready. So, dev and master are going to have different code to reflect their reflective stability. To get started with a fix, we first create a feature branch from master:
git checkout -b 3241-fix-embed-codes master
This simply creates a new branch of master called 3241-fix-embed-codes and checks it out. When the ticket is completed and the code has been committed, the patch thinking really comes into play. Since this now needs to be tested in the dev environment, the branch first gets applied to the dev branch:
git checkout dev
git merge —no-ff 3241-fix-embed-codes
Using the —no-ff option on git merge is important for this patch mindset: it creates a separate commit for the merge itself, which allows you to git revert the entire thing (if necessary), rather than having to undo each individual commit within it.
Once we’ve decided this fix is read for production, it’s time to move the code over to master. Without the patch mindset, you might consider merging dev into master, but that means you’d be copying anything that’s applied to dev, some of which might not yet be ready. When you think of your feature branch as a patch, however, it’s easy to only apply the one you need. To apply this patch to master, just use a similar method as before:
git checkout master
git merge --no-ff 3241-fix-embed-codes
Now you’ve only moved the safe commits over, leaving any buggy code safely in dev.
This method may seem obvious, but the mindset has really changed the way I use Git, and I think it makes it a much more powerful tool, especially when you’re working across multiple environments (like production and staging). I’ve skipped over some additional considerations, like merging master/dev into your feature branch, but those are topics for a future post.
Introducing node-xml2object
Recently, I’ve been playing around with node.js, because, well, it’s really, really cool. I found myself wanting to parse XML into a Javascript object, but I couldn’t find any existing modules that did what I needed. So, I went ahead and made my own, node-xml2object. It’s dead simple to use, and I hope others find it as useful as I have. For example, imagine you have some XML like this:
<root>
<videos total="2">
<video id="1" length="20">
<title>Video 1</title>
</video>
<video>
<title>Video 2</title>
</video>
</videos>
</root>
Here’s how you would access it as an object, assuming the XML is stored in the variable xml:
var sys = require('sys'),
xml2object = require('./xml2object');
var response = xml2object.parseString(xml);
response.addCallback(function(obj) {
// To output a simple value, just use as an object
// Since there are 2 video elements under <videos>, it's stored as an array
sys.puts(obj.root.videos.video[1].title) // outputs "Video 2"
// attr(key) returns the value for attribute with name "key"
sys.puts(obj.root.videos.attr("total")) // outputs "2"
// attrs() returns an object of all attributes
sys.puts(obj.root.videos.video[0].attrs().id); // outputs "1"
});
Node-xml2object depends on the node-xml module, and the tests use ntest. Right now, I’m embedding them as Git submodules, but I’m planning on changing that in the near future, since it’s pretty messy this way. The source code is licensed under the MIT license, so feel free to use it however you’d like. I’m pretty happy with where it’s at now, but if anyone would like to fork it and improve things, go for it!
iPad Keyboard Fragmentation
As usual, I enjoyed reading John Gruber’s musings on the iPad. I was intrigued most, however, by his thoughts on the iPad’s support for hardware keyboards:
Having used the hardware keyboard yesterday, though, it is clearly a secondary form of input. You cannot even vaguely drive the iPad interface by keyboard alone. […] There are some glaring holes. For example, in iPad Mail, when you start typing in the To: field to address a message, and the iPhone-style autocomplete suggestion list appears under the field, you cannot select from it using the keyboard. You have to touch the screen. […] It just seems like it’s not finished yet.
What struck me as interesting is how similar this is to Android development’s biggest drawback: hardware fragmentation. Due to the vast array of Android devices, app developers have to consciously design their apps to support several different input methods. This may seem fairly trivial, but it is actually a fairly significant problem, especially for games and more complex UIs. In the Android Market, some games and applications just don’t work without a hardware keyboard, likely because the app developer didn’t take the time to consider touchscreen input. Apple seems to now be encountering this problem as well.
Maybe John’s right, and this is a rough edge that will be smoothed over when the device launches. But, there’s more to it than just fixing iPad Mail. What about the 140,000 apps in the App Store? They certainly weren’t built with any considerations of keyboard navigation, so the experience is likely to be sub-par, unless the developer has taken the time to support an input method that he or she might not even have access to (assuming he or she doesn’t own an iPad).
If keyboard support is solely intended for text input, as John suggests, a lot of users will be confused. Standard operations, such as tabbing between fields and navigating via arrow keys, are expected behavior when a user is given a keyboard. It would be frustrating to have that taken away. Certainly, Apple could fix this issue by the time the iPad hits the market, but for a platform that preaches ease-of-development due to the uniformity of its hardware, it’ll be interesting to see how it’s handled.
Three Weeks with Swype
Roughly three weeks ago, I stumbled across the Swype for Android preview. My first impressions were very positive, and over the last three weeks, I’ve been using Swype exclusively on my Droid. If you’re not familiar with Swype, it’s a new method of typing on a touchscreen device, from the inventor of T9. Instead of tapping out each letter, you just drag your finger across the keyboard, hitting each of the letters in the word in sequence. I recorded a short video showing its basic features:
What I Liked
What really surprised me about Swype was how quickly I was able to get the hang of it. When I watched demo videos, it seemed like it was overly-complicated, but once I used it myself, I couldn’t believe how simple it was. For some of the less intuitive features (such as capitalization, which requires you swipe above the keyboard), I had to run through the built-in tutorial, but after that, I could swipe very easily. One big perk with Swype is that it’s actually pretty easy to use without looking, once you get the hang of it. I found that I could type reasonably well without ever looking at my fingers, something I would have no chance of doing with the standard keyboard.
Drawbacks
My biggest gripe with Swype is it’s just nowhere near as polished as the built-in keyboard. For starters, it’s much more difficult to access symbols, and numbers are laid out pretty strangely. Also, there’s a complete lack on auto-completion for text fields that support it. For instance, if you’re typing the name of a contact in landscape view, the regular Android keyboard will have suggestions below the field that will allow you to select the person without typing their whole name. Swype does not seem to support this at all, which is really pretty annoying. In addition, it’s difficult to type out words normally, if they do not exist in the Swype dictionary. When tapping out letters, Swype tends to interpret your taps as swipes, adding unnecessary spaces between letters. Once you type an unknown word the first time, however, you never have to do it again, because it gets added to the dictionary, which is pretty nice.
In addition, I’ve found that the sensitivity of the keyboard can be a little strange when swiping quickly. Many times, it won’t recognize that you’ve stopped a word and started a new one (which is indicated by lifting your finger up), so it won’t recognize what you’re trying to input at all. In the options panel, there are ways to adjust the sensitivity, but I’d rather these settings were hidden away from users, because it seems like a bit of a cop-out. Swype should instead learn how you type, adjusting its algorithm as necessary.
Conclusions
While there certainly are some issues with the Swype build I used for this review, pretty much all of problems are fixable, and I’m excited to see what the final version turns out to be. They’ve got a really great concept that, with tweaking, could become the best way to input text on a touchscreen mobile device, especially for those who aren’t very adept with traditional on-screen keyboards. I’m not sure what Swype’s strategy is going be with regards to pricing: whether it will be a free app, or if you’ll have to pay for it. Personally, if they’re able to fix my issues above, I would be happy to pay $5-6 for it, and maybe even more, because it really is quite incredible. Even if you can type well with the standard keyboard, definitely give Swype a try.
A Geotagged Vacation
Over the holidays, my family and I took a three-day trip to Chicago, and because I had left my charger for my Canon Powershot G9 at home, I was stuck taking pictures with my Droid’s built-in camera. I thought it would turn out to be a disappointing endeavor, but it actually got me really excited about the future of internet connected cameras.
My least favorite part of photography has always been all of the work afterwards to get it online. I have to take out the SD card, copy the files to my computer, edit them, and then post them to Flickr. When I was taking photos with my Droid in Chicago, I loved how easy it was to instantly post photos online. Using Twidroid, I was able to easily upload photos to yFrog, tweet the link, and have it all geotagged, almost instantly. It allowed me to share what I was doing with my friends as I was doing it, something I could never do with my G9.
The quality of the photos certainly isn’t anywhere near what I could accomplish with a better camera, but that really didn’t bother me too much. As the quality of phone cameras improves, this will become less and less of an issue. Since I had a limited amount of time in the city, I was more concerned with sharing snapshots of where I was (like at the “Bean”) than with creating works of art. On a longer trip, where I have the ability to take my time and set up shots, I’m sure I would want to have a nicer camera along, but for a quick 2.5-day trip to Chicago, my phone worked pretty well.
There are certainly areas where this method of taking photos could improve, however. Like I said before, the quality of the camera is a drawback, but it was one I was willing to accept. Beyond that, I was a little disappointed by the geotagging abilities of Twidroid. If I took a picture of something inside (like the Apollo 8 command module, cool!), the coordinates would be way off, since it couldn’t get a good GPS signal. I would have preferred to be able to pick the Museum of Science and Industry as my location, rather than relying on what the GPS picked out for me. This is something that appears it would be relatively simple to fix. The Google Maps 4 Twidroid source code is available online, so I might try and update it myself to use places (using Google’s local search API or something similar), or at the very least it could allow you to check back into a previous location. I am also hoping Twitter releases more features related to geotagging on their site. Right now, coordinates are only visible through the API, so unless you’re viewing my tweets in a geo-enabled Twitter client, you won’t see my location.
I certainly could use a service such as Brightkite to fix some of the issues above, but I really want to stick to just using Twitter. It’s become clear to me that Brightkite really isn’t pushing the envelope any more as a service, and there really is little incentive to post there. I definitely agree with Colin Devroe that their future should be to act as a Twitter client, rather than as their own community, since I really don’t see them being very successful otherwise.
Clearly, the future is bright for geotagging, and I can’t wait for the day when I can have a high-quality camera in my pocket that allows me to do everything my Droid does on vacation. While I’m not someone who likes broadcasting my location constantly, it’s a nice ability to have while travelling, to both share your trip with others, and to be able to look back at what you did. Hopefully the tools will continue to improve, and they’ll be more and more universal, because I think this is something everyone could enjoy.