piątek, 15 czerwca 2012

Integracja IBM Synergy z kdiff3

Mała porada dla osób korzystających (a raczej zmuszonych do korzystania) na co dzień ze "wspaniałego" narzędzia „configuration management solution for global software development”, jakim jest IBM Rational Synergy. O wadach tego narzędzia nie będę się tutaj rozpisywał, bo bym potrzebował osobny post na to, a artykuł na temat zalet zostawiłbym pusty. Sparafrazuję jedynie zdanie ziomka: „IBM sprzedał Synergy ludziom, którzy tak naprawdę w ogóle go nie potrzebują”. I rzeczywiście jest to prawda.

Można na całe szczęście przynajmniej wymienić narzędzie do porównywania i merge'owania plików. Poniżej instrukcja.

  • Ściągamy i instalujemy kdiff3 (jeśli jeszcze nie mamy)
  • Odszukujemy plik ccm.properties w katalogu instalacyjnym Synergy\etc.
  • Robimy kopię
  • Otwieramy oryginał i zamieniamy
    windows.tool.compare.ascii  = %ccm_compare

    na
    windows.tool.compare.ascii  = "C:\\Program Files (x86)\\KDiff3\\kdiff3.exe" -cs EncodingForA=UTF-8 –cs EncodingForB=UTF-8 "%file1" "%file2"
  • a także
    windows.tool.merge.ascii    = %ccm_merge

    na
    windows.tool.merge.ascii = "D:\\Program Files (x86)\\KDiff3\\kdiff3.exe" --cs "EncodingForA=UTF-8" --cs "EncodingForB=UTF-8" --cs "EncodingForC=UTF-8" --cs "EncodingForOutput=UTF-8" --L1 "%ancestor_label" --L2 "%file1_label" --L3 "%file2_label" "%ancestor" "%file1" "%file2" -o "%outfile"
    

Trzeba jeszcze uwzględnić gdzie rzeczywiście mamy zainstalowanego kdiff’a. Gdy jest on dodany do path’a to możemy po prostu kdiff3 w powyższych miejscach wpisać. Jak nie, to trzeba jedynie pamiętać, aby podwójnych backslash’ów użyć. Dodatkowo skorzystałem z flagi -cs EncodingForA=UTF-8, aby z kodowaniem nic mi się nie powaliło.

Jeśli nic nie popsuliśmy to po zrestartowaniu klienta Synergy, możemy się cieszyć kdiff’em przy porównywaniu i merge'owaniu zmian. Co prawda nie robią się one automatycznie jak w przypadku integracji z SVN’em lub GIT’em (nie wiem dlaczego), ale i tak mi lepiej odpowiada to narzędzie, niż standardowe załączone w kliencie Synergy.

Jak się nie podoba, to zawsze można wrócić do starego, standardowego narzędzia dostarczonego razem z Synergy.

czwartek, 14 czerwca 2012

Ekologia kosztuje


Poniżej zdjęcie zjawiska jakie ostatnio zaobserwowałem na poczcie.


Może nie najlepiej to widać, ale mamy tutaj po lewej stronie ekologiczne koperty na listy, wyprodukowane z papieru z odzysku, 25 sztuk. Papier szary miękki i brzydki. Kosztują one 1,29 Euro. Po prawej mamy również 25 kopert, z białego papieru, eleganckie, miłe w dotyku. Kosztują niecałe 1 Euro.

No i niech mi ktoś wytłumaczy, dlaczego koperty produkowane z odzysku są droższe od tych normalnych, wystruganych ze świeżych drzew? Czy przetwórstwo starego papieru jest droższe od wyprodukowania nowego papieru? A może chodzi o modę na wszystko co jest ekologiczne i Bio? A może zamówień na papier z odzysku jest tyle, że trzeba go dodatkowo ze świeżego surowca wytwarzać?

Zdrowy rozsądek podpowiada, że papier z odzysku powinien być tańszy, więc tym bardziej nie mogę się nadziwić o co chodzi.

poniedziałek, 4 czerwca 2012

Code Retreat w Berlinie

W Niedzielę 3ciego czerwca wziąłem udział w warsztatach Code Retreat w Berlinie. Był to mój nie pierwszy udział w tego typu „imprezie”, ale pierwszy raz było to za granicą i w otwartej formie jednoczenie (wcześniej zorganizowaliśmy sobie CR w pracy). Co mnie bardzo zaskoczyło to wielka różnorodność kulturowa. Spodziewałem się, że event będzie prowadzony w języku niemieckim, ale jak się okazało w Berlinie mieszka sporo ludzi, którzy nie mówią w tym języku. Z drugiej strony, jak się okazało, łatwiej jest mówić o typowo technicznych sprawach w języku angielskim.

Pierwszą sesję kodowałem z Carlosem z Portugali. Przykładowo on mimo prawie rocznego już tutaj pobytu nie używał Niemieckiego, a w pracy oficjalnym językiem jest angielski, ze względu na sporą różnorodność kulturowa. Kodowaliśmy w Rubym, tzn. miałem okazję zobaczyć jak to można robić i poznać podstawy podstaw, ale ogółem nic konkretnego. Generalnie w Portugalii jest podobna sytuacja jak w Polsce, tzn. projekty są, praca jest, ale lepiej być gdzieś indziej.

Druga sesję miałem okazję po kodować z Grzegorzem Dziemidowiczem. W końcu była możliwość się poznania i sprawdzenia się przy klawiaturze. Była to moja najbardziej produktywna sesja podczas tego dnia jak i chyba podczas wszystkich Code Retreat’ów w jakich brałem udział. Obaj dobrze się poruszaliśmy po IntelliJ IDEA, była super komunikacja, zbliżone pomysły na design (czyli nie wiele konfliktów) i szybka ewolucja designu (ekstrakcja osobnych klas dla żywych i umarłych komórek, przeniesienie do nowych klas odpowiednich implementacji).

Udało mi się sprzedać fajnego hotkey’a do Idei. Mianowicie zamiast pisać assercję, można napisać warunek, jaki chcemy sprawdzić (tak jak by to był zwykły if), zaznaczyć tekst, wcisnąć Alt + Enter i wybrać opcję „Create JUnit Assertion”, aby zamienić porównanie w wywołanie odpowiedniej metody. Screen poniżej.


Podczas kolejnej sesji (tym razem z Łukaszem Balamutem) jak drugi raz pokazywałem ten skrót, to odkryliśmy, że nie zawsze on działa. Teraz jak to sprawdzałem, to doszedłem do tego, że jak zaznaczymy tekst od lewej do prawej, to popup pokazuje się bez tej (i innych opcji). Na szczęście ktoś już zgłosił ten błąd: IDEA-86707.

Z Łukaszem ćwiczyliśmy pisanie w Javie, przy czym na napisanie testu mieliśmy tylko dwie minuty. Jak stoper dochodził do końca, a my nie zdążyliśmy skończyć testu, to trzeba było usunąć kod i zacząć od nowa. Później analogicznie robiliśmy z implementacją. Ćwiczenie to miało na celu tworzenie małych prostych testów i prostej implementacji. Mi się kilka razy nie udało skończyć testu, gdyż nie była to moja klawiatura i bardzo ciężko mi się tworzyło test „na szybko”. Dla mnie pisanie testu, to czas w którym intensywnie myślę, co chcę testować, jak, jaką nazwę dobrać i czy test jest poprawny. Dwie minuty to troszkę za mało, nawet jak test jest niewielki.

Później trochę się posprzeczaliśmy na temat używania słówka should na początku nazwy każdej metody testowej. Łukasz twierdzi, że kiedyś było test (bo musiało być), a teraz ten „noise” zamieniliśmy na should i jak czytamy nazwy niedziałających testów, to i tak pomijamy ten prefiks.

Później wyskoczyliśmy całą grupą na obiad. Poszliśmy na jakieś burgery w pobliskim bistro. Panie z za lady bardzo się zaskoczyły nagłym zmasowanym atakiem żądnych mięsa programistów w Niedzielę, gdyż wcześniej nikogo w tym barze nie było. Co prawda nie była to pizza, ale taki lepszy fast food, smaczny i sponsorowany przez Nokię. Była w tym czasie możliwość pogadania z innymi uczestnikami.

Po obiedzie miałem jeszcze okazję pokodować z Janem. Tym razem rozmawialiśmy po Niemiecku.


Ostanie dwie sesje były bardzo szalone. Postanowiliśmy zrobić coś, z czym spotkałem się pierwszy raz. Mianowicie 6 par postanowiło zacząć kodować w Javie i wykonywać rotację jednej osoby co 10 minut. Do tego nie skasowaliśmy kodu pomiędzy sesjami. Bardzo smutne było, gdy trafiałem co chwila na tą samą trefną implementację jednego z uczestników, jednak ciężko było mi przeforsować jemu inny sposób spojrzenia na problem i odpuściłem. Ciężko, zwłaszcza podczas drugiej sesji, przebiegało wdrożenie w to, co się dzieje w projekcie, gdyż przez 10 minut ktoś musiał wytłumaczyć / pokazać w którym miejscu jesteśmy, jak to implementujemy i coś dopisać. W momencie gdy udało się już dopchać do klawiatury, to przychodziła już nowa osoba na sąsiednie stanowisko i role się odwracały.

O dziwo prowadzący stwierdził, że pierwszy raz widział, że ludzie podczas ostatniej sesji są tak mocno ożywieni. I rzeczywiście tak było. Te częste rotacje powodowały, ze trzeba było dawać z siebie wszystko, a stres z tym związany na pewno powodował wydzielanie się motywująco – pobudzających substancji w naszym ciele.

Na koniec oczywiście retrospekcja z całego dnia, podziękowania, wymiana kontaktami i wypad na piwko. Tam to dopiero całość spływa z człowieka i można jeszcze pogadać w luźniejszej atmosferze. No i jeszcze było sporo dzielenia się wrażeniami z Marcinem Saneckim i Rafałem w drodze powrotnej.

Podziękowania dla sponsorów @nokia@crealytics, @klosebrothers. Miejsce odbywania się imprezy było ciekawe, gdyż znajdowało się w niezbyt uroczej dzielnicy, a blok wyglądał jak była fabryka. Za to firma crealytics udostępniła małe przytulne biuro i Club Mate, które trzymało mnie cały dzień na nogach. Powinni wprowadzić ten napój w pracy obok / zamiast kawy. Ogółem organizacja była bardzo dobra, dojście oznaczone, a na ścianach wisiały ciągle reguły gry.


Podsumowując, poznałem ciekawą technikę wymiany rotacyjnej uczestników co 10 minut, z którą nie spotkałem się wcześniej. Podpatrzyłem kilka innych konwencji nazywania metod testowych i zorientowałem się jak wygląda praca w Berlinie (miasto start-up’ów), gdzie dominującym językiem jest angielski.

sobota, 2 czerwca 2012

Różnice międzykulturowe, czyli zaskakujące fakty z życia w Niemczech

Już kiedyś pisałem (we wpisie: Hamburg wrażenia po miesięcznym pobycie) na temat tego jak to wygląda świat u naszych zachodnich sąsiadów. Dzisiaj czas na kolejną część życiowych ciekawostek i różnic międzykulturowych.

W Hamburgu mówią na lotnisko airport, zamiast niemieckiego Flughafen, jak to jest w większości lotnisk w Niemczech. Hamburg stara się być bardzo światowy przez to. Ponadto lotnisko to znajduje się w centrum miasta, przez co jego godziny działania są ograniczone. Nic tam nie ląduje (chyba że awaryjnie) w nocy, aby dać się wyspać okolicznym mieszkańcom. Dało się to odczuć, gdy się przylatywało późnym lotem do Hamburga, a lotnisko było niemal opustoszałe. Panująca pogoda w Hamburgu (albo pada, albo jest mgliście) jednak nie zachęca do tego, aby tam mieszkać na stałe, choć miasto samo w sobie jest piękne.

Wynajem mieszkań
Bardzo odmiennie wygląda sprawa wynajmu mieszkań w Niemczech. Bardzo ciężko jest tutaj znaleźć umeblowane mieszkanie. W Niemczech jak chce się wynająć mieszkanie, to jest to zazwyczaj jest ono w stanie surowym. Jak piszą w ogłoszeniu że jest odnowione, to znaczy że ściany są zagruntowane, pod stopami sterczy beton, a meble to trzeba sobie samemu skombinować.

Nie do końca rozumiem skąd wynika taka filozofia, ale chyba z przeświadczenia, że nowy najemca na pewno będzie chciał mieć inną podłogę niż obecny, więc na wszelki wypadek wyrzućmy ją zawczasu na śmietnik. Podobnie z meblami, kuchnią, lodówkami i innymi starymi gratami, tylko te zazwyczaj lądują na ulicznych wystawkach. I teraz właśnie rozumiem skąd ich tu tyle. I rozumiem biznes naszych, którzy jeździli kiedyś masowo do Niemiec, aby coś ciekawego znaleźć, zwieść do Polski i popchać dalej. Z drugiej strony takie podejście nakręca gospodarkę. W Polsce podczas przeprowadzki wiezie się zazwyczaj wszystkie graty ze sobą, a tutaj wyrzuca i kupuje nowe.

W mieszkaniach często nie ma pralek, ale za to zazwyczaj są gdzieś w piwnicach, tzn. w pralniach. W Polsce piwniczne pralnie / suszarnie zazwyczaj się przerabiało na jakiś składzik, rowerownię, siłownię, lub po prostu miejscówkę do spędzania czasu i picia piwa. Jako że porządek w Niemczech musi być, to korzystanie z pralki w pralni jest odpłatne. Mianowicie jak już w poprzednim wpisie wspominałem, że należy wrzucić zazwyczaj kilka 50 centówek. No tak tylko co jak się ich nie ma? Można rozmienić w sklepie. Proceder chyba na tyle popularny, że niektóre stacje benzynowe mają specjalne maszyny do rozmieniania pieniędzy. I to lepsze niż w autobusach, gdzie kierowca musi wrzucić monety do odpowiednich przegródek. Tu po prostu ładuje się do maszyny monetę, coś tam klika i wylatują pieniążki w żądanym nominale. Maszynka może chyba również działać w druga stronę, czyli zliczać klepaki. Mnie zaczęło zastanawiać, czy to po prostu wygoda, ograniczenie błędów w liczeniu przez człowieka, czy też ogłupianie społeczeństwa, które nie umie już pieniędzy rozmienić?

Wspominałem już kiedyś, że nie wszędzie karty płatnicze są akceptowane. Jeśli nie jest to karta EC to można się nieźle zdziwić przy kasie. Nawet w dużych sklepach często jest z tym problem. Raz gdy stałem w kolejce w sklepie i byłem przyczyna małego zamieszania związanego z niemożliwością obsłużenia mojej karty, to gościu w kolejce co stał za mną, zaczął tłumaczyć, że jak karta nie jest EC to sklep większą prowizję płaci i przez to mało który sklep chce je akceptować. Dobrze że Visa i MasterCard działają jeszcze w bankomatach.

A propo bankomatów. Zauważyłem tutaj, że niektóre bankomaty są na tyle fajne, że jak chcę wypłacić 100 E to mi wypluwają banknoty: 50E 20E 10E 10E 5E i 5E. Dzięki czemu w poniedziałek rano w piekarni wszyscy nie chcą płacić stówkami, a biedna pani z za lady nie wyrywa sobie włosów z głowy, bo nie ma z czego wydać. Bardzo fajne rozwiązanie, w końcu ktoś pomyślał.

Innym kolejnym ciekawym zjawiskiem jest brak numerów mieszkań w blokach. Gdy podajemy komuś nasz adres, to ważna jest ulica i numer bloku, a numer konkretnego mieszkania jest już zależny od nazwiska odbiorcy. Jak nazwiska nigdzie nie ma to lipa - przesyłki nie będzie. W Polsce ustawa o ochronie danych osobowych na to nie pozwala i korzysta się z numerów mieszkań. Nawet już na domofonach w Polsce nie można pisać nazwisk. A tutaj są wszędzie: na domofonie, skrzynkach pocztowych, przy dzwonku do drzwi. Dla tego lepiej zadbać o to aby nasz nazwisko było w tych wszystkich miejscach.

Ludzie ogółem są tutaj w ogólności milsi jak w Polsce. Chętnie i częściej mówi się tutaj dzień dobry, nawet jak się mieszka w wieżowcu. W Polskim blokowisku jest się bardziej anonimowym, chyba że zaszliśmy sąsiadom za skórę. Inaczej też wygląda tutaj pozdrawianie się tutaj przy niektórych aktywnościach. W Polsce jak się biega po parku, jedzie rowerem / motorem / tramwajem, to się macha, gdy mijamy osobę robiącą to samo. Tutaj tego nie robi.

W Niemczech łatwo wpaść w konflikt z sąsiadami. Czasem wystarczy, że jest trochę za głośno, a ściany są cienkie. Wtedy parę donosów i będą podjęte próby usunięcia szkodnika. Inaczej sprawa wygląda jak się ma małe dziecko. Wówczas to nic nie można takiej rodzinie zrobić i szybciej wredny sąsiad przestanie z nami rozmawiać i się w końcu wyprowadzi gdzieś gdzie będzie miał więcej ciszy i spokoju. Jest to typowe dla Niemców.

Z drugiej strony jak kiedyś pilarką przycinałem panele na korytarzu to przyszedł do mnie sąsiad i zaczął coś tam nawijać. Myślałem właśnie że zakłócam jego dzień wolny od pracy. Okazało się, że chce on mi pomóc i pożyczyć jakieś narzędzia, jakbym potrzebował. Bardzo pomocna postawa, pochwalam. Nie skorzystałem, gdyż akurat miałem to, co mi było potrzebne.

Ciekawą jeszcze sprawą jest cisza nocna. O ile w Polsce jest to od 22 do 6 rano, to w Niemczech dodatkowo dorzucono ciszę w godzinach 13.00-15.00. Pytałem dlaczego, to usłyszałem, ze jest to po to, aby starsi ludzie mogli sobie przyciąć komara. Dodatkowo również przez całą Niedzielę i święta ma być cisza. Obowiązuje ona również chorych a także osób, które muszą pracować w trybie wielozmianowym. Fajny jest jeszcze zapisek, proszący o niekąpanie się między 22.00 a 6.00 ze względu na sąsiadów. Dobrze że inne potrzeby fizjologiczne można jeszcze w tym czasie załatwiać ;)

Inaczej się tutaj jeszcze obchodzi niektóre święta. O dniu kobiet nikt nie pamięta, a dzień matki jest w inny dzień niż u nas. Ciekawy za to jest dzień ojca (a raczej mężczyzny). Podczas tego święta (wypada on w dzień wniebowstąpienia) faceci najczęściej organizują sobie Bollerwagen, czyli wózek na kołkach, do którego ładują alkohol i spacerują po mieście dobrze się bawiąc. Niektórzy dodatkowo usprawniają całość dodając elektryczny napęd (co by się łatwiej ciągło / pchało) i/lub głośną muzykę. Przykład poniżej.



Niektórzy jeszcze organizują sobie takie same koszulki (na zdjęciu są one niebieskie z napisem Schnaps - wódka), dzięki czemu wiadomo kto może korzystać z dobrodziejstwa jakie daje wózek. Nad całością zabawy czuwa policja, która jest w ten dzień bardziej widoczna na ulicach niż zwykle. Interweniuje ona jednak dopiero gdy rzeczywiście trzeba.

poniedziałek, 28 maja 2012

Wrażenia po prowadzeniu mini praktyk niestudenckich


Ostatnio, w czasie gdy większość z Was oddawała się GeeCON'owemu szaleństwu, lub spędzała kolejny nudny dzień w pracy tworząc super tajne projekty, ja miałem okazję podszlifować i wypróbować moje zdolności mentorskie (o ile takie w ogóle posiadam). Od zawsze lubiłem dzielić się swoją wiedzą z innymi. W przypadku programowania, to już na pierwszym roku studiów udzielałem korepetycji koleżankom z liceum, w zamian za ciepły obiadek :) Później zaangażowałem się w Warsztaty programowania urządzeń mobilnych przy Studenckim Kole Naukowym Informatyki Systemów Autonomicznych i Adaptacyjnych. Później zacząłem pisać tego bloga i coś tam od czasu do czasu ludziom przedstawiać w ramach JUG-ów. A teraz prowadzenie praktyki było czymś nowym dla mnie.

W minionym tygodniu dostałem od Marcin Saneckiego pod opiekę praktykanta Adriana. Uczęszcza On do technikum informatycznego i nastał taki moment, że musiał odbyć / odbębnić praktykę w zawodzie. Inni jego rówieśnicy, albo przeinstalowują systemy operacyjne w swoim liceum, albo idą do jakiegoś sklepu komputerowego składać blaszaki. Ostatecznie, jak nie mogą nigdzie znaleźć firmy, która przyjmie ich na praktykę, to idą do jakiś urzędów państwowych, gdzie można się tylko zniechęcić i uwstecznić.

Jako że Adrian nie do końca jest przekonany, co chce w życiu robić, miałem utrudnione zadanie. Miałem go zachęcić (a jeszcze lepiej przekonać go), aby szedł w stronę IT, a najlepiej programowania. Czy musiałem mu pokazać coś ciekawego, gdzie szybko widać fajny efekt pracy i co daje przyjemność samo w sobie. No i do tego miałem niewiele czasu (właściwie wyszły 2 dni po około 5 godzin). Mój praktykant miał podstawy Pascala (tzn. gdzieś tam w technikum się go kiedyś uczył) i trochę widział Html'a i Java Script'a. Ja słysząc tą ostatnią informację, trochę się przeraziłem, gdyż ja sam byłbym mocno zniechęcony do dalszej nauki po pobieżnym poznaniu JS.

Miałem więc bardzo trudny orzech do zgryzienia, gdyż młody adept sztuki programistycznej miał niewielkie doświadczenie, a musiałem w krótkim czasie coś go nauczyć i pokazać, że programowanie może być fajne i dawać satysfakcje. Zacząłem więc sobie przypominać, jak to było kiedyś ze mną, co mi dawało motywację, było łatwe, a efekt końcowy był szybko widoczny.

Mój wybór padł na Javę Micro Edition i postanowiłem stworzyć razem z Adrianem coś co by przypominało grę tank 1990. Odgrzebałem więc swoją starą prezentację na temat Tworzenia graficznego inferface’u użytkownika niskiego poziomu w J2ME, gdzie właśnie przedstawiałem jak operować prostymi obiektami dwuwymiarowymi. Prezentacja co prawda z 2009 roku, przygotowana na potrzeby wspominanych wcześniej warsztatów z J2ME, ale teraz po latach się przydała w celach szkoleniowych. Odgrzebałem też kod (jest on również przypięty do tamtej prezentacji) i pousuwałem z niego bardziej zaawansowane wynalazki, zostawiając namalowany jeden czołg i resztę szkieletu całej aplikacji. Był to nasz punkt wyjścia. Pozostałe prezentacje moje i kolegów z tego okresu można również znaleźć na slideshare.net.

Na początku wspólnej praktyki z Adrianem (i częściowo z Marcinem) przygotowaliśmy niezbędne środowisko programistyczne, czyli JDK7 (32 bit), NetBeans i dodatkowo WTK od Sony Ericsson'a (jakby standardowy emulator z nowym WIndowsem 7 nie chciał działać). Zeszło nam na to trochę czasu, ale końcem końców udało i można było zacząć zabawę.

Zaczęliśmy od jednego namalowanego czołgu. Nie tłumaczyłem w ogóle czym jest obiekt, a czym klasa a jedynie uczyłem przez analogię: „Aby przesunąć czołg trzeba wywołać na nim metodę move()...”, „tu masz wczytywanie obrazka, teraz wczytaj inny...” itd. Adrian często kopiował kod i zmieniał niewielkie fragmenty, rozszerzając w ten sposób funkcjonalność. Odwoływałem się również do języków, które on znał. Było o tablicach, praktycznym zastosowaniu pętli for i warunku if. Całość dopełniona slajdami i moją cierpliwością do tłumaczenia i poprawiania błędów składniowych. Ostatecznie dotarliśmy na koniec drugiego dnia do jeżdżącego czołgu po ładnej mapie z wykrywaniem kolizji z przeszkodami i niewyjeżdżaniem po za ekran.

Chciałem jeszcze zrobić strzelanie do cegieł, ale teraz wiem, że to trochę bardziej skomplikowana historia i mogła by on zniechęcić do dalszej nauki. Zresztą widziałem, że Adrian był już wymęczony tym kodowaniem.

Pewnie się zastanawiacie, czemu nie skorzystałem z Androida (pytał o to Jacek Laskowski na Twitterze)? Otóż żaden z nas nie posiadał telefonu z tym systemem, musiałbym wcześniej przygotować szkielet startowy (decyzja, że dzisiaj zaczynamy kodowanie wyszła bardzo spontanicznie), emulator androida dłużej startuje i miałem akurat prezentację na temat J2ME pod ręka. Technologia ta (Android w sumie też) daje nam szybką pętlę zwrotną, czyli wprowadzamy małą zmianę uruchamiamy emulator i oglądamy efekt. Dzięki temu praktykant może widzieć postęp swoich prac i kojarzyć, że napisanie pewnych linijek kodu, powoduje jakąś zmianę. Również efekt końcowy jest fajny, gdyż można wrzucić na telefon i pokazać kolegom w szkole. No i nie jest to nudna kolejna strona w HTMLu.

Całe wydarzenie uważam za udane. Czy Adrian się przekonał do kodowania? Nie wiem (ciągle czekam na feedback). Na pewno poczuł jak wygląda praca programisty i że można się przy niej zmęczyć, np. szukając babola w kodzie.

Dla zainteresowanych powtórzeniem ćwiczenia udostępniam kod na githubie. Proponuję zaczynać od rewizji 1d6ca27cc7be0507f4a9eda86e48957d1717c8d3, czyli mniej więcej od kodu z którego razem z Adrianem wychodziłem. Jest tam prezentacja przedstawiająca podstawy, jak i wyjaśniająca, co należy robić. Wrzuciłem również prezentację na slideshare.net, ale tam po kompresji prezentacja już nie wygląda tak jak powinna. Za jakiś czas udostępnię rozwiązanie w postaci kodu, jak i filmu z mojego kodowania. Materiał już nagrany, czeka tylko na post produkcję. A Was zachęcam do spróbowania swoich sił w J2ME i do zadawania pytań. Chętnie odpowiem.

sobota, 5 maja 2012

Przyszłość języków programowania, czyli kiedy i kto wygra nadchodzącą rewolucję?

Kiedyś na blogu Touching the Void przeczytałem ciekawego posta: 30 lat z życia programisty. Zaciekawił mnie ten artykuł i od jakiegoś czasu bacznie obserwuję sytuację, wypatrując następcę programowania obiektowego.

Ogółem z artykułu wynika, że co 8-10 lat jest jakaś globalna rewolucja w świecie programowania, co sprawia, że wszyscy się masowo przerzucają na dany język (czy tez bardziej ogólniej: na inny paradygmat programowania). Java już swoje przeżyła / dożywa...

Jaki język zastąpi Javę?

Ogółem świat dąży do tego, aby stworzyć taki język, że specyfikacja klienta będzie wykonywalnym programem. Niektórzy twierdzą, że wtedy programiści nie będą już potrzebni, ale pewnie nawet jak jakiś tego typu język powstanie, to i tak trzeba będzie zapisać tą specyfikację w odpowiedni sposób (czyli przez programistę). Przejawy dążenia w tym kierunku widzę w Spring Roo i w coraz popularniejszych DSL’ach (np. w Scali). Jednak raczej się nie zapowiada, aby taki kompletny język specyfikacji w najbliższym czasie powstał. Pewnie tęgie głowy na nie jednej wyższej uczelni próbują coś takiego stworzyć (albo chociaż opracować podstawy teoretyczne), ale chyba póki co chyba bez większych sukcesów – przynajmniej ja nie znam.

Wracając jednak do świata komercyjnego, to Java króluje na scenie już ponad 10 lat. Obecnie do głosu powoli dochodzą (wg. mnie i w/w. wpisu) języki funkcyjne. Wystarczy spojrzeć na to ile się o nich mówi na konferencjach. Wydaje się, że niedługo nastąpi ich czas. A może zaskoczy nas coś całkowicie innego? Może coś z kreowane przez konkurencję JVM’a? Może jakiś inny pragdygmat? Może w końcu powstaną komputery kwantowe?

Chcąc analizować popularność języków programowania warto się przyjrzeć statystykom prezentowanym na portalu tiobe.com. Ranking jest ogółem wyliczany na podstawie statystyk wyszukiwania na popularnych stronach takich jak Google, Blogger, Wikipedia, jak i na YouTube i Amazonie. Ważna jeszcze jest wartość „page hits”.

Źródło: tiobe.com, dostęp: 04.05.2012


Pierwszym zaskoczeniem jest język C, który cały czas się trzyma wysoko, a teraz nawet przegonił Javę. Podobno niektóre uczelnie wyższe powoli przestają go uczyć, ale ranking ten wskazuje, że to chyba błąd.

Kolejną ciekawostką jest bardzo szybka rosnąca popularność Objectiv-C. Jednakże język ten jest skierowany do specyficznej grupy odbiorców i nie zapowiada się, aby wyszedł po za nią.

Ciekawy jest też wykres dla Rubiego. Generalnie Wujek Bob mówił, że jakiś czas temu w Stanach było najłatwiej znaleźć pracę programistom rubina, jednakże teraz ta sytuacja się już zmienia i raczej odchodzi się od tego języka. Potwierdza to wykres jego popularności.

Tak można by było jeszcze analizować i analizować, ale zostawiam to Wam do własnej oceny i interpretacji. Wróćmy do głównego wątku, czyli co z tymi językami funkcyjnymi?

Patrząc na tabelki i wykresy można dostrzec, że jeśli chodzi o programowanie funkcyjne, to najwyżej stoi Python (8. miejsce), Perl (10.) i Lisp (15.). Nie są to języki, które są tylko funkcyjne, ale posiadają również cechy innych paradygmatów programowania. Dalej w zestawieniu jest jeszcze kilka języków z paradygmatem funkcyjnym. Natomiast Scala, która jest mocno promowana na konferencjach javowych, jest dopiero 45, a Clojure znalazł się po za pierwszą 50dziesiątką. Fakt faktem Tiobe może niekoniecznie jest najlepszym wskaźnikiem do porównywania popularności języków, ale nie znam innego podobnego zestawienia, pokazującego zmianę w czasie.

Mnie zastanawia dlaczego jeszcze nie pojawił się / jaki będzie język obecnej dekady, na który by się masowo przesiadało większość firm, tworząc oprogramowanie w tym języku, zamiast w Javie. Przyszło mi do głowy kilka przyczyn.

Według mnie największym mankamentem nowych języków programowania, jest brak narzędzi. Brakuje dobrych, rozwiniętych i stabilnych środowisk IDE. W Javie mamy IntelliJ Idea, gdzie automatyczny refaktoring jest bezbolesny, narzędzie podpowiada składnie zależnie od kontekstu i wie co chcemy napisać. Eclipse jest trochę słabszym narzędziem, ale znam takich co są z niego zadowoleni. Obecne dostępne IDE tak nas rozpieściły swoimi możliwościami, że aż nie chcemy siadać do jakiegoś języka, gdzie nie ma porządnego wsparcia ze strony środowiska programistycznego. Dla tego ja osobiście mocno kibicuję Kotlin’owi, który powstaje od razu ze wspierającym go IDE - aby mu się udało.

Inną bolączką nowych języków, jest brak (lub niewielka wciąż ilość) informacji, o dużych projektach, które się udały w nowopowstałych językach. Dla przykładu Twitter z Ruby’iego przenosi swoje główne elementy na JVM’a (Więcej na ten temat we wpisie: 33 degree 2012 dzień 1). To na pewno nie przystworzyło to Rubiemu popularności, co widać na wykresie.

Innym tematem, który sam doswiadczyłem na przykładzie Scali, jest ewolucja składni w przypadku nowych języków. Niby było zapowiadane, że Scala do kiedyś tam może być niekompatybilna wstecz, ale się odechciewa, gdy uruchamiając przykłady z tutoriala / książki na nowszej wersji, starsza składnia nie jest akceptowana.

Kolejną sprawą jest to, co się obecnie uczy młodych adeptów sztuki programowania na studiach informatycznych i pokrewnych. Cały czas wiodące języki, od których się zaczyna, to C/C++ i Java. Co do języków funkcyjnych, to kojarzę że na jakimś kursie w połowie studiów był Lisp, ale do tego czasu większość już się nauczyła nie chodzić na zajęcia, a i tak mimo tego zaliczać. Zresztą jaką tu mieć motywację do nauki czegoś, gdzie nie bardzo się widzi, aby którykolwiek pracodawca wymagał tego wynalazku przy rekrutacji?

Teraz każda firma / instytucja / przedsiębiorstwo, chce mieć jakieś oprogramowanie. Najlepiej szybko dostarczone, aby móc wyprzedzić konkurencję i aby zastąpić człowieka tam gdzie się da. Powoduje to, że projektów jest coraz więcej, a na to potrzeba więcej ludzi. Kiedyś (podobno – słyszałem z opowieści starszych), na studia informatyczne było o wiele ciężej się dostać, ale przez to trafiali na nie tylko zapaleńcy. Obecnie dalej nie jest łatwo, ale miejsc jest trochę więcej i mamy alternatywę po za uczelniami państwowymi. Potrzbujemy więcej zasobów ludzkich, ale jak fajnie zuaważyl Michał Bartyzel (autor bloga od którego rozpocząłem ten wpis) w poście: Craftsmanship nie dla wszystkich?, nie potrzebujemy w projektach samych wymiataczy. Wystarczy kilku rzemieslników, a reszta to moga być przeciętniaki, którzy robią od 8 do 16 i są niereformowalni.

Tak więc mamy grupę ludzi, która chce podążać za zmianami, być na bieżąco i nie skończyć jako dinozaury. Mamy też przeciętniaków którzy będą niechętni na całkowitą zmianę języka, lub jego wprowadzenie do projektu obok Javy. Musieli by oni wówczas poznać nowa składnię, przez co poczucie ich bezpieczeńswa / pewności zostałoby zaburzone. Niby nauka nowego języka nie powinna być dla nas problemem (w końcu podczas studiow się pisało w różnych dziwnych rzeczach), ale niektórzy mają ku temu spore opory w swojej pracy.

Co do samej ilości programistów, to problem z wyszkoleniem (wyprodukowaniem) odpowiedniej ich liczby, dobrze widać na zachodzie. Przykładowo w Niemczech, powstały już takie Hochfachschule (nazwałbym to wyższą zawodówką), które szkolą osoby pod konkretne technologie. Tzn. trwają one krócej niż normalne studia, a nacisk kładą na praktykę, ograniczając teorię do minimum. Bo i po co to komu? Na studiach to jest potrzebne, bo liczy się na to, że jednak ktoś z grona studentów pójdzie w stronę doktoratu, zostanie na uczelni i będzie przekazywał zdobytej wiedzy kolejnym pokoleniom studentów, a także rozwijał dalej teorię. Wspomniani absolwenci wyższych zawodówek idą do pracy, robią co do nich należy i jakiejś szczególnej wagi do dalszego rozwoju nie przykładają.

Wydaje mi się, że przez to robi się okopy w projektach, aby na wszelki wypadek się zabezpieczyć przed niedoświadczonymi świeżakami (lub przeciętniakami), którzy potencjalnie mogą używać powierzonych im narzędzi w niewłaściwy sposób. Moim ulubionym przykładem, jest dopisywanie w Javie, podczas zachowywania modyfikowanego pliku, słowa final, w prawie wszystkich możliwych miejscach (to jest do pól klasy, argumentów metod i zmiennych lokalnych). Kiedyś może to i miało sens, jak chcieliśmy trochę na wydajności zyskać, ale obecnie zaciemnia to kod i słowo final traci przez to swoje znaczenie. Oczywiście jest to sensowne, aby przy deklaracji pól klasy używać final, jeśli tylko raz przypisujemy im wartość, ale w pozostałych przypadkach nie ma to sensu. Po prostu próbujemy się zabezpieczyć przed tego typu kodem:

public static void main(String[] args) {
    int x = 5;
    System.out.println(x);
    half(x);
    System.out.println(x);
}

private static void half(int x) {
    x = x / 2;
}

Czyli ktoś chciał zmienić wartość x, zapomniał jednak jak działa przekazywanie prymitywów do metod.

Innym przykładem który lubię, jest konkatenacja Stringów za pomocą plusa. Kiedyś twierdzono, że to zło, gdyż były tworzone spore ilości chwilowych obiektów, aby zbudować jakiś dłuższy tekst. Zastępowano więc plusa takimi łańcuszkami ze StringBuilder'em. Obecnie kompilator robi to za nas, zamieniając plusa na StringBuilder’a automatycznie, a my zystujemy trochę na czytelności. I nie miał bym nic przeciwko, jeśli po takim uargumentowaniu, reguła ta, została by usunięta z findbugs’a. Jeśli jednak osoba mająca władzę, odnośnie konfiguracji tego typu narzędzi, jest niereformowalna (albo jakaś polityka jej nie pozwala), to trzeba się z tym pogodzić. A to hamuje nasz / projektu rozwój. Sprawia, że nie walczymy o zmiany, tylko z pokorą przyjmujemy na siebie to co kiedyś ktoś wymyślił i wprowadził do projektu.

A gdyby zamiast całych tych śmieszny regół, nauczyć ludzi pisać czysty kod – czy świat nie byłby lepszy? Niestety nie wszystkie firmy / projekty da się do tego przekonać (w myśl zasady nie piszesz to nie wytwarzasz wartości dodanej). Po za tym findbugs i checkstyle to swoiste baty na programistów, za pomocą których można im pokazać, że coś jest z ich kodem nie tak. Czasem pomaga to zmusić kogoś opornego do refaktoringu. Czy nowe języki programowania posiadają tego typu narzędzia? Z pewnością pomogły by im one zaistnieć.

To chyba tyle z mojej strony, jeśli chodzi o zbilżającą się rewolucję w programowaniu. Pewnie jeszcze jakieś interesujące powody by się znalazły, dlaczego ciężko jest się wybić innym językom na tyle, aby aktualny świat programowania obiektowego, wywrócić do góry nogami. Czekam na Wasze komentarze, jakie Wy macie poglądy na ten temat, jak i bacznie wypatruję następcę Javy. Jak będziecie wiedzieć, kto będzie następny, koniecznie dajcie znać!

czwartek, 19 kwietnia 2012

Migracja z EasyMock’a na Mockito

Dostałem wczoraj w projekcie zadanie zmigrowania testów korzystających z EasyMock’a na Mockito. Zadanie to przypadło mi, ponieważ jakiś czas temu udało mi się wprowadzić do projektu Mockito, co uważam za duży sukces, gdyż jak wiadomo inicjowanie zmian w projektach nie jest łatwe.

Poniżej przedstawiam jak mi poszło.

9:00 Zbudowałem projekt, odpaliłem testy i zapisałem ile ich jest.
9:02 Sprawdziłem, że mam tylko 3 testy wykorzystujące EasyMock’a. W tym momencie stwierdziłem, że nie ma co szukać w Google jakiegoś migratora, ściągać, instalować i zastanawiać się, jak go uruchomić. Przy tak nie wielkiej liczbie klas do zmiany szkoda zachodu i lepiej zrobić to prymitywną metodą Search & Replace.
9:16 Skończyłem migrować 1wszą klasę.
9:19 Po przyjrzeniu się klasie zrobiłem jeszcze refaktoring, bo jak nie teraz to kiedy? Później nigdy nie nadejdzie.
9:20 Zacząłem modyfikować następną klasę.
9:27 Zakończyłem migrację i refaktoring. Wziąłem się za ostatnią klasę.
9:34 Ukończyłem modyfikacje dla 3ciej klasy.
9:35 Uruchomiłem wszystkie testy – działa.
9:41 Usunąłem wpisy dotyczące EasyMock’a w pom’ach Mavenowych. Tutaj przydała się funkcjonalność „Szukaj w plikach”, jaką daje Notepad++, abym mógł wyszukać wszystkie wpisy.
9:42 Odpaliłem builda i testy w Eclipse - zakończone sukcesem.
9:43 Odpaliłem builda i testy za pomocą konsoli – również zakończone sukcesem.
9:44 Rozpocząłem proces synchronizacji z repozytorium.
9:46 Zmiany zacomitowane.
9:52 Wystartował build na serwerze CI.
10:00 Build zakończył się jednym fail’ujacym testem. Dziwne, bo lokalnie działało. Jako że nie mam dostępu do konfiguracji Jenkinsa to i tak bym nie zidentyfikował problemu. Podszedłem do problemu pragmatycznie: usunąłem nadmiarowe wywołanie verify() i nieużywanego Mocka w jednym teście.
10:08 Rozpocząłem synchronizację z repozytorium.
10:11 Zmiany zacomitowane.
10:12 Wystartował kolejny build.
10:23 Build zakończony sukcesem, banan na ustach, można iść na herbatę.

Na całe szczęście mój obecny projekt jest jeszcze we wczesnej fazie wytwarzania, więc nie było dużo do roboty. Przy czymś większym, gdzie EasyMock jest namiętnie używany, łatwiej było by napisać jakiś skrypcik robiący brudną robotę za nas. Dodatkowo mój zespół ma niewielką wiedzę odnośnie używania mock’ów (i pisania dobrych testów), więc mam kogo ewangelizować :)

Poniżej jeszcze prezentuję przekształcenia z jakich korzystałem. Nie jest to oczywiście pełen zestaw, ale może on stanowić zajawkę Waszych migracji, albo może pomóc zrozumieć różnice między tymi bibliotekami.

import static org.easymock.EasyMock.createMock;
import static org.mockito.Mockito.mock;
createMock
mock
import static org.easymock.EasyMock.expect;
import static org.mockito.Mockito.when;
expect
when
andReturn
thenReturn
import static org.easymock.EasyMock.verify;
import static org.mockito.Mockito.verify;
Elementy do usunięcia:
import static org.easymock.EasyMock.replay;
replay

Do rozpatrzenia:
Przy wywołaniach verify() trzeba dopisać metodę z argumentami jaka powinna się wywołać. Albo jeszcze lepiej zastanowić się nad sensownością testu, gdyż często verify() jest zbędne. Ponadto anyTimes() zazwyczaj trzeba usunąć.

Na więcej problemów nie natrafiłem, ale zdaję sobie sprawę z tego, że przy większym systemie, gdzie EasyMock jest namiętnie wykorzystywany, może nie być tak łatwo. Przy okazji migracji można od razu wyłapać testy które są niedobrze napisane lub są niepoprawne z punktu widzenia Mockito, np. wywołanie verify() przed testowaną metodą.