Jeśli programujesz, polecam 
The Productive Programmer: Mechanics
Archiwum kategorii ‘Programowanie’
The Productive Programmer: Mechanics
środa, 21 Kwiecień 2010
Software Craftsmanship, Beyond The Hype
niedziela, 14 Marzec 2010Ostatni tydzień spędziłem na konferencji QCon London (http://qconlondon.com/london-2010/) – było bardzo fajnie 
Napiszę teraz co nie co o sesji Software Craftsmanship, Beyond The Hype. Sesję poprowadził Corey Haines, który bardzo dosłownie potraktował idee “Journeyman” i jak możemy się dowiedzieć (http://www.coderetreat.com/) rok 2009 spędził podróżując po stanach ucząc programowania w parach w zamian za wikt i opierunek.
Jeśli nie słyszałeś jeszcze o Software Craftmanship, tutaj możesz przeczytać manifest. Jeśli agile jest o tym jak dostarczać oprogramowanie wysokiej jakości, to Software Craftmanship jest o tym jak kształcić deweloperów o wysokich kwalifikacjach. Corey opowiadał o tym, co w ostatnim czasie działo się w środowisku i tak:
- Rozpowszechniła się idea Code Katas
- Temat jest poruszany na konferencjach, np. ścieżka w czasie QCon
- Coderetreat - może warto coś takiego zorganizować we Wrocławiu? Corey podróżuje z tym teraz po świecie, więc można by go spróbować zaprosić.
- Powstają User Groups – btw, mamy jakieś aktywne grupy w Polsce?
- Craftsman Swaps – firmy wymieniają się pracownikami, na tydzień lub dwa. Pracownicy mogą zobaczyć jak podchodzi się do wytwarzania oprogramowania w innych “warsztatach”. Ktoś słyszał o czymś takim w Polsce?
- Craftsman Journeys – Tak jak Corey, ludzie zaczynają ruszać na dłuższe podróże, podczas których spotykają się z deweloperami z różnych zakątków świata, kodując razem z nimi i wymieniając się doświadczeniem i technikami.
- Craftsman Spikes – firmy dają możliwość chętnym, przyjść i popracować u siebie przez parę dni. Np studenci mogą przyjść ze swoim problemem i nauczyć się czegoś od praktykujących deweloperów.
Obiekty i struktury danych
poniedziałek, 1 Luty 2010Aktualnie czytam “Clean Code” Roberta Martina, więc pewnie pojawi się jeszcze kilka postów związanych z tą książką
Właśnie skończyłem czytać rozdział 6 i chciałbym tutaj zamieścić tłumaczenie podsumowania tego rozdziału.
Obiekty prezentują zachowania (funkcje) i ukrywają dane – to sprawia, że łatwo jest dodawać nowe rodzaje obiektów bez potrzeby zmiany zachowań (funkcji) istniejących obiektów. Kolejną konsekwencją jest to, że trudniej jest dodać nowe zachowanie do istniejących obiektów (wszystkie obiekty muszą się zmienić).
Struktury danych prezentują dane i nie mają żadnego znaczącego zachowania (funkcji). To sprawia, że łatwo jest dodać nowe zachowanie obsługujące istniejące struktury danych, ale trudniej dodać nowe struktury danych (bo wszystkie funkcje muszą się zmienić).
W każdym systemie będziemy chcieli czasem mieć elastyczność w dodawaniu nowych typów danych, więc wybierzemy obiekty dla tej części systemu. Kiedy indziej, będziemy chcieli łatwości w dodawaniu nowych funkcji i dla tej części systemu wybierzemy struktury danych i procedury. Dobry inżynier oprogramowania rozumie powyższe sprawy i bez uprzedzeń wybiera podejście, które najlepiej rozwiąże dany problem.
Co wy na to? Sam muszę to przemyśleć, na razie sugerowanie użycia struktur danych i procedur
wydaje mi się trochę podejrzane, ale z drugiej strony? ..
Jak pisać dobry kod?
piątek, 29 Styczeń 2010Jak pisać dobry kod? 
W TDD pracujemy w cyklach RED GREEN REFACTOR. Kiedy pierwszy raz spotkałem się z tym podejściem jednym z problemów było znalezienie odpowiedzi na pytanie: “Co i jak poprawiać w kodzie?“.
Jeśli też stawiasz sobie te pytanie, polecam Ci książkę Clean Code – można się z niej dowiedzieć wiele przydatnych rzeczy.
Tutaj znalazłem podsumowanie rozdziału 17, gdzie zebrane są wszystkie “heurystyki” i “brzydkie zapachy” związane z kodem.
Napisałem prościutki plugin do Eclipsa, który wyświetla listę tych heurystyk w okienku, dając nam możliwość sprawdzenia naszego kodu pod kątem tych heurystyk (oczywiście najpierw trzeba je znać i rozumieć) – taka ściągawka. Jeśli jesteś ciekawy tego pluginu, daj znać na maila lub w komentarzach, wyśle Ci
The Law of Leaky Abstractions
czwartek, 21 Styczeń 2010Właśnie przeczytałem stary wpis znaleziony na blogu Joel on Software.
Wpis daje parę przykładów tłumaczących “prawo przeciekających abstrakcji”. Chodzi mniej więcej o to, że mimo iż korzystamy z abstrakcji, to by poradzić sobie w trudnych sytuacjach ciągle musimy rozumieć mechanizmy, które kryją się za abstrakcją.
All non-trivial abstractions, to some degree, are leaky.
Wszystkie nie trywialne abstrakcje, do pewnego stopnia przeciekają.
Np abstrakcja TCP pretenduje, że można coś przesłać przez sieć w sposób, który gwarantuje dostarczenie. Jednak TCP jest zbudowane przy użyciu protokołu IP, który takiej gwarancji nie daje. Korzystając z TCP możemy się więc spotkać z sytuacją, że coś nie zostaje dostarczone, żeby zrozumieć czemu musimy sobie zdawać sprawę z istnienia IP.
Hello, World – Android
poniedziałek, 18 Styczeń 2010Wczoraj rano zainteresowałem się Android SDK.
Napisanie Hello World okazało się szybkie i przyjemne (dobra integracja z Eclipsem).
Gdy znajdę więcej czasu to może napiszę jakąś prostą aplikację. Kilka pomysłów mam
Aplikacje można publikować na Android Market