Plan wspólnej edukacji

Na początek miała być jakaś złota myśl o potrzebie stworzenia solidnych fundamentów wiedzy ale poniższy obrazek, który ktoś wrzucił na twittera będzie znacznie lepszy

Jeśli ktoś jeszcze nie czytał niesamowitej książki zatytułowanej Antifragile to bardzo polecam. Pośród wielu arcyciekawych konceptów jeden jest niezwykle istotny z punktu widzenia tego artykułu . Przewidywany cykl życia idei! Ów koncept może być dla czytelnika z początku mało intuicyjny bo cała mechanika działa inaczej niż z ludźmi jako takim - zoba te bulletpointy:

• Im dłużej żyje tym mniej życia mu zostało.
• Im Idea żyje dłużej tym więcej życia jej zostało!

Wytłumaczenie jest niezwykle proste. Idea jako Idea nie rdzewieje fizycznie, nie działają na nie wolne rodniki czy inne takie paskudztwa. Natomiast „Idea” umiera gdy "nosniki" przestają ją „przenosić” czyli konkretnie gdy ludzie przestają w daną Idea wierzyć. A wierzyć przestają gdy się z jakiegoś powodu nie sprawdza.

No i teraz mamy takie programowanie funkcyjne nie jako „język z lambdami” ale jako „Koncepcje przeprowadzenia obliczeń” - i ta koncepcja ma 100 lat prawie! To nie jest byle co ku*wa - 100 lat! I jest respawn teraz globalny! I jak ludzie do tego teraz wracają to znaczy, że ta „idea” przetrwała i coś w sobie ma. (dla porównania ludzie nie wracają do idei "woda posiada inteligencje", za którą ktoś tam kiedyś dostał IG Nobla)

No i np. pierwszy warsztat z Javy 8 za tydzień -> Java 8 warsztat meetup (Taka technika marketingowa niby, że se pisze bloga a podrzucam link). Lambda jako lambda w javie8 to prosta – interfejs z jedną metodą – ale co i gdzie można z tym zrobić to „ooo panie” i to „ooooo panie” jest dosyć uniwersalne – to się chyba mów „language agnostic”. Oczywiście kolejną istotną sprawą jest warsztat języka i jeśli jest za dużo ceremoniału by stworzyć coś „lambdopodobnego” (patrz java 7) to podejście staje się nieproduktywne i ludzie zwyczajnie go nie używają (Idea umiera nim się narodzi).

Za chwilę omówię pewien plan edukacji, który być może uda się zrealizować w tym roku na łódzkim JUGu poczynając od wiosny. Jakkolwiek wcześniej trochę Ideologii by zbudować fundamenty.

Teoria i praktyka

Co jakiś czas na różnych forach informatycznych pojawia się temat „czy tego a tego języka można nauczyć się głównie z książki?” No oczywiście, że nie można bo rzadko kiedy książka potrafi zasymulować skalę wyzwań rzeczywistego projektu. Ale jest pewne ALE. Bo tak z drugiej strony – czy języka/technologii można się nauczyć tylko z pracy w projekcie? Z tego co zauważyłem to jest szalenie niebezpieczne podejście! Dlaczego? Gdyż kiedy ludzie używają narzędzia a nie do końca rozumieją jak ono działa – to generują własne wytłumaczenia symboliczne dla zjawisk, które obserwują.

I tak np. osoba używająca mavena w tzw. „projektach komercyjnych” będzie znała wiele myków, które zaskoczą osobę ze znajomością teoretyczną ale być może ta sama osoba nie rozumie koncepcji mavena jako takiej! Zna strone na stackoverflow , z której trzeba przekleić kod by mieć wbudowane jetty ale jednocześnie nie rozumie jak ten wklejony kawałek ma się do koncepcji systemu budowania projektu.

I np. widziałem ludzi, którzy pisali w języku programowania, wiedzieli jak skompilować , jak uruchomić, jak coś wyświetlić. Ale proces tworzenia był niezwykle symboliczny „może tutaj jak wstawię ifa to zadziała, a może tam trzeba ifa, a tutaj jeszcze nie próbowałem”. Rozwińmy ten temat gdyż jest on niezwykle ciekawy w kontekście tego co dzieje się w informatyce.

Od myślenia magicznego do myślenia analitycznego

Na przykład mamy Hibernate - to dobry przykład bo popularny i sam go kaleczyłem. No i jest sobie ten Hibernate i można go użyć na dwa sposoby.

Raz, że się pozna odpowiednio relacyjne bazy danych, pozna się obiektowe mechanizmy Javy - dojdzie się do wniosku, ze trzeba jedno na drugie zmapować i poszuka czy nie ma przydatnego do tego zadania narzędzia. To będzie podejście takie nazwijmy to pragmatyczno-analityczne.
Dwa - można po prostu użyć Hibernate...no bo jak się czyta baze w Javie to przez Hibernate co nie? No tka przeca mówią na forach co nie?. To możemy nazwać myśleniem magicznym. Zastosowanie narzędzia rośnie tutaj do rangi symbolu uproszczonego poprzez sztuczną redukcję niewygodnych detali.

Albo Spring. Sam, żem kiedyś jebnął tzw. "open session in view". Działało. Psuło wiele rzeczy ale nie wiedziałem tego bo działało. Ostatnio znowu słyszałem o rozsypce przez radosne wrzucanie różnych annotacji tu i tam. Chcemy mieć transakcję - to @Transactional i hejnał!!!

Czy coś mniej oldskulowego - Apache Spark. Widziałem - ludzie używają Dataframe bez większej refleksji, że oto operują abstrakcją nad potencjalnie olbrzymim rozproszonym zbiorze danych. No przeca się wyświetla mój hello world to w czym problem? Tudzież ktoś rozpakowuje zipa ze sparkiem 1.6 gdzies w katalogu temp i ogłasza, że dokonał migracji do sparka 1.6. Cluster sruster - kompiluje się przeca!

A tak klasycznie myślenie magiczne to było np. przekonanie, że kwiaty nie rosną (skutek) bo pada deszcz (przyczyna) ale, ze istnieje siła nadprzyrodzona, która widząc kwiaty (przyczyna) sprawia, że pada deszcz (skutek). Czyli na odwyrtkę i na wysokim poziomie abstrakcji ---> więcej tutaj https://en.wikipedia.org/wiki/Magical_thinking

Także reasumując może warto spróbować podejść „teoria poparta praktyką projektową” lub „praktyka poparta zapleczem teoretycznym” ?

Cel Nauki

Na jesieni miał miejsce ciekawy kurs „programowanie funkcyjne w OCAML” i Na 90% raczej nic w życiu w OCAMLu nie napiszę (chociaż kto wie) - po co więc poświęcać czas na naukę? No bo niczego nie trzeba się w tym przypadku oduczać! Jak uczysz się programowania funkcyjnego w Javie, w której piszesz już kilka lat - to chcesz czy nie - przez swoje doświadczenie będziesz widział lambdy jako konstrukcje Javy na JVM – co samo w sobie jest dobre dla praktyki ale niekoniecznie dla edukacji.

A taki OCAML to było dla mnie wszystko nowe! No i się uczyłem. To było bardzo ciekawe gdyż konstrukcje na zmiennych „mutable”, które w Javie są codziennością (i niestety dla wielu jedynym sposobem rozwiązywania problemów) pojawiły się dopiero w tygodniu 5! Tak dopiero w tygodniu piątym! I jest miejsce na te rozwiązania i zapewne zgadujesz dobrze – zazwyczaj kiedy chodzi o wydajność.

Także to nie jest tak, że mutable jest złe i nie należy tego używać. Mutable jest za to szalenie niebezpieczne i trzeba zrozumieć cenę jaką się płaci za korzystanie z tej techniki. Tak – należy do tego podejść jak do techniki, która się używa gdy jest to potrzebne i płaci się cenę. W Ocaml jeśli dorbze pamiętam obszar minowy "mutable" jest ładnie ogrodzony klamerkami tak by było wiadomo, że zły krok i urwie nogę.

No i jeśli chodiz o optymalizację to poza wydajnością pojawia się też pojęcie zajętości. Czuli O(1) może się tyczyć zarówno szybkości jak i tego ile pamięci zajmują struktury danych. I jak masz mieć zajętość O(1) czyli stałą to nie ma siły – masz ograniczony obszar pamięci niezależny od wejściowego n i coś tam musisz w tym obszarze mutować.

Także absolutnie nie jest tak, że Functional Programming,Fanfary i świętujemy. ale może lepsze zrozumienie teorii pozwoli lepiej zrozumieć kiedy iść w stronę łatwego w zrozumieniu programowania deklaratywnego a kiedy poparte doświadczeniem programisty zanurkowanie w w podejście imperatywne przyniesie więcej pożytku niż szkody. I takie podejmowanie decyzji zdaje się nazywa „bycie inżynierem” :)

W biznesie z tego co zaobserwowałem normą dzienną są pytania „czy naprawdę potrzeba w poczekalni kanapy ze skóry aligatora za 20000 złotych czy może coś za 400 z meblowego na rogu będzie ok”. Czas może by i programiści zaczęli się zastanawiać czy mają obliczeniowy hajs na daną technikę czy nie.

Warsztaty jako edukacyjny proces społecznościowy

Dlaczego forma nauki w postaci warsztatów wydaje się według mnie najlepsza? Chociaż sam często mam potrzebę zredukowania bodźców oraz praca na ogromnych szwalniach „openspacowych” - gdzie w tle otacza nas ogromny szum – jest momentami dosyć denerwująca (i nieproduktywna - zwłaszcza jak codziennie o 16 wdzwania się "biurowy Tenor", który swoim głosem przebija nawet niemieckie techno w słuchawkach i przez 30 minut rozmawia o formatowaniu tabelek w excelu - idzie się po prostu zabić) to jednak ludzie jako ludzie żyli w gromadach od tysiącleci i ogólnie kontakty między ludzkie jak są robione dobrze to są fajne i motywujące.

No i generalnie czasem jak się siedzi tak samemu przy kompie gdzie fejsy,lajki i tweety są w odległości jednego kliknięcia by ukraść nasz cenny czas, który przeznaczmy sobie na naukę to nie idzie za wiele zrobić.A Warsztat pozwala nam uczestniczyć w wydarzeniu społecznym, które poza grupową motywacją do nauki zmniejsza tzw. „barierę wejścia w temat” bo dookoła mamy wiele osób zainteresowanych daną technologią, które mogą nam pomóc (+ do pomocy zawsze skromny prowadzący).

No i na sam koniec badania, które nie wiem czy są prawdziwe ale do pewnego stopnia potwierdzone empirycznie – że jak tylko słuchamy zapamiętamy 20-40% materiału a jak robimy to 90% (procenty pewnie wzięte z dupy). No i osobiście zawsze staram się umieścić cały materiał z ćwiczeniami praktycznymi w łatwo dostępnej formie online aby nikt się nie stresował, że jak czegoś nie zrozumie na warsztacie to już nie nadąży. Zawsze można sobie zrobić ćwiczenia na spokojnie w swoim tempie po warsztacie.

Problem systemowy - Jajko i Kura

"Szukam pracy aby zdobyć doświadczenie ale nikt nie chce dać mi pracy bo nie mam doświadczenia". Czyli standardowy problem - mamy nowy stos technologiczny - a ludzie niestety są nauczeni Javy a nie programowania. Sam to odkryłem u siebie na początku 2013 co mnie przeraziło "ja tak naprawdę umiem tylko Jave a nie Inżynierię programowania". Jakim było dla mnie szokiem gdy się okazało, że polimorfizm to nie jest dziedziczenie/interfejsy i tym podobne "odkrycia".

No i bez solidnych podstaw teoretycznych przejście od jednego paradygmatu do drugiego wymaga kolosalnej pracy. To już nie jest kwestia nauki nowego frameworka - trzeba zrozumieć koncepcje teoretyczne, które z kolei pozwolą zrozumieć pewien kontekst - co z kolei pozwoli zrozumieć np. publiczne pola to nie jest zło (a kiedy jest) oraz dlaczego izolacja operacji od danych raz jest dobra raz jest zła. I paradoksalnie widziałem, że nauka Scali na JVM idzie znacznie lepiej programistą .NET bo oni mieli te konstrukcje dużo wcześniej, te strzałki i monady nazywane u nich LINQ zdaje się.

I znowu wracamy do tego punktu "Teoria i praktyka" - jak kogoś poprostu rzucimy na projekt to może dojść do standardowego StackOverflow-Driven-Development - "Wkleję kawałek kodu z dokumentacji/stack overflow i tutaj teraz mi zadziałało. Dalsze konsekwencję? Skąd mam wiedzieć? Zobaczy się, Hejnał!!!" . Po raz kolejny uważam, że praktyka musi być uzupełniona/poprzedzona budowaniem solidnych podstaw teoretycznych.

No i to własnie będziemy to robić - wspólne budowanie fundamentów teoretycznych uzupełnione ćwiczeniami, które z jednej strony dadzą trochę praktyki małej skali ale na pewno nie zastąpią praktyki dużej skali, która można tylko zdobyć w projekcie. No ale przynajmniej skupimy się na tej cześć na którą mamy bezpośredni wpływ czyli na nas samych.

Plan Nauki

Programowanie funkcyjne

Ponieważ ludzie bardzo chcieli Javy bo na co dzień używają Javy to zaczynamy od Javy8 - Java 8 warsztat 1 (znowu przekaz podprogowy) i faktycznie chcą javy bo 60 osób się zapisało i jest mi z tego powodu naprawdę miło, że ludzie wkładają tyle zaufania w edukacje i te warsztaty.

Jednocześnie bardzo chcę równolegle prowadzić zajęcia z FP w Scali gdyż naprawdę ten język daje dużo większe możliwości jeśli chodzi o tworzenie przeróżnych konstrukcji z programowania funkcyjnego. Na początku materiał Scali i Javy będzie podobny a później w Scali zanurkujemy w bardziej zaawansowane rejony. Generalnie ludzie sobie wybiorą co im bardziej będzie pasować :)

Taka ciekawa historia. „Functional programming in Java” na początku było pisane przez tych samych autorów co „Functional programming in Scala” - później autorzy się zmienili i treść zaczęła stała się bardziej pisana „pod programistów javy”.

I do tego są zakupione dwie książki :

oraz

Pozycja do nauki scali jest znana :

Plus na bardziej zaawansowanych zajęciach wchodizmy w ScalaZ i cats

Gdyby to sobie zwizualizować na rysunku to mamy :

Po czym pojawia się kolejna ciekawa książka do nauki :

To jest o tyle ciekawe, że koleś tam już nie bawi się w rozwiązywanie problemów klasy "posortuje listę" ale próboje w duchu DDD rozwiazać problem domeny bankowej przy użyciu konstrukcji FP na poziomie scalaz czy cats.

Co daje

Czyli by jeszcze raz podkreślić – to nie nauka Scali czy Javy8 ale nauka Programowania Funkcyjnego – koncepcji mającej prawie 100 lat - przy pomocy Javy8 (bo ludzie chcieli) i NIEZALEŻNIE w Scali (bo widzę w niej niesamowity potencjał).

Programowanie Reaktywne

• Jest manifest - http://www.reactivemanifesto.org/
• Jest koncepcja, która podobno ma kilkadziesiąt lat i zadziałała ładnie hen czasu temu w Erlangu
• Jest i aktualne narzędzie Akka, którego bardzo chciałbym się w końcu nauczyć używać
• Ma być coś w Java9 - http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/Flow.html

I podobne podejście : nauka koncepcji przy pomocy narzędzia. A tutaj mamy następującą literaturę :

I znowu to jest specjalnie tak wypisane by skoncentrować się na podejściu a w drugiej kolejności na narzędziu.

I teraz mamy

I na koniec temat, o którym mam teraz małe pojęcie czyli "reactive streams" - a że mam pojęcie małe to będziemy się uczyć razem i teraz za dużo nie napiszę

I jak do tego dołożymy typowanych aktorów z tej książki "functional and reactive modeling" to teraz

Typy i „Calculusy”

To jest dla mnie coś nowego i niezwykle fascynującego. O ile w FP pojawia się fraza „function as a first class citizen” tak dalej możemy wyjść z czymś bardziej egzotycznym – co jeśli typ zwracany też można wykorzystać jako wartość? Wtedy pojawia się „type as a first class citizen”. I oto przed nami TDD jako Type Driven Development.

Jest to o tyle ciekawe, że w tej chwili twórcy Scali pracuje nad czymś nowym zwanym „Dotty” https://github.com/lampepfl/dotty. Dotty to chyba scala 3.0 , która uwzględnia coś co nazywa się „DOT Calculus” (DOT - Dependant Object Types). Calculus to „rachunek” i mniej więcej oznacza, że ktoś coś przemyślał i jest jakaś nauka ścisła za rozwiązaniem. Inna Calculus, o którym słyszałem to lambda calculus i to to mówi np. dokładnie kiedy Funktor to Funktor (są konkretne mierzalne warunki do spełnienia) - w OOP nie spotkałem podobnego podejścia - tutaj można dyskutować godzinami czy faktura to intefejs czy klasa abstrakcyjna czy coś tam innego cytując blogi sławnych ludzi. Czasem przyjemnie to się czyta jak ludzie się kłócą ale zazwyczaj wynik jest niemeirzalny i a proces trudny do zautomatyzowania. A w takim ScalaZ w zasadzie są gotowe testy by wrzucić tam naszą customową klaskę i albo jest to Funktor albo nie jest (tak - nie wyolbrzymiam - to jest tak proste).

Haskell

Od Haskella jest Artur Czajka : https://www.gitbook.com/book/tr00per/haskell-101/details. Bardzo dobra edukacja FP.

Inne

Dlaczeo Scala a nie np. Groovy? Jak ktoś chce niech robi ale w epoce kultury masowej konsumpcji mało komu chce się cokolwiek "wytwarzać" (wklejanie cudzych demotów się nie liczy) :) 3 lata temu jak zaczynałem warsztaty ze scali w firmie to pamiętam jak taki ziom narzekał "Scali nie chce ale bym się Clojure pouczył" - Clojure nie znałem to zaproponowałem by sam zrobił warsztat i temat się uciął. Także jak ktoś chce robić Groovy niech się zgłosi i doradzimy w sprawach logistyki i takich tam. Niejaki RobertB chce robić warsztaty z Go bo podobno to tak zajebisty język, że ślina leci. Jak już się spręży to będzie okazja zobaczyć.

Podsumowanie

Zdolnych programistów podobno brakuje. I firmy chcą zatrudniać dobrych programistów i dobrzy programiści chcą pracować z dobrymi programistami. Powyżej to jest własnie taki plan by było wincyj jeszcze wincyj zdolnych programistów - na razie zainteresowanie jest. Będziemy adaptować na bieżąco - jak ktoś chce pomóc niech śmiało się zgłasza.