- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Nekem csak az nem világos, hogy a diagram miért nem azt mutatja, amit a szöveg ír.
Lehet, hogy csak én látom rosszul?
- A hozzászóláshoz be kell jelentkezni
a szövegben is php+pythonról beszél, bad $title
No rainbow, no sugar
- A hozzászóláshoz be kell jelentkezni
Kiváncsi lennék hol szerepelne a diagrammon a Javascript fejlesztők iránti igény.
- A hozzászóláshoz be kell jelentkezni
Ott ahol a gwt? ;)
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
Ezt próbáld meg újra, úgy hogy értsem is mit szeretnél mondani. :)
- A hozzászóláshoz be kell jelentkezni
Vicc akart lenni. Lévén a gwt java nyelven írt kódból generál javascriptet.
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
Áháá azt akartad mondani, hogy nincs szükség js programozókra, mert a gwt megcsinálja java kódból? :)
- A hozzászóláshoz be kell jelentkezni
Hehe, már megint jókor váltottam :-) Most, hogy dömping lesz PHP-sekből, már nem csinálom. Eddig mindig sikerült 1-2 évvel megelőzni a trendeket, így mindig hiánypiac szerinti fizut tudtam kialkudni :-)
- A hozzászóláshoz be kell jelentkezni
És nem jobb Turdus v2.0-val játszani, mint bottal piszkálni messziről mindenféle szedet-vedett PHP kódot? :)
--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.
- A hozzászóláshoz be kell jelentkezni
Tehát 2005-ben alkalmaztak 2 python szakértőt és minden évben egyel többet, akkor az 350%-os növekedés, de vajon többen vannak-e mint a JAVA programozók? :)
- A hozzászóláshoz be kell jelentkezni
csak tudnam mi ez a beidegzodes egy csomo embernel hogy szegeny javat nagybetuvel irjak...
- A hozzászóláshoz be kell jelentkezni
Biztos sokat tőzsdéznek :D
- A hozzászóláshoz be kell jelentkezni
ebben a kontextusban viszont a "JAVA programozok"-at nem tudom ertelmezni. a reszvenyt programozzak? ;)
- A hozzászóláshoz be kell jelentkezni
Szerintem ez ugyanolyan rossz beidegződés lehet, mint a mondatokat kisbetűvel kezdeni, vagy például a bejegyzett márkaneveket nagy helyett kisbetűvel (Linux helyett linux) írni. Ez utóbbit a helyesírás-ellenőrző alá is húzza hibaként.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
meg jo, hogy ki lehet kapcsolni, akkor mar csak a fel gepet zabalja fel ez a bugos szar (firefox) az egesz helyett..
- A hozzászóláshoz be kell jelentkezni
Az egész HUP-ot egy 800MHz-en futó notebookon írom ezzel a bugos szarral (Firefox + helyesírás-ellenőrző), de nem látok vele semmi komolyabb problémát. Worksforme.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
mint ahogy az ubuntu is. tudjuk. :)
vegulis csak 125 mega memoriat zabal 4 tabbal.
- A hozzászóláshoz be kell jelentkezni
2 500 forint / GB memóriaár mellett tőlem 1 GB-ot is használhat. A böngésző a fő szoftver a gépemen. A jövedelmem nagy részét a böngészőnek köszönhetem, nélküle fél ember lennék. Megérdemli. A notebookomban 2GB RAM van. Mindenre elég. Még így is.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
ertem, tehat szerinted ha egy szoftver memleakel, akarmi, akkor toljunk ala egy kis memoriat, es kesz.
- A hozzászóláshoz be kell jelentkezni
Mutasd meg, hogy hol állítottam, hogy ha a szoftver memleakel és akkor alá kell tenni memóriát. Ha pedig nem állítottam, akkor ne adj a számba semmit a pipaálmaidból.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
nállam sinccsen bekabcsolva. simán tuddni kel heljesírni
- A hozzászóláshoz be kell jelentkezni
Igazából nem csodálkozom. Egyre több webalapú ügyviteli rendszer kerül forgalomba, melyek jó része ugye PHP fejlesztés. Értelem szerűen biztosan előfordul ezeken a helyeken más nyelv is, de szerveroldali programozásra ezek szerint ezen nyelvek hatékonyabbnak bizonyultak. Vagy csak a rövid fejlesztési idő a tényező.
- A hozzászóláshoz be kell jelentkezni
Volt szerencsém egy ilyen php-ban írt ügyviteli rendszer közelében dolgozni évekig. Sok dolgot nem értettem még. Nem értettem, hogy miért választják a java-t mikor a php olyan jó, könnyű cuki és aranyos. Miért probléma, hogy a saját hibaüzeneteit nem tudod elkapni catch ágban. Miért megy a nyafi az include pokol körül, mert "csak" oda kell figyelni és miért akarnak típusokat... satöbbi. Akkor és nem ismertem a java-t sem. Most, hogy ismerem a java nyelvet, a JEE koncepciókat, eszközöket úgy ahogy, azt mondom, hogy a php közelébe sem megyek többet. Php-s világban olyan problémák voltak, amik fel sem merülnek javas világban. Igen, a javas világban is vannak problémák, de ezek más minőségűek és tárgyúak, mint amott.
Maga a nyelv (php) könnyű és gyorsan tanulható. Ellenben ha valami nagyot, skálázhatót kell csinálni, akkor azt hogy? Mi van ha nagyon gyorsan növekszik a felhasználók száma? Van olyan eszköz php területen, mint a gwt java területen?
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
Én korábban elég sokat kódoltam PHP-ban, ebből éltem egy ideig, de szervernek elég sok mindenre Javat használtunk a cégnél. A JSP sem tetszett, SPRING meg főleg nem. Na mostanában JSF és hasonlókkal foglalkozok. (Hibernate persze a DB-hez.) Nem sírom vissza a PHP-t...
Üdv: Tamaas
- A hozzászóláshoz be kell jelentkezni
Csak csatlakozni tudok, sajnos a cégben viszont nem veszik jó néven a java-zást, mondván ha otthagyjuk a céget nem találnak majd embert aki megfizethető áron bele tud nyúlni a kódjainkba. Akkor már inkább felmondok, vagy megtanulok valami mást, csak phpül ne kelljen többet kódolni.
- A hozzászóláshoz be kell jelentkezni
Szerintem a jó PHP fejlesztő nem olcsóbb, mint a jó Java fejlesztő. Igaz php-sból könnyebb olcsót találni, csak ugye olcsó húsnak...
- A hozzászóláshoz be kell jelentkezni
"Egyre több webalapú ügyviteli rendszer kerül forgalomba"
De minek?...
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Hámmerszépésjó...!
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
Egy szóval sem írtam, hogy ez a követendő példa, csupán megállapítottam, hogy ma egy ilyen tendencia van növekedőben. Tény, hogy erre a célra vannak alkalmasabb eljárások, lehetőségek, de ha a piac ezt igényli, akkor lehet az ember frankó assembly-bitfaragó, a kutyának nem fog kelleni.
Aki pénzt akar keresni és tud php-ben programozni, kb. le fogja ejteni magasról, hogy milyen a php mögött álló hibahalmaz. Meg fogja írni, felveszi hó végén a fizetését, s elmegy a vidámparkba vattacukrot zabbantani. :)
- A hozzászóláshoz be kell jelentkezni
Statisztikákból mindent be lehet bizonyítani és azok ellenkezőjét is. :)
Mit értünk céges környezeten? Mert kis hazánkban is sokkal több PHP fejlesztéssel foglalkozó cég van, mint Java fejlesztéssel foglalkozó cég, természetes, hogy sokkal több PHP fejlesztőt keresnek, mint Java fejlesztőt. Azt hozzá kell tenni, hogy a PHP fejlesztők igen nagy része egyedi weboldalak programozásával foglalkozik, a maradék nagy része pedig meglévő PHP keretrendszerek módosításával. Lehet mondani, hogy a weboldal készítés "enterprise" tevékenység, de az "enterprise" környezet nem fórum vagy vendégkönyv fejlesztésről szól...
Vessünk egy pillantást a Netcraft grafikonra: http://news.netcraft.com/archives/2010/02/site_count_history.png
Mintha a php/python programozók számával együtt növekedne a weboldalak száma is. Fura egybeesés. :)
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
Én laikusként annyit látok most egy projekt kapcsán, hogy van két webshop, az egyik PHP, a másik Java alapú. Egy cég számára készül, enterprise felhasználásra. Mindkettőt egy-egy fejlesztőcég szállítja. Alapvető funkcionalitásokat látnak el. A kettő közt nagy különbségnek látom, hogy az egyik indulásához elegendő negyed akkora hardver, mint a másikéhoz. Az egyik x erőforrással bíró hardveren 3 másodperccel az elindítása után fut, a másik 4x erőforrással rendelkező hardveren 2-3-4-5-6 percig indul és utána sem egy speed king.
A mostani gazdasági légkörben nem mindegy, hogy milyen vas kell egy csöves webshop alá. Tehát az én meglátásom szerint (és az élet ezt alátámasztani látszik) van létjogosultsága a sokat szidott PHP-nak is akár vállalati környezetben.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
És ezen a HipHop is dobni fog még...
- A hozzászóláshoz be kell jelentkezni
A két két terméket nem ismerem, de a két technológiát ismerve azt tudom mondani, hogy a Java alapú tízszer akkora terheléssel se fog jelentősen több erőforrást igényelni, a PHP alapú pedig túl fogja nőni a rendelkezésre álló hardvert. Ezek után a PHP-t választó megrendelő fűhöz-fához fug futni, hogy miképpen tudná a karbantartási ablakot nullára csökkenteni, illetve több géppel kiszolgálni az igényeket, a Java-t választó megrendelő pedig esetleg kibővíti a cluster-t, ha szükséges. :)
Az Enterprise Java háttér három ok miatt fogyaszt több memóriát és indul lassan:
* Kiépíti a különböző pool-okat, felkészül a terhelésre
* Kiépíti a cache rétegeket, felkészül a terhelésre
* Előfordítja a JSP oldalakat
Így el lehet érni egy 4 magos géppel és 1G felhasznált memóriával percenként 80 ezer (>1000 tps) tranzakciót 200e (>2500 tps) adatbázis tranzakcióval (az adatbázis ennél combosabb gépen van). Mindezt elosztott tranzakcióval. Tegyél erre próbát PHP alapokon és az is 2-3-4-5 percig fog indulni aztán elér valami erőforrás limitet, mert nem erre tervezték... :)
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
_Franko_ frankón megmondta. Itt a pont. :D
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
kihagyva azt az igen valoszinu lehetoseget, hogy a terhelesi maximumot soha nem fogja elerni az ilyen rendszerek tobbsege:)
- A hozzászóláshoz be kell jelentkezni
"ogy a Java alapú tízszer akkora terheléssel se fog jelentősen több erőforrást igényelni, a PHP alapú pedig túl fogja nőni a rendelkezésre álló hardvert"
Tisztában vagyok azzal, hogy mindegyiknek van előnye és hátránya. Biztos vagyok benne, hogy az említett esetben sosem fogja túlnőni a hardvert a PHP. Éppen ezért mondtam, hogy meg van a maga helye. Mindent a maga helyére. Régóta hangoztatom és nem látom megdőlni ezt a nézetemet.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Soha nem lehet tudni, hogy mikor fogja túlnőni az igényeket, láttam már több esetben jól kiépített hardver parkot üresen járni és alábecsült forgalomtól összeomló rendszereket...
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
A nem fogja kinőni a vasat kijelentést nyilván úgy kell érteni, hogy az életciklusa alatt (vállaltoknál jellemzően 5 év). Utána úgyis vascsere.
Gondolom ezzel nem azt akarod mondani, hogy a PHP-nak úgy magában nincs létjogosultsága. Mert én azt állítom, hogy meg van a PHP-nek és a Java-nak is a maga helye. A mondandódból nekem az jön le, hogy te ezzel nem értesz egyet.
Nyilvánvalóan ~ 10 év folyamatos PHP-s weboldal üzemeltetés után nekem fogalmam sincs arról, hogy milyen terhelés alá körülbelül milyen vas kellhet és hova lehet alkalmas a PHP, de ebben az esetben más is egyetértett vele, hogy a Java ágyúval verébre.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nyilvánvalóan ~ 10 év folyamatos PHP-s weboldal üzemeltetés után nekem fogalmam sincs arról, hogy milyen terhelés alá körülbelül milyen vas kellhet és hova lehet alkalmas a PHP, de ebben az esetben más is egyetértett vele, hogy a Java ágyúval verébre.
Semmi ilyesmit nem mondok, azt említettem csupán, hogy az igények megnövekedhetnek és ezt a Java könnyedén támogatni tudja a PHP pedig nem, mert nehezen skálázható. A nem enterprise piacon a Java nincs elterjedve és nem is nagyon fog elterjedni. A példádban említett két termék közül a Java változat jó eséllyel az enterprise piacon is meg tud élni, a PHP pedig nem, mert nem képes olyan működésmódra és integrációra, amely szükséges egy enterprise környezetben.
A cikk állításaival ellentétben az enterprise piacra még nem sikerült betörnie PHP vagy Python alkalmazásoknak, ha valaki mégis ezt hiszi, akkor összekeveri a céges felhasználást az enterprise felhasználással: egy kávéfőző nem attól lesz ipari kivitel, hogy cégnél használja reggelente és ebéd után öt-tíz ember, hanem attól, hogy egy vendéglőben használják reggeltől estig folyamatosan éveken át.
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
Más szerint pedig nem attól enterprise valami, hogy vastagabb acélból van, hanem attól, hogy vállalaton belül, vállalati problémák megoldására használják.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Hm... ezt gondold át még egyszer.
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
Átgondoltam. Ugyanoda jutottam.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Tehát egy szoftver pusztán attól enterprise minősítésű, mert céges környezetben céges problémák megoldására használják? Másképp fogalmazva egy gép ipari felhasználásra való minősítése nem a tervezéstől és a kivitelezéstől függ, hanem a felhasználás helyszínétől?
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
Előbb azt kellene tisztázni, hogy az enterprise szó mit jelent. Ha a Facebook 100K gépen használ PHP-t az vajon kevésbé enterprise, mintha te 2 gépre Java-t telepítesz?
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
NagyZ -nek volt erről tavaly egy nagyon jó előadása az ELTÉn. Ha megkérjük, akkor biztosan linkeli neked az ott elhangzottakat. Az általam ismert link nem működik.
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
melyikre gondolsz? a Java EE osszefoglalora? van benne par helyesirasi hiba, meg a vegen a CDN reszen a nyilak par helyen rosszak, de az a pdf itt elerheto.
- A hozzászóláshoz be kell jelentkezni
Jöhet bármilyen _gyártófüggetlen_ elmélkedés arról, hogy mi az enterprise fogalma. Gyártók által összeállított agymosás arról, hogy _szerintük_ az ő termékük miért enterprise-abb másnál (főleg a konkurenciánál) nem érdekel.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
semmi gond, nem vagy szoftverfejleszto.
- A hozzászóláshoz be kell jelentkezni
Ebben egyetértünk. Teljesen más az enterprise fogalma a szoftverfejlesztő oldaláról, mint a technikai ember oldaláról. Teljesen más cégről cégre nézve. A Microsoft szerint az egy PC szerverre feltelepített egy darab Windows 2008 Enterprise Edition is enterprise. Ezért mondtam, hogy elég képlékeny dologról folyik itt a beszélgetés. Ez pedig nem egy robusztus megoldás.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
igaz, viszont van par dolog, amit le lehet fektetni, ha csak a hetkoznapi analogiat nezzuk. vagy nezzunk valami olyat, ami uzemeltetesi oldalrol:
- enterprise megoldas-e egy adatbazis ala 4db 1T-s desktop disk raid0ban?
- enterprise megoldas-e az, hogy az alkalmazast ha boviteni akarod, akkor 2x annyi proci kell ala, es 4x annyi ram, mert nincs ra lehetoseged, hogy normalisan berakj +n gepet?
a legjobb peldam, amit azert nem trivialis megoldani phpvel: webshop, juzer kattingat, van valami hw/sw LB az egesz elott. berakja a kosarba a cuccot, majd az egyik gep lehal (sticky http session van, szoval ugyanarra a gepre ment mindig a kerese). ilyenkor ugye mar a masik gepre menne, viszont ott nincs meg a session*, azaz a kosar ures lesz. vajon visszamegy az ugyfel?
*: tudom, tudom, megoldas lehet memcachedben tarolni a sessiont, vagy megoldas lehet nfsen fileban, csak k*rva lassu (ahogy itt a forumban sirt is valaki). a lenyeg: _kesz_ megoldast nem kapsz ra a phptol.
- A hozzászóláshoz be kell jelentkezni
Én feljebb azt kérdeztem, hogy vajon enterprise megoldás-e a Facebook PHP-ban írt megoldása. Erre nem kaptam választ.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
a facebook phpjanak annyi koze van az eredeti phphoz, mint nekem az autogumigyartashoz.
- A hozzászóláshoz be kell jelentkezni
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
szerinted mennyire irtak mar at? foleg hogy nemreg volt hir, hogy a coret is ujrairjak.
- A hozzászóláshoz be kell jelentkezni
A változtatásokról szóló linkek a cvs.php.net-re mutat. Emellett a Facebook ami tud visszaad a közösségnek.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
A Microsoft szerint az egy PC szerverre feltelepített egy darab Windows 2008 Enterprise Edition is enterprise.
Egy XP Home Edition attól nem lesz enterprise, mert egy cégnél azon van egy megosztott mappa amelyet vállalaton belül, vállalati problémák megoldására használnak. Egy áruházban a polcról levett PC se lesz enterprise, mert azon fut az előzőleg említett XP Home Edition.
Alapvető különbség az, hogy indulásnak jó az általános használatra szánt eszköz, bemész egy boltba, veszel egy kétezer forintos ütvefúrógépet és akár életed végéig kitart, ha nem léped túl a kereteit, és évente fúrsz vele téglafalba öt lyukat. A probléma ott kezdődik, ha panelbetonba akarsz lyukat fúrni vagy egymás után ötven lyukat téglafalba, ugyanis nem az lesz az eredmény, hogy több időbe kerül a probléma megoldása. A panelfalban egy 50mm mély nyolcas lyuk helyett lesz egy 40mm mély széles tölcsér, amely mindenre jó csak arra nem, hogy biztonságosan megálljon benne a tipli. A téglafalban pedig ötven lyuk helyett lesz 15-20 lyuk és a kezedben egy füstölő leégett fúrógép. Olcsón van egy viszonylag szűk mozgástered, aztán a következő lépés már a szakadékba vezet.
Az XP Home Edition is tökéletes mappák megosztására egészen addig, amíg nem akarsz jogkezelést, aztán szakadék. A PHP is tökéletes oldalak generálására, amíg nem akarsz magas rendelkezésre állást vagy XA tranzakcionalitást, ha ilyen kell, akkor a következő lépés a szakadékba vezet.
A Facebook nem pusztán PHP-t használ, bármennyire is próbálod bizonygatni. Jelentősen átírták a motort, mert a vanilla PHP nem alkalmas arra a célra, amire használják. Köré építettek egy olyan infrastruktúrát, amely képes arra, hogy session adatokat replikáljon és perzisztáljon, mert erre sem képes a vanilla PHP. Írtak hozzá egy precompilert, mert gyorsabb a natívra fordított kód, mint az interpretált PHP. Írtak hozzá saját adatbázis konnektort, mert az eredeti nem képes alapvető high availability viselkedésre. Tettek fölé egy cache réteget, mert ilyen nincs a PHP rendszerben. Apache helyett egy lecsupaszított HTTP szervert használnak. Gyakorlatilag kicseréltek mindent és maradt a PHP, mint nyelv, de a környezete teljesen más, mert erre volt szükségük. Egy részét odaadják a közösségnek (precompiler), de a lényegi részét nem, pont azt, amitől enterprise környezet lett náluk.
A PHP programozók igen nagy része csak pislogna a Facebook környezetét látva, mert teljesen más, mint az általa megszokott LAMP környezet, amely sajnos nem enterprise, de azzá tehető sok vérrel és verejtékkel, a végeredmény pedig nem LAMP környezet lesz, hanem a Facebook környezetéhez hasonló (érdemes keresni például "drupal clustering" kapcsán, már a sticky session is sok esetben problémás, mert a modulok fájlrendszerbe írnak vagy egyéb helyekre, amely nem kerül át másik node-ra, és hol van még a session replikáció).
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
Én nem próbáltam bizonygatni semmit. Főleg nem, hogy a Facebook csak PHP-t használ. Te próbálod bizonygatni, hogy a PHP semmire se való. Ilyenkor érzek mindig egy kis lenézést az elefántcsont toronyból. Valaki elkezd egyszer Java-zni (netán Java fórumot indít), vagy elmegy a Sun-hoz dolgozni, onnantól kezdve nem létezik más csak az. Szűklátókörűségre vall.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Én nem próbáltam bizonygatni semmit. Főleg nem, hogy a Facebook csak PHP-t használ. Te próbálod bizonygatni, hogy a PHP semmire se való.
Ahja. Én annyit bizonygattam, hogy a PHP nem való enterprise környezetbe, ellentétben a kiinduló cikk állításaival, viszont céges környezetben el tudok képzelni PHP programokat (lásd a kávéfőző esete céges felhasználásban példát).
Ezt eléggé érdekes módon arra fordítottad, hogy a Facebook PHP-t használ 100 ezer gépen, ezért a PHP igenis való enterprise környezetbe, aztán most a szemem közé vágod, hogy szerintem a PHP _semmire_ se való, holott ezt sehol nem írtam. Aztán persze szűklátókörű vagyok.
Én kérek elnézést.
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
aha, biztos igy van. nem tudom ki szokott a szemelyeskedes ellen felszolalni mindig, ugyhogy erdekes toled latni.
btw, ha feltunt volna (persze ahoz ertelmezni kene amit irok, nem csak loopolni vissza, se ismetelgetni a magadet), akkor en _szakmai_ szempontokat irtam arra, hogy miert fos a php.
szerintem tobbet foglalkoztam a temaval, mint Te valaha fogsz, foleg, hogy ilyen rendszereket fejlesztek. de en innen off, ugysem fogod meglatni az igazsagot ebben sem, es csak a sajat mantrad fogod ismetelgetni.
- A hozzászóláshoz be kell jelentkezni
Nem, te nem szakmai szempontból, hanem programozói szempontból írtad amit írtál, én meg leírtam, hogy akkor itt félreértés van. Innentől azért csak tovább hajtottad a magadét. Programozók gyakori hibája, hogy szerintük az ő szakmájukon kívül nincs más az informatikában.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Eddigi kozos vonasok az enterspajz termekeknel:
* Mocskosul draga (100%)
* Atlathatatlan (80%)
* I'am enterspajz poloban levo ceg arulja (99%)
* Zabalja a vasat (80%)
* Marktinkje szerint gyogyitja a rakot, a valosagban okozza (80%)
* Alapvetonek gondolt muvelet hianyzik/nem tamogatott (95%) (nem tamogatott: letezik nem hivatalos leiras, vagy kisakoztad hogyan lehet megoldani)
* (Nagyon) Sok ideig tart bevezetni (50%)
* Hosszu, buktatokkal teli upgrade folyamat (50%)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Attól enterprise valami, hogy a tervezése és a kivitelezése során arra törekedtek, hogy az eszköz hatékonyan és eredményesen végezze a feladatát ("ipari kivitel" jelző a kézzel fogható termékeknél). A Facebook ennek alapján enterprise, mert az általuk használt rendszert úgy tervezék és kivitelezték, hogy 7/24 hatalmas terheléseket viseljen el a lehetőségekhez mérten a leghatékonyabban. Náluk a PHP ipari célszerszámmá vált, ez a működésük alapja (vö.: kávéfőző egy vendéglőben), ráadásul nem vanilla PHP kódot futtatnak, mert az alkalmatlan erre a feladatra (vö.: átlagos kávéfőző egy iroda sarkában).
Mint említettem volt, nem az eszköz használati helye határozza meg az enterprise minősítést, hanem a tervezés és a kivitelezés. Nem is igazán tudok olyan PHP rendszerről, amely vanilla PHP kódon alapul és képes enterprise viselkedésre utaló jeleket felmutatni. Sok helyen JVM-ben futtatnak PHP kódokat (lásd Quercus), így a PHP alatt ott van egy alkalmazás szerver az enterprise architektúrájával, ettől még PHP nyelven kell programozni, de a klasszikus PHP kódbázishoz nincs sok köze.
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
PHP-ról beszéltünk általában. Most jön ez a "ez már nem olyan PHP". Bárkinek lehetősége van a Facebook-hoz hasonlóan fogni a PHP-t és megváltoztatni a saját szája íze szerint. Főleg úgy, hogy egy rakás változtatás visszakerül az upstream-be, meg úgy, hogy egy rakás változtatást kiadnak nyílt forrásúként. Ahogy a Facebook-nál "ipari célszerszámmá vált", ugyanúgy válhat x másik vállalatnál is azzá. Semmiképpen sem követném el azt a hibát, hogy a PHP-t leírjam, vagy lenézzem.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
arrol beszeltunk, h mi az enterprise, te meg terelsz, es valaszt sem adtal fent.
- A hozzászóláshoz be kell jelentkezni
Én fentebb lezártam a kérdést azzal, hogy számomra más az enterprise, mint amit beléd neveltek a Sun-nál. Erősen garantált lenne a körberöhögés, ha te itthon minden egyes megoldandó vállalati feladatnak úgy mennél neki, hogy a fentebb linkelt PDF-et lobogtatnád.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
en nem hangoztatnam ezt, mert leri, hogy nem ertesz hozza. javaban lehet gyorsan, jo, es robosztus kodot fejleszteni (lasd spring, apache wicket, ...), EE 6tal meginkabb.
hogy Te negativ peldakkal talalkoztal eddig, arra nem tudok mit mondani.
- A hozzászóláshoz be kell jelentkezni
Igazad van, a programozáshoz nem értek. Sőt, mi több, nem is akarok. Szerencsére nekem nem kell ezen a területen dolgozni. Én azon a területen dolgozok, aki azt szokta mondani a programozónak, hogy "öcsém szedd össze magad, aztán írjál rendesebb kódot, mert szégyen, hogy nem tudunk olyan vasat tolni alá, amin a fosod el tudna futni emberi módon". És eddig még mindig össze tudták szedni magukat és bebizonyosodott, hogy nem a fele, hanem a negyede is elég lett a végén annak, amit nagy arccal megálmodtak előtte.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
meg mindig nem ertem, hogy jon az, hogy inkompetens majmokkal talalkoztal akik programozonak hivtak magukat, az egesz temahoz.
- A hozzászóláshoz be kell jelentkezni
Egyetértek Trey-el. A magukat enterprise-nak nevező cégek sem tudnak normálisan programozni gondolom, könyörgöm lehet, hogy én egy párhuzamos univerzumban élek, de értelmes nem erőforrászabáló java-ban írt akármit még nem láttam.
http://hup.hu/szavazasok/20100212/ha_uj_hardvert_vesz_a_ceg_a_teljesitm…
Most lehet jönni azzal, hogy ezeknél az enterprise cégegnél csupa hátulgombolós dilettáns dolgozik, meg azzal is, hogy biztos ezen szoftverek bevezetését rontották el a rendszerintegrátorok és stb
- A hozzászóláshoz be kell jelentkezni
Nehe nagy enter spajz vendorok sajat honlapjainak viselkedeset is erdemes megnezni. viccess 50x hibakat dobnak :) ill. gyakran erdekes viselkedest (nem viselkesdest) produkalnak , es ok aruljak a valaltodba "a termeket", hogy te is ki tudj szolgalni :) LOL
Neha olyan szep hibakat produkal egy ket enterspajz cucc (kurva nagy vendrortol), amit pistike is szegyelne, es elgondolkozol, hogy miert nem Pistike termeket kertel. Komolyan mondom, meg pistike is jobb neha.
Mivel enterspajz a termek, nem baj ha szar hiszen van support. Ahhaaa , ahhaa ..
Pistikevel jobban szot lehet erteni.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
PHP-ról beszéltünk általában.
PHP alatt a szűkebb nyelvet érted, a nyelvhez kapcsolódó standard API-t vagy a php.net oldalról letölthető és lefordítható forrásokat vagy a LAMP/SAMP/WAMP környezetet?
Azért kérdezem, mert a Facebook csak a legszűkebb nyelvet tartotta meg, minden mást kicserélt. A munkaerőpiacon lévő fejlesztők igen nagy része pedig csak a LAMP-hoz ért, egy "Hello World" programot nem tudna a Facebook-nál megírni, mert a LAMP esetén nincsenek olyan függvények, hogy "is_facebook_user()" vagy "is_fbconnect_enabled()", a ciklus és az elágazás pedig minden nyelven ciklus és elágazás, nem az a programozás lényege, hanem a keretrendszer, abból pedig a Facebook sajátot fejlesztett.
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
Amit te konzekvensen kihagysz a szamitasbol az egy online szolgaltatas termeszetes fejlodese. A cegek 99%-a nem fog alapbol oriasi terhelesre felkeszulni, mivel nem eri meg a befektetett penzt. Ez nem alabecsules, ez esszeru dontes. Ha ehhez hozzaveszed az nemileg olcsobb munkaerot (bar ahogy a cikk is allitja ez kezd kiegyenlitodni), es a fejlesztes sebesseget, akkor vilagos, hogy miert ez a trend.
- A hozzászóláshoz be kell jelentkezni
Azt a fejlesztési sebességet magyarázd már el nekem.
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
+1, ezt akartam en is mondani, csak nem tudtam hova szurjam be trey es NagyZ koze:D
- A hozzászóláshoz be kell jelentkezni
azt meg Te hagyod ki a szamitasbol, hogy (bar nem vagyok php guru) ha felmerul igeny nagyobb rendelkezesreallasra, elosztottsagra, normalis read-write balancingra, akkor szivsz phpvel.
- A hozzászóláshoz be kell jelentkezni
Amit te konzekvensen kihagysz a szamitasbol az egy online szolgaltatas termeszetes fejlodese.
Pont ezt nem hagyom ki. Több esetben találkoztam olyannal, hogy hirtelen felfutott a szolgáltatás, aztán a PHP csodával ott álltak a szakadék szélén és sehogy nem tudták úgy bővíteni, hogy jó legyen, mert nem számítottak arra, hogy két gépen kell futtatni. Aztán először maradtak egy gépnél, és betettek egy saját cache réteget. Aztán ez is kevés lett, akkor denormalizálták az adatbázist. Aztán ez is kevés lett, akkor elkezdtek itt-ott fájlokba írni adatbázis helyett. Aztán ez is kevés lett, nem tudtak több processzort vagy több memóriát alátenni, kellett két gép. Aztán kiderült, hogy a cache nem elosztott, nem tudott egymásról a két gép, eldobták a cache réteget, és lett három gép. Aztán kiderült, hogy nincs session replikáció, lett helyette sticky session. Ebből kiderült, hogy egy-egy újraindítás esetén a látogatók egyharmada kiesik a rendszerből, de ezt lenyelik általában. Aztán kiderült, hogy a fájlrendszer se elosztott, tettek alá NFS fájlrenszert. Aztán kiderült, hogy nem használnak lock-ot, mert eddig egyedül írta-olvasta a fájlt egy program. Aztán kiderült, hogy kevés lesz egy adatbázis, és kettő kellene. Na, ekkor derült ki, hogy a használt adatbázis szerkezet nem tud két adatbázis instance-ban futni. Ésatöbbi apró pici szívás.
Ha az ember biztos benne, hogy nem fog felfutni a dolog, akkor nincs baj. De az élet sokszor vicces tud lenni, aztán jönnek a sorozatos vezeklések a rossz döntések miatt és a végén sokkal drágább lesz a számla, mintha olyan rendszerben kezdtek volna fejleszteni, amely a fentieket mind alapból támogatja.
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
Ja, meg olyat is látni nem egyet, hogy ott a több tíz / száz millió forintért megálmodott rendszer, a kutya nem látogatja a Google botokon kívül (azok is csak immel-ámmal mert fos az egész), kib. enterprise, messziről látszik (főleg a megbízott programozók díján) és a tizedéből ki lehetett volna hozni ha kisebbet, de a feladatnak megfelelőt álmodnak.
Külön pikantériája ennek az egész Java kérdésnek, hogy talán a Sun volt az egyetlen olyan IT vállalat, aki az elmúlt 10 éveben nem tudta megoldani a __saját__ weboldalainak lassúsági problémáját... ÜberJava ide, vagy oda.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Láttam én már ilyet is. De sajnos nem ez a többség, mert a befektetők szoktak aggódni a pénzükért, ezért inkább a fukarkodás és a nagy nyereség megálmodása a gyakori. A többség sajnos alultervezett rendszer, amely nem bővíthető, holott az üzleti tervben is megálmodták azt a látogató számot, amelynek a harmada már bedöntötte a kiszolgálót, de a választott technológia és az olcsó megoldások miatt nem lehetett tovább lépni.
Nekem a Sun oldalaival nem volt problémám, átlagos sebességgel volt elérhető. A java.net sokszor volt lassú, de az nem Sun.
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
Ha hirtelen megindul a szeker, az nem csak a weboldalt fogja erinteni, hanem sokminden mast is. Mellesleg szervezetileg sem fogsz egy multicegben megszokott infrastrukturat uzemeltetni kis vagy kozepcegben pusztan azert mert jol skalazodik.
Alapvetoen senki nem fog enterprise szintu clusterezett megoldassal (plane 5 9-essel) nekivagni egy olyan uzletnek, ami ezt _nem tuzte ki celjaul_. Akkor sem, ha ingyen a nyakadba akasztjak. Amikor a korulmenyek valtoznak es a rendszered kinotte magat, akkor majd le fogod cserelni. Akar tok masra. Igen, akkor es ott tobbe fog kerulni, mintha csak alatolnad a +n gepet, de termeszetesen merlegelni kell azt is, hogy a nagy attores esetleg 5 ev utan tortenik meg, mialatt meg is sporoltad azt az osszeget a szerenyebb megoldasoddal. Ez a kerdes nem pusztan technikai.
- A hozzászóláshoz be kell jelentkezni
Ha jól értem amit mondasz, akkor nem egészen értek vele egyet. Felénk nincs érezhető költségnövekedés azért, mert Java-ban fejlesztünk és nem akármi másban. Sokakkal ellentétben nem terheltebbek a szerverek*, a fejlesztési idő 1/4-ével csökkent, a tesztelési idő meg min 1/3-ával. Nem vitatom ennek lehet oka az, hogy mi ugyanazért az órabérért programozunk minden nyelven, és előfordulhat olyan, hogy amiatt nem költséghatékony az elején mondjuk Java-ban fejleszteni, mert nem olcsó a munkaerő.
* kis kitérőa teljesítmény miatt károgókról:
Nemrég egy rendszergazda panaszolta nekünk, hogy milyen szar az egész, mert van most egy projectjük és nem győzik alátolni a vasat mert a glassfish lezabál mindent, aztán nekem kellett felvilágosítani, hogy a glassfishnek fel kell venni a megnyitható fájlok számát, mert gyorsan túlnövi a limitet, gondolom mennyire felkészült volt a témából.
- A hozzászóláshoz be kell jelentkezni
Nem tudom, jol ertetted-e :-) Igy hirtelen nem latom az eros kotodest, de ez nem feltetlen baj :-)
Egy apro komment, mert a hatamon felall a szor, annyiszor hangzik mar el: a hatekonysag novekedes (fejlesztesi idoben, stb) nem a javanak koszonheto. Annak koszonheto, hogy jo, megbizhato grafikus eszkozeid vannak a fejleszteshez, az automatikus dokumentalashoz, stb. Egy IDE, ami tudja mit muvelsz, az 100x annyit jelent hatekonysagban mint maga a nyelv. Ennek a felismerese sajnos nem mutatkozik meg sok nyelv fejlesztese soran meg ma sem.
A Java es a c++ pl nyelvi szinten meglehetosen kozel vannak, megsem azert nehezebb c++ fejleszteni, mert a nyelv szar, hanem mert a mai napig vacak eszkozok vannak hozza. Nagy kar, hogy anno a c++ nem fejlodott tovabb (itt eros hangsuly van a fejlodesen) es nem tudta ledobni magarol a c betegsegeit. Akkor fejlodhetett volna kore IDE platform pont ugy ahogy kesobb a javahoz. Valszeg a java sem letezne ;-)
- A hozzászóláshoz be kell jelentkezni
Nem én akartam elsőnek kimondani, szerintem is egy nyelv hatékonysága leginkább a rendelkezésre álló eszközökön múlik (tracing, debuging, profiling, covering, IDE, stb.), egy percig sem gondoltam azt, hogy a Java mint programozási nyelv okozza a hatékonyság növekedését, hanem az, hogy az eszközkészlet olyan mértékben növeli a hatékonyságot, amiről a PHP-s világban még csak álmodni sem lehet.
- A hozzászóláshoz be kell jelentkezni
Azért ha csak a nyelveket nézed akkor is van közöttük pár óriási különbség. Az egyik fordított nyelv míg a másik interpretált. Az egyikben van típusellenőrzés a másikban nincs. Ott van a java virtuális gép rengeteg előnye.
- A hozzászóláshoz be kell jelentkezni
Mi különbség az interpretált java bájtkód és az interpretált PHP bájtkód (valamilyen acceleratorral) között?
suckIT szopás minden nap! Solaris Itaniumon
- A hozzászóláshoz be kell jelentkezni
Az, hogy a HotSpot JVM JIT-compilere szepen nativ kodot csinal a Java bytekodbol.
- A hozzászóláshoz be kell jelentkezni
Tehát ettől a Java "fordított nyelv", míg a PHP nem.
suckIT szopás minden nap! Solaris Itaniumon
- A hozzászóláshoz be kell jelentkezni
ezt irtak fent is, HTH.
- A hozzászóláshoz be kell jelentkezni
Ha tehát csinál valaki JIT-es interpretert, az is fordított nyelv lesz? Van olyan nyelv, amelyik nem tud fordított lenni?
suckIT szopás minden nap! Solaris Itaniumon
- A hozzászóláshoz be kell jelentkezni
nincs.
- A hozzászóláshoz be kell jelentkezni
Itt a forditas alatt azt értem, hogy a forráskód és a futtatott kód (bytekód) elkülönül, van köztük egy fordítási lépés. Ez még akkor is igaz, ha java interpreterrel futtatod a fordított bytekódot.
- A hozzászóláshoz be kell jelentkezni
PHP-nal is. Zend Engine bytecode fog futni a parzolas utan. Csakhogy defaultban mindig van parzolas, ezt a kulonfele opcode cache-ekkel ki lehet cselezni.
- A hozzászóláshoz be kell jelentkezni
Köszi ezt nem tudtam.
- A hozzászóláshoz be kell jelentkezni
Elképesztően fejlett ez a java-techológia. :)
Ebből levezetni azt, hogy a "java fordított nyelv", hát...
suckIT szopás minden nap! Solaris Itaniumon
- A hozzászóláshoz be kell jelentkezni
Nem a javáról van itt szó, hanem a fordításról és a típusosságról. :)
Bármilyen programnyelvről beszélsz, a kódolás hatékonyságát segíti és a hibák mennyiségét csökkeni, ha a forrás megírása után van egy fordítóprogramod - compilered, ami végignyalja a forrást, kiírja a szintaktikai hibáidat és a típusütközéseket.
Ellenkező esetben (interpretált nyelv, fordítás nélkül) bármilyen programban maradhat olyan ág, ami még nem futott le mert nem klikkelt oda senki, vagy nem volt olyan bemeneti adat, paraméter.
- A hozzászóláshoz be kell jelentkezni
En nem sok elonyt erzek a virtalis gepben, plane ha JIT is bejon a kepbe, akkor lenyegeben mar csak arrol beszelhetunk hogy dinamikusan fordit, ami termeszetesen barmi ala betolhato. Nem nyelv fuggo a dolog. Arrol nem beszelve, hogy attol hogy egy adott platformon le tud fordulni az a kod, az nem azt jelenti hogy ott hude optimalis lesz, mert nem fogjak _mindenhova_ optimalizalni meg a JITet sem.
- A hozzászóláshoz be kell jelentkezni
A VM egyik legnagyobb előnye a beépített garbage collection. A JIT pedig akár optimalizál akár nem, legalább natív kódot futtat. Szerintem x86 platformon mondjuk optimalizál is a JIT, voltak itt a HUP-on is belinkelt tesztek fordított C++ kód és JIT java kód sebesség összehasonlításáról, meglepően kis különbséggel.
A legnagyobb előny viszont a típusosság és a fordítás következménye: a kódolási hibák nagy százaléka fordítási időben kiderül (a szintaktikai hibák biztosan).
- A hozzászóláshoz be kell jelentkezni
Mivel a Java alapvetoen c++, nem olyan meglepo hogy kabe ugyanazt birjak ;-)
- A hozzászóláshoz be kell jelentkezni
Reszletkerdes amirol irsz.
Ez a "hirtelen felfut" az egyik legritkabb eset, es minden cegnek az az alma, hogy ilyen problemaja legyen ;)
Ha pedig megtortenik akkor, ahogy alattam is irtak sok mindent at kell majd alakitani, aminek csak egy technikai reszlete az, amirol te irtal. Raadasul ha mar a tech. reszet nezzuk, akkor ma 2010-ben egy normalis php/python/ruby (amugy nem vagom miert mindenki csak az elson lovagol...) kodbazis mellett igen nagy felfutasnak kell tortennie ahhoz, hogy a ceg ilyesfajta problemaba utkozzon (lasd pl yahoo answers), es ilyenkor is altalaban hibrid megoldasok szuletnek, leggyakoribb esetben a backend ujrairasa java-ban/scala-ban/etc-ben, mig a front ugyanugy marad php/python/ruby.
Osszegezve amit szerintem meg mindig nem latsz az az, hogy 100-bol 99 ceg (amikbol aztan par ugyes+szerencses kinovi magat egeszen odaig, hogy a fenti problemakba utkozzon) el sem indulna, ha rogton az altalad felvazolt architekturaval kezdene. Mint ahogy boltot sem ugy nyit az ember, hogy kezdesnek vesz 30 kamiont es 5 raktarat, biztos ami biztos.
- A hozzászóláshoz be kell jelentkezni
Osztom a véleményed, és bár mérésekkel nincs módom alátámasztani, de elég nehéz labdába rúgni a perisztencia kontextusban tárolt entitások és a cachelt servletekkel szemben egy folyton parsolós, szintaktikailag ellenőrzős, előfordítós környezetnek nagy terhelés mellett. Viszont ami szerintem méginkább elbillenti a mérleget, az a fejlesztési idő (itt nem egy egy űrlapos honlapra gondolok). Egy nagyobb project esetén összemérhetetlen az a kényelem, kódbiztonság, stb. amit a Java nyújt mondjuk a PHP-vel szemben, és bár mint trey írta ebben a gazdasági helyzetben számít mennyi és milyen vasat kell a rendszer alá venni, véleményem szerint a fejlesztői órák sokkal többe kerülnek.
- A hozzászóláshoz be kell jelentkezni
Nekem is hasonlók jutottak eszembe az erőforrások tekintetében.
Hasonlítsunk almát almával: a PHP (jó esetben) ahhoz hasonlít leginkább, mintha JSP-t használnál java objektumokkal. Frameworköktől most tekintsünk el. Tegyük fel, hogy így megírsz pár weboldalt mindkét technológiával. A JSP lefordul és elfut bármilyen kis servlet containerben. Ez biztosan nem lesz lassabb (sőt szerintem jóval gyorsabb lesz), mint ugyanannak az oldalnak a hasonló PHP-s verziója. Talán a szerver kezdeti memória foglalása lesz kicsivel magasabb, a jvm kezdeti inicializálása miatt. De ha csak a servlet containert nézed és nem egy full apllication servert, akkor a memória overhead nem jelentős. Az oldal generálás viszont baromi gyors lesz. Én például wickettel mértem 1-2ms -os válaszidőket adatbázisból generált dinamikus html oldalak esetén.
- A hozzászóláshoz be kell jelentkezni
Az Enterprise Java háttér három ok miatt fogyaszt több memóriát és indul lassan:
* Kiépíti a különböző pool-okat, felkészül a terhelésre
* Kiépíti a cache rétegeket, felkészül a terhelésre
* Előfordítja a JSP oldalakat
* Közös barátaink írják a kódot
:))
--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.
- A hozzászóláshoz be kell jelentkezni
:)))
- A hozzászóláshoz be kell jelentkezni
"Csöves webshop" mióta enterspájz fölhasználás? :)
--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.
- A hozzászóláshoz be kell jelentkezni
A projekt dokumentációja szerint vállalati megoldás. A Java programozók szerint enterprise megoldás(nak kellene lennie mindenképpen), amihez mérten kell őket majd díjazni (nyilvánvaló.... ahahahaahahah), szerintem pedig mindössze egy csöves webshop. Így jön az ki, hogy mindenki egy dologról beszél, de mégis máshogy nevezi. ;)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Valahogy ez jutott eszembe :D
- A hozzászóláshoz be kell jelentkezni
http://www.projectcartoon.com/cartoon/1 ez az igazi:)
- A hozzászóláshoz be kell jelentkezni
Érdekes szavakat adsz mások szájába...
Ha a cég fő tevékenysége weben eladni cuccokat, akkor oda enterprise megoldás kell.
Ha a cég fő tevékenysége alapvetően a puhafa köbözés és mellékesen kell neki egy webes felület, ahol pár ügyfelének el tudja adni a köbözött fát, de a webes felület hibája esetén nem áll le a puhafa köbözéssel, különösebb veszteséget nem okoz neki, akkor nem kell enterprise webshop.
Mindkét esetben lehet másképp dönteni, valaki fel fogja vállalni a döntése következményeit. Lehet ezen ember számára tanácsot adni, hogy a számára ismeretlen területen milyen kockázatok lehetnek és lehet hagyni, hogy sötétben döntsön és akkor az olcsóbbat fogja választani.
Azt hiszem erről a témáról eleget beszéltem már, nem fogok többet. Felesleges.
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
+1 a feleslegesre, ugysem ertik meg.
- A hozzászóláshoz be kell jelentkezni