restless: Najnowsze wpisy

JavaScript, Mobile i DevMeetings

Sun, 27 Mar 2011 23:28:35 +0100

Programowanie aplikacji mobilnych w JavaScript - relacja z DevMettingu w Gliwicach

DevMeetings i programowanie aplikacji mobilnych w JavaScript? Bardzo dobrze!

Bardzo dobry zbieg okoliczności

Pewnego dnia stwierdziłem, że najwyższy czas, aby poważniej zainteresować się developmentem dla urządzeń mobilnych. Z jednym zastrzeżeniem - developmentem softu, który będzie działał na różnych urządzeniach. Kilka chwil później dowiedziałem się, że wkrótce w mojej okolicy odbędzie się niejaki DevMeeting, którego tematyka obejmie dokładnie to co mnie interesuje. Przyznaję bez bicia, że nigdy wcześniej o DevMeetings nie słyszałem, ale postanowiłem zaryzykować i po chwili, wraz z Pigletto, moim współdeveloperem, zarejestrowaliśmy się szkolenie.

Zaskoczyło mnie to, że DevMeetings są darmowe. W tej sytuacji zbyt wiele się po nim nie spodziewałem... no cóż, pomyliłem się. W chwili obecnej stwierdzam, że dzięki brakowi opłat na szkoleniu pojawiają się osoby, które są tematem zainteresowane i które faktycznie chcą tam być, a nie ludzie przymuszeni przez pracodawców.

DevMeeting, o którym mowa odbył się 25 marca w Gliwicach.

Bardzo dobry skład

Zarówno prowadzący David de Rosier, organizatorzy, jak i uczestnicy DevMeetingu reprezentowali naprawdę dobry poziom i sprawili, że 12 godzin minęło bardzo szybko w miłej atmosferze.

Prowadzący - duża wiedza poparta doświadczeniem, a przy tym luz i komunikatywność.

Organizatorzy - sprawnie działające wi-fi i repozytorium (problemy z wyjściem na świat wynikały z winy hotelu), ładne notatniki dla uczestników, dobra pizza, kawa, której wystarczyło do samego końca i ogólnie profesjonalne podejście do tematu.

Uczestnicy - wszystkie zespoły dały radę stworzyć porównywalne aplikacje. Podrzucę tu jeszcze kilka statystyk:

Ilość uczestników: około 20 osób
Kobiety: 2 i co warte podkreślenia obie ładne (jeśli uważasz, że to seksistowskie to pewnie masz rację; jeśli Ci to nie odpowiada to przypominam, że to mój blog)
Laptopy z jabłuszkiem: około 6 sztuk, w tym przynajmniej jeden wypasiony MacBook Pro (trzymającej kilka długich godzin baterii trzeba zazdrościć)
Laptopy z Linuksem: 2 sztuki (mój i Pigletta, mogło być więcej, ale nie zauważyłem)
Profesje uczestników: głównie frontendowcy i web deweloperzy, tu muszę podkreślić, że wraz ze mną i Piglettem było czworo djangowców

Bardzo dobra forma szkolenia

Szkolenia są nudne. Byłem na niejednym, na którym po teoretycznym wstępie należało wykonać ćwiczenie: 1. kliknij przycisk X, 2. wpisz bla bla bla, 3. kliknij przycisk Y itd. Masakra, ale tu było inaczej!

Formuła DevMeetings polega na tym, że uczestnicy dzieleni są na grupy. Następnie prowadzący robi mniej lub bardziej krótki wstęp teoretyczny, po czym należy napisać kod, który będzie realizował jakąś funkcjonalność. Nie ma tu żadnej instrukcji krok-po-kroku. Grupa otrzymuje pliki ze strukturą programu, trochę wskazówek i zaczyna myśleć nad rozwiązaniem oraz tworzyć kod.

Moim zdaniem podział na grupy jest dobrym pomysłem. Przede wszystkim integracja i interakcja są zapewnione. Ponadto przy pracy grupowej każdy wnosi coś od siebie i nie ma przestojów wynikających z "nie wiem jak to zrobić" - zawsze ktoś z grupy wie lub ma jakiś pomysł. Wada jest taka, że właściwie stale powinna pisać osoba siedząca w środku, ewentualnie można się zmieniać przy jej komputerze.

Bardzo dobry temat

Programowanie aplikacji mobilnych w JavaScript to naprawdę fajna sprawa i w dobie ogromnej popularności coraz to lepszych telefonów bardzo na czasie. Na DevMeetingu można było nabyć sporo wiedzy oraz uporządkować tę już posiadaną. Świetnie było posłuchać porównania PhoneGap z Titanium, poznać wady i zalety JQuery Mobile, czy w końcu dowiedzieć się dlaczego PhoneGap nie jest doskonały.

Cała ta wiedza została, niczym kofeina w organizmie programisty, przetworzona w kod, który - ależ to była frajda - uruchomił się na rzeczywistym smartfonie z Androidem. Nie dość, że się uruchomił to jeszcze sprawnie wychwytywał zdarzenia płynące z akcelerometra i sterował czołgiem. Tak, mieliśmy łączność z Libią.

Podsumowanie

Kilka luźnych myśli: Jestem bardzo zadowolony z udziału. 12 godzin to jednak długo i pod koniec chyba wszyscy byli mocno zmęczeni. Teraz już wiem, że JavaScript to taki stary przyjaciel, który wygrał w loterii i chce się ze mną podzielić wygraną. Zamierzam skorzystać.

Na koniec może zaskoczę, ale udziału w DevMeetings nie polecam. Znacznie lepiej jest usiąść samemu przed monitorem, wyszukać odpowiednie tutoriale i spokojnie je sobie poczytać... a jak już będziecie czytać to ja spokojnie zapiszę się na kolejny DevMeeting nie martwiąc się o to czy wystarczy miejsc :P

Przezroczyste PNG w IE6 - ciąg dalszy

Sun, 12 Dec 2010 22:18:45 +0100

Rok temu pisałem o przezroczystości png w IE6. Czas na małą aktualizację.

Zachęcony pytaniem od jednej z czytelniczek mojego ubiegłorocznego artykułu na temat przezroczystości png w IE6, sprawdziłem aktualną sytuację w tym temacie. Pomimo, że IE6 (na szczęście) umiera pojawiły się nowe rozwiązania.

Przede wszystkim zachęcam do zerknięcia na ciekawy wpis na blogu Thomasa Hruski, w którym podaje on rozwiązanie problemu z wykorzystaniem png8, a na samym końcu artykułu odsyła do jeszcze innego interesującego podejścia.

Jeśli jednak, tak jak ja, nie lubicie się męczyć z grafiką warto skorzystać z innego, również polecanego przez Thomasa, rozwiązania jakim jest DD_belatedPNG. Jest to skrypt JavaScript, który można wykorzystać dodając na stronie:

   <!--[if IE 6]>

   <script src="DD_belatedPNG.js"></script>

   <script>
     DD_belatedPNG.fix('.png_bg');
   </script>
   <![endif]-->

gdzie .png_bg jest na selektorem CSS. Proste i działa świetnie zapewniając obsługę PNGów zarówno użytych w atrybutach src taga img, jak i jako własność parametru background-image w CSS. Co więcej w tym ostatnim przypadku właściwie działają background-position oraz background-repeat.

Wszystko dla Django

Wed, 10 Nov 2010 21:23:22 +0100

Jak mogłem to przegapić? Obowiązkowa strona dla użytkowników Django: http://djangopackages.com

Dawno dawno temu była sobie całkiem przyjemna strona Django Pluggables, na której można było znaleźć liczne aplikacje do wykorzystania we własnych projektach. Poźniej, jak pamiętam, pojawił się na liście dyskusyjnej Django wątek, w którym dyskutowano o tym, że tych aplikacji jest tak dużo, że nie wiadomo którą wybrać. Jak się wczoraj dowiedziałem na dyskusji się nie skończyło i oto Django Pluggables zamieniło się w Django Packages.

Django Packages to rewelacyjna strona. Po pierwsze znajdziemy na niej nie tylko uniwersalne aplikacje (wolne tłumaczenie angielskiego reusable apps), ale też frameworki, czyli np. CMSy, fora, czy sklepy internetowe, a także gotowe projekty oparte na Django oraz "inne", czyli to co nie łapie się do powyższych kategorii, ale jest przydatne jak np. buildoutowa recepta djangorecipe.

Po drugie wszystkie zamieszczone na stronie pakiety mają przypisane parametry pozwalające nam na ocenę ich popularności. Wśród parametrów tych znajdziemy: ilość pobrań ze strony pypi, aktywnośc w repozytorium projektu oraz ilość użytkowników.

Po trzecie Django Packages to gridy. Absolutnie przydatne zestawienia porównawcze. Co tu dużo pisać to trzeba zobaczyć, oto przykładowy grid dla CMSów.

Oczywiście każdy odwiedzający, po zarejestrowaniu, może dodać do strony nową aplikację, stworzyć nowy grid, lub zmodyfikować istniejące. Każdy może też kliknąć "I use it" przy aplikacji, z której korzysta, zwiększając tym samym licznik jej użytkowników.

Dla mnie rewelacja, po raz kolejny cieszę się, że używam Django.

Piramidalna zemsta Zope

Fri, 05 Nov 2010 22:24:33 +0100

Zagotowało się w świecie pythonowych frameworków webowych. Pylons, Repoze.BFG i być może TurboGears, nie mogąc sprostać konkurencji ze strony Django, postanowiły połączyć swoje siły.

Przesadziłem? Ok, z tym sprostaniem konkurencji ze strony Django to taka mała prowokacja. Niemniej jednak połączenie się wspomnianych frameworków jest oficjalnym faktem. Można o tym przeczytać na liście dyskusyjnej repoze.bfg, do czego zachęcam.

W kilku słowach ujmując zaistniałe zdarzenie, można powiedzieć, że repoze.bfg nie doczeka się wersji 1.4 (wersja 1.3 ukazała się 1 listopada... nomen omen w Święto Zmarłych), albowiem stało się właśnie frameworkiem Pyramid. Podobnie ma się sprawa z samymi Pylonsami, ktore niedawno doczekały się wersji 1.0 (linia 1.x będzie utrzymywana, według deweloperów, jeszcze przez parę lat), ale to co miało być Pylonsami 2.0 będzie po prostu frameworkiem Pyramid.

Pyramid rozwijany będzie w ramach projektu Pylons, który stanowić będzie zbiór różnych powiazanych technologii.

TurboGears, które bazuje na Pylonsach, jeszcze nie zdecydowało, czy również będzie się opierało na Pyramidzie, czy jednak zostanie na Pylons 1.0. Moim zdaniem zdecydują się na Pyramid.

Jakie są motywy powyższego kroku? Chodzi głównie o zwiększenie siły przebicia frameworku oraz o przezwyciężenie pewnych problemów, które Pylons miał ze swoją achitekturą:

(Jeden z twórców Pylons) discovered an architectural design flaw in Pylons [1]. The problem orients around the chosen strategy of implementing individual app
extensibility by allowing subclassing of the WSGIController

Sporo na ten temat można znaleźć w tej dyskusji. Obok długich tłumaczeń i wyjaśnień można tam też natrafić na dużą dozę niechęci i strachu ludzi przed Zope, z którego wywodzi się repoze.bfg. W dużej mierze wynika to jednak z braku wiedzy na temat tego czym jest Zope. Moim zdaniem komponenty wywodzące się z Zope, w tym architektura komponentowa (ang. Zope Component Architecture, ZCA) sprawią, że Pyramid będzie naprawdę elastycznym, dobrym frameworkiem. Warto mieć na niego oko.

Osobiście cieszę się, bo dobrze będzie mieć w Pythonie takie dwa frameworki jak Django i Pyramid. Cieszę się też, że używam Django, bo gdybym używał Pylonsów czy repoze.bfg to na dziś dzień miałbym przed sobą perspektywę migrowania aplikacji. Niby support ma być przez parę lat, ale zawsze to niefajnie pisać w czymś co ma już swojego lepszego następcę.

Front-Trends, czyli konferencja o front-endach

Fri, 05 Nov 2010 21:59:34 +0100

Konferencja Front-Trends, odbyła się w październiku w Warszawie i chociaż nie miałem okazji w niej uczestniczyć, to jednak poświęcam krótki wpis temu ciekawemu wydarzeniu.

Osobiście w Warszawie, w dniach 21-22 października, nie byłem, ale byli inni, w tym Mekk, który napisał taką relację z konferencji, ze czuję się jakbym tam był. Szacunek i serdeczne podziękowania.

Konferencja dotyczyła front-endów, stąd sporo mówiono podczas niej o JavaScripcie (który wcale nie jest tylko front-endowy), HTML 5, CSS 3. Pojawiły się też tematy związane z rozwiązaniami dla urządzeń mobilnych.

Wszystkich zainteresowanych zachęcam do przeczytania szczegółowych relacji Mekka:

Ja czytałem to z wywieszonym jęzorem ;)

Był sobie PyCon

Thu, 14 Oct 2010 22:24:16 +0100

W zeszłym tygodniu odbył się w Ustroniu trzeci polski PyCon. Byłem, widziałem, a oto moje wrażenia.

Rok temu na PyConie miałem zaszczyt wygłaszać prelekcję na temat Django oraz Pinaxa. Fajne doświadczenie, ale też wymagające sporej ilości czasu. Tego ostatniego w tym roku mi zabrakło, wobec czego pojechałem do Ustronia w charakterze zwykłego uczestnika.

Społeczność

Jak to ktoś ładnie napisał (Katharsis?) PyCon jest nieoficjalnym zlotem ludzi z kanału IRC #python.pl, a także #django-pl. Wyróżniamy się zwykle koszulkami z ładnymi nadrukami oraz przesiadywaniem w okolicach stołu bilardowego. Miło jest się ponownie spotkać lub zobaczyć po raz pierwszy (bo przecież kanały żyją i się rozrastają i ciągle pojawia się ktoś nowy) i oczywiście podyskutować na okołopythonowe tematy.

Zainteresowanych tym jak to wszystko naprawdę wyglądało odsyłam do blogów RMZ i Katharsisa, gdzie już są lub wkrótce pojawią się zdjęcia.

Oczywiście PyCon to też okazja do poznania ciekawych osób spoza IRC. W tym roku poznałem, o zgrozo, speców od Ruby On Rails z firmy Selleo. Nie znam RoR, ale mam do niego duży szacunek, tym ciekawiej było porozmawiać na temat różnic i podobieństw między tym frameworkiem a Django, a także ogólnie o Ruby i Pythonie oraz procesach wytwarzania oprogramowania. Tematów było zresztą więcej bo panowie imponowali rozległą wiedzą nie tylko techniczną ale i biznesową.

Technikalia

Z różnych względów nie byłem na wszystkich wykładach, ale spośród tych, które odwiedziłem najciekawsze były: warsztaty poprowadzone przez Marcina Bardzia na temat "Optymalizacji i profilingu metodami chałupniczymi" oraz prelekcja "Python: Fragmenty" Radomira Dopieralskiego.

Warsztaty pokazały w jaki sposób podejść do tematu badania wydajności kodu napisanego w Pythonie oraz jakie narzędzia można tu zastosować. Rzecz niewątpliwie przydatna w praktyce. Z kolei The Sheep, czyli Radomir, pokazywał "ciekawe" fragmenty kodu Pythona. Ciekawe czyli takie, które powodowały różne dziwne problemy, pomimo tego, że na pierwszy rzut oka wydawały się zupełnie w porządku. Bardzo pouczające, zachęcam do obejrzenia slajdów z tej prezentacji.

Bardzo fajna była też prezentacja Bartosza Krajnika na temat wykorzystania Pythona w laboratorium fizycznym. Nie jestem fizykiem, ale miło było zobaczyć jak dobrze sprawdza się Python w tym obszarze, tym bardziej, że wszystko było okraszone dużym entuzjazmem i poczuciem humoru prelegenta. Wykład ten bardzo dobrze uzupełnił wcześniejszą opowieść Mateusza Paprockiego o bibliotece SymPy podczas, której rosły serca wszystkim używającym Pythona matematykom.

Warto jeszcze wspomnieć lighting talka wygłoszonego przez reprezentanta MegiTeam, rozpoczętego słowami: "Jeśli serwujecie swoje serwisy WWW używając Apache to robicie źle". W ciekawy i nieco kontrowersyjny sposób mówca zachęcał do używania nginxa, przedstawiając liczne argumenty na poparcie swojej tezy. W skrócie nginx jest szybszy, stabilniejszy ("napisany w starym dobrym radzieckim stylu" i nigdy się nie wysypał) oraz bezpieczniejszy (odporny na DDOSy) niż Apache. No to się zainteresowałem cherokee...

Brakowało niestety jakichś talków na tematy związane z web developmentem. Jedynym wyjątkiem była krótka prezentacja o Plone 4, nieźle zrobiona, ale w przyszłym roku chciałbym zostać przekonany do tego, że warto używać Plone. Na dziś dzień wiem, że Plone się rozwija, ale chciałbym się dowiedzieć się jak z tym pracować na codzień, a przede wszystkim jak wygląda obecnie sprawa pisania własnych rozszerzeń. Niestety Zope, na którym Plone bazuje, a którego swego czasu używałem, zawsze miał słabą dokumentację. Znacznie bogatsza dokumentacja samego Plone też nie była rewelacyjna - były to raczej krótkie how-to, które doś szybko się dezaktualizowały. Niestety, ale doskonała dokumentacja Django rozpieszcza.

Podsumowanie

Ogólnie było naprawdę fajnie i jestem zadowolony, że tam byłem. Cieszy duża ilość osób, w tym sporej grupy dziewczyn. Niedociągnięć i słabszych talków też by się kilka znalazło, ale właściwie narzekać mogę tylko na brak prelekcji o web developmencie, który mnie najbardziej interesuje. Rok temu był buildout Dominika Szopy i legendarny już talk o obsysaniu Jarka Zgody, tym razem praktycznie nic. Nawiasem mówiąc to odniosłem wrażenie, że mało kto pamięta prawdziwy sens tej ostatniej prezentacji. Zachecam do przyjrzenia się slajdom i wyczytania między wierszami co tak naprawdę obsysało. To tyle. Do zobaczenia za rok.

Templates in django project

Wed, 30 Jun 2010 22:05:22 +0100

A smart way of placing templates in your django project.

So you're starting a new project in Django? One thing you'll obviously want are templates and you'll have to decide where to put them.

The Default Way

The method I used for a long time is the method described in Django Tutorial and used for example in Pinax. It is based on templates folder(s) which is placed somewhere in your filesystem, most often directly in your project's root.

- project
    -apps
        -app1
        -app2
    -templates
        -app1 (templates for app1)
        -app2 (templates for app2)
    -other folders/files

To get it working some configuration in settings.py is also required:

# Configure Django to first load templates from filesystem
# and then from application directories
# These are default settings
TEMPLATE_LOADERS = [
    "django.template.loaders.filesystem.Loader",
    "django.template.loaders.app_directories.Loader",
 ]

# Define where exactly Django should look for templates
PROJECT_ROOT = os.path.abspath(os.path.dirname(__file__))
TEMPLATE_DIRS = [
    os.path.join(PROJECT_ROOT, "templates"),
]

You can read more about settings used above here.

With this simple config you can create a theme for your project. Just start creating templates in templates directory. It is important to remember that it is prefferable to place templates in subdirectories to keep templates for specific apps separated.

However there are inconveniences with this configuration:

First is about templatetags - if you need a tag to render something project specific where should you place it's code? You need to create a dedicated application for this case.
Second is about i18n - to generate locales only for templates in Django < 1.2 it was required to manually move apps folders out of project directory, then call bin/django makessages -l pl (or whatever lang you use) and after that move apps back to project directory. Why? Because makemessages browses all folders under current folder so it would generate locales also for applications from apps. The good news is that Django 1.2 has provided --ignore option to makemessages that allows exclusion of some directories while generating messagefiles.

The LFC Way

The method I use now is based on a LFC's way of doing things. It is very simple and doesn't have inconveniences of previous method.

The main concept here is an application. Your theme is just an ordinary application, so instead of defining TEMPLATE_DIRS it is enough to add yourproject_theme app to INSTALLED_APPS.

Django searches for templates in apps specified in INSTALLED_APPS browsing them in order of definition so it is important to place yourproject_theme application before any other applications. For example:

INSTALLED_APPS = (
    "lfc_theme",
    "django.contrib.admin",
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    "django.contrib.flatpages",
    "django.contrib.sitemaps",
    "django.contrib.comments",
    "django_extensions",
    "lfc",
    "lfc_blog",
    "portlets",
    "tagging",
    "contact_form",
    "pagination",
    "workflows",
    "permissions",
    "gunicorn",
)

Main advantages of having a theme as an application are that you can have locales, templatetags and even static files as well as project specific utility functions in one place - your theme application.

Curious about example? Look into LFC Theme.

Summary

Both methods are simple to use but the second has advantages and IMHO results in a cleaner structure of a project.

Django-LFC

Fri, 07 May 2010 00:12:36 +0100

New shining star in the world of Django: Lighting Fast CMS - sneak preview

Django and CMS projects

This post was updated on 2010-07-05

Django and CMS projects

Some time ago I wrote about Django powered CMS projects. In particular I described django-cms and also mentioned Fein CMS. Both projects are really good ones (compare them) but... their competitor has just arrived (ok, almost because it is still in alpha) - Lighting Fast CMS.

LFC comes from the author of Lighting Fast Shop and shares some elements with that project so if you used LFS you will be positively surprised.

A bite of django-lfc

My first impression was: "oh.. it's plonish!". Yup, LFC resembles Plone to me - I really like this kind of clean interface and available options. It's not Django's Admin any more (see django-cms and feincms) but LFC's own management panel.

LFC is intuitive. I was able to set up a simple site without reading any docs. Of course there are docs! It is important thing in any serious project and LFC is going to be serious.

Full list of LFC features is rather long, so if you are interested just follow the link. I especially like: content types, portlets,

authorisation based on mapping between roles and permissions

and... workflows.

There is no rose without a thorn

Sadly, LFC is not yet 1.0 final, so nobody can expect it to be bug free and in fact there is some bugs. For example it is quite easy to set up running instance of LFC using buildout, but it quickly turns out that it is limited to work on supplied sqlite database only. There are still some problems that make it hard to run LFC on other database engines like postgres. However, everything is possible so if you're interested in how to set up current (1.0 alpha 8 - "Man o' War") release of LFC to work with postgres please read on.

LFC and Postgres

You can read about LFC installation in the official docs. The important part is to call:

hg clone http://bitbucket.org/diefenbach/lfc-buildout-development

to get a local copy of LFC.

However, in my case, before I performed the next step in installation process I had to modify buildout.cfg. Here is mine:

[buildout]
parts =
    PIL
    django
    lfc
    lfc_theme
    lfc_blog
    tagging
    contact-form
    django-fcgi
    permissions
    portlets
    workflows

[lfc]
recipe = mercurialrecipe
repository = http://bitbucket.org/diefenbach/django-lfc/

[lfc_theme]
recipe = mercurialrecipe
repository = http://bitbucket.org/diefenbach/lfc-theme

[lfc_blog]
recipe = mercurialrecipe
repository = http://bitbucket.org/diefenbach/lfc-blog

[permissions]
recipe = mercurialrecipe
repository = http://bitbucket.org/diefenbach/django-permissions

[portlets]
recipe = mercurialrecipe
repository = http://bitbucket.org/diefenbach/django-portlets

[workflows]
recipe = mercurialrecipe
repository = http://bitbucket.org/diefenbach/django-workflows

[tagging]
recipe = mercurialrecipe
repository = http://bitbucket.org/fivethreeo/django-tagging-inheritance/

[PIL]
recipe = zc.recipe.egg:custom
egg = PIL==1.1.6
find-links = http://dist.repoze.org/

[contact-form]
recipe = gocept.download
url = http://bitbucket.org/ubernostrum/django-contact-form/get/1d3791fa4dfb.zip
md5sum = 8e3e257fda807fef5f3abcc6b5beb398

[django-fcgi]
recipe = collective.recipe.template
port  = 8000
input = ${buildout:directory}/misc/conf/django-fcgi.sh.in
output = ${buildout:directory}/bin/django-fcgi.sh

[django]
recipe = djangorecipe
version = http://code.djangoproject.com/svn/django/branches/releases/1.1.X
eggs =
    PIL==1.1.6
    psycopg2
    feedparser
    pysqlite
    django-pagination
    django-extensions

project = lfc_project
settings=settings
extra-paths =
    ${buildout:directory}/lfc_project
    ${buildout:directory}/parts/permissions
    ${buildout:directory}/parts/workflows
    ${tagging:location}
    ${contact-form:location}
    ${lfc:location}
    ${lfc_theme:location}
    ${lfc_blog:location}
    ${permissions:location}
    ${workflows:location}
    ${portlets:location}

urls = lfc_project/urls

My modifications included:

setting a specific version of PIL (PIL == 1.1.6) - otherwise there was an import error
setting a specific version of Django - to include some patches for bugs that were causing LFC to raise exceptions when used with postgres

After everything was installed I changed settings.py to configure postgres database there.

My next step was to comment out last line: post_syncdb.connect(register) in parts/lfc/models.py. This line makes register function to be called on syncdb signal, but there is a problem because register is called multiple times. This breaks something when register function is trying to add the same objects for the second time (there is an unique index) raising database transaction errors.

After commenting the line out I ran syncdb and successfully created database tables and my superuser. Then I uncommented the line and called syncdb again. This raised an error but in general it worked registering important things like portlets, templates and content types.

Updated content: The last thing to do is to load some data. There is a helpful script initialize_lfc.py in scripts directory, so it is enough to start Django's shell (bin/django shell) and run:

from scripts import initialize_lfc
initialize_lfc.run()

The last thing I had to do was to add a Portal instance. To accomplish this I disabled lfc.context_processors.main context processor and added django.contrib.admin to INSTALLED_APPS in settings.py. I also added (r'^admin/(.*)', admin.site.root), to urls.py. Then I was able to enter admin panel and add Portal object there. After adding Portal I enabled (uncommented) lfc.context_processors.main and was able to work with LFC management panel.

After doing the above I was able to add things through admin panel. For example I got an exception when I tried to enter "Roles" menu. I had to add a role in admin to overcome this.

Another thing I did was to call bin/django loaddata to load predefined fixtures from LFS apps (you can find it in parts directory). I'm not sure why but these fixutres are not loaded automatically.

Summary

LFC has some cool features, not so bad docs and good hmm... feeling. I just like it, it's nice, pretty, it has good clean website containing even screencasts (to be honest I don't like screencasts so I didn't watch them :D). I'm going to use LFC in my project soon. It's not yet 1.0 but it already has some live sites. I'm sure it will be a serious competitor to django-cms and feincms, so don't bother to give it a try.

Django i formularze

Thu, 14 Jan 2010 21:32:05 +0100

Formularze są jednym z ważniejszych atutów Django. W tym krótkim wpisie wskazuję dwa artykuły przedstawiające różne ciekawe sposoby pracy z formularzami oraz pewną interesującą aplikację.

Zbiegi okoliczności jak najbardziej istnieją. Nie dalej jak wczoraj wgryzałem się w różne ciekawe triki dotyczące wykorzystania formularzy, a w dniu dzisiejszym niejaki Shabda opublikował artykuł na ten właśnie temat. Artykuł na tyle dobry, że skłonił mnie do wrzucenia tu informacji o nim oraz o jeszcze kilku ciekawostkach związanych z formularzami. Zapraszam do zapoznania się z poniższymi materiałami:

Shabda o tym co można zrobić z formularzami
James Bennet o dynamicznych formularzach
django-uni-form czyli formularze w divach

O Buildoucie i Django

Sun, 27 Dec 2009 00:20:30 +0100

Buildout to stworzony w języku Python system służący do zautomatyzowanego budowania oprogramowania. Oprogramowania zwykle złożonego z wielu różnych części, niekoniecznie opartych na Pythonie.

Buildout?

Z Buildoutem zetknąłem się po raz pierwszy wiele lat temu, gdy jeszcze bliżej było mi do Zope niż do Django. Zetknąłem się nie znaczy, że go używałem, ale jak mówi staropolskie powiedzenie "co się odwlecze to nie uciecze" i wygląda na to, że czas Buildouta nastał właśnie teraz. Owo teraz zaczęło się od Dominika "Dominno" Szopy i jego prezentacji na temat Buildouta, którą wygłosił na konferencji PyConPL. Temat na tyle mnie zainteresował, że postanowiłem zapoznać się z buildoutem bliżej i... jestem pozytywnie zaskoczony. W tym wpisie podzielę się kilkoma spostrzeżeniami na temat wykorzystania Buildouta we własnym projekcie Django.

Wprowadzenie do Buildouta

Najciekawsze wprowadzenie do Buildouta w języku polskim to artykuł wspomnianego Dominika Szopy z PyConPL. Niestety nie jest on chyba dostępny w Sieci (a przynajmniej nie potrafię go znaleźć), pozostaje więc zapoznanie się z samą tylko prezentacją Dominika oraz anglojęzycznymi materiałami. Poniżej kilka słów wprowadzenia w temat ode mnie, a potem linki do wybranych tutoriali.

Buildout z bliska

Buildout pozwala na zautomatyzowane instalowanie aplikacji wraz ze wszystkimi zależnościami. Jak można się spodziewać, aby taka zautomatyzowana instalacja zadziałała po pierwsze potrzebny jest Buildout, a po drugie plik konfiguracyjny, w którym znajdą się przepisy wskazujące co ma być zainstalowane. W praktyce oznacza to, że potrzebne są dwa pliki: bootstrap.py oraz buildout.cfg.

Żeby zainstalować Buildouta wystarczy pobrać i uruchomić skrypt bootstrap.py.

[ext@sandarcher buildout]$ 
    wget http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py
    (...)
    2009-12-25 23:17:02 (228 KB/s) - zapisano `bootstrap.py' [3807]
[ext@sandarcher buildout]$ touch buildout.cfg
[ext@sandarcher buildout]$ ls
    bootstrap.py buildout.cfg
[ext@sandarcher buildout]$ python bootstrap.py 
    Creating directory '/home/ext/tmp/buildout/bin'.
    Creating directory '/home/ext/tmp/buildout/parts'.
    Creating directory '/home/ext/tmp/buildout/eggs'.
    Creating directory '/home/ext/tmp/buildout/develop-eggs'.
    Generated script '/home/ext/tmp/buildout/bin/buildout'.

Następnie należy wywołać polecenie bin/buildout, co spowoduje, że Buildout zainstaluje to co zostało zdefiniowane w pliku konfiguracyjnym buildout.cfg.

W skrótcie to tyle, ale warto jeszcze wspomnieć o tym co znajduje się w pliku konfiguracyjnym. Otóż Buildout oparty jest na recipes czyli przepisach. Każdy przepis powoduje wykonanie różnych czynności, takich jak na przykład: zainstalowanie Django, stworzenie skrótu na dysku, czy zainstalowanie pakietu przez configure, make, make install. Tworząc plik konfiguracyjny wpisuje się w nim konkretne przepisy i podaje im parametry.

Więcej szczegółowych informacji o Buildoucie znaleźć można wśród poniższych materiałów:

Struktura plików i katalogów

Tutoriale tutorialami, ale tym co mnie najbardziej interesowało było to jak "zbuildoutować" mój istniejący, lub właśnie tworzony projekt w Django. Jakie stworzyć katalogi, gdzie umieścić konfig Buildouta, itp itd. Z powyższych materiałów niestety nie wynika to wprost dlatego przedstawię tu mój sposób. Jeśli ktoś zna lepszy lub inny to zapraszam do komentowania.

Jak już wspomniałem Buildout wymaga w zasadzie dwóch plików: konfiguracyjnego buildout.cfg oraz inicjalizującego środowisko bootstrap.py. Ja do tego dokładam jeszcze projekt djangowy i w efekcie moja struktura plików i katalogów wygląda następująco:

- bootstrap.py
- buildout.cfg
- project/ (katalog z moim projektem)

To, że mój projekt nazywa się "project" jest zapisane w konfiguracji dla Buildouta - będzie to widoczne w przedstawionym nieco dalej fragmencie buildout.cfg w sekcji [django].

Powyższe umieszczam w repozytorium, po czym wykonuję np. na innym serwerze checkout (pobranie z repozytorium), odpalam bootstrap.py (instalacja Buildouta) i wywołuję bin/buildout (instalacja projektu i zależności). W efekcie uzyskuję w pełni skonfigurowane środowisko do uruchamiania projektu.

Odrobina customizacji

Wśród wielu przydatnych opcji Buildouta warto wspomnieć o rozszerzaniu plików konfiguracyjnych. Rozszerzanie pozwala na zdefiniowanie różnych plików konfiguracyjnych np. dla środowiska deweloperskiego czy testowego, które bazując na innym pliku konfiguracyjnym modyfikują niektóre spośród zawartych w nim ustawień.

Fragment przykładowego pliku buildout.cfg:

[buildout]
parts = PIL django omlette cms-media

[PIL]
recipe = zc.recipe.egg
eggs = PIL==1.1.6
find-links = http://dist.repoze.org

[django]
recipe = djangorecipe
version = 1.1
project = project
eggs =
     PIL == 1.1.6
     psycopg2
     egenix-mx-base
     south
     django-reversion
     django-tinymce
     django-cms
wsgi = true
settings = production
extra-paths = ${buildout:directory}/project/apps
(...)

Powyższa konfiguracja instaluje PIL oraz kilka bibliotek i aplikacji określonych w sekcji eggs. Warto tu także zwrócić uwagę na ciekawe ustawienia w przepisie dla Django, takie jak "wsgi=True", które określa czy ma być generowany skrypt .wsgi pozwalający na uruchamianie projektu spod mod_wsgi oraz "settings=production" wskazujące jaki plik jest plikiem konfiguracyjnym projektu. Wpis "extra-paths" pozwala na określenie ścieżek, które zostaną dodane do PYTHONPATH, w tym przypadku jest to folder "apps" w moim projekcie, w którym to folderze trzymam wykonane na potrzeby projektu aplikacje.

Przykładowy plik devel.cfg dla środowiska deweloperskiego:

[buildout]
extends = buildout.cfg

[django]
wsgi=false
settings=development

Plik devel.cfg rozszerza konfigurację zawartą w buildout.cfg poprzez modyfikację ustawień dla sekcji [django]. Sekcja ta to przepis instalujący Django, który zostaje tu ustawiony tak, aby w środowisku deweloperskim nie generował pliku .wsgi oraz aby używał pliku o nazwie development.py jako konfiguracji Django.

Jak korzystać z takich rozszerzających plików konfiguracyjnych? Bardzo prosto:

bin/buildout -c devel.cfg

Uwaga na PIL

PIL czyli Python Imaging Library jest bardzo często wykorzystywany przez różne aplikacje Django (mam tu na myśli głównie aplikacje do wielokrotnego wykorzystania (ang. reusable apps)). Niestety biblioteka ta od zawsze sprawiała kłopoty przy instalacji i tak samo było podczas moich eksperymentów z PILem i Buildoutem. Żaden ze sposobów instalacji PIL podany w podlinkowanych wyżej materiałach nie chciał zadziałać. PIL instalował się w złej wersji, albo w dwóch różnych wersjach i Django nie chciało go "zobaczyć". Przyczyną problemu okazało się to, że wydana została nowa wersja PIL, a rozwiązanie polegało na określeniu w pliku konfiguracyjnym w dwóch miejscach dokładnej wersji PIL, co widać w przykładzie poniżej.

[PIL]
recipe = zc.recipe.egg
eggs = PIL==1.1.6
find-links = http://dist.repoze.org

[django]
recipe = djangorecipe
version = 1.1
project = project
eggs =
     PIL == 1.1.6

Jeśli więc po przeczytaniu tutoriala do Buildouta występują problemy z instalacją PIL sugeruję wypróbować powyższą konfigurację.

Dlaczego buildout a nie PIP?

PIP czyli Pip Installs Packages to narzędzie zastępujące easy_install. Tym co czyni PIP podobnym do Buildouta są pliki wymagań (ang. requirements), które pozwalają na zdefiniowanie zestawu pakietów do zainstalowania. Taki plik wymagań ma zwykle bardzo prostą postać np.:

MyApp
Framework==0.9.4
Library>=0.2
-e svn+http://myrepo/svn/MyApp#egg=MyApp

Pierwsze trzy wpisy określają konkretne biblioteki do zainstalowania (np. z PyPi), ostatnia linia wskazuje, że zainstalowana ma być aplikacja z repozytorium svn. Jeśli plik wymagań nazywa się requirements.txt to możemy zainstalować zdefiniowane w nim pakiety wydając polecenie:

pip install -r requirements.txt

Co bardzo istotne, zadaniem PIPa jest instalowanie pakietów Pythona, które są stworzone zgodnie ze standarowymi sposobami dystrybucji (zdefiniowanymi w distutils). Oznacza to, że każdy instalowany pakiet musi być pakietem pythonowym oraz musi posiadać prawidłowy plik setup.py.

Chociaż PIP i jego pliki wymagań sprawdzają się w wielu projektach (wiem bo sam korzystam) to jednak PIP ma pewne istotne ograniczenia i tak naprawdę jest narzędziem przeznaczonym do czegoś innego niż Buildout, który ma po prostu znacznie większe możliwości. Najlepszym dowodem na to jest fakt, że istnieje dla Buildouta przepis pozwalający na instalacje pakietów za pomocą PIP.

Dlaczego virtualenv i Buildout?

Na koniec kilka słów na temat virtualenv i Buildouta. Virtualenv to narzędzie do tworzenia wirtualnych wyizolowanych środowisk Pythona. W praktyce Buildout instalując aplikacje i różne pakiety działa nieco podobnie do virtualenva, gdyż umieszcza je w swoich własnych katalogach (wygenerowanych przez bootstrap.py) i nie narusza systemowego Pythona.

Kiedy więc warto połączyć virtualenv z Buildoutem? Otóż wtedy, gdy chcemy aby tworzone środowisko nie korzystało w ogóle z bibliotek z systemowego Pythona. Wówczas należy wygenerować nowe wirtualne środowisko za uruchamiając polecenie virtualenv z parametrem --no-site-packages i dopiero w nim uruchomić Buildouta.

Podsumowanie

Buildout jest narzędziem, którym zdecydowanie warto się zainteresować, po to aby... ułatwić sobie życie. Buildout przydaje się zarówno przy umieszczaniu projektu w wielu różnych środowiskach (deweloperskim, testowym, produkcyjnym) jak i przy pracy grupowej, gdy trzeba zainstalować projekt u kilku deweloperów. Ze swojej strony zdecydowanie zachęcem do wypróbowania Buildouta we własnych projektach.