LinkedIn JavaScript Bootcamp

W ramach nadrabiania zaległości (spowodowanych straconym czasem na pisanie pracy magisterskiej) oraz przygotowania do serii krótkich wykładów wewnątrz firmowych na temat podstaw (i nie tylko) języka JavaScript postanowiłem sprawdzić jak to się robi w dużych firmach. Na celownik jako pierwsza poszła ekipa z LinkedIn, a to za sprawą zeszłorocznej serii wykładów LinkedIn JavaScript Bootcamp w ramach LinkedIn Tech Talks. Seria ta uświadomiła mi, że mimo roku spędzonego przy projekcie opartym o JavaScript, wciąż nie doceniam tego języka i nie znam go odpowiednio dobrze. Zagadnienia takie jak hoisting, event capturing/bubbling, selectors performance, deffered/promise pattern - to tak naprawdę podstawy, choć bardzo często pomijane przy nauce tego języka. Nieznajomość tych tematów może prowadzić do ciężkich w wyprostowaniu konstrukcji, których utrzymywanie w późniejszym etapie może być bardzo bolesne (mówię z własnego doświadczenia).

Cała seria składa się z 12 części:

1. JavaScript 101
2. DOM Events
3. DOM Scripting
4. Javascript Debugging
5. AJAX at LinkedIn
6. Scoping
7. Object Oriented Programming
8. LinkedIn Homebrew
9. JS Coding Standards - najgorsza z prezentacji
10. jQuery at LinkedIn
11. The Curious Case of Dust - jedyna część, której nie byłem w stanie obejrzeć do końca. Kompletnie nie podchodzi mi taki sposób prowadzenia prezentacji
12. JS Unit Testing

Najbardziej polecam prelekcje Kiro Risk'a (Scoping, OOP oraz jQuery). Uważam je za najlepsze i chyba najbardziej zapadły mi w pamięć. Cała seria trwa prawie 10 godzin, lecz wydaje mi się. że prawie cały ten czas dobrze spędziłem.

Dodatkowo, w trakcie wielu z tych prezentacji mowa jest o różnych projektach Open Source, które prowadzi LinkedIn. Można je znaleźć na ich profilu na GitHub'ie.

Do następnego razu!

(Nie za bardzo) krótkie podsumowanie ubiegłego roku

Zeszły rok był zwariowany. Chociaż nie było tego widać po tym blogu, działo się bardzo dużo, bardzo szybko. O tym, że mam zamiar więcej publikować na blogu mówiłem między innymi tutaj i tutaj. Ale jak to mówią, dobrymi chęciami piekło jest wybrukowane.

Ubiegły rok pod względem blogowania był bardzo skromny. Raptem 3 posty napisane przez cały rok. To i tak lepiej, niż w roku 2011 ;-) W tym roku mam nadzieję znacznie więcej pisać, przynajmniej jeden post na 3-4 tygodnie. Jedynie tematyka lekko się zmieni. Będzie trochę o Trójmiasto JUG, więcej o JavaScript, pewnie trochę o Groovy/Grails oraz Python/Django i zapewne o czymkolwiek innym, czym zawodowo będę zajmować się w tym roku. Od prawie roku pracuje na stanowisku Junior Software Developer w firmie Solwit, gdzie co rusz spotykam się z wyzwaniami, tak więc sądzę, że na brak tematów do pisania narzekać nie będę mógł.

Zeszły rok był również moim ostatnim (mam nadzieję) spędzonym na Politechnice Gdańskiej. Obroniłem tytuł magistra inżyniera z Fizyki Technicznej na specjalności Informatyka Stosowana. Tematem mojej pracy była: "Baza wiedzy o ogrodach jako praktyczny przykład wykorzystania technologii GIS. Modułowy system oparty o architekturę chmury". Tematyka ciekawa, sam projekt okazał się totalną klapą. Ale najważniejsze, że ....

W roku 2012 miała miejsce jeszcze jedna zmiana, z której jestem bardzo dumny. Wraz z Mateuszem Mrozewskim podjęliśmy się zadania reanimacji Trójmiejskiej Grupy Użytkowników Java. Po roku spędzonym w tym temacie mogę śmiało powiedzieć, że udało się osiągnąć plan minimum i znacznie więcej. Kilka faktów i statystyk dotyczących działalności grupy w ubiegłym roku:

• odbyło się 8 spotań prowadzonych przez 7 prelegentów,
• odbywaliśmy spotkania w dwóch lokalizacjach: wpierw na Wydziale Fizyki Technicznej i Matematyki Stosowanej Politechniki Gdańskiej, by potem zadomowić się w Inkubatorze Starter prowadzonym przez Gdańską Fundację Przedsiębiorczości,
• uruchomiliśmy stronę grupy (także w języku angielskim),
• stworzyliśmy profil na Google+ orazkonto na Twitterze,
• uruchomiliśmy program O'Reilly Bookshelf, na zadadach O'Reilly Group Program, w ramach którego udało się zebrać 7 książek,
• mieliśmy przyjemność pomagać i brać udział w imprezie Startup Weekend Trójmiasto. Była to nasza pierwsza kontrybucja w lokalnym ekosystemie poza działalnością grupy,
• pozyskaliśmy 5 sponsorów (Solwit, JetBrains, O'Reilly, ZeroTurnaround oraz Inkubator Starter) oraz 3 partnerów (Google Development Group Trójmiasto, 3hack.pl, it3c),
• nagraliśmy kilkanaście godzin prelekcji i zrobiliśmy ponad setkę zdjęć.

Plany na rok 2013?

• wziąć udział w projekcie open source (choćby jedno contribution)
• prowadzić JUG'a regularnie, by rocznie odbywało się minimum 9 prelekcji
• pojechać na 33 Degree 
• pisać więcej na blogu ;-)

Do następnego razu!

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!

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!

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!

Programowanie to nie rzemiosło?

Witam serdecznie!

Wczoraj zaczynałem dalej rozwijać aplikację na przedmiot Platforma Programistyczna .NET (fuuuuj...). W czasie poszukiwania informacji na temat Windows Communication Foundation (.NET WCF) natrafiłem na post o intrygującym tytule "Programming is not a craft". Po skończeniu pracy zasiadłem do lektury i muszę powiedzieć nie przyszła mi ona łatwo. Po pierwsze nie zgadzam się z tezą przedstawioną przez autora, a po drugie stoi to w całkowitej sprzeczności z tym co przekazuje Sławomir Sobótka na konferencjach i swoim blogu. Nie przeczytałem wszystkich komentarzy do postu (a jest ich ponad 130!), ale odniosłem wrażenie, że autor chyba nie do końca zrozumiał pojęcie rzemiosła w ujęciu informatyki. Tak czy siak, warto spojrzeć czasem na pewne rzeczy z perspektywy osoby trzeciej, która stoi w opozycji do tego, w co się wierzy i co się stoi. Dlatego właśnie zachęcam do przeczytania tego artykułu.

Na pewien czas to tyle. Jestem zawalony pracą i nie daje mi to możliwości pisania tylu postów, ile bym chciał. Ale mam nadzieję, że już niedługo to wszystko się unormuję i będę mógł dotrzymać obietnic napisania postów na pewne tematy (jak ta złożona w tym poście).

Pozdrawiam i życzę miłej niedzieli przy pięknej pogodzie! :)

Ryan Singer - człowiek, który zmusił mnie do myślenia

Witam po długiej przerwie!

Od końca zeszłego roku nie opublikowałem żadnego postu. Dlaczego? Powodów jak zwykle można by wymieniać wiele, ale ja ograniczę się do podania jednego, najważniejszego. Otóż od kilku tygodni jestem dumnym posiadaczem tytułu inżyniera fizyki technicznej ze specjalnością informatyki stosowanej! :) W tym tygodniu rozpocząłem studia na drugim stopniu, na tym samym kierunku. Ponieważ nie planuję pracować studiując na pierwszym semestrze (32 godziny tygodniowo, zajęcia do 20-21 itp. bardzo skutecznie to utrudniają) w wolnym czasie postanowiłem nadrobić wiele zaległości.

Jedną z pierwszych rzeczy jakie postanowiłem nadrobić to obejrzenie trzech prezentacji Ryana Stingera, pracownika firmy 37signals. Firma ta jest znana z m.in. Rails'ów dla języka Ruby, czy też rewelacyjnej wręcz książki ReWork. Prezentacje Ryana zmusiły mnie do przemyślenia sposobu, w jaki do tej pory podchodziłem do swoich małych projektów. Zbyt szybkie siadanie do komputera i rozpoczęcie kodowania kosztuje mnie teraz bardzo wiele w drugiej iteracji malutkiej aplikacji, którą planuję przerobić. Doszło do tego, że znaczna większość kodu, który napisałem do pierwszej wersji jest do wyrzucenia. Ale człowiek uczy się na błędach i od bardziej doświadczonych od siebie :) Spróbuję zastosować rady Ryana w tym projekcie, zobaczymy co z tego wyjdzie ;)

A teraz zapraszam do obejrzenia wspomnianych przeze mnie prezentacji:

Ryan Singer at Future of Web Apps, London 2010

Weaving Design and Development

UI Fundamentals for Programmers

Pozdrawiam i do następnego razu!