CodeRetreat 2013 - Uwagi i wnioski

Frekwencja i alkowigilie

W tym roku zjawiło się mniej ludzi niż poprzednio. Być może jest to spowodowane bliskością Świat i faktem, że firmy organizują swoje Wigilie na których ludzie dzielą się wódko-opłatkiem. Nie jest to w zasadzie żadna przeszkoda bo w sobotę wpadło się kilka osób, które na pewno nie byłyby w stanie prowadzić samochodu. Także pierwsze lesson learn : na kacu też da radę (jest to ważne bo w przyszłym roku pewnie też CR odbędzie w sobotę).

Języki

Chociaż najwięcej było Javy to jednak pojawia się coraz więcej innych: głównie Javascript i Python. Pomału czasy żartów z Javascriptu odchodzą w przeszłość a zaczynają się czasy żartów z ludzi, którzy myślą, że Javascript jest tylko do obsługi onlicków. Był też C++ ale mój mózg odmawia interpretacji tego języka dlatego zazwyczaj patrzyłem się 5 sekund w ekran, pytałem czy jest jakiś dylemat, który mogą pomóc rozwiązać i zazwyczaj przechodziłem dalej.

Object Calisthenics to za mało

Object calisthenics to zestaw ciekawych ćwiczeń-ograniczeń, które wykorzystujemy co roku aby ćwiczyć dobre praktyki obiektowe. No właśnie - obiektowe. Biorąc pod uwagę kierunek w jakim rozwija się Java i inne języki na JVM warto by zrozumieć co tak naprawdę stoi za tymi ćwiczeniami i dlaczego niektóre mogą pomału tracić sens.

Weźmy taki ograniczenie - "one dot per line. W tym przypadku ćwiczenie polega na tym aby nauczyć się lepiej zamykać obiekty i nie wyciągać na zewnątrz ich bebechów. Czyli nie pisać czegoś takiego :

gra.getPlansza().getStrukturaKomorek()

Ale konstrukcja poniżej ma zupełnie inny charakter :

komorki.map(transformuj).filter(tylkoZywe)

Dwa kawałki kodu o zupełnie innym charakterze, o kompletnie innej naturze. Drugi dobry ale pierwszy bardzo niedobry, bardzo bardzo zły.

Może za rok ktoś wymyśli nowy zestaw ograniczeń z ukłonem w kierunku nowych mechanizmów Javy 8? "tylko funkcje jednoparametrowe" albo "wszystko jest funkcją" ?

Ciekawe rozwiązanie

Przy okazji dyskusji and kodem Javascryptowym pojawiło się ciekawe rozwiązanie odnośnie tego jak przygotować aplikację na rozbudowę w kierunku nowych typów komórek.

Prędzej czy później każdy dochodził do reprezentacji otoczenia komórki jak czegoś ala "Sąsiedztwo". Później komórka lub coś innego (w zależności od tego gdzie jest logika transformacji) uzyskuje z Sąsiedztwa informacji o ilości żywych sąsiadów i popycha ewolucję do przodu.

Można też inaczej. Każda nowa komórka może sama dostarczyć algorytm przeżycia a Sąsiedztwo zamieni się w funkcję wyższego rzędu, która ów przepis zmaterializuje. OT coś takiego :

abstract class Cell
case class DeadCell extends Cell{
 //...
}

case class LiveCell extends Cell{
 val lifeCellEvolutionRules:(Int=>Cell)=(liveNeighbours:Int)=> {
   if(Set(2,3).contains(liveNeighbours)) LiveCell()
   else DeadCell()
  }

 def evolve(environment:(Int=>Cell)=>Cell)=environment(lifeCellEvolutionRules)
}

object Game{
 def environmentPrototype(liveNeighbours:Int)(evolutionRules:(Int=>Cell))=evolutionRules(liveNeighbours)
 
 val cell=LiveCell()
 val environment=environmentPrototype(2)_
    cell.evolve(environment)                        //> res1 = LiveCell()
}

Teraz jak dodamy sobie np. komórkę "Zombie" to może ona łatwo sama dostarczyć zasady swojej ewolucji. Uważny czytelnik zauważy, że i tak może być dupa bo nie da się łatwo rozszerzyć starych zasad o nowe typy komórek. Otóż można to łatwo rozwiązać przenosząc zasady ewolucji do odpowiedniego komponentu, który będzie również odpowiednio rozszerzany przez nowy moduł.

trait EvolutionRulesKeeper{
 def evolutionRulesFor(cell:Cell): EnvironmentData=>Cell
}

class BasicEvolutionRules extends EvolutionRulesKeeper{
 protected val rulesForLiveCell=(environmentData:EnvironmentData)=>...
 protected val rulesForDeadCell=(environmentData:EnvironmentData)=>...
 protected val evolutionRules:Map[Cell,EnvironmentData=>Cell]=Map(LiveCell()->rulesForLiveCell,DeadCell()->rulesForDeadCell)
 def evolutionRulesFor(cell:Cell)=evolutionRules(cell)
}

Foty

link do fotek

Wypalenie zawodowe

Ale jeszcze nie moje. Po imprezie była posiadówka w trakcie której jeden kolega opowiadał o szkoleniu gdzie dowiedział się jak rozpoznać nadchodzące wypalenie zawodowe. Podobno najpierw zapierdala się biorąc na siebie coraz więcej i więcej obowiązków aż nagle człowiek pęka. W Holandii podobno jest specjalny typ urlopu, który można wziąć raz w życiu z powodu wypalenia zawodowego. Ja kiedyś zrobiłem sobie trzy miesiące wakacji aby ponownie odnaleźć sens w IT po ponad 2,5 roku pracy w fabryceIT przy cybertaśmie. I jak się okazuje u nas w Polsce jak się zrobi sobie taki urlop to na wszystkich rozmowach kwalifikacyjnych ludzie są zafascynowani tym faktem ;) (niektórzy nazywali to "dziurą w życiorysie zawodowym")

*      *      *