Boehrsi.de - IT und Gaming Blog

Neben der reinen Performance durch z.B. die CPU, sind auch sekundäre Komponenten maßgeblich an der Geschwindigkeit und guten Nutzbarkeit des Systems beteiligt. Heute geht es deswegen um meine Speichermedien. Mehr Speicherplatz ist dabei immer gut, aber manchmal ist schnellerer Speicherplatz das was man eigentlich brauch. Mit diesen Gedanken im Hinterkopf habe ich die Samsung 970 EVO Plus NVMe M.2 SSD (500 GB) open_in_new als meine Systemplatte gewählt und meine Arbeitsdaten (Softwareentwicklung, Videoschnitt usw.) liegen von nun an auf einer Crucial MX500 SSD (1 TB) open_in_new.

Zuletzt gab es relevante Informationen zum meinem ASUS TUF Gaming X570-Plus Mainboard und heute geht es weiter mit meiner CPU und Kühlung. Hier setze ich auf einen AMD Ryzen 7 5800X open_in_new, welcher sowohl fürs Gaming, wie auch für die Softwareentwicklung, Videoschnitt und andere Dinge die ich mit meinem Rechner erledige hervorragend geeignet ist.
Zur Kühlung setze ich eine Arctic Liquid Freezer II 280 open_in_new AIO ein. Dies ist meine erste AIO und ich bin sehr froh diese Entscheidung getroffen zu haben. Während ich in Windows bin und das System normal nutze ist die CPU bei unter 40° und während ich z.B. Battlefield 2042 spiele, welches ja durchaus Interesse an der CPU hat, liegt die Temperatur bei unter 50°. Diese Werte sind meiner Meinung nach extrem gut, vor allem wenn man bedenkt das unter anderem mit einer AMD Radeon RX 6800 XT weitere Komponenten im System sind, die die Temperatur generell hochtreiben. Die AIO habe ich aus Platzgründen vorne im Gehäuse verbaut, fahre damit aber auch sehr gut. Der Luftfluss ist gut, die anderen Komponenten erhalten trotzdem genug kühle Luft und die warme Abluft kann nach oben und hinten abgeleitet werden.

Nachdem ich zuletzt über die Beschaffung der Komponenten gesprochen habe, fange ich heute mit der eigentliche Hardware an. Dort macht das ASUS TUF Gaming X570-Plus Mainboard open_in_new den Anfang. Ich bin seit mehr als 15 Jahren mit Asus Mainboards unterwegs und hatte bis dato noch nie Probleme, deswegen fiel die finale Entscheidung auch auf dieses Board. Im direkten Vergleich gab es ansonsten noch das Gigabyte X570 Aorus Elite open_in_new.
Das Mainboard verfügte über alle von mir benötigten Anschlüsse, einzig ein Header für USB-C ist nicht vorhanden. Beim Kauf war mir dies bewusst, dass es aber so aufwendig ist eine Front USB-C Erweiterungskarte open_in_new mit dem nötigen Header und dann auch noch ein Verlängerungskabel dafür zu bekommen, hätte ich nicht erwartet. Doch erst einmal zurück zum Mainboard. Alle Amazon Links sind Affiliate- / Partner-Links die meinen Blog unterstützen.

In den letzten Wochen und vor allem Tagen habe ich relativ umfangreich an der Tessa App weitergearbeitet und das Resultat ist der Release von Version 1.2.0. Die neue Version bringt meiner in Flutter entwickelten Android App unter anderem die folgenden neuen Funktionen.

• Wiederkehrende Ereignisse
• Ausrüstungsliste
• Bilder in Pferdeorganisationslisten
• Bilder können gelöscht werden

Zusätzlich wurden diverse kleine Fehler behoben, welche z.B. die Premium-Kaufen Funktion, das Bearbeiten von Bildern und den Dateiimport negativ beeinflussten. Im Bereich der Verbesserungen gibt es eine schnellere Suche, der Splash Screen wurde überarbeitet und das User Interface hat generell die eine oder andere Verbesserung erhalten.
Die neue Version ist ab jetzt im Play Store verfügbar. Den Link findet ihr in den Related Links. Nachdem dieses Update relativ lange in Entwicklung war, sind neue Versionen nun wieder mindestens einmal im Quartal zu erwarten. Solltet ihr Wünsche, Feedback oder ähnliches haben, meldet euch gerne direkt hier in den Kommentaren.
Weitere Informationen findet ihr im Projektbereich hier im Blog oder auf der neu erstellten kleinen Webseite für die App oder direkt im Play Store.

Related Links

• Tessa - Reit-Assistent bei Google Play open_in_new
• Tessa - Reit-Assistent im Projektebereich open_in_new
• Tessa - Reit-Assitent Webseite open_in_new

Ich nutze Git sehr gerne und mittlerweile liegen quasi alle meine Projekte in einem Repository (Remote). Dies betrifft sowohl Code, wie auch textuellen Content und Bilder. Lediglich Daten die im Kontext der Videobearbeitung entstehen sind ausgenommen, da ich sehr große Binaries ungern im Git habe.
Das Ganze läuft so gut, dass ich fast über meine eigenen Flows gestolpert wäre. Damit gemeint ist, dass ich alle Daten im Git ablege und wenn ich etwas lokal lösche oder fälschlicherweise bearbeite stellt dies ja kein Problem dar, denn die Daten sind ja noch im Git und somit habe ich quasi ein implizites Backup.
Genau dieses “alle Daten” ist aber nicht korrekt und hier möchte ich noch einmal etwas die Wahrnehmung schärfen, sowohl von mir selbst, wie auch von euch. Es geht z.B. um Keys, lokale Konfigurationsdateien und jegliche Secrets, welche einfach nicht in einem Git liegen sollten, egal ob privat oder öffentlich. In meinem Fall ging es um Konfigurationsdateien für das Bauen und Signieren meiner Android Apps. Denn zur Zeit bereite ich einen App Release vor, merkte aber gestern ein Release Build ist derzeit nicht möglich. Grund dafür war das Fehlen besagter Dateien. Diese gingen im Rahmen der Neuinstallation meines Systems vor einigen Monaten verloren und wurden beim folgenden Setup nicht wieder hergestellt, denn dort richtete ich lediglich das Git wieder ein.
Es gilt also mal wieder, egal ob man ein Git Repository oder eine andere Versionsverwaltungssoftware nutzt, egal wie man seine Daten verwaltet und egal wie sehr man davon ausgeht das man auf der sicheren Seite ist, Backups bleiben ein muss. Mir haben selbige einiges an Arbeit erspart, denn irgendwelche Passwörter und Keys zurückzusetzen ist etwas worauf ich so gar keine Lust habe, geschweige denn die Zeit. Insofern beleibt mir als Lesson learned nur zu sagen, dass das nutzen eines Git Repositories für mich die Entwicklung und Datenhaltung massiv verbessert, aber eben nicht den Bedarf reduziert regelmäßige Backups zu erstellen.

Ich nutze mein neues System nun seit ca. 5 Monaten aktiv und denke ich habe jetzt ausreichend lange mit selbigem gearbeitet, um sagen zu können das alles läuft. Entsprechend möchte ich nun das eine oder andere Wort über mein neues Setup verlieren. Ich werde dabei keine umfangreichen Benchmarks durchführen und euch mit Zahlen bewerfen. Dies tun andere wesentlich besser und vor allem mit diversen Vergleichssystemen, ohne welche Benchmark-Ergebnisse ohnehin nicht aussagekräftig wären.
Ich denke allerdings trotzdem, dass es das eine oder andere interessante für euch geben könnte. Den Anfang mache ich heute mit dem eigentlichen Weg zur Hardware, denn selbiger ist in den heutigen Zeiten ja durchaus speziell, sofern man nicht den doppelten Preis für bestimmte Komponenten zahlen möchte.

Ich bin Softwareentwickler und ich nutze Java. Laut Twitter müsste ich mich nun schlecht fühlen, doch überraschenderweise ist dies gar nicht der Fall. Doch warum schreibe ich so etwas überhaupt? Im Rahmen der als Log4shell open_in_new bekannten Sicherheitslücke, in der weit verbreiteten Java Library Apache Log4j 2 open_in_new, gab es natürlich auch diverse verallgemeinerte undifferenzierte Aufrufe Java zu verteufeln. Dabei will ich vorab klarstellen das Java bei weitem nicht das Allheilmittel für die Probleme der Softwarewelt ist, aber eben auch nicht die grundlegende Quelle all dieser.

In der Softwareentwicklung und auch als Serverbetreiber ist das Thema Sicherheit natürlich allgegenwärtig. Sicherheitsmaßnahmen wollen eingerichtet und getestet werden. Dafür hat man verschiedene Wege und nachdem die initialen Tests bestanden sind, läuft dann meist alles im alltäglichen Flow weiter.
Zusätzlich zu diesen Abläufen testete ich gestern eher unfreiwillig eine der Sicherheitsmaßnahmen meines Servers. Es geht um Fail2Ban open_in_new, ein Tool welches gegen Brute-Force Angriffe auf Logins und ähnliches schützen soll. Ein kleines feines und unkompliziertes Tool, welches ich gerne als zusätzlichen Sicherheits-Layer betreibe.
Nun hatte ich gestern zwar nicht vor zu prüfen ob Fail2Ban ordentlich läuft, tat es aber trotzdem. In diesem Rahmen war Abends mein Server plötzlich nicht mehr zu erreichen und ich fragte mich wo das Problem liegen könnte. Jegliche Verbindungen meinerseits endeten in Fehlern. Nach ein paar kurzen Nachfragen stellte sich aber heraus, dass nur ich direkt betroffen war, es also gar keinen Ausfall gab. Ein paar weitere Nachforschungen offenbarten dann das Problem. Ein altes Smartphone, welches ich zum Debugging während der Entwicklung genutzt hatte.

Seit ca. einem Monat bin ich nun mit meinem neuen System unterwegs und bin bis dato sehr zufrieden. Zwei kleine Erweiterungen gab es noch an der Hardware, welche ich hier in aktualisierte Form niedergeschrieben habe. Zum einen habe ich mir eine 1 TB SSD für meine Arbeitsdaten zulegt und zusätzlich brauchte ich noch ein Verlängerungskabel für meine interne USB-C Erweiterungskarte, wobei sich letzteres erstaunlich kompliziert gestaltete.
Alles in allem ist das System nun aber aktiv und läuft problemlos, nach wenigen Abstürzen, sowie kurzzeitigen Schwierigkeiten mit der Erkennung der GPU. Einige Temperatur- und Lasttests führten zu stabilen Ergebnissen, dedizierte Benchmarks habe ich nicht durchgeführt, da ich selbige nicht sonderlich hilfreich finde.

Es ist schon etwas länger her das in dieser Sammlung etwas geschrieben wurde, aber nun wird es mal wieder Zeit. Denn nach einem durchaus ausführlichen Gespräch mit einem guten Freund und Entwicklerkollegen, hab ich mal wieder neues Lesematerial für euch.
Heute geht es um das Thema Over-Engineering und das in verschiedenen Formen. Den Anfang macht dabei die oft angepriesene nutzerzentrierte Entwicklung von Anwendungen. Ein schönes Buzzword, welches quasi immer im Raum steht bei Anwendungen die für Endanwender gedacht sind, aber sehr oft und sehr schnell vergessen wird. Egal ob die kleine private Anwendung, ein internes Firmentool oder aber eine große App für einen Kunden, das Problem mit dem Over-Engineering ist allgegenwärtig.
Dies äußert sich quasi immer darin, dass man im stillen Kämmerlein entwickelt und entwickelt. Man baut Features, implementiert Abläufe und davon immer mehr und mehr. Manchmal hat man konkrete User Stories, manchmal hat man sich selber etwas überlegt, aber am Ende basiert alles meist auf Annahmen. Denn selbst die beste Marktanalyse kann nicht garantieren, dass die entwickelten Funktionen der Art und Weise wie der Endanwender mit der Anwendung umgehen wollen entspricht. Dies bekommt man im eingeschränkten Rahmen durch Tests raus, aber am besten einfach durch echte Nutzer, die die Anwendung wirklich im Alltag verwenden. Entsprechend gilt hier Release Early Release Often mehr denn je.