Każdy koniec to nowy początek

Z przykrością muszę napisać, że ze względu na brak czasu niestety nie pojawi się już więcej nowych wpisów na Programistyce.
Wszystkim tym, którzy przez tyle czas czytali kolejne artykuły, komentowali lub w inny sposób motywowali mnie do tworzenia kolejnych treści serdecznie dziękuję.

Chcę również powiedzieć, że nie kończę z dzieleniem się wiedzą i pisaniem i szczerze zapraszam do aktywnego śledzenia dwóch pozostałych blogów przeze mnie prowadzonych:

• Let’s talk about Java – wszystko to, o czym pisałem tutaj będę kontynuował właśnie tam. Plus treści związane stricte z Javą i pokrewnymi.
• Between success and failure – o przywództwie, komunikacji, project managemencie, agile, motywacji, rozwoju i wielu innych soft skill’owych tematach, które mnie interesują.

Oczywiście jest jeszcze Webmastah.pl, gdzie obecnie publikuję odnowioną wersję kursu Jak programować obiektowo

Poza tym możecie mnie jeszcze znaleźć w wielu innych zakamarkach internetu:

• Twitter
• LinkedIn
• Facebook
• Google Plus

Ewentualnie pozostaje jeszcze kontakt bezpośredni :)
Jeśli macie jakieś pytania, problemy, w których rozwiązaniu mogę pomóc lub chcecie się wymienić poglądami na tematy dotyczące OOP to zawsze czekam :)

Tak czy inaczej, wierzę, że to nie koniec i jeszcze będę miał okazję zaserwować Wam jakieś interesujące (oby:) przemyślenia.


A powód? Jak już pisałem na wstępie – brak czasu.
Po pierwsze, Let’s talk about Java i Programistyka są mocno zbliżone tematycznie co często sprowadzało się do pisania i edycji tego samego dwukrotnie. Nie ukrywam, że wolę przeznaczyć ten czas na zaserwowanie Wam czegoś nowego.
Po drugie, mam nadzieję coraz częściej się z Wami spotykać na różnego rodzaju konferencjach i eventach, a to również wymaga przygotowania.
I na koniec, prowadzenie szkoleń, co od jakiegoś czasu chodzi mi po głowie. A na ich przygotowanie również muszę mieć czas.


Decyzja ta ciągnęła się za mną już od jakiegoś czasu, ale nieustannie zwyciężał sentyment.
Udało nam się wspólnie przetrwać 4 lata (pierwszy wpis pojawił się 14 lipca 2011). Przez ten czas męczyłem Was aż 97 razy (tyle wpisów udało się stworzyć przez ten czas).
Gdy zaczynałem to nie sądziłem, że będzie to tak świetna zabawa. Zajęcie, które przez tyle czasu będzie mnie angażowało i sprawi tak ogromną frajdę. I jestem przekonany, że będzie tak nadal!
Sporo się od Was nauczyłem. Dzięki Waszym komentarzom, poprzez rozmowy bezpośrednie i wtedy, gdy mieliśmy okazję spotkać się osobiście.


Jeszcze raz wielkie dzięki za czas, który poświęciliście na czytanie moich artykułów i jeszcze raz zapraszam Was do odwiedzania pozostałych moich blogów.

Bo jeszcze sporo przed nami :)

Prosić czy pytać?

o prawach i zasadach

Jakiś czas temu pisałem o Law of Demeter, o tym o co w tym właściwie chodzi oraz o plusach przestrzegania prawa :) Dzisiaj chciałbym przybliżyć Wam zasadę Tell, don’t ask, która w moim odczuciu jest punktem wyjścia do wspomnianego wcześniej prawa, przestrzeganie LoD jest jednym z następstw stosowania zasady TDA.

So you think you can code

Już niedługo, bo 4-go lipca, w Kampusie Głównym Uniwersytetu Warszawskiego odbędzie się kolejna edycja Confitury.
Dla Was będzie to możliwość wysłuchania świetnych prezentacji, którym może uda się wnieść coś nowego i odkrywczego do Waszego programistycznego życia.
I tam, wsród tych świetnych prezentacji, będziecie mieli okazję znaleźć moją :)

Dla mnie to kolejna okazja do wypróbowania swoich sił w przekazywaniu wiedzy za pomocą słowa mówionego i możliwość poznania niektórych z Was osobiście :)

Serdecznie zapraszam i, oby, do zobaczenia.

Zróbmy coś bezużytecznego

Wszystko ma sens wtedy, gdy ma sens. Nie tworzysz kodu, którego nie potrzebujesz z kilku powodów. Po pierwsze, może się okazać, że go (o ironio!) nie będziesz potrzebował. Po drugie, dodajesz pracy sobie i innym, ponieważ ktoś musi o ten kod dbać, ktoś będzie go zapewne niejednokrotnie czytał, i tak dalej. Po trzecie, kod który jest niepotrzebny stwarza problemy ze zrozumieniem aplikacji, bo przecież „skoro ktoś to dodał, to jest potrzebne”.

Nie zawsze jednak jest tak, że kod niepotrzebny nie jest nigdzie wykorzystywany. Zdarzają się sytuacje, gdy powstają metody, które co prawda są użyte, ale są jedynie elementem pewnej funkcjonalnej całości i same nie niosą nic poza potencjalnymi problemami.
I o takich tworach chciałbym dzisiaj opowiedzieć.

Where's the law?

z obcymi (nie) za pan brat

Jeżeli chcielibyśmy ująć kwintesencję Prawa Demeter (Law of Demeter) w jednym zdaniu to brzmiałoby ono: "rozmawiaj tylko z (bliskimi) przyjaciółmi".
W pełnej formie mówi ono o tym, że metoda danego obiektu może odwoływać się jedynie do metod należących do:

• tego samego obiektu,
• dowolnego parametru przekazanego do niej,
• dowolnego obiektu przez nią stworzonego,
• dowolnego składnika, klasy do której należy dana metoda.

being in the Zone

Jakiś czas temu rozmawiałem z kolegą z zespołu. Nie pamiętam o czym dyskutowaliśmy, ale to nie temat tej rozmowy jest bodźcem do napisania dzisiejszego wpisu.

W pewnym momencie mój rozmówca stwierdził, że po wszystkich czynnościach i aktywnościach, które zewsząd na niego spływały, w końcu miał chwilę na to, co programiści lubią najbardziej – na pisanie kodu. Przez jakiś czas nic go nie odrywało od programowania i znalazł się znanym każdemu programiście stanie, kiedy kod po prostu płynie przez palce.

Zawsze ten stan lubiłem i cenię każdą minutę, w trakcie której mogę pogrążyć się w kodzie. Nie martwiąc się o to, że coś lub ktoś mi zaraz przeszkodzi. Dlatego też stwierdziłem z uśmiechem, że w końcu mógł sobie w spokoju popisać, a będąc w tym stanie z pewnością efekty jego pracy stały na wysokim poziomie. Zawsze twierdziłem, że będąc tak skupionym na kodzie, gdy paradoksalnie prawie nie masz czasu na myślenie, jego tworzenie ma trochę ze sztuki. Jesteśmy natchnieni i temu natchnieniu dajemy ujście.

Jakież było moje zdziwienie, gdy mój znajomy stwierdził, że on wręcz przeciwnie, nie lubi być w takim „transie”.

Że co? Ale dlaczego?

Bo w takich chwilach jego kod za bardzo mu się podoba, podchodzi do niego niemal bezkrytycznie. Co z tego, że ten kod rzeczywiście płynie skoro jest podatny na błędy. A jest tym bardziej podatny, bo on… jest z niego zadowolony.

A co Wy myślicie na ten temat? Jak podchodzicie do tych momentów, gdy możecie zatopić się w tworzeniu i odpłynąć?

Test Doubles - z czym to się je?

o czym dzisiaj pomówimy?

Coś ostatnio niewiele kodu było na blogu, więc postanowiłem to trochę nadrobić. Tak więc dzisiaj czeka na Was jego odrobinę większa porcja.
Dzisiaj chciałbym Wam opowiedzieć trochę o Test Doubles. Czym są? Do czego je wykorzystujemy? Dlaczego to robimy?
A po krótkim teoretycznym wstępie przyjdzie pora na to, co programiści lubią najbardziej – kod :)

It’s all about… domain

Tematem Domain-Driven Design jestem zainteresowany już od dłuższego czasu, ale ostatnio częstotliwość jego występowania przy okazji developmentu znacznie się zwiększyła.
Biorąc to pod uwagę zdecydowałem się na odświeżenie swojej pamięci i ponowne przewertowanie stronic Domain-Driven Design Eric’a Evansa. A skoro już to zrobiłem, to chyba warto podzielić się odczuciami i obserwacjami na temat tej lektury z Wami.

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 :)

Publiczne metody w abstrakcie = interfejs istnieje

a zaczęło się to tak...

Jak każdy (a przynajmniej mam taką nadzieję) zespół ludzi pracujący nad tym samym kodem, i w naszym projekcie istnieje dokument ze standardami kodowania. Co jakiś czas wprowadzamy drobne modyfikacje, bo refaktoryzować można (i powinno się) nie tylko kod :)

Dzisiaj ten właśnie dokument przeglądał jeden z moich kolegów i natknął się na jedną z moich notatek/uwag w tym dokumencie, którą odrobinę przeredagowaną (niestety użyłem skrótów myślowych pisząc ją :) zamieszczam poniżej:
Jeżeli posiadasz klasę abstrakcyjną z metodą publiczną, która jest rozszerzana przez kilka klas nie implementujących tego samego interfejsu, to wiedz, że coś się dzieje.

Dobra, samo stwierdzenie może nie być zbyt oczywiste, ale wierzę, że po krótkich wyjaśnieniach dojdziecie nie tylko do wniosku, że ma to sens, ale co więcej, że sami już tą zasadę w kodzie stosujecie.
Jakby na to nie patrzeć, jest całkiem naturalna :)

SOLIDny kod

kolejna seria za nami

Następna seria wpisów skończona. Mam nadzieję, że udało mi się przedstawić omawiane zasady w jasny i zrozumiały sposób.

Dzisiaj jedynie krótki wpis, w którym chciałem zebrać linki do opublikowanych postów. Zdaję sobie sprawę, że spis treści zazwyczaj jest na początku, ale mam nadzieję, że mi wybaczycie tą ekstrawagancję :)

O zasadach SOLID jeszcze z pewnością nie raz napiszę, a jeżeli w między czasie będziecie mieli jakieś pytania lub wątpliwości to czekam na komentarze, może uda mi się coś więcej rozjaśnić, a może sam się czegoś nowego nauczę :)

A w międzyczasie zapraszam do czytania wpisów związanych z kolejną serią - tym razem temat długo przeze mnie pomijany, czyli wzorce projektowe.
Mam nadzieję, że po ponad trzech latach jestem już wystarczająco przygotowany :)