HOSTBLOGGER.de

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.

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.

Ich habe mir in den letzten Tagen und Wochen viele Gedanken um unsere jährliche Weihnachtsfeier gemacht.

Wie sich jeder vorstellen kann, gibt es eine ganze Reihe von Pro- und Contra-Argumenten. Ich erpare Euch (und mir ), diese aufzuführen. Letztendlich ist es derzeit wohl (noch) eher eine Frage der eigenen Meinung und Haltung.

Unter der Prämisse, dass es die gesetzliche und die epidemiologische Lage sowie der gesunde Menschenverstand es Anfang Dezember zulassen, werden wir dieses Jahr erstmals unsere Weihnachtsfeier hier im Haus stattfinden lassen. Und auch für das Catering werden wir kollektiv selbst sorgen (wobei ich persönlich einen großen Teil selbst stellen werde - dazu später einmal mehr).

Da wir danach nicht als Superspreader-Event in den Medien genannt werden wollen , haben wir uns dazu entschlossen, an diesem Tag einen für alle freiwilligen (!) (und kostenlosen) Corona-Schnelltest zu machen. Eine kleine Blitzumfrage unter allen hier hat ergeben, dass alle gerne dazu bereit sind.

So wird - sofern alles wie geplant läuft - am Tag unserer Weihnachtsfeier medizinisches Personal hier auflaufen und einen Test mit uns machen. Irgendwie glaube ich sogar, dass das sogar ganz "lustig" werden kann (besondere Zeiten - besondere Umstände), und vor allem, dass ein Negativ-Ergebnis uns allesamt etwas entspannter werden lässt.

Um gleich einiger Kritik zu begegnen:

1. Der Test ist wirklich freiwillig. Wer nicht möchte, darf ohne wenn und aber trotzdem kommen.

2. Der Test wird von uns als Firma bezahlt, und nicht über die Krankenkassen abgerechnet. Auch das medizinische Personal wird von uns bezahlt.

3. Ich weiß, dass der Test nicht 100% ist, weder in die eine noch die andere Richtung. Ich finde, das sollte in Verbindung mit Vernunft und weiteren Hygiene-Maßnahmen dennoch einen guten Schutz bieten.

4. Wir werden trotz eines Negativ-Ergebnisses dafür sorgen, dass wir mit noch mehr Abstand, Hygiene und Lüften für ein minimal mögliches Risiko sorgen.

Und jetzt auf zu den Kommentaren

Hier ein Erfahrungsbericht eines Kunden, was er bei einem anderen Hoster erlebt hat. Er hat mir explizit die Veröffentlichung gestattet (dafür vielen Dank):

Ich hatte dort einen VServer für meine Programmier-Experimente und wollte in einen aktuellen Tarif wechseln (Mehr Speicher, Mehr Cores, bessere Preis-Leistung). Nachdem ich mein gebuchtes Paket in keine Richtung upgraden oder downgraden konnte, habe ich bei der Hotline angerufen. "Upgrade oder Downgrade ist nicht möglich". Ja wieso haben Sie denn die Knöpfe dafür auf der Weboberfläche? Konnte keiner so richtig erklären. Nur der Hinweis das die nicht funktionieren. Dann kam der Profitipp: Neues Paket bestellen, altes stornieren. Zur Not. Mit monatlicher Laufzeit ist das aushaltbar. Dann kam die Schippe drauf: "Die Domain können Sie aber nur zwischen den Paketen übertragen, wenn Sie 20 Euro Übertragungsgebühr bezahlen". Dann kam meine Rückfrage: "Für eine Übertragung meiner eigenen Domain zwischen zwei Paketen, die ich parallel bezahle muss ich eine Servicepauschale bezahlen? Gibt es einen Grund?". "Die Kunden haben damals immer die Domains zwischen den Paketen hin und hergeschubst. Das haben wir damit unterbunden". Wahrscheinlich weil man sein VServer Paket nicht upgraden kann =) Mein Ankündigung mir Gedanken über meine Geschäftsbeziehung mit den Kollegen zu machen wurde mit einem "Ja" entgegengenommen. Traurig, dass man Kunden (die seit dem 25.12.2018 monatlich 8 Euro ohne zu Murren bezahlen) so in den Hintern tritt.

Kurzum: Gestern habe ich den ganzen Bims gekündigt und meine Domain zu euch gerettet.

Vor einiger Zeit erhielt ich von einem Nicht-Kunden aber Blog-Leser ein paar wertvolle Hinweise bzgl. unserer Webseite, wofür ich mich überraschenderweise mit einem manitu Care-Paket bedankt hatte.

Darauf hin kam der "Beweis", dass die Tasse gut angekommen und gut angenommen ist:

Seit einigen Tagen bieten wir in unseren Webhosting-Paketen die Möglichkeit, eigene Cronjobs anzulegen.

Die Konfiguration erfolgt bequem via Kunden-Menü. Es stehen verschiedene Arten von Befehlen (direkter Bash-Befehl, PHP-Skript oder auch URL abrufen) zur Verfügung. Auf Wunsch kann ein umfangreiches Reporting via E-Mail oder Log-Datei erfolgen.

Damit haben wir einen häufig geäußerten Wunsch unserer Kunden und derer, die es noch werden wollen, umgesetzt.

Mehr auf unserer Webseite.

Ich habe lange mit mir gerungen, ob ich - wie jedes Jahr - für manitu am Service Provider Summit teilnehmen soll.

Es waren jedes Jahr 2 erfolgreiche und tolle Tage mit vielen bekannten Gesichtern aus der Branche, die meisten trifft man quasi nur einmal im Jahr. Auch die Tatsache, dass wir wieder für die Awards nominiert sind und auf einen Preis hoffen können, macht(e) die Überlegung nicht einfacher.

Letztendlich habe ich mich jedoch gegen eine Teilnahme entschieden. Die Gründe liegen auf der Hand: Die aktuelle Corona-Situation.

Wir alle müssen uns an der ein oder anderen Stelle in etwas Verzicht üben, gerade wenn es um nicht notwendige Reisen und Veranstaltungen geht. Ob und für wen welche Veranstaltung notwendig ist, muss jeder einzelne für sich selbst entscheiden.

Ich habe für mich entschieden, dass ein Summit, bei dem es gerade um Kontakt-Suchen und -Finden geht, trotz oder auch gerade wegen des Hygiene-Konzepts eben nicht mehr das ist, was er in normalen Zeiten wäre. Es wäre für mich angespannt und unentspannt, ohne die Freude, die dieses Event jedes Jahr mit sich gebracht hat.

Ganz abgesehen davon, dass ich es mir nicht verzeihen würde, wenn ich von dort eine Infektion mit nach Hause bringen würde, und ich diese ggf. sogar an Menschen in meinem beruflichen und privaten Umfeld weitergeben würde.

Ich habe daher meine Teilnahme kurzfristig abgesagt, dem Veranstalter aber zugesichert, gerne die Teilnahmegebühr zahlen zu wollen - quasi als kleine Form der Wirtschaftsförderung.

Heute vor 23 Jahren begann die Geschichte von manitu.

Ich bin jeden einzelnen Tag glücklich, damals die Entscheidung der Selbständigkeit getroffen zu haben. Mit manitu habe ich mir alle meine (beruflichen) Wünsche erfüllt.

Alles, was ich damals zum 20-Jährigen Jubiliäum geschrieben habe, gilt uneingeschränkt und weiterhin!

Auf die nächsten 23 Jahre!

Aufgrund der eindringlichen Warnungen in den Kommentaren haben wir bei unserem neuen Feature "E-Mails im Webhosting direkt löschen oder abweisen" beim direkten Löschen (für unser Webhosting) eine Warnung und eine zusätzliche Bestätigung eingebaut: