ABB DevDay – podsumowanie


Wczoraj w Krakowie odbyła się druga edycja konferencji DevDay, organizowanej przez firmę ABB. O samej konferencji dowiedziałem się na początku września i kiedy zobaczyłem nazwiska prelegentów od razu stwierdziłem, że muszę tam być. O kim mowa i kto był prelegentem na DevDay? Scott Hanselman, Greg Young, Sebastien Lambla, Mark Rendle, Martin Mazur, Rob Ashton oraz Antek Piechnik, który do listy prelegentów doszedł niecałe 2 tyg przed konferencją. Każdy z prelegentów przedstawiał na prawdę wysoki poziom jeśli chodzi o wiedzę oraz prezentacje. Wszystkie sesje mają być dostępne online. Ja z miłą chęcią jeszcze raz obejrzę te prezentacje, bo na niektórych niestety całonocna podróż z Łodzi dała się we znaki i nie wszystko co prelegent mówił do mnie docierało.
Poniżej opiszę pokrótce o czym były poszczególne sesje i co mi się podobało w samej konferencji.

It’s not what you read, it’s what you ignore

Scott Hanselman

Pierwsza sesja chyba rozbudziła każdego, kto przyszedł na DevDay. Mogę śmiało stwierdzić, że Scott Hanselman robi świetne show podczas swojej prezentacji, była to chyba najlepsza prezentacja na jakiej byłem do tej pory. Sesja była o tym jak w dzisiejszych czasach nauczyć się ignorować mało istotne i niepotrzebne rzeczy, tak aby nie cierpieć z powodu przepełnienia informacją. Temat o którym można już było usłyszeć w jego wcześniejszych prezentacjach, czy poczytać na blogu, natomiast sam styl prowadzenia prezentacji był na tyle ciekawy, że publiczność praktycznie nie przestawała się śmiać. Niestety Scott wyszedł zaraz po swojej prezentacji i nie można już było z nim porozmawiać…

Hidden Complexity: Inside Simple.Data and Simple.Web

Mark Rendle

Największą niespodzianką tej sesji było zobaczenie jak Mark Rendle wygląda na prawdę. Zawsze chowa się za swoim awatarem, który nie zdradza do końca tego jak wygląda 😛 Temat jego prezentacji był oczywiście o Simple.Data, trochę mniej o Simple.Web, czyli bibliotekach ułatwiających dostęp do danych w .NET. Podczas sesji pokazał trochę kodu z Simple.Data oraz pokazał jak można wykorzystać techniki dynamicznego typowania w C#. Nie zawsze te przykłady były dobrymi technikami programowania (np przeciążenie wartości true), ale pokazały, że nie trzeba ograniczać się do silnie typowanego stylu programowania.

HTTP Caching 101

Sebastien Lambla

Sebastien opowiadał o możliwościach cache’owania danych zarówno po stronie serwera, jak i po stronie klienta oraz największych paradoksach protokołu HTTP 1.1. Większość jego prezentacji składało się z zapytań http i odpowiedzi serwera 🙂 Mimo wszystko wielką zaletą był entuzjazm z jakim prowadził całą prezentację.

Javascript sucks and it doesn’t matter

Rob Ashton

Bardzo popularny ostatnio temat, czyli Java Script. Rob Ashton pokazał, czemu programiści tak bardzo nie lubią pisać w javascripcie, oraz czemu powinniśmy zaakceptować, że java script ssie i po prostu w nim programować. Pierwsza część polegała na przedstawieniu paradoksów języka, coś podobnego do popularnego ostatnio filmiku na youtube: WAT. Potem już tylko pokazywał przykłady jak pisać w js, jak testować skrypty oraz jak poradzić sobie z brakiem obiektów w js. Warto obejrzeć tą prezentację, jeśli akurat szef zlecił Ci napisanie czegoś w js 🙂

Why you should talk to strangers

Martin Mazur

Kolejny prelegent okazał się bardzo sympatycznym szwedem, polskiego pochodzenia, który mówi równie dobrze po polsku, co po angielsku. Ogólnie prezentacja miała na celu nie tyle zachęcenie do podchodzenia do innych osób, co zmianę w sposobie myślenia o programistach innych języków jako ‚oni’, ‚ci gorsi’. Martin przedstawił kilka języków programowania oraz przykłady co z nich można wyciągnąć. Osobiście zachęcił mnie do poznania jakiegoś całkowicie odmiennego języka programowania, bo ostatnim czasy niczego poza C# nie miałem w rękach. Na koniec wymienił on listę języków programowania, które zna, czym bardzo mi zaimponował.

Shipping code

Antek Piechnik

Antek, mówił dużo o swojej firmie (FutureSimple) oraz o ich flagowym produkcie Base. Ogólnie mówił o tym czemu w jego firmie odeszli od klasycznych scrumowych metodyk programowania i postawili na technikę Programming motherfucker!. Dzięki takiemu rozwiązaniu są w stanie dostarczać rozwiązania o wiele szybciej i efektywniej, niż inne zespoły.

How to get productive in a project in 24h

Greg Young

Ostatnia prezentacja była nie lada wyzwaniem dla Grega Younga, musiał występować przed zmęczonymi i czekającymi na afterparty uczestnikami. Prezentacja Grega była o tym, jak potrafi w 3 dni usiąść do projektu, który widzi pierwszy raz w życiu i powiedzieć liderowi projektu gdzie jest błąd. Pokazał różne narzędzia do analizy kodu oraz zaprezentował gdzie należy w pierwszej kolejności szukać problemów z kodem.

Ogólnie cała konferencja, przebiegła bardzo fajnie i w miłej atmosferze. Firma ABB przy wejściu rozdała mazaki oraz koszulki, które z tyłu miały miejsce na ‚notatki’ od innych uczestników. Bardzo fajna integracja i miło spędzony czas w gronie geeków. Teraz mogę stwierdzić, że 24h bez snu były tego warte.

INotifyPropertyChanged bez wpisywania nazwy właściwości.

Każdy, kto choć przez chwilę miał przyjemność pisać jakąś aplikacje w .NET używającą bindowania zapewne zna doskonale ten interfejs. Sam spędziłem mnóstwo czasu pisząc w setterach do właściwości OnPropertyChanged(„NazwaWłaściwości”);

Możecie otworzyć szampana, gdyż w .NET Framework 4.5 możemy się pozbyć bezmyślnego kopiowania nazwy właściwości.

Jak było wcześniej?

Wcześniej wywołując event PropertyChanged dla właściwości trzeba było podać jej nazwę.

class SimpleClass : INotifyPropertyChanged
{
    private int _myProperty;
    public int MyProperty {
       get { return _myProperty; }
       set
       {
          _myProperty = value;
          OnPropertyChanged("MyProperty");
       }
    }
 
    public event PropertyChangedEventHandler PropertyChanged;
 
    private void OnPropertyChanged(string propertyName)
    {
       if (PropertyChanged != null)
       {
          PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
       }
    }
}

Jak wiadomo, nie służyło to refactoringowi. Wystarczyło zmienić nazwę właściwości a cały program się sypał i widok nie był odświeżany, gdy powinien.

Jak jest teraz?

Tak jak jednak wspominałem z pomocą przychodzi nam atrybut CallerMemberName, który jak możemy się domyślić zwraca nam nazwę właściwości/metody, która wywołała metodę.
Jak go użyć? Dodajemy ten atrybut przed deklaracją parametru do funkcji OnPropertyChanged oraz ustawiamy parametrowi wartość domyślną (null). Dzięki temu możemy wywołać funkcję OnPropertyChanged bez żadnych parametrów, a kompilator sam będzie wiedział co go wywołało.

class SimpleClass : INotifyPropertyChanged
{
   private int _myProperty;
   public int MyProperty {
      get { return _myProperty; }
      set
      {
         _myProperty = value;
         OnPropertyChanged();
      }
   }
 
   public event PropertyChangedEventHandler PropertyChanged;
 
   private void OnPropertyChanged([CallerMemberName]string propertyName = null)
   {
      if (PropertyChanged != null)
      {
         PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
      }
   }
}