Thrills

I just Syu --ignore kernel26'd my system. I couldn't do a normal Syu because it throws up an error about nvidia-173xx being homosexual. I knew that nvidia would give me hell.

I upgraded, made inittab drop me into runlevel 3, installed nvidia-beta and nvidia-beta-utils, ran a yaourt Syu for good measure, reverted inittab, and now have everything working again, all shiny.

The thrill of fucking things up, then singlehandedly fixing them, is better than sex.

Hacker Friends

Hacker Friends is a wonderful Chrome extension for highlighting the responses of those you respect.

Oh, other extensions I use:

• AdBlock
• Chromodoro
• Crossfire
• Readability Redux
• Vimium

Browsing erb.rb, part 1

Today's installment of One Month Codebase is a short browseof Masotoshi Seki's ruby/lib/erb.rb

It's 902 loc, not that hefty, and as we'll see, rather straightforward.

First, the introductory comments. The first 255 lines are great documentation. Several examples showing off different aspects, clear writing. It should make your day.

Pop open a buffer and type in these examples. They may seem trivial, and you really want to get to the meaty bits. Do it anyway. It may turn out that the example usage contains a bug, in which case in a few minutes you could contribute back to the project. If the code works, the sheer act of typing it out, running it, debugging your typos etc, will doubtless put you in the mindset of wondering where you can use

this technique. Hell, halfway through this you may have a brainfart that turns into a full project. At the very least, you will be accomplishing the important goal of playing with the code.

A good idea is to take one pomodoro (half an hour) per example. Keep another buffer open to jot down thoughts so you can come back to them later.

Now that you know how erb.rb is used, you can see how it works. Give yourself half an hour to skim the code, noting in a buffer points of interest, oddnesses, places where you need more comments. A good rule of thumb is that you should make a note of any oddly long method or class. These long methods and classes are great places for improvement: they're ripe to be refactored and simplified. Make a note

of any class or method that seems to be doing too many things, and ask yourself why it absolutely shouldn't be broken up. Sometimes there's a good reason, other times you will be saving countless people from horrible frustration.

Time: 1 pom

Cells.py a terrible temptation

Terrible, terrible temptation.

Today on HN phreeza posted an awesome python game called Cells.

I forked the project and began looking through it. Made some comments (seriously, fork it yourself and add comments. It needs it). Tried to think of ways to implement the TODOS. Popped open a buffer and began brainfarting a testsuite/profiler for it.

And then caught myself. This month is Ruby. Why am I plunging into Cells, even though it is undoubtably dripping with awesome sauce?

I can tell myself that there's plenty of time to do both. But that'll mean that the next cool code I want to jump into will be ever so much more distracting.

Solution: set up a cronjob to fetch the upstream repo once a week until I can dedicate myself to playing with it. When I jump back in, it'll be even more awesome (since the post on HN, it's already had a ton of contribs).

Pomodoro

The head of my todo.txt on Dropbox

As you can see, I'm going for as dead-simple an implementation as possible. I want to be able to C-a-2 into a screen buffer containing todo.txt, jot down brainfarts and update the list, and C-a-a right back to where I was. No mucking about with non-plaintext. I plan at some point to code up a pomodoro.el that adds pomodoro formatting to org-mode.

By the way, I put my todo.txt onto Dropbox, outside the Public share, and symlinked it to the one on my main box. Right now, it just means I can easily cat-tail it to a file such as goings.txt in the Public share to quickly show people what I'm doing at the moment. I can even cronjob it so every midnight, say, anyone who wants to can see what I've been doing.

Anyone have suggestions? A cooler way of integrating todo.[org|txt] with Dropbox?

Dropbox

I just pacman'd Dropbox.

I love it. Within seconds I git cloned my dotfiles to it, and aliased a command to push both to github and Dropbox. This is amazing, because it means I can instantly set up a box the way I want without needing root access to install git. I then exported my chrome bookmarks into it.

There's a great thread on HN about using Dropbox to increase the awesomeness in your life.

It's only been a few minutes, so I've not played around much with it. I'm going to try out encFS and TrueCrypt, as well as experiment with executable code. Can I put Arc or Rubinius in it, and have a testing environment? CANNOT FUCKING WAIT.

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.

Projects: Rave and Ruzbl

I've started some projects, and will start pumping them to github shortly (once I've got my testing workflow tweaked and automated enough not to let me screw up too badly). I'll post my testing setup once I've Hofstadterianly worked out its kinks.

Rave. A livecoding environment inspired by Topher Cyll's Practical Ruby Projects, with emacs integration. Plenty of space in which to play around. Look at mature livecoding projects like Impromptu, and you'll see there's boundless room for tweaking.

Ruzbl. An FXruby scaffold around uzbl. Uzbl-tabbed is simply not cool enough. I don't want tabs, I really want the sheer flexibility I expect from Xmonad and GNU Screen. I want to xmonadify uzbl: provide a terse and powerful way to tile, tab, and otherwise manipulate uzbl instances. Imagine how cool it'd be to have an uzbl layout that can tile, group by parent window or category...

My environment

As I said before, I am distracted by hackability. I procrastinate by tweaking things. My programming environment fully reflects that I am the kind of person who finds config files a far more interesting form of entertainment than Farmville or television.

I've evolved what I consider the perfect environment. It is utterly hackable, completely inscrutable to the impatient and incurious, and it provides a rather more valuable avenue for procrastination than what most people would choose.

Here's my environment: Arch Linux, Xmonad, emacs, zsh, screen, uzbl, and conkeror. (Look in the sidebar for some of my dotfiles in github). In short, I can tweak anything, as much as I want, and never be absolutely done. 


The upshot is that my procrastination is guaranteed to teach me something, as well as putting more awesome in my day. The downside, as far as I can tell, is that I have no clue who or what Lady Gaga is without googling.


Make your environment hackable; it keeps you off potentially more distracting hobbies like black tar heroin.

Workflow.org

As part of my attempt to become more productive, I am trying out a new system of organizing projects.


I've limited myself to a handful of projects at any time. Each is within its own vcs'd subdir within ~/code. This keeps me thinking in terms of projects rather than languages, which is how I used to organize things. Hopefully, I won't be as tempted, upon figuring out foo monad in one place, to try it out somewhere else and end up spending hours down the rabbit hole. I know I'm not the only one to be distracted by his fascination.


Upon mkdir, I create a workflow.org file. It contains, simply, my guess of how the project will break down into manageable units. Think of XP's User Stories. At the start it will be chunky with lots of magic steps:

• TODO IO monad for communicating with X safely
• TODO ????
• TODO PROFIT

Don't worry. Very quickly, it will become fleshed out as more subtasks are discovered, testsuites needed, packages updated, build environments automated, etc. Soon workflow.org will be a visible reminder of what steps have yet to be done, what steps still smell of "MAGIC AHEAD", and what your progress has been. Each C-c C-t will reinforce your sense of achievement, a minor cause for celebration. Feel discouraged? Look up its version history and see a visible reminder of how far you've come in figuring out that your project is a beast of complexity: "wow. I really didn't think that making this threadsafe would be such a bitch."


Can't say it will work for anyone else, but this seems like a good way to keep a sense of momentum on a project without complicating things.

zipWith

I've come to the conclusion that I shave too many yaks. I tend to go into broad hack mode, following tangents into deep waters without actually producing proportional results. My old ~/code was littered with projects half-completed, outlined, etc. I wasn't thinking in terms of "get foo to work" but "foo is interesting, I wonder if I can do bar as well?" This led to separate dirs for each language, full of separate projects and translations/ports and experiments.

One day, I decided to start anew. I archived all those odd starts and stops, and put them away with the metaphorical juvenilia where in an ideal world adolescent poetry would remain.

Starting from a blank slate is drastic yet liberating. I can already hear the objections, though:

"What about DRY?" someone will ask.

Well, have you looked at the code you wrote only a few months ago? Is it really repeating yourself to replace inadequate kludges with new and more sophisticated ones? If I wanted to strictly DRY, I would never bother refactoring. Consider a fresh start a de facto "you can do better than this. Rewrite it from scratch so maintainers don't hunt you down and stab you."