Ever heard of Bumblebee? Well I thought it was about this guy:

Apparently it wasn’t, in this case.

In fact, I still don’t even know what piece of software it is, but I do know about one of its most famous commits on github now.

This commit is very small, yet makes a very big difference for the user…

If you want to have a laugh see the commit yourself, and then all the comments, they are hilarous.

Ok, one teaser:

Still reading…?

I modified the script a tiny bit (color preferences + added __git_ps1 to detect branch) and would like to share you what I’ve got.

This is the complete script I use now, copy & paste if you like.

The result looks like this:

# This shows the git branch of the current directory
function __git_ps1 () {
git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
}

function __git_dirty {
git diff --quiet HEAD &>/dev/null
[ $? == 1 ] && echo " (changes!)"
}

function __git_branch {
__git_ps1 " %s"
}

function __my_rvm_ruby_version {
local gemset=$(echo $GEM_HOME | awk -F'@' '{print $2}')
[ "$gemset" != "" ] && gemset="@$gemset"
local version=$(echo $MY_RUBY_HOME | awk -F'-' '{print $2}')
[ "$version" == "1.8.7" ] && version=""
local full="$version$gemset"
[ "$full" != "" ] && echo "$full "
}

bash_prompt() {
local NONE="\[\033[0m\]"    # unsets color to term's fg color

# regular colors
local K="\[\033[0;30m\]"    # black
local R="\[\033[0;31m\]"    # red
local G="\[\033[0;32m\]"    # green
local Y="\[\033[0;33m\]"    # yellow
local B="\[\033[0;34m\]"    # blue
local M="\[\033[0;35m\]"    # magenta
local C="\[\033[0;36m\]"    # cyan
local W="\[\033[0;37m\]"    # white

# emphasized (bolded) colors
local EMK="\[\033[1;30m\]"
local EMR="\[\033[1;31m\]"
local EMG="\[\033[1;32m\]"
local EMY="\[\033[1;33m\]"
local EMB="\[\033[1;34m\]"
local EMM="\[\033[1;35m\]"
local EMC="\[\033[1;36m\]"
local EMW="\[\033[1;37m\]"

# background colors
local BGK="\[\033[40m\]"
local BGR="\[\033[41m\]"
local BGG="\[\033[42m\]"
local BGY="\[\033[43m\]"
local BGB="\[\033[44m\]"
local BGM="\[\033[45m\]"
local BGC="\[\033[46m\]"
local BGW="\[\033[47m\]"

local UC=$W                 # user's color
[ $UID -eq "0" ] && UC=$R   # root's color

PS1="$M\$(__my_rvm_ruby_version)$W\h$W:$EMG\w$EMC\$(__git_branch)$EMW\$(__git_dirty)${NONE} $ "
}

bash_prompt
unset bash_prompt

And so I found Stratagus and Wargus.

With Stratagus as engine, Wargus as “MOD” and with the original Warcraft 2 CD you can re-live Warcraft 2 again on your machine.

On Windows you should be able to install this without any problems, installers are provided and these work just fine. However, on a Mac you might be in some hassle to get this working. In fact, there is no official support as none of the authors run a Mac. Basically this means people with Macs had to figure out how to do this. After some time of googling I got Stratagus compiling and working with a Wargus game I already created on Windows.

Fortunately someone at github already made a version that should work on Mac OS X. Combined with a tutorial I found elsewhere I got it to compile. I can play Wargus now on my Mac!

For completeness sake I have combined the steps I have taken (and also forked Stratagus) so you can use that version. Don’t credit me for making Stratagus compile on the Mac though, as I did not make the nescesary changes in the makefile or code.

Install Xcode (from App store) & Install command line tools from Xcode

in Xcode, go to preferences, tab "Downloads" -> " Components" -> Command Line Tools

• - The command line tools should have installed git and svn for you, try them out:

hit "svn --version", and "git --version" in your terminal.
If they are not installed, you could install them via homebrew (brew install git && brew install svn) (after you installed Homebrew of course)

Install homebrew

ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go

Installing required dependencies

I have installed the following dependencies with homebrew like this:

brew install cmake libogg libvorbis theora libpng zlib libmikmod sqlite3 doxygen

Compile and build tolua

Go to your projects dir

git clone https://github.com/LuaDist/toluapp.git

cd toluaapp

mkdir build

cd build

cmake -G "Unix Makefiles"

make && sudo make install

Git clone stratagus

Determine where you want to checkout stratagus, ie in your ~/projects, then:

git clone https://github.com/stefanhendriks/stratagus

Compile it

cd stratagus
mkdir build
cd build
cmake -G "Unix Makefiles" ..
make

Now you should be able to run a stratagus game. Since I already created Wargus by using Windows, I copied this over to my mac (and put it in ~/projects/Wargus). Then I ran stratagus as:

./stratagus -d ~/projects/wargus/

A known issue I have is that on startup the screen looks as if it is drawing with a weird offset (ie too much out of screen at the upper left). By simply changing resolution this goes away. Don’t know why yet, but since we have the code now and we can compile, we might as well try to fix it some day!

Personally I’d like to see a better AI for wargus, especially since I like to play Skirmish games.

I hope this guide helped you get it to work on your mac. Please share your experiences in the comments section.

Currently, the most recent version is Allegro 5 which breaks with the Allegro 4 API and makes it impossible to convert from Allegro 4 to 5 (atleast for D2TM). From a nostalgic perspective I wanted to try Allegro 5 and on my new system which runs Mac OS X 10.8.

In this post I will describe how you can get Allegro 5 working on Mac OS X, under XCode 4.5. I had great help from the documentation provided, and hopefully this post is sufficient for you. If not, I would suggest to checkout this documentation, or this one.

Rough steps

To give you an idea what we’re going to do, here is the installation in very rough form:

1. - Installing required software
2. - Installing dependencies to make Allegro more useful and to get it compiling (cmake, etc)
3. - Compiling Allegro for Xcode, installing it and making sure the Frameworks are installed in /Library/Frameworks
4. - Setting up an Xcode project to test if Allegro works

Prerequisites (Installing required software)

Requirements for getting started, if you already have this installed you can skip the prerequisites

• Mac OS X 10.8
• Xcode 4.5 (with command line tools)
• Git/SVN
• Homebrew

Before we can start, we need to have installed some prerequisites. Which are Xcode (you can get this from the App store), git and svn. I have used homebrew to install dependencies, you can also use Macports but I do not have any experience with this. (as far as I can tell it should behave quite the same). My advice would be to install these in the following order:

• - Xcode
• - Install command line tools from Xcode

in Xcode, go to preferences, tab "Downloads" -> " Components" -> Command Line Tools

• - Install homebrew

ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go

• - The command line tools should have installed git and svn for you, try them out:

hit "svn --version", and "git --version" in your terminal.
If they are not installed, you could install them via homebrew (brew install git && brew install svn)

Installing required dependencies

As suggested by the Allegro 5 wiki we need to install dependencies. The wiki explains how to do it with Macports, but since I am using Homebrew, you need to do it like this:

brew install cmake

brew install zlib
brew install freetype
brew install jpeg
brew install libogg
brew install physfs
brew install libpng
brew install flac
brew install ffmpeg

The first one is cmake, which we will need to build Allegro. Cmake is required to create the OS specific build steps to compile Allegro, without it we cannot proceed. The other dependencies are used to make Allegro more useful. When we prepare to build Allegro in the next section, cmake will check what dependencies are installed. The more it finds, the more features it will provide in Allegro 5.

Note, you might get  a warning about zlib. If thats the case, you can ignore it.

Compiling Allegro for Xcode, and making sure the Frameworks are in /Library/Frameworks

Once we have everything set up, this step is relatively easy. Since we are going to compile it for Xcode, we basically are doing the same as the Allegro wiki is saying.

Open a terminal, and go (cd) to a directory where you want to get allegro’s sources. For example: ~/projects

cd ~/projects

We now need to fetch the sourcecode of Allegro, which we can do by using git clone. At this moment of writing, Allegro 5.1 is the current version. Our git clone command looks like this:

git clone git://git.code.sf.net/p/alleg/allegro

This takes a little while. Once git is done, you have Allegro’s sources in ~/projects/allegro.

Now: cd to allegro, and create a new directory called “build”, then go into that directory.

cd allegro
mkdir build
cd build

The first step is to let cmake (the first dependency we installed) prepare our build, then build it and then install it. This is done by the following:

cmake -G Xcode -DWANT_FRAMEWORKS=1 - ..
xcodebuild
sudo xcodebuild install

The last step requires you to enter your password.

I found that the last step did not work for me, in order to fix that I did:

cd lib/RelWithDebInfo

Within here all Frameworks are built. Now copy them over to your /Library/Frameworks directory with sudo. With this:

sudo cp -r *.* /Library/Frameworks/

If you don’t want to copy this over to your Library/Frameworks directory, then you need to remember the path to these frameworks as we are going to need them later.

Setting up an Xcode project and see it all working

This section is a copy & paste + improvement from this page.

• Start XCode, create a new empty project (Other->Empty)
  
• Add a Cocoa Application target to the project, let’s call it MyGame. (Click your project, then the + button at the bottom saying Add target, then Mac OSX->Application->Cocoa.)
  
• Select the MyGame target, go to the Build Phases tab and add a new Copy Files Build Phase (+ button down right).
  • Select Frameworks from the dropdown
  • Leave Subpath blank
  • We leave this build phase empty for now, we will need it later.
    
• Select the Build Settings tab then:
  • Note: You can change display from Basic to All at the top and use the search box to locate the following settings
  • Change Header Search Paths to (just copy & paste):

    /Library/Frameworks/Allegro-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroMain-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroAcodec-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroAudio-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroColor-5.1.framework/Versions/Current/Header /Library/Frameworks/AllegroDialog-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroFont-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroImage-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroPhysfs-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroMemfile-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroPrimitives-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroTTF-5.1.framework/Versions/Current/Headers
    

    (yes, it is intended to be one line)
    

  •  
  • In the targets Build Settings specify the Framework Search Paths as/Library/Frameworks.
  • • This is needed to have cross-platform code (#include <allegro5/allegro.h> working – otherwise paths like using #include <Allegro-5.0/allegro5/allegro> would work without changing the search path)
    • If you use another location, one way to save on typing is to double click the input field, then navigate to the Headers folder in each framework and drag it into the xcode input list
  • Delete Prefix Header (Edit->Delete)
    • You can of course use your own prefix headers – but the default Cocoa one will only work with objective C projects that’s why we remove it, assuming MyGame is a cross-platform C/C++ project
• Add all the Allegro frameworks as follows (this can be done in many ways, a group just keeps things tidy):
  • Select the Summary tab
  • Click the + button under Linked Frameworks and Libraries and add all the Allegro frameworks
    • In case they are not listed use the Add Other button and navigate to /Library/Frameworks to find them
  • Go to the Build Phases tab, then in the list to the left select all the Allegro frameworks and drag them to the Copy Files entry which we added before
    
    
  • Select all the frameworks again and this time drag them to the Frameworks group to the left (just to have things more tidy)
• Don’t forget to remove the created source files under MyGame and add your own source code instead (note the main.m in Supporting Files for example)
  • Create a new main.c
    
  • Give it the following content:

#include <allegro5/allegro.h>

int main(int argc, char **argv) {
   al_init();
   al_create_display(640, 480);
   al_clear_to_color(al_map_rgb_f(1, 1, 0));
   al_flip_display();
   al_rest(5.0);
   return 0;
}

Caveats

• Cannot find header files: Make sure you have set the header paths correctly. Try to copy the one line given above, into your header paths (remove old ones first). If that does not work. Try adding them one by one, to make it easier to copy/paste I have provided them for you separately as well:

  /Library/Frameworks/Allegro-5.1.framework/Versions/Current/Headers
  /Library/Frameworks/AllegroMain-5.1.framework/Versions/Current/Headers
  /Library/Frameworks/AllegroAcodec-5.1.framework/Versions/Current/Headers
  /Library/Frameworks/AllegroAudio-5.1.framework/Versions/Current/Headers
  /Library/Frameworks/AllegroColor-5.1.framework/Versions/Current/Header
  /Library/Frameworks/AllegroDialog-5.1.framework/Versions/Current/Headers
  /Library/Frameworks/AllegroFont-5.1.framework/Versions/Current/Headers
  /Library/Frameworks/AllegroImage-5.1.framework/Versions/Current/Headers
  /Library/Frameworks/AllegroPhysfs-5.1.framework/Versions/Current/Headers
  /Library/Frameworks/AllegroMemfile-5.1.framework/Versions/Current/Headers
  /Library/Frameworks/AllegroPrimitives-5.1.framework/Versions/Current/Headers
  /Library/Frameworks/AllegroTTF-5.1.framework/Versions/Current/Headers
  
  

• Compiling works fine, linking does not work: Make sure you have specified the Framework Search Paths as/Library/Frameworks.

And so far I love it there.

One of the things I now work in is OS X (10.8.2). I am programming in Ruby using RubyMine. I think RubyMine is great (especially since I am coming from IntelliJ as a Java programmer).

However, one of the things that bugged me was path variables not picking up in RubyMine.

From terminal all my stuff works great. Ie, rake spec, rails, etc. No problem.

However it seems RubyMine does not launch with the same path variables set as you terminal does. Also, the suggestions for does not work in OS X 10.8.

There where two ways for me to get around this problem. One is to simply launch RubyMine from terminal:

open -a /Applications/RubyMine.app/

Because you launch it from the terminal itself, RubyMine will get all the environment settings from there.

Another way was to edit the default settings in RubyMine for (in this case) rSpec:

And set the environmental path with value:

/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:$PATH

Now all rspec tests will use this environment path and run fine.

In this blog post I’d like to talk about a subtle introduction of coupling: when you introduce a factory method.

Consider you have an interesting piece of code, and this piece of code has quite a lot of properties:

class Person {
	private String firstName;
	private String lastName;
	// .. more properties here

	public void subcribeTo(Subscription subscription) {
		// do something interesting here
	}

}

The problem is, because of the amount of properties and other dependencies, we’d like to simplify its creation by introducing a Factory method. In this case we are building a web application, so we take the Request as input to read the parameters:

class Person {
	private String firstName;
	private String lastName;
	// .. more properties here

	public static Person create(HttpServletRequest request, .. more arguments here .. ) {
		this.firstName = request.getParameter("firstName");
		// .. read more properties
		// .. set up dependencies, etc.
	}

	public void subcribeTo(Subscription subscription) {
		// do something interesting here
	}

}

In the code that uses Person, it becomes easier to construct the Person and we’re happy with that. However, we have introduced coupling on several levels:

• We construct the object with specific parameters in the create method. If we want to create from different parameters, we cannot use it. There is a coupling between the parameters and the properties.
• The object is constructed using a Request object. We cannot now move the class to an application that does not use the web. A person has nothing to do with a request, it is just convenience that we put the factory method in the Person class. There is a coupling between the code of Person and the dependency delivering the Request object.

There are several ways to deal with this. But lets start with the last reason of coupling. It is easy to fix this coupling by creating a Factory class within your web application. From there you can generate the Person object out of a request. The Person class has no create method anymore, and thus is not tightly coupled to a Request class. The newly created Factory however is coupled to the Request, which is fine as it is meant to convert Requests into Person objects. Hence we could even name it that way:

class Person {
	private String firstName;
	private String lastName;
	// .. more properties here

	Person(String firstName, String lastName, ...) {
		this.firstName = firstName;
		this.lastName = lastName;
		// ...
	}


	public void subcribeTo(Subscription subscription) {
		// do something interesting here
	}

}

class PersonFromRequestFactory {

	// .. dependencies here 

	public Person create(HttpServletRequest request) {
		Person person = new Person(request.getParameter("firstName"), )		
		// .. read more properties
		// .. set up dependencies in Person, etc.
	}

}

Once we have this Factory, you can take it a step further:
If you have different kind of request parameters to create the same object you could create different methods in the new Factory:

class PersonFromRequestFactory {

	// .. dependencies here 

	public Person createFromRegistrationForm(HttpServletRequest request) {
		Person person = new Person(request.getParameter("firstName"), )		
		// .. read more properties
		// .. set up dependencies in Person, etc.
	}


	public Person createFromSubscriptionForm(HttpServletRequest request) {
		Person person = new Person(request.getParameter("givenName"), )		
		// .. read more properties
		// .. set up dependencies in Person, etc.
	}


}

You could also create a Parameter object and go from there. For instance, if your web application uses Spring, you could wire your request parameters to an object (called “Form binding“) automagically and use that object as input in your Factory. This way it is type safe:

class PersonFromRequestFactory {

	// .. dependencies here 

	public Person create(RegistrationForm form) {
		Person person = new Person(form.getFirstName(), ...)		
		// .. read more properties
		// .. set up dependencies in Person, etc.
	}


	public Person createFromSubscriptionForm(SubscriptionForm form) {
		Person person = new Person(form.getGivenName(), )		
		// .. read more properties
		// .. set up dependencies in Person, etc.
	}


}

But how do you test all this?
Did you notice the Person has private fields, and no get/set methods? The only way to set the fields is using the Person constructor. How do you test the correct construction of this Person class from the request? Since we are not able to read the properties, we have to use other ways to test that code. I’ll cover that in the next blog post.

To get it working on Linux I simply redid the steps I did back then. I’ve tested the results on Linux and also on Windows, with success!

If you are interested, then you can grab the natives here; and the JARs from here.

(or just simply clone dune2themaker4j and get it all in one go)

I came to Amsterdam Amstel train station, to pick up Corey Haines who I had asked if he wanted to meet the local community in Amsterdam and have some fun coding.

After I first introduced myself to a complete stranger (I swear he really looked like Corey Haines )…
I then walked to (the real and smiling) Corey Haines and got us to the car to get to our location.

It was a fun evening coding. Around 10 people came and we mainly focussed on coding. I want to share one of the highlighting moments (to me) of that evening.

A Randori.

I never did a Randori before, but I really liked this form of group programming, so let me share this with you. Perhaps you might want to try it yourself with a group of developers you know.

So what is a Randori?
If I had to put it in one sentence: A Randori is a pair-group-rotating-programming session.

What we did
We did a Kata, but not all by ourselves… we did it all together.

Doing a Kata on your own is fun.
Doing a Kata with multiple people surely would be more fun right?

In this case we did the LED Display Kata.

But how did we do it as a group? Basically it works like this:
You have one person controlling the computer (called the Driver). Another person, called the Navigator, has a say in what should be made (design-wise). The Driver and the Navigator form a pair.

The rest of the people (the Audience) has a role as well:
When doing the Kata (in TDD of course), while you are in the red phase (test fails), the Audience must remain silent while the Driver and Navigator try to get the test to green (test passes). The Driver and Navigator may talk and work it out. Once the test is green, the refactor phase starts, the Audience is allowed to bring in suggestions. Want to shut up the audience? Write a failing test

After a few minutes (in our case 5 minutes) you switch roles:
Navigator becomes Driver
Driver becomes Audience member
someone from the Audience becomes Driver

That’s a whole ‘session’. Reset the timer, and continue with the Kata where the previous pair left off.

Since you cannot write new code without a failing test, the Navigator is obliged to write (or let the Driver write to be more exact) a failing test first.

To avoid major rewrites of the code, there is a restriction to the Navigator. He may only refactor big changes after introducing an amount of new tests. Only when the tests pass, the Navigator may introduce major design changes.

So why is this fun?

It is fun for several reasons:
- It resembles a real world problem, where you have to work with existing code (and you can’t change the whole design because you feel like it).
- It’s fun to have short discussions about the code and its design
- You learn a lot from others when discussing code and design
- You learn how Java sucks by having no String.join()

Picture or it did not happen!
Here you can see Corey Haines (at the left) in the session, looking at code that Arjen (at the right) is typing. And yes, I am taking this picture so you don’t see me on it of course!

Recap
Doing a Kata is a fun excersise alone. If you are with a group of people you could consider doing a Randori, and have fun coding together. The Kata itself is only the means to pair program, fix a problem, in existing code you did not write and trying to

Practical: What do you need
- A group of people (around 10 people)
- A computer with a dev environment installed (testing framework required)
- A big screen / a beamer

Thanks!
Special thanks to Corey Haines for coming over and let us have this experience!

Footnote: Later Arjen, Daniel and I had worked on the LED Kata again in a teamviewer session. We made a working solution (we wanted to crack the problem badly), which is also on Github.

I have talked about coderetreats before; how they help improve your skills.

The most important reason to join coderetreats however is to just have fun.

I had a good time!

Why don’t you join a coderetreat event nearby and have a good time as well?

public MyObject {

	private String myField;
	 
	... (imagine multiple fields) ...

	public GenericObject toGenericObject() {
		GenericObjectFactory genericObjectFactory = GenericObjectFactory.getInstance();
		GenericObject genericObject = genericObjectFactory.create("myObject");
		genericObject.setField("myField", myField);
		// imagine multiple lines using genericObject.setField("field", field)
		return genericObject;
	}

}

Already many things are pointed out in the comments of the initial post.

One thing that immediately struck me is this line:

GenericObjectFactory genericObjectFactory = GenericObjectFactory.getInstance();

Don’t do this.

GenericObjectFactory implies with the getInstance to be a Singleton. Even though it is a singleton, never retrieve and instance inside your method like that.

Even though there “should be only one instance” of the GenericObjectFactory, it still is a dependency for serializing MyObject. Never hide your dependencies. It makes your code hide its intent, it’s hard to decouple, test, refactor, in short hard to maintain. The code should clearly communicate its intent and usage(s).

In my opinion, there are three (well four sort-off) options to deal with this:

1. Deliver GenericObjectFactory as a parameter (invasive in method signature, but automated refactoring tools (i.e. IntelliJ) handle this perfectly):

public GenericObject toGenericObject(GenericObjectFactory genericObjectFactory ) {
	GenericObject genericObject = genericObjectFactory.create("myObject");

2. Inject GenericObjectFactory as a property of MyObject (invasive in constructor)

public MyObject {

	private final GenericObjectFactory genericObjectFactory;

	public MyObject(final GenericObjectFactory genericObjectFactory) {
		this.genericObjectFactory = genericObjectFactory;
	}

	private String myField;

	... (imagine multiple fields) ...

	public GenericObject toGenericObject() {		
		GenericObject genericObject = genericObjectFactory.create("myObject");

2B. If you find option two too invasive, add the default constructor again but let it call the new constructor (makes point 2 less invasive, remove this default constructor after period of time).

public MyObject {

	private final GenericObjectFactory genericObjectFactory;

	public MyObject(final GenericObjectFactory genericObjectFactory) {
		this.genericObjectFactory = genericObjectFactory;
	}

	// add this default constructor
	public MyObject() {
		this(GenericObjectFactory.getInstance());
	}

	private String myField;

	... (imagine multiple fields) ...

	public GenericObject toGenericObject() {		
		GenericObject genericObject = genericObjectFactory.create("myObject");

3. Introduce protected getInstance method in MyObject (least invasive, increases testability)

public MyObject {

	... snip ...


	protected GenericObjectFactory getInstance() {
		return GenericObjectFactory.getInstance();
	}

	public GenericObject toGenericObject() {
		GenericObjectFactory genericObjectFactory = getInstance();
		GenericObject genericObject = genericObjectFactory.create("myObject");
		...
	}

This is sorted by my personal preference. Although option one and option two trade places from time to time. The third option is less favorable, as you still do not expose the need for dependencies, but it does make it more testable. It is also the least invasive way to refactor, which is sometimes beneficial in legacy projects with lots of untested code.

To conclude, never hide your dependencies, if you ever do see some class using getInstance, please, refactor it. It will make your, and your fellow-programmers, life a lot easier.

Thank you!