Norwegian Developers Conference je třídenní konference především pro vývojáře, kteří se pohybují okolo .NETu. Témata se ale netýkají výhradně Microsoftích technologií, člověk může zajít i na velmi kvalitní přednášky o obecnějších tématech – např. přednášky Roberta C. Martina jsou zárukou kvality a i jen kvůli nim se vyplatí na NDC vyrazit.
Zajímavostí této konference je to, že v minulých ročnících dávala videa ze všech přednášek volně ke stažení. Protože konference má 8 paralelních tracků a témata i přednášející jsou na úrovni, skončil jsem poslední dva roky vždy s cca 40 staženými videy, z nichž jsem nakonec kvůli nedostatku času (já vím, bla bla bla) viděl tak 10. Proto jsem se rozhodl (a firma mi to umožnila) vyrazit na konferenci osobně a mít tak jistotu, že to nejzajímavější uvidím a vstřebám.

Místo

Konference se konala v Oslu, v hale Spektrum, která se nachází v centru Osla, hned vedle hlavního vlakového/autobusového/MHD nádraží, což je 18 minut jízdy rychlovlakem z letiště. Vlak to frčí přes 200 km/h a za jednu cestu dáte nemalých 170 NOKů (~600 Kč). Hotel jsme měli hned přes ulici, takže kromě letenky a rychlovlaku nebylo třeba řešit další dopravu.
Po příletu jsme se ubytovali, udělali registraci a cca v 18:00 vyrazili do centra Osla. Nakonec jsme stihli hned první večer vidět vše podstatné, protože slunce ne a ne zapadnout. Tma nakonec byla až kolem půlnoci a ráno kolem čtvrté už byl zase den. Horší než jetlag, z toho se člověk vyspí.
Oslo je moc pěkné čisté město, je tu hodně parků a zeleně, moderní architektura, hodně mi připomínalo Seattle. Čeho jsem si všiml hned byl velký počet imigrantů – při zběžném pohledu na ulici bych tipnul 40 %. Tolik jsem nečekal.
Další věc, kterou jsem nečekal, že zde bude plno restaurací a všechny plné lidí (v úterý večer) – podle informací v průvodcích je v Norsku taková drahota, že Norové chodí do restaurací výjimečně. Na nás to tak nepůsobilo 🙂

Den první

Konferenci zahájil Joel Spolsky (např. spoluautor StackOverflow.com) přednáškou o komunitním životě vývojářů. Mluvil o tom, že SO.com je jako město – včetně voleb, vlády, společného jazyka. Ačkoliv jsou keynoty většinou o ničem, pár zajímavých postřehů přeci jen zaznělo. Např. že co může zazdít podobný server je to, když tam začnou lidi chatovat. Proto v drtivé většině případů zavírají „subjektivní otázky“, které by mohly sklouznout směrem k diskuzi. Stejně tak zavírají otázky, které jsou příliš konkrétní – typickým znakem je dlouhý kód v otázce. Snaží se vést tazatele k tomu, aby formulovali otázku tak, aby z jejího řešení mohli v budoucnu čerpat i ostatní. Jako krystalický příklad ukázal otázku, kde se někdo ptá, kde mu v několikasetřádkovém kódu v PHP chybí závorka. Odpověď, že na řádku 143 nikomu v budoucnu nepomůže. Když už chce něco řešit něco podobného na SO, měl by se ptát, jaký je nejlepší způsob, jak v PHP hledat zapomenuté závorky.

Další přednáška, „Concurrent and High-Performance Programming in .NET with TPL, async/await, and Dataflow„, byla rychlý úvod do TPL, Rx a TPL Dataflow. Nejzajímavější pro mě byla poslední jmenovaná technologie, kterou jsem zatím podrobně nezkoumal. Vypadá to jako obecnější Rx, které navíc umožňuje paralelizaci (Rx zpracovává data ve stejném pořadí v jakém přitékají). Z jiného pohledu bych to přirovnal ke code-centric verzi Workflow Foundation.

Předobědová přednáška pro mě byla must see – Robert C. Martin povídal o „Clean Architecture and Design„. Je to skvělý řečník, takže tuto přednášku jednoznačně doporučuji ke shlédnutí.
Mně se díky ní např. potvrdilo moje vnímání, že Entity byla měla zajišťovat non-application specific chování, zatímco za application-specific věci by mělo být zodpovědné něco o úroveň výše (Interactor). A boundary je ještě něco o kousek výše.
Další bod, ve kterém jsem s Uncle Bobem naprosto souzněl, je vnímání databází. Vzhledem k běžné velikosti RAM současných serverů a velikosti zpracovávaných dat většiny firem nemá původní význam databáze smysl (nevejde se to do paměti -> musíme to persistentně uložit někam vedle). A NoSQL databáze posledních let to jen potvrzují – mnohé z nich nemají persistentní ukládání na disk (nebo třeba jen formou „minidumpu“). V aplikaci se tento přístup projeví tak, že máte nějakou Entity Gateway, která může brát entity z paměti, z databáze, … Příkladem takové gateway je třeba ORM knihovna, ale jak říká Unlce Bob – „Isolate it!“ (tzn. nepoužívejte přímo nějaké ORM, mějte to za něčím schované).

Po výborném obědu (člověk si mohl vybrat z asijské kuchyně (sushi), anglické (ehm), americké, …) jsem si vybral přednášku, která slibovala, že bude o vytváření dostupných aplikací a nezávislosti jednotlivých (sub)systémů. Takže to byla přednáška o event-driven developmentu, ukázaná na NServiceBus. Pokud chcete vidět úvodní přednášku do event-driven architektury, hledejte jinde – viděl jsem lepší.

Další můj přednášející byl Jez Humble, který nepřekvapivě přednášel o Continuous Delivery. Vypíchl nejzákladnější principy continuous integration and delivery – minimálně jednou denně commitovat do trunku (vyhnout se long-running feature branches), používat feature toggles, červený build je highest priority věc k řešení, nasazení musí být jednoduché a nudné, blue/green deployment atd. atd.

Dále přednášel opět Uncle Bob Martin, tentokráte o komponentách, především jejich závislostech a verzování, takže byla řeč o různých metrikách pro měření stability komponent apod. Nejzajímavější myšlenka, která mi uvízla v hlavě, je ta, že komponenta by vždy měla záviset na komponentách s vyšší stabilitou. To mj. znamená, že na GUI (jakožto nejméně stabilní komponentě) by nemělo NIC záviset. A když Uncle Bob říká nic, myslí opravdu nic. Tedy nedělat testy systému přes GUI. O stabilitě GUI testů už toho bylo napsáno mnoho a tato přednáška mě jen utvrdila, že děláme dobře, že máme jen velmi základní GUI testy.

Poslední přednáška dne byla o škálování velké webové aplikace. Protože se částečně o toto téma zajímám, nebylo to pro mě nic moc nového, ale přednáška to byla plná praktických rad. Byla řeč o obecných věcech (škálování HW vs. SW, caching, stavovost), backendu (škálování databází, partitioning, sharding, read replicas, denormalizace, virtualizace/cloud) i frontendu (bundling, HTTP cache, CDN, static vs. dynamic content).

Den druhý

Raději jen bodově:

• Real World Polyglot Persistence: Bohužel na můj vkus až moc real-world, ukázáno použití čtyřech databází na příkladu jednoduchého e-shopu. Hlavní myšlenka byla ta, že by člověk měl aplikaci vertikálně rozříznout a pro podvozek použít to nejlepší, co se na danou věc hodí, přičemž jako velmi hrubé vodítko může být poměr read/write. Přednášející věděl, o čem mluví, a navíc sám doporučil knihu Seven Databases in Seven Weeks, kterou jsem před přednáškou listoval a přišla mi pěkně zpracovaná 🙂
• CQRS Hypermedia with WebAPI: První polovina přednášky byla čistě o RESTu, ale druhá část, kde dával do souvislosti REST a CQRS, byla docela zajímavá. Zaujala mě např. myšlenka, že přes REST se nevystavují Entities, ale Commandy – tj. GET vrátí „template“ Commandu (~formulář pro jeho vyplnění), PUT/POST pak udělá max. input validaci a pošle to dál na backend.
• Telephones and postcards: our brave new world of messaging: Přednáška o messagingu plná analogií s reálným světem, což dělá Jimmy rád.
• Erlang: a jump-start for .NET developers: Hlavní, co jsem pochytil, jsou informace o tom, co stojí za škálovatelností kódu v Erlangu. Jednotlivé procesy (běžící v rámci Erlang VM, nejsou to ani systémové procesy ani vlákna) mají malý footprint (~300 B), rychle se startují a přepínají, a jediná jejich možnost komunikace s okolím je přes mailbox (~messages, fronta zpráv), což jsou také rychlé operace. Jednotlivé procesy jsou tak úplně nezávislé (mají i samostaný GC), takže se to škáluje samo.
• What Every Hipster Should Know About Functional Programming: Docela zábavné vysvětlení základních principů funkcionálního programování. Ponies included 😉
• Rigorous, Professional JavaScript: Nastavení prostředí pro vývoj v JS – build, kontinuální integrace, testy…
• Kolega vyhrál kvadrokoptéru! 🙂
• Večer zahrála kapela, co hraje remaky soundracků ze starých her apod. Za kapelou se promítaly ukázky z těch her, takže docela fajn.

Den třetí

• NuGet for the Enterprise: Pěkný přehled NuGetu jako takového, plus různé info o interním použití ve firmě. Např. jsem nevěděl, že existují komerční řešení postavená nad NuGetem, která řeší nějaké problémy navíc, třeba přístupová práva.
• Bleeding edge ASP.NET: See what is new and next for MVC, Web API, SignalR and more: Seznámení s novinkami v posledních verzích ASP.NET (API i tooly). Pokud sledujete vývoj ASP.NET, tak nic zásadního.
• Big Object Graphs Up Front: Mark Seemann (autor vynikající knihy Dependency Injection in .NET) byl zárukou kvality a nezklamal. Ukázal, že ve většině případů (ne vždy!) nemá cenu řešit velkou hloubků stromů závislostí – v konstruktorech nic neděláme, CLR umí vytvářet objekty velmi rychle, takže nemá důvod to být pomalé. Když už narazíme na případ, který si vyžaduje pozornost, můžeme (pokud to dává smysl) vytvoření části grafu odložit třeba pomocí proxy (pro příklad použil standardní Lazy).
  Čím mi ale nasadil brouka do hlavy bylo to, když si položil otázku, proč bychom měli takový velký strom vytvářet znovu. Když nám do aplikace chodí třeba 50 různých requestů, proč nemít postavených 50 „statických“ stromů, kterými by requesty propadávaly? Asi začínám chápat, proč je v Castle Windsor jako defaulní lifestyle použit singleton 🙂
  Jediné (ale docela podstatné :-)), co mi ještě není jasné, jak se vypořádat s objekty, které nemůžou být singleton, tj. např. nejsou immutable nebo nejsou thread-safe. Když máte takový objekt (typicky IDbConnection jako PWR) jako listy stromu závislostí, je to docela problém. Běžný přístup by znamenal, že všechno nad takovým objektem musí mít maximálně takový lifestyle jako ten objekt dole (tzn. jedině PWR nebo transient).
  Nebo se na tento problém můžeme podívat z druhé strany – když je top-level object singleton (pak máme připraven celý strom), musí být singleton i všechny jeho závislosti (a jejich závislosti atd.). A takové IDbConnection opravdu jako Singleton mít nechceme, takže je potřeba to nějak pořešit (pište do komentářů ;-)). Napadá mě třeba nějaká proxy, která by reálné IDbConnections tahala z nějaké Factory, která by zajistila PWR chování. Tady se třeba píše o scoped proxy, což vypadá přesně jako realizace mé myšlenky.
  To, co teď rozebírám, jde na první pohled proti celkovému vyznění přednášky – a je to tak. Ale my v Avastu musíme mít všechno jinak 😉 Mám totiž změřeno, že při naší zátěži resolving a GCing žere signifikantně CPU, a počty alokovaných objektů viděné přes Perfomance Countery jsou také zajímavé. A tohle by mohla být cesta.
• Under the covers with ASP.NET SignalR: Živá ukázka toho, jak si naprogramovat vlastní SignalR. Účelem přednášky bylo to, aby člověk pohopil, co se +- děje uvnitř skutečného SignalR – minimalizuje se tím pravděpodobnost, že někde něco udělá na základě mylných předpokladů. Bohužel ukázali jen implementaci pomocí Server-Sent Events a long-poolingu. Zajímalo by mě serverové řešení WebSocketů (jak to je pořešené v IIS), ale o tom bohužel přednáška nebyla.

Celkový dojem

Celá konference se odehrávala v jedné velké sportovní/hudební hale, a buď přilehlých sálech nebo byla těžkými závěsy oddělena část tribun, čímž se vytvořil další sál. Když už nebylo místo v daném sále, mohl si člověk půjčit sluchátka, naladit správný sál a koukat na přímý přenos na tribuně, před kterou bylo obrovské plátno, na které se promítalo ze všech sálů. Pěkný nápad. V hale samotné pak byly kromě informačního stánku a hlavního pódia (keynote, koncerty) stánky sponzorů, na kterých byly různé dobroty, soutěže a jiná zábava.
Další pěkná vychytávka bylo hodnocení přednášek, které bylo uděláno tou nejjednodušší, ale nejefektivnější cestou – před sálem byla krabice a hromada zelených, žlutých a červených lístečků. A protože přestávky trvaly 20 minut a venku bylo o zábavu postaráno, nezůstal v sále nikdo a téměř všichni tak hlasovali.
Abych to shrnul – úroveň přednášek byla vynikající, o změnách se informovalo, organizace nikde nevázla (ani u registrace), jídla a pití byl dostatek, takže za mě dobrý – klidně bych jel příští rok (nebo v prosinci do Londýna) zase.