Thursday, August 22 2013 9:09 AM

Artikel zu "Meteor" im t3n-Magazin

Author: matthias - Last modified: Thursday, August 22 2013 9:11 AM

de meteor article  t3n  javascript

Vor einiger Zeit kam Print-Redaktionsleiter Luca Caracciolo vom t3n-Magazin auf mich zu und frug mich, ob ich Lust hätte, einen Artikel zum JS-Framework Meteor zu schreiben.

Da ich mich bis dato mit dem Framework auseinandersetze, gerne schreibe und JavaScript sowieso immer mehr ins Zentrum meines Coding-Alltags rückt, erklärte ich mich gerne bereit. Der Artikel erscheint am 27. August im gedruckten t3n-Magazin Nr. 33.

Als Vorgeschmack auf das Magazin ist der Artikel aber auch bereits online in voller Länge verfügbar: Einblick in die Full-Stack-JavaScript-Plattform für das Echtzeit-Web .

Der Beitrag versteht sich als Einführung, Überblick und Wegweiser zur technologischen Einordnung und richtet sich somit an ein breites Publikum von allgemein Technologie-Interessierten - ähnlich wie mein erster Blog-Artikel zu Meteor aus dem Herbst letzten Jahres.

Viel Spaß beim Lesen!

Comment / Share »
Thursday, October 25 2012 4:46 PM

Meteor resource loading: Eliminate cluttered js and css code

Author: matthias - Last modified: Thursday, November 1 2012 11:40 AM

en meteor twitter-bootstrap  responsiveness  smart-packages  css

Today I stumbled upon an interesting question asked on stackoverflow related to a problem with Twitter Bootstrap and how to solve it in Meteor.

Since Meteor loads a lot of resources "under the hood" one might ask how to manipulate e.g. css styles with inline style definitions after loading x.css but before loading y.css and so on (these things we all like to do as a quick solution, right?).

When writing Meteor apps you won't even get in touch with defining <link> or <script> tags and instead see some magically rendered code within your application HTML looking something like:

<link rel="stylesheet" href="/packages/bootstrap/css/bootstrap.css">
<link rel="stylesheet" href="/packages/bootstrap/css/bootstrap-responsive.css">
<link rel="stylesheet" href="/packages/bootstrap/css/bootstrap-override.css">
<link rel="stylesheet" href="/client/bootstrap-user.css"> 

Same with the following JS resources. End. That's your app. Nice.

The question specifically refers to a problem where body margins are "hacked" between the loading of bootstrap.css and bootstrap_responsive.css. That way, that the margins don't apply in certain media device dependent screen width sizes. How to hack this in Meteor?

I found the question interesting enough to figure out some solutions plus gathering some basic thoughts on this problem and on the Meteor way ignoring (or better: dealing with) it. I posted a quite too long answer and came to the conclusion that Meteor helps us writing cleaner code.

Meteor states in its' documentation that applications should be written such a way that it is insensitive to the order in which files are loaded (see Meteor documentation) . While this is (ideally) a good paradigm for designing and loading javascript modules and dependencies, it raises questions on how to do-it-best when defining user styles on top of a foundation like bootstrap.

In fact order matters when it comes to css in that way that specific styles should override default styles. With smart packages like Meteors bootstrap package the loading order of bootstrap.css and bootstrap_responsive.css directly one after another is fixedly defined. Thus said, putting something between it "on-the-fly" is impossible.

Recommended solution: Override on top of boostrap/responsive:

In my opinion best practice is do define and load user styles that way that they work like desired when loading after all of the foundation files. An example:

bootstrap-user.css:

@media (min-width: 980px) {
  body {
    padding-top: 60px;
    padding-bottom: 40px;
  }
}

When putting this into one of the user css files everything should be fine. User css files in the Meteor project root are always loaded after smart package files like those linked by the bootstrap package.

Well, here's the "inter-style" approach

If one nevertheless wants to hack it in that way like described in this answer (and even twitter itself suggests) you can go and write your own smart package:

package.js:

Package.describe({
  summary: "UX/UI framework from Twitter - My way"
});

Package.on_use(function (api) {
  api.add_files('css/bootstrap.css', 'client');
  api.add_files('css/bootstrap-pre-responsive.css', 'client');
  api.add_files('css/bootstrap-responsive.css', 'client');
  ...
  // More resource definitions like glyphicons-halflings go here
  ...
}

While the package file css/bootstrap-pre-responsive.css contains:

body {
  padding-top: 60px;
  padding-bottom: 40px;
}

Alternatively one can skip using a smart package for bootstrap integration and instead let just let Meteor collect and load the project resources - the conventions for loading order within your project root is described within the concepts section of the Meteor doc. But: This would mean naming files in an alphabetical way that reflects desired order! (not very elegant)

However, I personally don't like the way of solving the problem like described the latter way.

Last but not least: Of course it's sometimes the best way to build and compile an own boostrap variant with all desired styles minified to one file.

Comment / Share »
Monday, October 8 2012 11:22 PM

Meteor Web Plattform: Echtzeit ab Werk

Author: matthias - Last modified: Wednesday, December 23 2015 12:02 AM

de meteor nodejs  javascript  platform  framework  realtime  startup

Seit einigen Monaten verfolge ich neugierig das Treiben der Meteor Development Group und die Fortschritte ihres quelloffenen Kernprojekts Meteor. Meteor ist eine konsequent auf JavaScript und node aufsetzende Web Application Platform. In diesem Post werde ich einen kleinen Überblick über die Hintergründe geben und ein paar Paradigmen anhand eines Beispiels erläutern.

Wer? Eine Handvoll Jungs aus Kalifornien. Mal wieder.

Das kleine ambitionierte Startup aus San Francisco hat sich mit ihrem Projekt nicht Geringeres auf die Fahne geschrieben, als einen gehörigen Anteil am Transformationsprozess und an den Basistechnologien der in den kommenden Jahren weiter massiv an Bedeutung gewinnenden Web-Applikationen bestreiten zu wollen. Wie im Valley bzw. der Bay Area bei solch vielversprechenden Ansätzen nicht unüblich, sind die Jungs (Geeks, Nerds) im Sommer 2012 von verschiedenen Investoren mit einer anständigen Summe an Kapital ausgestattet worden, so dass sie sich zumindest um die mittelfristige Weiterverfolgung ihrer Vision keine Sorgen zu machen brauchen.

Warum ich ausgerechnet bei Meteor genauer hinschaue

Meteor ist im Anfangsstadium, die API ändert sich noch häufig - allzu viel lässt sich über die Zukunft wirklich nicht voraussagen. Aber mir gefällt das "Mission statement" und die Vision der Gründer (ich mag Visionen und gehe deswegen nicht zum Arzt!). Sie liesse sich etwas flappsig in etwa wie folgt sinngemäss zusammenfassen:

Entwickle Web-Anwendungen extrem schnell und einfach, entwickle Back- und Frontend in einer einzigen Sprache, entwickle mit Leichtigkeit Echtzeitanwendungen und integriere Deine Lösung in andere Systeme und umgekehrt - tue dies alles im vollsten Vertrauen, dass Deine Anwendung jederzeit für eine beliebig große Anwenderzahl verfügbar ist, natürlich bei Traum-Antwortzeiten. Kümmere Dich nicht um Hardware oder etwaige Administrationsaufgaben wie ödes Tuning von SQL-Datenbanken!

Also genau das, wovon jeder Web-Entwickler schon lange träumt! Nun, vielleicht ist es an der Zeit, erstmal ein praktisches Beispiel zu betrachten.

Für die Hacker/Ungeduldigen: Das Beispiel "Leaderboard"

Zur Installation von Meteor inkl. aller Abhängigkeiten und Erstellung des Beispielprojekts "leaderboard" braucht man ein anständiges Betriebssystem, eine Shell und eine Prise Neugierde sowie Vertrauen:

$ (sudo) curl https://install.meteor.com | sh
$ meteor create --example leaderboard
$ cd leaderboard
$ meteor

Der Aufruf $ meteor startet die Anwendung lokal auf Port 3000. Öffnet man diese Anwendung nun in zwei unterschiedlichen Browserfenstern (http://localhost:3000), stellt diese nebeneinander und vergibt ein paar Punkte hier und da, sollte sich das Aha!-Erlebnis schnell einstellen.

Ein Deployment in der Meteor-Cloud ist auch gleich vorgesehen:

$ meteor deploy [my-fancy-leaderboard].meteor.com

Wobei [my-fancy-leaderboard] selbstverständlich durch einen individuellen Namen ersetzt werden sollte, den möglichst noch kein Zweiter benutzt. Hier residiert gerade (m)eine Standard-Installation des Leaderboard-Beispiels: http://ml-leaderboard.meteor.com/.

Ein paar Paradigmen und ein kurzer Blick unter die Haube

JS and Database Everywhere

Das Leaderboard-Beispiel besteht aus drei Dateien, welche die eigentliche Anwendung beschreiben: 47 Zeilen JavaScript, 35 Zeilen HTML (mit Handlebars-Templates) und 62 Zeilen CSS - unkomprimiert und mit Kommentaren. Ein Blick in die Datei leaderboard.js:

if (Meteor.is_client) {
  Template.leaderboard.players = function () {
    return Players.find({}, {sort: {score: -1, name: 1}});
  };
  ...
}
...
if (Meteor.is_server) {
  Meteor.startup(function () {
    if (Players.find().count() === 0) {
      var names = ["Ada Lovelace", "Grace Hopper", "Marie Curie",  ... ];
      for (var i = 0; i < names.length; i++)
        Players.insert({name: names[i], score: Math.floor(Math.random()*10)*5});
    }
  });
}

Die Prüfungen is_client sowie ìs_server lassen ein wesentliches Merkmal von Meteor erahnen: Nämlich die Grundannahme, dass wesentliche Objekte sinnvollerweise auf dem Server und im Client verfügbar gemacht werden sollten. Bemüht man im Browser die JavaScript-Console z.B. derart:

> Players;

so bekommt man ohne Umwege ein Objekt vom Typ Meteor.Collection zurückgeliefert, welches die Dokumente der Collection Players in der standardmässig verfügbaren MongoDB-Datenbank repräsentiert. Dies lässt schon so manches Programmiererherz höher schlagen.

Viele Entwickler werden bestätigen, dass es reichlich gute Gründe gibt, bestimmte Objekte und Funktionalität manchmal besser im Browser, machmal besser auf dem Server und oft am liebsten auf beiden Seiten verfügbar zu machen. Da wir hier ausschliesslich in JavaScript programmieren, ist der gewählte Ansatz naheliegend. Kein redundanter JS-Code muss extra geschrieben oder mittels irgendwelcher Compiler für den Browser erzeugt werden.

Data on the Wire, Realtime as default

Dies passt nun auch nahtlos zum von Meteor propagierten Prinzip Data on the Wire, nach welchem der Client niemals "fertig gerendertes" HTML erhalten soll, sondern lediglich die Nutzdaten selbst vom Sever übermittelt bekommt. HTML existiert in Form von Templates - natürlich bzw. gerade auch auf Client-Seite. Diese werden beim Aufruf der (Single Page) Applikation geladen. Die von Meteor generierten Objekt-Prototypen hierzu kann man sich wieder über die JS-Console anschauen:

> Template;

Nun kombiniere man dies mit dem nächsten Paradigma Realtime as Default und der Tatsache, dass Meteor standardmässig Web-Sockets bereithält. Das Ereignis "Veränderung in der Datenbank" könnte somit sofort und ohne Umwege in der View bzw. im View-Modell des Clients durchschlagen. Wer mag, gibt "Grace Hopper" der Players-Collection also mal satte 150 Punkte zusätzlich. Ach so, natürlich wieder direkt mittels der JS-Console des Browsers.

> Players.update(Players.findOne({name: 'Grace Hopper'}), {$inc: {score: 150}});  

Bang!

Es sind noch nicht alle Paradigmen wie z.B. die Latency Compensation erwähnt, aber als erster Überblick sollte es an dieser Stelle ausreichend sein.

Ein kleines Fazit. Bis hierher.

Allgemein betrachtet: Bei einer weiterhin kontinuierlich wachsenden Menge an Daten sowie ständig neuen Anforderungen an deren kurzfristige Evaluation, Aggregation, Integration in andere Dienste und Bereitstellung für sich dynamisch verändernde Nutzergruppen wird es technologische Antworten wie Meteor geben müssen. Und diese, so viel steht schon jetzt fest, müssen auf jeden Fall eine extrem agile und modulare Entwicklungsweise sowie eine unproblematische Bereitstellung in hochverfügbaren Cloud-Infrastrukturen ermöglichen. Das Ganze bei überschaubaren Kosten, versteht sich.

Ein spezifisches Projekt wie Meteor, das seine Einfachheit und Mächtigkeit mit Trommelwirbel propagiert (wie seinerzeit vielleicht Rails) und in Wirklichkeit erst in den Anfängen und jenseits der Produktionsreife steckt, muss nicht zwingend eine große Zukunft besitzen. Gleichwohl traue ich den Köpfen dahinter weit mehr als einen Achtungserfolg zu. Meteor ist mindestens ein wichtiger Trendindikator für die Frage nach dem "Quo vadis, Web?". Das Projekt zeigt schon in diesem frühen Stadium einen sehr eleganten Weg für die Entwicklung und Bereitstellung moderner Applikationen, die auf Web-Standards basieren und Echtzeit- sowie Kollaborations-Anforderungen von Haus aus bedienen.

Ich schaue jedenfalls weiterhin gespannt auf die Entwicklung dieses Projekts!

Anmerkung: An dieser Stelle sollte ich noch betonen, dass ich keine Diskussion um z.B. unternehmenskritische Prozesse, Datenintegrität und Transaktionssicherheit in sensiblen Systemumgebungen einbringen möchte. Das ist eine andere Betrachtungsweise und hier beschränke ich mich zunächst auf die Anwendungsfälle der "agilen Web-Applikationen für jedermann".

Comment / Share »