2015 czas zacząć

Rok 2015 zaczął się już jakiś czas temu, więc chyba najwyższa pora na wpis otwierający kolejny rok, w którym będziemy mieli niejedną okazję do wymiany poglądów na tematy bezpośrednio dotykające tworzenia oprogramowania i na te trochę luźniej o tym traktujące :)

Dzisiaj wyjątkowo nie o programowaniu obiektowym ani też żadnym innym temacie związanym z wytwarzaniem oprogramowania. Dzisiaj chcę się z Wami podzielić kilkoma planami, które mam zamiar w tym roku zrealizować:

• Opublikowanie wszystkich wpisów z serii „Jak programować obiektowo”, które pokazują się na webmastah.pl.
  Jakiś czas temu postanowiłem odświeżyć serię artykułów dotyczących podstaw programowania obiektowego. Artykułów, które w znaczym stopniu wpłynęły na moje podejście do pisania.
• Publikowanie co najmniej dwóch wpisów miesięczne zarówno tutaj, jak i na moim anglojęzycznym blogu dotyczącym programowania - Let’s talk about Java.
  Ten punkt jest jednym z istotniejszych, bo częstotliwość pojawiania się wpisów jest czymś, za co od dawna chciałem się zabrać i poprawić. Niestety im więcej zajęć i obowiązków, tym mniej czasu na przyjemności :(
• Okazjonalne umieszczanie recenzji książek.
  Do tej pory co prawda pojawiały się od czasu do czasu, ale mam zamiar zwiększyć ich liczbę. Zawsze byłem zdania, że jedna dobra książka jest warta więcej niż spora ilość wpisów na blogach czy innego rodzaju artykułów. Dlaczego? Przedstawia dany temat w całości, w sposób spójny i poukładany.
  Poza tym, niektóre książki to klasyki, które powinno się znać :)
• Ostatnio pisałem o swojej prezentacji na JDD i muszę przyznać, że spodobało mi się. Dlatego w tym roku chciałbym nie tylko pojawić się tam ponownie z jakimś nowym tematem, ale postaram się również zaznaczyć swoją obecność na innych eventach. Oczywiście o wszelkich wydarzeniach, na których będzie można mnie spotkać poinformuję Was na blogu :)
• Mam również nadzieję, że w tym roku uda mi się w końcu zacząć prowadzić szkolenia. Od jakiegoś czasu ten temat chodził mi po głowie i ostatnio w końcu zmobilizowałem się i jestem na etapie tworzenia materiałów.
  Zaczynam powoli, czyli klasyka: Wzorce Projektowe, SOLID, TDD i refaktoryzacja, ale jeżeli okaże się, że pomysł wypali to z pewnością poszerzę listę tematów. Oczywiście jeżeli ktoś byłby chętny to proszę o kontakt :)

Poza powyższymi punktami zabrałem się jeszcze za realizację dwóch innych, mam nadzieję, że równie ekscytujących projektów, ale na razie nie chcę zbyt dużo mówić, ponieważ oba są jeszcze we wczesnej fazie, więc żeby nie zapeszyć…

Oprócz tego wszystkiego z chęcią zapoznam się z Waszymi pomysłami oraz sugestiami dotyczącymi tego, o czym warto by jeszcze napisać bądź opowiedzieć. W końcu piszę nie dla siebie, a dla Was :)

W międzyczasie doszedłem do wniosku, że warto spróbować swoich sił w konkursie organizowanym przez Onet.pl – Blog Roku 2014 w kategorii Specjalistyczne i Firmowe. W końcu obecności w internetach nigdy za dużo :P
Tak więc zachęcam wszystkich do wysyłania SMS-ów i oddawania głosów na (mam nadzieję :) Wasz ulubiony blog.

JDD2014: Code review - jak więcej zyskać niż stracić?

Jakiś czas temu pisałem o moim planowanym występie na JDD 2014. Wczoraj pojawił się film na youtubie z moją prezentacją, do którego obejrzenia gorąco Was namawiam. I liczę na jakiś feedback z Waszej strony, abym wiedział co poprawić na przyszłość :)

Osobiście jestem zadowolony zarówno z wystąpienia jak i doświadczenia, które dzięki niemu zdobyłem. Niemniej jednak, jestem ciekaw Waszych opinii.

Otrzymałem również maila od organizatorów, że na 98 oddanych na prezentację głosów, aż 83 to były głosy pozytywne. Za wszystkie dziękuję i mam nadzieję, że następnym razem będzie jeszcze lepiej :)

Jeżeli będziecie mieli trochę czasu i ochoty to zapraszam również na kanał PROIDEAconferences, na którym są wszystkie prezentacje z tegorocznego JDD, oraz wiele innych :)

Diagram prawdę Ci powie

porozmawiajmy o diagramach

Zdaję sobie sprawę, że pewnie wielu z Was odrzuca na samą myśl o UML-ach, ale chcąc nie chcąc, na pewnym etapie Waszej kariery się z nimi spotkacie i możliwe, że nawet sami będziecie musieli je wykorzystać do pracy twórczej.

Dlaczego tylu programistów czuje awersję do diagramów? Cóż, przypuszczam, że wynika to z pewnej niechęci do tego, czego nie znamy, w tym konkretnym przypadku – do języka, który jest nam obcy. Bo tym właśnie jest UML, językiem, który nie wszyscy rozumiemy, którym nie wszyscy mówimy. Dzisiaj jednak nie o tym.

Strach ma wielkie oczy...

Odwaga to podobno nie brak odczuwania strachu, a umiejętność jego pokonywania. I właśnie tą cechą powinien kierować się każdy, kto ma w planach napisanie jakiegoś testu. Nie ważne czy jest to test jednostkowy, czy integracyjny, czy jeszcze jakiś inny jego rodzaj - gdy zabieramy się za testowanie to właśnie w stronę tego, co nas przeraża powinniśmy kierować swój wzrok, w stronę tego, co spędza sen z powiek kolegom z naszego zespoł.

JDD 2014

W końcu zebrałem się w sobie i udaję się na konferencję w roli speakera. Co prawda z tegorocznym PHPCon'em nie wyszło, ale już niedługo, bo w przyszłym tygodniu, będziecie mieli okazję posłuchać mnie na JDD 2014. Będę mówił o Code Review, o tym co zrobić, żeby wycisnąć z niego wszystko, co najlepsze :)

Wiem, że trochę późno, ale mimo to serdecznie zapraszam. Może z niektórymi z Was będę miał okazję w końcu porozmawiać :)

Tak więc, jeżeli się jeszcze nie zdecydowaliście, a chodziło Wam to po głowie, to nie czekajcie tylko się zapisujcie i... do zobaczenia.

Senior Deweloper - a któż to jest?

gdy każdy widzi to inaczej

W mojej poprzedniej firmie mieliśmy pewnego razu kilka dyskusji dotyczących definicji ról w projektach i odpowiedniego tytułowania osób, które w nich uczestniczą. O ile nie było większych problemów z określeniem tego kim jest Junior oraz Regular Developer, to gdy przyszło do definiowania roli Seniora dyskusja zrobiła się naprawdę ciekawa :)

Po interesujących i żywych rozmowach (udało mi się nawet zaczepić ludzi na Goldenline, żeby "podkraść" dobre pomysły :), w trakcie których miałem okazję dowiedzieć się kim dla kogo jest senior i kim dla kogo nie jest, mogłem stwierdzić przede wszystkim dwie rzeczy:

• Uniwersalna definicja nie jest prosta do znalezienia.
• Przy liczbie osób większej niż jeden jest to tym mniej prawdopodobne.

Skończyło się na tym, że wróciliśmy do starego, dobrego i wypróbowanego developera :)

Visitator, czyli czas na wizytę to tu, to tam...

kolejna wizyta w świecie wzorców

Zapewne już trochę kodu mieliście okazję stworzyć odkąd pisałem o dekoratorze. Mam nadzieję, że przez ten czas mieliście możliwość go wypróbować i sprawdzić jak daje radę w świecie prawdziwych problemów.

Następnym wzorcem, z którym spróbujemy się zmierzyć będzie wizytator.
Muszę uczciwie się przyznać, że moje pierwsze z nim spotkanie, gdy wertowałem strony Wzorców Projektowych to nie była miłość od pierwszego wejrzenia i trochę czasu musiało minąć zanim w pełni doceniłem korzyści płynące z jego wykorzystania.

Ale jak tak w ogóle ten wizytator wygląda? Gdzie i po co się go stosuje?
Wierzę, że na te pytania uda mi się odpowiedzieć w poniższych akapitach.

Wzorce... wzorce są wszędzie!

Muszę szczerze przyznać, że sporo czasu upłynęło zanim książka Patterns of Enterprise Application Architecture Fowler'a trafiła z półki, na której zajmowała jedno z honorowych miejsc, do moich rąk. Przez długi czas nie mogłem się w sobie zebrać, zawsze w jakiś tajemniczy sposób znajdowała się pozycja, która skutecznie odciągała mnie od tej lektury. W końcu skończyło się na tym, że niekiedy nawet głupio było mi przyznawać się, że jeszcze jej stronic nie przewertowałem. Zebrałem się w sobie i... jakoś poszło :)

Nie pamiętam dokładnie jakie odczucia towarzyszyły mi gdy czytałem poszczególne opisy wzorców przedstawionych w książce przez Fowler'a. Miałem już za sobą lekturę Wzorców Projektowych Bandy Czworga, ba, nawet powoli zaczynała do mnie docierać wiedza w niej zawarta :) Mimo wszystko po przeczytaniu książki Fowler'a ponownie nie byłem w stanie zrozumieć wszystkiego, nie wszystkie motywacje były dla mnie jasne, niekiedy wręcz, sądziłem, że to przerost formy nad treścią, ale...

Dlaczego warto mówić jednym językiem?

Zapewne już nie raz mieliście okazję przeczytać stwierdzenie, że bardzo istotne jest to, aby w kodzie do nazywania klas domenowych wykorzystywać, te (nazwy) których używa nasz klient.
Wielu z Was uznaje to za oczywistość, wielu dodaje jakieś "ale", są tacy, którzy twierdzą, że przecież klient i tak nie wie czego chce, to po ci się przejmować. Oczywiście są też tacy, którzy sami się takimi "pierdołami" nie mają czasu przejmować, bo przecież "kod jest do napisania".
Nie powiem, że się nie da i Wasz projekt bez takiego odwzorowania nie ma szans na powodzenie, bo to nie jest prawda. Przynajmniej nie w każdym przypadku. Są jednak projekty odpowiednio duże bądź skomplikowane, gdzie ten brak spójności potrafi zauważalnie wpłynąć na tempo produkcji kodu oraz na jego jakość. Niestety, jeżeli się "nie dogadamy", to nawet mimo naszych najszczerszych chęci i przy wykorzystaniu najlepszych technik i praktyk nie unikniemy błędów.

Jak robić code review lepiej i krócej?

Code review jest to jedna z tych aktywności, do której niektórych bardzo ciężko przekonać, bo przecież to "kolejna rzecz do zrobienia". pamiętajcie jednak, że więcej nie znaczy wolniej i naprawdę warto spróbować, bo potencjalne korzyści są naprawdę duże.
Dzisiaj jednak nie mam na celu namawiania Was do wypróbowania tej aktywności w Waszym projekcie. Dzisiaj kilka rad dla tych, którzy już code review praktykują oraz dla tych, którzy mają w planach dodanie tej aktywności do swojego harmonogramu :)