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