September 30th, 2006

Die Imbros-Schlucht ist eine Alternative zur Samaria-Schlucht, wer nicht einen ganzen Tag durch eine Schlucht laufen will, wird hier gut bedient. Man soll sich allerdings keine Illusionen machen: Auch hier sind reichlich Wanderer unterwegs.
Highlight ist sicher, dass sich die Schlucht auf 1,60 verengt.


Die Schlucht war früher eine wichtige Verbindung zwischen Nord und Süd, davon zeugen die Reste eines befestigten Weges.
Wenn man nicht zurück laufen will (ich gehe lieber bergauf als bergab), so gibt es im Ort Taxis und Busse, die einen nach Imbros zurückbringen.

Alles in allem eine schöne, einfache Wanderung.

Posted in
Life
No Comments »
September 13th, 2006
Many companies have a policy in place on the use of internet, phone etc. Normally a limited private use is tolerated, because it is not a real probelm in terms of volume (and cost).
If there are serious concerns about the non-professional use (and even the professional use!) there are two possiblities:
- The communication need is excessive.
- The responsible manager is simply an idiot who wants to be known as cost-aware
Reason 1. has to distiguish professional use and private use:
- If the professional use cost serious amount of money there is something wrong with the structure or the training of the employees
- Excessive private use simply says that the employees seek distraction from their job (that is then likely to suck)
- If the private use is small, but still outnumbers professional use you surely have internal communication problems
So if it is not reason 2. (a reason I recommend to simply ignore as this will simply go away), the message should go only to the managers whose job it is to enable and motivate people.
Posted in
Life, Web, Java
No Comments »
September 11th, 2006
Today I had a job interview - in french, this is what makes this most remarkable; the interview drifted a bit off and I stated the following (I’ll give the english transcription, as my french writing is terrible)
You can reify the internal flow of a software-system by looking at the social network of the people who build it. The opposite is also true.
If you look at a sufficiently large piece of software, you’ll find different components and of course interface between these components. The developers of components are likely to form clusters, while over the interfaces you’ll find (occasional) communication that is more formal than within a component’s clique.
As a corollary to this observation I’d like to state: If you have an interface it will be working if and only if (iff - for mathematicians) the cliques hav a working communication.
I explained this to my girl-friend over diner (rest assured, she tells me about her professional poker experiences in turn) and we agreed that this is the key for the success of open source software.
An open source project can only exist if you have a working network and good communication among the subgroups. The mere fact that you found a group of people capable of forming such a network assures (at least) the necessary condition to create a good piece od software.
The existence proves statistically the need and the compliance with the mainstream of such a solution. Otherwise the likehood that such a group can find itself in the vast space of the internet will be zero.
(we had wine with and some calva after the dinner - so I am not capable to tell if this observation is just trivial or perhaps a real deep insight - anyway I am proud that I’d been able to express it after only three years of french)
Posted in
Architecture, Web, Java
No Comments »
September 8th, 2006
Turbo C# is available now.
I blogged about this 2 weeks ago. The install had been smooth (besides that I had to install .NET 1.1?!) and at look quite clean. The IDE cannot deny that is is made with .NET:

Well, Borland a little bit more work, even for a free product would have suited you better, the installer and the registration are so 90ty.

Perhaps it gets better in 100 years, when I have to register a new copy:-)
Posted in
Java
No Comments »
September 6th, 2006
I am reading Groovy in Action at the moment (via MEAP), today Chapter 4 and 5 arrived (So far a good read, but it offers not much more you’d expect from a good apidoc).
I flipped through chapter 4, as it is much know stuff, but this thing here was so strange that it caught my attention:
For the common case of having keys of type String, one can leave away the string markers (single or double quotes) in a map declaration.
assert [’a':1] == [a:1]
Nice, it comes comes as a side-effect from the pattern syntax, I guess. But it continues like this:
This notations can also get in the way when e.g. the content of a local variable is used as a key. Suppose, you have local variable x with content ‘a’. Since [x:1] is equal to [’x':1], how can we make it being equal to [’a':1]? The trick is that we can force Groovy to recognize a symbol as an expression by putting it inside parentheses.
def x = ‘a’
assert [’x':1] == [x:1]
assert [’a':1] == [(x):1]
Does this really simplify anything? Two things to consider
- Pattern work naturally(?) on strings, so it is nice that they don’t have to wrapped as in Java-regexp, in maps I rarely use strings as keys.
- The syntax of “()”: In patterns this is the group operator - here it is an eval. This I find confusing.
Posted in
Java
1 Comment »
September 3rd, 2006
There are millions of programmers and trillons of lines of code out there that use Java, but as Java is an All-purpose language, most of the code produced is procedural redump of what people did when they used C or Fortran.
I came up with a short-list of sanity checks that I use to benchmark my designs.
- No public method shall return null, this applies also to protected methods of non-final classes
- Never pass this as an argument
- Getters and Setters are evil
- A public method shall be declared by an interface (sometimes an abstract class is sufficient and more convenient)
- No switch / if-else if on class invariants (this includes instanceof)
- A class shall be either (conceptually)final or abstract
- No method declares a foreign exception (I am OK with some checked exceptions from the java* packages)
- An object that can be passed back to the API shall be immutable or a Builder
- Prefer delegation over inheritance (this makes 6. reasonable)
- The class skeleton shall fit on a single page, as do all methods (including the private methods that are used by a single method only)
- The number of ctors shall be much smaller than the number of instance methods
- All statics are in enums
This is no style-guide (most of them are a waste of time with as little impact as knowledge is required to contribute), this is what I distilled out of code that pleases me and that really works and has been proven to be maintainable and easy to integrate.
To be continued / comments and suggestions are welcome.
Actually I know of style-guide that focussed on more than indentation and the placement of whitespace: JSF air vehicle C++ coding standards
Update: I started some explainatory notes on each topic (1-6,10,11 for the moment) under Design Rules
Posted in
Architecture, Java
7 Comments »
September 3rd, 2006
Leben und Sterben in Medellin.
Handlung
Rosario ist Animierdame und verdient nicht schlecht damit gewisse Leute des Milleus zu beseitigen. Als sie Antoinio und Emilio kennenlernt entwickelt sich eine Dreiecksgeschichte; Rosario spielt ihre Macht aus, muss aber feststellen, dass sie nicht ihre Herkunft, die Slums von Medellin, abstreifen kann.
Warum sollte man den Film sehen?
Kein typischer Krimi, obwohl er of einem Krimifestival hier lief. Es ist eher ein gewalttätiges, erotisches Sozialdrama. Deformationen, die der Slum und ihre Arbeit Rosario zugefügt haben machen es ihr unmöglich dem Milleu zu entkommen. Antonio und Emilio sind grundverschieden, doch weder mit dem einen noch dem anderen kann Rosario sich wirklich finden, mal steht ihre Herkunft, mal ihre Sozialisiation ihr im Weg.
Was nervt
Ich mag keine Rückblenden, hier sollte damit die oberflächliche Spannung herausgenommen werden, es gibt aber auch andere Wege den Zuschauer auf das eigentlich Thema zu lenken.
Am Anfang wird der Film dadurch unverständlich und langatmig, zum Ende hin eher vorhersehbar.
Posted in
Kino
No Comments »