Hurra: Lotus Component Designer alias Lotus Workplace Designer wird aufgegeben

[flaite]

Lotus Component Designer alias Lotus Workplace Designer wird aufgegeben 
Gute Entscheidung von IBM. Das Produkt stiess auf kein Interesse und war auch wirklich sch...
Businesslogik sollte da in JavaScript reingehackert werden und dies öffnete die Türen weit für Entwickler obfuscation.
Bei meinem vorletzten Arbeitgeber zerschoss die sehr einfache Testumgebung alle 2 Wochen die DB2-Datenbank.
Ich hoffe, dass Lotus lernt und von solchen merkwürdigen Solos an der Seitenlinie in Zukunft die Finger läßt. Dann lieber mit OpenOffice, Eclipse Software Foundation und vielleicht irgendwann sogar Interface21/Springframework zusammenarbeiten.
http://vowe.net/archives/008873.html#comments
Die Comentaristas auf vowe.com zeigten mal wieder ihre gewohnt starke Form, um den täglichen "you-make-me-want-to-stick-a-knife-in-my-balls" Preis zu gewinnen. Vor allem das Gefasel eines Roland Leißl "Java architecture", "natural born Notes developer" und "Paradigm and platform of Lotus Notes".

[Ralf_M_Petter]

Hallo Axel!

Ich kann dir da überhaupt nicht recht geben. Die idee und auch die Umsetzunge ist prinzipiell nicht schlecht. Es ist ein Tool um auch Entwicklern die jetzt nicht die Möglichkeit oder die Fähigkeiten um für Portal zu entwickeln haben, auch Sachen umzusetzen. Ich finde, dass das vor allem für kleine IT Abteilungen in KMUs schon ein parktikabler Ansatz ist und hoffe, dass vieles von LCD sich im neuen Eclipse Domino Designer wiederfindet.

Dass LCD wirklich die DB/2 beschädigen kann, glaube ich dir nicht so ganz. Wir haben seit 1994 DB/2 auf der AS/400, Iseries I/5 im Einsatz und haben mit den verrüktesten Tools darauf zugegriffen. (Access, Centura SqlBuilder, Notes, Websphere Express, Excel...) und hatten nie eine Korruption der DB/2.

Grüße

Ralf

[flaite]

Hallo Ralf,

hab das nur am Rande mitbekommen und da waren auch keine wirklich professionellen DB2 DBAs beteiligt.

Meine Meinung ist bestimmt nicht die einzig wahre. Aber ich hab ein ungutes Gefühl, sobald IBM hergeht und im Namen der "Einfachheit" für Entwickler Abstraktions-Layer einziehen, die sie dann aber nicht wirklich konsequent managen oder weiterentwickeln. So übrigens kürzlich wieder erlebt bei relativ kostspieligen SAP Konnektoren. Änderungen auf der SAP Seite wurden auf der Konnektoren Seite nicht berücksichtigt und der Prozess mit dem Support könnte manchmal schneller sein.

Warum nicht einfach auf vorhandenes aufbauen, das ganze transparent halten und dadrauf dann Entwicklungs-Tools bauen, die es auch mehr "Wie"-orientierten Kollegen ermöglicht, neue Standards zu nutzen? Dann hat man auch als erfahrener Entwickler viel bessere Möglichkeiten die Kenntnisse einzusetzen. Wär für mich viel einfacher Gotchas und eventuelle bugs im IBM Zeugs zu verstehen.   
Ich mein damit Tools bei denen man den Source Code der generierten Portlets noch irgendwo sieht.
Aber im Namen der "Einfachheit" wird dann eine Black Box auf den Markt geworfen und das Ganze mit "Pragmatismus" begründet. Naja. Der Markt hat sich entschieden. Expeditor, die OpenOffice Geschichten, etc. sind offener und weisen in eine andere, transparentere Richtung.

1. Erfahrene Entwickler verwenden einen Teil ihrer Zeit damit, den Code übersichtlich und leicht veränderbar zu halten. Workplace Designer war imho so aufgebaut, dass darauf überhaupt keine Rücksicht genommen wird. Man konnte alles "kreativ" zusammenmatschen und hatte schnell ein gut-aussehendes Ergebnisse. Dies sehr leicht auf Kosten von Struktur (Übersichtlichkeit, Veränderbarkeit). Es ist statistisch erwiesen, dass viel mehr Kosten durch maintenance als durch Erstentwicklung von IT-Systemen entstehen. Dieser "pragmatische" Ansatz verhält sich gegen diese empirische Wahrheit. Es wird damit geworben, dass es erstmal nicht so "schwierig" ist. Im Nachhinein stellt sich dann aber heraus, dass Änderungen (auf Grund von Unter-Strukturierung zu Anfang) viel teurer werden. 
2. Von für mich inzwischen unverzichtbaren QM-Maßnahmen wie Unit-Testing war nicht einmal die Rede.
3. Es war ein Alleingang von IBM.  Als Entwickler oder Partner geht man damit stärkere Risiken ein,  als wenn die Architektur von mehreren genutzt und angeboten würde.
 
Gruß Axel

[Ralf_M_Petter]

Wie gesagt, du bist sicher nicht die Zielgruppe für LCD. Das Tool ist genauso wieder der Domino Designer eher für kleinere Projekte bei denen man schnell zu Ergebnissen kommen will. Das ganze ist meiner Meinung nach auch eine Bugdetfrage. Bei uns in der Firma habe ich ein CRM in Domino/Notes implementiert. Sicher ist es nicht 100% ideal gemacht, aber es funktioniert und es war vergleichsweise billig. Wenn man das mit allen Schikanen auf .Net Java oder sonst einer Programmierumgebung aufgezogen hätten dann wären wir heute noch nicht mal mit Modul 1 im Rollout. Man sieht das auch ganz einfach daran, wie einfach es in Notes doch ist z.B. mal schnell eine View zu erstellen. Wenn ich aber im Sidebar ein Plugin programmieren will, dann dauert das schon mal ungleich länger. Das ich dann natürlich ganz andere Möglichkeiten habe steht wieder auf einem anderen Blatt.

Fazit: Wenn ich viel Budget und Ressourcen habe und eine professionelle Lösung eventuell zum Verkaufen will, dann werde ich weder Domino Designer noch LCD verwenden. Wenn ich aber für den eigenen Firmenbedarf eine Speziallösung programmiere die noch dazu nicht extrem viel kosten darf, bin ich mit Domino Designer und LCD sicher nicht schlecht aufgestellt.

[flaite]

Ist die alte Debatte und seh das anders.
Was heisst Programmierumgebung Java/.NET?
ASP.NET? Sharepoint? JSF-Springframework?
Seh da keine besonderen Alleinstellungsmerkmale von Lotus Notes oder Domino Workplace.
Plattformen sind eben immer darauf ausgerichtet, dass Dinge schnell entwickelt werden können.

Geschwindigkeit mit der eine Ansicht programmiert werden kann, hängt halt sehr von dem verwendeten Framework-Stack ab.
Im übrigen wird sich SOA in den nächsten Jahren so auswirken, dass Integrierbarkeit/Komponentisierung wichtiger wird.

Ich entwickele zur Zeit bestehenden Lotus Script/Formelsprache Code, JavaScript/Ajax, Java Komponenten sowie Testweise IBM Portal. Seh da keine großen Geschwindigkeitsunterschiede in der Entwicklung. Letztlich sind das alles Plattformen und Programmiersprachen.
Muss man da neue proprietäre Umgebungen entwickeln? Sowas wie Ruby on Rails versteh ich. Das ist openSource. Da gibts eine Community hinter. Die kümmern sich um Unit Test Frameworks, etc. Aber proprietär? Hauptsächlich darauf ausgerichtet, dass Entwickler schnell etwas zusammenklicken können?

[Ralf_M_Petter]

Ich verstehe Deine Meinung ich hoffe du meine auch?

Grüße

Ralf

[flaite]

Ja. Versteh ich schon.
In diesem neuen Zeugs seh ich 2 grundlegende organisatorische Ansätze:
1. Tight Management of the platform stack.
2. Cooperative Management of the platform stack.
Lotus Workplace ist - wie das von mir wirklich geschätzte Netbeans - von einem Hersteller. Der kann dann ohne  weitere Diskussionen in Standardisierungsgremien genau entscheiden, wie was gemacht werden soll.
Sowas wie Expeditor, Symphony ist 2. IBM ist dort auf eine Zusammenarbeit mit Sun OpenOffice oder Eclipse Software Foundation angewiesen. Die Entscheidungsfindung ist komplexer, aber es gibt einfach mehr Leute, die dran arbeiten. Die Zusammenarbeit führt möglicherweise zu einer besseren Überprüfung von Design-Entscheidungen.

Man kann so gar nicht entscheiden, welcher Weg jetzt der "Richtige" ist. Der zweite Weg hat sich zu meinem Erstaunen in vielen Bereichen als echt effizient erwiesen. Z.B. in Eclipse oder in dem Ausmaß, in dem Springframework von Application Servern adoptiert oder zumindest offiziell unterstützt wird.