Baza danych w chmurze Pivotal (photo story)

Pokazywałam już, jak wdrożyć aplikację webową w chmurze PaaS Pivotal Web Services:

  1. Wdrażam moją aplikację (która nadal nic nie robi) w chmurze Pivotal Web Services

Pisałam też co nieco o nierelacyjnej bazie danych MongoDB:

  1. Jak zacząć z MongoDB?
  2. MongoDB + Spring Data
  3. Zapisuję dane użytkowników w bazie i robię głupie błędy podczas walidacji formularza

Jak zapewnić sobie dostęp do serwera bazodanowego działającego w chmurze?

Do tej pory uruchamiałam aplikację tylko lokalnie. Przed odpaleniem pliku .jar z wbudowanym serwerem Tomcat musiałam najpierw uruchomić lokalny serwer bazy danych.

W serwisie Pivotal istnieje tzw. Marketplace, w którym można kupować dodatkowe usługi. Wygląda to tak:

Lista dodatkowych serwisów Pivotal
Lista dodatkowych serwisów Pivotal

Odnalazłam na liście interesujący mnie element:

MongoDB w chmurze Pivotal
MongoDB w chmurze Pivotal

Moim celem jest teraz włączenie serwisu i powiązanie go z moją aplikacją Szafbook.

Mogę zrobić to z wiersza poleceń przy użyciu narzędzia cf (muszę wówczas użyć poleceń cf create-service, cf bind-service i ewentualnie cf-restage), mogę też wyklikać swoje wymagania w przeglądarce, na stronie Pivotal:

Banalnie prosta konfiguracja usługi
Banalnie prosta konfiguracja usługi

W przypadku wielu dodatkowych serwisów muszę wybrać pomiędzy kilkoma „planami” – najczęściej jeden z nich jest darmowy i dość ograniczony (np. 5 jednoczesnych połączeń, 20MB pojemności), a kolejne są coraz mocniejsze i coraz droższe. MLab na razie ma tylko darmową wersję.

Po kilkunastu sekundach mam już działające połączenie pomiędzy bazą a aplikacją:

Powiązanie serwisu MLab (MongdoDB as a service) z aplikacją w chmurze Pivotal Web Services
Powiązanie serwisu MLab (MongdoDB as a service) z aplikacją w chmurze Pivotal Web Services

Wszystko działa!

Działająca aplikacja :)
Działająca aplikacja :)

Chmura jest w stanie samodzielnie podmienić źródło danych aplikacji w taki sposób, by odwoływało się do nowoutworzonego serwisu. Programista nie musi nawet znać adresu tej usługi! Choć, oczywiście, może go sobie podejrzeć:

Więcej informacji na temat instancji MongoDB podpiętej do mojej aplikacji (na stronie dostawcy usługi)
Więcej informacji na temat instancji MongoDB podpiętej do mojej aplikacji (na stronie dostawcy usługi)

W rzeczywistości, jak zwykle, nie obyło się bez błędów:

  1. Opierając się o tutorial, wyklikałam dostęp do serwisu ElephantSQL, czyli bazy relacyjnej bazy PostgreSQL zamiast do MLab czyli MongoDB.
  2. Rozdzieliłam właściwości projektu pomiędzy kilka plików dla różnych profili (np. application-development.properties), po czym zapomniałam zmienić profil (z development na cloud) przy budowaniu na potrzeby wdrożenia.

 

 

Zapisuję dane użytkowników w bazie i robię głupie błędy podczas walidacji formularza

Zapis danych użytkowników w MongoDB

O MongoDB pisałam już w dwóch wcześniejszych postach: Jak zacząć z MongoDB? i MongoDB + Spring Data.

Dzisiaj postanowiłam zaimplementować wreszcie zapis danych z formularza użytkownika w mojej nierelacyjnej (dokumentowej) bazie danych.

W poprzednim tekście pokazałam, jakich adnotacji należy użyć w klasie User, żeby jej instancje zostały poprawnie zapisane w bazie danych. Żeby faktycznie zapisać dane z formularza, musiałam tylko dopisać kilka linii w kodzie kontrolera:

Co zrobić z hasłami?

Zależało mi na spełnieniu trzech warunków:

  1. Użytkownik podaje hasło dwa razy, żeby zmniejszyć ryzyko literówki.
  2. Wpisywane hasło jest niewidoczne.
  3. Hasło w bazie danych nie jest przechowywane w postaci jawnej.

Dwa hasła

Dodałam następujące pola do klasy reprezentującej użytkownika:

Specjalnie zaznaczyłam adnotację @Transient. Dzięki jej użyciu wskazane pola (w tym wypadku hasła zapisane jawnym tekstem) nie zostaną zapisane w bazie danych.

Ukrycie literek

Pola musiałam również dopisać do formularza. Użyłam pola input w wersji password, żeby zamiast liter wyświetlić gwiazdki (czy tam kropki).

Funkcja hashująca

Wreszcie, hasła. Nie powinny być przechowywane w bazie danych w postaci jawnej. Powodów jest wiele. Na przykład taki: ludzie często używają tych samych haseł w wielu miejscach. Gdyby administrator bazy danych miał wgląd w hasła do aplikacji, mógłby podjąć próbę zalogowania się na konta użytkowników w innych serwisach (np. gmail) przy użyciu tego samego hasła i adresu email.

Oprócz pokazanych już dwóch pól do wprowadzenia hasła roboczego, klasa User przechowuje jeszcze następujące dwie wartości:

passwordSalt to losowa wartość doklejana do hasła przed jego „zaszyfrowaniem” (dzięki niej w bazie danych nie będzie widać, że dwa użytkownicy przypadkowo użyli tego samego hasła), passwordEncrypted to wynik szyfrowania.

Losowanie i szyfrowanie realizuje następujący pomocniczy serwis, wywoływany z kontrolera dzięki adnotacji @Autowired:

Kontroler wygląda tak:

Błąd 1: strona błędu zamiast komunikatu o błędzie w formularzu

Podanie niepoprawnych danych w formularzu z nieznanego mi powodu zaczęło przenosić mnie na moją własną stronę błędu (zamiast wyświetlenia komunikatu przy polu formularza, które spowodowało problem).

Co się okazało?

W pewnym momencie zmieniłam sygnaturę metody kontrolera z:

na:

ponieważ chciałam dopisać informacje do modelu.

Okazuje się, że parametr reprezentujący BindingResult musi następować bezpośrednio po parametrze, przez który przekazywany jest dotyczący go obiekt (co ma sens, gdy jeden formularz obsługuje wiele obiektów).

Formularz zaczął działać poprawnie po zamianie kolejności parametrów:

Błąd 2: Error during execution of processor ‚org.thymeleaf.spring4.processor.attr.SpringErrorsAttrProcessor’

Kolejny błąd zaskoczył mnie, kiedy testowałam sytuację, w której użytkownik wpisze dwa różne hasła. Okazało się, że poczyniłam złe założenia na temat parametrów metody rejectValue, za pomocą której chciałam przekazać do formularza informację o wykryciu problemu. Napisałam:

zakładając, że drugi parametr to komunikat o błędzie. Tymczasem – to kod błędu. Komunikat można przekazać dopiero w trzecim parametrze (poprawny kod widać na listingu z metodą processPasswords). Błąd wynikał zatem z braku komunikatu o błędzie, który był wymagany w szablonie.

Wreszcie działa

Kod jest dostępny w moim repozytorium GitHub.

Komunikat o niepasujących do siebie hasłach
Komunikat o niepasujących do siebie hasłach
Wyświetlenie informacji o pierwszym lepszym użytkowniku z bazy
Wyświetlenie informacji o pierwszym lepszym użytkowniku z bazy

 

Jak zabezpieczyć strony generowane przez Spring Boot Actuator?

W mojej aplikacji webowej korzystam z biblioteki Actuator, która daje dostęp do masy pożytecznych informacji na temat działania aplikacji (w czasie rzeczywistym).

Wystarczy dodać w pom.xml następujący wpis:

Po uruchomieniu aplikacji uzyskuję dostęp do wielu stron ze szczegółami działania aplikacji. Przykładowo, pod adresem /health znajdę podstawowe informacje o aktualnym statusie aplikacji:

Raport na temat stanu zdrowia aplikacji
Raport na temat stanu zdrowia :)

Wszystko pięknie, tyle tylko, że nie chcę dzielić się takimi danymi z przypadkowymi (lub, co gorsza, nieprzypadkowymi) użytkownikami Internetu.

Pokazywałam już (we wpisie Spring Boot: Bezpieczeństwo 101) jak oznaczyć strony, które mają być wyświetlane tylko użytkownikom o statusie administratora. Problem z Actuatorem polega na tym, że generowane przez tę bibliotekę adresy nie mają wspólnego rdzenia. Mamy np.: /env, /metrics, /trace. Ich wymienianie jest nieco upierdliwe!

Wtem! Wyczytałam (w Spring Boot in Action), że można dodać tym stronom wspólny przedrostek za pomocą wpisu w pliku application.properties:

A następnie zabezpieczyć dostęp do stron na tej ścieżce:

I voilà! Po zalogowaniu się jako administrator widzę:

Raport o stanie zdrowia wyświetlam teraz pod innym, wspólnym adresem
Raport o stanie zdrowia wyświetlam teraz pod innym, wspólnym adresem

 

MongoDB + Spring Data

W poprzednim wpisie pokazałam, jak dodawać dokumenty i kolekcje do nierelacyjnej bazy MongoDB oraz jak połączyć się z tą bazą z kodu javowego.

W tym odcinku pokażę, jak łatwo utrwalić w MongoDB obiekty przetwarzane w aplikacji webowej.

Wpis w pom.xml

Kolejny raz korzystam ze „startera” Spring Boot, który grupuje w sobie kilka podstawowych bibliotek realizujących spójny cel – w tym wypadku mapowanie, zapis i odczyt danych z MongoDB:

Adnotacje w obiekcie, który ma zostać utrwalony w bazie danych

Do obiektu reprezentującego użytkownika bazy danych dodałam następujące adnotacje:

  • @Document oznacza, że mamy do czynienia z obiektem zapisywanym w bazie danych. Jest to odpowiednik @Entity w wersji Spring Data dla relacyjnych baz danych.
  • @Id to automatycznie generowany, obowiązkowy identyfikator dokumentu w ramach kolekcji w MongoDB.
  • Pola nieopisane zostaną bezpośrednio odwzorowane w dokumencie w bazie danych.
  • @DBRef oznacza odwołanie do innej kolekcji w bazie. Uwaga! Nie wolno tworzyć odwołań obustronnych, MongoDB brzydko się przez nie zapętli. Zamiast tego należy po jednej stronie jawnie zapisać identyfikator dokumentu.

Interfejs do obsługi repozytorium

Muszę tylko zasygnalizować, że będę chciała pobierać z bazy obiekty danego typu:

Użycie w kodzie: kontroler i widok

Kontroler

W celu przetestowania konfiguracji dodałam odwołanie do kolekcji użytkowników do mojego powitalnego kontrolera GreetingController:

Nazwa pierwszego napotkanego użytkownika zostanie dodana do modelu.

Widok

W powitalnym szablonie Thymeleaf dopisałam kod, który wyświetli nazwę odnalezionego w bazie danych użytkownika, o ile taki użytkownik istnieje:

Efekt

Wyświetlona informacja pobrana z bazy danych
Wyświetlenie informacji pobranej z bazy danych. Przecinek od czapy.

Zapis informacji w bazie

Mogę skorzystać ze sposobu pokazanego w poprzednim wpisie. Mogę też przygotować kod, który będzie wywoływany przy każdym uruchomieniu aplikacji:

Konfiguracja połączenia z bazą danych

Tym razem oparłam się na wartościach domyślnych. Nie wpisałam w application.properties żadnych danych na temat połączenia z bazą danych. Oczywiście musiałam uruchomić mój serwer MongoDB.

Wszystko zadziałało.

Mogę podejrzeć zastosowane wartości właściwości związanych z MongoDB dzięki dołączonej w pom.xml bibliotece Spring Boot Actuator. Pod adresem http://localhost:8080/configprops widzę m.in. takie dane:

Test to baza danych, którą utworzyłam na potrzeby poprzedniego wpisu.

Troubleshooting: co zrobiłam nie tak przy pierwszym podejściu?

  • Zapomniałam o wpisaniu @Autowired w kontrolerze w punkcie 4 (komunikat CrudRepository ... is no accessor method!)
  • Nie włączyłam MongoDB (Timed out after 10000 ms while waiting for a server that matches AnyServerSelector{} ... caused by {java.net.ConnectException: Connection refused: connect}})

Jak zacząć z MongoDB?

Wprowadzenie

Najwyższa pora dodać do mojej konkursowej aplikacji jakąś bazę danych. Od początku zakładałam, że z powodów edukacyjnych użyję bazy nierelacyjnej. Zdecydowałam się w końcu na MongoDB. Jest to jedna z popularnych baz nierelacyjnych obsługiwanych przez mojego dostawcę PaaS (Platform as a Service), tj. Pivotal Web Services.

Źródła

Swoją działalność w tym obszarze opieram na następujących źródłach:

Pierwsze kroki

Po instalacji serwera bazodanowego wykonuję następujące kroki:

  1. Uruchamiam proces serwera MongoDB:
  2. Przygotowuję rekord reprezentujący użytkownika mojego systemu (plik user.json). Rekordy w MongoDB mają postać dokumentów w standardzie JSON (w przybliżeniu). Wartościami pól mogą być również inne dokumenty oraz tablice (w tym tablice dokumentów). Dokumenty są przechowywane w ramach kolekcji. Kolekcja przypomina tablicę w relacyjnej bazie danych, tyle że zawarte w niej dokumenty wcale nie muszą mieć tej samej struktury. Dokumenty w kolekcji muszą mieć klucz główny o nazwie _id:
  3. Importuję rekord użytkownika do bazy danych:
  4. Dodaję sterownik MongoDB jako zależność w mavenowym pliku pom.xml.
  5. Łączę się z bazą danych z kodu w Javie:
  6. Wyszukuję użytkowników:
  7. Zmieniam wartość jednego z pól użytkownika (dokument d pełni tu rolę wzorca, według którego odnajdywany jest rekord z bazy):
  8. Nakładam indeks na nazwy użytkowników:

No i działa 🙂

Cały plik jest dostępny w GitHub.

Co dalej?

  1. Na serio dodać to do aplikacji 🙂
  2. Zastanowić się nad użyciem Hibernate.
  3. Zastanowić się, jak przechowywać zdjęcia.

Własny formularz logowania Spring Security

W poprzednim wpisie pokazałam, jak zabezpieczyć stronę lub widok hasłem. Korzystałam tam z domyślnego formularza logowania, który wyglądał tak:

Standardowy formularz logowania
Standardowy formularz logowania

Zawsze fajnie dostać coś za darmo, ale nie pasuje to wyglądem do reszty strony.

Co zrobiłam, żeby wymienić formularz na ładniejszy?

  1. Dopisałam odpowiednie fragmenty w metodzie configure wprowadzonej w poprzednim wpisie klasy SecurityConfiguration:
  2. Zdefiniowałam formularz w pliku login.html:
  3. Dodałam najprostszy możliwy kontroler:

Efekt wygląda tak:

Ulepszony formularz logowania
Ulepszony formularz logowania

Spring Boot: Bezpieczeństwo 101

Pora zabezpieczyć stronę – niektóre jej części chcę pokazywać tylko zalogowanym użytkownikom.

Ukrycie całej strony za hasłem

Ukrycie całej strony za hasłem jest wyjątkowo proste. Wystarczy dodać do pom.xml następującą zależność:

Strona wygląda wtedy tak:

Cała strona ukryta za hasłem
Cała strona ukryta za hasłem

Skąd wiem, jakiego podać użytkownika i hasło?

  • Jeśli nic dodatkowo nie konfigurowałam, mogę zalogować się przy użyciu nazwy użytkownika User oraz hasła zapisanego w logach serwera:
  • Mogę też podać dane logowania w pliku application.properties:

Zabezpieczenie na poziomie stron i metod

Dodaję do swojego kodu następującą klasę konfiguracyjną:

W metodzie configureAuth uzyskuję dostęp do obiektu AuthenticationManagerBuilder i definiuję parę użytkowników i nadajemy im role (użytkownika lub administratora).

W metodzie configure podaję, kto ma mieć dostęp do której części aplikacji. I tak:

  • Do adresów wymienionych w linii 17 dostęp mają wszyscy, a więc nie tylko zalogowani użytkownicy.
  • (18) Do stron pod adresem /admin i poniżej dostęp ma tylko użytkownik o prawach administratora.
  • (19) Do stron pod adresem /user i poniżej dostęp ma tylko użytkownik w roli USER.
  • (20) Do reszty stron dostęp mają tylko zalogowani użytkownicy, niezależnie od roli.
  • Włączam dodatkowo standardowy formularz logowania (21) i ustawiam adres / jako domyślne miejsce lądowania po udanym zalogowaniu bądź wylogowaniu.

Dodam jeszcze następujący fragment kodu do mojego szablonu strony:

Uwaga! Żeby silnik szablonów Thymeleaf odpowiednio przetworzył ten fragment, w pom.xml muszę dodać zależność do artefaktu thymeleaf-extras-springsecurity4.

Jak to wygląda na stronie?

Strona główna, niewymagająca logowania
Strona główna, niewymagająca logowania
Standardowy formularz logowania
Standardowy formularz logowania
Użytkownik zalogowany
Użytkownik zalogowany

Dodatkowo mogę definiować wymagania bezpieczeństwa w kodzie, przy każdej metodzie kontrolera, np.:

Kod jest dostępny w GitHubie.

Co dalej?

Pozbywam się powtarzalnych fragmentów HTML przy użyciu Thymeleaf

Każdy programista wie, że duplikacja w kodzie źródłowym to zło, gdyż:

  • jeśli zduplikowany kod zawiera błąd, trzeba naprawić go w kilku miejscach (i z reguły o którymś się zapomina),
  • długi kod trudniej się czyta.

A jednak zadanie przerzucenia powtarzanych fragmentów HTML (jak nagłówek i stopka wyświetlane na wszystkich podstronach) do osobnych, reużywalnych plików wcale nie jest trywialne!

Mój plik index.html w oryginalnej postaci zawierał 71 linii, z czego około 50 było wspólnych z innymi szablonami (nagłówek, stopka, menu, załączane skrypty js). Zależało mi na wyodrębnieniu części wspólnych do własnych plików. Chociażby po to, żeby dodanie pozycji z menu nie musiało być odwzorowywane w pięciu miejscach.

Jakie miałam możliwości?

  1. Oprogramować operację include w JavaScripcie (lub użyć czyjegoś kodu, np. z W3Schools). Wady:
    • dużo JavaScriptu,
    • metoda z gatunku nieeleganckich hacków.
  2. Użyć znaczników HTML: object, embed lub nawet iframe. Wady:
    • dwa pierwsze znaczniki zostały zaprojektowane do osadzania na stronach obiektach takich jak filmy, choć da się ich użyć tak że do wstawienia dokumentu HTML,
    • wszystkie służą do dodania do strony kompletnego dokumentu, a nie fragmentu,
    • styl CSS obowiązujący na stronie nie zadziała na załączone w ten sposób fragmenty.
  3. Skorzystać z mechanizmu udostępnianego przez silnik szablonów, w tym wypadku Thymeleaf. Wady:
    • serwer wykonuje pracę, którą mógłby wykonać klient 🙂
    • ewentualna zmiana silnika szablonów staje się jeszcze bardziej kosztowna.

Zdecydowałam się na rozwiązanie numer 3. Jak to wygląda w praktyce?

Na wszystkich moich stronach powtarzał się poniższy fragment:

Przeniosłam go (wraz z innymi podobnymi elementami) do osobnego pliku _menus.html:

Dzięki temu mogę załączać go wszędzie tam, gdzie jest potrzebny, w następujący sposób:

Pułapka 1: Na początku umieściłam atrybuty id i class we fragmencie załączanym (w _menus.html). Zostały zjedzone 🙂

A co, jeśli fragment, który chcę załączyć, nie jest otoczony sensowną parą znaczników? Mogę wtedy użyć bloku, np.:

I załączyć go w analogiczny sposób:

W obecnej chwili index.html ma tylko 32 niepuste linie i dużo zyskał na czytelności, podobnie jak inne szablony.

Pułapka 2: Po wyodrębnieniu stopki do osobnego pliku, moim oczom ukazał się taki oto widok:

Problem z kodowaniem załączonego pliku
Problem z kodowaniem załączonego pliku

Wszystkie pliki mam zakodowane w UTF-8, takie samo kodowanie deklaruję w nagłówku HTML. Poczytałam trochę o problemach z kodowaniem na linii Spring/Thymeleaf, ale ostatecznie, ponieważ na teraz jest to jedyne wystąpienie polskiego znaku na mojej stronie, po prostu zmieniłam odpowiadającą za to linię na:

 

 

 

 

Czasami coś idzie nie tak… Moja własna strona błędu

Nadal w ramach Daj się poznać.

Podobny obrazek widział chyba każdy programista aplikacji webowej. Od czasu do czasu serwer Tomcat postanawia poinformować użytkownika aplikacji, że coś poszło nie tak. Informuje dość brutalnie, przynajmniej od strony stylistycznej. Co gorsza, przy okazji potrafi wyjawić przypadkowemu użytkownikowi dość dużo informacji na temat wnętrza programu.

Informacja o błędzie wygenerowana przez serwer Tomcat. W tym wypadku żądana strona nie istnieje.
Informacja o błędzie wygenerowana przez serwer Tomcat. W tym wypadku żądana strona nie istnieje. Czasami można w tym miejscu zobaczyć ciekawszy materiał, czyli stack trace.

Tego typu informacje przydają się do debugowania aplikacji na etapie jej powstawania, ale użytkownik końcowy nie powinien ich oglądać (chociażby z powodów estetycznych).

Jak sobie z tym poradzić? Framework Spring Boot automatycznie ustawia dla nas nieco tylko ładniejszą stronę błędu:

Whitelabel Error Page, czyli strona błędu generowana przez Spring Boot
Whitelabel Error Page, czyli strona błędu generowana przez Spring Boot

Mechanizm ten można wyłączyć we właściwościach aplikacji (application.properties):

Także zmiana domyślnego ViewResolver może usunąć tę wersję informacji o błędzie i przywrócić wersję tomcatową.

Jeśli zamiast strony prezentowanej przez Springa chcesz ustawić swoją własną, musisz zerknąć do dokumentacji wybranego przez Ciebie silnika szablonów. W przypadku Thymeleaf wystarczy dodać szablon o nazwie error.html:

Szablon błędu dla silnika Thymeleaf
Szablon błędu dla silnika Thymeleaf

Dzięki temu strona błędu może wyglądać na przykład tak:

error

Czy jest ładniejsza… Pozostawiam ocenie Czytelnika 😀

Historie komórkowe

Ten tekst miał nazywać się „Mobilna wersja strony: podejście 2” w nawiązaniu do Mobilna wersja strony w Spring Boot. Potrzebowałam do niego zrzutu ekranu z mojego telefonu, a jedno spojrzenie na niego wyzwoliło całą lawinę wspomnień… Które również zamieszczam poniżej.

@media

Najpierw krótko o konkretach: w poprzednim wpisie pokazywałam, jak Spring Boot pozwala stworzyć mobilną wersję strony i zarządza jej wyświetlaniem. Wychodzi jednak na to, że w dzisiejszych czasach istnieją lepsze metody. Prym wśród nich wiodą CSS3 i reguły @media. Logika odpowiedzialna za formatowanie informacji trafia w tym modelu dokładnie tam, gdzie powinna: do arkusza stylów. W arkuszu stylów, przy użyciu reguł @media, możemy podjąć decyzję na temat sposobu wyświetlania informacji w zależności od tego, jakie urządzenie korzysta ze strony (np. ekran czy drukarka?), jaką ma orientację (pozioma czy pionowa?) bądź rozdzielczość.

Prosty przykład ze strony W3Schools:

Kolor tła zostanie zmieniony na magentę (ekhem, fuksję), jeśli szerokość wyświetlacza wyniesie co najmniej 480 pikseli.

W swojej konkursowej aplikacji postanowiłam pójść po najmniejszej linii oporu – znalazłam darmowy szablon CSS implementujący ten mechanizm 🙂 Wygląda to obecnie tak:

Przeglądarka na PC
Przeglądarka na PC
Strona wyświetlona na ekranie Samsung Galaxy Xcover 3
Strona wyświetlona na ekranie  urządzenia mobilnego o niskiej rozdzielczości

Telefony 🙂

Co do kiepskiej jakości urządzeń mobilnych… Jestem specyficznym typem użytkownika: masowo rozbijam telefony. Nie rzucam nimi ze złości (od dobrych paru lat). Same wypadają: z kieszeni, z torebki, z samochodu. Kąpią się w wannie i w napojach. Psują się.

Przedstawiony powyżej zrzut ekranu pochodzi z mojego Samsung Galaxy Xcover 3. A było tak.

W połowie ubiegłego roku doszłam do wniosku, że nie stać mnie na kupowanie co dwa miesiące nowego dobrej klasy smartfona (w obliczu śmiertelnego wypadku poprzednika). Zdecydowałam się wtedy na zakup urządzenia niskiej klasy, za to w metalowej obudowie. Przesadziłam – nie działało na nim nawet quizzwanie. Na szczęście, problem szybko rozwiązał się sam. Pierwszego dnia telefon wypadł mi z ręki, kiedy przechodziłam przez przedpokój na piętrze. Pięknym lobem poszybował w stronę krętych schodów, po czym szybem w rogu spadł aż do samej piwnicy. Kiedy bez większych nadziei zeszłam na dół, okazało się, że urządzenie nadal działa, chociaż róg ma zauważalnie wgnieciony. Nabrałam do niego nowego szacunku. Dwa dni później wypadł mi z tylnej kieszenie spodni, kiedy szukałam kluczy na podjeździe – i zbił się na amen.

Wtedy wpadłam na radykalnie odmienny pomysł: kupić drogie i dobre urządzenie, o które będę drżeć i którego wobec finansowych rozterek z pewnością nie upuszczę na podłogę. Wybrałam najnowszy model Galaxy Note. Telefon był piękny, wygodny, szybki… Tyle że trafiłam na wadliwy egzemplarz, który restartował się w losowo wybranych momentach kilka razy dziennie. Przegapiłam (tygodniowy) termin na oddanie telefonu bez wyjaśnień w lokalnym Brand Store, ponieważ od razu pojechałam z nim na wakacje. Po powrocie najpierw wmawiano mi, że wyłączyłam telefon podczas aktualizacji i dlatego działa źle. Potem kilka razy zwracano mi go jako naprawiony – pierwszą rzeczą, jaką robił po włączeniu (najpierw w domu, potem już w sklepie), był restart. Pikanterii sprawie dodawał fakt, że byłam wtedy w bardzo zaawansowanej ciąży i brak sprawnego telefonu był coraz bardziej ryzykowny. Po około miesiącu użyłam na piśmie magicznego sformułowania „Miejski Rzecznik Konsumentów” i odzyskałam pieniądze. Nie chciałam już innego egzemplarza (o który dopominałam się od początku, ustaliwszy szybko, że problem jest sprzętowy i dotyczy konkretnej sztuki w ogólności dobrego modelu), bo nie miałam ochoty na jeszcze jedno spotkanie z serwisem.

Lato 2015, Mazury. Dawid i Gałgan ćwiczą pracę wodną. Ja łapię zasięg i reinstaluję Androida
Lato 2015, Mazury. Dawid i Gałgan ćwiczą pracę wodną. Ja łapię zasięg i reinstaluję Androida

Potem chciałam tanio i dobrze kupić One Plus. Powstrzymało mnie to, że właśnie pojawił się nowy model. Kosztował dokładnie tyle, co stary, ale do zakupu wymagane było posiadanie zaproszenia. Kto normalny kupiłby starą wersję, jeśli nowa kosztowała tyle samo?! A zaproszenie ciągle nie nadchodziło…

Wtedy wygasła umowa na usługi komórkowe w organizacji, do której należę i pojawiła się możliwość uzyskania bez dopłaty cuda w postaci Samsung Galaxy Xcover 3. Na kolana powala przede wszystkim rozdzielczość (480 x 800px), ale pancerny telefon nadal działa po dziesiątkach upadków, kąpieli i ugryzień. I takiego doświadczenia życzę wszystkim!

Milsza strona programowania