Można powiedzieć, że marzenia się spełniają. Długo zapowiadana niespodzianka stała się faktem. Szykuje się największe w tej części Europy święto dla wszystkich ludzi odpowiedzialnych za kształt Internetu.

Niniejszym zapraszam na stronę informacyjną konferencji – Front-Trends.com. Jak dotąd, udało się nam zebrać samą śmietankę w postaci naukowców, ewangelizatorów i twórców popularnych frameworków. Ludzi, którzy kreują światowy web. Już wkrótce kolejne, równie gorące nazwiska!

Oficjalna strona wydarzenia ma obecnie charakter wyłącznie informacyjny. Identyfikacja wizualna wraz logo i pełną wersją strony (w tym płatnościami) pojawią się już niedługo. Jednocześnie zapraszamy na Twittera oraz Blip po najnowsze wiadomości.

To jednak tylko początek – twórcy zapowiadają ambitne plany, a to czy się powiodą zależy tylko od Was. Otóż udostępniono specjalny formularz, w którym możecie nadsyłać swoje propozycje ciekawych narzędzi. Zostaną one rozpatrzone i – w razie akceptacji – umieszczone obok takich “sław” jak Dojo czy Selenium.

A co u Drawtera? Nie ukrywam, że zarzuciłem na jakiś czas development z powodu braku czasu, jednak tego typu wydarzenia dają mi motywację, by skończyć nową wersję, bo jest tego warta.

Płeć

W gronie respondentów znalazła się tylko jedna kobieta. To dość interesujące, ponieważ spodziewałem się, mimo wszystko, nieco większej liczby reprezentantek płci pięknej – serwisy społecznościowe typu GoldenLine, według moich obserwacji, posiadają dość obszerną bazę kobiet, które pracują we front-endzie. Cóż, sfeminizowanym targetu mojego bloga bym nie nazwał.

Wiek

Ku mojej uciesze, ponad 80% badanych to osoby dorosłe (szczególnie mocno rzutuje to na wiarygodność pozostałych odpowiedzi, na przykład o zarobkach czy stosunku do wykształcenia wyższego). Co tu dużo mówić, jestem zadowolony. Jak widać jest tylko jedno miejsce dla idoli młodzieży w blogosferze technicznej.

Wykształcenie

Mała przewaga średniego nad wyższym. Bez większej historii, aczkolwiek dalej spróbujemy porównać jego przełożenie na zarobki i ogólny pogląd na temat posiadania wyższego wykształcenia.

Czy według Ciebie studia są przydatne?

Większość z Was jest zdania, że tak. I słusznie (być może niedługo będzie o tym jakiś artykuł). Z drugiej strony, znalazło się 11,11% badanych, którzy studia rzucili. Ciekawe ile teraz zarabiają – sprawdzimy niżej.

Pracujesz na etacie?

Prawie fifty-fifty. Na tak dobry wynik dla nie zapracowali uczniowie, aczkolwiek nie można pominąć freelancerów z wyboru.

Twój roczny dochód brutto:

Kontrowersyjne pytanie, bo kto niby lubi dzielić się informacjami o swoich zarobkach? Dlatego też nie było wymogu podania odpowiedzi. Niemniej większość z Was zaznaczyła którąś z opcji. Biorąc pod uwagę 77% odpowiedzi, zarabiamy dość mało, przynajmniej w porównaniu ze stawkami zagranicznymi i średnimi płacami w IT w Polsce. Z drugiej strony, rola front-endu w wielu firmach jest marginalizowana, co przekłada się na stosunkowo niskie zarobki. Temat rzeka, z pewnością wart dłuższego artykułu (choć nie bronię dyskusji w komentarzach).

W jak dużej firmie pracujesz?

Pracujemy w małych i średnich firmach. Część z Was to one-man-army.

Lata doświadczenia zawodowego:

Większość z Was dysponuje doświadczeniem nie przekraczającym trzech lat, co jest znakiem dla mnie, że warto pisać o sprawach, które mogą wydawać się oczywiste, aczkolwiek, czego dowodzą wyniki, nie każdy mógł się z nimi spotkać.

Jesteś zadowolony ze swojej pracy?

Mimo że nie zarabiamy kroci, jesteśmy zadowoleni. I chyba o to w tym wszystkim chodzi, prawda? Muszę też przyznać, że spodziewałem się nieco większej reprezentacji malkontentów – jak widać polscy front-endowcy potrafią wyzbyć się jednej z najgorszych cech narodowych – ciągłego narzekania.

Czy Twoja praca pomaga Ci się rozwijać?

Cóż, nieszczęśliwej dziewiętnastce radzę pomyśleć nad zmianami.

Co zmieniłbyś w swojej pracy?

Większość z nas jest zadowolona ze swojej pracy, jednak równolegle chcielibyśmy coś zmienić – lista jest dość pokaźna:

Pracowałeś kiedykolwiek jako freelancer?

Większość z nas miała do czynienia z frilansem. W sumie to niedziwne – prace front-endowe są, w większości, wręcz stworzone do freelance’u – to potnij, to złóż, machnij jakieś CSSy na poniedziałek – życie.

Uczestniczysz w zagranicznych konferencjach poświęconych front-endowi?

77,77% nie uczestniczy w zagranicznych konferencjach. A szkoda. Mogę tylko powiedzieć, że firmy inwestujące w zagraniczne konferencje i szkolenia podejmują bardzo dobrą decyzję. Warto zastanowić się nad problemem, tym bardziej, że niektóre konferencje okazują się dość tanie, a wiedza, którą się z nich wynosi jest z reguły bardzo wartościowa.

Uczestniczysz w lokalnych spotkaniach branżowych typu Bootstrap, Aula, Barcamp itd.?

Cóż, nie ma wśród moich Czytelników wielu miłośników tego typu zabaw. Jeszcze niedawno i ja należałem do tej grupy – poczytajcie wpis o Bootstrapie, warto przyjrzeć się takim spotkaniom i skonfrontować poglądy z rzeczywistością.

Masz swój startup, dzięki któremu zarobisz miliony?

Wynik mówi jedno – nie ma sensu pisać o startupach na ferrante.pl, choć miałem takie plany (głównie by sobie ponarzekać). No nic, przekonaliście mnie do wpisów o gołych babach.

Jak oceniłbyś swoją wiedzę i umiejętności branżowe?

Jedna z najciekawszych tabelek. Daje do zrozumienia, że wchodzi się tutaj po informacje o JavaScript. I bardzo dobrze. Jednocześnie płynie z niej wniosek, by nie pisać o HTML i CSS2 – racja, to dość oklepane tematy, tym bardziej, że znacie się na nich doskonale, jak widać. Moją niszą będzie więc twórczość na temat CSS3 i HTML5. Co zaskakuje, wielu z badanych zna bardzo dobrze tajniki programowania obiektowego. Nie jestem co do tego taki pewien – z doświadczenia wiem, że jest z tym dość krucho. No nic, pozostaje Wam uwierzyć na słowo, choć ten temat będzie jednym z bardziej wiodących w przyszłości. Użyteczność, dostępność i typografia wypadły dość blado – szczerze powiedziawszy nie wiem, jak ustosunkować się do tych wyników – można znać i można znać ze słyszenia. Wygląda na to, że przydałoby się więcej artykułów, choć uwierzcie mi – nie lubię o tym pisać.

Jakie frameworki JS znasz i umiesz w nich kodować

I tak ma być, chociaż pamiętajmy, że znajomość tylko jednego frameworka to w dzisiejszych czasach za mało.

Używasz frameworków CSS?

Pozdrowienia dla naszej czternastki!

Jakich narzędzi webdeveloperskich używasz? (np. Firebug itd.)

Długa lista – powiększenie wskazane:

Firebug zdominował stawkę, aczkolwiek wypada się przyjrzeć, czego używają koledzy – być może znajdzie się jakaś perełka.

Kodowałeś kiedyś back-end?

77,77% kodowało back-end. Z jednej strony to dobrze – nie zwalamy, jakby co, na brak doświadczenia w prawdziwym programowaniu, z drugiej – tylko 22,22% to hardkorzy, jak zwykło się mówić ostatnio w okolicach pierwszego piętra.

Stosunek wykształcenia do zarobków

Cóż, nie znajdziecie tutaj żadnej sensacji – wraz ze wzrostem wykształcenia rosną nasze zarobki. Co również ciekawe – rzuceniem studiów cieszą się osoby zaradne, na co wskazują relatywnie duże zarobki:

Zarobki na etacie

Cóż, co etat to etat! Zarabiacie tutaj najwięcej. Co innego freelancerzy:

Zarobki na frilansie

Trochę gorzej, czyż nie? Z drugiej strony freelance robią dość młodzi ludzie:

Z kolei zobaczmy, jak to wygląda u bardziej doświadczonych kolegów:

Nieźle, prawda?

Magistrzy i inżynierowie o studiach:

Ci, którzy poczuli na własnej skórze, czym są studia wyższe, są podzieleni. To jeden z tematów, na które będzie tyle opinii, co studentów.

Zarobki vs. umiejętności i doświadczenie

Na koniec wypada zobaczyć, jakie umiejętności posiadają ci, którzy zarabiają najwięcej:

Podsumowanie podsumowania

Jeszcze raz chcę podkreślić, że jestem bardzo zadowolony z przeprowadzonej ankiety. Również serwis Ankietka.pl zasługuje na słowa pochwały – wszystko przebiegło bez zakłóceń. Celowo nie analizowałem wyników, dotyczących mojej osoby i tego bloga – chciałbym jednak podziękować za to, że tak wylewnie dzieliliście się swoimi uwagami – na pewno wszystkie je przeczytam i wyciągnę stosowne wnioski.

Obiecałem też, że wyniki zostaną udostępnione do Waszego wglądu. Znajdziecie je tutaj.

Na yashke pisali tak:

Linkujmy to akcja na rzecz lepszej sieci. Lepszej bo sympatyczniejszej (szacun dla autora na którego się powołujemy), bo mądrzejszej (to linki rozszerzają i zawężają konteksty, konteksty to wiedza), i w ońcu lepszej bo bardziej obrabialnej maszynowo (internet to sieć nie tylko ludzi ale też robotów).

Wyjaśniając – akcja miała zachęcić blogerów (i nie tylko) do linkowania do cudzych treści/stron w swoich postach, artykułach i tak dalej. Mądrego linkowania, nie spamu. Pod swego rodzaju manifestem podpisały się tłumy (nie, nie podpisałem się pod akcją, choć pewnie zaliczyłbym kilka odwiedzin więcej…). I słusznie, dobre pomysły powinno propagować się z całych sił.

Ale jako że Polacy zbytnio krzepliwi nie są, całość postała sobie prawie rok na serwerach, po czym ślad o stronie zaginął. Niby domena jest zajęta, jednak wydaje się, ze linkowanie stało się passe.

Zastanawiam się, jak mogą wytłumaczyć się twórcy, jednak każda z wersji jest, że tak powiem, albo dość kompromitująca albo potwierdzająca tezę, że siedzimy jeszcze w internetowym zaścianku. Można więc powiedzieć, że ten swoisty ruch społeczny spełnił swoje zadania (a nowi niech se sprawdzą archive.org¹). Inna wersja – stwierdziliśmy, że pomysł jest kiepski i mało rozwojowy, ale nie powiemy o tym wprost, więc lepiej niech rozejdzie się po kościach. Kiedy indziej można też rzec, iż Krystyna z gazowni zapomniała zapłacić za domenę (?). Ostatecznie można także wytłumaczyć się awarią lub jakimś technicznym psikusem, jednak strony nie ma przynajmniej od kilku tygodni. Priorytety?

Podsumowując – zapewne ktoś tam, kiedyś, postanowił dzięki tej akcji linkować. Znajdą się też tacy, którzy linkowanie zbojkotowali, ich prawo. W każdym razie – już nie linkujemy.org.

Najsmutniejsze jest jednak to, że okazaliśmy się (bez wytykania palcami proszę, sprawcy i tak są podlinkowani) – pewnie po raz kolejny – całkiem sprawnymi krzykaczami. Znów liczył się tylko początkowy zryw, pomysł, slogan. Ci, którzy mieli się podpisać, podpisali się, a całą akcję pokrył ten sam kurz, co Wolny Tybet. Ostał się jedynie nieśmiertelny Che Guevera na koszulce.

1. Ups, nie podlinkowałem.

Postanowiłem stworzyć ankietę, w której zadaję Wam 30 pytań na różne, branżowe tematy. Najważniejsze dla mnie informacje są wymagane, jednak kilka pytań możecie z czystym sumieniem opuścić. Oczywiście ankieta jest w pełni anonimowa, tak więc im więcej respondentów, tym lepiej! Apeluję też o poważne odpowiedzi, ponieważ zależy mi na tym, by jak najlepiej dopasować ofertę bloga do Waszych preferencji. Na wynikach ankiety planuję również oprzeć wygląd paru projektów, związanych z tematyką blogów i front-endem jako takim.

Oczywiście wyniki ankiety omówię i przedstawię w jakiejś przystępnej formie. Bez obaw!

Zapraszam więc gorąco do wypełnienia ankiety na Ankietka.pl.

Wielu twórców stron internetowych narzekało na brak skalowalności i toporne zasady dobierania określonych znaczników. Powtarzano jak mantrę, że HTML nie ma nic wspólnego z programowaniem. Nie było dotąd żadnej możliwości użycia wzorców projektowych, raził brak kompilatora, a częste wycieki pamięci (tzw. memory leaks) w Internet Explorer coraz głośniej przypominały o potrzebie zastosowania Garbage Collectora. W3C, dotąd głuche na nawoływania zirytowanych programistów, postanowiło wyjść naprzeciw tym, którzy chcieliby tworzyć semantyczne i dobre strony internetowe. Jak udowodniła ostatnia ankieta na znanym blogu Techcrunch, dla większości badanych (ponad 70% respondentów opowiedziało się za tą opcją!) HTML jest zbyt zawiły (spójrzmy – przecież to zupełnie inne podejście do programowania!) i niezgodny ze współczesnymi dogmatami programowania.

Świat się zmienia — nie ukrywajmy tego. Developerzy stali się o wiele bardziej wymagający, chcą narzędzia odpowiadającego ich sporym umiejętnościom. W dobie OOCSS i innych obiektowych narzędzi, przestaliśmy być bierni wobec postępującego zjawiska obiektowości. Zaangażowaliśmy do badań swoich najlepszych specjalistów już 3 lata temu. Dziś z dumą ujawniamy rezultaty ich pracy.

Czym zaskoczy OOHTML?

Zmieni się przede wszystkim struktura dokumentów. Każda strona HTML będzie odzwierciedleniem klasy, którą trzeba będzie zdefiniować już na początku:

<class>news</class>

Domyślnie klasa w HTML będzie posiadała publiczny specyfikator dostępu. Nic nie szkodzi jednak na przeszkodzie, by wzbogacić ją o private czy protected.

<privateclass>news</privateclass>

W tym wypadku, prywatna klasa spowoduje, że kod źródłowy będzie niedostępny dla podglądu. Koniec ze skryptami blokującymi prawy przycisk myszy i dostęp do “Pokaż źródło strony!”. Wreszcie developerzy nie będą oceniani za jakość kodu, a za jego efektywność.

Z kolei klasa protected:

<protectedclass>news</protectedclass>

będzie zachowywać się tak, jak klasa publiczna, lecz dzięki magicznemu słowu protected zwiększą się zabezpieczenia przed wszelakimi intruzami, wirusami i trojanami. Jest to swoisty precedens, ponieważ W3C pierwszy raz bierze na swoje barki odpowiedzialność za bezpieczeństwo przeglądania stron, odciążając tym samym producentów przeglądarek. Rozwiązanie jest szeroko dyskutowane wśród banków, którym jak nikomu innemu zależy na bezpieczeństwie.

Warto dodać, że plik OOHTML powinien nazywać się tak, jak klasa w nim zdefiniowana, niezależnie od modyfikatora dostępu. Możemy również zapomnieć o tagu <html />!

Interfejsy

Co więcej, zyskamy dostęp do interfejsów, które będą zapisywane w pliku z rozszerzeniem .ihtml. Przykładowy interfejs:

<interface name="ExampleInterface">
	<div>
		<h1></h1>
		<p></p>
	</div>
</interface>

Klasa interpretująca dany interfejs powinna wyglądać następująco:

<class implements="ExampleInterface">index</class>
<head></head>
<body>
<div>
	<h1></h1>
	<p></p>
</div>
</body>

O ile w interfejsie nie możemy zdefiniować implementacji danych tagów (np. atrybutów typu class, id, href itd.), tak w implementującej go klasie da się zrobić cokolwiek:

<class implements="ExampleInterface">index</class>
<head></head>
<body>
<div id="article">
	<h1><a href="#"></a></h1>
	<p class="content"></p>
</div>
</body>

Dziedziczenie

W OOHTML zaimplementowano również dziedziczenie:

<class extends="ParentClass">index</class>

W ten sposób strona odziedziczy wszystkie tagi w <body> z pliku ParentClass.html. Co więcej, nadchodzi wielkie ułatwienie dla twórców startupów i pochodnych! Otóż, będzie można dziedziczyć także od konkretnych adresów URL:

<class extends="http://digg.com">index</class>

Jestem pewien, że twórcy wykopu, blipa i innych inspirowanych serwisów skorzystaliby właśnie z tej opcji. Z całą pewnością jest to rozwiązanie o wiele tańsze i wygodniejsze niż pisanie kodu od nowa. W3C myśli również nad gotowymi template’ami do dziedziczenia. I tak, możliwe będzie odziedziczenie z szablonu web2.0:

<class extends="web2.0"></class>

Wygeneruje to następujący kod w <body>:

<div id="logo"></div>
<div id="friends"></div>
<div id="tags-cloud"></div>
<div id="javascript-disabled"></div>
<div id="add2digg"></div>
<div id="add2delicio"></div>
<div id="add2whatever"></div>

Poliformizm

Poliformizm? Jasne! W zależności od kraju, skąd pochodzi dany user, strona będzie tłumaczona na lokalny język. Wystarczy zdefiniować obsługiwane kraje:

<class polymorphism ="pl,en,it">index</class>

Zapomnijmy o tłumaczach i ciężkiej pracy po stronie back-endu. Nadchodzi OOHTML z poliformizmem, jakiego jeszcze świat nie widział.

To na razie wszystko, co zdążyli ujawnić twórcy OOHTML, jeśli chodzi o składnię. Jak mówi Bill Jobs, jeden z głównych ewangelistów w W3C, sprawa jest jeszcze otwarta:

Postaramy się dogodzić każdemu programiście — tym, którzy programowali w C++ i tym, którzy mieli styczność na przykład z Delphi czy Basiciem. Nasz zespół stale prowadzi badania nad współczesnymi, obiektowymi językami programowania. Chcemy wyciągnąć z nich to, co najlepsze. Na pewno więc zajdą pewne rozbieżności pomiędzy obecnym, a oficjalnym API. Poza tym, mamy kilka asów w rękawie, których wolimy jeszcze nie ujawniać (śmiech).

HTML Garbage Collector

Oprócz tego, W3C informuje o dodatkowych cechach języka, niezwiązanych ze składnią. I tak, dostaniemy HTML Garbage Collector, który będzie odśmiecał z pamięci niepotrzebne dane. Zapowiada się duży wzrost szybkości, jeśli chodzi o aplikacje napisane w AJAX! Poza tym, koniec z memory leaks w Internet Explorer — wszystko, co wycieknie poza przeglądarkę zostanie wyłapane przez odśmiecacz i z powrotem ulokowane w pamięci. Czy potrzebna będzie maszyna wirtualna lub cokolwiek w tym stylu? Twórcy zapowiadają, że nie:

Rozmawialiśmy z producentami najpopularniejszych przeglądarek. Wszystkie zgodziły się na zaimplementowanie naszego Garbage Collectora. Nadal jednak prowadzimy rozmowy z Mozillą, która twierdzi, że pracuje już od dawna nad podobnym rozwiązaniem.

Na wieść o OOHTML szybko zareagowali również developerzy Eclipse. Mamy informację, że powstanie specjalne rozszerzenie do programu — OOHTML Eclipse. Zapowiada się rewolucyjnie – pierwsza w pełni obiektowa wersja języka z gotowym i sprawdzonym IDE!

Przy okazji informacji o OOHTML, zostały rozwiane wątpliwości co do kompatybilności wstecznej w Internet Explorer. Jego twórcy sensacyjnie przyznali, że IE obsługuje w pełni wszystkie cechy obiektowego HTML. Powołując się na Internet Explorer blog:

Był taki moment, kiedy w 2000 roku myśleliśmy, jak zrewolucjonizować programowanie stron internetowych w HTML. Jedną z opcji był właśnie OOHTML. Co zdumiewające, nasze założenia były wręcz identyczne, jak te z W3C. Zaczęliśmy więc implementację w kontekście IE6. Był chyba luty. Niestety, w tym czasie zmieniali się ludzie w dziale marketingu. Wiesz, reorganizacja. Nowy szef, John Doe stwierdził, że OOHTML to zbyt duża rewolucja, która może obrócić się na naszą niekorzyść. Fakt — OOHTML ma mnóstwo zastosowań, ale jest o wiele trudniejszy w nauce dla typowego Kowalskiego. Zaprzestaliśmy więc prac, jednak dotychczasowa implementacja OOHTML pozostała w silniku IE (Trident). Paradoksalnie wystarczy jedna zmiana w pliku config.dll, by włączyć tę fascynującą opcję, jaką wydaje się być OOHTML!

Zapowiada się duży przełom. Z niecierpliwością czekam na nowe informacje o OOHTML. Naprawmy wreszcie tą spróchniałą sieć!

Pokora to jedna z największych cnót

Szafowanie szeroką gamą branżowych terminów nie czyni z Ciebie specjalisty. Spotykałem osoby, które twierdziły, że wiedzą, co to dostępność, użyteczność i inne takie… No, zresztą, sami dobrze wiecie… Większość z nich, zapytana o szczegóły, rzucała jednak podstawowymi określeniami, które można bez trudu znaleźć po 30 sekundach wyszukiwania w sieci.

Bardzo często ktoś, coś tam słyszał, jednak nie przypomina sobie szczegółów. Nielsen, Don’t let me think. A! I o niepełnosprawnych coś było! Prawie jak na lekcji biologii… Problem w tym, że tak jak lekarz podczas operacji nie sięga po podręczniki, by dowiedzieć się, gdzie mieści się serce, tak programista front-end nie myśli dwie godziny nad tym, jak działa, dajmy na to, hierarchia nagłówków.

Dlatego też o wiele bardziej cenię ludzi pokornych, którzy owszem, w trakcie boomu na użyteczność słyszeli kilka podstawowych haseł, aczkolwiek otwarcie przyznają, że nie wiedzą zbyt wiele i chcieliby poszerzyć horyzonty.

Poza tym, gro osób spod znaku doskonała znajomość HTML, XHTML, CSS oraz standardów W3C, WAI tak naprawdę, co komiczne, ma w swoim portfolio strony, które przeczą współczesnym standardom. Co więcej, pewnikiem wszyscy zrobiliśmy kiedyś jakiegoś potworka. W związku z tym, sto razy bardziej docenię osobę, która jest świadoma tego faktu, niż tę, która stwierdzi, że wszystko jest w porządku, a jej kwalifikacjami powinna zająć się najlepiej komisja złożona ze Spolsky’ego, Meyer’a, Zeldmana i innych.

To nadal jest programowanie!

Jeśli chodzi o JavaScript, zważ, że to nie tylko jQuery. Wielu programistów uważa czysty JavaScript za zupełnie zbędny, kiedy jest to podejście pozbawione sensu. Chciałbym wiedzieć, ile do powiedzenia na temat optymalizacji, closures czy programowania obiektowego mają osoby, które w swoim portfolio oceniają JavaScript na “doskonały”. Sam łapałem się na tym wielokrotnie – udało mi się napisać to i owo, dlatego myślałem, że jestem w danej dziedzinie ekspertem. Nic bardziej mylnego, języki programowania to żywy twór, który z każdym dniem odsłania nowe obszary.

Kiedyś o eventach w JavaScript wiedziałem tylko tyle, że trzeba pobrać odnośnik do DOM i przypiąć stosowną funkcję. Dziś o ból głowy (z zachwytu nad rozwiązaniami) przyprawiają mnie problemy wycieków pamięci lub zdarzeń bąbelkowych.

A gdzie mi tu Panie do zaawansowanego użycia Canvas, w którym zrobiłem bardzo mało rzeczy, aczkolwiek mam świadomość, jak to działa i wiem, że gdybym poświęcił swój czas na konkretny projekt, na pewno bym go zrobił. O ile z czystym sumieniem mogę więc stwierdzić, że nie jestem specjalistą z tej dziedziny, tak wiele osób napisałoby na Goldenline czy gdziekolwiek indziej, że Canvas wciąga uchem, kiedy tak naprawdę używała jedynie jakiegoś widgetu z Ajaxian.com.

Poznawanie zagadnień od podstaw jest bardzo ważne. Prędzej czy później trafimy na problem, któremu nie będziemy mogli podołać przez nasze zaniedbania. Pierwszy przykład z brzegu – miałem swego czasu zoptymalizować system walidacji formularzy faktur. Pozycji było ponad 30, każda z nich miała po pięć sprawdzanych informacji. Pętli były dziesiątki (setki?) tysięcy, a czas wykonywania skryptu oscylował wokół 15 sekund. Wszystko oparte było o jQuery i jQuery Validation. Dla każdego walidowanego pola frywolnie używano selektorów jak poniżej:

$('input[name^=xxx][name$=xxx]');

Przyjmując, że jQuery musi sprytnie przefiltrować wszystkie inputy, dopasowując je do podanych dwóch wyrażeń regularnych, mamy 30*5*2*600 iteracji (w dokumencie było około 600 inputów). Ciekaw jestem, co powiedziałaby osoba bez jakiejkolwiek wiedzy analityczno-algorytmicznej (choćby jak działają selektory w jQuery). Że o podstawach JavaScript nie wspomnę.

Pomyśl też, co stałoby się, gdybyś musiał napisać coś w MooTools lub Prototype?

Staranność

Nie rób w kodzie bałaganu, pod żadnym pozorem. Nieważne, czy zaczynasz duży czy mały projekt. Nazywaj klasy i identyfikatory zgodnie z przyjętą przez Ciebie konwencją. Żadnych test3, somethingExampleHehe i innych potworków. Nie pisz skryptów na szybko, bez dobrego formatowania i logicznego nazewnictwa zmiennych. Utrzymuj porządek w sekcji head dokumentów, jak i w folderach z plikami źródłowymi. Przyjmij konwencje nazw katalogów, w których trzymasz pliki css, js i obrazki.

Otaczaj skrypty JS anonimowymi funkcjami, tak, by nikt nie nadpisał Twojego kodu:

(function() {
// Twoj kod...
})();

Niestety, programowanie stron niesie ze sobą wiele pułapek, a jedną z nich jest skłonność do powstawania bałaganu. Wielokrotnie widziałem zdublowany kod, puste deklaracje w CSSach i wiele innych niedoróbek. Znając życie, większość pochodzi z czystego pośpiechu. Osobiście, często robiłem coś na szybko, dodawałem style inline, by sprawdzić, jak coś się zachowa, mimo że miałem do dyspozycji debugger. CSS i JS są bardzo czułe na fuszerkę, dlatego unikaj kompromitacji, nawet, gdyby praca miała potrwać 10 minut dłużej.

Zdarza się również, że mozolnie szukamy rozwiązania, dajmy na to pod IE, dopisując coś i skreślając w kodzie, a także pisząc na szybko różne nazwy zmiennych, typu some, x, aaa itd. Gdy dochodzimy do celu, zapominamy o sprawie, skoro “jest zrobione“. W efekcie w kodzie pozostaje bubel, który będzie nielogiczny dla programistów edytujących kod w przyszłości. Zmusi ich to prawdopodobnie do kontynuowania złej konwencji i dalszego brudzenia, bo przecież nie będę się doczytywał, o co temu kolesiowi chodziło.. Nie zostawiaj po sobie kodu, którego sam nie zrozumiesz za miesiąc.

Debugger i dobre narzędzia wspomagające to świętość! Dowiedz się, co to Firebug, WebDeveloper, Live Headers, Pixel Perfect, IE Tab, HTML Validator, czy Firecookie. Przeglądaj często stronę z rozszerzeniami do Firefoxa. A nuż wyjdzie coś interesującego!

Frameworki CSS to nie do końca trafiony pomysł, jednak przydatny w pewnych okolicznościach. Przeanalizuj dokładnie wady i zalety takiego rozwiązania, zainteresuj się resetami CSS czy też projektami typu 960 grid system.

Typografia potrafi być ciekawa, a XHTML ma wady, więc bądź ostrożny.

Rozwój osobisty

Nikt nie jest alfą i omegą. Nie zniechęcaj się tym, że wielokrotnie podczas pracy używasz Google. Zapamiętywanie hacków, czy też bugów przeglądarek jest pomocne, lecz nie jest to najważniejsze. Wystarczy, że znasz i kojarzysz problem. Rozwiązanie to tylko kwestia doboru środków.

Czytaj książki. O sieci pisze się tyle ciekawych rzeczy! Nie przeczytasz ich na żadnej stronie internetowej. Luke Wroblewski, Joel Spolsky, Eric Meyer, Jakob Nielsen, Louis Rosenfeld, Dean Clarke to tylko czubek góry lodowej nazwisk, które szanujący się developer powinien znać. Czytanie zagranicznych pozycji to nie moda, lans czy cokolwiek innego – to polepszanie swoich kwalifikacji. Biorąc pod uwagę, że w sieci są prawdopodobnie tysiące koderów z szablonu (CSS, HTML, JS), zatrudniłbym kogoś, kto po prostu wie więcej.

Jeśli nie znasz z kolei jakiejś pozycji, przyznaj to otwarcie, zamiast szukać okrężnej drogi w swoich tłumaczeniach. Nie znać “X” czy “Y” to nie wstyd, acz argument do dalszej nauki i sztuki poznania. Osobę, która próbuje podjąć dyskusję na temat, o którym nie ma żadnego pojęcia, z reguły można rozpoznać po kilku sekundach. Pamiętaj o tym.

Staraj się czytać blogi, choć zważ na to, że nie jest to żaden wyznacznik Twojej wiedzy, o czym nieliczni próbują przekonywać. Jeśli blogi, to nie tylko polskie (tym bardziej, że bardzo mało jest tych wartościowych). O JavaScript absolutnie fantastyczne rzeczy tworzy John Resig (twórca jQuery), jest genialny Dean Edwards, Paul Bakaus, Valerio Proietti. To tylko kilka nazwisk, bo o JS i CSS piszą tysiące osób. Bardzo pomocne są też serwisy typu A List Apart czy też Ajaxian.com, gdzie zgromadzone są najnowsze wiadomości i projekty z branży.

Zauważ, że posiadanie sprzętu Apple lub pisanie Twittera/Blipa nie czyni Cię specjalistą. Wiedz, że na Macu nie zobaczysz 64-bitowej palety kolorów, a to że Zeldman twitteruje nie robi Cię jego kumplem od wódki. Jeśli mimo wszystko stawiasz powyższy fakt za swoje ewidentne zalety, powinieneś zaznajomić się ze znaczeniami ekshibicjonizmu i jego pochodnymi.

Ucz się języka obcego, najlepiej angielskiego. Większość ważnych rzeczy mówi się tutaj w języku Szekspira. W prestiżowych firmach komunikacja z klientem bardzo często odbywa się po angielsku. Z kolei, jeśli Twoje aspiracje sięgają naprawdę wysoko, raczej nie dosięgniesz nieba w Polsce. Niestety, pierwsza liga front-endu gra za granicą. Sam fakt, jak mało mają tam do powiedzenia Polacy, świadczy o tym, że możemy traktować nasz kraj jako branżowy zaścianek.

Bądź krytyczny i szczery w swoich osądach, nie bój się wyrażać własnych opinii. Jeśli projekt dyskutowany jest pod kątem dziedziny, w której jesteś ekspertem, narzuć swoje zdanie i przede wszystkim przedstaw stosowne argumenty. Broń swojej wiedzy! Kto ma wiedzieć cokolwiek o dostępności, jak nie specjalista front-end? Oczywiście, sugestie innych osób są cenne, jednak ostateczne zdanie powinno należeć do Ciebie.

Fajne rzeczy o rozwoju osobistym pisze Alex Barszczewski.

Użyteczność

Sądzę też przekornie, że użyteczność to jedna z największych pułapek, jakie wyprodukował webdevelopment w ostatnich latach. Podstawowe terminy użyteczności stron www są jak najbardziej zasadne, jednak im dalej w las, tym więcej drzew. Tak naprawdę, wiele aspektów użyteczności jest sprawą dyskusyjną i to, dlaczego, przyjmijmy umownie, link jest czerwony, a nie niebieski, w gruncie rzeczy determinuje kontekst, zamierzony cel i dziesięć innych czynników, których nie znajdziemy w szablonowych książkach o usability.

Jest to działka, w której najwięcej mają do powiedzenia krzykacze. Ubzdurało im się, że znają się na użyteczności, bo przeczytali kilka mądrych książek. Większość sporów o usability danego elementu na stronie można podważyć “pierwszą lepszą” publikacją książkową. Dlatego też najgorsze argumenty, jakie możesz użyć w dyskusji o usability, tyczą się fanatycznego powoływania na konkretnego autora i rzekomego specjalisty od użyteczności. Nikt jeszcze nie wymyślił złotego środka, a książki o usability wskazują jedynie na najpopularniejsze problemy!

Przede wszystkim radzę myśleć! Użyteczność to nie proste regułki. To nie wersety z książek, które często powielają banały lub które są po prostu słabe (vide publikacje Kasperskiego). Nie idź na łatwiznę. Dopatruj się kontekstu, przeprowadzaj testy z użytkownikami, dyskutuj z kolegami po fachu! Nie ma nic bardziej zbawiennego, niż solidna burza mózgów, poparta konkretnymi argumentami merytorycznymi. Wiele publikacji aspiruje do bycia tak uniwersalnym, jak tylko sie da. Nie daj się nabrać, tym bardziej, że jest to ostatnio niezwykle chwytliwy temat. Specjalistów od użyteczności przybywa niczym cinkciarzy pod Pewexem, dlatego powtórzę jeszcze raz – myśl!

Prototypowanie

Doceń prototypy i testy z użytkownikami. Muszę stwierdzić, że wcześniej rzadko korzystałem z papierowych bądź elektronicznych prototypów. Designy od początku do końca projektował dla mnie grafik, zgodnie ze słownymi wytycznymi. Jakież to amatorskie podejście! Profesjonalny projekt powstaje stopniowo. Najpierw pracuje się nad wymaganiami, potem wkracza front-endowiec, który ma za zadanie przedstawić prototyp funkcjonalności strony. Nie projektuje on designu, ale ustala layout, rozmieszczenie buttonów, warstw, menu i wszystkiego, co tyczy się www. Przy okazji projektuje on większość aspektów użyteczności strony. Prototyp ułatwia pracę wszystkim – klientowi, designerowi, back-endowi i Tobie oczywiście. To na etapie prototypu powinny być wyjaśniane wszystkie wątpliwości. Tutaj ustalany jest ostateczny, podkreślmy to, kształt aplikacji. Wszystko po to, by potem zająć się tylko i wyłącznie kodowaniem oraz testowaniem.

Profesjonalne prototypy można tworzyć np. w Axure.

Prawdopodobnie to nie wszystko, co można by napisać na ten temat. Uczymy się jednak na błędach, a kolejne akapity dopisze życie, z pewnością…

W skrócie jest to akcja, która zakłada, że każdy blogger podzieli się listą pięciu ciekawych blogów, które nie uchodzą za wielce popularne i nie każdy je zna. Po pełen opis odsyłam do strony projektu.

Osobiście, zgodnie z moim kredo czytania blogów, wyróżnię konkretne strony w większości za pojedyncze i wartościowe notki.

• blog.eldoras.com – świetnie opisany proces rekrutacyjny do Google. Autor pełną garścią buduje niesamowite napięcie, mimo że jest to.. no właśnie, tylko i wyłącznie opis jego rekrutacji do światowego potentata. Warto przeczytać, ja po lekturze serii artykułów nabrałem nieco dystansu do Google.

  Co mnie jedynie razi to pojawiające się od niedawna socjologiczne chwyty autora (sensacyjne nagłówki, masa pogrubień niekoniecznie kluczowych wyrazów itd.), mające na celu zwabić jak najwięcej czytelników.

• Dziudek blog – fantastyczna robota i fantastyczne artykuły o MooTools! Już za wkład pracy (pro bono) Dziudka należy się masa wyróżnień i pochwał. Jeśli chcesz zacząć programować w MT, jest to pozycja wręcz obowiązkowa. Wszystko o MT 1.2 i 1.1!
• Adriano blog – Web is brutal – masa przydatnych artykułów na temat bezpiecznych i user-friendly rozwiązań webowych. Można dowiedzieć się wiele o potencjalnych atakach na strony internetowe (m.in. na przykładzie Wykopu) i nie tylko.
• Splatch blog – guru, jeśli chodzi o PHP oraz bardzo dobry programista JAVA. Dobre teksty na wysokim poziomie zaawansowania wiedzy.
• CoSTa’s Family Page – CoSTa i wszystko jasne! Pewnie najbardziej znany blog w stawce, nie mogłem go nie wyróżnić. Świetne pióro tytułowego bloggera, mimo że tak naprawdę CoSTa pisze o wszystkim – o życiu – swoim i tym wokół. Jest rodzinnie, o grach, o Apple, o muzyce i polityce. Dla każdego coś miłego, a optymizm i humor autora wręcz uzależnia.

Do powyższej listy spokojnie mógłbym jeszcze dołączyć kilkanaście blogów joggerowych. Muszę przyznać, że jeśli miałbym zakładać bloga, nie mając własnego serwera – byłby to zdecydowanie Jogger.pl. Wyjątkowa społeczność, bardzo ciekawi i zdolni ludzie, a przede wszystkim niesamowita atmosfera. Techblog, z bardzo ciekawymi wpisami technicznymi. Od Assemblera do CSS! Kilkadziesiąt komentarzy pod wartościowymi notkami to standard. Aż chce się pisać i uczestniczyć w całym przedsięwzięciu! Co prawda, jak to bywa w tak dużych zbiorowościach – znajdą się i flame’y, i zwykły trolling. Doświadczony czytelnik Joggera potrafi jednak skutecznie omijać pewne miejsca pod tym kątem. Kiedyś nawet myślałem o migracji. Może kiedyś?