Ionrock Dot Org

My Weblog

Year End Updates

So, by some string of luck I managed to get a few follower's on my Posterous blog. Considering we are just starting a brand spankin new year, now seems like a good idea to offer a little overview of myself. Also, this Posterous blog is primarily just a way for me to blog on my own website, Ionrock Dot Org, so feel free to check it out or leave comments there.

Work

First off, I'm a programmer for YouGov. I program web applications with Python. This past year has been quite the roller coaster for jobs. I started off the new year with a company called BSG Alliance. This was after scrambling from a failed startup. BSG promptly changed their name and managed to grab even more VC money and I was semi-confused what the company really was doing. By the way, this confusion might seem like a negative statement about my previous employer, but in reality it says more about yours truly. I started working their because they used a pretty nice dynamic language and the guys I was going to work with were insanely fun. The problem was that I just didn't get whole Enterprise 2.0 mindset along side Rails. The result was that when some friends of friends pinged me to see if I was looking, it was a little too easy to entertain the idea.

So, after a name change for the company and a trip to Palo Alto for me, I found myself with a new job working from home. Since then, I've had a blast. I love where and what I work on every day. Previously, my endeavors ended up being rather focused on XML technologies. YouGov has given me a chance to avoid XML for a while and it is honestly rather refreshing. The XML world has made data formats interesting and useful, which translates well with other data formats such as JSON. At my job, we use JSON quite a bit and have written a good deal of internal services that focus on it as a data format, so while I'm not exercising nxml quite as diligently, my mindset for information hasn't been inactive.

The other big change for me in moving to YouGov is that I no longer work on my physical machine. I have a laptop, but it is effectively a dumb terminal that I use for connecting to my machine at the office. This has provided a great deal of challenges and allowed me to finally become serious about my Emacs and shell skills. It is funny to realize how little features like copy and paste can become slightly difficult when you can't easily just grab the mouse and make a few clicks.

Finally, I started blogging for O'Reilly. Things started out focusing on XML, but O'Reilly changed backend systems as well as reorganized their web content. The positive side of this was that I was able to blog about anything I want. The downside is gathering an audience is not quite a simple since my posts have become part of a much larger pool. I'm not complaining though. It is a lot of fun blogging about tech with a reputable organization and I've gotten a free book in the process, so I'm happy.

Music

So, outside of programming, I play bass in a band called Ume. This past year we finally got in the studio to record. This ended up taking quite a while to finally capture a small set of songs we had been working on. When we first moved to Austin, we got in the studio and started making a record. That process became somewhat difficult as our engineer ended up going on tour for a few months and we had to find another that was reasonable. By the time we finished the majority of the tracks we were contacted by a relatively well known producer that wanted to work with us. This was extremely exciting, so we dropped what we were doing to see what would happen. Being a good producer, he pretty much let us know that we needed practice. So, we spent massive amounts of time practicing and getting better playing together. Eventually it became obvious that while the producer wanted to work with us, it was pointless to wait, so we went in the studio and started working on a record.

We wrapped up the EP and have managed to get it pressed. A friend of ours did the artwork and really did a great job. We ended up playing Fun Fun Fun Fest and will be playing SXSW this year. My wife has been working with Girls Rock Camp Austin. Through some contacts there, she is going to be turning some Ume music into a real deal symphony piece. Ume also had the privilege to play Girls Rock Camp, which was pretty awesome.

A quick side note about Girls Rock Camp. It is a really powerful program! I don't think many men realize that the world still has a great deal of sexism that makes it very difficult for girls to find their own voice. I'm a guy, so my experience is very limited on the subject. But, what I can say is that I've had the privilege of seeing young girls gain confidence and it is really powerful.

This year the EP is coming out (Feb 24th digitally). There is a press campaign happening at the moment and a few friends have been working on some videos. Surprisingly, making a video is really hard work. It is physically challenging to effectively play a show for 6 to 8 hours. Hard work aside, I'm looking forward to checking them out.

So, that is about it for me this past year! Looking forward to 2009.

Heading to California

I'm going to be out in Palo Alto this week to hang out at the office for a bit. If anyone wants to get together for a drink or grab a bite to eat just let me know.

TDD gets you in the Zone?

I just read a blog post about how TDD is able to get you in Zone consistently. TDD has always been difficult to integrate into my workflow. It is clear that writing tests is a "good thing" and that it helps to write better code. In fact, I'm now of the opinion that tests are truly necessary in a dynamic language like Python because without tests, there is no way to follow the data. If you don't believe me, write a script to find where a specific object is used in codebase. It is near impossible because the type information is meant to be hidden. Testing allows you verify your application is working as it should.

Lately, I've been writing tests slightly more diligently, and it has paid off. When I had to switch functionality, it was trivial to just rerun the tests and verify things would still be working as they should. What's more, I've had fun writing the tests because it is something I get to start from scratch. It is always fun to create a new file and start fresh, and often times writing tests is exactly that. What's more, you get to write mock objects and helpers to replicate interactions. For example, in testing something at work, I needed to write a helper object that allows streaming file uploads. It was fun putting together a rather helpful little object for sending multipart/form-data uploads. I even was able to write a small command line tool to make testing things out even simpler.

This is a pattern I could really see working. Even if TDD ends up becoming an avenue to tinker with new things, I'm ok with it. Getting in the Zone is pretty awesome. There is most definitely a high. In fact, we just played a CD release show here in Austin that went very well. I'd say the "high" after the show is pretty similar to get in the Zone with some code. I'd love to play huge shows every night, but that is going to take a while. At the very least, I can try writing more tests and seeing if that lets me rock Emacs a bit more and get in the Zone consistently.

Does Javascript Need Jack?

Kevnin Dangoor mentioned Jack, a Rack implementation in Javascript. While I'm a fan of Rack, I don't get Jack. Why you ask? Well, I'll tell you!

The reason Rack works as it does is because Ruby doesn't support functions as first class citizens. Yes, I realize that many Rubyist fancy their language as an entry to functional programming (I'm assuming b/c of blocks), but Ruby is far from functional. Python, on the other hand, while also far from functional, does allow passing functions as arguments. The WSGI specification, where Rack draws its inspiration, in fact works via passing callables (a duck type for functions) along with an environment. This is very similar to XSLT in how the "." represents the current context, the environment represents the current state of the request. Secondly, WSGI allows two places to adjust the request response. Again, this is very functional. You either adjust the input (the environment) or the output. Basically, through passing functions, you nest them together using the WSGI spec and when the last one calls the start_response function, the output bubbles back through the function hierarchy.

Based on how WSGI works then, it makes no sense whatsoever to implement a WSGI copy in a similar fashion to Rack. Javascript already supports the necessary tools to make a rather pure WSGI implementation (lets call it JSGI) using the same patterns. One distinction the Jack docs make is that Jack is meant for server side Javascript. Again, I don't think this is a problem whatsoever.

I don't want to suggest that Jack is a bad idea, but it seems like basing it on Rack lacks foresight into the actual use of the design. WSGI has proven itself in a very powerful way. There are a multitude of applications, libraries and middleware that all make it clear WSGI is successful technology. Rack on the other hand does not have the same track record. Including Rack in Rails 3 doesn't really count either as Rails 3 is not released and there are no examples of sites or services using it. It also seems like a shame that the functional features of Javascript are not being utilized. The sucess of jQuery, I believe, is largely a function of its functional approach and respect for the language. It seems that a similar functional approach should be taken implementing something like WSGI in Javascript.

The Tech Behind the New Ume Site

Recently, I pushed the "live" button on the new Ume website. Being a programmer, I took the opportunity to update some code and try my hand at design. Feel free to leave any me comments (bugs!) here.

The Design

After the initial design got stale (which happened pretty quickly), Lauren did a redesign for our first official full length. This essentially Lauren's first foray into Photoshop and it lasted for quite a while. This last iteration is obviously also designed for our new EP. Laurel (a friend who also does projections at our shows) did the cover design and we managed to grab an image from her for the header.

This design actually came out of an entirely different design that I had almost finished. The previous working version had a really light feeling. The big problem was the actual content areas. When we decided to scrap it, I started over on the text. I put together some basic textual elements and then worked on the menu based on a previous experiment. Once the text was looking good, Lauren showed me a banner design she had been playing with. We added that to the page and things were pretty close. A few menu changes later and things were pretty much done!

The Code

When I first started writing code, the Ume website was where I actually used it. I cut my teeth on PHP and MySQL keeping our show listings up to date and managing our mailing list. In fact, I'm still using the same (poorly designed) database I always have! This iteration gave me a chance to finally clean up the PHP code for the show listings as well as fix some basic organization issues that always bothered. The majority of coding this time around was spent writing Javascript.

Before this iteration of the site, I started working on an electronic presskit. Many bands use something like Sonic Bids, which is actually pretty helpful, but for specific purposes they keep something of a online one sheet as well. For ours, I wanted users to be able to play our music. I found SoundManager2 and started working on a simple player that was similar to the WordPress plugins that turns mp3 links into neat players. It turned out pretty well and I had a decent jQuery plugin for SoundManager2. I used this player on earlier designs, but we thought it would be better to have a player that would play the whole record instead of just stream a few songs. The player on under the "listen" heading is the result.

Since I had a player and I didn't want it to restart whenever someone went to a different page, I went ahead and made all the page content load via Ajax. Now, I should mention, that I don't think the site degrades gracefully and personally I'm ok with it. Band sites are traditionally meant to look good, so if things break when a person turns off Javascript (or flash for other band sites), the user is out of luck. I'll try to fix this of course, but for the time being it wasn't a priority.

Ajax content is pretty simple stuff thanks to jQuery. I can't say I had any major innovations here. The URL fragment defines where it will pull the content from. I added a loading spinner from this site. As simple as it is, I was really glad getting a decent spinner was such a painless process. In fact, the whole implementation was extremely painless. jQuery is really an amazing library that made life really easy. The actual site specific code is written as a jQuery plugin, which feels similar to writing a Python web app and packaging it as an egg.

All in all, the site redesign was a real success. As a programmer, it was nice to see how my skills have grown throughout the years. It is also a reminder of how much the web has grown up with the advent of great libraries. The ease in which I made this relatively dynamic site is truly a testament to the libraries and evolution of the web as a platform more than anything. So, I suppose this post is generally a thanks to those folks who wrote great libraries!