The things I want to learn

2011 was the year I ...

• Became a Vim "super-user". Now I know what fast means.
• Understood what Unix is and why a command line shell is better.
• Learned how cool git is, and why I should care. 
• Found out Unix man pages presented C functions to the user.   
• Learned Python. It showed me that OOP can be elegant, and why using a generator is better.

Now in 2012 I want to ...

• Make my own Lisp. In Lisp.
• Show that Emacs is more than a text editor.
• Write bash code better than I do C.
• Know enough about Entropy to care about Portage.
• Learn, re-learn all the math I once knew and now forgot.

C++ Testable Design (part 2)

Note: This is Saeid's answer to his own first post. The original discussion happened on LebGeeks. Here's a link to the original thread, in case you want to follow the whole discussion.

My last post tried to address the issue of storing pointers to objects in other objects without having to worry about what gets destroyed first, and who's going to be destroying it.

Writing solid shell scripts

Shell scripting is an extremely powerful force sometimes overlooked by
programmers. I think this is due to the simplistic procedural approach it
presents. Programmers tend to place their trust in complex interpreters
implementing complex paradigms like OOP or functional programming. The success
of Python and Perl for example, in the system administration circles, is
undeniable. Yet you'll often hear old Unix folks chuckle in their beards when
they see the young (well intended) sysadmin defining lengthy classes or
importing heavy modules.

Are we through with the CPU?

A while ago, I complained that no real advance in CPU frequency has been made in 10 years. Adding more cores (virtual ones, no less!) will not drastically improve computing performance on the machine. It will only allow parallel computing (which if used correctly might improve overall performance but won't change the order of magnitude of computing speed).

C++ Testable Design

This article is the first of this blog to be written by a guest author.
Thank you very much Saeid Wazzan (saeidw) for allowing me to publish this.

This is a long post, you might want to grab a cup of coffee before reading.

Recently I've been exposed to Miško Hevery's blog and his Guide to Writing Testable Code.

Specifically, the following guideline: Do not create collaborators in your constructor, but pass them in.

This is meant to make it easy to pass in fake objects to test your class. It's just basic dependency injection, and it helps make code reusable.