Nachdem ich lange nach einem Theme gesucht habe, bin ich jetzt (endlich!) zu Jekyll umgestiegen.

Das neue Theme ist Neo HPSTR. Wie das Neo verraten lässt, gibt es schon ein HPSTR-Theme. Mit dem habe ich auch rumprobiert, aber das Menü gefiel mir dort nicht, das war mit JavaScript gemacht und das wollte ich nicht. Es gab das Theme auch nicht als RubyGem, was das ganze noch komplizierter gemacht hat. Neo HPSTR kommt im Gegensatz als Gem, und das Menü geht ganz ohne JS! Nur der Farbwechsel von hell zu dunkel beim scrollen geht scheinbar nur mit JS, aber solang’s nur kosmetisch ist, ist das okay.

Nachdem ich dann aber angefangen habe am Theme rumzubasteln, war das Gem dann doch ungünstig und ich wollte dann doch auf die Boilerplate-Variante umsteigen. Aber dann habe ich einfach den Zeilenumbruch aus dem Titel genommen und es war alles wieder okay.

Das (neue) Hintergrundbild ist von Annie Spratt von Unsplash

Beim Suchen nach nem Theme hat mich ziemlich gestört das überall direkt Disqus und Google Analytics verbaut ist. Neo HPSTR hat auch Disqus und GA mit drin, habe aber natürlich beides deaktiviert. :D
Aber Web-Designer packen auch überall Google Fonts und Google APIs rein, letzteres meist sogar nur für jQuery. Und CDN-Cache zählt hier nicht, jQuery hat nen eigenen CDN, der lässt sich auch wunderbar verwenden… naja, egal.

Hauptgrund für den Wechsel ist, dass ich meine Beiträge mittlerweile lieber in mit Markdown in Vim schreibe als Visuell oder als HTML im Wordpress Editor.
Dann blogge ich in Zukunft hoffentlich auch mal wieder was, jetzt wo Artikel veröffentlichen nur noch nen paar Befehle sind… ^^

octopress new $POST
jekyll serve &
vim $POST
kill $!
octopress deploy

Die von Wordpress importieren Beiträge könnten gegebenenfalls etwas komisch formatiert sein, ich habe noch nicht alle Fehler vom Import beseitigt. Es sind auch ein paar Links hinter Bildern kaputt, das filtere ich noch, die Bilder selbst funktionieren aber.

– criztovyl

Meh.

  • Ja, Proxy, diese jenkis-core.jar ist sehr böse, die darfst du bloß nicht durchlassen!
  • Nein, sdkman, ich möchte dich nicht via curl | bash installieren!

So, auch heut' Nacht ist nicht so recht was mit schlafen...

Erstmal noch Gedanken von gestern...

Semesterplan

Ich bin mir beim dieem Projekt nicht so recht sicher, welches interne Datenformat ich nehmen soll. Anfangs hatte ich einfach nur Hashes, dann bin ich zu Structs übergegangen, war dann kurzfristig bei echten Klassen und bin jetzt wieder bei Hashes. So final kommt ICS raus, da überleg' ich ob ich das nicht auch einfach intern VEVENTs nehme. Aber wie gesagt, ich bin mir da noch unsicher.

Nun aber zu heute.

GUI Frameworks

Für meine Idee ne neue Office-Suite zu machen brauche ich so eins, aber die auswahl ist groß und alles hat Vor- und Nachteile. Ich würde dazu ja gerne mal so eine generelle Gegenüberstellung erstellen. Dabei sein sollten: GTK, Qt, WPF.

Qt beispielsweise scheint für mich ne ganz eigene Sprache zu sein, so mit QML und C/C++ was noch ne zusätzliche Toolchain braucht. Und womit das Unternehmen dahinter sein Lebensunterhalt erwirtschaftet weiß ich leider noch nicht.

Bei GTK schwirrt mir nur das Statement durch den Kopf das denen Security egal sei.

Und WPF ist nen Microsoft-Windows-only Ding.

(Edit: Ich hab JavaFX unterschlagen D:)

Virtuelle Maschinen

Hier nicht im Sinne von virtualisierten Computern sonder im Sinne der JVM. Da hab ich etwas rumüberlegt was ich eigentlich generell von sowas halte, so ganz generell ist WORA ja sehr interessant.

Gegenüber der CLI scheint die JVM ja etwas offener zu sein, bei ersterem hat Mircosoft bei den neueren Versionen noch den Patente, wie das bei Oracle aussieht wüsst ich ja auch gern. Aber wenn die JVM patentiert wäre, wär' Android wohl nie so weit gekommen. (Und Orcale hatte im Rechtsstreit mit Google ne ganz andere Grundlage.)

HTML ohne JavaScript

Was mich ja so an Web-Apps gewissen Umfangs stört, ist der JS Anteil.

Ich behaupte mal das da der absolute Flaschenhals liegt, wenn ich da dran denke das UI ja doch gerne mit Threads arbeitet, die's ja in JS nicht gibt. (Also so fühlt sich das für mich jedenfalls meistens an.)

Also warum nicht einfach ohne JS?!

An sich find' ich HTML und CSS gar nicht schlimm, also warum das ganze nicht mit was mächtigererem kombinieren? Beispielsweise mit der JVM? :o

Oder scheitert das Multithreading am DOM? Ich denk' selbst wenn das DOM nicht threadsicher ist, lässt sich doch noch genug Kraft aus Threads holen die nur stupide Daten verarbeiten und somit das UI flüssig halten. (Wobei, kommen hier bei JS Service Worker ins Spiel?)

Wie dem auch sei, HTML+CSS mit JVM wär' spannend. Allzu gern würd' ich dafür nen PoC machen...

Git, I guess?

Und weil das nicht genug ist: Git geht immer!

Da frag' ich mich gerade wie wichtig die vollständige History für Git ist.

Ich stell' mir das so vor, das nach einiger Zeit Kosten und Nutzen vom umherschleppen der ganzen History nicht mehr ausgewogen sind. Gerade wenn ich dann jetzt an umfangreiche Projekte denke: Das klonen des Repo schleift nach einiger Zeit doch so viel Zeug mit, das es irgendwann kein clone-hack-push mehr ist, weil clone soo viel laden muss.

Das lässt sich bestimmt durch ein init-and-fetch verbessern, aber auch da kommt ja die ganze History der Branch mit, die ggf dann so im Projekt verzweigt ist, das wieder alles runtergeladen wird.

Ich finde den Ansatz alles lokal zu machen gut, aber braucht es dafür die ganze, vollumfängliche History?

Aber es gibt ja GVFS (Git virtual file system).

Nun, das habe ich nicht vernünftig durchdacht. Ein ander' Mal dann.

Konfigurationsmanagement

Ich hätte ja gerne Software die Updates und neue Features voneinander trennt. Aber werd' langsam müde, ein anderes Mal mehr.

gn8!

Nachdem ich mich jetzt im Bett nur 3 Stunden unruhig hin- und hergerollt' hab', muss ich hier jetzt einfach ein paar Gedanken niederschreiben.

Git Components

Nachdem ich im Rahmen meiner Arbeit mit IBM's Rational Team Concert Source Code Management (oder Software Configuration Management, SCM jedenfalls) zu tun hatte habe ich mir überlegt wie sich wohl die Komponenten, wie es sie in RTC gibt, in Git umsetzen ließen.

Ich hab' da daran gedacht die Komponenten einfach einzelne Trees in der Datenbank abzulegen. Das Arbeitsverzeichnis vom Git Repository kann dann je nach Komponentenauswahl befüllt werden, Unterverzeichnisse im Arbeitsverzeichnis werden ja im Repo auch nur durch Trees abgelegt.

Die einzige Schwierigkeit hier ist dann wie Commits die sich über mehrere Komponenten-Trees erstrecken vernünftig für die einzelnen Komponenten umgesetzt werden. Das werd' ich mir nochmal in RTC angucken. Spontan würde ich ja nur in den jeweiligen Komponenten-Branches Commits anlegen.

Git Mono-Repo Hosting

Im Zusammenhang mit einer Hausarbeit für mein Studium habe ich mich mit Git Hosting beschäftigt. Im Vorfeld hatte ich mich auch schon mal mit Mono-Repo und Mono-Tree beschäftigt.

Im Rahmen der Arbeit habe ich dann unter anderem verstanden, dass die üblichen Verdächtigen (Git Hoster) nicht gut mit Mono-Repos umgehen können. (Vorher hatte ich dazu schon einen Artikel gelesen, kannte die Tatsache so also schon, mir fehlte aber noch das tiefere Verständnis.)

Jedenfalls habe ich mir dazu Gedanken gemacht und dabei eine Plattform modelliert wie ich sie mir vorstellen würde.

Für mich bestünde so ein Mono-Repo erst mal aus Komponenten (nicht zwingend in der gleichen Bedeutung wie im letzten Ansatz). Und die diese Komponenten würde dann alle ihren eigenen Issue/Bug-Tracker haben. Möglw gibt es auch einen zentralen Tracker aus dem dann die Tickets in die zugehörigen Komponenten verschoben werden könnten.

Ganz generell wäre die Startseite für so ein Repo der Komponenten-Baum abstatt des Quellcodes.

Was dann ne Komponente ist würde ich über eine .component-Datei oder ähnliches machen ^^
Und dann noch eine zentrale MAINTAINERS-Datei oder so.

Mehr Git!

Und weil ich eig 3/4 des Tages nur über Git nachdenke, sind da noch so ein paar Sachen...

Einerseits Pull/Merge-Requests von beliebigen Repositories. Und um der Notwendigkeit von nem eigenen öffentlichen Repo (des Contributors) aus dem Weg zu gehen dort auch gerne mit Push-Zugriff (auf die PR/MR).

Brauser Browser

Und da ich momentan etwas unzufriedem mit der Browserauswahl bin, wollt' ich nen eigenen Browser machen... nja. :D

Sonstiges

Ansonsten habe ich mir noch Gedanken darum gemacht, wie ich am besten nen (Web-)Service modelliere. So YAML oder JSON schreiben dafür ist jetzt nicht soo geil zur Modellierung, daher dachte ich dann an UML, aber da's da kein vernünftiges Austauschformat gibt bist du da direkt nen proprierären Hersteller gebunden -.-

Und da es mich ärgert (zutiefst!) das TomEE keine JAXB-JSON Serialisierung anbietet, überlege ich ob ich den iwie anders bauen kann, mit JAXB-JSON. (Ich will keine extra Johnzon-Annotations haben. Letztendlich ist das auch proprietär, auch wenn's frei Software ist. Wozu gibt es denn eig JAXB?! Mag ja sein das's für XML gedacht ist, aber letzendlich ist Serialisierung doch Serialisierung? Nja, fairerweise sollte ich auch sagen, dass in der EE Spezifikation das wohl nicht geregelt ist.)

Und ansonsten bin ich voll dabei in meinem Kopf virtuell die ganze Abteilung in der ich momentan arbeite umzustrukturieren und Prozesse zu verbessern... das hilft auch nicht sonderlich beim Schlafen.

Genug hab' ich nie, darum mache ich mir auch noch Gedanken um ein Werkzeug das mir vernünftig meine Musik-Bibliothek organisiert. Ich will da was leichtgewichtiges, iwas auf der Befehlszeile. Was mir meine Musik von Bandcamp runterlädt und dann Album-Shuffle Playlisten für meine Player macht (cmus am Notebook zu hause, die Stock-Musik-App von meinem Ubuntu Phone und Clementine auf'm Arbeitslaptop.). Und dann am besten noch die zwischen den Geräten passend kodiert synchronisiert. (Ohne Cloud, einfach Peer-to-Peer.)

Ach, und dann ist da noch mein MSYS2 auf'm Arbeitslaptop (Win7), da will ich auch noch ein paar Sachen besser regeln. (v.a. wo die Daten liegen und die provisionierung mit nativen Tools, mag da flexibel sein.)

Hach und so viel mehr noch.
Zum Glück werd' ich jetzt langsam (laaaangsam) müde \o/

Gut' Nacht.