niedziela, 31 maja 2015

Czas ekspozycji na język - czyli co tak naprawdę jest czytelne i czy dziwne znaczki są dziwne?

W temacie czytelności kodu zdarzyło się ostatnio kilka ciekawych rzeczy. Po pierwsze w dobie prezentacji o tym jakiego koloru powinny być kartki z taskami pojawiło się jedno ciekawe wystąpienie, która podejmuje temat odmiennej perceppcji swiata intro i ekstrawertyków.

A TO JEST DO NIEJ LINK **-~~~~~>>>> http://www.infoq.com/presentations/psychology-agile

Prezentację polecam sobie obejrzeć całą - ale jest jeden ciekawy slajd w temacie czytelności kodu- ciekawy bo opowiada o tym jak "percepcyjnie" nasz móżg "dekoduje ten kod" :

I w skrócie okazuje się, iż z biegiem czasu programista nie czyta kodu znak po znaku ale raczej (powtórzmy to słowo)dekoduje zestaw znanych struktur - dlatego dwa kawałki kodu mogą mieć podobną złożoność wyliczoną jakimiś wskaźnikami a ludzie będą i tak jeden oceniać jako bardziej czytelny niż drugi. (A nawet kiedyś zrobiłem o tym artykuł - http://pawelwlodarski.blogspot.com/2011/10/poznaj-swoje-ograniczenia.html i znowu data 2011 i znowu zaduma nad pędzącym czasem...)

A po drugie mózgi niektórych programistów wychowanych w czeluściach działów utrzymania gdzie zalepiali luki w cegiełkach egipskich systemów ulegną zapewne przepaleniu bo wyszła oto dosyć ciekawa książka :

I to jest o Javie... i już nie można narzekać, że jakiś język X cośtamcośtam Bo-To-Jest-O-Javie ...i o strzałkach i (za jakieś 50 lat - dop. tłumacza) jak korporacje przejdą na Javę8 nie będzie już ucieczki od tych strzałek.

A przykładowy kod z książki wygląda tak :

public static <A, B, C, D> Function<A, Function<B, Function<C, Function<D, String>>>> f() {
    return a->b->c->d->String.format("%s, %s, %s, %s",a,b,c,d);
  }
(zwyklu currying - o ch*** ci chodzi?!)

FP Java

Książka z niebieską okładką jest książką bliźniaczą do wydanej poprzednio przez tych samych autorów czerwonej -pokazanej poniżej, tyle tylko że w dobie napięcia na linii Wschód-Zachód - ma mniej komunistyczną okładkę

Pierwsza ciekawa obserwacja : w obydwu książkach we wstępie jest ten sam przykład z refaktoringiem kodu zakupu kawy od wersji klasycznie-imperatywnej, która ze względu na efekty uboczne w zasadzie się nie komponuje z pozostałymi kawałkami kodu - do formy funkcyjnej, która ładnie składa się w większe kawałki logiki.

I tutaj podobieństwa się kończą bo w przypadku javy jest trochę zabawy z samą składnią gdzie co chwila autorzy piszą "fajnie gdyby się to dało zapisać tak a tak ale się nie da" plus jest trochę uzupełniania brakujących funkcjonalności jak doimplementowywanie klasy Tuple.

Tak czy inaczej fajne jest to, że jak ktoś nie miał okazji popracować z generykami w Javie to teraz będzie ją miał - a do tego kilka java puzzlerów dochodzi już w samym przykładzie próby zaimplementowania rekrencyjnej lambdy gdzie autorzy przedstawiają trzy haki na kompilator (plus taki kawałek - "na potrzeby edukacji udawajmy, że java wspiera tail recursion").

No dobra ale co z tą czytelnością i czy strzałki ją poprawiają?

Czas ekspozycji na technologię

Mamy taki kawałek Javy :
 public static final Function<Integer, Integer> triple = x -> x * 3;

  public static final Function<Integer, Integer> square = x -> x * x;

  public static final Function<Function<Integer, Integer>, Function<Function<Integer, Integer>,
                                        Function<Integer, Integer>>> compose = f1-> f2 -> x -> f1.apply(f2.apply(x));

  public static final Function<Integer, Integer> f = compose.apply(square).apply(triple);
I dokładnie taki sam poniżej w scali - w sensie analogiczny :

val triple:Int=>Int=_*3
val square= (x:Int)=>x*x
val compose : (Int=>Int) => (Int=>Int) => (Int=>Int) =
f1 => f2 => x=> f1(f2(x))

I teraz może nastąpić szereg uwag i obserwacji. Po pierwsze dla osób, które każdy problem rozwiązują skończoną ilością ifów obydwa kawałki kodu będą nieczytelne i stwierdzi, ze to całe FP to bzdura - wiem, bo sam tak kiedyś myślałem.

Po drugie w przypadku osób, które już mogą mieć doświadczenie w Javie8 drugi przykład z kodem _*3 i aliasami typów, które nie występują w Javie Int=>Int będzie zapewne nieczytelny i stwierdzi, ze ta scala to bzdura - wiem, bo sam tak kiedyś myślałem.

Ale zobaczmy teraz coś innego - twarze, których nie ma :

Dlaczego większość ludzi widzi tam twarze? Mózg rozpoznaje wzorce, ewolucja, krytyczne do przetrwania sratatata itd. Ale pytanie jak to ma się do kodu? Generalnie dałem te dwa obrazki aby każdy sam zobaczył, że coś może "po prostu się dziać w naszej głowie" i trudno to opisać w logiczne warunki w stylu "jest logiczne że ciąg znaków xyz jest lepszy abc"

Zakładając, że system percepcyjny może podobnie jak w przypadku twarzy przystosować się do pewnych wzorców w kodzie - a ten link z prezentacją z INFOQ był po to by pokazać, że podobno tak - to możemy sobie powiedzieć że czytelność kodu to nie tyle funkcja jego złożoności ale raczej :

CKp=f(Z,Te)

  • CKp - czytelność kodu według programisty P
  • Z - złoność kodu samego w sobie - cyclomatic complexity itd
  • Te - I to coś nowego! Czas ekspozycji programisty oceniającego na dany język/ sposób zapisu
I tutaj dobry moment na metaforę z siłownią. Generalnie by podnosić większe ciężary przejrzenie magazynu kulturystycznego nie wystarczy, trzeba (mądrze) ćwiczyć, ćwiczyć i jeszcze raz ćwiczyć. Podobnie Java w 24 godziny czy tam Scala dla niecierpliwych czy coś w tym stylu to też może być za mało.

Czy poniższy kod jest czytelny? Może warto zapytać - czy już jest czytelny dla Ciebie?!? (zauważyłem, że sprzedawcy jak mówią do grupy to często używają słowa "Ciebie")
(defn triple [x] (* x 3))
(defn square [x] (* x x))
(defn compose [f1 f2] (fn [x] (-> x f2 f1)))
Dla mnie kod clojure każdego dnia staje się coraz czytelniejszy a nie jestem pewien czy kiedyś i po nim nie jechałem. Nowa forma refaktoringu? - zmniejszenie złożoności kodu poprzez zwiększenie doświadczenia programistów bez zmiany kodu?

Dalsze porównania

Wróćmy an chwilę do narzekania na emotiocon driven development. Jest taki kod scali :

List(1,2,3,4,5).reduce((a,b)=>a+b)
List(1,2,3,4,5).reduce(_+_)

I podobny kod clojure - też są placeholdery %1, %2 - być może po ogarnięciu jednego języka z placeholderami ogólny koncept staje się dla nas akceptowalny?
(reduce (fn [a b] (+ a b)) (list 1 2 3 4 5))
(reduce #(+ %1 %2) (list 1 2 3 4 5))
(reduce + (list 1 2 3 4 5))

I może dzieje się podobnie z innymi językami?

addOneList' lst = map (\x -> x + 1) lst
addOneList'' = map (+1)

Powyższy kod to haskel i tylko wydaje mi się, że wiem co on robi bo przekleiłem go z netu. Istnieje możliwość, że gdzieś tam tworzy monadę 7 poziomu - grupowa infrawizja, +3 do rozpraszania meetingów.

KolonKolon - język zwinny

Ostatnio taka ciekawa rzecz się pojawiła - co się dzieję jak za bardzo przesadzimy z abstrakcjami i faktycznie wszystko jest obiektem?

val a:Any=List(1,2,3)
val res=a match {
    case x : Int => "haaaaaaaaa"
}

I to się kompiluje bo typ jest Any i kompilator nie ma tutaj za dużo do powiedzenia ale już w Runtime

Exception in thread "main" scala.MatchError: List(1, 2, 3) (of class scala.collection.immutable.$colon$colon)
KoląKolą

Otóż okazuje się, że mamy dwa ciekawe kawałki kodu składające się z samych dwukropków - po pierwsze metoda w List :

def ::[B >: A] (x: B): List[B] =
    new scala.collection.immutable.::(x, this)

To dzięki niej możemy sobie pisać :
1::2::Nil
Ponadto w ciele metody :: tworzona jest nowa instancja obiektu ::

final case class ::[B](override val head: B, private[scala] var tl: List[B]) extends List[B] {

i to dzięki tej klasie działa taki pattern matching :

val list=1::2::Nil

list match {
  case 1::2::Nil => "hahaha"
}

I takich konstrukcji jest więcej (np $hash$colon$colon w Stream czyli #::) - z tego co pamiętam w javie nazwy mogą zaczynać się od literki, dolara lub podkreślnika no i scala obchodzi to ograniczenie mapując :: z kodu w $colon$colon. Czytelne?

I znowu dwie strony medalu - jak ktoś ma clean code na półce (w sumie ja mam) to może się łapać za głowę bo kto to widział nazywać metody "::" ale jak się trochę porobi, następuje czas ekspozycji to taki zapis "1::oldList" naprawdę momentami "staje się" czytelniejszy od List.builder.add(1).add(2) , "oldList.prepend(1)" czy coś w ten deseń.

I druga ważna rzecz, ta cała konstrukcja :: to twór biblioteki a nie języka i w w tym jest właśnie siła Scali- w łatwości dodawania nowych konstrukcji.

CZAS NA METAFORĘ :

  • Jest siekiera - trzeba ściąć drzewo by zrobić papier
  • Generalnie chodzi o produkcję zwykłego papieru - ktoś przynosi pilę mechaniczną i uderzamy nią w drzewo jak siekierą - siekiera działała lepiej
  • Generalnie chodzi o stworzenie jakiegokolwiek papieru - ktoś daje nam maszynę wytwarzającą papier syntetyczny - uderzamy nią w drzewo - wniosek siekiera cały czas działa lepiej
  • Generalnie chodzi o stworzenie medium do wyświetlania znaków - ktoś przynosi tablet - uderzamy nim w drzewo - stara dobra siekiera cały czas działa lepiej.

Czy ta metafora ma sens? Nie wiem ale można sobie poczytać jak użyto Scali w Sparku :

  • https://databricks.com/blog/2015/04/13/deep-dive-into-spark-sqls-catalyst-optimizer.html
  • https://databricks.com/blog/2014/06/13/application-spotlight-typesafe.html
  • http://apache-spark-user-list.1001560.n3.nabble.com/Why-Scala-td6536.html

Podsumowanie

Czy można jasno stwierdzić, które znaczki są dziwne a które nie? Niemowlę wyciągnięte dopiero co ze świata Javy na pewno znajdzie zapewne trudność w odczytaniu takich zapisów _+_ czy #:: ale równie dobrze rasowy programista haskella może przeżyć szok gdy zacznie pisać w Javie i nagle

"Ej.. stary... o co tu chodzi... tutaj musisz stawiać w każdej linii ten znaczek... no to... ; ... to jest maksymalnie dziwne..."

Tak czy inaczej trzeba dać językowi szansę bo z czasem tak jak w tym matrixie będzie można odczytywać co tam spada na tym ekranie

niedziela, 24 maja 2015

Zachęta do robienia warsztatów + starter do Sparka

W Łodzi życie IT wydaje się rozkwitać (mimo , iż ludzi tutaj coraz mniej), jest kilka grup tematycznych i nawet specjalny tag #nowldz, który ma wszystkie zgromadzić i w jasności związać. Pomimo tego w porównaniu do niektórych miast relatywnie daje się odczuwać pustkę społeczno-informatyczną.

Powodów tego stanu rzeczy jak zwykle jest wiele - wiadomo czas, energia i te sprawy. Ale jest jeden powód dosyć ciekawy i to o nim chcę opowiedzieć - nazwać go można irracjonalny wewnętrzny opór. Wiele zdolnych osób uważa, że nie jest jeszcze gotowa aby poprowadzić warsztat, że mają za małą wiedzę itd - a wcale tak nie jest - oj nie!

Najpierw trochę tekstu a później będzie jeszcze więcej tekstu po czym nastąpi podsumowanie w formie tekstu (i na koniec jakiś kod)

Umieć ale nie umieć

Poniżej ponowne odkrywanie Ameryki czyyli kilka linków z wytłumaczeniem dlaczego to jest naturalne, iż ludzie boją się nazwijmy to takk ładnie "ekspozycji przed grupą ludzi". Linki wkleiłem po tytułach i te tytuły wydają się brzmieć sensownie ale już nie chciało mi się czytać tekstu także mam nadzieję, że zawartość jest zgodna z nalepką :

I nie ma co tłumaczyć, że to nie jest już potrzebne w 21 wieku, że jaskiniowcy, że sratata bo to ma taki sam sens jak tłumaczyć zasadę działania mięśni i oczekiwać, ze ktoś po takim wykładzie będzie nosić szafy. Natomiast ma sens wytłumaczenie metodyki ćwiczeń i oczekiwanie rezultatu po odpowiednio długim czasie owej metodyki stosowania.

Metodyka ćwiczeń

Jakaś tam teoria

To znowu temat rzeka ale w bardzo dużym skrócie -

  • Istnieją pewne naturalne instynkty, z którymi ludzie się rodzą - np. reakcja obronna na bardzo głośny dźwięk. Strach przed ekspozycją na grupę jest również naturalnie zakorzeniony
  • Jeśli bodziec jest stopniowany i następuje faza odpowiedniej "regeneracji" wtedy system nerwowy się adaptuje do coraz większej siły bodźca :
    • Czyli np. może pojawić się taki stan "dysocjacji" kiedy to niejako uczestniczymy w sytuacji z perspektywy trzeciej osoby, dzięki czemu nie następuje reakcja obronna, która blokuje kreatywne reakcje na nieoczekiwane sytuacje i ogólnie "samo nam wychodzi"
    • Znowu jak bodziec będzie za duży to na siłce wystąpi kontuzja, którą musi leczyć specjalista, a na gruncie psychicznym również wystąpi kontuzja zwana "traumą", której leczenie lepiej też powierzyć odpowiedniemu specjaliście

Oczywiście jestem tylko informatykiem i powyższe może nie być zgodne z rzeczywistością ale taki podkład teoretyczny był i jest dla mnie przydatny.
A jak stopniować bodziec ?

  • Na siłce to będzie systematyczne dokładanie obciążenia z treningu na trening - warto mieć karteczkę i sobie notować ile żelaza poszło w danej sesjji
  • W przypadku warsztatów - bo o tym miała być mowa - należałoby najpierw zrobić coś dla kilku znajomych. W tej sytuacji mamy już jakąś tzw. "wartość społeczną" i jak coś się nie uda instynktownie czujemy, ze nic wielkiego się nie stanie (pod warunkiem, że znajomi nie są z tych tzw. "toksycznych")
  • Później włączać włanczać do grupy odbiorców osoby obce. W tym przypadku wartość społeczna wynosi 0 i wszelkie zjebki zsuną nas na poziom ujemny - co jest dodatkowym stresorem. I do tego trzeba się przyzwyczaić by nie panikować i wydostać się na powierzchnię - znowu kilka razy się pewnie nie uda po czym nastąpi adaptacja systemu nerwowego.
  • Kolejnym elementem krytycznym jest wystąpienie przed ludźmi z potencjalnie większą wiedzą od nas samych - podświadomie wyczuwamy możliwość wystąpienia trola.
  • I chyba największym hardkorem byłoby wyskoczenie z prezentacją o zajebistości Javy na konferencji Microsoftu - tudzież w programie "młodzeż rzuca kamieniami w polityków"

Wszyscy myślą o sobie tylko ja myślę o mnie!

Inna ciekawą sprawą jest to, ze jak już coś się stanie to często kolejne wystąpienia tego czegoś przestają już być tak straszne. Nie znam dokładnej teorii ale coś mi się obiło o uszy a propo terapii "intensywnych bodźców" czy coś takiego.

Np. robimy warsztaty i boimy się (co jest naturalne), że coś pójdzie nie tak. No i na szczęście udaje nam się raz za razem, mamy pasmo udanych warsztatów - czy aby an szczęście? Niekoniecznie bo być może działamy zachowawczo przez co warsztaty tracą na wyrazistości a my nie osiągamy kolejnego poziomu.

W 2013 razem z kolegą Wojtkiem robiliśmy cykl wystąpień o Amazon AWS. Były dwa wystąpienia na targach pracy lokalnie w Łodzi. Później pojechaliśmy na 4Developers z tym samym tematem i generalnie zawsze się udawało. Ale czy na pewno udawało? Generalnie wtedy kuliśmy na blachę co każdy ma powiedzieć na którym slajdzie, było mało elastyczności ale generalnie jako, ze byliśmy przygotowani to to co chcieliśmy przekazać - przekazaliśmy - ale było trochę szaro a wszystko dowcipy zostały zawczasu przygotowane w laboratorium.

No i nastała konfitura 2013, stwierdziliśmy, że trochę zmienimy kontekst i z prezentacji "jak działa AWS" zrobimy taką w stylu "jak AWS zmienił naszą firmę". I na skutek koniunkcji zdarzeń losowych nie zdążyliśmy przygotować się naszym klasycznym sposobem nauki wszystkiego na pamieć - postanowiliśmy improwizować.

No i prezentacja wyszła raczej do dupy. Kilka osób coś tam miłego napisało jakkolwiek reszta słusznie wspomniała, że było raczej do dupy, "najgorsza prezentacja roku" i takie tam słodkie epitety.

No i mieli w sumie rację ale ciekawe jest to co stało się później. Następnego dnia słońce wstało i kolejnego dnia także i tak dalej i dalej. W zasadzie to nic się nie stało takiego złego (poza tym ,że zmarnowaliśmy kilku osobom parenaście minut życia). Natomiast ciekawie zmieniła się moja percepcja. Mózg zdał się zauważyć - "to tylko tyle? Nie będę ładował w ten strach tyle energii!!Są ciekawsze rzeczy, których można się bać!"

Jakieś blokady padły i zniknął u mnie strach przed eksperymentowaniem z różnymi formami wyrazu czy też pojawiła się chęć wprowadzania wariacji i eksperymentowania - np. co się stanie gdy wezmę podwójną dawkę przedtreningówki przed prezentacją (nie stanie się nic dobrego - dop. autora)

Inna sprawa to, że już nie jestem taki wybredny przy ocenie wystąpień i prezentacji bo zrozumiałem jakie to jest trudne. Kiedyś podobnie jak wiele osób dużo narzekałem i komentowałem. Teraz jestem na poziomie tzw. niekompetencji świadomej - czyli wiem, że nie wiem zaś wiele osób jeszcze nie zdaje sobie sprawę, że nie umie prezentować przez co łatwiej im jest dawać surowsze oceny. Sytuacja podobna do tej jak np. koleś z brzuchem i browarem siedzi na kanapie, ogląda mecz i z pełnymi ustami krzyczy "nozes ku**a biegnyj do tej pilki, no coz za patalachhy. Uff ale sie zapowietrzylem"

Teraz będzie ważny fragment

Paradoks eksperta - strach przed utratą pozycji społecznej

To jest jeden z ważniejszych eksperymentów w psychologii - gdy chwali się dzieci za wysiłek wierzą w siebie i podejmują ryzyko ucząc się efektywniej oraz pracując ciężej. Gdy chwali się je za zdolność wtedy działają zachowawczo i nie podejmują ryzyka tak jakby nie chcą aby przypadkiem się okazało, ze nie są zdolni.

Z poniższymi linkami akurat polecam się zapoznać bo są niezwykle ciekawe i życiowe:

Mam swoja teorię zebraną z tysiąca innych, która może tłumaczyć dlaczego tak się dzieje ale o tym są całe książki. Generalnie można rzec, iż osoby które osiągnęły pewien status, mają doczepioną etykietę "dobrego specjalisty w jakiejś dziedzinie" i boją się, że na skutek ponownej reewaluacji ten status stracą - to się doskonale komponuje ze strachem przed oceną grupy i mamy zabójczy tandem powstrzymujący nas przed działaniem.

Tutaj może pomóc tzw przeramowanie - http://en.wikipedia.org/wiki/Cognitive_reframing

Ja np. nie robię warsztatów ze Scali w kontekście "specjalista radzi" ale w kontekście "sam jej nie znam to przygotuję kilka warsztatów by się jej nauczyć". ( Co więcej to jest główny powód dla którego robię te warsztaty - niestety projektów Scalowych jest w Łodzi jak na lekarstwo toteż taka forma nauki wydaje mi się bardzo dobra - atakowanie tematu z wielu stron, analiza introwertywna i ekstrawertywna i jeszcze kilka mądrych słów. )

I to jest właśnie piękny paradoks - nie mogę stracić żadnej wartości społecznej bo z założenia żadnej nie mam! - stresu zero! Oczywiście zależy mi bardzo na tym aby wszystko było dobrze przygotowane i ludzie zdobyli jak najwięcej umiejętności bo głęboko wierzę, że wraz ze wzrostem wiedzy eksperckiej Łódź przestanie być "fabryką risorsów do utrzymywania muzealnych wersji Javy". Im mniej do stracenia tym mniej stresu - ot taki paradoks.

TL;DR

Podsumowując - bezpieczna i bezstresowa "RAMA" czy prościej nastawienie by nie stresować się warsztatem - "ja nie umiem i wy nie umiecie - to ja coś przygotuję i pouczymy się razem". I wydaje mi się, ze tym modelem każdy może jechać - jak już pisałem w Łodzi zdolnych ludzi jest masa - także śmiało!

Scala i Spark

Dalej w kontekście warsztatów ale już z lepszym stosunkiem kodu do słowotoku. Czego nauczyłem się wczoraj robiąc warsztat na cybercomdev? Plan był prosty : najpierw pokażemy, ze immutable jest fajne, potem, że fajnie jest w Scali wspierane następnie będziemy przeskakiwać od programowania imperatywnego do deklaratywnego i TADA!! - funkcje wyższego rzędu.

I mamy takie reduce bo wydawało mi się, że to prościej wytłumaczyć niż fold gdzie pojawiają się dwie pary nawiasów.
List(1,2,3).reduce((a,b)=>a+b)
List(1,2,3).reduce((a,b)=>a*b)
- i pada pytanie- a co się stanie jak lista będzie miała jeden elemen?
- (hehe zaraz im wytłumaczę, ze to nie dwa elementy ale akumulator) - bo widzisz bo to jest akumulator, który akumuluje wynik działania. - no ale co w nim jest? - (hehe no zero) - no zero - ale to by i przy mnożeniu wyszło zero a wyszło jeden... - (eeee...) I teraz zaczyna się ciekawy ciąg zdarzeń. JAk sobie zanurkujemy do kodu :
 def reduce[A1 >: A](op: (A1, A1) => A1): A1 = reduceLeft(op)
Czyli woła reduce left i co tam jest?:
 def reduceLeft[B >: A](op: (B, A) => B): B = {
    if (isEmpty)
      throw new UnsupportedOperationException("empty.reduceLeft")

    var first = true
    var acc: B = 0.asInstanceOf[B]

    for (x <- self) {
      if (first) {
        acc = x
        first = false
      }
      else acc = op(acc, x)
    }
    acc
  }
To jest co najmniej interesujące! Akumulatorem będzie zawsze pierwszy element ale... co.. to.. jest : var acc: B = 0.asInstanceOf[B] ??

Ta linijka doczekała się własnego wątku na stackoverflow : http://stackoverflow.com/questions/8465356/what-is-happening-with-0-asinstanceofb-in-scala-reduceleft-implementation . I jak ktoś będzie chciał poczytać to dokładnie zrozumie jakie cuda mogą dziać się na granicy kompilacji i runtime (po polsku rantajmu).

Spark

Za tydzień zaczyna się online kurs Sparka - https://www.edx.org/course/introduction-big-data-apache-spark-uc-berkeleyx-cs100-1x - Spark to jeśli ktoś nie wie to takie coś co ma zabić hadoopa.

kupiłem sobie spark in action, teraz jest MEAP v2 i nawet taki hello world przykładowy projekt - ale on jest w mavenie... :

"Ale dlaczego nie użyjesz mavena??"

Są jakieś gotowce z SBT w activatorze ale generalnie wystarczyło wrzucić takie coś

libraryDependencies ++= Seq(
  "org.apache.spark" %% "spark-core" % "1.3.1",
  "org.apache.spark" %% "spark-sql" % "1.3.1"
)
i wio
object HellloSpark {

  def main(args: Array[String]) {
  val conf=new SparkConf().setMaster("local").setAppName("nauka")
  val sc=new SparkContext(conf)
  val file: RDD[String] =sc.textFile(readTestFilePath)
  println(file.count())

  }

  def readTestFilePath: String = {
    val path=Paths.get(getClass.getClassLoader.getResource("InputFile.txt").toURI)
    path.toString
  }
}

Ten kurs na edx ma być chyba głównie z Pythonem czyli będzie też ciekawe ćwiczenie by zadania poprzerabiać na scalę

I jeszcze taka ciekawostka gdzieś się jeszcze napatoczyła : - http://0xdata.com/product/ (i patrz i znowu scala - ) - może się przydać.

niedziela, 17 maja 2015

Myśl jak inżynier + slajdy z geecona

Myśl przewodnia - myśl inżyniera

Aby nie relacjonować sucho slajdów z geecona stworzymy sobie jakąś myśl przewodnią artukułu, a skoro myśl na myśl to będzie o tym jak powinien myśleć inżynier.

Wiele osób w trakcie codziennych lektur przebiega tylko pobieżnie wzrokiem po nagłówkach budując w sobie jedynie symboliczną wiedzę odnośnie technologii i narzędzi. Myślenie symboliczne znacznie różni od inżynieryjskiego ale zanim do tego przejdziemy momęcik uwagi dla trolli ortograficznych. Nie wiem czy poprawnie piszę się "myśl inżynieryjska" czy "myśl inżynieryjna" czy "myśl inżynierska" ale google zwraca najwięcej dla "myśl inżynieryjska"

  1. "myśl inżynieryjska"
  2. "myśl inżynieryjna"
  3. "myśl inżynierska"
1
2
3

Czyli co dokładnie

Myślenie symboliczne na którym funkcjonuje większość ludzi to np :

  • wezmę noSQL i nie mam problemów ze skalowalnością
  • wezmę język funkcyjny i nie mam problemów z wielowątkowością
  • wezmę ORM i nie mam problemów z bazą danych

A jeśli tych przykładów jest mało to weźmy coś z życia. Np jedzenie :

  • sportowcy działają na poziomie makro składników /ilość kalorii/ilość białka/ilość tłuszczy/ ilość witamin/ilość minerałów. Wiedzą jak w danym momencie dnia ich organizm zareaguje na jakie składniki odżywcze i rozumieją jak inaczej działa ich metabolizm w kontekście danego cyklu treningowego.
  • Stefan Kowalski działa na poziomie kotleta schabowego a konkretnie posiłków /śniadanie/obiad/kolacja (a obiad z dwóch dań... bo ... obiad je się z dwóch dań bo tak!)
  • Czasem ludzie w symbolice bycia FIT jedzą 5 posiłków dziennie.. bo tak. Mistrzostwem było jak raz w tesco usłyszałem reklamę aby jeść 5 razy dziennie actimelki bo tak 5 posiłków jest na zdrowie

Zostańmy przy śmiesznych produktach FIT. Kto dokładnie patrzy na skład a kto tylko an symbol na opakowaniu klasyfikujący coś jako FIT? Takie coś widziałem w życiu. Kolega o dosyć pokaźnej tuszy pije sobie kolorowy napój, który ma w nazwie coś tam SLIM. Już sam fakt, ze kolor napoju nie wysptęuje samoczynnie w naturze powinien dać coś do myślenia ale idźmy dalej.

W składzie była mikroskopijna dawka LKarnityny, która niby pomaga w transporcie tłuszczu do mitochondriów. W praktyce raz, ze jest to dyskusyjne a dwa to podobne i tak łykanie teog w postaci suplementu nie ma sensu bo zanim ona trafi do krwi to w większości zostanie zneutralizowana w procesie trawienia. ale nie to jest najlepsze, napój był "o smaku" co oznacza, ze zawierał cukry. Tych cukrów w postaci etykiety "węglowodany" było tam sporo (nie licząc całej kolekcji E123). Cukry proste nazywane są prostymi dlatego, ze są szybko trawione i powodują wyrzut insuliny, który zamyka tłuszcz w komórkach. Także jedyne FIT w tej sytuacji to kondycja finansowa producenta napoju.

A teraz będzie prawdziwe mistrzostwo słyszałem na siłce historie jak to laski wynajmują sobie trenerów, wpadają 40 minut na bieżnie stąpając krokiem wczasowym (czasem towarzyszy temu relacja z ostatniego m jak miłość). Gdy padnie jakaś wzmianka o diecie mówią zdziwione, że przecież były na siłowni, dbają o siebie to mogą teraz w nagrodę walnąć pizzę z 4 browarami. Trudno mi wytłumaczyć skąd to się bierze bo nie mam dostępu do tych rejonów mózgu.

Zresztą na symbolice działa cały przemysł reklamowy, jak opie*dolić za 4 zł pół pokrojonego ziemniora? Trzaśnij scenkę dla samotnych ludzi, jak to znajdą sobie od razu przyjaciół gdy tylko otworzą paczkę czipsów. Albo reklama samochodu gdzie tam koleś z trzydniowym zarostem popitala samochodem po placu, niebo jest niebieskie a wszyscy patrzą z zazdrością - w praktyce to jest tak , że jak kupimy sobie np nowoczesne kombi to mamy do ogarnięcia większą powierzchnię na jaką padają gówna gołębie
Według wzoru : Ts=Pd*Is (Ts- czas sprzątania, Pd - powierzchnia dachu,Is - ilość starych sąsiadek, które dokarmiają gołębie starym chlebem)

Inny przykład myślenia magicznego, który jest trochę naiwnym i niebezpiecznym narzutem swiata korporacyjnego to wszędobylski efekt aureoli - jak np. koszule na rozmowie kwalifikacyjnej. "Jak kandydat ma plamę to znaczy, że..." to ch** znaczy - może mieć plamę i zajebiście programować.A jak zapnie się pod szyją i ściśnie krawatem to mu nawet tlen może do mózgu nie dochodzić .Pamiętam 50 stronnicowe dyskusje na goldenline w grupie Tom Managier o tym czy dawać stopień naukowy na wizytówce i o tym jakie mankiety do jakiej koszuli.

Na razie widziałem tylko jedną firmę IT, w której patrzą na ciebie dziwnie jak przychodzisz w garniaczku - i to jest bardzo dobra developerska firma. Bo jak np. zamawiamy hydraulika i on wpadnie w garniaku to coś jest nie tak - całe życie prowadził szkolenia, ze rąk sobie nie pobrudził?

A i na koniec dosyć ciekawy przykład - generalnie bieganie niekoniecznie musi być zdrowe a już na pewno może paradoksalnie prowadzić do większego zatłuszczenia. Ale to już kto chce sobie poszuka.

No i Scala. To też jest przykład myślenia magicznego zarówno ludzi, którzy chcą jej używać i nie wiedzą dlaczego jak i ludzie, którzy nie chcą jej używać i też nie wiedzą dlaczego. Generalnie lepiej by dzieciaki się za to nie brały bo tylko wygenerują więcej przypadków jak to "scalowe projekty się nie udają" z czego będą czerpać garściami przeróżni hejterzy.

Ogólnie FP to teraz taka magiczna pigułka. Nie wiem jak będzie to wyglądać z FP ale podobno wychodzimy z epoki dominacji OOP a ja chyba w życiu widziałem zaledwie kilka osób, które OOP używały poprawnie. Generalnie problemem jest bardziej analfabetyzm programistyczny aniżeli to jakiego paradygmatu się używa (wzorzec Manager+Helper żondzi).

No i wracając do geecona. Generalnie szacun dla organizatorów bo wiem ile pracy jest przy jednodniowej mobilizacji i ile rzeczy może się nie udać a tutaj jest 3 dniowa konferencja + warsztaty i 10000 rzeczy do ogarnięcia.

I tutaj też pojawia się przykład myślenia magicznego samych uczestników konferencji. Siedzimy sobie z takim jednym grubym w bistro pod multikinem i jest rozmowa o tym jak ciężko taką konferencję zrobić i jak ludzie, którzy tylko "konsumują"takie wydarzenia tego nie doceniają. Ale mija 10 minut i już w samochodzie gruby spaślak narzeka, ze ktoś tam nie przyjechał i on musiał siedzieć 5 minut na wykładzie. No biedny gruby biedny.

Ale tu gadu gadu a czas na kilka slajdów

Trochę slajdów

Matematyka i Cassandra

Było o algorytmie HyperLogLog - fajnie się nazywa i ciekawie działa. Oblicza jedynie przybliżenie liczebności zbiorów. To nie robi się magicznie tylko matematycznie.

Dalej było o czymś co chyba nazywa się "rodziną protokołów paxos" -> http://en.wikipedia.org/wiki/Paxos_%28computer_science%29
Generalnie gościu mówił, że czytał oryginalny artykuł naukowy kilka razy zanim to ogarnął i to tam działa pod spodem. Jeśli bedziesz używał Cassandry może się na to natkniesz - może wtedy magia pryśnie.

Cassandra+Spark - znowu nie zrobi się to automagicznie. Albo będzie poprawna konfiguracja - albo przesyłanie petabajtów danych w tę i na zad.

W czym jest napisana Java?

Java jest napisana w C++. Nie ma tam magii ale dużo kodu sprawdzającego na jakiej architekturze JVM działa. Jest kilka haków i dziwnych instrukcji. Prezentacja zeszła znacznie niżej niż standardowe omówienie modelu pamięci JVM. Ile osób wie na jakiej zasadzie działają bariery pamięci? Czy może w większości przypadków "serwer magicznie działa"? Zrobimy sobie ThreadLocal a później jebudu nie ma pamięci.

Jak szybkie są Streamy?

Wielowątkowe kolekcji robi się prosto :
Ale to nie działa bo for jest szybszy
A wcale nie :
A distinct jest wolne
Chyba, że jest unordered :
Ale i tak wszystko się zmienia jak zmienimy kompa
Pomiary Inżynier - rób pomiary!

Hype na Sparka

Na to chyba hype się jeszcze nie zaczął ale warto pamiętać, że jak robimy filter przed groupBy to po kablu może i kilkaset Terrabajtów mniej polecieć.

Przyśpieszanie JVMa ze znajomością krzemu

Kto rano wstaje - ten rano wstaje. Pracując dla kraju - pracujesz dla kraju. Osiągając 100% utylizacji procka...
... osiągasz 100% utylizacji procka i poza dobrym grzejnikiem być może nic innego nie uzyskujesz.
A tam w środku są fajne rzeczy
I podobno po kilku latach pracy faktycznie da się czytać te pomiary.
Ale gimby nie znają

Programowanie funkcyjne wszystko naprawi

I znowu można pozostać w świecie magii albo ogarnąć choć trochę co tam pod spodem się dzieje.

G1 - autotuning

Autotuning - do czasu aż nie zadziała i trzeba będzie jednak zrozumieć jaka mechanika stoi za magią -ale spoko są logi

Slajd na koniec

Na koniec slajd do pokazywania wszystkim którzy twierdzą, że nie muszą się zagłębiać w programowanie wielowątkowe.

niedziela, 10 maja 2015

In,Co,Contra - variance - Mem driven Learning

Z tematem po raz pierwszy zetknąłem się prawie dwa lata temu - http://pawelwlodarski.blogspot.com/2013/08/covariance-i-contravariance-dla.html i był to jeden z tych momentów kiedy zrozumiałem, że jeśli znam Javę i Springa to nie oznacza, że mogę twierdzić, że umiem programować.

W oryginalnym artykule sam próbowałem zrozumieć ten temat +A,-A,A, a że najlepsza nauka to próba wytłumaczenia komuś tego czego nie rozumiemy toteż to było pierwsze podejści. Do tego by pobudzić rozrywkowe obszary mózgu próbowałem użyć odpowiednia ilość razy słowo Dupa w kontekście domeny żłopu alkoholowego.

A że chlanie wódy to nie do końca zdrowe zajęcie plus jak jest za dużo tekstu to nikomu nie chce się czytać to spróbujmy innego podejścia.

The Box

Nie chodzi o film z Cameron Diaz z 2009, który opowiadał o złudnym poczuciu braku konsekwencji z samolubnych wyborów - http://www.imdb.com/title/tt0362478/

Generalnie te wszystkie ...variance tłumaczy się w kontekście typu, który jakoś opakowuje lub jest parametryzowany przez inny typ- M[T]. Na przykład Option[A],Try[A] czy List[A]

Przykład z listą jest niby wytłumaczyć najprościej bo to jest też w javię w cudownej postaci List<? extends User> czy List<? super User>. Co wygląda trochę dziwnie ale jest.

Natomiast w kwestii Coś opakowuje coś ludzie zapominają o klasyce :

Dla tych, którzy nie znają angielskiego "Dick" to imię wieloryba z przygód "Janka Muzykanta" http://www.filmweb.pl/film/Moby+Dick-1956-32061

Mem Driven Learning