<% Garbled

The buzz about Google Wave has worn off considerably (I’ve been unable to hand out the 18 Wave invites I have; if you want one, send me an email), but I also feel like I’ve used it enough to talk about it intelligently. I hear a lot of people still speak about Wave with confusion. They ask things like, “What is it for?” and “What am I supposed to do?”. People talk about running out of things to do in Wave. I’ve never really understood the thinking that leads to these quandaries. I tried analyzing it to understand it, but I don’t get it. So I’m going to try to explain how I’ve been thinking of it and hope that someone else can maybe bridge the gap for me.

What Is It For?

In a word: collaboration. It is not quite email and not quite AIM and not quite a wiki. It’s all of them. If you’re willing to wave someone instead of emailing them, you’ll get only a little bit of win out of Wave, which is that you can add someone in later, go back to edit old content and reply in line. That’s nice and all, but I think not enough that people really notice. Especially if the other person they’re trying to communicate with isn’t checking waves frequently.

The real win, in my experience, has been when I’m working with someone on some kind of document. For instance, some buddies and I want to put together a Gowalla Trip around the UT Campus. We started with a snippet that just had a big bulleted list of ideas from me. Below that, we discussed other ideas to add or not and all three added them to the list. Then we’ve been going around making the Spots and when we do, we add the url to the listing. It’s been a wonderful work flow; some of it has been real-time like a chat room and some of it has been asynchronous like email.

Similarly, I was working on some code and couldn’t figure out what was going wrong with a specific bit of it. I IMed a co-worker about it and he was trying to help me, but it was cumbersome because he couldn’t see the code (it’s a big campus). We switched over to a wave, where I pasted the code in. He could see it, edit it, reply in the middle of it. So much more efficient than using AIM.

So that’s the trick. Wave doesn’t have a lot of win over email if you’re telling your mom when to come over for dinner next weekend. It has a lot of win when you’re working with someone on some kind of document.

I Ran Out Of Things To Do

Well, yeah. That’s a bit like saying you ran out of things to do with your table saw. The same charge could be levied at gmail: if you don’t have any more emails to write or read, there’s not a lot else to do. Especially before people get comfortable with what wave is good at, you’re not going to have a ton of new waves. I, however, have had plenty to do in wave recently. Partly because I’ve been trying to find almost any excuse to use it so I could see what it was good at. This meant people replied to me there and some stuff wasn’t so good, but mostly nothing was amazingly worse in wave than whatever other tool we’d’ve been using for that interaction else wise.

So Wave Is Perfect?

No. In fact, I’ve found something that it’s pretty bad at or at least very awkward at: random chatting. If I IM a friend across the country to see how he’s doing and our conversation wanders in topic, I feel like wave is sort of too much structure. On the one hand, it’s nice to be able to manage threading as topics shift and change (if I post a tangent, we can basically split the conversation thread there). On the other hand, it’s kind of a pain to have to manage threading as topics shift and change. When we switch topics, do I want a new wave? Not really. I’m just not sure what to do with that kind of thing. Maybe it’s a matter of discovering the right work-flow, but maybe not.

Relatedly, since Google has taken the liberty of linking my gmail/gchat/gcal/etc. account with my wave account, it would be nice to be able to take a gmail thread or a gchat exchange and import it into wave for further editing. This is especially when I’m in a random chat and the topic shifts to some project we’ve been collaborating on. I assume this is something that’s on the horizon, but as I’ve been using wave pretty regularly, I’d get a lot of mileage out of it now.

I also think there are some things wave is or will be good at that no one’s discovered yet. I think it has huge potential and I’d like to warn people off of giving up on it too early. Like so many things that are super valuable to know how to use and can change the way you work (or work/play) for the better, it’ll take some getting used to, some learning and some exploration.

At the last Austin on Rails meeting (Nov 17), I gave a talked entitled Practical Git Quickstart (Prezi link). The slides don’t have a lot of content and mostly underscored what I hoped to talk about. I blew through them in about ten minutes or less. The short of it is that I feel like a lot of git tutorials and introductions start off with the high-level stuff and that, especially for people new to git, that that’s confusing. My goal was to give git newbies the most basic commands they’d need to be able to use git on a daily basis so that they could build their own abstractions before diving into the more heady stuff. I was aiming for an 80% solution to that, anyway.

After I finished the slides, I fired up a command line and an editor and just worked through some stuff. This post should sum up what I talked about, more or less. I started out covering the same stuff I covered in my previous git tutorial post, so maybe go check that out first. It should get you through setting up a new repository, adding files to the staging area, making a commit, checking your status and committing to a remote repository.

So let’s pick up there, with remote repositories. The way you get code up to your repo is with git push origin master. Once it’s up there, other people can get at it. If you recall, you told git where your remote repo was going to be with git remote add origin git@github.com:<username>/<project>.git. Someone who wants their own local copy of your repo does so with the clone command like so: git clone git@github.com:<username>/<project>.git. That will create a directory wherever the command is issued, named <project> and pull down the current state of the remote repo. Then, that person will be able to push their own changes, etc. This is all, of course, assuming they’ve got permission to do so.

So this new second person makes some changes and pushes them on up. How do you get them? Well, sensibly, the opposite of push is pull, so you issue git pull origin master. This is actually a two step process that’s just for convenience. I don’t want to get into the plumbing too much, but it basically grabs the state of the remote repo (git fetch) and then attempts to merge (git merge) it with your local stuff. So that’s the most basic case of working with someone else on a project, or working alone on one using different machines, if you like. I use that case all the time.

So what about conflicts? If you both make a change to the same file and they push it first, you’ll not be allowed to push because git can’t handle the merge on it’s own. Similarly, if you try to pull, it will do the fetch part, but be unable to merge and will tell you so. You can use git diff to see what the changed were and do the merge yourself. You can also use git difftool which is awesome, but takes some setup, so you should look into it later on (I skipped it in my presentation).

Once you handle the conflicts, you’ll add the conflicting files to the staging area and make a commit. With all merges, I should note, git makes a commit just for the merge, so when you have conflicts, it’ll have staged the things it can merge on its own and left the conflicts unstaged. As you fix them, you stage them and then you commit the merge commit. Git doesn’t know if you really fixed the conflicts, so you can gid add whatever version of the file you want, even a broken, not-conflict-resolved one. Just be aware.

That was more or less the end of my ordered presentation. There were some questions afterward and I’m going to attempt to sum up the discussion that followed, here:

First off, I wanted to mention how you ignore files in git. Unlike subversion, there is no git ignore. If you want git to ignore a file, you have to add it to a .gitignore file. This file is a list of patterns that git will ignore for the directory it’s in and all directories below it. So you might have one for a python project like this:

1
2

tmp/*
*.pyc

This will ignore all compiled python code (*.pyc) and everything in your tmp/ directory. I was baffled by this when I first came to git, but it’s not really that hard. Note that you generally commit your .gitignore so that others can share it. If there’s something you want to ignore on a per-machine basis, rather than a per-project basis, then you need to turn to my next topic.

Which is global git preferences. On Linux and Mac, git will look for a file in your root directory called .gitconfig and take global behaviors from it (it’s tricky on Windows, and I haven’t figured it out to my own satisfaction, sorry. If someone asks about it, I’ll try to sum up what I know in the comments). In my other git post, I had gone through setting up a repo on GitHub and said to follow the directions there. Two of those steps were these:

git config --global user.name "<your name>"
git config --global user.email <your_email>

Those created entries in your ~/.gitconfig telling git your name and email address. You can also declare a global ignore file there. I like to call mine .gitignore. This is shockingly original, I know. On the machine I’m typing on right now, my ~/.gitconfig looks like this:

1
2
3
4
5

[user]
  email = <blah blah blah>
  name = Ben Hamill
[core]
  excludesfile = /home/ben/.gitignore

I bet you can guess it, but just in case, you can either put your excludesfile in manually or do git config --global core.excludesfile /whatever/file/path/you/want. For reference, my ~/.gitignore looks like this:

1
2

*.kpf
*.swp

A .kpf file is a project file created by Komodo Edit, which I used to use for all my code editing needs, but not since I switched to vim, which is what creates *.swp files.

Finally, someone had asked about git stash. It’s what I’d consider a more advanced command, but a lot of git fanboys sell it hard because it’s cool and svn doesn’t have it. However, as cool as it is, I think it can get you into a lot of trouble. Basically, you can be working on something and issue git stash and git will store whatever changes you’re in the middle of and hide them away, putting your repo back in the state it was right after the last commit. You can then work on something more pressing, make commits, merges, new branches, whatever and when you’re done, issue git stash pop and it applies your changes back (if it can).

The really hairy bit is that you can name stashes and so have more than one stash going at once. While a super organized developer might find this really useful, I find that it’s easy to get stuff lost in there. You don’t want to have tons and tons of stuff stashed and not remember, anymore, what changes were in which stash, etc. I advise, as a basic rule of thumb, that if you’ve already got one thing stashed and find yourself wanting to stash something else, then you should be looking at branching, not stashing.

I think that about covers it. I think someone recorded audio of my talk or maybe video. If it ends up posted somewhere, I’ll come edit this post with a link to it. If you were at my talk and notice something I talked about then that I haven’t covered here, let me know and I’ll try to amend. Or, if you weren’t there and feel there’s a topic you have questions about, drop it in the comments and I’ll do what I can.

I recently started using vim on my Linux machines for development (actually gvim and I just haven’t gotten around to installing it on my Windows partition). I’d tried to learn it some time ago with the understanding that it’s awesome, but it didn’t catch on. I know a lot of smart people who use it and it was always one of those things that I felt would be really valuable for me to learn, but—it was hard.

Well, now it’s easy. @adambair mentioned this blog post by Derek Wyatt. It’s a collection of videos he made introducing you to the most basic commands in vim. Enough to get your feet under you so that further research on your own has something to stick to. They’re awesome.

However, the reason they’re awesome is not just that he takes you step by step through the most important stuff or that he’s lighthearted and friendly-sounding. The awesome part is that he shows you why it is that vim is so raved about. If you try to learn vim thinking that it’s like TextMate or NotePad or something, you won’t get it. And until you get it, there’s very little impetus to get over the learning hump (or through the dip, depending on which way you chart things in your head).

The key to understanding, for me, was realizing this: You should not be spending most of your time with vim in insert mode. You should not be typing and selecting in the sense that Word teaches. You should be doing finds and replaces and yanks. You should be operating on your code with macros. If you’re writing new code, great. You’ll be in insert mode for a while, but even then, you’ll want to invoke something that’ll set up your class structure with maybe some default methods in it or something. And as soon as you’re done, you’ll want to be jumping around by line number, moving to a specific character in a line, replacing a segment of a line with two keystrokes. Really, just the movement possibilities blew my mind. So, go watch the introduction.

For those of you who thought my last post (about role playing) was interesting, I have some news: I won’t be posting about that stuff here. I will, however, be writing on the topic. My friend, Stewart, and I realized the he and I would have a lot of fun writing together on a blog specifically about role playing. So if you are interested in our thoughts on that topic, we’ve called it Maximizing Rockmost. We’ve started off with several posts (some of which are expansions of material from my post here) so you can see what sort of thing we’re likely to be writing about. I’m looking forward to it.

For those of you who wonder why I’m blathering about RPGs and wish I’d get back onto a technical topic, don’t worry. I’m presenting at Austin on Rails this month about git (along with Mike Subelsky of OtherInbox). I plan on blogging about that presentation. I also want to write about vim and about ruby koans and about making my first ruby gem. So there’s technical topics in the pipeline. Never fear.

This is one of those posts bloggers write so that they can repeatedly refer to it later on. I intend this to be a short introduction to role playing (as in nerds at a table with dice, not a couple playing Santa or whatever your kink is) followed by a bit about my tastes and general habits regarding the hobby.

What’s an RPG?

If you want, check out the Wikipedia article on it, but my definition of a role playing game is this: There are some number of players and generally one Game Master (Dungeon Master, Referee, etc. terminology varies). The players and Game Master (GM) are telling a story together. Each player makes a character (a Player Character: PC) and they constitute the main characters of the story. In order to offer some tension for events where chance plays a part in the outcome, the group is generally using a set of rules that uses a randomizing tool (various kinds dice are most popular, but I’ve heard of cards, for instance) to help decide if the characters succeeded or failed at certain tasks. The important thing, here, is this sentence: The players and GM are telling a story together.

The GM is in charge, basically, of running the simulation, as it were. He (please don’t take offense at my use of pronouns, Lady GMs) manages the world, figures out what the various not-protagonist characters (Non-Player Characters: NPCs) are doing, arbitrates the result of any actions taken by the players the outcome of which is not guaranteed, etc. The other thing that the GM does is he plots the stories the group tells together. Plotting for an RPG campaign, however, is significantly different from plotting for a book or movie because the players each control one of the main characters. So the GM ends up getting a general idea of where things are headed, what the major goals of various NPCs are and then how the PCs fit into it all. Then the PCs get in there and muck things up in interesting, fun ways. This collaboration in authorship means (like laying out a web page) letting go of a certain non-trivial amount of control as compared to, say, a novel author.

The Ways of Ben

In my specific group, I’m the GM. I have, right now, three folks playing in the campaign I’m running. In many schools of GM thought, game play from one sitting to the next are strung together to form a “campaign”. The term originates from D&D’s origins in table top war gaming, so it can be a bit of a misnomer as it’s used today. What constitutes “a campaign” varies widely. My definition, which you’re about to read, is not in the majority, but it is how I do things.

In my social circle, a campaign is like a book: It has a beginning, middle and end. There’s some unifying plot that ties it all together. When the plot is done, those characters go away and you read an entirely different story (please ignore Robert Jordan for purposes of this analogy). A lot of people think of a campaign and the game as one and the same. They might be confused or skeptical about the same group of people just putting down one group of characters and making new ones. Campaigns without an end point in mind from the start can last for years and years and they generally increase in power level (trying to out do themselves over and over) to a place where the characters are fighting gods or eating planets or something suitably EPIC. People have fun doing this and that’s great for them, but it’s not for me. It starts to feel like a TV show that’s been running too many seasons in a row (better bring in Henry Winkler and some skis). I like a narrative arc and I like to pick the amount of epicness from the get go and have it be relatively stable. Also, having campaigns with a designed ending lets me change settings and try on a lot of different ideas. Which leads me to my next point.

My system of choice is GURPS. You can follow that link or not, but suffice it to say that it stands for Generic Universal RolePlaying System. It’s basically a toolkit of rules without any setting information (contrast the famous Dungeons & Dragons, which describes the world the game is played in to great detail). The thing I like about this aspect is that you can play a D&D-like fantasy campaign to completion, then play a space opera and then play a police procedural or something. The ability to try out one thing for a while (length of my campaigns varies wildly, so take that with a grain of salt) and then entirely change gears for the next campaign is a big draw for me. As a GM I really enjoy the world-creation aspect and so I’m constantly thinking about what worlds would be fun to play in and what stories would be fun to play out in them; what kind of interesting people might live there. You get the idea. That’s not the only reason I like GURPS, but I don’t want to evangelize too much. Maybe that’s a future post.

Another thing I do that I’ve heard very few people talk about is I’ve got a GM consultant. This is new as of my most recent campaign, but it’s worked out so well, I can’t imagine why I’d stop doing things this way unless the consultant turned into a player. Basically, the friend who introduced me to GURPS moved away and, in order to get his role playing fix, offered to help me hash over things with the world building of the campaign I was thinking of running. I recommend this technique to every GM that can swing it. Having two minds on the task, as long as you work well together, is an incredible boon. Your NPCs will seem more real and your world can afford to be more complex. It’s easier to track more events happening at once and you’re both going to think of cool things that the other wouldn’t have. I feel like it’s been multiplicative rather than additive to the quality of the campaign world.

Most RPG groups make a “party” or other group of characters that more or less always act in concert. They make decisions together and go do things all as a group. Lengthening the parade of unconventionality, that’s not how I do things. If your character is not in the scene, you’re not in the room. For some campaign settings, that means players (especially early on) can spend a non-trivial amount of time in my living room playing Rock Band or whatever instead of role playing. The win is that by containing information, you can, for instance, more easily dole out clues to each of the players and have them piece it together later when they’re all in. This is cool for the players, not for the GM, I should note. The other thing it does is it lets each player get used to his character and how to play him without the noise of other players doing the same thing; to establish a sort of a base line. It takes a while to really figure out how to inhabit a character you’re playing and unlike other kinds of acting, there aren’t really rehearsals.

I’ve implied that there’s a stage, early on, where the characters aren’t spending a lot of time together. This is a symptom of what my GM-consultant and I call the Dann-style Campaign (Dann was the guy that introduced my consultant to GURPS). Dann-style Campaigns are very formulaic, but it is a formula that works very well. There are 3 (less commonly 4) PCs. They don’t know each other at the start of the story and they all have different goals, needs and reasons for doing things. There is some kind of plot or conspiracy or mystery going on and their various goals draw them into being involved in it, which causes them to meet and discover/uncover/solve it together. The entire campaign general centers around a single, well developed location (say a single city). The fact that the characters are strangers and have different goals means they don’t trust each other right off. The fact that they have different (possibly opposed) goals means they want different things to get done or have different priorities for things to get done. Together, those two facts make it not uncommon for a player to say, “Great. You guys go do that, I’ll catch up with you later,” and then go do his own thing.

I hope this makes a bit of sense to the uninitiated. If you’ve read anything by William Gibson, he uses this sort of story telling a lot. There will be several independent stories going on that, in the end, all have to do with each other in some way and come crashing together at some point in the tale. Now, Gibson tends to have things come together in the final act. In a Dann-style campaign, you generally want the PCs to all meet and start collaborating around the half-way point of the first act. “Act”, here, is a vague unit of story-telling, not anything specific, mind.

Or think of a show like Lost, where the characters are strangers at the start and there’s a high level of distrust and paranoia about each other. People spend a fair amount of time doing things on their own. From setting to setting, of course, the level of distrust can be dialed up or down. In Lost, the level of distrust is rather high between some protagonists and there’s a fair amount of alliance shifting as time goes on. In a Dann-style campaign, you wouldn’t have as many PCs as Lost has main characters and so shifting alliances between them would be somewhat tricky to do if you wanted it.

All of this is really in service to the next post I want to write which addresses some ideas I’ve been batting around about how and what to vary up in the Dann-Style formula. It seemed that, before I talked about variations, I should do a kind of an introduction to my style and, then, that an introduction to what an RPG is, etc. seemed appropriate. If you have questions about anything I’ve put here, post a comment and I’ll be happy to answer it. Be warned, I may try to convince you that you should give role playing a try.

You read my blog, right? I mean—here you are reading it. I’ve been having an internal debate for a while about something, wondering what people who read my blog would think. Then I realized there’s a wonderful way to find out: ask.

So far, Garbled has been mostly about programming stuff. I also do a fair amount of table-top role playing and since I started blogging, some of my ideas on that topic have ended up sounding like they might be worth a blog post. But I don’t really have a role playing blog. In considering whether to post about both topics on Garbled, I’ve got two conflicting things going on:

1. People say you should pick a topic and stick to it if you want to build readership. By this advice, I should talk only about programming here and find another place to post role playing thoughts.
2. My thinking about programming and about role playing happen in adjacent or overlapping regions of my mind, so, to me, they are somewhat complimentary. I sort of feel like seeing both those lines of thought paints a (more) complete picture of me as a person.

So what are your thoughts? Would a rare or uncommon post about role playing in general or maybe GURPS in specific be alright? Considering that it would mostly probably be about plot construction and other GM related activities. Or should I stick to programming and programming-adjacent topics? Let me know in the comments.

National elections, especially the Presidential elections, get a lot of attention in the US. People talk for months about who might campaign before people even announce their candidacy. There are news stories all over the place covering them. On the other hand, more local elections (for state reps or city councils, etc.) get a lot less coverage (because it’s not CNN’s job, for instance). Right after this most recent Presidential election, I realized that I hadn’t voted at all since the previous Presidential election. In four years, I hadn’t cast a ballot, and I thought I should probably become somewhat more involved in local politics. Or, if not involved, at least aware.

One of the buildings adjacent to the one where I work is a polling location. In Texas, that means I can vote there during early voting. A few months ago, I was cutting through that lobby and saw voting booths set up. “Oh!” I thought to myself, “I wonder what we’re voting on today.” I could have voted right then, but I had no idea what was on the ballot, what the various opinions and angles were, etc. It would have been totally uninformed and random, so I refrained, but I started thinking about how I could be forewarned about elections so I could do my own research.

I could start watching the evening news or following local (or state-level) political blogs or take the local paper. But that’s a lot of overhead which I’ve already decided I don’t want to deal with… and just to get one piece of data. So I thought I’d solve my own problem and the way I’d solve it (and solve it for people other than me, who think in a similar way on this issue) was with Twitter.

The Pitch

My initial concept was that I’d set up an app that would store election dates and just tweet them. I quickly realized that it’s a little more complicated than that. If I just tweet on election day, I’ve just recreated the oh-what-are-we-voting-on-today problem. So I need to give some warning ahead of time. @JonLoyens pointed out that a tweet can be easily missed, so I should use direct messages. The beauty, here, is that I can build a reminder service and not have to manage who wants reminders: It’s all just based on who’s following the twitter account.

So the idea is that you’ll follow @heygovote and it will direct message all its followers to warn that an election is coming up. Simple enough and if you want to opt out, you unfollow. Easy.

Three Rules

I want to keep these three things foremost in my mind while I’m working on this thing:

• No Bias – I don’t want to help people decide how to vote, or influence their vote in any way. This is just about prodding people enough in advance that they can do their own research.
• No Data – I don’t want to know who the users are and I don’t want them to have to trust me that I’m not selling information about them to some organization (related to the above, as well). So I don’t want to have to know anything about the user other than their Twitter user name and I don’t even plan on storing that, just asking Twitter who’s following @heygovote.
• No Bother – I don’t want to hassle people. I want to remind people, not badger them. I also don’t want to have to mess with the thing myself to keep it running; it should be fire-and-forget.

Trouble Scoping

It pretty quickly became evident that I needed to decide who my target was. I’d intended to target “Austin”, but that doesn’t really scale gracefully to the county, state and national levels. After talking to my brother, who works on campaigns and the like, I’ve decided I’m going to target Travis County. That catches most of Austin (more to the point, it catches where I live, since this is solving my problem) and also scales up nicely.

For voting purposes, Texas breaks counties up into voting precincts. All the election dates for all the precincts in a given county are the same, so one tweet (or, rather, direct message) will apply to everyone in Travis County. If, beyond comprehension, this becomes wildly popular and other places want HeyGoVote to cover them, then I’ll deal with that as it occurs. My guess is that how elections are handled will be different enough from state to state that it would mean rebuilding the date-getting machinery for each, uh, constituency, as it were.

Where to Start

I haven’t started coding on anything yet; all work to date has been design thinking and research on how I can get a hold of the information I need. I’ve sent some emails back and forth with the Travis County Tax Office (which decides election dates, oddly enough), who’ve been helpful. They don’t seem to have a handy RSS feed of election dates that I can poll, so I’m still working out that side of things.

I will probably start on the reminder side of the application. If I design the DB schema intelligently, it can be very loosely coupled with the data gathering bit. Depending on how it goes, it also seems like the kind of thing that might make a useful Rails plug-in, too. So I might release that on it’s own.

That being said, I expect to use Rails as the tool set. That might seem like overkill since nothing I’ve described has needed a web interface to it, but I have the idea that, after I get the reminder working, it might be nice to build a tool or two that would help people figure out where their polling location is (for folks who skip early voting), what’s on the ballot for their precinct and things like that. If I can’t find existing, non-partisan tools to link to for this, I might have to build my own.

Expect to hear more about this as I work on it. If you have any suggestions or questions, leave a comment.

Whenever we interact with the world, we use cognitive shortcuts. It’s handy, you know. We make assumptions about our environment so that, if we’ve guessed right, we can respond appropriately to our environment more quickly as it changes. It’s a survival technique.

However, it can sometimes get us into trouble, especially socially. We see someone dressed a certain way or giving some other kind of social cue and we assume other things about them. Most of the time, this works brilliantly; they’re sending those cues on purpose and we’re supposed to interpret them the way that we do. Or they’re not sending those cues on purpose, but they’re identifying with a group and so our reaction is still appropriate.

I have a hard time, sometimes, in social situations. I have had to learn, via careful and intentional observation and memorization, many social conventions that it seems others picked up earlier, easier or more instinctively. So I’m somewhat sensitive, now, to the social cues that others send. Which is to say that I’m more consciously aware of the ones I notice, not that I notice all the little ones; the fact that I have to consciously process them slows me down and I miss many cues because of it.

I struggled, for a long time, with the fact that others often acted as if I understood some cue I’d missed (a reasonable assumption on their part, statistically speaking). And I realized that I was sending as many “normal” social cues as I could in order to fit in (my younger self was less comfortable being a huge nerd than my present self). But this meant that people were under the impression that I conformed to their expectations… I was basically lying to them.

So I set about trying to find some things I could do that would indicate to someone that they’d be best served (assuming their goal was to communicate effectively with me) being fully mentally engaged, rather than on auto-pilot. When i first had this idea, I also had the idea that I was special and different and so more deserving of people’s full attention. I’ve since become a bit more humble in that regard.

I don’t want to get into a whole ton of detail about my personal expectation breaking journey. I want to come to my point, which is this: I wanted to break people’s expectations so that they’d have a “What?” moment and hopefully clue in that something new or uncommon was going on. Instinctively, I knew I shouldn’t go too far off, but it’s not something I realized until recently.

Whether it’s yourself or a product or brand, I think people often want to break expectations. And I feel like people hand out that advice a lot. It’s decent advice, too. However, it’s one thing to wear funny socks or something and another to dress in a gorilla suit every day. Funny socks are different enough that people will look at you oddly, but still feel like they can have a conversation with you. A gorilla suit is so radical that many people will assume they can’t cope to the difference, whether they’re right or wrong.

The analogy that popped into my head when I initially thought of this was a window. If you want people to see you (assuming you’re transparent, like, you know, a window), then you might think that cracks would help. I certainly notice a window with a crack more than one without. But if you apply too much force, you’ll shatter the glass and there will be gaps in the window and jaggey bits that people are afraid to some too near, etc. It’s a much more upsetting experience. I guess my advice on the topic (for those that want it) is this: Break expectations if you like, but apply light pressure so you don’t shatter them.

In light of my last post, I got to thinking some more about old school hackers. Also, at my job, we’ve got some people who’ve been here a long time. One in particular, we’ll call him Steve, is very smart, but… And, see, that’s sort of the thing: I can’t put my finger on it exactly. Steve is blazingly smart. But there’s clearly a difference between he and I that isn’t, I think, just accounted for by the 20 or so (I’m guessing) year difference in our ages.

If I see something I dislike—something that could be better—I really want to see it change. I want to be involved in that change if not driving it. Steve is often watching and present. He’s paying attention mostly and if you ask him a question he’ll have an insightful answer. If someone proposes a change that’s actually a good one and addresses a real problem, etc. etc. he’ll be glad the change is coming. But he never pushes for it. He never starts a conversation (in the wider sense, I mean; he will say hi to you in the hall or whatever) and hardly chimes in unless addressed directly.

And I think Steve fits a sort of archetype. He’s very interested in low-level details (well, actually in almost any kind of technical detail). He seems to be pretty much interested in being left alone and tinkering in his shop to see how things work (to use a light metaphor, here). If something is bad or less than optimal for other programmers around him (and including him), he’ll either ignore it or work around it on his own. His solution wont be general enough to apply to everyone, though and he wouldn’t publicize it. He’s very internally focused. And I associate this stereotype with older programmers or, more accurately, with old school programmers (how long have you been coding, not how long have you been alive).

On the other hand, I think think there’s a newer breed of programmer that’s becoming or has become very common. And I want to be very specific, here: I’m talking about hackers; folks who code because they enjoy it, not those who do it because its their job. People who would code to solve computer-related problems they have at home even if they were a news anchor or a trail guide. This new breed is more externally focused. We want our solutions to problems to be useful to other people. We want to have a conversation and (often) change the way things are done (for what we see as the better). We want powerful abstractions and like to live up away from the metal, generally.

I haven’t cataloged all the differences and, in particular, I’m having a hard time figuring out the attributes for my “new breed” of hacker are. Of course I’m talking about generalizations and stereotypes, here, but I don’t think that’s intrinsically bad. Basically, I get a sense of a certain amount of cohesion in personality type and behavior in these two groups and it struck me as interesting. What do you think, am I drawing a distinction where there is none? Is this distinction useful for anything? Is there some interesting point I’ve missed?

You frequently hear (or I do, anyway) the advice that if you’re unhappy in your coding job, you should scratch your own itch, work on what you love… Work on something you’d be a user for. Because then you don’t have to do a bunch of requirements gathering and get them inevitably wrong, etc. etc. The idea seems to be that if you love the business process, you’ll love working on the code that enacts it. And, well, that’s fine. It seems to make a lot of sense, on the surface. But then I thought about history.

As programmers, we don’t have a lot of it (compare auto workers or, say, masons). History, I mean. But there’s some and in the days of Mel and COBOL Cowboys things were different from what they are now. Today we have all these powerful abstractions and high level languages. Folks (well, not all, but many) consider it to be ideal if you’re basically writing your code in a DSL specific to your business process. Which means your code is really tightly coupled to your business (on that layer, anyway). I don’t know that that’s a bad thing at all (in case I sounded critical). I just want to contrast it to what came before.

Those dudes were almost just writing ones and zeros. They were so far removed from the business processes they were enacting and the folks who were using their stuff that I wonder how much impact it had on them. Would Mel have been any more or less happy writing financial management apps for large companies than solitaire? I kind of think it wouldn’t have mattered to him; he was in it for the code and playing with numbers. He enjoyed all that low-level stuff.

So I wonder, is our (figurative us, here) unhappiness when dealing with business processes we aren’t personally invested in a symptom of all of our awesome high level languages and nice abstractions?

I have a lot of online identities. Who doesn’t these days? I’ve got a gmail account, which means I also have a gchat account and that account can also double as an OpenID. Because I got on the bandwagon before Google did, I have a different OpenID. I’ve got an AIM account (well, one active and a few that’ve atrophied over the years). I’ve got a Twitter account and an account at Hacker News and one over on the GURPS fora and an OtherInbox account and… a ton of other sites. Sometimes, it’s all a lot to keep track of.

However, sometimes they get conflated in ways that annoy me. For instance, especially since getting hooked into OtherInbox, I’ve protected my gmail account a lot. I route to it from several @benhamill.com addresses, for instance. And, really, it’s harder for other people to remember my picked-it-because-of-a-crowded-namespace-username at gmail.com than it is to remember my-first-name at my-full-name.com.

However, the circle of people I give my (or an) email address to is different from the circle of people I want to chat with over AIM (and is certainly different from the circle of sites I’d want to sign into with an OpenID). So I have warring desires: I like having an XMPP chat account now that I’ve used gchat and I wouldn’t have tried it if it hadn’t been handed to me, but now I wish it were a different account (so I could disclose my chat id, but not my email address). Problem is, now that I’ve got people used to that identity in that format, the overhead for switching is somewhat high. Also, there’s the convenient merging of contact lists that Google does for me (probably possible with different identities, but certainly not as easy).

So, if I didn’t have an OtherInbox account and I didn’t have a separate OpenID: just my gmail account… I’d be (tacitly) giving my email address to people I wanted to chat with and websites I signed into with OpenID, I’d be giving my OpenID and email address to people I chatted with, etc. That seems… bad to me. Am I being paranoid? There’s a balance, here, between lowering the bar of entry (“Want to try out New Thing X? Easily done: you already have an account.”) and separation of concerns. What’re your thoughts on the topic of identity management and separation thereof?

There’s been tons of hoopla about these slides that some guy showed at GoGaRuCo . Seriously, so much hoopla that I’ve been unable to absorb the guy’s name (note: I have a really, really hard time with names as it is, so…). Also so much hoopla that I don’t even really know what to link to so that people will have an idea of what I’m talking about if they don’t already. I guess _why did a decent job of explaining it by not explaining it. The short story is that there were some slides in a presentation with very scantily clad ladies doing very suggestive things. Everyone’s freakin’ blogging about it and I hate to me-too this thing, but I do want to express a thought I haven’t seen yet and I also neglected to make a post this month, which has been bugging me.

And Now, a Tangent

So in college, I played trombone in the marching band. It was good times and we had this principle that we called The Stupid. This may not make perfect sense to people who haven’t experienced band social dynamics first hand, but I’m going to try. Basically, the trombone section had a reputation amongst the rest of the band (360ish total members) for doing ridiculous, stupid things for no reason. It had been decided amongst ourselves that, rather than try to live this down, we’d just run with it. So we did Stupid things on purpose; frequently to humorous effect. I mean—we were always entertained, others were only sometimes entertained.

That was the big flashy visible part of the Stupid. We got elaborate, spending large percentages of our meager college student incomes on Stupid ideas that we planned for weeks. We went to great lengths. The part of the Stupid that wasn’t so visible was the great lengths we went to to ensure that we didn’t… inflict the Stupid on anyone who didn’t opt in. We had the goal of making so that if you missed some prank (or whatever you want to call it, not all of it was traditional pranks) of ours by a few hours, you’d never know it happened. We had varying levels of success with it, of course, but I think we did a pretty good job.

We also tried to go to Stupid lengths to be helpful to the band in general; we’d help clean up or take care of something that we saw needed doing rather than just waiting for someone else to do it or reporting it or whatever. I should point out that the directors found the Stupid highly unamusing in the way that I think is probably appropriate for teachers to find the antics of their students. Taking care of things and working hard was sort of our effort to come out net neutral in their minds and not get in hot water.

So the ‘bones weren’t nationwide (well, the Stupid did get on ESPN in the background a couple times and of course we were on TV performing at games, but not for our antics, generally), as Giles says, but we did have a reputation for being bad and (the key to being bad) getting away with it.

The Moral of Our Story

So, as things go in college, people get older and graduate and new folks come in, etc. Traditions shift and change. There came a day when some new kid was really jazzed up about the flashy, visible, bad part of The Stupid and didn’t have the working-hard, cleaning-up-after-yourself, help-others-out part of the Stupid down so good. Basically, he was seeing the bad and didn’t see what let us get away with it. And he (I’m actually talking about several people over a period of time and series of events) did something he thought was Stupid, but was just stupid. He got on people’s nerves, got in people’s way, maybe he broke something that cost money… and he didn’t do anything that would make people think, “Well, that’s alright, because… whatever.”

So I hope you see where I’m going by now. Amongst Railsers (as a broad generalization and as distinct from Rubyists) there’s a bit of a tradition of being bad. DHH is, arguably, the originator of that attitude and he’s certainly been an icon of it. I’m not even saying he’s wrong. I’m saying that whenever you have people like him (and he is, I should stress, not alone, here, Cf. Chad Fowler, Giles Bowkett and Zed Shaw) there will be others who look up to that way of being, who idolize it, who imitate it, but who, ultimately, don’t get it.

These freshman, as it were, will do the flashy, visible, bad part of the image (perhaps poorly, but perhaps not) but neglect to do the more subtle things that let their idols get away with it. I’m not sure what it is those idols are doing, specifically, that makes up for their behavior (they certainly aren’t practicing their music the most). I suspect that, really, everyone has to find their own way to make up for acting like a jerk.

What I’m driving at is that if you’re setting an example (as anyone highly visible in a community is) for being so awesome that no one minds when you’re a jerk, you have to take a bit of responsibility when others imitate you and screw it up. I think Matz chose (probably by nature, rather than consciously) an easier path: If you set an example of being humble and nice and people imitate you and fail, they’ll at least have the safety net of, ”...well, his intentions were good.”

Context… Perhaps Too Much Of It

So I was reading this blog post about learning and explaining because @carl_youngblood tweeted about it. I think Carl’s right: I had a hard time learning git (by which I don’t mean to imply I’m some sort of expert now, but the learning is going easier now).

I think the main problem that I had was this: Having learned Subversion, with it’s central repository, it was a hard abstract thing to understand. And some (I feel many of the ones I read, anyway) of the tutorials out there try to start at the abstract. Little help that did me (see above-linked article. Really, it’s very good). And even ignoring those, I had to read a lot lot lot of the practical ones before things started sinking in.

So I’ve sort of come to understand that, actually, the tutorials don’t suck; learning abstract things just takes time and, at the time, that can be frustrating. So I’m going to offer my own little sucky tutorial, which will focus on the practical aspects and, if you read this and don’t get it, you can follow some links at the end to other articles I found helpful and maybe, after roughly a week, you’ll have your ‘ah-Ha!’ moment and think about how git is just like monads… whatever the heck those are.

A lot of tutorials for git newbies start out explaining the Staging Area with some kind of metaphor so that it seems friendly or, I suspect, out of some subconscious wish to actually obscure it from Subversion converts so that git seems more familiar—more like SVN, which it is not very much like at all. I’m not going to really talk about it much. When we get to the commands that affect it (shortly, here), I’ll explain what they do. You can make the abstraction your self.

I’m intentionally writing this off the top of my head for two reasons: If I have to look up a command, then you might as well read whatever tutorial I looked it up on and if I have to look it up, then I clearly don’t use it all the time and thus, you don’t need to know it to get going on Git.

The Tutorial

1. Setup
2. Initial Commit
3. SitRep
4. Staging Area
5. Remote Repo
6. Conclusion/Links

Setup

You have a project you just started in a directory called ‘notes’. This isn’t even code, it’s just notes about something that you want to version control and back up. It’s a collection of text files and the directory structure is something like this.

$ pwd
~/notes/
$ ls
contact_info.txt  general.txt  outline.txt

After installing git as appropriate for your operating system, you start out by typing in the command line git init. This will create a directory called .git in notes/. There’s some stuff in there, but for the most part, you can ignore this for now. Suffice to say it’s where git does it’s book-keeping. What you’ve got now is a local git repository or, as the kids say, a “local repo”, but nothing’s in it.

Initial Commit

So you do a git add . (note the trailing period). This will toss everything (that’s what the period means) in notes/ into the staging area (including stuff that’s in directories that’re in directories that’re in notes/ etc.). The repo is still empty. To actual save stuff once it’s been staged, you do like this:

$ git commit -m 'Initial commit.'
[master (root-commit)]: created 7db8343: "Initial commit." 
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 contact_info.txt
 create mode 100644 general.txt
 create mode 100644 outline.txt

The -m option says you’re going to specify your commit message right after. Sometimes, you’ll want to leave a longer message, in which case, you forget the -m and git will automatically fire up a default text editor where you can put in longer stuff. Since a lot of that varies widely from OS to OS, I’m going to skip it and you can read more details on other tutorials (see below). Notice that you get a list of what’s changed (you created 3 new files in the repo) and you get your comment back in the output. Splendid.

SitRep

Now you’ve made your initial commit, and your stuff is in version control. Go into contact_info.txt and add something (doesn’t matter what for these purposes). Imagine you’ve made that change and then walked away and forgotten about it. You can use git status to see what’s new, thusly:

$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   contact_info.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

Using git status is just like a reminder. It doesn’t tell you much, but it can jog your memory about what you’ve already staged or what you changed and didn’t stage or what files you added. To get the real scoop about how a file changed, you use git diff. When you run git diff contact_info.txt the output will vary depending on what you had initially and what you added, but the gist is this: It will show you the changes (all of them) with a + before the line for additions and a – before the line for deletions. Generally, it gives a few lines before and after a change for context.

So let’s add our new contact_info change to the staging area and commit it, yeah? Do git add contact_info.txt and then git commit -m 'Updated contact info' or similar. Whatever comment you write is fine. Note we could’ve used git add . but I wanted to show the single-file syntax.

Staging Area

Now let’s put in some stuff into the outline.txt. Whatever you want. Just some stuff. Save it. But wait! We should also add some stuff to the general notes, just a quick overview at least, so put some stuff in there. We’ll finish the outline changes in a second. This is so much more pressing. Obviously.

Now, it’s good repo etiquette to only commit stuff atomically, which is to say that all the changes have to do with each other. Some people will say that you should only commit stuff that works (code compiles or whatever), but with git that’s less of a concern. I’ll come back to this point. What I’m getting at now is that you started one change and realized another needed to be made before you finished the first one. Now you want to commit only the second one, right? Simple: git add general.txt then git commit -m 'Added overview'. Because you never staged the outline (with your half-way-made changes), it doesn’t get committed. Later, if you need to revert that commit or whatever, you won’t have to worry that something else is mixed in there. Now, go ahead and finish your outline changes, and commit them. You should be able to do it on your own now.

Remote Repo

So, then… we’re version controlling this stuff. What if you want to get at it from another computer or let someone else get at it or… something? Pop on over to Git Hub which is my remote repo host of choice. There are others. Shop around, if you like. After you create an account, you can create a new remote repo called whatever you want. You’ll then be shown a page with some directions. Follow the ones under the heading “Existing Git Repo?”

The git remote add origin git@github.com:<username>/<project>.git command basically tells git where your remote repo is. You can have more than one if you like and, actually, do all sorts of crazy things with naming if you like, but I just want to handle the default, assumed case with this tutorial. One interesting thing: Github gives you two addresses for each repository (other hosts may do the same, I don’t know). The one that starts git@github.com is your read/write address and there’s one that starts git://github.com which is your read-only address. Since this is your own repo, you want to make sure to use the read/write address.

The git push origin master command is what actually moves your commits to the remote repo. This is where I recommend you adhere to the “only stuff that works” doctrine. If this is code, and you’re sharing the repo with your team or whatever, this is where they can get at it, so you don’t want to hand them broken stuff or half-finished ideas or whatever. So only push code that compiles/works. Pushing your code updates the remote repo with all the commits you’ve made since your last push.

The way you (or someone else) gets commits out of a repo is by using git pull. It takes the same arguments as git push. It will pull the commits down and then try to reconcile those changes with any that you’ve made since the last time your local repo was in the same state as the remote repo.

Conclusion/Links

I feel like this has gotten pretty long and I don’t want to put too much information all at once. That should be enough to get you started and, really, just try it out for a while and get comfortable with the basics. Don’t be afraid, if you get something out of whack and realize you’ve done something wrong, to kill your .git directory (which will delete the local repo) and start again from the top. I’ve intentionally left a lot of stuff out (like push/pull and branches and multiple remote repos can get kind of hairy), so here’s some documentation, blog posts and articles that I’ve found helpful. These are in no particular order and some are more advanced than others, so just start clicking and see what you like:

• Github’s Guides page
• The Git Homepage
• Git Magic (a huge work)
• Using Git Without Feeling Stupid part 1 and part 2
• Awesome StackOverflow page
• $ cheat git
• Understanding Git Conceptually
• Git for Computer Scientists (highly technical and abstract)
• Why Git is Better Than X (Not only evangelical, but some helpful stuff)
• Github’s Learn page

If you want to ask me about git or whatever, feel free to email me or leave something in the comments. Also, if you spot a mistake or something here doesn’t make sense, please let me know. Hope this is helpful to someone.

I’ve mentioned @carl_youngblood here before. Someone once was trying to buy him something with his name on it. I think it was a key chain. You know the kind, right? However, then didn’t have “Carl” only “Carlos”. So we joked that, one day, he needs to write an operating system and name it CarlOS. Aren’t we funny? I know. I’m sorry. Anyway, the other day, we actually got into some OS discussion that I thought had some interesting enough ideas to post here.

So how many computers do you own and use? I’ve got a desktop at home, a laptop and a machine at work. It’s sort of a bummer to have different stuff or different versions of stuff, or stuff with different preferences on different computers. At least, for me it can really jack up my work flow. Especially if there is some application I use a lot with non-default preferences. Man, that bugs me! Remembering it all, bleh.

One thing Carl’s fantasized about is having a computing environment the same everywhere you go. That’s sort of a mainframe or dumb-workstation idea, which is not new at all. However, what if your whole computer were version controlled? You could branch it (so you don’t have your work apps at home, etc.) and merge changes from one branch to another, if you wanted. You could check out a different branch on one machine and it would feel like you were on another.

Clearly an OS would have to be built from the ground up for this idea. You’d also have to have some kind of provision about storing the non-checked out branches locally. Also cloning the repo would be a hassle at current average (even high speed) connection speeds. But how cool would it be to install, say, Textmate at work and get all your settings right, etc. and then go home and merge that change in (You could merge it from work, I guess and then just pull from home. Whatever.)? You could get diff data (hard to implement, but with metadat not impossible):

1
2
3
4
5

$os diff gaming HEAD
+ Steam
+ Half-Life 2
+ X-Fire
-Textmate

Or whatever. You get the idea. Reverting would making backing up and creating, uh… what does Windows call them? Recovery Points? It would make all that easy and moot. Clearly Linus Torvalds needs to be in on this “project”; he has the experience in both OS design and version controlling that would be invaluable. Not that, you know, Carl or I are actually considering doing anything with this idea. It’s an interesting thought experiment, though.

I use Twitterfox to read and create tweets most of the time. I follow enough people that, when I open my browser for the first time for the day, more than 20 tweets have accumulated and, really, I don’t want to go back and read all 60-odd or whatever that have accumulated overnight. Twenty, I should note, is just what Twitterfox picks up when it first turns on.

Occasionally, I’ll come in and see the last few tweets in a conversation between two people I’m following (I only see @replies by others who are to people I’m also following). If it seems interesting enough, I’ll go back and page through to see what they were talking about, reading in reverse order. Sort of like reading a chat log written by the guys that made Memento. It’s not horrible, but neither is it ideal.

So I had an idea about it and I’ve started work. Twitter tracks what tweet (technically called a “Twitter status”, apparently) any given tweet was a reply to. And, I figured, it would be relatively simple to, given a Twitter status ID, recursively follow the reply chain back and get the whole conversation. Turns out, I was right.

A proof of concept:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

require 'rubygems'
require 'twitter'
 
class Reply
  attr_accessor :text, :author, :in_reply_to, :time, :atreply
  
  def initialize status_id
    status = Twitter::Client.new.status :get, status_id
    
    self.text = status.text
    self.author = if status.user.name then status.user.name else status.user.screen_name end
    self.time = status.created_at
    self.in_reply_to = status.in_reply_to_status_id
    self.atreply = Reply.new self.in_reply_to unless self.in_reply_to.nil?
  end
  
  def each_reply &block
    reply_chain.each do |reply|
      yield reply
    end
  end
  
  def to_s
    self.author + ' - ' + self.time.to_s + "\n" + self.text
  end
  
  protected
  
  def reply_chain
    return [self] unless self.atreply
    
    self.atreply.reply_chain << self
  end
end

This has a dependency on Joshuamiller’s version of twitter4r. My medium-term plan is to make a one-trick-website that will take an ID or twitter URL and give you the replies all pretty-like. Maybe make a bookmarklet for convenience’s sake. I plan on using Rails, even though that’s overkill because I figure it’ll be a good learning experience on that front. Find it on Github.