While You Were On Facebook

Karl Stolley has a great personal productivity project, a sort of daf yomi for hacking.

Check it out.

Buffalolabs on Hackerspaces.org

Mahipal on HN posted a link to hackerspaces.org, a global list of hackerspaces.

I didn't see any located in Buffalo, so after a bit of googling I added Buffalolabs.

Syntax Highlighting Test

Thanks to Alex Gorbatchev for a very cool and easy syntax highlighter for Blogger.

Check out the list of available brushes. Now use it.

def works?
  puts "omg hax!"
end

One month codebase: getting started

Read the Github guide on forking.

Good. Now if you want to follow along with my one month codebase project, you know how to do it easily. This month, I'm reading Ruby.

Now you have a shit ton of files and directories. Your goal is to grok them. And then improve them.

Now, you could have just cloned the repo directly, and gone abrowsing through the code. Don't do that. It makes things harder when you find bugs, typos, etc, to contribute a fix. Fork it, keep the codebase current, and push all your changes. The goal here is to not just read the code, but to learn what it's doing. That means getting your hands dirty and then leaving a trail of grubby handprints all over the code.

Optparse.rb is a good example of what you'll find: fine documentation and introduction, with scattered bits of undocumented and initially terrifying magic. Kind of like having sex for the first time.

ruby/lib

Before leaving for work, I'm spending an hour or two reading 3 random ruby/lib files:

observer.rb
benchmark.rb
optparse.rb

One hour is plenty of time to skip around a file, following ctags, getting a sense of its structure. There's even time to dive into hairy methods like #summarize and tweak out their logic.

While reading the code in vim (it is great for reading code, especially with NERDtree), I've got an emacs open to experiment with, comment on oddities, and run tests.

Try it. While reading the code, yank a method into its own file, and try to break it. Create your own unit tests, and see how hard it is to change the method without regression. Ideas that come to you while puttering about breaking things? Pop open a .org buffer and scribble them for later.

The important thing is not to approach it like a Google whiteboard interview. You don't need to memorize the entire damn file. Just figure out how it works, where it hides its superpowers, and what its weaknesses are. Once that's done, you've gotten halfway to being able to improve it and push your contributions to the project.

One Month Codebase Project

2:chaitin~/srcs% ls

arc/  conkeror/  ezbl/  git/  jquery/  mongoDB/  ruby/  slime/  tags  unix-jun/  uzbl/  xmonad/

I've already got a bunch of cool code I read. Nowhere near enough, though. 

If you don't already have a habit of reading code for fun, do it. You'll thank yourself for discovering something not only more meditative than zazen, more frustrating than slamming your genitals in a drawer, more addictive than sudoku, and more productive than NetHack, but also more fun than masturbation. Reading good code is like being Sherlock Holmes in the moment of solving a crime. Reading bad code is like being Watson as he watches Holmes repeatedly harpoon a pig carcass, wondering why the fuck didn't he look around for a better apartment. Both will teach you.

Previously, I've been skipping around willy nilly. A few hours reading one file in one repo, getting a bit of a hang of it, then switching to something else that interests me. In keeping with my effort to prevent getting distracted by projects and shiny closures, I'm trying out something. 

Each month I'm going to focus on one codebase. By the end of the month, sans distracting forays elsewhere, I will know that codebase better than I would previously have. Maybe even better than others who divide their time, skipping the begats across repos.

This month, it's Ruby. 

I'll post more on it later. Thanks to Oscar for providing the impetus to get my shit in gear.

Being Harpo

One of my big problems is that I rarely rant in a single location.

I can go into a full-on tropical storm bellowing rant on an irc channel on, say, why asking "what language should I learn first" is a sign the questioner will never get past helloworld. But, like lotus petals in a stream, these rants are impermanent. They disappear unless pastebinned for more permanent posterity.

The sole reason for having a blog is to rant, bellow, and generally piss people off. In the process, you'll learn something, even technical stuff. Keep it up long enough and you'll avoid being a complete unknown.

I'm not a good blogger, though. Sometime a few years ago I mostly gave up blogging, believing it to be mental masturbation with a soundtrack. Now, thanks to twitter, I can say that blogging is less offensive than making public every single grunting impulse.

So. I want to blog. I want to post snippets of code, occasional Petroleum Vetruvius Nasby rants, etc. But every time I think of posting, I get distracted by something that won't leave my verbal catspray forever marking this corner of the web.

I've got to figure out a good way of making regular updates a habit, or else learn how to play the harp.

The power of vim

I've been using vimprobable and vimium for a while now, and the vim UI has gotten to me a bit. At least for web browsing, the keyboard shortcuts rock. Especially on dvorak, as the j and k keys are actually in a logical position for their functions, as are the h and l keys.

Being an inveterate emacs-lover, this disturbed me. So I pacman'd vim and tried it out for the first time in years.

I now understand the real reason people use vim: the annoyance of switching modes.

Emacs is powerful because you can do anything you want in it. Anything. This naturally imposes a steep learning curve that guarantees you'll pick up emacsfu in order to get anything done.

Vim is powerful because it beeps like the Roadrunner being sodomized, any time you try to inefficiently use Insert mode. You will learn the esoteric arts of text-manipulation commands simply to prevent this unholy shrieking. The less beeps you hear, the more efficiently you're taking advantage of it.

This gave me an idea for an Editor Alike Tutorial. Simple: construct a plain text document whose editing and manipulation takes advantage of no special features of either Emacs or Vim. Then, open up a contest to see which wins.