... o ASP.NET C# nie mówiąc nikomu.
Bolączki początkującego w ASP.NET
Może to bolączki początkującego programisty a może rozpieszczenie. Nie wiem. Wiem jedno - ASP.NET to "pain in the ass". Ale od początku.
Interfejs stworzył kolega. Tyle wiem o tym jak to się robi. Mu się udało. Ja miałem zacząć wypakowywać go treścią z bazy danych. To co oferuje C# w tym zakresie jakoś nie zachwyca. Zacząłem od tworzenia zapytań w "stringu" i podpinania pod kontrolkę. No i działało... Kiedy już byłem zadowolny ... przypomniałem sobie o SQLInjection :/ Oczywiście funkcji do escapowania nie zaświadczysz w tak nowoczesnym języku jak C#.
Zaświtała mi myśl, aby zobaczyć czy może nie warto (póki czas) przerzucić się na MVC. Składnia SQLowata wbudowana w język programowania fajna, ale totalnie biedna. Bez joinów nie pakuję się w tą zabawę.
Wróciłem więc do zwykłego ASP.NET. Skoro już muszę w tym programować to może stworzę sobie fajną abstrakcję dla bazy danych. Zleciała mi na tym większość dnia. Niestety wybrałem ślepą uliczkę. Tylko dlaczego tak cudowne środowisko jak Visual Studio nie powiedziało mi, że wybierając na target SqlDataReader nie uda mi się go podpiąć jako DataSource do GridView z paginowanie. Nie wiem. A może po prostu nie wiedziało. Tak więc w cudowny sposób stanąłem z gotową, ładną acz kompletnie nieużyteczną klasą do obsługi bazy danych i straconymi 10 godzinami roboczo godzin. Dobrze, że chociaż mi za nie zapłacą.
Maszyna czasu - wskazówka cofa się
Mój dzisiejszy dzień i w ogóle całe programowanie w ASP.NET przypominają mi młodość. Czasy, w których nie wiedziałem co to framework. Czas, w którym wymyślało się koło na nowo. Czas, w którym tworzyło się mnóstwo autorskich rozwiązań.
W ASP.NET to nieunikonione. Nie jeżeli choć troszkę próbujemy dorównać wygodzie oferowanej przez takie technologie jak Django, Pylons, Symfony czy "Drupal Framework". A chyba nie umiem już zaakceptować faktu, że "coś jest źle zrobione".
Pomimo braku wygodnych i dobrze przemyślanych mechanizmów nie natrafiłem na jakiś wysyp "gotowców", które ułatwią Ci życie w sieci. A szkoda. Klasa do porządnej obsługi bazy danych by się przydała. Obecnie - wygląda to dziwnie.
Przyglądając się technologiom stosowanym w ASP.NET mam wrażenie, że tym co tam się znalazło rządziła "burza mózgów". 30 pomysłów, które po prostu zaimplementowano a potem zaczęto się zastanawiać jak to ma razem działać. I coś tam "sklecono". Szalenie niewygodne, nieelastyczne i dziwnie niskopoziomowe.
Pokolenie RuPy
Możemy kłócić się całymi latami o wyższość jednej technologii nad drugą. Idealizować Scalę, krytykować Pythona za niekonsekwencję, Rubego za "abstrakcję". Jednak po dzisiejszym dniu mam to po raz kolejny w nosie. W każdym z tych języków tworzenie witryn to bajka. Żal mi całych mas ludzi, którzy myślą, że ASP.NET to szczyt możliwości. Zarazem zaczynam z każdą chwilą doceniać każdy kolejny projekt, który przyjdzie mi tworzyć z użyciem, którejkolwiek z tych technologii.
Wszystkim, którzy cierpią na bezsenność z powodu wymyślania argumentów na korzyść/niekorzyść jakiegoś języka programowania - daję receptę. Zaprojektujcie w ASP.NET system newsów z komentarzami i bazą użytkowników. Spróbujcie zabezpieczyć aplikację przed XSS, CSRF, SQLInjection z użyciem C# i zróbcie to równie ładnie jak w Python'ie czy Ruby'm. Efekt - gwarantowany: "No more tears".
Podsumowanie
Część artykułów robiących wielkie halo wokół Iron Ruby i Iron Python to mydlenie oczu. Odniosłem kiedyś wrażenie, że Microsoft "robi łaskę", że implementuje te dwa świetny języki na swojej platformie. Może być tylko inaczej. MS idzie po najniższej linii oporu. Stara się zapewnić, godne porządnego, szanującego się programisty, (sic!) środowisko. Środowisko, które zacznie zbliżać się możliwościami do obecnych trendów. Jednak moim zdaniem jeszcze daleko do tego. Oczywiście. Elastyczność Ruby'go i Python'a będzie biła na głowę C# w każdym miejscu i usprawni tworzenie witryn o 150%. Jednak dopiero zastosowanie frameworków znanych ze świata CPython'a czy CRube'go sprawi, że będzie to opcja do rozważenia.
Prawda jest taka, że Microsoft ma problem. Ten problem nazywa się IIS. Jak widać doszli do wniosku, że jedynym wyjściem z niego to zrobić działające z nim implementacje tego co dobre. Oby tylko nie "ulepszyli" całości po swojemu robiąc z genialnych technologii kolejną, której nie da się używać.
P.S. Autor podkreśla na koniec, że w ASP.NET programuje bardzo krótko i negatywne zdanie o technologii może wynikać ze słabej znajomości języka.
Wednesday, July 29, 2009
Wednesday, July 22, 2009
Dlaczego istnieje ASP.NET MVC ?
Od wczoraj jestem "szczęśliwcem". Szczęśliwcem ponieważ mam możliwość (a dokładniej nie mam wyboru) programować w ASP.NET 3.5 w VS 2008.
Szczerze mówiąc - pogubiłem się. Chodzi o to, że niby ASP.NET jest jedno a jednak mówi się o ASP.NET Server-Side, ASP.NET AJAH, ASP.NET AJAX, ASP.NET AJAX + jQuery i nie wiem czy jest coś jeszcze ... ah tak ! Mówi się o ASP.NET MVC ... i to wszystko razem ! powoduje, że się totalnie gubię.
Chciałbym zacząć tworzyć stronę w czymś nowym... nowoczesnym, w czymś co jest obecnie na topie. Jednak obecnie już nie wiem co jest na topie i w co warto inwestować swoje zasoby. Który z tych wszystkich ASP przetrwa próbę czasu.
Wiem jak działa ASP.NET jako taki. Pisanie eventów do elementów witryny przeciągniętych z toolbox-ów. To było to udoskonalenie pozwalające oddzielić warstwę logiki od prezentacji. No i wszystko pięknie ... do momentu gdy nie spotkałem się z informacją, że istnieje ASP.NET MVC... Dlaczego?! zapytałem sam siebie. Czyżby innowacyjna na skalę całej sieci architektura tworzenia witryn internetowych Microsoftu miała okazać się ostatecznie źle zaprojektowaną ? Po co komu kontrolery i modele skoro wszystko można robić na elementach świetnie integrującymi się z bazami danych?
Szczerze mówiąc tak jak od 2 dni próbuję ogarnąć ten chaos tak mogę powiedzieć jedno. Na początku byłem pod ogromnym wrażeniem, że taktyka znana mi z VB 6: przeciągnij, kliknij dwa razy, zaprogramuj - działa również w wypadku witryn internetowych. Szybko, miło przyjemnie - syfiaście od strony źródła witryny, ale trudno.
I teraz nagle (na to wygląda) okazuje się, że (zgaduję - ale przecież z jakiś przyczyn powstało ASP.NET MVC) taka metoda tworzenia witryn jednak nie jest taka świetna ? Wprowadza się MVC ?
Obecnie wymaganie mam jedno: chciałbym stworzyć 99.99 AJAXową aplikację internetową w ASP.NET korzystając z maximum bajerów, które tam napchali. Jeżeli ktoś wie które ze wszystkich wybrać - byłbym wdzięczny.
Szczerze mówiąc - pogubiłem się. Chodzi o to, że niby ASP.NET jest jedno a jednak mówi się o ASP.NET Server-Side, ASP.NET AJAH, ASP.NET AJAX, ASP.NET AJAX + jQuery i nie wiem czy jest coś jeszcze ... ah tak ! Mówi się o ASP.NET MVC ... i to wszystko razem ! powoduje, że się totalnie gubię.
Chciałbym zacząć tworzyć stronę w czymś nowym... nowoczesnym, w czymś co jest obecnie na topie. Jednak obecnie już nie wiem co jest na topie i w co warto inwestować swoje zasoby. Który z tych wszystkich ASP przetrwa próbę czasu.
Wiem jak działa ASP.NET jako taki. Pisanie eventów do elementów witryny przeciągniętych z toolbox-ów. To było to udoskonalenie pozwalające oddzielić warstwę logiki od prezentacji. No i wszystko pięknie ... do momentu gdy nie spotkałem się z informacją, że istnieje ASP.NET MVC... Dlaczego?! zapytałem sam siebie. Czyżby innowacyjna na skalę całej sieci architektura tworzenia witryn internetowych Microsoftu miała okazać się ostatecznie źle zaprojektowaną ? Po co komu kontrolery i modele skoro wszystko można robić na elementach świetnie integrującymi się z bazami danych?
Szczerze mówiąc tak jak od 2 dni próbuję ogarnąć ten chaos tak mogę powiedzieć jedno. Na początku byłem pod ogromnym wrażeniem, że taktyka znana mi z VB 6: przeciągnij, kliknij dwa razy, zaprogramuj - działa również w wypadku witryn internetowych. Szybko, miło przyjemnie - syfiaście od strony źródła witryny, ale trudno.
I teraz nagle (na to wygląda) okazuje się, że (zgaduję - ale przecież z jakiś przyczyn powstało ASP.NET MVC) taka metoda tworzenia witryn jednak nie jest taka świetna ? Wprowadza się MVC ?
Obecnie wymaganie mam jedno: chciałbym stworzyć 99.99 AJAXową aplikację internetową w ASP.NET korzystając z maximum bajerów, które tam napchali. Jeżeli ktoś wie które ze wszystkich wybrać - byłbym wdzięczny.
Thursday, July 16, 2009
Obwiniajcie reżyserów - filmy są niewinne
Często wybierając się na jakiś film do kina lub chociaż chcąc wybrać repertuar na "filmowy wieczór" z przyjaciółmi zbieram opinie od znajomych. Jakie filmy im się podobały, co warto obejrzeć. Niektórzy wciąż wygłaszają subiektywne opinie, inni - rzetelniejsi - starają mi się w skrócie opisać klimat i wątek aby możliwie obiektywnie opisać mi jakiego kina mam się spodziewać. Ocenę pozostawiają mi. Jest też kilka osób, które zna mnie już na tyle dobrze, że mówią często "spodobałoby Ci się", albo "jak podobało Ci się to obejrzyj też to - trochę straszne - ale zobaczysz, że warto się pobać. W Twoich klimatach." Czasami trafiają, czasami nie, ale generalnie znają mnie już trochę i doradzają mi najlepiej jak potrafią.
Opinie o filmach
Opinie jakie czytam pod recenzjami filmów ... hmm ... Ujmę to tak. Nie rzucają mi się w oczy opinie obiektywne. Czyli fakty. Raczej krzykliwe "pierwsza część była lepsza", albo "super", czy coś w stylu "po co w ogóle kręcili coś jeszcze", "idźcie koniecznie, genialny film". Nic nie mówiące komentarze, przez które trzeba się przedzierać.
Pośród fal takich i podobnych uwag można czasem znaleźć perełki. "Jestem wrażliwą osobom i moim zdaniem w filmie jest za dużo krwi.", "Mój ośmioletni syn bawił się świetnie, ale jego starszy brat, lat 17, wynudził na śmierć.", albo "Mam 28 lat, jestem matką dwójki bliźniaków - lat 13. Moim zdaniem film jest zbyt brutalny jak na 13latków. Za dużo w nim przemocy."
Takie opinie, które wnoszą coś do ogólnego opisu filmu, to rzadkość. Chwała tym ludziom, że są ! Najczęściej spotyka się je w komentarzach pod bajkami dla dzieci. W innych często takich zimnokrwistych, naszpikowanych faktami ocen brak.
100 punktów i sławę wróżę portalowi, który wprowadzi do systemu komentarzy guziczek "odsiej subiektywne".
Dlaczego winicie niewinne filmy?
Chciałem skupić się na opiniach w stylu: "ten film jest do du**" albo "po co robiliście kolejną część? To chłam w porównaniu z pierwszą."
Weźmy na start Trylogię Tolkiena. Jest nakręcona i wyreżyserowana dość jednolicie - nieprawdaż ? Nie ma jakiś szczególnych różnic pomiędzy nimi. Styl, kostiumy, Świat są na mojego oko spójne. Nic dziwnego skoro całość wyreżyserował ten sam gość Peter Jackson. To jest nasz wzór. Teraz czas na odejścia od reguły.
Ktoś pamięta "Krótkie spięcie" ? Czy komuś podobała się bardziej druga część od pierwszej ? Mi osobiście nie i myślę, że istnieje znaczna rzesza osób, która podziela moje zdanie. Może to przez to, że pierwszą część wyreżyserował John Badham a drugą już Kenneth Johnson. No ale nic może to przypadek. Idźmy dalej.
Wracając, z kina po "Harry Potter i więzień Azkabanu" miałem dziwny niedosyt. Coś mi nie grało. Nie miałem nic filmowi konkretnie do zarzucenia, po prostu... takie dziwne uczucie, że coś było nie tak, źle, że nie na taki film się wybierałem. Tym bardziej dziwne, że dwie poprzednie części były super. Po powrocie sprawdziłem reżysera. Nie był to Chris Columbus ale Alfonso Cuarón. No cóż życie.
Butterfly Effect
Jestem obecnie na świeżo po obejrzeniu trzeciej części Efektu Motyla. Drugiej nie widziałem wcale. Pierwsza szalenie mi się podobała. O każdej kolejnej opinie były różne (te subiektywne). Część pisała, że jest super, inny, że beznadzieja.
Z pierwszą częścią nie miało to za bardzo nic wspólnego. Tam ktoś miał pomysł i ten pomysł było widać w filmie. On urzekł tych, którzy okrzyknęli ten film genialnym.
Po obejrzeniu trzeciej części znowu sprawdziłem reżysera. Zmienił się. Gość zrobił film o zabijaniu. Film, opinie o którym zaczęli wygłaszać nie specjaliści od "Butterfly Effect", ale specjaliści od filmów w stylu "Piła" a w tej kategorii (domyślam się bo nie jestem fanem) BFE 3 jest myślę fatalny. Z jakiś przyczyn reżyser wepchnął film do szuflady innej kategorii, kategorii gdzie nie ma szans, kategorii, w której opinie przestały dotyczyć tytułowego motywu a zaczęły "historii zabijania", kategorii gdzie głos zaczęli zabierać wielbiciele gore i innych - pokrewnych.
Przez różową szybkę
Jakie są z tego wnioski. Moim zdaniem idąc na film należałoby patrzeć nie na tytuł, ale na tytuł i na reżysera - a często już ten drugi wiele nam powie. Można szybko i bez problemu sprawdzić jego portfolio. Być może sprawdzenie w tworzeniu jakich filmów ma doświadczenie da nam wystarczający pogląd o tym czego możemy w kinie się spodziewać.
Jeżeli trzecia część HP była IMHO gorsza niż dwie poprzednie, a BFE 3 to "Time-machine Saw-killer" a nie Butter Fly Effect to może czas oceniać filmy po reżyserach i to ich karcić za to co nam się podobało a co nie? Warto też odnosić się do tego co podobało nam się w pierwszej części. Ta sama opinia względem "którejś części" i bez podobnego porównania zmienia wszystko.
Chiny serwisowi, który wprowadzi w komentarzach opcję "Za najlepszą z poprzednich części uważam: (o) pierwszą, ( ) drugą, ( ) trzecią".
Opinie o filmach
Opinie jakie czytam pod recenzjami filmów ... hmm ... Ujmę to tak. Nie rzucają mi się w oczy opinie obiektywne. Czyli fakty. Raczej krzykliwe "pierwsza część była lepsza", albo "super", czy coś w stylu "po co w ogóle kręcili coś jeszcze", "idźcie koniecznie, genialny film". Nic nie mówiące komentarze, przez które trzeba się przedzierać.
Pośród fal takich i podobnych uwag można czasem znaleźć perełki. "Jestem wrażliwą osobom i moim zdaniem w filmie jest za dużo krwi.", "Mój ośmioletni syn bawił się świetnie, ale jego starszy brat, lat 17, wynudził na śmierć.", albo "Mam 28 lat, jestem matką dwójki bliźniaków - lat 13. Moim zdaniem film jest zbyt brutalny jak na 13latków. Za dużo w nim przemocy."
Takie opinie, które wnoszą coś do ogólnego opisu filmu, to rzadkość. Chwała tym ludziom, że są ! Najczęściej spotyka się je w komentarzach pod bajkami dla dzieci. W innych często takich zimnokrwistych, naszpikowanych faktami ocen brak.
100 punktów i sławę wróżę portalowi, który wprowadzi do systemu komentarzy guziczek "odsiej subiektywne".
Dlaczego winicie niewinne filmy?
Chciałem skupić się na opiniach w stylu: "ten film jest do du**" albo "po co robiliście kolejną część? To chłam w porównaniu z pierwszą."
Weźmy na start Trylogię Tolkiena. Jest nakręcona i wyreżyserowana dość jednolicie - nieprawdaż ? Nie ma jakiś szczególnych różnic pomiędzy nimi. Styl, kostiumy, Świat są na mojego oko spójne. Nic dziwnego skoro całość wyreżyserował ten sam gość Peter Jackson. To jest nasz wzór. Teraz czas na odejścia od reguły.
Ktoś pamięta "Krótkie spięcie" ? Czy komuś podobała się bardziej druga część od pierwszej ? Mi osobiście nie i myślę, że istnieje znaczna rzesza osób, która podziela moje zdanie. Może to przez to, że pierwszą część wyreżyserował John Badham a drugą już Kenneth Johnson. No ale nic może to przypadek. Idźmy dalej.
Wracając, z kina po "Harry Potter i więzień Azkabanu" miałem dziwny niedosyt. Coś mi nie grało. Nie miałem nic filmowi konkretnie do zarzucenia, po prostu... takie dziwne uczucie, że coś było nie tak, źle, że nie na taki film się wybierałem. Tym bardziej dziwne, że dwie poprzednie części były super. Po powrocie sprawdziłem reżysera. Nie był to Chris Columbus ale Alfonso Cuarón. No cóż życie.
Butterfly Effect
Jestem obecnie na świeżo po obejrzeniu trzeciej części Efektu Motyla. Drugiej nie widziałem wcale. Pierwsza szalenie mi się podobała. O każdej kolejnej opinie były różne (te subiektywne). Część pisała, że jest super, inny, że beznadzieja.
Z pierwszą częścią nie miało to za bardzo nic wspólnego. Tam ktoś miał pomysł i ten pomysł było widać w filmie. On urzekł tych, którzy okrzyknęli ten film genialnym.
Po obejrzeniu trzeciej części znowu sprawdziłem reżysera. Zmienił się. Gość zrobił film o zabijaniu. Film, opinie o którym zaczęli wygłaszać nie specjaliści od "Butterfly Effect", ale specjaliści od filmów w stylu "Piła" a w tej kategorii (domyślam się bo nie jestem fanem) BFE 3 jest myślę fatalny. Z jakiś przyczyn reżyser wepchnął film do szuflady innej kategorii, kategorii gdzie nie ma szans, kategorii, w której opinie przestały dotyczyć tytułowego motywu a zaczęły "historii zabijania", kategorii gdzie głos zaczęli zabierać wielbiciele gore i innych - pokrewnych.
Przez różową szybkę
Jakie są z tego wnioski. Moim zdaniem idąc na film należałoby patrzeć nie na tytuł, ale na tytuł i na reżysera - a często już ten drugi wiele nam powie. Można szybko i bez problemu sprawdzić jego portfolio. Być może sprawdzenie w tworzeniu jakich filmów ma doświadczenie da nam wystarczający pogląd o tym czego możemy w kinie się spodziewać.
Jeżeli trzecia część HP była IMHO gorsza niż dwie poprzednie, a BFE 3 to "Time-machine Saw-killer" a nie Butter Fly Effect to może czas oceniać filmy po reżyserach i to ich karcić za to co nam się podobało a co nie? Warto też odnosić się do tego co podobało nam się w pierwszej części. Ta sama opinia względem "którejś części" i bez podobnego porównania zmienia wszystko.
Chiny serwisowi, który wprowadzi w komentarzach opcję "Za najlepszą z poprzednich części uważam: (o) pierwszą, ( ) drugą, ( ) trzecią".
Saturday, July 11, 2009
Roi est mort, vive le Roi! *
* Umarł Król niech żyje król !
Od obrazu do telewizji
Współczesny świat mediów to głównie przekaz obrazu - telewizja. To co kiedyś było malowidłami na ścianach jaskiń i grobowców, później obrazami na płótnach wyewolułowało w zdjęcia aby ostatecznie przyjąć znaną nam po dziś dzień formę telewizji. Połączenie obrazu i dźwięku. Pełne dynamiki pozwalające prezentować nie tylko to co ruchome ale również swoich statycznych przodków. Połączenie bazujące na dwóch tylko zmysłach: wzroku i słuchu, dające ogromne możliwości.
Medialny chaos
Wraz z rozwojem techniki telewizor stał się globalnym śmietnikiem. Możemy znaleźć tam niemal wszystko. Anonimowi ludzie proponują nam co dzień 24 godziny treści. Przemnożone przez ilość dostępnych kanałów tworzą globalną sieć informacji. Próbuje ją porządkować znany nam dobrze program telewizyjny lub jego nowocześniejszy potomek: gazeta telewizyjna.
Spoglądając z boku widzimy ogromną ilość programujących ludzi przekazów: reklam, haseł, poglądów, słów i gestów. Słowem - idealne medium do sprzedawania w atrakcyjny sposób wszelkich treści i zarabiania na tym bałaganie. Piąta władza w ręku możnych tego świata. Nigdy jednak nie stała się głosem ludu.
Medium społeczności
Internet. Najbardziej wolne z do tej pory istniejących mediów. Telewizja, w której zatrzymał się czas. Najnowocześniejsze z do tej pory istniejących metod przekazu informacji. Tutaj popularność zyskują Ci, którzy przypadają do gustu milionom. Bez promocji, kampanii reklamowych, marketingu. Prości, zwykli ludzie. Kiedyś źródło zawierające setki prostych dokumentów, dziś - naszpikowana najróżniejszymi technologiami i mediami sieć.
Z czego zbudowałbyś swój świat?
Medialne HTML5. Wprowadza w świat internetu technologie czyniące go bardziej telewizyjnym niż kiedykolwiek. Wrzuca do jednego worka wiele rożnych unowocześnień i jak sami twórcy przyznają :
Z drugiej strony stoi martwy XHTML 2: dobrze przemyślany, zaprojektowany jednak za późno aby zaistnieć na rynku przy szumnie reklamowanym HTML 5.
Z czego Ty zbudowałbyś swój świat? Z HTML 5, który przypomina duże kolorowe klocki Duplo. Jest ich naprawdę sporo, wszystkie siedzą w jednym pudle. Pozwalają budować pstrokate budowle, duże, zwracające na siebie uwagę twory.
A może zdecydowałbyś się na dużo bardziej skomplikowane Lego Technic: wymagające więcej wysiłku - pozwalające jednak tworzyć zaprojektowane z inżynierską precyzją machiny.
Tworząc standardy, nadając im charakter a następnie wprowadzając je do użytku -wyznaczamy kierunek, w którym zmierza sieć i formę w jaką się przekształca. Globalna telewizja, pełna medialnych haseł, krzykliwych reklamówek i serwisów telewizyjnych? A może system świetnie zaprojektowanych, semantycznych aplikacji sieciowych? Wybór należy do nas.
Duże trudniej uzgodnić
Nie uważam, że HTML 5 jest zły. Uważam tylko, że jego wdrożenie i forma są kompletnie nieprzemyślane. Kolejny standard, który za rok będzie trzeba poprawiać. Po co? Skoro można zaprojektować go od razu dobrze? Odnoszę silne wrażenie, że ktoś pcha go do sieci na siłę, oby szybciej - jakby miał zbić na tym nie lada interes. Niestety kosztem jego jakości a na tym stracą wszyscy. Rewolucja zawsze niosła za sobą ofiary. Moim zdaniem tak będzie i w tym przypadku. Standard, choć stworzony w słusznej sprawie sprzeciwu wobec opieszałości W3C, idzie do sieci po trupach.
Pierwsze ułomności już widać. Wystarczy przeczytać W3C porzuca standaryzację kodeków audio i wideo w HTML 5. Przy istniejącej ilości graczy, od których zależy kształt sieci, ciężko jest "coś ustalić". XHTML 2 nie mieszał się tam gdzie go nie proszono. Skupiał się na podstawach tworzenia opisu dokumentu. HTML 5, stara się być "teorią wszystkiego". Tak więc jaka każda teoria wszystkiego będzie borykał się z podobnymi problemami jeszcze nie raz.
Podział jest dobry
Moim zdaniem wystarczyłoby usiąść nad tym co wymyślono w obydwu standardach i jeszcze raz wybrać to co z nich najlepsze. Jednak - tak jak w przypaku XHTML 2 - rozdzielić zadania pomiędzy technologie. Standardy zaś zaprojektować tak aby łatwo się je łączyło. To właśnie urzekło mnie w XHTML 2. Był mały i skupiał się dobrze na celach, do realizacji, których był przeznaczony. Tam gdzie trzeba było - zakładał korzystanie z koleżeńskich technologii.
Dlaczego moim zdaniem tak jest lepiej ?
Rozwój sieci oparty o wiele wspierających się standardów będzie znacznie szybszy i prostszy. Prostsze dokonywanie zmian, szybsze podejmowanie decyzji charakterystyczne dla mniejszych grup zadaniowych, jasno wyznaczony kierunek i cel. Atomizacja zawsze służyła elastyczności - duże rozwiązania są jej pozbawione i trudniejsze do ogarnięcia.
Stworzenie osobnego standardu dla opisu mediów oszczędziłoby nam już jednego problemu. SVG tylko na tym skorzystało. MathML czy RDF to kolejne przykłady "standardów-wtyczek" (o ile można byłoby je tak nazwać). O ile trudniejsze byłoby i dłużej trwało rozwijanie ich w ciele istniejących metajęzyków ? Tym czasem do HTML 5 próbuje się "na wczoraj" wrzucić technologie, których asymilacja jak widać sprawia nie lada problemy. A wystarczyłoby rozwiązać i rozwinąć temat w swoim czasie, z użyciem odrębnego standardu. Może MediaML ?
Ślepa uliczka
Bałagan stworzyć jest łatwo - jednak tymi, którzy będą się z nim borykali jesteśmy my: webmasterzy. Nawet najnowocześniejsze techniki modernizacji sieci - źle zaprojektowane - przyniosą nam więcej problemów niż korzyści.
Tworząc nowe standardy: jeden duży czy 5 małych, możemy jasno wyznaczać kierunek w jakim będzie zdążała sieć: większego bałaganu czy nowocześniejszych technologii. Nie można obejść się tutaj bez podejścia inżynierskiego, bez którego, konstrukcja zacznie się za jakiś czas walić.
Bez względu na to jak dobrze zaprojektowane zostaną technologie pozostaje jeszcze jeden problem. Ilość standardów rośnie: RDF, MathML, HTML 5, WebForms, SVG. Rośnie także ich objętość a wraz z nią czas jaki poświęcamy na tworzenie witryn. Witryn, które aby były tworzone szybko wymagałyby nowoczesnych narzędzi pozwalających natychmiastowo skorzystać z najnowszych osiągnięć i uzyskać oczekiwany efekt. Narzędzi, których W3C nam nie da.
HTML 5 posiada te same wady co Ruby względem Python czy PHP względem swoich poprzedników: można w nim napisać coś strasznie niepoprawnego - liczy się na dojrzałość i samodyscyplinę programisty. Czy z takim standardem zajdziemy daleko ? Jak szybko stanie się kulą u nogi ? A może lepiej byłoby zaczekać i wprowadzić unowocześnienia w bardziej przemyślany sposób, stworzyć do nich narzędzia ? Na te pytania każdy może odpowiedzieć sobie sam. Ja marzę o sieci: semantycznej, wolnej i technologicznie doskonałej. O internecie złożonym z aplikacji sieciowych, dobrze zaprojektowanych mechanizmów. Drugiego telewizora mi nie trzeba. Jeden bałagan w pudełko mi starczy.
Od obrazu do telewizji
Współczesny świat mediów to głównie przekaz obrazu - telewizja. To co kiedyś było malowidłami na ścianach jaskiń i grobowców, później obrazami na płótnach wyewolułowało w zdjęcia aby ostatecznie przyjąć znaną nam po dziś dzień formę telewizji. Połączenie obrazu i dźwięku. Pełne dynamiki pozwalające prezentować nie tylko to co ruchome ale również swoich statycznych przodków. Połączenie bazujące na dwóch tylko zmysłach: wzroku i słuchu, dające ogromne możliwości.
Medialny chaos
Wraz z rozwojem techniki telewizor stał się globalnym śmietnikiem. Możemy znaleźć tam niemal wszystko. Anonimowi ludzie proponują nam co dzień 24 godziny treści. Przemnożone przez ilość dostępnych kanałów tworzą globalną sieć informacji. Próbuje ją porządkować znany nam dobrze program telewizyjny lub jego nowocześniejszy potomek: gazeta telewizyjna.
Spoglądając z boku widzimy ogromną ilość programujących ludzi przekazów: reklam, haseł, poglądów, słów i gestów. Słowem - idealne medium do sprzedawania w atrakcyjny sposób wszelkich treści i zarabiania na tym bałaganie. Piąta władza w ręku możnych tego świata. Nigdy jednak nie stała się głosem ludu.
Medium społeczności
Internet. Najbardziej wolne z do tej pory istniejących mediów. Telewizja, w której zatrzymał się czas. Najnowocześniejsze z do tej pory istniejących metod przekazu informacji. Tutaj popularność zyskują Ci, którzy przypadają do gustu milionom. Bez promocji, kampanii reklamowych, marketingu. Prości, zwykli ludzie. Kiedyś źródło zawierające setki prostych dokumentów, dziś - naszpikowana najróżniejszymi technologiami i mediami sieć.
Z czego zbudowałbyś swój świat?
Medialne HTML5. Wprowadza w świat internetu technologie czyniące go bardziej telewizyjnym niż kiedykolwiek. Wrzuca do jednego worka wiele rożnych unowocześnień i jak sami twórcy przyznają :
"HTML is a mess!" and "rather than being designed, HTML just grew, by different people just adding stuff to it".
Z drugiej strony stoi martwy XHTML 2: dobrze przemyślany, zaprojektowany jednak za późno aby zaistnieć na rynku przy szumnie reklamowanym HTML 5.
Z czego Ty zbudowałbyś swój świat? Z HTML 5, który przypomina duże kolorowe klocki Duplo. Jest ich naprawdę sporo, wszystkie siedzą w jednym pudle. Pozwalają budować pstrokate budowle, duże, zwracające na siebie uwagę twory.
A może zdecydowałbyś się na dużo bardziej skomplikowane Lego Technic: wymagające więcej wysiłku - pozwalające jednak tworzyć zaprojektowane z inżynierską precyzją machiny.
Tworząc standardy, nadając im charakter a następnie wprowadzając je do użytku -wyznaczamy kierunek, w którym zmierza sieć i formę w jaką się przekształca. Globalna telewizja, pełna medialnych haseł, krzykliwych reklamówek i serwisów telewizyjnych? A może system świetnie zaprojektowanych, semantycznych aplikacji sieciowych? Wybór należy do nas.
Duże trudniej uzgodnić
Nie uważam, że HTML 5 jest zły. Uważam tylko, że jego wdrożenie i forma są kompletnie nieprzemyślane. Kolejny standard, który za rok będzie trzeba poprawiać. Po co? Skoro można zaprojektować go od razu dobrze? Odnoszę silne wrażenie, że ktoś pcha go do sieci na siłę, oby szybciej - jakby miał zbić na tym nie lada interes. Niestety kosztem jego jakości a na tym stracą wszyscy. Rewolucja zawsze niosła za sobą ofiary. Moim zdaniem tak będzie i w tym przypadku. Standard, choć stworzony w słusznej sprawie sprzeciwu wobec opieszałości W3C, idzie do sieci po trupach.
Pierwsze ułomności już widać. Wystarczy przeczytać W3C porzuca standaryzację kodeków audio i wideo w HTML 5. Przy istniejącej ilości graczy, od których zależy kształt sieci, ciężko jest "coś ustalić". XHTML 2 nie mieszał się tam gdzie go nie proszono. Skupiał się na podstawach tworzenia opisu dokumentu. HTML 5, stara się być "teorią wszystkiego". Tak więc jaka każda teoria wszystkiego będzie borykał się z podobnymi problemami jeszcze nie raz.
Podział jest dobry
Moim zdaniem wystarczyłoby usiąść nad tym co wymyślono w obydwu standardach i jeszcze raz wybrać to co z nich najlepsze. Jednak - tak jak w przypaku XHTML 2 - rozdzielić zadania pomiędzy technologie. Standardy zaś zaprojektować tak aby łatwo się je łączyło. To właśnie urzekło mnie w XHTML 2. Był mały i skupiał się dobrze na celach, do realizacji, których był przeznaczony. Tam gdzie trzeba było - zakładał korzystanie z koleżeńskich technologii.
Dlaczego moim zdaniem tak jest lepiej ?
Rozwój sieci oparty o wiele wspierających się standardów będzie znacznie szybszy i prostszy. Prostsze dokonywanie zmian, szybsze podejmowanie decyzji charakterystyczne dla mniejszych grup zadaniowych, jasno wyznaczony kierunek i cel. Atomizacja zawsze służyła elastyczności - duże rozwiązania są jej pozbawione i trudniejsze do ogarnięcia.
Stworzenie osobnego standardu dla opisu mediów oszczędziłoby nam już jednego problemu. SVG tylko na tym skorzystało. MathML czy RDF to kolejne przykłady "standardów-wtyczek" (o ile można byłoby je tak nazwać). O ile trudniejsze byłoby i dłużej trwało rozwijanie ich w ciele istniejących metajęzyków ? Tym czasem do HTML 5 próbuje się "na wczoraj" wrzucić technologie, których asymilacja jak widać sprawia nie lada problemy. A wystarczyłoby rozwiązać i rozwinąć temat w swoim czasie, z użyciem odrębnego standardu. Może MediaML ?
Ślepa uliczka
Bałagan stworzyć jest łatwo - jednak tymi, którzy będą się z nim borykali jesteśmy my: webmasterzy. Nawet najnowocześniejsze techniki modernizacji sieci - źle zaprojektowane - przyniosą nam więcej problemów niż korzyści.
Tworząc nowe standardy: jeden duży czy 5 małych, możemy jasno wyznaczać kierunek w jakim będzie zdążała sieć: większego bałaganu czy nowocześniejszych technologii. Nie można obejść się tutaj bez podejścia inżynierskiego, bez którego, konstrukcja zacznie się za jakiś czas walić.
Bez względu na to jak dobrze zaprojektowane zostaną technologie pozostaje jeszcze jeden problem. Ilość standardów rośnie: RDF, MathML, HTML 5, WebForms, SVG. Rośnie także ich objętość a wraz z nią czas jaki poświęcamy na tworzenie witryn. Witryn, które aby były tworzone szybko wymagałyby nowoczesnych narzędzi pozwalających natychmiastowo skorzystać z najnowszych osiągnięć i uzyskać oczekiwany efekt. Narzędzi, których W3C nam nie da.
HTML 5 posiada te same wady co Ruby względem Python czy PHP względem swoich poprzedników: można w nim napisać coś strasznie niepoprawnego - liczy się na dojrzałość i samodyscyplinę programisty. Czy z takim standardem zajdziemy daleko ? Jak szybko stanie się kulą u nogi ? A może lepiej byłoby zaczekać i wprowadzić unowocześnienia w bardziej przemyślany sposób, stworzyć do nich narzędzia ? Na te pytania każdy może odpowiedzieć sobie sam. Ja marzę o sieci: semantycznej, wolnej i technologicznie doskonałej. O internecie złożonym z aplikacji sieciowych, dobrze zaprojektowanych mechanizmów. Drugiego telewizora mi nie trzeba. Jeden bałagan w pudełko mi starczy.
Friday, July 10, 2009
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ą.
Saturday, July 4, 2009
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:
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:
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.
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.
Subscribe to:
Posts (Atom)