Obecnie prace nad projektem „Profitto” są zawieszone.

Zapraszam za to do tworzącego się serwisu MindPlace, poświęconego biofeedbackowi, relaksacji, radzeniu sobie ze stresem. Pierwsze tematy związane są z biofeedback-iem, czyli czy można za pomocą urządzeń zmierzyć, jaki masz nastrój, jak można na to wpływać i co z tego wynika…

Zapraszam

http://www.mindplace.pl

Zadanie napisania pierwszego „naszego” parsera padło na mnie. Nie będę ukrywał, że z początku uznałem to za pewne wyzwanie. Na szczęście dość szybko znalazłem to czego szukałem – czyli BeautifulSoup. Nazwa dość dziwna, ale o tym później. Wystarczyło kilka chwil (czytaj: wieczorów, gdy choć jeden domownik już śpi ), żeby przy jej użyciu, prosto i przyjemnie uzyskać to czego się chce. Nie będę tu pisał manual’a, ale pokusiłem się o prosty przykład. Załóżmy, że interesuje nas, kto komentował nasze wpisy ma blogu. Voilà:

#-*- coding: UTF-8 -*-

from BeautifulSoup import BeautifulSoup
import urllib

url = "http://blog.profitto.pl/2008/11/wybor-technologii"
soup = BeautifulSoup(urllib.urlopen(url).read())

authors = set() # unikalność
for comment in soup('div',{'class':'cmtinfo'}):
    authors.add(comment.cite.string)

print ', '.join(authors)

Jeśli jeszcze nie czujesz bluesa, to dodam, że BS poradzi sobie z popsutymi znacznikami i konwersją kodowania. Poza tym mamy do dyspozycji całą moc pythona – biblioteki bardzo ułatwiają szybkie rozwiązywanie problemów z przymusem zalogowania się na stronę:

#-*- coding: UTF-8 -*-
# używamy słownika do wypełnienia formularza
from BeautifulSoup import BeautifulSoup
import urllib

url = "http://poczta.profitto.pl"
params =  urllib.urlencode( { 'login':'profitto',
                              'password':'żyrafyWchodząNaSzafy',
                              'hiddenField': 'hidden' } )
soup = BeautifulSoup(urllib.urlopen(url,params).read())
print soup.prettify()

używania tylko najwłaściwszej przeglądarki:

#-*- coding: UTF-8 -*-

from BeautifulSoup import BeautifulSoup
import urllib2

url = "http://www.useragent.org/"
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor())
opener.addheaders=[ ( 'user-agent','NCSA_Mosaic/2.0' ) ]
soup = BeautifulSoup(opener.open(url))
print soup.prettify()

Na koniec dwa słowa o nazwie biblioteki. Brzmi dość dziwnie, ale jakoś przed zabraniem się za pisanie tego tekstu nie wnikałem skąd się wzięła. Nie powiem, że mnie nie natchnęła (fragment kodu: soup = kitchen.getSoup(url)  ). Nie trzeba wiele, by odkryć (mam nadzieje, że nie tylko ja musiałem to odkrywać) – ta nazwa zainspirowana jest utworem Lewis’a Carroll’a Alicja w Krainie Czarów. A dokładnie jest to podmiot liryczny jednej z piosenek - Soup Of The Evening. Zupa na wieczór – niekoniecznie jeden.

Dodatkowa literatura:

• urllib2 – zaginiony podręcznik

Wydawałoby się, że prezenty gwiazdowe znajduje się tylko pod choinką. W czasie jednego ze świątecznych spacerów zauważyłem na mieście pewien intrygujący billboard – jako, że miałem ze sobą aparat uwieczniłem tą chwilę…

Dzisiaj krótszy post i to trochę filozoficznej natury.

Rysując model domenowy dla naszej aplikacji w postaci UML-owego diagramu klas natknąłem się na pewną zagwozdkę. Konkretnie dylemat dotyczył różnic pomiędzy asocjacją, kompozycją a agregacją. Czytając formalne opisy, sprawa wydaje się prosta. Wątpliwości pojawiają się  w przypadku wyboru pomiędzy asocjacją, a jej bardziej specjalizowanym kuzynem – agregacją. Agregacja zgodnie z  definicją reprezentuje asocjację typu „has a”. Jednak rysując już konkretny diagram wybór ten nie jest wcale taki oczywisty: człowiek „subskrybuje” czasopismo (asocjacja), czy też człowiek „ma subskrypcję na” czasopismo (agregacja) – przykłady i dyskusje można by mnożyć bez końca.

Co więcej różnica ta nie ma żadnego przełożenia na kod programu, gdyż zarówno asocjacja, jak i agregacja reprezentowane są w identyczny sposób. Gdzie więc narysować grubą czerwoną linię oddzielającą jedno pojęcie od drugiego, gdy nie dość że z semantycznego punktu widzenia sprawa jest mocno dyskusyjna, to dodatkowo jeszcze wybór takiego a nie innego rodzaju połączenia nie powoduje żadnego rozróżnienia w kodzie? Modelowanie nie powinno być sztuką dla sztuki i taki a nie inny model powinien mieć praktyczne odzwierciedlenie. Zdaje się, że w związku z takimi niejednoznacznościami, przez pewien czas planowano nawet usunąć pojęcie „agregacji” z UML 2.0, finalnie jednak tak się nie stało.

Z kompozycją sprawa jest już dużo prostsza, ponieważ ten rodzaj połączenia dodaje istotną informację, że pewien obiekt może istnieć wyłącznie jako część kompozycji i tym samym cykl jego życia jest zależny od cyklu życia obiektu-kontenera. W przypadku języków nie posiadających garbage collector-a, jak np. C++, będzie to oznaczało, że w trakcie niszczenia obiektu-kontenera, powinny być niszczone obiekty, które on zawiera. W przypadku nowocześniejszych języków, jak np. Java, C#, Python, itp. nie będzie to jednak już tak widoczne – ponieważ tam nie ma potrzeby „ręcznego” zwalniania pamięci.

Konkluzja

Pojęcie kompozycji wydaje się być dość jasno określone, co jednak z dylematem asocjacja vs agregacja? Tutaj skłaniam się ku sugestii Martina Fowler-a: nie używaj agregacji, dopóki nie masz naprawdę dobrego uzasadnienia .

Lektura uzupełniająca:

• JavaRanch FAQ: Association Vs Aggregation Vs Composition
• Association, Composition and Aggregation (OO, Patterns, UML and Refactoring forum at JavaRanch)

Jednym z pytań, które zazwyczaj sobie stawiamy rozpoczynając nowy projekt jest to dotyczące wyboru technologii. Nie inaczej było i tym razem –  każda technologia ma swoje plusy i minusy, swoje specyficzne smaczki, które powodują że dla pewnych zagadnień sprawdza się lepiej lub gorzej. Najlepszego języka/framework-a nie ma i być nie może, z tej prostej przyczyny że każdy zwraca uwagę na inne detale, co innego jest dla niego istotne, tak też framework-i skupiają się na różnych aspektach: szybkości tworzenia, elegancji, wydajności, itd. Pojawienie się idealnego języka/framework-a oznaczałoby koniec rozwoju, stagnację… na szczęście wygląda, że nam to nie grozi. Zadaniem tego postu jest pokazanie na co my zwróciliśmy uwagę i jaka decyzję finalnie podjęliśmy.

W zależności od naszej wiedzy, doświadczeń oraz ilości czasu jaki mamy na podjęcie takiej decyzji możemy podejść do tematu w różny sposób:

• Wybór podyktowany technologiami, które już znamy. Z jednej strony dzięki temu minimalizujemy czas potrzebny na poznanie nowych technologii, minimalizujemy ryzyko wszelkiego rodzaju potyczek technologicznych, bo cześć z nich już stoczyliśmy i znamy gotowe rozwiązania. Z drugiej strony możemy w ten sposób utknąć przy rozwiązaniach, które na chwilę obecną z różnych względów nie są najbardziej optymalne,
• Rozpoznanie bojem. Jedno z bardziej ciekawych i rozwijających podejść do tematu. Wybieramy N najbardziej rokujących naszym zdaniem rozwiązań, a następnie dla każdego z nich wykonujemy mały PoC („Proof of Concept”, nie mylić z „Pirates of the Caribbean” ). Podejście to wymaga jednego założenia: mamy sporo czasu na takie prace, a z tym to już różnie bywa…,
• Zapoznanie się z możliwie szeroką opinią innych ludzi. Możemy więc spędzić kilka wieczorów z Google-em i na podstawie tak ograniczonej ilości informacji podjąć decyzję. Z jednej strony pomysł może wydawać się ryzykowny, bo na temat każdej technologii znajdziemy zarówno psalmy pochwalne jak i posty o przeciwnym zabarwieniu (wystarczy wpisać w google-a wybrany język + sucks, np. „php sucks”). Z drugiej strony przy odpowiedniej dawce przeciwstawnych opinii i odrobinie intuicji, można podjąć naprawdę dobrą decyzję niskim kosztem.

Szranki i konkury¹

Pierwszym moim podejściem było „znana technologia” — miała to być Java, jako że ostatnie kilka lat spędziłem tworząc aplikacje web-owe oparte o ten właśnie język (oczywiście plus framework-i jak Struts, Hibernate, itp.). Rozważałem także dodanie jednego czy dwóch framework-ów, z którymi nie miałem dużych doświadczeń (jak np. Spring), ale generalnie zamierzałem oprzeć się na znanych mi rozwiązaniach.

Jednak prace mimo wszystko nie posuwały się tak szybko, jakbym sobie tego życzył. Przy drugim podejściu, które nastąpiło jakiś czas później postanowiłem poddać weryfikacji swoją wcześniejszą decyzję. Jako, że na nadmiar wolnego czasu raczej nie mogę narzekać, stanęło na rozwiązaniu: „kilka wieczorów z Google-m”. Do szranków stanęły:

• C#
• Java
• PHP
• Python
• Perl
• Ruby

(oczywiście powyższa lista nie zawiera wszystkich dostępnych opcji, a tylko te, które w moim odczuciu były najbardziej rokujące)

Teoretycznie aplikację tego typu można napisać w każdym z wymienionych języków (oraz w sporej ilości niewymienionych), ale jak przychodzi już do pisania trzeba się zdecydować na ten jeden konkretny, który w naszym odczuciu do danego rodzaju aplikacji będzie najodpowiedniejszy. Na początek postanowiłem przyjrzeć się następującym kryteriom:

• otwartość rozwiązania, rozumiana głównie jako otwartość źródeł,
• szybkość tworzenia kodu oraz łatwość jego późniejszego rozwoju i utrzymania,
• popularność danego języka a tym samym łatwość późniejszego pozyskania na rynku developerów posługujących się nim,
• szeroko rozumiana zasobo-żerność i wynikająca z niej wydajność przy określonej ilości sprzętu,
• dostępność zewnętrznych bibliotek (najlepiej freeware-owych),
• składnia języka,
• dojrzałość framework-ów służących do tworzenia aplikacji web-owych w danym języku, najlepiej opartych o model MVC.

Mając to wszytko na uwadze rozpocząłem swoje wieczory sam na sam z Google-m. Prawdę mówiąc wybór był już dokonany (Java) i tak naprawdę chciałem tylko potwierdzić jego słuszność. Trzeba przyznać, że trochę byłem zaskoczony (tak to jest, gdy człowiek skupi się tylko na korporacyjnych rozwiązaniach), gdy już po kilku godzinach poszukiwań okazało się, że Java delikatnie mówiąc, nie jest najczęściej wybieranym rozwiązaniem — z większych serwisów wypatrzyłem tylko FeedBurner (który oparty jest na Java+JS+Tomcat+MySQL. Z naszego rodzimego podwórka serwis Grono.net początkowo napisany został w oparciu o język Java, jednak po dwóch latach został on przepisany, wykorzystując tym razem Python+Django — swoją drogą chętnie spytałbym się osób odpowiedzialnych za tą decyzję, co spowodowało tak poważną decyzję i co ważniejsze jak tą decyzję oceniają z perspektywy następnych kilku lat.

Otwartość rozwiązania

Na tym etapie odpadł C#, w zasadzie bez większego zgłębiania tematu. Język ten na pewno ma mnóstwo ciekawych rozwiązań, jednak fakt ograniczenia się do produktów Microsoft-u zadecydował o jego dyskwalifikacji. Wszystkie inne rozwiązania w mniejszym lub większym stopniu oparte są o otwarte rozwiązania.

Szybkość tworzenia / łatwość utrzymania aplikacji

Nie są to rzeczy łatwo mierzalne, jednak ze wszystkich znaków na niebie i ziemi (czyli dziesiątków postów) wynika że znacząco szybciej tworzy się kod przy użyciu języków interpretowanych, dynamicznie typowanych. Jeśli chodzi o łatwość utrzymania kodu, to tak postawione pytanie jest jednym z wielu wywołujących niekończące się dyskusje w stylu: które języki są lepsze dynamicznie, czy statycznie typowane, KDE czy GNOME, Ruby czy Python, święta Bożego Narodzenia, czy Wielkanocne. Dotąd też byłem zwolennikiem języków statycznie typowanych i taki Smalltalk wydawał mi się onegdaj bardziej ciekawostką, niż językiem do tworzenia dużych systemów. Jednak wydaje się, że w przypadku serwisów internetowych języki dynamiczne lepiej się sprawdzają ze względu na zwiększenie produktywności. A wady takie jak trudniejszy refactoring, czy też możliwość, że pewne błędy zostaną wyłapane dopiero w czasie testów (a nie kompilacji) są akceptowalnym kosztem. W swoim czasie Bruce Eckel (tak ten od „Thinking in Java”, „Thinking in C++”) popełnij następujący post Strong Typing vs. Strong Testing, traktujący o tym że w dobie TDD zysk ze statycznej kontroli typów stał się znikomy.

W tym konkretnym konkursie postanowiłem więc przyznać punkty językom dynamicznie typowanym, tj. Perl/Python/PHP/Ruby. Jeśli kogoś zainteresowało porównanie mocnych i słabych strony języków typowanych statycznie versus dynamicznie, to odsyłam do małej prezentacji Contrasting java and dynamic languages. Interesujące porównanie jest także tutaj C++ vs Java vs Python vs Ruby (i od razu oczywiście krytyka takiego podejścia).

Popularność danego języka

Jednym ze sposobów weryfikacji popularności języka może być: TIOBE Programming Community Index lub Programming Language Popularity. Innym weryfikacja na swoim ulubionym portalu z pracą, ile jest ofert związanych z określonym językiem programowania. W zależności od wyboru takiego portalu (polski/zagraniczny) wyniki mogą się trochę różnić. Wydaje się jednak że ze znalezieniem programistów Java lub PHP nie powinno być problemu. Choć w przypadku PHP należałoby pewnie zadać sobie także dodatkowe pytanie: Jak wielu z nich jest obeznanych z programowaniem obiektowym, zna i docenia zalety modeli typu MVC.

A może jeśli na lokalnym rynku nie ma za dużo programistów znających język, który chcemy użyć jesteśmy w stanie stworzyć odpowiednie community? Czy są blisko uczelnie informatyczne, które używają danego języka programowania w trakcie nauki studentów? Jeśli nie, to czy byłyby skłonne zacząć i jeszcze lepiej współuczestniczyć w tworzeniu community?

Wydajność

Dość trudno odpowiedzieć na to pytanie. Z jednej strony te same algorytmy napisane w Java wydają się być szybsze niż ich odpowiedniki w Python/Ruby. Z drugiej strony, jak się spojrzy ile pamięci potrzebuje Tomcat, aby rozsądnie działać versus np. moduł mod_python, to sprawa nie jest już taka oczywista. Można w internecie znaleźć setki takich porównań a chwilę potem tyle samo komentarzy przekonywujących czemu dany test nie ma specjalnie sensu. Przykładowe posty: Ruby on Rails vs. Django performance, Framework Performance, The performance test of 6 leading frameworks (choć ten już trochę leciwy, bo z 2007 roku).

Osobiście byłbym skłonny dołączyć się do głosów, że 20-30% różnicy w takich testach nie jest specjalnie znaczące, a większość optymalizacji dotyczy bazy danych.

W kategorii tej nie został wybrany jednoznaczny zwycięzca.

Zewnętrzne biblioteki

Wydaje się, że wszystkie z wymienionych języków mają dość bogatą ofertę zewnętrznych bibliotek.

Więc także brak jednoznacznego zwycięzcy.

Składnia języka

Jeden język został na tym etapie zdyskwalifikowany — Perl, rozumiem, że są zadania gdzie świetnie się sprawdza, ale do mnie jego składnia nie trafia i już. Także PHP nie popisał się na tym polu, w internecie aż roi się od postów wytykających bałagan dotyczący składni, np. PHP Sucks, But It Doesn’t Matter.

Framework-i

Każde z tych rozwiązań dorobiło się już dojrzałych framework-ów. Dla PHP są to m.in. CakePHP, Symfony, Zend, dla Ruby Ruby on Rails, a także ostatnio Merb. Dla Python-a będą to chociażby: Django, TurboGears, Pylons, o Javie nie wspominając, bo ciężko byłoby je wszystkie wymienić.

Tak więc i w tej kategorii nie ma jednoznacznych wygranych, czy też przegranych.

Podsumowanie

Wybór w dużej mierze sprowadza się do zagadnienia „języki typowane statycznie versus dynamicznie”. Te drugie pozwalają szybciej kodować, oczywiście jakimś kosztem. Wydaje się jednak, że w naszym przypadku zastosowanie ich jest całkowicie uzasadnione.

And the winner is…

Które więc z rozwiązań PHP/Python/Perl/Ruby. Perl odpadł w związku z jego składnią. PHP jakoś mimo swojej dużej popularności do mnie nie przemawia — zresztą nie tylko do mnie (jedna z wielu dyskusji o wyższości jednego języka nad drugim). Może jest to kwestia różnych korzeni – moje są obiektowe, jego nie specjalnie. Pozostają Python i Ruby — oba obiektowe, oba mające swoich zwolenników i przeciwników.

Schodząc na poziom framework-ów oznaczało wybór pomiędzy: Django/Pylons/TurboGears/Ruby on Rails/Merb. Tu wybór nie był już wcale oczywisty i każdy z nich prawdopodobnie świetnie by się spisał. Jednak decyzję trzeba podjąć — Merb wydaje się trochę za świeży, RoR ma trochę za dużo magii, Pylons&TurboGears z jednej strony integrują w całość najlepsze komponenty, z drugiej strony czas potrzebny na to, aby stać się produktywnym jest siłą rzeczy większy, no i ta nie najlepsza dokumentacja. Django za to sprawdził się w boju, okrzepł (ostatnio dorobił się wersji 1.0), ma doskonałą dokumentację i nawet jeśli w pewnych miejscach jest trochę słabszy — zdaje się być najlepszym wyborem dla nas. Dodatkowo Python jest jednym z trzech głównych języków używanych w firmie Google, a ichni Google App Engine pozwala uruchamiać aplikacje w okrojonej wersji Django, co nawet jeśli nie zamierzamy tego wykorzystywać o czymś świadczy.

Tak więc wybraliśmy zestaw: Python + Django.

Jeśli ktoś ma ochotę na więcej, poniżej inne ciekawe posty w temacie wyboru technologii:

• Aplikacja webowa – wybór technologii
• Dlaczego Ruby on Rails?

Założenia z grubsza mieliśmy podobne, jednak jak widać decyzje podjęliśmy inne. Czy któraś z nich była lepsza/gorsza? Moim zdaniem nie, po prostu są one inne. Co więcej, za pół roku mając te same założenia można by podjąć inną decyzję.

¹ Szranki i konkury – zbieżność tytułów całkowicie przypadkowa