Donnerstag, 3. Juli 2014

Silent Coding :: Episode 2 :: Restlet, Liquidbase, H2 und Guice

In der zweiten Episode von Silent Coding erweitere ich das Beispiel aus der ersten Episode mit einer Datenbankanbindung. Die Abfrage der Datenbank erfolgt dabei mittels JDBI während die Struktur mittels Liquibase beschrieben wird. Zur Steigerung des Komforts wird ausserdem ein DI-Container eingesetzt.



Code:
https://bitbucket.org/blackhawkdc/silent-coding-episode2

Links:
http://restlet.com/
http://h2database.com/html/main.html
http://www.liquibase.org/
http://jdbi.org/
https://code.google.com/p/google-guice/
https://hc.apache.org/

Montag, 23. Juni 2014

Silent Coding :: Episode 1 - Restlet

Willkommen bei Silent Coding.

Hier bei Silent Coding geht es nur ums programmieren, kein quatschen, keine Effekte - reines coden.

Das Ziel von Episode 1 ist ein Grundgerüst für die testgetriebene Entwicklung einer REST-Applikation. Ausgehend von einem Integrationstest wird die Applikation mittels Restlet entwickelt.



Code:
https://bitbucket.org/blackhawkdc/silent-coding-episode1

Links:
http://restlet.org
http://restclient.net






Dienstag, 28. Januar 2014

Aller Anfang ist schwer

Willkommen zu meinem Blog.

Da ich nun lange genug mir gefallende Blogs konsumiert habe, jedoch auch eigene Gedanken habe die ich kommunizieren möchte, werde ich ebenfalls einen kleinen Blog eröffnen.

Hier will ich mich mit allem auseinandersetzen was mit der Entwicklung und Entstehung von Software in Berührung kommt. Ich versuche hier meine bisherigen Schranken und Verhaltens- sowie Denkmuster zu durchbrechen. Ich bin selbst gespannt was dabei herauskommt.

Patrick

Samstag, 25. Januar 2014

Die zwei Arten von Performance

Das wird nun mein erster wirklicher Post. Ich schreibe über ein Thema, das mich die  letzten Tage beschäftigt hat - Performance.

Bei Performance dachte ich bisher lediglich an die  Geschwindigkeit einer Webanwendung. Das ist aber nur eine Performance. Eine andere, und in meinen Augen weitaus wichtigere, ist die Zeit und Kraft, die ein Team benötigt, um Bugs zu beheben und neue Anforderungen umzusetzen.

Während der letzten Projekte habe ich festgestellt, dass diese zwei Arten von Performance sich gegenseitig negativ beeinflussen können.

Um die Geschwindigkeit einer Anwendung zu erhöhen setzt man meist auf einen Cache. Man zerlegt eine Webseite in einzelne Teile, lässt diese im Vorfeld als Schnipsel rendern und im Cache ablegen. Das Frontend muss die Schnipsel nur in der richtigen Weise zusammensetzen.

Was sind nun die Nachteile an solch einem Cache?

Ein Nachteil ist die Größe und damit einhergehend dessen Komplexität. Wie schnell so etwas komplex werden kann, möchte ich an einem kleinen Beispiel zeigen.

Ein Onlineshop hat zu jedem Produkt Bewertungen. Die durchschnittliche Bewertung eines Produkts soll an verschiedenen Stellen im Shop dargestellt werden. Mal in der Detailansicht als große Sternchen, mal innerhalb einer Produktliste als etwas kleinere. Ein anderes Mal soll sie rein textuell zur Geltung kommen. Wann immer die Durchschnittsbewertung das Aussehen beeinflusst, muss ein separates Schnipsel gerendert, mit einer CacheId versehen und gespeichert werden. Wenn eine neue Bewertung hinzukommt, müssen all diese Schnipsel für ungültig erklärt und neu berechnet werden.

Ein weiterer Nachteil ist, dass es meist zwei Stellen gibt, an denen das Aussehen der Seite beeinflusst wird. Zum einen im Backend, wo die einzelnen Schnipsel erzeugt werden und zum anderen im Frontend, wo die Schnipsel zusammengesetzt werden. Das beeinflusst vorrangig die Performance des Teams, da dessen Mitglieder meist gezwungen sind, Änderungen an unterschiedlichen Modulen vorzunehmen.

Was also machen?

Ich würde sagen, wir reduzieren den Inhalt des Caches soweit wie möglich um uns teure Berechnungen zu ersparen. Für das vorherige Beispiel also auf den Durchschnitt der Bewertungen.

Für jedes Produkt also nur eine Zahl anstatt  drei Schnipsel mit Markup.

Damit halten wir die zu cachenden Daten gering und verteilen die Aufgaben neu. Das Backend ist für die Berechnung der Daten zuständig, auf welche das Frontend jederzeit schnell zugreifen kann. Somit hat jedes Modul genau eine Aufgabe zugewiesen bekommen, was die Fehlersuche und Umsetzunge neuer Anforderungen erleichtern sollte.

Des Weiteren reduziert sich die Menge der zu cachenden Daten soweit, dass diese eventuell im Speicher der Applikation vorgehalten und auf den Einsatz eines externen Caches wie Redis oder Memcache verzichtet werden kann. Sollte dies der Fall sein, müssen gecachte Daten nicht mehr übertragen werden, was dann auch zu einer Steigerung der reinen Geschwindigkeit der Webseite führt. In diesem Fall würde die Steigerung der Teamperformance eine Steigerung der technischen Performance bedingen - also eine positive gegenseite Beeinflussung.

Entscheidend für eine gute Balance der zwei Arten von Performance ist scheinbar der Inhalt des Cache.

"Vorberechnen statt Vorrendern" scheint der bessere Weg zu sein.

Patrick