Moja frustracja kumulowała się od jakichś dwóch lat. Irytowało mnie swoją topornością prawie wszystko, w dodatku z zazdrością spoglądałem na przepiękny interfejs Mac OS X. Dziś z zachwytem rozpracowuję kolejne zakamarki tego systemu (Expose, Spotlight, gesty, dock, dashboard, mrr!), będąc też pod wrażeniem jakości wykonania całego laptopa. Na razie szukam dobrych aplikacji umilających życie zwykłego użytkownika, jak i developera, także wszelkie porady mocno wskazane!

Wkrótce dam tutaj jakąś szerszą relację i zdjęcia, ponieważ rozwiązałem też problem dużego monitora pod postacią Della 3008 WFP.

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.

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

EditPlus, to, trzeba powiedzieć jasno, program dla bardziej zaawansowanych koderów. Nie znajdziecie w nim wielu gotowych snippetów, tak, jak to miało miejsce w CoreEditor. Dostępne są za to absolutnie podstawowe, takie jak wstawianie szablonów <script> i tym podobnych. Dobrą wiadomością jest to, że takowe można dodać własnoręcznie. Warto też wspomnieć, że EP nie oferuje edytora WYSIWYG pozwalającego rysować nasze strony.

Biorąc pod uwagę inne edytory, EP wygląda przy nich, jak biedny krewny z Kazachstanu. I, myślę, że o to właśnie tutaj chodzi. EditPlus jest szybki i wydajny. Pozwala zapisać dokumenty w UTF, również z nagłówkiem. EditPlus to fajne formatowanie tekstu – można zmieniać wielkości liter, zmieniać spacje na tabulatory i odwrotnie. Także kolorowanie składni jest w pełni edytowalne. Można zwijać prosto kod, dzięki code folding. Łatwo odróżnimy taby od spacji, a skróty klawiszowe pozwolą nam szybciej poruszać się po dokumencie i dostępnych opcjach.

Kiedy mówisz szybka edycja kodu, myślisz EditPlus! Program pozwala kompleksowo i błyskawicznie dostać się do konkretnych linii kodu, a jego przejrzystość i, paradoksalnie, archaiczny wygląd stawiają go obok NotePada+ na piedestale prostych i bardzo funkcjonalnych edytorów HTML, CSS, JS, a nawet, używając lekkiego nadużycia, PHP.

EditPlus jest programem płatnym, aczkolwiek warto wypróbować jego 30dniową wersję próbną.

–> EditPlus

Kiedy jakiś program zainteresuje mnie czymkolwiek, staram się go przetestować choć przez chwilę. Leniwa ze mnie bestia i z reguły tego typu zabawy kończą się w przeciągu 2-3 minut. Człowiek kliknie tu i tam, by zobaczyć, że nie ma nic nowego i kasuje program z twardego dysku. Z CoreEditor także nie wiązałem większych nadziei, byłem tylko ciekawy, głównie z sentymentu do EdHTML, co takiego oferuje jego oficjalny następca. Tym razem moje “testy” zakończyły się po 10 minutach, co jest wręcz niewyobrażalnym wynikiem, jeśli chodzi o moją osobę. Co prawda nie warto się spodziewać długiej listy pochwał, aczkolwiek należy wyróżnić CoreEditor pod paroma względami.

Pamiętam, że w swojej karierze, kiedy jeszcze XHTML był mgnieniem przyszłości, używałem w większości tagów pisanych wersalikami. Po rewolucji, w związku z którą porzucono tego typu pisownię, miałem niemały kłopot z przekonwertowaniem kodu na małe litery. Co prawda mogłem napisać program robiący to za mnie, ale jakoś nigdy do tego nie doszło, przez co większość stron z tamtego okresu pozostawała w swojej archaicznej postaci. Wielka szkoda, że nie było przy mnie CodeEditora. Między innymi właśnie zmiana tagów na xhtmlowe przykuła moją uwagę na dłużej. CoreEditor robi to bardzo sprawnie, jednym kliknięciem możemy poprawić skutki niewiedzy naszych współpracowników, którzy o XHTML nigdy nie słyszeli.

Co jeszcze utkwiło mi w pamięci z okazji kontaktu z edytorem to możliwość zmiany tego typu potworków: align=”left” na style=”text-align: left;”. Moduł ten jest w wersji beta, więc nie działa jeszcze sprawnie, aczkolwiek sprawił mi miłą niespodziankę.

Poza tym, CoreEditor jest, ku mojemu zdziwieniu, dość “lekki” i nie zabiera dużej ilości pamięci. Nie miałem okazji wypróbować go przy pracy z kilkunastoma zakładkami, bo zabraniała tego wersja demo, aczkolwiek przy mniejszej ich ilości było całkiem sympatycznie.

Standardowo, program Karola zawiera mnóstwo snippetów do wielu języków: php, html, js, czy mysql. Dołączone są też manuale i kursy. Plusem jest też domyślnie, świetne kolorowanie składni. Szczególnie w wypadku PHP. Przynajmniej jeśli o mnie chodzi, bardzo mi się podoba. Gdybym zaczynał, miałbym z pewnością słabe pojęcie o zmianie kolorowania składni, więc zaproponowane, defaultowe rozwiązanie tego problemu byłoby mi na rękę.

Myślę, że dla początkujących CoreEditor to świetny kombajn, pozwalający tworzyć dokumenty w wielu rozszerzeniach i systemach kodowania (utf8 ready!). Co prawda jest to program płatny, przez co liczba potencjalnych użytkowników zniwelowała się na starcie o połowę, ale z racji zawodu warto go okiełznać.

–> CoreEditor