Klingt erstmal simpel und langweilig – aber macht unglaublich viel Spaß! Die Challenge besteht weniger darin, die einzelnen Aufgaben einfach nur zu lösen. Viel mehr will man diese möglichst kurz und intelligent lösen. Nachdem man eine Aufgabe gelöst hat, bekommt man die Lösungen der anderen zu sehen. Hier gibt es schon gewaltige Unterschiede in der Länge des Codes.

Hier ist für mich auch der größte Lerneffekt zu verzeichnen. Man hat sich eine Weile mit einem Problem beschäftigt und ist zu einer Lösung gekommen. Aber ob das nun gut und schlau gemacht ist? Weiß man normalerweise nicht. Bei Codewars beschäftige ich mich dann länger mit den Ansätzen von anderen Entwicklern und lerne so, viel schnelleren und performanteren Code zu schreiben.

Ein Beispiel:

Man soll in jeder Zeile des folgenden Dreiecks die Summe berechnen können. Die übergebene Zeile kann natürlich auch 128094839 sein.

             1
          3     5
       7     9    11
   13    15    17    19
21    23    25    27    29
...

Also wie löst man das Ganze?

Meine Lösung war folgende:

function rowSumOddNumbers(n) {
  var res = 0;
  for (i = n * n - n; i < n * n + n; i++) {
    if (i % 2 == 1) res += i;
  }
  return res;
}

Die am besten bewertet Lösung war allerdings viel kürzer:

function rowSumOddNumbers(n) {
  return Math.pow(n, 3);
}

Wäre ich erstmal nicht drauf gekommen. Andere machen es aber noch viel komplizierter. Hier ein sehr langes Beispiel:

function rowSumOddNumbers(n) {
  //find odd numbers
  //the nth row will contain n+1 odd numbers
  var triangle = [];
  var odds = [];
  var sum = 0;
  
  var findOdds = function (n) {
    var numberOdds = 0;
    //find out how many odds there are total
    for(var i = 0; i < n; i++){
      numberOdds = numberOdds + i + 1;
     }
    //create an array of odd numbers
    for(var j = 0; j != numberOdds; j++){
      odds.push((2 * j) + 1); 
    }
  };
  
//sum the last n + 1 numbers of odds
  
  var sumLastRow = function(n){  
    var lastRow = [];
   
     for (var i = 0; i < n; i++){
      lastRow.push(odds[odds.length - (n - i)]);
      }
     
      for (i = 0; i < lastRow.length; i++){
          sum += lastRow[i];
          }     
   }     
   
 findOdds(n);
 sumLastRow(n);
 return sum;
}

Das Ergebnis ist exakt das gleiche. Verrückt, oder? Das schöne ist, dass man sich sicher sein kann, dass alle gezeigten Lösungen auch wirklich funktionieren. Denn beim Programmieren muss man verschiedene Unit-Tests bestehen, welche vom Autor des Katas vorgegeben wurden. So kommt man in den meisten Fällen nicht um eine korrekte Lösung herum, da man die Tests beim Einreichen auch nicht sieht oder kennt. Man kann also faktisch nicht manipulieren. Klasse gemacht!

Ich kann die Plattform jedenfalls voll empfehlen! Das Gute ist, dass man erst einen kleinen Test bestehen muss um sich anzumelden. So wird vermieden, dass ich absolute Beginner oder Bots auf der Seite überhaupt anmelden. Man ist also unter Entwicklern.

Und die Aufgaben sind meistens so kreativ, dass man schon hin und wieder Google braucht. Das meiste ist allerdings mit etwas Köpfchen gut zu schaffen. Allerdings habe ich die ganz schweren Aufgaben bisher auch links liegen lassen. Aber das sind dann richtige Herausforderungen!

Falls ihr nun Lust bekommen habt, meldet euch doch schnell an!

Und was ist das Ergebnis? Ich ärgere mich, dass ich das nicht schon viel eher gemacht habe! Dabei habe ich mich schon häufig gefragt, wie manche Web-Apps gebaut wurden. Oder viel mehr: Wie behalten die Entwickler den Überblick in so riesigen UIs? Und ich glaube, dass ich für mich genau diese Antwort in AngularJS gefunden habe!

Aber wie? Nur vom Dokumentation lesen wird einem schnell langweilig – und so richtig steigt man dann doch nicht dahinter. Die Antwort für solche Themen ist für mich seit gut einem Jahr Udemy. Und auch dieses Mal bin ich dort wieder über einen tollen Kurs zum Thema AngularJS gestolpert: Learn and Understand AngularJS.

Spätestens ab Kapitel 9 strahlt ein jQuery-Nutzer wie ich über das ganze Gesicht. Man muss sich einfach nicht mehr selbst um das ganze Ein- und Ausblenden von Komponenten und die DOM-Pflege kümmern. All das macht das Framework. Hier muss man natürlich am Anfang entsprechen umdenken und darf nicht versuchen, alles selbst zu erledigen. Viel mehr beschreibt man, was mit Elementen in bestimmten Situationen geschehen soll (Directives).

Ich möchte hieraus nun kein AngularJS-Tutorial machen, sondern viel mehr darauf Aufmerksam machen, dass man eventuell ein tolles Framework verpasst, wenn man es einfach ungeachtet links liegen lässt. Und dann entwickelt man auf einmal eine Single-Page-Application mit jQuery. Das funktioniert bestimmt, ist aber eben sehr anstrengend und nicht unbedingt empfehlenswert. Früher oder später verliert man den Überblick, oder muss sich seltsame Konstrukte ausdenken. Spätestens, wenn neue Entwickler ins Boot kommen, darf man seine eigenen Patterns erklären. All das entfällt, wenn man direkt mit AngularJS startet. Hier ist das meiste sehr strikt vorgegeben und man muss sich über bestimmte Wege keine Gedanken machen, da diese schon definiert sind.

Nimmt man dann noch ein Framework wie Bootstrap zu Hilfe, kommt man schnell zu tollen Ergebnissen, die sich wirklich sehen lassen können. Man muss nicht mehr so viel Environment vorbereiten, sondern kann direkt mit der eigentlichen Logik durchstarten.

Ich bin jedenfalls froh, dass ich das Thema angeschaut habe. In naher Zukunft wird dann sicher das ein oder andere neue git-Repo angelegt, in denen ich das alles Umsetze. Aktuell habe ich schon mehrere Ideen für Projekte mit dem Framework. Eventuell sogar etwas im Bereich Haus-Automatisierung. Seid gespannt.

Und in der Zeit: Nehmt Euch den Themen an, die schon zu lange auf der ToDo-Liste stehen! Bei steht z.B. noch nodejs an.

Aber nun zum eigentlichen Thema: Wie unterscheidet sich var von let? Mit beiden Schlüsselworten kann man neue Variablen deklarieren.

Globale deklaration

Benutzt man diese Schlüsselwörter außerhalb von Funktionen, verhalten sie sich exakt identisch. Beide Zeilen führen hier also zum gleichen Ergebnis:

let testLet = 'klappt';
var testVar = 'alles';

Innerhalb Funktionen

Das wird jetzt etwas verwundern, aber auch hier sind die beiden Schlüsselwörter komplett identisch zu verstehen.

function meineTolleFunktion() {
    let anotherLetTest = 'beides';
    var anotherVartest = 'identisch';
}

Blocks / Blöcke

Hier kommen jetzt die Stärken von let zum tragen. Außerhalb von for-Schleifen ist die Variable auf einmal nicht mehr verfügbar. Für mich auf jeden Fall erstrebenswert und das schönere Verhalten.

function testLet() {
    for( let i = 0; i < 10; i++ ) {
        // Nur hier kann i genutzt werden
    };

    // i ist hier NICHT verfügbar
};

function testVar() {
    for( var j = 0; j < 10; j++ ) {
        // natürlich ist j hier auch verfügbar
    };

    // j IST hier verfügbar
};

Ich denke, dass es durch das Beispiel sehr deutlich wird, was es mit dem Schlüsselwort auf sich hat. Total genial finde ich auch das Feature, dass man Variablen extra für einen bestimmten Scope deklarieren kann:

function weiteresFeature() {
    let( nochEinTest = 'blabla' ) {
        // nochEinTest kann hier genutzt werden
    };

    // nochEinTest ist hier NICHT verfügbar
}

Fazit

Für eine sauberere Programmierung würde ich eigentlich immer die Nutzung von let innerhalb von Blöcken empfehlen. Dann kommt man gar nicht erst in die Verlegenheit, Variablen zu nutzen, welche in einem anderen Scope definiert wurden.Ich kann es eigentlich überhaupt nicht leiden, wenn Variablen auf einmal nach einer Schleife noch verfügbar sind. Das ist einfach unschön und diese zu verwenden hat mit guter Programmierung auch wenig zu tun. Aber leider lässt man ältere Browser damit definitiv auf der Strecke und die Seite ist auf einmal nicht mehr lauffähig.

Gut, für den IE6 optimieren mittlerweile eh die wenigsten (hoffe ich zumindest) – aber für das bisschen an Mehrwert während der Entwicklung, würde ich das Risiko auf mich nehmen und let einfach nie benutzen.

Wie schon in so vielen Beiträgen erwähnt, kann ich nur dazu raten brew zu installieren. Dabei handelt es sich um einen Paket-Manager für Mac OS X, welcher die Installation von neuer Software wirklich super einfach gestaltet. Ich habe kaum Pakete gefunden, welche nicht über brew verfügbar sind (momentan fällt mir sogar nichtmal ein Beispiel ein).

Die Installation stoßen wir also ganz einfach mit folgendem Befehl an:

brew install node

Sobald man sich auf ghost.org registriert hat, kann man die Quellen herunterladen. Nachdem diese entpackt sind, findet man die Datei config.example.js. Diese wird einfach dupliziert und config.js genannt.

cp config.example.js config.js

In dieser Datei ändern wir die Datenbankkonfiguration auf mySQL. Ich nutze mySQL einfach, weil ich lokal MAMP installiert habe – ihr könnt natürlich auch jede andere Datenbank nutzen. Per phpMyAdmin lege ich eine neue Datenbank namens „ghost“ an. Die Konfiguration wird dann wie folgt angepasst:

database: {
	client: 'mysql',
	connection: {
		host: '127.0.0.1',
		user: 'root',
		password: 'root',
		database: 'ghost',
		charset: 'utf8'
	},
	debug: false
},

Damit mySQL auch lauffähig ist, wird das nötige Paket über npm installiert:

npm install mysql

Danach können wir (im ghost-Verzeichnis) folgenden Befehl ausführen, um alle Abhängigkeiten zu installieren:

npm install --production

Nun können wir die Instanz von Ghost auch schon starten:

node index.js

Die Ausgabe sollte dann in etwas so aussehen:

Ghost is running in development... 
Listening on 127.0.0.1:2368 
Url configured as: http://my-ghost-blog.com

Gibt man nun die IP + Port in den persönlichen Lieblingsbrowser ein, wird man auch schon begrüßt. Das war ja wirklich einfach! Schaut man sich die Datenbank dann an, sieht man auch, dass einige Tabellen erstellt wurden – der Datenbankzugriff funktioniert also super.

Folgt man dem Hinweis, dass man doch bitte /ghost/ aufrufen möchte, dann hat man die Chance einen Admin-Account anzulegen. Nachdem man das getan hat, kann man auch direkt mit dem Schreiben starten. Da ich lokal Postfix konfiguriert habe, bekomme ich auch gleich eine Begrüßungsmail.

Und schon haben wir eine funktionierende Installation von Ghost. Tat doch gar nicht weh, oder? Ich werde mich jedenfalls in Zukunft etwas näher mit node.js und Ghost auseinander setzen. Ich denke, Ghost steht noch ganz am Anfang.

Der aktuelle Trend für OnePages ist allerdings das sogenannte „parallax scrolling“ – das bedeutet, dass sich unterschiedliche Ebenen beim scrollen unterschiedlich schnell bewegen. So entsteht viel mehr Tiefe auf der Seite und alles wirkt einfach lebendiger.

Wer jetzt noch nicht verstanden hat was ich genau meine, der sollte sich durch folgende Links klicken:

• teamtreehouse.com
• spotify.com
• oakley.com
• jessandruss.us

Also, was braucht man denn nun um solch ein Layout zu bauen? Im Web existieren verschiedene Frameworks, welche einem alle einen relativ guten Start geben. Ich habe mich vom Bauchgefühl her aber bisher nur auf „cool kitten“ fixiert und bin insgesamt mit den Ergebnissen sehr zufrieden. Bisher konnte ich alles realisieren was ich mir vorgenommen habe. Außerdem bietet es einen einfachen Start in die Materie und man landet relativ schnell da, wo man hin möchte.

So habe ich als erstes eine Landing-Page für die Neugeborenen-Shootings meiner Freundin ins Leben gerufen, um mich mit der Materie etwas genauer auseinander zu setzen. Und ich muss sagen, dass ich mit den Ergebnissen sehr zufrieden bin. Leider unterstützen Mobilgeräte die Funktion noch nicht wirklich, und so muss man die Seite nebenbei nochmals für Mobilgeräte optimieren. Bisher habe ich auch noch keine Lösung gefunden, um diesen Effekt auf Mobilgeräten zu realisieren.

Das komische daran ist, dass es im Firefox seit Ewigkeiten korrekt funktioniert hat – nur Chrome ging nicht so richtig. Seit den neueren Firefox-Versionen trat dann das selbe Problem auf. Nach einem Ajax-Call sind die Links im Menu in neuen Tabs geöffnet worden anstatt direkt in dem anderen Frame.

Ich habe viel ausprobiert um das Problem zu lösen – das erneute setzen des Frame-Namens nach jedem Request (per JavaScript) hat das Problem schließlich gelöst.

self.name = "content";

Am besten man nutzt einfach keine Frames mehr und geht solchen Problemen direkt aus dem Weg.

Ich habe mich schon öfter gefragt, welche Vorteile es wohl hat, wenn man jQuery von Google hosten lässt statt sich einfach eine Version zu laden und diese einzubinden. An Traffic-Ersparnissen oder gar Speicherplatz kann es ja nun wirklich nicht liegen. In diesem Artikel möchte ich Vor- und Nachteile beleuchten.

<script type="text/javascript" src="/jQuery.min.js"></script>

Ja, auch ich habe bisher meistens (eigentlich immer) eine Kopie von jQuery geladen und auf dem eigenen Server deponiert. Aber warum sollte man die entsprechenden Daten nicht aus dem CDN (Content Delivery Network) von Google beziehen? Google ist schließlich für schnelle Server und hohe Erreichbarkeit bekannt. Einen Ausfall der Server kann man also beruhigt ausschließen denke ich. Bei mir lag es immer an einem anderen Grund: Ich habe einfach kein gutes Gefühl dabei, wenn essentielle Teile meiner Webseiten irgendwo im Internet verstreut liegen. Außerdem kann ich die Webseite dann nicht offline weiterentwickeln (ok, das ist wirklich etwas konstruiert).

Als letzter und wichtigster Punkt: Das Google CDN ist kostenlos und für jeden ohne Anmeldungen oder Restriktionen verfügbar!

Vorteil: Geringere Verzögerung

Dieser Punkt kommt sicher erst in größeren und internationaleren Projekten zum tragen, aber durch das CDN von Google, lädt jeder Browser des Benutzers die Daten vom nächsten Zugriffspunkt anstatt von dem (eventuell) viel weiter entfernten eigenen Server.

Vorteil: Parallele Verbindungen

Die heutigen Browser beschränken aus Performance-Gründen gerne die Anzahl von parellel Verbindungen zu einem Hostname. In der Zeit wo sonst jQuery vom eigenen Server geladen würde, hat man also noch Reserven um den eigenen Inhalt schneller zu laden. Falls man fünf oder mehr parallele Verbindungen konfiguriert hat, macht sich das natürlich weniger bemerkbar. Die heutigen Breitbandanschlüsse sind im übrigen so schnell, dass dieser Punkt sicherlich nicht sehr stark ins Gewicht fällt. Aber am Ende ist man doch dankbar um jede Millisekunde die man sparen kann, oder?

Vorteil: Caching

Der in meinen Augen größte Benefit ist, dass dank Caching-Mechanismen im Browser die komplette Datei nur einmal geladen werden muss – und das sogar Seitenübergreifend. Kommt man also von einer unbekannten Seite, welche zufällig die selbe Version von jQuery benutzt, muss man diese nicht erneut laden, da Google dann mit einem 304 (Not Modified) antwortet. Es werden also ausschließlich die Header-Informationen ausgetauscht. Das funktioniert sogar, wenn man die Seite komplett neu lädt. So entscheidet also nicht der Browser des Benutzers ob der Cache genutzt werden soll, sondern der Server von Google. Die Daten werden einfach nicht ausgeliefert.

Würde also jede Seite mit jQuery das CDN nutzen, würde man insgesamt sicher einige Megabyte einsparen können.

Implementation

Um die Vorteile des Google CDN zu nutzen, kann man einfach folgenden Code verwenden:

<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">// <![CDATA[
  google.load("jquery", "1.8.2");
  google.setOnLoadCallback(function() {
    // Hier der jQuery Code - statt $(document).ready()
  });
// ]]></script>

So wird die entsprechende Library in der angegebenen Version geladen. Das ist natürlich etwas irreführend – wo soll da die Performance her kommen? Nun haben wir doch schon zwei Requests statt nur einen. Außerdem ist es für mich schon wieder viel zu viel extra Code. Daher würde ich mich persönlich auf eine etwas gekürzte Version einlassen:

<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>

Nun hat man gleich viel Code wie in der vorigen Variante (mit einer Kopie auf dem eigenen Server). Nur der Pfad hat sich geändert.

Als ich den Code das erste Mal gesehen habe, habe ich gedacht der Pfad sei falsch. Immerhin fehlt dort ein http:// oder https://. Dies ist aber vielmehr eine intelligente Lösung um sowohl im http- als auch im http-Kontext zu laufen. Wirklich genial.

Fazit

Wie man sieht macht es durchaus Sinn, dass man dass CDN von Google nutzt und jQuery von Google hosten lässt. Ich werde jedenfalls in Zukunft etwas anders über diese Möglichkeit denken, anstatt es nur zu belächeln und nicht zu verstehen.