RevDeBug

In last Thursday I have pleasure to take part in Warwaw .NET User Group and hear about new logging tool named "RevDeBug".

RevDeBug is a .net tool, that can be joined to any .net solution at compile time and after compiled into .net solution it collect information about call stack. It's not "error call stack" that we know from standard exception stacktrace. It collects any information, about how code was executed so we can watch how aplication works line by line like we usually do it in debuger. But this time, this code is from production/uat/whatever server.

For me it is quite interesting tool. Maybe I will use it in future in production when I find some very tricky error. 

Cons: 
- logs can be really huge, in example 1GB of logs can be taken in 15-20 minutes (or maybe even less)
- performance - every logging tool working live on production lowers performance of our application

https://www.revdebug.com/ -> project web site

Session about RevDeBug in English (from .net Leipzig Meetup)

HTML 5 Local Storage vs Cookies

While I was solving Weekly Javascript Chalange Task 3 I ask my self a quite interesting question. What is a difference between Local Storage and Cookies?
Somebody already asked that question on SO:  http://stackoverflow.com/questions/3220660/local-storage-vs-cookies ,and there is a very good answer:

Cookies and local storage serve different purposes. Cookies are primarily for reading server-side, local storage can only be read client-side. So the question is, in your app, who needs this data — the client or the server?
If it's your client (your JavaScript), then by all means switch. You're wasting bandwidth by sending all the data in each HTTP header.
If it's your server, local storage isn't so useful because you'd have to forward the data along somehow (with Ajax or hidden form fields or something). This might be okay if the server only needs a small subset of the total data for each request.
You'll want to leave your session cookie as a cookie either way though.
As per the technical difference, and also my understanding:

1. Apart from being an old way of saving data, Cookies give you a limit of 4096 bytes (4095, actually) - its per cookie. Local Storage is as big as 5MB per domain - SO Question also mentions it
2. localStorage is an implementation of the Storage Interface. It stores data with no expiration date, and gets cleared only through JavaScript, or clearing the Browser Cache / Locally Stored Data - unlike cookie expiry.

 Why I mention about it? For two reasons:
a) I use this blog as my notepad, that I sometimes visit
b) this question have a great "interview question" potential

Weekly JavaScript Challenge

This note is to promote some great event that I have found in internet.

Michał Miszczyszyn is one of polish javascript community leader and he starts new weekly javascript chalange. It works, that Michał ones a week create new javascript task, and any competitor can join and try to solve that task. After that time (about one week) Michał takes responses and makes code review.
When he finish code reviews he put task review on his blog.

What a great oportunity for learning new language with code review. Seems great. What you think about it?

I think, that I try to solve some challenges in my free time, but not guarantee that they where will appear regular.

Links:
Michał blog: https://typeofweb.com
Michał blog posts about chalange: https://typeofweb.com/tag/weekly-javascript-challenge/
facebook group where we can find news about new challenge: https://www.facebook.com/groups/1131907053499522/
First task event: https://www.facebook.com/events/997187053723327/
My solutions on github: https://github.com/zchpit/WeeklyJavaScriptChallenge
My solution for task 1 in jsFindle: https://jsfiddle.net/vknqwnb8/15/

Review of tools for PDF generate in .net

 This is my first blog post in English, so fill free to add your comment if any part is incomprehensible.

We have many pdf libraries that we can use, but none of them are perfect and all of them have some advantages and disadvantages. Here is my little experience with generating PDF file in .net framework with generating reports both, in a browser on demand and large numbers in bash/console by night.

Crystal_Reports - big, commercial library develop by big company
Pros: 
- can be really fast
Cons: 
- ugly (at least not pretty) reports
- works on my machine issue (your report can be seen different in different machine, in example on server what can be frustrating when troubleshooting). 

SQL_Server_Reporting_Services - big library that comes with commercial licence for MS SQL Server
Pros:
- quite pretty
- have many in common with office / excel, so you BI can help you in building reports
- can use custom fonts
Cons:
Local Mode:
- have memory leaks (you will see it when you try generate PDF in large numbers)
- more complicated reports can be really slow (reporting services team upgrading reporting services from .net 3.5 to 4.0 made bug with grouping rows in table).
- don't have justify text 
- you can't "copy/paste" document from MS Word
Server Mode:
- sometimes there are issue with authentication and priviliges
- you can't use collection of your objects as data source (it was a reason why I choose Local Mode).
- don't have justify text 
- you can't "copy/paste" document from MS Word

Wkhtmltopdf - open source library made by google for converting html into pdf
Pros:
- quite fast
Cons:
- graph from jQuery library are medium quality (in magnification you can see pixels)
- few options for editing text

MS Word Interop - native MS Word API for CRUD operations in word documents
Pros:
- best MS Word document projection
Cons:
- slow
- need to have MS Office Word installed on working machine
- requires a little work and workarounds when we want to use it from task scheduler ( http://stackoverflow.com/questions/1006923/automating-office-via-windows-service-on-server-2008/1680214#1680214 )
- requires a much more work when we want to use it from IIS 

Telerik - Kendo-UI - commercial library to creating great html, and export it to pdf
Pros:
- quite pretty
- write html and just export it into pdf
Cons:
- have trouble with custom fonts 
- pdf generation could be faster 

ELMAH

ELMAH, czyli Error Logging Modules And Handlers (ELMAH) - jest to biblioteka/moduł dostępny za darmo służący do zarządzania oraz monitorowania błędów w oprogramowaniu. Moduł ten oparty jest na śledzeniu zdarzeń i można go podpiąć do istniejącej aplikacji bez zmiany ani jednej linii kodu (zmiany wykonujemy tylko w konfiguracji). Główne zadania ELMAH-a, to obsługa, zarządzanie, monitorowanie, eskalacja błędów, ze szczególnym uwzględnieniem błędów nieobsłużonych.

Główne zalety/funkcjonalności ELMAHA:
- prostota konfiguracji
- prosty interfejs webowy pokazujący szczegółowe dane
- odkładanie błędów do bazy danych / plików xml / etc
- przechwytywanie i logowanie nieobsłużonych błędów
- wysyłanie maili i notyfikacji w momencie wystąpienia błędów
- logowanie wszystkich lub tylko wybranych typów błędów
- darmowa biblioteka
- możliwość logowania w sposób "tradycyjny" z poziomu C#
( ErrorSignal.FromCurrentContext().Raise(e); )

Z tego tez powodu uważam, że warto się przyjrzeć tej bibliotece bliżej.

Linki:
- http://code.google.com/p/elmah/
- http://www.asp.net/web-forms/overview/older-versions-getting-started/deploying-web-site-projects/logging-error-details-with-elmah-cs

konferencja meet.js summit (#meetjs16)

O konferencji "Meet.js Summit 2016" dowiedziałem się dosyć niedawno, czyli na około tydź. przed konferencją. W tamtym czasie, biletów już nie było, jednak dzięki odrobinie szczęścia oraz życzliwości jednego z użytkowników portalu wykop.pl udało mi się zdobyć wejściówkę na tą konferencję (jednemu z uczestników coś wypadło i oddał wejściówkę, aby się nie zmarnowała). Tym oto zrządzeniem losu udało mi się pójść na tą, jakże wspaniałą konferencję, poświęconą językowi javasctipt.

Najpierw pokrótce opiszę kilka prezentacji, na których byłem, a nast. kilka uwag ogólnych na temat konferencji.

Katarzyna Jastrzębska - "Web projects with ClojureScript" -> Kasia pokazała nowy język, będący mieszanką Clojure oraz Javascriptu (te języki można mieszać ze sobą w składni, m.in. w taki sposób następuje odwołanie do obiektów drzewa DOM). Moje pierwsze wrażenie na temat ClojureScript jest takie, że nie zastosował bym go w moich, korporacyjnych projektach. Powodem jest zbyt słabo typowana składnia. Kasia jako przykład dynamiki języka, pokazała instrukcję "if", która nie jest wyrażeniem języka, a jedynie funkcją odpowiednio zmutowaną, aby pełniła taką rolę (sam język nie posiada instrukcji "if"). Jest przez to bardzo elastyczny. Niestety, ale w korporacjach utrzymanie istniejącego kodu trwa wiele lat, zespoły programistyczne zmieniają się często, a przez to miałem m.in. okazję utrzymywać kod jako piąty programista. Oczywiście każdy poprzednik miał swój sposób pisania kodu, swoje dobre praktyki oraz swoje niedbałości. Jak do tego dojdzie jeszcze pisanie "if-a" na 20 różnych sposobów, to w takim kodzie po kilku latach może być naprawdę niezły "mindfuck".
Pozwólcie, że zacytuję klasyka:

define TRUE FALSE
//Happy debugging suckers

Jeżeli natomiast chodzi o uwagi do prelegenta, to miałbym 3 drobne uwagi:
- więcej pewności siebie ;-)
- na slajdach, które pokazują tą samą metodę w 2 językach jednak fajnie by było, gdyby ta metoda posiadała tą samą nazwę, oraz te same parametry
- przy pokazywani praktycznych przykładów, dobrze jest wcześniej przygotować sobie snippety z kodem (wtedy wszystko odbywa się jakby płynniej)
- ale ogólnie to pozytywna prezentacja
- dziękuję za kubek scalaz ;-)

Grzegorz Koronowski - "Angular & JS lessons learned" -> całkiem fajna prezentacja nt. praktycznych przykładów korzystania z angular.js. Osobiście nie korzystałem z angulara na produkcji, natomiast kolega, który siedział obok mnie, nad jednym z pokazywanych przykładów (nr. 2 lub nr. 3), spędził sporo czasu w pracy, a na koniec doszedł niezależnie do podobnych wniosków, co autor. Ja się zastanawiałem nad przykładem nr.4, tj. czy nie prościej było by zwobić zwykły "target _blank", ale później sobie pomyślałem, że autor zapewne do nowego okna chciał przekazywać stan aplikacji lub jej parametry w sposób "ukryty", oraz obudować tą logikę w jakiś sprytny mechanizm. Takie też później padło pytanie, a odpowiedź mniej więcej pokrywała się z moimi przypuszczeniami. Ogólnie fajna i na pewno przydatna prezentacja. Taka życia.
Drobna uwaga do prelegenta: w wolnej chwili można ciut bardziej podszlifować język angielski. Jest dobrze, ale mogło by być jeszcze lepiej ;-)

Łukasz Fiszer - "Npm scripts as an automated tool" -> fajny talk. Łukasz przedstawiał sposoby automatyzacji tasków, oraz sporo porównywał do obecnie stosowanych narzędzi, tj. gulp i grunt. Że często próbuje się z nich zrobić "szwajcarski scyzoryk" i stosować nawet w tych miejscach, w których nie powinno się tego robić. Łukasz wspomniał też o tym, że na rynku popularne są dwa narzędzia o niekompatybilnych ze sobą plikach wsadowych, dlatego on pokazuje trzecie rozwiązanie. Z drugiej strony, podczas swojej prezentacji był bardzo przekonujący.

Robert Kawecki - "Reliable Node.js application for a reactive world" -> dosyć dobra prezentacja o tym, co jest ostatnio "trendy" w świecie backendu, czyli CQRS + EventStore + DDD, na przykładzie konkretnego, działającego produktu, stworzonej przez stosunkowo młodą firmę. A to wszystko w świecie javascriptu. Jak ktoś chce poznać obecne trendy na konkretnym, działającym (i wdrożonym produkcyjnie) przykładzie, w dodatku przedstawioną w bardzo prostej i przystępnej formie, to koniecznie powinien obejrzeć tą prezentację. Po prostu SUPER!!!.

Łukasz Korowicki - "Style Guide Driven Development - Episode IV - New Hope for Front-end" -> ta prezentacja, to taki przekrój przez dostępne obecnie na rynku sposoby tworzenia różnej maści "css-ów", czyli LESS, SASS. W sumie nie jestem grafikiem, więc się nie wypowiem nt. szczegółów.

Adrian Makowski & Adam Chwitkowski - "Creating easy going code" -> bardzo fajna prezentacja. Oboje panowie wybrali po kilka prostych zasad, zarówno z front-endu, jak i back-endu, których przestrzeganie bardzo ułatwia życie. Z front-endu było m.in. oocss, bem, itcss, natomiast z back-endu były 2 literki z SOLID oraz "composition over inheritence" (interfejsy > dziedziczenie) wraz z praktycznymi przykładami "bad code vs good code" + tdd. Rady odnośnie backendu znałem od dawna, za to najwyższy czas, zainteresować się tym, co oznaczają wymienione skróty z frontendu. Bardzo fajna i przydatna prezentacja.

Artur Szott - "React enlightenment - my 10 month Journey with React.js" -> z tego co pamiętam, to Artur pokazywał w swojej prezentacji, że sam React.js na początku może być nieco przytłaczający dla kogoś z zewnątrz, oraz pokazywał od czego można zacząć, czyli od ".jsx" natomiast testować z wykorzystaniem mocha i chai. Tak teraz sprawdzam i... nie mam więcej notatek na temat tej prezentacji, czyli raczej taki intro talk dla zupełnie początkujących w świecie react-a.

Zbyszek Tenerowicz - "Gettin your Node.js app production redy" -> od jakiegoś czasu, bawię się w domu kursem Node.js z nodeschool.io i ten talk był idealnie adresowany do mnie, ponieważ autor wychodzi z założenie, że jego widownia tyle co skończyła kurs na nodeschool.io albo inny, czyli zna podst. node.js i chciała by zrobić krok dalej, czyli umieścić swoje rozwiązanie na produkcji. Zbyszek pokazuje zaróno narzędzia z jakimi poleca się zapoznać, tj. pm2 (process manager),  podejścia programistyczne, jakie powinniśmy stosować w naszym node.js (aplikacja pomiędzy requestami http powinna być bezstanowa, ewentualnie kiedy już naprawdę jesteśmy zmuszeni utrzymywać stan pomiędzy requestami, to wtedy korzystamy z redis). Wszystko powinniśmy wykonywać asynchronicznie, polubić się z TypeScryptem, zapoznać się z poziomami logowania, podpiąć pod istniejące syst. monitorowania w firmie, o ile takie są (kiepski syst. monitorowania, na który ktoś patrzy full time, jest dużo lepszy niż dobry syst. monitorowania, na który sami będziemy patrzeli od czasu do czasu). Kolejne narzędzia / biblioteki, do monitorowania stanu aplikacji: Nsp chceck, node secure project, requireSafe (oraz komenda javascriptowa process.memoryUsage().rss wykonywana z wewnątrz naszego kodu). I na koniec linki, czyli absolutny "must watch", czyli netflix -> nodejs-in-flames, ponieważ lepiej wiedzieć co nas spotka w życiu wcześniej i od samego pocz. mieć przyg. plan naprawczy. Super talk. Jak dla osoby, która sama sobie po nocach koduje w node.js, a docelowo chcę zrobić jakiś własny "pet project", w którym node.js wykorzystam, to ten talk był dla mnie super.
p.s. uwaga na wycieki pamięci, ponieważ node.js ma limit 1.5gb danych (jak proces node.js będzie zajmował więcej pamięci, to się wywali).

Michał Załęcki - "Reactive JavaScript" -> ta prezentacja, to opis tego, czym są "reactive extensions", jaka była droga ewolucji w javascripcie, czyli callbacks -> promises -> asynnc/await -> react extensions (i dlaczego aktualnie warto stos. właśnie reactive extensions i w czym one są lepsze, np. dużo bardziej czytelna składnia niż async/await). Było też o zastosowaniu kilku wzorcach projektowych (m.in. obserwator), oraz programowania funkcyjnego w javascript. Całkiem przyjemny talk poglądowy, dlaczego warto korzystać z reactive extensions. Całkiem miło i przyjemnie spędzony czas.

Z prelekcji, na których nie byłem, za to widzę wielkie ochy i achy na twitterze, to Staś Małolepszy - "The future od Javascript is now. How to make the most of it?". Jak tylko pojawią się nagrania z konferencji w necie (prelekcje były nagrywane), to chętnie ją sobie obejrzę.

Uwagi ogólne do organizatorów? Super konferencja, dobra lokalizacja, wyżywienie, mega super prelekcje. Naprawdę mega konferencja. Czy czegoś mi brakowało albo co można by było zmienić? Brakowało mi dwóch rzeczy. W sumie pierdoły, ale mogę o nich wspomnieć:
- osoby z dzwonkiem, która by przypominała, że właśnie rozpoczęła się prezentacja na jednej z sali. Na korytarzu zawsze było kilka osób, był szum, ciągle coś się działo, więc bardzo łatwo można było przegapić czas rozpoczęcia prezentacji, co skutkowało tym, że drzwi do sali były otwarte trochę dłużej niż powinny (nawet 10-15 min od rozpoczęcia prelekcji) i siedząc w ostatnich rzędach było słychać szum dochodzący z korytarza.
- na jednej z konferencji zauważyłem fajny bajer, tj. 3 kolorowe karteczki (zielony, żółty, czerwony), które były dostępne podczas wychodzenia z prezentacji a wychodzący z prezentacji uczestnicy wrzucali je półmiska, dając tym samym łatwo widoczny "feedback".

Ale tak to super. Mega konferencja i jestem bardzo zadowolony, że mogłem wziąć w niej udział. Jakościowo to stała MEGA, co zresztą widać w opisach konkretnych prezentacji. Zdecydowanie polecam.

Node.js

Ost. czasy bardzo popularnym językiem jest javascript. Ten język istnieje od dosyć dawna, jednak przez wiele lat traktowny był "po macoszemu". Ost. kilka lat, to jednak zdecydowany "boom" na ten konkretny język. Ilość bibliotek i frameworków jaka powstaje jest wprost niesamowita.
Javascript przez wiele lat kojarzony był głównie z frontendem, czyli tą częścią strony www, która wykonuje się bezpośrednio w przeglądarce internetowej. Teraz jednak javascript dorobił się porządnego rozwiązania serwerowego, zgodnie z ideologią "jeden język programowania - wszędzie". Typ rozwiązaniem serwerowym jest Node.js

Krótki wpis, co to jest npm (node package manager), jak i samo nodejs można znaleźć na blogu Gutka link, więc nie będę się tutaj powtarzał, szczególnie, że Gutek opisał to fajnie, zgrabnie itp (ohy i ahy).

Ja z mojej strony polecił bym zacząć się z tym bawić, od robienia tutoriali z nodeschool.io/.Samemu skończyłem już część Core-ową i aktualnie robię wersję rozszerzoną i jak na razie mi się to podoba. A, że warto spróbować i dać nodejs szansę, to warto spojrzeć choćby na przykładowy serwer wystawiający json-y, jaki można postawić z wykorzystaniem biblioteki "express".

var portNumber = process.argv[2];
var url = require('url');
var express = require('express');
var app = express();

app.get('/api/parsetime', function(req, res){
  var parsedUrl = url.parse(req.url, true);
  var date = new Date(parsedUrl.query.iso);

  res.json({ hour: date.getHours(), minute: date.getMinutes(), second: date.getSeconds()  })
});
app.get('/api/unixtime', function(req, res){
  var parsedUrl = url.parse(req.url, true);
  var date = new Date(parsedUrl.query.iso);

  res.json({ unixtime: date.getTime() })
});

app.listen(portNumber);

Wygląda znajomo?
Prawie, jak w we wspaniałym nancyfx.org.
Dodatkowo, fajnie rzeczy można wyczarować operując na strumieniach danych (nieco inaczej się operuje niż w c#) oraz tworzyć z nich "wężyki" Method chaining.

Całkiem interesująca technologia.

Powtórzenie z algorytmów

Jakiś czas temu, postanowiłem się doszkolić ze znajomości algorytmów. Częściowo było to spowodowane tym, że na studiach miałem dosyć okrojone algorytmy (mieliśmy różne sortowania, różne sposoby podziału, ale do grafów już nie doszliśmy) i o ile przez długi czas ta wiedza była wystarczająca, z czasem jednak codility rosło w popularność. O ile obecnie swój "peak" zapewne ma już za sobą, to podczas przykładowej rozmowy kwalifikacyjnej lub zgłaszania swojego uczestnictwa do darmowego szkolenia lub hakatonu zawsze możemy zostać poproszeni o zakodowanie czegoś "na szybko".

Ten temat miałem w tyle głowy jako "TODO" już od wiosny 2015r, jednak wziąłem się za niego dopiero jesienią 2015. Na pocz. sygnałem był temat z tagiem #zadaniaBartosza na popularnym portalu społecznościowym wykop.pl. Jeden z użytkowników wziął przykładową książkę do algorytów i raz w tyg. publikował zadanie, które nast. pozostali użytkownicy rozwiązywali. Po kilku zadaniach użytkownikowi znudziła się cała zabawa, a i algorytmy jakie rozwiązywaliśmy pozostawiały nieco do życzenia. Ważne jest to, że dała mi impuls do tego, aby wreszcie wziąć się za ten temat.

Nast. postanowiłem wziąć się za algorytmy sam. I wziąć się za nie w dwójnasób, tj. za pomocą strony z algorytmami jaką znałem, tj. projecteuler.net oraz kupując książkę teoretyczną. Przy wyborze książki swój wybór oparłem na tym opisie: książki do nauki algorytmów, a ost. wybór padł na Wprowadzenie do algorytów.

Co mogę napisać o tych dwóch sposobach uczenia?
- project Euler to już jest bardzo stara strona, która posiada multum zagadek (ponad 200), jednak wiele z nich to problemy czysto matematyczne. Zaletą natomiast jest to, że istnieje wiele gotowych rozwiązań, wraz z zwyjaśnieniami zadań, tzn. najpierw możemy sami spróbować, a później znaleźć lepsze rozwiązanie z wytłumaczeniem dlaczego tak, a nie inaczej
- książka wyjaśnia pewne podstawy, wyjaśnia również coraz bardziej zaawansowane rzeczy, jednak jest strasznie duża (gruba) i pisana językiem matematycznym. Widać, że jest to podręcznik akademicki, co ma swoje zalety jak i wady.

Jeżeli ktoś nie chce wydawać pieniędzy aby kupować książkę, to po wykonaniu danego zadania, polecam mu zajrzeć np. na http://www.mathblog.dk/project-euler-solutions/, w którym autor dosyć dobrze opisuje dane zagadnienie, zarówno w kwestii podstaw teoretycznych, jak i dostarcza działający kod. Zazwyczaj dostarcza kilka rozwiązań, tłumaczy czym one się różnią oraz wyjaśnia brakujące podstawy teoretyczne. Polecam do nauki.

Uczyłem się z tego, aż do pewnej rozmowy z Michał Franc, która nieco odświeżyła moją wiedzę. Z tej rozmowy były dwa wnioski:
- algorytmy to tylko jeden z bardzo wielu elementów wymaganych wobec programisty i wcale nie trzeba ich mieć obcykanych na tip top, aby móc powiedzieć o sobie, że jesteśmy "pro"
- pokazał mi, że istnieje lepsza strona z zadaniami od projektu Euler, czyli https://leetcode.com/

Ost. strona, tj. leetcode.com, mimo iż spędziłem przy niej najmniej czasu ze wszystkich wymienionych tutaj projektów, wydaje mi się obecnie najlepsza do nauki. Problemy wydają się bardziej życiowe, choć mogło to być spowodowane tym, że Eulera brałem "od początku", a LeetCode losowo ze środka, a dodatkowo dostajemy do tego masę testów jednostkowych, które podają nam wynik. To właśnie te jawne testy mają największą przewagę ze wszystkich wymienionych tutaj rozwiązań.
Gdybym obecnie ponownie stawał do zadania "naucz się algorytmów" to uczył bym się ich z https://leetcode.com/

Ciekawostki:
- w trakcie pracy nad tym zadaniem, udało mi się też zostać kontrybutorem (współautorem) jednego z zadań w projekcie rosettacode.org, a dokładniej wersji C# problemu  sumy największej ścieżki wewnątrz trójkąta Maximum_triangle_path_sum#C.23
- niektóre z rozwiązanych przezemnie zadań umieściłem na githubie. Wyjątkiem jest "leetcode", który posiada własny system pamiętania rozwiązań.

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 :-)

e-learning, pluralsight.com vs coursera.org

W tym wpisie postaram się opisać moje przemyślenia, nt. dwóch platform elearningowych, z których miałem okazję korzystać ost. jesieni.

Pierwszą platformą, z której skorzystałem jest to pluralsight.com.
Platforma dostarcza dwie opcje dostępu, tj. "standard" ograniczoną do oglądania filmów video, oraz "plus", w którórej dostępne są również ćwiczenia, sprawdzenia wiedzy oraz certyfikaty.

Standardowo, każdy może skorzystać z "free trail", dzięki któremu, możemy skorzystać z 10dni/200min darmowego dostępu. Dzięki uprzejmości Pawła Klimczyka miałem dostęp miesięczny dostęp do platformy za pomocą kodu promocyjnego.

Podczas mojej obecności na platformie, korzystałem z dostępu standard i obejrzałem dwa materiały szkoleniowe, jeden związany z Angular.js, oraz drugi, z językiem Scala. To na co zwróciłem uwagę, to spora ilość materiałów szkoleniowych, oraz wysoki poziom prezentowanych materiałów. Podczas kursu angular.js autor wykorzystywał plunkera, natomiast w prezentacji nt. języka scala autor pierwsze co zrobił, to postawił sobie środowisko z automatycznym testowaniem testów jednostkowych podczas pisania kodu oprogramowania. W środkowisku .net za podobną funkcjonalność odpowiada płatny plug-in do VS o nazwie NCrunch.

Kursy mi się podobały, można się było sporo nauczyć od profesionalistów, jednak wesja standard to jest jednak zdecydowanie za mało. Cały materiał pojedyńczego kursu podzielony jest na kilka półgodzinnych części. Nie wiem jak inni, ale u mnie, podczas oglądania półgodzinnego materiału z czasem spadało skupienie. Samo oglądanie, to jednak za mało. Zapewne dużo lepiej sprawdziła by sie wersja "plus", w której jest więcej ćwiczeń do samodzielnego opracowania tematu.

Warto też wspomnieć, że plularsight się rozwija i zakupił inne, podobne serwisy, takie jak np. codeschool.com ,który bardzo polubiłem swego czasu, jednak w momencie, kiedy testowałem ten serwis, to konta oraz płatności pomiędzy tymi serwisami nie były zintegrowane.


Drugą platformą do elearningu, którą miałem okazję ost. przetestować jest www.coursera.org.
Coursera, to platforma oparta o uczelnie wyższe, tj. renomowane uczelnie na codzień zajmujące się kształceniem studentów. Warto wspomnieć, ze w projekcie coursery można znaleźć takie uczelnie jak m.in. słynne MIT.
Coursera oferuje ścieżki nauki, w których znajdują się kursy, z różnymi dziedzinami danego zagadnienia prowadzone przez różne uczelnie. Każdy kurs składa się z 4 tygodni nauki. W każdym tyg. mamy część video z teorią, test wiedzy oraz kilka zadań praktycznych, które musimy wykonać samodzielnie, a nast. przesłać na uczelnię. Na każdym tyg. mamy deadline, w którym musimy się zmieścić z wykonaniem swoich zadań. Deadliny są dwa. Jeżeli wyrobimy się w pierwszym to ok, jeżeli jednak się z nim nie wyrobimy, to za każdy dzień zwłoki tracimy 5% punktów za odp. Nieryrobienie się w drugim deadline oznacza niezaliczenie zadania. W wersji płatnej możliwe są oficjalne certyfikaty wydawane przez uczelnie.

W moim przypadku był to kurs programowania urządzeń mobilnych w języku java na platformę Andrid prowadzony przez University of Maryland, College Park.  To co warte jest wspomnienia, to fakt, że podczas oglądania materiałow wideo, średnio co 3-5 min. była pauza z 1-3 pytań nt. omawianego materiału (pomaga w skupieniu się na omawianym materiale), oraz fakt, iż prowadzący od samego początku pokazuje, w których miejscach należy szukać informacji (linki do dokumentacji platformy, lokalnych grup użytkoników, forum stackoverflow.com, itp.). 
Bardzo fajny sposób nauki, który wymaga od ucznia, zarówno poznania teorii, samodzielnej pracy z kodem, jak i pracy na dokumentacji.
Główną wadą, jaką zauważyłem odnośnie coursery jest stosunkowo mała ilość dostępnych kursów / ścieżek. Np. szukałem ścieżki z programowania funkcyjnego i niestety niemogłem nic znaleźć.


Podsumowanie:
Obie platformy są bardzo fajne. 
W plularsight podobała mi się ilość dostępnych materiałów oraz profesionalne podejście prowadzących. Widać, że mamy do czynienia z zawodowcami, którzy od samego początku uczą "dobrych praktyk". Główną wadą tej wersji, z której korzystałem była zaby mała interakcja pomiędzy prowadzącym a prowadzonym. W wersji standard brakowało tego "learn by doing".  Możliwe, że w wersji "plus" te mankamenty zostały poprawione, jednak nie wiem czy stoją ona na tak wysokim poziomie, jak w courserze.

W courserze podobało mi się połączenie wykładów (materiały wideo), pracy na dokumentacji (testy na zaliczenie) oraz prac domowych z kodem (przygotowane wcześniej aplikacje, które trzeba nieco przerobić, aby zaczęły pracować tak jak chcemy). Główną wadą coursery jest dostępna ilość materiałów, oraz ich aktualność. Kurs, który ja przechodziłem miał już dobre 1.5 roku, więc zdąćył się już nieco zestarzeć poprawny kod programu działał tylko na emulatorach (maszynach wirtualnych) tylko niektórych androidów.

Co bym polecił?
Gdybym samemu miał wydawać własne pieniądze, to:
a) jeżeli ktoś nie ma żadnego doświadczenia, lub jest dopiero początkujący w jakiejś technologii, to dla takiej osoby polecił bym zacząć od wykonania pełnej ścieżki (6 kursów) na courserze. Zostanie ładnie oprowadzony po danej technologii, pozna jej różne aspekty, dzięki czemu będzie posiadał solidne podstawy.

b) jeżeli jednak ktoś ma podstawy i miał już okazję pracować w danej technologii, a chciałby jedynie podnieść swój poziom, tudzież się "doszkolić" w najnowszych trendach, to dla takich osób polecił bym plularsight.