Ben does it in software

I know many people who live and die with some of these shiny IDEs: nice fully-featured software to manage software projects. Design, code, compile, run, debug. Me, I distrust these great magnificient beasts. The good ones I've heard of work best when targetting certain platforms and languages, such as Xcode (for Mac and iOS software written mainly in Objective C), Eclipse (for Java software) and Microsoft Visual Studio (for C/C++/C# targetted at MS Windows). I've only worked with the latter, so bear with the gratuitous generality, but I've got the vibe that these IDEs feel cumbersome outside of their choice targets.

I've abandoned IDEs without looking back when I discovered the bash shell and Vim. I have been fascinated with the ease by which complex tasks could be easily solved by snapping together a couple of Unix tools. Being a keyboard-loving touch typist, I found that a few scripts and Makefiles replace beneficially the GUI used for compiling and running software from IDEs. For the coding part, I fell in love with the multiplatform Vim editor. Two things are still done more easily in IDEs, though: interface design, of which I really don't do much, and source navigation.

Now I have a nice trick for the latter.

Having just fallen in love with literate programming, I stumble on this hilarious piece. Not so sobering as just a reminder that not every problem is a nail. As I said earlier, literate programming is a tool to manage the complexity of a problem solved in software. However, when the solution is expressed concisely in a certain language or toolkit, it is thus a simple problem in this perspective. Therefore, there is no complexity to manage in its solution, hence no need for tools such as literate programming.

I will look like a complete Philistine, but this piece is my first serious exposition to literate programming. The times I had heard about this approach to software development, it had been derided as academical, unpragmatic and impractical -- something that was of interest only to its pioneer, Donald Knuth. That that I can see it for myself, I think the ideas behind literate programming are utterly exciting.

Not that I think that the piece above got it completely right. Actually, its takeaway should be "do as I say, not as I do." The author hits his mark when saying that the text segments between the code fragments should explain the why of the code, not the what. Explaining the what is repeating oneself, as the code is the what. Still, the author goes off and writes about the what of his code and not they why, so his whole program is a bit hard to read, in spite of being simple and fully documented.

The what is the code. The why lives as a second, third, nth degree within the code. What the text between the code should say is why some variable is made global. Why some functionality is spread between these three processes, these five functions. Why these things are coupled, when we know coupling is bad. Real-life code gets ugly, as programming is like packing one's car trunk: you make decisions above decisions you've made previously from less information. It's NP-hard!

Literate programming done in increments, supported by unit tests, should then document the decisions as they are taken. This documentation can drive future debugging and refactoring, avoiding contradiction and easing new developers trying to wrap their head around the growing code base. I feel that literate programming is a complementary way to manage the complexity bloom of software projects.

Its now a cliché that programs are parsed by computers, but read by people. I'll add that if compilers have a right to complain that a program is unfit to be read, so should people. Programmers must communicate their ideas to people. They thus must be good writers. These days, we see many people embracing the functional programming languages and approaches that I had seen my coeds deride when we learned them in undergrad CS. FP is the old idea that's become a good, fashionable idea. I feel that the next such concept to resurface will be literate programming.

I am a member of the Vim cult. We hold no meetings, we don't always know each other, we don't all mock Emacs (at least I don't), we just share an unlikely love for this lean and efficient text editor. Vim is like a good dog, it follows you everywhere you code, your faithful companion.

However, like a good dog, Vim requires some taming, some domestication (actually, Vim tames you -- even out of soviet Russia). It has been said to have a steep learning curve, which I cannot deny. However, putting its commands at one's fingers yields rewards of unexpected magnitude. Its bimodal approach to editing has been derided, but one does get used to it, and it then feels natural: now I'm reading, now I'm writing, and so on.

The steep learning curve, however, is best overcome in small steps. This is the main point of this great lesson in text editing by Vim's original author and actual maintainer, Bram Moolenaar. Learn the basics, then learn the advanced features that allow you to be efficient in your own work. Practice until these new features have become second nature. Repeat as needed. As Vim only requires keyboard interaction and few chords, it enters easily in one's muscle memory.

Very honest piece. As a software developer of any walk or flavor, you work a market, so you have to sell something, to offer some value to someone. Making yourself hireable entails making this value explicit. So shine away.

Here's a good quote out of the article that has prompted some bitter responses:

You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.

I get the bitterness, but I totally agree with the author. How do you think have computers become so important in this economy? They were born to run complicated and tedious calculations. However, they have taken so much market space because of automation: doing stuff that people use to do more reliably and more cheaply. Hence, putting people out of jobs.

Scotch tape fetish

Back when I was working for my Ph.D., there was this post-doc in our lab who had this funny habit. He had this big roll of scotch tape by his computer screen. Every morning, as he sat down for work, he tore off a good length of that tape to bind his left-hand ring and pinky fingers together.

"Is this some kind of fetish?", I asked on a slow day. "No, it's because of the pain." He went on to explain that he used to mouse with his right hand, but then he developed severe carpal tunnel syndrome. When the pain became chronic, he switched to mousing with his left hand, but then the carpal tunnel started flaring up on this side as well. "That's when I realized that I had this unconscious habit of stretching my pinky away just so when I held the mouse. Now, my right hand is busted for mousing, but I can still get by with the left by forcing my pinky in this relaxed position."

Does your work involve repetitive gestures, such as mousing or typing at a keyboard all day? Well, then you have to care for your work ergonomics. This means a lot of things, but as a rule of thumb, you must be careful about avoiding any sort of excessive fatigue.

Eyestrain 10pt, bold

I am a lucky man not to have had to endure the torment of carpal tunnel, but I also have my pet peeve as a full-time software developer. Hard days get me headaches. Not migraines, thank god, but headaches sufficient to ask my kids not to be so noisy while I fix dinner. Dull, tired, sad headaches. I hold myself to some standard as a dad, so I need to have some control over these headaches.

I have remarked that the worst skullbores happen on days where I'm under pressure and I squint at the screen. I surprise myself peering confounded at the glass, shoulders tense, neck craned forward, back stooped, eyebrows furled. I put myself into this crow-like position unconsciously when I get nervous about some code or bug or negotiation or change of plan or what-have-you.

I figure headaches come from the physical fatigue of the crow stance, so this can be tackled as an ergonomics problem. How can I avoid squinting? The first thing that comes to mind is to reduce eyestrain any way I can. For reading text and documentation in my web browser, just increasing font size has worked wonders. I also ditched the old bright-characters-on-dark-background color scheme that I found so 'leet when I was a college student. I now use lower-contrast black-on-lightgray color schemes, in which the characters do not become blurry as the day progresses. Figuring out colors for syntax highlighting that contrast sufficiently against gray backgrounds was a small hurdle.

However, it did not fully fix the dreadful headaches that come from difficult coding and debugging, activities I do in editors and terminals. These are the domain of monospace fonts, the readability of which does not seem to be directly enhanced by simple enlargement. Also, bigger monospace fonts yield work windows with less rows and columns, or that become so big that the editor and shell windows cannot fit side-by-side on the screen. In short, I needed a cleaner, more readable font that would get me to squint less.

The $220,000 font

I recently discovered the excellent font work of Fabrizio Schiavi (@fabrizioschiavi). He designed PragmataPro, a monospace font that is highly readable and comfortable even in small sizes. It is condensed in both width and height, but somehow still manages to breath on the screen. It is a real labor of love, as all the characters appear crisp and clear even for large font sizes.

The problem is that this font is sold at 170 euros. I know, "what's a headache worth to you" and all of this, but I just do not have this kind of petty money on hand. However, Schiavi has a plan to make the font free, if he can somehow recoup the resources he spent designing it. The amount he is trying to raise gives pause, and his budget breakdown made me glad I live under Canada's tax burden. Still, if he fails to reach his financing goal, Schiavi has pledged to offer the font to all contributors for a more affordable 20 euros.

This offer was quite palatable to me, and maybe it's because my wife is a graphic designer too, but I contributed enough to be offered the ancestor font of PragmataPro, named Pragmata. This thing is my new sliced bread. Like PragmataPro, it is a horizontally condensed font design, but with a largish interline space. On my 1680x1050 screens, the font size that I find most comfortable still yields more than 40 lines of text, which, while less than Inconsolata's yield, fits my need. I am surprised at how I like this interline space: it breathes and feels like the old electric typewriter I used when I was a kid.

Here's a screenshot to show the font in action. On the left is a 25-lines iTerm2 window with a Gambit Scheme session. On the right is a 41-lines MacVim window with a bit of Markdown code. In both cases, I appreciate the equilibrium of the characters, more than twice as tall as they are wide. I also love the large space between the characters, which help them breath. It is this space that makes the medium-weight characters so crisp and easy to read. There is neither bloat nor blurriness to this font, even after reading page after page of terminal output.

Fond of your font?

We software developers have access to many free high-quality tools. There are also those tools that we paid for, sometimes dearly. I've seen people advocating passionately for the likes of TextMate, Mac OS X, optimizing C compilers, Matlab, Visual Studio… We see how one can get by without these tools we love, but we would not. I feel this way about the Pragmata font, and I expect as much from PragmataPro.

Sorry for the long hiatus, dear reader, the last many days have been crazy at the job.

These are notes for a presentation by Perl guru Mark Jason Dominus, the author of Higher-Order Perl, among other things. From these many wisdom nuggets, here's a few ideas I retain.

As said Vonnegut, "God damn it, you've got to be kind." Really, it's not so hard, even I am up to it. Writing to someone you know but in reputation, to ask or comment about code or ideas? Introduce yourself briefly, give some context to your question or remark. Do not confound curtness and concision: the latter is appreciated, the former is unsettling. Hellos, pleases and thankyous are not fluff, they're air: the air that fills the tires your car/bike rolls on. Want a smooth ride?

The other side of the coin of kindness is the fish discussion. I've taught many classes at the undergrad level, and I've seen the results of a having a positive stance towards questions. I've always given prompt, helpful answers to students who cared to state their question clearly enough for me to understand (not always the case). Those students who pried direct answers for homework problems were seldom interested with the course material in the first place, and often performed in the lower and middle tiers of the group. However, for people interested in the course matter, a few helpful answers would get them on track to complete their projects and solve the most difficults problems on their own, making them happy and proud of themselves, and getting them to perform in the higher tier of the group. There was no sucking-up, nor any sort of favoritism or nepotism going on. What have I got out of this all? Many of these then-interested students have become good professional contacts, with whom I share a common appreciation of our respective competences. In other words, if I'm seeking work, I can call some numbers. Giving a bit of your knowledge freely nets you karma, grasshopper.

OH: apparently, Lisp communities are not friendly with newcomers. HA! opportunity, here we go. I love Lisp dialects, though I've only dabbled lightly. Let's talk some Lisp; let's start a Lisp community that takes heed to my idea #1 above. To be honest, Montreal's Clojure user group, named Bonjure, is a very nice bunch. Let's copy their kindness without mercy, while we talk some Lisp problems.

Dominus raises a very good point about pragmatism of code solutions. This is the one snag I always trip in while doing test-driven development: after writing a few tests, I get smartypants. I start writing a clever complex solution. It takes time. In the end, it's useful as-is only as often as it's not, which I figure as I get to later parts of the task. So much time lost! 

So, brain, hear this: from now on, when going for the first implementation that gets a test to run, you go for simple. Keep the smart stuff for when simple is not enough anymore. Don't look over this moment's shoulder, don't try to take into account what's coming after these tests, just do simple. Does it look dumb? Whatever. Does it look inefficient? It's only looks. Do you think we'll have to scrap it before lunch? We'll see. Ok? That's a good brain.

Software is like any human project: sometimes, it's, you know, finished. That it receives no further update or new feature does not mean it's abandoned. It's just right as it is.

A good example of this is TeX, Donald Knuth's famous document preparation software. It has not had a single new features since the '80s. Is it abandoned? No, it's finished! Besides having received a few bugfixes throughout the 30 years since being feature-complete, it's used both by itself and within many other document preparation systems, notably LaTeX. Many mathematicians, physicists, engineers, scientists and writers can use //nothing else// to typeset their stuff. So, before pronouncing the death of software that's not receiving updates, wonder whether it just solves your problem already.

Reading is hard. Sure, one can follow the text, maybe even retain some of the material. In all honesty, while writing this post, I am referring again and again to Dominus' notes: "What was he saying again?" It's just about four pages long and I have trouble remembering what's in there. So what's in that big 500-page book you've read last week?

Reading actively is difficult, I'm often drawn too much towards what comes next to really pay attention. I prefer Andy Hunt's advice in Pragmatic Thinking and Learning: read once through the whole document, to get an overview of the material. Then, take the time to re-read slowly, taking notes in margins or in a notebook. I must say, while I love e-books for learning, since they're lightweight and inexpensive, there is just not a single good way to annotate them. I mean, the whole bezel area of my Kindle is covered with annotation graffiti after reading through Hunt's book. I've tried sticky notes, but they fall off the device after a while.

I've been a Vim user for almost 15 years, now. Vim is my one true companion while programming: it has taken me through undergrad CS and grade school, home projects, school projects, research projects, article writing, thesis writing, desperate attempts at system administration and so, so much random noodling. With Vim, I have succeeded and I have failed. In spite of my Ph.D. advisors best intents, I have converted my best research colleague to Vim, which tightened our friendship. Vim is now an extension of my mind and typing hands, and is the first tool I make sure is installed everytime I lay hands on a new system.

Sorry for the thematic disruption, but this is important. Also, sorry about the exclusivity of this rant. Abuse online is disgusting in any and all cases. However, I am personnally moved to action about issues of woman equality and feminism. What is at stake here is not disagreement or dissension to points, ideas or even personalities in online discussion: these can be dealt with, even when they get emotional or personal. No, I am infuriated to tears here about the hatred on exhibit.

I am a naive, idealistic man. Living in Québec, Canada, surrounded with so many examples of women succeding and making their place in what was a man's world 40 years ago, getting respect and equal opportunity in many aspects of their lives, folding all of this goddamned laundry all by myself (please laugh along), I thought ah! we're there. My generation is the first to have women and men stand on equal footing. I even started pleading for less feminism in discussion of gender issues, and try to redirect our efforts towards equity and equality.

In the name of all that is holy and sacred to me, I was so biased. So wrong!

I take it all back. Feminist --- hear this, not equalitarian --- activism is as important today as it was in the time of suffragettes. It might be even more, because the big visible victories have been won, so the revolutions's flag is waving over parliament hill, while the reactionaries have fallen back to waging a guerilla war. Affronts at womens' freedom of speech are marginalized and neglected in the greater public discourse, so as discussed in the linked article, writing in public as a woman requires much more courage that I've ever had to muster.

To conclude, I would like to call upon two groups of people. I have nothing to say to haters, so my first point addresses the indifferent. The fight for basic women rights, such as arguing opinions in public, is not over. Are men threatened of rape or assault every time they take the soap box? No. If it were the case, the outrage would make such a racket that I could not go to sleep at night, which would shake some politics into action. These sorts of threats are happening for women writing in public today. And no, I won't accept that the hating commenters are young temporary imbeciles, so that the problem will go away once the Internet crowd grows up. Young haters grow into old haters. Hate left to itself festers, ferments and blows up in your face the day you lift the lid. Haters must be identified, accused and condemned. Be warned or be sorry.

Way back when in undergrad CS, I had been fascinated with functional programming. The teacher was reviled by everyone but me, because each lesson would put many more questions into your head than it did answer. I am not a very intelligent guy: I get by on sheer perseverance and putting in the work, and although I have good memory and a knack for explaining things, I get few good ideas. In the past five years, all good ideas I've got were about functional languages and programming, which might explain why I did not do so good as an imaging researcher (always dreaming about FP).

(via Instapaper)

This is not Fred Brooks' seminal book, but it riffs along similar lines.

(via Instapaper)

I have been using virtualization since starting up on the job with Arcadia, and I am not going back. I love that machine state can be saved for archiving, reuse or packaged as a product.

The piece I link to here presents a virtualization implementation that makes the virtual machine run in a stealthy fashion with respect to the host machine and other VMs. The tech is introduced as a way to run sensitive computations in a securized environment, which is nice. My take is that it can also be used for nefarious purposes: such a stealthy VM can be implanted from malware and then used as a fully-featured backdoor for snooping, illegal file storage and running payloads.