move typo fixes
This commit is contained in:
Andreas Zweili
parent
6f7fecec07
commit
8b972523ed
|
|
@ -37,40 +37,41 @@ Ereignis, und nach Kapiteln getrennt.
|
|||
|
||||
Dieses Dokument wurde von Andreas Zweili im Rahmen der Diplomarbeit an der IBZ
|
||||
Schule erstellt und steht unter der gls:cc BY-SA 4.0 footcite:cc Lizenz.
|
||||
Dadurch darf die Arbeit unter beibehalten der Lizenz kopiert und
|
||||
Dadurch darf die Arbeit unter Beibehalten der Lizenz kopiert und
|
||||
weiterverarbeitet werden. Zusätzlich muss der Urheber genannt werden.
|
||||
|
||||
* Initialisierung
|
||||
** Vision
|
||||
|
||||
Die Software soll gls:borg für den durchschnittlichen Computer User zugänglich
|
||||
machen. Die Backups sollen dabei schnell und unkompliziert erstellt werden
|
||||
können. Die Möglichkeit automatischer im Hintergrund laufender Backups soll dem
|
||||
User gegeben sein damit die Hürde für Backups so tief wie möglich gehalten wird.
|
||||
machen. Backups sollen dabei schnell und unkompliziert erstellt werden können.
|
||||
Auch die Möglichkeit automatischer im Hintergrund laufender Backups soll dem
|
||||
User gegeben sein damit die Hürde für Backups so tief wie möglich gehalten
|
||||
wird.
|
||||
|
||||
Die besten Backups sind solche bei denen man gar nicht mehr weiss das man sie
|
||||
hat bis man sie braucht.
|
||||
|
||||
** Ausgangslage
|
||||
|
||||
gls:borg ist deshalb interessant weil es während einem Backup relativ
|
||||
gls:borg ist deshalb interessant, weil es während einem Backup relativ
|
||||
wenig Ressource im Vergleich zu anderen Systemen benötigt und schon relativ
|
||||
lange aktiv entwickelt wird. Dadurch ist es im Alltag geprüft worden.
|
||||
Des weiteren bietet gls:borg die Funktion für Verschlüsselung was es einem User
|
||||
Des Weiteren bietet gls:borg die Funktion für Verschlüsselung was es einem User
|
||||
ermöglicht die Daten auf einem unsicheren Cloud Speicher abzulegen.
|
||||
|
||||
Des weiteren speichert gls:borg die Daten mit Block basierter gls:dedup ab. Dies
|
||||
Des Weiteren speichert gls:borg die Daten mit Block basierter gls:dedup ab. Dies
|
||||
hat den riesigen Vorteil das bei einem Backup nur die Änderungen auf
|
||||
Block-Ebene gespeichert werden und nicht jedes Mal die ganze Datei kopiert
|
||||
werden muss.
|
||||
|
||||
Damit ermöglicht die Software auch Backups von sehr grossen Dateien, wie Videos
|
||||
oder Disk Images von virtuellen Maschinen, in mehreren Version. Ohne dabei
|
||||
oder Disk Images von virtuellen Maschinen, in mehreren Versionen. Ohne dabei
|
||||
jedoch signifikant mehr an Speicher zu benötigen. Zusätzlich werden die Backups
|
||||
dadurch rasend schnell ausgeführt. Gerade dieses Feature macht gls:borg in den
|
||||
Augen des Autors besonders interessant da sich der durchschnittliche User
|
||||
möglichst wenig mit Dingen wie Backups auseinander setzen möchte. Umso besser
|
||||
also wenn sie schnell gehen und so wenig Speicherplatz wie möglich verbrauchen.
|
||||
möglichst wenig mit Dingen wie Backups auseinandersetzen möchte. Umso besser
|
||||
also, wenn sie schnell gehen und so wenig Speicherplatz wie möglich verbrauchen.
|
||||
|
||||
gls:borg wird jedoch komplett über die Kommandozeile bedient. Somit ist es für
|
||||
normale Benutzer eher schwierig den Zugang zu der Software zu finden geschweige
|
||||
|
|
@ -89,9 +90,9 @@ Stunden bis zum 18. März 2019 erarbeitet werden.
|
|||
|
||||
Das Hauptziel der Arbeit soll es sein eine einfach nutzbare grafische
|
||||
Oberfläche für gls:borg zu entwickeln. Da gls:borg selber freie Software ist und
|
||||
der Autor mit gls:libre viel gute Erfahrungen gemacht hat soll das Projekt
|
||||
der Autor mit gls:libre viel gute Erfahrungen gemacht hat, soll das Projekt
|
||||
selber auch wieder gls:libre sein. Zum einen um der Community etwas
|
||||
zurückzugeben des weiteren um anderen Entwicklern die Möglichkeit zu geben die
|
||||
zurückzugeben des weiteren, um anderen Entwicklern die Möglichkeit zu geben die
|
||||
Software zu verbessern und weiter zu entwickeln.
|
||||
|
||||
Als neben läufiges Ziel soll mit dieser Arbeit auch die Verbreitung von freier
|
||||
|
|
@ -113,10 +114,10 @@ auszuweiten.
|
|||
|
||||
Im Projektantrag wurden vor gängig folgende Ziele definiert und entsprechend
|
||||
gewichtet. Die Gewichtung wurde dabei so vorgenommen, dass Ziele mit einer
|
||||
Muss-Gewichtung den Minimalanforderungen der Software entsprechen.
|
||||
Die weiteren Ziele wurden dann mit Ziffern von 5-1 gewichtet. Eine 5 bedeutet
|
||||
dabei dass, das Ziel in naher Zukunft sehr nützlich/wichtig für die Software
|
||||
wäre ist. Eine tiefe Zahl sollte dabei wenn möglich auch einmal in die Software
|
||||
Muss-Gewichtung den Minimalanforderungen der Software entsprechen. Die weiteren
|
||||
Ziele wurden dann mit Ziffern von 5 bis 1 gewichtet. Eine 5 bedeutet dabei
|
||||
dass, das Ziel in naher Zukunft sehr nützlich/wichtig für die Software wäre
|
||||
ist. Eine tiefe Zahl sollte dabei, wenn möglich, auch einmal in die Software
|
||||
integriert werden und ist nicht unwichtig.
|
||||
|
||||
#+CAPTION: Projektziele
|
||||
|
|
@ -196,13 +197,13 @@ integriert werden und ist nicht unwichtig.
|
|||
|
||||
Die Anwendung beschränkt sich darauf Funktionen von gls:borg grafisch
|
||||
darzustellen oder nützlich zu erweitern soweit dies über die gls:api möglich
|
||||
ist. Wie in, Abbildung:([[fig:kontext]]), zu sehen ist werden die Aktion effektiv
|
||||
ist. Wie in Abbildung:([[fig:kontext]]) zu sehen ist, werden die Aktionen effektiv
|
||||
immer vom Borg Binary ausgeführt und nicht von der grafischen Oberfläche. Eine
|
||||
Erweiterung von gls:borg ist nicht vorgesehen. Backup und Verschlüsselung sind
|
||||
heikle Themen und sollten unbedingt nur von Experten angegangen werden. Das
|
||||
Potential für Fehler und die Auswirkungen deren sind einfach schlicht zu gross.
|
||||
Potenzial für Fehler und die Auswirkungen derer, sind einfach schlicht zu gross.
|
||||
|
||||
Des weiteren wird die Grundlage für eine kollaborative Entwicklung geschaffen.
|
||||
Des Weiteren wird die Grundlage für eine kollaborative Entwicklung geschaffen.
|
||||
Während der Laufzeit der Diplomarbeit werden jedoch keine Inputs aus der Borg
|
||||
Community im Bezug auf die Entwicklung entgegengenommen.
|
||||
|
||||
|
|
@ -217,8 +218,8 @@ entdeckt werden, wird dieser dem Projekt melden jedoch nicht selber beheben.
|
|||
** Projektmethode
|
||||
|
||||
Für das Projekt wurde die Wasserfall-Methode gewählt. Da nur eine
|
||||
einzige Person am Projekt arbeitet kann nur ein Task nach dem anderen
|
||||
abgearbeitet werden und viele Aufgaben stehen in Abhängigkeiten zu einander.
|
||||
einzige Person am Projekt arbeitet, kann nur ein Task nach dem anderen
|
||||
abgearbeitet werden und viele Aufgaben stehen in Abhängigkeiten zueinander.
|
||||
Somit macht das iterative Vorgehen der Wasserfall-Methode für dieses Projekt am
|
||||
meisten Sinn.
|
||||
|
||||
|
|
@ -240,26 +241,26 @@ Versionsnummern sind für die Applikation zum jetzigen Zeitpunkt noch nicht
|
|||
vorgesehen. Sollten sie zukünftig einmal verwendet werden soll eine semantische
|
||||
Versionierung footcite:semver verwendet. Dabei ist eine Versionsnummer immer
|
||||
nach diesem Schema aufgebaut, MAJOR.MINOR.PATCH. Bei Änderungen wir die:
|
||||
1. MAJOR Version erhöht wenn man inkompatible Änderungen an der gls:api macht.
|
||||
2. MINOR Version erhöht wenn man Funktionalität hinzufügt die
|
||||
1. MAJOR Version erhöht, wenn man inkompatible Änderungen an der gls:api macht.
|
||||
2. MINOR Version erhöht, wenn man Funktionalität hinzufügt, die
|
||||
abwärtskompatibel ist.
|
||||
3. PATCH Version erhöht wenn man abwärtskompatibel Bug-Fixes hinzufügt.
|
||||
3. PATCH Version erhöht, wenn man abwärtskompatibel Bug-Fixes hinzufügt.
|
||||
|
||||
Auf jeden Fall sollte wenn möglich immer nur lauffähiger Code im Master Branch
|
||||
Auf jeden Fall sollte, wenn möglich immer nur lauffähiger Code im Master Branch
|
||||
eingecheckt sein damit der Master Branch immer eine funktionierende Software
|
||||
repräsentiert. Dies gilt auch für das Repository der Dokumentation. Der Master
|
||||
Branch der Dokumentation sollte maximal mit zwei Befehlen ~make clean~ und
|
||||
~make~ "kompilierbar " sein.
|
||||
~make~ "kompilierbar" sein.
|
||||
|
||||
Als Software für die Versionskontrolle wurde Git footcite:git aus folgenden
|
||||
Gründen ausgewählt:
|
||||
|
||||
- Ist der de facto Standard bei Versionskontrollsoftware
|
||||
- Läuft auf allen gängigen Betriebssystemen
|
||||
- Es gäbe gratis Services die man nutzen könnte (Github, Gitlab)
|
||||
- Es gäbe gratis Services, die man nutzen könnte (Github, Gitlab)
|
||||
- Man kann offline arbeiten und Commits erstellen
|
||||
- Der Author hat bereits einen eigenen Git Server zur Verfügung
|
||||
- Der Author ist bereits mit Git aus vorhergehenden Projekten vertraut,
|
||||
- Der Autor hat bereits einen eigenen Git Server zur Verfügung
|
||||
- Der Autor ist bereits mit Git aus vorhergehenden Projekten vertraut,
|
||||
dadurch muss man keine Ressourcen aufwenden eine neue Software zu lernen.
|
||||
Zusätzlich hat sich Git in den vorhergehenden Projekten als robuste
|
||||
und schnelle Software erwiesen.
|
||||
|
|
@ -279,13 +280,13 @@ und Emails schreiben ist alles möglich.
|
|||
|
||||
Diese Dokumentation wurde in Org-mode footcite:orgmode, einer Erweiterung für
|
||||
den Text Editor Emacs, geschrieben. Die Syntax erinnert an Markdown und
|
||||
Org-mode bietet einem eine Vielzahl an Hilfen dafür inklusive dem erstellen von
|
||||
Org-mode bietet einem eine Vielzahl an Hilfen dafür inklusive dem Erstellen von
|
||||
Tabellen und Spreadsheet Funktionen. Für finale Version des Dokuments kann
|
||||
Org-mode die ursprünglich Textdatei über LaTeX in ein PDF exportieren.
|
||||
|
||||
LaTeX footcite:latex ist eine Software, welche einem die Benutzung des
|
||||
Textsatzsystems TeXs vereinfacht. LaTeX wurde gegenüber einem "What You See Is
|
||||
What You Get" (z.Bsp. MS. Word), Editor gewählt weil es einem mit seiner Markup
|
||||
What You Get" (z.Bsp. MS. Word) Editor gewählt, weil es einem mit seiner Markup
|
||||
Sprache erlaubt das Dokument in Text Dateien zu erstellen, gerade für
|
||||
Programmiere ist dies eine sehr interessante Lösung. Dadurch, dass LaTeX auch
|
||||
nur aus reinen Textdateien besteht, kann man die Dokumente auch ohne weiteres
|
||||
|
|
@ -301,34 +302,35 @@ Die Diagramme wurden mit Draw.io footcite:draw erstellt. Draw.io ist gls:libre
|
|||
unter Apache Lizenz Version 2.0 footcite:apache und kann sowohl als Desktop
|
||||
Applikation wie auch als Webanwendung genutzt werden.
|
||||
|
||||
Beim Design der Arbeit wurden soweit als möglich die typographischen Regeln aus
|
||||
Beim Design der Arbeit wurden soweit als möglich die typografischen Regeln aus
|
||||
dem Buch "Practical Typography" von Matthew Butterick footcite:typo angewandt.
|
||||
Bei den Diagrammen wurden ausschliesslich Farben aus der von Google
|
||||
entwickelten Design Sprache "Material"footcite:material eingesetzt.
|
||||
entwickelten Design Sprache "Material" footcite:material eingesetzt.
|
||||
|
||||
** Zeitplanung
|
||||
|
||||
Die detaillierte Zeitplanung ist dem Ganttchart in der Datei
|
||||
[[file:Zeitplanung_Andreas_Zweili.html][Zeitplanung_Andreas_Zweili.html]] zu entnehmen. Bei der Zeitplanung wurde darauf
|
||||
geachtet das die Arbeit soweit als möglich nicht mit dem Berufsleben kollidiert
|
||||
An einem normalen Arbeitstag wurde dabei damit gerechnet das ca. 2 Stunden
|
||||
Arbeit am Abend möglich sein sollten. An einem arbeitsfreien Tag wurde mit 6
|
||||
Stunden Arbeit gerechnet. Über die Festtage wurden diverse Tage von der Planung
|
||||
ausgenommen da es nicht realistisch schien das an diesen Tagen die Arbeit
|
||||
signifikant vorwärts gehen würde. Auch Schultage wurde nicht als Arbeitstage
|
||||
gerechnet da man meist nicht mehr für weitere Tätigkeiten gross motiviert ist.
|
||||
geachtet das die Arbeit soweit, als möglich nicht mit dem Berufsleben
|
||||
kollidiert An einem normalen Arbeitstag wurde dabei damit gerechnet das ca. 2
|
||||
Stunden Arbeit am Abend möglich sein sollten. An einem arbeitsfreien Tag wurde
|
||||
mit 6 Stunden Arbeit gerechnet. Über die Festtage wurden diverse Tage von der
|
||||
Planung ausgenommen, da es nicht realistisch schien das an diesen Tagen die
|
||||
Arbeit signifikant vorwärtsgehen würde. Auch Schultage wurde nicht, als
|
||||
Arbeitstage gerechnet da man meist nicht mehr für weitere Tätigkeiten gross
|
||||
motiviert ist.
|
||||
|
||||
Als zusätzliche Massnahme um die Arbeitslast zu verteilen wurde vom 14. Januar
|
||||
bis zum 11. März jeder Montag auf der Arbeitsstelle als frei eingegeben.
|
||||
Dadurch steht wägend des Projektes etwas mehr Zeit zur Verfügung als sonst mit
|
||||
einer 100% Arbeitsstelle möglich wäre.
|
||||
einer 100 Prozent Arbeitsstelle möglich wäre.
|
||||
|
||||
** Controlling
|
||||
|
||||
Das Controlling wird verwendet um zu kontrollieren das die eigentliche Planung
|
||||
mit dem effektiv geleisteten Aufwand respektive den effektiv verwendeten
|
||||
Ressourcen übereinstimmt. Somit können für zukünftige Projekte Lehren gezogen
|
||||
werden.
|
||||
Das Controlling wird verwendet, um zu kontrollieren, dass die eigentliche
|
||||
Planung mit dem effektiv geleisteten Aufwand respektive den effektiv
|
||||
verwendeten Ressourcen übereinstimmt. Somit können für zukünftige Projekte
|
||||
Lehren gezogen werden.
|
||||
|
||||
#+LATEX:\newpage
|
||||
#+LATEX:\begin{landscape}
|
||||
|
|
@ -395,7 +397,7 @@ theoretischer Faktor.
|
|||
|
||||
Das Risikomanagement dient dazu Risiken im Projekt zu erkennen und Massnahmen
|
||||
zur Vermeidung der Risiken zu definieren. Dadurch steht man ihnen nicht
|
||||
unvorbereitet gegenüber sollten sie eintreffen.
|
||||
unvorbereitet gegenüber, sollten sie eintreffen.
|
||||
|
||||
*** Risikobeschreibung
|
||||
|
||||
|
|
@ -482,19 +484,19 @@ Verfügung gestellt.
|
|||
|
||||
** Risiko-Analyse
|
||||
|
||||
Bei der Risikoanalyse wird von einem durchschnittlichen Benutzer ausgegangen
|
||||
der zur Zeit noch keine Backups macht und beginnen möchte gls:borg zu nutzen um
|
||||
Bei der Risiko-Analyse wird von einem durchschnittlichen Benutzer ausgegangen,
|
||||
der zur Zeit noch keine Backups macht und beginnen möchte gls:borg zu nutzen, um
|
||||
auf einer externen Harddisk seine Backups zu speichern.
|
||||
|
||||
Es wird dabei eine Ist/Soll Analyse gemacht um die Lösung gegenüber der
|
||||
Es wird dabei eine Ist/Soll Analyse gemacht, um die Lösung gegenüber der
|
||||
bestehenden Möglichkeiten zu vergleichen. Jedes Risiko wurde entsprechend der
|
||||
Tabelle: ([[tab:wahrscheinlichkeit]]) nach der Wahrscheinlichkeit des Eintreffens
|
||||
bewertet und entsprechend der Tabelle: ([[tab:auswirkung]]) nach seiner Auswirkung
|
||||
im Bezug auf die Nützlichkeit der gemachten Backups.
|
||||
|
||||
In der Tabelle: ([[tab:risikobeschreibung]]) sind dabei die Risiken für das
|
||||
Szenario aufgelistet und nummeriert. In der, Abbildung:([[fig:istrisiko]]), ist die
|
||||
Bewertung des Ist-Risikos grafisch dargestellt und in der,
|
||||
Szenario aufgelistet und nummeriert. In der Abbildung:([[fig:istrisiko]]), ist die
|
||||
Bewertung des Ist-Risikos grafisch dargestellt und in der
|
||||
Abbildung:([[fig:sollrisiko]]), ist das Soll-Risiko welches mit dieser Arbeit
|
||||
angestrebt wird ebenfalls grafisch dargestellt.
|
||||
|
||||
|
|
@ -566,13 +568,13 @@ Abbildung:([[fig:swot]]) zu sehen.
|
|||
|
||||
** Anforderungskatalog
|
||||
|
||||
Der Anforderungskatalog entspricht 1:1 den Zielen welche in der Tabelle
|
||||
Der Anforderungskatalog entspricht 1 zu 1 den Zielen, welche in der Tabelle
|
||||
[[tab:projektziele]] definiert wurden.
|
||||
|
||||
** Use Cases
|
||||
|
||||
Ein Use Case sammelt alle möglichen Szenarien, die eintreten können,
|
||||
wenn ein Akteur versucht, mit Hilfe des betrachteten Systems ein
|
||||
wenn ein Akteur versucht, mithilfe des betrachteten Systems ein
|
||||
bestimmtes Ziel zu erreichen. Dabei beschreibt er, was beim Versuch der
|
||||
Zielerreichung passieren kann. Je nach Ablauf kann auch ein Fehlschlag
|
||||
ein Ergebnis eines Anwendungsfalls sein (e.g. falsches Passwort beim
|
||||
|
|
@ -601,14 +603,14 @@ Das Anwendungsfalldiagramm für das gls:borg gls:gui ist in der Abbildung:
|
|||
|
||||
*** Use Cases Detailbeschreibung
|
||||
|
||||
Use Cases werden in der Regel mit Hilfe einer sogenannten Use Case Schablone im
|
||||
Use Cases werden in der Regel mithilfe einer sogenannten Use Case Schablone im
|
||||
Detail beschrieben, damit klar ist, wie der Ablauf jeweils genau aussieht. Die
|
||||
in diesem Projekt verwendete Schablone wurde von Alistair Cockburn definiert.
|
||||
|
||||
Die nachfolgend aufgeführten Use Cases, Tabellen:([[tab:uc_backup]], [[tab:uc_delete]],
|
||||
[[tab:uc_restore]], [[tab:uc_file]], [[tab:uc_mount]], [[tab:uc_config]], [[tab:uc_automatic]])
|
||||
wurden dem Anwendungsfalldiagramm, Abbildung:([[fig:usecase]]), entnommen und
|
||||
zusätzlich noch um jeweils ein Aktivitätsdiagramm , Abbildungen:
|
||||
zusätzlich noch um jeweils ein Aktivitätsdiagramm, Abbildungen:
|
||||
([[fig:activity_backup]], [[fig:activity_delete]], [[fig:activity_restore]],
|
||||
[[fig:activity_mount]], [[fig:activity_settings]], [[fig:activity_automatic]]), erweitert
|
||||
um den Ablauf verständlicher zu machen.
|
||||
|
|
@ -961,7 +963,7 @@ Use Cases und zeigt einem gut die Zuständigkeiten der Aktoren auf.
|
|||
|
||||
** Varianten
|
||||
|
||||
Da Borg eine JSON API zur Verfügung stellt bieten sich diverse Möglichkeiten um
|
||||
Da Borg eine JSON API zur Verfügung stellt bieten sich diverse Möglichkeiten, um
|
||||
das Programm anzubinden. Da das Ziel ist, das Programm normalen Nutzern
|
||||
zugänglicher zu machen, bietet sich ein normales Desktop Programm am ehesten
|
||||
an. Desktop Programme werden von allen Computer Usern täglich genutzt und sind
|
||||
|
|
@ -974,7 +976,7 @@ Projekt.
|
|||
|
||||
Die Bewertungspunkte setzen sich einerseits aus den Projektzielen anderseits
|
||||
aus für das Projekt sinnvollen Punkten zusammen. Dadurch ergeben sich dann die
|
||||
Bewertungen welche in der nachfolgenden Tabelle aufgenommen wurden. Die
|
||||
Bewertungen, welche in der nachfolgenden Tabelle aufgenommen wurden. Die
|
||||
möglichen Varianten wurden danach bewertet. Die effektive Berechnung des
|
||||
Resultats wird nach folgender Formel durchgeführt.
|
||||
|
||||
|
|
@ -1017,26 +1019,26 @@ der Tabelle Projektziele ([[tab:projektziele]]).
|
|||
*** Backend
|
||||
|
||||
Fürs Backend bieten sich die folgende drei Sprachen an: [[C#][C#]], [[C++][C++]], [[Python][Python]].
|
||||
Dies vor allem weil alle Allrounder Sprachen sind und sich gut für Desktop
|
||||
Dies vor allem, weil alle Allrounder Sprachen sind und sich gut für Desktop
|
||||
Applikationen eignen.
|
||||
|
||||
**** C#
|
||||
|
||||
C# ist eine von Microsoft entwickelte Programmiersprache welche viele
|
||||
Frameworks zur Verfügung hat. Insbesondere Aufgrund der grossen kommerziellen
|
||||
Frameworks zur Verfügung hat. Insbesondere aufgrund der grossen kommerziellen
|
||||
Nutzung und der guten Integration mit Windows hat C# eine relative grosse
|
||||
Verbreitung. Bei Linux und OS X ist es jedoch schwieriger C# zu integrieren und
|
||||
zu nutzen.
|
||||
|
||||
Sie ist zu Teilen gls:libre. Die Common Language Runtime welche für das
|
||||
Sie ist zu Teilen gls:libre. Die Common Language Runtime, welche für das
|
||||
Ausführen von Software zuständig ist, ist unter der MIT Lizenz lizenziert
|
||||
footcite:csharp der aktuelle Compiler Roslyn ist unter der Apache Lizenz
|
||||
verfügbar footcite:roslyn. Da es sehr viele offizielle Teile um die Sprache C#
|
||||
gibt kann im Rahmen des Projektes nicht direkt abgeschätzt werden ob alle
|
||||
gibt, kann im Rahmen des Projektes nicht direkt abgeschätzt werden, ob alle
|
||||
benötigten Teile gls:libre sind. Für die Bewertung wird deshalb ein kleinerer
|
||||
Wert als bei C++ und Python genommen.
|
||||
|
||||
C# ist die Programmiersprache welche an der IBZ hauptsächlich gelehrt wird.
|
||||
C# ist die Programmiersprache, welche an der IBZ hauptsächlich gelehrt wird.
|
||||
Dadurch sind die Kenntnisse der Sprache und ihrer Anwendung bereits
|
||||
einigermassen vorhanden. Ausserhalb der Schule wurde die Sprache jedoch noch nie
|
||||
eingesetzt.
|
||||
|
|
@ -1044,7 +1046,7 @@ eingesetzt.
|
|||
Entwickelt wird C# hauptsächlich mit der gls:ide Microsoft Visual Studio.
|
||||
Eine sehr umfangreiche und komplexe Software. Visual Studio ist dabei nur für
|
||||
Windows und OS X erhältlich. Es ist auch möglich C# Projekte ausserhalb von
|
||||
Visual Studio zu erstellen ist jedoch nicht sehr einfach.
|
||||
Visual Studio zu erstellen, es ist jedoch nicht sehr einfach.
|
||||
|
||||
Der Code ist gut lesbar und es gibt offizielle Styleguides von Microsoft was
|
||||
den Code über Projekte hinaus einigermassen einheitlich aussehen lässt. Zudem
|
||||
|
|
@ -1059,17 +1061,17 @@ installieren und nutzbar zu machen. Auf anderen Plattform wird dies leider
|
|||
nicht einfacher und unter Linux ist es bereits schwierig eine funktionierende
|
||||
Umgebung in Gang zu bringen.
|
||||
|
||||
Da C# bereits an der IBZ gelernt wird ist der Lernfaktor hier im Vergleich zu
|
||||
Da C# bereits an der IBZ gelernt wird, ist der Lernfaktor hier im Vergleich zu
|
||||
den anderen Sprachen sicher am kleinsten. Allerdings gibt es noch keinerlei
|
||||
Kenntnisse beim Einbinden eines der unten aufgeführten gls:gui Frameworks.
|
||||
Daher gibt es auf jeden Fall noch genügend zu lernen.
|
||||
|
||||
Die gls:borg Community hat vor relativ kurzer Zeit die offizielle Unterstützung
|
||||
von Windows zurückgezogen. Da C# eine sehr Windows lastige Sprache ist wird
|
||||
von Windows zurückgezogen. Da C# eine sehr Windows lastige Sprache ist, wird
|
||||
daher davon ausgegangen das die Sprache innerhalb der gls:borg Community nicht
|
||||
sehr verbreitet ist.
|
||||
|
||||
C# ist eine stark typisiert Sprache und kompilierte Sprache. Des weiteren ist
|
||||
C# ist eine stark typisiert Sprache und kompilierte Sprache. Des Weiteren ist
|
||||
Visual Studio der Erfahrung nach nicht die schnellste Software. Dies alles
|
||||
führt dazu das C# nicht gerade die schnellste Sprache zum Programmieren ist.
|
||||
Jedoch aufgrund des moderneren Unterbaus sicher schneller als C++.
|
||||
|
|
@ -1101,7 +1103,7 @@ Jedoch aufgrund des moderneren Unterbaus sicher schneller als C++.
|
|||
|
||||
C++ ist eine stark typisierte und kompilierte Programmiersprache. Sie ist seit
|
||||
1998 Teil des ISO Standards footcite:cpp98. ISO/IEC 14882:2017 footcite:cpp17
|
||||
ist zur Zeit die aktuellste Variante. Die Sprache existiert seit ca. 33 Jahren
|
||||
ist zurzeit die aktuellste Variante. Die Sprache existiert seit ca. 33 Jahren
|
||||
und hat eine weitreichende Verbreitung gefunden. C++ ist auf allen
|
||||
Betriebssystemen gut unterstützt muss jedoch für jedes System separat
|
||||
kompiliert werden.
|
||||
|
|
@ -1113,18 +1115,18 @@ C++ kompiliert direkt zu Maschinensprache und ist dadurch sehr performant und
|
|||
läuft sehr gut auf jedem System. C++ ist im Vergleich zu modernen Sprachen
|
||||
jedoch relativ komplex und bietet diverse Stolpersteine für Programmierer.
|
||||
|
||||
Zum entwickeln braucht es verhältnismässig wenig. Da die Sprache bereits sehr
|
||||
Zum Entwickeln braucht es verhältnismässig wenig. Da die Sprache bereits sehr
|
||||
alt ist, stammt sie noch aus einer Zeit wo man noch etwas rudimentärer
|
||||
programmierte. Allerdings braucht man in jedem Fall einen gls:compiler um ein
|
||||
ausführbares Programm zu erzeugen. Bei komplexeren Programmen wird man um
|
||||
mindestens so etwas wie glspl:makefile auch nicht herum kommen
|
||||
mindestens so etwas wie glspl:makefile auch nicht herumkommen
|
||||
|
||||
Im Vergleich zu Python oder C# ist C++ wohl die am schwersten lesbare Sprache.
|
||||
Zudem gibt es auch keinen zentralen Styleguide welcher einem vorgeben würde wie
|
||||
Zudem gibt es auch keinen zentralen Styleguide, welcher einem vorgeben würde wie
|
||||
der Code am besten ausschauen sollte. Somit haben sich über die Jahre mehrere
|
||||
Standards etabliert.
|
||||
|
||||
Der Lernfaktor wäre Aufgrund der mangelnden Vorkenntnisse hier ganz klar am
|
||||
Der Lernfaktor wäre aufgrund der mangelnden Vorkenntnisse hier ganz klar am
|
||||
Grössten.
|
||||
|
||||
Da C++ eine alte Sprache ist geniesst sie auch eine dementsprechende
|
||||
|
|
@ -1132,10 +1134,10 @@ Verbreitung. Daher ist anzunehmen das sicher mindestens ein grössere Teil der
|
|||
älteren BorgBackup Entwickler C++ oder C gelernt haben.
|
||||
|
||||
Da C++ auch heute noch zu den meistgenutzten Sprachen gehört gibt es
|
||||
entsprechend viele Ressourcen dazu und Beispiel Projekte von denen man ableiten
|
||||
kann. Auch hilfreiche Libraries gibt es sehr viele welche den Programmierer
|
||||
entsprechend viele Ressourcen dazu und Beispiel Projekte, von denen man ableiten
|
||||
kann. Auch hilfreiche Libraries gibt es sehr viele, welche den Programmierer
|
||||
unterstützen können. Die Sprache selber ist jedoch eher umständlich zu
|
||||
schreiben. Hinzu kommt noch das man während der Entwicklung immer wieder den
|
||||
schreiben. Hinzu kommt noch das man, während der Entwicklung immer wieder den
|
||||
Code kompilieren muss. In einem Projekt mit dieser begrenzten Zeitspanne eher
|
||||
ungeeignet.
|
||||
|
||||
|
|
@ -1168,7 +1170,7 @@ Der Python Interpreter ist für eine Vielzahl an Betriebssystemen erhältlich,
|
|||
inklusive Windows, OS X und Linux. Nahezu jedes Desktop Linux System kommt mit
|
||||
Python vor installiert. Auch OS X kommt bereits ab Werk mit Python Version 2.
|
||||
Version 3 lässt sich sehr einfach nachinstallieren und ist einfach nutzbar.
|
||||
Unter Windows gestaltetet sich die Installation etwas aufwändiger aber auch
|
||||
Unter Windows gestaltetet sich die Installation etwas aufwendiger aber auch
|
||||
nicht sehr kompliziert integriert sich in Windows jedoch etwas weniger elegant
|
||||
als C#.
|
||||
|
||||
|
|
@ -1204,7 +1206,7 @@ python3 example.py
|
|||
|
||||
Da Python schon eine etwas bekanntere Sprache ist, ist der Lernfaktor der
|
||||
Sprache selber nicht mehr so hoch. Allerdings gibt es noch viele interessante
|
||||
Konzepte die man im Zusammenhang mit der Sprache lernen kann. Wie etwa zum
|
||||
Konzepte, die man im Zusammenhang mit der Sprache lernen kann. Wie etwa zum
|
||||
Beispiel multiple Vererbung von Klassen.
|
||||
|
||||
gls:borg selber wurde in Python geschrieben. Daher ist davon auszugehen das
|
||||
|
|
@ -1214,7 +1216,7 @@ Python ist eine dynamisch typisierte und interpretierte Sprache. Dies bedeutet
|
|||
das man bei Variablen nicht explizit den Typ angeben muss und die Programme zur
|
||||
Laufzeit für den Computer übersetzt werden. Interpretierte Sprachen haben den
|
||||
Vorteil das man mit ihnen in der Regel sehr schnell und unkompliziert
|
||||
entwickeln kann, dies jedoch zu Lasten der Performance.
|
||||
entwickeln kann, dies jedoch zulasten der Performance.
|
||||
|
||||
#+CAPTION: Python Bewertungstabelle
|
||||
#+ATTR_LATEX: :align |>{\columncolor[HTML]{EFEFEF}}p{4cm}|c|p{2cm}|p{2cm}|p{2cm}|
|
||||
|
|
@ -1244,14 +1246,14 @@ entwickeln kann, dies jedoch zu Lasten der Performance.
|
|||
Fürs Frontend sind folgende Projekte interessant: [[Qt][Qt]], [[Gtk][Gtk]] und [[Electron][Electron]]. Alle
|
||||
drei sind cross-plattform fähige gls:gui Frameworks und nicht von einer
|
||||
spezifischen Sprache abhängig. Da nahezu keine Erfahrung mit den aufgeführten
|
||||
Frameworks vorhanden ist werden bei den Frontend Frameworks die Punkte der
|
||||
Verbreitung in der Community und Geschwindigkeit der Entwicklung ausgeschlossen
|
||||
da in allen Fällen nicht mal eine ungenaue Schätzung wirklich möglich wäre.
|
||||
Frameworks vorhanden ist, werden bei den Frontend Frameworks die Punkte der
|
||||
Verbreitung in der Community und Geschwindigkeit der Entwicklung ausgeschlossen.
|
||||
In beiden Fällen wäre nicht mal eine ungenaue Schätzung wirklich möglich.
|
||||
|
||||
**** Qt
|
||||
|
||||
Qt footcite:qt, "cute" ausgesprochen, ist ein Framework zum Entwickeln von
|
||||
grafischen Oberflächen welche auf verschiedenen System ohne grosse Änderungen
|
||||
grafischen Oberflächen, welche auf verschiedenen System ohne grosse Änderungen
|
||||
laufen sollen und sich dabei soweit als möglich wie eine native Applikation
|
||||
verhalten und "anfühlen" soll.
|
||||
|
||||
|
|
|
|||
Reference in New Issue