Ciąg dalszy mojej subiektywnej relacji z Front-Trends 2010, warszawskiej konferencji poświęconej technologiom webowym.
Część pierwsza jest tutaj.
Piątkowe wykłady
Podobnie jak pierwszego dnia, konferencja miała dwie ścieżki i mogę opisać tylko część wykładów.
Testing JavaScript
Morgan Roderick miał mówić o testowaniu aplikacji JavaScriptowych. Zaczął od wprowadzenia poświęconego zaletom testowania. Opowiedział o katastrofie sondy kosmicznej, błędach aparatury medycznej i paru podobnych przypadkach i rzucił wiele uwag typu potrzebujemy testów bo nie mamy wiedzy z dziedziny problemu czy programujemy, by rozwiązywać problemy realnego świata. Czas mijał, wprowadzenie trwało, monotonny głos wpatrzonego w swoje notatki prezentera usypiał, słuchacze się wiercili... - i tak przez 35 minut.
Później miała miejsce odrobina konkretów: Morgan wspomniał, że z mrowia narzędzi do testowania JavaScriptu wybrał JsTestDriver wspomagając go Sinon.JS. Sala się ożywiła, prezenter pokazał parę wycinków kodu z PubSubJS (systemu publish-subscribe swojego autorstwa) - znowu wpadając w monotonię przy wyjaśnianiu co robią poszczególne operacje - a na sam koniec wykładu zaprezentował kod kilku prostych unit-testów.
Spory zawód, tym bardziej, że Morgan wydaje się posiadać spore doświadczenie i wiedzę - ale jakoś nie trafił z planem i pomysłem prezentacji (i wyraźnie nie czuł się komfortowo ją prowadząc).
Slajdy:
Zapiski z sesji pytań:
- JsTestDriver nie daje możliwości testowania asynchronicznych wywołań,
- by przetestować kod realizujący komunikację z backendami trzeba podmieniać go na zaślepki, obecnie najwygodniej robić to przy pomocy Sinon.JS, które potrafi zamockować cały XmlHttpRequest.
Z sali padły też pochwały Cucumbera i Culerity jako narzędzi pomagających budować testy integracyjne.
Reusable Code, for Good or for Awesome
Na wykładzie Jake Archibalda nie byłem i żałuję - wdg. opinii kolegów był interesujący, a poświęcony przede wszystkim zagadnieniu jak zaprojektować dobre, rozszerzalne API.
Na szczęście Jake prowadził już tę samą prezentację na Fronteers 2010 i jest dostępne nagranie wideo:
Jake Archibald | Reusable Code, for good or for awesome! | Fronteers 2010 from Fronteers on Vimeo.
a także slajdy:
(niestety nie wiem, na ile warszawska prezentacja się od powyższej różniła).
Test-first JavaScript
Christian Johansen przeprowadził fantastyczny pokaz programowania sterowanego testami.
Po kilku wprowadzających slajdach przedstawiających autora i przypominających założenia TDD (napisz test, zobacz że się nie udaje, spraw by przechodził, usuń duplikaty) po prostu odpalił Emacsa i zaczął programować.
W przeciągu godziny Christian zdążył zaimplementować od zera sporą
część funkcjonalności live searcha, demonstrując przy tym wiele
możliwości JsTestDriver i Sinon.JS, szczegółowo objaśniając
pisany (autentycznie na żywo pisany a nie wklejany) kod, uruchamiając
testy, naprawiając przewidywane i nieprzewidziane błędy, nanosząc
poprawki według uwag z sali, odpowiadając na pytania i dorzucając
wiele szczegółowych uwag. A na koniec zdążył jeszcze szybko
pokazać Hudsona automatycznie uruchamiającego testy
po git push
.
Padła też propozycja kolejności prac:
- zaczynamy od ogólnego testu całej potrzebnej funkcjonalności (np. tutaj działania całego live searcha),
- upewniamy się, że nie działa,
- zaczynamy budować poszczególne elementarne fragmenty implementacji (Christian budował np. funkcję dokładania listy podpowiedzi do drzewa DOM), po trochu składając je w większe całości,
- przy tym każdą drobną funkcję też zaczynamy pisać od napisania testu (a gdy test już przejdzie, iteracyjnie dodajemy nowe testy aż wyczerpiemy wszystkie ważne elementy funkcjonalności).
Pokaz zrobił na mnie (i nie tylko, Christian dostał długie, gromkie brawa) wielkie wrażenie, jeśli organizatorzy opublikują nagranie, zachęcam do obejrzenia.
Patrz też opis prezentacji na blogu autora oraz skrawki kodu związanego z prezentacją.
Parę szczegółowych uwag zanotowanych przeze mnie w trakcie prezentacji i pytań:
-
JsTestDriver nie działa w kontekście pełnej przygotowanej strony HTML, zamiast tego pisane są specjalne komentarze definiujące potrzebne elementy (np. formularz), nie ma w tej chwili możliwości generowania ich z szablonów (ma się to pojawić) ale można zrobić to raz a dobrze dla wielu testów po prostu umieszczając taki komentarz w procedurze setup.
-
Symulowanie opóźnień (takich jak np. półsekundowe oczekiwanie na aktywowanie się pisanego live searcha) oznaczałoby bardzo długi czas realizacji testów, by tego uniknąć Sinon.JS pozwala oszukiwać timery (
this.clock.tick()
zaimplementowane wsinon.testcase
, które po prostu trzeba wywołać w kodzie testu). -
Łączenie testowania JavaScriptu z testowaniem kodu serwerowego jest mało praktyczne (niech ten kod testują osoby zań odpowiedzialne). W ramach testów definiujemy symulowane odpowiedzi serwera przy pomocy
this.server.respondWith
(gdzie można przypisać różne odpowiedzi różnym URLom). Niestety odpowiedzi trzeba definiować ręcznie, nie ma narzędzia do nagrania odpowiedzi serwera. -
Nie testujemy osobno czy była odpowiedź (albo czy jej nie było), wystarczy w odpowiednim miejscu testu zweryfikować czy aktualna treść odpowiedzi zgadza się z tym co zdefiniowano via
respondWith
. -
Komenda
jsautotest
wykrywa modyfikacje plików i uruchamia odpowiednie testy on save, co jest bardzo wygodne w trakcie edycji. -
Nie należy umieszczać znaczącego kodu w treści strony HTML, dla testów zdecydowanie sensowniejsze jest wynoszenie go do osobnych plików i pluginów.
-
Christian nie używa Selenium, jest ono zbyt mocno związane z DOM przez co bardzo trudno utrzymać aktualność testów. Woli mieć zaufanie do kompletności testów uruchamianych JsTestDriverem.
Christian jest autorem książki Test-Driven JavaScript Development. Na podstawie kompetencji autora spodziewam się, że może być naprawdę ciekawa...
Ciekawostka systemowa: jak widać ze zdjęć, Christian używał Ubuntu - i był chyba jedynym prezenterem korzystającym z Linuksa. Dwie czy trzy osoby miały Windows, cała reszta korzystała z laptopów Apple.
Cross-device applications development
Po wcześniejszych zapowiedziach miałem nadzieję na jakiś pokaz wykorzystania PhoneGap. Niestety, Kamil Trebunia ograniczył się jedynie do przedstawienia suchego wykazu narzędzi umożliwiających tworzenie natywnych aplikacji na telefony przy pomocy standardów Webowych, tj. w HTML i JavaScripcie (a przynajmniej ograniczył się do tego w pierwszej części wykładu, na drugą nie poszedłem). Pomysł radzenia sobie w ten sposób z niekompatybilnością urządzeń - ważny, sama lista - przydatna ale ... w prezentacji nie było niczego, czego nie znalazłbym sam przez parę godzin googlowania (a i prowadzący opisywał omawiane produkty w sposób sugerujący, że większości z nich nie używał).
Cóż, w prezentacji wartościowe były linki, więc je zanotujmy:
- Wholesale Applications Community - organizacja próbująca definiować przenośne standardy dla urządzeń mobilnych,
Narzędzia pozwalające pisać przenośne aplikacje:
-
PhoneGap - generowanie aplikacji z kodu HTML i JavaScript, wykorzystywanie standardowych API W3C, obsługa bardzo wielu urządzeń, open-source, słaba dokumentacja i ciągle kłopotliwa instalacja i używanie - ale szybki rozwój,
-
Titanium Mobile - tylko iPhone i Android (celowe ograniczenie do mocnych smartfonów), bardzo dobra dokumentacja, wsparcie dla natywnych kontrolek UI, API własne (niestandardowe), za to zbliżone do Titanium Desktop więc dające szanse na dzielenie kodu z aplikacjami desktopowymi, także open-source,
-
Corona - tylko iPhone i Android, przeznaczone przede wszystkim do robienia gier, wsparcie dla sprzętowego OpenGL, physics engine, interfejsy do serwisów społecznościowych, własne, specyficzne UI, komercyjne (ale niezbyt drogie) z darmowym okresem próbnym,
-
Airplay SDK - kod pisany w C++ lub Lua, także przeznaczone przede wszystkim do pisania gier, kompiluje binarne programy (na ARM), obsługuje iPhone, Android, Windows Mobile, Maemo i inne (min. konsole), sprzętowy OpenGL, pełne wsparcie dla biblioteki standardowej C++, zaawansowany symulator i debugger działający pod Windows, masa narzędzi przydatnych przy pisaniu gier, produkt komercyjny ale przy ograniczeniu się tylko do iPhone i niewielkiej sprzedaży - darmowy,
-
Rhomobile - Ruby, szeroki zakres urządzeń, licencja MIT albo komercyjna, dostępny hostowany serwis do kompilacji co umożliwia budowę aplikacji bez instalowania narzędzi.
W dalszej części wykładu miały być omawiane przydatne biblioteki, zdążyłem zanotować jQuery Mobile i Sencha Touch po czym nastąpiła przerwa i zdecydowałem się pójść posłuchać o HTML5.
Od siebie dorzucę zauważone niedawno Jo.
Using Data of the Web and offering your own services
Na wykładzie Christiana Heilmana także niestety nie byłem (mam tu trochę żalu do organizatorów, siedząc w sali B nie wiedziałem o zmianie kolejności prezentacji w sali A), a był w opinii kolegów bardzo interesujący. Chris demonstrował, jak przy pomocy JavaScriptu i YQL budował webowe mashupy czyli serwisy wybierające i łączące dane z innych stron WWW dla dostarczenia specjalizowanej informacji.
Niestety, przynajmniej na razie, nie ma w sieci slajdów ani nagrania.
Christian opublikował slajdy:
oraz nagranie swojego wykładu:
Z końcówki sesji pytań zapiszę CORS reklamowany przez jednego z dyskutantów jako właściwsza alternatywa dla JSONP.
HTML5: Right here, right now
Tantek Çelik pokazał parę efektownych zastosowań HTML5 (ruchome cząsteczki, odtwarzanie wideo z wykrywaniem krawędzi, Google Pacman), rzucił krótkie historyczne tło powstania HTML5 z szczególnym uwzględnieniem narastającego podziału między forsującym XMLowe techniki (XHTML, X/Forms itp) W3C a współpracującymi w WHATWG twórcami przeglądarek (in 2004 Apple, Microsoft, Firefox, Opera all agreed, but W3C missed it) a następnie przeszedł do meritum, czyli do systematycznego przeglądu co nowego w HTML5.
Wszystkie nowinki podzielił na:
- takie, na których można polegać już dziś (obsługiwane przez wszystkie nowe przeglądarki, dobrze degradujące się w starych),
- używalne z trudem (dostępne w niewielu przeglądarkach),
- dziwaczne,
- interesujące ale niezbyt ważne,
- warte eksperymentów ale jeszcze niepraktyczne.
Pełen tekst prezentacji jest dostępny, dlatego szczegółów
nie będę przepisywał. Podział sugerowany przez Tanteka jest sensowny i
przydatny, nad użyciem elementów z pierwszej grupy faktycznie trzeba
się zastanowić, choć niektóre rady (np. wprowadzanie <section><div
class="section">...</div></section>
) budzą pewne moje
wątpliwości. Tak czy siak, slajdy warto przeklikać, jest
to dobre zwarte podsumowanie.
Zabawnym elementem prezentacji była demonstracja zachowania pól
<input type="date">
i <input type="number">
w Chrome czy Safari.
Wchodzimy używając Chrome lub Safari na stronę testową i przy (pustych) polach liczby czy daty klikamy strzałkę w dół (lub w górę).
Ciąg dalszy nastąpi(ł)
… i będzie zawierał opis dwóch ostatnich wykładów plus trochę uwag końcowych.
… i zawiera opis dwóch ostatnich wykładów plus trochę uwag końcowych.