Post Category → polish

EGit development

Nie będę ukrywał, że jestem fanem zarówno Eclipse‘a jak i Git‘a. Idealnym połączeniem obu faktów jest projekt EGit, czyli (jak by ktoś jeszcze nie wiedział albo się nie domyślał) wtyczka dodająca obsługę repozytoriów Git’a do Eclipse’a.

Jakiś czas temu opisywałem EGit’a. Wtedy to już zauważyłem brak kilku opcji w UI. Jedną z nich była np. obsługa tagowania … ale już tak nie jest (a właściwie to nie będzie), gdyż wczoraj wysłałem do Code review efekt kilku godzin mojej pracy. Jeżeli patch zostanie zaaplikowany to w najnowszej wersji EGit’a będzie można już swobodnie tagować i zmieniać nazwy tagów prosto z UI.

BTW. Nie jest to mój pierwszy patch w tym projekcie, kilka dni temu zostały zaakceptowane moje poprawki do jednej z klas w EGit’cie 😉 W zanadrzu mam jeszcze coś … ale o tym za jakiś czas dopiero ;>

Biurko developera v2.0

Jeszcze zanim dotarło do mnie biurko i krzesło wiedziałem, że następnym wydatkiem będzie monitor … w założeniach miało to być trochę później ale jak widać na powyższym zdjęciu realizacja nastąpiła dość szybko.

Dziś właśnie dotarł do mnie 24 calowa matryca LCD, zwana potocznie monitorem ;). Ciągle jestem jeszcze zszokowany jej ogromem.  Nie ma co tutaj porównywać z 13,3″ w MacBook’u; trzeba będzie na nowo zaaranżować sobie przestrzeń pracy w Eclipse’ie. Jeszcze większym wyzwaniem będzie odpowiednia konfiguracja awesome (a właściwie to odpowiednie jego oskryptowanie), żeby możliwe było ergonomiczne korzystanie z dostępnej powierzchni wyświetlanego obrazu. Trzeba będzie dobrać odpowiednie skróty do manipulacji oknami oraz do żonglowania nimi między tagami … ech … plany są spore, czas jest ograniczony wszystko zależy od chęci 😉

Jak na razie po podłączeniu pod wielki monitor głównie z niego korzystam, a wyświetlacz w MacBook’u służy wyłącznie w celach relaksacyjnych 😉

Dopiero teraz swoją użyteczność okazuje zagłówek w krześle. Wcześniej kiedy to wpatrywałem się w monitor w laptopie często odrywałem głowę od niego pochylając ją lekko to przodu. Teraz głowa jest cały czas oparta o zagłówek, oczy są na wysokości głównego monitora … nie wiem na ile jest to poprawna postawa ale na pewno jest lepsza niż ta jaką miałem do tej pory.

Następny etap urządzania przestrzeni developera to system nagłaśniający. Wzmacniacz już jest pozostaje tylko dokupić odpowiednie przetworniki (tj. głośniki) … z tym zakupem na pewno się jeszcze wstrzymam dość szaleństw finansowych …

Biurko developera v1.0

Należę do ludzi których dla których wykonywana praca jest jednocześnie hobby, nie zawsze jest to dobre gdyż zazwyczaj po kilku godzinach pracy wracam do mieszkania i znowu zasiadam do komputera i zajmuję się „czymś”. Nie lubię siedzieć przed telewizorem (nawet takowego nie posiadam) czy też innym „emiterem obrazu” i bezczynnie wpatrywać się w projekcję, wolę czas wolny spędzać aktywne. Przez „aktywnie” rozumiem rozwijanie swoich zainteresowań, zazwyczaj po pracy siadam do jakiś moich mniejszych lub większych projektów, czytam blogi różnego rodzaju i ogólnie rozwijam „się”, ostatnio dla urozmaicenia (oraz zachowania pewnego poziomu zdrowotności) zacząłem biegać.

Kiedy uświadomiłem sobie, że 80-90% czasu spędzam przed komputerem w różnych „dziwnych” miejscach i pozach (a to w kuchni, a to w pokoju, a to przy za małym biurku itp.). Postanowiłem „coś” z tym fantem zrobić, żeby nie być za bardzo „pogięty” na tzw. starość. Od pewnego czasu dorastała we mnie myśl potrzeby zakupu odpowiedniego sprzętu do pracy, po pracy 😉 … w międzyczasie ukazało się parę wpisów odnośnie środowiska pracy.

Kilka dni tygodni temu myśl ta dojrzała tak bardzo, że została została zrealizowana … oto jej efekt 😉

Podstawowe zalety zestawu:

  • biurko:
    • duże
    • bez szuflad i regałów
    • regulowana wysokość blatu
    • solidne
  • krzesło:
    • zagłówek
    • regulacja wysokości, rozstawu oraz kąta podłokietników
    • regulacja kąta pochylenia oparcia
    • regulacja twardości siedziska
    • regulacja oddalenia siedziska
    • regulacja wysokości

Jeżeli pominiemy zewnętrzny monitor i ramię to mój domowy zestaw nie umywa się do tego z którego korzystam w firmie ;>

Do pełni szczęścia brakuje jeszcze mi kilku rzeczy:

  • dużego monitora
  • ramienia do tego monitora
  • nagłośnienia (gdyż nie potrafię pracować w ciszy)

Ale spokojnie, wszystko w swoim czasie 😉 na razie jest solidna podstawa ;>

A jak wygląda Twoje miejsce pracy po pracy ? Ile spędzasz tam czasu ?

Git, EGit i Gerrit …

Podczas prac nad moją pracą inżynierska mam przyjemność używać git’a jako systemu kontroli wersji. Żeby współpraca układała się „zgrabniej” używam wtyczki do Eclipse‘a EGit znajdującej się w inkubatorze Eclispe Fundation (kilka dni temu zdarzyło się mi popełnić mały artykuł na temat EGit’a).

W naszej współpracy brakowało mi pewnych dwóch małych wodotrysków w dialogu do wybierania gałęzi, mianowicie reakcji na podwójne kliknięcie w nazwę gałęzi oraz poruszania się po drzewie za pomocą kursorów. Pomyślałem sobie, że warto by było chłopaków wesprzeć w pracy, w końcu odwalili kawał dobrej roboty … tak więc stworzyłem odpowiednią poprawkę. Niby nic wielkiego … do czasu … okazuje się projekt ten używa rozbudowanego narzędzia do przeglądania (review) i współtworzenia (conribute) kodu no i właśnie tutaj znajduje się problem … ale do rzeczy.

Gerrit, jest rozbudowanym (przynajmniej z mojego punktu widzenia) narzędziem do zarządzania rozproszonym projektem. Wymusza on pewien system pracy. Każdy patch musi zostać przejrzany oraz oceniony zanim trafi do głównego repozytorium. Nad każdą poprawką odbywa się głosowanie; dopiero po uzyskaniu odpowiedniej liczby głosów (od osób uprawnionych) zostanie ona włączona do głównej gałęzi kodu. Dodatkowo każdą linie poprawki można skomentować co ułatwia współpracę w rozproszonym zespole, zwłaszcza z nowymi jego członkami. Wprowadzane poprawki do poprawki ( 😉 ) np. na podstawie komentarzy, są widoczne w jednym miejscu. Całość od strony interfejsu wygląda ładnie i przejrzyście (osobiście nie miałem najmniejszych kłopotów żeby się „połapać” w tym web’owym interfejsie).

Projekt EGit udostępnia dokumentację ułatwiającą rozpoczęcie współpracy z Gerrit’em. Bezproblemowo przez nią przebrnąłem, stworzyłem potrzebne konto, dodałem klucz publiczny, odpowiednio skonfigurowałem Git’a dodając hook‘i … więc można zaczynać zabawę. ;>

Szybkie ogarnięcie w kodzie, lokalizacja odpowiedniej klasy, chwila google’ania o SWT … i gotowa jest poprawka. Szybki commit do lokalnego repo, potem wypchnięcie tego do Gerrit’a … i oczekiwanie na werdykt developerów ;>

Minęły 3 dni … jest pierwszy werdykt … -1 :|. Z mojego pośpiechu wkradły się dwie literówki błąd dość infantylny … no i nie trzymam standardów formatowania (nie potrzebnie ujmuję w klamry jedno-instrukcjowe linie w if’ach i else’ach). Trzeba to poprawić … no i tutaj właśnie zaczęły się strome schody …

Zrobiłem poprawkę, commit, push … Gerrit zamiast dodać tą poprawkę do już istniejącej wyodrębnił to jako zupełnie osobną zmianę … nie tak się umawialiśmy, nie tak miało być.

Jak się po chwili okazuje, EGit nie wspiera hook’ów … w ogóle ich nie używa tak więc w moim commit’cie zabrakło jednej bardzo ważnej linii:

Change-Id:

Teraz muszę to jakoś ręcznie połączyć …

Nie równa walka trwała dwie czy trzy godziny … w tym czasie za-spamowałem trochę skrzynki mailowe commit‘erą, bo dostają maila o każdej nowej poprawce zgłoszonej do systemu, a ja takich nie prawdziwych poprawek podczas walki wprowadziłem :/. Na szczęście całość zakończyła się sukcesem. Tak więc co zrobić jeżeli wypchniemy do Gerrit’a naszą zmianę bez Change-Id i chcemy do niej wprowadzić poprawkę ?

Najpierw musimy się na pewno znajdować w odpowiednim miejscu historii Git’a. Tak więc na początku tworzymy sobie nową gałąź i przełączamy się na nią (oczywiście wszystko robimy z linii poleceń):

git branch fixes
git checkout fixes

Za pomocą git log znajdujemy commit który wypchnęliśmy do repozytorium, niech to będzie np. f4a33b1 (wystarczy 6 pierwszych znaków z SHA-1) i cofamy się w czasie:

git reset –hard  f4a33b1

Dokonujemy potrzebnych zmian, za pomocą git add dodajemy nasze zmiany do commit’a i (ważne), poprawiamy ostatni commit (czyli ten f4a33b1):

git commit –amend

Najlepiej w samej treści wiadomości dołączonej do commit‘a nic nie zmieniać, zatwierdzamy commit wychodząc z edytora. Teraz ponownie odpalamy git log i zapisujemy/zapamiętujemy 6 pierwszych znaków z nowego commit’a (na pewno będą różne od poprzednich), np. ee421a. Wypychamy naszą poprawkę do repozytorium

git push ssh://username@egit.eclipse.org:29418/egit.git ee421a:refs/for/master

Po chwili powinniśmy dostać maila potwierdzającego wprowadzenie zmian.

Uff, to na tyle. Być może jest na to lepszy sposób … ale ten na pewno działa (a nie chcę wystawiać cierpliwości developerów EGit’a na zbyt dużą próbę).

BTW. Ten post starałem się pisać bez zbędnych anglikanizmów … wyszło to raczej średnio, nie mogłem skojarzyć odpowiedniego polskiego odpowiednika dla commit oraz hook.

Gitosis dodanie repo

Prace nad programem do inżynierki zaszły już tak “daleko”, że wypadało by gdzieś ten kod przetrzymywać dla bezpieczeństwa. Dobrym dodatkowym feature’m byla by też możliwość jego wersjonowania … jako, że jakiś temu postawiłem sobie własne repo git’a (dwie (1, 2) z zamierzonych trzech części opisu instalacji zostały już opublikowane) wybór był oczywisty.

Początkowo zadanie wydawało się bardzo banalne … dodać repozytorium do gitosis i wszystko powinno się zrobić automatycznie … cóż tak niestety nie było. Dla potomności (oraz mojej często wątpliwej pamięci) postanowiłem opisać całą procedurę.

Będzie do tego potrzebna nam konfiguracja gitosis. Jako że jest ona przetrzymywana jako jedno z repozytoriów nie powinno być żadnych problemów z jej uzyskaniem. Tak więc jeżeli nie mamy już jakiejś kopi na dysku wywołujemy komendę:

git clone ssh://gitosis@server.z.gitem.org/gitosis-admin.git

Następnie edytujemy plik gitosis.conf w którym odajemy nowe repo:

[repo nazwa-nowego-repo]
owner = joe
description = opis

No i niby wygląda na to, że to wszystko … niestety nie jest tak łatwo, z tego co doświadczyłem to  gitosis wymaga, żeby każde repo posiadało osobną grupę o tej samej nazwie (możliwe, że można to jakoś przekonfigurować ale ja nie znalazłem takich informacji). Więc nie pozostaje nam nic innego jak dodać kolejną grupę:

[group nazwa-nowego-repo]
owner = joe
writable = nazwa-nowego-repo
members = joe

Zapisujemy zmiany i za pomocą git push wypychamy je na serwer … no to konfiguracje gitosis mamy za sobą. Teraz zostało nam jeszcze utworzyć repo ;>

Tak więc w lokalnym systemie tworzymy sobie nowy katalog albo wchodzimy do katalogu projektu który chcemy wrzucić do repo, w środku wywołujemy git init, następnie przy użyciu git add dodajemy wszystkie pliki do commit’a. Potem commit’ujemy zmiany do lokalnego repo (git commit -m “initial commit”) … no i teraz najważniejsze, dodajemy nasze zdalne repo:

git remote add dowolna-nazwa-repo ssh://gitosis@server.z.gitem.org/nazwa-nowego-repo.git

i tryumfalnie wypychamy wszystko na serwer

git push dowolna-nazwa-repo --all

To tyle, wszystko powinno działać … przynajmniej na razie u mnie działa ;>

Dziś lub jutro dodam wpis odnośnie aktualnego stanu wtyczki dodającej obsługę git’a dla Eclipse 😉 będzie to bardzo szybkie overview funkcjonalności których do tej pory użyłem/używałem.

UPDATE:
Wpis o git’cie i eclipse jest prawie gotowy, zostało mi jeszcze opisać branche’owanie, merge’owanie, push’owanie oraz pull’owanie i wstawić screenshot’y 😉

UPDATE2:
Dziś git też mnie pokonał 😐 … okazało się, że aktualnie plugin nie wspiera merge’owania branche’y, a push’owanie i fetch’owanie jest zbyt skomplikowane żeby opisywać je w jednym wpisie (zwłaszcza jeżeli nie ma się z tym zbyt wiele doświadczenia). Postaram się skończyć wpis jutro (zapamiętać: jutro nigdy nie umiera ;)) i go opublikować.