7 simple rules of conduct for software developers

I often refer to the adaptation of the boy scout rule for software development which says that as a software developer you should aim to ”always check a module in cleaner than when you checked it out” .

Continuing to be inspired by the boy scouts and their scout law, here are 7 simple rules that every software developer should aim to live by.

  1. A software developer always tries to write as clean code as possible and respects the code written by others.
  2. A software developer acts honestly and reliably.
  3. A software developer is friendly and helpful towards others.
  4. A software developer shows respect and is a good coworker.
  5. A software developer faces difficult times with a cheerful mood.
  6. A software developer gets to know the code base and cherishes it.
  7. A software developer feels responsible for his code and that of his coworkers.

How to create a structured .gitignore file

If you are working with git as your version control system on your projects then you are probably aware of the .gitignore file.

Not heard about the .gitignore file before? Then I recommend to read up on what the .gitignore file does!

Most often the .gitignore file organically grows beyond control as the project evolves and you end up with a bunch unstructured files and folders that should not be tracked. You end up asking your self why a file or folder is ignored.
If you wish to regain control over the .gitignore file then generate it at gitignore.io. Gitignore.io which is designed create useful .gitignore files for your project. It will not be able to handle your project specific files and folders but you will be able to sort out operating system, IDE and programming language specific files that should be ignored.

WordPress Themes vs Plugins and the single responsibility principle

Have you every thought about what should go into a WordPress theme and what should go into a WordPress plugin? This is a question that I for sometime have been thinking reading about.

The WordPress codex has the following definitions:

”Fundamentally, the WordPress Theme system is a way to ”skin” your weblog. Yet, it is more than just a ”skin.” Skinning your site implies that only the design is changed. WordPress Themes can provide much more control over the look and presentation of the material on your website.” — http://codex.wordpress.org/Theme

”Plugins are tools to extend the functionality of WordPress. …. Plugins offer custom functions and features so that each user can tailor their site to their specific needs.” — http://codex.wordpress.org/Plugins

Based on these definitions, we can say that a theme is a about adding a look and feel / design / skin to the site and it can also extend functionality, while a plugin is only about extending functionality.

We could say the theme concept in some way embrace the plugin concept.

For as long as you never need to share functionality between several themes you could include the functionality in the theme it self and there is no need to create a plugin.

As soon as you need to share the functionality between two themes then you would need to create a separate plugin for that functionality.

But, creating a plugin is simple. Separating the design of the site and the functionality of the site is enforcing the single responsibility principle (SRP) pattern to your code base. The theme would be responsible for the design and the plugin would be responsible for the functionality.

It is more future proof to separate these concerns then not separating them since you most probably will create undesired dependencies and assumptions in the code base between the concerns if you don’t separate the the concerns. This would make it hard to separate them in the future.

What do you think? Is a good idea to separate the design and functionality into a theme and plugin respectively even if it is currently not needed? Leave a comment and let us know!

Use Vagrant to setup and manage your development environment

When there are more then one person working on developing a application there is a need to make sure every  one is using the same revisions off all the tools that are used to produce the application.

One way is to write list with all tools and their revisions and special settings and then make sure that every one updates their environment accordingly.

However, there is a lot of manual and error prone work involved to make sure that this always followed by all involved in the project.

Enter Vagrant! This is simple and easy to use tool that allows you to in a simple way create, maintain and distribute a development environment running on Virtual Box, VMware or even AWS. You can even version control the configuration, e.g. using git!

By using simple shell scripts you can provision your environment to make sure that everyone are using the same tools etc.

Go a head and have a look at it! Let us know what you think!

Do you have a good flow in GIT?

I have previously talked about a successful git branching model by Vincent Driessen which I find to be very useful as starting point for creating a branching model that fits your needs.

Now there is a cool little tool called gitflow which is a collection of Git extensions to provide high-level repository operations that match the branching model by Vincent Driessen.

You can also go one step further and install git-flow-completion to help you to achieve git-flow completion nirvana. This requires that you install a great little tool called bash git completion.

Happy GIT-ing!

How to install PEAR on Mac OS X

Needing to use PEAR I stumbled upon a simple tutorial to install PEAR on Mac OS X by Jason McCreary.

Simply follow the three steps and you’ll be up and running!

  1. Download PEAR
  2. Configure and Install PEAR
  3. Verify PEAR


Run the following bash commands

curl -O http://pear.php.net/go-pear.phar
sudo php -d detect_unicode=0 go-pear.phar

Configure and Install

  1. Set the ”Installation base ($prefix)” to ”/usr/local/pear”.
    • Type 1 and press return.
    • Enter: /usr/local/pear
  2. Set the ”Binaries directory” to ”/usr/local/bin”
    • Type 4 and press return.
    • Enter: /usr/local/bin
  3. Finish the configuration by pressing return twice.


By running any pear command you should be able to verify if it works or not.


$ pear version
PEAR Version: 1.9.4
PHP Version: 5.3.15
Zend Engine Version: 2.3.0

Creating a single file WordPress plugin in 2 steps

To create a single file plugin in WordPress is really simple. Following the steps below should leave you with a single file plugin that is ready to be filled with valuable functionality.

  1. Create a new PHP file with a name derived from your chosen Plugin name and store it in the wp-content/plugins directory, e.g. ”wp-content/plugins/FooBar.php”.
  2. Within the PHP file, add the standard plugin information header. Without the standard plugin information header the plugin will never be activated and will never run. The absolute minimum information needed is the plugin name.
Plugin Name: The FooBar Plugin

That is it! You should now be able to find the plugin on the Plugin management screen. Filling the plugin with valuable functionality is a different story and is left for you to do your self.

Visit the WordPress codex to learn more about writing a WordPress plugin!

4 core company statements for your business

Do you run a business?

If so, there are 4 statements that you should be aware of and preferably have defined for your business.

These statements are…

  • the vision statement, a description of what your organization wants to become
  • the mission statement, a description of why your organization currently exists
  • a statement of values, a description of core beliefs your organization follows
  • and a slogan, a short, catchy and simple phrase identifying your organization

Do you have all of these statements? Maybe some? Let us know! Leave a comment!

Agile vs Iterative developement

Developing new (software) products in an agile manner has become more or less de-facto standard these days. Most of us can agree to that, right?

But are your really sure that you are doing agile development?

Maybe you are not.

Maybe you are only working in an iterative environment thinking that it must be agile.

Maybe you are working with the devil in disguise!

It is time to do some self-evaluation!

I surfed into a article called ”Should we choose Agile or Iterative development?” by Sandy Mamoli which nicely outlines the following six points that differ between agile and iterative development.

  • Mini-waterfall is still waterfall
  • Agile is iterative AND incremental
  • Agile helps “building the right thing” through customer involvement
  • Agile delivers high quality
  • Agile is open to incorporating feedback and learnings
  • Agile fosters communication and collaboration

Head over and read entire article to get a better and deeper understand to if you are doing agile or iterative development!