devdiary #1

First day at work. Sounds like a bit of drama occured over the weekend. Our primary payment provider went down and the team was scrambling to get a half-baked release out the door so that we could bring a second payment provider online.

Got set up with Jira, Confluence, checked out some code from the repos and started poking around. Dev leads were busy putting out fires, so it was mostly “get yourself acquainted” day.

A call for rigorous evidence-based software engineering

Here’s a video recording of a keynote presented by Greg Wilson at CUSEC 2010 entitled “Bits of Evidence: What we actually know about software development and why we believe it’s true”.

My favourites are a few of his closing thoughts.

On the point of research:

The point of research is to find a really good question that is going to move human knowledge forward. There are lots of bad questions out there that are either pointless or too hard to tackle. Finding something that is worth answering and within reach is an art form, and the only way to teach it to you is to have you do it for a few years.

On the purpose of university:

We are trying to teach you how to take over the world because you’re going to have to whether you want it or not, sooner than you think.

On inheriting the world:

I want [my daughter] to inherit a better world from you than you’re going to inherit from us. And the only way to get there is to have you think a little more clearly… [Before you know it,] You’ll be running the world, and the world you’ll be running will be scarier place than the one you’ve got now. You’ll be dealing with all the mess that my generation is leaving behind because we’re to fat and happy to fix it.

For a more comprehensive transcript, check out Joey deVilla’s notes on the Canadian Developer Connection MSDN blog.

Dealing with on-coming pedestrians while cycling

Cyclists generally know how to indicate their directional intentions a vehicle behind. If one wishes to turn left, one raises and extends one’s left arm till it is horizontal. Likewise when one wants to turn right, except one would use one’s right arm.

But how does one indicate to on-coming pedestrian traffic. Raising either arm will result in a most certain confusion. For example, does the raising of one’s arm serve as an instructional “please modify your path of travel and head in that direction”, or is an informational “That’s where I’m headed, please get out of the way”.

This is an uncertainty that is hard to resolve in the average time that stands between a cyclist and an on-coming pedestrian. It often results in said pedestrian freezing in a less than ideal position, requiring the cyclist to perform a high-speed maneuver to the unpleasant soundtrack of said pedestrian spouting expletives.

No, there is a better way.

When approaching a pedestrian, you first attempt to make eye contact. Thanks to evolution and a general love for life, pedestrians are wired to pay very close attention to sudden and quick motions, making this the easiest step. An exception would be a growing number of people who pedestriate around with their eyes glued to their mobile devices. Not to worry, they’re sufficiently distracted, are quick to admit to being in the wrong, and that they should be more attentive to their surroundings while commuting.

Step two. Once you’ve made eye contact, you need to produce a stare that says “Hey you, yes you! I’m talking to you. pay attention now”. This takes a bit of practice because you’re not allowed to mouth the words. All you have are two eyes and a network of facial muscles to get the message across. Don’t care for coming across rude for this instance, matters of safety trumps courtesy.

Step three, after a firm channel of communication has been established, drop the eye contact abruptly and proceed to look assertively towards the route that you intend to take. Do not use your arms, do not re-establish eye contact to see if the pedestrian got the message, do not go in any direction other than the direction that you’ve look-dicated.

Here’s what this sequence of actions should communicate.

  1. Hey you, pay attention to me.
  2. I know you’re there, I’m not going to tell you where to go, but here’s where I’m headed.
  3. Now that you know where I’m headed, you’re free to decide what you’d like to do.

As the bigger commuter and the one who is able to call the shots in this split second relationship, it is the cyclist’s solemn duty to cause as little inconvenience as possible to his/her co-commuting pedestrian friends. The rule of thumb is to pick a path around the pedestrian, and use the above techniques to assure said pedestrian that he/she is not required to change directions.

Day 1: Vim to Emacs

Today’s my first day using Emacs at work. I picked a cognitively easy task (HTML markup editing) to practice on. Being somewhat wired up in Vim, I found myself thinking in terms of Vim operations, and trying to replicate it in Emacs. I know it’s not the most orthodox way of learning/doing Emacs, but it was the only way I knew to get started, and it’s helped me cope so far.

Here is my personal Vim to Emacs conversion table. It’s what I’ve been able to pick up and use fairly proficiently so far, in the order that made most sense to me as I picked the tool up.

“-” in the Vim column means I don’t know how it’s done, rather than Vim not being able to perform it. I expect that all these keys would work on a plain vanilla Emacs 23 install with no configuration or extra scripts added on.

You notice that I’ve used ctrl- and alt- notations directly instead of C- and M- which is the Emacs convention. I’ve done so because that’s what the labels say on the keyboard I use. Also, my brain is already bogged down enough making the cognitive leaps from Vim to Emacs, it doesn’t need to be bothered by M- to alt- and C- to ctrl- translations for now. If you’re not happy with it, go make your own list. Apologies to Mac users, you’ll have to think of alt- as your cmd- key.

Here we go.

 

Moving around

Vim Emacs
Left h ctrl-b (back)
Right l ctrl-f (forward)
Up j ctrl-p (previous)
Down k ctrl-n (next)
Start of Line ^ ctrl-a (alpha)
End of Line $ ctrl-e(end)
Left by a word w alt-f (forward, bigger)
Right by a word b alt-b (back, bigger)
Next paragraph ctrl-] alt-e (end of next line)
Previous paragraph ctrl-[ alt-a (alpha of previous line)
Start of buffer gg alt-<
End of buffer G alt->

 

Basic file and program operations

Vim Emacs
Cancel command esc ctrl-g
Open file :e ctrl-x ctrl-f
Save file :w ctrl-x ctrl-s
Quit :q ctrl-x ctrl-c

 

Making selections

Vim Emacs
Start selection v ctrl-space

 

Undo, Cut, Copy, Paste, Delete

Vim Emacs
Undo u ctrl-_ or ctrl-/
Cut d ctrl-w
Copy y alt-w
Paste p ctrl-y
Cycle through previous copies ctrl-y (once) alt-y (to iterate)
Delete x ctrl-d
Delete word dw (to clipboard) alt-d (no clipboard)
Cut line dd ctrl-a ctrl-k
Copy line yy ctrl-a ctrl-space ctrl-e alt-w
Copy entire buffer gg v G y alt-< ctrl-space alt-> alt-w

 

Move around with search

Vim Emacs
Search forward /[search chars] ctrl-s [search chars]
Search backwards ?[search chars] ctrl-r [search chars] (reverse)
Next result n ctrl-s (after Search forward)
Previous result N ctrl-r (after Search backwards)
Clear search :nohlsearch ret

 

Search and replace

Vim Emacs
Whole document :%s/[search]/[replace]/g alt-x replace-string ret [search] ret[replace]alt-x replace-regex ret [search] ret [replace]
Within selection (make selection):s/[search]/[replace]g (make selection)alt-x replace-string ret [search] ret [replace]

alt-x replace-regex ret [search] ret [replace]

 

Opening new lines

Vim Emacs
Before current line O ctrl-a ctrl-o
After current line o ctrl-e ctrl-o

 

Buffer splits

Vim Emacs
Split top/bottom ctrl-w s ctrl-x 2
Split left/right ctrl-w v ctrl-x 3
Close current split ctrl-w d ctrl-x 0
Close other splits ctrl-w o ctrl-x 1