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.

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

1. Buzzr


2. Wordpress


3. 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ć.

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!

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:

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ć:)

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

<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!

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.

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ń:)