Hacking Github

This weekend, a Github user named Egor Homakov hacked Github in such a way that allowed him to commit directly to the Rails core project. Since Homakov is not a Rails team member, this is a really big deal.

Since this happened, there’s been a lot of talk about the Rails core being fundamentally insecure. In fact, Homakov has been harping on this for at least 1000 years. A few days ago he filed an issue about a mass assignment vulnerability in the Rails core, and later he illustrated this vulnerability by filing an issue report from the future. He was illustrating that you can inject attributes into a Rails model with an HTTP request.

So, when no-one took him seriously, he took the next step. He created HTTP PUT requests adding his SSH key to a Rails core user id, then pushed a commit directly to Rails core.

How to Hack Rails

It turns out that Rails apps, by default, are easy to hack. Peter Nixey wrote a very detailed post about how Homakov hacked Github and the one line of code that could have prevented it, so if you want the full details, read there. The summary is much shorter.

Let’s create a simple User model which has two attributes, name and role. By default, every attribute of every model can be modified by using update_attributes. We all know this, and we’ve known it for a while. What it means is that any User, even if they don’t have permission, can update their own role. Imagine if I log in to our example app and submit a PUT request to the UsersController with the package {'params': {'id': 23, 'role': 'superadmin'} }. By default, the app will accept this and update the user with the new role.

This is exactly what Homakov did. He sent an HTTP request to Github and used update_attributes to change the Github database. All of this could, he argued, be prevented by adding attr_accessor to the User model.

Rails: Convention over Configuration Security

Now, the philosophical point I want to make about this is that the Rails core team seems to be ignoring their own mantra. All of us know that Rails adheres strongly to the Convention over Configuration design pattern. It’s a pattern that Rails users are taught from day one. In fact, it’s embedded in the framework’s name.¹

One of the outcomes of Convention over Configuration is that sensible defaults should be, well, sensible. The Rails core team feel strongly that attr_accessor should not be a default² and that security is the responsibility of the app developer. I agree that security is our responsibility, but disagree that the dominant Rails design-pattern-come-mantra supports this.

It’s almost as if no-one wants to say “Yeah, we should really take care of this.” Everyone is saying “You know, you should really take care of this.”

Stop the world! We’ve found a SQL injection

There’s a term that makes all software developers give pause: “SQL Injection.” It’s a phrase that keeps us lying awake at night, and gives us nightmares when we finally fall asleep. The idea that someone, using nothing more than a web browser, can change our database willy nilly. It’s a terrifying thought.

I can’t help but take an initial read of all the hubbub and think that we’re not giving it the importance that it’s due. Everyone sees a headline saying Rails has a ‘mass assignment vulnerability’ and says to themselves ‘I should probably look into that at some point.’ It’s too vague, to uncertain. To unemotional.³

I have to assume that everyone would be treating this differently if we called it what it is. Imagine your thoughts (and actions) if you read a different headline, something like “Rails apps prone to SQL injection by default”

Don’t you think you’d get something done? You should, because that’s what we’re talking about. This is a path to SQL injection, full stop.

Who owns this issue

I love Ruby on Rails. Like Python, Scala, Node.js, and a host of other technologies that we have at our disposal, Ruby’s web framework makes being a developer both powerful and fun. There’s so much we can do– and so much we can do very quickly. But there’s a cost to pay. Convention over Configuration is a good thing, but we can’t expect people to learn fast, develop fast– create fast– if we don’t respect the logical outcome of that philosophy.

That outcome is this: We, Rails developers, understand that we are responsible for our security; however, we also believe in you, the Rails core team. We trust you. We believe it when you tell us to follow “Convention over Configuration,” and so we naturally believe that the defaults you give us will be a safe, or at least not horribly, dangerously wrong. We, all of us– developers and Rails core team both– can’t have it both ways. We are telling ourselves to follow Convention over Configuration, but we’re also telling ourselves that SQL Injection is a viable convention, thus, that we have security as a configuration.

Now, personally, I don’t believe that attr_accessor belongs in the model– or at least that security from view-based actions belongs in the model. Rails is an MVC framework, and therefore I don’t like forcing myself to define my model based on actions in the view. I don’t want my view owning control of my model that way. I think the controller should manage these permissions and there are others who feel the same. In fact Yehuda Katz argues this as well.

Still, the overall question remains: How can we reconcile the mantra of Convention over Configuration if we support the standard of dangerous insecurity by convention?

1. Look, just stay on these rails and you’ll move fast. We’re not responsible for what happens if you go over there
2. Incidentally, I don’t either, but you can set this as the default by using ActiveRecord::Base.send(:attr_accessible, nil), but this causes all sorts of problems
3. In fact, to be honest, that’s how I was reading it.

Like tomato sandwiches, Celtic music, beer, and programming- Github is something that, try as I might, I just can’t make myself sick of.¹

Recently, I took the Git survey, and it contained an interesting question along the lines of “What do you use Git for?” The answers were things like “configuration files” and “large binary files.”

I use Git and Github for a lot- configuration files are one use (I love the “raw” path), but it was only a small percentage of what that list suggested, so I started wondering how else I could use it.

Today, I thought of an interesting way: Github as a CDN.²

If you know what a Content Delivery Network (CDN) is, you don’t want me to explain. If you don’t, then it’s good enough to say that it’s a way to server up pictures or other content from another server. It’s often used to, say, serve the main portion of an html page from a webserver, but serve the images, CSS files, etc. from something like Amazon to speed things up.

I recently finished work on The Great John Metta Branding Project and, like with so many projects, stored the images in Dropbox. Then, deciding I might want to version them, I stored them in Github. Then, just as I was starting to begin the rather annoying process of copying all these logos and textmarks to my various sites throughout the web and updating all the image tags, I thought to myself “Hey, if these are already in Github, and I can access the raw files, why don’t I just use that as the image source?” But I don’t want to have to remember the URL each time. What if it was somewhat dynamically generated?

A RESTful CDN system for a logo

This is exactly why I made johnmetta.com a Rails project, to play with stuff like this and then have a place to have it be live if I wanted to use it.

I’ve got a lot of different styles that my logo can take. Stacked, Icon only, textmark only, icon one-color grey, textmark one-color blue, etc. Ideally, I wouldn’t have to remember the path to each, I could type something like http://johnmetta.com/brand/icon/blue/transparent/logo.png³ and have the app return the image that is strictly the icon (no words) with blue coloring and transparency inside the logo (instead of the normal white).

Since none of these actual images is created on the fly, I created a sensible directory structure and embedded all the files in this structure, naming them all logo.png and putting the default logo in the top level. So the above image would be {base}/full/logo.png, while a version with the icon on top would be {base}/full/stacked/logo.png. A one-color version of only the icon might be {base}/icon/blue/logo.png

So I created a Brander class which would turn arguments into an appropriate path and added some new routes such as “brand/:type/:color/logo.png” and created a call to brander in the controller’s “brand” action that ends with a redirect to the returned URL.

It’s all really simple, but it allows me to have a url like http://johnmetta.com/brand/icon/logo.png and supply my logo, and http://johnmetta.com/brand/stacked/blue/logo.png for a one-color blue stacked logo. Then, if I update the colors (move the files, whatever) they update automatically. At a maximum, I just check in the changes and make minimal changes to the routes- but don’t have to copy files to servers.

A Good Illustration

Right now, the Brander class is pretty dumb- little more than a way to translate a route into the correct external URL. It was built up not as an illustration of how to accomplish “Github as a CDN,” but merely as a toy to test one way that it might be done on a small scale. It might be better done as a class where instance attributes make more sense, and I’ll clean it up a bit, but not much more than that.

Also, it’s cool to know that stuff like this can be set up so easily, and for my uses- where bandwith might reach a whopping few requests per day, it’s useful while being low impact. But for a real CDN, you’d still want to use something like AWS- or at least talk to the Github guys before swamping their webservers.

1. I’ve tried for the past two summers to make myself sick of eating tomato sandwiches. I just can’t.
2. The title is with Rails because that’s what I used, but it would take 2.4 minutes to make this a “With Django” or “With Lift” example
3. Actually having “logo.png” is unnecessary, however, sometimes the software using the URL will depend on that, so I just made it convention so that I don’t have to think about when sometimes is.

Smart and Gets Things Done

As best I can tell, this trend really took off– even if it didn’t start– with Joel Spolsky’s blog article titled “The Guerrilla Guide to Interviewing.” In that article, he stated that there was one primary requirement for working at Fog Creek Software: “Smart, and gets things done.”

His basic argument, with which I tend to agree, is that it doesn’t really matter what your past qualifications are as much as it matters that you can do to things: 1) Learn shit, and 2) Actually do shit.

His point? If you can’t learn, you’ll be stuck trying to write software in Visual Basic and someone will eventually shove you off of a roof out of frustration. Furthermore, if you don’t actually DO anything, but rather just talk about it, or think about it, or tell others why you could do it better– then you won’t even write software in Visual Basic. You won’t write any software at all, and someone will eventually shove you off of a roof out of frustration.

But if you can learn, it doesn’t matter what you come into the job knowing, because that’s merely a starting point. It’s how your knowledge and skills translate over time that’s important. You can learn <insert whatever you need to do your job here> quickly. I say quickly because you are a DOER, and doers always learn new stuff, so they can DO more stuff.

The most important thing here: The job will probably change, and when it changes, it’s the people who can LEARN, ADAPT and DO that will help the company succeed. The person who came to the job with one incredible skill but can’t learn probably has that one incredible skill in a stupid technology like Visual Basic, and someone will eventually shove–

well, you get the idea.

The problem with catchy words

So, herein lies a bit of the problem. Joel also talks about hiring the best people, treating them like “rockstars,” etc. Again, I think he has a point, but that there are a great deal of people who are stupidly picking up the hot new terms like “rockstar” and “ninja” and using the words, basically, without using their brains.

I see them a lot. Those posting that sound all hip and cool: “Are you a Python Guru?” or “We’re looking for a Ruby Rockstar for-” or “We want a PHP ninja to-” Everytime I see one of them I want to slap them in the head with the nearest O’Reilly book and then vomit.

This type of job posting proves one thing to the very people that you want hire: That they don’t want to work for you.

Why?

Because the very people you want to hire are the ones who describe themselves as “hard working” or “with a lot to learn” or even “not as good as many, but loyal, friendly and likes to learn new things.”

Do you really want to hire a ninja?

What’s a ninja?

It’s such a stupid, overused buzzword! Do you even know what it means? It’s either an assassin or a stupid 14 year old jumping out of a dumpster brandishing a medieval sword.

You don’t want either of those things!

Ninja: It's a word that's THIS overused

Yes, there’s some evidence that a well trained ninja was, if absolutely nothing else, a competent assassin (though the Samurai made fun of them). A ninja is basically a person who does one single thing really well, they kill people, and the rest of life- including the whole “getting along with people” part- they could give a rat’s ass about.

Human interaction to a ninja is “kill them!”

Conflict resolution to a ninja: “Kill them!”

For those who miss my subtly: A ninja programmer’s response to pretty much anything is going to be this: “Do it my way and no-one gets stabbed in the face with my medieval sword.”¹

Think about it. Do you really want to hire someone who does one single thing really well? To the exclusion of things like “showering” and, say “talking to other human beings?”

Ninjas are Zombies!

Here’s a neat trick: think of another stupid, overused buzzword: Zombie. What if I told you that ninjas are just zombies with black bags over their heads?

They do one thing really well: kill people (eating their brains- mostly the brains of your team if you hire them), and they could give a rat’s ass about things like “human interaction” and “conflict resolution.” What’s their solution to everything? “Kill them! (and, since we’re here, we could maybe snack on their brains too…)”

Ninjas are zombies! They’re mindless idiots going around trying to do one thing.

That’s it.

When you say “I want a ninja” you’re saying “you can be a complete asshole, refuse to learn anything new, refuse to respond to other human needs or the needs of the business, and also be a social trainwreck. Oh, and you don’t really need to know, or care, about 90% of programming or computer work, but if you can sit in your hole and <do that one thing well> and not talk to anyone, you’re the guy for us!”

You want a ninja-zombie as your lead developer, don’t you? Admit it.

Rockstars: They go to 11

Alright, I think you get my point, but let me touch upon rockstars for a moment. Here’s another place where I think Joel’s point was completely missed by a lot of people. Joel says “hire the best people you can find and treat them like rockstars” and in pure politician-like “I don’t really want to put any actual cognitive thought into this process, so I’ll just pull a buzzword”-style, job announcements start popping up for undefinable qualities such as “Ruby Rockstar.”

You want these guys in your company?

The mistake here is that all the corporate bozos think “Hey, ‘Rockstar’ is the current buzzword, so I’ll use that too!” without stopping to think about one thing: “Rockstars don’t usually make the best employee material.”

Think of the words “punctual” and “hardworking.” Okay, now, keep those words in your head, and think of the word “rockstar.”

Yeah, your neck hurts doesn’t it?

See what happens when you take things out of context? Joel’s statement was “treat them like rockstars.” In otherwords, treat them like they mean something, like they matter, like the company depends on their happiness… so they will be happy… and do really good work… and make you more money.

The line was emphatically NOT “Make them into rockstars.”

Seriously! Think about your average caricature of a rockstar.² They show up late, drunk, stoned, with a 16 year old’s bra stuck to their belt, and give you a loud, shitty performance of something they don’t feel like playing before hopping back into the bus for more sex, booze, and food.

Okay people, repeat this after me:

“I don’t want to hire a Rockstar!”

A rockstar is probably worse than a ninja, because at least a ninja- or a zombie, for that matter- can do one freakin’ thing well. The only thing the rockstar can do is pray to god that the sound team can mix together the shit they call a studio performance, and that the stage crew can hit blow the fireworks early to cover the guitarist tripping and falling because they’re too freakin stoned to remember that there’s a drumset behind them.

They think of themselves as the best thing that’s ever happened to you, and if you tell them otherwise, they’ll freak out.

Rockstars look good. Full stop.

You know who the rockstar is? It’s the young programmer I met at the Open Source Bridge conference who immediately berated me for using a different database strategy than him– without ever stopping to listen to the problem I was solving, to hear about my application’s design, or to learn why I would choose one over the other.

I was wrong, they were right, and I should really just stop being stupid and do it their way.

Yeah, that’s who I want on my team.

Fucking rockstars.

Are you an incompetent programmer with an overblown sense of self-worth?

Here’s the part that bugs me the most: The people posting these job announcements are actively selecting for people with a tendency to overstate their abilities while understating their faults.

It’s called the Dunning-Kruger effect and it’s well documented in both the scientific literature andpopular journalism.

The basic Gist is this: Incompetent people tend to overstate their abilities and think they are amazing, while highly competent people tend to downplay their skills and think that they are less than amazing.

And you know it’s true.

Go pick the first male rockstar-ninja-zombie programmer you can find and I’ll pick the first quiet, understated female programmer I can find. Then we’ll see which one can actually shut the hell up about how great they are and get something done.

The best people for the job are not the ones who are going to feel comfortable applying for the “Amazing Rockstar!!1!” position for the very reason that they are the ones that you want to hire: because they are too busy being amazed at all the stuff they don’t know to be rockstars who tell you everything that they do know.

They don’t think they know everything. In fact, with everything there is out there, they realize that they know basically nothing. Most importantly: They know that there’s a lot to learn, and they are trying to learn it.

The rockstars? The ninjas? They already know it, and they’ll tell you.

In fact, They’re more than happy to tell you how much they know.

Every single time you interact with them.

Folk Developer: Will learn and be nice for food

I don’t apply to any of these positions because, while there are a lot of things that I am and can do, there are certain things that I am emphatically not. A partial list of the things that I’m not is:

• Rockstar
• Ninja
• Zombie
• Best person in the world at <fill in whatever you want here>

Me, I’m not any of that. And that makes me think, from the majority of jobs I see lately, that I won’t be good enough to make the cut. And let’s face it, if they’re advertising for a rockstar, then I am probably not, because I do a lot of things competently, not one thing better than everyone else including you.

See here’s the thing: I’ve been programming for 25+ years, I’m competent in at least 10 different languages, and really good in at least 4.³ I’ve built everything from robotic control systems to mathematical models, from spatial applications to social web applications. I’ve taught programming, and am about to do so again, and I do other things like start a Ruby users group.

By many-if-not-all accounts, I’d be one hell of a developer to have on a team; yet many teams are seeking rockstars.

I am not a rockstar.

I’m not the guy on stage with lights and explosions and a screaming electric guitar.

I’m the guy who goes to a party and sits on the couch singing a song on a guitar. A really fun song, with really good guitar work, but not anything that needs lights and explosions. I may also pick up a banjo or back someone up on a number of other instruments, but mostly I just stay at the party and hang out with people.

No lights. No explosions.

I’m a folk developer.

I’m a seeker, I’m a learner. I’m a hard worker who will spend his free time coming up to speed on a technology for curiosity as well as success. I’m loyal, I’m friendly, I’ve got a sense of humor and would much rather laugh at myself than at anyone else. I spend my off time programming, like lots of people who love programming, but I also spend my off time playing the Irish flute and banjo, cycling, brewing cider and mead, working in community theater, and lots of other social pursuits.

Despite this (or, rather, because of it) I see myself as little more than “a decent programmer who’s probably not as good as most, but might be better than some.” In fact, I don’t have enough fingers to count the number of jobs I’ve actually turned down because I thought that I was probably not good enough– only to find that someone else was hired whom I actually know that I can outperform.

I am not going to apply for a job as a Python ninja or a Ruby Rockstar, because I’m not a ninja or a rockstar. I’m a person who knows a heck of a lot less about Ruby than many other Ruby programmers.

I’m a person with a lot to learn.

Exactly zero of my qualities describe a rockstar.

Are you an incompetent company with an overblown sense of self-worth?

And I know that’s also true of many of my developer friends and colleagues. Companies select for people who are not them.

Here’s the clincher. Most of those companies who are hiring ninjas and rockstars are probably doing so because they see themselves as ninja and rockstar companies.

They are the companies that say things like “do you want to work in our cool-ass company where everything is better than any other company you’ve ever worked for, where we have foosball all day and are all awesome and badass about everything we do?”

Sound familiar? I’ll bet it does.

It sounds like a rockstar of a company.

1. No, don’t ask your ninja programmer why they have a European weapon, you’ll get stabbed in the face.
2. which is all we’re really talking about in either case- neither Joel or you are talking about Dar Williams, here.
3. 5 if we count Ruby, which I’m learning more about every day

It’s a small thing, more of an annoyance than a real problem. Something like my tendency to forget “end” after blocks (a Python holdover) and to assume that zero equals false (a sort of “everything else” holdover).

It boils down to this:

belongs_to is singular,  you stupid dipshit! Stop being a mindless screwhead and remember that for a change, John!

Honestly, it only takes me a second once I get the ever familiar error, but it’s just better to not get the error at all, right? Efficiency and correctness.

If anyone reads this and runs into me later, I wouldn’t mind if you repeat that statement to me.

More reminders couldn’t hurt.

Mostly, when I code, I focus on logic: algorithms, object models and other back-end stuff. All the stuff that’s hard and doesn’t give any sort of gratification to the front-end developers or users because, well, it’s not on the front-end. The stuff I like to code are the elegant binary-keyed dictionary structures that route water in multiple simultaneous directions in a hydrologic model. It’s the stuff no-one sees.

Consequently, because I hate the design side,¹ my apps generally look extremely rough, almost unusable, but damn do they do some cool shit. If it’s something that needs a front-end, I either do that last, or get the back-end working and then ship it out.

Recently, I took on a project for a fellow who’d been working for months with a developer. I pretty much thought I was going to “parachute in” and take this developer’s code and bring it to launch. Well, it turned out that the previous developer didn’t actually write any code. None. Zip. Instead, what they did was create long “what we should do” lists and emails.

And, they got a design.

So, the “code” I was given was not code at all. Rather, it was a really nice design from a third-party designer. Thus, rather than build the back-end to the site, I had a design that I just had to plug into. I decided to break up that design into views and plug them into my new Rails app directory before I started build models.

This, as it turns out, was a very serious mistake.

Because it seems that I have a certain workflow, and that workflow is to develop an object model based on the logic that is needed, and that logic is based on the function that the application is to perform. That’s why I work so well on the backend without a design. The bare scaffolding allows me to think about the object and not the layout.

In this case, I made the mistake of applying this design before creating even my first model. That was bad. Very bad.

The thing is, designs have all kinds of embedded assumptions. Usually, when the design is based on the logic, the assumption is “it has to provide an interface for this logic.” However, when the design is created in absence of the logic, then the assumption is something more along the lines of “well, hell, I guess it might need one of these.”

I didn’t ever realize it until very recently, but I now know that what I was doing was some weird, disconnected hybrid of design reasoning. It was something between “This is the most robust-yet-simple object model that I can start with and build from” and “well, the design says it has an X button, so I guess I’d better build an X model.”

Yeah, I know it’s stupid. The thing was, it all happened so subtly that I didn’t even realize it! I guess that, in other projects, by time the design is applied, the object model is solidified. Thus, if there’s a button, you can be damn sure it needs to be hooked up. In this case, there are buttons that pretty much everyone sees and thinks “Yeah, I don’t know why that’s there.”

So, today I was trying to work around 7 polymorphic models and at the same time I was thinking “this would be easier if I didn’t have to scroll past all the glitzy site images to see this whenever I look at it.”

That was when it hit me. I don’t. And more than that, the 7 polymorphic models I have are really only there because there’s this navigation bar, immediately above the glitzy site images, that says they should be.

So, believe it or not, I did the crazy thing. New repository, new Rails scaffold. Start over.

So now, it’s 4th down in the 4th quarter, there’s like 5 minutes to play until this prototype is due, and I’m dropping back to punt with a new Rails app that doesn’t have a design applied.

And I’m hopeful, because it’s actually a fairly simple app, just with a complicated design. But as a simple app, I know it’ll be simple for me to whip out, now that I have a clean understanding of the object model, and no design cluttering my thoughts.

Damn, it’s late in the game to come to this play, but at least I know better now.

1. I don’t actually hate it. I just take 7 hours playing around with 2 px changes in CSS files and then finally give up

“Sure, Ruby’s fun, but it’s not really useful. It’s a cute scripting language, but it can’t scale.”

Until recently, this was an opinion that I agreed with. Hell, it was actually something I told other people.

One day, I realized why I agreed with it.

Now it’s just an opinion that makes me want to smack someone.

Geeks are Dumb

I don’t really know where the whole “Ruby can’t scale” argument comes from, but I have my suspicions.

The main suspicion is that, as a general rule, programmers are geeks, and geeks spend a great deal of their childhood development getting beaten up by non-geeks.¹ Thus, we child-geeks tended to focus our efforts on something we knew that we did better than the wrestlers and football players. That something was generally not wrestling or football. It was academics.

We geeks are smart.

Think about the football player who spends his entire school day like a stupid monkey, proving that he’s tougher and plays football better than the other stupid football playing monkeys.

Geeks aren’t stupid monkeys. Geeks have a brain.

And we use that brain to spend our entire school day like a stupid monkey, proving that we’re smarter and use our brain better than the other stupid brain-using monkeys.

Oop. There it is.

Truth Hurts

Oh stop being dramatic! You know it’s true! You’re just too busy being a stupid brain-using monkey to want to admit it!

You can’t name a single geek-dominated situation that wasn’t essentially a “I’ll take your obsure science fiction reference and raise you an obscure Dungeons and Dragons reference” chest-pounding war of the stupid monkey-brained geeks.

No, you can’t. Stop trying.

The point is, it’s all about being the übergeek. And the competition of übergeek is a constant struggle of

“No, I was the smartest person in my class! So if you say something smart, I have to say something smarter!”

And so when someone tells me that they are programming in some hot, trendy new language, I can’t say something like

“Oh, it’s great that you’re moving forward and trying something new… I’ve been feeling a bit old lately, kind of in a rut, and was somewhat scared to learn that shiny new language.”

Yeah, right.

Imagine a geek actually admitting weakness! HA!

No, when I hear someone say they’re programming in some hot, trendy new language, I say:

“But hot and trendy are stupid, like that hot girl who wouldn’t date me in high school. And your new language is stupid too! And I think I overheard someone say that it has a defect, and so even though I don’t know anything about your new language, I’m going to spout out this defect to prove that I’m better than you for not using it. There! I win!”

Fun fact: Geeks, as a general rule, are freakin’ terrified of anything that carries the descriptor “trendy,” because if we knew what that word meant, we wouldn’t be geeks, we’d be popular.

Datapoints

This may seem harsh, but stop being all “must not admit weakness”-y and use that monkey brain to actually think about it.

Here’s a nice datapoint: Twitter.

(I already hear you, by the way)

“But Twitter was down all the time! Because Ruby can’t scale! That’s why they moved to Scala!”

Was it? Was it really? Is that smart monkey brain actually working? Saying Twitter was down all the time is like saying that the United States Postal Service is not a good choice to carry mail because it’s inefficient and looses a lot of mail.

But, but, they lost a letter of mine once!

Yeah, sure. And they deliver on the order of a billion freakin letters every day! Did your super smart übergeek brain never actually grok percentages?

Do you have any idea what kind of traffic Twitter had when they moved to Scala? Saying Ruby can’t scale because Twitter had a freakin’ failwhale every once in a while is like saying that the space shuttle’s not a real spacecraft because it only goes into near space.

It goes into freakin space… and you don’t have jack shit that’s ever going to be any better.

Why are you even talking?

Coffee Shop Critics

The truth of the matter is that the people saying that Ruby can’t scale are not the developers from Twitter, or from 37 Signals, or from Github. They are not the developers from the companies that have built ridiculously freakin’ big web applications in Ruby.

No, they are the developers who are sitting in coffee shops– secure in the knowledge that if someone just knew how smart they were, they wouldn’t have to sit in that coffee shop and talk about their amazing idea. If someone only knew their greatness, they could be a contender!

It’s simple. The people who are busy having the “my language is better than your language” battle in coffee shops are pretty much guaranteed to not be the same people who are actually building large-scale applications. Why?

Because those people are too busy actually building large-scale applications to get into stupid chest-pounding arguments with monkey-brained nitwits.²

Look, none of us likes to admit weakness. Me worst of all. All I’m saying is that admitting weakness can make us stronger.

And saying something like “Ruby can’t scale–” especially when you’ve never programmed in Ruby and are just spouting stupid shit that you heard someone else say just so you can say something– is weak.

Unless you actually have something built– and that something is so freakin “oh my god we have more data than Twitter”-big that you actually know that it couldn’t be done in Ruby– then you’re full of shit, you know you’re full of shit, I know you’re full of shit, so you might as well just admit that you’re full of shit. Because if you don’t then you just look stupid.

And no true geek wants to look stupid.

Sometimes I think I may slap the next coffee shop critic that tells me Ruby can’t scale.

Me: “I’m learning Ruby”

Monkey: “But Ruby can’t scale”

Me: “Hrm. I guess you’re right. By the way, what do you use for Source Control”

Monkey: “Github.”

Me: <SMACK!>

See?

Duck typing with Duct Tape

I’m learning Ruby. I’m programming web applications in Ruby on Rails.

Moreso, I’m programming web applications that absolutely must scale.

“But why are you using Ruby? Ruby can’t sc–”<SMACK!>

Because let me tell you something: Having a “0.01% of users sometimes complain that it’s broken, can’t really scale because it worked for Twitter just fine” webapp is much better than having… oh, say nothing!

I’m not going to fool myself. Maybe Ruby can’t scale beyond a certain point. Who knows? I sure as hell don’t, because I’m not at that point. And the person telling me that Ruby can’t scale isn’t at that point either, I’ll bet.

We’re not at the point where we have 25 million users.

We’re not at the point where VC firms are dumping $15 million dollars in our laps.

We’re at the point where we are so busy talking that we’re not actually doing anything.

I’m in a freakin coffee shop, with a maybe good idea. And with a really fun language… one that’s powerful enough for Github and which scaled well enough to bring VC firms to Twitter after 25 million users came!

And with enough freakin’ bravery to at least want to admit weakness– that I don’t know what the hell I’m talking about when someone mentions the next trendy language that I’m too scared of, or too lazy to learn, or simply not really interested in.

I’m in a coffee shop, and I’m ready to use duck typing, or freakin’ duct tape if I have to, if that’s what it takes to actually stop spouting bullshit about scaling issues and actually accomplish something…

…and get the hell out of this damn coffee shop!

1. That was pretty much my childhood, anyway, so maybe I’m projecting a bit.
2. Oh stop being dramatic! I don’t have anything to show either. I’m in a coffee shop writing a freakin’ blog post instead of actually accomplishing something.

invalid option: --autospec
Test::Unit automatic runner.

Usage: -e [options] [-- untouched arguments]

Check whether you’re using the RedGreen colorizing gem. It seems that this conflicts somehow with the setup. The good thing is that I can turn that off and still work well since I have the autotest-growl plugin installed, so I see Growl notifications of my tests.

Hope this helps someone’s frustrated Google results.

I debated a while on how to do this, and even found other people looking for the same thing. Following up on that, I downloaded the citynames GIS database from the National Weather Service and started working. The result was a full suite of US city names– over 41,000 records!

Rails Plugin

I created my first Rails plugin to incorporate this data into an existing Rails application. The plugin is hosted on Github as geoinfo. This is as much an attempt to learn about creating plugins/gems as it is an attempt to provide a useful library for someone. Those of you who are looking to use it, check things out first.

Innards: lib/db

Basically, the important part is in lib/db. In that file are some YAML files holding the actual database of 41.5k cities and US states and outlying areas as well as Canadian provinces and territories. In lib/db/migrate are the migration files for geoinfo_cities and geoinfo_states database tables. I chose this naming convention to avoid clashes with other tables. Thus, if you want to use this data without the plugin, grabbing the lib/db folder is really all you need to do.

Coda

In the future, I hope to create custom methods for generating smart AJAXy dropdowns so that people can choose a state and have a city dropdown populated from that. I’d also like to include postal codes and more countries, because others may find that useful. We’ll see how much I can add– given that hunting down the data is the hard part.

Details, updates, changes, etc. will mostly be housed on Github. Feel free to fork and update/modify and send pull requests. If you have data to add (i.e. other countries or zipcode info), I’d love to collaborate.

So, the default installation of Ruby on Snow Leopard holds a set of default gems in

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8

That’s nice, because the system comes set up for basically instant development. However, those gems are out of date, and I kept having problems installing newer versions and get gem collisions. The main source of the problem was that I couldn’t simply “gem uninstall [old-version]” because the versions in the default directory stuck around. Similarly “gem clean” wouldn’t really vacuum anything up.

My solution was simply to remove them.

sudo mv /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8.default

sudo mkdir /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8

After this, I also removed all the user gems in /Library/Ruby/Gems/1.8, just to make sure nothing was around and cleaned things up until “gem list” showed nothing. After that, I reinstalled all the gems I needed and ran “gem update –system”

Now there won’t be any clash with the default gems that were installed with Snow Leopard, and I can still get to them if, for some strange reason, I need them.

My hope is that there’s someone else who’s as clueless as me. If that person is out there, and happens to get strange errors with Rails, maybe using Authlogic, maybe this will help.

ActionController::RoutingError in Users#show

Alright, so you’re building a Rails app, and you have no damn clue what the hell you’re doing, and you still decided to get all complicated and have completely useless and meaningless things like “users” and “sessions” and “logins.”

Well, it’s your own damn fault when you get some strange error like¹

user_url failed to generate from {:action=>"show", :controller=>"users"}

especially when you know damn well that the frackin’ controller is there and the show method works because you just used it 2 minutes ago and everything worked just find thank you very much!!!

Look, I told you it’s your own damn fault for getting complicated.

Sessions are like cactuses, they’re pointy and hurt, but pretty in Ansel Adams pictures

Yes, by the way, I know that the plural is technically cacti, but I’m going for comedic effect.

So, the deal is, the authentication token hangs around, and you’ve probably done something stupid like

rake db:drop && rake db:create && rake db:migrate && rake db:seed

just so that you could test some random thing that you don’t understand. Well, if you do that, and you’re using authlogic, and you don’t bother to logout before hand, your session token will remain live in the browser cache and then you will be totally screwed when you suddenly refresh your browser and get strange incomprehensible errors on a webapp that was working fine just thirty $*#(@*! seconds ago!!!

So, kill the server, flush the browser cache, and then do your crazy “let’s delete the entire damn database and fill it with the exact same information that it had in the first place because it makes us feel better” routine.²

Because, as it turns out, it’s not the exact same information.

Sessions are a bitch.

1. a full traceback is here, for you meatheads who actually get such an error
2. By the way, I know this only because I have an incredibly deep understanding of the subtleties of this language, not because I’d be stupid enough to spend the last few hours fighting with something that’s so blatantly simple… just so you know.