Real Hope

In February of 2007, I, my one year old daughter, and my wife who was pregnant with our second child drove down to Springfield, IL. We believed that our young Senator would right the wrongs that had been committed by his predecessor, and set our country back on a proper course. 

We wanted to witness history as he announced his candidacy for the Presidency of the United States. 

That's me, wearing his shirt, when my wife gave birth to the boy that was in her body when he announced in February, 2007.

You see, I'm not some Obama hater.

Now, though, I am ashamed for my support of President Obama. I am stunned by the breadth and scope to which our constitution has been violated under his watch.

And yet we still have hope because of Edward Snowden.  

Edward Snowden is a courageous patriot, who will no doubt go down in our nation's history as one of the most important defenders of freedom we have known.

I have lost faith in congress, the President, and those who claim to protect us. But I have hope because despite the sure harm that will come to him, Edward Snowden stood up and defended the ideals upon which our nation was founded.

We owe him a debt we will likely never be able to repay. 

This work is licensed under a Creative Commons Attribution 3.0 Unported License. It may be altered and used for any purpose including commercial.

Full size JPG file here, and PSD File here.

How We Work: A Badass Git Workflow

About six months ago, our team was using Beanstalk to manage all of our Git repositories. We can't say enough good things about Beanstalk (they offer Subversion and Mecurial, too) and what they provided us, but we finally made the switch to GitHub.

GitHub just had more features that would greatly improve our day to day workflow and let's face it, most developers have a GitHub account.

Like I said, GitHub gave us a bunch of great new features that Beanstalk just wasn't providing us. Not because Beanstalk is bad or anything, that's just the truth.++You can have a kickass Git workflow without GitHub, but we feel like GitHub adds a great deal of improvement to it. Another great part of our workflow is how we use Basecamp, and you'll see that below.

Inspired by the GitHub team themselves, on a day to day basis, this is what we do:

1. Pick a feature, bugfix, or tweak from Basecamp.+Our features are organized in Basecamp todo lists. These lists often translate into a pull request, focused on one particular feature (I'll talk more about pull requests later)

2. Cut a branch from master with a name similar to the feature.+This is important. Don't call your branch "feature-branch", "new-feature", or "derek-fixes". If you were adding a tweak which made the logo glow when the mouse hovered on it, call your branch something like this: "logo-hover-effect". You get the point.

3. Do your work on your branch. You own this branch. You can push as many times as you want. We use Semaphore to run our specs each time a commit is pushed to GitHub. It's helpful to know when you break something, so push and forget about running the specs on your local machine. Use the compute power of your continuous integ srver.

4. Open a pull request (at any time). Pull requests are cheap. Open one. It gives you a diff between master and your branch. You can discuss your code with other people on your team. You'll have a record of when the tests broke and when they passed. If you decide your code sucks, you can close the pull request. No harm done. If your code gets merged to master, you have a great record of it and can reference the pull request later.

5. Review the pull request. We don't have any formal code reviews (in the form of a big meeting). It's every developer's job to review code and make sure it's at least neat and appears to be functional. We also check to see if there are no tests or something looks out of whack. Two pairs of eyes are ter than o

That's our typical workflow when we work on Tula Software, our own product.

Our workflow on our client projects varies a bit, since we have a small approval stage (instead of pulling into master, we pull into a staging branch).

This workflow seems to be one that could be implemented quickly, and if you've worked on an open source project before, this probably seems familiar to you (with slight variations, of course

If you deploy everyday, this should make perfect sense to you. You want some friction (code reviews), but not too much friction (defined releases) in your day to day.

If you follow something similar, let us know. We'd love to hear from you.

HAML vs ERB: Keep your emotions out of it

There are tradeoffs in everything we do in life. Everything is relative to your situation. There are no absolutes.

Let's revisit a conversation our team recently had in HipChat. It was the ultimate debate of pros vs cons, and at one point it turned a little bit emotional.

HAML vs ERB

There are already a bunch of debates documented on the web. Just a simple Google search gives you enough to make your head spin: HAML vs ERB vs SLIM in terms of render speed, Haml vs erb, Fashion Runway: ERb vs. Haml, and so on. You get the point.

But, what about the arguments we were making?

We shouldn't be afraid of it.

I sensed a little fear from our team, so I had to say that. Our team isn't exclusively developers. Most of us know our way around HTML & CSS, and since we use ERB most of the time, everyone at least knows what it looks like. But, like anything else, we shouldn't avoid something because we're afraid of it. It's usually good to step out of your comfort zone.

We have an existing code base.

We have an application where we used ERB exclusively. Why should we try to make the switch to HAML? To me, it's a waste of time and a poor decision that wouldn't provide many benefits. While our code would suddenly be cleaner and a little more beautiful in HAML, we'd waste precious hours converting ERB to HAML. We have so many other important things to do, why waste that time on something so pointless in this case?

I can write ugly code in any language.

One of the common arguments for HAML is that it's clean and beautiful. While I agree that a language that depends on whitespace forces you to indent and keep things organized, I guarantee that I can write ugly code in HAML as well. Look what I found: Haml Sucks for Content

That doesn't look pretty and organized to me. If you use a tool like HAML in the wrong way, you'll end up something that looks terrible. Like Chris says in his post about why Haml Sucks for Content:

Haml’s use of CSS syntax for IDs and class names should make it very clear: The markup you write in Haml is intended to be styled by your stylesheets. Conversely, content does not usually have specific styling - it is styled by tags.

It's important to realize that your situation is completely different than everyone else out there. If you're starting a brand new application and you plan on experimenting with some new tools, you can afford to use HAML (and it's usually a good idea to learn something new). But what if you need to stand up an application in a week? Use what you know.

There are plenty of reasons to not use HAML. Maybe, you don't have time to learn it. Maybe, you have some junior developers on your team that only know ERB. Maybe, you have a personal preference against HAML.

It's all relative. You don't need to use HAML. ERB can do all the same things. They are just different tools for the same job.

Software and diminishing returns

It's tempting to believe that everything matters equally. That every detail is as important as the other. It's tempting because when everything matters equally, the difficult labor of making trade-offs doesn't need to happen.

But as with many things that are difficult, the rewards for getting good at making trade-offs, and making the right ones, can be huge.

Making trade-offs is particularly difficult though because the return you get for expending time/energy/resources on something is almost always greater than zero. Very rarely will the answer to the question: "If I spend ___ hours/dollars working on _____, can I make it better?" be a 'no' answer.

But that is the wrong question to ask.

The right question to ask is: "Given the current state of my product and the number of customers I have, is this the best place to spend my time/money?"

Not all returns are equal.

So the challenge is to make the right tradeoffs so that you maximize the return on the energy/time/money you spend on something. And the right trade-off will be different depending on the state of your own product.

What I've realized is that most decisions and disagreements aren't ones of details, timing, design, features, functionality or anything else.

They're all about trade-offs.

Fighting Over Guns

'I have come to believe that the debate around gun control brings out pretty much the worst of everyone in this country.

There are of course crazy people on both sides of the argument, though let's face it, people in support of gun rights sure seem to be a lot crazier. The NRA thinks we need more guns in schools, and for some reason, some people have figured out how to make the gun debate a religious issue.

And on the flip side, we liberals who are usually talking about the importance of science and data when it comes to things like climate change, poverty, education and a host of other issues apparently think data suddenly doesn't matter when it comes to the issue of gun control.

No one has said it better than the authors of Freakonomics.

When hazard is high and outrage is low, people under react. And when hazard is low and outrage is high, they overreact.

Every death is sad and tragic, but especially when it's at the hands of a violent criminal and especially when the victims are children.

But the tone regarding the debate about guns in our country has to change on both sides if we're actually going to accomplish anything. If you ask a gun rights person why anyone needs to shoot 50 rounds in a second they scream at you for hating the constitution.  But I've also dared to ask my liberal friends about certain realities about the data of gun violence (like the fact that there are more victims from drunk driving than there are from gun violence yet we have about the same number of cars and guns per capita) and am spoken back to as if I'm a crazy far right winger because maybe I might disagree about one policy.

This is a shame because the data allows us to see that the violence we experience with guns in this country are a symptom of larger issues.

Maybe if we'd take a moment to stop and look at the data, we'd see that we could probably save more lives by legalizing drugs than we could by taking away guns.

In fact, any attempt to have a discussion about gun control in this country without discussing the war on drugs is completely pointless.

Diane Feinstein is set to introduce legislation that will supposedly be a victory for gun control advocates. Oh and also, she says:

We believe we have (perfected it). We exempt over 900 specific weapons that will not fall under the bill..

Because we'll all feel safer if a lunatic is only able to choose from 900 weapons?

And so here's really the only thing we know we can count on to come out of the debate over gun control.

First, nothing meaningful will actually happen in Washington. After all, these are the same politicians who can't figure out how to get our basic revenue and expense needs in order.

And second, politicians and pundits on both sides of the debate will eventually forget about the children of Newtown and keep fighting as if they're little children arguing over toys, trying to score their political points.

Except we aren't children fighting over toys.

We're adults fighting over guns.