ugrás a tartalomhoz

A tervezés szerepe a webfejlesztésben

foxmulder · 2007. Okt. 6. (Szo), 22.53
Sziasztok!

Kezdő vagyok (oly régóta már :), ezért nézzétek el, ha lámaságokat (ráadásul sokat) beszélek.
Kitaláltam magamnak egy elég összetettnek tűnő webportált (CakePHP-t használok hozzá), gondoltam egy teljes projekt építéséből lehet a legtöbbet tanulni. Jelenleg 57 adatbázis táblánál tartok, talán ez az adat elég jól jelzi az alkalmazás bonyolultágát. Persze sokan a tapasztaltabbak közül most azt mondják: "Ez semmiség, rutinmunka..", de én már kezdem elveszíteni a fonalat és a kérdésem éppen ezzel a "fonallal" kapcsolatos. Nem tudom, más hogy van vele, de a neten fellelhető tutorialok rövid példái, vagy egy 5-10 táblát használó alkalmazás még vígan átlátható a számomra, ezen tapasztalatok nyomán felbátorodva és nagyobb tervek megvalósításába belevágva azonban egyszerűen elveszítem a kontrollt.

Szóval hogyan lehet egy nagyobb (felhasználókezelés, cikkek szerkesztése (mint a Wikipédiában), többnyelvű felület és tartalom (a nyelvek száma nem kötött), stb..) alkalmazást átláthatóvá tenni, egyáltalán szokás-e valamilyen tervezési módszert alkalmazni összetettebb weboldalak készítése közben? A CakePHP manual például nagyjából azzal indít, hogy "készítsük el az adatbázist, aztán majd megy minden mint a karikacsapás..". Az én esetemben már ez az első lépés is több hónapja tart és gyakran egy röpke új ötlet miatt újra kell tervezni az egészet. Fizetős munka esetén ez biztosan megengedhetetlen, úgyhogy felmerül a tervezés (és a tervhez való ragaszkodás?) szükségessége, de webes fejlesztésekkel kapcsolatban ilyesmiről nemigen olvastam még (az adatbázistervezés fontosságáról persze már igen).

Talán jobb, ha pontokba szedem a kérdéseket:

- Használnak-e a webfejlesztésben (az ER modell mellett) UML-t, vagy hasonló tervezési metódust?
- A gyakorlatban is, vagy csak elméletben?
- Mikortól válik egy projekt "többemberessé"?
- Hogyan tehető egy projekt bővíthetővé, folyamatosan fejlesztehtővé?

Remélem nem kérdezek botorságokat, köszönöm a válaszokat.
 
1

Igen

janoszen · 2007. Okt. 7. (V), 07.35
Használnak-e a webfejlesztésben (az ER modell mellett) UML-t, vagy hasonló tervezési metódust?

Igen. Mi például használunk.

A gyakorlatban is, vagy csak elméletben?

Teljes mértékben gyakorlatban, az adatbázis tábláihou egy sor SQL-t nem írunk kézzel, mindig UML-ből generáljuk illetve az osztályaink vázát is UML-ből állítjuk elő.

Mikortól válik egy projekt "többemberessé"?

A nagyságától. Egy ember lehet kvázi-többemberes, amikor nekiül a dizájner, utána nekiül a szájtbilder, stb. és lehet ténylegesen több emberes, amikor több fejlesztő dolgozik ugyanazon a programon egyszerre.

Hogyan tehető egy projekt bővíthetővé, folyamatosan fejlesztehtővé?


Ez egy összetett kérdés, mert több féle képpen is lehet érteni. Ha arra gondolsz, hogy hogy tud több ember együtt dolgozni, arra viszonylag egyszerű a megoldás, valamilyen verziókövetést kell használ, be kell vezetni kódolási szabványokat, kötelező eljárásokat (pl nightly build, stable tag, stb) és azokat ellenőrizni kell.

Ha magára a programkódra gondolsz, az egy bonyolultabb feladat. Meg kell csinálni a megfelelő absztrakciós mechanizmusokat, szét kell választani minél jobban az alkalmazáslogikát a megjelenéstől és magától a keretrendszertől (ez utóbbi dolog még nagyon sok helyen hiányzik, nagyon sok helyen közvetlenül a keretrendszer részét képezi az alkalmazáslogika).

Ez persze elég elméleti és van egy rossz hírem is. A tervezés tapasztalatom szerint legtöbbször nem a fejlesztésnél hibádzik mert elég könnyű felismerni a tervezési igényeket mert utána Te szívod meg ha nem terveztél. Ergo, két-három projekt és tudod mit akarsz. A sokkal rosszabb a dologban az, hogy valahogy a dizájnereket is rá kell venni arra hogy tartsák magukat a specifikációhoz vagy egyáltalán elolvassák. Mivel nem ők fogják utána megszívni ha nem jót alkottak, ezért nehéz őket rászorítani arra hogy figyeljenek.

Egyébként jó téma, jó kérdés. Köszi. :) (Légyszi kapcsold be az üzenetküldést vagy keress meg magánban.)
3

Kicsit rossz volt a kérdés

foxmulder · 2007. Okt. 7. (V), 22.15
Csak a könyvespolcomra kellett volna pillantanom. Barta Zoltán: Alkalmazásfejlesztés Perlben. Nagyon sok jó példa van benne, csakhát a Perlről azt gondoltam, nehezebb lesz megemészteni, mint a PHP-t, ezért hanyagoltam ezt a könyvet. A könyvből az mindenesetre kiderül, mindegy, hogy webalkalmazásról van szó, vagy másról, a módszer a tervezésben ugyanaz. Szóval a kérdés ott hibádzott, hogy a tervezés szerepét a webes fejlesztésekre szűkítette (annyiban viszont nem hülyeség, hogy valóban használják-e a tervezési módszereket a webfejlesztők). Viszont, ha a webnél maradunk, akkor visszakérdeznék arra, amit a keretrendszerekről írtál:
szét kell választani minél jobban az alkalmazáslogikát a megjelenéstől és magától a keretrendszertől (ez utóbbi dolog még nagyon sok helyen hiányzik, nagyon sok helyen közvetlenül a keretrendszer részét képezi az alkalmazáslogika)

Ezt kifejthetnéd bővebben? Én valami olyasmit értek ki belőle, hogy a keretrendszer határozza meg a tervet és nem fordítva és szerinted ez rossz. Ha a CakePHP-t nézzük, mint keretrendszert, akkor ugye abban az MVC minta érvényesül, amiről néha azt érzem, hogy teher, illetve túlzottan megköt. Persze az a valószínű, hogy egyszerűen nem ismerem eléggé a CakePHP-t. És el is jutottunk a másik kérdéshez. Feltételezve egy Igazán Profi Fejlesztőcsapat-ot (továbbiakban IProFecs), az ideális módszer az, hogy az IProFecs megismerve a feladatspecifikációt kiválasztja az ideális keretrendszert és programozási nyelvet, összegyűjti a megoldáshoz az elérhető kódkönyvtárakat, előkapja a szerszámosládából a megfelelő tervezési mintákat és "percek alatt" összeüti a kész alkalmazást, majd az egészet leönti az egyedi kinézet mázával. Mindehhez persze az szükséges, hogy az IProFecs folyamatosan képben legyen az elérhető eszközökkel kapcsolatban az adatbázisszerverektől a programozási és jelölő nyelveken keresztül a grafikán át a keretrendszerekig. Talán nem csak nekem tűnik úgy, hogy ez szinte lehetetlen. Marad tehát az, hogy az IProFecs kiválaszt magának EGY keretrendszert, EGY-KÉT adatbázisszervert stb., vagy bizonyos típusú feladatokra specializálódik, amihez esetleg saját keretrendszert készít. Egy-két emberes cégek számára az utóbbi tűnik járhatónak. Szóval érdemes egyáltalán keretrendszert használni? Vagy a feladattól függően újakat kell mindig megtanulni? Vagy ismerni kell az összeset? Vagy mindez együtt?

(Üzenetküldést bekapcsoltam (azt hiszem).)
5

Fejlesztés módszere

janoszen · 2007. Okt. 8. (H), 08.10
Tyűűű hallod, Te aztán tudsz izgalmas kérdéseket föltenni. :)

Egy jó ideje figyelem ezt a témakört, mivel nagyon érdekel. Ha elmész egy átlag webfejlesztőnek nevezett céghez, ott úgy működik, hogy a projekvezető (rosszabb esetben a főnök) leül az ügyféllel, megbeszélik hogy mit akar, grafikus leül, megcsinálja a tervet, elküldi az ügyfélnek, az rábólint, majd ki lesz adva a programozónak hogy csinálja meg. Na ez nem módszer, ez hülyeség, remélhetőleg nem kell kifejtenem, miért.

Egy kicsit jobb cégnél a programozó egyezteti le a funkcionális részét.

Egy igazán profi cégnél (webfejlesztés terén ilyenhez nem volt még szerencsém) a tervező megtervezi, specifikálja a működést és ez alapján kezd el mind a programozó mind a grafikus dolgozni. (MVC a munkamódszerben.)

-

Ami a szétválasztást illeti, azért hangsúlyoztam, hogy a keretrendszer elemeit is szét kell választani, mert ne tudd meg hányszor láttam már olyat, hogy php->smarty és döngött a mellkas hogy milyen jól szét van választva. Aztán amikor egy lekérdezést meg kellett kicsit változtatni, nekiült a tag és a keretrendszerbe belehegesztette a fícsört PHPban. Namost ez a kód újrahasznosítását kicsit odavágja.

A másik amit még gyűlölök, azok a behegesztett URI-k egy-egy modulhoz, amit nem lehet csak mindenféle hekkeléssel, aliasokkal, stb. kiküszöbölni.

Az ilyesmit konfigurálni kell tudni! Méghozzá sok keresgélés nélkül! Lehet hogy eleinte megköti a kezed de módosítási kéréseknél szidni fogod önmagad (vagy az elődöd) ha nem történik meg.
6

UML

bizi · 2007. Okt. 8. (H), 15.34
az adatbázis tábláihou egy sor SQL-t nem írunk kézzel, mindig UML-ből generáljuk illetve az osztályaink vázát is UML-ből állítjuk elő.

Milyen progival generáljátok az sql-t és a php-t (ha php-t használtok)?
bizi
7

EA

winston · 2007. Okt. 8. (H), 16.54
jópár uml tervezőprogram van (és még legalább ennyi grafikus sql tervező). Proclub az Enterpise Architect-et használja, ahogy jó magam is. az olcsóbb kategóriában ez a(z egyik) legjobb tervezőprogram, és még Eclipse plugginja is van kódszinkronizáláshoz (igaz, külön árulják, és csak windows alá... az EA-t magát linux alá is be lehet herkenteni egyszerűen). drágább kategóriában ott a Rational, de az már milliós tétel. ami webes méretekben kell, ahhoz tökéletes az EA, bár a kódgeneráló templatjait kicsit át kell irogatni, de ezt leszámítva remek dologk.
8

Köszi

bizi · 2007. Okt. 8. (H), 21.20
Köszi, a héten utánanézek ezeknek.
SQL tervezőket találtam én is, de a php lett volna fontosabb. Kb. 2 éve keresgéltem, de akkor nem találtam működőt vagy megfizethetőt.
bizi
9

Open source?

foxmulder · 2007. Okt. 9. (K), 21.29
Mi a véleményetek az Umbrelloról, vagy a Diaról?
10

Kicsik, kevesek

janoszen · 2007. Okt. 10. (Sze), 05.47
A DIA egy rajzolóprogram, ha jól nézem, nem UML eszköz. Az Umbrello aranyosnak néz ki, de túl kicsi az eszközkészlete. És nem tud PHP-t generálni. Sajnos ez az a kategória, amit nem úszol meg ingyen...
11

ArgoUML

zila · 2007. Okt. 10. (Sze), 09.00
Az ArgoUML nyílt forrású és ingyenes, php, java, csharp, c++ kódgenerálást tud...
Visual Paradigm szintén elég jó, a fizetős verziója tud php-t is generálni, van adatbázis tervező modulja, elég klassz cucc.
12

... :S

janoszen · 2007. Okt. 10. (Sze), 10.05
A Visual Paradigm-ot próbáltuk, de nem jött be, nem tudtunk olyan szinten dolgozni vele mint szerettük volna. Az ArgoUML meg... UML 1.4? Szinte minden eszköz 2-es UML-t támogat.

Használta valaki ezeket gyakorlatban (nem csak adatbázis tervezésre, hanem pl szekvencia diagrammra, követelmény-elemzésre, stb.)? Elég sokáig kerestünk megfelelő eszközt de a bonyolultabb funkciók terén pangás van...
13

Umbrello és Dia

foxmulder · 2007. Okt. 10. (Sze), 19.13
Az Umbrello is tud PHP-t generálni (több más nyelv mellett), bár még nem nyaggattam elég tüzetesen. A Dia is rendelkezik egy UML rajzoló elemkészlettel, bár kódot nem tud generálni, viszont az autodia nevű Perl program képes a Dia által értelmezhető diagramokat rajzolni forráskód alapján. Utóbbit PHP-val teszteltem (szintén csak a legegyszerűbb osztályjal). A Gaphor (amely szintén nem túl fejlett kódgenerálás terén - csak Pythont tud, de azt oda-vissza) viszont kezeli az UML 2.0-t.

Egyébként van jelentősége az UML verziónak? Azt olvastam valahol, hogy az UML eszközkészletének 20 %-ával modellezhető a valós helyzetek 80 %-a. Persze, ha céges előírások vannak az UML verzióval kapcsolatban, akkor biztos van, de a webszerkesztő társadalom "félvad" szegmesében mi a gyakorlat? Mert például Proclub a magasabb szintű funkciókat hiányolja az ingyenes eszközökkel kapcsolatban, ugyanakkor úgy tűnik, ezzel a kívánsággal kisebbségben van, mintha a webfejlesztők többsége nem is használna UML-t (vagy más tervezési módszert). Rosszul látom?
14

uml használat

winston · 2007. Okt. 10. (Sze), 20.23
a webfejlesztő "társadalom" nagyon színes képet mutat, a programozás (szigorúan véve fejlesztőt értek, nem sitebuildert és/vagy grafikust, hanem pl. php programozót) azon szegmense, ahol talán a legváltozatosabb fajtájú fejlesztők találhatóak, az egyszerű pistikétől a sokéves tapasztalattal rendelkező profiig. ez az egyik 'változó', a másik pedig, hogy a webes projekteknek szintén elég sok vállfaja van: a kis éppencsak dinamikus oldaltól a drupal testreszabáson át a tényleg nagy framework-ökig, vagy nagyterheltségű siteokig (flickr, amazon, miegyéb...). az uml alapvetően tervező "eszköz" (egy eszköz a fejlesztő kezében), aminek mind a két fenti dologgal szemben vannak bizonyos kritériumai: a fejlesztőtől megkívánja a kellő ismereteket, a projekttől pedig a kellő bonyolultsági fokot (hogy érdemes legyen használni).
ezzel asszem eléggé leszűkítettük a gyakorlati uml-használatot (olyanokat figyelembe se véve, hogy például egy valós és nem ideális fejlesztés esetén általában rohanás van, általában "nincs idő" uml-ezésre. persze ha az ember szakít rá, az általában később megtérül, de ez az idealizált eset), így valóban: tapasztalataim szerint webes projektek esetén elég kevés esetben használják az uml-t.
15

Doksi

janoszen · 2007. Okt. 10. (Sze), 20.28
Ezek gyenge eszközök ahhoz képest, amihez vagyok szokva. Nyilván, ingyenesen nem csoda. Amit én szeretek, hogy megtervezem a felhasználói követelményektől kezdve, doksit és kódot generálok, akár nyomtatásra... kényelem. Mivel az emberi erőforrás drága ezért a kényelem sokat számít.

Sajnos a tervezési módszerek tekintetében a webfejlesztés eléggé "barbár" környék, még aki adatbázis tervezésre UML-t használ is, máshol meg dolgokat gyógyít össze amik nem összevalók.

Sajnos mivel a web nagyobbrészt a dizájnerek oldaláról kap ügyfeleket, a fejlesztési rész háttérben zajlik és mivel elég egyedi, a szoftvertervezési sémákat nem lehet ráhúzni és nincs kialakult módszertan. Ez most kezd (talán) kialakulni, de nagyon nehéz keresztül vinni, hogy legalább az alapvető dolgokat tartsák be (főleg a grafikus részlegen).

Amit talán a módszeresség hiányánál is jobban utálok a web terén az az állandó futószalag munka. A "hackerek" filozófiája szerint egy feladatot egyszer kelljen elvégezni. Ahhoz képest minen nap azonos problémák előtt állunk és magára a fejlődésre "nincs idő".
16

programtervezési minták

winston · 2007. Okt. 10. (Sze), 20.36
a szoftvertervezési sémákat nem lehet ráhúzni


szerintem ez így, ilyen formában nem teljesen igaz. várható, hogy egy kisebb oldalnál valóban nincs rá szükség, de egy nagy bonyolultságú oldalnál, neadjisten egy keretrendszernél vagy cms-nél igenis az alap (GoF féle) programozási minták jelentős része használható (persze nem kell belezsúfolni, csak hogy ott legyen, olyat is láttam már). abban viszont teljességgel egyetértek, hogy nem szokás használni, nincs még elterjedve és hogy kialakulóban van. ami viszont olyan szempontból jó, hogy nem gyöpösödött be a szakma, és vannak külön dierkt webre, vagy hasonló környezetre vonatkozó minták is (hellyel-közzel idevágóan: lásd sun féle J2EE minták), nem csak a régieket használják.
17

Minták...

janoszen · 2007. Okt. 10. (Sze), 20.45
Azért nem érzem úgy, hogy a tervezési mintákat lehetne használni, mert a HTTP közismerten állapot nélküli, egy-egy lekérés megy, nem lehet szigorúan megtervezni a felhasználói interakciókat. Ezért érzem úgy, hogy nem lehet az UML-t és a tervezési módszereket szigorúan átültetni.

A sarkallatos pont: Ami az ügyféligényeket illeti, elsősorban (a hagyományos programokkal ellentétben nem a funkcionalitás felől közelítik meg a dolgot, hanem a reprezentatív oldalról, tehát jobban hasonlít a követelmény egy reklámra mint egy szoftverre.
18

minták létjogosultsága

winston · 2007. Okt. 10. (Sze), 21.05
igen, az ügyfelek általában nem látják a weblap mögötti programozás mértékét, de ezért Ők nem is vonhatóak felelőségre.
néhány minta, amik szerintem használhatóak: mvc (ez ugye most már alap :)), abstract factory, builder, factory method, singleton, adapter, bridge, decorator, facade, lightweight, strategy, esetleg commant és iterator. most így hirtelen ezek jutottak eszembe, bár láttam már felelőségláncot is, igaz az erős túlzás volt, de kissé sántítva rá lehetett húzni. és ezzel az alap minták jó részét felsoroltam. persze az is hozzátartozik, hogy mint minden absztrakció, ezek is lassíthatnak, ami egy másodpercenként több száz-ezer kérést kiszolgáló oldalnál gondot okozhat (persze lehet cachelni), mindenesetre szerintem igenis van létjogosultságuk webes téren is.
(a j2ee minták kapcsán meg érdemes itt nézelődni: ( http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html és http://www.corej2eepatterns.com/Patterns2ndEd/index.htm ) van néhány ötlet
19

Optimista vagy. :)

janoszen · 2007. Okt. 10. (Sze), 21.08
Optimista vagy ha azt gondolod hogy az MVC webes téren alap. Talán az MV de a C még erős hiányosságokkal küzd.
20

mvc

winston · 2007. Okt. 10. (Sze), 21.11
elnézést, a fogalmazás tényleg nem szavatos. itt az irányvonalakra gondoltam, hogy mi az, ami mostanában jobb körökben és fejlesztésekben dívik. lásd ruby on rails, és egyéb új keretrendszerek.
29

iterator

inf3rno · 2007. Okt. 18. (Cs), 18.45
Én ugyan még csak tanulgatom a mintákat, de az iteratort pl nagyon sokszor használom :-)
Javascriptben meg mondjuk objectekből xml vagy querystring meg ilyesmikhez visitort(vagy ahhoz hasonlót) is szoktam.
21

Tanulságos :)

foxmulder · 2007. Okt. 10. (Sze), 21.18
Tök érdekes amiket írtok (remélem nem csak nekem)!

Lehet, hogy hülyeség amit írok, de talán az AJAX lehet egy olyasféle megoldás, ami elmozdítaná a webet az "állapotosság" (nem tudom, hogy fogalmazzam meg, az állapot nélküliség ellentéte) irányába. Ha a hangsúly a kliens irányába tolódik el, és a szerver oldali szkriptnyelvre "csupán" az adatbázis felé irányuló kapcsolat megteremtése marad (így valósítva meg a javascriptből hiányzó, az adatok perzisztenssé tételének képességét), akkor talán kiterjedtebben lehetne alkalmazni az asztali alkalmazásoknál bevált tervezési mintákat. Tömörebben fogalmazva a javascript nyelven írt alkalmazás a böngészőben fut, az adattárolást pedig (és csak azt) a távoli adatbázis végzi, hasonlóan egy asztali alkalmazáshoz, mely a helyi merevlemezt használja például adatok fájlba írására. Ekkor az egész alkalmazáslogika egy helyen van, a szerver csak adatot tárol (és megoszt).

UI.: Oppá elkéstem..
22

Sarokpontok

janoszen · 2007. Okt. 10. (Sze), 21.25
Az AJAX valóban nagyon szép és jó és valószínűleg én lennék a legboldogabb ha csak AJAX-szal meg lehetne oldani a problémát, de több sarkallatos pontja is van a dolognak:

  • SEO. A keresőgépek nem tudnak mit kezdeni az AJAX-szal.
  • Hozzáférhetőség (Vakok, robotok, stb).
  • Perzisztencia (az oldalaknak nincs klasszikus URL-je)


Jól látod, hogy ez lehetne egy fajta view az MVC-ben, de csak alkalmazásoknál. Oldalak kiszolgálásánál nem, mert gátolja az indexelést. Mivel a weboldalak többsége (mint a weblabor is) nem steril oldal vagy steril alkalmazás, valahogy megpróbáljuk mindig belőni a középmezőnyt. Ha a kompatibilitás a cél, akkor diszkrét JavaScriptet kell használni, ami általánosan szintén megoldatlan probléma.

Meg aztán ott van ugye a biztonság kérdése is...

Mint látod, van itt mit fejleszteni, csak lenne rá ideje az embernek. Az biztos, hogy aki megoldja ezt a problémát (amire az AJAX csak egy kerülő válasz) és el is tudja adni, az sikeres ember lesz. :)
23

Biztonság

Joó Ádám · 2007. Okt. 10. (Sze), 22.43
Mivel a Javascript forrásához bárki hozzáférhet, így vannak dolgok, amiket nem lehet kliensoldalon megoldani.
24

js

winston · 2007. Okt. 11. (Cs), 06.47
a js egy nagyon jó dolog, de mint előttem írták, megvannak a maga hibái. rengeteg minden megvalósítható vele, de teljességgel ez se tudja áthidalni a http azon tulajdonságát, hogy nem folyamatos a kapcsolat. illetve bizonyos mértékig igen, de csak a megfelelő korlátok mellett (indexelés, js nélküli böngészők... az url-ekre láttam megoldást, bár nem próbáltam még ki). a web egy elég különleges fejlesztési platform, a maga szabályaival és szeszélyeivel, és bizony korlátaival, amiket nagyrészt nem tudunk áthidalni.
30

php

inf3rno · 2007. Okt. 18. (Cs), 18.54
Ahogy láttam, nem csak az AJAXal van a gond, hanem a PHPvel is, bár ez utóbbiban kevesebb a tapasztalatom. Én speciel egy comet változatot szeretnék csinálni éppen, ami egy adatbázisból olvas ki híreket(amiisket egy rss reader gyűjt össze) na most ott akadtam el, hogy nem tudom semmilyen értelmes módon késleltetni a választ addig, amíg frissül az adatbázis. Annyi kéne, hogy az adatbázis frissítő, és a lekérő php ugyanazt a memória részt tudja figyelni. A másik probléma meg mondjuk a szétválasztásnál lenne, mert úgy meg már nem is egy gépen futna a két funkció.
31

comet

winston · 2007. Okt. 19. (P), 07.30
hú. kora reggel van, kávé miegyéb. azért igyekszek valami épkézlábat. comet. volt róla egy egész jó előadás a webkonfon, most valahogy az ugrott be. tehát. ha szerveroldalról akarod kezdeményezni a frissítést, akkor folyamatosan fenn kell tartanod egy http requestet a böngészőből. (az egy idő után bezárul, miegyéb, így adott időnként le kell lőni és újraindítani, ez js) aztán ezen keresztül a szerver küldözgeti a változásokat. Memóriacím nem kell, ha arra gondolsz amire én, igaz a comettel nem nagyon foglalkoztam még, de szerintem a fenti módszerrel megvalósítható. a szétválasztásos részt nem igazán értem, hogy mi futna két két helyről? (db és php?)
32

Terhelés...

janoszen · 2007. Okt. 19. (P), 08.02
Ez ugye pontosan az oka annak, amiért egy Flashchat vagy hasonló applikációk meg tudnak enni egy szervert önmagukban. Állandóan rugdossák a szervert.
33

gmail?

winston · 2007. Okt. 19. (P), 08.16
amennyire emlékszek, erről is szó esett, és ki volt valami rá találva. a gmail is comet-en alapul (igaz, nem a hagyományoson, hanem egy iframe alapú), és gondolom ugye sok erőforrás van mögötte, de mégis, mivel rengetegen használják, szerintem elég hatékony lehet az erőforrás kihasználtság (lévén ha nem lenne, akkor a googlenak nem érné meg akkora szerverparkot fenntartania a szolgáltatásra) gondolom én
34

Optimalizálás

janoszen · 2007. Okt. 19. (P), 08.41
A Google-nak nagyon nagy tapasztalata van az optimalizálásban, főleg a terheléselosztásban. Ne bízz benne, hogy egy mezei egygépes szerveren meg tudod ugyanazt csinálni, mint amit a Google egy cache-orientált szerverparkon.
35

de azért meglehet

winston · 2007. Okt. 19. (P), 09.01
abban azért nem bízok. a google mögött rengeteg szakértelem és erőforrás áll. de azért nem veszett fejsze nyele, ha meg lehet csinálni
37

én próbálkozom

inf3rno · 2007. Okt. 19. (P), 11.13
hát amíg nem próbáljuk ki, hogy mit lehet és mit nem, addig úgysem tudjuk meg, azért én próbálkozom a dooggal, aztán majd meglátom mennyit eszik a kicsike
36

aham

inf3rno · 2007. Okt. 19. (P), 11.10
jaja db és php külön helyről futna, meg persze a db frissítése és a lekérés is külön helyről. a lekérésnek meg kell egy timestamp, hogy legutóbb mikor frissült a db, mert az alapján tudja, hogy van e friss adat az adatbázisban, és kell e db queryt küldenie, vagy sem. olvastam azt a cometes cikket, csak az ottani megoldás a friss info lekérésére nem nyerő. ha jól emlékszem állandóan lekéri az adatbázisból az adatot, és ha kap valamit, akkor kirajzolja, na most ez nagyon leterheli az adatbázist, ezért szeretném kicsit ésszerűbben megoldani az adatkérés kérdését.
38

hogyan máshogy?

amonrpg · 2007. Okt. 19. (P), 12.49
Ha nem kérdezed le állandóan az adatbázist, akkor hogyan is értesül róla az alkalmazásod, hogy új adatot kell kitolni a már nyitott csatornán? Nem igazán értem. A Comet éppen, hogy a HTTP csatorna nyitottságát jelenti. Ettől még a DB-t le kell kérdezned, másképpen nem tudod meg, hogy jött-e új adat. Hacsak nem ugyanaz a kódrész foglalkozik a db frissítéssel és a kiszolgálással is, de ez valószínűtlen, és nem éppen szép megoldás.
39

szerintem

inf3rno · 2007. Okt. 19. (P), 13.02
Nyilván nem ugyanaz a kódrész foglalkozik vele, viszont a két kód között kell valami kapcsolatot létrehozni az adatbázis felett, mert különben állandóan az adatbázist kell kérdezgetni, hogy frissült e, ami meg nem tesz túl jót az oldalnak párszáz látogató felett. Ha egy gépen van a kettő, akkor lehet egy közös memóriarészbe írni timestampet, vagy mondjuk a legfrissebb bejegyzés idjét, ha külön gépen fut a két progi, akkor viszont nem tudom, hogy ezt a kapcsolatot hogyan lehet megoldani a db server terhelése nélkül :-/ Ezzel a több gépes témával mondjuk elméletben foglalkozom csak egyelőre.
40

memória

winston · 2007. Okt. 19. (P), 13.27
ha jól értem mire gondolsz... akkor nem fog menni. nem fogod tudni mysql-ből és php-ből sem a kijelölt memóriacímet írni. tudtommal.

update: oké, unix alapú rendszerekkel hívhatsz valami shellfilet, de ezzel is csak php-ből van megoldva a dolog
41

hmm

inf3rno · 2007. Okt. 19. (P), 18.56
Hát ez rossz hír. Azt hittem php kicsit többre képes.
42

ne dőlj be ;)

Hodicska Gergely · 2007. Okt. 19. (P), 20.47
Hát ez rossz hír. Azt hittem php kicsit többre képes.
Nem biztos, hogy minden, egy fórumban elhangzó hozzászólást kézpénznek kell venned. Ráadásul nem hiszem, hogy épp a PHP lenne ebben a párosban a szűk keresztmetszet.

Ha nagyon akarod, akkor bármikor megteheted, hogy írsz egy MySQL függvényt, amivel tudsz shared memory-t kezelni, ez valaszeg nem túl bonyolult, de konkrét tapasztalatom nincs e téren (bár egyszer már írtam egy MySQL függvényt). Ezt utána PHP-ból tudod kezelni. Szintén tudsz mondjuk ugyanígy Memcache-be írni, annak elég egyszerű protokolja van. És ha valaki otthon van jobban rendszer programozásban, szerintem még biztosan lehetnek egyéb megoldások is.

Pl. olyat is el tudok képzelni, hogy MySQL Proxyn megy keresztül a query, és az kezeli le transzparensen a cache kezelését.

Megteheted azt is, hogy fut egy deamon szerűséged, ami figyeli a DB-t folyamatsan, és ő írja mondjuk Memcache-be a szükséges adatokat, és az oldalt kiszolgáló PHP-k ezt rángatják.

Ezenkívül nem vagyok benne biztos, hogy feltétlenül leromlik a DB teljesítménye több felhasználónál is, valószínűleg a Query Cache ebben az esetben jó szolgálatot tehet. Bár még ha onnan is jön az adat, biztosan többe kerül kiszolgálni, mintha Memcache-ből jönne.


Üdv,
Felhő
43

Huh

inf3rno · 2007. Okt. 19. (P), 22.14
Előszöris köszi a tanácsokat. :-)
Ez most így egyszerre kicsit sok volt, de ígérem mindegyik megoldásnak utánajárok előbb, vagy utóbb. Még van mit tanulnom programozás terén, és fogok is :-) Php terén meg főleg van mit :-) Most éppen infokat gyűjtök, hogy milyen technológiákat lehet használni, és melyeket érdemes is, és azt hiszem ez a sokminden, amit leírtál elég hasznos lesz nekem, szal kösz mégegyszer.

Üdv. Jánszky László
47

Umbrello

virág · 2008. Ápr. 10. (Cs), 14.07
Szia én használom az Umbrello-t, de annyira butácska szegény, hogy csak nagy körültekintés mellett tudom ajánlani. Szinte semmilyen ellenőrzés nincs benne, teljesen megbízik abban amit te összeraksz és nem a legfényesebb a logikája sem. Ami még a hibája az-az, hogy bár nagyon sok nyelvet támogat (PHP-t is), de egy nyelven belül a konkrét beállítási lehetőségei nagyon szűkösek. Azért lehet használni, de odafigyelve!
2

Modszertan

zmb · 2007. Okt. 7. (V), 08.45
Termeszetesen nincs olyan altalanos recept a szoftver tervezesre/szoftver fejlesztesre, mint a husleves keszitesehez. Pontosabban egy megfeleloen magas abszrakcios szinten minden fejlesztes ugyanugy nez ki, de ez olyan magas, hogy nem nagyon hasznosithato.

Ha valamifele modszertant keresel, akkor szemely szerint ajanlanam az XP-t. A tapasztalat azt mutatja, hogy a mindennapi munka soran rengeteg elvet hasznalnak fel a fejlesztok az XP-bol. Nem azert, mert XP-t hasznalnak, hanem a gyakorlatiassag kivanja. A modszertan nem azt mondja meg, hogy milyen lepeseket tegy, hogy egy tokeletes adatmodelled legyen (ez nem egy matematikai egyenlet), hanem azt, hogy a projekt ne Brown-mozgas legyen, hanem valami olyan ize, amirol latszik, hogy honnan hova jut.
4

Módszertan?

foxmulder · 2007. Okt. 7. (V), 22.38
Nem tudom, hogy módszertant keresek-e. Itt egy riport Scott W. Amblerrel, az Agilis modellezési módszertan alkotójával, aki a cikkben a negyedik kérdésre ("Milyen követelményeket támaszt az agilitás a fejlesztőkkel szemben?") ezt válaszolja:

Szerintem fontos a nyitottság és az alapvető informatikai tudás is. Tudni kell például szoftvert fejleszteni...

Ha a módszertan nem ad választ arra a kérdésre, hogy hogyan kell szoftvert fejleszteni (mert feltételezi, hogy ez a tudás már megvan), akkor nem módszertant keresek, hanem választ erre a kérdésre, mármint arra, hogy hogyan kell szoftvert fejleszteni. A tapasztalat viszont azt mutatja, hogy előbb-utóbb beleütközünk a tervezés szükségességébe. Valószínű, hogy az átlagos megrendelő nem fog olyan feladatot kitűzni, ami ne lenne megoldható a már meglévő keretrendszerekkel (vagyis a munka nagy része rutinmunkának tűnik), de a karbantarthatóság és fejleszthetőség miatt mégis szükséges lehet átlátni a dolgokat. Hogyan zajlik ez a gyakorlatban? Egy csapat egy keretrendszert használ (akár a sajátját), vagy folyton újakat tanul (ha igen, akkor ezt az adott feladat függvényében teszi, vagy a konkrét feladatoktól függetlenül igyekszik minden vonalon naprakész lenni)?
25

UML vagy keretrendszer?

foxmulder · 2007. Okt. 17. (Sze), 20.10
Félig már ismerem a CakePHP-t. A tervezés szerepe ebben annyi, hogy egy megfelelő adatmodellt kell kreálni (javítsatok ki, ha tévedek), aztán szöszölni egy kicsit a modeleken, majd megírni a controllereket és nézeteket. Az UML azonban (úgy tűnik) ennél jóval többre képes (mármint jóval többre, mint egy ER modell). Vagyis a keretrendszer szerepe annyi, hogy levegye a vállamról a tervezés terhét (egy kész tervet nyújt, amibe bele kell "szuszakolnom" az alkalmazáslogikát)? Vagy előbb terveznem kéne és a terv ismeretében kiválasztani a megfelelő keretrendszert, jelesül azt, amelyik a terv megvalósítását a lehető leggyorsabbá teszi avagy ha nincs ilyen, egyedi alkalmazást írni, vagy ha az alkalmazás problematikája újrahasznosítható, akkor saját keretrendszert írni? Szóval melyik az előrevalóbb?
26

UML

janoszen · 2007. Okt. 17. (Sze), 20.34
Az UML sokkal sokkal többre képest mint egy adatmodell készítés. Egy adatmodellt végszükség esetén akár kézzel is meg lehet alkotni, sokkal bonyolultabb az osztályok egymástól függése, stb.

A keretrendszer egy olyan dolog... én világéletemben a magam útját jártam és nem bántam meg.
27

Hm...

foxmulder · 2007. Okt. 17. (Sze), 21.20
:)
28

Tervezés

Fraki · 2007. Okt. 18. (Cs), 00.30
A tervezés szerepe ebben annyi, hogy egy megfelelő adatmodellt kell kreálni (javítsatok ki, ha tévedek)


Tévedsz. Webes keretrendszerekről van szó ugyebár, azért ezt ne feledjük. A webnek meg van egy bizonyos kontextusa, egy többé-kevésbé kötött feladatrepertoárja, ergó egy platform. A webes keretrendszerek, mint a Cake, az ezzel a platformmal való ismétlődő munkáidat egyszerűsíti le (DRY), illetve emeli olyan absztrakt szintre, ahol ez minimalizálódik. Tehát azt a területet fedi le, amit le kell neki, valószínűleg jobban, mint ahogy te tennéd (a kollektív tudás miatt). Azaz nem a tervezés terhét veszi le; hanem annak egy bizonyos részét.

Az az érvelés, hogy egy webes keretrendszer túl korlátozó, éppen ezért általában nem helytálló, mert az rejlik mögötte, hogy az illető nem méri fel rendesen a szerepét és a mozgásterét egy ilyen keretrendszerrel való együttműködésben.

A keretrendszerben való gondolkodás egyébként azért is egészséges, mert ez a két aspektus – általános és specifikus, vagy másképp: platformspecifikus és projektspecifikus feladatok – elválasztódik a tervezésben és megvalósításban is.
44

Igaz, de...

foxmulder · 2007. Okt. 26. (P), 00.02
A válaszod középső bekezdésével teljesen egyetértek.

A keretrendszerek "korlátaival" kapcsolatos nyűglődéseim oka az AJAX környékén tűnik kikristályosodni. A keretrendszerek ugye szétválasztják az adatot (Model), a működést (Controller) és a megjelenítést (View). Utóbbi azonban az AJAX révén (mely adott esetben meglehetősen bonyolult is lehet) ismét felbontható, hiszen már nem pusztán megjelenés, formázás, hanem egyben működés is (közvetlenül eléri az adatot, a Modelt), vagyis úgy tűnik, mintha a működés (vezérlés) egy része "átfolyna" a kliensre és a tervező elbizonytalanodik. Mit tartson meg szerver oldalon a Controllerben és mit érdemes a kliensoldali Javascripre bízni? Vagy ez már ízlés dolga?
45

Controller marad

kicsy · 2007. Okt. 26. (P), 00.50
Szerintem semmiképp sem szabad a kliensnek közvetlenül elérnie a modellt, csak a controlleren keresztül. Így gyakorlatilag nem sok különbség van a klasszikus kérés és az AJAX-os kapcsolat között: jön a kérés, a controller kiszolgálja és visszadja az adatokkal (model) feltöltöt sablonrészt (view), valamilyen formában, valamelyik csatornán. Elméleti különbség nincs a két megoldás között.
46

ajax

Fraki · 2007. Okt. 29. (H), 08.26
Nem folyik át. Az ajax elsősorban view logika: ugyanolyan felületen – http kérések – kommunikál, mint a böngősző navigáláskor, csak a választ szkriptből dolgozod fel. Tkp. egyfajta user agent-nek is felfogható.

Ennélfogva a modellel a kliensoldal nem is tud kommunikálni. Ez az adminműveletek optikai csalódása lehet; de ha belegondolsz, minden adminművelet klasszikus navigációval is megoldható, csak kényelmetlenebbül; ezért jó az ajax, mert kényelmes.

Egy elegáns ajax-alkalmazás egy MVC-rendszerben olyan, hogy mind a modell, mind a controller kódja változatlan.

Egyébként az MVC rendszerek ha valamiben, az ajaxozásban aztán bika erősek, a helpereikkel főleg. (Van egy olyan érzésem, hogy nagy részben az ajax terjedésével nőtt meg rájuk a kereslet.)
48

json

inf3rno · 2008. Nov. 1. (Szo), 09.36
Hát igen, mert mondjuk ha azt szeretnéd, hogy az oldalad javascripttel és anélkül is menjen, akkor írsz Viewnek egy json sablont meg egy html sablont, egy kicsit bütykölsz a linken, és el van intézve.