niedziela, 1 kwietnia 2012

Firebug Lite vs platformy mobilne

Mnogość platform mobilnych z wolna przytłacza młodych programistów. Niezależnie od wieku i doświadczenia - wszyscy marzymy o tworzeniu rozwiązań działających dobrze i jednakowo na każdej platformie sprzętowej jak i softwarej. Nie inaczej sprawa ma się w przypadku tworzenia aplikacji webowych. Bardzo często problem polega na bardzo drobnych, lecz dokuczliwych różnicach w implementacjach przeglądarek na różne platformy. Osobiście spotkałem się ostatnio z takim problemem w Safari na iPadzie. Zastanawiałem się przez dłuższa chwilę jak przeanalizować dobrze działanie strony na tablecie z jabłkiem. Safari na iPadzie nie dostarcza (a przynajmniej nie udało mi się takiej opcji znaleźć) konsoli JavaScript ani podglądu drzewa dom, tak więc moje opcje były dosyć ograniczone... do czasu uświadomienia sobie, że jest coś takiego jak Firebug Lite. Sam Firebug nie raz i nie dwa uratował mi życie przy tworzeniu aplikacji. Problem pojawił się w momencie osadzenia go na stronie - nie mogłem zmienić w danej chwili źródła strony, tak więc zwykłe osadzenie skryptu nie było możliwe. Chwile spędzone z Google jak zwykle okazały się bezcenne.

Post Paula Horowitza Run Firebug on iPad and iPhone opisuje dokładnie wszystko, co należy zrobić, aby móc korzystać z dobrodziejstw Firebug na tabletach i smartphone'ach. Całość sprowadza się do... utworzenia zakładki w przeglądarce! Chociaż wydajność tego rozwiązania nie powala (skrypt potrzebuje chwili żeby się załadować) lecz daje elastyczność momentu, w którym chcemy z niego skorzystać - w dowolnej chwili włączamy przygotowaną wcześniej zakładkę, zamiast ładować Firebuga razem z całą stroną. Jak dla mnie idealnie rekompensuje to czas ładowania.

To tyle na dzisiaj. Mam nadzieję, że komuś przyda się to rozwiązanie.

Pozdrawiam i do następnego razu!

środa, 21 marca 2012

O podstawach języka JavaScript słów kilka (ponownie)

Temat odgrzewany jak poobiednia kiełbasa. Ale prawda jest taka, że bez dobrej znajomości podstaw danego języka nie jesteśmy (my, w sensie juniorów) w stanie robić czegoś dobrze przez dłuższy czas. Im więcej czasu poświęcać będziemy na nasz kod, tym bardziej będzie się on rozszerzał, a co za tym idzie - rosnąc będzie prawdopodobieństwo, że popełnimy znaczący, trudny do zdiagnozowania błąd wynikający z braku zrozumienia podstawowych zasad rządzących danym językiem. Jestem przekonany, że jeszcze 2 lata temu słysząc, że ktoś boryka się z kłopotami z JavaScript'em parsknąłbym i zapytał - "a co może być takiego trudnego w JS?!". Otóż jak się okazuje wiele rzeczy może być trudnych i nieintuicyjnych, co nie znaczy, że język ten jest zły.

Półtorej roku temu, w trakcie moich letnich praktyk pisałem na blogu o filmiku z serii Google Tech Talks, w którym przez trochę ponad godzinę Miško Hevery opowiada o podstawach JavaScriptu oraz manipulacjach obiektem DOM. W tamtym czasie podszedłem to tematu chyba zbyt swobodnie, co stwierdziłem niedawno pracując nad kolejnym projektem z udziałem JavaScriptu. Ponownie te same błędy, znów te same problemy. Niestety - język ten ma kilka specyficznych elementów, które umykają człowiekowi, jeśli dostatecznie dużo nie spędzi się czasu pisząc kod bezpośrednio korzystający lub omijający te niuanse. Dlatego właśnie postanowiłem powrócić do lektury, do czego zachęcam także Was.


To, czego zabrakło w poprzednim wpisie to krótkie podsumowanie prezentacji przez prelegenta. Oto ono:

  • JavaScript jest obiektowy jedynie w przyjętej konwencji, jest to typowy język funkcyjny
  • Obiektem domyślnym jest zawsze obiekt window
  • Brak słówka kluczowego this oznacza przypisanie zmiennej do obiektu window
  • Referencja funkcji gubi this - staje się nim obiekt window. Aby temu zapobiec należy korzystać z bindingu - metody call() oraz apply()
  • Skrypt jest wywoływany w jednym wątku a wywołanie funkcji zwraca wynik natychmiast - konieczność stosowania callback'ów
Uzbrojony w tą wiedzę zamierzam w niedalekiej przyszłości przeczytać (i oczywiście opisać na blogu) książkę Douglasa Crockforda - "JavaScript: The Good Parts" wydawnictwa O'Reilly.

Do następnego razu!

niedziela, 26 lutego 2012

Joel Spolsky "Smart and gets things done"

Ciężko uwierzyć, że minął prawie rok od mojego ostatniego posta... Co prawda dzieje się bardzo dużo, ale nie aż tak dużo, żeby raz na jakiś czas nie móc napisać choć krótkiego posta tak jak dziś. Prawda jest taka, że aby być w czymś dobrym, a ja bardzo chciałbym być dobrym bloggerem, należy to robić bardzo często. Jakiś czas temu Jacek Laskowski przytoczył bardzo ciekawy artykuł listujący 8 zasad, którymi powinien się kierować każdy blogger, by stać się efektywnym pisarzem. Podstawowa zasada to - pisać! Nawet najkrótsze artykuły niosą pewną wartość zarówno dla czytelnika jak i pisarza, tak więc będę się starać od teraz pisać choćby i krótkie wpisy, ale minimum jeden na dwa tygodnie.

Wracając do tematu dzisiejszego wpisu - miałem ostatnio przyjemność przeczytać jedną z książek Joela Spolsky'ego, wydaną w 2007 roku "Smart & gets things done". Choć do wszystkiego co pisze Joel należy podchodzić z ekstremalną ostrożnością, to przyznać mu trzeba, że jest bardzo dobrym, doświadczonym pisarzem. W książce tej opisuje proces rekrutacyjny swojej firmy - Fog Creek. Opisy dla kogoś takiego jak ja wydają się co najmniej fantazyjne (limuzyna odbierająca kandydata z lotniska, wynajęcie drogiego hotelu, wycieczki po Nowym Jorku itd. itd.) a mimo to oprócz faktu, iż książkę czytało się bardzo przyjemnie to przyniosła pewną mierzalną wartość.

Bardzo często słyszy się o tzw. testach małpy, testach odpornościowych etc. Osobiście rzadko stosowałem takie podejście. Wynika to z wielu rzeczy: akademickiej natury większości projektów w jakich brałem udział, braku przekonania co do słuszności "tracenia czasu" na takie zabiegi etc. W swojej książce Joel Spolsky opisu coś co nazywa "Hallway test",czyli poproszenie osoby przechodzącej obok (która nie jest związana z produktem, nad którym pracujesz) o spędzenie kilku chwil i wypróbowanie i ocenienie użyteczności, łatwości korzystania i wielu innych aspektów projektu, które nam - programistom - bardzo ciężko ocenić. O słuszności takiego podejścia przekonałem się następnego dnia po przeczytaniu książki. Tworzyłem kawałek funkcjonalności i wydawało mi się, że zmierzam w absolutnie dobrym kierunku. Kiedy prototyp interfejsu był gotowy coś mnie tknęło i postanowiłem pokazać go koledze z zespołu, by go ocenił, przeklikał. Okazało się, że   przez zbyt długie przesiadywanie z kodem nie zauważyłem podstawowych niedogodności użytkowania modułu. Od tej pory staram się pozyskiwać 2-3 minuty czasu innej osoby dziennie na ocenienie moich idei, toków myślenia przy projektowaniu interfejsu użytkownika i nie tylko. W samym zeszłym tygodniu takie krótkie konsultacje okazały się oszczędzić mi pracy przez minimum jeden dzień. Całkiem nieźle, co? :)

Podsumowując - książka Joela Spolsky'ego jest godna polecenia każdemu programiście, menadżerowi i komukolwiek innemu związanemu w ten czy inny sposób z procesem rekrutacji lub te wytwarzania oprogramowania jeśli tylko potrafią dystansować się od tego co czytają. Mi lektura sprawiła ogromną przyjemność i już szukam możliwości dostania w swoje ręce kolejnej jego książki :)

Pozdrawiam i do następnego razu!