Die Quintessenz ist richtig: Man soll lernen. Ich bin ja aus dem Emacs-Lager und lerne jedes was neues, was Emacs so kann. Vor sechs Jahren beispielsweise waren es die Tastaturmakros, die es mir angetan haben und bis heute nutze ich dieses Feature ca. alle zwei Tage.
Das nicht tot zu kriegende Märchen ist ja: Sobald man etwas zusammenklicken kann, ist es einfach und gut. An dieser Illusion scheitern dann die Leute in der Praxis. Mir wurde neulich gesagt, Excel wäre so toll. Statistik mit 100000ten Datensätzen sollte man in Excel mache, denn das wäre Standard. Ich wäre in der Praxis habe diese Äußerung ignoriert und mich in R eingearbeitet. Eine CSV-Datei importierte ich nun mit ein R-Programm und kloppe einen mehrseitigen Bericht im PDF-Format raus, mit Kennzahlen und Diagrammen. Denkbar wäre es nun sogar, dieses Erstellen eines Berichtes zu automatisieren (Cronjob und/oder Shellscript) und per E-Mail zu verwenden.
Die größte Herausforderung aber ist, die Vorurteile der anderen abzubauen. Ich vermute auch Faulheit, eine neue Sprache zu lernen. Nun bin ich auch schon einige Jahre dabei und habe viel Zeug kommen und gehen sehen. Was versprach man sich nicht alles von UML-Werkzeugen, die Sourcecode generieren? Lief jemals eins dieser Programme? Bei uns in der Firma waren Birt-Reports sehr beliebt. Problem hierbei: Die Konfigurationsdatei war in einem äußerst komplizierten und umfrangreichen XML geschrieben. Nur mit der Nutzung von Eclipse-Plugins kamen wir zum Ziel. Es musste aber auch alle Entwickler exakt die gleiche Plugin-Version haben, sonst hätte das funktioniert. Ich befürchte, das uns die Birt-Reports in den Altprojekten wie ein Bumerang zurückkommen werden, wenn die passende Eclipse-Version und die passende Plugin-Version nicht mehr auffindbar ist.
Nach einigen Jahren Berufserfahrung ist die meine Quintessenz folgendes:
1. Text ist Binärformaten vorzuziehen. Dann kann man auch Sed, AWK, grep und Co. verwenden. (Nutze ich heute täglich und ich administriere nicht.) Versionskontrolle mit Textdateien auch einfacher. 2. Wenn möglich, auf XML verzichten. Lieber zeilenorientierte Konfigurationen oder einfach mal eine DSL entwickeln. (Spannendes Thema mit viel Potential.) XML ist grauslich, auch wenn es textbasiert ist. 3. Potential zur Automatisierung muss gegeben sein. Lieber sollte man schauen, ob man DocBook, Markdown oder LaTeX in irgendeiner Form verwenden kann, bevor man zu Word greift. Sicherlich kann man auch Visual-Basic-Programme schreiben, aber selbst da wäre ich faul, mich da hineinzuarbeiten. Da gibt zu wenig Bücher und kann man Excel-Makros mit einem Editor seiner Wahl programmieren?
Bei uns in der Firma schwirren Excel-Dateien herum, in denen Testsetups beschrieben werden, die von Java-Import-Routinen eingelesen werden. Erst schrien alle Oh und ach, denn so ein Excel-Sheet kann man ja mit tollen Farben aufpeppen. Aber nach drei Jahren sind einige am Kotzen, weil Randbedingungen geändert haben, die neue Testsetups benötigen. Und nun müssen die Excel-Dateien angepasst werden und auch die Importer. Das ist eine Menge arbeit, weil man nicht einfach so mal mit grep, find, sed und awk die notwendigen Änderungen identifizieren kann.
Die Excel-Dateien haben zudem einen enomen Umfang und verlangen, dass man horizontal scrollt. Für mich ist horizontales Scrollen ein No-Go, weil die vermeintlich bessere Übersicht damit zu einer gewissen schlechteren Übersicht wird.
Die Quintessenz ist richtig: Man soll lernen. Ich bin ja aus dem Emacs-Lager und lerne jedes was neues, was Emacs so kann. Vor sechs Jahren beispielsweise waren es die Tastaturmakros, die es mir angetan haben und bis heute nutze ich dieses Feature ca. alle zwei Tage.
Das nicht tot zu kriegende Märchen ist ja: Sobald man etwas zusammenklicken kann, ist es einfach und gut. An dieser Illusion scheitern dann die Leute in der Praxis. Mir wurde neulich gesagt, Excel wäre so toll. Statistik mit 100000ten Datensätzen sollte man in Excel mache, denn das wäre Standard. Ich wäre in der Praxis habe diese Äußerung ignoriert und mich in R eingearbeitet. Eine CSV-Datei importierte ich nun mit ein R-Programm und kloppe einen mehrseitigen Bericht im PDF-Format raus, mit Kennzahlen und Diagrammen. Denkbar wäre es nun sogar, dieses Erstellen eines Berichtes zu automatisieren (Cronjob und/oder Shellscript) und per E-Mail zu verwenden.
Die größte Herausforderung aber ist, die Vorurteile der anderen abzubauen. Ich vermute auch Faulheit, eine neue Sprache zu lernen. Nun bin ich auch schon einige Jahre dabei und habe viel Zeug kommen und gehen sehen. Was versprach man sich nicht alles von UML-Werkzeugen, die Sourcecode generieren? Lief jemals eins dieser Programme? Bei uns in der Firma waren Birt-Reports sehr beliebt. Problem hierbei: Die Konfigurationsdatei war in einem äußerst komplizierten und umfrangreichen XML geschrieben. Nur mit der Nutzung von Eclipse-Plugins kamen wir zum Ziel. Es musste aber auch alle Entwickler exakt die gleiche Plugin-Version haben, sonst hätte das funktioniert. Ich befürchte, das uns die Birt-Reports in den Altprojekten wie ein Bumerang zurückkommen werden, wenn die passende Eclipse-Version und die passende Plugin-Version nicht mehr auffindbar ist.
Nach einigen Jahren Berufserfahrung ist die meine Quintessenz folgendes:
1. Text ist Binärformaten vorzuziehen. Dann kann man auch Sed, AWK, grep und Co. verwenden. (Nutze ich heute täglich und ich administriere nicht.) Versionskontrolle mit Textdateien auch einfacher.
2. Wenn möglich, auf XML verzichten. Lieber zeilenorientierte Konfigurationen oder einfach mal eine DSL entwickeln. (Spannendes Thema mit viel Potential.) XML ist grauslich, auch wenn es textbasiert ist.
3. Potential zur Automatisierung muss gegeben sein. Lieber sollte man schauen, ob man DocBook, Markdown oder LaTeX in irgendeiner Form verwenden kann, bevor man zu Word greift. Sicherlich kann man auch Visual-Basic-Programme schreiben, aber selbst da wäre ich faul, mich da hineinzuarbeiten. Da gibt zu wenig Bücher und kann man Excel-Makros mit einem Editor seiner Wahl programmieren?
Bei uns in der Firma schwirren Excel-Dateien herum, in denen Testsetups beschrieben werden, die von Java-Import-Routinen eingelesen werden. Erst schrien alle Oh und ach, denn so ein Excel-Sheet kann man ja mit tollen Farben aufpeppen. Aber nach drei Jahren sind einige am Kotzen, weil Randbedingungen geändert haben, die neue Testsetups benötigen. Und nun müssen die Excel-Dateien angepasst werden und auch die Importer. Das ist eine Menge arbeit, weil man nicht einfach so mal mit grep, find, sed und awk die notwendigen Änderungen identifizieren kann.
Die Excel-Dateien haben zudem einen enomen Umfang und verlangen, dass man horizontal scrollt. Für mich ist horizontales Scrollen ein No-Go, weil die vermeintlich bessere Übersicht damit zu einer gewissen schlechteren Übersicht wird.