2013. március 27., szerda

Portolják az Unreal Engine-t JavaScript-re


Utána néztem kicsit a technológiának. C/C++ kódot eddig is lehetett JavaScript-re fordítani úgy, hogy lefordítottuk LLVM virtuális gépre, amit Emscripten-el lehet JavaScript-re fordítani. Pár alkalmazást portoltak is már így JavaScript-re. Persze ez azért jelentős teljesítmény romlást is jelent, mivel a JavaScript ugye nem natív kód.

Erre a Google megoldása a NaCl (Native Client), amivel natív kódot futtathatunk a böngészőben. Ez egy JavaScript-től teljesen független saját technológia, tehát a támogatásához külön plugin kell, illetve minden platformra külön kell fordítani (bár ha jól tudom, itt is készül LLVM-es megoldás, amit az adott platformon futtatás előtt fordítanak natív kódra).
 
A Mozilla megoldása (amit most az Unreal Engine-hez is használnak) egy asm.js nevű kiterjesztés a JavaScript-hez. Az asm.js-es kód sima JavaScript, de van benne néhány speciális változó, stb. amit az asm.js-t támogató JavaScript engine-ek jobban tudnak optimalizálni. Ezeknek a változóknak fix típusa van például, így ki lehet pl. hagyni a dinamikus változókat érintő plusz konverziókat, ellenőrzéseket, stb. illetve előre natív kódra lehet fordítani, így nem kell interpreterrel futtatni. Ennek ugye az a nagy előnye, hogy sima JavaScript, nem kell hozzá semmilyen böngésző plugin (mint az NaCl esetén), mégis natívhoz közeli sebességgel fut.

Itt még érdemes megemlíteni szerintem a Dart-ot, ami ugyancsak JavaScript-re fordítható, tehát plugin nélkül is tud futni a böngészőben, de ha a saját virtuális gépben fut, akkor az opcionális típusoknak, SIMD műveleteknek, stb. hála natív kódhoz közeli sebességgel futtathatunk kódot. Mivel a js fordítónak köszönhetően ehhez sem kell külső plugin, ezért ez sokkal inkább tekinthető az asm.js alternatívájának.  

Akármelyik technológiát is nézzük, a lényeg, hogy a webes alkalmazások lassan de biztosan kezdik teljesítményben is felvenni a versenyt a natív alkalmazásokkal.

#blog  

Reshared post from +TechCrunch
To show off what game developers can do with a modern browser & without plugins, Mozilla and Epic teamed up to port Unreal Engine 3 to the web.





Mozilla And Epic Games Bring Unreal Engine 3 To The Web, No Plugin Needed | TechCrunch
TechCrunch is a leading technology media property, dedicated to obsessively profiling startups, reviewing new Internet products, and breaking tech news.

2013. március 26., kedd

Egy nagyon jó előadás Dr

Orosz Lászlótól, ahol Dr. Egely György könyveiről beszél

Az előadás a könyvekben elkövetett hibákról szól. Érdemes megnézni mindenkinek, akit az örökmozgó téma érdekel. Az érdekessége, hogy az előadást Egely is végigülte a hallgatókkal. A végén azért van Egely-től egy ügyes odavágás, amit nem tudott a prof. jól hárítani. Azt remekül megmutatta az előadás, hogy milyen matematikai és fizikai hibákat ejtett Egely (azért Egely zsenialitása mellet szól, hogy ezeket nem mindig könnyű kiszúrni), és ezzel a célját maradéktalanul teljesítette is. Ugyanakkor arra nem kaptunk választ, hogy a jelenségek maguk léteznek-e. Valószínűleg a gyakorlat is a professzort igazolná, de ezt a kérdést valóban csak kísérletekkel lehet eldönteni, ahogyan Egely is felhozta az előadás végén. És ebben a helyzetben tényleg hibás volt a prof. hozzáállása, hogy "Nem kell elvégeznem a kísérletet, a nélkül is le tudom vezetni". A dolognak egyébként könnyen pontot lehetne tenni a végre azzal, hogy Egely-ék hozzák a jelenséget, a prof. a matekot és a fizikát. Elvégzik a mérést, és ha azt prof. magyarázni tudja az eszközkészletével, akkor neki volt igaza, ha nem, akkor Egely-ék valóban találtak valamit. 

Köszönet a linkkért +Krisztián Kovács -nak.

#blog  

Áltudományos mechanika - Dr. Orosz László előadása

2013. március 17., vasárnap

Az ember tragédiája mint Cloud Atlas


Az ember tragédiájából (http://hu.wikipedia.org/wiki/Az_ember_trag%C3%A9di%C3%A1ja - igen igen az a Madách féle még irodalom óráról) kicsit kiszínezve, hollywoodi köntösbe bújtatva szerintem nagyon jó Cloud Atlas szerű filmet lehetne készíteni. A szereplők (Ádám, Éva, Lucifer és pár mellékszereplő) ugyanúgy reinkarnálódnának az egyes korokon át, mint a Cloud Atlas szereplői. Ugyanúgy be lehetne csempészni kis áthatásokat az egyes idősíkok közé, bár igazából ezt nem is kell külön erőltetni, mivel a tézis-antitézis-szintézis folyam önmagában megteremti a síkok egymásra hatását. A Falanszter részt kicsit ki lehetne csicsázni egy valódi jövőbeli világgá repülő autókkal, robotokkal, miegymás. Az űr béli színt valahogy úgy magyarázni, hogy Ádám milliárdosként valami űrbázisra költözik ki, stb. Kéne rajta dolgozni, csiszolgatni kicsit a mai kor szellemének megfelelően, de szerintem zseniális lenne. Megkockáztatom, hogy sokkal jobb, mint a Cloud Atlas (ami amúgy maga sem rossz film), sokkal mélyebb történettel és mondanivalóval. Szinte fáj, hogy ez a film bizonyára nem fog elkészülni ... 

#blog   

jQuery alapok


A jQuery az egyik legelterjedtebb JavaScript programkönyvtár. Rengeteg oldal használja, és sok JavaScript keretrendszer épül rá. A követezőkben nagyon röviden azt szeretném bemutatni, hogy mi is ez a jQuery, miért jó, és mire lehet használni. A leírás olvasása alapvető HTML és CSS és JavaScript ismereteket igényel. Ezekre nem térek majd ki külön, mert nagyon elnyújtaná a bejegyzést.

Ha egy mondatban kellene meghatározni, akkor azt mondanám, hogy a jQuery olyasmi mint a CSS, csak itt nem designt rendelünk az egyes HTML elemekhez, hanem működést. Az elemek kijelöléséhez ugyanazokat a szelektorokat használhatjuk, mint CSS esetén, és az így kijelölt elemeket manipulálhatjuk, eseménykezelőket aggathatunk rájuk, lekérdezhetjük az értéküket, vagy valamilyen más működéssel láthatjuk el. Hamarosan mutatok példákat is, de gyorsan nézzük át, mik ennek az egésznek az előnyei:

- Ahogyan a CSS esetén elválik a design a HTML kódtól, ugyanúgy leválasztható a jQuery segítségével a működés is az elemekről. (Ez véleményem szerint néha hasznos, néha nem, de ebbe most ne menjünk bele.)
-  A jQuery-s működés elrejti előlünk a böngészők közötti különbséget. Amire adott esetben többféle elágaztatott JavaScript-re lenne szükség, az jQuery-ben egyetlen hívással megoldható. A jQuery egyébként (tudtommal) az összes ismert nagy böngészőt támogatja, ide értve a desktop és mobil változatokat is.
- Sok mindent sokkal egyszerűbb megoldani jQuery-ben, mint tiszta JavaScript-ben, ráadásul nagyon egyszerűen lehet hozzá új funkciókat adni pluginek formájában, és rengeteg plugin elérhető hozzá a weben. Köztük olyan komplex dolgok is, mint wysiwyg editor, adattáblák, tree komponens, miegymás.

No, akkor nézzük is, hogy megy mindez a gyakorlatban. Ha jQuery-t szeretnénk használni, akkor ugye egy script tag-el be kell hivatkozni. Ezt két módon tehetjük meg. Vagy letöltjük a jQuery aktuális változatát, és azt használjuk, vagy CDN-ről hivatkozzuk be. A CDN egy fix hely a weben, ahol az aktuális változat megtalálható. A legismertebb ilyen CDN a Google féle (http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js). Ennek az az előnye, hogy innen a böngésző egyszer letölti a JavaScript kódot, és utána cache-eli. Mivel sokan használják így a jquery-t, ezért jó esetben már valószínűleg cache-elve van a böngészőben, így mikor a mi weblapunk töltődik be, ezt már nem kell újra letölteni. Olyan baromi nagy különbség amúgy nincs a két megoldás közt, csak érdekesség.

Ha behivatkoztuk a lib-et, elkezdhetjük használni. Készítsünk egy kis HTML olalt, amin van egy gomb (button tag). Rakjunk erre egy eseménykezelőt, ami klikkelésre kiír valami üzenetet. Ez így néz ki:

$('button').click(function(){
  alert('Hello World');
})

Láthatóan nem valami bonyolult. A jQuery-re a $ fv.-el tudunk hivatkozni, aminek paramétere egy css szelektor. Ezek ugyanazok a jelölések, amit css esetén használunk az elemek kijelölésére. Tehát a $('button') jelen esetben azt jelenti, hogy minden button elem-re vonatkozzon a kijelölés. Ezt ki is próbálhatjuk. Rakjunk be még egy gombot az oldalra. Így akármelyikre gyomunk, meg fog jelenni az alert. A $ jel helyett használhatjuk a jQuery nevet is, de olyat is láttam, ahol jq-t használtak. Tehát a $('button'), a jQuery('button') és a jq('button') ugyanazt jelölik. Ha kijelöltük az elemet, akkor jöhetnek az azon végzett műveletek. Jelen esetben a click, ami egy eseménykezelőt helyez az adott elemre. Most nézzünk egy olyan példát, ahol nem eseménykezelőt rakunk az elemre, hanem valamilyen manipulációt végzünk rajta.

$('button').css('font-weight', 'bold');

Ez a sor az összes gomb font-weight tulajdonságát bold-ra állítja, tehát minden gomb felirata vastagon lesz szedve. A jQuery hívásokat láncolhatjuk is, így:

$('button').css('font-weight', 'bold').click(function() {
  alert('!!!');
})

Persze kettőnél sokkal több hívás is követheti egymást, így egész komplex működéseket egész egyszerűen írhatunk le. Ha egy eseménykezelőben az aktuális elemre akarunk hivatkozni, azt a this kulcsszóval tehetjük meg. A this ez esetben a HTML objektumot jelöli, így ha jQuery-s műveletet akarunk rajta végezni, akkor $()-be kell rakni. Erre itt egy példa:

$('button').click(function() {
  $(this).hide('slow');
});

Ez így annyit csinál, hogy ha megnyomjuk a gombot, akkor szépen animálva elrejti azt. De ez alapján elrejthetünk/megjeleníthatünk komplett formokat, stb.

Eddig ugye minden esetben a gombok mindegyikére vonatkozott az adott művelet. Ha pontosabban ki szeretnénk jelölni a célt, akkor használjuk a szokásos css szelektorokat. Adjunk az egyik gombnak egy 'gomb' class-t. Erre a $('.gomb') -al hivatkozhatunk. Így csak a 'gomb' osztályú elemekre fog hivatkozni az adott hívás. Ha egy adott elemet akarunk kijelölni, akkor adjunk neki valami id-t. Ha 'gomb' id-t adunk neki, akkor a css-hez hasonlóan $('#gomb') -al hivatkozhatunk rá. De persze mennek a bonyolultabb szelektorok is. Pl. az item class-u li elemeken belüli gomb class-u gombok, stb.

Amivel még gyakran találkozni, az a $('document').ready esemény, ami jQuery-ben az onload megfelelője. Tehát amit ide írunk, az akkor fog végrehajtódni, ha már teljesen betöltődött az oldal. Amolyan ökölszabályként elmondható, hogy érdemes a teljes jQuery kódot ebbe írni, valahogy így:

$( document ).ready(function() {
  $('button').click(function() {
    $(this).hide('slow');
  });
  ...
});

Hát, indulásnak kb. ennyi szerintem elég. Rengeteg példát találni weben, és a jQuery honlapján (http://jquery.com/). Igény esetén készülhet hasonló leírás egy egy témáról, de mivel a jQuery eszközkészlete elég szerteágazó, írjátok le, hogy pontosan melyik része érdekel, és ha azzal a résszel kapcsolatban van tapasztalat, azt szívesen leírom.

#blog   #jquery

2013. március 16., szombat

Készítettem egy ilyen kis PHP + AngularJS mintát

Van benne kis PHP, kis AngularJS, kis SQL (SQLite-al), meg egy kis JavaScript. Akit érdekel, Cloud9-en ki tudja próbálni, bele tud nézni a forrásba, esetleg igény esetén kár ki is elemezgethetjük, hogy mi mit csinál. 

Reshared post from +Laszlo Fazekas
PHP messageboard

Kíváncsi voltam, hogy lehet-e csupán +AngularJS használatával "értelmes" üzenőfalat csinálni. Végül is az eredmény egy kis (a sallangot leszámítva 1 fájl) PHP alkalmazás lett. Az üzenetek tárolására sqlite-ot használtam, a szerver oldal PHP, a kliens oldal pedig AngularJS és egy kis AngularUI (csak az animáció miatt). Akit érdekel, klónozza le Cloud9-be (itt van hozzá leírás: https://plus.google.com/115334992192871078712/posts/gxfBQsDEsp4) , és ki tudja próbálni. Ehhez ugye index.php-n nyomjunk egy Run-t, majd két böngészőfülön nyissuk meg az url-t. Ha az egyik oldalon írunk valamit, akkor az a másik oldalon is megjelenik 5mp-es frissítéssel. Nem nagy valami, de a célnak pont megfelel.

Gitub repo: git://github.com/TheBojda/php-messageboard.git

#blog   #php   #angularjs   #angularui  

PHP messageboard


Kíváncsi voltam, hogy lehet-e csupán +AngularJS használatával "értelmes" üzenőfalat csinálni. Végül is az eredmény egy kis (a sallangot leszámítva 1 fájl) PHP alkalmazás lett. Az üzenetek tárolására sqlite-ot használtam, a szerver oldal PHP, a kliens oldal pedig AngularJS és egy kis AngularUI (csak az animáció miatt). Akit érdekel, klónozza le Cloud9-be (itt van hozzá leírás: https://plus.google.com/115334992192871078712/posts/gxfBQsDEsp4) , és ki tudja próbálni. Ehhez ugye index.php-n nyomjunk egy Run-t, majd két böngészőfülön nyissuk meg az url-t. Ha az egyik oldalon írunk valamit, akkor az a másik oldalon is megjelenik 5mp-es frissítéssel. Nem nagy valami, de a célnak pont megfelel.

Gitub repo: git://github.com/TheBojda/php-messageboard.git

#blog   #php   #angularjs   #angularui  

2013. március 15., péntek

Ez nem annyira alap JavaScript, de ha valaki rendelkezik alapvető HTML és JavaScript...

Ez nem annyira alap JavaScript, de ha valaki rendelkezik alapvető HTML és JavaScript tudással (tényleg elég az alap tudás), az már csodákat tud művelni AngularJS segítségével. Ezért gondoltam, hogy érdemes ide is bepostolni.

/cc +Robert Cartman +Nádi András 

Reshared post from +Laszlo Fazekas
AngularJS (1. alapok)

Már egy ideje ígérgetem, hogy írok egy rövid bejegyzést arról, hogy mi is az AngularJS. Amikor elsőnek találkoztam vele, úgy jellemezte valaki a rendszert, hogy ilyen lenne a HTML nyelv, ha most találták volna fel. Tehát felfoghatjuk akár a jelenlegi szabvány felokosításának is.

Kicsit jobban kifejtve az AngularJS egy nagyon szépen megkonstruált MVC keretrendszer. Ez valami baromi misztikus dolognak hangzik, pedig nem az. Az MVC a Model View Controller hármas rövidítése. és mostanában tulajdonképpen szinte minden adatokat kezelő alkalmazás ezt a felépítést használja. Az MVC annyit jelent, hogy az alkalmazást három rétegre osztjuk. Az adattartalomra (model), a megjelenítésre (view), és a működésre (controller). Ezek a rétegek körkörösen hivatkoznak egymásra. Az adattartalmat (model) a view réteg jeleníti meg, ahonnan mindenféle felhasználói események hatására meghívódik valami működés (controller), ami megváltoztatja az adattartalmat, és itt körbe is ért az egész. Talán még így is ködös kicsit az egész, úgyhogy nézzünk egy példát. Egy sima todo listát, ahová új elemeket lehet felvenni, és törölni onnan (mint mondjuk egy bevásárló lista). Itt ugye az adattartalom (model) az a lista, ami a todo elemeket tartalmazza. A view az ezt megjelenítő felhasználói felület. A cotroller pedig az eseménykezelők összessége, tehát hogy mit kell csinálni hozzáadáskor, illetve elem törlésekor. Így már úgy nagyjából talán világos, hogy mi az az MVC, de hogy valósul meg ez AngularJS-ben?

AngularJS-ben a model réteget JavaScript változók adják. Ezek tárolják az adatokat. A view réteget a HTML kód adja, amit az AngularJS saját attribútumokkal egészít ki. Innen jött ugye a bejegyzés elején említett dolog, tehát hogy fel lehet fogni az AngularJS-t a HTML nyelv felokosításának is. Ezek az attribútumok rendelik össze a model-t a view-val (tehát hogy hol milyen adatot kell megjeleníteni), illetve a controllerrel (hogy milyen eseményre mit kell reagálni). A controller réteget JavaScript függvények adják, amik a model réteget adó JavaScript változókat manipulálják, és ezzel teljes is a kép.

Lássunk is pár példát. Ehhez látogassunk el a http://angularjs.org helyre, és tekerjük kicsit le az oldalt a második HTML kódig (az 'Add Some Control' címet keressük). Ez pont az a todo alkalmazás, amit a példában is említettem. Nézzük hogyan is épül fel. Kattintsunk át a todo.js fülre. Itt látunk egy TodoCtrl nevű függvényt (valójában inkább osztály, de JavaScriptben ezek összemosódnak). Ennek van egy $scope nevű paramétere. Ennek részletezésébe most annyira nem akarok belemenni, mert nagyon elnyúlna a bejegyzés, de lényeg, hogy minden változót (model), és működést leíró függvényt (controller) ehhez kell majd hozzárendelnünk. Rögtön a kód elején láthatjuk is a todos változó kezdeti értékének beállítását. Itt a todos változóba két érték kerül, az egyik egy todo elem, ami már le van zárva, a másik pedig egy még nem teljesült todo elem. Az előbbiek fényében már gondolom mindenki tudja, hogy ebben az alkalmazásban ez a todos változó a model réteg szerepét tölti be. A változón túl van még 3 függvény. Ezek képezik a controller réteget. Az addTodo egy új elemet ad a listához, az archive pedig törli a már teljesült elemeket. Hát, a remaining olyan öszvér fajta, mert igaz, hogy függvény, de igazából adatot ad vissza (pontosan azt adja vissza, hogy hány elvégzendő feladat van), amit a felületen kijelzünk, tehát inkább a model rétegbe sorolnám. Most kattintsunk át a html nézetre. Itt láthatjuk a view réteget, és az összerendeléseket, ami az AngularJS igazi ereje. A kód elején van egy ng-app attribútum. Ez minden AngularJS alkalmazás elejére kell, ez jelöli ki azt a részt, ahol a speciális attribútumokat értelmezni kell. Ebben az esetben ez a teljes html kódra vonatkozik. Aztán van két script rész, ahol behivatkozzuk az AngularJS-t magát, illetve a controller-t tartalmazó javascript állományt. Eztán jön egy ng-controller attribútum, mivel az előbb definiált controllert egy html blokkhoz rendeljük. Ha a HTML oldal olyan felépítésű, akkor megtehetjük, hogy egyes részeihez más más controller-t rendelünk, vagy ezeket akár egymásba is ágyazhatjuk, de ilyesmivel most ne bonyolítsuk az életünket. Az ng-controller-es div-en belül vannak {{ és }} jelek közti szakaszok. Ezekkel dinamikus tartalmat illeszthetünk be a HTML kódba, ráadásul nemesen egyszerű módon. Egyszerűen ha itt megadjuk egy $scope-hoz rendelt változó nevét, akkor a rendszer ide behelyettesíti annak tartalmát, illetve ugyanez történik, ha valamilyen függvény hívást írunk a jelek közé (tulajdonképpen ide bármilyen egyszerűbb JavaScript kifejezést írhatunk). Utóbbira példa a {{remining()}} rész, előbbire pedig a {{todos.length}}. Ez tehát egy módja a model bekötésének. Eztán jön egy link ng-click attribútummal. Ez egy szép példa a controller bekötésére. Leírja, hogy egy esemény hatására milyen működésnek kell életbe lépnie. Ha ugye erre a linkre kattintunk (archive), akkor az archive() függvényt kell meghívni a $scope-ból. Eztán jön egy ng-repeat rész, ami megintcsak a  model bekötésének módja. Ez végigszalad a megadott változón, és közben egy másik változó minden körben felveszi az aktuális elem értékét. Itt ugye a todos változón szaladunk végig. Minden körben generálódik egy li elem, és a todo változó felveszi az aktuális elem értékét. A li elemben találunk egy checkbox-ot, amihez ng-model-el van hozzárendelve a todo elem done változója. Míg a {{}} jelek használata egyirányú összerendelés (csak odaírja a rendszer a változó tartalmát), addig az ng-model kétirányú. Tehát egyfelől az elem a változó tartalmának megfelelően viselkedik, másfelől a változó az elem állapotának megfelelő értéket kapja. Olyan mint ha innentől a változó a HTML elem leképződése lenne, ebben az esetben a checkbox-é. Ha a változó értéke változik, változik a checkbox állapota is, illetve ha a felhasználó változtat a checkbox állapotán, akkor változik a változó értéke is. A következő span részben az elem class-ja a todo.done-tól függ. Ez az egyszerű {{}} jeles behelyettesítés. Amire érdemes felfigyelni, hogy az egész dolog teljesen real-time. Tehát mikor beklikkeljük a checkbox-ot, és megváltozik a változó értéke, akkor vele együtt minden változóhoz kötött dolog is változik. Tehát jelen esetben az elem class-a is. Ezt ki is próbálhatjuk, ha jobb oldalon a checkbox-ra kattintunk. Nem kell azzal vesződnünk, mint mondjuk jQuery esetén, hogy a bejelölés eseményre rakjunk egy eseménykezelőt, ami megváltoztatja a másik elem class-át. Ezzel sokkal rövidebb, szebb, és tisztább kódot kapunk. Végül pedig van egy ng-submit eseménykezelő, ami az add gomb megnyomására meghívja az addTodo függvényt, ami berakja az új todo elemet, aminek tartalma az előtte lévő text elemben lévő ng-model attribútumnak hála a todoText változóba kerül.  

Hát, nagyon tömören ennyit akartam írni az alapokról. Az AngularJS nagyon sok mindent tud még ezen kívül. Definiálhatunk modulokat, saját attribútumokat, kommunikálhatunk a szerverrel, stb. de ezeknek már talán érdemes új bejegyzést szentelni. 

#blog   #angularjs  


Embedded Link


AngularJS — Superheroic JavaScript MVW Framework
AngularJS is what HTML would have been, had it been designed for building web-apps. Declarative templates with data-binding, MVW, MVVM, MVC, dependency injection and great ...

AngularJS (1. alapok)


Már egy ideje ígérgetem, hogy írok egy rövid bejegyzést arról, hogy mi is az AngularJS. Amikor elsőnek találkoztam vele, úgy jellemezte valaki a rendszert, hogy ilyen lenne a HTML nyelv, ha most találták volna fel. Tehát felfoghatjuk akár a jelenlegi szabvány felokosításának is.

Kicsit jobban kifejtve az AngularJS egy nagyon szépen megkonstruált MVC keretrendszer. Ez valami baromi misztikus dolognak hangzik, pedig nem az. Az MVC a Model View Controller hármas rövidítése. és mostanában tulajdonképpen szinte minden adatokat kezelő alkalmazás ezt a felépítést használja. Az MVC annyit jelent, hogy az alkalmazást három rétegre osztjuk. Az adattartalomra (model), a megjelenítésre (view), és a működésre (controller). Ezek a rétegek körkörösen hivatkoznak egymásra. Az adattartalmat (model) a view réteg jeleníti meg, ahonnan mindenféle felhasználói események hatására meghívódik valami működés (controller), ami megváltoztatja az adattartalmat, és itt körbe is ért az egész. Talán még így is ködös kicsit az egész, úgyhogy nézzünk egy példát. Egy sima todo listát, ahová új elemeket lehet felvenni, és törölni onnan (mint mondjuk egy bevásárló lista). Itt ugye az adattartalom (model) az a lista, ami a todo elemeket tartalmazza. A view az ezt megjelenítő felhasználói felület. A cotroller pedig az eseménykezelők összessége, tehát hogy mit kell csinálni hozzáadáskor, illetve elem törlésekor. Így már úgy nagyjából talán világos, hogy mi az az MVC, de hogy valósul meg ez AngularJS-ben?

AngularJS-ben a model réteget JavaScript változók adják. Ezek tárolják az adatokat. A view réteget a HTML kód adja, amit az AngularJS saját attribútumokkal egészít ki. Innen jött ugye a bejegyzés elején említett dolog, tehát hogy fel lehet fogni az AngularJS-t a HTML nyelv felokosításának is. Ezek az attribútumok rendelik össze a model-t a view-val (tehát hogy hol milyen adatot kell megjeleníteni), illetve a controllerrel (hogy milyen eseményre mit kell reagálni). A controller réteget JavaScript függvények adják, amik a model réteget adó JavaScript változókat manipulálják, és ezzel teljes is a kép.

Lássunk is pár példát. Ehhez látogassunk el a http://angularjs.org helyre, és tekerjük kicsit le az oldalt a második HTML kódig (az 'Add Some Control' címet keressük). Ez pont az a todo alkalmazás, amit a példában is említettem. Nézzük hogyan is épül fel. Kattintsunk át a todo.js fülre. Itt látunk egy TodoCtrl nevű függvényt (valójában inkább osztály, de JavaScriptben ezek összemosódnak). Ennek van egy $scope nevű paramétere. Ennek részletezésébe most annyira nem akarok belemenni, mert nagyon elnyúlna a bejegyzés, de lényeg, hogy minden változót (model), és működést leíró függvényt (controller) ehhez kell majd hozzárendelnünk. Rögtön a kód elején láthatjuk is a todos változó kezdeti értékének beállítását. Itt a todos változóba két érték kerül, az egyik egy todo elem, ami már le van zárva, a másik pedig egy még nem teljesült todo elem. Az előbbiek fényében már gondolom mindenki tudja, hogy ebben az alkalmazásban ez a todos változó a model réteg szerepét tölti be. A változón túl van még 3 függvény. Ezek képezik a controller réteget. Az addTodo egy új elemet ad a listához, az archive pedig törli a már teljesült elemeket. Hát, a remaining olyan öszvér fajta, mert igaz, hogy függvény, de igazából adatot ad vissza (pontosan azt adja vissza, hogy hány elvégzendő feladat van), amit a felületen kijelzünk, tehát inkább a model rétegbe sorolnám. Most kattintsunk át a html nézetre. Itt láthatjuk a view réteget, és az összerendeléseket, ami az AngularJS igazi ereje. A kód elején van egy ng-app attribútum. Ez minden AngularJS alkalmazás elejére kell, ez jelöli ki azt a részt, ahol a speciális attribútumokat értelmezni kell. Ebben az esetben ez a teljes html kódra vonatkozik. Aztán van két script rész, ahol behivatkozzuk az AngularJS-t magát, illetve a controller-t tartalmazó javascript állományt. Eztán jön egy ng-controller attribútum, mivel az előbb definiált controllert egy html blokkhoz rendeljük. Ha a HTML oldal olyan felépítésű, akkor megtehetjük, hogy egyes részeihez más más controller-t rendelünk, vagy ezeket akár egymásba is ágyazhatjuk, de ilyesmivel most ne bonyolítsuk az életünket. Az ng-controller-es div-en belül vannak {{ és }} jelek közti szakaszok. Ezekkel dinamikus tartalmat illeszthetünk be a HTML kódba, ráadásul nemesen egyszerű módon. Egyszerűen ha itt megadjuk egy $scope-hoz rendelt változó nevét, akkor a rendszer ide behelyettesíti annak tartalmát, illetve ugyanez történik, ha valamilyen függvény hívást írunk a jelek közé (tulajdonképpen ide bármilyen egyszerűbb JavaScript kifejezést írhatunk). Utóbbira példa a {{remining()}} rész, előbbire pedig a {{todos.length}}. Ez tehát egy módja a model bekötésének. Eztán jön egy link ng-click attribútummal. Ez egy szép példa a controller bekötésére. Leírja, hogy egy esemény hatására milyen működésnek kell életbe lépnie. Ha ugye erre a linkre kattintunk (archive), akkor az archive() függvényt kell meghívni a $scope-ból. Eztán jön egy ng-repeat rész, ami megintcsak a  model bekötésének módja. Ez végigszalad a megadott változón, és közben egy másik változó minden körben felveszi az aktuális elem értékét. Itt ugye a todos változón szaladunk végig. Minden körben generálódik egy li elem, és a todo változó felveszi az aktuális elem értékét. A li elemben találunk egy checkbox-ot, amihez ng-model-el van hozzárendelve a todo elem done változója. Míg a {{}} jelek használata egyirányú összerendelés (csak odaírja a rendszer a változó tartalmát), addig az ng-model kétirányú. Tehát egyfelől az elem a változó tartalmának megfelelően viselkedik, másfelől a változó az elem állapotának megfelelő értéket kapja. Olyan mint ha innentől a változó a HTML elem leképződése lenne, ebben az esetben a checkbox-é. Ha a változó értéke változik, változik a checkbox állapota is, illetve ha a felhasználó változtat a checkbox állapotán, akkor változik a változó értéke is. A következő span részben az elem class-ja a todo.done-tól függ. Ez az egyszerű {{}} jeles behelyettesítés. Amire érdemes felfigyelni, hogy az egész dolog teljesen real-time. Tehát mikor beklikkeljük a checkbox-ot, és megváltozik a változó értéke, akkor vele együtt minden változóhoz kötött dolog is változik. Tehát jelen esetben az elem class-a is. Ezt ki is próbálhatjuk, ha jobb oldalon a checkbox-ra kattintunk. Nem kell azzal vesződnünk, mint mondjuk jQuery esetén, hogy a bejelölés eseményre rakjunk egy eseménykezelőt, ami megváltoztatja a másik elem class-át. Ezzel sokkal rövidebb, szebb, és tisztább kódot kapunk. Végül pedig van egy ng-submit eseménykezelő, ami az add gomb megnyomására meghívja az addTodo függvényt, ami berakja az új todo elemet, aminek tartalma az előtte lévő text elemben lévő ng-model attribútumnak hála a todoText változóba kerül.  

Hát, nagyon tömören ennyit akartam írni az alapokról. Az AngularJS nagyon sok mindent tud még ezen kívül. Definiálhatunk modulokat, saját attribútumokat, kommunikálhatunk a szerverrel, stb. de ezeknek már talán érdemes új bejegyzést szentelni. 

#blog   #angularjs  


Embedded Link


AngularJS — Superheroic JavaScript MVW Framework
AngularJS is what HTML would have been, had it been designed for building web-apps. Declarative templates with data-binding, MVW, MVVM, MVC, dependency injection and great ...

2013. március 13., szerda

WordPress (nagyon)gyorstalpaló (bővítmények fejlesztése)


Ez a bejegyzés némi PHP tudást feltételez, de ennek ellenére nem lesz bonyolult. Igazából szerintem a WordPress leglenyűgözőbb tulajdonsága az egyszerűsége. De lássuk, hogy is megy ez ...

Ahogyan a dolog nevéből is adódik, a bővítmények segítségével új funkcionalitással bővíthetjük a rendszert. Ilyen kiegészítők segítségével szinte bármit megvalósíthatunk. A bővítmények a sablonokhoz hasonlóan a wp-content mappában találhatóak, a plugins könyvtárban. A pluginek felépítése is nagyon hasonló a sablonokéhoz. A WordPress végigszalad a plugins könyvtár tartalmán. Az ott található php fájlok, illetve könyvtárak tartalmazhatnak plugineket. A plugin adatok a sablonokhoz hasonlóan a fájl elején kommentben találhatóak. Ha a plugin könyvtárban található, akkor a WordPress a könyvtár nevével megegyező php állományt keres. Tehát ha a plugin a 'test' könyvtárban található, akkor 'test.php'-t. Minden WordPress változatban található egy 'Hello Dolly' nevű teszt plugin, amit a plugins könyvtárban találhatunk hello.php néven. Ennek az elején láthatjuk az előbb említett komment részt a plugin nevével és leírásával. Ez alapján már elkészíthetjük a saját bővítményünket. Hozzunk létre mondjuk egy test.php nevű állományt a plugins könyvtárban, és kommentek segítségével adjunk neki nevet és leírást. Ha minden jól megy, ez már elég ahhoz, hogy a pluginünk megjelenjen a bővítmények listájában. Ugyanígy működni fog az is, ha a test.php-t egy test nevű könyvtárban helyezzük el az esetleges egyéb állományokkal.

Tehát van már egy bővítményünk, ami egyenlőre nem csinál semmit. Most jöhet az, hogy valami tényleges funkcionalitást adjunk a rendszerhez. Erre a WordPress-ben az action-ök és a filterek szolgálnak. Az action-ök olyan pontok a rendszerben, ahová saját működést szúrhatunk be. Ilyen action például az oldal fejlécének generálása, vagy éppen az, hogy a rendszer kigenerált egy blogbejegyzést. Vegyünk például egy olyan plugint, ami egy megosztó sávot (like, G+, stb.) helyez a bejegyzések aljára. Egy ilyen plugin-nak a bejegyzés generálása után meghívódó action-re kell regisztrálnia egy függvényt. Ahogy a WordPress generálja az oldal darabjait, az egyes action-öknél meghívja a mi kezelőinket, így avatkozhatunk be az oldalgenerálás folyamatába.

A filter a beavatkozás másik formája. Ez egy olyan függvény, ami valami adatot kap a paraméterében, és valami változtatást végez rajta. Így például bizonyos karaktersorozatokat cserélhetünk le a tartalomban, menü elemeket adhatunk az admin felülethez, és hasonlók.

Az action-ökön és filtereken túl van még pár lehetőség a működésbe való beavatkozásra, de az esetek nagy többségében ezeken keresztül adhatjuk hozzá az új működést a rendszerhez. Ráadásul a kialakítás annyira flexibilis, hogy szinte bármit megoldhatunk WordPress-en belül.

Igazából a plugin fejlesztésről könyvet lehetne írni, de indulásnak talán ennyi elég. A továbblépéshez a WordPress Codex vonatkozó fejezeteit tudom ajánlani: http://codex.wordpress.org/Plugins , de ezen kívül is sok tutorial található a weben, illetve sokat tanulhatunk már meglévő plugin-ek forráskódjának böngészésével is.

#blog  

2013. március 12., kedd

PHP naplózás Chrome JavaScript konzolra


Ez is egy hasznos tool php-hoz. A Chrome JavaScript konzoljára lehet vele log-olni, így nem "piszkoljuk" össze az oldalt a debug üzenetekkel, var_dump-okkal, stb. A php-s logger a HTTP header-t használja a log üzenetek Chrome-hoz való továbbítására, így (elvileg) AJAX hívásokra is működik.

#blog  

http://www.chromephp.com/





ChromePHP
ChromePHP is a console logging extension for Google Chrome. It lets you log data directly from your PHP scripts into the Chrome console to help you debug your applications.

WordPress (nagyon)gyorstalpaló (sablonkezelés)


Most, hogy (kb. 5 perc munkával) sikeresen telepítettünk saját WordPress-t, elkezdhetjük testre szabni. Ennek legfontosabb része, hogy kialakítsuk az oldal külső megjelenését. A WordPress ilyen szempontból nagyon jól testre szabható a sablonok segítségével.

Lépjünk be a WordPress vezérlőpultjára, és válasszuk ki a Megjelenés menü / Sablonok részt. Itt jelennek meg a már elérhető sablonok, illetve van felül egy Sablonok telepítése fül, ott tudunk új sablonokat telepíteni. Mivel a weben több száz (de lehet, hogy több ezer) WordPress sablon megtalálható, ezért én azt javasolnám, hogy soha ne kezdjünk el nulláról sablont fejleszteni. Keressünk valamit, ami nagyjából megfelel az igényeinknek, és ha kell, azt módosítsuk tovább. Ha nem a belső sablonkeresőt használjuk, akkor weben a http://wordpress.org/extend/themes/ címen keresgélhetünk az ingyenes változatok közt. Ebből jelenleg 1700+ db van (!), ami nem kevés, de ha Google-ben rákeresünk a wordpress témákra, találunk még legalább ugyanennyit, illetve van sok fizetős is. Szóval tényleg hatalmas a felhozatal. Ha megtaláltuk a céljainknak leginkább megfelelő sablont, töltsük fel a sablonkezelőben, telepítsük, és szabjuk testre igényeknek megfelelően.

No, de hogy valamiről szóljon is a bejegyzés, lássuk mit kell tennünk akkor, ha saját sablont szeretnénk készíteni, vagy legalábbis átalakítani a már meglévőt. A WordPress wp-content/themes könyvtárában találhatóak meg a WordPress sablonok. A frissen telepített sablonunk is ide került be, így ha minden igaz, van ott egy könyvtár neki is. Új sablont hozzáadni elég egyszerű, ugyanis a WordPress egyszerűen végig szalad ezen a könyvtáron, és minden itt lévő alkönyvtárat sablonként értelmez. Az új sablon készítéséhez tehát fogjuk a már telepített (alapanyagnak leginkább megfelelő) sablont, és lemásoljuk mondjuk 'sajat_sablon' néven. Eztán lépjünk be a 'sajat_sablon' könyvtárba, és nyissuk meg az itt található style.css-t. Igazából itt van a trükk, ugyanis a style.css elején van egy komment rész. A WordPress innen olvassa ki a sablon adatait. Itt írjuk át a sablon nevét, megadhatjuk a készítőt, stb. Ha az adatokat módosítottuk, nézzünk rá WordPress-ben a sablonkezelőre. Ha minden jól megy, ott meg is jelent a saját sablonunk az általunk adott névvel. Ennyi, kész is életünk első WordPress sablonja. Az esetek nagy többségében általában sikerül jó alapot találni, és elég a css-t módosítani. Amennyiben ez nem elég, és bele kell nyúlni a html kódba is, úgy érdemes kicsit szétnézni a könyvtárban. Itt van pár PHP állomány, amik a weboldal különböző darabkáját tartalmazzák. Ezek igazából HTML fájlok némi PHP betéttel. Ha valamit módosítani kellene, akkor itt tehetjük azt meg. Mivel a sablonok felépítése többféle lehet, ezért nincs általános szabály arra, hogy mit hol találunk meg. Én azt szoktam csinálni, hogy megnézem az oldal aktuális állapotának forrását, keresek valami arra a részre jellemző motívumot (id-t, class-t, stb.) arra rákeresek a sablonba, és az így megtalált darabban már elvégezhető a módosítás.

Igazából a WordPress sablonkezelése még egy csomó mindent lehetővé tesz. Regisztrálhatunk dinamikus területeket widgeteknek, új funkcionalitást adhatuk az oldalnak, stb. Tulajdonképpen bármit ki lehet alakítani így. Akár egy teljes Facebook, vagy Google+ oldal is megvalósítható a WordPress sablonrendszerének segítségével, nincs semmi, ami bármiben is korlátozna.  Ez viszont már a mély víz (vagy legalábbis mélyebb) kategória, így túlmutat egy ilyen rövid bejegyzés határain. Indulásnak szerintem ennyi bőven elég. Aki jobban el akar mélyedni a témában, az talál bőven leírásokat a weben.

A továbblépéshez itt egy nagyon jó infografika és leírás a sablonok működéséről: http://yoast.com/wordpress-theme-anatomy/

Illetve a hivatalos WordPress doksi: http://codex.wordpress.org/Theme_Development 

#blog  

2013. március 11., hétfő

WordPress (nagyon)gyorstalpaló (telepítés)


Ez a rövid bejegyzés arról fog szólni, hogy hogyan telepíthetünk WordPress-t a már előzőleg feltelepített XAMPP rendszerünkre.

Először töltsük le a WordPress legújabb példányát a http://wphu.org/letoltes oldalról. Hozzunk létre egy könyvtárat a xampp könyvtárában lévő htdocs mappában. Legyen a könyvtár neve mondjuk wp. Zippeljük ki a letöltött WordPress csomagot ebbe a wp mappába. Indítsuk el az Apache-ot és a MySQL-t, majd nyissuk meg a böngészőben a http://localhost/wp oldalt.

A megjelenő install képernyőn meg kell adnunk az adatbázis adatait, ehhez viszont létre kell hoznunk egy adatbázist. Az adatbázis adminisztrációs felületet a http://localhost/phpmyadmin oldalon találjuk meg. Itt az adatbázisok tabfül alatt hozhatunk létre adatbázist. Legyen az adatbázis neve mondjuk wordpress, az illesztésnél pedig válasszuk ki az utf8_unicode_ci-t. Létrehoz, és már kész is az adatbázis. Térjünk vissza az admin oldalra, az adatbázis nevénél adjuk meg a frissen létrehozott adatbázis nevét (jelen esetben wordpress), a felhasználó root, a jelszó pedig üres. Ha megnyomtuk a tovább gombot, a rendszer kér még pár adatot, majd létrehozza az új wordpress változatot.

Igazából ennyi az egész. Pár egyszerű lépés, és már használatba is vehetjük új WordPress oldalunkat. 

#blog  

2013. március 10., vasárnap

Lokális fejlesztés XAMPP használatával


Habár induláshoz szerintem a Cloud9 a legalkalmasabb (regisztrálás után egy pöccre összelőtt felületet kapuk szerkesztővel, szerverrel, git-el, mindennel), kicsit komplexebb projektekhez már a XAMPP-ot (http://www.apachefriends.org/en/xampp.html) ajánlanám. A XAMPP egy egyszerűen telepíthető környezet, mely tartalmazza a webszervert (apache), az SQL szervert (MySQL), a PHP futtatókörnyezetet, és még pár hasznos dolgot. Igazából a legnagyobb előnye a Cloud9-el szemben az SQL szerver (MySQL), amit Cloud9 esetén csak a fizetős változatban kapunk. Hátránya pedig, hogy telepíteni kell, nem kapunk kényelmes kódszerkesztőt, és Git támogatást.

A XAMPP telepítése után simán a létrejött parancsikonra kattintva indíthatjuk. Itt a megjelenő vezérlőpanelen indítsuk el az apacehe-ot és a mysql-t. Másra egyelőre nem igen lesz szükség. A http://localhost címet a böngészőben megnyitva rögtön láthatjuk is hogy fut, és innen el is érhetünk pár hasznos toolt.

A PHP-s oldalak futtatása sem sokkal bonyolultabb. Keressük ki az a könyvtárat, ahová a XAMPP-ot telepítettük. Itt a htdocs könyvtárban hozzunk létre egy alkönyvtárat mondjuk 'teszt' néven. A könyvtárban hozzunk létre egy teszt.php állományt, és másoljunk bele valami PHP-s kódot. Majd nyissuk meg böngészőben a http://localhost/teszt/teszt.php url-t, és ha minden igaz, látni is fogjuk az eredményt. Ha a teszt.php-t átnevezzük index.php-ra, akkor elég a http://localhost/teszt címet megadni, mivel alapbeállítás szerint ez az alapértelmezett PHP állomány, amit akkor futtat a webszerver, ha nincs külön PHP állomány megadva.

Igazából ennyi elég is az induláshoz ...
 
#blog  





apache friends - xampp
XAMPP is an easy to install Apache Distribution for Linux, Windows, Mac OS X, and Solaris. The package includes the Apache web server, MySQL, SQLite, PHP, Perl, a FTP-Server and phpMyAdmin.

Cloud 9 használata GitHubbal (4.)


Habár az előző bejegyzésről azt mondtam, hogy az lesz az utolsó, van még egy dolog, ami fontos lehet. Ha forkoltunk egy tárolót, az a későbbiekben változhat (új fejlesztések, hibajavítások kerülnek a mester változatba), ezeket a változásokat pedig vissza kell húznunk a saját águnkba, hogy dolgozhassunk vele. Ezt a következő módon tehetjük meg:

Lépjünk be cloud9-be, és nyissuk meg szerkesztésre a helyi klónt.

Adjuk ki a git remote add upstream <mester tároló url címe> parancsot. Ezt elég egyszer megcsinálni, a későbbiekben ezt a parancsot már nem kell majd kiadnunk.

A git fetch upstream paranccsal húzzuk le a változásokat, majd a git merge upstream/master paranccsal fésüljük be azokat a saját változatunkba. Így tehát a helyi változat már frissült a mester változatból.

Innen pedig már csak a szokásos git push paranccsal toljuk vissza az egészet GitHub-ra. Így frissíthetjük a lokális változatot a mester tárolóból.

#blog  

Nem hiszek abban, hogy bárkit is negatív megerősítéssel ösztönözni lehetne...

Nem hiszek abban, hogy bárkit is negatív megerősítéssel ösztönözni lehetne bármire. A rossztól való félelem korlátozhat ugyan, de igazán ösztönözni szerintem nem lehet így. Ha valakinek az épülését kívánjuk, mindig csak dicsérjük, soha ne kritizáljuk élesen. Legalábbis én így gondolom ...


#blog  

Google Chrome Developer Tools


Ha valaki Eclipse-ből szeretne JavaScript-et debugolni, annak ez egy nagyon hasznos kis eszköz. Most próbáltam ki. Beszippantja Chrome-ból a JavaScript-eket, amiket szépen meg lehet nyitogatni, el lehet bennük helyezni brakepoint-ot, nézegetni a változók tartalmát, sőt, még át is lehet írni a JS-t, és visszanyomni a böngésző v8-as virtuális gépébe. Igazából a Chrome beépített debuggere többet tud. Akkor lehet kényelmes, ha tiszta JavaScript-et szeretnénk debugolni. 

https://code.google.com/p/chromedevtools/

#blog  





chromedevtools
Google Chrome Developer Tools for Java

2013. március 9., szombat

Cloud 9 használata GitHubbal (3.)


Ebben a harmadik (és ebből a sorozatból szerintem utolsó) részben azt írom le, hogy hogyan szállhatunk be más GitHub-os fejlesztésekbe és hogyan dolgozhatunk együtt másokkal. Igazából itt fog összeérni a három írás és remélhetőleg sikerül rávilágítani arra is, hogy miért olyan nagyszerű eszköz a GitHub, ha nyílt forrású fejlesztésen törjük a fejünket.

Ha minden igaz, akkor már van GitHub accountunk. Tegyük fel, hogy találtunk egy projektet aminek a fejlesztésébe szeretnénk beszállni. Van valami jó ötletünk, valami feature, vagy hibajavítás. Jelen esetben legyen ez a projekt az általam létrehozott PHP mintaprojekt, ami itt érhető el: https://github.com/TheBojda/php-examples . Ha be vagyunk jelentkezve GitHub-ra, felül fogunk látni egy Fork gombot. Ezt megnyomva a tárolóról némi pötyörgés után készül egy másolat, ami bekerül a saját tárolóink közé.

Most hogy már van saját példányunk, lépjünk be cloud9-be, és a már leírtaknak megfelelően húzzuk be a GitHub-ról a tartalmat, futtassuk, módosítsuk, majd toljuk vissza GitHub-ra.

Ha a változások már GitHub-on vannak, akkor jön a varázslat, amiben a GitHub ereje rejlik. Van felül egy pull request gomb. Ezt megnyomva küldhetünk egy kérelmet az eredeti tároló tulajdonosának, hogy olvassza be a mi változtatásainkat a fő ágba. A pull requesthez írhatunk valami leírást, és a projekt gazdájának számára is jól látszik, hogy a változtatás miket foglal magában. Így nagyon egyszerű módon hozzájárulhatunk más projektekhez. Nem kell kérnünk, hogy felvegyenek a fejlesztő csapatba, nincs szükség semmilyen felesleges interakcióra. Egyszerűen csak fogjuk a cuccot, kérünk belőle egy másolatot, változatunk/hozzáadunk amit gondolunk, majd küldünk egy pull request-et, ami alapján vagy beolvasztják a változtatásainkat a projektbe, vagy nem. Többek között például sok Google projekt is a GitHub-ot használja. Például a népszerű AngularJS keretrendszer tárolójában várakozó pull request-eket itt láthatjuk: https://github.com/angular/angular.js/pulls . Ezek mind olyan emberek hozzájárulásai a Google keretrendszeréhez, akik nem Google alkalmazottak. Egyszerűen csak használják a rendszert, és így segítik a rendszer fejlődését. Ettől lesz az egész nyílt forrású fejlesztés közösségi ... 

#blog  

2013. március 8., péntek

Cloud 9 használata GitHubbal (2.)


Az előző rész alapján már elvileg bárki le tudja klónozni cloud9-be más GitHub tárolóját, és futtathatja onnan annak tartalmát. Most arról írnék röviden, hogy hogyan használhatjuk a saját GitHub tárolónkat saját projektjeink fejlesztéséhez. Nem lesz sokkal bonyolultabb, mint az előző ...

Először is regisztráljunk GitHub-on egy felhasználót. Ha ez megvan, akkor jobb felső sarokban a kis könyves plusszos ikonnal csináljunk egy tárolót ('create new repo'). Alul van egy checkbox, hogy csináljon readme-t is, jelöljük be azt is. Megadjuk a nevet, és kész is a repo, jöhet a cloud9.

Most hogy van GitHub felhasználónk, azzal be is léphetünk cloud9-re, vagy ha már van felhasználónk, a profil oldalon hozzárendelhetjük a GitHub felhasználónkat. Ha ez megvan, akkor elvileg cloud9 ben bal oldalon alul meg is jelennek a github tárolóink, köztük az újjal, amit most hoztunk létre. Ez a tároló a GitHub-on létezik, így a szerkesztéshez le kell klónozni cloud9-be. Ehhez elég kiválasztani bal oldalon a repo-t, majd megnyomni a 'clone to edit' gombot felül. Ha ez megvolt, akkor létrejön a workspace, és lehet szerkeszteni.

Hozzunk létre mondjuk egy php állományt, írjunk bele valami tartalmat, futtassuk, stb. Lényeg, hogy legyen valami tartalom, amit visszatölthetünk a repo-ba.

Na, ha már van tartalom is, akkor jön a git, aminek használatához parancssor szükséges. A terminált a képernyő alján találjuk, itt adhatjuk ki a parancsokat. 

A git add <fájlnév> paranccsal jelölhetjük meg az egyes állományokat verzionálásra, vagy git add . használatával egyből hozzáadhatjuk az összes állományt. A git az így megjelölt fájlokat fogja a továbbiakban kezelni.

A git add után git commit -m 'Leírás' paranccsal tolhatjuk ki a változásokat a cloud9-en lévő helyi tárolóba. Ennek a mi esetünkben nem sok értelme van, de ha valami nagyobb fejlesztésen dolgozunk, akkor érdemes lehet fejlesztés közben mentegetni. Az így létrejött verziókra később visszatérhetünk, megtekinthetjük a különbségeket, stb. Egyenlőre most ezekkel ne foglalkozzunk, lényeg, hogy commit-al kikerültek a helyi (cloud9-es) tárolóba a változások.

Végül a git push parancs kiadásával a lokális tárolóból kitolhatjuk a tartalmat a GitHub-ra. Ha minden jól ment, akkor ha visszanézünk a GitHub-ra, látni fogjuk ott a művünket. Azt mások is megtekinthetik, leklónozhatják, fejleszthetik, stb. Ezzel jegyet váltottunk a nyílt forrású fejlesztők közösségébe.

A következő részben arról lesz szó, hogy hogy szállhatunk be már meglévő projektek fejlesztésébe.

#blog  

Lebegő szigetek


Épp kinéztem az ablakon, és elég borús az idő. Arra gondoltam, milyen jópofa lenne héliummal töltött léghajókkal mesterséges szigeteket emelni a felhők fölé, ahol mindig süt a nap, és gyönyörű a kilátás. A sziget energiaellátása mehetne napelemről, és szélerőművekről, és eleve az egész önfenntartó lenne. Saját víztisztító rendszer, saját kis kertek az élelem megtermelésére, úgy, mint egy valódi szigeten. Szerintem egy ilyen viszonylag hamar visszahozná az árát az ide szervezett luxusnyaralásokból, de később akár egy alternatív megoldás is lehetne a föld túlnépesedésének kezelésére.

#blog  

2013. március 7., csütörtök

Cloud 9 használata GitHubbal (1.)



Reshared post from +Laszlo Fazekas
Cloud 9 használata GitHubbal (1.)

A GitHub amolyan közösségi tér fejlesztőknek (itt írtam róla kicsit: http://lf.estontorise.hu/archives/288). +Papp Zsolt -al beszélgettünk kicsit, és végül az lett a konklúzió, hogy érdemes ezt az eszközt már a tanulás elején megismerni, mivel már ebben a fázisban jó hasznát vehetjük.

Ebben a bejegyzésben azt fogom leírni, hogy hogyan lehet egy már GitHubon létező projektet behúzni cloud9 (http://c9.io) alá, és futtatni. A későbbiekben tervezem, hogy készülne 1-2 további bejegyzés arról, hogy hogyan hozhatunk létre saját GitHub repository-kat, illetve hogyan járulhatunk hozzá más open source projektek fejlesztéséhez.

Egy GitHub-os projektet nagyon egyszerű behúzni cloud 9 alá. Egyszerűen jelentkezzünk be (ez előtt persze regisztráljunk cloud 9-en), majd válasszuk a 'Create new workspace' részt, azon belül pedig a 'Clone URL'-t. Itt kell megadnunk a GitHub-os tároló nevét. Én direkt teszt célra csináltam egy git://github.com/TheBojda/php-examples.git tárolót, így jobb híján adjuk meg azt- 'Create', és már kész is a klón. Válasszuk ki a listából, majd nyomjuk meg a 'Start Editing'-et, így megjelenik a szerkesztő. Itt nyissuk meg az index.php-t a hello_world mappából, majd jobb felül nyomjuk meg a Run gombot. Az alul megjelenő URL-re kattintva megnyithatjuk azt a beépített böngészőben, és láthatjuk az eredményt. Ha valamit átírunk a kódon, elég menteni, majd frissíteni a beépített böngészőt, és már látszik is az eredmény.

Hát, igazából ennyi. Nem egy nagy varázslat ... 

#blog  





GitHub, avagy közösségi kódolás
Aki foglalkozott már nyílt forrású projektek fejlesztésével, az valószínűleg belefutott már a problémába, hogy ha elkészült, a végeredményt hogy ossza meg másokkal. Az egyik lehetőség, hogy összera......

Cloud 9 használata GitHubbal (1.)


A GitHub amolyan közösségi tér fejlesztőknek (itt írtam róla kicsit: http://lf.estontorise.hu/archives/288). +Papp Zsolt -al beszélgettünk kicsit, és végül az lett a konklúzió, hogy érdemes ezt az eszközt már a tanulás elején megismerni, mivel már ebben a fázisban jó hasznát vehetjük.

Ebben a bejegyzésben azt fogom leírni, hogy hogyan lehet egy már GitHubon létező projektet behúzni cloud9 (http://c9.io) alá, és futtatni. A későbbiekben tervezem, hogy készülne 1-2 további bejegyzés arról, hogy hogyan hozhatunk létre saját GitHub repository-kat, illetve hogyan járulhatunk hozzá más open source projektek fejlesztéséhez.

Egy GitHub-os projektet nagyon egyszerű behúzni cloud 9 alá. Egyszerűen jelentkezzünk be (ez előtt persze regisztráljunk cloud 9-en), majd válasszuk a 'Create new workspace' részt, azon belül pedig a 'Clone URL'-t. Itt kell megadnunk a GitHub-os tároló nevét. Én direkt teszt célra csináltam egy git://github.com/TheBojda/php-examples.git tárolót, így jobb híján adjuk meg azt- 'Create', és már kész is a klón. Válasszuk ki a listából, majd nyomjuk meg a 'Start Editing'-et, így megjelenik a szerkesztő. Itt nyissuk meg az index.php-t a hello_world mappából, majd jobb felül nyomjuk meg a Run gombot. Az alul megjelenő URL-re kattintva megnyithatjuk azt a beépített böngészőben, és láthatjuk az eredményt. Ha valamit átírunk a kódon, elég menteni, majd frissíteni a beépített böngészőt, és már látszik is az eredmény.

Hát, igazából ennyi. Nem egy nagy varázslat ... 

#blog  





GitHub, avagy közösségi kódolás
Aki foglalkozott már nyílt forrású projektek fejlesztésével, az valószínűleg belefutott már a problémába, hogy ha elkészült, a végeredményt hogy ossza meg másokkal. Az egyik lehetőség, hogy összera......

Leheletteszttel diagnosztizálható a rák


A gyomorrák mellett úgy tudom a tüdőrák kimutatására is létezik hasonló módszer. Ezek a módszerek azért nagyon fontosak, mert igazándiból a rák jól gyógyítható betegség, ha időben észreveszik. Gond akkor szokott lenni, ha már áttétek képződnek, és nem lokalizálható a daganat. Persze ettől még nagyon messze van az, hogy az átlagember számára elérhető legyen az eljárás. Eleve az is problémát jelent, hogy az ember nem ér rá elmenni az orvoshoz elvégeztetni a tesztet. Szerintem jó megoldás lenne tesztelő automatákat telepíteni. Olyasmi lenne, mint mondjuk egy kóla automata. Az ember bedobja a pénzt, és már fújhatja is a szondát, a gép pedig kidobja az eredményt, vagy ha sokáig tart az analízis, elküldi sms-ben, vagy e-mailben, stb. Az embereknek is egyszerűbb lenne, a gép üzemeltetőjének is megéri, ha pedig valakinek az életét ez menti meg, az megfizethetetlen ...

#blog   

http://www.metropol.hu/mellekletek/tudomany/cikk/1007415





Leheletteszttel diagnosztizálható a gyomorrák
Egy gyors és egyszerű leheletteszttel kilencven százalékos biztonsággal megállapítható a gyomorrák.

2013. március 5., kedd

FON


Ez a FON egy nagy találmány. Veszel egy FON routert, amit egyfelől sima wifi routerként tudsz használni, másfelől kívülről is elérhető publikus hot-spot ként. Akik tagjai a FON közösségnek, azok ingyen használhatják egymás internet elérését. Aki nem tagja a közösségnek, az pedig viszonylag olcsón fizethet a wifi elérésért, amiből ráadásul a hot-spot tulajdonosa jutalékot kap. Így a felhasználók építik ki a világméretű wifi hálózatot.

A megoldás hasonlít a SpaceMonkey-ra, ahol a felhasználók tárhelyet dobnak be a közösbe, és egymás tárolóira backupolják a sajátjukat, így amolyan közösségi cloud-ot alkotva.

Ezekben a közösségi megoldásokban még nagy potenciál lehet a jövőben.

#blog    

http://corp.fon.com/





Home | Fon
What is Fon? Fon is your Global WiFi Network. It's built by people just like you. Fon members share a bit of their home WiFi, and in turn get free access at millions of other Fon hotspots worldwide. J...

2013. március 3., vasárnap

Google Glass, a világ leghatékonyabb megfigyelő rendszere


Mostanában divatos téma a Google Glass-al kapcsolatos biztonsági kérdések feszegetése. Gondoljunk csak bele, hogy ha az emberek nagy része rendelkezik Google Glass-al (vagy valami ahhoz hasonló kütyüvel), úgy soha senki nem lehet benne biztos, hogy nem figyelik meg. Az egészet egy arcfelismerő algoritmussal kombinálva már az is folyamatosan követhető lenne, hogy hol van az adott személy. Egyfelől érthető a paranoia, másfelől viszont a dolog már régóta létezik, nem kell hozzá Google Glass. Eleve ha valakinél bekapcsolt mobiltelefon van (kb. mindenki), annak a helyzete pillanatok alatt meghatározható az adótornyok információi alapján. A telefon mindig hozzárendelhető az adott emberhez, így ha valakinek hatalmában áll, telefonunk alapján bármikor tudhatja épp merre járunk. De térfigyelő kamerákból is rengeteg van az utcákon, így bekapcsolt mobiltelefon hiányában is megfigyelhetnek bárkit. A Google Glass-al csak annyit változik a helyzet, hogy így mindez a titkosszolgálatok, rendőrség, stb. hatásköréből átkerülhet a privát szférába. Bárki telepíthet majd ilyen megfigyelő szoftvert a saját eszközére, amivel valaki számára adatokat gyűjthet. A kérdés, hogy van-e (kell-e) megoldás a problémára. Tegyük fel, hogy bizonyos helyeken majd tiltják a Google szemüvegek használatát. De mi lesz azokkal, akik mondjuk retina implantátumot használnak, mert a nélkül vakok lennének? Vagy ha a Google Glass már csak egy kontaktlencse lesz, esetleg valami beültethető implantátum. Lassan olyan szerves részév válhat az életünknek, mint maga a látás, és az emberek nem fognak lelkesülni azért, ha valaki el akarja venni a "látásukat". Alapvetően úgy gondolom, hogy hosszú távon egyszerűen a magánélethez való viszonyunk fog megváltozni. Egyszerűen meg fogunk tanulni együtt élni azzal, hogy bármit is csinálunk, arról mások tudomást szerezhetnek. Ez persze az esetek többségében nem érdekel senkit. Félni igazából azoknak kell, akik valami rossz fát tettek a tűzre., például lopni készülnek egy boltból, a rendőrség elől bujkálnak, vagy bármi hasonló. Az pedig talán nem is olyan nagy baj. Akárhogy is legyen, ez ellen küzdeni szerintem csak értelmetlen szélmalomharc ...

#blog  

http://www.kurzweilai.net/the-google-glass-feature-no-one-is-talking-about





The Google Glass feature no one is talking about | KurzweilAI
When everything is connected --- a scene from a video about Watchdogs, a future Sony PS4 game (credit: Ubisoft) Google Glass might change your life, but

2013. március 2., szombat

SIMD műveletek Dart-ban (avagy miért érdemes Dart-ban programozni)


Egy rövid prezentáció a Dart-ban bevezetett SIMD műveletekről. Azért érdemes belenézni, mert itt már kezd felsejleni, hogy mi az értelme a Dart-nak. Vannak olyan dolgok, amik a JavaScript alkalmazások teljesítményét nyelv szinten korlátozzák. Ilyen például az, hogy a JavaScript tipikusan típus nélküli nyelv, így számolni csak lebegőpontos számokkal tud. A Dart-ban viszont opcionálisan használhatunk típusokat, ami alapján a fordító jobb kódot tud generálni. Egész számokat például egész számokként kezel (nem lebegőpontosként, mint a JS), amivel sokkal gyorsabban lehet számolni, és kevésbé erőforrás igényes (mobil eszközök, aksi, fogyasztás ...). Hasonló kategória a SIMD műveletek (amiről a prezentáció szól), ahol egy műveletet több adaton hajtunk végre. Ez multimédiás alkalmazásoknál, 3D-s alkalmazásoknál, stb. gyakori dolog (ez a lényege pl. az MMX, 3DNow, SSE utasításkészleteknek x86-os procikon). Ezeket a jelenlegi JavaScript motorok is használják, de csak olyan szinten, hogy a fordító "megpróbálja kitalálni", hogy hol lehetne ilyesmit alkalmazni, ami nem olyan hatékony, mint ha explicit módon megadjuk ezt, és erre optimalizáljuk a kódot. Az ilyen feature-ök hosszú távon a Dart-ot a leghatékonyabb script nyelvvé tehetik, amivel olyan kód készíthető, aminek sebessége vetekszik a natív alkalmazásokéval. A Java teljesítményét talán már most is eléri (talán túl is szárnyalja) a Dart, de így a jövőben akár C, és natív alkalmazások helyett is érdemesebb lehet Dart-ot használni. Persze jelenleg ennek nincs túl sok értelme, mivel Dart kódot maximum a Chrome tud futtatni, és még ő sem alapértelmezetten, de ha elterjed, sok szempontból jobb választás lehet, mint a JS vagy akár a Java. Mondjuk nem tudhatjuk azt sem, hogy a JavaScript addigra hol fog tartani, esetleg nem-e emelnek át ilyen Dart-os feature-öket, mint amilyen az opcionális típusosság, ami megint a JavaScriptet teszi majd erősebbé ...  

#blog  

https://docs.google.com/presentation/d/1zfucLA3XNqRb7W56ldU_Biya-IrS00QmSuXNYwewlyg/edit?forcehl=1&hl=hu#slide=id.p19

2013. március 1., péntek

Cloud9


Ha valaki a codeacademy-n (http://www.codecademy.com/) már kiképezte magát JavaScript-ből és HTML-ből (esetleg Pythonból, Ruby-ból, vagy PHP-ból), és nekiállna valami saját kis projektnek, annak tudom ajánlani a Cloud9-et. Ez egy ingyenesen (is) elérhető online fejlesztő környezet, ahol egyből futtatható is az elkészült alkalmazás. Így tulajdonképpen minden egyben van bármilyen webes projekt fejlesztéséhez úgy, hogy nem kell telepítenünk hozzá semmit. Ha komolyra fordulna a dolog, akkor pedig van premium plan ($12/hó), illetve foghatjuk az egész projektet, és átvihetjük egy hoszting szolgáltatóhoz. 

#blog  

https://c9.io/


Embedded Link


Cloud9 IDE | Online IDE – Your code anywhere, anytime
Give us a shout out: Share on twitter Share on Google Share on facebook Share on email · Sign up · Sign out. Reset password. To reset your password, type the full email address or username. You will r...

Először sikerült összekötni két patkány agyát


Még a szimulált valóságos postomban (http://lf.estontorise.hu/archives/305) írtam, hogy a szimulált valóság egyik lehetséges megoldási alternatívája az lenne, ha egyszerűen az agyakat kötnénk össze mindenféle felügyelő MI nélkül, és valamiféle kollektív álomban maguk a résztvevők hoznák létre a világot. Ennek a megoldása persze még fényévnyi távolságban van (ha egyáltalán lehetséges), de ez a kísérlet valami halvány reménysugár arra, hogy egyszer talán mindez lehetséges lehet. 

#blog  

http://pcforum.hu/hirek/14687/Agyakat+kotottek+ossze+interneten+at+a+tudosok.html





Agyakat kötöttek össze interneten át a tudósok
Az amerikai neurobiológusok kísérlete új fejezetet nyithat az idegi kutatás, sőt, az intelligencia fejlődésében is