Nowy rok, nowe postanowienia

Zmienił się rok, niby nic specjalnego, ot, umowna data kiedy to wszyscy mamy być szczęśliwi i radośni aby później blogi mógł zalać potok sukcesów w zeszłym roku i postanowień na Nowy Rok.

Moje postanowienia są osobiste, więc nie będę się nimi tutaj dzielił, sukcesy i porażki – no cóż, przez moją opieszałość w pisaniu minął czas i teraz to musztarda po obiedzie. Dzisiaj mamy najbardziej depresyjny dzień roku, kumulacja złamanych noworocznych postanowień z nadchodzącym terminem płatności kredytówek (czyżby przypadkiem płatność za okres obejmujący święta?) czyli blue monday. Z tej okazji zdradzę mój tajny, super sekretny sposób na dotrzymywanie postanowień noworocznych dzięki któremu zarobiłem miliony spełniłem 9 z 14 zeszłorocznych postanowień. Całkiem niezły wynik szczególnie, że przepis jest super prosty.

Właściwie składa się z 2 rzeczy.

1) Zapisz postanowienia noworoczne. Jak do wszystkich list tak i do tej używam Wunderlist, który się synchronizuje ze wszystkim co się rusza więc zawsze swoje listy mam przy sobie.

2) Ustaw w kalendarzu comiesięczne przypomnienie, że należy sprawdzić listę postanowień. Używam do tego google calendar z przypomnieniami na sms.

Tyle i aż tyle. Zapisanie postanowień powoduje, że jasno i klarownie mamy napisane co chcemy uzyskać. Bez ściemy, że się coś zapomniało. Sami przed sobą możemy się rozliczyć. Drugi krok po prostu nie pozwala zapomnieć. Co miesiąc mamy przypomnienie i możemy wykreślić to co zostało zrealizowane a co nie, oraz co ważniejsze skorygować kierunek i usunąć te postanowienia, które są bez sensu. Wiadomo, takowe się trafiają; czasem życie weryfikuje listę i niektóre wypadają. Nie ma co nad nimi płakać.

Jeśli już złamałeś/aś swoje postanowienia noworoczne (a wg. statystyki tak właśnie jest) to proponuję 1 lutego zrobić nową listę. 1 luty ma tę przewagę nad 1 stycznia, że nie masz kaca, dzień jest dłuższy a i miesiąc jakby trochę krótszy. Poza tym, ten dzień nie jest bardziej lub mniej szczególny niż 1.01.RRRR+1

TDD is dead czyli telenowela dla jajogłowych

David H Hannson, autor Ruby on Rails opublikował artykuł: http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html no i poszło… mleko się rozlało. Burza większa niż o sosnę (tą rozdartą – nie o brzozę, brzozy są niepolityczne).

tdd

Uncle Bob napisał http://blog.8thlight.com/uncle-bob/2014/05/11/FrameworkBound.html ale jak wieść gminna niesie to jest wersja politycznie poprawiona bo czyjeś uczucia religijne zostały obrażone – oryginalna wersja jest jeszcze w feedly i/lub cache googla. Generalnie wydarzyło się to tak szybki, że zanim przeczytałem artykuł to był już zmieniony – dobrze że koledzy z zespołu mi o tym powiedzieli bo dzięki nim przeczytałem oba te teksty.

Potem wielka debata Is TDD Dead z Martinem Fowlerem, Kentem Beckiem i Davidem Hannsonem, o której chyba pół internetu grzmiało (https://plus.google.com/events/ci2g23mk0lh9too9bgbp3rbut0k).

Następny odcinek czyli DHH problem http://codon.com/the-dhh-problem

W pracy pół poniedziałku TDD i tego samego dnia polska grupa celebryto.netowa wciągnęła się w telenowelę.

learn to use tdd

Co będzie dalej, gdzie ta telenowela się skończy? Podobno – znowu wieść gminna niesie że w 4 odcinku debaty Fowler – Beck – Hannson ma się okazać, że DHH jest synem (lub ojcem) Uncle Bob-a.

lodowka

Ci co oglądali South Park i pamiętają odcinek z piekłem i niebem wiedzą, że prawidłowa odpowiedź przyjdzie po śmierci (spoiler:  mormoni). Dla mnie na tą chwilę faktem jest to, że TDD jest trudne do ogarnięcia, ale nie trudne w podstawach bo te są łopatologicznie proste. Można je ogarnąć w kilka godzin czy dni. Problem jest taki, że wymaga to olbrzymiej determinacji od programisty oraz ciągłego trzymania się metodyki. Linijka po linijce, kawałek po kawałki dzień po dniu nabierać trzeba doświadczenia w TDD. Dzięki temu już po kilku latach jest szansa, że będziemy mieli wyczucie, kiedy używać TDD a kiedy nie, kiedy pisać wór testów na jedną mała klasę a kiedy napisać 5 testów na wór klas. Unit Testing testuje UNIT czyli jednostkę – jednostka to nie 1 klasa  czy 1 metoda, to może być zbiór klas. Żeby to czuć, kiedy iść w tą a kiedy w inną stronę to trzeba mieć dużo doświadczenia. Wydaje mi się, że czuję to, po ponad 4 latach z TDD (w różnym natężeniu), wydaje mi się, że to potrafię mimo, że jest jeszcze masa do nauczenia przedemną. Jedno jest pewne, TDD nie tworzy architektury i jej nie polepszy. TDD jedynie może zdegradować architekturę jeśli postawimy ołtarzyk tej metodyce. TDD to świetne narzędzie, które wymaga wprawy i umiejętności użycia.

Wg. mojej percepcji świata, TDD to przyszłość, to potężna umiejętność i warto w to inwestować. Jeśli mam rację to super, bo wszyscy przeciwnicy TDD odpadną z rynku i będzie jeszcze więcej miejsca. Jeśli się mylę, no cóż, zawszę mogę usunąć testy i wrócić do mozolnego „przeklikiwania” kodu lub zostać skrytym anonimowym tdd-owcem. Życie pokaże. Tymczasem czas iść do lodówki i mieć nadzieję, że telenowela tam nie zawitała, mieć nadzieję, że ostatni bastion spokoju u chłodu ostał się.

Połowę czasu spędzamy w pracy

We wpisie o sprzeczności interesów pracodawca-pracownik napisałem, że spędzamy połowę życia w pracy.  Zakładając 8h snu pozostaje 16h “świadomego życia” z tego 8h w pracy ale przecież od poniedziałku do piątku, i jeszcze są święta no i urlop – jak wyliczył Paweł 250 dni pracujących – 26 dni urlopu (do tego jeszcze możemy mieć 2 dni opieki etc). Wszystko się zgadza…

… z tą drobną różnicą, że praca to nie 8h. Do tego trzeba doliczyć czas dojazdu – w obie strony. Czyli jeśli wyjście z domu, odpalenie samochodu, przetransportowanie się do firmy oraz zaparkowanie zajmuje tylko 30 minut w jedną stronę, to tak naprawdę czas pracy to 9h (zakładam, że trzeba jeszcze wrócić). W tygodniu to dodatkowe 5h z życia wyjęte. Co więcej, transport kosztuje, czy to czas jeśli idziemy pieszo, czy czas i pieniądze jeśli jedziemy autobusem/autem/rowerem. Jeśli używasz jakiegokolwiek środka transportu to ten środek transportu wymaga pieniędzy – paliwa, przeglądów, napraw – i to są dodatkowe koszty na które trzeba zapracować. Czyli albo pracujemy 8h ale część tego czasu poświęcamy na opłacenie kosztów dojazdu albo pracujemy więcej.

Praca zawodowa to nie wszystko!

Niezbędną pracą, którą musimy wykonywać regularnie to również zakupy, sprzątanie, mycie i wszystko to co jest związane z obsługą samych siebie i rodziny. Policz ile czasu poświęcasz tygodniowo na zakupy, chodzenie do urzędów, lekarzy i innych placówek, które trzeba odwiedzić. W skali roku nazbiera się tego całkiem sporo. Jak to zebrać wszystko razem to obawiam się, że z tego świadomego życia  połowa chyba nawet nie wychodzi. Ilość rzeczy, które na prawdę musimy zrobić jest spora więc ważne aby pozostały czas wykorzystywać bardzo rozsądnie, w końcu mamy go niewiele – bardzo niewiele.

Jak sobie z tym poradzić?

Hm….. nie pchać się w bezsensowne aktywności, które marnują nasze zasoby a nie wzbogacają nas zbytnio. To co MUSIMY MUSIMY ograniczać w miarę możliwości do minimum i…… no właśnie, co jeszcze?

Pracownik pracodawca – sprzeczność interesów

Dzisiaj nie technicznie jednak temat bardzo ważny bo przecież połowę życia spędzamy w pracy.

Tak połowę. Czas to najcenniejszy zasób jaki mamy (najcenniejszy asset jeśli pracujesz w korpo). Doba dla wszystkich ma tyle samo godzin, minut i sekund. Nikt na ziemi nie dostał go mniej lub więcej, wszyscy dokładnie tyle samo, jak w komunie. Z tego jakieś 8h zużywamy na spanie – średnio 8h bo jedni śpią mniej inni więcej ale Ci z białych fartuchach mówią, że 8 jest zdrowo. Zatem pozostaje 16h dobo/życia. Z tego teoretycznie 8h spędzamy w pracy czyli połowę świadomego dobo/życia. Połowę, życia w pracy!!!! No i teraz pytanie, czy chcesz spędzić ten czas w kiepskiej atmosferze, która wysysa Twoje soki życiowe? Gdzie rano wstając mówisz, że idziesz do roboty a po południu jesteś tak wypompowany, że jedyne na co możesz sobie pozwolić to włączenie 4 sezonu mody na sukces i powolna wegetacja? Dość grubo, na szczęście takich sytuacji jest bardzo mało i myślę, że większość ludzi ma radar na takie patologie co jednak z miękką wersja?

Chciałbyś poznać async/await ale nie możesz bo nie możemy przejść z projektem na frameworka wyższego niż 2.0?

Chciałbyś pojechać na konferencję ale nie możesz bo….. wiesz dużo pracy, może w przyszłym roku.

Chciałbyś zacząć pracę z TDD ale nie możesz bo my mamy inny charakter pracy (!!??!)

Chciałbyś wprowadzić Scrum-a ale nie możesz bo “ludzie będą się czuć przesłuchiwani”.

Można mnożyć, ale wiadomo o co chodzi. Jakoś tak jest, że zaczynając przygodę z firmą/zespołem, wszystko na początku wygląda super, ale z czasem pojawiają się różne taki kwiatki. Tutaj właśnie pojawia się sprzeczność interesów z tematu tego posta. Należy sobie uświadomić, że żaden pracodawca (bez względu czy to praca na etat czy inny rodzaj współpracy) nie będzie nas głaskał po głowie i zawsze pozwalał na wszystko co chcemy albo lepiej, ciężko takich znaleźć. Zbieżność naszych zawodowych/rozwojowych interesów jest czasowa z tym czego chce pracodawca. I nie ma w tym niczego złego. To tak działa. Nie można mieć za złe pracodawcy, że np. nie przechodzi na wyższego .net-a (czy inną Javę czy cokolwiek, wstaw tutaj co chcesz) bo przez to odciął by się od np. kluczowych klientów. Nie można mieć również za złe pracownikowi, że chce użyć czegoś nowszego.

Moja teoria na ten temat jest taka, wchodząc do zespołu nasze własne interesy powinny być maksymalnie zbieżne z interesami zespołu, dzięki temu będzie się wszystkim świetnie pracowało. Należy mieć jednak świadomość, że pewnie za 2-5 lat te interesy się rozejdą. Wtedy nie czas na marudzenie, że nie chcą nas wysłać na takie czy inne szkolenie i że nie możemy użyć tego czy tamtego (mimo, że może to są lepsze technologie). Wówczas nadchodzi czas na zmianę otoczenia. Jeśli oddamy się w ręce pracodawcy, to do momentu, aż będziemy mu potrzebni będziemy grać jak nam każe. W naszym zawodzie wątpliwe jest abyśmy tak zdołali dociągnąć do ciepłej emeryturki. Jest większa szansa, że pewnego dnia zostaniemy wyrzuceni jak zużyty sprzęt. Dlatego, bierz swój los w swoje ręce. Ucz się tego, co chcesz i co uważasz za przydatne i pamiętaj, że współpraca z firmą jest tymczasowa. Jeden pracodawca w tej branży dłużej niż 10 lat wymaga poważnego “reality chceck”. Może trafiłeś idealnie i jesteś szczęśliwy a może wygoda i pozorna stabilność uśpiły Twoją czujność.

DevDay DevDay i po DevDay-u

Było, mineło… teraz trzeba czekać kolejny rok na najlepszą konferencję w Polsce. Tymczasem małe subiektywne podsumowanie.

W zeszłym roku marudziłem na niewygodną do czytania agendę na zawieszce i brak kontaktów (gniazdek), teraz nie mam do czego się przyczepić. Gniazdka były, lud korzystał w miarę potrzeb i nie było problemu. Agenda na zawieszce też czytelna i nie trzeba było obracać jakoś specjalnie ot podnosisz smycz i czytasz co tam leci dalej. Bomba. Wiem, że to są pierdoły ale psujące UX.

Z nowości, świetny pomysł z bananami. W ogóle jedzenie bardzo mnie pozytywnie zaskoczyło, wołowinka na konferencyjnym cateringu – mioodzio (podobno były też ryby i coś dla wegan). Kolacja to już w ogóle kosmos. Nie widziałem takiej na żadnej konferencji, jedynie na jakiejś konferencji prasowej czy loży dla tzw. vipów/prelegentów/wystawców ale dla “ludu” już nie. KUDOS!!!

Jednak nie po jedzenie tam przyjechaliśmy. Piwo…

Wykłady czyli dev mięso

Otwarcie to John Skeet czyli legenda Stack Overflow-a i C# a z nim Tony The Pony. Dla mnie wystarczył by ten jeden wykład aby tułać się o 5 rano z domu autobusami. Mistrz na scenie i to zarówno ze względu na wiedzę jak i na umiejętności oratorskie (w końcu pastor). Wykład dosyć miękki, nie odkrywający tajemnicy wszechświata jednak dosyć podstawowy dla każdego programisty – typy danych i jak to właściwie sami sobie wszystko komplikujemy…. podane lepiej niż filet mignon w najlepszej restauracji. Potem Patric Kua – i dosyć podstawowy wykład o Continuos Delivery. Chciałbym z takim spokojem i lekkością umieć poprowadzić wykład, merytorycznie jakoś nie znalazłem nic odkrywczego ale uważam, że dla kogoś kto nie czytał/nie miał styczności z CD to mógł być bardzo wartościowy wykład. Dalej, Andreas Håkansson czyli TheCodeJunkie. Bardzo czekałem na ten wykład i nie zawiodłem się. Znowu technicznie nic odkrywczego bo Andreas pokazywał to co c# oferuje “out of the box” jednak pokazał kilka bardzo fajnych zastosowań dynamic-a, implicit casting i marker interfaceów. Materiał bardzo fajny i dla mnie bardzo przydatny jako natchnienie do niektórych projektów.

Kolejny wykład, na który bardzo czekałem to Hadi Hariri z “Moving the Web to the client”. Chyba największe rozczarowanie. Hadi pokazał Angular.js oraz webapi w wersji kotlin + wasabi. Rozczarowanie dlatego, że aktualnie trochę z tym pracujemy więc znowu nic odkrywczego ale co z tego. Hadi nie mógł wiedzieć, że to już wiem i jestem przekonany, że sporo osób wyniosło coś dla siebie z jego sesji. Dla mnie wykład mimo wszystko świetny a to ze względu na sposób przedstawienia całości. Po prostu Hadi jest lepszy od większości kabaretów. Przy okazji, siedząc kilka foteli od John-a Skeeta widziałem, jak tworzył legendę – jak odpisywał na Stacku. (tak wiem, nieładnie patrzeć przez ramie).

Kolejny to wykład, Itamar Syn-Hershko i full-text search z Lucene. Miałem nadzieję, na więcej kodu i jak to to ugryźć, żeby potem użyć u siebie. Wstęp teoretyczny do full-text-a bardzo fajny ale potem odpadłem na Elastic Search i przesiadłem się do drugiej sali na końcówkę Paul-a Stack-a i jego Windows – having its ass kicked by Puppet and PowerShell. Trudno mi powiedzieć coś o całym wykładzie skoro widziałem drugą połówkę. Mimo tego, widzę to tak, puppet może pięknie zautomatyzować środowisko i wydaje się fajną alternatywą ale nie podoba mi się sposób konfiguracji (z tego co widziałęm). Fajnie że Paul wspomniał http://chocolatey.org/ i nie sprzedawał na siłę Puppeta. To co dla mnie najważniejsze, co zdążyłem wyciągnąć to przechowywanie konfiguracji w repo i stawianie maszyn od zera ale z nową konfiguracją zamiast gmerać w nich. Ciekawe czy uda mi się to kiedyś wdrożyć Puszczam oczko

Kolejny wykład to był zgryz, czy Dino Esposito – legenda czy Marco Cecconi i architektura StackOverflow-a. Wygrała chęć zobaczenia jak to “u nich” działa i poszedłem na “The Architecture of StackOverflow’”. OMG ~64 miejsce pod względem ruch w stanach i 16 w Polsce. Miliony użytkowników i jeszcze większe ilości postów. Chleb powszedni devów – StackOverflow działą na ~25 serwerach (dwa prawie nic nie robią, jakiś ekstra do bazy danych, 2 redisy, chyba 11 iis-ów) i tyle a jak to powiedział Marco, w sumie 5 by chyba to uciągnęło. Solution składające się z 9 projektów, 1 testowy z ~250 testami. WOW! Jak powiedział, problemy z jakimi się stykali spowodowały, że większość kodu to statyczne metody i taka a nie inna struktura kodu. Serio – nie spodziewałem się tego. I co najciekawsze – “the John Skeet problem” (co znowu oderwało Johna od pisania na stacku – tak był na tym wykładzie). Problem polega na tym, że jeśli The John Skeet pierwszy wywoła jakieś zapytanie to Sql trochę inaczej buduje plan zapytania – pod Johna, który trochę odbiega od statystycznego użytkownika Puszczam oczko. Generalnie wszystko działa ale “normalnym” system działa koszmarnie nieefektywnie. Ot trzeba ręcznie usunąć plan i jak odpowiedział Marco na pytanie z sali, nie nie mają if( “John Skeet” w kodzie. Swoją drogą to po tym wykładzie padło chyba najwięcej pytań z sali.

Na koniec wisienka. Rob Ashton poopowiadał o ostatnim roku jego życia. Czytający jego bloga wiedzą o co chodzi. Ja nie będę pisał o czym był wykład żeby nie psuć odbioru jak już się pojawią filmy (pojawią się?). Generalnie wulkan energii i doświadczenia.

Na koniec jeszcze meksykańska fala x2, wspólna fotka (jakiś 300 osób) i fajrant.

Część nieoficjalna.

Piwko, kolacja, jeszcze jedno piwko i “soszalajzing”. Dane mi było poznać kilka osób, które znałem jedynie z twittera czy z blogów, to niesamowite zobaczyć ich “live” – oni istnieją. Się porozmawiało, powygłupiało generalnie energia bijąca od organizatorów udzieliła się chyba wszystkim. Po ostatnim DevDay-u wróciłem z głową pełną pomysłów i pełen energii, tym razem również naładowałem dev akumulatory, kilka pomysłów się po głowie kołacze, generalnie “they did it again”.

Czy jest coś co mi nie odpowiadało? Hm….. chyba jedynie to, że były dwie ścieżki i musiałem wybrać na co iść ale lepiej tak niż z 7 ścieżek nie mieć gdzie się podziać.