Domino 9 und frühere Versionen > ND8: Entwicklung - XPages

Automatisierte Migration Lotus Notes Client => XPages

<< < (2/4) > >>

Thomas Schulte:
Nathan is nicht mehr wirklich bei GBS. Und mit ihm sind eine Menge andere Leute ebenfalls gegangen. Und was die Firma selbst angeht ist vielleicht ein Blick auf das Blog von Vowe recht nützlich.
Ich bin teilweise der Meinung von Sven. Wenn du sauber definierte, in einem vernünftigen Wartungszyklus befindliche Anwendungen hast, die State of the Art Entwicklung darstellen und in denen nicht gefummelt wurde, zum Beispiel mit C-API aufrufen, dann kann es sein, das dir ein Tool tatsächlich etwas nützt.

Ich bin nur bei den 15 "Gleichen" Anwendungen anderer Meinung. Wenn du diese Struktur hast, dann ist es warscheinlicher, das der Aufwand für eine manuelle Neuschaffung kleiner ist als der sich in ein Tool einzuarbeiten und das mit den Mitteln und dann auch sehr deutlichen Grenzen des Tools durchzuführen.

Glombi:
Die ganzen Cracks von GBS sind nun hier gelandet:
http://redpilldevelopment.com/

Sieht irgendwie nach der Matrix aus  8)

Das wars dann wohl für den Transformer, oder?

Andreas

Ralf_M_Petter:
Zitat von Nathan: "You might notice, of course, that the above list includes a rather prominent team from GBS. Does this mean we are leaving the company? Yes and no. We're no longer going to be employees or representatives of GBS, but we have close ties to the company and have entered into several ongoing agreements. Details on these will be published later."

Sein Blog wird auch nachwievor von GBS gehostet. Sieht für mich also nicht so aus, als ob redpilldevelopment nicht weiter für GBS arbeiten sollte.

Grüße

Ralf

flaite:
http://redpilldevelopment.com/
Vorsicht mit irgendwelchen Rückschlüssen auf die realen Gegebenheiten von den Aussagen auf dem blog vom Gädget (mein liebevoller Spitzname für vowe).
Dessen Kompetenzen konzentrieren sich auf zwei Felder:
- wochenlanges Herumspielen mit wild blinkenden technischen Gerätschaften.
- Public Relations
Das immer im Hinterkopf behalten.  

Solche Code-Automatisierungs-Tools sind leider auch ein emotionales Thema. Sie entsprechen dem Traum von IT-Controllern/Management, dass man das Zeug bestimmt auch mit Maschinen generieren kann und so auf diese seltsamen und kostspieligen Entwickler/Programmierer verzichten kann, die in einer beunruhigenden Parallelwelt zu leben scheinen. Für Programmierer stellt es eine Art Territorial-Verletzung dar. Stichwort: Da pinkelt ein Roboter an MEINEN Baum.

Ich find diese generelle Ablehnung wenig realistisch, weil ja der Notes Designer bei jedem Abspeichern von source code das Zeugs letztlich in nativen Code für den Prozessor übersetzt. Das was in der Anwendung WIRKLICH läuft, würde keiner von uns wiedererkennen.    
Nur gibts natürlich in Anwendungen so viele Spezialitäten, dass sie von keinem Code Konvertierer wirklich auf die neue Plattform umgesetzt werden können. Auch nicht in 2 Jahren, nicht in 10 Jahren, nicht in 100 Jahren, nicht in 1000 Jahren, nicht in 10000 Jahren, nicht in 100000 Jahren. Mit dieser Erkenntnis tun sich viele IT-Controller/Manager schwer.
Tools können aber eine Konvertierung in eine andere Plattform unterstützen. Die stellt aber ein komplexes Projekt dar. Deshalb laufen ja noch diese vielen Cobol-Programme auf den sündhaft teuren Groß-Rechnern für deren Experten man inzwischen Mond-Preise bezahlt. Technisch wäre die Portierung auf moderne Plattformen kein Thema. Nur muss man vorher den Code der alten Programme in vielen, vielen, vielen Details verstehen. Genau dieser Punkt ist sehr teuer.
Ihr braucht auf eurer Seite auf jeden Fall Notes Experten, im besten Fall Notes UND XPages Experten. Oder Java/JEE/RichFaces Experten, die Lust haben sich in XPages reinzuarbeiten, weil das halt Enterprise Java ist. Kann vorteilhaft sein, dass Leute dabei sind, die das ganze rein aus der Sicht der Ziel-Plattform betrachten. Man braucht aber immer Notes-Experten UND WIRKLICHE XPAGES/JEE Experten. Ein Notes-Mann, der ein bischen mit Xpages rumgedaddelt hat, ist KEIN wirklicher XPAGES/JEE Experte. Ein JEE Mann, der sich ernsthaft in XPages einarbeitet eher.  
Gegenüber Redpill die hohen Erfolgs-Risiken des Projekts möglichst spät übernehmen, ohne unfair zu sein. Die Katze also nicht im Sack kaufen.
Grundsätzlich ist sowas tool-unterstützt schon möglich. War selbst an der Konvertierung von einer Domino Anwendung auf eine CRM Plattform beteiligt, die ich nicht mal beherrsche. So eine sehr abstrakte, model-artige Erweiterung/Change kann Kosten sparen, muss aber nicht. In jedem Fall brauchts Experten, die sich in der Ausgangs-, Zielplattform und Anwendungs-Entwicklung insgesamt auskennen.

Ohne jenes Tool, das über einen Release Prozess namens Evolution und unter möglicherweise göttlicher Beteiligung entstanden ist und das wir gemeinhin als menschliches Gehirn bezeichnen, gehts nicht.

Sven Hasselbach:
@Pitiyankee:
Prinzipiell kann ich Deinen Ausführungen nur zustimmen, bis auf das hier:


--- Zitat ---Ein Notes-Mann, der ein bischen mit Xpages rumgedaddelt hat, ist KEIN wirklicher XPAGES/JEE Experte. Ein JEE Mann, der sich ernsthaft in XPages einarbeitet eher.

--- Ende Zitat ---
Wenn es sich um eine neue Applikation handelt, dann ist der JEE Mann im Vorteil. Aber bei einer bestehenden Applikation ist er doch eher hoffnungslos aufgeschmissen. Ich habe in den letzten zwei Jahren ein paar "Newbies" erlebt, die Fit in Java, auf XPages losgelassen wurden, und unglaubliche Probleme mit dem Backend hatten - und so in ständige Konzeptprobleme gerasselt sind (umgekehrt sind die Notes-Hasen natürlich in die JEE Fallen getappt). Für beide Seiten ist der Einstieg hart, aber bei einer Migration muss man wissen, was passiert.

Hält man sich vor Augen was für "Sauereien" mit Notes Applikationen möglich sind, kann die der JEE Mann nicht überblicken. Man kann ja wichtige Funktionen in Applikationen sonstwo "verstecken", sei es ein Button (Der eine Button mit diesem achtzeiligen, komischen Konstrukt aus @() usw., naja, egal. Wird schon nicht so wild kompliziert sein...), die guten "%Includes" im LS Code, gekapselte UI Funktionen, usw usf.

@Thomas Schulte:
ich meinte nicht 15 gleiche Applikationen, sondern 15 Applikationen, die allesamt einen gleichen Unterbau haben (Stichwort "Konfigurationsmechanismus" usw), so daß man nicht jede Applikation komplett nachbessern muss.

@All:
Hier ein Info-Link für das Prozedere: http://www.dnug.de/DNUG/dnugcms.nsf/5a419d474f3279b3c1256c09002f3b2a/05adda58c21126cfc12578f0004cbcb1/$FILE/V3-2011-11-08%20-%20GBS%20Transformer%20-%20Anwendungen%20f%C3%BCr%20die%20Zukunft.pdf

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete