Recenzja - "Adaptive Code via C# - Agile coding with design patterns and SOLID principles" -> Gary McLead Hall

Na tą książkę zwróciłem uwagę, dzięki pytaniu K.Cebuli na naszej grupie na portalu www.facebook.com. To był chyba grudzień 2014r. i akurat amazon.com miał promocję na tą książkę. Recenzje miała dobre, wydawcę również (Microsoft), a tytuł brzmiał zachęcająco. Kupiłem więc tą książkę w formie ebooka, załadowałem na mojego kindla i w wolnym czasie ją sobie "trawiłem".

Cóż mogę napisać o samej książce?
Pierwszy rozdział, to głównie Agile oraz szczegółowe omówienie metodologii SCRUM. Przy okazji wspomniane jest też jak ważną rolę odgrywają w "zwinnym podejściu" takie elementy jak zależności, interfejsy oraz testy jednostkowe. 

W tym rozdziale autor opisał też, dlaczego powinniśmy unikać pewnych elementów języka, takich jak m.in. extension method czy używanie słówka "new". 
Porównał to do używania korzystania z dżwigu (skyhook) oraz windy (lift). Obie mogą posłużyć do wejścia na dach budynku, jednak windy są dużo bezpieczniejsze i dużo lepiej sprawdzają się "długoterminowo".

Drugi rozdział, to szczegółowe omówienie zasad SOLID. Tutaj autorowi należą się dodatkowe podziękowania, z uwagi na bardzo dobre tłumaczenie tematu oraz wplecenie w te rozdziały wzorców projektowych. Autor wspomniał o GoF, o tym, że przez lata pewne wzorce stały się kanonem, a inne antywzorcami i... wszystko demonstruje na przykładach. Bardzo dobra robota.

Trzeci rozdział, to próba połączenia dwóch pierwszych rozdziałów na przykładzie niewielkiego zespołu oraz przykładowego zadania. Mamy tutaj rozmowy projektowe, szacowanie kosztów oraz... samo kodowanie ;-)

Napisałem po krótce, o czym jest ta książka, ale... teraz najważniejsze pytanie. Czy warto? Osobiście uważam że tak. Uważam, że ta książka jest bardzo dobra, zarówno pod względem technicznym, jak i samego sposobu jej napisania. Uważam również, że każdy szanujący się developer powinien ja przeczytać (a przynajmniej prawie cały 1 i cały drugi rozdział). Dodatkowo uważam, że książka GoF jest już na tyle stara i ciężko napisana (trudno się ją czyta), że... powinna odejść do lamusa i to właśnie "Adaptive Code via C# - Agile coding with design patterns and SOLID principles" powinna zająć jej miejsce.

DevDay 2014 - relacja - dzień pierwszy (25.09.2014)

Za nami najpopularniejsza, a przynajmniej najbardziej oczekiwana konferencja związana ze środowiskiem programistów .NET w 2014 roku, czyli Devday 2014.

Organizowana przez ABB konferencja była od dawna oczekiwana w środowisku, a problemy z dostaniem wejściówki tylko to potwierdziły. Pierwsza tura darmowych biletów rozeszła się w 5 min, druga w 2 min., więc postanowiłem nie czekać i wykupiłem płatne warsztaty, dzięki czemu bilet na bądź co bądź darmową konferencję dostałem gratis.

W związku z powyższym pozwoliłem pokusić się o małą recenzję tego, bądź co bądź bardzo wyczekiwanego eventu.

Dzień 1, 25.09.2014 (czwartek)
W czwartek odbyły się dwa szkolenia. Jedno z Angular.Js z Tiberu Covaci, oraz drugie  "Accelerated Agile: from months to minute" z Dan'em North. Ja wybrałem się na szkolenie z Agile ponieważ zarówno temat jak i prowadzący wydawali mi się bardziej interesujący. Inna sprawa, iż uważam, że angulara dużo lepiej i taniej można się nauczyć z jakiś książek/tutoriali niż z jednodniowego szkolenia.

Szkolenie składało się z 5 części tematycznych, trwających 50-70 min. każda z przerwami na kawę, toaletę oraz obiad. Podczas szkolenia byliśmy podzieleni na 7 sześcioosobowych zespołów, wewnątrz których mieliśmy wykonywać mniej lub bardziej skomplikowane zadania w stosunkowo krótkich okresach czasu (2-3 min.). Idea była prosta -> jest x ludzi w zespole i bardzo ograniczony czas, a trzeba dojść do konsensusu i wystosować wspólne stanowisko grupy wobec podanego tematu. A tematy? Różne, od tego, jak ma się nazywać zespół, na czym ma się skupić prowadzący podczas zajęć, po różne elementy cyklu wytwarzania oprogramowania. Szkolenie odbywało się więc w formie mniej lub bardziej luźniej zabawy, za to z elementem "tykającego zegarka".

Ok. A gdzie w tym to całe "mięcho", po które przyszliśmy? Hmmm, pierwsze sesje były raczej takie "zapoznawcze" oraz mniej lub bardziej ogólnikowe np. tworzenie oprogramowania składa się z 3 faz: 
- badawcza (testujemy technologię, narzędzia, koncepcję itp.)
- działającego prototypu (jesteśmy w stanie pokazać klientowi coś co działa mniej lub bardziej zgodnie z założeniami)
- odtwarzalnej produkcji na masową skalę (cykl zmniejszania kosztów i zwiększania zysków, czyli ktoś inny może odtworzyć naszą pracę mniejszym nakładem sił)

Była też cała sesja poświęcona tworzeniom wersji "spike" oraz "prod". Znałem wcześniej pojęcie PoF, ale nie znałem pojęcia spike
Jedak największe wrażenie na mnie wywarły 2 ostatnie sesje. 

Pierwsza z nich, związana z ryzykiem utrzymywania aplikacji i związanymi z nią testami, próbowała odpowiedzieć na pytanie, czy "pokrycie kodu testami" to najlepszy sposób mierzenia oprogramowania? Zdaniem prowadzącego niekoniecznie. Zamiast bawić się w automat, powinniśmy rozdzielić naszą funkcjonalność, pod względem "skomplikowania" oraz "konsekwencji wystąpienia błędu (jak bardzo nas to zaboli)" w odniesieniu do "kontekstu" w jakim działamy (kontekst zazwyczaj zna tylko "biznes"). Idea, którą starał nam się przekazać Dan, polegała na tym, że nie każda część syst. musi być równo przetestowana (np. unit testami). Że czas, który poświęcili byśmy na pisanie testów dla mało znaczącego i stosunkowo prostego elementu, dużo lepiej jest spożytkować na dodatkowe testy tam, gdzie jak coś się wywali to nas (i nasz biznes) mocno zaboli. Dan wspomniał też, że zazwyczaj jak trafimy na element, który jest zarówno bardzo skomplikowany jak i bardzo istotny biznesowo, to... najczęściej da się go rozdzielić na kilka mniejszych elementów i... choćby testowanie jest wtedy łatwiejsze.

Druga, sesja, która mi się bardzo podobała, to była sesja związana z wycenianiem czasu trwania projektów. Coś, z czym często programiści mają problem. Jak się okazało, z ok ~40 os. na sali, tylko 4-5 czuły się w tym w miarę mocne. Dan podszedł do tematu nieco inaczej. Nie pokazywał nam jakiś "magicznych" metodologii przepowiadania przyszłości, a posłużył się metaforą przewidywania pogody. O ile w przypadku prognoz pogody, mamy do czynienia z 4 zmiennymi i... nikt nie wymaga od prognoz specjalnej dokładności, o tyle w przypadku tworzenia oprogramowania tych zmiennych jest znacznie więcej (często od 8 w górę), a... wszyscy wymagają od nas dokładnego przewidywania, nawet na kilka mieś. do przodu.
Zamiast tradycyjnego wróżenia z fusów nt. pracochłonności, Dan zaproponował odwrócenie procesu, tzn. biznes powinien się zadeklarować, ile jest w stanie na dany projekt wydać oraz ile planuje na nim zarobić. Podając pewne widełki, np. 50-150 tyś. dolarów, można przyjąć pewien okres prac programistycznych, np. 3-9 mieś., i na tej podstawie prognozować, czy skończenie projektu jest prawdopodobne. Nast. wraz z upływem czasu i wzrostem wydanych kosztów, śledzić na bieżąco i doprecyzowywać szacowanie np. po wydaniu 40 tyś. dol. spróbować oszacować, czy już mamy połowę, czy dopiero 1/3. I później, wraz z biegiem czasu i coraz lepszym poznawaniem tematu prognozować, czy dany projekt w ogóle ma sens.
Może i nie jest to super opis tego, o czym mówił Dan, ale jest to mniej więcej pogląd na wycenianie, jaki warto jest zacząć rozważać, skoro wcześniejsze próby wyceniania zwyczajnie się nie sprawdzają.

Ogólnie warsztaty z Danem były całkiem miłe i przyjemne. Gdybym miał je ocenić to? Hmmm, z całą pewnością były inspirujące i coś z nich wyniosłem, a pewne przemyślenia będę się starał włączyć do rzeczywistych projektów. Czego zabrakło? Z całą pewnością narzędzi, SCRUM-u, i innych "sformalizowanych" specyfik. Ale czy na pewno zabrakło? Hmmm.
A ocena? Pocz. myślałem o 7/10, ale obecnie, po powrocie do domu bardziej skłaniał bym się do 8/10.

Po warsztatach, poszedłem wziąć prysznic i nieco odpocząć, ponieważ tego samego dnia swoje spotkanie miała również Krakowska grupa .NET.

Do siedziby ABB dotarłem tuż przed rozpoczęciem prelekcji przez Maćka Aniserowicza i nie żałuję, bo wcześniejszą prezentację Michała o F# miałem okazję już wcześniej zobaczyć na spotkaniu Warszawskiej grupy .NET.
Maciek mówił o Dependency Injection i jak ktoś czyta jego bloga to w sumie niczego zaskakującego się podczas tej prezentacji nie dowiedział, za to to, co było miłe podczas tego spotkania, to ilość ludzi, jaka się zebrała (były problemy z miejscami stojącymi na sali), a także darmowe piwo i pizza (na koszt tretton37) podczas spotkania o losowaniu licencji na R# nie wspomnę ;)

Po spotkaniu większość devów udała się na miasto w celu dalszej dyskusji mniej lub bardziej palących nas spraw. Fajnie było znowu pobyć w wśród większej ilości, często bardziej doświadczonych devów i powymieniać się własnymi, często jakże różnymi doświadczeniami.

Szkolenie Comarch - Programowanie .NET 4.0 - kurs zaawansowany

W dniach od 05.02.2014 do 07.02.2014 (3 dni) miałem przyjemność wziąć udział w szkoleniu, zorganizowanym przez firmę Comarch nt. ' Programowanie .NET 4.0 - kurs zaawansowany'.

Szkolenie przeprowadził Marcin Najder (techblog), ale zanim przejdę do konkretów najpierw kilka spraw "formalnych". Szkolenie odbyło się w Warszawskiej siedzibie firmy, przy ul. Leśna 2 (przecznica ul. Puławskiej 525), czyli... na Ursynowie, przy ul. Puławskiej, drugie światła od zjazdu z południowej obwodnicy Warszawy, czyli... bardzo dobra lokalizacja dla zmotoryzowanych (w okoliczny jest gdzie zaparkować).

Co do oferty szkoleniowej, to można ją przejrzeć tutaj, natomiast szczegóły szkolenia, na którym ja byłem, można obejrzeć tutaj. Pod każdym szczegółowym opisem szkolenia jest niebieski przycisk "Terminarz i Rejestracja", więc jeżeli ktoś jest zainteresowany, to wiadomo co i jak.

Jeżeli chodzi o samo szkolenie, to nie będę ukrywał, że cena 3 dniowego szkolenia, była jak na Warszawę bardzo konkurencyjna  (w promocji, 1400zł + VAT).

A jak wyglądało samo szkolenie?
    Należy zacząć od tego, że sam prowadzący, to bardzo sympatyczny, a przy tym doświadczony programista. Prawdziwy pasjonat w swoim fachu, fan zarówno języków funkcyjnych jak i obiektowych i to m.in. próbował nam przekazać podczas szkolenia. Ponieważ w naszej 7 os. grupie, były os. o bardzo zróżnicowanym doświadczeniu programistycznym, Marcin musiał się nieco wysilić, szczególnie że był niemal przez cały czas pod porządnym gradobiciem pytań.
     Były więc os. zaraz po studiach (i kursie podstawowym), które prosiły o więcej wyjaśnień związanych z lambdami, delegatami itp., jak i doświadczony programista PHP pragnący spróbować swoich sił w .NET, jak i 2-3 bardziej doświadczonych programistów, pytających co chwila o bardziej zaawansowane tematy oraz różnego rodzaju "wątki poboczne".
     Na wszystkie te tematy, prowadzący odpowiadał spokojnie i rzeczowo. W efekcie, w trakcie kursu, przerobiliśmy też fragment "kursu podstawowego", to co było w agendzie związane z zaawansowanymi aspektami programowania w .NET (linq, lambdy, refleksja, więcej lambd, T4, wzorce projektowe, programowanie współbieżne, jeszcze więcej lambd itp. ;)), ale również tematy okołoprogramistyczne, takie jak np. rozproszone kontrole wersji (github, bitbucket), "NoSQL" (MongoDb, RavenDb), JSON, frameworki javascriptowe (Angular.JS, Node.JS). Wspomniany został nawet ServiceStack (niestety aktualnie płatny) Jeżeli doliczymy do tego ćwiczenia praktyczne z wykorzystaniem nUnit oraz Resharpera, oraz rozmowy programistyczne oraz  około programistyczne, czy w czasie kursu, czy też w czasie wspólnego posiłku to daje nam naprawdę intensywnie spędzone 3 dni..
     Wprawdzie to nie Ja płaciłem za szkolenie(firma płaciła), ale uważam, że naprawdę warto było pójść na to szkolenie. Fajnie jest przebywać w towarzystwie inteligęnych (i nierzadko mądrzejszych) ludzi od siebie i tak "na spokojnie" się czegoś nowego dowiedzieć/nauczyć. Taki miłe urozmaicenie w stosunku do samotnego przerabiania tutoriali / dokumentacji / oglądania podcastów w domu ;)

Z tego co Marcin mówił, to obok pracy na etacie, prowadzi również szkolenia ASP.MVC, programowanie reaktywne, jak i kurs podstawowy. Inna sprawa, że kurs podstawowy, czasami prowadzi też inna zupełnie inna osoba.

To tyle. Gdyby ktoś kiedyś miał okazję udać się na takie szkolenie, to szczerze polecam. Fajnie było :)

Testowanie ConfigurationManager (xUnit, FakeItEasy)

Tworząc testy jednostkowe ważne jest, aby testy działały bardzo szybko, oraz niezależnie od zewnętrznych zasobów, takich jak np. web service, dostęp do plików itp. Mówi o tym, m.in. Roy Osherove podczas swoich szkoleń, np. Understanding Test Driven Development

Jednym z takich zewnętrznych zasobów dla aplikacji internetowych, jest plik konfiguracyjny web.config. Przykładowy sposób, jak skutecznie zastosować DI oraz testy jednostkowe dla tego rozwiązania pokazuje na swoim blogu KAZI MANZUR RASHID. Niestety dla mnie, Kazi pokazuje to z wykorzystaniem "Mock", natomiast Ja, pod wpływem postów Macieja Aniserowicza jako narzędzie 'mockujące' postanowiłem wykorzystywać FakeItEasy.  Poniżej prezentuję działające rozwiązanie wykorzystujące bibliotekę FakeItEasy.

Ponieważ zmieniam tylko bibliotekę 'Mock' na "FakeItEasy' to podstawowe klasy, pozostały takie same, jak w kodzie Kazi Manur'a

    public interface IConfigurationManager
    {
        NameValueCollection AppSettings
        {
            get;
        }
        string ConnectionStrings(string name);
        T GetSection<T>(string sectionName);
    }
    public class ConfigurationManagerWrapper : IConfigurationManager
    {
        public NameValueCollection AppSettings
        {
            get
            {
                return ConfigurationManager.AppSettings;
            }
        }
        public string ConnectionStrings(string name)
        {
            return ConfigurationManager.ConnectionStrings[name].ConnectionString;
        }
        public T GetSection<T>(string sectionName)
        {
            return (T)ConfigurationManager.GetSection(sectionName);
        }
    }

Aby pokazać bardziej realistyczny przykład użycia, utworzyłem klasę BL (Business Logic), która do swojej pracy wykorzystuje dane, pobrane z web.config. Założyłem również, że plik web.config posiada wpis o nazwie customAppSetting z wartością "test".

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
public class BL
{
    private readonly IConfigurationManager configuration;
public BL()
{
        this.configuration = new ConfigurationManagerWrapper();
}
    public BL(IConfigurationManager configuration)
    {
        this.configuration = configuration;
    }
    public string GetAppSetting(string customAppSettingName)
    {
        string customAppSetting = configuration.AppSettings[customAppSettingName];
        //TODO: some business logic
        return customAppSetting;
    }
}

Praktyczne wykorzystanie klasy BL przez solucję produkcyjną:

    private void ProductionWebConfig()
    {
        BL businessLogic = new BL(new ConfigurationManagerWrapper());
        string customAppSetting = businessLogic.GetAppSetting("customAppSetting");
    }

Praktyczne wykorzystanie klasy BL przez bibliotekę testującą:

    [Fact]
    public void GetAppSetting_PositiveString_StringTest()
    {
        var customAppSetting = new NameValueCollection { { "customAppSetting", "test" } };
        IConfigurationManager fakeConfiguration = A.Fake<IConfigurationManager>();
        A.CallTo(() => fakeConfiguration.AppSettings).Returns(customAppSetting);
        BL bl = new BL(fakeConfiguration);
        string fakeString = bl.GetAppSetting("customAppSetting");
        string realString = "test";
        Assert.Equal(fakeString, realString);
    }