The art of learning

I don't remember the last time I wrote something on my blog, nevermined. Tody a bit o simple creativity and art. Please look at the picture below:

What can it be? Please do not try to find some extra words, do not think to much. It is really simple. Ok, look once again and stop reading...... Simple, isn't it!?!? My 3 years old son showed it to me after some supper few weeks ago and asked me what I think it could be. He noticed very quickly that I think too much and explained me that this is................................ a pig. I looked at him and just smiled.
Children help us to be pleased with things we just simple ignore. I try to be openminded and learn as much as possible from the special relationships I have especially with my children.

CodeRetreat w Berlinie

Bardzo sie ciesze, ze kolejny raz moglem wziac udzial w CodeRetreat (CR). Sa to warsztaty integrujace ludzi pracujacych jakkolwiek z kodem. Wedlug mnie dobrym polskim tlumaczeniem "Code Retreat" bedzie: "Rekolekcje dla programistow". CR stwarza mozliwosc do pomedytowania nad kodem, do wymiany refleksji nad jego stanem, do podjecia postanowien, do zmiany myslenia i wreszcie do uczenia sie od siebie nawzajem. Poza hardskillami w naturalny sposob uczysz sie softskilli. Pair programming, zmiana w parach co sesje, retrospekcje, wspolny obiad bez pospiechu - to wszystko sprzyja interakcji.

Tak bylo i tym razem. Dzieki zapalencom (no bo jak nazwac osoby zjezdzajace sie i to w niedziele po to zeby caly dzien razem kodowac) oraz sponsorom: @nokia, @crealytics, @klosebrothers udaly sie kolejne rekolekcje. Bardzo ciekawa relacje mozna przeczytac na blogu Staszka.

Praktyki nie-studenckie w KEEP CODING

Nie obejdzie sie bez wyjasnienia, ze poleglem kolejny raz na metodzie "malej lyzeczki", czy jak kto woli "metodzie malych kroczkow". Regularnosc to cos co caly czas walczy we mnie z tym co nazywam spontanicznoscia choc jest to w duzej czesci mieszanka lenistwa i slabej woli. Post na blogu po miesiecznej przerwie jest tego dobrym przykladem szczegolnie, ze sie dzialo.

Oto przez dwa tygdnie mialem na praktyce ucznia technikum informatycznego, osobe z rodziny po stronie mojej zony, Adriana. Jako, ze ostatnio bywam duzo w Polsce zazachodniej polaczylem oferte praktycznej nauki zawodu z "wycieczka" krajoznawcza co sie dobrze sprawdzilo.

Najbardziej zalezalo mi na odkryciu prawdziwej pasji ucznia czyli tego co tak naprawde lubi robic oraz poszerzeniu jego horyzontu czyli pokazaniu co robic moze. Ostatecznie sie okazalo, ze jak na razie pracy z softem to nie lubi. O wile bardziej woli hardware i to w wersji hard -  szczegoly pomijam. I dobrze, karty zostaly odkryte i latwiej bylo reszte ustawic. 

Czy to co dzsiaj nie jest twoja pasja moze byc nia jutro? Znasz odpowiedz na to pytanie. Czy mozna robic cos bez pasji? - tu tez nie musze podpowiadac. Ostanio jeden ze znajomych opowiadzial mi o nowej osobie w swojej pracy (software) ktora to wybrala kierunek informatyczny studiow ze wzgledow ekonomicznych. Dzis nie ma problemu ze znalezieniem dobrej pracy i nie musi pracowac po pracy co pozwala jej na zajecie sie swoja prawdziwa pasja. Tak tez mozna :)

Kolejna istotna kwestia to swiadomosci, ze jesli koniec swiata nie nadejdzie po Euro 2012, a nawet w 2015 to trzeba bedzie na tym swiecie jakos zyc i cos robic. Ta wlasnie swiadomosc, moze zmotywowac do dzialania dzisiaj, do malych kroczkow lub jak to mowil jeden z moich wykladowcow, malej lyzeczki co jest jednym z wysoce skutecznych sposobow na dojscie do celu. O tak... cel... do niego mozna isc, mozna go miec lub tez nie, itp. Wiec ja jako starszy brat przedstawilem kilka celow, kilka gor, ktore czekaja na zdobycie. Piekna rzecza jest moc dzielic sie swoim doswiadczeniem i pomagac innym zdobywac gory, ktore przed nimi stoja. Dla mnie to byla podroz w przeszlosc, dla Adriana w przyszlosc, odbyla sie co ciekawe w terazniejszosci.

Wszystko przeplatany bylo roznymi zadaniami zwiazanymi z programowaniem od prostych stronek w html i javascripcie po gierki w JavaME. Zaliczylismy tez wyklad na JUGu o CauchDB, kilka wyjsc na bronka i jakis sport. Przy okazji wielkie podziekowania Marcinowi Stachniukowi za kursik JavaME, intro do yarba mate i cala pomoc w indoktrynacji praktykanta.

Juz po wszystkim przeczytalem wpis Jacka Laskowskiego o praktykach studenckich w IBM.

Tu bardzo spodobala mi sie propozycja przyuczenia do blogowania, twittowania, blipowania, itd jako sposobu dzielenia sie wiedza. Przy okazji nastepnych praktyk zastosuje ten pomysl.

Wymowne nazwy metod i kontekst.

Metoda malych kroczkow wprowadzam do kodu, z ktorym na codzien pracuje pewne konwencje. Piszac testy staram sie nazwac metode testowa tak aby w pewien sposob oddala kontekst testu. Jednak na nic te konwencje jesli tylko ja bede ich uzywal. Wiec pokazalem jednemu koledze moj kod z takimi dlugasnymi nazwami metodami (okolo 100 znakow na nazwe) i poprosilem o komentarz. 100 znakow! WTF! No wybacz, sa taki jezyki (nie programowania), ktore potrzebuja duzo miejsca. Podobno jezyk finski przebija wszystkie.

zwracaTrueDlaProcesowZewnetrznychTechnicznieZwalidowanychWersjonowanieRozpoczete

No wiec pokazje koledze pierwsza motode.... a on czytajac ja w polowie dostal stackoverflow. Czyta drugi raz i znowu. Mowi do mnie, ze to nie przejdzie, ze to do dokumentacji, ze jak dla niego 3 wyrazy i basta. Na koniec podkreslil jeszcze dobitnie, ze to za duzo. Sie zdziwilem, ze tak od razu, ze sie nie reebotuje i nie walczy no ale coz. Dla mnie jego zdanie jest wazyne bo przeciez na jednym kodzie pracujemy. Staram sie jednak mu pomoc i go zachecic. Czytam mu nazwe metody i robie przerwy. On to zwuwazyl i mowi mi, ze z tymi przerwami juz kmini ale ich w nazwie nie widzi. No wiec edytuje kod:

zwracaTrue_DlaProcesowZewnetrznych_TechnicznieZwalidowanych_WersjonowanieRozpoczete

Kolega jeszcze sie krzywi, no jest lepiej ale. Pokazuje mu inna, stara nazwe metody testowej:

rodzajSourcinguZmieniony

i pytam czy ta nazwa mu cos mowi. Kolega zaczyna parsowac, glowi sie, patrzy w kod (zaslonilem mu na chwile ;)). No nic, z samej nazwy metody nic nie wyprodukuje, nie wie w ktorym kosciele dzwoni. Odslaniam kod testu. W sumie pogorszylo tylko sprawe :D
No ale nie cisne na sile. Skoro jemu trudno to odczytac i woli w dokumentacji to mu pokazuje dokumentacje klasy i szeroko opisan kontekst. Swieteni, robi sie jasniej. Zmarszczki na czole powoli sie prostuja ( mam nadzieje, ze pod czaszka nastepuje proces odwrotny). W powietrzu czuc porozumienie. No to ide za ciosem. Cialo metody:

// GIVEN
wstepny kontekst, setup, ustawienie stanu systemu
// WHEN
zdarzenie faktycznie testowane (np. wywolenia metody)
//THEN
sprawdzenie wynikow tesotwanej metody, asercja

I tu pozytywna reakcja. Weszlo jak w maslo, sa pochwaly, jest dobrze. Rownoczesnie patrzymy na inne metody testowe napisane dawno temu. Czy ktos myslal kiedys o tym, ze inni beda je czytac szukajac powodu defektu? Czy ty myslisz o tym, piszac kod?

O estymacji

Koncze pisac specyfikacje, a co sie z tym wiaze zblizam sie do aktualizacji wstepnych oszacowan.
Podczas rozmowy z jednym z kolegow z projektu na temat tych wlasnie oszacowan uslyszalem cos czym chcialbym sie podzielic.

"Prognozowanie jest trudne zwlaszcza jesli chodzi o przyszlosc."

"Dlaczego nasz leader prosi nas co piatek o aktualizacje oszacowan?
On gra w totolotka i uwaza, ze jestesmy najlepszym generatorem liczb losowach."

Ha ha ha ha...

Po co to cale szacowanie?

W uproszczeniu szacowanie to okreslanie przyblizonej wartosci jakiejs wielkosci przy posiadaniu niepelnych danych.
Spotykamy sie z nim caly czas. Kiedy zony gotujac obiad dzwoni do meza wracajacego z pracy i pyta: "O ktorej bedziesz w domu?" prosi go o oszacowanie czasu jaki zajmie mu dojaz. Odpowiadz jaka udzieli obarczona jest bledem nawet jesli uda mu sie przybyc na czas.Co z tego, ze maz ma super szybka fure jesli nie wie bidulka, ze dwa skrzyzowania dalej byla stluczka i objazd nie jest mozliwy. Co to spowoduje w konteksie rodzinnego obiadu? To zalezy czy maz zadzwoni do zony i zaktualizuje wczesniej przekazane jej informacje.Moze jednak zalozyc, ze jego super szybka fura nadrobi stracony czas na kolejnym etapie drogi do domu i w zwiazku z tym, zakladajac, ze nic dodatkowo nie zakluci jego jazdy, nie ma sensu dzwonic i zawracac zonie glowy. Brzmi znajomo?

Wracajac do tematu: Po co to szacowania?
Odpowiedz zalezy w duzej mierze od punktu widzenia. Inaczej odpowie na nie malo doswiadczony pracownik, inaczej stary wyjadacz, ignorant, pracus, a jeszcze inaczej ten, ktory pilnuje aby zadania zostaly zrobione dobrze, w budzecie i na czas np. team leader.
No wiec zapytalem kilka osob i takie oto otrzymalem odpowiedzi.

• Malo doswiadczony pracownik: Ktos potrzebuje cos zaplanowac i kaze mi to robic wiec to robie.
• Stary wyjadacz: kierownictwo wciaz liczy, ze cos na tym projekcie zarobi. Podaje im co jakis czas nowe szacunki, a oni obliczaja to swoje cos.
• Ignorant: kaza mi to robie ale i tak zawsze wychodzi inaczej.
• Pracus optymista: naanalizowalem sie, naliczylem i na koncu przestraszylem, obetne troche zeby szef sie nie wkurzal.
• Team leader: zeby moc cokolwiek zaplanowac. Praca Henia zalezy od pracy Piotrka, praca testerow zalezy od pracy programistow, programistow od analitykow itd. no i jeszcze ludzie chce miec jakies wakacje (sic!), a klient pyta wciaz kiedy bedzie mogl uzyc zamowiony produkt.
  

Pytanie "Po co to szacowanie?" nurtowalo mnie czesto w momentach kiedy wiedzialem, ze wymagania lub specyfikacja sa dziurawe. No po co kaza mi to szacowac terazprzeciez za 2,3 dni dojdzie nowe wymaganie, cos sie zmieni w specyfikacji i trzeba bedzie robic to na nowo. To szacowanie to marnowanie czasu. Trzeba jakis czas poczekac, az temat dojrzeje i wtedy.... No wlasnie wtedy, "wtedy" jest tu kluczowym slowem. Zamiast zastanawiac sie kiedy bedzie to odpowiednie "wtedy" przyjmijmy, ze "wtedy" oznacza teraz. I zabierzymy sie do pracy.

Estymacja to zawsze duze wyzwanie, zwlaszcza kiedy dodamy do niej takie czynniki jak:

• nieznajomosc lub slaba znajomosc technik stosowanych do estymacji
• nieznajomosc lub slaba znajomosc domeny problemu
• niedokladnie zdefiniowane wymagania
• zaleznosc pomiedzy czesciami wykonywanymi przez rózne osoby. grupy, programy
  

Zbyt szczególowa analiza wymagan, zaleznosci i ciegle zmiany moge sparalizowac estymacje i moze ona niezostac ostatecznie zrobiona. Z drugiej strony moze sie okazac, ze estymacja byla zbyt pobiezna, optymistyczna co sprawilo, ze pewne sprawy zostaly pominiete.

Jak sobie z tym poradzic? Jak wkoncu szacowac zeby to mialo sens.

Po pierwsze trzeba to ciagle robic i uczyc sie na popelnionych bledach.
Mozna tez pomoc sobie okreslajac jakie szacowanie w danym momencie ma sens.

1. Szacowanie rzedu wielkosci (porównywanie z czyms podobnym) - odchylenie 2 lub 3 krotnosc rzeczywistej wielkosci. Mozna powiedziec, ze szacowanie rzedu wielkosci to zadne szacowanie. W tym przypadku jest to jedyne oszacowanie na którym mozemy sie jakkolwiek opierac. Ma ono znaczaca wartosc dla organizacji oraz zespolu projektowego poniewaz daje pewne wytyczne dla projektu jesli chodzi o czas, ludzi i pieniadze. Lepiej wiedziec, ze cos zajmie 4-6 miesiecy niz nie miec bladego pojecie ile to zajmie.
   
2. Zgrubna estymacja - odchylenie 50-100% rzeczywistej wielkosci Pracujesz z dobrze zrozumianymi wymaganiami, oraz jest ktos dobrze obeznany z domena problemu i problemami technicznymi, które moga sie pojawic.
   
3. Estymacja dokladna: odchylenie 25-50% rzeczywistej wielkosci. Jestes bardzo obeznany z tym co ma byc zrobione i robiles to juz wiele razy wczesniej. Takie podejscie nadaje sie do czynnosci wiele razy powtazanych (np. w utrzymaniu aplikacji) gdzie rozwiazania sa znane lub przy dodawaniu dobrze znanej i rozumianej funkcjonalnosci, która juz wczesniej byla dodawana.
   

W efekcie otrzymamy oszacowanie, ktore obarczone jest jak zawsze bledem. Patrzac bardzo ogolnie blad ten moze nazywac sie:

• przeszacowanie - wtedy moze sie okazac, ze do realizacji zostanie wziety ktos inny (inna firma lub inny pracownik) lub, ze w rezultacie pewne wygania nie zostana spelnione z braku czasu, zasobow. Redukcja wymagan moze wystapic juz na wstepie.
• niedoszacowanie - wymagania zostana zaakceptowane jednak niedostateczna ilosc czy czasu lub zasobów spowoduje brak ich realizacji. Redukcja wymagan nastpuje w pozniejszej fazie projektu, potrzeba przeplanowac prace ludzi, zespolow, termin dostarczenia produktu do klienta jest niedotrzymany.
  

Podsumowujac.
Warto pamietac, ze cale to szacowanie nie sluzy do przewidywania przysylosci ale pomaga dowiedziec sie jakie decyzje nalezy podjac obecnie. Np. obecnie nie trzeba zmieniac planu i podzialu zadan poniewaz ty wciaz twierdzisz, ze sie wyrobisz, a przynajmniej nie sygnalizujesz, ze cos idzie nie tak ;)

Pani Linda Rising powiedziala bardzo ladne zdanie, ktore pasuje do tematu szacowania:

Podejmuj zdecydowane decyzje ale nie trzymaj sie ich kurczowo, dopuszczaj zmiany.

O tym napisze nastepnym razem.

Testy Alibi

Spotkalem sie dzisiaj z nowym rodzajem testow. Tak mi sie on spodobal, ze zechcialem wspomniec o nim na blogu. Chodzi o Testy Alibi. Moja definicja tego pojecia jest nastepujaca:

Testy Alibi - to takie testy, ktorych glownym celem jest istnienie samo w sobie.

Jesli ktos pyta czy do danego kodu napisane sa testy to w przypadku testow alibi mozna odpowiedziec, ze oczywiscie tak. Najlepiej odpowiedziec na tyle stanowczo zeby nie otrzymac kolejnego pytania na ich temat.

S.O.L.I.D i refaktoring

Wszystkim zainteresowanym tematem polecam mocno wg mnie dobre darmowe e-booki traktujace temat SOLIDnego projektowania i refaktoryzacji.

Po co nam te javadocki, komantarze, etc...

Grzebiac w kodzie znalazlem kilka metod opatrzonych takim oto komentarzem:

"Life is too short..."

Autor mial zapewne wazniejsze rzeczy do robienia podczas pisania kodu i niepisania javadoca. Ocenil sytuacje i stwierdzil, ze szkoda jego cennego czasu, jego zycia na takie pierdoly. Po jakims czasie ja trafiam na to miejsce starajac sie zrozumiec jak cos dziala. Co z moim czasem, z moim zyciem? Patrzac z szerszej perspektywy, ktos bedzie musial za to zaplacic i z pewnoscia nie autor, ktory zaoszczedzil swoj czas.
Podumowujac:
Kod wiecej razy czytamy niz piszemy. Dlatego tak wazne jest zeby juz napisany byl czytelny i zrozumialy. Wszystkim piszacym kod polecam ksiazke "Clean Code" by Robert C. Martin (Uncle Bob).

Czy znasz wystarczajaco dobrze narzedzia, ktorych uzywasz?

Jaka jest twoja odpowiedz na to pytanie? Nie badz taki surowy ;) przeciez jestes wazna, nieprzecietna osoba! Jak trzeba bedzie to nauczysz sie wszystkiego w 2 dni.

Zaczne moze od tego, ze glownym powodem mojej sympatii do szeroko pojetego tematu komputerow i nauki o nich jest to, ze komputery moga wykonac szybko pewne zadane przez ludzi zadania. W ten sposob moga nam ulatwic zycie. Ulatwic zycie znaczy w pewnych sytuacjach oszczedzic nasz cenny czas.

Spojrzmy teraz na pewien zespol programistow. Jest ich 6. Codziennie spedzaja w pracy 8-9 godzin. Z tego efektywnie pracuja 4-6. Tu wtrace, ze blokowanie dostepu do pewnych zasobow internetu wcale nie poprawia, a czesto pogarsza ten wynik. Dla uproszczenia przyjme ze kazda osoba pracuje 5 = (6+4)/2 godzin dziennie. Do pracy uzywaja pewnego zbioru narzedzi. Nie znaja jednak wielu zastosowan tych narzedzi. Znaja pewne ich zastosowania i do tego maje wlasne przyzwyczajenia. Co sie stanie jesli pokazesz im jak uzywac narzedzi tak aby zaoszczedzili 10 minut dziennie?

10 min * 6 osob *20 dni pracy na miesiac * 12 miesiecy = 14400 minut
14400 minut / 60 minut / 8 godzin deklarowanej pracy na dzien = 30 dni
14400 minut / 60 minut / 5 efektywnej pracy = 48 dni!

Tak. Kazdy latwo sobie dalej przemnozy ile to pieniedzy (programisci pomnoza przez p, managerowie przez p*m, gdzie m>8). Jaki z tego wniosek?

Doskonalenie rzemiosla do pewnego poziomu oplaca sie.

W kolejnych postach opisze historie programisty Henia, ktoremu udalo sie wprowadzic pewne usprawnienia w projekcie, w ktorym pracuje. Zastanowimy sie tez ile oszczednosci moglo to wprowadzic.

A ile oszczednosci moze to wprowadzic w twojej pracy, niekoniecznie zawodowej?

Jak dziala hibernate'owy cache

Jako, ze w kolejce czekaja zadania z optymalizacji aplikacji. Postanowilem zbadac jak dziala cache w hibernate. Zanim bede czytal kod hibernate (glownie na potrzeby second-level-cache) zapoznalem sie z tekstami innych programistow. Ten artykul uwazam za jeden z ciekawszych:
http://blog.dynatrace.com/2009/02/16/understanding-caching-in-hibernate-part-one-the-session-cache/

Kolejne czesci latwo wskaze uncle Google.

Popatrzec na program okiem uzytkownika

Niessamowite doswiadczenie mialem w piatek. W ramach wdrozenia wyslany zostalem wraz z kolega z projektu na szkolenie dla uzytkownikow systemu, ktory programujemy. Grupa szkoleniowa to osoby z dzialow zakupow +my.
Spotkanie z uzytkownikami softu, ktory klepie to moje zawodowe marzenie. Sugerowalem przelozonemu cos takiego jednak okazalo sie, ze jest inna grupa za to odpowiedzialna i w sumie nikt nigdy czegos takiego nie robil.... musze bardziej nad nim popracowac :)
..wiec stalo sie, jestem na szkoleniu.
Postanowilem nie proznowac i notowalem wszystkie obserwacje uzytkownikow. Pytalem jak klikaja, czego uzywaja, czego nie uzywaja (wow tu bylem mocno zaskoczony), co jest dla nich trudne. Notowalem wszystkie uwagi, na temat kolorow, ukladu, niejasnosci, gdzie sie gubili. Mam materialy na 2-3 misiace pracy. To byl czad! Kiedy pokazywalem niektorym osobom jak cos mozna lepiej zrobic, byli zachwyceni. Co za soft! Dla nich to cenne informacje pozwalajace oszczedzic czas i usprawnic prace. Dodatkowo poznalem lepiej proces zakupow. Uslyszalem wiele przykladow z zycia codziennego co dalo mi nowe spojrzenie nie tylko na sam system ale ogolnie na prace, ktora wykonuje. Jak wazne jest dobre zrozumienie tematu, przygotowanie uzytecznego rozwiazania i komunikacja.
Takie spotkanie polecam kazdemu kto pisze soft dla ludzi.

Prawie jak SVN :)

Jesli pracujesz z CVS to masz szanse natknac sie na taki oto problem:
Programista Henio przychodzi do pracy i synchronizuje sie z repozytorium cvs. Wszystko mu sie pieknie zbudowalo. W trakcie testowania czegos zauwaza, ze cos jednak w programie dziala nie tak jak wczoraj. Hmmm, pewnie ktos cos pozmienial. Zaraz sprawdzimy. I tu Henio sie orientuje, ze standardowy plugin w jego eclipsie nie pozwala pokazac jakie pliki zostaly zmienione w konkretnym commicie. Ojjojjoj jak dobrze bylo uzywac svn. I jak sie teraz dowiedziec kto, co i kiedy zacommitowal.

Heniowi pyta wujka Googlek o rade, a on wskazuje na ten oto adres:
Eclipse CVS ChangeLog Plugin. Henio instaluje plugin w swoim eclipse, wszystko ladnie dziala. Teraz juz wiadomo kto co ostatnio commitowal, latwiej znalez co zostalo popsute. CVS stal sie prawie jak SVN tak na 5 minut.

Czytanie między wierszami ma swoje minusy

Dużo dobrego słyszałem o polskich programistach, którzy z byle jakie specyfikacji potrafią zmajstrować solidny program. Jak oni to robią? Z tego co udało mi się zaobserwować stosuję metodologię CzytajMiędzyWierszami. A kim są ci, którzy bardzo lubią tą metodologię? Są to ludzie, którzy z różnych powodów opracowują niestarannie wymagania klienta, piszą nieprzemyślaną specyfikację, później to zatwierdzają i przekazują dalej (cokolwiek to znaczy).

Oto programista Henio dostaje do wyklepania CRa. Widzi jego opis zarejestrowany w BTS, widzi komentarze, jakieś dodatkowe wyjaśnienia, linki do UseCase'ów, widzi maile z kolejnymi potwierdzeniami od specyfikatorów i testerów, wszystko jest ok. Henio jest pilnym programistą i już niejedno na swojej programistycznej ścieżce widział. Po pierwszym czytaniu Henio widzi, że to co jest w BTS i to co jest w UseCase'ach to nie to samo. Henio zna metodologię CzytajMiędzyWierszami wie kiedy jest deadline i wie jeszcze, że żeby odkręcić te kilka szczegółów trzeba porozmawiać (Henio wie, że maila wysyła się, kiedy nie trzeba czegoś szybko załatwić) z 3 osobami, wyjaśnić im co jest nie tak, poprosić o komentarz, posłuchać ich wyjaśnień i dostać od nich poprawione wersje. Do tego wszystkiego dochodzi jeszcze pośrednio kierownik projektu, który zablokował pliki, ponieważ dostał informację, że wszystko jest zapięte. Tak się składa, że do pokoju Henia przyszedł Zenek. Henio przedstawił sprawę Zenkowi i zapytał co by Zenek zrobił. Zenek też zna metodę CzytajMiędzyWierszami do tego zna jeszcze NieCzytajMiędzWierszami. Zenek pyta Henia co się stanie jeśli CR zostanie wyklepany i pójdzie do testów. No jak to co? Testerzy przeczytają specyfikację i go przetestują, tzn przetestuję część. To co stoi między wierszami pominą. W końcu po to mamy specyfikację i wymagania, żeby na nich polegać. CR trafi na produkcję. Przyjdzie kilka bugów, się poprawi i jakoś będzie - pochodna code and fix. Ktoś nie dostanie na czas swojego samochodu, ktoś dostanie paczkę z tygodniowym opóźnieniem, innych 1000 osób będzie musiało dalej drukować i pewne dokumenty zamiast móc je przekazywać drogą elektroniczną. No chyba, że Heniu poświęci swój cenny czas, jaki spędza w pracy na zrobienie czegoś naprawdę dobrze i na poziomie. Co zrobi Heniu? A co zrobisz ty w takiej sytuacji?

FritzBox - telefonia internetowa

Oto moj modem FritzBox 7170

Nie ma to jak przyjaciele i ich dobre rady. Po jednej z nich zakupilem ten model, ktory jak dla ma bogata funkcjonalnosc. To z czego obecnie korzystam i bardzo jestem zadowolony to wbudowane w niego bramka VOIP. Numer niemiecki zakupilem u lokalnego dostawcy, numer polski w strefie 071 easycall.pl (5zl/rok). Do routera podlaczylem zwykly telefon stacjonarn. Router pozwala zarejestrowac kilka numerow telefonu i podpiac je pod jeden telefon. I tak oto rodzina z Polski dzwoni na moj numer ze strefy 071 i placi lokalnie, znajomi z Niemiec dzwonia do mnie jak do volksdojcza. Ja wybierajac odpowiedni prefix dzwonie przez 071 do polski (0.08 gr/min), a do Niemiec przez odpowidni inny prefix. Jestem bardzo zadowolony z tego rozwiazania. Jesli ktos chce znac szczegoly to chetnie podziele sie na priv.

ThoughtWorks - relacja

Na wyklad przyszla ponad setka osob.

Wolf Schlegel: "Dos and don'ts of Continuous Integration and Delivery"
Wolf zadal takie oto pytanie: Ile czasu zajmuje dostarczenie nowej wersji na produkcje po dodaniu jednej linijki kodu?
Mozliwos szybkiego i sprawnego dostarczenia nowej wersji jest kluczowa. Decyzja o tym kiedy nowy releas wejdzie na produkcje jest sprawa marketingowa, umiejetnosc zrobienia tego jest sprawa techniczna. I ta umiejetnosc czesto przesadza o tym kto zagarnie nowych klientow.
Znane sa sytuacje kiedy programista nie zdarzyl sie wyrobic i pewna czesc funkcjonalnosci przesunieta zostala do kolejnego release (np. na 3 miesiace)
bo taki jest plan.
A co gdyby po kazdej wprowadzonej zmianie mozna bylo miec mozliwosc latwego dostarczenia nowej wersj na produkcje?
Oznacza to m.in.:

• latwosc zarzadzania wersja
• sprawne przeprowadzenie testow (np. automatyzacja)
• sprawny proces budowy nowej wersji, sprawny deployment (lacznie z backupami danych)
  

Erik Dörnenburg: "Lean for enterprise architecture"
Erik twierdzi, ze architektura oprogramowania ma wbrew pozorom wiecej wspolnego z ogrodnictwem niz z klasyczna architektura i budownictwem.
Tu przpomina mi sie czesc artykulu Martina Fowlera http://www.thoughtworks.com/the-new-methodology. Jakims sposobem zapamietalem prawi nic z jego sesji ale moze dlatego ze
nie bylo w niej nic nowego poza tym co napisal Fowler we wspomnianym artykule. Musze jednak zaznaczyc, ze sesja Erika podobala mi sie najbardzie.

Martin Fowler: "Software Design in the 21st Century"
Na tego pana czekalem z duzym zainteresowaniem. Do tej pory czytalem tylko jego ksiazki, bloga i artykuly. Tym razem mialem okazje chwile go poobserwowac i zamienic slowo.
Martin opowiadal o wzkorzystaniu podejscia przy projektowaniu. Glowynm argumentem za bylo mozliwosc przywrocenia systemu do danego stanu za pomoca zalogowanych eventow.
Latwa reprodukcje defektow na podstawie sekwencji eventow. Mozliwosc badania systemu w roznych stanach i latwosc uzyskiwania tach stanow. Szczegoly sa tu http://martinfowler.com/eaaDev/EventSourcing.html

W drugiej czesci omawiany byl software design ogolnie. Nie obylo sie bez Uncle Bob i kwesti moralnej kazdego programisty wsickajacego codziennie guzik(i). Poruszony zostal rowniez temat dlugo technicznego (technical debt) http://martinfowler.com/bliki/TechnicalDebt.html. Jak to z kazdym dlugiem, trzeba go kiedys zwrucic, czesto z odsetkami. Chodzi tu o sytuaje kiedy management cisnie na zrobienie czegos na wczoraj zeby dzialalo, nie wazne jak, zaby tylko klient mogl przeklikac. I nie ma nic w tym zlego. Kredyty sa zaciagane na przerozne rzyczy. Jedyne o czym trzeba pamietac to splata - ona kiedys nastapi. Moze nie podczas trwania projektu, a juz w fazie utrzymania. Nie wazne - zaplacic wkoncu trzeba, a zaplaci pewnie klient.

We wszystkich wystapiniech czuc bylo mocno podejscie adaptacyjne i nacisk na bardzo bliska wspolprace z klientem oraz profesjonalizm w wytwarzaniu oprogramowania. Wszystko po to zeby stworzyc nie tyle sam produkt ile srodowisko pozwalajace przygotowac taki produkt, ktory da sie:

• latwo dopasowac do zmian na rynku (dodanie nowzch funkcjonalnosci, zmiana istniejacych) good design
• sprawnie wprowadzac na rynek - WPROWADZAC i WPROWADZAC ciagle - continues integration and delivery
• tworzyc przy nierozlacznej wspolpracy biznesu z IT - klient jest aktywna czescie zespolu tworzacego oprogramowanie

W tym srodowisku najwazniejsi sa ludzie. "Put people first" i moja parafraza pewnego sloganu "People matter, results come". Ten caly agile jest po prostu dla ludzi, a nie dla projektow czy tam procesow. To znaczy, sa ludzie, ktorzy beda w takim systemie dobrze pracowali i sa tacy ktorym on bedzie nie na reke. Jednak te male robaczki z samego dolu programistycznego padolu sa waze, a nawet bardzo. Nazywane przez niektorych resource'ami sa jak to pisze Fowler indywidualnosciami przeznaczonymi do tworczej pracy. Jak to wlasciwie jest ?

Software Design in the 21st Century by ThoughtWorks

Dzisiaj po pracy jade do Berlina na: Software Design in the 21st Century. Przy okazji chcialem podziekowac Marcinowi za informacje o tym wydarzeniu. Networking dziala! Czytalem troche Fowlera i postanowilem nie przepuscic tej okazji. Udalo mi sie namowic kolege z projektu wiec jedziemy razem, bedziemy mieli okazje na dluzsza rozmowe.

Malgosia i Janek sind schon da....

wczoraj w nocy przyjechalismy razem do Wolfsburga... Janek zniosl droge (5,5h) zaskakujaco dobrze, wiekszosc czasu spal. Teraz czas na adaptacje w nowym terenie, w nowej konfiguracji.

W mylynowym kontescie nie widac wszystkich plikow

Po co widziec te wszystkie pliki? Po to sa rozne kontesty zeby latwiej bylo sie w nich poruszac (moje proste wyjasnienie). To kwestia przestawienia sie na Task Focused Programming. Jednak moj kontekst sie szybko "brudzil".
Byly ku temu dwa powody:

1. A to w trakcie pracy nad problemem A zapragnalem na chwile wskoczyc w problem B
2. A to ktos przyszedl do mnie, zeby sie o cos spytac w kodzie

Wylaczenie aktywnego zadania powodowalo, ze wszystkie edytory byly tez zamykane. Wtedy ja szukalem tego co mi bylo potrzebne. Ewentualnie nie deaktywowalem zadania nad ktorym pracowalem i wtedy kontekst "wybogacal sie" o rzeczy z nim niezwiazane. Znalazlem na to 2 rozwiaznia. Oto one:
Rozwiazanie 1. Utworzylem sobie nowe lokalne zadanie o nazwie WTF (wiadomo). Mozna tez AnyOtherBusiness lub DevNull jak kto woli. Ilekroc ktos ma do mnie jaki biznes przelaczam sie na moje specjalne smietnikowe zadanie i szafa gra.
Rozwiazanie 2. Zauwazylem ze w widoku "Projec Explorer" kiedy zatrzymam myszke na ikonce projektu lub pakietu pojawia sie obok niej taki maly "+". Po nacisnieciu dostaje sie pelny widok jednak nie jest on dodawany do kontekstu dopukni nie otworze pliku.
Rozwiazaniem podzielilem sie z kolega obok i bardzo mu sie spodobalo.Tteraz obaj mamy zadanie WTF na naszych listach :)

Byc testerem, pierwsze wrazenia...

Od kilku dni wspieram zespol testerow. Ktos pomyslal, ze bedzie to dla mnie dobra okazja do zapoznania sie z funkcjonalnoscia systemu. No wiec testuje i wspolczuje wszystkim testerom klikajacym codziennie po raz setny ten to smo GUI. Robie przy tym notatki z uwagami co do procesu. Nie moge powiedziec, ze sie niczego ciekawego nie ucze. Jednak taka praca powinna byc w jak najwiekszym stopniu zautomatyzowana tak zeby ludzie, majacy mozg, wyobraznie i inne niessamowite atrybuty mogli zajmowac sie wlasciwymi dla nich rzeczami. W ksiazce Pragmatic Project Automation mozna znalezc akapit pod tytulem:
Why should automate something? - Bardzo jasno wyjasnine.