Bei jedem Mac Os Update vergisst der Mac einige relevante Einstellungen. In diesem Artikel sammle ich die Befehle, mit denen ich den Zustand herstellen kann, den ich von meinem Mac erwarte.

Mir ist klar, dass ich das ganze auch in Scripte gießen kann, aber spätestens, wenn das System komplett neu aufgesetzt wird, kann ich diese Gedankenstütze hier brauchen.

Der Artikel wird bei neuen Erkentnissen aktualisiert.

.DS_Store

Nach jedem Update hinterlässt der Mac (genauer: der Finder) in allen möglichen Verzeichnissen diese hässlichen Ordner. Besonders nervig ist das, wenn man in Repositories oder auf Netzlaufwerken unterwegs ist.

Mit dem folgenden Befehl kann er daran gehindert werden:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

SMB v2 erzwingen

Ob der Mac bei einem Update wirklich vergisst wie man mit der Fritzbox redet, weiß ich noch nicht. Nach dem letzten Update war es jedenfalls notwendig, die folgenden Zeilen in die /etc/nsmb.conf zu schreiben:

[default] protocol_vers_map=2

TBC!

Vor einigen Tagen musste ein kleines Projekt unter recht hohem Zeitdruck erstellt werden. Ich kann garnicht mehr zählen, wie oft ich Projekte erstellt habe und wie oft ich dabei die immer gleichen Schritte gegangen bin. Das kann dazu führen, dass Projekte die viel gemeinsam haben, sich deutlich voneinander unterscheiden können.

Ein Weg um sich die Arbeit und die Unterschiede zu ersparen, sind Vorlagen für Projekte. Hier muss darauf geachtet werden, wie spezifisch sie sein müssen und dürfen. Das Resultat meiner Überlegungen ist hier zu finden und kann als Beispiel dienen.

Da es sich um eine Vorlage für ein React-Projekt handelt, muss es den grundlegenden Anforderungen an React-Projekte genügen. So spezifisch muss es also mindstens sein.

Mir war wichtig, dass man schnell anfangen kann und die wesentlichen Dependencies mitgebracht werden. Aber auch nicht mehr!

"dependencies": {
                  "react": "^17.0.2",
                  "react-dom": "^17.0.2"
                },
                ...
                "devDependencies": {
                  "express": "^4.17.1",
                  "ts-loader": "^8.0.18",
                  "typescript": "^4.2.3",
                  "webpack": "^5.27.2",
                  "webpack-cli": "^4.5.0"
                }
                

Die package.json bringt in der tat eine Abhängigkeit mit, bei der nicht klar ist, ob sie hier hinein gehört: Express.

Als Webserver gehört es eigentlich nicht hier hinein. Allerdings war mir wichtig, dass ich die Seite die mit React erstellt wird schnell sehen kann. Dazu brauche ich einen Webserver. Sollte das Projekt auf einen anderen Server für das Backens setzen, so wird Express vermutlich schnell wieder entfernt. Hier ist die Vorlage also zu spezifisch.

Das Template darf gerne kopiert, verwendet und angepasst werden. Über Pull Requests auf Github freue ich mich ebenfalls!

Heute bin ich über ein Bild gestolpert, dass ein paar Leute in der Planking-Position zeigt. Die Bildbeschreibung besagt, dass man damit Meetings kurz halten könnte. Vergleichbare Bilder wurden mir häufig im Zusammenhang mit Stand Up Meetings gezeigt.

Ich bin mir nicht sicher, ob die ganze Sache ernst gemeint ist, kann es mir aber gut vorstellen. Ein weiteres Beispiel für eine Maßnahme mit der Meetingteilnehmer dazu gebracht werden sollen, sich knapp zu halten: Derjenige der an der Reihe ist, bekommt ein Streichholz und zündet es an. Er darf reden bis es abgebrannt ist.

Nicht ganz so abwegig erscheint dagegen die Idee, einen Timer zu stellen, der das Meeting nach 15 Minuten beendet. Wobei man hier die Frage stellen kann, warum das Meeting immer 15 Minuten dauern darf, egal ob es mit zwei oder 20 Teilnehmern stattfindet.

Vielleicht sollte man lieber die Ursache für zu lange Redezeiten in Stand Up Meetings suchen und beseitigen und/oder die Teilnahme für alle optional machen.

Ich denke, dass man in Stand Up Meetings die Teilnehmer in eine Situation bringt, in der sie sich gezwungen sehen, etwas sagen zu müssen, auch wenn sie nichts interessantes zu sagen haben. Der gleiche Mechanismus sorgt dafür, dass der Teilnehmer, der an der Reihe ist, länger redet als nötig ist.

Abstimmungen können sinnvoll sein, aber wenn man darüber nachdenken muss, Meetings mit Folter oder Feuer kurz zu halten, dann sollte vielleicht besser das Meeting abgeschafft werden.

Ich hatte zwar in der Vergangenheit mal ein iPhone, aber so richtig für Apple und seine Produkte erwärmen konnte ich mich nie. Aber mit dem M1-Prozessor haben sie den Nerd in mir erwischt. Nach langem hin und her sollte es also ein MacBook Air werden.

Mein erster äußerer Eindruck war geprägt von der geringen Größe. 13" konnte ich scheinbar nicht einschätzen. Das Ding ist wirklich klein. Aber gut, es kommt ja auf die inneren Werte an.

Die Einrichtung war wie erwartet ein Kinderspiel und auch Dinge die über das hinausgehen, was der normale Anwender tut waren recht einfach zu installieren.

Das Ziel meines ersten Abends mit dem Gerät war es, die folgenden Tools zu installieren und zum Laufen zu bringen:

• Postgres
• Python3
• Git
• Flask
• node.js

Die dafür notwendige Internetrecherche hielt sich in engen Grenzen und so konnte ich mit Hilfe von Homebrew nach etwa einer Stunde meine Checkliste an die Seite legen. Alles erledigt.

Die Steuerung ist gewöhnungsbedürftig. Ich wurde mit Windows sozialisiert und bin seit 15 Jahren Linuxnutzer und ein paar Sachen scheinen mir wirklich nicht sinnvoll. Warum ein Fenster einen eigenen Arbeitsbereich bekommt ist mir schleierhaft und wie ich zwischen mehreren Instanzen eines Programms wechseln kann erschließt sich mir auch noch nicht. Klar geht das alles, aber es ist nicht intuitiv.

An der Hardware gibt es erwartungsgemäß nichts auszusetzen. Alles top verarbeitet und wertig und -ganz wichtig und leider immer noch nicht selbstverständlich- keine Pixelfehler.

Ich hatte erwartet, dass ich mich als Linuxer einigermaßen schnell einarbeiten kann, was ich nicht erwartet hatte war, dass ich ein System vorfinde, dass nicht weiter von einem Ubuntu weg ist, als es beispielweise ein Red Hat ist.

Insgesamt also eine positive Erfahrung.

P.S. Auch das Erstellen und Deployen dieses Artikels mit dem Gerät war ohne Probleme möglich. Dazu benutze ich unter anderem make und scp. Auch hier war die Einrichtung und Konfiguration (für Ubuntu entwickelt) ohne Anpassungen möglich.

Auch wenn ich beruflich fast ausschließlich mit nicht statischen (also dynamischen) Seiten zu tun habe, will ich hier eine Lanze für statische Seiten brechen. Aber zunächst mal zu dem was ich unter statischen bzw. dynamischen Seiten verstehe:

Eine dynamische Seite ist jede Seite, die ein Backend hat das Inhalte dynamisch erzeugt und meistens ist dabei eine Datenbank involviert. In der Regel gibt es also eine Persistenzebene neben dem reinen HTML-Dokument.

Eine statische Seite kommt ohne diese zusätzliche Persistenzebene aus. Kurz gesagt: Eine statische Seite ist ein Dokument das von einem Autor geschrieben und bereitgestellt wird.

Mir ist klar, dass an statische Seiten nicht die gleichen Anforderungen gestellt werden dürfen wie an dynamische Seiten und jeder muss für sich selber herausfinden, ob für seine spezifischen Zwecke eine statische Seite ausreicht. Mir geht es vor allem darum, vor der Erstellung einer Webseite zu überlegen, welche Funktionalität benötigt wird und ob nicht eine statische Seite ausreichend sein könnte.

Ich habe bei vielen kleineren (meist privaten) Projekten die Erfahrung gemacht, dass statische Seiten eine echte Alternative zu dynamischen Seiten sein können. Diese Vorteile will ich im Folgeden durchgehen und im Anschluss auch die Nachteile nicht verschweigen. Die hier getroffenen Einschätzungen sind höchst subjektiv.

Vorteile

Sicherheit

Da statische Seiten ohne Backend auskommen sind die Angriffsmöglichkeiten beschränkt. Sofern die Seite öffentlich zugänglich ist, gibt es wenig Grund dafür einen Angriff auf die Seite zu unternehmen der über eine DOS-Attacke hinausgeht. SQL- und Script-Injection sind ausgeschlossen und Daten können auch keine geleakt werden.

Außerdem gibt es kein Backend welches regelmäßig aktualisiert werden müsste. Natürlich sollte die Infrastruktur (zu der ich den bereitstellenden Webserver zähle) auf einem aktuellen und gut konfigurierten Stand sein. Aber es müssen keine DBMS, Runtimes oder Frameworks gepflegt werden.

Fehlerfreiheit

Statische Seiten bieten wenig Gelegenheit für Fehler. Klar, Rechtschreibfehler wird man auch hier finden und vielleicht gibt es den einen oder anderen toten Link. Das alles ist aber nichts im Vergleich zum Fehlerpotential das dynamische Seiten in aller Regel aufweisen. Vielleicht ist Fehlerfreiheit hier also die falsche Überschrift, in jedem Fall haben Fehler aber deutlich unkritischere Auswirkungen als es bei dynamischen Seiten der Fall ist. Natürlich ist dieser Vorteil durch fehlende Funktionalität erkauft.

Schnelligkeit

Sofern nicht große Dateien Teil der statischen Seite sind, werden die Ladezeiten gering ausfallen. Da sich statische Seiten auch nur selten verändern, können Browser sie auch sehr gut cachen. Dieser Vorteil kann allerdings durch die Einbindung von Scripten auch schnell wieder verspielt werden.

Einfach zu erstellen

In der Regel sollte die Erstellung einer statischen Seite leicht von der Hand gehen. Selbst wenn man sich keiner Helferchen bedient. Auch hier gilt aber wieder: Wenn Funktionalität eingebaut wird oder das Design besonders hübsch ausfallen soll, dann kann dieser Vorteil schnell verloren gehen. Allerdings gilt das auch für dynamische Seiten.

In vielen Fällen ausreichend

Für rein informative Seiten die nicht den Anspruch haben mit dem Benutzer in Interaktion zu treten reichen statische Seiten in aller Regel aus. Eine Seite auf der sich z.B. ein Unternehmen vorstellt benötigt nicht zwingend ein CMS, da sich die Inhalte hier nicht häufig ändern werden.

Datenschutzrechtlich unbedenklich

Vorausgesetzt der Webserver ist entsprechend konfiguriert (Stichowrt IP-Adressen in Log Files) und es werden keine Fremdinhalte eingebunden oder Dinge wie Reichweitenmessung unternommen, reicht bei einer statischen Webseite eine entsprechende Datenschutzerklärung um alle DSGVO-Ängste zu zerstreuen.

Nachteile

Keine Interaktion mit Nutzern

Es liegt in der Natur statischer Seiten, dass eine Interaktion mit dem Betrachter einer statischen Seite ohne Umwege nicht möglich ist. Kommentare zu diesem Artikel hier können nur auf Fremdplattformen abgegeben werden. Das ist der Reichweite dieses Artikels sicher nicht zuträglich.

Unflexibel bei Anpassungen

Nachdem der Artikel morgen online gegangen ist und ich ihn mir das erste mal unterwegs mit dem Handy ansehe, werde ich zahlreiche Rechtschreibfehler feststellen. Diese dann zu korrigieren ist mit dem Handy zwar möglich, aber keine Freude (Quelldatei mit dem VIM direkt auf dem Server editieren, etc.). An dieser Stelle werde ich mir die Möglichkeit wünschen den Artikel mit Hilfe eines Formulars zu bearbeiten.

Fazit

Statische Seiten sollten immer dann verwendet werden, wenn keine Interaktion mit dem Anwender nötig ist oder Daten gespeichert werden sollen. Hier können Seiten mit speziellen Aufgaben besonders in betracht kommen. Ein Beispiel für eine solche Seite könnten Dokumentationsseiten für Software sein. Hier ist in der Regel keine Interaktion mit dem Nutzer nötig.

Statische Seiten sind eine gutes Beispiel für das gelebte KISS-Prinzip. Wenn eine statische Seite ausreicht um ihren Zweck zu erfüllen, gibt es keinen Grund sie mit einem Backend und dynamischen Inhalten aufzublasen.

Helferchen

Nur weil eine Seite für den Nutzer statisch ist, heißt das nicht, dass die Erzeugung der Seite nicht dynamisch sein kann. Diese Seite hier wurde mit einem Satz von Scripten Anvil erzeugt, die auf Jinja und Less zurückgreifen um die Vorteile von Templating und dynamisch erzeugtem CSS zu nutzen. Das Resultat ist zwar eine Reihe von HTML- und CSS-Dateien, während der Erstellung kann aber z.B. Coderedundanz vermieden werden.