Wczoraj przyszło mi oddać i obronić projekt z przedmiotu programowanie WWW. Nie ukrywam, że podchodziłem do niego z pewną taką nieśmiałością — na szczęście prowadzący okazał się człowiekiem wyrozumiałym i moja kompletna ignorancja w tej dziedzinie nie przeszkodziła mi w uzyskaniu zaliczenia :).

Już po fakcie dowiedziałem się, że mój projekt i tak nie zostanie wdrożony, a zamiast niego będzie funkcjonować obecna wersja. Jedna z przyczyn: interfejs panelu administracyjnego.

Aplikacja bazuje na Fleksie, a panel administracyjny jest jego lekko przerobioną wariacją (jest po polsku, a jego wygląd bardziej komponuje się z, że tak to nazwę, brandingiem katedry). Najbardziej przykre w tym wszystkim było to, że faktycznie interfejs Fleksa nie był testowany na żadnej “pani Krysi z sekretariatu”. Mój wykładowca wytknął mu parę błędów, które można sprowadzić do jednego: przekombinowanie.

Obecny panel administracyjny tej strony nie wykorzystuje techniki inner browsing czy paneli, ale za to ma ikonki i znacznie lepiej niż Flex spełnia założenia reguły KISS:

Reguła KISS (ang. Keep It Simple, Stupid, czyli to ma być proste, głupcze) jest wspominana przy dyskusji architektury lub szczegółów budowy projektów. Jej istotą jest dążenie do utrzymania eleganckiej i przejrzystej struktury, bez dodawania nadmiarowych udogodnień.

Wikipedia

Jednym z głównych założeń, z myślą o których projektowałem Fleksa, była prostota. W praktyce okazuje się, że stworzenie aplikacji, która jest prosta w obsłudze (bo tego naprawdę oczekuje pani Krysia), a z drugiej strony pozwala na przyspieszenie i usprawnienie pracy (bo pani Krysia mówi, że tego oczekuje), jest trudne. Ale możliwe.

Z ciekawości przejrzałem wczoraj parę innych aplikacji bazujących na WWW. Mam wrażenie, że nie tylko ja mam ten problem — już widzę, jak nasza bohaterka walczy np. ze (skądinąd zacnym) CMS-em ezPublish.

Jaki więc powinien być interfejs CMS-a? Pewnie wrócę do tematu.

Przede wszystkim rzuca się w oczy “firefoksyzacja” norweskiej przeglądarki. Asa Dotzler narzekał nie tak dawno, że jej interfejs jest przeładowany i wymaga sporo roboty, aby mógł go bezstresowo używać Joe Average (w Polsce znany lepiej jako Jan Kowalski). Zmiany pojawiły się już w wersji 7.60, a obecnie główne menu przypomina to, co znamy z Firefoksa, tzn. jest proste, przejrzyste i nie przeraża.

Opera 8 beta

Trudno nie oprzeć się wrażeniu, że historia zrobiła małe koło: najpierw Mozilla “ukradła” Operze panele, a teraz interfejs tej ostatniej wyraźnie ewoluuje w kierunku Firefoksa. Cóż, moim zdaniem nie ma w tym nic złego, a nowe oblicze Opery podoba mi się znacznie bardziej niż kiedyś.

Wypada jeszcze wspomnieć, że Norwegowie lubią Polskę i wyrozumiale traktują nasz rynek.

Niestety, jak z kobietami, atrakcyjny interfejs potrafi ukrywać nieciekawe wnętrze. Proba zalogowania się do Fleksa zakończyła się uprzejmym komunikatem: “Wystąpił problem z aplikacją Opera Internet Browser i zostanie ona zamknięta”. Trudno dociec co i jak, ale mam przynajmniej powód do dumy, bo mój kod wysypuje przeglądarkę ze 100-procentową skutecznością. Żeby było ciekawiej, wersja 7.54 nie reaguje równie dramatycznie (Flex również w niej nie działa, ale z zupełnie innych przyczyn).

Ale do napisania tego tekstu skłoniło mnie co innego, tzn. brak obsługi znacznika <optgroup>. Formularz, który zawiera ten znacznik, NIE BĘDZIE działać, o czym przekonałem się przed chwilką, sprawdzając w nowej Operze swoją ostatnią produkcję. Z Googli można się dowiedzieć, że przeszkadzało to ludziom już ładnych parę lat temu, więc zastanawia mnie, jak długo jeszcze przyjdzie poczekać na dogonienie przez Norwegów standardu HTML 4.01.

Aktualizacja: quiris pomógł ustalić, że jednak nie miałem racji – Opera obsługuje znacznik <optgroup>, a błąd wynikał z mojej pomyłki w kodzie. Zwracam honor Norwegom.

(Krewkim fanom wyjaśniam od razu, że nie jestem wrogiem Opery. Zresztą pewnie i tak przerobię stronę, nad którą teraz siedzę. Po prostu trochę śmieszy i denerwuje taka rzecz w 2005 roku…)

Aktualizacja: no, to teraz operowcy mnie rozszarpią za tamten tekst :).

Sukces PHP jest także dowodem na skuteczność rozwiązań open source. Upublicznienie kodu źródłowego może okazać się doskonałym sposobem na przyspieszenie rozwoju aplikacji i wzrost jej funkcjonalności. Nie wyklucza to jednak działalności biznesowej i czerpania zysków ze wspierania otwartego oprogramowania, czego dowodem jest firma Zend. Systemy zarządzania treścią w języku PHP

Sformułowanie jest na na tyle ostrożnie, że mogę się pod nim podpisać nawet dziś. Pamiętam jednak, że wtedy byłem święcie przekonany, że na wolnym i otwartym oprogramowaniu można JAKOŚ zarobić. Nie bardzo wiedziałem JAK, ale przecież to niemożliwe, by setki tysięcy programistów rzucało się za darmo do pracy nad aplikacjami, o których być może nikt nie usłyszy…

Nieco wcześniej obejrzałem Revolution OS, film dokumentalny o fenomenie Linuksa i open source. Kilkadziesiat osób przez cały film przekonuje, że można na tym zarobić. Cóż, choć film obejrzałem dwukrotnie, jakoś nie bardzo te tłumaczenia zrozumiałem. Ale to pewnie wina mojej słabej znajomości angielskiego.

Ostatnio miałem okazję, by w końcu znaleźć odpowiedź — na zaliczenie miałem przygotować krótki referat na wybrany przez siebie temat z pogranicza prawa (dwuznaczność niezamierzona) i informatyki. Postanowiłem bliżej przyjrzeć się filozofii GNU i licencjonowaniu wolnego i otwartego oprogramowania. W pracy ograniczyłem się do suchego zestawienia głównych licencji Open Source, dywagacje zostawiłem sobie na deser.

Czytając prawie przez cały dzień zasady leżące u podstaw filozofii Stallmana, nie mogłem oprzeć się wrażeniu, że żyje on w innym świecie. Lepszym i piękniejszym. Takim, w którym ludzie nie chcą być bogaci, wystarcza im możliwość rozwoju własnych osobowości i wspaniałego software’u.

Czy jednak ktoś, kto chce pracować jako programista i utrzymywać się z tego, może pisać wyłącznie wolne programy? Oczywiście, są przykłady firm, które wspierają open source, a przy tym z powodzeniem prowadzą działalność biznesową, np. wspomniany Zend czy IBM. Jednak otwarte programy NIE są źródłem ich zysków. Zenda założyli dwaj główni programiści PHP, ale dziś firma zarabia na sprzedaży jak najbardziej komercyjnego i zamkniętego oprogramowania. PHP wygląda więc na metodę stworzenia nowego rynku, na którym można zarabiać w sposób tradycyjny, odległy od zasad GNU. Zresztą Stallman krytykuje model Zenda i podobne, gdyż uważa, że WSZYSTKIE programy powinny być wolne.

Ktoś powie, że można zarabiać na wsparciu technicznym do tworzonych przez siebie wolnych programów. Nie oszukujmy się, naprawdę trudno mi wyobrazić sobie praktyczne funkcjonowanie takiej firmy. Zresztą przypuszczam, że ilość zarabianych przez nią pieniędzy byłaby odwrotnie proporcjonalna do jakości dokumentacji, a ta ostatnia jest przecież jedną z podstaw powodzenia programu. Poza tym całą brudną robotę wykonywaliby programiści, ale to nie oni generowaliby przychody, tylko konsultanci przy telefonach.

Jestem fanem open source. Uważam, że to najskuteczniejsza metoda tworzenia dobrych programów. Trudno mi się tylko pogodzić z tym, że programista, inaczej niż administrator, konsultant czy sprzątaczka, nie ma prawa do utrzymywania się dzięki swojej pracy.

Szukając odpowiedzi na swoje wątpliwości, zadałem nawet fundamentalne pytanie Wyroczni. Podsunęła mi ciekawy artykuł. Myślę, że jest to najlepsze podsumowanie tego tematu.

Plik RSS jest generowany dynamicznie przy pomocy PHP i Smarty. Coraz bardziej podoba mi się ten wynalazek – stworzenie odpowiedniego szablonu, który wyświetli dane otrzymane ze skryptów PHP, jest łatwe i szybkie. A przede wszystkim: eleganckie. Skrypty zajmują się tylko odczytaniem danych z bazy i nie są “zaśmiecane” kodem XHTML.

Skoro jestem przy elegancji, to jeszcze wspomnę o przyczynie, dla której stworzenie kanału RSS zajęło mi ponad godzinę, a nie 15 minut. RSS jest odmianą XML i savoir-vivre wymaga, aby był wysyłany z typem mime application/xml. W przeglądarkach, które reagują na typy mime (a więc nie dotyczy to IE), dokument taki zostanie wyświetlony w postaci drzewa XML, a nie zwykłego tekstu. Można się o tym przekonać, klikając na link do kanału np. w Firefoksie czy Mozilli. Przy pierwszym podejściu przeglądarka wyświetliła mi błąd parsowania:

Błąd parsowania XML w Firefoksie

Okazało się, że jeden z moich skryptów PHP drukuje na ekranie spację, która pojawia się przed prologiem XML. Dobrze uformowany dokument XML nie ma prawa zawierać w tym miejscu niczego, więc trzeba było namierzyć błąd w skrypcie. Najpierw podjąłem się przeglądania źródeł wszystkich skryptów, które są używane na stronie – ponieważ korzystam ze Smarty i paru pomocniczych klas, wysiłek byłby naprawdę heroiczny. Tudzież bez sensu: wystarczy wyłączyć buforowanie wyjścia w php.ini, wywołać w którymś miejscu funkcję header() i PHP samo pokaże, gdzie jest błąd polegający na przedwczesnym wysyłaniu tekstu do przeglądarki. I tak właśnie zrobiłem i szybko znalazłem usterkę, ale cała sytuacja daje trochę do myślenia.

Przecież do przeglądarki można wysyłać jako XML nie tylko RSS, ale także XHTML. Jeśli ktoś korzysta z wersji 1.1 XHTML, jest to nawet konieczne. Zalety: satysfakcja z czystego kodu (niewątpliwie jest to zboczenie, na które jednak cierpi wielu programistów, i którego pierwsze symptomy zauważam u siebie) oraz szybkie wykrywanie błędów w kodzie. Jeśli takowy się pojawi, użytkownik zobaczy na ekranie, o ile oczywiście używa porządnej przeglądarki, komunikat o błędzie parsowania, zamiast strony. Webmaster dość szybko dowie się więc od swoich gości, że popełnił błąd, może go zatem poprawić i dalej napawać się własnym perfekcjonizmem. Takie rozwiązanie stosuje np. Simon Willson na swoim blogu (swoją drogą, polecam). Nie ma chyba potrzeby tłumaczyć, że jeśli strona ma charakter komercyjny, lepiej nie eksperymentować w ten sposób, bo mogłoby się to pewnie okazać szybką i skuteczną drogą do bankructwa.

Inne wady (hmm… czyżby zalety gdzieś umknęły?): IE i tak nie przełknie takiego dania, należy więc dla niego zrobić wyjątek i wysłać stronę z typem text/html, zamiast application/xhtml+xml.

Już wspomniałem, że każde odstępstwo od specyfikacji XML zostanie niemiłosiernie wytknięte przez parsery wbudowane w nowoczesne przeglądarki. Takim odstępstwem jest spacja na początku strony (patrz wyżej) czy używanie w kodzie znaku & zamiast odpowiedniej encji. Dochodzą do tego kolejne, bardziej subtelne detale. Np. nie wolno wówczas stosować znacznika <meta> z atrybutem http-equiv. Można więc zapomnieć o prostym, powszechnie akceptowanym sposobie deklaracji kodowania:

<meta http-equiv="content-type
  content="text/html; charset=iso-8859-2" />

Zamiast tego, należy zadeklarować kodowanie w prologu XML:

<?xml version="1.0" encoding="iso-8859-2"?>

Tak na marginesie, po napotkaniu go na początku strony IE zaczyna się zachowywać mało przewidywalnie, więc należy mu zapewnić alternatywę w postaci <meta />.

Sporo tych niuansów. Ale to jeszcze nie koniec. Kiedy już wyślemy do odpowiedniej przeglądarki dokument XHTML z odpowiednim typem mime, może ona wyświetlić coś takiego:

Drzewo XML dokumentu XHTML

Nie jest to do końca to, czego chciałem.

The XML stylesheet PI SHOULD be used to associate style sheets. XHTML Media Types

Innymi słowy, należy zaimportować pliki CSS zaraz po prologu XML, w sposób zrozumiały dla parserów XML:

<?xml-stylesheet href="style.css" type="text/css"?>

Podsumujmy. Żeby strona była naprawdę koszerna i zgodna z XHTML 1.1, a przy tym nie rozlatywała się na ekranach 95% użytkowników należy:

• wysłać plik z typem mime application/xhtml+xml, pamiętając by IE serwować text/html
• umieścić na początku prolog XML i zadeklarować w nim kodowanie; użytkownikom IE (i tylko im) zapewnić alternatywę w postaci <meta />
• arkusze stylów zaimportować za pomocą instrukcji przetwarzania XML; nie wspomniałem o tym, że IE jej nie zrozumie, ale chyba każdy zdążył się już tego domyśleć?
• unikać jak ognia wszelkich błędów i odstępstw od specyfikacji, ponieważ natychmiast uniemożliwią one wyświetlenie strony w przeglądarkach poprawnie interpretujących XHTML.

I to już wszystko! Wnioski pozostawiam Wam.

Przydałoby się teraz zrobić małe samobiczowanie i wypunktować zasady z tej listy, które są złamane na szafranek.net. Biorąc pod uwagę moje masochistyczne skłonności, taki spis pewnie powstanie.