Pragmatic developer

Przeglądając internet zauważyłem nurtujący nowych (ale nie tylko) programistów temat "Wzorce projektowe". Po co one są? Jakie powinniśmy znać? Czy znajomość ich w czymś pomaga? Czy warto się ich uczyć? Spróbuje odpowiedzieć na te ciężkie (bo trzeba przyznać, że każdy programista ma inne zdanie na ten temat) pytania. Co to są wzorce projektowe? Wzorce projektowe są rozwiązaniami problemów tworzenia oprogramowania, które są opisane, posiadają swoją, znaną przez użytkowników nazwę oraz definiują kiedy warto, a kiedy nie warto je używać. Definicja odpowiada już na dwa pytania: Po co one są? Do rozwiązywania problemów tworzenia oprogramowania. Czy znajomość ich w czymś pomaga? W rozwiązaniu problemu programistycznego. Można powiedzieć, że wzorzec projektowy to taka dobra praktyka rozwiązania problemu. Jest powszechnie używany i ukazane są jego zalety i wady. Czy warto je znać, a jak tak to jakie? Tutaj nie ma już prostych odpowiedzi. Uważam, że warto znać jak naj

Spotkałem się z problemem nazewnictwa testów jednostkowych, jak pisać oraz co w nich sprawdzać. Sposobów rozwiązania tych wszystkich problemów jest masę. Przedstawię kilka dobrych zasad, które pozwolą na długą i owocną pracę z testami. Spróbuje je wytłumaczyć i pokazać zalety takiego prowadzenia testów. Nazewnictwo Najważniejszą zasadą jest to, aby nazwy testów przedstawiały nam jasno co one testują. Nie ważne jak to uzyskacie. Ważne, aby powracając nawet po kilku latach nie mieć problemów z odczytaniem co test miał testować. Dlaczego to takie ważne? Mam kilka argumentów do tej zasady: Testów jest dużo więcej niż logiki, dlatego jest duża szansa, że nie będziemy pamiętać co dany test robił. Z jasnymi nazwami testów, gdy przestanie nam działać duża ilość, możemy bez zaglądania w kod wywnioskować co się po zepsuło. Metod testów nie używa się w logice, w kodzie, nigdzie. Z tego powodu ani konwencja nazewnicza, ani długa nazwa, ani cyfry, znaczki, cokolwiek nie będzie pr

W poprzednim wpisie opisałem jak działa Spring Security. Przedstawię Wam teraz jak wygląda implementacja tych rzeczy. W przykładach używam Java Configuration. Aplikacja, która zostaje zabezpieczona jest aplikacją internetową. Wybrałem taką, ponieważ to do takich aplikacji najczęściej jest ten framework używany. Inicjatory Klasy, które rozpoczynają pracę z aplikacjami internetowymi. Serwer aplikacyjny inicjuje kontekst oraz inne z tym związane rzeczy właśnie przez takiego rodzaju klasy. Jest to alternatywa dla web.xml. U mnie takim inicjatorem jest poniższa klasa: Ona sama w sobie nic nie robi. Jednakże rozszerza ona klasę abstrakcyjną AbstractSecurityWebApplicationInitializer. Klasa bazowa robi za nas całą konfigurację, którą potrzebujemy aby rozpocząć pracę z Spring Security dla aplikacji webowych. Tworzy ona kontekst aplikacji, jeżeli użyliśmy konstruktora klasy bazowej z argumentem klas konfiguracyjnych (np. wywołując ją w konstruktorze klasy podrzędnej) oraz dodaje filtr do za

Ostatnio w pracy zauważyłem pewną cechę w Spring Data JPA, którą chciałbym się z wami podzielić. Okazuje się, że w JPA modyfikowanego obiektu nie trzeba na końcu zmian zapisywać metodą T save(T entity). Dlaczego tak się dzieje? W trakcie pracy z JPA działamy na obiektach tak samo jak byśmy działali na encjach. Używając metody T save(T entity) przydzielamy obiekt do obiektów obsługiwanych przez JPA. Wniosek jest taki, że każdy nowy obiekt, który chcemy stworzyć w bazie musimy zakończyć potwierdzeniem tego metodą zapisującą. Inaczej jest z obiektami, które pobieramy. Pobieramy obiekt jest już obsługiwany, dlatego każda zmiana na tym obiekcie będzie kończyła się zmianą wartości w bazie danych. A co jeżeli nie chcemy, aby tak się działo? Są rozwiązania i obejścia tego mechanizmu. Jednym z rozwiązań jest wykonanie metody detach() z konkretnym obiektem lub clear() na EntityManagerze. Metody te usuwają z kontekstu JPA obiekty i przestają je obsługiwać. Przeczytałem także o szybkim obej

Spring Framework jest jednym z najbardziej popularnych szkieletów tworzenia aplikacji dla języka Java (i nie tylko). Aktualnie posiada ona bardzo dużo modułów ułatwiających pisanie aplikacji webowych, korzystających z repozytoriów danych, transakcyjnych, potrzebujących zabezpieczeń autoryzacji i uwierzytelniania itd.. Szeroka gama rozwiązań problemów programistycznych oraz architektonicznych aplikacji została już przez nich rozwiązana, a programiści muszą zająć się tylko jej kofiguracją. Dlaczego Spring jest taki dobry? W czym tkwi sekret takiej popularyzacji? Kontekst, czyli kontener IoC Zacznę od krótkiego wytłumaczenia co to jest IoC (Inversion of Control), czyli odwrócenie sterowania. Jest to sposób budowania architektury obiektowego programu. Polega on na użyciu zewnętrznego procesu, który dostarcza odpowiednie obiekty klas implementujących interfejs, który potrzebujemy lub używamy. W klasycznym podejściu do tematu obiekty są tworzone w klasie, którą używamy (w konstruktorze, w

Postanowiłem poczytać i zaznajomić się z technologią Spring Security. Przedstawię Wam, wiedzę którą zdobyłem w sposób jaki ja bym chciał ją zdobyć. Mam nadzieję, że tym wpisem pomogę Wam zrozumieć jak działa spring security. Co to jest Spring Security i do czego służy? Spring Security to framework, który służy do zabezpieczenia aplikacji. Skupia się ona na warstwie samej aplikacji i zajmuje się dwoma zagadnieniami: uwierzytelnianiem (sprawdzenie kim jest użytkownik, czyli logowanie wszelkiego rodzaju) i autoryzowaniem (sprawdzeniem czy użytkownik ma prawa do zasobów (stron, plików, zapytań itd.)). Stał się bardzo popularny w rozwiązaniach biznesowych, ponieważ pozwalają na prostą i szybką konfigurację tej warstwy zabezpieczeń. Framework stale jest rozwijany i uzyskuje coraz to nowsze rozwiązania. W trakcie pisania tego wpisu posiada już kilkanaście gotowych rozwiązań. Jednocześnie umożliwia implementacje własnych rozwiązań. Do czego używać? Spring Security można używać do każdej ap

Postanowiłem stworzyć prosty minutnik w celu zaprezentowania proces tworzenia GUI w technologii JavaFX. Od czego zacząć? Zaczynając pracę z JavaFX 8 wystarczy mieć JDK 1.8. Biblioteki są zawarte w narzędziach deweloperskich Javy. Klasa uruchomieniowa Klasa główna powinna rozszerzać klasę javafx.application.Application, która pozwala w łatwy sposób uruchomić samodzielną aplikację. W funkcji main wywołujemy metodę launch(String... args) z argumentami aplikacji. Klasa Application jest klasą abstrakcyjną z jedną metodą do zaimplementowania. W funkcji abstrakcyjnej start(Stage stage) piszemy początkowy kod naszej aplikacji. U mnie klasa wygląda następująco: Ustawiam ikonę do okna aplikacji. Następnie wywołuję klasę, która reprezentuje mi scene konfiguracji minutnika. Teraz przedstawię wygląd pliku fxml: Przedstawię co dokładnie zaimplementowałem. <?import java.lang.*?> <?import java.net.*?> <?import java.util.*?> <?import javafx.scene.*?> <?import javaf

Szukając alternatywy dla swing'a do tworzenia GUI aplikacji desktopowych spotkałem JavaFX. Nazwa wydawała mi się znajoma, którą widziałem na różnych stronach oraz w netbeansie. Zawsze jednak myślałem, że to jakiś framework dla specjalnej platformy (np. jakiś android czy coś). Bardzo się jednak myliłem. Okazuje się, że sam Oracle uważa JavaFX za alternatywę do Swing'a i dlatego postanowiłem się bliżej przyjrzeć tej technologii. Po co w ogóle alternatywa? Przypuszczam, że każdy kto próbował pisać aplikacji w Swing'u, odczuł wrażenie, że robi masę niepotrzebnych rzeczy. Stworzenie prostego GUI zajmowało dużo czasu. Jednocześnie jak już coś się stworzyło to strach było poruszyć jedną kontrolką, żeby nie rozwaliło się całe GUI. Oczywiście dało się napisać to tak, aby strachu nie było. Tylko zajmowało to jeszcze więcej czasu. Swojego czasu używałem SWT/JFace. Muszę przyznać, że wolałem go od Swing'a. Rozkładanie kontrolek było bardziej intuicyjne, a obiekty pozwalały na le

Kontynuujmy aplikacje z poprzedniego wpisu licznik życia . Dodamy do niego połączenie z bazą danych. Wykorzystamy do tego bazę h2, HikariDataSource, Hibernate i tytułowy JPA Spring Data. Pokażę i wytłumaczę jak to działa w praktyce z uwzględnieniem teorii na ten temat. Proponuję zajrzeć do mojego poprzedniego wpisu w którym przeczytacie jak działają warstwy połączenia z bazą danych aplikacji Java . W celu prezentacji stworzę osobny projekt, który będzie zaczątkiem do aplikacji samodzielnej. Dołączę do niego poprzedni projekt, który będzie służył za logikę aplikacji. Efekt ten zyskuje dodając do pom'a dane o projekcie. Grupa oraz wersja jest identyczna jak w nowym projekcie. Różnią się jedynie nazwa projektu (artifactId). Wykonuję to poniższym fragmentem pliku: <dependency> <groupId>${project.groupId}</groupId> <artifactId>lifetimer</artifactId> <version>${project.version}</version> </dependency> Zajmijmy się teraz sam

Postanowiłem trochę przybliżyć temat połączenia aplikacji Javowych z bazą danych. Aktualnie dużo osób w internecie szuka rozwiązań, bo coś im nie działa. Problem leży w tym, że dużo programistów nawet nie wie jak to powinno działać. Powiedzieć można, że "automagicznie" tworzą się obiekty z bazy i w drugą stronę. Tak mówię już o obiektach, ponieważ teraz w erze hibernate, a nawet spring data jpa, nikt nawet nie zastanawia się jak zwracane są dane. Wystarczy przekopiować działającą konfiguracje i wszystko gotowe. Połączenie z bazą danych, czyli JDBC. JDBC (Java DataBase Connectivity) jest to API do komunikacji aplikacji z bazami danych. Wszyscy pewnie zauważyli, że to jest interfejs. Konkretną implementację (zwaną czasem sterownikiem) trzeba szukać pod bazę danych, którą chcemy wykorzystać. Na co pozwala JDBC? Posiadając sterownik do bazy możemy: połączyć się z nią, wykonać na niej zapytanie, obsłużyć tranzakcyjność. Zrobić możemy, na tym etapie, już wszy

Napiszemy sobie serwis do obsługi czasu, będziemy go dodawać do repozytorium. Nie zdecydowałem jeszcze jaki nośnik pamięci to będzie dlatego do wytestowania wykorzystamy framework Mockito. Jednocześnie niektóre czasy będą się składały na czasy ogólniejsze. Zacznijmy od stworzenia atrapy obiektu interfejsu Repository. Interfejs na razie jest pusty ponieważ nie wiem jakie metody będziemy potrzebować. Wykorzystamy do tego adnotację @Mock, ktory działa na zasadzie Dependency Injection. Następnie utworzymy obiekt naszego serwisu. Obiekty tego typu z założenia nie powinny przechowywać stanu wewnętrznego. Wykorzystując to stworzymy jeden obiekt dla wszystkich testów. Potrzebujemy jednocześnie, żeby stworzony w teście Mock został wstrzyknięty do naszej klasy serwisowej. Używamy do tej czynności adnotacji @InjectMocks. Ok. Mamy już stworzone puste obiekty. Chcielibyśmy jednak, aby coś one robiły. Bierzmy się więc do roboty. Napiszmy test, że wraz z użyciem w serwisie metody "add"

Co to jest Mockito? Mockito to framework stworzony dla testów jednostkowych Javy. Stosuje się go do utworzenia atrapy obiektu (Mock'a) w celu zaślepienia funkcji lub weryfikacji zdarzeń na nim wykonanych. Dlaczego stosuje się mocki? Testy pisane z atrapami są czytelniejsze i przyjemniejsze do debugowania. Jednocześnie łatwiejsze do napisania, ponieważ autor testu nie musi znać implementacji funkcji aktualnie nietestowanej, która wykorzystywana jest w testowanym fragmencie kodu. Przeznaczamy, dzięki temu, mniej czasu na przygotowanie danych wejściowych i dostajemy gwarancje, że zmiana kodu innej funkcji nie zepsuje stworzonych testów. Na co pozwala Mockito? Pierwszą czynnością, którą możemy zrobić to stworzenie atrap obiektów. Pozwala nam to na używanie obiektów jeszcze niezaimplementowanych. Alternatywą tego zastosowania byłoby stworzenie pustej klasy, ale to nie jest ładne rozwiązanie, ani przyjemne, ani wydajne. Drugą funkcjonalnością jest przypisanie do poszczególnych meto