In der Praxis kommt es hin und wieder vor, dass man zu einem Eintrag X vorherige und/oder nachfolgende Einträge benötigt.
Beispiele dafür könnten folgende User-Stories sein:
In einer Tabelle sind für die Lebzeit eines Gebäudes alle geplanten Wartungen eingetragen. Als Gebäudeverwalter möchte ich im Dashboard zu dem Gebäude immer die nächsten 3 fälligen Wartungen sehen.
In einer Tabelle sind alle bisher durchgeführten Reparaturen eines Autos erfasst. Als Nutzer möchte ich in einem Dashboard/Report immer die letzten 5 Wartungen sehen.
Eine Tabelle beinhaltet alle veröffentlichte PC-Spiele. Als Nutzer möchte ich zu jedem Spiel, das Spiel, die vorherige und die 2 nachher veröffentlichten Spiele angezeigt bekommen.
Sehr häufig habe ich bisher die Aufgabe aufgeteilt. Ich habe per SQL die Daten so weit wie notwendig eingegrenzt und sortiert und in einer Programmiersprache, dann die Logik für X vorherige/nachfolgende Einträge gebaut.
Diese Aufgabe lässt sich auch komplett im SQL lösen und genau darum geht es auch in diesem Beitrag.
localhost ist ein per Internetstandard definierter Domainname, der über eine Loopback-Schnittstelle auf die gerade genutzte Maschine verweist, meistens auf die IP-Adresse 127.0.0.1.[1]
In diesem Beitrag geht es darum, was das localhost aus den verschiedenen Perspektiven beim Einsatz von Docker ist. Dafür setzen wir die folgende Testumgebung auf:
Service A mit Webserver auf Port 80
Service B mit Webserver auf Port 81
In dem Repository docker-localhost habe ich die zwei Dockerfiles inkl. der Konfigurationsdateien bereitgestellt. Darin ist auch beschrieben, wie man die Images erstellen kann.
In einem aktuellen Modul-Projekt haben wir uns als Team für die Verwendung von LaTeX für die Dokumentationserstellung entschieden. Der Download und die Installation von MiKTeX und dem Editor TeXnicCenter waren absolut reibungslos.
Ich versuchte ein Dokument zu erstellen und die Vorschau - idealerweise - in meinem Standard PDF-Programm “Adobe Acrobat Reader DC” zu sehen.
Zwar öffnet sich der Adobe PDF-Reader, allerdings ohne das erwartete Dokument. Nach einigen Sekunden erhalte ich in TeXnicCenter die nachfolgende Fehlermeldung.
Beim Entwickeln auf dem Raspberry Pi/Raspbian mit Visual Studio (wie das geht, beschreibe ich in dem Beitrag Entwickeln mit Visual Studio für Raspberry Pi mit Raspbian) bin ich darauf gestoßen, dass man beim Debuggen nach dem fork()-Aufruf nur den Elternteil Schritt für Schritt durchgehen kann.
In einer unserer letzten Projektdokumentation stellten wir in Word 2016 fest, dass Bilder im Inhaltsverzeichnis angezeigt wurden. Als erstes vermuteten wir, dass Word mit unserem Dokument oder der darin befindlichen Struktur nicht klarkommt.
Für ein Projekt musste ich ein Projekt für/auf dem Raspberry Pi realisieren. Die Variante, mit vim oder nano auf dem Raspberry direkt zu entwickeln und dann mit gcc von hand das Projekt zu kompilieren, die uns von unseren Dozenten/Betreuern empfohlen wurde, war wegen der bereits gewohnten und lieb gewonnenen Komfortabilität von IDE’s keine Option.
In diesem Post beschreibe ich, was und wie man alles einrichten muss, damit man wie gewohnt in Visual Studio entwickeln, und das Debuggen und Deployen auf dem Raspberry Pi ausgeführt wird.
Nach einer Erweiterung der XML-Konfigurations-Dateien in einem Open-Source Projekt, sind die Validierungs-Tests in der CI fehlgeschlagen. In diesem Projekt werden die XML-Dateien gegen eine rng-Datei (RELAX NG-Schema) validiert und ich habe das Schema noch nicht um meine Erweiterungen ergänzt.
Ich stellte fest, dass für die Validierung das Tool xmllint (Bestandteil von libxml2) verwendet wird. Um meine Änderungen schnell selber prüfen zu können, wollte ich das Tool auf meiner Maschine ausführen und die XML-Dateien gegen die RNG-Dateien validieren.
Ich habe in einem Projekt ein wenig mit Python 3.x gearbeitet und habe beim Hochladen per FTP eine Fehlermeldung erhalten die nicht direkt schlüssig/selberklärend war.