Hallo liebes Forum!

Nachdem ich mit meinem zu simplem Projektthema zu Recht gescheitert bin, liegt mir nun folgender Vorschlag seitens meines Ausbilders vor:

Implementierung eines File-Upload Features/Prototyps! Dieses Feature könnte grob folgende Punkte umfassen. Ich habe mich gefragt, ob ihr mir dabei helfen könnt auszuwählen, welche ich davon im Rahmen des Projektes abdecken sollte. Das wäre wirklich super nett von euch. Ich bin mir nämlich total unsicher was den Umfang des Projektes anbelangt, da ich viele Projektdokus im Internet gelesen und dort riesige Unterschiede empfunden habe:

1. UI - Angular
   1. - File upload Komponente
   2. -  Drag & Drop und "Mehr Dateien Anhängen Button"
   3. - Auflistung der hochzuladenden/hochgeladenen Dateien
   4. - Progress-Bar für die jeweiligen hochzuladenden Dateien
   5. - Dropdowns für scheduled-delete, i.e. "Recipients" und "Days till deletion"
2. UI - APIs
   1. - Schnittstellen zum hochladen, auflisten und löschen der Datei(n)
3. UI - Tests
   1. - Tests und Mocks
4. Upload Manager -  APIs
   1. - Schnittstellen zur Verwaltungs-Datenbank 
   2. - Schnittstellen zum Client-UI
   3. - Schnittstellen zum Upload Service
5. Upload Manager - Tests
   1. - Tests und Mocks
6. Datenbank - Upload Manager
   1. ERM-Diagram
7. Upload Service - APIs
   1. - Schnitstellen zur Verwaltungs-Datenbank
   2. - Schnittstellen zum Virenscanner
   3. - Schnittstellen zur Object-Storage
8. Datenbank - Upload Service
   1. ERM-Diagram
9. Upload Service - Tests
   1. - Tests und Mocks
10. CI/CD
    1. - Docker, Make und Jenkinsfiles
    2. - Githooks

Vielen Dank : |

Bearbeitet 12. März 20214 j von CompileThis

Was ist das Problem, wenn der File Upload die Lösung ist?

Und wenn du mal die ganzen Budenzauber und die Buzzwords weg lässt, steht da eine Funktionalität, die ein fertiger FIAE am Vormittag macht.

Bearbeitet 12. März 20214 j von MartinSt

Sehe ich wie mein Vorredner. Für einen FIAE eindeutig zu wenig. Evtl. mit einem Panel zur Verwaltung der Daten, dann könnte es ausreichen, allerdings, wie bereits erwähnt wurde, fehlt hier die Problemstellung und der Grund, warum eine der unendlich existierenden Lösungen nicht etabliert werden kann/sollte. 

Oh mann, wirklich? Auch das ist zu wenig...?

Naja, das Problem ist, dass unsere Kunden bisweilen bei der Nutzung unserer Web-Applikation Datei(n) jedes mal neu hochladen müssen. Ein oft gefordertes Feature ist deshalb ein File-Upload bzw. File-Management Reiter in der Benutzeroberfläche, wo die Kunden ihre Datei(n) dauerhaft hochladen und verwalten können.

Der bestehende File-Upload service ist ein legacy service, der von einem, ich glaube, Pearl-Team entwickelt wurde und langsam aber sicher abgelöst werden soll. Das Team ist so unterbesetzt, dass es sogar für bug-fixes teilweise Wochen/Monate braucht.

Es kann nicht irgendeine Lösung genommen werden. Meinst du sowas wie Drop-Box? Der Upload-Service muss in die Web-App integriert werden und sich in unsere Microservice-Architektur einfügen lassen, mit der das legacy system abgelöst wurde, damit andere Teams den Service auch benutzen können. 

Dann weiß ich echt nicht was ich machen soll... Scheisse... 🤯 Das wars dann wohl für mich... 

Bearbeitet 13. März 20214 j von CompileThis

Immerhin haben wir damit ein Problem gefunden: Ein altgedienter Pearl-Service soll abgelöst werden, da er nicht mehr den heutigen Standards entspricht, sich nur mäßig in die Produktlandschaft einfügt und durch das verantwortliche Team kaum noch  Patches eingespielt werden, so dass vermutlich auch Feature Requests von Kunden auf der Strecke bleiben. Dummerweise wird so ein Dienst jedoch benötigt.

Inwieweit das zu wenig ist oder nicht, schwierig. Aber die Annahme, dass ein ausgelernter FIAE an einem Vormittag einen API-basierten File-Upload in Angular schreibt, an Virenscanner und andere Systeme anbindet UND sich noch um das Jenkins-Deployment kümmert, halte ich fast für ein bisschen gewagt. Vom Zeitaufwand her kann das schon hinhauen. Dazu mag es zwar Fileuploads für Angular geben, aber Scheduler und der bereits erwähnte Virenscan und so weiter sind Dinge, für die bestehende Lösungen auch erst evaluiert und an vermutlich irgendeiner Stelle aufgebohrt werden müssten. Will sagen: "Besonderen Anforderungen" könnten das retten.

Bleibt die Frage danach, wo du Entscheidungen treffen kannst.
Es ist ja im weitesten Sinne alles vorgegeben und das sehe ich als bislang größten Knackpunkt.

Guten Morgen Visar,

vielen Dank für deine Antwort!

vor 7 Minuten schrieb Visar:

Immerhin haben wir damit ein Problem gefunden: Ein altgedienter Pearl-Service soll abgelöst werden, da er nicht mehr den heutigen Standards entspricht, sich nur mäßig in die Produktlandschaft einfügt und durch das verantwortliche Team kaum noch  Patches eingespielt werden, so dass vermutlich auch Feature Requests von Kunden auf der Strecke bleiben. Dummerweise wird so ein Dienst jedoch benötigt.

Ja, das ist das Problem. Es wohl auch nicht bloß ein Pearl-Service, sondern ein riesiger Monolith und die übrigen Pearl-Entwickler sollen sich "nur" noch mit maintenance und bug-fixing befassen, soweit ich das verstehe.

 

vor 13 Minuten schrieb Visar:

Inwieweit das zu wenig ist oder nicht, schwierig. Aber die Annahme, dass ein ausgelernter FIAE an einem Vormittag einen API-basierten File-Upload in Angular schreibt, an Virenscanner und andere Systeme anbindet UND sich noch um das Jenkins-Deployment kümmert, halte ich fast für ein bisschen gewagt

Ob das zu wenig oder zu viel ist, das ist eben die Frage. Ich persönlich werde mich besonders anstrengen müssen, um die Programmierung innerhalb von 20-30 Stunden zu schaffen.

 

vor 14 Minuten schrieb Visar:

Will sagen: "Besonderen Anforderungen" könnten das retten. Bleibt die Frage danach, wo du Entscheidungen treffen kannst.
Es ist ja im weitesten Sinne alles vorgegeben und das sehe ich als bislang größten Knackpunkt.

Was ich da oben an Struktur vorgeschlagen habe, war eben nur das: ein Vorschlag, eine Einschätzung. Ich dachte, das wäre hilfreich dabei verständlich darzustellen, welchen Umfang das Projekt in meinem Fall in Folge der Entwurfsphase annehmen könnte. Ich habe so etwas noch nie gemacht und nach einigen Gesprächen hat sich für mich eben ergeben, dass eigentlich nur der Frontend-Teil vorgegeben ist. Wie ich den Rest in die bestehende Microservices-Architektur einbinde... 🤷‍♂️

Das ist auch so eine Sache: Für welche Punkte muss ich mich im Antrag festlegen, wie viel sollte erst im Rahmen der Entwurfsphase entschieden werden? Muss ich mich schon für die Programmiersprachen entscheiden? Nur für einen Teil? 🤕
 

@Visar Was meinst du genau mit "besondere Anforderungen" und wo sind für dich die Knackpunkte, die im Rahmen des Projektes entschieden bzw. abgewogen werden müssten?

 

Es heißt glaube ich Perl und nicht Pearl

Ich würde strategisch gesehen das Projekt  nicht "File Upload" nennen, sondern "Neuimplementierung eines Kundenportals" mit zwei Problemstellungen:

• Wirtschaftlich: Es gibt keine Perl-Entwickler mehr, Bugs zu beheben dauern lange -> kostenaufwändig
• Technisch: Veraltete Technologie, Aspekt auf Sicherheit, nicht mehr State of the Art

Dann natürlich ganz Standard: Ist-Zustand, Anforderungsanalyse, Auswahl der Technologien, Entwurf der Datenbankstruktur, ... 

Die ganzen Details wie Drag & Drop, dass Angular verwendet wird, Deployment usw. würde ich garnicht so detailreich nennen, da vor allem die im Projekt getroffenen Entscheidungen entschieden für den Projekterfolg sind.

vor 6 Minuten schrieb pr0gg3r:

Es heißt glaube ich Perl und nicht Pearl

Jo. So isses.

https://de.wikipedia.org/wiki/Perl_(Programmiersprache)

https://de.wikipedia.org/wiki/Pearl_(Versandhandel)