I recently read Joshua Foer’s excellent book, Moonwalking with Einstein. The book, very much in Gay Talese fashion, relates the story of a resporter who goes to investigate the goings on of an international fellowship of “mnemnostists;” that is, professional rememberers. I’ve long had an interest bordering on obsession as pertains to memory. I’ve always wanted to remember more, in more clarity and to assemble the world’s languages with Mentat-like skill. But alas, I appear to be wired with commodity hardware (like most of us).

Foer, very much a mortal, suggests that astounding levels of memory retention can be attained by embracing the wisdom of the ancients and using the memory technique known as a “mind palace” or, as it was known to the Romans, memoria loci (contra memoriam verborum, for verbatim text).

Last week news broke, via a conscientious objector, that the US government is culling metadata bout phone calls in the use en masse. On the heels of this another story broke that the government had back-doors into the servers of several big-name tech entities: Google, Facebook, et al. This was later revealed to be less of a back door and more of a web tool for gathering court-mandated data from said entities.

A week later I have to ask: Why the outrage?

As I see it there are two issues:

1. Metadata harvesting via Verizon
2. PRISM as a tool for accessing big providers’ data sources

Let me address them in reverse.

The question is often enough asked: “Why is there such a dearth of diversity in open source?” While some have supposed that there may be some sort of genetic difference (hogwash) or similar, this last week I had some experiences that showed me why newcomers to technical and open source communities might decide to quite quickly spin on their toes and walk right back out.

A reader recently sent me a nice bit of research about job market for MBAs. It was a well-written article and I enjoyed reading it. Readers, you may find this interesting as well. One of the sections marked for growth is “Big Data:” a topic near and dear to my heart.

I especially found this quote by Robert Fitzgerald of the Lorenzi Group interesting:

…take statistics and economics…[don’t] be choosy about…[their]…first job.

Fitzgerald was later quoted:

“Get ANY role you can. Yes, it will suck. Yes, you are worth more, or at least your degree is. And while you are in that role, in your free time, start analyzing everything. Come up with infographics that are funny, helpful, and interesting. Show them around the office. You will get noticed,” he said.

The quote seems to certify that the days of being a special snowflake by virtue of your degree or the debt you went in to attain it are over. Once upon a time a man (yeah, a man) could spend a few years at college, refine his Latin and Theology training, and then study for the bar, apprentice, become a lawyer and then a politician (cf. Noah Webster, John Adams, John Quincy Adams, et al).

MBAs in the year 2013 anno domini, I have bad news: labor is global and the paper with the blackletter repeating the name your parents gave you is worth far less than the fact that some guy in Asia knows books full of math, economics, and statistics and can offer not merely the promise of capability, but can deliver results right now.

Heck, this fellow beat out more people just to get his shot to learn those topics than you’ve ever competed against in your lifetime. You are at a disadvantage.

Potentially, as you move up the ladder (surely thanks to your witty infographics, admirable golf handicap, and hard work), you will enter a part of the influence and leadership curve where your MBA will help differentiate you from the database wizard: you’ve learnt “articulating vision” and have the shibboleth credentials of looking like executive management and have the good fortune of citizenship.

But opporunities for differentiation won’t come until later and you’ve got to service your debt and your household in the here and now. I liked Fitzgerald’s practical suggestion. It’s also a fact about the world of today: get used to running all the time.

What is it about tech conferences that makes individuals who work in a highly cerebral and reflective industry like software development go quite so nuts? Why the oral sex jokes, the thong-model backgrounds on slides, etc.? And why are the sponsors so willing to bring out Hooters girls or hire go-go dancers at their events?[1] In short, why does the tech conference misbehavior look so much like the hormonal, puerile misbehavior associated with Spring Break misbehavior? I believe that a contributing force rarely mentioned is the way conventions and their host cities (intentionally or not, tacitly or not) market the host city’s “vice” industries as a selling point[2].

It comes down to capitalism and insecurity. The cities that build convention centers and hotel complexes court conventions to attract conventioneers and their filthy lucre. It’s like shooting fish in a barrel: conventioneers, unfamiliar with the city, without a car and and lacking their standard social support mechanisms are in the perfect mindset to dispatch their insecurities with expensive calorie-bomb comfort food and alcohol. Inflating local business revenues and procuring the tax-runoff thereof by attracting these hordes must seem like such an obvious win politically and financially. It’s no surprise that municipalities and their politicians so readily reach for the “build a convention district” plan for municipal funds recovery.

I further contend that there are a few cities that have acquired the reputation of being cities with a really good vice market: San Francisco (North Beach, Tenderloin), New Orleans (French Quarter), Miami (Everywhere?), and the 2 ton gorilla, Las Vegas (Everywhere!). When you go to a convention in one of the cities there’s the unstated “Yeah it’s in $VICE_CITY … nudge-nudge-wink-wink.”

It’s probably no surprise therefore that the picture atop this post was a bit of litter I found on the sidewalk a block away from San Francisco’s Moscone convention center.

Introduction

On my walk home from work I often listen to the Ruby Rogues podcast. In their episode with Glenn Vanderburg on ”Complexity,” there’s a fascinating discussion on the nature of science, and how that defines the modus operandi of “computer science.” Dave, a panelist, asserts that: “computer science is heaving with science, but its heaving with formal science as opposed to empirical science.” I believe development is “heaving” with “formal science” because of of an all-too-human reason: vanity. Developers esteem formal reasoning over empirical reasoning out of peer pressure to seem “smart” which is associated more with the formal style of reasoning. I’d like to look at why this is the case.

Formal Correctness Versus Empirical Correctness

Given a set of propositions, ideas, lemmas, rules, etc., one can manipulate the input data, via a series of actions and “prove” that the system is “correct.” Much like logical truth, more helpfully called consistency in logic, this “correct” is not the “correct” that tests or use by end-users illustrates. Rather, this consistency or correctness follows from the form of the argument and the definition of the atoms and their transformative processes. The computer scientist Knuth’s humorous statement is recalled: “Beware of bugs in the following code. I have merely proved it correct. I have not tested it.”

This is the kind of “computer science” that can be done with a pencil and paper. It looks a lot like math or symbolic logic ergo formal science. It feels old-school, punch card, ur-nerd, Rand Corp, programs in 16K of memory badass.

As mentioned above, “correct” for end-users has nothing to do with the aforementioned formal correctness per se but translates to “the app did what I expected to. It didn’t blow up.” Like an 8-year-old discovering the miracle of baking soda and vinegar, empirical correctness is based on “did that blow up in the way I expected or not?”

This is the kind of “computer science” that requires a compiler and a unit test framework. It benefits from more computer tooling that makes the feedback loop between failing test, passing test, beautiful code being sped up. It doesn’t look like that staid horn-rims and tie computer science, it looks like SoMa and people command-tabbing through screens like monkeys undergoing attention defeceit research.

Developers’ Esteeming Formal Versus Empirical Correctness

I find that developers seem to have a natural, per-person bias towards empirical or formal testing of their code and that there is a privileged association with formal reasoning about code. Dave, speaking of his clients said:

Yeah. I’m actually facing with multiple clients recently this resistance to [empirical] testing. And there’s just this innate need to think about code and to logic your way to the facts.

Dave, I believe, used “innate” hyperbolically, I believe he really meant that “developers see empirical testing as less prestigious, B-team and don’t want to admit that they could benefit from it.”

Let’s imagine a bug crops up in a system, who wouldn’t like be the formal adept in this scenario:

You approach debugging from a mathematical point of view: proceeding from inputs what must be the case. You look at the code and fold you hands and, with the help of a single console-logging statement or debugger statement (or two) you find where in the logical exercise that things go the wrong way. You edit an if/else and the bug disappears.

Who wouldn’t like to be thought of like that? It makes you sound wicked smart. Alternatively:

You look at the bug report and see that the inputs were X, Y and 2. You know that the code blew up at line 22 so you put a debugger on line 21. You run the code with those inputs and look around the system. You manually make the deadly code on line 22 run, you evaluate its results. You see the bug. You write a test case to run the deadly input set. You run the test over and over (automatedly) while you fix the bug. You see the bug is fixed (via the test) you check in your test and your patched code and move on.

Doesn’t this sound less ivory tower, less ethereal, more plebeian? So if a consultant came in and told you in a meeting with your peers that your team should embrace automated testing would you be the one who would be brave enough to break the culture rank to say “Y’know, that’s a good idea” when the implicit cultural tenet is: “The best of us are smart enough to always logic our way through?”

In computer science, full of its math envy as it is, we want to look like those early mathematicians turned computer scientist like von Neumann, Turing and Adm. Hopper - formalists.

Out of fear of appearing like the weak one (lower peer/boss review, less pay, less respect, less prestige), the emperically-biased programmer stifles her dissent (something humans have a hard time with anyway) and presents, if not feigns, dislike of empirical methods. Perhaps this behavior is so universal that it seems “innate,” as Dave related.

It’s vanity and peer-pressure: the same forces behind most bad decisions in human history.

Conclusion

I think that all developers should be strong in both approaches: As an empiricist, I’ve worked hard to get better at formal evaluation and at writing code that’s easier to reason about so that I don’t have to step through it or make it blow up several times to figuring it out (empirical methods). However, I think we should all have the humility to admit when an empirical test helps figure out the bug.

As Kernighan said in “Unix for Beginners” (1979):

The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

Even the masters need visual confirmation sometimes!

Coda: Honest Talk

I feel like I would be dishonest if I were to not explain my own background on this question. In part I hope that if you read the previous section and thought “Wow, thanks for saying that” you might enjoy my being honest with you about how I mix the two disciplines. Here it is:

I didn’t come to development via computer science but by a mongrel polymath background so it’s less (just barely) embarrassing for me to say that I like empirical debugging. It feels good to me to make stuff blow up on command and then to know that when I’m done I’ve left a fix and a test behind, a check on other things blowing up in the future if someone else changes a part of the system. I like the emergent phenomenon that several small tests, in aggregate, might serve to cover more uses and possible error states than we had thought of by following the formal structure of the code.

But that comes with a catch: if you look at code and errors this way you may cover only one case of a whole variety of bug cases, you’re only being guided by the latest disaster. Eventually you’ll stop the bleeding but by layering a thousand bandages versus one perfectly placed suture. What to do? Here are the steps I follow:

Practical Debugging Steps

I found an interesting discussion on this topic by Jeff Vroom who said use the one to focus the other (formal to empirical and vice versa). I think this is good advice. Here’s what I, an empirically-biased developer, try to do to engage that “enhance the other” virtuous cycle:

1. Something blew up
2. Where?
3. Generate a test case where those same inputs cause the blow up to happen. We future-proof against this error. Just as I don’t need accessibility features (big print, ramps, handicap door openers) I’m glad they’re there when I’m tired or my hands are full. Even the most brilliant formal thinkers will eventually be thankful for your empirical test
4. Why did it blow up? I switch to formal analysis here
5. Which of the inputs was invalid?
6. How did it get set incorrectly?
7. If you have code that adheres to the single responsibility principle and is nicely structured so that it has small parts you should be able to reason through the process easily
8. If you need to, add a logger or debugger breakpoint to “get” the failure.
9. If this code is hard to reason about promise to make it easier to reason about after you patch this bug
10. Fix the failure
11. Switch back to empiricism: is the test passing?
12. Fulfill the promise: was it hard to reason about? Can we write the code in a way such that things are easier to reason about? This is refactoring. There are many good books on the topic and you only get better by practice
13. Commit and move on

These are the steps by which I’m trying to make complexity more graspable for humans of all reasoning biases more quickly. Sometimes I do better than others, but there’s where I’m at today.

I’ve been programming Rails for a while now, and with the major releases I feel like I’m back to square one. There’s new gotchas, new strangeness talking to the databse, etc. As I encounter strangeness, I’m documenting it here.

I started by installing rbenv and Ruby 2.0. I then followed this Stack Overflow post on how to install edge Rails. I really like this approach because it makes use of Git submodules.

Things after I got Edge rails installed, I then set up my Gemfile. I don’t want CoffeeScript so I handled that by commenting out its line in the Gemfile.

I installed Postgres via apt and that went swimmingly. I was suposed to merely configure the config/databases.yml file and then rake db:create my way to happiness. Here’s where the pain appeared. I kept encountering an error like: FATAL: Peer authentication failed for user.

Fortunately Stephen Goss at Delicious Robots Blog had the solution: reconfigure pg_hba.conf. With that I was able to execute rake db:create and see my databases. I’m planning on following Michael Hartl’s excellent tutorial mostly as a means to make sure that I step through many of the new ways of doing things.

I’m planning on blogging any other snags I find along the way, but that Postgres one was a real nasty one.

I have completely been remiss in terms of medical care. In fact, there’s a critical reason why: I was afraid. You see, in my last visit to a doctor ( about 7 years ago ) I got that kind of news nobody likes to hear: you have too much stress, you weigh too much, and your triglyceride levels look to be on the low end of acceptable.

After that I moved and never found a doctor I liked, moved again and never found a doctor that I liked and just kept ignoring that I needed to get a physical. I think it had been 6 years.

So the other week I resolved to remedy this situation and to talk to some friends about what sort of medical care they were receiving. I received a recommendation for One Medical here in San Francisco. It’s a club, basically, that one pays to join ($150/annum) and, in exchange, you get things like guaranteed same-day appointments, iPhone app appointments, medical interaction over 21st century media (email your results, automated reminders on your GMail calendar, etc.) — you get the “e-Medicine” promise that seem, largely, to have never delivered on its vision.

Today, as I read my mail via iPhone on Muni, I received a summary:

1
2
3
4
5
6

 - Your screening test for diabetes shows that your glucose (blood sugar) is in a healthy range.

- Your lipid profile (a.k.a. cholesterol test) results are as follows:
   - Your triglyceride level is excellent.
   - Your LDL ("bad cholesterol") level is in safe territory (based on your calculated cardiovascular risk.)
   - Your HDL ("good cholesterol") is at a healthy level.

Somewhere over the last 7 years I got healthier. I attribute it to the following:

• Living with a Southern Californian, their endemic “let’s go outside” is antithetical to my native Texan: “Outside? Where the hot is?”
• Walking 1-2 miles daily thanks to the highly walkable life of San Francisco
• Taking up running a few years ago
• Vegetarian since January

Wherever you are, no matter your age, you can change. It may be hard, you may have to have a Harajuku Moment, but when you see yourself beat the maxim that aging is slowly falling apart, your self-esteem goes through the roof.

There has recently been some discussion about how hard or easy it is to get started with Ember. I’ve been using Ember for a while, so I don’t think that it’s that hard, personally. But there are a lot of moving pieces.

While my Ember-friend Trek is busily preparing getting started guides and the word is getting out, I have updated my Halbert software to have a tag so that you can get started right away.

WARNING: This is Ruby-biased. I’m not serving you omakase or anything like that, I just don’t know Node well enough to get something delivered quickly.

Steps

1. git clone https://github.com/sgharms/Halbert.git
2. cd Halbert
3. git checkout -b my-embert embert-1.0rc1
4. bundle install
5. rake: this starts a local web server on port :4567
6. Point a browser to http://localhost:4567

Screenshot

Adding a View

Here’s a gist to add a new Ember.View:

Closing

Obviously, if you want to follow along with other tutorials or start doing advanced work with the router or Ember Data this minimal harness may break down (I don’t know, I haven’t tried to break this setup ;) ), but it should let you see that creating a baseline Ember app is not impossible, or even hard!

And let me point out, further, Ember is not like YUI or MooTools or jQuery. It is not a tool that lets you do Javascript work. It is a framework for building applications in Javascript. As such, approach it and its learning curve like learning Rails. Does anyone get mad when Rails doesn’t reveal its secrets in a day or two? No, you realize that learning this paradigm will pay dividends down the road and that learning curve time is an exchange for power.

That said, get hacking. Ember is great.

I recently signed up to take an Algorithms class online via Coursera. The language of the class is the new lingua franca, Java. I do most of my development on a VPS which means I’m accustomed to doing my work on the command line with my editor being Vim. While the class doesn’t require one to use an IDE, I didn’t see that any other work flows explained how to do the assignments without an IDE.

I’ve done some work around Java build management using Maven, so I thought I would try to apply Maven’s basics so that I could do my work on my VPS. Here’s my documentation on how I did that. I hope that others in the class might benefit from this as well.