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ń.