@tildy:): A CakePHP is MVC. Meg a Zend is. (Model View Controller) Szerencsére megint hallok egy új javascript frameworkről.

@sajt: Tudom. Azert kerdeztem meg, melyik kell.

MVC?

Ne ezért utálom a rövidítéseket. Hiába telepítek és felügyelek LAMP rendszereket, elsőre eszembe sem jutott, hogy arról van szó.

Lehet érdemes lenne bedobni a MHTerror kommentjeibe.
A postok között elég sok a frusztrált informatikus.

@Kerek Perec: nah latod arra en is. kovetelmeny megvan eleg szepen, kivancsi lennek megtudnak -e fizetni...
telleg, tavmelo szobajohet?

Hát azt MVC-t meg kellet néznem, hogy mi. Égő :D

írtam már mvc-t, az ojjektumokat a kezemmel szoktam orientálni, ahogyan a dzsudzsák a fotball labdát. a php a második, az sql a harmadik anyanyelvem. javascript, jquery, extJS, mootooool, ha mondom segít a gondon. az xhtml/css remélem csak sértés, mert már minden kiscsoportos ovodás keni vágja, nehogymá követelmény legyen. 0.5M hufér elmegyek, ha kapok ingyé egy zöld trabantot szolgálati autónak, és egy iklón telefont. csak azér ilyen kedvező az ár, mer szeretem a blog.hu-t, bár szerintem szarul működik :)

Meglep hogy az MVC a magas labda.

Akkor rendesen lehetne szűrni ilyenekkel, hogy OCP, LSP, SRP...
Persze ezek is csak mind TLA-k (vagy HBR-ek), de aki már hallott róluk annak talán beugrik hogy micsodák.

@kitvalasztanal.hu: ez mondjuk benne van a hirdetesben, h nem tavmunkarol van szo.

@tildy:): ez reszletkedes.

Hmm, így eléggé szétesett hogy ki lett moderálva sok minden. Gyakorlatilag kérdés nélküli válaszok lettek. Nekem is válaszoltál de a többiek nem tudják mire. Ezt gondold át legközelebb.

@Kerek Perec: az erdemei kerdesek bentmaradtak, azokra valaszolok is. de muszaj attekinthetonek maradnia, a csetet altalaban birjuk, de ennel a posztnal nem, szorri, amit kiirtottam, az nem relevans cset vagy gyalazkodas volt.

@sztahanov: benne van, benne van. nade a rugalmassag?
nah, mindegy, ugysem nekem lett volna erdekes, havernek :)

@kitvalasztanal.hu: tavmunka ilyen tipusu munkanal nem mukodik. ez csapatmunka, sok operativ, napi teendo resze van, rengeteg a kommunikacio. szoval ez klasszikus bentulos melo, legalabbis az ido 90%-aban.

@sztahanov:
skypeal is meg lehet oldani sok mindent. En is innet dolgoztam meg egy darabig haza.

@tvk:
Meglep hogy az MVC a magas labda.
-------------------------------------
Tudod én pl. évek óta fejlesztek phpban, de eddig még kimaradt az életemből az MVC . Igaz meg tudom tanulni. Sajnos nekem is felejtős a távmunka lehetetlensége miatt, persze ha otthon élnék most talán jól jönne egy ilyen munka.

"Tudod én pl. évek óta fejlesztek phpban, de eddig még kimaradt az életemből az MVC"

Júj ezért jobb helyeken lefejezés jár ;)

@butcher511: Járjon. Tudom mi az, és azt is, hogy képes vagyok megtanulni. Egyelőre nem kellett , de tudom hogy fog, ugyhogy tanulom. Van par ebookom:D
Eleve hátrányból indultam így is sokszor, a nemem miatt. Nő? Fejlesztő? ÁÁÁ...

@tildy:): Nálam előny lenne ha felvételiznél ;)

Amúgy simán végezhető távmunkába is az ilyen fejlesztés és support. Én 1 évig csináltam így. Az ügyfelek úgy is távolról keresnek, a szervert meg csak újraindítani kell fizikailag, minden más távolról elérhető. A csapatmunka pedig jórészt skype-on folyik mert az ember lusta egy asztallal is odébb menni. De ha 3-4 országból tevődik össze a csapat akkor is gond nélkül pörög a meló.

A távmunka csak hozzáállás kérdése.

Az MVC pedig alap, akinek ez a szakmája, az hamar belefut. Amúgy is minden állásinterjún rákérdeznek, ami elég ciki 5-10 éves gyakorlat esetében.

oszt mennyi a della? profi csak profi céghez megy dolgozni ahol a 3.mondatattól tudja hogy mennyi dellát tehet el a munkájáért...

@tildy: Bökd meg legalább akkor ne gyere azzal hogy nő vagy, amikor kijelented hogy nem tudsz valamit. Nem taktikus. A többi nőnek még hagyj esélyt :)

@sztahanov: nalunk 4 programozo dolgozik az orszag 4 kulonbozo pontjarol 1 projecten.
De Egerbol en is nagyon szeretek pecsiekkel dolgozni.
XXI. szazad. Bar IRC mar elotte is volt...

Várhatók a közeljövőben komolyabb fejlesztések a blog.hu-n, ezért kell új ember? Ez jó hír lenne, úgyhogy erősítsétek meg, ha így van. :)

Legközelebb szmájli mellé odaírom, hogy viccelek, mert látom komolyan vettétek. Nem gondoltam komolyn :)

portás nem kell? vagy irodista?

Én szeretnék jelenkezni, de sajnos nem értem az első bekezdést a sok rövidítés miatt.

Mire rendbe teszem a referenciáimat, meg úgy az egész weboldalamat, addigra 3x betelik az összes (1db?) pozíció... :S

Ha lehet kérdeznem: hány főt kerestek és nagyjából meddig van értelme leadni a jelentkezéseket?

@prometheus_X: kb jovo pentekig lesz kint a hirdetes es egynel tobb embert keresunk.

a tavmunkarol kene egy kulon forum, ugy latom :-) mert ha itt elkezdunk vitatkozni rola, elvisszuk az egesz topikot. maradjunk abba, h mi nem igy dolgozunk, masnal siman bejohet.

@agyvihar: annyi tervunk van, h tiz fejlesztonek is lenne munkaja. de persze nem en mondom meg, hany fejlesztonk lehet.

@kalnoki: a della mindig, mindenhol alku kerdese.

@charliesan: Gondolom nálad is van valami, amiben nem vagy otthonos. És egyébként is, valahol el kell kezdeni, igen vannak dolgok amiket nem tudok, de szeretnék tudni.
És az is igaz , párszor már rákérdeztek miért van egy csaj ilyen területen.
De nyugodj meg az MVC nem tudásának - meg lehet ugye tanulni , és a hajlandóság megvan- eddig köze nem volt ahhoz hogy erre a dologra rákérdeztek.

Igen az MVC-t nem tudom (még) , de emellett olyan portfolióval rendelkezem, amely megállja a helyét akár külföldön is . :P

mi a tököm az az mvc, miért jobb mint a nyers php?

Az MVC meg az objektumorientáltság nagyon jó (lehet) fejlesztői oldalról, de amikor egy interpreterre fejleszt az ember, akkor azért érdemes elgondolkodni, hogy ezek valóban kellenek-e. Én szeretem az OOP-ot, meg tényleg jó az üzleti logikát is elválasztai az adatkezelő rétegtől, de azért az indokoltságot érdemes átgondolni PHP esetén.

Bár teszteket nem ismerek és idő hiányában nem is készítek, de egyszer tanulságos volna lemérni, hogy egy JÓL megírt OOP és MVC mennyit lassít egy több száz konkurens useres alkalmazáson. Még az is lehet, hogy egy fürge szerveren nem jelentős (bár ezt erősen kétlem).

Valakinek van ilyen irányú tapasztalata?

Már ha nem leszek kimoderálva ismét gyorsan.

@Blogerovac: én igazándiból azt várom a php 6-tól, hogy teljes mértékű objektumorientáltságot kapjon, mint pl a C#, vagy a java.

@Blogerovac: "Bár teszteket nem ismerek és idő hiányában nem is készítek, de egyszer tanulságos volna lemérni, hogy egy JÓL megírt OOP és MVC mennyit lassít egy több száz konkurens useres alkalmazáson. Még az is lehet, hogy egy fürge szerveren nem jelentős (bár ezt erősen kétlem)."

Egy komolyabb alkalmazást nem lehet megírni OOP és MVC nélkül.
Az optimalizáció pedig más kérdés, nem a fenti 2 dolgon kell behozni a sebességet.
Aki nem tudja mi az az MVC az gyorsan nézzen utána mert alap tudás,
függetlenül attól hogy milyen nyelven dolgozik.

@tildy:): "Igen az MVC-t nem tudom (még) , de emellett olyan portfolióval rendelkezem, amely megállja a helyét akár külföldön is . :P"

Ebben ne légy olyan biztos, nem tudom hány év gyakorlatod van de ha elmész egy interjúra és nem tudsz válaszolni egy teljesen alap kérdésre, azonnal elhasaltál, és nem azért mert csaj vagy.

A fenti sorokból látom,hogy nagyon sok emberre ráfér ezen oldal átböngészése:
en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Még van ezen felül jónéhány hasznos design pattern...

@sztahanov: "a della mindig, mindenhol alku kerdese."

Nekem az a tapasztalatom hogy komolyabb cégek előre eldöntik mennyit szánnak a melóra vagy az adott tudású emberre. Kis cégek szoktak alkudozni, természetesen hogy minél olcsóbban megkapják a munkaerőt, de ez sajnos sokszor a minőség rovására megy. Szerintem.

Amúgy sarkalatos pont a pénz mert egy rakás helyre berángatják az embert mert tetszik nekik az önéletrajz, aztán kiderül hogy fele annyit sem tudnak fizetni mint amennyit ér. Szerintem jobb ha előre közlik, akár csak nagyságrendileg is.

@Kerek Perec: "Egy komolyabb alkalmazást nem lehet megírni OOP és MVC nélkül."

Még nem programozok nagyon régen munkaként (étsd: nem csak hobbiból), csak '89 óta, de azért ezt cáfolnám. Vannak olyan projektek, amikbe egyszerűen nem szükségszerű az OOP, bár az előnyeit nem vitatom egy pillanatig sem és már csak megszokásból is alkalmazom, ha csak valamiért nem látom nagyon indokolatlannak.

Az MVC pedig szintén akkor lehet érdekes, ha van rá esély, hogy az adatkezelő réteg változhat (például másik adatbáziskezelő kerülhet valaha az alkalmazás alá), vagy ha a fejlesztő csapatban "speialisták" dolgoznak, akikből van aki az egyik réteghez, van aki a másikhoz ért különösen jól (értsd: az egyik SQL guru, a másik meg vágja a javascriptet). Egyéb esetekben szerintem nagyon szépen és átláthatóan lehet fejleszteni MVC nélkül is. Ezzel együtt természetesen az MVC jó, és érdemes alkalmazni, csak túlzásnak érzem azt állítani, hogy nélküle nem lehet.

Egyébként meg nyilván az ember személyes tapasztalatai erősen meghatározzák a véleményét :)

"egy rakás helyre berángatják az embert mert tetszik nekik az önéletrajz, aztán kiderül hogy fele annyit sem tudnak fizetni"

5 éve volt egy ilyen esetem, hogy egy Holdinghoz(!) mentem állásinterjúra. Budai iroda, teljes szint az övéké, nagyon profi, komoly, mindenre kiterjedő írsbeli kérdéssor (logika, programozás elmélet, gyakorlat, személyes rész) - gondoltam ez egy komoly cég. Aztán kiértesítettek, hogy megfeleltem és mondtak olyan bruttó fizetést a próbaidő utánra, amit a próbaidőre nettóban is nevetségesnek tartottam.

Szóval néha tényleg jobb lenne nem rabolni egymás idejét. :)

@Blogerovac: Hát, azért vannak olyan nyelvek melyek szinte determinálják, hogy milyen eszközökkel/stílusban kell dolgoznod. Pl egy Java ill. egy C# .Net programozónak elég nehéz meglennie az OOP nélkül.. :P

Blogerovac: skálázható, robosztus rendszerekben jelentősen növeli az átláthatóságot, és csökkenti a fejlesztési időt az MVC-k használata. nem mintha, egyébként nem lassítana - mert ugyebár minden absztrakció lassít valamennyit. de általában nem szűk keresztmetszet. bár meg kell jegyeznem, hogy egy komoly elosztott rendszer tervezésekor az MVC az csak egy pattern a sok közül, amit érdemes használni. bár az említett frameworköket nem ismerem. de az biztos, hogy aki még mindig ott tart, hogy ne legyünk objektumorientáltak, mert a vtable sok memóriát foglal és nagyobb lesz a callstack, az kábé 20 évvel van lemaradva. értelem szerűen nem a kólaautómata programozókra vonatkozik.

@EvilHedgehog: ezért mondom, h jó lenne ha a php-t fullos oop rendszerré alakítanák. akkor nem lenne szükség látszatmegoldásokra. mondjuk ebben az esetben meg azzal lenne kicseszve aki az oop nélkül szeretné a php progikat megírni. akkor lehetne egymás mellett fejleszteni 2 interpretert. pl - igaz nem interpreter de - a gcc és a g++.

@Kerek Perec: 3. Bár már 2002ben is írtam php kódot, csak utána évekig más területen dolgoztam.

@danleis: én konkréta a PHP, mint interpreter esetében tettem egy kisebb kérdőjelet az OOP mögé. Mivel PHP-ban nem fejlesztettem még igazán robosztus rendszert, csak "offline" platformon, így konkrétan ebben az esetben érdekelne, hogy ez mennyire fogja meg a szervert. Nem webes, kliens-szerver alkalmazásoknál nem kérdés az OOP, az MVC meg néhány fejlesztő környezetben részben szinte automatikus is lehet.

De mondjuk attól is elsírom magam, amikor belegondolok, hogy az ASP.NET felhúzza a komoly objektum strukturákat a relatív egyszerű weboldalakhoz, csak mert rápakoltak pár "gyári" komponenst. Mondjuk láttam is élőben egy ilyen 80 milliós rendszert, ahogy összeroskadt a gigaszerveren, amikor az 50 user elkezdte használni. Persze ez adódhat egyéb szervezési, fejlesztési gondokból is, nem feltétlenül az OOP bűne (sokkal inkább a ASP-s megvalósításé ;) - bár ez tényleg csak kacsintós, mert nem ismerem mélyen az ASP.NET-et)

@Blogerovac: hát az ASP.NET az tényleg elég gyenge :) ezzel egyet értek. meg hát az MS-nek van még jónéhány megoldása aminek be kéne kerülnie a "Hogyan NE írjunk keretrendszert?" c. könyvembe, amit már régóta tervezek megírni :)

sok hányadék rendszert láttam már én is. dehát az okos ember más hibájából is tud tanulni nemde? :) nem egy olyan projektet láttam, ahol picipénzből akartak nagy rendszert és olyanokra bízták, akikre nem kellett volna. aztán amikor jöttek a deadlineok a "guruk" kezdték elhagyni a sűlyedő hajót. és akkor jön a "rendben megfizetünk egy profit, csak rakja rendbe" megoldás, amikor aztán az ember két hányás között megpróbálja rábeszélni a menágereket, hogy "könyörgöm hadd írjuk újra, mert ebből nem lehet...", se dokumentáció, se rajzok, se kommentek.

(és hogy értelme is legyen annak amit írok) mindenkinek melegen javaslom a design patternek, kódolási konvenciók, fejlesztési módszertanok, tervezőeszközök és a kommentezés megszokását és használatát - egy közepes fejlesztő háromszor többet ér, ha kommentezi a kódját, mégha nem is egy lángelme, mint a zseni, akinek a munkáját senki sem tudja folytatni. bár meg kell hagyni, az utóbbi stratégia is lehet életbiztosítás :)

@Kerek Perec: >Egy komolyabb alkalmazást nem lehet megírni OOP és MVC nélkül.

Ez baromsag. A vilagon mindent meg lehet irni OOP nelkul.
Ez nem azt jelenti, hogy erdemes is. ;)

@RaveAcE: attól függ. ha csapatmunkáról van szó, akkor a személyes jelenlét elengedhetetlen. közvetlen kapcsolat a projekt vezetőjével és a csapattagokkal. az együttműködést nagyban növeli. szerintem.

@LORD GAGA:
Ezzel nem is vitatkozom, csak azzal, hogy erre napi szinten lenne szükség. Cserébe a sokkal kevesebb utazási és irodai költségekért és a nagyobb flexibilitásért.
Ha egy programozóval naponta (többször) kell egyeztetni, mi a dolga - és nem elég a mail, chat, telefon - az elég ciki.

Az OOP tényleg sokszor felesleges. Az egyszerű, szépen dokumentált kód aranyat ér!

Sok sikert Blogmotor-fejlesztők!

G*** mod on:

XHTML ismereteket nem veletlenul varjak am el az uj embertol! :)

validator.w3.org/check?uri=http%3A%2F%2Fwww.blog.hu%2F&charset=%28detect+automatically%29&doctype=Inline&group=0&user-agent=W3C_Validator%2F1.654

(Persze a sajat oldalaim se kulonbek, csak kivancsi voltam)

@Kerek Perec: a penz fugg attol is pl, h mennyire eros embert talalunk egy poziciora. tehat ha egy 'eppen megfelelo' ember akad a horogra, akkorn nem ugyanakkora a keret, mintha egy sokkal jobb.

de ezzel nem szokott baj lenni, legkesobb az elso interjun tisztazodik.

OOP nelkul a blog.hu komplexitasaval szoftvert tervezni komolytalan. az optimalizalas nem ezen a szinten van. mivel a jelenlegi rendszer abszolut OOP, nem erdemes azzal kezdeni az interjut, h valaki szeretne oop-tleniteni az elso nehany honapban :-)

"A legnagyobb és legambíciózusabb hazai blogszolgáltatás tervezési, fejlesztési és üzemeltetési feladatait fogod megoldani egy fiatal, kísérletező, lehetetlent nem ismerő csapatban."
Nekem ez a kedvenc mondatom.

@LORD GAGA: ha nem akartok dugni (bocs:) akkor inditsd el a skype -ot, hasznalj mikrofont es fel sem fogtuni a kulonbseg. hacsak,h nem kel latkiabalni egyik fulkebol a masikba mertha normalisan beszelsz is halja.
azert ha 90% a munkaidobol kommunikaciora megye el, mikor kell dolgozni?:)

"XHTML ismereteket nem veletlenul varjak am el az uj embertol! :)"

Ezzel szerintem az a fő baj, hogy ha a site egyes részeit a userek írják (lásd: a blog szövege), akkor azt valamilyen editorral teszik. Ha az nem plain text, akkor költséghatékony megoldás, nem túl tiszta, de száraz érzés ;), ha valamilyen nyílt forráskodú terméket raksz be. Az viszont ki tudja, milyen szabvány szerinti - ha éppen nem teljesen szabványtalan - html kódot vág majd be az egyébként nagyon xhtml strict oldaladra.

Erre persze lehet azt mondani, hogy nem kell mások "sz@rját" használni és ezzel egyébként teljesen egyet is értek, csak néha van, hogy egyszerűen nem fér bele a költségkeretbe vagy az időbe, hogy elkészüljön egy meglehetősen nagy, de például a megrendelő részéről szinte nem is látszó fejlesztés, és akkor marad az elérhető komponensek beépítése. Mint ahogy ez a blug.hu esetében is így van konkrétan a blog szövegeditor esetében (is).

@sztahanov: "mivel a jelenlegi rendszer abszolut OOP, nem erdemes azzal kezdeni az interjut, h valaki szeretne oop-tleniteni"

Bocs, félreérthető voltam. Nem amellett akarok lándzsát törni, hogy az OOP rossz (sőt!), csak felvetettem - mivel egy ideje foglalkoztat a kérdés -, hogy vajon mit jelent ez erőforrásigényben. De ha lesz egy kis időm, tényleg írok már egy ilyen irányú tesztet. Mondjuk egy blogmotort ;)

Ha meg a rendszer egyébként OOP, akkor nem kérdés, hogy ahhoz kell igazodnia a további fejlesztéseknek is. De arra egyébként kíváncsi lennék, hogy a blog.hu mennyire komplex. Leginkább az a gyanúm, hogy indokolatlanul, mivel egy robosztus nyílt forráskódra épül (ha jól sejtem), ami jól skálázható akart lenni, ezért van fél tonna kód benne a 70 kg-os feladatra.

De ez legyen már a jelentkezők gondja :)

@Blogerovac: mar csak az adminfelulet tartalmaz nyomokban b2evo reszeket, a teljes backend+frontend ujra lett irva sajat, terhelesturo frameworkben/re/on. A kod nem spagetti, a rendszer alaparchitekturaja nem ganyolt, hanem szep.

@tildy:): Azért.. tegyük, hozzá, hogy helyes, és a hátrány ledolgozhatatlan előnnyé változik.

Ami a hirdetést illeti.. egy jófajta java fejlesztő nem kell a backendre? :) Költői kérdés... sejtem, hogy nem.

@Watchman: de kell, de nem tudunk erre egy teljes poziciot szanni. eleg keves resz van javaban.

@sztahanov: sajat, terhelesturo frameworkben/re/on.

Tényleg bocs, hogy off, töröld ha zavaró, de ilyen kijelentést én már az index-nél sokkal nagyobb cégtől is hallottam. És hát.. a saját volt benne az igaz... a többi a wishful thinking. Tényleg ennyire irtózik még az index is az idő próbáját kiállt nyílt keretrendszerektől, vagy csak php-ban nincs ilyen?

@Watchman: komoly feladatra sajat keretrendszer kell, nem veletlen, h az index sem ipari cms-t hasznal. a blog.hu nagyon nagy komplexitasu, nagyon nagy terhelest kiszolgalo, nagyon dinamikus rendszer. nem lehet szorakozni valakinek a keszen irt cuccaval, ami ezer sebbol verzik, mert nem azokkal a prioritasokkal terveztek, amire nekunk kell.

perpill van egy bizonyitottan mukodo, terhelesbiro, nagyon skalazhato, rugalmas, robusztus rendszerunk, nem tudom, miert kene rosszul ereznunk magunkat emiatt.

@sztahanov: A legkevésbé sem szántam támadásnak, tehát ne érezzétek magatokat rosszul emiatt. Nem is ismerem olyan jól a php-t, hogy vitába kezdjek veled. De java-ban a tapasztalatom azt mutatja, hogy a nem szoftverfejlesztéssel foglalkozó cégek sosem tudnak olyan keretrendszert írni, ami az apache/eclipse/sun/stb. által paternált keretrendszerekkel versenybe tudna szállni a webfejlesztés terén. És tényleg nem szomszédpisti btjétől van szó, hanem multikról. Csak érdekelt volna, hogy a php-ban nincsenek ilyen rendszerek, vagy az általam rendkívül nyitottnak gondolt index is idegenkedik-e ezektől.

@Watchman: nem vettem tamadasnak, hanem diskurzusnak termeszetesen.

A multiknak egeszen mas prioritasaik vannak, mint webes szolgaltatasnak (pl egy multinal nem kell igazi terhelesre keszulni), ez ket teljesen mas vilag, igy pl a nagy webes szolgaltatasok kozott sem hasznalnak tul sokan se javat, se elore megirt keretrendszert (a legtobb nagyrol ki lehet guglizni, h milyen platformot hasznal, meglepoen dominans a php es a mysql, meg persze az is, h vegyes kornyezetben dolgoznak, feladatonkent mas nyelvben/alrendszerben, mindegy).

Nem tudom igazabol, van-e olyan php-s keretrendszer, ami etalonnak tekintheto, azt tippelem, h inkabb rengeteg obskurus rendszer van, mintsem nehany elfogadott. De keretrendszert irni nem olyan draga mulatsag, boven megeri az, h a sajat prioritasaidat figyelembe tudod venni.

@sztahanov: pozitívan csalódtam bennetek. Meg voltam győződve, hogy csak foltozgattok egy "importált" blogmotort. Ez már így jól hangzik. Lehet, hogy Fejlesztők dolgoznak ott? ;)

@Watchman: nekem is az a tapasztalatom, hogy ha egy opensource rendszert kezdesz használni valami komolyabb feladatra - akár csak egy kisebb közössségi oldal kiszolgálására - előbb-utóbb eljutsz oda, hogy bárcsak nekikezdtél volna inkább nulláról lefejleszteni (persze általában erre nincs idő/pénz, vagy el akarják spórolni :)). Mert biztos, hogy beleütközöl a korlátaiba, méggyakrabban a hibáiba és akkor hozzá kell fejleszteni. Ekkor találkozol egy számodra ismeretlen, talán dokumentálatlan logikával, felépítéssel, forrással, ami rossz esetben még csak nem is pont arra készült, amire használni szeretnéd. Belefoltozol, aztán meg fogod a fejed, hogy most hogy tedd rá a az j, hibajavításokat tartalmazó verziót, ami kijön rá, mert az agyonüti a hozzáfejlesztett kódod. Ha meg nem frissítesz, akkor foltozhatod tovább magad további rengeteg időt, energiát rááldozva. Persze, ha frissíted, akkor is ez lesz :)

Szóval komolyabb felhasználás esetén vagy nagy kompromisszumok jönnek, vagy nagy fejfájás és plusz munka. Ami nagyon általános, az azért nem jó, ami speciális, az meg azért :)

@Blogerovac: a fejlesztés idejét figyelembe kell venni. egy ismeretlen kód bogarászása rengeteg időt tud felemészteni és ki tudja, hogy hányszor kell ezt megtenned az oldal élete során. egy új kód mindenféleképpen jó, mivel ismered és bármikor hozzá tudsz nyúlni, már ha megfelelően van megtervezve.

@Blogerovac: nem volt egyszeru egyebkent eladni, h ujra szeretnenk irni a bloghu belsejet, tehat kb azt a reszt, amit senki sem vesz eszre, h letezik, csak akkor, ha epp le van halva a rendszer. Szoval volt egy jo feleves projekt, amiben semmi latvanyos elem nem volt. Megerne egy kulon miset vagy posztot az is.

Iden viszont szeretnenk latvanyos dolgokat csinalni, na.

Azért nem állom meg, hogy ne reagáljak erre: "komoly feladatra sajat keretrendszer kell". Ez így azért nem igaz, Yahoo Answers is elketyeg symfony-val, igaz az alap ORM-et dobták belőle. Egy átlag MVC rendszerből az VC rész az általában kb. bármire használhat, az M tud problémás lennei (már ha van rá beépített támogatás). Az M-re viszont úgyis tudsz általában bármit használni, nem köti meg a kezed a framework.

Azt is érdemes mondjuk figyelembe venni, hogy egy nagy terhelésű rendszer esetén is az oldalak elég nagy százaléka nem kap terhelést, ezért nem feltétlenül gond az, ha az egyéb előnyök (pl. fejlesztési idő) miatt bukunk kicsit a teljesítményen.

Az viszont tény, hogy előnyökkel jár egy saját framework (mi is ezt használunk), alapvetően már csak az, hogy a konkrét feladatra kell megoldást nyújtania, nem kell mindenkinek megfelelni, ami sokszor kicsit terjengőssé tud tenni egy frameworköt.

@"nem ismerem az MVC-t": Az megvan hogy mi az a tervezési minta?

@sztahanov: Ti az új index házban laktok? Ha nem, hol?

@sztahanov: Nem lenne egyszerűbb valahogy fullra Wordpresst használni, valami API-al? A cucc már van, és hatalmas jók a feature-ök, érted. Valahogy meg beállítjátok kötelezőbe ezt a rohadt fontos két hirdetési helyet, amiből a "skyscraper" nevű hatalmas rosszul klikkelődik / konvertál amúgy.

Ja, szóval nem okoskodni akarok, de az a fél év kódolás... én lennék a főnök, én is hanyattfordulnÁk, érted. :)

@tvk: ott, igen.

@Nyelvész Józsi: nem nagyon latod a dolog a komplexitasat, ezzel most nem sertegetni akarlak, csak mondom :-) A Wordpress kifele csilivili, de belulrol egy ocska ganyolt szemet, abbol nem lehet epitkezni, plusz nem multijuzer multiblogos kornyezetnek terveztek, raadasul nem nagyon oldhato meg az, hogy ha a wordpressbol kijon egy uj verzio, akkor az magatol befrissuljon, hiszen addig egy csomohelyen mar belenyultunk, minden valtozast kezzel atvezetni - remalom, az fckeditorral ezt csinaljuk, az joval szimplabb rendszer, de ott is halal.

Nem tudom, hogy miért van az eddig általam olvasott hozzászólók mindegyikének olyan berögzése, hogy ami MVC, az csakis OO lehet. Ez egy baromság. Az OO egy programozási technika, amit egy nyelv vagy támogat (valamennyire), vagy nem, de az OO nem támogatás függő (elvileg... a gyakorlatban meg b+ akinek annyi ideje van, hogy OO-t implementál olyan nyelvre, ahol nincs rá támogatás :PP). Az MVC egy tervezési minta, egyáltalán nem függ attól, hogy egy rendszer OO-e vagy sem. Vannak nem OO alapú adatelérő megoldások, vannak nem OO alapú sablonozók (bár egy V attól lehet több is, kevesebb is), a C-t pedig csak akkor nem felesleges OO-ra írni, ha a keretrendszer OO.

@sztahanov: Ha nem használok ismert OO FW-t, de van sajátom ami OO is, MVC is, sőt ORM-et is tartalmaz, az belefér, vagy mindenképp szükséges a gyakorlati jártasság mondjuk Symfony-ban vagy ZF-ben? Felszínesen valamennyire mindkettőt ismerem, mert nézegetni szoktam a develóper gájdjait meg az API doksikat hogy ne haljak meg hülyén, de ennek semmi köze a gyakorlathoz azért. A sajátomat nyilván használom is :P az egyébként eleve ExtJS orientáltságú (nem drótosan, de pl. a JsonStore kezelését egyszerűsítő megoldást IS implementáltam bele).

És köszi az előző választ.

@prometheus_X: ez nem ilyen rigid, nem arra van szuksegunk, h pont az altalunk hasznalt frameworko(ke)t, eszkozok ismerje valaki, hanem hogy el lehessen rola hinni, h betanul ezekbe. ha hasznalt analog rendszereket es erti az elvi hatteret, akkor elhisszuk, h belejon ebbe is. nincsenek kesz fejlesztok, alakithatokat keresunk.

Köszi!

@tvk: Arra gondolsz, hogy jól elkülöníthetően legyen meg a megjelenítés , és a backend rész?
Mert ha igen, ilyen rendszert már használtam, de köze nem volt ismert MVCkhez.

@tildy:): Mondjuk ezek a munkahelyem saját fejlesztésű CRM és CMS rendszerei voltak.
Igaz nem OO-ak.

@Blogerovac: raadasul ezek a wysiwyg editorok vannak olyan pofatlanok, hogy nem is direkte szurjak be a kodot, hanem a bongeszodnek erre hivatott metodusait/fuggvenyeit hivogatjak, amik persze bongeszonkent valtoznak mind hivas, mind vegeredmeny szempontjabol (pl. az MSIE ha jol tudom, a mai napig nagybetuvel irja a tageket a kodba, enter leutesere "</P><P>" kodot ir, mig pl. a FF meg "<br /><br />"-t). Momentan nem lehet olyan editort irni, ami minden bongeszon strict HTML kodot ad, mert nem az editor js kodja a bottleneck, hanem a bongeszo maga.

@sztahanov: Ha te mondod, biztos így van. De azért van pl. Wordpress MU, amit kifejezetten erre találtak ki. De te vagy a szakértő, én nem gondoltam volna, hogy a WP "gány belülről".

@tildy:): mik azok az "ismert MVCk"? :)

@BOB: ja igen, ezek a kulonbsegek amikrol beszelsz, a designmode-dal megvalositott wysiwyg feluleteken jonnek elo.
az elterjedtebb wysiwyg editorok (pl tinyMCE), egyforma kodot generalnak minden bongeszon.

@Nyelvész Józsi: sajnos a wordpress mu belseje egy igazi horror, annak idejen en egyebkent probalkoztam vele egy ideig, de az nem igaz, h erre talaltak ki, hanem egyszeruen fogtak a wordpresst, es megprobaltakat megeroszakolni ugy, h multiblogos legyen. ezt ugy csinaltak, h minden uj blognak uj tablakat kellett letrehozni az adatbazisban... el tudod kepzelni, h a szazezer bloghoz felveszel az adatbazisban szazezer uj tablat? (legalabb 5 tabla kellett neki egy uj bloghoz, szoval inkabb felmilliot).

egyaltalan, a wp egyszeruen mas prioritasokkal keszult, sokkal fontosabb volt pl a rugalmassag, mint az, h mass service alapjaul szolgaljon. a legutobbi verziokat mar nem ismerem, de az elejen nagyon dinamikus, ergo terhelhetetlen volt, raadasul a wp sablonban pl van php, ez elkepzelhetetlen lenne egy szolgaltatas eseteben, nem tudod kontrolllalni, melyik kedves juzer hogy probalja lehalasztani a rendszeredet sablonba szurt hekkekkel.

@BOB: az fckeditornal - es szerintem mashol is - konfigolhato, h mit szurjon be enterre. persze az elso verziok, amiket a blog.hu-ban is hasznaltunk, p-t szurtak be ie-ben, br-t firefoxban, igen.

@sztahanov: Értelek. PHP-val én se játszatnám a parasztokat. Így is megőrülök, ha havonta-kéthavonta van egy "sünetelés". De utálom azt a sünt, te. :)

Ja, szólok egy-két PHP-mókus spannak, hogy van ez a lehetőség, jut eszembe, ezért kattintottam ide. :)

Aki nem tudja mi az az mvc, az nézze meg ezt:
blog.aer.hu/
meg olvassa el ezt:
blog.aer.hu/wp-content/uploads/2007/06/alkalmazasfejlesztes-cakephp-keretrendszerrel.pdf

@Nyelvész Józsi: nagyon ritkan van mar suneteles (jo az uj frontend), ha van, akkor ejjel van konkret karbvantartasi okkal.

tinymce úgy ahogy strict kódot ad, beállíthatod neki, hogy <p></p> vagy <br /> -t használjon, nagyon jó kis editor, szerintem jobb mint az fck.

@karacsi_maci: az fck is strict kodot csinal, sztem minden ilyen editor. tervezzuk egyebkent, h legyen alternativa, de nem a tinymce, hanem a ck editor a favorit.

WP-MU-val mi is probalkoztunk annak idejen (egy csodalatos goth.hu blogrendszert szerettunk volna csinalni :) ) es elsore en is megrokonyodtem ezen az blogonkent uj tablak dolgon. Raadasul mi is fejlesztgettunk hozza a kodjahoz rendesen, es tenyleg katasztrofalis (volt akkor, nem tudom azota hogy nez ki).
Viszont PHP frameworkokrol nincs valahol valami ertekezes? Kivancsi lennek, hogy ki mit hasznal, milyen elonyeik vannak az egyiknek/masiknak gyakorlati szempontbol megkozelitve. En Zend-et kezdtem el hasznalni, de masfele meg nem is nagyon tekintgettem ezugyben.

@Lzolcsi: szerintem a wordpress, meg ugy altalaban a nyilt forraskodu cuccok ellen leginkabb az szol, hogy rendszeresen feltorik oket, mig egy hazilag ganyolt rendszer biztonsagi hibait forraskod nelkul joval nehezebb kiismerni.

a frameworkok kozul szerintem a cakephp es a symfony johet meg szamitasba. utobbira van nagyobb kereslet mostanaban, es nagyobb a tamogatottsaga is.
en mindenesetre zendet hasznalok, megiscsak az a leg "php kozelibb" ;P

@tildy:): hehe, pont rad gondoltam en is :)

CSS? Azt hogy lehet megtanulni? Én már x éve próbálom, de nem megy. Persze nem az óvodás színezgetés stb, hanem pl. a div-es layout, amit képtelen voltam úgy megcsinálni, hogy mindenhol menjen (IE6 ugye, a kedvencem), vagy mindig szétesett. Hackeket meg akar a halál.
Mikor lesz már normális, mindenhol ugyanúgy támogatott a CSS? 10 év, 20 év?

Nem tom de én már a kezdek kezdtén elválasztottam a rétegeket mert idegesített a zagyvaság :)

@Lzolcsi: Szerintem a Yii-t érdemes nézegetni. Az API leírása alapjánt tiszta, átgondolt OO rendszer - nem mellékesen tör fel mint a karsztvíz.
JS FW-k közül szerintem az ExtJS az, ami 1-2 éven belül megkerülhetetlen szakismereti tényezővé válik - ha az Ext Designer-t is kiadják még ezévben, akkor szerintem hamarabb is.

@eztskubizd: "szerintem a wordpress, meg ugy altalaban a nyilt forraskodu cuccok ellen leginkabb az szol, hogy rendszeresen feltorik oket, mig egy hazilag ganyolt rendszer biztonsagi hibait forraskod nelkul joval nehezebb kiismerni."

Ezzel csak azért nem tudok egyetérteni, mert a házi sufnituning rendszerek pedig többnyire alulmaradnak az olyan tipikus hibák kivédésében, mint az SQL inject, az XSS, vagy a Unicode támadhatóságok kezelése. Meg egyébként még kismillió más téren is. A nem publikus kód nem jelent kisebb sebezhetőséget, a sebezhetőségek nagy része tipikus. Az egyetlen dolog, ami képes csökkenteni egy rendszer sebezhetőségét, az a minél kisebb kódméret és a minél nagyobb szegmentáltság (utóbbi viszont máshol jelent hátrányt: sebességben, főleg, később pedig áttekinthetőségben üthet vissza). A fő szempont, hogy mekkora mennyiségű kódra mekkora mennyiségű legalább közepesen jártas koponya jut. Utóbbiban lássuk be, a nyílt rendszerek ismertebb része erősebb. Persze, ez adhat lehetőséget visszaélésekre is. De egy támadás nem annyira a célrendszertől függ, mint inkább attól, hogy mi a támadó érdeke és ahhoz milyen potenciális felületeket választ. Ha spam a cél, akkor kisebb apróhirdető oldalak az ideálisak, de ez sincs összefüggésben azzal, hogy mivel üzemelnek ezek az oldalak. Másrészt: törhetetlen rendszerek csak a marketing menedzserek álmaiban vannak.

"a frameworkok kozul szerintem a cakephp es a symfony johet meg szamitasba."
Mindkét rendszert egyre több és egyre keményebb kritika éri. Szerintem a Cake hamar ki fog szorulni, a Symfony nekem jóval rugalmasabbnak tűnik, ott ez a trend akár változhat is.

Magánként mindenki olyan rendszert használjon, ami neki a legkézenfekvőbb, amiben a legproduktívabb tud lenni - persze érdemes mindig figyelemmel kísérni az újabb rendszerek alakulását is. Csapatban pedig úgy is azt kell majd használnia, amit a csapat vagy a góré kiválaszt - lett légyen az akármekkora fostalicska is (vagy épp jó, mindegy).

@prometheus_X: Yii-nek utana fogok nezni, koszi a tippet. ExtJS-hez, meg mondhatni volt mar szerencsem, harom ugyviteli rendszert sikerult mar elkesziteni benne. Egyetertek abban, hogy bizonyos teruleteken ez a jovo, peldaul egy szamlazo programnal nagyon hasznos, hogy akarhol akarmilyen gepen mindig rendelkezesre all minden adat, es nem kell tokolni a program telepitesevel, nameg persze a platformfuggetlenseg sem utolso.

@sztahanov:

hát lehet hogy nem ide tartozik de én megkérdem szóval hogy a blog.hu-nak van olyanja hogy mondjuk localhoston futtatot php-ből postolok a bloggjaimra? api vagy hogy híjják olyan mint bloggeren

olyan van?

@raklap: az api kerdese sokszor felmerul, jo lenne, bar eleg szuk reteg hasznalna. azt mondanam, h fel van irva a kivansaglistankra, csak van sok mas kivansag is. fejleszto meg keves. hacsak nem jelentkeztek.

@prometheus_X: "Ezzel csak azért nem tudok egyetérteni, mert a házi sufnituning rendszerek pedig többnyire alulmaradnak az olyan tipikus hibák kivédésében, mint az SQL inject, az XSS, vagy a Unicode támadhatóságok kezelése."

jogos, de elsosorban komolyabb egyedi rendszerekre gondoltam, amiket nem kiskovacspistikek olloznak ossze netrol, hanem megfelelo tudas van mogottuk.

az elterjedtebb rendszereket feltorni jobban megterulo melo, hiszen ha valahova megvan a kiskapu, akkor rogton kismillio helyre is.
erre mondjuk jo pelda, (bar nem konkretan webfejlesztes) hogy amig a firefox kevesbe ismert bongeszo volt, nem igazan voltak ra tamado kodok, szemben az explorerrel.
aztan ahogy egyre nagyobb lett a piaca, megjelentek a konkretan firefox sebezhetosegire epito huncutsagok is.

de tenyleg van igazsag abban amit irtal, a nyilt forraskodu rendszerek kore epulo kozossegek erteket nem szabad lebecsulni, mindenesetre wordpresst, joomlat stb tamado "virusok" nehany havonta jelennek meg, ezen nincs mit szepiteni :)

"Symfony nekem jóval rugalmasabbnak tűnik"
nem veletlen, hogy ennyire kezd elterjedni.

"Csapatban pedig úgy is azt kell majd használnia, amit a csapat vagy a góré kiválaszt - lett légyen az akármekkora fostalicska is (vagy épp jó, mindegy)."
bizony, foleg magyar viszonylatban nagy mak kell, hogy olyan melot talalj, ahol nem valami szedettvedett "elozo programozonk lelepett" cmst kell foltozgatni :P

@Lzolcsi: Igen, ilyen típusú alkalmazások fejlesztéséhez talán a legszerencsésebb választás. Bár megjegyzem: bármilyen CMS admin felületének megoldásához sem utolsó, míg az ExtCore a frontend részeken lassan kezdi felvenni a versenyt a jQuery-vel (persze, hogy beelőzze, az még nem mostanában lesz). Ahol backend-en ExtJS-t használok, ott frontend-en ExtCore-t, mert a kódok a "két" keretrendszer közt így viszonylag könnyen hordozhatóak, és nem kell 2-3 JS FW idiótaságait fejben tartanom.

@eztskubizd: "jogos, de elsosorban komolyabb egyedi rendszerekre gondoltam, amiket nem kiskovacspistikek olloznak ossze netrol, hanem megfelelo tudas van mogottuk."

Ez nem tűnt ki az írásból, amire reagáltam - de előfordul, hogy figyelmetlen vagyok :)

"az elterjedtebb rendszereket feltorni jobban megterulo melo, hiszen ha valahova megvan a kiskapu, akkor rogton kismillio helyre is."

Feltéve, hogy mind a kismillió egyezik még patch-level számra is, nem hogy minor verzióra. Erre viszont nem olyan nagyon nagy az esély, bár a fene tudja.

"erre mondjuk jo pelda, (bar nem konkretan webfejlesztes) hogy amig a firefox kevesbe ismert bongeszo volt, nem igazan voltak ra tamado kodok, szemben az explorerrel.
aztan ahogy egyre nagyobb lett a piaca, megjelentek a konkretan firefox sebezhetosegire epito huncutsagok is."

Itt most gyakorlatilag önellentmondásba keveredtél, hiszen az IE kódja mindig is zárt volt, ellenben az FF-é mindig is nyílt. Mégsem ez, hanem a piaci terjedés határozta meg, hogy célponttá vált az FF is.

"mindenesetre wordpresst, joomlat stb tamado "virusok" nehany havonta jelennek meg, ezen nincs mit szepiteni :)"

Azon nem is csodálkozom. Mindkettő egy rakás ...

""Symfony nekem jóval rugalmasabbnak tűnik"
nem veletlen, hogy ennyire kezd elterjedni."
Itt épp arról írtam, hogy megtorpant a terjedése, mivel egyre jelentősebb kritika éri, főként az ORM-je, meg úgy általában az egész felépítése, a hatékonysága, és a YAML-lal való állandó szívások miatt. Emellett nem árt megjegyezni: a PHP-ből sosem lesz RoR, akkor se, ha a Symfony-fejlesztők akarják.

"bizony, foleg magyar viszonylatban nagy mak kell, hogy olyan melot talalj, ahol nem valami szedettvedett "elozo programozonk lelepett" cmst kell foltozgatni :P"
Ez nem csak magyar viszonylatra igaz. Dolgoztam már ámeriái, meg szlovenszká kóddal is, illetve láttam dojcsét is, semmivel sem volt trágyább mint a magyar tákolmányok. A tákolás és a spagettikód nem magyar sajátosság, hanem rengeteg emberi hiba, hibás döntések sorozatának a végeredménye. Egyik munkahelyem 2k USD-ért vásárolt streaming CMS-t dobozos termékként, gyakorlatilag 0 komment volt a kódban, dokumentáció semmi, átláthatóság semmi, ellenben az összes elképzelhető biztonsági hibát felleltük benne alig pár óra leforgása alatt. És ezt a motort net-szerte használják fizetős oldalak is.

Ez csak egy példa volt. Nyíltkódú rendszer esetén ilyen nincs: megnézed a kódot, ha tetszik licenceled (ha szükséges), ha nem, akkor megnézel 50 másikat. Szerintem zseniális.

Nincs igazán értelme - és nem is az volt a célom - hogy OS vs. CS vitába torkolljon az egész: a pocsék forráskód nem sajátossága sem egyik, sem másik piaci szemléletnek, és mindkettőnek megvannak a maga vélt vagy valós előnyei és hátrányai. Példákat és ellenpéldákat mindkét oldal mellett és ellen a végtelenségig lehetne felhozni - értelmetlen flame lesz a vége, ezt mindannyian tudjuk.

@prometheus_X:
"Ez csak egy példa volt. Nyíltkódú rendszer esetén ilyen nincs: megnézed a kódot, ha tetszik licenceled (ha szükséges), ha nem, akkor megnézel 50 másikat. Szerintem zseniális."

Zéró keretrendszer ismerettel kell hozzá 2-3-4 hónap is mire úgy felszívod magad, hogy képes leszel összehasonlítani a specifikációs igényekkel a rendszer képességeit. Nem beszélve arról, hogy az üzleti oldalnak általában nem szent a speckó, az elég gyakran változik. Nem véletlen, hogy egy nagyobb fejlesztés esetén nem vág bele egy kisebb csapat (kis büzsdével) egy barnamezős beruházásba (azaz már ismert keretrendszerre építve), mert az még eladható a menedzsmentnek, hogy a cucc kicsit drágább lesz, meg tovább is fog tartani az elkészítése, de garantáltan elkészül VS. hamar nekivágunk, olcsóbb lesz, de fogalmunk sincs mikor futunk bele a keretrendszernél vmi szűk keresztmetszetbe, aminél a megoldásban max. a Firefox meg a Google lehet a segítség.