Erstmal die guten Nachrichten. Mit der Version 0.65 von Struktor funktionieren die Arrays wieder. Schon eine ganze Weile aber ich bin bis jetzt nicht dazugekommen, dass zu erwähnen.

Allerdings gibt es auch schlechte Nachrichten. Viele User haben sich beschwert, dass sie keine Struktogramme mehr cut&pasten können. Tja, bedankt Euch bei Oracle. Seit der Java Version 1.6.0_24 hat Oracle cut&paste als sicherheitechnisch bedenklich für unsignierte Applets deaktiviert. Genaueres gibt es hier: http://mindprod.com/jgloss/copypaste.html

Damit das wieder ermöglicht wird könnt Ihr eine ältere Version von Java verwenden oder ich könnte das Applet signieren. Aber dafür habe ich derzeit weder Geld noch Zeit übrig.

Wie das geht scheint hier beschrieben zu sein: http://download.oracle.com/javase/1,5.0/docs/guide/plugin/developer_guide/rsa_signing.html

Vielleicht komme ich ja demnächst dazu mich auf die Suche nach einem kostenlosen Zertifikat zu begeben. Hilfe wird gerne angenommen.

Aus aktuellem Anlass: Es gibt dummerweise seit einiger Zeit einen Fehler in Struktor, der dafür sorgt, dass arrays nicht mehr funktionieren. Der Fehler ist im Sourceforge-Bugtracker dokumentiert:
http://sourceforge.net/tracker/?func=detail&aid=2960667&group_id=79692&atid=557470

Danke an Alfred und auch Roland für den Hinweis. Der Fehler hat sich bei der Migration vom alten JLex auf JFlex eingeschlichen und hat in der Folge zu einem Bugeintrag bei JFlex geführt:
https://sourceforge.net/tracker/index.php?func=detail&aid=2961512&group_id=14929&atid=114929

Ich könnte prinzipiell versuchen den Bug zu workarounden aber dafür fehlt mir die Zeit. Wenn ich dazu komme, werde ich demnächst einen Rollback der Version machen, also eine alte Version zum Einsatz bringen.

Sorry mir fehlt hier einfach die Zeit um mich mit dem Projekt zu beschäftigen, jede Hilfe ist hoch willkommen, es gibt dann auch von mir Extra-Couching.

schöne Grüsse

Kim

Nasowas, die Johannes-Kepler-Universität in Linz hostet Struktor auf Ihren Webseiten und velinkt für eine Kurzanleitung auf meine Seiten.

Obwohl es Ihr gutes Recht ist, bin ich irgendwie noch zwiegespalten ...

Wikis zu editieren macht nicht immer Spass. Speziell nicht, wenn es um die Linksyntax geht. Da hilft nicht mal sich die Syntax zu merken, dass korrekte verlinken verkommt zur Fleissarbeit. In Confluence kann man ungefähr so umschreiben:

function makeConfluenceLink(url) {
url=encodeURI(url);
var regex = /http:\/\/[^\/]+\/display\/([^\/]+)\/([^#]+)(#[^#]+)?/;
regex.exec(url);
if (RegExp.$3 ) {
name = RegExp.$3;
} else {
name = "";
}
conLink = "[" + RegExp.$1 + ":" + RegExp.$2 + name + "]";
conLink = jiraLink.replace(/\+/g," ");
return conLink;
}

Das ist mir dann meist doch zuviel Arbeit und man pastet einfach den http-Url in den Text. Auch nicht sehr schön. Also automatieren wir das ganze mit einem Greasemonkey Usercript. Das funktioniert natürlich nur, wer den Firefox benutzt und Greasemonkey installiert hat.

Ausprobieren kann man dann das Script z.b. in der Confluence-Sandbox auf dass ich auch jetzt erstmal den Scope des Scripts eingestellt habe (die Maus über die Überschriften fahren). Für den produktivaen Bereich muss der natürlich geändert werden.

Es gibt statistische Erhebungen, von denen weiss man erst dann, dass man seit jeher auf sie gewartet hat, wenn man sie sieht.

Dazu gehört mit Sicherheit die Erhebung der Todesfälle roter Overalls in TOS, die Hypothesenbildung, -überprüfung und natürlich auch die angemessene graphische Darstellung des Ergebnisses.

Kleine Zusammenfassung:
Die meisten Todesfälle gibt es in roten Overalls (Binsenweisheit). Wenn Kirk eine Affäre hat, sinkt die Todesrate, sie steigt aber wiederum, wenn es gleichzeitig einen Kampf gibt.

(via Scott Berkun)

Laaaange Zeit gab es nichts neues über Struktor. Ich hatte trotzdem recht konstante Zugriffszahlen. Jeden Tag hab ich so um die 20 bis 100 Besucher auf den Seiten. Viele wissen wo sie hinwollen und steuern sofort diese Seite an.

Auf Dauer fand ich das garnicht mehr zeitgemäß. Irgendwie stört es mich auch, dass so viele Leute direkt auf nur eine Seite des ganzen Angebots zugreifen. Ich kann es aber natürlich nicht verübeln. Irgendwann hat man das ganze statische Angebot eben durchsurft und was noch bleibt ist eben das dynamische Spielen mit Struktor.

Vor einiger Zeit ist mir hingegen die Idee gekommen, das Wiki-Prinzip auf das Webangebot anzuwenden. Klingt doch sehr plausibel. die Anwender können selber z.b. den Glossar erweitern, eigene Struktogramme veröffentlichen und darauf aufbauend vielleicht ganz neue Kursinhalte erstellen.

Es war gar nicht so schwierig. Vielleicht ist es kein besonders komfortables Produkt aber das war Struktor ja noch nie

Lange Reder, kurzer Link: http://wiki.learn2prog.de

Lang- bzw. Mittelfristig will ich das alte Angebot komplett durch das Wiki ersetzen.

Kommentare gerne hier oder auch dort: Jede Seite im Wiki ist kommentierbar!

GTD ist eine von Produktivitäts-Guru "David Allen" kreiierte Selbstmanagement-Methode. Ich habe GTD über die Publikationen von Frank Westphal kennengelernt. 2 zentrale Elemente in GTD sind ein vertrauensvolles System das man alle seine Aufgaben, Verbindlichkeiten und Ideen aufnimmt. Das ermöglicht, den Kopf freizubekommen um sich fokussieren zu können auf den "Next Step", das zweite wichtige Prinzip von GTD. Denn um in seinen Projekten und Vorhaben vorwärtszukommen müssen wir mithilfe des Systems zu "Actionable Items" kommen, unsere Aufgaben deren Erfüllung uns unseren Zielen näher bringt. Zu guter letzt müssen wir natürlich diese Aufgaben dann auch noch erledigen

Ebenso bin ich ein Fan des Projektmanagement-Tools "TRAC". Trac wird v.a. in der (agilen) Softwareentwicklung eingesetzt. Es kombiniert drei Dinge in unvergleichlicher Weise:

1. ein Wiki
2. ein Issue-Management-System
3. eine Codeverwaltung (standardmäßig Subversion) wobei der Quellcode komplett über die Weboberfläche einsehbar ist.

Jedes dieser Elemente wird wahrscheinlich durch andere Systeme besser umgesetzt. Es gibt bestimmt bessere Wikis, ausgefeiltere Issue-Management-Systeme und Subversion ist ohnehin in bestimmten Kontexten der defacto-Standard. Die Kombination dieser drei Elemente ist in TRAC aber unvergleichbar elegant gelöst (vielleicht zu gegeber Zeit mehr dazu).

Vor ziemlich genau einem Jahr habe ich an anderer Stelle für den Einsatz von TRAC geworben und mehr zufällig in Anlehnung an dieses Interview TRAC als Ziel für den kollaborativen "Mind-Sweep" bezeichnet, also als System um all die Ideen, Gedanken, Aufgaben und Themen in einem Projekt aus den Köpfen in ein System zu transferieren, dem man vertraut.

Nun haben 2 Forscher aus der Freien Universität Brüssel GTD aus der wissenschaftlichen Perspektive (was immer das auch heissen mag) unter die Lupe genommen. Interessanterweise sind sie auch auf Wege und Möglichkeiten eingegangen, GTD im Team zu nutzen. Hier ein Textauszug:

The advantage of externalizing information into the environment is
not only that it supports individual information processing, but also that it facilitates sharing
between different individuals. Indeed, an external memory, such as a library or database, can
typically be used by many people—unlike the memories in your brain. But the stigmergic/GTD
paradigm focuses on more than mere information storage: it demands the externalization of tasks,
to-dos or “next actions”, i.e. the registration of concrete stimuli that trigger an activity when
encountered in the right context. By sharing these, coordination between different agents becomes
much easier.
[...]
More complex workflow systems can support the process of delegating tasks to co-
workers. However, these tools typically assume a rigid scheme that specifies exactly who does
what when. Such explicit plans run counter to the philosophy of adaptability, opportunism and
self-organization that characterizes GTD and stigmergy. A more flexible approach is suggested
by job ticketing systems, which are used in organizations such as call centers that provide support
about technical problems concerning software or hardware. When a customer calls in with a
specific question, an expert needs to be located that has the relevant knowledge and that is
available as soon as possible. Rather than immediately delegating the task to a specific individual,
the system creates a “job ticket” with a short description of the type of problem. These tickets are
added to a shared pool of tasks to be performed.

Völlig neu war für mich das Konzept des stigmergisches System. Dabei geht es um die Koordination und Kommunikation von Individuen durch Modifizierung der lokalen Umwelt. Beispiele kommen klassischerweise aus der Tierwelt aber auch das Wiki wird als Beispiel für ein stigmergisches System geannt.

The most important items are the ones that are actionable. Here the additional decision
needs to be made who will perform the action. In a truly flexible, stigmergic system that decision
is ideally made by the individual who commits to the action, not by a boss who delegates the
action to a subordinate without knowing precisely whether that subordinate is available,
competent or willing to perform it. The philosophy of GTD is that people commit to a certain
action on the basis of personal criteria, such as context, time, energy and priority—not because it
is imposed on them. Normally, the individuals themselves are the ones best able to judge whether
they are ready to perform a task.

Eine ähnliche Auffassung über die Erfüllung von Teilaufgaben gibt es übrigens auch bei SCRUM. Hier ist das Commitment auf das Sprint-Backlog ein Kernpunkt. Der Artikel geht allerdings in eine ganz andere Richtung. Während bei Scrum jemand existiert, der die Prioritäten festsetzt und sich das Team möglichst an diesen Prioritäten orientieren soll (der Product-owner) wird in dem Artikel davon ausgegangen das in wahrhaft stigmergischen Systemen sich dieses Problem irgendwie von alleine lösen solte.

Na das hört sich nach Chaos an. Allerdings wird das tatsächlich praktiziert. Die Chaosfrage wird natürlich noch größer, wenn die Mitarbeiter sich nicht nur Ihre Aufgaben selber aussuchen können sondern auch noch innerhalb ihrer Organisation ganz nach Belieben zwischen den Projekten wechseln können. in diesem Praxisbericht wird die Chaosfrage folgendermaßen formuliert:

How could this ever work?

I get that question a lot. Heck, I asked it myself. What's to stop engineers from leaving all the trouble projects, leaving behind bug-ridden operational nightmares? What keeps engineers working towards the corporate goals if they can work on whatever they want? How do the most important projects get staffed appropriately?

In der Theorie wird diese Frage in Anlehnung an die Pheromone der Ameisen mit Punkten gelöst, die eine magische Hand auf die Aufgaben verteilt. Derjenige, der die Aufgaben löst, kann sich die Punkte in irgendeiner Form auf den Lohnzettel transferieren lassen.

If it turns out that certain tasks still have not been performed after an extended period, in
spite of the points they offer, this may be a signal for the management that the task is either not
that interesting and therefore should better be withdrawn, or—if it is deemed really important—
that the task is more difficult than expected and therefore deserves more points.

Und hierzu wieder der Praxisbericht:

First, and arguably most importantly, Google drives behavior through incentives. Engineers working on important projects are, on average, rewarded more than those on less-important projects. You can choose to work on a far-fetched research-y kind of project that may never be practical to anyone, but the work will have to be a reward unto itself. If it turns out you were right and everyone else was wrong (the startup's dream), and your little project turns out to be tremendously impactful, then you'll be rewarded for it. Guaranteed.

Und was braucht nun das individuum in der Praxis der Praxis noch am ehesten, um sein stigmergisches System erfolgreich zu machen?

Then all you need is a work queue. That's it. You want hand-wavy math? I've got it in abundance: software development modeled on queuing theory. Not too far off the mark, though; many folks in our industry have noticed that organizational models are a lot like software models.

With a priority queue, you have a dumping-ground for any and all ideas (and bugs) that people suggest as the project unfolds. No engineer is ever idle, unless the queue is empty, which by definition means the project has launched. Tasks can be suspended and resumed simply by putting them back in the queue with appropriate notes or documentation. You always know how much work is left, and if you like, you can make time estimates based on the remaining tasks. You can examine closed work items to infer anything from bug regression rates to (if you like) individual productivity. You can see which tasks are often passed over, which can help you discover root causes of pain in the organization. A work queue is completely transparent, so there is minimal risk of accidental duplication of work.
[...]
Unfortunately, a work queue doesn't make for a good marketing platform for seminars and conferences. It's not glamorous. It sounds a lot like a pile of work, because that's exactly what it is.

Ausriss aus einem Beitrag zum Thema "Termintreue" von mir an anderer Stelle:

[...] In der Praxis und v.a. im Bereich Softwareherstellung dient eine solche Terminnennung v.a. einem Zweck: Man erhofft, dass die Zeitüberschreitung geringer ausfällt, als wenn gar kein Termin im Raum steht, man möchte also mit solchen Terminen die Dinge nach vorne treiben. Dieser Ansatz ist mit Sicherheit richtig. Auffällig ist nur, wieviel Termine defacto gerissen werden. [...] Seit 1994 gibt die Standish-group [1] in regelmäßigen Abständen ihren legendär gewordenen sog. "Chaos-Report" heraus[2], zuletzt 2006, in dem sie seit dem über 40.000 Softwareherstellungsprojekte auf Projekterfolg, Zeit- und Budgetüberschreitung untersucht hat.
1994 sind lediglich 16% der Projekte erfolgreich verlaufen, 52% der Projekte hatten Zeit- und/oder Budgetüberschreitungen, über 30% der Projekte wurden erfolglos abgebrochen.
2006 hat sich die Lage gebessert. Bereits 35% der Projekte wurden erfolgreich abgeschlossen, 46% der Projekte haben Zeit und/oder Budgetüberschreitungen und 19 % sind erfolglos abgebrochen worden [3].
Immerhin, die Lage hat sich gebessert, trotzdem ist die Lage aus Projektmanagementsicht her alles andere als befriedigend. Rein statistisch gesehen sind immer noch knapp 50% von Kosten oder Zeitangaben schlicht für den Mülleimer. Untersucht wurde nämlich auch der Grad der Abweichung, und die ist mitnichten unerheblich. Durchschnittlich wurde sich 1994% Durchschnittlich um 222% verschätzt! Durchschnittlich! Für die Statistikfans: 35% der Zeitüberschreitungen lagen damals bei 100%-200% (Median) [4]. Der Grad der Abweichung für 2006 habe ich leider nicht gefunden.
Es sollte jedem der solche Schätzungen vornimmt oder rezipiert klar sein, mit welcher grossen Unsicherheit diese behaftet sind. Eine besonders grosse Bedeutung kommt demnach auch der Schätzungsgrundlage zu: Also wie schätzen wir überhaupt? Schließlich gibt es da eine grosse Bandbreite, abgefangen von der Daumenmethode bis zu "Evidence Based Scheduling" [5]
.[...]

[1] http://www.standishgroup.com/
[2] http://de.wikipedia.org/wiki/Chaos-Studie
[3] http://www.computerwoche.de/produkte_technik/589879/
[4] http://www3.uta.edu/faculty/reyes/teaching/general_presentations/chaos1994.pdf
[5] http://www.joelonsoftware.com/items/2007/10/26.html

Mittlererweile bin ich Autobesitzer und habe Kinder. Eine Situation, die Probleme löst und zukünftige schaffen kann. Deswegen habe ich auch mit Interesse diesen Artikel gelesen. Der Autor hat offensichtlich in diesem Bereich wesentlich mehr Erfahrung als ich:

Before we can show you the contents of our pair of mapping files, we need to explain our very simple data model and application. Our application is concerned with a small family - a husband, Jack; a wife, Jill; and their son, James - who own four cars among them. The reason they own four cars is that one of the cars, a sporty car owned by James, is often in the shop for repairs. James has a tendency to have accidents for which others - never he - is responsible, and the accidents amazingly tend to occur when he is driving that specific car. Note that no member of this family is permitted to drive each other's cars - the attachment to their own car is too great. As a result, there is a one-to-many association between a Driver and the Cars that driver may drive. (In most families, the association would probably be many-to-many, but in the family in our example it is one-to-many.) Nothing stops this family from conceivably purchasing additional cars, but due to the prevailing family dynamics in their family, no member will ever drive each other's cars.

Im Technology Review ist ein interessantes Interview mit Bent Flyvbjerg. Der Mann untersucht Grossprojekte und stellt fest, dass 90% Ihre Kosten überschreiten. Interessant fand ich, dass dabei Komplexität nicht als Hauptgrund angesehen wurde, sondern Zweckoptimismus und politischer Druck:

Die meisten Mega-Projekte stehen unter einem gewaltigen politischen Druck. Ebenso hoch ist auch der wirtschaftliche Druck, sie zu verwirklichen. Verschiedene Gruppen verbinden sehr große Interessen mit einem solchen Projekt. Wir erklären die Überschreitungen mit etwas, das wir fehlgeleiteten Optimismus und strategische Falschangaben nennen. Wenn man Komplexität verdrängt, ist das eine Art falscher Optimismus.

Zusätzlich findet eine bewusste Fehlinformation statt: Personen, die wollen, dass das Projekt genehmigt wird, unterschätzen die Kosten und überbewerten den Nutzen. Das Projekt sieht dann auf dem Papier besser aus, und damit steigt auch die Wahrscheinlichkeit, dass man den Zuschlag bekommt. Fehlgeleiteter Optimismus und strategische Fehlauskunft geschehen mit System. In unserer Forschung belegen wir das deutlich mit Statistiken.

Ist das Lügen? Nein:

Es ist mehr so, dass jeder weiß, was zu tun ist. Sie reden darüber gar nicht. Sie sind sogar in der Lage, das Nachdenken darüber zu verdrängen. Sie machen es einfach. Es ist eine eigene Kultur. Ich nenne sie die Kultur der Fehlinformation.

Teilweise sind aber auch Kostenüberschreitungen von vorneherein eingeplant, sonst wäre man ja mit dem Anfangspreis gar nicht "konkurrenzfähig":

Sogar auf dem privaten Sektor ist dies ein Problem, da hier oft zusätzliche Arbeiten zu leisten sind und die Auftragnehmer das auch wissen. Daher verdienen sie ihr Geld mit diesen Extra-Arbeiten, die sie sehr teuer machen.

Naja, eigentlich weitgehend alles schon bekannt, allerdings hat man anscheinend zumindest in Grossbritanien erste Konsequenzen gezogen. (mehr).

Gert Lovink in einem Interview für die Zeit:

Der digitale Nihilismus, wie ich ihn verstehe, hat nichts mehr mit einer Religion und nur wenig 
mit einer ethischen �berzeugung zu tun. Vielmehr entspringt er einem Misstrauen den Utopien 
selbst gegenüber. Es ist eine Position, die von einem imaginären Nullpunkt ausgeht, dem 
»Zero« in Zero Comments. Denn die Mehrzahl der Blogs wird ja gerade nicht gelesen, sie spielen 
in einer Grauzone der �ffentlichkeit, von der sich einige wenige Spitzen-Blogger abheben. Die 
Null, die in der Software aufscheint � kein Verkehr, niemand da gewesen, das »Nihil« von 
Nihilismus �, ist die Regel, nicht die Ausnahme.

via Juergen Luebeck

P.S.: ich wünsch jetzt mal ganz unnihilistisch frohe Weihnachten, schöne Feiertage und einen guten Rutsch

Auch Google kennt schon seit längerem die Antwort auf Frage nach dem Leben, dem Universum und dem ganzen Rest. Die Antwort ist natürlich 42. Einer der ebenfalls unermüdlich nach Antworten, v.a. in den großen weiten des Web 2.0, sucht, ist Mario Sixtus mit seinem Videoblog Elektrischer Reporter. Nach einer längeren Schaffenspause hat er, ausgerechnet in seinem zweiundvierzigstem Beitrag eine (oder besser gesagt zwei) Zusammenfassungen aller bisher gesendeten Episoden veröffentlicht.

Sehenswert, denn der Mann, bzw. genauer seine Interviewpartner, gehören ohnehin zum Pflichtprogramm für alle ... ja für wen eigentlich.

denn seit gestern ist WhatsYourPlace Online. Dort kann man das virtuell in Google-Maps vorhandene reale Land erwerben und ... ja, ab jetzt wird es schwammig. Man kann dann seine Parzelle mit Fotos, Beschreibungen etc. versehen und in der Community präsentieren.
Wenn man sich irgendwas populäres angeschafft hat, vielleicht noch ein wenig auf Preissteigerung hoffen.

Das habe ich mir nicht zwei mal sagen lassen und mir kurzerhand das Kanzleramt gegönnt, für schlappe knappe 25 Euronen. Nicht, dass ich da rein will, vielmehr hoffe ich auf satte Preissteigerungen, denn WhatsYourPlace ist eine tolle Möglichkeit für jedem ein wenig am Web2.0 Fieber teilzunehmen und sich nach der Erwerbung ganz in Ruhe auf seine Exit-Strategie vorzubereiten.

Im Ernst, WhatsYourPlace ist zwar eine interessante, skurrile Idee aber die wird stehen und fallen mit dem Funktionsumfang, der um den Landerwerb herum aufgebaut wird. Man wird sehen, was die Zukunft bringt denn irgendwie ist derzeit der Kundennutzen doch noch etwas schwammig.

Nachdem ich vor einiger Zeit etwas Verwirrung bei der Installation von Magento gestiftet habe, hier eine detaillierte Installationsanleitung bis zur Installation über den Browser, getestet auf einem frisch installierten Ubuntu.

Die Installation unter Debian und unter Ubuntu ist mehr oder weniger identisch. Kommandos, die root-Rechte benötigen müssen in Ubuntu mit einem "sudo" vorangestellt werden. Das erspare ich mir hier in der Beschreibung und gehe davon aus, dass alle Kommados mit root-rechten ausgeführt werden.

Die notwendigen Programme installieren:

apt-get install apache2 php5 php5-mhash php5-curl php5-mcrypt mysql-client-5.0 mysql-server-5.0 

Datenbank und User anlegen anlegen:

/usr/bin/mysqladmin -u root password 'root-passwort'
echo "CREATE DATABASE magento;" | mysql -u root -p
echo "GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP ON magento.* TO 'magento'@'localhost' IDENTIFIED BY 'magento';" | mysql -u root -p

Magento runterladen und entpacken und Rechte setzen:

cd /var/www
wget http://www.magentocommerce.com/downloads/assets/0.6.12840/full/magento-0.6.12840.tar.gz
tar -xzvf magento-0.6.12840.tar.gz 
chown -R www-data:root magento

mod_rewrite installieren, the debian way:

a2enmod rewrite

in der Datei /etc/apache2/httpd.conf folgende 3 Zeilen hinzufügen:

<Directory "/var/www/magento">
   AllowOverride All
<Directory>

apache neu starten:

/etc/init.d/apache2 force-reload

Und nun kann man die weitere Installation bequem über den Browser abwickeln wie im vorher schon angesprochenen Blogeintrag beschrieben:
http://localhost/magento/install/