Okazało się, że standard HTML5 opisuje specjalne typy pól wejściowych dla adresu email oraz daty. W kodzie strony wygląda to tak:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<form action="#"method="post">
<table>
<tr>
<td>Email:*</td>
<td><input type="email"/></td>
</tr>
<tr>
<td>Birthday:</td>
<td><input type="date"/></td>
</tr>
<tr>
<td><button type="submit">Submit</button></td>
</tr>
</table>
</form>
Email
Najpierw email. W Firefoksie mamy:
Walidacja adresu email w przeglądarce Firefox
W Chrome podobnie, ale dostajemy trochę więcej informacji:
Walidacja adresu email w przeglądarce Google Chrome
Data
Przy datach jest jeszcze ciekawiej.
Oto Chrome:
Pole do wprowadzania daty w Chrome, widok po załadowaniuPole do wprowadzania daty w Chrome, widok po najechaniu myszką i rozwinięciu menu
Co na to Firefox?
Firefox się nie wykazuje
Firefox nic, Explorer oczywiście także.
Boję się przeglądarki Chrome. Google czyta moje maile i wie, czego szukam w Internecie. To, co wpisuję w pasku adresowym jest dla mnie ostatnią granicą… Ale w tej chwili chciałabym, żeby wszyscy użytkownicy korzystali właśnie z niej 🙂
Lubię często wysyłać stan pracy do repozytorium – czuję się wtedy bezpiecznie (chociaż akurat Eclipse jest dość pomocny jeśli chodzi o odzyskiwanie wersji z lokalnej historii). Podczas pracy nad poprzednim wpisem wysłałam do swojego lokalnego repozytorium Git masę głupich “testowych” commitów. Byłam przekonana, że nie zostawią śladu w ostatecznej wersji w GitHub. Tyle że… zostawiły! Przy wypychaniu zmian do repozytorium zdalnego przekazywana jest tam cała historia. O wstydzie, o chaosie!
Podczas dzisiejszych eksperymentów z silnikiem szablonów Thymeleaf, nauczona doświadczeniem oraz komentarzami do wcześniejszego wpisu, postanowiłam skorzystać z opcji git rebase -i, która pozwala interaktywnie uporządkować i scalić commity. W ten sposób do zdalnego repozytorium w serwisie GitHub trafi ostateczny i kontrolowany wynik mojej pracy, a nie poszczególne jej fragmenty.
A było tak:
1. Potrzebowałam trzech commitów, żeby przy użyciu Thymeleaf zwrócić użytkownikowi powitalną stronę:
O trzy kroki do przodu względem zdalnej gałęzi master
3. Nie potrafię użyć interaktywnego rebase w Eclipse, dlatego na chwilę przenoszę się do konsoli:
1
$git rebase-i
4. Konsola gita usłużenie wyświetla mi plik w edytorze vim, który to edytor zawsze jest mile widziany pod Windowsem (not):
Co mogę zrobić z moimi trzema commitami?
Edycja pliku pociągnie za zmianę historii repozytorium. Na samej górze widać moje trzy commity i towarzyszące im opisy. Poniżej mam bardzo czytelną instrukcję. Słowo pick na początku każdej z trzech linii odpowiadających commitom mogę zamienić na jedną z dostępnych komend.
5. Oto mój wybór:
Zdecyduj się, człowieku!
Zdecydowałam, że chcę wcielić dwa ostatnie commity do pierwszego i odrzucić ich opisy (fixup), a także zmienić opis pierwszego commita (reword).
6. Po zamknięciu i zapisaniu pliku pojawia się kolejny, w którym mogę edytować opis jedynego pozostałego przy życiu commita:
Nowy komentarz do commita
7. Wracam do konsoli, gdzie czeka na mnie podnoszący na duchu komunikat:
1
2
3
4
5
6
7
8
9
10
11
$git rebase-i
[detached HEAD a89b890]thymeleaf template added with staticresources andacontroller
8. Wracam do Eclipse. Po odświeżeniu projektu widzę, że rzeczywiście commity w lokalnym repozytorium zostały scalone do jednego:
Tylko jeden krok do przodu względem zdalnej gałęzi master
9. Wypycham kod do GitHuba. Tym razem na stronie widać jeden kompletny commit, a nie zbieraninę drobnicy, jak poprzednio.
Jeden commit zamiast trzech
PS. Zrozumiałam już, że mimo że jestem tu sama, nie powinnam pracować w gałęzi master. Mam natomiast wątpliwości związane z wypychaniem chwilowych branchy do GitHuba. Może wypowie się któryś z moich gitowych pomocników?
PS2. To jest czwarty wpis na temat Gita. Poprzednie to:
Dopiero teraz, przy piątym wpisie w ramach konkursu Daj się poznać, osiągnęłam etap aplikacji “Witaj Świecie”. No cóż. W tym artykule opowiem krótko co przy tej okazji zrobiłam i co mnie zaskoczyło. Kod jest, oczywiście, dostępny w GitHubie.
Najważniejsze elementy w strukturze aplikacji to (tradycyjnie zresztą):
katalog src/main/java z kodem w języku Java (domyślnie wypełniany przez Spring Initializr jedną klasą o nazwie Application),
katalog src/test/java z testami jednostkowymi,
src/main/resources to miejsce na zasoby; podkatalog static ma zawierać pliki przetwarzane po stronie klienta (obrazki, javascript), a podkatalog templates szablony przetwarzane po stronie serwera,
plik pom.xml to informacje dla Mavena, którego wybrałam jako narzędzie do budowania mojego projektu; zawiera przede wszystkim listę potrzebnych mi bibliotek.
Hello World!
Aplikacja kompilowała się już w poprzedniej odsłonie, ale teraz zależało mi na jej uruchomieniu i wyświetleniu czegoś w przeglądarce. W oparciu o tutorial na stronie Springa powstał ten oto skomplikowany kontroler:
1
2
3
4
5
6
7
8
9
@RestController
publicclassHelloController{
@RequestMapping("/")
publicStringindex(){
return"Szafbook: work in progress!";
}
}
@RestController to adnotacja, która sprawi, że klasa będzie mogła obsługiwać żądania REST. Jej użycie jest równoważne zastosowaniu dwóch innych adnotacji: @Controller and @ResponseBody. W ten sposób tworzę kontroler, który zwraca dane tekstowe (a nie kod HTML).
@RequestMapping pozwala określić adres, pod jakim ma być dostępny kontroler. W naszym wypadku będzie to adres najwyższego rzędu.
Klasa uruchamiająca aplikację wygląda w najprostszej wersji tak:
Adnotacja @SpringBootApplication również grupuje kilka innych adnotacji. Być może najistotniejsza z nich to @ComponentScan. Dzięki niej pakiet, w którym umieściłam kod zostanie przeszukany pod kątem usług sieciowych – w ten sposób znaleziony zostanie HelloController.
Za radą tutoriala urozmaiciłam sobie efekt w konsoli dodając kod przeglądający ziarna (beans) dostępne w tzw. kontekście aplikacji.
System.out.println("Inspect the beans provided by Spring Boot:");
String[]beanNames=ctx.getBeanDefinitionNames();
Arrays.sort(beanNames);
for(StringbeanName:beanNames){
System.out.println(beanName);
}
}
}
Jak to wygląda w przeglądarce? Zerknij na nagłówek tego wpisu.
Poniżej przedstawiam dane wypisane w konsoli. Zwróć uwagę, że aplikacja webowa jest uruchamiania w wierszu poleceń z pliku JAR, a nie z pliku WAR wgranego na serwer. Jak to możliwe? Otóż przy aktualnej konfiguracji, wynikowy plik JAR zawiera wbudowaną wersję serwera Tomcat. Wielkość szafbook-0.0.1-SNAPSHOT.jar to 33 MB…
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
java-jar szafbook-0.0.1-SNAPSHOT.jar
(...)
Inspect the beans provided by Spring Boot:
_halObjectMapper
_linkDiscovererRegistry
_relProvider
actuatorMetricReader
alpsController
alpsConverter
alpsJsonHttpMessageConverter
annotatedEventHandlerInvoker
annotationRelProvider
applicationContextIdFilter
auditEventRepository
auditListener
auditableBeanWrapperFactory
autoConfigurationReportEndpoint
backendIdConverterRegistry
backendIdHandlerMethodArgumentResolver
baseUri
basicErrorController
beanNameHandlerMapping
beanNameViewResolver
(...)
Głupie wtopy: co zrobiłam nie tak przy pierwszym podejściu
Problem 1: Aplikacja buduje się (przy użyciu Mavena) w Eclipse i nie buduje się na zewnątrz. Rozwiązanie: Instalacja w systemie Mavena 3 i przestawienie Eclipse na tę samą instalację (wcześniej Eclipse korzystał z instalacji wbudowanej, a w systemie miałam Mavena 2).
Problem 2: java.lang.UnsupportedClassVersionError Rozwiązanie: Zmiana wartości zmiennej JAVA_HOME w systemie na wersję Javy używaną przez projekt w Eclipse.
Problem 3: Aplikacja działa w przeglądarce, ale w konsoli mam “java.lang.IllegalStateException: Tomcat connector in failed state“. Rozwiązanie: Usunąć zduplikowane wywołanie SpringApplication.run 🙂 Sukcesem może zakończyć się tylko jedno z nich, potem port będzie już zajęty.
Co dalej?
Jeśli chodzi o rozwijanie projektu, to najbliższe prace poświęcone będą:
Ciągłej Integracji,
“M” w MVC, czyli modelowi danych.
Jeśli chodzi o blogowanie, to planuję wpisy bezpośrednio związane z rozwojem kodu, a dodatkowo:
git rebase, którego znaczenie wreszcie zrozumiałam,
Maven.
PS. Java Beans – ciekawostka lingwistyczna
W języku programowania Java istotną rolę pełnią tzw. “ziarenka”: JavaBeans oraz Enterprise JavaBeans. Dlaczego ziarenka? Otóż “Java” to w Stanach synonim słowa “kawa” (bardzo dużo kawy uprawiano na wyspie Jawie). Stąd pomysł, żeby najmniejsze samodzielne składowe aplikacji określić mianem “ziaren kawy”.
Oficjalne logo języka Java – parujący kubek z kawą
Git pozwala na przyjemną i efektywną pracę z branchami. Łatwo je tworzyć, scalać i usuwać. Wczoraj zabrałam się za tworzenie szkieletu mojej konkursowej aplikacji Szafbook i wykorzystałam to jako pretekst do poeksperymentowania z odgałęzieniami.
Ogólny zarys moich działań
Utworzenie nowego brancha w konsoli.
W ramach brancha: przygotowanie szkieletu aplikacji Spring Boot za pomocą serwisu https://start.spring.io/.
Wcielenie zmian z nowego brancha do głównej linii kodu (konsola).
Utworzenie brancha przez interfejs Eclipse.
W ramach brancha: prace mające doprowadzić kod do stanu, w którym się kompiluje.
Wcielenie zmian z nowego brancha do głównej linii kodu (Eclipse).
Ustalenie, dlaczego nie było mi potrzebne słowo rebase.
Powyższe polecenie jest skrótem dla dwóch innych, z których pierwsze tworzy brancha, a drugie mnie do niego przenosi:
1
2
$git branch bootinit
$git checkout bootinit
Następnie wprowadzam swoje zmiany. W tym wypadku to wrzucenie szkieletu aplikacji webowej do katalogu projektowego oraz usunięcie niepotrzebnych mi już plików.
Po wprowadzeniu zmian polecenie git status zwraca następującą informację):
Wynik wywołania polecenie git status w nowej gałęzi po wprowadzeniu zmian
Chcę śledzić wszystkie te zmiany i chcę je uwzględnić w kolejnym commicie, dlatego dodaję wszystko:
1
$git add-A
Alternatywnie mogłabym zaznaczyć poszczególne zmienione i dodane pliki poleceniem git add <plik>, a usunięte pliki poleceniem git rm <plik>.
Na tym etapie postanawiam wysłać swoje zmiany do repozytorium:
1
$git commit-m"initial webapp template"
Załóżmy, że moje prace w gałęzi bootinit osiągnęły taki poziom dojrzałości, że chcę scalić je z główną gałęzią kodu (master).
W tym celu muszę przejść do gałęzi, do której mam wrzucić zmiany i tam wywołać polecenie merge.
1
2
$git checkout master
$git merge bootinit
Merge. Kolory bardzo przyjemne
Jeśli gałąź nie będzie mi już potrzebna, mogę ją usunąć:
1
$git branch-dbootinit
I już.
Eclipse
Teraz przerzucam się na pracę w środowisku Eclipse. Na początku importuję istniejący projekt z repozytorium Git.
W Eclipse narzędzia związane z kontrolą wersji znajdują się w menu kontekstowym projektu, w zakładce Team.
Kontrola wersji w Eclipse
Tworzę nową gałąź korzystając z opcji wyświetlonej na powyższym obrazku: Team->Switch To->New Branch
Nazwa aktualnej gałęzi jest wyświetlana przy nazwie projektu.
Wersja projektu w gałęzi eclipsebranchtest
Dalej wprowadzam swoje zmiany. Przed wszystkim chcę doprowadzić aplikację do stanu, w którym kompiluje się bez błędów (za pomocą Mavena) i zawiera chociaż jeden (bezsensowny na razie) test jednostkowy.
Jedna ze zmian to oznaczenie części plików w katalogu projektu jako ignorowanych – mam na myśli pliki stanowiące wynik kompilacji. W systemie kontroli wersji chcę trzymać tylko źródła. W menu mamy odpowiednią opcję Ignore, która jest powiązana ze zrozumiałym dla Gita plikiem .gitignore.
Praca w ramach jednej gałęzi została już umówiona w poprzednim wpisie. Załóżmy teraz, że wszystkie zmiany zostały wysłane do repozytorium, a prace w ramach nowej gałęzi eclipsebranchtest zostały zakończone.
Podobnie jak w przypadku pracy w konsoli, najpierw muszę przejść do gałęzi, do której chcę wcielić zmiany (w tym wypadku to master). Tam z menu Team wybieram opcję Merge. Pojawi się okienko przedstawione na poniższym obrazku.
Wybór gałęzi do scalenia. Wybieram eclipsebranchtest
No i to by było na tyle! Mogę jeszcze usunąć niepotrzebną już gałąź w Team->Advanced->Delete Branch.
Rebase
Spodziewałam się, że podczas zabawy z branchami dotrę do momentu, w którym potrzebne stanie się słówko rebase, ale tak się nie stało. Nie pozostało mi nic innego jak RTFM. Oto, co ustaliłam (w wielkim skrócie):
Scalać można albo przy użyciu merge, albo rebase. W zależności od dokonanego wyboru, inaczej będzie wyglądała historia zmian w projekcie. Po merge historia będzie dokładnie odwzorowywała to, co się działo – wszystkie rozgałęzienia i powroty. Dla odmiany rebase pozwala nieco przepisać historię, w taki sposób, że – mimo pracy w odgałęzieniach – wygląda ona na liniową. Nie jest to prawda historyczna, ale ta forma może okazać się znacznie bardziej czytelna.
To pierwszy z dwóch wpisów, który chcę poświęcić tematowi kontroli wersji za pomocą Gita. Pierwszy będzie wprowadzający i nie pojawi się w nim słowo rebase. W drugim się pojawi, ponieważ jestem nim zaintrygowana. Obu towarzyszyć będą commity do mojego repozytorium projektowego w ramach konkursu Daj się poznać.
Wstęp (dla informatyków)
Zacznę od wyjawienia wstydliwej prawdy: nie znam się Gicie. Tak wyszło, że w pracy najpierw używaliśmy CVS, potem SVN, potem Perforce (P4). To już i tak niezły mętlik – prosta komenda checkout w SVN i P4 znaczy coś zupełnie odmiennego : odpowiednio pobranie projektu na lokalny dysk albo otwarcie pliku do edycji wraz z zablokowaniem wersji na serwerze. Kilka razy w życiu musiałam dotknąć Gita bądź GitHuba: głównie w zadaniach domowych na Courserze bądź w ramach współpracy z zespołami, które z Gita korzystały.
Życie zmusiło mnie nawet do napisania (wraz z kompanami, co chyba jeszcze pogarsza sprawę) kodu, który automatycznie synchronizował dane w Gicie z danymi w Perforce. Istnieje, co prawda, odpowiedni plugin do P4, ale mieliśmy zbyt starą wersję serwera…
Wstęp (dla tych, co nie lubią „tajemniczych szyfrów”*)
System kontroli wersji to narzędzie, które pozwala śledzić zmiany wprowadzane w dokumencie. Dzięki temu zawsze możesz sprawdzić, Wiesz kto i kiedy wprowadził zmianę (czyli dodał, usunął lub zmienił linijkę tekstu). Jeśli zmiany są wprowadzane przez kilka osób, możesz łatwo (a przynajmniej łatwiej niż w innych okolicznościach) je połączyć. Możesz przywrócić dowolną wersję dokumentu – nawet taką, która w rzeczywistości nigdy nie istniała (np. zawierającą zmiany wprowadzone przez dwie osoby, a bez zmian trzeciej).
Systemy kontroli wersji służą przede wszystkim programistom, ale mogą przydać się właściwie każdej osobie pracującej z tekstem, jak dziennikarz czy tłumacz. Można zresztą pilnować w ten sposób nawet listy zakupów… Żeby jednak w pełni skorzystać z funkcjonalności takiego systemu (np. porównywanie dwóch różnych wersji) dane powinny być w postaci czysto tekstowej – takiej, jaką da się otworzyć za pomocą zwykłego edytora tekstu (jak windowsowy Notatnik).
Obecnie najpopularniejszym systemem kontroli wersji jest Git, któremu poświęcony jest ten wpis. Znalazłam nawet artykuł (po angielsku) o tym, jak wersjonować w Gicie pliki MS Word. Do domowych zastosowań wystarczy prostszy koncepcyjnie Subversion.
* Dostałam dzisiaj taką miłą recenzję: Twojego bloga czyta się jednym tchem (gdy pomijam oczywiście wpisy poświęcone jakimś tajemniczym szyfrom ;)).
Anegdotka
Żeby nie musieć od razu zabierać się do pracy, opowiem jeszcze anegdotkę.
Zostałam kiedyś zaproszona do wygłoszenia wykładu na temat ciągłej integracji. Połowę czasu spędziłam na live coding (yeah). Pokazałam, jak stworzyć projekt i buildy na serwerze Bamboo (w chmurze firmy Atlassian), oraz w jaki sposób można uruchomić (wyzwolić) plany. Ponieważ na moim prezentacyjnym netbooku z Windows 8 (teraz mieszka tam Linux Mint, więc powstrzymajcie kamienie) nie miałam zainstalowanego żadnego systemu kontroli wersji, wyedytowałam plik w GitHubie (kod też miał być w chmurze) przez przeglądarkę.
Na koniec organizator tego spotkania (który zresztą również bierze udział w konkursie) zwierzył mi się, że o ile treść wykładu zawierała informacje już mu znane, to nie miał pojęcia, że można zmieniać kod w GitHubie z poziomu przeglądarki i to właśnie z tego wykładu wyniesie.
W tym celu należy wybrać na stronie opcję New Repository i wybrać pożądane opcje (repozytorium publiczne lub prywatne, puste lub z plikiem Readme.md; można dodać informację o licencji oraz ignorowanych typach plików). W ten sposób powstało repozytorium mojego projektu.
(GitHub oferuje dodatkowe możliwości, jak strony Wiki czy możliwość zgłaszania błędów – ale o tym nie będziemy tu rozmawiać.)
4. Pobrać kod, tworząc przy okazji lokalne repozytorium
W wybranej przeze mnie lokalizacji wywołuję komendę:
1
$git clonehttps://github.com/1nk4/szafbook.git
Zawartość katalogu szafbook:
1
2
3
$ls
LICENSE README.md
Czylimójplik README.mdiplikzinformacjąolicencji.
Jeśli przyjrzymy się dokładniej, znajdziemy jeszcze ukryty katalog z informacjami dla systemu kontroli wersji:
1
2
$ls-a
. .. .git LICENSE README.md
Nie będziemy tam zaglądać.
5. Status
Na wszelki wypadek sprawdźmy teraz status plików projektowych i upewnijmy się, że działamy na aktualnej wersji gałęzi MASTER (główna i domyślna gałąź repozytorium):
1
2
3
4
5
$git status
On branch master
Your branch isup-to-date with'origin/master
nothing tocommit,working directory clean
6. Pora coś popsuć! Zmiana w kodzie
Wprowadziłam zmianę w pliku README.md. Po jej zapisaniu:
1
2
3
4
5
6
7
8
9
10
11
$git status
On branch master
Your branch isup-to-date with'origin/master'.
Changes notstaged forcommit:
(use"git add <file>..."toupdate what will be committed)
(use"git checkout -- <file>..."todiscard changes inworking dir
modified: README.md
no changes added tocommit(use"git add"and/or"git commit -a")
7. Dodanie pliku
Utworzę jeszcze nowy plik w tym samym katalogu. Nazwę go test.txt. Po zapisaniu:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$git status
On branch master
Your branch isup-to-date with'origin/master'.
Changes notstaged forcommit:
(use"git add <file>..."toupdate what will be committed)
(use"git add <file>..."toinclude inwhat will be committed)
test.txt
no changes added tocommit(use"git add"and/or"git commit -a")
Git pokazuje mi, co zmieniłam, a także informuje mnie, że jeśli chcę odwzorować te zmiany w repozytorium, muszę użyć komendy add.
8. Staging: pomiędzy zmianą a commitem
Ponieważ chcę zapisać zmiany w repozytorium, użyję komendy add:
1
2
3
4
5
6
7
8
9
10
11
$git add test.txt
$git add *
$git status
On branch master
Your branch isup-to-date with'origin/
Changes tobe committed:
(use"git reset HEAD <file>..."toun
modified: README.md
newfile: test.txt
9. Wysłanie zmian do repozytorium
Uwaga 1: Na razie do mojego repozytorium na dysku, a nie do centralnego repozytorium GitHub!) Uwaga 2: Na tym etapie git może poprosić o podanie informacji o użytkowniku.
1
$git commit
W domyślnym edytorze tekstu otwarty zostanie plik z informacjami na temat aktualnego zestawu zmian, gdzie należy wprowadzić objaśniający komentarz.
Alternatywnie mogę podać ten komentarz od razu przy wywołaniu polecenia commit:
1
2
3
4
$git commit-m"first commit from local repo"
[master09ba074]first commit from local repo
2files changed,2insertions(+),1deletion(-)
create mode100644test.txt
10. Historia zmian
Historię zmian możemy śledzić za pomocą komendy log:
1
2
3
4
5
6
7
8
9
10
11
12
$git log
commit09ba0745e4fe7f3a410b1ab013ddc080a797ff7d
Author:1nk4<justyna.walkowska@gmail.com>
Date: Fri Mar416:20:572016+0100
first commit from local repo
commit fce6dacc78640c88b33d54549eac60ab1f9972b7
Author:1nk4<justyna.walkowska@gmail.com>
Date: Tue Feb214:16:552016+0100
Initial commit
11. Wysłanie zmian do centralnego repozytorium GitHub
1
$git push origin master
origin to repozytorium, z którego oryginalnie pobrałam kod (czyli mój projekt w GitHub, zapamiętany przy wywołaniu polecenia clone)
master to nazwa gałęzi w repozytorium
Uwaga: gdyby w międzyczasie ktoś zmienił kod w głównym repozytorium, musiałabym najpierw zaakceptować jego zmiany – system nie pozwoliłby mi wysłać moich. W tym wypadku jestem jednak jedyną osobą z prawem zapisu, więc mam pewność, że nie natknę się na tego typu kłopoty.
12. Podejrzenie zmian
Na tym etapie moje zmiany są już widoczne w portalu GitHub! Hurra!
Więcej?
Więcej informacji: np. jak cofnąć wprowadzone zmiany, odkopać starszą wersję, poradzić sobie ze zmianami wprowadzonymi przez różnych użytkowników, znajdziesz w podręczniku na oficjalnej stronie Gita. Jesteśmy teraz w rozdziale Git Basics.
Oznacza to, że w ciągu najbliższych dwóch miesięcy (lub do odwołania) dwa razy w tygodniu będę publikowała tu wpisy na temat mojego projekciku open source. Zrobi się trochę bardziej technicznie. Mam nadzieję, że nie pociągnie to za sobą exodusu Czytelników zaglądających tu w poszukiwaniu lżejszych tekstów okołoprogramistycznych. Postaram się zachować przyjazny ton.
Na co mi to?
Jedno słowo: motywacja.
Cztery słowa: najlepiej pracuję pod presją.
Wielu przyjaciół naiwnie wierzy w moje nieprzebrane pokłady ambicji i samozaparcia. W rzeczywistości, jak uczeń z oślej ławki, robię coś tylko wtedy, kiedy wiem, że ktoś na pewno mnie sprawdzi. W związku z tym pracę nad każdym większym przedsięwzięciem (nie przepadam za słowem „projekt”, chociaż akurat tu akurat pasuje) rozpoczynam od poszukiwań sprawdzacza.
Bądź moim sprawdzaczem.
Jeśli ktoś pokusi się o merytoryczne komentarze i podpowiedzi: tym lepiej dla mnie.
To jest moja garderoba. Praca nad dzisiejszym wpisem wymagała ode mnie między innymi uprzątnięcia sterty prania zalegającego na oknie i na desce do prasowania.
Opis problemu
Mam dużo ubrań, a ciągle chodzę w tych samych, bo nie pamiętam, co jest w dolnych pokładach mojej szafy.
Mam trochę ubrań na wymianę – z których wyrosłam 😉 ja lub moje dziecko.
Rozwiązanie i zarys funkcjonalności
Wymyśliłam sobie aplikację, która umożliwi mi skatalogowanie zawartości szafy oraz jej przeszukiwanie, a także udostępnienie jej zawartości znajomym i ewentualną wymianę bądź wypożyczenia.
Szkic wymagań:
Użytkownik zarządza jedną lub więcej szafami.
Dodaje do szafy ubrania wraz ze zdjęciami i krótkim opisem. Ubrania są umieszczane w odpowiedniej kategorii (ręcznie lub poprzez analizę tekstu, a w bajkowej wersji full-wypas także przez analizę obrazu). Metadane muszą, oczywiście, zawierać rozmiar.
Użytkownik może udostępnić szafę do przeglądania komuś ze swoich znajomych.
Możliwe są wymiany i wypożyczenia.
Dostępne jest semantyczne wyszukiwanie, np. „wszystkie czarne topy” albo „szalik pasujący do tego swetra”.
Technologie
Przyznam, że kusiła mnie szaleńcza idea stworzenia aplikacji webowej w Haskellu. Ostatecznie doszłam jednak do wniosku, że wolę uzupełnić swoją coraz bardziej dziurawą wiedzę na temat Javy. To mój ulubiony język programowania, a nie dotykałam go właściwie od dwóch lat (ponieważ wybór zajęć determinowała dziedzina, a nie preferencje programisty). W tym czasie tworzyłam za to kod w: Perlu, Pythonie, C++, Rubym, R.
Dlatego mimo że JEE to temat nudny i oklepany, tym właśnie chcę się zająć. Wśród rzeczy, których chcę użyć, nauczyć się, przypomnieć sobie lub o nich napisać, są:
Java 8,
jakiś framework webowy, pewnie Spring Boot,
microservices (?),
Maven,
jakieś narzędzie do analizy statycznej,
JUnit,
Git/GitHub,
jakieś darmowe narzędzie do ciągłej integracji, pewnie Jenkins,
jakieś narzędzie do przetwarzania danych RDF/OWL,
któraś nierelacyjna baza danych,
Android w dalekiej, dalekiej przyszłości 🙂
Mój pomysł podoba mi się, bo:
Mogę rozwiązać istniejący problem (być może tylko mój).
Bardzo rzadko mam okazję pisać coś od zera.
Zorientuję się, co się dzieje w Javie.
To przedsięwzięcie da się przekuć w serię przyjaznych wpisów na temat różnych technologii.
Wszystko to trochę wygłup. Zawsze w cenie.
Mój pomysł nie podoba mi się, bo:
Temat jest „dziewczyński”.
Technologie, których chcę użyć, są pospolite.
Od strony technicznej to nic odkrywczego.
Wątpię, żebym w czasie trwania konkursu była w stanie wyprodukować aplikację wartą pokazania.
Zespół cieśni nadgarstka to najwyraźniej przypadłość nie tylko czynnych programistów i pracowników linii produkcyjnych, ale także młodych matek noszących coraz cięższego stwora.
Pora zabrać się do roboty! Nie mam profesjonalnych ortez, jak Erlich. Zamiast nich używam ochraniaczy do jazdy na rolkach. Naprawdę pomagają.
Milsza strona programowania
Ta strona korzysta z ciasteczek. Możesz zablokować je w opcjach przeglądarki, jeśli nie wyrażasz na nie zgody. Rozumiem
