W moim ogródecku…

Dlaczego w ogóle Software Garden, co to znaczy?

Jeśli szukasz odpowiedzi na pytanie czym jest Software garden, to wydaje mi się, że nie znajdziesz lepszego wytłumaczenia niż koncepcja (którą przeczytałem kilka lat temu) oryginalnie wyłożona w książce Pragmatyczny Programista Andrzeja Hunta and Dawida Thomasa.

Istnieją takie książki, filmy, obrazy, etc., które rewolucjonizują nasz sposób myślenia w pewnych obszarach. Wiele osób wyciągnęło ciekawe wnioski z tej inspirującej książki: jedni zaczęli gotować żaby, inni gadać do gumowej kaczki… Ja wychowywałem się blisko natury, dlatego moim zdaniem oprogramowanie przez nas tworzone i wykorzystywane dużo bardziej przypomina ogród niż budownictwo czy jakieś maszyny. Na swój sposób ono żyje. Nigdy nie jest w pełni ukończone. Cały ekosystem dookoła podlega ciągłym zmianom. Modlimy się o deszcz. Pory roku zmieniają się po sobie. Potrzeba miejsca na nowe rośliny. Trzeba się pozbywać pasożytów, żeby było co jeść. Nie można co tydzień wszystkiego zaorać i zaczynać od nowa. I tak dalej…

Dlatego przed kilku laty zmieniłem opis mojego stanowiska z “Programista” lub “Inżynier oprogramowania” na “Software Gardener” (choć z wykształcenia jestem właśnie inżynierem programistą i mam na to papier). Oczywiście ludzie, którzy nie przeczytali Pragmatycznego Programisty, są czasem zmieszani lub zakłopotani. Z drugiej strony pozwala mi to bez słów porozumieć się z tymi paroma osobami (a spotkałem takie), które na wizytówce mają również napisane “Software Gardener”. Coś za coś.

Ta strona to taka internetowa reprezentacja mojej niekończącej się podróży w Ogrodnictwo Programowania. To nie jest wielkoobszarowa farma z monokulturą. To mój mały ogródek, z roślinkami o które staram się dbać, z ptakami śpiewającymi nad głową i z paroma robalami pewnie też. Rozgość się, proszę.

All my G-spots

Zdaniem niektórych codzienna praca programisty polega przede wszystkim na rozwiązywaniu problemów, a nie używaniu narzędzi. Moim zdaniem wykorzystywanie właściwych narzędzi nie tylko rozwiązuje problemy, ale pozwala wyeliminować wiele z nich. Trochę to trwało nim uświadomiłem sobie, że o ile żadne narzędzie nie jest złotym młotkiem, o tyle niektóre są dla mnie prawdziwymi punktami G*. Używanie ich daje prawdziwą satysfakcję podczas reagowania na “kolejne wymaganie biznesowe”. Chciałbym Wam pokazać moje zawodowe punkty G i pomóc znaleźć wasze. Oraz wskazać co brak tych punktów możne oznaczać w kolejnej “fantastycznej” ofercie pracy, którą właśnie otrzymaliście.

CONTEXTVS, STVLTE! (Kontekst, głupcze!)

“Najlepszy algorytm do sortowania to quick sort.”
“Indeksy przyspieszają działanie bazy.”
“Dane sortuje się przy pomocy ORDER BY.”
“Dziedziczenie be, kompozycja cacy.”
“Windows to system operacyjny.”
“W bazie musisz mieć transakcje.”
“Java jest wolna.”
“Nie jedz żółtego śniegu.”
“Nie należy samemu podpisywać certyfikatów.”
“Interrupt w Javie jest skopane.”

Świat IT jest pełen mantr/prawd objawionych, przekazywanych (często w tradycji ustnej) w plemionach programistów. Bezmyślnie powtarzane z pokolenia na pokolenia (często już od uczelni) powodują bezrefleksyjne stosowanie, które może wywołać w najlepszym przypadku więcej szkody niż pożytku. W najgorszym: totalną klapę za wagony dolarów. Kontekst jest nieodzowną otoczką każdej mantry. Pozwala bez pudła odróżnić właściwe użycie od nadchodzącej plajty.

Graylog: one tool to log 'em all

Istnieje 10 rodzajów ludzi: ci, którzy już logują i ci, którzy dopiero będą. ;-) Ale co może być fascynującego w logowaniu? To tylko dodawanie wpisów z określonym poziomem do jakiegoś pliku w /var/log, po co w ogóle ta prezentacja? Cóż, zwyczajne dodawanie linii do /var/log i śledzenie ich przy pomocy tail -f albo przeszukiwanie grepem jest takie… w stylu lat osiemdziesiątych i niewydajne. Poznajcie Grayloga: scentralizowany i rozproszony system do zarządzania dziennkami. Narzędzie, które pozwli ci gromadzić, przetwarzać, analizować dzienniki z wielu źródeł: sysloga, twojej aplikacji, Apache/nginxa, bazy danych, firewalla, itd. Umożliwi przeszukiwanie wszerz i wzdłuż, analizowanie wpisów bez względu na język/technologię, które te wpisy poczyniły. I robi to dobrze. I jest Open Source. Ta prezentacja jest o pewnych pułapkach, które można spotkać przy prawdziwym wykorzystaniu, szybkim uruchamianiu Grayloga, podłączaniu twoich aplikacji/systemów/serwerów, analizowaniu dzienników. Zasymlujemy ruch, jakieś awarie… Zamysł prezentacji jest taki, że po jej zakończeniu będziesz w stanie w poniedziałek uruchomić Grayloga u siebie w biurze i zacząć czerpać z niego profity. Poziom średnio zaawansowany.

Logowanie w Javie z SLF4J i Logbackiem

System.out.println("Czy dobrze jest tak logować?");
logger.warn("Oczywiście nie!");

Logować czy nie logować: to NIE jest pytanie!

Postawmy sprawę jasno: wypluwanie wiadomości z dziennika bezpośrednio na wyjście standardowe / konsolę jest nie do przyjęcia.

Wszyscy chcielibyśmy żyć w idealnym świecie, w którym zarówno nasze programy, jak i ich użytkownicy, zachowują się przewidywalnie. Ale rzeczywistość pokazuje coś zgoła odmiennego: mają miejsce wypadki, których nie sposób przewidzieć, zatem powinniśmy zrobić co w naszej mocy, by się na nieprzewidywalne jakoś przygotować. Logowanie jest częścią tych przygotowań. Pozwala szybciej i łatwiej zrozumieć nasze systemy w środowisku produkcyjnym.

Passwords, do you keep them safe?

Niektórzy uważają, że przepis na bezpieczne hasła w aplikacji [webowej] jest prosty: trochę pomieszać, czasem trochę posolić i gotowe! Tymczasem przechowywanie haseł i innych wrażliwych danych może wymagać nieco więcej zachodu. Garść przykładów tego, czego nie robić i tego, co robić, okraszonych historiami z życia wolnego strzelca. Bezwzględne stosowanie nie jest wymagane, ale pozwala uniknąć typowych niestrawności i nadmiaru kwasu. Prezentowane przykłady będą napisane w Javie, PHP i C, dlatego zrozumie je każdy programista, bez względu na język i poziom doświadczenia. W ramach edycji rozszerzonej przemigrujemy sobie zapuszczoną bazę i puścimy parę benchmarków.