GitHub Repository mit Travis CI Unterstützung

[Chris M.]

Wäre da nicht "WebStorm" die richtigere Wahl?

Aber ja, ich denke wir fallen da unter deren Bedingungen für eine kostenlose OSS Lizenz.

Da ich mit meiner Entwicklung in Kate nur bedingt zufrieden bin, hol mir auch mal eine Lizenz. Evtl. ist's ja besser. Und evtl. ist's endlich mal eine Java Anwendung die auf dem Desktop Sinn macht.

[peuter]

WebStorm ist da mit drin und PHPStorm auch, also alles was man braucht in einer IDE. WebStorm nutzen wir in der Firma und in Sachen Javascript IDE ist die schon ziemlich gut, ich habe da noch nichts besseres gefunden (was nicht heißt das alles perfekt ist).

Die kleineren Fehler habe ich geändert, mit der Versions-Geschichte ist das nicht so einfach. Aktuell steht in der Versions-Datei GIT (es gibt übrigens im Root-Verzeichnis noch eine Versionsdatei und in der steht noch SVN). Grunt benötigt eine Versionsnummer nach dem Semantic Versioning Prinzip (http://semver.org/). GIT oder SVN ist da nicht gültig, also müsste das sowieso geändert werden und dann kann man die Version doch zentral in der package.json halten oder nicht?

[Chris M.]

WebStorm ist da mit drin und PHPStorm auch, also alles was man braucht in einer IDE. .

Ah, ok. Dann passts ja

Hab mich auch gerade die 30 Tage Demo installiert und teste gerade Hab auch schon den vim Modus gefunden

Aktuell steht in der Versions-Datei GIT (es gibt übrigens im Root-Verzeichnis noch eine Versionsdatei und in der steht noch SVN). Grunt benötigt eine Versionsnummer nach dem Semantic Versioning Prinzip (http://semver.org/). GIT oder SVN ist da nicht gültig, also müsste das sowieso geändert werden und dann kann man die Version doch zentral in der package.json halten oder nicht?

Wo und wie wir das machen ist mir ziemlich egal - wichtig ist das Ergebnis. Und das muss sein:

• Nur eine (oder halt möglichst wenige) Stelle, um bei einem Release nichts zu vergessen. Auch nicht wenn das Release-Script geändert wird
• Das gilt auch wir Package-Ersteller (z.B. wenn aus dem cometvisu-1.2.3.zip jemand ein cometvisu.deb mit der Version "1.2.3-system4" bastelt)
• Der manager.php soll die Version anzeigen (-> hilft uns bei der Fehlersuche, oft weiß ein Anwender ja nicht, welche Version er hat)

[peuter]

So die version-Datei wird nun automatisch beim build geschrieben, ebenfalls wird die Version in der Demo-Config im release Ordner aktualisiert. Damit sollte die Konsistenz gewährleistet sein und keine weiteren Änderungen nötig sein.

[peuter]

Ich hatte zu jeder JS Datei eine minimierte gesehen, aber nicht, dass alle in einer großen Datei zusammengefasst wurden. Evtl. hab ich's auch übersehen.
Aber da würde ich mir noch keinen Kopf machen. Wenn das Release naht, kann man hier an den Details feilen.

An sich habe ich die vorhandene build-Konfiguration für requirejs einfach übernommen, d.h. es wird nach wie vor alles in die templateengine.js geschrieben. Die einzige Änderung die ich gemacht habe ist, dass SourceMaps generiert werden (http://www.html5rocks.com/en/tutoria...ls/sourcemaps/) und ich denke dafür braucht er halt noch die originalen Dateien (mit Sourcemaps habe ich aber auch noch keine Erfahrung, finde ich nur sehr praktisch, weil erleichtert die Fehlersuche im Release doch ungemein, wenn man nicht im "uglifizierten" Code rumsuchen muss.

[peuter]

So ich habe noch ein wenig mit dem neuen Grunt-Build System herumgespielt und mal versucht das Haupt-Package im Release (also die Templateengine.js) so klein wie möglich zu bekommen. Hier gibt es 2 Hauptansatzpunkte:

1. Dadurch das es nun SourceMaps gibt und der Browser in den Entwicklertools den Originalen-Sourcecode (mit Lizenzheader) anzeigt, beim eigentlichen Laden aber nur den minifizierten Code nutzt, ist es meiner Meinung nach nicht nötig, dort auch noch Lizenzheader drin zu haben (hier kann ich mich aber auch täuschen, hab mich da nicht schlau gemacht wie es rechtlich korrekt gemacht werden muss, das ist jetzt nur eine persönliche Einschätzung).

2. Jquery-UI unterstützt requirejs und soweit ich da sehe nutzt die CometVisu nur den Slider und indirekt über jquery-ui.touch-punch.js widget und mouse. Daher habe ich die Sourcen von Jquery-UI einzeln eingebunden hab die nötigen Abhängigkeiten eingetragen und lasse Requirejs dann nur das einbinden was benötigt wird.

Das Endergebnis kann sich sehen lassen, wobei ich hier natürlich nicht sagen kann ob wirklich nichts fehlt. Hier mal ein Vergleich zwischen meiner aktuellen Produktiv Version und einem neu gebauten Release, die beide die Demo-Config laden:

Produktiv:
orig.png

Neues Release:
grunt-release.png

Scheint eigentlich ein wenig zu gut um wahr zu sein, also habe ich vermutlich wirklich was vergessen, aber beim kurzen durchklicken hat erstmal alles funktioniert.

[Chris M.]

Sehr interessant. Wobei auch noch spannend ist, die Größe zu betrachten nachdem diese Dateien durch gzip geschickt wurden, denn das ist das, was real übertragen werden sollte (richtig konfigurierter Web-Server vorausgesetzt)

[peuter]

Jetzt wo Du es sagst fällt mir ein das der Vergleich oben doch ziemlich unfair war. Mein Produktiv-System läuft (wegen openHAB) auf Jetty-Webserver und der gzipped nicht automatisch. Das Testsystem auf Apache und der macht das. Habe das schnell mal oben korrigiert. Ist immer noch ein deutlicher Größenunterschied zu erkennen, aber jetzt ist der auch realistisch (143 vs. 79 kb). Beides also automatisch gzipped.

[Chris M.]

Hab gerade mal einfach "grunt" drüber laufen lassen. Dabei ist mir ein Bug aufgefallen:
Es werden nun in den Dateien oben neue Lizenz-Kommentare eingefügt - der alte dabei aber nicht entfernt. D.h. die werden verdoppelt...

-> Lässt sich das optimieren?

[peuter]

Leider muss man die alten einmalig manuell entfernen (der Task sucht nach einen Header mit ausgeschriebenem copyright, was die alten nicht haben). Ab dann wird korrekt aktualisiert und es gibt keine doppelten Header mehr.

[Chris M.]

Und noch was: kann / könnte ich per Komandozeile den Namen des Releases vorgeben (also, dass es den Inhalt der version-Datei überschreibt und den Namen der Release-Zip entsprechend wählt)?

[peuter]

Und noch was: kann / könnte ich per Komandozeile den Namen des Releases vorgeben

Das müsste ich erstmal checken. Es gibt release Tasks denen man sagen kann New minor/major release und dementsprechend ändert der die Version. Direkt per Kommandozeile gibt's bestimmt irgendwie auch einen Weg. Die Zentrale Stelle die geändert werden muss ist in der package.json da gibt's den Version Eintrag, wenn Du den manuell anpasst ändert sich alles andere Automatisch (Version Datei, Dateinamen der zips, Versionshinweis in der Demo-Config im Release Ordner.

[peuter]

Ich habe die Version jetzt mal manuell auf 0.9.1-RC1 geändert, da es nur 1 Stelle gibt an der man das ändern muss, denke ich hier brauchen wir kein weiteren Automatismen, oder?

Außerdem habe ich den Task, der die Lizenz-Header in der Source-Dateien ändern erstmal rausgenommen. Wenn man das in Zukunft einmal richtig macht, sollten Informationen wie der Autor und das Erstellungsdatum da rausgeziogen werden und als normaler Source-Kommentar eingefügt werden (hat meiner Meinung nach nichts im Lizenzheader zu suchen. Dann z.B. in diesem Format:

/**
 * <Beschreibung der Datei>
 *
 * @author <Autor>     * @since <Erstellungsjahr>
*/

(Irgendwie formatiert das Forum das nicht richtig @author und @since sollen natürlich in eigene Zeilen).

Das ist hat eine einmalige Fleißarbeit, aber dann hat mans richtig.

Chris M.
In den Release-Archiven scheinen viele Dinge drin zu sein, die nicht Teil des Repositories sind (Div. Designs, Configs, ein theApp Ordner, der Icons-Order ist massiv größer als bei mir, usw.). Eventuell wäre ein cleaner checkout des Repos besser um ungewollte dreingaben im Release zu vermeiden.

[peuter]

Ok gibt wohl nichts was es nicht gibt in Grunt:

grunt bump:prepatch --dry-run
Running "bump:prepatch" (bump) task
Running grunt-bump in dry mode!
md 
>> bump-dry: Version bumped to 0.9.1-rc.0 (in package.json)
>> bump-dry: git commit  package.json -m "Release v0.9.1-rc.0"
>> bump-dry: git tag -a v0.9.1-rc.0 -m "Version 0.9.1-rc.0"
>> bump-dry: git push upstream release-0.9.1 && git push upstream v0.9.1-rc.0

Done, without errors.

Würde einem wohl ein wenig Arbeit annehmen. Sind das in etwa die Schritte, die Du bisher unternommen hast für das Pre-Release? Weitere Anwedungsbeispiele gibts hier: https://github.com/vojtajina/grunt-bump#usage-examples

Ich versuche mich gerade noch darin ein automatisches Changelog mit Grunt zu erstellen (klappt aber nicht, gibt auch keinen Fehler aus, daher bin ich da momentan etwas ratlos). Damit wären dann aber alle Schritte fürs Release beisammen, oder?

[peuter]

Das mit dem Changelog bekomme ich mit Grunt nicht hin, wenn es da bisher einen Automatismus gab, dann teilt mir den gerne mit, dann kann ich damit vielleicht noch was hinbekommen.