21. 5. 2013

GeeCON 2013 - 2. den

Zápisky z druhého dne konference GeeCON 2013

První den.

Oliver Gierke: Data Access 2.0? Please welcome - Spring Data!

Spring Data je knihovna Springu pro přístup k NoSQL databázím. Klasický springový přístup využívající návrhový vzor Template Method, podobně jako u relačních databází je JdbcTemplate nebo u JMS JmsTemplate.
  • zdůrazňoval, že Spring Data se snaží zachovat specifické vlastnosti konkrétních NoSQL databází (u NoSQL databází je vzájemná odlišnost přece jen větší než u relačních), např. podpora zeměpisných souřadnic u Monga
  • ukázky pro Mongo a Neo4J
  • Spring Data definuje vlastní anotace mající zhruba ekvivalent v JPA. Právě proto, že Spring Data je jen projekt zastřešující menší podprojekty pro konkrétní NoSQL databáze, má každý podprojekt na míru ušitou sadu anotací. Např. @Entity z JPA odpovídá u Monga @Document, u Neo4J @NodeEntity
  • MongoTemplate - obdoba JdbcTemplate
  • repositories - obdoba DAO u JDBC
  • možnost definovat dotaz anotací @Query v signatuře DAO metody a anotacemi parametrů metody vyznačit navázání parametrů dotazu
  • plugin do IDE dokáže zpracovat anotované třídy a vylepšit podle nich nápovědu jmen. Např. za findBy nabídne Name, pokud má entita takovou property
  • QueryDslPredicateExecutor - vyjádření dotazu pomocí predikátu, metoda findAll
  • integrace s CDI
  • DZone refcard pro projekt Spring Data (přednášející je leader projektu a zároveň autor taháku)

Jessica Kerr: Object-Oriented Design in the Wild

Poměrně informativní přednáška především v mluveném slovu, slajdy hrály spíš roli vyvolání emocí, bavení a dotvoření celkového efektu. Oceňuji především rozvedení základních principů OOD: SOLID, DRY, YAGNI a pár dalších. Po zhlédnutí přednášky stojí za to si je znovu projít na stránce Principy OOD nebo aspoň na wikipedii.
  • úvod o typech, třídách atd., porovnání Java/Haskell
  • rajský obrázek s podmanivou hudbou a zasněným prohlášením "Ruby is my developer joy" (u Haskellu protikladný projev) - docela vtipné
  • Single responsibility principle (S v SOLID)
    • třída by měla mít pouze jeden důvod ke změně
    • příklad se zbožím, které je na skladu, lze ho koupit a prodat:
    • Java: class Good implements InvItem,Purchase,Sellable
    • Ruby: class Good include InvItem include Purchase...
  • Interface segregation principle (I v SOLID)
    • deklarujte nejmenší možný interface
  • Liskov substitution principle (L v SOLID)
    • podtřída má properties nadtřídy, ale nemění jejich význam
    • LSP=PLS=Principle of Least Surprise
    • překvapením může být: přístup na globální stav, změna vstupního argumentu, změna okolí třídy, porušení očekávání
  • Dependency inversion principle (D v SOLID)
    • části by neměly o sobě vědět, přirovnání k linuxu: cat data.csv | grep 42 | cut -f2 | sort
  • Open-closed principle (O v SOLID)
    • knihovna je "closed for modification", ale "open for extension" aplikací, která ji používá
  • cohesion x coupling
  • Reuse-Release equivalency principle - znovupoužití kódu by mělo být umožněno ne kopírováním, ale pouze v releasech, u nichž je uživatel odstíněn od vnitřní implementace a jejichž vydání je patřičně komunikováno. Uvedla Guavu jako ukázku dodržování tohoto principu.
  • napsat komponentu s tím, že je předem plánována pro znovupoužití, je předčasná optimalizace (kořen všeho zla - Donald Knuth). Podepisuji to z vlastní zkušenosti: jakákoli i třeba dobře myšlená aktivita (nejen kus softwaru, ale třeba zavedení používání nějakého nástroje nebo firemního procesu), která vznikne rozhodnutím někoho od stolu, je odsouzena k tomu, že ji nikdo nepoužívá, nezvykne si na ni a nepřijme za vlastní. Musí vzniknout reaktivně, ne proaktivně.
  • Acyclic dependencies principle
  • Stable dependency principle
    • komponenta, na které někdo závisí, by měla být stabilnější než závisející komponenta
    • Příklad: stabilita roste zleva doprava: javascript na stránce -> JQuery -> browser
  • Stable abstraction principle
    • když mám modelovat tygra, nemodeluju ho jako něco, co implementuje rozhraní kočka a rozhraní zvíře v džungli, ale prostě jako tygra, jinak je to přeabstrahováno
  • nalézt zlatou střední cestu mezi znovupoužitelným a abstraktním
  • princip DRY
    • nepřehánět to a moc nevysušovat, nebo vznikne poušť
    • příklad: na řadě míst se vyskytuje formátování datumu, někdo z toho v dobré víře udělá společnou komponentu, ale to může být špatně, protože každý výskyt může formátovat podle jiných národních zvyklostí
    • někdy je copypaste lepší alternativa než zavlečení další závislosti na společné logice
  • princip YAGNI - kill zombie code, případně zakomentovat
  • každé pravidlo pomáhá jen do té míry, do jaké nasměruje správným směrem
  • starý kód je často lepší, protože již prokázal svůj přínos
  • svoboda porušit pravidla, pokud to dává smysl - používat selský rozum

Tom Bujok: SOAP sucks, doesn't it?

Pro mě nejlepší přednáška druhého dne. Uklidnila mě, že nejsem sám, komu připadá práce se SOAP webservisami přes nízkoúrovňové XML jednodušší a intuitivnější než přes heavyweight stacky jako CXF, Axis nebo Metro. Když jsme měli na projektu implementovat webservisy, rozhodl jsem se použít Spring Web Services (tehdy ale ještě ve verzi 1.5.9, podpora testů ještě nebyla součástí a musela se použít úžasná knihovna Lukáše Křečana) a nad nimi udělat jen tenkou vrstvu pro potřeby projektu. Tady zašli ještě dál a udělali nad Spring WS poměrně flexibilní, intuitivní a stručné API - knihovnu Reficio SOAP-WS.
Můj pohled na webservisy hodně utvářel článek Arjena Poutsmy (project leadera Spring WS) a bylo vidět, že prezentace byla v podobném duchu (rozdíl code-first x contract-first). To už sliboval i abstrakt přednášky. Poznámky:
  • pojem "buzzword driven architecture"
  • odstrašující příklad složitého psaní ws: hodně factory, builderů, práce s DOM, metoda normalize s nejasným významem - v Javě na jedné stránce
  • v protikladu Groovy příkad s XmlSlurper na 2 řádky
  • odstrašující příklad, co se musí vše definovat v CXF: wsdl, binding.xml, cxf.xml, 2x spring applicationContext, cxf-servlet.xml, web.xml, ant/maven pluginy: cxf-codegen, builderhelper
  • API postavené na builder patternu, který je použit pro vše: tvorbu message, WSDL i konfiguraci. Ukázky:
    • String message = Wsdl.parse(URL).binding().localPart(...)
    • WsdlParser
    • SoapContext().builder().alwaysBuildHeaders(true)...
    • SoapClient.builder().endpointUrl(...).basicAuthentication(...).connectTimeout(...).readTimeout(...).build().post(soapAction,message);
    • SoapServer.builder().httpPort(...).maxThreads(...).start() ... .stop()
    • RequestResponder, Source respond(request) - čistý OO návrh API pro práci se zprávou, které umožňuje ji v případě potřeby změnit, ale zůstává jednoduché v defaultním nastavení.
  • následovaly příklady a praktická ukázka, groovy demo

Trisha Gee: What do you mean, backwards compatibility?

Přednášející z vývojového týmu MongoDB, předváděla praktické zkušenosti s vývojem nového driveru pro Mongo. Vzhledem k povaze projektu, na kterém dělám (účelově zaměřený produkt pro jednoho klienta), neřešíme v oblasti kompatibility tak závažné problémy jako u softwaru typu Mongo, nicméně byla to zajímavá přehledová přednáška, i když slajdy opět spíš jen pro efekt.
  • Design is process not document
  • everybody is designer - jako by opsala některé myšlenky z prezentace Martina Čackého 
  • sepsali dvoustránkový dokument s cíli nového návrhu -> důležité ujasnit si, jaké podmínky má nové řešení splňovat
  • obecné podmínky:
    • konzistence (pořadí parametrů, zda jsou fieldy na začátku/na konci třídy, ale zas tyto maličkosti moc neřešit, důležitá je architektura)
    • cleaner design
    • intuitivní API ("users are our friends"), např. přirozené pořadí volání metod: collection.find(query).sort(sortCriteria).count()
    • sane exception handling
    • test friendly
    • backward compatible
  • žádné chyby ze statické analýzy, projití testů - nutná podmínka správně vyřešené zpětné kompatibility
  • identifikujte své uživatele - kdo to bude používat? (java developer, developer knihovny třetí strany, contributor)
  • přizpůsobení starého API, něco na způsob toho, co jednou psal Dagi 
  • souvislost se SpringData a předchozí přednáškou Olivera Gierkeho
Dotaz přednášející na to, kdo to používá, nakonec trochu zkazil jinak dobrý dojem - evidentně se zvedlo méně rukou, než čekala, důvodem byl zřejmě fakt, že lidé používají API na vyšší úrovni (viz právě předchozí zápisek o Spring Data).
Na přednášce byly použity UML diagramy nakreslené v online utilitě Gliffy. Vypadaly pěkně, až budu potřebovat zas někdy namalovat UML, tento nástroj rozhodně zvážím. Už jsem takto přešel od Photoshopu a Gimpu ve prospěch Pixlr. Myslím, že kvalita online nástrojů neustále roste. Chápu, že pro fulltime grafika nebo analytika by to asi cesta nebyla, ale pro nárazovou práci to splňuje úkol lépe než těžkotonážní systémy typu Enterprise Architect.

Slawek Sobótka: Model is all you need

Člověk zaměřený na DDD. Znalost business problematiky je u nás dost důležitá a okolo modelování se točí práce mnoha programátorů a analytiků. Kromě samotného modelování domény na úrovni entit řešíme i to, jak se do modelu promítá UI a také toho se prezentace dotkla. Prezentace byla jinak zajímavá počtem názorných přirovnání a parabol a v neposlední řadě i použitým prezentačním nástrojem prezi.com (prezentace).
  • složitost (complexity) systému
    • essential - složitost samotné povahy problému, nevyhnutelná (představuje hranici, za kterou není možné problém zjednodušit, jinak už by se řešil jiný problém)
    • accidental - složitost vyvolaná implementací konkrétního řešení problému, tu se snažíme minimalizovat
  • doménový expert a autor modelu spolupracují nad modelem
    • doménový expert předává znalost autorovi modelu
    • autor modelu tvoří mode
    • doménový expert ověřuje, že model odpovídá realitě
  • iterace: udělat nejdřív model z user story, zdokumentovat a pak konfrontovat s novým scénářem (a až pak ho teprve nakódovat). Např. objednávka má více položek, pak přijde scénář, kdy je nutno vydat jen některé položky z objednávky a doménový model se změní tak, že z entity Objednávka se stane entita Rezervace).
  • "compiler is your friend unless you have a dynamic language and you have to run it, static lanuage is not bad idea" - kolikrát už jsme se spolehli na překladač, když se při změně modelu něco rozbilo...
  • vztah mezi modelem a UI: z UI flow se musí rekonstruovat proces a zákonitosti business logiky, z nich API a z API teprve domain model
  • user story se zaměřuje na mentální model uživatele, což je ok, ale pro naprogramování to není dost
  • skvělé přirovnání, co odlišuje user story od znalosti business logiky: když hraju kulečník, můžu napsat 100000 user stories, které budou znít "když držím tágo tak, půjdou koule tam". Ale podstatné je znát to základní: zákon odrazu (business rules).
  • "objednávka má více řádků - tak si to namalujeme jako tabulku s řádky, ne jako UML s propojením ♦—, za UML vás lidi z businessu vyhodí. Řada lidí má vizuální inteligenci a potřebuje to vidět, nestyďte se za to." Trefné a svým způsobem osvobozující.
  • dobrý model sděluje informace o realitě implicitně svým návrhem. Např. má-li entita metodu Invoice issuance(Order order), říká tím model, že můžeme vydat a vyfakturovat právě jednu objednávku.
  • symetricky: Dont hack your model. Ústupky a špinavé triky v oblasti modelování core entit jsou větší zlo než např. hackování implementace kódu, který je jinak postaven nad dobrým modelem. Známe z praxe: např. špatná rozhodnutí v návrhu db tabulek nebo volba nesprávných datových struktur.
  • problém: overgeneralization (přehnané zobecnění) - např. různé nesouvisející objekty dědí z Document jenom proto, že implementuje Printable "to look more professionally"
  • klientská abstrakce modeluje koncepty nějak a v modelu můžou být úplně jiné
  • metoda approveOrder, kterou přednášející zakončil příklad, má v sobě tolik ifů, že by mohla sloužit jako startovní bod pro včerejší přednášku o refactoringu. Ale tady představuje cílový stav :-).
  • modelování peněz (vtip: kolik je 2 EUR krát 3 EUR? odpověď: 6 EUR čtverečních)
  • využití open-closed principu a návrhového vzoru Strategie - např. pro výpočet daně: rozdělit na pevnou logiku (BookKeeper), měnitelnou strategii (TaxPolicy) a logiku, která strategii nastaví do pevné logiky (Factory)
  • featura patří k doméně nebo k aplikační logice? Jak to poznat? Přirovnání: Kam patří nákupní košík?
    • když to je nějaký obchod, kde nemají košíky, tak jen k aplikační logice
    • když je košík např. součástí psychologického šetření chováni zákazniků, se kterým má aplikace počítat, pak je to součást domény
  • další přirovnání: pozoruji z okna, že Slunce obíhá Zemi, založím na tom nový programovací jazyk, bez getterů a setterů s jednořádkovými cykly a dám ho do cloudu (schválně tam nacpal co nejvíc cool věcí). Ale model mám špatně.
  • není důležité, aby model modeloval realitu, důležité je, aby modeloval situaci, na které funguje ten byznys. Pokud je byznys založen na tom, že Slunce obíhá Zemi a funguje, pak ho musím takhle namodelovat.
  • doménový expert musí mít znalost ne širokou, ale hlubokou. Kdo ví všechno o všem, není doménový expert.

Sam Newman: Surfing The Event Stream

Tato přednáška mne zajímala především proto, že často hledám ve velkém množství logů. Myšlenkou přednášky bylo zacházet se zprávami logu jako s eventy a tyto eventy přeposílat a rozesílat (do jiných systémů nebo knihoven pro zobrazení a zpracování statistik), filtrovat atd. I když řešení, které předváděl, bylo určené pro zpracování mnohem rozsáhlejších dat než naše logy, byla přednáška užitečná kvůli zmínkám o mnoha stránkách, odkazech a dalších nástrojích:
Celkový dojem: téma je mi v tomto podání vzdáleno, ale přednáška nabídla hodně odkazů ke studiu a prozkoumání. Myšlenka zpracovávat logy online, generovat události a rovnou je třídit a posílat monitorovacím systémům, je fajn.

Joel Spolsky: The Cultural Anthropology of Stack Exchange (keynote)

Autor StackOverflow, odlehčující keynote na konec, nicméně se zajímavými informacemi spíš k poslouchání než pro nějaké dlouhé poznámky.

  • yahoo answers jsou jako otázky školáků, když se vrátí ze školy - otázky do diskuse, ne do Q&A fóra
  • proč reputation? jako sociální jev, který je všude (srov. s armádou)
  • meta stackoverflow - SO o SO
  • "we hate fun" - zavírají se otázky, jaká je nejvtipnějši hláška v kódu/komentářích (neřeší problém, site je zaměřena na řešení problémů)
Třetí den.






Vystavil v

Žádné komentáře:

Okomentovat

Přihlásit se k odběru: Komentáře k příspěvku (Atom)