Archiwa tagu: daj się poznać

Konkurs “Daj się poznać”: status i wrażenia

Nawet okazjonalni Czytelnicy mojego bloga z pewnością zdążyli już się zorientować, że obserwowalny od początku miesiąca tajemniczy zalew (głównie technicznych) wpisów jest związany z moim udziałem w programistyczno-blogerskim konkursie Daj się poznać. Dla rozluźnienia atmosfery, w tym przedświątecznym wpisie chciałabym podsumować swoje dotychczasowe wrażenia.

1. Aaaa! Dwa wpisy w tygodniu to za dużo.

Dla czytelników, jak i dla pisarzy.

Wydaje mi się, że “siedząc w domu” na urlopie macierzyńskim (przy innej okazji możemy porozmawiać o tym, ile dokładnie ma to wspólnego z siedzeniem), w tygodniu mam miej więcej tyle samo czasu, co wtedy, kiedy chodziłam na 8-9 godzin do pracy. Dokładając do tego normalnie życie, inne hobby (dowiedziałam się o konkursie krótko po tym, jak zapisałam się na dość intensywny kurs pisarski, o czym pewnie jeszcze wspomnę)… Siadam do projektu obowiązkowe dwa, czasem trzy razy w tygodniu i za każdym razem panikuję, czy wydarzy się coś wartego opowiedzenia.

Cierpię także jako czytelnik cudzych blogów. Konkurs generuje masę cudnych treści (o tym poniżej), z których konsumpcją nie jestem w stanie nadążyć. Zakładam jednak, że większość z nich zostanie w tak zwanej blogosferze i później nadrobię sobie zaległości.

2. Ile ludzi! Ile fajnych projektów!

Maciejowi (pomysłodawcy i organizatorowi konkursu) należą się ogromne brawa za skłonienie takiej masy ludzi do wyjścia ze swoich norek i dzielenia się wiedzą – oraz osobowością. Jestem bardzo ciekawa, ile blogów pozostanie aktywnych po konkursie. Szczerze kibicuję przynajmniej kilku z nich, nawet jeśli, jak wspomniałam powyżej, na razie niespecjalnie nadążam z konsumpcją treści.

3. Ile ludzi! A ile wśród nich… kobiet?

Na stronie z uczestnikami doliczyłam się 296 osób. Imion żeńskich mamy 22 (zakładając, że “Dziewczyna” to również imię żeńskie), co daje nieco ponad 7%. Mało. A z drugiej strony to aż 22 Polki z technicznymi blogami!

4. Slack: doprawdy, za mało mam przeszkadzaczy…

Wśród atrakcji konkursowych pojawił się Slack (“ty nowinkarzu” powiedział na wieść o tym mój mąż). Na kilku konkursowych kanałach toczą się zażarte dyskusje. Szczerze mówiąc, mam mieszane uczucia. Z jednej strony sporo tam wartościowego materiału. Z drugiej, przecież ja staram się z całej siły walczyć z odciągaczami uwagi, zwłaszcza tymi, które chcą wyświetlać powiadomienia na moim ekranie! Ostatecznie zaglądam tam maksymalnie raz dziennie, widzę końcówkę dyskusji i czuję się jak nastolatka, którą przez surowych rodziców omija fajna impreza. No trudno.

5. +100 do motywacji.

Zapisując się na konkurs, szukałam przede wszystkim motywacji. Ten cel uznaję, póki co, za zrealizowany. Jeśli chodzi o moje konkursowe podcele, wystawiam sobie następujące oceny:

  • Blogowanie: 100%. Trzymam się konkursowych wymogów i póki co nie wstydzę się żadnego wpisu 🙂
  • Nauka: 90%. O wiele lepiej ogarniam Gita, zaczynam poruszać się w świecie Spring Boot. Poznałam nowy silnik szablonów, Thymeleaf. Jest dobrze, chociaż chciałabym dokładniej zagłębić się w te zagadnienia.
  • Kodowanie: 70%. Blogowanie zżera mi za dużo czasu 🙂 Ale coś się na moim GitHubie dzieje, zatem mamy nieskończenie wielki skok z zera do czegoś namacalnego.

6. Nowi goście na moim blogu

Od kiedy zaczęłam się udzielać konkursowo, na moim blogu (i jego facebookowym fanpage’u) pojawia się więcej komentarzy osób, których nie znam osobiście. Dziękują lub doradzają. To ogromnie budujące. Wzrosła też codzienna liczba wejść na mojego bloga.

7. Starzy goście na moim blogu

Ciągle boję się, że przez zalew technikaliów odejdą ode mnie czytelnicy szukający tu tematów ogólniejszych. Jedyne co mogę zrobić, to obiecać im (Wam) większą różnorodność w przyszłości. Osobą szczególnie poszkodowaną jest mój nauczyciel z kursu pisarskiego, któremu powiedziałam, że staram się na informatycznym blogu uprawiać storytelling. No cóż, ostatnio niezbyt wychodzi. A ja naprawdę lubię pisać, tak po prostu i po polsku 🙂

8. Organizacja konkursu: zbawienne dwa tygodnie przerwy

Jestem bardzo wdzięczna za przewidziane przez regulamin dwa tygodnie przerwy. Konkurs trwa 12 tygodni, blogować trzeba przez 10. W przyszłym tygodniu czeka mnie operacja nadgarstka. Na parę dni rozstanę się z klawiaturą.

Co takiego stało się z moim nadgarstkiem? Otóż ani to (tym razem) cieśń nadgarstka, ani nawet podnoszenie wierzgających 6 kilo. Uparłam się, że wniosę z mężem na piętro zawadzający mi stół z litego drewna. Przedsięwzięcie to trwało około 3 nieprzyjemnych minut i wystarczyło do spowodowania trwałego uszczerbku w postaci zespołu de Quervaina. Ludzie, szanujcie swoje coraz starsze ciała. Dobrze Wam radzę.

stolik
Zabójca nadgarstków

9. Organizacja konkursu: przedwcześnie odkryłam karty

Udział w konkursie wymagał ode mnie poniesienia pewnych kosztów psychicznych. Musiałam wymyślić jakiś projekt. Bałam się, że będzie durny i niewystarczający. Nie potrafiłam przewidzieć, z czym wystąpią inni uczestnicy. Dlatego poczułam się zrobiona w balona, kiedy rejestracja została przedłużona o dwa tygodnie, a zgłoszone wcześniej aplikacje zostały już ujawnione.

10. Organizacja konkursu: wolę merytokrację

Z zasady nie biorę udziału w konkursach, w których o zwycięstwie decyduje liczba polubień. Zdecydowanie wolę konkursy z jury. W tym wypadku nie sprawdziłam zawczasu – szukałam motywacji, nie nagród. W końcu jednak zainteresował mnie sposób wyłaniania zwycięzców. Wyczytałam tyle: “Uczestnicy i Społeczność (Obserwatorzy) dostaną ankietę do wytypowania swoich ulubieńców. Wpływ na to będą mieli również Sponsorzy oferujący swoje dedykowane nagrody. Ja jako Organizator będę interweniował w przypadkach konfliktów/niejasności.” A więc kliki 🙂 No trudno.

Jestem ciekawa wrażeń innych uczestników. Na szczęście łatwo podejrzeć ich posty, może ktoś coś na ten temat napisze 🙂

PS. Blog Macieja zaczęłam obserwować niedługo przed ogłoszeniem konkursu. Ostatnio mam wrażenie, że dzieje się na nim trochę mniej. Czyżby pochłonęła go lektura wpisów prawie 300 podopiecznych? 🙂

PS2. A jak już jesteśmy przy konkursach i nagrodach, to pochwalę się zdobytym w ubiegły weekend medalem. Przebiegłam Maniacką Dziesiątkę! Zajęłam miejsce ok. 4300 na 5000 i jestem z siebie BARDZO dumna. Pomógł mi pan w stroju lisa, który biegł przede mną i utrzymywał równe, rekreacyjne tempo.

2016-03-25 12.58.08
Co jeszcze robię zamiast pisania: Maniacka Dziesiątka

A więc do tego służy git rebase!

Miałam zakończyć raportowanie postępów w nauce systemu kontroli wersji Git, ale właśnie zrozumiałam coś istotnego.

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ę:

Aktualny stan aplikacji (commit bbafde0)
Aktualny stan aplikacji (commit bbafde0)

2. Eclipse jak zwykle trzymał rękę na pulsie:

O trzy kroki do przodu względem zdalnej gałęzi master
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:

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?
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!
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
Nowy komentarz do commita

7. Wracam do konsoli, gdzie czeka na mnie podnoszący na duchu komunikat:

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
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
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:

3.. 2.. 1.. Witaj, Spring Boot!

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.

Szkielet aplikacji

Za radą Java Magazine, szkielet aplikacji wygenerowałam przy użyciu serwisu Spring Initializr.

Struktura projektu Spring Boot
Struktura projektu Spring Boot

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:

  • @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.

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…

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ą:

  1. Ciągłej Integracji,
  2. “M” w MVC, czyli modelowi danych.

Jeśli chodzi o blogowanie, to planuję wpisy bezpośrednio związane z rozwojem kodu, a dodatkowo:

  1. git rebase, którego znaczenie wreszcie zrozumiałam,
  2. 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ą
Oficjalne logo języka Java – parujący kubek z kawą

 

 

Git: przedzieram się przez gałęzie

System kontroli wersji Git był tematem dwóch niedawnych wpisów na moim blogu: No i Git! Kontrola wersji służy nie tylko programistom oraz Git w Eclipse. W tym odcinku chcę na jakiś czas zamknąć temat. Skoncentruję się na kwestii odgałęzień w kodzie (branches).

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ń
  1. Utworzenie nowego brancha w konsoli.
  2. W ramach brancha: przygotowanie szkieletu aplikacji Spring Boot za pomocą serwisu https://start.spring.io/.
  3. Wcielenie zmian z nowego brancha do głównej linii kodu (konsola).
  4. Utworzenie brancha przez interfejs Eclipse.
  5. W ramach brancha: prace mające doprowadzić kod do stanu, w którym się kompiluje.
  6. Wcielenie zmian z nowego brancha do głównej linii kodu (Eclipse).
  7. Ustalenie, dlaczego nie było mi potrzebne słowo rebase.
Konsola

W oparciu o informacje w odpowiednim rozdziale podręcznika, tworzę nową gałąź (o nazwie bootinit):

Powyższe polecenie jest skrótem dla dwóch innych, z których pierwsze tworzy brancha, a drugie mnie do niego przenosi:

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ę):

5
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:

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:

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.

8
Merge. Kolory bardzo przyjemne

Jeśli gałąź nie będzie mi już potrzebna, mogę ją usunąć:

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
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.

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
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.

[edit: popełniłam jeszcze jeden wpis na temat rebase]

PS.

Wrócę z tematem Gita, jak dorobię się pierwszego poważnego konfliktu w kodzie.

Git w Eclipse

W poprzednim wpisie nauczyłam się – a może przy okazji chociaż jednego Czytelnika – jak kontrolować wersje programu przy użyciu systemu Git i serwisu GitHub. Dzisiaj postanowiłam sprawdzić, jak powiązać repozytorium Git ze środowiskiem programistycznym Eclipse, w którym zamierzam rozwijać swój projekt. Szczególnie ciekawiło mnie, w jaki sposób Eclipse rozwiązuje kwestię dwóch poziomów repozytorium: lokalnego na dysku i zdalnego w chmurze (GitHub).

Gdyby na tym etapie ktoś chciał zwrócić mi uwagę, że rozwijam swój projekt od d**y strony, to uprzejmie informuję, że jestem tu imperatorem. Moim celem jest przede wszystkim nauczenie się czegoś w przyjemny sposób. Jeśli kiedyś w końcu wyjdzie z tego produkt – tym lepiej.

Poniżej przedstawiam kroki potrzebne do powiązania mojego kodu w GitHub z projektem w środowisku Eclipse.

  1. Instalacja Eclipse, oczywiście. W moim przypadku jest to wersja Mars dla programistów Java Enterprise Edition. Nie twierdzę, że to bezsprzecznie najlepsze IDE, ale zamierzam używać go w konkursowym projekcie. Tutaj można znaleźć opisy najpopularniejszych darmowych edytorów dla Javy (po angielsku).
  2. Instalacja w Eclipse narzędzia EGit.

    Help->Install New Software
    Help->Install New Software->http://download.eclipse.org/egit/updates/
  3. Stworzenie nowego projektu w oparciu o istniejący kod.

    import
    File->Import->Projects from Git
  4. Wybranie jednej z dwóch opcji: nowe lokalne repozytorium z kodem z GitHub (clone) lub istniejące lokalne repozytorium powiązane wcześniej z GitHub (np. to, które stworzyłam w konsoli na potrzeby poprzedniego wpisu).

    clone
    Klonowanie!
  5. Podanie adresu projektu w GitHub

    clone2
    W przypadku publicznego repozytorium w GitHub wystarczy podać link
  6. Wybór gałęzi – u mnie na razie jest tylko jedna, główna.

    clone3
    Co by tu wybrać?
  7. Podziwianie zaimportowanego projektu.

    project
    Tak wygląda projekt zsynchronizowany z repozytorium Git
  8. Zmiany w kodzie. Zmodyfikowałam treść jednego pliku i dodałam jeden nowy. EGit natychmiast bardzo wyraźnie sygnalizuje te zmiany.

    project2
    Jeden plik zmieniony, jeden plik utworzony, ale jeszcze nie wersjonowany
  9. Wyświetlenie menu kontroli wersji (opcja Team w menu kontekstowym projektu). Ponieważ chcę dodać do kolejnego commita wszystkie wprowadzone zmiany, wybieram opcję Add to Index (w konsoli to git add).

    team1
    Menu kontroli wersji w projekcie
  10. Zmieniły się ikonki! Zmiany zostały oznaczone jako zaplanowane do wysyłki (staged), ale ciągle nie nastąpił commit.

    team2
    Przed commitem
  11. Wybranie z menu opcji Commit. Do wyboru mamy – i to jest moment, na który czekałam – wysłanie zmian tylko do lokalnego repozytorium, bądź wysłanie ich i lokalnie, i dalej, do GitHub.

    team3
    Wysyłamy zmiany
  12. Mniej więcej na tym etapie nastąpi wreszcie prośba o logowanie.

    credentials
    To repozytorium jest otwarte dla wszystkich do odczytu, ale tylko wybrańcom wolno wysyłać do niego kod
  13. Zdecydowałam się na wysyłkę z jednoczesnym wypchnięciem kodu do GitHub (może niezbyt rozsądnie, ale wszystko to w ramach eksperymentu). Sprawdzę teraz, czy moje zmiany są widoczne w serwisie.

    github
    Co słychać w GitHub? Wprawne oko zauważy w commicie plik, o którym nie wspominałam wcześniej. Zagadka: dlaczego tam trafił?
  14. Historię zmian mogę podejrzeć także od strony IDE.

    view
    Praca wre

Jak na razie, wszystko przebiegło bardzo intuicyjnie. W najbliższym czasie postaram się utworzyć rozłączne gałęzie kodu z konfliktującymi zmianami (tu wstaw szatański śmiech).

Więcej informacji na temat korzystania z EGit znajdziesz w instrukcji użytkownika.

PS. Mam bardzo silne skojarzenie z wyrazem eclipse (zaćmienie). W wieku wczesnonastoletnim, podczas wakacji nad polskim morzem, namówiłam tatę i siostrę na pójście do kina. Grali akurat film z młodym Leo DiCaprio, w którym kochała się połowa podstawówki. Film nazywał się Całkowite zaćmienie i traktował, jak się okazało, o zakazanej homoseksualnej miłości.  Obejrzenie tego w obecności rodzica zdecydowanie plasuje się w top 5 najbardziej żenujących sytuacji w moim życiu.

No i Git! Kontrola wersji służy nie tylko programistom

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.

Treść wykładu można znaleźć na blogu: Ciągła Integracja: anioł stróż dobrego programisty i Ciągła Integracja: jak skonfigurować proces budowania na serwerze Bamboo?

 

Git: cechy charakterystyczne

  • System rozproszony: programiści utrzymuję własne lokalne repozytoria i tylko czasami wysyłają kod do repozytorium głównego.
  • Łatwość tworzenia i scalania gałęzi (branches) do pracy nad różnymi wersjami czy funkcjonalnościami.
  • Staging Area: można wygodnie wskazać, które spośród wprowadzonych zmian mają się znaleźć w commicie, nawet jeśli dotyczą tego samego pliku.
  • Darmowe narzędzie z otwartymi źródłami.

githubheart

Do rzeczy: jak wersjonować projekt w Gicie i przechowywać w ogólnodostępnym repozytorium GitHub?

W 12 krokach:

1. Zainstalować Git w wersji dla odpowiedniego systemu ze strony https://git-scm.com/downloads.
2. Utworzyć konto na stronie GitHub: https://github.com/
3. Utworzyć repozytorium dla projektu

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ę:

Zawartość katalogu szafbook:

Jeśli przyjrzymy się dokładniej, znajdziemy jeszcze ukryty katalog z informacjami dla systemu kontroli wersji:

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):

6. Pora coś popsuć! Zmiana w kodzie

Wprowadziłam zmianę w pliku README.md. Po jej zapisaniu:

7. Dodanie pliku

Utworzę jeszcze nowy plik w tym samym katalogu. Nazwę go test.txt. Po zapisaniu:

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:

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.

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:

10. Historia zmian

Historię zmian możemy śledzić za pomocą komendy log:

11. Wysłanie zmian do centralnego repozytorium GitHub

  • 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.

Dam się poznać: mój projekt open source

Zgodnie z zapowiedzią w poprzednim wpisie (o prokrastynacji), postanowiłam wziąć udział w konkursie Daj się poznać organizowanym przez Macieja Aniserowicza z bloga devstyle.

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.

A na co mi sam blog? O tym chyba tutaj: O mnie.

Mój pomysł: szafbook

szafa
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

  1. Mam dużo ubrań, a ciągle chodzę w tych samych, bo nie pamiętam, co jest w dolnych pokładach mojej szafy.
  2. 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ń:

  1. Użytkownik zarządza jedną lub więcej szafami.
  2. 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.
  3. Użytkownik może udostępnić szafę do przeglądania komuś ze swoich znajomych.
  4. Możliwe są wymiany i wypożyczenia.
  5. 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ą:

  1. Java 8,
  2. jakiś framework webowy, pewnie Spring Boot,
  3. microservices (?),
  4. Maven,
  5. jakieś narzędzie do analizy statycznej,
  6. JUnit,
  7. Git/GitHub,
  8. jakieś darmowe narzędzie do ciągłej integracji, pewnie Jenkins,
  9. jakieś narzędzie do przetwarzania danych RDF/OWL,
  10. któraś nierelacyjna baza danych,
  11. Android w dalekiej, dalekiej przyszłości 🙂

Mój pomysł podoba mi się, bo:

  1. Mogę rozwiązać istniejący problem (być może tylko mój).
  2. Bardzo rzadko mam okazję pisać coś od zera.
  3. Zorientuję się, co się dzieje w Javie.
  4. To przedsięwzięcie da się przekuć w serię przyjaznych wpisów na temat różnych technologii.
  5. Wszystko to trochę wygłup. Zawsze w cenie.

Mój pomysł nie podoba mi się, bo:

  1. Temat jest „dziewczyński”.
  2. Technologie, których chcę użyć, są pospolite.
  3. Od strony technicznej to nic odkrywczego.
  4. Wątpię, żebym w czasie trwania konkursu była w stanie wyprodukować aplikację wartą pokazania.

Informacje techniczne

  1. Wpisy konkursowe będę oznaczać tagiem daj się poznać.
  2. GitHub: https://github.com/1nk4/szafbook
  3. www: http://szafbook.pl/

PS.

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.

erlich
Pora zabrać się do roboty! Nie mam profesjonalnych ortez, jak Erlich. Zamiast nich używam ochraniaczy do jazdy na rolkach. Naprawdę pomagają.

Ekshibicjonistyczny wpis o prokrastynacji i diecie informacyjnej

Dziś o marnowaniu czasu w Internecie.

Zaczęło się od tego, że…

Postanowiłam wziąć udział w konkursie Daj się poznać. Konkurs wymaga utworzenia projektu open source i blogowania o postępach prac. Jako że różnych hobby[1] mam więcej niż Java bibliotek ORM (hłe, hłe), a moment w życiu nie zachęca do rzucania się z motyką na cokolwiek – potrzebowałam zewnętrznej motywacji do działania.

Czas pokaże, czy wystarczy mi determinacji do samego końca. Póki co, rozmyślam o prokrastynacji i szkodliwych nawykach. Z tej okazji kolejny raz wróciłam do przełomowej dla mnie książki Information Diet Claya A. Johnsona.

Jeszcze jeden brzydki wyraz

Prokrastynacja” to nie jest ładne słowo. Nie ma go w „Słowniku języka polskiego” PWN, a to prawie zawsze oznacza, że istnieje już poprawne polskie słowo oznaczające dokładnie to samo. Najpiękniejszy wolny przekład, z jakim się spotkałam, to „kunktatorstwo”, ale bliżej sedna jest chyba zwykłe „zwlekanie”.

Prokrastynację najczęściej powoduje niepokój (przed porażką lub, o dziwo, sukcesem), a jej najbliższym pomagierem jest, oczywiście, Internet.

Najlepsze remedium na prokrastynację…

… to sprawowanie opieki nad niemowlęciem. Takie odkrycie z ostatnich trzech miesięcy 🙂 Mimo że mam „aniołka”, który płacze tylko, gdy ma realny problem, to znalezienie chwili na kreatywny namysł graniczy z niemożliwością. W efekcie wiem, że kliknięcie w ten jeden kuszący link istotnie zwiększy ryzyko, że pracę nad kolejną linijką (gdy wreszcie się za nią zabiorę) przerwie rozdzierający wrzask. To naprawdę skuteczny wspomagacz dyscypliny.

Siła nawyku i obiecany ekshibicjonizm

Czas się przyznać. Nawet przy dziecku mam potężny problem z pozbyciem się jednego szalenie szkodliwego i trochę wstydliwego nawyku. Czytam w wannie. Uwielbiam czytać w wannie. Nie od święta i nie zawsze przy świecach. Prawie codziennie. Rano. Książkę, ale także głupoty w Internecie.

Mądrzejsi od mnie twierdzą, że nawyk składa się z trzech elementów: wyzwalacza, reakcji oraz nagrody, i że można tę sekwencję wykorzystać do świadomego wytworzenia nawyków pożądanych. Chciałabym, po dzwonku budzika, na autopilocie lądować w lesie na przebieżce z psem (póki mąż w domu), a nie w wannie w stanie półhibernacji! Trzymaj za mnie kciuki.

Czy nabijasz się z milionów Polaków bezmyślnie wpatrzonych w telewizor?

Jak wielu moich przyjaciół, nie oglądam telewizji. Mogę sobie gratulować, że wiele dzieli mnie od statystycznego Polaka, który spędza przed telewizorem zatrważające 4,5 godziny dziennie. Tylko że… Nie czarujmy się. Internet niekoniecznie jest lepszy, a w wydaniu większości (do której pewnie należę) zdecydowanie taki nie jest.

Internet to największy zasób wiedzy na świecie, a jednocześnie największy zasób głupoty.

Pamiętaj, że mózg staje się najlepszy w tym, w czym regularnie go ćwiczysz. Czy warto wyspecjalizować się w podążaniu za clickbaitem (odmieniłam, a co)?

Dieta informacyjna

Autor Information Diet porównuje konsumpcję informacji do konsumpcji żywności.

Tak jak w przypadku jedzenia, najzdrowsza jest informacja nieprzetworzona, pochodząca z samego źródła. Zatem nie wiadomości na portalach i w tygodnikach opinii, tylko artykuły naukowe, notatki agencji prasowych, potwierdzone relacje świadków, poparte źródłami analizy ekspertów. Porównanie wbrew pierwszemu wrażeniu nie jest na wyrost. Autor wskazuje informacyjne odpowiedniki śmieciowego jedzenia i tłumaczy, jakie mechanizmy sprawiają, że nabieramy się na jedno i drugie.

Co ciekawe, problemu nie rozwiązuje samo publiczne udostępnienie źródeł (np. rządowych raportów na temat wydatków), ponieważ czytelnik musiałby jeszcze do nich sięgnąć. Porównanie z książki: zalanie rynku brokułami nie sprawi, że ludzie zaczną odżywiać się zdrowo. Musimy zdobyć się na świadomy wysiłek.

Tak jak w przypadku jedzenia, w przypadku informacji również można przejść na dietę.

  • Odmawiać sobie klikania linków w stylu „a wtedy stało się TO”.
  • Trenować interwałami utrzymywanie uwagi i koncentracji.
  • Sięgać do źródeł.
  • Sprawdzać pochodzenie zdjęć (w Google Images można szukać zdjęć podobnych do danego zdjęcia oraz wcześniejszych wystąpień tego samego zdjęcia w artykułach).
  • Zaglądać do magazynów prezentujących przeciwną opcję polityczną.

Istnieją narzędzia pozwalające zwiększyć produktywność przy komputerze. Jednym z nich jest RescueTime, które śledzi naszą aktywność i przedstawia raporty na temat czynności wartościowych i nie. Narzędzie jest konfigurowalne i podobno bezpieczne.

Zadanie domowe

Chciałabym zaproponować Ci zadanie domowe.

Jeśli jeszcze tego nie robisz: następnym razem, kiedy poruszy Cię wiadomość przeczytana w Internecie, postaraj się dotrzeć do samego źródła. Znajdź nagranie, cytat, raport z badań. W wersji „z gwiazdką” sprawdź dodatkowo, czy w ogóle i w jaki sposób piszą na ten sam temat media z przeciwnej opcji.

Dzielę się swoimi wynikami: news, który mnie zbulwersował, okazał się niestety niepodkolorowaną prawdą. Kandydat na prezydenta, poseł i ojciec trzech córek faktycznie insynuował że nieatrakcyjna (jego zdaniem) kobieta powinna cieszyć się z molestowania.

 

[1] Do bardzo niedawna sądziłam, że mój nadmiar zainteresowań jest głęboką patologią. Natknęłam się jednak na cudowne wystąpienie Emilie Wapnick na TED i odetchnęłam z ulgą. Polecam.

[2] Obrazek w nagłówku pochodzi stąd: https://sketchport-hrd.appspot.com/drawing/5795385024970752/hotdog. Okazało się, że nie potrafię narysować hot doga.