Kosmetyka w nazwia, natomiast temat wiodący stał się mi bardzo bliski przez ostatni rok pracy w Microsofcie. Temat wydaje mi się istotny również dla społeczności programistów, którzy odkrywają C++ na nowo i/lub zainteresowani zmianami w Windows 8 przychodzą ze swoimi przyzwyczajeniami, wiedzą i doświadczeniem C++ pochodzącą z innych platform.

Jak zaznaczyłem na początku, wpis krótki. Zaznaczenie, pewnego nowego etapu, który mam nadzieję, wyda się czytelnikom interesujący.

To oczywiście semantyka C++. W C# jest to ładnie opakowane w słowem kluczowym async. Analogiczna konstrukcja metody foo w c# wyglądała by następująco:

async int foo(int bar) {} lub async void foo(int bar) {}

Wtedy pomimo deklaracji danego typu do zwrotu przygotowany jest obiekt System.Threading.Tasks.Task<int> lub System.Threading.Tasks.Task.

Jeśli sami konstruujemy własną metodę z typową operacją asynchroniczną i w ramach tej metody chcielibyśmy wywołać kilka innych operacji asynchronicznych, poczekać na ich wynik, aby nasz algorytm poprawnie zwrócił wynik, ale cały czas w tle, wtedy w języku C# możemy zastosować słowo klucz await, składnia wielce przyjemna i powodująca, że programista tak naprawdę nie widzi znaczącej różnicy w kodzie synchronicznym i asynchronicznym. Oto przykład:

async public int fooAsync(int bar)
{
      SomeOtherObject obj = new SomeOtherObject();
      await obj.firstCallAsync();
      var intval = await obj.giveMeIntAsync();
      return intvalue;
}

Taka składnia nie jest niestety dostępna z perspektywy C++. W C++ przypominam mamy dostępne interfejsy IAsyncOperation<T> oraz IAsyncAction. W obu przypadkach istotne są dla nas dwa elementy związane z rezultatem zleconego zadania. Jeden z nich to metoda GetResults(). W przypadku IAsyncOperation zwraca T, w przypadku IAsyncAction zwraca void, co jest specyficznym kuriozum przyznam, żeby widzieć metodę void GetResults(). Druga metoda jest krytyczna dla obu przypadków, jest to właściwość Completed następującego typu AsyncOperationCompletedHandler<TResult>^.

Te interfejsy podobnie jak w przypadku C# zwracają opakowane obiekty pochodzące z Concurrency Runtime (PPL). Jeśli tworzymy własną metodę asynchroniczną w C++ (naprzykład na potrzeby własnego komponentu WInRT do wykorzystania w innych językach) z Concurrency Runtime i biblioteką PPL wypadało by się zaprzyjaźnić. Poniżej podam tylko prosty przykład jak analogiczny fooAsync z C# skonstruować w C++. Najpierw synchroniczne wywołanie operacji asynchroncznej, czyli symulacja słówka kluczowego await:  

       template <typename TResult>
       TResult sync_call(Windows::Foundation::IAsyncOperation<TResult>^ asyncOp)
       {
             Concurrency::event synchronizer;
             while( 0 != synchronizer.wait(10))
             {
                    if(asyncOp->Status == Windows::Foundation::AsyncStatus::Completed)
                          return asyncOp->GetResults();
                    if (asyncOp->Status ==Windows::Foundation::AsyncStatus::Error)
                          //todo: tutaj ustaw właściwy dla siebie sposób obsługi błędów
                          //           podczas wykonania operacji asynchronicznej
                          throw std::exception("Sync call failed");
             }
             return asyncOp->GetResults();
       } 

wtedy nasza operacja synchroniczna, która chciała by wywołać operację asynchroniczną również w sposób synchroniczny wyglądałaby następująco:

int foo(int bar) 
{ 
      SomeOtherObject^ obj = ref new SomeOtherObject();
      try {
          sync_call(obj->firstCallAsync());
          auto intval = sync_call(obj.giveMeIntAsync());
          return intvalue;
      } catch (...) {
           return -1;
      } 
}

Połowa sukcesu. Teraz jak nasze zadanie wrzucić w tło i jako całość wywołać asynchronicznie? Załóżmy sobie konstrukcję gotowego obiektu i wyeksponowane w nim tylko elementy co istotniejsze dla naszego zadania:

public ref class FooContainer
{
public:
     int foo(int bar) { } 
     IAsyncOperation<int> fooAsync(int bar)     {} 
private: 
}; 

Jak wygląda foo, już wiemy. Jego wywołanie asynchroniczne to odpowiednie opakowanie w metodzie fooAsync, która powinna wyglądać następująco:

IAsyncOperation<int> fooAsync(int bar) {
    auto fooTask = create_async([=]() -> int { return foo(bar); });
    return fooTask; 
} 

Proste i czytelne prawda. Oczywiście to tylko banalny przykład. Komplet informacji w temacie jest dostępny tutaj:

• Concurrency namespace
• PPL i Concurrency Engine jest dostepny także dla klasycznego programowania w C++ (Win32, Visual Studio 2010), więcej informacji tutaj.
• Podobny artykuł po angielsku, napisany przez kolegów zza wielkiej kałuży.
• Artykuł na Windows 8 Dev Center:    

Zacznę więc może od końca.

ABI = Application Binary Interface. Po dłuższe wytłumaczenie odsyłam do Wikipedii oraz StackOverflow. W skrócie jest to abstrakcyjny interfejs dla aplikacji, za pomocą z którego komunikują się z systemem operacyjnym czy innymi aplikacjami. Opis takiego interfejsu może zawiera format danych przekazywanych danych czy parametrów, sposób wywoływania funkcji (metod), sposób w jaki aplikacja wywołuje funkcje systemowe.

Przykład ABI to prosta funkcja, która może wyglądać tak:

int function foo(int bar)
{
   return bar;
}

W ramach ABI, możemy ustalić, czy:
- parametr wejściowy jest przekazywany poprzez zarezerwowane rejestry procesora (tak często bywało przy kompilatorach i 16bitowych systemach operacyjnych).
- parametr wejściowy jest przekazywany poprzez stos i w ciele funkcji zdejmowany ze stosu (__cdecl)
- czy gdybyśmy mieli więcej parametrów to wrzucane były by na stos od lewej do prawej czy od prawej do lewej (konwencja C lub Pascalowska)
- w jaki sposób przekazywane są wyjątki
- w jaki sposób jedna platforma jest w stanie odczytać obiekt, w jaki sposób możemy go przekazać (pochodne z serializacją, marshalling)

ABI może być różne dla architektury procesora, systemu operacyjnego, kompilatora, platformy deweloperskiej w zależności od funkcji celu jaką realizuje.

WRL to skrót od Windows Runtime Library, czyli biblioteka C++ dla biblioteki systemowej Windows 8 o dźwięcznej nazwie WinRT (Windows Runtime).
WinRT same w sobie da się programować w C++, więc po co WRL?

Otóż ze względu właśnie na ABI Windows 8 i mechanizmy zaszyte w WinRT (jak możliwość projekcji bibliotek w niej zawartych na różne języki programowania, specyfika bezpieczeństwa, zarządzania pamięcią, itd) programowanie w C++ to tak naprawdę programowanie w C++/Cx. Cx to nakładka na standardowy ISO C++ zawierająca wiele ciekawych mechanizmów zawartych w składni. Mamy obiekty z daszkiem (Object^), dla których pamięć jest zarządzana poprzez liczenie referencji (refcount). Klasy mogą być zamknięte dla dalszego dziedziczenia (sealed). Klasy mogą mieć właściwości (properties) i akcesory (get/set), to tylko przykłady dodatkowych elementów języka pomocnych w tym, aby jedna spójna biblioteka była dostępna dla wszystkich języków programowania wspieranych systemowo (C++, C#, VB, Javascript).

Z perspektywy programisty C++ widoczne są dwie opcje, albo zaakceptuje te zmiany w języku i efektywnie korzystając z biblioteki WinRT może napisać aplikację Windows 8, albo...

... przyjrzy się skrótowi WRL, który to jest biblioteką COM wykorzystująca tylko ISO C++, nie ma daszków i innych rzeczy, których purysta C++ nie chce zaakceptować.
Składnia jest trochę pokręcona (na pewno więcej linii kodu), ale właśnie wynika to z ABI.. 

Dlaczego COM? Otóż całe Windows RT zostało napisane w znacząco zmienionej wersji, ale wciąż COMa.

De facto wielu programistów C++, którzy korzystają tylko z WRL już zaczęło w żargonie mówić, że programują w ABI, kiedy to wykorzystują czyste C++ i bibliotekę WRL.

WRL jest wciąż słabo udokumentowane na stronach MSDN, więc jeśli jesteście zainteresowani konkretniejszą dawką wiedzy, polecam prezentacje z konferencji Microsoft (Build i Developing Windows 8 Metro styled  apps with C++):

https://channel9.msdn.com/Events/Windows-Camp/Developing-Windows-8-Metro-style-apps-in-Cpp/The-Windows-Runtime-Library-WRL
https://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%2fecn.channel9.msdn.com%2fevents%2fWin8CppEvent%2fWRL.pptx

https://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-532T#c634517976543836549

Przejdę zatem do sedna i spróbuję tak skrótowo opisać coś co ponownie i po wielu latach stało się moją wielką pasją, czyli nazwijmy sobie.. takie ćwiczenie hobbistyczne doskonałości kodu w C++.
Kiedyś, jeszcze za młodzieńczych czasów demoscenowych, wspólnie ze znajomymi z którymi w tej społeczności się rozwijaliśmy, potrafiliśmy tygodniami siedzieć nad małymi fragmentami kodu i upojnie zastanawiać się jak pewne rzeczy można zrobić lepiej. Zmiana a raczej dalsza ewolucja standardu języka C++ dostarczyła impulsu potrzebnego, aby ponownie zacząć zadawać sobie z pozoru głupie pytania. Z drugiej strony jednak.. jeśli komuś zależy na pełnej kontroli tego co nazywa kodem, na pewno na wiele rzeczy w nowym C++ już zdążył zwrócić uwagę. Jeśli nie to pozwolę sobie taki artykuł wysmarować jako start do pewnej dyskusji...

Drobne zmiany składniowe

Zacznijmy od drobnostek takich jak chociażby auto. Przez wiele lat programowania w C#/.NET Framework przywykłem do tego, że mam coś takiego jak var. Dla wygody szybkiego programowania, kiedy to pozwalamy sobie na zaufanie dla kompilatora, który z łatwością odgadnie jaki nazwany typ ma zastosować przy uruchomieniu naszego kodu, var jest bezcenne. Ale właśnie.. w C# i przynajmniej przy moich mocno uproszczonych, ale i mocno czytelnych technikach projektowania obiektowego ten var to tak naprawdę element lenistwa, który mi koledzy z Redmond dostarczyli. Intellisense sam w sobie był przez te wszystkie lata wystarczającym mechanizmem, aby odpowiedni typ w odpowiedniej linijce kodu się po prostu znalazł po kilku wpisanych znakach. Trzech... czterech, jak auto czy var. 

W C++ zaś auto, pełniący podobną funkcje odbierany jest przeze mnie o wiele mocniej. Zwłaszcza przy predykatach, iteratorach czy innych tymczasowo przetrzymywanych obietkach pochodzących z szablonowych obiektów chociażby biblioteki STL. Deklarowanie typu dla tworzonego w locie wyrażenia Lambda... auto, auto, auto...

Wyrażenia Lambda pominę w tym wpisie. Poświęciłem tej koncepcji kilka wpisów lata temu. Wróćmy do prostych, acz sympatycznych rzeczy.

(unsigned) long long zamiast __int64

Niby drobnostka, ale spójna. Zwłaszcza, że wg definicji standardu long long to nie stricte 64 bity tylko maksymalna wielkość liczby całkowitej jaką jest w stanie obsłużyć architektura CPU.
Po co..? Dla optymalizacji obliczeń matematycznych zgodnych z architekturą komputera na którym pracujemy. Zakładam, że jak kiedyś do nas dojdą komputery 128 bitowe to ta sama deklaracja

long long a = 1; 
long long b = 2;
long long c = a+b;

wygeneruje nam odpowiednie rozkazy opierające się na bieżącej architekturze CPU.

Nie chcemy wiedzieć, czy to na koniec jest: 

mov eax, 1
mov ebx, 2
add eax, ebx
mov ecx, eax

czy cokolwiek innego..

Chcemy wiedzieć, że jak możliwości matematyczne komputerów się zwiększą, a zależy nam na maksymalnym zasięgu liczbowym, to nie będziemy musieli robić refactoringu.
Wystarczy teraz określić odpowiedni typ, który jest zgodny ze standardem, czyli powinien być zaimplementowany przez każdy kompilator, który jest z nim zgodny. 

Na dzień dzisiejszy dyskusja jest mocno teoretyczna. Zawarta jest jednak w definicji samego standardu: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1811.pdf 

NULL

Pominę długie tłumaczenie wprowadzenie kolejnego słowa kluczowego, nullptr. Dla kogoś kto chciał rozróżnić wartość 0L od NULL, który zwykle wszędzie byl definiowany jako #define NULL 0L sens powinien się właśnie ujawnić.

RValues oraz LValues

Trudne hasła, bo jeśli nie do końca rozumiemy mechanikę języka, to zwykle tego typu nazwy widzimy w komunikatach błędów kompilatora.
Bardzo dobre wyjaśnienie do tej części dostarcza stary już wpis teamu odpowiedzialnego za Visual C++:
https://blogs.msdn.com/b/vcblog/archive/2009/02/03/rvalue-references-c-0x-features-in-vc10-part-2.aspx

W praktyce, po zmianach w standardzie, nie powinniście mieć problemu chociażby z kompilacją czegoś takiego:

#include <iostream>
#include <string>

using namespace std;

int main()
{
   string s = string("h") + "e" + "ll" + "o";
   cout << s << endl;
}

Dodatkowym efektem wprowadzenia zmian związanych z przekazywaniem referencji do tymczasowych obiektów jest konstruktor przeniesienia (move constructor).
Dzięki niemu za pomocą prostej deklaracji i kodu, który za nią pójdzie, obok konstruktora kopiującego, możemy zadeklarować takowy:

SimplestMoveableObject(SimplestMoveableObject&& moveSource)

i/lub operator przypisania takowy:

SimplestMoveableObject& operator=(SimplestMoveableObject&& moveSource)

i wiele z operacji, które reprezentują nasz kod mają szansą odbyć się bez zbędnego kopiowania dużej ilości danych, które często nasze obiekty w sobie kryją.

Ach te szablony!

Na koniec jeszcze kilka zdań na temat static_assert. Sprzed zmiany standardu mieliśmy oczywiście makro ASSERT oraz dyrektywę #error.

Feller niestety polega na tym, że słabo się przydają przy szablonowych klasach (templates). Dlaczego? 
Odpowiedź jest prosta.. klasyczny ASSERT zrzuca błędy po uruchomieniu, natomiast prawdziwy vs. deklarowany kształt obiektów szablonowych widzimy dopiero na etapie kompilacji.
Przydałoby się narzędzie, które na etapie kompilacji szablonów pozwoliło by nam wychwycić możliwe nieprawidłowości.
Do tego właśnie służy static_assert!

Dobry przykład z pierwszej części wspomnianego przeze artykułu na vcblog

template <int N> struct Kitten {
    static_assert(N < 2, "Kitten<N> requires N < 2.");
}; 

int main() {
    Kitten<1> peppermint; 
    Kitten<3> jazz;
}

Jeśli są pewne błędy w szablonie wynikające z nieprawidłowego podania parametrów do niego, static_assert pomaga je sprawdzić i zakomunikować.

To tylko pierwsze przykłady, drobnych ale i mocnych zmian. Jak widać po referencyjnych blogach, wcale nie od dzisiaj zaimplementowane w Visual C++.
Wierzę jednak, że przez fakt, że poza tematem gier C++ w środowisku Windows wcale nie musiało być tak często wykorzystywane, te rzeczy mogły być przez wielu z was niezauważone.
W dobie Windows 8 i mocnego wsparcia dla C++ przy tworzeniu aplikacji Metro, temat C++ wraca. Wraz z nim temat możliwie najlepszych praktyk w programowaniu w języku, który nie jest łatwy, ale jak się go opanuje, to dostarcza chyba największej frajdy z kontroli tego co się wokół dzieje.

Temat nowego standardu jest oczywiście o wiele szerszy. Zmiany dotyczą zarówno samego składnika, jak i biblioteki standardowej (STL).
Kolejnym dobrym punktem startu w tym temacie jest chociażby tabelka zamieszczona na tym wpisie:
https://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx 

Zawiera w miarę kompletną informację o tym, jak przy okazji przemiery VS11, do wsparcia dla C++11 podchodzi ekipa Visual C++.

pozdrawiam po dłuższej przerwie,
Daniel Biesiada 

W ramach odpowiedzi pokazałem mu zaciśniętą pięść i rzekłem: to jest PROJEKT.

Trochę się zdziwił, więć poszedłem dalej i pokazałem pełną dłoń i 5 palców. Powiedziałem: z tylu części składa się projekt.

Troche się rozjaśniło, ale wytłumaczyłem do końca...

Najmniejszy palec to pomysł. Niby nic, takie małe, ale bardzo ważne. Następny palec to ludzie, których trzeba znaleźć do pomocy, bo mało jest takich projektów, żeby się dało tak samemu... Środkowy to praca. Pokazałem mu fakju i powiedziałem, że tyle jest ważna sama w sobie. Palec wskazujący to cel, który chcielibyśmy osiągnąć i mamy nadzieję, że się uda. Jak się uda, kciuk to PR i nagroda z dobrze wykonanej roboty. Może być jak w Rzymie na arenie, kciuk w górę lub w dół..

Pięść, to jest projekt.

No ale ja nie o tym. W tzw. między czasie potestowałem sobie konstrukcję systemu zdarzeniowego opartego właśnie o wzorzec delegacyjny i z wykorzystaniem wyrażeń Lambda z C++0x.
Zadziałało i wyglada przyznam, całkiem csharpowo. Oto kawałek kodu, który dodaje mi procedurę obsługującą klawiaturę już w właściwej aplikacji:

Wygląda sympatycznie i swojsko jeśli ktoś wraca do C++ z wieloletnimi przyzwyczajeniami z C# czy Java.
Dla kompletu istotny fragment definicji klasy okna:

Już jest widoczne, że każde zdarzenie to tak naprawdę wektor wyrażeń lambda z określonymi parametrami do szablonu zgodnymi z parametrami wejściowymi jakie chcielibyśmy przekazać do funkcji, która to zdarzenie obsługuje.

W moim przypadku założyłem sobie, że zawsze idzie uniwersalny wskaźnik void* (dosyć surowo) a dalej parametry określonych typów, które miały sens przy deklaracji poszczególnych zdarzeń.

Aby w pełni zrozumieć ten przykład brakuje jeszcze implementacji metod wirtualnych on_* 
Oto jedna z nich, dla wykorzystanego powyżej zdarzenia key_down:

 W przypadku implementacji pod Windows nie pozostaje nic innego jak tylko w procedurze WNDPROC odpowiednio przekierować odwołanie z komunikatu WM_KEYDOWN:

Aktualnie testuję w praktyce, taki system - właśnie na okienkach. Otwartą kwestią bowiem jest wydajność.
Jeśli ten przykład nie jest dla was jasny to polecam poniższą lekturę:

https://msdn.microsoft.com/en-us/library/169de7b0.aspx - Opis elementów standardowej biblioteki opisanych w nagłówku <functional> 
https://channel9.msdn.com/shows/c9-goingnative - Seria webcastów (nowa) na Channel9, skupiona wokół C++ na platformie Windows

https://stackoverflow.com/questions/89488/comparing-stdtr1function-objects - dyskusja i alternatywne pomysły na delegacyjny system zdarzeń w C++

Mnie pozostają dwie prezentacje, o których na razie nie będę jeszcze pisał. Dodam tylko, że tematy to dla mnie swoisty back_to_roots w kwestiach technologicznych.
Ale tak bardzo back..back. Jak ktoś (zapewne bardziej z grupy bliższych znajomych) pamięta mnie sprzed 10-15 lat bardziej z schematu nick^group niż imię i nazwisko, może się już domyślać tematu jednej z nich.

W każdym razie, zapowiada się zabawnie, chociaż z drugiej strony trochę dziwnie. To dla mnie zwiastun pewnych zmian, gdzie cieżar .NETu zmienia się bardziej w strone takich technologii co mają tagi i język programowania, który doprowadza do bólu głowy każdego architekta przyzwyczajnego do twardego typowania. Dla równowagi będę się też bawił takimi technologiami, które wymagają przypomnienia sobie co to znaczy pointer.

To już jednak dygresja. Kończąc, dla tych co jeszcze nie odkryli ważnych stron, kilka odnośników na temat konferencji:

https://www.mtskonferencja.pl/ - strona konferencji

https://www.mtskonferencja.pl/dlaczego-warto#obszary - obszary tematyczne (w tym roku opieki merytorycznej nad konferencją podjeli się Mariusz Kędziora oraz Artur Żarski)

https://www.facebook.com/MicrosoftTechnologySummit - Strona MTS na Facebooku. Polecam jeśli chcecie się wyrazić i zostać szybko wysłuchanymi.

Aby wyjaśnić o co chodzi, przekleję informację z tejże strony:

Kiedyś prowadziłem bloga, który ewoluował. Skupiał się na nowościach i ciekawych informacjach dotyczących programowania. Z racji zainteresowań i później pracodawcy dotyczył głównie świata Microsoftu. Ostatnia wersja (v2.0) jest cały czas hostowana na MSDN (Microsoft Developer Network).

Ostatnio się zastanawiałem nad ewolucją Internetu z perspektywy Ciebie i mnie, zwykłych ludzi, którzy chcą kontrybuować:
* Web 1.0 - Bazuje na odklejonych od siebie stronach i kiepskich wyszukiwarkach.
* Web 2.0 - Bazuje na wyszukiwarkach, mocna integracja stron, mash-ups, blogi, kontrybucja dojrzalsza i bardziej widoczna.
* Web 3.0 - Bazuje na sieciach społecznościowych, to one są mianownikiem do wyszukiwania, wspóldzielenia i lektury tego co już znajdziemy.

Ta refleksja spowodowała, że postanowiłem przetestować Facebook jako medium.

-
Daniel Biesiada | Developer Evangelist

Czy to oznacza, że to miejsce uznaję za zamknięte? Nie wiem.. przyznam szczerze - eksperymentuję.
W praktyce odkryłem jakiś czas temu, że więcej czasu poświęcam na dzieleniu się swoimi (i znalezionymi w internecie) opiniami via Facebook i Tweeter niż jakiejkolwiek aktywności bloggerskiej. Niewiele więc w praktyce ten eksperyment zmienia.

Nie jestem jedyny, który do takiego wniosku doszedł. Mój dobry znajomy zza oceanu, bloger i przy okazji dyrektor w moim dziale pare dobrych szczebli wyżej w Redmond - Frank Arrigo - również całkiem niedawno pochwalił się podobną refleksją. Zresztą... to chyba nie jest tylko Microsoftu domena, aby ewaluować możliwości drzemiące w sieciach społecznościowych. Jak patrzę co wielu moich znajomych wyczynia na FB pomyślałem, że to dobry moment aby uporządkować swój śmietnik na "ścianie" i rozdzielić to co mam na liście znajomych, a to co chciałbym przekazać zawodowo (a czasem pseudo-zawodowo).

Na tamtej stronie poza notatkami (jak wpisy na blogu), znaleźć będziecie mogli różne dokumenty i prezentacje jakie poczyniłem i poczynię. Również informacje o ciekawych (moim zdaniem) wydarzeniach, które odbędą się w niedługim czasie oraz pewnie pojawi się po drodzę parę innych pomysłów co można z tym FB zrobić.

Wpisy po polsku, więc dla was. Odseparowany blog anglojęzyczny na dbiesiada.com zostaje. Tam też co prawda zbyt często nie zaglądam, ale jest motywacja, aby pisac na tematy kompletnie odklejone zupełnie od spraw MS (ot takie miejsce dla przyjaciół królika).

Jedyny minus tej strony FB jaki na ten moment znalazłem to brak możliwości wystawienia RSS'a z tej ściany, notek czy czegokolwiek. Wiele osób może zaboleć, mam nadzieję, że jakoś się z tym uporamy. Jeśli chcecie mi pomóc w tym eksperymencie to zapraszam do subskrypcji (lubienia) tam..

Zakończe dowcipem:
Przychodzi baba do lekarza z książką na twarzy. Lekarz pyta, co pani jest. Baba odpowiada: Facebook. :>

Dodatkowo drugiego grudnia jest w USA konferencja "Firestarter", na której ScottG ma keynote o dżwięcznym temacie "Future of Silverlight".
Nic więcej nie powiem, ale warto się zarejestrować i na żywo obejrzeć streaming z tego wydarzenia. Powinien rozwiać wszelkie wątpliwości na temat przyszłości tej technologii.

Linki:
https://www.silverlight.net/news/events/firestarter/ - Konferencja „Firestarter”.
https://weblogs.asp.net/scottgu/ - blog Scotta Gurthie
https://weblogs.asp.net/scottgu/archive/2010/11/04/silverlight-questions.aspx - wpis o SL (w kontekście PDC).

Książka jest już dostępna w sklepie online naszego wydawcy, firmy APN Promise. Adres jest poniżej:

https://www.ksiazki.promise.pl/aspx/produkt.aspx?pid=55483&n=windows_azure_platforma_cloud_computing_dla_programistow

W księgarniach ksiażka będzie wyglądać następująco: