HOSTBLOGGER.de

Blog-Leser Jan-Luca hatte mich darauf hingewiesen, dass es hier keinen Link mehr zum RSS-Feed gab. In der Tat benutzt das kaum noch jemand, dennoch habe ich ihn wieder in den Footer aufgenommen.

Und wer nicht runterscrollen möchte:

https://www.hostblogger.de/blog/rss.php

Danke nochmal, Jan-Luca!

Update 29.12.2020 10:32 Uhr
Ich lasse den RSS-Feed natürlich bestehen, keine Sorge

Wie immer habe ich die Weihnachtspost persönlich beantwortet. Dieses Jahr war es so viel, dass ich es nicht mehr komplett vor den Feiertagen geschafft habe.

Irgendwann brauche ich einen Ghost-Writer

Und um mal etwas die Statistiker zu erfreuen: Es antworten deutlich mehr Frauen auf unser Weihnachtsmailing als Männer. Konkret haben wir unter unseren Kunden ein Verhältnis w zu m von 1:3,7. Unter den Weihnachtsmailing-Antwortenden ist es 1:2,5.

Das merke ich beim Antworten durchaus, und der Antwortstil ist auch anders. Und: Man merkt ein Nord-Süd-Gefälle. Und ich würde jetzt fast wetten, dass man die Länge der Antwort-Mails auch in eine Nord-Süd-Relation setzen könnte

Ich wünsche Euch allen, Euren Familien und all' Euren Liebsten ein frohes und vor allem gesundes Weihnachtsfest.

Da ich auch zwischen den Tagen im Büro sein werde, gibt es die Neujahrsgrüße getrennt

Ein lieber und treuer Kunde hatte uns 5 kg (!) Süßigkeiten geschickt:


So sieht das nach wenigen Tagen bei uns aus


An dieser Stelle nochmals vielen lieben Dank, Peter! Wir haben uns sehr gefreut!

Ich äußere mich in der Tat hier selten politisch, und noch seltener derart emotional, wie ich es heute tun werde.

Wie man auf diversen Nachrichten-Seiten lesen kann (z.B. hier), sollen während des ab Mittwoch geltenden Lockdowns auch Baumärkte geschlossen werden.

Ohne den nötigen Respekt: Diese Idioten, die sich das ausgedacht haben, haben vermutlich noch nie irgendetwas handwerklich geleistet. Die können sich vermutlich gar nicht vorstellen, wie man zu Hause selbst etwas repariert, was ggf. gar nicht bis Januar warten kann. Was wäre wohl deren Antwort, wenn man sie danach fragen würde? "Handwerker rufen"? Ganz wunderbar! Erstens sind die eh schon chronisch ausgelastet, zweitens überteuert.

Dass Menschen in Baumärkten nicht (nur) Wellness-Shopping betreiben, sondern z.B. Dinge einkaufen, um Arbeit und Beschäftigung über die Feiertage zu haben, weil sie eben sonst (draußen) nichts zu erledigen haben, kann sich unsere Politik offenbar mangels Hirnmasse auch nicht vorstellen.

UNFASSBAR!

Update 16.12.2020 08:58
Wie ich erfahren habe, ist zumindest hier im Saarland Click&Collect bei Baumärkten (entgegen erster Aussagen!) zulässig und wird auch genutzt.

Damit ist, wie ich finde, ein fairer Kompromiss, wenn auch etwas zu spät kommuniziert, gefunden, der das Nötige auf der einen wie das Nötige auf der anderen Seite in eine Relation stellt.

Damit ziehe ich meine Kritik zurück (abgesehen von der späten Kommunikation, dass das erlaubt ist).

Auf mehrfachen Wunsch hin hier der manitu Kalender 2021 auch wieder als PDF:

Kalender 2021 als PDF

Damit noch mehr Weihnachtsstimmung aufkommt, haben wir etwas dekoriert:






Vielen lieben Dank an die fleißigen Dekorateure und Bäcker

Seit einiger Zeit haben wir ja PostgreSQL bei uns im Webhosting im Angebot.

Kurz danach erreichte uns dieses Buch mit einer sehr schönen, wunderbaren und handgeschriebenen Widmung, über die wir uns sehr gefreut haben:




Um bewusst keine Werbung für den ein oder anderen Buchhändler zu machen, hier nur der Vollständigkeit halber die ISBN: 9783752967340.

An dieser Stelle nochmals herzlichen Dank an Mark Lorenz!

Unsere Kalender für 2021 sind druckfrisch eingetroffen:


Wir verschenken unsere Kalender (es fallen lediglich Versandkosten an).

Wer möchte, kann seinen (gerne auch mehrere) in unserem Fan-Shop bestellen:

manitu Fan-Shop

Ausgelöst durch die aktuelle Situation und untermauert durch die wohl kommende Corona-Verordnung im Saarland werden wir dieses Jahr auf unsere Weihnachtsfeier verzichten.

Ich hätte diese durchaus gerne - unter Zuhilfenahme des angekündigten Schnelltests - durchgeführt, aber vermutlich werden wir einerseits juristisch nicht sauber durchführen können, und vermutlich würde auch immer ein Rest-Unwohlgefühl bleiben.

Daher gilt: Aufgeschoben ist nicht aufgehoben.

Ob man es glaubt oder nicht: Für 5 Euro sagt einem DHL & Co. quasi in Echtzeit, wo ein Paket gerade ist, wann es voraussichtlich ankommt (und das klappt meiner Erfahrung nach recht gut - man beachte die Anzahl an Paketen, die jeden Tag umgesetzt werden!) etc. pp.

Da könnten sich deutsche Automobilhersteller bzw. deren Logistikpartner ein Scheibchen abschneiden.

Und jeder schiebt es auf Corona. Das dürfte wohl die meistgenutzte Ausrede im Jahr 2020 sein.

Wenn ich mir die neuesten Ideen unserer Politiker so ansehe, stehen mir die Haare zu Berge.

Wenn jeder, der einen leichten Schnupfen hat, nicht nur zu Hause bleibt (was ich okay finde), sondern auch quasi standardmäßig krankgeschrieben wird, bin ich gespannt, wer demnächst die Räder in unserem Land am Laufen hält.

Ich habe ja noch die Hoffnung, dass in den diversen Presseartikeln der Part fehlt, dass die Krankschreibung nicht der Standard-Fall sein sondern dass das Homeoffice die erste Wahl bleiben soll. Denn beides zusammen wird arbeitsrechtlich schwierig.

Zwei eifrige Twitter-(aber noch-nicht Blog-)Leser hatten mich (privat) nach diesem Tweet nach ein paar Interna über unsere API gefragt - genauer gesagt, was wir intern als API-Format einsetzen. Gerne - Here we go.

Und da ich gestern ja schon meine Meinung über XML geschrieben hatte, tue ich das an dieser Stelle gerne auch für REST. So einfach eine REST-basierte API ja auf den ersten Blick ist, hat dieses "Format" in meinen Augen einige Schwächen.

Zum einen finde ich es gruselig, das Konzept von CRUD (Create, Read, Update, Delete) in http-Methoden (GET, POST, PUT, DELETE) zu packen. Auch wenn es für die meisten Fälle ausreicht, ist man dennoch irgendwie beschränkt. Und nicht alles lässt sich logisch matchen.

Das Ergebnis der API-Aktion in einen http-Fehlercode zu packen, finde ich ebenso unschön, um nicht wieder gruselig zu schreiben. Ich finde, man sollte klar zwischen Fehlercode auf Transport-Ebene (stimmt nicht ganz, aber nennen wir es mal so), und dem auf API-Ebene unterscheiden. Und demnach kann ein "200 OK" auf http-Ebene durchaus ein negatives API-Ergebnis enthalten.

Es gäbe jetzt durchaus bekannte Alternativen, eine davon ist JSON:API. Aber auch dieses Format halte ich für nicht wirklich praktikabel. Es bildet z.B. keinerlei Authorisation und Authentifikation ab. Und über das Layout kann man durchaus diskutieren, und evtl. auch schmunzeln.

Wir haben uns daher für uns intern für ein auf JSON basierendes Format entschieden, das Wert auf Praktikabilität und Sicherheit legt. Unter anderem war uns wichtig, interne API-Anfragen mit Keys zu signieren und diese gegen Replay-Attacken abzusichern.

Wie man nun die einzelnen JSON-Elemente nennt, ist dabei eher Geschmackssache. Wir haben uns hier intern etwas mit "auth", "action" und "payload" als Anfrage sowie "auth", "status" und "payload" als Antwort ausgedacht. Funktioniert sehr simpel, effektiv und ist dennoch sicher.

Vielleicht mag der ein oder andere, der auch etwas Eigenes implementieren möchte, sich ja daran orientieren.

Seit heute haben wir (noch rechtzeitig für die Deadline am 24.11.2020) automatisch für alle Rechnungen und Gutschriften die e-Rechnung gemäß EN 16931 (auch Factur-X oder ZUGFeRD) implementiert. Sprich alle PDF-Rechnungen enthalten eine Datei "factur-x.xml" mit den nötigen Angaben, wie sie öffentliche Auftraggeber etc. künftig zwingend erfordern.

Klingt ersteinmal unspannend, ist es vermutlich auch. Wäre da nicht dieses - und jetzt lehne ich mich einmal weit aus dem Fenster - dämliche XML-Format, was sich vermutlich nur viel zu gut bezahlte Berater ausgedacht haben können, die niemals auch nur eine Zeile Code erstellt haben.

Was die Ausgedenkt-Habenden sich da zusammengebastelt haben, mag zwar wie ein brauchbares und wunderbar auf hunderten Seiten dokumentiertes Format aussehen, es geht in meinen Augen jedoch an der üblichen Praxis vorbei. Nicht, dass ich XML nicht mag (ich mag es nicht!).

Aber dass man im Jahr 2020 (fast 2021), wo es nicht unbedingt auf ein paar Zeichen ankommt, z.B. Zahlungsweisen in Codes angibt, tut meinem Programmierer-Herz weh. Wäre eine Angabe wie "sepa_directdebit" statt "49" nicht vielleicht doch besser (aka intuitiver) gewesen?

Ganz zu schweigen von den vorhandenen Validatoren, die zwar inoffiziell sind, aber allesamt gerade bei Fehlern oft wenig aussagekräftig sind (eine Nennung der Verletzung des XML-Schemas bringt einen da selten weiter), und selbst nicht mit allem klarkommen, was sogar teilweise in der offiziellen Dokumentation als Beispiel-PDFs mitgeliefert wird. Hmpf.

Ganz zu schweigen davon, dass das Format bestimmte Spezialfälle (unterschiedliche MwSt-Sätze in einer Rechnung für mehr als 1 Land) so gar nicht abbilden kann. Aber das ist dann wohl Sorge des Empfängers, das verbuchen zu können.

Ich glaube, man hätte sich ein für den "Normal-Fall" einfacheres Format in einer zeitgemäßen Notation (ich präferiere ja JSON) einfallen lassen können, das im Endeffekt lesbarer und vermutlich nur halb so groß gewesen wäre. Aber das hätte ja den großen Playern der Branche, die Abrechnungs-Leistungen anbieten, nicht in die Hände gespielt.

Auf wirklich vielfachen Wunsch hin haben wir heute die Möglichkeit, Postgres-Datenbanken bei uns im Webhosting anzulegen, als Beta freigeschaltet.

Prinzipiell funktioniert bereits alles, wie es später im Produktivbetrieb sein wird, lediglich die Verfügbarkeit der Datenbanken kann noch etwas variieren, und wir fertigen noch keine Backups etc. an.

Daher bitte wirklich nur zum Testen verwenden, oder wenn die Daten nicht wichtig sind.

Ich hoffe, dass wir Euch damit eine Freude machen konnten.