Blogasek by Piotrek Reinmar Koszuliński

Artykuł został przeniesiony na mój nowy blog – code42.pl.

Zastanawiałem się od dłuższego czasu (a przez ostatni tydzień nawet aktywnie) co się stało, że... no właśnie, nic się nie stało. Kiedy zaglądam po długiej przerwie do swojego czytnika RSS w poszukiwaniu ciekawych polskich treści z Wielkiej Trójcy (HTML, CSS, JS) nie znajduję najczęściej nic. W Zamierzchłych Czasach, kiedy to 5 lat temu byłem początkującym developerem, było przecież (chyba) inaczej. Takie przynajmniej odnoszę wrażenie, kiedy sięgam pamięcią wstecz. Jeśli nawet jednak nie było, to czemu dzisiaj jest tak jak jest?

Winą za zastój w temacie obarczyłem brak społeczności zintegrowanej z jakimś miejscem w internecie. Tak mi się przynajmniej wydawało. Lubię należeć do społeczności i mieć podsunięte pod nos ciekawe tematy oraz móc się lansować samemu, więc postanowiłem poszukać odpowiedniego miejsca.

Fora

Zacząłem szukać takiego, na którym mógłbym się trochę powymądrzać na ciekawe tematy, bo wymądrzać się lubię. Moja wiedza dzisiaj jest też o wiele bogatsza niż kilka lat temu. W Zamierzchłych Czasach korzystałem w tym celu z Forum Mozilli gdzie dział standardów i technologii webowych kręcił się bardzo prężnie. Dzisiaj – w sumie pustki. Google też mi nie pomogło – trafiłem na forumweb, forum Webinside, forum Webhelp i ee... W sumie nigdzie więcej. Blipowicze też mi niczego więcej nie podsunęli. Po zagłębieniu się w treść tych forów stwierdzam, że średnio pojawiają się na nich 2 posty w interesujących mnie kategoriach dziennie bądź więcej, ale typu:

Chciałbym zrobić na stronie (wstaw dowolną frazę dla której Google pokazuje 100 wyników z rozwiązaniami), ale nie wiem jak to zrobić. Pomurzcie.

Jednym słowem – kaplica.

Portale

No to może jakieś portale społecznościowe czy newsowe? Z wyjątkiem nowo otwartego JSNews.pl, któremu kibicuję, nie znalazłem żadnych w swoim czytniku RSS, więc byłem znów zmuszony skorzystać z Google'a. I... Nawet nie chce mi się linkować do miejsc, które odwiedziłem. Jedynym portalem na jaki wrócę jest Webhelp gdzie znalazłem sporo ciekawej treści i aktywny blog newsowy. Nie potrafię jednak powiedzieć czy wokół tego miejsca "coś się kręci". Na pewno jednak jakościowo odróżnia się ono od wszystkiego co udało mi się znaleźć.

Agregatory

Osobną grupą są agregatory. Blogbox odpada, bo w kategorii technologia królują tematy zbyt ogólne. Tak samo na 10przykazań, o którym raz, że nie słyszałem nic od dwóch lat, dwa, że jest zbyt ogólny. Kiedyś coś ciekawego można było dorwać też na Wykopie jednak w tej chwili jest to już niemożliwe. Poza tym tam chyba nigdy nie było społeczności. Znam jeszcze webdevowy klon Wykopu, którym jest Develway, niestety po niezłym starcie portal umiera. Wciąż mu jednak kibicuję i zamierzam w przyszłości wrzucać tam nie tylko swoje wpisy, ale też wszystkie ciekawe, które znajdę. Was też do tego zachęcam.

Swoją drogą zastanawia mnie jedno. Dlaczego tak mało osób promuje swoje własne wpisy? Bo choć społeczności żadnej znaleźć nie mogę, to zapewne dużo ciekawych treści jest tworzonych. Tylko jak do Was, moi Drodzy Koledzy, trafić skoro nie da się Was znaleźć? Wielu pewnie uważa, że to inni powinni próbować nas promować, bo samemu jest głupio. Ja wcale tak nie uważam. Jeśli tworzę coś co uważam za ciekawe, to staram się by dotarło to do jak największego grona odbiorców. Jeśli się komuś nie spodoba link, który wrzuciłem na Blipa, to po prostu go nie kliknie bądź ucieknie ze strony. Jeśli się spodoba, to tym samym dzięki mojemu działaniu osoba ta zaoszczędziła czas, a ja może zyskam kolejnego odbiorcę. Tak więc promujcie swoje własne wpisy.

Ciekawym miejscem wciąż jest Techblog, czyli agregator technicznych wpisów z Joggera. Niestety, wraz z odejściem wielu osób z Joggera Techblog automatycznie też przymiera, a w związku z tym, że system blogowy jakim jest ten pierwszy raczej nie ma szans konkurować z WordPressami i innymi tej parze nie wróżę świetlanej przyszłości. W tej chwili jednak Techblog wciąż potrafi wygenerować kilkaset odwiedzin jednego wpisu, co jest wynikiem, jak na moje warunki, bardzo dobrym.

Mikroblogi

Idąc dalej należy wziąć pod lupę mikroblogi. Sam korzystam aktywnie z Blipa i jest to jedno z ciekawszych miejsc w naszym internecie. Dodatkowo zorientowanie serwisu na obserwowanie tagów oraz ograniczona ilość użytkowników powoduje, że łatwo tam z jednej strony trafić do odpowiednich odbiorców, z drugiej być tym odbiorcą. Mam też konto na Flakerze jednak nie korzystam z niego, bo bardziej przypada mi do gustu prostota Blipa. Nie potrafię więc powiedzieć co się na nim dzieje.

Oczywiście jest jeszcze Twitter, jednak to już jest społeczność międzynarodowa. Nie mogę się przekonać do jego aktywnego użytkowania, bo czuję się jakbym pisał w kosmos. Ludzi jest za dużo, a na dodatek ciężko trafić do nich tematycznie. No i ciężko trafić jedynie do polaków.

Blogi

Na koniec zostały same blogi, bo wokół niektórych również potrafi rozkręcić się niezła społeczność. Niestety w tej chwili nasi lokalni guru w większości poznikali. I nie chodzi nawet o to, że uciekli z blogami za granicę, tylko po prostu przestali pisać. Jednocześnie nowym ciężko się wypromować, bo i gdzie mieliby to zrobić? Nie istnieje w końcu żadna większa społeczność do której można dotrzeć.

Swoją drogą zastanawiam się, czy mała ilość polskich blogów prowadzonych przez prawdziwych ekspertów nie wynika z tego, że frontend developer w Polsce to w znacznej mierze stanowisko dla tyracza i osoby, które naprawdę coś potrafią albo wyjechały za granicę (i piszą po angielsku), albo nie mają warunków finansowych i zawodowych, do poświęcania swojego czasu na pisanie. Nie znam zachodnich realiów (polskie w sumie też słabo) i jest to bardziej pytanie do Was niż stwierdzenie faktu.

Można się też zastanowić, czy w Polsce wciąż jest dostatecznie liczna grupa odbiorców, w szczególności bardziej zaawansowanych, dla których opłaca się pisać. Może po prostu większość potencjalnych czytelników przerzuciło się na serwisy anglojęzyczne i nie zagląda już na nasze podwórko? Nie wiem. Sam jednak, mimo że czytanie po angielsku nie sprawia mi problemów, wciąż interesuję się równie mocno tym co dzieje się w kraju. Nie sądzę też bym był odosobniony w swoich preferencjach.

Podsumowanie

Kiedyś było inaczej... lepiej. Kiedy słyszę takie stwierdzenie od osoby ze starszego pokolenia zawsze pojawia mi się na ustach uśmiech. Teraz jednak sam jestem zmuszony tak napisać. Może to tylko moje złudzenie bądź w dzisiejszych czasach już tak musi być. Jednak nie tylko ja uważam, że coś tu jest nie tak. Niedawno Damian Wielgosik napisał o braniu sprawy w swoje ręce i co prawda nie robi on porównań do Zamierzchłych Czasów, ale również zauważa, że jest źle.

Jeśli już jesteśmy przy Damianie, to bardzo mu kibicuję. Jest, jak na nasze standardy, niezwykle aktywny (blog, newsy, kolejna konferencja, działalność szkoleniowa) i jest na pewno ekspertem w tym co robi.

Może ktoś spytać dlaczego sam nie spróbuję stworzyć jakiejś społeczności. W końcu nie ma co gadać, trzeba brać się do roboty. Owszem, racja. Nie widzę jednak sensu robić czegoś co już zostało zrobione. Sam więc w żadnym wypadku nie zamierzam pisać żadnego portalu, czy innego serwisu. Uważam, że odpowiednie już istnieją – potrzebują tylko naszego zainteresowania. I dlatego w najbliższym czasie zamierzam skupić się na Develway'u, na którego zacznę wrzucać ciekawszy content. Przyjrzę się też jak działa Webhelp i w jaki sposób mogę mu pomóc.

Ostatnia kwestia to czas i warunki. Sam studiuję, pracuję i... lubię pisać. Niestety to ostatnie robię zbyt rzadko, bo dwie pierwsze czynności i moje hobby zabierają mi za dużo czasu. Zauważyłem jednak ostatnio, że praca jaką obecnie wykonuję już nie rozwija mnie tak jak jeszcze rok temu (bo wciąż przerabiam te same tematy). Na dodatek mój pracodawca nie widzi sensu w prowadzeniu przez jego pracowników własnych projektów. Zredukowałem więc trochę ilość etatu na jakim pracuję i mam nadzieję mieć więcej czasu na pisanie. Czas pokaże.

Tło

Próbując zdobyć papierek inżyniera i tę odrobinę sensownej wiedzy, którą można znaleźć na studiach z informatyki (Politechnika Wrocławska) dotarłem do semestru piątego i kursu Projektowanie Oprogramowania. Jest to kurs z tych ciekawszych, bo w tym semestrze mam jeszcze np. Technologie Przetwarzania Mediów Cyfrowych (montowaliśmy reklamę radiową oraz słuchowisko, później robiliśmy retusz zdjęcia, a teraz fotomontaż - tak WTF?!), czy Informatyczne Systemy Sterowania (kurs dość zaawansowany, a więc zupełne przeciwieństwo TPMC, z tym, że wiedza przyda się może kilku(nastu) osobom).

Dwa miesiące pisania sztucznej specyfikacji i rysowania diagramików UML utwierdziło mnie jeszcze bardziej w przekonaniu, że nigdy w przyszłości nie będę chciał tego robić. Nasza specyfikacja na tym etapie obejmuje jedynie malutki wycinek systemu, a poświęciliśmy na jej przygotowanie kilka dni roboczych. I nie – nie projektujemy systemu bankowego, a uproszczoną księgarnię internetową. I tak naprawdę skupiamy się tylko na procesie składania zamówienia.

W tej chwili dotarliśmy do etapu kiedy już trzeba ogarnąć architekturę aplikacji. Co prawda większość studentów zaprojektuje zapewne jakiś tam sobie diagram komponentów, sekwencji i co tam jeszcze obejmuje ten etap kursu, kompletnie nie interesując się jak to będzie współgrało z frameworkiem/technologią którą później zastosują (narzucona z góry Java). Ja jednak tak nie potrafię. Zacząłem więc szukać Java'owego frameworka do aplikacji webowych, który później zastosujemy. I w tym momencie szczęka mi opadła.

Każda potwora...

Na początku semestru, kiedy dowiedziałem się, że będziemy projektować, a później w małej części kodować, aplikację webową poszedłem do prowadzącego spytać się czy jest z góry narzucony język. Dowiedziałem, się że prowadzący proponuje Javę, ale że nie – jeśli ktoś z nas chce coś innego, to może spróbować. Choć prowadzący nie polecał takich prób (szczególnie jak usłyszał o PHP :). Wtedy odpowiedziałem, że w trakcie semestru się zastanowię, bo dobrze znam symfony i byłoby mi łatwiej, a nie słyszałem o żadnym sensownym i otwartym rozwiązaniu w Javie. Prowadzący odpowiedział, że jest sporo dobrych i otwartych frameworków. Zrobiło mi się wtedy głupio, bo moja wypowiedź nie była poparta żadnymi głębszymi doświadczeniami. Po prostu – taki stereotyp Javy.

W trakcie semestru uświadomiłem sobie, że ten rodzaj betonowej specyfikacji nijak nie pasuje do symfony, ani Railsów, czy Django, które w większym/mniejszym stopniu znam. Że jestem zbyt słaby w UMLu, aby przenieść magię tego frameworka, do tych wszystkich diagramów, które musimy stworzyć. Postanowiłem więc się nie wyłamywać z tłumu i jak wszyscy pozostać przy Javie.

Wczoraj zacząłem research w poszukiwaniu odpowiedniego frameworka. Przejrzałem wiele stron na wiki i nieliczne porównania. Stwierdziłem, że najlepiej prezentuje się Spring 3. Został nieźle oceniony w porównaniu, a do tego w Google'ach potrafiłem znaleźć coś co przypominało stronę nowoczesnego projektu, a nie przedpotopowej, zapomnianej kobyły.

Przyzwyczajony jestem do świetnej dokumentacji typu "Get started" (sf, railsy, django), którą można zlokalizować na stronie domowej projektu w minutę, a która trzyma mnie za rączkę, aż do momentu kiedy jestem w stanie korzystać ze słabej (w przypadku symfony – bardzo słabej) dokumentacji API i tutorialów związanych z bardziej zaawansowanymi rozwiązaniami.

Tego samego szukałem na stronie Springa. Po 5 minutach wiedziałem już, że tak prosto nie będzie. Autorzy frameworka stworzyli 800 stronicowy podręcznik, w którym jest pewnie opisane wszystko, o czym 100 jego twórców myślało przez ostatnie dwa lata. Stworzyli też dziesiątki stron, w których chwalą się jakie to fajne rozwiązania wprowadzili do swojego dziecka. Nie znalazłem na stronie domowej projektu jednak nic dotyczącego Springa 3 (ta wersja ma już ponad rok) co pomogłoby mi go uruchomić.

Postanowiłem jednak się nie poddawać i rozpocząłem przeszukiwanie nie tylko strony domowej, ale całego internetu. W ciągu dwóch godzin trafiłem w kilka miejsc, jednak... sami popatrzcie – tu, tu, tu, tu (nawet nieźle), tu, czy tu. Jednym słowem wielki śmietnik. Postanowiłem spróbować z innym frameworkiem.

Kolejny, któremu chciałem się przyjrzeć, to JavaServer Faces. Tutaj było jeszcze gorzej. W Google'ach nie potrafiłem znaleźć nawet czegoś co można by było nazwać "jednolitą stroną projektu". Nie wiem jaka jest geneza (i już mnie to nie interesuje) tego frameworka, ale moim zdaniem to wręcz niepoważne. Polecam obejrzeć przykładowe strony, które są w pierwszej 10tce w Google'ach.

Po drodze był też JBoss. Strona na którą trafiłem wyglądała jak strona korporacji, więc po 5 minutach dałem sobie spokój. Żal coś pisać w tym temacie.

Pod lupę wziąłem też Strutsa. Najpierw się załamałem, bo strona projektu przypomina typową Apache'ową. Trzeba jednak być twardym. Documantation -> Get started -> Tutorials -> Getting Started i jest! Coś znalazłem. Nie jest to co prawda poziom znanych mi frameworków, ale daje radę. Jednak ścieżka jaką musiałem przejść żeby trafić do interesującej mnie strony bawi mnie dalej :).

Na koniec wróciłem zrezygnowany jeszcze raz do Springa i znalazłem cykl artykułów dla początkujących oraz Spring Roo. I choć na początku Spring mnie załamał, to w tej chwili wraz ze Strutsem i jedną sensowną książką do JSF jest moim ostatnim punktem zaczepienia w tym temacie.

... znajdzie swojego adoratora

Wspomniałem na początku, że zrobiło mi się głupio kiedy, nie mając podstaw, powiedziałem, że nie znam żadnego sensownego javowego frameworka. Zasiadając do poszukiwań szczerze wierzyłem w to, że skoro są miłośnicy Javy, wśród których są przecież świetni programiści, to musi istnieć jakaś sensowny projekt związany z sensownym frameworkiem.

Teraz już wiem – ze spokojem mogę mówić, że nie znam sensownego projektu. Nie mogę za to nic powiedzieć o samych frameworkach, bo aby je ocenić należy ich użyć. Możliwe, że każdy z frameworków, któremu się przyglądałem jest świetny. Ich autorzy zapomnieli jednak, że nie na kodzie i technicznym manualu Świat się kończy.

Zawsze drażnili mnie (a może bawili) programiści twierdzący, że taki stan projektów im odpowiada. To moja wina, że nie potrafię znaleźć interesujących mnie informacji. Moja wina, że nie zamierzam przeczytać 400 stron w książce aby choć w najprostszym zakresie potrafić użyć narzędzia. Moja wina, że za szybko się zniechęcam – generalnie jestem słabym programistą i nie umiem szukać oraz czytać ze zrozumieniem.

Dlatego tak bardzo zainteresowała mnie idea UCD – projektowania zorientowanego na użytkownika. Choć swoją popularność zdobyła głównie w związku z projektowaniem interfejsów, bądź ogólniej – interakcji człowieka z komputerem, to lubię ją aplikować do każdej sytuacji kiedy istnieje jakiś produkt i jego odbiorcy. Do nikomu niepotrzebnych usług, które według ich twórców są rewolucją, przedmiotów codziennego użytku, które przyprawiają nas o ataki szału, czy... no właśnie – nie przychodzi mi żaden produkt, przy opracowywaniu którego programiści nie mieliby swojego destruktywnego udziału.

Programiści i innego rodzaju osobniki, które pojęły sposób działania komputera (sieciowcy, administratorzy) to najbardziej zakute łby na naszej planecie. Wyłączam tutaj polityków, których ciężko ocenić, bo nigdy nie wiadomo kiedy kłamią. To natura informatyki, ze wszystkich dziedzin, najdalej odbiegła od natury człowieka. Dlatego osoby trudniące się pojmowaniem tej nauki są najbardziej aspołeczne. Nie mam tu na myśli sposobu ubierania się (bądź nie), zachowywania, czy poruszanych tematów rozmów. Mam na myśli sposób myślenia i wnioskowania.

Java Centered Design

Wracając do Javy od której to zacząłem. Jest to najbardziej odczłowieczony język jaki dany mi było poznać. Jego społeczność nie wywołuje we mnie żadnych uczuć. Nawet nie wiem czy istnieje. Nie znam żadnego programisty Javy, który by ten język lubił. Odnoszę wrażenie, że w ogóle wszyscy z niego korzystający zamknęli się w swoich bankowych, księgowych i ubezpieczeniowych gettach. Zaraz, zaraz. Przecież to właśnie te najbardziej nieprzyjazne człowiekowi systemy...

Oczywiście Java wpłynęła też na frameworki, które w niej powstały. Tak jak pisałem, znalazłem wiele artykułów napisanych przez autorów Springa ukazujących jakie wspaniałe wzorce projektowe zastosowali, jakimi dobrymi są programistami, jaki wspaniały techniczny podręcznik napisali. Zapomnieli jednak co jest wyznacznikiem jakości ich pracy.

Jest takie powiedzenie w piłce nożnej, że za podanie odpowiada podający, a nie jego odbiorca. Tak samo jest w w przypadku dokumentacji frameworków. To nie ja jestem głupi jeśli nie potrafię znaleźć interesujących mnie informacji i nie rozumiem tego co napisaliście. To Wasza wina. Ja oczywiście mogę szybciej pobiec do piłki i może jakimś cudem zdążę, ale tak naprawdę to wyście skopali swoją robotę tak beznadziejnie podając.

Dzisiejsza walka jeszcze głębiej utwierdziła mnie w przekonaniu, że Java jest smutna, zakuta i nieprzyjazna użytkownikowi końcowemu. Będę się dalej trzymał jak najbliżej frontendowych technologii webowych, aby mieć jak najbliżej do użytkownika końcowego. Dzięki temu mam nadzieję, że nigdy nie zapomnę dla kogo tak naprawdę co jest wyznacznikiem jakości mojej pracy. Zadowolenie użytkownika końcowego.

Kilka tygodniu temu zauważyłem, że drastycznie spadła mi liczba odwiedzin na blogu. Jako że nic nie pisałem przez ostatnie pół roku, przez długi czas utrzymywała mi się w miarę stała średnia liczba odwiedzających miesięcznie i były to w znacznej mierze wejścia z wyszukiwarek. W październiku zanotowałem spadek do 200 wejść w ciągu miesiąca. Zmartwiony tym faktem zacząłem się przyglądać o co chodzi. I trafiłem na taki wykres:

Przy czym wszystkie wejścia w ostatnim okresie, jeśli się nie mylę, pochodzą z innych nich Google wyszukiwarek, albo z wyszukiwarki obrazków Google'a.

Zacząłem więc przeszukiwać Google'a różnymi frazami, pod którymi zawsze dało się mnie znaleźć. Nie znalazłem nic pod na przykład: "javascript klasy", "conky ikony", czy "reinmar", a są to frazy z których miałem sporo wejść. Nie ma mnie nawet pod "blog koszulinski". Jednym słowem pełny ban.

Rozpocząłem więc edukację, ponieważ nigdy nie interesowałem się głębiej SEO (nie miałem nawet keywordsów ustawionych na blogu). Sprawdziłem swoją domenę narzędziami z cyklu "Google Ban Checker" i dowiedziałem się, że nie wygląda to na bana. Narzędzia te patrzą na wyniki dla frazy "site:blog.koszulinski.pl", dla której rzeczywiście coś się pokazuje. Pytanie tylko na ile można tym narzędziom ufać.

Sprawdziłem też, czy nie linkuję w jakieś kiepskie miejsca. Znalazłem do tego narzędzie Bad Neighborhood, które nie wykazało nic szczególnego. Podobne wyniki do mojego uzyskują inne strony.

Uruchomiłem Google Webmaster Tools. Dodałem sitemapę, sprawdziłem czy się indeksuję, czy są jakieś błędy, jakie słowa kluczowe mi znaleźli i kto do mnie linkuje. W sumie nie znalazłem nic szczególnego, poza tym, że mam ponad 1700 linków z domeny wroc.pl (drugi jest jogger.pl z zaledwie 700 linkami) i nie mam pojęcia skąd one mogą pochodzić. Nie wiem też jak to sprawdzić. Gdyby ktoś znał jakieś narzędzie/sposób niech da znać.

Na koniec spytałem się na forum Google'a, a tam usłyszałem od pracownika Google'a, że: odniosłem wrażenie że masz dosyć sporo cytatów na różne tematy. Nie wiem czy podpowiedziało to jakieś narzędzie (jeśli tak to kiepsko), czy to obserwacja z ręcznego przeklikania się po moim blogu. Tak, czy siak - cytatów u mnie kilka jest i jeśli za to bana dostałem, to mają tragiczny algorytm. Prewencyjnie jednak pokasuję wpisy gdzie sporo cytowałem (przy czym będą to głównie jakieś stare rzeczy).

Podsumowanie

Nie wiem do końca co mnie teraz czeka. Trochę jeszcze poczekam, ale jeśli się nic nie zmieni, to będę zmuszony się przenieść. Nie wiem tylko czy zmienić wtedy też domenę. Czy tylko serwer. Szkoda będzie odchodzić z Joggera po tylu latach. A wygląda na to, że to już mój piąty rok tutaj :).

Artykuł został przeniesiony na mój nowy blog – code42.pl.

Blog WTFJS o dziwactwach w JavaScriptcie widział już pewnie każdy. Niektóre przykłady są naprawdę fajne :) Co więcej — niektóre działają mi w sposób przedstawiony przez autorów tylko czasami, choć to pewnie nie problem JavaScriptu, a Firebuga :).

Jako, że lubię wiedzieć dlaczego tak to działa, a nie inaczej, staram się wyjaśnić sobie o co chodzi w każdym przykładzie. Niektórych nadal nie rozumiem, część jest oczywista, część ma rozwiązania podane na stronie, a te ciekawsze postaram się wyjaśnić w tym (i może następnych) wpisach.

Jestem prawie obiektowy

typeof "abc" == "string" // true
typeof String("abc") == "string" // true
String("abc") == "abc" // true -- same types get casted to equal each other
 
String("abc") instanceof String // false -- hmmm...
(new String("abc")) instanceof String // true
String("abc") == (new String("abc")) // true -- wait, wtf?

new String() to nie String(), a "string" to nie "object". Proste? :) Trochę wolniej:

Pierwsza linia jest oczywista, ale warta zapamiętania — typem literału stringa jest "string". W drugiej mogłoby się wydawać że tworzymy obiekt, ale nie — konstruktor String wywołany bez new po prostu rzutuje na stringa. Trzecia linia tylko to potwierdza.

Czwarta linia to nawiązanie do tytułu jaki nadałem tej sekcji — Jestem prawie obiektowy. Autor tego przykładu zdziwił się skąd takie zachowanie, ponieważ pewnie nie wiedział o typach prostych w JavaScriptcie. Otóż wartości: 1, "a", true nie są typu "object" tylko odpowiednio "number", "string", "boolean". Nie są z tego powodu instancjami swoich podobnie brzmiących z nazwy klas (ale uwaga — czerpią z ich prototypów). Jest to zachowanie całkiem uzasadnione (choć niefajne w działaniu), ponieważ w innym przypadku (gdyby typy proste nie istniały) nie działało by porównanie ===.

Wyobraźmy sobie sytuację, w której pisząc "a" tworzymy nowy obiekt typu "string". Porównanie dwóch zmiennych, które są obiektami za pomocą operatora === sprawdza, czy zmienne te odnoszą się do dokładnie tego samego obiektu w pamięci. Tak więc w naszej hipotetycznej sytuacji otrzymalibyśmy:

"a" === "a"; // -> false

Uups. Po lewej obiekt, po prawej obiekt, ale to nie te same obiekty. Na szczęście teraz jest tak:

"a" === "a"; // -> true
new String("a") === new String("a"); // -> false
true === true; // -> true
new Boolean(true) === new Boolean(true); // -> false

Nie twierdzę, że jestem fanem takiego rozwiązania. Nie jestem pewien, ale chyba w Javie jest podobnie, za to na przykład już w Rubym jest to rozwiązane lepiej (ktoś potwierdzi?). Cóż — nic nie jest idealne ;).

Wróćmy jednak do przykładu. W piątej linii wreszcie tworzymy obiekt typu String. Dla przypomnienia:

typeof new String("a"); // -> "object"
typeof String("a"); // -> "string"

Ostatnia linia powinna być już oczywista jeśli powiem, że operator == przeprowadza konwersję zmiennych stojących po obu jego stronach do jednego typu (którego, tego nie wiem — pewnie zmiennej po lewej — kto ma ochotę niech sprawdzi w specyfikacji i napisze w komentarzu :). Tak więc z porównania String("abc") == (new String("abc")) otrzymujemy porównanie "a" == "a". Dla porównania:

String("abc") === (new String("abc")); // -> false

Widać więc, że trzeba uważać na krótki operator porównania i stosować go z głową. Polecam przyzwyczajenie się do używania potrójnego operatora i tylko w szczególnych wypadkach, kiedy na przykład znamy typy zmiennych (typeof x == "string"), używanie podwójnego.

Jestem prawie obiektowy, ale umiem porównywać

Kolejny przykład będzie tylko rozwinięciem poprzedniej części. Oto on:

(1) === 1; // true
Number.prototype.isOne = function () { return this === 1; }
(1).isOne(); // false!
Number.prototype.reallyIsOne = function () { return this - 1 === 0; }
(1).reallyIsOne(); // true

Pierwsza linia powinna być oczywista — nawias nie ma znaczenia. Druga i trzecia to ścisłe nawiązanie do poprzedniej części. W isOne typeof this; // -> "object". Mimo, że wywołujemy metodę na zmiennej typu "number", to jest ona po cichu rzutowana na "object" — dziwne, ale do zrozumienia — ciężko żeby this nie było obiektem.

Dwie ostatnie linie, to dynamiczne rzutowanie. Operacja odejmowania stara się rzutować obie zmienne na typ liczbowy. this jest rzutowane na 1 i reszta jest jasna. Równie dobrze można byłoby zapisać reallyIsOne w ten sposób:

Number.prototype.reallyIsOne = function () { return +this === 1; };

Używaj średników!

Poprzedni przykład przekleiłem na czysto z WTFJS. Jeśli będziecie go w tej postaci wklejać do Firebuga, to możecie się spotkać z latającymi wyjątkami. Skąd ten problem? Na końcu drugiej i czwartej linii brakuje średników i przynajmniej firefoksowy silnik wysiada. Rada na przyszłość — średniki dobre są.

Niezrozumiałe dla mnie

Tego już nie wytłumaczę :). Choć — obstawiałbym, że problem leży gdzieś w standardzie reprezentacji liczb zmiennoprzecinkowych, ale to tylko mój domysł.

Number.MAX_VALUE*1.0000000000000001 === (1/0) // false
Number.MAX_VALUE*1.0000000000000002 === (1/0) // true

Artykuł został przeniesiony na mój nowy blog – code42.pl.

Artykuł został przeniesiony na mój nowy blog – code42.pl.

Sesja się już dla mnie skończyła, można więc coś napisać. Dzisiaj będzie jednak krótko, bo i temat prosty.

Cóż to takiego framework CSS?

No właśnie. Każdy wie co to są frameworki programistyczne, ale CSSowy? Według wiki:

A CSS framework, also known as a web design framework is a pre-prepared library that is meant to allow for easier, more standards-compliant styling of a webpage using the Cascading Style Sheets language. Just like programming and scripting language libraries, CSS frameworks (usually packaged as external .css sheets inserted into the header) package a number of ready-made options for designing and outlaying a webpage.

Czyli, tak jak w językach programowania, framework jest biblioteką (w tym wypadku grupą reguł CSS) która ułatwia implementowanie jakichś standardowych, często powtarzających się funkcjonalności (w tym wypadku pewnych schematów w layoutcie).

Co, według mnie, frameworkiem CSS nie jest? Pisałem w listopadzie o parserze/kompilatorze/procesorze CSS - LESS, który rozszerza składnię CSS o kilka świetnych rzeczy. Między innymi - zmienne, zagnieżdżone reguły, obliczenia, wielokrotne wykorzystywanie reguł. Jakby nie było - nie podchodzi to pod definicję z Wikipedii, ale niestety znajduje się w linkach do przykładowych frameworków. Dla ustalenia uwagi - LESS nie jest frameworkiem.

Czemuż ssie?

Pod mą lupę wziąłem pierwsze linki zwrócone przez Google. Przyjrzałem się chwilkę frameworkom: Blueprint, Elastic CSS, YUI 2 Grids. Prawdopodobnie są lepsze rozwiązania od tych i z chęcią się im przyjrzę jeśli linki pojawią się w komciach :).

Słówko o nieudanym porodzie

Wypada jeszcze wtrącić, dla niezorientowanych, co to za poroniony pomysł ten Grid system. Otóż wpadł ktoś na pomysł, że wygodnie będzie wszystkim (grafikom, programistom) jak ustalimy sobie, że strona składa się z X kolumn po Ypx szerokości każda, między którymi są marginesy po Zpx. Przyznam, że obaj z grafikiem byliśmy zachwyceni, aż do... pierwszego projektu. Życzę np. sporo zabawy z cieniami wychodzącymi poza granice kolumn, w przypadku kiedy nie możemy użyć box-shadow. Szlag trafia wszystkie piękne, okrągłe wartości.

Koniec wtrącenia

Najpierw kawałek kodu z YUI 2 Grids:

<div id="yui-main">
   <div class="yui-b">
      <div class="yui-g">
         <div class="yui-g first">
            <div class="yui-u first"></div>
            <div class="yui-u"></div>
         </div>
         <div class="yui-g">
            <div class="yui-u first"></div>
            <div class="yui-u"></div>
         </div>
      </div>
   </div>
</div>

Tyle się kiedyś mówiło o semantyce kodu i oddzieleniu wyglądu od treści. Ponad pięć lat temu, kiedy zaczynałem naukę HTMLa i CSSa, trwała walka o to aby programiści zaczęli pisać porządny kod. Wydawało mi się, że teraz już nie powinno być z tym problemów, a tu zonk. Patrzę na ten przykład i co widzę?

• Prezentacja zbita razem z HTMLem - żeby zmienić układ strony zmieniamy HTMLa, a nie CSS,
• Kompletnie bezznaczeniowe nazwy klas i identyfikatorów - jedno wielkie semantyczne szambo. Wybrałem akurat framework od YUI, bo jest w tym najgorszy (choć Blueprint mu nie ustępuje). Elastic CSS wygląda trochę lepiej,
• Divitis. W przypadku YUI można chyba akurat dowolnie zmieniać użyte tagi, bo framework resetuje marginesy i paddingi dla wszystkich elementów (co też, tak na marginesie, uważam za kiepską praktykę). Kiedy jednak używając Blueprinta postanowimy zawrzeć którąś kolumnę w listę, to wszystko szlag trafia, bo uwaga... niektóre selektory zawierają nazwę tagu :O
• Narzucona struktura i kolejność elementów w kodzie HTML. Ja akurat poświęcam sporo uwagi temu aby każdy element nawigacyjny był w sensownym miejscu, aby nie używać niepotrzebnych tagów, a wykorzystując framework nie mam tej elastyczności,
• I wreszcie - przecież to wszystko co oferuje framework można w czasie, który jest bez znaczenia w stosunku do całego projektu, napisać ręcznie. To jest kilka reguł, które doświadczona osoba pisze na raz i to od razu z ewentualnym hackiem dla IE6. Tak, wiem, że nie wszyscy mają taką wiedzę, ale wykorzystując framework nigdy jej nie pogłębią.

Tak więc w żadnym wypadku nie widzę sensu w używaniu frameworków do budowy układu strony. Żeby jednak nie było, że w ogóle nie umiem wykorzystywać zewnętrznego kodu - uważam, że przydatne są frameworki poprawiające typografię, bądź też pod niektórymi względami formularze. Muszą jednak bazować na selektorach używających tagów, a nie klas, czy nie daj Boże identyfikatorów.

Zadałem jakiś czas temu na blipie pytanie dotyczące artykułu Label Placement in Forms. Interesowało mnie czy może jest jakiś powód dla którego niektórzy (np. Marek Kasperski w swojej książce Projektowanie stron WWW) piszą aby labele do pól formularzy umieszczać na lewo od samych pól i wyrównane do prawej, a dlaczego inni (choćby autor tego artykułu) uważają, że najlepiej opis pola umieścić ponad polem, zmniejszając tym samym liczbę fiksacji wzroku? Czy Ci pierwsi nie znają badań? Czy kierują nimi jakieś inne przesłanki (np. praktyczne), o których ja nie wiem? Rzecz jasna, nie udało mi się tak doprecyzować pytania (ciężko się było w 160 znakach zmieścić :D).

Dostałem dwie odpowiedzi. Skopiowałem sobie kiedyś tylko ich treść, nie podam niestety linka, bo w blipowym archiwum nie mam szansy tego znaleźć. Tak wyglądała rozmowa:

reinmar: #usability labele nad inputami, czy na lewo od nich (wyrównane do prawej)? Za każdym razem piszą inaczej (choć to pewnie bez znaczenia)

PanA > reinmar: nie bez znaczenia, zależy co chcesz osiągnąć. U góry się szybciej czyta niż obok, mniej fiksacji

PanB > reinmar: [blip] tak jak mówi ^PanA, najlepiej nad ale pola muszą być udzielone, mogą też być po lewej ale z wyrównaniem do prawej

Zaciekawiło mnie co miał PanA na myśli pisząc: zależy co chcesz osiągnąć:

reinmar > PanA: To co mogę osiągnąć umieszczając je po lewej? Więcej fiksacji, więc umieszczać je tam jak chcę zniechęcić użytkownika? ;P

PanA > reinmar: czasami użytkownikowi nie ma być łatwiej - możemy chcieć zmusić go do zastanowienia się nad tym co wpisuje, etc.

reinmar > PanA: Dlatego odciągamy go od zastanawiania utrudniając ogarnięcie formularza? Czy dajemy mu więcej czasu na zastanowienie się

Uhh... Urocze powtarzanie usłyszanych od branżowych guru i wyczytanych z książek zdań. Zresztą - już moje pytanie było zadane złośliwie, bo po zależy co chcesz osiągnąć w miarę wiedziałem czego się mogę spodziewać.

Jednak nie do samej rozmowy chciałem bić w tym wpisie (dlatego też ocenzurowałem rozmówców - nie chcę tu dyskusji :P), a do dwóch błędów, które moim zdaniem wiele osób popełnia podczas projektowania.

Jestem specjalistą - przeczytałem 20 książek

Generalnie sytuacja ta odnosi się do każdej branży. Młodzi adepci Czegoś siadają do książek, chłoną, chłoną i napuchli wiedzą stają się w ich mniemaniu pełnowartościowymi specjalistami od Czegoś. Znają dziesiątki strasznie brzmiących terminów, mogą toczyć poważne dyskusje z ważnymi osobami ze świadka Czegoś. Zabawa kończy się jednak kiedy "specjalista" wkracza w granice praktyki. I tutaj, w zależności od osobowości i życiowej mądrości, z pokorą zbiera doświadczenie i weryfikuje posiadaną już wiedzę, bądź też dalej wygłasza znaną sobie teorię, która zupełnie nie ma zastosowania w praktyce.

Żeby była jasność - nie neguję wartości znajomości teorii i nie twierdzę, że ktoś kto poznał teorię może być dobrym praktykiem.

Tort, znaczek Nike i płyta DVD

PanB > reinmar: osobiście nad daje gdy jest mało pól, przy większej ilości daje z lewej

O. I to jest ciekawa odpowiedź. Rzeczywiście - ciężko przy 20 polowym formularzu dawać opisy ponad pola, ponieważ formularz ten rośnie nam do ogromnych rozmiarów. Przypomniała mi się jednak przenośnia (?), którą kiedyś wymyśliłem aby zobrazować w firmie jaki popełniamy błąd projektując funkcjonalności jednego serwisu. Wiele osób działa tak:

Weźmy tort, bo przecież każdy lubi tort. Tort jest fajny!

Weźmy znaczek Nike. Przecież jest teraz trendy, na pewno każdemu się spodoba.

Ja chcę jeszcze płytę DVD. Przecież jest taka funkcjonalna. Płyta DVD jest fajna!

I co dostajemy? Tort z przyklejonym z boku znaczkiem Nike i wbitą na sztorc płytą DVD. Dzieło sztuki po prostu. Niestety tak działa wiele osób - dobierając funkcjonalności serwisu wybierają (np. z konkurencyjnych rozwiązań) te, które są fajne, nie myśląc o tym, czy razem będą tworzyły spójną całość. Projektując interfejs zagłebiąją się w statystyki, badania, wybierają atomowo najlepsze, najszybsze, najczytelniejsze rozwiązania i nie patrzą na ogół serwisu. Nagminne.

Nim mnie zjedziesz

Nie, nie uważam się za specjalistę od użyteczności, nie przeczytał nawet 5 książek. Co więcej - możliwe, że PanA ma rację, a ja jestem zbyt ograniczony by go zrozumieć.

Tak samo - sam nie jestem wolny od wyśmiewanych przeze mnie błędów. Niestety ;)

BTW. muszę wreszcie stworzyć sobie jakiś design do tego blogaska.