blog.testowka.pl

Testowanie

Szukamy QA!

opublikowany przez 21, Maj, 2015, w kategoriach Inne, Praca, Testowanie

Przez długi czas w Pragmatic Coders pracowaliśmy bez QA. Później mieliśmy testera po stronie klienta. W obydwu przypadka radziliśmy sobie całkiem dobrze. Teraz jednak stwierdziliśmy, że chcielibyśmy radzić sobie jeszcze lepiej.

Datego…

Poszukujemy osoby na stanowisko Quality Assurance Engineer, która wniesie dodatkową wartość do naszego zespołu.

Jeśli:

  • jesteś przyzwyczajony do pracy od 8 do 16 i nie wyobrażasz sobie tego jak można inaczej (nie tolerujesz wychodzenia z pracy kiedy się chce i pracy zdalnej jeśli ma się na to ochotę),
  • masz certyfikat ISTQB Advanced Level i posiadasz szerokie doświadczenie w stosowaniu omawianych tam praktyk,
  • jesteś ekspertem w pracy w ciągłym konflikcie z developerami i potrafisz ten konflikt efektywnie wykorzystywać do tego, by zapewnić jak najwyższą jakość,
  • Agile dla Ciebie jest fajny, ale zdajesz sobie sprawę z tego, że w praktyce lepiej jest jednak napisać plan testów, przypadki testowe i scenariusze,
  • masz bogate doświadczenia jako Test Manager i z łatwością zbudujesz dla nas dział testów w skład którego wejdą Twoi nowi podwładni,
  • masz doświadczenie w automatyzacji testów i wiesz, że automatyzacja ma sens tylko jeśli funkcjonalności są już stabilne i nie będą się zmieniać,
  • potrafisz sukcesywnie odseparować swoje życie od pracy (bo przecież praca to smutny obowiązek, ale jednak konieczny by móc się poza nią rozwijać),
  • jesteś prawdziwym ekspertem w wykonywaniu scenariuszy testowych, a Twoje raporty z testów i zgłoszenia błędów są zawsze bardzo starannie opisane i nie wyobrażasz sobie by można to było robić inaczej,
  • wiesz jak efektywnie wtestować jakość w oprogramowanie – znasz wiele praktyk, które na to pozwalają i wiesz jak je wdrożyć w życie,
  • potrafisz efektywne komunikować się z programistami używając wyłacznie Jiry (i/lub innego bugtrackera),

…jeśli spełniasz powyższe wymagania… to… raczej nie masz czego u nas szukać… No chyba, że szukasz terapii szokowej…

W innych przypadkach daj nam znać – chętnie porozmawiamy o Twoim doświadczeniu! Nie liczy się dla nas piękne CV i dekady doświadczeń w korpo – prawdziwa wiedza i doświadczenie oraz chęć i umiejętność szybkiego uczenia się – to jest to, co jest dla nas najważniejsze!

Więcej informacji i faktyczne wymagania znajdziecie tutaj.

Wiemy, że poprzeczka jest dosyć wysoko, ale nasz zespół w tej chwili potrzebuje osób, które faktycznie nie będą zostawały z tyłu w tym szybko zmieniającym sie i rozwijającym środowisku. W każdym razie postaramy się w miarę możliwości dać szansę każdemu kto spełnia przynajmniej kilka z wymienionych wymagań.

Widełki (bo przecież trzeba): 3000-8000 PLN (netto)
Zasady są proste – wynagrodzenie zależy od ilości spełnianych wymagań.

Miejsce pracy: Kraków
Umowa o Dzieło/Zlecenie lub B2B.

Jeśli macie jakieś pytania to dajcie znać.

 

 

1 komentarz więcej...

Definicja jakości

opublikowany przez 12, Maj, 2015, w kategoriach Agile, Jakość, Testowanie

5387711359_26983180a5_o

 

Definicji jakości oprogramowania powstało już wiele. Jedną z chyba najczęściej cytowanych ostatnio jest ta (chyba jej autor to Gerald Marvin (Jerry) Weinberg ):

„Quality is a value to some person”

Jakość jest tym co jest wartościowe dla kogoś. Czyli definicja jakości będzie się różniła w zależności od tego kogo o nią zapytamy.

James Marcus Bach dorzucił do tej definicji kolejne dwa słowa:

„Quality is a value to some person who metters”

Przecież w definicji jakości nie istotne jest zdanie każdego człowieka. Liczy się tylko zdanie osób które się liczą. Użytkowników, interesariuszy, sponsorów oprogramowania czy też osób wyznaczających trendy.

Ja do tej definicji dopisuję kolejny warunek:

„Quality is a value to some person who matters and it varies in time”

Jakość oprogramowania jest tym co ma wartość dla osób, które mają znaczenie i z pewnością będzie się to zmieniać w czasie.

Zmiana jest nieunikniona. Zmieniają się trendy na rynku, konkurencja wypuszcza kolejne, coraz lepsze rozwiązania, technologia się rozwija dając nam nowe możliwości. Ale przede wszystkim w miarę postępów pracy nad produktem i walidacji naszych założeń odkrywamy kolejne wartości i kolejne grupy osób które się liczą w definiowaniu jakości.

Podstawą jakości według mojej definicji jest możliwość ciągłego rozwijania i zmieniania oprogramowania przy stosunkowo stabilnych i przewidywalnych kosztach. W zasadzie to mając zapewnioną możliwość łatwego wprowadzania zmian w oprogramowaniu stosunkowo łatwo jesteśmy w stanie zapewnić dostarczanie wartości/jakości dla ludzi, którzy się liczą.

Warto pamiętać też że „liczące się osoby” z czasem też się zmienią…

2 komentarze więcej...

Trzech developerów – czyli krótka historia z morałem

opublikowany przez 09, Kwi, 2015, w kategoriach Agile, Automatyzacja, TDD, Testowanie, XP

5597863793_60f320a45d_o

Trzech programistów zostało zapytanych o to jak długo zajmie im przejście przez pole do domu?

Junior Developer popatrzył na dystans dzielący go od domu i powiedział: „Nie wygląda żeby było daleko  – zajmie mi to 10 minut”. 

Senior Developer popatrzył uważnie na pole i powiedział: „Powinienem być w stanie dotrzeć tam w ciągu dnia”. Oczywiście zdziwiło to Junior Developera. 

Ninja Developer popatrzył na pole i powiedział: „Wygląda na dziesięć minut drogi, ale myślę, że piętnaście minut będzie odpowiednią estymatą”

Junior Developer wystartował ale po kilku krokach wybuchła pierwsza mina zakopana na polu co sprawiło, że Junior Developer musiał zboczyć z najprostszej drogi. Po tym jak wielokrotnie musiał zawracać wysadzając po drodze kolejne miny, po dwóch dniach udało mu się dotrzeć do celu. Oczywiście nie obyło się bez ran.

Senior Developer od razu rozpoczął swoją podróż na czworaka uważnie sprawdzając każdy metr drogi i przemieszczając się tylko tam gdzie jest bezpiecznie. Oczwiście kilka razy natknął się na minę ale zdążył dotrzeć do celu w trochę ponad jeden dzień. 

Ninja Developer wystartował i spokojnie przeszedł przez pole do celu. Dotarł tam po dziesięciu minutach. 

Dwaj pozostali programiści zszokowani zapytali: „Jak udało Ci się to osiągnąć?”, „Jak przeszedłeś przez pole nie wysadzając żadnej miny?”

„To było łatwe” odpowiedział Ninja Developer – „Po prostu nie zakopałem tam tych min wcześniej”.

[znalezione na Quorze  i przetłumaczone na nasze]

Konkluzja: Emergent Architecture – fajna sprawa, ale warto czasem pamiętać o reużywalności i możliwościach rozwoju naszego kodu. Warto też mieć testy automatyczne, które przez takie pole minowe nas spokojnie, może trochę powoli, ale jednak bezpiecznie przeprowadzą.

 

 

Dodaj komentarz więcej...

Jeśli nie wiadomo o co chodzi…

opublikowany przez 10, Lut, 2015, w kategoriach Praca, Programowanie, Testowanie, Zarządzanie

…to chodzi o pieniądze…

Konkretnie o stawki w widełkach płacowych w ogłoszeniach o pracę. Już któryś raz spotkałem się z opinią, że ogłoszenia o pracę dla developerów/testerów/etc. powinny zawierać widełki płacowe. Oczywiście się z tym zgadzam. Ale ostatnio na grupie poświęconej testowaniu oprogramowania na Facebooku pojawił się też pomysł by widełki te nie były zbyt szerokie. Z perspektywy (dosyć świeżego) pracodawcy to mnie to troszeczkę ukłuło.

Co jeśli ktoś płaci ludziom faktycznie pomiędzy 2k a 10k PLN i to faktycznie zależy od umiejętności danej osoby? W Pragmatic Coders szukamy zarówno doświadczonych wymiataczy jak i osób ambitnych lecz jeszcze z niewielkim doświadczeniem, które maja duży potencjał. Ponadto zdarza się, że sporo osób z najwyższymi oczekiwaniami finansowymi (pytamy o to zanim zaprosimy kogoś na rozmowę) wypada dużo słabiej na rozmowach niż osoby z oczekiwaniami z pierwszej połowy widełek.
 
Sami zatrudniamy ludzi i stawki są naprawdę różne (może nie aż tak rozjechane, ale jednak) i faktycznie jest to w dużej mierze zależne od ich umiejętności. A raczej od tego jak dobrze wypadną na rozmowie/podczas rozwiązywania zadań rekrutacyjnych.
Jeśli chciałbym wrzucić widełki typu 8-10k to musiał bym podziękować większości kandydatów, których zatrudniliśmy bo najzwyczajniej ich umiejętności nie były dla nas tyle warte. Nie wiem też ile osób doszło by do wniosku, że są po prostu „za słabe” na takie pieniądze i by do nas nie napisało. Niemniej jednak dzięki temu, że nasze widełki są szersze pracujemy teraz z ludźmi z dużym potencjałem, których pensje odpowiadają ich umiejętnościom.
 
To co proponuję wszystkim malkontentom, którzy narzekają na brak czy niedokładność widełek to aby podawali swoje oczekiwania finansowe w przesyłanych CV. Wystarczy zrobić tam dopisek, żeby pracodawcy nie zawracali nam głowy jeśli uważają, że na podstawie CV/profilu na linkedIn/20 minut rozmowy przez telefon nasze umiejętności nie są dla nich tyle warte, lub jeśli w ogóle nie są w stanie tyle zapłacić komuś na tym stanowisku. Z mojego doświadczenia – takie coś w zasadzie eliminowało temat pieniędzy podczas dalszych rozmów lub było to dogadywane z różnym skutkiem na samym początku komunikacji. I pisze to zarówno z perspektywy kandydata jak i pracodawcy. 
 
Oczywiście moja propozycja nie wyklucza potrzeby widełek w ogłoszeniach. To tylko pewna propozycja rozszerzenia netykiety dla wspólnego dobra pracodawców i kandydatów. 
 
Z trzeciej strony jeśli dla kogoś jedynym powodem do tego by z nami współpracować miała by być kasa, to nie jestem przekonany czy wszyscy będziemy docelowo z takiego układu zadowoleni.
Osobiście gdy, kiedyś szukałem pracy to uważałem, że podanie moich oczekiwań płacowych na początku kontaktów (w CV, pierwszym mailu, przez telefon) to po prostu pragmatyczna oszczędność czasu osoby rekrutujące ale także przede wszystkim MOJEGO… Także szczerze polecam taki sposób komunikacji – także z nami gdybyście programowaniem w Pythonie byli zainteresowani.

4 komentarze więcej...

Podsumowanie Quality Excites 2014

opublikowany przez 02, Cze, 2014, w kategoriach Coaching, Jakość, Konferencje, Testowanie

qe

W sobotę miała miejsce już trzecia edycja darmowej konferencji Quality Excites 2014 w Gliwicach, organizowanej przez firmę Future Processing. Uczestniczyłem w tym wydarzeniu jako prelegent po raz trzecie – dzięki temu miałem okazję od samego początku przyglądać się temu jak rozwija się samo wydarzenie jak i firma je organizująca.

Może zacznijmy od organizatorów – nie wiem za wiele o FP bo nigdy tam nie pracowałem, ale znam tych ludzi i wiem, że jakość ma dla nich znaczenie. Teraz odwiedzając ich biuro mogłem zobaczyć postępy jakie poczynili. Gdy dwa lata temu byłem tam po raz pierwszy to w miejscu obecnego kompleksu biurowego była dziura w ziemi. W tej chwili stoi tam nowoczesny kompleks biurowy z kantyną, siłownią, centrum spa, zjeżdżalniami(!) i wieloma innymi fajnymi rzeczami wspierającymi kreatywną pracę. Niewiele jest w naszym kraju firm zdających sobie sprawę z tego, że ich największym kapitałem są ludzie i ich wiedza, a do tego jeszcze inwestujących w ten kapitał nie ilościowo ale jakościowo.

O samej konferencji można by napisać wiele. Zacznę od tego, że jest to jedyna (znana mi) konferencja w tym kraju, na której testerzy i programiści mówią tym samym językiem. Jest to wydarzenie skierowane zarówno do testerów, programistów, managerów, analityków poświęcone jednemu – bardzo ważnemu tematowi: szerokiej jakości oprogramowania. W programie znalazły się prezentacje zarówno o testowaniu, automatyzacji testów, wymaganiach, metrykach jak i praktykach  i narzędziach developerski. A wisienką na torcie był wykład o tym Kim jest Agile Coach według Krysitana Kaczora zamykający konferencję.

Oprócz wykładów, równolegle odbywały się niesamowicie ciekawe warsztaty prowadzone przez praktyków z Future Processing. Najciekawsze były oczywiście rozmowy w kuluarach i podczas afeter party. Spotkałem wielu starych znajomych i poznałem jeszcze więcej nowych. Zaskakująco miło mi, gdy ktoś w rozmowie odnosi się do tematów, o których mówiłem na poprzednich konferencjach i innych wydarzeniach. To znaczy, że to co robię ma jakieś znaczenie i nie ginie w przestrzeni – zostaje w głowach przynajmniej jednostek, które z sukcesami stosują tą wiedzę w praktyce.

Future Processing z Quality Excites byli chyba pierwsi jeśli chodzi o niekomercyjne wydarzenia tego typu, organizowane na taką skalę. Na szczęście tego typu imprez oraz różnych mniej lub bardziej lokalnych grup entuzjastów jakości przybywa co przekłada się na realne postępy w dziedzinie jakości oprogramowania.

Na koniec jeszcze kilka słów na temat wspomnianego wykładu Krystiana Kaczora – już dawno nie widziałem wykładu na interesujący mnie temat, z którym bym się tak bardzo zgadzał. Sam jakiś czas temu miałem podobne przemyślenia – więcej tu i tu. Tym bardziej cieszę się, że Krystian dołączył do naszego zespołu trenerów w Code Sprinters.

18 komentarzy więcej...

Coding Dojo – TDD Kata

opublikowany przez 31, Mar, 2014, w kategoriach Agile, Automatyzacja, CI, TDD, XP

Kanji-shu-ha-ri507
Kilka tygodni temu miałem przyjemność poprowadzić dla jednego z moich klientów krótki warsztat w formie Coding Dojo. Na codzień z tymi zespołami pracujemy nad wdrożeniem Continuous Delivery oraz innych praktyk związanych z Agile. Dojo nie było częścią regularnego Agile Coachingu, ale pomyśleliśmy, że może być dobrą formą oderwania się od codziennej pracy, wyjścia ze strefy komfortu i nauczenia się czegoś nowego. I tak też chyba się stało.

Po pierwsze czym jest Coding Dojo?

Dojo to termin pochodzący z języka japońskiego oznaczający „miejsce treningu”. Odnosił się on do trenowania sztuk walki takich jak Kendo czy Aikido. Nie jest to zwykła sala treningowa, gdyż obowiązują na niej pewne zasady, wchodząc do Dojo zgadzamy się postępować zgodnie z obowiązującymi tam normami.

Coding Dojo to również miejsce gdzie chcemy potrenować nie tyle sztuki walki co sztuki tworzenia kodu. Tutaj też obowiązują pewne zasady, o których za chwilę…

Podczas Coding Dojo zgromadzeni programiści próbują rozwiązać określony problem. W naszym przypadku podeszliśmy do problemu „String Calculator” – prosty kalkulator obliczający sumę parametrów podanych na wejściu. Backlog do tego zadania udostępniłem tutaj.

Zasady

Dojo zorganizowaliśmy w formie TDD Kata oraz podzieliliśmy je na 4 iteracje. Każda iteracja to 30 minut kodowania, 6 minut na code review i 6 minut na wspólną retrospekcję.

Uczestnicy programowali w parach. Po każdej iteracji zmiana pary, poniżej więcej na ten temat.

W przeciwieństwie do typowego Code Retreat po każdej iteracji nie usuwaliśmy wytworzonego kodu tylko kontynuowaliśmy poprzednio zaczętą pracę.

Przebieg Coding Dojo

Pierwsza iteracja to dla większości uczestników pierwsze kroki w TDD (niektórzy mieli już pewną wprawę, niemniej jednak przypomnienie zasad każdemu się przydało) – programujemy zgodnie z zasadą Red -> Green -> Refactor. Co 3 minuty zmienia się osoba przy klawiaturze – to wymuszało komunikację. TDD Kata to ćwiczenie służące do doskonalenia swoich umiejętności.

Po blisko pół godziny tworzenia kodu przyszedł czas na Code Review, ze względu na to, że było około 20 osób postanowiliśmy, że w ramach Code Review wymieszamy pary, praca każdej pary musiała zostać przejrzana przez kogoś z innej pary. Ta praktyka pozwoliła bardzo szybko pokazać różnice pomiędzy parami i poszczególnymi uczestnikami, a następnie pozwoliła wymienić się zdobytą wiedzą i spostrzeżeniami.

I oczywiście wspólna retrospekcja, podczas której rozwiewaliśmy wszelkie wątpliwości i omawialiśmy problemy oraz spostrzeżenia.

W drugiej iteracji wprowadziłem dwie zmiany – po pierwsze postanowiliśmy stosować TDD ping-pong. Jest to metoda programowania w parze polegająca na tym, że pierwsza osoba pisze test, druga pisze funkcjonalność spełniającą ten test, pierwsza refaktoryzuje, druga pisze test itd. To ćwiczenie pozwoliło uczestnikom lepiej dostrzec różnice pomiędzy poszczególnymi etapami w pętli TDD, oraz to czym się różni TDD od Test-First.

Drugą zmianą (nie do końca w mojej ocenie udaną, powinienem zostawić to na trzecią iterację) był zakaz rozmawiania podczas kodowania. Znacznie lepiej było by, gdybyśmy wprowadzili to w następnej iteracji, po tym jak już uczestnicy opanowali podstawy pętli TDD. Celem wprowadzenia tej zasady było wymuszenie pisania na tyle czytelnego kodu by druga osoba mogła łatwo zrozumieć intencje. Niemniej jednak było to całkiem zabawne nawet pomimo tego, że jeszcze nie wszyscy zrozumieli dobrze zasady TDD w tej iteracji. Braki nadrobiliśmy w kolejnej.

Trzecia iteracja po Code Review i Retrospekcji była podobna do poprzedniej z tą różnicą, że teraz można było już rozmawiać. To zaowocowało ożywionymi dyskusjami, oraz dzieleniem się pomysłami, które nagromadziły się w poprzedniej iteracji, oraz podczas Code Review. W efekcie było dużo refactoringu.

Iteracja czwarta – „porzuć swój kod”. Ponieważ w życiu programisty bardzo często bywa tak, że musi grzebać się w kodzie, którego sam nie tworzył postanowiłem podczas naszego Coding Dojo również zrobić taki eksperyment. Tym razem zasada przy dobieraniu się w pary była prosta – wszyscy wstają od komputerów przy których siedzą i starają się dobrać w pary z kimś z kim jeszcze nie programowali oraz wspólnie usiąść przy komputerze przy którym jeszcze nie siedzieli.

Była to chyba jeden z najciekawszych eksperymentów jaki przeprowadzałem na ludziach (i ich kodzie) ;-). To niesamowite jak bardzo różnie można zaimplementować te same funkcjonalności oraz na jak wiele różnych pomysłów można wpaść w zależności od tego z kim się pracuje. Podczas tej iteracji niektórzy zawzięcie refaktoryzowali (pamiętając o zasadach TDD) inni starali się dodawać nowe funkcjonalności przyjmując zastane konwencje.

W ramach przedłużonego Code Review po tej iteracji poprosiłem by wszyscy wracali do wszystkich komputerów, przy których mieli okazję wcześniej pracować i dokładnie przejrzeli co stało się z „ich” kodem odkąd opuścili to miejsce (nie tylko w ostatniej iteracji ale także w poprzednich).

Wnioski

Pojawiło się kilka ciekawych pytań i wniosków oto kilka z nich:

„Tworząc kod w ten sposób widzę, że implementując w sumie prosty problem poprzez stosowanie TDD wydłużył się czas implementacji oraz tak na prawdę spadła jakość tego co zrobiłem – gdybym nie stosował TDD to zrobił bym to szybciej i lepiej”. 

Moja odpowiedź brzmiała: Tak! Gdybyś dzisiaj to zaimplementował bez TDD to zrobił byś to ładniej (i może nawet napisał byś testy). Niemniej jednak w TDD Kata chodzi właśnie o dążenie do perfekcji i doskonalenie swoich umiejętności. Tego typu ćwiczenia wykonujemy właśnie po to, by za którymś razem napisać ten kod jeszcze lepiej i szybciej używając TDD, gdyż ta metoda ma wiele innych zalet, które warte są poświęcenia czasu potrzebnego na jej dobre opanowanie.

„TDD jest proste, gdy tworzymy nową funkcjonalność – a co jeśli mam już sporo kodu i to nawet z testami i nagle przychodzi zmiana wymagań. Co jeśli mam na przykład 5000 testów? Mam teraz szukać i zmieniać wszystkie testy zanim wprowadzę zmiany?”

Moja odpowiedź: jeśli wiesz, które testy trzeba zmienić i możesz to w miarę prosto i szybko zrobić to to zrób. Jeśli nie wiesz to… napisz nowy test, wprowadź testowaną zmianę w zachowaniu aplikacji, odpal testy i zobacz które testy przestały przechodzić. Potem zastanów się czy testy, które przestały przechodzić zrobiły to. bo zmieniło się zachowanie, czy dlatego, że coś zepsułeś. Następnie przemyśl, czy poprawiając testy przypadkiem nie duplikujesz tych, które przed chwilą napisałeś. Jeśli nie, to zastanów się, czy zmiana w funkcjonalności, którą wprowadziłeś nie była przypadkiem zbyt duża i nie miała jeszcze innych niechcianych konsekwencji. Jeśli wszystko jest ok, to powtórz powyższą pętlę aż wprowadzisz wszystkie zmiany.

Moja ogólna rada – nie bójcie się czerwonych testów. One właśnie po to są by często nie przechodziły i pokazywały Wam status systemu. Jeśli zastosujecie zasady z Clean Code oraz dobrze przemyślicie swoje testy to analiza tego dlaczego nie przechodzą będzie łatwa i przyjemna, a co za tym idzie wniesie to znaczną wartość do Waszej pracy.

Reasumując

Coding Dojo w tej formie jest w mojej ocenie bardzo fajnym ćwiczeniem wartym polecenia każdemu zespołowi. Przedmiotem Dojo wcale nie musi być TDD Kata – możecie spróbować zmienić się z zupełnie innym problemem nawet niekoniecznie programistycznym. Najważniejsze jest to, by wykonywane ćwiczenia wnosiły jakąś wartość i pozwalały Wam poszerzyć wiedzę.

Dojo, które przeprowadziłem z zespołem B&T Skyrise miało na celu przede wszystkim poszerzenie wiedzy na temat TDD oraz nabranie wprawy w praktykach Code Review. Myślę, że cel został osiągnięty.

PS: Niezmiernie ciekawi mnie, czy któryś z uczestników spróbował później podejść do samodzielnego rozwiązania jakiejś TDD Katy… Sprawdzę to przy najbliższej okazji.

1 komentarz więcej...

Quality Excites – się kręci…

opublikowany przez 17, Mar, 2014, w kategoriach Jakość, Konferencje, Testowanie

qe

Jak co roku zachęcam Was do wzięcia udziału w Quality Excites. Miałem przyjemność uczestniczyć w Quality Excites od samego początku kiedy to w 2012 roku zostałem zaproszony jako jeden z kilku prelegentów. Od tamtego czasu wydarzenie rozrosło się i stało się jednym z najważniejszych miejsc na mapie i w kalendarzu naszego krajowego testowania i jakości oprogramowania. Co roku staram się jak mogę wspierać inicjatywę oraz dzielić się z uczestnikami swoim doświadczeniem.

W tym roku jakością będziemy się ekscytować 31 maja jak zawsze w Gliwicach.

Jeśli chcieli byście podzielić się jakimś ciekawym tematem to Call For Papers już wystartowało i potrwa do końca marca. Szczerze zachęcam do zgłaszania prezentacji, gdyż wiem, że wielu czytelników mojego bloga ma się czym pochwalić! (Poza tym ileż można ciągle oglądać te same twarze – w tym moją :P).

Swoją drogą jeśli sami nie czujecie się na siłach by coś opowiedzieć to może chcieli byście bym ja odpowiedział na jakieś Wasze pytania albo szerzej omówił któryś z tematów prezentowanych przeze mnie na blogu lub gdzieś indziej? Nie to żebym sam nie miał pomysłów, ale zawsze lepiej się opowiada mając świadomość, że gdzieś tam na widowni jest przynajmniej jedna osoba, którą dany temat interesuje :).

Zapraszam do podzielenia się propozycjami pod postem lub na facebooku.

4 komentarze więcej...