yet another innoq blog

Lange war es still in diesem Blog, zu still. Es wird Zeit meine werte Leserschaft mit neuem Input zu füttern :-). Heute geht es aber noch ruhig zur Sache nur ein paar Links:

"Jester, if you don’t remember, is a little JavaScript library we developed here to act as a REST client."

Jester 1.6: Modern REST

Twitter: How Not To Crash Responsibly

Rubinius On Rails: Rubinius Becomes 3rd Ruby Implementation to Run Rails

Processing.js

Nichts mit IT aber gut:

Warum wir alles voll stopfen

So, heute mach ich mal den etwas anderen Blogpost. Bevor ich lange erzähle wie der Prototyp aussieht, seht ihn euch an:

http://www.youtube.com/watch?v=oRoVB_qwUfk

Kurz zum Workflow:

1) man legt ein Modell an
2) in dem Modell kann man dann beliebig viele Klassendiagramme anlegen
3) im Klassendiagramm kann man danach Elemente wie Klassen, Assoziationen usw. anlegen

Die Eingaben werden direkt Validiert d.h. ein Klassenname muß Modellweit eindeutig sein usw.. Anschließend werden die Daten in der Datenbank gespeichert. Bis jetzt spiele ich nur mit Klassendaten herum. Geht der User z.B. auf "Show" werden die Daten mittels JSON vom Server geholt und direkt in DIV's gerendert, an der Positionierung bin ich gerade dran. Legt der User eine Klasse an, wird die auch direkt an den Server gesendet und anschließend in die Arbeitsfläche gerendert. Die ganze JSON-Sache ist echt cool, weil man den ganzen "JSON-Baum" wunderbar auf Clientseite durchiterieren kann. So kann ich auch leicht auf Operationen und Attribute der Klasse zugreifen und ebenfalls in das Klassendiagramm rendern.
Naja, ich bin Müde deswegen ist für heute Feierabend. Kurz noch einen Ausblick wie es weiter geht:

update

- Positionierung hinbekommen
Die Positionierung klappt jetzt zumindest schonmal für Klassen. D.h. die Positionsdaten werden jetzt in der Datenbank abgespeichert und die Container befinden sich so bei einem neuen Aufruf an der bekannten Stelle.
Auf Datenbankebene ist das Ganze so gelöst, dass z.B. die Tabelle "clazz" - ist meine Konvention für class - in Beziehung mit der Tabelle "clazz_position" steht.

update end

- Assoziationen zwischen Klassen zeichnen können und die Semantik an den Server bekommen und auch wiederherstellen (diese Geschichte wird denke ich länger dauern, obwohl ich schon ein paar Ideen habe
- weiter an der Bedienung feilen

Letzte Woche ist der Rückblick direkt schonmal ausgefallen :-). Viel zu tun und am Sa. ging es dann auf die Euruko 2008. Es war eine gelungene Konferenz mit teilweise sehr guten Vorträgen.
Besonders cool fand ich den JRuby-Vortrag (denke auch ein interessantes Thema für Java-Entwickler).

Diese Woche habe ich mir schnell mal ein Subversion-Repository auf Beanstalk besorgt. Ist wirklich schnell eingerichtet und gut zu administrieren.

Dann bin ich noch auf Netbeans umgestiegen. Kann nur sagen, eine feine IDE. Gute SVN und CVS Integration, die Ruby Code-Completion scheint auch gut zu funktkionieren und Refactoring klappt auch, was will man mehr. Vorallem ist das Netbeans Rubypaket gerade einmal 20MB groß.

So und jetzt gibts noch paar Links:

Tonabnehmer 14 Ruby on Rails 2.0
-Riding Rails: A taste of what's coming in Rails 2.1
-Ryan's Scraps: What's New in Edge Rails: Dirty Objects
-UI-First Software Development
-Publish us: Getting Real, 2nd Edition

Ich versuche jetzt immer Freitags die besten(aus meiner Sicht:-)) Rails - Blogeinträge, Tools, Seiten - mit euch zu teilen. Ok, los gehts:

Ruby on Rails: the Duplo generation
How Duplo (and I) offended people
Big Name Companies Using Ruby on Rails
A Flickr-based Introduction to Ruby on Rails 2.0 nette GUI
Video Conversion in Ruby on Rails

Die nächsten Änderungen sind eingebaut. Ich hab aber auch noch ein paar Fragen:

"Die Klasse "Diagramme" bzw. "Klassendiagramm" sollte über Assoziationen ergänzt werden."

Ich hab jetzt der Klasse "Klassendiagramm" die Modellelemente bekannt gemacht. Oder sollte ich lieber die einzelnen Klassen z.B. "Klasse", "Assoziation" mit dem "Klassendiagramm" verbinden.

Pakete können ja wieder in Paketen stecken usw., die Beziehung soll wahrscheinlich auch mit in das Modell oder?

Die Anmerkung von Stefan mit Klassen- oder Instanzmethode muß ich noch einbauen.

Aufjedenfall bekomm ich langsam eine andere Sicht auf die UML. Ein Fehler am Anfang war das ich z.B. nicht zwischen der grafischen Repräsentation und der eigentlichen Semantik unterschieden habe :).
Wenn ich das richtig sehe, kann ich doch nachher gegen das Metamodell validieren?

Das Cheatsheet ist zwar noch für Rails 1.2 aber macht trotzdem einen ganz guten Eindruck.

So, nun wurden wieder ein paar Änderungen am Modell vorgenommen. Ich hab jetzt die Generalisierung reingebracht, allerdings erstmal nur für Klassen. Assoziationen können ja auch Generalisierungen beinhalten, soll das mit rein? Ansonsten hab ich noch einige Vorschläge von Phillip eingebaut, besser gesagt es Versucht :). In Kürze wird es aber nochmal ein Update des Modells geben.

Als nächstes möchte ich dann gerne die ganzen anderen Dinge wie Attribute und Operationen in das Modell einbauen. Als Leitfaden soll mir die OMG Superstructure dienen.

Und nun das Wort zum Sonntag: Auch wenn mir die ganze Metamodellierung nicht ganz so leicht fällt, macht es doch irgendwie Spaß :-)!

Hier ist mal der erste Versuch eines Metamodells für meine Anwendung. Dinge wie Generalisierung usw. hab ich in diesem Modell noch nicht betrachtet. Ich hab aber direkt mal ein paar Fragen:

- sollte ich die Operationen und Attribute evtl. "auslagern" und an eine eigene Klasse("xyz") hängen die später in Beziehung mit der Klasse("Klasse") steht?

- ist die Idee sinnvoll das man ein Modell anlegt und in diesem befinden sich die einzelnen Modell-Elemente?

- gehen die Gedanken in die total falsche Richtung?

Je mehr ich mich mit dem Thema "Zeichnen im Browser" beschäftige, umso mehr stellt sich die Frage, welche Technologie ich denn nun nutzen soll. SVG und das Canvas-Element haben beide ihre Stärken. Man kann mit JavaScript sowohl eine SVG-Grafik als auch Canvas-Elemente manipulieren was bei meinem Projekt unverzichtbar ist. Aber es kommt mir so vor, dass man mit dem Canvas-Element doch etwas einfacher arbeiten kann. Im Netz findet man einige Anwendungen die vom Canvas-Element Gebrauch machen:

http://pipes.yahoo.com/pipes/
http://www.mindmeister.com/
http://www.ditchnet.org/cocoauml/

Und da diese Anwendungen in einem gewissen Sinne mit meiner zu vergleichen sind, hab ich mal einen kleinen Prototypen mit dem Canvas-Element gebaut - ein sehr sehr gutes Tutorial gibt es übrigens hier - :

Man kann zwei Klassen anlegen, diese auch verschieben und eine Assoziation zwischen diesen Klassen erstellen. Der blaue Container - ein div-Element - enthält das Canvas-Element. So kann man nun dank JS auf die Assoziationen zugreifen. Die Verbindung ist aber noch nicht an die beiden Klassen gekoppelt.
Was bei mir als nächstes auf der Liste steht ist:

• welche Rechtecke sind miteinander verbunden und auf welche Art
• beliebig viele Rechtecke miteinander verbinden
• Verweis auf sich selbst

Die html-Seite könnt ihr hier bekommen (nur im Firefox > 2.0 getestet):

Download file

Jetzt auch mit allen libs. :-)!

Gibt es irgendwelche Einwände das mit dem Canvas-Element zu machen oder sonstige Anmerkungen?

Die Seite von David Dailey ist eine wahre SVG-Fundgrube. Die Seite sieht zwar etwas merkwürdig aus :), aber die Beispiele sind echt cool.

Vielleicht fragt sich jetzt ja der ein oder andere warum ich mich mit SVG beschäftige. Ich würde gerne die einzelnen Elemente - Klasse, Assoziationen usw. - im Frontend direkt als Grafik bereitstellen. Mal schauen ob das so klappt.

Ansonsten hab ich mir mal ein paar Gedanken zur Architektur der Plattform gemacht, die ich bei der nächsten Diplomandenrude gerne durchsprechen würde :-).