Piękny przykład na problemy w komunikacji świata IT, medycyny i inżynierii przesyłu cieczy. Moim zdaniem prezentacja jest ciekawa sama w sobie merytorycznie, ale pokazuje też, że inne branże mają problemy tej samej klasy:)
Warto obejrzeć aby mieć świadomość jakie jeszcze siły działają na projekt oprócz wycieków pamięci;)
http://www.ted.com/talks/tal_golesworthy_how_i_repaired_my_own_heart
Pokazywanie postów oznaczonych etykietą z dystansu. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą z dystansu. Pokaż wszystkie posty
poniedziałek, 16 lutego 2015
wtorek, 22 lipca 2014
Everything You Were Taught About Java Is Wrong
Ciekawa prezentacja byłego pracownika Sun: http://vimeo.com/99577260
Nieco sklejona na kolanie, ale poprzez bigerpikczer pokazuje np:
Nieco sklejona na kolanie, ale poprzez bigerpikczer pokazuje np:
- skąd wzięła się kuriozalna konwencja JavaBean
- koncepcja serwera aplikacyjnego pochodzi z czasów gdy RAM liczono w dziesiątkach MB
- starając się zbyt mocno programować współbieżnie programujemy wbrew współbieżności
Ciekawe...
piątek, 14 marca 2014
Wiedza i umiejętności na poziomie Hello World
Warto przeczytać, bo wszystko o czym pisze Alex ma przełożenie również na zdobywanie wiedzy technicznej w naszej branży: http://alexba.eu/2014-03-12/rozwoj-kariera-praca/powazna-slabosc-wiekszosci-szansa-dla-nielicznych/
niedziela, 9 marca 2014
Dzień dziecka kiedyś się skończy...
Jeżeli myśleliście, że Uncle Bob skończył się na Kill'em All, to zachęcam do obejrzenia prezentacji na temat profesjonalizmu: http://vimeo.com/84676528.
Cytując z pamięci frywolne tłumaczenie:
~~Pewnego dnia jakiś mierny programista popełni jakiś głupi błąd, który spowoduje śmierć tysięcy ludzi. To nieuniknione. Wówczas politycy zaczną się nam przyglądać i zadadzą pytanie: jak mogliście do tego dopuścić (...) A później zrobią coś czego byście nie chcieli, zajmą się wprowadzaniem norm, standardów, ustaw, będą mówić nam w jakich technologiach możemy programować.~~
Tak więc Panie i Panowie: skupcie się, bo kiedyś wszyscy będziemy musieli programować w technologiach najmocniejszego lobbysty (który produkuje doskonałe klawiatury i przeciętne systemy operacyjne) i merdżować kodzik w CVS;)
//=====================================
Akcje rządowe typu "każdy powinien programować" można by jednak przemyśleć...
środa, 5 lutego 2014
Przykład rzetelości w IT
"Jak zaprojektowałbyś eksperyment aby sprawdzić swoją tezę?" - gdyby każda prezentacja w naszej branży zaczynał się od takiego stwierdzenia, to świat byłby lepszy:)
Merytorycznie świetna prezentacja, nawet jeżeli nie interesujesz się wydajnością, to warto obejrzeć pierwsze 4 minuty jak wzorcowy przykład krytycznego myślenia (myślenia nad tym co się myśli?)
http://www.infoq.com/presentations/top-10-performance-myths
Merytorycznie świetna prezentacja, nawet jeżeli nie interesujesz się wydajnością, to warto obejrzeć pierwsze 4 minuty jak wzorcowy przykład krytycznego myślenia (myślenia nad tym co się myśli?)
http://www.infoq.com/presentations/top-10-performance-myths
piątek, 10 stycznia 2014
Śmiech przez łzy #1
Pewien człowiek przeprowadził się na wieś aby rozkręcić tam interes. Dużo słyszał na salonach o tym, że "teraz wartość wejść w kury". Pozyskał zatem dofinansowanie i postawił wspaniałe kurniki przemysłowe oparte o najnowsze rozwiązania architektoniczne i wytyczne dostawców podsystemów, zastosował wszystkie modne metodyki (niektóre nawet dwa razy) i wdrożył frameworki hodowli oraz szyny dystrybucji paszy, zaczął nawet mówić do drobiu w najnowszych językach co chwilę wtrącając nawias wąsaty "{".
Pewnego dnia odwiedził go autochtoniczny sąsiad i zapytał: "Dlaczego zamiast jajek zbiera Pan gówna?"
Pewnego dnia odwiedził go autochtoniczny sąsiad i zapytał: "Dlaczego zamiast jajek zbiera Pan gówna?"
wtorek, 3 grudnia 2013
Czasowniki głupcze!
Kilka dni temu mój brat zwrócił mi uwagę na ciekawe zjawisko.
/*
Dodam, że brat z wykształcenia jest dziennikarzem, pracuje jako redaktor w radiu i dodatkowo relacjonuje wydarzenia w naszej branży w dziale Planeta IT w programistamag.pl (próbka relacji z jPikniku: Java nad Wisłą)
*/
Otóż człowiek, który na co dzień zajmuje się komunikacją, przejrzał z ciekawości kilka moich artykułów oraz tekstów innych autorów technicznych i zapytał:
- Dlaczego Ty (Wy) używacie tak namiętnie rzeczowników, rzeczowników odczasownikowych i posługujecie się namiętnie równoważnikami zdań?
- ???
- No na przykład: dokonanie faktu wystawienia faktury przez księgowego zamiast: księgowy wystawił fakturę; częste występowanie błędu zamiast: błąd występuje często itd
- Hmm w sumie nigdy się nad tym nie zastanawiałem...
I co śmieszne: powiedziałem o tym niedawno kilku osobom podczas lunchu, pośmialiśmy się sami z siebie po czym każdy nieświadomie skomentował zjawisko przy pomocy form bezczasownikowych:P
//==================================
Stare porzekadło mówi, że: język jakim mówisz determinuje sposób w jaki myślisz...
W jednym z najbliższych postów z serii DDD h4x przedstawię techniki lingwistyczne pozwalające na tworzenie behawioralnych modeli domeny (zorientowanych na czynności reguły nimi rządzące) zamiast anemicznych struktury danych wyrażonych przez rzeczowniki.
Celem będzie czytanie kodu niczym prozy, takiej w której pojawi się podmiot, orzeczenie, dopełnienie jak i nawet przydawka:)
/*
Dodam, że brat z wykształcenia jest dziennikarzem, pracuje jako redaktor w radiu i dodatkowo relacjonuje wydarzenia w naszej branży w dziale Planeta IT w programistamag.pl (próbka relacji z jPikniku: Java nad Wisłą)
*/
Otóż człowiek, który na co dzień zajmuje się komunikacją, przejrzał z ciekawości kilka moich artykułów oraz tekstów innych autorów technicznych i zapytał:
- Dlaczego Ty (Wy) używacie tak namiętnie rzeczowników, rzeczowników odczasownikowych i posługujecie się namiętnie równoważnikami zdań?
- ???
- No na przykład: dokonanie faktu wystawienia faktury przez księgowego zamiast: księgowy wystawił fakturę; częste występowanie błędu zamiast: błąd występuje często itd
- Hmm w sumie nigdy się nad tym nie zastanawiałem...
I co śmieszne: powiedziałem o tym niedawno kilku osobom podczas lunchu, pośmialiśmy się sami z siebie po czym każdy nieświadomie skomentował zjawisko przy pomocy form bezczasownikowych:P
//==================================
Stare porzekadło mówi, że: język jakim mówisz determinuje sposób w jaki myślisz...
W jednym z najbliższych postów z serii DDD h4x przedstawię techniki lingwistyczne pozwalające na tworzenie behawioralnych modeli domeny (zorientowanych na czynności reguły nimi rządzące) zamiast anemicznych struktury danych wyrażonych przez rzeczowniki.
Celem będzie czytanie kodu niczym prozy, takiej w której pojawi się podmiot, orzeczenie, dopełnienie jak i nawet przydawka:)
środa, 20 listopada 2013
Style programowania (myślenia)
Jeżeli zajmujesz się programowaniem, to na prawdę powinieneś/powinnaś obejrzeć tę prezentację: http://www.infoq.com/presentations/style-methodology
Jak często zastanawiasz się nad sposobem myślenia o problemie, który implementujesz?
Dlaczego posługujesz się tym sposobem? Czy robisz to świadomie?
Czy to, że był to ulubiony sposób myślenia o problemach twórcy danego języka programowania (pierwszego jaki poznałeś/poznałaś) i został przez tegoż twórcę "zamrożony" w składni języka jest wystarczającym powodem?
Autorka prezentacji zadaje wiele ciekawych pytań.
Od siebie dodam, że z obserwacji setek programistów i programistek wyłaniają się pewne wzorce. Generalnie każdy z nas ma pewne standardowe "modele wewnętrzne", których używa do wyobrażania sobie problemów:
Po latach zrozumiałem też, że próby oceny/krytyki kodu nie mają sensu, jeżeli posługujesz się innymi kryteriami estetycznymi niż jego twórcy.
Stawia to również pod znakiem zapytania Agileową wspólnotę kodu. Bo co jeżeli każdy, kto "udziela" się w danym fragmencie kodu chce dobrze ale każdy inaczej rozumie dobrze a przez to "ciągnie" design w swoją stronę? Powstaje to co zwykle... wielka... kupa... błota;)
Osobiście nie jestem teoretykiem języków tak jak autorka prezentacji, dlatego z najbliższym poście z serii DDD h4x przedstawię klasyfikację bazowych building blocks (bardziej ogólnych BB z DDD), które może wykorzystać z powodzeniem każdy, nie koniecznie stosując DDD jako takie.
Jak często zastanawiasz się nad sposobem myślenia o problemie, który implementujesz?
Dlaczego posługujesz się tym sposobem? Czy robisz to świadomie?
Czy to, że był to ulubiony sposób myślenia o problemach twórcy danego języka programowania (pierwszego jaki poznałeś/poznałaś) i został przez tegoż twórcę "zamrożony" w składni języka jest wystarczającym powodem?
Autorka prezentacji zadaje wiele ciekawych pytań.
Od siebie dodam, że z obserwacji setek programistów i programistek wyłaniają się pewne wzorce. Generalnie każdy z nas ma pewne standardowe "modele wewnętrzne", których używa do wyobrażania sobie problemów:
- linijki kodu
- przepływ danych
- przepływ sterowania (np podane w prezentacji "rurki")
- kształty na płaszczyźnie
- ruchome kształty w przestrzeni
- itd
- zwięzłość - jeżeli myślisz linijkami kodu, to będziesz szukać zwięzłych języków, barokowa składnia przeładowuje Twą pamięć
- harmonia - jeżeli wyobrażasz sobie kształty (język będzie nieistotny - odwrotnie niż w poprzednim przypadku)
- znalezienie ogólnych modeli (np generalne klasy - oczywiście z masą statusów:) - jeżeli lubisz uogólniać
- znalezienie szczegółowych modeli (np. wiele osobnych klas) - jeżeli lubisz różnicować
- eksploracja słownictwa domenowego
- przejście w abstrakcje (np. mapy i operacje na kolekcjach zamiast operacji domenowych)
- itd...
Po latach zrozumiałem też, że próby oceny/krytyki kodu nie mają sensu, jeżeli posługujesz się innymi kryteriami estetycznymi niż jego twórcy.
Stawia to również pod znakiem zapytania Agileową wspólnotę kodu. Bo co jeżeli każdy, kto "udziela" się w danym fragmencie kodu chce dobrze ale każdy inaczej rozumie dobrze a przez to "ciągnie" design w swoją stronę? Powstaje to co zwykle... wielka... kupa... błota;)
Osobiście nie jestem teoretykiem języków tak jak autorka prezentacji, dlatego z najbliższym poście z serii DDD h4x przedstawię klasyfikację bazowych building blocks (bardziej ogólnych BB z DDD), które może wykorzystać z powodzeniem każdy, nie koniecznie stosując DDD jako takie.
środa, 14 sierpnia 2013
niedziela, 11 sierpnia 2013
A miało być tak pięknie...
W jaki sposób zbudować formę i zaplanować treść prezentacji, która: jest prowokacyjna ale skłania do refleksji, jest arcy-śmieszna oraz obrazoburcza wobec gigantów branży i dogmatów a przy okazji jest rodzajem rozliczenia tego czego dokonaliśmy?
Na przykład tak:
Bret Victor - The Future of Programming from Bret Victor on Vimeo.
Oglądaj w pełnym skupieniu, bo każdy detal w formie, każdy szczegół w treści wyzwala wewnętrzny chichot (oczywiście o ile jesteś geekiem:).
//===========================
btw: gdzie można kupić takie ochraniacze na długopisy do kieszeni koszuli?
Na przykład tak:
Bret Victor - The Future of Programming from Bret Victor on Vimeo.
Oglądaj w pełnym skupieniu, bo każdy detal w formie, każdy szczegół w treści wyzwala wewnętrzny chichot (oczywiście o ile jesteś geekiem:).
//===========================
btw: gdzie można kupić takie ochraniacze na długopisy do kieszeni koszuli?
środa, 7 sierpnia 2013
This is where the one who knows meets the one who doesn't care
"This is where the one who knows meets the one who doesn't care" - wers z utworu Chrisa Rea; płyty Chrisa towarzyszą mi często w samochodzie gdy godzinami przemierzam trasy prowadzące do kolejnego hotelu...
Dziś będzie o próbach komunikacji i wyzwaniach jakie są z nią związane oraz (niestety) o parszywych manipulacjach. Jako studium przypadku posłuży nam coś w stylu konwersacji dwóch ekspertów, zasłużonych weteranów w naszej branży: Jim Coplien i Bob Martin debatują na temat słuszności TDD.
Zacznę od zaznaczenia, że nie zajmuję stanowiska wobec treści. Nie będę stawał po żadnej stronie w tej dyskusji, skupię się na formie i wybranych wzorcach i antywzorcach jakie możemy obserwować podczas "konwersacji" w naszej branży. Zresztą... jeżeli programujesz już od kilka lat, to zapewne wiesz, że każda nietrywialna technika działa jedynie w kontekście problemu a poza nim może być wręcz szkodliwa.
Źródło autorytetu
Jeden z interlokutorów powołuje się na autorytet własnej osoby. Cytuje sam siebie. Opiera argumenty na definicjach, które sam wymyśla.
Drugi zaś, podpiera się autorytetem zewnętrznym powołując się na cytaty innych osób. O ile nie jest to tak śmieszne jak poprzednia strategia, to czy przez to staje się bardziej wiarygodne?
Generalnie mamy tutaj zderzenie dwóch strategi kognitywnych: "co by powiedzieli inni?" vs "chrzanić innych, ja mówię jak jest".
Piętnowanie
Któż z nas nie chciałby być uważany za profesjonalistę (w polskim rozumieniu tego słowa, a nie angielskim, gdzie jest to ktoś zarabia na danej działalności)?
Jak pewnie zauważyliście, jeden z rozmówców stwierdza na wstępie, że ten, kto nie praktykuje pewnej techniki w swej pracy nie jest profesjonalistą. Techniki, która jest rdzeniem jego komercyjnych produktów:) Nie stoi za tym stwierdzeniem żadna sensowna argumentacja ani odniesienia do badań, po prostu własne "widzimisię" - wynikające ze źródła autorytetu.
Drugi z rozmówców mógłby w tym momencie zastosować tani chwyt zdając pytanie: "a co z tymi setkami tysięcy ludzi, którzy nieszczęśliwie urodzili się przed popularyzacją metodyki, czy byli szmaciarzami?" Zamiast tego powołuje się na badania, które wykazują szkodliwość metodyki (rozumianą jako zwiększenie ilości błędów) - ale pamiętajmy, że badania przeprowadzono w specyficznym kontekście.
Mowa ciała
Jaskrawe niedopasowanie rozmówców możemy zaobserwować na poziomie niewerbalnym. Jeden z nich często gestykuluje do swego centrum (w tym wypadku w kierunku splotu słonecznego). Widać silną inteligencję kinestetyczną, tok rozumowania wspierany wyobrażeniami ruchowymi.
Drugi zaś większość czasu spędza "w głowie". Zamiast dyskusji mamy więc "wymianę sygnałów" pomiędzy intuicją jednego z rozmówców a konstruktami złożonymi z abstraktów drugiego z nich.
Gdy następnym razem będziesz świadkiem jałowej dyskusji podczas spotkania projektowego zwróć uwagę na taki "szczegół" jak dopasowanie postaw rozmówców. Spotkanie będzie generalnie pozbawione sensu, ponieważ obie strony używają zupełnie innych reprezentacji mentalnych, innymi słowy mają w głowie inne modele, oparte na innych założeniach. Na poziomie werbalnym niby wszystko jest ok, ale dyskusja jakoś nie doprowadzi do konkluzji i wspólnego działania.
Pomocyyyy...
Niemowlęta mają w repertuarze swoich zachowań specjalny ruch: odruch Moro. Pomaga to im poczuć się lepiej. U dorosłych ludzi zredukowana wersja odruchu (założenie rąk ponad głowę) pojawia się nieświadomie, gdy chcieliby aby mama przyszła i zabrała ich już z niewygodnej sytuacji. Ew. dodaje nieco otuchy i pozwala zabrać myśli aby przejść do kontrataku z wykorzystaniem klasycznych technik erystycznych.
Tak, tak
Podobno ludzie kiwają głową gdy się zgadzają - ale z samym sobą (wewnętrznie w "myślach"). Tak więc jeżeli widzisz uśmieszek w kąciku ust i kiwanie głową, to masz pewność, że interlokutor przestał właśnie słuchać i testuje pławienie się w rozkoszy riposty jaką przygotował do poprzedniego zdania. Możesz skończyć wydawanie dźwięków, trafiają na /dev/null.
Dreyfus.
Model rozwoju kompetencji Braci Dreyfus jest ostatnimi czasy popularny w naszej branży. Jeżeli się z nim nie spotkałeś/spotkałaś, to zachęcam do zapoznania się z wstępem do wstępu.
Generalnie widać różnicę w targetowaniu przekazu: jeden z rozmówców celuje w odbiorców będących na I i II poziomie Dreyfus, którzy oczekują prostych i bezkontekstowych reguł postępowania. Drugi może być odebrany ze zrozumieniem tylko na kolejnych poziomach.
Nadużywanie słowa "architektura"
Mam takie przemyślenie, że najczęściej używane słowa w naszej branży: komponent, moduł i architektura są rozumiane "intuicyjnie". Czyli nikt nie wie, co to tak na prawdę jest. Szczególnie słowo "architektura" doklejane jest do tytułów książek i prezentacji służąc zwykle do zdobywania ekstra punktów reputacji;)
Obaj panowie zdają się poruszać temat Object Oriented Design, tam gdzie pada słowo architektura. Oczywiście mamy różne skale architektury (aplikacyjna, systemowa, wdrożeniowa, skalowania, bezpieczeństwa), ale generalnie rozumiem to słowo jako "design of design". Czyli w przypadku architektury aplikacyjnej będą to struktury ponad OOD (np, warstwy, heksagony, pipes&filters itd)
Na zakończenie kolejny akcent muzyczny (jeżeli nie przepadasz za starożytną muzyką, to wystarczy intro)
//=================================
A tutaj Paweł Badeński zwraca uwagę na inne ciekawe błędy oraz wyjaśnia dlaczego nasza branża nigdy nie będzie postrzegana poważnie przez tak zwane prawdziwe dziedziny nauki:)
Dziś będzie o próbach komunikacji i wyzwaniach jakie są z nią związane oraz (niestety) o parszywych manipulacjach. Jako studium przypadku posłuży nam coś w stylu konwersacji dwóch ekspertów, zasłużonych weteranów w naszej branży: Jim Coplien i Bob Martin debatują na temat słuszności TDD.
Zacznę od zaznaczenia, że nie zajmuję stanowiska wobec treści. Nie będę stawał po żadnej stronie w tej dyskusji, skupię się na formie i wybranych wzorcach i antywzorcach jakie możemy obserwować podczas "konwersacji" w naszej branży. Zresztą... jeżeli programujesz już od kilka lat, to zapewne wiesz, że każda nietrywialna technika działa jedynie w kontekście problemu a poza nim może być wręcz szkodliwa.
Źródło autorytetu
Jeden z interlokutorów powołuje się na autorytet własnej osoby. Cytuje sam siebie. Opiera argumenty na definicjach, które sam wymyśla.
Drugi zaś, podpiera się autorytetem zewnętrznym powołując się na cytaty innych osób. O ile nie jest to tak śmieszne jak poprzednia strategia, to czy przez to staje się bardziej wiarygodne?
Generalnie mamy tutaj zderzenie dwóch strategi kognitywnych: "co by powiedzieli inni?" vs "chrzanić innych, ja mówię jak jest".
Piętnowanie
Któż z nas nie chciałby być uważany za profesjonalistę (w polskim rozumieniu tego słowa, a nie angielskim, gdzie jest to ktoś zarabia na danej działalności)?
Jak pewnie zauważyliście, jeden z rozmówców stwierdza na wstępie, że ten, kto nie praktykuje pewnej techniki w swej pracy nie jest profesjonalistą. Techniki, która jest rdzeniem jego komercyjnych produktów:) Nie stoi za tym stwierdzeniem żadna sensowna argumentacja ani odniesienia do badań, po prostu własne "widzimisię" - wynikające ze źródła autorytetu.
Drugi z rozmówców mógłby w tym momencie zastosować tani chwyt zdając pytanie: "a co z tymi setkami tysięcy ludzi, którzy nieszczęśliwie urodzili się przed popularyzacją metodyki, czy byli szmaciarzami?" Zamiast tego powołuje się na badania, które wykazują szkodliwość metodyki (rozumianą jako zwiększenie ilości błędów) - ale pamiętajmy, że badania przeprowadzono w specyficznym kontekście.
Mowa ciała
Jaskrawe niedopasowanie rozmówców możemy zaobserwować na poziomie niewerbalnym. Jeden z nich często gestykuluje do swego centrum (w tym wypadku w kierunku splotu słonecznego). Widać silną inteligencję kinestetyczną, tok rozumowania wspierany wyobrażeniami ruchowymi.
Drugi zaś większość czasu spędza "w głowie". Zamiast dyskusji mamy więc "wymianę sygnałów" pomiędzy intuicją jednego z rozmówców a konstruktami złożonymi z abstraktów drugiego z nich.
Gdy następnym razem będziesz świadkiem jałowej dyskusji podczas spotkania projektowego zwróć uwagę na taki "szczegół" jak dopasowanie postaw rozmówców. Spotkanie będzie generalnie pozbawione sensu, ponieważ obie strony używają zupełnie innych reprezentacji mentalnych, innymi słowy mają w głowie inne modele, oparte na innych założeniach. Na poziomie werbalnym niby wszystko jest ok, ale dyskusja jakoś nie doprowadzi do konkluzji i wspólnego działania.
Pomocyyyy...
Niemowlęta mają w repertuarze swoich zachowań specjalny ruch: odruch Moro. Pomaga to im poczuć się lepiej. U dorosłych ludzi zredukowana wersja odruchu (założenie rąk ponad głowę) pojawia się nieświadomie, gdy chcieliby aby mama przyszła i zabrała ich już z niewygodnej sytuacji. Ew. dodaje nieco otuchy i pozwala zabrać myśli aby przejść do kontrataku z wykorzystaniem klasycznych technik erystycznych.
Tak, tak
Podobno ludzie kiwają głową gdy się zgadzają - ale z samym sobą (wewnętrznie w "myślach"). Tak więc jeżeli widzisz uśmieszek w kąciku ust i kiwanie głową, to masz pewność, że interlokutor przestał właśnie słuchać i testuje pławienie się w rozkoszy riposty jaką przygotował do poprzedniego zdania. Możesz skończyć wydawanie dźwięków, trafiają na /dev/null.
Dreyfus.
Model rozwoju kompetencji Braci Dreyfus jest ostatnimi czasy popularny w naszej branży. Jeżeli się z nim nie spotkałeś/spotkałaś, to zachęcam do zapoznania się z wstępem do wstępu.
Generalnie widać różnicę w targetowaniu przekazu: jeden z rozmówców celuje w odbiorców będących na I i II poziomie Dreyfus, którzy oczekują prostych i bezkontekstowych reguł postępowania. Drugi może być odebrany ze zrozumieniem tylko na kolejnych poziomach.
Nadużywanie słowa "architektura"
Mam takie przemyślenie, że najczęściej używane słowa w naszej branży: komponent, moduł i architektura są rozumiane "intuicyjnie". Czyli nikt nie wie, co to tak na prawdę jest. Szczególnie słowo "architektura" doklejane jest do tytułów książek i prezentacji służąc zwykle do zdobywania ekstra punktów reputacji;)
Obaj panowie zdają się poruszać temat Object Oriented Design, tam gdzie pada słowo architektura. Oczywiście mamy różne skale architektury (aplikacyjna, systemowa, wdrożeniowa, skalowania, bezpieczeństwa), ale generalnie rozumiem to słowo jako "design of design". Czyli w przypadku architektury aplikacyjnej będą to struktury ponad OOD (np, warstwy, heksagony, pipes&filters itd)
Na zakończenie kolejny akcent muzyczny (jeżeli nie przepadasz za starożytną muzyką, to wystarczy intro)
//=================================
A tutaj Paweł Badeński zwraca uwagę na inne ciekawe błędy oraz wyjaśnia dlaczego nasza branża nigdy nie będzie postrzegana poważnie przez tak zwane prawdziwe dziedziny nauki:)
czwartek, 13 czerwca 2013
3 zasady optymalizacji
- Nie optymalizuj - jeżeli na prawdę tego nie potrzebujesz - być może to "tylko" twoje ego chce się pobawić pozostając w strefie komfortu; spójrz na parking za oknem i policz ile samochodów tam stojących było projektowanych z myślą szybkości (chyba, że pracujesz w centrum Londynu:)
- Nie optymalizuj jeżeli nie rozumiesz co robisz - być może dotkniesz warstw, gdzie nie sięgają Twoje kompetencje - i być może cały Twój wysiłek zostanie zniweczony na poziomie pakietów i ramek TCP/IP lub będzie pomijalny dzięki optymalizacjom wirtualnej maszyny
- Nie optymalizuj jeżeli nie mierzysz wydajności przed i po - być może intuicja, która świetnie działa na sawannie, nie działa w świecie krzemu - i być może wysłanie kilku zapytań do bazy danych, obróbka wyników w pamięci serwera aplikacji jest lepszym pomysłem niż jedno zapytanie z 30 joinami:P
btw: pamiętaj, że wirtualna maszyna Javy "wie" o optymalizacji więcej niż znakomita większość programistów C - zwykle wystarczy się nie wydurniać, a JVM zajmie się resztą...
poniedziałek, 10 czerwca 2013
Twój mózg Cię oszukuje (gdy uczysz się nowego języka)
Dziś chciałbym polecić prezentację, którą powinien obejrzeć każdy programista: Don’t Trust Your Brain.
Treść przyda się szczególnie tym z Was, których zmuszono do nauki nowego języka programowania (jeżeli uczysz się z własnej woli, to za pewne idzie znacznie łatwiej:)
W lekki, zabawny i okraszony wiedzą za zakresu psychologii sposób dowiecie się, że składnia to przysłowiowy pikuś; kluczowe są: kultura, narzędzia, wzorce i idiomy.
//================================================
Zawsze przerażali mnie programiści klasy King Bruce Lee Karate Mistrz, którzy twierdzą, że "każdego języka mógłbym nauczyć się w tydzień (ale mi się nie chce)". Później widzimy potworki napisane np. w Javie w C albo w C# w Cobolu...
Treść przyda się szczególnie tym z Was, których zmuszono do nauki nowego języka programowania (jeżeli uczysz się z własnej woli, to za pewne idzie znacznie łatwiej:)
W lekki, zabawny i okraszony wiedzą za zakresu psychologii sposób dowiecie się, że składnia to przysłowiowy pikuś; kluczowe są: kultura, narzędzia, wzorce i idiomy.
//================================================
Zawsze przerażali mnie programiści klasy King Bruce Lee Karate Mistrz, którzy twierdzą, że "każdego języka mógłbym nauczyć się w tydzień (ale mi się nie chce)". Później widzimy potworki napisane np. w Javie w C albo w C# w Cobolu...
wtorek, 9 października 2012
ORM - "The Vietnam of Computer Science"
...cytat Teda Newarda rozbawił mnie szczerze - ale to śmiech przez łzy. Martin Fowler natomiast pyta: Ale co w zamian?
Jednak są to rozwiązania specyficznych klas problemów (podróże w czasie, wektory uczące dla Sztucznych Sieci Neuronowych) lub problemów skali Googl/Twitter/Facebbok - mimo, że nie pracujemy w tych firmach, to lubimy się na nie powoływać w swych elaboratach architektonicznych:)
W razie problemów z wydajnością warto spróbować różnych form separacji z podejścia: Command-query Responsibility Segregation.
//==========================
Więcej w archiwalnym poście, natomiast rozwinięcie w najbliższym numerze programistamag.pl
Możemy uciec się do rozwiązań typu Datoms (Encja, Atrybut, Wartość, Timestamp) lub bardziej "semantycznego" Event Sorcingu.
Jednak są to rozwiązania specyficznych klas problemów (podróże w czasie, wektory uczące dla Sztucznych Sieci Neuronowych) lub problemów skali Googl/Twitter/Facebbok - mimo, że nie pracujemy w tych firmach, to lubimy się na nie powoływać w swych elaboratach architektonicznych:)
Natomiast w typowych systemach biznesowych wystarczy przyjęcie prostych i racjonalnych zasad doboru odpowiedniego młotka do odpowiedniej klasy problemu:
- Obiekty persystentne to Agregaty, których granice są wyznaczane wg dobrych praktyk DDD: np. modelowanie niezmienników oraz modelowanie jednostki zmiany biznesowej
- Do persystencji Agregatów używamy ORM, ponieważ dobrze zakreślone granice agregatów (w tym unikanie zbędnych połączeń) rozwiązują większość problemów
- Do wydajnego odczytu danych przekrojowych nie używamy ORM - nie służą do tego typu zadań
W razie problemów z wydajnością warto spróbować różnych form separacji z podejścia: Command-query Responsibility Segregation.
//==========================
Więcej w archiwalnym poście, natomiast rozwinięcie w najbliższym numerze programistamag.pl
czwartek, 13 września 2012
Klocki czy Puzzle?
Właśnie mija północ a wraz z nią tegoroczny Dzień Programisty.
Gdybyś mógł/mogła zażyczyć sobie z tej okazji prezent od Wielkiego Elektronika mając do wyboru Klocki i Puzzle, to co byś wybrał/wybrała?
Skąd to pytanie? Obie te rzeczy dostarczają rozrywki umysłowej, jednak zupełnie innego typu. Z klocków możesz zbudować coś co sam kreujesz. Mamy wolną rękę i ograniczenia jedynie co do rodzaju klocków i sposobu ich łączenia. Generalnie są pewne reguły i wiele punktów swobody. Puzzle natomiast to wyzwanie innego typu: nie mamy swobody i poruszamy się w z góry narzuconych przez kogoś "ciasnych regułach", problem polega na ogarnięciu dużej ilości informacji (jednego typu) bez możliwości wyjścia poza "ramy".
Pozwolę sobie teraz wysnuć paralelę (trudne słowo:) do naszej pracy. Niektóre zadania lub nawet całe projekty polegają na projektowaniu, kreowaniu, eksperymentowaniu a inne na utrzymaniu i łataniu tego co jest (np legacy).
Podczas pracy z różnego rodzaju zespołami programistycznymi zauważam generalnie 2 typy programistów: szczęśliwi z tego co robią i niezbyt zadowoleni. Często jest to skorelowane z rodzajem zadań jakie zostały im przydzielone i dopasowaniem rodzaju tych zadań do potrzeb emocjonalnych. I nie chcę tutaj wartościować, jaki rodzaj jest lepszy czy gorszy - każdy ma swoje osobiste preferencje.
Chodzi o to aby w miarę możliwości świadomie podejmować zadania tego typu, który zaspokaja nasze potrzeby kognitywne i emocjonalne. Zamiast biernie dryfować lub być popychanym czy używanym przez kogoś jako narzędzie, zacznij świadomie kierować swą karierą.
Tak więc z okazji swego święta przypomnij sobie: czym wolałeś/wolałaś się bawić w dzieciństwie - klockami czy puzzlami? "...a później zacznij to robić".
Gdybyś mógł/mogła zażyczyć sobie z tej okazji prezent od Wielkiego Elektronika mając do wyboru Klocki i Puzzle, to co byś wybrał/wybrała?
Skąd to pytanie? Obie te rzeczy dostarczają rozrywki umysłowej, jednak zupełnie innego typu. Z klocków możesz zbudować coś co sam kreujesz. Mamy wolną rękę i ograniczenia jedynie co do rodzaju klocków i sposobu ich łączenia. Generalnie są pewne reguły i wiele punktów swobody. Puzzle natomiast to wyzwanie innego typu: nie mamy swobody i poruszamy się w z góry narzuconych przez kogoś "ciasnych regułach", problem polega na ogarnięciu dużej ilości informacji (jednego typu) bez możliwości wyjścia poza "ramy".
Pozwolę sobie teraz wysnuć paralelę (trudne słowo:) do naszej pracy. Niektóre zadania lub nawet całe projekty polegają na projektowaniu, kreowaniu, eksperymentowaniu a inne na utrzymaniu i łataniu tego co jest (np legacy).
Podczas pracy z różnego rodzaju zespołami programistycznymi zauważam generalnie 2 typy programistów: szczęśliwi z tego co robią i niezbyt zadowoleni. Często jest to skorelowane z rodzajem zadań jakie zostały im przydzielone i dopasowaniem rodzaju tych zadań do potrzeb emocjonalnych. I nie chcę tutaj wartościować, jaki rodzaj jest lepszy czy gorszy - każdy ma swoje osobiste preferencje.
Chodzi o to aby w miarę możliwości świadomie podejmować zadania tego typu, który zaspokaja nasze potrzeby kognitywne i emocjonalne. Zamiast biernie dryfować lub być popychanym czy używanym przez kogoś jako narzędzie, zacznij świadomie kierować swą karierą.
Tak więc z okazji swego święta przypomnij sobie: czym wolałeś/wolałaś się bawić w dzieciństwie - klockami czy puzzlami? "...a później zacznij to robić".
środa, 29 sierpnia 2012
Diabeł tkwi w przerywanych liniach
Do czego prowadzi praca w paranoi polegającej na projektowaniu oczywistych oczywistości z pominięciem istotnych szczegółów:
The Pragmatic Architect - To Boldly Go Where No One Has Gone Before
Autor w przykładach rozwiązań nawiązujących do jednego z Bulding Blocków DDD: Value Objects, spojrzał zaledwie przez dziurkę od klucza na wierzchołek góry lodowej. Więcej można znaleźć np. tu (w cenie, która w dniu publikacji posta jest bardzo atrakcyjna:).
//===================================
Pierwszy komentarz pod artykułem jest wart takiej samej uwagi na sam artykuł.
Autor w przykładach rozwiązań nawiązujących do jednego z Bulding Blocków DDD: Value Objects, spojrzał zaledwie przez dziurkę od klucza na wierzchołek góry lodowej. Więcej można znaleźć np. tu (w cenie, która w dniu publikacji posta jest bardzo atrakcyjna:).
//===================================
Pierwszy komentarz pod artykułem jest wart takiej samej uwagi na sam artykuł.
piątek, 8 czerwca 2012
Ciekawe schorzenie
Do You Suffer From Answer Syndrome?
Ja na swe usprawiedliwienie mogę powiedzieć, że to choroba zawodowa:)
Ja na swe usprawiedliwienie mogę powiedzieć, że to choroba zawodowa:)
środa, 21 marca 2012
Average polish Java developer is not an idiot for Zeus' sake!
If You live in Western Europe or US and visit Poland, You may strike general impression (looking at airport, cars, clothes fashion) that Poland is rather poor country.
Therefore: if society could not manage to generate wealthy "system", than You may infer that only logical explanation is that human beings living in given area must be somehow stupid. I don't know much about macro/psycho/social/ - economy, but let's temporarily agree about this hypothesis.
Average Java developer in Poland has mostly just a Master Degree (99,9%) in Computer Science (I guess that over 70%), usually there are just few Phds per company.
So, maybe Average Java developer in Poland is not a genius, but for Zeus' sake: when giving a talk at Java conference You don't have to explain to him/her that:
And some of us even understand laser at the quantum level:PPP
//============================================
33 Degree Conference was a great event (again), I would like to thank every single one for awesome vibes, see You next year:)))
Special thanks to Grzesiek!
Full conference summary at the weekend, after coming back home from workshop...
Therefore: if society could not manage to generate wealthy "system", than You may infer that only logical explanation is that human beings living in given area must be somehow stupid. I don't know much about macro/psycho/social/ - economy, but let's temporarily agree about this hypothesis.
Average Java developer in Poland has mostly just a Master Degree (99,9%) in Computer Science (I guess that over 70%), usually there are just few Phds per company.
So, maybe Average Java developer in Poland is not a genius, but for Zeus' sake: when giving a talk at Java conference You don't have to explain to him/her that:
- methods should be short
- code should be simple, simple, simple
- 2.0 - 1.1 is almost 0.9 when operating on doubles
- duplication in code is bad (but not always!!!)
- SSD is faster than HDD
And some of us even understand laser at the quantum level:PPP
//============================================
33 Degree Conference was a great event (again), I would like to thank every single one for awesome vibes, see You next year:)))
Special thanks to Grzesiek!
Full conference summary at the weekend, after coming back home from workshop...
poniedziałek, 27 lutego 2012
Musisz to zobaczyć!
Jeżeli jesteś developerem (a któż inny zaglądnął by w to miejsce) to na prawdę musisz to zobaczyć.
http://vimeo.com/36579366
Jak nazwiemy to "coś"? Example Driven Development? Feeling DD? TDD 2.0? What You See is What You Code?
Czekam na propozycje...
//=================================
I nie mówcie, że zabawka użyta przy wizualizacji Binary Search to gadżet dla początkujących... wszyscy znamy hakierów, którym mogłoby się to przydać w codziennej pracy:P
A teraz czas sprawdzić czy nasz serwer EE skończył już redeploy...
http://vimeo.com/36579366
Jak nazwiemy to "coś"? Example Driven Development? Feeling DD? TDD 2.0? What You See is What You Code?
Czekam na propozycje...
//=================================
I nie mówcie, że zabawka użyta przy wizualizacji Binary Search to gadżet dla początkujących... wszyscy znamy hakierów, którym mogłoby się to przydać w codziennej pracy:P
A teraz czas sprawdzić czy nasz serwer EE skończył już redeploy...
środa, 30 listopada 2011
Geneza boskich klas
Zarówno po dzisiejszej konferencji softdevcon jak i zeszłotygodniowej JDD kilka osób prosiło mnie o powtórzenie tekstu o "boskich klasach", którym staram się rozbudzić uczestników prezentacji o DDD. Postanowiłem nieco rozszerzyć opowiastkę...
Poczynania śmiałka powodują oczywiście niejednokrotnie lawiny, które rozrywają na dole i tak już nieszczelne siatki bezpieczeństwa testów.
Boska klasa aby istnieć potrzebuje ofiar. Najlepsze są młode, niewinne praktykantki. W swej naiwności opartej na akademickich wierzeniach we wszechmoc Maszyny Turinga składają się w ofierze na ołtarzu Boskiej Klasy...
Z czasem udaje im się wyrwać z grawitacji osobliwości, ale już nigdy nie będą takie jak wcześniej...
Narodziny
Każda boska klasa ma swój początek jako niewinny ośmiotysięcznik - klasa zawierająca osiem tysięcy linijek kodu.
Eskalacja
Zmiany w ośmiotysięczniku wymagają specjalnej wyprawy. Śmiałek wspina się przez kilka dni na wysokość ok piątego tysiąca próbując zrozumieć logikę/ironię kodu po czym zakłada tam bazę - rozgrzebuje kod kilkoma enterami aby zrobić sobie nieco miejsca, w którym to następnego dnia (bo aktualnie opada z wycieńczenia i niedoboru podstawowych neuroprzekaźników w mózgu) zacznie drążyć tunelik jako fundament dla nadbudówek.Poczynania śmiałka powodują oczywiście niejednokrotnie lawiny, które rozrywają na dole i tak już nieszczelne siatki bezpieczeństwa testów.
Kolaps
Z czasem ośmiotysięcznik rozrasta się aby w końcu zapaść się grawitacyjnie pod własnym ciężarem. Powstaje wówczas osobliwość, z której wyłania się Boska Klasa - klasa, która wszystko wie, wszystko potrafi i jest połączona ze wszystkim w każdym możliwym wymiarze.Boska klasa aby istnieć potrzebuje ofiar. Najlepsze są młode, niewinne praktykantki. W swej naiwności opartej na akademickich wierzeniach we wszechmoc Maszyny Turinga składają się w ofierze na ołtarzu Boskiej Klasy...
Z czasem udaje im się wyrwać z grawitacji osobliwości, ale już nigdy nie będą takie jak wcześniej...
Subskrybuj:
Posty (Atom)