real page files

resources/page/blogs/blag/entries/01-yottabyte.md

@@ -0,0 +1,36 @@
+---
+{:title "Yottabyte"}
+---
+
+# Was ist ein Yottabyte?
+
+Wieviel ist das? Wie kann man sich so eine Zahl vor Augen halten?
+
+Zur Verdeutlichung, die Reihenfolge der Binärpräfixe ist:
+
+- Kilo
+- Mega
+- Giga
+- Tera
+- Peta
+- Exa
+- Zetta
+- Yotta
+
+<blink>
+
+Wie kann man so eine gigantische Menge von Bytes nachstellen? Die Überlegung stammt von Anfang 2011, da waren Terabytefestplatten so langsam üblich. Also nimmt man eine entsprechend große Menge solcher Datenträger und vergleicht diese mit bekannten Größen.
+
+Die nachfolgende Liste an Rechnungen und Beispielen haben keinerlei Anspruch auf Korrektheit, Praxisnähe oder Machbarkeit. Als Berechnungsgrundlage dient meine alte eigene 1TB-Festplatte - Typ Samsung HD 103 SJ.
+
+- 10 hoch 15 (1.000.000.000.000.000 oder 1 Billiarde) Festplatten zu je 1 Terabyte entsprechen 1 Yottabyte, oder einer Trilliarde Megabyte
+- Bei einem Cache von 32 Megabyte pro Festplatte haben wir 32 Zettabyte oder 32 Tausend Exabyte Cache
+- Bei einem Stromverbrauch von 7,2 Watt pro Festplatte ergibt sich bei 10 hoch 15 Festplatten ein Gesamtstromverbrauch von 7,2 Billionen Kilowatt oder 7,2 Milliarden Megawatt
+    - Dies entspricht der Leistung von 4.500.000 Atomkraftwerken
+- Die Masse einer Festplatte beträgt 625g - bei einer Billiarde Festplatten ergeben das 625.000.000 Kilotonnen Masse
+    - Die Masse der Titanic betrug zu "Lebzeiten" 53.147 Tonnen
+    - Die Masse einer Billiarde Samsung HD 103 SJ entspricht der Masse von 11.759.835,92 Titanicen (Pluralbildung korrekt?)
+- Eine Samsung HD 103 SJ kann mit einer Geschwindigkeit von bis zu 96,582 Megabyte pro Sekunde beschrieben werden
+    - Eine Billiarde Samsung HD 103 SJ nacheinander komplett zu beschreiben dauert 1,035389 mal 10 hoch 19 Sekunden. Diese unscheinbare Sekundenanzahl entspricht 32.800.000.000.000 (32,8 Billionen) Jahren
+- Eine Samsung HD 103 SJ hat folgende Maße: Höhe 26,1mm, Breite 101,5mm, Länge 147,0mm
+    - Die Fläche von 1 Billarde dieser Festplatten beträgt 14.838.680.000.000.000.000.000 - also rund 14 Trilliarden Quadratkilometern. Wenn man davon ausgeht, dass die Erde eine Fläche von 510 Millionen Quadratkilometern aufweist, braucht man ungefähr 29.095.450.980.392,15 (rund 29 Billionen) Erden, um alle Platten nebeneinander auslegen zu können. Naja, im Universum gibt es ja genug Sterne...

resources/page/blogs/blag/entries/02-perlis.md

@@ -0,0 +1,45 @@
+---
+{:title "Epigramme von Alan J. Perlis"}
+---
+
+# Epigramme von Alan J. Perlis
+
+1982 verfasste der US-amerikanische Informatiker Alan J. Perlis etwas über 100 Epigramme über das Programmieren. Meine Quelle hierfür ist ein Eintrag bei [archive.org](http://web.archive.org/web/19990117034445/http://www-pu.informatik.uni-tuebingen.de/users/klaeren/epigrams.html). Hier einige ins Deutsche übersetzt:
+
+> 1: One man's constant is another man's variable.
+
+Was für den einen eine Konstante ist, ist für den anderen eine Variable.
+
+<blink>
+
+> 5: If a program manipulates a large amount of data, it does so in a small number of ways.
+
+Verändert ein Programm große Mengen an Daten, tut es dies in einer geringen Menge an unterschiedlichen Schritten.
+
+> 6: Symmetry is a complexity reducing concept; seek it everywhere.
+
+Symmetrie ist ein Konzept, das Komplexität verringert. Strebe danach.
+
+> 7: It is easier to write an incorrect program than understand a correct one.
+
+Es ist einfacher, ein falsches Programm zu schreiben, als ein falsches zu verstehen.
+
+> 40: There are two ways to write error-free programs; only the third one works.
+
+Es gibt zwei Möglichkeiten, ein fehlerfreies Programm zu schreiben. Nur die dritte funktioniert.
+
+> 63: When we write programs that "learn", it turns out we do and they don't.
+
+Wenn wir Programme schreiben, die "lernen", stellt sich heraus, dass wir diejenigen sind, die lernen.
+
+> 79: A year spent in artificial intelligence is enough to make one believe in God.
+
+Ein Jahr im Bereich Künstliche Intelligenz zu verbringen, ist genug, einen an Gott glauben zu lassen.
+
+> 104: The proof of a system's value is its existence.
+
+Der Beweis für den Wert eines Systems ist dessen Existenz
+
+> 114: Within a computer natural language is unnatural.
+
+Innerhalb eines Computers sind natürliche Sprachen unnatürlich.

resources/page/blogs/blag/entries/03-solid-vs-stable.md

@@ -0,0 +1,47 @@
+---
+{:title "Solid vs Stable"}
+---
+
+# Über die Wartung von Code: S.O.L.I.D. oder S.T.A.B.L.E.
+
+Erklärtes Ziel der objektorientierten Programmierung ist bekanntermaßen, die reale Welt mit Objekten nachzustellen. Objekte stellen dabei meist Sammlungen von Eigenschaften dar, die Fähigkeiten besitzen. Dass, und warum, bei der Umsetzung eines solchen Objektmodells einiges schiefgehen kann, muss man sicherlich niemandem erklären.
+
+<blink>
+
+Um dieser Tendenz entgegenzuarbeiten, es wird an der Stelle auch gerne von Erosion gesprochen, wurden von Robert C. Martin fünf Prinzipien für ein gutes objektorientiertes Design entwickelt, die jeder Programmierer kennen sollte. Zusammengefasst werden sie als `SOLID`:
+
+1.  **S**ingle responsibility principle  
+    Eine Komponente sollte genau eine Zuständigkeit besitzen.
+2.  **O**pen closed principle  
+    Komponenten sollten offen für Erweiterungen, aber geschlossen für Veränderungen sein.
+3.  **L**iskov substitution principle  
+    Objekte sollten durch Instanzen ihrer Kinder ersetzbar sein, ohne die Korrektheit des Programms zu beeinflussen. Benannt nach Barbara Liskov.
+4.  **I**nterface segregation principle  
+    Ein Objekt sollte nicht gezwungen sein, Schnittstellen zu besitzen, die es nicht benötigt.
+5.  **D**ependency inversion principle  
+    Abstrakte Objekte sollten nicht von konkreten abhängig sein.
+
+Diese fünf Prinzipien, so man sie denn korrekt befolgt, führen zu einem prinzipiell wartbaren und gut verständlichem Softwareprojekt. Nun ist es allerdings so, dass es einen weiteren Grundsatz gibt:
+
+> Software wird öfter gelesen als ausgeführt.
+
+Das bedeutet, dass in die Wartung großer Projekte sehr viel Zeit reinfießt; und weil Wartung viel Geld kostet und die User sich an ihre Software gewöhnt haben und, und, und... starten Projekte selten auf der sprichwörtlichen grünen Wiese, fangen also selten bei 0 an. Das beudetet, man findet oftamls über Jahre gewachsene Strukturen vor, die unter den verschiedensten Faktoren entwickelt wurden und von Entwicklern verschiedensten Könnens gewartet werden.
+
+Was das mit `SOLID` zu tun hat? Die oben genannten Prinzipien sind sehr grundlegende, tiefgreifende architektonische Richtlinien. Es bedeutet viel Aufwand sowohl in Sachen Programmierung als auch Testen, ein `Dependency inversion principle` in ein Projekt einzubauen, das bereits seit fünf Jahren prima ohne auskommt. Wie schon an der Formulierung zu erkennen ist, ist der Mehrwert oftmals auch zweifelhalt gering. Woran soll man sich nun also halten, was ist die Mao-Bibel des Legacy-Entwicklers?
+
+Die Softwareentwicklerin Sarah Mei aus den USA schlug für die Wartung von bestehender Software eine andere Abkürzung vor, `STABLE`:
+
+1.  **S**mell your code  
+    Wie man an einem Wein zuerst riecht, soll man sich mit der Codebasis, an er man arbeiten soll, vorher vertraut machen. Was sind bekannte Probleme, was kann man schnell verbessern?
+2.  **T**iny problems first  
+    In gewachsenen Projekten gibt es viele Probleme, vieles *riecht*. Statt den großen Umbau, mit dem man erst Tage später vielleicht fertig ist, zu starten, sollte man die kleinen Probleme zuerst angehen. Erst wenn man die ganzen kleinen Ärgernisse beseitigt hat, kann man das große Ganze korrekt einschätzen.
+3.  **A**ugment tests  
+    Bevor man große Komponenten anfasst und von Problemen bereinigt, muss man das korrekte Verhalten definieren und mit automatischen Tests validieren. Erst dann kann man sicher Korrekturen vornehmen.
+4.  **B**ack up  
+    Sind Objekte zu abstrakt und Funktionen zu verkapselt, sollte die Codebasis erstmal in eine einfachere Form, beispielsweise prozedural, gebracht werden. Danach kann man sich um all die Duplikationen und Kapselungen kümmern und so ein neues Design entwerfen.
+5.  **L**eave it better than you found it  
+    Auch unter dem Namen *Pfadfinderregel* bekannt. Code, den man verwüstet vorfindet, aber an dem man nicht unbedingt Änderungen vornehmen muss, sollte man trotzdem aufräumen und so für den nächsten Entwickler, vielleicht man selbst, besser hinterlassen.
+6.  **E**xpect good reasons  
+    Man sollte immer davon ausgehen, dass Entwickler gute Gründe für das haben, was sie tun. Vielleicht steckt hinter abstrusen Konstruktionen ein tieferer Sinn oder eine Funktion, die man so nicht erahnt hätte. Außerdem ist es gut für die Teammoral, wenn man nicht sofort seinen Kollegen anschimpft, warum Code aussieht, wie er es tut.
+
+Vielleicht können mehr Entwicklerteams diese Prinzipien beachten, wenn sie es mal wieder mit urtümlichen Code nach alter Väter Sitte zu tun haben. Die Folien, inklusive Transkript, des hervorragenden Vortrags, von dem ich diese Informationen habe, sind hier zu finden: [Speakerdeck](https://speakerdeck.com/sarahmei/is-your-code-too-solid-with-transcript).

resources/page/blogs/blag/index.md

@@ -0,0 +1,3 @@
+---
+{:title "Blog"}
+---

resources/page/blogs/datblag/entries/01-entry.md

@@ -1,7 +0,0 @@
----
-{:title "first entry"}
----
-
-# FIRST
-
-hallo welt

resources/page/blogs/datblag/entries/02-entry.md

@@ -1,11 +0,0 @@
----
-{:title "second entry"}
----
-
-# SECOND
-
-Inhalt und so
-
-<blink>
-
-hallo welt wieder

resources/page/blogs/datblag/entries/03-entry.md

@@ -1,7 +0,0 @@
----
-{:title "third entry"}
----
-
-# THIRD
-
-hallo welt wieder wieder

resources/page/blogs/datblag/index.md~

@@ -1,4 +0,0 @@
----
-{:title "datblag"}
----
-

resources/page/index.html

@@ -10,9 +10,9 @@
   <body>
     <header>
       <nav>
-	<a href="index.html">Index</a>
+	<a href="index.html">Startseite</a>
-	<a href="datblag/index.html">Datblad</a>
+	<a href="blag/index.html">Alle Einträge</a>
-	<a href="about.html">About</a>
+	<a href="impressum.html">Impressum</a>
       </nav>
     </header>
     <main>

resources/page/resources/style.css

@@ -19,11 +19,11 @@ header h1 {
 }
 
 main h1 {
-    font-size: 1.7em;
+    font-size: 1.5em;
 }
 
 main h2 {
-    font-size: 1.4em;
+    font-size: 1.3em;
 }
 
 main h3 {
@@ -42,27 +42,18 @@ article {
     padding-left: 1em;
 }
 
-#content .article-title {
+article h1:before {
-    margin-left: -.5em;
+    content: "▻ ";
-    margin-bottom: .3em;
 }
 
-#content .article-title:before {
+blockquote {
-    content: "â–» ";
-}
-
-#content > .article-title~time {
-    margin-bottom: 1em;
-}
-
-#content blockquote {
     background-color: #f5f5f5;
     padding: .3em;
     padding-left: .6em;
     margin-left: 0;
 }
 
-#content blockquote p {
+blockquote p {
     margin: 0;
 }
 

resources/page/sites/impressum.md

@@ -1,3 +1,6 @@
+---
+{:title "Impressum"}
+---
 # Impressum - auch Pflichtangaben genannt
 
 Josha von Gizycki  

resources/page/sites/index.md

@@ -1,6 +1,4 @@
 ---
-{:title "Home"}
+{:title "Startseite"}
 ---
-# Sweet home
+&:last-blog-sites:blag
-
-&:last-blog-sites:datblag