Drupalcon Szeged, negyedik nap

Kicsit nehéz volt felkelni, ebből következően alaposan ki kellett lépni, hogy ideérjünk időben - de ezzel még az egyik előadó is így volt.

Jose Reyero, Jeff Miccolis: Messaging and Notifications frameworks (link)

Az igények: emailek, feliratkozás, sms, válasz - egyszerűen a rendszerrel való kapcsolatteremtés a weben túl. A célok: feliratkozások kezelése, üzenetek kiküldése, válasz - mindez egy keretrendszerként. Többféleképpen lehet ezt megvalósítani: egyetlen nagy modullal; különválasztva az értesítést az üzenetküldéstől; végül amit használnak: pluginekkel bővíthetően ugyanez: eseménytípusok (tartalom, felhasználó, ...), felhasználói felület és feliratkozási típusok csatlakoznak az értesítéshez; tokenek, küldési módok és üzenetrészek kapcsolódnak az üzenetküldéshez.
Üzenetküldés: szóval emaileket akarsz kiküldeni? Miért nem üzeneteket? Hogyan szeretnéd kiküldeni: emailben, postán, sms-ben, azonnali üzenetként, twitterre, ... - minden alkalommal, óránként, hetente, havonta? Van lehetőség több csatornára (email, sms, azonnali üzenet, ...), többféle formátumra (egyszerű szöveg, HTML), push és pull módszerekre; az átjárók bővíthetőek, stb. Az ügymenet akövetkező: a pluginek triggerelik az eseményeket; ellenőrizzük a feliratkozásokat, és sorbaállítjuk az értesítéseket; a sort feldolgozzuk (digest, duplumok kiszűrése); összeállítjuk az üzenetet; majd végül elküldjük. Az első két lépés az oldal betöltésekor esedékes, a többi három cronból.
Ha a M&N modulok rengeteg beállítási lehetősége elriasztana, mint modul fejlesztőt, ott van a notification_lite: szintén bővíthető, de jóval egyszerűbb használni, lévén nincs annyi opciója. Az előadás végén még egy rövidke demót is láthattunk.

A szünetben Bálint összehozott Eric Gundersennel a DevelopmentSeedtől, így kiderült, hogy a projektmenedzsment-kérdéseimre a válasz a casetracker - épp "csak" azt kell majd kivárni, míg elkészül a d6 port... ;S

Konstantin Käfer: Developing flexible and modular JavaScript components (link)

A JS függvények igazából első osztályú entitások: tárolhatók változókban, de akár függvényeket is adhatnak vissza; bárhol létrehozhatók; lehetnek névtelenek; stb. A JS-ben viszont nincsenek osztályok, de helyettesíthetők függvény-prototípusokkal. Ugyanakkor minden objektum bármikor bővíthető/módosítható - még azon függvények is, amelyek más függvények (osztályok? ;) ) ősei. Például a Number objektum prototípusa bővíthető egy convertToFahrenheit függvénnyel, így a (34).convertToFahrenheit(); simán visszaadja a 34 Celsius-fok Fahrenheit megfelelőjét. Innentől viszont kicsit kezdtem elveszteni a fonalat: gyakorlatilag elmerült a JS, mint OOP mélységeiben anélkül, hogy osztályokat használhatna - ellenben bemutatta az öröklődést, a felülírást, stb.
A második részben a Drupal JS dolgairól szólt: drupal_add_js(), drupal_json(), vagy éppen Drupal.t('How are you, %object?', { '%object' : object.name }); - egyszerű, nem? ;) Aztán elmagyarázta a Drupal ahah.js hasznát, stb. A JS hibák kiszűrésére pedig a JavaScriptLint nevű cuccot javasolta.

Barry Jaspan: Developer Experience: Because Coders Are People Too! (link)

Nem is annyira előadás, inkább beszélgetés. Az "előadó" a 2,5 éve kezdett Drupal előtt hozzá se ért PHP kódhoz. A fejlesztő is felhasználó: a DX (developer's experience) az a UX (user experience), amikor a fejlesztő használja a terméket. Az a probléma a Drupallal, hogy teljesen más, mint minden hasonló: egy cég nem vehet fel "webfejlesztőt", neki "Drupal fejlesztő" kell. Van néhány további "hiba" Drupalban. A variable_get() függvény nem ad hibát, ha elírás van a változó nevében, és minden alkalommal meg kell neki adni az alapértelmezést - minek? Használjunk például PHP konstansokat, így már fordítási időben kiderül az elírás. Vagy: miért a form_submit()-ban csinálunk meg mindent - miért nem API-ban? Ennél még az is jobb megoldás lenne, ha a form_submit() egyszerűen meghívná az API függvényt a $form_state-tel.

Darren Mothersele: Drupal as an Enterprise Web Framework (link)

2003-ban lőtte fel az első Drupal-alapú oldalát, de csak ez az első Drupalconja.
Eldöntentő: nulláról építünk? használunk valami keretrendszert? meglevőt bővítünk? Lehet-e az MVC (model-view-container) megközelítést alkalmazni Drupalnál? Az adatmodell-réteg kiváló Drupalban, az interoperabilitás szintén.
Az egész előadásra jellemző, hogy random mintákat mutat random dolgokból: ezt így csináltuk - de nem igazán jön át, hogy miért, milyen egyéb lehetőségek lettek volna, stb.

Kristof Van Tomme, Dries Buytaert, Gábor Hojtsy: Closing remarks (link)

Legelsőként Kristof előadta tekerőlanton a Drupal-songot, aztán (egy már lelépett) fickó kapott egy iPodot. Bemutatták a szponzorokat, majd az önkénteseket. A zárszóra a videók negyede, az előadások legnagyobb része elérhető volt, és azt ígérték, hogy a holnapi code sprint végére minden fenn lesz. Közzétették a bevételek és kiadások felosztását, legalábbis a dolgok jelenlegi felállása szerint.
Később Kristof és Goba körbejártak a mikrofonjaikkal, és bárkinek volt megosztanivalója, elmondhatta. A magyar Drupal közösség nevében PP lepte meg a szervezőket két karton túrórudival. Kb. félórával később a war roomból lejött egy srác és közölte, hogy már a videók több, mint fele fent van (kifelé tudnák tolni 100Mbittel, de archive.org csak 1Mbittel fogadja). Végül Dries is kapott egy mikrofont: végre egy Drupalcon, ami nem szívja ki belőle az energiát.

A zárszó után visszamentünk a szállásra, pihentünk egyet, majd az igen finom "pásztorálom" nevű egytálétel és a mellé dukál sör után alvás.