Z komentarzy pod wykopem¹ i z postów na forum płyną dwa (no, może w porywach trzy) wnioski – tylko młodzież robi kompletne strony za przysłowiową flaszkę (lub paczkę fajek, jeśli to młodzież mniej buntownicza jest), za 50zł nie da się kupić dobrej whisky (tudzież palety sprawdzonego, niemieckiego Marlboro od Tomasza H.) oraz to, że żaden szanujący się programista nie spędzi dwóch tygodni, by zarobić stawkę, jaką może uzyskać za godzinę w dobrej firmie.

Przede wszystkim jednak – nie przesadzajmy i nie demonizujmy rzeczywistości. Natura, jak kiedyś mądrze powiedziano, lubi równowagę. Zawsze znajdzie się ktoś, kto zrobi serwis za grosze. Takie mamy prawa rynku – jeden potrzebuje na chleb, drugi na ferrari. Pewnych rzeczy niestety nie można zmienić, mimo że wszelka logika nakazuje, by było tak, a nie inaczej. Poza tym za małe pieniądze pracuje wielu młodych programistów. Bardzo często ktoś, coś tam, kiedyś zakodował, udało się, więc dlaczego nie przyjąć zlecenia? Jasna sprawa, sam tak robiłem. Jakie są jednak konsekwencje niskich cen i małego doświadczenia programistów?

Każda strona internetowa, choćby tylko z księgą gości, to określona funkcjonalność i masa zależności. O ile kiedyś nie doceniałem porównań z budową domu, tak teraz jest to dla mnie sztandarowa analogia. Dom można zbudować na kilka sposobów – użyć innych – droższych lub gorszych – materiałów. Zatrudnić bardziej bądź mniej wykwalifikowanych pracowników. Skorzystać z tańszej lub droższej ekipy budowlanej. I tak dalej. Identycznie jest z programowaniem – serwer (dzielony hosting, serwer dedykowany?), język (tani w utrzymaniu PHP, potężna JAVA?), baza (darmowy PostgreSQL czy drogi Oracle?).

Często wiele rzeczy można zrobić na kilka sposobów. Z reguły tylko doświadczeni (a więc drożsi i lepsi) programiści wiedzą, jaki wybrać sposób, bo spędzili mnóstwo czasu na kodowaniu i nauce, poznając różne techniki i rozwiązania wielu problemów. Nie od parady wymyślono na studiach specjalizację o dumnej nazwie inżynieria oprogramowania, a osobom, które tworzą programowanie daje się tytuł inżyniera, a potem magistra. Wracając do przykładu z budową domu, drogi kliencie – komu zleciłbyś coś, co ma Tobie służyć na lata (zapewne także Twoim potomkom)? Młokosom czy doświadczonym budowniczym?

Następny problem to spłycanie prestiżu własnych produktów. Zlecając wykonanie dość skomplikowanej strony za zaniżoną stawkę automatycznie godzimy się na to, że finalny efekt będzie na poziomie deski klozetowej. Jak w każdej branży, dobre usługi kosztują więcej od tych średnich i kompletnie słabych. Nie wiesz, czy można zaufać danej firmie? Spytaj specjalistę bądź znajomego, który ma o tym pojęcie!

Mimo wszystko, popyt na tanie usługi wciąż rośnie. Zawsze znajdą się osoby, które mało zapłacą oraz te, które z przyjemnością mało zarobią. Rodzą się pytania – jak można zminimalizować rujnowanie trudnego zawodu, jakim jest fach programisty? Czy czasem w głowach nam się nie poprzewracało bo tak naprawdę programowanie nie jest wcale ciężkie i drogie? Jaki wpływ mają tanie usługi na kondycję technologii na świecie (i stron internetowych, jeśli spłycamy problem tylko do webdevelopmentu)?

Odpowiedź na pierwsze pytanie jest łatwa, ale i mało przekonująca. Niestety, pieniądz zawsze wygra z ideami. Możemy ewangelizować, indoktrynować i pouczać. Z większymi lub mniejszymi – jak to bywa – skutkami. Czy aby jednak wystarczającymi, kiedy, bądźmy szczerzy, statystyczny klient odpowiada sobie głównie na jedno pytanie: jak dużo mogę zyskać za jak najmniejszą kwotę? Czy wystarczy mu wiadomość, że produkt za 50zł nadaje się do kosza? (przecież działa!). Nie jestem pewien, czy odpowiednią kampanią możemy kogoś przekonać, tym bardziej, że wiele osób kupuje za bezcen z premedytacją (jak bohater wykopowego wątku)! Może więc uderzyć w programistów? Ale co wtedy, kiedy jeden z drugim nie ma co wrzucić do gara? Może jest po prostu za słaby, bo dobrze płatna praca w IT zawsze się znajdzie, a nie mają jej tylko miernoty? Ekhm…

Ciekawa jest też sprawa gloryfikacji naszego zawodu. Na ten temat można spotkać wiele skrajnych opinii, jednak jako człowiek, który włożył w swoją edukację bardzo dużo wysiłku (oraz godzin przed monitorem i książkami) chciałbym stanowczo zaakcentować, że programista chłonie mnóstwo wiedzy, porównywalnie z lekarzem czy prawnikiem. W dodatku nieprzestanie używa swojego mózgu, wymyśla, kreuje, nie powiela ścieżek i wzorów, choć jak wszędzie, posługuje się pewnymi wzorcami projektowymi i algorytmami. Nasza praca nie polega jednak na banalnym dopasowywaniu elementów! W żadnym wypadku! To godziny żmudnej harówki, ciągłego rozwoju i mnóstwa wyrzeczeń – dobrze, że jeszcze weekendowych dyżurów nam nie dają… Programista to zawód ważny i trudny, choć obarczony relatywnie niską skalą ryzyka.

Bagatelizowanie problemu cen, a co za tym idzie powstawanie słabego oprogramowania oceniam jako zagrożenie, choć każdy jest kowalem własnego losu. Dziurawa strona może spowodować wyciek danych naszych klientów lub zablokowanie strony przez internetowych wandali (czy po prostu tzw. script-kiddies), a to tylko pierwsze z brzegu przykłady. Oprogramowanie słabej jakości nie skaluje się, nie można go szybko i tanio rozwijać. Źle napisane aplikacje są mało wydajne, wymagają większych nakładów na sprzęt i utrzymanie. Po prostu nie działają! Sprawiają tylko wrażenie działających!

Wypada poruszyć także temat tych, którzy sprzedają swoje usługi za bezcen. Jak powiedziano, są to w większości młodzi programiści, którzy łączą przyjemne z pożytecznym – naukę i zarobek. Trzeba sobie powiedzieć jasno, nie da się w 2 lata zdobyć wystarczającej wiedzy (choć pal licho wiedzę, tutaj, przyrzekam, najważniejsze jest doświadczenie i tysiące linijek kodu “w palcach”). Jasne, młody programista może stworzyć coś, co działa, nie ma jednak pewnego dystansu do tworzonego przez siebie kodu, nie poznał zbyt wielu technologii i technik, w efekcie jego kod jest generalnie nieefektywny i mało elastyczny, a to tylko dwa z kilkunastu przymiotników, jakie miałem uszykowanych na tę okazję.

Co 16-latek wie np. o Dependency Injection? Uwierzcie, z każdym miesiącem rzeczy, które wcześniej były zbyt skomplikowane stają się banalne, a kod, który napisaliście wcześniej okazuje się zupełnie do kitu. Oczywiście potrzebna jest ciągła praktyka i stosowna edukacja (stety-niestety uczelnia, paradoksalnie, bardzo pomaga w rozwoju programisty, choćby forsując dotąd nieznany przez Ciebie język, który okazuje się strzałem w dziesiątkę!). Z czasem skomplikowaną tablicę nazwiemy dojrzale strukturą danych, a dane podejście wzorcem projektowym. Bez doświadczenia to tylko “ee no, Ty, jakoś podziałałem tym set_array() i forem i wyszło, hehe, a teraz idę na real, elo“.

Ciężko jest mi jednoznacznie ocenić, czy nie powinno się brać zleceń w młodym wieku, bo sam takie brałem, mając dziś świadomość, że kod nie był najlepszej jakości. Jednak to, co wyniosłem z moich, nazwijmy to, “programistycznych przygód” bardzo doceniam, bo wiem, że dało mi niesamowite podstawy, mimo że – można by rzec – bawiłem się w programowanie. Może powinniśmy jednak przenieść w czasie pobieranie pieniędzy za naszą twórczość, skupiając się na oprogramowaniu open source bądź własnych, szkolnych projektach? No właśnie. Czy szkoły poza olimpiadami i zawodami oferują jakiekolwiek możliwości do polepszenia swoich praktycznych umiejętności? Czy młodzież woli dostać dyplom i uznanie, czy też 50 złotowy banknot? Może to już tak musi być, że najpierw młodzi piszą słabe programowanie, które potem poprawia kolejny nowicjusz, kiedy pierwotny autor zahaczył się już o dobrą posadę głównego programisty w dobrym banku?

Czy eliminując problem niskich cen, nie narazilibyśmy się na poniższą zależność?

Mało ofert dla słabo doświadczonych programistów -> nikłe możliwości ich rozwoju -> słabi programiści

Z kolei teraz, mam wrażenie, wygląda to tak:

Niskie ceny -> mierna jakość produktów -> … -> … -> dobrzy programiści

Pytanie, jak wyglądają proporcje i ilu słabych programistów zostaje wyprodukowanych na końcu tego procesu? Takich pytań jest więcej.

Dyskusja na temat jakości oprogramowania za niską cenę, paradoksalnie, niesie ze sobą wiele aspektów – finansowych, edukacyjnych, ale i – w pewnym sensie – społecznych. Z pewnością nadal będziemy mieć do czynienia z ofertami, podobnymi do tej wymienionej we wstępie. Myślę jednak, że padło na tyle dużo pytań, by więcej nie bagatelizować poruszonego tutaj problemu i odpowiedzieć na nie każdy osobno.

1. Swoją drogą widać jak na dłoni popularność Wykopu. Obecnie bardzo rzadko pojawiają się (a przynajmniej mam takie wrażenie) wpisy zahaczające o web, nie mówiąc już o polskiej blogosferze technicznej (choć tutaj nie narzekałbym – wykopywanie trupa to zadanie mało przyjemne). Macie jakiś plan ratunkowy? ;-)

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.

Powyższa, stereotypowa opinia zapewne nie wykluła się bez podstaw – jest (choć trend ten zanika wraz z coraz mniejszą liczbą polskich blogerów) trochę osób, którym wydaje się po takich spotkaniach, że sięgnęli nieba. Również ton w jakim pisuje się o Aulach, Barcampach itd. nie zachwyca – jest buńczuczny i pełen patosu. Razi to szczególnie, kiedy event poświęcony jest sprawom oczywistym i końcowe wnioski nie zachwycają niczym szczególnym.

Niemniej postanowiłem dać szansę Boostrapowi. Majowa edycja odbyła się, jak zawsze, w klimatycznej kawiarni przy ulicy Chłodnej 25 w Warszawie 9. maja. Miejsce niezwykle urokliwe, choć jak to w stolicy bywa – leżące wręcz na pograniczu PRLowskich kamienic na Woli i wielkiego, biurowcowego biznesu. Bardzo sympatyczna atmosfera wewnątrz była więc dobrym prognostykiem przed właściwym tego dnia głównym punktem programu.

Zaplanowany na 12:00 start odbył się jednak z małym poślizgiem. Przyczyną był, zwyczajowo że tak powiem, sprzęt Apple, a konkretnie niekompatybilny z rzutnikiem laptop ichniej firmy. [Tutaj miejsce na mały flame]. Co jeszcze zaskoczyło to zmiana kolejności prezentacji. Rozumiem, że Bootstrapowi bliżej do spotkań nieformalnych, jednak tego typu zagrywka nie powinna mieć miejsca, tym bardziej zakładając, że ktoś chciał posłuchać tylko pierwszej, planowej prezentacji.

W efekcie, Bootstrap zaczął Artur Kuć z SalesGuru.pl. Było o tym, jak freelancerzy powinni komunikować się z klientami. O ile Artur nie sprzedawał słuchaczom jakichś trudno dostępnych nowinek, tak w mądry sposób zebrał i przedstawił wszelkie wytyczne dot. komunikacji, które, do czego również się przyznaje, czasem bagatelizujemy. Brakowało mi jednak najważniejszego – kim Ty człowieku jesteś i jakie masz osiągnięcia. Kiedy i jak zastosowałeś (bądź Twoi klienci zastosowali) swe porady w praktyce? To w zasadzie małe wady prezentacji, która wypadła bardzo pozytywnie. Zawsze jednak mogło być lepiej.

Po Arturze zaczęła przemawiać Helena Pryłowska z helen.pl. Helen opowiedziała, jak powinniśmy rozmawiać z designerami. Przy okazji dowiedzieliśmy się trochę o jej stylu pracy (zgaduje, że tyczy się on przynajmniej większości profesjonalnych grafików). W zasadzie nie mam do czego się przyczepić – prezentacja była solidna, wnioski również, choć raczej gruntowały wiedzę osób, które wykonały już kilka projektów we współpracy z grafikiem. Dla nowicjuszy mogła być to cenna lekcja. Irytowała natomiast rozmowa, która zrodziła się po tej prezentacji. Ktoś z publiczności próbował stanowczo przeintelektualizować podejście do designu, pytając o… sam nie wiem co. W każdym razie padło coś na temat prostota versus złożoność. Pytanie jednak było tak niezgrabnie postawione, że radziłbym autorowi pójście na kurs prostoty. Nie designu, lecz wypowiedzi.

Ostatnim punktem programu była winda na boostrap – czyli dwa, pięciominutowe wystąpienia chętnych osób. I tak, Michał Śliwiński z nozbe.com szuka biura (bądź kawiarni) na Bemowie i okolicach(?), w którym mógłby popracować parę godzin i wrócić szybko do domu. Przy okazji możecie skontaktować się z Michałem, jeśli poszukujecie pracy jako PHPowiec i programista jQuery.

Następnie wystąpił Jacek Szczap z przystanku Praga, stając się, w moim mniemaniu, gwiazdą tej edycji Boostrapa. Wyliczył on, że zarobi 60 milionów złotych na serwisach lokalnych (typu wspomniany przystanek czy też portel.pl) innych miast. Oczywiście, od razu z widowni padły kontrargumenty (obecność i konkurencja wielkich portali, wyliczenia z kosmosu, hurraoptymizm), świadczące o bezsensowności tego pomysłu. Niemniej jednak, to co mnie uderzyło, to nieprawdopodobna pasja i swego rodzaju romantyzm. W zasadzie prezenter (Pan w okolicach 50-tki) zbył wszystkie docinki Pana od trudności z wyrażaniem myśli tym, że to nie pieniądze zdecydują o sukcesie, a klimat wokół serwisu i pewne poczucie własnego miejsca w internecie mieszkańców dzielnic czy osiedli. O ile więc od wszystkiego bił, trzeba przyznać, jakiś wielki, bezzasadny optymizm, tak z mojej perspektywy kibicuję z całego serca tej inicjatywie, ponieważ… ten człowiek był najbardziej wiarygodny z całej czwórki! Oto przyszedł normalny mężczyzna rodem z warszawskiej Pragi, jakby zupełnie oderwany od trendseterskiej kasty Wielkich Twórców Startupów z Macami na Kolanach i 1000 Subskrybowanych Blogów, Wiedzących Wszystko. Nie było tutaj ni krzty cwaniactwa czy owijania w bawełnę. Przyszedł człowiek z marzeniami na ustach. Oczywiście, może się nie udać, lecz zawsze warto próbować, tym bardziej, jeśli nie uzależniamy od projektu swojego być albo nie być. Myślę, że teza ta mogłaby stać się eo ipso mottem sobotniego spotkania. Z ciekawości sprawdziłem, kim dokładnie jest Jacek Szczap i oto, co znalazłem w Google:

W mediach i w marketingu od poczatku lat 90-tych. Specjalista w zakresie marketingu internetowego i promocji sprzedaży. Pracował w największych polskich redakcjach (Gazeta Wyborcza, Prószyński i S-ka, Super Express) – zajmując się grami, konkursami i działaniami promocyjnymi dla gazet, magazynów, radia, audioteksu i stron internetowych. Był m.in.redaktorem naczelnym pisma “Manager” a także dyrektorem marketingu w “Rzeczpospolitej”.

W 1998 – założyciel i prezes Family Games – pierwszej polskiej firmy specjalizującej się wyłącznie w konkursach i grach promocyjnych. Obecnie prowadzi Media Games – firmę zajmującą się marketingiem interaktywnym (gry, konkursy, marketing w Internecie, one-to-one marketing, marketing prasy), promocją sprzedaży i szkoleniami marketingowymi. Ceniony również jako konsultant i szkoleniowiec.

Twórca wielu konkursów i gier. Pracował m.in. dla takich firm i marek jak Tesco, SMG/KRC, Hager, Polar, Heineken, WSIP, Eidipresse, Agora, Kostrzyn Paper i wielu innych.

Autor licznych artykułów o tematyce marketingowej w prasie branżowej (Marketing W praktyce, Impact, Manager i in) a także w prasie codziennej (Gazeta Wyborcza).

Wykładał na wielu seminariach i konferencjach o tematyce marketingowej i przeprowadził wiele szkolen marketingowych współpracjując m.in. z takimi firmami szkoleniwymi jak Midwest, Eskadra, Infor Training

Prywatnie mąż, ojciec dwóch synów, miłośnik łamigłówek, gier, gór, kung-fu i tai-chi.

Jeśli Pan Jacek w marketingu jest tak samo skuteczny, jak w zjednywaniu sobie ludzi, wróżę jego projektowi wiele sukcesów.

Podsumowując, odsunąłem w kąt wszelkie stereotypowe myślenie na temat Boostrapa. Nie zastałem tam żadnego pieniactwa, poczucia wyższości czy czegoś w tym rodzaju (może dlatego, że nie było Artura Kurasińskiego? He he.) Z drugiej strony, czasami zbyt luźna atmosfera nie każdemu może się spodobać, choć jest to, zważywszy na całokształt imprezy, pigułka całkowicie do przełknięcia.

Naszym celem jest stworzenie przypisów dolnych tak, aby wyglądały jako boczne, zupełnie jak na tym blogu. Jeśli w jakimś akapicie znajdzie się odnośnik do przypisu, jego treść powinnna pojawić się z prawej strony akapitu (tagu <p />). Zacznijmy od semantycznego szablonu:

<div class="article">
	<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus massa. Fusce sed erat. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Suspendisse auctor neque id purus. Ut dignissim felis et velit suscipit fringilla. Aenean et est et lacus interdum rutrum.<a href="#przypis-1" class="hint"><sup>1</sup></a> Nam iaculis ipsum vel neque blandit placerat. Cras dui elit, varius at, gravida a, consectetur ut, elit. Donec turpis. Fusce quis sapien ac nisl lobortis eleifend. Morbi posuere, massa vel fermentum commodo, arcu quam fermentum turpis, vel tincidunt ante odio at arcu. Sed vitae purus.</p>
	<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus massa. Fusce sed erat. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Suspendisse auctor neque id purus. Ut dignissim felis et velit suscipit fringilla. Aenean et est et lacus interdum rutrum. Nam iaculis ipsum vel neque blandit placerat. Cras dui elit, varius at, gravida a, consectetur ut, elit. Donec turpis. Fusce quis sapien ac nisl<a href="#przypis-2" class="hint"><sup>2</sup></a>lobortis eleifend. Morbi posuere, massa vel fermentum commodo, arcu quam fermentum turpis, vel tincidunt ante odio at arcu. Sed vitae purus.</p>
	<hr />
	<ol id="notes">
		<li id="przypis-1">First note</li>
		<li id="przypis-2">Second note</li>
	</ol>
</div>

Jak widać, kontenerem dla artykułu jest .article, odnośnikami do przypisów są linki .hint. Domyślne przypisy dolne tworzy lista #notes.

Pora na trochę podstawowych CSSów. Wypozycjonujmy treść, nadajmy odpowiednie typy fontów i tak dalej:

* {
	padding: 0;
	margin: 0;
}
a {
	text-decoration:none;
	color: #7EBB1F;
	font-weight: bold;
}
a:hover {
	background-color: #7EBB1F;
	color: #fff;
}
.article {
	width: 960px;
	margin: auto;
	font: normal 14px 'Lucida Sans Unicode', Arial, Helvetica, sans-serif;
}
.article p {
	margin-bottom: 20px;
	line-height: 20px;
	width: 680px;
}

Generalnie, cel jest następujący – jeśli mamy włączony JavaScript usuwamy listę numerowaną <ol#notes />, a jej elementy zmieniamy na <p /> i umieszczamy pomiędzy stosownymi akapitami artykułu. To teoretyczny opis. W praktyce będzie to zrobione nieco inaczej.

Poszukamy akapitów, które linkują do określonych przypisów. Jeśli dany akapit zawiera link .hint to dodajemy zaraz po nim stosowny przypis. Treść przypisu pobierzemy na podstawie identyfikatora, który znajduje się po hashu (#) w linku-odnośniku.

Najpierw jednak zajmijmy się sytuacją, kiedy mamy wyłączony JavaScript:

.article hr {
	border: none;
	border-top: 1px solid #7EBB1F;
	width: 680px;
	float: left;
	margin-bottom: 10px;
}
.article #notes {
	clear: left;
}
#notes li {
	font-size: 11px;
	width: 680px;
	margin-bottom: 3px;
	line-height: 15px;
	font-style: italic;
}

Powyższym ostylowaliśmy przypisy dolne – w końcu jeśli JavaScript będzie wyłączony, to będzie trzeba jakoś je zaprezentować. Warto sprawdzić efekt.

Fajnie jednak byłoby, gdyby jakiś aktywny przypis (tzn. ten, w który kliknęliśmy) został nieco wyróżniony. Zrobić możemy to dzięki selektorowi :target:

#notes li:target {
	font-weight: bold;
}

Oznacza to, że jeśli w linku pojawi się identyfikator jakiegoś tagu <li /> np. przypis1.html#przypis-2 to treść tego tagu (tutaj: < li id=”przypis-2″ />) zostanie wyboldowana. Wynika na to, że załatwiliśmy problem wyłączonego JavaScriptu.

Zajmijmy się teraz odpowiednimi skryptami, które przeniosą elementy z listy #notes pod stosowne akapity. Skorzystamy w tym celu z jQuery.

Najpierw należy poszukać wszystkich linków .hint w obrębie artykułu .article:

$().ready(function() {
	$('.article .hint').each(function(i, element) {

Dzięki funkcji each przeiterujemy się przez wszystkie znalezione odnośniki do przypisów. Pierwsze, co powinniśmy zrobić, to znaleźć akapit, który jest rodzicem danego linku:

$().ready(function() {
	$('.article .hint').each(function(i, element) {

		var parent = $(element).parent('p');

Następnie pobieramy adres linku, by uzyskać identyfikator przypisu, do którego się on odnosi:

$().ready(function() {
	$('.article .hint').each(function(i, element) {

		var parent = $(element).parent('p');
		var id = $(element).attr('href');

Tym sposobem pod zmienną id będą następujące wartości:

• #przypis-1
• #przypis-2
• itd.

Pora pobrać treść przypisu na podstawie jego ID i uformować nowy akapit z przypisem:

$().ready(function() {
	$('.article .hint').each(function(i, element) {

		var parent = $(element).parent('p');
		var id = $(element).attr('href');

		var note = $(id).html();

		var newNote = $('<p class="note"><sup id="'+id.replace(/#/g, '')+'">'+(i+1)+'</sup>'+note+'</p>');

Szczególnie istotna jest tutaj 8. linijka:

var newNote = $('<p class="note"><sup id="'+id+'">'+(i+1)+'</sup>'+note+'</p>');

Otóż dzięki niej tworzymy nowy tag drzewa DOM jakim jest <p />. Oczywiście ubieramy go w stosowne wdzianko - nadajmy class="note" - tak, by potem można było ostylować przypis boczny. W nowym przypisie umieszczamy również indeks w <sup />, korzystając ze zmiennej i z pętli each - jej wartość zaczyna się standardowo od zera, więc należy dodać jeden, by otrzymać zwykłe odliczanie od 1. Znacznik sup musi mieć dobry identyfikator bez hasha na początku. Wyrzucamy więc "#" przez id.replace(/#/g, '').

Trzeba jeszcze zająć się pozycjonowaniem przypisu tak, by był wertykalnie nieco bliżej jego odnośnika .hint. Spróbujemy ustawić tak dobrany, ujemny margin-top, by nie było zbytnich przerw pomiędzy wspomnianym linkiem i akapitem z przypisem.

$().ready(function() {
	$('.article .hint').each(function(i, element) {

		var parent = $(element).parent('p');
		var id = $(element).attr('href');

		var note = $(id).html();

		var newNote = $('<p class="note"><sup id="'+id.replace(/#/g, '')+'">'+(i+1)+</sup>'+note+'</p>');

		newNote.css('margin-top', (parseInt($(parent).css('margin-bottom')) + ($(parent).height() + $(parent).offset().top) - $(element).offset().top) * -1);

Stosowny margines górny ustawiamy na podstawie prostego wyliczenia. Sumujemy wysokość i odległość od początku strony całego akapitu, a następnie od tej sumy odejmujemy odległość linku od początku strony. Odległość od początku strony możemy pobrać przez jQuery'owe offset().top, a wysokość przez height(). Do wszystkiego dodajemy jeszcze margines dolny akapitu, w którym mieści się link. Wszystko mnożymy razy minus jeden, by uzyskać ujemny margines dla naszego przypisu. Oto rysunek poglądowy, jak wyliczamy margines:

Pora dodać nowy przypis pod stosowny akapit i zakończyć pętlę each:

$().ready(function() {
	$('.article .hint').each(function(i, element) {

		var parent = $(element).parent('p');
		var id = $(element).attr('href');

		var note = $(id).html();

		var newNote = $('<p class="note"><sup id="'+id.replace(/#/g, '')+'">'+(i+1)+'</sup>'+note+'</p>');

		newNote.css('margin-top', (parseInt($(parent).css('margin-bottom')) + ($(parent).height() + $(parent).offset().top) - $(element).offset().top) * -1);

		newNote.insertAfter(parent);

});

Na koniec musimy jeszcze usunąć przypisy dolne, które nie są już nam potrzebne:

$().ready(function() {
	$('.article .hint').each(function(i, element) {

		var parent = $(element).parent('p');
		var id = $(element).attr('href');

		var note = $(id).html();

		var newNote = $('<p class="note"><sup id="'+id.replace(/#/g, '')+'">'+(i+1)+</sup>'+note+'</p>');

		newNote.css('margin-top', (parseInt($(parent).css('margin-bottom')) + ($(parent).height() + $(parent).offset().top) - $(element).offset().top) * -1);

		newNote.insertAfter(parent);

	});

	$('#notes').prev('hr').remove();
	$('#notes').remove();
});

Wynik naszej zabawy nie wygląda jednak zbyt atrakcyjnie.

Pora dodać stosowne style dla .note:

.article .note {
	float: right;
	background-color: #FBF1AB;
	border: 1px solid #ECD42B;
	width: 162px;
	padding: 4px;
	overflow: hidden;
	font-size: 12px;
}
.article .note sup {
	float:left;
	font-size:20px;
	vertical-align: bottom;
	margin-right: 5px;
	text-align: center;
	width: 30px;
}
.article .note sup:target {
	background: #FBEA71;
}

Jest całkiem nieźle!

Można by co prawda zwiększyć widoczność odnośników do przypisów:

.article .hint {
	margin-right: 10px;
}
.article .hint sup {
	font-size: 14px;
}

Działa wyśmienicie!

Zastosowane tutaj rozwiązanie ma w zasadzie tylko jedną wadę - nie należy nadużywać przypisów w jednym akapicie, ponieważ mogą one na siebie nachodzić, tworząc dość nieprzyjemny efekt. Oczywiście możemy nie stosować pozycjonowania względem odnośnika, usuwając linijkę odpowiedzialną za ustawianie górnego marginesu. Wtedy możemy stawiać przypisy gdziekolwiek i w jakiej ilości chcemy.

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ą…

Nieprzypadkowo przywołuje motyw samotnej żeglugi i pustych (prawie) butelek po rumie – przez długi czas to miejsce wyglądało na zupełnie opuszczone, a jedyne, co jako tako ratowało tę nędzę, to zebrane dotąd artykuły (prawie jak “wiadomość w butelce”!) i design, który wciąż mnie inspiruje.

Tłumaczą się tylko winni, ale wychodzę z założenia, że należy się Wam kilka słów wyjaśnienia. Przede wszystkim moje zasoby czasowe zostały znacząco uszczuplone przez pracę na pełen etat. Poza tym doszło kilka innych problemów, o których nie wypada tutaj wspominać. Do dzisiaj zastanawiam się, kto miał największy wpływ na moją opieszałość w publikowaniu. Lenistwo, czy zmęczenie. Strzelam, że to “coś” po środku.

W każdym razie – nie mam zamiaru kolejny raz usprawiedliwiać się i obiecywać przyszłego powrotu. Tym razem wracam definitywnie, aczkolwiek punkt widzenia zależy od punktu siedzenia i tym razem też tak będzie.

Uznałem bowiem, że o ile nie mam żadnych zastrzeżeń do jakości zgromadzonych tutaj treści, tak kierunek w którym idę (w zasadzie szedłem…) jest dla mnie rujnujący. Jestem z natury człowiekiem solidnym. Nie lubię fuszerki podpisanej swoim nazwiskiem (stąd też między innymi zamiast krótkiego “wracam” dłuższa notka). Niemało Czytelników na pewno zauważyło, że gros materiałów ma ponadprzeciętną długość. Wymagam jednak od siebie wyczerpania tematu w każdej z podejmowanych przeze mnie kwestii. Dlatego też teksty są przeważne bardzo obszerne i co za tym idzie włożony został w nie duży wysiłek. Tak od początku nakazywała konwencja tego bloga – jak najprościej, jak najjaśniej, jak najobszerniej!

Pora zamknąć pewien rozdział. Ferrante.pl nie będzie już skupiać się na absolutnych podstawach programowania w JS. Uznaje, że obecny materiał porusza większość podstawowych zagadnień. Od dziś skupimy się na rzeczach bardziej mi bliskich – zaawansowanym JavaScript’cie, CSS’ie itd. Dotąd funkcjonowaliśmy, przyznacie, od artykułu do artykułu, a przerwy między nimi potrafiły oscylować w granicach miesiąca. To się zmieni.

Zakładam, że ferrante.pl powinien być czytany jako dobry, programistyczny pamiętnik, a nie jako zbiór artykułów, gdzie każdy traktuje o czymś innym. Będzie o wiele więcej prywaty i publicystycznego charakteru bloga.

Wybieram też bardziej różnorodną treść. Postaram się oczywiście nawiązywać do front-endowej tematyki w każdym z postów, aczkolwiek nie mam zamiaru kontynuować polityki, która zrobiła z tego bloga prawie że wortal o JS. Zapewne początki nie będą wymarzone, ale przeżyłem naprawdę duży deficyt weny, bombardowany przez permanentny brak czasu. W skrócie – inna forma, jakość ta sama!

Idzie nowe

Abstrahując od przeszłych problemów, na horyzoncie widać bardzo ciekawe rzeczy. Pracuję intensywnie nad nowym projektem (tematyka? CSS!), którego jeszcze w Polsce nie było. Jeśli o innowacje chodzi nie rzucam słów na wiatr. Wkrótce powinno się więcej wyklarować, na razie postawiliśmy pierwsze, standardowe kroki – domena, wstępny koncept.

Ostatnio wiele czasu poświęcam na programowanie w JAVA. Zapewne usłyszycie ode mnie o tym języku jeszcze nie raz. Być może, po małym retuszu, opublikuje też prostą w użyciu bibliotekę formularzy w PHP. Szczerze powiedziawszy, bardzo zdystansowałem się od tego języka, dostrzegając wady, na widok których wcześniej przymykałem oczy.

Z prywatnych spraw zamierzam też nauczyć się języka hiszpańskiego (Argentyna!) oraz wejść nieco głębiej w temat fotografii. Odkładam te rzeczy na później średnio co tydzień, także jak na dłoni widać, że wolny czas nie jest moją dobrą stroną (między innymi z tego powodu zacząłem coraz mocniej interesować się technikami zarządzania czasem, którymi swego czasu nieco gardziłem).

Co tam Panie w polityce?

Mimo wszystko nie przestałem czytywać polskich blogów. Trzeba jednak szczerze przyznać, że bardzo mało się tutaj dzieje. No, wyłączając może ich coraz częstsze zamknięcia. Większość rodzimych blogów jest nudna, jak flaki z olejem. Brakuje nawet porządnych flame’ów. Z tego wszystkiego zacząłem odwiedzać częściej blogi fotograficzne.

Mówiąc jednak poważnie – pokażcie mi ciekawy blog o front-endzie w języku polskim. Można spamować w komentarzach. Z chęcią przekonam się, czy się mylę, ale wydaje się, że w Polsce nie ma już nikogo (ostatni był chyba Riddle), kto potrafiłby napisać coś ponad tłumaczeniami nowych usług w Google lub API w jQuery. Co prawda współdziałający równolegle z blogosferą ruch spotkań startup’owych typu Barcamp ma się całkiem dobrze, ale to zupełnie nie tłumaczy zastoju. Podpisuje się zresztą pod opinią, którą znalazłem bodaj u RAFiego:

shpyo:

Wiecie jak to z polskimi specami od web20 jest. Nie udało im się odpalić czegoś fajnego, to zostali krytykami ;>

Krytyka, krytyką, trzeba jednak przyznać, że koncepcja blogów zaczyna się wypalać. Oczywiście do filtra jeszcze daleko, ale sytuacja nie jest zbyt zachęcająca. Długoletni bloggerzy niechętnie wymieniają stalówki swoich piór (choć tacy, jak – żeby długo nie szukać – CoSta, trzymają się mocno), a świeża krew ma problem z wypromowaniem się lub też świeżej krwi w ogóle w polskiej blogosferze nie ma. Pokażcie się! Nie ukrywam, że będę starał się poruszyć jeszcze ten temat. Ba, jeden z moich projektów jest z tym ściśle związany.

Tymczasem Ferrante.pl obchodziło cztery dni temu drugą rocznicę powstania. Sam fakt, że wspominam o tym dopiero teraz mówi wiele na temat mojej pisarskiej kondycji. Założenia urodzinowe nie są już tak ambitne, jak rok temu. Czasem, niestety, ambicja potrafi zagłuszyć zdrowy rozsądek, dlatego obecnie chcę po prostu… pisać. Regularnie i dobrze. Zapraszam do kibicowania.

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ś?

MVC to nic innego, jak skrót od Model View Controller. Jest to wzorzec projektowy (a więc zbiór pewnych reguł, według których budowane są aplikacje na całym świecie), który cieszy się bardzo dużą popularnością wśród webdeveloperów.

Nie wiem, jak dotąd projektowałeś swoje aplikacje PHP. Jeśli robiłeś to strukturalnie, w oparciu o funkcje, ten artykuł raczej nie jest dla Ciebie – co prawda można użyć MVC w podejściu strukturalnym, byłaby to jednak w pewnym sensie kpina ze sztuki. Kod strukturalny w PHP jest, może już to gdzieś słyszałeś, niczym źle przyrządzone spaghetti – wygląda, jak nie wiadomo co i w dodatku ucieka z talerza.

Jeśli z kolei znasz i wiesz na czym polega programowanie obiektowe, mamy o czym ze sobą rozmawiać. Zacznijmy od teorii.

Z reguły proste aplikacje w PHP wyglądają tak, że sprawdzany jest adres wpisany do przeglądarki (na podstawie $_GET, bądź innych właściwości z $_SERVER), potem includowane są potrzebne pliki w zależności od pozyskanych danych. Absolutne podstawy podstaw.

Stosując MVC nie możemy opierać się, jak to zwykle bywa w tradycyjnym podejściu, tylko na jednym pliku, np. index.php, w którym mieszamy kod prezentacji (np. HTML) i logikę biznesową (dane np. z MySQL).

Działa to zupełnie inaczej, a mianowicie mamy 3 główne elementy aplikacji, gdzie każda odpowiedzialna jest tylko za jedną rzecz. Są nimi:

• Controller steruje wszystkim tym, co dzieje się podczas uruchamiania danej akcji. Np. podczas wywołania index.php?controller=news&id=55.

  Przykładowo, jeśli dodasz np. nowego usera do bazy, to kontroler zdecyduje, że po tej czynności przeniesiony zostaniesz np. do edycji profilu. Kontroler to mózg sterujący całym wywołaniem strony. W pliku kontrolera wybierasz, z którego modelu (a więc pliku odpowiedzialnego za pobieranie danych – może to być baza danych, plik, cokolwiek) weźmiesz treść dla strony, a także jak ją wyświetlisz (czyli który widok Cię interesuje).

• Model zajmuje się tylko i wyłącznie pracą na danych.
• Widok (View) zajmuje się tylko i wyłącznie wyświetlaniem danych.

I tak, dobrą praktyką jest umieszczanie kontrolerów w folderze np. /controllers, widoków w /views, a modeli w /models. W ten sposób mamy jasny i prosty podział naszej aplikacji.

Jeśli więc uruchomimy przykładowo stronę index.php?controller=news&param=55, według MVC powinny dziać się następujące rzeczy:

• Dzięki takiemu parsowaniu adresów możemy łatwo zarządzać i dołączać kontrolery, które będą stanowić serce aplikacji. Po co stosować switch czy if do sprawdzania, co zostało wpisane w pole adresu, skoro możemy od razu, jeśli takowy istnieje, dołączyć stosowny plik.

  Funkcja/Klasa odpowiedzialna za parsowanie adresu (np. Router) pobiera go i na podstawie konfiguracji stwierdza, które słowo/zmienna w adresie oznacza kontroler, a które parametry doń przekazywane. Posiłkując się powyższym URL, kontrolerem będzie słówko news, a parametrem 55.

  Następnie, na podstawie uzyskanych danych, includujemy potrzebne pliki. Jak już się przekonaliśmy, potrzebny nam jest kontroler. Sprawdzamy więc, czy w folderze, który umownie wybraliśmy (controllers) znajduje się plik news.php (tak, news pochodzi z adresu strony).

• Następnie, mając załadowany kontroler, uruchamiamy jego defaultową metodę/funkcję, bo oprócz nazwy kontrolera nie mamy niestety nazwy żadnej jego akcji, którą moglibyśmy wywołać (gdyby adres miał postać index.php?controller=news&action=delete&id=55, można by posłużyć się zmienną $_GET['action'] i uruchomić coś takiego: $controller->$_GET['action']($_GET['id']). W takim razie używamy $controller->index(), bądź coś podobnego – wszystko zależy od konfiguracji.

  Nie muszę chyba też przypominać, że dane $_GET należy przefiltrować pod kątem złośliwych ataków. Z reguły robi to klasa odpowiedzialna za parsowanie adresu, bądź specjalna klasa obsługująca dany request (wywołanie adresu) pod kątem danych przekazanych przez użytkownika.

Od strony kodu, przykładowe wywołanie MVC wygląda następująco:

//index.php

$controller = Router::getController();
$controller = new $controller;
$action = Router::getAction();

$controller->$action(Router::getParams());

//controllers/news.php

class news_Controller extends Controller
{
	public function index($params)
	{
		$model = Router::getModel(); // // pobierze Model
		$model = new $model;

		$view = Router::getView(); // pobierze Widok
		$view = new $view; 

		$data = $model->getData($params); // pobiera dane z Modelu
		$view->setData($data); // przekazuje dane do Widoku, by ten mógł je wyświetlić
		$view->Render(); // wyświetli stronę
	}
}

Zalety MVC:

• Oddzielenie logiki biznesowej od warstwy prezentacji. Nie mieszamy znaczników HTML z zapytaniami SQL czy innymi konstrukcjami, nie mającymi ze sobą nic wspólnego.
• Przejrzystość aplikacji
• Łatwość rozbudowy
• Duża konfigurowalność
• MVC narzuca określony styl kodowania, ze strukturą katalogów włącznie, co w przypadku PHP ma duże znaczenie
• Łatwość utrzymania aplikacji
• i wiele innych

Artykuł ten to tylko zalążek tego, co można by powiedzieć o MVC. Postanowiłem przedstawić temat powierzchownie, ale na tyle wystarczająco, aby można było łatwo dowiedzieć się, z czym to, przysłowiowo, się je.

Kto wie, jeśli zainteresowanie tematem będzie duże, spróbuję rozbudować materiał, tworząc tutorial, jak zbudować framework oparty o MVC. Decyzja należy do Was.

Utrwaliło się dość mocno w świadomości pracodawców i wszelakich branżowych decydentów, że Pan od wyglądu zewnętrznego aplikacji powinien znać także JavaScript. W swojej 6-letniej karierze webdevelopera jako takiego, wykonywałem prace frontendowca, jak i backendowca. I znacząco twierdzę, że obecny podział ról jest czasem (podkreślmy – czasem) dość rujnujący.

Doświadczenie nakazuje mi sądzić, że zrzucanie na frontendowca obowiązków, związanych z JavaScript nie jest zawsze słuszne. Prowadzi to często do dość drastycznych nieporozumień. Do wzajemnej irytacji dochodzi w momencie, kiedy backendowiec wchodzi na grunt frontendowca. Ma to miejsce w kilku punktach zapalnych, jak np. przy okazji implementacji przez backend wszelakich skryptów autosearch, autocomplete itd. i innych, całkiem już niecodziennych sytuacjach, przeważnie jednak wtedy, kiedy należy pobrać coś via AJAX i dodać różne efekty.

Nie każdy, kto zna CSS&HTML, ma też zmysł programistyczny. Nie ukrywajmy, że implementacja różnych animacji i bardziej skomplikowanych efektów wymaga dobrego przemyślenia problemu. jQuery, które przyszło na świat, zbawiając wielu koderów CSS, w większości nie pomoże, gdy przyjdzie zakodować coś bardziej innowacyjnego. Czy ktoś, kto posiada zmysł artystyczny i estetyczny, zakoduje, w miarę sensownie, małą webaplikację, o którą proszą się od miesięcy backendowcy dla ich CMSa?

Osobiście znam kilku świetnych koderów CSS, którzy z JS są na bakier, przyznając jednocześnie, że to ich boli i stawia w trudnej roli na rynku pracy:

Po prostu nie mam smykałki do tego – mam okrutnie schematyczny mózg. HTML i CSS maja swoje reguły, które łatwo pojąc, JS nie ogranicza nic i to mnie właśnie przeraża.

Są oni za to świetnymi grafikami, co z kolei nie zawsze idzie w parze z naszym kochanym, frontendowym trio (CSS, JS, HTML). Wypada znaleźć alfę i omegę, prawda?

W zasadzie można by wyróżnić trzy profile frontendowca:

• design www, css, html, js, seo, usability, doświadczenie z php – tzw. alfa i omega i teoretycznie najlepszy kandydat
• css, html, js, biegła znajomość Photoshopa w zakresie cięcia grafiki i jej obróbki, seo, usability – tzw. złoty środek – człowiek nie zna się na grafice, co pozwala domniemywać, że do czynienia mamy z umysłem ścisłym i dobrym programistą JS
• design www, css, html, seo, usability – tzw. pożyteczny grafik, po prostu

Oczywiście najlepszym wyborem jest pierwsza opcja. Zna się na programowaniu, ma zmysł graficzny. W swoim życiu spotkałem tylko jedną, no, może dwie takie osoby, w dodatku jedna z nich, z tego, co wiem, absolutnie oddała się teraz kodowaniu. Trudnodostępny okaz, potwierdzający regułę, że umie się wszystko i nic. Połączenie tych funkcji doprowadziłoby do eksploatacji jego chęci i entuzjazmu do pracy na miarę kopalni węgla w Wałbrzychu.

Druga opcja to dobry wybór, jeśli mamy w zespole grafika, który zajmuje się tylko i wyłącznie… grafiką. Z reguły duet ten sprawdza się świetnie i jest najpopularniejszym rozwiązaniem – mamy w zespole artystów pędzla i klawiatury. Trzeci typ to także popularna konfiguracja, która nastręcza jednak dużo problemów, ze względu na nieznajomość JavaScript. Pytanie, co zrobić? Nauczyć się JS albo zginąć? Odpowiedź jest dwuznaczna – rynek jest bezlitosny i znajdzie się niejeden, kto nie wyobraża sobie zatrudnienia osoby bez znajomości JS, całkiem słusznie zresztą. W takim razie, w okolicznościach kompletnej i permanentnej niechęci do programowania, wypada zainwestować w grafikę bądź… liczyć na pracodawców, którzy preferują rozdzielenie funkcji na kodera JS i kodera CSS&HTML. Takich spotkałem za granicą, a w Polsce, paradoksalnie, w Gronie…

Aktualnie pracujemy nad nową wersją Drawtera, gdzie możemy pozwolić sobie na duży rozrzut obowiązków. Jedna osoba zajmuje się tylko i wyłącznie ergonomicznym designem, druga tworzy semantyczny kod CSS&HTML, a trzecia zajmuje się JS i sprawami backend. Nie wyobrażam sobie stresu i nawału pracy, jaki spotkałby kodera, łączącego te dwie pierwsze funkcje, a już na pewno nie wszystkie na raz. W przypadku małych serwisów może by się to udało, jeśli chodzi zaś o większe – uważam to za katorgę.

Moja konkluzja jest następująca – najbardziej wydajnym eksperymentem jest rozdzielnie funkcji na programistę JS oraz CSS&HTML, ale tylko wtedy, jeśli to ma rzeczywisty sens projektowy – tzn. wtedy, kiedy koder JS będzie miał dwa razy więcej pracy, niż normalnie. Nielogiczne byłoby rozdzielnie tych obowiązków w obliczu klepania skryptów accordion.

Jeśli zaś chodzi o normalne warunki pracy frontend – warto, by programiści backend znali dobrze JS – pozwala to uniknąć kilku nieporozumień. Co z koderami CSS bez znajomości JS? Czy skazani są na grafikę bądź nowoczesnych pracodawców, mających dla nich zbawienny etat? Z chęcią poznam Wasze opinie!

Nie, to nie jest lead wywiadu z Januszem L. Wiśniewskim. Przypadkowo buszując po tabloidach Gazety.pl trafiłem na, nazwijmy to modnie, startup odezwijsie.pl, skąd zapożyczyłem tenże ekscentryczny wstęp.

Pomijając fakt, że strona jest zrobiona na odwal się, a podobną grafikę widzieliśmy już w 100 innych miejsach webeo dwaeo zereo, to coś w tym pomyśle niewątpliwie jest. Do tego stopnia, że radziłbym Panom z fotka.pl, naszej-klasy.pl, bądź grono.net mocno zainteresować się taką funkcją w ich serwisach. Jako oddzielny twór coś takiego to raczej chybiony pomysł (trolling, faking, spamming), jednak jako część dużego wortalu społecznościowego – cud, miód, malina – dużo klikania, jeszcze więcej czytania bzdur o kimś innym. Isn’t it?