This is my custom one, which updates the prompt and the terminal name.


function promptcmd() {
GITBRANCH=""
GITBRANCH_SHORT=""
if GITBRANCH=$(git-symbolic-ref HEAD 2> /dev/null); then
GITBRANCH_SHORT="${GITBRANCH#refs/heads/}"
GITBRANCH=" (${GITBRANCH_SHORT})"
fi
USER_SHORT=${USER:0:1}
HOSTNAME_SHORT=${HOSTNAME%%.*}
TIMESTAMP=$(date "+%a %H:%M:%S")
PS1='${debian_chroot:+($debian_chroot)}$TIMESTAMP $USER_SHORT@\h:\w$GITBRANCH\$ '
LOC=${PWD}
if [ "$GITBRANCH_SHORT" = "" ]; then
LOC=${PWD}
else
LOC=${GITBRANCH_SHORT}
fi
if [ "$LOC" = "/home/psycho" ]; then
LOC="~"
fi
echo -ne "33]0;${USER_SHORT}@${HOSTNAME_SHORT}:${LOC}07"
}
export PROMPT_COMMAND=promptcmd


I highly value that you try to rethink the value system in software development. I also think that switching the role model for software developers from ‘architect’ or ‘engineer’ to ‘craftsman’ may help. However, apart from that I’m a bit afraid that your wording does not currently differentiate your movement enough from regular software development. :-/ Here’s why: Consider you’re talking to a manager-type of guy from company X. Company X is as far from the software craftsmanship ideal as you can get. To this manager, you pose the following questions:

* Do you [as a company] gain the trust of the businesses by delivering superior quality?
* Do you write code that is defect-free, proven, readable, understandable and malleable?
* Do your developers improve their skill-set by learning new things?
* Do you have a culture of open collaboration between developers?

It’s obvious that all this is good, so probably the answer to this will be mostly ‘Yes’, even though these are basically the same statements as the ones in the URL you gave. I’m not saying it *is* actually like that in company X, but from the outside, it may be hard to tell the difference. [Actually, for the manager, it may even be hard to tell the difference from the *inside*.]

In my opinion, it’s maybe a bit too simple to fall into the trap of considering oneself a software craftsman too soon. How can you tell people they are not software craftsmen and should consider adopting more of these practices, when you don’t define signs of *not* being a software craftsman? (I imagine endless discussions about the interpretation of the manifesto in defense of company X here.)

I also fail to see the place where the Software Craftsmanship manifesto states that it’s an extension of the Agile manifesto and that you have to “be Agile” to be a Software Craftsman. Is that the case?

–Günther

This has been the primary criticism for the software craftsmanship movement. I agree that it is still romanticized and not fully fleshed out. The ethic is another step in the right direction, but still a work in progress(http://groups.google.com/group/software_craftsmanship/web/principles-of-software-craftsmanship).

I think the major factors of software craftsmanship are emphasizing the lifelong journey of learning, practicing, and improving your skill sets. Craftsmanship is a great technique people have used (with varying success) to produce highly skilled artisans.

Die Surfer sollte man leicht finden können, indem man von den Nackten aus dem Fluss flussaufwärts nachgeht.

Ich habe allerdings nicht getwittert ^^

In a language like Java (with static typing and a type system with generics) this may look like this:

public  T accept(Visitor visitor) {
  return visitor.visit(this);
}

A typical expression visitor might specialize T as a number type. This way, the evaluation method could for example be implemented like this:

public Integer visit(AddExpression expr) {
  return expr.leftSubExpression().accept(this) + expr.rightSubExpression.accept(this);
}

(This code is untested.) To be honest, it’s a bit sad that Java only allows to specialize a generic type using class types, not atomic types like int. I hope that helped.

Best regards,
Günther

thanks

When you want to make you object both a subclass of Observer<A> and Observer<B> (A and B being unrelated classes), it’s not possible in Java as far as I know. (This has to do with byte code compatibility to earlier versions where generics were not possible yet.) However, if the object in the Observer role registers itself at the observable object, it may be possible to use inner classes that implement Observer<A> and Observer<B>. (The inner classes’ instances can only be created by an instance of the surrounding class and can also access private methods and fields of that object.)

Unfortunately, avoiding instanceof is usually not straightforward. Here’s the bird view on that issue: When implementing some functionality in a method, you can usually choose into which class that method belongs. (For the other related objects, it may be unavoidable to use instanceof.) A simple heuristic would be to identify of which of used argument objects (also the receiver object [1]) the most instance variables need to be used (or simply “which is the most important object in this piece of code?”). Another concern is that you usually want to be able to use polymorphism (so that subclasses can override methods), but it only works on the receiver argument. To choose, which of the used objects is the receiver, there needs to be some kind of imbalance between all the argument objects. However, in some cases, the imbalance is not always given and all argument objects are equally important. If that happens, I usually try the following:

(1) Building an additional layer of abstraction around one or more of these arguments, so that they are used in a less direct way. As a result, an imbalance can be established, thereby marking the “most important” object’s class as the class, where the method fits into best. Another result of an additional layer of abstraction is often that the use of instanceof “moves into the implementation of that layer”. When applying this technique recursively, it ultimately usually disappears.
(2) If this doesn’t work, you need something called “multiple dispatch”. This means that the question, which method is to be executed when a call is made, is answered not only using the type of the receiver object, but instead using the types of *all objects* handed as arguments. (Note that you can directly use this to avoid instanceofs! ) Java doesn’t support this as a language feature, but the visitor pattern does exactly that. (I just recently wrote a blog entry about it, where I talk about that pattern, but the best resource on the topic probably is the classic “Gang of Four” design patterns book. http://home.earthlink.net/~huston2/dp/visitor.html looks good, too. Be careful about the sources you use here, because many people see the visitor pattern very much from a “walking tree structures” angle, which is a very related idea that can be done easily using it, but which leads many people into the mistaken belief that this is all the pattern does.)

To sum up, I have made the experience that (1) instanceof usage often disappears by adding more layers of abstraction and (2) if this makes difficulties, the visitor pattern can be used as last escape.

I’m afraid this may have been even more confusing than the previous comment I wrote. I hope it still helps. In doubt, don’t trust me but trust the Gang of Four book. Also don’t take patterns too dogmatic. It’s not so important to use the exact same names as in the books, but if you know a pattern and you have thought about its advantages and disadvantages, it often helps to explore the design space faster or in a more efficient manner. If you have some new insights, I’d be happy to hear about it.

[1] Small example for terminology: In the following code snippet, “taxi” is the receiver object, “memphis” and “driver” are arguments to the method:

taxi.drive(driver, memphis);

When considering the order of these arguments, it makes sense to see all three “taxi”, “driver” and “memphis” as plain arguments first and later decide which of the classes Car, Person and City is imporant enough to host the “drive” method.

I’m playing around with an application that listens to a controller- the controller needs to send messages, which I thought would be straightforward. But each message could have different components (from states to actual data), which mean different objects. So I guess I’m stuck with the ‘instanceof’ model. I guess an improvement would be if Observer could have method signatures with the desired class instead of passing ‘Object’. That’s an old beaten horse, since Observer/Observable have been around since 1.0.

1. When just using the “Standard” Observer class that you can find in the Java class library, observers implement the interface method “void update(Observable o, Object arg)”. Even though a program may be designed so that a *specific* implementation only gets notifications from a *specific* Observable implementation, the type of the argument given in “update” is still “Observable”. Thus, a cast is needed to do something more specific, therefore most programmers would use instanceof to check whether that cast will work first. Using generics, the correct type is given directly to the update method and both the cast and this instanceof aren’t needed any more.

2. The second part of the answer is concerned with the case that the observers observe a larger class hierarchy and thus more actual types can be passed to update(). (You won’t like this answer. ) I believe this problem is completely independent of the observer pattern in that the question is actually “what to do when different things must be done for different subclasses”. The basic answer is: Starting from a switch statement or multiple if-constructs, move the code for the different cases into the relevant class hierarchy and use Polymorphism instead.

There are people who say that instanceof is generally to be avoided, and when working in an Object Oriented context, it probably makes sense. Here’s a bigger discussion on that topic:
http://c2.com/cgi/wiki?InstanceofInConditionals
http://c2.com/cgi/wiki?ReplaceConditionalWithPolymorphism

I hope I could help you a bit. If not, feel free to ask.