Witajcie,

Jak już pisałem poszukujemy wolontariuszy do akcji Szlachetna Paczka. Aby pomoc mogła trafić do jak największej liczby rodzin potrzebujemy 30 wolontariuszy. Chwilowo nasz zespół liczy 14 osób, co bardzo łatwo przekłada się na to, że dostarczymy pomoc do połowy rodzin z tych zaplanowanych.

Dlatego apeluję do Was – włączcie się w akcję – pomnóżcie dobro na Święta.

Obowiązki wolontariusza wyglądają następująco:

• 2 wizyty u rodziny – co ważne:
• jest gotowa lista adresów – nie chodzimy i nie pukamy do drzwi na chybił trafił, tylko idziemy w konkretne miejsce,
• wolontariusze zawsze chodzą parami, nigdy samodzielnie, więc nie będziecie zdani tylko na siebie,
• wpisanie opisu rodziny do internetowej bazy,
• opieka nad darczyńcą – kimś, kto chce przygotować paczkę (kontakt telefoniczny),
• podczas finału (11-13 grudnia) obsługa darczyńcy w magazynie i dostarczenie paczki do rodziny.

Bądź szlachetny – zostań wolontariuszem!

Wydaje mi się, że była to najlepsza sesja na TechEd 2009, w jakiej miałem przyjemność brać udział, dlatego postanowiłem poświęcić jej osobną notkę. Wcześniej coś tam słyszałem o MEFie, ale na tyle mało, że chciałem dowiedzieć się więcej, szczególnie, że ta technologia znajduje się na liście moich “TODO” [ostatnio mam wrażenie, że ta lista raczej będzie się wydłużać niż skracać – przyp. autora].

O samej technologii dowiedziałem się, że jest to framework, który największy nacisk kładzie na rozszerzalność i modularność naszych aplikacji. Oczywiście od strony kodu (jak zwykle) to od nas zależy jak napiszemy aplikację i czy będzie ona łatwa do rozszerzania. W każdym razie chodzi o budowanie aplikacji poprzez dynamiczne komponowanie jej z różnych elementów. Co więcej osoby/firmy trzecie mogą pisać własne rozszerzenia do istniejących aplikacji opartych o MEFa – tu doskonałym przykładem jest plugin do VS2010, który wyświetla wiadomości z Twittera (btw. moim zdaniem Twitter sucks). Przy tej okazji należałoby też wspomnieć, że całe VS2010 i chyba również Oslo oparte są właśnie o MEFa, więc MSFT na pewno będzie dbał o ten Framework.

Podstawy MEFa:

• Export It
• Import It
• Compose It
• Catalog
• Container

A teraz co te magiczne słówka znaczą. Ogólnie chodzi o coś w rodzaju wstrzykiwania zależności (MEF wspiera CSL). Katalogi “usług” dostępne są na różnych poziomach (Type, Assembly, Directory, Aggregating). Co więcej mamy tutaj dostępne:

• Lazy Evaluation
• Context Injection – to jest mega funkcjonalność jak dla mnie, szczególnie jak zobaczyłem to w praktyce, ale o tym na końcu. Możemy też napisać własny catalog. Property AllowRecomposition mówi, czy kontekst może się zmieniać podczas uruchomienia aplikacji.

MEF vs. System.Addin

Pojawia się więc pytanie jak ma się MEF do System.Addin – czy nie jest to kolejne podejście do tego samego. To pytanie padło podczas sesji. Nie do końca. Można w uproszczeniu na MEFa patrzeć jak na architekturę pluginową, ale z tego co zrozumiałem, to chodzi trochę o zmienienie sposobu myślenia – komponujemy aplikacje poprzez dynamiczne łączenie części… Szczerze powiem, że sam nie do końca umiem to wyjaśnić. Mniej więcej czuję o co chodzi, ale gorzej z wytłumaczeniem.

Co do samego System.Addin – na pewno MEF jest prostszy i przyjemniejszy w użyciu niż System.Addin.

MEF nie ma izolacji pomiędzy domenami aplikacji.

MEF + System.Addin – takie połączenie daje izolację pomiędzy domenami aplikacji. Chyba istnieją takie rozwiązania na Codeplex.

Co jeszcze:

• Dostępna jest już aplikacja ExtensionManager, która pozwala na wybieranie sobie dodatków, które chcemy mieć “zainstalowane” w danej aplikacji.
• Rozszerzanie .NET Framework – Olson powiedział, że nie wiadomo czy się na to zdecydują, ale być może będzie można pisać własne rozszerzenia do Frameworka. Nie mówił na razie jak, ale takie coś rzucił.
• Pisanie rozszerzeń do przeglądarek internetowych – już podobno są takie projekty.
• Chmura + MEF

W praktyce – co było na demo

Na sesji nie zabrakło też części demonstracyjnej. Zawierała w zasadzie dwie części – obie powalające:

1. Mamy aplikację, która wyświetla dane z jakiegoś źródła. Źródło jest naturalnie wstrzykiwane do samej funkcjonalności wyświetlającej. Piszemy dwóch dostawców danych – jednego online, drugiego offline. W warstwie integracji określamy, że kontener będzie kontekstowy i że o kontekście będzie decydował stan sieci (offline/online). Uruchamiamy aplikację… Dane się wczytały… Wyciągamy wtyczkę sieciową… Mijają 2 sekundy… Dane zostały zamienione na dane z providera Offline… Wkładamy wtyczkę… Mijają 2 sekundy… Dane wracają do tych z providera online…
   Po tej demonstracji długo zbierałem szczękę z podłogi – jak z resztą większość sali. Efekt WOW + 10.
   
2. Ta sama aplikacja. Cały czas uruchomiona… W tym czasie my piszemy rozszerzenie, które dodaje nowy przycisk umożliwiający wysłanie wyświetlanych danych mailem. Kompilujemy… Otrzymaną dllkę wrzucamy do odpowiedniego katalogu uruchomionej aplikacji… Czekamy 2 sekundy… Pojawia nam się nowy przycisk z nową funkcjonalnością…
   Efekt WOW + 20.

Z przyczyn czasowych MEF dalej jest na mojej liście TODO, ale myślę, że już niedługo.

Dla zainteresowanych Glenn Block – PM od MEFa będzie w Polsce w ostatnim pełnym tygodniu czerwca.

Jak dla mnie R# jest genialnym narzędziem i nie bardzo wyobrażam sobie pracę bez niego :). Na szczęście nie muszę. Ale do rzeczy. Jeden z moich kolegów zaobserwował pewien problem z uruchamianiem testów NUnit poprez R#. Po poszukiwaniach dotarł do takiej dyskusji na forum:

http://jetbrains.net/devnet/thread/281286;jsessionid=8BD47E092C947293C56C7962E82A505A

Wynika stąd, że atrybut [ExpectedException] nie jest w chwili obecnej wspierany i nie wiadomo kiedy zacznie być. Można sobie poradzić używając Assert.Throws<>(delegate).

Co prawda nie ja do tego dotarłem, ale sprawa wydała mi się na tyle ciekawa i istotna, że za zgodą kolegi dzielę się z Wami tą informacją.

Jeśli ktoś ma inne doświadczenia, to chętnie poczytam.

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

Dzień 2

The Most Persistent Microsoft SQL Server Myths (and Why They Are Wrong)

Panel dyskusyjny prowadzony przez Macieja Pileckiego.

Kolejny panel dyskusyjny prowadzony przez Maćka – rzecz jasna nie mogłem sobie odpuścić, szczególnie, że temat interesujący…

1. Table variables remain only in memory

Okazało się, że to tak nie do końca jest :). Opis tabeli ląduje w tempDB, a dane jeśli się mieszczą, to mogą siedzieć w cache’u, ale to nie znaczy, że nie lądują też w tempDB. Dodatkowo dowiedziałem się, że zmienne tablicowe (nie pamiętam, czy dotyczy to również tabel tymczasowych) “przeżywają” ROLLBACK.

2. Ciekawe typy danych, które różnie są interpretowane

• Timestamp – nie ma nic wspólnego z czasem, jest wewnętrznym identyfikatorem oznaczającym wersję wiersza.
• Bit – to NIE jest to samo co boolean.
• Vardecimal – tu niestety nie pamiętam o co chodziło…

3. Clustered Index == Primary Key

To akurat wiem, że nieprawda :).

4. Clustered Index == Physical Order

To też wiem. To nie prawda. Clustered Index == Logical Order.

5. Group by ensures order

Tylko się nie zawsze zgadza, jak się niektóre operacje zrównoleglą.

6. Execution plans == query performance

Jedynie SQL Profiler prawdę Ci powie. Tak to zarówno IO Statistics, jak i plan wykonania czasami “kłamią”. W profilerze na początku najlepiej zwrócić uwagę na czas, CPU, liczbę odczytów, zużycie pamięci.

7. Identity columns are unique

Zwykle tak, ale jak się je zresetuje, to już różnie bywa.

8. Z której godziny dane znajdą się w backupie rozpoczętym o 3:00, a zakończonym o 3:30

Na pewno nie z 3:00. Prawdopodobnie z okolic 3:29, w każdym razie blisko 3:30.

9. 64-bits servers are faster :D

10. Max server memory setting

Chodziło o to, że limit odnosi się tylko do buffer pool

11. To go beyond 4GB we need 64-bits

12. Index Views are Enterprise Edition only

Są też w wersji Express, tyle że optymalizator zapytań skorzysta z nich tylko w wersji Enterprise.

Oprócz tego dodatkowa wiedza wyniesiona z sesji:

1. Unique index na kolumnie z NULLami
1. SQL 2008 – Filtered Index
2. SQL 2005 – Indexed View
2. Zmienne tablicowe (w przeciwieństwie do tabel tymczasowych) nie posiadają statystyk
3. Nieprawidłowe statystyki można podejrzewać, jeżeli jest duża różnica pomiędzy estimated cost i actual estimated cost.
4. No more BACKUP LOG WITH TRUNCATE ONLY in SQL 2008
5. Nauczyłem się fajnego żartu SQLowego:
• How much RAM does SQL Server need?
• MORE!!! :D

Ogólne wrażenie po sesji bardzo pozytywne. Jest jeszcze więcej takich mitów, sam kilka mam w głowie. Generalnie takie mity powinno się jak najczęściej obalać.

Tough Lessons Learned As a Software Project Manager

Gregg Boer

Pan z dużym bagażem jako PM, również z doświadczeniami niezrealizowanych projektów prezentował swoje przemyślenia. Było zabawnie i przekazał dużo istotnych informacji, które jak to zwykle na takich sesjach – niby są oczywiste, tylko gorzej w praktyce…

1. Pracowanie nad najważniejszą rzeczą jest bardzo trudne.
2. Trzeba zawsze mieć w tyle głowy cel całego projektu.
3. Priorytety
1. Jeśli ich nie dostajemy – ktoś źle wykonuje swoją pracę.
2. Jeśli ich nie wymagamy – sami źle wykonujemy pracę.
4. Rola PMa to często umiejętność
1. Obrony decyzji rezygnacji z danej funkcjonalności
2. Obrony decyzji realizacji danej funkcjonalności
5. Często przy realizacji danego kawałka systemu zapominamy PO CO to jest realizowane.
6. Krótkie/agresywne deadline nie motywują!!!
7. Trzeba rozumieć znaczenie i wykorzystywanie estymat.
1. Jeśli developer potrzebuje 2 dni, żeby ocenić, że pracochłonność zadania wynosi 3 to źle.
2. Jeśli pytamy kogoś ile coś będzie kosztować, mówimy o kwotach rzędu 300000$ i chcemy odpowiedź w 15 sekund, to bardzo źle.
8. Rola PMa – zaprezentować i umieć obronić rzeczywisty harmonogram.
9. Większość ryzyka w projektach jest znana i NIE zarządzana.
10. Należy osobom realizującym dane zadnie zadawać pytanie: “Co mogłoby się stać, co przeszkodziłoby Ci w realizacji tego zadania?”.
11. PM ma być szanowany, niekoniecznie popularny.

From the Trenches: Using Architectural Skills to Increase Solution Adoption Success Rates

Jim Wilt

Pan mówił o kilku elementach, na które warto zwrócić uwagę przy realizowaniu systemów:

1. Należy edukować i szkolić klienta.
2. Strategia powinna być skoncentrowana na problemie i jego rozwiązaniu, a nie na konkretnej technologii.
3. Powinniśmy się starać przekonać klienta, że to On jest właścicielem projektu i w ten sposób przesunąć ponoszone ryzyko na niego.
4. Need Approach Benefit Considerations – zwięzły sposób przekazywania idei – powinno się mieścić na jednej stronie.
5. StrategyMap (Norton & Kaplan) – do rozpoznania…

Understanding Code Extensibility

Jason Olson

Po zobaczeniu o czym będzie sesja (reguły SOLID) wyszliśmy po 15 minutach. To już znamy.

Parallel Computing APIs with the Microsoft .NET Framework 4

Mark Michaelis

Tu trafiłem dopiero w połowie i niestety to co mnie najbardziej interesowało (System.Threading.Tasks) zostało już omówione, więc z nowych rzeczy wyniosłem tylko:

1. Lazy
2. ConcurrentCollecitons
3. CHESS – narzędzie Microsoft Research do testowania aplikacji wielowątkowych.

Creating REST Enterprise Mashups Using Microsoft Office SharePoint Designer 2007

J.R. Arredondo, Dave Pae

Na tę sesję wybraliśmy się tak totalnie bezmyślnie… I okazało się, że to był strzał w 10. Korzystając z mocy, jaką dają WebServicy i SharepointDesignera Panowie w 30 minut wyklikali aplikację, która łączyła ze sobą dane z bazy danych, Twittera, serwisów pogodowych, ładnie wyglądała i prezentowała jeszcze odpowiednie informacje na GoogleMaps. Wszystko dostępne za darmo (zarówno Designer, jak i WSS, które wystarczało…)

Nie wiem jakie możliwości ma SharePoint i pewnie mało prawdopodobne, żebym szedł w kierunku dowiadywania się, ale warto było zobaczyć takie coś w praktyce. Jak znajdę chwilę to się tym pobawię, czyli najprawdopodobniej nigdy.

Tytułem Wstępu

Razem z Basią i Szymonem miałem przyjemność uczestniczyć w tegorocznym TechEdzie w Los Angeles, CA. Wrażeń jest sporo, zarówno związanych z samym pobytem w LA, jak i z konferencją. Ogólnie krótko podsumowując samo konferencje – niesamowite. Byłem i nadal jestem pod wrażeniem, że da się zorganizować konferencję dla ponad 4000 osób i wszystko dograć. Ja ze swej perspektywy nie zarejestrowałem ani jednej wpadki. Zawsze wiedziałem, w którą stronę iść, którędy udać się na posiłek, a obsługa była uśmiechnięta i przyjaźnie nastawiona do uczestników.

Dzień 0

Zarejestrowałem się już niedzielę wieczorem, chcąc ominąć poniedziałkowy tłok, poza tym w poniedziałek wyczaiłem panel dyskusyjny, który zaczynał się przed Keynote, więc wiedziałem, że trzeba będzie się sprężać ze śniadaniem.

Co do materiałów:

• Torba ogólnego zastosowania – wypasiona na maksa. Nieprzeliczalna w zasadzie ilość kieszonek.
• Kubek-termos – super, choć bardziej jako gadżet – na konferencji nie wykorzystałem ani razu.

I to w zasadzie byłoby na tyle. Poza tym niewiele reklamówek, jakieś ulotki mówiące o konkursach, kilka czasopism.

Dzień 1

Pros and Cons of Stored Procedures

Panel dyskusyjny poprowadzony przez Macieja Pileckiego.

W zasadzie sprowadzało się to do części Pros, a szkoda… Kilka wniosków płynących z dyskusji:

1. Wykorzystanie procedur składowanych to w zasadzie decyzja architektoniczna i powinny tu być brane pod uwagę 3 kwestie:
   • Dodatkowa warstwa abstrakcji
   • Bezpieczeństwo (i to jest w zasadzie ten najważniejszy aspekt)
   • Wydajność (i to jest ten najmniej ważny aspekt)
2. Zwykle nie warto nadmiernie troszczyć się o to, aby nasza aplikacja działa na Oracle, MS SQL Server, DB2 i nie wiadomo czym jeszcze – Panowie skomentowali to prosto – zadając pytanie do Sali czy ktoś kiedykolwiek musiał podczas działania już systemu zmienić silnik bazy danych. Jedna osoba na kilkadziesiąt podniosła rękę.
   Inaczej ma się kwestia, jeżeli chcemy mieć aplikację, którą możemy sprzedać kilku klientom i jeden z nich ma Oracle, a drugi MS SQL Server, ale jeżeli mamy dobrą architekturę aplikacji, to jest to tylko kwestia napisania drugiej wersji modułu dostępu do danych.
3. To coupling jest największym problemem wielu aplikacji i z niego zwykle wynika większość problemów ze skalowalnością, wieloplatformowością, itp.
4. Jeżeli mamy model domeny w couplingu z procedurami składowanymi to jest bardzo źle…
5. Na procedury składowane należy patrzeć podobnie jak na klasy/metody:
   • Powinny być małe
   • Powinny być proste
   • Powinny robić tylko jedną rzecz
   • Powinny być objęte takim samym procesem tworzenia, testowania, i wdrażania jak każdy inny element systemu.

I w zasadzie punktem 4 i 5 Panowie trafili do mnie najbardziej. Szczególnie 5 wydaje się krytyczny – nie wiem jak Wy, ale ja nie mam testów jednostkowych, które sprawdzają procedury składowane, nie mam procedur składowanych w serwerze wersji i nie zawsze mam przygotowane konkretne, sprawdzone skrypty podmieniania i wdrażania procedur składowanych.

Keynote

Tu za wiele się nie działo. Bardziej skierowane do ITPro, ale kilka ładnych demonstracji dotyczących Windows 7 i tematu wirtualizacji się pojawiło.

Modeling RESTful Data Services

Mike Flasko

Było to pokazanie aplikacji RESTowej opartej o projekt „Astoria” czyli ADO Data Services. Najważniejsze jest, aby nasze serwisy były resource-centric.

Ogólnie dostałem odpowiedź na większość pytań:

1. Autentykacja – jest pluggable.W dodatku na CodePlex jest gotowe coś co się chyba nazywa BasicAuth, oprócz tego FormsAuth jest od kopa.
2. Curl – fajne narzędzie linii poleceń do odpytywania naszej aplikacji.
3. Astoria wspiera LINQ – mapuje się to do URI.
4. Autoryzacja – trzeba napisać sobie odpowiednie QueryInterceptory.
5. Modyfikowanie wyników – trzeba napisać ChangeInterceptory.
6. Cachowanie w oparciu o HTTPCachePolicy, albo o ETag.
7. Wersjonowanie serwisu na dwóch poziomach:
   • Schema danych – IgnoreMissingProperties zapewnia nam zgodność wstecz przy dodawaniu nowych.
   • Protocol versioning (niestety nie pamiętam co Pan miał tu na myśli) jest wbudowane.

Sesję psuły tylko dwie rzeczy:

1. Kod jak to dla aplikacji przykładowych był napisany tak żałośnie, że gdybym sobie nie wymyślił na szybko jak można to napisać „ładnie”, to bym wyszedł z sesji zniesmaczony.
2. W wersji 1.5 Astorii będzie już Count – co oznacza, że teraz go nie ma, czyli ogólnie nie ma pewnie wielu rzeczy, które trzeba sobie samodzielnie napisać…

The Manycore Shift: Making Parallel Computing Mainstream

Stephen Toub

Ogólnie wiele nowego się nie dowiedziałem, ale sesja dobrze ugruntowała moje poczucie, że teraz bez wielowątkowości to jak bez ręki. Na wykresie Pan ładnie zamodelował, że w 2015 roku Parallelism Oportunity, czyli stosunek tempa przetwarzania na maszynie wieloprocesorowej do jednoprocesorowej powinien być gdzieś w okolicy 80. Czyli ogólnie bez tego się nie da.

„Best developers should fokus on business value not concurrency” – jest to jedna z najważniejszych myśli, jakie należy wynieść po tej konferencji. Samo sedno.

Oprócz tego Pan poopowiadał co nowego dostaniemy do wielowątkowego przetwarzania w C# 4.0 i VS2010, czyli było o ParallelLINQ, TasksFramework, Parallel.For, ParallelDebugger – to w większości już widziałem.

Microsoft SQL Server 2008 Nine Months Post-Release: Best Practices and Lessons Learned

Amit Shukla, Michael Wang

Tutaj mnie sesja mocno rozczarowała. Spodziewałem się ciekawych tematów, nowych wiadomości o mechanizmach, o których już słyszałem. A tu znowu sprowadziło się wszystko do pokazania co nowego w SQL Server 2008 powstało. Kilka rzeczy jednak ciekawych usłyszałem:

1. Ad-hoc workloads – plan zapytania przechowywany dopiero za drugim razem, a za pierwszym razem tylko jego namiastka. Ma to poprawić taką sytuację, że pierwszy zbiór danych, na podstawie którego generowany jest plan zapytania jest zupełnie niereprezentatywny, co powoduje później problemy wydajnościowe.
2. TableValueParameters – zasilanie bazy w taki sposób dla liczby wierszy 5-1000 jest szybsze niż seria operacji Insert i szybsze niż operacje masowe (wszelkiego rodzaju Bulk-i)
3. SELECT * FROM (VALUES …) TABLE (aaa) – zamiast korzystania ze zmiennych tablicowych – tego nie znałem.

Oprócz tego trochę informacji pojawiło się o tym w jaki sposób zgłaszać różne rzeczy do M$ i że im naprawdę zależy na feedbacku od nas.

I stało się. Meta-kontener dependency injection wspomniany przeze mnie na Speaker Idolu na WG.NET zostanie dziś opublikowany na codeplex. Jest to wspólne dzieło moje i Szymona Pobiegi.

 

Poniżej krótki opis koncepcji, założeń i celów jakie przyświecały nam przy realizacji tego projektu. 

[opis krótki, bo będę mówił na C2C o koncepcji meta-kontenera i nie chciałbym zepsuć zabawy wszystkim, którzy na C2C się wybierają, a równocześnie czytają artykuły na zine].

 

Założenia i cele:

1. Chcemy, aby nasze rozwiązania były niezależne od konkretnej implementacji kontenera DI.
2. Chcemy mieć możliwość podmienienia jednej implementacji kontenera DI na inną.
3. Chcemy mieć możliwość tworzenia kontenerów potomnych.
4. Chcemy mieć możliwość rejestrowania:
   1. Komponentów realizujących jakieś usługi.
   2. Metod fabrykujących tworzących komponenty realizujące jakieś usługi.
5. Chcemy mieć możliwość określenia czasu życia komponentów.
6. Chcemy aby interfejs meta-kontenera był rozszerzeniem CommonServiceLocatora
7. Chcemy aby nasze API było jak najprostsze i jak najmniejsze. Wszelkiego rodzaju udogodnienia chcemy zrealizować poprzez metody rozszerzające.

    

Abstrakcja:

Ogólnie o meta-kontenerze możemy myśleć w kontekście warstwy abstrakcji  nad konkretnymi kontenerami DI. W naszych aplikacjach odwołujemy się jedynie do tego API nie interesując się czy pod spodem jest Unity, Autofac, Ninject czy coś innego.

 

Krótki rzut oka na API:

I to by było na tyle, jeżeli chodzi o API. Generyczne wersje metody Register dostępne są jako ExtensionMethods.

 

Konsekwencje naszych działań:

1. Brak wsparcia dla PropertyInjection. Zdecydowaliśmy się na ten krok, gdyż istnieją frameworki, które wymagają w tym kontekście użycia specjalnego atrybutu. Dodatkowo obaj jesteśmy zdania, że należy w jasny sposób wyrażać swoje intencje, a do tego zalecamy ConstructorInjection - tzn. jeżeli jakiś obiekt zależy od pewnych usług, to określmy to wprost przez zależności w konstruktorze.
2. Nasze API jest minimalistyczne, ale naszym zdaniem do realizacji większości rozwiązań - zupełnie wystarczające. Na chwilę obecną nie ma żadnego wsparcia dla interceptorów, wstrzykiwania zależności do już istniejących obiektów, i pewnie dla wielu innych mechanizmów.
3. Obsługujemy tylko cykl życia Transient oraz Singleton.

    

   W momencie publikacji projektu zrealizowane są implementacje meta-kontenera na frameworkach:

4. Unity
5. Castle.MicroKernel, Castle.Windsor
6. Autofac

   Wszystkie te implementacje są wersjami referencyjnymi, które mają jedynie pokazać, że na tych frameworkach da się to zrobić. Równocześnie na pewno podejmiemy kroki  mające na celu współpracę z wszystkimi providerami kontenerów DI, którzy wspierają także CommonServiceLocatora.

    

   Tyle z linii frontu na chwilę obecną. Obiecuję, że więcej "mięcha" na temat meta-kontenera pojawi się po C2C, na które wszystkich serdecznie zapraszam.