Die Vorteile von Yarn

FAST, RELIABLE, AND SECURE DEPENDENCY MANAGEMENT.

Das ist der Leitspruch von Yarn, und daraus ergeben sich auch die wichtigsten Vorteile.

Schnell

Yarn ist schnell. Sogar sehr schnell. Das liegt an zwei Gründen:

1. Yarn speichert alle Packages, die heruntergeladen werden
2. Yarn führt mehrere Operationen gleichzeitig aus

Das bedeutet, wenn ich in einem Projekt zum Beispiel das das NPM Package “webpack” verwende, wird dieses auf meinem Computer gespeichert. Wenn ich nun ein neues Projekt starte, und dort ebenfalls wieder “webpack” verwende, wird das Package direkt von meiner Festplatte geladen und muss nicht erneut über das Internet aus dem Onlineverzeichnis heruntergeladen werden. Das ist einerseits schneller, und andererseits erhält man dadurch auch die Möglichkeit neue Projekte zu starten, ohne mit dem Internet verbunden sein zu müssen.

Zuverlässig

In einem normalen NPM-Projekt werden die Packages die verwendet werden in einer package.json Datei gespeichert. In dieser Datei wird für jedes Package angegeben, welche Version davon installiert ist beziehungsweise welche Version mindestens benötigt wird. Yarn geht hierbei noch einen Schritt weiter: Es wird nicht nur gespeichert, welche Version des verwendeten Packages benutzt wird, es speichert zudem auch alle Versionen der Dependencies dieses Packages in ein eigenes File namens yarn.lock. Gemeinsam mit dieser Information und einem eigenen Algorithmus für Installationen, garantiert Yarn so, dass ein Projekt das auf einem Computer lauft, auch auf jedem anderen Computer funktioniert.

Sicher

Yarn verwendet zudem Checksummen um die Intigrität von installierten Packages zu verifizieren bevor diese ausgeführt werden.

Installation

Nun da wir die wichtigsten Vorteile von Yarn kennen wird es Zeit Yarn zu installieren und zu verwenden. Und wie wird man Yarn wohl am einfachsten installieren? Richtig: über NPM!
Also ganz einfach, wie gewohnt: npm install -g yarn ausführen, um Yarn global zu installieren.
Und von nun an kann man Yarn nahezu ident zu NPM verwenden. Die meisten üblichen Befehle sind gleich, oder haben nur geringe Abweichungen.

Die wichtigsten Befehle

Ein neues Package hinzufügen

yarn add <packagename>

Ein neues Package als dev-dependency hinzufügen

yarn add --dev <packagename>

Ein Package entfernen

yarn remove <packagename>

Installation starten

yarn (“install” muss nicht eingegeben werden)

Weitere Befehle

Die meisten anderen Befehle sind eins zu eins gleich wie bei NPM:

npm link === yarn link
npm outdated === yarn outdated
npm publish === yarn publish
npm run === yarn run
npm cache clean === yarn cache clean
npm login === yarn login
npm logout === yarn logout
npm test === yarn test


Fazit

Yarn ist einfach einzurichten und benötigt beinahe keine Einarbeitungszeit. Mit einigen Vorteilen gegenüber NPM und dem gleichen Ekosystem dahinter, ist es somit meiner persönlicher Favorit und auch meine erste Wahl für zukünftige Projekte.

The post Yarn – “the new cool kid on the block” appeared first on Mobile USTP MKL.

Die meisten Webdeveloper haben bestimmt schon einmal von Google PageSpeed Insights gehört. Viele davon haben vermutlich auch schon die eine oder andere Maßnahme ergriffen, um ihr aktuelles Websiteprojekt dahingehend zu optimieren, um bei der Überprüfung durch Google PageSpeed Insights ein besseres Ergebnis als zuvor zu erzielen. Was man jedoch eher selten sieht, sind Websites die wirklich bis aufs letzte optimiert worden sind, um eine wirklich hohe Punktezahl bei der Beurteilung durch Google PageSpeed Insights zu erhalten.
Dafür mag es viele Gründe geben, die wichtigsten sind jedoch wahrscheinlich:

• zu wenig Geld
• zu wenig Zeit
• zu wenig Fachwissen

In den meisten Projekten ist es wahrscheinlich eine Kombination aus allen drei Gründen, vielleicht auch nur eine Kombination aus den beiden ersten. An alle, die jedoch noch wenig oder gar keine Erfahrung mit der Performanceoptimierung haben, richtet sich folgender Blogbeitrag.

Grundvoraussetzungen

Bevor man sich explizit ans Optimieren macht, sollte man sicherstellen, das die Grundvoraussetzungen einer “sauberen” Website erfüllt werden. Damit meine ich vor allem sauberen HTML-Code mit allem was dazu gehört. Am besten also zuerst einmal den HTML-Code validieren lassen, zum Beispiel über W3C Validator. Falls dort der eine oder andere beliebte Fehler, wie zum Beispiel fehlende alt-Tags bei Bildern oder falsch verschachtelter HTML-Code entlarvt wird, sollten diese Fehler vorweg behoben werden.

Was muss optimiert werden?

Nun ist es soweit, die Optimierung kann starten. Um zu wissen, was man an der aktuellen Seite alles optimieren kann, ist es am leichtesten einfach mal die Google PageSpeed Insights aufzurufen, den Link der Website einzugeben, und sich die Vorschläge von Google anzusehen.

Keine Angst, es ist normal, dass eine Website die bis jetzt noch nicht oder kaum optimiert wurde, hier erst einmal ziemlich schlecht abschneidet. Also nicht schrecken, auch wenn Werte unter 70 von Google in oranger Warnfarbe, und Werte unter 60 sogar in roter Farbe gekennzeichnet werden.

Mobil vs. Desktop

Auch normal ist, dass die Wertung für Mobile geringer ist, als für Desktop. Das liegt vor allem daran, dass Google davon ausgeht, dass man beim Zugriff auf Websiten über mobile Geräte über eine langsamere Internetverbindung verfügt, was das Laden von Ressourcen verzögert, was wiederrum zur Folge hat, dass Seiten für die mobile Nutzung noch stärker optimiert werden sollten. Eine Seite die gute Werte für den Abruf über Desktop – Geräte hat, kann also durchaus nur mittelmäßige Werte beim Abruf über mobile Geräte haben. Zu sehen ist das im folgenden Screenshot, der die gleiche Website wie zuvor zeigt, jedoch eben mit anderer Gewichtung unterschiedlicher Faktoren.

Die wichtigsten Optimierungen

Nachdem man nun weiß, wo Google Optimierungspotential sieht, kann man sich auch schon darauf stürzen.

Caching

Der erste Fehler, der in unserem Beispiel von Google aufgeführt wird, ist in diesem Fall “Browser-Caching nutzen”. Freundlicherweise gibt es bei jedem Fehler auch einen Link zur Fehlerbehebung, der zum jeweiligen Artikel in der Dokumentation der Google PageSpeed Insights führt. Dieser Link hier zum Beispiel, informiert uns also darüber, wie wir Browser-Caching nutzen können. Wie genau die dort beschriebenen Punkte aber umgesetzt werden können, steht hier leider nicht dabei. Aber nach einer kurzen Recherche gibt es massenhaft Links zu Websites, die hierbei behilflich sind. Zum Beispiel empfiehlt Patrick Sexton auf seiner eigens für die Optimierung von Websiten für Google Page Speed Insights angelegten Website varvy.com folgenden Code in die .htaccess Datei der Website einzufügen:

## EXPIRES CACHING ##

## EXPIRES CACHING ##

“above the fold”

Der nächste Punkte der so gut wie immer auftauchen wird, wenn eine Seite das erste mal von Google Page Speed Insights überprüft wird, nennt sich “above the fold”. Hier geht es darum, dass JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten “above the fold” (ohne Scrollen sichtbar) zu beseitigen. Ich persönlich habe bei meinem Portfolio das Node-Package critical von Addy Osmani verwendet. Wer sich genauer mit diesem Thema beschäftigen möchte, sollte sich den ebenfalls hier auf dem MFG Blog verfügbaren Artikel “Critical CSS” zu Gemüte führen.

Komprimierung

Ebenfalls sehr wichtig ist die Komprimierung der Daten bevor sie ausgeliefert werden. Eine genaue Beschreibung dazu findet sich ebenfalls auf der wirklich empfehlenswerten Website varvy.com, von der auch die beiden folgenden Code-Snippets stammen, die wiederum in die .htaccess integriert werden müssen. Je nachdem um welchen Webserver es sich handelt, bzw. welche Rechte dort vorhanden sind, sollte entweder dieser Code:
ifModule mod_gzip.c
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
/ifModule

oder sonst dieser:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

das gewünschte Ziel herbeiführen.

Ergebnis

Wenn man sich so also Schritt für Schritt voran hantelt, sollte man nach jeder durchgeführten Optimierung eine Verbesserung der Wertung auf Google PageSpeed Insights erkennen. Wenn man das nun bis zum Limit treibt, sind beinahe 100 Punkte möglich. Ich selbst habe dies auf meiner Website www.suits.at ausprobiert, und bin mit dem Ergebnis mehr als zufrieden.
Perfektionisten werden sich nun an dem einen fehlenden Punkt stören – mir ging es hierbei nicht anders. Dieser eine Punkte kommt daher, dass Google der Meinung ist, dass Google Analytics Script sollte gecached werden. Da das Script aber bekanntlich auf Googles Servern liegt, hat man als Nutzer keinen Einfluss auf das Caching dieses Scripts. Es gibt zwar Ansätze und Ideen auf Stackoverflow in denen User dazu raten, das Script über einen Cronjob regelmäßig herunterzuladen und dann vom eigenen Server aus zu laden und cachen, die folgende Antwort gefiel mir persönlich jedoch am besten:
“I wouldn’t worry about it. Don’t put it on your own server, it sounds like this is an issue with Google, but as good as it gets. Putting the file on your own server will create many new problems. They probably need the file to get called every time rather than getting it from the client’s cache, since that way you wouldn’t count the visits. If you have a problem to feel fine with that, run the Google insights URL on Google insights itself, have a laugh, relax and get on with your work.”
Was ich getan habe, und nach einem kurzen lächeln war ich dann auch mit den 99 Punkten zufrieden.

The post Performance Optimierung für Google PageSpeed Insights appeared first on Mobile USTP MKL.

Im Rahmen des Initialprojekts für Mobile Anwendungen habe ich mit “QR Live Stats” eine kleine Webapplikation erstellt, die Daten aus der Google Anylatics API im Frontend ausgibt. Ansich ist das keine Hexerei und mit relativ wenig Code umsetzbar – jedoch gibt es eine Menge Stolpersteine, die es zu überwinden gilt, bevor man zu dem gewünschten Ergebnis kommt. Da ich diese Erfahrung bereits gemacht habe, möchte ich mit diesem Blogeintrag meine Erfahrungen teilen, und hoffe dem einen oder anderen damit etwas Zeit zu ersparen.

Aller Anfang ist schwer

Wie so oft in der Welt der Webentwicklung, startete auch dieses Projekt mit einer Google Suche. Wenige Mausklicks später landetete ich in der sehr, und ich meine wirklich sehr umfangreichen Google Analytics API. Der Umfang der API hat zur Folge, dass sich in dieser Informationen zu beinahe jedem Anwendungsfall finden – was gleichzeit sowohl ein Vor- als auch ein Nachteil ist. Wenn man genau weiß wonach man sucht, ist dies auf jedenfall ein Vorteil. Es gibt viele Codebeispiele, sogar in verschiedenen Programmiersprachen und jede Menge Referenzen allermöglicher Attribute, Werte, Einstellungen und was man sonst noch brauchen könnte. Wenn man jedoch keine Ahnung hat, was genau man sucht, und probiert über Stichwörter wie “frontendausgabe, php, javascript” zu einem Ergebnis zu kommen, ist man möglicherweise schon auf der Übersichtsseite der Google Analytics API verwirrt und muss mit einigen Stunden an Recherchearbeit rechnen. Da die vielen Themen auf die man dabei stoßen kann, bis man findet was man eigentlich braucht, nicht besonders spannend sind, lasse ich diesen Teil aus und komme weiter zu dem Punkt, in dem ich erkläre, was nun wirklich zu tun ist.

Vorraussetzungen

Zu allererst braucht man natürlich eine Website, von der die Daten kommen sollen und dafür natürlich auch den entsprechenden Analytics Code. Da dieser sich nicht vom “normalen” Code unterscheidet, den man sonst braucht, wenn man eine Seite tracken möchte, gehe ich hier nicht weiter darauf ein.
Zudem braucht man außerdem einen sogenannten Service Account um die Authentifizierung die normalerweise notwendig ist um ins Dashboard von Google Analytics zu gelangen, und sich die Daten anzeigen zu lassen, zu umgehen bzw. direkt am Server zu erledigen. Hierbei sind folgende Schritte notwendig:

1. Eine Client ID in der Google Developers Console anlegen und die Emailadresse des neuen Service Accounts zum Google Analytics Account hinzufügen.
2. Die PHP Client Library die für den Zugriff auf die API benötigt wird auf den Server kopieren.
3. Das “key.p12” File, dass beim Erzeugen der Client ID generiert wurde, auf den Server kopieren.

Weitere Informationen dazu finden sich in der Google Anlytics API.

Umsetzung

Nun braucht man noch ein PHP File, in dem die Einbindung aller Ressourcen stattfindet. Ein Beispielfile dafür stellt Google ebenfalls in der API (hier) bereit. Wenn man nun noch die Pfade für die PHP API und das Keyfile richtig setzt, und zudem die Mailadresse des Serviceaccounts einträgt, sollte an dieser Stelle die Grundfunktionalität gegeben sein.
Wer jetzt diesen Error bekommt “A client error occurred: Could not create storage directory” der ist nicht der Erste. Bei Stackoverflow habe ich auch hierfür eine Lösung gefunden:

$config = new Google_Config();
$config->setClassConfig('Google_Cache_File', array('directory' => '../tmp/cache'));
// Here I set a relative folder to avoid pb on permissions to a folder like /tmp that is not permitted on my mutualised host
$client = new Google_Client($config);
// And then,  you pass the config for your GoogleClient

Mit diesem Snippet sollte nun alles funktionieren.

Feintuning

Wenn man den Beispielcode aus der API verwendet, werden alle Sessions der letzten 7 Tage angezeigt. Wenn man andere Daten auslesen beziehungsweise anzeigen möchte, kann man die Parameter in der getResults Function entsprechend anpassen. Im Dimensions & Metrics Explorer gibt es dazu eine ebenfalls sehr umfangreiche Dokumentation der möglichen Werte. Zudem können auch diverser Filter verwendet werden. Ebenfalls sehr hilfreich ist hierbei der Query Explorer, mit Hilfe dessen man die Querys testen kann, bevor ma sie auf den eigenen Code anwendet.

The post Google Analytics: Datenausgabe im Frontend appeared first on Mobile USTP MKL.

Idee

Ziel von QR Live Stats war es, mit Hilfe von QR-Codes auf Visitenkarten, möglichst viele Personen auf die für dieses Projekt erstellte Website zu leiten.

Design

Da ich mich selbst nicht als Designer ansehe, wollte ich auch das Design des Printmaterials möglichst einfach halten. Um dennoch den einen oder anderen anzusprechen, habe ich deswegen versucht, an die Neugierde der Personen zu appellieren, was folgiges Design zur Folge hatte:

Vorgehensweise

Die Visitenkarten enthielten dabei verschiedene verschiedene QR-Codes, die in Abhängigkeit von ihrer Platzierung eine jeweils andere ID erhalten. Somit war es mir möglich zu erkennen, wo der QR-Code gescanned wurde. Zum Beispiel hatte der QR-Code auf dem Tisch eine andere ID als der auf dem Beamer.

Was mich auch schon zum weiterführenden Ziel bringt: Nachdem der Nutzer den QR-Code gescanned hat, soll dieser auf eine Website geleitet werden (zum Beispiel hierhin), auf welcher er nun Statistiken erhält. Zum werden Angaben darüber gemacht, der wievielte „Neugierige“ am jeweiligen Ort der Nutzer bereits ist, zum anderen erhält er dort weiterführende Informationen anhand der Google Analytics API. Derzeit erfolgt hierbei eine Auflistung der am meisten benutzten Mobile Devices.

Ausblick

Falls das Projekt weiterverfolgt und ausgebaut wird, können hier jedoch noch eine Vielzahl an weiterer Daten wie z.b. verwendeter Browser, beliebte Uhrzeiten, … ausgegeben werden. Ebenfalls für ein weiterführendes Projekt interessant wären Infografiken, welche die ausgegebenen Statistiken grafisch ansprechend aufbereiten.

Technische Umsetzung & Fazit

Die technische Umsetzung erfolgte mit Hilfe von von PHP/HTML/JS/CSS und der Google Analytics API. Da ich bei der Erstellung dieser Anwendung über eine Vielzahl von “Steinen gestolpert” bin, werde ich hierzu noch einen eigenen Artikel schreiben, welcher sich im Detail mit der Frontendausgabe von Daten aus der Google Analytics API beschäftigt, und hoffe somit dem einen oder anderen etwas Zeit mit der Google Analytics API ersparen zu können.

The post Print To Mobile: QR Live Stats appeared first on Mobile USTP MKL.