Write Test Cases First!

Whether or not you have the luxury of having your work tested by a tester it is essential to write test cases for the code you are about to write before starting to write it. Writing tests first yourself dramatically changes the way a implementation approached.

When I say tests, I do not mean unit tests. Unit tests define the API interfaces that will be defined and the expected results from each programming construct. Tests are clear definitions of what is expected for a range of inputs, what behavior should not happen, and what should happen if the application is used in invalid ways. An example test case for a registration form:

Unit tests are not enough for defining the outcome of an application. Unit tests are limited in their ability to test actual functionality as they will be used by the end-user.

Defining Tests First Avoids Cognitive Bias

After you have spent dozens of hours building an application a programmer is usually blinded to the inputs and possible usages of his application which can cause it to break.

This is not a character flaw in people. By design us humans cannot effectively attempt to break what we just created because we have a tendency to fall in love with our creation. We will end up owning the code personally in a subconscious level. It is psychologically impossible to want to break something you put a great deal of effort in making. You are naturally inclined to take the routes that are likely to show that the application you built is working. You are cognitively blinded from finding ways to break the software you made.

Defining Tests First Saves Time and Money

When you start writing an application without the full understanding of the application you tend to design as you code. This is a very bad practice and should be avoided. You may even get more ideas on implementation of that tiny little feature. This scope creep is a addictive test-develop viscious loop that is going to cost a lot of time.

Highlighting Text

To highlight text take the cursor to the start or end of the text where you want to start highlighting and then press Ctrl+Space. Release the keys then move the cursor around to cover the text that should be copied or cut.

Operations on highlighted text

Your productivty and the quality of your code and even your ability to think in a higher level of abstraction can be aided or hindered by the text editor you use.

Emacs: Extension of Your Hand

Emacs is extensible. Power users have customized it so much that they’ve turned the editor into an extension of their own hands. Some have extended it so well as to run email clients, a browser, chat clients, IRC clients all within emacs.

Emacs is famous for being the hacker’s text editor – the one that is used by the most technically savvy, most productive programmers.

Learning Emacs

I am a beginner to using Emacs myself.  You don’t sit and learn emacs. Emacs is NOT intuitive. You can’t get how to do even the most fundamental tasks like copying, pasting, cutting just by looking at the interface. You won’t even know how to exit the program when you start it! Most people just give up completely when encountering such problems. I did too when I first opened emacs to find out what that old dude with a beard who came to my college  said he created.

The most authoritative resource on the topic at the time of this writing seems to be EmacsWiki. It is a very very badly organized and written website that is barely understandable for a beginner. I instead opted to purchase Peepcode’s screencast on emacs. Anything that saves me hours of time later is damn good investment. I highly recommend buying it.

The video is around 50 minutes or so long and it is jam packed with tips and tricks. I was only able to get upto 20 minutes before needing to stop and jot down everything that was said. I’m planning on revisiting the screencast, learn another 10 minutes of tips and tricks and then apply them the following month.

Conclusion

Emacs is a text editor that you gradually mold to your preference. There are few hard and fast rules like in other text editor where EVERYTHING is pre-defined.

I have been making WordPress themes and plugins for over 2 years now. I feel like I have reached a stage where there is absolutely nothing in WordPress I cannot figure out on my own and cannot handle on my own. I am not yet there where I can generate complex plugins in a matter of minutes.

WordPress Theme Development: My First Theme

I started out by creating a simple WordPress theme. It wasn’t a very good one. It was just decent enough. I tried to submit it to the WordPress.org repository. I kept getting error messages saying the theme is missing this, that, this and that. I eventually gave up on distributing the theme. It wasn’t a very good one but it was very very minimal. Didn’t think lot of people would have downloaded and used it.

I called the theme “Simple News”.

WordPress Plugin Development: WP Autoresponder

Creating WP Autoresponder taught me a lot about WordPress. The development of the plugin touched upon a good huge chunk of the WordPress plugin API – categories, posts, cron jobs, widgets, user access limitation and so on. During the course of developing the plugin I was able to muddle through and figure out where to look for answers.

I was under the impression that the core of WordPress was some voodoo that nobody touched. It is only worked upon by the most daring souls. But then I soon realized that whenever I asked a question the developers at wp-hackers simply read the source code in the relevant file. And it wasn’t voodoo magic like I thought it will be. The code was pretty well commented, no scary identifiers like EventModelAdaptermMarshallInterface or something.  From that day forward, I completely stopped posting in all major mailing lists and forums.

After that I moved to Ubuntu. Now I just grep -r the source code for what I want. Almost in all cases I find what I want.