akrish

During this break, I’ve had a pretty hard to keeping myself occupied. I’ve been playing a lot of music and hanging out with my friends a lot, but I haven’t really been in touch with my nerdy programming self apart from this company that I’m working on. At the same time, my brother has been talking about this whole “viral” movement and we’ve been discussing strategies to get your product out to tons of users with minimal effort. One of the obvious solutions is to make a Facebook application which is immediately available to the however-many-million users there are on Facebook and is also easily spreadable via the invitation process. I decided that I too would jump on this all-too-techie bandwagon and make myself a Facebook application.

Over the summer, I was very against the whole Facebook platform movement (you can read about it here) and I’m still not really happy with a lot of things that I’ve heard about Facebook, but I made this app more for entertainment than for anything else. I’m also not very good at using client libraries and api’s and whatnot (I’m really impatient and don’t like to read things) so I figured this would give some practice at working with an api that I definitely needed for the success of my app.

I’ll cut to the chase. You should add this application. Now you may ask: what exactly is it? Well, it’s called Rumor Mill and essentially it’s a way for you to make up, or publicize rumors about your friends. It’ll also keep you up to date with all the latest rumors (real or not) about your friends and let you determine if the rumor is true or not. Once you make this judgment, it’ll show you what other people thought about the rumor. So, why should you add it? Well first of all, what’s the harm? It’s very unobtrusive; it takes no space on your profile page and it remains dormant until someone makes up a rumor about you, when you’ll get a mini-feed notification about aforementioned rumor. Secondly, it’s fun; who doesn’t enjoy make up random stories about your friends and seeing what other people think about them? I think that there’s tons of potential in this application and hope to see the subscriptions skyrocket in the near future.

In reality, I didn’t spend that much time making the application (Sunday and Monday) and I don’t really plan to spend much more fixing it or doing any other Facebook development. I kind of wanted to see what all the commotion about Facebook development was about. I thought I could see how popular it gets (you should add it! and use it!). I also want to switch hosting companies and this other company has a discount (it’s free) if you’re hosting a facebook app on your server.

Anyway that’s my little bit of publicity, add the Rumor Mill!

I’ve been working on voiTunes for a couple of months on and off and I’m finally done! I’m proud to say that it has impressed quite a few of my friends and I’m ready to release to the rest of the world (well, just the mac users). You can download it here. It will only work on Mac OS X, and possible Leopard (I have yet to test it on Leopard). If you have Windows, I’m sorry but you’ll have to wait until I port it (if I ever get around to it).

A few notes: I really enjoyed working on the widget, it turned out to be not too difficult but I wasn’t able to add all the functionality that I wanted mostly because I wanted to have something concretely released this week. I have almost working code that adds a couple more features but it’ll take me several more hours to integrate that nicely into the working widget. As a result, functionality is limited, but it still works and works decently well. Recognition isn’t that great, but that isn’t exactly my fault as I’m using a recognition engine for Carnegie Mellon.

Please post comments, criticisms (be harsh!), or any other feedback.

Last week, Yahoo! held a Hack day at my school, so my friend and I decided to participate/compete (there were some cool prizes). We made a little maps application that is accessible from both the web and via text messaging, but more on that later. First, what exactly is a Hack Day? So Yahoo! has been holding these events for a year (or a couple, I’m not really sure) and essentially they consist of one twenty-four hour session where you form teams and build something cool and useful. Yahoo! always provides food, entertainment and some help. In general they are really fun events for hackers. Most of the time the hacks are exactly that, very few of them turn into successful businesses.

University Hack Day’s are exactly the same thing. Yahoo! came to our school, had a couple talks about their API’s and about PHP, and then they let us form teams and hack away. We only had about 5 hours though, so in terms of technical complication, we couldn’t do anything spectacular.

My friend and I are pretty entrepreneurial-minded, and we always share ideas with each other. The application that we created is one of the ideas that we discussed some time in the spring, but we just never got around to working on it. In that sense the Hack Day was awesome, because it gave us time to crunch out a prototype, and it gave us more incentive to keep working on it. Apart from that, both of us think the idea is pretty useful, and I know for a fact that people have been wanting an app like this to be built.

The application that we built was a meeting place locater that finds locations closest to the middle of the parties involved. Currently it only supports two parties (inputted as addresses), but we plan to expand it to several. The user experience is as follows: the user inputs his/her address and his/her friends address and selects a type of place that they’d like to meet, and a map pops up with markers indicating locations in between the two addresses that match the search query. From the text-messaging interface, the user sends us a text message with the two addresses and location type and we send them back the address and phone number of the best result. It’s a pretty simple idea, but it’s something that we feel people would want to use in a variety of situations.

Technologically it was pretty simple. We used Yahoo!’s geocoding API to get latitude and longitude data and find the midpoint. Then we send a query to Yahoo! with the midpoint and the location type, and we get back data about the results that best match this query. Finally we plot all of this on a map. Naturally there are plenty of improvements that we can make here, but we didn’t have that much time, so we decided to keep it simple.

The text-messaging interface was really hack-y. Essentially, the text message is sent to a Gmail account, which gets routed to my Apple Mail.app on my locale machine. On my computer, I have an Applescript script to check my Mail.app inbox for new mail, and parse out the necessary data from it. I also have another Applescript script that takes in the data and sends an e-mail from Mail.app. (Both of these are fairly simple to code in Applescript, which is pretty awesome). Both of these scripts are wrapped in a PHP script that’s infinitely looping. The PHP script takes the info from the incoming e-mail and fetches data from Yahoo! (similar to the web interface). Then it calls the outgoing script. Clearly this implementation is pretty bad and obviously doesn’t scale, but it worked in our demo’s and that was really all that mattered.

The web interfaces is up and running and can be viewed at Ingapo. It’s called Ingapo which in Tamil (both my and my friends native language) means “go there.” Since the text messaging interface runs locally on my machine, I don’t keep it running. Also I’m pretty sure things will break if I receive and e-mail that’s not intended to be parsed by the scripts.

On the whole though, Hack day was fun and really worthwhile. I hope to attend some of the other ones (there’s one every year at Yahoo!’s headquarters) and in fact, the two of us may end up heading to Sunnyvale in the spring to participate there. It was also interesting to see some of the other ideas which were very cool as well.

What do you think of our idea? Do you think it would be useful?

It’s time to finally let the cat out of the bag. I announced about a month ago that I was working on a really cool project and now I’m finally going to talk about it. From the title, it’s pretty obvious that the project involves voice recognition and media libraries. Well, here we go!

I worked at a company called Tellme this summer, and all of their technology revolves around voice recognition. Anyway, after working on voice applications for them, I thought it’d be really cool to extend iTunes to take voice commands. I talked to some of my fellow interns about third party voice recognition software that I could use, and got started.

First, let me talk about some of the software I’m using. My voice recognition tool is called sphinx. It’s an open source Java package provided by Carnegie Mellon that’s really easy to extend. Sphinx was a bit difficult to install, but once that’s done, they provide a lot of demos that you can just look at and add on to. I just took their “hello world” demo, and added a bunch of stuff to it to get my media library recognition to work. If you’re at all interested (and because you’re still reading, I take it that you are) I strongly recommend checking out their software, playing with it and extending it to build your own applications.

On the other side of the application, I’m using a perl module to control iTunes. The module just has functions that output some applescript, so unfortunately this project can only be installed on top of OS X right now, but it’s a really simple, easy to use interface to applescript and therefore iTunes. This is what I really love about perl; there are so many libraries for perl that you can do pretty much whatever you want, just with installing a couple of modules onto your computer. I’m also using perl for XML parsing and other file handling, while I’m using Java for the user interface and interaction to sphinx.

Ok, so what exactly does my prototype do? Essentially, I have a java program that starts up the sphinx recognizer, waits for the user to say something like “itunes play”, “itunes pause”, “itunes next”, or “itunes select”, and then it processes the command, and sends a command to iTunes. “Play”, “pause”, and “next” are self explanatory, but “select” is a little more intricate. When the users says “itunes select,” the program prompts you to say an artist name, and then a track name by that artist and then it searches your iTunes library and plays that specific track. That’s the program from a high level.

Looking deeper down, the Java code is just a loop that waits for recognition, but I use different grammars each time. The main procedure just has a grammar that accepts the “iTunes” commands. Each command outputs a different string, which I send as the argument to a perl script. The perl script then uses the applescript library to send a command to iTunes.

Prior to loading the recognizer, I use perl’s XML libraries to parse “Itunes Media Libary.xml,” the file that stores all of iTunes’ track information. Then when the user says, “itunes select,” I dynamically generate a grammar composed of a list of all the artists in your music library. Then when you say an artist name, I dynamically generate a grammar of all the song titles. Once I have the artist name and the song name, I pass the information into the perl script, which again sends the commands to iTunes. On the whole, the project doesn’t seem too complicated, but there’s quite a bit of code involved, and it’s definitely more challenging than any of the other projects I’ve worked on.

My current prototype is fully operating as I just described, but it’s certainly not complete. Before I actually publicize and maybe distribute my software, I want to fully integrate it into iTunes as a plug-in. I also need to improve recognition, because my ultimate goal is to just leave the plug-in on, but it should know when it should be listening and when it shouldn’t. Finally, I also want to let the system learn artist and track names, because as of now, it only understands legitimate English words and a lot or artists names aren’t English words. I want to build a feature that allows you to train the system when you first run it, so that it learns this names and recognizes them for later runs.

Of course all of my aspiration and additions are a lot more challenging than just getting my prototype running, but I really think this project is cool and that it’s worthwhile for me to spend my time on. It would be amazing to show off to my friends, peers, and, of course, recruiters. What’s more important, though, is that I’ll learn a lot about building a stable, user-friendly, product that integrates a lot of different technologies. I hope to make this a project that I take from start to finish, spending time on all aspects of product development. It’s a challenge, but it’s been fun so far, and it’ll be so worth it when it’s complete.

Originally, I built the framework for this blog entirely on PHP, using XML to store my articles, comments, and all other data (see this and this for a detailed explanation of the original structure). Unfortunately, this design didn’t lend itself to scalability or adding functionality in terms of XML parsing. In contrast, perl has a DOM-based parser that makes parsing xml nice and easy. I decided to have a go at writing an xml parser in perl that has identical functionality to the php one I’m using currently thinking that I’d be a lot easier to enhance my blog.

I’ll start off by briefly explaining both parsers. PHP’s is handle based, meaning that the parser object starts at the top of the document, and whenever it gets to a tag, it calls either a start tag handler, or an end tag handler. When the parser gets to text between tags, it calls a data handler. The parser is good for crawling a file top down, but it’s not that easy to use if you’re looking for specific tags scattered throughout the file. You have to have dummy handlers that don’t do anything and keep switching the handlers when you come across the tag that you’re looking for. It’s also not very good for counting the instances of a specific tag because you may have to use global variables (generally a bad practice that should be avoided if possible) as counters. What’s more, each handler function is essentially just an if/elseif ladder that does something depending on what tag it’s analyzing. What’s more, adding functionality meant changing every handler to recognize a certain tag, or to change behavior when at a certain tag. In my case, I had about 12 different handlers, things were really redundant, and adding functionality was enough of a pain that I just decided not to do it (not the right solution). Using the PHP parser lead to really sloppy code and made it hard to add features to the parser.

In contrast, the perl module XML::DOM is a DOM-based parser, it works a lot like javascript parsing of HTML pages. You can call methods like “getElementsByTagName”, “getAttributes”, and “getChildren” on any node to extract information from that node. It’s pretty simple, easy to use, and the online documentation at CPAN is very useful.

So why switch over from PHP to Perl when it involves hours of reprogramming already working code? For one, I want to add functionality. If I kept the parser in PHP, this would take a lot of time and cause me plenty of frustration. Now that things are in perl, adding a feature is a straightforward as writing a simple subroutine. What’s more, the perl parser eliminates all redundancies, I’ve modularized everything into subroutines so that I never have repeated code in my parser. My perl code is also a lot cleaner, I don’t have long if ladders, instead I have a hash that maps tag names to subroutines. Everything in the perl parser just seems a lot cleaner than that PHP one, and I don’t regret spending a couple of hours to fix up my code.

One of the cooler aspects of the perl XML Parser that I’ve written is that I’m using mutual recursion very liberally. I have a couple of main functions: one for generating the html for multiple stories, one for generating html for just one story, one for getting all the titles of the stories in a given feed, and one for retrieving the latest story it. The first two functions call a private parse_story method, which goes into the mutual recursion. Each tag name in the story is a key in a hash that maps tags to subroutines. I iterate through all the child tags, and execute that subroutine. Each of these subroutines spits out some html and then tries to parse all the children again, recursively. With this recursion, I only need one subroutine per valid tag name, and the XML is parsed similarly to performing recursive algorithms on a tree structure. To add support for a tag, I just have to add it to the hash table, and build it’s subroutine. With this mutual recursion, the parsing code is much simpler and a lot easier to build upon.

If you notice, all of my served pages are still in PHP, so how am I calling this perl parser from php? I’m using PHP’s shell_exec function, which executes a shell command and returns a string of all the output from that shell command. The perl parser returns a string of html that my web pages echo out to the client. I don’t think this is optimal in terms of performance because I have both php and perl running simultaneously, but I didn’t want to build my entire framework in perl, so it’s a hacked solution.

So perl’s the way to go for XML parsing. It’s relatively easy, and allows for maintainable code (unlike PHP’s parser). Unfortunately, perl’s not nearly as popular for web scripting as PHP is, so if I wanted to distribute this, I’d probably have to use a PHP parser. Anyway, I’ve had the perl parser running on the site for about two weeks now, and I haven’t received complaints or seen any bugs, so things seem to be working well.