Showing posts with label python. Show all posts
Showing posts with label python. Show all posts

Friday, May 27, 2011

Continous integration i Python?

Czy ktoś widział może kiedyś budowanie projektu pisanego w Pythonie?
Może nie jestem czegoś świadom, albo myślę zbyt szablonowo ale: continous-integration jest dobrze zdefiniowane dla projektów, które trzeba kompilować. Wiadomo. Developer nie kompiluje kodu sam. System CI sam sprawdza za niego czy kod pozytywnie przechodzi etap kompilacji i wysyła powiadomienia.

Ale jak odnieść się do tego w świetle Pythona. No dobra, wyciągamy kod źródłowy z repozytorium - i co? Przecież go nie skompiluję. Wszystko, na stać moją wyobraźnię na dzień dzisiejszy, to hmm... scan pylint, pychecker, pep8, odpalanie metody .compile() na każdym module? Jeżeli już zdecydujemy się na skany: to jak zachować się w przypadku jakiś komunikatów. Kod nie musi być źle napisany, zresztą zakładamy, że przeszedł review, ale wtedy co? Sfailować build tylko dlatego, że kod Pythona programisty nie odpowiada pylint. To niczego nie udowadnia.

Piszę ten post w związku z sytuacją jaka miała miejsce kilka dni temu. Rozumiem, żeby w trakcie budowania projektu Pythonowego odpalać testy w ramach. W moim przypadku nie mam nawet czasu aby je pisać więc nie ma co odpalać. Przyjmuję argument, że to co wychodzi na produkcję powinno być numerowane. To bardzo pomocne i użyteczne. Jednak w Python 2 wszystko co sobie wyobrażam to otagowywanie kolejnych wersji w repozytorium. Podmienianie egga, który wywala serwer Apache ponieważ przestają mu się zgadzać sumy kontrolne - to jakaś porażka. To nie wiem co innego mógłbym robić? Dodawać komentarz z numerem buildu w jakimś umówionym pliku? Dodam jeszcze, że to aplikacja internetowa pisana w Django.

Jeżeli ktoś jest w temacie to jestem bardzo zainteresowany wymianą doświadczeń w tym temacie.

Webdevelopment i unit testy

Kilka tygodni temu zacząłem developować webowy frontend dla projektu gitolite o nazwie glboard. Gitolite to warstwa abstrakcji pozwalająca na kontrolę dostępu do repozytoriów systemu git podczas dostępu do serwera przez ssh.

Glboard od samego początku pisany był z myślą o testach, dlatego wraz z kodem publikowane były unit testy do udowadniania poprawności metod, klasy, która stanowi trzon funkcjonalności.
Podczas oglądania prelekcji "State of Pylons/Turbo Gears2/repoze.bfg", moją uwagę przykuły zarzuty postawione unit testom w web-developmencie.

W tym okresie spędziłem sporo czasu, w glboard, na poprawianiu unit testów. Jeżeli padłem ofiarą zbyt wczesnego testowania - to jaki sens ma Test Driven Development?
Podczas zmieniania głównej klasy, obsługującej operacje na repozytorium gita, uzyskałem pewien ciekawy efekt - witryna działała i mogłem dzięki niej wykonać wszystkie operacje - natomiast testy failowały. Wszystkie. Powód był prosty: klasa przyjmowała teraz nowy argument w metodzie __init__.

Wspomniana prelekcja uświadomiła mi jedną rzecz. Jeżeli nie wystawiasz czegoś na zewnątrz, nie wystawiasz API lub biblioteki, nie będziesz zobligowany do zachowywania wstecznej kompatybilności z jakimś stworzonym przez siebie interfejsem, które kiedyś udostępniłeś, tylko dlatego, że używają go klienci - nie używaj unit testów. Pisanie unit testów do elementów, które zostają w twoim projekcie i nie wychodzą w żaden sposób na zewnątrz - to strzelanie sobie w stopę.

Moim zdaniem pisząc aplikację we frameworku webowym to co powinno się testować - to działanie przez przeglądarce. Testy funkcjonalne wydają się wystarczające. Może są troszkę bardziej kosztowne niż unit testy, ale w gruncie rzeczy, dobrze napisane, testują dokładnie to co powinny. Nie skupiają się na API konkretnej klasy, funkcji, metody, ale na tym czy witryna działa - nie ważne jest jak.

Odnosząc się do narzekań na Selenium i długiego czasu trwania testów w nim napisanych: myślę, że możemy spodziewać się rewolucji w świecie testów web-aplikacji dzięki PhantomJS. Nie znam jego wydajności, ale funkcjonalność jest w tej dziedzinie bardzo obiecująca i daje znacznie więcej możliwości niż zwykłe funkcyjne testy. Równocześnie nie używa całego niepotrzebne osprzętu jakie ładuje przeglądarka.

Wszystko co w tej chwili mi pozostaje to usunąć unit testy z glboard i napisać functional testy :)

Saturday, January 22, 2011

Co w ostatnich tygodniach.

Dawno nie pisałem na blogu. Gdy jeszcze dzieliłem czas na studia i pracę starczało mi czasu na wszystko. Obecnie obcowaniem z komputerem staram się ograniczać do siedzenia przed nim w pracy, a wieczory i weekendy spędzać w inny sposób.

Ćwiczę Angielski. Umiałem go świetnie przed maturą, jednak studia inżynierskie skutecznie uwsteczniły mnie w tej materii. Jakiś już czas temu, bo w zeszłym roku, mój manager widząc braki, zorganizował spotkania z lektorką dzięki czemu wtorki i czwartki zaczynam lektoratem z języka angielskiego :) co skutecznie poprawia mi humor na pozostałą część tygodnia.

Co do języków programowania - wciąż używam Pytona, ze względu na jego znajomość zostałem zatrudniony i przez ostatnie 1,5 roku zostawiłem po sobie na tyle skryptów i aplikacji zapisanych w tym dialekcie, że ciężko codziennie się z nim nie stykać. Jednak moje marzenia i pasje kierują się w stronę Node.JS oraz wciąż zagadkowego dla mnie języka Scala.

Node.JS chciałem rozpocząć od przebrnięcia przez fantastyczny podręcznik do JavaScript "Eloquent JavaScript". Niestety, silnie funkcyjne podejście autora do sprawy skutecznie utrudnia mi przyswojenie lektury, a problemy zaczęły się już w rozdziale 4.

Co do Scala jest lepiej. Wiele zawdzięczam prelekcji Mikołaja Sochackiego Aplikacje webowe w Scala i Lift wygłoszonej na Zimowisku TLUGu. Sama prezentacja, jak i późniejsza wymiana doświadczeń w prywatnej rozmowie z prelegentem, pozwoliły mi dojść do wniosku, że trzeba przestać przejmować się, że "czegoś" nie rozumiem i opanować Scalę na miarę swoich możliwości - z czasem poznając ją może po prostu lepiej.

Tak też narodził się pomysł na prostego bloga, z przykładowymi aplikacjami w języku Scala, które skupiałyby się na konkretach i w prosty sposób pozwoliły na zapoznanie się z językiem. Co z tego wyjdzie - zobaczymy. Obecnie robię rozeznanie w silnikach, na których warto byłoby taki "blog" postawić. Z dotychczasowych poszukiwań wszystko wskazuje na Joggera - chyba, że znajdą się jakieś fundusze na zakup i utrzymanie domeny - wtedy będzie to Wordpress. Przy okazji trafiłem na Polski Portal Scala, na którym już w tej chwili można zapoznać się z niemałym zbiorem przykładów kodu w tym języku.

Jednak pierwszeństwo przed projektem Scalowym ma stworzenie Planety Pythona, którego podjąłem się niedawno w ramach mojej działalności w Polish Python Coders Group - wszak na koszulkę jakoś trzeba sobie zasłużyć :). Twarzą w twarz poznałem większość ekipy dopiero na PyCon.pl 2010 i co tu dużo gadać - są genialni. Kocham tych chłopaków za kawał dobrej roboty jaki odwalają, szczególnie na IRCu i Forum - uważam, że mamy fantastyczną scenę Pythonową w Polsce jakiej można tylko pozazdrościć i każdy kto chce zacząć przygodę z tym językiem nie mógłby sobie wymarzyć lepszej społeczności niż obecna.

Wracając do Zimowiska Linuksowego TLUG - było naprawdę fajnie. Dzięki zakwaterowaniu w Puckim HOMie czułem się jak na wczasach, do tego urok małego miasteczka jakim jest Puck - genialnie. Prelekcje były zróżnicowane, poziom wielu z nich naprawdę wysoki i profesjonalny. Szczególnie dało się to odczuć w prezentacjach Piotra Macuk, Tomasza Torcz (wiem, że gdzieś prowadzi bloga, ale nie mam adresu), Roberta Jaroszuk, Grzegorza Borowiak oraz Dariusza Puchalak. Subiektywnie jednak bardziej interesują mnie technologie webowe i ten charakter konferencji, która moim zdaniem była zaadresowana głównie do administratorów systemu Unix, nie przypadł mi specjalnie do gustu.

Co do spędzania czasu po pracy zagospodarowuję go w znacznej mierze treningami Aikido w Shoshin Dojo. I grubsza tyle z nowinek - wracam chorować :]

Sunday, November 7, 2010

Pyramid - następca Pylons

Kilka dni temu Kevin J. Smith napisał na grupie dyskusyjnej pylons-discuss, że jako użytkownik Pylons, czuje się troszkę zmieszany ponieważ pierwszy raz trafia na informacje o Pyramid.

Szybko okazało się, że developerzy Pylons zaczęli pracować już nad następcą Pylons - jednak nie ogłosili tego światu. Tak oto przypadkiem świat dowiedział się o Pyramid.

O kierunkach jakie przyjmie Pylons 2.0 można było przeczytać już kilka tygodni temu na blogu Bena Bangerta we wpisie Why Extending Through Subclassing (a framework’s classes) is a Bad Idea. Było to preludium do kierunku jakim podąży Pylons 2.0 - a właściwie powinienem powiedzieć Pyramid.

Pierwsze - Pyramid "połączyło się" z zespołem repoze.bfg. Połączyło się, a raczej stwierdziło, że dotychczasowy model tworzenia kolejny aplikacji (poprzez tworzenie podklas WSGIController) jest ślepym zaułkiem - przed czym zostali ostrzeżeni przez sławę CherryPy Boba Brewera. Aby nie wymyślać koła na nowo obecnie Pylons tworzony jako adaptacja repoze.bfg. Tak zostało wydane ogłoszenie iż obecnie repoze.bfg staje się projektem Pyramid i będzie wydawane pod tą nazwą. Dwa fantastyczne zespoły połaczyły siły aby na bazie już dobrze ukształtowanego repoze.bfg oraz posiadającego swoich fanów Pylons powstał jeszcze lepszy framework dla języka Python.

Dzięki temu połączeniu, oraz faktowi iż kod Pyramid posiada dobrze ugruntowaną bazę w postaci kodu repoze.bfg już dziś możemy cieszyć się Pyramid 1.0a dostępnym przez Python Package Index.

Te informacje napawają optymizmem. Wszystko wskazuje na to, że następca Pylons wyjdzie szybciej niż ktokolwiek by się spodziewał i będzie to naprawdę fantastyczny framework. Oby w parze z postępami w kodzie pojawiały się artykuły, a dokumentacja rosła :) Nic tylko czekać na Pyramid Book :)

Sunday, October 17, 2010

PyCons

Tydzień po powrocie z polskiego PyCona zacząłem oglądać konferencje z konferencji pythonowych, które odbyły się w innych częściach świata. Fantastyczną nowiną jest fakt iż większość z nich zamieszcza nagrania wideo prelekcji (nie tylko slajdy) więc można po prostu wysłuchać i zobaczyć prelekcję - taką jaka była - w zaciszu własnego domu.

Tematy poruszane w różnych zakątkach świata są bardzo różne :) i dobrze. Można się naprawdę wiele nauczyć i wybrać sobie te tematy, które odpowiednio pasują do naszego obecnego poziomu lub po prostu zainteresował nas temat. Tutaj pierwsza uwaga.

Temat konferencji czasami kompletnie nic nie mówi o jej treści. To smutne, ale widzisz temat i nie wiesz - warto to w ogóle odpalać, czy lepiej odpuścić sobie. Bo co na przykład mówi tytuł "Dude, Where's My Database?". Na szczęście są (przy większości tematów) opisy mówiące o treści konferencji. Bezcenne.

Druga rzecz - jakość materiałów. Chyba najlepiej zorganizowane są na stronie PyCon Atlanta. Naprawdę super. Łatwy dostęp do wszystkiego. Natomiast materiały wideo z UK czy Europy są tragiczne. Co z tego, że mają nagranie wideo skoro ani nie słychać na nim prowadzącego wykład ani nie widać wyraźnie slajdów. Po prostu ... bezużyteczne.

Osobiście czytanie dokumentacji ze zrozumieniem przychodzi mi z trudnością i nigdy nie mogę wyłapać w niej niuansów i szczegółów implementacyjnych. Takie prelekcje są dla mnie jak znalazł. Głównie dlatego, że ludzie w nich skupiają się na tym co jest ważne, dają przykłady i pokazują "big picture", który czasem ciężko samemu dostrzec. Te trzy aspekty sprawiają, że takie konferencje to dla mnie kopania wiedzy :) Polecam każdemu!

Sunday, September 19, 2010

Flask - Nie tylko Bottle

W poprzednim wpisie pisałem o Bottle jako fajnym microframeworku dla Pythona. Jeszcze wczoraj zupełnie przypadkiem trafiłem na Flaska.

Na pierwszy rzut oka zniechęca mnie fakt, że zbudowany jest na WerkZeug. W drugim rzucie Flask wymaga ciut więcej kodu niż Bottle:

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
return "Hello World!"

if __name__ == "__main__":
app.run()


Jednak później jest już tylko lepiej. Dostępna funkcja url_for do budowania poprawnych linków - to strzał w dziesiątkę. Dokładnie to czego brakowało mi w Bottle.

Renderowanie szablonów odbywa się tutaj bardziej w stylu Pylons. Domyślnym mechanizmem jest Jinja2.

Dokumentacja Flaska wypada o niebo lepiej aniżeli konkurenta. W dokumentacji Bottle zdażają się działy mające status todo. Tutaj nie znajdziemy nic podobnego.

Na koniec dwie rzeczy, które pozytywnie mnie zaskoczyły we Flask. Wsparcie dla Flash Messages oraz wbudowane loggery aplikacji.

Tuesday, September 14, 2010

Bottle i ZODB w jednym stali domu ...

... o swojej genialności nie mówiąc nikomu.

Wybory w Kręgu Harcerstwa Starszego Matrix - napisanie prostej ankiety. W końcu okazja, aby przećwiczyć coś nowego. Tym razem ZODB i Bottle.

Bottle wydaje się nadal rozwijany oraz w jakiś sposób subiektywnie "lepszy" niż Bobo. Posiada prosty wbudowany system szablonów. Bazuje on na założeniu, że szablony znajdują się w katalogu "views" dzięki czemu unikamy potrzeby konfiguracji (jak w Rails - convention over configuration).

W obu frameworkach brakuje mi jakiejś funkcji, która generowałaby poprawne linki - chociaż niby co to za problem zrobić sobie jednolinijkową funkcję do tego. Może tyle na temat micro-frameworków. Czas o ZODB.

O ZODB usłyszałem od mojego przyjaciela, który pracuje od jakiegoś już czasu w Plone i jest tym CM/F/S em zafascynowany. Kiedyś wracając z kina powiedział "No przypisujesz sobie jak chcesz atrybuty/klucze do obiektu i jest". Brzmiało obiecująco jednak nie okazało się tak piękne.

Plone robi bardzo dużo za nas. Pierwsze - nie wystarczy przypisać. ZODB jest bazą transakcyjną i nasze działania wymagają commitowania. Najprostsza sytuacja wygląda tak:
import transaction

#
# Tutaj sobie zmieniasz
#

transaction.commit()
Kolejna sprawa, dojście do której zajęło mi sporo czasu - ZODB wychwytuje zmiany tylko elementów korzenia. Tak więc:
# W bazie danych mamy taką strukturę:
# root.osoby = [{'id': 1, 'imie': 'Jan'}, {'id': 2, 'imie': 'Katarzyna'}]

# Łączysz się z bazą danych

root.osoby[1]['imie'] = 'Kasia'
transaction.commit()
Nie zadziała ponieważ ZODB nie przeczesuje w głąb struktur danych w celu poszukiwania zmian. Musimy więc zrobić na przykład:
osoby = root.osoby
osoby[1]['imie'] = 'Kasia'
root.osoby = osoby
transaction.commit()


Co odniesie skutek. Jak więc widać ZODB jest znacznie fajniejszy w Plone niż poza nim choć nadal jest fajny :)

Monday, July 26, 2010

Umarł król niech żyje król

Pisałem swojego czasu o tym jak zauroczyła mnie swoją prostotą Sinatra o Werkzeug jako analogicznym rozwiązaniu dla Pythona. Dzisiaj przyszło mi wrócić do pewnego skryptu WSGI i zacząć mocno go przerabiać. Jedna metoda wystawiona na zewnątrz z użyciem Werkzeug z wykorzystaniem kilku funkcji pomocniczych.

Dzisiaj, kiedy przyszło mi dopisać do tego kilka dodatkowych metod znajdujących się pod innymi adresami i wysłanie formularza nie wytrzymałem. Werkzeug wymagała ode mnie wklepania masy kodu do mapowania URLi, potem napisania obsługi w application, do tego dokumentacja nie odpowiedziała mi na pytanie jak wystawić metodę tylko jako GET :| Poddałem się. Ta sytuacja skłoniła mnie do poszukiwań nowej Sinatry dla Pythona.

Tak trafiłem na framework Bobo. Jestem po prostu zauroczony! Banalne, proste dekoratory (jak w Sinatra) - kilka metod, nic wyszukanego. Gdyby ktoś był ciekaw jak podpiąć do mod_wsgi polecam artykuł na blogu Grahama Dumpletona "Using bobo on top of mod_wsgi". Krótko mówiąc - umarł król niech żyje król.

Werkzeug stał się w moich oczach krową i wyleciał z sektora, w którym miał być najlepszym. Teraz to takie Django w wydaniu zrób to sam. Czyli moim zdaniem - bez sensu. Bobo jest troszkę magiczne, ale ten rodzaj magii w Pythonie jest dla mnie nie tylko akceptowalny, ale nawet pożądany. Polecam wszystkim, którzy szukają wygodnego micro frameworka dla Pythona.

Sunday, May 16, 2010

Fabric - Pythonowe Capistrano

Wczoraj trafiłem na Fabric - Pythonowy odpowiednik Capistrano. Już czuję, że je polubię :] Zapowiada się naprawdę świetnie! Na znalezisko natknąłem się buszując po Rubo-wych narzędziach do pracy z kodem równocześnie porównując z Jarkiem Zabiłłą Ruby Python. Ruby: Rack, Python: WSGI, Ruby: Sinatra, Python: WerkZeug, Ruby: Rubinius(wyszła wersja 1.0), Python: PyPy, Ruby: Merb(byłem w szoku, że nadal jest rozwijany), Python: Pylons(jest wersja 1.0 beta 1!), Ruby: Capistrano ... Python? Tak jest Fabric!
Narzędzie jest bardzo młode (takiego wrażenie sprawia) i nie trafiłem w nim na żadne opcje związane z konkretnym systemem wersjonowania (jak w Capistrano), ale to nic :) bo może być to kwestią czasu a jeżeli nie to konwencji - wszak można użyć poleceń systemowych :]
Co do kolejności - tutaj było różnie. Rack powstał bo Rubowcy pozazdrościli Pythonowi WSGI, Fabric bo nie było odpowiednika Capistrano w Pythonie. Nie ma to jednak większego znaczenia :) Dobrze, że oba języki programowania dobrze radzą sobie w szerokim spektrum zagadnień i udostępniają wygodne narzędzia :] Ja się cieszę.

Thursday, May 13, 2010

Przygoda z Merbem i jak przeszedłem na Sinatrę

Dzisiejszej nocy nadszedł czas, gdy miałem okazję zmierzyć się wreszcie z Merbem. Znany mi świat frameworków to raczej rozwiązania typowe dla Pythona. Byłem bardzo mile zaskoczony poznając świat frameworków Ruby.
Do tej pory nie było żadnego małego projektu, od którego można byłoby zacząć naukę. Stworzenie wyszukiwarki dla kampani 1% dla ZHR.pl było fantastyczną okazją do liźnięcia Merba.
Pierwszym rozczarowaniem, była walka z samym Merbem. Zainstalowałem nowe gemy Merba 1.1.0. Pamiętał, że jest coś takiego jak wersja flat aplikacji. Bardzo zależało mi na tym właśnie modelu. Już na samym początku trafiłem na bug Merba #712. To było niestety bardzo bolesne spotkanie z rzeczywistością, które pozostawiło mnie bez złudzeń - Merb nie jest już rozwijany.
Kolejną niemiłą niespodzianką było odpalenie mongrela. Na szczęście tutaj pomogło dodanie require 'mongrel' do skryptu merb w katalogu bin projektu i skorzystanie z tak zmodyfikowanej binarki. Co gorsza, wcześniej straciłem kilkadziesiąt minut na odpalaniu webricka, który w ogóle nie łykał urlsów.
Skoro już jesteśmy przy dodatkowym sofcie. Najnowsza wersja Haml 3.0.2 nie radzi sobie z renderowaniem SASS, który kończy się błędem jak w issue #163. Wszystko działa natomiast bez problemu z najnowszą wersją Haml z gałęzi 2. Aha. Najlepsze jest to, że istnieje masa nieaktualnej dokumentacji. Szczególnie bolesne gdy chodzi o włączenie SASS. Nawet dokumentacja SASS podaje jakieś lewe informacje. Dopiero ten wpis pozwolił mi prze konwertować SASS do CSS.
Takie przygody to chleb powszedni, jeżeli oprogramowanie nie jest rozwijane od ponad roku. Nie ma się co dziwić. Najgorsze jest dla mnie to, że w Rails 3 nie ma czegoś takiego jak merb-gen flat czy merb-gen very_flat. Można obciąć to co generuje Rails 3 ale to wciąż nie jest minimalna aplikacja z własną konfiguracją. Trochę pocieszyła mnie Sinatra. Kiedy w niej kodowałem to przypomniał mi się Pythonowy WerkZeug, z tym, że w przeciwieństwie do tego drugiego Sinatra działa :P Ciekawe, że Sinatra to DSL :) co daje bardzo miłe wrażenie kodowania w zetknięciu z nią :]
Kiedy przenosiłem aplikację z Merba na Sinatrę to właściwie jedyne co musiałem zrobić poza przekopiowaniem plików statycznych i widoków to zmienić rozszerzenie widoków HAML. Reszta sama poszła. Bardzo spodobał mi się minimalizm Sinatry, który w przypadku wyszukiwarki jaką piszę był w dziesiątkę! Niestety to nie to samo co modularny Merb, który jak trzeba było to poza wygenerowanie małej aplikacji potrafił i kapcie przynieść i kawę zaparzyć. Rails nie posiada tak rozwiniętej modularności w stopniu w jakim została stworzona w Merbie - a szkoda.
Jeżeli miałbym porównać świat frameworków Pythonowych i Rubowych to tutaj jest jak z językiem - Python prosto, Ruby z dużo bogatszym wachlarzem możliwości. Mam wrażenie, że deweloperzy Pythona skupili się na prostocie jako celu, gdzie w Rubym widać dążenie do niej ale przez wszystkie etapy ogólności, które widać w wielu narzędziach.
Na tle tych przygód jest jeszcze gdzieś Scala, która wydaje mi się tak zaawansowana, że aż nie widzę dla niej zastosowania w projektach, które tworzę. To jest chyba jakiś target heavy enterprise a ja jeszcze w tych kategoriach nie myślę. Szalenie podoba mi się tutaj Merb, w którym możesz zacząć sobie dewelopować aplikację od jednoplikowej wersji very_flat po typowo railsowym bufoniastym systemie układu katalogów skończywszy. Szkoda, że Rails 3 nie daje takiego wyboru. Na szczęście jest Sinatra :) jednak jak już pisałem, Merb był gdzieś pomiędzy i szkoda, że go już nie ma.

Tuesday, March 2, 2010

Gdyby pieniądze Microsoftu ...

Ostatnio kolega podesłał mi ciekawy artykuł Python + Django vs. C# + ASP.NET: Productivity Showdown. Złożyło się to z rozmową z jednym z moich współlokatorów o doświadczeniu pisania w .NET aplikacji webowych.

Przytoczny artykuł pokazuje w skrócie, że kilku niedoświadczonych programistów zaczynających swoją przygodę z Django może pobić wydajnością większą grupę doświadczonych C# piszących ten sam projekt w ASP.NET. To pokrywa się z moimi doświadczeniami z pracy. Jednak w tym wpisie chciałem zwrócić uwagę na coś innego.

Model MVC - pierwszy raz opisany w 1797 został zastosowany we wszystkich znanych mi frameworkach i okazał się dobrym rozwiązaniem. Microsoft dopiero w 2009 r. wypuścił stabilną wersję MVC.NET. Iron Python i IronRuby to próba nadgonienia przepaści pomiędzy ASP.NET a światem rozwiązań Open Source, w końcu umożliwienie wchłonięcia dobrodziejstw wszystkich projektów typu Django czy Ruby On Rails.

Ilość pieniędzy wpakowana w ASP zapewne jest ogromna. Zastanawiam się w jakim miejscu bylibyśmy dzisiaj gdyby te same środki przeznaczyć na rozwój takich projektów jak Ruby On Rails, Django, Pylons, Web2Py, Lift ,Merb czy chociażby Drupal.

Są to projekty o skromnych funduszach lub powstające niemalże wyłącznie dzięki dobrej woli wolontariuszy. Niemniej łamią stereotypy, wyznaczają nowe trendy w tworzeniu aplikacji sieciowych, są ponadczasowe a rozwiązania w nich zastosowane wyprzedzają swoją epokę. Gdzie byłby dzisiaj świat gdyby przeznaczyć na tego rodzaju projekty pieniądze jakie Microsoft zainwestował w ASP?

Odpowiedź na to pytanie istnieje. Masz ją nawet "przed oczami" lub na stronie startowej twojej przeglądarki. Tak jest! Zgadłeś! Odpowiedzią jest - Google.
Google jest jedyną znaną mi firmą, która powszechnie na dużą skalę korzystała z dobrodziejstw rozwiązań Open Source i inwestowała w nie pieniądze. Adaptacja jądra Linuksa w projekcie Android, własne patche do MySQL czy zmodyfikowany Python to tylko niektóre przypadki sukcesu Google w wykorzystywaniu tego co już zrobiono i udostępniono za darmo.

Wiele firm z powodzeniem korzysta z całych środowisk, ekosystemów udostępnianych przez Microsoft: serwery, usługi, fora, wiki, blogi, platformy multimedialne, narzędzia do pracy zdalnej i grupowej, aplikacje biurowe. Przykładów można byłoby mnożyć i mnożyć. Wtedy tworząc narzędzie dla firmy jesteś "zmuszony" tworzyć go w .NET. Być może nie jesteś zmuszony wprost ale jednak aplikacje pod produkty Microsoft pisze się najlepiej właśnie z użyciem tych technologii. Ba! Wyobraź sobie reakcje wyższego managementu na zażądanie Apache 2 i Python bo chcesz pisać coś w Django - kiedy oni wydali setki tysięcy dolarów na produkty firmy Microsoft. A Ty chcesz im powiedzieć, że niepotrzebnie - bo użyjesz sobie darmowego softu? Zbrodnia!

Może troszkę udemonizowałem scenariusz w poprzednim akapicie, ale to wyjaskrawienie jest moim zdaniem potrzebne. Google jest jedynym przedsiębiorstwem, w którym nie widać wszechobecności technologii Microsoftu. Z mojego punktu widzenia wygląda to tak, że Google chce wciąż mieć wybór w tym czego i jak używają. Czuć się dzięki temu wolnym i nieskrępowanym co czyni z nich niesamowicie elastyczną i innowacyjną firmę.

Mam wrażenie, że języki programowania znane ze świata Open Source ukierunkowują "na zewnątrz" zaś języki Microsoft "do wewnątrz". Python, Ruby czy Scala nie są związane z żadną konkretną technologią i dlatego powstające na ich bazie rozwiązania ukierunkowane są na nowe cele wyznaczające nowe kierunki. Tak robi Google i wiele innych firm kiedy tworzy coś nowego: Gmail, Google Docs, Youtube, Facebook, Twitter.
Platformy programistyczne Microsoft wymagają zawsze włożenia gro wysiłku w opracowaniu ich "pod systemu Microsoftu". Są więc ukierunkowane "do systemów Microsoft" działania z nimi, stworzenia API i do tego najlepiej się nadają - tworzenia własnych narzędzi dobrze zintegrowanych z ekosystemem ze stajni Billa Gatesa.

Myślę, że właśnie to "przywiązanie", to "zaplecze" jakie musi posiadać każda nowo powstała technologia wytwarzania oprogramowania z Microsoft sprawia, że nie starcza już tym technologiom "pary" aby stać się technologią, w której powstanie coś ponad epokowego i łamiące współczesne standardy.

Jak już wspominałem przywiązaniu temu nie podlega Google, wybierające do realizacji projektów technologie, które pozwalają rozwinąć skrzydła programisto i stworzyć coś - co jeszcze nie istnieje. Nie ograniczając ich ale dodatkowo dając wsparcie ich innowacyjnym pomysłom w stosowanej technologii.

Co więc byłoby gdyby Microsoft wkładał swoje pieniądze w rozwój Ruby On Rails, Django czy innych projektów Open Sourcowych? Mielibyśmy Google świata Open Source :] Czyż nie byłoby to piękne?

Tuesday, February 23, 2010

Rok 2010 rokiem przełomów w aplikacjach sieciowych

To wręcz niesamowite jak wiele dzieje się w tym roku w dziedzinie aplikacji sieciowych. Być może to tylko wrażenie, jakie można mieć co roku ale moim zdaniem jest to rok przełomowy.

Dzisiaj po 2 w nocy wyszła wersja Release Candidate 1 Gallery 3. Jest to ogromny krok w dziedzinie aplikacji do przetrzymywania zdjęć. Większość dostępnych w sieci skryptów zakłada, że istnieje jeden właściciel galerii, który publikuje w niej zdjęcia. Gallery to jedyny znany mi do tej pory system pozwalający w ramach jednej galerii tworzenie wielu albumów i przydzielania uprawnień do nich wielu użytkownikom.

Gallery posiada pewne bardzo proste - acz daleko idące w skutkach założenie - jeżeli nie masz dostępu do zdjęcia - nie masz do niego dostępu wogóle, nawet poprzez bezpośredni link. Gallery w wersji 2 realizowało to poprzez przetrzymywanie obrazków poza folderami dostępnymi przez Apache zaś każde żądanie pliku PNG, JPG czy innego było tłumaczone przez mod_rewrite na wywołanie skryptu PHP, który sprawdzał uprawnienia do pliku i ewentualnie zezwalał na jego wyświetlenie.

Niestety - przy galeriach dużych rozmiarów całość znacznie rzutowała na wydajność, wygodę i szybkość korzystania.

Gallery 3 to krok milowy w każdej tych dziedzin. Dzięki modelowaniu uprawnień na poziomie plików .htaccess udało się otrzymać wydajny i szybki mechanizm bezpieczeństwa. Celem stało się utrzymanie aplikacji sprawną, lekką i wydajną. Dołożono do tego interfejs oparty o jQuery. Całość zaś oparto na fantastycznym frameworku Kohana.

Kolejne zaskoczenie to milowe w dzidzinie od lat zgłaszanych braków Django 1.2. W końcu poprawki w dziedzinie modeli, obsługa wielu baz danych, zamknięcie wielu ticketów, które od lat straszą na Djangowym bug tracku. Django w końcu przełamuje barierę "argumentu za użyciem Pylons" jakim był brak możliwości obsługi wielu baz danych co czyni go znacznie bliższym zastosowań enterprise.

Skoro już przy Pylons jesteśmy. Nigdy nie wierzyłem, że dożyję dnia kiedy zostanie wydana publicznie wersja Pylons 1.0 beta. Jednak stało się. Pylons pretenduje do wersji stabilnej z niezmiennym API i w końcu może zacząć być używany w projektach gdzie liczy się stałość i ciągłość wersji w aktualizacji 3rd party components.

Nie można też pominąć Rails 3 - chociaż tutaj nie chcę się wypowiadać to z oglądanych przeze mnie prelekcji, wypowiedzi Yehudy Katz oraz wpisów na blogach Polskich Rubystów widać, że Rails 3 jest krokiem milowym w jakości tego frameworka ku doskonałości.

Wszystko wskazuje na to, że również Drupal 7 pojawi się w tym roku. Dwa dni temu została wypuszczona wersja Alpha 2 - co oczywiście w przypadku Drupala kompletnie o niczym nie świadczy - ale zawsze to jakiś krok do przodu. Oby prace poszły szybko - bo zapowiada się naprawdę fantastyczny framework.

Prawdopodobnie jeszcze wiele zaskoczeń czeka nas w dziedzinie aplikacji sieciowych - jednak Luty i Marzec to prawdziwy wysyp. Dzisiejszy dzień to jeden z tych, w których nie mogę uwierzyć, że jest aż tak dobrze. Oby więcej takich postępów i dobrze wykonanej pracy!

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


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

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.

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.

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:


  • 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.

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.

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


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

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

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

Co to znaczy lepszy język ?

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

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

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

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

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

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

Kiedy zaczynamy się kłócić ?

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

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

Piszmy o pozytywach !

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

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

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

Bądźmy mistrzami w kunszcie :)

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

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

Friday, January 23, 2009

Django banał

Dziś pisałem przykładową aplikację, na której będę chciał pokazać jak wykorzystuje się luki w atakach XSS i CSRF. Chciałem to zrobić szybko i wybrałem Django, którego w ogóle nie znam.

Muszę przyznać, że jestem w szoku. Aplikację napisałem w trymiga, dokumentacja świetna, walidacja, formularze generują się same a modele posiadają metody idealnie do CRUDa. Najbardziej denerwują urls.py, które co nóż to trzeba uzupełniać. Formularze tworzyłem na bazie modeli i nie za bardzo wiedziałem też jak zrobić bez grzebania w klasie formularza (o ile to w ogóle możliwe), żeby pewne pole wyświetlało się w trybie readonly. Poza tym wszystko szło jak burza.

Szczerze mówiąc framework szalenie przyśpiesza tworzenie aplikacji. Dzięki temu, że nie trzeba dokładać do niego kolejnych modułów skupiam się na pisaniu aplikacji nie zaś na szukaniu rozwiązań, które po prostu były podane jak na dłoni w świetnej moim zdaniem dokumentacji.

Programowało mi się przez tą chwilę znacznie lepiej, szybciej, wygodniej i przyjemniej niż w Pylons, w którym wszystko musiałem robić sam. W Django nie widać na przykład żadnych transakcji (jeżeli nie chce się ich mieć), klasy posiadają metody - nie trzeba korzystać jawnie z jakiegoś meta.Session, gdzie w Pylons musisz sobie samemu (choć to tylko chwilka) zrobić takie cudo.

Brakowało mi tylko dekoratora do walidacji formularzy, żeby wyrzucić oczywisty kod na zewnątrz metody i nie zaśmiecać jej sprawdzaniem czy formularz się zwalidował ale napisanie go to pewnie sekundka.

Nie będę się jednak uczył tego frameworka - na ile mi potrzeba już go umiem :] Po Pylons (gdy skończę pisać projekt, który w nim zacząłem) przyjdzie czas na naukę Rubego :P

Thursday, January 22, 2009

TruboGears 2 - framework na Pylons

Wiadomość stara - jednak dla mnie szokująca. TurboGears w wersji 2 to framework, który jest napisany na Pylons. Nie wiem czy istnieje inny przykład frameworka pisanego na innym frameworku. Wątek na pylons-discuss jest z 27 Czerwca 2007 r.

Zainteresowałem się temat ponieważ dziwnie często w niektórych źródłach ukazywały się jakieś "porównania" tych frameworków, ale nie na zasadzie TurboGears vs Pylons tylko na zasadzie "co użyto w Pylons co można byłoby użyć w TG", albo "W Pylons użyte jest to a w TG użyto tego i tego - trzeba sprawdzić czy nie powinniśmy używać tego w Pylons". Moim skromnym zdaniem :) fakt zaistnienia takiej sytuacji pokazuje, że Pylons to poważny framework, ceniony w gronie developerów Pythona :] i to aż tak fajny, że można na nim pisać inne frameworki.

TG 2.0 jeszcze nie wyszedł (jest w wersji beta), być może wydanie jego pełnej wersji jest uzależnione od wyjścia Pylons w wersji 1.0. Poczekamy - zobaczymy :)

Nowa strona Pylons i wersja 0.9.7 rc4

Od wczoraj na stronie Pylons "psuło się" w niektórych działach menu - dziś możemy oglądać nową odsłonę witryny. Wiele witryn ładnie komponuje się z "otoczką" w stylu egipskim - najlepiej witryna główna. Wiki straszy obecnie troszeczkę Python stylowym wyglądem, który ciężko przypiąć do obecnego layoutu witryny :]

Myślę, że wraz z odświeżeniem strony nastąpi też ożywienie społeczności, będzie to jaki bodziec, pozytywny akcent. To co cieszy to fakt iż proponowana do ściągnięcia na stronie wersja Pylons to 0.9.7rc4. Jak można wyczytać na grupie dyskusyjnej do wydania wersji 0.9.7 kod prawdopodobnie nie ulegnie zmianie bo jedyne zadania, które zostały do ukończenia to tickety niezwiązane z kodem.

Jestem szalenie ciekaw jak szybko ruszą prace nad 9.8 i czy zmiany z 9.7 zostaną zmergowane do gałęzi 1.0, która już od około 10 miesięcy się nie zmienia. Zobaczymy :) Czekam na marcową wersję Pylons 1.0 ;]