Moja nierelacja z WROC#

Nie bywam na konferencjach tak często jakbym chciał. Dlaczego? Myślę, że moim problemem jest nonkonformizm, przesadny indywidualizm. Będąc na konferencji trzeba się socjalizować. Uprawiać networking (nie cierpię tego słowa). Jak już się tam jest to warto by było skorzystać z okazji i zagadać do prelegentów. Porozmawiać z niewidzianymi od dawna kolegami ze studiów. Powiedzieć parę razy "zgadamy się" i kilka "będziemy w kontakcie". Czy to problem? Nie. Czy jestem osobą zamkniętą? Nie. Wręcz przeciwnie.

Nauka uczenia (się)

Człowiek uczy się całe życie. Słyszymy, powtarzamy ten truizm. Czasem jest to pochwała, najczęściej pocieszenie.

Wiedza, mądrość, inteligencja, czy to synonimy?

Na studiach uczymy się czy studiujemy? Po studiach jesteśmy mądrzejsi czy mamy większą wiedzę?

Czasami słyszę pytania skąd wiem to co wiem i w jaki sposób dowiaduję się co mam wiedzieć. Sam też często zadaję na rozmowach kwalifikacyjnych pytania: 

"Skąd Pani/Pan czerpie wiedzę?"

"Co Pani/Pan robi gdy natrafi na problem, z którym do tej pory się nie spotkała/ł"

"Czy ma Pani/Pan jakieś może nie autorytety programistyczne ale po prostu ludzi na których odpowiedzi Pani/Pan często trafia?"

Podsumowaniem odpowiedzi niech będzie miks:

"No wie Pan, zwykle to jak wszyscy: StackOverflow, Google. A osoby? Eee... Raczej nie kojarzę teraz, najczęściej to po prostu szukam odpowiedzi i tyle"

A Ty mój drogi czytelniku, czego szukasz na tym blogu? Rozwiązania problemu? Inspiracji? Tak sobie klikasz? Skrolujesz?

Sierpień 2007 roku był miesiącem, który nie zapisał się wielce na kartach historii, zaczął się jak każdy od 12 lat Przystankiem Woodstock. Przez Mikołajki przeszedł największy szkwał w historii. 46te urodziny obchodził pewien senator z Illinois. Wyszła pierwsza wersja jQuery. Gdzieś pomiędzy tymi wydarzeniami rozpoczął swoją zawodową karierę niżej podpisany blogger.

Cierpienia niemłodego bloggera - czyli próbuję napisać tekst o wczytywaniu komponentów w Knockout.JS na podstawie konwencji nazewniczej. Wymyślając przy okazji najdłuższy wpis w historii tego bloga. Doh! -_-

Życie bloggera to nie jest bułka z szynką. To nie prosta sprawa. Co prawda pomysły same wpadają do głowy. Idzie człowiek ulicą, drepcze tak sobie drepcze i nagle bęc, nagle bum! Albo koduje sobie taki, wymyśla rozwiązanie i myśli sobie: O! To świetny temat na blog! Warto się nim podzielić! Tylko potem to jakoś tak ciężko przelać na papier. Siada sobie Pan Redaktor. Zabiera się za spisanie swych wiekopomnych odkryć. Herbata stygnie, zapada zmrok a pod klawiaturą ciągle nic, obowiązek obowiązkiem jest, wpis musi posiadać tekst.

No i siadam. Klasyczne pytania. Jak zacząć? Jak Ciebie nie zanudzić, mój drogi czytelniku? Ej człowieku, pisz tam lepiej. Nie mazgaj się i tak piszesz dla siebie. Ale, ale... jak? To przecież nie ma być kolejny suchy, irytujący wpis jakich pełno w blogosferze. Chyba mnie grypa bierze...

Tyle rzeczy do przekazania... Tyle rzeczy do powiedzenia...

Może wspomnieć, że jest mi smutno, że Knockout.JS przegrał już jakiś czas temu walkę z Angularem? Albo, że wg mnie nie powinno się przenosić wprost backendowych wzorców do zupełnie innego środowiska JavaScriptu? 

Wspomnieć o tym, że nie mam zaufania do React? Że kojarzy mi się z programowaniem WinFormsowym? Hmmm...

A może po prostu wejść na pełnej k... i powiedzieć od razu, że mam świetną klasę, którą nazwałem ComponentByNamingConventionLoader? I że bierzcie i jedzcie z tego wszyscy? Dodać, że jeśli używacie Knockout.JS to na pewno Wam się przyda? Eeee... to jakoś nie wygląda... (Siorb) Ej! Herbata już całkiem zimna...

A może wrócić do podstaw? Może rozprawkę? Wprowadzenie, teza, argument pierwszy, drugi, trzeci, czwarty, potwierdzenie tezy, podsumowanie. Ma to sens. Ma to sens. Wszystko byle już wreszcie zacząć. Ołówek, notatnik i jadziem kapela.

What really grind my gears #1 - IIIIIIIIIIIIIIIIF!

Jestem spokojnym człowiekiem, niespotykanie spokojnym. Ale... Jestem Oskar, z Polski. Miejsca urodzenia nie przeskoczę. Natura, historia, zwyczaje, pierogi, kierpce, Szopen wieczorową porą. 

I irytacja. 

Rosnąca irytacja. 

Pulsująca irytacja. 

Przechodząca w krótkie, staropolskie słowo rozpoczynające się i kończące się na W.

No co ja na to poradzę? Po prostu wiele rzeczy mnie denerwuje. Co np.? To, że gdy chcę jeździć na rowerze to jest za gorąco albo pada deszcz. To, że po piciu  wódki na drugi dzień boli głowa. To, że studentów tyle w pociągach i to, że po każdej niedzieli przychodzi poniedziałek. Co ja będę Wam mówił, nie jest łatwo być Polakiem. Wicie rozumicie, wina Tuska.

Ciężko być Polakiem, ale być Polakiem i programistą to już tylko ciężej być kibicem i sprzedawcą butów (oh wait...). Te porażki w piłkarzyki w pracy, te przymusowe przerwy od przeglądania memów, gdy nam każą popracować. Ta dojmująca, nieznośna lekkość bytu. 

I IFy. 

IIIIIIFY. 

KŁIIII KŁIII KŁIIIIIIIIIIIFY. 

Englishman in New York, czyli jak .NETowiec może uwić sobie gniazdko w świecie MSSQL

Wieczór, herbata, ciepłe papcie, nie za twardy, nie za miękki narożnik, na którym wyciągasz swoje zmęczone nogi. Gdzieś w tle leniwie snuje się muzyczka plum plum plum... Cieplutko, mięciutko, strefa komfortu. Mmmmm... Klawo!

Gdy tak sobie leżysz w apogeum czilałtu muzyka przestaje nagle grać, idąc sprawdzić o co chodzi zahaczasz nogą i wyrywasz kabel sieciowy, potem przepala Ci się bezpiecznik od światła, a z kranu zaczyna ciec woda. Tyle było twojego komfortu...

Jedziesz na tydzień na narty do Czech. Niby wszyscy mili, niby podobny język, ale jednak jakoś tak dziwnie. Uśmiechy wydają się coraz bardziej ukradkowe. Po złożeniu zamówienia w restauracji do ostatniej chwili drżysz czy faktycznie zamówiłeś to co chciałeś.

Albo dajmy na to delegacja do Wałbrzycha lub Sosnowca...

Praca programisty daleka  jest od błogostanu. Nowy dzień, nowe problemy. Pudełko czekoladek prosto od Foresta. Szczególną sytuacją jest zmiana projektu. Konsternacja sięga zenitu. Nowe osoby, nowe środowisko i te parszywe nowe technologie.

"...you can hear it in my accent when I talk, I'm an Englishman in New York"

  

Jakiś czas temu doświadczyłem takiej zmiany. Drastyyycznej zmiany. Z intensywnej pracy przy mocno JavaScriptowym systemie przeszedłem na drugą stronę. Ciemniejszą stronę. Tam gdzie nie ma frontendu - systemu Business Inteligence w MSSQL.

"First I was afraid, I was petrified"
 

Nie tylko Ty się tak czułaś moja droga Glorio.

Suma wszystkich strachów

Czego się obawiałem?

1. Management Studio jest przyzwoitym środowiskiem do zarządzania bazą danych. Z funkcjonalnościami i rozbudowaniem Visual Studio nie ma jednak żadnego porównania. Ot taki mniej rozgarnięty koleżka. Ten co nosi za duże, używane rzeczy po starszym bracie.

2. Skryptów inkrementalnych. Każdy z nas wie jak bolesne jest utrzymywanie tego barachła. Oczywiście można sobie radzić, stosować konwencje nazewnicze, używać migracji w Entity Framework, ale czy to czyni sprawę przyjemną? Don't think so... Znośniejszą. W najlepszym razie. Dodajmy jeszcze do tego konieczność utrzymywania aktualnej struktury bazy, by można było zawsze odtworzyć ją od zera, kontrolę wersji i pracę na wielu branchach. Mniam. Mniam. Paluszki lizać.

3. Wdrażania na różne środowiska. Developerskie, Testowe, Preprod, Produkcjne, NaKolejneZyczenieKlienta. I każde z tych środowisk się trochę różni, na każdym trzeba trochę inne skrypty odpalić. Kup sobie chłopcze zapas melisy jeśli chcesz być wdrożeniowcem, wujo Ci to mówi. Jeden Cherry pick, drugi cherry pick, zapomnisz przerzucić jeden skrypt inkrementalny i KA BOOM! Nie ma Cię - ehę. Albo produkcji. Twoja premia też gdzieś się zapodziała.

4. Struktura i modularność projektu. Jak ładnie utrzymywać strukturę projektu w świecie MSSQL. Podział kodu, modularność, biblioteki, współdzielenie kodu przez różne projekty? Czy to w ogóle możliwe? Projekty w Management Studio, w porównaniu do tych znanych z VS to właśnie te spodnie starszego brata, które podcięto, żeby robiły za bojówki. Do tego kod się nie kompiluje, jak być pewnym, że po zmianie nazwy kolumny nie zapomnieliśmy poprawić kodu, w którejś procedurze? Jak być pewnym, że nasz projekt jest dalej stabilny?

5. No i na koniec duszki Kacperki w porównaniu z poprzednimi punktami. Czyli takie fanaberie jak intellisence, refactoring, sprawdzanie gdzie używana jest procedura, tabela, przystępniejsze debugowanie kodu. Małe rzeczy, które czynią nas szczęśliwszymi. 

SSDT To the Rescue!

SQLowa ciekawostka #1 - Uważaj na Exists kolego

Tym razem, po serii nostalgiczno-branżowo-przemyśleniowych wpisów, będzie krótko i technicznie. Chciałbym się przed wami popisać  swoją niewiedzą. Nie ma się w zasadzie czym chwalić, ale uważam, że głupotą nie jest brak wiedzy, co raczej wstyd przed jego okazaniem... No ale nie o to, nie o to, Oskarze, do sedna, do sedna...

Wczoraj podczas godzin spędzonych na szukaniu błędu natrafiłem w pewnej procedurze na takowy kod:

if exists (
 select Kolumna
 from Tabela t
 where t.Id = @Id
)
begin
 (...)zrób coś
end

Kod jak kod pomyślałem. Ale zastanowił mnie komentarz: "Zrób coś"  tylko gdy Kolumna ma ustawioną wartość. Rzuciło mi się to w oczy bo z zasady jestem wyczulony na kod, który wymaga komentarzy. Okazało się, że mimo tego, że dla mojego rekordu Kolumna nie miała wartości to IF zawsze zwracał TRUE i "robił coś". Dlaczego?

 

Ano dlatego, że dla EXISTS zwrócone przez subquery wartości nie mają żadnego znaczenia . Ważna dla niego jest tylko liczba zwróconych rekordów. Niezależnie od tego czy zwrócimy wszystkie czy jedną kolumnę, czy zwrócimy NULL, czy wartość dla Exists będzie to zawsze TRUE. Bo zwróciliśmy wiersz.

 

Pusty wiersz to nie to samo co brak wierszy.

 

Brak decyzji też często bywa decyzją...

Dla zwizualizowania odpalcie sobie dwa zapytania:

SELECT 1 WHERE EXISTS(SELECT NULL)

i: 

SELECT 1 WHERE EXISTS(SELECT NULL WHERE 1=2)

Mała rzecz a cieszy. Niby podstawy podstaw, a człowiek może dać się złapać. A przecież na MSDN jest jak wół napisane.
Codziennie człowiek uczy się czegoś nowego. I to chyba jest fajne w naszym zawodzie, czyż nie?

Borys najlepiej dryblował

Borys najlepiej dryblował, Cybor kręcił najlepsze rogale, było kilku kajtków, robiących 200 kapek. Moja piąta B, zawsze bo ciężkim meczu dokopywała piątej A. Od jakiegoś czasu graliśmy już tylko "na nowe". Ja nie robiłem setek zwodów, robienie kapek kończyłem na 20-30. Nie bawiło mnie to. Nie potrzebne mi były nadmiarowe ozdobniki, uważałem że koniec końców najważniejsze są podstawy. Kopnięcie piłki tam gdzie się chce. Co za różnica czy walnie się w okienko, brazylianę czy piłka ledwo się wtoczy? Ważne, żeby znalazła się w bramce. Koniec końców to się liczy. Sztuka dla sztuki? Nie dla mnie. 

W Fifę nigdy nie wybierałem Brazylii, nawet w 98ym nie grałem Francją. To byłoby za proste. W końcu lepiej iść pod prąd. Co to za trudność grać na nastrojonej gitarze? Lepiej przegrywać z lepszymi niż wygrywać ze słabszymi. Lepiej być szeregowym graczem w Manchasterze Utd. niż kapitanem w Miedzi Legnica. 

Zawsze czytam instrukcje. W końcu trzeba się przygotować. Trzeba skręcić jak należy. 

Nie kupuję rzeczy pierwszych z brzegu, sprawdzam Ceneo, czytam fora, na Allegro ustawiam snajpera.

Wczoraj po dwóch latach naprawiłem zepsutą żaluzję.

- Jaka jest Pana największa wada?
- Jestem perfekcjonistą.

Czasem mówię o sobie mistrz niedokończonych pomysłów. Jak większość z nas marzę o swoim własnym pomyśle, swoim własnym produkcie, startupie. Regularnie przystępuję do kolejnych błyskotliwych (w zamierzeniu) pomysłów i regularnie je nie dokańczam. Każda próba kończy się tak samo, "to samo miejsce inna dziewczyna". 

Oczywiście każdy mój projekt musi mieć solidne fundamenty. Najpierw architektura, framework. Wszystko musi być na tip top, najnowsze rozwiązania, dobre praktyki, wzorce projektowe. W końcu mam teraz wolną rękę, nie muszę się przejmować marudzącym klientem. Ogólnie to chyba u nas w branży często bywa jak w PKP, wszystko by zajebiście szło gdyby nie klienci. Często naśmiewamy się z tego, że co on tam wie, że głupek, że nie będzie uczył ojca dzieci robić. Co tam kolorki, przycisk przesunięty o 3 pixele w lewo, albo nie ten odcień? Ważne żeby było SOLID. Najważniejsze to mieć dobrą architekturę i świetnie funkcjonujące trzewia. Nasze projekty są jak góra lodowa, olbrzymie pod spodem, tylko widocznych efektów jakoś tak niedużo. 

W zeszłym tygodniu trafiła mi w ręce książka, w zasadzie ebook "Just Fucking Ship" napisana przez Amy Hoy. Świetnie trafiła w mój nastrój zadumy nad tym co robię źle. Dlaczego Borys jest tym pamiętanym przez wszystkich piłkarzem z podwórka, nie ja? Dlaczego mój tato mówi, że mam słomiany zapał? Dlaczego Xamarin i SignalR świecą sukcesy, a mój niedokończony framework z podobnymi założeniami leży gdzieś na końcu mojego dysku nie rozwijany od kilku lat? Przecież wydawałoby się, że robię wszystko jak należy. Rozsądek. Solidne podstawy. Wiedza. Doświadczenie. Mr Prim and Proper. 

Może to właśnie dlatego, że popełniam te same błędy co wszyscy (no prawie wszyscy), czyli:
- nie skupiam się na złapaniu króliczka tylko go gonieniu. Projekt zaczynam od frameworka, stronę od layoutu, a w ogóle to od wymyślenia nazwy domeny. Przez co tracę okres największego entuzjazmu na pierdoły, które z punktu widzenia produktu są najmniej ważne.
- nie notuję, nie spisuję planów - "no bo po co? Nie potrzebuję tego - ćwiczę pamięć"
- nie skupiam się na celu, nie wyznaczam sobie deadline'ów.
- nie postępuję w myśl zasady "start small, grow big". 

"How programmers spend time on a project. This one's funny because it's true" via @ErlangSolutions pic.twitter.com/qYJpPsQLFS
— About Programming (@abt_programming) January 31, 2015

Książka Amy nie jest wielce odkrywcza, nie da złotej recepty - nawet do tego nie aspiruje. To co na pewno da to powiew świeżości w głowie, otwarcie kilku zamkniętych zapadek i garść cennych, konkretnych, życiowych porad. Najważniejsza z nich to: wyznacz sobie cel, termin i po prostu to kurwa zrób. Najpierw cel i czas potem zakres i metody realizacji. Oczywiście, każdy z nas powie "e no, tak to się nie zawsze da zrobić". Tylko spójrzcie inaczej: czy chcąc zaprosić znajomych na obiad planujemy, że "może to za 2 tygodnie jednak, bo nie zdążę zrobić trzydaniowego obiadu, tortu i domowej nalewki". Przecież tak nie robimy. Dopasowujemy listę dań lub kupujemy coś gotowego. Czy nie da się tej polityki przenieść na grunt naszych też projektów? 

Amy zauważa, że za bardzo skupiamy się na projekcie jako całości. Nie wyznaczamy sobie małych celów, których zrealizowanie pozwoliłoby nam być osiągnąć satysfakcję i motywację do kolejnych działań. Tak bardzo skupiamy się na ogólnej wizji, że w końcu zarzucamy nasz pomysł nie robiąc niczego. Boimy się, że nie jest on wystarczająco fajny, wystarczająco innowacyjny. Czemu nie damy innym szansy tego ocenić? Zostajemy w progach startowych zamiast po prostu biec i zobaczyć gdzie dobiegniemy. Zapominamy, że aby wejść na piętro należy pokonać schody krok po kroku. Stojąc na parterze, zastanawiając czy damy radę wejść niczego nie osiągniemy. Możemy nawet wjechać windą, bylebyśmy to kurwa zrobili. 

Po tej lekturze nie wywrócę swojego życia do góry nogami, nie stanę się nagle innym człowiekiem. Po prostu tym razem spróbuję swoje plany wreszcie kurwa dowieźć. 

Tydzień temu, w wieku prawie 30 lat odebrałem swój pierwszy piłkarski medal. Jest jeszcze nadzieja.

Na temat branży

Naszym programistycznym światkiem wstrząsnął ten oto wpis: http://natemat.pl/105597,it-arystokracja. Artykuł jak artykuł, nieco grafomański, nieco tendencyjny, ale w gruncie rzeczy nic wielkiego. Klasyczny przedstawiciel domorosłego blogowego "dziennikarstwa". Gdy sam na niego trafiłem to zapomniałem o nim gdzieś pomiędzy jednym, a drugim mrugnięciem okiem. Wydawało mi się, że to nic nowego, rzeczy ogólnie znane, ale wszedłem na "fejsa", a tam gorączka. Wpisy u znajomych, nawet na Grupie .NET szaleństwo. Truizm "uderz w stół, a nożyczki się odezwą" stał się ciałem. O tempora, o mores!
Kto by przypuszczał, że taki wpis wzbudzi tyle emocji... Aż sam się zagotowałem (tak, Johann to sem ja). Ale to co wzbudziło we mnie tyle emocji to niechęć do zwykłego powiedzenia "no okej, mam lepiej niż inni i co Ci do tego?". Czytając wpisy, rozmawiając ze znajomymi dowiedziałem się, że na zachodzie to Panie eurasy kokosy, a u nas co, ziemniaki mają być? Jak nie będę pracował za dziesięć tysi to co? Mam za miskę ryżu pracować? A w ogóle to po co ta dyskusja, prawa rynku, podaż, popyt. Panowie w prążki mający pieniążki na mnie zarabiają to ja mam nic nie przytulić? Frajer przeca nie jestem! Zgłupiałeś tak jak Ci co wybrali inne studia niż programistyczne? Życie to w ogóle brutalna dżungla, nie chcesz to jedź jak prezes Optimusa w Bieszczady i hoduj owce. No i ogólnie ten tego...

No dobra troszeczkę wyolbrzymiam, ale tak jak pisałem na fejsowej gównoburzy - nie rozumiem obruszenia, że ktoś nazwał naszą grupę uprzywilejowaną, bo przecież tacy jesteśmy. Popyt nas takimi uczynił, nie my sami.
Trochę dziecinne jest wg mnie udawać, że jest inaczej i się obrażać na takie stwierdzenia. Dodatkowo nie rozumiem takiego podejścia, że mnie się udało, inni mogli robić to co ja to też by tak mieli. Chodzi mi tylko o odrobinę więcej pokory i szacunku dla innych. 
Tego sobie i innym życzę ;)

Refleksyjnie plus pierwszy w historii Vlog - Podstawy programowania w Office 2013

Heh. 
To już ponad 1,5 roku od poprzedniego wpisu. 
Gdzieś w między czasie uleciał trochu wolny czas, trochu zapał. Tak to już jest. Jutro się tym zajmę, może w następnym tygodniu, w weekend na pewno będę miał czas, a jak nie to już od następnego miesiąca będę królem samozaparcia i samorealizacji. Każdy to zna, każdy to przeżywa. Potem się okazuje, że to święte oburzenie zostało zamienione na czas spędzony na poobiednich drzemkach, oglądaniu 9 sezonów Dwóch i pół, czy graniu w 2048. Potem to już tylko, że jestem zarobiony, w pracy ciężko i w ogóle tyle roboty, że taczki nie ma jak załadować, a o szyby deszcz dzwoni, deszcz dzwoni jesienny.
Jakiś czas temu "popełniłem wykon" (tak bardzo nie cierpię nowomowy, że aż musiałem jej użyć) na potrzeby wewnętrznych szkoleń w firmie, w której pracuję. Programowanie w Office 2013. Temat wydaje mi się, że ciekawy i mało zagospodarowany. Przez co duże w nim pole do popisu. Z racji, że to mój debiut w tej materii to proszę o litościwość.

Mam nadzieję, że dorównałem mistrzowi:

Dla chętnych - źródła:  pobierz

Prezent od Microsoft - Darmowa książka o programowaniu w Windows 8

Microsoft konsekwentnie kontynuuje taktykę ściągania nie .NETowych programistów - udostępnił darmową książkę w ramach Microsoft Press: "Programming Windows 8 Apps with HTML, CSS, and JavaScript". Jest ona dostępna pod adresem:
- http://blogs.msdn.com/b/microsoft_press/archive/2012/10/29/free-ebook-programming-windows-8-apps-with-html-css-and-javascript.aspx
Nie do końca jestem przekonany do tego, że HTML5, JavaScript i CSS jest tym kierunkiem, w którym powinny podążać systemy operacyjne. Wg mnie te technologie są chaotyczne, mają pełno złych zaszłości historycznych i są ciężkie w utrzymaniu. (Nie)stety nie tylko Microsoft podąża w tą stronę - Apple, Google również mocno w nią idą. 
A wy co o tym wszystkim sądzicie?

Serializacja dla .NET 4.5 oraz Windows Runtime przy pomocy Sharpserializer

Trochę mnie nie było, dawno już nie pisałem - ten post będzie dla mnie nietypowy - krótki. Mam nadzieję, że to będzie jego zaleta.
W swoim projekcie-po-godzinach do serializacji danych używam biblioteki SharpSerializer. Projekt ma środowiska klienckie napisane w Silverlight i Windows Phone. Nie ma w nich klasy BinaryFormatter przez co bez stosowania zewnętrznych bibliotek trzeba by stosować sztuczki z serializacją poprzez mechanizm DataContract z WCF (więcej szczegółów na blogu Damona Payne'a). Nie jest to zbyt wygodne wg mnie.
SharpSerializer pozwala w prosty, wygodny i efektywny sposób serializować dane do postaci binarnej. 
Dlaczego tak nagle o tym piszę? W tym tygodniu zacząłem przenosić kod projektu na .NET 4.5 i Windows Runtime. Niestety nie zostały do tej pory wypuszczone wersje na te środowiska.
Na szczęście ze strony można ściągnąć kody źródłowe.
Pobrałem je, przekonwertowałem, poprawiłem część rzeczy, przekompilowałem i okazało się, że wszystko wygląda jakby działało.
Efekt moich prac możecie pobrać: tutaj (src + dll).
Więcej informacji na temat SharpSerializer pod linkami:
- http://www.sharpserializer.com/en/tutorial/index.html
- http://www.codeproject.com/Articles/76530/XML-Serialization-of-Generic-Dictionary-Multidimen
- http://www.codeproject.com/Articles/240621/How-to-serialize-data-effectively-Custom-serializa
- http://www.codeproject.com/Articles/116020/Binary-Serialization-to-Isolated-Storage-in-Silver
Zachęcam do zabawy z SharpSerializerem, naprawdę dobra biblioteka.

Jak z kilku dllek zrobić jedną, czyli modularność przy pomocy ILMerge

Wstęp

Pracuję aktualnie nad strukturą pewnego projektu. Ideą, która przyświeca przy jej tworzeniu jest to, żeby była jak najbardziej modularna - tak by składała się z niezależnych, niepowiązanych ze sobą podaplikacji. 

Aby lepiej przybliżyć problem przyjrzyjmy się przykładowi:

Rysunek 1 - Przykładowa struktura

Przyjmijmy, że chcemy stworzyć moduł zarządzania użytkownikami, który będziemy używać w kilku tworzonych przez nas aplikacjach. Nie chcemy, bowiem za każdym razem wynajdywać koła od początku.  Moduł ten składać się będzie z podmodułów odpowiadających za rejestrację, logowanie, uprawnienia. 

Standardowo do każdego z tych "klocków" utworzylibyśmy osobny projekt, chcąc dodać do naszych aplikacji musielibyśmy wrzucić 4 osobne dllki:

- główną - Modułu Zarządzania Użytkownikami

- 3 zależne - Moduł Rejestracji, Moduł Logowania, Moduł Uprawnień

Dorzucenie 4 dllek nie wydaje się chyba wielkim problemem, prawda? 

Pójdźmy jednak dalej. Załóżmy, że nasza firma zajmuje się tworzeniem stron internetowych. Mamy kilka "żyjących" i rozwijanych stron. Każdą z nich zajmuje się osobny zespół programistów, mamy również dział geeków, którzy zajmuje się core'em. Nasi klienci stwierdzili, że chcieliby mieć możliwość logowania się i rejestracji przy pomocy otwartych systemów uwierzytelniania jak OpenID, Google, Facebook. Zespół naszych geeków czym prędzej zaczyna się tym zajmować i na koniec generuje następującą strukturę:

Rysunek 2 - Rozszerzona struktura

Przy uaktualnianiu Modułu Zarządzania Użytkownikami musimy pamiętać, że musimy dodać kolejne dziewięć dllek dla każdego z podmodułów. W sumie mamy trzynaście dllek, może i pechowa liczba, ale to dalej nie jest krytyczny problem, czyż nie? Krytycznie jednak zaczyna się robić, gdy mamy kilka używanych w wielu miejscach modułów, z których każdy składa się z podmodułów. Gdy jeszcze trzymamy się zasadom luźno powiązanych klas, inversion of control i korzystamy z kontenerów dependency injection to sytuacja robi się jeszcze bardziej problematyczna, a zapomnienie dorzucenia dllki łatwiejsze i bardziej problematyczne.

Dużym uproszczeniem byłaby sytuacja gdy każdy moduł jest osobną dllką. Dzięki temu programiści, którzy z niego korzystają nie muszą się zastanawiać z czego on dokładnie się składa, musiał by tylko wiedzieć jak się go używa. 

Co to jest ILMerge?

ILMerge jest narzędziem dostarczonym przez Microsoft, pozwalającym na łączenie kilku asemblatów w jeden (stąd jego nazwa - łączenie ILa). Radzi on sobie bez większych problemów również z łączeniem plików .pdb umożliwiając tym samym debugowanie. Dostarczany jest w postaci pliku EXE (można go pobrać pod linkiem), który uruchomiony z odpowiednimi parametrami pozwala nam na złączenie asemblatów. Przykładowe jego wywołanie to:

ilmerge /target:winexe /out:myprogram.exe yourexe.exe yourlibrary.dll

Gdzie:
- ilmerge - nazwa pliku ilmerge'a 
- /target - parametr mówiący czy nasz asemblat ma być plikiem exe (winexe) cz dllką (module) 
- /out: - parametr mówiący o nazwie wynikowego pliku, podajemy też asemblaty, które chcemy złączyć


Jak to zobaczyłem to stwierdziłem, że bardzo to fajne, tylko że wywoływanie za każdym razem polecenia z linii komend. Na szczęście znalazłem świetny artykuł Scotta Hanselmana jak można ten proces zautomatyzować.


Automatyczne wywołanie ILMerge


MSBuild pozwala na zdefiniowanie akcji, które będą wykonywane po procesie zbudowania projektu (tzw. Post build actions). Możemy zatem zdefiniować akcję, która będzie polegała na wywołaniu ILMerge'a z odpowiednimi parametrami dla wybranych przez nas projektów. Jak tego dokonać? Ponieważ pliki projektów są zarazem plikami MSBuilda możemy je odpowiednio zmodyfikować.
Zacznijmy od utworzenia nowej solucji i struktury projektów. Niech wygląda ona następująco:

Rysunek 3 - przykładowa struktura projektów

Odpowiada ona przykładowej strukturze projektów przedstawionej wcześniej. Mamy projekt ILMergeSample.UserManagementModule, który ma referencję do trzech podmodułów. Zbudujmy teraz nasz solucję i przejdźmy do katalogu Debug dla naszego projektu modułu obsługi pracowników.

Rysunek 4 - Wynik standardowego builda

Zgodnie z przewidywaniami standardowo skopiował dllki podmodułów. Przejdźmy więc do sedna artyukułu i zacznijmy łączyć je w jedną. Rozpocznijmy od skopiowania pliku ILMerge.exe do struktury naszej solucji (domyślnie znajduje się w "C:\Program Files (x86)\Microsoft\ILMerge"). Pozwoli nam to uniezależnić od tego czy inny developer ma go na swoim komputerze i pod jaką ścieżką się u niego znajduje.
Dodajmy również plik o nazwie "Ilmerge.CSharp.targets".
Nasza struktura solucji powinna wyglądać teraz następująco:

Rysunek 5 - Struktura projektu po dodaniu ILMerge'a

Otwórzmy teraz plik "Ilmerge.CSharp.targets" i wklejmy do niego następujące dane:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">  
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />   
 <Target Name="AfterBuild">     
 <CreateItem Include="@(ReferencePath)" Condition="'%(CopyLocal)'=='true' and '%(ReferencePath.IlMerge)'=='true'">
   
 
 
 <Message Text="MERGING: @(IlmergeAssemblies->'%(Filename)')" Importance="High" /> 
 
 <Exec Command="&quot;$(SolutionDir)\Ilmerge.exe&quot;
    /targetplatform:v4,&quot;%ProgramFiles%\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0&quot; 
    /out:@(MainAssembly) &quot;@(IntermediateAssembly)&quot; @(IlmergeAssemblies->'&quot;%(FullPath)&quot;', ' ')" /> 
 </Target> 
 
 <Target Name="_CopyFilesMarkedCopyLocal"/>     
</Project>

Co to tak naprawdę robi? Prześledźmy to po kolei:
- Project DefaultTargets="Build" - określamy tutaj, że definiujemy akcję dla builda
- Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" - importujemy tutaj domyślne ustawienia builda, nie chcemy bowiem wszystko definiować od początku, tylko nadpisać część ustawień
- CreateItem Include="@(ReferencePath)" Condition="'%(CopyLocal)'=='true' and '%(ReferencePath.IlMerge)'=='true'" - dzięki temu warunkowi wybieramy do złączenia te asemblaty, które są dołączone do naszego projektu i mają zaznaczoną opcję "Copy Local" oraz "ILMerge" na true
- Message Text - tutaj definiujemy wiadomość, która będzie informowała nas w outputcie o tym, że dokonujemy złączenia asemblatów w trakcie budowania projektu
- Exec Command - tutaj definiujemy odpowiednie wywołanie ILMerge'a. Moja konfiguracja jest specyficzna dla .NET 4.0, jeżeli macie asemblaty w innej wersji .NET powinniście zmodyfikować parametr /targetplatform


Mając konfigurację MSBuilda z ILMerge powinniśmy jeszcze poinformować nasz projekt, że ma z niej korzystać. Dokonujemy tego poprzez ręczną modyfikację pliku projektu (naciskamy na niego prawym przyciskiem i wybieramy opcję "Edit Project File").
Po otworzeniu pliku projektu naszego Modułu Zarządzania Użytkownikami powinniśmy odnaleźć następujące linijki:

Rysunek 6 - Plik projektu przed modyfikacjami

Jedyne co musimy zrobić to zmodyfikować plik następująco:

Rysunek 7 - Plik projektu po modyfikacjach

Dodaliśmy tylko dla wybranych przez nas projektów zmienną <IlMerger> z wartością true informując o tym, że chcemy, żeby projekt został połączony i podmieniliśmy domyślną konfigurację builda przygotowaną wcześniej w pliku "Ilmerge.CSharp.targets".

Zapiszmy teraz plik projektu, przeładujmy go i przebudujmy. Ponownie zerknijmy do katalogu Debug naszego Modułu Zarządzania Użytkownikami i ujrzymy, że została wygenerowana tylko jedna dllka.

Rysynek 8 - Wygenerowane pliki po konfiguracji ILMerge

Czy ILMerge działa dla Silverlighta i Phone'a?


Ależ owsze, czemu nie. Należy tylko odpowiednio spreparować nasz plik targets:
- dla Phone'a nasz plik wyglądał by następująco:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">    
  <Import Project="$(MSBuildExtensionsPath)\Microsoft\Silverlight for Phone\$(TargetFrameworkVersion)\Microsoft.Silverlight.$(TargetFrameworkProfile).Overrides.targets" />
  <Import Project="$(MSBuildExtensionsPath)\Microsoft\Silverlight for Phone\$(TargetFrameworkVersion)\Microsoft.Silverlight.CSharp.targets" />
   
 <Target Name="AfterBuild">     
 <CreateItem Include="@(ReferencePath)" Condition="'%(CopyLocal)'=='true' and '%(ReferencePath.IlMerge)'=='true'">
   
 
 
 <Message Text="MERGING: @(IlmergeAssemblies->'%(Filename)')" Importance="High" /> 
 
 <Exec Command="&quot;$(SolutionDir)\Ilmerge.exe&quot;
    /targetplatform:v4,&quot;%ProgramFiles%\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone&quot; 
    /out:@(MainAssembly) &quot;@(IntermediateAssembly)&quot; @(IlmergeAssemblies->'&quot;%(FullPath)&quot;', ' ')" /> 
 </Target> 
 
 <Target Name="_CopyFilesMarkedCopyLocal"/>     
</Project>

- dla Silverlight'a nasz plik wyglądał by następująco:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">  
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\Silverlight\$(SilverlightVersion)\Microsoft.Silverlight.CSharp.targets" />   
 <Target Name="AfterBuild">     
 <CreateItem Include="@(ReferencePath)" Condition="'%(CopyLocal)'=='true' and '%(ReferencePath.IlMerge)'=='true'">
   
 
 
 <Message Text="MERGING: @(IlmergeAssemblies->'%(Filename)')" Importance="High" /> 
 
 <Exec Command="&quot;$(SolutionDir)\Ilmerge.exe&quot;
    /targetplatform:v4,&quot;%ProgramFiles%\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0&quot; 
    /out:@(MainAssembly) &quot;@(IntermediateAssembly)&quot; @(IlmergeAssemblies->'&quot;%(FullPath)&quot;', ' ')" /> 
 </Target> 
 
 <Target Name="_CopyFilesMarkedCopyLocal"/>     
</Project>

Jak łatwo zauważyć podmieniliśmy tylko ścieżki do plików z domyślnymi ustawieniami buildów dla tych środowisk oraz poprawiliśmy wywołanie ILMerge'a w Exec Command tak aby dotyczyła właściwej platformy.


ILMerge i Resharper


Jeżeli zrobiliście wszystko zgodnie z powyższym opisem to po dodaniu klas i próbie wywołania ich w projekcie Application okaże się, że Resharper nie widzi klas z podmodułów (Authorization, Registration, Login). Dzieje się tak dlatego, że projekty naszych modułów znajdują się w tej samej solucji co projekt Application. Jeżeli utworzylibyśmy osobną solucję, w której nie znajdowałyby się nasze podmoduły, a tylko projekt Application okaże się, że Resharper widzi je już bez większych problemów.
Jest to błąd Resharpera - chociaż oni twierdzą inaczej. Zapewne nie chce im się tego naprawiać, ale oczywiście mają na to mądre wytłumaczenie. Mówią, że jeżeli doprowadziło się do takiej sytuacji to znaczy, że układ projektów jest zły. Można by się było z nimi po części zgodzić, bo moduły powinny być traktowane jako całość i posiadać osobne solucje a nie być wepchnięte w jedną dużą. Jest to jednak spore uniedogodnienie, szczególnie na początku tworzenia systemu, gdy moduły są często zmieniane - trzeba wtedy pracować na kilku solucjach na raz, albo ignorować błędnie podświetlony przez Resharpera kod.


Podsumowanie i linki


Mam nadzieję, że tym artykułem udało mi się przybliżyć to jak ILMerge może pomóc nam przy tworzeniu modularnych aplikacji oraz przede wszystkim ułatwić życie programistom.
Kody źródłowe przykładów z tego artykułu możecie znaleźć tutaj.

Linki do artykułów z których korzystałem przy tworzeniu tego wpisu to:
- http://www.hanselman.com/blog/MixingLanguagesInASingleAssemblyInVisualStudioSeamlesslyWithILMergeAndMSBuild.aspx
- http://blogs.msdn.com/b/jomo_fisher/archive/2006/03/05/544144.aspx
- http://blogs.clariusconsulting.net/kzu/leveraging-ilmerge-to-simplify-deployment-and-your-users-experience/
- http://awkwardcoder.blogspot.com/2011/05/using-ilmerge-for-windows-phone-7.html
- http://albao.wordpress.com/tag/ilmerge-error-documentation-exception-net/
- http://nitoprograms.blogspot.com/2010/09/using-ilmerge-with-net-40-andor-rx.html
- http://devnet.jetbrains.net/message/5253869#5253869

WrocNet - Team Foundation Server to nie SVN - Materiały

Przedwczoraj (środa 21.03) debiutowałem w roli "wykładowcy" na spotkaniu Wrocławskiej grupy .NET. Zaprezentowałem tam rozwinięcie moich wpisów związanych z połączeniem SCRUM z Team Foundation Server. 

Mnie jako prezentującemu na pewno podobało się zaangażowanie słuchaczy, za co serdecznie dziękuję. Nie wiem jak było w drugą stronę, jeżeli ktoś był i chce się podzielić swoimi wrażeniami (nawet najbardziej negatywnymi) to bardzo proszę o komentarze.

Obiecałem, że przedstawię materiały, z których dociekliwi mogliby się dowiedzieć więcej o przedstawianym przeze mnie temacie.

Jako pierwsze zareklamuje swoje wcześniejsze wpisy:

- Opis metodyki SCRUM

- Instalacja TFS 11

- Wystawienie TFS na zewnątrz

- Utworzenie projektu w TFS

- Continuous Integration i automatyczne buildy

- Proces TDD w realizowanym projekcie

A teraz linki z których korzystałem:

- Ogólny opis nowości w TFS 11

- Tworzenie storyboardów

- Testowanie przy pomocy Test Managera

- Zarządzanie kontaktem z klientem (Feedback Manager) - tutorial

- Zmiany w Team Explorerze oraz opis Code Review

- Nowy mechanizm merge'owania plików

- Podsumowanie zmian w kontroli wersji

- Raporty z TFS przy użyciu Excela

- Maszyna wirtualna z przykładową konfiguracją TFS oraz sporo tutoriali

Polecam również dwie świetne książki (dotyczą one co prawda TFS 2010, ale większość porad i opisów ma również zastosowanie w przypadku nowej wersji):

- "Professional Scrum with Team Foundation Server 2010" - S.Resnick, A. Bjork, M. de la Maza

- "Proffesional Team Foundation Server 2010" - E. Blankenship, M. Woodward, G. Holliday, B. Keller

Miłej lektury!

   

Multiplatforomowe aplikacje w .NET, Silverlight i Windows Phone Cz.3 - Konfiguracja komunikacji socketami

Wstęp

W poprzednich dwóch wpisach, przedstawiłem ogólne zasady tworzenia aplikacji multiplatformowych, pokazałem jak można zapisywać i odczytywać dane z socketów. Oparłem się przy tym mocno na przykładzie Johna Papa. W tym przykładzie pójdę dalej tym tropem i pokażę jak można uruchomić komunikację klient serwer. Jak sprawić, żeby sockety zaczęły nasłuchiwać i ze sobą rozmawiać.

Odczyt/zapis socketa

W poprzednim wpisie przedstawiłem dwie klasy do odczytywania poleceń przesyłanych przez sockety (kody źródłowe dostępne są tutaj), Ponieważ nasze sockety będą miały komunikować się dwustronnie dla uproszczenia sprawy wprowadźmy jeszcze dodatkową klasę opakowującą CommandReaderWriter.

public class CommandReaderWriter
{
    public Socket Socket { get; protected set; }
    public delegate void OnConnectedDelegate(object sender, SocketAsyncEventArgs e);

    public event OnConnectedDelegate OnConnectedEvent = delegate { };

    public CommandReader Reader { get; protected set; }
    public CommandWriter Writer { get; protected set; }

    public CommandReaderWriter()
    {

    }

    public CommandReaderWriter(Socket socket)
    {
        InitializeConnection(socket);
    }

    /// <summary>
    /// Metoda inicjująca połączenie z konkretnym socketem
    /// </summary>
    /// <param name="socket"></param>
    public void InitializeConnection(Socket socket)
    {
        Reader = new CommandReader(socket);
        Writer = new CommandWriter(socket);
    }

    /// <summary>
    /// Metoda inicjująca połączenie z socketem
    /// znajdującym się pod wskazany adresem i portem
    /// </summary>
    /// <param name="serverName">adres serwera</param>
    /// <param name="port">port</param>
    public void InitializeConnection(string serverName, int port)
    {
        var s = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
        var e = new SocketAsyncEventArgs
                {
                    RemoteEndPoint = new DnsEndPoint(serverName, port)
                };
        e.Completed += OnConnected;
        s.ConnectAsync(e);
    }

    /// <summary>
    /// Metoda obsługująca zdarzenie połączenia się z socketem
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    private void OnConnected(object sender, SocketAsyncEventArgs e)
    {
        Socket s = (Socket)sender;
        if (e.SocketError != SocketError.Success)
        {
            throw new Exception("Nie udało się połączyć!");
        }

        InitializeConnection(s);

        OnConnectedEvent(this, e);
    }

    /// <summary>
    /// Metoda zakańczająca nasłuchiwanie socketu
    /// </summary>
    public void StopReading()
    {
        Reader.StopReading();
    }

    /// <summary>
    /// Metoda rozpoczynająca nasłuchiwanie socketu
    /// </summary>
    /// <param name="h"></param>
    public void StartListening(ICommandHandler h)
    {
        Reader.StartListening(h);
    }

    /// <summary>
    /// Metoda wysyłająca polecenie poprzez socket
    /// przekazany w konstruktorze
    /// </summary>
    /// <param name="command">polecenie</param>
    public void Write(Command command)
    {
        Writer.Write(command);
    }

    public void DoCommand(CommandReader r, Command cmd)
    {
        //tutaj dodana zostanie obsługi polecenia
    }
}

Klasa ta oprócz opakowania metod CommandReader i CommandWriter posiada też metody odpowiedzialne za jego inicjalizację. Ta z adresem i numerem portu powinna być używana przez aplikację kliencką, ta z Socketem w aplikacji serwerowej.
Mamy już tak naprawdę komplet klas, które pozwolą nam na odczytywanie i zapisywanie z socketów. Musimy teraz utworzyć klasy, które je nam wywołają.


Konfiguracja klienta


Zacznijmy od sprawy prostszej - konfiguracji klienta. Otwórzmy definicję głównego okna aplikacji Multiplatform.Client.Silverlight - MainPage.xaml.cs i zmodyfikujmy je następująco:

public partial class MainPage : UserControl, ICommandHandler
{
    private CommandReaderWriter _commandReaderWriter;

    public MainPage()
    {
        InitializeComponent();

        InitializeNetworkConnection();
    }

    /// <summary>
    /// Metoda inicjująca połączenie z serwerem
    /// </summary>
    private void InitializeNetworkConnection()
    {
        _commandReaderWriter = new CommandReaderWriter();
        _commandReaderWriter.InitializeConnection("localhost", 4529);
        _commandReaderWriter.OnConnectedEvent += CommandReaderWriter_OnConnectedEvent;
    }

    /// <summary>
    /// Metoda przechwytująca zdarzenie połączenia z serwerem
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    void CommandReaderWriter_OnConnectedEvent(object sender, SocketAsyncEventArgs e)
    {
        //skoro udało się połączyć, to rozpocznij nasłuchiwanie
        _commandReaderWriter.StartListening(this);
    }

    public void DoCommand(CommandReader r, Command cmd)
    {
        //tutaj będzie obsługa poleceń
    }
}

Dodaliśmy do niego zainicjowanie połączenia z serwerem poprzez podanie adresu oraz numeru portu, na którym będziemy nasłuchiwać. Klasa ta implementuje również interfejs ICommandHandler, dzięki czemu może obsługiwać polecenia wysłane przez serwer.
Dokładnie to samo moglibyśmy zrobić w przypadku MainWindow aplikacji WPF oraz MainPage w aplikacji na Phone'a, z małym wyjątkiem w przypadku tego ostatniego. Nie możemy podać jako adres serwera "localhost", gdyż emulator telefonu potraktuje to jako odwołanie się do siebie, a nie do naszego komputera. Możemy to łatwo obejść wpisując zamiast "localhost" nazwę sieciową naszego komputera. Należy uważać też na numer portu, ale o tym szerzej w kolejnym punkcie.


Konfiguracja serwera


Serwer w swoim zachowaniu będzie zbliżony do klienta, poza tym, że będzie musiał rozpocząć nasłuchiwanie na połączenie z klientem, a nie łączyć się bezpośrednio z nim. Utwórzmy nowy katalog solucji "Server" oraz nowy projekt "Multiplatform.Server" typu "Class Library". Dodajmy klasę ServerProgram - będzie ona odpowiadała za rozpoczęcie nasłuchiwania oraz obsługę poleceń od klienta. Powinna ona wyglądać następująco:

public class ServerProgram : ICommandHandler
{
    readonly TcpListener _server = new TcpListener(IPAddress.Any, 4529);

    private CommandReaderWriter _commandReaderWriter;

    void Run()
    {
        _server.Start();
        while (true)
        {
            Socket s = _server.AcceptSocket();

            _commandReaderWriter = new CommandReaderWriter(s);
            _commandReaderWriter.StartListening(this);
        }
    }

    /// <summary>
    /// Statyczna metoda tworząca nową instancję serwera
    /// </summary>
    public static void Start()
    {
        Console.WriteLine("Starting PictureHunt Server on port 4529");
        var p = new ServerProgram();
        p.Run();
    }

    /// <summary>
    /// Metoda obsługująca polecenie od klienta
    /// </summary>
    /// <param name="r"></param>
    /// <param name="cmd"></param>
    public void DoCommand(CommandReader r, Command cmd)
    {
        //tutaj będziemy obsługiwać polecenie
    }
}

Utwórzmy jeszcze projekt Multiplatform.Server.Host w katalogu solucji Server, który będzie uruchamiał metodę Start naszego Servera w swojej metodzie Main (oszczędzę sobie trudu wklejania, a Wam czytania tej jakże zawiłej klasy).


Wprawiamy to wszystko w ruch


Mamy już zatem 3 rodzaje klientów - WPF, Silverlight, Phone oraz serwer. Co prawda jest to póki co dosyć oszukany serwer bo może obsłużyć, ale zawsze... 
Wypadało by teraz zrobić jakąś własną komendę, dzięki której będziemy mogli przetestować czy nasz szkielet, ma już mięśnie, czy dalej odmawia uczynienia choćby małego ruchu. Zróbmy klasę we współdzielonym projekcie TextCommand, będzie ona pozwalała na przesłanie tekstu.

public class TextCommand : Command
{
    public string Text { get; set; }

    public TextCommand()
    {
        CommandType = 1;
    }

    public TextCommand(string text) : this()
    {
        Text = text;

        // tutaj powinna być serializacja binarna
        // obiektu Text i przypisanie do tablicy Data
    }
}

Jak widzimy jest to bardzo prosta klasa. Dziedziczy po klasie Command, ma konstruktor domyślny oraz przyjmujący parametr z tekstem, który chcemy przesłać. Na pewno was zastanawia dlaczego nie zrobiłem tutaj standardowej serializacji przy pomocy BinaryFormattera. Otóż nie mogłem tego zrobić, bo z nieznanych mi powodów w Silverlight tej klasy nie ma. Można kombinować i robić hacki stosując serializację WCFową, ja jednak polecam użycie Open Source'owej biblioteki SharpSerializer. Pozwala ona na całkiem sprawną i szybką serializację zarówno w zwykłych projektach .NETowych jak i Silverlight, Windows Phone.
Po pobraniu i dołączeniu plików dll do projektów dodajmy klasę opakowującą do dla tej biblioteki.

public static class BinaryUtils
{
    private static readonly SharpSerializer SharpSerializer = new SharpSerializer(true);

    public static byte[] Serialize(object obj)
    {
        using (var memoryStream = new MemoryStream())
        {
            SharpSerializer.Serialize(obj, memoryStream);

            return memoryStream.GetBuffer();
        }
    }

    public static object Deserialize(byte[] bytes)
    {
        using (var memoryStream = new MemoryStream(bytes))
        {
            return SharpSerializer.Deserialize(memoryStream);
        }
    }
}

Jak widać, użycie biblioteki jest banalnie proste, nie wymaga specjalnego tłumaczenia. Mając to już gotowe, możemy dodać serializację tekstu w konstruktorze naszej klasy TextCommand. Ostatecznie wygląda on:

public TextCommand(string text) : this()
{
    Text = text;

    Data = BinaryUtils.Serialize(Text);
}

Dodajmy więc prostą funkcjonalność przesyłania tej komendy pomiędzy klientem a serwerem i odwrotnie. Klient po nawiązaniu połączenia wyśle wiadomość "Ping", serwer mu odpowie wiadomością "Pong". Musimy dokonać zmian w obsłudze Poleceń zarówno po stronie klienckiej ja i stronie serwerowej.

Klasa okna klienta wyglądało będzie po zmianach:

public partial class MainWindow : Window, ICommandHandler
{
    private CommandReaderWriter _commandReaderWriter;

    public MainWindow()
    {
        InitializeComponent();

        InitializeNetworkConnection();
    }

    /// <summary>
    /// Metoda inicjująca połączenie z serwerem
    /// </summary>
    private void InitializeNetworkConnection()
    {
        _commandReaderWriter = new CommandReaderWriter();
        _commandReaderWriter.InitializeConnection("localhost", 4529);
        _commandReaderWriter.OnConnectedEvent += CommandReaderWriter_OnConnectedEvent;
    }

    /// <summary>
    /// Metoda przechwytująca zdarzenie połączenia z serwerem
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    void CommandReaderWriter_OnConnectedEvent(object sender, SocketAsyncEventArgs e)
    {
        //skoro udało się połączyć, to rozpocznij nasłuchiwanie
        _commandReaderWriter.StartListening(this);
        _commandReaderWriter.Write(new TextCommand("Ping!")); // 1.
    }

    public void DoCommand(CommandReader r, Command cmd)
    {
        switch (cmd.CommandType)
        {
            case 1:
                string text = (string)BinaryUtils.Deserialize(cmd.Data); //2
                Debug.WriteLine(text);
                break;
        }
    }
}

Dodałem przesłanie polecenia z tekstem po nawiązaniu połączenia z serwerem (oznaczone numerem 1) oraz przechwycenie polecenia z serwera i obsłużenie go (oznaczone numerem 2). Analogicznie klasa serwera po zmianach będzie wyglądała:

public class ServerProgram : ICommandHandler
{
    readonly TcpListener _server = new TcpListener(IPAddress.Any, 4529);

    private CommandReaderWriter _commandReaderWriter;

    void Run()
    {
        _server.Start();
        while (true)
        {
            Socket s = _server.AcceptSocket();

            _commandReaderWriter = new CommandReaderWriter(s);
            _commandReaderWriter.StartListening(this);
        }
    }

    /// <summary>
    /// Statyczna metoda tworząca nową instancję serwera
    /// </summary>
    public static void Start()
    {
        Console.WriteLine("Starting PictureHunt Server on port 4529");
        var p = new ServerProgram();
        p.Run();
    }

    /// <summary>
    /// Metoda obsługująca polecenie od klienta
    /// </summary>
    /// <param name="r"></param>
    /// <param name="cmd"></param>
    public void DoCommand(CommandReader r, Command cmd)
    {
        switch (cmd.CommandType)
        {
            case 1:
                string text = (string)BinaryUtils.Deserialize(cmd.Data);
                Console.WriteLine(text);
                //odpowiedz klientowi "Pong!"
                _commandReaderWriter.Write(new TextCommand("Pong!"));
                break;
        }
    }
}

Pozostało nam tylko dodać jeszcze obsługę naszego polecenia w CommandReaderze w metodzie TransformData

private void TransformData(SocketAsyncEventArgs e)
{
    [...]
    while (data.Length >= 12)
    {
        [...]

        //zainicjuj obiekt polecenia
        Command cmd = null;
        switch (opcode)
        {
            case 1:
                cmd = new TextCommand {Data = newData};
                break;
            default:
                cmd = new Command{Data = newData};
                break;
        }

        [...]
    }
}

Możecie śmiało odpalić serwer, i jedną z aplikacji klienckich, wszędzie zadziała dobrze oprócz Silverlighta. Dlaczego? Wytłumaczenie znajdziecie w kolejnym punkcie...

Silverlight i Sockety

Silverlight jako chyba najbardziej irytująca technologia Microsoftu i tutaj musi utrudniać programistom życie. Oczywiście celem jest dobro i bezpieczeństwo użytkowników końcowych. Ja jednak nie do końca ufam i nie do końca wierzę tym tłumaczeniom, skoro w Windows Phone nie ma już takich utrudnień związanych z socketami.

Szczegółowo można przeczytać na ten temat w artykule Network Security Access Restrictions in Silverlight na MSDN - ja postaram się to skrócić w kilku zdaniach. Aby zachować bezpieczeństwo i wygodę użytkowników w Silverlight można łączyć się z Socketami tylko z zakresu 4502-4534. Dodatkowo aplikacja Silverlightowa łącząca się z serwerem na zadanym adresie i zadanym porcie najpierw próbuje połączyć się z tym adresem z portem 943. Oczekuje, że na tym porcie będzie wystawiona usługa, która mu dostarczy plik xml z informacjami o zasadach bezpieczeństwa (tzw. "policy file").

Jeżeli nie odnajdzie tej usługi i nie pobierze tego pliku, to automatycznie ignoruje połączenie uznając, że jest ono niebezpieczne. Wszystko dla naszego dobra, oczywiście.

Nie będę tutaj wklejał tego kodu, jest on dostępny w przedstawionym wcześniej artykule, oraz w kodach źródłowych na końcu artykułu. Należy pamiętać, żeby usługa ta była zawsze uruchomiona na tym samym adresie co nasz serwer.

Podsumowanie

W tym artykule pokazałem już jak wprawić w ruch machinę komunikacji socketami pomiędzy klientem a serwerem i serwerem a klientem. W kolejnych artykułach przedstawię jak zrobić serwer obsługujący wielu użytkowników oraz jak ukryć za fasadą tą niezbyt elegancką obsługę komend.

Kody źródłowe możecie pobrać stąd.

Multiplatforomowe aplikacje w .NET, Silverlight i Windows Phone Cz.2 - Wstęp do komunikacji socketami

Wstęp

W poprzednim wpisie przedstawiłem wstęp oraz kilka problemów, które napotykamy przy rozpoczęciu zabawy z aplikacji wieloplatformowych. Tak jak zapowiedziałem, w tym wpisie przedstawię kolejny krok do utworzenia gry multiplayer w Kuku. Tym razem na warsztat wzięte zostają metody komunikacji klient-serwer, serwer-klient przy pomocy socketów. Dlaczego przy pomocy socketów, a nie WCF? Szczegóły później. Najpierw się zastanówmy czego tak naprawdę potrzebujemy.

Naszą wersję Kuku można opisać następująco:

- zbierają się gracze,

- każdemu z nich rozdajemy karty, pierwszy gracz dostaje 4, resta 3,

- jeżeli któryś z graczy ma 3 karty w jednym kolorze lub z tymi samymi figurami, to może krzyknąć "kuku!". Jeżeli nikt tego nie zrobił, to

- zaczyna się tura pierwszego gracza,

- wybiera on jedną kartę i przekazuje ją kolejnemu graczowi,

- zaczyna się jego tura,

- jeśli karta do niego wróci, może ją wymienić,

- kto pierwszy skompletuje kuku ten wygrywa.

Zatem nasza gra powinna:

- umożliwić dołączanie graczy,

- reagować na wybory gracza,

- powiadamiać graczy o zmianie stanu gry. 

Potrzebujemy zatem komunikacji pomiędzy graczami. Niektórym z Was od razu może się to skojarzyć z grami/programami typu P2P (Peer To Peer). Będzie to bardzo dobre skojarzenie. Implementując nasz system można by było w teorii pokusić się o to, żeby gracz, wysyłał kolejnemu graczowi informację: "Stary teraz twoja kolej!". A pozostałym o tym, że to zrobił. Niestety takie systemy są trudne do utrzymania, kontroli i rozwoju. Dodatkowo cała logika biznesowa jest przechowywana w aplikacji klienckiej, co powoduje ich nadmierny rozrost, tworząc je za dużymi do zastosowania na stronach internetowych oraz telefonach komórkowych. Według mnie lepsze jest rozwiązanie pośrednie:

- gracz przesyła informację do serwera o swoim wyborze,

- serwer decyduje o tym jaka akcja powinna być wykonana - to on mówi kolejnemu graczowi o jego turze, on rozsyła informacje do pozostałych graczy.

Komunikacja musi być zatem dwustronna:

- klient - serwer

- serwer - klient

Podejrzewam, że większość z Was miała już do czynienia z web service'ami pisanymi przy pomocy WCF. Są one dobre dla standardowych rozwiązań biznesowych, w których wysyłamy zapytanie, dostajemy odpowiedź - typowa komunikacja jednostronna. Niestety ten model komunikacji nie sprawdzi się w przypadku naszego problemu. U nas żądania wysyłane są w dwie strony, nie wiemy również kiedy dokładnie one wystąpią. Niektórzy z Was zapewne natrafili na Duplex Channel, pozwalający oprogramować w WCF komunikację dwustronną. Niestety w Silverlight dostępna jest tylko jego uboższa wersja, mając dużo ograniczeń, nie nadająca się do rozwiązań komercyjnych (więcej szczegółów na blogu Tomasza Janczuka tutaj i tutaj). Z pomocą przyjdą nam stare jak świat sockety.

Sockety 

Jest to rozwiązanie znane od dawien dawna, istnieje ono zarówno w C++ jak i w Javie. Nie będę się nad tym przesadnie rozpisywał, raczej przedstawię ich ogólną zasadę.

Sockety pozwalają na bezpośrednią komunikację pomiędzy dwoma komputerami. Aby nawiązać połączenie musimy znać adres internetowy komputera oraz port, na którym on nasłuchuje. Klient znając te dane serwera łączy się z nim. Tworzone jest połączenie TCP. Połączenie jest utrzymywane cały czas, dlatego też możliwa jest komunikacja w dwie strony. Odbywa się ona przy pomocy strumienia bajtów. Zalety tego rozwiązania to szybkość i wydajność, minusem jest to, że musimy oprogramować cały mechanizm "odszyfrowywania" strumienia. Musimy sami określać, które bajty odpowiadają za co, gdzie kończy się jedno rozwiązanie, a zaczyna kolejne.

W moich rozważaniach punktem wyjściowym będzie świetny przykład Johna Papa zaprezentowany na Silverlight TV. Przedstawił on tam podstawowy mechanizm przetwarzania socketów, zachęcam do przyjrzenia się mu i porównania ze zmianami, które do niego wprowadziłem.

Zaproponował on bardzo sprytny i prosty zarazem sposób przetwarzania danych przesyłanych w socketach, wykorzystał on przy tym wzorzec projektowy Polecenie (Command).
Chcąc przesłać żądanie do serwera musimy utworzyć obiekt klasy Command. Następnie serializujemy go do postaci binarnej i przesyłamy go poprzez socket do serwera. Serwer odbiera bajty i deserializuje je. Tak utworzony obiekt polecenia przetwarzamy przy pomocy klasy pomocniczej CommandHandler. Dla każdego rodzaju operacji konieczne jest utworzenie implementacji klasy Command, dzięki temu klasa pomocnicza wie w jaki sposób ma wykonać polecenie (na podstawie jej typu).
Wspominałem wcześniej, że największym problemem przy Socketach jest określenie, w jaki sposób rozdzielić jedno żądanie od innego. Tak jak już napisałem pomiędzy klientem a serwerem utworzony jest strumień TCP. Zwykle  każde żądanie jest wysyłane osobno, lecz może dość do sytuacji gdy w jednym pakiecie wysłane zostanie kilka żądań (np. gdy są opóźnienia w sieci a klient wykonał szybko kilka akcji), lub jedno żądanie zostanie podzielone na kilka pakietów (np. gdy wysyłamy sporą liczbę danych). Nie będziemy wiedzieli więc od razu po odczytaniu danych ze strumienia, czy możemy już deserializować i wykonać Polecenie. Jak zatem sobie z tym poradzić? 
John Papa zaproponował, żeby komenda posiadała nagłówek. Nagłówek ten posiadał będzie podstawowe informacje o niej (takie jak jej rozmiar). Najważniejszą jego cechą jest to, że będzie on miał stałą wielkość. Dzięki czemu będzie można go zserializować od razu gdy zorientujemy się, że mamy do czynienia z nowym żądaniem. Po jego odczytaniu będziemy wiedzieć ile jeszcze bajtów zostało nam do odczytania, wiedząc tym samym, w którym miejscu kończy się żądanie. 

Konkrety


Klasa polecenia napisana zgodnie z tymi wytycznymi wygląda następująco:

/// <summary>
/// Klasa wzorowana na rozwiązaniu przedstawionym
/// przez Johna Papa w Silverlight TV
/// http://channel9.msdn.com/Shows/SilverlightTV/Silverlight-TV-70-Sockets-Unplugged
/// </summary>
public class Command
{
    /// <summary>
    /// Typ polecenia
    /// 
    public int CommandType;
    /// <summary>
    /// Rozmiar nagłówka
    /// </summary>
    public int HeaderLen;
    /// <summary>
    /// Dane nagłówka
    /// </summary>
    public byte[] Header;

    /// <summary>
    /// Dane polecenia
    /// </summary>
    public byte[] Data;

    public Command()
    {
        HeaderLen = 12;
        Header = null;
        Data = null;
    }
        
    /// <summary>
    /// Metoda inicjująca nagłówek
    /// </summary>
    /// <returns></returns>
    public virtual BinaryWriter InitHeader()
    {
        Debug.Assert(CommandType != 0);
        Debug.Assert(HeaderLen >= 12);
        Header = new byte[HeaderLen];
        var bw = new BinaryWriter(new MemoryStream(Header));
        bw.Write(Htonl(HeaderLen));
        bw.Write(Htonl(Data == null ? 0 : Data.Length));
        bw.Write(Htonl(CommandType));
        return bw;
    }

    /// <summary>
    /// Metoda formatująca liczby do formatu
    /// odpowiedzniego dla socketów
    /// </summary>
    /// <param name="value"></param>
    /// <returns></returns>
    public Int32 Htonl(Int32 value)
    {
        return IPAddress.HostToNetworkOrder(value);
    }
}

Do zapisywania wysłania polecenia przez Socket służy klasa CommandWriter

/// <summary>
/// Klasa służąca do wysyłania danych poprzez socket
/// </summary>
public class CommandWriter
{
    public Socket Socket;

    public CommandWriter()
    {
    }

    public CommandWriter(Socket socket)
    {
        Socket = socket;
    }

    /// <summary>
    /// Metoda wysyłająca polecenie poprzez socket
    /// przekazany w konstruktorze
    /// </summary>
    /// <param name="command">polecenie</param>
    public void Write(Command command)
    {
        Write(Socket, command);
    }

    /// <summary>
    /// Metoda wysyłająca polecenie poprzez
    /// zadany socket
    /// </summary>
    /// <param name="socket">socket</param>
    /// <param name="command">polecenie</param>
    public void Write(Socket socket, Command command)
    {
        //utwórz nagłówek
        command.InitHeader();
        var senddata = new List<ArraySegment<byte>> { new ArraySegment<byte>(command.Header) };
        //wrzuć dane polecenia
        if (command.Data != null)
        {
            senddata.Add(new ArraySegment<byte>(command.Data));
        }
        var writeEventArgs = new SocketAsyncEventArgs();
        writeEventArgs.Completed += WriteCompleted;
        writeEventArgs.BufferList = senddata;
        //wyślij socketem bajty
        socket.SendAsync(writeEventArgs);
    }
}

Klasa odczytująca polecenie z socketa będzie wyglądała następująco:

/// <summary>
/// Klasa służaca do odczytywania danych z socketa
/// wzorowana na rozwiązaniu przedstawionym
/// przez Johna Papa w Silverlight TV
/// http://channel9.msdn.com/Shows/SilverlightTV/Silverlight-TV-70-Sockets-Unplugged
/// </summary>
public class CommandReader
{
    public Socket Socket;

    byte[] data = new byte[0];

    public CommandReader(Socket socket)
    {
        this.Socket = socket;
    }
    /// <summary>
    /// Metoda zamieniająca liczbę z formatu socketa
    /// na format standardowy
    /// </summary>
    /// <param name="value"></param>
    /// <returns></returns>
    public static Int32 Ntohl(Int32 value)
    {
        return System.Net.IPAddress.NetworkToHostOrder(value);
    }

    /// <summary>
    /// Metoda rozpoczynająca nasłuchiwanie socketu
    /// </summary>
    /// <param name="h"></param>
    public void StartListening(ICommandHandler h)
    {
        Console.WriteLine("CR: Go  : Socket {0} CR {1}", Socket, this);

        //określ parametry nasłuchiwania
        const int size = 10000;
        var e = new SocketAsyncEventArgs();
        e.Completed += OnRead;
        e.UserToken = h;
        e.SetBuffer(new byte[size], 0, size);

        //rozpocznij nasłuchiwanie
        while (Socket.ReceiveAsync(e) == false)
        {
            TransformData(e);
        }
    }

    /// <summary>
    /// Metoda wywołana po zaczytaniu paczki danych z socketa
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    private void OnRead(object sender, SocketAsyncEventArgs e)
    {
        //przetwarzaj dane
        TransformData(e);
        //nasłuchuj czy nie przychodzą kolejne porcje danych
        while (Socket != null && Socket.ReceiveAsync(e) == false)
        {
            TransformData(e);
            if (e.BytesTransferred == 0)
            {
                break;
            }
        }

    }
    /// <summary>
    /// Metoda przetwarzająca dane otrzymane z socketa
    /// </summary>
    /// <param name="e"></param>
    private void TransformData(SocketAsyncEventArgs e)
    {
        var oldLen = data.Length;
        var newLen = oldLen + e.BytesTransferred;
        Array.Resize<byte>(ref data, newLen);
        Array.Copy(e.Buffer, 0, data, oldLen, e.BytesTransferred);
        while (data.Length >= 12)
        {
            //pobrano już co najmniej nagłówek
            var reader = new BinaryReader(new MemoryStream(data));
            var headerLen = Ntohl(reader.ReadInt32());
            var dataLen = Ntohl(reader.ReadInt32());
            var opcode = Ntohl(reader.ReadInt32());
            var totLen = headerLen + dataLen;
            var extra = data.Length - totLen;

            //jeżeli nie pobrano jeszcze całości danych
            //zakończ przetwarzanie i czekaj na kolejną
            //paczkę z danymi
            if (extra < 0)
                break;
                
            //Pobrano już co najmniej tyle danych ile ma polecenie
            //utwórz nową tablicę do przechowywania danych polecenia
            byte[] newData = new Byte[dataLen];
            Array.Copy(data, headerLen, newData, 0, dataLen);

            //zainicjuj obiekt polecenia
            Command cmd = null;
            switch (opcode)
            {
                //tutaj wstawiamy tworzenie poszczególnych poleceń
                //w zależności od typu
                default:
                    cmd = new Command{Data = newData};
                    break;
            }

            //jeżeli pobrano więcej bajtów niż miało mieć polecenie
            //przenieś je do nowej tablicy
            if (extra > 0)
            {
                Array.Copy(data, totLen, data, 0, extra);
            }
            Array.Resize<byte>(ref data, extra);

            //wykonaj polecenie
            ICommandHandler h = (ICommandHandler)e.UserToken;
            h.DoCommand(this, cmd);
        }
    }
}

Podsumowanie

W tym poście przedstawiłem ogólny zarys sposobu komunikacji dla aplikacji multiplatformowych w środowisku .NET. Pokazane zostało po co nam komunikacja dwustronna, klient - serwer, serwer - klient. Jak można zaimplementować ją przy pomocy socketów.

Popisałem się również umiejętnością czytania ze zrozumieniem i pokazałem klasy do obsługi czytania i zapisu do socketów zaprezentowane przez Johna Papa. W kolejnych postach przedstawię jak w ogóle uruchomić sockety, jak skonfigurować serwer i klienta i pokażę trochę własnej inwencji przedstawiając swoje ulepszenia do dotychczas opisanych rozwiązań.

Kody źródłowe można pobrać tutaj.