Entwicklungsinfrastruktur: Build-System, Lint, Dokumentation, Minifier

[Chris M.]

Da der Code ja inzwischen eine gewisse Komplexität erreicht hat, macht es IMHO Sinn das ganze Thema Entwicklungsinfrastruktur an zu gehen.

Aktuell hätte ich geplant:

• Make als Build-System
• JSLint für'n Lint
• YUI Doc für automatische Code-Doku
• UglifyJS als Minifier

Auch wenn es hier sicher viele verschiedene persönliche Präferenzen gibt, muss hier IMHO das Ziel sein mit minimalen zusätzlichen Dependencies ein gutes Ergebnis zu bekommen.


Da ich selber kaum welche dieser Tools eingesetzt habe und folglich kaum Erfahrungswerte habe:
Gibt es Gegenvorschläge (mit Begründung...)?

[netzkind]

Von JSLint würde ich abraten: das Tool markiert nach meinem Wissen verdammt viele Dinge an die mehr den Coding-Style betreffen als die Code-Korrektheit. Wir nutzen es auf der Arbeit nurnoch in der Form dass aus der Ausgabe nur bekannte Problemfälle rauspicken und sonst 96% der Ausgabe wegwerfen.

Uglifyjs kenne ich nicht. Ich hätte spontan eines der mir bekannten, viel genutzten und deshalb Fehler-armen (?) Tools zu nutzen: YUI-compressor oder Googles Closure Compiler.

Zu make und YUI Doc hab ich keine Produkt-Meinung.

Inline-Doku zu HTML zu kompilieren halte ich persönlich eh für Quatsch wenn man nicht grade eine öffentliche API erzeugt - da die CometVisu keine public api ist die man wie eine Blackbox von außen auf Codeebene aufruft spielt das keine Rolle. Gute Inline-Doku ist trotzdem wichtig, und wenn YUI Doc die gleiche Syntax hat wie phpdoc, javadoc etc., dann ab dafür!

Grüße,
Julian

[Chris M.]

Von JSLint würde ich abraten: das Tool markiert nach meinem Wissen verdammt viele Dinge an die mehr den Coding-Style betreffen als die Code-Korrektheit.

Stimmt, hab auch so was gelesen. JSHint scheint da der "Nachfolger" zu sein (genauer: der Fork von ein paar Leuten die von der JSLint-Politik angepisst waren...)

Uglifyjs kenne ich nicht. Ich hätte spontan eines der mir bekannten, viel genutzten und deshalb Fehler-armen (?) Tools zu nutzen: YUI-compressor oder Googles Closure Compiler.

Ich hab halt geschaut was z.B. jQ benutzt...

Inline-Doku zu HTML zu kompilieren halte ich persönlich eh für Quatsch wenn man nicht grade eine öffentliche API erzeugt - da die CometVisu keine public api ist die man wie eine Blackbox von außen auf Codeebene aufruft spielt das keine Rolle. Gute Inline-Doku ist trotzdem wichtig, und wenn YUI Doc die gleiche Syntax hat wie phpdoc, javadoc etc., dann ab dafür!

Syntax dürfte hoffentlich gleich oder zumindest sehr ähnlich sein: YUI Doc

Öffentliche API haben wir beim CometVisu-Client (und beim JSFloorPlan an dem ich ja gerade dran bin und der mir diesbezüglich mehr unter Nägeln brennt. Wenn ich den nur bis Weihnachten so weit bringen könnte, dass ich den in der CV einbinden kann...)
Für den Rest ist's in der Tat eher ein Weil-ich-kann (+ einheitlicher Doku-Stil) als ein Muss.

[makki]

[*]UglifyJS als Minifier

Keine Ahnung, aber ziemlich zu beginn der CV (also schon ne Weile her) hatte ich alles getestet (zumindest alles was nicht Java war..) und bin bei jsmin (uralt, ganz einfach&übersichtlich..) hängen geblieben: war das einzige, was unter keinen Umständen etwas kaputt machte.. Den Rest macht der lighty mit gzip - auch ohne Ärger

Makki

[2ndsky]

wir verwenden bei uns in einer Maven2 Build Umgebung ebenfalls YUI-compressor und lassen damit sogar die jQuery JS Files und andere komprimieren. Funktioniert problemlos!

[makki]

Release & Packaging

Nachdem ich da grade dransitze, möchte ich das mal aufwärmen: in Stichworten einige Dinge die man IMHO noch optimieren könnte/sollte.
Keine Kritik, mehr als Log - auch der eigenen Lernkurve - zu verstehen.

1) minify vor einem Release; ich denke im SVN sollte jeweils die non-minified Version liegen und verwendet werden, sonst bekommt man beim Debuggen die Krise aber im Release nur noch die minified-Version. Nicht wie jetzt beide oder ein MischMasch, verwirrt mich selbst teilw..
-> Vorschlag, um zwischen SVN & Release möglichst wenig ändern&testen zu müssen: Einbindung aller .js mit dem "nomalen Namen" ohne .min.js -> im Release enthält die *.js einfach die jew. minified-Version, dann muss man nur die austauschen, nicht in 20 anderen Files rumwurschteln (?)
(Script dafür mach ich gern, wenn man sich auf einen minifier einigt, mehr als jsmin traue ich mich nicht)

Momentan machte ich das händisch, ist nur a) Fehlerträchtig und b) z.B. beim Packaging für OpenWRT so nicht ohne weitere Verrenkungen möglich, ich würde das gerne soweit als möglich automatisieren..
(Die alternative wären Patches im Packaging, nicht wirklich schön!)

2) Benamsung:
- kein CamelCase in Releases, das ist bei eigentlich allem verpöhnt
- das Verzeichnis im release-File cometvisu-x.y.z.tar.gz sollte auch cometvisu-x.y.z heissen. Sonst fliegen einfach 20 Automatismen diverser Build-umgebungen auf die Nase..
- keine wilden Versionsnummern (ist ja nicht mehr, nur nochmal fürs Protokoll) w.x.y.z ist alles i.O solange die Rückwärts aufsteigend sind; -XX am Ende ist der Version des jeweiligen Package vorbehalten.
-RCx ist ok, solange daraus nie ein Paket wird, sonst fliegen sowohl dpkg als auch opkg uvm auf die Nase.

3) Makefile-basiert: wäre sicher gut & praktisch (um z.B. den minify zu machen) aber da kenne ich mich auch nur sehr oberflächlich aus..
Perfektioniert gibts dann ein ./configure --without-design=ABC --without-ttf
Ist aber vermutlich oversized, ausser es kennt sich jemand mit Makefiles aus und schreibt das "mal eben" runter, wär natürlich cool!

-> Nächster Schritt: wer kümmert sich um was fürs nächste Release? ich mach gern mit wenns um Shellscripts, (bisschen Makefile anpassen geht auch) usw. geht, das Packaging sowieso aber ich würde gerne davon einen gehörigen Teil auf "make dist-gzip" verschieben

Makki