Programtervezés tanulása

Algoritmusok

Sziasztok,

Hosszú idő óta szeretnék egy webes tartalomkezelőrendszert összeállítani, melynek az alapvető irányelve, hogy minnél általánosabb legyen, moduláris felépítéssel. Sajnos bizonyos tervezési kérdésekre nagyon nehezen találom a választ (most például a modulszervezésnél akadtam el) és úgy érzem, hogy gyakran nem a legoptimálisabb utat választom, ami egyszerűen visszavezethető tanulatlanságomra. Szeretném tanácsotokat kérni, hogy milyen könyvekkel/jegyzetekkel bővíthetem a tudásomat. Leginkább általános programszervezési ismeretekre lenne szükségem, nem algoritmusokra.
Vetettem egy rövid pillantást az UML-re, gondolom érdemes a használatát elsajátítani, de megoldást kínál önmagában a problémára? Amennyire láttam, csak a dolog ábrázolás részét oldja meg. (Nem gondolkozik helyettem, oh.)

Köszönöm a segítséget, sajnálom hogy homályosan fogalmaztam, nehezen tudom megfogalmazni, hogy valójában mi is hiányzik nekem.

  • 7438 megtekintés

( Oops | 2009. 03. 19., cs – 22:09 )

az UML-t illetőleg igazad van: csak arra jó, hogy jól megfogalmazd az ötleteidet

( BikMak | 2009. 03. 19., cs – 23:22 )

Valószínűleg a 'tudatlanságod' az oka annak, hogy meg akarod valósítani. Ilyenekből Dunát lehet rekeszteni. Persze programtervezést tanulni jó, nem akarlak eltántorítani, de ha élesnek akarsz ilyet használni, valószínűleg jobban jársz azzal, ha egy olyan rendszert használsz amit sok tapasztalt ember fejlesztett, és még több tesztelt, így valószínűleg jobb lesz mint amit egyedül otthon össze tudsz rakni.

Ha php-t használsz rá, akkor volt egy php5 haladóknak könyv (fekete), amit még régebben olvastam, abban elég sok használható oo tervezési minta volt speciálisan webes cuccokhoz.

Nem értek veled teljes mértékben egyet. Egyrészt a "több tapasztalt ember" is lehet hülye, és írhat olyan kódot, amibe nem szívesen nyúl bele a jóízlésű ember. Másrészt a több ember által tesztelt rendszerben az ismert hibák száma is jelentősen több. Lehet hogy nem alkotsz biztonság szempontjából jobbat, de az előny, hogy mégse ismeri kismillió ember a kódot a kezedben van. Harmadrészt mi a cégnél saját keretrendszert használunk, mégpedig azért, mert úgy és azt csinálja ahogy akarjuk, vagy ha nem mivel álmomban is el tudom mondani, hogy mi hol és hogyan történik pillanatok alatt igényre tudom szabni. Valószínű ha hasonló feladatot kapnék, mint a kérdésben szerepel, és nem csak egy egyalkalmas "kiteszek egy blogot" szintű feladatról lenne szó, én is megírnám az egészet (felhasználva a keretrendszert, amiben pillanatok alatt tudok modult fejleszteni, hisz arra van).

( xbit | 2009. 03. 19., cs – 23:29 )

Vannak konyvek a temaban, "programtervezesi mintak" pl ha jol emlekszek, de igazabol ez az egesz a kreativitason, logikussagon mulik, ha egy adott problemad van. Egyik konyv sem fog neked algoritmust adni, hogy hogyan konstrualj meg egy modulhierarchiat. otletek, paradigmak vannak, amiket vagy kovetsz, vagy elvetsz, amik menten gondolkozol vagy sem... Ezeket persze fontos megismerni...
ugyhogy bele kell vagni valahogy, nem biztos hogy a legjobb lesz egybol. az fontos, hogy lasd az utat, tudd _mit_ akarsz megvalositani, es kb fel tudd becsulni, mit kellhet meg kesobb belepakolni. Nem mindig a _hogyan_ a fo szempont...
Egyszoval sok tapasztalatot kell szerezni.

zsolt

Ha erre gondolsz, megvan, beleolvastam, de még nem sajátítottam el teljesen. A könyv sajnos jóval túlmutat a webes rendszerek szükségletein.

Tulajdonképpen ahogy haladni tudok, az a szükségletek folyamatos legyűrése, és puskázás az okosok kódjaiból. (pl.: Drupal)
Fontos a tapasztalat, de szerettem volna a 'korai' szakaszt kikerülni, és nem belefutni a "megtervezem, implementálom, jajj-nemjó, goto 0"-ba. Ezekszerint a megfelelő logika, gyakorlat és tapasztalat megszerzéséhez szenvedni kell?

A szenvedést képletesen értettem, nem kínzom magamaz ha gondolkozok ,)
A php tökéletesen kiváltható (pl.: pythonnal) de egyelőre ehez értek legjobban. A célom viszont olyan specifikáció elkészítése, aminek implementálása nem okoz problémát hasonló nyelvekben. Ezalatt azt értem, hogy a specifikáció maga nyelvfüggetlen.

Ez a konyv nem mutat tul a webes rendszereken. Egy tervezesi minta pont azert jo, mert altalanosan hasznalhato. Lehet, hogy a nevek felrevezetnek, de a mintak igenis hasznalhatoak altalaban webes kornywzetben is, hiszen az is csak egy szoftver, ami HTTP protokollal mukodik. Persze pont emiatt Observer mintat soha nem fogsz tudni esszeruen implementalni, de ehhez hozza kell szokni, ugyanugy, ahogyan rendes MVC sincs HTTP felett (pont az Observer hianya miatt).

Tegyuk fel, hogy van egy entitasom, amelyet ket kliens megtekint, egy harmadik meg szerkeszt. A szerkesztes pillanataban HTTP protokoll segitsegevel hogyan oldod meg, hogy a megtekintos kliensek view-ja updatelje sajat magat a modositott adatokkal? A bizonyos idokozonkenti pollozas/ujratoltes gagyi megoldas, az open-ended HTTP kapcsolat nem megoldas.

Vagy nezzuk a kovetkezo szituaciot: van egy hosszan futo folyamatom, ennek allapotvaltozasait akarom kovetni. Hogyan fogja megtudni a kliens azonnal, hogy valtozott az entitasom allapota? Mikent tudja HTTP segitsegevel a szerver ezt kozolni, anelkul, hogy pollozna a kliens?

Ezek a megoldasok csak epitenek felig-meddig egy reteget a HTTP fole, emulalnak bizonyosfajta mukodeseket. Be kene mar ismerni, hogy a HTTP-t nem erre talaltak ki, es helyette csinalni egy uj protokollt. A HTTP mar lassan 20 eves lesz, lejart felette az ido. Mar masra hasznaljak az emberek a webet, mint 20 evvel ezelott. Miert kotjuk magunkat foggal-korommel egy technologiahoz? Kardokkal sem filezunk hust. Masra valo, megis vago-szuro eszkoz.

Nálam nem biztos örülne az ügyfél ha frissülgetne a listája. De van ilyen lehetőség, persze dolgozni kell vele, nem automatikus (ahogy én tudom, bár mintha paradoxban lett volna ilyen) Change notification Oracle/.NET alatt
Szerintem az, hogy ezt egy böngészőben működő vagy desktop alkalmazás használja mindegy, a megoldások hasonlók.

Az Oracle.NET-nel erosen nem mindegy, hogy desktop vagy webes az alkalmazas, meghozza azert nem, mert nem mindegy, ki hajtja vegre a .NET kodot. A bongeszo ezt nem fogja megtenni, igy meg mindig nem latom, hogy hogyan kapja meg HTTP-n at a user a valtozasokat.

Masreszt nem feltetlenul igaz az, hogy az entitasom adatbazisban tarolodik, lehet memoriabeli objektum, amely csak addig el, amig par kliens csatlakozik hozza, viszont akkor a valtozasokra reagalni kell (pl. chat, online jatekok, stb).

Tegyuk fel, hogy van ket kliens, az egyik modosit, a masik errol meg nem ertesult, es modositani akar, erre jon neki a valasz, hogy bocs, ezt ebben az allapotban nem tudod megtenni, mert inkonzisztens lenne az adat, kezd elolrol. Sok ugyfel meg ennek nem orul.

Webes alkalmazásnál a .NET vagy java (ha nem applet) kód a szerveren hajtódik végre, ez természetes és jó is. Ha változásfigyelés kell akkor egy javascript megoldással olvasok a szerverről (mint az ajax-nál) vagy refresh-elem az oldalt.
Az hogy adatbázisban entitás vagy máshol tárolódik az entitás nekem mindegy, húzok egy réteget a tényleges tárolás fölé és nem foglalkozok vele.
Két kliens, egyik módosít, másik is akar: itt sql-ben select for update-el trükköznék és már az elsőnél lockolnám így a másik már a bevitelhez sem jutna mivel az adat módosítás alatt van.
Nem tudom hogy képzeled el a beviteli képernyőt, a második miközben tölti ki egyszercsak megváltozik az adat? ;)
Ha meg listát kér akkor miért frissüljön? Ha nyomtatja az már nem fog frissülni, ha pedig tudja hogy gyorsan változó adatok vannak akkor refresh-el vagy ő vagy a program automatikusan.
Chat egyszerűen megy ajax-al, keress rá google-vel.

"a második miközben tölti ki egyszercsak megváltozik az adat?"

Konkurrens hozzaferesnel ez barmikor megtortenhet. Lasd pl. egyetemen a targyfelvetel. Van meghidetve egy tantargy, 30 fos limittel. Belep user 1 es user 2, mind a ketto larja, van meg 1 hely. User 1 felveszi a targyat, majd user 2 is fel akarna venni (hiszen nala meg mindig az latszik, hogy van 1 hely), erre kapja a hibauzenetet, hogy bocs, de a kurzus betelt. Az ilyen es hasonlo esetek baromira kenyelmetlenek es rontjak az UX-et.

Igen, en is kepernyon lathato adatra gondoltam. Az mar programozastechnikai balfaszsag, ha ugyanazt az entitast szeretnel szerkeszteni egyszerre tobb klienssel, en arra gondoltam, amikor az egyik szerkeszt, vegez vele, utana a masik szerkesztene, mert a felulet ad ra lehetoseget, de o meg a regi adatokat latja, mert az adatmodell nem tudott szolni, hogy frissult. Ez UX teren nagy problema. Hasonlit ez ahhoz, amikor mondjuk VCS-ek eseteben conflict lep fel, ugyanilyen okokbol.

Egy kicsit azt érzem, hogy fából akarsz vaskarikát. Nem mondom, hogy a HTTP az űberkirály, de mivel a böngészők és webszerverek ezt használják, két lehetőséged (az ügyfélnek is) van:
1. belátod a protokoll hiányosságait és annak keretei között megoldod a felmrülő problémát,
2. keresel/implementálsz másik protokollt és hozzá kliens és szerver alkalmazást.

Lehet én vagyok a tudatlan, és akkor kérlek homályosírts fel, de mi köze van egy programozási paradigmának, vagy architektúrának nevezzük bárhogy, ahhoz, hogy a kimenet nem frissül az adatok változásával? Szerintem, bejön a kérés HTTP-n a szerverbe, a rendszer az url alapján a megfelelő Controllerbe irányítja a kérést, a Controller Modelleken végeez műveleteket, majd a View által legenerált választ visszaküldi HTTP-n a kliensnek. mindhárom szerepkör teljesen elválasztott, és View is csak a neki kiszabott feladatot látta el. Legalábbis felénk ez így megy.

Akkor masra gondoltunk. Ez inkabb szoftverarchitektura ( n-tier achitektura, n=3), en az MVC-re, mint tervezesi mintara gondoltam, amely alapvetoen ugyanaz mint az Observer, ott pedig alap dolog, hogy a modellvaltozasokat nem lekerjuk, hanem a modell szol, hogy megvaltozott az allapota. Na, ez az utobbi notifikacios dolog az, ami csak ganyolassal megy HTTP-n. Amugy meg a megvalositasok (iframek, ajax-hivasok, stb.) azok mind webes kornyezetet teteleznek fel, marmint webbongeszoben futast, azonban a HTTP-t nem csak HTML+JS tartalmak kezelesere lehet hasznalni, hanem altalaban dokumentumkezelesre is, lasd DAV es hasonlo kiegeszitesek hozza (amelyek csak plusz metodusokkal egeszitik ki a protokollt, azonban az alapjai, erossegei es hibai ugyanugy megmaradnak). Ezert a fent leirtak (Comet, stb.) nem tudnak mukodni nem webes kornyezetben rendesen. Nem webes desktop alkalmazasoknal is lehet ertelme HTTP-n keresztul kommunikalni Interneten at, ugyanis a HTTP-t altalaban kiengedik a tuzfalak (meg a prtokolltuzfalak is), ezert a felhasznaloi elmeny jobb, mintha azt mondanank, hogy bocs, de te ezt a progit nem tudod hasznalni, mert nem engedelyezett protokollt es portot hasznal.

"View által legenerált választ visszaküldi HTTP-n a kliensnek"

Amugy pont itt van a legnagyobb baj es talan felreertes az eredeti, nem webes MVC szerepeivel kapcsolatban: a View nem general valaszt, a View az maga az az entitas, ami megjeleniti az adatmodellt megfelelo modon (termeszetesen egy adatmodellt tobb View is megjelenithet, egymastol fuggetlenul, peldaul egyszerre listanezet, tablazatos nezet, stb). Egy-egy View peldany pedig updatelodik, ujrarajzolodik akkor, amikor az adatmodell jelenti neki, hogy "He, engem egy Controller arra kert, hogy modositsam magam, modosultam, frissits". Namarmost a weben a kulonfele viewk azok tkp. a kulonfele bongeszesi sessionok ( a frissito JS kodok a View felhasznalo fele valo megjelenitesenek logikajat tartalmazzak), mig az adatmodell es lehetoleg a kontroller az a szerveren letezik (bar REST eseteben a kontroller nem feltetlenul) es egy update muvelet tkp. az oldal egy reszenek vagy egeszenek a frissitese, kicserelese uj HTML fileokkal. Persze ezeket a fileokat elo lehet allitani kliens es szerveroldalon is, az adatmodell megfelelo informaciojanak a felhasznalasaval. Ugyanugy, egy jo HTTP-alapu alkalmazasnal lehet elkepzelni olyan klienst, amely a kapott modellinformaciokat Win32 widgetek segitsegevel jeleniti meg, nem pedig rabizza a bongeszore a HTML leiras alapjan a widgetek kirakasat. Csakhogy a frissitest a modellnek kell inditvanyoznia, nem pedig ganyolassal megoldani, hogy megkerdezem tole, hogy "Mi az allapotod? Ujra akarlak rajzolni, mert hatha modosultal."
A HTTP igazi, szemantikus hasznalata (dokumentumok-adatmodell informaciok lekerese, modositasa, keszitese, metaadatok lekerese) amire eredetileg is kitalaltak, az par eve REST neven kezd el terjedni a webalkalmazas-keszitok koreben.

Termeszetesen van ertelme annak, hogy weben imitaljuk az asztali alkalmazasok mukodeset, hiszen centralizalt a kodbazis, igy egyszeru frissiteni, elerheto mindenhonnan, stb. A JS (Ajax) + HTML paros vette at azt a szerepet, amit regebben a Java Appleteknek szantak, mivel elegge sok hatranyuk volt (lassu inicializalas, plugin kell, stb.) pedig minden bongeszoben konzisztens felhasznaloi elmenyt sokkal egyszerubb Java Appletek segitsegevel megoldani, mint CSS, JS hackeket, n layert hasznalo libeket hasznalni a bongeszok kulonbozosegei miatt. Legalabb a Javat felig-meddig konzisztensen implementalta minden vendor.

( gabrielakos v | 2009. 03. 21., szo – 06:30 )

design patterns könyv
--
Gabriel Akos

( atomheart v | 2009. 03. 21., szo – 10:10 )

Tudasodat ez iranyba a kovetkezo modszerekkel fejlesztheted szvsz:

1. Szakirodalom bongeszese. Sok okos ember sok erdekes es hasznos dologra jott mar ra, konyveik adnak egy elmeleti tudast, amire konnyu epitkezni. Szamodra erdekesek lehetnek:

emlitett GoF konyv, Refactoring to Patterns, Patterns of Enterprise Applications, Applying UML and Patterns, stb.

2. Letezo designok tanulmanyozasa. Nezz bele openszorsz CMS-ek, forummotrok, keretrendszerek forraskodjaba, fogsz talalni dolgokat, amelyekrol konyvekben nem olvastal. Jobb fejlesztok dokumentaljak kodjukat, kommentekben, vagy kulon dokumentumokban kifejtik a megoldasaik mogott levo erveket.

3. Fejlessz magad minel tobb ilyen rendszert, fektess nagy hangsulyt a design-ra, eloszor tervezz, utana kodolj. Munkaidat idonkent nezd at, gondold meg, hogy mit csinalnal maskepp, kerd ki kollegak/ismerosok velemenyet.

A 3. pont a legfontosabb, nem tanulhatsz meg uszni konyveket olvasva, masokat uszas kozben figyelve... ;^) Kezdokent szinte biztos, hogy sok rossz dontest fogsz hozni, ez teljesen normalis...

Szerk: felteteleztem, hogy a hasznalt nyelvet/keretrendszert, RDBMS-t ismered jol, ha nem, eloszor erre fektes nagyobb hangsulyt. Konnyebb elore tervezni, ha ismered az eszkozeid korlatait...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

1. GoF ittvan előttem, többit köszönöm, vetek rájuk egy pillantást.
2. Drupalt szoktam nézni, sajnos az nem objektum-orientált, de már a modellből elég jól tudom tippelni a választott utat.
3. Ez sem hiányzik. Igazából már rengetegszer elkezdtem, eljutottam valameddig, majd belefutottam egy -a tervből kimaradt- problémába, ami miatt tisztábbnak éreztem újrakezdeni. Ebben a projectben nem kötnek határidők, megengedhetem magamnak a tökéletesség _igényét_.

Sajnos csak nemrég hoztam meg azt a döntést, hogy az ingyenes tárhelyektől megválva, egy olyan rendszert fejlesztek, amit jelenleg host hiányában nem tudnék üzembe helyezni. Ezért az RDBMS ismereteim elég korlátozottak, de ezt könnyebben fejleszthetőnek találom.

A Drupal objektum orientált, csak a PHP OOP eszközkészlete túl szegényes hozzá, hogy egy komolyabb OOP rendszert össze lehessen dobni vele nagyobb fájdalmak nélkül. Smalltalk-ban menne, csak az nem túl elterjedt nyelv a weben :)

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

( handler | 2009. 03. 21., szo – 14:16 )

Ajanlom figyelmedbe az OOPSLA konferenciak anyagait, azok kozul is a problemamegoldas es absztrakcios kepessegek, valamint az OOP/UML nyelvek tanitasarol szolo anyagokat.
Sok gyakorlati tapasztalatot igenyel, mire belatja valaki, hogy egy adott problematipusra a legegyszerubb megoldas valamilyen tervezesi minta lehet egy adott programozasi nyelven.

De kicsit tovabb haladva a gondolatmenetben: valoban erosseg lenne a tervezesi mintak meglete? Erosseg programsorok szazait legyartani ugyanazon problematipusra egy minta alapjan ujra es ujra ? Nem inkabb az adott programozasi nyelv "gyengesege" ? :D

( strangelove | 2009. 03. 21., szo – 14:49 )

programtervező matematikus szak kell neked!
ami át van húzva, azt teljesen fölösleges elolvasni. az olyan, mintha ott sem lenne

( gmatyi | 2009. 03. 21., szo – 17:41 )

vélekedésem szerint a kulcsszó jelen eseten: open source illetve reverse engineering. Vagyis az a teendőd, hogy előveszed a drupalt, wordpresst, joomlat stb. és elkezded olvasni a kódod, és megpróbálsz rájönni, hogy miként működik. Néhány hónapnyi munka után rá fogsz jönni, hogy mik az alapvető részei egy ilyen rendszernek, melyik rendszerben mi a jó, mi a rossz stb. Aztán ha még mindig nem adtad fel, nekiállhatsz elkészíteni a saját rendszeredet. (először uml-ben, aztán mehet a kódolás.). De valóban kérdés, hogy mennyire éri meg, hiszen ilyen rendszerekből valóban dunát lehet rekeszteni.

"kérdés, hogy mennyire éri meg, hiszen ilyen rendszerekből valóban dunát lehet rekeszteni."
- rengeteget lehet tanulni
- a saját keretrendszeredet jobban ismered, mint bármi mást, így gyorsan tudsz vele dolgozni
- Az említett rendszerek lassú dögök, túl vannak bonyolítva, tele felesleges dolgokkal, rendszeresen találnak bennük biztonsági hibákat

-----------
"Itt a tavasz lehelete,
hihi haha, hehe-hehe." :)

( hedermisi v | 2009. 03. 21., szo – 22:00 )

Szerintem a tervezési mintáknál sokkal fontosabb, hogy megismerd milyen szoftver architektúrák illetve architektúra minták léteznek, és ezek közül mit szoktak a web-en használni.

Az architektúrákról általában egy vázlatos összefoglalót ad a wikilap.

Ami a web szempontjából releváns, az szerintem a 2, 3, 3 1/2 rétegű architektúrák ismerete link. Ezeket útóbbi kettőt szokták bevetni enterprise, főleg java környezetben.

Aztán itt van a SOA, amit szerintem egy CMS rendszernél nem fogsz bevetni, de érdemes tudni miről van szó: wikilap.

És ha már SOA volt akkor jöjjön a jelenlegi kedvencem, a REST/ROA, amit nagyon fontolóra érdemes venni egy php alkalmazás esetén: itt és főleg itt

Van aztán az MVC, ami körül elég sok homály leng szvsz. Van ugyanis egy OO tervezési minta, amit egy UML diagramon ábrázolva megtalálsz a patterns könyvben, és van egy webalkalmazás tervezési "stílus" ami erre emlékeztet, szintén MVC-nek szeretik nevezni, de ha UML diagramon ábrázolnád akkor nem pont úgy nézne ki. Sőt olyan alkalmazást is neveztek már MVC alapúnak ami még csak nem is objektum orientált nyelven íródott. Szóval ha egy MVC programot látok sose tudom mire gondoljak pontosan...

Van még egy mókás dolog, a Pipes and Filters, amit itt-ott érdemes használni: wikilap. Filterek már az idők kezdete óta vannak a java servletekben és újabban már az apache-ban is. Szép példa a Cocoon arra, hogy meddig lehet eljutni egy kis REST-tel és a filterekkel. A legjobb ezt a megoldást használni az authentikációnál pl.

Megemlítendő még az eseményvezérelt architektúra: wikilap.

Ha ezekbe a wikilapokba, fejezetekbe beleolvasol, rá fogsz jönni, hogy a szoftvertervezés azért jobbára még esetleges és okkult tudomány, ahol ötletek kavarognak és még az sem biztos, hogy miről beszélünk...

Szerencsére azért már látszik egy kis fény a távolban: tőlünk nyugatabbra már van olyan szakma és képzés, hogy software engineer, aminek a törzsanyagát az IEEE sok-sok szakértője határozta meg, köztük néhány magyar is: http://www.swebok.org/. Ennek a törzsanyagnak az adaptálódását látom itthon a BME infó rendszerfejlesztés szakirányon (a többit nem ismerem annyira).

Illetve ha sok időd van, és tényleg érteni akarsz a dolgokhoz, akkor van itt egy könyv:
http://www.amazon.com/Software-Engineering-International-Computer-Scien…
magyarul:
http://www.libri.hu/hu/konyvek/szamitastechnika_internet/programozas_fe…

A konkrét problémára visszatérve, ha adott a technológia, az erősen befolyásolja, hogy milyen tervet használsz. Például a php alapvetően nem egy állapottal rendelkező dolog és ennek sajnos következményei vannak. Továbbá php-ban legtöbbször együtt használnak OO mintákat és relációs adatbázist, ami valami ORM megoldás bevetését teszi szükségessé. Ezek olyanok, hogy egész jól működnek, amíg egyszer valami igazán bonyolult dolgot akarsz velük csinálni és akkor jól megszívatnak. Ha meg nem használsz ORM-réteget, akkor fennáll a lehetősége hogy az adott adatbázis programtól fogsz függeni... Szóval a lényeg az, hogy a követelményeidet tisztázd előbb és az alapján dönts.

Köszönöm a sok tippet a sw architektúrákról, igyekszem minél jobban megérteni őket. Az ajánlott könyvről tudnál pár szót szólni? Nem egy olcsó mulatság, de ha tényleg szükségem van rá, feltétlenül megveszem. (Remélem a magyar is jó)
A felhasználandó technikáknál viszont kénytelen leszek húzni egy határt, mert a végén ott fogok tartani, hogy glassfisht kell terveznem.

A technológiát tekintve a php nem adott, csupán ehez értek legjobban. A cél hogy sokat tanuljak. Ha ennek melléktermékeként keletkezik egy általam jól ismert és használható általános célú cms, hát nembánom ,) (hangsúlyozom; olyan, amit én tudok jól használni, nem pedig drupalkiller). Bár ez a hozzáállás hibásnak tűnik, mert így a tervezés első lépésénél elakadok ("Alapvető célok meghatározása"), ezért van egy elképzelt kép a végtermékről.

Az ORM-ek határai talán egy ilyen rendszer szükségletei fölött húzhatóak meg, de ki tudja. Majd elválik a döntés helyessége később, hogy bevettem/kihagytam az orm-et.

>A felhasználandó technikáknál viszont kénytelen leszek húzni egy határt, mert a végén ott fogok tartani, hogy glassfisht kell terveznem.

Glassfisht semmiképp se tervezz :) Az architektúrákat ismerni kell, hogy tudd, a választott keretrendszer amit használsz hogyan működik.

A könyv a legátfogóbb szoftver metodológia irodalom, minden benne van a követelményanalízistől a tesztelésig. Csak emiatt a projekt miatt nem érdemes megvenni, ahhoz túl általános.

Ha egy CMS-t tervezel, akkor talán az a legfontosabb, hogy kitaláld milyen tartalmak lesznek, milyen relációban. Fórumon meg cikkeken kívül szokott lenni naptár, szavazások, ilyesmik. Bár nem (csak) CMS rendszer, de jó elrettentő példa az eGroupware: sokatféle entitás van benne sokféle relációban, cserébe kb 150 adatbázistábla és brutál joinok...

Az ajánlott könyvről tudnál pár szót szólni? Nem egy olcsó mulatság, de ha tényleg szükségem van rá, feltétlenül megveszem.

Sommerville konyve valoban jo bevezetes a szoftverfejlesztes tudomanyaba, ad egy amolyan "szoftverfejlesztoi altalanos muveltseget". Elonye, hogy valoban lefedi a teljes folyamatot, es minden fejezet vegen ajanl a szerzo nehany, a fejezet temajahoz kapcsolodo konyvet.

Hatranya szvsz, hogy csak egy bevezeto, elmagyarazza az alapfogalmakat, neha ad par tanacsot is, de egyik temat sem meriti ki, ~800 oldalban ez lehetetlen.

Szvsz szerezd be a konyvet, ha komolyan gondolod
a szakmat. A CMS-ed fejlesztesehez nem tartalmaz annyi hasznos informaciot...

Ha sokallod a >80$-os arat, megkaphatod hasznaltan az Amazon Marketplace-rol, szallitassal egyutt kijohet ~60$-bol. Magyar forditast semmilyen szakkonyvbol ne vasarolj! ;^)

Szerk: most latom, hogy nagyjabol ezt hedermisi is leirta...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Pénzt nem sajnálok ha tanulásról van szó, ez nekem egy jó befektetés, az árának a sokszorosát szeretném visszakeresni a merített tudásanyaggal ,)
A CMS teljesen másodlagos, a tapasztalatgyűjtés számít.

> "Magyar forditast semmilyen szakkonyvbol ne vasarolj! ;^)"
Ennyire rossz a helyzet? Olvastam én már szabályos kifejezést (regex) meg szerezGyermeket, és gondolom az említett könyv nyelvezete elég nehéz.

Pénzt nem sajnálok ha tanulásról van szó

Helyes! :^)

Ennyire rossz a helyzet?

En eddig egyszer valasztottam magyar forditast eredeti angol helyett, mert joval olcsobb volt, es nagyon megbantam. Benan volt forditva, tele volt hibakkal, stb.

Azert is erdemes az angol valtozatot valasztani, mert igy gyakorlod a nyelvet. Meg ha nehezebb is kezdetben, hidd el, megeri!

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Annyi még, hogy a Pendragon a kiadótól rendeli a könyvet ami sok esetben drágább mint ha futárral megrendelnéd Amazonról.

Az Amazon.com-nál érdemes figyelni, mert több különböző eladó is árulhatja ugyan azt a könyvet, de eddig én úgy vettem észre, hogy csak az Amazon.com (itt most mint eladó) szállít Magyarországra.

mert több különböző eladó is árulhatja ugyan azt a könyvet, de eddig én úgy vettem észre, hogy csak az Amazon.com (itt most mint eladó) szállít Magyarországra

Az Amazon Marketplace-re gondolsz? Az egy amolyan ebay konyveknek, ott kozvetlenul a tulaj arulja a konyvet, tole fugg, hogy hajlando-e elpostazni .hu-ra...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

nem gyenge egy eset alapján megítélni mindet.

Nem epp ez tortent, a ratyiul forditott konyv vasarlasa elott is az angol nyelvueket preferaltam, de a magyar valtozat jelentosen olcsobb volt, gondoltam megeri lemondani az angol konyv elonyeirol.

A erveimben jobban kellett volna hangsulyoznom a masodikat (nyelvtanulas)...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Jajj, az elvont gyár... Szívem másik csücske. :)

Nehéz ügy ez a fordítás, hogy hol húzod meg a határt. Én ott, hogy ha egy szöveget nehezebb megérteni az anyanyelveden, mint az eredeti, idegen nyelven, akkor valószínű sikerült túlzásba esni a magyarítással.

Aztán persze van, hogy az elsőre furcsán csengő kifejezés egy idő után gyökeret ereszt a köznyelvben, és természetes lesz a használata, de az elvont gyár például nem ez a kategória szerintem.
--
geri / otperc.net