Holy Chao

I made some more beef jerky. It came out well, far better than the batch at the beginning of the month. Gonna try and get a little scientific about this shizz:

• 2lbs chip steaks
• 4tbsp sriracha
• 1.75C soy sauce

Sliced steaks to thin strips, put in marinade for 36 hours, dehydrated for ~3.5 hours at 160 deg F.

Could be spicier, 8tbsp sriracha and 1.5C soy sauce might work better.

This is a continuance of a thought that I'd briefly mulled over on twitter to some reaction. No point in summarizing as it's only a few characters: "In #Clojure I find it best to try and avoid naming anything except for the tools (fns and constants) used to construct a running system."

The reactions were great, as I would more or less expect, namely trying to drive at the thrust of why I would say such a thing. "What are examples of things I would avoid naming?" "By naming do I mean assigning to a Var, or something else?" and "My examples are primarily stateful things, is this to cure live programming woes?"

I'll do my best to expound on my reasoning in more detail, become more crisp in defining what I mean, and perhaps persuade you to strive in the vicinity of this same goal.

I have lived in Baltimore County, Maryland exclusively since November of 2004.

In that time I have only received one Jury summons, it was for tomorrow, and my call in number was 365. I ducked getting called, as they only wanted 1 through 225.

Looking at the call in messages for today and for tomorrow, it appears that ~400 individuals are chosen each day. If one presumes the courts are only operating on standard business days, that yields about 248 days of 400 individuals. Each year, then, 99,200 individuals are randomly summoned to appear as jurors.

Presently the population of Baltimore County is approximately 817,455. If the proportion of summoned jurors to population held constant over the past ten years (a groundless assumption), then each year an individual has a ~12.13% chance of being summoned. Consequently your odds are ~87.87% of not being selected in any given year.

The odds of successfully avoiding summonses for 9 years in a row are ~31.22%. By purely random chance, one could expect to get a Jury Summons once every 5 years (.8787^5 = .5238). The odds of getting summoned two years in a row are ~1.5%.

Apple has recently announced the Swift programming language, along with language specifications and documents to support it. I'm not particularly interested in learning much about this language, in no small part because it seems like it's tightly coupled to Apple's walled garden. However, I am interested in discussing nil and/or null, which I will call nil from now on, because Swift calls it that, Clojure calls it that, and Ruby calls it that.

Swift promises to disallow the use of nil in a variable except in those cases which someone has specifically allowed for nil; be it a parameter, a variable declaration or what have you.

Having written 0 Swift programs, my opinion on this is tangentially valuable at best, but I have written many programs in many other languages, and each of those languages has always had some concept of nil, and many of them were entirely birthed after nil was well explored and people understood the costs of nil, and chose to include it anyway. I'd like to discuss some arguments about why I don't find Swift's approach valuable. Additionally I'd like to discuss some other ways languages have approached the problems nil introduces.

My CEO/friend/person who's fired me twice Justin Gehtland exclaimed on the twitters yesterday: "What the hell is going on with everyone? Boston API Jam, Belvedere Vodka, Santorum. Is it National Misogyny Month and I missed the PSA???" I glibly replied: "People started paying attention to misogyny and calling it out. The misogyny didn't increase, your visibility into it did."

I find this basically true and explanatory, but after a few hours of reflection and home improvement I'd like to discuss it in further length than 140 characters allow.

I use Typo, because I like Rails, and it's free, and the feature set is pretty nice. But often I find that migrating between major versions sucks.

I just upgraded to 6 from 5, and experienced a problem every time I tried to read an article imported from 5. The failures looked something like:

ActionView::MissingTemplate (Missing template /articles with {:handlers=>[:erb, :rjs, :builder, :rhtml, :rxml], :formats=>[:html], :locale=>[:en, :en]} in view paths "/blog/themes/scribbish/views", ...)

After digging around a bit I found the culprit.

If you're trying to install REE with RVM, and you just, for example plug in the following

rvm install ree-2011.03

It doesn't work terrifically under OS X

It also serves as a local minima of functionality, in that it will get caught with the failure condition even if you remember to add something like:

rvm install ree-2011.03 -C --with-readline-dir=/usr/local

after having done the wrong thing.

You need to do the following:

rvm cleanup all
rvm install ree-2011.03 -C --with-readline-dir=/usr/local

At Relevance, one of our favorite tools to use is Devise. It has become the de facto standard for authorization when we need a solution, and with good reason. It solves a specific problems and plays nicely with others.

However, it can totally ruin your test suite's performance.

I've recently had the opportunity to work with some really exciting JavaScript tools that make developing apps that run in the browser much more powerful and managable than I've been accustomed to working with in the past. The trio of tools I am specifically interested in is CoffeeScript, Underscore.js and Backbone.js. I am specifically targeting technical audiences for this work, I will be assuming a good deal of comfort working with JavaScript, the DOM, and jQuery already. Additionally I will assume you understand Rails well enough to build a trivial app in it.

Rivaling the amazing transitive powers of Nightcrawler, Jon Distad and I decided to tackle the problem of parsing CSV rapidly under Ruby 1.9. "Aha!" you might be saying, "FasterCSV was already rolled into the stdlib in Ruby 1.9! Why would I need a gem to handle it?" Well you have a very good point there, FasterCSV was a good response to the performance of the old 1.8 stdlib CSV parser. However there are still cases where it doesn't quite go fast enough.