3D-s weblap

A kommunikaciora meg visszaterunk, epp debuggolom ki hogy mit is csinalnak a maiak, meg hogy is volt ez... Valszeg csak siman dumas az RPC, de pl. a mostani mail appban azt se latom hol szol a szervernek, vagy hova rakja le az adatbazist.

Ez a demagóg maszlag :) A lényeg, hogy valaki _EGY_ technológiát akar használni. ;)
De miert? Miert akarunk mi egyetlen technologiat hasznalni? Kinek? Ki kert ra?

Eleve egyetlen _technologiat_ soha nem lehet hasznalni. Az SQL es a DocumentDB ("NoSQL") akkor is ket kulon technologia, ha van kulonbsegeket elrejto API-m.

Egyetlen nyelvet, azt lehet hasznalni, de jo esellyel teljesitmenyt es esetleg feature-t vesztek.

Ezt en legutobb JS-sel oldottam meg, couchdb + node.js + browser trioban, mert a cegnek ahol dolgoztam epp volt 200 JS programozoja akinek lemegseztek a projektjet, es ugy gondoltam, ha elut a villamos, akkor jobb ha nem pythonban van a szerveroldal.

De amugy van ket teljesen eltero kornyezetem, az egyik egy kliens, ami konzumer appok eseten keves dedikalt RAM-ot es CPU idot jelent, de az mehet erre az egy dologra, meg van egy (sok) szerver, ami teljesen erre a feladatra van dedikalva, viszont tobb peldany is fut ugyanabbol.

Browser eseten egyetlen kotott nyelv van, ezt ugy hivjak hogy javascript. Nem tudok sajnos azonosulni azzal a gondolkodasmoddal, ami minden erovel ennek a nyelvnek a megerteset elkerulni igyekszik, es helyette eroltet valamit, ami abszolut opcionalis.

A maven workflowt természetesen nem zárja ki az, hogy nem java (a szókiforgatásba megintcsak nem megyek bele), de magadon kívül mutass fel még egyvalakit a 0,000001% közül, aki normális deploying workflowt alkalmaz a php-s pythonos ruby-s kóklerkedés mellé

Akikrol tudok, igy kapasbol: Nokia, Facebook, Yahoo. A nokianak - talan ez nem baj ha kiderul - szo szerint maven workflowja van, a Facebooknak egy picit sajatabb a rendszere de a lenyegen nem valtoztat, a Yahoo -rol most hirtelen nem tudnam megmondani, valszeg van benne maven. A mostani cegnel sajna nincs build, de nem is maradok sokaig :) Jenkins viszont van.

Symfony-s (PHP) rendszereket altalaban illik buildelni, ruby-s rendszereket szinten, pythonos (django) rendszereket szinten.

Az nem feltetlenul baj, ha valami lefele is skalazodik, es nem kell hozza egy tobb giga memoriat zabalo IDE, hogy osszerakjak egy prototipust, vagy kiprobaljak egy otletet, de felfele meg muszaj skalazodni, nyilvan a legtobb nagyobbacska cegnel pre-hookok vannak az SVN-ben, vagy automatikusan buildel egy jenkins vagy codecruiser es kiabal ha baj van.

Szoval bocsanat, nem akarok szemelyeskedni, de 2012 van, letezik az a nyelv, ami a vilag osszes szamitogepere fel van telepitve es varhatoan tudod hasznalni, javascriptnek hivjak, ha nem tetszik az egyeni szoc. problem, viszont mindazok a dolgok, amik szuksegesek ahhoz, hogy alkalmazasokat ezen a nyelven nagyuzemi modon lehessen fejleszteni nyilvan megjelent, hisz ipari igeny van ra azoknal a vallalatoknal, akiknek erre szukseguk van, nevezetesen, akik nagyuzemben fejlesztenek webalkalmazasokat.

Az, hogy ezt kicsiben is lehet csinalni, a java meg nem skalazodik lefele jol, hat ezt talan ne nevezzuk elonynek, ha nincs mindenkinek igenye arra hogy maven-osgi comboval deployolja a Bela es Tsa Bt honlapjat, ez nem feltetlenul gond.

Ja, hogy kkv fejlesztoirodabol Magyarorszagon tobb van, mint enterspajzbol, ill. az otttani enterspajzok olyan programozokat vesznek fel akik nem akarnak hallani mas nyelvekrol, emiatt tisztan keptelenek kodolni JS-ben (hogy utalom, ne tudd meg: amikor a programozo megorul ha rosszul van indentalva a java-kodja, de JQuery-ben irja a spagettit, mikozben latod, hogy a requestek-commitok 85%-a frontend jellegu, de o nem hajlando megtanulni...), szoval ez azt gondolom, nem technologiai kerdes, ezen a javascript civilizalt oktatasaval es valamifele nyitottabb hozzaallassal lehetne segiteni...

De ugye Crockford apank mondta mindig, hogy a szoftver nem hardver, itt platformvaltas 20 evente van, mert egyszeruen kihalasos alapon tunnek csak el a berogzodesek, pl. hogy a java "a" multiplatform.