Dariusz [LocK] Łuksza

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.

Kolejna porcja screenshot’ów z “pracy inżynierskiej”

Jak widać doszła obsługa menu, a w niej:

• My location – automatycznie centruje mapę na naszej pozycji
• Start scan(/Stop scan) – “włącza/wyłącza” wątek skanujący
• List AP – wyświetla listę wszystkich Access Point’ów które w czasie działania aplikacji znajdowały się w zasięgu
• Setting – wyświetla ustawienia aplikacji (ta pozycja wymaga jeszcze implementacji)

Trzy z czterech dostępnych akcji są oprogramowane, zostało mi jeszcze stworzyć odpowiednie menu z ustawieniami aplikacji.

Tak wygląda lista wszystkich “odkrytych” Access Point’ów, z lewej strony widać grafikę/piktogram opisujący jakość sygnału danej sieci (w założeniach jest też, żeby ten sam obrazek opisywał poziom zabezpieczeń danej sieci). Obok jest czytelna nazwa punktu dostępowego (czyli SSID). Punkty dostępowe rozróżniane są po BSSID czyli adresie fizycznym urządzenia, więc w szczególnych przypadkach na liście mogą pojawić się kilka pozycji o tej samej nazwie. W każdy element na liście można “kliknąć” i uzyskać widok szczegółowy.

Muszę się dowiedzieć o status licencyjny grafik dołączonych do Androida …

Ostatni screenshot, pokazuje wspomniany już “widok szczegółowy”. Mamy tutaj szczegółowe dane odnośnie wybranego punktu dostępowego. Jak można zauważyć widok ten wymaga jeszcze dopracowania, gdyż nie wszystkie dane są w pełni widoczne.

To na tyle, więcej za jakiś czas

Oto pierwszy screenshot z mojej pracy inżynierskiej

Aplikacja posiada już następujące funkcjonalności:

• Potrafi sprawdzić stan WiFi oraz w razie potrzeby sama go włączyć (nie pytając użytkownika o zdanie … bo po co ? jeżeli się uruchamia taką aplikację wiadomo, że sieć bezprzewodowa musi być włączona )
• Potrafi sprawdzić status usługi GPS oraz poprosić użytkownika o jej włączenie (ponieważ android może za zgodą użytkownika wysyłać dane lokalizacyjne go Google’a warto żeby użytkownik sam włączył usługę, ewentualnie wyłączył moją aplikację)

• Wyświetla aktualną pozycję użytkownika (to jest właśnie ta gwiazdka na środku ekranu)
• Automatycznie co pół sekundy skanuje eter w poszukiwaniu sieci bezprzewodowych.
• W prawym górnym rogu umieszczona jest licznik aktualnie wykrytych sieci
• W prawym dolnym rogu umieszczony jest licznik sieci które aplikacja “mniej więcej” zlokalizowała (ew. potrafiła zlokalizować)

Przewidywane funkcjonalności:

• Automatyczne wycentrowanie mapy na pozycję użytkownika (gwiazdkę)
• Dodanie możliwości konfiguracji (chociażby możliwość zmiany interwału skanowania)
• Obsługa przycisku “menu”
• Zapisywanie wyników aplikacji w “jakimś” formacie
• Kalibracja aplikacji
• Algorytm lokalizacji punktów na podstawie sygnału WiFi oraz lokalizacji użytkownika

Teoretycznie powinno już być z górki, gdyż już w miarę zaprzyjaźniłem się z SDK oraz API android’a. Największym wyzwaniem będzie główna część czyli implementacja (raz opracowanie) algorytmu pozwalającego na zlokalizowanie access point’a; jego zarysy już kłębią się mi w głowie z tym, że posiada on jeszcze kilka słabostek.

Zmiana platformy implementacyjnej znacząco przyśpieszyła prace nad aplikacją

Dziś w ciągu nie całych 2 godzin udało się mi wystartować cały projekt oraz uruchomić usługę Google Maps, GPS oraz zintegrować całość ze sobą. Jedyną rzeczą jaką (na razie) moja aplikacja wykonuje, jest umieszczenie markera (w postaci maskotki androida – robota) na odpowiedniej szerokości i długości geograficznej oraz przesunięcie w to miejsce mapy. Czyli aktualnie geo-lokuje telefon ;>

Całość wymaga jeszcze dopracowania, gdyż jest to tylko szybki szkic … ale posiada bardzo ważna cecha, DZIAŁA . Przede mną jeszcze sporo pracy:

• Ustalenie odpowiednich interface’ów
• Zaprojektowanie architektury aplikacji
• Obsługa wyjątków (reakcja na włączenie/wyłączenie GPS’u, WiFi itp.)
• Obsługa WiFi
• Reprezentacja zebranych danych na mapie
• Zapis całości w formie pliku wynikowego czy tez map w Google Maps

Na chwilę obecną tylko tyle przychodzi mi do głowy, pewnie jeszcze sporo rzeczy wyjdzie w “praniu”.

Do mojego zbioru przydatnych linków doszły dwa nowe elementy, głównie dzięki nim udało się mi tak szybko przebrnąć przez tą część

Siedem semestrów nauki już za mną, czas więc na napisanie pracy inżynierskiej … a czasu zostało nie wiele, bo do końca kwietnia. Tak więc czeka mnie teraz wzmożony okres ;>. Moje ambitne plany zakładają do końca lutego stworzyć aplikację na tyle, żeby można było rozpocząć badania (oczywiście w między czasie aplikacja będzie musiała być ulepszana). Cały marzec mam zamiar poświęcić na przeprowadzenie “badań naukowych”  oraz “napisanie” pracy.

Jeżeli wszystko pójdzie zgodnie z ambitnym planem to w połowie kwietnia powinienem złożyć gotową pracę … zobaczymy jak to wyjdzie.

W pierwotnej wersji moja praca inżynierska miała wiązać się z OpenMoko … niestety semestr walki z JNA nie przyniósł pożądanych efektów dlatego postanowiłem zmienić platformę na “bardziej dojrzałą” (zwłaszcza, że w między czasie nabyłem G1).

Taki obrót sytuacji spowodował, że na chwilę obecną nie posiadam nawet zarysu aplikacji ;>. Ale czym tu się przejmować, nie ma co biadolić czas zabierać się za robotę

IMHO bardzo dobrym quick-start’em jest ta dwugodzinna prezentacja. Zawiera ona dość przekrojową wiedzę potrzebną do tego żeby szybko wystartować z projektem; brakuje w niej opisu manifestu aplikacji, poziomów dostępu do danych i sprzętu … to będzie trzeba uzupełnić na własną rękę.

Oprócz tego standardową kopalnią wiedzy na temat androida jest strona developer.android.com, gdzie dostępne są prezentacje z Google I/O oraz inne sponsorowane przez Google jak również dostępna jest pełna dokumentacja.

W tym poście postaram się agregować wszystkie przydatne linki które okażą się pomocne podczas tworzenia aplikacji. Więc jeżeli interesujesz się tym tematem to zapraszam do zaglądania tutaj … podobnie jeżeli Ty posiadasz jakieś interesujące materiały nie krępuj się umieścić link do nich w komentarzu

• Tutorial pokazujący wykorzystanie widgetu MapView dostępnego w Google APIs (czyli dodatku do standardowego API androida)
• Szybki TUT jak rozpocząć “zabawy” z GPS’em

Ponad rok temu wspominałem tutaj o blogu Mariusz Lipińskiego w kontekście SCJP. Od wspominanego wpisu minął ponad rok. W tym czasie Mariusz zdążył uzyskać certyfikat, a nawet opublikować dwa wydania własnej książki (pierwsze jest całkowicie darmowe, a drugie można kupić tutaj), dodatkowo na łamach bloga krótko opisuje każdy rozdział z Sun Certified Programmer for Java 5 Stury Guide.

Ja w tym samy czasie próbowałem moich sił z  Sun Certified Programmer for Java 6 Stury Guide (SCJP6SG), cóż ukazał się dokładnie jeden post o tym temacie (w sumie to nie ma się czym chwalić ), a natłok obowiązków związanych ze studiami i pracą nie pozwolił mi kontynuować tą serię wpisów.

Wspomniałem już wcześniej o książce Mariusza w formie drukowanej, dziś właśnie dotarł do mnie jeden jej egzemplarz. Objętościowo jest on nie do porównania z SCJP6SG. Jeszcze nie zagłębiałem się dokładnie w Przygotowanie do certyfikacji SCJP6 ale zakładam, że jest to odpowiedni wstęp jak i repetytorium przed i po zapoznaniem się z SCPJ6SG.

W tym roku nie ma już raczej szans żebym przystąpił do egzaminu … ale za to postaram się to zrobić w przyszłym

Kilka dni temu JetBrains udostępniło okrojona wersje (ładnie nazwaną Community Edition) swojego IDE dla Javy. Jako że nigdy nie miałem do czynienia z InteliJ postanowiłem zassać ową darmową wersję i sprawdzić jak się spisuje.

Niestety, używam dość egzotycznego window managera który zwie się Awesome. Posiada on funkcjonalność auto organizacji okien na pulpicie co jak się okazuje nie podoba się Javie 1.5 wzwyż. Winę za to ponosi zmieniony w JRE 1.5 backend do komunikacji z X-Window, JRE do wersji 1.4 korzystało z Motif, natomiast w późniejszych z Xtoolkit/XAWT które to nie jest kompatybilne z ICCCM (cokolwiek to znaczy ). Warto tutaj wspomnieć ze pośrednio może tutaj tez być winne JetBrains gdyż ciągle korzystają z AWT, a nie Swing‘a …

Rozwiązania ?
Są dwa. Pierwsze bardziej drastyczne uruchamiać InteliJ z wykorzystaniem JRE 1.4 – tego nie próbowałem ale teoretycznie powinno zadziałać. Drugie rozwiązanie posiada pewien haczyk, gdyż (jak się domyślam) 64-bitowa wersja Javy nie posiada wsparcia dla Motif; osoby posiadające 64-bitowe maszyny i systemy operacyjne z 64bitowa maszyna wirtualna ustawiona jako domyślną muszą dodatkowo zassać i gdzieś umieścić wersje 32-bitowa JDK/JRE. Oprócz 32-bitowej maszyny wirtualnej musimy dodać zmienna środowiskową AWT_TOOLKIT ustawiona na MToolkit. Ja zmodyfikowałem sobie plik bin/idea.sh dodając w linii 59 taki oto fragment:

# fixes for Awesome WM
export AWT_TOOLKIT="MToolkit"
IDEA_JDK="/ścieżka/do/jdk-x86"

Dziś światło dzienne ujrzała stabilna wersja GWT 1.6, o zmianach i nowościach pisałem już wcześniej, dodatkowo nowością (przynajmniej dla mnie) jest plug-in do eclipse’a dodający parę wizardów i nowych funkcjonalności. Teraz najważniejsze, gwt moża pobrać tutaj, a plugin do eclipse’a stąd ;>

Sesja sesją, ale w między czasie umknęły mi dwa w miarę ważne wydarzenia … myślę tutaj o 2 milestone’ach GWT 1.6.

Nie ma co tu ukrywać trochę czasu minęło, nie jest to już nowinka … ale wprowadzone zmiany w najnowszej wersji Google Web Toolkit są dość spore.

Przede wszystkim trzeba tutaj wymienić zmianę podejścia do reakcji na zdarzenia. W najnowszym GWT  zrezygnowano ze wzorca obserwatora (observer pattern) na rzecz podejścia zdarzeniowego. Dodatkowo można programowo (z kodu Java’y) wywoływać zdarzenia systemowe (takie jak np. kliknięcie na przycisk) na widget’ach, w poprzednich wersjach nie było to możliwe.

GWTSchell i GWTCompiler zostają zastąpione przez HostedMode i Compiler. Dodatkowo w HostedMode zostało zastosowane Jetty (zamiast Tomcat’a) oraz dodano, jakże przydatną funkcję (jeżeli zmienia się implementację serwisów RPC lub przesyłanych encji), restartu servlet contener’a bez konieczności restartu całej aplikacji.

Kolejną ważną zmianą jest zmiana struktury katalogów w war’rze, rezygnacja z ogólnego katalogu public.

Wprowadzono dwa nowe widget’y:

• DatePicker – jak sama nazwa mówi służy do wyboru daty
• LazyPanel – załaduje zawartość panelu po pierwszej interakcji ze strony użytkownika

Standardowo,  poprawiono wydajność generowanych java script’ów oraz błędy.

To na tyle szybkiego przeglądu, więcej informacji można znaleść tutaj, a samo GWT zassać można z tąd … trzeba będzie znaleść chwilę czasu żeby się przyjrzeć bliżej nowej wersji GWT

W poprzednim wpisie, pokazałem jak wystawić pojedynczy węzeł (node), dziś zrobię/zrobimy trochę więcej, a mianowicie opublikujemy “wiadomość”, a przede wszystkim odbierzemy zdarzenie o utworzeniu wiadomości. Przecież o tą zaletę XMPP-PubSub nam (a przynajmniej mi ) najbardziej chodzi … o jego zdarzeniowy charakter ;> … a więc do roboby

Czytaj więcej…