JavaScript catches a lot of flack for it’s “ugliness,” but I’m rather fond of the language. It’s first-class functions make up for any quirks you have to deal with in the language. Consider this test case:

It generates this output when run with --spec:

I’m using test cases like this throughout my upcoming Programming Node.js book to test output of some of the simple scripts.

Yes, I know you can get some amazingly expressive test cases in other languages, but I dare people who say that JavaScript is any ugly language to find fault with this bit of code.

Shh… Don’t tell my editor I’m blogging. I’m procrastinating by writing this blog post instead of working on Programming Node. I’ll still get to that, but this is on the brain right now.

Today marks the 50th straight day of pushing code to GitHub. My work on Armstrong has made a lot of this possible—it’s easy to push code when you’re getting paid to write open source software—but not every day has been Armstrong related code.

During the course of the last 50 days, I’ve rediscovered a few things that I want to share, in case anyone else thinks that they can’t possibly do this without changing jobs.

Keep it small

I’ve written about manageable chunks in writing, but not in contribution. It’s easy to make excuses about why you aren’t pushing code on a daily basis. You need to clean the code up; its not good enough, yet; or it’s not really significant enough to make a difference.

Excuses. All of them.

Every single piece of code you write has importance. Otherwise you wouldn’t write it. There are exceptions to this rule, but those are outliers. Most of the stuff you and I would write and go to the trouble of committing is going to be useful to someone.

Case in point, earlier this week I helped add some interactivity to a timeline on the Texas Tribune. My contribution was trivial, but it might be useful to someone trying to do something similar, so it’s up on GitHub.

There’s always something

There is always something you can do with 5 minutes. I’ve made a lot of contributions to bash-it. Think of it as your terminal on steriods, with pretty colors. I started out with some minor tweaks, then found some places where code could be better handled, then other devs built on that, and I’ve started refactoring some other parts.

I spend the vast majority of my time looking at a terminal, so it needs to fit like a glove. Working on bash-it means I’m getting more and more familiar with my environment and making some pretty cool enhancements.

Find something that you use, something that would make your life a little bit better if it just had X, then go to town and try to figure out how to do X in it. My bash programming sucks. Seriously, I wouldn’t know where to start to write a real bash program, but I can muck around in the internals and figure it out. Just because you don’t know how to program in a language doesn’t mean you: 1) can’t, 2) shouldn’t, 3) aren’t fully capable of figuring it out as a smart human being which I know at least some of you are.

Just start

It’s really easy to get part of the way through a month and say “oh, I’ll start the first of next month.” No. No you won’t. Well, if you’re me you won’t. I have a horrible tendency to want to go big or go home. Not necessarily a bad thing in and of itself, but not good for just getting shit done.™

It’s especially bad when “going big” is “I’m going to commit code every day in a month” and you’re already into an existing month. Then ya wait and you lose that initial momentum.

So the answer for me is to just start. The raw #s are what matters. Get out there, do something, start tallying it up.

We released our first version of Armstrong this past Wednesday. After taking a quick breather, I set out on getting Armstrong setup inside a Vagrant virtual machine to make evaluation easy. I finally got it running. There’s more information about getting started in the README, where it belongs, but I ran into some interesting technical issues while setting it up that I want to document here.

Vagrant + Puppet + pip

I initially wanted to create a full build-script inside Vagrant that could be used to setup the entire environment. I used puppet to start the process and found the puppet-pip provider so I was even going to be able to install Armstrong easily. Or so I thought.

There’s something that is happening when puppet runs pip that causes the installation to fail. I’m a big subscriber to select not being broken, but in this case I think there’s some odd in the combination of pip and puppet. The reason is that pip install armstrong via an ssh connection to the same virtual machine works. After briefly discussing it on #pip on Freenode, I opened ticket #298 which outlines the issues we ran into.

I finally decided to go the pragmatic route. For the time being I have a box that’s installed the way you would if you had a raw box yourself. It’s not ideal, but our new armstrong box (warning, that’s a 500mb download) boots up with everything you need to start playing with Armstrong.

Eventually, either I’ll figure out what the issue with pip+puppet is or I’ll switch to some other method that will work. My reason for picking puppet was pretty simple. The provisioning section of the getting started guide for Vagrant shows you puppet code and says essentially “Chef it too complex to simply show you how, so just use this prepared stuff.” I like simple. Right or wrong decision, I’m not 100% sure yet.

Django Server on Bootup

The server runs on startup thanks to upstart in Ubuntu. As far as Ubuntu is concerned, Armstrong is now a service that can be started and stopped with start armstrong, stop armstrong, and so on.

Upstart works on the concept of events. Different tasks emit different events that other tasks can be configured to react to. There’s a startup event and a net-device-up event and so on. I tried all manner of combinations before it dawned on me, the VM is booting, then Vagrant is mounting the NFS with the project.

Once I figured that part out, this recipe helped get things started. A quick task that starts monitoring for the config/development.py file that is mounted after booting was all I need to get runserver_plus going on “bootup”. You can check out the upstart scripts being used in the repository.

I chose runserver_plus from django-extensions rather than the built-in runserver because of issue 15880. Since I’m starting the script on start up, there’s no interactive interface and the watcher gets a little wonky. It works out though, because you get the awesome werkzeug debugger for development.

Closing

Minus a few oddities in the process, I’m really pleased with the end result. It should be noted that this is meant for development only. As we near our first stable release later this year I hope to be able to create another box that’s more deployment ready, but hopefully this will get you started down the right path.

Had a good week at 2011’s version of tek. Thanks to Marco Tabini and his whole crew for putting together another great conference this year. I haven’t professionally developed in PHP for several years now, but still consider this a must attend conference. This was my 4th year. The people and the content make it worth attending, even though I’m mostly doing Python work these days.

I gave two talks this year, both on Git. Both talks went well, but my advanced Git talk needs some tweaking so I can get it in at an hour. I always plan too much material when I first give it, so it needs a little more taken out.

As promised, I am going to get both talks online over the next week. Each of the repositories we walked through in the advanced talk are going to be posted to GitHub in their “before” state that you can play with them. They also include README files that explain what you’re doing and how to do it.

I’ve already posted my amending and rebasing repositories. You can search my github for pres. to see all of the repositories. I’ll post again once I have them all up.

One of the more interesting evenings this year was a late-night hackathon that involved two 5 gallon kegs from Jason Sweat’s personal stash. I went to bed early’ish, but got this image emailed to me around 1:30. I’m told whiskey fueled its creation. :-)

Two weekends ago I quietly rolled out a new feature that people have been clamoring for here at TravisSwicegood.com. Feeds for tags. So say you’re only interested in following my personal posts, you can add that tag page to your favorite RSS reader to subscribe to it.

Or if you’re geeky, you might want to subscribe to my armstrong feed but don’t like the automagical discovery. In that case, just add /atom/ to the end of the URL and you’ve got your RSS feed.

Ok, time to fess up. Nobody’s actually asked for it, but since moving over to the new site last year I’ve only had one feed. It’s been a sore spot and I’ve censored myself on my blog feeling I need to keep it cohesive. Screw that now.

I’m working on setting up a new (old) MacBook Pro this evening when I came across an oddity. Colors in iTerm2 were working, but not in xterm-256color mode. Both laptops are sitting on the table next to each other, so I started debugging.

There’s all manner of bugs that have been reported, but no amount of tweaking my environment variables worked. Some time during the process, Xcode 3 finished installing and all of the sudden things started working.

My guess is that Xcode ships with X11 which is needed for xterm-256color to work, although I’m not planning on uninstalling just to see if it works. At any rate, if you’re having issues with 256-color mode in iTerm2, check to make sure you have Xcode installed.

A few weeks ago, I got a lot of responses to the following tweet:

As I write this post, Twitter’s ever-unreliable updates counter is showing that I have 9,999 tweets. It’s time for a Twitter Timeout.

Why? I’ve found myself thinking too quickly, without depth, mostly in the form of 140 characters. I want to get back to my place, my blog.

I’m tired of playing in other people’s backyards, as it were. A large part of my interactions with the world are through Twitter and Facebook, two things I don’t own. My blog, my email. Those are mine. Until the Internet gives way to some bastardization of itself in the name of safety, security, or the God-forsaken “user experience,” it will always be mine to give and not at the control of some private entity.

So, I’m shuttering my Twitter account for a little while. I’m not sure how long, but I won’t be responding to any tweets or reading Twitter for a little while.

My contact information is amazingly public (it’s in the sidebar), so there’s no shortage of ways to get in touch with me. Feel free to.

This past November I participated in the PragProWriMo. For those familiar with the NaNoWriMo, the concept is similar. Commit to writing on a technical book every single day for the entire month of November.

I had been kicking around the idea of writing a book on Node.js and decided to use this as an opportunity to see what I had to say on the topic. Turns out that I had about a hundred and fifty pages worth of material.

I’m lucky enough that Pragmatic has agreed to pick up the book, so I’ve got a solid base to build out the tentatively titled Programming Node.js. This post isn’t a book announcement though, it’s about the process.

Why I did it

This past month was mostly for my own benefit. I was certain I could get into a rhythm and turn out a lot of material. My last book took a lot longer than I originally planned and came really close to not happening.

I’m not the first author to find himself behind schedule and feeling like there’s no way out, but it was the first time it happened to me. PragProWriMo was my chance to prove to myself that I could get some serious writing in.

Lessons learned

I’ve got three big take aways from this experience. First, the power of doing first, then talking about it. Second, the power of periodization in sports applies to mental tasks. Third, streaks are powerful incentives.

Actions build more than words

Earlier this fall I watched this talk at Ted from Derek Sivers about goals. The gist is that you shouldn’t talk up you idea, you should just do it.

Studies seems to show that you get the same mental reward from talking about your goals as you do for actually achieving it. I’ve had plenty of ideas fall flat after really talking them up, so I decided to try this tactic and see how it panned out.

That’s not to say I didn’t talk about it at all. I participated daily on the forums posting updates at where I was in the process. I did make sure to not talk about what I was doing though, it was just the end result.

I never made any grand announcement though. There was no blog post claiming I was going to write every day of the month or that I’d finish the month well over half way through a shitty first draft. I just did it.

Periodization: it’s for more than sports

The second lesson was more subtle, but obvious to me in retrospect. I could have written more on any given day than I did. I ended just about every day midstream, but that was fine. I left those ideas sitting there waiting to be explained.

Picking up where I left off was easy. There was no need to figure out what was next. I didn’t have to ramp up and there was no fighting that feeling of being spent. Like I said, this is obvious with the benefit of hindsight. It’s one of the core principles of training.

For those of you who don’t know me that well, I used to be a pretty competitive mountain biker. I spent a few years racing and one of those was spent all over the southwest racing at national events. I wasn’t amazing. I was consistent and faster than a lot of people, but I dove into the process of training. I picked it apart, tried to understand everything, and came away with what I believe is a pretty solid understanding of the fundamentals that underly training as an endurance athlete.

One of the main principles is that you never want to leave it all out on the trail unless it’s a race. You want to end each day with something left in the tank. It’s counterintuitive at first, but the reason is simple. You’ve got to ride tomorrow. And the next day. And the next day.

You get faster by slowly ramping up the pace and the miles, and rarely draining yourself down to zero. You can’t recover quickly enough to get the next ride in when you do that.

I made a conscious decision to limit myself to two pomodoros a day, or roughly an hour of time dedicated to nothing but writing. Keeping the commitment small was key to my success. It kept me from getting burned out and ensured that I was still enjoying the process every day without over doing it.

Keep it going

The final piece is the streak. Today marks the 42 straight day that I’ve written or worked on my book. I’ve spent the past few days converting it from ReStructured Text over to Pragmatic’s internal markup, but I count those as days of work.

I probably could have spent a few hours over the weekend and knocked it all out in one sitting, but I wanted to keep a steady pace so I could keep the streak up. Today marks the 42nd straight day I’ve worked on the book and now that I’ve stretched it out this far I don’t want to see it go away.

Nothing here is new, though. These are all things that other people have figured out before me. This November simply put these things into sharp focus for me and the end result is that I’m half way through a book on a tool I thoroughly enjoy using and think more people need to know about.

For the record, I did miss one day in November. I didn’t write the day I gave my Pragmatic Guide to Git talk at Zendcon. I figure giving a talk is a good enough excuse for missing a day.

I talk with a lot of people about NoSQL. I’ve been following it pretty closely for about 3 years now. One of the things I often tell people who are trying to wrap their heads around the concepts of NoSQL and what all of the data stores mean is to go search for Justin Sheehy and his NoSQL East Talk.

Then it dawned on me, why don’t I just embed the video on my site? Makes it super easy for people to find (travisswicegood.com/tags/riak) and I don’t have to go searching for it.

So, here’s what I consider one of the best talks to date on NoSQL.

I’m excited to announce that I’ve accepted the senior position on the tech team at the Texas Tribune, a policy and politics news outfit based out of Austin, Texas. I’m helping them round out their internal tools and data processing starting next week (the 11th to be precise).

This means some big changes for me and my family. First, I’m moving to Austin. I love Lawrence, the quirky little town that it is, but it’s time for a change. Austin was high on the list of other places to consider (great cycling, big tech community, cool vibe, etc., etc.) so when this opportunity came up I had to take it.

The move is complicated by virtue of owning a house. For the first six months or so we’re going to split the house – me in Austin and Meg in Lawrence. I’ll be spending a week or so a month working from Lawrence so I can help finish up some of the random project on the house that we want to finish before we attempt to sell it. This works perfect with the Lawrence real estate market which peaks in April every year.

What happens to Domain51?

One question I’ve gotten repeatedly is what happens to Domain51? Well, nothing in particular. I’ve spent the last 5 months or so winding it down in preparation for a transition of some sort. Until recently, I didn’t know exactly what that transition was going to be, but I’ve setup all of my former employees on their own adventures and wrapped up the work for existing clients. So it will go back to being my placeholder for any random consulting I do and the legal owner of all of my personal code copyrights.

What about Lawrence?

Lawrence is one of the coolest places I’ve lived. While writing this post I realized that it’s the place I’ve called home more than any other place since I left El Paso years ago.

There are tons of great people here, the culture is great, the weather isn’t half bad (though 2010 hasn’t puts its best foot forward), and it has some of the best food in the world if you’re a vegetarian. I am truly going to miss this town and everyone in it.

Isn’t journalism dead?

Yup, that’s what is so exciting about the Tribune. They’re trying a different model, and helping them make it successful could set the tone for how journalism copes with the seismic forces that are causing it so much change.

The Tribune is adopting what I call the NPR approach to journalism. They’re organized as a non-profit. You don’t subscribe to a paper or some such, you become a supporting member of it. Interested in politics and policy in Texas? Then you need to visit this page for more information about how you can support them.

I am really excited about this move. It’s the meshing of the past year’s work in non-profits and politics into one gig in an industry that is in the mist of a massive shift. How could I not want to be in the middle of that?