Was ist der Pip Paketmanager?

Pip steht für „Pip Installs Packages“ und ist ein Paketverwaltungssystem, mit dem Python-Programmierer Softwarepakete aus dem Python Package Index (PyPI) installieren können. PyPI ist eine Online-Repository, in der Entwickler ihre Python-Pakete für die Öffentlichkeit bereitstellen können.

Geschichte von Pip

Die Notwendigkeit eines Paketmanagers für Python trat im Laufe der Zeit auf, da die Anzahl der verfügbaren Pakete stieg und der Bedarf an einem zentralen Ort zur Verwaltung dieser Ressourcen wuchs. Pip wurde ursprünglich von Ian Bicking erstellt und basiert auf seinem setuptools-Projekt. Es bot eine einheitliche Schnittstelle zum Installieren und Verwalten von Python-Paketen und wurde schnell zur bevorzugten Methode für diese Aufgabe.

Pip richtig einrichten und nutzen

Die Installation ist relativ unkompliziert:

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py python get-pip.py

Für Benutzer, die mit einer Python-Version ab 3.4 oder höher arbeiten, ist Pip bereits in der Standardbibliothek enthalten und muss nicht separat installiert werden.

Beim Arbeiten damit gibt es einige Best Practices, die man befolgen sollte:

1. Virtuelle Umgebungen nutzen: Vor der Installation von Paketen empfiehlt es sich, eine virtuelle Umgebung mit venv oder virtualenv zu erstellen. Dies gewährleistet, dass man Pakete projektbezogen installieren kann und keine Konflikte mit global installierten Paketen entstehen.
2. Anforderungsdateien verwenden: Es ist eine gute Praxis, eine requirements.txt Datei zu erstellen, in der alle für ein Projekt erforderlichen Pakete aufgelistet sind. Dies erleichtert das Einrichten von Projekten auf neuen Systemen.
3. Regelmäßige Aktualisierungen durchführen: Um sicherzustellen, dass alle Pakete aktuell und sicher sind, sollte man Pip regelmäßig verwenden, um Updates zu überprüfen und zu installieren.

Einige grundlegende Befehle

• Ein Paket installieren:

pip install paketname

• Ein Paket deinstallieren:

pip uninstall paketname

• Verfügbare Pakete anzeigen:

pip list

• Anforderungsdatei verwenden, um Pakete zu installieren:

pip install -r requirements.txt

Fazit

Pip bietet Python-Entwicklern ein robustes und flexibles Werkzeug zur Verwaltung ihrer Pakete. Mit einem fundierten Verständnis davon und den zugehörigen Best Practices können Entwickler ihre Projekte effizienter und zuverlässiger gestalten.

Hinweis: Die Informationen und Befehle in diesem Blog-Beitrag können sich mit der Zeit ändern. Es wird daher empfohlen, die offizielle Dokumentation zu Rate zu ziehen, um aktuelle und genaue Informationen zu erhalten.

Der Beitrag Pip – Python Paketmanager erschien zuerst auf CEOsBay.

Maven vereinfacht den Softwareerstellungsprozess, bietet ein einheitliches System für die Entwicklerarbeit, hochwertige Projektinformationen, Richtlinien für das Festlegen von Best Practices und erleichtert die Migration zu neuen Funktionen durch mehr Transparenz. Es beschreibt sowohl, wie Software gebaut wird, als auch deren Abhängigkeiten. Apache hilft sowohl bei der Verwaltung von Projekten und dient als Tool zum Verständnis. Es hilft also dabei, den Zustand eines Projekts zu organisieren und relativ schnell darzustellen.

Primär wird das Programm von Entwicklern und Projektmanagern bei Java-Anwendungsprojekten verwendet. Das Tool kann nützlich sein, um den Zustand eines Projektes auf einem Blick für technisch weniger versierte Personen, wie Führungspersönlichkeiten und Investoren, zusammenzufassen und gleichzeitig, um einige Prozesse bei der Softwareentwicklung zu automatisieren.

Maven basiert auf dem Objektmodell. Projekte werden als eine Pom.xml-Datei gespeichert. Das Tool verwaltet Projekt-Builds, Reportings und Dokumentationen aus einer zentralen XML-Informationsbasis. Mit der Standard-Plug-in-Architektur kann man es über den Standard-Input mit so gut wie jeder Anwendung nutzen und kollaborieren. Es vereinfacht den Prozess für das Erstellen von Java-Anwendungen erheblich, sodass der Nutzer den Status des Projektes viel einfacher einschätzen kann.

Der Name Maven kommt aus dem Jiddischen und bedeutet so viel wie „Sammler des Wissens“.

Kurze Zeitreise

Maven entstand in der Apache Software Foundation aus Frust über den Build-Prozess von Turbine. Es wurde bald zum Top-Level-Projekt aufgrund der Notwendigkeit, die Builds der vielen unterschiedlichen Projekte der Apache Software Foundation möglichst zu vereinheitlichen und somit auch zu vereinfachen.

Durch die vereinheitlichten Strukturen konnten Mitglieder unterschiedlicher Entwicklungsteams zwischen den einzelnen Teilprojekten wechseln und produktivere Arbeitsergebnisse erzielen. Dank der projektübergreifenden Standardisierung war es nicht mehr notwendig, sich in komplizierte Prozesse einzuarbeiten, um das Projekt ausführen und testen zu können.

Die Entwicklung von Maven 1 wurde im Jahr 2003 begonnen und am 13. Juli 2004 als Version 1.0 veröffentlicht. Die Umsetzung wurde jedoch sehr schnell realisiert, sodass einige Eigenheiten nicht bedacht wurden. Beispielsweise gab es Probleme bei der Performance sowie einen Überschuss an Konfigurationsdateien und -angaben, die es zu beherrschen galt. 2014 wurde das End of Life (EoL) von Maven 1 verkündet. Die letzte veröffentlichte Version ist 1.1 vom 25. Juni 2007.

Im Jahr 2005 wurde parallel damit begonnen, Maven 2 zu entwickeln, welches mit Version 2.0 am 19. Oktober 2005 fertiggestellt wurde. Mit dem Major-Release 2 wurde Maven von Grund auf überarbeitet und bekannte Probleme aus der Vorgängerversion wurden behoben. Aus diesem Grund sind Maven 1 und Maven 2 untereinander inkompatibel. Am 18. Februar 2014 wurde das End of Life von Maven 2 kommuniziert. Die letzte veröffentlichte Version ist 2.2.1 aus November 2009.

Die Entwicklung von Maven 3 begann im Jahr 2008, bei der man sich insbesondere auf die Kompatibilität zwischen Maven 2 und 3 konzentrierte.

In der zweiten Hälfte des Jahres 2021 wurden die Arbeiten an Maven 4 begonnen. Eine wesentliche Verbesserung ist die stark optimierte Unterstützung von Multi-Modul-Projekten.

Wie funktioniert Maven?

Maven benötigt zur Ausführung eine Java virtuelle Maschine (JVM) und ist aufgrund dieses Umstandes plattformunabhängig. Aus diesem Grund kann es auf jedem Betriebssystem ausgeführt werden, für das eine Java VM verfügbar ist.

Der Kern von Maven ist mit wenigen Megabyte als Paket kompakt gehalten. Die interne Struktur ist modular aufgebaut. Sämtliche Funktionen werden über Erweiterungen, sogenannte Plugins, bei der erstmaligen Verwendung über ein öffentliches im Internet verfügbares Repository, Maven Central genannt, nachgeladen und in einem lokalen Repository abgelegt.

Maven ist deklarativ und basiert auf zwei wesentlichen Paradigmen. Zum einen auf „Don’t Repeat Yourself“ (DRY bzw. Wiederhole dich nicht selbst) bedeutet sinngemäß im Kontext von Maven, dass man nicht bei jedem Projekt dieselben Build-Schritte neu definiert muss. Und auf „Convention over Configuration“ (CoC bzw. Konvention vor Konfiguration). Dies bezieht sich auf die Konfigurationsdatei (POM), mit denen Maven-Projekte beschrieben werden. Durch festgelegte Konventionen haben möglichst viele Konfigurationseinträge gemeingültige Vorbelegungen (Default-Werte), die für die meisten Anwendungsfälle bereits die erwünschten Ergebnisse produzieren.

Maven folgt den beiden beschriebenen Paradigmen über den gesamten Zyklus der Softwareerstellung konsequent. Eine wichtige Voraussetzung für eine erfolgreiche Automatisierung der einzelnen Schritte des Softwareerstellungsprozesses sind strikte Vereinheitlichungen, wie sie durch die beiden Paradigmen DRY und CoC geschaffen werden.

Obwohl Maven bereits sehr viele Vorgaben liefert, können Projekte diese Vorgaben an ihre tatsächlichen Bedürfnisse anpassen. Sowohl für künftige neuere Versionen von Maven als auch bei der Anbindung von Drittanbieterprodukten ist es eine bewährte Praxis, möglichst nahe am Maven-Standard zu bleiben.

Wichtige Begriffe bei der Arbeit mit Maven

Im Zusammenhang mit Maven werden wichtige Begriffe verwendet, mit denen man vertraut sein sollte, um effektiv damit zu arbeiten:

• Artifacts (Artefakte) Diese werden in Maven sowohl Plugins als auch Abhängigkeiten zu externen Programmbibliotheken und die selbst erstellten binären Programmdateien des eigenen Softwareprojektes bezeichnet.
• Lifecycles (Lebenszyklen) Dies kann auch als Workflow oder Prozess verstanden werden. Maven kennt drei Lifecycles: „clean“, „site“ und „build“.
• Phases (Phasen) In diesen werden die einzelnen Schritte innerhalb eines „Lifecycles“ bezeichnet, die in festgelegter linearer Reihenfolge durchlaufen werden. Der Build-Lifecycle Default kennt 23 Schritte.
• Goals (Ziele) Sind einzelne Aktionen bzw. Funktionalitäten, die in einem Plugin bereitgestellt werden.
• Archetypes (Archetypen) In diesen können Gerüste für unterschiedlichste Arten von Softwareprojekten erstellt werden, deren Struktur dem Standard von Maven entspricht. Was auch als ein wesentliches Merkmal von Maven-Projekten ist. Die einheitliche Verzeichnisstruktur, auf die ich nachfolgend eingehen werde.

Verzeichnisstruktur

my-project/ – Wurzelverzeichnis

pom.xml – Projektbeschreibung (Build-Logik)

src/ – alle Eingabedateien

main/ – Eingabedateien für die Erstellung des eigentlichen Produkts

java/ – Java-Quelltext-Dateien

resources/ – Projektdateien, die kein Java-Quellcode sind, aber für die Übersetzung oder zur Laufzeit benötigt werden, z. B. Bilder, SQL, Java-Properties-Dateien etc.

test/ – Eingabedateien, die für automatisierte Testläufe benötigt werden

java/ – Testfälle, die als Java-Quellcode vorliegen, z. B. JUnit-Testfälle

resources/ – Zusätzliche Ressourcen für Testfälle

target/ – Alle durch Maven während des Build-Vorgangs erstellten Dateien

classes/ – kompilierte Java-Klassen

Die Konfigurationsdatei „pom.xml“

Die Konfigurationsdatei für Maven-Projekte hat die offizielle Bezeichnung „Project Object Model (POM)“und ist als pom.xml im Wurzelverzeichnis des Projektes abgelegt. Im Kontext des Build-Managements ist die pom.xml die Build-Logik, die von externen Werkzeugen wie dem Automatisierungsserver Jenkins aufgerufen wird. Über Jenkins habe ich bereits geschrieben.

Die zwingenden Basisangaben für ein Projekt innerhalb einer POM sind die sogenannten GAV-Parameter, zuzüglich des Packagetyps. GAV steht für (G) = GroupID, (A) = ArtifactId und (V) = Version. Die GAV-Koordinaten müssen für jedes Projekt eindeutig sein und dürfen nicht mehrfach Verwendung finden.

Abhängigkeiten bzw. (Dependency Management)

Einer der wichtigsten Faktoren für den Erfolg von Maven ist der einfache Umgang mit fremden Abhängigkeiten, sogenannten 3rd Party Libraries. Externe Abhängigkeiten werden in der pom.xml notiert und über ihre GAV-Koordinaten eindeutig und transitiv aufgelöst. Die definierten Abhängigkeiten werden nicht physisch in die Versionsverwaltung mit aufgenommen, sondern während des Buildvorgangs im Projekt-Ausgabeverzeichnis target bereitgestellt.

Bei der Verwendung eines Artefaktes prüft Maven, ob es bereits lokal im Repository vorhanden ist. Das lokale Repository ist ein verstecktes Verzeichnis mit der Bezeichnung .m2/repository und findet sich im home-Verzeichnis des am Betriebssystem angemeldeten Nutzers.

Wird von Maven das angeforderte Artefakt im lokalen Repository nicht gefunden, wird in einem öffentlichen Remote-Repository danach gesucht. Bei erfolgreicher Suche wird das Artefakt im lokalen Repository verfügbar gemacht. Das Wichtigste öffentlich frei verfügbare Repository für Java-Artefakte lautet „Maven Central“ und wird von dem Unternehmen Sonatype betrieben.

Es besteht die Möglichkeit, einen eigenen Repository-Server zu betreiben, um selbst erstellte Artefakte im Unternehmen bzw. im Intranet für andere Projekte bereitzustellen oder diese über das Internet zur Verfügung zu stellen.

Wichtige Implementierungen zum Hosten eigener Artefakte sind Sonatype Nexus OSS oder JFrog Artifactory, für die es sowohl freie Community Versionen als auch kommerzielle Enterprise-Varianten gibt. Diese Lösungen können neben den verschiedenen Java-Artefakten auch andere Formate wie beispielsweise Docker Images, RubyGems, .NET nuget oder NPM verwalten. Maven Central, das größte Open-Source-Repository, wird mit Nexus OSS betrieben.

Maven-Lebenszyklen (Lifecycles)

Wie bereits vorher erwähnt, kommen in einem Maven Workflow verschiedene Lebenszyklen zum Einsatz. Diese sind:

• clean (Zum Löschen von Ergebnissen vorheriger Builds, mit den Phasen pre-clean, clean, post-cl
• build (default) (Zum Erstellen eines Projekts im Rahmen der verschiedenen Phasen
• site (Zum Erstellen von Webseiten zur Projektdokumentation und Reports, mit den Phasen pre-site, site, post-site, site-deploy.

Maven geht dabei jeweils von einem Zyklus aus, der bei der Softwareerstellung im Allgemeinen durchlaufen wird. Es muss aber nicht jedes Softwareprojekt alle Phasen des im Folgenden verkürzt dargestellten Default-Zyklus verwenden. Die Standardfunktionalität kann durch die Einbindung von zusätzlichen Plug-ins an die entsprechende Phase erweitert werden.

• validate bzw. validieren (Es wird überprüft, ob die pom.xml und die Projektstrukturen vollständig, valide und gültig sind.
• compile bzw. kompilieren (In dieser Phase wird der Quellcode kompiliert.
• test bzw. testen (Hier wird der kompilierte Code durch das eingebundene Unit-Test-Framework (z. B. JUnit, TestNG) getestet. Maven berücksichtigt dabei in späteren Zyklen, dass Testklassen normalerweise nicht in der auszuliefernden Software vorhanden sind.
• package bzw. verpacken (Das Kompilat wird – ggf. mit anderen nicht kompilierbaren Dateien – zur Weitergabe verpackt. Häufig handelt es sich dabei um eine JAR-Datei.
• integration-test bzw. Integrationstests (Bereitstellen der programmatisch erstellten Integrationstests mittels Behavior Driven Development (z. B. Cucumber, jGiven).
• verify bzw. Gültigkeitsprüfung des Softwarepakets (Überprüfung der Artefakte, ob die festgelegten Spezifikationen erfüllt wurden, D.H. die bereitgestellten Integrationstests werden ausgeführt.
• install bzw. das Kopieren in die lokale Maven-Repository (Kopiert das Softwarepaket ins lokale Maven-Repository, um es dann in anderen lokalen Maven-Projekten verwenden zu können. Dies ist insbesondere für modulare Projekte von Bedeutung.
• deploy bzw. anwenden (Lädt das Softwarepaket in ein entferntes Maven-Repository hoch, wonach es auch anderen Entwicklern global zur Verfügung steht.

Fazit

Hierbei kann man sich relativ kurzfassen. Ein Software-Projekt sollte stehts mit einem vernünftigen Buildmanagement ausgestattet sein. Das Open-Source-Tool bietet sich dabei vor allem bei Java-Projekten an, zumal es selbst auf Java basiert. Es ist ebenso möglich, Maven durch selbst entwickelte Plugins zu erweitern. Aufgrund dieser Eigenschaft wird es auch als Plugin Execution Framework bezeichnet. Man kann damit die Kollaboration bei der Entwicklung durch Programmierer und Projektmanager mit verschiedensten Skill-Sets wesentlich erleichtern bzw. vereinfachen.

Der Beitrag Apache Maven – Projekte inklusive Abhängigkeiten mühelos verwalten erschien zuerst auf CEOsBay.

Da die Programmierung so stark auf einer exakten Syntax beruht, sind die Namenskonventionen für Programmiersprachen und Ressourcen alles andere als intuitiv. Java und JavaScript sind in etwa so eng miteinander verwandt wie Äpfel und Birnen, und das Python-Logo mag zwar ein Bild von ineinander verschlungenen Schlangen sein, aber eigentlich ist es nach „Monty Python’s Flying Circus“, einer BBC-Comedy-Serie aus den 70er Jahren benannt. Aber dies ist nur die Spitze des Eisbergs :). Für jemanden, der zum ersten Mal von Git und GitHub hört, ist die offensichtliche Verbindung vielleicht nicht ganz so offensichtlich.

Ist es nun dasselbe? Wenn nicht, sind sie in irgendeiner Weise miteinander verbunden? Oder ist die Verbindung, wie bei Java und JavaScript, nur oberflächlich?

Dies sind durchaus gerechtfertigte Fragen. Immerhin war Microsoft im Jahr 2018 bereit, 7,5 Milliarden Dollar für die Übernahme auszugeben, sodass Entwickler aller Qualifikationsstufen aufhorchen sollten. Die Wahrheit ist, dass Beiden viel enger miteinander verbunden sind als Java und JavaScript – aber mit einigen wichtigen Unterschieden, die sie voneinander unterscheiden. Nachdem ich gestern bereits über Git geschrieben habe, hier die Eigenschaften von GitHub.

Was ist GitHub?

In der Diskussion wurde oft der Vergleich gezogen, dass GitHub für Git das ist, was Facebook für das tatsächliche Gesicht ihrer Nutzer ist. Folglich ist Facebook eine Art Online-Gesichtsdatenbank und GitHub ist als Hosting-Service für Git-Repositories konzipiert.

Und was genau ist ein Git-Repository-Hosting-Dienst?

Es handelt sich um eine Online-Datenbank, mit der Git-Versionskontrollprojekte außerhalb des lokalen Computers/Servers gemeinsam genutzt werden können. Während Git lokal betrieben bzw. selbst gehosted werden muss, ist GitHub ausschließlich Cloud-basiert und ein kostenpflichtiger Dienst (Die grundlegenden Repository-Hosting-Funktionen sind kostenlos verfügbar, wenn man ein Profil erstellt ;). Was GitHub zu einer beliebten Wahl für Open-Source-Projekte macht).

Das liegt daran, dass es nicht nur alle Funktionen und Vorteile von Git bietet, sondern auch die Grundfunktionen von Git erweitert. Es bietet eine äußerst intuitive, GUI (Graphical User Interface – Grafische Benutzeroberfläche) und stellt Programmierern integrierte Kontroll- und Aufgabenverwaltungswerkzeuge zur Verfügung. Zusätzliche Funktionen können über den Marketplace-Dienst implementiert werden. Und da GitHub cloudbasiert ist, kann jede autorisierte Person von jedem Computer oder Smart-Device, ja, auch mit dem Smartphone, überall auf der Welt auf die Git-Repositories zugreifen (Vorausgesetzt, die Person verfügt über eine Internetverbindung).

Man kann darüber den eigenen Code mit anderen teilen und im Zuge der Kollaboration die Möglichkeit nutzen, Überarbeitungen an den verschiedenen Git-Zweigen vorzunehmen. Auf diese Weise können sich ganze Teams in Echtzeit in diversen Projekten abstimmen. Wenn Änderungen vorgenommen werden, werden neue Zweige erstellt, so dass das Team den Code weiter überarbeiten kann, ohne die Arbeit der anderen zu überschreiben. Diese Zweige sind wie Kopien, und die darin vorgenommenen Änderungen werden nicht in den Hauptverzeichnissen auf den Rechnern der anderen Benutzer wiedergegeben, es sei denn, die Benutzer entscheiden sich dafür, die Änderungen zu pushen (schieben) oder zu pullen (ziehen), um sie zu übernehmen. Es gibt auch eine Desktop-Anwendung, die einige zusätzliche Funktionen für erfahrene Entwickler bietet.

Es gibt auch andere Git-Repository-Hosting-Dienste wie GitLab, BitBucket und SourceForge, die allesamt brauchbare Alternativen darstellen und mit denen ich auch schon in verschiedenen Projekten gearbeitet habe. GitLab bietet sogar eine integrierte Option, mit der die Nutzer ihre Projekte direkt nach GitLab migrieren können.

Tabellarische Gegenüberstellung

Fazit

Alles in allem ist Git ein Versionskontrollsystem, mit dem man den Quellcode verwalten und verfolgen kann. GitHub ist ein Cloud-basierter Hosting-Dienst, mit dem man die Git-Repositories verwalten kann. Wenn man ein Open-Source-Projekt hat, welches Git verwendet, dann soll es helfen, dieses einfacher zu verwalten.

Schließlich sind die Namenskonventionen in der Welt der Programmierung nicht immer intuitiv. Deshalb lohnt es sich, die Verbindungen und Unterschiede zwischen den ähnlich benannten Lösungen zu erkennen. Beide bieten Programmierern wertvolle Versionskontrollfunktionen, sodass man laufend Software erstellen kann, ohne die Befürchtung zu haben, dass alles durcheinander kommt, da viele Menschen daran arbeiten. In diesem Fall verderben viele Köche nicht wirklich den Brei. GitHub geht nur ein bisschen weiter als Git. Es bietet ein paar Funktionen mehr sowie Ressourcen wie den Online-Speicherplatz und erleichtert die Zusammenarbeit an Projekten durch eine einfach zu bedienende Benutzeroberfläche.

Der Beitrag GitHub – Das Zentrum kollaborativer Softwareentwicklung und der Ort, um Code, Ideen und Innovationen zu teilen erschien zuerst auf CEOsBay.

Git wurde ursprünglich von Linus Torvalds im Jahr 2005 für die Entwicklung des Linux-Kernels entwickelt, wobei andere Kernel-Entwickler zur anfänglichen Entwicklung wesentliche Beiträge geleistet haben. Seit 2005 ist Junio Hamano der Hauptverantwortliche. Wie bei den meisten anderen verteilten Versionskontrollsystemen und im Gegensatz zu den meisten Client-Server-Systemen ist jedes Git-Verzeichnis auf jedem Computer ein vollwertiges Repository mit einer vollständigen Historie und vollständigen Versionsverfolgungsfunktionen, unabhängig vom Netzwerkzugang oder einem zentralen Server. Git ist, wie Anfangs angesprochen, freie und Open Source Software, die unter der GPL-2.0-Lizenz vertrieben wird.

Eine kurze Anekdote über Git und dessen Abbreviatur

Linus Torvalds witzelte sarkastisch über den Namen git (was im britischen Slang „unangenehme Person“ bedeutet): „Ich bin ein egoistischer Mistkerl und benenne alle meine Projekte nach mir selbst. Erst „Linux“, jetzt „Git“. Die Manpage beschreibt Git als „the stupid content tracker“ Die Read-me-Datei des Quellcodes führt weiter aus:
„Git“ kann alles Mögliche bedeuten, je nach Laune (Ich werde dies in der englischen Sprache belassen, da es so wahrscheinlich mehr Sinn macht 😉 ).

• Random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of „get“ may or may not be relevant.
• Stupid. Contemptible and despicable. Simple. Take your pick from the dictionary of slang.
• „Global information tracker“: you’re in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
• „Goddamn idiotic truckload of sh*t“: when it breaks.

Um Git zu verstehen sind im Prinzip 8 Begriffe relevant. Repository (Kurz: Repo), die Versionskontrolle, Fork bzw. Forking (Gabel bzw. Gabelung), Branch (Verzweigung), Stage (Phase oder Stadium), Modified (modifiziert), Commit (Verbindlichkeit) und Merge (Zusammenführung). Diese Begriffe werde ich nachfolgend beschreiben.

Was ist eine Repository?

Eine Repository, kurz Repo genannt, ist ein Speicherort für Softwarepakete. Oft wird auch ein Inhaltsverzeichnis zusammen mit Metadaten (Metainformationen bzw. -daten sind strukturierte Daten, die Informationen über Merkmale anderer Daten enthalten) gespeichert. Eine Software-Repository wird in der Regel von Source-Control-Managern (SCM) oder Repository-Managern (Ein Repository-Manager ist eine dedizierte Server-Anwendung, die für die Verwaltung von Repositories mit binären Komponenten entwickelt wurde) verwaltet – Dazu teilweise mehr in der Versionskontrolle und in späteren Beiträgen. Paketmanager ermöglichen die automatische Installation und Aktualisierung von Repositories (Deshalb auch „Pakete“ genannt).

Viele Organisationen und Softwarehersteller unterhalten zu diesem Zweck Server im Internet, teilweise kostenlos oder gegen eine Gebühr. Repositories können können verschiedene Programmiersprachen, Betriebssysteme, Spiele oder andere Anwendungen sowie Dokumente und Daten beherbergen. Die Betreiber solcher Repositories stellen in der Regel ein Paketverwaltungssystem zur Verfügung. Folglich Werkzeuge, mit denen Softwarepakete aus den Repositories gesucht, installiert und anderweitig bearbeitet werden können. Viele Linux-Distributionen (Der Begriff Distribution stammt aus dem Lateinischen „distributio“ und hat im Zusammenhang mit Software zwei unterschiedliche Bedeutungen: Softwarepaketierung und Softwareverteilung) verwenden z. B. das Advanced Packaging Tool (APT), das häufig in Debian-basierten Distributionen zu finden ist oder yum in Red Hat-basierten Distributionen. Es gibt auch mehrere unabhängige Paketverwaltungssysteme, wie z. B. pacman, dass in Arch Linux verwendet wird und equo, welches in Sabayon Linux zu finden ist. Ich bin primär mit Debian-basierten Distributionen unterwegs. Werde ich aber in zukünftigen Beiträgen ausführlicher thematisieren.

Was ist Versionskontrolle?

Die Versionskontrolle unterstützt Entwickler bei der Verfolgung und Verwaltung von Änderungen am Quellcode eines Softwareprojekts. Wenn ein Projekt und die Anzahl der Programmierer wachsen, wird die Versionskontrolle unabdingbar. Doch in der Regel kommen sowohl bei kleineren als auch größeren Softwareprojekten mehrere Personen zum Einsatz, die gemeinsam an dem Quellcode arbeiten. Wenn man beispielsweise als Core-Entwickler an einem bestimmten Teil der Codebasis arbeiten möchte, ist es nicht förderlich oder effizient, wenn der Quellcode direkt bearbeitet wird, da zeitgleich noch andere die an dem Projekt beteiligt sind und daran arbeiten. Dies kann am Ende des Tages für ein enormes Durcheinander sorgen 😀

Da man auf dieses Durcheinander gut verzichten kann, arbeitet man als Entwickler mit einer Versionskontrolle „sicher“ durch branching (Verzweigungen) und merging (Zusammenführungen). „Sicher“ in Anführungszeichen, da es auch da einige Stolpersteine gibt 😉

Beim branching dupliziert ein Entwickler den Teil des Quellcodes (Das so genannte Repository bzw. die Repo), der für ihn relevant ist und kann die Änderungen genau an diesem Teil des Codes vornehmen, ohne den Rest des Projekts zu beeinträchtigen. Sobald der Entwickler seinen Teil des Codes ordnungsgemäß fertiggestellt hat, kann er diesen Code wieder in den Hauptquellcode mergen (einbinden), um es offiziell zu machen. All diese Änderungen werden protokolliert, kommentiert und können bei Bedarf eingesehen, kontrolliert oder rückgängig gemacht werden.

Was ist Fork. bzw. Forking?

Ein Fork ist eine Kopie einer Repository. Das Forken einer Repository ermöglicht es, frei mit Änderungen zu experimentieren, ohne das Originalprojekt zu beeinträchtigen. Dieser Begriff wird auch anderweitig genutzt, doch darauf werde ich jetzt nicht weiter eingehen 😀

Was ist Branch bzw. Branching?

Ein Branch (Zweig) ist ein hervorstehender Teil eines Baumes. Etwas, dass aus einem Hauptteil herausragt. So, auch in unserem Kontext. Ein Zweig stellt eine unabhängige Entwicklungslinie dar. Zweige dienen als Abstraktion für den Prozess der Bearbeitung (Stage/Commit). Man kann sie sich als eine Möglichkeit vorstellen, ein neues Arbeitsverzeichnis, einen Bereitstellungsbereich und/oder einen Projektverlauf anzufordern.

Was ist Modified bzw. Modifying?

Modified (Geändert) bedeutet, dass die Datei(en) geändert wurden aber noch nicht in die Datenbank bzw. Repository übertragen wurden.

Was ist Stage bzw. Staging?

Staged (Phase/Stadium) bedeutet, dass eine geänderte Datei in ihrer aktuellen Version markiert wurde, um sie in dem nächsten Commit-Snapshot (Schnappschuss) zu übernehmen.

Was ist Commit bzw. Committing ?

Commits (Verbindlichkeiten) sind die zentralen Bausteineinheiten einer Git-Projektzeitleiste. Sie können als Schnappschüsse oder Meilensteine entlang der Zeitachse eines Git-Projekts betrachtet werden. Commits werden mit dem Befehl „git commit“ erstellt, um den Zustand eines Projekts zu diesem Zeitpunkt festzuhalten. Im Endeffekt wie das Zwischenspeichern mit F5 bei Spielen oder Strg + S bei der regulären Arbeit am Computer. In der Betrachtungsweise einiger interessanter und manchmal nervtötender Zeitgenossen – Lediglich etwas fundamentaler 😉

Merge

Mit dem Merging-Befehl fügt Git einen geforkten (aufgegabelten) Verlauf wieder zusammen. Mit dem Befehl „git merge“ kann man die unabhängigen Entwicklungslinien, die mit dem Befehl „git branch“ erstellt wurden, in einen einzigen Zweig integrieren.

Fazit

Alles in allem sollte dies für eine kurze Erklärung reichen. In naher Zukunft werde ich auch ein Tutorial über die Nutzung von Git schreiben. Sicherlich gibt es heutzutage auch kommerzielle Cloud-Lösungen wie GitHub oder GitKraken, die diese Schritte auf wenige Mausklicks reduzieren und so eine nahtlosere Zusammenarbeit ohne etwaige Vorkenntnisse ermöglichen, doch dies werde ich auch in zukünftigen Beiträgen thematisieren.

Der Beitrag Git – Die Codeverwaltung für effiziente Zusammenarbeit revolutionieren erschien zuerst auf CEOsBay.

Die 3D Objekte wurden damals kurzerhand mit dem OpenSource 3D Programm Blender erstellt. Im Anschluss wurde mit ThreeJS programmiert und die 3D Objekte wurden mit Animationen und weiteren Interaktionsmöglichkeiten zum Leben erweckt.

In den letzten Tagen habe ich angefangen, diverse Themen zu erlernen. In diesem Zusammenhang bin ich auch über tween.js gestolpert. Eine JavaScript– Engine für „vereinfachte“ Animationen. Vereinfacht deshalb, da diverse Gleichungen von einem gewissen Herrn Robert Penner wesentlich optimiert und zur Verfügung gestellt wurden.

Einige meiner Webanwendungen die ich erstelle, benötigen komplexe Berechnungen. Beispielsweise um 3D Objekte in einem Browser von A nach B zu bewegen. Dank der Hilfe von tween.js, geht dies nun wesentlich schneller. Vor allem, weil man sich nicht so viele Gedanken über die komplexen Gleichungen machen muss. Das Ergebnis könnt ihr auf der Begrüßungsseite meiner persönlichen Website oder gleich aus der nachfolgenden Bildschirmaufnahme entnehmen.

Interoperabilität

Diese Art der Visualisierung soll interaktiv darstellen, dass alle Bereiche, die ich so in meinem Portfolio, durchaus miteinander kompatibel sind.

Ein kurzes Beispiel hierfür:

Man erstellt hochwertige 3D Laser-Scans des Interieurs undAußenanlage eines Unternehmens. In der Regel durch den Einsatz von Luft- und Boden-Laser-Scannern. Im Anschluss ein bis auf ein hundertstel Millimeter präzises digitales Abbild des Firmengebäudes und des Firmenareals. Optimiert und konvertiert man die Point Cloud in ein konventionelles 3D Modell (3d Mesh), kann man dieses im Anschluss verwenden, um mit Hilfe von diversen Tools, die Produktionsabläufe zu optimieren oder aber auch Umbauten oder Anbauten besser zu planen.

Selbstverständlich dienen all diese Daten auch der Dokumentation. Denkt man zurück, an den Brand von Notre-Dame in Paris 2019, konnten dank solcher Scans, die vorher zur Erstellung von Spielewelten erstellt wurden, manche Teile die bei dem Brand zerstört wurden, wesentlich akkurater wiederhergestellt werden. Bedenkt man die Tatsache, dass von derart alten Gebäuden größtenteils keine Baupläne erhältlich sind, können auch diese anhand von Laser Scans, dementsprechend präzise erstellt werden. Im kleineren Maßstab lassen sich auch Ersatzteile oder neue Teile für Produkte im 3D-Druck-Verfahren erstellt werden. Die Möglichkeiten sind geradezu unbegrenzt und werden mit Sicherheit noch in den zukünftigen Blogbeiträgen zu Wort gebracht.

Der Beitrag Website – Aus ALT mach NEU erschien zuerst auf CEOsBay.

Was sind Container?

Zu dem heutigen Industriestandard gehört die Verwendung von virtuellen Maschinen (VMs) zur Ausführung von Softwareanwendungen zum Alltag. Ein Docker-Container ist eine Standardsoftwareeinheit, die einen Code in all seinen Abhängigkeiten speichert. So wird die Anwendung schnell und zuverlässig auf verschiedensten Computerumgebungen lauffähig. Ein Container bildet ein leichtes eigenständiges ausführbares Softwarepaket ab, das alles enthält, was zum Ausführen einer Anwendungscodelaufzeit benötigt wird. Was im Grunde genommen benötigt wird sind in der Regel der Programmcode, diverse RunTime-Engines, Systemtools, die dazugehörigen Systembibliotheken und so ziemlich alle Einstellungen. Diese containerisierte Software läuft unabhängig von dem Betriebssystem, also auf Linux-, Mac- und Windows-basierten Systemen. Und dies vollkommen unabhängig von der jeweiligen Infrastruktur. Die Container isolieren die Software von der Umgebung und stellen sicher, dass sie trotz der Unterschiede einheitlich funktioniert.

Vorteile von Containern

Docker-Container sind besonders beliebt, weil sie gegenüber Virtuellen Maschinen (VMs) viele Vorteile bieten. VMs enthalten grundsätzlich vollständige Kopien eines umfassenden Betriebssystems, die Anwendung(en) selbst, alle erforderlichen Binärdateien und Bibliotheken. Diese Tatsache beansprucht in der Regel Unmengen an Speicherkapazität.

VMs booten im Vergleich auch ausgesprochen langsam. Container benötigen grundsätzlich weniger Speicherplatz, da ihre Images normalerweise nur wenige hundert Megabyte groß sind. So können bei dem Einsatz von Docker viel mehr Anwendungen gleichzeitig verarbeitet werden. Dies reduziert Verwendung von VMs und Betriebssystemen.

Auch der Einsatz von Containern auf Edge-Devices, z.B. auf kompakten Einplatinencomputern (Single-Board Computer (SBC) wie die beliebten Raspberry Pi’s oder NVIDIA Jetson’s, sowie robusten und wartungsarmen Embedded PC’s in der Industrie, ist problemlos möglich. Container sind flexibler und effektiver als VMs und die Verwendung von Docker in der Cloud ist ebenfalls sehr beliebt. Die Möglichkeit, dass verschiedene Anwendungen auf einer einzelnen Betriebssystem-Instanz ausgeführt werden können, verbessert vielfältige Einsatzmöglichkeiten immens. Ein weiterer entscheidender Vorteil von Containern ist die Fähigkeit, Apps nicht nur voneinander, sondern auch von ihrem zugrundeliegenden System zu isolieren.

So kann der Anwender leicht bestimmen, wie eine zugewiesene containerisierte Einheit das jeweilige System und die vorhandenen Ressourcen (CPU, GPU und Netzwerk) nutzt. Zudem stellt es auch sicher, dass Daten und Code voneinander getrennt bleiben was durchaus eine weitere Sicherheitsinstanz darstellen kann.

Komponenten von Docker

Die Docker-Plattform besteht aus einer Reihe von Komponenten. Desktop und Engine sind die zwei wesentlichen Bestandteile davon. Images definieren den Inhalt von Containern. Container sind lauffähige Instanzen von Images. Der Daemon ist eine Hintergrundanwendung, die Images und -Container verwaltet und ausführt. Der Client ist ein Befehlszeilenprogramm (CLI Command-Line Interface) „Ein Befehlszeileninterpreter oder Befehlszeilenprozessor.“ Es verwendet eine Befehlszeilenschnittstelle, um Befehle von einem Benutzer in Form von Textzeilen zu empfangen, dass die API des Daemons aufruft. Registries enthalten Images, und der Hub ist ein weit verbreitetes öffentliches Registry. Zudem gibt es noch die Toolbox, um Docker auf Systeme zu bringen, die nicht nativ unterstützt werden. Dies wird dadurch erreicht, indem eine virtualisierte Linux-Instanz gestartet wird. Dies geschieht beispielsweise innerhalb von VirtualBox. Und Docker wird dann innerhalb dieser virtuellen Maschine ausgeführt.‎ Ein Großteil von Docker (jedoch nicht Desktop) ist Open Source. Lizenziert ist es unter der Apache-V2-Lizenz.

Docker Desktop

Während die meisten Komponenten sowohl für Windows, Mac und Linux verfügbar sind, und trotz der Tatsache, dass die meisten Container auf Linux lauffähig sind, ist Docker Desktop lediglich für Windows und Mac verfügbar. Docker Desktop ist ein GUI-Tool (Graphical User Interface / Grafische Benutzeroberfläche), welches im Wesentlichen eine virtuelle Maschineninstallation abdeckt. Diese virtuelle Maschine ist unter Linux nicht notwendig, da hier direkt die Engine lauffähig ist. Docker Desktop dient unter Windows und Mac zum Management verschiedener Komponenten und Funktionen, einschließlich von Containern, Images, Volumes (an Container angehängter Speicher), lokalem Kubernetes (eine Automatisierung der Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen – Doch hierzu später mehr), Entwicklungsumgebungen innerhalb von Containern und vielem mehr.

Docker-Images und -Registry

Ein Docker-Image ist eine unveränderliche Datei, die im wesentlichen Sinn einen Schnappschuss eines Containers darstellt. Images werden mit dem Befehl „build“ erstellt und erzeugen einen Container, wenn sie mit „run“ gestartet werden. Images werden in einer Registry wie „registry.hub.docker.com“ gespeichert. Sie sind so konzipiert, dass sie aus mehreren Schichten anderer Images bestehen können. So muss bei der Übermittlung von Images über das Netzwerk nur eine geringe Datenmenge übertragen werden.

Docker-Container

Als Programmierer spricht man bei einem Image immer von einer Klasse und bei Containern über eine Instanz einer Klasse – bzw. über ein Laufzeitobjekt. Container sind der Grund, warum Docker so vielfältig verwendet wird: Sie sind leichtgewichtige und portable Kapselungen einer Umgebung, in der Anwendungen ausgeführt werden können.

Docker-Engine

Bei einem Blick auf die Docker-Engine und ihre Komponenten, kann man eine grundlegende Vorstellung davon erhalten, wie das System funktioniert. Mit der Engine entwickelt man Anwendungen, stellt sie zusammen, liefert sie aus und im Anschluss kann man sie ausführen, indem die folgenden Komponenten verwenden: Der Docker Deamon – Ein dauerhafter Hintergrundprozess, der Images, Container, Netzwerke und Speichervolumen verwaltet. Der Daemon „betrachtet“ ständig die Docker-API-Anforderungen und verarbeitet sie.

Die Docker Engine REST API – Eine Schnittstelle, die von Anwendungen verwendet wird, um mit dem Daemon zu interagieren. Auf sie kann über einen https-Client zugegriffen werden. Der Docker Client bzw. die CLI – Ermöglicht den Benutzern die Interaktion mit Docker. Er kann sich auf demselben Host wie der Daemon befinden oder eine Verbindung zu einem Daemon auf einem entfernten Host herstellen und mit mehr als einem Daemon kommunizieren.

Der Docker-Client bietet eine Befehlszeilenschnittstelle (CLI = Command Line Interpreter), über die man einem Daemon Befehle zum Erstellen, Ausführen und Anhalten von Anwendungen erteilen kann. Der Hauptzweck des Clients besteht darin, ein Mittel zur Verfügung zu stellen, mit dem Images aus einer Registry gezogen und auf einem Docker-Host ausgeführt werden können. Die gängigen Befehle, die von einem Client ausgegeben werden, sind: docker build, docker pull und docker run.

Portainer – Zur Vereinfachung der Arbeit mit Docker-Befehlen ist das freie, intuitive und leicht zu implementierende GUI (Graphical User Interface = Grafische Benutzeroberfläche) Portainer oft eine gute Wahl. Die Verwaltung der Engines und das komplette Management ist mit Portainer auch für kleine Projekte geeignet. Ich selbst hatte nur wenig Kontakt damit, daher bitte mit Vorsicht genießen ;). Hardwareinformationen wie die Anzahl der Prozessoren und die Größe des Arbeitsspeichers, sowie Docker-spezifische Informationen (Anzahl der Container, Images, Volumes und Networks) sind auf jeden Fall relativ leicht ersichtlich. So kann das Dockertool mit seiner übersichtlichen Weboberfläche die Standard-Docker-Funktionen und die Verwaltung übernehmen.

Kubernetes

Ein Thema, mit dem ich mich auch noch auseinandersetzen werde und es noch einen gesonderten Beitrag darüber geben wird. Im Grunde genommen ist Kubernetes ein Open-Source-System, welches mit Hilfe von Prozessautomatisierung die Verwaltung der Container übernimmt und somit Hand in Hand mit dem Docker zusammenarbeitet.

In einem Helm-Chart werden Konfigurationsdaten an Kubernetes übergeben. Dort wird konfiguriert, welche Container ausgerollt, überwacht und verwaltet werden sollen. Kubernetes löst diese Aufgabe auch mit einer hohen Anzahl an Containern problemlos. Außerdem kann Kubernetes Ressourcen perfekt einsetzen. Maschinen, die nicht benötigt werden, können entweder ausgeschaltet oder an andere Tasks weitervergeben werden, um Kosten sowie Kapazitäten zu sparen und folglich ein besseres Ressourcenmanagement zu ermöglichen.

Auf welchen Betriebssystemen läuft Docker?

Ein Docker-Container läuft mit der Engine direkt unter Linux und auf jedem Host-Computer, der die Container-Laufzeitumgebung „Docker Desktop“ unterstützt (Mac und Windows). Die Anwendungen müssen nicht an das Host-Betriebssystem angepasst werden. So kann sowohl die Anwendungsumgebung, als auch die zugrunde liegende Betriebssystemumgebung sauber und minimalistisch gehalten werden. Containerbasierte Anwendungen können so problemlos von Systemen in Cloud-Umgebungen oder von Entwickler-Notebooks auf Server geschoben werden, wenn das Zielsystem Docker und alle damit verwendeten Tools von Drittanbietern unterstützt.

Wie kann Docker installiert werden?

• Installationsanleitung für Docker Desktop (Windows)
• Installationsanleitung für Docker Desktop (Mac)
• Installationsanleitung für die Docker-Engine auf diversen Linux Distributionen

Microservices-Modell – Was ist das?

Die meisten Geschäftsanwendungen bestehen aus mehreren separaten Komponenten, die in einem sogenannten „Stack“ organisiert sind. Beispiele hierfür sind ein Webserver, eine Datenbank oder ein In-Memory-Cache. Container ermöglichen es, diese einzelnen Komponenten zu einer funktionalen Einheit mit leicht austauschbaren Teilen zusammenzustellen. Verschiedene Container können diese Komponenten beinhalten. So kann jede Komponente für sich gepflegt, aktualisiert und unabhängig von den anderen modifiziert werden. Im Grunde ist dies das Microservices-Modell des Anwendungsdesigns. Indem die Anwendungsfunktionalität in separate und in sich geschlossene Dienste unterteilt ist, bietet das Modell eine Alternative zu langsamen traditionellen Entwicklungsprozessen und unflexiblen Apps. Leichtgewichtige übertragbare Container machen es einfacher, Microservices basierende Anwendungen zu erstellen und zu pflegen.

Alles in allem trägt Docker dazu bei, die Verwaltung einer kompletten Infrastruktur wesentlich zu vereinfachen, indem es die zugrunde liegenden Instanzen leichter, schneller und robuster macht. Darüber hinaus trennt es die Anwendungsschicht von der Infrastrukturebene und bringt die dringend benötigte Portabilität, Zusammenarbeit und Kontrolle über die Softwarebereitstellungskette. Es wurde für moderne DevOps-Teams entwickelt. Das Verständnis seiner Architektur kann helfen, das Beste aus containerisierten Anwendungen herauszuholen.

Der Beitrag Docker – Verpacken, verteilen und überall ausführen – Laufzeitumgebung für Softwareanwendungen erschien zuerst auf CEOsBay.