ugrás a tartalomhoz

Practical Django Projects

Török Gábor · 2008. Okt. 1. (Sze), 10.45

Szerző:

James Bennett

Kiadó:

Apress

2008

ISBN:

978-1590599969

Oldalak száma:

256

Értékelés:

10

Linkek

James Bennett neve a Djangót kedvelők számára ismerősen csenghet. Naplójában – b-list.org – rendre kiváló értekezéseket nyújt a legkülönfélébb technológiai témákban, de hogy messzire ne menjünk (és a könyvajánló tartalmi elvárásainak eleget tegyünk), az úriember nevéhez köthető a Practical Django Projects is. A könyvről előljáróban csak annyit: zseniális.

Az Ubuntu Konferencia végén kaptam kölcsön Farkas Szilvesztertől a szóban forgó könyvet, és meg kell vallanom, előítélettel fogadtam. Egyfelől a Django vesszőparipám (noha csak kínosan keveset tudok vele foglalkozni), másik oldalról a könyv kiadója az Apress, aki pedig már tartott a kezében tőlük jegyzetet, az tudja, hogy az egyet jelent a tipográfiai minőséggel.

A Practical Django Projects puha fedeles, vékony (mintegy kétszáz oldalas) kivitele inkább egy tankönyv érzetét kelti az emberben, szemben a keménybe kötött Practical Common Lisp bibliámmal. Tankönyv már csak abban az aspektusában is, hogy James az iromány folyamán végigvezeti az olvasót a Django telepítési instrukcióitól egy közösségi kódmegosztó site kivitelezéséig. Tankönyv továbbá abban a tekintetben, hogy nem csupán kódszeleteket mutat fel, hanem három, az első sortól az utolsóig működő, kipróbálható, tanulmányozható alkalmazást (CMS, weblog, kódmegosztó) épít fel a könyv során.

A kiadvány címe lehetne akár Django gyakorlati minták is. Nem néhány, egymástól elszigetelt alkalmazás fejlesztését mutatja be a szerző, hanem építve a Django újrafelhasználható komponenseire, tálalási javaslatokat nyújt egyszerű problémák gyári csomagok segítségével történő kivitelezésére, majd az egyes fejezetek végén elmélyül az egyedi továbbfejlesztés lehetőségeiben.

A Practical Django Projects nem követeli meg a Python nyelv ismeretét. James rendre széljegyzetekkel szolgál, ha olyan nyelvi elemre támaszkodik, amely kifejezetten pythonos, vagy amit érdemes lehet megjegyezni. Valójában még a Django keretrendszer ismerete sem kritérium, mint említettem a keretrendszer telepítésével indít a könyv, majd az egyes alkalmazások fejlesztése során egyre összetettebb komponenseit ismerjük meg.

Noha a könyvet még a Django hivatalos 1.0-s kiadásának megjelenése előtt zárták le, a példaprogramok forráskódjához a szerző az akkori fejlesztői változat kódjára támaszkodott, így elenyésző módosítással futtathatók az alkalmazások a stabil verzión.

A könyv zárófejezetében az olvasottakat összegezendő, James – ahogy egész írásában – hangsúlyozza az újrafelhasználható komponensek fontosságát, és instrukciókat ad arra, miképpen lehet könnyen telepíthető programcsomagokat létrehozni a Django alapú fejlesztéseinkből.

Hogy vajon az Apress, a Python, a Django vagy egyéb miatt, mindenesetre zseniális.
 
1

DjangoCon 2008: Reusable Apps

Török Gábor · 2008. Okt. 5. (V), 19.41
James a DjangoConon is tartott előadást újrafelhasználható komponensek témában.
2

Lehet

tolmi · 2008. Okt. 6. (H), 09.22
Lehet el kellene olvasnom, mert nekem egyáltalán nem jött be a nagy Django őrület. Én inkább TurboGears.

Talán pont ezért nem jött be igazán a Rails sem. Nem tud valaki egy hasonló non-intrusive Ruby webes keretrendszert (mint a TG)? :D
3

Három framework, három filozófia

Török Gábor · 2008. Okt. 6. (H), 09.36
A TurboGears, Rails és Django, mindhárman elég más filozófiát követnek. A Django és a TG is természetszerűen sokat kölcsönöztek a Railstől, de amíg pl. a Rails egy nagy (pluginekkel bővített) alkalmazásban gondolkodik, addig a Django az újrafelhasználó komponensekben hisz, és egy egyszerű webalkalmazáshoz is alkalmazások fejlesztésének vagy használatának tucatját javasolja. TurboGears a Djangótól annyiban tér el, hogy már meglévő komponensekből építkezik, sokkal lazábbak azok kapcsolatai, így bármelyik eleme könnyen leváltható egy másikra. A Djangót from the scratch írták, és a rendszerelemei viszonylag szorosan kapcsolódnak, lehetőség van itt is komponensek cseréjére, de nem ez az irány, amit a keretrendszer képvisel.
4

Tudom hogy a TG, a Django és

tolmi · 2008. Okt. 6. (H), 11.03
Tudom hogy a TG, a Django és a Rails triplet között vannak gyökeresen eltérő (és nagyon hasonló) elemek, azonban ettől még összehasonlíthatóak, hogy melyik alkalmasabb (persze szubjektíven) erre vagy arra. Nekem a TG jobban bejött pont amiatt amit írtál. A Rails pedig nagyon találóan kapta a nevét, valóban olyan mintha sinen futna a dolog, nem lehet semmit nagy kínszenvedések nélkül megcsinálni, ami nem a sín mentén vezet. Ezzel persze időt nyer az aki futószalagon gyárt alkalmazást, de én nem látok sok kihívást a futószalag alkalmazásokban. Nem is foglalkozom velük (scriptet írok rájuk - az izgalmasabb :D).

Jól jött le nekem, hogy ez a könyv akkor nem fog túl nagy meglepetésekkel szolgálni?

Ettől még Ruby alá keresem a megfelelő munkát segítő webes keretrendszert ;)
5

Djangós tálalási javaslatok

Török Gábor · 2008. Okt. 6. (H), 12.55
A könyv tárgya, hogyan célszerű és hasznos Django-alapú webappokat fejleszteni. Bemutatja, hol érdemes (Django terminusban vett) alkalmazások határait meghúzni, és jó néhány praktikával szolgál az egyes fejlesztések során. Ezek akkor izgalmasak számodra, ha már eldöntötted, hogy Django alapon fejlesztesz. A könyvnek nem célja, hogy téged meggyőzzön, inkább iránymutató, hogy Djangóban mit hogyan érdemes.

(Ruby meetupra menj el.)
7

Ha nagyon puritan cuccot

hron84 · 2008. Nov. 17. (H), 21.49
Ha nagyon puritan cuccot akarsz hasznalni, akkor a Ruby beepitve tartalmaz ketto komplett templating rendszert (ERB, ERuby), valamint az objektumok dinamizmusa miatt szinte barmit meg tudsz oldani.

Valo igaz, hogy Rails-ben a filozofiatol gyokeresen eltero dolgot nagyon nehez megvalositani - ugyanakkor egyfelol a legtobb problema imlpementalhato a filozofiajaba, masfelol pedig ez minden keretrendszerrel igy van. Biztos van olyan TG-ben is, amit nagy szivasok aran lehet megvalositani, szoval egyik rendszer sem jobb a masiknal. A kerdes inkabb az, hogy kepes vagy-e az adott problemat az adott keretrendszerben implementalni vagy sem. Ha nem, akkor masik eszkozt kell keresni - ugyanis mindig, kivetel nelkul a cel valaszt eszkozt es nem viszont.
8

Ha nagyon puritan cuccot

tolmi · 2008. Nov. 18. (K), 14.56
Ha nagyon puritan cuccot akarsz hasznalni, akkor a Ruby beepitve tartalmaz ketto komplett templating rendszert (ERB, ERuby), valamint az objektumok dinamizmusa miatt szinte barmit meg tudsz oldani.

Nem puritánságra vágyom (legyen elég utalás az hogy Drupal-lal és ZF-el dolgozom :)), inkább a flexibilitásra. Nekem az az eszköz a barátom, amelyik segít a mainstream problémák kezelésében, de szabad kezet ad, amikor a problémám nem mainstream.

Ez pl. PHP-ban a Zend Framework esetében egészen szépen kikristályosodik. Nem kell pl. lecserélnem az egész Views kezelőt, mert szeretném a funkcionalitását kiegészíteni, vagy éppen a meglevő elemeket másként felhasználni.

ugyanakkor egyfelol a legtobb problema imlpementalhato a filozofiajaba, masfelol pedig ez minden keretrendszerrel igy van.

Ezzekkel a kijelentésekkel vigyázz! :) Azzal maximálisan egyetértek, hogyha egy adott problémára van mainstream megoldás (pl. ismert design pattern), akkor azt illik és kell is használni (felelősség a fejlesztői társadalommal szemben - volt már erről egy agymenésem proclubbal itt a weblaboron).

Azonban ha kínkeserves szenvedés egy problémát ráhúzni egy Sínre, akkor azt nem szabad, sőt tilos. Ne vezessük meg a másikat hogy egy problémát egy másiknak álcázunk. Ráadásul hosszútávon megvezetjük vele magunkat is.

Biztos van olyan TG-ben is, amit nagy szivasok aran lehet megvalositani

Biztos van, csakhát akkor azt nehéz megvalósítani natív Pythonban is. Bevallom nem volt még fullos projektem TG-ben. De pont arra szerettem volna kilyukadni, hogy csak azt kell módosítanom amire tényleg szükségem van, nem kell pl. egy fullos DB layer-t írnom, csakhogy transzparens BLOB dekódolást csináljon a Model layer. Elég ha override-olom a megfelelő oszály megfelelő metódusát.

Ha nem, akkor masik eszkozt kell keresni - ugyanis mindig, kivetel nelkul a cel valaszt eszkozt es nem viszont.

Ezzel is egyetértek, azonban én nem szeretek egyedül végigcsinálni egy projektet, szeretek másokkal együtt dolgozni. Gondolom azt megérted hogy nem mindenki ismer annyi mindent mint én vagy te (önfényezés++ :)). Tehát egy olyan eszközt kell választanom/választanunk, amellyel hosszútávon sokféle projektre tudunk megoldást adni még akkor is ha nem az a legjobb eszköz minden problémára.
6

merb

js · 2008. Okt. 7. (K), 23.17
Szerintem a fölösleg jelentős részét a merb-ből remekül kihagyták, bár egy oldalért még mindig nem fogod felrakni az egész hóbelevancot. Mindenesetre remekül lehet teljes merb szoftverből szeletet csinálni, hogy más szoftverbe berakhasd, és én itt látom a kód újrafelhasználásának legjobb módját.
9

Second edition

Török Gábor · 2010. Ápr. 9. (P), 12.13
Nemrég jelent meg a Practical Django Projects második kiadása. Azontúl, hogy a példakódok immáron a Django 1.1 API-jára és képességeire támaszkodnak, új fejezettel is bővült a könyv. A Practical Development Techniquesben szó esik a verziókövető rendszerek használatáról, a projekt környezet javasolt kialakításáról (virtualenv), és ízelítőt kapunk build (pip) és deploy (fabric) eszközök használatából is.