@Formula-Befehle in Lotus Script abbilden

[Axel_Janssen]

folgende Use Cases

+ Neues Code Dokument erstellen/bearbeiten/löschen.
(zu trivial um jetzt weiter spezifiziert werden zu müssen).

+ Code Dokument suchen (Über Kategorien oder Volltextsuche über Beschreibung)
(zu trivial, um jetzt weiter spezifiziert werden zu müssen).

+ Kollaborationsfeature für Version 1.0
sehe 2 Alternativen: zentraler Server oder P2P für Arme.

Wie ich das am Schreiben war, dachte ich das der zentrale Server doch wg. Bedienerkomfort und einfacher-zu-programmieren sehr vermutlich die bessere Lösung darstellt.

Wir müssen bei der Replizierung mit dem zentralen Server nicht Notes-Replizierung nehmen, sondern wir können das nachprogrammieren.
Der Server im Internet ist ja nicht unbedingt ein Notes-Server und v.a. ist er nicht in der selben Domäne wie der Client im Firmennetzwerk oder zu Hause. Hin und hergeschickt zwischen dem Server im Internet und Client werden dann xml-Dokumente. Diese enthalten Replizierungsanforderungen und zu replizierende code-Dokumente. Das ginge dann über http und macht firewall-mässig keine Probleme

a) User intiierte -Push-Replizierung
pre-condition: User ist mit dem Internet verbunden.
post-condition: die seit der letzten push-Replizierung vom User geänderten/neuen Dokumente befinden sich auf dem zentralen Server

- User betätigt Button Push-Replizierung
- lokales System schaut nach Datum der letzten Push Replizierung
System packt die nach der letzten Replizierung geänderten/neuen Dokumente in eine xml-Struktur.
- lokales System sendet die xml-Struktur per http gegen den zentralen Server (zentrales System).
- zentrales System fügt die in der xml-Struktur enthaltenen code-Dokumente (etwa nach einer Transformation in Notes-Dokumente) in den eigenen Datenbestand ein.

pre-condition: User ist mit dem Internet verbunden.
post-condition: die seit der letzten pull-Replizierung im zentralen System geänderten/neuen Dokumente befinden sich im Datenbestand des clients

b) user initiierte Pull Replizierung
-  - User betätigt Button Pull-Replizierung
- lokales System erzeugt ein xml-Dokument, das den Namen des Users und das Datum der letzten Pull Replizierung enthält
- lokales System sendet das Pull-Replizierungs-Anforderungs-xml gegen den zentralen Server (über http)
- zentrale Server empfängt das Replizierungs-Anforderungs-xml
- zentrale System packt aus eigenen Datenbestand neue/geänderte code-Dokument in ein Pull-Replizierungs-Antwort xml
- zentrale System schickt Pull-Replizierungs-Antwort.xml an den Client (als normale http-Response).
- lokales System fügt die neuen Dokumente in den eigenen Datenbestand ein.

c)
a) und b) lassen sich auch zu einer Push-Pull-Replizierung verknüpfen.

2. P2P Lösung
In Java gibt es zwar P2P-Lösungen. Die sind aber echt komplex und vermutlich nicht richtig ausgereift. Außerdem befürchte ich eine Menge Probleme durch Firmen-Firewalls, Personal-Firewalls, nicht-feste-IP Adressen und ganz allgemein Sicherheit.

Deshalb p2p für arme:
1. User A wählt aus einer Liste, den anderen User B aus, von dem er eine Pull-Replikation haben will.
2. System erstellt ein xml-Dokument, das Datum, Zeitpunkt der letzten Pull Replikation von User A gegen User B sowie den Namen, die email von User A enthält.
3. User A hängt das xml-Dokument an eine Mail an und adressiert diese an User B
4. User B löst das von User A gesendete Attachment aus der Mail in ein bestimmtes Verzeichnis.
5. User B betätigt Button, um ein weiteres xml-Dokument erzeugen (Pull-Replikations-Antwort-Dokument). Dieses xml-Dokument enthält die xml-Repräsentation aller code-Dokumente (s.o.), die nach dem Datum der letzten Pull-Replikation erstellt oder geändert wurden.
(Frage: Deletion-Stubbs?)
6. User B hängt das Pull-Replikations-Antwort-xml an eine Mail und sendet diese an den Pull-Replikations-Anforderer User A.
7. User A detached Pull-Replikations-Antwort-xml auf eine bestimmte Stelle auf der Festplatte.
8. User A betätigt Button und die Pull-Replikations-Antwort-xml-Dokumente werden in den Datenbestand seines code-repositories aufgenommen.

(für Leute, die LoNo als häusliches-Mailprogramm benutzen kann die Mail-Verschickung auch automatisiert werden, mit Outlook oder Mozilla-Mail hab ich das noch nicht gemacht, wobei sollte auch gehen).

[koehlerbv]

Ääh, verteilen wir jetzt nicht das Fell des Bären, bevor wir ihn gefangen haben ?
Was hatte das jetzt noch mit einer LotusScript-Goodies-Lib gemeinsam ?

Bernhard

[Axel_Janssen]

Was das Thema XML jetzt hier soll, kann ich nicht ganz nachvollziehen ...
...

Ich gebe dir zum großen Teil recht. Zunächst sollte erst einmal ein Datenbestand da sein.

Mein Vorschlag bezieht sich rein auf das Nebenthema, dass ein code repository nix abgeschlossenes ist, sondern etwas was mit der Zeit wächst.

Deshalb mache ich mir Gedanken dazu, wie die neuen/geänderten code Schnippsel möglichst komfortabel zwischen den Teilnehmern hin und hergeschickt werden können.

Das ist noch nicht mal kompliziert zu programmieren und kann später rangepflanscht werden.

[koehlerbv]

Bon, dann sind wir d'accord ;-)

Why there is no russian resturants in usa?
may be some ..who knows. But when compared to Chinese, Thai,Italian and Indian we can hardly find any russian resturants?
Because Americans have a habit to drive to Russian restaurants. And Russian restaurants make no sense without vodka!

Da kann ich Dir aus eigener Erfahrung - aber im Urspungsland - zustimmen. Ich hoffe, kommendes Jahr mal wieder auf (private Einladung, das andere bringt ja nix) wieder hinzufahren / fliegen ;-)
Leider geht mein Lieblingsziel Abchasien aus bekannten Gründen momentan absolut nicht. Hätte ich mir nie träumen lassen, als ich 1978 das erste mal dort war, dass dort überhaupt ein Bürgerkrieg möglich wäre ... Das ist sowas von traurig !

Bernhard

[TMC]

OK, hab mal das bisherige Brainstorming visuell dargestellt (see attached gif)

TMC

[TMC]

Die Grafik noch im Mindmanager-Format angehängt.

Wer es bearbeiten will, braucht aber den Mindmanager von http://www.mindjet.de

TMC

[Axel Janssen temp]

oh. oh. oh. Was habe ich da angerichtet  

Ich habe zur Zeit 3 Projekte.
Sollen wir nicht erst mal einen einfachen Prototypen in Notes entwickeln?

Mir ist wichtig:
- aller code wird in Dokumenten abgespeichert
- es gibt eine flexible Kategorisierung.
a) eine Kategorie kann mehrere hierarchische Unterkategorien enthalten:
(Office-Integration\excel oder String)
ein Dokument kann verschiedenen Kategorien zugeordnet werden.
- Kollaborationsfeatures werden später umgesetzt.

Wie es jetzt aussieht, kann ich mich mit der Sache erst wirklich frühestens in der 2. Dezemberhälfte beschäftigen.

Gruß Axel

[Axel Janssen temp]

...ansonsten eignet sich die Aufgabenstellung wie ich sie verstehe hervorragend, für ein mittleres Lernprojekt in Java.
Wenn sich also >= 2 Mitstreiter commiten, die e.r.n.s.t.h.a.f.t daran mitarbeiten wollen, dann könnte ich den Entwicklungsprozeß kollektivieren.

Ich hab da auch heute auf der Fahrt zur Arbeit drüber nachgedacht. Das dürfte machbar sein.

[TMC]

Hi,

nun ist das erste Brainstorming gelaufen, jetzt denke ich ist es an der Zeit dass wir mal loslegen, sonst wird es nie was  

Es wurde ja vermehrt festgestellt, dass wir uns vor der eigentlichen Erstellung der Scripts Gedanken über den Aufbau etc. machen müssen der Scripts.

Nochmal zusammengefasst:
- Errorhandling
- Funktionsbezüge
- Test(verfahren) inkl. Protokoll
- Abhängigkeiten
- Art der Einbindung (komplette Lib oder einzelne Routinen)
- Einheitliches Coding
- Einheitliches Dokumentieren
- Trennung Frontend/Backend - Routinen
- Einheitlicher Aufbau

Wenn ich diese Liste so überfliege, stelle ich fest, dass man zu jedem Thema alleine bestimmt zig Postings machen könnte, bevor man auch nur ein einziges Script hat.

Daher erscheint mir nun die Gefahr, dass wir uns hier u.U. zutode diskutieren, ohne zu einem Ergebnis zu kommen.

Andererseits ist es m.E. alles nicht zu tragisch, wenn man das ganze mal anders betrachtet.

Mal ein Vorschlag von mir:

Errorhandling:
Sollte im Semeaphoros-Thread abgedeckt werden

Art der Einbindung (komplette Lib oder einzelne Routinen)
Sollten wir uns überlegen, sobald mal ein paar Codes stehen
--> zurückstellen

- Funktionsbezüge
Sollten wir uns überlegen, sobald mal ein paar Codes stehen
--> zurückstellen

Abhängigkeiten
Sollte doch Teil der Dokumentation sein
--> verschieb zu Dokumention

Trennung Frontend/Backend - Routinen
Sollte auch Teil der Doku sein bzw. dann in der Plattform ersichtlich, was es betrifft.
--> erst auch mal zurückgestellt, wird nachgezogen

Rest:
- Einheitliches Coding
- Einheitliches Dokumentieren
- Einheitlicher Aufbau
- Test(verfahren) inkl. Protokoll

Zum Rest: Jetzt schlage ich wirklich vor, wir picken uns eine Problemstellung raus, und starten mit dieser.

TMC

[Axel_Janssen]

Rest:
- Einheitliches Coding
- Einheitliches Dokumentieren
- Einheitlicher Aufbau
- Test(verfahren) inkl. Protokoll

Erstmal grundsätzlich und werde noch heute konkreter.
Modernes Projektmanagement (Agile movement, Rational Unified Process, xTreme Programming) geht davon aus, dass die Effektivität von detaillierter Planung im Projektvorfeld in der Vergangenheit deutlich überschätzt wurden.
Lassen wir uns also bei den "Einheitliches x" Punkten von der Vorstellung leiten, dass wir durch die Definition nicht jedes Problem aus der Welt schaffen können.
Schliesslich soll ja das Hinzufügen von Routinen Spaß machen und der Beitragende soll sich nicht durch einen bürokratischen Prozeß quälen.

Ein gewisser Rahmen kann natürlich einiges vereinfachen. Deshalb später ein paar konkreten Vorschläge.

Gruß Axel

[TMC]

Modernes Projektmanagement (Agile movement, Rational Unified Process, xTreme Programming) geht davon aus, dass die Effektivität von detaillierter Planung im Projektvorfeld in der Vergangenheit deutlich überschätzt wurden.

Ich bin da auch Deiner Meinung! Hast Du dazu 'ne Quelle?
Wo das andersrum schiefgelaufen ist, ist ja das Maut-System in Germany. Steht auch ein netter Artikel in der letzten c't. Hier war aber u.a. das Problem, dass ein Zeitdruck aufgebaut wurde, und der Anbieter u.a. nur deshalb den Zuschlag bekam, weil er das ganze schneller realisiert. Das Ergebnis davon sehen wir ja jetzt.

Wir haben hier ja definitiv die Sunglasses auf   Zeitdruck ist soweit nicht existent  
Trotzdem sollten wir mal starten, ist m.E. einfach völlig unproduktiv, dass Notes-Programmierer immer wieder das Rad neu erfinden und sich neue Routinen basteln bzw. bestehende anpassen.

TMC

[Axel_Janssen]

Ich bin da auch Deiner Meinung! Hast Du dazu 'ne Quelle?

http://www.wikiservice.at/dse/wiki.cgi?AgileSoftwareEntwicklung (Links)
Martin Fowler, Craig Larman, Kent Beck, Phillipe Kruchten, Alistair Cockburn.
http://www-140.ibm.com/developerworks/rational

+ Einheitliches Coding
- einheitliches Kommentar-Template zu Beginn jeder Funktion:
%rem
eindeutige_ID:(kann zum generieren ein kleines Java-Tool programmieren, das per Icon vom desktop gestartet wird)
Ersteller:<email>
categories:String-Handling, Validation
version:
datum:
ziel_kurz:
beschreibung:
bemerkung:
benutzt_folgende_funktionen:id_Funktion, id_Funktion
%end rem

- Sprechende Variablennamen mit "Typmarkierung" zu Anfang:
strName
varName
intName
docName
colName
sName
dbName

und in "camel-case", dh Gross und Kleinschreibung in Form eines Kamels:
strEmailOrganisation = "ttt@jupp.com"
Ich neige oft dazu Variablennamen extrem auszuschreiben. Vermutlich ist strEmailOrg leichter lesbar. Ich weiss es nicht.
Ich bin ein grosser Freund rein englischer Variablennamen (docEmployee statt docAngestellter).  
Notes-Objekte die sich im Scope des Aufrufers befinden immer mit This.
Eine Funktion, die hauptsächlich aus einem Notes-Dokument heraus aufgerufen wird (querySave, Button) hat so:  docThis (Dokument, aus dem code aufgerufen wurde), sThis (User-Session), dbThis (Datenbank, in der sich der code befindet).
(hoffe das ist verständlich).

Ich finde, man sollte hier aber nicht päpstlicher als der Pabst sein.
Ein sehr einflussreiches Buch der OO/Agile-Bewegung (Fowler, Refactoring) sagt imnsho sehr richtig, dass man schlechten code sowieso als solchen erkennt und die Formalia nicht sooo wichtig sind (bad code smells).

+ einheitliches Dokumentieren
Dafür sind Kommentarzeilen da.


+ Einheitlicher Aufbau
Alle Dim statements zu Beginn.
Einheitliches Errorhandling
Ansonsten ist dieses wichtige Anliegen schwer in wenigen Worten zu formalisieren.
Z.B. sollten komplexe Funktionen in Unterroutinen aufgeteilt werden, die kohäsive (d.h. klar abgegrenzte nicht zu viele Aufgaben/Verantwortungen übernehmen).

- Test(verfahren) inkl. Protokoll
Mir nicht ganz klar, wie das gemeint ist.
Der Ideengeber mag es mir Verzeihen, aber das riecht für mich ein bischen nach Formalismus.
Das hängt auch mit dem eigentlichen Ziel zusammen und da mag den Beteiligten unterschiedliches Vorschweben.
Was mich anbetrifft, soll es eine Sammlung an feingranularen, kohäsiven Funktionen werden (deutsch: kleine Funktionen).
Beispiel: Alle Arbeitstage zwischen Tag_x und Tag_y ausrechnen als eigenes Code-Dokument und nicht die Suche nach der endgültigen allumfassenden Skript-Bibliothek für Datumshandling.
Feingranulare Funktionen erfüllen klar definierte Aufgaben und sind somit ohne viel Formalismus vom Ersteller zu testen.

Gruß Axel

[TMC]

sind doch schon mal  coole Vorschläge von Axel !!

Bin zwar etwas abgelenkt, weil ich mir grad die 'The Chemical Brothers' Singles 93-03 in voller Lautstärke reindröhne, aber das inspiriert ungemein :-)
Die Nachbarn haben sich auch noch nicht beschwert....

Beim Code-Header hätte ich den Vorschlag, dass das die Plattform automatisch übernimmt (wir haben da ja eh die Felder 'Ersteller', 'Erstellt am', etc.).

Ansonsten finde ich auch, dass wir englische Bezeichnungen nehmen sollten. Jeder Coder kann englisch (wenn wer nicht: mein Beileid).

Thanks Axel, gute Vorgaben.

TMC

[Semeaphoros]

Axel hat da wirklich gute Vorschläge, danke.

Bad code smells:

Stimmt, und kommentierter schlechter Code "still smells", läuft auf einer sprachlichen Ebene: wer unlesbaren Code schreibt, kann auch nicht deutlich kommentieren, ein inhärenter Zusammenhang (Axel möge das übersetzen, er hat ja Uebung darin ..... :-)

[koehlerbv]

Jo, TMC, anfangen sollten wir jetzt mal. Und dann das Ergebnis besprechen. Und das Ganze im ersten Anlauf vielleicht mal off-list: Du verteilst an die Bereitwilligen (die vielleicht schon Routinen angeboten haben) Aufgaben, sammelst und verteilst diese. Dann besprechen wir die Ergebnisse, die Testszenarien etc.

Was den Header angeht: Wir haben hier Standards (leider zwei - 'ne kleine und 'ne grosse Variante). Die würde ich gerne zur DIskussion stellen, würde mir ja selbst sehr helfen (das wird dann die dritte und endgültige Variante).
Was die Coding Standards angeht: In wirklich internationaler Zusammenarbeit hat sich bei uns die Budapester Notation (die wohl ursprünglich aus der C++-Ecke stammt) echt bewährt. Sag an, wenn ich das mal Notes- und Forums-gemäss aufbereiten und posten soll.

Und nun los (nach der Nachtruhe ;-)

Bernhard

PS: Wegen "Zudröhnen" - ich höre gerade (nachbarfreundlich über Kopfhörer) meine Neuerwerbung: "Deep Purple live at K.B. Hallen, Kopenhagen 1972". Da müssen fast alle Youngsters aber noch verdammt viel lernen ... Aus einem 4:17 min Studio-Titel fast eine halbe Stunde zu improvisieren, ohne dass die ganze Sache aus dem Ruder gerät, sondern vielmehr zu *dem* "Space Truckin' - da gibt es bis heute nicht viele Teams, die das können ... Da können wir auch von lernen, auich wenn das hier im Forum ja schon fast perfekt funktioniert (siehe den CRM-Thread heute ;-)

PPS: "Deep Purple live at K.B. Hallen" ist natürlich legal erworben und nicht das berühmte Bootleg ;-)  Das Geld war's mir wert !

PPPS: Für sieben Freunde darf ich's brennen laut deutschem Urheberrecht ... Bis jetzt habe ich noch keine Kopie gemacht ;-)

[TMC]

Was die Coding Standards angeht: In wirklich internationaler Zusammenarbeit hat sich bei uns die Budapester Notation (die wohl ursprünglich aus der C++-Ecke stammt) echt bewährt. Sag an, wenn ich das mal Notes- und Forums-gemäss aufbereiten und posten soll.

Bitte gerne. Die heißt übrigens "Hungarian Notation".
Ein paar Links:
http://www.gregleg.com/oldHome/hungarian.html
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsgen/html/hunganotat.asp
http://www.it-academy.cc/content/article_browse.php?ID=995
http://www.uni-koblenz.de/~daniel/Namenskonventionen.html
http://support.microsoft.com/support/kb/articles/Q110/2/64.asp
http://www.qucis.queensu.ca/Software-Engineering/archive/hungarian
http://cm-solutions.com/cms/technical/guide/hungarian_naming_convention.htm

Aufs Original von Charles Simonyi kommt man leider nur über archive.org, die Seite ist aber z.Zt. wohl nicht verfügbar oder überlastet: http://web.archive.org/web/20001018073323/www.strangecreations.com/library/c/naming.txt

TMC

[eknori]

da bin ich ja mal auf die ersten konkreten Ergebnisse gespannt...

wenn "damals" so  theoretisiert worden wäre ( ich hasse Konjunktive ), dann würden wir heute noch an der Konsole arbeiten.

[Axel_Janssen]

wenn "damals" so  theoretisiert worden wäre ( ich hasse Konjunktive ), dann würden wir heute noch an der Konsole arbeiten.

Damals brach wurde ja auch irgendwann abgebrochen.

Sollten wir uns auf Java als Interface einigen, kann ich den Theorie-Granatwerfer erst richtig einschalten.  
Bei meiner derzeitigen Arbeits/Zertifizierungs-Belastung rechne ich mit einem konkreten Ergebnis nicht vor 2004 (sehr am Anfang).

Der code ist doch eigentlich schon da (code-bin von ntftools, searchDomino.com)
Wir müssen den einfach nur in eine vernünftige kollaborative Form mit einem wirklich guten User Interface bringen.  

Gruß Axel,

der absolut davon überzeugt ist, dass "Programmierung" immer weniger aus tippen besteht und immer mehr aus dem, was Herr Krause "theoretisieren" bezeichnet. Nur aufpassen, das richtig theoretisiert wird.  

[Axel_Janssen]

halte ungarische Notation nicht für sinnvoll.

Sie erscheint mir sehr C bezogen. Es stimmt einfach nicht, dass sie in für allemöglichen Programmierstandard der Standard ist. Java hat z.B. seinen eigenen Standard, der praktisch nix mit der ungarischen Notation zu tun hat. Z.b. ist da der Datentyp explizit nicht Teil des Variablennamens.

Man schaue sich einfach mal diese Datentypen-Kürzel an:
http://www.uni-koblenz.de/~daniel/Namenskonventionen.html#Pr%E4fixe

Die Datentypen gibt es überhaupt nicht in LotusScript.

Deshalb mein Vorschlag: Eigener Namensstandard.
Welche Informationen brauchen wir:
1. Datentyp: Wie wäre es für jeden Datentyp einen relativ deskriptiven 3-Buschstabenkürzel zu nehmen:
int, lng, dob, var, str, etc.
Gut an der ungarischen Notation finde ich die explizite Kennzeichnung von globalen Variablen durch ein vorgestelltes g_
Der Rest der Namen wäre dann deskriptiv für die Funktion der Variablen. BeispielName:
g_dobSumme
Also eine globale double-Variable double, die eine Summe enthält.

Gruß Axel

[koehlerbv]

Die ungarische Notation war bei uns nur der Aufhänger, um Konventionen für Notes zu entwickeln.

Ohne Anspruch auf Vollständigkeit und "That's it!" hier ein schneller Auszug:
i               Integer
l               Long
sng          Single
dft            Double
crr            Currency
sz            String
v              Variant
a              Array
lst             List


b   Boolean      In Wirklichkeit Integer - nur genutzt für "True" und "False"
t   Type      Dim tPersonRecord as PersonRecord
C   Class
m_   Member variable   (of a class)
g_   Global variable prefix


ws   NotesUIWorkspace
uidoc   NotesUIDocument
session   NotesSession
dbd    NotesDbDirectory
db   NotesDatabase
log   NotesLog
dt   NotesDateTime
nl   NotesNewsLetter
dc   NotesDocumentCollection
doc   NotesDocument
view   NotesView
viewcol   NotesViewColumn
agent   NotesAgent
acl   NotesACL
acle   NotesACLEntry
itm   NotesItem
name   NotesName
rti   NotesRichTextItem
eo   NotesEmbeddedObject
dt   NotesDateTime

Nur so als Vorschlag. Ich passe mich da auch gerne an ;-)

Bernhard

PS: Den Versuch einer Ausrichtung der Liste gebe ich auf - das dauert mir jetzt zu lange, Tabs zu ersetzen ...