2010-10-21
Memory Leak ...
Heute hatte ich einen Gedächtniseffekt der ganz besonderen Art:
Ein Kollege erzählte mir, er habe eine ClassCastException im PreferencesXMLConverter.
Muss man jetzt nicht unbedingt vestehen, wesentlich ist meine Reaktion darauf:
"Wie kann das, den Fehler habe ich doch neulich gefixt!"
Der Kollege weiter: "Der SystemIndependentJFrame kann nicht gecastet werden".
Meine Antwort: "Klar, der Cast auf FrameContainer ist weder richtig noch nötig.
Aber den hatte ich doch entfernt!".
Klare Erinnerung mit Ansage, also keinesfalls ein Deja-vu Effekt!
Ich kann mich genau erinnern, dass vor einer Weile ein Kollege kam und mir diesen
Fehler (den ein übrigens damals abwesender Kollege eingebaut hatte) gemeldet hat.
Ich hatte ihn dann (eben wegen der Abwesenheit des besagten Kollegen) gefixt.
Ich konnte mich genau erinnern, den Fehler erst kommentieren und dann meinem
Kollegen mailen zu wollen, ihn dann aber eben schnell selbst behoben zu haben.
Nichts mehr von gehört, alles Bingo. Musste so circa 1,5 Monate her sein.
Heute tritt der Fehler also wieder in Erscheinung, und ich wundere mich.
Naja, kann ja mal passieren, dass jemand ungeschickt einen alten Stand über
einen neueren in die Versionsverwaltung einspielt.
Also gehe ich auf die Suche nach meiner damaligen Korrektur. Und siehe: Weder
im Versionsverwaltungssystem, noch in unserer Fehlerdokumentation, noch auf meiner
PC-Festplatte (auf der ich eine eigene Versionsverwaltung zusätzlich einsetze) ist
irgendeine Spur der von mir durchgeführten Änderung zu finden.
Kann Erinnerung so dermaßen trügen???? Ich habe über zwei Stunden immer wieder
versucht, irgendwo (auch in älteren Versionen) eine Spur dieser Fehlerkorrektur
zu finden.
Aber noch viel schlimmer: Der Fehler selbst kann erst 14 Tage alt sein!
Alle älteren Stände haben den fehlerhaften Code noch gar nicht enthalten.
Ich müsste innerhalb der letzten 14 Tage sowohl die Entdeckung des Fehlers als
auch seine Korrektur geträumt haben, und das ziemlich realitätsgetreu.
Nach langem, langem Nachgrübeln habe ich mich entschieden, ganz wissenschaftlich
exakt vorzugehen, gemäß dem Motto meines scharfsinnigen Vorbildes Sherlock Holmes:
"Wenn man das Unmögliche abzieht, dann muss das, was übrig bleibt, die Lösung sein,
wenn es auch noch so unwahrscheinlich klingt" (Für Star Trek Kinogänger: Nein, der Spruch
stammt nicht von einem Vorfahren des Mr. Spock !)
Und so kam ich auf die einzige plausible Lösung:
Es handelt sich um ein Memory Leak.
Ein Leck in der Erinnerung. Nicht zu verwechseln mit einer Gedächtnislücke, eher im Gegenteil.
Das Leck in der Erinnerung funktioniert ähnlich einem Wurmloch. Es ist ein Bruch im
normalen Raum-Zeit-Kontinuum, der dafür sorgt, dass Gedächtnisinhalte (Memories)
zwischen zwei Paralleluniversen ausgetauscht werden.
In einem anderen Universum hatte ich den Fehler tatsächlich gefunden und behoben, und
diese Erinnerung schlüpfte nun durch das Leak in mein diesseitiges Hirn.
Ja, so muss es sein! Und da ich nun endlich die Erklärung hatte, konnte ich mich wieder
beruhigt meiner Arbeit zuwenden ...
Ein Kollege erzählte mir, er habe eine ClassCastException im PreferencesXMLConverter.
Muss man jetzt nicht unbedingt vestehen, wesentlich ist meine Reaktion darauf:
"Wie kann das, den Fehler habe ich doch neulich gefixt!"
Der Kollege weiter: "Der SystemIndependentJFrame kann nicht gecastet werden".
Meine Antwort: "Klar, der Cast auf FrameContainer ist weder richtig noch nötig.
Aber den hatte ich doch entfernt!".
Klare Erinnerung mit Ansage, also keinesfalls ein Deja-vu Effekt!
Ich kann mich genau erinnern, dass vor einer Weile ein Kollege kam und mir diesen
Fehler (den ein übrigens damals abwesender Kollege eingebaut hatte) gemeldet hat.
Ich hatte ihn dann (eben wegen der Abwesenheit des besagten Kollegen) gefixt.
Ich konnte mich genau erinnern, den Fehler erst kommentieren und dann meinem
Kollegen mailen zu wollen, ihn dann aber eben schnell selbst behoben zu haben.
Nichts mehr von gehört, alles Bingo. Musste so circa 1,5 Monate her sein.
Heute tritt der Fehler also wieder in Erscheinung, und ich wundere mich.
Naja, kann ja mal passieren, dass jemand ungeschickt einen alten Stand über
einen neueren in die Versionsverwaltung einspielt.
Also gehe ich auf die Suche nach meiner damaligen Korrektur. Und siehe: Weder
im Versionsverwaltungssystem, noch in unserer Fehlerdokumentation, noch auf meiner
PC-Festplatte (auf der ich eine eigene Versionsverwaltung zusätzlich einsetze) ist
irgendeine Spur der von mir durchgeführten Änderung zu finden.
Kann Erinnerung so dermaßen trügen???? Ich habe über zwei Stunden immer wieder
versucht, irgendwo (auch in älteren Versionen) eine Spur dieser Fehlerkorrektur
zu finden.
Aber noch viel schlimmer: Der Fehler selbst kann erst 14 Tage alt sein!
Alle älteren Stände haben den fehlerhaften Code noch gar nicht enthalten.
Ich müsste innerhalb der letzten 14 Tage sowohl die Entdeckung des Fehlers als
auch seine Korrektur geträumt haben, und das ziemlich realitätsgetreu.
Nach langem, langem Nachgrübeln habe ich mich entschieden, ganz wissenschaftlich
exakt vorzugehen, gemäß dem Motto meines scharfsinnigen Vorbildes Sherlock Holmes:
"Wenn man das Unmögliche abzieht, dann muss das, was übrig bleibt, die Lösung sein,
wenn es auch noch so unwahrscheinlich klingt" (Für Star Trek Kinogänger: Nein, der Spruch
stammt nicht von einem Vorfahren des Mr. Spock !)
Und so kam ich auf die einzige plausible Lösung:
Es handelt sich um ein Memory Leak.
Ein Leck in der Erinnerung. Nicht zu verwechseln mit einer Gedächtnislücke, eher im Gegenteil.
Das Leck in der Erinnerung funktioniert ähnlich einem Wurmloch. Es ist ein Bruch im
normalen Raum-Zeit-Kontinuum, der dafür sorgt, dass Gedächtnisinhalte (Memories)
zwischen zwei Paralleluniversen ausgetauscht werden.
In einem anderen Universum hatte ich den Fehler tatsächlich gefunden und behoben, und
diese Erinnerung schlüpfte nun durch das Leak in mein diesseitiges Hirn.
Ja, so muss es sein! Und da ich nun endlich die Erklärung hatte, konnte ich mich wieder
beruhigt meiner Arbeit zuwenden ...
2010-10-05
2010-09-03
Modernes Personalmanagement ...
Schritt 1: Nicht Einsehen, dass ein Acker gepflügt und bewässert werden muss. Kostet nur Geld und Arbeit, und den Pflanzen geht es doch gut.
Schritt 2: Sich wundern, dass die Erträge mit der Zeit immer geringer werden.
Schritt 3. An den Pflanzen ziehen, damit sie besser wachsen.
Schritt 4: Den Nutzpflanzen die Schuld geben. Andere Pflanzen gedeihen schliesslich auch.
Schritt 5: Die verdorrten Nutzpflanzen ausreissen.
Schritt 6: Lamentieren, dass der trockene Distelacker keinen Ertrag bringt.
Schritt 7: Den Acker als "potenziell ertragreich" anpreisen und schleunigst abstoßen.
Schritt 8: Das Weite suchen.
Schritt 2: Sich wundern, dass die Erträge mit der Zeit immer geringer werden.
Schritt 3. An den Pflanzen ziehen, damit sie besser wachsen.
Schritt 4: Den Nutzpflanzen die Schuld geben. Andere Pflanzen gedeihen schliesslich auch.
Schritt 5: Die verdorrten Nutzpflanzen ausreissen.
Schritt 6: Lamentieren, dass der trockene Distelacker keinen Ertrag bringt.
Schritt 7: Den Acker als "potenziell ertragreich" anpreisen und schleunigst abstoßen.
Schritt 8: Das Weite suchen.
2008-09-10
Just a quote ...
Perfection is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
Antoine de Saint-Exupery
Perfektion wird nicht erreicht, wenn es nichts mehr hinzuzufügen, sondern wenn es nichts mehr wegzunehmen gibt.
2008-07-04
Ich bin ein E-Mail Könner ...
... na sowas!
Hat der Test im Manager-Magazin ergeben.
Somit: Netter Test, schmeichelndes Ergebnis, Signifikanz fraglich.
Hat der Test im Manager-Magazin ergeben.
Und wie immer bei solchen Tests: Vielleicht hätte ich noch drei bis fünf Punkte rausholen können, wenn die Antworten bei ein paar Fragen nicht gar so restriktiv gewesen wären.E-MAIL-KNIGGE-TESTSie sind ein E-Mail-Könner!
Sie haben 60 von 72 möglichen Punkten erreicht.
Ihre E-Mail-Kompetenz ist gut. Sie nutzen E-Mails häufig und sehr bewusst und wissen, in welcher Situation Sie welche E-Mail zu schreiben haben. Zum Schluss ein Tipp: Die E-Mail ist viel weniger ein Geschäftsbrief, als häufig angenommen - sie ähnelt vielmehr der mündlichen Kommunikation. Rasch wechseln Ansprechpartner, Situationen und Themen. Läuft ein E-Mail-Dialog mal nicht so glücklich, analysieren Sie die Fehler. Suchen Sie nach möglichen Gründen und probieren Sie andere Stilmittel.
Somit: Netter Test, schmeichelndes Ergebnis, Signifikanz fraglich.
2008-06-17
Download Day: Mozilla Team erbost Fans
Da wurde groß seit Monaten die Werbetrommel gerührt für den Download Day, da Mozilla mit seinem Firefox 3 in das Guiness Buch der Rekorde möchte, doch am heutigen 17. Juni sind viele User rund um den Globus enttäuscht und erbost über die "amerikanische Arroganz".
So wurde auf der Homepage des Download-Events mal gar kein Datum angekündigt. Erst auf der Übersichtsseite der abgegebenen Versprechen ist nun das Datum zu sehen:
The official date for the launch of Firefox 3 is June 17, 2008. Join our community and this effort by pledging today.
Doch leider bekommt man erst über Umwege mitgeteilt, dass der 17. Juni eben nicht für jedermann in der Welt der 17. Juni ist. Das Mozilla-Team jedenfalls versteht darunter 10:oo Uhr Lokalzeit San Francisco. Und ja, für uns ist der Dienstag, 17. Juni, dann schon fast rum, denn das entspricht in unserer Zeit 19:00 Uhr abends.
Fans in aller Welt haben sich auch entschlossen, zum Download-Day kleinere oder größere Feiern zu veranstalten, doch leider mussten diese in etlichen Ländern der Welt ohne den Download selbst stattfinden. So feiert man also ein wenig, ärgert sich, und geht ins Bett um dann vielleicht morgen noch den Download nachzuholen. Denn dann ist der 17. Juni auch in Amerika angekommen.
Kein Countdown auf der Zentralseite, und selbst wer sich heute vormittag (deutsche Zeit) erst registriert hat, bekommt in der Meldemail keine Informationen darüber, wann es denn los geht.
Man fragt sich schon, wieso im Zeitalter des Internet der modernste aller Browser nicht mit der zentralisierten Weltzeit (UTC) angepriesen wird. Und so gehen inzwischen die ersten potentiellen Download-Teilnehmer schon wieder ins Bett, und wenn sie Mozilla gnädig gesinnt sind, versuchen sie es halt am Mittwoch dem 18. nochmal.
Sorry Ihr Mozillaner, aber um einen Weltrekord mit Weltbeteilung aufzustellen muss man sich auch entsprechend Weltmännisch aufstellen. Da ist ja der Domino-Day besser organisiert!
Links zu Forenthreads:
So wurde auf der Homepage des Download-Events mal gar kein Datum angekündigt. Erst auf der Übersichtsseite der abgegebenen Versprechen ist nun das Datum zu sehen:
The official date for the launch of Firefox 3 is June 17, 2008. Join our community and this effort by pledging today.
Doch leider bekommt man erst über Umwege mitgeteilt, dass der 17. Juni eben nicht für jedermann in der Welt der 17. Juni ist. Das Mozilla-Team jedenfalls versteht darunter 10:oo Uhr Lokalzeit San Francisco. Und ja, für uns ist der Dienstag, 17. Juni, dann schon fast rum, denn das entspricht in unserer Zeit 19:00 Uhr abends.
Fans in aller Welt haben sich auch entschlossen, zum Download-Day kleinere oder größere Feiern zu veranstalten, doch leider mussten diese in etlichen Ländern der Welt ohne den Download selbst stattfinden. So feiert man also ein wenig, ärgert sich, und geht ins Bett um dann vielleicht morgen noch den Download nachzuholen. Denn dann ist der 17. Juni auch in Amerika angekommen.
Kein Countdown auf der Zentralseite, und selbst wer sich heute vormittag (deutsche Zeit) erst registriert hat, bekommt in der Meldemail keine Informationen darüber, wann es denn los geht.
Man fragt sich schon, wieso im Zeitalter des Internet der modernste aller Browser nicht mit der zentralisierten Weltzeit (UTC) angepriesen wird. Und so gehen inzwischen die ersten potentiellen Download-Teilnehmer schon wieder ins Bett, und wenn sie Mozilla gnädig gesinnt sind, versuchen sie es halt am Mittwoch dem 18. nochmal.
Sorry Ihr Mozillaner, aber um einen Weltrekord mit Weltbeteilung aufzustellen muss man sich auch entsprechend Weltmännisch aufstellen. Da ist ja der Domino-Day besser organisiert!
Links zu Forenthreads:
2008-06-13
Ach übrigens ....
So ganz nebenbei:
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Keine Ahnung, was das jetzt soll? Dann google mal:
09:F9:11:02:9D:74:E3:5B:D8:41:56:C5:63:56:88:C0
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Keine Ahnung, was das jetzt soll? Dann google mal:
09:F9:11:02:9D:74:E3:5B:D8:41:56:C5:63:56:88:C0
2008-06-03
Guiness Buch der Rekorde: Firefox 3 Downloadday 2008
Hallo zusammen, für alle, die es noch nicht wissen:
Das Firefox-Team will mit der Version 3 meines Webbrowser-Lieblings in das Guiness Buch der Rekorde, und zwar mit dem meisten Downloads an einem Tag.
Sie werden dazu einen Downloadday organisieren, dessen Datum aber zur Zeit noch nicht bekannt ist.
Weitere Infos, eine Übersicht der bisher abgegebenen weltweiten Downloadversprechen und mehr gibt es auf der Webseite spreadfirefox.com .
Das Firefox-Team will mit der Version 3 meines Webbrowser-Lieblings in das Guiness Buch der Rekorde, und zwar mit dem meisten Downloads an einem Tag.
Sie werden dazu einen Downloadday organisieren, dessen Datum aber zur Zeit noch nicht bekannt ist.
Weitere Infos, eine Übersicht der bisher abgegebenen weltweiten Downloadversprechen und mehr gibt es auf der Webseite spreadfirefox.com .
2008-05-16
2008-05-13
Freudscher Verprogrammierer
Du weißt, dass es zu heiß in deinem Büro ist, wenn du dich beim Tippen von folgendem Code ertappst:
import java.util.logging.*
private final static sLogger = Nogger.getNogger(...);
import java.util.logging.*
private final static sLogger = Nogger.getNogger(...);
2008-05-07
Na, wo isser denn ???
In einem Kommentar im Otherblog hat Matthias gefragt, wo der Rover den gerade steckt.
Well, ich hatte eine Auszeit, in der ich mich mal von den ständigen ernsten Themen zurückgezogen und mich gezielt meinen Hobbies gewidmet habe.
Auch in dem Umfeld war ich schreiberisch aktiv und kreativ, aber da merkt man nunmal hier nicht viel von.
(D.h.: vielleicht verlinke ich hier bald mal was davon).
Bald wird es im Otherblog auch wieder weitergehen. Versprochen ;-) .
Well, ich hatte eine Auszeit, in der ich mich mal von den ständigen ernsten Themen zurückgezogen und mich gezielt meinen Hobbies gewidmet habe.
Auch in dem Umfeld war ich schreiberisch aktiv und kreativ, aber da merkt man nunmal hier nicht viel von.
(D.h.: vielleicht verlinke ich hier bald mal was davon).
Bald wird es im Otherblog auch wieder weitergehen. Versprochen ;-) .
2008-04-08
Der Geek am Abend ...
Wann weisst du, dass du dich zuviel mit Computern beschäftigst?
Wenn du das Wort "Hubschrauber" liest und es für einen Kosenamen für den Netzwerktechniker hältst!
Wenn du das Wort "Hubschrauber" liest und es für einen Kosenamen für den Netzwerktechniker hältst!
2008-02-15
Esoteric Programming Language: CopyNPaste
Well, there is just a good bunch of Esoteric Programming Languages on the market, some really serious (means: causing serious damage to your brain), some meant as a joke .
Sigh, would I have more time, I could contribute with an idea for a new one.
What makes modern PLs so successful? It is that they express common programming patterns and paradigms directly on the code level.
A good example is Scala, which incorporates e.g. the singleton pattern with the keyword 'object', or implicit getter/setter generation for a property (you find that in Groovy too).
And here is the new idea, here is one pattern which was never implemented on language level:
Copy and Paste.
Really, a such often used pattern, and no language designed for it ....
And it would be so easy!
Simply take a base language, say: Java.
There you could have a class with a method, say:
In Java, adding a new method which also iterates over its input, but does some other impressing stuff with the elements and does not return a collection would be very annoying. You would copy and paste the above method and change the parts which shall differ from the original version per hand.
But why doing it yourself if your computer can do it for you? So it would be much better to simply tell your computer what to do, and the best way is to make this an integral part of the language itsself.
So the job could be done very easy with CopyNPaste, a language based on Java, but with additional features:
It will indeed become more interesting if the second method will be used as template for a third one ...
The advantages are obvious: You have to think only once about the way the first method doSomething() shall work. Then you are free to concentrate on how the method doSomeOtherThing() differs from that method.
You are free to think in your copy and paste paradigm without leaving this context when doing the new coding.
Thinks can be so easy ...
Sigh, would I have more time, I could contribute with an idea for a new one.
What makes modern PLs so successful? It is that they express common programming patterns and paradigms directly on the code level.
A good example is Scala, which incorporates e.g. the singleton pattern with the keyword 'object', or implicit getter/setter generation for a property (you find that in Groovy too).
And here is the new idea, here is one pattern which was never implemented on language level:
Copy and Paste.
Really, a such often used pattern, and no language designed for it ....
And it would be so easy!
Simply take a base language, say: Java.
There you could have a class with a method, say:
1 public class MyTest {
2 ...
3 public Collection doSomething(Collection input) {
4 Collection newcoll = new SomeCollectionType();
5 Iterator iter = input.iterator();
6 while (iter.hasNext()) {
7 Element elem = (Element) iter.next();
8 Object someNewElem = somethingReallyImpressingDoneWith( elem );
9 newcoll.add( someNewElem );
10 }
11 }
12 }
In Java, adding a new method which also iterates over its input, but does some other impressing stuff with the elements and does not return a collection would be very annoying. You would copy and paste the above method and change the parts which shall differ from the original version per hand.
But why doing it yourself if your computer can do it for you? So it would be much better to simply tell your computer what to do, and the best way is to make this an integral part of the language itsself.
So the job could be done very easy with CopyNPaste, a language based on Java, but with additional features:
1 public class MyTest {
2 ...
3 public Collection doSomething(Collection input) {
4 Collection newcoll = new SomeCollectionType();
5 Iterator iter = input.iterator();
6 while (iter.hasNext()) {
7 Element elem = (Element) iter.next();
8 Object someNewElem = somethingReallyImpressingDoneWith( elem );
9 newcoll.add( someNewElem );
10 }
11 }
12
13 paste:: copy(L:{3-11}) -> {
14 onLine(1): s/Collection/void/ s/doSomething/doSomeOtherThing/ ;
15 delLine(2);
16 delLine(6);
17 onLine(5): delChar({1-21}) ; s/thingReallyImpressing/OtherThing/ ;
18 }
19 }
It will indeed become more interesting if the second method will be used as template for a third one ...
The advantages are obvious: You have to think only once about the way the first method doSomething() shall work. Then you are free to concentrate on how the method doSomeOtherThing() differs from that method.
You are free to think in your copy and paste paradigm without leaving this context when doing the new coding.
Thinks can be so easy ...
2008-02-13
Weisheit aus der Arbeitswelt
Schickte uns ein Kollege:
A train station is where trains stop.
A bus station is where busses stop.
A Work Station is where ...
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.
2007-10-12
(K)ubuntu und -studio und so....
So, nachdem ich damals mit Suse 6.3 und Debian 3.0 mit Linux in eine Pause gegangen bin, geht's jetzt mal wieder los. Warum?
Vier Gründe:
Nachdem ich Kubuntu nun ohne größere Probleme (nur mit einer durchwarteten Nacht) auf meinem PII 400 MHz mit 128 MB RAM laufen habe und das Dingen ganz locker meinen alten Epson Stylus 400 Printer und meinen HP PSC 1110 all-in-one angesprochen hat, fühlt es sich ganz gut an, das auch auf richtigen Rechnern zu installieren.
Demnächst wird es hier also ein paar Erlebnisberichte zu Linux in Rover's Camp geben.
Vier Gründe:
- Vista kommt mir nicht auf die Platte, und da XP irgendwann doch mal ausläuft, muss ich schauen, was danach kommt. M$ ist es möglichst nicht!
- Ich will mal endlich anfangen, mehr Musik auf meinem Rechner zu basteln, und Ubuntu hat mit der Studio-Version ja nun was passendes für mein Budget auf die Welt losgelassen.
- Ich war durch meinen Unix-geleiteten Werdegang ja immer sehr Linux-affin, jetzt gehe ich also back to the roots.
- ... äh ... hab ich vergessen. Setz einfach was ein ...
Nachdem ich Kubuntu nun ohne größere Probleme (nur mit einer durchwarteten Nacht) auf meinem PII 400 MHz mit 128 MB RAM laufen habe und das Dingen ganz locker meinen alten Epson Stylus 400 Printer und meinen HP PSC 1110 all-in-one angesprochen hat, fühlt es sich ganz gut an, das auch auf richtigen Rechnern zu installieren.
Demnächst wird es hier also ein paar Erlebnisberichte zu Linux in Rover's Camp geben.
2007-10-04
2007-08-21
Freier Artikel
Dieser Artikel ist absichtlich frei und enthält lediglich Text der erklärt, dass dieser Artikel absichtlich frei ist und lediglich Text enthält, der dies erklärt und ansonsten leer wäre und wäre ansonsten leer
2007-03-20
DreamTimeException
Für Java-Kenner ...
[FATAL] Fatal system error: End of virtuality reached,
falling back to real world
StackTrace:
au.inhabit.DreamtimeExeption: Broken dreamtime
at Office
at 08:15
at Monday
aborigined by:
org.det.absent.VirtualityException
at org.det.Brain.dream() (Brain.human: 42)
at org.det.Me.awareness()(Me.human: 0)
caused by:
org.det.body.OutOfBrainException
Abonnieren
Posts (Atom)

