Odchudzanie lisa

Jak można przeczytać tu i ówdzie (a potem sprawdzić u źródła), premiera czwartej wersji przeglądarki Firefox przesunie się z końca tego roku na początek przyszłego. Zwolennicy tzw. bardziej nowoczesnych przeglądarek zapewne skorzystają z okazji, by używać tego faktu jako argumentu na rzecz tezy, że Ognisty Lis pozostaje w tyle pod względem szybkości, zgodności z sieciowymi standardami oraz estetyki i komfortu interfejsu.
Nawet jako jego użytkownik muszę przyznać, że przynajmniej ostatni z tych zarzutów faktycznie może być zasadny – ale tylko pod jednym zastrzeżeniem, które w przypadku Firefoksa jest po prostu nie fair. O ile bowiem FF3.6 out-of-the-box jest faktycznie dość siermiężny, o tyle nadrabia to z nawiązką możliwościami konfiguracji, których nie można w uczciwym zestawieniu pominąć.

Standardowy interfejs Firefoksa

Żeby jednak nie być gołosłownym pozwolę sobie pokazać, jak w kilku krokach możemy ów niezbyt imponujący, standardowy interfejs przekształcić w coś bardziej ‘nowoczesnego’. Mój opis można będzie potem potraktować jako swego rodzaju konstruktywną ripostę w świętych wojnach przeglądarkowych :)

Partycja na plik wymiany

Instalując ostatnio Linuksa zauważyłem, iż standardową praktyką tego systemu jest wydzielanie zupełnie osobnej partycji na plik stronnicowania (pagefile), zwany też potocznie plikiem wymiany. Mówiąc zresztą ściślej, Linux nie tworzy tam żadnych plików i zamiast tego korzysta z partycji bezpośrednio jako źródła miejsca dla pamięci wirtualnej.

Skąd taki pomysł, skoro Windows domyślnie radzi sobie całkiem dobrze, trzymając swoje dane stronnicowania w zwykłym pliku?… No cóż, to jest jedna z tych rzeczy, które Linux akurat robi lepiej. Umieszczenie pliku wymiany na innej partycji niż systemowa ma bowiem uzasadnienie wydajnościowe. W najlepszym wypadku ona sama powinna zresztą znajdować się na zupełnie osobnym dysku, dzięki czemu możliwe byłoby równolegle korzystanie z pliku wymiany i “normalnych” danych. Oczywiście nie zawsze jest to możliwe, zwłaszcza w komputerach przenośnych, siłą rzeczy dysponujących tylko jednym fizycznym dyskiem.

Co dokładnie daje umieszczenie pliku wymiany na jego własnej partycji? Myślę, że nietrudno się tego domyślić: chodzi o brak fragmentacji. Ponieważ brak jest kontaktu z jednostkami alokacji innych rodzajów danych, możliwe jest zachowanie integralności pliku wymiany, który w dodatku położony będzie zawsze blisko początku swojej partycji. To zaś przyspiesza do niego dostęp.
Znaczenie ma również położenie samej partycji na dysku. W idealnym przypadku powinna być ona na samym początku dysku, ale niestety jest to właściwie nie do osiągnięcia, jako że tam zwykle znajduje się już system operacyjny. Jeżeli nie chcemy go reinstalować, to dobrym rozwiązaniem jest umieszczenie partycji swap pośrodku dysku, między częścią systemową a partycją z danymi. Minimalizujemy wtedy drogę głowicy do pliku wymiany, jeśli już znajduje się ona nad którąś ze wspomnianych dwóch części. Wadą tego rozwiązania jest kłopotliwe powiększanie którejś z nich, jeśli kiedyś okaże się, że potrzebujemy więcej miejsca na system kosztem danych lub odwrotnie. Nie ma bowiem wtedy innej opcji jak usunięcie partycji wymiany i stworzenie jej na nowo.

Papier 2.0

Od kilku miesięcy popularność na świecie (w znacznie mniejszym stopniu w Polsce) zdobywają tzw. tablety, czyli komputery przenośne bez klawiatury, a jedynie z ekranem dotykowym. (Ich najbardziej znanym przykładem jest oczywiście iPad). Jako jedno z ich (niezbyt licznych) zastosowań podaje się możliwość wygodnego przeglądania stron internetowych, czytania kolorowych magazynów w wersji elektronicznej oraz e-booków, czyli książek. Co do pierwszych dwóch, mógłbym się ewentualnie zgodzić. Ale co do ostatniego – absolutnie nie, co nie powinno w sumie zaskakiwać. Długotrwałe męczenie oczu podążaniem za jednorodnym tekstem książki na dużym, świecącym i połyskliwym ekranie – połączone z trzymaniem w rękach urządzenia o nietrywialnym przecież ciężarze – trudno bowiem kojarzyć z jakimkolwiek komfortem.

Do czytania potrzeba więc urządzenia zarówno mniejszego, jak i bardziej do tego przystosowanego – choćby pod względem rodzaju wyświetlacza, bardziej imitującego rzeczywisty papier. Odpowiednie technologie istnieją już od ładnych kilku lat i zostały zastosowane w kilku produktach – z różnym skutkiem. Świeżym przykładem jest Kindle 3, którego to ostatnio sobie sprawiłem i w związku z tym pozwolę sobie podzielić się wrażeniami z jego użytkowania :)
Ale najpierw odpowiem na nasuwające się zapewne pytanie: a po co komuś coś takiego? Posiadanie przenośnego czytnika dokumentów tekstowych (w tym e-booków) okazuje się jednak bardzo przydatne, jeśli czytamy ich dużo lub jeśli często zdarza nam się przymusowe oczekiwanie w warunkach niepozwalających na wyciągnięcie “cięższego sprzętu” elektronicznego (przykładem takich sytuacji są chociażby przejazdy komunikacją miejską). Mogę z pełnym przekonaniem stwierdzić, że możliwość lektury e-booka, dokumentacji, zachowanych wcześniej notek z blogów czy artykułów z sieci w komfortowej, niemęczącej oczu i rąk formie jest doprawdy bardzo wygodna.

Wśród urządzeń, które na to pozwalają, Kindle prezentuje się przy tym bardzo pozytywnie. Wrażenia wzrokowe po dłuższej lekturze są mniej więcej takie, jak po czytaniu kolorowego albumu drukowanego na śliskim papierze. Nie jest to jeszcze matowość kart książki znalezionej u dziadka na strychu, ale fakt ten w niczym nie przeszkadza :) Sam zastosowany tu e-papier posiada doskonały kontrast i ostrość obrazu, a jedyne obserwowalne odblaski (niezbyt duże) pochodzą jedynie z jego plastikowej osłonki. Ogólnie z urządzenia można korzystać tak, jak z tradycyjnej książki.
Lista formatów dokumentów, które Kindle obsługuje bezpośrednio lub pośrednio, jest ponadto całkiem długa. Są na niej zarówno pozycje specyficzne dla czytników (np. MOBI), jak i bardziej znane PDF czy HTML (ten pierwszy odczytywany jest z marszu). Wreszcie jest tu także łączność WiFi (opcjonalnie też 3G) i przeglądarka stron WWW oparta na silniku WebKit (tym od Safari lub Chrome) o zaskakująco dużych możliwościach. Dzięki niej – oraz za pomocą usługi Read It Later i autorskiego skryptu w PHP – udało mi się na przykład znaleźć eleganckie rozwiązanie pewnego use case‘a, który pojawia się niemal natychmiast po rozpoczęciu korzystania z czytnika. Chodzi mianowicie o szybkie zachowanie artykułu znalezionego w sieci (na zwykłym komputerze) do późniejszego przeczytania z użyciem Kindle. Oferowany w tamtejszej przeglądarce tryb Article Mode potrafi bowiem niezwykle skutecznie pozbyć się ze strony wszystkiego, co nie jest głównym tekstem, a samą treść sformatować w sposób eliminujący konieczność przewijania w poziomie.

Obecność w pełni funkcjonalnej przeglądarki przestaje być zaskakująca, gdy weźmiemy pod uwagę to, że Kindle – podobnie jak większość urządzeń elektronicznych bardziej złożonych od mikrofalówki – działa pod kontrolą odpowiednio zmodyfikowanego Linuksa. A to od razu rodzi pytanie co do ewentualnego… tworzenia aplikacji na tą platformę :)
Odpowiedź jest tu także dość typowa i brzmi: albo zhakuj urządzenia i zdobądź prawa roota (z wiadomym skutkiem dla gwarancji), albo użyj autoryzowanego SDK. Ta druga opcja na razie jest dostępna niestety tylko dla wybranych, gdyż SDK (zwane KDK) jest obecnie w fazie na wpół zamkniętej bety. Miejmy nadzieję, że prędko zostanie ono wydane publicznie – albo że przynajmniej moje zgłoszenie chęci udziału w testach zostanie rozpatrzone pozytywnie ;P

Rozproszone systemy kontroli wersji

Z systemami kontroli wersji (w skrócie VCS) zetknął się każdy programista i dla niemal wszystkich jest to oczywiste narzędzie pracy. Dla wielu jednak wciąż jeszcze kojarzą się one z jednym, centralnym miejscem zawierającym zawierającym bazę kodu projektu (czyli repozytorium) oraz z licznymi kopiami roboczymi, nad którymi pracują programiści. Kiedy zaś chcą połączyć swoje zmiany, wówczas wykonują tylko operację znaną jako commit.

Tak jest w systemach typu CVS czy Subversion, ale obecnie sporą popularność zyskały też inne, działające na nieco innej zasadzie. Nazywają się one rozproszonymi (distributed version control system – DVCS) i zgodnie z tym określeniem ich główną cechą jest brak wydzielonego, centralnego repozytorium. Zamiast tego może być ich dowolna ilość, która w rzeczywistych projektach może łatwo urosnąć do setek, a nawet tysięcy. Najczęściej bowiem swoje własne repozytorium ma na przykład… każdy pracujący nad projektem programista.
Obłęd? Niezupełnie. Wszystko opiera się bowiem na operacji synchronizacji dwóch repozytoriów, którą nazywa się – w zależności od punktu widzenia – push lub pull. Push oznacza wprowadzenie poprawek z naszego repozytorium do innego, zaś pull oznacza ściągnięcie zmian z innego repozytorium do własnego. Jak nietrudno zauważyć, operacja ta jest symetryczna. I chociaż techniczne wszystkie repozytoria są równoważne, w praktyce jedno z nich jest zwykle bazą projektu, zawierającą jego “autorytatywną” wersję. Ponadto z każdym repozytorium można też pracować “normalnie”, tj. przy pomocy znanych i lubianych operacji commit i update.

Działanie rozproszonych systemów kontroli wersji

Po co taka zmiana? Przydaje się ona zwłaszcza w dwóch sytuacjach:

• Dla projektów typu open source umożliwia względnie niezależne opracowywanie poprawek do projektów. W tym celu wystarczy sklonować główne repozytorium, a następnie w spokoju pracować nad uzyskanym kodem, korzystając z jego kopii. Chcąc następie uczynić zmiany obowiązującymi, możemy wykonać push – ale tylko wtedy, jeśli mamy do tego prawa. Jeśli nie, możliwe jest stworzenie łatki (patch), zawierającej nasze modyfikacje i przekazania jej osobie zarządzającej projektem. Ta zaś może – zapewne po przetestowaniu zmian na własnej kopii repozytorium – wprowadzić je wreszcie do bazy kodu. Podobny akceptowania poprawek występował w projektach open source już od dawna, ale dopiero rozproszone systemy kontroli wsparły go od strony technicznej.
• Jeśli pracujemy wyłącznie lokalnie nad własnymi projektami, możemy stworzyć sobie takież repozytorium, które będzie przy tym jedynym. Nie synchronizujemy wtedy zmian z żadnym innym repozytorium, ale wciąż możemy korzystać ze standardowych funkcjonalności systemów kontroli wersji.

W średniej skali (takiej, jak przedstawiona na obrazku powyżej) systemy rozproszone sprawdzają się natomiast nieco gorzej – zwłaszcza, gdy częstotliwość zmian jest duża. Wówczas często zachodzi potrzeba łączenia (merge) różnych ścieżek tworzenia aplikacji.

Tym niemniej warto się zainteresować tego rodzaju systemami kontroli wersji, by przekonać się, że poza Subversion też coś istnieje :) Przykładami rozproszonych VCS-ów są np. Mercurcial i Git.

Windows co zna 64 bity

Ze sporym opóźnieniem i nie bez kłopotów zrobiłem wreszcie, co planowałem uczynić od dawna: pozbyć się Visty z komputera stacjonarnego i zamiast tego sprokurować tam sobie Windows 7. A że przy okazji mogłem ów nowy system zainstalować w wersji 64-bitowej, postanowiłem tak właśnie uczynić. Jakie są rezultaty tego eksperymentu?… Niestety dość kiepskie.

Nie znaczy to na szczęście, że 64-bitowy system na 64-bitowym procesorze jest nieużywalny – no nie, tak źle to nie jest :) Wydaje mi się, że istnieje tylko niewielka szansa, że podwojenie liczby systemowych bitów zaowocuje problemami z uruchomieniem jakieś aplikacji, która wcześniej działała dobrze. Jak wiadomo jest tu emulacja trybu 32-bitowego, która sprawdza się bardzo dobrze.
Skąd to wiem? Ano stąd, że okazji do jej wykorzystania jest mnóstwo – i w zasadzie to właśnie jest problem. Wersji aplikacji dedykowanych do x64 nie jest znowu tak dużo, a jeśli już da się takie znaleźć, to często są one pod znacznie gorszą opieką developerską i można mieć uzasadnione wątpliwości co do ich stabilności. Przykładem jest chociażby Firefox, którego 64-bitowa wersja jest tylko na wpół oficjalna i dostępna jedynie w angielskiej wersji językowej. W sumie więc mój Menedżer zadań pokazuje zdecydowaną większość procesów z dopiskiem * 32, zaś pozostałe to albo usługi systemowe, albo aplikacje zarządzane .NET lub Javy.

O ile jednak cudów po aplikacjach nie ma sensu się spodziewać (zwłaszcza tych przeznaczonych dla użytkowników domowych), o tyle 64-bitowe sterowniki do urządzeń byłyby bardzo wskazane. I tu może spotkać nas niemiła niespodzianka, gdyż ich także często brakuje. W moim przypadku z zadania wywiązała się jedynie NVidia, dostarczając sterowniki w wersji x64 zarówno do karty graficznej, jak i chipsetu płyty głównej. Ale już np. Microsoft nie uważał za stosowne zapewnienia drivera dla firmowanej przez siebie myszki Sidewinder X5, wykręcając się kompatybilnością jego 32-bitowej wersji, opracowanej z myślą o Viście.
To zresztą typowy scenariusz i można się tylko cieszyć, że te vistowe sterowniki działają bez problemów. Nie można tego natomiast powiedzieć o ewentualnym oprogramowaniu dodatkowym, dołączanym do różnych sprzętów. Jego zainstalowanie wymaga co najmniej kombinowania z trybem zgodności. oszukującym je co do rzeczywistej wersji systemu. W niektórych przypadkach (jak chociażby wspomnianego gryzonia) i to nie jest wystarczające, gdyż system blokuje instalację aplikacji, tłumacząc się – cytuję – “znanymi problemami ze zgodnością” ;P

Konkluzja jest więc taka, że 64 bity to wciąż żadne udogodnienie, a jedynie konieczność powodowana oczywiście chęcią wykorzystania większej ilości RAM-u niż ok. 3GB obsługiwane przez systemy 32-bitowe. Doświadczenie korzystania z systemu x64 przypomina używanie aplikacji w wersji Release Candidate: żadnych błędów nie znajdziemy i rzecz zasadniczo będzie działać, ale widoczne będą jakieś zgrzyty, o których wiadomo już, że zostaną naprawione dopiero patchami do wersji finalnej – jeżeli w ogóle. Wydaję mi się, że dopóki 4GB RAM-u nie będą standardem dla komputerów w cenowej strefie średnio-niskiej, wsparcie dla x64 ze strony producentów oprogramowania może być w dużym stopniu dobrowolne.
A kiedy coś takiego może stać?… Cóż, prawdopodobnie dopiero wraz z kolejną wersją Windows.

Sztuczki z adresem e-mail

Chcę dzisiaj wspomnieć o kilku ciekawostkach dotyczących tego, co każdy posiada – czyli adresu e-mail. Wydawałoby się, że nie ma tutaj niczego do odkrycia, jako że wszyscy już dawno zdążyliśmy się już przyzwyczaić do poczty elektronicznej i formatu adresów, które ona używa. Jak to jednak okazuje się zwykle w takich sytuacjach, w rzeczywistości przynajmniej kilka trików nie musi być wcale powszechnie znanych :)

I tak pierwszym z nich jest fakt, że część adresu specyficzna dla użytkownika (ta przed znakiem @) może być łańcuchem znaków zawartych w cudzysłowach. Między nimi ulegają wtedy pewnemu poluzowaniu reguł odnośnie dopuszczalnych znaków i dozwolone stają się chociażby spacje. Reasumując, zupełnie poprawny jest adres w rodzaju:

Jest tu jednak pewien haczyk. Otóż serwery pocztowe niekoniecznie muszą takie adresy akceptować. Samo RFC (nr 5321) przestrzega przed potencjalnymi problemami, zalecając nieużywanie cudzysłowów, jeśli… chcemy otrzymywać jakąś pocztę :)
Do czego więc mogą się one przydać? Chociażby do adresów, które wykorzystuje się wyłącznie jako nadawcze, wysyłając np. zautomatyzowane wiadomości do użytkowników jakiejś sieciowej usługi, na które ci nie powinni odpowiadać.

Drugą rzeczą wartą odnotowania jest to, że część adresu następująca po znaku @ niekoniecznie musi być nazwą domeny. Dopuszczalne są mianowicie adresy IP w zwyczajowej postaci kropkowej. Aby je odróżnić przyjęto konwencję, że powinny być zawarte w nawiasach kwadratowych:

Pozwala to chociażby – jak sugeruje powyższy przykład – na testowanie serwerów pocztowych bez konieczności posiadania domeny.

Wreszcie, trzeci trik różni się od dwóch pozostałych tym, że może być rzeczywiście przydatny w prawdziwym świecie ;D Chodzi mianowicie o to, że część adresu przed znakiem @ (specyficzna dla użytkownika) może być interpretowana przez jego serwer pocztowy w dowolny sposób. To sprawia, że ów serwer może udostępniać dodatkowe feature‘y z nią związane.
Typowym i częstym przykładem jest możliwość tworzenia tagów adresowych, wspomagających sortowanie wiadomości. Zwykle dzieje się to za pomocą plusa (+) lub myślnika (-), co w sumie skutkuje adresem w rodzaju:

Jeśli server.com obsługuje tagi w takim właśnie formacie, to wiadomości trafiające na powyższy adres zostaną umieszczone w skrzynce użytkownika user, ale pod etykietą stuff. Co to dokładnie znaczy, zależy od serwera; najpewniej będzie to przydzielenie wiadomości do osobnego folderu lub dodatkowe kryterium pomocne przy wyszukiwaniu.
Z popularnych serwisów hostujących pocztę tagi oferuje Google Mail, właśnie w powyższym formacie z plusem.

Przekierowania do innych URL-i

Potrzeba automatycznego przekierowania strony WWW do innego adresu URL pojawia się całkiem często. Dość typowe są na przykład serwisy typu download, gdzie faktyczne ściągnięcie pliku poprzedzone jest krótkim oczekiwaniem i odpowiednim komunikatem. Służy to głównie temu, by użytkownik omyłkowo nie rozpoczął procesu ściągania więcej niż raz.

Przyjrzyjmy się dzisiaj sposobom na dokonywanie takich przekierowań. Jeśli bowiem chwilę się nad tym zastanowić, to okazuje się, że można je przeprowadzać na różnych poziomach protokołów HTTP i nie tylko. Wśród możliwych metod można wyróżnić choćby takie:

• Javascript i window.location. Ustawienie tej właściwości na adres URL powoduje automatyczne wykonanie przekierowania. Do działania wymaga to naturalnie obsługi Javascriptu po stronie klienta, więc może służyć do odfiltrowania tych klientów, którzy nie spełniają tego warunku. Dotyczy to na przykład przeglądarek tekstowych, takich jak Lynx.
• Znacznik <meta>. HTML przewiduje możliwość odświeżenia strony po określonym czasie, z opcjonalnym przekierowaniem do innego URL-a. Korzysta się w tym celu ze znacznika &lt;meta>:
  1. <meta http-equiv="Refresh" content="10; http://other.url.com">

  Właśnie ta metoda jest zwykle wykorzystywana do implementacji wspomnianego na początku opóźnionego ściągania plików.

• Kody 3xx odpowiedzi HTTP. Protokół HTTP przewiduje możliwość zwrócenia przez serwer kodu odpowiedzi, powodującego (przynajmniej w założeniu) przekierowanie do innego adresu (przekazanego w nagłówku Location). Istnieje cała grupa takich kodów o numerach zaczynających się od 300, jak na przykład 301 (Moved Permanently), będący trwałym przekierowaniem, czy 302/307 (Found/Temporary Redirect), wskazujące na mniej lub bardziej tymczasowe odesłanie do innego adresu.
• Rekordy CNAME w DNS. Jeszcze niżej w warstwie sieciowej położone są “przekierowania” z użyciem systemu DNS (Domain Name System) i rekordów CNAME (lub DNAME), które to można ustawiać dla swoich domen. Gdy są obecne i wykorzystywane przez serwer DNS, wówczas klient pytający o adres IP związany z domeną (np. www.a.com) będzie poinstruowany, by użył innej nazwy (np. foo.b.net) i ponowił zapytanie. Takie “przekierowanie” nie będzie raczej widoczne dla użytkownika w wysokopoziomowych programach takich jak przeglądarki WWW, a co najwyżej w narzędziach sieciowych typu ping.

Jeśli przypadkiem zastanawiamy się, który rodzaj przekierowania powinniśmy zastosować, to spieszę z odpowiedzią, że prawie na pewno dobrym wyborem będzie któryś z dwóch środkowych elementów listy. Uzasadnieniem jest tu głównie chęć współpracy z robotami wyszukiwarek internetowych. Nie powinniśmy mianowicie spodziewać się, by uruchamiały one kod Javascript na przeglądanych przez siebie stronach, bo kosztowałoby to je zbyt dużo zasobów. Z drugiej strony istnieje też duża szansa, że nie będą one “świadome” “przekierowań” dokonywanych na poziomie systemu DNS, przez co mogą one potraktować dostępność tych samych treści z dwóch różnych adresów jako świadome duplikowanie contentu i próbę ich oszukania.

W grę wchodzą naturalnie jeszcze kwestie praktyczne. Nie każdy dysponuje własną domeną lub możliwością zmiany jej rekordów DNS. Nie każdy może też zmieniać ustawienia serwera HTTP, na którym funkcjonuje jego serwis. Wtedy przydatne są przekierowania dokonywane po stronie klienta np. za pomocą tagów HTML.