Tak jakoś wyszło (mniejsza o przyczyny), że w trwającej już kilka dni wielkiej debacie o rozwoju Joggera nie zabrałem dotąd głosu – ale może to i lepiej, bo po paru kolejnych odcinkach można już zrobić małe podsumowanie.

Przede wszystkim, spora część dyskutantów wykazała się zboczeniem zawodowym programistów, czyli myśleniem przede wszystkim o kodzie. Co tam społeczność, co tam funkcjonalności – najważniejsze, żeby było open source. OK, może i fajnie by było, ale to tak naprawdę trzeciorzędna kwestia. Nieważne, czy kod będzie otwarty czy zamknięty – ważniejsze, jakie będą efekty jego działania i jak będzie wyglądał jego rozwój. Ale i to jest kwestią drugorzędną. Najważniejszy jest – jak zawsze – efekt końcowy, czyli rozwój społeczności. A to ma już naprawdę niewiele wspólnego z samym kodem.

Żeby nie być gołosłownym – w obecnej pracy zajmuję się rozwijaniem serwisu, który ma 100k UU dziennie, a niektóre partie kodu to po prostu burdel na kółkach: niekończące się elseify, masa zmiennych globalnych, skamieniałości z czasów pehapa łupanego, dziki gąszcz powiązań między dziesiątkami plików i generalnie pokaz, jak nie należy programować. Jakim cudem to wszystko się nie wywala dziesięć razy dziennie, nie jestem w stanie pojąć. Ale użytkownicy tego nie widzą, więc dla nich problem nie istnieje, a serwis się trzyma – może na słowo honoru, ale jednak.

Wracając do Joggera – nie wiem oczywiście, jak wygląda jego kod (D4rky twierdzi, że tragicznie, ale to pojęcie względne), na pewno jednak nie tam tkwi przyczyna spadku popularności platformy. Owszem, źle napisany kod trudniej się rozwija, ale da się z tym żyć, przynajmniej do pewnego momentu. Rzecz w tym, żeby w ogóle ktoś się tym regularnie zajmował, bo nie ma (no, prawie nie ma) takich problemów, których przy odrobinie wysiłku nie dałoby się obejść.

Każde dziecko, które miało do czynienia z programowaniem, dobrze wie, że komentarze w kodzie pełnią dwie funkcje: po pierwsze, oczywiście komentowanie kodu (co za niespodzianka, nie?), po drugie – „wyłączanie” kawałków kodu, których nie chcemy wykonywać, ale nie chcemy ich także kasować. Banał. Jest jednak pewna nie do końca banalna kwestia – zdarza się, że podczas pisania i testowania kodu na przemian „włączamy” i „wyłączamy” jakiś fragment, sprawdzając jego działanie oraz działanie kodu bez niego. Żaden problem, jeśli fragment jest krótki i można go zakomentować/odkomentować w dwie sekundy – ale jeśli zajmuje on, powiedzmy, kilka ekranów, a nasz edytor nie ma automatycznego usuwania znaków końca komentarza po usunięciu początku, to ciągłe latanie kursorem w te i wewte może być dość męczące. Co więcej, jeśli odkomentujemy kod, a potem coś dopiszemy i zechcemy go znowu zakomentować, to nierzadko stracimy chwilę na znalezienie miejsca, w którym fragment do zakomentowania się kończy. Niby drobiazg, ale czasem przeszkadza.

Cóż zatem począć? Na pewno wygodniej by było, gdyby początek i koniec komentarza był widoczny także po jego chwilowym usunięciu, a włączanie i wyłączanie komentarza dało się zrobić w jednym kroku, zamiast w dwóch. Niektórzy radzą sobie z tym problemem, obejmując kod klamrami i dając na początku warunek „if(0)”. Efekt niby taki sam jak przy komentarzu, no i wystarczy zmienić zero na jedynkę, żeby kod się wykonał. Nie jest to jednak ani eleganckie, ani nie odpowiada w pełni komentarzowi – raz, że „zakomentowany” w ten sposób kod musi być poprawny, żeby kompilator/interpreter się nie wywalił, a dwa, że nie widać na pierwszy rzut oka, że kod jest nieaktywny, bo kolorowanie składni pozostaje.

Były już Lemingi w DHTML-u, był Mario w JS, był nawet Defender w favikonce, więc postanowiłem też się wykazać w tej nieco absurdalnej konkurencji i w mitycznym wolnym czasie wystrugałem Kółko i krzyżyk w CSS.

Nie jest to może osiągnięcie porównywalne z powyższymi, ale i CSS nie daje wielkich możliwości interakcji. Cała sztuczka opiera się na sprytnym wykorzystaniu hovera – każde z pustych pól zawiera w sobie planszę z układem znaczków po kolejnym ruchu, gdzie znowu każde z pustych pól zawiera planszę itd. a najechanie na pole powoduje pokazanie tej planszy, która dzięki odpowiednim stylom zasłania poprzednią. Chyba nie muszę dodawać, w jakIEj przeglądarce to nie działa;-).

Jak nietrudno policzyć, nawet w tak prostej gierce liczba węzłów w drzewie wynosi 1 + 9 + (9*8) + (9*8*7) + (9*8*7*6) + … = cholernie dużo. Dlatego właśnie krzyżykami gra komputer, co pozwoliło zmniejszyć liczbę kombinacji do niecałej setki. To oczywiście i tak było zbyt wiele, żeby kodować to ręcznie, ale tę czarną robotę odwalił już za mnie prosty skrypt.

Cóż dodać – mogę tylko życzyć miłych zmagań, aczkolwiek bez szans na zwycięstwo [tu wstawić demoniczny śmiech].

Kwestia, która mnie nurtuje od jakiegoś czasu – dlaczego wszyscy (no dobra, prawie wszyscy) formatują kod CSS tak:

.something
{
    width: 100px;
    height: 30px;
    border: 2px solid #ABC;
}

.something a
{
    text-transform: uppercase;
    color: #666;
}

.somethingElse
{
    float: left;
    clear: both;
    display: block;
    padding: 5px;
}

…a nie tak?

.something { width: 100px; height: 30px; border: 2px solid #ABC; }
.something a { text-transform: uppercase; color: #666; }

.somethingElse { float: left; clear: both; display: block; padding: 5px; }

Jakoś nie przychodzi mi do głowy żadna odpowiedź, poza „no bo przecież wszyscy tak robią”. Wyższość drugiego sposobu wydaje mi się bowiem oczywista – kilkakrotna różnica w liczbie zajętych linijek (w powyższym przykładzie cztery zamiast dwudziestu) to nie w kij dmuchał, a chyba mało kto lubi mieć kod rozciągnięty na dziesięć ekranów, gdy można go praktycznie bez straty dla czytelności zmieścić na dwóch. Oczywiście „zwinięty” kod wymaga przyjęcia jakiejś ustalonej kolejności znaczników, żeby je łatwo znajdować wzrokiem, ale odrobina wewnętrznej dyscypliny to chyba nie taki wielki problem.

OK, rozumiem, że niektórym (a może nawet większości) mimo wszystko wygodniej mieć każdy znacznik w osobnej linijce – ale żeby ci „niektórzy” stanowili 99% webmasterów? Tego jakoś nie kumam.

Potrafi mi to ktoś wytłumaczyć?