Drupal csapda?

Aspi képe

Tudom volt már ilyen téma Drupal csalódás - Drupal csapda, de az egy nagy értelmetlen vitatkozásba torkollott. Ezért úgy gondoltam a Drupal rendszer alkalmasságáról és jövőjéről igenis kellene egy komoly topic. Egy iránytű azon fejlesztők számára, akik most készülnek Drupallal foglalkozni.

A topikot lezártam, mert nincs benne kérdés. - pp -

Az ehhez hasonló írásokat kérlek saját blogodba írd, majd jelezd nekünk létezését és bekerül a Drupal.hu planetbe (ergo ki a címlapra) - alippai -

nevergone képe

Ezek a viták nagyrészt azért fordultak értelmetlen vitatkozásba, mert a kérdező nem ismerte a webes technológiákat (legfőképpen a Drupalt), nem olvasta el a fellelhető szakirodalmak legalább első pár fejezetét, és nem is akart ezek megszerzésével bíbelődni, neki "azonnal, most és ingyen" megoldás kellett. A többiek pedig esetleg félreértették őt, ezért nem helyesen reagáltak.
Viszont én ehhez a témához többet nem is szólok hozzá, sőt megfontolandó, hogy mennyire va rá szükség.

0
0
Aspi képe

"A teknős kidugja a fejét, körülnéz és aztán indul el."

0
0
Aspi képe

A projektmendszerekkel együtt kell dolgozni! A projektmenedzser az, aki a piacot képviseli, a progarmozó meg az, aki technikailag megvalósítja az elképzeléseket. Ha a kettő nem tud együtt dolgozni, az mindkét fél együttes hibája. S én azt tapszataltam, ez minden kezdetben surlódásokkal jár. Ezek fontos problémák! Ezek megoldása szükséges, ahhoz hogy pénzt nyerjünk a ki a webbányából.

Nem tudom ki hogy van vele, de nekem számít a pénz, mindeféle dolgokat veszek belőle a boltban, például olyanokat, amiket magam nem tudok megcsinálni;) Nem születtem szupergazdagnak, ezért nekem ebből kell megélnem! Felteszem, vagyunk még egy páran így ezzel:)

Ezúton kérek minden kedves hozzászólót, hogy arroganciáját hagyja otthon és operatívan szóljon hozzá a témához.

Köszönöm!

0
0
Aspi képe

Jó pár év programozgatás után, úgy gondoltam kipróbálom a Drupal keretrendszert.
Fontos tisztázni a Drupal nem egy programozási nyelv, sokkal inkább egy alkalmazásokat egybegyűjtő rendszer, melyhez széleskörű PHP, Javascript, SQL (pl.MySQL), CSS, HTML (DHTML stb.), némi Ajax és JQuery ismeret szükséges.
Kezdők számára kaotikusnak tűnik, de azért el lehet benne találni;)

Nekiálltam tehát egy site megépítésének. Beléptetéssel, szavazással, kereséssel, kissebb egyedi igényekkel fűszerezve. Elég kaotikusnak tűnt az egész, mi hol van, de ezt pár óra keresgélés után, ki lehetett bogózni. Az igazi nagy problémát az elején, az egyedi smink elkészítése jelentette. Mégis elkészült 12 óra és 28 perc alatt, az első értékelhető példány és már fent is volt adatbázisostul a neten. Tudom mit mondanátok: 'olyan is'. Hát nem! Kompromisszumok nélkül, olyan módon ahogy megrendelő kérte. Igaz később jött egy kívánság, hogy a fejlécbe tegyek egy kis Flasht, lehetőleg úgy hogy ne befolyásolja a botokat. Azért ez még pár órát rátett néhány nappal később szombat délelött, amíg mindenki aludt nálunk;)
Na, ez komolyan elgondolkodtatott. Egy senior fejlesztőnek ez a feladat 3-4 hétig tartott volna 0-ról. Egy juniournak, meg 3 hónap;) Látványos eredmény és mindent tud, amit akartunk. Nem semmi! Le is döbbentem:o
Elkezdtem hát mégjobban tanulmányozni programozói szemmel és azt a következtetést vontam le, hogy tényleg sok mindenre jó. Vannak hibái, de folyamatosan fejlődik és javul! Ami nincs benne vagy nem tetszik azt szépen lekódolja az ember és kész. Így van kitalálva az egész rendszer. Össze lehet rakni, mint egy legót és ha nincs olyan darab ami kellene, átalakíthatom vagy készíthetek egy újat hozzá. Ez ám a programozói kánaán!:)
Általánosságban azt mondhatom, hogy a következő fejlesztési metodika jött be nekem:
Fel kell állítani a specifikációt, méghozzá legalább két rétegben:
- Az első a megrendelő kívánságai, minél széleskörűbben, ami igazodik az 'atyaúristen, mindenható' végfelhasználó igényeihez, a publikumhoz. (Végülis ezért van az egész, nem?)
Ha a megrendelő nem igazodik a végfelhasználó nevü főnökéhez, akkor halálra van ítélve a piacon.
- A második a programozható megvalósítási terv és a részfaladatok elkülönítése. Ebből lehet becsülni a fejlesztési időt, és a szükséges erőforrásokat. A vasat és a programozókat, esetleges licencek díjat, stb. Egy kellően tapasztalt projectmenedzser, de egy programozó is (én pl. mindkettő vagyok/voltam egyszerre) tudja, hogy időbeli hibatűréssel kell számolni, mert menet közben kiderülhetnek olyan dolgok, amiket meg kell oldani. Mindig! Ha elég jó a specifikáció, akkor ez kb. 20%-30%, tehát 1 hónapos tervezett fejlesztési idő mellett ez kb. 1 -1,5 hét plusz idő.
Ha komoly változások vannak ez akár 70%-ra is felmehet, ezzel számolnia kell a projectmenedzsernek. Ezenkívül vannak nagyon kemény dió vállalkozások is. Itt még 100%-200%-os időtúllépés sem ritka. A szaknyelv ezeket már waporware-eknek nevezi. Mert előfordulhat, hogy az elhúzódó fejlesztési idő túllépi a várható elévülési időt, és akkor már értelmetlen tovább folytatni. Az igazán jó ötletnél ez nem fordulhat elő. Ez például az ötlet próbája is egyben;)
Tapasztalataim azt mutatják egy project akkor lesz igazán átütő jellegű, ha a projectmenedzser képes lenne egyébként maga is kifejleszteni a kívánt alkalmazást(okat).
Ez az üzleti felállás. A specifikációs szint.
Ha ez megvan a technikai megvalósítás jöhet:
-Első lépés: körül kell nézni laposan mit tud a Drupal hozzáteni a projecthez. Át kell nézni az összes idevágó modult. Mit tud, mi kell hozzá, stb.
-Második lépés: össze kell állítani a rendelkezésre álló alaprendszerből és modulokból a vázat vagy hívhatjuk keretnek is. Ezért hívják a Drupalt keretrendszernek, nem pedig fejlesztő rendszernek, milyen érdekes:) Ezt nagyon alaposan dokumentálni kell!!!
-Harmadik lépés: átalakítani vagy megírni a speciális igényeket kielégítő részeket. Ezt is dokumentálni kell, sőt érdemes még a kódba alapos kommenteket is tenni. Célszerű már az elején úgy nekiállni, hogy áttanulmányozzuk a Drupal fejlesztési konvencióit, hogy később, akár a rendszerbe is lehessen illeszteni. Ez nem csak közösség érdekeit szolgálja, hanem a magunkét is, mert idővel, ha már megtanultuk/megszoktuk a szintaktikát és a szokásokat, akkor mi magunk is jobban eltalálunk benne, akár évek múlva is. Sőt ha jön még kolléga, ő is hozzá tud fogni a munkához.
-Negyedik lépés: a kialakult egyedi rendszer tesztelése. A tesztelést a részfeladatoknál is célszerű elvégezni. Minél kissebb a részfeladat annál könnyebb! Ha a részfeladatok folymatosan tesztelve vannak, akkor a fejlesztési kockázat a 0-hoz konvergál!

Összeségében azt mondhatom, hogy eddig nem jött olyan igény, amit ne tudtam volna megvalósítani a Drupal keretrendszer segítségével. Hangsúlyozom azonban, hogy ez egy keretrendszer és nem maga a fejlesztő eszköz!

Egy tapasztalt sokat megélt programozó, már eleve elrakja korábbi munkáit, moduljait. Ha esetleg később kellene, felhasználja, esetleg kicsit átalakítja (passzintja). Egy idő múlva ez egy saját keretrendszerré fejlődik. A drupal is egy ilyen keretrendszer, csak itt több senior programozó dobja össze munkáját és együttes szellemi erővel állítja fel a keretrendszert. Ehhez csak egyetlen dolog kell: egy szabályrendszer felállítása, amit be is kell tartani, hogy összehangoltan tudjon működni a project. (Drupal is egy project.)
Nem kell hozzá agysebésznek lenni, hogy rájöjjünk ennek óriási hatástöbbszöröző ereje van! Egy programozó akármilyen ügyes is, nem ér fel más 1000 ugyanilyen ügyes (ha nem ügyesebb) programozóval. Ehhez nem kell mást tennie, mint elfogadni a Drupal rendszer fejlesztési konvencióit és nem sajnálni a munkáját másoktól;)
Ezzel minden résztvevő fejlesztő nyer, nemcsak az én szellemi termékemet használják mások, hanem én is a másokét! Megéri, mert az egyes programozó ezred vagy inkább milliomod részt tesz csak hozzá az egész nagy műhöz és mégis élvezheti előnyeit "ingyen". Azért nem teljesen ingyen, mert a keretrendszer elsajátításohoz energiát és időt kell befekteni.

Na ez lenne a nagy DRUPAL CSAPDA?

0
0