Projekt do CV - Java Spring RESTful

Projekt jakich wiele. Mógłbyś sklonować jakiś spring-crud-example, pozmieniać nazwy i wyjdzie coś takiego. Do CV średnio.

co w takim razie polecasz innego?

Coś bardziej rozbudowanego. Coś o czym potem mowiesz opowiedzieć, co ma jakąś (skomplikowaną) logikę lub rozwiązuje jakiś techniczny problem. Zastanów się, co możesz na rozmowie powiedzieć o tym projekcie? Czego się nauczyłeś i jakie ciekawe rozwiązania tam zaimplementowałeś?

A podobno 90% osób nie robi w pracy skomplikowanych rzeczy tylko pisze crudy, to po co coś innego?
Nie każdy chce być w tych 10% i pisać sterowniki do głowic nuklearnych (o ile takie coś istnieje) :-D

podobno. Umieszczając projekt w CV chciałbyś raczej żeby pomógł on wybić Ci się z tłumu. Po pięcioletnich studiach ludzie mają znacznie ciekawsze projekty w CV niż CRUD w springu, więc takie coś może zadziałać wręcz odwrotnie do zamierzonego celu.

A co to jest, bo README nie widzę.

Nie ma testów, nie ma frontu, nie korzystasz z dockera. Jeszcze długa droga przed tobą do juniora/stażysty. Tak jak kolega wyżej napisał, twój projekt nie różni niczym od projektów ludzi po bootcampach, więc zginiesz w tłumie miernych CV. Wygląda jak lekko zmieniony Spring CRUD example.

Polecam robić własne projekty od zera. Nie musi to być nawet oklepany CRUD w springu i hibernate. Twój projekt robi tyle co zwykła TODO-lista. Jak chcesz zdobyć pracę i mieć coś ciekawego do CV to postaraj się i zrób coś kreatywnego i użytecznego. Mój znajomy ostatnio się przebranżawiał i robiłem mu mały code-review. Zrobił prostą aplikację wielowątkową: porównywarkę cen danego produktu(z allegro, ebay, amazon itd), która odpalała się co określony czas (np raz na tydzień). Łączyła się z różnymi API, jeżeli cena była w innych walutach to łączył się również z kantorem i obliczał, zapisywał do bazy a potem generował raport w postaci pliku excela jak cena zmieniała się w czasie. Nie było to łatwe wyzwanie i czasami gdy nie miał dostępu do publicznego API używał parserów HTML typu JSoup.

Mając taką prostą aplikację w CV z łatwością dostał się na staż i z tego co wiem jest zadowolony i jakoś sobie radzi. Bo na temat takiej aplikacji mógł sobie porozmawiać na rozmowie, rozwiązał kilka problemów, które musiał sam rozwiązać, bo nie było do nich "tutoriala". O twojej apce nie ma zbytnio co rozmawiać, więc jak już chcesz robić takie aplikacje CRUDowe to rób je porządnie tzn.
**- zawsze rób testy!!! (jednostkowe bez mockowania, integracyjne)
- jeśli chodzi o pakiety to masz układ typowo z tutoriala, poczytaj o package by feature http://www.javapractices.com/topic/TopicAction.do?Id=205
- dodaj front np: w thymeleafie, angularze lub reactcie
- naucz się i korzystaj z dockera
*- dodaj trochę operacji i logiki biznesowej do tego CRUDa, żeby ta aplikacja nie opierała się tylko na operacjach na bazie danych. Przykładowo: wysyłanie maili, generowanie statystyk, cokolwiek fajnego sobie wymyślisz *
*- zamiast robić dużo małych aplikacji zrób 1-2 większe, nad którymi posiedzisz kilka miesięcy i przyłożysz się do jakości i czystości kodu ***

popatrz np: tutaj: https://github.com/bezikan/pharmacy/blob/f062bb189eb1efeab99a2cb4b1a0913f25350647/src/main/java/com/example/pharmacy/controller/DiseaseController.java#L74

Jaki sens mają te puste linie? Świadczy to tylko o twoim niedbalstwie w kodzie.

Rzuciłem okiem na kod, endpoint do zapisywania chorób:

@PostMapping("/diseases")
    public ResponseEntity<?> createDisease(@RequestBody Disease disease) {
        if(diseaseRepository.findById(disease.getId()).isPresent()) {
            logger.info("choroba istnieje w bazie");
            return new ResponseEntity<>(HttpStatus.CONFLICT);
        }
        return  new ResponseEntity<>(HttpStatus.CREATED);
    }

Gdzie tu jest zapis? :D No i unikałbym stosowania ? w konkretnym, nie-generycznym kontrolerze.

@witold12

• jeśli chodzi o pakiety to masz układ typowo z tutoriala, poczytaj o package by feature http://www.javapractices.com/topic/TopicAction.do?Id=205

Ja osobiście się z tym podziałem package by feature nie zgadzam, szczególnie z takim jak pokazany w tym artykule. Moim zdaniem podział na zasadzie moduły by feature a wewnątrz modułu podział na warstwy jest dużo sensowniejszy, bo z jednej strony masz moduły odpowiedzialne za niezależne ficzery, a z drugiej strony masz oddzielone pakiety infrastrukturalne (jak kontrolery i repozytoria) i pakiety z logiką domenową. Ale nawet i to ma sens tylko jeśli serio masz tam rozbudowaną logikę i coś się tam faktycznie dzieje, bo jak ktoś ma 3 klasy i robi z tego projekt na 5 modułów i 50 pakietów to czasem brakuje słów.

• naucz się i korzystaj z dockera

gdzie tam jest miejsce na dockera w ogóle?

W sumie ciężko na tej stronie znaleźć kto w ogóle za nią stoi, nie wiem więc czemu ktoś miałby brać te porady na poważnie.

Poza tym, ze wszystkimi tymi poradami typu package by feature, package private i fasady czy DDD problem jest taki, że ludzie którzy promują te idee prezentują je na bardzo prostych przykładach i nieskomplikowanej domenie. W realnym świecie domena jest często na tyle zawiła, że nie da się tak łatwo wydzielić niepowiązanych ze sobą features.

@witold12 @tdudzik Ok, dzięki :)
Hmmm... więc brakuje logiki i testów w tym projekcie... coś poza tym?

Mam POMYSŁ ! :)
Czy aplikacja webowa komunikujący się z zewnętrznym api będzie dobrym pomysłem? np. Yahoo - restowe zapytania do wyciągania notowań akcji spółek giełdowych + prosta 2-stronicowa warstwa frontendowa w react albo angular

Osobiście nie jestem fanem side projectów i mam problemy z wymyślaniem czegoś ciekawego. Załapałem się do branży jak jeszcze było łatwo, a w CV miałem jakiś system rezerwacji w JEE (z webowym interfejsem, lekką logiką i testami) i jakiś niedokończony poker (z TDD). Wtedy wystarczyło, a teraz już nie mam żadnych projektów w CV i daje radę.

Z jakichś pomysłów, które może nie są świetne, ale lepsze niż CRUD to np:

• collaborative LaTeX editor - możesz wykorzystać np. serwer LSP (https://texlab.netlify.com/), algorytm OT (https://en.wikipedia.org/wiki/Operational_transformation) i jakieś ciekawe technologie frontendowe, backendowe pewnie też,
• turowa gra multiplayer, np. statki czy poker - tutaj można poszaleć na backendzie + np. frontend oparty o websockety, można też rozważyć JSON-RPC, gRPC czy protobuf
• mobilna, aplikacja do zdalnego sterowania samochodem (samochodzikiem) - tutaj też można poszaleć, zarówno po stronie mobilnej (można skorzystać z jakichś sensorów), ale też choćby z elektroniką i dodać np. automatyczne hamowanie kiedy utracona jest łączność.

Nie są to co prawda typowe projekty pod Springa, ale nie wiem też czemu się tak ograniczać i na mnie coś takiego zrobiłoby większe wrażenie niż kolejny CRUD. Każdy z nich pokaże, że się przyłożyłeś, zaimplementowałeś jakiś algorytm lub rozwiązałeś techniczny projekt, potrafiłeś zrozumieć różne technologie i zagłębić się w rózne specyfikacje. Może też pokazać, że umiesz pisać dobry kod, jeżeli komuś będzie chciało się wejść na githuba i go przeglądać. Prawda jest jednak taka, że na staż umiejętność pisania pięknego kodu nie jest kluczowa i wiele osób przekona sam opis projektów, a reszta wyjdzie na rozmowie.