Dzień 3

Zen of Architecture

Juval Lowy

Ta sesja ogólnie była mocno inspirująca, również dlatego, że temat roli architekta jest ostatnio głośny w naszej firmie.

Jak zwykle garść cennych informacji do zapamiętania po tej sesji:

  1. Beginner architect sees many options. Master architect sees only a few.
  2. Unikamy zjawiska analysis-paralysis. Architekt nie powinien mieć zbyt dużo czasu na przygotowanie architektury.
  3. Dekompozycja funkcjonalna daje niewielką wartość.
  4. UML, VSTS2010-Architect – sucks.
  5. Używanie własnej, prostej notacji, która oznacza różne rzeczy w kontekstach różnych diagramów (jak na projektach sieci elektrycznych).
  6. Duuużo diagramów. Czytanie jest u nas cechą nabytą, natomiast oglądanie rysunków jest wbudowane :). Dzięki temu operacje na rysunkach wspierane są sprzętowo, a nie wymagają dodatkowego oprogramowania.
  7. Tu ciekawa teza, że wszystkie komunikacje między warstwami powinny być zrealizowane poprzez WCF. W ten sposób na pewno żadnego couplingu nie będzie. Pan wygłosił również tezę, że każda klasa powinna być usługą WCF – miał nawet sesję na ten temat, ale na tym nie byłem. Szymon natomiast był i napisał o tym nawet osobną notkę.
  8. Kolejne uwagi do komunikacji pomiędzy warstwami – powinniśmy przekazywać tylko primitives, arrays of primitives, data contracts, arrays of data contracts. Wszystko inno to ZŁO. I znowu teza dość ciekawa, ale w kontekście poprzedniej wydaje się jak najbardziej słuszna.
  9. Walidacja architektury
    1. Wykorzystywanie najmniejszej ilości komponentów, która realizuje dany przypadek użycia.
    2. Wybranie 4-6 naprawdę ważnych przypadków użycia, które odpowiadają naturze naszego systemu.
  10. Architekt powinien często zadawać pytanie “DLACZEGO”. Szczególnie, jeżeli programista chce “otworzyć” architekturę, np. umożliwić komunikację między warstwami w takim kierunku, w jakim nie powinno jej być. Bardzo często jest to konsekwencja nie zapewnienia na poziomie architektury odpowiednich mechanizmów komunikacyjnych między wybranymi warstwami (pub/sub, kolejki).
  11. Zarządzanie assembly – to powinna być decyzja architektoniczna. Assembly nie powinny być dzielone pomiędzy kilku developerów.

Ponadto to co tu wymieniłem Juval pokazał swoją własną notację architektury, pomysł na to jakie elementy powinny się w niej znaleźć i co oznaczają na jakich wykresach. To była ta mniej interesująca część. Szczerze mówiąc chciałbym zobaczyć na żywo projekt, gdzie ten koleś jest architektem i jak to jest w rzeczywistości realizowane, bo niektóre założenia są ciekawe, ale wprowadzenie ich w życie (szczególnie punktów 8 i 11) wydaje się dość kontrowersyjne. Naturalnie daje nam to na pewno luźno powiązane komponenty, ale do tego są też inne mechanizmy, niekoniecznie WCF.

TechEd Daily Scrum

Stephen Forte, Joel Semeniuk

Na tę sesję poszedłem z kilku powodów, ale głównie dla prelegentów. Stephena widziałem na dwóch panelach dyskusyjnych, a o ich wystąpieniu w duecie mówił mi Szymon w kontekście Lean Software Development. Sposób w jaki prezentacja była prowadzona mi bardzo odpowiadał – nie był to nie wiadomo jaki poziom, niemniej jednak dawka humoru wystarczała na cały dzień :).

Ciekawe wnioski, które płyną dla mnie z tej sesji:

  1. Projekt pilotażowy – jeżeli ciężko jest przekonać szefostwo do Scruma, to można spróbować w taki sposób – zaproponować realizację następnego średniej wielkości projektu wg Scruma.
  2. Sprinty powinny być środa-środa. Nie powinny zaczynać na pewno ani w poniedziałek ani w piątek.
  3. Jeżeli jedna osoba musi zostać po godzinach – cały zespół zostaje po godzinach.
  4. Pair programming?? Kiedyś to miało większy sens. Teraz przy tym co oferują obecne środowiska IDE trochę traci to na znaczeniu. Zysk nie jest aż taki jak dawniej, a koszt duży. W obecnej chwili raczej podejście Pair design + TDD, przy czym jedna osoba robi implementację, a druga pisze testy.

The World Turned Upside Down: Development Strategies for Lean Times

Na ten panel dyskusyjny trafiłem zupełnie przez przypadek – wydawało mi się, że będzie miał inny temat – dni mi się pomyliły, ale w cale nie żałuję.

Moje odczucie po byciu w stanach i po słuchaniu tamtejszych kolegów po fachu jest takie, że do nas to kryzys jeszcze nie dotarł. Oni to dopiero mają kryzys. Na TechEdzie było wcale nie mało sesji na temat tego jak radzić sobie w trudnych czasach, jak taniej wytwarzać oprogramowanie, itp. itd.

W każdym razie paneliści określili z ich punktu widzenia sporo zaleceń na te trudne czasy. Oto te z nich, które mi przypadły do gustu:

  1. Jeżeli nie chcemy aby nam przeszkadzano (całemu zespołowi) w pracy dobrze wprowadzić jakiś przedmiot, kartkę, cokolwiek… Jeżeli ta rzecz pojawi się na zewnątrz naszego pokoju, to oznacza, że nie należy nam przeszkadzać. I tutaj bardzo ważna rzecz. Twój przełożony musi to respektować. Jeżeli on nie będzie, to nikt nie będzie.\
  2. To nie są czasy, żeby pracować “9 to 5” (w domyśle – więcej).
  3. Priorytety!!! (to już kolejna sesja, na której zwracają na to uwagę).
  4. Pracuj, ucz się i rób wszystko co robisz tak, jak gdybyś to robił DLA SIEBIE. Niezależnie od tego, czy masz własną firmę, czy robisz coś u kogoś.
  5. Dobry czas na założenie własnej firmy.
  6. Czas na retooling relearning.
  7. To nie są czasy na to, żeby specjalizować się tylko w jednej rzeczy.

Building Scalable and Available Web Applications with the Microsoft Code Name "Velocity"

Scott Hanselman

Na tę sesję poszedłem głównie dlatego, że chciałem zobaczyć jak Hanselman prowadzi sesję. Bo jestem regularnym czytelnikiem jego bloga, a ostatnio słuchałem jakiegoś podcastu.

Sesja prowadzona fajnie, na wesoło, oczywiście z Twitterem :>.

Czym jest “Velocity”?

W uproszczeniu jest to rozproszona tablica haszująca. Ale taka wypasiona. Możemy wprowadzić do naszej architektury dodatkową warstwę przeznaczoną specjalnie na cache. Może też działać jako cache lokalny.

Wysoka dostępność

Bardzo istotna jest wysoka dostępność poprzez możliwość wprowadzenia redundancji cacheowania. Hanselman pokazał w praktyce jak działa redundancja cache’a i jak po odłączeniu komputera na którym dany zasób był cacheowany jako primary zasób na innym komputerze, na którym był jako secondary przeszedł nagle w primary, a na jeszcze innym, na którym go w ogóle nie było pojawił się jako secondary.

Ma mechanizm Session Provider, dzięki temu mamy wysoką dostępność bez wykorzystania cookies.

W przyszłości
  • Integracja z PerfMonem
  • Wsparcie dla/przez System Center
  • OutputCache
    • Będzie działał z chmurą
    • Będzie dostępny w chmurze

Domain Specific Languages with Team System 2010

Cameron Skinner

Tutaj okazało się, że poziom jest dla mnie za wysoki (sesja na poziomie 300). Niestety o DSLach za mało wiedziałem by zapewne wyciągnąć wszystkie dobre i złe wiadomości z tej sesji.

Dowiedziałem się jedynie, że postawiono duży nacisk na

  • interakcje modelu z widokami
  • rozszerzalność z zachowanie zgodności wstecz
    • nowe własności w nowej “wersji” naszego języka
    • walidacja modelu
    • nowe elementy modelu
  • copy/paste :) takie bardziej wypasione
  • experimental hive – możliwość uruchomienia Visual Studio w trybie do zabawy z nowym językiem, nie psując sobie istniejącego środowiska developerskiego