Lernen im Team zu arbeiten - Projekte zusammen umsetzen

osion

Bekanntes Mitglied
Hallo

Ich suche interessierte Programmierer, welche Interesse an Demoprojekte haben.
Es werden einfache Projekte umgesetzt, welche ermöglichen, dass man lernt im Team zu programmieren.

Es werden Projekte wie an der UNI sein (einfache Aufgabe, Review, kein Zeitdruck etc.), welche per GIT verwaltet werden.
Das Ziel ist nicht, dass die Projekte nach der Beendigung verwendet werden.

Wer Interesse hat...einfach melden.

Gruss
osion
 
in welchen sprachen ( ja gut java forum... java liegt nahe ) aber mal zur safety mal so gefragt

angular + java geht ja auch usw
 
in welchen sprachen ( ja gut java forum... java liegt nahe ) aber mal zur safety mal so gefragt

angular + java geht ja auch usw
Es ist abhängig davon wer sich meldet. Die Projekte werden so ausgelegt, dass möglichst vielfältige Aufgaben anfallen und die Personen mit möglichst vielen Problemen konfrontiert werden.

Beispiel: Chat mit verschiedene Features.

Gerne auch Personen, welche sich gut mit Architektur auskennen, welche nur Review machen wollen.
 
Also fuer Review und sonstige Diskussionen in der Richtung bin ich immer zu haben. Wieviel Zeit (und Lust) ich dann noch auf etwas so nebenher habe ist immer die Frage. Aber wenn du im Zweifel etwas warten kannst.
 
Eine Spring Boot Applikation wird für das Backend verwendet, welches den Server darstellt (läuft über ein Docker)
Je nach Chat Art ist es komplett ungeeignet. Wenn du einen Echtzeit-Chat willst, ist ein HTTP-Framework wit Spring Boot schlecht dafuer geeignet. Du kannst zwar die Funktionalitaet abbilden, aber es wird nie so genau passen weil HTTP fuer solche Sachen nicht so toll geeignet ist. Wenn du einen "annaehernd Echtzeit"-Chat willst, zum Beispiel so wie WhatsApp oder Signal, dann ja, dann macht es Sinn sich eine REST-API zu bauen welche Nachrichten empfaengt und diese auf Anfrage rausrueckt.

Spring Boot ist ein 70MB Monster mit, vermutlich, auch einer inkludierten Guillotine zum stechen von Ohrloechern. Wenn du relativ neu bist im Programmieren, wuerde ich vorschlagen entweder direkt auf Socket-Ebene anzufangen, oder mit einem Embedded-Jetty. Beides ist relativ schnell gemacht, einlesen muss man sich so oder so, und du hast den Vorteil dass du zumindest einmal den Unterbau fuer *alle* Frameworks da drauszen kennst.

Also die echte Frage ist: Welche Features soll dieser Chat haben? Welcher Typ soll es sein?
 
Netty könnte gut geeignet sein vllt hab aber noch nicht so viel gemacht aber joaa für desktop apps solls passen

jaja ich weis desktop apps sind böse und unbrauchbar und alles muss in den browser
aber wahrscheinlich bin ich da zu alt dafür ( also runter von meinem browser ! ) um das noch zu verstehen warum man das alles im browser braucht

gut websiten die einfach mal 10 min laden sind schon ne tolle sache oder es laggt einfach alles aber nur deswegen ?
 
aber wahrscheinlich bin ich da zu alt dafür ( also runter von meinem browser ! ) um das noch zu verstehen warum man das alles im browser braucht
Oder zu jung... Die Geschichte wiederholt sich - zumindest in ähnlicher Weise. Die Aufteilung von UI, Logik und Datenhaltung verschiebt sich ständig irgendwo zwischen zentral und dezentral.

Man muss halt eine Kosten-/Nutzenrechnung machen und da liegt der Browser in vielen Bereichen einfach so weit vorne, dass man lieber an der ein ander anderen Stelle in den sauren Apfel beißt. So gibt es mittlerweile ja kaum noch etwas, das der Browser nicht kann und vieles davon lässt sich mit ein paar Zeilen Code nutzen. Auf der Anwenderseite entfällt der gesamte Installations- und Aktualisierungsaufwand.

gut websiten die einfach mal 10 min laden sind schon ne tolle sache oder es laggt einfach alles aber nur deswegen ?
Naja, das kommt darauf an, was man macht.
 
Welche Aufgaben gäbe es denn so?
Kommunikation zwischen zwei Systemen, welche Ortsunabhängig sind. Umsetzung verschiedene Architekturen und Anwendung verschiedenste Design Pattern sowie Technologien.
Je nach Chat Art ist es komplett ungeeignet. Wenn du einen Echtzeit-Chat willst, ist ein HTTP-Framework wit Spring Boot schlecht dafuer geeignet. Du kannst zwar die Funktionalitaet abbilden, aber es wird nie so genau passen weil HTTP fuer solche Sachen nicht so toll geeignet ist. Wenn du einen "annaehernd Echtzeit"-Chat willst, zum Beispiel so wie WhatsApp oder Signal, dann ja, dann macht es Sinn sich eine REST-API zu bauen welche Nachrichten empfaengt und diese auf Anfrage rausrueckt.

Spring Boot ist ein 70MB Monster mit, vermutlich, auch einer inkludierten Guillotine zum stechen von Ohrloechern. Wenn du relativ neu bist im Programmieren, wuerde ich vorschlagen entweder direkt auf Socket-Ebene anzufangen, oder mit einem Embedded-Jetty. Beides ist relativ schnell gemacht, einlesen muss man sich so oder so, und du hast den Vorteil dass du zumindest einmal den Unterbau fuer *alle* Frameworks da drauszen kennst.

Also die echte Frage ist: Welche Features soll dieser Chat haben? Welcher Typ soll es sein?
Die Features wären folgende:
- Chat mit einer Person
- Chat mit mehreren Personen
- Anlage senden / empfangen
- Login
- Registrierung
- Role: Admin/User
-> Admin kann eine Nachricht an alle User senden (erscheint in allen Chats)
- User blocken

An einer Rest-API habe ich auch gedacht. Zusätzlich kann man die Rest-API auch unter andere Umgebungen wie Android, Web ansprechen. Der Chat sollte Live sein (Realität).
----
Für das erste Projekt würde ich 4 Wochen planen (wir arbeiten ja nur begrenzt daran) und ziehen ein Fazit. Entweder gefällt es den Personen und wollen noch eins machen oder nicht. Natürlich hat das nur ein Sinn, wenn wenigstens 10 Personen im Forum Interesse haben.
 
Wir sind gut 5 Leute, davon etwa 3 Personen die Programmieren. Soweit in Ordnung.
Klären wir noch die Punkte und fangen am Wochenende an.
 

Neue Themen


Zurück
Oben