Tutaj dowiesz się, co nowego w czwartej wersji. M.in. o wiele szybszy JavaScript, zmodyfikowany interfejs i wiele innych!

Polecam też zobaczyć jak szybko i w jakich ilościach jest pobierana nowa wersja Firefoksa. Jest też bardzo ciekawe Twitter Party – efekt „wow” murowany.

Biblioteka jest generalnie skierowana do trochę większych projektów, ale jakoś dało się zmieścić cały koncept w czymś dość prostym. Liczę, że uświadomi Wam to trochę, czym tak naprawdę jest Dataview.js.

Przyjmijmy, że mamy taki obiekt z danymi:

{
	name: "John Doe",
	arr: [1, 2, 3],
	obj: {
		foo: "bar"
	}
}

Modyfikują go w naszym systemie różne zdarzenia i moduły, na przykład takie:

$("#foo").click(function() {
	data.name = "Jan Kowalski;
});
$("#bar").pick(function(name) {
	data.name = name;
});

Można zaradzić takiemu swobodnemu dostępowi do danych przy użyciu Dataview.js.

Tworzymy najpierw obiekt Dataview:

var data = dataview({
	name: "John Doe",
	arr: [1, 2, 3],
	obj: {
		foo: "bar"
	}
});

Następnie musimy mieć odpowiedni widok, który będzie o tyle uprzywilejowany, że będzie zawierał metody, które jako jedyne będą mogły zmieniać cokolwiek w data:

var view = {
	updateName: function () {
		// [...]
		/this.update("Leonardo da Vinci"); // zaktualizuje imię i nazwisko
	},
	removeFromArr: function () {
		// [...]
		this.remove(1); // usunie element z pierwszego indeksu tablicy
	},
	addToObj: function () {
		// [...]
		this.add("key", "value"); // doda element "key" o wartości "value" do obiektu
	}
};

Musimy teraz spoić całość tak, by metody widoku rzeczywiście mogły korzystać z this.update/add/remove. Wszystko odbywa się poprzez specjalne połączenie widoku z danymi i funkcje connect oraz on. Pierwsza odpowiada za połączenie z widokiem, w drugiej definiujemy, które metody mają modyfikować wybrane przez nas własności:

data.connect(view).on({
	name: "updateName", // view.updateName zmodyfikuje 'name'
	arr: "removeFromArr", // view.removeFromArr zmodyfikuje 'arr'
	obj: "addToObj" // view.addToObj zmodyfikuje 'obj'
});

Można też to zrobić w ten sposób, Dataview jest bardzo elastyczny:

data.connect(view).on("name", "updateName").on("arr", "removeFromArr").on("obj", "addToObj");

Jeśli już połączyliśmy metody z odpowiednimi własnościami obiektu danych, pora używać metod widoku gdziekolwiek. I tak analogicznie może to wyglądać w ten sposób:

$("#foo").click(function() {
	view.updateName();
	view.removeFromArr();
	view.addToObj();
});
$("#bar").pick(function(name) {
	view.updateName(name);
});

Nasze dane wyglądać będą teraz tak:

{
	name: "Leonardo da Vinci",
	arr: [1, 3],
	obj: {
		foo: "bar",
		key: "value"
	}
}

Oczywiście możemy używać callbacków, by śledzić zmiany danych w obrębie aplikacji:

data.onRemove({
	arr: function (index) {
		console.log("Usunięto element z tablicy o indeksie:", index)
	}
});

view.removeFromArr();
// Usunięto element z tablicy o indeksie: 1

Do dyspozycji mamy też inne ich rodzaje: onAdd i onUpdate.

Największą jednak siłą Dataview jest to, że możemy łatwo sprawić, że zdefiniowane wyżej własności, jak wspomniałem, mogą być modyfikowane tylko i wyłącznie przez wybrane metody. Jak to zrobić? Z pomocą przychodzi funkcja lock():

data.connect(view).on({
	name: "updateName",
	arr: "removeFromArr",
	obj: "addToObj"
}).lock();

Pamiętaj, by zawrzeć ją zawsze na końcu „połączenia”.

W ten sposób nie możemy już dodawać nowych widoków do danych:

data.connect(view).on({
	name: "somethingElse"
});
// "Couldn't connect new methods. Locked property: name"

Ani też zmienić danych poza metodami, które zdefiniowaliśmy:

data.update("arr", 1, "new value");

Wartość tablicy arr na pozycji 1 nie zmieni się na new value.

O Dataview.js możecie poczytać na stronie biblioteki – Dataviewjs.com. Jest ona napisana zgodnie z duchem TDD, więc na GitHubie znajdziecie również testy jednostkowe.

Nie ukrywam, że jestem dumny z listy prelegentów, którą udało nam się stworzyć. Nie chcieliśmy, by prezentacje były odgrzewanymi kotletami, dlatego tematyka eventu jest bardzo różnorodna. Na pewno postawiliśmy na urządzenia mobilne. Będzie o tym jak projektować dla nich UX, o webOS, PhoneGapie, wydajności JavaScriptu i tak dalej. Opowiedzą o tym ludzie, związani z Nokią, Vodafone czy Palmem. Czy potrzeba do tego większej rekomendacji?

Ponadto, nie mogło obyć się bez nowości, jeśli chodzi o web development jako taki. Usłyszymy o HTML5, a także o CSS3 w dwugodzinnej sesji, omawiającej większość ficzerów tej wersji.

Całość dopełni panel dyskusyjny, który postara się odpowiedzieć na pytanie o przyszłość standardów sieciowych, a także JavaScriptu. W związku z tym prośba do Was. Jeśli chcecie zadać jakieś pytanie Douglasowi Crockfordowi, Tantekowi Çelikowi lub PPK, proszę zostawcie je w komentarzu pod postem. Prowadzimy ostateczne rozmowy, by panel był streamowany na żywo, a także dostępny w postaci video po konferencji.

Jeśli chodzi o inne, ważne informacje, wsparła nas Mozilla, która została oficjalnym partnerem Front-Trends. Jesteśmy z tego faktu dumni, tym bardziej, że organizacja ta wyznaje podobne wartości i przekonania do naszych. Oprócz tego, Zbigniew Braniecki i koledzy postarają się przygotować kilka niespodzianek dla uczestników. Nie mogę się doczekać!

Cały czas pracujemy nad nagrodami. Jeśli wszystko pójdzie po naszej myśli, trochę tego będzie, a mianowicie książki, telefony, sprzęt komputerowy oraz masa innych gadgetów. Trzymajcie kciuki, by wszystkie rozmowy poszły wzorowo.

Podsumowując, zapowiadają się bardzo ciekawe dwa dni. Jako organizator nie ukrywam, że jestem wyjątkowo podekscytowany, ponieważ będzie to zdecydowanie pionierskie przedsięwzięcie, jeśli chodzi o jego skalę. Wierzę, że Front-Trends zapoczątkują coś bardzo fajnego w polskim front-endzie. Szkoda tylko, że nie mam czasu, by blogować o bardziej technicznych sprawach. Jak zawsze mam nadzieję, że to się zmieni. Być może nie tutaj, a na innym blogu.

PS Zostało jeszcze trochę biletów – http://front-trends.com/registration

O co chodzi w Zen Coding? Popatrzcie na film instruktażowy. W skrócie jest to plugin, który pozwala w naszym edytorze napisać np. tak:

div#container>p.article

Po czym dostaniemy następujący kod:

<div id="container">
     <p class="article"></p>
</div>

Ja z kolei zaproponowałem coś takiego:

<div#container:p.article></p:div>

Niestety wyobraźni starczyło tylko na to, ale mogę być dumny, że byłem naprawdę blisko ;-). Przy okazji bardzo polecam koncept Zen Coding, który pozwala zaoszczędzić mnóstwo czasu!

Faktem jest, że nie miałem zbyt dużo czasu, by napisać więcej, w dodatku ręce automatycznie chciały ozdobić jakkolwiek tekst i wyszli z tego „szanowani front-endowcy z Makami”. Wierzę, że przebaczyliście mi to, bo to ja sam głównie się nie szanowałem, nie kupując wcześniej maszyny z kompletnie inną filozofią, bo naturalnie nic nie mam do ludzi posiadających inne komputery. Mimo że na Windowsa przeklinałem prawie codziennie. Ale do rzeczy. Uprzednio proszę też o to, by nie tłumaczyć mi w komentarzach, że jest inaczej, skoro coś mi się podoba i podpisuje się pod czymś obiema rękoma. Natomiast fajnie byłoby, gdyby wynikła rzetelna dyskusja na temat pewnych rozwiązań dla konkretnej grupy osób. Poza tym, ten post nie ma zamiaru nikogo przekonywać, spisuje tutaj moje spostrzeżenia na temat nowej maszyny, o której swego czasu mówiłem różne, niepoparte argumentami rzeczy, wynikające głównie z tego, ze chciałem, a nie miałem pieniędzy.

Stan wyjściowy do kupna Maka wyglądał następująco. Windows (przeplatany Linuxami). Bodaj od 98 do Visty. Brzydki interfejs, toporność przy instalacji softu deweloperskiego, choćby Perla, SVNa (np. grzebanie w zmiennych systemowych), wkurzający menu start, gdzie musisz przejechać nieskończenie wiele poziomów, by dostać się do interesującego Cię punktu (tak tak, Launchy), słaba typografia (polecam tutaj wykłady Tkaczyka), toporna konsola i ogólna niechęć. Czułem po prostu, że robię zbyt wiele, choć teoretycznie nie musiałbym. To tylko kilka z powodów, a jest ich więcej. Ważne jednak, że jest jeden główny – czułem się po prostu zmęczony. Tak, jak czujecie się zmęczeni przebywaniem non-stop z daną osobą, tak, jak nudzi Was kolejny sezon ulubionego, choć odgrzewanego serialu, czy kolejne wybory, gdzie startują ludzie, którzy kręcą się wokół pojęcia zwanego władzą już od 20 lat. Po prostu. Użeranie się z tym, co znam od kilkunastu lat i nie jest dla mnie idealne doprowadzało mnie wręcz do szewskiej pasji. Oczywiście, większość problemów mógłbym pewnie załatwić odpowiednią konfiguracją, instalacją kolejnego softu, grzebaniem, zmienianiem („no, no, to teraz tę .dll’kę to wrzuć do /Windows/, a tamto .ini do System32.. aaa REJESTR człowieku, rejestr, 10 linijek do zmiany!„). Mógłbym też analogicznie zrobić sobie przerwę od serialu, od osoby, z którą przebywam np. w pracy, wyemigrować, ale nie o to chodzi, bo rodzi to zupełnie inne owoce, niż zamierzone. Powiedziałem sobie raz na zawsze – dość tego, szukam alternatywy!

Taką okazał się MacBook Pro. Wielokrotnie podpatrywałem różne sztuczki u znajomych koderów, używałem go też wcześniej przez krótki czas i byłem po prostu ciekawy, jak zadziała on na codziennym polu bitwy. Finalne wrażenia są bardzo dobre. Zarówno system, jak i wykonanie komputera utwierdzają mnie w przekonaniu, że dokonałem prawidłowego wyboru.

Co takiego jest w Maku, co sobie cenię? Zacznijmy od Mac OS X, czyli systemu operacyjnego. Jest bezproblemowy w użytkowaniu. Po prostu. Nie będę tutaj dołączał tekstów o niezawieszaniu się, blue screenach i podobnych. Nigdy nie lubiłem tego typu porównań z Windows. Zacząłem jednak używać OS X i po kilku godzinach zapomniałem o wszelkich uciążliwościach, związanych z produktem Microsoftu, których doświadczyłem lub które opisywali inni. Nie przeszkadza umieszczenie przycisku zamknij po lewej stronie – przyzwyczaiłem się do tego naprawdę bardzo szybko. Poza tym urzekł mnie Dock, choć to nic rewolucyjnego, to tak powinno wyglądać menu start. Przede wszystkim jednak Mac OS X to świetny wygląd, w większości bardzo przemyślany UX oraz przepiękne wygładzanie fontów (Helvetica Neue, powstań!). Nie wiem też dlaczego, ale dzięki Mac OS X człowiek czuję większą kontrolę nad tym, co instaluje na swoim komputerze. Administracja programami jest dziecinnie prosta, instalacja jeszcze bardziej (przerzucasz ikonkę do folderu „aplikacje” i już!). Do tego świetny Spotlight, który jeszcze nigdy mnie nie zawiódł w wyszukiwaniu tego, czego szukałem. Nie rozstaje się już ze skrótem ⌘+SPACJA. Oczywiście należy też wspomnieć o świetnym dashboardzie, wirtualnych pulpitach – spaces, świetnym Keynocie do prezentacji (przewyższającym znacznie PowerPointa). Bardzo zadowolony jestem również z TextMate’a – Bundles i kilka innych rozwiązań bije na głowę wszystko inne, co miałem okazję do tej pory spotkać. Wielkim plusem tego systemu jest to, że nie narzuca się użytkownikowi, a przynajmniej mam takie wrażenie. Chcesz udostępnić sieć? Jeden klik tam, gdzie trzeba. Maksimum dwa ekrany do ustawienia, wszystko przejrzyste, bez dodatkowych czynności. To samo domyślne aplikacje, takie jak Mail czy iCal. Są dobrze wykonane, świetnie wyglądają i miałem nawet przez chwilę wrażenie, że są płatne i ktoś przez przypadek mi je zainstalował. Nie mogę niestety tego powiedzieć o Outlooku. Fajny jest też iPhoto z integracją z Facebookiem. Konsola linuxowa to coś, co jest wisienką na torcie. Moja ulubiona komenda to mate . – uruchomiona w określonym folderze stworzy nowy projekt w TextMate’cie z umieszczonych tam folderów i plików. Uwielbiam też aplikację Snippets, która fajnie przechowuje nasze kawałki kodu, pozwalając je świetnie otagować i mieć do nich dostęp z każdego miejsca w systemie. Przyjemną sprawą jest również domyślnie zainstalowany SVN, Python, czy Ruby. Czy wymieniłem już szybkie uruchomienie komputera i wręcz ekspresowe wybudzanie się? Takich smaczków jest naprawdę bardzo dużo i musiałbym pisać ten tekst jeszcze co najmniej miesiąc, by przypomnieć sobie i wymienić je wszystkie.

Co do samego wykonania Maka – jest świetne. Urządzenie jest zrobione solidnie, bardzo ładnie wygląda, a LCD jest po prostu wybornej jakości. Na uwagę zasługuje gładzik – dzięki specjalnym gestom (np. dwa palce do scrollowania) wręcz uzależniłem się od niego i rzadko używam myszki. Wadą dla mnie są natomiast tylko dwa sloty USB oraz Mini Display Port, przez który musisz zaopatrzyć się dodatkowo w tonę przejściówek, które tanie nie są.

Oczywiście, nie jestem ślepy i dostrzegam również wady urządzeń, które posiadam. W przypadku Maka będzie to zaskakująca niestabilność w działaniu Firefoxa, który potrafi się wykrzaczyć przy niepozornych czynnościach oraz współpraca z Flashem (choć Linuxy też mają z tym problem), kiedy oglądając na przykład YT wiatraczek potrafi zagłuszyć wszystko inne.

Co do testowania Internet Explorera – nie czułem jeszcze takiej potrzeby, aczkolwiek będzie do tego służył mój stary komputer. Jeśli zaś chodzi o wszelakiego rodzaju pliki Excela i Worda – nie miałem jeszcze z tym większych problemów, wszystko da załatwić się przy użyciu Numbers, Pages bądź Open Office’a. Z drugiej strony, nie używam zaawansowanych arkuszy czy dokumentów.

Kończąc tego posta mam świadomość, ze nie wymieniłem wielu zalet tego komputera, jak i systemu (mnóstwo świetnych skrótów klawiszowych, rozwiązań w TextMate’cie i konsoli), a także pewnie zapomniałem o jakichś drobnych wadach. W każdym razie to, co mówi wszystko o tym komputerze to prostota i piękno. Jestem estetą, lubię mądre i ładne rozwiązania. Mak oferuje wszystko to, a nawet więcej. Wcześniej, mimo że jako tako siedzę w tej branży, nie miałem nawet pojęcia o połowie jego funkcji. Ten komputer wiele zyskuje dopiero wtedy, kiedy zaczniesz go używać i poznawać różne zakamarki. Inaczej nie ma sensu się o nim wypowiadać.

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