Enterpriseok tenyleg szeretik a javat ?

Java

Nehany itteni hozzaszolasban talalkoztam olyan felhangokkal, hogy ugyan azt a megoldast javaban implementalva jobb penzert lehet eladni.
Ez tenyleg igaz ?
Valoban jobb bevetelekre szamithat az ember, ha Javaban dolgozik, meg ha ez mas szempontokbol nem is lenne indokolt ?

  • 8754 megtekintés

( NagyZ v | 2010. 03. 21., v – 23:55 )

igen. a java superior, szerver oldalon mindent visz.

annyira, hogy lássam az erőforrás felhasználását, annyira biztosan.
de ettől függetlenül, elég megnézni a specifikációkat, hogy lásd, nem takarékosság volt a cél. adatbázison jdbc réteg, azon rowset, azon dataprovider (ha csak woodstockot nézed), másik irányból hibernate, jpa, mindenféle varázsszavak, minden xml-ben megy, mert a jáva fanok atombombánál kisebbet még szúnyogra sem bírnak dobni... nézz meg egy glassfish server.log-ot, ha az nem szószátyár, akkor mi az? Az a kisebbik, hogy kis terhelésű szerveren is secperc alatt eltűnik 4-5 giga diszk a logok miatt, de mire megtalálod benne, hogy mi baja volt...

mindenre van szabvány, mire átlátod, nem csak a hardver procit és memóriát, de a szoftver procit is kisámfázod...

nem akarok az előnyeiről vitatkozni, nyilván vannak olyanok, de a proci meg a memória felhasználás biztosan nincs közöttük.

én meg azt bírom, amikor valakinek annyi az érve, hogy mer úgy van, PONT.

En meg azt imadom, amikor valaki elkezd egy teruletrol sommas velemenyeket mondani, holott nem is biztos, hogy azon a kornyeken dolgozik, es/vagy hogy tenyleg melyen ismeri az illeto teruletet.
1) Ma mar majdnem minden kommunikacio XML alapu. Ami nem, az JSON alapu. Pont. En is utalom az XML-t butykolni, de pl. egy perl kodot sokkal jobban utalok piszkalni.
2) GF server.log? Na ne rohogtess, az sokszor meg tul szukszavu is. En debugoltam mar orakat, hogy mi a francert nem indul el a szerver. Raadasul tudok nagyon sok bobeszedubb appot mondani, ahol 4G logterulet olyan, mintha nem is lenne.
3) Mindenre van szabvany: akkor kezdenek el aggodni, ha a vilag a szabvanytalansag fele menne el. A C/C++ vilagbol ugy hianyzik mar egy kicsivel nagyobb egysegesseg, mint egy falat kenyer. Raadasul a Java egy szabad nyelv: nem kotelezo mindent szabvanyosan csinalni, leimplementalhatsz a vilagon mindent magadnak - csak azutan gyozd karbantartani is.
4) Eroforras: erre nem tudok mit mondani. Nyilvan aki komolyabb enterprise dologba kezd bele, az nem egy P4 512 RAM 40G HDD trioval fog nekivagni. A mai hardverek, kivaltkepp a mai szerverhardverek pedig rohogve elbirjak egy EE app terheleset. Nem gondolnam, hogy ha webszervert kell az embernek csinalni, akkor belepo szintu hardverben kezd el gondolkodni.
Egyebkent, mint mindent, ezt is tervezni kell, es optimalizalni is kell. Az a Java kod, ami kesz allapotaban is irrealisat fogyaszt, az... optimalizalatlan. Ezen felul a mai memoriaarak mellett mar ne kezdjunk el pont a memorian garasoskodni. Foleg annak fenyeben, hogy bizonyos oprendszerek alaphangon harapnak egy fel giga ramot indulaskepp, plusz extrem prociigenyei is vannak.
5) meg a logokra egy kicsit visszaterve: amennyire tudom, eleg jol allithato, hogy hol mennyi log termelodjon. Ha az alkalmazas oldalan ez nem allithato - elnezest, de ezert nem a Java a hibas, a lehetoseg ugyanis megvan. Produktiv kornyezetben egyebkent sem biztos, hogy development szintu logolast kell tartani.
6) Nyilvan nem csak annyi az erv, hogy mert ugy van. De en azt tapasztaltam, hogy egy eleve tamado attituddel indulo vitaban a fo csapasirany ugyis egymas utlegelese lesz, es ebbol hihetetlen nehez ertelmes kommunikaciot kialakitani. En sem szeretem NagyZ attitudjet, de ezt nem vetitem ra az altala kepviselt teruletre, reszben azert, mert magam is kedvelem a Java-t, reszben pedig azert, mert e tekintetben NagyZ-nek semmi koze a Java-hoz, o maximum egy undok fejleszto, aki veletlenul a Java-t valasztotta.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Azert kommunikaciora a nagyok kitalaltak mar okosabb dolgokat is, pl. protobuf vagy Thrift. Miert kene a gepek kozotti kommunikacionak ember altal olvashatonak lennie, foleg teljesitmenyintenziv helyen? Baromsag is lenne.
Bovebben:
http://code.google.com/p/protobuf/
es
http://incubator.apache.org/thrift/
(a Thrift annak ellenere, hogy Apache Incubator projekt, a Facebook sajat fejlesztese)

Nem rossz az, csak tudni kell hasznalni. Sokak szamara viszont ultimate megoldast jelent (XML DB azert LOL). Strukturalt dokumentumok tarolasara tokeletes, de nagyteljesitmenyu adatmozgatasra vagy adattarolasra, foleg ott, ahol csak gepek dolgozzak fel az adatokat (azaz nem kell szem ele kerulnie SOHA), agyuval verebre kategoria.

Igen, mert az egy elore elkeszitett schema felhasznaloi felulet leirasara...a kiiindulo gondolat az volt, hogy de jo az XML-ben tarolt adat (tetszoleges elore definialt schemaval), mert azt egy XSLT transzformacioval ki lehet adni az UI-ra a usernek. Tudsz olyan XSLT transzformaciot, ami megcsinalhja az alabbit: van egy adatfile-om egy adott schemahoz. Ebbol transzformal nekem egy olyan XAML filet, ami tartalmazza az adatokat, valamint a mukodeseket (tarolas, validacio) leiro fuggvenyeket, majd meg is jeleniti a felhasznaloi feluleten? A XAMl meg mindig csak az UI layout leirasara szolgal, a mukodesre nem.

Igen, specialisan definialt XML dokumentuk alapjan tud algoritmikusan UI-t epiteni (ez nem nagy kunszt, ilyet csinaltam en is SWT-hez: sajat magam altal definialt XML-bol epitettem dialog boxokat a beallitasi lehetosegek tarolasara plugin-rendszeru kornyezetben), de te arrol beszeltel, hogy van valahol egy adat-xml-ed es azt szepen XSLT-vel ki tudod tolni a user fele..az XSLT ki fogja neked talalni, hogy oda, ahol ket beallitasi lehetoseg van, a checkbox a jo megoldas vagy a ketelemu lista? Az XSLT ki fogja neked talalni, hogy az adatod alapjan mik a valid es nem valid szemantikai tartalmak? Erre ugyanugy kod kell. Vagy kitalalja nekem, hogy bizony ehhez az XML-hez ilyen sugoszovegek kellenek? Ha elindulunk abba az iranyba, hogy ezt megcsinaljuk, oda jutunk, hogy lesz XML az adat szamara, meg lesz XML a felhasznaloi felulet szamara..mint ahogy most is van az XHTML template + XML adatforras eseten. Csakhogy az XHTML felhasznaloi feluleti elemei nagyon szegenyesek a rendes dekstop GUI-khoz kepest. Persze lehetne Javascripttel okositani mindent (sajat widgetek irasa), de attol az meg nem lesz nativ UI-elem, legjobb pelda a ComboBox, azaz a szerkesztheto lenyilo lista. Ilyen XHTML-ben nincs. Vagy a tabok. Vagy a splitpanek, vagy a fa-widgetek, vagy a progressbarok. En szeretem, ha a kinezet beleillik a platform altal adott nativ kinezetben . Ezert tudok hanyni a sok Swinges nem nativ, csak emulalt nativ GUI-tol, meg a fontbeallitasokat se veszi at az OS-tol, rendes hinting sincs. Akkor mar inkabb SWT, az nativ.

Adott esetben az XSLT-t eleg jol fel lehet am okositani, illetve a statikus dolgokat bele lehet tenni kulon XML-be is, de nem is ez a lenyeg.

Nyilvan nem mindent kell XML-ben tarolni, csak amit lehet, es aminek ertelme is van. En sem ertek egyet az XMLDB-kkel, de ugyanakkor nem is mondom azt, hogy az XML a legrosszabb, ami a vilaggal tortenhetett. Igenis megvan a maga helye a vilagban, es a letjogosultsaga. Peldaul, a Qt forditasi fajljai XML-ek, es hihetetlen konnyebbseget jelent, hogy tudok kulon forditoi kommenteket is belefuzni; ugyanakkor ezt PO fajllal nem nagyon lehet eljatszani. Aztan ott az XML-RPC, a SOAP... ezek mind olyan jo dolgok, amik nelkul szegenyebb lenne a vilag szerintem.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

json-nel szamolni kell a melyseget, nem annyira jol olvashato tabulalas nelkul, de nem is feltetlen amiatt hoztam szoba, csak arra akartam utalni, hogy nem feltetlen a nem binarissaga miatt bloat az xml.
csak egyszeruen ez lett elobb, ezt kezdte el mindenki hasznalni, es sok ido fog meg elteni, mire kikopik azokrol a helyekrol, ahova nem o (az xml) a legalkalmasabb.

Tyrael

Mert akkor könyebb feldolgozni mi? Ne légy már naiv, greppelni XML-ben is lehet, a syslog meg csak egy eszköz a továbbításra / tárolásra, de nem a formátumra... Ha strukturált a dump, akkor legalább lehet rá tool-t írni, ami feldolgozza... és könyebb mint plaintextre...

ha strukturált, több szinten egymásba ágyazott adat van xml-ben, akkor hiába grepelsz rá, nem feltétlenül találod meg azt a szülőt, amelyik gyerekét kidobta a grep.

"lehet rá toolt írni": aha, látod már, hogy miért mondtam, hogy egyes jáva fanboyok atombombánál kisebb cuccal nem mennek még verébre sem...

A szemlélet nem tetszik, hogy egy helytelenül megválasztott/használt eszközt újabb és újabb toolok bevonásával próbálnak használhatóvá tenni, ahelyett, hogy a problémát kiváltó okot orvosolnák...

Ez egyrészt olyan, mint a windows: nem a windowst faragják meg rendesen, hanem vegyél rá víruskeresőt, spyware removert, adware blockert, ilyeneket. Másrészt meg olyan, mintha a nemzeti bank a Hősök terére kirakott asztalokon tárolná a pénzt és csodálkoznának, hogy mindig ellopják, majd raknának kerítést, őröket, kamerarendszert a Hősök terére, ahelyett, hogy visszahordanák a budaörsi központjuk páncéltermébe a csentót.

Nem szeretem workaroundolni a problémát. Megoldani szeretem a problémát.

Madj ha a Linux is lesz annyira elterjedt, mint a Windows platform, arra is vehetsz spyware removert, viruskeresot, barmit. Nem veletlenul celcsoport a Windows a szamitogepes bunozesben. Ne hidd, hogy a Linux sokkal jobb biztonsagban, vagy barmilyen mas opensource projekt. Egyszeruen csak amit kevesen hasznalnak, ott kevesebbszer jon elo problema, vagy nem celcsoport a direkt tamadasok ellen. Na meg aztan Linuxon is van AppArmor, SELinux, PaX, stb, ami mind-mind plusz eszkoz, mert onmagaban a rendszer nem biztonsagos. Csak legfeljebb ezeket nem kell megvenni.

A szemlélet nem tetszik, hogy egy helytelenül megválasztott/használt eszközt újabb és újabb toolok bevonásával próbálnak használhatóvá tenni, ahelyett, hogy a problémát kiváltó okot orvosolnák...

Az a baj, hogy nálad a Java és az XML oldhatatlan kötéssel rögzítve van a "helytelenül megválasztott eszköz" dobozkádba. Minden érved ebből indul ki, s egyszerűen leperegnek rólad azok a tények és mérések, amelyek ezt nem támaszják alá, miközben évek - lassan évtizedek - óta elavult és idejét múlt tényekkel próbálod alátámasztani ezt a rögeszméd.

Nem szeretem workaroundolni a problémát. Megoldani szeretem a problémát.

Az a baj, hogy innen nézve nem oldod meg a problémát, hanem próbálod az általad elérhető és érthető eszközök szintjén tartani. Ha pedig nem oldható meg az általad használt eszközökkel, akkor csak és kizárólag "workaround létezik rá" a kis világodban.
--
http://wiki.javaforum.hu/display/FREEBSD

Hmm... vajon ki is kezdte... megvan, valami bambano volt a neve.

Úgy látom nehezen tudod feldolgozni, hogy nincs igazad. Egyszerűen ebból lehet erre következtetni, hogy tényekre és mérésekre személyeskedni kezdesz, ahelyett, hogy tényekkel és mérésekkel vágnál vissza. Ebből tovább gondolkodva az ember könnyen arra a következtetésre jut, hogy eredetileg se volt tudás és tapasztalat a hozzászólásod mögött, csak másod- vagy harmadkézből való félinformációkra alapoztad a hozzászólásodat. És sajnos teszed ezt továbbra is.

Természetesen bocsánatot kérek a személyeskedésért, amint mutatsz ebben a thread-ben olyan tőled származó írást, ami tényekkel, mérésekkel alátámasztható megállapítást tartalmaz. Én sajnos nem találtam, de talán mutatsz majd egy ilyet.
--
http://wiki.javaforum.hu/display/FREEBSD

No akkor személyeskedjünk egy kicsit:
lassan írom, hogy te is megértsd a kis világodban: egy poénnak szánt hozzászólást nem fogok mérési eredményekkel alátámasztani. Két választási lehetőséged van mindössze: röhögsz rajta egy jót vagy beszólsz, hogy szar vicc volt. Humortalanul élni rossz, március 25-én csütörtökön délután egy március 22-i rosszul sikerült hozzászóláson rugózni még rosszabb.

Ok, én is lassan írom, hogy megértsd: nem egy poénnak szánt hozzászólásról van szó.

Segítek:

annyira, hogy lássam az erőforrás felhasználását, annyira biztosan.
de ettől függetlenül, elég megnézni a specifikációkat, hogy lásd, nem takarékosság volt a cél. adatbázison jdbc réteg, azon rowset, azon dataprovider (ha csak woodstockot nézed), másik irányból hibernate, jpa, mindenféle varázsszavak, minden xml-ben megy, mert a jáva fanok atombombánál kisebbet még szúnyogra sem bírnak dobni... nézz meg egy glassfish server.log-ot, ha az nem szószátyár, akkor mi az? Az a kisebbik, hogy kis terhelésű szerveren is secperc alatt eltűnik 4-5 giga diszk a logok miatt, de mire megtalálod benne, hogy mi baja volt...

mindenre van szabvány, mire átlátod, nem csak a hardver procit és memóriát, de a szoftver procit is kisámfázod...

nem akarok az előnyeiről vitatkozni, nyilván vannak olyanok, de a proci meg a memória felhasználás biztosan nincs közöttük.

én meg azt bírom, amikor valakinek annyi az érve, hogy mer úgy van, PONT.

Ebben hol a poén? Kérlek, mutass rá, mert nem látom.

Főképp erre reagáltam mérésekkel és következetésekkel:

nem akarok az előnyeiről vitatkozni, nyilván vannak olyanok, de a proci meg a memória felhasználás biztosan nincs közöttük.

Ebben hol a poén?

Nem érdekel, hogy poénnal nyitottál a vízözön előtt, az utána poénmentes hozzászólásokat írtál személyeskedő hangvételben. Aztán még játszod a sértődöttet... szánalmas vagy, azt kell mondjam.

Természetesen bocsánatot kérek a személyeskedésért, amint mutatsz ebben a thread-ben olyan tőled származó írást, ami tényekkel, mérésekkel alátámasztható megállapítást tartalmaz. Én sajnos nem találtam, de talán mutatsz majd egy ilyet.

Úgy látom, te se találtál ilyet a hozzászólásaid között... én itt befejeztem, nem látom értelmét folytatni.
--
http://wiki.javaforum.hu/display/FREEBSD

Öm, tisztázzuk, én ezt úgy értettem fentebb, hogy text editorban nehéz az XML-t értelmezni, embernek, ha 69 megányi adatod van. Nyilván van rá egy xslt-m.
Valószínűleg azért van ez az egész kavar, mert human readable, strukturált, de gépi értelmezésre szánt formátum az XML. ezt sokan nem értik.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

????? Grep-hez minek regex? fgrep valamiszoveg /var/log/messages. Ebbe nem latom a regexpet, de lehet en vagyok vak. XPath-hoz viszont nem eleg a keresett szoveg, de FIXME itt is, ha tevednek.

Nem a magam igazat hajtom, csak komolyan nem ertem, hogy mire gondolsz.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

itt valaki azt írta, hogy a 63MB-os txt logot is fel lehet dolgozni regex-el. Mások meg azt állítják hogy ehhez célszerűbb lehet az XPath, ha már a program tudja strukturálni. Volt már arról is szó hogy XML is text és azt is lehet greppelni. Próbáld meg összerakni újra, szerintem felesleges még egyszer leírni az összes érvet. A lényeg amit mondani akarok: egy XML dump nem rosszabb egy text dumpnál, mivelhogy sokkal több eszközzel tudod elemezni. De vannak itt a threadben emberek, akik nem tudnak XPath-ul, és nehéznek érzik ezt, így dramatizálnak. Feleslegesen.

Ha fogalmad sincs az xml-ről és az xpath-ról, akkor biztosan nehéz.
pl. az említett 64MB-s xml-ből kell kikeresned egy olyan node-ot, aminek adott a szülője, a nagyszülője és valamilyen attribútuma egy bizonyos feltételnek felel meg. Ezt grep-pel, ha megfeszülnék se tudnám leírni, főleg nem reggel, álmosan! :-)
A fenti xpath-szal nagyon egyszerű.

Vegyünk egy konkrét példát, a szegedi időjárást. Szeretném megtudni, hogy lesz-e az előrejelzésben 20 foknál nagyobb hőmérséklet.

wget -O - "http://weather.yahooapis.com/forecastrss?w=815498&u=c" | xpath -q -e "//channel/item/yweather:forecast[@high>20]"

Magyarázat, azon node-ot keresem, aminek a neve "yweather:forecast", van egy "item" nevű szülője, annak egy "channel" nevű szülője és a "high" nevű attribútuma 20-nál nagyobb.

Az XML lényege, hogy strukturált, és emiatt könnyű benne keresni, bármilyen nagy is legyen.

Szulo, nagyszulo, dedszulo... Alom-alom, edes alom, nincs is jobb kerek e vilagon.

Nekem olyan feladataim szoktak lenni, hogy keress olyan uzenetsorokat, amiben arrol esik szo, hogy a backup megdoglott, es ird ki ezek idopontjait. XML-nel 1) jo esellyel total mas taget kell kiirni, mint amire keresek, 2) nem tudom, hogy mennyire lehet szavakat keresni egy hosszabb szovegezesu text tagben. Es nem, nem segit az, ha kiiratom az osszes olyan uzenetet, aminek a forrasa a "backup" volt.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Hadd kerdezzem meg: mennyire egyszeru az a kifejezes, ami ilyent csinal? Es mennyi XPath-tal valo szorakozas utan lehet azt mondani, hogy "nagyon egyszeru"?
Attol, mert valaki tud XPath-ul, meg nem biztos, hogy jartas is benne.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ha strukturált amiben keresni kell, akkor az megkönnyíti a dolgokat, nem megnehezíti.
Pl. <error modul="backup" time="2010.03.25 12:43:12" message="Fatal error!"> Sok soros leírás </error>

1) Tudja ezt, sőt jobban, mint a grep. Ebben könnyű keresni bármelyik adatra, és nem kell azt az adatát kiírni. Pont a grep-nél vannak nehézségek, ha megtalálsz valamit, akkor csak a környezetét tudod kiíratni. A grepnél az összefüggések leírása már nehézkes, ha az nem egy sorban van.

2) Könnyen contains fv. segítségével.

Pl. A fenti error-ban keresünk egy szöveget ('Fred') a "Sok soros leírásban", majd írassuk ki az időket:
//error[contains(text(),'Fred')]/@time

Ezt grep-pel mutasd meg légy szíves, hogyan csinálnád?

Ez volt az egyszerubb eset. Azonban nem minden xml ilyen egyszeru, en lattam mar szornyedelmeket is, ahol a datum a nagybatyja volt az uzenetnek. (Mas volt a konkret esetben, de maradjunk a peldanal).
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A text formatumu lognal ez ugy nez ki, hogy "grep 'backup error' backup.log | cut -d' ' -f 2-5"

Epp azert kerdeztem az XML-esre, mert az XML formatum egyik hibajanak tartom, hogy nehezkesebb benne keresni. Mint kiderult, ez igaz is, meg nem is. Vannak eszkozok a kereseshez (legalabb...), viszont a keresokifejezes irasahoz az embernek foglalkozni kell az XPath-tal is, csak a formatum ismerete keves. Arra akartam ravilagitani, hogy szoveges log eseteben van annyi konnyebbseg, hogy nem feltetlenul kell tudnod regexp kifejezeseket irnod ahhoz, hogy egyszeru szoveges kereseseket tudj vegrehajtani egy szoveges dokumentumban. A grep ugyanis minden teketoria nelkul fogadja el a siman bepottyentett szoveget, meg a contains(text(),...) sem kell hozza.

Azt sosem allitottam, hogy az XML-ben is greppel kellene keresni (bar, mint kiderult, nyilvan lehet, hiszen egy adott csomopont valoszinuleg adott szamu sorral van a talalat folott, a felesleges sorok kiszurese pedig mar egy masik, formazo kifejezes resze), sot, ha tehetem, en inkabb elkerulom az XML pure kihanyasat a logokba.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Kimentik fajlba, elkuldik levelben, meg par darabbol grafikont csinalnak. Ebbol egyedul az utolsot nem tudom kezzel megcsinalni.
Bocs, biztos jok ezek az automata toolok, de en nem szeretem oket. Max azt tudom elkepzelni, hogy a statjaikat/elemzett logjaikat tegyek ki valahova, ahol meg tudom nezni oket, de alapvetoen en nem szeretem a mukodo rendszert piszkalni. Vannak ilyen averzioim sajnos.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Van a CORBA-nak referenciaimplementacioja? Sajnos nincs, ahany implementacio, annyira kulonbozo viselkedesek sajnos. Egy platformon belul jo objektumcserere, de platformok kozott (szoftverfejlesztesi platformok, nem CPU-architekturak vagy OS-ek) mar nem annyira. A protobuf es a Thrift pedig multiplatform, referenciaimplementacioval.

mindjart szolok az altalunk fejlesztett (pure java, szerveroldalon) monitoring cuccnak, hogy hasznaljon tobb cput, meg memoriat, mert allitolag ugy kell neki mukodnie ;)
fyi, ma mar mindenre van lightweight megoldas. nemkell appszerver, csak egy servlet container? jetty/grizzly. aztan azt raksz bele amit akarsz, lego az egesz.
a loggingot be lehet konfiguralni, engem sosem zavart, hogy eltunik 5g logra, mikor egy kis szerverbe is belemegy 4db 300g -s diszk.

szerinted mi a dragabb: az en ordijam, amit azzal toltok, hogy langyos vizben sajtreszelovel verjem amig c/c++ban lefejlesztem ugyanezt, vagy venni meg xgb memot, meg x procit?

szerinted mi a dragabb: az en ordijam, amit azzal toltok, hogy ... c/c++ban lefejlesztem ugyanezt, vagy venni meg xgb memot, meg x procit?

Amennyiben a nagyi befottes uvegei koze dugott szerveredrol van szo, biztosan olcsobb a hardver (bar az oradijadat nem ismerem) viszont, ha a szoftver nem csak egy darab szerveren fut, a koltseg eleg gyorsan megugorhat, nem? ;)

Hat igen...a facebooknal egyes forrasok szerint 30E szerver van, kb 700M felhasznalora, szerverenkent 23E ezer felhasznalo atlagosan. Az iWiW-nel meg a legutolso altalam ismert adatkozleskor volt kb. 3M felhasznalo 24 db szerverre, azaz 125E felhasznalo egy szerveren. Lasd itt: http://iwiw.blog.hu/2006/02/10/technologia es itt: http://www.datacenterknowledge.com/archives/2009/10/13/facebook-now-has…

Persze, de a felhasznaloszam es szolgaltatasok mennyisege is valtozott, bar nem hinnem, hogy 4-5-od reszere esett volna vissza az egy szerverre juto felhasznaloszam. Masreszt ez egy olyan mutato, ami mond valamit, de sokat nem arul el, facebookeknal pl. volt olyan, hogy 1800 MySQL server, 10E web frontend, meg 805 memcahced szerver. Tehat osszessegeben volt kb 12E szerveruk, es annak tulnyomo resze web frontent. Jo lenne latni a pontos architekturat, hogy jobban ossze lehessen hasonlitani oket. Na meg nem mindegy, hogy azok a hardverek milyenek, ha megnezed, az iWiW hardverei mar a maguk koraban (4 evvel ezelott) se igazan voltak csucshardverek, viszont legalabb volt THC szerveurk is :)

A helyzet az, hogy a 2006-os szerverekhez képest darabszámban nem több, hanem kevesebb szokott kelleni, még annak ellenére is, hogy közben nőtt a terhelés.
2006-ban jelentek meg a két magos Opteronok 90nm-en...

suckIT szopás minden nap! A fájlokat tömörítsük, vagy a fájlrendszert?

Pedig milyen jó lenne valami "eat my cpu" alkalmazást futtatni, a facebook cpu idejét pedig pénzért továbbértékesíteni...
Send a spam alkalmazás is lehetne, mindenki kapna tízezred fillért minden elküldött spamért.

suckIT szopás minden nap! A fájlokat tömörítsük, vagy a fájlrendszert?

"Az iWiW-nel meg a legutolso altalam ismert adatkozleskor volt kb. 3M felhasznalo 24 db szerverre"

Ehhez képest már 2007-ben is kb. 100 szerverrel dolgoztak: 


1	Hardveres load balancer
61	Alkalmazás szerver (Tomcat + lighttpd)
8	Image storage szerver
7	Image/thumbnail reverse proxy szerver
4	Object cache szerver (memcached)
5	WIWD szerver („Legrövidebb út”)
1	Üzenet-adatbázis szerver (Oracle)
5	Adatbázis szerver (Oracle RAC)
3	Adminisztratív szerver

Forrás: iWiW Problémák és megoldások

A felhasználók száma pedig a ppt szerint 2,5 millió volt 2007-ben.

Nem akarok megesküdni, mert sör is fogyott ott, de mintha úgy emlékeznék, hogy egy forrás 2008 nyarán azt állította, hogy 100 felett vannak a szerverszámban.

--
trey @ gépház

aha. ha javaban kezdtek volna, akkor most irnak at c++ -ba. vagy egy uj, gyorsabb java forditot... szoval azert valamit kodoltak na :D
csak arra szerettem volna ramutatni, hogy ok talan kiszamoltak, hogy hosszutavon olcsobb a szoftveresek munkadija, mint a szolgaltatas alatolni ujabb vasakat.

Nem látom, hogy kitől és mit kaptam volna meg... De felvettem a szótáramba a javafan kifejezést, akik ugyanúgy védik a jávát, mint maserati tulajdonosok az apple-t...

A fentebb leírt hsz-ekkel az a baj, hogy én nem mondtam olyat, hogy a jávának semmi előnye nincs, sőt, az előnyökről még utalás szintjén sem esett szó. A jáva nagyon sok tulajdonságából kettőt emeltem ki, és utána írtam egy smileyt. Ez utóbbi tény a csak írástudók (olvasni nem tudók) figyelmét elkerülte.

"akik ugyanúgy védik a jávát, mint maserati tulajdonosok az apple-t..."

személyeskedsz?
vagy egyébként mi köze van a maseratinak az apple-hoz?
na látod, ez a trollkodás!

érvekkel mondj ellent a többiek állításainak, esetleg mérésekkel, dokumentációkkal megtámogatva, ne pedig érzelmi alapon, amihez hozzákeversz engem - pedig meg sem szólaltam ebben a szálban -, meg a kocsimat.
nem is értem, hogy én, és a kocsim, meg az apple hogy jövünk ebbe a szálba?!

annyira, hogy lássam az erőforrás felhasználását, annyira biztosan.

És láttál-e azonos teljesítményt nyújtó, de kevesebb erőforrást igénylő terméket? Ha igen, melyik volt és milyen területen? Konkrét példákat szeretnék. Vegyük elő ismét a méréseket, amikor kiderült, hogy a Java vs. C/C++ implementáció közel azonos erőforrás igényt jelentett?

http://hup.hu/cikkek/20090517/az_androidra_alapozza_a_jovot_az_amerikai…

de ettől függetlenül, elég megnézni a specifikációkat, hogy lásd, nem takarékosság volt a cél. adatbázison jdbc réteg, azon rowset, azon dataprovider (ha csak woodstockot nézed), másik irányból hibernate, jpa, mindenféle varázsszavak, minden xml-ben megy, mert a jáva fanok atombombánál kisebbet még szúnyogra sem bírnak dobni...

Mi az ultimate megoldás szerinted? :)

nézz meg egy glassfish server.log-ot, ha az nem szószátyár, akkor mi az? Az a kisebbik, hogy kis terhelésű szerveren is secperc alatt eltűnik 4-5 giga diszk a logok miatt, de mire megtalálod benne, hogy mi baja volt...

Ki lehet kapcsolni, illetve be lehet állítani a részletességet. Nálam alapszinten egy sor kerül a logba egy kérés kiszolgálásához. Az apache log sokkal többet hízik. De ha hibát kell keresni, akkor átírom menet közben a hiba útján a loglevelt INFO-ról TRACE-re és megtalálom a hibát. Bár ehhez értelmesen kell naplózni, ami nem nyelv specifikus.

mindenre van szabvány, mire átlátod, nem csak a hardver procit és memóriát, de a szoftver procit is kisámfázod...

Mintpéldául? Nézzünk egy JBoss AS példányt. A "minden lehetséges funkció bekapcsolva" (vagyis cluster, session replikáció, JMS replikáció, szinkronizált és elosztott JPA cache, stb) konfiguráció egy telepített portállal (JavaForum2.0) eszik 78M PermGen és 229M heap memóriát. Egy Drupal eszik 0M memóriát telepítés és elindítás után. Nézzük munka közben. Terheljük meg egy szálon mindkettőt (itt a laptopomon a másik laptopról mérve):
Drupal welcome oldal: 17,2 req/sec
javaforum.hu Rólunk oldal (laptopon!): 18,6 req/sec, 80M PermGen és 240M heap, 100% CPU

Nos, eresszünk rá 1000 szálacskát: 


-/+ buffers/cache:    2001484    2055976
Swap:      4200956     273164    3927792                                 
linux-cp5o:~ # rcapache2 start
-/+ buffers/cache:    2005508    2051952
Swap:      4200956     273160    3927796

Drupal welcome oldal: 17,3 req/sec, 3,17% hiba 


-/+ buffers/cache:    3338964     718496
Swap:      4200956    1146708    3054248
linux-cp5o:~ # rcapache2 stop
-/+ buffers/cache:    1338236    2719224
Swap:      4200956    1145280    3055676

Hm... mintha eltűnt volna 2G memória valahol, csak nem az Apache zabálta meg? És ráadásul fel se szabadította 15 perc múlva a kérések kiszolgálása után. Hm.

Nézzük a JavaEE technológiát, 1000 szál hasonló körülmények: 


-/+ buffers/cache:    1383352    2674108
Swap:      4200956     854736    3346220

javaforum.hu "Rólunk" oldal: 16,2 req/sec, 0.00% hiba, 82M PermGen és 330M heap 


-/+ buffers/cache:    1495800    2561660
Swap:      4200956     850144    3350812

Hmm.. nagyjából 100M-110M memória tűnt el, ott van az alkalmazás szervernél, teli connection pool és cache formájában. Ha kell, JMX hívással le lehet csökkenteni, de idővel leépíti az alkalmazás szerver is, csak nem azonnal, tudom mikor, mert én állítottam be ezeket a paramétereket. Az Apache is talán megteszi ezt, nem láttam rá beállítási lehetőségeket.

nem akarok az előnyeiről vitatkozni, nyilván vannak olyanok, de a proci meg a memória felhasználás biztosan nincs közöttük.

Ahja. Lehet C/C++ nyelven is portál írni, még nem láttam ilyet, de biztos van. Lehet PHP-ban és lehet Python-ban is, de ahogy a mellékelt mérés mutatja, egyátalán nem biztos, hogy a JavaEE (JPA, EJB, WebService, stb.) akkora hátrányt jelent. Sőt.

én meg azt bírom, amikor valakinek annyi az érve, hogy mer úgy van, PONT.

Örömmel vennék ezek után tőled is _mérési_ eredményeket, nem véleményt, illetve "elég megnézni a specifikációkat", illetve "a jáva fanok atombombánál"... ésatöbbi.
--
http://wiki.javaforum.hu/display/FREEBSD

"Mi az ultimate megoldás szerinted? :)" hagy válaszoljak csak erre az egy kérdésre. *Szerintem* az ultimate megoldás az, hogy az ember összeszedi a pro meg kontra érveket, ami neki előny vagy neki hátrány, azt figyelembe veszi, a többire magasról tesz:)))

A jávának vannak fejlesztői/programozó oldali előnyei, amiért cserébe a megrendelő drágább hardvert fog kifizetni. Persze lehet, hogy az egész összességében nem drágább, mert kevesebbe kerül a szoftver fejlesztése, mint amennyivel drágább a hardver, ez már helyzetfüggő.

A jávának vannak fejlesztői/programozó oldali előnyei, amiért cserébe a megrendelő drágább hardvert fog kifizetni. Persze lehet, hogy az egész összességében nem drágább, mert kevesebbe kerül a szoftver fejlesztése, mint amennyivel drágább a hardver, ez már helyzetfüggő.

Értem. A francnak mérek és írok belőle regényt, ha figyelmen kívül hagyod, mert nem illik a világképedbe.
--
http://wiki.javaforum.hu/display/FREEBSD

nem akarok az előnyeiről vitatkozni, nyilván vannak olyanok, de a proci meg a memória felhasználás biztosan nincs közöttük.

Ebben a mondatban hol a smiley? Trükkösen elrejtetted? Mert nekem úgy tűnik, hogy az idézett hozzászólásod komoly volt. Ránézésre annak szántad, abban a tudatban, hogy megalapozott tényt közöltél. Amikor kimértem, hogy például egy Java alapú portál terhelés alatt* kevesebb erőforrásból is megél, mint egy hasonló tudású népszerű PHP portál, akkor megsértődsz (tipikus példája a kognitív disszonanciának :).

*terhelés alatt: valahogy úgy vettem észre, hogy a rendszergazdák és az üzemeltetők nem szeretik, ha terhelik azt a rendszert, amit üzemeltetniük kell. Ha rajtuk múlna, akkor kihúznák a hálózatból és egész nap simogatnák a szervereket, meg ódákat írnának a "0,00" load emlékére.
--
http://wiki.javaforum.hu/display/FREEBSD

Ez a sor volt a vitát kiváltó hozzászólásom? Nem ez volt, ezt mi sem bizonyítja jobban, minthogy nem ez a hsz váltotta ki többek ellenvéleményét.

Ez: http://hup.hu/node/84779#comment-985224 volt a vitát kiváltó hozzászólásom, ezt meg az bizonyítja, hogy ez van legelöl a vitatkozós althreadben.

van benne smiley? van, tripla vigyorgás. de idézem neked, nehogy megint lemaradjon:
"memóriát, procit biztosan :)))"

Az a kettőspont meg a három zárójel, az a smiley. Ennek tükrében az, hogy itt kapaszkodsz a jávádba kb. annyira nem helytálló, mintha Hofitól minden kabaréjához KSH kimutatást kértél volna.

Ez nem a kognitív disszonancia, hanem funkcionális analfabétizmus, de ez nem nálam játszik.

Jajjmár, olvastam azt, amit Te vitaindítónak gondolsz. Aztán írtál még három személyeskedő, meg még kettő komolynak tűnő -- már-már mélyenszántó elemzést arról, hogy milyen szar a Java CPU és memória tekintetében - lehet, hogy utólag már letagadnád, de attól még megírtad. Egyik mögött se volt mosoly, s ezek után meg én vagyok a funkcionális analfabéta.

Én kérek elnézést.
--
http://wiki.javaforum.hu/display/FREEBSD

"amiért cserébe a megrendelő drágább hardvert fog kifizetni."
A gond az, hogy ugy gondolod, ez egyenes kovetkezmenye annak, hogy a megoldas Java nyelven irodott, holott a keplet nem ennyire egyszeru. Nagyon sok fugg a programozotol, es a megoldas jellegetol is, csak ezek egyuttes ismereteben lehet barmi ilyesmit nyilatkozni. Lehet, hogy adott megoldas egyebkent C++-ban megirva se igenyelne sokkal-sokkal kisebb hardvert, mert mondjuk eleve eroforrasigenyes feladatrol beszelunk. Szoval, elsosorban azon kellene elgondolkodni, mennyire van ertelme sommas kijelenteseket mondani egy olyan temaval kapcsolatban, ami baromi sok tenyezotol fugg.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Minek eresztunk ra ezer szalat amikor nyilvanvaloan elfogadhato kesleltetessel egyik sem tud kiszolgalni 20 szalnal tobbet ?
Tipikus nagy terhelesnek modhato az 5 oldal lekeres /sec (Az tobb requestet jelent). 432_000 oldal per nap.
2 sec es oldal letoltesi ido alatt nevezuk elfogadhatonak a latencyt altalaban. Ez az internet atlaga is.

Nagyon erdekes szamdaralasban hasonlitani java / C -t. Itt valoban jo teljesitmenyt nyujt a java. De egy tipikus EE web alkazmasnal nem a szamdaralasi kepesseg lesz a mervado, hanem az alkalmazott technologiak milyensege alacsonyabb szinten. Nem kotelezo hasznalni oket, de amiket altalaban hasznalnak azt nem a sebbeseguk miatt valasztottak.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Minek eresztunk ra ezer szalat amikor nyilvanvaloan elfogadhato kesleltetessel egyik sem tud kiszolgalni 20 szalnal tobbet ?

Nyilván egy core esetén nem tud többet. De például 32 core esetén már 640 szálnál tartunk és még csak egy gépről van szó.

Tipikus nagy terhelesnek modhato az 5 oldal lekeres /sec (Az tobb requestet jelent). 432_000 oldal per nap.

Neked lehet, hogy ez már nagy terhelés. Nekem a 200-300 PI/sec az, amikor már azt mondom, hogy átlagos terhelés van... ha ehhez hozzávesszük a különféle egyéb embedded tartalmak letöltést, akkor már lazán 2-4e szálnál tartunk. :)

De egy tipikus EE web alkazmasnal nem a szamdaralasi kepesseg lesz a mervado, hanem az alkalmazott technologiak milyensege alacsonyabb szinten. Nem kotelezo hasznalni oket, de amiket altalaban hasznalnak azt nem a sebbeseguk miatt valasztottak.

A fenti példában a JavaEE web alkalmazásnál mindenféle keretrendszer benne van, ami JavaEE esetén szóba jön. Így hozza a fenti számokat.
--
http://wiki.javaforum.hu/display/FREEBSD

FIXME: En akarhogy is nezem az interneten feleleheto adatokat, de pl. egy index.hu / origo.hu forgalma sem tunik nagysagrenddel nagyobnak. Van errol valami konkeret adat valahol ?

"De egy tipikus EE web alkazmasnal nem a szamdaralasi kepesseg lesz a mervado,"
"A fenti példában a JavaEE web alkalmazásnál mindenféle keretrendszer benne van, ami JavaEE esetén szóba jön. Így hozza a fenti számokat."
A szamdaralos linkedre gondoltam. FYI: Itt a javas portalhoz hasonlo sebessegeunek tuno (extrak nelkuli) php , szamadralasban is legalabb 8 szor lasabb, mint a C/C++ a java meg kb. egyenlo. Erdekes ugye.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

FIXME: En akarhogy is nezem az interneten feleleheto adatokat, de pl. egy index.hu / origo.hu forgalma sem tunik nagysagrenddel nagyobnak. Van errol valami konkeret adat valahol ?

A webaudit.hu jó lehet kiindulásnak.

FYI: Itt a javas portalhoz hasonlo sebessegeunek tuno (extrak nelkuli) php , szamadralasban is legalabb 8 szor lasabb, mint a C/C++ a java meg kb. egyenlo. Erdekes ugye.

Ezt elolvastam ötször, de akkor sem értem.
--
http://wiki.javaforum.hu/display/FREEBSD

Kosz linket. Valoban nagyobb a forgalmuk, mint ahogy kulfoldi oldalak alapjan latszott.
5 /sec az hvg.hu koruli dolog ami magyar viszonylatban eleg nagynak szamit.

Arrol beszelek, hogy az emberek gyakran hozzak fel, hogy java olyan gyors, mint C/C++ szamolgatos benchmarkokon. Ezeken rendszerint C szeru kodot irnak javaban. Ez valoban lenyukozo.
Ugyan ezeken szamolgatos benchmarkokon php 8 szor rosszabb legalabb, mint a java.

A mostani teszten complex portal kiszolgalasban az az elony sehol nem latszik, 20% alatti elterest lattunk.
Az en gepemen alap beallitasok szerint hello.php vs. hello servlet eseten 1.5 szer tobbet szolgalt ki a tomcat, mint a php, mikozban a php 1.8 szor tobb processzort evet. (100 szal terheles, 5000-8000 response/sec) Latency 12ms vs. 20ms a java javara.

Kiindulasi helyzetben lathato, hogy java servlet koncepcionak hatalmas elonye van. A vegen megsem mindig latszik. (php cumok meg tovabb gyorsithatok, mindenfele eloforditas cachelesel ..stb)
Bonyolodassal ha csak azt tudom, hogy JVM vs. php interpreter jatszik akkor arra fogadnek, hogy ez az elony tovabb no. De nem igy szokott lenne. A csoda technlogiak amiket meg hozza illesztenek nem a sebessegrol / memoria hatekonysagrol hiresek.

php bonyultabb rendszereknel lathatova valhat egy tovabbi bunteto. Neki minden requestnel ujra kell epitenie a vilagot. Szoktak itt mondani, hogy php csak a egy template engine.
Jol tervezett java megoldasnal itt megint durvan ra lehetne verni a php-ra.
php esetben, ha vilag ujra epitese nem jarhato ut egy kulonalo C/C++ server/agent szokott besegiteni, vagy DB-n keresztul ad infokat. Vagy pl. SOAP -oznak.

Memoria nalam egesz maskep alakult. mod_php hasznalok. Apache forkolta magat (az szinte ingyen van) es alig evett memoriat (33Mb).
Tomcat sok sok teszt utan felment 546Mb residensre. Kikenyszeritettem gc-t (JMX/jconsole) be is gyujtotte a szemetet, de az OS nem kapta vissza a memoriat (commited ertek maradt). Nem szokta. Es ez normalis.
Szinte egytelen memoria foglalas strategianak sem resze az "OS kapja vissza" az apro memoria darabkakat. Draga vissza adni es ujra elkerni. Nem veletlen, hogy java-s szervereknel minimum beallitott lefoglalando heap, rogton ugyan-annyi, mint a maximum.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ugyan ezeken szamolgatos benchmarkokon php 8 szor rosszabb legalabb, mint a java.

Igen, a PHP nem számolgatásokra való. Nem arra találták ki.

A mostani teszten complex portal kiszolgalasban az az elony sehol nem latszik, 20% alatti elterest lattunk.

Igen. Mert a Java oldal kicsit többet tudott, ahogy írtam volt: cluster, session replikáció, JMS replikáció, szinkronizált és elosztott JPA cache, stb; ezek levesznek a teljesítményből, és a PHP platform pont ezeken a területeken kezd sűrű dagonyává válni, amelyben nehéz haladni. Nem tudtam ezeket kivenni a portálból, s nem találtam olyan (ingyenes) PHP portált, amely ezeket tudta volna.

Kiindulasi helyzetben lathato, hogy java servlet koncepcionak hatalmas elonye van. A vegen megsem mindig latszik. (php cumok meg tovabb gyorsithatok, mindenfele eloforditas cachelesel ..stb)

Annyira nem rossz a mod_php, a HipHip "JIT" is csak ötszörös gyorsulást tud szélsőséges esetben, átlagosan kétszeres az előnye.
--
http://wiki.javaforum.hu/display/FREEBSD

"Igen. Mert a Java oldal kicsit többet tudott, ahogy írtam volt: cluster, session replikáció, JMS replikáció, szinkronizált és elosztott JPA cache, stb; ezek levesznek a "
Amig egy node van csak, addig nem sokat szamitanak (indulasi idoben persze szamit). Jboss IMHO eleg jo cluster architecturaval rendelkezik, foleg kisebb clustereknel 4<. Nagyobaknal inkabb management kerdesek merulhetnek fel, mintsem teljesitmeny beli.

Erdekes, hogy JPA cache hatranynak tekinted. Most szerintem kifejezetten elonyt jelenthetet leven "cache". Okosan tervezve a hasznalatat meg tobb elonyt is lehet kovacsolni belole. Van nemi reflection magia benne , de ha nem hozod letre allandoan azt amit megtarthatnal akkor meg tobbet is nyerhetsz vele. (gyakori hiba)
Prepered statement is alkalmazhato az implementacioban, amivel megint php fele lehet kerulni.
php -nal egy memcached minimum kell, hogyha cachelni akarunk.

JAVA's csoda dolgokban gyakroi performnce gyilkos, a szuksegtelen serilizatio/deserilizacio ugyan azon JVM -en belul. (Rendszerint elkerulheto lenne, de ki latja felul, hogy mi van alul ?)
Masik dolog, szinten belul hasznalnak a componesek mondjuk XML-t adatcserere.

java nem teszi kotelezove, hogy igy keljen elni, de gyakorlatban sokat lat az ember ilyesmit.

"PHP platform pont ezeken a területeken kezd sűrű dagonyává válni"
Mert nem igy erdemes hasznalni :) Ne akarjunk, a szamarbol lovat csinalni.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Amig egy node van csak, addig nem sokat szamitanak (indulasi idoben persze szamit).

Mértél ilyet, vagy csak mondod? :)

Erdekes, hogy JPA cache hatranynak tekinted.

Magát a JPA-t tekintettem annak egy követlenül csak és kizárólag MySQL/PgSQL adatbázisra felkészített PHP portálhoz képest. Az elosztott JPA cache továbbra is hátrány egy node mérése esetén. Egyszerűen olyan kódrészleteket használ, amelyet nem kellene egy node esetén, de használnia kell, mert bármikor jöhet egy újabb node. Ilyen például az EclipseLink JMS topic-on keresztül való L2 cache szinkronizációja, gyönyörűen látszik, hogy egyedül is használja.

JAVA's csoda dolgokban gyakroi performnce gyilkos, a szuksegtelen serilizatio/deserilizacio ugyan azon JVM -en belul.

Van remote EJB réteg, a terhelés elosztása okán, de JBoss okos annyira, hogy InVM nem serializál, de ez is okoz némi plusz futásidőt. Van minden metódusra TRACE log, ésatöbbi, ezek is vesznek el időt, ha nem is sokat.
--
http://wiki.javaforum.hu/display/FREEBSD

Tudatlansagom reven en a dolgokat kisse egyszerubben latom.

Eloszor is, majdnem minden nagyobb PHP alapu webalkalmazas felepiti a sajat perzisztencia reteget, ami vagy jobb, vagy nem jobb annal, mintha lenne egy standard perzisztencia megoldas. Szoval az overhead ott is megvan, annyi kulonbseggel, hogy PHP eseten egyaltalan nem divat felkeszulni a clusterezett hasznaaltra, mig Java eseten ez alapveto.

Masfelol a JPA annyiban jo, hogy viszonylag konstans terhelese van, lehet vele szamolni. Egy ismeretlen implementacioju perzisztencia frameworkot kulon le kell meregetni, es nem is biztos, hogy ott nem talalkozol felesleges koddal.

Egyebkent pedig nem gondolom, hogy a JPA-nak tudnia kell, hogy o most eppen hany node-s kornyezetben fut, egyszeruen azert, mert ez nem az o hataskore. Igy viszont nehez egy, ket, negy, tiz node-s kornyezetekre optimalizalni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Egyebkent pedig nem gondolom, hogy a JPA-nak tudnia kell, hogy o most eppen hany node-s kornyezetben fut, egyszeruen azert, mert ez nem az o hataskore. Igy viszont nehez egy, ket, negy, tiz node-s kornyezetekre optimalizalni.

Valóban, a JPA-nak nem kell tudnia, hogy hány node van bekötve. A gond akkor kezdődik, amikor akarsz cache-t használni. Ugyanis ha nincs cache coordination, akkor a node-ok nem tudják egymás módosításait, így előfordulhat, hogy az egyik node módosít egy entitást, majd perzisztálja azt és erről nem tud a többi node, azok a cache-ből még a régi tartalmat mutatják. A cache coordination pedig nem egyszerű dolog, erőforrást igényel, illetve indololt esetben szinkronizációt és várakozást.
--
http://wiki.javaforum.hu/display/FREEBSD

Ha már teljesítményvita. Én egyáltalán nem vitázni akarok, csak java-ban látom otthon vagy. Írtam egy kódot (C-ben, lényegében FFT), Maga a kód nem túl hosszú. Annyit csinál, hogy egy képet a megadott paraméterekkel, mint hologrammot rekonstruál (max 8192*8192 méretű double pontosságú képpel próbáltam). A lényegbe nem megyek bele, de komplex számok szorzása osztása + fourier transzformáció...... Na ha nagyon szépen megkérnélek, azt átírva java-ra, tudnál mondani, egy rekonstrukciós időt? Ha ok előkeresem a C-kódot. Én java-hoz totál dilettáns vagyok. Legalább lenne egy "objektív" proci-terhelős nagyon matekos teszt is.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Ez pont egy CPU izzasztó C vs. Java mérés volt:
http://hup.hu/cikkek/20090517/az_androidra_alapozza_a_jovot_az_amerikai…

Nem biztos, hogy arra akarok időt szakítani, hogy átgondoltan és teljesítményre optimalizálva portoljak Java-ra C programokat egész addig, amíg egyszercsak lassabb nem lesz a Java port... :)

Ps.:

Sámsonról elterjed a hír, hogy buzi. Mikor a fülébe jut, nagyon ideges lesz. Kihirdeti, hogy vasárnap az arénában 1000 nõt tesz magáévá. Eljön a vasárnap, megvan az 1000 nő, és megtelik az aréna nézőkkel. Sámson nekilát. 500-ig simán bírja. 600-nál piheg. 700-nál kezd kifulladni. 800-nál remeg a lába. 923-nál elájul.
A tömeg őrjöngése 1 percre abbamarad, majd skandálni kezdik:
BUZI!!! BUZI!!!

--
http://wiki.javaforum.hu/display/FREEBSD

Mint már említettem, egyáltalán nem kötekedni akartam. Azért gondoltam egy ilyesmire, mert már annyi benchmarkot dugtak az orraom alá, hogy ez jobb vagy az jobb (ami szerintem marhaság, hogy melyik....), amikor gyak sorról sorra portoltak kódokat a-nyelvből b-be, de oda vissza teljesen átgondolatlanul. Így eddig azt tudtam megállapőítani, hogy a rosszul portolt C-kódtól, az általam megítélhetelten módon portolt java program gyakran kissebb-nagyobb mértékben gyorsabb vagy lassabb. Azért gondoltam, hogy két nem sorról sorra portolt, hanem funkcionálisan portolt kódot kellene összehasonlítani, na mindegy.

Sámsonról röviden annyit. Egyértelműen túlvállata magát :D, etalonként tette ki, hogy 1000-alatt ..... Tehát..... :D

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Egy napja regisztrált felhasználó, no profile info, csak ide szólt hozzá... haha :)

Én vállalom a nevem, vállalom a munkám, többek között azt is, hogy én már hasonlítottam össze C++ és Java apróságokat reprodukálhatóan ismételhető módon. Minimum ennyit elvárok azzal szemben, aki vitatkozni próbál. Jah igen, bővebben itt és itt.

Sosem tudott erdekelni a forumokba valo picsogas mennyisege es a szakmai mult melldongetese, most sem fog. Az, hogy java (plane 1.4) program 3-4x gyorsabb, mint a vele _ekvivalens_ C program, az (joindulatot feltetelezve) eros csusztatas. Az ekvivalens C programot tessek ugy ertelmezni, ahogy a te altalad linkelt oldalok is teszik, melyek sokkal finomabban bannak az olyan kovetkeztetesekkel, amiket te sugalltal a linkeddel. Attol, hogy ebbol elsz, meg nem muszaj neked vinni a java zaszlojat.

Ha a 'minden'-t szo szerint ertetted, akkor hulyeseget irtal. :) Nezz londoni allashirdeteseket: a C++ mindent visz. Ipartol fugg ugyanis -- a Java meg mindig nem a realtime kereskedesekre van tervezve, peldaul.

----------------------
while (!sleep) sheep++;

En ezt igy Londonbol egy financial services ceg belsejebol nem igazan latom igy.

1. Szerintem inkabb a Java/.NET dominal a befektetesi bankokban es egyeb financial services (trading, spread betting, stb.) cegeknel.
2. Ahol lehet, mi pl. igyekszunk atterni a C/C++-rol a Java-ra, siman azert mert a Java sokkal stabilabb, robusztusabb, sokkal jobban skalazhato horizontalisan (mutass nekem legy szives egy C/C++ alapu uzleti termek minosegu data gridet).

Ahol millisec-eket kell lefarigcsalni, ott szamithat a C++, de sajnos ott pedig a skalazhatosag az felejtheto (egy bizonyos hataron tul nem tudod a memoriat/cpu-kat boviteni). A parhuzamosithatosagnak, karbantarthatosagnak es a menedzselhetosegnek pedig a platform korlatai igencsak betesznek.

Ahol nagy mennyisegu adattal kell dolgozz es gyorsan, ott meg mindig a data gridek a nyerok, ez pedig leginkabb Java-t jelent jelenleg, esetleg kliens technologianak .NET es neha C++.

Udv,

Finrod

( eax | 2010. 03. 22., h – 00:08 )

"ugyan azt a megoldast javaban implementalva jobb penzert lehet eladni"

... mint?

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

A döntéshozók és az egyikhez sem hozzáértő de cégen belül fajsúlyos véleménnyel bírók fülében jobban cseng általában az, hogy Java, J2EE vagy egyéb varázsszavak, mint például a Python, Django stb. Pusztán azért, mert nagyobb az ismertsége, jobb a marketingje, elterjedtebb stb.
Ez nem technológiai előnyt jelent (de ugyanígy amit pl. gyorsabban lehet implementálni egy adott keretrendszerben az sem lesz feltétlenül "jobb", akármit is értsenek az illetékesek az ilyen összevetéseken), és egyébként is normális helyen igyekeznek kicsit utánajárni, majd rábízni a munkához értőkre a megoldást. Legfeljebb eleve úgy szűkítik az ajánlatkérést, hogy beleírják az elvárt dolgokat, rosszabb esetben hallomásos alapon...
Ezért még Ha nem foglalkoznál a technikai oldalával és a tengernyi lehetőségével, akkor is minimum megfontolandó megismerkedni vele.

( XMI | 2010. 03. 22., h – 02:44 )

Valoban jobb bevetelekre szamithat az ember, ha Javaban dolgozik, meg ha ez mas szempontokbol nem is lenne indokolt ?
Hát vannak olyan cégek ahol van ilyen jelenség, hogy a "JavaEE az igazi enterprise", de szerintem nem ez a gyakori. A legtöbb helyen ahol Javában fejlesztetnek, ott van is valami "más szempont", ami miatt indokolt. Igazából az a más szempont az, amiért több bevételre lehet számítani és nem maga a Java.
---
Internet Memetikai Tanszék

+1

És a "más szempont" kategóriában rengeteg apróság van, cégenként más és más. Akár a time to market, akár a biztonság (jójó, ezt is el lehet rontani ha valaki el akarja), akár csak az, hogy szükség esetén elég nagy a fejlesztői pool... És akkor a technológiai oldalt csak minimálisan érintettem.

Amit en velek a hatterben, hogy Java-hoz ertonek a programozok 60% -a valja magat.
Egy cegnel ahol mar eleve jelen van a java, celszeru lehet olyan eszkozoket valasztani amihez jo esellyel hozza tudnak szagolni odabent is. Ami persze nem feltetlen van igy, de ha CV -k ben es temek leirasban is megtalalhato a java szo management szinten lehet ilyesmit feltetelezni. Ilyen dontesekre lettek tanitva.

A masik dolag a "Java" szo suttogo marketingje az, hogy az nagyon vallalati dolog, es ez eljutott sok fulbe.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"suttogo marketingje"

Kezdek ignoráns lenni azokkal szemben, akik úgy vallják magukat szakértőknek, hogy igazából lövésük sincs arról, hogy mi a java. Vulgáris leszek: nesze b+, nézz körül itt, és mond azt, hogy igazából ez a Java csak kamu: http://java-source.net/

Ugyanis amit itt látsz, az mind open-source, és többnyire industry-ready cucc, amire kisebb-nagyobb cégek már rengeteg sikeres alkalmazást építettek. Ami jó, annak nem kell marketing... (szerk: na jó, ez utóbbi nem igaz, kell annak is marketing, de nem kell neki hamis marketing)

Lassuk, mi a java:

- Egy szigoruan tipusos osztaly-orientalt nyelv
- Egy meglehetosen szetb.ott economy (hany perzisztencia megoldas is van? Van meg olyan orult, aki a Sun altal hivatalosan nyomott Java EE-t hasznalja spring helyett?)
- A magyar egyetemek kozos oktatonyelve COP programozashoz
- Egy bukott platform a 90-es evekbol (az ugye megvan, hogy ennek a rendszernek a tervek szerint koze nem lett volna a szerverekhez? Mindenhez csak ahhoz nem)
- A Nyelv, Aminek Az a Reklamja, Hogy Multiplatform (mintha az osszes tobbi dinamikus nyelv - kiveve a .NET CLR alapuak egy resze - nem lenne az)
- Egy fejlesztoeszkozokkel eroteljesen tamogatott platform (anelkul bele is orulne mindenki)

Syntern, tul sok energiat oltel ebbe a nyelvbe, egyszeruen hulyesegeket mondasz.

Java mint legjobb Time-to-market?? Ezt statikus nyelvvel megis hogy? Az en szamaim finoman szolva nem ezt tamasztjak ala. Konkretan megakadnak projektek azert, mert a java mint nyelv olyan amilyen. Tobb eves csuszasokrol beszelunk, ha egyaltalan valaha is kesz lesz a feature!

Nem, jo time to marketje nem a javanak van, az az altalatok lenezett PHP, meg a ruby, a python.

Persze, kivetel ha csupa java gurubol all a teamed. Anno Paul Grahamek is LISP-eztek: azt ismertek ( http://www.paulgraham.com/avg.html ).

En megertem, ha valaki ezt a nyelvet ismeri leginkabb, es ragaszkodik hozza: rendben van. Azt is elismerem, hogy oriasi energiakat kell belefeccolni amire megerted az EJB 2.1 mukodeset (itt jeleznem: en megtettem, belefeccoltem ezt az energiat), vagy amire atlatod a rengeteg frameworkot, mikor melyiket kell hasznalni - az meg plane sok ido, mire megtanulod tenyleg hasznalni is oket.

En csak azt allitom, ez az energiabelefeccoles felesleges: a java mint nyelv bukott, kesz. Nincsenek benne meg azok a feature-ok, amik kenyelmesebbe teszik a programozast. Igen, kiveve az IDE tamogatast: villamgyorsan elozi be a tobbi nyelv, hidd el. (Meg mar a javasok se javat hasznalnak erre: Roo, grails - ezek nem javaul beszelnek)

A java es a .net parhuzamos bemutatasanak az a celja, hogy a delikvens kepes legyen elrugaszkodni az adott platformtol, es pusztan altalanos programozasi problemakban gondolkodni. Ez az, amit a kepzesunk meg mindig nem hangsulyoz elegge.

Nem kell hamis marketing? Hasznalsz meg J2EE -t? Jo volt az? Iszonyat marketing ment bele, most meg mivan: Spring MVC, ami egy ruby klon. Most abba, hogy az XML mennyire alkalmas konfiguracios nyelvnek meg siman nem mennek bele.

Vagy probalj valamit megirni Ext.JS-ben (vagy alkalmazasfuggoen jQuery + HTML/CSS-ben) natur, aztan utana hasznalj GWT-t. Szerintem meg fogsz lepodni: negyedannyi energia! De persze elotte meg kell ismerni a technologiakat: hogy a javascript prototipus orientalt, hogy az internet explorer-t kulon at kell kapcsolni standards modba, stb.

Szoval en ertem, hogy a java is your language of choice, de ettol ez meg jo nyelv nem lesz.

Es a trend azt mutatja, hogy szalad ki alolad a vonat.

te meg kicsit ugylatom, hogy elszalltal a dinamikus nyelvek kenyelmebe. en hanyok a dinamikus nyelvektol. igenis, a statikus tipusossag jo dolog.
masreszt miert emlegeted az EJB 2.1-et, mikor 3.1nel jarunk?
harmadreszt igen, en fejlesztek EE-ben. az 5 kiraly, a 6 meg megkiralyabb.

a trend meg azt mutatja, hogy meg lehet belole elni.

Hat aki szeret gepelni, az gepeljen :) Hogy ettol gyorsabban nem fog kodolni, az biztos (meg kodkiegeszitessel egyutt se).

A tapasztalat az, hogy keves az EE user, mert megse annyira kiraly, bar ezt sokan pont a 2.1-nek tulajdonitjak, hogy azota kerulik.

Bizonyos szint felett meg lehet elni dinamikus nyelvekbol is. A trend kerdese nem ez, a trend kerdese az, hogy meg lehet-e elni 10 ev mulva is a java mint egyetlen/fo nyelv ismeretebol. Az elemzok szerint - nem talalom az infoq cikket - nem.

EE 5 es 6 alatt az annotaciok miatt hatalmasat valtozott az EE platform, foleg ha meg a hozzaadott IDE tamogatast nezzuk...egy Db-re epulo CRUD-os webservice kiepitese 5 percnel tobbet nem vesz nagyon igenybe egy kismeretu projekt eseten, kb ugyanennyi klienst csinalni hozza. Es ez csak egy pelda volt. Az EE 5 es 6 minosegi feljodest hoztak az EE platformra, a 2.1-gyel osszehasonlitani kb az lenne, mintha Win95-ot es WinNT-t hasonlitanal ossze.

Kosz, tudom mi ez :)

De amikor a javasokat szabadjara engedem, hirtelen megjelennek mindenfele roo konyvtarak meg hibernate.jar, meg spring-mvc.jar, mindezt ugy, hogy az ukasz egy betartando WSDL-t es ket felhasznalando adattablat ir elo osszesen, azaz tolem azt hasznalnak, amit akarnak.

Ebbol - es a SpringSource jelenlegi piaci helyzetebol - kovetkeztetem azt, hogy nem volt annyira jo otlet a Java EE. Na meg vannak benne ordito marhasagok persze (kezdve mondjuk a Managed Beanekkel), amiket nem lehet pusztan annotacioval meguszni.

Tehát az embereid (khm) nem feltétlen a legjobbak vagy (khm) nem feltétlen a legjobb irányításuk van... mindkettő javítható, csak ne kiabáld tele ostobaságokkal a világot emiatt...

Amúgy a SpringSource piaci helyzetéből a Java-val kapcsolatban következtetni csak kicsivel jobb, mintha kecskevérből és békanyálból jósolnál...

Megvalami, ez fontos:

A tapasztalat, hogy az informatikai innovacionak legnagyobb ellensegei az informatikusok.

(Most egy kalap ala veszem a progmatosokat - computer scientist - meg a muinfosokat - information / software engineer -, elnezest.)

Tudod, hany evbe telt, mire embereket leszoktattunk a goto-rol? Pedig tok logikus.

Hany evbe telt, amire embereket raszoktattunk a magas szintu nyelvekre? Pedig tok logikus.

Hany evbe telt, mire az intel es az AMD elkezdett MIPS architekturaju procikat gyartani? Pedig tok logikus.

A java a 90-es evek kozepen szuletett, de a 80-as evek szellemisegeben: interpreter - akkor meg -, szigoru tipusossag, picit leegyszerusitett C++ - ami 15 evvel feltalalasa utan mar kelloen nepszeru volt - mig kortarsai - nincs tul sok idokulonbseg a php-ruby-python vilaggal am! - egy ennel vitathatoan eloremutatobb iranyt vettek fel.

Nem veletlenul nem terjedt el a simula vagy a smalltalk, helyette a c++ lett meno: tul nagy ugras lett volna a programozoknak. Ez nem jelenti azt, a smalltalk nem egy jo nyelv, vagy hogy nincs rovid - hadd idezzek, tetszik - time-to-market ideje: valojaban kortarsait nagysagrendekkel korozte le ebben a smalltalk.

A java egy batortalan lepes volt a C++-tol elszakadastol, es mint anno a c++, vagy kesobb a delphi, pont ettol lett nepszeru.

De mint ahogy c++ es delphi programokat se gyartunk mostanaban, nem hiszek abban, hogy fogunk java programokat gyartani 5 ev mulva - ekkora mertekben.

Sok mindennel egyetértek, inkább kiegészítenék:

Tudod, hany evbe telt, mire embereket leszoktattunk a goto-rol? Pedig tok logikus.
A goto C nyelvnél egy jól használható exception handling eszköz. Nyilván megfelelően szabályozva a használatát az adott projekt Coding Standards-ében. (Szigorú, automatizáltan ellenőrzött Coding Standards nélkül bármelyik nyelvvel lábon lövöd magad.)


A java a 90-es evek kozepen szuletett, de a 80-as evek szellemisegeben: interpreter - akkor meg -, szigoru tipusossag, picit leegyszerusitett C++ - ami 15 evvel feltalalasa utan mar kelloen nepszeru volt - mig kortarsai - nincs tul sok idokulonbseg a php-ruby-python vilaggal am! - egy ennel vitathatoan eloremutatobb iranyt vettek fel.

Szerintem nem feltétlenül elhibázott koncepció a szigorú típusosság, a Java _nyelv_ egyik legnagyobb előnye az, hogy egyszerűen analizálható/transzformálható. Viszonylag kevés nyelvi elem van benne, emiatt szószátyár, de emiatt vannak hozzá jó eszközök.
A másik nagy előnye a nyelvnek, hogy nagyon sok féle platformon tudod felhasználni, mobiltelefontól az enterprise alkalmazásokig. Ma a Java nyelv az egyetlen, amivel minden üzleti szempontból jelentős mobilplatformra tudsz fejleszteni (igen, iPhone-ra is).

A hagyományos JVM alapú Java platformnak pedig az a nagy előnye, hogy nem csak a Java nyelvet tudod használni, hanem az általad felsorolt dinamikus nyelvek megfelelő implementációit is, emiatt integrációs platformként is szolgál. Bár tény, hogy vannak kompatibilitási gondok (write-once debug-everywhere), de mégis tudsz az összes fontos desktop és szerver platformra JVM alapú futtatókörnyezetet varázsolni, amit aztán tudsz production környezetben használni.


Nem veletlenul nem terjedt el a simula vagy a smalltalk, helyette a c++ lett meno: tul nagy ugras lett volna a programozoknak. Ez nem jelenti azt, a smalltalk nem egy jo nyelv, vagy hogy nincs rovid - hadd idezzek, tetszik - time-to-market ideje: valojaban kortarsait nagysagrendekkel korozte le ebben a smalltalk.
A java egy batortalan lepes volt a C++-tol elszakadastol, es mint anno a c++, vagy kesobb a delphi, pont ettol lett nepszeru.

Az, hogy a SmallTalk féle OO megközelítés nem terjedt el, és sok végzett informatikus egyáltalán nem ismeri, nagy kár. Pedig ebből az irányzatból származik az Objective-C is, ami ipari szempontból is jelentős a MacOSX és az iPhone miatt.

Véleményem szerint az ObjC az egyik legszebb hibrid nyelv: a C teljesítménye ötvöződik egy dinamikus nyelv erejével. Nagyon hasznos lenne, ha az OO programozás oktatás a C++ és a Java / C# mellett felfedezné az Objective-C-t is.

Üdv,
Gergely

goto-> continue

En azt gondolom, a java kortarsainak tobbsege nem volt szigoruan tipusos. Nem azt mondom, hogy ez egy elhibazott koncepcio, pusztan nem gondolom ugy, ennek a 21. szazad masodik evtizedeben meg mindig mainstream-nek kell lennie. Nyilvan van, ahol ADA-t hasznalunk, pedig az se mai gyerek.

A nyelvi segedeszkozokkel - az automatikus nyelvi DOM -ra gondolsz valoszinuleg, amit a refactor tud hasznalni pl. - az van, hogy a programozasnal az ember a szamitogeppel beszelget, nem pedig a java compilerrel. En azt gondolom, a szigoru tipusossag a gep reszerol feltetelez kevesebb inteligenciat, es azt is gondolom - latom is - hogy a toolok folyamatosan jonnek fel a dinamikus nyelvekbol. Intelligensebb toolok kellenek hozzajuk, ez igaz.

A transzformacio nem mentett meg minket sokmindentol, ill. megmentett, amikor a teljes nyelvet csereltuk a JVM felett (clojure, scala es tarsai), errol egyszer Marie Poppendieck mondott egy jot, hogy ha elkezdesz generalni kodot, akkor egy rakat generalt kodot kell karbantartanod, es ezert doltek be a 4GL rendszerek (fejleszt valaki CASE toollal mostanaban?)

Az, hogy a java nyelv az egyetlen, amely minden platformon elerheto, egy nevetseges erv. Ilyen pl. a javascript is (PhoneGap mobil, nodejs szerver), de en pl. meg nem lattam javas iPhone appot, a j2me-android-blackberry pedig harom egymasra ortogonalis java API.

Az, hogy a JVM jelenleg integracios platform, az teny, en csak azt vitatom, hogy a java mint nyelv mukodokepes alternativa lesz 10 even belul.

Az Objective C egy aranyos platform, csak nem szabad elfelejteni rola, hogy eleg dinamikus a message dispatch benne, igy az automatikus toolok elonyeit - a javas toolok intelligenciaszintjen - nem tudod kihasznalni pl.

"tul sok energiat oltel ebbe a nyelvbe, egyszeruen hulyesegeket mondasz"
Mit szívsz, én is kérek :P

"Hasznalsz meg J2EE -t? Jo volt az?"
5 éve még jó volt, mert _akkor_, abban a helyzetben az volt a legmegfelelőbb stack, aminek volt tervezése, támogatása, elfogadottsága, ismertsége - nem volt jelentős az alternatívája. Azóta továbblépett a világ, és ha még mindig az alapján véleményezed a Java-t, akkor érdemes egy kicsit nyitottabb szemmel járni. És hogy mi az aktuális stack, amire személyes preferenciák alapján fejlesztek? Wicket + Spring + Hazelcast. A Spring konkrétan csak a JMX export, e-mail küldés wrapping meg az autowire miatt van, amúgy le is lehetne cserélni. Nézd meg ezt: http://deect.com/ - semmi EJB, még JDBC sem, mert SimpleDB illetve Lucene a backend. Komponens-alapú fejlesztés, tisztán HTML alapú design, OO kód mindenhol. Az egyszerűbb keresések mindenesetül lefutnak 200-300 ms alatt, a bonyolultabb mintailleszéseknek több kell, de tipikusan csak azon múlik hogy mennyire van bufferben az index...

Amúgy tökéletesen leszarom hogy a Java nem dinamikus nyelv, mert ilyen technológiák mellett nem igénylem hogy dinamikus nyelv legyen. Az, hogy te már a dinamikus nyelvek bűvöletében élsz, még nem jelenti azt, hogy minden más rossz, vagy az ördögtől való. Igen, vannak feladatok, amikre jó egy dinamikus nyelv, de te megismerted mint kalapács és azóta mindent szögnek nézel...

Calici virust, azert erek ra itt irogatni :)

En azt gondolom, 5 evvel ezelott kinn voltak mar olyan stackek mas nyelveken, amik sokkal jobban hasznalhatoak voltak.

Azt gondolom, hogy aki mindent szognek nez, az az, akinek meg kell varnia, mig megirjak a java komponenst/klienst/klont valamihez, semmint szabadon valaszthat nyelvet, platformot az adott problema megoldasara.

Marpedig te megvartad a wicket megjeleneset (holott egyertelmu a smarty influence benne), megvartad a hazelcast megjeleneset (memcached?), elotte olyan technologiakat hasznaltal, amik kevesbe voltak erre jok, de nem volt javas megfeleloje ezeknek.

En nem vartam meg oket: hasznaltam azokat az eszkozoket, amik eleg jok voltak az adott problema megoldasahoz.

Ertem, hogy ido es energia kovetni a java trendek mellett a python, a ruby, a javascript trendjeit; megerteni melyan a nyelvet foleg (ezert volt a GWT kezdetben nagyon nepszeru a java-programozok kozt: nem kellett hozza megerteni a javascriptet; pedig jobban jartak volna vele!)

De ezek utan azt mondani valakirol, hogy beszukult, csak mert 3-4 nyelven programoz folyekonyan, es ugy gondolja, ez a jovo?

Igazsagtalannak erzem: mivel en kovetem ezeket a nyelveket is, latom, ahogy egyre magasabb szintu tamogatast kapnak toolsetben, egyre nagyobb az elterjedtseguk, egyre magasabb kodminoseget kovetnek, en jogosnak tartom kijelenteni azt, hogy a java nyelv - es nem feltetlenul a JVM platform! - napjai meg vannak szamlalva. Teszem ezt latva oriasi projekteket, amint docognek elore.

Ezek a projektek azert docognek elore - szerintem - mert a java nyelv nem mindig volt ennyire intelligens, mint most; a rengeteg generalt kodot, vagy copy-paste megirt kodokat pedig nem tudjak egyszeruen kifaktoralni, hiaba minden automatizmus: a nyelv nem volt kelloen absztrakt, a modulok megirasakor nem gondoltak arra, hogy ezeket egyszer sokkal absztraktabb modon kene kezelni. Hiaba a toolset, eveket csusznak az ujabb es ujabb verziok.

Ehhez a fajta jovokompatibilitashoz viszont kevesnek erzem ma is a nyelvet: pont a szigoru tipusossagaval, pont azzal, hogy nem funkcionalis.

Azt gondolom, ezek a forraskodok ugy keletkeztek, hogy a programozok nem tudtak szepen elmondani a gepnek, mit akarnak csinalni. Azt gondolom, ez a nyelv hibaja, nem a gepe.

Azt is gondolom, hogy azert nem tudtak szepen elmondani, mert tul sok mindent kellett - volna - tudniuk ehhez; hanyszor latom a programozok arcan, hogy rettenet nagy energiakat belefeccoltek a J2EE megtanulasaba, es most egyszeruen nem akarjak feladni.

Pedig elobb-utobb kenytelenek lesznek: nem hiszem azt, hogy azokra a problemakra, amikkel most foglalkozunk, a java egy jo valasz.

Egyszeruen azert, mert latok jobbakat.

Nem, amire haragszom az az, hogy egyebkent okos emberek vallasi ahitattal ragaszkodnak egyetlen nyelvhez, es en vagyok a hulye, aki meg nem.

Szeretnek egy olyan vilagban elni, ahol ezek az okos emberek nincsenek bedolve a hajdani Sun marketinggepezetnek, es nem kell az ugyfellel azon vitaznom, hogy nehogy levaltsa a bevalt PHP rendszeret javara, meg nem kell modulonkent bebizonyitani az enterprise programozo kollegaknak, hogy ebben is meg lehet irni, nem bugzik, nem lassu, es fokent haromezerszer elobb kesz volt.

Meg nem kell latnom projekteket - pl. Kir-dev - latni evekig szenvedni csak azert, mert valaki bedolt annak a hulyesegnek, hogy ez jobb. (Nyilvan aztan php-ban irtak meg vegul a nagy reszet, a J2EE valtozat soha nem lett eles.)

Azt hiszem ezek az egyébként nem hülye emberek a nyelv helyett inkább a platformhoz ragaszkodnak. Merthogy egy nyelv az semmi, az két nap alatt nulláról megtanulható (excluding perl, ahhoz egy élet nem elég hogy olvasd, csak írd), viszont a platform az valami olyan, amihez ha egyszer hozzászoktál hogy mit nyújt, akkor nehéz egy kisebb szolgáltatásokkal rendelkező, vagy azonos szolgáltatásokat nehezebben nyújtó eszköztárat igénybe venni. Ahogyan pl. sokan Java mellett/helyett Grovvy-znak, azért hogy kihasználják a dinamikus nyelvet _és_ megőrizzék a platform előnyeit.

A PHP sokmindenre jó, de pl. nem tudsz vele tisztességes in-process és/vagy cluster cache-t csinálni. Nem tudsz vele tisztességes Lucene index kezelést csinálni szintén in-process módon. Persze ha kiragadod a PHP erősségét (azaz hogy HTML-t egyszerűen gyártasz vele), akkor tény, hogy Java-ban ugyanazt sokkal nehezebb megcsinálni. Ugyanakkor a terhelés nagyságrendje bőven elérheti azt a szintet, hogy egyszercsak ezekre a funkciókra szükség van, és hidd el, a memcached távolról sem optimálisan kezeli a cache-elést.

Szóval a probléma lényegesen sokkal komplexebb, mint hogy "a sok hülye, hiszen bekajálták a marketinget", legalábbis sokkal több olyan aspektusa van, ami esetleg a Te döntésedben nem lényeges, de mások esetében pedig igenis fontos.

Najó, leírom hogy szerintem miért jó.

Megfelel a keep it simple elvnek, pontosan annyit tud amennyit egy template nyelvnek kell. Így egyszerű megtanulni, és látod a fától az erdőt.

Tehát nincs benne saját:
* dinamikus kódbetöltés - használj OSGI-t
* kifejezés kiértékelés - arra ott a Java
* taglib - minek újra feltalálni a kereket? A taglib a metóshívásnak az újraimplementálása. Nélkülözhetetlen innováció :-)
* reflektív elérés - error prone, pont erre találták fel a szigorú típusosságot

JSP-hez képest:
* a template fordítást felesleges runtime-re hagyni, mert:
* dinamikus kódbetöltést úgyis illik megoldani (pl osgi)
* fordított kódot nem árt látni néha
* nem kell külön compile függőséget definiálni a template-ekhez
* _semmilyen_ runtime függősége nincs. Egyetlen absztarkt ősösztályt persze érdemes írni az adott alkalmazásnak megfelelően
* Nem kell taglibet tanulni
* Taglibhez képest hatékonyabb, scriptlet only JSP-vel "pariban" van

Freemarker, Velocity tsa-hoz képest:
* statikusan ellenőrzött típusokat használ
* Sokszoros a hatékonysága, mivel minden metódushívás direkt, nincs a reflektivitásból adódó overhead

Mindhez képest:
* Támogatja a refaktor lépéseket a template-ből felhasznált libeken.
* amit tetszik Javában írhatod meg, amit tetszik beírod template-ként.
* Van benne metódushívás - egyszerű módon pont úgy ahogy Javában - ezzel rengeteg redundanciát el lehet kerülni, amit templatekbe tipikusan bele szoktak írni a programozók.
* Learning curve 5 perc. 5 perc alatt mindent tudsz, nem alapfokon!

Ami az egyetlen hátránya:
* Csak programozók használhatják, "sima" web designernek nem adnám a kezébe. Bevallom kevés projektet láttam, ahol web designer írt volna template-t, úgyhogy ez számomra nem valódi hátrány.

Azert azt ne feledd, PHP-ban nem merul fel a megosztott allapot problemaja, hisz by design request-alapu eletciklusok vannak. Ez teszi rendkivul egyszeruve a skalazast (es nem hiaba vannak komoly, skalazas-orientalt projektek PHP-ban irva, kezdve mondjuk a facebookkal)

A memcached jelenleg a vilagon A standard terheleselosztasi mechanizmus (kereshetnek szakcikket, de lusta vagyok), igy nem igazan ertem, mi a bajod vele ;) Na jo, teny, lassan kezdik levaltani a writeback adatbazisok meg meg nagyon sok mas technologia - es persze kozel se tokeletes, de azt nem mondanam, hogy elerhet olyan nagysagrendet, amikor mar mindenkeppen java toolsetet kell alkalmazni memcached helyett - top 500 site-ok hasznaljak.

Viszont a megfogalmazasod erdekes:

akkor nehéz egy kisebb szolgáltatásokkal rendelkező, vagy azonos szolgáltatásokat nehezebben nyújtó eszköztárat

Nyilvan vannak olyan szolgaltatasok, amiket a java nyujt a legkenyelmesebben; en pusztan azt allitom, hogy a standard webfejlesztesre, arra, amit mindenki akarva-akaratlanul csinal (hiaba allitja a legtobb java fejleszto, hogy o csak backendet akar fejleszteni, erre van igeny), sem az eredeti java toolset (JSF) sem maga a nyelv (szigoru tipusossag) nem a legalkalmasabb eszkoz.

Persze, lehet groovy-t hasznalni grails felett, es akkor hozzaferek a javahoz, de hozzaferek natur PHP-bol, jythonbol, jrubybol is.

De igazabol ha megnezed a toolsetet mondjuk pythonhoz kozelrol, nem biztos, hogy ugy gondolnad, kisebb szolgaltatasokat nyujt, vagy akar azonos szolgaltatasokat nehezebben.

> memcached jelenleg a vilagon A standard terheleselosztasi mechanizmus

Boldogok a lelki szegenyek... amit te irsz az maximum php-ra igaz. Azert mert top500 siteok hasznaljak, az nem jelenti azt hogy sokkal tobb top500 site nem hasznal valami teljesen mast...

Es persze magyarazd el miert szoritja ki fentrol lefele (ertsd dragabbtol az olcsobb iranyba) haladva a memcached-t az Oracle Coherence...

delphi, de nincs ingyen.

Nem lattam meg _ingyenes_ vizualis webfejleszto eszkozt php-ra, bar egyszer egy felvetelizo emlegetett valamit, hogy o azt..

Igazsaghoz hozzatartozik, hogy a sajat cuccainkhoz sincs sose idom kifejleszteni vizualis tool-t, mondjuk eleg szerteagazo amit csinalni kell, a tervek visioban vannak, es amit lehet,yaml-be zavarunk bele, igy nem sok ido 'begepelni' a tervet.

Szoval en maradok egyelore a generatoroknal, amik szovegfajlbol dolgoznak, aztan majd ha raerek, epitek ra ext.js alapon valamit :)

Azért a "tervezünk visioba, átgépeljük PHP-be" és a "összehúzzuk a Netbeans Visual Editorba" között ég és föld a különbség. És mielőtt megkérdezed, igen, én láttam olyan projektet, amelyik így fejlesztve szépen gyorsan haladt... És nem, elébe megyek a következőnek is, nem minden projektre ideális ez sem. De azt hiszem pont az a szép ebben, hogy van egy csomó lehetőség benne :)

Jo, ebben pont nem az :)

Ha grafikus dizajner kene bindinggal, akkor valoszinuleg az Ext builder lenne a favorit, de csinaltam en mar roundtrip engineeringet greppel meg diaval is :)

Csak nyilvan egy picit nagyobb tehetseg kell ahhoz, hogy felfogja az ember, mi micsoda, es ossze tudja huzni ezeket a toolokat, mint ahhoz, hogy leszedje a netrol a mar kesz cuccot :)

En se ertem, miert csak CMS-ekhez szokas grafikus buildert adni ingyen (pl. typo3 kickstart, egyes drupal toolok), a gyakorlatban ha eleg jol vegiggondoltak a leirok (ezert a yaml) nem hianyoznak annyira.

Errgh... nezd.

Ahhoz, hogy tenyleg minosegi webalkalmazast adj le, ahhoz at kell latni a HTTP karakterprotokol-retegetol kezdve a javascript magasszintu library-jeinek mukodeseig (kozbe azert ismerve a bongeszok flow engine-jeit, DOM elmeletet stb) rengeteg dolgot.

A php/django/rails vonalat olyan emberek fejlesztettek, akik ezekkel tisztaban voltak, igazabol egy rendkivul minimalista nezetbol indul a PHP. Ez a minimalista, retegrol-retegre felfedezett tudas az, ami a mai MVC szerveroldali webes rendszerek mogott van, a rendkivul egyszeru, vegletekig egyszerusitett template nyelvekkel, a kizarolag input-model-output parositassal foglalkozo controllerekkel, az egeszet iranyito routerrel, executionfilterrel, mindazzal, amit megtalalsz egy rendes modern webes frameworkben, latsz az utcan ezret, ujabban - de csak ujabban - javahoz is.

A javas vilagra viszont ezt rakenyszeritettek. Ok baromira nem webet (html-szervert) akartak fejleszteni. A Sunnal a webes celnyelv egy idoben konkretan a szerveroldali javascript volt (netscape-sun deal). Kijott a JSP, ami vegulis PHP for java, tehat ilyen inversion-of-display vagy nem tudom minek becezzem, amit a java fejlesztok baromira nem ertettek.

Aztan addig eroszakoltak magukat, amig kijott a JSF.

A JSF-fel (ez lesz most a fo pelda, es a raepulo visual toolsetek mondjuk) az a baj, hogy a modellje hamis: hulyeseg amit allit. Nem ugy mukodik a web, ahogy azt a kitalaloi elgondoltak. Neha egyenest at kell vagni. Szo szerint.

Tudod mi a vegeredmeny?

Gyakorlatilag ugyanaz, mint amikor a 90-es evek vegen frontpage-dzsel meg word- mentes weblapkenttal szerencsetlenkedtek ossze titkarnok meg unatkozo haziasszonyok, csak epp programkent.

Mig-ral-hat-at-lan. Sot: re-fak-tor-al-hat-at-lan.

Kesz.

Ra van kenyszeritve a webfejlesztes az Enterspajz Dzsava 2000 Zrt-re, ami egesz eddig csak az SAP-t integralta Oracle-lel. Fog egy ilyen vizualis tool-t, meg belefeccolnek az embereik 200 evet abba, hogy megertsek a menedzselt babokat, amiket kompletten kene kihajitani az egeszbe. Aztan vagy ok, vagy a grafikus kis legozo, vagy az IDE, vagy a container, lenyegtelen, legeneralnak 300 tonna kodot, ami osszekapcsolja az uzleti modelt abbol amit megertettek az eszkozeikbol, amiket atbasztak annyira, hogy majdnem azt csinalja, amit az ugyfel akart. Ehhez hozza tartozik, hogy hangsulyozom, a JSF fejlesztoinek valoszinuleg elotte nem kellett webet fejleszteni, nem onnan jottek.

Osszerakjak a kis programot, leadjak, elmegy a fejlesztoceg (megszunik,osszevesztek, mittudomen), eltelik 3 ev, mi van?

Variaciok:
- A vevo azert kerul uzleti hatranyba, mert nem tudja a valtozasokhoz igazitani a szoftveret (esetek 80%-a)
- A vevo megprobalja a valtozasokhoz igazitatni a szoftveret, de iszonyatos erofeszitesek aran megy csak, ha egyaltalan (maradek 15%)
- A vevo kidobja a programot egybe , es fejlesztet egy ujat, ami vagy modern ertelmezesben lesz kacat, vagy egyszer megirjak normalisan vegre, de mindenkeppen dupla (tripla, kvadra...) koltseg.

Nem nagyon talalkoztam olyan emberrel, aki JSF-et hasznalna, es kokemenyen atlatna a webet. Komolyan. Ezek olyan emberek, akik sokminden mashoz nagyon jol ertenek, de a webhez nem akarnak: ok geekek, kockak. Ok "bekkend-fejlesztok" akarnak lenni, nem akarnak az ugyfel, plane az ugyfel vevojenek orra ele fejleszteni szoftvert, ok benn akarnak lenni az irodaban, hagyjak oket beken. Talalnak egy ilyen tool-t es orulnek.

(Ugyanez dotnetre is am, az AUT honlapjan pl. nem lehet enterre bejelentkezni, mert a formbuilder amivel osszedobtak, ugy gondolta, az input submitot nem hasznalja... a www.bme.hu nevu katasztrofarol meg nem beszelunk, komolyan visszasirom a regi, statikus, 1997-es oldalt, ahhoz akkor erteni kellett.)

A szornyu az, hogy ezek egyebkent okos emberek: mindketten tudjuk, ki rakta ossze azt a honlapot, nem buta ember. Ceges kornyezetben senior fejleszto lenne minimum... de egyszeruen... toollal lett osszerakva.

Ugy lett toollal osszerakva, hogy vagy a tool keszitoi, vagy a hasznaloi nem voltak eleg jok. Valaki nem ertett valamit. Egy trivialis dolgot.

Ezert van az, hogy sokkal inkabb bizom a sajat tooljaimban, amiket per projekt irunk vagy hozunk at, mikor erezzuk a taszkok ismetlodeset. Meg azokban, amiket soronkent neztem at. Amiket teljesen megertek.

Cseszettul erteni kell hozza? Igaz. A legtobb vevonek nincs ilyen minosegigenye? Most meg.

De a ronda az, hogy a JSF-ben dolgozo senior-fejleszto altal keszitett weblap altalaban pont olyan szar, mint a kispistike bt altal php-ban osszeganyolt.

Az egyik a foldrol epitkezett, koszos, mocskos eszkozokkel, es primitiv volt.

A masik meg - hat, az also reteghez o se ertett talan jobban. Megtanult egy csomo koztes dolgot, amik egyebkent baromira nem kellettek volna pont ehhez, ha hajlando lett volna megtanulni a masik eszkozeit a sajat eszevel hasznalni.

A munkaja nem lett jobb.

1, mindig kisregenyt irsz - menj el ironak ;)
2, a JSF egy fos, ezt alairom. de a Javas web nem itt tart. nem az az ultimate keretrendszer, toolkit, akarmi, nem muszaj neked visual builderrel osszehuzogatni, es osszeganyolni. van SOK mas lehetoseged is.
3, a kettes alapjan baromi nagy csusztatas ez az egesz amit eloadsz

(mondom ezt ugy, hogy railseztem, grailseztem, bar nem vagyok webes ember, ezt elismerem, JShez sem ertek komolyabban, viszont a wicket meg mindig tetszik, es az csak egy a sok kozul)

A javas web 5 ev hatranyban van, nem itt tart, hanem ahol a tobbiek tartottak 5 eve. A visualis tool 4-5 eve volt divat, most kene boviteni az ezen alapulo programokat.

Pont azert van 5 ev csuszas, mert teljesen mainstreamme kell valnia valaminek ahhoz, hogy te is elkezdd hasznalni, akit nem erdekel.

A reakcio arrol szolt, mire jutsz, ha elkezdesz hasznalni egy vizualis toolsetet, amit a netrol lottel. Ebbol faces-hez volt sok.

Wickethez van ilyen?

(Remelem, rovid voltam.)

Onanizal a fene.

Fogj egy issue trackert tetszoleges atlagos informacios rendszer projekten, es nezd meg, hogy hany issue nem kotodott a frontendhez.

Esetleg vedd ki azokat is, amik nem adatbazis-sema valtoztatasokrol szoltak (-> DB fejlesztes)

Na, a maradek, az a backendfejlesztes. Amit minden javas szeret. Amit hiszi, hogy fontos.

A frontendhez meg erteni kene azokhoz a dolgokhoz, amikhez a legtobb java fejleszto nem akar. Ideertve a JS nyelvet is. (Pl. tudtad, hogy a class nem kulccszo benne?)

Amit en az elejen allitottam, hogy ehhez a szereny kisebbseghez (ami a taszkok 60%-a minimum) nem jo a java.

De most epp arrol kerdezett bambano, hogy van-e vizualis toolset php-hoz, mire mondtam, nem divat, inkabb irunk, erre syntern reagalta, hogy na, de javahoz van, mire visszairtam kb, hogy don't dare to use it, makes customers life hard.

Errrrrrrrrrrrrrrrrgh

Ipari titok sertes lenne... Maradjunk annyiban, hogy latom a vilag legnagyobb javaban irt site-jainak egy reszet.

Nem feltetlenul az a leggazabb projekt, de ... na mindegy, nem mondok semmit.

A ceg ahol dolgozom alapvetoen nem php-val foglalkozik, nem magyarorszagnak fejlesztunk, es nem pici ugyfelekkel. Egyik projektben segitenem kellett megoldani egy problemat, mert a (http, sima webtartalom) proxyk es a gepek kozti 15 gb/sec-es uveg nem birja az adatforgalmat, de annak a java forrasat nem ismerem (csak a proxytechnologiat), csupan meretet illusztralok.

Ruby? Fogalmam sincs, az eredeti keretben nem volt, helyette ok HAML-eztek sokaig, ilyen yaml + html vilagban eltek.

(Bacsi Laszlo, a magyar ruby elet egyik kulcsfigurajanak eloadasa: http://www.virgo.hu/undercode/2009/02/html-es-css-szerkesztes-gyorsan-e… )

Divat meg neha a markdown, ami egy wiki szeru szintaxis.

(Utananeztem neked:. van visual rails. Ez nem valtoztat a tanacsomon: don't use a tool unless you fully understand what it does)

A JSF azert volt pelda, mert arra epulnek azok a toolok mind, amiket en lattam (netbeans beepitett, eclipse-nek valami ibm szallitott, meg valaminek volt vizualis jsf buildere)

Ha már szóba került a kir-dev (amit ugye anno én gründoltam össze mielőtt pofátlanul leléptem az sch-ból és magukra hagytam őket az egy borcsokj kivétellel, akinek még a diplomamunkájánál konzulenskedtem egy sort), meg a wicket, gondoltam beböfögök egy sort én is. Mint talán emlékszel a kir-dev pont php-n indult valamikor 11-12 éve, a jávásításban semmi részem nem volt, talán ha van másképp alakul minden. Mindegy.

Ami viszont vicces, hogy a wicket-et pont 5 éve találtam meg, azóta is használom, használtam, kb. mindenhol az elmúlt 5 évben, amerre vetett a sors. Legalább 3 olyan magyar cég van, ahol a fejlesztési eszközkészletbe én vittem be a wicket-et - több helyen a mai napig (úgy értem távozásom után is) kitartanak ennél a technológiánál (használták már több nagy magyarországi banknál frontend fejlesztésre, migráltunk több struts-os alkalmazást wicket-re, tudnék sorolni projekteket) - ha van értelme használni, és a megrendelő nem a "drága a tízpluszáfás óradíj" típusó olcsójános. Nem mindig volt egyszerű keresztülverni a helyi fejlesztői kultúrán, hogy "tessék elfelejteni a struts-ot, ne is gondolkodjanak jsf-ben, ez jobb", de egy gyors pilot meg a framework képességeinek megmutatása után mindig sikerült. Persze voltak kudarcélmények is: elsősorban a humán tényező mutatta meg a foga fehérjét többször is, amikor is kiderült, hogy a pocsék programozó minden nyelven és platformon pocsék programozó és pocsék kódot ír. Az ellen nem véd semmi.

A Szeretgom.hu is full wicket webapp, eclipselink és glassfish felett, a 3 éves x2100 m2-őn egy index címlapos hírben szereplő közvetlen link estéjén sem láttam 0.4-nél magasabb load-ot, pedig az adatbázis is ugyanott fut. Ha a kir-dev közelében maradok (emlékszem valaki még nógatott is, hogy maradjak az sch-ban nevtanárnak, de nem maradtam), akkor valószinűleg ugyanezen a kódon futna az is.

Tanulság? A tapasztalat és a hozzáállás sokkal fontosabb egy projekt sikeres lezárásához, mint az, hogy milyen nyelvet választasz. Egyrészt mert fel tudod ismerni, ha nem a feladatnak megfelelő a választásod, és tudsz korrigálni. Másrészt megfelelő hozzáállással minden eszközt addig tudsz formálni, míg az alkalmas lesz a problémád megoldására.

Én a következő 5 évben biztosan maradok Java platformon, hacsak az Oracle valamit nagyon el nem kúr.

--
The reason that half of us are in computing at all is that we see computers as things that we can make beautiful things out of..

"Konkretan megakadnak projektek azert, mert a java mint nyelv olyan amilyen. Tobb eves csuszasokrol beszelunk, ha egyaltalan valaha is kesz lesz a feature!"

Jó fejlesztőket kell alkalmazni, és meg kell őket fizetni, ennyi a titka az egésznek.

Az EJB résszel egyetértek, viszont nem a fejlesztő / architect feladata, hogy megértse, hogy egy adott keretrendszer mire való, és mire nem? Mi gondolkodtunk saját keretrendszerről j2ee átállásra, és úgy néz ki, nem fogjuk megtenni, mert nem tudja azt, amire nekünk szükségünk van. Viszont ebből nagyon sokat tanultunk, és mégsem gondoljuk azt, hogy a j2ee nem lenne jó. Jó az, amire kitalálták. Nekünk meg nem az kell.

Igen, a programozok 60%-a vallja magat Java-hoz ertonek... es vajon mennyi ert valojaban a Javahoz? A fele? De 'isz nincsenek is annyian! :-)
Attol, mert valaki ossze tudott rakni egy akarmilyen programot, attol meg nem lesz egy adott nyelv szakertoje.
Es nem, egyaltalan nem olyan biztos, hogy talalsz odabent olyan embert, aki hozza tud szagolni. Illetve, lehet, hogy talalsz, de nem biztos, hogy az o tudasaval engeded is hozzaszagolni. A Java egy eleg nagy terulet, nem lehet benne mindenki mindennek a szakertoje.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( gabrielakos v | 2010. 03. 22., h – 11:50 )

Önmagában szerintem nem.

Sorolj fel érveket a Java és a PHP mellett és ellen is. Aztán tedd egymás mellé, és gondolkodj ügyfél fejjel, hogy megér neked egy forintot is a különbség?

Vállalkozási szempontból pedig tedd mellé, hogy a nagyobb bevételhez vajon nagyobb kiadás is tartozik-e? (általában igen).

Nálunk szerencsére nem csak Java szakértelem van, általában a kisebb saját projekteknél PHP-t használunk.

Nem egyszerű a képlet, nem lehet generálisan ezt vagy azt mondani. Rettentően ügyfélkör függő is. Tipikusan az elején kell elhatározni, hogy melyik piaci szegmensre lősz. Kis céggel nem lehet több piaci szegmensre lőni, mert nincs rá kapacitásod. Sem szakmai, sem egyéb.

--
Gábriel Ákos

( persicsb | 2010. 03. 22., h – 14:26 )

Javitsd ki a typot a cimben, Eneterprise van ugyanis most. Kosz.

( sj | 2010. 03. 22., h – 14:53 )

meg mielott a penz szoba kerulne, imho elobb define enterprise...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

( sibidiba | 2010. 03. 22., h – 16:46 )

Rengeteg enterprise alkalmazást *csak* Javaban van esélyed implementálni. Nekiállhatsz ugyan C/C++/Perl/Pythonban hackelni, de bízisten nem fogod megtalálni azt a rengeteg API-t amivel a CORBA-tól a WS/REST-en át egészen a legacy adatbázisukhoz mind csatlakozni tudsz. Nem funcionális követelményekből is van egy halom, amit Java ad, többi nyelv egyáltalán nem, vagy csak csak valami megbízhatatlan, használhatatlan hackekel (pl. még a 90-es évekből van egy plugin lib a sourceforgeon...). Skálázhatóság, integrálhatóság (pl. appserver) stb.

Enterprisenak csak az számít, hogy tervezhető legyen, kellő minőségű legyen és tényleg működjön a végén.
Ezt sokszor Javaban egyszerű. Az enterpsise meg minden pénzt megad, ezért tűnik gyakran úgy, hogy java-ban többet lehet kersni.

--
The Net is indeed vast and infinite...
http://gablog.eu

( uid_4263 v | 2010. 03. 22., h – 19:20 )

Számomra érdekes a témafelvetés, mert volt ilyen tárgy a szakomon, és érdekelt volna hogy érdemes-e még foglalkozni vele a későbbiekben vagy elég ha örülök a zöld mezőnek a Neptunban. Olvasgatom a HUP-ot és tudom hogy itt többen évek óta közelről ismerik a témát.

Sajnos legalább a topic fele önérzeteskedésbe meg személyeskedésbe ment át. Most olvashatok 2x annyit a hasznos infókért. Kösz azoknak, akik nem tudnak csendben figyelni.

********************
"Aki nem backupol az tehetsegtelen :-)"
"...ha nem tévedek!" (Sam Hawkins)
http://holo-media.hu

Nyilvánvalóan a kérdés összetett, így a válasz is az. Leszögezem, én nem fejlesztettem még enterprájsz környezetre, akárhogyan is definiáljátok azt.

Ha enterpriseról beszélünk, nyilván nem az adott rendszer lesz az első, ami bevezetésre kerül, így aztán imho érdemes illeszkedni a jelenlegi technológiákhoz ( BÁRMI is legyen az ), kivételt képez az az eset, mikor bebizonyosodik ez utóbbinak a létjogosulatlansága, hogy így mondjam.

Hiába fejlesztesz le egy bánomisén milyen java kódot pikk-pakk, ha annak az integrációja sokkal nehezebb lesz. Ugyanígy természetesen más nyelvekre is igaz ez.

Továbbfűzném akkor a kérdést: Ha lenne egy olyan terved, amivel jó eséllyel pár éven belül enterprájszod lesz, és meg van a lehetőséged a 0-ról indulásra, akkor mivel ugranál neki? Beszélhetünk akár egy webes szolgáltatásról, vagy elosztott hálózati alkalmazásról. Engem inkább ez érdekelne, nem az, hogy a multik mit használnak.

( _Joel | 2010. 03. 25., cs – 20:19 )

Hadd szóljak hozzá az eredeti kérdéshez is.

"ugyan azt a megoldast javaban implementalva jobb penzert lehet eladni. Ez tenyleg igaz ?"

A két dolog között nincs közvetlen reláció. Egy valami igaz: az átlag jávás fejlesztői óradíj 25-40%-kal magasabb, mint mondjuk az átlag php-s fejlesztői óradíj. Magyarul drágábban dolgoznak a jávás emberek. Főleg, ha van 8-10 év tapasztalatuk.

"Valoban jobb bevetelekre szamithat az ember, ha Javaban dolgozik, meg ha ez mas szempontokbol nem is lenne indokolt ?"

Ha fejlesztőként dolgozik, akkor igen. A Java fejlesztők többet keresnek, mint a PHP fejlesztők. Egyéb nyelvekről nem nyilatkozom.

És akkor térjünk vissza az első kérdésedre:

"ugyan azt a megoldast javaban implementalva jobb penzert lehet eladni"

Amennyiben nem fix áron, hanem T&M alapon dolgozol egy feladaton, akkor a fentebbi magasabb óradíjak alatt egységnyi időért magasabb összeget fogsz elkérni a megrendelődtől. Természetesen ugyanazt a funkcionalitást kifejleszteni lehet 1 óra, 1 nap, 1 hét, 1 hónap különböző nyelveken és környezetekben, illetve más és más felkészültségű emberek használata esetén.

Ha terméket fejlesztesz, vagyis nem egyedi szoftvert hegesztesz valakinek, akkor nyilván a termék fogyasztói árát úgy fogod belőni, hogy a termék kifejlesztését (a befektetésedet) visszahozza, mondjuk az első 1-2-3 év eladásaiból. Vannak erre nagyszerű modellek. Enterspájz piacon például az az elterjedt modell, hogy felveszel egy dörzsölt fekete bmw-s sales gyereket, aki addig jár a potenciális ügyfelek nyakára a termékeddel, amíg annyira elegük nem lesz belőle, hogy a következő negyedévre bebádzsetelik a sok százezer eurós licenceárat, és megveszik tőled a szoftvert. Amit jobb esetben nem a polcra raknak ki, hanem be is vezetik, amire meg eladhatsz professional services szolgáltatást ezer eurós napidíjért a licence ára felett.

Van sok enterspájz szoftver, ahol ez működik. Vállalatírányítási rendszerek, vezetői management szoftverek, döntéstámogató rendszerek, dokumentummanagement rendszerek, crm, srm rendszerek, lehetne sorolni.

A másik feljövőben lévő modell az, hogy nem drága sales-ekre költöd a pénzed, hanem a terméked fejlesztésére, és bízol abban, hogy sokan felismerik, hogy az milyen király, és sokan fogják azt megvenni tőled. Erre épül például az Atlassian (JIRA, Confluence, stb), vagy a Fog Creek Software (FogBugz) üzleti modellje. Bizonyos szoftvertípusoknál ez is tök jól működik.

Mint látod, a válasz eléggé összetett. Ha programozó vagy, és nem fejlesztő céget építesz ami terméket fejleszt, akkor igen, a java nyelv nem rossz választás, mert keresett a piacon és jól megfizetik a jó jávás embereket.

Ha terméket fejlesztesz amit el akarsz adni a szoftverek nagy világpiacán akkor meg qrvára mindegy, hogy milyen nyelvhez értesz, mert úgysem az a legfontosabb (bár az nagyon fontos, hogy valamilyen technológiához iszonyatos agykapacitások legyenek a cégben, de ettől még nagyon el lehet bukni a piacon ha elcseszed az üzleti részt).

Ja, és a harmadikat kihagytam, ez magyar (balkáni) sajátosság:

Vedd fel sales-nek valamelyik közepesen híres politikus rokonát, aki majd hozza a milliárdos megrendeléseket. Teljesíteni nem feltétlenül kell, ellenben legyen egy jó táskabolt a közeledben, mert az fogyóeszköz lesz a cégben (bár újabban nokiadobozokat is lehet használni).

( ssikiss | 2010. 03. 25., cs – 22:46 )

Nagy pénzt általában nagy rendszerekért lehet kérni. Na most, hogy ilyet csinálhass, oda kell férkőzni valahogy a naaagy kondérhoz. A nagy kondérhoz naaaagy ismerős révén lehet odajutni. Ha nem csak számlázni akarsz, hanem véletlenül működő rendszert is szeretnél szállítani, akkor lehet kérdés a megvalósítás eszköze. Naaagy pénznél már jönnek minden irányból "behatások", hogy ezt kell használni, meg azt tekintsd adottnak, meg amabból mindenképpen venni kell legalább x-et, hogy más naaagy ismerősök ismerősei is falatozhassanak abból a kondérból. Ilyenkor általában már "finomodnak" az eredeti kiírásban szereplő követelmények és elvárások is.
A Java (és JEE) ennek a játéknak a technológiai részére egy állati jó megoldás, mert minden van hozzá (sokszor ingyen), amivel meg tudsz felelni a határidőknek (kisebb-nagyobb csúszásokkal), elvárásoknak és követelményeknek.
Van még az Ms (M$) vonal is. Az ottani szitut nem igazán ismerem, de biztos jó, és ajánlólevélnek sem rossz az Ms alap.

( sj | 2010. 03. 29., h – 14:08 )

A millio fele java-related roviditesek kozott kicsit elveszve kerdezem, hogy ha egy brutal nagy teljesitmenyu web alkalmazast akarok csinalni, akkor arra jo valasztas egy valamilyen java app szerver / container / whatever + jsp?

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Attol fug Afrikai vagy Europai.

Manapsag a vasak kurva erosek, barmilyen technologiaval barmit kiszolgalnak elfogadhato sebbesseggel.
Ugyhogy az esetek 99%-ban barmi jo, leginkabb izles kerdese. Dontesnel legtobbszor nem a teljesitmeny kell legyen a fo szempont.

Altalanosan had ne keljen mar megvalaszolni, hogy jo -e. Sok mindentol fugghet.

A Valoban "Brutal nagy" teljesitmenyhez egyetlen kozismert megoldas sem eleg jo :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Kicsoda-micsoda milyen kontinensu?

Az, hogy ma a vasak mennyire erosek, aligha erv amellett, hogy egy nagy terheltsegu site-ot ne a leghatekonyabb technologiaval oldjunk meg, ld. x db vas vs. 3-4*x db vas.

Mivel csak erdeklodom, ezert altalanos a kerdes, es ezert csak annyi a meghatarozas, hogy 'brutal nagy'. Gondolom, most az egyszer elnezed nekem, hogy most ez a fo szempont ;-)

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

semmi konkret, de csak a pelda kedveert: csinalni akarok egy iwiw2-t (nem akarok, de ha valaha az eletben pl. egy startup-hoz kerulnek, akik viszont akarnanak.... :-)) A lenyeg tehat az, hogy fentebb olvasgatva a velemenyeket + nehany hivatkozo benchmarkot az jott le, hogy a php egy hataron tul nem megfelelo, viszont a java pl. nagyon jol skalazodik egy sok magos gepen es sokkal gyorsabb, mint a php. Ezert arra gondoltam, hogy kiprobalom az utobbit (javat), es ehhez kerek tanacsot.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

nem csak sok magos gepen skalazodik jol, hanem sok gepre is, akar transzparensen. epp most irom a tdkmat, az elmult jopar napot ilyen temaju cikket/projectet megneztem.

ami latszik, hogy
- perszisztencia skalazasra van jo megoldas (cassandra, neo4j, ...)
- business logic skalazasra majdnem van jo megoldas (gridgain, terracotta, hazelcast, ...)
- view cachingre van jo megoldas (terracottas ehcache, oracle coherence, ...)
- a webes tartalmi fejlesztesre van jo megoldas (wicket, velocity, ...)

szerintem teljesen jo. en is alig talaltam fogast mar a dolgokon, amirol lehetne irni.

Szia NagyZ,

egyreszt engem is erdekelne a TDK-d, masreszt viszont a csoportositassal gondokat latok:

Az Oracle Coherence-t egyszeruen besorolod a view cache-ek koze, holott az emlitett teruletek kozul barmire eleg jol hasznalhato.

Perzisztencia skalazas: par szaz nodeig siman out-of-the box megy a Coherence is, utana kicsit trukkosebb, mindenesetre a failover latency-re viszont valoszinuleg jobb eredmenyt ad mint a cassandra/egyeb nosql cuccok. Viszont ha a perzisztenciarol lemondasz, akkor failoverben meg valoszinuleg jobb mint a nosql cuccok.

Business logic skalazas: ide gyonyoruen beillik a Coherence, mi is hasznaljuk erre (is). A hazelcast nem igazan megbizhato szerintem, mivel nem garantalt, hogy ha egy box tobb node-dal lehal, akkor nem vesztesz particiot. Gridgain onmagaban eleg fapados megoldas, szeret valami backenddel (pl. Coherence) integralodni.

View caching: Terracotta ehcache. Eleg hires volt az EHcache azon hibaja, mikor idofuggo eviction policy hasznalata eseten bizonyos meret fole erve az update egyre gyorsabban novekvo valaszidoket mutatott (magyarul bizonyos meret fole nem volt skalazhato).

Udv,

Finrod

csak gyorsan szkeccseltem egyet, tudom, hogy vannak athallasok a kategoriak kozott, de azert koszi a kiegeszitest. :)

coherence-backed gridgainrol tudsz meselni? ami engem erdekel gridgain ugyileg, az foleg a @Gridify (terracottasoknak @DMI), meg hogy lat-e az ipar egy elosztott tetszoleges adattaroloban (nyilvan particionalassal) fantaziat.

a tdk pentek-hetfo korul lesz kesz, csak gaz, mert penteken el kell utaznom kulfoldre. de ha lesz vmi hasznalhato, ugyis kirakom, vagyok ennyire exhibicionista :)

Szia NagyZ,

Ha jol emlekszem (kb. 1-2 eve neztem), a GridGain mind taskok-related adatokat (pl. job/task state) tud Coherence cache-ben tarolni, mind a sajat kommunikaciojat (Gridgain jvm-ek kozott) tudja Coherence felett vegezni.

Az elso nyilvanvalo elonye hogy egy gyakorlatilag korlatlanul skalazhato (partitioned) data gridbe pakolhatja a task adatait.

A masodik elonye, hogy egyreszt a Coherence service-ekre vonatkozo event handlerekre a Gridgain ra tud ulni, ergo a Coherence garanciait kapod a Gridgain node-ok eletciklusaba tartozo esemenyekre (node jott, node elhalt, stb.), masreszt ki tudod hasznalni a Coherence-ben levo key affinity hasznalatabol szarmazo elonyoket (osszetartozo adatok 1 JVM-ben), es az adatvegrehajtas odakuldheto az adathoz.

Azota lehet hogy meg szorosabbra huztak az integraciot, anno eleg jo kapcsolat volt a GridGain es a Tangosol kozott, gondolom ez nem valtozott azzal hogy az Oracle megvette a Tangosolt.

Viszont a Coherence-es berkeken belul elkezdodott egypar ujabb kezdemenyezes ami bizonyos mertekben parhuzamos (lesz majd) a GridGain-el (Coherence Incubator Processing Pattern).

Egyebkent ha ilyesmi erdekel, akkor irj egy levelet (hova utazol egyebkent penteken? ha Londonba, akkor meg elotte irj :-) (elvileg itt a hupon keresztul tudsz)).

Udv,

Finrod

Jol skalazodik a php, tobb serverre is.
iwiw -nel "legrovidebb ut" az amit klaszikus csak requestkor lefuto php scriptekkel nem erdemes megoldani Ill. csak jsp -vel sem.

iwiw doksik alapjan "legrovidebb ut" kerdest is kulon serverek valszoljak meg, az reszlet kerdes, hogy miben van implementalva, de en C/C++ inkabb javasolnek erre, de a java is szoba johet. Script nyelvet inkabb nem javasolnek.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Jol skalazodik a php, tobb serverre is.

Hmm, mondjuk fastcgi-vel?

amit klaszikus csak requestkor lefuto php scriptekkel nem erdemes megoldani

Hirtelen az jutott eszembe, hogy a google sem akkor allitja ossze a 'sex' kulcsszora kereses eredmenyet, amikor kattintasz. Vegul is, le lehet tarolni, hogy kihez hogyan jutok el, bar azert soknak tunik ez az adat, meg akkor is, ha 6(?) hopnal senki sincs messzebb...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

biztos..., viszont kicsit toprengve hazafele a buszon, azon tunodtem, vajon van-e ertelme / kezelheto adatmennyiseget kapunk, ha mondjuk 1M ember eseten kiszamoljuk az (n-1)+(n-2)+(n-3)+....+1 szamot (~1M*500k=500G), ha pedig ugyanet 4M-ra szamoljuk (kb. ennyi tagja van az iwiw-nek, ha jol emlekszem), ~4M*2M=8T kapcsolat/path lehetseges.

Szoval lehet, hogy ezt megsporoljak, es nem egy shortest_path{'user1:user2'} kulcs-erteket kerdeznek le, hanem valamilyen masszivan optimalizalt adathalmazra eresztenek ra egy algoritmust...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

megis melyik hatarrol beszelsz? Amin a facebook fut (felmilliard felhasznalo), amin a farmville (ennek kb. a fele), amin a flickr (meg nem mondom most mennyi) vagy amin az iwiw?

Az iwiwen kivul mind PHP alkalmazasok (ill. a facebook elsosorban/frontend szempontbol PHP, a farmville pure PHP)

Nyelvi szinten stateless, elbaszni se lehet a skalazodasat. Nincs az az ocsmany PHP kod, ami ne skalazodna, ezt a cegnel egy orokolt kod tetelesen bizonyitotta (jo, tegyuk hozza, edgesuite felett, ami azert jocskan novel a teljesitmenyen, ellenben kevesen tudjak megfizetni)

Persze mindenki ugy szopatja magat, ahogy akarja :)

Ne higgy a vallalati programozoknak, a nagy forgalmak (szazmillios userszamok, teljesen dinamikus alkalmazasok) nem ott vannak.

kossz az infot, akkor egyelore nem cserelem le a php-ban (mvc rulez) megirt webui-t a clapf-hoz :-)

Amugy foleg http://gwan.ch/en_scalability.html alapjan ertettem a hatart. (Mondjuk gwan-ra tuti nem valtok, mert irjon web app-ot az C-ben, akinek 6 anyja van...) Szoval a felvetes eleje arra reklektalt, hogy a cpu clock mar nem igazan fog noni(?), de a magok szama nohet a cpu-kban. Ha viszont egyre tobb magosak lesznek a szerverek, akkor olyan alkalmazas kell, ami azokat ki is kepes hasznalni. Az elmeletem az, hogy a php fastcgi-vel kepes lehet erre.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

:)

A skálázódás amúgy szinte minden esetben azon múlik, hogy:
- mennyire ragaszkodsz konzisztens adatokhoz (pl. RDBMS überkonzisztens de emiatt rosszul skálázódik), ideértve azt is hogy mennyire élsz együtt outdated cache adatokkal...
- hogyan ábrázolod az adatodat, és azon belül mennyire hatékony indexeket használsz pl. sok esetben az inverted index (pl. Lucene) hatékonyabb mint a B+-tree és társai még range query-kre is, persze kicsit máshogyan kell megfogalmazni, hogy mi az adat amivel dolgoznak. Nem árt ha az ember megbarátkozik a denormalizáció fogalmával és társai...
- mennyire hatékony a lockfoglalás és -felhasználás
- mennyire beszédes a cluster protokoll

Az hogy a frontend alatt milyen technológia van, csak részletkérdés, a fentiek szinte mindent meghatároznak. Feltűnt hogy nem szerepel benne programozási nyelv illetve platform? Ugyanakkor szerepel benne egy csomó olyan tétel, amire egy PHP pl. alkalmatlan, a Java, erlang, python meg kifejezetten támogat (net, clustering, threading és locking...).

persze, mindent a technologia es annak hasznalata _egyuttesen_ hataroz meg, ezert van az, hogy gyorsabban generalok xml-t adatbazisbol, ha perl-t hasznalok middletiernek, mintha az oracle xml-ben, "hozzaertok" altal megirt kodot hasznalnam.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Amin a facebook fut (felmilliard felhasznalo)

az C++-ra forditott, es nativra kompilalt PHP kod! :^D

On the other hand, scripting languages are known to generally be less efficient when it comes to CPU and memory usage. Because of this, it's been challenging to scale Facebook to over 400 billion PHP-based page views every month.

One common way to address these inefficiencies is to rewrite the more complex parts of your PHP application directly in C++ as PHP Extensions.

;^)

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

nemtom hogy olvastad-e, de pl. rasmus is irta, hogy nagyon keves olyan webalkalmazas van, amiben mar a logikai/matematikai/string muveletek vegrehajtasanak a C-hez hasonlitott sebessegkulonbsege a legnagyobb problema.
altalaban ez az utolso dolog ami optimalizalni akarsz.
valszeg a facebook-on mar olyan optimalis volt a kod, hogy megerte meghozni ezt a lepest.
mig mondjuk egy atlag webappon valamilyen cache bevezetese, vagy az adatbazis skalazasa tobb nagysagrenddel gyorsitja a lapletolteseket, mint az, hogy milyen gyakran olvassa be, parseolja fel a php kodot az interpreter (jo esetben memoriaba cachelt filebol, vagy megjobb esetben bytecode-bol)

Tyrael

nagy forgalmu portalok alatt is ez a tendencia.
myspace evekig dobalta a csunyabnal csunyabb hibauzeneteket, amig tudtak ala irni normalis kodot, meg rakni ala normalis rendszert.

el sem tudok kepzelni, hany nagyforgalmu oldalnal vannak olyan szakemberek, akik szerint a clusterezes az az, hogy kulon vasra teszed az sql szervert.

elso korben sosem az nyelv lessz a szuk keresztmetszet, hanem az adatbazis, a fajlrendszer, a halozat, a cache (pl. asszem facebook-nal csinaltak meg azt, hogy atirtak a memcache-t udp alapu kommunikaciora, es 3szor vagy 4szer annyi klienst tudott kezelni igy 1-1 szerver)

ezeken tobbet lehet optimalizalni, mint amit az az 50%, amit a hiphop a facebooknak hozott:
http://developers.facebook.com/hiphop-php/
es ennek a gyorsulasnak egy resze szerintem siman abbol jon, hogy a hiphop nem csak egy php -> c++ konverzios program, hanem egy lightweight webszerver is.
es ezt hasonlitgatjak az apache+php kombohoz. vicc.

Tyrael

( pwm | 2010. 03. 30., k – 19:51 )

Nehany itteni hozzaszolasban talalkoztam olyan felhangokkal, hogy ugyan azt a megoldast javaban implementalva jobb penzert lehet eladni.
Ez tenyleg igaz ?
Valoban jobb bevetelekre szamithat az ember, ha Javaban dolgozik, meg ha ez mas szempontokbol nem is lenne indokolt ?

Nem. Termeszetesen a penz nem nyelv, hanem feladat fuggo. Ugy mar inkabb igaz, hogy jelenleg a legjobban fizetett feladatok nagy reszehez java/.net technologiakat hasznalnak. Magyaran java-val/.net-el jelenleg nagyobb az eselyed arra, hogy olyan projectben vegyel reszt, ami jobban fizet, mint egy php/ruby/python project. Viszont az is igaz, hogy nagy altalanossagban zarodik befele ez az ollo, es vannak teruletek (pl az itt sokat citalt web), ahol gyakorlatilag be is zarult. Es persze vannak teruletek, ahova szvsz sose fognak hatekonyan betorni ezek a nyelvek + a rajuk epulo technologiak.