Pragmatic developer

Witam wszystkich. Postanowiłem troszkę bardziej urozmaicić swoje i Wasze życie. Z tego powodu zacząłem się uczyć zupełnie innego języka programowania. W tej serii wpisów będziecie mogli się go nauczyć razem ze mną. Wypowiem się na temat problemów jakie napotkałem z zmianą myślenia o składni, technice programowania itp.. Dlaczego Ruby on Rails? Z jednej strony ciekawość i chęć poznania czegoś innego. Z drugiej po przeczytanych różnych wpisach oraz opiniach ludzi język wydawał się rozwiązaniem na różne problemy programistów. Jednocześnie myślałem o językach skryptowych, ponieważ duża społeczność programistów uważa je za języki przyszłościowe. A więc zaczynamy!!! Zaczynam naukę, a o wynikach jej oraz o samym języku będziecie mogli przeczytać na kolejnych wpisach.

Witam, chciałbym przedstawić swój pogląd na temat słuchania muzyki podczas programowania i właśnie o tym będzie dzisiejszy wpis. Rodzaj muzyki Słyszałem kiedyś teorię, że przy muzyce klasycznej lepiej się uczy i pracuje. Pomimo, że lubię taką muzykę nie ma dla mnie różnicy jakiej muzyki słucham. Wydaje mi się, że to nie do końca prawda (albo ja jestem specyficzny). Ale czy muzyka cokolwiek daje? Według mnie tak. Zauważyłem, że słuchanie muzyki powala w zapadnięcie w "ciąg programowania". Chodzi tutaj o to, że piszemy wszystko szybciej, sprawniej i nie przeszkadza nam nic z otoczenia. Wtedy produktywność wytwarzania kodu bardzo się przyśpiesza. Ale jak zawsze jest jakieś "ale" Problem z tym przyśpieszeniem produktywności jest taki, że popełniamy wtedy więcej błędów. Nie skupiamy się czy to, co piszemy, ma jakiś sens. Czasami bezmyślnie przepisujemy zdania z dokumentacji na kod, które tak na prawdę też mogą posiadać pomyłkę. Podsumowując Zostawiam Wam ocenieni

Witam Was czytelnicy, chciałbym Wam wytłumaczyć lub przypomnieć co oznacza programowanie zorientowane obiektowo. Problem polega na tym, że każdy programista ponoć wie co to znaczy. A zwłaszcza Ci po studiach. Tylko, że z czasem pisząc w różnych projektach okazuje się, że pomimo używania języka obiektowego, nasz kod jest daleki od założeń paradygmatu programowania, który chcemy stosować. Programowanie obiektowe Jest to paradygmat programowa w którym problemy przedstawiamy jako zbiór obiektów komunikujących się ze sobą oraz posiadających jakiś stan. Zbliżony on jest do codziennego myślenia człowieka. Chętnie podam przykład dla wyjaśnienia. Pomyślmy o człowieku jako problemie, który chcemy zaimplementować. Dajmy mu możliwość odkręcania śrubek. Oczywiście człowiek człowiekowi nie równy i każdy ma swoją technikę, doświadczenie, siłę, zręczność i cokolwiek innego co jest potrzebne do tej czynności. I tutaj właśnie użyliśmy myślenia obiektowego dla obiektu człowiek. Ma on swoje atrybuty w

Dzisiaj przedstawię jak sprawić, aby metody klas były czytelniejsze. Oczywiście czekam na komentarze, aby uzyskać jeszcze lepszą technikę pisania kodu. Mam nadzieję, że współpraca będzie owocna, a więc zaczynamy. Co uważam za ważne dla czytelności funkcji? Rozdzielenie poziomów abstrakcji Przybliżę, co mam na myśli. Co uważam za poziomy abstrakcji? Jeden poziom abstrakcji to są opisy czynności jakie musimy wykonać uwzględniając identyczną szczegółowość. Najłatwiej będzie to pokazać na przykładzie. Z powodu, że jest już po świętach przydałoby się rozebrać choinkę :). Najbardziej ogólnym poziomem abstrakcji to będzie czynność "rozbieranie choinki". Kolejnym poziomem to będzie ściągnąć bombki, ściągnąć lampki oraz ściągnąć łańcuch. Następny to weź złap lampki od góry i okrężnym ruchem powoli je ściągaj, tak samo z łańcuchami. Mam nadzieję, że wyjaśniłem czym są poziomy abstrakcji. Dlaczego rozdzielenie tych poziomów się przydaje? Czytelnik takiego kodu

Witajcie czytelnicy Dzisiaj mam zamiar przedstawić Wam ciekawostkę na którą się napotkałem. Mam nadzieję, ze niektórym to pomoże w trakcie szukania błędu w swojej implementacji lub rozwiązania tego problemu. Zjawisko Miałem stworzonego bean'a w konfiguracji .xml'owej Spring'a z metodą inicjującą. Ustawiłem na tej metodzie @Transactional(propagation=Propagation.REQUIRED) i myślałem, że wszystko działa. W trakcie implementacji tej metody, użyłem innego serwisu, który wymagał transakcji @Transactional(propagation=Propagation.MANDATORY). Nie widzieliście mojego zdziwienia jak dostałem wyjątkiem na twarz o treści: org.springframework.transaction.IllegalTransactionStateException: No existing transaction found for transaction marked with propagation 'mandatory'. Wiedziałem czego dotyczy błąd, ale nie wiedziałem dlaczego go otrzymuje skoro mam transakcje. Zaczęło się szukanie Pierwszy pomysł, "może coś źle napisałem?". Zerkam na kod. Jest ok. Drugi to, &qu

Witam cię czytelniku. Skoro tutaj zajrzałeś to znaczy, że chcesz stać się lepszym programistą. Postanowiłem stworzyć serię wpisów, która będzie mówiła o przejrzystym i czystym kodzie. Chciałbym, abyś zostawił komentarz pod wpisem, jeżeli masz jakieś wątpliwości lub spostrzeżenia. Jednocześnie odpowiem chętnie na wszystkie pytania związane z tym tematem. Nie mówię, że wypracowany przeze mnie system jest najlepszy dlatego prosiłbym także o Waszą opinie, która pozwoli stworzyć nam porady jak pisać czysty i czytelny kod. A więc zaczynajmy. Co to znaczy czysty kod? Jest to kod napisany tak, że dla użytkownika tego kodu (drugiego programisty, a nawet autora) będzie on czytelny nawet po długim czasie. To kod, który pozwala na łatwe i przyjemne przeglądanie, gdzie widać co się w nim dzieje. Kod powinień być prosty, pomimo skomplikowanych algorytmów. Osoba nie znająca systemu powinna w łatwy sposób wywnioskować co fragment kodu robi. Co potrzeba, aby pisać czysty kod? Bardzo dużej dyscypli

Przedstawię tutaj moją opinie (opartą na doświadczeniu, książkach oraz opiniach innych ludzi) na temat komentarzy w kodzie. Co to są komentarze? Wiem, każdy wie co to są komentarze. Przedstawię tutaj tylko inną definicje komentarzy. Komentarze to ZŁO (czasami konieczne). Zaraz dowiecie się dlaczego. Komentarze opisujące kod Jestem całkowitym przeciwnikiem komentarzy, ale często sam je stosuje. Zapytać teraz możecie "ej, ale dlaczego?". Wykorzystuje je właśnie jako pomocnik do poprawy czytelności cudzego, a nawet czasami swojego, kodu. Staram się nie zostawiać komentarzy w kodzie. Są one półśrodkiem do refaktoringu. Refaktoring dużej, brzydkiej i nieczytelnej funkcji zaczynam właśnie od podzielenia kodu tej funkcji na sekcje i napisaniu odpowiedniego komentarza opisującego te bloki kodu. I tutaj właśnie zauważyć można dlaczego tak surowo oceniłem komentarze. Uważam, że komentarze po prostu próbują zaślepić użytkownika kodu, aby nie zauważył, że jest napisany źle i nieczyte