Vassilios Karakoidas Weblog

Based on a true story …

You are a software engineer. Great! You have already worked on numerous low-impact, low-innovation projects and now you have polished your skills and want to work with the big guys. Large teams in various corporations that all want to deliver a big and very complex project. Your job is to design and implement a software component that does serious business. A software component that will save the world, maybe.

For that task you are using all the gizmos that a software engineer could want: version control systems, modern software development methodologies, bug/issue tracking systems, wikis, complex IDEs and many more. Those resources are the easy ones to pick, the one that are under your control.

What you cannot select is your co-workers (at least at this stage). Most of them will be honest, hard-working people that at first are eager to cooperate with you (at most times) and help you surpass all the hardships of modern software development.

When they don’t, you have to be careful and remember: “do not fall to the dark side of the force”. This order will help you to mentally prepare for these situations, expose the behavioral patterns of such people, and make you keep the hatchets deep buried and get the task done.

The Standards Zealot

Those are people that like coding standards. Oh, they love them. In fact, they love almost every document (in electronic form or not) that can be described as a “specification”. They think we must follow them, because the standards offer a common way of doing things. You know what, they are right. But like all religions, there are some followers that want to make big issue about minor things. For example, let’s consider that you do not follow the naming convention in some variables or you are forgetting to leave a double space after each class declaration in your Python code. They will be the first to remind you that you are wrong. They tend to focus on regulations and coding standards and not on the job that needs to be done.

Tip: Ignore them. Ok, it is nice to follow a coding standard, but it is not the end of the world if you accidentally forgot that empty line at the end of the source file. Sometimes they have something interesting to say, but in most cases tend to focus on the irrelevant. Do not forget to fix those discrepancies though and do not begin a flame war with them, you can lose a day and achieve nothing.

The Cowboy Programmer

The cowboy programmer is a guy that thinks he is alone in the whole project and maybe in the universe. He usually commits and break the code of others and if you ask him the answer is one: “I think the changes were necessary to achieve the required functionality”. Cowboy programmers think their way is the only way. They tend to simplify things they cannot understand and over-engineer things they found exciting. In addition, they drop commit-nukes. They work silently and will try to avoid revealing their designs and code, until it is too late.

Tip: Do not try to explain things to them. It is a big waste of time. Instead, contact their manager (the sheriff for that matter) and make them follow a formal commit-review-testing process with his support. Enforce unit testing on the development process and make them revert their unwanted changes themselves. Be careful, they are prone to engage in commit wars!

The Comfy Developer

This is usually a guy that wants only to make a living by his profession. No, he does not want to create a superb system and he could easily write in Visual Basic 6.0 until his retirement, if that would afford him a steady income. He knows one way of doing things, he will not experiment and he will absolutely do nothing, unless it is strictly required. When you try to talk to him, he is eager to listen but less eager to do anything outside his comfort zone.

Tip: I like those guys and I usually want to see them write boiler-plate code. They are born to do it. Do not intimidate them, but try and explain what you want in a relaxed and polite manner. They will sometimes break the code in the repository, but no worries, they will help to fix it. Just tell them. Take them by the hand and point the way to the right directions, they will follow.

The Technology Expert

Those are software engineers that know an area of technology very well. If their expertise can be used in the project, then you are lucky. If not, they will eventually compare everything with the technology they know. Do not try to convince them about flaws related with their area of expertise. They will not believe you, cause they are the experts after all!

Tip: Usually, those kind of people are there when their expertise is related to the project. Exploit them! Do not engage on big talks with them, unless you have the guts to hear all related terminology in 10 minutes talk, just ask them specific questions and get specific answers on corner cases.

The Systems Guru

There is a category of software engineers that have more experience with systems and scripting than in software engineering formalities. These are great guys, but they have two big flaws: they do not respect software development processes and they tend to use whatever tool makes their job right. This usually ends up on causing inconsistencies in the build and testing process, along with many unwanted dependencies. They act like commandos, they can save the day, but they cannot be restrained easily.

Tip: Never ask their advice regarding technologies, they tend to go where the wind blows, and their advices are focused on just answering the question, not answering the question in the context of the project. Let them work on the tools that support the development process, but not on the project itself. Do not, at any circumstances, engage in a flame war with them.

The Hitman Coder

Usually contractors, coming from other companies temporarily to give a boost to the development effort. They are not loyal and will focus only to the task they are given. They do not like to get into trouble and will avoid to do things that will embarrass them or their employee, typically a consulting company. They value their rate, most of all. In fact of those things, they are usually very skilled and competent. They will answer all your questions with sincerity. They are experts on “task dodging” and they will often try to convince you that this is not their job.

Tip: They will never sacrifice their good name in the market to argue with you. So, use that for your advantage. Exploit the fact that they are very experienced and have worked in various companies to enrich your way of doing things in the software development process. The key is to make them participate and propose things, but do not forget, it is not their job to make the big decisions, nor they will share the burden if they are wrong.

The Guardian

Usually a developer that becomes very intimate with his tasks. He never accepts  comments or suggestions from others. These guys live in their fortress, behind close walls, they actually guard their work. Unlike the cowboy programmers they know what they are doing, but since they are humans like all of us, if they are missing something, you will know it when it is very late and it will be very difficult to convince them to change their masterplan. There are some guardians that want to prove themselves to the team and feel important by adopting more tasks than they can handle.

Tip: If you have one of these guys in your team, then you are in trouble. It is then an absolute necessity to adopt an agile development methodology and begin with pair programming and small iterations. Never argue with them, be strict, but polite. Ask them to do things not by asking, but by issuing orders. They are prone to flame and commit wars.

Epilogue

Those are just few types of people you can encounter when you are part of large development effort. Many of them will get on your nerves, but remember you are there to get the job done, not to compete with your colleagues. My advice is, “first listen, then argue”, do your work with professionalism and get results.

Acknowledgments

I would like to thank Diomidis Spinellis, Marianthi Theocharidou, Dimitrios Mitropoulos, Panagiotis Louridas and Dimitrios Liappis for their comments.

That UTF-8 BOM can be very irritating … especially when parsing text files. Use that simple command to easily remove it.

tail -b 4 [your-file] > [your-file]

Cool, huh.

EavesDrop is a wow plugin that acts as simple combat log that displays events using icons for spells/kills instead of raw text. It seperates incoming events (left side) from out going events (right side) from misc. events (middle).

Since cataclysm, the add-on bugged in Atramedes fight (Blackwing descent), when he used the sound power. The add-on has not updated since 15/10/2010 (before cataclysm), so I took the liberty to introduce a minor fix for this.

Please note that this is a workaround. The add-on will ignore all sound abilities.

Many thanx to Maria, for pointing out the problem and spending her time discussing possible solutions .

You can download the add-on from http://bkarak.wizhut.com/www/programs/misc/EavesDrop.zip

Visit it now … and find the books’ source code, errata and more. — http://stepsinscala.com/

Overloading constructors in Java (not only) is good for the overall design. When used effectively it can result with correct and efficient initialisation of a class and avoidance of many lines of boiler-plate code.

Yesterday, I stumbled on the following problem. I wrote a class like the following,

public class Foo {
     public Foo(Integer i, Double d) { ... }
 
     public Foo(Integer i, Float f) { ... }
}

which defines a class Foo with two constructors that accept Integer and Double, and Integer and Float.

For some reason (not important right now) I wanted to initialise the first (Integer,Double) with the second parameter set as null.

This resulted as a compiler error, because the compiler actually could not decide which of the two constructors I wanted to use. Whoops … what could I do?

I could introduce a third constructor, with only one parameter and call this. Try it, you will see, that you will end up using part of the initialisation of the two others, which may complicate things (at least it did in my case).

Fascinating, isn’t it? Maybe we need a Null<Double> or Null<Float> to avoid this mess? Maybe the null value should be a generic Null<T> and use it to ensure type safety and instruct the compiler to correctly solve this ambiguity?

I do not know. My real-world problem solved with a third constructor as a work-around and some duplication of code. C’est la vie.

Browsing some source code (actually my own) and I noticed that long is used. The range for this type is from -9,223,372,036,854,775,808 to +9,223,372,036,854,775,808.

Wow, thats a LOT of expected errors. On the other hand, better safe than sorry .

1
2
3
4
5
6
7

public void setErrorCount(long e) {
    this.errors = e;
}
 
public long getErrorCount() {
    return errors;
}

Recently I began coding the Firefox client of the Pithos application. This release include some small fixes, that permits you to copy local files outside your home directory in windows-based systems. I plan to add some cool features in the near future.

A very close friend of mine, Christos KK Loverdos and Apostolos Syropoulos are close to finish their efforts in completing their book for Scala, titled “Steps in Scala”.

Good luck to both of them, keep up the good work, and I will gladly pre-order my copy .

These days i’m finalising the FIRE regular expression compiler. To add a feature, the need arise to modify the classpath at runtime. It was a surprise for me when i discovered that there is no official way to modify this at runtime. I even created my own URLClassLoader (java.net), and set it as default classloader for my thread, but nothing.

I searched in google a little and found this post on a forum, which provided a class named ClassPathHacker that could add a path or file (jar) to a classpath at runtime. All this by a programmer named Antony Miguel. Well done .

The source code of the class follows:

import java.net.*;
import java.io.*;
import java.lang.reflect.*;
 
public class ClassPathHacker {
 
	private static final Class[] parameters = new Class[]{URL.class};
 
	public static void addFile(String s) throws IOException {
		File f = new File(s);
		addFile(f);
	}
 
	public static void addFile(File f) throws IOException {
		addURL(f.toURL());
	}	 
 
	public static void addURL(URL u) throws IOException {			
		URLClassLoader sysloader = (URLClassLoader)ClassLoader.getSystemClassLoader();
		Class sysclass = URLClassLoader.class;
 
		try {
			Method method = sysclass.getDeclaredMethod("addURL",parameters);
			method.setAccessible(true);
			method.invoke(sysloader,new Object[]{ u });
		} catch (Throwable t) {
			t.printStackTrace();
			throw new IOException("Error, could not add URL to system classloader");
		}		
	}	
}

and an example of usage ..

import java.io.*;
 
public class ClassPathAdder {
	public static void main(String[] args) {
		try {
			ClassPathHacker.add(new File("/home/user/newClassPath"));
		} catch (IOException e) {
			System.err.println("Error - " + e.toString());
		}
	}
}

Cool!

You can find the latest release of biblio.py here.

v0.55 (sanity), bkarak:
* FIXED: ~/.biblio.py/repositories file is now created correctly, when you run the program for the first time
* ADDED: pdf storage support
 
	Now biblio.py automatically find and adds to each bibtex entry pdf file that contain the actual document.
	The pdf file is stored in a folder with the bib file's name, in the same directory. For example, the file '/home/bkarak/foo.bib'
	should contain the pdf files in '/home/bkarak/foo'. The pdf file should have as filename the entry's key.
 
	The generated entry will look like:
 
	@techreport{GRSH00,
	 Title = {Rules of Thumb in Data Engineering},
	 Year = {2000},
	 Author = {Jim Gray and Prashant Shenoy},
	 Institution = {Microsoft Research, Advanced Technology Division},
	 Filename = {[...]/bibliography/reading/2009/june-2009.bib},
	 pdf-file = {[...]/bibliography/reading/2009/june-2009/grsh00.pdf},}
* REMOVED: Optik library removed