I like to do things with computers. Being someone whose creativity is reinforced by rules and limitations, I'm naturally drawn to the little boxes of regulated bits. But I don't like to do things just for myself. I like to share, so hey: websites. They're great for showing people things you do with a computer. And maybe those people can do things with your website that show you things they did with a computer! It's super great.
So I decided to make a new website for myself. I wanted to treat myself to the latest cool things on the Internet, and my old one-page thingy wasn't really a great place to house such treasures.
One of the new, additional parts of my new, additional site is this blog. To fill it out, here's an introduction to the stuff I used to make it. Maybe you're not a web developer but are interested in how websites are put together, or maybe you are and you're just wondering why this is all so slow. People in either one of those two situations will probably like reading this stuff. Everyone else: get out.
In General
What you're looking at right now is cobbled together by a cool Python web framework called Django. It's really good at getting out of the way and letting me actually make a website. It's doesn't hold your hand as much as a Ruby on Rails, but your reward for being brave and taking on extra responsibility is the freedom to do a whole lot more. URLs are governed by pretty nifty regular expressions, and it mostly doesn't care how you want to store data, write templates, or whatever.
Despite that freedom, most of the data on this site is stored in a fairly standard MySQL database. There wasn't really a reason for that other than the fact that I can just tell Django what's going on and then completely forget about it.
Standing at the gates of the server is gunicorn riding a dragon web server named nginx. They show users in and direct them to the files and services they request, handling all the tedious work involved in processing those sorts of things. Like MySQL and Django, I chose nginx and gunicorn because they don't get in the way of the things I want to do, and they're ridiculously easy to configure.
All of this stuff is running on a virtual server from Rackspace running Ubuntu. They call them "Cloud Servers", but that sure is dumb. They're pretty good, though! Nothing other than the OS install is done for you unless you ask, and they pretty much let you go about your business. You only pay for what you use, which means it's pretty cheap for me since I hardly use any bandwidth and need 1995-level amounts of memory and disk space.
A Cool Thing
Right there on the front page is a little app that shows you some of the things the Internet keeps track of as I go about my life. In an ideal Web, it would update you in real-time; but there are these great things called "rate limits" that exist only to keep me from reaching my dreams. So, I can only show you what's happening with my very important day every fifteen seconds or so.
Update: I'm now using Node and Socket.io instead of all that other stuff. It keeps memory usage way down and only uses one process, so that's fun! I'll keep this other stuff here because I spent five minutes so much time writing it.
But anyway! Since I needed it to keep asking things like Twitter and Youtube for updates all the time, I went with a suggestion from some guy on Twitter and used Celery. Celery keeps a list of things the server needs to do, and the server does as many of them at once as it can. Some of those services can be a little slow, so it's in everyone's best interest to get them asynchronously. It's obviously more complicated than that, but shut up, idiot.
Celery keeps its list in Redis, an in-memory data storage thingy. Redis also keeps the updates themselves, formatted into nice little JSON snippets. Honestly, the only real reason I did it this way was to learn how to use that stuff. I'm sure I could've kept it all in MySQL and just used corn cron instead of Celery, since I'm sure the demand isn't going to be so high that I need to optimize anything at all.
So, when a user visits my thing, a JavaScript library all the cool people use called jQuery sends a cool Ajax request (another name I don't like), parses the JSON, and shuffles around some DOM elements to make it look nice.
Weirdly enough, the hardest thing in all of that for me to get through was making sure you could see how long ago all those updates happened. When I started out, I had no idea you could use dateutil to easily parse all the different time representations sent by all those APIs, or that caring about anything but UTC is just headaches. Daylight savings time can do something it doesn't enjoy at all for all I care!
And So
That's pretty much how my site works. If you want to know more or tell me I'm dumb about computers, you can find me on all those sites down there in the footer, or on irc.freenode.net as grampajoe.