Megnőtt a PHP és Python fejlesztők iránti kereslet

Címkék

Új kutatás szerint nőtt a kereslet a PHP és Python programozók iránt. Céges környezetben egyre nagyobb arányban használják ezeket programozási nyelveket fejlesztésiekhez. Az angol nyelvű cikk diagrammal itt olvasható.

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?

Kiváncsi lennék hol szerepelne a diagrammon a Javascript fejlesztők iránti igény.

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 :-)

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? :)

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ő.

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 --

É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

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.

java'nother blog

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. :)

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

É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 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

"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 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

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

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

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

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 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

É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

É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

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.

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

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.

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

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

É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

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

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

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.

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

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.

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

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

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

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.

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.

java'nother blog

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 ;-)

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.

java'nother blog

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.

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 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).

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.

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.

java'nother blog

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.

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 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

É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