Różowy Windows Phone i kobiety na wysokościach

28. stycznia we Wrocławiu odbyło się 8. spotkanie Women in Technology. Niecnie wykorzystałam swoją znajomość z szefową i wkręciłam się wtedy na prelekcję ze swoim cyrkiem obwoźnym, czyli wstępem do programowania w Windows Phone. Sam łysogórski zlot odbył się na 25 piętrze SkyTower. Przypomniało mi się dość szybko, że mam lęk wysokości, więc przez całe spotkanie unikałam wielkiego okna z tyłu sali. Mimo wszystko trochę go przełamałam i udało mi się uchwycić widoczny stamtąd uliczny zgiełk.

wit

Gosia rozpoczęła spotkanie od przedstawienia kilku nowości technologiczno-konferencyjno-sponsoringowych (jakkolwiek dziwacznie to brzmi Uśmiech). Następnie po krótkim przedstawieniu się wszystkich, rozpoczęłam prezentację.

Po ostatniej porażce konfiguracyjno-przygotowawczej, mój poziom pewności siebie oscylował w okolicach –10. Dlatego tego dnia pojawiłam się na miejscu dużo wcześniej i sprawdziłam, czy na pewno wszystko dobrze działa.

Działało Uśmiech … do momentu, gdy miałam rozpocząć. Na pierwszy ogień poszedł rzutnik – nie chciał wyświetlić niczego co miałam na ekranie, choć robił to zaledwie 15 min wcześniej. No ale powiedzmy, że się na mnie obraził za to, że udostępniłam go Gosi zamiast tkwić wiernie przyczepiona kabelkiem. Nie obyło się bez jego restartu, co wprowadziło nieco ożywienia, bo pilot również odmówił współpracy. Pozostała więc drabina i ręczne użycie guzika prezentera przyczepionego do sufitu.

Potem oczywiście padła mi sieć i wywalił się emulator, ale… wpadłam na iście genialny pomysł. Zamiast miotać się z szukaniem problemów w konfiguracji, postanowiłam zastosować najstarszą sztuczkę w świecie IT – turn it off and on again… wiedząc, że mój komp wstanie w czasie ok. 5 sekund. Decyzja ta zbawiła moje wystąpienie, a dalsza część przeszła już gładko i bez zbędnych przerywników.

W kilku momentach pojawiły się dyskusje, ponieważ na sali obecne były ekspertki od Windows Phone. Sama też dowiedziałam się kilku rzeczy, dzięki czemu moja prezentacja po raz kolejny została ulepszona. Przekonywałam jak zwykle, by w codziennej pracy używać urządzenia zamiast emulatora. A z racji takiego, a nie innego grona, wzbudzałam mniej kontrowersji, gdy machałam różowym telefonem.

WP_20140128_001-150x150

Po mnie nastąpiła kolej na ćwiczenie networkingowe, za przygotowanie którego należy się wielki szacun dla Kasi. Dowiedziałyśmy się (pewnie po raz kolejny) jak ważna jest komunikacja i jak różne może przybierać formy. Poznałyśmy się trochę lepiej i już w całkiem luźnym, choć nadal licznym gronie wybrałyśmy się na afterowego browara.

IoC, DI i akademicka dyskusja

W sobotę odbyła się łódzka konferencja GET.NET (o czym jeszcze napiszę), w trakcie której tuż przed moją, odbyła się prezentacja Procenta o Dependency Injection. Samo wystąpienie było świetne, a moją ciekawość podsyciła dodatkowo obietnica (powtórzona dwukrotnie) wyjaśnienia całego zamieszania wokół pojęć DI (Dependency Injecton i Inversion) oraz IoC. Jakie było moje rozczarowanie, gdy upragniony moment nadszedł, a Maciek skwitował wszystko zdaniem, że definicje nie są ważne.

Oj wkurzyłam się… Pomyślałam – naprawdę? Czy to, że ludzie mylą te pojęcia oznacza, że powinniśmy to olać i pozwolić, by żółć sączyła się z rany? Oczywiście zgadzam się z ogólnym stwierdzeniem, że w sumie nie ważna jest nomenklatura, byle dobre praktyki stosować, ale… czy na pewno tak jest do końca? Czy SRP pod inna nazwą równie by pachniała? Czy od teraz powinniśmy się komunikować opisując co dana zasada czy wzorzec robi, zamiast operować ich nazwami? Jakoś tego nie widzę, zajmowałoby to stanowczo za dużo czasu.

No to jak to jest z tym IoC i DI? Ano bardzo prosto, aż szkoda, że tyle przekłamań w internetach. Zacznijmy od ogółu.

Inversion of Control

IoC jest zasadą, która przeciwstawia się tradycyjnemu proceduralnemu podejściu do programowania. Polega na odwróceniu kontroli (tak, wiem, że rozumiecie Uśmiech), w taki sposób, by miał ją zewnętrzny kod zamiast głównego flowu.

A oto obrazek przedstawiający ideę, zapożyczony z ok kolegi z fb, gdyż stwierdził (a ja się zgodziłam), że go tu brakuje.

ioc

W tradycyjnym podejściu nasz program wykonuje kroki, wywołując metody bibliotek, do których posiada on referencje. W podejściu IoC natomiast, to zewnętrzny software wywołuje nasz kod by wykonać pewne akcje. Relacje wtedy układają się zupełnie na odwrót. Dlatego zasada ta jest często żartobliwie nazywana regułą Hollywood: Don’t call us, we’ll call you.

Jest to więc bardzo szerokie pojęcie, dużo szersze niż wstrzykiwanie zależności, czy Service Locator. Przykładami z innej bajki są eventy, callbacki, czy zwykłe programowanie bazujące na interfejsach (np. wzorzec strategii).

Dependency Injection

Czyli wiemy już, że DI jest po prostu jedną z implementacji IoC. Wzorcem projektowym polegającym na tym, że przekazujemy (injection) zależność (dependency) do obiektu. Zależność staje się częścią stanu klienta (np. polem klasy lub jego property). Kluczową sprawą jest fakt jej przekazania, by nie pozwalać na tworzenie lub pozyskiwanie jej po stronie używającego obiektu.

Dependency Inversion

A jak się ma do tego Dependency Inversion? Jest to jedna z zasad SOLID faworyzująca taką budowę modułów, by odwrócić zależności i wprowadzić jak najbardziej luźne powiązania między nimi. DI oraz Service Locator się do niej stosują. A brzmi ona następująco:

  • Moduły wyższego poziomu nie powinny polegać na modułach niższego poziomu, lecz na abstrakcjach
  • Abstrakcje nie powinny polegać na konkretnych implementacjach, to konkretne implementacje powinny polegać na abstrakcjach

(Błędnie stosowana często prowadzi do tego, że po prostu wrzucamy na każdym poziomie interfejs, który jest implementowany przez dokładnie jeden moduł, ale to temat na zupełnie inny post.)

Mylić więc Dependency Injection i Dependency Inversion to całkiem normalna sprawa. Natomiast wrzucanie tego do jednego wora z IoC, to już lekkie nadużycie, bo wór ten jest o wiele obszerniejszy.

Fody Weaver i PropertyChanged

Jeśli zdarza się nam pracować z plikami .xaml i korzystamy z dobrobytu jakim jest bindowanie kod-widok (niezależnie od tego czy będzie to MVVM czy code behind), po pewnym czasie nadchodzi moment, gdy szlag nas trafia i musimy napisać po raz kolejny zamiast prostego ładnego property:

public class MyClass
{
    public string MyProperty { get; set; }
}

jakiegoś takiego potworka:

public class MyClass
{
    public event PropertyChangedEventHandler PropertyChanged;

    string _myProperty;
    public string MyProperty
    {
        get { return _myProperty; }
        set 
        {
            if (value != _myProperty)
            {
                _myProperty = value;
                OnPropertyChanged("MyProperty");
            }
        }
    }

    public virtual void OnPropertyChanged(string propertyName)
    {
        var propertyChanged = PropertyChanged;
        if(propertyChanged != null)
        {
            propertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }
}

Pojawiają się w naszej klasie: event, implementacja metody OnPropertyChanged, oraz jej wykorzystanie w setterach. Pomijam tu “smaczek” podawania nazwy w stringu. To i tak nie jest najgorsze co się nam może przydarzyć. Moglibyśmy mieć property, które odwołuje się do kilku innych. Wtedy musimy dodatkowo pamiętać, by OnPropertyChanged dla niego wykonać w setterach składowych.

Bleh…

Z pomocą przychodzi np. Fody. Jest to prosty pakiet, który należy ściągnąć (np. stąd, lub nugetem), zainstalować i nakazać projektowi, by go używał (Project > Fody > Enable). Dodatkowo, przyda się konfiguracja weavera. Jest na to kilka opcji, a tu już odsyłam do dokumentacji.

Ja akurat używam pliku .xml:

<?xml version="1.0" encoding="utf-8" ?>
<Weavers>
  <PropertyChanged EventInvokerNames="raisePropertyChanged"/>
</Weavers>

Dzięki temu nie muszę w swojej klasie ani w moim property robić nic poza czystym get i set. Moje ViewModele stają się zwykłymi klasami, bo chyba do tego zostały wymyślone.

Fody oczywiście sporo od siebie dodaje i kod przybiera inną formę. Nasza klasa zaczyna implementować interfejs, dostaje event, ma zaimplementowaną metodę OnPropertyChanged, a wszystkie property są poorane w przedstawiony wcześniej sposób, nawet te złożone z kilku innych. Ale czego oczy nie widzą, tego sercu nie żal Uśmiech

Hack.Krk w końcu w .Net

Po frekwencji na poszczególnych eventach, wnioskować można, że wiele osób wie, iż Base organizuje od czasu do czasu hackatony. Jednak zdziwienie przyszło ze środowiska .Net, najpierw z powodu tego, że Base w ogóle .Netem się bawi, potem, że wpadliśmy na pomysł zorganizowania Hack.KRK specjalnie dla programistów tej platformy.

Base kojarzy się raczej z Railsami. Choć wiele osób dopuszcza myśl, że jako firma wyznająca zasadę post PC, zatrudnia programistów systemów Android, czy iOS, to .Net nie jest nasuwającą się na myśl technologią. Wydarzenie było więc dobrą okazją by uświadomić brać programistyczną, że takowych programistów również mamy i potrzebujemy. 24.01.2014 odbył się więc pierwszy Hack.Krk .Net, którego gwiazdą i przyciągaczem tłumów miał być Procent. Informacje o evencie pojawiły się dość późno, ale i tak zebrał się niemały tłumek ludzi chętnych o gry w statki.

Z chłopakami wymyśliliśmy właśnie taką formę challengu. Wymyśliliśmy to raczej nadużycie – byliśmy na piwie w tej sprawie i gdy ja akurat wróciłam z toalety, dowiedziałam się, o pomyśle Kuby. Podobno miał go już dawno, czekał jedynie na nasz odpowiedni stan upojenia by go jednogłośnie przepchnąć.

Zaczęły się więc prace – głównie w trakcie okresu świątecznego. Koncepcyjnie pomysł przeszedł od fazy pojedynku do końcowej wersji – losowej planszy z określonymi wcześniej ilością i rodzajami statków, którą to mieli rozpracowywać gracze. Punktów dostawało się więcej jeśli zatopione zostały wszystkie statki przy jak najmniejszej liczbie ruchów. Dodatkowo brana była statystyka z kolejnych prób, by zminimalizować szczęśliwe trafy algorytmów losowych.

Przyszedł piątek i do Krakowa, w siedzibie Base pojawiło się sporo .Netowców. I nie tylko, bo zadanie zastali w formie API restowego, więc niemal każda technologia się nadawała. Wprowadzeniem była Randka z Nancy Procenta, a po niej nastąpił fight. Wszystko odbywało się w luźnej atmosferze przy towarzystwie browarów i dobrego jedzonka. Większość obecnych pilnie kodowała, ale było jedna grupa… ehm… moja, siadła w kącie i … kłapała zamiast programować.

Ok. 21:30 ruszyły zaplanowane wcześniej lightning talks. Roman mówił o stateless code, ja o tym jak wszyscy powinniśmy być architektami i jak świetnie jest w tej materii w Base, a Natalia i Jan namawiali nas do uczestniczenia w hack4good. Każdemu wyszło nieco dłużej niż błyskawicznie, ale to chyba niczemu nie szkodziło. Zaraz po wystąpieniu dostałam zaproszenie na wygłoszenie wersji rozszerzonej na wroc.net.

Cieszę się, że namówiłam Adriana by przyszedł (choć przyznaję, że bardzo się nie opierał), gdyż inaczej całe podium należałoby do Base’owców. A tak przynajmniej srebro zgarnął ktoś z zewnątrz. Dwa pierwsze miejsca nagrodzone zostały czołgami, które miały wziąć udział w pojedynku, ale… Adrian zepsuł baterie do swojego Uśmiech Pozostało nam więc oficjalnie zakończyć wieczór.

Dla mnie zdarzenie to było okazją by zaprosić kilku znajomych do Krakowa i spędzić wspólnie weekend. Ponieważ uwielbiam mieszkać sama, bo jestem silna niezależną kobietą Uśmiech, na co dzień nie do końca trawię gości. Albo inaczej – śmiało mogę powiedzieć, że za nimi nie przepadam. Coś mnie jednak podkusiło i postanowiłam przełamać to w sobie, przynajmniej na ten jeden weekend. I nie było łatwo.

3 osoby w piątek i 4 w sobotę, to coś co można określić jako zupełne przeciwieństwo mojego dotychczasowego aspargera i aspołeczności. Ale dało się. Pomimo trudności, tego, że po mroźnej nocy nie zapaliło mi auto, że musiałam łózko dzielić z koleżanką i skazać dwóch gości na nocleg na podłodze. Zaliczyliśmy wspólnie Schindlera, hamburgery, wieczorne winko i towarzyszące temu dyskusje.

W niedzielę byłam bardzo zmęczona towarzystwem, ale również zadowolona, że udało mi się spędzić trochę czasu z ludźmi, których lubię. A Maciek suma summarum okazał się gwiazdą TV.