Richard34

Hm und nehmen wir an, die Doku hätte einige Fehler, weil etwas unklar ist ect. das Projekt ist aber Lauffähig? Oder etwas an den Anlagen, eventuell irgenwelchen Diagrammen ist nicht so wie es sein sollte, kann man so etwas dann nachreichen? Oder man war bei de präsi so nervös, das alles schief ging?

Hm okay. Also im Prinzp könnte ich es so machen. Nehem wir an ne Anwendung mit Datenbank zugriff und dann soll die noch auf andere externe Dienste wie z.B Wetterdienste, Verkehrdienste e.c.t. zugreifen können, (egal was, haubtsache dafür gibts passende api's). Dann ist das alles, Datenbank, die Api's mit dem Backend verbunden, da geht alles über Symfoni, was mir im Prinzip dann gebündelt die rohen, nakten Daten bereit stellt, daran schleise ich dann irgend ein Frontend an mit z.B dieser Rest Api. Sollte ich dann z.B ne App haben wollen oder ne Destop-Anwendung, kann ich die einfach nur an dieses Backend "Anschliesen" und muss da nicht erst alles neu einbinden sondern muss nur eine Schnittstelle dafür verwalten, so jetzt meine Grundidee, liege ich da dann in etwa so richtig mit meiner Denkweise?

Also, es ist so, dass ich herum experimentiert habe mit React und Datenbankanbindung ect. Da gibt es tools und son zeugs, (express.js wäre eins, auch andere) auch für das Benutzen von Api´s, aber mir kommt immer mehr der Eindruck, dass es vielleicht nicht verkehrt ist Front und Backend zu trennen, gerade wenn man mit React arbeitet. Ich würde mir dann in etwa das so vorstellen, das man z.B Symfony nutzt, dort dann die Datenbankanbindung hat, api´s und sowas alles darüber läuft und React dann quasi nur auf dieses "Backend" zugreift, dem das alles überlässt und sich nur um die Ansicht und Darstellung kümmert, eben das was es ja auch gut kann. Es ist aber auch so, dass ich mich da schier erschlagen fühle, selbst um React und Symfony miteinander zum laufen zu bringen gibt es schon zig möglichkeiten, wie soll man denn bei all dem wirklich durchblicken und wissen was nun gut ist? Und wie geht ihr vor, versucht ihr Front und Backend immer soweit es geht zu trennen oder macht das jeder dann am ende ein wenig anders?

Gut gut, das hier ist der neue Antrag: --------------------------------------------------------------------------------- 1 Thema Ein TYPO3 Control System (XXX Project Hub) als Webanwendung 2 Bearbeitungszeit 12.10.2020 –> 15.11.2020 3 Übersicht 3.1 Einleitung: Um den Kunden möglichst flexible Webseiten anbieten zu können, benutzt die Kommunikations-Agentur xxx verschiedene Content Management Systeme. Da XXX zu 95% TYPO3 als CMS verwendet, soll dieses Projekt auf dieses CMS ausgerichtet sein. Solche komplexen Systeme und deren Erweiterungen unterliegen einem stetigen Update-Prozess zur Vermeidung von Kompromittierung und auch um der DSGVO gerecht zu werden und die Systeme auf dem neusten Stand der Technik zu halten. Ziel des Projekts wird es sein, ein mandantenfähiges System (XXX Project Hub) zu entwickeln und eine Prozessoptimierung vorzunehmen. Dabei liegt der Fokus auf folgenden Punkten: Datenkonsolidierung, Fehlerminimierung und Zeitersparnis. XXX arbeitet mit einem Deployment-Prozess zur Veröffentlichung der Entwicklungsarbeiten. Das bedeutet, dass jedes Projekt 3 eigenständige TYPO3 Instanzen vorhält Development Instanz (sieht nur XXX und ist nicht von Extern erreichbar) Staging Instanz (zur Abstimmung mit dem Kunden, für die Öffentlichkeit nicht zugänglich) Live Instanz (Öffentliche Webseite) Für die Erfolgskontrolle von den Webseiten (beispielweise Besucherzahlen) kommt das externe Statistik-Tool Matomo zum Einsatz. Für die Kommunikation innerhalb der Projekte, aber auch mit dem Kunden, findet das Ticketsytem Redmine Anwendung. 3.2 Ist Zustand: Um die Komplexität innerhalb der Projekte weiter auszuführen, werden folgende Prozesse beschrieben: Löschzyklen: Der temporäre Ordner (typo3temp) enthält gecachte Dateien, die regelmäßig gelöscht werden müssen. Updates: Der Update-Prozess ist aktuell sehr zeitaufwändig, da das CMS und jede dazugehörige Erweiterung manuell ge-updatet werden muss. Dies betrifft dann auch alle Kunden und Projekte. Inhalte: Der Kunde pflegt seine Inhalte direkt in der Live Instanz ein, was bedeutet, dass die beiden anderen Instanzen (Development und Staging) keinen aktuellen Content-Stand besitzen. Bei Neuentwicklungen werden für Testzwecke allerdings oft auch die aktuellen Contentstrukturen in der Development- und/oder Staging Instanz benötigt. Um diesen Zustand herzustellen, bedeutet es einen nicht unerheblichen Aufwand für das Entwickler-Team. Dabei werden die Daten aus der Datenbank manuell übertragen. Fehlerprüfung: Für die Überprüfung von möglichen Fehlern der Webseite, schaut der Entwickler üblicherweise in die Logdateien des Servers. Die Verbindung zum Server und das Auffinden der korrekten Daten ist relativ aufwändig. Externe Tools: Redmine und Matomo müssen über eine eigene URL im Browser und eigene Login Daten aufgerufen werden. Dadurch entsteht jedes Mal ein Medienbruch. 3.3 Soll Zustand: Für die genannten Prozesse aus 3.2 werden folgende Überlegungen zur Optimierung herangezogen: Löschzyklen: In der Übersicht jedes Projekts soll es einen Button geben, über welchen die Inhalte des temporären Ordners automatisiert gelöscht werden können. Updates: Für jedes Projekt soll es eine Übersicht des jeweiligen TYPO3 Kern-Projekts und sämtlicher installierten Erweiterungen geben. Über eine Auswahl können alle Erweiterungen gleichzeitig aktualisiert werden. Bei Bedarf können aber auch einzelne Erweiterungen ab- oder angewählt werden. Über einen Absende-Button können die Updates der ausgewählten Erweiterungen angestoßen werden. Inhalte: Über eine Ansicht soll eine Versionsübersicht der 3 Instanzen (Development-, Staging- und Live Instanz) angezeigt werden. Der aktuellste Content Stand befindet sich jederzeit auf der Live Instanz. Damit für Testzwecke die Inhalte auch auf den beiden anderen Instanzen verfügbar gemacht werden können, wird es in der Projektübersicht einen Button geben, welcher einen automatischen Prozess anstößt. Dieser Prozess kopiert die Inhalte wahlweise von der Live Instanz zur Staging- oder Development-Instanz. Fehlerprüfung: Ohne umständlich auf dem Server die Logdaten zu suchen, werden in der Übersicht alle Logdateien übersichtlich dargestellt. Man sieht um welche Art Logdatei (beispielsweise PHP, Apache, TYPO3 etc.) es sich handelt und den Stand des letzten Eintrages (timestamp). Externe Tools: Die beiden Tools (Matomo und Redmine) bieten eine offene API an. Somit lassen sich die Daten auch in den XXX Project Hub übertragen und sich beispielsweise alle offenen Tickets und die statistischen Details direkt in der Übersicht anzeigen. 3.4 Umsetzung: Die Umsetzung vom XXX Project Hub wird der Inhalt meines Projektes sein. Dazu werde ich eine Webanwendung mit React und ggf. Symfony entwickeln die über Schnittstellen (API´s) mit TYPO3, Datenbanken und externen Tools verbunden ist. -------------------------------------------------------- Okay also wenn es Auszüge sind geht es ja noch. Selbst Programmiert wird da definitiv, die Frameworks nehmen einem zwar vieles ab, aber auch nicht alles. Nur da muss ich schauen, das ich das dann sauber kennzeichne was vom Framework und was von mir ist. Mit den Klassen muss ich schauen wie ich das mache, aber da werde ich schon ne Lösung finden. Nur ob ich 10 Klassen zusammenkriege die auch ne gewisse Größe haben, das weiss ich jetzt nicht, 5-6 Klassen werd ich aber schon hinkriegen. Könnte ja auch alles in eine packen, aber das ist ja nicht wirklich Sinn der Sache, ich will da ja selbst auch Ordnung drinn haben.

So, also der neue Antrag wurde under Auflagen Genemigt. Allerdings habe ich ihn vorher nochmal komplett umgeschrieben und habe mich in die Situation eines Projektmanagers begeben, der versucht mit diesem Antrag einen Kunden oder b.z.w. seinen Vorgesetzen zu überzeugen. Bei Bedarf kann ich den überarbeiteten Antrag nochmal hier rein stellen. Hier nun die Auflagen: ---------------------------------------------------------------------------------------------------- hr Projektantrag wurde mit Auflage genehmigt. Grund: Sehr geehrter Herr XXXX der Projektantrag wird unter folgenden Auflagen genehmigt: - Ausführliche Darlegung des eigenen Quellcodes. - Ausführliche Darlegung der Trennung von eigenem Quellcode und Programmfunktionen und dem Quellecode und Programmfunktionen verwendeter Frameworks. - Grafische Modelle wie Klassendiagramme, Use-Case-Diagramme und grafische Modelle zur Datenpersistenz müssen erstellt werden. Mit freundlichen Grüßen, Ihr Prüfungsausschuss ---------------------------------------------------------------------------------------------------- Heist das, ich muss meinen kompletten Quelltext ausdrucken und der Doku anheften? Bei Klassendiagrammen könnte es schwierig werden, da ich bei React ja theoretisch auch sogut wie alles ohne Klassen schreiben könnte, oder eben sehr viele Klassen, jenachdem ob ich die Hooks nutze oder die klassichere Variante.

Also, wenn man mit React schtreibt, schreibt man das ja quai alles in JS und nutzt halt eben nich JSX und die Libary die React mitbringt. Es ist ja nun so, dass es die Props, state und Hooks gibt und son Zeugs. Nun gibt es auch sowas, wie useState, useEffekt e.c.t, dafür muss man aber eine Funktion schreiben, soweit ich das weis kann man das nicht innerhalb einer Klasse nutzen (oder ich weiss zumindest nicht wie, bin halt noch anfänger). Diese Hooks zu nutzen macht es halt sehr angenehm, jetzt hab ich aber auch immer mal wieder gelesen, dass die wohl das ein oder andere Mal Probleme verursachen können. Ist bei meinen Tests bisher noch nicht aufgefallen, aber da habt ihr vielleicht mehr Erfahrung mit.

Ja sicher bin ich mir da auch nicht wirklich, wobei das in Relation zu dem was andere machen eher noch viel ist. Also das denke ich mir nicht aus ich meine ich hab das gesehen was andere einreichen. Oder die haben das ganze einfach besser dargestellt, kann auch sein. Die meiste Zeit werde ich mehr für das das drum herum benötigen als das eigentliche Programmieren an sich, aber ich habe ja für alles nur 2 Wochen, auch für die Dokumentation. Man muss auch bedenken, ich leiste nicht das gleiche wie ein erfahrener Programmierer. Aber kann die Gestaltung nicht schon viel Zeit beinhalten? Meine Idee war halt erstmal die Funktionalität ansich fertigzustellen, allerdings muss es ja auch übersichtlich sein. Es soll ja etwas sein, mit dem täglich gearbeitet wird. Ich dachte da an sowas, dass man die Ansicht nach Kunden sortieren kann, sich dort dann die mit TYPO3 erstellten Seiten anzeigen lassen kann, dazu alle passenden Tickets und Statistiken, allerdings weiss ich auch nicht wie aufwendig das dann am ende wirklich wird. Es bringt mir ja nicht viel nur die Daten zu haben, es muss ja auch nach was aussehen, das ist ein Anspruch den ich an mich selbst stelle. Also will ich auch soetwas wie UX-Design berücksichtigen, das System auserdem so aufbauen, dass man es gut erweitern kann. Wenn ich das ordentlich umsetzen will, wird es mehr Zeit kosten als es auf den ersten Blick wirkt. Vielleicht verstehst du wo das ganze am Ende hinnsoll.

Also ich trage eigentlich sogut wie immer (jetzt halt für den Büro, in neinem Fall noch Schulalltag) ein kurzärmeliges Hemd (meistens kariert ) und ne schlichte Jeanshose (also ohne Muster und sowas), egal welche Jahreszeit es ist. Hab auch schwarze Stoffhosen und weises Hemd, was auch okay wäre als dauerhafter Arbeitskleidung. Aber alles was dann darübergeht, würde mich auf dauer schon nerven. Ich mein wenn es nur um eine begrenzte Zeit geht ist so ziemlich alles okay, aber jeden Tag mit Anzug und Krawatte wäre schon unangenehm. Eigentlich wäre ich ja am liebsten in irged einem Keller ohne viel Menschenkontakt, das wäre traumhaft...

Also diese Anwendung an sich erstell ich nicht mit nem CMS, es geht darum, dass vorhandene CMS (TYPO3 hatt) zu verwalten. Diese Anwendung die das können soll, werde ich selbst mit React und eventuell Synfony für das Backend, schreiben. Was das UI angeht, versuche ich agil mit den "Auftraggebern" in Kontakt zu bleiben. War zumindest meine Idee. Das ganze soll nacher auf einem Server laufen, welcher der Auftraggeber bereit stellt. Unter Punt 3.5 habe ich geschrieben was ich so in etwa vorhabe, aber wenn das nicht sogut rüberkahm, hättest du einen Vorschlag wie ich das besser zeigen könnte?

Also ich hoffe mal das ist okay, aber auch wegen der Übersicht wollte ich ein neues Thema aufmachen, da es sich hierbei ja auch um einen neuen Antrag handelt. Mir bleibt leider nicht viel übrig als den heute abzugeben, aber sollte er abelehnt werden, könnt ihr hierbei vielleicht mehr dazu sagen. Tut mir leid das ich damit nerve, aber naja es ist halt alles sehr knapp bei mir. =========================================================== 1 Thema Ein TYPO3 Control System als Webanwendung 2 Bearbeitungszeit 12.10.2020 –> 15.11.2020 3 Übersicht 3.1 Einleitung: Das Unternehmen XXX benutzt als CMS TYPO3, ebenso auch dazu passende Extensions, darunter auch eigens erstellte. Logs lassen sich jederzeit einsehen. Änderungen der mit TYPO3 erstellten Websites von Seiten der Entwickler erfolgen im „Dev-System. Im Stage-System werden Änderungen den Kunden gezeigt, bevor sie Live gehen. Das Dev-System steht nur den Entwicklern zur Verfügung, auf das Stage System, haben Kunden (Die Redakteure in diesem Fall) und die Entwickler zugriff, das Live-System ist dann das System, dass wie der name schon sagt, Live geht. Zugriff darauf haben ebenso die Redakteure und die Entwickler. Als Ticketsystem wird Redmine genutzt, für die Verwaltung von Statistiken Matomo 3.2 Ist Zustand: Alle 3 Systeme (Dev, Stage und Live) müssen aktuell gehalten werden, was derzeit manuell für jedes System und jede Extension, ebenso jedem Core, gemacht werden muss. Der TYPO3-temp Ordner enthält gecachte Dateien, das kann dazu führen, dass es nach Änderungen im System zu Fehlern kommt. Vor Allem nach einem TYPO3 Minor-Update sollte der Ordner immer geleert werden Redakteure können Änderungen direkt im Live oder im Stagesystem durchführen, was dazu führt, dass das Live-System aktueller als das Stage- oder das Dev-System ist. Wollen die Entwickler etwas ändern, müssen sie also jedesmal das Dev-System manuell an das Live-System angleichen. Möchte man einen Einblick in die Logs haben, musste dies bisher direkt auf dem Server geschehen. Redmine und Matomo hat jeweils einen eigenen Login, der nicht mit der Active-Directory von XXX Verknüpft werden kann. Das heißt man muss sich in jedem System einzeln anmelden. 3.3 Das Problem: Jeder einzelne Schritt ist mit einem Zeitaufwand verbunden. Da dies immer wieder gemacht werden muss, summiert sich diese Zeit und wird als unangenehm empfunden. Unangenehme Aufgaben werden gerne aufgeschoben und verleiten zu Flüchtigkeitsfehlern die im Anschluss oftmals mit viel Zeitaufwand behoben werden müssen. Je mehr repetitive Arbeit man automatisieren kann, desto besser ist es für alle Beteiligten. 3.4 Soll Zustand: Gefordert wird ein System, dass alles in einer Plattform vereint. In einer Übersicht sollen je nach Projekt die Version des Typo3 Core sowie deren Extension angezeigt werden, jeweils für die Live-, Stage- und Dev-Version. Der TYPO3- Tempordner soll sich ebenfalls unkompliziert per Knopfdruck leeren lassen. Es soll außerdem möglich sein, alle Extension sowie den Core mit einem Klick zu aktualisieren, aber auch einzelne Extension auszulassen. Ebenso soll zwischen erworbenen und eigens entwickelten Extensions unterschieden werden. Ein Database-Compare dient dazu die aktuelle Datenbank mit den Anforderungen der installierten Extensions abzugleichen und gegebenenfalls anzupassen. Das und die Aktualisierung des File-Admins sollen über einen Button möglich sein, ebenso wie das einsehen der Logs. Zusätzlich ist eine direkte Einsicht über die Statistik und die Tickets erwünscht. 3.5 Umsetzung: Die Umsetzung wird der Inhalt meines Projektes sein, dazu werde ich eine Webanwendung mit React entwickeln die über API´s mit TYPO3 und den Datenbanken verbunden ist. Sollte dies Probleme verursachen, würde ich als Backend mit Synfony arbeiten und React für den Frontend benutzen. Es wird eine Benutzerverwaltung geben in der sich Benutzer registrieren und anmelden können. Die Entwicklung der Webanwendung soll agil sein, ich werde in ständigem Kontakt zum Auftraggeber und den Benutzern (in diesem Falle die Entwickler) stehen und ihre Wünsche und Einwände berücksichtigen. Dazu werde ich Wireframes erstellen und diese den Benutzern vorlegen. Anhand ihres Feedbacks und der technischen Machbarkeit werde ich die Wireframes anpassen. Parallel dazu werde ich am Kern und Grundgerüst der Webseite arbeiten. Durch die Wahl von React als Framework, lassen sich Änderungen im Frontend relativ schnell und unkompliziert vornehmen. Priorität haben die Aktualisierung des TYPO3 Core, der Extensions´s, der Datenbankdump, das Leeren des TYPO3- Temp Ordner und die Aktualisierung des File Ordner. Die Anbindung des Ticket- und Statistiksystem wären sekundär. 4 Umfeld 4.1 Betrieb und Abteilung: XXX XXX hat 85 Mitarbeiter und die Abteilung in dem ich mein Projekt absolviere, befasst sich mit dem Erstellen von Websites, Geschäftsberichten und Newslettern mit der Hilfe eines CMS. 4.2 Benutzte Elemente: 4.2.1 Programmiersprachen: HTML5, CSS3 / SCSS, PHP MySQL, Js JSON ———— 4.2.2 Frameworks und Libarys: React, Redux, jQuerry, Bootstrap. Evt. Synfony ———— 4.2.3 Sonstiges: VSC als IDE, MySqlWorkbench, Chrome / Firefox, Git als Versionsverwaltung, Balsamiq für Wireframes, Draw.io für Diagramme 5 Projektphasen mit Zeitplanung 5.1 Grobe Einteilung: Analyse = 5h, Entwurf = 11h, Implementierung = 35h, Testphase = 7h, Dokumentation = 12h, Gesamt = 70h ————————————— 5.2 Detaillierte Angaben: 5.2.1 Analyse 5h: Use-Case Analyse = 1h, Kostenanalyse = 1h, Lasten und Pflichtenheft = 3h ———— 5.2.2 Entwurf 11h: Erstellen von Wireframes = 5h, Erstellen von Datenbankstruktur und ER-Diagramm = 2h, Erstellen von sonstigen Diagrammen = 4h ———— 5.2.3 Implementierung 35h: Erstellen des Grundgerüstes der Webseite = 12h, Erstellen der Datenbank = 2h, Implementierung der API´s = 8h, Optische Gestaltung der Webseite = 12h ———— 5.2.4 Testphase 7h: Testung durch Mitarbeiter = 2h, Testen von Sonderfällen = 2h, Beheben von Fehlern = 3h ———— 5.2.5 Dokumentation 12h: Entwicklerdokumentation = 5h, Projektdokumentation = 7h ===========================================================

Ich mag dieses "bla bla" auch nicht, aber dache, eventuell muss das so sein. Sonst bin ich wohl eher jemand, der sachen zu trocken und zu klein, b.z.w. "langweilig" beschreibt (laut anderen). Das es noch nicht weiter ausgeführt wurde liegt derzeit! noch daran, das ich da leider auch nicht so viel Zeit habe, aber ich bin ja noch in der Planung und Ausarbeitung. Aber ja im Prinzip ist es eine Anwendung mit der man Typo3 verwalten kann. Gut der wirtschaftliche Aspekt ist der Zeitgewinn, kann das alleine nicht auch schon ausreichen? Und dieser wäre definitiv vorhanden, eben weil viele kleine Schritte wegfallen. Ein anderer Punkt aber auch die Übersicht, das eben alles in einem System ist. Meine Idee war es, das man zu jedem "Projekt (also diese mit Typo3 erstellten webseiten)" auch die dazu passenden Tickets einsehen kann. Eventuell auch eine Sortierung nach Kunden, dass man dann alle dazu zugeordneten Statistiken, Tickets und Projekte sieht. Das schwirrt alles noch in meinem Kopf herum, mein Ausbilder und ein anderer Mitarbeiter finden das bisher aber vom Ansatzt her gut. Eventuell wird es durch diese Erklärung ein wenig klarer. Datenbanken werde ich für diese Webseite nicht großartig was brauchen. Gut für die Kunden und die Benutzer halt, aber viel ist es nicht. Da bleibe ich dann auch bei MySql. Und du meinst, es wirkt alles so wie schon in Stein gemeiselt? Gut ich kann mir vorstellen, dass ich vieles so oder so am Ende komplett anders machen muss, aber wird nicht erwartet, dass ich schon in etwa plane, wie es am ende aussehen soll? Mein Wunsch wäre es eher, das ganze dynamischer zu gestalten, also wärend der Entwicklung in Rücksprache mit dem Auftraggeber zu stehen und dann eben auch so besser auf unvorhergesehenes reagieren zu können. Ich weiss aber nicht wirklich, ob ich das so in den Projektantrag reinschreiben kann. Was ich benutze um das ganze zu erstellen, da war ich noch am überlegen, aber ich werde das mit React machen. Das ist definitv das mit dem ich mich derzeit halt noch am besten auskenne, also nehme ich das, denke mal das macht auch Sinn.

So, also ich bin nun dabei etwas neues auszuarbeiten, einen neuen Antrag für ein neues Projekt. Mein Ausbilder hat drübergeschaut und meinte, da muss noch was angepasst werden, im groben und ganzen ist es aber schonmal die richtige Richtung. Ob ein neues Thema wirklich notwendig ist, weiss ich nicht, aber wenn doch, mache ich gerne eines auf. Was ich zeigen werde ist ersteinmal nur ein erster Entwurf der Übersicht. Es ist sicherlich vieles nicht richtig erklärt und beschrieben, aber da werdet ihr einen bessern Blick für haben. ======================================================= 3 Übersicht 3.1 Einleitung: Das Unternehmen XXX benutzt als CMS Typo3. Um alle Aufgaben in gewünschter Qualität erfüllen zu können, werden verschiedene Extension benötigt. Dazu ist es eine wichtige und zeitsparende Hilfe, in einem Fehlerfall eine Einsicht in die Log-dateien zu haben. Änderungen der mit Typo3 erstellten Websites von Seiten der Entwickler werden nicht direkt im Live-System durchgeführt, dafür gibt es ein extra System(Dev-System). Ebenso haben Redakteure (In diesem Fall die Kunden) ihr eigenes System(Stage-System), an dem sie Anpassungen vornehmen können und testen können, bevor sie es Live schalten. Dies trifft auch auf Änderungen zu, die in der Datenbank eingetragen werden. Ein gutes Ticketsystem und gut geführte Statistiken sind essentiell um die Kundenzufriedenheit sicherzustellen und um ein wirtschaftliches Arbeiten zu ermöglichen. XXX benutzt als Ticketsystem Redmine und als System für die Statistik Matomo. 3.2 Ist Zustand: Was sich in der Theorie einfach anhört, stellt sich in der Praxis dann doch oftmals als störender und zeitaufwendiger heraus als man es im ersten Moment annehmen mag. Nehmen wir das Typo3 System mit den Extension. So Sinnvoll und wichtig diese auch sind, umso aufwendiger ist es, diese aktuell zu halten. Derzeit muss das alles manuell gemacht werden. Jede einzelne Extension muss einzeln ausgewählt und aktualisiert werden. Das gilt auch für den Core vom CMS Typo3. Da es neben dem Live-System Auch noch das Stage-system und das Dev-System aktuell gehalten werden müssen und MPM mehrere Kunden hat, bedeutet dies jedesmal einen großen Zeitaufwand. Ein immer wieder auftretendes Problem ist der Typo3- Tempordner. Dieser muss derzeit manuell geleert werden. Idealerweise würden Änderungen von Redakteuren nur im Stage-System durchgeführt werden und dann auf das Live-System übertragen werden, die Realität läuft aber nicht ideal ab, so das es unterschiede zwischen beiden Systemen geben kann. Auch muss für eine Wartung der Entwickler jedesmal der Status des Live-Systems manuell auf das Dev-System übertragen werden, inklusive der verknüpften Datenbanken. Möchte man einen Einblick in die Logs haben, musste dies bisher manuell geschehen. Für das Ticketsystem und das System sind derzeit jeweils einzelne aufrufbar, eine Verbindung zu den jeweiligen Kunden und Projekten ist nicht immer sofort ersichtlich. 3.3 Soll Zustand: Gefordert wird ein System, dass alles in einer Plattform vereint. In einer Übersicht sollen je nach Projekt die Version des Typo3 Core sowie deren Extension angezeigt werden, jeweils für die Live-, Stage- und Dev-Version. Zusätzlich soll ersichtlich sein, wann die Files und die Datenbank zum letzen mal Aktualisiert wurden. Der Typo3- Tempordner soll sich ebenfalls unkompliziert per Knopfdruck leeren lassen. Es soll außerdem möglich sein, alle Extension sowie den Core mit einem Klick zu aktualisieren, aber auch einzelne Extension auszulassen. Ebenso soll zwischen erworbenen und eigens entwickelten Extensions unterschieden werden. Die Kopie der Datenbank( Datenbank Compare) sowie die Aktualisierung des File-Admins soll ebenfalls per Klick möglich sein, ebenso wie das einsehen der Logs. Zusätzlich wäre eine direkte Einsicht in die zum Projekt gehörenden Tickets und Statistiken wünschenswert. 3.4 Umsetzung: Die Umsetzung wird der Inhalt meines Projektes sein, dazu werde ich eine Webanwendung entwickeln die über API´s mit Typo3 und den Datenbanken verbunden ist. Es wird eine Benutzerverwaltung geben in der sich Benutzer registrieren und anmelden können. Angemeldete Benutzer können über eine Suche oder ein Dropdown-Menü die passenden Projekte heraus suchen. In einem Filter können sie die Auswahl speziell nach Live-, Stage- oder Dev-Versionen filtern. Wird ein Projekt ausgewählt, sieht man die Version des Typo3Core sowie der Extension. Dazu sieht man den letzen Stand der Aktualisierung der Datenbank und der Files. Ebenso besteht die Möglichkeit sich Pro Projekt die passenden Logs anzeigen zu lassen. Diese können entweder über eine Suche, oder ein Dropdown-Menü je nach Typ heraus gesucht werden. Zum vergleich der Live-, Stage und Dev-Versionen, wird man sich die dazugehörigen Versionen in einer Spaltenansicht daneben anzeigen lassen können. Um den Core b.z.w. die Extension´s zu aktualisieren, kann man kleine Checkboxen neben den angezeigten Extension anklicken, mit der Option “alles Auswählen“ werden alle Häkchen gesetzt. Mit einem weiteren Knopfdruck kann man die Aktualisierung für alle ausgewählten Elemente ausführen. Ebenso wird es möglich sein, den Fileadmin und/oder Datenbank einer Version als Master b.z.w. Slave zu markieren und dann mit entsprechendem Button den Status des Slaves an den Master anzugleichen. Die Einbindung des Ticketsystems sowie von Matomo wird vorerst so vollzogen, dass einen Übersicht der Tickets angezeigt werden inklusive einem Link zu dem eigentlichen Ticketsystem. Von Matomo werden die wichtigsten Daten angezeigt, ebenso wie einem Link der zu Matomo direkt führt. ======================================================= Es ist wie gesagt nur ein erster Entwurf, aber wenn man sich grundlegend etwas darunter vorstellen kann uns es so an sich als Projekt angemessen ist, kann ich darauf ja aufbauen. Ich muss auch irgendwie sagen, dass ich auf dieses Projekt auch mehr Lust hätte. Wenn das zu wenig ist, könnte man immer noch mehr Sachen einbauen.

Okay ja das klingt alles nachvollziehbar. Ich muss auch sagen, als ich damals mit React-Native angefangen habe, war ich erstmal total übefordert. Das was das erste mal, das ich überhaubt mal regelmäßiger mit der Konsole arbeiten musste (jetzt mal abgesehen von 1-2 Befehlen). Dann alles nur auf Englisch, gefühlt tausende Begriffe die mir nix sagen. Naja dann als ich mir django angeschaut hatte, war es zwar schon definitiv immernoch neu und anders, irgendwie aber auch vertraut und es ging halt alles viel schneller. Fand das Django eher vorallem wegen dem Python interessant, aber da ich so oder so für die Schule das Java brauche und da auch den Test für das einfache Zertifikat bezahlt bekomme, will ich das definitiv mitnehmen. Mit JS hab ich auch schon bissel was gemacht, mit React auch, dann konzentriere ich mich ersteinmal darauf. Ich merke ja jetzt schon wie ich immer mal wieder Java und JS durcheinander bringe. Diese Argumentation mit Java hat ürbigens genau so auch meine Schule genutzt, auch wenn die meisten meiner Mitschüler was in der Webentwicklung machen, python ist wohl auch bei einigen dabei, aber Java nutzt keiner von denen. Aber gut, als Grundlage ist Java ja finde ich schon ganz gut. Unser Dozent ist aber zum glück auch so, dass er uns erklärt hatt, wie Java so ein bissel im Hintergrund arbeitet und dass man das bei anderen Sprachen beachten sollte.

Hm naja, ich wusste nicht wie ich den Titel besser halten soll. Es geht ja eher um die eigene Einstellung dazu, wie es einen beruflich weiterbringt und so weiter. Oder entscheidet man das dann eher nur nach aktueller Situation? Vieleicht stell ich mir das zu bindend vor, aber in meinem Kopf ist das, jetzt mal dramatisch vormuliert "Das was ich nun lerne, werde ich den rest meines Lebens machen müssen, auf immer und ewig" und da sich halt so schnell was ändert, kann man soetwas doch garnicht entscheiden.

Also nun... Es geht, wie der Titel schon sagt um die Zukunft, von gewissen Frameworks (auch wenn React kein richrtiges Framework ist) und Sprachen. Ja das ist sicherlich nicht so leicht zu beantworten, aber ich vermute mal, das ihr hier einen besseren Eindruck habt als ich als Neuling. In meinem Falle speziell geht es bei den "Frameworks" um ReactJs, Django und Symfony. Diese 3 bauen auf unterschiedlichen Sprachen auf und gerade react ist im Handing ja nochmal anders, zumindest soweit ich das als ziemlicher Neuling sehe. Generell wird man aber von diversen Frameworks und Libary´s geradezu erschlagen, auch wenn diese einem das Leben leichter machen können. Man lernt zwar nichts umsonst, aber baut man etwas mit einer Sprache und Framework/Libary auf und will es noch länger als Basis für etwas nutzen, macht es Sinn sich etwas zu suchen, das auch noch mehrere Jahre gepflegt wird. Anderseits hätte niemand etwas neueres versucht und wäre auf nummer Sicher gehen, würden wir noch in Höhlen leben. Wie handelt ihr sowas, wie entscheidet ihr in was ihr euch weiterbildet und was ihr für Anwendungen und Projekte benutzt?