Mirki, trochę się ogarnąłem z #java i stwierdziłem, że projekt, który rozgrzebałem jest ponad moje siły, jak na pierwszy projekt początkującego - prosty menadżer magazynu sklepowego okazał się być wcale nie tak prosty. Postanowiłem zrobić zatem inną, mniej skomplikowaną apkę.
Docelowo TimeKeeper, bo tak się nazywa, ma być zegarem/timerem do śledzenia czasu poświęconego na pracę nad danym zadaniem (inspiracją był blogowy wpis @JavaDevMatt). Jeśli chodzi o rozwiązania projektowe: dane przechowywane są w pliku .csv, ale podłączenie bazy danych przez np. Hibernate nie powinno być problemem (podmiana implementacji interfejsu + dodanie adnotacji, albo pliku xml). Każda część GUI jest obsługiwana przez odrębny kontroler. Dzięki temu nie ma jednego wielkiego pliku FXML, tylko kilka odrębnych mniejszych, a i sama klasa kontrolera jest znacznie mniejsza. DI jest rozwiązane bez framework'u, w głównym pliku FXML, który instancjuje kontrolery poszczególnych elementów UI i wstrzykuje do głównego kontrolera.

Apka ma też dawać możliwość zwinięcia do paska systemowego, ale póki co JavaFX nie pozwala na to (tzn. jest obejście z wykorzystaniem Swing'a, ale wolałbym go uniknąć). Na chwilę obecną zaimplementowana jest podstawowa funkcjonalność, tj. mierzenie czasu od dodania zadania do jego ukończenia z możliwością zapauzowania. Zmiany zapisywane są automatycznie co minutę plus przy każdym zapauzowaniu zadania Chcę dodać w najbliższym czasie kolumnę z ikonami (uruchomiona, zatrzymana, zakończona, +1h, +3h, +5h, +10h), pasek statusu i legenda u dołu i tooltipy oraz ogarnąć do końca wygląd okna i poszczególnych elementów. Mój #rozowypasek zasugerował, żeby dodać też opcję timer'a (odliczanie czasu od zadanej wartości do zera i później czasu ile przekroczono zadaną wartość).

Czego się nauczyłem przy
k.....e - Mirki, trochę się ogarnąłem z #java i stwierdziłem, że projekt, który rozgr...

źródło: comment_vqhD1LY0shp2YTcXGuCrfmDCwZhJGies.jpg

Pobierz
@kitke: jeśli można się przyczepić to na pewno do e.printStackTrace() przy wyjątkach np. operacji plikowych. Powinien pokazać się jakiś komunikat o błędzie dla użytkownika...
  • Odpowiedz
Mirki, małe podsumowanie postępów, wolniejszych zresztą niż przewidywałem (robota i grypa swoje musiały zająć...). Od momentu coming-out'u coming-out'u, wydaje mi się, że udało mi się projekt posunąć we właściwym kierunku. Ogarnąłem podstawowe funkcjonalności Hibernate na tyle, że napisałem proste DAO pozwalające na zapis i wczytywanie danych do bazy (na początku planowałem SQLite, ale ze względu na brak pełnego wsparcia Hibernate, przesiadłem się na HSQLDB), ogarnąłem też podstawowe klasy opisujące przedmiot i jego ceny i klasę reprezentującą stawki podatku VAT potrzebną do wyliczania cen.

Do zrobienia na nabliższe tygodnie:
- ogarnąć zależności między klasami:
- najważniejszym obiektem jest obiekt DAO i wydaje mi się, że najsensowniej będzie zrobić nadrzędny obiekt, na poziomie którego obiekt DAO będzie wstrzykiwany przez konstruktor do obiektów wymagających dostępu do bazy (przede wszystkim obiektu reprezentującego magazyn sklepowy, w którym będą przechowywane przedmioty).
- ogarnąć metody pobierania/dodawania/usuwaniu/wyszkiwania danych w obiekcie DAO. Zależy mi na tym, żeby było jak najbardziej uniwersalne i żebym w razie potrzeby miał gotową klasę, która z powodzeniem da się użyć w innym projekcie opartym o Hibernate. Narazie w metodach pobierania/dodawania używam klasy Object, ale jest to niewygodne ze względu na konieczność późniejszego rzutowania. Rzecz do ogarnięcia: Generics (nie znam zgrabnego terminu polskiego). Narazie klasa jest zaśmiecona i wymaga uproszczenia i
@kitke: Siemka,

z tym DAO to entityManager jest sam w sobie implementacją DAO. To czego szukasz to Service

jeśli chodzi o uniwersalność to nie robimy na Object. Możesz zrobić generyczne (generic) service realizujące takie
  • Odpowiedz
OK, zgodnie z obietnicą, cotygodniowa aktualizacja.
Zapiernicz w pracy i bobo w domu mocno ograniczyły mi czas w tym tygodniu, więc prace posuwają się w tempie ślimaka wyścigowego. Co zatem się udało. Zgodnie z sugestą @mamapoth zrezygnowałem z używania zmiennych zmiennoprzecinkowych do przechowywania informacji o kasie. Popatrzyłem za info w sieci (thank you Stackoverflow!) i najłatwiej - chociaż z punktu widzenia wydajności programu, niezbyt optymalnie - będzie sprawę ogarnąć używając BigDecimal - tu artykuł o tym W przybliżeniu klasa ta pozwala na wykonywania obliczeń o dużej dokładności, a później zaokrąglania wyników zgodnie ze zdefiniowaną dokładnością i regułami.

Jak już pisałem, czytam Roberta C. Martina, Czysty Kod (dotarłem do połowy książki), w kolejce mam jeszcze parę innych prac. Wczoraj napisałem sobie w ramach treningu prosty parser tekstu, który przyda mi się w robocie, ułatwiając nudną pracę. Mam 40-stronicowy plik, w miarę jednolicie sformatowany, zawierający nazwiska autorów piszących do czasopisma wydawanego przez wydział, którym pracuję, i adresy URL do ich profili w bazie nauka polska. Wszystko to musi trafić na stronę internetową. Zamiast ręcznie klepać <p class="... <a href="... napisałem programik, który robi to za mnie :-) Pierwsze #profity z nauki Java już zatem są :D

Parę rzeczy, nad rozkminieniem których zastanawiam się w głównym projekcie. Kto zaglądał na GitHub'a ten wie, ze mam klasę Item, która opisuje przedmiot przechowywany w magazynie (Storehouse) sklepu. Przedmiot ma w sumie 9 'właściwości'/zmiennych instancyjnych: 1. nazwę, 2. symbol PKWiU, 3. cenę zakupu, 4. cenę netto, 5.
1. robisz centralnie miejsce konfigurowania obiektów i ustalasz, że prosząc o „db” zawsze dostaniesz jeden i ten sam obiekt.
2. wstrzykujesz ten obiekt innym obiektom, które go potrzebują (najlepiej w konstruktorze)

Na cholerę komuś Singletony i wszechobecne statyczne getInstance()? Mamy 21. wiek i fw z DIC!
  • Odpowiedz
Czytam, za radą @CamelCase, książkę R. C. Martin'a, Czysty Kod. Podręcznik dobrego programisty. Zanim kupiłem wydanie polskie zacząłem czytać ją po angielsku (Clean code. A Handbook of Agile Software Craftsmanship). I o ile wersję angielską czyta się z dużą przyjemnością o tyle polski przekład mnie męczy. Odnoszę wrażenie, że równie mocno męczył się tłumacz przekładając bądź co bądź techniczny żargon, którym Martin bez przerwy operuje. Oprócz doznań natury, powiedzmy, estetycznej mam wrażenie, że przekład zaciemnia myśl wyłożoną w wersji angielskiej i po prostu utrudnia zrozumienie książki.

Dodam tylko, że nie jest to odosobniony przypadek. Wszystkie tłumaczenia prac anglojęzycznych dotyczących programowania odrzucały mnie ze względu na szorstki język przekładu utrudniający zrozumienie pracy.

Wniosek, jeśli tylko można, lepiej czytać w oryginale