Productivity Tip #2

I recently realized that I'm actually two very different people. I'm one person at night, and another when the alarm clock goes off. My night-self, let us call him Mr. Gogo, is tired, but his brain is functioning pretty well. My night self makes all kinds of plans for the next day. And then, my morning-self, Mr. Gozen, screws everything up. So, my second productivity tip is:

Tip #2 - Kill Mr. Gozen

I don't mean to promote violence or anything, it's just that Gozen is an asshole. He has only one thing on his mind - going back to sleep. That just plain sucks. I want to do things, and he ruins everything. So I've decided to terminate him.

For the past week, my alarm clock has been going off at the ungodly hour of 5:58 am. I get up and start looking for the damn clock, usually thinking of nothing else but going back to sleep. By the time I find it, I'm pretty much awake, and Gozen is dying. You see, much like the Wicked Witch of the West (WWW) melts in water, my morning self melts in wakefulness. And I must say that life is much better without him.

Every morning, I do the dishes while I finish waking up, ignoring the last feeble screams of Gozen, then stretch and exercise, drink something warm, and head off to the computer to work for an hour on one of my hobby projects (I promise to reveal what they are soon). Then I wake the wife with a kiss, and on I go to work. It's great.

Now, most of you are probably worried that getting up in the morning will be bad because you'll lose sleep. Well, nothing can be further from the truth. While I do sleep less, I don't lose any sleep. If the left hand side of the equation is waking up early, than the right hand side must be to go to sleep early. Well, no, No, NO! That's were the beauty of this whole habit is - my evening self has some ability for cognitive action. And when he gets tired, he says - off to sleep, because being tired after a long day means that that's what you need to do. On the other hand, being tired after 6-8 hours of sleep means you are not thinking properly, Gozen has taken control.

The beauty of the system is that everything balances up. If you don't get enough sleep, you'll go to sleep earlier. But you will never oversleep anymore - you'll get exactly the amount of sleep that your body needs.

I find I'm more productive in the morning, even though I work pretty well at 2-3 am as well. It's just that I have plenty of peace and quite to do what I want.

Why Not to Write Shell Scripts

Don't write shell script. Not in bash, and not in any other shell. There are two very simple reasons for this:

1. They are not portable.
2. They are hard to read.

Nowadays, we have a much better option - write those same shell-scripts in a cross-platform scripting language, such as Python or Perl. These languages are much easier to read than some devilish combination of awk, sed and a cryptic syntax. Well, Python is. But Perl can be readable too, contrary to common wisdom, if a bit of care is taken when writing the script. Sure, most shell scripts use some really neat tricks & hacks, but let me quote Brian Kernighan:

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

Brian Kernighan

(If you follow the link, you'd see Mr. Kernighan has a hand or two in the scripting pot himself. Oh well...)

In my experience, even the most temporary script ends up expanding beyond its original intention, and thus needs to be modified and maintained. Shell scripts are just not the right tools anymore.


Further Reading

1. Python, Subprocess and Multiple Arguments
2. Programming with VI
   

Productivity Tip #1

I lead a pretty busy life. Besides working full-time, I'm taking a very intensive university course in Japanese, I try to blog weekly, exercise, read lots of books, work on hobby programming projects, do the dishes, spend quality time with my wife each and every day, go hiking every month and occasionally have some semblance of a social life. It's not much, and I won't give up any of these things, at least until we get a dishwasher. I do, however, need to better utilize my time so that I can get more things done.

This post will hopefully kick off a series on what I learn as I try and be more productive, or, more precisely, more efficient. I don't intend for it to be anything like those "self help" blogs, I actually kind of hate those. I want these posts to be about concrete, down-to-earth tips that I find useful. So, without further ado:

Tip #1 - Listen to Podcasts

Most people know this already. For a programmer, I'm pretty caveman like in my knowledge of the latest technological hype. I'm usually several years late when in comes to the latest thing. But although I've known about podcasts for months, I could never find the time to listen to them.

This where this tip gets productivity related. Podcasts are great for doing something useful in those "dead" moments we have each day. Most people listen to podcasts on their way to work. For me, however, it takes less than 5 minutes to drive to work each morning, so it's not really an option. The solution is obvious, although it took me ages to find it out - I listen to podcasts in the gym.

I think exercising regularly is very important, but that will have to wait for its own blog post. Listening to podcasts while exercises has been really great for me, and I can finally catch up on all those StackOverflow podcasts.

Programming Editors

I've used a wide range of programming editors throughout my life. From the glorious copy con and QBasic of the DOS days, through the Turbo C of my teenage years, including the emacs of my college days and the Source Insight and Eclipse of my professional career, one thing is clear:

I was a terrible IDE user

This means that I rarely used, or even knew of, more than 5% of the features of each IDE - excluding (maybe) the glorious copy con editor, of course. I can still remember the shock at watching someone else debug code by using a debugger (!!!). Turns out there was one right inside Turbo C all along.

And then came along The Pragmatic Programmer, which is a phenomenal book. One of the things they recommend is to choose a text editor and learn how to use it. Learn how to use it real well. Which is why, I think, having a learning curve that's a bit steep is a good thing.

In college, after the first year the emacs police got off of our backs, and we could use eclipse. Many people did just that. I didn't - I had been forced to endure emacs for too long, and had to pay too many hours to learn the likes of "Ctrl+X 2", that I just didn't want to learn how to do it all over again (I still don't know how to do it in eclipse). This was, of course, a stupid idea. But to rationalize why everyone had red squiggly lines below their errors as they typed and I didn't, I had to learn emacs just bit more in depth. Or at least spend hours talking to the emacs psychiatrist, which eclipse doesn't have. Take that eclipse!

The problem was that I never really liked emacs. It can do horrible thing to your keyboard's CTRL key. And I never liked it's MS-Word philosophy of putting together one huge application (or OS) instead of many small programs which can be bundled together as you see fit. And getting a decent copy outside of unix-land is always an annoyance, even on my Mac, which is a citizen of unix-land, kind-of. I still hate programs that are several mega-bytes overweight. That's why I'm switching to vi.

So far, I really, really like vi. The whole normal mode is great for touch-typing - no more reaching out for the arrow keys (or the CTRL key). It's a nice programming editor, though I still have a lot to learn. My main IDE is still Eclipse, and although its C++ support is sketchy, it will probably take a while before I'm proficient enough in vi to give eclipse up completely.

Above all, I still miss Source Insight, now that I'm on a linux machine. It's probably the best editor for a large code base. It's one of the most ugly editors, but when most of the code is already written, it can't be beat. But now I mostly write new code, so it's not too bad. I'm good with vi.

But I still don't know how you say Ctrl+X 2 in vi...

edit: it's ":split filename"

Source Code Highlighting - In Blogger!

There are a great many posts on how to post syntax highlighted code in blogger. I can't really understand why google doesn't have a ready made solution in place.

I think I've found a solution I'm comfortable with:

1. Convert the code to html (":TOhtml" in vi)
   
2. In the Compose tab, type: <pre> </pre>
   
3. Paste you code between the tags
   
4. Publish

That's it - no installation, not too much hassle.

For extra credit, you can modify the css for <pre> sections.

If you want line numbers:

1. ":set nu" - show line numbers in vi
   
2. ":TOhtml" - convert to html
   
3. ":set nonu" - remove line numbers for easy copy & paste (or, use Ctrl-V)

1  #include <stdio.h>
2
3  int main( int argc, char *argv[] ) {
4      printf("Hello World!\n");
5      return 0;
6  }

All that's left is to find a good color scheme for vi.

edit: Ars Pythonica has added that in your .vimrc file, you can add: "let html_use_css = 1" to include css in the output.

Thanks to:

1. Eli Bendersky - for the pre trick
2. FluidBlog - For the vi TOHtml trick
   

Project Euler

I've just stumbled upon Project Euler. It's a nice little site with mathematical puzzles to be solved using a computer. For example, this first problem is to find the sum of all the natural numbers who are multiples of either 3 or 5, and are below 1000.

There are hundreds of such puzzles, most of them more challenging, so I'll allow myself to post the answer to this first problem:

#!/usr/local/bin/python
sum = 0
for number in range(1, 1000):
  if number % 3 == 0 or number % 5 == 0:
          sum += number
print sum

And what is great is that once you solve a problem, you get access to a pdf file with an overview of the problem and efficient solutions. The above solution I wrote, which is quite naive, can be computed in O(1), had I first used a pencil and paper as my IDE, and not Vi. Can you see how?

Programming with Vi

This page will serve as a place to store my notes on using vi as a programming editor. And when I mean vi, I really mean vim, but these days I think it's pretty safe to assume vi=vim. I'm placing these notes on the web in the hopes that it may help other programmers new to vi, as I currently am. I will update this page with information I find useful.

The Two Modes

The most important concept to understand about vi is that it has two separate modes - command mode and insertion mode. This originally struck me as rather cumbersome, and I found my self working nearly completely in insertion mode. You can get along like this. You can also write C++ code in Microsoft Word. There's a really good reason for this separation - because command mode is separate, the commands are much simpler. For example, navigating around the document is really easy:

Navigation

j - Move one row up
k - Move one row down
h - Move one column left
l - Move one column right
w - Move to the start of the next word
b - Move to the start of the previous word
e - Move to the end of the next word
0 - Move to the beginning of the line
$ - Move to the end of the line
1G - Move to the beginning of the file
G - Move to the end of the file
% - Move cursor to matching bracket

The jkhl commands may seem quite stupid. There are arrow keys after all. But if you know how to touch type, you'll find that this really improves your productivity. It takes a bit getting used to, but it really pays off, in my opinion.

Like many commands, you can add a number before a navigation, so that 4j moves you four rows down.

Undo & Redo

u - undo last change
Ctrl+R - redo

Copy & Paste

v - enter visual selection mode. Moving the cursor will select text for later actions, such as:
y - yanks the selected text. aka, copy
yy - yanks the current line
p - paste text

Multiple Windows

:split filename - split a window and open filename
:vsplit filename - split a window and open filename

Running Shell Commands

:!make - executes a shell command, such as make
:r !ls - executes a shell command and pastes the output into the file

Search & Replace

/expression - Searches for expression
:%s/expression/newtext/g - Searches for expression and replaces it with newtext

Configuring The Environment

:set nu - shows the line numbers
:set nonu - don't show the line numbers
:colorscheme - changes the color scheme
:set sw=4 - sets the tab size to be 4 spaces

All these commands can be placed in ~/.vimrc

References

1. Yolinux is always a good source
2. Run vimtutor for a good hands-on tutorial
   

Current Reading List

This page contains books I'm currently reading and the books I recommend, though I will probably not update it too diligently (last update-30'th of December, 2011). I have also stopped buying the dead-tree variety of books, and read on my iPad. Finally, note that reading is not enough, you also have to do things.

Current Reading List
Release It / Michael T. Nygard

---

Books I Recommend

The Timeless Way of Building / Christopher Alexander

I still can't relay say that I finished this book. I still need to find a quite afternoon to finish it. But, it is an excellent book, there is much Zen in it.

The 7 Habits of Highly Effective People / Stephen R. Covey

I think it's a good book. I haven't read many self-help book, and I generally dislike the entire genre. The 7 habits, however, is a serious book that doesn't promise any shortcuts - it doesn't promise easy solutions to anything, and I like that. I disagree with a couple of things, but it's a good read.

Peopleware: Productive Projects and Teams / Tom DeMarco & Timothy Lister

This is book is recommended by many people, and now by myself as well. It's a great book about managing people who get payed to think. It's a great read even for regular programmers like myself. It's a small book with plenty of fun stories. Highly recommended.

Don't Make Me Think: A Common Sense Approach to Web Usability / Steve Krug
This is a book about designing web sites to be usable. It's a very quick read - large fonts, plenty of pictures. Nonetheless, I think it's worth the money. A day after finishing the book I happened to show my mom the blog of our honeymoon, and I immediately noticed the many flaws I made when designing the blog.

Kafka on the Shore / Haruki Murakami
This is the second book by Murakami-san I've read. Like the first one (The Wind-Up Bird Chronicle), it is quite surrealistic. I can say that I really liked it, even though I disagreed with many of the overly-simplistic pacifistic messages Murakami tried to convey. Next I need to read Norwegian Wood (done).

Learning Japanese

I started studying Japanese a couple of months ago. I decided to register for an intensive course at the local university. There were other places to go to, such as the Japanese embassy, private tutors, specialized companies or just learn it by myself. I'm not too sure why I chose to study in a university.

Ages ago (2003), when I was contemplating what to study, I narrowed it down to three options - Physics, Computer-Science and Japanese (as part of a degree in Far-East Studies). And then I decided the choice was too hard, so I'd take two of the three. The final choice was to study Physics and CS, with the hope of squeezing a course in Japanese somewhere in between. I can't say I'm sorry, even though I never did manage to take that Japanese course.

After finishing my degree, it was only logical that I finally study Japanese. And I guess I decided to do that in the university because that was my frame of mind back then. I did consider the other options, but either they were too expensive, or they were not rigorous enough for my taste. In any case, now that the semester is nearly over, I can say I'm quite please with my choice.

I must say that the learning Japanese is quite different from learning Physics. The entire atmosphere is different. For example, classes are much more interactive, but that may be due to the fact that few people want to study Japanese, but a great many want to study Computer Science (for $ome $trange rea$on). In any case, the biggest difference is that there's a lot of memorizing required when learning a new language. Except some courses in mathematics, I really didn't have to do much memorizing during my studies in the exact sciences.

I've always had a love-hate relationship with memorization. My teachers in high-school kept on saying that it's important to understand concepts, and not to memorize them, and I've spent most of my life agreeing with them. I no longer do. I think that memorization is an important step in the path to understanding. It is also important in itself. For example, any physicist should remember what Planck's constant equals, as well as the value of Boltzmann's constant. Remembering important equations is also very important, because it allows you to solve various problems without breaking your chain of thought by opening a book (or Wikipedia).

My father knows pretty much the entire Hebrew bible by heart. He's not religious, far from it. It's just that his teachers didn't have any problems with forcing people to memorize passages. And I think his teachers had a good point. My teachers also had a good point, but that's how life is.

So, back to Japanese. I've spent the last couple of months having to memorize stuff for the first time in my life (at least to such an extent). I wasn't prepared for it. I tried various techniques. At first, I wrote each new word in a tiny notebook which I intended to take with me everywhere. That didn't workout, mostly because I didn't take it with me everywhere I went (it had a spiral binding, quite uncomfortable in the pocket). I still think it's a good enough idea in most cases, and it certainly works out quite well for my brother, who gave me the idea. My current invention goes something like this:

1. Buy a bunch of cards
2. Write the English/Hebrew term on one side.
3. Write the Japanese translation on the other side.
4. Add some useful information (for verbs, for example, if it's いちだん or ごだん)

Yes, it may very well be the breakthrough in language study that millions of people have been waiting for. Oh, wait. Someone thought of it before me. Damn.

Both of the methods I tried are okay, but that's pretty much all I can say about them. Of course, I don't rely solely on them. I still think that the best way to learn is by doing, and, as a corollary, the best way to learn to read is by writing. So I write a lot, which is important in Japanese because their alphabet is a mess. A beautiful mess, but a mess none-the-less. The bottom line, however, is that all these methods fall under the category of "memorize by repetition". It's a good, proven method. It just takes up a lot of time, time which I simply don't have (when am I supposed to write that game in Python?).

There has to be a better way. I've started looking into the various tricks of memorization. In high-school, we once got a visit from some sales-person for a private course in improving learning skills, or something like it. She taught us how to remember all the different offices in the government in a couple of minutes. She did this by telling us a story, and I still remember it more than 10 years later. It's based on a simple trick, that is the basis of most memorization techniques.

The basic concept is that we have an associative memory, and we remember the extraordinary. So, to remember a list of things, you just make up some bizarre story that connects the various items. The more extraordinary, the better, especially if it involves as many senses as possible. There are many methods that take this basic idea much further, but I don't know enough about them right now. It's one of the things I've decided I want to learn (yes, yet another one).

And yet, I'm not sure these techniques are good enough for Japanese. There are thousands of "letters", each with several different pronunciations, depending on the context. Most letters have a dozen or more strokes to remember. I just don't know of a better way to remember them than by endless repetition.

So, although it's been a fun post, it's one of the longer ones I've written, and I have to go memorize some kanjis (料利 is especially annoying).

I also have to improve my English writing skills sometime.

Further Reading

1. Learning Japanese - Memorization: includes many new lessons I've learned since writing this article.