Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

Sind Notesler zu sehr auf ihre Plattform fixiert?

<< < (3/4) > >>

wfh:
Axel,

Unausgereiftheit ergibt sich für mich aufgrund des Alters einiger Produkte (z. B. Workplace). Notes/Domino war auch erst nach 10 Jahren einigermaßen in Ordnung.  Das ist eine Feststellung, keine Kritik. Man sollte vorher klären, was man sich mit einer Software "antut" (im postivien, wie im negativen).

Aber bei der Komplexität erwischt Du einen "wunden" Punkt bei mir. Ich sehe in diesem Zusammenhang auch die Entwicklung im Notes/Domino-Umfeld kritisch: Mit DB2-Integration und Websphere (WAS) als J2EE-Server inkl. NAS-Anbindung des Storage über ISCSI und Virtual LANS bei ausgesourcetem Netzwerk. Wer soll da noch den Durchblick haben bzw. die Konsequenzen bei kleinsten Änderungen abschätzen können (von Fehleranalyse ganz zu schweigen). Der Netzwerkspezialist, der OS-Guru oder der DB/JE22-Freak und dies vielleicht zusammen? Ist für mich eine interessante Frage und wird unsere Jobs auf absehbare Zeit sichern, aber...
J2EE ist in diesem Zusammenhang für mich so ein Konstrukt. Daher, sagen wir mal, meine Skepsis (klar auch Notes/Domino ist komplex, aus meinem Blickwinkel aber weniger als andere Konstrukte). Klar die Entwicklung geht weiter, aber ich muss mich als Unternehmen/Firma auch klar darüber sein, was es kostet, derartiger Konstrukte zu betreuen (dies gilt gerade auch bei Know-how, das ich mir extern einkaufe). Wobei klar ist: Es gibt Applikations-Anforderungen, die dies notwendig machen. Die Frage ist nur: Wieviele derartiger Applikationen gibt es in einem Unternehmen und habe ich eine IT-Strategie?
Notes/Domino ist ein Allrounder und das ist der Charm in vielen, aber nicht allen Bereichen. Auch Notes/Domino muss sinnvoll eingesetzt werden, um davon einen Nutzen zu haben.

Servus
Wolfgang

Marinero Atlántico:
Wolfgang,

--- Zitat von: wfh am 31.01.05 - 19:47:39 ---Unausgereiftheit ergibt sich für mich aufgrund des Alters einiger Produkte (z. B. Workplace). Notes/Domino war auch erst nach 10 Jahren einigermaßen in Ordnung.  Das ist eine Feststellung, keine Kritik. Man sollte vorher klären, was man sich mit einer Software "antut" (im postivien, wie im negativen).

--- Ende Zitat ---
Es existiert auch sowas wie Software Entrophie. D.h. auf Systeme wird immer mehr draufgepackt und am Ende geht die Struktur flöten.
Beispiele hierfür sind imho Notes RichText sowie die Klassen NotesViewEntry, NotesViewEntryCollection, etc.

Viele langjährig laufende Anwendungen basieren teilweise auf "historisch gewachsenen" code. Erweiterungen, Fehlerausmerzung komplizieren und verteuern sich in diesem Wust z.T. immens.
Auch zu Domino basierenden add-on Produkten wie DWF und auch LEI kann ich inzwischen eine Menge stories erzählen. Letztlich bleibt es an mir hängen, die Fehler zu suchen. Und es stellt sich oft heraus, dass ich z.B. nach einem Wechsel von Domino R5.10 -> R5.11, die issues an Fehlfunktionen besagter Produkte liegt (die überhaupt nicht geändert wurden). Ich find die Hinweise dann immer im Workflow und Enterprise (Des-)Integration Forum von Notes Net. J2EE und .NET besitzen hier einfach eine wesentlich saubere Architektur. Diese Architektur ermöglicht es, dass Anwendungen nicht mehr zu unübersichtlichen Monstern werden.   


--- Zitat von: wfh am 31.01.05 - 19:47:39 ---Mit DB2-Integration und Websphere (WAS) als J2EE-Server inkl. NAS-Anbindung des Storage über ISCSI und Virtual LANS bei ausgesourcetem Netzwerk. Wer soll da noch den Durchblick haben bzw. die Konsequenzen bei kleinsten Änderungen abschätzen können (von Fehleranalyse ganz zu schweigen). Der Netzwerkspezialist, der OS-Guru oder der DB/JE22-Freak und dies vielleicht zusammen? Ist für mich eine interessante Frage und wird unsere Jobs auf absehbare Zeit sichern, aber...

--- Ende Zitat ---
Tja. Diese Richtung sieht man hier leider sehr oft. Auf der LotusSphere war die Stimmung scheinbar ein bischen anders (nämlich pro J2EE).
Nicht nur meiner Meinung nach lassen sich Fehler viel leichter in einer sauber strukturierten und gelayerten J2EE Architektur finden als in einer komplexeren Notes-Datenbank (wo potentiell jedes Feld und jeder Agent mit seiner warmen Hand direkt auf die Backend-Datenbestände von anderen Datenbanken zugreift). Man hat auch mit Profilern, etc. viel bessere Analysetools und mit OO, TDD uvam. Methoden der Anwendungsentwicklung, die zu übersichtlicheren Anwendungen führen.


--- Zitat ---J2EE ist in diesem Zusammenhang für mich so ein Konstrukt. Daher, sagen wir mal, meine Skepsis (klar auch Notes/Domino ist komplex, aus meinem Blickwinkel aber weniger als andere Konstrukte). Klar die Entwicklung geht weiter, aber ich muss mich als Unternehmen/Firma auch klar darüber sein, was es kostet, derartiger Konstrukte zu betreuen (dies gilt gerade auch bei Know-how, das ich mir extern einkaufe). Wobei klar ist: Es gibt Applikations-Anforderungen, die dies notwendig machen. Die Frage ist nur: Wieviele derartiger Applikationen gibt es in einem Unternehmen und habe ich eine IT-Strategie?

--- Ende Zitat ---
Es gibt mittlerweile sehr viele J2EE Anwendungen. Es ist kein theoretisches Konstrukt. Es ist Praxis. 

Ich sehe es so. Du siehst es anders.

Axel

P.S. Leute, die glauben, dass J2EE/.NET erst in einigen Jahren stabil sein wird, haben eine interessante Zeit vor sich. Sie werden weiterhin eine Menge Überraschungen erleben.  ;D

Thomas Schulte:

--- Zitat von: Marinero Atlántico am 01.02.05 - 09:57:34 ---Es existiert auch sowas wie Software Entrophie. D.h. auf Systeme wird immer mehr draufgepackt und am Ende geht die Struktur flöten.

--- Ende Zitat ---
Full ACK


--- Zitat von: Marinero Atlántico am 01.02.05 - 09:57:34 ---Viele langjährig laufende Anwendungen basieren teilweise auf "historisch gewachsenen" code. Erweiterungen, Fehlerausmerzung komplizieren und verteuern sich in diesem Wust z.T. immens.

--- Ende Zitat ---
Ebenfalls. Diese Aussage stimmt so.  gilt mit hoher Warscheinlichkeit irgendwann auch für  J2EE. Dieses "Produkt" ist  im Vergleich zu anderen noch am Anfang seines Lebenszyklus. Warten wir ab, wie es da mit der Komplexität in sagen wir einmal 10 Jahren ausschaut.


--- Zitat von: Marinero Atlántico am 01.02.05 - 09:57:34 ---Zu Domino basierenden add-on Produkten wie DWF und auch LEI kann ich inzwischen eine Menge stories erzählen. Letztlich bleibt es an mir hängen, die Fehler zu suchen. Und es stellt sich oft heraus, dass ich z.B. nach einem Wechsel von Domino R5.10 -> R5.11, die issues an Fehlfunktionen besagter Produkte liegt (die überhaupt nicht geändert wurden). Ich find die Hinweise dann immer im Workflow und Enterprise (Des-)Integration Forum von Notes Net. J2EE und .NET besitzen hier einfach eine wesentlich saubere Architektur. Diese Architektur ermöglicht es, dass Anwendungen nicht mehr zu unübersichtlichen Monstern werden.

--- Ende Zitat ---
Und genau das glaube ich nicht. Es mag sein das das vielleicht etwas leichter möglich ist, Anwnedungen zu schreiben die keine "Monster" werden, aber: 99% aller Monster sind deswegen Monster weil ohne Plan von unterschieldichen Personen mit sehr unterschiedlichen Erfahrungsgraden daran gearbeitet wurde ohne einen "Masterplan" und jemand der ihn überwacht zu haben, Das es also Monster gibt liegt nach meiner Erfahrung nicht an der Sprache oder Umgebung in der eine Anwendung entwickelt wird, sondern an den Entwicklern.

Und was die Fehlersuche angeht. Da sind Monster und gut strukturierte Anwendungen für mich ziemlich gleich. Solange ich nur aus den Reaktionen an der Oberfläche auf den Fehler im Kern der Anwendung Rückschlüsse ziehen  kann und muss, weil ich keine Sourcen auf die ich zugreifen kann zur Verfügung stehen habe, solange ist es egal, ob ich in C, C++, Perl, .Net , Java oder Lotus Script programmiere, ob ich  Eclipse oder WSAD oder den Domino Designer als Framework benutze oder ob eine Relationale oder eine Domino Datenbank  meine Datenbasis bildet. Ich sehe den Fehler nicht  und kann daher nicht direkt auf das Problem schließen sondern muss mich dem Ziel auf Umwegen nähern.


--- Zitat von: Marinero Atlántico am 01.02.05 - 09:57:34 ---Nicht nur meiner Meinung nach lassen sich Fehler viel leichter in einer sauber strukturierten und gelayerten J2EE Architektur finden als in einer komplexeren Notes-Datenbank (wo potentiell jedes Feld und jeder Agent mit seiner warmen Hand direkt auf die Backend-Datenbestände von anderen Datenbanken zugreift). Man hat auch mit Profilern, etc. viel bessere Analysetools und mit OO, TDD uvam. Methoden der Anwendungsentwicklung, die zu übersichtlicheren Anwendungen führen.

--- Ende Zitat ---
Auch das hat meiner Meinung nach nichts mit J2EE zu tun sondern einfach mit der Tatsache, ob "sauber" programmiert und dokumentiert wurde. Jede Methode der Anwendungsentwicklung oder Analyse ist per se erst einmal unabhängig von einer bestimmten Sprache oder Umgebung.  Worin ich dir beipflichte ist, das es durchaus Umgebungen gibt die bestimmte Methoden besser unterstützen als andere. Oder was das angeht Tools die die Analyse besser unterstützen.

Semeaphoros:
Kurz zusammengefasst, was Thomas da eben gesagt hat:

Saubere, strukturierte Arbeit ist der Schlüssel zum Erfolg, unabhängig vom eingesetzen Werkzeug und dessen allenfalls vorhandenen Einschränkungen.

Marinero Atlántico:

--- Zitat von: Thomas Schulte am 01.02.05 - 10:30:23 ---Ebenfalls. Diese Aussage stimmt so.  gilt mit hoher Warscheinlichkeit irgendwann auch für  J2EE. Dieses "Produkt" ist  im Vergleich zu anderen noch am Anfang seines Lebenszyklus. Warten wir ab, wie es da mit der Komplexität in sagen wir einmal 10 Jahren ausschaut.

--- Ende Zitat ---
Ist wie diskutieren über ungelegte Eier, aber ich glaube (wissen kann man das nicht), dass man heute weiter ist hinsichtlich der "Reinhaltung" einer komplexen Architektur und auch ein stärkeres Bewusstsein für Software-Enthropie besitzt. Z.B. geht man auch bei Release-Wechseln härter vor. Z.B. hat sich Websphere Administration dramatisch geändert in 5. EJBs sind auch sehr anders in EJB2.0 gegenüber EJB1.2/1.1/1.0. Dieser Hang zum Neubau war sicher nicht immer lustig für die Projektverantwortlichen, hilft aber auch die Architektur reinzuhalten. In EJB3.0 wird noch einmal ein ernsthaft radikaler Wandel vollzogen. 

--- Zitat von: Thomas Schulte am 01.02.05 - 10:30:23 ---[SkriptMonster]Und genau das glaube ich nicht. Es mag sein das das vielleicht etwas leichter möglich ist, Anwnedungen zu schreiben die keine "Monster" werden, aber: 99% aller Monster sind deswegen Monster weil ohne Plan von unterschieldichen Personen mit sehr unterschiedlichen Erfahrungsgraden daran gearbeitet wurde ohne einen "Masterplan" und jemand der ihn überwacht zu haben, Das es also Monster gibt liegt nach meiner Erfahrung nicht an der Sprache oder Umgebung in der eine Anwendung entwickelt wird, sondern an den Entwicklern.

--- Ende Zitat ---
Naja. Sehe ich z.T. auch so. Auf der anderen Seite ist die Planungsfähigkeit des Menschen eben beschränkt (s. Untergang des Kommunismus). Ich bin auch völlig hoffnungslos bezüglich des rationalen Verhaltens menschlicher Organisationen (Projektgruppe). Für rationales Verhalten braucht man:
1. vollständige Information (Softwareprojekte sind irgendwie immer auch Entdeckungsverfahren, dh man trifft auf unerwartetes und alle Leute überschätzen die Qualität der Informationen auf denen ihre Entscheidungen beruhen, inklusive explizit ich).
2. rational für das Gemeinwohl arbeitende Beteiligte. (Leute verfolgen aber auch immer subjektive Ziele und vieles hat mit Politik zu tun. Und: Es ist nicht immer so, aber ich glaub jeder hat schon Leute Projektpläne erstellen sehen, die stattdessen besser Mittags das Essen ausgegeben hätten.
 
Ausserdem: Die Agile-Bewegung hat klar darauf hingewiesen, dass die Requirements der Projekt-Anwender sich quasi immer während des Projekts ändern. Das stürzt den schönsten Plan um. Gerade deshalb benötigt man Entwickler, die changing requirements erwarten und trotzdem die Anwendung stabil halten. Unit Tests, Design Patterns, Kappselung durch OO, Kappselung durch geschichtete Architekturen helfen hier. Da glaub ich inzwischen ziemlich fest dran. Es ist nicht einfach und erfordert Erfahrung. 

--- Zitat ---nur aus den Reaktionen an der Oberfläche auf den Fehler im Kern der Anwendung Rückschlüsse ziehen  kann und muss, weil ich keine Sourcen auf die ich zugreifen kann zur Verfügung stehen habe, solange ist es egal, ob ich in C, C++, Perl, .Net , Java oder Lotus Script programmiere, ob ich  Eclipse oder WSAD oder den Domino Designer als Framework benutze oder ob eine Relationale oder eine Domino Datenbank  meine Datenbasis bildet. Ich sehe den Fehler nicht  und kann daher nicht direkt auf das Problem schließen sondern muss mich dem Ziel auf Umwegen nähern.

--- Ende Zitat ---
Die Sourcen von Java sind weitgehend frei zugänglich. Perl ist soweit ich weiss openSource. Eclipse ist openSource. Viele RDBMS sind openSource (java: hsqldb, derby. c/c++(?): mySql, PosGreSQL (jetzt_auf_windows_ohne_cygwin.nett.btw)). Die Frage ist natürlich inwieweit man in der Lage ist, dort den Source code zu durchblicken. Immerhin gibt es gerade für OpenSource Projekte gute Foren.

--- Zitat ---Auch das hat meiner Meinung nach nichts mit J2EE zu tun sondern einfach mit der Tatsache, ob "sauber" programmiert und dokumentiert wurde. Jede Methode der Anwendungsentwicklung oder Analyse ist per se erst einmal unabhängig von einer bestimmten Sprache oder Umgebung.  Worin ich dir beipflichte ist, das es durchaus Umgebungen gibt die bestimmte Methoden besser unterstützen als andere. Oder was das angeht Tools die die Analyse besser unterstützen.

--- Ende Zitat ---
Auch hier wieder großes (und vielleicht über-idealistisches) Armwinken von meiner Seite: Es hat noch nie einen Entwickler-Pool gegeben, der so intensiv und leidenschaftlich über die maintainability von Anwendungen nachgedacht und diskutiert hat als gerade Java Leute. Gut. Vielleicht SmallTalk. Aber das ist wirklich zu langsam. Bei C++ gab/gibt es glaub ich große Unterschiede. Das war - so weit ich es Überblicke - ab einem gewissen Level sehr elitär. Und ausserdem erlaubte die Sprache an sich große Unsauberkeiten.
Es geht nicht um die Erfüllung von "richtigen" Methoden. Methoden sind immer kontext-abhängig. Imho geht es um Wissen, Erfahrung und Skepsis. Methoden sind immer eingebettet in einem Kontext und sowas wie Rational Unified Process besteht bewusst rein aus optionalen Modulen.   
Es geht nicht um Tools. Ich bin bekennender Rationale-Hasser. Tools können auch im Weg stehen. Haben hier gerade den Einsatz von Rational Test Director für das Projekt gekippt (haha). 
Bin im letzten Jahr zu einem immer größeren Freund von leichtgewichtigen Prozessen und Tools geworden.

Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete