Design Cards!

Gamification is a great thing to get fun and motivation into daily routine. When working on Software there can be long discussions about how to solve a problem or which problem needs more attention. Good, that there are principles like KISS or Divide and Rule. If you’re like me, you will have examples of situations, where the discussion was over and you remembered one of this principles. It would have been marvelous to come up with the right thing at the right time! What can we do about this pitty? Right, train these principles and have something physical, reminding, near the discussions! Luckily there is now something to get this problems solved: the Design Cards from Christian Rehn and Matthias Wittum. They are here to help you memorize and remind you the right things at the right time. Lets have a short look at them:

Different types of principles have different colors.
A very nice box and high quality!

I am happy, that we have those cards now in our team and couldn’t be more keen to see the results in the discussions. For now i can recommend the Design cards fully!

What different types of cards do you have? And what are they for?

As always thanks for sharing and reading!

Switch on wordpress debugging

To switch on the wordpress debugging completely, you have to put this code into the wp-config.php (before the “/* That’s all, stop editing! Happy publishing. */”)

// DEBUGGING:
define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_DISPLAY’, true);

Sushi programming

Today i want to share a programming technique with you. My former fellow developer Felix and i tried it and had real good experiences while using it. (Damn, its a long time we didn’t worked together and i miss it!)

We named it sushi programming. I will explain later how we came to this name, the differences to Katas and Pair Programming and where we found pros and cons. Let’s keep things short and dive into the sushi bar!

How to do it?

We have two phases in sushi programming:

  1. the performance and
  2. the discussion

Let’s dive into the performance

The base philosophy behind “Sushi Programming” is to watch, and ONLY watch, note things, which will be discussed later. So we have one developer who is writing code with his normal IDE in the normal way he does this. Lets call him the author.

The other role is the audience, at minimum one other developer. The audience is only watching the author. It is important, that the audience in no circumstance (only a nuclear war or the lunch time should disturb us ;)) talks to each other or the author. No questions like “How did you get your IDE to automagically create this whole file?” or “Why don’t you use this fancy key combination to commit your code?”. The audience just writes remarkable things down. This phase should durate between 15 and 45 minutes. With shorter phases you won’t find enough new good or bad habits, with longer the amount of things will decrease.

In the second phase, called discussion, the audience and the author walk through the notes of the audience. Here all good habits swap around the team and the bad ones get out of the author. Rule of thumb is, that all points should be formulated respectfull and without a personal judgement. So only ask “How did you did that magic trick?” or “Do you know, that you could generate the getters/setters?”. I think it is important to write about this rule, cause it will keep the drama out of the discussion. The aim of this technique is to spread the given knowledge as much as possible in the team and increase everyones work quality and speed.

Differences to other techniques

Pair Programming

In pair programming you are allowed to talk all the time. This gives the software developers a better understanding of each other and the solution they build. With suhi programming we are aiming only at the habits of each other. Therefore the silence in the first phase is installed.

Peer Reviews

Peer reviews are either with one guy or with multiple guys. So whenever a piece of code, a software or UI design or an architecture is watched by a group of people, we can call it a peer review. The aim is slightly different from sushi programming: in peer reviews we want to improve the code at all. We should not mind who wrote the code, we just want to see, if it fits our quality standards and our understanding.

Code Katas

Code Katas are a great wy to learn things as a group. We sit together and work through a rigid plan of steps without thinking too deep while doing. The aim is to get a new habit into our muscle memory. For instance it is perfect to get into the Test Driven Development circle, if you never before used it. Or a new framework into your brain. This said, the aim is clearly close to sushi programming: train the new things.

Why the crazy name “Sushi Programming”?

I’m not sure where i got this information from and if it is true: i heard, if you want to become a sushi cook, you have to spend a certain time as a dish washer and as a waiter. This phase around your aimed work should give you the respect for the other activities and let you soak in the spirit of a sushi restaurant, like how to treat the food and the guests. This should beware you of doing the biggest mistakes in the everyday worklife over and over again. You’re filled with best practices before you even ram your first knive in the first fish. Soaking the spirit, for the learning developers, and spreading the spirit, for the master developers is a healthy habit in my eyes.

Pros and cons

  • the flow of the author isn’t broke by discussions – a big plus to get more knowledge moving from one to another individual
  • the author and the audience find more hidden treasures (a.k.a. IDE shortcuts or bad habits) in the everyday routines of the other than by Pair Programming
  • the team members get a deeper understanding of the used techniques
  • the team members get kwowing each other better, because they see each other finding solutions (hopefully they reflect their own too and thereby know themself better)
  • the team members train discussing techniques and routines without hurting personal feelings, which will be good for the team spirit
  • after a time only the knowledge of the team is spreaded, there is a “we don’t learn anthing new” if you do it too often, without developers from the outside of the team

Conclusion

For me it was a really useful habit to sometimes sushi program. Our team knowledge went up fast and it helped me and the others! So my recommendation is: try it yourself and have fun!

Did you liked the article or the idea? Do you feel the urge to propose a better name? Do you know, if it is part of becoming a suhsi cook to be dish washer and waiter first? Did you tried it yourself with some colleagues? What were your experiences? Than please leave a comment!

Thanks for reading and sharing!

Reading the GET parameters in JavaScript

Today i want to write about the situation, when you need a GET parameter in the JavaScript part, and only there, of your website. As sayed, you will never touch or even read the parameter in the PHP or Ruby part of your code, cause it is only there to get something done in the frontend. Exempli gratia you want to switch to the second jquery tab of the actual site. Lets say you want to do this by the GET parameter “tab”. You add the “?tab=0” (as an IT guy i start to count at zero ;)) to your URL. Now you only have to read this parameter and switch to the correct tab. Therefore a GET parameter reading function was my first idea. You call the function and get a nice key-value-object back, so that you can work with it further. Enough said, lets dive into the code:

function getGETParameters() {
    var parameterString = document.location.search.replace('?','');
    var parametersAsString = parameterString.split('&');

    var parameters = {};

    jQuery.each(parametersAsString, function (index, parameter) {
        var parts = parameter.split('=');

        parameters[decodeURIComponent(parts[0])] = decodeURIComponent(parts[1]);
    });

    return parameters;
}

Do you like this post or the code? Let some kind words here 🙂

If not, let me know what could be improved!

You want me to coach you with your programming or software development skills? Write me a direct email to: i@sebastianbauer.name

You want to hire me? Write a direct email too 🙂

Short guide to set up an apache virtual host on ubuntu 14.04

Knowing, that there are very good and detailed guides for virtual host creation, i decided to have a shortest possible how to on this topic here.
Assuming, that you have installed and running your apache in Ubuntu 14.04 Trusty Tahr, then these are the steps to create a new virtual host:

  • assure, that the directory, where your virtual host should to “live” in, exists (e.g. “/var/www/awesome.local”)
  • assure, that the permissions of your document root are set to 755
  • create an apache virtual host configuration file (copy the default config file)
    • sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/awesome.local
    • fill it with your configuration (with the editor of your choice)
  • <VirtualHost *:80>
        ServerAdmin admin@awesome.local
        ServerName awesome.local
        ServerAlias www.awesome.local
        DocumentRoot /var/www/awesome.local
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
    </VirtualHost>
  • enable the virtual host configuration:
    sudo a2ensite awesome.local
  • restart apache:
    sudo service apache2 restart
  • set up your local /etc/hosts:
    • open the file “etc/hosts”
    • add the line
      127.0.0.1 awesome.local www.awesome.local
  • open http://awesome.local and/or http://www.awesome.local in your browser and check, if everything went well (if you see an empty page, check, that there is something in your document root ;))

SVN export script

If you ever wanted to export some svn repository from and clean it from some things like the tests or other helper scripts, i have a nice little helper script.

Download it or copy paste it:

#!/bin/bash

path_export="EXPORTPATH"
remove=( "/export.sh" )


rm -r --force $path_export
svn export . $path_export


for i in "${remove[@]}"
do
    echo $i
    rm -r --force $path_export$i
done

Add any files or directories you want to delete from the exported version to the fourth line like this:

remove=( "export.sh" "another_file.txt" "a_directory" )

Let me know, if you have any suggestions, improvements or if you just like it in the comments.

Little GREPpings

Sometimes it is great to have the little help of grep. I’m often asked for some hints, so here are my favorite tiny commands:

grep -lir 'PATTERN' *

where the l stands for “give me only the file names”, i for “case insensitive”, r for recursive and the asterisk for all files (use *.xml or other wildcards to only search in certain files).

grep -lir 'PATTERN' * | grep -v "svn"

to search all files, except the svn files (hopefully there is no other filename with svn in it 😉 ). The | is the pipe operator.

I hope that they are useful and help you to grep around!

Language Smells

Watching this video about the future of JavaScript, i liked one cite “The human compiler, at work.” from Paul Graham so much, that i googled it and stumbled upon Are Design Patterns Missing Language Features. To outline this great thoughts: if we wish to extract or already have extracted a design pattern, it is no longer a code smell, but a language smell. In other words not the programmer or developer cares not enough of the code design, but the language designer.

My first thoughts to this thesis: any language designer should carefully look at a statistic on how often each design pattern is used in the most famous open source projects (or even better proprietary one too) and think about getting them into the next language version. On the other hand some patterns have different realizations. For example the transition function of the state pattern could be implemented by entry-/exit-functions in each concrete state or as a function moveTo(oldState, newState) in the state machine. Both implementations have pros and cons, but if a language designer chooses one for the language, it would be a pain if a programmer/developer needs the other one. If both versions are implemented in the language, things get complexer. This would be contrary the design goal of simple languages.

Glad i found this inspiring thoughts! Whats your opinion?

SME Server – Dansguardian installation script

I wrote a script to install a Dansguardian filter on a SME Server 7.5:
here it is!

Download it by typing

wget http://www.sebastianbauer.name/files/servers/sme/sme_dansguardian_setup.sh

to your server shell as root.

Then make it executable by

chmod +x sme_dansguardian_setup.sh

and run it by

./sme_dansguardian_setup.sh

… thats it ;)!

If you have any hints, critiques or improvements, let me know it and write a comment or an email!

Security script: ubuntu server automatic check of services

Looking at this post on about perl i got the idea to write my own script to check if all services are running.

Here it is:
check_services.py

There are only a few things you have to do:

  • change the path to the script in the script (necessary cause we use cron)
  • put it in your crontab:
    • “crontab -e” as root
    • set your local PATH variable (look it up in the shell with “echo $PATH”)
    • * * * * * /PATH_TO_YOUR_SCRIPT/check_services.py
  • think about how you observe the logfile (maybe you want an email or a notification at login)

If you like the script, see any points i missed or have problems: let me know it and write a comment!