Randall Degges

How I Learned to Program

Fri, 03 Feb 2012 22:18:00 -0800

Programming is, without a doubt, the most mentally rewarding thing I've ever done. Programming taught me that life should be fun, filled with creativity, and lived to the fullest. Programming taught me that anything is possible; I can do anything I want using only my mind.

Programming also taught me that learning is fun. It showed me that the more you know, the more power you have. Programming showed me that a life filled with learning is a life worth living. Programming revealed to me who I am inside, and has continuously helped me work towards my goals.

I feel extremely lucky to have had the means and opportunity to learn programming early in my life. While my methods are certainly not optimal for everyone, they worked well for me.

I have no regrets.

So I figured I'd share my methods with you, in hopes that a beginner will read this and get some value out of it.

If you don't want to read all this, the important takeaway here is to, above all else, have fun.

Install Linux on Your Box

While in my own life, I actually learned quite a bit about computers through video games on MSDOS computers--my real learning started the first day I installed a linux operating system on my home computer.

It doesn't matter whether or not you use Windows on your laptop, or if you have a Macbook Air--if you want to learn to program well, you need to use linux. Sure, there are a ton of great programmers out there using other systems, but you cannot beat linux as a learning machine.

Despite what you may think, programmers don't just "program". Programming as you probably think of it is nothing more than input and output. You type things, and stuff happens. This is incorrect.

Programming is a way of life.

Programmers are people obsessed with knowledge. Programmers use this obsession to fuel a life of learning, discovery, and creation. That is the true definition of a programmer.

A big reason to use linux for your day to day work is that it helps you passively learn about programming as you use it. On Windows, if you want to copy a file from one box to another, you drag and drop. On linux, if you want to copy a file from one box to another, you use scp or rsync. Learning how to use the command line teaches you basic technical logic and problem solving skills.

Another important skill you passively acquire by using linux is self sufficiency. Unlike many other lines of work, programming does not require you to memorize a million things, or repeatedly do the same thing over and over again; instead, programming requires intense self motivation and determination.

Even the best programmers typically have no idea what they're doing when they start a new project. If I could summarize one thing I do more than anything else as a programmer, it would be research. Programmers must know how to lookup information, and how to process and use that information in a useful manner. This skill is typically acquired over long periods of time--but linux can help.

Using linux will require you to actively seek out solutions to problems. If you don't know how to setup an SSH tunnel--you will learn. Using linux will drive you to discover new things you never would have thought of while using Mac or Windows. As you slowly become a better and better linux user, you will coincidentally become a better and better programmer and pragmatist. You'll learn how to go about solving problems. How to hunt down errors. How to use your combined knowledge to create new things and make your life (and others' lives) easier.

Furthermore, since linux (as well as a majority of its applications) is open source, you're in a great position to learn more about programming culture. At one point or another, I can almost guarantee you will:

Find a bug in an application you use.
You'll search for an answer online.
You'll find either a ticket system or a forum for the software you're using.
You'll submit a ticket about the bug, or post on the forum stating your problem.
Interact with other users like yourself to help resolve the issue.

While this may not sound cool now, just wait. Once you've done the above, you'll really be acquainted with the tech community. Finding problems, discussing them with others, and solving problems is what makes the technical community thrive.

If everything was perfect and there were no problems to solve in the world--life would be boring. Getting out there and fixing stuff--fighting chaos--that makes life worth living. So enjoy it!

Linux can help teach you these things, and more.

Have an Intense Desire

Why do you want to program? What is motivating you? What drives you? Unless you desperately want to learn programming, you will fail.

When I started coding, it was because I had an intense desire to hack video games. Back when I was a kid, video games were my life. I would rush home from school and spend as long as I could on the computer playing old classics. Some of my fondest memories are playing epic Starcraft matches against my brother (we'd have no rush 2 hour games where we'd max out our units and have battles that would cause our GPUs to quake in terror).

More than anything, I wanted to hack the shit out of those games. I wanted to dominate them. I wanted to enslave my computer and have it do my bidding.

While my old motivations are silly to me now, back then I felt them intensely. I'd dream about it at night, constantly think about it during the day, and obsess about it while I was on the computer in the afternoon.

When I set my mind towards learning to program, I knew I would make it happen. I knew that no matter what happened in my life, I'd either learn to program or I'd die trying. It was what I can only describe as a glorious feeling. It was similar to that feeling you have where you want something so bad, so intensely, that you feel it with every muscle in your body.

Regardless of the fact that I had absolutely no idea what I was doing--that I knew absolustely no technical people whatsoever--that I had no resources--and that I had zero guidance--I found a way. I ruthlessly read through internet tutorials on random webpages. I spend hundreds of hours scouring random forums looking for bits of information.

The most important thing, however, is that because I wanted it so bad, it felt easy. I've always been an all-or-nothing type of person, and I think that this helped me break through the initial barriers and eventually become a half decent programmer.

Build Small Command Line Programs

A lot of people now-a-days seem to be learning programming by diving head first into web development. While this may work for some people, it seems pretty damn crazy to me. Not only are web technologies complex and vast (building a modern website requires a ton of separate skills that take years to mature), but they're frustrating and discouraging for new developers.

Maybe I'm old school (I'm only 23 :x), but there is nothing more satisfying (and educational!) than writing a ton of simple, command line programs.

I can't even begin to express how useful this was in my programming education. For the longest time (after I gained a basic understanding of programming) I'd rush home from school, sit down at my computer, and spend 5 or 6 hours writing a simple command line utility. I'd write tons of things:

A simple program that takes in filenames as input, and stores those files all in an organized directory hierarchy depending on the file type.
An IRC bot that logs all channel activity to a text file.
A simple program that downloads all the images on a given web page.
A tool to convert base 10 numbers to any other base on the CLI.
A provisioning script that installs all my OS customizations: wallpapers, themes, etc.
A basic screenshot program that automatically uploads screenshot to an image hosting website, and copies the resulting URL into the clipboard for instant copy-paste fun.
And a million other things.

I got so much value out of these small exercises. Each one was simple enough to be written in several hours (no more), and each one taught me stuff: either a new language, library, or strategy. There's no doubt in my mind that I gained a good portion of my programming knowledge through building these apps.

The other benefit to building these small apps is confidence. Each app I built was a huge personal accomplishment. I felt proud of each one. I'd maintain all of them, and periodically rewrite the code using all the new strategies I'd learn. This taught me basic iterative programming (making improvements over time), and how to really contribute to the open source world.

If you're a new programmer, I doubt there's anything better (or more fun) than writing a ton of small command line utilities. Don't believe me? Try it, and tell me you aren't addicted after the first one!

Write, Write, Write

Writing is a bit controversial. When I started programming, nerds had a reputation for being bad at everything except computers. For a while, I assumed that since I was good at computers, I was naturally worse at everything else: writing included.

That's bullshit.

I've come to realize over the years that programmers are, in particular, excellent writers. The ability to think logically and solve problems is a great writing asset. It's particularly hard to explain your thoughts in writing. In my opinion, having strong programming skills makes this much easier, since as a programmer, you're used to arguing with logic and use it everyday in your work.

Through the process of writing a lot, you'll greatly improve your reasoning ability, and consequently, become a better programmer.

As a programmer, having a blog is a great way to practice writing. It's a great way to keep track of the things you learn, and help ensure you are always making progress. Through the process of writing about things, techincal things in particular, you'll greatly increase your knowledge on the subject.

For instance, if you're writing a CLI app that orders pizza through Dominos, it would be hard to write about that without going into detail describing the technology you're using, how the Domino's API works, etc. By taking the time to write about your experiences working with their API, you'll consequently learn a lot more than you would if you didn't.

Writing can be amazingly helpful when used to describe technical stuff, as it really simplifies and clarifies the root of the problem--forcing you to think of the problem in the simplest way possible. I can't tell you how many times I've worked on a really tough problem, then taken the time to write about it and realized that I vastly overcomplicated the issue.

One of my biggest regrets is that over the years I threw away a vast majority of my articles. Over time I rewrote my website frequently, mismanaged servers, and slowly lost most of my writing. This blog you're reading now exists primarily as the result of my decision to save all my future writings and provide a home for them that I won't mistakely lose. Don't make the same mistake I did!

Join an Online Community

The internet is a big place. Programming is a big field. While it is certainly possible to become an excellent programmer by yourself, completely isolated--it is much easier to do it with the help of friends.

When I started programming I was lucky enough to meet some amazing like-minded programmers online using IRC. The people I met were some of the smartest, passionate, and most motivated individuals I've ever met in my life. We're still friends today!

Having other insanely passionate and driven friends kept me motivated, and helped push me to be the best I could. We wrote articles for one another to share things we learned--we critiqued each other's code. We talked about projects we were working on, and what the best way to implement them was.

Having a group of people with the same passion and drive as yourself cannot be understated.

Finding a group like this, on the otherhand, is extremely difficult. I highly recommend using IRC (as a lot of bright people seem to use it), and gradually joining new channels and chatting with people who share similar interests. If, in the offchance you're like me, and want to hang out in the same circle, you're invited to check out #heapify.

Have Fun

Programming is fun. Programming is really, insanely fun. Just writing about it makes me feel happy inside. It's hard to contain my excitement.

The most important part of learning to program is to always HAVE FUN! Regardless of whether you're just getting into programming, or whether you've been a programmer for a long time: having fun is the most important thing you can do.

Let's say you're just starting to learn python (Dive Into Python is still one of the best python books ever written, by the way)--don't start by writing some boring project. Write something new! Something that you will find useful. Have fun with it, and challenge yourself.

If your sole motivation for working on a project is to get it done, you're cheating yourself. Part of being a good programmer is building stuff that YOU find cool. There is plenty of dreary software in the world, what the world needs is more AWESOME software. And the only way to make awesome software is to have fun building it!

I could literally go on ranting about how much fun programming is indefinitely. But instead, I want to challenge YOU (ya, you!). Think of something you'd really love to build: maybe it's a file sharing site, maybe a video editor--whatever excites you and gives you that warm fuzzy feeling inside. Got it?

OK, now go build it!

Regardless of where you are in your programming career: always have fun, and keep pushing yourself!

Permalink | Leave a comment »

My Ideal Life

Wed, 18 Jan 2012 21:32:00 -0800

As a strong believer in personal development, I realize that I will never be perfect. Despite this, a big part of the fun in life is working towards making yourself a better person. If you don't do that, what else is there?

In order to make yourself a better person, knowing which traits you'd like to eventually have is essential. Maybe you're a smoker, but you'd like to eventually quit. Maybe you're skinny, and want to add 10lbs of muscle to your frame. Regardless of your personal development strategy, knowing what to work towards is mandatory.

Over the past year, I've come to realize the importance of having positive habits, and how building a series of habits into your daily schedule is one of the best ways to make long term, sustainable change.

As my life goals are still undefined, my current focus is on building a repertoire of habits and skills so that over time, I'll gradually become the person I'd like to be, with as little friction as possible.

For the past few days I've been trying to enumerate the skills I want to have, and the life I want to live. After a lot of thought and personal debate, I've narrowed my ideal life down to the following 24 hour snapshot. My thought is that if I'm able to spend each day doing the things below, I'll be both happy and wildly productive throughout my life.

ALSO: I'm absolutely positive that I'm going to continuously change my mind about this over time. The points below represent my thinking at this current moment only. Future self, if you're reading this: what are you up to? Have your goals changed? Your ideal life?

In a given 24 hour day, I'd like to spend:

10 hours sleeping. This includes buffer time, stuff like brushing teeth and sliding into bed. This way, I'll get a minimum of 8 hours of sleep (with 2 hours of buffer in there, just incase).
1 hour writing. Writing is a tool I'm quickly becoming more and more fond of. Writing has helped me learn things in much greater depth, as well as improve my communication skills. I highly value communication skills, so this is high on my list of importance.
1 hour reading. I do a lot of reading, and I plan to continue this. Reading books, in particular, has taught me innumerable lessons, and the value I receive for my time investment is overwhelming.
1 hour exercising. Having a strong body is important--not only for longevity, but for mental health and mood. Hitting the gym everyday and lifting weights would be a great way to stay in top condition year round.
3 hours eating. This means uninterrupted meal and relaxation time either by myself, or with my family and friends. Rushing through meals is unsatisfying, and eating slow seems like a healthy, relaxing routine.
1 hour hacking on an open source project. This means writing code that goes straight back to the community. Not only do open source projects build programming skill, but they're extremely fun, and provide a great way to meet other smart, talented people.
2 hours working. This would ideally be hacking on my own company in some form: giving direction, writing code, whatever. Just working on a meaningful project that provides real value in the world, and enough money so that I don't have to worry about it.
5 hours doing anything else. This includes watching TV, hanging out with my wife, attending events, showering, volunteering, whatever.

Why so little work? Well, it's my thought that by improving myself in all areas (including things that aren't quantifiable--like focus, willpower, etc.), I'll be able to accomplish a lot more by working both smarter, and with more focus.

Working smarter means only doing things that absolutely require my personal attention. By putting myself in a position where I can outsource all but the most essential functions to others, I'll be able to drastically cut down my daily todo list, leaving me with much less (but more important) work to be done.

By working with more focus, I mean that over time, I'd like to build up my focus to a point where I'm able to completely immerse myself in a task for hours on end, without breaking concentration. Having that sort of intense focusing power would allow me to accomplish a great amount of work in a very small amount of time.

I believe that if I'm eventually able to work both smarter and with more focus, than 2 hours should be more than enough time to make a difference at work.

For the extra 5 hours of random time each day, I'd like to use that to do meaningful things. Maybe work on other projects, volunteer my time for a worthy cause, etc. It would also be nice to have free time so that, even on bad days, I can just lay down for a large chunk of the day and not feel guilty. After all, this is supposed to be a sustainable schedule--something that I can live with over a long period of time, not just a short term thing. This could also be a great way to throw myself at whatever I'm feeling most passionate about that particular day. This would free me up to spend an extra few hours working if I'm really in the mood, or maybe an extra couple hours reading--who knows.

So, that's my ideal life in a nutshell. What's your ideal life (or day) look like?

Permalink | Leave a comment »

How I Program Stuff

Mon, 16 Jan 2012 19:54:00 -0800

I love programming. I can truly say that of all the things I enjoy, I enjoy programming the most. There's nothing quite like the feeling you get when you create something. Writing code is a lot like building your own little universe.

When you build stuff, you're in complete control, and, no matter how hard you fight it, your code directly reflects yourself. If you write sloppy code, I can almost guarantee you'll be a sloppy person. If you haphazardly throw code around with any care or passion, it's likely you treat yourself the same way.

I tend to think of myself as a passionate programmer (subsequently, this is one of the best books I've ever read). When I'm building things, I do so with a lot of care. I like to:

Take my time, and not rush myself.
Maintain 100% strict style rules across the codebase. I'm a style nazi.
Ruthlessly refactor old or ugly code.
Put a lot of thought into the APIs available, and think of ways to minimize or get rid of them all together.
Keep a single, clear, and minimalistic purpose for the project.

I try to make every piece of code I touch a bit more like me (for better or worse). With the above in mind, here's my method for programming stuff.

Step 1 - Isolate

I work best in complete isolation (excluding the companionship of my dog, Scribbles). I find that when I'm completely alone, with no distractions, I'm able to really get into the proper mood for building things.

Confidence.

Being alone gives me a lot of confidence. If you're by yourself, you have absolutely nothing to lose working on that funky feature branch that will probably never work out, or attempting to refactor an enormous method that you later realize was written that way for a very important reason. When you're by yourself, there is nothing to be embarassed about. You have complete creative freedom to try new things without consequence.

Energy.

Maybe it's because I'm deeply anti-social at my core, but for some reason, I'm just not myself around other people. As (odd?) as that may be, being around other people seems to really drain my energy and sap my creativeness. Despite my best efforts, I just don't have the same energy around other people as I do by myself. When I'm isolated, I have an enormous amount of mental energy that I just can't help but use in creative endeavors.

Information.

I find that while alone, I'm able to make better use of available information. For instance, when I'm working with other people (physically), I tend not to use information resources as much. I won't google things, or read articles about the topics I'm working on. When alone, I tend to spend much more time researching relevant information, best practices, and learning skills that can help me do what needs to be done.

Step 2 - Eliminate

When it's time to really build things, the second thing I do is eliminate all unnecessary information. This includes:

Closing all browser tabs and starting fresh.
Closing all terminal sessions.
Closing all IM conversations.
Moving everything off my desk.

With everything out of the way, I'm able to easily focus on programming things. The code almost flows out naturally when nothing else is in the way, stopping it.

THOUGHT: Maybe we're all meant to be programmers, and our environment is simply stopping us from coding. In this case, it is our duty to eliminate all distractions and return to our natural state!

Step 3 - Code Ruthlessly

Coding ruthlessly is something I strongly believe in. I think that of all the things I've learned over the years, this has been the most important.

There is no room in this world for fear while programming. As a programmer, you have to be courageous, bold, fearless, and ruthless. If you can't bring yourself to remove legacy code because you may need it later, you've failed. Whenever I feel hesitation while programming, I make a mental note to seriously reconsider what I'm doing. If it makes me feel uncomfortable, there's a good chance I need to do that shit right away.

Being ruthless with your code means you make commits that fix whitespace, fix indentation, remove entire source files, deprecate API calls, and drastically change functionality--whatever needs to be done, you do it without a bit of regret.

There have been countless times that I've worked on code for a week or two, just to realize I went off on a tangent and completely strayed from the main objective. In times like this, the only thing to do is remove everything and move on. There is no room for ego in success.

Be ruthless.

How About You?

I'm extremely interested in how other people build stuff. If you've written about how you program stuff, or how you prefer to work, please let me know.

Permalink | Leave a comment »

Reflections on Heroku's Waza Event

Sun, 15 Jan 2012 23:46:55 -0800

Several days ago I was lucky enough to attend Heroku's first conference, Waza. Waza is the Japanese word for art and technique, which, in retrospect, was nothing short of the perfect name for the event. In my life, I've never attended such an artistic, well planned, and stylish event.

Surprise!

If this isn't the first time you've visited my site, you probably know I primarily write about technical stuff. Over the past few months I've been writing a lot about Heroku, which is, in my opinion, the best Django hosting platform available.

A few weeks back I got an email inviting me to Heroku's first conference, Waza, which was going to be held on January 11th in San Francisco.

Woa.

I immediately accepted the invitation. It's not every day you get to meet with a group of the best programmers in the industry. The guys who work at Heroku are all top notch developers, and people. If programming was illegal streetfighting, and I had to pick a partner to help me escape a no-rules-streetfight, I would pick anyone from the Heroku team in a heartbeat. :)

Anyhow, despite the fact that I can't imagine why anyone from Heroku would invite me to their conference, I got in!

Waza

Without a doubt, Waza was by far the nicest conference I've ever been to. It was nothing like a traditional tech conference.

The venue was particularly stunning. The event was held at Yoshi's, a jazz club in San Francisco. Heroku essentially turned the entire inside of the place into a Japanese village. There were zen gardens, Japanese style eating mats, amazing tea, and beautiful lighting throughout. Entering the venue was a lot like walking into a dream. The entire place was beautiful, elegant, and relaxing.

NOTE: I didn't get any pictures of the event, but Kenneth Reitz got a ton that totally kick-ass. I highly recommend checking out his Flickr album. If you look close, you'll find me :)

The event started at 11am with an excellent opening talk by Adam Wiggins, CTO and co-founder of Heroku. His talk was all about building excellent applications: why elegance is important, what trends software development got over the past decade, and what trends will become influential this decade. His talk primarily focused on application elegance, which I thought was a great intro for the Waza conference, which focused on software development technique and art more than anything else.

The talks were all amazing. All were focused around building elegant applications. As a developer, I truly enjoyed the talks I got to attend. They were all inspiring, well executed, and filled with lots of useful information.

People

By far the best part of the event was the people. In particular, I got to meet: Craig Kerstiens, Kenneth Reitz, Curt Micol, and Issac Kelly. Those guys are all programming superheros.

I've known Craig, Kenneth and Issac online for a while, but meeting them in person was really great. If you guys are reading this: we should meet up again soon!

As a complete surprise to me, I learned after arriving at Waza that Rob Pike was going to be giving the closing talk. If you don't know Rob Pike: he's one of the most influential programmers of all time. He co-created UTF-8 (unicode), created the Go programming language, and made countless contributions to UNIX. He also wrote two excellent books that contributed wildly to the programming profession: The Practice of Programming, and The UNIX Programming Environment. Without Rob Pike, the world would truly be a different place.

Seeing Rob in person was fucking awesome. His talk was great, and it was incredibly inspiring to even be in the same room as such an amazing guy. As my wife can attest, one of my lifelong dreams has been to meet Brian Kernighan, Dennis Ritchie, and Rob Pike. While I'll never be able to meet Dennis (he passed away last year), I'm extremely happy to have had the opportunity to meet Rob.

Tea

Oddly enough, other than an excellent group of techies--Waza had some amazing vendors come to cater the event, one of which was teance, a Berkely tea shop. They were serving several types of fresh tea, all of which were fabulous.

I've never been into tea much, but after a cup of teance's green tea, I was a convert. Best tea I've ever had in my life, hands down.

What made it even better was that the owner of the shop happened to be at the event serving tea, and answered all sorts of crazy questions I had about the tea.

After the event, my wife and I drove to the teance shop in Berkely, and had tea at their bar. We tried several types of tea, and left with a couple hundred dollars worth of the stuff. Money well spent.

If you're into tea at all, you should definitely check out the teance site and order some. I guarantee you won't be disappointed.

Overall

Waza was a great event. The venue was great, the whole thing was comfortable and relaxing, and there were tons of smart and interesting people all over the place. It was a great experience, and I had a ton of fun.

I hope the Heroku guys throw another one sometime soon.

Permalink | Leave a comment »

Dogs Are Great Programming Companions

Mon, 09 Jan 2012 22:37:00 -0800

I love dogs. Really. They're the best beasts on the planet.

For those of you who don't know: I work at home with my chihuaha, Scribbles. She's an awesome programming companion. As I work she lays in her dog bed next to my desk, and naps while I code. When I stand up and move around, she chases me around the house, and gets me to take her outside for a walk.

Since I started working at home two years ago, I've realized how great a dog can really be while you work. For me, Scribbles keeps me balanced. When I'm feeling stressed, I can lean down and scratch her head. If I've been sitting too long, Scribbles will get my attention and demand a walk. She always knows exactly what to do to keep me sane, day after day.

When I'm working on particularly complex software problems, I'll often talk out loud to her, explaining my thinking and proposed solution. Half the time, just the act of forcing myself to talk to her, explaining myself, helps me realize problems in my thinking.

In addition to the benefits of having a funny looking animal around at all times: knowing you've got some unconditional love no more than 2 feet away is a nice reminder life is good. Even when I'm working really hard to fix critical problems, or in the zone coding away, having a dog nearby makes me feel comfortable and happy.

Here are some pictures of Scribbles (the destroyer of worlds), in all her glory:

See the full gallery on Posterous

NOTE: Incase you're wondering--she's named Scribbles because she has scribbled markings all over her coat.

Permalink | Leave a comment »

Tools I Use - tmux

Sat, 07 Jan 2012 17:34:00 -0800

I love reading about tools other programmers use in their day-to-day existence. There are so many great pieces of software out there that it's impossible to hear about them all. Whenever I read articles (or watch screencasts) that other developers make, I tend to learn a lot.

So, I decided to start my own series here on my site, dedicated to talking about the tools I use, and how I use them. Unfortunately, I probably don't have much useful information to give in this area--but I figure that if I start writing about it, I'm bound to learn more about the tools I use along the way. So this is a win-win for me.

As this is the first article in the series, I figured what better time to discuss tmux, my favorite terminal multiplexer!

Terminal Multiplexers

If you've ever had the need to run multiple terminal windows inside an existing terminal window, you've probably heard of GNU screen.

GNU screen is one of the most popular terminal multiplexers of all time. What it allows you to do is have a large amount of virtual terminals that you can create, move around, and use at will. What's great about tools like GNU screen is that they allow you to quickly move between your terminal windows using keyboard shortcuts, which can often times be a lot quicker than alt+tab'ing to a new terminal window on your OS.

The other great thing about terminal multiplexers like GNU screen and tmux is that they give you the power to tile your windows as you please. For instance, you can run two terminals side by side, one window with code, and another with a shell for testing your code on the command line. This can be a great help in many situations.

When I first made the jump from using my OS terminal program to using GNU screen a few years ago, my productivity shot up enormously, as I was able to quickly move around through terminals like I never could before. I instantly started writing code faster, finding problems quicker, and spending much less time creating and moving terminal windows around on my desktop.

tmux - A Cool Terminal Multiplexer

While I was using GNU screen for a few years, I always had some issues with it that didn't sit well with me. For one, while I had my GNU screen software highly configured, I was still unable to perform some seemingly basic tasks like create horizontally split windows. This meant that I could only open columns of terminals, restricting the usefulness of my terminal.

Furthermore, GNU screen had a lot of complex keybindings that tended to make it difficult for me to get used to. I remember spending quite a bit of time when first learning GNU screen just memorizing the basics.

One frustrating day while I was struggling to adjust some screen keybindings, I decided to look for alternatives. After a bit of research I stumbled upon tmux. What a great day that was.

tmux, just like screen, is a terminal multiplexer. What's great about tmux is:

It's a lot simpler than GNU screen. It has sane defaults configured, and requires much less configuration to be useful.
It supports both vertical AND horizontally split windows.
It has a really awesome keybinding that allows you to magically rearrange your terminal windows in a variety of patterns. This is extremely useful for situations where you open multiple windows, and then want them to be moved to a decent looking pattern, but don't want to configure each window manually.
It has great documentation.

tmux in Action

A picture is worth a thousand words. I won't bore you any further, here are some screenies of tmux in action.

This first picture is just a simple display of tmux with multiple windows open (note the window names at the bottom):

Next, we have a single tmux window open, broken into three panes: one is vertically split, while the other is horizontally split. As you can see, this makes coding quite convenient since I can code, look at tests, and browse documentation all in the same window:

Here I just hit a single key, and had tmux automatically re-arrange my panes a few times in a row. Nice, huh?

See the full gallery on Posterous

tmux - Configuration

One of the great things about tmux is that it requires almost no configuration to be useful. Unlike GNU screen which requires quite a bit of tweaking (in my opinion) to be useful, tmux has sane defaults out of the box.

Below is my ~/.tmux.conf file. As you can see, it's very simple:

set -g prefix C-a
unbind %
bind \ split-window -h
bind - split-window -v
bind-key k select-pane -U
bind-key j select-pane -D
bind-key h select-pane -L
bind-key l select-pane -R

The changes I made are simply to remap keys for my own preferences. Here's what my changes do:

Set the tmux command key to CTRL+a (just like GNU screen). That means all tmux commands are prefixed with C-a.
To create vertical split windows, I setup keymappings for C-a |. To me, since the pipe key (|) looks like a vertical split, it makes sense to have that key open a new split window.
Likewise, I also bound the horizontal split key to C-a - (the dash key), since the dash key looks like a horizontal split.
The last few changes make moving between split windows easy. To navigate through windows, I assigned vim-like keybindings. EG:
- C-a h will move you one window to the left.
- C-a j will move you one window down.
- C-a k will move you one window up.
- C-a l will move you one window right.

As you can see, I had to make very few changes to tmux in order for it to be useful to me.

tmux - Resources

If you'd like to give tmux a try, here are some resources to get you going. tmux has become one of my favorite and most used tools since I started using it earlier last year. I'd highly recommend it to anyone who does a lot of terminal work.

The main tmux website.
man tmux - has great information and is highly readable.
tmux crash course, a really great introduction to using tmux.
tmux, a series of blog posts explaining tmux in depth. A great read.

Permalink | Leave a comment »

Going to War

Sat, 07 Jan 2012 17:31:00 -0800

Sometimes personal development can be hard, really hard. I find that I go through periods where I just feel exhausted of continuously trying to make myself a better person.

Unfortunately, I don't really see this discussed much online. I think people who write online tend to do so when they're feeling good, thereby eliminating a big amount of the negative personal development articles that would exist otherwise. Since I'm in a neutral mood right now, I figured I'd throw my opinions up here to contribute to the discussion.

Exhaustion

When I'm exhausted with personal development, I tend to not do much to fix it. Instead of consciously seeking out ways to get out of my slump, I'll usually just sit around thinking about things myself. When I get into this mood, I feel completely exhausted.

I think that becoming tired of dealing with personal development in a normal thing. When you spend a large amount of your time and energy trying to better yourself (eat better, work better, play better), it is only natural that your body and mind will need some time to rest.

The real problem arises when after you've sufficently recovered, you still can't get yourself back into the development phase again.

The War Motive

To me, nothing is more motivating than a big life or death challenge. We've all seen this in movies, and read about it in books.

The hero is hopelessly outnumbered, surrounded by bad guys. He's weak, frightened, and near death. He realizes that he's about to die, and then, his life flashes before his eyes. He immediately realizes why he's fighting in the first place, and decides to commit to winning with his life. A moment later he explodes in fury, wiping out his enemies, and emerging victorious.

The reason the hero won is because he went to war. He knew that he was in a dire situation, and he decided to do whatever it would take to win.

War can be a powerful motive, not only for heros in movies, but for you. If you find yourself stuck at a point where you can no longer progress, and find yourself battling off the forces that be but not winning--maybe you should consider starting a war.

Doing so is farily easy: you commit to winning with your life. You make a pact with yourself to fight this thing with every last ounce of energy left in your body and mind, or you die trying.

This sort of motivation is drastic, probably not recommended by psychiatrists, but effective.

I've found that the war motive works really well for me. I've used it frequently over the past few years to kick myself out of poor situations and progress regardless of whatever issues I was facing at the time.

What techniques do you use to motivate yourself, and push yourself beyond your limits?

Permalink | Leave a comment »

How to Instantly Fix Problematic Deployments on Heroku

Fri, 06 Jan 2012 20:37:00 -0800

NOTE: Have no idea what Heroku is? I feel sorry for you. You should create an account with them immediately, then come back and read this post!

Today I was working with my new co-worker on one of our company's Django projects, and after deploying some code, noticed that our NewRelic panel was spitting out loads of DatabaseErrors.

Oh shit!

In situations like this, Heroku's fabulous releases addon can really save the day. While the releases addon is still in beta, it is indespensable to any serious project. Using the releases addon, I simply ran the command: heroku rollback in the terminal, and everything was fine. How awesome is that?

The releases addon gives you an extremely useful rollback command to use, that instantly swaps your deployed Heroku code with the most recent deployed copy. This is a lifesaver. Without the releases application, you have only a few choices available to you should a disaster occur:

Revert all of your previous commits in your local Git repository, then push your changes to Heroku. This works--but takes a while to do, and can be error prone (do you know what the most recent deployed Git commit was on Heroku vs. your local repo?).
Slowly go through your most recent commits, looking to find the problem area. Once you've found the problematic code--update it, then re-push to Heroku. Again, this is time consuming and error prone.
Freak out, and run away.

All three of those options suck. The releases addon is a developer safety net, and a good one. Instead of wasting time worrying about stuff, just rollback your Heroku application, and casually debug your application looking for the problems.

In addition to the awesomeness of the simple rollback command, the advanced releases addon (heroku addons:add releases:advanced) gives you even more power: the ability to instantly deploy any revision of code previously deployed to Heroku.

Let's say you deploy several times before realizing your application is broken, and there is already an army of angry users with pitchforks heading to your cheeto-covered dungeon.

The last thing you want to do is throw on your chainmail, grab your longsword, and fight them off. Let's face reality here: you'd much rather be watching The IT Crowd and guzzling mountain dew. So instead of going to war, you decide to simply roll back to the last working release.

But wait! Your rollback command isn't working! You forgot that the last working release was several deployments ago. Damn.

Luckily, you remember that since you're using the releases addon, you can simply run heroku releases, and view a list of all your previous releases:

Oh yes, you think. Release v304 was the last working release. Just to confirm, you then run the heroku releases:info v304 command, and after taking a look to make sure, you decide that you've found the correct release to rollback to.

To finish your rollback, you simply run heroku rollback v304, and BAM, everything is working again. Now you can spend the rest of the afternoon writing a twilio script that sends text messages to each of your users en-route to your cheeto dungeon to destroy you, informing them that the problem has been solved, and asking them to return to their lairs.

Whenever you're working on production projects, problems will arise. Being a developer is no easy task! Luckily for us, Heroku is on our side.

If you're interested in using the Heroku releases addon, you should read through the official documentation, it's really great.

Permalink | Leave a comment »

New Habit - 100 Carbs

Tue, 03 Jan 2012 18:39:00 -0800

Since finishing my writing habit, I decided to kick off the new year with a health related habit.

Over the past year or so, I've been making gradual changes to my diet and exercise regimen, with the intention of losing weight, getting healthier, and getting smarter. There's a lot of evidence that suggests having a fit body also leads to having a fit mind, and that is what originally enticed me to give the whole fitness thing a shot.

When I first started dieting / exercising, I had no clue what I was doing. No clue whatsoever. I thought eating meat was bad for you and fat content in food was directly correlated to waist size. How wrong I was!

After several months of eating nothing but vegetabls and breads, running till I couldn't breathe, and struggling for every pound of weight lost, I began to actually research the whole process. I started reading numerous books on health, which foods are good for you, which foods are bad for you, etc.--eventually discovering the ketogenic diet.

A keto diet is essentially a high protein, high fat, and low carb diet. Without going into all the details, a keto diet restricts carb intake because consuming carbs increases the amount of insulin in your bloodstream. When your insulin level is high, your body stores fat. When your insulin level is low, you body doesn't.

During the three months that I maintained a strict keto diet, I lost nearly 40 lbs, and reached my lowest weight since the start of university in 2006. It felt great.

Then I started getting busy. I gained some of the weight back, and gradually let my exercise regimen slip out of control.

So starting today, I'm working my way back to where I was, to finish this thing the way I started--a success. The new habit I'm attempting to build is simple: eat less than 100 carbs per day.

I'd eventually like to cut my daily carb intake down to around 30 carbs and completely eliminate all sugar intake (sugar is bad for you), but I figure that to start, 100 carbs should be fine. Since I haven't been in hard-core dieting mode a for a while, 100 carbs is enough to make it not so difficult, while still being a challenge.

These habits are meant to last forever, after all, so I'm in no rush. I'll start with 100 carbs now, and then possibly jump down to 75, 50, and eventually 30, depending on how successful I am along the way.

Reflecting back on why I think I failed to maintain my diet / exercise regiment earlier last year--I think the primary reason was that I jumped into things too headstrong. I have always been a perfectionist by nature, and when I decide to do things, I typically dive in all the way. While this mentality has served me well in numerous circumstances, it has also backfired more times than I care to mention here.

When I eventually started to slip off my diet months ago, instead of simply getting back into the groove after a cheat day, and treating my diet as a habit (and thus, a lifestyle change), I instead ended up feeling angry with myself for messing up, and gradually drawing out the problem instead of fixing it.

Since I dove into it so headstrong before, when I did mess up, I was extremely upset with myself, and had a really hard time continuing. This time, to remedy that possibility, I'm going to be taking things a bit slower, and building sustainable changes that will (with discipline) last a lifetime.

If you'd like to learn more about ketogenic diets, here are some good resources:

The keto subreddit.
A doctor's guide to ketosis.
The Something Awful Keto Guide.
The bodybuilding.com guide to ketosis.
My personal favorite, A Guide to Ketosis.

On a side note, if you're currently working on building a health related habit, I'd love to hear about it. I'm extremely interested in health related habits and personal development.

Permalink | Leave a comment »

Writing Habit -- Complete

Mon, 02 Jan 2012 21:39:00 -0800

Two days ago I successfully completed establishing my writing habit. It took me exactly 21 days to build (I didn't mess up at all)! My habit was to write for at least 30 minutes per day.

When I wrote about what I'd learned at the half-way point, nearly two weeks ago--I think I was on the right track. The largest impact my daily writing habit has had on me has been mental. Instead of viewing writing as something challenging, it has become something enjoyable and relaxing for me. Over the past few weeks I've drastically changed the way I feel about writing.

It feels good.

Will I continue to maintain this habit in the long term? Yes. So far I've written 7 blog articles, and a number of private journal entries that I've been quite proud of. Whenever I write, I tend to learn a lot of new things about whatever subject I'm writing about. Furthermore, and quite possibly most important, writing helps me clarify my thoughts in ways that talking and reading cannot.

There's something special about writing words, stringing them into sentences, and then shifting those sentences around to construct arguments and ideas that is completely magical. Like I explained in a previous post about writing--it makes me feel like an inventor. While writing I feel like I'm Leonardo da Vinci, obsessively writing away by candlelight in a workshop long after everyone else is asleep. Only writing gives me that magical feeling.

Since I've recently finished building the habit, below are some tips you may (or may not) find useful if you too are considering developing a writing habit.

First of all--try to find (early on) a good time for writing in your day. My days are typically chaotic, as my wife's work schedule changes from day-to-day, and depending on the situation at my work I may be busy in either morning, noon, or night. I found that for me, I tend to be in the writing mood most at night time, when things are quiet and I know that I'm no longer needed for any other activities by friends, family, or work. Having a good time each day you can set aside to write may mean the difference between successfully building your writing habit, or failing.

Take caffine before writing. Seriously. I've mentioned before that I'm a caffeine junkie. While I'm not particularly proud of my addiction, I've found that caffine makes a world of difference in my writing. It helps me focus, and more importantly, makes me a lot more creative. Several times over the past few weeks I wrote in an uncaffeinated state, and during those times I seemed to mope along at best, accomplishing very little. I've found that while under the influence of caffeine I'm a lot more thoughtful, creative, and successful with my writing.

Don't restrict yourself to a single topic or genre. Before I started working on building this writing habit, I briefly considered wording it in a way that would restrict me to a particular type of writing (eg: writing a journal for 30 minutes each day, or something to that effect). I'm glad I didn't. What I realized is that some days I'm in the mood to write a private journal, while some days I'd much rather be working on a technical post, or even ranting about random things. I think that giving yourself the freedom to write whatever you want, so long as you write something, can be a great motivator and really help push you through the days where you just don't think you can do it.

Hopefully my experiences have been useful and/or entertaining to you. If there's anything you'd like to know, or if you have any questions--feel free to leave a comment.

Permalink | Leave a comment »

What I'm Doing in 2012

Mon, 02 Jan 2012 21:23:00 -0800

I'm really glad the new year is here. For the longest time I thought new year's resolutions were a bit silly, and I never participated in them. The past few years, however, I've completely changed my opinion. Maybe I'm getting older, but the thought of starting a new year makes me feel happy and optimistic about things to come. A clean slate! Let's do this!

Last year I focused on accomplishing goals. I wanted to visit San Francisco, Santa Barbara, and a slew of other things. Some of my goals were specific enough that I accomplished them, while some were way too vague and didn't materialize.

This year is going to be all about habits for me. Instead of focusing on doing specific things, I'm going to be focusing on building habits into my daily routine. Over the past year I've come to really appreciate habit building. Instead of focusing on the outcome (eg: your goals), you focus on the process.

I've found that building habits is my personal niche. It makes me feel productive, while keeping me relaxed. When I'm working on building habits I'm not constantly stressed about results, or burdered with the possibility of failure--instead, I just feel relaxed, confident, and happy. What makes this work for me is that while building habits I simply tell myself "Randall, just write for 30 mintues a day. If you can do that everyday, you'll become a better writer in no time. Don't worry about writing X amount of blog posts per week, or exercising X amount of minutes each day--just have fun with it, and make the most of each day."

Currently I'm using HabitForge to track my habits. I've been using them for just about a year now, with great success. The way HabitForge works is you tell them what habit you want to build, and each day they email you (for 21 days in a row), asking if you did your habit (yes or no). Once you complete your habit 21 days in a row, HabitForge considers your habit "done", by which time you should be so used to performing your habit day after day, that it is second nature. If you fail to complete your habit any day during the 21 day entry period, your cycle resets to day 1, and you have to complete another 21 days of your habit in a row.

What I like about the HabitForge system is that it works for me. It works really well. I find that once I start working on developing a habit, I don't want that 21-day counter to reset, so I try really hard to make sure I do my habit each day. After trying really hard for 15 days or so, it becomes much easier to do. For me, I just sort of do them on autopilot after that point.

Just yesterday I finished establishing my writing habit. It was a great success. Since I started, I've written for at least 30 minutes every day. This has made a big impact on me already. I feel much more confident in my writing, and I'm enjoying the process of writing much more than before. If I continue on this path, by January 1st, 2013 I'll have written for at least 182.5 hours. That's a lot!

Another thing I've come to thoroughly enjoy about building habits is that they don't let you fool yourself into achieving false goals. For instance, if I say I want to lose 30lbs--I could easily lose 30lbs by running everyday, eating a very low amount of calories, and generally pushing myself to lose the weight quickly; all for the sake of reaching my goal.

What if, instead of saying "I want to lose X lbs", I say "I want to eat only animal meats and vegetables"? If that were the case, I'd be building a healthy habit while losing weight as a side-effect; focusing more on the lifestyle change than the outcome.

With all that said, here are a few of the habits I've got in mind for this year. These are subject to change, but I plan on writing posts here on my blog detailing each habit I build through the year.

Spend at least 30 minutes per day working on open source code.
Spend at least one hour per day reading.
Exercise for 30 minutes per day (take a walk, do CrossFit, ride a bike--something).
Eat less than 30 carbs per day. This is a tricky one to maintain long term, but I've read quite a lot about it the past year (and done it for 3 months in a row), to great success.
Work on a business project of my own for at least 30 minutes per day.
Tidy up my apartment for 15 minutes per day.

There are also other habits I'd like to build for the long term. Stuff like going on dates with my wife a certain amount of times per month, reviewing my personal and professional progress every month, etc. Certain things like that are easily overlooked as time passes, but are things that I'd like to ensure I do so that I can make necessary adjustments to myself when necessary.

Other than the above, in more general terms, there are a lot of other things I'd like to do this year.

Over the past year I got a lot better at programming Python and Django, and this year I intend to break out of the intermediate level and enter the expert level. It's very hard for me to gauge my progress in this area as it is entirely subjective, and the field of programming itself contains limitless information that is impossible for any one person to learn. To combat this, I plan to continue building software using these technologies, learning new techniques, and tools as I go.

Another thing I'd like to do this year is slowly improve my text editing skills with vim. While I've been using vim for a long time, I still consider myself a beginner. After watching people like Gary Bernhardt use vim, not only do I feel like a complete n00b, but I'm also intensely driven to become better. My initial plan for tackling my vim deamons is to watch through every single episode of vimcasts. Since it's hard to remember the vim shortcuts right away, I'd like to watch an episode once a week, and specifically practice the video topic that week to commit the topic to memory.

I'd also like to write a book this year. I started working on a book, Learn Asterisk the Fun Way, earlier last year--but haven't made nearly as much progress as I would have liked. This year I'd like to really commit to the project, and see it through to completion. Publishing a book has always been a dream of mine, and something that would make me really proud of myself.

Here's to a having a great, happy, relaxed, and interesting 2012.

Permalink | Leave a comment »

DevOps Django - Part 4 - Choosing Heroku

Fri, 30 Dec 2011 17:43:00 -0800

This is the fourth article in a series I'm writing titled DevOps Django. If you're new, you may want to read the first part of the series before this one. In this article I'll be continuing where I left off in the previous article: explaining why I chose to move my company's teleconferencing service from Rackspace to Heroku.

Making the decision to move my company's infrastructure from Rackspace to Heroku was no easy task. As I'm sure you all know--moving infrastructure components is an enormous risk, even in the best of circumstances. However, despite the immense risk involved, a change was needed.

Time

As I mentioned earlier in this series, I work for a tech startup. With a small team of people, you don't have much time to mess around. Our greatest expense as a company is engineering time. Our company's revenue is directly correlated to our productivity. The more bugs we fix, features we deliver, and users we make happy--the more money we make.

Even though we were using the best devops tools available (puppet, nagios, etc.), we were spending almost all of our engineering time building and maintaining our infrastructure. For me, this meant a typical day ended up looking something like the following:

85% of my time spent writing or updating puppet modules to fix (or add) required functionality to our infrastructure.
10% of my time spent planning tasks, adding bugs to the tracker, updating the TODO list.
5% of my time doing actual development.

Regardless of the fact that I enjoy writing puppet modules and building a large, scalable infrastructure--it is disheartening to spend an entire month working extremely hard, building awesome backend tools, only to have nothing to show your users for your hard work. While I'm extremely happy and grateful to have learned so much about deploying robust services, a change was necessary.

When I sat down and calculated what a typical workday would look like for me if we moved to Heroku, I immediately knew we needed to make the switch, regardless of the risk. Based on my time estimates, a typical day for me (after moving all our infrastructure to Heroku) would look something like:

10% of time planning tasks, working on TODO items, etc.
90% of time hacking on our company projects.

That is a drastic change.

Going from 5% to 90% of available hacking time per day? I'll take it!

There's nothing I love more than writing code (exluding my wife and dog). Building infrastructure tools is fun and all, but in comparison to building new libraries and features? No comparison.

With the ridiculous amount of time Heroku would save each day, my company would be able to ship insane amounts of code. When I discussed this with my boss, the decision seemed clear: use Heroku.

Price

After calculating the manpower time Heroku would save, the next thing I wanted to calculate was the price. Exactly how much will it cost us to move to Heroku?

NOTE: I received a lot of price related questions when I published the last installment of this series. A lot of people emailed me saying that they'd love to use Heroku, but after looking at their prices, decided to stick with AWS or Rackspace. Hopefully this information clears up any misconceptions.

To start, I'd like to take a moment to explain Heroku's overall pricing scheme. Understanding how Heroku bills will probably answer a lot of questions.

Heroku's core service is a dyno. A dyno is essentially a long running program that:

Uses up to 512M of RAM (and can burst up to 1.5G if you don't mind swap).
Shares CPU with other dynos on the system.
Can scale horizontally as much as necessary.

For each application you have on Heroku, you get 1 free dyno per month. If you just want to run a small website, you can do it completely free of charge. For each additonal dyno you run, Heroku charges 35$ per month (5 cents per hour, at the time of writing).

Based on Heroku's simple pricing rules, you can easily gauge how much running your application will cost. What's nice about Heroku's billing is that, like AWS (which Heroku is built on top of), you pay only for your usage (per hour). This allows you to instantly scale up (and down) your dynos based on traffic. If you get a lot of hits every Friday night, you can spin up a few extra dynos to handle the load, then remove them Saturday morning, only spending a few dollars in the process.

In regards to Heroku's database pricing, here's what you need to know: every application you create can use a free shared PostgreSQL database. The free database you get allows you store as much data as you want. The catch? The free database only provides 5M of RAM for your data. That means queries will be slow; however--for a majority of sites, a shared database will suffice. What's great about the shared database is that, like their paid counterparts, Heroku manages it for you. That means no data loss, full access to your backups, etc.

Heroku's dedicated databases are much more robust than their free counterparts. In terms of pricing, their cost goes up based on the amount of allowed connections, RAM, and CPU units. Currently, the cheapest dedicated database plan costs 200$ per month, allows 16 concurrent connections, has 1.7G of RAM, and 1 CPU unit.

What's nice about the dedicated database plans (and what justifies their price, in my opinion), is that:

You get direct psql access.
They run PostgreSQL 9 (instead of 8.3).
You can instantly create read slaves, and duplicate masters (for staging, testing, etc.).
You are billed by the hour (just like dynos).
They are fully managed (you'll never lose data, or have to worry about downtime).

If you take into account what you get for those database prices, you'll see that you're getting an insanely good deal. My favorite feature is Heroku's concept of forking and following.

Let's say you have a single paid database (with the name ``HEROKU_POSTGRESQL_GREEN``), and you want to create a read slave. Heroku allows you to "follow" your existing database (``HEROKU_POSTGRESQL_GREEN``), and in doing so, automatically provisions your new database as a read slave. For instance, to provision a new read slave in the scenario I just described, I could simply run ``heroku addons:add heroku-postgresql:ronin --follow HEROKU_POSTGRESQL_GREEN``, and I'd have a new read slave up and running in a short period of time.

Similarly to Heroku's "follow" feature is "fork". Forking a database gives you a new database with a snapshot of your existing database's data. It won't stay up-to-date with changes (aka: become a read slave). This is useful for creating staging environments with real production data in them, testing schema changes, etc.

Given the amount of work it takes to create new read slaves and databases by hand (or using tools like puppet and chef), Heroku's method is infinitely simpler, and more graceful. Furthermore, in my experience, the process is very fast. When I've provisioned read slaves for my applications, they only take as long to finish building as the amount of data needed to copy over to them.

OK, let's talk about addons.

Heroku's addons are... well... perfect. All the addons I use in production: memcached, NewRelic(this particular addon is so amazing that I'm dedicating an entire section of this series to it),Redis, and RabbitMQ are all excellent.

The addons are all very farily priced (in my opinion), and have free tiers that allow you to use them at no cost with small amounts of data. Just as with Heroku's free tier, a majority of the addons' free tiers are sufficient to use for small websites without paying a dime. This lets you bootstrap your projects from the start, and pay for them as they grow.

As with Heroku's dynos, all the addons I've used provision instantly. In addition to fast provisioning--all addons can also be resized; you can downgrade or upgrade them at any time using the Heroku command line tool. This makes scaling your infrastructure components a one liner.

Hidden Cost

One thing that played an important role in our decision was the hidden cost of running our infrastructure ourselves.

When you're simply looking at basic price comparisons between services (in our case, Rackspace vs. Heroku), it's easy to miscalculate cost. In our case, we looked at the cost of Rackspace instances vs. the cost of Heroku dynos.

Since Heroku dynos give you 512M of RAM to work with, I based my initial price comparison on this factor. A single Heroku dyno costs 35$ per month, and a 512M Rackspace server costs 21.90$ per month. According to this simplistic analysis--Heroku looks approximately 1.5x's as expensive.

The hidden costs show themselves in three primary areas:

Infrastructure management cost.
Scaling cost.
Bandwidth.

Infrastructure Management Cost

Quite possibly the largest hidden cost for us was infrastructure management.

The most obvious manifestation of infrastructure management cost in our company was engineering time. As I stated above, it was not uncommon for me to spend 85% of my time (per day!) writing infrastructure related code. That's an enormous investment.

The second hidden infrastructure cost is related to building reliable services. Since my company primarily builds teleconferencing systems, high availability is a requirement. It is simply unacceptable for us to have even small periods of downtime, since we're dealing with real-time conversations.

What this meant in our case was that we needed to have multiple copies of everything. One web server? No good. One MySQL master server? No good. One load balancer? No good. One RabbitMQ server? No good. I'm sure you can see where this is going.

Having multiple backup servers ready to handle outages adds considerable expense to any infrastructure. For us, it meant we paid nearly twice as much as necessary to host our servers so that we could reliably recover from failures.

In addition to the extra server cost per month, there is also a high overhead for time required to not only build working backup and failover programs for each piece of our infrastructure, but also to build (and test) the recovery software itself, to ensure that when we do fail over, it actually works.

Scaling Cost

While not nearly as devious infrastructure management cost--scaling cost is also infrequently mentioned.

In the teleconferencing business, it is normal to get large amounts of traffic during certain hours of the day. Since our business is fairly easy to predict, dynamically resizing our infrastructure based on actual need can save a lot of money.

Unfortunately, in order to dynamically resize your infrastructure, you need to spend an enormous amount of time building tools that can do this. In my case, I spent many hours over a period of almost a year writing fabric scripts that could bootstrap new nodes (new webservers, rabbitmq servers, etc.) using the apache-libcloud library. While both fabric and apache-libcloud make writing these sorts of scripts easier, it is still a large task to do it right.

Even after writing scripts that make dynamically creating and removing servers simple--there is still a time factor involved in the actual process. For instance--booting a Rackspace server can take anywhere from 60 seconds to 5 minutes. In addition to that, once the server has been booted, the scripts I wrote would install the required base software along with puppet (to handle the node configuration). Once puppet is installed, it would take another large block of time (up to 30 minutes for some applications) to fully finish provisioning the server for usage. That's a long time.

Having a 35+ minute delay when you need to scale your infrastructure? Unacceptable.

One of Heroku's greatest strengths is their incredibly simple scaling procedures. You can instantly add and remove dynos with a single command. Furthermore, their scaling seems to be instant. There is no waiting to provision new servers, install puppet, etc.--it just works.

Bandwidth

Depending on what sort of applications you run, bandwidth pricing may be a concern for you. In my case, we don't use much bandwidth, so it was never a considerable cost--but I thought I'd mention this anyhow.

The way Heroku handles bandwidth pricing is that each application you have is allowed 2TB of bandwidth per month, included in your cost. Any more than that, and I'm assuming they'll charge you extra (although I could not find information on this anywhere on their site).

In comparison to Heroku, Rackspace charges for bandwidth in a per-gigabyte fashion. According to the Rackspace pricing calculator I used on their site, 2TB of bandwidth on Rackspace can cost you an additional $368.64 per month. That's a lot in comparison to the 0$ you'd pay for the same amount of bandwidth using Heroku.

Summary

After analyzing the costs (both obvious and hidden) of both keeping our setup the way it was, or switching to Heroku; we decided overwhelmingly to move to Heroku.

In terms of usefulness, simplicity, elegance, and cost--there is absolutely no comparison. For my company, using Heroku was clearly the best choice to make.

Since switching to Heroku, my company has saved lots of money on server costs, and even more money in engineering time. Since the switch, we've completed more features, bug fixes, and have overall accomplishd more than at any other point in the year. The effect has been tremendous.

In the next part of this series, I'll be discussing how I actually moved my company's infrastructure from Rackspace to Heroku. I'll get into the technical details, and explain the entire setup from start to finish.

Permalink | Leave a comment »

My "Done" List

Sun, 25 Dec 2011 00:08:00 -0800

I really enjoy thinking and writing about programming. Since I started writing code years ago, I've been obsessed with code quality and best practices--and I think it's safe to say that a lot of hackers out there feel the same.

I'm pretty sure my urge to write excellent code is driven by some innate desire to perfect everything; regardless, I stopped trying to fight it long ago, and started embracing it.

Disclaimer: what I'm about to discuss is stupidly obvious. I actually feel quite stupid writing this; however, since this has made such a large impact on my code quality and programming mentality, I figured I would share it despite my shame.

Have a "Done" List

One of the greatest productivity tricks I've learned has been this: always have a "done" list.

A "done" list is checklist that you use as a personal binding contract. Having a "done" list means making a commitment to yourself that each time you touch a piece of code, you don't consider it "done" until you've completely gone through your checklist.

For instance, my "done" list is:

Purpose of what I'm doing is logged in some form of tracking system (GitHub Issues, sprintly, etc.).
Tests are written.
Code implemented.
Tests pass.
Code review.
Documentation written.
Deployed.

If that means it takes a while longer to code, then so be it. A "done" list is a simple way to hold yourself to a high devleopment standard, and consistently write quality code.

I've found that even when I'm not able to consistently go through my "done" list every time I touch code--through the process of trying to meet each of my "done" requirements, I write much better code than I would otherwise.

Do you have a "done" list? If so, what's on it?

Permalink | Leave a comment »

What I've Learned About Writing (So Far)

Mon, 19 Dec 2011 22:23:00 -0800

As I mentioned a few days ago, I've been working on establishing a writing habit in my daily life. Today marks the 10th continual day, since starting, that I've been writing for at least 30 minutes a day.

I figured now would be a good time to reflect on what I've learned so far. Above all else, what I've learned so far is that

Practice Works

I've read numerous books on skill building, including one of my all time favorites, Talent is Overrated (affiliate link). The book discusses how people who are excellent at what they do become excellent. The secret is: disciplined practice. Top performers (in all fields) set aside time each day to practice what they are bad at, and struggle through exercises.

Focused practice over longs periods of time builds skill. There are no shortcuts.

While I've always enjoyed writing casually, this has been the first time in my life that I've actually set aside time each day to sit down and write for a specific timeframe.

Although it has only been 10 days so far, I've noticed that my continued practice is already making a difference. So far the difference doesn't seem to be in my writing itself, but in my attitude towards writing.

I've noticed that I've been able to write with a much higher level of joy in the past few days than at any previous time in my life. Maybe this is just an emotional side effect of the continuous success I've had in sticking to my schedule for the past 10 days--but I have been enjoying writing a lot more than normal.

Furthermore, I've become a lot less rigid with my writing. As a perfectionist, I've always had problems expressing my thoughts on paper. When I would attempt to write, I'd spend long periods of time working out each sentence in my head perfectly before writing it down. This behavior tended to eat up a lot of momentum.

Since I've started writing daily, I've been able to simply type what I'm thinking, gradually refining it. This feels great. It feels like the shackles that have held me back from expressing my thoughts are beginning to loosen.

Goals

I don't have any specific goals in regards to my writing at the moment. At least for a while, I'd like to simply continue writing for 30 minutes each day, and gradually become better at expressing my thoughts in a clear, concise, and structured way.

I'm hoping that as I practice writing more and more, it will become more natural for me, and I'll be able to experience a greater feeling of relief and happiness while writing.

Permalink | Leave a comment »

DevOps Django - Part 3 - The Heroku Way

Sun, 18 Dec 2011 16:15:00 -0800

This article is part of a series I'm writing called DevOps Django, which explains how to best deploy modern Django sites. If you're new, you should probably read the first article of the series before this one.

My Search for Solutions

In the previous installment of this series, I discussed (in depth) the problems with deploying Django as a devops guy. After struggling with deployment for ~2 years, and finding very little relief in modern devops tools (puppet, monit, nagios, etc.), I started looking for new solutions.

Several months ago I was reading Hacker News and noticed that Heroku had recently added Python support to their platform-as-a-service stack. If you're not familiar with Heroku, they're a very popular ployglot hosting platform. They've been around since 2007 providing Ruby hosting, but over the past year they've added support for multiple languages, and seem to be kicking ass and growing like mad.

I've continuously heard their name mentioned by other programmers, but this was the first I'd heard of them having any Python support, so I bookmarked their Django tutorial and told myself I'd give it a spin sometime.

Coincidentally, a few weeks later I was asked to give an impromptu lightning talk during apyladies hack-a-thon, so I decided to give Heroku a spin, and do my lightning talk on that. In a weird twist of fate, the few hours I spent learning Heroku turned out to be some of the best invested hours of my life.

During the hack-a-thon I built and deployed a simple Django site (with celery support) in just under an hour. If I were to build the same site and attempt to deploy it on EC2, I'd have easily spent a week getting things deployed using puppet, monit, nagios, etc.

After the hack-a-thon ended, I decided to play around with Heroku a bit more, and see what the platform really had to offer other than what I used during my short sprint.

A Second Look

Later that week, I had a few hours to kill, so I revisited Heroku's website, and read through all their help resources and tutorials. I also took an in-depth look at their addons, trying to decide what their services could be used for: personal projets, business ideas, work projects?

The first thing I was blown away to discover is that Heroku has an enormous amount of addons. They literally have addons for almost any piece of infrastructure you could ever want:PostgreSQL, Redis, cron, memcached, RabbitMQ, Solr, etc. Upon seeing this, I started to get excited.

Second, I took the opportunity to play around with their extremely easy to install and use CLI tool, and was blown away again. Heroku's CLI tool gives you complete control over your Heroku applications. You're able to create new Heroku applications out of Git repositories, instantly provision addons for your application (PostgreSQL, Redis, etc.), view streaming logfiles, instantly scale up (and down) your nodes, etc. Furthermore, you're able to run shell commands locally using their CLI tool. Need to access the Django shell? No problem, you can simply execute ``heroku run python manage.py shell`` from your terminal.

By this point, I was really itching to use Heroku for something serious.

While I was able to build and deploy a simple Django site on Heroku in under an hour during the hack-a-thon, I knew that I needed to port a much larger, more complex site over to Heroku to really see if it could meet my professional needs.

So, I checked out a fresh copy of the teleconferencing service that I develop at work, and got to it.

How I Ported My Work Application to Heroku

If you'd like to see details about what technologies the teleconferencing service uses, check out the previous part of this series. As the teleconferencing service is large, complex, and infrastructure heavy--I figured that if I could port it to Heroku then I'd be able to use Heroku for almost anything.

The first thing I did was create a new Heroku application using their CLI tool: ``heroku create --stack cedar``, then deploy my application to Heroku using Git: ``git push heroku master``.

Secondly, I installed a few addons so I could use my required infrastructure components (RabbitMQ, memcached, PostgreSQL, and cron):

``heroku addons:add rabbitmq``
``heroku addons:add memcache``
``heroku addons:add shared-database``
``heroku addons:add scheduler``

NOTE: By leaving off the size of the addons at the end, you install the cheapest (smallest) plan for each service. By adding these addons just as I've shown above, it adds 0$ per month to your bill.

Next, I modified my production settings file (``project/settings/prod.py``, in my case), to work with Heroku's hosted RabbitMQ, memcached, and PostgreSQL services. In the end, my settings file looked something like this:

"""Production settings and globals."""


from os import environ
from sys import exc_info
from urlparse import urlparse, uses_netloc

from S3 import CallingFormat

from common import *


# Helper lambda for gracefully degrading environmental variables:
env = lambda e, d: environ[e] if environ.has_key(e) else d


########## EMAIL CONFIGURATION
# See: https://docs.djangoproject.com/en/1.3/ref/settings/#email-backend
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'

# See: https://docs.djangoproject.com/en/1.3/ref/settings/#email-host
EMAIL_HOST = env('EMAIL_HOST', 'smtp.gmail.com')

# See: https://docs.djangoproject.com/en/1.3/ref/settings/#email-host-password
EMAIL_HOST_PASSWORD = env('EMAIL_HOST_PASSWORD', '')

# See: https://docs.djangoproject.com/en/1.3/ref/settings/#email-host-user
EMAIL_HOST_USER = env('EMAIL_HOST_USER', 'your_email@example.com')

# See: https://docs.djangoproject.com/en/1.3/ref/settings/#email-port
EMAIL_PORT = env('EMAIL_PORT', 587)

# See: https://docs.djangoproject.com/en/1.3/ref/settings/#email-subject-prefix
EMAIL_SUBJECT_PREFIX = '[%s] ' % SITE_NAME

# See: https://docs.djangoproject.com/en/1.3/ref/settings/#email-use-tls
EMAIL_USE_TLS = True

# See: https://docs.djangoproject.com/en/1.3/ref/settings/#server-email
SERVER_EMAIL = EMAIL_HOST_USER
########## END EMAIL CONFIGURATION


########## DATABASE CONFIGURATION
# See: http://devcenter.heroku.com/articles/django#postgres_database_config
uses_netloc.append('postgres')
uses_netloc.append('mysql')

try:
    if environ.has_key('DATABASE_URL'):
        url = urlparse(environ['DATABASE_URL'])
        DATABASES['default'] = {
            'NAME': url.path[1:],
            'USER': url.username,
            'PASSWORD': url.password,
            'HOST': url.hostname,
            'PORT': url.port,
        }
        if url.scheme == 'postgres':
            DATABASES['default']['ENGINE'] = 'django.db.backends.postgresql_psycopg2'
        if url.scheme == 'mysql':
            DATABASES['default']['ENGINE'] = 'django.db.backends.mysql'
except:
    print "Unexpected error:", exc_info()

#DATABASE_ROUTERS = ('settings.routers.MasterSlaveRouter',)
########## END DATABASE CONFIGURATION


########## CACHE CONFIGURATION
# See: https://docs.djangoproject.com/en/1.3/ref/settings/#caches
CACHES = {
    'default': {
        'BACKEND': 'django_pylibmc.memcached.PyLibMCCache',
        'LOCATION': 'localhost:11211',
        'TIMEOUT': 500,
        'BINARY': True,
        'OPTIONS': {
            'tcp_nodelay': True,
            'ketama': True,
        }
    }
}
########## END CACHE CONFIGURATION


########## CELERY CONFIGURATION
# See: http://docs.celeryproject.org/en/latest/configuration.html#broker-transport
BROKER_TRANSPORT = 'amqplib'

# See: http://docs.celeryproject.org/en/latest/configuration.html#broker-url
BROKER_URL = env('RABBITMQ_URL', '')

# See: http://docs.celeryproject.org/en/latest/configuration.html#celery-result-backend
CELERY_RESULT_BACKEND = 'amqp'

# See: http://docs.celeryproject.org/en/latest/configuration.html#celery-task-result-expires
CELERY_TASK_RESULT_EXPIRES = 60 * 60 * 5
########## END CELERY CONFIGURATION


########## STORAGE CONFIGURATION
# See: http://django-storages.readthedocs.org/en/latest/index.html
INSTALLED_APPS += (
    'storages',
)

# See: http://django-storages.readthedocs.org/en/latest/backends/amazon-S3.html#settings
DEFAULT_FILE_STORAGE = 'storages.backends.s3boto.S3BotoStorage'
STATICFILES_STORAGE = 'storages.backends.s3boto.S3BotoStorage'

AWS_CALLING_FORMAT = CallingFormat.SUBDOMAIN

AWS_ACCESS_KEY_ID = env('AWS_ACCESS_KEY_ID', '')
AWS_SECRET_ACCESS_KEY = env('AWS_SECRET_ACCESS_KEY', '')
AWS_STORAGE_BUCKET_NAME = env('AWS_STORAGE_BUCKET_NAME', '')

STATIC_URL = 'https://s3.amazonaws.com/%s/' % AWS_STORAGE_BUCKET_NAME
########## END STORAGE CONFIGURATION


########## WEBSERVER CONFIGURATION
# See: http://gunicorn.org/
INSTALLED_APPS += (
    'gunicorn',
)
########## END WEBSERVER CONFIGURATION


########## SECRET KEY CONFIGURATION
SECRET_KEY = env('SECRET_KEY', '')
########## END SECRET KEY CONFIGURATION

As quick note, everytime you push code to Heroku, they automatically read your top-level ``requirements.txt`` file, and install any packages you've defined. This makes handling site dependencies completely transparent to you (the developer). In order to get my site working on Heroku, the only change I had to make to my requirements file was adding ``django-pylibmc-sasl``, as the Heroku memcached addon requires SASL authentication, which the commonly used ``python-memcached`` library doesn't provide.

Just for clarity, here's my ``requirements.txt`` file:

Django==1.3.1
docutils==0.8.1
psycopg2==2.4.2
Fabric==1.3.2
South==0.7.3
gunicorn==0.13.4
newrelic==1.0.5.156
django-celery==2.4.2
django-kombu==0.9.4
django-storages==1.1.3
boto==2.1.1
pylibmc==1.2.2
django-pylibmc-sasl==0.2.4
django-sorting==0.1
django-guardian==1.0.3
django-pagination==1.0.7
pyst2==0.4
django-annoying==0.7.6
django-tastypie==0.9.11
django-coverage==1.2.1
django-nose==0.1.3
nosexcover==1.0.7
django-debug-toolbar==0.8.5
Sphinx==1.1.2
django-cache-machine==0.6

As you can see in the settings file, Django is simply using environment variables to interact with the various infrastructure components we added earlier. All of Heroku's addons work by exporting one (or more) environment variables that your application can use. This makes using Heroku addons extremely convenient. You can reuse most of your Django settings across all your projets, since you're storing the important stuff in environment variables. No coupling required.

Additionally, the Heroku CLI tool also allows you to set, edit, and remove your own environment variables. I used this functionality to set my application's ``SECRET_KEY``, along with other arbitrary stuff (like my Amazon S3 credentials, etc.). To add these environment variables to my Heroku application, I simply ran: ``heroku config:add SECRET_KEY=xxx AWS_ACCESS_KEY_ID=xxx ...``.

The next thing I did was define a top-level file, ``Procfile``, which Heroku uses to specify the different types of 'dynos' you'll be running. Essentially, a Procfile just lists a series of executable commands that do stuff. Here's the Procfile I wrote:

web: python project/manage.py run_gunicorn -b "0.0.0.0:$PORT" -w 3 --log-level info --settings=settings.prod
scheduler: python project/manage.py celeryd -B -E --settings=settings.prod
worker: python project/manage.py celeryd -E --settings=settings.prod

Each line contains a reference name, followed by the command you want to run. In my case, I've got three separate 'dyno' types: a gunicorn instance (this is my actual Django web application), a celerybeat instance (for scheduling periodic tasks), and a celery worker instance (for processing asynchronous tasks).

The way Heroku runs and manages your application is via these dyno types. For instance, let's say I want to have Heroku run three 'web' instances (this is the equivalent of running three separate web servers), I could run: ``heroku scale web=3`` from the CLI, and Heroku would instantly ensure that three of my 'web' dynos are running--automatically load balancing incoming HTTP requests across the three.

NOTE: You can run ``heroku ps`` to see what processes (and how many of each) are running.

After defining my ``Procfile``, I just ran ``heroku scale web=1 scheduler=1 worker=1``, and Heroku instantly spun up my entire cloud infrastructure.

INSANE

NOTE: If you are running celerybeat, be sure to only run it a single time, and no more. If you have multiple celerybeat instances running, you'll have duplicate tasks in your queue. That's why I specifically created two separate celery dyno types, "scheduler" and "worker", so that I could safely scale my worker processes using: ``heroku scale worker=x``, while keeping only a single scheduler.

A Quick Recap

It took me a total of ~2 hours to:

Make a large website and API completely Heroku compatible.
Fully provision a PostgreSQL server.
Fully provision a memcached server.
Fully provision a RabbitMQ server.

And don't forget--this is the amount of time it took me while still learning about Heroku, and reading through the documentation. I think it is fair to say that if there were more tutorials, articles, and information available, this process could be shortened substantially.

I'll repeat this again: that is INSANE.

Compared to the time, effort, and maintenance required to setup my teleconferencing application normally using a standard devops toolset, this was a piece of cake. I didn't have to provision a puppet server, manage a puppet repo, or anything.

Heroku makes deployment so easy, you don't even need a fabfile.

The Heroku Way

Through the process of learning, using, and eventually moving my company's entire infrastructure over to Heroku, I learned quite a bit about Heroku's ideals.

In my first article discussing the "deployment problem" in the Django community, I said that I have a dream for the Django community; a dream that all Django developers can build their websites with peace of mind, knowing a production deployment is no more than 10 minutes away.

Heroku is quickly making my dream a reality.

The "Heroku Way", as I refer to it now, consists of a few simple principles:

Build your Django sites using standard open source tools.
Use Git to manage your deployment revisions.
Instantly provision, resize, or remove any infrastructure components you need.
Keep your private data decoupled from your codebase via environment variables.
Instantly scale your infrastructure up and down as you please.
Pay by usage.

After having tried numerous deployment methods myself, and after using Heroku, I strongly believe that Heroku's approach to solving the deployment problem is the right way. As a developer, using Heroku is a big win:

You can deploy both small and large sites the same way (and scale them as large as you'd like with no added complexity).
It's cost effective (Heroku's prices aren't much more expensive than Amazon's, which Heroku is built on top of). I'll go into more depth on this in my next article.
You aren't locked into anything: the same codebase you use to develop your site locally can be used on Heroku in a matter of minutes.

Deploying code to Heroku feels right. As a developer, you shouldn't have to spend 90% of your time writing puppet rules and working with vendor APIs to provision servers. You shouldn't need two weeks to scale your site when you get an influx of users.

Instead, you should be coding--which is precisely what Heroku is designed to help you do.

In the next part of this series, I'll be detailing my decision to move from Rackspace to Heroku. Making an infrastructure move is a big decision. In the next article I'll discuss my reasoning with you.

PS: If you read this far--I'd like to ask you a question. Would you be interested in a book about Django deployments? If so, what sort of topics would you expect to be covered?

UPDATE: I've finished the next part of the series! You can read it here.

Permalink | Leave a comment »

system76 "Bonobo" Ubuntu Laptop Review

Wed, 14 Dec 2011 20:00:00 -0800

See the full gallery on Posterous

I don't normally write product reviews on my blog (although I do frequently write amazon reviews), so this is a bit out of place. However, I feel the need to write about the system76 laptop I recently purchased.

NOTE: I'm not making any money off this. I'm not in any way affiliated with system76. I don't have any affiliate links, or any of that jazz.

As a programmer (and more importantly, nerd) I spend a majority of my days (and nights) online. As a linux guy, finding a decent laptop that has full hardware compatibility can be a huge pain. Over the past year I've been using a laptop as my primary machine, which has compounded this issue and made it a nightmare for me to find new laptops when an old one dies. Incase you're wondering, I've gone through 4 laptops this past year, and each time spent no less than 4 days finding a suitable replacement.

The problem with finding a decent linux laptop is that even if you google the exact model you plan on purchasing before hand, there is no guarantee it will work. At least in my experience, googling laptop models before purchase is a lot like playing Russian roulette--you may get lucky, but it's a risk.

The last time I purchased a laptop earlier this year I spent quite a while online researching the best options, eventually settling with a high end HP that was within my price range. Fast forward two weeks to delivery day--I'm installing Ubuntu on the laptop, and to my dismay, there are no video card drivers available. Damnet.

system76

After having several awful linux laptop experiences, I asked some friends to recommend a decent hardware vendor with full linux support. That's when I first heard of system76. They're a hardware vendor that builds and ships Ubuntu ready laptops, destkops, and servers.

A few weeks back, when my current laptop started dying, I decided to give system76 a try and I ordered their Bonobo model (their largest laptop). I got the base model with a couple small modifications:

A 120G SSD drive (I like speed).
8G of RAM.

I decided to go with their largest model (it's a 17.3") because I love looking at lots of code on a single screen. I don't use any external monitors, so having a large screen is important for my day-to-day workflow.

With the background out of the way, here's my review of the actual laptop.

First Impressions

system76 did a great job on first impressions. You know how most laptops typically come in awful boxes, filled with tons of spam? system76 doesn't do that at all. The shipping box was simple, easy to open, and not cluttered.

Inside their shipping box there was simply the laptop, the carrying case, and a card with links to the system76 website for help. Elegant.

My first thoughts upon seeing the actual laptop (once I pulled it out and set it on my table) was: woa. The laptop is really big and sturdy looking. It's got a metallic casing around it (not plastic), and looks expensive. The lid of the laptop has the system76 logo etched into it, which looks brilliant.

The screen on this thing is amazing. It's huge, clear, and surprisingly crisp. Maybe I've just been using shitty laptops 'till now, but this thing makes my old Sony Vaio look like a child's toy.

The keyboard is sturdy with thick, responsive keys. This is a big win for me, as I type fast, and having highly responsive keys just feels right.

Also: there are no stickers on the laptop. I hate getting a new machine covered in Intel, Windows, and other ridiculous stickers. This gives the laptop a really nice clean look, and it's refreshing to not be bombarded by hardware ads.

Software Support

After working my way through the first boot process just to see what it was like (it was fine), I popped in my own Ubuntu 11.04 CD and formatted the box. I was curious to see if this laptop was truly linux compatible, or if it was just loaded with a bunch of special drivers to make things work decently.

Surprisingly, I had absolutly no issues installing Ubuntu. Everything worked perfectly out of the box. Webcam, microphone, video card drivers, etc. It was a pretty great feeling to get everything installed fresh with no issues whatsoever.

Speed

This thing is fast. Really, insanely fast. I don't have much else to say about this, except that I've never had such a fast system. Ubuntu boots in less than 2 seconds, consistently.

Pricing

If you've ever purchased a laptop online from a major hardware vendor (Dell, HP, etc.), you'll notice that when customizing the laptop components, you've got a million choices. It's typical to be able to choose from at least 20 different CPUs, 30 times of RAM, etc.

From what I saw, system76 takes a different approach. All their base systems have excellent hardware, and they only offer a few upgrade options. I prefer this a lot more to the traditional model. Why? Because pricing is a lot clearer. Instead of purchasing a laptop that you think will cost 500$, and then upgrading it to make it decent and then realizing that the price is now 3,000$--you know right off the bat what sort of price you're looking at.

While this laptop was expensive (I paid ~1,800$), its hardware stats are comparable to similarly priced HP laptops.

Problems

NOTE: I've only been using this laptop for two weeks so far. If I experience any other problems I'll update this post to include them.

The power key. The most annoying problem I've had with the laptop to date is the power key. It's hard to press. I can push it down easily enough, but it seems like you have to push it down and hold it for a second for it to actually recognize your keypress. This is pretty annoying as it takes me at least two tries to turn the thing on.

The caps lock / num lock / wifi icons that light up when they're on are ugly. They look like they're pixelated globe icons from the 1980s. system76--if you read this, consider using something a bit nicer looking. They really detract from the clean, professional look of the laptop.

Lastly, the power cable for this thing is massive. The laptop doesn't use your standard size power cord, it has a massive black box at least 3x's larger than any laptop cord I've owned before. While I understand this is the largest model of laptop, and it has high end power-hungry hardware, the cord size still matters (at least to me). I haven't carried this laptop anywhere with me yet, but I assume that when I do, my carrying case will be at least a few pounds heavier with the cord inside.

Conclusion

system76 makes a damn good laptop, as far as I'm concerned. Despite a few minor flaws, this thing has been excellent. I can honstely say that I've never owned such a great laptop in my life.

It's fast, sturdy, looks great, and has perfect linux hardware compatibility.

If you're a linux guy looking for a great laptop, I'd strongly recommend you give system76 a shot for your next purchase.

You can check out all their systems on their main site: http://www.system76.com/

Permalink | Leave a comment »

Establishing a Writing Habit

Tue, 13 Dec 2011 18:51:00 -0800

I'm a big fan of personal growth and development. My thought on the matter is that each of us is only given a little time to live, so we might as well make the most of it. Improving yourself is always a good time investment.

A few years ago I started building positive habits. I read a few books, and learned that one of the most effective ways to cultivate yourself is by slowly building positive habits into your daily routine, one at a time. Shortly thereafter I discovered HabitForge, a webapp that helps you build new habits by sending you daily email reminders and tracking your progress.

Let's say you want to read for 30 minutes every day. According to the research HabitForge has done, if you force yourself to read 30 minutes a day for 21 days in a row, your 30 minutes of reading will have become a natural habit. Of course, your habit won't come completely naturally (you will still have to put fourth conscious effort to do it each day), but it will be significantly easier for you to maintain day after day.

The catch is that if you break-the-chain, you have to start your 21 day habit building cycle fresh. This means that if you read for 20 days in a row, but on the 21st day forget--you're our of luck. You'll need to start again from day 1, and work through a full 21 day period before your habit will become second nature.

The great thing about the 21 day method is that it seems to work (at least it does for me). Last year I built several habits that I've kept since. My only regret is that I didn't continue to add more habits after successfully establishing a few great ones.

Which brings me to the topic of this article...

Writing

I've always enjoyed writing. It appeals to my sentimental side. There's something about writing that just feels great. The best way I can describe the way I feel when writing is:

Imagine Leonardo da Vinci in his workshop in Italy in the late 1400's. He's been obsessively locked up in there for weeks on end buliding a new prototype. It's late at night, and there are papers scattered across his desk. He's sitting on a wooden stool, hunched over the desk working by candlelight, madly scribbling his discoveries using a feather pen into an extremely aged looking notebook.

That's how writing makes me feel.

Unfortunately, while I have written quite a lot over the past few years--I've come nowhere close producing either the quality or quantity of writing that I'd like to.

A few days ago I started a new habit on HabitForge, my first one in a few months--dedicated to writing. I'm going to make "writing for 30 minutes" a daily part of my routine. It isn't much, but I'm hoping that 30 minutes of intensely focused writing will help me grow as a writer.

If you're one of the few people who do actually read what I write on here, you can expect to see more frequently articles in the coming days and weeks.

If you're looking to build new positive habits into your life, why not make an account at HabitForge (it's totally free) and get started?

UPDATE: I wrote some reflections on my habit so far, you can read them here.

UPDATE: My writing habit is built! I've written for 30 minutes for each of the 21 days without fail. I wrote another post which also includes some tips and thoughts, you can read it here.

Permalink | Leave a comment »

DevOps Django - Part 2 - The Pain of Deployment

Mon, 12 Dec 2011 22:30:00 -0800

This article is part of a series I'm writing called DevOps Django. This series is meant to explain how to best deploy modern Django sites. If you're new, you should probably read the first article of the series before this one.

What I Build

As I mentioned in the first article of the series, I work at a tech startup building telephony services. Our primary product is a hosted teleconferencing platform that hundreds of thousands of callers use each month. As all my experience with deployment has (primarily) come from building and maintaining this platform, I'd like to take this opportunity to explain what I actually build.

Our product is broken up in two primary components: a telephony layer that powers our core teleconferencing service, and a web layer that powers our API backend and user portal. Having two completely separate (and isolated) infrastructures means having to deal with multiple deployment patterns.

Our telephony infrastructure is built on top of:

ubuntu-server, a great Debian based operating system.
Asterisk, the open source PBX engine.
OpenSIPS, the open source SIP router.
Cisco hardware (for routing physical calls over multiple DS3 circuits).
NFSd, for storing large amounts of sound files.

The majority of our telephony code is written in Asterisk's custom scripting language (dialplan). This language lets us completely control call behavior. With it, we can do things like:

Play sound files.
Record sounds.
Bridge multiple calls together.
Recognize touch tone input and perform other actions.

Here's a small diagram which shows how our physical infrastructure is architectured (excuse my poor diagrams, I'm awful with this stuff):

The way things work here is that callers (eg: you) dial our phone number on your cell phone (or landline, whatever) and your call travels through the PSTN (public telephone network). Your call eventually arrives at our Cisco equipment, which converts the calls from hard line formats into VoIP, so that we can easily move the call around our network.

From there, your call is sent to our load balancer (OpenSIPS), which determines which Asterisk server should handle your call. At this point, your call is then sent to Asterisk, which does whatever needs to be done.

The NFS server is used to store user generated soundfiles. This way, our Asterisk servers can remain stateless (we can simply plug more Asterisk servers into our network at any time to increase capacity).

Where things get interesting is our web infrastructure. Our web stack provides lots of functionality to our systems, including:

The ability to manage conference rooms in real time. This includes stuff like muting callers, banning callers, changing caller nick names for easy identification, etc.
Centralized logging of all user metrics: which conference rooms they use, how often, what features they use the most.
Billing integration that allows us to track how many minutes are being used by each conference room.
Account management for users (and administrators).
An API that our telephony infrastructure uses to communicate with us.
Other cool features that I won't get into.

Our web stack WAS built using the following technologies:

NOTE: I'm choosing to list the old technologies here as this article is focused primarily on my original problems deploying Django. While I've solved a majority of my problems, that will be discussed in a future part of this article series.

Python, our favorite programming language.
Django, our favorite web framework.
RabbitMQ, a useful queueing system.
Celery, a distributed task queue.
Memcached, a simple caching server.
FreeRADIUS, an annoying and stupid (but necessary) system for logging call metrics.
MySQL, an incredibly frustrating database server.
Git and GitHub, for version control.

And this is a list of our old infrastructure tools (most of these are gone now in our new environment):

Puppet, a centralized configuration management service. Essentially, it allows you to write scripts that automatically configure your servers in a modular fashion.
monit, application monitoring software we used for automatically fixing critical problems and sending alerts. It lets you do stuff like say "send me an alert if the CPU usage on this box goes above 50%".
munin, a simple monitoring tool that generates useful graphs (network traffic, CPU usage, etc.).
nagios, a popular system monitoring tool.
HAproxy, the fast HTTP load balancer.
nginx, our web server of choice for buffering HTTP requests locally to our WSGI server.
gunicorn, a unicorn with a gun. OK, not really... It's actually a pretty awesome pure python WSGI server.
Jenkins, a simple continuous integration server for running tests and deploying code to production.
Rackspace, our server host.

These are the core technologies that we used to develop our web stack over the past two years (up until a few weeks ago).

I've taken the liberty of drawing this up in a small diagram (again, excuse my poor diagramming skills):

As you can probably imagine, we use Python and Django to build our website and backend API. These are the core technologies that power our web services. RabbitMQ holds our queued tasks, and Celery processes the queued tasks and executes them on worker servers asynchronously. Memcached is used to store data in memory for fast retrieval (stuff like lists of banned callers, etc.) and MySQL was used to store all of our persistent data.

FreeRADIUS is really in a leage of its own, as we use it exclusively to track call metrics from our physical Cisco devices. Most high end Cisco equpiment supports radius logging, so we have a FreeRADIUS instance running at all times to track our physical call metrics (which calls enter and leave our network before ever talking to our telephony servers), as this data is far more accurate than data that arrives via API calls (due to timing issues across the network).

In regards to our monitoring software (puppet, etc.) we used quite a mix. The reason being that no one piece covered all our basic requirements. For our services, we wanted to have the following:

Alerts when stuff goes down.
The ability to automatically fix weird issues (restart services that stopped, etc.).
Graphs to show CPU usage, memory usage, etc., so that (as a devops guy) you can scale your infrastructure as necessary, spot bottlenecks, etc.
The ability to automatically provision new servers. Manually provisioning servers is:
- A waste of time and energy.
- Error prone (what if you forget to do something?).
- Not scalable.
The ability to quickly and easily confirm things are working.

A lot of our core functionality comes from the integration between our telephony services (which are colocated at various datacenters around the US), and our centralized cloud platform. Due to the dynamic nature of our architecture, our web platform is extremely important. If our web platform goes down, our users see a majority of their features vanish instantly, as we can't log usage data, perform authentication checks against users, etc.

With both parts of our stack working together, we're able to give our users a really great experience both through their phone and browser.

Why Deployment was Painful

As our product focuses on real time user communication, we have a lot of technical challenges. Our service needs to:

Provide fast interaction between our physical telephony infrastructure and cloud infrastructure.
Provide accurate logging information for billing.
Maintain high availability for our systems, as even a minute of downtime effects thousands of callers.
Rapidly push changes to our applications in production with no maintenance windows.

With our intense availability requirements, I'd say that (up until our recent infrastructure change), I was spending about 90% of my time working on either maintaining our infrastructure and tools, updating components, automating components, or scaling our components.

Given the fact that we have so many different technologies (a lot of them requiring their own servers and redundancy), complexity couldn't be helped--even using modern tools like puppet, monit, nagios, etc.

If you're into devops type stuff, you might be wondering what problems I had given my setup. After all, a majority of the technologies I was using are quite popular in high-tech circles. People look at you funny if you work at a tech company that doesn't use puppet (or chef) and nagios. These tools have a reputation for making your life easier (as a developer), and supposedly let you focus more on coding than sysadmin taks.

Despite the hype, building out your infrastructure and monitoring tools is hard. Really hard. If you want to do it right.

Firstly, let's talk time. The time required to learn all of the infrastructure technologies we used was immense. As anyone who knows me can attest, I spend a ridiculous amount of time programming. Even with the insane hours I consistently pull hacking code, it took a long time before I was able to build quality puppet modules, monitoring scripts, and deployment tools.

Once we started heavily using our infrastructure toolset: puppet, nagios, monit, etc., I found that I'd spend at least 90% of my time throughout the workday either:

Writing new monitoring and deployment modules.
Fixing bugs in old monitoring and deployment modules.
Dealing with random one-off issues that occur because of slight differences in production environments.

Since my company is small, and engineering time is our most valuable resource, this was a real killer.

Secondly, hosting cost becomes an issue. When you require high availability for your services, you can't run just one of anything. This led to a ton of overhead cost on Rackspace, as we had at least two of everything running constantly. Ouch. Not to mention the time it took to engineer the backups / restoration / monitoring tools so that they would actually be useful in the event that a service died.

For the longest time I always assumed builiding failproof services would be easy. How wrong I was! Even the simplest of services, take RabbitMQ for instance, requires an immense amount of planning, thought, and maintained focus to build properly. In an environment where you rely on that RabbitMQ server being available 24x7 with as many nines of availability as possible, even the simplest of services can become an enormous pain.

Engineering failover that works is an art. A time consuming art.

Third, MySQL. ARG! Ever tried to automate MySQL deployments? I dare you to build a puppet module that can successfully spin up MySQL replication slaves on demand. It is so painful that I'd rather slap myself in the face with a porcupine than attempt that again.

NOTE: I tried endlessly to find (and build) a decent puppet-mysql module. I found numerous semi-maintained ones on GitHub, but never found a single working one. The one I ended up building myself (and using) was so tightly coupled to my specific deployment scenario that I actually still wake up in hot sweats on occasion just from thinking about it.

MySQL is annoying to manage in production.

Fourth, complexity. Having so many tools deployed just to keep things running is a real pain. Not only is it a time sink, expensive, and hard to maintain--it is complex.

Complexity gets you in subtle ways.

For me, complexity manifested itself in coupling issues. With such a large amount of scripts, tools, and services--making a change anywhere in the codebase was likely to break some part of our deployment or monitoring toolset. This was especially annoying, as it diverted a lot of attention that could have been spent better elsewhere.

Painful Lessons

Since I first started building our teleconferencing service almost two full years ago, I've learned quite a bit about deploying Django. Before completely overhauling our service and porting everything to Django, I was relatively inexperienced with production deployments, having only built small passion projects.

What I learned through all of my experiences learning (and using) a variety of popular sysadmin and devops type tools is that nothing in the sysadmin (or devops) world is perfect. There are some great tools out there (puppet), but they've got a long way to go before they're simple enough that a single devops guy can build out an entire production infrastructure solo.

By far the greatest hurdle I encountered over the past two years has been infrastructure. There is a huge time investment gap between building a basic infrastructure (installing nginx, gunicorn, celery, etc., on a single server), and automatically provisioning that same infrastructure (with puppet, etc.). In regards to the difficulty of actualy writing code that can scale across a large infrastructure, the challenges have been much simpler to overcome. In fact, I'm happy to say that using Django has been an excellent choice for us.

Regardless of the difficulties I've had over the past two years in building out our infrastructure, and effectively deploying Django--it has been a great learning experience. I've learned more these past two years than at any previous point in my life.

But for me, what it really comes down to, is...

I'm a programmer at heart. I like coding and building new things. At the end of the day, it hurts me inside to spend a ton of time working really hard to maintain and scale your infrastructure, and then realize that through all your effort, you've only managed to fight off the chaos for another day. Bummer. I'd rather be hacking on new Django modules, or playing around with the latest async javascript framework.

But that's just me.

In the next part of the series, I'll be discussing the first part of the deployment solution I discovered.

EDIT: I finished part 3, you can read it here.

Permalink | Leave a comment »

DevOps Django - Part 1 - Goals

Mon, 05 Dec 2011 10:25:00 -0800

A little over a month ago I published an article (Deploying Django) describing the state of Django deployment. If you don't want to read the backstory, I'll summarize it for you here: deploying Django is hard.

Surprisingly, my previous article drew quite a bit of attention from the Django community. I was fortunate enough to speak with some really brilliant people, and hear stories from lots of developers who had both good and bad experiences with deployment. However, the overwhelming majority of developers I spoke with all agreed: deploying Django is hard.

Now, a lot of the "deployment problem" (as I've come to refer to it) is not directly Django's fault, but rather a side effect of working with so many technologies, services, and libraries. It is only natural that building complex and performant software require sufficient deployment and administration attention in order to work well.

After writing Deploying Django, I decided to embark on a personal quest to find, implement, and write about the best possible deployment strategies currently around. Since then, I've been extremely fortunate in that I've found what I consider to be the best possible deployment strategy for modern Django projects.

The goal of this article series is to tell my own tale of deploying Django: what my problems were, what solutions I've found, and what problems still exist--in hopes that my experiences will help guide other Djangonauts looking for a better way.

Deployment Goals

To kickstart this article, I'd like to explain where I'm coming from: what I do, what I value, and what my deployment goals are--as these are all crucial to the story. Everyone has different needs, and there's a good chance that your needs (and subsequently, goals) may be vastly different from mine.

I'm the lead developer at a small telecommunications startup in the USA. My company builds various telephony services, all of which are free for personal usage. For more than a year, I was the sole technical employee, responsible for:

Building our products.
Building our architecture.
Scaling our services.

Note: I'm still responsible for all of the above, but we've expanded a bit so I'm no longer alone =)

As we're a small tech company, our primary concern is productivity. Our revenue is directly related to the amount of bugs we fix and features we add, so it is in our best interest to free up as much engineering time as possible so that we can focus on adding value to our users' lives.

What this means for my company is that we greatly value devops work. Any pieces of our infrastructure that we can automate and scale through code are infintely valuable to us, as they free up engineering time in the long run, giving us more time to make an impact in our product.

In an perfect world, as a developer, I should be able to:

Run a single command to deploy my application into production.
Run a single command to automatically scale up (or scale down) my application.
Instantly add services to my infrastructure that my application needs (memcached, redis,postgresql, etc.).
Have full access to logs and metrics for all parts of my infrastructure, so that I can find problems and fix them based on facts, not assumptions.

Furthermore, I want my application and all of its related infrastructure components to *just work*, and require NO maintenance. For instance, if I provision a redis server, I want to know that it will always be up and available, and that I will never need to make changes to it again (other than scaling it up or down).

I think we can all agree that if the conditions above could be met with minimal work, life as a developer would be grand.

In the next part of this series, I'll explain my company's product technology in detail, highlighting the pain points of deployment.

EDIT: I finished Part 2, so you can continue reading here.

Permalink | Leave a comment »

Deploying Django

Sun, 30 Oct 2011 00:00:00 -0700

Over the past two years, I've learned a hell of a lot about deploying Django apps into production. And yes, I really do mean a HELL of a lot. While Django is a great web framework, one of its primary weaknesses (in my opinion) is a lack of strong deployment documentation and community standards. There has been no easy way (until now, kinda) to deploy your apps into production in a reliable, simple fashion. Period.

Sure, there are excellent best practices that a few awesome programmers follow, but for the majority of users, the best practices are just too complex and time consuming to setup and administer for typical site.

Real World Deployment

Let's pretend, for a moment, that you're an intermediate Django programmer. You spend 8 hours a day working on a single project that is built purely in python / Django. Your primary main objective is to keep your users happy (fix bugs, release new features, etc.). You're fairly familiar with the Django ecosystem: you know which apps to look at for solving various problems, and you know where to find information you don't already know.

Let's further assume that you're also an all-around-geek, and manage your own Rackspace or Amazon servers which you use to host your Django app. You boot your fresh new Ubuntu cloud server, then install Apache and mod_wsgi to run your Django site. You then spin up a second server and install PostgreSQL, which your site uses as its primary data store.

You think you're doing a good job--you wrote your app and got it online, spent time learning how to use your cloud provider's APIs to boot up your new server, and you managed to install, configure, and administrate your app. Furthermore, you know where to look for problems: apache error logs, Django 500 and 404 emails, etc. In your mind, you're awesome.

When you think about the amount of effort you put into your work, you feel highly accomplished. Not only did you do a good job getting everything running, but you also spent years learning all the technologies that power your site: HTML, CSS, Javascript, Python, Django, linux, etc.

... BUT ...

After three months of building your site, and 1 month of getting it running in production, you finally have real users. As a matter of fact, you're getting about 20 hits per second. While this may be awesome for business, your web server's load is 14, and your users' HTTP requests start timing out.

Since your Postgres server still has reasonable load, you decide to scale your site horizontally by spinning up a second web server, and splitting HTTP requests between the two. This way, you can serve twice as many users and keep your site running smoothly.

You spin up a new server, install Apache / mod_wsgi again, then copy your code over. After a few hours researching HTTP load balancing, you decide to use HAproxy to proxy your requests. A week later, you have HAproxy running on a new server, and can see HTTP requests hitting each web server.

Finally, your users can view your site again, whew. WRONG.

As your site has grown, you've noticed that several pages have started eating lots of CPU cycles. Upon further analysis, you see the problem: rendering the dashboard page requires about 30 time intensive SELECT queries on your PostgreSQL server. Damn. To make matters worse, you can tell that if you don't get this fixed right away, the database server will be destroyed by the week's end.

To avoid repeating the large SQL queries, you decide to cache the page data for an hour the first time a user visits the page. That way, repeat requests for that page will not generate repeat SQL queries, thereby taking load off the database. You provision a new server, and install memcached. Two days later, you've got a caching server working, and you've rewritten most of your Django views to utilized memcached.

Now you can finally get back to coding! WRONG.

Your pages are still loading slowly. You analyze your codebase, and realize the new problem: once your cached page expires (at the end each hour), multiple users hit the page simultaneously, generating numerous time intensive SQL queries, effectively hammering your database server and causing HTTP timeouts. Back to the drawing board.

At this point, you're frustrated with progress.

After a few days of research, you discover how to solve your caching problems: cache invalidation + distributed message queues. Essentially, each time a user adds new data to your site, you'll:

Dump a small message onto the queue that says "do some processing, then update the cache".
Your queue will get the message, and hold onto it.
Your worker processes will grab the oldest message from the queue, one at a time, and do what needs to be done (do processing, update the cache, etc.).

This way, your page cache is never stale, and you never run into the same traffic stampede issues that you previously had.

The only problem now is that setting up a distributed message queue is a lot of work. You need to setup a RabbitMQ, celerybeat, and one (or more) celeryd servers.

Two weeks and a lot of energy drinks later, you've got it all set up and working. You've rewritten most of your initial Django code to make good use of celery and memcached.

But... then you realize the Postgres server is dying. FUCK!

Even with all the fancy new scaling tools implemented, the database just can't handle the constant load. Two weeks later you finish deploying multiple PostgreSQL read slaves, and configure your Django database routing rules to use the new PostgreSQL cluster effectively.

At this point, you're dying to get back to programming. You've spent almost two months keeping your site running, but that's it. You haven't had time to work on bug fixes, or feature requests for your site. To top it all off, you've had to rapidly learn numerous new technologies just to keep things going, and you're afraid that if anything fails, you'll be completely screwed.

In order to maintain your sanity, you spend a few more days researching server management tools, and discover puppet. Then...

Oh my fucking GOD!

Yes, grasshopper! You now see it: you have only begun to discover the amount of work that lays ahead. You've barely scratched the surface as to the tools, methods, and skills necessary to manage and operate even the simplest of production sites. Your work is cut out for you.

The Truth

If I've learned anything in the past two years working with production Django deployments, it's that deployment is fucking hard. Every real project I've put into production over the past few years has involved hundreds (if not thousands) of hours worth of infrastructure management. Even though I'd like to think that my overall syadmin skills are slightly above that of your typical programmer, I still spend an inordinate amount of time working on infrastructure.

After speaking to loads of other programmers in the Django community, I realize it isn't only me who has this problem, it's everyone. While I don't have any statistics to back this up, I'd estimate that typical Django programmers spends at least half their time working on infrastructure related tasks.

The Django community is at an interesting place right now.

We're sitting on verge of an enormous technology breakthrough. There are currently sufficient tools, methods, and practices that allow Django developers to build simple, robust, and scalable applications. However, the community as a whole lacks direction and confidence in deployment.

What Django Needs

In order to fix the deployment problems in the Django community, several things need to happen. If community members realize the importance of this problem, it is more likely to get resolved quickly. By solving the deployment problem, Django can set an unprecedented standard for web development.

First and foremost, all of the Django hosting companies around (Heroku, Gondor, epio, djangozoom, etc.) need to really step up their game. These companies are in the best position to fix the delployment problem. Their livelihood depends on making developer's lives easier, and since they have developers giving them money, they're in the best position to gather real world usage data from numerous Django developers, and build elegant deployment abstractions.

I'd personally like to see Heroku succeed as the dominant Django hosting provider. In my opinion, they are tackling the deployment problem the best way. Their model is simple: provide solid support for hosting your apps, and a large collection of add-ons that any developer can easily add and remove from their site in an instant. Their addons allow you (as a developer) to completely ignore 90% of typical infrastructure work, focusing purely on application code. Furthermore, since Heroku is running on Amazon's cloud, it's likely that their prices will drop over time as their user base continues to grow and Amazon's infrastructure becomes a commodity.

Second, we need strong deployment leadership from Django's core team. In my opinion, Jacob Kaplan-Moss is best posed to take on the role of deployment-BDFL. Jacob (one of the Django creators and core developers) is an outspoken devops advocate, frequently giving presentations on Django deployment and infrastructure best practices.

With a strong leader willing to tackle the deployment problem, the official deployment documentation needs to be heavily updated. Currently, the official documentation is woefully inadequate--covering only the most basic deployment patterns. In order for the Django community to continue to grow and succeed, the official deployment documentation needs to have a strong voice and opinion--it needs to say:

Here's how to do caching right.
Here's how to properly setup asynchronous tasks.
Here's how to scale your database for certain usage patterns.
etc.

While this will surely upset a lot of people who believe in Python's flexibility, Django needs to take an opinionated stance in regards to tools, patterns, and practices. Without a stance, the community will stay as it is: stuck in a confused state regarding deployment. If we (as a community) can agree to take a stance on deployment: decide what to do, and what not to do--it will revolutionize Django.

Third, the open source community needs to develop high-level abstractions for common patterns. There are currently excellent tools available to Django developers wanting to build production apps (celery, rabbitmq, memcached, redis, etc.), but due to the complexity associated with setting them up and managing them, they are not used nearly as often as they should be.

Developers need tools to fully automate and manage various pieces of Django infrastructure. If it was as easy to deploy an auto-scaling distributed cache as it was to start a Django app on the command line, Django developers everywhere would be much happier.

I Have a Dream

In my dream, all Django developers (from the newest to the most experienced) can rapidly build their web apps, knowing that production deployment is at most 10 minutes away from completion.

Imagine a world where (as a developer) you can build an app, and have it running live in a best-practices, scalable, and sustainable way in no more than 10 minutes. The possible benefits are tremendous:

Production Django sites will typically be more reliable than their counterparts.
Django developers worldwide will have confidence in not only writing, but also deploying their applications to the world.
New developers will be greatly attracted to Django as a framework, due to its immensely simplified and powerful deployment options.
Django developers will be able to spend more time, each day, writing python and Django code, instead of focusing their efforts on infrastructure management.

We're at an awesome time in Django history.

Each of us has the ability to greatly effect the future of the framework we all love so much. We have the ability to influence the newest generation of sites that power the internet. We need to collectively decide to show our fellow developers the light, and remove the confusion that exists around deployment.

EDIT: Based on the feeback I received from this article, I decided to write a series on deploying Django. If you're interested, you can read the first part here.

Permalink | Leave a comment »