Framework's killers*

Rozdzielczość wykresu jest umowna i nie stanowi żadnej faktycznej miary mówiącej o skali różnić w czasie projektowania.

Tworzenie witryn na bazie Drupala, w kolejnych projektach, zajmuje coraz mniej czasu. Godziny mu poświęcone zwracają się znacznie szybciej niż te zainwestowane we frameworki. Tyle z teorii - czas na fakty.

Niewdzięczny start

Początki to przedzieranie się przez kolejną dokumentację. Opis klas, funkcji, doczytywanie szczegółów. Wewnętrzna walka nakazująca szukać rozwiązania we frameworku nie zaś w samym języku programowania.

Wiele zależy tu od naszych zdolności, jakości dokumentacji, dostępnych materiałów, aktywności społeczności na forach i grupach dyskusyjnych. W obydwu przypadkach wszystko zaczyna się mniej więcej od tego samego poziomu.

Framework-bajka

Rozpoczynający swoją pracę z frameworkami doznają szokujących usprawnień.

Granicząca z cudem autonomiczność warstwy baz danych (ORM shock!). Drastycznie zwiększona kohezja kodu po rozmieszczeniu go w kontrolerach (controllers' code improvement). Wszystko-ułatwiające helpery wykonujące dokładnie to czego potrzebujemy (helpers exactly).

Zaczynamy z wolna czuć się jak Alicja w Krainie Czarów, której nagle pokazano wejście do króliczej nory. Pozornie ciemne i ciasne, jednak kryjące w sobie cały nowy świat. Świat, w którym ciężko jest znaleźć zadanie wymagające napisania więcej niż 7 linii kodu.

Oszczędność czasu we frameworkach

W następnych projektach - zaczynamy wykorzystywać stworzone przez nas rozwiązania ponownie. Prawo lenistwa.

Do kolejnych projektów przenosimy klasy, funkcje, z czasem kontrolery, modele a nawet całe biblioteki. Od czasu do czasu coś modyfikujemy, dodajemy kilka nowych opcji, poprawiamy znalezione błędy.

Godziny poświęcane na tworzeniu strony zaczynamy liczyć w wykonanych instrukcja copy/paste. Jedyne usprawnienia stanowi używanie skrótów klawiszowych zamiast opcji menu kontekstowego. Po pewnym czasie przestają działać nam klawisze [CTRL], [X], [C] i [V] a w koszta projektu zaczynamy wliczać nową klawiaturę.

Magiczny świat CMS'ów

Wczoraj był u Ciebie klient. Zamówił witrynę. W nocy miałeś sen. Rozmawiałeś z wróżką. Mówiła o jakimś fantastycznym rozwiązaniu. Posiada wszystkie zalety framework'a. Większość standardowych klas ktoś zaprogramował za Ciebie. Witryna jest już praktycznie gotowa. Twoim jedynym zadaniem jest dostosować wszystko do Twoich potrzeb.

Drupal - gotowi start !

W Drupal'u dostajemy wszystko to, a nawet więcej. Z punktu widzenia developera. Gdzieś na spodzie funkcjonuje sobie zwykły framework. Taki z abstrakcją dla baz danych, helperami, systemem templatów i innymi featurami.

Na nim dopiero napisane są klasy do CMS'a. Tutaj dostajemy kilkanaście mechanizmów ekstra: ACL'e, klasy użytkowników, newsów, system rejestracji i logowania, raportowanie... Wymieniać można naprawdę długo.

Poza klasami - system szablonów: formularze, panele administracyjne, tabelki, domyślne CSS'y. Do tego kilka autorskich bibliotek JS dzięki, którym interfejs stylizuje się (sic!) na aplikację webową.
Z punktu widzenia użytkownika - gotowa strona, developera - wymarzony punkt startu.

Gdzie oszczędzamy czas ?

Zyskaliśmy już czas na projektowaniu i adaptacji standardowych elementów witryny. Systemu użytkowników, newsów, ACL'e, menu - są już gotowe. Doinstalowanie dodatkowych modułów, autorskich czy też pobranych z witryny projektu, zajmuje kilka chwil. Znacznie mniej niż wkoponowywanie ich do strony na poziomie kodu. O to dba Drupal.

Tworzymy wyłącznie to czego nam brakuje, ewentualnie modyfikujemy istniejące rozwiązania. Możliwość jakie dają 144 funkcje (Drupal 7) pozwalające wpiąć się w niemal każdy mechanizm przygotowanych przez twórców - są nieograniczone. Wolno nam wszystko: od modyfikowania pól formularzy po przeprojektowywanie zapytań SQL.

Stworzenie zwijanego pola fieldset, sortowania drag & drop, przyklejonych nagłówków tabel, poziomych zakładek. Wszystko wymaga dodania parametru przy wywołaniu helpera lub nadania odpowiednich klas CSS. JavaScript ? A co to jest ?

Podsumowanie

Znacznie szybciej modyfikuje się gotową witrynę, aniżeli pisze na nowo. Szczególnie łatwo w przypadku Drupal'a, który do takich przeróbek został stworzony. API pozwalające zmieniać każdy aspekt działania aplikacji. Obszerna tutoriale dla developerów. Świetnie udokumentowane API. Czytelny, jednolity kod. Setki funkcji i gotowych bibliotek. Bibliotek które od lat sprawdzają się na dziesiątkach tysięcy witryn internetowych.

Barierę stanowi pomyślenie o CMS'ie w funkcji środowiska developerskiego - nie gotowej aplikacji. Przyjrzenie się na ile modyfikowanie jest szybsze od tworzenia. O ile łatwiej jest zmieniać dobrze zaprojektowane rozwiązania w miejscu ich tworzenia. Jednak ostrzegam - być może już nigdy więcej nie sięgniesz do żadnego frameworka.

* Wpis traktuje o Drupal'u ponieważ jest najlepiej znanym autorowi, od strony developerskiej, CMS'em. Nie wyklucza on faktu iż równie dobre, a nawet lepsze, efekty można uzyskać w przypadku innych, dobrze zaprojektowanych systemów zarządzania treścią.

Dramaty WSGI i geniusz Microsoftu

Każdy kto choć odrobinkę siedział w administracji serwerami zna temat hostowania aplikacji. Gdy mowa o PHP zazwyczaj mówi się tylko o mod_php i temat jest prosty. Znacznie ciekawiej maluje się hostowanie aplikacji napisanych w innych językach: między innymi ruby czy python.

Starsi wujkowie

Bardziej wymagający użytkownicy, których aplikacje miały działać z uprawnieniami właściciela pliku albo być wrappowane przez suexeca konfigurowało się z wykorzystaniem CGI lub jego bardziej wydajnego kolegi FastCGI. Istniejące w różnych odmianach dobrze służyły aplikacjom webowym serwowanym z odrębnymi uprawnieniami, zwiększając bezpieczeństwo i wygodę operowania na zasobach znajdujących się po stronie serwera.

Wraz z wkroczeniem w świat Pythona czy Rubego w sieci zaroiło się od "rails-serwerów" taki jak Thin, Ebb, Mongrel. Frameworki Pythona takie jak Web2Py, Django, Pylons były wyposażone we własne wydajne serwery developerskie, które nie jednej osobie posłużyły również w środowisku produkcyjnym.

Próba wejścia w świat Apache

Równocześnie na arenie zaczęły pojawiać się inne rozwiązanie, te przypominające w swojej budowie mod_php: mod_python, mod_passenger. Swój debiut miał nawet mod_ruby.

Również dedykowane serwery "zagościły" pod piórem Apache. Obsługiwane przez wynalazki rodziny modułów mod_proxy zapytania, trafiały na silnie skalowalne, wydajne klastry serwerów dedykowananych, takich jak wcześniej wspomniany Thin, Ebb czy Mongrel. Pozwalało to obsługiwać w wydajny sposób zapytania, równocześnie nie zdejmując z głowy pióropusza wodzowi plemienia Apachów.

WSGIzachwyt

O WSGI po raz pierwszy przeczytałem gdy w ramach nauki języka angielskiego postanowiłem przeczytać całe PEP-333. Posiadała wszelkie zalety:

• Technologia nie działała stricte jako moduł - tym samym zawieszenie się hostowanej z jej użyciem aplikacji nie powodowało zawieszenia serwera a jedynie samej aplikacji


• Kolejne zapytania były przesyłane do kolejnych procesów i obsługiwane w kolejnych wątkach podobnie jak FastCGI. Wykorzystywało więc zalety maszyn zarówno wieloprocesorowych jak i procesorów z kilkoma rdzeniami


• Pozwalało ad-hoc bez zewnętrznych wrapperów, jak suexec, uruchamiać aplikacje działające w imieniu konkretnego użytkownika i grupy. Wszystko out-of-the-box.

Specyfikacja mnie urzekła. Koniec z nieprzespanymi nocami spędzonymi nad pisaniem łatek do suexeca, z wiszącymi bez celu procesami FastCGI, koniec z koszmarami o sprytnych użytkownikach zawieszającymi serwer swoimi skryptami :]

WSGIrozczarowanie

Bajka o tytule "Pylons na WSGI hostowane pod Apache/mod_wsgi w Linuksie" skończyła się w dniu, gdy miałem napisać prostą witrynę w IIS, bez użycia frameworka.

Na starcie okazało się, że standard w ogóle nie przewiduje hostowania plików statycznych. Trzeba się uciekać do sztuczek:

• przekierowywania ścieżek na poziomie serwera


• używania subdomen dla plików statycznych


• serwowania plików przez naszą aplikację


• unikania plików statycznych

Echa tych problemów można zauważyć w poradnikach konfiguracji serwerów dla frameworków czy kodzie aplikacji. Narzędzie, które tworzyłem miało być proste w użyciu, skalowalne i przenośne. Możliwe do wykorzystania w kilka chwil. Skoro tak - osobne konfigurowanie serwera odpadało, a rezygnacja z plików statycznych niestety nie wchodziła tutaj w grę.

Z czasem prosty skrypt zaczął rozrastać się do rangi frameworka. System szablonów Mako, paste i kod przekopiowany żywcem z Pylonsów pozwalający serwować pliki statyczne - czułem, że wymyślam koło na nowo a z prostego projektu zaczyna robić się kolosalne przedsięwzięcie. Projekt, którego znaczną część stanowi jakaś otoczka, kompletnie zaciemniająca najważniejsze - kod samego narzędzia.

Wszystko działo się w ramach isapi-wsgi. Potencjał jaki posiada dawał podstawy do wstrzyknięcie odpowiedniej konfiguracji do witryny IIS automatycznie. Pojawiły się problemy.

Każdorazowa zmiana w działaniu skryptu wymuszała restart serwera. Na produkcyjnym, rozwiązaniem tego problemu, było resetowanie osobnej puli zasobów IIS'a, do której przydzielona została aplikacja z Pythonem. Jedyną metodą aby to wykonać było posiadanie praw administratora lub pisanie do takowego - gdy coś się zmieniło.

W międzyczasie okazało się, że isapi-wsgi posiadał, na szczęście banalny do naprawienia, błąd. Wskazywał on na to iż twórca skupia się na tworzeniu modułu dla IIS for clients natomiast nie testuje go w warunkach IIS for servers.

A żaba chińczyka co z tego wynika

Cała przygoda skończyła się na przeprojektowaniu wszystkiego tak aby działało w trybie CGI. To kolejna historia, która skłania mnie do refleksji, że z jakiś przyczyn Windows jest środowiskiem, "zasadowym" - dla rozwiązań genialnie funkcjonujących w świecie Open Source. Pracując coraz więcej z produktami Microsoftu odczuwam stwierdzenia w stylu "Python jest multiplatformowym" jako postawienie równości z kompletnym pominięciem wygody użytkowania.

Zapewnia ją dopiero korzystanie z analogicznych implementacji wprowadzanych przez MS. Każde z nich świetnie wkomponowuje się w funkcjonujący ekosystem rozwiązań ze stajni Redmond. Mechanizmy i integracja stoją na oszałamiającym poziomie. Tworzone w ich ramach narzędzia uzyskują genialne efekty i możliwości. Tym samym dając wygodę użytkowania analogiczną dla systemów bazujących na rozwiązaniach opensourcowych.

Moim skromnym zdaniem zachwyt nad geniuszem produktów Microsoftu może osiągnąć zenit wyłącznie na poziomie rozwiązań jemu dedykowanych. Tak jak osiąga zenit zachwyt nad przygotowanym środowiskiem pracy Mac'a - Apple. Nikt, decydując się na Linuksa, nie dziwi iż programy spod Windows często nie działają. Nikt nie narzeka kupując Mac'a, że nie ma tam MS Office. Wszyscy nagminnie korzystają z aplikacji nie pisanych przez Microsoft narzekając na Windows.

P.S. Wpis jest dzieckiem zachwytu nad wygodą i wydajnością pracy w środowisku zbudowanym wyłącznie z użyciem produktów Microsoft. Oszołomienia, w jak wielkim stopniu, tak jednolite technologicznie środowisko przekracza bariery, których osiągnięcie (sic!) byłoby niewyobrażalnie trudniejsze w świecie Open Source.

Instalacja Internet Explorer 8 może trwać dobę

Wczoraj wieczór poświęciłem troszkę czasu aby ponownie wrócić do Windows Vista. Czułem pewien dyskomfort na myśl iż Windows 7 zrobi sobie od Lipca wakacje i stwierdzi, że od tej pory co dwie godziny musi odpoczywać.

Po powrocie na Windows Vista w pierwszej kolejności chciałem zainstalować Internet Explorer 8. Uważałem ten manewr za kluczowy w procesie zwiększenia bezpieczeństwa mojego komputera. IE w wersji 8 pojawił się w systemie dopiero przed chwilą. Minęły około 24 godziny od momentu, w który Windows uporał się ze wszystkimi łatkami i pozwolił zainstalować przeglądarkę w najnowszej wersji.

Zdaję sobie sprawę, że na całą sytuację ma wpływ niska częstotliwość wydań Windows i silna integracja, zależność przeglądarki od systemu. Przyznajcie jednak, że sytuacja jest niekomfortowa.

Nie zaświadczymy podobnych problemów z żadną inną z popularnych przeglądarek pod Windows i dobrze :) Cieszę się tym bardziej w tej chwili widząc iż mam w końcu najnowszy browser produkcji z Redmond.

Opera Unite - zmiana polityki autoryzacji

Nie zgadniecie jak wielkie było moje zdziwienie kiedy dziś rano próbowałem skorzystać z Opera Unite i okazało się (fakt, kiedyś zakładałem konto ma my.opera.com), że mój mail jest zajęty.

Ale to nic :) Kiedy próbowałem nadać nazwie konta formę jaką zwykłem stosować z kropką okazało się, że nie mogę. I nie byłoby w tym nic dziwnego gdyby nie to, że posiadam już takie konto :] na my.opera.com

Panowie z Opery, przy próbie logowania, grzecznie zasugerowali nazwę zmiany konta (wszak musi spełniać wszystkie obostrzenia adresu URL)

Nie pozostaje mi nic innego jak założyć wczas konto "koprowski" i stworzyć komputer "jan" ;]

Express yourself - dlaczego kłócimy się o wyższość języków programowania

Na co dzień używamy jakiegoś języka. W naszym przypadku jest to język polski. Nikt nie narzeka na to iż nauczono go akurat tego języka i akurat w nim się wychował. Używamy go jak potrafimy najlepiej. Kiedy z czasem zaczynamy zagłębiać się w meandry języka angielskiego zauważamy iż jest niezrównany w opisie i pojemności leksykalnej gdy chodzi o żargon techniczny. Jego wykorzystanie w tej dziedzinie daje nam ogromne możliwości i otwiera wiele zamkniętych drzwi, które gdy władaliśmy jeszcze wyłącznie polskim, stały przed nami zamknięte. Nikt nie narzeka jednak i nie krytykuje języka polskiego, nie przestaje go nagle używać twierdząc, "że jest gorszy". Następuje raczej zapożyczanie, mieszanie i ewentualne spolszczanie wyrazów angielskich w gronie osób "technicznych".

Również będąc fizykiem czy biologiem ciężko mieć pretensje do ilości łaciny z jaką się stykamy. Ten źródłosłów po prostu w najlepszy sposób opisuje istotę zagadnienia i nie ma od kilkunastu tysięcy lat lepszego języka aby wyrazić to wszystko co opisuje.

Należy również dodać, że każdy język ulega z czasem czemuś co puryści nazwali by "skażeniem". Chodzi o przekręcanie i dodawanie nowych wyrazów i sformułowań, często w danym okresie czasu kompletnie nie poprawnych gramatycznie. Takich wyrazów "ułomnych". Zjawisko to występowało i występuje w wielu językach nie tylko w języku polskim ale również i w angielskim i zapewne każdym innym.

O co się właściwie kłócimy ?

Do tego wpisu sprowokowały mnie kłótnie, które systematycznie wywiązują się pod moimi artykułami publikowanymi na Webhosting.pl. Który polak (który chce aby oświadczyny wypadły pięknie) wybrałby do nich język niemiecki (szorstki i suchy) mogąc wykorzystać piękno i urok choćby języka francuskiego lub mając do dyspozycji całą gamę poezji śpiewanej Erotyków Krzysztofa Kamila Baczyńskiego ?

Języki programowania są różne. Na początku, gdy zaczynamy przygodę z programowaniem, używamy ich aby wklepać ciąg instrukcji, które ma dla nas wykonać komputer. Z czasem zaczynają nam służyć do czegoś więcej. Programując, po kilku latach, zaczynamy pisać kod tak aby wyrazić swoją intencję - zupełnie jak w języku naturalnym.

Czasem możemy pisać coś w Pythonie i myślimy: no nie, tutaj to idealnie, no po prostu idealnie użyłbym domknięcia (z języka Ruby), a tutaj .... kurcze - genialna sytuacja do wykorzystania modułów (z języka Ruby). Stajemy przed wyborem: zmieniamy język programowania albo spędzamy więcej czasu jak bez użycia tych mechanizmów równie dobrze wyrazić naszą intencję konstruując poprawnie kod.
Myślę, że właśnie w tym momencie u wielu osób zaczyna zapalać się lampka "może język XYZ jest lepszy od ABC ?".

Co to znaczy lepszy język ?

Co to znaczy lepszy język ? Czy angielski jest lepszy od polskiego ponieważ w znacznym stopniu (jest wszak źródłosłowem) składa się na nomenklaturę techniczną ? Czy francuski jest lepszy od polskiego ponieważ oświadczyny, czy przysięga małżeńska ma w nim tak szalenie uroczy wydźwięk i oszałamiające brzmienie ?

Do tej pory w Polsce funkcjonują wydziały, gdzie wykłada się informatykę, na których obowiązuje ochrona języka Polskiego czytaj - nie używa się nomenklatury anglojęzycznej. A więc się da :) Jak to naprowadziło mnie na pewne odniesienie do języków programowania ?

Kiedy czyta się książkę o C pisaną przez entuzjastycznego programistę lat 90tych nie raz i nie dwa razy, ale niemalże, co publikację, można trafić na stwierdzenie, że "wskaźniki to potężne narzędzie" i można je wykorzystać na tak wiele sposobów. Sam kiedy zaczynałem studia - a programowaliśmy pierwszy rok w C - używałem ich namiętnie i z niemałym zachwytem podziwiałem kunszt ich wykorzystywania. Nastąpił czas gdy wskaźniki zaczęto krytykować. Świetnie opisuje to w swojej książce "Inżynieria Oprogramowania C++" Victor Shtern. Jednak były tak silnie zakorzenione w mentalności programistów czasów języka C iż wielu nie wyobrażało sobie nowoczesnego języka ich pozbawionych. Myśl o ich nieobecności budziła w wielu lęk, obawy. Nie potrafili myśleć w perspektywie pozbawionej takiego mechanizmu. I na tym chciałem się skupić.

Wiele współczesnych języków programowania pokazuje, że w przypadku znacznej klasy zagadnień, da się programować bez wskaźników. Młode pokolenie programistów-samouków, które zaczęło swoją przygodę z językami wyższego poziomu niż C++, może nigdy się nie dowie co to wskaźnik i, że coś takiego w ogóle istniało. To co najważniejsze w tym wydarzeniu to fakt iż to jak postrzegamy język programowania zależy od tego jak bardzo w funkcji charakterystycznych dla niego struktur myślimy.

Python jest językiem o pewnych cechach. Na pewno jest językiem prostym (jak na przykład angielski). Anglicy dobrze rozumieją się ze sobą i posługują swoim językiem od kilkunastu setek lat. Żaden z nich nie narzeka na jakieś "braki". Tak samo programiści Pythona. Jeżeli potraktować kod języka jako "ja piszę kod daję komuś innemu aby go zrozumiał on go czyta i rozumie albo nie" to i Pythonowcy bardzo dobrze się rozumieją. Równie dobrze rozumieją się ludzie piszący w Pascalu, Ruby, czy każdym innym językiem programowania.

Bardzo nie lubię kłótni o wadach czy o rzekomych ułomnościach jakiegoś języka czy jego wyższości nad innym. Lambda w Pythonie. Podobno ułomna - spełnia wspaniale szereg zadań i jest nieocenioną pomocą w wielu przypadkach. Ktoś ma lepszą lambdę - fantastycznie, jeżeli będę jej potrzebował na pewno użyję jego języka. A jak bardzo chcą to niech ją wdrożą i w Pythonie, tylko, żeby nie popsuli języka. Nikt im nie broni. Zapytajcie jednak świeżo upieczonego programistę Pythona (wcześniej powiedzmy PHP) o wrażenia - powie, że język jest świetny. Mechanizmy zaprezentowane w kursie przyjmie do wiadomości takimi jakimi są i takimi zacznie je lubić, stosować i będzie robił to dobrze. Tak samo będzie gdy ktoś nauczy się Rubego czy Scali - oczywiście wciąż tylko jednego z nich. Chodzi o to, że nauczeni dobrze myśleć w jakiś ramach możemy pisać z nich naprawdę dobre programy. Ktoś kto dobrze umie Pythona nie będzie miał problemu z wyrażeniem siebie w kodzie - zrobi to tak jak pozwala mu na to język i zrobi to dobrze.

Kiedy zaczynamy się kłócić ?

Wszystko zaczyna się psuć gdy znamy np. i Pythona i Rubego. Nie uważam broń Boże, że to złe. Uważam, że to fantastyczne. Jednak wciąż denerwują mnie ludzie, którzy znają oba te języki i zaczynają narzekać, że "Python nie jest Rubym", a "Ruby nie jest Pythonem" w zależności od sytuacji. Najbardziej na tym cierpią nowi programiści, którzy właśnie zastanawiają się nad przejściem, na któryś z tych świetnych języków i trafiają na tego rodzaju dyskusje. Po prostu beton. I wcale się nie dziwie ludziom, którzy po wejściu na 5 pierwszych stron i przeczytaniu komentarzy tego rodzaju rezygnują i zostają np. przy PHP rezygnując z dalszego rozwoju w kierunku, który naprawdę może dać wiele zabawy, satysfakcji i nowych, ekscytujących doświadczeń.

Całe filozofowanie zaczyna się chyba przez to, że ulegliśmy "reklamie" i marketingowi jakiegoś języka programowania i przez jakiś czas uważaliśmy go za "naj" a teraz gdy poznajemy kolejny to nagle ten poprzedni wydaje nam się jakiś taki... nie za bardzo "naj".
Wszystko przez to, że daliśmy się złapać na prosty chwyt. Chwyt polegający, że za "naj" nie było już żadnego słowa, które powiedziałoby najjaki jest ten język programowania, który zamierzamy poznać.

Piszmy o pozytywach !

Python jest najprostszy - zwięzłością, oszczędnością i czytelnością bije po oczach
Ruby jest najekspresywniejszy - powala pisać developerski poematy
Scala jest najczystsza - purystyczna koncepcyjnie, paradygmatowo i składniowo

Czy nie jest to obiektywną prawdą ? Czy takie ujęcie tematu nie jest prawdziwsze ? Oczywiście rozumiem, że jakaś struktura w jednym języku programowania została zaprojektowana lepiej niż w innym. W porządku. Języki naturalne ewoluują, na ile jest to możliwe. Na pewno lata świetlne trudniej ewoluują też i języki programowania. Nikt nie broni wprowadzić do języka dobrych zmian i go unowocześniać. Wiadomo jednak, że pewne zmiany nie będą mogły być wprowadzone, inne będą kosztowały nie wiadomo ile wysiłku aby ich dokonać. Języki obecnie istniejące są ulepszane na ile to tylko możliwe i należy się z tego cieszyć, wspierać ich rozwój (choćby duchowo) i korzystać z ich zalet - nie skupiać się zaś na wadach szczególnie tych, z którymi nic nie można zrobić - bo po co o nich pisać skoro nie można ich naprawić. Należy te wady znać, pokazać język, których nie posiada ale nie wciąż krytykować.

Jeżeli język naturalny pozwala nam na rozbudowanie go o zaporzyczenia angielskie, łacińskie czy francuskie - korzystajmy z nich. Jeżeli pozwala to robić w znacznym stopniu - róbmy tak, jeżeli w mniejszym, wykorzystujmy to nadal na ile się da. Ale nie mówmy, że nasz język jest zły. Jest piękny, ma pewną historię i z pewnych przyczyn brzmi i wygląda tak a nie inaczej. Jako Polacy nie obrażamy się na naszą gramatykę i ortografię, gremialnie nie zaczynamy, rezygnować z naszego nadwiślańskiego narzecza, na rzecz angielskiego. Część z nas czyni zaporzyczenia inni uczą się władać innym językiem (bo muszą albo dziedzina ich do tego zmusza) - nikt jednak nie robi afery z tego iż język polski jest jaki jest.

Bądźmy mistrzami w kunszcie :)

Sztuka bycia człowiekiem elokwentnym polega między innymi na wykorzystaniu tego co się zna tak jak tylko najlepiej się potrafi w sytuacji, z którą się spotyka a gdy trzeba, douczenia się czegoś nowego. Człowiek inteligentny zna zarówno zalety jak i wady narzędzi, którymi się posługuje - bo to jest potrzebne aby dobrze ich używać - jednak nie wytyka ich "gdzie popadnie" i "jak tylko nadarzy się okazja". Zarówno jedne jak i drugie informacje służą ku lepszemu użytkowaniu i znacznie bardziej precyzyjnemu doborowi potrzebnej aparatury niż krytyce. Nikt nie narzeka na młotek, że ciężko się nim wkręca śrubki i nikt na piłę, że słabo się nią wbija gwoździe.

Chciałem wszem i wobec zaznaczyć, że tekst nie jest skierowany przeciwko jakiejś konkretnej osobie. Jest wyłącznie zbiorem moich przemyśleń.

HTML 5 i WebForms 2.0 pod strzechą

Dzisiaj wraz ze współlokatorem postanowiliśmy sprawdzić jak malują się nowoczesne standardy sieciowe i co w trawie piszczy. Wyniki naszych obserwacji przerosły najśmielsze oczekiwania.

Od dziś tylko HTML 5

To chyba pierwsze co do nas dotarło. Łaziliśmy po stronkach i zaglądaliśmy do źródeł. Chyba największym odkryciem było przejrzenie źródeł witryny postawionej na Wordpressie i ... stwierdzenie, że szablon jest napisany w HTML 5.
Potem przyjrzeliśmy się innej napisanej dla hecy przez jakiegoś blogera wertując równocześnie znaczenia poszczególnych tagów i nie znanych nam atrybutów w drafcie W3C. Zrobiliśmy własną prostą stronkę i ... to po prostu działa. Stronka opisana w HTML 5 posiada masę fajowych znaczników. W gruncie rzeczy ich wstawianie nic nie zmienia z wyglądu strony ale najważniejsze jest to, że chyba, żadna przeglądarka się tym nie zachłysnęła i zwróciła najnormalniejszy prosty dokument. Nie mówię tu o jakiś videach czy innych audiach ale zwykłych nowych znacznikach, tych które posiadają raczej znaczenie niż "wygląd" czy funkcjonalność.
O ile dla nas może nie wiele zmieniają - z wyglądu - o tyle dla robotów wyszukiwarek to musi być prawdziwa rewolucja na miarę RDF. Wiedzieć gdzie jest menu, gdzie nagłówek, a gdzie stopka, co jest tekstem, co wstawką ... kurcze - internet gdzie strony byłby opisane z użyciem HTML 5 (o RDF nie wspominając) to chyba 3/11 Raju dla wszystkich wyszukiwarek kontekstowych. Po prostu masa znaczników, które pozwalają oddzielić treść, od znaczenia, od tagów odpowiedzialnych za elementy witryny nie związane z treścią. Bomba !
Wniosek ?
Od dziś tylko HTML 5. Przeglądarki znaczniki tolerują, a roboty mogą w magiczny niemalże w porównaniu z HTML 4 sposób zindeksować naszą stronę.

Webforms 2.0 - dla nowoczesnych

Zawsze podobała nam się koncepcja Webforms 2.0 gdzie walidacja jest wbudowana w składnię znaczników i nie trzeba się o to martwić, pola odpowiednich typów mają swój interfejs do wybierania daty itd... Chyba nie wyobrażacie sobie jakie było nasze zdziwinie gdy zobaczyliśmy na wikipedii, że ... format jest w 100% obsługiwany w Operze 9.0. Po prostu szok. Przeglądarka z Presto na pokładzie poszła błyskawicznie w ruch. Kto chce zobaczyć jakie udogodnienia wprowadza WebForms 2.0 i jak rewolucyjne są to zmiany niech obejrzy sobie witrynę http://olav.dk/wf2/demo/.
Sceptyków IE poczęstuję wiadomością iż na podanej powyżej stronie zarówno IE 6 jak i 7 (sic!) obsługują WebFormsy w 100% (sic!) ! IE 6 lepszy od FF i Webkit, które sobie w ogóle z tym sobie nie radzą (według danych z Wikipedii obsługują 1 atrybut) ? Czy to możliwe ?! Gdzieś musi być haczyk ! Jeżeli chcesz go znaleźć odwiedź http://olav.dk/wf2/demo/. Brawa dla Microsoftu - zrobili to jak zrobili - ale zrobili to już w IE 6 i działa ! Byli pierwsi i to lata świetlne przed konkurencją. Szacunek !
Ale to nic. Najlepsze przed nami. Otoż istnieje biblioteka, która implementuje WebForms z użyciem JavaScript. W tym momencie zapadła decyzja - od dziś używamy WebForms 2.0. Dzięki tej bibliotece będzie obsługiwana w każdej popularnej przeglądarce :] To wspaniała wiadomość. Osoby projektujące strony z wersja dla "nie posiadających JS" wcale nie muszą się przejmować - walidator W3C nie zwróci błędów w przypadku formularzy typu data czy czas, a jeżeli nie wesprze ich przeglądarka to po prostu wyświetli w ich miejscu pola tekstowe - czyli to co mielibyśmy w HTML 4. A walidacja ? Jest czy nie, WebForms 2.0 czy JavaScript - i tak dla bezpieczeństwa trzeba dane przemielić jeszcze po stronie serwera.
Wniosek ?
Dlaczego nie używamy jeszcze WebForms 2.0 ? No właśnie... sam zadaję sobie to pytanie i moja odpowiedź brzmi "nie wiem", od dziś używam !

CSS 3 w natarciu

Tak wiem. IE 8 nie zdaje ACID 3 i zasysa... Już się tego nasłuchałem. Dobre zestawienie co się da posiada QuirksMode. Prawa kolumna wygląda sielsko :] Po lewej IE w barwach wojennych. Nie patrzę na IE 5.5 czy 6 wcześniejsze niż 8 bo to bez sensu. Mówimy o nowoczesnych standardach i przeglądarkach. Historię pozostawmy historykom. To jest blog informatyka. CSS3: selektory i deklaracje. IE 8 w deklaracjach CSS 3 wypada tylko trochę gorzej niż Firefox. Wszystkich krzykaczy zasłaniających się testem ACID 3 ostudzę faktem iż oficjalnie Opera 10a i Safari 4 ACID 3 zdają - co z tego skoro z tabelki i tak wynika iż wszystkich znaczników nie obsługują bezbłędnie. Ten test można przejść bez pełnej obsługi CSS.
Zresztą - mówił o tym już kilka lat temu Microsoft w kontekście ACID 2. "Przejście ACID 2 nie oznacza zgodności ze standardami" argumentował fakt iż Internet Explorer nie zdaje tego testu. Jest tak również z ACID 3. Test można przejść - a zgodności ze standardami nie spełniać. Jednak trzeba bez bicia przyznać się iż Microsoft nas na razie tutaj nie rozpieszcza.
Wnioski ?
Jak do tej pory tylko dwie przeglądarki obsługują w znacznym stopniu CSS 3. Tutaj jednak w przeciwieństwie do HTML 5 czy WebForms stajemy przed wyborem: wszystko albo nic... Pozostaje więc czekać i liczyć na to iż za pół roku (oby szybciej) będziemy mogli cieszyć się CSS3 w znacznie większym stopniu. Taka natura kaskadowych arkuszy stylów iż nie da się ich potraktować jak HTML 5. Szkoda.

Podsumowanie

Dla mnie dzisiejsze odkrycia stanowią rewolucję w życiu webmastera. Mogę bez przeszkód (sic!) używać HTML 5 i WebForms 2.0. Może nawet jeżeli dziś enginy wyszukiwarek nie do końca to wykorzystają, a w śród odwiedziającyc znajdą się osoby, których formularze nie będą posiadały funkcjonalności WebForms 2.0 to za rok czy dwa, gdy standardy te będą już normą, stworzona dziś stronka nie będzie wcale odstawała od tych "nowocześniejszych". Wszystko zupełnie bez żadnego wysiłku i pracy z mojej strony. Po prostu to co napisałem a nie było obsługiwane zacznie działać. Czysty zysk :]
Niestety z CSS 3 nie jest już tak kolorowo. Fajnie, że już od dawna można używać składni selektorów w wersjach bibliotek JScriptowych. Mogłoby (o ile to wykonalne) powstać coś na wzór biblioteki JS do WebForms. Uzyskiwanie layoutów zgodnych z CSS 3 z użyciem JS ? Możliwe ? Nie wiem. Chciałbym jednak dziś czegoś takiego używać. Twórcy przeglądarek mogliby sobie standard implementować tak długo jak muszą a developerzy używać już nowej składni. To byłoby piękne.
Z niecierpliwością czekam na obsługę CSS 3, a od dziś - tylko HTML 5 i WebForms 2.0!

Biurowe formaty plików a użytkownik

Często zdarzało się, że któryś ze znajomych prosił mnie o pomoc z odczytaniem zawartości pliku docx lub podobnego. Ktoś uraczył go tym nowoczesnym formatem i wysyłając zapisane w nim dokumenty robił mu po prostu niedźwiedzią przysługę. Sam posiadam wyłącznie OpenOffice a jeszcze do niedawna nie dawał sobie rady z Open XML Format.

Dziś wyszło słońce dla wszystkich użytkowników Windows a także i Linuksów. Na stronach CodePlex pojawiło się pierwsze wydanie OpenXML Document Viewer. Przeciętnego użytkownika nie posiadającego Microsoft Office zainteresuje funkcjonalność pozwalająca odczytywać format docx w przeglądarce. Istnieją pakiety wersja dla IE, Opery, Firefoxa oraz dla linii komend dostępne zarówno dla Windows jak i Linux.



Po zainstalowaniu pakietu możemy otworzyć plik Open XML Microsoft Word w przeglądarce interenetowej. Zostanie on prze konwertowany na stronę HTML.



Osoby, które potrzebuję konwersji a nie boją się o prywatność danych mogą już od dawna korzystać z oferty http://www.zamzar.com/. Lista formatów, nai które, z których możemy konwertować budzi podziw. Jednak wysyłamy swoje dane gdzieś i nie wiadomo co do końca się z nimi dzieje - plik skonwertowany przychodzi po pewnym czasie do nas na maila. Pewne osoby mogą mieć wątpliwości co do prywatności tak konwertowanych informacji.

Niektóre pliki możemy sobie obejrzeć lub zmienić ich format z użyciem Google Documents inne obejrzeć z wykorzystaniem darmowych Microsoft * Viewer. Listę "podglądarek" i konwerterów znajdziemy na przykład pod tym adresem.

Na dzień dzisiejszy nie ma problemu. Format taki jak docx otwiera się nawet w WordPadzie. Tak tak - mowa o Windows 7. WordPad obsługuje również ODT. Sam chciałbym zobaczyć swoją minę gdy w Windows 7 klikając dwa razy na plik ODT otworzył mi go właśnie Wordpad. Problem jak widać zaczyna być z docem. A jak jest z konwersją pomiędzy starymi formatami Microsoft Office, nowymi i natywnymi plikami Open Office ?

Byłem w szoku gdy dotarłem do projektów Open XML / ODF Translator oraz b2xtranslator. Pierwszy ma zapewnić interopracyjność pomiędzy dokumentami OpenOffice a Open XML. Zadaniem drugiego jest konwersja plików bez końcówki 'x' (doc, xls, ppt) na tą z 'x' na końcu (docx, xlsx, pptx). Działanie wydaj się banelne. Podczas instalacji jesteśmy pytani czy aplikacja ma zintegrować się z menu kontekstowym jako rozszerzenie explorera. Po kliknięciu na przykład na plik doc pojawia się opcja "Convert to docx". Wybierając ją po chwili mamy ten sam plik w nowym formacie. Prościej się chyba nie dało !



Dziwne tylko, że rozszerzenie nie działa gdy domyślną aplikacją dla doców jest Open Office Writer. No właśnie - najprościej jednak jest chyba mieć w pogotowiu OpenOffica, który choć często z błędami, otworzy wszystko.

Bardzo cieszy mnie stan oprogramowania dotyczący biurowych formatów plików. Narzędzia do konwersji z doc na docx, obsługa ODT przez WordPad, możliwość otwierania plików OpenXML w OpenOffice :] Świat staje się piękny a to co było koszmarem jeszcze pół roku temu zaczyna być używalne. Widać, że ani Microsoft ani twórcy, których oprogramowanie używa domyślnie ODF nie próżnują. Cieszę się, że w tej "wielkiej walce formatów" ktoś dostrzegł małego użytkownika i zadbał o to aby nie był pokrzywdzony w tym starciu ale raczej by mógł z niego wyjść bez szwanku. Tak trzymać panowie !