Zapiski na Koszulce

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

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

Będzie krótko, bo jutro święto jakieś :)

Od bardzo dawna przy wielu stronach natrafiałem na problem w jaki sposób ostylować listę ~~definicji~~ opisów (patrz komentarze) dl, tak aby elementy dt wyświetlały się na lewo od elementów dd. Przy czym kod musiał spełniać warunki:

lista musiała się nie rozsypywać w przypadku różnej wysokości elementów dt i dd,
szerokość listy mogła być zmienna,
ustaloną szerokość miały elementy dt. Elementy dd miały się rozszerzać do maksymalnej dostępnej szerokości.

Nigdy nie miałem ochoty się w ten problem zagłębiać i jeśli już stałem pod ścianą to każdy "wiersz" takiej listy pakowałem do osobnego elementu dl, co rozwiązywało najtrudniejszy problem, czyli odpowiedniego ułożenia elementów w pionie. W sumie, to z tego niezbyt pięknego rozwiązania korzystałem często, bo w ten sposób używam listy definicji do tworzenia formularzy.

Ostatnio postanowiłem jednak rozwiązać swój odwieczny problem i po wielu próbach — między innymi z różnymi kombinacjami floatów, display:inline-block i wieloma dziwactwami — udało mi się znaleźć kilka rozwiązań, które działały, ale np. do momentu kiedy nie rozszerzyło się całej listy do sporej szerokości, albo nie nastąpił jakiś przypadek stosunków szerokości. Wpadłem jednak przed chwilą na rozwiązanie, które działa w każdym interesującym mnie przypadku i aż chcę się pochwalić :).

Skrócony kod HTML:

{geshi lang=html}

Widelec: Jest biały i leży na moim biurku.
Widelec: Jest biały i leży na moim biurku.
...

{/geshi}

I skrócony kod CSS:

{geshi lang=css}dl { width: 70%; min-width: 40em; overflow: hidden; ... } dt { float: left; width: 15em; clear: both; ... } dd:after { content: '\00a0'; display: block; clear: left; float: right; height: 0; width: 0; } dd { margin: 0 0 0.5em 18em; clear: right; ... }{/geshi}

Działający przykład.

Cała magia zawiera się w regule dla dd:after. To ona powoduje, że jeśli element dt jest wyższy od następującej po nim definicji, to następna definicja jest wyświetlana w odpowiednim miejscu (nie przeskakuje ponad swój temat).

Wesołego jajka. Idę spać :)

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

Opublikowane na licencji CC przez Trufflepig.

W poprzednim artykule o obiektach w JavaScriptcie poruszyłem kwestię ich tworzenia, dostępu do właściwości, kontekstu wywoływania metod oraz wspomniałem o kilku cechach. Czyste literały obiektów same w sobie są już w tym języku bardzo przydatne — przekonał się pewnie o tym każdy kto korzystał z jakiejś biblioteki typu MooTools czy Prototype. Pozwalają na przykład w dość wygodny sposób na podanie dowolnej liczby nazwanych argumentów funkcji:

{geshi lang=javascript}new Ajax.Request('/your/url', { parameters: { id: 12, action: 'sth' }, onSuccess: function (transport) { alert(transport.responseText); }, evalJS: false });{/geshi}

Pisałem ostatnio o tym, że w JavaScriptcie nie ma klas. Skąd więc w przykładzie słówko kluczowe new, które w typowym języku służy do tworzenia instancji obiektu na bazie jakiejś klasy? Otóż okazuje się, że w JavaScriptcie wprowadzono twór zwany konstruktorami obiektów.

Konstruktor obiektu

Zwyczajnie zaczyna się od definiowania klasy jakiegoś kotka, samochodu, czy figury geometrycznej. Nudy. Chciałem wymyślić coś bardziej konstruktywnego i spośród wszystkich dostępnych na moim biurku obiektów wybrałem butelkę po miodzie pitnym (pustą niestety). Myślę, że konstruktory dla napoju alkoholowego i butelki będą wystarczająco oryginalne :). Do dzieła:

{geshi lang=javascript}var Alkohol = function (nazwa, ilosc_procentow, kolor) { this.nazwa = nazwa; this.ilosc_procentow = ilosc_procentow; this.kolor = kolor; }; var ButelkaAlkoholu = function (alkohol, pojemnosc, rok_produkcji, kraj_produkcji) { this.alkohol = alkohol; this.pojemnosc = pojemnosc; this.rok_produkcji = rok_produkcji; this.kraj_produkcji = kraj_produkcji; };{/geshi}

Oj tak. JavaScript to dziwoląg. Miały być konstruktory obiektów, a tu znowu pojawiły się funkcje. Z drugiej strony pojawiło się też słowo kluczowe this, więc cały przykład przypomina dwa wycięte z definicji klas napisanych w normalnym języku konstruktory. Na szczęście obiekty tworzymy już normalnie:

{geshi lang=javascript}var miod = new Alkohol('Miód pitny', 13, '#850'); var butelka_miodu = new ButelkaAlkoholu(miod, 750, 2009, 'Polska'); console.dir(miod); // -> screenshot poniżej console.dir(butelka_miodu); // -> screenshot poniżej butelka_miodu.alkohol.nazwa; // -> "Miód pitny"{/geshi}

Utworzyliśmy w ten sposób dwa obiekty, których struktura została wylistowana przy pomocy Firebuga i którą przedstawiłem na screenie.

W poprzedniej części artykułu pisałem o tym, że obiekt może mieć swoje metody (inaczej funkcje przypisane jako właściwości obiektu). Musi więc być sposób aby w konstruktorze obiektu zdefiniować takie metody. Dodajmy więc kilka linii do konstruktora ButelkaAlkohol:

{geshi lang=javascript}var ButelkaAlkoholu = function (alkohol, pojemnosc, rok_produkcji, kraj_produkcji) { //... this.pelna = true; this.oproznij = function () { this.pelna = false; }; }; var butelka_miodu = new ButelkaAlkoholu(miod, 750, 2009, 'Polska'); butelka_miodu.pelna; // -> true butelka_miodu.oproznij(); butelka_miodu.pelna; // -> false{/geshi}

Jak widać, aby utworzyć coś co możemy nazwać metodą, musimy przypisać funkcję do właściwości przyszłego obiektu. Uczulam znowu na działanie słowa this, o czym pisałem już poprzednim razem.

Alternatywna metoda tworzenia konstruktorów obiektów

Naszym celem jest utworzenie obiektu o zadanych przez nas wartościach właściwości. Pamiętając, że najprostszym sposobem na utworzenie obiektu jest skorzystanie z literału możemy dojść do następującej konstrukcji: stwórzmy funkcję zwracającją obiekt zapisany za pomocą literału:

{geshi lang=javascript}var Alkohol2 = function (nazwa, ilosc_procentow, kolor) { var obj = { nazwa: nazwa, ilosc_procentow: ilosc_procentow, kolor: kolor, pelna: true, oproznij: function () { this.pelna = false; } }; return obj; }; var piwo = Alkohol2('piwo Tyskie', 5.6, '#FE3'); piwo; // -> Object nazwa=piwo Tyskie ilosc_procentow=5.6 kolor=#FE3{/geshi}

Tak więc skorzystaliśmy z funkcji w jej czysto funkcyjnym wymiarze. To jednak nie koniec. Dawno już nie było mowy o żadnym JavaScriptowym dziwactwie. Pora na następne. Otóż ten zapis również zadziała:

{geshi lang=javascript}var piwo2 = new Alkohol2('piwo Tyskie', 5.6, '#FE3'); piwo2; // -> Object nazwa=piwo Tyskie ilosc_procentow=5.6 kolor=#FE3{/geshi}

Zonk.

Anegdota o użyciu `new` z funkcją

Kiedy dowiedziałem się o powyższym od razu zacząłem się zastanawiać jak w zasadzie JavaScript traktuje new w kontekście funkcji. Pierwsze co ciśnie się na palce, to modyfikacja przykładu z konstruktorem Alkohol2 tak by zwracał "nieobiekt":

{geshi lang=javascript}var Cons = function () { return 5; }; var obj = new Cons(); obj; // -> Object{/geshi}

Nic ciekawego — jakiś pusty obiekt otrzymaliśmy. Dodajmy więc właściwość (pierwszy sposób tworzenia konstruktorów):

{geshi lang=javascript}var Cons = function () { this.a = 'a'; return 5; }; var obj = new Cons(); obj; // -> Object a=a{/geshi}

Ciekawe, choć do wytłumaczenia — return 5 jest pomijane. Połączmy teraz dwa sposoby tworzenia konstruktorów:

{geshi lang=javascript}var Cons = function () { this.a = 'a'; return { b: 'b' }; }; var obj = new Cons(); obj; // -> Object b=b{/geshi}

Uups. JavaScript pomija właściwości zadeklarowane przy użyciu słowa this. W ten sposób dochodzimy do algorytmu, którym kieruje się ten język (a przynajmniej Firefox — może komuś się chce zajrzeć do specyfikacji? :):

Jeśli zwracana przez funkcję wartość jest obiektem, to wyrażenie new Cons() zwraca ten obiekt.
W przeciwnym wypadku wyrażenie to zwraca obiekt z właściwościami ustalonymi przy pomocy słowa this.

Porównując obydwa sposoby pisania konstruktorów można dojść do wniosku, że lepsza jest ta druga, (ze zwracaniem gotowego obiektu), ponieważ działa na obydwa sposoby: new Cons() i Cons(). Osobiście uważam jednak, że ta metoda jest gorsza — dlaczego? O tym później w tej i w następnej części artykułu.

Elementy programowania obiektowego

Umiemy już tworzyć konstruktory obiektów, które można porównać do klas w zwyczajnym języku. Obiekty tworzone za ich pomocą posiadały do tej pory jednak tylko publiczne właściwości i metody. JavaScript nie udostępnia mechanizmu modyfikatorów dostępu, można jednak skorzystać z jego cech aby oprogramować w prosty sposób podobne konstrukcje.

Właściwości prywatne

{geshi lang=javascript}var Cons = function () { var private = 'jestem prywatna'; this.getPrivate = function () { return private; }; }; var obj = new Cons(); obj.getPrivate(); // -> "jestem prywatna" obj.private; // -> undefined{/geshi}

Dlaczego to działa? Wszystko opiera się o kolejny dziwoląg, czyli JavaScriptowego scope'a, a także o closures (BTW. fajne tematy na kolejne artykuły). W skrócie — funkcja zadeklarowana w innej funkcji ma dostęp do zmiennych dostępnych w swoim "rodzicu". Do tego mechanizm domknięć powoduje, że funkcja getPrivate "zapamiętuje" środowisko, w którym została zadeklarowana.

Właściwości statyczne

{geshi lang=javascript}var Cons = function () { this.nonstatic = 'nie jestem statyczna'; }; Cons.static = 'jestem statyczna'; Cons.static; // -> "jestem statyczna" Cons.nonstatic; // -> undefined{/geshi}

Chyba nic nie trzeba wyjaśniać. Konstruktor Cons jak każda funkcja jest obiektem, więc można dodawać mu właściwości, co robimy w czwartej linii.

Dla jasności dodam, że w identyczny sposób tworzymy prywatne i statyczne metody obiektów i klas.

Dostęp z obiektu do konstruktora

Każdy obiekt posiada właściwość constructor, która daje dostęp do konstruktora (porównywalne do Javowego Object.getClass()):

{geshi lang=javascript}var Cons = function () { this.sth = 'sth'; }; var obj = new Cons(); obj.constructor; // -> function() obj.constructor.toString(); // -> "function () { this.sth = "sth"; }"{/geshi}

A teraz niespodzianka. Dlaczego drugi sposób tworzenia konstruktorów (przez literał obiektu) uważam za gorszy? O to jeden z powodów:

{geshi lang=javascript}var Cons2 = function () { return { sth: 'sth' }; }; var obj2 = Cons2(); var obj3 = new Cons2(); obj2.constructor; // -> Object() obj3.constructor; // -> Object() obj2.constructor.toString(); // -> "function Object() { [native code] }" obj3.constructor.toString(); // -> "function Object() { [native code] }"{/geshi}

Zdefiniowaliśmy konstruktor, który teoretycznie działa jak ten z poprzedniego przykładu (zwraca obiekt o tej samej właściwości). Okazuje się jednak, że kiedy spróbujemy dostać się do konstruktora tego obiektu, to nie jest nim funkcja Cons2, a zwykła, natywna Object. Dla porównania:

{geshi lang=javascript}({}).constructor.toString(); // -> "function Object() { [native code] }"{/geshi}

Co dalej?

Umiemy już posługiwać się obiektami. Umiemy też tworzyć ich konstruktory. Pora więc na dziedziczenie. O tym za czas jakiś w następnej części :)

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

Opublikowane na licencji CC przez Trufflepig.

Do tego czteroczęściowego (jak zapowiem, to może napiszę :) artykułu natchnęło mnie szkolenie z zaawansowanego JavaScriptu które, w miniony weekend, zorganizował we Wrocławiu Damian Ferrante Wielgosik. Już na początku chciałbym mu podziękować za wiedzę, którą się podzielił, ponieważ przed szkoleniem byłbym wstanie napisać tylko część tego artykułu.

JavaScript to dziwoląg

Tego nie da się ukryć. JavaScript należy do wąskiej grupy języków z rodziny ECMAScriptu (JS, ActionScript, E4X), którą cechuje to, że ich obiektowość oparta jest na prototypach. Oznacza to, że w JavaScriptcie nie istnieje pojęcie klasy. Nie oznacza to jednak tego, że w JavaScriptcie nie da się programować obiektowo z wykorzystaniem np. konkretyzacji, dziedziczenia, czy właściwości prywatnych. Da się. Co więcej — da się uzyskać dużo więcej funkcjonalności klasycznego języka obiektowego, choć, o czym na sam koniec, niekoniecznie jest po co.

Obiekt

W języku z obiektowością klasową wypada zacząć od definicji klasy. Tak przynajmniej zaczynali autorzy książek, które czytałem. W przypadku JavaScriptu mielibyśmy jednak pewien problem, bo klas tutaj nie ma. Trzeba więc zacząć od utworzenia obiektu. Oto najprostszy:

{geshi lang=javascript}var obj = {}; typeof obj; // -> "object"{/geshi}

Tak, to w JavaScriptcie jest najprostszy obiekt. Zadeklarowany w przykładzie jest pusty i dziedziczy po obiekcie Object. Możemy sprawdzić to za pomocą poniższego kodu (jak działa i co to znaczy, o tym później):

{geshi lang=javascript}var obj = {}; obj.__count__; // -> 0, działa tylko w Firefoksie obj.__proto__.constructor; // -> Object(){/geshi}

Obiekt możemy również utworzyć za pomocą konstruktora Object(). Nie jest to jednak sposób polecany, ponieważ... zmienną Object można nadpisać. Lepiej pozostać przy literałach obiektów, które są bezpieczniejsze i ładniejsze.

{geshi lang=javascript}var obj = new Object(); // -> Object Object = 5; var obj2 = Object(); // -> TypeError: Object is not a constructor{/geshi}

Właściwości obiektu

Nic nam jednak z pustego obiektu. Pora dodać do niego dane i metody. Możemy skorzystać ze składni literału obiektu:

{geshi lang=javascript}var obj = { text: 'Jestem obiektem', saySth: function () { alert(this.text); } };{/geshi}

Bądź stworzyć pusty obiekt i dodać mu właściwości:

{geshi lang=javascript}var obj = {}; obj.text = 'Jestem obiektem'; obj.saySth = function () { alert(this.text); };{/geshi}

W obu przypadkach efekt będzie ten sam. Kiedy wywołamy obj.saySth(); dostaniemy alerta z tekstem Jestem obiektem.

Jeszcze słowo wtrącenia o literałach. Trzeba uważać na przecinek po ostatniej właściwości. Firefox i chyba wszystkie normalne przeglądarki trzymają się specyfikacji ECMAScript 5 pkt 11.1.5 (bądź to specyfikacja trzyma się tych przeglądarek ;), a kochany IE6, który zawsze musi być inny ("inny nie znaczy gorszy" w tym wypadku nie działa ;) trzyma się specyfikacji ECMAScript 3 pkt 11.1.5. Tak więc przecinek po ostatniej właściwości zostanie zaakceptowany przez przeglądarki z rodziny normalnych, zaś IE6 wywali cichaczem błąd. Nie wiem co prawda jak sprawa wygląda w IE7 i IE8, ale radzę po prostu tego przecinka nie stawiać. Koniec dygresji.

W Javie, czy PHP metoda obiektu jest czymś zupełnie innym niż jego właściwość. W JavaScriptcie metoda jest po prostu funkcją przypisaną do właściwości obiektu. Widać to najlepiej w trzeciej linii ostatniego przykładu: obj.saySth = function () {};. Wynika to z tego, że w JavaScriptcie funkcja też jest obiektem. Dzięki temu możemy ją przypisywać do zmiennych, zwracać w innych funkcjach, czy... wywoływać na niej metody. Ta właściwość JavaScriptu jest naprawdę potężna i myślę, że język ten sporo teraz zyskał w oczach osób lubiących Rubiego, Pythona, czy jakiś język funkcyjny :).

Uwaga na `this`

{geshi lang=javascript}typeof obj.saySth; // -> "function" var sayNothing = obj.saySth; typeof sayNothing; // -> "function" sayNothing(); // -> alert undefined{/geshi}

Z pierwszych trzech linii widać, że możemy sobie dowolnie operować funkcją. Czwarta może być zaskoczeniem. Dlaczego this.text === undefined? Zauważcie, że funkcja sayNothing nie została wywołana w kontekście obiektu obj, tylko w kontekście... no właśnie — czego? Żeby to sprawdzić dodajmy dwie linie kodu do poprzednich przykładów:

{geshi lang=javascript}window.text = 'Jestem globalnym scopem'; sayNothing(); // -> alert "Jestem globalnym scopem"{/geshi}

Teraz widać, że funkcja sayNothing(); wywołana jest w globalnym kontekście. Możemy ją także wywołać w odpowiednim kontekście używając metody call() działającej na funkcji (tak jak pisałem wcześniej — funkcja też jest obiektem, więc ma też swoje metody):

{geshi lang=javascript}sayNothing.call(obj); // -> alert "Jestem obiektem"{/geshi}

Więcej na ten temat u Ferrante w "this" w JavaScript.

Jeszcze trochę o obiektach

Do właściwości obiektu możemy się również dostać za pomocą operatora [], czyli w taki sposób jak do elementów tablicy. Jest to przydatne kiedy chcemy uzyskać właściwość, której nazwa trzymana jest w zmiennej:

{geshi lang=javascript}var obj = { a: 'A', b: 'B', m: function () { return 'M'; } }; obj['a']; // -> "A" var name = 'b'; obj[name]; // -> "B" obj['m'](); // -> "M"{/geshi}

Po właściwościach obiektu można też iterować za pomocą konstrukcji for (i in obj). Trzeba jednak uważać, bo, w zależności od tego jakim obiektem dysponujemy, możemy dostać niespodziewane (przynajmniej na razie) rezultaty. Póki co jednak wystarczy nam:

{geshi lang=javascript}var obj = { a: 'A', b: 'B', c: 'C', d: 'D' }; for (i in obj) { alert('obj[' + i + '] = ' + obj[i]); }{/geshi}

Obiekty można też zagłębiać. Jest to własność oczywista, ale wypada dla jasności o niej wspomnieć.

{geshi lang=javascript}var obj = { obj: { obj: { hidden: 'Zonk' } } }; obj.obj.obj.hidden; // -> "Zonk"{/geshi}

Co dalej?

Samym obiektem programista żyć nie może. Klas jednak w JavaScripcie nie uświadczymy, trzeba więc wymyślić coś innego. Z pomocą przyjdą nam konstruktory obiektów, ale zrobią to dopiero w następnej części :).

Poza tym w trzeciej części mam zamiar napisać o prototypach, czyli JavaScriptowym dziedziczeniu. W czwartej chciałbym zebrać wszystko do kupy, pokazać może jakieś wzorce i napisać kilka uwag o programowaniu w JavaScriptcie. W zasadzie to uwagi mam już napisane, bo zacząłem od końca :D

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.

Zen Coding - snippety nie mają szans

Sun, 22 Nov 2009 23:58:11 +0100

Snippety do htmla? Nieeee. Zobaczcie Zen Coding. W skrócie działa to tak. Wpisuję w edytorze CSSową składnią:

{geshi lang=css}div#content>h1+p{/geshi}

Wciskam jakąś kombinację klawiszy i dostaję:

{geshi lang=xml}

{/geshi}

Sprytne, nie? :) Ale to jeszcze mało. Spróbujcie tego:

{geshi lang=css}div#top>h1>a[title=Do strony głównej]{Moja strona}

li.pos$*3>a{/geshi} {geshi lang=xml}

Moja strona

{/geshi}

Chyba nie muszę mówić jak bardzo taka pomoc przyspiesza pracę. Napisanie z palca kodu z drugiego przykładu zajęłoby mi przypuszczalnie więcej niż 2 minuty. Gdybym użył snippetów (do których przy HTMLu nie mogę się przyzwyczaić) może skróciłbym ten czas dwukrotnie. Zaś używając wynalazku Zen Coding całość naklepałem w 20s (i to nie mając wprawy). Tak więc gorąco polecam.

Gdyby ktoś szukał wtyczki do VIMa, to powstał plugin, którego twórca zainspirował się Zen Codingiem.

O tym jak wydłużyłem sobie dobę

Sat, 21 Nov 2009 02:39:47 +0100

Tym razem będzie krótko i o życiu.

Do niedawna mój przykładowy dzień wyglądał tak:

8:30-9:00 pobudka
10:00 pojawiam się w pracy (albo zasiadam do niej w domu)
16:00-17:00 kończę robotę (tak - to nie 8h; pracuję na 1/2 etatu, a w pracy jestem 3dni/tyg.)
18:00 po godzinnym staniu w korkach jestem w domu
19:00 zjadłem, odpocząłem, mogę zabrać się do pracy i biegania
2:00 damn - pora iść spać - nie za dużo tego czasu miałem

Dało się tak żyć w lecie. Teraz niestety prawie całą moją dobę było ciemno za oknem, co zaczęło dodatkowo działać depresyjnie. Do tego stałem sobie codziennie w pięknych koreczkach tracąc dodatkowe godziny doby i denerwując się, co działa demotywująco.

Zmiana

Całkiem przez przypadek założyłem się z siostrą, że wyjdę z domu przed nią (czyli przed ok. 8:00). Budziki nastawiłem już od 6:20, bo potrzebuję minimum pięciu żeby się obudzić. Fartem - złapał mnie już pierwszy i... pierwszy raz od... uh - roku? dwóch? wyszedłem z domu o 6:50. I mój dzień wyglądał tak:

7:10 w pracy - korków jeszcze nie było
15:00 wychodzę - zrobiłem całe 8h, więc jeden z 3 dni roboczych będę miał luźny. Dodatkowo widziałem wschód słońca, skończyłem jak ciągle było jasno na dworze
15:20 w domu - koreczków nie było, wróciłem ekspresowo
16:20 kończę bieganie - wreszcie udało mi się pobiegać przy świetle dziennym
17:20 zabieram się do pracy, nauki, itd.
1:00 już zasypiam, żeby następnego dnia powtórzyć historię

I tak żyłem przez kilka dni. Efekt niesamowity. Zrobiłem rzeczy, które wcześniej zajęłyby mi kilka tygodni. Dodatkowo psychika lepiej znosi zimę, bo nie przesypiam połowy dnia. No i w jeden z 3 dni pracuję tylko 4h.

Co dalej?

Co prawda dzisiaj (co widać po godzinie) idę spać późno, ale to wypadek przy pracy. Zamierzam i tak wstać o 7:00, bo najważniejsze, to wyrobić sobie nawyk. Dobranoc i życzcie mi powodzenia :)

WUD Tour 2009 - Wrocław - relacja i przemyślenia

Wed, 18 Nov 2009 23:28:17 +0100

W zeszły czwartek (tj. 12 listopada) odbyła się Wrocławska część WUD Tour, na której miałem przyjemność być. Nawiasem mówiąc była to pierwsza konferencja poświęcona usability, na którą dotarłem, bo naście poprzednich albo przegapiłem, albo z przyczyn niezależnych dotrzeć nie mogłem. Tym razem też nie było idealnie, bo po kilku pierwszych prezentacjach musiałem udać się na zajęcia.

W skrócie co widziałem

Wprowadzenie do tematyki usability - nic szczególnego, ani tym bardziej zaskakującego - raczej dla tych, którzy pomylili salę i potrzebowali wprowadzenia od zera.
Akcelerator Designu - prezentacja pracowników Urzędu Miasta Wrocławia dotycząca inicjatywy mającej na celu promowanie idei wzornictwa przemysłowego i użyteczności wśród przedsiębiorców (itd., itd.). Temat póki co mnie nie prawie nie dotyczący, więc było trochę nudno. Sytuację poprawił dopiero trzeci z prowadzących będący z pochodzenia Włochem, który swoją łamaną polszczyzną bardzo zgrabnie przedstawił nam pewnego włoskiego designera. Kto był ten wie o czym mówię ;D
Co chcą zobaczyć klienci sklepów elektronicznych? - O tej prezentacji za chwilę. W skrócie powiem tylko, że była całkiem ciekawa i tak "politechnikowo" przedstawiona :P
Możliwość używania - drugi biegun względem poprzedniej ekipy (prosta graficznie prezentacja, ale ładnie opracowana typograficznie versus prezentacja "specyfikacyjna" :). Prelekcja przeprowadzona przez Krzysztofa Kubaska - pracownika ASP i projektanta wzornictwa zawodu, dotycząca łączenia użyteczności z designem. Krzysztof z powodzeniem pokazywał, że te dwie rzeczy mogą iść ze sobą w parze i współpraca designera z inżynierem jest jedną z podstaw dobrego produktu. Przy okazji pokazał kilka przykładów zabawnie zaprojektowanych przedmiotów codziennego użytku, jak np. widelec w kształcie samolotu (leci samolocik... AM! :P), czy kubków z dziobami/pyskami zwierząt. Krzysztof zrobił dobre wrażenie i myślę, że taki był główny cel tej prezentacji. Według mojej spiskowej teorii - śmiech -> dobre wrażenie -> więcej klientów ;). Zwróciłem też uwagę, że specjalistów od usability uważa za informatyków. Ciekawe :)

Później niestety musiałem już sobie iść. Najciekawsze prelekcje opuściłem i czekam z niecierpliwością na video z konferencji.

Czy użytkownik jest złym projektantem?

Wracając do prelekcji dotyczącej sklepów internetowych. Marcin Kuliński przedstawił nam narzędzie służące do badania preferencji użytkowników dotyczących rozmieszczenia elementów interfejsów (w tym przypadku sklepów internetowych). Narzędzie to składało się z dwóch części - pierwszej - bardzo prostej, pozwalajacej za pomocą drag&dropa zaprojektować z dostępnych elementów własny interfejs. Druga służyła do przeglądania wyników tego badania. Nie pamiętam wszystkich funkcji tego narzędzia, ale na pewno można było filtrować badanych, porównywać wyniki dla grup, itd.

Drugą część prezentacji prowadziła Katarzyna Jach, która przedstawiła wyniki badań na grupie, jeśli dobrze pamiętam, 500 studentów IZetu. Zostali oni zapytani gdzie umieściliby przedstawione im elementy interfejsu. Dla każdego z predefioniowanych elementów serwisu (logo, kategorie, zdjęcie produktu, itd) zobaczyliśmy "mapę cieplną" gdzie badani widzieli tę funkcjonalność. Wyników nie pamiętam i nie udało mi się ich znaleźć. Dotarłem tylko do screenów i dema aplikacji nazwanej pieszczotliwie microSzu.

Na zakończenie z sali padły dwa pytania. Jedno dotyczyło tego po co powstała ten system skoro można przeprowadzić testy A/B przy pomocy Google Website Optimizera (który jest bezpłatny, w przeciwieństwie do microSzu). Dla mnie odpowiedź jest oczywista (a pytanie bez sensu) - testy A/B pozwalają nam jedynie udoskonalać istniejącą już stronę i tylko element po elemencie. Wcześniej trzeba przecież tę stronę zaprojektować, czyli między innymi rozmieścić na niej elementy interfejsu. Badanie przeprowadzone przez microSzu pozwala nam na optymalne dla użytkowników zaprojektowanie strony. No właśnie - czy na pewno optymalne?

Tego dotyczyło kolejne pytanie, a w zasadzie stwierdzenie - "użytkownik nie jest dobrym projektantem". W pierwszym momencie stwierdziłem, że i to pytanie jest bez sensu. Nie dajemy przecież użytkownikowi projektować, tylko badamy jego preferencje. To przecież część UCD. Później (między innymi po przeczytaniu relacji Agnieszki Matysiak-Szóstek, której prelekcji nie widziałem, czego bardzo żałuję) zacząłem się zastanawiać, czy na pewno mam rację. W końcu badanie polegało nie tylko na odpowiedzi na pytanie gdzie szukałaby Pani/Pan listy kategorii?, ale na zaprojektowaniu całej strony na raz, czyli zmierzeniu się np. z problemem - ten róg mam już zajęty, gdzie ja teraz ciapnę to to?.

Myślę, że właśnie w treści pytania i zadaniu do wykonania leży cały problem. Gdyby udało się uzyskać od badanego wszystkie informacje, bez zmierzenia go z problemem całej strony jednocześnie, to uzyskane dane byłyby bardzo przydatne. Możnaby stworzyć proste wytyczne, w którym miejscu (bądź miejscach) możemy umieścić dany element by był łatwo znajdowalny (jeśli chodzi o region, bo pozostają użyte nazwy, czy kolor/wielkość/etc.) przez użytkownika. I nie musi to od razu ograniczać inwencji i talentu projektanta, który może zawsze zaryzykować jakąś zmianę względem szablonu. To jest tylko propozycja, a czy skorzystam, to zależy np. od ilości czasu jaką mogę projektowaniu poświęcić.

Tak przynajmniej myślę ja u początków mojej przygody z użytecznością :)

Adobe AIR podstaw podstawy

Sat, 25 Apr 2009 23:19:15 +0200

Generalnie, jako bardziej linuksowe wydanie geeka, nie patrzyłem na newsy związane z Adobe AIR zbyt przychylnym okiem. Jakieś zamknięte rozwiązanie, pewnie trzeba mieć adobowskie środowisko za 1k$ od stanowiska i na bank zrobią obsługę na Linuksie za dwa lata, jak zacznie im się tam nudzić. Tak więc skłaniałem się bardziej ku rozwiązaniom pokroju Mozilli Prism, czy Google Gears. Byłem jednak przez Darka Juszczuka namiętnie atakowany linkami o AIRze i kiedyś jeden otworzyłem. Na stronie znalazłem przycisk "install", po kliknięciu którego, jak zrozumiałem, miała zainstalować mi się jakaś aplikacja.Z uśmiechem politowania na twarzy, bo w końcu nie mam AIRa na swoim Linuksie, więc się musi wysypać, kliknąłem w ów przycisk. No i zonk. Z poziomu wtyczki Flash zainstalował mi się Adobe AIR, po czym zaczął się instalować program, którego stronę przed chwilą oglądałem. Z pewną dozą nieufności podałem swoje hasło "administratora" (jedyny minus - nie wystarczą uprawnienia szarego usera do instalacji softu - na szczęście sam instalator jest zaufany) i gotowe. Aplikacja się odpala, śmiga jak marzenie, ładnie wygląda i w ogóle jakbym się na Windowsa przeniósł. No cóż. To skoro panowie z Adobe się tak postarali pora dać im szansę :).

AIR - was ist das?

Za wikipedią:

Adobe Integrated Runtime, w skrócie AIR (nazwa kodowa Apollo) – wieloplatformowe środowisko wykonawcze dla RIA (ang. Rich Internet Application) zbudowanych za pomocą Flash, Flex, lub HTML i AJAX.

Programy AIR mogą być aplikacjami pulpitu.

Czyli? Środowisko dla efektownych i bogatych aplikacji internetowych. Aplikacje te mogą być odpalane jak normalne desktopowe programy. A co to w praktyce? Jeszcze nie do końca wiem, bo w zasadzie, to na bieżąco się uczę pisząc ten artykuł (dla tego proszę o poprawianie jak bym jakoś naginał czasoprzestrzeń), ale na pewno integracja z systemem plików, lokalna baza danych, kontrolki jakie oferuje Flex (o nim pewnie w przyszłości), itd.

Co ważne dla geeków ortodoksów. AIR != Flash. Aplikacje Flashowe mogą używać AIRa by powiększać swe możliwości. Ale Flasha w aplikacji AIRowej może w ogóle nie być. Zamiast niego można z powodzeniem użyć XHTMLa+JS, czy Fleksa+Actionscripta (który to kompiluje się już do obiektu SWF, ale za to ma wolne SDK i nie potrzeba do niego żadnych płatnych narzędzi).

Co trochę znamienne dla strony Adobe - miałem przed chwilą spory problem z podlinkowaniem SDK Fleksa. Niestety nie potrafię się poruszać płynnie po ich stronie i w ogóle nie znalazłem podstrony samego SDK. Ale spokojnie - może trochę dziwnie i niespójnie połączone, ale na stronie(nach) znajduje się cała potrzebna dokumentacja, którą do tej pory oceniam raczej dobrze.

Aha - Flex, jeśli dobrze rozumiem, jest open source'owy :O

Moja pierwsza aplikacja AIR oparta o HTML

Czego potrzebujemy? Na pewno przyda nam się AIR SDK. Co prawda można skorzystać także z darmowej Aptany, albo płatnego Adobe Dreamweaver CS3/CS4 z Adobe AIR Extension for Dreamweaver, ale my skupimy się na najniższym poziomowo rozwiązaniu, czyli AIR SDK (który rzecz jasna należy pobrać). Do tego na pewno będzie nam potrzebna zainstalowana biblioteka uruchomieniowa (czyt. plugin) Adobe AIR. No i na koniec zwykły edytor tekstu (najlepiej gvim :).

Mało odkrywczo zaczniemy od przywitania się ze światem. Nie pokazuje to ani trochę możliwości AIRa, ale w tym wpisie już nic więcej nie zmieszczę - za długi się robi :). Stwórzmy więc sobie katalog HelloWorld, w którym będziemy potrzebowali kilku plików.

HelloWorld.html: plik obowiązkowy - główna strona naszej aplikacji,
HelloWorld-app.xml: również obowiązkowy - konfiguracja aplikacji (z ang. descriptor) w którym między innymi można ustawić ścieżkę instalacji, nazwę, ikony, ustawienia okna, czy ścieżkę do głównego pliku HTML,
AIRAliases.js: plik przydatny - tworzy proste aliasy do JSowych obiektów dostępnych dzięki AIR. Np. zamiast window.runtime.flash.filesystem.File otrzymujemy air.File. Plik ten przekopiowujemy z sciezka_do_AdobeAIRSDK/frameworks/libs/air/.

Na początek HelloWorld.html. Zakładam, że składnię HTMLa znasz i nie muszę nic tłumaczyć. Jakby ktoś chciał więcej szczegółów odnośnie zawartości plików, to odsyłam do źródła skąd cały ten przykład zaczerpnąłem.

{geshi lang=xml}

Hello World

{/geshi}

Jak widać - żadnych rewolucji. Pora na HelloWorld-app.xml:

{geshi lang=xml} examples.html.HelloWorld 0.1 HelloWorld HelloWorld.html true 400 200 {/geshi}

Wydaje mi się, że wszystko powinno być jasne. Jedynie wartość elementu <filename> była dla mnie niejasna, więc tłumaczę - jest to nazwa aplikacji w systemie (czyli po zainstalowaniu). Wchodzi w to: katalog instalacyjny, plik wykonywalny oraz nazwa w menu systemowym (każdą z tych rzeczy można jeszcze ustawić osobno).

Testowanie aplikacji

Do testowego uruchamiania (i debugowania) stworzonej aplikacji służy odpalany z wiersza poleceń AIR Debug Launcher (ADL). Znajduje się on w sciezka_do_AdobeAIRSDK/bin/. Włączamy więc konsolę, przechodzimy do katalogu HelloWorld i startujemy:

p@d:/air/HelloWorld$ /air/AdobeAIRSDK/bin/adl HelloWorld-app.xml
Jakis trace
p@d:/air/HelloWorld$

Powinniśmy obejrzeć takie o to, piękne okienko:

Jak widać program wydrukował nam też na konsoli "Jakis trace" co jest wynikiem działania air.trace("Jakis trace").

Tworzenie pliku instalacyjnego .air

Pora teraz spakować do jednego pliku instalacyjnego (paczka zip) naszą aplikację dzięki której zapanujemy nad światem. Służy do tego narzędzie ADT.

Pierwsze co trzeba wiedzieć, to że wszystkie AIRowskie aplikacje są cyfrowo podpisane. Temat ten jest mi kompletnie obcy i za pierwszym razem męczyłem się 3h żeby wygenerować jakiś swój klucz. Otóż poszedłem w stronę javowego keytoola, co było dla mnie ślepą uliczką ;). Co prawda nauczyłem się generować wszystkie typy kluczy, ale żaden nie działał :D. Na szczęście jest o wiele prostsza (i przede wszystkim działająca) ścieżka, którą przegapiłem. O niej za chwilę, a teraz cytat ze strony Adobe o bezpieczeństwie:

To ensure application security, all AIR installation files must be digitally signed. For development purposes, you can generate a basic, self-signed certificate with ADT or another certificate generation tool. You can also buy a commercial code-signing certificate from a commercial certificate authority such as VeriSign or Thawte. When users install a self-signed AIR file, the publisher is displayed as “unknown” during the installation process. This is because a self-signed certificate only guarantees that the AIR file has not been changed since it was created. There is nothing to prevent someone from self-signing a masquerade AIR file and presenting it as your application. For publicly released AIR files, a verifiable, commercial certificate is strongly recommended. For an overview of AIR security issues, see AIR security.

Oczywiście przegapiłem zaznaczony fragment i cały akapit poniżej :) A w zasadzie to mam wrażenie, że go tam wcześniej nie było. Ale koniec płaczu nad straconym czasem. Generujemy własny klucz:

p@d:/air/HelloWorld$ /air/AdobeAIRSDK/bin/adt -certificate -cn AIRBegginer 1024-RSA my_key_file dupa.8

W ten o to sposób wygenerowaliśmy klucz na nazwę podmiotu (company name) AIRBegginer, zabezpieczony hasłem dupa.8, który został zapisany do pliku my_key_file. Można go podejrzeć javowym narzędziem keytool:

p@d:/air/HelloWorld$ keytool -list -v -keystore my_key_file -storetype pkcs12
Enter keystore password:  

Keystore type: PKCS12
Keystore provider: SunJSSE

Your keystore contains 1 entry

Alias name: 1
Creation date: 2009-04-25
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=AIRBegginer
Issuer: CN=AIRBegginer
Serial number: 36373061626165333a31323064646264383133663a2d38303030
Valid from: Sat Apr 25 16:46:05 CEST 2009 until: Fri Apr 25 16:46:05 CEST 2014
(...)

Tak utworzonym kluczem możemy teraz podpisać naszą aplikację:

p@d:/air/HelloWorld$ /air/AdobeAIRSDK/bin/adt -package -storetype pkcs12 -keystore my_key_file HelloWorld.air HelloWorld-app.xml HelloWorld.html AIRAliases.js

Zostaniemy poproszeni o hasło i jeśli nic nie skopaliśmy, to ADT stworzy nam plik HelloWorld.air, który jest naszą pierwszą spakowaną i gotową do instalacji aplikacją AIR.

Instalacja

Najprostszy sposób jeśli mamy w systemie zmapowane rozszerzenie .air z instalatorem Adobe AIR (ja standardowo tak miałem) to instalacja jak na Windowsie - przez podwójnego klika w HelloWorld.air. Jeśli nie to wpisujemy:

p@d:/air/HelloWorld$ /opt/Adobe AIR/Versions/1.0/airappinstaller ./HelloWorld.air 
unexpected error: ArgumentError: Error #2004
p@d:/air/HelloWorld$ /opt/Adobe AIR/Versions/1.0/airappinstaller /air/HelloWorld/HelloWorld.air

Jak widać skrypt jest zbyt "głupi" żeby sobie poradzić ze ścieżką względną i trzeba podać absolutną. Chwila czekania i zium:

Znów hasło roota i wszystko działa.

Zarządzanie zainstalowanymi aplikacjami na Linuksie

Programy niestety na moim Ubuntu pojawiają się w menu systemowym w sekcji "Akcesoria". Zainstalowałem już kilka na próbę i zaczął mi się tam robić bałagan. Ustawienie w pliku konfiguracyjnym aplikacji pola <programMenuFolder> zdaje się działać tylko na Windowsach.

Przed chwilą znalazłem także informację o tym jak można zarządzać już zainstalowanymi programami. Otóż są one instalowane jak paczki odpowiednio deb albo rpm. Dzięki temu np. w moim Ubuntu mogłem odinstalować programy z poziomu Synaptica. Nazwa programu składa się z z pola applicationId (np. examples.html.helloworld) oraz publisherID.

Uwaga dla każdego, kto nie znalazł swojej aplikacji - ja musiałem zrestartować system żeby Synaptic się odświeżył.

Koniec

To by było na tyle. Miałem jeszcze w tym artykule (ależ to ładnie brzmi ;P) pokazać jakiś ciekawszy przykład aplikacji, ale wydaje mi się, że byłby to już zbyt długi wpis. Postaram się więc dość szybko zmajstrować następną notkę. I będzie ona albo przedstawiała możliwości jakie daje AIR, albo skrobnę coś o Fleksie. A najpewniej i jedno, i drugie w krótkim czasie :).

Jeśli chodzi o ten wpis, to wszelkie sugestie, uwagi, czy pytania mile widziane. Jak zaznaczyłem gdzieś po drodze - moja wiedza na temat Adobe AIR jest nikła i mogłem popełnić sporo błędów.

Źródło i inne przydatne linki

Źródło, którego ten tekst jest w zasadzie bardzo luźnym tłumaczeniem,
Więcej informacji o Adobe AIR na Linuksie,
AIR Developer Center - sam czubek góry lodowej. Stąd chyba dobrze zaczynać poszukiwania czegokolwiek,
Dokumentacja Adobe AIR.

Wpis ten ukazał się równolegle na moim blogu firmowym.

Walidacja jednego pola formularza w symfony

Tue, 31 Mar 2009 15:34:02 +0200

Natknąłem się ostatnio na problem. Otóż wszystkie formularze walidujemy przy wykorzystaniu symfoniowych Formsów. Standardowe użycie podczas aktualizacji obiektu Place wygląda następująco:

{geshi lang=php}$this->form = new PlaceForm ($place); $this->form->bind ($request->getParameter ('place')); if ($this->form->isValid()) { $place = $this->form->updateObject(); $place->save(); }{/geshi}

Co jednak kiedy nie chcemy walidować całego formularza? Np. w przypadku kiedy używając InPlaceEditora zmieniamy jedno pole. Podpowiem, że próba wysłania tylko tego jednego pola i wykorzystaniu tej samej akcji skończy się wyzerowaniem pozostałych pól.

Dokumentacja symfony niestety milczy na ten temat (choć przyznam się, że nie szukałem jakoś strasznie dokładnie), a wiemy chyba wszyscy co jest jej największą bolączką - opisanie tylko kilku funkcjonalności poszczególnych modułów. Jak się chce czegoś więcej, to droga wolna - szukajcie sobie sami w kodzie.

Tak też postąpiłem. I po koszmarnie długim czasie odkryłem, że do walidowania każdego z pól służy metoda o intuicyjnej nazwie... clean(). Przykład walidacji jednego pola:

{geshi lang=php}$form = new PlaceForm($place); try { $cleaned = $form->getValidator($field_name)->clean($value); #1 $place->setByName($field_name, $cleaned, BasePeer::TYPE_FIELDNAME); #2 $place->save(); } catch (sfValidatorError $e) #3 { #Obsługa błędu }{/geshi}

Pobranie odpowiedniego walidatora oraz wywołanie na nim metody clean(), która w przypadku, gdy pole ma poprawną wartość zwraca je. A w przypadku błędu wyrzuca wyjątek sfValidatorError,
Zapisanie wyczyszczonej wartości tego pola do obiektu,
Kod obsługujący przypadek niewalidującego się pola.

Mam nadzieję, że ten krótki artykuł pozwoli komuś zaoszczędzić trochę czasu.

Wpis opublikowałem także na firmowym blogu code42.

Ideowo o HTMLu i CSSie

Wed, 18 Mar 2009 02:28:32 +0100

Nie, nie będzie to wpis o tym jak moim zdaniem powinien wyglądać HTML5 i CSS3 (a w zasadzie to 4 już). Popełnienie takiego tekstu mam w planach i jak trochę powrócę do żywych, to może mi się uda :).

Jak pewnie niektórzy wiedzą - zostałem zatrudniony na etacie w firmie, z którą od dłuższego czasu (~dwa lata) współpracowałem jako freelancer. Na pierwszy ogień poszedł mały, wewnętrzny projekt, przy którym współpracuję między innymi z mcvłem. Do tej pory obaj sporo tworzyliśmy HTMLa i CSSów, ale żaden z nas, a na pewno nie ja, nie musiał przy tym z nikim ściśle współpracować.

Każdy programista na pewno rozumie to, że w nowym zespole zawsze trzeba ustalić konwencje dotyczące stylu kodowania. My apropo HTMLa ustaliliśmy, że używamy pojedynczych cudzysłowów (do tej pory zawsze korzystałem z podwójnych i herezją było dla mnie używanie pojedynczych, ale w zasadzie nie jest źle :). Z CSSem było gorzej, bo musiałem zmusić mcvała żeby pisać całe selektory i wszystkie właściwości w jednej linii, ale dało radę.

I tak z pierwszymi ustaleniami zasiedliśmy do pracy. Popracowaliśmy całe 4 dni i okazało się, że te krótkie ustalenia to stanowczo za mało.

`<address>`

Interpretacja mcvała

Tagu address możemy używać jedynie zgodnie ze specyfikacją HTMLa 4.01:

The ADDRESS element may be used by authors to supply contact information for a document or a major part of a document such as a form.

Czyli możemy w tym tagu zawrzeć informacje dotyczące kontaktu z autorem (prawdopodobnie jedynie drogą elektroniczną). Mogą to być linki, maile, ale co ciekawe - ulica i miasto już raczej nie. Wydaje się to potwierdzać dość dziwny przykład podany dalej w specyfikacji:

{geshi lang=html}

Dave Raggett, Arnaud Le Hors, contact persons for the W3C HTML Activity
$Date: 1999/12/24 23:37:50 $

{/geshi}

Moja interpretacja

Nie ma potrzeby trzymać się co do słowa niedoskonałej specyfikacji HTMLa sprzed prawie 10 lat. Użyjmy taga address jako taga semantycznego nadającego znaczenie każdemu zawartemu w środku adresowi (czy to pocztowemu, czy mailowemu, czy też stronie firmowej). Dodatkowo - nie oznaczajamy nim jedynie danych kontaktowych z autorem strony, ale także z każdym innym podmiotem, który na stronie opisujemy (np. we wszelakich bazach miejsc).

Dodatkowo uważam, że nazwa address jest bardzo niefortunna, jeśli mamy tam umieszczać linki. Gdyby ktoś miał na myśli jedynie informacje o kontakcie, to tag nazywałby się contact.

I tutaj chciałbym wesprzeć się przetłumaczonym przez Łukasza Grabunia artykułem pt. Zapomniane znaczniki, który od lat służy mi pomocą w walce ze sklerozą :).

Inne moje nadinterpretacje

Istnieje jeszcze kilka innych tagów, przy których interpretacji nie uważam za sensowne ściśle trzymać się specyfikacji. Od razu podkreślam, że nie mam na myśli zupełnego oderwania się od niej. Nie chcę używać table jako tagu do opisu stołu w restauracji, albo tabelkowego layoutu. Uważam natomiast, że na przykład lista definicji to nie tylko stricte:

{geshi lang=html}

Kura: Stworzenie boskie, o dwóch nogach i opierzonym ciele

{/geshi}

Ale także inne konstrukcje zawierające jakiś temat i jego zawartość. Na przykład lista użyta przeze mnie wcześniej trochę z premedytacją:

{geshi lang=html}

Interpretacja mcvała: (...)
Moja interpretacja: (...)

{/geshi}

Oczywiście mogłaby też wyglądać tak:

{geshi lang=html}

Interpretacja mcvała

(...)

Moja interpretacja

(...)

{/geshi}

I w pewnym przypadkach jest to zdecydowanie poprawniejsze rozwiązanie. Jednak kiedy nagłówki sekcji nie są wyraźne (mam tu na myśli rzecz jasna znaczenie wynikające z treści strony, a nie jej wyglądu :P) i są jedynie opisami tego co znajduje się niżej, to wolę użyć rozwiązania pierwszego. Ale akurat w specyfikacji listy definicji twórcy HTMLa podali więcej przykładów, które w pewnym sensie tłumaczą moją nadinterpretację.

Przypomina mi się także, że kiedyś był mały ruch przekonujący by całą stronę (poza treścią typowo akapitowo - nagłówkową) opisywać listami uporządkowanymi, nieuporządkowanymi i listami definicji. W pewnym sensie zgadzałem się z tym, że cała strona jest jakąś listą i sporą większość jej elementów da się zrozumieć jako jakąś część listy. Zdaje się jednak, że to już przesada w drugą stronę :)

Na HTMLu nie koniec

Żeby nie było za miło posprzeczaliśmy się także o niektóre rozwiązania w CSSie :)

Styl mcvała

zostawiamy przeglądarkowe paddingi i marginesy, bądź ustalamy ich początkowe wartości (ale nie na zero),
aby odsunąć w pionie zawartość rodzica od dziecka nadajemy dziecku marginesy pionowe i jeśli potrzeba rodzicowi padding:0.1px. Jeśli trzeba, czyli w przypadku braku obramowania, bądź paddingu,
wszystkie marginesy i paddingi ustalamy według emów - aby zwiększona w kodzie wielkość czcionki miała wpływ na te wielkości.

Mój styl

zerujemy za pomocą * {padding:0; margin:0} wszystkie niepotrzebne odstępy, aby móc nad nimi dokładnie zapanować. Nadajemy je z powrotem dopiero w treściach strony,
aby odsunąć w pionie zawartość rodzica od dziecka używamy paddingów dla tego pierwszego. A poprzez :last-child zerujemy margines ostatniemu dziecku (dzieci mają marginesy aby je od siebie odsunąć),
marginesy i paddingi w 90% przypadków podajemy w pikselach, by mieć większą kontrolę nad ich wartościami (i nie mieć zonka że coś się rozjeżdża bo zmieniłem wielkość czcionki)

Oczywiście żaden z nas nie był w stanie przekonać drugiego do swoich racji :). Niestety - obaj w swoim życiu już za dużo layoutów pocieliśmy i zbyt wyrobione mamy zdanie na niektóre tematy. Ale i tak uważam, że można się sporo ciekawych rzeczy dowiedzieć pracując z drugą osobą. Ja na przykład dowiedziałem się o własciwości box-sizing i wreszcie zapanuję nad {width:100%; padding:10px} :).

"Echowanie" Javascriptu przy pomocy Firebuga

Sun, 08 Mar 2009 00:04:44 +0100

Rys historyczny, można pomijać

Tak, wiem, że istnieje coś takiego jak debugger :). Nigdy się jednak z żadnego porządnie nie nauczyłem korzystać. Po trochu dlatego, że wymaga to zazwyczaj poświęcenia dodatkowego czasu na naukę nowego narzędzia, po trochu dlatego, że najwięcej kodu tworzę w PHP i JS w gVimie, który chyba nie posiada żadnego zintegrowanego narzędzia, ale głównie dlatego, że to często armata na komara. Niejednokrotnie wystarczy podejrzeć przecież zawartość jednej zmiennej aby rozwiązać problem. I tak prawdopodobnie każdy programista nauczył się "echowania" (kłania się zapewne PHP ;).

Problem pojawia się jednak kiedy zaczynamy tworzyć w Javascriptcie, który to nie posiada żadnego wyjścia, jakieś proste skrypciki. Pierwszym pomysłem jaki przychodzi do głowy jest wykorzystanie funkcji alert(). Często to dobre rozwiązanie, choć mało wygodne - wyskakujące okienko bywa naprawdę denerwujące. Szczególnie jak zaczyna pokazywać się coraz częściej i w większych ilościach. Dodatkowo, Firefox z którego korzystam, ma tę niezrozumiałą dla mnie własność, że kiedy wyskoczył jakiś alert nie dopuszcza mnie do okna przeglądarki. Co więcej - nie pozwala (a przynajmniej mi się nigdy nie udało) wyłączyć Javascriptu z poziomu tegoż okienka (co potrafi np. Opera). Kończy się więc to killem przeglądarki kiedy jakiś dowcipniś wrzuci alert("joke"); w niekończącą się pętle. A samemu podczas "echowania" też zdarzyło mi się zabić takim alertem, więc trzeba uważać :) (setInterval(), czy niefortunne powiązanie z jakimś zdarzeniem).

W związku z pytaniem, które ktoś rzucił dzisiaj na blipa zacząłem zastanawiać się czy nie ma lepszego rozwiązania. Pierwszy pomysł jaki mi przyszedł do głowy to napisanie prostej klasy Console, która będzie dodawała swoje okno na stronie i za pomocą jakiejś metody out(), push(), czy jakiejś pozwalała ładnie wypisywać zawartość danej zmiennej. Szybko jednak okazało się, że twórcy Firebuga wpadli na ten pomysł pierwsi :).

Konsola Firebuga, część właściwa wpisu

Konsola Firebuga udostępnia nam kilka ciekawych funkcjonalności. Pierwszą z nich jest console.log(), która pozwala formatować wyjście na kilka sposobów:

{geshi lang=javascript}console.log("Ten kod powinien się wykonać"); var foo = "bar", x = 12.34, i = 122; console.log("foo: %s, (int) i: %d, (float) x: %f", foo, i, x); function Kopytko() { this.palec1 = 11.12; this.palec2 = "qń"; }; kopyto = new Kopytko(); console.log(kopyto); console.log(kopyto.brak);{/geshi}

Jednak to nie wszystko. Możemy także pokolorować i nadać znaczenia naszej radosnej twórczości. I tak mamy dostępne metody console.debug(), console.info(), console.warn(), console.error().

Dodatkowo, przydatne (np. przy pracy z Ajaksem, czy manipulacjach w drzewie DOM) może się okazać również drukowanie HTMLa oraz XMLa. Służy do tego metoda console.dirxml(DOMElement). Wyświetla ona drzewo znane nam z zakładki "HTML" Firebuga.

To chyba na tyle o "echowaniu" na konsolę Firebuga. Więcej informacji możecie znaleźć w Console API oraz Rejestrowaniu Javascriptu (damn - nie mogę lepszego tłumaczenia znaleźć :). I tak z poziomu kodu można mierzyć czas wykonania bloku instrukcji console.time("name"); {..} console.timeEnd("name");, czy tworzyć asercje (a jak to się tłumaczy?).

Rys historyczny cz. 2, też można pominąć

Wpis ten napisałem głównie dla ludzi, którzy tak jak ja, jakimś cudem przeoczyli tę funkcjonalność Firebuga. Nie mylili się Zergu i mcv mówiąc, że o rzeczach oczywistych się nie pisze bo są... oczywiste. Jak jednak często się okazuje - nie dla każdego :). A właśnie taka demotywująca myśl spowodowała, że od tak dawna nic nie pisałem.

Wpis ten ukazał się w okrojonej (mniej osobistej) formie na moim blogu firmowym

Przenosiny cz. 2

Fri, 06 Mar 2009 14:42:45 +0100

Tych co nie czytali części poprzedniej zapraszam tu: Przenosiny cz. 1

Akt trzeci - czekanie

Tak więc od początku stycznia czekaliśmy na otwarcie Systemu, by móc złożyć podanie. Przypomnę, że za załatwianie sprawy z wiadomych względów zabraliśmy się na półtora miesiąca przed sesją. I... ku naszej niebywałej uciesze, jakoś tuż przed końcem semestru System uruchomiono. Czad po prostu.

Akt czwarty - podanie

Cóż - nie ma co marudzić, zabieramy się za wypełnianie podania. Wpisuję miasto, reszta moich danych jest. Wybieram kierunek na który chcę się przenieść. Do wyboru mam ciągi w stylu P0-W08-INF---ST-I-WRO------PWR1-DWU. Uroczo. Szukam pomocy, znajduję coś niestety i tak muszę zgadywać. Wybieram jak cytowałem, w końcu I musi oznaczać pierwszy rok. Teraz pora uzupełnić dorobek. Tutaj sprawa komplikuje się jeszcze bardziej. Mam przepisać wszystkie kursy (ponad 30)? Co to są te dziwaczne pola CNPS, ZZU? I które z 15 pól na kurs mam uzupełniać? Na te pytania jednak nie znajduję odpowiedzi, więc uzupełniam wszystko według uznania. I tak przepisanie indeksu zabiera mi ponad 2h.

Wypada mi jeszcze sparować kursy, jednak dla IZetu pojawiają mi się jakieś dziwactwa, których wiem, że nie mieli. Uznaję to za błąd systemu i umawiam się ze znajomym przy dziekanacie dnia następnego.

Akt piąty - podanie drugie

Jako że już blisko sesji, wystajemy godzinkę pod dziekanatem. Poraża nas jednak kultura ludzi. I tu pora na dygresję o kolejkach na Elektronice.

Otóż kolejka do dziekanatu na Elektronice wygląda jak kulka plasteliny ciśnięta o ścianę. Wynika to głównie z tego, że jakiś mózg wymyślił, że do dziekanatu, gdzie jest 8 stanowisk, są jedne drzwi i do tego nieprzezroczyste. Jako że stanowiska są przydzielone do studentów na stałe, niektórzy, udając że idą do stanowiska do którego nie ma kolejki, wchodzą do środka, pomijając ogromną kolejkę stojacą pod drzwiami, po czym stają w kolejce już do określonego stanowiska. W praktyce wygląda to tak, że 10 osób stoi pod drzwiami i nie może wejść (bo są wywalani), a w środku, do interesującego ich stanowiska jest cały czas tyle samo ludzi. Nie muszę wspominać, że ja oczywiście muszę swoje sprawy załatwiać przy stanowisku do którego zawsze jest najwięcej ludzi :).

Na IZecie jednak za drzwiami jest tylko jedno okienko, więc problem nie istnieje. I tak po godzinie grzecznie odstanej w kolejce wyjaśniamy naszą sprawę bardzo przemiłej pani siedzącej w środku. Ona wpisuje moje nazwisko po czym z uśmiechem na twarzy oznajmia, że wybrałem nie ten kierunek. Z listy powinienem wybrać taki z Ii, a nie samym I. Uh - prawie bym się przeniósł na nieistniejący kierunek. Cóż za ulga. Przy okazji dowiedzieliśmy się, że należy wpisać tylko wiodące kursy.

Myśląc że wiemy już wszystko spieszymy do jakiegoś wygodnego miejsca, aby usiąść i ponownie uzupełnić podanie. Wpisałem miasto, wybrałem dobry kierunek, zacząłem uzupełniać kursy, po czym chciałem je sparować. Uh... Znowu fail - nie wiem które z którymi połączyć (mniejsza z tym dlaczego). No to do dziekanatu.

Tym razem już bez kolejki wchodzimy do środka. Pani cieszy się niezmiernie że widzi nas ponownie jeszcze tego samego dnia. Patrzy na nasze podania u siebie w systemie, po czym stwierdza, że System nas pokonał i musi to zrobić za nas. No dobrze - klikamy opcję "przekaż" przy podaniu i zostawiamy to Pani.

Akt szósty - podanie trzecie

Po dwóch dniach patrzę na status swojej sprawy, który zmienia się z "złożona" na "odrzucona". Odrzucona przez dziekana, powód "nie uzup. sem. real.". Patrzę w system na swoje kursy... Nie ma pola od którego skrót mógłby tak wyglądać. Domyślam się jednak, że dziekan oczywiście widzi inne nazwy pól u siebie. Kolega po wizycie w dziekanacie potwierdza moje przypuszczenia i już wiemy co trzeba douzupełnić. No to jeszcze raz - 1h na uzupełnienie podania. Przy okazji wychodzi, że kiedy uzupełnia się te pole, system zapomina kilka innych (z losową jednak częstotliwością). Podanie złożone, wydrukowane, zaniesione, zatwierdzone. A nie - nie tak szybko, Panie Piotrze. Okazuje się, że pismo pt. "różnice programowe" które musieliśmy zanieść wczęsniej do dziekana nie ma podpisu, bo to co na nim widnieje, to jakieś gryzmoły. Uroczo - 2h w kolejce i mam podpis. No to teraz czekam.

Po trzech dniach sprawa zmienia status ze "złożona" na "do rozpatrzenia". Już się cieszę, że coś poszło o krok dalej niż ostatnio. Kawałek niżej jednak widnieje status "brak decyzji", a jeszcze w jednym miejscu "decyzja prawomocna: tak". Eee... no jasne. U kolegi to samo. Postanawiamy jeszcze poczekać.

Tutaj dygresja apropo zapisów na Elektronice, które wypadły właśnie w tym momencie. Jako że nie wiedziałem, czy całą sprawę uda mi się pozytywnie załatwić postanowiłem się zapisać na zajęcia, normalnie jakbym dalej studiował.

A po tygodniu postanawiamy zajrzeć do dziekanatu w sprawie naszych podań.

Akt siódmy - indeksik

Wystajemy znowu swoje w kolecje. W środku już o nas zapomniano, więc grzecznie tłumaczymy z czym przychodzimy. Pani zagląda do podania kolegi i okazuje się, że dobrze że przyszliśmy. Podczas przerabiania podania system wygenerował błąd i podanie zostało zapomniane. A skąd status "do rozpatrzenia"? Tego nie udaje nam się dowiedzieć. "Klik" i podanie kolegi tym razem przechodzi - super, witamy Pana na naszym wydziale. Teraz pora na moje podanie. "Klik" - u Pana jest błąd. Musi Pan mieć przepisane wszystkie oceny do indeksu elektronicznego. Że co? Kolega nie ma, a jemu przeszło, dlaczego? Trzy razy spytałem i dowiedziałem się tylko, że ja muszę. Pani niestety teraz nie była tak miła, bo dorwała administratora Systemu i mu nawymyślała.

Wychodzę zniesmaczony, bo do tej pory moim prowadzącym udało się do tegoż indeksu (części Systemu) przepisać aż 3 oceny. Na 20... Że niby mam ich teraz do tego zmusić? No nic - łudzę się, że może ktoś to odgórnie zrobić. Idę do swojego dziekanatu - półtorej godziny w kolejeczce i dowiaduję się, że nie, nie ma takiej osoby. Idę jeszcze do sekcji informatycznej, gdzie od znajomego słyszę to samo. SUPER! Przy okazji dowiaduję się, że prowadzący mieli już jeden termin na załatwienie sprawy, ale prawie nikt tego nie zrobił, więc przedłużono im go do 7mego marca. Ekstra - na IZecie mam czas na załatwienie wszystkiego do 10tego. I jakoś nie wierzę, żeby wszyscy tego 7mego dotrzymali. Jedna osoba mnie oleje, zniknie na tydzień i nici z przenosiń.

Co więcej - abym mógł spokojnie popracować, jedyną alternatywą dla przeniesienia się jest wzięcie dziekanki. Na to termin też mam do 10tego marca. Więc jedna rzecz się przedłuży, a będę musiał normalnie studiować. Uroczo. Półtora miesiąca zabawy i nic nie załatwię.

Tak na koniec dzisiejszej części jeszcze krótko o wypełnianiu podania o urlop dziekański. Oczywiście wszystko w Systemie. Do uzupełnienia początkowy semestr urlopu i końcowy semestr urlopu. Niby wszystko jasne, ale zaraz - jak biorę urlop na jeden semestr to co wpisuję w końcowym? Ten sam co początkowy, czy następny? Nie dowiem się niestety metodą prób i błędów, bo System zezwoli nawet na wzięcie dziekanki rok temu i co więcej - nawet na wzięcie dziekanki cofającej - gdzie start > koniec ;).

Akt ósmy - pewna informacja

Część trzecia już za czas z góry nieokreślony :)

Przenosiny

Fri, 06 Mar 2009 01:14:26 +0100

Żyję.

To zdanie ~~(albo raczej, jeśli dobrze pamiętam z liceum, jego równoważnik)~~ jest dla mnie zdaniem przełomowym, bo nie udało mi się opublikować żadnego wpisu od października 2006. Co oznacza skromną, ponaddwuletnią przerwę i moją pozorną śmierć (nawet w mych oczach). Ale nic to - o tym (tzn. o powodach) kiedy indziej (bo pisać mam zamiar więcej), a teraz na temat.

Prolog

Na wstępie wypada mi przedstawić sytuację w jakiej znajdowałem się na początku całego dramatu (ma prolog i akty, to prawie jak dramat ;P - tylko chóru brakuje ;)

W roku pańskim 2007 zacząłem studia na Wydziale Elektroniki Politechniki Wrocławskiej, kierunek Informatyka. W teorii wymarzone - informatyczne, próg najwyższy i... i to chyba wszystko czym się kierowałem. A szkoda.

W roku pańskim 2008, w miesiącu styczniu, później lutym, później lipcu - mówiąc wprost - od prawie samego początku pierwszego roku - narzekałem. Studia informatyczne okazały się być matematyczno-elektronicznymi i o ile to pierwsze nie dziwi na pierwszym roku, a drugie też nie dużo mniej, to miałem obawy czy nie będzie tak do końca. Jednak na obawach się skończyło i zostałem na Wydziale Elektroniki.

W grudniu roku 2008 zapadła jednak decyzja - chcę się przenieść. Do wyboru miałem jeszcze dwie informatyki na PWR. Jedną na IZecie, a drugą na PPTcie. Wybór padł na IZet.

Cały obszerny wstęp dopełnia informacja o tym, że z semetru 4tego planowałem się przenieść na semestr drugi. Cała zabawa po to, abym mógł trochę więcej poświęcić się pracy przez następny rok (większość kursów zostanie mi mam nadzieję przepisana).

Akt pierwszy - rozpoczynamy

Pierwszym krokiem było powiadomienie rodziców - ok - podołali :). Drugim - znajomych i tu niespodzianka - jeden z moich lepszych kumpli jeszcze z czasów gimnazjum też chce się przenieść (kierunek macierzysty: AiR na EKA). Informacja ta dodała mi otuchy, bo to zawsze łatwiej.

Krokiem następnym była wizyta u bardzo zachwalanego przez znajomych z IZetu dziekana do spraw dydaktycznych - dr. Janusza Martana. Pierwszy raz byliśmy u niego jakoś na początku stycznia i datę tę można uznać za początek procesu Przenosin. Proces rozpoczęliśmy tak wcześniej (sesja od połowy lutego), aby przed sesją wszystko załatwić - wiadomo - kilometrowe kolejki, itd. Dziekan rzeczywiście okazał się być bardzo miłym i konkretnym człowiekiem. Wszystko (a przynajmniej tak się nam zdawało) nam wytłumaczył. Plan miał wyglądać następująco:

Tworzymy i przynosimy "różnice programowe" - tabelkę kursów które nam się pokrywają,
Czekamy na otwarcieu elektronicznego, internetowego systemu EdukacjaCL,
Składamy podanie o przeniesienie,
Przynosimy wydrukowane podanie (sic! - jest przecież w systemie),
Dziekan akceptuje, bo czemu by nie,
Hurraa!! krzyczymy i idziemy się nawalić jak zwierzęta. Tfu... studenci.

Nic prostszego, prawda? :) Ja nie byłem tak optymistycznie nastawiony, a to dlatego...

Akt drugi - System

Od początku kiedy mówiłem znajomym o przenosinach, ci ostrzegali mnie przed Systemem. System ów zwany pieszczotliwie Edukacją jest (a w zasadzie miał być) elektronicznym dziekanatem, a także systemem rekrutacyjnym i czym tam jeszcze. Nas interesowało to pierwsze. Politechnika wdraża go z oporami od niepamiętnych czasów, a teraz - w przerwie zimowej (nigdy nie pojmę dlaczego zimowej, a nie 5x dłuższej letniej :O?!?!) postanowiła wprowadzić go metodą małych kroczków - kroczków kangura giganta. Od teraz - wszystko co chcecie załatwiać w dziekanacie drodzy studenci możecie załatwić w portalu... po czym musicie to do nas przynieść i tak. Aha - to nic że w systemie nie ma jeszcze tego podania - złożysz je za pół roku. Czasy załatwiania spraw oczywiście się skrócą, pół roku temu znajomy przeniósł się w dwa dni, a my na pewno załatwimy to szybciej.

Sam System tworzony jest przez notowaną na giełdzie spółkę Sygnity SA (gdzie pewnie pracuje setka mściwych, byłych studentów Politechniki ;)). System jest bardzo sprawny - prawie jak Windows - uważaj co robisz, bo każda źle podjęta decyzja oznacza nieodwracalne w skutkach błędy. I tak - nie cofaj się do poprzedniej strony, bo dostaniesz komunikat o błędzie. Uzupełnij każde wymagane pole w podaniu zgodnie z przeznaczeniem. Niestety to które pola są wymagane oraz to jakie jest ich przeznaczenie miej lub bardziej jasne jest... Ee... Nie wiem - tego nie wie nikt. Od pań w dziekanatach, po dziekanów oraz po dokumentację systemu, która nie istnieje (piszę to z premedytacją, bo poradnik dla samobójców który jest dostępny raczaj się nie przydaje).

Itd., itd... mógłbym marudzić dalej, ale ważne jest tylko to, że wiedziałem, że muszę wypełnić wszystko co wymagane, a jak o czymś zapomnę/pomylę się/nie będę wiedział, to dowiem się o tym jak będę całe podanie (2h pracy) uzupełniać ponownie, bo nie da się podania cofnąć i douzupełnić.

Akt trzeci - czekanie

Był początek stycznia kiedy zaczęliśmy czekać na otwarcie systemu... Część druga już jutro :)

Zapiski na Koszulce

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

WTFJS - rozjaśnienie umysłu

Jestem prawie obiektowy

Jestem prawie obiektowy, ale umiem porównywać

Używaj średników!

Niezrozumiałe dla mnie

Obiektowy JavaScript cz.2. - klasa sama w sobie

Konstruktor obiektu

Alternatywna metoda tworzenia konstruktorów obiektów

Anegdota o użyciu new z funkcją

Elementy programowania obiektowego

Właściwości prywatne

Właściwości statyczne

Dostęp z obiektu do konstruktora

Co dalej?

Dlaczego iPhone też już ssie?

Obiektowy JavaScript cz.1. - obiekt Twoim przyjacielem

JavaScript to dziwoląg

Obiekt

Właściwości obiektu

Uwaga na this

Jeszcze trochę o obiektach

Co dalej?

Dlaczego frameworki CSS ssą?

Cóż to takiego framework CSS?

Czemuż ssie?

Słówko o nieudanym porodzie

Koniec wtrącenia

Wybiła 15stka

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

Słów kilka o projektowaniu

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

Tort, znaczek Nike i płyta DVD

Nim mnie zjedziesz

Przegląd prasy

Usability vel użyteczność

Łebowe i niełebowe programowanie

Inne

Write LESS, do more - czyli pimp my CSS

CSS rady nie daje

Wysyp wspomagaczy

Instalacja

Ficzery

Praca z LESSem

Zen Coding - snippety nie mają szans

Moja strona

O tym jak wydłużyłem sobie dobę

Zmiana

Co dalej?

WUD Tour 2009 - Wrocław - relacja i przemyślenia

W skrócie co widziałem

Czy użytkownik jest złym projektantem?

Adobe AIR podstaw podstawy

AIR - was ist das?

Moja pierwsza aplikacja AIR oparta o HTML

Hello World

Testowanie aplikacji

Tworzenie pliku instalacyjnego .air

Instalacja

Zarządzanie zainstalowanymi aplikacjami na Linuksie

Koniec

Źródło i inne przydatne linki

Walidacja jednego pola formularza w symfony

Ideowo o HTMLu i CSSie

<address>

Inne moje nadinterpretacje

Interpretacja mcvała

Moja interpretacja

Na HTMLu nie koniec

Styl mcvała

Mój styl

"Echowanie" Javascriptu przy pomocy Firebuga

Rys historyczny, można pomijać

Konsola Firebuga, część właściwa wpisu

Rys historyczny cz. 2, też można pominąć

Przenosiny cz. 2

Akt trzeci - czekanie

Akt czwarty - podanie

Akt piąty - podanie drugie

Anegdota o użyciu `new` z funkcją

Uwaga na `this`

`<address>`