Programowanie funkcyjne z wykorzystaniem języka F#

Pierwszy raz styczność z językiem F# miałem około półtora roku temu, kiedy to Michał Łusiak zaprezentował nam ten język podczas spotkania WG.NET. To był mój pierwszy kontakt z tym językiem. Pewne elementy wydawały się być całkiem fajne, inne nieco dziwne, ale ogólne wrażenie nt. tego języka jakie odniosłem po tej prezentacji było takie, że Microsoft traktuje ten język jako swego rodzaju "piaskownicę" oraz "miejsce treningowe" podczas wprowadzania rozszerzeń do języka C#. Że to jednak C# ma pozostać głównym językiem, bądź co bądź korporacyjnej platformy, natomiast F# to ma być takie laboratorium stworzone dla tzw. "szalonych naukowców" oraz innych eksperymentatorów, którzy będą tworzyć nowe rozszerzenia języka oraz platformy. Jeżeli stworzą coś nowego i uda im się to skompilować do MSIL, a przy okazji nic nie wybuchnie, to wtedy wszelkie nowości będzie można zaadaptować do C#.

W międzyczasie, możliwe że nawet wcześniej, podczas jednego ze szkoleń nt. C# prowadzonego przez Comarch, autor szkolenia wyjawił, że osobiście jest fanem języków funkcyjnych, oraz że obecnie, bardzo dużo, albo niemal wszystko co znamy z języków funkcyjnych da się zrobić w Linq, tyle tylko, że zapis jest wtedy nieco dłuższy i bardziej pokręcony.

Wracając jednak do właściwego F#, kolejnym takim momentem, przemawiającym na jego korzyść był fakt, iż podczas konferencji Wroc# 2015 ten język, obok Angular.JS dostał jedną z sesji prezentacyjnych (wszystkich sesji było 6). To oznaczało, że coś się dzieje.

Prawdziwym przełomem w moim postrzeganiu tego języka, była jednak konferencja devday 2015, podczas której nie tylko były sesje z jezyka F#, a na korytarzach można było osobiście porozmawiać z samym Tomasem Petrickiem, który nomenomen zrobił z jednego z niewielu dostepnych stolików swoisty "F# Corner" ;-) Prawdziwym przełomowym momentem, to był fragment prezentacji Chada Fawlera, która stanowiła keynote tej konferencji:

Chad mówi tam m.in., aby w obecnych czasach zainteresować się 3 tematami:
- linux (z którego aktualnie tworze tego posta)
- mobile development (jesienią tego roku przerobiłem kurs na courserze z programowania na platformę Android)
- programowanie funkcyjne, o którym tutaj właśnie się rozpisuje.

Więc czym tak naprawdę jest język F# i jak się do niego zabrałem?
F# jest to język o funkcyjnym paradygmacie programowania, w odróżnieniu np. od C#, Javy, Pythona lub C++, które są językami o obiektowym paradygmacie programowania. F# jest też integralnym językiem platformy .NET, co oznacza, że jego kod źródłowy kompilowany jest do języka MSIL, a dopiero później przerabiany na kod maszynowy. Język ten ma też kilka innych ciekawostek, które postaram się wylistować:

• język funkcyjny (funkcyjny paradygmat programowania)
• język kodu pośredniego platformy .NET
• dopuszcza mix z kodem źródłowym innego języka .NET (przez co dopuszczalne jest korzystanie z bibliotek standardowych platformy .NET lub tworzenie projketów będących swoistymi mieszańcami C# oraz F#).
• brak dynamicznego mapowania typów, co czasami bywa irytujące
• wszystkie zmienne z definicji są stałe i niezmienne, ale możliwe jest tworzenie klasycznych zmiennych (poprzed dodanie słowa kluczowego "mutable"). Ma to na celu tworzenie ułatwienie rozwiązań pracujących w trybie zrównoleglonym (wielowątkowym)
• "model aktorów", zwany tutaj "mailbox agent", znany m.in. z biblioteki "Akka" oraz "Akka.net" jest tutaj wbudowany jako naturalny element składowy jezyka 
• open source - język jest w pełni otwarty i oficjalnie tworzony przez społeczność, choć część jego twórców dostaje za pracę nad projektem wypłatę z Microsoftu
• hierarchia plików w solucji ma znaczenie (w odróżnieniu np. od C#, gdzie nie ma to znaczenia)

To co wypunktowałem, to są główne, charakterystyczne cechy tego języka, ale co one oznaczają w praktyce? Czym np. jest ten funkcyjny paradygmat programowania?
Funkcyjny paradygmat programowania, to w porównaniu do obiektowego paradygmatu programowania nieco inne spojrzenie na te same problemy.
   W przypadku programowania obiektowego, tworzymy klasy, jako definicję obiektów, w oparciu o które tworzymy obiekty. W tych obiektach "zamykamy" pewne dane, a nast. wykonujemy na nich pewne obiczenia. Mamy więc zbiory obiektów, każdy z nich wewnątrz ma swoje specyficzne dane, na których wykonuje obliczenia, często w sposób mniej lub bardziej tajny (tzw. enkapsulacja), a nast. operujemy na danych wynikowych wychodzących z tych obiektów.
   W przypadku programowania funkcyjnego mamy do czynienia z innym podejściem. Tutaj nie mamy typowych klas przedstawiających obiekty. Mamy za to funkcje, które przyjmują pewne wartości i które zwracają wyniki. Do tego mamy kilka typów kolekcji i... operujemy na danych z tych kolekcji za pomocą tworzonych funkcji. Jeżeli trzeba, to w naszych funkcjach, wykorzystujemy inne funkcje, w których możemy wykorzystywać kolejne funkcje itd. Oczywiście istnieje kilka typów kolekcji, różniących się od siebie właściwościami (np. sekwencje z definicji obsługują "lazy loading", natomiast Sety bazują na drzewie binarnym), jak i kilka typów kluczowych (np. rec sprawiających, że dana funkcja jest funkcją rekurencyjną).

Skąd czerpałem wiedzę?
Postanowiłem połączyć teorię z praktyką czyli:

• Jako teorię czytałem książkę "F# for Quantitative Finance (Johan Astborg)", która ma raczej średnie opinie w necie, ale z uwagi, że wpadła w moje ręce za darmo podczas jednej z promocji na "Pact Publishing" to postanowiłem ja przeczytać i czegoś się z niej nauczyć.
• Jako praktykę, postanowiłem wykonać przynajmniej 10 zadań z Project Euler. Jak mi poszło, można sprawdzić na w odp. projekcie, na moim koncie na githubie.
• Połączenie jednego z drugim, czyli forum stackoverflow

Po tym nieco przydługim wstępnie, teraz czas na to, co tygryski lubią najbardziej, czyli konkluzje, czyli wnioski.

• czytając opis języka w książce myślałem sobie, niby spoko
• do czasu, aż zacząłem to programować samemu, wtedy co rusz napotykałem na dziwne błędy oraz zmuszenie mnie do zmiany sposobu myślenia
• o ile pierwsze zadania z projektu euler były stosunkowo proste (przydała się praktyka w stos. linq oraz przykłady z książki, to im dalej w las tym trudniej)
• sporo problemów i frustracji, szczególnie podczas pracy z pętlami przytrafił mi typ danych unit. Ponieważ jest on bardzo podobny do uint, na początku te typy mi się myliły, szczególnie, że F# nie pozwala na dynamiczną zmianę typów. Tworzyłem więc pętle, które z jakiegoś powodu w którymś momencie zwracały unit (brak wartości), natomiast mi się wydawało, że wraz z którąć iterecją, z nieznanego mi powodu zwracają one typ uint i mam problem z mapowaniem i porównywaniem typów. 
• pętle w F# nie są typowymi "pętlami" tylko "wyrażeniami" lub "wyrażeniami wyższego rzędu", co oznacza, że nie posiadają typowego "break-a". Nie możemy w dowolnym momencie, ot tak sobie wyjść z pętli przerywając jej działanie, tylko musimy ją ładnie "zamknąć", tudzieź pozwolić aby wszystko się wykonało tak jak należy
• sposobem, aby pętle nie trwały nieskończenie wiele, albo nie robiły zbyt dużo "pustych przelotów", jest zastosowanie sekwencji z ich "lazy loading", oraz słowa kluczowego "yield". Bardzo ładnie obrazuje to przykład rozwiązania problemu nr.9 https://github.com/zchpit/ProjectEuler/blob/master/F%23/ProjectEulerInF%23/ProjectEulerInF%23/Problem9.fs
• kod napisany w F# zazwyczaj jest krótszy i bardziej "elegancki" niż w porównaniu do tradycjnej wersji C#
• kod przynajmniej w teorii dużo łatwiej powinno się dać skalować (wielowątkowość)
• choć nie wiem, jak wygląda kwestia jego wydajności względem C#
• Chad Fowler zachęcał do nauki języków funkcyjnych, widząc w tym przyszłość
• jednak ilość obecnych ogłoszeń o pracę na popularnych portalach z pracą (w PL) na chwilę obecną jakoś specjalnie do tego nie zachęca
•  rozmawiając nt. temat z managerem jednej z firm deweloperskich, usłyszałem odp., że na razie to jest raczej nowość i nie ma na rynku zbyt dużo os., więc ewentualna zasępowalność jest niewielka i co za tym idzie na chwilę obecna bardziej ceniona jest dla nich chęć uniknięcia tzw. "Bus factor" niż "innowacyjność".
• z drugiej strony, to natywne wsparcie dla programowania rozproszonego oraz wielowątkowego kusi, oj kusi :D

Reasumując, temat warty uwagi śledzenia. O ile obecnie jest zauważalny "hype" na konferencjach oraz grupach programistycznych, jednak jak na razie nie przekłada się to na ilość ofert pracy dla ludzi umiejących F#. W sumie najbardziej popularnym obecnie jezykiem funkcyjnym jest w polsce Scala, jednak tak naprawdę, ten język to takie "niewiadomo co", a z całą pewnością nie można go nazwać językiem typowo funkcyjnym. Z drugiej strony, od czasu rozpropagowania modelu aktorów do języków obiektowych, częściowo otwarta została pewna "nisza" wykorzystywana wcześniej jedynie przez języki funkcyjne.

Jak to się wszystko potoczy? Myślę, że bardzo dużo zależy od tego, czy będą się pojawiały ogłoszenia o pracę w tym konkretnym języku, zarówno pod względem ich ilości jak i jakości. W każdym bądź razie zamierzam temat bacznie obserwować, przynajmniej jeszcze przez jakiś czas :-)

Konferencja DevDay 2015

W środowisku istnieje dobry zwyczaj, dawania "feedbacku", odnośnie wydarzeń, w których się wzięło udział. Feedback potrzebny jest organizatorom, prelegentom, aby wiedzieć, co ewentualnie poprawić, ale również i osobom postronnym zainteresowanym wybraniem się na podobny event w przyszłym roku, aby wiedzieć, czego mniej więcej można się spodziewać.

W związku z tym, postanowiłem po krótce opisać moje wrażenia z konferencji devday 2015. W tym roku, konferencja była płata, jednak istniała spora pula darmowych, biletów, które można było wygrać w różnych konkursach. Mi udało się wygrać bilet w konkursie organizowanym przez wroc# (i w związku z tym, z własnej inicjatywy pierwszego dnia konferencji chodziłem w "ich" koszulce, robiąc za żywą reklamę ;-)).

Konferenacja, jak zwykle bardzo udana. Konferencja twała 2 dni i podobnie jak rok temu, odbyła się w centrum dydaktycznym wydziału medycznego Uniwersytety Jagielońskiego. Większość prezentacji odbywało się w dwóch salach obok siebie, które dla spotkań otwierających oraz zamykających każdego dnia były łączone w jedną dużą salę wykładową. Z tego co wspominali organizatorzy, wszystkie sesje były nagrywane, więc jak ktoś przegapił coś interesującego, to w przyszłości będzie mógł sobie obejrzeć interesujące go sesje na youtubie.

Pod względem tematycznym rozrzut był całkiem spory, a prezentacje stały na mocno nierównym poziomie. Zdarzały się zarówno takie mega profesionalne, po których szczena opadała i chciało by się słuchać gościa jeszcze i jeszcze, a były też takie, na których zastanawiałem się "co ja tu robię" :/ Odniosłem też wrażenie, że przerwy między sesjami mogłby by być nieco krótsze, a dzięki temu prezentacje ciut dłuższe (np. o 5 min.).

Kolejnym miłym dla mnie zaskoczeniem był fakt, że powoli zaczynam być znany i rozpoznawany "wewnątrz" ;-) Zdarzyło się kilka syt., że ktoś do mnie podszedł i mówi "my się chyba znamy". Czasem było to z którejś z poprzednich konferencji, czasem z wg.net, a czasem z działalności z grupy net.developers.poland .Nie ukrywam, że bardzo miło było chwilę z wami porozmawiać :)

Zanim napiszę po kilka zdań, odnośnie różnych sesji, to zdecydowanie dwie zasługują na pochwałę: Chris Heilmann "Qou vadis, JavaScript" oraz Chad Fowler "From Homogeneous Monolith to Radically Heterogeous Microservices: The Wunderlist 3 story". Zdecydowanie najbardziej interesujące sesje tej konferencji.

Chad Fowler - "The passionate programmer 10 years later" - Ogólnie całkiem fajna i przyjemna sesja nt. podróży, jaką jest życie developera. Chad mówił o tym, że wiele się w życiu zmienia, że często dostawa rolę, lub pisał książkę o czym, na czym nie do końca się znał, ale taką miał rolę, więc ją wykonywał, a później jego praca i przemyślenia stawały się bestsellerami. Wspominał też o potrzebie znalezienia mentora, który pchnie nas ostro do przodu w naszym rozwoju, oraz o potrzebie bycia mentorem. Ogólnie spoko, jednak na samym pocz. nieco za bardzo przynudzał nt. swojej biografi ;-)

Oliver Sturm - "Creepy C#" - Sesja nt. błędów w kodzie. Oliver pokazał kilka przykładów złego kodu, który znalazł kiedyś na produkcji. Sesja miała wyraz humorystyczny (i z tego powodu podobała się kilku os., z którymi rozmawiałem), jednak dla mnie, przedstawione przykłady były zbyt banalne. Dla kogoś, kto wcześniej przerobił książki0 "Ucle Bob" Martina nt. jakości kodu źródłowego oraz na co dzień posługuje się R# te przykłady były zbyt banalne. Sorry, ale odniosłem wrażenie, że tracę czas.

Scoot Allen - "Introduction to Aurelia" - Scoot pokazał w swojej sesji to, można się dowiedzieć wchodząc na stronę i robiąc typowy tutorial. W zasadzie, cała ta sesja to było robienie tuoriala z komentarzem. Problem z tą sesją był taki, że na sam koniec, gdy padło pytanie: "w czym Aurelia jest lepsze od Angular.js"? to Scoot, który jest jedną z os. pracujących nad tym projektem, do końca nie umiał odpowiedzieć. Skoro "insider" sam nie wie, w czym jego produkt jest lepszy od głównego konkurenta, albo na czym będzie polegała główna różnica to poszę Cie, ale... nie.

Shay Friedman - "The wonderful world that is twitter bootstrap" - Kolejny, po Aurelii tutorial jednej z technologii. O termin bootstrapa obił mi się kiedyś o uszy, o tyle dla wielu os. na konferencji to był chleb powszedni. Mi osobiście się podobało i zamierzam pochodzić po stronie projektu i gdzieś to zastosować, o tyle wiem, że wiele os. miało z tą sesją problem taki, że technologia jest już na rynku 2-3 lata, wiele os. z niej korzysta, przyjeżdża gość na konferencje, to myśleli, że pokaże jakieś "tips & tricks", a nie tutoriala od zera do poczatkującego.

Rob Connery - Hard Lessons Learned: Why rethinkdb 2.0 is worth a look - Sesja nt. kolejnej bazy typu NoSQL, przeznaczonej do użytku w trybie on-line z nużym naciskiem położonym na skalowalność. Typowa baza, dla rodzącego się start-upu, opartej o wymianę danych on-line na wielu urządzeniach (synchronizacja). Unikalną umiejętnością tej bazy, jest łatwa replikowalność oraz skalowalność, czyli "rozdwajanie". Pojedyńczy przycisk myszy i z 1 bazy masz dwie (posiadające te same dane i wewnętrznie synchronizowalne).
Zapytania pisze się w języku funkcyjnym. Jak ktoś robi startup z dostępem on-line dostępny na kilku różnych urządzeniach jednocześnie to powienien się zainteresować tematem.

Manimaran Chandrasekaran - Buildin cloud scale enviroment with octopus deploy and powershell dsc - Temat wydawał mi się interesujący, szczególnie z uwagi na myśl o poznaniu i zrozumieniu octopus deploy oraz poznanie opinii na jego temat przez praktyka. Niestety poziom prowadzenia samej prezentacji, był na dosyć niskim poziomie. Już pal licho "angielskawy" prowadzącego, ale sam sposób prowadzenia, dobór materiałów, itp. pozostawiał jednak zbyt wiele do życzenia. Przychylam się do zdania, które uslyszałem w kuluarach: "autor powinien wziąć kamerę i spróbować poprowadzić swoją prezentację kilka razy na sucho, a nast. się obejrzeć". Wszystkim nam, wyszło by to na zdrowie.

Steve Freeman - Rediscovering the command line, or Your Data isn't that Big - Co mogę powiedzieć o tej prezentacji? Że sposób prowadzenia był "usypiający"? Że nie do końca mnie to kręciło? Że temat może i interesujący, jednak po obejrzeniu prezentacji doszedłem do wniosku, że gdzies sobie to zapiszę w głowie, że takie coś istnieje być może wrócę do tego kiedyś później. Temat chyba jednak bardziej na jakiś blog post, niż na masową konferencję.

Will Evans - Heretics, High priests, and Hegiolatry - są dwa dni po konferencji, a ja nawet za bardzo nie mogę sobie przypomnieć, o czym była ta prezentacja. Serio. Widocznie nic bardzo ważnego, albo coś, czego mój mózg nie był w stanie jakoś sensownie strawić. Nic dziwnego, że wyszedłem na 5-10 min przed końcem.

Chris Heilman - Qou vadis, javascript - Chrisa pamiętam jeszcze z Wroc#, jako gościa z Mozilli, który zatrudnił się w Microsofcie w celu zniszczenia Internet Explorer "od środka". Chris opowiadał o javascripcie, o jego zaletach, wadach, wizjach rozwoju i towarzyszącym temu problemach bez żadnych ogródek, ani tematów tabu. Jako, że .js jest obecnie mega gorącym zagadnieniem, warto było posłuchać naprawdę kumatego gościa, siedzącego w temacie po uszy, który mówił "jak jest" i jak to widzą, zarówno twórcy języka, jak i twórcy przeglądarek.

S.Belczyk, M.Łusiak, S.Elamin - "Lighting talks" - kilka, krótkich, 10-15 min "lighting talków". Taki miły i całkiem sympatyczny przerywnik, między większymi prezentacjami. Michał opowiadał tym, jak został prelegentem, Sam o tym, jak robili aplikacje dla jednej z konferencji i spieprzyli sprawę, a mimo tego, im zapłacili, natomiast Sebastian opowiadał o projektach naukowych (sondy kosmiczne, wielki zderzacz hadronów), które trwaja wiele lat, kosztują miliardy, a mają tylko jeden, decydujący releasee, a mimo to, udaje im się osiągnąć sukces.

Gary Short - Walkthrough of a European space data agency science - całkiem fajna prezentacja, nt. tego, w jaki sposób za pomocą komputerowej analizy zdjęć satelitarnych (ew. zdjęć lotniczych) wskazać miejsca, gdzie rosną wybrane rośliny, policzyć ich ilość a nawet, zbadać stan ich zdrowia (wskazać miejsca, w których wegetacja roślin danego typu przebiega w spos. niestandardowy). Jako ciekawostkę, autor pokazywał kody źródłowe, oraz prowadził prezentację w sposób taki, jak należy. Dobra robota.

Chad Fowler "From Homogeneous Monolith to Radically Heterogeous Microservices: The Wunderlist 3 story" - przed prezentacją, wiele os. bało się kolejnego "tutoriala dla początkujących", a w praktyce dostaliśmy coś 100 razy lepszego. Chad opowiadał, jak pewnego dnia rzucił dobrze płatną pracę na kierowniczym stanowisku w jednej z korpo w stanach, aby zostać CTO w jednym ze starupów w Berlinie, który robił "TODO list", czyli taki odpowiednik "Hello world". Opowiadał o problemach, jakie zastał jego zespół podczas pierwszego realesee ich monolitycznej aplikacji napisanej w Ruby (48h przycięcie łącza) oraz o podjęciu decyzji, o zmianie strategii. O wprowadzeniu mikroserwisów, o daniu bardzo dużej dowolności programistom w doborze technologii, o rozmowach z inwestorami, lub wewnętrznych rozmowach w dziale. Pokazywał też architekturę i o niej opowiadał. Dużo, konkretnego "mięcha". Wszystko od strony "praktycznej", żadnego zbędnego, pieprzenia ;-) Mega pozytyw.

Rob Conery - Document storage techniques with PostgreSql and JSONB - Ten sam Rob, który dzień wcześniej opowiadał o RethinkDb, nast. dnia wspominał o zaletach tradycyjnej, relacyjnej bazy danych oraz o rozszerzeniu, którym do niej napisał, dzięki któremu, z PostgreSql można zrobić bazę dokumentów i składować w niej dokumenty, niczym w bazie NoSQL. Pokazywał też te same, lekko skomplikowane zapytanie, które zrobił dzień wcześniej na bazie RethinkDb, i że w zasadzie, jak ktoś chce, to można to sprowadzić jedynie do różnicy w składni. Na pytania o różnice, między bazami, odpowiedział, że PostgreSql lepiej poradzi sobie ze statycznym wyciąganiem danych (mamy np. milion rekordów i piszemy select i wystarczy jedna maszyna), za to RethinkDb jest łatwiej skalowalny i lepiej poradzi sobie pod dużym obciążeniem z www  w syt. gdy trzeba będzie postawić 20-40 maszyn. Po za tym, PostgreSql, w odróżnieniu od niektórych dokumentowych baz dancyh, nie gubi danych <lol> :D

Nat Pryce - Metaphors we code by - taki "lekki" temat na sam koniec, o różnicach jeżykowych oraz "kulturowych", które wpływają na to, w jaki sposób myślimy oraz się ze sobą porozumiewamy. Taka lekka gatka o wszystkim i o niczym.

Uwaga: Podczas konferencji, było co najmniej kilka sesji poświęconych F#, jednak osobiście na żadną z nich sie nie wybrałem, więc ich tutaj nie opisuję.

Wielowątkowy dostęp do zasobów "po polsku" :D

Jak każdy wie, samo programowanie jest wystarczająco trudne, a programowanie wielowątkowe jest trudne do kwadratu. O tym, że jest u nas z tym "krucho" można się było przekonać podczas tegorocznego DevDay 2014 w Krk, podczas którego Dan North wytknął to polskim programistom (głównie tym uczestniczącym na jego warsztatach).

Może ze świadomością wielowątkowości nie jest jakoś super, ale jednak pewna świadomość jest, co pokazała choćby sesja nt. "Modelu aktorów" na Warszawskiej grupie .NET.

A gdzie ja się z tym ost. spotkałem? Ano w aplikacji webowej, którą stworzyłem, a która do generowania raportów wykorzystuje SQL Server Reporting Services w trybie "local reports", tzn. do generowania raportów wykorzystywane są pliki ".rdlc" umieszczone na tym samym serwerze co serwer IIS hostujący stronę web (w moim konkretnym przypadku framework nancyfx).

I o ile przez większość czasu, te raporty generowały się poprawnie, o tyle przed wystawieniem aplikacji dla naszych doradców (pierwsza faza testów objęła ok 50-60 docelowych użytkowników systemu) razem z Adamem K. (osoba z "biznesu") postanowiliśmy przetestować to na x raportów wygenerowanych równocześnie. Zrobiliśmy tak i... klops. Pojawiły się błędy, jedne, te związane z użyciem słówka "static" udało się szybko wyeliminować, to pozostał jeszcze "concurrent access to file".

Stackoverflow.com  zaproponowało synchroniczny dostęp do plików za pomocą "lock". O ile na "początek" to miało sens, tj. wrzucam 'lock'a' "na szybko" i oddaję pierwszą wersję aplikacji użytkownikom do testów, o tyle w docelowej wersji (i kilka razy większej ilości użytkowników) taka wersja systemu była by bardzo niewygodna.

Z pomocą i pomysłem przyszedł mi Michał Kwiatos, który zaproponował rozwiązanie pt. "dla każdego requesta wygeneruj GUID, utwórz katalog z nazwą GUIDa, przekopiuj tam swoje pliki, wykorzystaj je do generowania raportu, a na koniec skasuj niepotrzebny już, śmieciowy katalog", co też zrobiłem i co... rozwiązało mój problem.

I tak sobie teraz myślę, że... najprostsze rozwiązania zwykle bywają najskuteczniejsze.

p.s. mój system docelowo będzie miał mniej niż 500 userów, czyli takie rozwiązanie wydaje się być optymalne. Gdybym tworzył system na +2k userów, to myślę, że na poważnie zastanowił bym się nad implementacją "modelu aktorów" w tym systemie.
p.s.2 wszelkie uwagi mile widziane

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.