Schlagwort: Javascript

Kategorien
Code Webentwicklung

Do-It-Yourself oder intelligente Verzahnung – Wieviel Eigenleistung steckt in einem Software-Projekt?

Mauer - Stein auf Stein
Stein auf Stein – So ähnlich baut ein modernes Web-Projekt auf bestehenden Bibliotheken auf – oder?

Hintergrundinformation: Ich arbeite aktuell in der Firma an einem größeren Projekt, welches unter anderem die Entwicklung einer komplett JS-basierten Oberfläche zur Konfiguration und Abfrage von Maschinen und der Erstellung eines Angebots für Kunden enthält. Das Projekt läuft seit 8 (“initial commit”: 22. Juli)  Monaten und es arbeiten 2, stellenweise 3 Entwickler daran.

Ich habe mir mal den Spaß gemacht, nachzuschauen, wie viel Code da von unserer Firma drinsteckt:

Die Gesamtsumme aller “per Hand” bearbeiteten Daten beträgt knapp 600KB. Der Rest des Projekts setzt sich zusammen aus den benutzten Bibliotheken: cookie.js, Ember.js, Font Awesome, Handlebars, Holder.js, html5shiv, jQuery, jQuery Tools, jQuery UI, Normalize.css, spin.js, Underscore.js, Grunt

Insgesamt werden beim ersten Laden des Projekts im Browser 580 KB abgerufen, dazu kommen noch ca. 62,7 KB aus (bisher unkomprimierten) Dateien, die erst später Nachgeladen werden (können). Das schließt allerdings keine Abfrage von Daten, sondern nur den Payload des Projekts ein. HTML, JS, CSS/LESS, Bilder.

Ich schwanke meinungstechnisch noch zwischen: “Cool wie effizient” und “oh, das ist aber wenig” (Das Quantität keine Qualitätsaussage ist, ist mir dabei durchaus bewusst). Zum Glück werden wir nicht nach KB bezahlt. (Ausnahmen bestätigen die Regel aber meistens ist das dann eher eine Bezahlung pro gespartem KB)

Wie ist das bei euch? Wie viele Libraries haben eure großen Projekte? Ist das Verhältnis von eigenem vs. fremdem Code bei euch auch so ähnlich oder entwickelt ihr alles “from Scratch”? Sieht das bei “Backend”-Projekten ähnlich aus?

Bild: CC0 von Martin Wessely via Unsplash.com

Kategorien
Allgemein Werkzeuge

“Make Manager”: Massenbearbeitung für Redmine-Gruppen

Dieses Bookmarklet löst das Problem, wenn man eine neue Gruppe in Redmine einlädt und diese zu allen Projekten hinzufügen möchte.

javascript:$('#membership_project_id').val( $('#membership_project_id option:not(:disabled):last').val() ) && $('.splitcontentright [name="membership[role_ids][]"]:first').prop( 'checked', true ).change() &&  $('#tab-content-memberships .splitcontentright input[type=submit]').click();void 0

Das ganze als Bookmarklet anlegen und unter https://[redmine-url]/groups/[gruppenID]/edit?tab=memberships (Gruppe bearbeiten, in Tab “Projekte”) solange anklicken, bis eine Fehlermeldung kommt ;). Ggf. muss man bei dem “membership_role_ids_” noch den Selector anpassen, wenn man nicht die die oberste Rolle nehmen will.

Kategorien
Releases Webentwicklung Werkzeuge

Webeditor auf Basis von Webtechnologien: Brackets [Sprint 31]

Brackets Startscreen
Brackets Sprint 31

Adobe entwickelt Brackets, einen Webeditor, mit Webtechniken: Node.js, HTML und Javascript. Brackets ist Open Source und bietet aus meiner einen vielversprechenden Ansatz. Mit LESS und meinem Workflow kann das Teil allerdings auf den ersten Blick nicht das anfangen, was ich persönlich brauche, aber ich werde den Editor mal im Auge behalten…

wiederentdeckt durch Jens Grochtdreis

Kategorien
Webentwicklung

File-Based-CMS: Kirby vs. Stacey

Ich habe mich in der Vergangenheit mal ein bisschen mit so genannten “Static Web Page Generators” auseinandergesetzt, also Systeme wie Jekyll, Hyde, “Octopress” und vor allem Docpad. Docpad ist ja bei allen genannten mein Favorit. Es basiert auf Node.js und läuft auch unter Windows ohne große Mühen. Allerdings gibt es noch eine Zwischenlösung zwischen komplett statisch ausgelieferten Seiten und den “großen” Playern wie z.B. WordPress, TYPO3 und Joomla.

Dazwischen liegen ein paar kleine Perlen, die so genannten “file based CMS”. Dazu habe ich mal zwei der CMSe angeschaut: Kirby und Stacey. Wie ich auf Kirby gekommen bin weiß ich nicht mehr genau, vermutlich über einen Artikel bei Dr. Web Magazin.

Stacey habe ich dann über Kirby entdeckt. Während ein Bekannter von mir mit Kirby recht schnell Ergebnisse produziert hat, bin ich mit Stacey nur langsam warm geworden. Zuviele Fragen bleiben offen in der aktuellen Phase.

Daran kann man eines sehr gut erkennen: eine gefällige Präsentation und eine auf den ersten Blick sehr gute Dokumentation, die auch ohne große Hürden Rückfragen bietet, hilft Einsteigern und Interessierten, sehr schnell in die Materie hineinzukommen.

Im Gegensatz dazu ist Stacey eher spartanisch präsentiert und schreckt auf den ersten Blick ab. Die Ideen, die in dem CMS stecken sind aber durchaus gut, die Referenzenliste ist beeindruckend vielfältig.

Gemeinsamkeiten

Beide Systeme haben trotz aller äußerlichen Unterschiede den gleichen Ansatz und ein fast identisches Konzept: Nur soviel wie nötig. In der Standard-Ausführungen haben beide Systeme kein Frontend, das Bearbeiten der Dateien geschieht via FTP und Texteditoren. Kirby bietet hier auch noch eine Erweiterung, die das ganze auch teilweise in einem Webfrontend ermöglicht, aber eigentlich ist das nicht die Standard-Funktionalität.

Ausblick

Kirby hat eine bestehende Nutzerschaft und einen aktiven Entwickler, der sich über Production Lizenzen finanziert. Interessant wird, ob Kirby 2 einen ähnlichen Bruch produzieren wird, wie Stacey 3.0, das aktuell noch sehr unfertig ist. Kirby bietet aktuell mehr Möglichkeiten, das System “Endkundentauglicher” zu konfigurieren, unter anderem auch durch Dinge wie das Kontaktformular-Plugin.

Trotzdem werde ich beide Systeme für die Zukunft im Auge behalten.

Kategorien
Code Webentwicklung

Wie sollte man Prototypen bauen?

Konzept: Von der Skizze zum Prototypen

Wir gehen in diesem Artikel davon aus, dass für ein neues Projekt Skizzen bestehen, die zeigen, wie die fertige (Web-)Anwendung etwa aussehen und sich verhalten soll. Basierend auf diesen Skizzen möchte der Kunde sehen, wie sich das “anfühlt”, wenn man es im Browser bedient. Wir gehen im folgenden davon aus, dass der Prototyp keinerlei Datenverbindungen oder serverseitige Entwicklung benötigt, also ein reiner “Klick-Dummy” ist.

Grundüberlegungen

Bevor die erste Code-Zeile entsteht sollte man sich schon über einige Dinge Gedanken gemacht haben:

  1. Code-Organisation / Ordnerstrukturen
  2. Zu verwendende Libraries und deren Lizenzen

Was davon in der Entwicklung davon übrig bleibt, ist egal, aber ein Plan sollte vorhanden sein. Mit am wichtigsten ist, dass alle “Screens” auf Atomisierbarkeit gecheckt werden:

  • Habe ich oft gleiche Strukturen?
  • Kann ich die kombinieren?

Dabei sind z.B. Dinge wie immer wiederkehrende Dinge wie Tabellen mit gleichem Aufbau. Hier lohnt sich unter Umständen recht schnell der Einsatz einer Templating-Engine wie Handlebarsjs oder Mustache.

Weitere Dinge: Welche Präprozessoren / DRY-Tools benutze ich, z.B. LESS, SASS und/oder Ajax (um Teile der Oberfläche nachzuladen).

Umsetzung: Was sollte bei der Entwicklung des Prototypen beachtet werden?

[red_box]Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle![/red_box]

Man kann es gar nicht oft genug sagen. Jeder nachvollziehbare Schritt ist ein sinnvoller Schritt in die richtige Richtung. Insbesondere, wenn mehrere Personen am gleichen Code arbeiten, ist ein SCM-Tool richtig wichtig.

Der Code sollte dabei im Code selbst gut dokumentiert sein, zusätzliche Dokumentation in einem Wiki oder ähnlichem wäre optimal. Nutzt eine Toolchain wie Grunt.js um Produktionsreifen Code zu erzeugen:

  1. Minifying
  2. Compressing
  3. Entkommentarisierung 😉

Request-Lagging

Wenn im Klick-Dummy Requests simuliert werden, die im Prototyp nicht oder lokal stattfinden, verzögert Sie im Prototypen mit JavaScript-

Diskussion: quick’n’dirty vs. Produktionsreife

Wieviel produktionsreifen Code soll eurer Meinung ein Prototyp enthalten? Werdet euch mit den Kunden einig darüber, was ihr unter einem Prototyp versteht und was der Übergang vom Prototypen zur “live”-Version bedeutet. Je nachdem sollten natürlich auch unterschiedliche Aufwände in den Prototypen gesteckt werden.