5 błędów początkującego blogera

Jeżeli mój poprzedni wpis o zaletach blogowania zainspirował Cię do założenia własnego bloga albo już wcześniej chodził Ci po głowie pomysł założenia to jest pięć rzeczy, które musisz wiedzieć. Poznaj 5 błędów popełnianych przez osoby zaczynające blogowanie. Te 5 błędów bardzo często powoduje, że blogi jak szybko powstają tak samo szybko umierają ze szkodą dla ludzkości 🙂 Taką szkodą, że mogły by się tam pojawić bardzo wartościowe przemyślenia – ale się nie pojawią bo osoba prowadząca utknęła – najczęściej – na przynajmniej jednym z poniższych problemów….. serio, widziałem to kilkanaście razy, ktoś stwierdził, że zacznie pisać, a potem…. no cóż….

Kiedy zacząć prowadzić bloga

No właśnie, kiedy? Niektórzy mówią, że blogosfera już umarła, że teraz videło, jutuby i inne tego typu wynalazki bo milenialsi to pokolenie obrazkowe. Serio? Ale serio? Fajnie się ogląda vlogi i filmiki ale jeśli potrzeba konkretnej wiedzy to jednak tekst jest wygodniejszy do konsumpcji, łatwiejszy do wyszukania, łatwiejszy do szybkiego przeglądnięcia, do szybkiego przeczytania. I nawet źli osławieni milenialsi czytają. Tekst nie umarł, dlatego i blogi nie umarły. Zresztą zastanów się przez chwilę, ile treści odnośnie programowania konsumujesz w postaci video a ile w postaci blogów i artykułów tekstowych o programowaniu? No właśnie…

Blogi nie przeminęły, słowo pisane nie przeminęło. Jeśli chcesz założyć bloga to to zrób, tu i teraz. Otwórz nową zakładkę w przeglądarce i załóż. Nie ma co czekać na poniedziałek, pierwszy dzień miesiąca czy nie daj boże roku. Tu i teraz jest najlepszy czas. Lepszy czas już był 5, 10 lat temu. Jeśli serio chcesz założyć bloga to nie odkładaj tego – pora działać.

Wybór platformy blogowej

TL;DR; Wordpress.

Nie zastanawiaj się, czy lepszy jest wordpress czy joomla, czy może drupal, a może ghost, a może samemu coś by się dało napisać. Żadne własne wynalazki się nie sprawdzą. Serio… Zbudowanie porządnej platformy do blogowania to zadanie na pełny etat. Trzeba pomyśleć o bezpieczeństwie, o SEO, o wygodzie czytelnika i milionie innych rzeczy. Nie ma sensu pisać własnego narzędzia jeśli w 5 minut jesteś w stanie postawić działającego wordpressa. Wybór platformy blogowej to pierwsze sito odsiewające. Na tym etapie padło wielu. Wchłonięci w czeluści internetów, analizujący internetowe wojny o wyższości XXX nad YYY. Bez sensu…. instaluj wordpressa i pisz. To jest Twoje najważniejsze zadanie na początku prowadzenia bloga. Może kiedyś, gdy Twoje umiejętności w temacie wzrosną, gdy świadomość wzrośnie, zaczniesz się zastanawiać nad zmianą platformy. Ale tu i teraz, nie pora na to. Instaluj i pisz pisz pisz!!!

Wybór hostingu

Sito numer dwa, hosting. Który lepszy, który wydajniejszy, który daje więcej ficzerów. Może VPS lepszy bo postawie co chcę i jak chcę. Wszystko zabezpieczę, wszystko poustawiam…. bla bla bla. Serio? Masz telefon w kieszeni? Zbudowany samodzielnie? A może samochód kupujesz w częściach i składasz w garażu? Wybór hostingu na początku nie ma zupełnie znaczenia. Nawet najgorszy, najmniej wydajny hosting da radę. Powaga. Jeśli kupując domenę dostałeś jakiś minimalny hosting za free – to wiedz, że on zupełnie wystarczy. Cały myk w blogowaniu polega na tym aby pisać pisać pisać. Na początku nie będzie walić 10000 ludzi dziennie więc to serio nie ma znaczenia. Nie ma sensu marnować energii i czasu na analizowanie wszystkich hostingów na rynku. Zdradzę, Ci sekret. Bloga można przenosić pomiędzy hostingami. To się da zrobić i nawet nie jest jakieś specjalnie trudne. Jeśli myślisz o założeniu bloga to kluczem jest pisanie. Więc na początku skup się tylko na tym….. i na niczym innym.

Wybór skórki, tematu

Trzeci krąg piekła, odsiewający tych co już zainstalowali wordpressa. Ten krąg odsiewa najwięcej adeptów. Temat, skórka, wygląd. Jaki wybrać. Co wybrać. Wiadomo, musi być responsywny, musi być piękny, musi być wspaniały. Najlepiej bezpłatny. I wchodzisz w skórki, i przeglądasz, i szukasz. Energia Ci maleje bo tematów w internetach znajdziesz miliony. W każdym coś nie będzie Ci pasować, w każdym coś będzie nie tak. Czasem może się pojawić szaleńcza myśl, poprawię ten temat, albo jeszcze gorsza, zrobię samodzielnie temat. UWAGA!!! TO BŁĄD. Co jest najważniejsza rzeczą w blogu? TREŚĆ!!! TREŚĆ!!! TREŚĆ!!! więc pisz pisz pisz. Jeśli po trzech miesiącach dalej będzie Ci się chciało pisać i będziesz regularnie pisać to wtedy poszukaj sobie jakiegoś tematu. Wcześniej nie ma sensu bo poszukiwania idealnego tematu zabiorą Ci resztki energii i nie powstanie nic. Znowu, z doświadczenia, wielu adeptów padło na tym etapie. Chcieli prowadzić bloga ale poszukiwania tematu idealnego zwiodły ich na manowce. Nie popełniaj tego błędu i używaj tematu domyślnego. Zacznij myśleć o jego zmianie dopiero 3 miesiące po regularnym pisaniu. Jeśli domyślny temat wydaje Ci się brzydki i bezsensowny to mimo wszystko oprzyj się pokusie zmieniania go a swoją energię przelej na pisanie pisanie i jeszcze raz pisanie.

Wybór pluginów

Jest jeszcze jeden krąg piekła, który odsiał niemało adeptów blogowania i zawrócił z drogi tworzenia na drogę konsumpcji. Pluginy. Wiadomo, żodyn, ale to żodyn wordpress nie ostanie się bez dobrej paczki pluginów. Tylko jakie wybrać. Jak zainstalować. Cache, optymalizacje, seo, karty fb, karty tt, meta sreta. Jeśli dalej czytasz, to już wiesz jaka jest odpowiedź. Na początku drogi nie potrzebujesz, żadnych pluginów. Potrzebujesz treści więc musisz pisać pisać i jeszcze raz pisać. Dopiero po jakimś czasie zastanów się, czy na pewno potrzebujesz jakiegoś pluginu, a jeśli tak to jakiego. Na samym początku skup się na treści. Przyjdzie czas na picowanie bloga.

Na koniec mały disclaimer. Nie zrozum mnie źle, pluginy, dobry temat, solidny hosting to wszystko jest potrzebne i ważne ale nie na początku. Na początku skup się na budowaniu treści i budowaniu nawyku pisania. Masz wiele rzeczy nad którymi trzeba pracować więc nie bierz za dużo na barki. Nie zmarnuj swojej początkowej energii a skieruj ją na pisanie i tworzenie TREŚCI.  Na początku to jest najważniejsze. Wszystkie inne rzeczy to drugi, trzeci i czwarty plan. Serio, jeśli wytrwasz i przez trzy miesiące będziesz regularnie pisać to dopiero wtedy zacznij myśleć o tych innych rzeczach. Wtedy to będzie miało sens.

…a teraz pora założyć swojego bloga, tylko wiesz…. 🙂

Powodzenia

 

 

5 rzeczy, które da Ci prowadzenie bloga

Ponad 10 lat temu założyłem tego bloga. Jak, chyba każdy,sam zacząłem od wpisu a’la hello world. Właśnie przed chwilą go otwarłem i przypomniałem sobie, że to nie było pierwsze podejście do tematu – zresztą sprawdź sam. Przez te 10 lat nie blogowałem regularnie, jednak z perspektywy czasu nasunęło mi się kilka myśli i powodów dlaczego warto założyć własnego bloga – choćby dzisiaj. Być może będzie to dla Ciebie ciekawa inspiracja, być może stwierdzisz, że też tak chcesz. Być może masz już swojego blogaska i masz inną perspektywę – chętnie posłucham. Tymczasem oto moja subiektywna lista 5 rzeczy, które da Ci prowadzenie bloga.

1. Wzrosną Twoje umiejętności

Bez względu na tematykę bloga, Twoje umiejętności wzrosną. Poprawi Ci się interfejs pisarski. W zawodzie programisty często krąży obiegowa opinia, że to nie jest nasz najważniejszy skill – bo przecież „ja se kodzik pisze a nie wypracowania”. Nie do końca jest to prawda. Czasem trzeba napisać maila do klienta albo współpracownika. Czasem trzeba napisać – o zgrozo – kawałek dokumentacji. Pół biedy jak to jest dokumentacja techniczna – wtedy dobra ilość „exampli” się obroni, czasem jednak trzeba napisać dokumentację taką dla… wiesz, normalnych ludzi. Zresztą pisanie to nie wszystko. Przecież bloga prowadzi się o czymś. Jeśli zaś piszemy o czymś, to warto by było pisać o czymś na czym się znamy – zgadza się? Pisząc o programowaniu czasem trzeba sięgnąć do książki czy dokumentacji i okazuje się, że właśnie nasze umiejętności techniczne trochę wzrastają. Działa tutaj stara zasada – jeśli chcesz się czegoś dobrze nauczyć, zacznij uczyć innych. Wtedy wszelkie luki we własnej wiedzy powoli się wypełniają. Czasem ktoś zada ciekawe pytanie i trzeba poszukać głębiej. Czasem ktoś podrzuci uzupełniający materiał. Przekazując wiedzę innym, pogłębiasz swoją własną. Win-win.

2. Prowadznie bloga nauczy Cię SEO

Być może, nie tworzysz systemów webowych, być może seo zupełnie Cię nie interesuje. Prowadząc bloga jest jednak duża szansa, że wcześniej czy później zaczniesz zgłębiać tą tematykę. Dowiesz się jakie znaczenie ma optymalizacja tekstu, js-ów, css-ów i wielu, wielu innych rzeczy. Tematyka jest bardzo szeroka. Ja dzięki temu blogowi liznąłem tematykę AdWords i AdSense, jakieś podstawy SEO właśnie, reklamy na FB, jak pisać ciekawie – tak aby ludzie chcieli to czytać. Poznałem wiele narzędzi i mechanizmów, których bym nie poznał bo nie leżą one w zakresie moich codziennych zadań. Jak pewnie wiesz, trudno uczyć się wszystkiego, trudno też uczyć się suchej teorii. Blog może być bardzo fajnym eksperymentem do zgłębiania tajników internetów i lepszego zrozumienia jak cała ta sieć działa. Być może odkryjesz w sobie nowe talenty albo poznasz technologie, które bardziej Cię wciągną niż codzienna „bieżączka”.

3. Poznasz ciekawych ludzi

Nie samym internetem człowiek żyje, ale internet może spowodować, że poznasz ciekawych ludzi, którzy mają podobne pasje i podobne zainteresowania jak Twoje. Znajomości offlineowe mają pewne geograficzne ograniczenie. Internet znosi tą barierę a prowadzenie bloga może spowodować, że dotrzesz do takich jak Ty. Jak to działa? Ano jeśli piszesz w miarę regularnie to zostawiasz w Internecie pewną wartość. Nawet nie zdajesz sobie sprawy dla jak wielu ludziom Twój wpis może ułatwić pracę. Później będąc na konferencji czy jakimś meetupie te osoby mogą przyjść i podziękować, powiedzieć, że Twój tekst im pomógł. Nie raz miałem takie sytuacje i to daje miłą satysfakcję i energię do dalszej pracy. Pewnego razu dostałem nawet mailowe podziękowania od kogoś z bodajże USA, że mój post pozwolił rozwiązać problem, który ta osoba miała, a nawet na Stack Overflow nie było odpowiedzi. Najciekawsze w tym wszystkim jest fakt, że piszę po polsku – to jednak nie stanowiło bariery. Komunikat błędu plus screeny były wystarczającą informacją dla tej osoby. Piękne, prawda? Jestem przekonany, że w Twojej codziennej pracy zmagasz się z wieloma problemami. Opisz je, podaj rozwiązanie, pomożesz komuś.

4. Otworzą się przed Tobą różne drzwi

Prowadzenie bloga otwiera czasem, różne ciekawe drzwi. Czasem jakaś firma poprosi Cię o opinię. U mnie tak się stało po serii artykułów o długu technologicznym. Napisała do mnie firma z Francji, która próbowała wprowadzić narzędzie do zarządzania długiem technologicznym na polski rynek. Niestety wtedy (a był to rok 2013) temat był… delikatnie mówiąc abstrakcyjny dla wielu ludzi.  Po wielu mailach stwierdziliśmy, że jeszcze nie pora na to narzędzie. Oczywiście firma prowadziła dalej swoje badania (przecież nie będą się podpierać opinią jakiegoś jednego kolesia z internetów), wróciła do mnie po ponad pół roku z informacją, że niestety ale na tamtą chwilę, rynku w Polsce na to nie ma. Inne drzwi, które otwarły się dla mnie przez (między innymi) prowadzenie bloga to możliwość prowadzenia szkoleń – a tym samym pogłębianie mojej własnej wiedzy (patrz punkt 1). Z tymi szkoleniami to dłuższa historia – może na inny wpis – jednak posiadanie jakiejś udokumentowanej i online-owej bazy tekstów ułatwiły wejście do tego świata.

5. Zbudujesz swoją własną, podręczną bazę wiedzy w formie bloga

Najważniejsze zostawiam na koniec. Własna podręczna baza wiedzy w formie bloga. Rozpoczynając blogowanie nie miałem zamiaru zostać znanym blogerem – to nie był mój cel. Bardziej chciałem spisywać rzeczy, które mnie interesują. Pisać dla siebie. Tworzyć treści, do których mogę czasem wrócić. Wielokrotnie zresztą wracałem. Ile razy zdarzyło Ci się drugi, trzeci raz tłumaczyć to samo? Albo kolejny raz szukać rozwiązania tego samego problemu? Napisz notkę na blogu i voila. Czasem sam sięgałem do taki wpisów a czasem podsyłałem komuś link do gotowego rozwiązania – jak choćby integracja SVN z GIT-em. Jeden link i problem z głowy. Same plusy.

 

 

Umarł GitLab niech żyje Git czyli co zrobić jak zepsuje się repozytorium Git-a

git sie zepsul co robic

Git to repozytorium kodu a repozytorium kodu to jedno z podstawowych narzędzi pracy programisty. Dzisiaj pół internetu pisze, że GitLab – serwis do hostowania repozytoriów git – zaliczył poważną wpadkę. Trudno, zdarza się ale jakie można z tego wyciągnąć wnioski?


Single Point Of Failure

Centralne repozytorium kodu ma tą wielką zaletę, że jest centralne. SVN-y, SourceSafe-y i inne tego typu repozytoria kodu mają wielką zaletę – jedno źródło prawdy. To też najsłabsza strona – bo jak padnie serwer to nie ma nic. Na komputerach programistów pozostanie wprawdzie kod źródłowy ale bez jakiejkolwiek historii. Na ten wypadek warto mieć zbudowany odpowiedni plan backupu a właściwie kilku backupów – w chmurze, w szafie ogniotrwałej, offsite. Warto by było od czasu do czasu sprawdzić czy z backupu da się cokolwiek odzyskać. Generalnie w sytuacji awarii serwera odgrzebujemy backup, przywracamy repozytorum i pracujemy dalej no chyba, że padł sprzęt a my nie mamy zapasu, wtedy zamawiamy nowy, przywracamy co trzeba i pracujemy dalej. Już po kilku godzinach lub dniach spokojnie sobie pracujemy. Czy nie da się tego jakoś usprawnić?

Git na ratunek!

Dzisiejsza awaria GitLaba przeraziła całkiem sporą część internetu. Nie ma się co dziwić, bo wyobraź sobie, że nagle nie masz dostępu do swojego repozytorium. Mi się taka akcja zdarzyła w najgorszym możliwym momencie – w czasie wdrożenia przy sporej presji czasowej. Nagle repozytorium git-owe padło a dokładniej padł vpn do serwera ileś tam kilometrów dalej. Dwie osoby pracują nad kodem – wiadomo, ostatnie poprawki – czas ucieka, zmęczenie doskwiera a tu co? mamy ręcznie kod mergować? Na szczęście git to rozproszone repozytorium kodu a nie jak wspomniane w pierwszym akapicie „centralne repozytoria”. Rozproszone repozytorium oznacz tyle, że masz lokalną kopię całego repozytorium na komputerze. To oznacz, że bardzo szybko możesz postawić inne repozytorium. W moim przypadku sprowadziło się to do założenia repozytorium na bitbuckecie (bo tam można za darmo hostować prywatne repozytorum) a potem wykonania dwóch komend:

[code]

    git remote add backup git@bitbucket.org:.../.....git

    git push backup master

[/code]

To spowodowało, że w chmurze pojawiła się pełna kopia repo i mogliśmy spokojnie pracować dalej. Cała operacja trwała może 5 minut razem z założeniem konta i wysłaniem danych.

Czy awaria gita to jakaś tragedia?

No właśnie, wracając do samej awarii gitlab-a (ale i innch, githuba, bitbucket-a i tych wszystkich tajnych firmowych „bezpiecznych” repozytoriów), jeśli tylko nasze repozytorium jest rozproszone to w 5 minut jesteśmy wstanie postawić kopię i pracować dalej. Taka awaria będzie dla nas mikro przeszkodą a nie tragedią blokującą pracę na godziny a czasem nawet na dni. To jest siła posiadania kopii repozytorium lokalnie…

… z małym zastrzeżeniem, jeśli regularnie commitujemy i regularnie pushujemy do zewnętrznego repozytorium.

Sprzątaj swój kodzik nieustannie czyli o ciągłej refaktoryzacji.

refaktoryzacja to proces ciągły

Siadam do kodu i piszę… i piszę… i piszę… a potem save, commit, push. Done? No, nie bardzo. Jeśli pracujesz w TDD, to dobrze wiesz co to jest: red, green, refactor. REFACTOR!, REFAKTORYZACJA! Czyli moment kiedy po prawie skończonej pracy porządkujemy kod. To  sprowadza się do posprzątania śmieci, usunięcia zbędnych zmiennych, metod i klas oraz wprowadzenia abstrakcji tam gdzie trzeba – ogólnie doprowadzenie kodu do stanu używalności – do stanu jaki chciałbyś sam zastać jak będziesz z nim pracować. Jeśli nie pracujesz w TDD to pewnie i tak sprzątasz twórczy bałagan – tylko nie nazywasz to refaktoryzacją. No chyba, że tego nie robisz; to może pora zacząć.

Dlaczego kod nie refaktoryzowany ssie?

Ile razy ktoś marudził na kiepski kod? Jak to jest, że taki kod powstaje? Sam się przecież nie pisze. To my go takim robimy. Czasem nie ma czasu, żeby sprzątnąć bo deadline albo jakakolwiek inna wymówka, ot po prostu nie refaktoryzujemy. Czasami po prostu nie mamy chęci i energii; to jednak nikogo nie zwalnia z obowiązku refaktoryzowania od czasu do czasu. Przecież koniec końców to  my w przyszłości będziemy z tym kodem najwięcej obcować. Zawsze można coś zwalić na innych członków zespołu. Im większy zespół tym łatwiej ale czy na pewno o to chodzi? Jesteśmy dorośli… trzeba po sobie posprzątać. Jaki jest sens trzymania 10 pustych linii pomiędzy metodami? To nie jest kartka papieru gdzie kiedyś coś dopiszemy. Nic tak nie rozprasza jak wtedy, gdy przewijając kod widzisz raz większe a raz mniejsze dziury w kodzie. Do tego jakieś kawałki kodu wykomentowane. Serio? Przecież nawet nie wiadomo czy to jeszcze działa. Co to robiło. Wywal te komentarze i wywal puste miejsca i niech to jakoś wygląda. Na początek tyko tyle i aż tyle. Dzisiaj po otwarciu 690 linijkowego pliku zacząłem wywalać takie puste miejsca. Jak skończyłem zostało ich 615. Nie usunąłem wszystkich pustych linii bo to by było bez sensu.

Najprostsza refaktoryzacja – puste linie

Puste linie są świetnym narzędziem do poprawienia czytelności kodu gdy oddzielają metody, gdy oddzielają usingi od namespace-a czy logiczne kawałki kodu od siebie. Wtedy ich użycie jest bardzo zasadne. Kod ma się dobrze i łatwo czytać a takie wolne miejsce pozwala coś zaznaczyć . Edytory kodu nie mają (na szczęście) pogrubiania czy ustawiania różnych fontów dla kawałków kodu (wyobrażasz sobie pół metody boldem bo to jest ważniejsze pół metody?). Wolna linia jest naszym narzędziem.

A wracając do wątku… po wyczyszczeniu tego jednego pliku odpaliłem te same reguły na całym solution i okazało się, że 120 plików się zmieniło. Jak dobrze, że są automaty, które potrafią usprawnić ten proces 🙂

A jak to jest w innych branżach?

W piekarni, cukierni, kuchni robi się bałagan. To jest naturalny efekt uboczny procesu przygotowania produktu. Tu się coś wysypie, tam się wyleje. Nie da się utrzymać kuchni bez jednego brudka, bez jednej skazy podczas gotowania,ale naturalne jest, że po skończonej pracy wszystko się sprząta. Nie zostawia się na kiedyś. Nikt nie mówi, jutro. Jak się zostawi syf to potem się zalęgnie robactwo i będzie coraz trudniej doprowadzić lokal do stanu używalności. Zresztą, czy ty jako klient swojej ulubionej restauracji wolisz, aby sprzątali na kuchni codziennie czy może nie sprzątali w ogóle a raz na pół roku (jak wynegocjują z klientami sprint na sprzątanie) robili miesiąc wielkiego, gruntownego sprzątania? Myślisz, że tak sobie wymyślam? Zobacz jak pracują kucharze w MasterChefie gdzie gotują amatorzy a jak w Top Chefie gdzie gotują zawodowcy. Pomimo skrajnie skromnych ilości czasu w Top Chefie na ugotowanie czegokolwiek – oni ciągle sprzątają. Gotują i ciągle, dbają o to aby było czyściutko – to się nazywa ciągła refaktoryzacja w kuchni. To nie jest zryw przed końcem czasu, to jest ciągły proces, ich druga natura. Talerz leży do wydania a stanowisko prawie jak nietknięte. W MasterChef-ie natomiast jest więcej czasu a mimo tego często na stanowiskach jest… bałagan. Jest bałagan, bo uczestnicy nie mają we krwi ciągłego sprzątania swojego warsztatu no i jak już dzieło jest skończone to nie ma czasu aby doprowadzić stół do porządku. To jest różnica pomiędzy profesjonalistami a amatorami.

Czy warto prowadzić bloga?

W ostatnim wpisie pisałem dlaczego warto zgłosić się do konkursu daj się poznać – tak przy okazji to jeśli jeszcze się wahasz to chyba ciągle można się zgłaszać więc nie jest za późno. Tak przy niedzieli mnie naszło – dlaczego warto prowadzić bloga. Poza różnymi benefitami, których nawet się nie spodziewasz i poza “personal brandingiem”, który może bardzo pomóc w przyszłości jest coś co jest słabo może mierzalne finansowo ale jest bardzo inspirujące – przynajmniej dla mnie. Mianowicie satysfakcja. Czyli coś czego nie da Ci nawet najlepsza wypłata za najbardziej gównianą robotę. Dobra płaca za męczącą pracę wcześniej czy później wypali, zniszczy, przemieli i wypluje pusty korpusik. Satysfakcja z tego co się robi jest kołem napędowym do wielu wielu wielu innych rzeczy. Daje poczucie sensu. Dla mnie takie poczucie dały dwa komentarze jakie dostałem.

Really Need That, Thanks Bro

Muhammad Taha

Thank you very much to share your knowledge you save me

Victor Cabrera

Dlaczego piszę o tych dwóch konkretnych komentarzach? Bo są po angielsku i mimo, że nie prowadzę bloga po angielsku a po polsku to jednak pewnie problemy jakie opisałem były na tyle efemeryczne, że dopiero tutaj ktoś trafił na rozwiązanie. Każdy z nas tygodniowo co najmniej kilka takich błędów rozwiązuje. Warto o tym napisać, żeby wszystkim się lepiej żyło. Nic tak nie irytuje jak znalezienie błędu, który mnie zatrzymuje w pracy a w internetach nikt takiego problemu nie ma. Pisz! Ktoś pewnie czeka na Twoje rozwiązanie.

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ć.