Wybór technologii. System dla przychodni.

Zastanawiam się nad technologiami, które mógłbym wybrać w celu napisania pracy inżynierskiej. Tematyka, to system dla przychodni, nastawiony raczej nie na zarządzanie przychodnią (faktury, godziny pracy etc.) tylko na pomoc dla pacjenta (zapisy online, korespondencja z lekarzem w znaczeniu jakichś zaleceń etc.). Chciałbym mniej więcej, żeby to działało na zasadzie REST API i osobnego klienta. Co już umiem? Znam już podstawy Javy i Springa. Myślałem nad paroma opcjami. Odnośnie frontendu:

1. Angular i zrobić to w przeglądarce,
2. Kotlin i aplikacja na androida.
   Od strony backendu myślałem nad:
3. Nad tym co już w jakimś stopniu umiem, czyli Java + Spring,
4. Groovy + Spring,
5. Kotlin + Spring, wtedy łatwiej byłoby napisać aplikację na androida,
6. Coś innego, nie na JVM a mianowicie Go.
   W wakacje będę się starał o staż jako programista Java głównie dlatego, że jest najwięcej ofert dla Javowców, a i pisanie aplikacji serwerowych (tych opartych o REST) mi się najbardziej podoba, więc w miarę rozsądnym wyborem byłaby Java + Spring. Z drugiej strony, fajnie byłoby poznać coś nowego np. Go - tylko w tym przypadku ofert pracy, praktycznie nie ma jeszcze. Poradzicie coś?

@Aisekai: szczerze mówiąc troche słaby temat, jeszcze napiszesz się w życiu CRUDów. Ale generalnie skupiłbym się na Javie (Spring) + front w JS

Technologia najmniej ważna, w takich aplikacjach pełno jest wiedzy dziedzinowej i wymagań biznesowych (pracowałem kiedyś przy takim projekcie jako tester manualny, to wiem, jak bardzo to sa złożone rzeczy i wiedza dziedzinowa aż epatowała z GUI, mimo, że kodu to ja nawet nie widziałem).

Pytanie tylko, czy to nie jest za ambitny temat na pracę inżynierską, bo nie odtworzysz faktycznego systemu dla przychodni (chociaż zapewne samo robienie takiego systemu może cię dużo nauczyć programowania. Tylko czy praca inżynierska służyć ma tylko nauce programowania?).

Implementacja też jest ważna, ale to jaki sobie język wybierzesz będzie miało małe znaczenie (pod warunkiem, że wybierzesz ten, który znasz, lubisz i który jest w miarę popularny), przy każdym większym projekcie nabiera nabierać znaczenia architektura czy design całego projektu. Decyzje projektowe, ten czy inny sposób powiązań między poszczególnymi modułami czy klasami w projekcie.

tylko na pomoc dla pacjenta (zapisy online, korespondencja z lekarzem w znaczeniu jakichś zaleceń etc.).

Lepiej się zastanowić głębiej w jaki sposób zaimplementujesz te zapisy czy korespondencję z lekarzem (np. jakie klasy do tego celu stworzysz i jak będą ze sobą współpracować. Albo nawet od strony UX - w jaki sposób to ma działać pod kątem interfejsu. To są ważniejsze rzeczy

Znam już podstawy Javy i Springa.

Ja akurat jestem frontendowcem, ale powiem tak - jakbym miał robić większy projekt frontendowy i miałbym do wyboru robić go w:

1. JS
2. ReasonML
3. Elm

to wybrałbym JS, bo go znam i lubię, a w ReasonML czy Elmie nigdy nie pisałem i może są lepsze, ale co z tego*. Mało tego, nawet jakbym miał do wyboru TypeScripta (za którym nie przepadam) to bym wybrał TypeScripta, dlatego, że byłoby mi się swobodniej poruszać w nim (w końcu TS to tylko JS + dodatki) niż w jakimś nowym nieznanym języku.

* tzn. poznawanie nowych języków może być fajne, rozwijające i ekscytujące. Ale może nie w sytuacji, kiedy od tego zależy nasza kariera, powodzenie większego projektu czy zaliczenie studiów.

Zdaję sobie sprawę nad tym, że jest to trochę mało ambitny temat, ale postanowiłem wybrać taki temat bo znam kogoś, kto będzie w najbliższym czasie otwierał przychodnię i mógłbym zrobić coś takiego i wykorzystać to jako pracę inżynierską (o ile nie będzie to tylko wizytówka). W dodatku, bardziej mi chodzi, nie o to aby było dużo logiki, co o samą architekturę aplikacji oraz poznanie bardziej jakiejś technologii. Superdurszlak w innym temacie zaproponował aby stworzyć mini-framework pokroju Spirng Boota i też by to było rozwijające (wymusiłoby to dogłębniejsze poznanie jak działa Spring) - tylko według mnie lepiej nie ryzykować, a dodatkowo - tak jak mówiłem - zrobić dwie rzeczy na raz. Myślałem też nad tym, żeby stworzyć zarówno stronę w Angularze oraz aplikację na androida, na pewno lepiej to będzie wyglądać jakby ktoś chciał wziąć kiedyś zobaczyć mój temat. Tylko pytanie, czy rzeczywiście temat pracy inżynierskiej ma jakiekolwiek znaczenie w przyszłości?

Lepiej się zastanowić głębiej w jaki sposób zaimplementujesz te zapisy czy korespondencję z lekarzem (np. jakie klasy do tego celu stworzysz i jak będą ze sobą współpracować. Albo nawet od strony UX - w jaki sposób to ma działać pod kątem interfejsu. To są ważniejsze rzeczy

To jest jedna z tych rzeczy, które też chciałem się nauczyć pisząc pracę inżynierską. Oprócz tego kilka innych modułów Springowych (których nie znam). Raczej nie odtworzę całego systemu dla przychodni, raczej chciałem się skupić na przychodni od strony pacjenta, plus jakieś tam mini zaplecze administracyjne. Odnośnie reszty, chyba masz rację i naukę nowych języków pozostawię na kiedy indziej.

Może mam trochę pesymistyczne podejście po pisaniu własnej inżynierki - ale rada moja jest taka: weź jakąkolwiek technologię, którą znasz teraz najlepiej i w której najszybciej zakodzisz co masz zakodzić. Nie bierz nic nowego i nieznanego, chyba że jesteś super ambitny, rozumiesz że ponosisz ryzyko zawalenia projektu i nie będziesz zniechęcony wiecznym googlowaniem rzeczy które już w Javie znasz :) Promotora rzadko będzie interesować co jest w środku, ważne będzie pokazanie że działa i można poklikać. Za to mnóstwo czasu zejdzie ci na pisanie pracy, szukanie zmyślonej bibliografii i ping-pong z prowadzącym doczepiającym się każdego przecinka i słowa. Serio, zaoszczędzisz sporo czasu, który możesz poświęcić na inne rzeczy typu Go :)

Ktoś gdzieś nawet na tym forum mówił, że to jest straszna ilość dokumentacji przez którą trzeba przebrnąć i wymogów, które trzeba spełnić, żeby taki system był w ogóle dopuszczony do użytku. I pamiętam, że polecał najpierw przeczytać nowelizację ustawy z 27 sierpnia 2004 r. o świadczeniu opieki zdrowotnej finansowanej ze środków publicznych (Dz.U. z 2008 r. Nr 164 poz. 1027) i jeszcze dwa inne dokumenty, których nie pamiętam, ale w razie czego, to powodzenia :)