Archiwa kategorii: Średnio zaawansowane

Wpisy dla programistów (także początkujących)

Zawrót głowy w Scali: class, trait, object, instancja

Fajne rzeczy w Scali: klasy przypadkówKiedy jako programista Javy po raz pierwszy ujrzałam kod napisany w Scali, miałam spore problemy ze zrozumieniem, czym różnią się od siebie poszczególne byty:

  • class (klasa)
  • case class (klasa przypadków)
  • trait (cecha)
  • object (obiekt)
  • instancje klas (bo “obiekt” w Scali to wcale nie jest instancja!).

Poniżej ściąga dla zainteresowanych i dla przyszłej mnie 🙂

Klasa

Klasa (class) jak w przypadku większości obiektowych języków programowania, to szablon, na podstawie którego można tworzyć ukonkretnione instancje. Zawiera pola i metody. Ponieważ Scala jest językiem funkcyjnym, dobrym zwyczajem jest tworzenie klas niemodyfikowalnych.

Klasa przypadków

O klasach przypadków (case class) więcej napisałam tutaj: Fajne rzeczy w Scali: klasy przypadków. Klasy przypadków to specjalne klasy, których instancje można porównywać przez wartość i dopasowywać do wzorców w ramach instrukcji match.

Cecha

Cechy (trait) są podobne do klas i umożliwiają wielokrotne dziedziczenie (które ostatecznie i tak jest linearyzowane przez kompilator, ale nie o tym teraz). Różne byty (klasy, obiekty, cechy) w Scali mogą rozszerzać jedną tylko klasę, ale za to wiele cech.

Przy dziedziczeniu z kilku cech trzeba użyć słowa kluczowego with:

Jeśli wśród “rodziców” znajduje się jakaś klasa, musi ona zostać wymieniona pierwsza, zaraz po słowie extends.

Nie można tworzyć instancji cech.

Cechy można dodawać do klas na etapie ich definicji, ale także do instancji na etapie ich tworzenia. Cechę można dorzucić do właściwie każdej klasy – chyba że ograniczymy listę dozwolonych typów przy użyciu słowa kluczowego self (co ma sens np. jeśli kod którejś z metod odwołuje się do pola istniejącego tylko w danej hierarchii klas).

Obiekt

Obiekt (object) w Scali to klasa, która może miec maksymalnie jedną instancję – a więc, innymi słowy, singleton. Instancja ta zostanie utworzona w momencie pierwszego dostępu do niej przez JVM. Obiekty umożliwiają tworzenie odpowiedników metod i pól statycznych (globalnych), tj. atrybutów niepowiązanych z konkretną instancją klasy.

Obiekt może dziedziczyć z jakiejś klasy albo cechy.

Często stosowanym wzorcem w Scali są obiekty towarzyszące. Obiekt towarzyszący ma taką samą nazwę jak klasa, jest definiowany w tym samym pliku i ma (z wzajemnością) dostęp do jej prywatnych pól i metod. Obiekty towarzyszące mogą pełnić funkcję fabryki instancji danej klasy.

Kolejne zastosowanie obiektów to aplikacje w linii poleceń. Wewnątrz obiektu można zdefiniować metodę main, która zostanie uruchomiona po wywołaniu kodu z linii poleceń.

Instancja

Instancja to instancja 🙂 czyli konkretny jeden byt stworzony w oparciu o wzór opisany w ramach klasy.

Przyznam, że w mojej własnej głowie nietypowe użycie słowa object narobiło sporo zamieszania. Podejrzewam, że w miarę poznawania języka zrozumiem, dlaczego tak się stało i przestanie mnie to zaskakiwać.

Gdzie znaleźć więcej szczegółów?

Oto kilka źródeł dogłębniej tłumaczących omawiane to różnice:

Fajne rzeczy w Scali: klasy przypadków

Skończyłam pierwszy z pięciu kursów programowania w języku Scala w pięciokursowej specjalizacji na Courserze, prowadzonej przez twórcę tego języka.

Kolejna ciekawa cecha języka, jaką poznałam, to klasy przypadków (ang. case classes) i dopasowywanie wzorców (ang. pattern matching).

Instrukcje wielokrotnego wyboru i wzorce w innych językach

W wielu językach programowania istnieje jakaś forma instrukcji switch. W Javie pozwala  ona dokonywać wyboru dla zmiennej typu prostego oraz, nie od początku, zmiennej typu String. Na przykład:

Dopasowywanie wzorców i instrukcja match w Scali

Niektóre języki, w tym Scala, idą o krok dalej. Instrukcji wielokrotnego wyboru można w nich używać nie tylko na danych typów prostych. Co więcej, dopasoowywanie wzorców pozwala nam opisać przypadki w sposób niepełny – np. z zastosowaniem symboli wieloznacznych (ang. wildcards).

Poniżej przykład ze Scali, w którym przetwarzane są wierzchołki drzewa binarnego – osobno wierzchołki wewnętrzne (Fork), osobno liście (Leaf) drzewa.

W zależności od typu wierzchołka (Fork lub Leaf) oraz od wartości jednego z pól w przypadku klasy Leaf, w odmienny sposób zwrócona zostanie waga wierzchołka.

Nieistotne parametry zostały zastąpione symbolem _, który dopasuje się do wszystkiego.  Istotnym parametrom przypisujemy nazwę, dzięki czemu będzie można się do nich odwołać. Można też użyć ukonkretnionych wartości, żeby zdefiniować konkretne przypadki.

Po prawej stronie case nie ma żadnego przypisania ani instrukcji, ponieważ match jest wyrażeniem – zwróci jako wartość prawą stronę operatora =>.

Test  powyższej funkcji (przechodzący, daję słowo):

Klasy przypadków i ich cechy

Brakuje jeszcze definicji klas Leaf oraz Fork. Jak łatwo się domyślić, żeby używać ich w ten sposób, klasy te muszą zostać zdefiniowane jako klasy przypadków.

Ich definicja wygląda tak:

Klasy przypadków:

  • definiuje się z użyciem słowa kluczowego case,
  • powinny być niemodyfikowalne,
  • są porównywane przez podobieństwo strukturalne i wartości, a nie przez referencję,
  • wartości przekazane w konstruktorze są publicznie dostępne.

FAQ

Poniżej kilka szybkich pytań i odpowiedzi:

Q1: Co się stanie, jeśli nie przewidzisz wszystkich wzorców i na etapie wywołania okaże się, że zmienna nie pasuje do żadnego wzorca?
A1:  Otrzymasz scala.MatchError.

Q2: Jak utworzyć odpowiednik javowego default?
A2: Tak:

Q3: Czy to działa także dla typów prostych.
A3: Tak. Co więcej, możliwa jest nawet taka operacja:

PS.

Bardzo to wszystko wygodne i czytelne.

O, podstawowa dokumentacja Scali została przetłumaczona na język polski!

Fajne rzeczy w Scali: zwracanie funkcji

Kontynuuję kurs programowania w języku Scala, o którym wspominałam w poprzednim wpisie.  Zgodnie z obietnicą, pokazuję kolejną fajną rzecz, której się nauczyłam.

Funkcje, które zwracają funkcje!

W Scali funkcje są tzw. obywatelami pierwszej kategorii (ang. first class citizens).  Inaczej, funkcje są pierwszoklasowe. Oznacza to, że można z nimi robić wszystko to, co można robić z “normalnymi” typami danych, to jest: przekazywać jako argumenty, przypisywać do zmiennych, zwracać z funkcji, tworzyć je na bieżąco.

W szczególności, jedna funkcja może zwrócić inną. Poniżej przykład.

Na początku tworzymy alias o nazwie Set. Reprezentuje on typ funkcyjny: wszystkie funkcje pobierające parametr typu Int i zwracające wartość typu Boolean. W ten sposób chcemy, na potrzeby przykładu, reprezentować zbiory: jako funkcję, która dla każdej podanej liczby całkowitej powie nam, czy liczba ta należy do tego zbioru.

Jeśli nasz zbiór ma być zbiorem jednoelementowym (ang. singleton), to w zależności od tego, jaki to element, musielibyśmy utworzyć (nieskończenie) wiele funkcji sprawdzających, przynależność do zbioru – dla każdego możliwego elementu zbioru jednostkowego. Osobno dla zbioru zawierającego tylko liczbę 1, osobno dla liczby 2 itp. Dzięki możliwości zwracania funkcji, mamy tylko jedną funkcję, która tworzy i zwraca funkcję badającą przynależność do zbioru jednostkowego zawierającego wybrany element – przekazany jako parametr do funkcji singletonSet.

Jak to działa w praktyce?

Na początku testu tworzymy zbiór jednoelementowy zawierający liczbę całkowitą 4. Nasz zbiór – czyli funkcję pobierającą argument Int, zwróconą z funkcji singletonSet – przypisujemy do zmiennej (hm, stałej właściwie) single.

Następnie, wywołując funkcję przypisaną do zmiennej single, sprawdzamy, czy do zbioru {4} należą odpowiednio liczby 4 oraz 1. Zgodnie z oczekiwaniami, dla 4 otrzymujemy wartość true, dla 1 wartość false.

Uczę się Scali!

Zapisałam się na kurs programowania w języku Scala. Prowadzi go na Courserze twórca tego języka, Martin Odersky.

Postanowiłam po każdym tygodniu kursu dzielić się jakimś spostrzeżeniem albo cechą języka.

Co spodobało mi się w pierwszym tygodniu? Możliwość definiowania funkcji zagnieżdżonych, czyli funkcji w funkcjach. Poniżej przedstawiam definicję funkcji rekurencyjnej spradzającej parzystość nawiasów. Pomocnicza funkcja z dodatkowym parametrem jest zdefiniowana wewnątrz niej.

Co to daje? Przede wszystkim, funkcje pomocnicze przeznaczone do jednokrotnego użycia nie zaśmiecają przestrzeni nazw. Oczywiście w Javie zdefiniowałabym taką funkcję jako prywatną, więc do “zaśmiecenia” doszłoby tylko w ramach jednej klasy – ale i to potrafi uprzykrzyć kodowanie, np. kiedy IDE podpowiada mi wersje metody zamiast jednej.

Scala nie jest jedynym językiem pozwalającym na stosowanie zagnieżdżonych funkcji. Pełna lista jest dostępna w Wikipedii, w artykule o funkcjach zagnieżdżonych (opisane są tam też “obejścia” tego problemu w językach bez bezpośredniego wsparcia dla takich funkcji).

Inna rzecz, która przykuła mogą uwagę na kursie, to akcent prowadzącego. Nie mogłam się oprzeć i sprawdziłam, skąd pochodzi. Okazało się, że to Niemiec, ale pracujący we francuskojęzycznej części Szwajcarii.

Swoją droga, bardzo podobają mi się zadania domowe. Wymagają chwili pomyślunku, dobrze ilustrują treść wykładów – a przy tym nie zajmują bardzo dużo czasu.

Zachęcam do przyłączenia się do mnie na kursie!

“Stałe” w Javie:
final, static, i niemodyfikowalność

Wpis z dedykacją dla D, który postanowił nauczyć się nowego języka programowania i, chcąc utworzyć stałą (constant – słowo kluczowe niedostępne w Javie),  zapytał mnie o relację pomiędzy terminami: final, static i obiekt niemodyfikowalny (immutable).

final

Słowo final zmienia znaczenie w zależności od kontekstu, ale zawsze oznacza, że coś jest “ostateczne” i po utworzeniu nie da się już tego zmienić.

Klasa final

Jeśli klasę oznaczymy słowem final, nie będzie można jej rozszerzać, czyli tworzyć jej podklas. Zatem będzie to “ostateczna” wersja danej klasy.

Metoda final

Z metodami jest podobnie jak z klasami. Jeśli słowem final oznaczymy metodę, nie będzie można jej przesłaniać w klasach pochodnych – czyli mamy do czynienia z “ostateczną” wersją danej metody.

Zmienna final

Jeśli jako final opiszemy zwykłą zmienną w środku kodu, wartość (a dokładniej: wartość w przypadku typów prostych lub referencję w przypadku obiektów) będzie można jej przypisać maksymalnie raz. Na przykład:

Pole klasy final

Jeśli słowem final oznaczymy pole klasy, będzie to oznaczało, że wartość (lub referencję, jak powyżej) można mu nadać tylko raz – będzie ona ostateczna. Wartość tę można przypisać na dwa sposoby – albo “w miejscu”, przy definiowaniu klasy, albo w konstruktorze. Nie da się tego zrobić później. Jeśli pole final nie otrzyma wartości w żadnym z tych dwóch miejsc, kompilator zaprostesuje.

Za przykład niech posłuży fragment definicji klasy String z Javy 8:

Parametr final

Jeśli jako final oznaczymy parametr metody,  zablokujemy możliwość zmiany jego wartości. I tak nie powinniśmy tego robić – to jedna z dobrych praktyk. Użycie słowa final oficjalnie nas do niej zobowiązuje.

static

Słowo kluczowe static nie musi być łączone ze stałymi. Chcę jednak rozebrać je na czynniki pierwsze, ponieważ często spotyka się je razem z final w następujących konstrukcjach (ta akurat znów klasy String):

Słowo “statyczny”, jako przeciwieństwo “dynamiczny” można w uproszczeniu rozumieć w ten sposób, że opisany nim byt do życia nie potrzebuje obiektów (tworzonych dynamicznie).

Pole klasy static

Jeśli pole klasy zostanie oznaczone jako static (jak w przykładzie bezpośrednio powyżej), oznacza to, że jest współdzielone przez wszystkie obiekty danej klasy. Można uzyskać do niego dostęp odwołując się do nazwy obiektu lub do nazwy klasy – efekt będzie ten sam. Pamięć jest przydzielana tylko raz, podczas ładowania klasy.

W ten sposób można definiować ważne stałe albo różnego rodzaju liczniki (np. liczba egzemplarzy danej klasy – wówczas w konstruktorze zwiększamy wartość tego pola o 1).

Metoda static

Metoda static jest współdzielona przez wszystkie obiekty, można ją także wywołać odnosząc się bezpośrednio do nazwy klasy, bez potrzeby tworzenia obiektu.

Metoda ta ma dostęp jedynie do statycznych atrybutów (pól i metod) danej klasy. Co za tym idzie, nie może też używać słów this ani super.

W ten sposób często definiuje się różne metody pomocnicze – na przykład większość metod w klasy Math.

Najbardziej znana metoda statyczna to oczywiście main.

Blok kodu static

Wewnątrz definicji klasy można umieścić statyczny blok kodu, w którym, na przykład, zainicjalizujemy jakieś statyczne pola. Zostanie on wywołany w trakcie ładowania klasy.

Mimo że bloki statyczne rzadko pojawiają się w kodzie, kolejność ich wykonywania to konik wielu profesorów informatyki na egzaminach z programowania obiektowego.

Zagnieżdżona klasa static

Jeśli klasę zagnieżdżoną opiszemy słowem static, będzie ona mogła odwoływać się jedynie do statycznych atrybutów swojej klasy zewnętrznej.

Obiekty niemodyfikowalne

Obiekt niemodyfikowalny (immutable) to taki obiekt, w którym po użyciu konstruktora nie można już dokonywać żadnych zmian.

Przekazując taki obiekt, mamy pewność, że nie zostanie on zmieniony przez żaden kod – ani nasz, ani znajdujący się pod kontrolą kogoś innego. Obiekty niemodyfikowalne są wybawieniem podczas pracy z wątkami, ponieważ nie trzeba synchronizować ich stanu.

Niemutowalne są na przykład obiekty klasy Integer.

Oto fragment definicji tej klasy:

Wartość value (czyli liczbę typu prostego int opakowywaną przez klasę Integer) można ustawić jedynie przy użyciu któregoś z konstruktorów. Nie da się jej zmienić później. Klasa Integer ma szereg metod pozwalających uzyskać dostęp do tej wartości, ale sama wartość wewnątrz obiektu tej klasy nigdy  nie zostanie zmieniona. Nie jest do tego potrzebne słowo final (które zostało tu użyte) – wystarczyłaby sama enkapsulacja. final daje nam jednak niezbitą pewność, że po inicjalizacji nikt już tej wartości nie zmieni.

Co ma zrobić osoba, która potrzebuje innej liczby Integer? Będzie musiała po prostu utworzyć nowy obiekt.

Nie istnieje słowo kluczowe immutable. Obiekty niemodyfikowalne tworzy programista, korzystając z mechanizmu enkapsulacji oraz słowafinal.

Wszystko razem, czyli static final String

Rozważmy definicję poniższych pól:

Wszystkie trzy pola są opisane jako static final, czyli są to stałe współdzielone przez wszystkie obiekty danej klasy.

W pierwszym przypadku mamy stałą typu prostego. Sprawa jest oczywista – nie wolno nam zmienić jej wartości. Nie możemy przypisać pod ERROR_CODE żadnej innej wartości.

W drugim przypadku mamy obiekt. Jest to, dodatkowo, obiekt niemodyfikowalny (immutable). Uczący się Javy kolega zapytał ostatnio, po co dodawać final, skoro obiekt jest niemodyfikowalny. Po co? – żeby nie można było zmienić referencji. Gdyby nie słowo final, możliwa byłaby następująca operacja:

Obiekt String z wartością “Ouch” jest co prawda niemodyfikowalny (nie można zmienić przechowywanej w nim wartości), ale nic nie stałoby na przeszkodzie, żeby podmienić obiekty przypisane do zmiennej RESPONSE. Użycie final nas przed tym chroni.

W ostatnim przypadku mamy zwykły (modyfikowalny) obiekt ze zmiennym stanem, przypisany do pola oznaczonego jako final. Co to oznacza? Że co prawda, dzięki final, nie możemy zmienić referencji (to będzie nadal tem sam obiekt) ale ciągle możemy nieźle namieszać w jego wnętrzu przy użyciu API:

Jasne?

Odpowiedne korzystanie z javowych “stałych”, wartości statycznych i obiektów niemodyfikowalnych pozwala na oszczędzenie miejsca w pamięci i stworzenie czytelnego, łatwego w utrzymaniu kodu.

Wyrażenia regularne w Javie – figle i psikusy

To trzeci (i na jakiś czas ostatni) z serii wpisów na temat wyrażeń regularnych w Javie, po O wyrażeniach regularnych. Podstępna różnica pomiędzy find i matches oraz Wyrażenia regularne dla nieprogramistów. Historycznie ten jest najwcześniejszy – to zaktualizowana wersja tekstu z mojego poprzedniego bloga.

Poruszam tu bardzo podstawowe kwestie, które potrafią jednak dać się we znaki. Rozwiązanie tych paru niewinnych problemików kosztowało mnie niemało czasu i nerwów. Liczę, że kiedy jakaś zbłąkana dusza znajdzie się w tej samej sytuacji, Google zaprowadzi ją prosto w moje troskliwe ramiona.

Artykuł powstał podczas mojej pracy nad narzędziem do przekształcania metadanych.

Psikus 1: znaki ucieczki w wyrażeniach wczytywanych z zewnętrznego pliku

Załóżmy, że wyrażenie (które chcemy wczytać z zewnętrznego pliku) w zwykłym kodzie Javy wygląda tak:

Linia przedstawia zakres wieków, do którego dopasuje się na przykład linia:

Proste, prawda?

Prawda – ale do czasu. Problemy pojawiły się, kiedy zaczęłam wczytywać wyrażenia regularne zapisane w zewnętrznym pliku. Wczytywałam między innymi następujący fragment:

Wszystko przestało działać. Łańcuchy znaków, które bez najmniejszych wątpliwości powinny były dopasować się do wyrażenia, przechodziły niezauważone. Po godzinie analiz niebezpiecznie zbliżałam się do stanu, w którym myślałam, że oszalał albo świat dokoła mnie. Wtedy na szczęście nadeszła pora lunchu. Opowiedziałam o problemie nad talerzem naleśników, a jeden z kolegów zadał oczywiste w sumie pytanie – czy na pewno dobrze wyeskejpowałam (przepraszam!!!) wszystkie znaki specjalne. I wtedy wreszcie nadeszło olśnienie: nie, nie zrobiłam tego dobrze. Przeeskejpowałam je.

Znaki specjalne, takie jak d, w wyrażeniu regularnym oznaczające cyfrę, należy poprzedzić tzw. symbolem ucieczki, czyli w tym wypadku backslashem (ukośnikiem wstecznym). W łańcuchach znaków w kodzie Javy konieczne jest wprowadzenie dodatkowego backslasha, gdyż musimy jeszcze odebrać specjalne znaczenie samemu backslashowi (musimy poprzedzić znak ucieczki znakiem ucieczki…). Tyle razy widziałam te dwa ukośniki w parze, że zupełnie zapomniałam o tym, że w zewnętrznym pliku należy użyć tylko jednego!

Psikus 2: flagi

To bardzo proste. Załóżmy, że wyrażenie nie ma brać pod uwagę wielkość liter. Normalnie oznaczamy to tak:

Świetnie, tylko jak przekazać tę flagę, jeśli wyrażenie jest wczytywane z zewnątrz? Wychodzi na to, że flagę, poprzedzoną znakiem zapytania, należy umieścić w nawiasie na początku wyrażenia. Ignorowanie wielkości liter (przy okazji, poznałam ostatnio nowe słowo – kasztowość) to literka i, zatem dodajemy (?i). Ostatecznie, w kodzie wyrażenie wygląda tak:

a poza kodem, z pojedynczymi ukośnikami, tak:

Psikus 3: String.replaceAll

W pewnym brzegowym przypadku mój kod, w wyniku wczytania wyrażeń regularnych z pliku, wykonywał operację, którą można w uproszczeniu zapisać tak:

Po wykonaniu się tego kodu spodziewałam się, że treść zostanie całkowicie zastąpiona, czyli wartością s będzie:

skoro * jest zachłannym kwantyfikatorem, to .* powinno dopasować się do całego napisu niezależnie od okoliczności.

Wyobraźcie sobie moje zaskoczenie (czy raczej przerażenie), gdy okazało się, że s przyjęło wartość:

Próbowałam użyć jeszcze bardziej zaborczego kwantyfikatora *+, ale efekt był ten sam. Byłabym mniej zaskoczona, gdyby .* zostało dopasowane do każdej litery w łańcuchu. Jakim cudem dopasowało się dokładnie dwa razy?

Dalsze śledztwo wykazało, że przebieg akcji jest następujący:

  1. Cały łańcuch dopasowuje się do .* i jest zamieniany na łańcuch “nowa treść”.
  2. Po dopasowaniu z oryginalnego łańcucha znaków nie zostaje nic, a raczej zostaje łańcuch "". Metoda replaceAll jeszcze raz sprawdza możliwość dopasowania i okazuje się, że "" także pasuje do .*, zatem pusty łańcuch również zostaje wymieniony.
  3. Zasadniczo można by kontynuować i w nieskończoność dodawać na końcu "nowa zawartość", jednak na szczęście (?) dana pozycja w łańcuchu znaków jest traktowana jako sprawdzona i wykonanie metody kończy się.

Pozdrawiam siostry i braci w cierpieniu.

O wyrażeniach regularnych. Podstępna różnica pomiędzy find i matches

Wyrażenia regularne to jedno z zagadnień dzielących programistów. Są tacy, którzy je uwielbiają i ci, którzy szczerze ich nienawidzą.

Sama zaliczam się do pierwszej grupy, być może z powodu upodobań lingwistycznych (wyrażenia regularne ≈  języki regularne ≈ automaty skończone). Wyrażenia regularne pozwalają na bardzo zwięzły i precyzyjny zapis warunków wyszukiwania, które – gdyby ograniczyć się do tradycyjnych konstrukcji zawartych w danym języku programowania – mogłyby zająć wiele linii. Po stronie minusów należy zapisać trudność zrozumienia dłuższych wyrażeń regularnych, zwłaszcza, jeśli są dziełem kogoś innego.

W tym wpisie chcę podzielić się swoją niedawną przygodą optymalizacyjną. W najbliższym czasie (czyli przed końcem roku) wrzucę jeszcze stary tekst o pułapkach, w które można wpaść pisząc wyrażenia regularne w Javie oraz nowy o tym, jak regeksy mogą przydać się nieprogramistom w ich codziennych zadaniach.

Do rzeczy.

Napisałam ostatnio kod analizujący treść stron internetowych. Mniejsza z tym, po co to robił. Stanowił część większej całości (moduł mavenowy) i podobnie jak reszta kodu korzystał m.in. z Javy 8 i biblioteki JSoup. Napisałam masę testów jednostkowych, testowałam na kilkuset stronach… Jednak prawdziwa próba ognia miała nadejść kilka dni po oddaniu przeze mnie projektu, podczas uruchomienia pełnego łańcucha przetwarzania na kilkudziesięciu (kilkuset?) tysiącach stron.

W pięciu przypadkach mój kod zawiesił się na ponad dobę.

Naprawa, kiedy już do niej zasiadłam zajęła mi niecałą godzinę. Co się okazało? W kilku miejscach w moim kodzie użyłam metody Element::getElementsByAttributeValueMatching i dałam się zwieść nazwie. Na swoją obronę mam to, że Javadoc też wprowadza w błąd. Otóż wyobraziłam sobie, że gdzieś w głębinach metoda wywołuje metodę Matcher::matches, dlatego szukany przeze mnie fragment otoczyłam znakami ".*" przed i po właściwym wzorcu.

Skoro już wszystko się zapętliło, zajrzałam do środka, a tam:

Podstawowa różnica pomiędzy wspomnianą już Matcher::matches a Matcher::find jest taka, że matches szuka pełnych dopasowań (cały łańcuch znaków musi pasować do wzorca), a find zadowoli się dopasowaniem w środku łańcucha znaków (i może takich dopasowań zwrócić wiele).

Czyli jeśli nasz wzorzec ma postać "[abc]e", to find dopasuje go do łańcucha "cel", w przeciwieństwie do metody matches:

Jeśli dodam na początku i na końcu wzorca uniwersalne symbole ".*" (uzyskując ".*[abc]e.*") to również metoda matches uzna, że mamy dopasowanie:

Jednak jednak użyjemy metody find przy odpowiednio złożonym i zagnieżdzonym wyrażeniu regularnym z opcjonalnymi elementami i przy odpowiednio długim tekście, pojawi się tyle możliwości dopasowania wyrażenia do łańcucha znaków, że wejdziemy na obszar tzw. Catastrophic Backtracking (katastrofalne nawracanie?).

Moja poprawka sprowadziła się, oczywiście, do usunięcia czterech znaków: ".*" z początku i końca wyrażenia przekazanego jako argument metodzie Element::getElementsByAttributeValueMatching.

Jaka z tego nauczka? Rutynowo zaglądać w cudzy kod, niestety.

PS. Polecam krzyżówki regeksowe: Regex Crossword.

Spring Boot: autoryzacja użytkowników w oparciu o bazę danych

O logowaniu użytkowników pisałam wcześniej w następujących postach:

Dzisiaj dodałam do mojej raczkującej aplikacji funkcjonalność logowania użytkowników zapisanych wcześniej w bazie danych.

Poniżej przedstawiam zmiany, które musiałam w tym celu wprowadzić do mojej aplikacji.

a)  Wersja podstawowa

W klasie User, która od teraz ma być nie tylko klasą przechowującą dane, ale także bazą do autoryzacji użytkowników, muszę zaimplementować interfejs UserDetails:

W klasie SecurityConfiguration opisuję nowy sposób logowania:

Brakuje mi odpowiedniej metody do pobrania obiektu użytkownika po jego nazwie (getUserByUsername) w klasie UserRepository. Do tej pory szukałam użytkowników jedynie na podstawie confirmationId (co opisałam tutaj: Aktywacja konta poprzez email). Na szczęście dzięki Spring Data nie muszę jej nawet implementować, wystarczy, że dodam następującą linię:

b) Wersja rozszerzona. Przecież ja szyfruję hasła!

W tym celu muszę zarejestrować odpowiedni bean szyfrujący:

Jego właśnie muszę użyć do zaszyfrowania hasła przy tworzeniu nowego użytkownika:

Należy też wspomnieć o nim w konfiguracji:

Klasa BCryptPasswordEncoder implementuję metodę matches z interfejsu PasswordEncoder, która sprawdza, czy hasło w czystej postaci pasuje do jego zahaszowanej wersji przechowywanej w bazie danych.

Już.

PS. Podczas testowania mój dostawca domeny i serwera zablokował mi konto email, przekonany, że ktoś się na nie włamał i rozsyła spam

Przeglądarka w Javie FX

Stanęłam ostatnio wobec następującego problemu: potrzebowałam aplikacji do ręcznej klasyfikacji stron internetowych. Chodziło o to, żeby wyświetlić użytkownikowi kolejną stronę z listy i udostępnić przycisk, który pozwoli odpowiednio ją oznaczyć.

Oczywiście Java nie jest najlepszym rozwiązaniem, jakie można tu zaproponować, ale chciałam zrobić to szybko w języku zrozumiałym dla większości zainteresowanych osób. Na Stack Overflow znalazłam kilka wątków pokazujących, jak uruchomić domyślną przeglądarkę internetową w danym systemie, ale po pierwsze przechwycenie danych z niej to wyższa szkoła jazdy, a po drugie chciałam otwierać kolejne strony w tej samej zakładce.

Z pomocą przyszła JavaFX, a dokładniej komponent WebView oparty na otwartym silniku WebKit. W tej wersji uruchomienie przeglądarki i obserwowanie zachowania użytkownika staje się dziecinnie proste. Poniżej całość kodu, który:

  • wyświetla stronę startową
  • wypisuje w konsoli kolejne strony odwiedzane przez użytkownika

Najważniejsze linie:

  • 13: aplikacja JavaFX
  • 22: tytuł okienka
  • 24: pionowy układ elementów
  • 27: etykieta wyświetlająca aktualny url
  • 30-31: przeglądarka i strona startowa
  • 34-41: obsługa zdarzenia: załadowanie nowej strony (z lambdą!)

Fajne, prawda?

Okno aplikacji z załadowaną stroną startową
Okno aplikacji z załadowaną stroną startową

 

Aktywacja konta poprzez email

Poprzedni wpis poświęciłam kwestii wysyłania maili przez aplikację napisaną w Javie.

Kontynuując, teraz chcę upewnić się, że świeżo zarejestrowany użytkownik to człowiek (a nie bot) i że podał poprawny adres email. Poniżej opisuję kroki prowadzącego do tego celu.

Krok 1: nieaktywny użytkownik z wygenerowanym kodem

Po wypełnieniu formularza rejestracyjnego obiekt reprezentujący użytkownika jest zapisywany w bazie danych jako nieaktywny. Razem z nim zapisywany jest losowo wygenerowany kod do aktywacji konta. Na tym etapie użytkownik nie może się logować, nie zna też przypisanego mu kodu.

Krok 2: email z linkiem aktywacyjnym

Aplikacja wysyła na adres podany przez użytkownika wiadomość zawierającą link aktywacyjny. Kod wygenerowany losowo w poprzednim kroku jest doklejony do adresu jako parametr URL.

Krok 3: obsługa linku aktywacyjnego

Wejście pod adres podany w mailu powoduje uruchomienie servletu weryfikacyjnego. Aplikacja szuka w bazie danych obiektu użytkownika, któremu przypisano kod podany jako parametr. Jeśli taki użytkownik istnieje, jest oznaczany jako aktywny. Od tej chwili może się już logować, ponieważ potwierdzono (czy raczej zwiększono prawdopodobieństwo), że to rzeczywista osoba.

Krok 4: usunięcie nieaktywnych kont

Należałoby usunąć zbyt długo przechowywane nieaktywne konta. Ale jeszcze się za to nie zabrałam 🙂

Ciekawostka: wyszukanie użytkownika w bazie

Oto ilość pracy, którą włożyłam w wyszukanie użytkownika w bazie danych MongoDB po wartości confirmationId:

Resztę robi za mnie Spring Data, parsując nazwę metody!

Więcej informacji na ten temat można znaleźć tutaj.

PS.

To ostatni techniczny wpis w ramach konkursu Daj się poznać 2016. Jutro postaram się napisać krótkie podsumowanie. O ile wieczorem na spotkaniu młodych mam nie poleje się za dużo wina.