poniedziałek, 21 stycznia 2013

Nocna zmiana

Mój ojciec pracował niegdyś w trybie zmianowym (zmiana poranna, popołudniowa i nocna). Wynikało to wówczas z utrzymania ciągłości produkcji w fabryce i realizacji planów gospodarki sterowanej centralnie.

Bez obaw - nie zamierzam pisać o polityce i centralnym sterowaniu gospodarką:)

Wielu programistów pracuje po nocach - niektórzy sobie to chwalą, inni przeklinają nie mogąc wyrwać się z tego programu dobowego. Mnie również się to zdarza.

Do tej pory myślałem, że są tego 3 (mniej lub bardziej) powszechnie znane przyczyny (które zapewne się nakładają na siebie):

  1. doświetlenie szyszynki przez matryce naszych komputerów, co w efekcie rozregulowuje wydzielanie melatoniny
  2. brak energii o poranku (a kumulacja wieczorem) spowodowany rozregulowaniem wydzielania kortyzolu - wynik diety opartej na węglowodanach
  3. po prostu rozproszenie przez to co dzieje się dookoła nas (to zależy jeszcze od wyczulenia percepcji któregoś ze zmysłów)
Dziś w mailingu z linkedin dostałem linka do ciekawego artykułu: Why Programmers Work At Night, w którym to autor integruje całość:
  • odnosząc się do pierwszeej przyczyny
  • odnosząc się do przyczyny trzeciej: nazywa dwa rodzaje skupienia: ludzi zarządzających vs ludzi wytwarzających (coś wartościowego;) Ludzi zarządzający dzielą czas na odcinki, ludzie tworzący kreatywne połączenia muszą "załadować sobie kontekst" - ciekawe zwerbalizowanie tego co każdy jakoś tam intuicyjnie czuje
  • podaje kolejną hipotezę: zmęczenia mózgu, która gdy się nad nią zastanowić ma "intuicyjny sens"
Kolejna hipoteza zakłada, że hiper-aktywność mózgu, która nie pozwala się nam skupić na jednej rzeczy i prowokuje do "skoków w bok"  (powszechnie znany problem) znika jeżeli mózg jest dostatecznie zmęczony. Daje to możliwość "załadowania kontekstu" i wykonania na nim operacji.

Zatem wieczorem, gdy jesteśmy już zmęczeni na tyle, że nie możemy się rozpraszać i możemy skupić się na jednym wątku następuje czas, gdy można zrobić coś sensownego:)

Szkoda tylko, że w artykule nie ma odnośników do badań:P

//=======================

O różnicach w wewnętrznym modelowaniu czasu pisałem dawno temu.

A jak to jest w Waszym przypadku?

niedziela, 13 stycznia 2013

100 mandaysów za dodanie jednego checkboxa?!?

Standardowa scenka: spotkanie tak zwanego "biznesu" z tak zwanym "IT"; dyskusja nad "małą kosmetyczną zmianą" polegającą na "dodaniu jedynie małego checkboksa".

Na minach "IT" najpierw pojawia się grymas namysłu, a następnie ekspresja (nie mikro-ekspresja) zagłady i katastrofy. W wyobraźni ujrzeli trzęsienie ziemi, która kruszy katedrę, którą budują od x miesięcy/iteracji/cokolwiek. "IT" przełyka ślinę i odpowiada: "zajmie nam to 100 mandaysów".

Mina "biznesu":

Dalszy rozwój scenariusza może przebiegać różnie w zależności o relacji - czy mamy negocjacje klient-dostawca, dział biznesowy-dział it, itd.
Typową dziecinną techniką jest zaniżanie o połowę, ale IT już wie, że "oni zawsze zaniżają", więc defaultowo  zawyża, jednak biznes, wie, że "oni defaultowo zawyżają", więc zaniża 4-krotnie, itd... wszyscy traktują się nawzajem jak by druga strona była opóźniona.

W każdym jednak przypadku "IT" jest na przegranej pozycji. Podczas gdy "my" doskonalimy się we frameworkach, wzorcach i architekturach, "oni" zdobywają siódmy czarny pas w NLP i technikach manipulacji wszystkim czym da się manipulować...

Skąd bierze się takie niezrozumienie powagi zmiany?
Najprawdopodobniej obie strony mają w swoich umysłach inne modele mentalne problemu oraz jego złożoności.

Bywalcy konferencji oraz czytelnicy książek przyprawionych nutką Agile próbują posiłkować się metaforą "Długu technicznego", który został kiedyś zaciągnięty i oto nadeszła chwila, kiedy trzeba go spłacić. "Ale jaki dług, przecież działa!" - możemy usłyszeć w odpowiedzi.

Gdyby istniał wspólny model domeny problemu, wówczas każdy uczestnik projektu "czułby" intuicyjnie powagę zmiany. Ew. naiwne uproszczenia dokonywane z wielu (zwykle racjonalnych) powodów, mogłyby być dokonywane ze świadomością konsekwencji. Uświadomiony dług techniczny.


Dla przykładu: powyżej widzimy model budynku wydrukowany przez drukarkę 3D. Nawet osoba nietechniczna intuicyjnie poczuje, że "postawienie o tutaj (wskazuje palcem na dach) lądowiska dla helikoptera" będzie "nieco" kosztowne. Trzeba przecież znacznie rozbudować konstrukcję nośną albo jeżeli chcemy ją zachować wymienić słupy na tworzywo wykradzione z NASA;)

Spróbujmy osiągnąć taki poziom świadomości gdyby obie strony siadły do: a) rysunków technicznych, b) dokumentów wizji, przeczuć i życzeń zwanych czasem dumnie artefaktami analitycznymi.

Ten przydługi wstęp miał być zachętą do zapoznania się z ostatnim z publikowanej w programistamag.pl serii "DDD krok po kroku": Modeling Whirlpool – iteracyjny proces modelowania (dostęp jest całkowicie darmowy).

Modeling Whirpool jest zwinnym procesem tworzenia wspólnego modelu, który jest zrozumiały również dla Eksperta Domenowego oraz implementowalny 1:1 w kodzie źródłowym - żadnych poziomów abstrakcji, które tworzą luki semantyczne.

//====================================

W styczniowym numerze rozpoczynam nową serię: "Niezbędnik początkującego Architekta", wktórej znajdziecie systematyzację (mam nadzieję) wiedzy bazowej oraz kilka sprawdzonych receptur.

Zainteresowanych DDD i Modeling Whirlpool zapraszam na konferencję 33rd Degree - prezentacja i warsztaty.

niedziela, 16 grudnia 2012

Testowanie automatyczne - artykuł

W najnowszym numerze programistamag.pl ukazał się kolejny artykuł z serii DDD: "Kompendium testowania aplikacji opartej o DDD – problemy, strategie, taktyki i techniki".

Artykuł można pobrać również tutaj: http://bottega.com.pl/artykuly-i-prezentacje (całkowicie free:).

Problem testowania automatycznego został osadzony w kontekście DDD, ale traktuje o testowaniu w ogólności, tak więc lektura powinna być pożyteczna dla każdego programisty i projektanta. Proponujemy w nim nieco inne spojrzenie na klasyczną już piramidę testów - dosłowne mapowanie piramidy na architekturę warstwową oraz nieco inne spojrzenie na pokrycie kodu testami.

Treść została uporządkowana wg struktury: Problemy, Strategie, Techniki, Taktyki i Narzędzia.
Jest to autorska metodyka opracowana w naszej firmie, którą stosujemy podczas coachingu z zakresu testowania automatycznego, składająca się z 2 etapów:
  • W fazie analizy sytuacji poruszamy się ścieżką top-down aby zdiagnozować cele na każdym poziomie w kontekście poziomu wyższego.
  • Natomiast w fazie wdrażania (coachingu) poruszamy się ścieżka bottom-up aby skupić się tylko na tych aspektach, które wprowadzają największą wartość.
Jeżeli wdrażasz (lub planujesz wdrożyć) zmiany we własnej organizacji to zachęcamy do wypróbowania tego podejścia i podzielenia się spostrzeżeniami.

//=======================================

Jednak główne przesłanie artykułu to: "unikaj pracy z serwerem aplikacji i bazy danych". Ile czasu zajmuje Ci cykl od momentu wciśnięcia ctrl+s w swoim IDE do przekonania się czy zmiany w kodzie są poprawne? Kilkanaście minut? Próba hotdeploymentu, przeładowanie aplikacji, które kończy się restartem serwera, przygotowanie danych, przeklikanie kilkunastu formularzy (każdy po kilka zakładek z kilkunstaoma polami) aby wreszcie zobaczyć np złą kwotę po naciśnięci "Zatwierdź" na ostatnim formularzu.

Czy po to studiowałeś/studiowałaś 5 lat?

Dzięki wydzieleniu warstwy domenowej, a w niej posługiwaniu się Bulding Blocks zgodnie z zasadami DDD osiągamy wysokie testability kodu, które pozwala na pracę z pojedynczymi fragmentami modelu przy pomocy testów jednostkowych (tanich w stworzeniu, bo unikamy sytuacji gdy potrzeba stworzyć Mock/Stub/Fake).







niedziela, 2 grudnia 2012

Java User Group - Wrocław, Szczecin, Kraków

Entuzjastów inżynierii oprogramowania (niekoniecznie związanych z Javą), zapraszam na 3 prezentacje, które odbędą się w ramach lokalnych JUGów (wstęp wolny również dla uczestników spoza JUG)

Wrocław 4 grudnia:
Tematy: Techniki strukturyzacji architektury oraz rozwinięcie do Architektury Ports & Adapters.
Szczegóły pojawią się na stronie grupy.

Szczecin 10 grudnia:
Tematy: Techniki strukturyzacji architektury oraz rozwinięcie do Architektury Ports & Adapters.
Szczegóły pojawią się na stronie grupy.

Kraków 13 grudnia:
Temat i miejsce ustalamy na grupie dyskusyjnej Polish JUG. Więcej info pojawi się gdy ustalimy szczegóły.

niedziela, 11 listopada 2012

DDD krok po proku - dostęp do artykułów i plany kolejnej serii

Ostatnie pół roku działalności bloga można podsumować krótko: marazm:)

Przyczyną jest oczywiście nawał pracy. Miesięczny "zasób weny" inwestowałem w projekt tworzenia serii artykułów "DDD krok po kroku", która ma na celu przedstawienie technik z zakresu architektury systemu, architektury aplikacji oraz implementacji projektu opartego na podejściu DDD.

Artykuły są publikowane co miesiąc w  programistamag.pl, natomiast dzisiaj - dzięki uprzejmości redakcji - możemy je udostępnić w formie niekomercyjnej - do pobrania tutaj.

W serii zaplanowane są jeszcze 2 artykuły:
  • Kompendium testowania automatycznego - problemy, strategie, taktyki i techniki
  • Kompleksowy proces modelowania DDD "Modeling Whirlpool" (z elementami BDD i Specification by Example)

Oba artykuły zostaną również udostępnione na blogu i będą ekstraktem całej naszej aktualnej firmowej wiedzy, którą stosujemy w projektach i pracy coachingowej z zespołami.

//=====================================

W planach mam kolejną serię artykułów, tym razem przeznaczoną dla początkujących programujących projektantów i programujących architektów. Seria będzie miała na celu wprowadzenie początkujących w świat podstawowych pojęć jak również zaawansowanych koncepcji oraz konkretnych rozwiązań typowych problemów.

Tematy z założenia nie będą ze sobą powiązane, jednak chciałbym wprowadzać bazowe pojęcia w początkowych artykułach aby na ich bazie budować bardziej złożone struktury.

Przykładowe tematy:
  • Trzy smaki odwracania (i utraty) kontroli 
  • Programowanie funkcyjne w Javie - kiedy i po co?
  • Fabryka dekorowanych strategii - czyli o trójpodziale logiki
  • Deus ex Machina Stanów - dlaczego potrzebujesz jej w modelu biznesowym i jak zrobić ją źle 
  • Lazy Loading w pułapce czasu - błędy logiczne, które prawdopodobnie masz i o których prawdopodobnie nie wiesz
  • Emulacja Traits w Javie - Role Object Pattern
  • Mock czy Stub? - Command-query Separation prawdę Ci powie
Jeżeli ktoś chciałby "zamówić" jakiś temat to czekam na propozycje.

czwartek, 1 listopada 2012

A teraz coś z zupełnie innej beczki: Mózg

Długi jesienny weekend może być okazją do refleksji, tak więc chciałem zaproponować temat. Temat poniekąd branżowy, jednak nie związany z systemami klasy Enterprise tudzież robieniem "internetów", nie związany z metodykami ani dywagacjami nad tym, który język "wąsaty" (wywodzący się z C++) jest słabszy ani z tym który framework przeszkadza bardziej lub czy testy lepiej pisać przed czy po:)

Temat pozwalający oderwać się od klas problemów z jakimi zmagamy się na co dzień (np. praca nad tym aby czyjś biznes działał lepiej) i nabrać do nich nieco dystansu...

Na podstawie rozmów ze znajomymi postawię tezę, że niemal każdy kto zetkną się na studiach z tematyką Sztucznych Sieci Neuronowych był nią zauroczony. Wyjątkiem mogą być nieszczęśnicy, którzy trafili na inwalidę pedagogicznego, który skutecznie tematykę obrzydził - ale pomińmy smutne wyjątki.

Jeżeli zaliczasz się do grona zauroczonych, to polecam prezentację Jeffa Hawkinsa Computing Like the Brain. Jej tytuł jest przewrotny, bo już na wstępie dowiecie się, że wg najnowszej wiedzy mózg nie jest "maszyną wykonującą obliczenia" a "jedynie" pamięcią. I to bardzo sprytną pamięcią o ciekawej charakterystyce. W dalszej części dowiecie się, że generalnie "szkolne" SSN jedynie w nazwie używają metafory sieci neuronowej, natomiast z mózgiem nie mają nic wspólnego.

Po wchłonięciu wiedzy z prezentacji zachęcam do refleksji nad: paradygmatami programowania (czy wszystko jest na pewno obiektem/funkcją?) nad paradygmatami modeli danych (sql/nosql),... Ciekawe jak nasze mózgi przyswoiły sobie paradygmaty, które są zupełnie inne niż ich wewnętrzna implementacja:P

//======================================

Sam Jeff Hawkins sam w sobie jest postacią inspirującą.

Z noty biograficznej zawartej w jego książce On Intelligence dowiedziałem się, że jako student został owładnięty rządzą zrozumienia jak działa mózg.

Jego pomysły zostały wyśmiane w kilku korporacjach, co zatem zrobił? Przez kilkanaście lat zbudował kilka biznesów niezwiązanych z mózgiem, które przynoszą mu niezłe dochody. Jeff jest na przykład człowiekiem, który opatentował algorytm rozpoznawania pisma odręcznego - prawdopodobnie używasz go na co dzień.

Po kilkunastu latach powrócił do swej pasji wyposażony w wiedzę i kapitał, który sam sobie zdobył na ten cel. Jedne z jego firm wypracowują dochód, który inwestuje w inne swe firmy prowadzące przełomowe badania nad mózgiem. Na początku z czystej ciekawości (niektórzy na prawdę tak mają), natomiast aktualnie jego rozwiązania wygrywają wyścigi tradingowe z innymi automatami. Epic Win!