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.