Saturday, 30 April 2011

Reverse Incremental Search in Bash

I learned a new trick this week. Reverse incremental search through bash history using the up key. This blog post outlines it nicely:

http://codeinthehole.com/archives/17-The-most-important-command-line-tip-incremental-history-searching-with-.inputrc.html


Using these bindings, I can type 'git', then hit the up-arrow to search back through all the recent git commands I've used. This is a really quick way to improve productivity at the command line.

For future reference, just in case the above linked blog entry disappears.

In ~/.inputrc:
"\e[A": history-search-backward
"\e[B": history-search-forward
"\e[C": forward-char
"\e[D": backward-char
In ~/.bashrc:
export HISTSIZE=1000000
export HISTFILESIZE=1000000000

Thursday, 28 April 2011

Make it Work First...

==========
Pragmatic Thinking and Learning (Neill Alexander) (Hunt)
- Highlight Loc. 1277-83  | Added on Saturday, April 23, 2011, 10:06 AM

Author Anne Lamott is an advocate of purposefully creating a shitty first draft. That is, it's better to complete a shitty first draft than to never complete a perfect one. In her book Bird by Bird: Some Instructions on Writing and Life, Lamott explains the dangers of perfectionism: "Perfectionism is the voice of the oppressor, the enemy of the people. It will keep you cramped and insane your whole life, and it is the main obstacle between you and a shitty first draft. I think perfectionism is based on the obsessive belief that if you run carefully enough, hitting each stepping-stone just right, you won't have to die. The truth is that you will die anyway and that a lot of people who aren't even looking at their feet are going to do a whole lot better than you, and have a lot more fun while they're doing it."
==========

Make it work first, then make it better.

Tuesday, 26 April 2011

Deliberate Practice

==========
Pragmatic Thinking and Learning (Neill Alexander) (Hunt)
- Highlight Loc. 1067-69  | Added on Friday, April 08, 2011, 08:16 PM

Skills and abilities that you constantly use and constantly practice will begin to dominate, and more of your brain will become wired for those purposes. At the same time, lesser-used skills will lose ground. "Use it or lose it" is perfectly accurate in this case, because your brain will dedicate more resources to whatever you are doing the most.
==========
Pragmatic Thinking and Learning (Neill Alexander) (Hunt)
- Highlight Loc. 1070-73  | Added on Friday, April 08, 2011, 08:16 PM

Perhaps this is why musicians practice scales incessantly; it's sort of like refreshing dynamic RAM. Want to be a better coder? Practice coding more. Engage in deliberate, focused practice as described in the sidebar (here…). Want to learn a foreign language? Immerse yourself in it. Speak it all the time. Think in it. Your brain will soon catch on and adapt itself to better facilitate this new usage.
==========

Over the last couple of years the majority of my personal programming time has gone into 2 largish applications; Sponge and Meditation Helper. The main aim of the first project was to write something substantial in Clojure, and the second to do the same for Android. Both were fun projects to work on. However, I have now decided to change my approach.

Instead of embarking on another application, I am instead using my personal programming time to practice scales. I am writing toy classes to learn apis, libraries etc that I haven't had much experience with, or that I want to learn in more depth. I want to improve as a programmer, and the only way to do that is practice, practice, practice.

Sunday, 24 April 2011

Unknown Unknowns

==========
Pragmatic Thinking and Learning (Neill Alexander) (Hunt)
- Highlight Loc. 376-89  | Added on Thursday, April 07, 2011, 07:58 AM

When you are not very skilled in some area, you are more likely to think you're actually pretty expert at it. In the paper "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments" [AUOIHDIROOILTIS] , psychologists Kruger and Dunning relate the unfortunate story of a would-be thief who robbed a bank in broad daylight. He was incredulous at his prompt arrest, because he was under the impression that wearing lemon juice on your face would make you invisible to security cameras. The "lemon juice man" never suspected that his hypothesis was, er, suspect. This lack of accurate self-assessment is referred to as second-order incompetence, that is, the condition of being unskilled and unaware of it. This condition is a huge problem in software development, because many programmers and managers aren't aware that better methods and practices even exist. I've met many younger programmers (one to five years of experience) who never have been on a successful project. They have already succumbed to the notion that a normal project should be painful and should fail. Charles Darwin pegged it when he said, "Ignorance more frequently begets confidence than does knowledge." The converse seems to be true as well; once you truly become an expert, you become painfully aware of just how little you really know.
==========

Friday, 22 April 2011

Baby Steps

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 1850-55  | Added on Monday, April 04, 2011, 07:24 AM

When you're driving on a long trip, does it make sense to hold the wheel firmly in one position, stare straight ahead, and then just floor the gas for a couple of hours? Of course not. You have to steer. You have to be constantly aware of traffic. You have to check your gas gauge. You have to stop for fuel, food, and other necessities, and so on.[30] Don't code for hours, or even minutes, without stopping to make sure you're on the right path---by testing what you produce. Instead, code in short increments. You'll find that coding in increments helps you refine and structure the code as you go along. The code is less likely to become complicated or messy; you build the code based on the on-going feedback from writing and testing in increments.
==========

At university, there were people who used to code and code and code and code and code and code and code and code...

Then they'd hit the compile button and wonder why they had so many errors. A lot of them thought programming was 'too hard' because of this.

Wednesday, 20 April 2011

Commenting Code is like Eating Peas

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 1786-88  | Added on Monday, April 04, 2011, 07:19 AM

Code will always be read many more times than written, so the little extra effort that is required to document your code when writing it will pay you back handsomely in the end.
==========

When I was a kid, I used to leave my vegetables until last. At the end of my dinner I'd be sitting there with an enormous mound of peas, with my mother breathing down my neck, demanding that they be finished before I could leave the table.

I hated peas.

When I was at university learning how to program, there were people in my class who used to leave commenting code until the end. They used to write their entire computer program, then go back at the end and add comments, because they'd lose marks if they didn't provide any.

They hated writing comments.

What I didn't understand as a kid was that peas aren't so bad when you eat them in combination with the rest of your food. In fact, now I think they are delicious. I wouldn't like to eat a giant mound of them by themselves though.

Monday, 18 April 2011

ORM is a Solved Problem

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 864-66  | Added on Friday, April 01, 2011, 08:47 AM

For instance, if you have a hankering to develop your own persistence layer, remember Ted Neward's remark that "object-relational mapping is the Vietnam of computer science." You can spend more time and effort building only what you need to build for your application---the domain or application-specific stuff.
==========

This made me laugh, because I built a persistence layer for a project, then realized after the fact that I should just have used Hibernate. It was a valuable lesson.

The thing is, at one point during the project I was talking to the project manager who expressed his concern at the length of time it was taking to complete the work. I said to him, "Don't worry, I'm not trying to re-implement Hibernate!". Shortly after that conversation I realized that I was, in fact, trying to re-implement Hibernate. It all started very naively - I implemented a solution using Spring JDBC, and then saw an opportunity to extract some higher level abstractions. That process continued to the point that I found myself writing a DSL that would enable me to express the various object relationships, and map them to the database structure.

Hmmm. Object relational mapping you say. That rings a bell.

Object-relational mapping is a solved problem. There are multiple solutions out there. Pick one and use that. Even if you need to learn it from scratch, it will still be quicker than writing your own version.

Saturday, 16 April 2011

Rooting for the Underdog

I installed Cyanogen 7 onto my HTC Desire this week. Along the way I changed the partition table to free up some space for applications. I now have a phone running the very latest version of Android, and space for plenty more apps.

The ability to customize my phone in this way is very important to me. I will never buy a phone that does not allow me to have root access, or that prevents me from installing ROMs with mechanisms such as signed bootloaders. I didn't know about any of this stuff when I jumped from the good ship Apple (see Operation Bad Apple). I bought an HTC Desire because it seemed like the best Android phone at the time. Had I known about custom ROMs and rooting, I probably would have gone for the Nexus One, because for a while it wasn't possible to get full root access to the Desire. It was only when Alpharev came along that this became possible.

Which is why this link is so important - http://unrevoked.com/rootwiki/doku.php/public/root_friendly. It's a list of phones that are amenable to rooting. You'll notice all the newer HTC phones appear in the "poor choices" category. That's because HTC have started signing the boot partition, making it impossible to install custom ROMs. In my eyes, in the space of a year, HTC have move from being the plucky underdogs who need to be supported. to the dicks that need to be ignored. Although I am very impressed with my HTC Desire, there is no way I will be buying any of the newer HTC phones.

Meanwhile, Sony Ericsson have announced that all their new phones in the Xperia range will have unlockable bootloaders. They even provide a web-site to enable you to unlock the bootloader (see http://unlockbootloader.sonyericsson.com/). This is fantastic news, and is likely to win Sony Ericsson a lot of hardcore Android fans. You'll note that the new Sony phones appear in the "root friendly" section of the unrevoked list.

Hopefully this is a sign of things to come, and more manufacturers will follow Sony's lead. If I were in the market for a new phone right now, I'd probably go for the Sony Arc. This kind of enlightened behaviour from phone manufacturers needs to be encouraged.

Context Matters

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 373-75  | Added on Friday, April 01, 2011, 07:53 AM

There is no absolute best, only better. Despite the popularity of the term, there is no such thing as "best practices," only better practices in a particular situation.
==========

In General Semantics we talk about non-elementalism i.e. don't split verbally what cannot be split in actuality. The classic example is talking about 'space' and 'time' as opposed to space-time. Another example might be 'body' and 'mind' as opposed to the organism-as-a-whole.

Everything has a context and must be evaluated in relation to that context.

Thursday, 14 April 2011

Speak Up!

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 329-32  | Added on Friday, April 01, 2011, 07:49 AM

We all have some good ideas and some bad ideas, and everyone on the team needs to feel free to express them. Even if your idea is not fully taken up, it may help shape the solution. Don't be afraid of being criticized. Remember, everyone who became an expert started somewhere. In the words of Les Brown, "You don't have to be great to get started, but you have to get started to be great."
==========

Even if the idea that you come up with isn't adopted, it may trigger someone else in the room to come up with a better idea. And that may in turn trigger someone else. Inspiration comes from the funniest places.

I've read a few Edward de Bono books in my time where he talks about using nonsense words to trigger lateral thinking e.g. foo a bike with square wheels might lead someone to think about active suspension in a bike.

Tuesday, 12 April 2011

Dealing with Problems

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 206-11  | Added on Thursday, March 31, 2011, 09:02 AM

You may not believe this, but not everyone always has the outcome of the project as their top priority. Not even you. Consider your first, "default" reaction when a problem arises. You might inadvertently fuel the problem by saying things that will complicate things further, by casting blame, or by making people feel defensive. Instead, take the high road, and ask, "What can I do to solve this or make it better?" In an agile team, the focus is on outcomes. You want to focus on fixing the problem, instead of affixing the blame. Blame doesn't fix bugs.

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 221-24  | Added on Thursday, March 31, 2011, 09:03 AM

On an agile team, the situation is different. If you go to an agile team member with a complaint, you'll hear, "OK, what can I do to help you with this?" Instead of brooding over the problem, they'll direct their efforts toward solving it. Their motive is clear; it's the outcome that's important, not the credit, the blame, or the ongoing intellectual superiority contest.
==========

Sunday, 10 April 2011

Compass

I read about the Compass Project in the book Modular Java. When I next need to add search functionality to a Java application I will definitely be checking it out.

Friday, 8 April 2011

Over Learning

==========
Pomodoro Technique Illustrated (Neill Alexander) (Noteberg)
- Highlight Loc. 646-56  | Added on Sunday, March 27, 2011, 12:49 PM

Never switch activities in the middle of a Pomodoro. If you finish an activity halfway through a Pomodoro, spend the rest of the time over-learning. For example, if I finish early, I review what I have done, I repeat what I have learned, I see whether I can enhance my work, or I note new conclusions on paper---until the kitchen timer rings. Over-learning is when we continue to study or practice even after attaining proficiency. Malcolm Gladwell argues that this is necessary if we want to be really good at something: "Once a musician has enough ability to get into a top music school, the thing that distinguishes one performer from another is how hard he or she works. That's it. And what's more, the people at the very top don't work just harder or even much harder than everyone else. They work much, much harder.".[32] So, you're not allowed to impulsively switch activities in the middle of a Pomodoro. In fact, just having the option to switch in the middle is a recurring disturbance. You can't just stop in the middle of a Pomodoro and take a break either. Then you will lose the rhythm. And since the stopped Pomodoro was shorter, it will not be compatible---in terms of tracking---with other Pomodori.
==========

I hadn't heard or read the phrase 'over-learning' prior to reading this book. It makes sense, and is something I am looking to adopt to improve my technical / programming skills.

The Pomodoro Technique is, 1 week later, proving to be a useful addition to my personal productivity.

Wednesday, 6 April 2011

Double Trouble

==========
Backgammon For Dummies (Chris Bray)
- Highlight on Page 78 | Loc. 989-91  | Added on Monday, March 14, 2011, 07:33 AM

In a game you may make up to 30 decisions about how to move your checkers, but you’re likely to make only two or three doubling of decisions, so taking the time to get them right is worth it. As Paul Magriel said, in his 1976 book Backgammon, ‘Good checker play will never compensate for serious errors of judgement in doubling.’
==========
Backgammon For Dummies (Chris Bray)
- Highlight on Page 99 | Loc. 1245-49  | Added on Monday, March 14, 2011, 08:06 AM

One of the keys to winning backgammon is to double when you have a strong threat, not after you’ve executed that threat perfectly. Remember, your opponent has to have some chance of winning in order to take your double. Winning just one point when you may have won four (via a doubled gammon) won’t make you rich, or leave you satisfied. Of course, sometimes you double and your opponent turns the game around and wins it. You just develop the knack of living with that possibility. If certainty is what you seek, backgammon is probably not for you. If, however, you want excitement, you’re playing the right game!
==========

I have come to the conclusion that backgammon is a solved problem. For any particular roll of a dice there is a statistically best move you can make. Neural net based backgammon bots have proved this. However, you can play a match making the best moves all the way and still lose due to bad dice luck.

So I'm putting my short-lived online backgammon career behind me.

Monday, 4 April 2011

Do it Properly

==========
Code Complete (Steve McConnell)
- Highlight Loc. 27111-19  | Added on Thursday, February 24, 2011, 07:19 AM

Making code readable is not an optional part of the development process, and favoring write-time convenience over read-time convenience is a false economy. You should go to the effort of writing good code, which you can do once, rather than the effort of reading bad code, which you'd have to do again and again. "What if I'm just writing code for myself? Why should I make it readable?" Because a week or two from now you're going to be working on another program and think, "Hey! I already wrote this class last week. I'll just drop in my old tested, debugged code and save some time." If the code isn't readable, good luck! The idea of writing unreadable code because you're the only person working on a project sets a dangerous precedent. Your mother used to say, "What if your face froze in that expression?" And your dad used to say, "You play how you practice." Habits affect all your work; you can't turn them on and off at will, so be sure that what you're doing is something you want to become a habit. A professional programmer writes readable code, period.
==========

This comes back to integrity. You do something because it is the right thing to do, not because you're afraid of being found out. I have to admit, there is some code in the Android application that I wrote that isn't too pretty. I justified it to myself by saying that I was the only person looking at the code, therefore it didn't matter if it was a bit ugly. Of course, I ended up cursing myself when I returned to make a change or add a new feature!

It's amazing how quickly you forget about code that you have written. That's why it's important to do it properly the first time (with comments) even if you are the only person that will be looking at the code.

I write this not to convince you, dear reader, but to convince myself. You, I am sure, write perfect code every time.

Saturday, 2 April 2011

Pomodroido Tasker Integration

Last weekend I read Pomodoro Technique Illustrated and decided to give it a try. A while back I adopted Getting Things Done to organize my life. GTD is great for organizing and remembering tasks, but doesn't help with actually doing the work! Procrastination is still a problem. Pomodoro helps in that respect because it uses the idea of time-boxing to create artificial deadlines to help focus the mind. Combining GTD and Pomodoro seems to me to be a very promising personal productivity approach.

Anyway, since I have an Android phone, I had a look around for an application that would help me adopt the Pomodoro technique. Pomodroido fits the bill nicely.

The thing that really impressed me with the application was the integration with Tasker. Tasker is one of those apps that I've had on my phone for a long time, but never really found a use for. It's the swiss army knife of applications - you can do almost anything with it. I just never bothered learning how to use it properly.

When I bought Pomodroido I compared the free version with the pro version. The pro version promised Tasker integration. Intrigued, I bought it to try it out. And when I tried it out I realized I'd missed a trick with my own application, Meditation Helper. You see, Pomodroido triggers an event when a Pomodoro starts, and another when it ends. Tasker knows about this event, and therefore you can change the settings of your phone during a Pomodoro.

Here's what I did.
  • When a Pomodoro starts I change the display timeout to 10 seconds, disable the screen lock, and switch off the radio. This means that during a Pomodoro I will not be disturbed by telephone calls, I can switch the screen on to see how much time is left in the Pomodoro without having to unlock the phone, and the screen will switch off again after 10 seconds.
  • When a Pomodoro ends I revert these changes back to their defaults, and also switch the screen on as a further indication to me that the Pomodoro has ended.
This is really clever. In Mediation Helper I added options to enable airplane mode during a meditation, to disable the screen lock etc. Instead of doing this, I could simply have fired an event when the meditation session started, then fired another when it ended, and allowed the user to customize their experience using Tasker.

Although I have put any further development on Meditation Helper to one side for the meantime, I have added 'Tasker Integration' as one of the main new features that I will introduce in the next version.

Update: here are links to the Tasker profiles I created.

Friday, 1 April 2011

Estimation

==========
Code Complete (Steve McConnell)
- Highlight Loc. 26756-72  | Added on Wednesday, February 23, 2011, 07:44 AM

If management applies pressure to change your estimate, realize that ultimately the decision whether to do a project rests with management: "Look. This is how much it's going to cost. I can't say whether it's worth this price to the company—that's your job. But I can tell you how long it takes to develop a piece of software—that's my job. I can't ‘negotiate’ how long it will take; that's like negotiating how many feet are in a mile. You can't negotiate laws of nature. We can, however, negotiate other aspects of the project that affect the schedule and then reestimate the schedule. We can eliminate features, reduce performance, develop the project in increments, or use fewer people and a longer schedule or more people and a shorter schedule." One of the scariest exchanges I've ever heard was at a lecture on managing software projects. The speaker was the author of a best-selling software-project-management book. A member of the audience asked, "What do you do if management asks for an estimate and you know that if you give them an accurate estimate they'll say it's too high and decide not to do the project?" The speaker responded that that was one of those tricky areas in which you had to get management to buy into the project by underestimating it. He said that once they'd invested in the first part of the project, they'd see it through to the end. Wrong answer! Management is responsible for the big-picture issues of running a company. If a certain software capability is worth $250K to a company and you estimate it will cost $750K to develop, the company shouldn't develop the software. It's management's responsibility to make such judgments. When the speaker advocated lying about the project's cost, telling management it would cost less than it really would, he advocated covertly stealing management's authority. If you think a project is interesting, breaks important new ground for the company, or provides valuable training, say so. Management can weigh those factors, too. But tricking management into making the wrong decision could literally cost the company hundreds of thousands of dollars. If it costs you your job, you'll have gotten what you deserve.
==========

And once you have given them your honest estimate on how long a piece of work will take, pray that they have heard of the 'Mythical Man Month'.

Estimation is a difficult thing to get right. The best advice I ever read about providing software estimates was to use suitable units of estimation. If you think something will take 3 days, estimate 'a week'. Chances are your 3 day estimate is hopelessly optimistic anyway.

And always keep in mind Hofstader's law, even though it will make no difference:
"Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law."