Pokazywanie postów oznaczonych etykietą DevCrowd. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą DevCrowd. Pokaż wszystkie posty

środa, 23 kwietnia 2014

DevCrowd 2014

W tym roku udało mi się ponownie (bo po raz drugi) zawitać na konferencję DevCrowd do Szczecina. Nie jest to kolos kalibru GeeCona czy 33rd Degree, ale tworzy ona swój własny specyficzny klimat. Przygotowano nawet aplikację na androida, pomagającą w podjęciu decyzji, na którą prelekcję wybrać się aktualnie. A do wyboru były dwie równoległe ścieżki.

Rozpoczęcie konferencji przeciągnęło się mocno, przez co do obiadu wszystkie wystąpienia zostały przesunięte o kilkanaście minut. Na szczęście po obiedzie wszystko wróciło na swoje miejsce.

Na początek udałem się na prezentację Macieja Opały i Wojtka Erbetowskiego pt. Designing API for Mobile App. Jak więc projektować serwerowe API dla aplikacji mobilnych? Przede wszystkim z powodu powolnych łączy komórkowych, problemów z zasięgiem, przemieszczania się użytkownika, należy ograniczyć liczbę przesyłanych danych do minimum. Jeśli wystawiamy po stronie serwerowej RESTa, to lepiej jest przesyłać dane za pomocą JSONa niż XMLa. W przykładzie prelegentów, pozwoliło to na zmniejszenie wielkości wiadomości o 37%.

Warto również korzystać z Cache’a Http po stronie serwera, jak i Androida. W telefonie można w tym celu skorzystać z tych narzędzi: retrofit, OkHttp i HttpResponseCache. Dobrym sposobem na zmniejszenie rozmiaru paczki danych przesyłanej przez sieć, jest skorzystanie z kompresji GZIPa. Trzeba jednak uważać, gdyż dla małych plików, może ona nie opłacać się.

Przedstawiony był również problem wersjonowania naszych Interface’ów. Wynika on z opóźnionego aktualizowania aplikacji na telefonach użytkowników, czyli mogą wymagać starego API. Najlepiej, aby się ono nie zmieniało, ale najczęściej jest to niemożliwe. I tak można podawać Path parameter (np. http://api.example.com/res/v1) media type (lub custom header) (np. http://api.example.com/res+v1) albo subdomenę (np. http://v1.api.example.com/res). Wszystkie rozwiązania posiadają jednak swoje wady.

Na koniec wspomniano jeszcze o narzędziu Swagger, do tworzenia dokumentacji (coś ala javadoc) dla RESTowych aplikacji.

Zawsze bałem się prezentacji, gdzie jest dwóch prelegentów. Najczęściej oznaczało to, że prowadzący zbytnio nie znają się na temacie, lub mają opory przed wystąpieniami publicznymi. Tutaj jednak wypadło to dobrze i sprawnie.

Na drugą prezentacje wybrałem wystąpienie Mateusza Kaczmarka pt. Good design makes us happy – czyli podejmij tę decyzję za mnie. Na początku Mateusz polecał książki, od których wszystko się u niego zaczęło, czyli pozycje Dona Normana (nie pamiętam którą dokładniej) i Steva Kruga Don’t Make Me Think. Na zajawkę zamieszczam prezentację z TEDa tego pierwszego Pana.



Następnie prezentacja była wypełniona przykładami, gdzie zastosowano fajne, udane pomysły, jak i przedstawiono firmowe porażki. I tak Apple swego czasu było warte więcej niż polskie PKB, Amazon stworzył przyjemny proces zakupowy, Google uznało, że wyszukiwanie musi być proste itd. Natomiast w sektorze gier, firma EA zdobyła 2 razy z rzędu tytuł najgorszej firmy roku w USA. A zasłużyła sobie na to, dzięki wypuszczaniu niedokończonych tytułów. Inaczej było w przypadku Diablo 2 i Starcrafta, na które wydawcy kazali sobie dłuuugo czekać, co zostało sowicie nagrodzone. Również Blizzard (wydawca Diablo) pokazał, jak można naprawić swoje błędy. Przykładowo firma zamknęła sklep, za pomocą którego gracze handlowali przedmiotami w grach, gdyż to psuło rozrywkę. I ogłosili to ludzie wyglądający jak gracze, a nie panowie w garniturkach.

Co więc robić aby uzyskać UX User experience? Dla ludzi biznesu trzeba wkładać więcej wykresów do naszych aplikacji, a dla szarych Kowalskich należy upraszać nasze interfejsy graficzne. Dzięki temu użytkownicy czują się bezpieczniej i będą korzystać z naszej aplikacji. Warto też podejmować typowe decyzje za użytkownika, ograniczając mu liczbę opcji do skonfigurowania, gdyż najgorzej to stracić zaufanie użytkownika, a jeszcze gorzej jego pracę.

Prezentacja fajna, aczkolwiek był to raczej wstęp do tematu, który nie jednemu zapewne uświadomił istnienie problemu. Brakowało mi bardziej konkretnych rad i wytycznych, jak tworzyć proste i przyjemne interfejsy użytkowników. Na koniec wspomniano o innej książce Steva Kruga Rocket Surgery Made Easy, traktującej o tym, w jaki sposób tworzyć testy interfejsów na użytkownikach końcowych.

Następnie udałem się na prezentację Koziołka: Jak pracować i nie zwariować. Rozmawialiśmy o tym, co najbardziej wpływa na naszą pracę (a wiec krzesło, klawiatura, dysk SSD, RAM i 2 monitory). Każdego dnia powinniśmy lepiej poznawać nasze IDE, biblioteki i narzędzia. Warto też automatyzować jak najwięcej, gdyż jesteśmy leniwi, a jak nie będziemy musieli wielokrotnie pisać tego samego, to życie będzie przyjemniejsze.

Dalej było o introwertykach, psychopatach, dzieciach autystycznych, mądrej asertywności, drugim znaczeniu słowa SCRUM, potrzebie twardego resetu, śnie i przerywnikach w pracy. Ciekawy był pomysł Koziołka, jak odliczać sobie czas w technice pomodoro. Warto do tego użyć gier na facebooku, w których coś tam po jakimś czasie można zebrać i na nowo posiać. Wymusi to na nas regularne przerwy dla umysłu. Z praktycznych narzędzi, było wspomniane o bibliotece jFairy. która to generuje losowe dane.

Była to fajna i śmieszna prezentacja.

Następnie byłem na prezentacji Bartłomieja Nićka pt. Programista to za mało. Prelegent bardzo chaotycznie mówił i w ogóle nie zrozumiałem ani grupy docelowej, ani celu prezentacji. Było coś o wadach naszego zawodu, wadach samych programistów, jak się dawniej realizowało projekty, a jak się to robi obecnie. Prezentacja bardzo nieudana. Z prezentacji jedynie utkwiła mi różnica miedzy Computer Programer a Software Developer wg. US Bureau of Labor Statistic. A więc:

Computer programmers write code to create software programs. They turn the program designs created by software developers and engineers into instructions that a computer can follow.

Software developers are the creative minds behind computer programs. Some develop the applications that allow people to do specific tasks on a computer or other device. Others develop the underlying systems that run the devices or control networks.

Następnie był smaczny obiad i wystąpienie Pawła Szulca na temat JavaScriptu. Nie wiem czy to był celowy zamysł organizatorów, aby Pawła umieścić zaraz po obiedzie, ale jak dla mnie był to strzał w dziesiątkę! Nieprzerwany potok słów Pawła nie pozwalał ani na chwilę nudy i raczej nikomu nie chciało się spać.

Prelegent przekonywał nas, że JavaScript nie jest Mordorem, którego należy się obawiać, a wystarczy poznać i zrozumieć różnice w stosunku do Javy, to będzie dobrze. Przede wszystkim JS jest językiem funkcyjnym, a nie obiektowym. To, co początkowo przeraża, to możliwość wywołania funkcji z inną liczbą argumentów niż ją zadeklarowano! I tak niezdefiniowane argumenty będą undefined, a nadmiarowe będą zignorowane. W JS każda funkcja posiada lokalną zmienną argumentsktóra to przechowuje wartości argumentów przekazanych nam do funkcji.

Następnie Paweł bardzo fajnie omówił sposoby wywoływania funkcji w JS i czym się one od siebie różnią. A różnią się zazwyczaj kontekstem, na rzecz którego będzie odbywać się wywołanie, tzn. możemy otrzymać coś innego pod lokalna zmienną this. I tak mamy 4 możliwości:

1.    Wywołanie bezpośrednie powoduje, że funkcja otrzyma domyślny context, w przypadku przeglądarki jest to obiekt window
function func() {
    console.log(this)};

func();
// [object Window]
2.    Wywołanie jako metoda. Polega to na przypisaniu funkcji do pola w obiekcie. Dzięki temu dostajemy metodę, którą mozemy wywołać. W tym przypadku jako this otrzymujemy obiekt na rzecz którego funkcja została wywołana.
function func() {
    console.log(this)
}

var variable = {
    property: 'value'
};

variable.method = func;
variable.method();
// Object { property="value", meth=func()}
3.    Wywołanie jako konstruktor, a więc ze słówkiem kluczowym new powoduje utworzenie pustego obiektu (dziedziczącego z prototype). Funkcja ma w takim przypadku za zadania zainicjowanie obiektu, który zostaje zwrócony jako rezultat wywołania.
function func() {
    console.log(typeof(this))
}

var obj = new func('abc');
// object
4.    Wywołanie za pomocą applay() i call(). Przydaje się ta możliwość, gdy nie chcemy kopiować funkcji do innego obiektu, aby nie powtarzać kodu. Podmienimy jednak przez to context, czyli this. Predefiniowana funkcja applay() przyjmuje poza pierwszym argumentem tablicę z argumentami, a call() przyjmuje argumenty osobno (po prostu po przecinku)
function func() {
    console.log(this)
}

var variable = {
    property: 'value'
};

func.call(variable)
// Object { property="value"}
Było jeszcze trochę o Scop’ach, Hoistingu, domknięciach i modułach. Warto swój kod Javaskriptowy testować, np. Za pomocą narzędzi jak jasmine, czy mocha. Warto również testować swój kod statycznym analizatorem, np. JSLint. A jak musimy się na szybko nauczyć tego języka, to warto się zabrać za czytanie 2-giego i 3-ciego rozdziału Secrets of the JavaScript Ninja.

Kolejną prezentacją, na którą się udałem, było wystąpienie Tomka Borka, na temat zaawansowanego testowania. Chciałem początkowo iść na SCRUM, but, ale już miałem dość miękkich prezentacji i potrzebowałem czegoś technicznego posłuchać.

Na początku Tomek przestrzegał, aby nie używać PowerMocka, gdyż jest bardzo czasożerny, gryzie się z narzędziami do testowania pokrycia kodu, rzuca kiepskie wyjątki, a przede wszystkim pomaga początkującym pisać brzydki kod.

Dalej było trochę o adnotacji Parameterized z JUnita i ich alternatywach. Ciekawie wygląda projekt zohhak, którego wcześniej nie znałem.

Prelegent opowiedział jeszcze o paru ciekawych pomysłach, dotyczących testowania. Przykładowo, gdy wystawiamy usługi RESTowe na zewnątrz, to warto sprawdzić, czy te opublikowane interfejsy nie zmieniły się. Co do adnotacji @Ignore, to powinna być przy niej data do kiedy może ona być w teście i dlaczego.

Było jeszcze o narzędziach pomagających ogarnąć nam bazę danych, tj Liquibase, DBUnit i Databene Benerator. To ostatnie narzędzie pomaga generować testowe zbiory danych.

Z innych ciekawych (albo też egzotycznych) narzędzi był wspomniany Sureassert. Działa on tylko z Eclipse i pomaga realizować ideę design by contract i ciągłego uruchamiania testów (czyli coś jak infinitest). Niestety nie jestem fanem podejścia programowania kontraktowego i rozwiązanie działa tylko w Eclipsie.

Było jeszcze wspomniane o trzech bibliotekach, pomagających w skanowaniu naszych klas w celu poszukiwania adnotacji: Scannotation, Reflections i Classindex. Na koniec prezentacji było fajne podsumowanie, pokazujące co było omawiane na prezentacji.

Na koniec organizatorzy konferencji przygotowali niespodziankę, a mianowicie zdalne wystąpienie Adama Bienia z tematem How To Tackle Java EE 7. Live streaming był bardzo dobrze przygotowany, całość była transmitowana przez platformę ustream.tv. Prelegent zmieniał tło na którym mówił i wyglądało to bardzo profesjonalnie. Inne jego prezentacje można obejrzeć tutaj: tv.adam-bien.com.

Widać że Adam ma sporo doświadczenia w tym temacie. Było sporo kodowania na żywo, niewiele slajdów (które są dostępne tutaj), a pytania z publiczności można było zadawać za pomocą twittera. Ciekawe rozwiązanie, aczkolwiek z telefonu trochę dłużej pisze się twitnięcie, przez co było spore opóźnienie w dialogu.

Co do samej prezentacji, to Adam pokazał nam, jak można łatwo i szybko zbudować projekt z wykorzystaniem Javy EE 7. Polegało to na skorzystaniu z archetypu mavenowego i wyrzuceniu połowy domyślnego pom’a. Projekt Prelegent twierdził, że nie powinno się dodawać biblioteki do projektu „na zaś”, tylko w momencie gdy naprawdę są potrzebne. Przez to czas build’a i deploymentu powinien (przynajmniej początkowo) trwać krócej.

Generalnie kodzenia było za dużo i po jakimś czasie człowiek się wyłączał i gubił w kodzie. Dla mnie był to trochę odgrzewany kotlet, gdyż podobną prezentację widziałem na JDD 2012 z tą różnicą, że wtedy była Java EE 6 na tapecie. Jeśli ktoś chce obejrzeć tą prezentację, to jest ona dostępna poniżej:


Na zakończenie było jeszcze zbieranie ankiet i losowanie nagrody.  Konferencja wypadła bardzo fajnie. Brakowało mi jedynie typowo technicznych zagadnień, no ale trudno. Może następnym razem.

poniedziałek, 16 kwietnia 2012

DevCrowd 2012

Ledwo 3 tygodnie temu zakończyło się 33 Degree, a tu już kolejna polska konferencja DevCrowd, tym razem w Szczecinie. Konferencja ta jest całkowicie jest przeciwieństwem tej Krakowskiej, jeśli chodzi o wielkość, prelegentów, atmosferę no i cenę. Nie wiedziałem, czy uda mi się wybrać na tą konferencję, ale rzuciłem temat wśród ziomków i z racji dobrego połączenia ze Szczecinem, uczestniczyliśmy w tym wydarzeniu. Przejdźmy od prezentacji.

Na początku udałem się na prezentację Sebastiana Pietrowskiego na temat programowania funkcyjnego w codziennym developmencie. Sebastian opowiadał, czym są języki funkcyjne, po co to i tak dalej. Było trochę przykładów kodu, co jak można w innych językach zrobić, wzmianka o bibliotece Guava, która kilka pomysłów funkcyjnych stara się zaadoptować w Javie.

Później była jeszcze historia na temat tego, co się stało ze słowem kluczowym GOTO i całego sporu na temat stosowalności tego wynalazku. Ciekawa jest ewolucja tej instrukcji, od assemblera, przez programowanie strukturalne (C), obiektowe i w końcu funkcyjne. W Javie słowo goto jest słowem kluczowym (nie możemy nazwać w ten sposób zmiennej), ale nie ma ono implementacji. Mamy za to break i continue, które pozwalają nam wyskoczyć z pętli. Prelegent się mocno zastanawiał, czy w językach funkcyjnych miało by to słowo kluczowe jakieś sensowne zastosowanie i jakie inne ewentualnie konstrukcje językowe mogą podobną funkcjonalność zaoferować.

Generalnie na prezentacji było trochę mało informacji przedstawionych, spodziewałem się trochę więcej. Może coś więcej bym napisał w tym wpisie, ale z racji wszczesnej godziny wyjazdu nie pomyślalem, aby spakować ze sobą notes. Co do samego prelegenta, to jeszcze musi on trochę poćwiczyć wystąpienia publiczne, gdyż było czuć jekkie zdenerwowanie i prezentacja jak dla mnie byla mało ciekawie prowadzona.

Następnie było wystąpienie Jacka Laskowskiego, którego nikomu chyba przedstawiać nie trzeba, na temat Clojure'a, Jest to temat którym Jacek się od dłuższego czasu zajmuje, opisuje na blogu i przedstawia na konferencjach. Wcześniej raczej z daleka omijałem ten wynalazek, chyba ze względu na składnię pełną nawiasów i moje słabe rozeznanie paradygmatu funkcyjnego. Ostatnio jednak się przekonuję, że trzeba się przyjrzeć temu językowi (a na pewno jakiemuś funkcyjnemu).

Co jest w Clojur'ze takiego wspaniałego? Mnie np. zachwyciła obsługa wielowątkowości, którą przedstawił Venkat na 33 degree (więcej we wpisie: 33 degree 2012 dzień 2). Jacek przedstawił jednak temat w inny sposób.

Jako że na sali byli programiści obiektowi, prelegent starał się porównać byty obecne w Javie do tych które występują w Clojure. I tak w Javie mamy klasy, które posiadają metody, a klasy są agregowane w pakiety. Innymi słowy pakiet to zbiór klas, a klasa to zbiór metod. W programowaniu funkcyjnym mamy funkcje (jako byt podstawowy), które są agregowane w pakietach. Nie wiem czy to poprawne określenie w ramach tego języka, ale to co musimy sobie uświadomić, to to, że odpowiednikiem klasy w programowaniu funkcyjnym jest pakiet. W dalszej części prezentacji Jacek udowodnił tą tezę w kodzie.

Aby dalej zrozumieć temat, prelegent kazał się zastanowić, co robimy w programowaniu obiektowym. Mianowicie tworzymy obiekty, przekazujemy je jako argumenty metod i możemy je również otrzymać jako wynik wywołania jakiejś metody. W programowaniu funkcyjnym możemy funkcję (analogicznie jak obiekt) przekazać jako argument funkcji, zwrócić jako wynik i przypisać do zmiennej (a właściwie do stałej). Porównanie to dało mi sporo do myślenia.

Dalej Jacek kodował na żywo. Pokazał, jak można wywoływać rzeczy napisane w Clojure z poziomu Javy. Można skompilować kod pisany w Clojure do bytekodu, w taki sposób, aby było to widoczne przez klasy Javowe. Do tego automatycznie się generował plik JAR, który już w sobie miał wszystkie potrzebne biblioteki wymagane przez Clojure. Dzięki temu wystarczy zaimportować plik do projektu i używać po jawowemu. Jacek przez to zachęcał do pisania po kryjomu w projekcie kodu w tym funkcyjnym języku, bo i tak będzie działało. Na pewno duże zdumienie by było podczas review takiego kodu...

Bardzo mi się jeszcze spodobało spostrzeżenie, że wszystkie języki kompilujące się do bytecodu JVM’a, to tak naprawdę dostarczają nam ten sam produkt (bytecode), ale w trochę inny sposób. Tak więc na poziomie bytekodu języki te są nie rozróżnialne! Czy Java jest w tej sytuacji jakoś uprzywilejowana? NIE! Po prostu była pierwszym językiem do generowania bytecodu.

Co do samego wystąpienia Jacka, to poziom jak zwykle wysoki, potrafił zaciekawić słuchaczy, nawiązać dialog z publiką i zmusić ją do myślenia. W tytule prezentacji było o zastosowaniach serwerowych i spodziewałem się prezentacji jakiegoś framework’a Webowego do Clojura, a był pokazany prosty serwerek, który odbierał żądania http. Więcej, co pokazał Jacek, możecie przeczytać na jego angielskojęzycznym blogu.

Następnie udałem się na warsztaty ze Scali z Łukaszem Kuczerą (@lkuczera). Były one zaplanowane na 3 godziny plus przerwa obiadowa. Początkowo Łukasz wprowadzał nas do języka, dużo o nim opowiadając. Ja kilka dni przed konferencja poczytałem trochę i coś tam napisałem sobie w Scali, aby nie być całkiem zielonym. Dzięki temu na części wprowadzającej w język wiedziałem już co nieco, przez co tematy które nie do końca rozumiałem stawały się jaśniejsze. Do tego dostałem w piątek licencję na IntelliJ IDEA, w zamian za opisanie wrażeń z 33 degree. Mogłem więc od razu zobaczyć jak nowa wersja IDEI radzi sobie ze Scalą.

Później był obiad (zapewniony przez organizatorów). Do wyboru były pierogi, lub kurczak, a całość była dostarczona w styropianach pewnie przez jakąś lokalną firmę cateringową. Dzięki temu można było z obiadem iść gdziekolwiek i wraz z Marcinem Saneckim poszliśmy na zewnątrz na słoneczko. Tam już siedział Jacek Laskowski z Sebastianem Pietrowskim na krawężniku (w pobliżu nie było ławek) i zaprosili nas do wspólnego jedzenia.

Jacek bardzo pochwalił moje wpisy na blogu i nakręcił mnie do dalszej aktywności w tym kierunku. Jeszcze inne bardzo ciekawe tematy się wywiązały, ale lepiej o nich tutaj nie wspominać ;)

Po smacznym obiadku wróciliśmy dalej poznawać zakamarki Scali. Nie będę tutaj opisywał cech języka, ani tego o czym Łukasz opowiadał, bo było tego sporo, a jako świeżak w temacie nie chciałbym nikogo wprowadzać w błąd.

Następnie uczestnicy podzielili się na 2 części i zaczęliśmy w końcu kodować. Generalnie był trochę problem z tym co chcemy napisać, ale w końcu postanowiliśmy napisać parsera wpisow na bash.org, który będzie je zapisywał w bazie danych. Tak więc jeden zespół pisał bazę, a drugi (w którym uczestniczyłem) pisał parsera dla podanej strony. Nie poszlo nam zbytnio, polegliśmy na wyrażeniach regularnych i parsowaniu html’a.

Podczas tego szkolenia zdałem sobie sprawę, jak trudno jest poprowadzić warsztat dla nowicjuszy z nowego języka programowania. Jak dobrze przygotować zadania, aby uczestnicy w ciągu kilku godzin mogli coś napisać i wyjść z warsztatów z przeświadczeniem, że się czegoś nauczyli? Odpowiedź na pytanie z pewnością nie jest łatwa. To, że się nie pamięta podstawowych konstrukcji  języka i nie zna jego API, sprawia, że jednak każdy musi w domu sam usiąść z książką / tutorialem i poprostu zacząć pisać. Czy da się zrobić to jakoś podzczas kilkugodzinnego warsztatu? Nie wiem.

Na zakończenie konferencji było jeszcze rozstrzygnięcie konkursów. Firma SoftwareMill zaproponowała konkurs w którym można było wygrać SonyPlayStation3 Vita. Należało podesłać kawałek kodu, który będzie grał w papier, kamień, nożyce. Bardzo fajna akcja, jednak odpadłem w pierwszej rozgrywce. Było jeszcze losowanie 3ch licencji IntelliJ IDEA, ale już mam, wiec nie brałem nawet udziału :P

Wieczorem była jeszcze impreza pokonferencyjna. Dzięki uprzejmości Andrzeja (który prowadził i zgodził się wracać później) uczestniczyliśmy w after party. I tu było mega pozytywne zaskoczenie, gdyż po wejściu do restauracji zobaczyliśmy białe nakrycia stołów i jedzenie. Przez chwile myśleliśmy, że to jakaś inna impreza, ale zobaczyliśmy innych uczestników konferencji (koszulki konferencyjne przydają się do czegoś), a pani kelnerka jeszcze nas w tym utwierdziła. Nie mogłem się nadziwić, gdyż konferencja była w pełni darmowa, a do tego obiad w trakcie i po (można było spokojnie biegac po dokładkę) i dodatkowo sponsorowane napoje (wiadomo jakie). Wielki szacun dla organizatorów, za taką wspaniałą organizację!

Na wspomnianej afterparty było już mniej osób niż na samej konferencji, przez co atmosfera zrobiła się bardziej kameralno - społecznosciowa. Podpowiedź na przyszły rok: trzeba od razu od samego początku złączyć stoły, aby szybciej zacząć integrację z innymi. Może jeszcze warto zastosowac jakieś techniki sprzyjajace integracji? Myślę, że jest to warte rozważenia.

Z udziału w konferencji jestem bardzo zadowolony, zwłaszcza z możliwosci dowiedzenia się jak IT funkcjonuje w innych miastach (Szczecin), podzielenia sie z innymi swoimi uwagami, jaki i z ogólnego uspołecznienia, oraz możliwości spotkania innych branżowych zapaleńców. Podziękowania dla organizatorów, bo jak na darmowy event, to całość stała bardzo wysoko. Do zobaczenia (mam nadzieję) za rok.