Projektantrag nicht genehmigt: Mehr Entwicklung?

[Gast Schnuggenfuggler]

Hallo liebes Forum!

Habe gerade die Ablehnungserklärung meines Antrages erhalten:

Zitat

Anhand der Projektbeschreibung ist kein größerer Programmieranteil nachvollziehbar. Erweitern Sie das Abschlussprojekt um Entwicklungskomponenten (weniger Konfiguration, mehr Programmentwicklung). Machen Sie Angaben zur geplanten Entwicklungsumgebung/Programmier- oder Scriptingsprache.
Freundliche Grüße
Ihr Prüfungsausschuss

Seht ihr in meinem Antrag irgendwo noch eine Möglichkeit diesen zu retten bzw. um einen größeren Programmieranteil zu erweitern?

Ich sehe hier bloß folgende Möglichkeiten:

1. Ein größerer Fokus auf Authentifizierung: 
   1. Microservices-Gateway benutzen: Server mit Express, Routes und Http-Headers (wieder nur konfiguration?)
   2. SSO benutzen: keine Ahnung wie ich das bei uns umsetzen würde, vermutl. aber auch nur "konfiguration"?
2. Ein größerer Fokus auf das User Interface:
   1. Template Anpassen: Bevor die Designer loslegen, nehme ich selbst Änderungen im Template, CSS/HTML/JS vor...
   2. Keine Ahnung...
3. Ich haue das Projekt in die Tonne (bzw.) muss es dann ja trotzem machen weil wir es im Betrieb brauchen. Und mache stattdessen etwas mit Angular. Ich "programmiere" bzw. ersetze dort ein PrimeNG/Material Klasse durch eine selbst "programmierte" klasse...yawn?

 

Zitat

 

1) Auftraggeber und Zielgruppe
...
Die Technical Writer möchten ihre Dokumentation in Asciidoc verfassen. Asciidoc erlaubt es, Texte in
verschiedenen Granularitäten beliebig wiederzuverwenden und gleichermaßen zu
refaktorisieren.

Für die Writer, Entwickler und Webdesigner, bedarf es zum einen nun einer Infrastruktur bzw.
einer Pipeline, die aus den Asciidoc-Texten schematisch und automatisiert eine Website
bereitstellt. Für die Stakeholder ist es außerdem wichtig, dass die Pipeline nicht nur eine
Website bereitstellt. Der Server, der die Website bereitstellt, darf lediglich authentifizierten
Benutzern zugänglich sein. Letztlich liegt es nahe, die Website um Funktionen wie PDF- und
Such-Funktionen sowie Multi-Language-Support zu erweitern.

2) Ist-Zustand
Da es für dieses Projekt keinen Vorläufer gibt, besteht keine projektspezifische Infrastruktur auf
die aufgebaut werden kann oder an die der Technical-Writer anknüpfen kann. Für die
Entwicklung der Pipeline stehen allerdings bereits self-hosted Gitlab-, Jenkins- und
Ansble-Server, sowie die notwendigen Entwickler-Zugänge und Deployment-Keys zur
Verfügung.

3) Soll-Zustand
Am Ende des Projektes sollte eine Pipeline zur schematischen und automatischen Erstellung
einer Website vorhanden sein. Insbesondere bedarf es dafür einer Entwicklungsinfrastruktur
sowie einer automatisierten Pipeline, die es Entwicklern, Webdesignern und den Technical
Writern erlaubt Änderungen in ihren jeweiligen Aufgabenbereichen vorzunehmen und
unproblematisch zu veröffentlichen bzw. einen build der Website auszulösen. Änderungen
sollten auf Staging-, Development und Production-Server zur Verfügung gestellt werden
können. Wobei Staging- und Development-Server den Mitarbeitern und lediglich der
Production-Server den Kunden zugänglich sein sollte.
Schließlich gibt es naheliegende Funktionen, wie eine Such-Funktion, Multi-Language-Support
oder PDF-Konvertierung, die sich für eine Dokumentations-Website anbieten. Im Rahmen der
Planungsphase sollte festgestellt werden, welche Funktionen zunächst benötigt und innerhalb
dieses Entwicklungsykluses realisiert werden können.

Grobe Kriterien zur Beurteilung der Zielerfüllung sollten wie folgt lauten:

• Die HTML-Website sollte mittels SSG schematisch generiert werden.
• Der SSG sollte Asciidoc unterstützen und möglichst frei erweiterbar sein.
• Das UI der HTML-Website muss gestaltbar sein.
• Das UI muss bündelbar sein.
• Die Projektteile sollten sinnvoll in mehreren Gitlab-Repositories strukturiert werden.
• Der Webserver sollte statische Inhalte bereitstellen können.
• Der Webserver sollte Inhalte lediglich authentifizierten Benutzern zur Verfügung stellen.
• Die Anwendungen sollten containerisierbar sein.
• Anwendungen bzw. Artefakte sollten automatisch gebaut werden.
• Die Pipeline sollte auf Staging-, Development- und Production-Server veröffentlichen können.
• Entwickler, Designer und Writer sollten die Pipeline selbst auslösen können.
• Der SGG und/oder das User-Interface sollten im Rahmen des Projektes um mindestens eines
• der nachfolgenden Funktionen erweitert werden. Die Wahl der Funktion sollte im Rahmen der
• Planungsphase getroffen werden:
• Such-Funktionalität innerhalb der Website hinzufügen
• Multi-Language-Support mit po-Dateien oder einer Crowdin-Schnittstelle
• Asciidocs auch als PDF generieren und innerhalb der Website zur Verfügung stellen

 

 

 

Bearbeitet 10. März 2021 von Schnuggenfuggler

[charmanta]

vor 47 Minuten schrieb Schnuggenfuggler:

Ein größerer Fokus auf Authentifizierung: 

1. Microservices-Gateway benutzen: Server mit Express, Routes und Http-Headers (wieder nur konfiguration?)
2. SSO benutzen: keine Ahnung wie ich das bei uns umsetzen würde, vermutl. aber auch nur "konfiguration"?

... das wäre ja nicht die Programmierung. Der PA schreibt ausdrücklich, Du sollst mehr selbst programmieren ...

Bleib beim Thema

[Gast Schnuggenfuggler]

Tut mir leid. Ich stehe irgendwie auf dem Schlauch... 😅 Ist sowas mal als Beispiel keine Programmierung:

app.configure(function(){
  app.use(function(req, res, next) {
    var matchUrl = '/StaticFolder';
    if(req.url.substring(0, matchUrl.length) === matchUrl) {
      res.setHeader("Access-Control-Allow-Origin", "*");
    }
    return next();
  });
  app.use(express.static(path.join(application_root, "StaticPages")));
  app.use(express.errorHandler({ dumpExceptions: true, showStack: true }));
});

Wahrscheinlich geht es einfach darum irgend ein paar simple OOP-Klassen bzw. Methoden zu machen, die sich schön in UML- und ER-Diagramme pressen lassen. 

Ich denke in dem Fall ist es das beste einfach einen neuen Projektantrag zu schreiben, der mehr auf die IHK als auf die Realität in meinem Betrieb zugeschnitten ist.

Bearbeitet 10. März 2021 von Schnuggenfuggler

[Whiz-zarD]

Ehrlich gesagt, finde ich den Antrag und nun deinen Beitrag hier sehr hochnäsig und abgehoben. In deinem Antrag ist von einer Programmierung überhaupt nicht die Rede. Ich lese nur, dass du eine Pipeline bereitstellen willst, die da irgendeine Webseite generiert. Das ist aber DevOps und keine reine Entwicklertätigkeit. Keine Ahnung, was Asciidoc ist und wie es verwendet wird aber wenn das sowas ist, wie z.B Doxygen oder Sandcastle, dann sage ich dem Renderer nur, wo er den Quellcode finden kann und daraus wird dann die Webseite generiert. Programmieren muss man da dann überhaupt nichts. Nur Konfigurieren.

 

[CompileThis]

Okay @Whiz-zarD So sollte das natürlich nicht sein. Es ging auch nicht gerade darum dem Renderer zu sagen wo der Quellcode ist, sondern die Entwicklungsinfrastruktur drumherum aufzubauen und zu automatisieren, damit die technischen Schreiber und Designer die Website, mit möglichst wenig CLI-Befehlen eigenständig ihren Vorgaben nach entwickeln können. 

Die Schreiber sollen lediglich "git add/commit/push" machen und damit einen Build der Website auslösen. Bzw. git-tags in einen Teams-Chat posten für die Staging, QA und Prod builds. Da muss man schon ein paar Skripte, Jenkins- und Dockerfiles schreiben. So geübt bin ich darin noch nicht. Dann muss ich ja noch wegen des Gateways bzw. der Authentifizierung sehen, welche Header ich mitschicken muss, damit die Website einwandfrei gemapped wird. Und bestimmt den Renderer anpassen, damit er innerhalb der HTML-Seiten passende links generiert. Für mich ist das schon eine Herausforderung... 😳

Nichts desto trotz, ich verstehe, dass das nichts mit einer schönen objektorientierten Arbeit zu tun hat. Deshalb neige ich stark dazu nicht weiter zu versuchen der IHK das Projekt schmackhaft zu machen. 

vor 3 Stunden schrieb Schnuggenfuggler:

Wahrscheinlich geht es einfach darum irgend ein paar simple OOP-Klassen bzw. Methoden zu machen, die sich schön in UML- und ER-Diagramme pressen lassen. 

"Simpel" wird das natürlich auch nicht unbedingt... 😅 FML...

[pr0gg3r]

Ich sehe hier im Projekt verschiedene Teile. Die Deployment- und Container-Geschichten hören sich durchaus sehr DevOps-lastig an. Wobei man hier streiten kann, ob ein Entwickler nicht auch das beherrschen sollte. Noch gehört es aber nicht zum täglichen Handwerk eines Entwicklers und so wird die IHK das auch sehen.

Aber bevor ich aber zu philosophisch werde, mein Rat:

So wie ich das verstanden habe, checken die Technical Writer ihre Asciidocs in ein Repo ein. Du machst nichts anderes, als in einem Jenkins-Job das Repo auszuchecken und daraus eine statische Seite zu generieren. Das ist jetzt auch keine krasse Pipeline sondern einfach nur das Ausführen eines Terminal-Befehls. Ok wenn man möchte kann man noch ein container erstellen und bereitstellen und sich für den Passwortschutz noch was überlegen. Aber das ist auch nur noch ein paar Zeilen Dockerfile schreiben. Also insgesamt  da auch nicht die Komplexität und deshalb würde ich zu einem anderen Thema raten. 

[Whiz-zarD]

vor einer Stunde schrieb CompileThis:

Die Schreiber sollen lediglich "git add/commit/push" machen und damit einen Build der Website auslösen.

Das ist dennoch DevOps. Letzendlich ist das nur ein Git Hook oder eine Aufgabe in der CI/CD-Pipeline, wo du dann ein Script startest.

 

vor einer Stunde schrieb pr0gg3r:

Also insgesamt  da auch nicht die Komplexität und deshalb würde ich zu einem anderen Thema raten.

Das würde ich auch so sehen.

Bearbeitet 10. März 2021 von Whiz-zarD

[Thanks-and-Goodbye]

@Schnuggenfuggler und @CompileThis: Ihr beide einigt euch bitte schnellstens auf die Verwendung eines einzigen Accounts. Alternativ helfe ich da gerne nach. Danke.