Hmmm... amazon s3? Ma nagyon jo fej vagyok :) Bar biztos lattatok. On demand poccinthetok a plusz szerverek, hasznalat utan fizetsz. A befektetokkel meg nem csak az a baj, hogy az otleted+megvalositas 5%-ot er, 95% a befektetoe, hanem az is, hogy hajlamosak szetverni a ceget. Pont tegnap emlegettem fel egy kollegamnak, asszem egy Joel Spolsky cikk volt arrol, hogy miert van tele a net olyan cikkekkel, hogy csinalni akartunk egy startupot, aztan kellett a toke, aztan a VCk szetvertek az egeszet.

A valasz pedig az, hogy a vallalkozonak es a VCnek baromira mas a strategiaja es ezert az erdeke is. Csak latszolag kozos a cel, valojaban a vallalkozo nagy (80-90%-os) valoszinuseggel akar tisztes hasznot elerni, a VC pedig kis! valoszinuseggel (mondjuk 10%) akar NAGY hasznot (sokezer %, esetleg 100x-os nagysagrend). A VC sem hulye, nem is kockaztat sokat, hiszen o nem egy lapra tesz fel mindent, hanem sok ceg kozott osztja szet a tokejet (mondjuk a pelda szerint 10 cegbe, akkor eleg a 10%-os siker valoszinuseg). A vallalkozo viszont sokat kockaztat, egyszerre egy biznisze fut, az egesz elete soran meg mondjuk 2-3-4 ilyen dologba kezd bele az ember.

A vallalkozo ezert kevesebb penzbol realis otleteket es megvalositasi utemet akar, a VC viszont porgetni akarja a bizniszt, sok penzt rak bele egyszerre, es irrealis fejlesztesekbe hajszolja a ceget. (Pl. egybol sok ember felvetele, stb. ami raadasul a sw bizniszben kifejezetten hatranyos.) Nem meselem el az egeszet, kereess ra :).

Amugy egy (scamel becenevu) haverom meselte, hogy az occse ismerosei valami lastFM szeru dolgot csinalnak, de uber titkos. Nem lehet, hogy ti vagytok azok? ;)

bizony, amazon s3, amazon ec2, talán amazon mqs is, ezen még vitázunk :)
más úton - de szintén részben olvasva - és nemrég egy befektető által tulajdonolt cégben dolgozva jutottam oda, hogy a befektetőt inkább lelőni kell, mint szóbaállni vele.

A leggázabb a világon talán a magyar pénzügyi befektető és multitól kirúgott, bosszúra vágyó ügyvezető kombinációja. Na az biztos bukás.

Jó nagy pénzeket toltak bele, amik elmennek bérre, irodára, drága szoftverlicencekre, a bérek adóira, de marketingre már nem jut.

Nem ismerem scamelt, de ma, hogy visszajöttem konferenciáról, majd körbekérdezek.

A Getting Realt olvastad?

Kozben kiderult, hogy nem ti vagytok azok. Azok a sracok masok, es mast is csinalnak. A getting realt meg nem olvastam, de jol bebookmarkoltam :)

Az iwiw-et telelg nem ertem, hogy miert Javaban kellett megcsinalni...olyan ótvar lassú, hogy totalgaz!

JAVA-ba sokan, sok indokkal belevágnak.
Maga a nyelv, az ojjektum-orientáltsága az, ami vonzóvá teszi, hiszen a Microsoft-féle .Net platform által támogatott nyelveken kívül webes fejlesztésre más "igazi" ojjektumorientált nyelv nincs.
Sajnos a JAVA nem alkalmas nagyforgalmú weblapok kiszolgálására, amiben komoly része van a kódot futtattó webszerverek bénaságának is. Azaz a JAVA kódot kevésbé fordítják le a gép nyelvére a futtató rendszerek, mint pl. a .Net kódot az IIS.

Több alternatív platformot is szemügyre vettünk mielőtt a Mono mellett döntöttünk. Több alternatíva, pl. RoR, Python azért sem jöhetett szóba, mert az interpretált mivoltuk miatt lassabbak. A C# magasszintű és a Mono nagyon jól megírt JIT-tel rendelkezik, ami miatt gyors is. A fejleszőknek azért is tetszett, mert volt már .NET-es tapasztalatuk.

Buksi, Meister: nem nagyon vagytok kepben. Gyonyoruen mukodnek nagy forgalmu weboldalak (ill. nagy forgalmu mindenfele szerverek) JVMrol kiszolgalva. Nagy reszuk persze javaban keszult. Abbol a ket infobol, hogy a wiw lassu es javaban keszult azt a kovetkeztetest levonni, hogy 'a java lassu', hat... nem tul szakszeru... :) Nehez kivulrol megmondani, hogy egy oldal miert lassu. A wiw-esek megeskusznek ra, hogy szarra van optimalizalva, es tenyleg csak a szerveruk keves ekkora forgalom (es ilyen szolgaltatasok) biztositasara. Olyan 90-100 szerverrol van szo, allitolag nincs szuk keresztemtszet (egyenletes a terheles). Ebbol egyebkent asszem 5 db.-on clusterezett oracle fut, ez alapjan azt is mondhatnank, hogy az a szar :).

A webrol elerheto az architektura diagramjuk, es hat azt megnezve hat minimum gyanus, hogy tervezesi hibak vannak benne. (Persze a legtobbunk sosem csinalt, es sosem fog ekkora rendszert csinalni.)

Mesiter:
> hiszen a Microsoft-féle .Net platform által támogatott
> nyelveken kívül webes fejlesztésre más "igazi"
> ojjektumorientált nyelv nincs.

Ez nem igaz. Ott van a nepszeru Ruby (lassu, mint a dog) vagy a Python (joval gyorsabb, de meg mindig joval lassabb, mint a java). Mindketto OO, mindkettohoz van jo es gyors fejlesztest biztosito webes alkalmazas keretrendszer (Ruby: Rails, Python: Django es tarsai).

> amiben komoly része van a kódot futtattó webszerverek
> bénaságának is. Azaz a JAVA kódot kevésbé fordítják le
> a gép nyelvére a futtató rendszerek, mint pl. a .Net
> kódot az IIS.

Itt nagy a kavar. Eloszor is, a webszervereknek egyik technologia eseten sincs kozuk a forditashoz. Az a platform (JVM es .NET) szolgaltatasa. Masodszor a JVM (Java) eleg kiforrot JIT forditokkal rendelkezik (nyilvan a legtobben a Sun-os JVMben levo HotSpotot hasznaljak, persze anelkul, hogy tudnak - ettol is JIT). Menet kozben fordit (Just In Time), es eleg sok olyan optimalizalast is el tud vagazni, amit elore (AOT - Ahead Of Time) nem lehet. .NET kezdetben AOT forditott, Monda Laci kommentjebol viszont ugy tunik, hogy mar rajottek, hogy a JIT a jobb megoldas (vagy a Mono sajatja, de vegulis mindegy).

Ok, én nem a wiw lassúságából vontam le a következtetést, de arról, hogy hol futottunk bele problémába, nem tudok írni. (Nem írhatok).

A lényeg, hogy ott is lassú volt, zabálta a memóriát. Ugyanaz az alkalmazás (nagyjából) korábban php-ben volt megírva, s sokkal gyengébb vason elmuzsikált.
Aztán ugyanazt a forgalmat .Net-es Windows-os környezetben is lazán sikerült kiszolgálni.

Nem nehez szarra megirni egy alkalmazast javaban. Foleg ugy, hogy eleg sok seged technologiat fel lehet hasznalni, aminek ugye mindnek ismerni kell a mukodeset (pl. rosszul hasznalt EJBkrol horror torteneteket lehetett hallani). Ha ismered ezeket, akkor sokat segitenek a fejlesztesben, ha nem, akkor tobbet artanak, mint hasznalnak.

Memoria ugyileg a JVM alkalmazasok valoban tobbet foglalnak, mint a PHP (koszonhetoen tobbek kozt pont a JITnek), viszont a .NET nagysagrendileg kb. ugyanott van (en olyan teszteket lattam, ahol altalaban 1.5-2x tobbet foglalt, de az meg azert egy nagysagrend). A masik 'memoria zabalo' faktor az a mindenfele segedeszkozok hasznalata, pl. kozvetlen SQL query-k helyett object/relational mapper hasznalata. Itt nyilvan hatekonysagot aldozol cserebe a gyorsabb fejlesztesert es erthetobb kodert. Egy alkalmazas szerveren futo javas megoldast nem elegans osszehasonlitani nehany - esetleg meg frameworkot sem hasznalo - mezitlabas PHP scripttel. Mas a kezelhetoseguk, karbantarthatosaguk, stb. (Amugy 'igazi' j2ee alkalmazasszerverre eleg ritkan lenne szukseg ajava vilagban is, tul gyakran hasznaljak feleslegesen.)

De konkretumok nelkul tenyleg nehez mit mondani. Csak olyanokat lehet puffogtatni, hogy annyira szar nem lehet, ha a google is kiterjedten hasznalja (szemben a PHPvel meg a .NET-tel, amit viszont lathatolag egyaltalan nem).

Ok. .Net-ben is lehet szart írni, pl. .Net-ben nem illik string-concatenálni, hanem azonnal mehet ki a response-ba. Nos, ügyfél csinált ilyet, ahol egy 3 megabájtos stringet rakott össze, (kb 1000 darabból), s nem értette, hogy miért timeoutol el a weblapja. Szóval programozni tudni kell, s a rendszert is ismerni kell.

Illetve gondolom olyat nem illik, hogy str += "valami", hanem van ra egy builder osztaly. Ugyanez van javaban is :). (String inmutable, es az egy db. 'str += masik' hivas letrehoz es eldob 2-3 objektumot. Ez kicsiben nem baj, ciklusban viszont gyilkos.)

igen.