Mit Tachyonen und Gold-Chip gegen Handystrahlen...

[Thomas 'Tom' Malkus]

Alexander Schreiber meinte:

Also ich finde es schon praktisch, wenn das Team komplett in einem Raum sitzt.
So kann man mal quer durch den Raum rufen, fix zum Kollegen ruebergehen oder
auf Zuruf ein Designmeeting abhalten.

Ich habe mal in einem Trakt gearbeitet, da hatten die Büros alle
Zwischentüren, ich saß alleine, nebenan 3 Leute, dann wieder einer.
Oft hatten wir die Türen offen, bei Bedarf dann aber die Tür zu
schließen ist auch nicht übel.

an den anderen Standorten. Wobei es da immens hilft, wenn man 1-2 mal im
Jahr rueberfliegt und 2-3 Wochen wirklich in persona zusammenarbeitet.

Das glaube ich, ich habe mindestens eine jährliche Tour nach Österreich und
bin dann nur auf den Höfen unterwegs. Das bringt unheimlich was.

Gratuliere - viel Erfolg!

Danke, jetzt fehlt nur noch die Online-Hilfe.

73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19

 

[Stefan Reuther]

Alexander Schreiber wrote:

Thomas 'Tom' Malkus <tom@isnix.de> wrote:
Alexander Schreiber meinte:
ausgegeben wird. Und die Ausstattung des Office ist zwar teurer als eine
08/15 Cubefarm, aber unterm Strich ist das
- nicht so superteuer
- zahlt sich im positiven Effekt auf die Mitarbeitermotivation locker aus

Cubefarm finde ich absolut eklig. Selbst bei den Fotos, auch wenn es
nett aussieht und schon wesentlich besser, ich mag diese Großraumbüros
überhaupt nicht.

Also ich finde es schon praktisch, wenn das Team komplett in einem Raum sitzt.
So kann man mal quer durch den Raum rufen, fix zum Kollegen ruebergehen oder
auf Zuruf ein Designmeeting abhalten.

Dazu braucht man aber keine Cubes. Wir haben hier "normale" Labore mit,
je nach Größe, 2..6 Personen drin. Da müssen das spontan einberufene
Meeting nicht 20 Cubefarm-Bewohner mithören. Und "mal eben rübergehen"
ist ja nun auch dann nicht schwer, wenn man da zwei Türen und eine Gang-
Ecke passieren muss.

Klar gibt's auch Leute, die den Nachbarzimmerbewohner dennoch anrufen.
Ich zähle nicht dazu. Ein bisschen Bewegung muss sein.


Stefan

 

[Dirk Ruth]

Axel Schwenkeschrieb:
"

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

Kommentare im Source Code sind IMHO keine Dokumentation. Das sehen
auch Behoerden oft so. Was aus den Tools rauskommt, ist teilweise
haarstraeubend. Oft genug "genossen".

Kennst Du http://www.stack.nl/~dimitri/doxygen ?

Das reicht nicht. Man braucht drei Arten von Dokumentation:

1. API-Dokumentation. Dafür (und *nur dafür) sind Doxygen, JavaDoc &
Freunde ganz brauchbar. Ich hab in der Vergangenheit auch Perceps
gern dafür genutzt. Perceps ist im Prinzip wie Doxygen. Allerdings
nutzt es Templates und kann so z.B. auch LaTeX erzeugen.

2. High-Level Dokumentation. Funktionsprinzipien, Konfigurations-
parameter, Dateiformate, Hintergrundinfos.

Exakt.
Source-Code wird mit reinen Texteditoren erstellt und mehr können die
auch nicht. Tabellen sind schon eine Qual und Grafiken wie Skizzen
oder Flussdiagramme gehen gar nicht. ASCII-Art will man da nicht
wirklich drin haben.
Wundert mich eigendlich, dass MS noch nichts richtiges eingefallen
ist, um Sourcen und Doku zusammen zu führen.

Dirk

 

[Gerrit Heitsch]

Dirk Ruth wrote:

Exakt.
Source-Code wird mit reinen Texteditoren erstellt und mehr können die
auch nicht. Tabellen sind schon eine Qual und Grafiken wie Skizzen
oder Flussdiagramme gehen gar nicht. ASCII-Art will man da nicht
wirklich drin haben.
Wundert mich eigendlich, dass MS noch nichts richtiges eingefallen
ist, um Sourcen und Doku zusammen zu führen.

Weil es dann kein reiner Text mehr waere und das will man wirklich
nicht. Waere so, als wenn du deinen Source in MS-Word schreibst und dann
auch nur damit wieder lesen kannst.

Gerrit

 

[Stefan Reuther]

Dirk Ruth wrote:

Axel Schwenkeschrieb:
2. High-Level Dokumentation. Funktionsprinzipien, Konfigurations-
parameter, Dateiformate, Hintergrundinfos.

Exakt.
Source-Code wird mit reinen Texteditoren erstellt und mehr können die
auch nicht. Tabellen sind schon eine Qual und Grafiken wie Skizzen
oder Flussdiagramme gehen gar nicht. ASCII-Art will man da nicht
wirklich drin haben.

Warum nicht?

Für einfache Blockdiagramme kenne ich nichts unkomplizierteres. Zum
Beispiel Datenstrukturen dokumentiere ich gerne mal so im Quelltext.
Und in den High-Level-Dokumentationen findest du auch gerne mal ASCII-
Art. Geht einfach schneller und einfacher als mit der Word-Malfunktion.

Wundert mich eigendlich, dass MS noch nichts richtiges eingefallen
ist, um Sourcen und Doku zusammen zu führen.

WIMRE hatten sie mal ein Doxygen-Workalike (Autoduck?).


Stefan

 

[Dirk Ruth]

Gerrit Heitschschrieb:
"

Dirk Ruth wrote:


Exakt.
Source-Code wird mit reinen Texteditoren erstellt und mehr können die
auch nicht. Tabellen sind schon eine Qual und Grafiken wie Skizzen
oder Flussdiagramme gehen gar nicht. ASCII-Art will man da nicht
wirklich drin haben.
Wundert mich eigendlich, dass MS noch nichts richtiges eingefallen
ist, um Sourcen und Doku zusammen zu führen.

Weil es dann kein reiner Text mehr waere und das will man wirklich
nicht. Waere so, als wenn du deinen Source in MS-Word schreibst und dann
auch nur damit wieder lesen kannst.

Muss nicht sein.
Ich stelle mir eher einen Editor vor, der seine Daten in XML
abspeichert. Mitten in den Sourcen könnte ich dann einen Container
einfügen, in dem ich beliebige Daten einwerfen kann (Skizzen,
Programm-Ablaufpläne, Ergebnisse aus Meetings oder Telefongesprächen
usw.) . Sollte doch mit OLE, oder wie das mal hieß, zu machen sein.
Den Container kann man dann wieder zuklappen, so dass am Seitenrand
nur ein kleiner Link erscheint (PDF kennt sowas ähnliches als
Notiz-Funktion).
Sowas habe ich schon immer vermisst. Stattdessen liegt der Kram meißt
quer über die Server verteilt in mehr oder weniger sinvoll benannten
Verzeichnissen und ohne Versionierung.
Nach einem Jahr sucht man dann ewig, bis man das Gesprächs- oder
Meeting-Protokoll gefunden hat, warum der Code an genau der Stellle so
geändert wurde, weil Kunde am xx.yy.2007 wollte, dass die Funktion nun
genau so sein soll.
Mir fällt gerade ein, dass man darin auch wunderbar die Zeiten für
Codeerstellung, Debugging usw. mitführen könnte, um die
Softwareentwicklung besser messbar zu machen, was ja essentiell für
die Projektplanung ist.
Könnte man zu jeder Info, die in den Container kommt, ein Tag
auswählen, dann ließe sich die Ausgabe wunderbar filtern, also z.B.
Code, Hilfe, Doku, Verwaltung, Fehlertracking usw.

Word halte ich da für völlig ungeeignet, da wird alles nur stumpf
zusammen gemixt.

Dirk

 

[Falk Willberg]

Dirk Ruth schrieb:
....

Ich stelle mir eher einen Editor vor, der seine Daten in XML
abspeichert. Mitten in den Sourcen könnte ich dann einen Container
einfügen, in dem ich beliebige Daten einwerfen kann (Skizzen,
Programm-Ablaufpläne, Ergebnisse aus Meetings oder Telefongesprächen
usw.) . Sollte doch mit OLE, oder wie das mal hieß, zu machen sein.

Klar, dann kann man nur noch mit dem OS eines einzigen Herstellers
programmieren.

Den Container kann man dann wieder zuklappen, so dass am Seitenrand
nur ein kleiner Link erscheint (PDF kennt sowas ähnliches als
Notiz-Funktion).

Danke, in C-sourcen will ich C-Syntax und sonst nix.

Sowas habe ich schon immer vermisst. Stattdessen liegt der Kram meißt
quer über die Server verteilt in mehr oder weniger sinvoll benannten
Verzeichnissen und ohne Versionierung.

Dagegen hilft seit Jahren RCS oder ein Klicki-Bunti Versions-Kontrollsystem.

Nach einem Jahr sucht man dann ewig, bis man das Gesprächs- oder
Meeting-Protokoll gefunden hat, warum der Code an genau der Stellle so
geändert wurde, weil Kunde am xx.yy.2007 wollte, dass die Funktion nun
genau so sein soll.

Sowas schreibe ich in Kommentare. Größere Änderungen werden mit RCS
dokumentiert.

Ich schreibe seit Jahren Software mit vi, die Abhängigkeiten prüft make,
kompilieren tue ich mit gcc.

Jetzt habe ich das erste Projekt, bei dem ich mit Codewarrior arbeiten
*muß*. Seit ich den unter wine benutzen kann, macht es auch wieder Spaß.
Jetzt muß ich mich nicht mehr mit seinen Zicken herumschlagen, sondern
kann mich der Software widmen.
....

Falk

 

[Dirk Ruth]

Stefan Reutherschrieb:
"

Dirk Ruth wrote:
Axel Schwenkeschrieb:
2. High-Level Dokumentation. Funktionsprinzipien, Konfigurations-
parameter, Dateiformate, Hintergrundinfos.

Exakt.
Source-Code wird mit reinen Texteditoren erstellt und mehr können die
auch nicht. Tabellen sind schon eine Qual und Grafiken wie Skizzen
oder Flussdiagramme gehen gar nicht. ASCII-Art will man da nicht
wirklich drin haben.

Warum nicht?

Für einfache Blockdiagramme kenne ich nichts unkomplizierteres. Zum
Beispiel Datenstrukturen dokumentiere ich gerne mal so im Quelltext.
Und in den High-Level-Dokumentationen findest du auch gerne mal ASCII-
Art. Geht einfach schneller und einfacher als mit der Word-Malfunktion.

Word ist für nichts anderes geeignet, als gelegendlich mal einen Brief
zu schreiben, der aber auch nicht zu lang sein darf.
Ich glaube, da sind wir uns auch einig.

ASCII-Art ist eher ein workaround für dieses Problem. Ein so
eingefügtes Diagramm oder Grafik will hinterher keiner mehr ändern,
wenn man nicht irgendwo die originalen Quellen dafür hinterlegt hat.
Hinzu kommt, dass die Auflösung sehr begrenzt ist und alle Entwickler
die gleichen Schriftparameter eingestellt haben müssen, damit es in
etwa auch gleich aussieht. Mal ebenso ein paar mathematische Formeln
einzufügen wird da echt zur Qual.
Hier hängt die Entwicklung der Entwicklungsumgebungen m.E. den
Anforderungen weit hinterher

Dirk

 

[Joerg]

Gerhard Hoffmann wrote:

On Sat, 03 Jan 2009 12:40:45 -0800, Joerg <notthisjoergsch@removethispacbell.net> wrote:

Nimm es jetzt nicht uebel, aber genau das kritisiere ich an SW Projekten
oft. Kommentare im Source Code sind IMHO keine Dokumentation. Das sehen
auch Behoerden oft so. Was aus den Tools rauskommt, ist teilweise
haarstraeubend. Oft genug "genossen".

Das kommt doch nur darauf an, was man an Kommentaren reinschreibt.
Wer
i <= i + 1; -- i incrementieren

akzeptiert ist selber schuld.

Und das ist es, da stehen oft Sachen drin, die nur eingefleischte
Programmierer verstehen. Oft nur welche, die das Projekt kennen.

Wie auch immer, das geht in regulierten Bereichen eh meist nicht. Dort
muss die Doku vor oder waehrend des Projekts entstehen, nicht als
laestige Taetigkeit hinterher.

Ein ordentlicher Textblock im header ist im Zweifelsfall das
einzige, was langfristig mit dem eigentlichen Programm
konsistent ist. Wenn man erst die Doku aus Subversion
auschecken muss, mit tex/word/writer ändern und wieder
einchecken muss, macht das eben irgendwann am Freitag um 1
jemand nicht mehr. Am Montag um 9 ist das längst vergessen.



Gruß, Gerhard

(der sich jetzt einen rant über Management by Visio verkneift)

Bei uns war's immer Gantt ...

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

 

[Joerg]

Reinhard Zwirner wrote:

Thomas 'Tom' Malkus schrieb:
Reinhard Zwirner meinte:
Thomas 'Tom' Malkus schrieb:
Axel Schwenke meinte:
...
... in erster Linie ein Zeichen schlechter Organisation. Entweder
hast du dir einen zu großen Brocken aufgeladen und solltest tat-
sächlich besser jemanden einstellen. Oder du hast dich bei der
Abschätzung von Aufwand und/oder der Festlegung der Deadline über
den Tisch ziehen lassen.
Saisongeschäft kennst Du? ...
das, was Axel beschreibt, hat nichts mit Saisongeschäft zu tun!
Doch, weil es eine Antwort auf die Darstellung meiner Arbeit als
Selbständiger ist und sich auch nur darauf bezog, bzw. auf die
"Einzelkämpfer" in der Branche. In dem obigen Absatz spricht Axel
auch mich direkt an.

Aber Deine Situation als Selbständiger ist absolut nicht
repräsentativ für die Arbeitssituation der in diesem Fred
als Mangelware bezeichneten Ingenieure! Die sind nämlich
in mehr oder weniger großen Unternehmen _angestellt_!

Schade dass wir im Usent keine Statistik erheben koennen. Ich denke, in
dieser NG sind prozentual mehr Selbststaendige vertreten als Du denkst.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

 

[Stefan Reuther]

Dirk Ruth wrote:

Stefan Reutherschrieb:
Dirk Ruth wrote:
Exakt.
Source-Code wird mit reinen Texteditoren erstellt und mehr können die
auch nicht. Tabellen sind schon eine Qual und Grafiken wie Skizzen
oder Flussdiagramme gehen gar nicht. ASCII-Art will man da nicht
wirklich drin haben.

Warum nicht?

Für einfache Blockdiagramme kenne ich nichts unkomplizierteres. Zum
Beispiel Datenstrukturen dokumentiere ich gerne mal so im Quelltext.
Und in den High-Level-Dokumentationen findest du auch gerne mal ASCII-
Art. Geht einfach schneller und einfacher als mit der Word-Malfunktion.

Word ist für nichts anderes geeignet, als gelegendlich mal einen Brief
zu schreiben, der aber auch nicht zu lang sein darf.

Ich bin leider noch nicht dazu gekommen, die Formblätter in LaTeX
nachzubauen.

Der Leidensdruck steigt allerdings. In einem der neuen Formblätter wurde
die Fußzeile mit RET RET RET RET ... ans Ende der Seite geschoben.
Heißt: sie wandert mit, sobald ich Text eingebe :-/

ASCII-Art ist eher ein workaround für dieses Problem. Ein so
eingefügtes Diagramm oder Grafik will hinterher keiner mehr ändern,
wenn man nicht irgendwo die originalen Quellen dafür hinterlegt hat.

Wieso "originale Quellen"? ASCII-Art ist Klartext und kann mit jedem
Editor geändert werden. Sogar Word. Bequemer ist natürlich
<http://www.jave.de/>. Der akzeptiert natürlich auch Cut&Paste von Word.

Hinzu kommt, dass die Auflösung sehr begrenzt ist und alle Entwickler
die gleichen Schriftparameter eingestellt haben müssen, damit es in
etwa auch gleich aussieht.

Die Schriftart kann man ja in Word einstellen. Ansonsten reicht es, wenn
es eine Festbreitenschrift ist.

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

Formeln, so mit ASCII-Art-Wurzelzeichen und so, baue ich nicht.
Vielleicht noch sowas

riesen * langer * ausdruck
sqrt ( ---------------------------- )
( noch + ein ) ^ ausdruck

aber das kann man ja auch in jeder Festbreitenschriftart lesen.


Stefan

 

[Reinhard Zwirner]

Joerg schrieb:

....
Schade dass wir im Usent keine Statistik erheben koennen. Ich denke, in
dieser NG sind prozentual mehr Selbststaendige vertreten als Du denkst.

Hallo Jörg,

das kann schon sein. Dennoch klagt die _Industrie_ am lautesten über
Ingenieursmangel: und in der _Industrie_ sind die Ingenieure halt
Angestellte. Ich bin der festen Überzeugung, daß der Großteil der
Ingenieure in D angestellt und nur ein kleiner Teil selbständig ist.

Ciao

Reinhard

 

[Joerg]

Rolf_Bombach wrote:

Christian Zietz schrieb:
Holger Bruns schrieb:

Dann hat Leichelt mal wieder den Katalog geputzt. Die werden auch
immer conradiger, was das Sortiment betrifft.

Hätte Jörg nach UJT (oder PUT) gesucht, wäre er auch bei Reichelt fündig
geworden.

Die Bauteile verhalten sich ähnlich, sind aber gänzlich anders
aufgebaut. Der UJT hat nur eine Sperrschicht und ist irgendwie
FET-änhlich aufgebaut, während der PUT ein "normaler" Vierschicht-
Thyristor mit drei Sperrschichten ist, wo aber freundlicherweise
auch die obere Steuerschicht mit einem Drähtchen versehen ist.
Dieses Zusatzfeature kostet offenbar unglaublich viel Geld,
2 Transis aneinander sind viel billiger. *joergumzustimmungbittend*

Hierzulande bauen wir Saegezahngeneratoren einfach klassisch auf.
Stromquelle -> Schwellwert -> Entladung -> Wieder von vorn.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

 

[Lutz Schulze]

Am Sun, 04 Jan 2009 09:20:56 -0800 schrieb Joerg:

Doch, weil es eine Antwort auf die Darstellung meiner Arbeit als
Selbständiger ist und sich auch nur darauf bezog, bzw. auf die
"Einzelkämpfer" in der Branche. In dem obigen Absatz spricht Axel
auch mich direkt an.

Aber Deine Situation als Selbständiger ist absolut nicht
repräsentativ für die Arbeitssituation der in diesem Fred
als Mangelware bezeichneten Ingenieure! Die sind nämlich
in mehr oder weniger großen Unternehmen _angestellt_!


Schade dass wir im Usent keine Statistik erheben koennen. Ich denke, in
dieser NG sind prozentual mehr Selbststaendige vertreten als Du denkst.

Das ist die selektive Wahrnehmung. Seit einiger Zeit sehe ich auch viel mehr
Frauen um die vierzig als früher ;-)

Lutz

--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Neu: Ethernetbox jetzt auch im 19 Zoll Gehäuse mit 12 Ports für Sensoren

 

[Joerg]

Dirk Ruth wrote:

Axel Schwenkeschrieb:
"
Thomas 'Tom' Malkus <tom@isnix.de> wrote:
Joerg meinte:

Kommentare im Source Code sind IMHO keine Dokumentation. Das sehen
auch Behoerden oft so. Was aus den Tools rauskommt, ist teilweise
haarstraeubend. Oft genug "genossen".
Kennst Du http://www.stack.nl/~dimitri/doxygen ?
Das reicht nicht. Man braucht drei Arten von Dokumentation:

1. API-Dokumentation. Dafür (und *nur dafür) sind Doxygen, JavaDoc &
Freunde ganz brauchbar. Ich hab in der Vergangenheit auch Perceps
gern dafür genutzt. Perceps ist im Prinzip wie Doxygen. Allerdings
nutzt es Templates und kann so z.B. auch LaTeX erzeugen.

2. High-Level Dokumentation. Funktionsprinzipien, Konfigurations-
parameter, Dateiformate, Hintergrundinfos.


Exakt.
Source-Code wird mit reinen Texteditoren erstellt und mehr können die
auch nicht. Tabellen sind schon eine Qual und Grafiken wie Skizzen
oder Flussdiagramme gehen gar nicht. ASCII-Art will man da nicht
wirklich drin haben.
Wundert mich eigendlich, dass MS noch nichts richtiges eingefallen
ist, um Sourcen und Doku zusammen zu führen.

Richtig. Du kriegst nicht mal ein gescheites Flussdiagramm hin und das
braucht man in der SW nun mal. Ich hatte unserer SW jedenfalls so eine
Quelltext-Doku allein nicht erlaubt.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

 

[Dirk Ruth]

Falk Willbergschrieb:
"

Dirk Ruth schrieb:
...
Ich stelle mir eher einen Editor vor, der seine Daten in XML
abspeichert. Mitten in den Sourcen könnte ich dann einen Container
einfügen, in dem ich beliebige Daten einwerfen kann (Skizzen,
Programm-Ablaufpläne, Ergebnisse aus Meetings oder Telefongesprächen
usw.) . Sollte doch mit OLE, oder wie das mal hieß, zu machen sein.

Klar, dann kann man nur noch mit dem OS eines einzigen Herstellers
programmieren.

Warum? Wenn die Info in eigens dafür vorgesehene Tags eingebettet ist.

Den Container kann man dann wieder zuklappen, so dass am Seitenrand
nur ein kleiner Link erscheint (PDF kennt sowas ähnliches als
Notiz-Funktion).

Danke, in C-sourcen will ich C-Syntax und sonst nix.

Damit reißt Du aber zusammen gehörende Informationen auseinander.
Müssen diese später wieder zusammengefügt werden, dann geht die
Sucherei los. Der Verwaltungsaufwand für verteilte Informationen ist
enorm und ließe sich so recht gut automatisieren.

Sowas habe ich schon immer vermisst. Stattdessen liegt der Kram meißt
quer über die Server verteilt in mehr oder weniger sinvoll benannten
Verzeichnissen und ohne Versionierung.

Dagegen hilft seit Jahren RCS oder ein Klicki-Bunti Versions-Kontrollsystem.

Nein hilft es nicht.

Nach einem Jahr sucht man dann ewig, bis man das Gesprächs- oder
Meeting-Protokoll gefunden hat, warum der Code an genau der Stellle so
geändert wurde, weil Kunde am xx.yy.2007 wollte, dass die Funktion nun
genau so sein soll.

Sowas schreibe ich in Kommentare. Größere Änderungen werden mit RCS
dokumentiert.

Irgendwann wird die Informationsmenge in den Kommentaten so groß, das
es unübersichtlich wird. Dann müssen selbst die Informationen in den
Kommentaren strukturiert werden.

Der Ansatz ist ja eher, dass es eine Source-Datei gibt, auf die
mehrere Sichten existieren können.
Zusammengehörende Informationen über möglichst kurze Wege zu
vernetzen, halte ich für das Ordnungssystem mit der höchsten
Effizienz. Die einlaufen Informationen zu dem Zeitpunkt zu vernetzen,
zu dem sie bearbeitet und angewendet werden steigert die Effizienz
nochmals und sorgt für den geringsten Informatonsverlust.
Also nichts da mit Dokumentation aus dem Nichts nach Fertigstellung
des Projekts erstellen.

Ich schreibe seit Jahren Software mit vi, die Abhängigkeiten prüft make,
kompilieren tue ich mit gcc.

Habe ich früher auch mal so gemacht.
Heute verwende ich lieber eine Entwicklungsumgebung, mit der ich
sowohl programmieren, compilieren, die Versionen verwalten, debuggen,
simulieren, in der Online-Hilfe suchen, GUI-Entwickeln, flashen usw.
kann und das über mehrere Einzelprojekte.
Fehler gefunden, Änderung gemacht, Code weiterlaufen lassen, ohne neu
compilieren zu müssen, sind z.B. nette features, die ich nicht mehr
missen möchte.
Sicher, kann man auch alles einzeln machen. Ist mir persönlich zu
unkonfortabel.

Jetzt habe ich das erste Projekt, bei dem ich mit Codewarrior arbeiten
*muß*. Seit ich den unter wine benutzen kann, macht es auch wieder Spaß.
Jetzt muß ich mich nicht mehr mit seinen Zicken herumschlagen, sondern
kann mich der Software widmen.
...

Ich habe den Eindruck, deine Abneigung kommt eher aus den Erfahrungen
mit schlechten Entwicklungstools.

Dirk

 

[Gerrit Heitsch]

Dirk Ruth wrote:

Gerrit Heitschschrieb:
"
Dirk Ruth wrote:

Exakt.
Source-Code wird mit reinen Texteditoren erstellt und mehr können die
auch nicht. Tabellen sind schon eine Qual und Grafiken wie Skizzen
oder Flussdiagramme gehen gar nicht. ASCII-Art will man da nicht
wirklich drin haben.
Wundert mich eigendlich, dass MS noch nichts richtiges eingefallen
ist, um Sourcen und Doku zusammen zu führen.
Weil es dann kein reiner Text mehr waere und das will man wirklich
nicht. Waere so, als wenn du deinen Source in MS-Word schreibst und dann
auch nur damit wieder lesen kannst.



Muss nicht sein.
Ich stelle mir eher einen Editor vor, der seine Daten in XML
abspeichert. Mitten in den Sourcen könnte ich dann einen Container
einfügen, in dem ich beliebige Daten einwerfen kann (Skizzen,
Programm-Ablaufpläne, Ergebnisse aus Meetings oder Telefongesprächen
usw.) .

Aha... und damit ist es kein reiner Text mehr und wird garantiert nur
noch von einem Compiler verstanden bzw. muss mit einem bestimmten IDE
verarbeitet werden. Danke, nein.

Sowas habe ich schon immer vermisst. Stattdessen liegt der Kram meißt
quer über die Server verteilt in mehr oder weniger sinvoll benannten
Verzeichnissen und ohne Versionierung.

RCS, CVS oder Subversion existieren.

Nach einem Jahr sucht man dann ewig, bis man das Gesprächs- oder
Meeting-Protokoll gefunden hat, warum der Code an genau der Stellle so
geändert wurde, weil Kunde am xx.yy.2007 wollte, dass die Funktion nun
genau so sein soll.

Genau sowas gehoert in den Kommentar im Source, nirgendwo anders.

Word halte ich da für völlig ungeeignet, da wird alles nur stumpf
zusammen gemixt.

Jedes andere nicht-Text-Format hat aehnliche Probleme und XML wird
sowieso viel zu oft missbraucht.

Gerrit

 

[Gerrit Heitsch]

Dirk Ruth wrote:

Falk Willbergschrieb:
"
Dirk Ruth schrieb:
...
Ich stelle mir eher einen Editor vor, der seine Daten in XML
abspeichert. Mitten in den Sourcen könnte ich dann einen Container
einfügen, in dem ich beliebige Daten einwerfen kann (Skizzen,
Programm-Ablaufpläne, Ergebnisse aus Meetings oder Telefongesprächen
usw.) . Sollte doch mit OLE, oder wie das mal hieß, zu machen sein.
Klar, dann kann man nur noch mit dem OS eines einzigen Herstellers
programmieren.


Warum? Wenn die Info in eigens dafür vorgesehene Tags eingebettet ist.

Aha... und welcher Compiler baut das XML erstmal nach Text um damit er
damit was anfangen kann? Garantiert nur bestimmte Hersteller und dann
noch mit inkompatiblen Tags womit du beim Programmieren auf einen
bestimmten Editor festgelegt bist. Danke, muss nicht sein.

Der Ansatz ist ja eher, dass es eine Source-Datei gibt, auf die
mehrere Sichten existieren können.
Zusammengehörende Informationen über möglichst kurze Wege zu
vernetzen, halte ich für das Ordnungssystem mit der höchsten
Effizienz. Die einlaufen Informationen zu dem Zeitpunkt zu vernetzen,
zu dem sie bearbeitet und angewendet werden steigert die Effizienz
nochmals und sorgt für den geringsten Informatonsverlust.
Also nichts da mit Dokumentation aus dem Nichts nach Fertigstellung
des Projekts erstellen.

Kannst du gerne per externer Datei machen, aber der Source muss reiner
Text bleiben.

Ich schreibe seit Jahren Software mit vi, die Abhängigkeiten prüft make,
kompilieren tue ich mit gcc.


Habe ich früher auch mal so gemacht.
Heute verwende ich lieber eine Entwicklungsumgebung, mit der ich
sowohl programmieren, compilieren, die Versionen verwalten, debuggen,
simulieren, in der Online-Hilfe suchen, GUI-Entwickeln, flashen usw.
kann und das über mehrere Einzelprojekte.

Damit bist du aber auf einen Editor festgelegt. Schoen, wenn der dir
gefaellt. Aber was machst du wenn das nicht der Fall ist?

Vergiss nicht, was machst du wenn du in 10 Jahren nochmal an den Source
ranwillst aber das XML von damals keiner mehr versteht? Alles was hier
_immer_ lesbar sein soll (Source, Texte, usw...) lagert hier als
Textfile, PDF, HTML, GIF, JPEG oder PNG. Alle anderen Formate haben sich
als zu kurzlebig oder zu proprietaer erwiesen, besonders wenn man hin
und wieder mal die Platform gewechselt hat.

Gerrit

 

[Gerrit Heitsch]

Joerg wrote:

Hierzulande bauen wir Saegezahngeneratoren einfach klassisch auf.
Stromquelle -> Schwellwert -> Entladung -> Wieder von vorn.

Die alte Schaltung mit Widerstand, Kondensator und Glimmlampe?

Gerrit

 

[Alexander Schreiber]

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

Gerrit Heitschschrieb:
"
Dirk Ruth wrote:


Exakt.
Source-Code wird mit reinen Texteditoren erstellt und mehr können die
auch nicht. Tabellen sind schon eine Qual und Grafiken wie Skizzen
oder Flussdiagramme gehen gar nicht. ASCII-Art will man da nicht
wirklich drin haben.
Wundert mich eigendlich, dass MS noch nichts richtiges eingefallen
ist, um Sourcen und Doku zusammen zu führen.

Weil es dann kein reiner Text mehr waere und das will man wirklich
nicht. Waere so, als wenn du deinen Source in MS-Word schreibst und dann
auch nur damit wieder lesen kannst.



Muss nicht sein.
Ich stelle mir eher einen Editor vor, der seine Daten in XML
abspeichert. Mitten in den Sourcen könnte ich dann einen Container
einfügen, in dem ich beliebige Daten einwerfen kann (Skizzen,
Programm-Ablaufpläne, Ergebnisse aus Meetings oder Telefongesprächen
usw.) . Sollte doch mit OLE, oder wie das mal hieß, zu machen sein.
Den Container kann man dann wieder zuklappen, so dass am Seitenrand
nur ein kleiner Link erscheint (PDF kennt sowas ähnliches als
Notiz-Funktion).

*oergs*

Damit kann man dann nur noch mit einer ganz speziellen Toolchain (Editor,
Compiler) programmieren. Prima lock-in, mit vermutlich lausigen Werkzeugen.
Danke, nein.

Sowas habe ich schon immer vermisst. Stattdessen liegt der Kram meißt
quer über die Server verteilt in mehr oder weniger sinvoll benannten
Verzeichnissen und ohne Versionierung.

Fuer "Ohne Versionierung" gibt es heutzutage _keine_ Ausrede mehr. Es gibt
mittlerweile genug freie und sehr gute Versionierungssysteme, auch auf
Windows.

Nach einem Jahr sucht man dann ewig, bis man das Gesprächs- oder
Meeting-Protokoll gefunden hat, warum der Code an genau der Stellle so
geändert wurde, weil Kunde am xx.yy.2007 wollte, dass die Funktion nun
genau so sein soll.

Dazu gibt es Versionierungssysteme und ggf. entsprechende Frontends, die
solche Suchen und Darstellungen noch weiter vereinfachen.

Mir fällt gerade ein, dass man darin auch wunderbar die Zeiten für
Codeerstellung, Debugging usw. mitführen könnte, um die
Softwareentwicklung besser messbar zu machen, was ja essentiell für
die Projektplanung ist.

Habe ich nie wirklich gebraucht, aber ich bin mir ziemlich sicher, dass
es da fuers Projektmanagement geeignete Werkzeuge gibt.

Könnte man zu jeder Info, die in den Container kommt, ein Tag
auswählen, dann ließe sich die Ausgabe wunderbar filtern, also z.B.
Code, Hilfe, Doku, Verwaltung, Fehlertracking usw.

Word halte ich da für völlig ungeeignet, da wird alles nur stumpf
zusammen gemixt.

Word ist IMHO generell ungeeignet fuer alles was ueber den "Hallo, Tante
Elise" Brief hinausgeht.

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