A train station is where trains stop.
A bus station is where busses stop.
A Work Station is where ...
Posts mit dem Label Development werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Development werden angezeigt. Alle Posts anzeigen
2008-02-13
Weisheit aus der Arbeitswelt
Schickte uns ein Kollege:
2007-12-18
How not to use static class members
Recently I came across a new experience which I consider a good example of "How not to use static class members".
Static class members are members (attributes and methods) which are shared between all instances of a class.
I.e.: If one instance changes the value of a static attribute, all other instances know this new value immediately.
Static members -particularly attributes- are shurely useful for configuration purposes, where all instances share a really really common knowledge with each other.
Static members are also indeed necessary for patterns like Singleton or Factory.
They are absolutely necessary to declare constants.
BUT: Static members are fatal if their usage include a runtime aspect.
I experienced that, when I inherited some code which extended the JUnit Framework to do validation on a loaded Model. Each validation was declared as test method of a so called "ValidationCase". As JUnit implicitly creates new instances for each test method to be called as test case.
So when running a specific test class, there are a bunch of instances of this class. For the validation now they had to share the model element to be tested.
The quick answer to this problem was: put it into a static member, all instances will know it then. Advantage: The location where these instances were created was inside the JUnit framework and didn't need to be touched.
BUT:
The error in this notion was: Not all instances of a test class share this model element. (As there are more model elements which are tested later and before by the same test class).
So the rule is: Only all instances of the test class which exist at a given time share this knowledge. At other times the share contains other information, shared by all instances actually existing then.
It worked well as long as only one model element was validated at a time.
The problem of this approach occured when once the validation system was extended to call a validation of one model element out of a validation of the other.
Now there were two groups of instances, one for element A, one for element B. But when B was under test, all instances shared the reference to B. And the reference to A was lost. Overwritten at a point in time.
Even this worked, as long as the validation of B happened to be the last action in the test of A, and the A reference was never needed afterwards.
But it was obvious that this card house once would collapse....
So: Everytime you introduce a static variable into a class, check carefully if its value is really valid for all instances of this class, even over time.
Avoid using static members out of well known pattern (like constants, Singleton, Factory ...).
Static class members are members (attributes and methods) which are shared between all instances of a class.
I.e.: If one instance changes the value of a static attribute, all other instances know this new value immediately.
Static members -particularly attributes- are shurely useful for configuration purposes, where all instances share a really really common knowledge with each other.
Static members are also indeed necessary for patterns like Singleton or Factory.
They are absolutely necessary to declare constants.
BUT: Static members are fatal if their usage include a runtime aspect.
I experienced that, when I inherited some code which extended the JUnit Framework to do validation on a loaded Model. Each validation was declared as test method of a so called "ValidationCase". As JUnit implicitly creates new instances for each test method to be called as test case.
So when running a specific test class, there are a bunch of instances of this class. For the validation now they had to share the model element to be tested.
The quick answer to this problem was: put it into a static member, all instances will know it then. Advantage: The location where these instances were created was inside the JUnit framework and didn't need to be touched.
BUT:
The error in this notion was: Not all instances of a test class share this model element. (As there are more model elements which are tested later and before by the same test class).
So the rule is: Only all instances of the test class which exist at a given time share this knowledge. At other times the share contains other information, shared by all instances actually existing then.
It worked well as long as only one model element was validated at a time.
The problem of this approach occured when once the validation system was extended to call a validation of one model element out of a validation of the other.
Now there were two groups of instances, one for element A, one for element B. But when B was under test, all instances shared the reference to B. And the reference to A was lost. Overwritten at a point in time.
Even this worked, as long as the validation of B happened to be the last action in the test of A, and the A reference was never needed afterwards.
But it was obvious that this card house once would collapse....
So: Everytime you introduce a static variable into a class, check carefully if its value is really valid for all instances of this class, even over time.
Avoid using static members out of well known pattern (like constants, Singleton, Factory ...).
2007-11-08
Hacker's Emblem
So since today you find a new simple little logo on this site:
What is it? What is it about?
Why do I display it here?
I will answer the last question first:
Because I am a software developer, grew up with Unix (and now Linux), saw the upcoming of the Internet and the Hacker culture (see also: History) and strongly sympathise with the paradigm of 'free' like used in 'free software'. This logo symbolises how I now understand life and society, perhaps also the universe and all the rest ;-) .
The other questions are well explained here:
The Hacker Emblem and The Emblem's FAQ
and in german:
Das Hacker Emblem und Häufig gestellte Fragen zum Glider
Daneben: Was ist ein Hacker? - leider sind andere vormals vorhandene deutsche Übersetzungen von ESR's Texten inzwischen nicht mehr verfügbar.
What is it? What is it about?
Why do I display it here?
I will answer the last question first:
Because I am a software developer, grew up with Unix (and now Linux), saw the upcoming of the Internet and the Hacker culture (see also: History) and strongly sympathise with the paradigm of 'free' like used in 'free software'. This logo symbolises how I now understand life and society, perhaps also the universe and all the rest ;-) .
The other questions are well explained here:
The Hacker Emblem and The Emblem's FAQ
and in german:
Das Hacker Emblem und Häufig gestellte Fragen zum Glider
Daneben: Was ist ein Hacker? - leider sind andere vormals vorhandene deutsche Übersetzungen von ESR's Texten inzwischen nicht mehr verfügbar.
2006-08-15
Cites all around computer stuff
Programmers don't die, they GOSUB without RETURN.
(Found in a signature in www.rubyforen.de)
Programmer: A biological machine designed to convert caffeine into code.
(Found in a signature in www.rubyforen.de)
There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
C. A. R. Hoare
If the code was hard to write, I'm going to damn well make it hard to read!
Dimator, on Slashdot
Walking on water and developing software from a specification are easy if both are frozen.
Edward V. Berard
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning.
Rick Cook (NASA)
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg.
Bjarne Stroustrup
Managing programmers is like trying to herd cats.
Greg Settle
$cd /pub
$more beer
Found on T-Shirt
Alcohol and calculus don't mix... Don't drink and derive.
The great thing about standards is that there are so many of them...
Personalization: the automatic tailoring of sites and messages to the individuals viewing them so that we can feel that somewhere there's a piece of software that loves us for who we are.
David Weinberger, JOHO
Weeks of coding can save you hours of planning.
An ironic "Microsoft Solution Framework" course attender
Lubarsky's Law of Cybernetic Entomology: There's always one more bug.
If at first you don't succeed, add 1 to any integer variable.
111,111,111 x 111,111,111 = 12,345,678,987,654,321
Useless facts
Tips to make your life and reality more computer-adapted:
- Doubleclick all buttons
- Put bookmarks on your favourite locations
- Check your mailbox every 10 minutes
- Start a newsgroup at the noteboard of your local supermarket
- Recover things from the trashbin that you regret you threw away
- When you show emotions, turn your head vertically and make faces
- When something goes wrong during the day, reboot: go home, go to sleep and start over :-)
Java technology is not fault tolerant and is not designed, manufactured, or intended for use or resale as online control equipment in hazardous environments [...] in which the failure of Java technology could lead directly to death, personal injury, or severe physical or environmental damage.
Microsoft IIS license
A friend of mine in a compiler writing class produced a compiler with one error message "you lied to me when you told me this was a program"
Consistently separating words by spaces became a general custom about the tenth century A.D., and lasted until about 1957, when FORTRAN abandoned the practice.
Sun FORTRAN Reference Manual
0x2B | ~0x2B
Hamlet
There are only 10 types of people in the world - those who understand binary and those who don´t
(unknown)
As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.
Maurice Wilkes discovers debugging in 1949
Telling computer guys that they need to have permission to quote things is like having to tell little children about Death.
Ted Nelson
One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs.
Robert Firth
2005-06-03
Ich hack dich ...
Eine der besten Stories seit langem.
Wir im Kollegenkreis haben herzhaft gelacht ...
Ich hack dich ...
Wir im Kollegenkreis haben herzhaft gelacht ...
Ich hack dich ...
2005-04-12
Programmieren - Kunst oder Wissenschaft?
Heute morgen ging mir so durch den Kopf: Was ist eigentlich "Programmieren", Kunst oder Wissenschaft? Ist es einfach ein ingenieursmaessiges Vorgehen? Anwenden von Methodik zur Analyse, Design, Strukturierung, Test?
Ja, bestimmt. Das ist schliesslich das Tagesgeschaeft. Das ist auch vielfach die Denkweise des akademischen Informatikers. Sehr mathematisch angehaucht: "Wir haben hier einen Problemraum, und muessen dazu den Loesungsraum identifizieren."
Gerade im MDA-Ansatz werden dann Modelle gezeichnet, Code generiert usw. usw.
Aus Unternehmenssicht, Projektsicht mit Kosten- und Zeitfaktoren, Anforderungs- und Release-Management und all dem ist die Entwicklung einer Software nicht anders zu verstehen als die Entwicklung jeder anderen, realen Maschine. Es werden Zeichnungen angefertigt, daraus Maschinenteile erstellt, diese werden montiert und das Ganze geht in Test und Produktion.
Und doch ... irgendwie geht es mir persoenlich doch anders. Der Umgang mit den UML-Modellen und insbesondere mit dem Quellcode ist fuer mich doch noch mehr. Gerade Quellcode: Ist das doch letztlich irgendwo geschriebener Text in einer Sprache, in der man Sachverhalte ausdrueckt.
Und so empfinde ich tatsaechlich fuer Quelltexte eine gewisse Aesthetik. Ein Programm kann "schoen" oder "haesslich" sein, "ansprechend" oder "abstossend".
Genau wie in literarischen Texten kann man in Programmen Sachverhalte klar und eindeutig auf den Punkt bringen oder um den heissen Brei reden, verschleiern, undeutlich werden.
Man kann in Programmtexten sogar Witze machen. (Ich hoffe, ich stosse bald mal wieder auf ein paar Beispiele, dann mach ich dazu mal eine Seite).
Programmierer, die viel Quelltexte schreiben, entwickeln einen Schreibstil. So kann man unter Kollegen tatsaechlich beim Lesen eines Code-Abschnittes recht treffsicher erahnen, wer ihn geschrieben hat. Ein Autor praegt den Programmtext.
Programmierer entwickeln sich auch weiter, und so kann man Programmtexte eines Programmierers seinen "fruehen" oder "spaeten " Phasen zuordnen. Einfluesse lassen sich erkennen: Der Programmierer lernte eine weitere Sprache oder weitere Designkonzepte, die seinen Stil beeinflusst haben.
Zurueck zur Aesthetik: Tatsaechlich ist es so, dass man (ich?) beim Programmieren mit Empfindungen arbeiten kann, was teilweise in Form von Metaphern geschieht. So wird ein Programm beim Lesen z.B. wie ein schiefes Haus empfunden, bei dem keine Ecke rechtwinklig ist, und alles irgendwie nicht zusammenpasst. Man fuehlt sich wohl beim Lesen, empfindet Orientierung, oder man empfindet eben Orientierungslosigkeit. Man erfasst den Sinn eines Codeabschnittes intuitiv und fuehlt sich wohl, oder man springt von einem Codeabschnitt zum naechsten bei dem verzweifelten Versuch, sich zurechtzufinden und einen roten Faden zu erkennen. Irgendwann landet man wieder am Ursprung und fuehlt sich wie in einem Labyrinth. Ach ja, Metapher: Der Ausdruck "Spaghetti-Code" ist ja allgemeiner Sprachgebrauch in der Programmiererwelt geworden.
Ist Programmieren also doch Kunst? Ich fuer mich habe entschieden: Ja! Auch wenn es Projektleitung und Management vielleicht gar nicht so sehen wollen, denn dann waere es ja nicht durch Regelwerke erfassbar und somit letztendlich nicht lernbar. Genau wie bei einem, der ein Instrument lernen will. Entweder er hat's, dann fliesst es mit jeder neu erlernten Technik aus ihm heraus, oder er hat es nicht, dann kann er zwar Techniken erlernen und brauchbare Musik erzeugen, aber wird immer hinter einer gewissen Grenze zurueckbleiben. Es fehlt dann das "gewisse Etwas". Das aber bereitet Managern Angst, denn das ist nicht planbar und kalkulierbar.
Doch stellen wir nicht immer wieder fest, dass es einzelne wirklich grossartige Programmierer gibt, die ueberraschende Dinge moeglich machen und dabei Code produzieren, der jedem nur als Lehrbeispiel dienen kann?
Und kennen wir nicht auch Programmierer, wo man beim Lesen des Codes leise seinen Kollegen fragt: "Was, der programmiert wirklich schon seit 15 Jahren???".
Warum wohl?
Ja, bestimmt. Das ist schliesslich das Tagesgeschaeft. Das ist auch vielfach die Denkweise des akademischen Informatikers. Sehr mathematisch angehaucht: "Wir haben hier einen Problemraum, und muessen dazu den Loesungsraum identifizieren."
Gerade im MDA-Ansatz werden dann Modelle gezeichnet, Code generiert usw. usw.
Aus Unternehmenssicht, Projektsicht mit Kosten- und Zeitfaktoren, Anforderungs- und Release-Management und all dem ist die Entwicklung einer Software nicht anders zu verstehen als die Entwicklung jeder anderen, realen Maschine. Es werden Zeichnungen angefertigt, daraus Maschinenteile erstellt, diese werden montiert und das Ganze geht in Test und Produktion.
Und doch ... irgendwie geht es mir persoenlich doch anders. Der Umgang mit den UML-Modellen und insbesondere mit dem Quellcode ist fuer mich doch noch mehr. Gerade Quellcode: Ist das doch letztlich irgendwo geschriebener Text in einer Sprache, in der man Sachverhalte ausdrueckt.
Und so empfinde ich tatsaechlich fuer Quelltexte eine gewisse Aesthetik. Ein Programm kann "schoen" oder "haesslich" sein, "ansprechend" oder "abstossend".
Genau wie in literarischen Texten kann man in Programmen Sachverhalte klar und eindeutig auf den Punkt bringen oder um den heissen Brei reden, verschleiern, undeutlich werden.
Man kann in Programmtexten sogar Witze machen. (Ich hoffe, ich stosse bald mal wieder auf ein paar Beispiele, dann mach ich dazu mal eine Seite).
Programmierer, die viel Quelltexte schreiben, entwickeln einen Schreibstil. So kann man unter Kollegen tatsaechlich beim Lesen eines Code-Abschnittes recht treffsicher erahnen, wer ihn geschrieben hat. Ein Autor praegt den Programmtext.
Programmierer entwickeln sich auch weiter, und so kann man Programmtexte eines Programmierers seinen "fruehen" oder "spaeten " Phasen zuordnen. Einfluesse lassen sich erkennen: Der Programmierer lernte eine weitere Sprache oder weitere Designkonzepte, die seinen Stil beeinflusst haben.
Zurueck zur Aesthetik: Tatsaechlich ist es so, dass man (ich?) beim Programmieren mit Empfindungen arbeiten kann, was teilweise in Form von Metaphern geschieht. So wird ein Programm beim Lesen z.B. wie ein schiefes Haus empfunden, bei dem keine Ecke rechtwinklig ist, und alles irgendwie nicht zusammenpasst. Man fuehlt sich wohl beim Lesen, empfindet Orientierung, oder man empfindet eben Orientierungslosigkeit. Man erfasst den Sinn eines Codeabschnittes intuitiv und fuehlt sich wohl, oder man springt von einem Codeabschnitt zum naechsten bei dem verzweifelten Versuch, sich zurechtzufinden und einen roten Faden zu erkennen. Irgendwann landet man wieder am Ursprung und fuehlt sich wie in einem Labyrinth. Ach ja, Metapher: Der Ausdruck "Spaghetti-Code" ist ja allgemeiner Sprachgebrauch in der Programmiererwelt geworden.
Ist Programmieren also doch Kunst? Ich fuer mich habe entschieden: Ja! Auch wenn es Projektleitung und Management vielleicht gar nicht so sehen wollen, denn dann waere es ja nicht durch Regelwerke erfassbar und somit letztendlich nicht lernbar. Genau wie bei einem, der ein Instrument lernen will. Entweder er hat's, dann fliesst es mit jeder neu erlernten Technik aus ihm heraus, oder er hat es nicht, dann kann er zwar Techniken erlernen und brauchbare Musik erzeugen, aber wird immer hinter einer gewissen Grenze zurueckbleiben. Es fehlt dann das "gewisse Etwas". Das aber bereitet Managern Angst, denn das ist nicht planbar und kalkulierbar.
Doch stellen wir nicht immer wieder fest, dass es einzelne wirklich grossartige Programmierer gibt, die ueberraschende Dinge moeglich machen und dabei Code produzieren, der jedem nur als Lehrbeispiel dienen kann?
Und kennen wir nicht auch Programmierer, wo man beim Lesen des Codes leise seinen Kollegen fragt: "Was, der programmiert wirklich schon seit 15 Jahren???".
Warum wohl?
Abonnieren
Posts (Atom)
