One of the coolest innovations I have seen in recent times is Swiftkey Flow. This is a keyboard input method that is geared towards touchscreen devices, where the user enters text by sliding a finger across the letters of the word to be input. With a little help from predictive technology, this method is simple, accurate, fast and intuitive.
On a Samsung Galaxy Note 2, you can enable this on the “Samsung Keyboard” through the “Settings” menu. If you’ve also setup one-handed operations (the keyboard moves over closer to one side) you could be typing long letters or blog posts with just your thumb and your brain for hours.
Compared to other forms of input such as voice, what makes this so compelling is how easy and seamless it is to handle errors. With dictation, there are bound to be mistakes unless you continually keep looking at the screen to see what gets typed (which you wouldn’t want to be doing if you were talking). With the onscreen keyboard, it is completely intuitive to pay attention to the words you have input, and switch back to conventional typing temporarily when there are errors. It doesn’t hurt that Swiftkey normally figures out the right words to enter without the user having to try too hard, so errors are much less frequent. (This normally happens when you hesitate while spelling out the word.)
Now that this site is hosted on my own server, I wanted ensure that the server is up and running most of the time. Although five 9’s is not my availability target, I needed some mechanism by which changes and updates that I made to the site were not reflected in the production website (can I call it that?) until the right time.
The solution is a simple one: run a development website in parallel, so that all changes can be tested on that first. Updating the primary website would be like flipping a switch. Here’s how I managed this:
Set up a new virtual host for the development site.
Set up a new database for the development site and populate it with existing records.
Update the WordPress configuration file to select a different database based on the current working directory.
Set up server authentication for the development website.
Write an initscript to copy (rsync) all the files from the development site to the primary one. Exclude the authentication files like htpasswd, of course.
Set up a dependency on the new script in Apache, so that restarting the service also restarts Apache (this is useful at times).
It’s amazing how much can be achieved with the help of a few scripts. If you come to think of it, scripts are the original mashups that Web 2.0 has venerated in recent times.
Today, I decided that I would have a “Now Listening” box shown on my blog — I’m not sure if it is visible at this moment — which would display the name of the artist of the currently playing track on my computer. So here’s what I came up with -
A Bash script that would use DCOP to query Amarok, determine the currently playing song, and update a temporary file accordingly.
A small PHP script that would read the file and display this information, but only if it is available.
A set of CSS rules to format the generated XHTML.
I know that the title of this post sounds like an election slogan, but that’s not what this is all about. This change is all about domain names and CNAME records, but I won’t say too much about it. The bottom-line is that I decided to host this site on my own server, rather than on a shared webhost, and with that change, I also decided to start the blog afresh. You may rest assured that this had nothing to do with being too lazy to port the old blog to a new location, but you’re not going to believe me are you?
If the site seems to be too slow to load, please leave me a message and I will urge my server to work harder. Don’t worry, it listens to me.