Tuesday, January 27, 2009

Latest Books

So I finally finished the book "This is Your Brain on Music", which turned out to be a pretty interesting read. I described it somewhat earlier, but basically it was a book about why we love music, what about music makes our brain recognize, assemble, and appreciate it. It is the kind of thing that I want to read again as I learn more about music and the technical aspects of it, but it was really pretty accessible to the lay reader as well. I recommend it to anyone who just loves music but doesn't actually know why!

Last week I also read Cormac McCarthy's The Road, which was incredible. The way it was written was just really impressive. I didn't have any trouble with the writing and punctuation (lack of quotations) that could be annoying to some. There was so much about this book that was so good, and left me wanting more. I think the fact that we didn't really know too much about what caused this apocalyptic event, that we didn't know how old these people were, where they came from, where they were headed would sometimes be frustrating. The way it was written and the fact that the reader can become so invested in the character can balance the frustration with appreciation. It's been a while since I had eight pages left in a book and didn't want to read them because then I would be done. I plan on devouring the remainder of this author's work.

Another book I started recently (it's a big one and I am only 1/4 of the way through) is The Day of Battle: The War in Sicily and Italy, by Rick Atkinson. This gives a detailed history of the Allied campaign in Sicily and Italy, starting from preparation to make landfall in Sicily. It's amazing how much stuff went wrong for the Allies - how many paratrooper snafus, how much of an issue logistics was, how much of a problem cooperation between England and the US was, and even how much of a problem inter-branch communication and cooperation was. This is an interesting book 150 pages in - it's the kind of history book that reads unlike a history book, and I've enjoyed it thus far.

Finally, my current subway reading is The Second Civil War, by Ronald Brownstein, which tells the story of extreme partisan politics in the United States - how it has evolved since the late 1800s, and how it affects the ability of the legislature to pass laws - what's good about it, what's bad, and (hopefully) what we can do to overcome extreme partisanship. It's part history, part political science, and thus far an informative and easy read. It's been enjoyable learning about the people behind the names on the Congressional Buildings down the street from me - Cannon, Rayburn, Dirksen, etc. I'll write more on this one as time goes on, but it's a good follow-on to the book 'America's Three Regimes' that I read last year. Hopefully the Obamanation of our government will render all this extreme partisanship moot, but I have my doubts.

Monday, January 26, 2009

Get Agile!

Well here at Sportsvite, we are working on getting agile. We've had a new team member join us (Jeff), and with him he brought a bunch of ideas about software development and process. He is a pretty strong devotee to the Scrum process (to which I am quite open), to Spring (which I think is in many cases overrated, but maybe I am just being stupid), and to the New England Patriots, which I suppose we can forgive.

As a small team that is spread out across multiple offices with different work schedules, we are truly hitting some edge cases when it comes to Scrum/Agile implementation. As we navigate the process, we can talk more about how it's going, but here are the issues that I see up front:

1) Multiple Responsibilities

We have one platform, but many streams of work. How can we reconcile sprints to the timelines that exist based on external client demands? While the core product timeline may say that we plan on delivering some software on March 20, but a client says March 6, how do we address this - theoretically we will have a bunch of half-done stuff going out live. Normally, this can be addressed by using source control branches, etc, but what if there are platform dependencies? Just a matter of careful planning, but there is the definite potential for trouble here.

2) Verification

On a small team without dedicated QA, how can you really verify that things work? So part of this problem is not having a dedicated quality team, but you can obviously make do. The issue here is that in a perfect world you have QA folks working in lockstep with the developers and UI designers writing test cases and readying for the verification step - in our case if the developers have to do this, they aren't developing nearly as much, and then they have to stop dead in their tracks to test, rather than getting folks testing while the developer can finish up more tasks. Not a shortcoming of agile, just another hurdle in general.

The idea that we came up with is a two week sprint of work, with a one week verification sprint. This sort of violates the spirit, to me, as a sprint should theoretically result in 'finished' work, but it's an adaptation that seemed to be the best compromise available in our situation (comments and suggestions always welcome)!

3) Heavy UI Requirements

Part of the big idea with agile is to coordinate effort and get everyone on the same page that things are ready to deploy in a timely and high-quality fashion. Here, and at many places where you develop a world-facing site, you have a heavy reliance on UI designers. Here we get templates and we apply them once the server side work is done, turning HTML into JSP. This is okay, but now we want to make it all cohesive. How can we do this, when the UI needs to be done ahead of the developers? We can have the UI team working ahead of the engineers, then catch up with them towards the end of the development sprint in order to do any cleanup and browser testing fixes. This is okay, but one of the best benefits I see in this is that the sprint planning session should take place before the UI work starts, so we aren't hurrying through last minute requirements on the UI, and I am not sure if this is going to be the case if the UI folks are already making templates.

4) Geographical Issues

We have developers in Washington, and non-technical staff and UI designers in New York city. Traditional scrum is very hands on and paper/white board based. We obviously can't all be in the same room, can't all physically watch people manipulate the task list, and whatnot, but we do have technology to do it. We just need a way to manage the 'state' of our project. To that end we can use tools, but we haven't found one that is all the way there and reasonably priced. We are using Scrumy for now to see how it goes - it's pretty nice, but there are definitely shortcomings.

I am hoping that people out there who are agile pros have run across things like this. Obviously the positives outweigh the negatives. We will be able to plan out our work better, get a better idea of how long things take, to prioritize more effectively, and hopefully to deliver better software on tighter timelines. We just can't do the vanilla agile implementation.

Friday, January 23, 2009

Interesting Entrepreneurial Readings

Read a couple of interesting posts over the last couple of days.

Keith Casey on 'Clarifying that Idea' - so true. If you can't explain it to yourself on a piece of paper, then how in the HELL are you going to sell it, or get someone else to invest in it. I think that this sort of activity forces you to

A) be real about your idea - will it work, now that you have restated it in a more concrete fashion? B) think about what you are saying, thus spawning more creativity - ou can't just have an idea and then dive in, because then what you are implementing is as half-baked as the idea itself - Garbage In, Garbage Out.

Jessica Mah on why entrepreneurs fail - they fail because:

1) They have lots of ideas, but no implementation
2) They have lots of ideas, but half-assed implementations
3) They have lots of ideas, lots of implementations, but no focus

Personally, I would say that 1-3 are all ahead of the game. How many 'entrepreneurs' are sitting around at home thinking up ways to get rich, to stop working for 'the man', and don't think of anything at all. I guess they are #0, and we all know whey they fail =).
When I actually have ideas, I certainly see myself falling under #2/#3, my problem is that I get bored easily, and want to create things, so I have four projects at home of stuff I thought would be good - this is why you need a well rounded team. Someone has to NOT CARE about technology, and just want to build products and make money. Without that guy, all you are doing is building cool stuff that never sees the light of day.

Thursday, January 22, 2009

Get Inaugural!

Well, January 20th has come and gone, and thankfully everything was, while exciting and wild, still peaceful - a success. Our home, Washington, DC, served as a wonderful host to hundreds of thousands of people. People who came here to celebrate a new hope, a new purpose, and a new commitment to making our nation a better place to live, and a better place for our children to grow up. It would appear that those people served as good guests as well.

Jena and I wandered down towards the Capitol around 11:15 on Inauguration Day to see if we could at least hear what was going on, but things were blocked off pretty good, so we went back home and watched in our living room, where the wind chill wasn't a factor. I know that not everyone was wowed by our new President's speech, but I was.

He has made all the campaign speeches. He already has everyone excited. This inaugural speech was about telling people it was time. Time to start fulfilling our promise. Time to remind everyone that this land is OUR land. That the government's purpose is to allow everyone the pursuit of happiness, and not to guarantee it. That much is up to all of us. It's time for each of us to do our part in remaking the American dream. I hope that all the talk and the excitement doesn't fade, like so many children's toys that fall from favor days or weeks after they are given to them.

Real, tangible action will do so much to keep the momentum. The new whitehouse.gov site was a great start - it's not perfect, but the fact is, it's symbolic of the new administration - here's what we are doing, come and see. This says to me "this administration will not do something that we can't share, because if we can't share it, it's not something we should be doing." Obviously this doesn't apply to clandestine services, but most of what we do as a government should be distilled in a manner that allows the average interested American to understand what, how and why it's happening.

I will be interested to see how the agenda is reconciled on the site itself - so, here was the administration's agenda, and here's what really happened, here's links to votes on topics, here's discussion on this issue, etc. There are so many possibilities. Let's see what becomes reality. I for one am certainly optimistic - change is always good when things are going wrong. Different is better, at least at first, and now we just have to work together to keep it going.

Wednesday, January 21, 2009

Sick + Birthday + Busy Releasing Software = Bad Blogger

Apologies to my legion of faithful readers. I have been a terrible blogger - be on the lookout for some good stuff in the next few days!

Friday, January 9, 2009

Field Guide to Setting Up Your Home Webserver

Well, it's taken a while, but I finally have http://kirkandjena.com up and serving pages from my server at home. This has been much more difficult than it should have been and the saga features four different operating systems, two DNS servers, multiple calls to my cable Internet provider, and more than a few headaches. I think that there is very little thorough documentation out there about setting up a website from your house, so let me take a stab at it.

First the background:

I have a Dell SC430, an old piece of crap small business server that is pretty stripped down. I had OpenSUSE 10.2 installed on it initially, which at first was fine - it seemed to agree with my system in a pretty plug-and-play fashion. I was pleased enough with the UI, and it performed great considering it really wasn't a very high-horsepower setup, but then bad stuff happened, and I moved onto Ubuntu 8.04. Now, I have already described my admiration for Ubuntu 8.0.4. It seems to come with most everything that you need on your server. My biggest problem with Ubuntu wasn't really a problem with Ubuntu I guess - the resolution on my 22-in monitor wouldn't be recognized, no matter what I tried. Apparently, this has to do with the bobo graphics card (Radeon ES1000) that is delivered with the Dell SC430. Anyway, long story short, the screen was awful to work with, and I had heard great things about OpenSUSE 11.0.

I gave it a shot. The screen resolution was recognized right away. That was good - it was very fast, and had a great look to it. The rub was, every time I tried to setup the network, I would lose my network connection altogether. Even when I hit finish after making no changes, it would hose my connection completely, and I would have to uninstall and reinstall my network driver. Not that great. The package manager is much better on SUSE 11 though. So, I had an epiphany. My loyal readers will remember that RCN screwed me out of running a media center PC at home, because they are bad, bad corporate citizens. I thought, why don't I make this server just a server that I only connect to using ssh, and use the idle media center as my computer at my desk. Eureka! I downloaded Ubuntu Server Edition 8.10, since Ubuntu did what I wanted it to. Within mere minutes, I had a server installation loaded up, no problem.

Now that I have woven this tale of woe, it's time to actually talk about what I meant to talk about: how to actually set yourself up to have a domain name and a webserver.

Step 1) Get your domain name. I use godaddy.com. It's a terrible website, but it is pretty cheap and simple enough.

Step 2) Get a static IP - this is more or less expensive based on whether or not you have an evil ISP. Despite RCN's lame decision to force cable boxes on the masses, they have REALLY cheap business internet and static IP costs. I pity the fool who uses Verizon DSL. It was MUCH more expensive through them.

Step 3) Set up your router - the steps I am describing are for a netgear wireless router. I assume it's pretty much the same no matter what router you have as long as it's not a complete piece of junk, and was built recently:

a) Set a static IP address for your server - this can be achieved by mapping an IP address to your server's mac address. This means that every time your server receives an IP address, it can be one of your choosing.
b) Setup port forwarding - now that you have it established that your server is listening on port xxx.xxx.xxx.xxx, you can setup port forwarding. The obvious port would be 80, the default http port. You can point 80 over so that all http requests to your ip address are routed to the web server on the server.

Step 4) Set up your entry in a Domain Name Server (DNS). You need to tell the Internet that your domain name is associated to your statically assigned IP address. This is accomplished by adding an entry to a DNS somewhere. There are a bunch that you have have to pay for, but thankfully, there are a few that are free, and seem to work pretty well. I personally used everydns.net. It's simple to say "associate this name with this IP address". Then go back to your hosting account, and set the nameservers on the domain name to point to the nameservers you just setup. Now the web knows that points to myawesomesite.com. This takes a while to propagate across the web, so give it time. Once it gets to your ISP though, you will be able to type your domain name in and have it resolve to your IP.

This is the setup that takes place outside of your server. Now you can move on to the good bits, setting up your content, your webserver, and any operating-system level configuration required to serve pages to the internet.

Step 1) If you don't have it already, get apache. There are about a billion tutorials on installing apache, so I won't bother you with the details there. Once you have it installed and running, you should be able to type http://localhost and see the stock apache page that says you have it installed. Now you are ready to do your thing.

Step 2) Decide how you want to host your content. Do you want to host just one directory worth of stuff, or do you want to have a slightly more complicated setup. I want to use kirkandjena.com for more than just one directory. I would like to have a homepage that can link to as many things as can think of to host. Here's how I did that:

a) set up my web root at /my/path - all you have to do is have an index.html, or index.php - whatever start page is defined in your apache configuration - just search for 'DirectoryIndex'. Add your homepage there.

b) setup as many directories of other content that you want. These directories will be referred to by subdirectories. kirkandjena.com/photos is an example of this. These will host the content of your 'applications'.

c) now setup your virtual host. There are quite a few examples on how to do this on the web. The most clear documentation I have found is here. The idea is that you want to tell apache that if it gets a request with this path and this URL, on this port, here is what you want it to do. In this case, I may want to host multiple sites, but currently just kirkandjena.com. So I define one virtual host, saying if you get this request, here's the pages you should serve:

  1. <Directory /photo/app/directory>

  2. Options FollowSymLinks

  3. AllowOverride Limit Options FileInfo

  4. </Directory>

  5. <VirtualHost kirkandjena.com>

  6. DocumentRoot /my/content/path

  7. ServerName kirkandjena.com

  8. Alias /photos "/photo/app/directory"

  9. <directory "/photo/app/directory">

  10. Options Indexes

  11. AllowOverride None

  12. Order allow,deny

  13. Allow from all

  14. </directory>

  15. </VirtualHost>

Step 3) Setup your /etc/host file. This file will tell your machine that when things get requested on certain IPs, do this: localhost ubuntu-server
xxx.xxx.xxx.xxx kirkandjena.com

The IP address for your site comes from the settings above (whatever IP address you assigned to your server). Restart apache for good measure after updating this file.

So that's it - now restart apache, and if your directories are in the right place, you should be all set to start serving your pages to the world. Hope this helps, and feel free to chime in with some pointers or corrections.

Shameless Plug for a Guitar Hero

Like I said the other day, I have been taking guitar lessons for a little over a year now. It's been a lot of fun. It's a great escape from all the other stuff I do from day-to-day (you can only program and read and watch sports so often). I feel like it opens up the creative part of my brain, and as someone who loves to listen to music, it's just kind of fun to actually MAKE some once in a while.

Now I am not necessarily predisposed to being a good musician, so the fact that I have made any progress is a true testament to my awesome guitar teacher, Dan Cohn. I strongly recommend that anyone in the DC area who is interested in giving guitar a try, be it electric, acoustic, classical or not, to check him out! He makes lessons fun, and every week you learn something new. His website is full of testimonials from real guitarists talking about he has taken them to the next level, but he's every bit as good about getting you started. The best thing he did was ask for a CD of music you like, so that he can teach you in a way that will get you playing those songs.

Go take lessons today!

Disclaimer: I didn't get any free lessons or anything to post this - just wanted to note that Dan's awesome. Part of my 2009 resolutions are about recognition of things that are excellent.

Wednesday, January 7, 2009

Ode To jQuery

As someone who uses a large quantity of code written by others, I run across some pretty good stuff, some pretty weird stuff, and some pretty bad stuff, but only once in a while do I use a library and think to myself, "wow, this is pretty sweet", because after all, how sweet and awesome can a software library be. It's a software library, after all, not a shiny red car. jQuery is the shiny red car of software libraries. It's pretty awesome. Here's why:

1) It takes something that's painful and makes it close to fun.

2) I can write things in succinct fashion rather than endless document.this.that.this.theotherthing notation, and define custom behavior for basically anything on the page.

3) I can find a seemingly endless quantity of plugins to do almost anything I need to do. Need a better tooltip? Use jTip! Need a really sweet overlay? Use thickbox! Need a star rating system to help your users become more interactive? We got that.

4) Everyone else is using it and making it more and more awesome all the time. Those people are all documenting their work pretty well for the most part, and cataloging it at one central, easy to use and search site.

5) It makes things that once required a fair amount of hand-written javascript into little snippets of easily replicated goodness:
   var postTarget = "/my/awesome/path;

{ var1: 'holla!' },


That little goodie does an AJAX post, then shows a little spinning wheel of wholesomeness, letting our friend the user know that we are working on their behalf. Handle response can do whatever we want, like hiding or showing something, or inserting something new and benevolent into the DOM, using the awesome show() or hide() method, or the html( yourstringhere) method. So good.

Libraries like this are important, because as anyone who works with Javascript much knows, writing code can quickly be about the JavaScript, and not about what you were trying to accomplish. When your focus is on the use case, and not the implementation, you can do a much better job, so jQuery, we salute you. You are the shiny red car of javascript development. Nerds everywhere are better for having worked with you.

Postscript: hilariously, my boss just wrote almost this exact post, albeit more polished.

Tuesday, January 6, 2009

Finish It.

I was recently talking to a friend and former colleague about work feedback, and the most important piece of advice I could think of was to be a finisher. It's easy to start things, and also really easy to get things to a certain point. This is why R&D-type work is kind of fun - you figure what's possible and give it a boost and then start something else, but at some point there is a finish line, and to be effective you have to cross it. In the case of R&D, perhaps to finish you have to write a feasibility study, or present findings on the topic - without that, you just have a half-finished something that nobody really knows how to use.

The world of software is littered with half-finished things. Programs that were the result of a good idea or a real business need, but that end up languishing in the sad limbo of incompleteness. Incompleteness has many forms. As it relates to software, it could be in any state (not fully coded, not tested, not documented, not turned over, not marketed) that means that it can't be used to its full potential. I am no stranger to unfinished stuff. Somewhere out there on the web, there is a Subversion repository with a bunch of code, mostly written by me, that does a little bit of stuff, but not nearly enough to be a product. It's unfinished, and essentially useless, and represents a bunch of wasted time. When I left Blackboard, I was struggling to hand over four separate unfinished projects to different members of the development team. Each could have been useful had I finished them, but when explaining them half-finished people really didn't get it or see what its potential really was.

We are only given 168 hours per week on this planet, of which we have to sleep for almost one third. That leaves us with 110-120 hours. Now you take away mundane stuff like commuting, eating, getting dressed, etc, and you are down to about 80 hours or so. You have 80 hours every week to finish things. It's not a lot of time, and you have to use it pretty wisely if you are going to be even remotely effective.

This seems like it's pretty tough from some folks standpoint, but compare it to something like a an auto mechanic. I was rear-ended two days before Christmas, and while fortunately everyone involved was unhurt, my car's rear-end took a bit of a beating. I dropped the car off at the body shop today to be repaired. Imagine that I was called by the shop, notifiying me that the car is finished, then going to the body shop only to find that you only have half a bumper. Would that inspire you to recommend that shop to someone you knew who needed auto repair? That auto shop would go out of business because nobody would hire them to fix a car. Similarly, if you as a developer can't demonstrate a finished product to their manager, or to a prospective employer, why should he or she give you a raise, or believe that you are capable of doing anything good for them in the future?

Finishing is also important to your confidence as a developer. If you have taken something from start to finish, you know that you can do that. That's no small feat. Like I said, there are many unfinished works out there. That's a lot of stuff that hasn't been done. You will learn all the things there to learn in the home stretch - things you would never learn unless you tread in that area. You learn about how to verify the quality of something, about how to ensure that a user can use what you have built, how to document what you have built so that you can explain it to someone who uses it, or better yet, how it can explain itself. You may even learn how to 'sell' it - to convince others that it is worth using, and to get them to adopt it. These are things you can never learn in full by going half way, or even three quarters.

Working at a small company has taught me to finish. I am certainly no expert, but I have become much better at it, because if I don't finish, nobody else is going to finish it for me, and we can't afford not to finish things with such a small team. 2009 is a year where I hope to do a lot more finishing at work and on my personal endeavors.

When Bad Error Messages Attack!

When considering how you should display error messages to your users, try to shy away from error messages like this:
There was an error connecting to the database. Please try playing the game again later, or right now.
Not the best, most informative message, but hey, at least we get a choice, right?

Quality error messages (or lack thereof) seem to really separate polished applications from those that are a bit hackish, when you using various sites on the web. It's the kind of thing that's a real pain in the ass to fix after the fact, so start out with good, informative messages, and a good framework to handle logging and error notification. This means "don't pipe your errors to System.out". When you do that, you end up with 64GB catalina.out files that aren't rotated. While disk space is cheap, it's not THAT cheap.

* These pieces of advice are not meant in any way to convey the illusion that the author of this blog has never made any of these mistakes (except the wack error message).

Friday, January 2, 2009

Goodbye 2008

Welcome to a new year. This post will be the obligatory "look back, look forward" post that all self-respecting bloggers seem to make. Since I aspire to be self-respecting (at least I can respect myself if nobody else will), here goes:


2008 was a pretty awesome year, as far as years go. Let's recap the highlights:

1) I got married!

After six long years of wondering if I could sucker Jena into spending the rest of her life with me, she finally caved, and we had a beautiful (if somewhat Hannah soaked) ceremony, and a fantastic reception with our family and best friends there. It was a great, great day, and as a bonus, almost four months later, Jena is still sticking with me! I not only gained a wife, but a large new family, all of whom had already treated me like family. I am happy and honored to be official.

2) We went to Italy for almost three weeks to celebrate our wedding! We started in Roma, taking in as many historical sights and as many gelatos as possible for three days. We saw the Vatican, walked through the city, checking out such tourist standbys as the Spanish Steps, Trevi Fountain, the Colosseum, and the other 2000 year old stuff that Rome offers. We then hopped a ferry to Sardinia where we spent a week enjoying the relaxing coast, and eating delicious Sarda fare. Then it was back to the mainland for a week in Tuscany, exploring more history, eating, drinking Chianti, and taking hot air balloon rides. Fantastic trip.

3) I got a new job at Sportsvite back in March, and have been flooding my brain with new stuff ever since. I think this is the year I sort of 'turned the corner' in my career. I was always pretty good at what I did, but I think this year, and the switch to a new job has really sealed it for me as far as a higher-level understanding of all the moving parts. Like I talked about in this post, it's great to work as a developer at a startup, because you really become a solid generalist. There aren't enough people around to just focus on one area. You have to touch everything, and this requires some level of understanding.

4) I got a lot better at the guitar. I have been taking lessons solid for about a year now, and I have really come a long way. I am not going on tour anytime soon, but I am certainly much less incompetent on the guitar, and can pick up and play most simple songs. If my stupid fingers would cooperate with barre chords more, I could play a lot more. Guitar is something I have always wanted to play, and my wonderful wife got me one for Christmas a couple of years ago. It took me a while to realize I'd need lessons, but once I finally got started, the progress has been really encouraging.

5) I blogged a fair amount...and it sucked for the most part, I think. The bright side is that in the haystack, there were some decent needles. May 2009 be better on that front.

Happy New Year - 2009 is coming next.