Od wielu lat pasjonuję się IT. Zaczęło się od gier, w które grałem początkowo na Atari 65XE, a potem na różnych wersjach Amigi. W końcu nastała era PC-tów, a ja porzuciłem gry na rzecz oprogramowania i jego szeroko rozumianego tworzenia, czym zajmuję się do dziś.
Dni Wolnego Oprogramowania
Kilka słów na temat Dni Wolnego Oprogramowania, od prawie uczestnika
W dniach 2-4 marca 2012 odbyły się w Bielsku-Białej V już Dni Wolnego Oprogramowania. DWO to cykliczna impreza organizowana głównie za sprawą Dominika Kozaczko, przy wsparciu m.in. Polskiej Grupy Użytkowników Linuxa (PLUG), poświęcona… nie tylko wolnemu oprogramowaniu. Nie tylko, gdyż tematyka jest zwykle bardzo różnorodna, a przy tym ciekawa.
Przyznaję bez bicia, że nigdy wcześniej na DWO nie byłem. Trochę mi się one kojarzyły z imprezą dla licealistów (niesłusznie), a do tego to tak już jakoś jest, że na imprezę w moim rodzinnym mieście jest mi trudniej wpaść niż na event odbywający się kilkadziesiąt czy nawet kilkaset kilometrów dalej.
W tym roku tradycyjnie nie miałem na DWO czasu, ale splot wydarzeń (dziękuję Filipie) sprawił, że jednak na chwilę na konferencję wpadłem.
Już na samym początku zaskoczyło mnie to, że większa część wykładów odbywała się nie w budynku LO nr 5 (jak to, z tego co wiem, bywało do tej pory), ale w sali Bielskiej Wyższej Szkoły im. J. Tyszkiewicza. To chyba dobry pomysł, bo jak usłyszałem od jednego z uczestników: “teraz to jest konferencja, wcześniej to było trochę jak na zajęciach w szkole”.
Faktycznie, potwierdzam, że organizacja była bardzo dobra – bez problemu trafiłem pod odpowiednią salę, gdzie miłe 
dziewczyny próbowały mnie zarejestrować (przepraszam, że nie skorzystałem, ja tam byłem tylko przelotem), a w samej sali wykładowej do dyspozycji uczestników była kawa, napoje i cała masa ciastek i innych przekąsek. Zdecydowanie organizacja przypomniała mi najlepsze dokonania PLUGa np. w postaci PyconPL.
Sednem konferencji jednak nie są ciasteczka, ale ludzie, których można tam spotkać oraz wykłady. Te elementy pozytywnie mnie zaskoczyły, zatem małe podsumowanie pozytywów:
- Agenda konferencji świadczy o tym, że warto na niej być – jest ciekawie imho dla każdego informatyka
- Widziałem sesję q&a po wykładzie Mateusza Juścińskiego i przyznaję, że mi się podobało. Humor i pewność siebie prowadzącego powalały. Do tego sam temat był ciekawy – na tyle na ile udało mi się wywnioskować z pytań i odpowiedzi to dotyczył systemów continuous integration i ogólnie ciekawych technologii jak git. Szkoda tylko, że ta cała fantastyczność działa na rzecz… PHP.
- Widziałem też wykład Stanisława “dozziego” Klekota i o ile tu temat niezbyt mnie interesował to jednak sam talk był poprowadzony całkiem fajnie i przebijał z niego profesjonalizm oraz wiedza prowadzącego. Jeśli pozostałe wykłady były na podobnym poziomie to naprawdę musiało być nieźle.
- Fajna duża sala, a na niej naprawdę sporo uczestników, ot konferencja pełną gębą.
- Ludzie. Dostrzegłem na sali kilka znanych mi osób i to takich, które nie są byle kim (zdecydowanie to nie jest, jak napisałem wyżej, konferencja dedykowana dla licealistów). Byli np. spece od Rubiego, a także, co mnie szczególnie cieszy, pokaźna ekipa djangowa. Ba, był nawet talk (niestety nie widziałem go) podsumowujący niedawny Django sprint, który odbył się w Krakowie i w którym miałem przyjemność uczestniczyć.
Podsumowując, muszę powiedzieć, że moja króciutka bytność na DWO była… fajna i to fajna na tyle, aby napisać pierwszego od roku posta na tym blogu. DWO to po prostu dobra konferencja, która mam nadzieję będzie się dalej rozwijać.
JavaScript, Mobile i DevMeetings
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 
Przezroczyste PNG w IE6 – ciąg dalszy
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
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
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
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
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 a django project
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
appsfolders out of project directory, then callbin/django makessages -l pl(or whatever lang you use) and after that moveappsback 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--ignoreoption 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
New shining star in the world of Django: Lighting Fast CMS – sneak preview
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 ). 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
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