Dzisiaj około godziny 5 rano zmagania z Machinarium zakończyły się sukcesem. Mogłem pójść spać.
Gra jest niesamowicie przygotowana:) Naprawdę robi wrażenie. Po pierwsze nie jest to gra przygodowa w stylu "chuchnij dwa razy, otwórz okno, przejrzyj się w lusterku a otworzą się drzwi". Wszystkie zagadki (może poza ptakiem na kablach i ostatnią sceną) zostały bardzo dokładnie przygotowane. Nawet jeżeli nie wiemy co robić, możemy uzyskać pomoc i zobaczyć "co autor miał na myśli", a nawet wtedy wykonanie zadania stanowi wyzwanie, a rozwiązanie nie jest oczywiste.
Gra zaskoczyła mnie rosnącym poziomem trudności. Lokacje stają się stopniowo coraz bardziej złożone, początkowo zaś wszystko musimy wykonać w "jednym pomieszczeniu". To moim zdaniem ogromna zaleta. Gdy interakcje i relacje stają się coraz bardziej złożone zaczynają pomagać genialne miniaturki przedmiotów. Dzięki wyeksponowanym ważnym elementom (np. jak zobaczyłem radio odrazu wiedziałem co z nim zrobić) wiadomo czego szukać. Wygląd przedmiotu bardzo często sugeruje nam jakiś punkt zaczepienia. Brawo!
Gra bardzo przyjemna, na pewno przejdę ją jeszcze nie raz:] Polecam każdemu
Wednesday, December 16, 2009
Tuesday, December 15, 2009
Machinarium
Dzisiaj kupiłem fantastyczną grę pod tytułem: Machinarium. Już od dawna miałem chęć zmierzyć się z jakąś grą przygodową. Demo tej gry mnie wręcz urzekło. Nie wytrzymałem i kupiłem! Kosztować mnie to będzie około 72zł. Nie mało jednak najbardziej zadowolił mnie charakter zakupu. Po podaniu numeru karty i autoryzowaniu jej po prostu dostałem na maila linki z adresami skąd mogę pobrać grę. Fantastyczne! Nie muszę czekać na przesyłkę, martwić się czy dojdzie. Po prostu płacę i to kiedy dotrze gra zależy już tylko od mojego łącza! :) Oby więcej takich produkcji!
Notatnik obserwatora zjawisk legalnych:
Od dziecka (kiedy pamiętam) lubiłem gry przygodowe. Jednak każdą przechodziłem z solucją. Powiem wam, że pierwszy raz głupio mi jest przejść z solucją grę. Grę za którą się zapłaciło (aby mieć z niej zabawę a nie ją przejść). Jak widać kupowanie gier bardzo zmienia do nich podejście.
Notatnik obserwatora zjawisk legalnych:
Od dziecka (kiedy pamiętam) lubiłem gry przygodowe. Jednak każdą przechodziłem z solucją. Powiem wam, że pierwszy raz głupio mi jest przejść z solucją grę. Grę za którą się zapłaciło (aby mieć z niej zabawę a nie ją przejść). Jak widać kupowanie gier bardzo zmienia do nich podejście.
Sunday, December 13, 2009
Korzystanie z kolei stało się zmorą
Czasy gdy szło się do okienka i prosiło "studencki do Gdańska Oliwy" minęły bezpowrotnie. Dzisiaj widać efekty Państwowego rozdzielenia ostatnich taborów pomiędzy Marszałków Województw i spółkę Intercity.
Nadszedł czas kolei ekskluzywnej bo drogiej. Ci, którzy chcą pojechać gdzieś w Polskę muszą przedzierać się przez dziesiątki promocji, planować podróż znacznie wcześniej, kupować bilety przez internet.
Najbardziej współczuje studentom, którzy lubili często jeździć do domu. Oni odczują te zmiany najbardziej. Nie wystarczy już po prostu kupić biletu. Każda podróż będzie loterią pomiędzy "im wcześniej tym taniej" a "last minute ticket". Wielką strategiczną grą wyboru pomiędzy nastoma ofertami spółki InterCity a przesiadkami z wykorzystaniem połączeń InterRegio.
Ja chyba przerzucę się na PKSy. Bo to chyba jedyna ostoja "kupuję bilet i jadę". Swoją drogą uważam, że przeżyją renesans.
Nadszedł czas kolei ekskluzywnej bo drogiej. Ci, którzy chcą pojechać gdzieś w Polskę muszą przedzierać się przez dziesiątki promocji, planować podróż znacznie wcześniej, kupować bilety przez internet.
Najbardziej współczuje studentom, którzy lubili często jeździć do domu. Oni odczują te zmiany najbardziej. Nie wystarczy już po prostu kupić biletu. Każda podróż będzie loterią pomiędzy "im wcześniej tym taniej" a "last minute ticket". Wielką strategiczną grą wyboru pomiędzy nastoma ofertami spółki InterCity a przesiadkami z wykorzystaniem połączeń InterRegio.
Ja chyba przerzucę się na PKSy. Bo to chyba jedyna ostoja "kupuję bilet i jadę". Swoją drogą uważam, że przeżyją renesans.
Czy Starcraft II będzie idealny?
Od tygodnia oglądam wszystkie battle reporty z SC II jakie tylko się nawiną. SC2 jeszcze nie wyszedł ale rozegrano już w nim naprawdę wiele rozgrywek.
Rodzi się pytanie. Czy SC2 będzie grą idealną? Dlaczego? Podczas projektowania SC domyślam się, że nie było możliwości uzyskania takiego odzewu graczy jak tutaj. Gra i plansze mogą być na bieżąco równoważone i poprawiane pod dyktando mistrzów rozgrywek światowych w tej dziedzinie. Jest więc szansa, że SC II długo nie będzie wymagało patchy balansujących grę i szanse wszystkich ras.
Rodzi się pytanie. Czy SC2 będzie grą idealną? Dlaczego? Podczas projektowania SC domyślam się, że nie było możliwości uzyskania takiego odzewu graczy jak tutaj. Gra i plansze mogą być na bieżąco równoważone i poprawiane pod dyktando mistrzów rozgrywek światowych w tej dziedzinie. Jest więc szansa, że SC II długo nie będzie wymagało patchy balansujących grę i szanse wszystkich ras.
Saturday, December 5, 2009
Drupal 7 w cieniu Buzzr
Wczoraj natrafiłem na genialną prezentację projektu o nazwie Buzzr.
Zrobiła na mnie ogromne wrażenie. Buzzr to frontend zbudowany na Drupalu 6. Szalenie podoba mi się jego "Wordpressowość". W końcu coś przyjaznego, z ikonkami. Dzięki silnemu wykorzystaniu Drag&Drop oraz podzieleniu wszystkiego na kroki można naprawdę w genialnie prosty sposób konfigurować witrynę. Pomysły chłopaków z Lullabot uważam wręcz za rewelacyjne a wykonanie za naprawdę dobre.
Drupal 7 koncentruje siły developerów głównie na poprawianiu i porządkowaniu.
Dużo pracy zostało włożone w usunięcie pewnych niewygodnych funkcji obsługi plików. Wiele hooków posiada swoje bardziej wyspecjalizowane wersje. Niektóre ogólne zostały podzielone na kilka miejszych (tak np. hook_node_api czy hook_form_alter) inne zaczęły żyć własnym życiem (weźmy choćby hook_schema).
Drupal 7 korzysta już z PDO więc developerzy nie muszą się już martwić o implementowanie driverów do baz danych - będą obsługiwać ich tyle ile PDO obsłuży. API bazodanowe w ogóle zostało znacznie usprawnione. W końcu można w Drupalu korzystać z transakcji a nawet tabele w bazie MySQL tworzą się jako InnoDB.
To wszystko pięknie, ale odczują to raczej developerzy modułów (ja odczułem i muszę powiedzieć, że wprowadzone zmiany są naprawdę fantastyczne), ale nie zwykli użytkownicy (obecnie D7 i tak jest wolniejszy od D6). Właśnie tutaj zastanawiam się co jest grane.
Buzzr to ewidentna rewolucja. I moim zdaniem genialna rewolucja. Rozumiem, że D7 woli iść drogą ewolucji. Wiele funkcjonalności zewnętrznych modułów zostało wessane do samego Drupala. Na pewno pozwoli to lepiej je zintegrować, zrobić większy porządek.
Tak jak Drupal 6 ukierunkowywał się na nody tak Drupal 7 ukierunkowuje się na pola. Wygląda to jakby D7 miał wbudowane CCK i jest w tym dużo prawdy bo D7 znaczną część CCK wciągnął do siebie.
Nowinki znowu idą w stronę zaawansowanych technologii i performance. Bo kto dzisiaj wykorzysta wsparcie Drupala dla RDF poza naprawdę świadomymi firmami (choć moim zdaniem to świadczy o Drupalu jako poważnym graczu na rynku Business i Enterprise) czy chociażby możliwość w końcu przyśpieszenia Drupala Varnishem, który przez nieprzemyślaną metodę obsługi ciasteczek w D6 nie mógł praktycznie nic cachować?
A czemu skoro pojawił się już pasek u góry to nie tak fajny, ładny i przyjazny jak ten z Buzzr? Dlaczego nikt nie wpadł na pomysł nowego procesu instalacyjnego (takiego jak ten z Buzzr) czy uproszczenia do bólu tak podstawowych akcji jak zmiana podstawowych elementów strony (jak ten w Buzzr).
Do tej pory dzieliłem CMSy nad banalnie prostego Wordpress-a i zaawansowanego Drupala. Chłopaki z Lullabot pokazali, że można genialnie pogodzić ogień z wodą. Buzzr moim zdaniem swoją prostotą bije na głowę Wordpressa równocześnie posiadając wszystkie aspekty potęgi jaką dysponuje Drupal.
Mam nadzieję, że Drupal wiele nauczy się od Buzzr i postawi w końcu na "look and feel", które w Drupalu wciąż boleje i jest toporne.
Top 3 look & feel & simple usability & user friendly
Geniusz developerów Drupala i ich kunszt w pisaniu bijącego swoją epokę kodu w PHP oraz prostata bijąca na głowę Wordpressa... Lepiej nikt nie mógł tego wymyśleć.
Zrobiła na mnie ogromne wrażenie. Buzzr to frontend zbudowany na Drupalu 6. Szalenie podoba mi się jego "Wordpressowość". W końcu coś przyjaznego, z ikonkami. Dzięki silnemu wykorzystaniu Drag&Drop oraz podzieleniu wszystkiego na kroki można naprawdę w genialnie prosty sposób konfigurować witrynę. Pomysły chłopaków z Lullabot uważam wręcz za rewelacyjne a wykonanie za naprawdę dobre.
Drupal 7 koncentruje siły developerów głównie na poprawianiu i porządkowaniu.
Dużo pracy zostało włożone w usunięcie pewnych niewygodnych funkcji obsługi plików. Wiele hooków posiada swoje bardziej wyspecjalizowane wersje. Niektóre ogólne zostały podzielone na kilka miejszych (tak np. hook_node_api czy hook_form_alter) inne zaczęły żyć własnym życiem (weźmy choćby hook_schema).
Drupal 7 korzysta już z PDO więc developerzy nie muszą się już martwić o implementowanie driverów do baz danych - będą obsługiwać ich tyle ile PDO obsłuży. API bazodanowe w ogóle zostało znacznie usprawnione. W końcu można w Drupalu korzystać z transakcji a nawet tabele w bazie MySQL tworzą się jako InnoDB.
To wszystko pięknie, ale odczują to raczej developerzy modułów (ja odczułem i muszę powiedzieć, że wprowadzone zmiany są naprawdę fantastyczne), ale nie zwykli użytkownicy (obecnie D7 i tak jest wolniejszy od D6). Właśnie tutaj zastanawiam się co jest grane.
Buzzr to ewidentna rewolucja. I moim zdaniem genialna rewolucja. Rozumiem, że D7 woli iść drogą ewolucji. Wiele funkcjonalności zewnętrznych modułów zostało wessane do samego Drupala. Na pewno pozwoli to lepiej je zintegrować, zrobić większy porządek.
Tak jak Drupal 6 ukierunkowywał się na nody tak Drupal 7 ukierunkowuje się na pola. Wygląda to jakby D7 miał wbudowane CCK i jest w tym dużo prawdy bo D7 znaczną część CCK wciągnął do siebie.
Nowinki znowu idą w stronę zaawansowanych technologii i performance. Bo kto dzisiaj wykorzysta wsparcie Drupala dla RDF poza naprawdę świadomymi firmami (choć moim zdaniem to świadczy o Drupalu jako poważnym graczu na rynku Business i Enterprise) czy chociażby możliwość w końcu przyśpieszenia Drupala Varnishem, który przez nieprzemyślaną metodę obsługi ciasteczek w D6 nie mógł praktycznie nic cachować?
A czemu skoro pojawił się już pasek u góry to nie tak fajny, ładny i przyjazny jak ten z Buzzr? Dlaczego nikt nie wpadł na pomysł nowego procesu instalacyjnego (takiego jak ten z Buzzr) czy uproszczenia do bólu tak podstawowych akcji jak zmiana podstawowych elementów strony (jak ten w Buzzr).
Do tej pory dzieliłem CMSy nad banalnie prostego Wordpress-a i zaawansowanego Drupala. Chłopaki z Lullabot pokazali, że można genialnie pogodzić ogień z wodą. Buzzr moim zdaniem swoją prostotą bije na głowę Wordpressa równocześnie posiadając wszystkie aspekty potęgi jaką dysponuje Drupal.
Mam nadzieję, że Drupal wiele nauczy się od Buzzr i postawi w końcu na "look and feel", które w Drupalu wciąż boleje i jest toporne.
Top 3 look & feel & simple usability & user friendly
- Buzzr
- Wordpress
- Drupal
Geniusz developerów Drupala i ich kunszt w pisaniu bijącego swoją epokę kodu w PHP oraz prostata bijąca na głowę Wordpressa... Lepiej nikt nie mógł tego wymyśleć.
Friday, December 4, 2009
Radość z programowania
Dzisiaj uświadomiłem sobie, że największą radość z programowania czerpię pisząc w C. Sam nie wiem dlaczego. Początkowo myślałem, że może największą radość czerpie się z programowania w języku, który jako pierwszy się poznało, jednak, w moim przypadku wcześniej był Pascal. Więc to nie to.
C było językiem, który miałem wprowadzony na początku studiów, wiele rzeczy się w nim pisało: obsługa MPI i MPI2, współbiegi, poznawanie C++ ... same miłe wspomnienia związane z fascynacją nowymi technologiami i technikami. Może stąd sentyment.
Programowanie w C czy C++ uważam za swojego rodzaju kunszt, Python czy Ruby służą mi raczej jako narzędzia do wykonania jakiś prostych zadań.
Dlatego, choć może to wydać się dziwne, książką, którą kupię w najbliższym czasie będzie pewnie właśnie książka o programowaniu w gołym C i chyba właśnie Jej wertowanie sprawi mi szaloną radość :) Brakuje mi do tego jeszcze pasji C++ grębosza i Stroustrupa :) i voila!
C było językiem, który miałem wprowadzony na początku studiów, wiele rzeczy się w nim pisało: obsługa MPI i MPI2, współbiegi, poznawanie C++ ... same miłe wspomnienia związane z fascynacją nowymi technologiami i technikami. Może stąd sentyment.
Programowanie w C czy C++ uważam za swojego rodzaju kunszt, Python czy Ruby służą mi raczej jako narzędzia do wykonania jakiś prostych zadań.
Dlatego, choć może to wydać się dziwne, książką, którą kupię w najbliższym czasie będzie pewnie właśnie książka o programowaniu w gołym C i chyba właśnie Jej wertowanie sprawi mi szaloną radość :) Brakuje mi do tego jeszcze pasji C++ grębosza i Stroustrupa :) i voila!
Friday, November 27, 2009
PHPize 5.3.1 i --prefix=""
Od kilku dni tworzę high-end webstack dla pewnego rozwiązania działającego na systemie opensolaris. W związku z tym musiałem skompilować ręcznie również PHP i modułów do niego.
W trakcie zacząłem dostawać różne dziwne błędy. Zacząłem szukać po forach, bugtrackach, forach dyskusyjnych... Problem objawiał się komunikatami błedu "sed-a" podczas uruchamiania skryptu phpize dla XCache. Wyglądało to mniej więcej tak:
Problem okazała się trywialny. Podczas kompilacji podałem przełącznik --prefix="". Z jakiś przyczyn PHP zamiast wstawić do skryptu phpize prefix pusty to w ogóle stwierdziło, że go nie potrzebuje i nie stworzyło takiej zmiennej w bashu przez co wyrażenie regularne podane jako parametr seda było puste i reszta już sama ładnie się sypała. Teraz, po podaniu wartości prefix, wszystko zdaje się ładnie działać:)
W trakcie zacząłem dostawać różne dziwne błędy. Zacząłem szukać po forach, bugtrackach, forach dyskusyjnych... Problem objawiał się komunikatami błedu "sed-a" podczas uruchamiania skryptu phpize dla XCache. Wyglądało to mniej więcej tak:
PHP Api Version: 20090626
Zend Module Api No: 20090626
Zend Extension Api No: 220090626
First RE may not be null
autoheader: error: AC_CONFIG_HEADERS not found in configure.in
Problem okazała się trywialny. Podczas kompilacji podałem przełącznik --prefix="". Z jakiś przyczyn PHP zamiast wstawić do skryptu phpize prefix pusty to w ogóle stwierdziło, że go nie potrzebuje i nie stworzyło takiej zmiennej w bashu przez co wyrażenie regularne podane jako parametr seda było puste i reszta już sama ładnie się sypała. Teraz, po podaniu wartości prefix, wszystko zdaje się ładnie działać:)
Tuesday, November 24, 2009
Ruby on V8, Python on V8? Koniec ery JavaScript?
To nieźle zabiło mi klina. Od tygodnia trafiam na linki związane z odpaleniem jakieś skryptu napisanego w Pythonie czy Ruby na V8.
Ruby on V8
Binding Python to V8
PyV8
Projekty wyglądają raczej na próby i eksperymenty niż realnie zarysowującą się perspektywę wykorzenienia JavaScript. To jednak dobry znak. Wiadomo - V8 pisane jest z myślą o zwiększeniu wydajności JS i jakby "pod JS" dlatego inne języki mogą sobie radzić na tej wirtualnej maszynie różnie, raz znacznie lepiej innym razem gorzej, jednak sam fakt istnienia wirtualnej maszyny w przeglądarce, uświadomienie sobie tego i próby odpalenia tam współczesnych dzisiejszemu światu języków programowania daje nadzieję na przyszłość.
Nie potrafię opisać emocji jakimi napawa mnie myśl wykorzystywania pQuery albo rQuery :) w kombinacji z genialną składnią Pythona czy klasami Rubego. Może dla naszych dzieci
będzie już czymś normalnym:) Pożyjemy zobaczymy! Trzymam kciuki za eksperymenty i żywię głęboką nadzieję na prezentowany w tym wpisie obrót spraw!
Ruby on V8
Binding Python to V8
PyV8
Projekty wyglądają raczej na próby i eksperymenty niż realnie zarysowującą się perspektywę wykorzenienia JavaScript. To jednak dobry znak. Wiadomo - V8 pisane jest z myślą o zwiększeniu wydajności JS i jakby "pod JS" dlatego inne języki mogą sobie radzić na tej wirtualnej maszynie różnie, raz znacznie lepiej innym razem gorzej, jednak sam fakt istnienia wirtualnej maszyny w przeglądarce, uświadomienie sobie tego i próby odpalenia tam współczesnych dzisiejszemu światu języków programowania daje nadzieję na przyszłość.
Nie potrafię opisać emocji jakimi napawa mnie myśl wykorzystywania pQuery albo rQuery :) w kombinacji z genialną składnią Pythona czy klasami Rubego. Może dla naszych dzieci
<script src="script.rb" type="text/ruby"></script>
<script src="script.py" type="text/python"></script>
będzie już czymś normalnym:) Pożyjemy zobaczymy! Trzymam kciuki za eksperymenty i żywię głęboką nadzieję na prezentowany w tym wpisie obrót spraw!
Thursday, November 19, 2009
Wrażenia ze spotkania "Wprowadzenie do języka Scala"
Właśnie wróciłem z Uniwersytetu Gdańskiego gdzie uczestniczyłem w spotkaniu Trójmiejskiego Java User Group. Prelegentem był Łukasz Kuczera.
Idąc na spotkania miałem wobec niego ogromne oczekiwania. Liczyłem na to, że "ktoś nauczy mnie w końcu Scali" i "nie będę musiał się przedzierać przez 'Programming in Scala'". Jeszcze przed wejściem byłem mile zaskoczony gdy na korytarzu przed audytorium zobaczyłem osobą wertującą ową książkę.
Na samym początku w kilku słowach została omówiona historia języka, jego twórców oraz to jak ich doświadczenie z Javą wpłynęło na kształt oraz możliwości Scali. Po tym wstępie autor zaprezentował hierarchię klas w Scali oraz dostępne ad hoc metody i funkcje. Pokaz możliwości języka rozpoczął się od przykładowej implementacji klasy Rational. Prelegent skupił się na: używaniu metod klasy jak operatorów, wykorzystaniu funkcji require oraz stworzeniu konwertera intToRational. W między czasie przewijał się wątek funkcyjności Scali - chociaż pokazana została typowo od strony obiektowej.
W dalszej kolejności zostały zaimplementowane kolejki - z wykorzystaniem klas abstrakcyjnych, a zaraz po nich przyszła kolej na traitsy, z pokazaniem możliwości ich sekwencyjnego wywoływania. Nie zabrakło też przykładu implementacji Aktorów.
Konferencja była poprowadzona bardzo chaotycznie. Było to chyba winą tego iż "starano się przedstawić wszystko", zamiast skupić się omówić kilka interesujących fragmentów. Sprawozdawca wciąż skakał z tematu na temat, miotając się, jakby nie mogąc zdecydować o czym opowiedzieć (a o czym nie (sic!)).
Ponieważ spotkanie było dla członków JUGu, co krok ktoś (czy to prowadzący,czy ktoś z audytorium) próbował odnieść się do Javy. Porównania były czasem mniej, czasem bardziej trafne.
To co najbardziej mnie zaciekawiło to doświadczenia prelegenta z użyciem Scali w środowisku produkcyjnym. Przepisując na Scalę projekt, napisany wcześniej w Java, otrzymał on 5 MB (tak dokładnie - megabajtowy) Applet! Rozmiar pliku był zdeterminowany zawarciem w nim - poza kodem - również całego środowiska Scala :) (wszak przeciętnie użytkownik ma po swojej stronie tylko Javę). Po odnalezieniu metody minimalizacji jego rozmiaru (zmalał do 300 KB - mniejszy niż w przypadku Java) okazało się, że metoda zawodzi w przypadku używania Server Pages (jednak nie jestem do końca pewien czy dokładnie o tą technologię chodziło). Po obejściu problemu zaczęto dopisywać fragmenty kodu z użyciem Swinga. Tutaj jednak projekt został zawieszony. Nie udało się zmusić Scali do rysowania po elemencie canvas. Całość została przepisana ponownie do Javy. Jak wspomina sprawozdawca mogła to być wina po stronie teamu - jednak nie było czasu szukać rozwiązania i przyczyn problemu.
Ostatecznie spotkanie zakończyło się chwilę przed 19:30. Osobiście oceniam je jako bardzo owocne:) Po prelekcji miałem okazję zamienić kilka słów z autorem wykładu:) Bardzo ucieszyła mnie ogromna pasja i optymistyczne nastawienie do Scali;) Zostałem nawet podwieziony do domu:] Osobiście zastanawiam się czy samemu nie przygotować serii wykładów na ten temat - zobaczymy:)
P.S. Pomimo krytycznej oceny autor wpisu zna realia mieszanki adrenaliny i audytorium liczącego kilkadziesiąt osób i wie z jak wielkim stresem wiąże się stanie "po drugiej stronie". Dodatkowo prelegent poinformował o swoim nie najlepszym samopoczuciu - i przeprosił za ewentualne, wynikające z tego, komplikacje.
Idąc na spotkania miałem wobec niego ogromne oczekiwania. Liczyłem na to, że "ktoś nauczy mnie w końcu Scali" i "nie będę musiał się przedzierać przez 'Programming in Scala'". Jeszcze przed wejściem byłem mile zaskoczony gdy na korytarzu przed audytorium zobaczyłem osobą wertującą ową książkę.
Na samym początku w kilku słowach została omówiona historia języka, jego twórców oraz to jak ich doświadczenie z Javą wpłynęło na kształt oraz możliwości Scali. Po tym wstępie autor zaprezentował hierarchię klas w Scali oraz dostępne ad hoc metody i funkcje. Pokaz możliwości języka rozpoczął się od przykładowej implementacji klasy Rational. Prelegent skupił się na: używaniu metod klasy jak operatorów, wykorzystaniu funkcji require oraz stworzeniu konwertera intToRational. W między czasie przewijał się wątek funkcyjności Scali - chociaż pokazana została typowo od strony obiektowej.
W dalszej kolejności zostały zaimplementowane kolejki - z wykorzystaniem klas abstrakcyjnych, a zaraz po nich przyszła kolej na traitsy, z pokazaniem możliwości ich sekwencyjnego wywoływania. Nie zabrakło też przykładu implementacji Aktorów.
Konferencja była poprowadzona bardzo chaotycznie. Było to chyba winą tego iż "starano się przedstawić wszystko", zamiast skupić się omówić kilka interesujących fragmentów. Sprawozdawca wciąż skakał z tematu na temat, miotając się, jakby nie mogąc zdecydować o czym opowiedzieć (a o czym nie (sic!)).
Ponieważ spotkanie było dla członków JUGu, co krok ktoś (czy to prowadzący,czy ktoś z audytorium) próbował odnieść się do Javy. Porównania były czasem mniej, czasem bardziej trafne.
To co najbardziej mnie zaciekawiło to doświadczenia prelegenta z użyciem Scali w środowisku produkcyjnym. Przepisując na Scalę projekt, napisany wcześniej w Java, otrzymał on 5 MB (tak dokładnie - megabajtowy) Applet! Rozmiar pliku był zdeterminowany zawarciem w nim - poza kodem - również całego środowiska Scala :) (wszak przeciętnie użytkownik ma po swojej stronie tylko Javę). Po odnalezieniu metody minimalizacji jego rozmiaru (zmalał do 300 KB - mniejszy niż w przypadku Java) okazało się, że metoda zawodzi w przypadku używania Server Pages (jednak nie jestem do końca pewien czy dokładnie o tą technologię chodziło). Po obejściu problemu zaczęto dopisywać fragmenty kodu z użyciem Swinga. Tutaj jednak projekt został zawieszony. Nie udało się zmusić Scali do rysowania po elemencie canvas. Całość została przepisana ponownie do Javy. Jak wspomina sprawozdawca mogła to być wina po stronie teamu - jednak nie było czasu szukać rozwiązania i przyczyn problemu.
Ostatecznie spotkanie zakończyło się chwilę przed 19:30. Osobiście oceniam je jako bardzo owocne:) Po prelekcji miałem okazję zamienić kilka słów z autorem wykładu:) Bardzo ucieszyła mnie ogromna pasja i optymistyczne nastawienie do Scali;) Zostałem nawet podwieziony do domu:] Osobiście zastanawiam się czy samemu nie przygotować serii wykładów na ten temat - zobaczymy:)
P.S. Pomimo krytycznej oceny autor wpisu zna realia mieszanki adrenaliny i audytorium liczącego kilkadziesiąt osób i wie z jak wielkim stresem wiąże się stanie "po drugiej stronie". Dodatkowo prelegent poinformował o swoim nie najlepszym samopoczuciu - i przeprosił za ewentualne, wynikające z tego, komplikacje.
Friday, November 13, 2009
Scala - język ok, ale kto wykorzysta jej potencjał?
Z każdym dniem lepiej poznając Scalę dochodzę do wniosku, że to język programowania o fantastycznym potencjale i możliwościach. Jednak wraz z kolejnymi mechanizmami tego języka programowania zastanawiam się kto dziś (a jeżeli nie dziś to kiedy) wykorzystam ten kolosalny, drzemiący w języku potencjał?
O ile C, C++ czy inne języki programowania odbieram jako odpowiedź na rosnące potrzeby programistów o tyle scala jest dla mnie czymś "zadanym". Rozumiem, że PHP było odpowiedzią na braki w językach do tworzenia witryn internetowych, a C++ popularyzacją obiektowego stylu projektowania, jednak na co odpowiedzią jest Scala?
Ilość usprawnień i wprowadzonych w niej koncepcji mnie osobiście, jako programistę, przerasta. Ogromny potencjał jakim emanuje sprawia, że zamiast skupiać się na problemie i jego rozwiązaniu (z użyciem języka programowania) zastanawiam się jak tego języka programowania użyć wymiernie do jego możliwości. Scala po prostu obecnie mnie przerasta. Jest dla mnie trochę jak objawienie - nie rozwiązanie problemów z obecnymi językami programowania (poza ułomną lambdą Python w 100% mi wystarcza).
Jestem pełen podziwu i szacunku wobec geniuszu twórców tego języka i zastosowanych w nim rozwiązań:)
O ile C, C++ czy inne języki programowania odbieram jako odpowiedź na rosnące potrzeby programistów o tyle scala jest dla mnie czymś "zadanym". Rozumiem, że PHP było odpowiedzią na braki w językach do tworzenia witryn internetowych, a C++ popularyzacją obiektowego stylu projektowania, jednak na co odpowiedzią jest Scala?
Ilość usprawnień i wprowadzonych w niej koncepcji mnie osobiście, jako programistę, przerasta. Ogromny potencjał jakim emanuje sprawia, że zamiast skupiać się na problemie i jego rozwiązaniu (z użyciem języka programowania) zastanawiam się jak tego języka programowania użyć wymiernie do jego możliwości. Scala po prostu obecnie mnie przerasta. Jest dla mnie trochę jak objawienie - nie rozwiązanie problemów z obecnymi językami programowania (poza ułomną lambdą Python w 100% mi wystarcza).
Jestem pełen podziwu i szacunku wobec geniuszu twórców tego języka i zastosowanych w nim rozwiązań:)
Wednesday, October 28, 2009
Scala - znak równości a wartość zwracana przez funkcję
Przeczytałem dziś o ciekawej własności, może raczej pewnym niuansie, związanym z typem zwracanym przez funkcje w Scali. Deklarując funkcję podajemy zwykle na końcu zwracany przez nią typ.
To co mnie zdziwiło to typ Unit. Używamy go gdy zadaniem funkcji, którą tworzymy nie jest zwrócenie nowej wartości, ale jej efekt uboczny. Efekt uboczny rozumiany jako "funkcja powinna zwrócić wartość, ale jeżeli tego nie robi to znaczy, że wszystko co robi jest jej efekt ubocznym". W tym przypadku efektem ubocznym funkcji (która z natury powinna coś zwrócić) jest wyświetlenie parametru na ekranie.
Tak więc gdy gdy typem zwracanym przez funkcję jest Unit wiemy, że celem funkcji nie jest zwrócenie nam jakiejś wartości, ale wykonanie innych zadań. To co mnie zaciekawiło to fakt iż pominięcie znaku równości przy deklarowaniu funkcji oznacza domyślnie "zwracam Unit. Powstaję tylko dla moich efektów ubocznych" zaś jego podanie oznacza "zwracam jakąś wartość".Co łatwo zobaczyć :)
Podoba mi się takie rozróżnienie :)
def pokaz(a: Int): Unit = {
println(a)
}
To co mnie zdziwiło to typ Unit. Używamy go gdy zadaniem funkcji, którą tworzymy nie jest zwrócenie nowej wartości, ale jej efekt uboczny. Efekt uboczny rozumiany jako "funkcja powinna zwrócić wartość, ale jeżeli tego nie robi to znaczy, że wszystko co robi jest jej efekt ubocznym". W tym przypadku efektem ubocznym funkcji (która z natury powinna coś zwrócić) jest wyświetlenie parametru na ekranie.
Tak więc gdy gdy typem zwracanym przez funkcję jest Unit wiemy, że celem funkcji nie jest zwrócenie nam jakiejś wartości, ale wykonanie innych zadań. To co mnie zaciekawiło to fakt iż pominięcie znaku równości przy deklarowaniu funkcji oznacza domyślnie "zwracam Unit. Powstaję tylko dla moich efektów ubocznych" zaś jego podanie oznacza "zwracam jakąś wartość".Co łatwo zobaczyć :)
scala> def funkcja() = { "String" }
funkcja: ()java.lang.String
scala> def funkcja() { "String" }
funkcja: ()Unit
Podoba mi się takie rozróżnienie :)
Thursday, October 22, 2009
OpenSolaris - zmiana powłoki użytkownika
Niestety w OpenSolaris nie zaznamy polecenia chsh. Możemy jednak pomóc sobie:
usermod -s /ścieżka/do/powłoki nazwa_użytkownika
OpenSolaris - rozpakowywanie tar.gz
Od niedawna mam styczność z systemem OpenSolaris. Od czasu do czasu będę publikował jak coś w nim zrobić.
Dzisiaj zastanawiałem się jak rozpakować w nim plik tar.gz Oto metoda dla ciekawskich.
Dzisiaj zastanawiałem się jak rozpakować w nim plik tar.gz Oto metoda dla ciekawskich.
gunzip < plik.tar.gz | tar xvf -
Monday, October 19, 2009
Trendy polskie a praca na świeci
Nie wiem co mnie dziś tknęło ale postanowiłem sprawdzić pewną rzecz.
Przeczesując zasoby polskiej sieci, w poszukiwaniu informacji na temat tworzenia witryn internetowych, trafiamy głównie na kursy Ruby On Rails albo Django. Dzisiaj postanowiłem zobaczyć jak sprawa się ma jeżeli chodzi o "jobtrends" na świecie. Wyniki z serwisu Indeed.com/jobtrends poniżej.
O ile popularność Railsów mnie nie zszokowała (może co najwyżej jej skala) o tyle fakt iż Drupal stoi znacznie wyżej niż dziesiątki razy opisywany w polskiej sieci Django - mocno mnie zdziwiło. Czyżby Django przegrywało w świecie biznesu z Drupalem? Może to jakaś wskazówka? Szczególnie, jeżeli planujemy naszą przyszłość w perspektywie pracy programisty. I jak sytuacja ta ma się do polskich warunków pracy? Pytania pozostawiam bez odpowiedzi.
Thursday, October 8, 2009
Trywialny błąd we wtyczce Chrome Frame
Właśnie przygotowuję wykłady na Politechnikę i chciałem dzisiaj pokazać Chrome Frame. Zawiodłem się gdy wtyczka zamiast pokazać ramkę z propozycją instalacji dodatku zawiesiła na moment Internet Explorer a po chwili wyrzuciła błąd. Ostatecznie problem okazał się banalny:
W skrypcie CFInstall.js linia 173 wyglądała:
var installUrl = '//www.google.com/chromeframe';
zamiast
var installUrl = 'http://www.google.com/chromeframe';
Po zmianie tego odnośnika :) zaczęło działać :) Mam nadzieję, że komuś się przyda.
Monday, September 28, 2009
Jakość a czas pisania artykułów
Poczyniłem dzisiaj refleksję dotyczącą jakości a czasu pisania artykułów.
Miło mi, kiedy gro osób jest zniecierpliwionych i oczekuje kolejnej części kursu, serii artykułów. Jednak równocześnie presja skłania ku pośpiechowi. A na tym cierpi jakość. Być może są ludzie zdolni, którzy piszą artykuł od razu w formie w jakiej chcą go zobaczyć. W moim przypadku mam wizję, ale aby ją osiągnąć muszę najpierw napisać to co chcę zawrzeć. Później trwa przeredagowywanie. I ten właśnie proces jest długotrwały. Pozmieniam szyk zdań, część informacji wyjmę z tekstu i ujmę w formie tabelki, wzmiankę o innych pominę. Następnie potrzebuję tygodnia, w którym myślę jak poprawić ten tekst dalej, co jeszcze jest w nim zbyt skomplikowane ...
Po tygodniu siadam i wprowadzam kolejne poprawki itd... Czasami dobry tekst powstaje dwa miesiące. Oczywiście - napisany jest w 2 dni, ale gotowy dopiero po 60-70.
Takie życie:) Staram się jak mogę. Jak widać wrodzonego talentu nie mam. Chociaż zdarza mi się, że jakiś temat jest "na fali". W takim sensie, że mnie obecnie pasjonuje i pochłania. Wtedy artykuły, prawie w finalnej formie, wychodzą jak z rękawa. Ale wtedy jest kilka dni nie odchodzenia od komputera i czasochłonnego spisywania myśli - na co często nie mogę sobie już pozwolić (studia, praca). No i tyle :]
Pozdrawiam!
Friday, September 4, 2009
I(IS)nwazja (aktualizacja)
Dzisiaj grzecznie od rana chcę siąść do kolejne częściu kursu developerów Drupala. Odpalam sobie Chrome i wchodzę na witrynę http://localhost/drupal7/admin/structure/modules a tu nagle
Szybkie spojrzenie na localhost
I wszystko jasne. Mój Apache został brutalnie skazany przez upgrady Windows na banicję. Szkoda tylko, że nikt mnie o tym nie poinformował. To jeden z tych przypadków "przecież wczoraj działało" i z jakiś przyczyn nagle moja Vista stwierdziła, że w sumie to nie ważne, że postawiłem sobie na porcie 80tym serwer Apache bo przecież ona wie lepiej co jest dla mnie lepsze i po cichu w upgradach uszczęśliwi mnie IIS7.
Szybkie spojrzenie na localhost
I wszystko jasne. Mój Apache został brutalnie skazany przez upgrady Windows na banicję. Szkoda tylko, że nikt mnie o tym nie poinformował. To jeden z tych przypadków "przecież wczoraj działało" i z jakiś przyczyn nagle moja Vista stwierdziła, że w sumie to nie ważne, że postawiłem sobie na porcie 80tym serwer Apache bo przecież ona wie lepiej co jest dla mnie lepsze i po cichu w upgradach uszczęśliwi mnie IIS7.
To jest tylko serwerek domowy, developerski. Nie ma więc o co płakać, ale jeżeli ktoś miałby taki am myk w środowisku produkcyjnym - to byłaby to masakra. Zaraz spróbuję wyłączyć dziada i wrócić do pracy, ale MS nie zapłaci mi za stracony czas.
Problem powodowały upgrady "Apple Software Update" (które przyszły wraz z Bonjour) nie mechanizmy Microsoftu.
Thursday, August 27, 2009
Drupal 7 zaczął maleć
Przez ostatnie kilka tygodni Drupal 7 rósł. Dosłownie Od około 1,54 MB wzrósł do 1,95 MB. Wszystko posuwało się do przodu. Aż do "teraz". Jakiś czas temu zauważyłem spadek, który na dzień dzisiejszy zatrzymał się na poziomie 1,91 MB. Czyżby przyszedł czas na usunięcie starych funkcji, przeczyszczenie niekompatybilnego kodu i "refactoring size"? Ciekawe. Obserwując ten, jakże świeży trend, można wnioskować, że został ukończony pewien duży etap. Pytanie, czy to już koniec? Drupal 7 ma zostać wstępnie wydany najpierw "dla firm", dopiero później usłyszy o nim świat. Kto wie, czy za kuluarami nie nastał już właśnie ten moment? Z jednej strony ilość ticketów w bugtrackerze sugeruje iż przed developerami jeszcze długa droga. Nikt jednak nie wie nic "na pewno" a niejasna i niezgłębiona myśl releaserów Drupala nie pozwala przeniknąć się i odkryć etapu, na którym znajduje się projekt. Ciekawe.
Monday, August 24, 2009
Myśl na dziś - konsola i GUI
Instalując Linuksa spędzasz trzy dni na dostosowaniu środowiska graficznego do swoich upodobań.
Instalując Windowsa spędzasz trzy dni na dostosowaniu linii poleceń do swoich upodobań.
P.S. Przy czym w pierwszym konsola działa odrazu tak jak chcesz a w drugim akceptujesz środowisko graficzne takie jakim jest.
Autor zdaje sobie sprawę, że stwierdzenia są bardzo ogólne i nie odnoszą się do większości użytkowników systemu są to tylko subiektywne odczucia spowodowane dzisiejszym dniem w pracy.
Instalując Windowsa spędzasz trzy dni na dostosowaniu linii poleceń do swoich upodobań.
P.S. Przy czym w pierwszym konsola działa odrazu tak jak chcesz a w drugim akceptujesz środowisko graficzne takie jakim jest.
Autor zdaje sobie sprawę, że stwierdzenia są bardzo ogólne i nie odnoszą się do większości użytkowników systemu są to tylko subiektywne odczucia spowodowane dzisiejszym dniem w pracy.
Wednesday, July 29, 2009
Python i Ruby w jednym stali domu ...
... 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.
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 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.
Saturday, June 20, 2009
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.
Thursday, June 18, 2009
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" ;]
Wednesday, June 17, 2009
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.
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ć.
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.
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ń.
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ć.
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ń.
Thursday, May 28, 2009
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.
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ę.
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 !
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.
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!
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!
Tuesday, May 19, 2009
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 !
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 !
Test nowego algorytmu kompresji zipx w WinZip 12
Dawno już w kompresję się nie bawiłem a informacja o nowym algorytmie wzbudziła moje zainteresowanie z kilku powodów. Po pierwsze ponieważ obecnie temat mam omawiany w ramach kilku wykładów prowadzonych na uczelni, po drugiej ponieważ mam sentyment do WinZipa. Głównie ze względu na sympatyczny interfejs.
Na co dzień jednak używam 7zip. Przyszedł czas aby na chwilę zagościło u mnie i płatne oprogramowanie (Windowsa nie licząc). Test nie będzie bardzo wyszukany - od kompresja kilku plików starą i nową metodą a następnie przyjrzenie się wynikom.
Na wstępie już podczas instalacji jesteśmy pytani o domyślną metodę kompresji oraz o zaletach nowej, zipx, ujawniającej się podczas kompresowania obrazów jpeg.
Podczas instalacji jesteśmy pytani o domyślną metodę kompresji.
Zanim jednak testy pewna uwaga. Wszystko wykonywałem na Windows 7. Aby było "wygodniej" poprosiłem WinZipa w opcjach (po instalacji) aby ładnie zintegrował się jako "explorer extension" w celu ułatwienia mi tworzenia archiwów. Nie wyobrażacie sobie jaki byłem zdziwiony gdy - opcja nie do końca działała. Konkretnie: gdy wywołałem menu kontekstowe dla pliku na pulpicie miałem podmenu Winzip i możliwość dodania pliku do archiwum. WinZip nie dał sobie jednak rady z Windowsowym "Libraries" z którego korzystam bardzo często aby uzyskać dostęp do Obrazków, Muzyki czy właśnie Dokumentów - i tutaj niestety menu się nie pojawiało. W tym samym folderze, wywołanym z pełną ściężką (C:\Users\ itd...) - wszystko działało ok :)
Można byłoby przemilczeć temat - wszak Windows 7 jeszcze nie wyszedł - ale piszę o tym gdyż darmowy 7-zip w przeciwieństwie do WinZip radzi sobie tutaj znakomicie. Brawo !
Przejdźmy do testów. W tym celu przygotowałem sobie foldery z 4 rodzajami danych. Dokumenty: tutaj głównie były pliki PDF i kilka odt. Zazwyczaj prezentacje mojej roboty lub jakieś z wykładów z uczelni więc nafaszerowane sporą ilością grafiki, muzyka: 10 plików mp3 średnio po 30 minut każdy z kazaniami ks. Piotra Pawlukiewicza, obrazki: polskie tapety z Windows 7 każdy o wymiarach 1920x1200 w sumie 5 sztuk i 7 skryptów Pythona, niewielkich programików po kilka kilkaset kibibajtów. Wyniki malują się następująco.
Nie da się ukryć, że kompresja zipx dała sobie radę znacznie lepiej. Należy jednak wspomnieć, że we wszystkich przypadkach użycie tej metody było bardzo czasochłonne i tworzenie archiwum trwało zdecydowanie dłużej. Różnica w czasie była tak duża że aż rzucająca się w oczy. Po analizie kompresji poszczególnych plików widać, że zyskaliśmy głównie na zwiększonym stopniu upakowania dużych plików - małe były pakowane tak samo. Jest to pierwszy sygnał mogący świadczyć o tym iż przy nowej metodzie zyskujemy pakując mniej większych porcji danych niż więcej mniejszych. Może być to też kwestia faktu iż w tych plikach PDF występowało więcej obrazków niż w innych chociaż naprawdę ciężko mi to określić - to tylko jakaś propozycja hipotezy. Skąd akurat taki pomysł ? Zobaczycie w następnym teście.
To tutaj zipx ma osiągać lepsze wyniki i trzeba przyznać, że zipx pokazał pazur. O ile w przypadku dokumentów różnica wynosiła 1% na korzyść pierwszego o tyle tutaj - 18%, robi wrażenie. Z jednej strony można się domyślać, że tapety Microsoftu nie są jakoś specjalnie skompresowane jako JPGi do użytku na ekranach dużej rozdzielczości jednak mówimy o kompresji bezstratnej !. Wszak po rozpakowaniu mamy te same obrazki - bez pogorszenia jakości. Sprawne algorytmy kompresji obrazu: jedne komercyjne, inne darmowe, są znane nie od wczoraj. Wiele mądrych głów zajmowało się tym zagadnieniem i wiele w tej dziedzinie osiągnięto. Domyślam się, że to co tutaj obserwujemy to po prostu skorzystanie z tych doświadczeń. Dwie "dziedziny kompresji": plików w ogóle i obrazów - łączą siły. Bardzo dobry ruch ! Zobaczmy co dalej.
Analizując powyższe dane można zauważyć, że przy kompresji plików, które upakowują się bardzo słabo albo bardzo dobrze, stosując zipx, zyskujemy i w tym i w tym przypadku 1% na naszą korzyść.
Zipx miał lepiej kompresować obrazy i robi to w rzeczywistości dużo lepiej niż starszy brat. To może niewielka nowość jak na "nowy format kompresji" z krzykliwą literką "x" na końcu jednak zawsze powód do radości i pogratulowania. Algorytm został też poprawiony na oko "w ogóle" gdyż również przy kompresji innego rodzaju formatów zyskujemy ten 1%. Tak więc nigdy nie tracimy na jakości kompresji - kosztem jest jednak przenośność gdyż obecnie archiwum zipx otworzymy wyłącznie za pomocą najnowszego WinZipa. Na razie coś za coś - z biegiem miesięcy kwestia czasu :]
Na co dzień jednak używam 7zip. Przyszedł czas aby na chwilę zagościło u mnie i płatne oprogramowanie (Windowsa nie licząc). Test nie będzie bardzo wyszukany - od kompresja kilku plików starą i nową metodą a następnie przyjrzenie się wynikom.
Na wstępie już podczas instalacji jesteśmy pytani o domyślną metodę kompresji oraz o zaletach nowej, zipx, ujawniającej się podczas kompresowania obrazów jpeg.
Podczas instalacji jesteśmy pytani o domyślną metodę kompresji.
Zanim jednak testy pewna uwaga. Wszystko wykonywałem na Windows 7. Aby było "wygodniej" poprosiłem WinZipa w opcjach (po instalacji) aby ładnie zintegrował się jako "explorer extension" w celu ułatwienia mi tworzenia archiwów. Nie wyobrażacie sobie jaki byłem zdziwiony gdy - opcja nie do końca działała. Konkretnie: gdy wywołałem menu kontekstowe dla pliku na pulpicie miałem podmenu Winzip i możliwość dodania pliku do archiwum. WinZip nie dał sobie jednak rady z Windowsowym "Libraries" z którego korzystam bardzo często aby uzyskać dostęp do Obrazków, Muzyki czy właśnie Dokumentów - i tutaj niestety menu się nie pojawiało. W tym samym folderze, wywołanym z pełną ściężką (C:\Users\ itd...) - wszystko działało ok :)
Można byłoby przemilczeć temat - wszak Windows 7 jeszcze nie wyszedł - ale piszę o tym gdyż darmowy 7-zip w przeciwieństwie do WinZip radzi sobie tutaj znakomicie. Brawo !
Przejdźmy do testów. W tym celu przygotowałem sobie foldery z 4 rodzajami danych. Dokumenty: tutaj głównie były pliki PDF i kilka odt. Zazwyczaj prezentacje mojej roboty lub jakieś z wykładów z uczelni więc nafaszerowane sporą ilością grafiki, muzyka: 10 plików mp3 średnio po 30 minut każdy z kazaniami ks. Piotra Pawlukiewicza, obrazki: polskie tapety z Windows 7 każdy o wymiarach 1920x1200 w sumie 5 sztuk i 7 skryptów Pythona, niewielkich programików po kilka kilkaset kibibajtów. Wyniki malują się następująco.
Dokumenty
Kompresja zip
Kompresja zipx
Nie da się ukryć, że kompresja zipx dała sobie radę znacznie lepiej. Należy jednak wspomnieć, że we wszystkich przypadkach użycie tej metody było bardzo czasochłonne i tworzenie archiwum trwało zdecydowanie dłużej. Różnica w czasie była tak duża że aż rzucająca się w oczy. Po analizie kompresji poszczególnych plików widać, że zyskaliśmy głównie na zwiększonym stopniu upakowania dużych plików - małe były pakowane tak samo. Jest to pierwszy sygnał mogący świadczyć o tym iż przy nowej metodzie zyskujemy pakując mniej większych porcji danych niż więcej mniejszych. Może być to też kwestia faktu iż w tych plikach PDF występowało więcej obrazków niż w innych chociaż naprawdę ciężko mi to określić - to tylko jakaś propozycja hipotezy. Skąd akurat taki pomysł ? Zobaczycie w następnym teście.
Obrazy
Kompresja zip
Kompresja zipx
To tutaj zipx ma osiągać lepsze wyniki i trzeba przyznać, że zipx pokazał pazur. O ile w przypadku dokumentów różnica wynosiła 1% na korzyść pierwszego o tyle tutaj - 18%, robi wrażenie. Z jednej strony można się domyślać, że tapety Microsoftu nie są jakoś specjalnie skompresowane jako JPGi do użytku na ekranach dużej rozdzielczości jednak mówimy o kompresji bezstratnej !. Wszak po rozpakowaniu mamy te same obrazki - bez pogorszenia jakości. Sprawne algorytmy kompresji obrazu: jedne komercyjne, inne darmowe, są znane nie od wczoraj. Wiele mądrych głów zajmowało się tym zagadnieniem i wiele w tej dziedzinie osiągnięto. Domyślam się, że to co tutaj obserwujemy to po prostu skorzystanie z tych doświadczeń. Dwie "dziedziny kompresji": plików w ogóle i obrazów - łączą siły. Bardzo dobry ruch ! Zobaczmy co dalej.
Pliki mp3
Kompresja zip
Kompresja zipx
Skrypt Pythona
Kompresja zip
Kompresja zip
Analizując powyższe dane można zauważyć, że przy kompresji plików, które upakowują się bardzo słabo albo bardzo dobrze, stosując zipx, zyskujemy i w tym i w tym przypadku 1% na naszą korzyść.
Zipx miał lepiej kompresować obrazy i robi to w rzeczywistości dużo lepiej niż starszy brat. To może niewielka nowość jak na "nowy format kompresji" z krzykliwą literką "x" na końcu jednak zawsze powód do radości i pogratulowania. Algorytm został też poprawiony na oko "w ogóle" gdyż również przy kompresji innego rodzaju formatów zyskujemy ten 1%. Tak więc nigdy nie tracimy na jakości kompresji - kosztem jest jednak przenośność gdyż obecnie archiwum zipx otworzymy wyłącznie za pomocą najnowszego WinZipa. Na razie coś za coś - z biegiem miesięcy kwestia czasu :]
Subscribe to:
Posts (Atom)