Do what you have to do
Štítky Python
NoSQL databáze jako cache
21. Zář
Posledních několik dní jsem byl zavalen přítelkyní, školou a prací, že jsem se k blogování téměř nedostal. Trpí tím hlavně slíbené seriály, z nich Django bych chtěl dopsat ve středu večer. O víkendu jsem byl ve škole, což byla tentokrát, krom nebezpečného večera, ohromná kupa nudy a začal jsem si číst o NoSQL, které jsem se o pár hodin později pokusil použít v administraci pro Roští.cz a docela se mi zalíbilo.
Především jsem řešil následující problém. Administrace při vytváření nového uživatele čte nějaké údaje ze systému (třeba jestli má daný uživatel vytvoření účet). K těm se dostává přes SSH a autentizaci řeším klíči. Takovýhle proces jsem zvolil kvůli tomu, že mohu mít v jedné administraci uživatele rozložené přes několik serverů. Admin jim pak dává vědět kde mají databázi, kde vyzvedávat e-maily atd. Problém nastává v době, kdy potřebuju při každém kliku na přidání PostgreSQL databáze zjistit, jestli má už daný člověk vytvořený účet. To se udělá jednoduše. Připojím se přes SSH na server kde by měl účet mít a pomocí psql se dopátrám odpovědi. Jenže tahle sranda stojí dost času, který já sice mám, ale uživatel už ne a to nejlepší co by mohl udělat, je kliknout několikrát.
No rozhodl jsem se tyto prodlevy odstranit NoSQL stylem a postavit nad dotazování cache. Na základě těchto hodnot pak budu moct hromadně vypisovat stav konfigurace jednotlivých uživatelů. U všech takto udržovaných hodnot (zatím existence účtu pro MySQL a PostgreSQL) řeším i opětovné vytvoření záznamu v cache, pokud ten zmizí, ale správně by tam měl být. Když se ještě dokopu k tomu, abych doplnil k mé implementaci keystore databáze expiraci, tak budu moct udržovat téměř reálná data, i když se v systému něco změní. Takové případy nejsou nikdy dobré a spíš povedou k debugovacím hlášením v mé e-mailové schránce, takže bych to nazval nejistým jistícím mechanizmem, protože při změně v systému se klíč z databáze prostě neodstraní.
Doba takové expirace pak závisí na tom, jak „jistou“ konzistenci dat bych si přál a jak pohodlné by to měl uživatel. Když dám expiraci na hodinu, využije se cache na aktuální změny na účtu, což u administrace hostingu bohatě stačí. Ale už taková cache nejde využít pro prohlížení statistik jednotlivých uživatelů. Expirace v takovém případě nepřinese nic dobrého, takže se ještě rozmýšlím.
Implementaci jsem udělal nad Djangem a jeho databázovým modelem. K tomu jsem si udělal čtyři jednoduché funkce kset(), kget(), krm() a klist(). V aplikaci pak jednoduše vytvářím, čtu a ruším klíče. U časově náročných operací, kde výsledkem je nějaká informace, to bude neocenitelný pomocník.
Django má vcelku dobrou podporu třeba pro NoSQL databázi redis a to díky projektu django-kvstore. Nicméně se mi zdá použití zbytečně složité a navíc by se ukládala další data někde jinde, jako kdyby nestačilo, že musím vytvářet cache pro získání konfigurace systému. Vytvořením dalšího úložiště bych si mohl zadělat na problémy.
Tohle je vlastně poprvé, kdy jsem se setkal s implementací cache v nějakém projektu. I když některé mé weby dělají desítku SQL dotazů na jeden klik, nikdy se to nedostalo do takových mezí, že by to bylo vidět třeba na loadu serveru. Cache ale v tomto případě odstraní několika sekundové čekání, které by měl uživatel s každým klikem podstoupit. Náhodou jsem si NoSQL spojil s mým projektem v době, kdy jsem implementoval nové funkce, které toho dokáží využít. Navíc se dá moje keystore databáze využít i pro konfiguraci některých parametrů.
Django #2: začínáme
13. Zář
Po malém zpoždění tu máme druhý díl seriálu o webovém frameworku Django. Dneska si ukážeme jak vytvořit kostru projektu, vysvětlíme si jak funguje nastavení, kde o něm najdeme informace a také si povíme o aplikacích a projektech. Aplikace je potřeba se naučit používat správně, protože vám to může ušetřit hodně práce u projektů jiných. Více se jim ale budeme věnovat až v příštím díle.
Django programátory nutí, aby si udržovali pořádek a když začínáte nějaký projekt, měli byste se podle toho zařídit a rozmyslet si, jak bude rozdělený. V Djangu se projekty rozdělují na aplikace a když je využijete dobře, budete moct přenést funkcionalitu z jednoho projektu do druhého s minimálním zasahováním do pythoního kódu a největší bolest vám bude působit „jen“ předělání šablon.
Aplikace mohou být různé, může jít o kostru uživatelského rozhraní, mohou to být komentáře, galerie, knihy návštěv, fóra, články, blogy, nálepky, kategorie, prostě co fantazie a schopnosti dovolí. Mnoho aplikací je možné stáhnout od jiných programátorů a o některých bude řeč i v tomto seriálu. Jeden projekt se dá napsat pouze v jedné aplikaci, ale určitě sami uznáte, že by to mohlo být trochu nepřehledné. Taky není dobré pro každou tabulku vytvářet zvláštní aplikaci. Například kategorie pro články určitě nebudou to samé co kategorie pro bazar a přenos bazaru do projektu, kde už jsou články, by s oddělenými kategoriemi mohlo přinést hodně práce navíc.
Lepší představu o aplikacích si uděláte s vytvořením prvního projektu. Předpokládám, že Django už máte nainstalované. Pokud ne, tak na Linuxu, konkrétně na Debianu/Ubuntu, je to docela jednoduché:
-
$ sudo apt-get install python-django
U jiných distribucí to je na vás. Taky zvažte použití návodu popsaného v jednom z mých minulých postů. U Djanga nic dalšího nepotřebujete. Má v sobě testovací webový server, přes který si projekt spustíte na nějakém vyšším portu a můžete směle testovat. Proti PHP, kde se musí instalovat a konfigurovat webový server, to pro vás bude asi příjemná změna. Pro mě byla. Navíc Django disponuje ladícími utilitami jak integrovanými, tak od třetích stran, které se velmi jednoduše používají a dají vám přesný přehled o tom, co se děje, jak vypadal požadavek, co je ve které proměnné a nebo kolik se udělalo SQL dotazů.
První projekt
Nadešel čas vytvořit projekt:
-
$ cd ~/co
-
$ django-admin startproject myexperiences
Po spuštění se vytvoří adresář myexperiences, který obsahuje:
-
$ cd myexperiences
-
$ ls
-
__init__.py manage.py settings.py urls.py
Než se vrhneme na vytvoření první aplikace, popíšeme si to co se ve vytvořeném adresáři objevilo.
- __init__.py – tímto řekneme pythonu, že tady má hledat pythoní soubory
- manage.py – skript pro správu projektu
- settings.py – nastavení projektu (databáze, jazyk, aplikace, …)
- urls.py – mapování URL na metody a funkce v aplikacích
Správa projektu
Skript pro správu vám umožní manipulovat s projektem a to ve smyslu spouštění testovacího serveru, testovací konzole, kompilování lokalizačních souborů, vytváření aplikací a mnoho dalšího. Po zadání python manage.py help dostanete vše co potřebujete vědět, ale vyzdvihl bych tu několik voleb, které se vám budou do začátku hodit:
- reset název_aplikace – resetuje SQL tabulky patřící k nějaké databázi
- runserver [ip:port] – spustí testovací server
- shell – testovací shell
- dbshell – stejné jako shell, ale vypisuje provedené SQL příkazy
- sql název_aplikace – vypíše inicializační SQL příkazy k zadané aplikaci
- startapp název_aplikace – připraví strukturu pro aplikaci
- syncdb – vytvoří SQL tabulky v databázi pokud neexistují
- help [příkaz] – nápověda k jednotlivým příkazům
Nastavení
Centrem každého projektu je soubor settings.py. Ten nemusí mít vždy tento název a až budeme konfigurovat WSGI, tak si ukážeme, jak lze jednu aplikaci spustit v několika instancích a lišit se budou jen tímto souborem. Django je na to samozřejmě připraveno. Je zde definováno jaké se mají načíst middlewary (o těch bude řeč až za hodně dlouho) a aplikace, kde je databáze a jak se k ní připojit, kde se mají brát šablony, jaký má být použit jazyk, jestli má být spuštěno ladění, kde jsou uložena statická data a na jaké e-maily mají být zasílána chybová hlášení, pokud je vypnuto ladění. To jsou hodnoty, které uvidíte na první pohled po otevřený souboru settings.py, ale dokumentace je mnohem bohatší. Ta odkrývá zákoutí e-mailové komunikace, ochrany CSRF, kódování, formátu času a data, jemnější nastavení šablon a mnoho, mnoho dalšího.
My se zatím budeme věnovat tomu, co nám Django vychrlilo ve výchozím nastavení. Soubor je velmi dobře okomentován, ale já si dovolím komentáře smazat a nahradit je svými.
-
# -*- coding: utf-8 -*-
-
-
# Konfigurace projektu myexperiences
-
-
# Ladění
-
DEBUG = True
-
TEMPLATE_DEBUG = DEBUG
-
-
# Sem dejte svoje jméno a e-mail. Když vypnete ladění, budou vám sem pak chodit chyby.
-
ADMINS = (
-
(‘Adam Štrauch’, ‘cx@initd.cz’),
-
)
-
-
MANAGERS = ADMINS
-
-
# Od Djanga 1.2 můžete využívat spojení s více databázemi.
-
# To vám pomůže především při rozložení zátěže nebo při
-
# vytváření on-line zrdcadla. Zatím nám bude stačit jedna
-
# databáze s označením default.
-
DATABASES = {
-
‘default’: {
-
# Databázový engine, na výběr máte:
-
# postgresql_psycopg2, postgresql, mysql,
-
# sqlite3 a oracle. Další enginy lze nalézt u
-
# jiných vývojářů a existuje i podpora noSQL
-
# databází
-
‘ENGINE’: ‘django.db.backends.postgresql_psycopg2′,
-
‘NAME’: ‘myexperiences’, # Název databáze – povinné
-
‘USER’: “, # Jméno uživatele – nepovinné
-
‘PASSWORD’: “, # Heslo – nepovinné
-
‘HOST’: “, # Server – nepovinné
-
‘PORT’: “, # Port – nepovinné
-
}
-
}
-
-
# Časová zóna. Dostupné zóny najdete zde:
-
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
-
TIME_ZONE = ‘Europe/Prague’
-
-
# Kód lokalizace. Dostupné kódy najdete zde:
-
# http://www.i18nguy.com/unicode/language-identifiers.html
-
LANGUAGE_CODE = ‘cs’
-
-
# ID stránky, nechte na 1
-
SITE_ID = 1
-
-
# Nechte True, pokud dáte False, vypne Django možnosti lokalizace
-
# vašeho projektu, ale ty my budeme později využívat.
-
USE_I18N = True
-
-
# Vypnutí či zapnutí lokalizace číselných hodnot.
-
USE_L10N = True
-
-
# Proměnná, která není standardní, ale používám jí, protože se s ní v
-
# projektu lépe pracuje
-
ROOT = ‘/home/cx/co/myexperiences/’
-
# Cesta k adresáři se statickými daty (styly, obrázky, skripty, ….)
-
# Důležité je lomítko na konci, bez něj nefungují některé instalace
-
# Djanga správně
-
MEDIA_ROOT = ROOT+‘m/’
-
-
# URL adresa k médiím. /media si zabrala administrace, takže dávám /m/
-
MEDIA_URL = ‘/m/’
-
-
# URL adresa k médiím Django administrace, není důvod měnit
-
ADMIN_MEDIA_PREFIX = ‘/media/’
-
-
# Tajný klíč, s nikým ho nesdílejte.
-
SECRET_KEY = ‘m#^o_b0uvk2!q^0$ebl*5(2y2vlc5!m!%ove8l#$6qeex3)$%f’
-
-
# Seznam "loaderů" šablon. V prvním případě se hledá v adresářích
-
# zapsaných v TEMPLATE_DIRS a druhé v pořadí jdou aplikace, ve kterých
-
# můžeme šablony ukládat do adresáře název_aplikace/templates.
-
TEMPLATE_LOADERS = (
-
‘django.template.loaders.filesystem.Loader’,
-
‘django.template.loaders.app_directories.Loader’,
-
)
-
-
# Procesy, kterými má požadavek projít, než se dostane do vašich rukou.
-
# Není důvod měnit.
-
MIDDLEWARE_CLASSES = (
-
‘django.middleware.common.CommonMiddleware’,
-
‘django.contrib.sessions.middleware.SessionMiddleware’,
-
‘django.middleware.csrf.CsrfViewMiddleware’,
-
‘django.contrib.auth.middleware.AuthenticationMiddleware’,
-
‘django.contrib.messages.middleware.MessageMiddleware’,
-
)
-
-
# Odkud se má začít s mapováním URL adres na metody a funkce. Také
-
# není důvod měnit.
-
ROOT_URLCONF = ‘myexperiences.urls’
-
-
# Seznam s adresáři se šablonami. Osobně raději preferuji držet šablony uvnitř
-
# aplikace.
-
TEMPLATE_DIRS = (
-
)
-
-
# Seznam instalovaných aplikací. Prvních několik souvisí s autentizací, sezeními,
-
# stránkami (ve smyslu více instancí jednoho projektu), zprávami (předávání zpráv
-
# mezi požadavky) a nakonec je zde automaticky generovaná administrace, která
-
# bude na pořadu dne pravděpodobně příští a přespříští díl. Nakonec tohoto seznamu
-
# dopisujeme vlastní aplikace ve formátu ‘název_projektu.název_aplikace’, ale já
-
# spíše volím jen ‘název_aplikace’, i když to není nejšťastnější řešení. Vše závisí na
-
# prioritách načítání jednotlivých modulů.
-
INSTALLED_APPS = (
-
‘django.contrib.auth’,
-
‘django.contrib.contenttypes’,
-
‘django.contrib.sessions’,
-
‘django.contrib.sites’,
-
‘django.contrib.messages’,
-
‘django.contrib.admin’,
-
)
Určitě jste si všimli, že Django používá mezery místo tabulátorů. Já preferuji spíše tabulátory, je s nimi jednodušší práce a ty dva vygenerované soubory si upravuji. Bohužel se Django občas vzdálí od zavedeného konceptu, že identifikátory v Pythonu se píší takto:
- foo
- foo_moo
- foo_moo_foo
V Djangu často narazíte na identifikátory psané:
- foo
- fooMoo
- fooMooFoo
To je druhá věc, na které se s vývojáři Djanga neshodneme, ale krom malého zmatku je to vcelku jedno. Já tento rozdíl téměř nevnímám. Pokud je již všechno nastavené, připravíme se na start naší aplikace.
A můžeme startovat
Začneme vytvořením databáze. Předpokládám, že máte běžící Postgresql server nebo víte, jak u sebe nějakou databázi z těch podporovaných vytvořit.
-
$ createdb myexperiences
A teď aplikaci spustíme:
-
$ python manage.py runserver
-
Validating models…
-
0 errors found
-
-
Django version 1.2.3, using settings ‘myexperiences.settings’
-
Development server is running at http://127.0.0.1:8000/
-
Quit the server with CONTROL-C.
-
[13/Sep/2010 21:57:48] "GET / HTTP/1.1" 200 2065
Vše by mělo projet bez problémů a pokud zadáte do prohlížeče adresu http://localhost:8000/, objeví se vám něco takového:
Závěr
Teď už máme připravené vše, co potřebujeme pro vývoj. Už v pátek si vytvoříme první aplikaci, kde bude datový model ke zprávám naší malé sociální sítě. K jejich správě použijeme generované administrační rozhraní.
Webový framework Django #1: motivační úvod
3. Zář
Hned prvním článkem o Djangu vás nebudu nějak trápit a uděláme si motivační úvod. Django je pythoní webový framework, který když se naučíte, pomůže vám s moha úkoly kolem vývoje webových stránek, v některých případech je ani nebudete muset dělat. Takové je Django, šetří čas i nervy a přitom nechce o moc víc než jiné frameworky.
Hned z kraje motivačního úvodu máte jistě spousty otázek a tou největší je cena hostingu. Přeci jen PHP se zahostuje za pár korun i zadarmo a je nalezlé prakticky všude, takže proč se zajímat zrovna o Python. Pokud studujete nebo jen nechcete za nějakou malou stránku dávat peníze, ale její existence je pro vás nějak důležitá, tak určitě nemůžete přehlídnout Google App Engine. To je služba, která vám dá přesně to co chcete. Django se na ní dá použít a poběží na spolehlivé Googlí platformě. Nemám momentálně tušení jaké jsou podmínky pro provoz, protože jsem si s GAE začal hrál teprve dnes, ale minimálně deset aplikací pro vlastní potřebu zdarma tam rozjet můžete. To si myslím že je pro běžného smrtelníka dost a pro PHP podobnou službu nenajdete.
Další varianta je použít nějaký levný hosting, kde vám pythoní aplikace budou trpět. Většina hosterů je zdeformovaná mod_php modulem a jejich infrastruktura nepojme Python ani náhodou. Ti lepší sáhli k FastCGI a tady už je jen krůček k podpoře jazyka Python a tím pádem i frameworku Django. Ještě se můžete setkat s mod_pythonem, ale tomu se radím vyhnout. U hostera, který běží na nějakém *CGI, nebudete muset řešit práva a máte zaručenou mnohem větší bezpečnost pro vaši aplikaci. Takový hosting nabízím i já na Roští.cz a to nově za 50 kč za každou aplikaci. Pokud bude váš projekt nějak spojen s open source světem nebo budete mít projektů více, domluvíme se i výhodnější ceně.
Největší konkurent pro Python na webu je PHP. I to má svoje frameworky a musím říct, že některé jsou opravdu dobré, ale ať už použijete sebelepší framework, pamatujte, že nevýhod PHP se nezbavíte. PHP vidím po pěti letech jeho používání jako mor, který zachvátil serverovou část webu a ne a ne najít vakcínu. PHP bylo ze začátku navrhováno téměř na koleni, vývojáři přilepili něco sem a něco támhle a najednou to bylo neudržitelné a snaha udržet zpětnou kompatibilitu za každou cenu prakticky odřízla projekt od předělání některých klíčových vlastností. Když přišlo PHP5 k životu, já se od něj odvrátil a začal zkoumat Python a později Django. To mi dalo všechno co jsem kdy potřeboval a po malých toulkách mezi CherryPy a mým PyWebem, jsem u něj už zůstal.
Django není jen framework pro základní komunikaci s uživatelem, ale obsahuje ohromné množství nástrojů, které vám usnadní vytváření webů. To znamená že s ním jednoduše odešlete e-mail i s přílohou, vytvoříte stránkování, lokalizujete svůj web do nespočtu jazyků, nemusíte se starat o administraci, jednoduše zpracujete formulář, namapujete si ajaxové funkce na ty pythonovské, budete mít přehled o tom jaké dotazy váš web k databází posílá nebo velmi efektně vyřešíte cachování. Django má všechno co by správný framework měl mít a to nejlepší je, že za ním stojí velká komunita a stále se vyvíjí. Když začnete používat Django, budete psát weby velmi čistě, rychle a hlavně levně.
A teď něco pro samouky. Django má velmi dobře zpracovanou dokumentaci, kde se dozvíte vše co potřebujete. Zdrojové kódy jsou samozřejmě otevřené, takže co nenajdete v dokumentaci, prozradí zdroják. V dokumentaci se nachází tutoriál o čtyřech dílech a toho se budou držet i první díly tohoto seriálu. Tutoriálem ale končit nebudu. Rozhodně ho zpracuji jinak než je v dokumentaci a postupně budu popisovat vše co jsem někdy použil. Určitě bude tento seriál po dokončení vhodným materiálem pro studium Djanga a to velmi do hloubky a doufám, že ho jednou odevzdám jako nějakou semestrální, či bakalářskou práci. Dalším dobrým zdrojem informací je již ukončený seriál na serveru zdrojak.cz. Tam jsem také pochytil některé triky, jenž jsem neznal.
Jestli umíte anglicky a prokoušete se tutoriálem, budete ovládat Django na dostatečné úrovni, abyste něco napsali, nicméně se nezapomeňte vrátit každý pátek na můj blog, kde se dozvíte informace o dalších věcech, které jste třeba přehlédli.
Nakonec ještě jeden detail. Během psaní seriálu budu postupně psát aplikaci, na které vše popsané předvedu. Mělo by jít o něco jednoduchého, na čem půjde předvést kdejaká kravina. Blog již mám napsaný a rozvíjet ho dál nechci, ale třeba mi s vymýšlením co by to mělo být pomůžete v diskusi. Osobně bych se rád naklonil k nějaké jednoduché sociální síti ala Google Buzz. Tam je potenciál využít novou podporu pro více databází i některé kravinky, které se v Djangu dají najít.
Další zdroje:
LinuxAlt 2010: mám pro vás sto minut Djanga
1. Zář
Nejlepší a nejdůležitější linuxová konference tohoto roku, LinuxAlt 2010, o půl noci uzavřela „call for papers“ a to znamená, že už je pomalu za dveřmi. Já jsem se tento rok opět rozhodl zúčastnit a tentokrát jsem si vybral jako téma webový framework Django. Samozřejmě se ještě musím zalíbit návštěvníkům linuxalt.cz, kteří budou o přednáškách hlasovat, ale to bude ještě chvíli trvat a určitě na to upozorním na Twitteru. Zatím tady trochu rozeberu o čem hypotetická přednáška bude.
Minulý rok jsem přednášel o OpenWRT a byl to asi můj první výstup, při kterém se mi neklepal hlas. Celkově přednáška dopadla dobře, ale hodně jsem bojoval s časem. Vůbec jsem netušil, že toho můžu o OpenWRT tolik říct a tolik ukázat. Samozřejmě se ukázal i generálský efekt a něco přestalo fungovat. Všechno nakonec dopadlo dobře a dalšímu přednášejícímu jsem ukousnul asi jen pět minut.
Tentokrát jsem se rozhodl jít na to „zvostra“ a využít toho, že organizátoři nabízejí možnost výstupu na 2×50 minut. O Djangu můžu mluvit ještě déle než o OpenWRT, takže je dobrá šance, že dám dohromady něco, z čeho budou moci začínající djangisti vycházet. Rád bych přednášku pojal tak, aby člověk který poslouchal, mohl z přednášky odejít a rovnou začít pracovat na svém webu.
Úvodní část přednášky plánuji věnovat rozdělení projektu na menší aplikace a seznámení s dokumentací. To jsou věci, nad kterými jsem jako začátečník mávl rukou, ale postupem času jsem zjistil, že občasné čtení dokumentace nad nejistým kusem kódu velmi pomůže, stejně jako správné rozdělení celé aplikace na menší bloky, které lze později použít jinde.
Druhá část přednášky se bude věnovat čtyřem základním oblastem v Djangu a to:
- Databáze
- Šablony
- Formuláře
- URL dispatcher
Když umíte pracovat s tímhle, web už napíšete. Během této části bych také rád ukázal, jak se dá napsat velmi rychle jednoduchá wiki. To je taková vděčná ukázka, protože se zde využijí všechny čtyři oblasti a zároveň se nemusí řešit takové věci jako je registrace a přihlášení. Také se dá ukázat i interní administrace.
Třetí část bude věnována doplňkovým a užitečným funkcím. Jejich přehled, který jsem uvedl v abstraktu je zde:
- Emaily
- Lokalizace
- Cache
- Práce s více databázemi
- Ajax
- Paginator
Jelikož jsem to psal v rychlosti, asi půl hodiny před skončením termínu, tak dodatečně sem ještě doplním:
- Uživatelé
- Interní administrace
Přednášku jsem rozdělil tak, abych v případě nedostatku času, mohl méně důležité části na konci vynechat, ale jejich seřazení si ponechám až na dobu, kdy budu pracovat na materiálech.
Nakonec ještě informace o novém seriálu na mém blogu, který bude vycházet každý pátek a bude představovat po kouskách Django. Po GITu a víkendových povídkách, to bude třetí seriál, což mi trochu ulehčí život.
