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!

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 195.12.4.1 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:

 
<Directory /photo/app/directory>
 
Options FollowSymLinks
 
AllowOverride Limit Options FileInfo
 
</Directory>
 
<VirtualHost kirkandjena.com>
 
DocumentRoot /my/content/path
 
ServerName kirkandjena.com
 
Alias /photos "/photo/app/directory"
 
<directory "/photo/app/directory">
 
Options Indexes
 
AllowOverride None
 
Order allow,deny
 
Allow from all
 
</directory>
 
</VirtualHost>

Step 3) Setup your /etc/host file. This file will tell your machine that when things get requested on certain IPs, do this:

127.0.0.1 localhost
127.0.1.1 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.

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;


  jQuery.post(postTarget,
      { var1: 'holla!' },
        function(data)
        {
          handleResponse(data);
        });
      
  jQuery("#ajax_loader").show();

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.

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).

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

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.