DevDay 2014 - relacja - dzień drugi (26.09.2014)

Dzień drugi to już właściwa konferencja. Pomijając występ początkowy oraz końcowy, przez większość dnia możliwe było wybranie jednego z dwóch wykładów, więc moja recenzja z założenia nie będzie obejmowała wszystkich dostępnych wykładów. Na szczęście, podczas sesji na salach dostępne były kamery wideo, więc w przyszłości możemy spodziewać się nagrać z sesji i nadrobić zaległości na youtubie lub innym vimeo.

Wychodząc z każdej z sesji, uczestnicy mogli wrzucić do koszyka kartkę jednego z trzech kolorów (zielony, żółty, czerwony) i w ten spos. ocenić prezentację

Dan North - Jackstones, a journey to Mastery.
No cóż. Ten wykład widziałem już wcześniej w internecie, jako zapis z którejś z poprzednich konferencji. Ogólnie wykład ciekawy i warty obejrzenia, jednak tak jak z każdym odgrzewanym kotletem, za każdym kolejnym razem smakuje nieco mniej. Jak ktoś jeszcze nie widział, to warte obejrzenia.
Kartka: zielona, bo mimo wszystko jednak warto tą prezentację obejrzeć.

Nial Merrigan - Defensive Programming 101 v5 - Common Security Mistakes in Web Applications
Bezpieczeństwo to jedna z tych rzeczy, na które warto zwracać uwagę, więc chętnie się na ten wykład wybrałem. Nial pokazał 10 najczęściej popełnianych błędów bezpieczeństwa. Zdecydowana większość była mi znana już wcześniej, ale takie perełki jak np. możliwość wyszukania plików web.config przez google, albo fakt, że iPhony nie walidują sieci wi-fi i łączą się ze wszystkim jak popadnie (np. jedziemy na lotnisko, zczytujemy nazwy darmowych sieci wifi, jedziemy w inne miejsce, tworzymy sieci wifi o takich samych nazwach i polujemy na jeleni metodą na "men in the middle" nie wiedziałem). Generalnie fajna sesja, na której zdecydowanie warto było być.
Kartka: zielona (zdecydowanie zasłużenie)

Qi - Hacking the mind: How Art can help us talk (and teach) technology
Po nazwie spodziewałem się sporo. Myślałem, że zostaną przedstawione jakieś fajne sposoby uczenia się. Po prowadzącym też spodziewałem się sporo. W końcu myślałem, że będzie albo coś o hakerstwie, albo o technikach uczenia. Niestety sporo się zawiodłem. Sesja była mdła, nieco zbyt nudna i bez pomysłu. Niby autor coś chciał nam przekazać np. pokazując fragment gazety mówił, że wiadomość ma być krótka i zwięzła przy czym... strasznie usypiał nas całą prezentacją, która zresztą trwała więcej niż było na nią przeznaczone. Generalnie, przez większość czasu się wynudziłem. Całą prezentację "uratowała" końcówka, dosłownie ost. 5 min. Czy było warto? Hmmm, ja tam się wynudziłem i generalnie żałowałem, że nie wybrałem się na konkurencyjną sesję.
Kartka: żółta (gdyby zakończył "o czasie", czyli bez ost. 5-7 min., z całą pewnością była by czerwona).

Rob Ashton - React + NPM for Great Good
Nie ma co ukrywać, na ten występ poszedłem specjalnie dla Roba. Temat jego wystąpienia był rzeczą względną. Był Rob i miało być fajnie. I w sumie tak też było. Rob pokazywał na scenie swoją żywiołowość oraz umiejętności posługiwania się VIM'em, opowiadając o kolejnym super-duper javoscriptowym frameworku przy okazji nabijając się z Angular.JS. Sam temat prezentacji wyglądał na taki niezbyt skomplikowany tutorial, Rob mówił bardzo żywiołowo i.. szybko. Tak szybko, że czasami nawet za szybko i momentami miałem problemy ze zrozumieniem o czym mówi. O ile do samej prezentacji można się było przyczepić, o tyle żywiołowa forma prezentacji była jakże miłą odmianą po usypiającej sesji Qi.
Kartka: zielona, głównie za sympatię do prowadzącego (i żywiołowość wystąpienia).

Kasia Mrowca - Art of Saying NO
Kolejny wykład, po którym spodziewałem się dowiedzieć czegoś ciekawego i... na którym się srodze zawiodłem. Może i Kasia się przygotowała, ale... mówiła dużo ogólników, mało konkretów. O ile na normalnej konferencji na jakiejś grupie .NET pewnie by to było ok, ale... na DevDay jednak publika jest nieco inna. Tutaj przyjechali sami entuzjaści, którzy "samorozwój" katują w praktyce na lewo i prawo od iluś tam lat. Osobiście byłem zawiedziony tym wystąpieniem i zdecydowanie spodziewałem się czegoś lepszego.
Karta: żółta (choć zastanawiałem się nad czerwoną).

Paul Stack - What is DevOps and How It Can Help My Bussiness Succeed?
Mimo iż stwierdzenie "DevOps" od dawna krąży w środowisku, to osobiście nie wiedziałem o co w tym chodzi, więc postanowiłem się dowiedzieć. I myślę, że moje oczekiwania zostały spełnione. Podczas prezentacji dowiedziałem się, że termin ten odnosi się do "Dev" (programistów), którzy równocześnie są też "Ops" (Administratorzy/Sieciowcy wdrażający ich rozwiązania w korpo). Tyle w teorii, jednak w praktyce, nie ma takiego stanowiska jak "devops", a sam termin "devops" to raczej kwestia kultury przedsiębiorstwa i panujących tam stosunków między różnymi specjalizacjami (płynne przechodzenie z admina w deva i na odwrót). Resztę prezentacji Paul pokazywał narzędzie do badania ruchu sieciowego opartego na logach linuxa oraz jak poprzez analizę tych logów sprawdzać, czy "jest jeszcze jest ok, czy już nie jest ok".
Kartka: zielona (całkiem przyjemna sesja).

Simon Brown - Software Architecture vs Code
Autor w założeniu starał się pokazać, że światy architektów i ich UML oraz programistów i ich "kodu" są wspólne i da się je połączyć, przy okazji starając się uzmysłowić kontekst i potrzebę samodoskonalenia poprzez analogię z łódką i łowieniem ryb, a... wyszło nie do końca wiadomo co. Jak tak sobie to teraz przypomnę, to w gruncie rzeczy trudno jest mi sobie uzmysłowić, co pozytywnego wyniosłem z tej sesji? To że samo przeczytanie książki o łowieniu ryb nic nam nie da, bo jeszcze trzeba zawartą tam wiedzę dostosować do otaczających nas warunków? Hmmm? Chyba to jednak nieco za mało jak na taką konferencję.
Kartka: zielona (bo było nieco śmiesznie, choć obecnie dałbym nieco gorszą ocenę). 

Po ost. sesji, nastał "beer time", czyli dalsze debaty. Najpierw na korytarzach uczelnii medycznej, na której odbywała się konferencja, a nast. w wynajętej knajpie.

Podsumowanie: Konferencja jak najbardziej na plus. Warsztaty z Danem były na całkiem fajnym poziomie (kilka nowych, inspirujących rzeczy), wykłady podczas konferencji ok (ale raczej takie sobie), organizacja na najwyższym możłiwym poziomie (wszystko blisko, koło siebie, dobra sala itp), spotkanie Krakowskiej grupy .NET (fajny dodatek) i możliwość spotkania się i pogadania z mnóstwem innych pasjonatów (najfajniejsza część konferencji). Fajnie było, chyba głównie z uwagi, na możliwość wyjścia ze swojej "jaskini" i spotkania innych, podobnych do siebie "geeków", których okazało się być zdecydowanie więcej niż się spodziewałem ;).
Fajnie było i do zobaczenia w przyszłości :)

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.

Generowanie PDF z wykorzystaniem Nancy, Pechkin, wkhtmltopdf

Jednym z zadań, jakie dostałem było wygenerowanie raportu, który równocześnie miał się wyświetlać jako html, jak i pdf. Moją pierwszą myślą, było stworzenie tego raportu jako www, a nast. zamiana tego www w pdf. Dodatkowo, chciałem dać użytkownikowi, aby sam wybrał, czy rezultat raportu chce otrzymać jako html, czy jako pdf. Jako web frameworku wykorzystałem nancyfx.

Jako bibliotekę, która zamienia html na pdf, wykorzystałem darmową bibliotekę, dostarczoną przez google, czyli wkhtmltopdf. Ta biblioteka jest dużo lepsza, od konkurencyjnej itextsharp ponieważ itextsharp na chwilę obecną nie radzi sobie z bardziej skomplikowanymi html'ami (w moim przypadku był to brak chart'ów o których wspomniałem w moim poprzednim wpisie).

Aby korzystać płynnie z wkhtmltopdf w .NET, skorzystałem z darmowej biblioteki Pechkin (link do githuba). Przykład wykorzystania pechkin'a z wkhtmltopdf można znaleźć na githubie ale również np. na blogu Ulises Reyes.
Ulises po za kilkoma przykładami użycia, informuje nas również o kilku ważnych aspektach korzystania z Pechkina:

• It's trivial, here are some gotchas though:

• GIF Images are not supported

• Paths to images must be fully qualified as URLs (http://example.com/a/b/image.jpg) or file URIs (file://host/path)

• Resources over HTTPS cannot be fetched through URLs. You can get around this by specifying the path as a file URIs.

• References CSS files are supported, I found it easier to write inline CSS (classes in the same document enclosed in a style tag)

Ok. Mamy bibliotekę (napisaną w C), do zamiany html'a w pdf. Mamy adapter, aby wykorzystać tą bibliotekę w .NET. Brakuje nam jeszcze odpowiedniego kodu, aby wykorzystać to w naszej ukochanej Nancy. Na szczęście, natknąłem się na podobny wpis na blogu Shane Mitchell link. Tam wprawdzie była wykorzystywana inna biblioteka, ale nic nie stało na przeszkodzie, aby wszystko połączyć w jedną całość i utworzyć klasę, generującą odpowiedni widok:

using Nancy;
using Nancy.Responses;
using Nancy.ViewEngines;
using Pechkin;
using Pechkin.Synchronized;
using System.Drawing.Printing;
using System.IO;

namespace Nancy.MVC
{
    public static class ResponseAsPDF
    {
        public static Response RenderToPdfPechkin(NancyModule module, string viewName, dynamic model)
        {
            string content = GetPageContent(module, viewName, model);
            SynchronizedPechkin sc = new SynchronizedPechkin(new GlobalConfig().SetMargins(new Margins(0, 0, 0, 0))
                .SetDocumentTitle("Ololo").SetCopyCount(1).SetImageQuality(100)
                .SetLosslessCompression(true).SetMaxImageDpi(-1).SetOutlineGeneration(true).SetOutputDpi(-1).SetPaperOrientation(true)
                .SetPaperSize(PaperKind.Letter));
         
            byte[] pdfBuf = sc.Convert(new ObjectConfig().SetLoadImages(true)
            .SetPrintBackground(true)
            .SetAllowLocalContent(true)
            .SetScreenMediaType(true)
            .SetRunJavascript(true)
            .SetCreateExternalLinks(true), content);
         
            return new StreamResponse(() =>
            {
                var pdfOutput = new MemoryStream(pdfBuf);
                pdfOutput.Seek(0, SeekOrigin.Begin);
                return pdfOutput;
            }, "application/pdf");
        }
        private static string GetPageContent(NancyModule module, string viewName, dynamic model)
        {
            ViewLocationContext viewLocationContext = new ViewLocationContext()
            {
                Context = module.Context,
                ModuleName = module.GetType().Name,
                ModulePath = module.ModulePath
            };
            var rendered = module.ViewFactory.RenderView(viewName, model, viewLocationContext);
            var content = "";
            using (var ms = new MemoryStream())
            {
                rendered.Contents.Invoke(ms);
                ms.Seek(0, SeekOrigin.Begin);
                using (TextReader reader = new StreamReader(ms))
                {
                    content = reader.ReadToEnd();
                }
            };
            return content;
        }
    }
}

Google Charts w ASP.MVC (Razor)

Do rysowania wykresów za pośrednictwem ASP.MVC postanowiłem użyć darmowej biblioteki dostarczonej przez google, czyli chart. Wykresy rysuje się w tym w sposób bardzo prosty i przyjemny, tj. za pomocą javascriptu. Przykłady są dobrze opisane, oraz zawierają odnośnik do jsfiddle.
Całość sprowadza się, do odniesienia się do wgrania zew. biblioteki rys.

<script type="text/javascript" src="https://www.google.com/jsapi?autoload={'modules':[{'name':'visualization','version':'1','packages':['corechart']}]}"></script>

wybrania miejsca, w którym ma się ten wykres narysować:

     <div id="piechart" style="width: 900px; height: 500px;"></div>

stworzenia metody rysującej oraz "podpięcie" jej pod delegata:

      google.setOnLoadCallback(drawChart);
      function drawChart() {
        var data = google.visualization.arrayToDataTable([
          ['Task', 'Hours per Day'],
          ['Work',     11],
          ['Eat',      2],
          ['Commute',  2],
          ['Watch TV', 2],
          ['Sleep',    7]
        ]);
        var options = {
          title: 'My Daily Activities'
        };
        var chart = new google.visualization.PieChart(document.getElementById('piechart'));
        chart.draw(data, options);
      }

Ok.Mamy javascript, mamy jsfiddle, na którym możemy przetestować nasz odpowiednik wykresu, a nawet kilka wykresów pod sobą. A co jeżeli jako źródło danych, chcieli byśmy wykorzystać model z naszego ASP.MVC ??

Na szczęście istnieje znacznik (tag) <text>  </text> który możemy wykorzystać.
Poniżej przykład takiej metody:

        function drawCurrency() {
            @if (Model.Tasks != null && Model.Tasks.Count > 0)
            {
                <text>
                var data = google.visualization.arrayToDataTable([
                ['Task', 'Hours per Day'],
                @foreach (var task in @Model.Tasks)
                {
                    <text>
                    ['@task.name', parseFloat('@task.hour')],
                    </text>
                }
                ]);
                var chart = new google.visualization.PieChart(document.getElementById('piechart'));
                chart.draw(data, options);
                </text>
            }
        }