Mit Tachyonen und Gold-Chip gegen Handystrahlen...

[Rafael Deliano]

"Warum einfach, wenn's komplizierter besser geht?"
Kenn ich ich nur ohne das "besser".

MfG JRD

----------------------------------------------------
The genius of a construction lies in its simplicity.
Everybody can build complicated things.
Sergei P. Korolev

http://en.wikipedia.org/wiki/Sergey_Korolyov

 

[Wiebus]

Hallo Rafael.

"Warum einfach, wenn's komplizierter besser geht?"

Kenn ich ich nur ohne das "besser".

Wer im trüben Fischen will, muss im Zweifelsfalle die Trübung erst
verursachen. ;-)

Mit freundlichem Gruß: Bernd Wiebus

http://www.dl0dg.de

 

[Guido Grohmann]

Rolf_Bombach schrieb:

Klaus Butzmann schrieb:

.... der bekloppterweise auch arbeiten geht und nicht mit einem AK47
durch Berlin zieht...

Gibt ja auch Mischlösungen. Ein Kollege im Ländle ist mal mit
ner AK47 auf dem Rücken mit dem Mopped in die Firma gesaust.
Das hat dann schon Panik in der Teppichetage hervorgerufen...

Nanu, wollte der zum Chef und sein Gehalt neu verhandeln?

Guido

 

[Axel Schwenke]

Dirk Ruth <d.ruth@itecnet.de> wrote:

Axel Schwenke schrieb:

Von Details abgesehen hast du gerade "Literate Programming"
wiedererfunden:

http://de.wikipedia.org/wiki/Literate_programming

Dann gibt es das also schon seit 1981 - sehr interessant.
Scheinbar bin ich also mit meinen Wünschen doch nicht so ganz allein.

Könnte ja jetzt die ketzerische Frage stelllen, wie Tex heute nach
fast 30 Jahren immer noch funktionieren kann und compilierbar ist,
wenn es doch mit so einem abstrusen Konzept entwickelt wurde.

Das könnte damit zusammenhängen, daß D.E.K. für jeden neu gefundenen
Bug in TeX einen Scheck ausstellt. Und daß die Summe auf den Schecks
sich jedes Jahr verdoppelt. Wenn Bill Gates das gemacht hättee, dann
wäre er jetzt wohl im Armenhaus

Allerdings sollte man anmerken, daß das heutige TeX automatisch nach
C konvertiert wurde. Pascal ist doch etwas zu obskur.


XL

 

[Guido Grohmann]

Stefan Reuther schrieb:

Klar gibt's auch Leute, die den Nachbarzimmerbewohner dennoch anrufen.

Wenn die Türen zu sind, warum nicht? "Kollege, komm mal her, sieh dir
mal an, was du schon wieder angestellt hast!"

Ich zähle nicht dazu. Ein bisschen Bewegung muss sein.

Das kommt dann, wenn ich den betreffenden suchen gehe. Ich meine, es
gibt zwar Telefone und Türen, aber es ist nicht immer notwendig, den
Kollegen aus einem Arbeitsgang zu reißen. Einige militante
Telefonbenutzer verstehen das nur nicht ...

Guido

 

[Thomas Schaerer]

Wiebus <bernd.wiebus@gmx.de> wrote:

Wer im tr?ben Fischen will, muss im Zweifelsfalle die Tr?bung erst
verursachen. ;-)

Das kann nur die Weisheit eines Politikers sein.

Gruss
Thomas
--
Mein ELKO-Buch ueber Opamp, OTA und Instrumentation-Amplifier:
http://www.elektronik-kompendium.de/shop/buecher/operationsverstaerker-und-instrumentationsverstaerker
(Aendere "akz" durch "isi" in der Mailadresse fuer Reply!)

 

[Guido Grohmann]

Rainer Buchty schrieb:

In article <4fk2m4tg5bh2fagk019qqag93g1dsk8rek@4ax.com>,
Dirk Ruth <d.ruth@itecnet.de> writes:
|
|> Ja das machst Du. Sonst aber wahrscheinlich keiner weiter auf dieser
|> Welt. In einem Ein-Mann-Team ist das auch völlig egal. Wenn aber 25
|> Entwickler an einem Projekt arbeiten, kann man aber erstmal die 25
|> Leute auf eine 6wöchige LaTex-Schulung schicken. Damit sind dann schon
|> mal 3 Mannjahre weg.

Wenn diese Leute 6 Wochen brauchen, um die Grundzüge von LaTeX zu erlernen,
dann wäre es höchste Zeit, sich von ihnen zu trennen.

Ja selbst für "HTML-Programmierer" <hust-hust> wäre das zu lange

Guido

 

[Rainer Buchty]

In article <4fk2m4tg5bh2fagk019qqag93g1dsk8rek@4ax.com>,
Dirk Ruth <d.ruth@itecnet.de> writes:
|>
|> Ja das machst Du. Sonst aber wahrscheinlich keiner weiter auf dieser
|> Welt. In einem Ein-Mann-Team ist das auch völlig egal. Wenn aber 25
|> Entwickler an einem Projekt arbeiten, kann man aber erstmal die 25
|> Leute auf eine 6wöchige LaTex-Schulung schicken. Damit sind dann schon
|> mal 3 Mannjahre weg.

Wenn diese Leute 6 Wochen brauchen, um die Grundzüge von LaTeX zu erlernen,
dann wäre es höchste Zeit, sich von ihnen zu trennen.

Es geht hier nicht um das Schreiben von Templates in TeX, sondern das
Verfassen von Dokumenten. Da braucht es weder esoterisches Wissen noch
langjährige Geek-Erfahrung.

Und ob man ein Symbol in irgendeiner Tabelle sucht und per Klick ins
Dokument schießt oder das Symbol in irgendeiner Tabelle sucht und als
\symbolname in den Text tut, ist nun wirklich kein Unterschied.

Außer, daß man nach kurzer Zeit die wichtigsten Symbole schneller getippt
hat als per Point&Click aus der Tabelle gelutscht.

|> Ein guter Standard fehlt leider. XML könnte diese Lücke schließen.

Dann müßte Dir Inkscape gefallen.

Rainer

 

[Stefan Reuther]

Dirk Ruth wrote:

Axel Schwenkeschrieb:
Von Details abgesehen hast du gerade "Literate Programming"
wiedererfunden:

Dann gibt es das also schon seit 1981 - sehr interessant.
Scheinbar bin ich also mit meinen Wünschen doch nicht so ganz allein.

Nun, schöne Softwaredokumentation wünscht sich natürlich jeder.

Könnte ja jetzt die ketzerische Frage stelllen, wie Tex heute nach
fast 30 Jahren immer noch funktionieren kann und compilierbar ist,
wenn es doch mit so einem abstrusen Konzept entwickelt wurde.

Ehrlich gesagt: als ich das letzte mal in die TeX-Quellen geschaut habe,
hab ich kein Wort verstanden. Dass man das schön nach TeX rendern kann,
ist ja schön und gut, aber es sollte ja auch einfach änderbar sein.

Meine andere Erfahrung mit Literate Programming kommt aus der Haskell-
Ecke. Dort hat der Compiler gleich das Feature eingebaut, nur Code
anzuschauen, der in \begin{code} / \end{code} eingefasst ist. Eigentlich
ist das eine feine Idee, so schreibt man seine Moduldokumentation, und
wenn man dann zu den Details kommt, streut man halt etwas Code ein, und
außerdem kann man das Ding nicht nur durch den Compiler, sondern auch
durch LaTeX nudeln.

In der Praxis sieht das so aus, dass da
\section{Declarations}
\begin{code}
steht, gefolgt von 500 Zeilen nicht weiter kommentiertem Code. Danach
\end{code}
\section{Implementation}
\begin{code}
und weitere 2000 Zeilen.

Also auch nicht besser als das übliche C-Modul, dessen einziger
Kommentar der automatisch generierte Lizenz-Header ist.


Stefan

 

[Stefan Reuther]

Dirk Ruth wrote:

Stefan Reuther schrieb:
Dirk Ruth wrote:
Wenn du in Excel eine Messreihe und daraus ein Diagramm erstellt hast,
dass dann wieder als Bild abgespeichert und in ASCII umgewandelt wird,
dann mußt du das Excel-Original nochmal irgendwo hinterlegen. Ändern
sich da mal ein paar Werte, muss die Grafik und das ASCII neu erzeugt
werden, weil du das mit den Punkten und Strichen usw. händisch nicht
so hinbekommst, wie ASCII-Art.

Warum sollte ich so einen Unfug machen? Natürlich hebe ich mir bei sowas
die Originaldaten auf, völlig egal, ob das nun eine Excel-Datei oder
eine Gnuplot-Eingabedatei ist. Schon, weil Word bei eingebetteten
Diagrammen gerne mal Mist macht. Aber es ging doch um Grafiken und
Skizzen, also Dinge, die man der Dokumentation wegen extra erstellt. Zum
Beispiel so ein schickes Blockdiagramm
[...]
Mit sowas bin ich in ASCII-Art dreimal schneller als mit der
Word-Malfunktion (malfunction? .

Word stand wie gesagt nicht zur Debatte.
Jetzt stell dir einfach mal eine Diagramm vor, indem 5
Temperaturkurven eingezeichnet sind.

Das als ASCII-Art ist wirklich Quatsch, falls du das unbedingt noch mal
in der Form von mir lesen wolltest. Aber mir geht es bei sowas mehr um
Blockdiagramme usw. Ich bin Softwerker, Messkurven machen andere

Mathematische oder physikalische Hindergründe oder Herleitungen halte
ich für recht wichtig bei der Code-Entwicklung. Schon allein um die
Präzision bei Rechenoperationen abschätzen zu können, ist es
unentbehrlich. Sowas will ich nicht in einem externen Dokument. Wenn
ich dann Summenformeln oder Integrale in Courier New in die Kommentare
schreiben muss, dann mach das keinen Spass.

Herleitungen müssen nicht unbedingt vollständig im Quelltext stehen. Da
reicht mir sowas:
/* This is the solution to
sqrt(a - sa*x) + sqrt(b - sb*x) = d
obtained with Mathematica.
[d = sqrt(d2), Anm.d.Posters] */
return ((a - b - d2)*sa - (a - b + d2)*sb + 2*sqrt(d2*(b*sa*sa
- (a+b-d2)*sa*sb + a*sb*sb)))
/
((sa-sb)*(sa-sb));
Wer nachrechnen will, darf das gerne tun, aber so genau muss es nun auch
nicht im Quelltext stehen.

Nein das reicht mir nicht als Dokumentation (auch nicht als
Kommentar).

Das reicht dir deswegen nicht, weil du nicht weißt, warum da
ausgerechnet 'sqrt(a - sa*x) + sqrt(b - sb*x) = d' gelöst wird, weil du
nicht weißt, was für ein Problem da mit welchem Ansatz gelöst wird. Das
Problem lautet, wenn du es wirklich wissen willst, "Auflösungen von
Überlappenden Minenfeldern in VGA Planets auf faire Weise", der Lösungs-
ansatz ist in einem 120 Zeilen langen Kommentar ein paar Seiten weiter
oben dokumentiert.

Aber die Auflösungsschritte, wie man von der Originalgleichung zu dem
Monsterausdruck als Lösung kommt, gehören nicht in den Code, auch wenn
man da Seiten mit füllen könnte (was ich in der Tat versucht habe, bevor
ich nach ca. 5 A3-Blättern zu Mathematica gegriffen habe). Wenn du mal
s=a/2*t˛ oder R=U/I umstellst, konservierst du das ja auch nicht auf
Ewigkeiten in der Entwurfsmappe.


Stefan

 

[Stefan Reuther]

Dirk Ruth wrote:

Alexander Schreiberschrieb:
Zum Programmieren nimmt man Schriftarten mit fester Breit, Problem
geloest. Proportionalschriften machen bei ASCII-Format nun wirklich
keinen Sinn.

Beim Programmierren lasse ich den Entwicklern frei Hand, wie sie ihren
Text-Editor einstellen möchten. Farbe, Schriftart usw. schreibe ich
niemanden vor. Jeder kann sich seinen Arbeitsplatz so einrichten, dass
er am effektivsten arbeiten kann.

Da im allgemeinen in Teams gearbeitet wird, sollten schon ein paar
Standards her. Das üblichste ist da schon "Festbreitenschrift, keine Tabs."

Mal ebenso ein paar mathematische Formeln
einzufügen wird da echt zur Qual.

Schreibs halt im LaTeX-Format, das ist relativ gut lesbar. BTDT ;-)

Ja das machst Du. Sonst aber wahrscheinlich keiner weiter auf dieser
Welt.

Doxygen kannst du wohl als Quasi-Standard ansehen, und der unterstützt
Formeln in LaTeX-Syntax (was wohl daran liegt, dass er LaTeX nimmt, um
sie zu rendern).

In einem Ein-Mann-Team ist das auch völlig egal. Wenn aber 25
Entwickler an einem Projekt arbeiten, kann man aber erstmal die 25
Leute auf eine 6wöchige LaTex-Schulung schicken. Damit sind dann schon
mal 3 Mannjahre weg.

Wenn die Leute ihr Handwerk verstehen, reicht es, ihnen ein Blatt mit
den grundlegenden Befehlen und ein paar Beispielen nebst Link zur Doku
in die Hand zu drücken. Da braucht's keine Schulung. Das ist keine
Raketenwissenschaft.

Teamarbeit funktioniert nur, wenn es Standards gibt. LaTex im
Quellcode ist kein Standard.

"LaTeX im Quellcode" ist dank Doxygen mehr Standard als du denkst. Nur
Romane schreibt damit halt keiner.

Ein guter Standard fehlt leider. XML könnte diese Lücke schließen.

XML kombiniert an der Stelle nur den allgemeinen Nachteil von XML
(umständlich zu notieren) mit der Tatsache, inkompatibel zu allem
existierenden zu sein.

Du darfst allerdings in einem Doxygen-Kommentar auch HTML verwenden. Ist
ja fast XML.


Stefan

 

[Gerrit Heitsch]

Stefan Reuther wrote:

Dirk Ruth wrote:
Alexander Schreiberschrieb:
Zum Programmieren nimmt man Schriftarten mit fester Breit, Problem
geloest. Proportionalschriften machen bei ASCII-Format nun wirklich
keinen Sinn.
Beim Programmierren lasse ich den Entwicklern frei Hand, wie sie ihren
Text-Editor einstellen möchten. Farbe, Schriftart usw. schreibe ich
niemanden vor. Jeder kann sich seinen Arbeitsplatz so einrichten, dass
er am effektivsten arbeiten kann.

Da im allgemeinen in Teams gearbeitet wird, sollten schon ein paar
Standards her. Das üblichste ist da schon "Festbreitenschrift, keine Tabs."

Wie das ganze bei jedem einzelnen Programmierer aussieht kann dir doch
egal sein. Nachdem der Quelltext sowieso reiner Text ist merkt er sich
die Einstellungen dort nicht.

Gerrit

 

[Stefan Reuther]

Gerrit Heitsch wrote:

Stefan Reuther wrote:
Dirk Ruth wrote:
Beim Programmierren lasse ich den Entwicklern frei Hand, wie sie ihren
Text-Editor einstellen möchten. Farbe, Schriftart usw. schreibe ich
niemanden vor. Jeder kann sich seinen Arbeitsplatz so einrichten, dass
er am effektivsten arbeiten kann.

Da im allgemeinen in Teams gearbeitet wird, sollten schon ein paar
Standards her. Das üblichste ist da schon "Festbreitenschrift, keine
Tabs."

Wie das ganze bei jedem einzelnen Programmierer aussieht kann dir doch
egal sein. Nachdem der Quelltext sowieso reiner Text ist merkt er sich
die Einstellungen dort nicht.

Wenn er sich nicht an die zwei Dinge hält, produziert er aber
Buchstabensuppe, die bei allen anderen sch***e aussieht.


Stefan

 

[Gerrit Heitsch]

Stefan Reuther wrote:

Meine andere Erfahrung mit Literate Programming kommt aus der Haskell-
Ecke. Dort hat der Compiler gleich das Feature eingebaut, nur Code
anzuschauen, der in \begin{code} / \end{code} eingefasst ist.

Na prima. Wetten das da kaum einer kommentiert wenn er sich fuer jeden
Kommentar mit einem \begin{code} und \end{code} die Finger verbiegen
muss? Kommentare muessen einfach zu definieren sein, also wie '#' in der
Shell/PERL oder '//' in C++ sonst benutzt sie keiner.

In der Praxis sieht das so aus, dass da
\section{Declarations}
\begin{code}
steht, gefolgt von 500 Zeilen nicht weiter kommentiertem Code. Danach
\end{code}
\section{Implementation}
\begin{code}
und weitere 2000 Zeilen.

Bei dieser *zensiert*-Syntax wundert mich das nicht die Bohne.

Gerrit

 

[Alexander Schreiber]

Dirk Ruth <d.ruth@itecnet.de> wrote:

Alexander Schreiberschrieb:
"
Dirk Ruth <d.ruth@itecnet.de> wrote:

Zum Programmieren nimmt man Schriftarten mit fester Breit, Problem
geloest. Proportionalschriften machen bei ASCII-Format nun wirklich
keinen Sinn.


Beim Programmierren lasse ich den Entwicklern frei Hand, wie sie ihren
Text-Editor einstellen möchten. Farbe, Schriftart usw. schreibe ich
niemanden vor. Jeder kann sich seinen Arbeitsplatz so einrichten, dass
er am effektivsten arbeiten kann.


Mal ebenso ein paar mathematische Formeln
einzufügen wird da echt zur Qual.

Schreibs halt im LaTeX-Format, das ist relativ gut lesbar. BTDT ;-)


Ja das machst Du. Sonst aber wahrscheinlich keiner weiter auf dieser
Welt. In einem Ein-Mann-Team ist das auch völlig egal. Wenn aber 25
Entwickler an einem Projekt arbeiten, kann man aber erstmal die 25
Leute auf eine 6wöchige LaTex-Schulung schicken. Damit sind dann schon
mal 3 Mannjahre weg.

Du hast Leute, die 6 Wochen Schulung braeuchten um die LaTeX-Grundlagen zu
erlernenm aber als Programmierer arbeiten? Hast Du Dir etwa vom Arbeitsamt
"umgelernte" Maurer andrehen lassen? Wirf sie raus und heuer Leute an, die
was koennen. Die brauchen dann auch keine 6 Wochen, sondern, wenn es nur um
die mathematische Syntax fuer den Formelsatz geht, einen Vormittag und die
Referenz zum Nachsehen der Symbole fuer die erste Zeit.

Teamarbeit funktioniert nur, wenn es Standards gibt. LaTex im
Quellcode ist kein Standard.

Es ist einer, frei nach Tanenbaum[0] ;-)

Ein guter Standard fehlt leider. XML könnte diese Lücke schließen.

Naja, ich kann dem "XML ueber alles" Hype nicht wirklich viel abgewinnen.
Und wie Microsoft bewiesen hat, kann man auch XML-basierte Formate so
widerwaertig vergurken wie binaere.

Man liest sich,
Alex.
[0] The nice thing about standards is that you have so many to choose from.
Furthermore, if you do not like any of them, you can just wait for next
year's model. -- Andrew S. Tanenbaum: Computer Networks
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

 

[Falk Willberg]

Stefan Reuther schrieb:

Gerrit Heitsch wrote:
Stefan Reuther wrote:
Dirk Ruth wrote:
Beim Programmierren lasse ich den Entwicklern frei Hand, wie sie ihren
Text-Editor einstellen möchten. Farbe, Schriftart usw. schreibe ich
niemanden vor. Jeder kann sich seinen Arbeitsplatz so einrichten, dass
er am effektivsten arbeiten kann.
Da im allgemeinen in Teams gearbeitet wird, sollten schon ein paar
Standards her. Das üblichste ist da schon "Festbreitenschrift, keine
Tabs."
Wie das ganze bei jedem einzelnen Programmierer aussieht kann dir doch
egal sein. Nachdem der Quelltext sowieso reiner Text ist merkt er sich
die Einstellungen dort nicht.

Wenn er sich nicht an die zwei Dinge hält, produziert er aber
Buchstabensuppe, die bei allen anderen sch***e aussieht.

Komische Editoren benutzt ihr... Klingt eher nach einer Textverarbeitung.

Falk
P.S.: :1,$s/ /^I/g

 

[Alexander Schreiber]

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:

Stefan Reuther wrote:
Dirk Ruth wrote:
Alexander Schreiberschrieb:
Zum Programmieren nimmt man Schriftarten mit fester Breit, Problem
geloest. Proportionalschriften machen bei ASCII-Format nun wirklich
keinen Sinn.
Beim Programmierren lasse ich den Entwicklern frei Hand, wie sie ihren
Text-Editor einstellen möchten. Farbe, Schriftart usw. schreibe ich
niemanden vor. Jeder kann sich seinen Arbeitsplatz so einrichten, dass
er am effektivsten arbeiten kann.

Da im allgemeinen in Teams gearbeitet wird, sollten schon ein paar
Standards her. Das üblichste ist da schon "Festbreitenschrift, keine Tabs."

Wie das ganze bei jedem einzelnen Programmierer aussieht kann dir doch
egal sein. Nachdem der Quelltext sowieso reiner Text ist merkt er sich
die Einstellungen dort nicht.

Tabs vs. Spaces ist ein vorprogrammiertes Konfliktpunkt, wenn man das
nicht von vornherein auf "no tabs[0], spaces only" festlegt. Das faengt
damit an, dass man Tabs ja auf beliebige Laenge einstellen kann und geht
dann weiter, wenn Quelltexte gemischt mit Tabs und Spaces editiert werden.

Man liest sich,
Alex.
[0] Ausser Makefiles, *grrr*
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

 

[Alexander Schreiber]

Falk Willberg <Faweglassenlk@falk-willberg.de> wrote:

Stefan Reuther schrieb:
Gerrit Heitsch wrote:
Stefan Reuther wrote:
Dirk Ruth wrote:
Beim Programmierren lasse ich den Entwicklern frei Hand, wie sie ihren
Text-Editor einstellen möchten. Farbe, Schriftart usw. schreibe ich
niemanden vor. Jeder kann sich seinen Arbeitsplatz so einrichten, dass
er am effektivsten arbeiten kann.
Da im allgemeinen in Teams gearbeitet wird, sollten schon ein paar
Standards her. Das üblichste ist da schon "Festbreitenschrift, keine
Tabs."
Wie das ganze bei jedem einzelnen Programmierer aussieht kann dir doch
egal sein. Nachdem der Quelltext sowieso reiner Text ist merkt er sich
die Einstellungen dort nicht.

Wenn er sich nicht an die zwei Dinge hält, produziert er aber
Buchstabensuppe, die bei allen anderen sch***e aussieht.

Komische Editoren benutzt ihr... Klingt eher nach einer Textverarbeitung.

Falk
P.S.: :1,$s/ /^I/g

Oder schlicht beim Codereview Sourcen mit Tabs[0] als nicht OK zurueckgehen
lassen.

Man liest sich,
Alex
[0] Ausser halt da, wo noetig, siehe Makefiles
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

 

[Alexander Schreiber]

Michael Eggert <m.eggert.nul@web.de> wrote:

Thomas 'Tom' Malkus <tom@isnix.de> wrote:

Moin!

Aber die Büros sehen so aus wie die Ausstellung bei IKEA.

Jau, denn auch bei IKEA wären die Billardkugeln am Tisch festgeklebt:
http://picasaweb.google.com/zurich.office.images/ZurichOfficePhotos#5174254532920134562
http://picasaweb.google.com/zurich.office.images/ZurichOfficePhotos#5174254631704382386



Also, so ein ganz klein wenig gestellt schauts doch aus...

Das erste Foto (mit Leuten) ist normaler Anblick in dem Microkitchen.
Und nein, die Kugeln sind nicht festgeklebt, das haetten wir dann doch
beim regelmaessigen Spiel gemerkt ;-)

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

 

[Kai-Martin Knaak]

On Mon, 05 Jan 2009 18:53:48 +0100, Stefan Reuther wrote:

In der Praxis sieht das so aus, dass da
\section{Declarations}
\begin{code}
steht, gefolgt von 500 Zeilen nicht weiter kommentiertem Code. Danach
\end{code}
\section{Implementation}
\begin{code}
und weitere 2000 Zeilen.

Ein gutes Beispiel dafĂźr, dass lesbarer Code in erster Linie ein soziales
Problem ist. Wenn der Programmier-Sklave Dienst nach Syntaxvorschrift
macht, hilft auch die beste Infrastuktur nichts.

---<(kaimartin)>---