Perhaps the most common error I see in assertions on the internet (be it in the popular press, blogs, or what have you) is rooted in overstating your case. Quite simply, overstating your case occurs when you state that you have more evidence then you actually do, or when you state that your opponent has less evidence then they actually do. This occurs near rampantly in live debates (especially among the non-scientific), because rhetorically it sounds great to say that you have all the evidence and that your opponent has none, however this is rarely true. And you can see these types of mistakes coming back to haunt people.

For example, Jon Stewart actually got nailed for this recently by Politifact. He first made the statement that polls showed that Fox News viewers were consistently the most misinformed. While this doesn't quite encompass all the nuance of the truth, it's a very defensible statement, and probably would have gotten a "mostly true" rating. However he had the mistake of going one step too far and stating that Fox viewers were the most misinformed "consistently, every poll." That every sets a rather high bar of evidence, and ultimately led to his statement being rated as "false". Credit should be given to Mr. Stewart for going on air and apologizing for his misstatement (It's a sad day when we see greater journalistic integrity from a comedy show then we do from our own free press).

Remember when engaged in rational discussion, it's appropriate to couch your assertions and to question those who do not. You will notice a great deal of this in the scientific literature. Reason deals in probabilities, evidence, and nuance. Rhetoric deals in absolutes, assertions without evidence, and ad hominem. If the person you're listening to is dealing in rhetoric and not reason, you're probably not dealing with a reasonable debate so much as a talking points exchange. State the facts you have, and not more.

If I had to break down all the things I learned at RailsConf into individual items, I think most people would be surprised which individual items sees the most usage when I'm giving tips to someone else on their Ruby code. When working with an item that I need to be an array, and yet have no idea what it actually is, people frequently use an if:

if result.class != "Array"

Or, some people will use the more compacted method of a ternary operator:

result = result.class == "Array" ? result : [result]

However, the Array class is already equipped for a more confident method:

result = Array(result)

The Array class' initialize method already returns an array of any class you pass it, with the exception of another Array. If you pass it an Array already it will simply return the original Array.

It's quite a simple tip, but I've been extremely surprised how infrequently used it is, and how often I've used it or passed it along since I got back from RailsConf. Big thanks to Avdi Grimm for his amazing lecture Confident Code at RailsConf 2011.

One of the things I love most about Ruby is the simple extensible ways you can manipulate objects. So when I recently came across a new instance of this, I thought I'd pass it along to my readers. I decided to write a framework for working with pen and paper games, and when I started writing the dice rolling class I noticed that I had a block that had to be unnecessary in Ruby.

num.times { rolls << (rand(dtype)+1) }

The first line is just rolling the dice a specified number of times and loading them into the rolls array that I previously declared. The rest of it is just adding up all the numbers to return a sum. Being a former Java programmer this is exactly how I would have done it there, so I just wrote it that way and moved on. But as I began to look back, I realized that it was quite ugly. Beyond that, I couldn't believe that Ruby wouldn't have a more elegant way to handle this common task of reducing an array of components to a final result. Fortunately it does, and the answer is in the inject and reduce methods.

These two methods appear to be identical as far as I can see (if I'm wrong, then feel free to correct me in the comments and I'll edit this later), so I'll be addressing just reduce, since I find it more pleasing syntacitcally. So using these how can I solve my problem?

rolls.reduce(:+)

One tiny line. I love me some Ruby. Reduce actually performs an identical operation on each element of the array, keeping a carryover variable as it does so. For simple mathmatical operations, you can pass a symbol of the operator you want to use, like :+ to add everyone up. But you can also use other operators, even :** if you wanted the code to exponentially increase on every iteration. However, what if you have an array of strings you'd like to get specific data out of with a constant operation. Or what if you want to do a little more complex operation to each one. Well as usual, blocks come to the rescue.

rolls.reduce { |total, n| (total + n) * -1 }

The first one does a more complex operation, multiplying the result by -1 every time. It's contrived, but it shows how you can give the array a block of more complex math. The second example iterates through the array comparing the elements looking for the largest item in the array. It should be noted that the return value from the block becomes the new carried variable, and the final returned variable is the return from the method. Also note this doesn't change the value of the array.

Hopefully someone else will find that this saves them some time later!

Being the cheerful, skeptical fellow that I am, my wife was good enough to point me to this gem from the International Air Transport Association. This is probably due to the skepticism I expressed about the FAA regulation involving the usage of personal electronic devices during takeoff and landing. To be clear, I have no issue with them banning cell phone usage. I could vaguely see how the active broadcast of cell phone signals MIGHT interfere with some of the more sensitive equipment. I still doubt it, but that sounds plausible to me. An e-reader though? Or an iPod? Or a CD Player? Really? You think that the tiny electromagnetic radiation from their power consumption is really going to affect the equipment? If your equipment was that unshielded and sensitive, then your own power consumption would fuck it up.

So did this article from my wife change my opinion on the matter?

I'm still highly skeptical of the entire thing. For starters, the paper that they produced isn't a scientific paper, it's a survey they conducted not trying to find evidence that this occurred, but rather asking crew members if there were any incidents they BELIEVED were caused by passengers using portable electronic devices. No evidence they actually were is needed, just write down your suspicions. Furthermore, they only came up with 75 of those. This survey covered their organization (125 airlines) for the years 2003-2009, or a grand total of 17,520,000 flights, and yet this terrible problem only produces 75 reports? Ridiculous. That's only .0004%. To put that in perspective, the National Transportation Safety Board reported that in the US, during that same period there were 2133 fatal accidents in the United States airline industry. Being that this organization accounts for one quarter of the industry, they should be responsible for 533.25 of them during that same time. So fatal accidents are definitely documented to be seven times the problem that portable electronic devices kinda maybe might be.

Why even produce these kinds of papers if you're just going to use such shoddy methodology and come up with such terrible results that don't even support the position you're trying to put forward? It just undermines everything you're doing and makes you look like you're just producing lying papers to try to iterate unpopular talking points. Verdict:

Specifications are probably the most important, completely ignored artifact I've seen in the developer world. Open source developers (including myself) swear by them, because they are a way to keep us all following the same rules. Yet, for a variety of reasons, they take a long time to adopt, and large companies have a tendency to just run over them whenever they become inconvenient. Worse yet, even when the specifications are revised later to make them work better, they continue to ignore them because now they have a backlog of code that ignores the specifications to work off of (See Internet Explorer). All this brings my latest cause of depletion of my Excedrin bottle.

OAuth is a specification for authentication between applications and server-side APIs. It's supported by most major internet APIs, though most of them are preferring OAuth 2.0 (Facebook recently forced all developers to move their applications to OAuth 2.0). You can find the OAuth specification here.

So why am I writing about this particular specification? Well recently I was working on a few outstanding issues on the ruby twitter gem (specifically Issue #161), which detailed a problem wherein posting a multi-part form with extra options in the body was causing an incorrect signature error to come back from Twitter. I sat down and traced it back to the generation of the OAuth signature in the middleware used by the twitter gem. I realized that it was throwing the entire body in the signature, except for the uploaded media. So I flipped open the specification and found that per section 3.5.2, the body should only be encoded if the content-type is set to "application/x-www-form-urlencoded". So I updated the code, made sure all the test cases ran, verified that it fixed the original problem, then checked to make sure that a few other commands were still working, then called it a day. However, upon review, @sferik discovered that this patch to the middleware had broken the normal status updating function.

Needless to say at this point I felt quite embarrassed, and doubly committed to actually fixing the issue appropriately. So I started going through twitter's development API to check how they were doing their authentication specifically. It was there I found out that Twitter encodes the entire body if there is no uploaded media, and NONE of the body if there is uploaded media. Obviously this is completely off specification (though I'll admit it is more secure than the specification way of doing it). I talked to the guys who run the twitter gem and ended up coding up a custom solution for the twitter gem to override the middleware's OAuth implementation, which resolved the problem.

But in the end I find myself conflicted about the entire experience. I understand that in order to facilitate a more secure environment for their users that the Twitter devs would want to encode the entire body for the majority of their interactions, however by going off specification, they're making it more difficult for all the other developers by forcing everyone to use custom solutions to deal with them. And anyone who's ever worked with CSS in Internet Explorer knows what kind of headache that can be.

So I guess in the end I'm curious what you all think? When is it appropriate to ignore the specification and code your own custom solution? Is it whenever you can do it better? When your company is large enough? When it threatens your clients? What's your tipping point?