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.

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?

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!

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.

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

web2py - wymiękłem

Jeszcze tydzień temu zachwalałem, w swojej prezentacji, na konferencji w Warszawie Pylons. Prezentowałem jego cechy, zalety oraz braki. No właśnie braki. Po obejrzeniu prezentacji Webhosting.pl o wdrożeniu Pylons oraz "Pylons - Demonstracja możliwości" Tomasza Nazara. Można je znaleźć na stronie materiałów PyCon2008 PL zaczęło do mnie docierać, że Pylons nie jest niczym - fenomenalnym.

Zacząłem analizować ... porównania. Porównania z innymi frameworkami. W Merb zachwyciła mnie modularność, wydajność i czytelność kodu. Przyznaję się. Nie napisałem w tym frameworku nawet pół linijki kodu. Cały podziw dla kunsztu przedkładam wyłącznie z wypowiedzi z jakimi spotykam się w sieci. Przeglądając pluginy znalazłem ciekawą opcję walidacji danych wchodzących do datamapeera jednak zabrakło mi gdzieś generowania formulrzy czy chociażby samej obecności admin panelu. Wiem, że ma być obecny w wersji 2.0 :) To cieszy. Być może coś przeoczyłem jednak przy moich obecnych obserwajach Merb w porównaniu do Pylons ma fantastyczne validowanie, z tłumaczeniami błędów i to w kilku języka... I do tego ta elegancja składni dekoratorów - miodzio.

No właśnie. Skoro już przy tym jesteśmy. Pylons tak jak merb nie posiada admin panelu. Tutaj na tle frameworków Pythonowych króluje Django. Nie ma mowy o scaffoldingu czy czymkolwiek takim. Nic z tych rzeczy. Modularność może cieszyć, jednak niestety nie znajdujemy mechanizmów do generowania formularz (znowu) ... Co prawda jest FormBuild ale wygląda bynajmniej podejrzanie, pomimo tego że jest opisana w PylonsBook, i jakoś ... nie o takim generowaniu marzę.

No więc może Django. Posiadania rozbudowane generowanie formularzy oraz admin panel. Pomimo tego nie dorasta do pięt Pylons w walidowaniu formularzy o braku możliwości testowania kodu (co często jest krytczne) nie wspomnę.

Sprostowanie

Od wersji 1.0 Django posiada możliwość pisania zarówno unittestów (z użyciem Pythonowej biblioteki unittest) jak i functional testów. Jest temu poświęcony poddział dokumentacji.

Co do Railsów - wydają się tutaj rozsądne. Posiadają na przykłąd mailer, którego na próżno szukać w jakimkolwiek pythonowym frameworku. Jest konsola (jak w Pylons), Scaffolding. Może brak admin panelu (chociaż może ktoś zna takowy), ale nie ma co narzekać: mailer, rack do testowania, migracje. HAML, SASS, spory wybór możliwych do podpięcia ORMów ... bomba.
A co gdybyśmy chcieli programować w Pythonie ? HAML i SASS oczywiście nie zagościł tutaj, mailerów nie można się spodziewać (choć szkoda, bo przydałaby się dobrze przetesowana biblioteka odporna na MailInjection) .

Wszystkie frameworki są do siebie jednak podobne. Generowany jest jakiś kod, używa się poleceń skryptowych i konsoli...
Dziś trafiłem na ten screencast pokazujący możliwości frameworka web2py



Nie wiem jakie macie podejście do tego co jest na nim pokazane. Wszystko co jest tam zaprezentowane to prawda, choć bardziej przypomina to "klikanie" aplikacji, niż jej tworzenie. Na prawdę. Nie otworzyłem ani przez sekundę edytora. Konsola też w gruncie rzeczy jest zbędna (chyba, że chcesz w niej odpalić serwer). Jest scaffolding (wow). Co prawda nie zauważyłem, żeby można było sobie wygenerować jego kod do pliku "od tak" jak w Rails, ale jest ! i to nie lada. Formularzy się "nie generuje" po prostu ... są :) i walidowanie jest ... bajecznie proste.
Wydaje mi się troszkę, że tak zautomatyzowany framework będzie podpadał pod zarzuty pod jakimi padał Django w ogniu Grono.net jednak ... to co dziś widziałem robi na mnie wrażenie. Web2Py to coś ... innego, coś co zmienia myślenie o tworzeniu aplikacji internetowych. Zobaczymy co jeszcze :)

Ruby on Rails vs .... series

Dziś kolega, zafascynowany Ruby on Rails, pokazał mi filmiki z serii Ruby on Rails vs .... http://pl.youtube.com/results?search_query=Ruby+On+Rails+vs&search_type=&aq=f

Na starcie zapytałem: "A jak wygląda filmik z Django" [http://pl.youtube.com/watch?v=PLUS00QrYWw] Chyba musieli się naprawdę wysilić żeby coś takiego wymyślić. Moim zdaniem - śmiech na sali. W momencie, w którym to obejrzałem twórcy wydali mi sie śmieszni i w gruncie rzeczy - sami ośmieszyli Railsy.

Przy informacjach, jakie można znaleźć na blogach, w których zarzutami przeciwko railsom jest wydajność (tutaj Django pokazuje klasę że hoho) czy też błędy znane od lat, czy chociaż kiepski sposób implementacji porównywanie siebie z Django z góry z założeniem "Railsy muszą wypaść na plus" - jest bez sensowne.