blog.testowka.pl

W skrócie…
Gdyby zapisy zawarte w ACTA obowiązywały pięć lat temu ten blog najprawdopodobniej nigdy by nie powstał, lub znalazł by się też paragraf na to, by go teraz zdelegalizować.

O ile to co tutaj zamieszczam jest moją własnością lub jest udostępniane na zasadzie wolnego oprogramowania o tyle wiedza, którą zdobyłem na przestrzeni ostatnich kilku lat zapewne w większości nie była by dostępna, gdyby przepisy takie jak te zawarte w ACTA, SOPA czy PIPA zostały wprowadzone, a to właśnie ta wiedza jest moją własnością – no właśnie, czy w świetle ACTA nadal jest moją własnością?

Więcej o ACTA możecie dowiedzieć się z tego filmiku, oraz dyskusji na Wikipedii i przede wszystkim stąd.

Swoją drogą nigdy nie miałem ochoty a przede wszystkim powodu by wychodzić na ulicę i manifestować swoje poglądy a przede wszystkim jakikolwiek sprzeciw. Natomiast tym razem zamierzam skorzystać z demokratycznego prawa do manifestacji swojego niezadowolenia.

A jeśli jesteście we Wrocławiu i okolicach zapraszam do przyłączenia się do protestu w środę – i przekazywania informacji dalej.

Oczywiście zachęcam też, do protestów w Waszych miastach.

(Zdielano w Polandii)

Minęło już trochę czasu od konferencji Test Warez 2011, w której miałem okazję brać udział jako prelegent, więc chyba najwyższa pora, by podzielić się moimi spostrzeżeniami.

Test Warez jest obecnie największa i prawdopodobnie najpopularniejszą konferencją skierowaną do testerów w Polsce. W zasadzie można śmiało stwierdzić, że nie ma żadnych konurencyjnych wydarzeń w tej tematyce na taką skalę… Właśnie to, że jest to jedyna taka konferencja w naszym kraju jest naszym największym problemem.

Sam poziom konferencji pomimo tego, iż na polskie warunki na prawdę bardzo wysoki niestety nie ma się co równać z konferencjami za granicą. Niemniej jednak wielkie podziękowania dla organizatorów za to, że próbują zrobić coś dla testerów w Polsce.

Nie będę się rozpisywał na temat wszystkich prelekcji i prelegentów, ale chciałem się skupić na dwóch, które pozwoliły mi zrozumieć jaki jest obecny stan Polskiego światka testerów oprogramowania.

Na pierwszy ogień panel dyskusyjny Radka Smilgina z Testerzy.pl zatytułowany: “Dokąd idziesz Testowanie? Co ważnego wydarzyło się w testowaniu w ostatnim roku i co wydarzy się w kolejnych latach”. Panel miał na celu wskazanie najważniejszych wydarzeń w polskim testowaniu oprogramowania, które miały miejsce w minionym roku. Do jednych z głównych wydarzeń roku zostały zaliczone:
- rozpoczęcie kierunku studiów “Testowanie Oprogramowania”
- start platformy crowdsourcingowej testuj.pl
Obydwa powyższe wydarzenia na prawdę są znaczące, niestety polskie testowanie oprogramowania jest daleko w tyle za innymi krajami. Gdy na całym świecie coraz większą popularność zyskuje Agile, a o czymś takim jak Waterfall wszyscy powoli zapominają u nas nadal wszyscy skupiają się na tym jak wykrywać błędy zamiast pracować nad tym jak tych błędów do oprogramowania nie wprowadzać. Platformy crowdsourcingowe skupiające testerów oprogramowania także nie są niczym nowym.
Chociaż akurat powstanie polskiej platformy powinno niektórym dać jasny sygnał do tego, że testowanie oprogramowania w wielu firmach w postaci takiej jak miało miejsce przez ostatnich wiele lat (klikanie) powoli ma się ku końcowi – po co utrzymywać dział klikaczy skoro zawsze można tą usługę dużo taniej wydzierżawić na zewnątrz płacąc tylko za efekty.
Niestety powyższe wydarzenia to tylko kopia tego co na całym świecie miało miejsce już wiele lat temu.

Kolejną prelekcja, która dużo mi uświadomiła był agile’owy wykład Moniki Konieczny na temat kontaktów między testerami a programistami w zespołach (głównie mniej, lub bardziej zwinnych zespołach), oraz o tym jak przy użyciu gemifikacji można te kontakty poprawiać. Podczas prelekcji na sali zaistniał pewien szum rozmów, a nawet śmiechów i pytań typu “o czym ona gada?, jakie konflikty z programistami?”. Dało mi to wiele do myślenia i w końcu po przeprowadzeniu kilku wywiadów środowiskowych przypomniałem sobie o potencjalnych przyczynach tego problemu. Mówienie o pozornie nieznaczących konfliktach między programistami a testerami w zespołach może nie docierać do wielu osób, które nigdy w zespole programistyczno-testerskim nie pracowały. Sam pamiętam czasy, gdy pracowałem w firmie, gdzie dział testerski znajdował się na pierwszym piętrze budynku, a programiści siedzieli na czwartym. Wielu z tych programistów nie spotkałem nigdy osobiście i nawet nie wiem o tym jak wyglądają, a co dopiero mówić o konfliktach i problemach komunikacyjnych w codziennej pracy face2face. To jeszcze jeden argument świadczący o tym, że niestety świadomość polskich firm IT o jakości oprogramowania i zapewnianiu tejże jakości jest dosyć niska w porównaniu do naszych kolegów i koleżanek z zagranicy.

Wisienką na torcie, a raczej kroplą, która przelała czarę goryczy była rozmowa z jednym z wysoko postawionych członków Stowarzyszenia Jakości Systemów Informatycznych (SJSI), który przy obiedzie opowiedział mi o swoich odczuciach po spotkaniu z Tom’em Gilb’em (jeden ze specjalistów od Lean Software Development), na którym Tom opowiadało o tym, że jakość oprogramowania wcale nie bierze się z jego testowania tylko jest zaszyta w nim dużo wcześniej. Testowanie oprogramowania a zwłaszcza wykrywane błędy to zwykły waste. Wspomniany przedstawiciel SJSI był pod wielkim wrażeniem powyższego stwierdzenia i niesamowicie zaskoczony jego trafnością (WTF!). Dlaczego dopiero teraz?! Mamy 2011 rok! 10 lat od opublikowania manifestu Agile, kilkanaście lat od powstania eXtreeme Programming, kilka lat od ogłoszenia Software Craftmentship Manifest, a w Polsce ludzie, którzy są odpowiedzialni za głoszenie informacji mających na celu poprawianie jakości wytwarzanego oprogramowania dopiero teraz odkrywają rzeczy, które na całym świecie są oczywiste od ponad dekady.

Tak jak kiedyś na moim blogu w komentarzu napisał Krystian Kaczor: “W tym roku jest konferencja TestWarez pod tytułem “Testować tradycyjnie, czy zwinnie?”. No co to za pytanie w ogóle? Może “Iść pod prąd, czy nie?””  Agile i wytwarzanie oprogramowania wysokiej jakości od samego początku jest faktem. To nie bajka, o której opowiadają gdzieś na mitycznym Zachodzie, to fakt, który bardzo szybko wykluczy polskie firmy IT, które nie będą w stanie sprostać wymaganiom narzucanym przez zagraniczną konkurencję.

Agile Central Europe 2011 – jedna z najlepszych konferencji w jakich miałem przyjemność uczestniczyć! Dwa bardzo intensywne dni konferencji po których na szczęście był weekend dzięki czemu mogłem odpocząć i poukładać myśli. Z pełną premedytacją publikuję swoje przemyślenia dopiero dzisiaj – postanowiłem nabrać dystansu i pozbyć się emocji wzbudzonych przez niektóre prezentację i samą konferencję jako całość.

W tym roku Agile Central Europe została zorganizowana jako konferencja z tylko jedną ścieżką, co moim zdaniem było strzałem w dziesiątkę! Nie było niepotrzebnego rozproszenia, a prelegenci mieli tylko po 30 minut (z dwoma wyjątkami) na prezentacje dzięki czemu wszystkie prezentacje były bardzo treściwe i dynamiczne. Dzięki świetnie zorganizowanym sesjom Open Space każdy miał okazję głębiej wniknąć w omawiane tematy podczas bezpośrednich rozmów z prelegentami. Świetnym pomysłem było także konferencyjne piwo już pierwszego dnia, dzięki czemu frekwencja była znacznie większa niż gdyby odbyło się to w ostatni dzień.

Do rzeczy! Nie sposób opisać wszystkich prezentacji i prelegentów, dlatego też skupię się na tych, które wywarły na mnie największe wrażenie i najdłużej pozostały w mojej pamięci (to też był jeden z powodów tego, iż czekałem z publikacją tego wpisu, wydaje mi się, że jeśli coś zdążyło w ciągu kilku tygodniu ulecieć z pamięci to nie było to dla mnie aż tak istotne). Kilka dni temu zostały opublikowane nagrania prezentacji dlatego też nie będę się skupiał na szczegółach tylko postaram się zachęcić do obejrzenia tego co według mnie warto obejrzeć na pewno.

Konferencję rozpoczął Corey Haines – jeden z najbardziej charyzmatycznych ludzi IT z jakimi miałem kiedykolwiek do czynienia. Corey między innymi nawiązał do tego jak to wszystko się zaczęło – jak powstał Manifest Agile, jak powstało XP i co tak na prawdę te zasady znaczą. Kluczem tej prezentacji a zarazem jednym z kluczowych tematów całej konferencji była “informacja zwrotna” – generalnie cała idea zwinnego wytwarzania oprogramowania opiera się o szybką informację zwrotną na różnych poziomach. Ta prezentacja jak i sam Corey zrobiły na mnie prawdopodobnie największe wrażenie. Pozwolę sobie przytoczyć także odpowiedź Corey’a na pytanie co myśli o QAach w zespole agile’owym, które zadałem wieczorem przy piwie: “Uwielbiam QAów – to są przeważnie świetni fachowcy, którzy doskonale znają system nad którym pracujemy, wiedzą znacznie więcej niż programiści, gdyż często patrzą na aplikacje z innej, bardziej ogólnej, całościowej perspektywy, są bardzo pomocni. Nie znoszę natomiast testerów – małp klikających, nie ma większej straty niż tacy ludzie – po co mi tester skoro jego pracę mogę praktycznie w całości zautomatyzować.” Pomijając całą otoczkę wokół tego jak bardzo testerzy są potrzebni etc. zgadzam się z powyższą wypowiedzią – zresztą kiedyś już o tym pisałem.

Kolejną prezentacją która wywarła na mnie duże wrażenie była prezentacja Petry Skapa, która przytoczyła kilka przykładów wdrożeń zwinnych metodyk wytwarzania oprogramowania w różnych organizacjach. Pojawiło się także wiele przykładów realnych problemów oraz rozwiązań jakie Petra zastosowała. Dzięki praktycznym przykładom ta prelekcja pokazała realne problemy a także różne podejścia do tego jak sobie z tymi problemami radzić. Polecam zwłaszcza tym, którzy próbują wdrażać Agile we własnej organizacji.

Bardzo wartościowa dla mnie była także prelekcja Thomas’a Sundberg’a, której tematem był Technical Debt – dług, który zaciągamy nie przestrzegając zasad zapewniania jakości w procesie wytwarzania oprogramowania. Prezentacja warta obejrzenia, chociażby po to by sobie przypomnieć jak łatwo wpaść w błędne koło zaciągania długu technicznego. Poza tym podczas prelekcji pojawiło się wiele ciekawych metafor.

Oczywiście wszystkie prezentacje były warte obejrzenia. Każdy z pewnością znajdzie coś dla siebie.

Niezwykle istotne dla mnie okazały się także rozmowy Open Space, gdzie miałem okazję poruszyć kilka tematów i zadać kilka pytań, które od dłuższego czasu mnie nurtowały. Uzyskałem bardzo wartościowe i ciekawe odpowiedzi od ludzi, którzy są specjalistami w swoich dziedzinach, a na pewno starają się ciągle rozwijać i doskonalić swoje umiejętności. Być może wkrótce rozwinę ten temat tutaj.

Podsumowując – jeśli tylko nic nie stanie na przeszkodzie to w przyszłym roku na pewno spotkamy się na ACE2012! Gratulacje i podziękowania dla Paula Klipp’a – świetna organizacja i pomysł, oby tak dalej!

Tajemniczy tytuł Shu-Ha-Ri to zaczerpnięte z kultury japońskiej trzy poziomy doświadczenia, często używane w kontekście sztuk walki takich jak aikido. Piszę o tym, gdyż nauka sztuk walki ma zaskakująco wiele wspólnego z wdrażaniem metodologi w organizacji. Trzy poziomy doświadczenia, trzy poziomy wtajemniczenia wymuszają na uczniu stopniową, systematyczną naukę dzięki czemu eliminuje się większość błędów.

Shu – przyswojenie, zachowanie, pielęgnacja
Jest to pierwszy etap nauki, w której uczeń skupia się na opanowaniu podstawowych technik i zachowań. Termin ten oznacza także lojalność wobec jednego nauczyciela. Podczas tego etapu najważniejsze jest przyswajanie wszystkiego z największa dokładnością bez możliwości wprowadzania jakichkolwiek zmian. W tej fazie nieistotne są powody stosowania technik, najważniejsze jest opanowanie do perfekcji podstaw. (Przypomina mi się scena z “Karate Kid” w której dzieciak uczy się podstawowych ruchów myjąc samochody ). Nie wszyscy zdają sobie sprawę z tego jak ważne jest zbudowanie podstaw, by móc z powodzeniem dalej rozwijać swoje umiejętności. Na poziomie Shu okazuje się, że do osiągnięcia celu jakim jest efektywne wykorzystanie umiejętności wystarczająca jest jedna droga, stąd też wymóg lojalności do nauczyciela i posłuszeństwo. Ta stara zasada jasno pokazuje, że mieszanie różnych technik a w naszym przypadku metodologi wprowadza chaos i doprowadza do sytuacji, w której mamy dużo różnych umiejętności ale nie reprezentują one żadnej wartości praktycznej ani technicznej jako całość. Według tradycji to nauczyciel decyduje o tym kiedy uczeń może zakończyć ten etap i przejść na poziom Ha.

Ha – odłączenie, zerwanie z tradycją
Drugi etap nauki polega na uwolnieniu się do pewnego stopnia od klasycznych metod. W tej fazie ważne jest by odnaleźć i zrozumieć powody technik nauczonych na poprzednim etapie. Tutaj zaczyna się sztuka, odłączenie od codziennie powtarzanych czynności i stopniowe rozwijanie technik. Na tym etapie uczeń rozpoczyna własne eksperymenty, powinien być gotowy na to by samodzielnie analizować i myśleć nad powodami wykorzystywania niektórych technik po to by w przyszłości samodzielnie je rozwijać i dołączać nowe. Cała dostępna wiedza została zdobyta, teraz uczeń musi nabyć doświadczenia.

Ri – uwolnienie
Ostatni etap, w którym uczeń staje się mistrzem, uwalnia się od tradycji, przechodzi poza granice. Uczeń posiadający duże doświadczenie i wiedzę może je wykorzystywać w życiu codziennym. Na tym etapie uczeń już nie uczy się sztuki walki od innych tylko tworzy swój własny niepowtarzalny styl. Dopiero tutaj możliwe jest całkowite uwolnienie od standardów i podstaw. Tutaj uczeń/mistrz może pozwolić sobie na niekonwencjonalność, która dzięki zdobytej wcześniej wiedzy i doświadczeniu ma bardzo duże szanse na sukces.

Jak to wszystko ma się do wdrażania metodologii? Miałem nie do końca przyjemną okazję kilkukrotnego obserwowania prób wdrożenia metodologi/narzędzi (Scrum, Kanban) w różnych organizacjach, które zakończyło się porażką. Porażka ta według moich obserwacji wynikała między innymi z tego, że wdrażający zakładali, iż członkowie zespołu i oni sami są co najmniej na poziomie Ha, z tym że wielokrotnie brakowało im wiele do osiągnięcia Shu – nie znali, bądź nie potrafili stosować podstaw. Ponadto wdrożenia typu “weźmy planowanie ze Scrum, tablicę z Kanban ale nie stosujmy na niej limitów, do tego eliminujmy waste za pomocą narzędzi Lean i nazwijmy to wszystko Agile to może nam coś tego wyjdzie” ciężko jest nazwać wdrożeniem. Jak już pisałem w notce o automatycznym chaosie jeśli wdrażamy coś w organizacji to przede wszystkim musimy wiedzieć co wdrażamy i mieć jakiś, co najmniej ogólny plan wdrożenia. Pisałem też już kiedyś o teorii i jej zestawieniu z praktyką, moje doświadczenia jasno pokazują, że teorie sprawdzają się w przygniatającej większości przypadków jeśli tylko spełni się jeden zasadniczy warunek – postępuje się według jednej teorii od początku do końca.
Miałem okazję jakiś czas temu wspierać jeden mały zespół podczas wdrażania Scrum, postanowiłem zastosować zasadę Shu-Ha-Ri. Na początku pokazałem im wszystkie artefakty, pokazałem jak powinno wyglądać planowanie, jak rozbijać zadania, jak rozmawiać podczas spotkań typu stand-up oraz wyjaśniłem klientowi w jaki sposób opisywać wymagania. Po dwóch sprintach, podczas których na prawdę sumiennie starali się przestrzegać wszystkich zasad, praktycznie nie musiałem już tłumaczyć po co to wszystko było – sami dobrze wiedzieli co zyskali porównując sytuację obecną z poprzednimi projektami i z łatwością potrafili wskazać przyczyny stosowania takich a nie innych technik. Obecnie po trzech miesiącach zespół skutecznie wprowadza własne usprawnienia do stosowanej metodologi – starają się używać TDD, programują w parach, robią regularne przeglądy kodu. Wielce pomocne okazały się retrospekcje, które dosyć szybko definiowały problemy, a metoda systematycznego wprowadzania poprawek do procesu owocuje polepszeniem jakości pracy a także lepszą atmosferą i motywacją wynikającą każdorazowo z sukcesu jakim jest eliminacja błędów z procesu.

Po raz pierwszy o Shu-Ha-Ri przeczytałem w książce Alistera Cockburn’a “Agile Software Development – Gra Zespołowa”, którą polecam. Lektura zachęciła mnie do dalszego drążenia tematu, którego efektem jest ta notka

Ostatnio wpadła w moje ręce książka autorstwa Radka Smilgina i Anny Piaskowy “Dane testowe – teoria i praktyka”. W zasadzie to dostałem ją od Radka w prezencie , także po to by napisać kilka słów o tym co myślę na jej temat.
Z tego co wiem jest to pierwsza publikacja na temat danych testowych na polskim rynku i to już samo w sobie daje jej dużego plusa. Moje pierwsze odczucia po przeczytaniu książki były raczej mieszane. Po pierwsze jest dosyć cienka – przeczytałem ją w jeden wieczór. Całość składa się z dwóch części – pierwsza to ogólna teoria na temat danych testowych i ich wykorzystania oraz przykłady typowych danych testowych wraz z normami prawnymi i obowiązującymi standardami, druga część to w zasadzie instrukcja obsługi generatora danych testowych – bardzo praktyczna aplikacja, ale o tym może innym razem.
Po przeczytaniu wszystkiego pozostał pewien niedosyt – czegoś mi tutaj brakowało, ale może takie właśnie było założenie autora – żeby nie lać wody a skupić się na suchej analizie, która sama w sobie jest dosyć treściwa, (a w wykonaniu Radka na bardzo wysokim poziomie), książka na pewno zachęca do samodzielnego poszukiwania dalszych informacji. Czytając zastanawiałem się komu sam bym polecił przeczytanie tej pozycji – doszedłem do wniosku, że książka jest skierowana, głównie do osób początkujących w testowaniu czy programowaniu, stanowi także świetne uzupełnienie materiałów uniwersyteckich dla studentów informatyki. Mi osobiście treść książki przypomniała o kilku ważnych aspektach dobierania danych testowych w zależności od rodzajów testów, oraz o zasadach definiowania przypadków testowych. Jeśli mowa o przykładach i teorii zawartych w książce to niestety (albo może właśnie to jest jej największy atut) książka jest mocno zlokalizowana na rynek polski, dane są specyficzne dla naszego kraju. Z drugiej strony czytając przykłady i omówienie zasad tworzenia np. imion w języku polskim znalazłem bardzo wiele interesujących ciekawostek, o których wcześniej nie miałem pojęcia.
Nie będę tutaj streszczał treści, wszystkich zainteresowanych odsyłam do księgarni (książkę wydał Helion, więc można ją nabyć przez internet ).
Ogólna ocena: “dobry”.
Warto przeczytać chociażby po to by podsumować swoją dotychczasową wiedzę, a początkującym na pewno książka ta pomoże w trafny sposób dobierać dane testowe, oraz poszerzy horyzonty wskazując miejsca skąd można dane do testów uzyskać.
Ponadto jak wspomniałem na początku wielki plus za to, że wreszcie pojawiła się jakaś pozycja tematyczna na naszym krajowym rynku autorstwa naszych rodzimych specjalistów. Mam nadzieję, że to nie koniec twórczości Radka i że jeszcze nie raz będziemy mieli okazję przeczytać wiele interesujących publikacji na temat testowania i nie tylko autorstwa naszych kolegów i koleżanek po fachu.

Nareszcie udało się opublikować nagranie z mojej prelekcji w ramach scrum.org.pl. Niestety z powodu problemów technicznych wyciętych jest kilka minut wstępu, ale to co najważniejsze się ostało.

Zwinne środowisko testowe aplikacji webowych from Andy Brandt on Vimeo.

Zgodnie z obietnicą zamieszczam prezentację z ostatniego SPINu. Dziękuję wszystkim za przybycie.

Link do prezentacji znajduje się tutaj: TDD i Continous Integration.

Ze względu na trudności techniczne podczas praktycznej części prezentacji film który był nagrywany zostanie uzupełniony o DZIAŁAJĄCE przykłady (oczywiście link do niego też znajdzie się na blogu). Za wszelkie niedociągnięcia techniczne przepraszam, tak to jest gdy w ostatniej chwili wpada się na “genialne” pomysły przeróbek i udoskonaleń prezentacji…

Wyciągnąłem wnioski na przyszłość…

Serdecznie zapraszam na najbliższe spotkanie krakowskiej grupy SPIN, które odbędzie się 27.05.2010 o godzinie 18.00 tradycyjnie już w siedzibie Comarchu. Na spotkaniu tym postaram się przybliżyć ideę Continous Integration oraz TDD a przede wszystkim pokażę jak za darmo stworzyć kompletne środowisko do automatycznych testów GUI (zgonie z zasadami CI).

Po spotkaniu zamieszczę tutaj prezentację pewnie z jakimś szczegółowym opisem, a także nagranie (jeśli wszystko pójdzie zgodnie z planem).

Jeszcze raz serdecznie zapraszam!

Ostatnio miałem okazje uczestniczyć w konferencji PyConPl’09 poświęconej programowaniu w pythonie (i nie tylko). Konferencja odbyła się w ośrodku wczasowym “Gwarek” w  malowniczym Ustroniu. Kto był ten wie jak było, a kogo nie było niech czyta i zazdrości .

Pokuszę się o  krótkie streszczenie tego co według Testera było ciekawe.

Piątek 16 X 2009:
Niesamowicie ciekawy wykład Wesley’a Chuna o referencjach i modelach pamięci w pythonie. Podczas tego wykładu wreszcie udało mi się w pełni (mam nadzieję) zrozumieć idee alokacji pamięci nie tylko podczas programowania w Pythonie. Poza tym na uwagę zasłużyło stwierdzenie Wesley’a – “Wy jesteście młodzi i to do Was należy przyszłość świata”, miało ono sens ponieważ zostało poparte niewątpliwym przykładem w osobie samego Wesley’a który te słowa usłyszał kilka/kilkanaście lat temu od jednego ze swoich nauczycieli i teraz polata jak spojrzał wstecz i podsumował to co udało mu się osiągnąć (kilka książek o Pythonie, wykłady, prelekcje, szkolenia) to faktycznie wniósł jakiś wkład w przyszłość świata.

Sobota 17 X 2009:
Dzień zaczął się od warsztatów Pair Programing i TDD prowadzonych przez Konrada Delaga i Krzysztofa Goja, o ile do Pair Programing (patrząc z boku) jestem dość sceptycznie nastawiony o tyle TDD uważam za podstawę prowadzenia projektów agileowych. Niemniej jednak ponieważ TDD jest u nas w firmie na porządku dziennym i mamy w  tym spore doświadczenie to same warsztaty dla mnie osobiście nie były interesujące (może po części też dlatego, że jednak wymagały umiejętności programowania w Pythonie). Ale brawa dla chłopaków, bo tego typu praktyki trzeba jak najbardziej propagować, jeśli chcemy zapewnić wysoką jakość tworzonych a zwłaszcza rozwijanych aplikacji.

Kolejną dość ciekawą prelekcją było zagadnienie praktycznego wykorzystania Pythona we współczesnych systemach pomiarowych używanych w laboratoriach fizycznych. Prelekcje poprowadził Paweł Nita. Duży plus za pokazanie praktycznego wykorzystania języka.

Następnie bardzo interesujący wykład Marcina Mierzejewskiego o dataminingu i przewidywaniu przyszłości za pomocą Python i Orange. Dla mnie wykład był o tyle interesujący, że po dwóch latach studiów Informatyki i Ekonometrii wreszcie ktoś pokazał mi na prawdę proste ale bardzo efektywne zastosowanie podstaw metod ekonometrycznych i statystycznych. Oczywiście aspekt wykorzystania pythona do tworzenia modeli, które przewidują przyszłość obliczając trendy i inne tego typu rzeczy pokazuje kolejne praktyczne i wydajne zastosowanie tego języka. Sam temat dataminingu jest wart zainteresowania i w mitycznej wolnej chwili na pewno postaram się poszerzyć swoja wiedzę w tym temacie.

A po obiedzie był Adam Zieliński współtwórca serwisu dla kinomaniaków Filmaster.pl. I tutaj przeżyłem szok, gdy usłyszałem, że w serwisie, którego kod jest otwarty nie napisano prawie żadnych testów. Ja bym się wstydził pokazywać innym coś takiego i raczej bym się z tym krył. Niemniej jednak serwis świetny i wart polecenia.

Niedziela 18 X 2009:
Niedzielny poranek rozpoczął Jarosław Zgoda prezentacją o WSGI której konkluzją była idea wykorzystywania istniejących już rozwiązań a nie próba wynajdywania koła od nowa. Prezentacja bardzo wartościowa zwłaszcza dla początkujących programistów, którzy zawsze wiedzą lepiej

Wartym uwagi był też wykład Mrka Gajdy o tworzeniu prostych gier w Pythonie i nie tylko. Chyba nawet złapałem bakcyla, może to fajny pomysł na nowe hobby.

Podsumowanie: Konferencja na pewno pozostawiła pozytywne wrażenie – ciekawa tematyka i świetni ludzie. Kilka minusów organizacyjnych: bardzo marny internet, prąd którego dosyć często brakowało, ciasna i duszna sala etc. ale na plus świetna lokalizacja i doskonałe jedzenie . Mała dygresja – czemu można zorganizować konferencję dla programistów pythona której koszt to około 300 zł, a nie można zorganizować konferencji dla testerów za mniej niż 1000zł?

A i oczywiście podziękowania dla Code Sprinters i Andy’ego za zasponsorowanie naszego udziału w konferencji.

…W ciemnym pokoju, blask monitora oświetla przygarbioną postać testera… W tle słychać odgłosy stukania w klawiaturę i klikania myszką… Nagle ciszę przerywa złowieszczy śmiech… Operacja się udała… Wszyscy żyją… Może nie wyglądają już tak pieknie jak kiedyś, ale żyją…

Wreszcie po długich oczekiwaniach zmiana layoutu na blogu ze standardowego WordPressowego “pixeled” na moją własną kompozycję kolorystyczną. Od razu podkreślam, że w zasadzie zmieniłem tylko kolorystykę i kilka drobnych szczegółów, gdyż uważam, że sam schemat layoutu “pixeled” jest zadowalający. Może teraz blog nie wygląda tak ładnie jak przedtem ale z pewnością… jest bardziej czytelny…

Z ciekawostek do doboru kolorów użyłem bardzo ciekawego narzędzia “Color palette generator“, które wyciąga głębie barw z podanego obrazka.

Zdjęcie, które wykorzystałem znalazłem na iStockphoto i mam nadzieję, że wyciągnięcie głębi barw nie stanowi naruszenia praw autorskich

Oto i obrazek:

…prawda, że podobne?

Wprost idealnie wpasowuje się w kolorystykę strony. Eksperyment się powiódł, jak widać narzędzia tego typu mogą być bardzo pomocne przy projektowaniu schematów kolorystycznych dla stron.

Marek Kasperski w swojej ksiażce “Projektowanie Stron WWW – Użytecznosć w praktyce” pokazuje przydatność takich narzędzi w wszelkiego rodzaju próbach podświadomego wpływu za pomocą barw na percepcje użytkownika. Na przykład barwy ze zdjęć rajskich wysp idealnie nadają się do kolorystyki stron biur podróży.

Jedną z kilku ostatnio przeczytanych przeze mnie książek – nie związanych (bezpośrednio) z informatyką była książka “Sztuka Wojny” w przekładzie Jarka Zawadzkiego. Jednym słowem: “Klasyka”. Książka, którą warto przeczytać. Kilka (w Polsce) lat temu książka robiła furorę w środowisku menagerskim, jednak wszystko jakby trochę przycichło – czyżby okazało się, że praca to nie do końca wojna? Jednak na potrzeby tej notki przyjmę założenie, że praca i kariera mają z wojną wiele wspólnego.

Krótka histora – książka powstała prawdopodobnie około 740 -470 r. p.n.e. autorami są najprawdopodobniej Sun Wu i Su Bin obydwaj zwani Sun Tzu. Pierwszy po sformułowaniu trzynastu rozdziałów dotyczących sztuki wojny został generałem i pokonał wrogie armie, drugi był doradcą innego generała kilkadziesiat lat później.

“Sztuka Wojny” przyciągnęła moją uwagę ze względu na dwa aspekty – możliwość wykorzystania opisanych w niej zasad do zarządzania projektami, ludźmi – “armią”, oraz zastosowanie tychże zasad w “pojedynkach” z konkurencją i klientami. Wiele lekcji Sun Tzu udaje mi się także zastosować w życiu codzienny nie związnym z pracą – w zwykłych kontaktach międzyludzkich, rozwiązywaniu problemów, konfliktów…

Czytając książkę chwilami wydawało mi się, że czytam dobry podręcznik do agile – np. “Aby pokonać wroga trzeba jego armię rozbić na mniejsze i słabsze oddziały”, brzmi jak aby dobrze i szybko wykonać projekt należy każde zadanie rozbić na mniejsze – łatwiejsze do wykonania, “Swoje najlepsze oddziały wystawiaj przeciwko średnim przeciwnika, swoje średnie przeciwko najsłabszym, a najsilniejsze oddziały przeciwnika zostawiaj na koniec i możliwie najbardziej je rozbijaj i osłabiaj” tą zasadę można porównać do odpowiedniego rozdzielenia pracy w zespole programistów. O ile w książce były opisane tak drastyczne metody jak ścinanie niefrasobliwych generałów – o tyle w życiu raczej nie zamierzam nikogo ścinać. Zarządzanie zespołem ludzi w firmie można porównać do zarządzania armią. O ile w scrumie zespół sam się organizuje, a scrum master pełni rolę bardziej nadzorczą i wsparcia, o tyle w innych metodologiach silny lider jest konieczny. W dużych zespołach ważne jest także posłuszeństwo i dokładna wiedza na temat tego co jest czyim zadaniem oraz kto jest za co odpowiedzialny.

Na rynku w branży IT (i nie tylko) trwa nieustanna walka (jeśli nawet nie wojna), w której wszyscy walczą o klienta nie zawsze czysto. Także w tej dziedzinie możemy znaleźć wiele alegorii pomiędzy sztuką wojny a sztuką handlu/merketingu. Według Sun Tzu podstawą do zwycięstwa jest wywiad, tak też wiedza o tym kto czego potrzebuje na rynku jest kluczem do pozyskania klientów, a wiedza o tym co robi konkurencja daje możliwośc bycia zawsze o krok przed nimi.

W walce o klienta, czy w normalnym życiu przydaje się też umiejętność wprowadzania wrogów w błąd – sztuka podstępu. Czasem dobrze jest sprawić, gdy akurat mamy bardzo silną pozycję by wszyscy myśleli, że jest ona słaba chociażby po to by ją jeszcze bardziej wzmocnić, lub wykorzystać pewność siebie konkurencji. Także odwrotnie czasami trzeba umieć stworzyć pozytywną atmosferę gdy wszystko idzie źle, po to, by nie dać przeciwnikom szans na skuteczny atak.

Choć nie wiem jak byśmy się starali nasze życie pełne jest codziennych walk, sporów, wojen, dlatego polecam “Sztukę Wojny” może nie jako poradnik codziennego oszukiwania siebie i innych, ale jako dobrą wskazówkę, że tak też można i co gorsza inni to robią.

Na początku napisałem, że książka nie jest związana z informatyką – chyba jednak się myliłem – czyżby pracocholizm??

Na zakończenie 5 zasad na drodze do wygrania wojny:

- jedność moralna ludzi z władcą
- zdolności wodza
- umiejętne wykorzystanie czasu
- umiejętne wykorzystanie przestrzeni
- dobrze wyszkolone i moralnie zwarte wojsko