Zapiski na Koszulce

The end – blog zamknięty

Wed, 31 Aug 2011 15:39:37 +0200

Myślałem, że dam radę prowadzić dwa blogi, jeden bardziej techniczny, drugi luźniejszy, czyli ten. Nic jednak z tego, dlatego zamykam tego bloga. Od roku wszystkie moje artykuły (głównie JavaScript) lądują na Code42.pl.

Dziękuję Joggerku, to były wspaniałe lata z Tobą :)

Delegacja i funkcje generyczne w JavaScript + mały offtopic

Sun, 09 Jan 2011 17:28:33 +0100

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

Darmowe szkolenie z programowania gier w JavaScript by DevMeetings

Sat, 01 Jan 2011 15:33:30 +0100

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

Gdzie ta społeczność polskich frontendowców?

Sun, 26 Dec 2010 23:29:00 +0100

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.

Zarezerwowane słowa kluczowe w JavaScript - gramatyka języka

Thu, 23 Dec 2010 18:18:35 +0100

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

Obiektowy JavaScript i właściwości chronione – w poszukiwaniu Świętego Graala

Mon, 20 Dec 2010 00:05:51 +0100

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

Java Centered Design

Sat, 11 Dec 2010 18:00:28 +0100

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.

Google mnie zbanowało?

Sat, 27 Nov 2010 01:28:39 +0100

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 :).

Drogowców jajo z Ronda

Thu, 25 Nov 2010 00:19:42 +0100

Napisałem przed chwilą maila do wrocławskiej Gazety Wyborczej. Możliwe, że list opublikują (do tej pory za każdym razem kiedy pisałem tak było), jednak wyszło mi całkiem ładnie, więc zamieszczam też na blogu.

Edit: W związku z moim filtrowaniem mnie przez Google'a postanowiłem nie cytować siebie samego, a zamieścić linki. Mój list pojawił się ostatecznie na:

Dwukolumnowa lista definicji (edit: w HTML5 lista opisów (?))

Sun, 04 Apr 2010 01:36:01 +0200

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

WTFJS - rozjaśnienie umysłu

Sat, 06 Mar 2010 01:34:06 +0100

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

{geshi lang=javascript}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?{/geshi}

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:

{geshi lang=javascript}"a" === "a"; // -> false{/geshi}

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

{geshi lang=javascript}"a" === "a"; // -> true new String("a") === new String("a"); // -> false true === true; // -> true new Boolean(true) === new Boolean(true); // -> false{/geshi}

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:

{geshi lang=javascript}typeof new String("a"); // -> "object" typeof String("a"); // -> "string"{/geshi}

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:

{geshi lang=javascript}String("abc") === (new String("abc")); // -> false{/geshi}

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:

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

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:

{geshi lang=javascript}Number.prototype.reallyIsOne = function () { return +this === 1; };{/geshi}

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ł.

{geshi lang=javascript}Number.MAX_VALUE*1.0000000000000001 === (1/0) // false Number.MAX_VALUE*1.0000000000000002 === (1/0) // true{/geshi}

Obiektowy JavaScript cz.2. - klasa sama w sobie

Sun, 28 Feb 2010 03:10:25 +0100

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

Dlaczego iPhone też już ssie?

Tue, 09 Feb 2010 21:28:42 +0100

Opublikowane na licencji CC przez Roberta Thomsona.

Tytułem tym chciałem nawiązać do ubiegłotygodniowego wpisu Dlaczego frameworki CSS ssą?. Niech tradycją się stanie, że kiedy używam słowa "ssać" to chcę coś nieobiektywnie pojechać. Piszę "nieobiektywnie", żeby mnie ktoś znowu nie próbował przekonać, że wpis ten w mych oczach miał pretendować do bycia obiektywnym. Nie — to jest blog i publikuję tu moje odczucia, a nie badania naukowe (które notabene, po wpadce klimatologów, wiemy już jak są prowadzone).

Wpis ten zacząłem pisać wczoraj wieczorem, jeszcze zanim miałem okazję przeżyć dzisiejsze przygody (które wymieniam na liście). Tak więc czara goryczy przelała się już wcześniej, a to co stało się dzisiaj tylko mnie przekonało, że bardzo chcę opublikować ten tekst.

Żeby było jasne — iPhone (wersja 3G) jest oryginalny, zakupiony w Erze półtora roku temu, nigdy nie jailbrake'owany, nigdy nie przytrafiło mu się też nic strasznego. Windows do którego go podłączam włączany jest tylko w celu synchronizacji telefonu z iTunesem, bądź odpalenia kilku gier (kupionych w sklepie, nie ściąganych). Można więc przyjąć, że jest w miarę czysty.

Co przydarzyło mi się dzisiaj:

dwukrotnie miałem już następującą sytuację — iPhone staje się trochę niestabilny (coś tam pada, coś tam laguje), postanawiam więc go wyłączyć i włączyć — wiadomo, że czasami dobrze jest odśmiecić pamięć. Wyłączam iPhone'a, włączam... nie — nie włączam — słodki ekran z jabłuszkiem zawisa na czas nieskończony (ostatnio jak zawisł mi przed seansem w kinie, to po seansie nadal się włączał). Wtedy trzeba pokombinować jakoś żeby go na twardo zresetować, ale stop — nie da się do cholery wyciągnąć baterii. Wciskam więc wszystkie jego dwa klawisze i za którymś razem (żeby nie było zbyt prosto — kilka razy mogę dusić te przyciski po kilka minut i nie ma reakcji) udaje mi się go wyłączyć. Ponowna próba włączenia kończy się sukcesem, o ile sukcesem można nazwać stan, w którym przestają działać wszystkie doinstalowane aplikacje i wymagana jest synchronizacja z iTunesem,
tak jak pisałem — sytuacja ta przytrafiła mi się dwukrotnie. Za pierwszym razem udało mi się przy pomocy iTunesa przywrócić słuchawkę do normalnego stanu. Dzisiaj jednak czterokrotnie już zawiesił mi się iTunes, wgrywanie nowego softu na telefon zostało przerwane, później synchronizacja, później nie udało mi się w 100% przywrócić iPhone'a z kopii zapasowej (to po kiego grzyba ta urocza, trwająca wieki synchronizacja przy każdym podłączeniu do komputera?). W skrócie — telefon po kilku godzinach działa, ale nie mogę wgrać na niego muzyki, bo po 3 minutach od podłączenia i rozpoczęcia synchronizacji iTunes nagle stwierdza, że jednak dzisiaj nie ma na nią siły i bez jakiegokolwiek komunikatu kończy (nie powiadamiając o tym iPhone'a) synchronizację,

To wszystko zabolało mnie jednak w głównej mierze dzisiaj. Poprzednia akcja ze zwiechą podczas włączania telefonu zakończyła się udaną synchronizacją i przywróceniem akceptowalnego stanu. Tak więc co natchnęło mnie wczoraj do rozpoczęcia pisania tego wpisu?

ten sprzęt jest niemożliwie, czasami aż do bólu groteskowo wolny,
na początek, przez pierwszy rok (to tak jak w małżeństwie ;), było naprawdę spoko — nie miałem telefonowi nic do zarzucenia. Jednak po każdym upgradzie softu system staje się wolniejszy. Najgorzej było kiedy dziadek Dżobs postanowił wypuścić iPhone'a 3GS — wtedy odczułem bardzo duży spadek wydajności. Jeśli dziadunio myśli, że nakłoni mnie tym do kupienia jego młodszego dziecka, to grubo się myli — nie cierpię takiego cwaniactwa,
wyciszenie iPhone'a czasami trwa ponad 4s — mam na myśli czas od zmiany ustawienia suwaka do jakiejkolwiek reakcji telefonu (wibracja, ekran),
odblokowanie iPhone'a (takie codzienne — z trybu uśpienia) czasami trwa ponad 10s — najpierw trzeba poczekać aż pojawi się suwak, później aż zareaguje na ruch palca, później pojawia się klawiatura, która też potrzebuje czasu żeby sobie przypomnieć, że jest klikalna, a na koniec ikonki, które muszą sobie wyskoczyć z wszystkich rogów ekranu, zamiast po ludzku się pokazać,
włączenie smsów, książki kontaktowej, ostatnich telefonów, czy listy alarmów... nawet nie chce mi się myśleć ile to potrafi zabrać czasu, ale i tak wielcy jabłkowi programiści "zoptymalizowali" te programy, bo było gorzej,
iPhone lubi sobie co jakiś czas (tak raz na miesiąc) zgubić sieć — czasem podczas rozmowy, czasem podczas stanu uśpienia,
czasem ten stan zgubienia sieci zamienia się w stan niemożliwości dodzwonienia się do mnie i zadzwonienia ode mnie (operator się buntuje) przez dłuższy czas,
paczka z iTunesem ma 90MB. Co oni tam za przeproszeniem ładują? Zestaw animowanych emotek w formacie 128px na 128px na każdą porę dnia i nocy?,
Synchronizacja trwa pół godziny (fakt faktem, że robię ją rzadko),
iTunes jest niestabilny, nieużyteczny, ekstremalnie powolny, zasobożerny (wolę słuchać muzyki z Youtube'a — mniej ciągnie z proca) i nie rozumie oggów. Na dodatek zamiast napisać, że coś mu się nie podoba, że czegoś nie może znaleźć, czy że ma zły dzień, to milczy,

Wszystko to co mnie irytuje w tym telefonie nie zmienia jednak jednego — Apple ma niesamowitych projektantów interfejsów. Kiedy wreszcie pozbędę się tego bezużytecznego narzędzia, to nie sądzę żebym w jakimkolwiek innym systemie czuł się tak dobrze. Szkoda.

Powstrzymałem się w tym tekście od użycia naprawdę wielu brzydkich wyrazów, więc na koniec tylko podsumuję całą sytuację — kurwa, nigdy więcej sprzętu, którego nazwa zaczyna się od "ip".

Ciekawy jestem czy tylko ja mam takie problemy z tym telefonem. Przeszło mi rzecz jasna przez myśl, że słuchawka może być uszkodzona. Wolę jednak wierzyć, że pozostali też mają problemy, ale boją się to przyznać, bo przecież tak kiedyś zachwalali iPhone'a ;). Szkoda tylko, że kiedyś to był naprawdę fajny sprzęt.

Obiektowy JavaScript cz.1. - obiekt Twoim przyjacielem

Sat, 06 Feb 2010 13:16:09 +0100

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

Dlaczego frameworki CSS ssą?

Fri, 29 Jan 2010 11:45:21 +0100

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:

{geshi lang=xml}

{/geshi}

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.

Wybiła 15stka

Sun, 24 Jan 2010 12:48:30 +0100

Od teraz KK pozwala mi się żenić bez zgody rodziców, wpuszczą mnie wreszcie do niektórych pubów i w ogóle :P Teraz dopiero czuję się dorosły. No i w końcu to oczko — więc to musi być szczęśliwy rok.

O tym jak wydłużyłem sobie dobę (cz. 2)

Sun, 10 Jan 2010 19:04:39 +0100

Minął już zdecydowanie ponad miesiąc od kiedy "wydłużyłem sobie dobę", pora więc na jakieś podsumowanie.

Pierwsza rzecz o której wypada mi wspomnieć, to to, że udało mi się utrzymać zmianę w swoim dobowym grafiku. Poniedziałek, wtorek i czasami środa stawiam się w pracy na 7:00-7:15, co uważam za swój spory sukces. Szczególnie teraz, w tym burym okresie, daje mi to kopa, bo więcej czasu działam przy świetle dziennym. Muszę przyznać, że nie było dla mnie w święta nic gorszego, niż wstać o 14stej i do końca dnia nic nie robić, bo "przecież już wieczór, ciemno i w ogóle". No ale właśnie - przechodzimy do porażki.

Porażką jest absolutny brak zmian w pozostałych dniach tygodnia i dniach świątecznych. Ciągle wstaję pomiędzy 9tą - 12stą, ekstremalnie 14stą. Spowodowane jest to tym, że chodzę późno spać, bo godziny 0:00 - 2:00 to dla mnie wciąż najproduktywniejszy okres. Ucisza się komunikator, ucisza się dom, mam święty spokój i mogę spokojnie skończyć to co danego dnia zacząłem robić.

Plan na najbliższy miesiąc, który akurat będzie miesiącem kolokwiów, jest taki aby trochę ograniczyć czas kiedy mam włączony komunikator. Blip, mimo swoich niewątpliwych zalet, ma jednak też poważną wadę - rozprasza. Zobaczymy jak zadziała metoda nie wprost :).

PS. wziąłem się ostatnio na poważnie, za projekt, który wisiałem koledze. Oznacza to, że pisać będę raczej rzadko. Trzeba zakończyć kiedyś tę otwartą pętlę :)

Słów kilka o projektowaniu

Wed, 23 Dec 2009 15:21:10 +0100

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.

Przegląd prasy

Tue, 08 Dec 2009 00:47:43 +0100

Przez mój czytnik i mojego blipa przewija się masa linków. Część ze znalezionych informacji dodaję do swojego del.icio.us, jednak mimo to o tych najważniejszych / wartych najwięcej uwagi czasem zapominam. Pomyślałem więc, że będę publikował co jakiś czas najciekawsze moim zdaniem znaleziska z zakresu web developowania i usability. Raz, że samemu będzie mi łatwiej do tych informacji wrócić, dwa, że może komuś zaoszczędzę trochę czasu i podsunę coś czego jeszcze nie czytał.

Wiele z poniższych linków macie szansę znać, wiele to starsze informacje, ale to pierwszy wpis w tym cyklu (tak, jeśli będę miał o czym pisać, to może zacznę to robić regularnie :) - następne będą aktualniejsze i zgrabniejsze. Na dodatek aby znaleźć te linki niestety musiałem przeglądać historię i wiele ciekawych rzeczy mogłem pominąć.

Usability vel użyteczność

AB Tests – strona zbiera wyniki testów A/B podsyłane przez czytelników. Nie zawsze są to wiarygodne testy (ze względu na zbyt małe próbki), ale jest też wiele wartościowych badań, z których można nauczyć się czegoś na przyszłość.
10 przydatnych wskazówek związanych z użytecznością – jak to w Smashing Magazine – krótko, treściwie, ładnie i z głową.
Jak wygląda raport z audytu użyteczności – by Robert Drózd.
UI Flow Shorthand Notation – prosty sposób na graficzne przedstawienie "flow" serwisu. Czyli podstrony, akcje użytkownika i ścieżki między nimi.
Dlaczego zatrudnię do mojego startupu programistę gier – trochę mniej związane z usability, ale nadal.
Google Analytics w kontekście użyteczności – prezentacja przeprowadzona przez Roberta Drózda na WUD Tour. O tym, że nie wystarczy odpalenie statystyk - trzeba jeszcze umieć ich użyć.
Lista lektur o użyteczności – wrzucam ją chyba sam dla siebie, żeby się motywować do czytania :).

Łebowe i niełebowe programowanie

Python - pomoce, kursy, ćwiczenia – zacząłem się ostatnio uczyć Pythona i tu znalazłem sporo ciekawych materiałów. Polecam Python Challenge – najbardziej praktyczna nauka języka :).
O tym dlaczego chowanie elementów interfejsu przez display:none jest złe – Sam odpowiedzi nie znałem. Artykuł o tym jak to zrobić lepiej.
Falsy values i operatory porównania w Javascriptcie – dla mnie same falsy values były oczywiste, gorzej jednak z operatorami porównania - warto zapamiętać.
ECMA zatwierdza ECMAScript 5 jako standard – więcej informacji na ten temat.
Słownik HTMLa 5 – bardzo wygodny i przejrzysty spis tagów. Do każdego elementu mamy opis i przykładowy kod (brakuje mi listy atrybutów). Warto do niego zaglądać (jak i na całego HTML5 Doctora).
HTML5 WTF? – prezentacja w komiksowym stylu o HTMLu 5. W sam raz dla szefa :)
Jak powinien wyglądać śliczny kod HTML – nie z każdym elementem się zgadzam, ale to temat na osobny wpis. W skrócie - HTML5 w praktyce.
JS Ninja – kilka przykładów ataków XSS. Przydatne do samokontroli podczas pisania Javascriptu.

Inne

Komiksy o świecie twórców stron – z humorem o naszej pracy i środowisku :)
Klienci z piekła rodem – bez komentarza. Trzeba poczytać. W każdą z tych sytuacji jestem w stanie uwierzyć :P

Póki co na tym koniec. Od teraz co ciekawszy znaleziony link będę sobie odkładał, więc następne wydanie przeglądu prasy będzie aktualniejsze.

Write LESS, do more - czyli pimp my CSS

Thu, 26 Nov 2009 01:20:01 +0100

Uwaga: wyszedł mi "odrobinkę" przydługi wstęp. Zabieganych zapraszam od razu do konkretów.

CSS rady nie daje

Nie da się ukryć że frontend developerzy (czy inaczej "ci od cięcia grafiki" :) łatwego życia nie mają. Pierwsza sprawa to niedoskonałości samych języków (CSS, xHTML, Javascript+DOM), druga to różnice i bugi (zwane inaczej ficzerami) w obsłudze przez przeglądarki. Każdy z tych języków na szczęście się rozwija (CSS3, HTML5, ECMAScript 5), a implementacja standardów jest, nawet w Internet Explorerze, sukcesywnie polepszana. Trwa to jednak strasznie długo, dlatego warto pokombinować samemu.

Ostatnio opisałem plugin do edytorów tekstów dzięki któremu można przyspieszyć pisanie HTMLa. Dzisiaj pod lupę chciałbym wziąć CSS. Osobiście na tempo pisania listy właściwości nie narzekam - mam własny zestaw snippetów, który umila mi życie. Inaczej ma się sprawa w stosunku do selektorów. Już w niedużym projekcie potrafią się zrobić cuda typu:

{geshi lang=css}#content .news_list .item .title {...} #content .news_list .item .date {...} #content .news_list .item .date .day {...}{/geshi}

Albo:

{geshi lang=css}.s1 { width:120px; float:left; font-size:1.1em; margin-left:10px; color:#FA0; } /*gdzieś kawałek dalej:*/ .s2 { width:120px; float:left; font-size:1.1em; margin-left:10px; color:#C14; }{/geshi}

Gdzie wypada to połączyć do pary selektorów i dla każdego z osobna jeszcze kolor ustawić. Niestety to najprostszy przypadek z tej rodziny, czasami trzeba znaleźć części wspólne dla kilku reguł po kilkunaście właściwości, albo olać wszystko.

Dalej można wymieniać:

Powtarzające się wartości kolorów, rozmiarów, marginesów, itd. Zmiana jednej wymaga zmiany pozostałych, bo np. tekst ma mieć ten sam kolor w nagłówkach newsów co gdzieś w sidebarze i górnym menu. I jak pozapamiętywać te wszystkie kluczowe wartości, żeby później nie szukać co to był za kod tego pomarańczowego, który używam do podkreśleń?
Obliczenia - dopełnianie się marginesów, paddingów i borderów, kolor lekko ciemniejszy, kolor lekko jaśniejszy. Ja zawsze do cięcia siadałem z kartką A4, która już po kilku godzinach była zapisana do pełna wartościami i obliczeniami.
{geshi lang=css}-moz-border-radius: 5px; -webkit-border-radius: 5px; border-radius: 5px;{/geshi}

Co więcej - to są problemy które pojawiają się już na etapie stron o średniej wielkości i kodowania w pojedynkę. W przypadku sporych serwisów (długo i wieloetapowo rozwijanych) i większego zespołu potrafią urosnąć do &*$#$%. To jest jak rzeźba w gównie. Trzeba przepisać cały ten bajzel. Sam ostatnio tak opisałem jeden commit do bazy.

Wysyp wspomagaczy

Jakiś czas temu dostałem od kogoś link do LESS CSS - parsera/kompilatora (nie wiem jak to nazwać) rozszerzającego możliwości CSSa o kilka interesujących rzeczy typu: zmienne, obliczenia, reguły zagnieżdżone, itd. O temacie jednak zapomniałem (mało ostatnio koduję) i przypomniał mi kilka dni temu o nim Occulkot, który podrzucił mi Sassa. Obydwa kompilatory napisane są w Rubym. Zrobiłem mały research i znalazłem jeszcze podobne cudo, tyle że w Pythonie - Clever CSS.

Po krótkim wczytywaniu się w przykłady zdecydowałem się na LESSa. Dodaje do CSSa trochę mniej ficzerów, ale przynajmniej nie zmienia jego składni (plik CSS jest poprawnym plikiem LESS) i nie wymusza na mnie jedynego, właściwego formatowania kodu (Sass i Clever CSS mają składnię czerpiącą z języków w jakich zostały napisane - odpowiednio Ruby i Python - wymagają więc wcięć).

Polecam przeczytać Haml-sass, czyli tragedia w dwóch aktach. Przy okazji tej lektury ja również odradzam Hamla, który jest w teorii cudownym (zen i te sprawy) systemem szablonów HTMLa. Tylko, że kompletnie to nieczytelne, brzydkie i bez sensu.

Instalacja

Po tym przydługim wstępie (chciałem usunąć, ale żal jak się już napisało) przejdźmy do konkretów.

Instalacja, dla posiadających gema (ci nieposiadający najlepiej niech go zainstalują), jest banalna:

{geshi lang=bash}$ sudo gem install less{/geshi}

Ewentualnie jeśli ktoś koduje w Railsach, to może go zainteresować ten plugin.Najprostszym sposobem skorzystania z LESSa jest jednak przy pomocy konsoli:

{geshi lang=bash}$ lessc style.less{/geshi}

Wykonanie tego polecenia spowoduje utworzenie pliku style.css zawierającego wynik działania kompilatora.

Ficzery

Zmienne

Kompilując taki kod:

{geshi lang=css}@brand_color: #4D926F; #header { color: @brand_color; } h2 { color: @brand_color; }{/geshi}

Otrzymamy:

{geshi lang=css}#header, h2 { color: #4d926f; }{/geshi}

Jak widać, poza podstawieniem zmiennej, LESS połączył też reguły o tej samej liście właściwości. To informacja dla miłośników oszczędzania na bajtach transferu :).

Wielokrotne wykorzystanie reguł

CSSowe DRY :).

{geshi lang=css}.rounded_corners (@radius: 5px) { -moz-border-radius: @radius; -webkit-border-radius: @radius; border-radius: @radius; } h1 .stronger { font-weight:bold; font-size:1.1em; } #header { .rounded_corners; h1 .stronger; } #footer { .rounded_corners(10px); }{/geshi}

Po kompilacji:

{geshi lang=css}h1 .stronger { font-weight: bold; font-size: 1.1em; } #header { -moz-border-radius: 5px; -webkit-border-radius: 5px; border-radius: 5px; font-weight: bold; font-size: 1.1em; } #footer { -moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius: 10px; } {/geshi}

Przy czym definicja reguły musi wystąpić przed jej użyciem. Przykład z wykorzystaniem h1 .stronger nie ma uzasadnienia w praktyce (jest w zasadzie błędny), ale chciałem tylko pokazać, że można wykorzystywać ponownie dowolne reguły.

Zagnieżdżone reguły

To chyba mój ulubieniec. Dzięki temu rozszerzeniu unikniemy pisania co chwilę mega długich selektorów. Dziwię się w ogóle, że nie ma tego w oficjalnym CSSie.

{geshi lang=css}#header { color: red; a { font-weight: bold; text-decoration: none; } > p { color: blue; } }{/geshi}

Po kompilacji:

{geshi lang=css}#header { color: red; } #header a { font-weight: bold; text-decoration: none; } #header > p { color: blue; }{/geshi}

Obliczenia

Chyba nie muszę tłumaczyć.

{geshi lang=css}@the-border: 1px; @base-color: #111; #header { color: @base-color * 3; border-left: @the-border; border-right: @the-border * 2; } #footer { color: (@base-color + #111) * 2; }{/geshi}

Po kompilacji:

{geshi lang=css}#header { color: #333333; border-left: 1px; border-right: 2px; } #footer { color: #444444; }{/geshi}

To by było na tyle. Jeśli kogoś temat zainteresował to zapraszam do specyfikacji, gdzie autor omawia jeszcze kilka dodatków.

W każdym razie - cztery małe ficzery, a jak cieszą, prawda? :)

Praca z LESSem

Zastanawiałem się tylko jak usprawnić kompilację po wprowadzeniu zmian do pliku LESS. Najfajniej gdyby udało mi się w moim VIMie podłączyć wykonanie $ lessc pod operację zapisania, ale to nie na moje umiejętności. Mcv zaproponował mi takiego Makefile'a:

{geshi lang=bash}%.css: %.less lessc $<{/geshi}

Wykonujemy go uruchamiając: $ make plik1.css plik2.css. To już powinno mi się udać podpiąć w VIMie pod zapis pliku. Ewentualnie można spróbować tak:

{geshi lang=bash}all: *.css %.css: %.less lessc $<{/geshi}

Co zadziała automatycznie dla wszystkich istniejących już plików CSS po wykonaniu prostego $ make. Przy czym, jeśli się mylę, to proszę mnie poprawić, bo nigdy żadnego makefile'a sam nie napisałem.

EDIT: w komentarzach pojawiły się rozwiązania mojego problemu.