ugrás a tartalomhoz

Konferenciát hoz a Prezi, a LogMeIn és a Ustream

Heilig Szabolcs · 2013. Jan. 27. (V), 00.55
MLOC.JS nemzetközi JavaScript konferencia
 ■
1

Komoly konferencia komoly

Hidvégi Gábor · 2013. Jan. 27. (V), 17.33
Komoly konferencia komoly előadókkal. IT-ben van pár nagyon erős cégünk, a fentiek mellett a Doclerről tudok még, bízom benne, a nemzetközi versenyben erősíteni tudják a pozícióikat. Magyarországnak - természeti erőforrások híján - humán oldalon van esélye kitörni, remélem, erre a döntéshozók is rájönnek, és segítik az iparágat érvényesülni.

Douglas Crockford így kezdi: a programozási nyelveket az aktuális divatok szerint tervezik. Én ezt úgy fogalmaznám inkább, hogy a mainstream számítástechnikát - az internettel az élen - az aktuális divatirányzatok befolyásolják leginkább, a racionalitást a sutba dobtuk már évtizedekkel ezelőtt.

Ami viszont nagyon furcsa, nyolc előadás a tizenötből arról szól, hogy 1, más nyelven készítsük el a kódot, mert hatékonyabb, mint a JS, 2, a JS hiányosságaira keressünk valamilyen áthidaló megoldást, mert igazából nem erre lett tervezve. Ha ezt jól értem, az nagyon nagy baj, ráadásul a HTML-t sem alkalmazásfejlesztésre találták ki.
2

Magyarországnak - természeti

Joó Ádám · 2013. Jan. 27. (V), 17.49
Magyarországnak - természeti erőforrások híján - humán oldalon van esélye kitörni, remélem, erre a döntéshozók is rájönnek, és segítik az iparágat érvényesülni.


Magyarországnak kiváló természeti adottságai és erőforrásai vannak, ipariakból – legalábbis mióta Trianonban egy részét elcsatolták, a másik részét pedig a szocialista vezetés vonatra lapátolta – van kevés. Ezekkel együtt egyetértek a meglátásoddal, sajnos a kezdeti ígéretek ellenére már az államtitkári képviselete sincs meg az ágazatnak a kormányzatban.

Ami viszont nagyon furcsa, nyolc előadás a tizenötből arról szól, hogy 1, más nyelven készítsük el a kódot, mert hatékonyabb, mint a JS, 2, a JS hiányosságaira keressünk valamilyen áthidaló megoldást, mert igazából nem erre lett tervezve. Ha ezt jól értem, az nagyon nagy baj, ráadásul a HTML-t sem alkalmazásfejlesztésre találták ki.


Ezeket a nyelveket más célra tervezték, ezért önmagukban már alkalmatlanok az ilyen komplexitású alkalmazások kiszolgálására, azonban adottságok, amiket nem lehet megkerülni. Assembly-ben sem lehet ma már üzleti alkalmazást írni, mégis fordítókat használunk, és nem a processzor értelmezi a PHP-t.
3

Melyik szocialistára

eddig bírtam szó nélkül · 2013. Jan. 27. (V), 17.57
Melyik szocialistára céloztál?
Mert Kádárék alatt relative köszönjük, viszonylag jól voltunk ipar terén. (valahogy azt mindig, mindenki hajlamos elfelejteni, hogy a nyereséget a "baráti országoknak" nyújtott "támogatások" vitték el leginkább.

Amikor jött a gengszterváltás, akkor vágták agyon az ipart, az viszont az akkori MDF-KDNP kormány számlájára írható. Ami meg azóta megy...
4

Példa

Hidvégi Gábor · 2013. Jan. 27. (V), 18.19
Hová tűnt a magyar titán?
6

Melyik szocialistára

Joó Ádám · 2013. Jan. 27. (V), 18.44
Melyik szocialistára céloztál? Mert Kádárék alatt relative köszönjük, viszonylag jól voltunk ipar terén. (valahogy azt mindig, mindenki hajlamos elfelejteni, hogy a nyereséget a "baráti országoknak" nyújtott "támogatások" vitték el leginkább.


Arra a szocialistára és a barátainknak küldött szerelvényekre. Különösen a Gábor által alább hivatkozott titánra.
8

Na csak azért, mert akkoriban

eddig bírtam szó nélkül · 2013. Jan. 27. (V), 19.08
Na csak azért, mert akkoriban azért még nyomokban volt egész jó iparunk... Az akkortájt gyártott Ikaruszok egy része tán a mai napig üzemel (nem csak itthon). Volt Rába, a CSM egy részének is elég jó híre volt a világban... Ezek többségét a gengszterváltás tette tönkre, mert egyszerűen kiárusították őket, a konkurencia meg gondoskodott róla, hogy mind tönkremenjen.
De volt egy magyar Pick, amiből nézd meg, mit csinált az azt felvásárló multi! Sorolhatnám... :-(
9

Mielőtt még visszasírnánk az

Joó Ádám · 2013. Jan. 27. (V), 19.37
Mielőtt még visszasírnánk az elvtársakat, tegyük hozzá, hogy a magyar ipar már a harmincas években világszínvonalú volt, anélkül, hogy a vas és acél országának kiáltottuk volna ki magunkat, és erőszakoltunk volna magunkra egy teljesen torz gazdasági szerkezetet.
10

Sokan nem tudják, hogy ha

Hidvégi Gábor · 2013. Jan. 27. (V), 19.47
Sokan nem tudják, hogy ha 1914-ben nem tört volna ki az első világháború, a Monarchia központja Bécsből átköltözött volna Budapestre két éven belül.
12

Ehhez tudsz forrást?

Joó Ádám · 2013. Jan. 27. (V), 19.56
Ehhez tudsz forrást?
19

Történelemből tanultam, de

Hidvégi Gábor · 2013. Jan. 27. (V), 21.33
Történelemből tanultam, de majd utánajárok.
11

Visszasírni? Hát... azt

eddig bírtam szó nélkül · 2013. Jan. 27. (V), 19.50
Visszasírni? Hát... azt hiszem, te nagyon fiatal lehetsz.
Ad 1 - nincs mit visszasírni, most is pontosan ugyanaz a rendszer van, leszámítva, hogy most szabadon mehetsz amerre akarsz
Ad 2 - azért megbeszélhetnéd pár hajléktalannal, munkanélkülivel, egyéb nyomorgóval, hogy mennyivel szívesebben élne abban az "elnyomásban", amikor legalább a munkásszálló ott volt a feje fölött és nem kellett attól tartania, hogy megfagy, éhenhal stb.!

És nem volt több adóssága az országnak, mint most. (értékében, nem forintosítva)
De már máskor is írtam: politizálást hagyjuk meg más blogokra/fórumokra! Ha gondolod, gyere át a szemétdombomra, ott a kutyát sem zavarja a téma, itt meg...
13

Hát... azt hiszem, te nagyon

Joó Ádám · 2013. Jan. 27. (V), 19.58
Hát... azt hiszem, te nagyon fiatal lehetsz.


Hogy jön ez most ide? :) A kor nem erény, hanem állapot.
16

Úgy, hogy valószínűleg nem

eddig bírtam szó nélkül · 2013. Jan. 27. (V), 20.31
Úgy, hogy valószínűleg nem éltél abban a rendszerben, csak szájhagyomány útján van róla infód.
17

Még épp beleszülettem, de nem

Joó Ádám · 2013. Jan. 27. (V), 20.45
Még épp beleszülettem, de nem hiszem, hogy bármit is számít. A népirtási statisztikák tények, ahogy a géppisztoly csöve is a hét éves apám tarkóján ’56-ban.

De ha folytatjuk, akkor tényleg máshol.
18

Én nem 56-ról beszélek, hanem

eddig bírtam szó nélkül · 2013. Jan. 27. (V), 21.02
Én nem 56-ról beszélek, hanem a 70-es, 80-as évekről. De mindegy, tényleg hagyjuk!
14

Hát ezt nem bírok ki hogy ne

Karvaly84 · 2013. Jan. 27. (V), 20.10
Hát ezt nem bírok ki hogy ne szóljak hozzá az offoláshoz :D

Kádár idejében jó volt az ipar ez tény...

Pixelt nem tűrő vélemény törölve. – Joó Ádám


És mikor mentek akkor vitték magukkal az ipart is. Ami akkor volt az akkor sem a mienk volt már, csak itt gyűjtötték a profitot, amihez magyar állami cégek kelletek. Szépen el somfordáltak offshore cégekbe, és vitték a tőkét is. A magyar ipar most is jó, csak már nem magyar. De ez csak az én elméletem, ha már offolunk :D
15

Itt zárjuk is le az offot :)

Joó Ádám · 2013. Jan. 27. (V), 20.19
Itt zárjuk is le az offot :)
5

Én a JS-sel kapcsolatban nem

Hidvégi Gábor · 2013. Jan. 27. (V), 18.39
Én a JS-sel kapcsolatban nem látok problémát, eddig minden feladatot meg tudtam vele oldani, a HTML persze annál inkább kényelmetlen, köhögős. Egyszer nézegettem XFORMS-ban készített űrlapokat, na, az egy jó példa volt arra, amilyennek lennie kéne a webes alkalmazásfejlesztésnek. A Microsoftnak meg kb. tizenöt éve van az Internet Explorerben beépített alkalmazásfejlesztő eszköze.

Meg, amit nem értek, miért erősítik a kliensoldalt? Hisz az köztudottan nem megbízható. Eszembe nem jutna adatbevitelen kívül bármit kitenni a böngészőbe, hisz a szerveroldalon kell mindent úgyis feldolgozni, ehhez pedig nem szükséges nagyon bonyolult JS-t fejleszteni. Vagy mit nem veszek figyelembe?
7

Én a JS-sel kapcsolatban nem

Joó Ádám · 2013. Jan. 27. (V), 18.53
Én a JS-sel kapcsolatban nem látok problémát, eddig minden feladatot meg tudtam vele oldani


Rosszul skálázódik, mert nem nagy kódbázisra tervezték. Hiányoznak belőle olyan nyelvi elemek, amik más nyelvekben megvannak.

Meg, amit nem értek, miért erősítik a kliensoldalt? Hisz az köztudottan nem megbízható. Eszembe nem jutna adatbevitelen kívül bármit kitenni a böngészőbe, hisz a szerveroldalon kell mindent úgyis feldolgozni, ehhez pedig nem szükséges nagyon bonyolult JS-t fejleszteni. Vagy mit nem veszek figyelembe?


A felhasználói élményt. Az XForms egy jó példa: az ellenőrzést a kiszolgálón is el kell végezd, de mennyivel jobb, ha oldalújratöltés nélkül kap a felhasználó visszajelzést a bevitelkor. Rengeteg eszközhöz még hozzá kell tudjunk férni a kliensnél, tudni kell integrálni a rendszerrel és más alkalmazásokkal. Adott esetben érdemes lehet bizonyos számításokat is kihelyezni a kliensre, így nem terhelve a kiszolgálót. Általában meg lehet spórolni a várakozást a kiszolgálóra, ha helyben végzünk feladatokat. És persze a dizájn terén is rengeteg lehetőség van még a kliensoldalban.

Arról nem is beszélve, hogy a JavaScript már nem csak kliensoldali nyelv…
20

Arról nem is beszélve, hogy a

virág · 2013. Jan. 28. (H), 10.12
Arról nem is beszélve, hogy a JavaScript már nem csak kliensoldali nyelv…


Így igaz és ez egy nagyon fontos mondat, mert innentől kezdve már nagyon nehéz beskatulyázni a JavaScript-et, aki kicsit is ismeri például a Node.js-t annak világos, hogy miért :)
21

node

Hidvégi Gábor · 2013. Jan. 28. (H), 16.52
Az tény, hogy létezik a node.js, de más kérdés, hogy a Hello World-ön kívül milyen komolyabb fejlesztést benne végezni?

1, A külső eszközök drivereihez nincs olyasféle támogatás, mint php-ban, ha szerencséd van, az adatbáziskezelődhöz a gyártója készített ilyet, különben pedig a közösség által fejlesztett (van hozzá támogatás? meddig?), legtöbbször JS-ben megírt, azaz nem túl hatékony illesztőket használhatsz.

2, A callback-es dolog miatt teljesen új felfogást kíván a programozás. Eddig volt egy függvényed, ami egy feladatért volt felelős (átlag programozási nyelvben), ha van mondjuk tíz lekérdezésed, akkor lesz helyből tíz függvényed. Jó szem kell hozzá, ha át szeretnéd látni. Mondjuk ezt még meg lehet szokni, de elsőre mindenképp furcsa.
22

A külső eszközök drivereihez

Joó Ádám · 2013. Jan. 28. (H), 18.18
A külső eszközök drivereihez nincs olyasféle támogatás, mint php-ban, ha szerencséd van, az adatbáziskezelődhöz a gyártója készített ilyet, különben pedig a közösség által fejlesztett (van hozzá támogatás? meddig?), legtöbbször JS-ben megírt, azaz nem túl hatékony illesztőket használhatsz.


Miért, a PHP-nál nem úgy működik, hogy ha szerencséd van vagy a gyártó vagy a közösség által (van hozzá támogatás? meddig?), legtöbbször PHP-ban megírt, azaz nem túl hatékony illesztőket használhatsz?

Vagy ahogy a PHP-ban, úgy Node.js-ben is leülsz és megírod C-ben, amire szükséged van, és nincs rá kész megoldás.

A callback-es dolog miatt teljesen új felfogást kíván a programozás. Eddig volt egy függvényed, ami egy feladatért volt felelős (átlag programozási nyelvben), ha van mondjuk tíz lekérdezésed, akkor lesz helyből tíz függvényed.


Miért baj ez? A függvény nem más, mint egy tetszőleges időpontban végrehajtható kódblokk.
if (io() == IO_SUCCESS) {
    // :)
} else {
    // :(
}
io(function () {
    // :)
}, function () {
    // :(
});
Te látsz különbséget?
23

Miért, a PHP-nál nem úgy

Hidvégi Gábor · 2013. Jan. 28. (H), 19.11
Miért, a PHP-nál nem úgy működik, hogy ha szerencséd van vagy a gyártó vagy a közösség által (van hozzá támogatás? meddig?), legtöbbször PHP-ban megírt, azaz nem túl hatékony illesztőket használhatsz?
Nem egy kategória a kettő. Elég megnézni a PHP changelogot, hogy lásd, kik foglalkoznak a kiegészítők hibáival.

Tegyük fel, hogy MySQL drivert keresek, melyiket válasszam a felsoroltak közül? Legyen mondjuk a mysql nevezetű, verziója 2.0.0-alpha5.

A másikra írtam, hogy szokható.
24

Alfát élesre? Hááááát... én

eddig bírtam szó nélkül · 2013. Jan. 28. (H), 19.57
Alfát élesre? Hááááát... én nem tenném.
25

Másra való

Poetro · 2013. Jan. 28. (H), 21.23
Nem hiszem, hogy PHP-val kellene összehasonlítani. És főleg nem MySQL driverrel. Gondolom, ha elkezdesz mondjuk Erlang-ban, Lisp-ban, Haskell-ben programozni, sem a MySQL driverrel kezdesz. Eleve van a MySQL-nél rengeteg jobb adatbáziskezelő, ami jobban illik azokhoz az alkalmazásokhoz, amiket Node.js-ben érdemes megírni. Ráadásul a Node.js nem egy nyelv, hanem csak egy alap, és sose tekintette a részének, hogy különböző drivereket írjanak az alap keretrendszerben bármihez, ami nem közvetlenül kapcsolódik az I/O-hoz.
26

Mire való?

Hidvégi Gábor · 2013. Jan. 28. (H), 21.54
Akkor mégis milyen adatbázisokkal használják? NoSQL-lel? Pont a múlt héten volt erről téma itt, hogy a mongodb nem tud sorrendezni. Nem csak drivert, hanem működő adatbáziskezelőt is kell mellé keresni? Szeretek JS-ben programozni, már párszor nekifutottam, de nem jöttem rá, mire is való ez tulajdonképp. Sajnos nem az én igényeim kielégítésére, de akkor kiére? Hogy lehet így akkor benne alkalmazást fejleszteni? Szeretném megérteni ezeket.
27

Én úgy tudom, a Postgre,

Poetro · 2013. Jan. 28. (H), 22.13
Én úgy tudom, a Postgre, CouchDB, SQLite driverek jók, és használják is őket éles környezetben. Valamint nem minden alkalmazáshoz kell adatbázis, a legtöbb általam ismert alkalmazás egy API-t használ, ezen keresztül fér hozzá adatokhoz. Ilyen például a Linkedin vagy a Walmart mobil valamint a MySpace weboldalai.

De természetesen nem csak webre alkalmas. Én szívesen használok különböző parancssori eszközöket különböző feladatok végrehajtása, például LESS fordítása, JS, CSS minify-olása, különböző adatbányász feladatok. De segítségével vezérelnek különböző eszközöket is, például robotokat, vagy szerverek közötti kommunikációban is jelentős szerepet vállalnak.
28

Köszönöm a választ. A

Hidvégi Gábor · 2013. Jan. 29. (K), 10.21
Köszönöm a választ. A kiszolgálórész egyszálú működéséből adódóan egyébként is csak korlátozottan alkalmas nagyobb tartalmak küldésére, tehát weboldalakhoz nem túl jó, kis adatcsomagokkal operáló alkalmazásokhoz talán inkább.
29

Mostanában küldtem be pár

Poetro · 2013. Jan. 29. (K), 12.18
Mostanában küldtem be pár csiripet, inspiráló jelleggel, mások mire használják.
31

Ugye tudod, hogy az Nginx és

Joó Ádám · 2013. Jan. 30. (Sze), 04.08
Ugye tudod, hogy az Nginx és a Lighttpd pont ugyanúgy működik, mint a Node.js?
32

Igen, amikor ezen a szálon

Hidvégi Gábor · 2013. Jan. 30. (Sze), 12.36
Igen, amikor ezen a szálon felmerült a node.js, akkor utánaolvastam a dolgoknak, hogyan működik pontosan a node, és ott írtak arról, hogy az nginx is egyszálú.

Ez egy webszerver esetében még elfogadható elképzelés, mert végeredményben statikus tartalmat szolgál ki (a fájlok ugye triviálisak, de egy script eredménye is logikailag, a webszerver szempontjából is ugyanaz), dolgoznia nem kell, az egyetlen dolga, hogy a kérésre választ adjon, tehát a legtöbbet IO-ra vár (azaz ki tud szolgálni bármi mást).

A node.js ezzel szemben scripteket futtat, azaz nem tudod megmondani, hogy mikor végez, főleg egy nagyobb oldal összeállításakor.
33

Többször ellent mondasz

Joó Ádám · 2013. Jan. 30. (Sze), 12.54
Többször ellent mondasz önmagadnak:

A kiszolgálórész egyszálú működéséből adódóan egyébként is csak korlátozottan alkalmas nagyobb tartalmak küldésére, tehát weboldalakhoz nem túl jó


vs.

Ez egy webszerver esetében még elfogadható elképzelés, mert végeredményben statikus tartalmat szolgál ki


a fájlok ugye triviálisak, de egy script eredménye is logikailag, a webszerver szempontjából is ugyanaz


vs.

A node.js ezzel szemben scripteket futtat



Egyébként:

A node.js ezzel szemben scripteket futtat, azaz nem tudod megmondani, hogy mikor végez, főleg egy nagyobb oldal összeállításakor.


Egy nagyobb oldal összeállításakor is az IO az, ami elviszi az időt, arra pedig nem vár, emellett a teljes oldal összeállítását sem kell megvárja, mert streameli a tartalmat.

Ha pedig tudod, hogy számításigényes feladatot indítsz, akkor azt ki tudod tenni önálló szálba.
34

Nincs ellentmondás: "A

Hidvégi Gábor · 2013. Jan. 30. (Sze), 13.44
Nincs ellentmondás:
"A kiszolgálórész egyszálú működéséből adódóan egyébként is csak korlátozottan alkalmas nagyobb tartalmak küldésére, tehát weboldalakhoz nem túl jó"-t a node-re írtam, és a 32-ben leírtam, miért: mert amikor a node scriptet futtat, addig blokkolja a többi kérés kiszolgálását (mivel egy szálon dolgozik). Ha node-dal állítasz össze nagy oldalt, akkor ez lesz. Webszerver esetében IO-ra vársz, azaz egy fájl beolvasására memóriából, vagy hogy a scripted végezzen, utána kiküldöd a kimenetre, tehát közben nem blokkolsz semmit.

Olvastam egy jó, szemléltető példát, azt átültetem ide:

Az nginx-et nagyjából így kell elképzelni: odamész egy gyorsétterembe, kérsz egy hamburgert. Az nginx beszól a konyhába, hogy hamburger rendel, ha kész, a szakácsok kirakják az ablakba, ő átadja neked. Közben mások kéréseit is ki tudja szolgálni.

A node.js-t így: odamész egy gyorsétterembe, kérsz egy hamburgert, akkor ő beteszi a mikróba a hozzávalókat, aztán tesz bele salátát, ketchupot, és ha kész, odaadja. Ha csak egy üdítőt kérsz, akkor megvan mindjárt, akkor több mindenkit tud ugyanannyi idő alatt kiszolgálni.

Az apache-ot talán így: van egy hatalmas épületkomplexum, tele hamburgeresekkel. Odamész az elsőhöz, kérsz egy hambit, a konyha elkészíti, odaadják. Ha jön másvalaki, akkor egy másik hamburgereshez küldik. Ha túl sok kérés jön be, akkor úgy tudják bővíteni, hogy új hamburgereseket építenek hozzá.

Tehát másra kell használni az apache-ot, mint az nginx-et.
35

A node.js-t így: odamész egy

Poetro · 2013. Jan. 30. (Sze), 14.28
A node.js-t így: odamész egy gyorsétterembe, kérsz egy hamburgert, akkor ő beteszi a mikróba a hozzávalókat, aztán tesz bele salátát, ketchupot, és ha kész, odaadja. Ha csak egy üdítőt kérsz, akkor megvan mindjárt, akkor több mindenkit tud ugyanannyi idő alatt kiszolgálni.

Ez azért nincsen így. Mert a te szkripted is, amíg várakozik, addig visszaadja a vezérlést, és addig újabb kéréseket lehet kiszolgálni. Például
  1. Beérkezik a kérés.
  2. Adatbázisból és fájlrendszerből kell valami. Vezérlés vissza az eseménykezelőnek - újabb kéréseket tudunk kiszolgálni.
  3. Megjött a válasz az adatbázisból. Vezérlés vissza az eseménykezelőnek - újabb kéréseket tudunk kiszolgálni.
  4. Megjött a válasz a fájlrendszerből. Most hogy már minden megvan összeállítjuk a tartalmat, és visszaadjuk vele a vezérlés vissza az eseménykezelőnek - újabb kéréseket tudunk kiszolgálni.

Ha csak adatot kell mondjuk egy I/O forrásból a másikba átrakni, azt egyszerűen át lehet pumpálni (stream.pipe), ekkor egyből visszaadódik a vezérlés az eseménykezelőnek.
36

Így van

Hidvégi Gábor · 2013. Jan. 30. (Sze), 14.40
Ezért fogalmaztam úgy, hogy beteszem a mikróba a dolgokat felmelegedni (adatbázisból lekérem az adatokat), addig ki tudok szolgálni mást is, aztán mikor megvan, feldíszítem őket, és odaadom a megrendelőnek. A lényeg, hogy minél kevesebbet kelljen dolgoznom, hogy ne legyen hosszú a sor.
37

A másikra írtam, hogy

Joó Ádám · 2013. Feb. 4. (H), 05.00
A másikra írtam, hogy szokható.


Igazad van, közben én is belefutottam olyan mintákba, amiket nem lehet egyszerűsíteni: http://weblabor.hu/blogmarkok/114111
30

Szia Gábor! Utolsó

tisch.david · 2013. Jan. 29. (K), 13.07
Szia Gábor!

Utolsó bekezdésed kapcsán jutott ez a szösszenet eszembe: mi asztali környezetben Magic fejlesztő eszközt használunk. Rengeteg érdeme mellett sok hibája is van az eszköznek, webre se használnám, de van egy jópofa elgondolásuk: megírod egyszer, egy helyen a kódot, aztán megmondod neki, hogy ebből mi az, ami a szerveren hajtódjon végre, és mi az, ami a kliens oldali virtuális gépen. Valami ilyesmit szívesen látnék webre is. :)

Üdv:

Dávid