2013. december 29., vasárnap

Ha ezt így meg tudják csinálni, akkor az nagyon durva

Márpedig ha előrendelni lehet, akkor jó eséllyel meg tudják. Lehet eldobálni a telefont, notebookot, tabletet, stb. és jöhet a valódi argumented reality. Ha csak időközben nem jön valami még sokkal durvább technológia (agyi implantátumon kívűl mást nem nagyon tudok elképzelni, attól meg még messze vagyunk), akkor szerintem a következő pár év kütyük terén a szemüvegekről fog szólni ...

https://www.spaceglasses.com/

MetaPro: 15 times the screen of Google Glass

#blog  

2013. december 14., szombat

Ez tipikusan az az eset, mikor a saját sémáinkat próbáljuk ráhúzni valamire....

Ez tipikusan az az eset, mikor a saját sémáinkat próbáljuk ráhúzni valamire. A DNS programkód, amit a sejt futtat, és felépíti belőle az élőlényt, mint ahogy mi csináljuk a számítógépekkel. De a természet nem így működik. Az egész egy kusza izé, ami amúgy tök jól működik, de nem modulárisan, és nem a mi logikánk alapján van felépítve. Inkább hasonlít önmódosító kódhoz, sőt, még annál is bonyolultabb. Létrejönnek dolgok, amik befolyásolják az olvasást, ami miatt már teljesen máshogy működik az egész folyamat, ami a következő részt olvassa, amiből így már valami teljesen más lesz. És ilyen kusza, nem moduláris, nem hierarchikus dolgokból áll össze minden. Ilyen az agy, a természetes ökoszisztémák, vagy akár az időjárás, az, hogy hol alakulnak ki földrengések, igazából bármi a természetben. Ezt így egyben nem igazá tudjuk kezelni, mert túl komplex. Ezért nagyon veszélyes bármilyen formában is beavatkozni ebbe az egészbe, mert ki tudja mi lesz a következménye. De pont ezért nincsenek is igazán jó eszközeink. Pl. a rák kezelésénél annyit tudunk, hogy kivágjuk, kiégetjük, vagy kilúgozzuk az egész embert. Simán el tudom amúgy képzelni azt is, hogy tényleg létezik valahol valami növény, amit ha elrágcsál az ember, akkor kigyógyulhat a rákból, mert van valami komplex folyamat, amihez ha hozzáadjuk ezt a kis összetevőt, az a rákos sejtek halálát okozza. Pont úgy, ahogy a pillnagó szárnycsapása hurrikánt okoz a káoszelméletes példában. Ebben hozhatnak áttörést a minél nagyobb teljesítményű számítógépek. Ha megmarad az exponenciális növekedés, akkor szimulálhatjuk ezeket a rendszereket, és ha nem is értjük a működésüket, kitalálhatjuk, hogy mi az, aminek hatására az fog történni, amit szeretnénk. Szerintem el fogunk érni egy olyan szintet, ahol bizonyos dolgokat már csak a gépek fognak érteni, de ez nem feltétlenül kell, hogy zavarjon, mivel számunkra igazából csak a válaszok az érdekesek.  

#blog  

http://index.hu/tudomany/egeszseg/2013/12/13/masodik_kodot_is_rejt_a_dns





Rejtett kódot találtak a DNS-ben
Amerikai kutatók több mint negyven év után fedezték fel. Ráírták a másikra, így bújt el.

2013. szeptember 9., hétfő

Sokáig ment a találgatás, hogy a Google-nek lesz-e saját oprendszere

Aztán ugye megjelent az Android, de igazából van nekik valami még érdekesebb, az pedig a Chrome. Amikor megjelent a Chrome, már akkor lehetett sejteni, hogy ez nem egy szimpla böngésző. Volt saját feladatkezelője, minden modul külön process, stb. amik inkább oprendszerekre jellemzőek, mint böngészőkre. Most pedig már van saját "startmenüje" is, ami beépül a gazda oprendszerbe. Komplett alkalmazásokat futtathatunk alatta, és ráadásul nem kell elköteleznünk magunkat mellette, mint ahogy mondjuk Linux és Windows között kell választanunk, mert ez egy gazda oprendszer felett fut. Tehát a Chrome-ot önmagában (nem csak a Chrome OS-t) nevezhetjük a Google operációs rendszerének. Ha majd a mobil változat is utoléri a desktopot, akkor talán (és ez egy nagy talán) sokkal relevánsabb lehet, mint az Android, sőt azt sem tartom kizártnak, hogy pár év múlva az Android alap tartozékává fog válni. Szóval szerintem érdemes odafigyelni a Chrome-ra, és a webes app-okra, mert a jövőben jó eséllyel ez lehet a vezető szoftverfejlesztési trend.

#blog  

2013. szeptember 6., péntek

Ez akkor lesz majd igazán jó, ha mobilra is megjelenik (a cikk szerint a nem közeli...

Ez akkor lesz majd igazán jó, ha mobilra is megjelenik (a cikk szerint a nem közeli jövőben). Szerintem előbb-utóbb a Chrome integránsan be fog olvadni az Androidba is (nem most, de pár év múlva), és teljes értékű app-okat lehet majd oda is fejleszteni oda is pusztán webes technológiákkal, úgy mint FirefoxOS-re. És ebben valószínűleg az Apple és a M$ sem akar majd lemaradni, így ők is támogatni fogják a szükséges webes szabványokat. Így a webes technológiák tényleg valódi platformfüggetlen fejlesztést tesznek majd lehetővé. Persze addig még jópár natív mobilapp-ot el fogunk készíteni.

#blog     

http://itcafe.hu/hir/google_chrome_desktop_alkalmazasok.html





Asztali Chrome alkalmazások érkeztek - IT café Szoftver hír
Asztali Chrome alkalmazások érkeztek - Ötéves lett a Chrome, a Google pedig valami különlegessel készült az évfordulóra: asztali, online kapcsolat nélkül is futtatható Chrome alkalmazásokkal. -- szoftver, google, hír, informatika

Egy ilyesmit el tudnék képzelni a jövőben monitor helyett mobiltelefonhoz

Néhány plusz érzékelővel, és egy okos kesztyűvel akár a desktop környezet is kiváltható lenne. Az ember előtt megjelenne mondjuk 3 virtuális monitor, illetve a billentyűzetet is látná, ha lenéz, miközben a valóságban a buszon ül egy mobillal a zsebében, egy ilyennel, a kezén pedig kesztyűvel.

#blog  

http://ipon.hu/hir/hordozhato_mozi_a_fejre/26765





Hordozható mozi a fejre
A Sony bemutatta a fejen hordható házimozi rendszerének harmadik generációját.

2013. szeptember 1., vasárnap

Ezek szerint a Google-nek is lesz okos órája

Lassan de biztosan minden használati tárgyunk okos lesz. Okos szemüveg, okos óra, okos TV. De a jövőben el tudok képzelni okos KV főzőt, okos villanykapcsolókat, vagy akár okos cipőt, kabátot, stb. Egy Raspberry Pi, ami viszonylag erős hardver, 5000 Ft jelenleg. Kis androidos célhardvereket gondolom még olcsóbban lehet tömeggyártani. Tehát valami pár ezer Ft-ért már "okossá" tehető. Innen meg már adja magát a dolog, hogy miért ne lenne körülöttünk minden okos. Az összes használati tárgy. Ide értve tényleg bármit. Az autónkat, a konyhafelszerelést, vagy akár a ruhánkat is. Ezen a területen még sok minden várható ...

#blog   

http://pcpult.hu/it-technologia/hirek-ujdonsagok/smartwatch-gyarto-ceg-kerult-a-google-egisze-ala.html





Smartwatch gyártó cég került a Google égisze alá
A WIMM Labs még 2011-ben mutatott be egy Androidos smartwatchot, majd ezt követően a cég teljes hallgatásba burkolózott. A honlapjukon mindössze annyi volt olvasható, hogy exkluzív együttműködésbe léptek egy vállalattal - azonban azt nem árulták el, hogy kivel. Sokan az Applere tippeltek, azonban a Google előjött az árnyakból és színt vallott: a saját smartwach projektjüket a WIMM csapatával közösen működtetik.

Egy vízió a jövőről 2050-re

Amúgy semmi extra, a szokásos. Okos épületek, lokális energia és élelemtermelés, robotautók, és egyéb robotok, folyamatos online jelenlét, stb. Az a mókás benne, hogy az ember mindezt kicsit talán még szkeptikusan is olvassa. Olyan futurisztikus az egész, hogy 2050-re így élhetünk, pedig az itt leírt technológiák vagy teljesen kidolgozott formában, vagy előrehaladott kutatások formájában már most léteznek. Ha valakinek lenne rá elég pénze, már most, pár éven belül felépíthetne egy ilyen várost, nincs benne semmi különleges. A fejlődés gátja talán nem is a technológia, hanem az emberek gyatra vágya az újra, és a változásra ...

#blog

http://www.hir24.hu/tudomany/2013/08/29/ilyen-lesz-egy-varos-2050-ben/





Ilyen lesz egy város 2050-ben - Hir24
Megszűnnek a dugók, a boltokban saját magunknak nyomtatjuk ki a személyre szabott árut, az utcákon pedig lámpák helyett fák fognak világítan

2013. augusztus 23., péntek

5000 fényév hosszú gázsugár

Fel tudja ezt valaki fogni, hogy mekkora távolság? A föld-nap távolság kb. 8 fényperc. Hihetetlenül gigászian óriási. A föld, és az egész emberiség annyira hihetetlenül, jelentéktelenül kicsi a világban létező legtöbb objektumhoz képest. És milyen hihetetlen energiák vannak ezekben koncentrálva. Igazából ha találnánk hatékony módszert a hasznosítására, akkor a Nap energiája is több mint elég volna hogy kielégítse minden igényünket, de egy ilyen fekete lyukat, vagy csupán más csillagok fúziós energiáját megcsapolva bármire képesek lehetnénk. Akár teremthetnénk új bolygókat, vagy akár egész naprendszereket. Anyag és energia szinte végtelen mennyiségben rendelkezésre áll az univerzumban. Nincs szükség ehhez nullponti energiára, örökmozgókra, meg mindenféle misztikus dologra. Ott van az az általános fizikai világképünk alapján is. A kérdés csak az, hogy miképp lehet ezt (lehet-e egyáltalán) irányítani, és a saját céljainkra felhasználni. Persze kicsit mulatságosnak tűnik a kérdésfelvetés, ha arra gondolunk, hogy a legtöbb, amit le tudtunk tenni az asztalra, hogy eljutottunk a Holdra. Még csak nem is a legközelebbi bolygóra, csak a Hold-ra ...

#blog    

Reshared post from +Shared Science
Jet of Superheated Gas -- 5,000 Light-Years Long -- Ejected from Supermassive Black Hole
Aug. 22, 2013 — More than thirteen years of observations from NASA's Hubble Space Telescope have allowed astronomers to assemble time-lapse movies of a 5,000-light-year-long jet of superheated gas being ejected from a supermassive black hole in the center of the giant elliptical galaxy M87.
http://www.sciencedaily.com/releases/2013/08/130822122530.htm
#ScienceEveryday   #Space  


2013. augusztus 20., kedd

Lendkerekes energia tároló rendszer

Amikor arról van szó, hogy energiát kellene tárolni, akkor mindenkinek az akkumulátorok jutnak az eszébe, pedig van még egy pár tisztább, és nagyobb hatásfokú módszer. Például az erőművek által előállított hatalmas energiát nem lehet csak úgy akkumulátorokban tárolni. Itt azt szokták csinálni, hogy vizet nyomnak fel egy toronyba a megtermelt árammal, majd ha kell, leeresztik, és egy generátort hajtanak meg vele. Kisebb méretekben pedig egy jó alternatíva az alábbihoz hasonló lendkerekes megoldás.

#blog  

http://www.kickstarter.com/projects/1340066560/velkess-energy-storage





Velkess Energy Storage
We're developing a new flywheel technology which will dramatically reduce the cost of energy storage and clean energy.

2013. augusztus 19., hétfő

Ötletes cucc

Valójában egy sztereó kamera, és egész jól használhatónak tűnik. Kicsit tovább gondolva az eszközt, be lehetne építeni például mobiltelefonokba, amit aztán egy TV-hez kapcsolva olyan mint ha lenne egy desktop PC-nk. Nem kell külön billentyűzet, vagy egér. Ha még esetleg egy mini projektor is van nálunk, akkor a TV sem kell (azt egyelőre nehéz elképzelni, hogy ezt is a telefonba préseljék). De egy ilyen cuccal felszerelt telefon jó beviteli eszköz lenne Google Glass-hoz. Vagy el tudok képzelni egy karkötőt, ami ilyen eszközt tartalmaz, így a felkarunkat, vagy épp a tenyerünket használhatnánk billentyűzetként és touchpad-ként Google Glass-hoz.

#blog  

http://www.kickstarter.com/projects/haptix/haptix-multitouch-reinvented





Haptix: Multitouch Reinvented
Transform any flat surface into a 3D multitouch surface to control your computer, TV, or any other screen.

2013. augusztus 13., kedd

Azon gondolkodtam, hogy lehetne minél jobb távkonferencia élményt adni

Eddig a legjobb megoldás amit láttam, hogy egy asztalt körberaktak monitorokkal, így olyan érzete volt az embernek, hogy vele szemben ülnek a többiek. Az csak a gond, hogy egy ilyen rendszer nagyon drága a sok monitor miatt. Ezt lehetne kiváltani projektorral. Az asztalt simán lapokkal kellene csak körberakni, a projektor képét pedig szoftveresen lehetne úgy torzítani, hogy normál képek jelenjenek meg a lapokon. Esetleg egy kis forgó tükrös rendszer segítségével lehetne különböző képeket pozicionálni az egyes lapokra. A projektor gyorsan váltogatná a képeket a tükör állásának megfelelőn, és mindig annak megfelelő képet mutatna, amerre a tükör áll. Mondjuk nem tudom, milyen ezeknek a házi projektoroknak a képfrissítése, de talán kivitelezhető lenne. Így akár egyetlen projektorral ki lehetne tölteni a teljes látóteret is, úgy, hogy a képet a szobában lévő tárgyakra torzítják. Megfelelő képfrissítéssel akár 3D-s vetítést is meg lehetne oldani, és ha a túloldalon sztereó kamerák vannak, akkor a tagok 3D-s képét lehetne továbbítani. Így akár egész élethű távkonferenciát is lehetne szervezni viszonylag olcsó eszközökkel. (Többszereplős 3D-s játékokról nem is beszélve.) 

#blog  

2013. augusztus 10., szombat

Közösségi finanszírozás vs. adományozás


Épp az Ubuntu Edge kapcsán gondolkodtam rajta, hogy az emberek fejében mennyire keveredik a közösségi finanszírozás, és az adományozás fogalma. Pedig nagy a különbség. Amíg az adományozás csak "jófejség", más munkájának elismerése, addig a közösségi finanszírozás kő kemény üzleti modell, nem pedig pénz tarhálása, mint ahogyan azt sokan gondolják. Az Ubuntu Edge-nél (és a közösségi finanszírozású projekteknél általában) ez jól látszik a reward-ok rendszerén. Itt ugyanis ha valaki nagyobb összeget ad a projekt létrejöttére, az kedvezményesen juthat hozzá a telefon egyes példányaihoz. Ebben az esetben tehát inkább hasonlítható az egész a mobilszolgáltatók prepaid rendszeréhez, ahol minél több beszélgetési időt veszünk meg előre (minél drágább feltöltőkártyát veszünk), annál kedvezményesebb áron juthatunk hozzá ehhez. És egy mobil feltöltőkártyáról senkinek nem jut eszébe a kéregetés.

Mivel az ötlet, és a megvalósításához szükséges erőforrások a legritkább esetben vannak egy helyen, ezért egy termék, vagy szolgáltatás létrejöttének standard lefolyása a következő: valakinek a fejében megszületik az ötlet, kidolgozza azt, majd kockázati tőke után néz. Találni kell egy befektetőt, akinek van elég pénze, és a jövőbeni megtérülés reményében jutalék fejében ad is a megvalósításra. Az így létrejött termék aztán a későbbi értékesítés folyamán termeli ki a belé fektetett pénzt is munkát. Jó esetben ... Ez ugyanis elég nagy kockázat vállalását jelenti. Ezért is hívják kockázati tőkének. A közösségi finanszírozás esetén ez az egész megfordul. Kvázi előre eladják a terméket a jövőbeni felhasználóknak, és az így összejött pénzből utólag fejlesztik ki azt. Így nincs kockázat, és nincs szükség külső befektető bevonására, hiszen itt a befektetők maguk a későbbi felhasználók, akik sok kicsi sokra megy alapon adják össze a pénzt a fejlesztésre.

Akkor sem változik sokat a helyzet, ha elvesszük a képletből a reward-okat. Például a fejlesztő egy nyílt forrású szoftver fejlesztésére gyűjt pénzt. Ebben az esetben a reward maga az elkészült szoftver, amihez a felhasználók "fizess amennyit akarsz" modellben jutnak hozzá (és itt opció az is, hogy nem fizetsz semmit). Tehát ezt sem igazán nevezném adománynak, sokkal inkább a szoftver elővásárlásának, hiszen az történik, hogy azok az emberek, akiknek ez a szoftver kell, tetszőleges összegért megvehetik azt, és ezt az összeget történetesen előre kell fizetni. Tehát ily módon itt két nem szokványos üzleti modell keveredéséről beszélhetünk.

Régebben sokat gondolkodtam azon, hogy miért van az, hogy a nagy open source projektek (Mozilla Firefox, WikiPedia, stb.) vígan megélnek adományokból, amíg kis méretekben (buy me a beer, stb.) nem igazán működik a dolog. A megoldás szerintem itt is az, hogy amit a nagyok csinálnak, az közösségi finanszírozás, nem adományok gyűjtése. Mind a WikiPedia-nál, mind a Mozillánál egyértelmű, hogy az összegyűlt összegből történik a fejlesztés. Ha a felhasználók nem adnak pénzt, nem fog működni a dolog. Tehát itt is ugyanaz történik, "fizess amennyit akarsz" modellben fizetnek a felhasználók a termékért, és előfinanszírozzák azt.

Úgy gondolom, hogy ennek a tudatosítás mind a felhasználók, mind a fejlesztők fejében jótékonyan hatna az egész ökoszisztémára. Ha egy nyílt forrású projekt számára elég pénz gyűlik össze, akkor a fejlesztők adott esetben tudják ezt fő munkaidőben csinálni, és sokkal gyorsabb lenne a fejlődés. Valószínűleg sok ilyen projekt fejlesztése állt már le, vagy csak stagnál a pénz hiánya matt, és ennek nem az az oka, hogy az adott termék ingyenes, de még csak nem is az, hogy a felhasználók zsugoriak lennének. Egyszerűen az ok a rossz kommunikáció. Amíg a fizetési mód adományként van feltüntetve, addig a felhasználók nem érzik, hogy fizetniük kellene az adott termékért, vagy szolgáltatásért, noha pár dollárt minden további nélkül fizetnének érte. Ez pedig rossz a fejlesztőnek, aki nem tudja megvalósítani az ötletét, és rossz a felhasználónak is, aki szívesen használná a szoftvert, valójában fizetne is érte pár dollárt, de nem teszi, mert nem érzi, hogy fizetnie kellene.

Gondoltam rá, hogy talán érdemes lenne létrehozni egy portált kifejezetten nyílt forrású szoftverek finanszírozására. Itt bárki publikálhatná az ötletét, és lehetőség lenne összegyűjteni a pénzt az indulásra, valamint már meglévő projektek esetén pénzt lehetne gyűjteni a következő verzió elkészítésére. Szerintem ez a modell komplett cégeket eltarthatna, akik ingyenes szoftverek fejlesztéséből élnek, míg ha ez elsőre kicsit paradoxnak is hangzik.

Azt gondolom tehát, hogy nagy jövő van még a közösségi finanszírozás előtt, de ahhoz, hogy igazán működjön a dolog, először az emberekben kellene tudatosulnia, hogy valójában miről is van szó. Tudatosulnia kellene, hogy a közösségi finanszírozás nem kéregetés ...      

#blog  

2013. július 27., szombat

Kéne egy tudomány/tech magazin, minek az a lényege, hogy az adott nap összes...

Kéne egy tudomány/tech magazin, minek az a lényege, hogy az adott nap összes releváns tudomány/tech hírét hozza, de csak a lényeget kiemelve. Szabály lenne, hogy maximum 5 mondat (esetleg valami még erősebb karakter korlát) lehet egy hír. Amolyan twitter szerű megoldás, de 160 karaktert kevésnek tartanék erre.

Szerintem összesen kb. napi 2-3 órám elmegy hírolvasásra. Már próbálok szelektálgatni, és olvasás közben is átugrálni mondatokat, de így is sok erőforrás. Aki pedig nem követi a történéseket, az lemarad. A web olyan információáradatot zúdít az emberre, amit az már sokszor képtelen feldolgozni, ezért szerintem lenne létjogosultsága egy ilyen "tl;dr; oldalnak". Ha biztos lennék benne, hogy ezt Magyarországon meg lehet csinálni rentábilis formában (pénzben visszahozná a befektetett energiát), még be is vállalnám, hogy csinálom.

#blog    

2013. július 23., kedd

A SZTAKI-s jelnyelv fordító eszköz kapcsán jutott eszembe egy másik eszköz,...

A SZTAKI-s jelnyelv fordító eszköz kapcsán jutott eszembe egy másik eszköz, az "ultrahangos fehér bot" vakoknak. Az egész egy ultrahangos távolságmérő, és egy a telefonokban is használt vibráló izéből (nem tudom mi a neve) állna össze, és elférne az ember tenyerében. Tulajdonképpen egy kesztyű lenne. A vibrálás sebessége az ultrahangos egység által érzékelt távolságtól függene. Így a vak ember letapogathatná a környezetét, de sokkal nagyobb távolságban, mint ahogyan bottal tudná, illetve kevésbé zavaró módon. Tudom, van már retina protézis, meg miegymás, de ez egy egyszerű eszköz. Szerintem fillérekből elő lehetne állítani, és nagy segítség lenne.

#blog  

2013. július 15., hétfő

Bloggolj!


Annak idején írtam pár oktató jellegű postot a Tanuljunk együtt IT csoportba. Egyszer asszem +Papp Zsolt meg is kérdezte, hogy miért éri meg valakinek ilyen oktató bejegyzéseket írni a helyett, hogy ráül a tudásra. Asszem azt írtam, hogy ha ennek valaki hasznát veszi, attól én már eleve boldog vagyok, meg hogy én is sokat tanultam ilyenekből. Meg hogy aki ezt olvassa, lehet, hogy később ír majd egy másik hasonló bejegyzést, aminek majd én veszem hasznát.

Ami még a történetben érdekes, hogy van egy WordPress pluginem, és egy telepített WordPress blogom (http://gp.estontorise.hu), ahová kicsatornázom innen G+-ról az érdekesebb tartalmakat (köztük ezeket az oktató anyagokat is).

Nemrég kaptam egy e-mailt, hogy valaki egy ilyen bejegyzés alapján rátalált Google-ben az egyik ilyen kicsatornázott postomra, és neki pont WordPress fejlesztőre lenne szüksége. Annyi azért csorbítja a történet szépségét, hogy jelenleg annyira el vagyok havazva, hogy nem mertem már pluszba bevállalni egy ilyen projektet, de azért a tanuláság az maradt. Tessék blogolni, mert az ilyen "céltalan munka" is hosszú távon meghálálhatja a belé fektetett időt. Például úgy, hogy megtalálnak a neten, és munkát ajánlanak neked ... ;)

#blog    

2013. július 13., szombat

Life Blogging


Épp tegnap gondoltam rá, hogy sokszor csinál valami jópofát a kölök, és végigfut az agyamon, hogy milyen jó lett volna levideózni, vagy lefényképezni. Pár év múlva szerintem ez már úgy fog kinézni, hogy mindenkin ott lesz a Google Glass, vagy valami hasonló eszköz, ami az olcsó, gyors, nagy tárolókapacitásnak köszönhetően folyamatosan rögzíti majd amit látunk. Mondjuk ilyen körkörös rendszerben, ahol minden rész 24 óráig elérhető, aztán folyamatosan írják felül a másnapi történések. Ha valamit le szerettünk volna fényképezni, vagy videózni, azt egyszerűen kijelöljük a stream-ből, és mehet hosszútávú tárolásra a cloud-ba. Valahogy így képzelem a nem túl távoli jövőt ...

#blog   

2013. július 11., csütörtök

A +Dart elterjedésére szerintem nagyon jótékonyan hatna, ha összedobnának...

A +Dart elterjedésére szerintem nagyon jótékonyan hatna, ha összedobnának hozzá egy futtatókörnyezetet JVM fölé. Annak ellenére, hogy a Dart-nak van saját futtatókörnyezete, lenen értelme egy ilyen párhuzamos projektnek, hiszen így beágyazható lenne a meglévő Java alkalmazásokba. Tehát rögtön futtathatnánk Dart-ot Androidon, Dart-ban bővíthetnénk a meglévő szerver oldali Java alapú rendszerünket, stb. Biztos sokan kezdenék el használni. Aztán utólag még mindig lehet dönteni, hogy maradnak JVM-en, vagy inkább raknak alá natív DartVM-et.

Igazából egy dart2java fordítónak szerintem legalább annyira létjogosultsága lenne szerver oldalon (+android), mint amennyire létjogosultsága van a dart2js-nek kliens oldalon.

#blog  

2013. július 9., kedd

Érdekes írás

Egy baktérium mindössze 120 génnel is leírható, de csak azért lehet ilyen egyszerű, mert él benne egy másik baktérium, ami bizonyos feladatokat elvégez helyette. Tehát ezt a kérdést nem vizsgálhatjuk csak önmagában, csak az egész ökoszisztémát egyben. Ez az ami egyébként nagyon nehézzé teszi az élet (és úgy általában az összes természetes folyamat) megértését, hogy itt minden mindennel összefügg, nem lehet jól modulokra bontani, mert hamis következtetésekre jutnánk. Ez a különbség a mesterséges és az evolúciósan kialakult rendszerek közt. Mi emberek szisztematikusan építkezünk, az evolúció esetén pedig van egy feltétel rendszer, ami az egész ökoszisztémára hat, és az egész egyben változik, amíg ki nem elégíti azt. Ez egyfelől hibatűrővé teszi, mert egy-egy folyamat "több lábon is állhat", ugyanakkor kiszámíthatatlanná is, mivel a kapcsolatok bonyolult hálójának köszönhetően egy kis változás drasztikus változásokat okozhat valahol máshol. 

#blog  

http://ipon.hu/hir/hany_gen_kell_az_elethez/25936





Hány gén kell az élethez?
A szakértőket régóta érdekli, hogy vajon mekkora lehet az a génállomány, amely feltétlenül szükséges az élethez. Egyre inkább úgy tűnik azonban, hogy ez nem egy egyszerű számmal leírható feltétel, hanem a probléma jóval bonyolultabb. 

2013. július 7., vasárnap

Az AppScale segítségével Google AppEngine alkalmazásokat futtathatunk bármilyen...

Az AppScale segítségével Google AppEngine alkalmazásokat futtathatunk bármilyen cloud szolgáltatónál, vagy saját szerveren. Így nem kell félnünk attól, hogy "beszorulunk" a Google platformjára. Ez igazából még egy érv a mellett, hogy AppEngine-en kezdjük el fejleszteni az alkalmazásunkat, hiszen amíg elindul a szolgáltatás, teljesen ingyen van, később pedig dönthetünk, hogy maradunk a Google-nél, vagy (minden gond nélkül!) költöztetjük az egész cuccot AWS-re, vagy akár saját szerverre.

#blog     

(Ma AppEngine hétvége van nálam.) 

http://www.appscale.com/





AppScale
AppScale is an open-source emulation of the award winning Google App Engine platform. AppScale is capable of running on any private or public virtualized environment. Develop, deploy and scale your applications with absolute ease.

Vannak itt G+-on többen is, akik nagyon színvonalas tech oldalakat, blogokat futtatnak....

Vannak itt G+-on többen is, akik nagyon színvonalas tech oldalakat, blogokat futtatnak. Azon gondolkodtam, hogy ha üzleti vállalkozásként tekintenék egy ilyen oldalra, akkor angolul kezdenék neki. A web a mennyiségekről szól. Gondoljunk csak a Google centenként összeszedett milliárdos vagyonára. Magyarország egy pici ország, a magyar nyelv pedig egy olyan nyelv, amit csak ebben a pici országban beszélnek. Ráadásul a magyar nyelvet beszélők közül is csak egy szűkebb réteget érdekel egy adott téma. Persze, lehet így is sikeresnek lenni, de sokkal nehezebb. Főleg ha a weben jelenlévő felhasználók, és ezzel az elérhető potenciális célközönség méretét arányítom az (ehhez képest) elenyésző magyar olvasótáborhoz. Nem hiszem, hogy a magyar szakemberek felkészületlenebbek, vagy rosszabbul képzettek lennének, mint USA-béli társaik. A gond szerintem sokkal inkább a fentiekben rejlik. Mi magyarok agyban sokszor be vagyunk szorulva a nyelvünkbe, és ezzel együtt a piciny országunkba.   

Mondjuk ez esetben én vagyok az a pap, aki bort iszik, és vizet prédikál, mert én is magyarul blogolok. Esetemben ennek főleg az az oka, hogy nem érzem annyira biztosnak az angol tudásomat, hogy angolul cikkezzek. De azért kacérkodok a gondolattal, hogy tech témában írok pár angol nyelvű cikket, forráskód részletekkel sűrűn teletűzdelve, mert azt a nyelvet azért jobban "beszélem". Kísérletnek sem lenne utolsó, összehasonlítani egy kis idő után a magyar és az angol nyelvű blog forgalmát. Aztán meg ki tudja. Valaki ebből él ...

#blog  

2013. július 6., szombat

Kipróbáltam, hogy mennyire nehéz a Google AppEngine-t használni

Java-val próbálkoztam, de gondolom Python és PHP esetén is hasonló a dolog. Igazából meglepően egyszerű az egész. Van egy Eclipse plugin, amit telepíteni kell. Aztán létrehoz az ember egy AppEngine web projektet, ami néhány speciális libet kivéve olyan mint egy sima Java webprojekt. Kötöttebbek a lehetőségek mint egy általános alkalmazásszerveren, de az alap dolgok megvannak. Ha nincs szükségünk semmi extrára, akkor az ember észre sem veszi, hogy AppEngine alá fejleszt. Készíthetünk servleteket, jsp oldalakat, az elosztott adattárolót sima JPA rétegen keresztül érhetjük el, stb. Az elkészült app-ot lokálisan tesztelhetjük mint bármely más Java-s webappot. Ha kész, akkor pedig csak kiválasztjuk a menüből a deploy-t, megadunk egy app id-t amit előzőleg az admin felületen lehet létrehozni és már fent is van.

És hogy miért AppEngine? Mert teljesen leveszi az ember válláról az erőforrás elosztás terhét. Igazából soha nem tudhatjuk, hogy épp milyen szerver szolgálja ki, de ezzel nekünk nem is kell foglalkozni. A Google rendszerei megoldják, hogy minden request vállalható időn belül ki legyen szolgálva. Tehát jelenleg talán ez a legegyszerűbb módja annak, hogy valaki jól skálázódó, nagy forgalmú rendszert állítson elő minden különösebb speciális tudás nélkül. A másik előny a jelentős free kvóta. Ennek köszönhetően egy kis forgalmú, vagy kezdő szolgáltatás teljesen ingyen van a készítőjének.  

Aki startupon töri a fejét, annak ajánlatos megfontolnia ezt a lehetőséget. 

#blog  

2013. július 3., szerda

Brackets


Kipróbáltam ezt a Brackets-et. Egész kis pofás. Azt kell róla tudni, hogy egy HTML szerkesztő kódkiegészítővel, szintaxis kiemelővel, mindennel. HTML-ben és JS-ben készült, az Adobe fejleszti, és open-source. Elsőre azt hittem, hogy ez valami online cucc, de annak ellenére, hogy HTML+JS ez egy Desktop App. Kb. 5 percet használtam, úgyhogy nem vizsgáltam meg tüzetesebben,  de úgy láttam, hogy egy beágyazott Chrome + egy Node.js az App lelke. Nagyon jó példa arra, hogy mostanra a HTML+JS teljes értékű desktop fejlesztőeszközökké váltak. Szóval ha valaki desktop alkalmazásfejlesztésre adja a fejét, érdemes ezt az alternatívát is megvizsgálni. Mert gyorsan lehet így UI-t fejleszteni, ráadásul a meglévő eszközökre építve nagyon szép, kényelmes és modern UI-kat, cross-platform módon.

#blog  

http://brackets.io/





Brackets
About Brackets. Brackets is an open-source editor for web design and development built on top of web technologies such as HTML, CSS and JavaScript. The project was created and is maintained by Adobe, and is released under an MIT License.

2013. július 1., hétfő

A "Mi az élet értelme?" kérdésnek önmagában azért nincs értelme,...

A "Mi az élet értelme?" kérdésnek önmagában azért nincs értelme, mert csak adott kontextusban értelmezhető, globálisan nem.

Az egyén szempontjából szerintem mindössze annyi a lényeg, hogy jól érezze magát. Örülni kell a létezésnek, és "élni a lehetőséggel" amíg lehet. Bármilyen más preferencia szerintem ennek van alárendelve. Még az önfeláldozás célja is valahol az önös érdek, mert jobban érezzük magunkat tőle, és mardosna a lelkiismeret, ha nem tennénk meg. Ennyire egyszerű.

A közösség, vagy más emberek szempontjából az egyén életének értékét az adja, hogy mennyit tett a közösségért, vagy másokért. Ezért olyan nagy veszteség mondjuk egy tudós, vagy egy jó ember elvesztése. De ez csak mások preferenciája. Az egyén szempontjából ez nem jelenti azt, hogy tudósnak, vagy csak úgy egyáltalán jó embernek kellene lennie. Az ő szempontjából azért lehet értelme ennek, mert ettől érzi jól magát.

És végül globálisan, az egész univerzum szempontjából (merthogy implicit módon így szoktuk feltenni, és érteni a kérdést) az egyén életének semmi értelme nincs. Ugyan mit számít a világegyetem végtelenjéhez képest a porszemnyi földön mindössze villanásnyi ideig jelenlévő emberi kultúra létezése? Egyszer majd eltűnik az egész, mintha sosem lett volna, és senki nem fog emlékezni rá. Ugyanúgy, ahogyan eltűnik az egyén is, majd azok is, akiknek valaha valamit is számított a léte.

Az ember élete olyasmi mint egy kis hullám, vagy inkább csak amolyan fodrozódás a vízen. A semmiből lesz, és idővel ugyanúgy semmivé foszlik el. Talán hatással van más hullámokra, egyesek talán nagyobb fodrok, mások csak kisebbek, de összességében nincs nagy jelentősége egy kis hullámnak a víz felszínén.

Igazából talán többet nem is érdemes foglalkozni a kérdéssel. Inkább megyek labdázok kicsit a kölökkel ... ;)  

#blog  

2013. június 28., péntek

Tök érdekes figyelni a gyereket, ahogy fejlődik a szókincse

Nem beszél még, csak saját szavai vannak. De ami igazából érdekes, hogy milyen kényszeresen próbáljuk az ő szavait a mi szavainknak megfeleltetni. Ez ezt jelent, az azt, aztán később rájövünk, hogy mégsem. Arra jöttem rá, hogy ez teljesen rossz irány. Az ő fejében egy sokkal tágabb kategória rendszer van a világra. Van szó például a szájba vehető dolgokra, de olyan szó is van, amire nem is lehet jó kategóriát ráhúzni. A "te-ta" például mindenféle lógó, himbálódzó, rezgő, stb. dolgot jelent. Érdekes lenne belelátni a fejébe. Meggyőződésem, hogy valami mienkétől gyökeresen különböző mód az, ahogyan ő látja a világot. Olyan mintha a kezdetben egységes maszlagot valamilyen tulajdonságok mentén elkezdte volna particionálni, de a felbontás még a mienknél sokkal durvább. A későbbiekben ez fog finomodni, míg végül eljut a valódi szavakhoz, és általános fogalmakhoz.

Ugyanez történt a látásával is, mikor még kisebb volt (legalábbis én így láttam). Kezdetben csak bambán, defókuszáltan nézett ki a fejéből. Valószínűleg a világot egy összefüggő maszlagként látta. Értelmezhetetlen volt számára az egész. Aztán elkezdte érzékelni a mélységet. Ahogy mozgatta a fejét, meg tapogatott, megtanult térben látni, és ahogy elkezdte mozgatni a dolgokat, a világ különálló objektumokra esett szét. Ez is egyfajta particionálás.

Ezek alapján úgy érzem, hogy nagyon alapvető dolgokat is úgy tanulunk életünk során, nincs beépítve algoritmus a látásra, a beszédre, a világot alkotó szemantikus háló felépítésére, stb. A trükk a struktúrában rejlik, amiben ezek a dolgok ki tudnak alakulni. Ha ezt sikerülne elcsípni, akkor lennénk képesek a klasszikus értelemben vett, emberihez hasonló MI létrehozására. Ezek olyan alacsony szintű dolgok, amiknek kvázi semmi köze ahhoz, hogy amúgy hogyan gondolkodunk, mert az ugye magától alakul ki, ez csak a közeg hozzá.

Azon is gondolkodtam, hogy ez mennyire hasonlít az evolúcióhoz. Ha a gondolkodást magát akarnánk számítógépre leképezni (van egy ilyen MI irányzat - szemantikus hálók, tudás reprezentáció, stb.), az olyan mint ha szervenként szisztematikusan szeretnénk felépíteni egy élőlényt. Baromi nehéz feladat lenne. Ugyanakkor az evolúció egy viszonylag egyszerű algoritmussal megoldotta mindezt. Csak a környezeti paramétereket kell megfelelően beállítani, megteremteni az evolúció lehetőségét, és várni, míg kialakul. Tehát itt is a környezet, a rendszer struktúrája teremti meg a feltételeket arra, hogy kialakuljon a kívánt élőlény. Talán az agyban is ez történik. Adott egy struktúra, adottak a környezeti hatások, és ebben a közegben evolúciós úton alakulnak ki a látás, a hallás, a gondolkodás algoritmusai. Ebben az evolúcióban tehát ezek a működések (látás, hallás, gondolkodás) az egyedek, és a környezet is annyira előkészített, hogy ne kelljen évmilliókat várni a kialakulásukra, elég legyen hozzá pár év, amíg egy gyermek felnő. 

Ami tehát a lényeg, hogy az agy működésének a hátterében talán valami sokkal egyszerűbb struktúra rejlik. Mondjuk annál talán bonyolultabb, mint a jelenlegi nagyon leegyszerűsített neurális modellek.

Sokat lehet szerintem tanulni abból, ha az ember figyeli, hogy hogyan fejlődik egy gyermek. Bizonyára sokat is tanultak az MI rendszerek fejlesztői, és amiket leírtam, az jó eséllyel nekik teljesen triviális. Ennek ellenére jó érzés figyelemmel kísérni, és "újra felfedezni" ezeket. :)  

#blog   

2013. június 24., hétfő

Érdekes kezdeményezés

Alapvetően én látnék benne fantáziát, de nem olyan formában, hogy X ezer Ft-ot hozzávágnak az emberhez. Ezt az emberek egy jó része szerintem élből elinná, eldorbézolná, stb. és jobb nem lenne semmi, csak még többen élnének az utcán. Aminek értelme lenne, ha bizonyos élelmiszerek, szolgáltatások, energia, lakás stb. ingyen lennének, vagy ezt a pénzt valamilyen utalványok formájában csak erre lehetne elkölteni. Tehát mindenkinek biztosítva lenne valamilyen lakás, vagy ugyanilyen értékben utalvány lakóhely vásárlására, biztosítva lenne az étel, és az energia ami a megélhetéshez kell. Így nem éhezne senki, nem élne senki az utcán, nem fázna senki télen, stb. Szerintem erre ki lehetne alakítani valamilyen optimális rendszert. Erre szerintem elég lenne az a cikkben említett 40-50 ezer Ft. Hiszen az erre a célra kialakított gazdaságok, pékségek, stb. olcsón, adók és kereskedői jutalékok nélkül állíthatnák elő az élelmet. Az alanyi jogon járó könnyű szerkezetes házak/lakások futószalagon gördülhetnének ki a gyárból, ugyancsak adók és jutalékoktól mentesen, akár célgépek által építve. Az energiát pedig megújuló forrásokból állítanák elő, lehetőleg helyben, hogy ne vesszen el sok a szállításon, és minél kevésbé függjön a központi hálózattól. Ez szerintem így reális és megvalósítható. Sok munka, sok fejlesztés, de kivitelezhető lenne, pénzbe pedig csak a luxus kerülne ...   

Egyszer szerintem már olvastam erről, akkor asszem +Kemény Zsolt ajánlotta. 

#blog  

http://utajovobe.eu/hirek/eu-tarsadalom-es-jog/3507-jarjon-penz-csak-azert-mert-elunk





Járjon pénz csak azért, mert élünk?

2013. június 22., szombat

Mikor az ember már úgy érzi, hogy érti a DNS (és az élet) működését, kiderül,...

Mikor az ember már úgy érzi, hogy érti a DNS (és az élet) működését, kiderül, hogy az egész valami sokkal sokkal bonyolultabb dolog. Én annak idején azon gondolkodtam el, hogy az ember miért nem egy golyó. :) Ahogy elképzeljük, hogy osztódnak a sejtek, a végén egy nagy gömbnek kellene lennünk. Ezzel szemben vannak végtagjaink, szerveink, stb. Egy biológus haverom mesélte, hogy ez azért van, mert bizonyos gének csak később aktiválódnak, az egész folyamat környezetfüggő. De vannak részek, amik egyszer így, egyszer úgy értelmeződnek, vannak teljesen funkció nélküli szakaszok, stb. Az egész dologban a DNS csak egy tényező. Fontos tényező, mert ez tárolja a kódot, de az, hogy végül mi lesz belőle, bonyolult folyamatok egymásra hatásának eredménye. A DNS alapján fehérjék keletkeznek, de a folyamatra visszahatnak az előzőleg keletkezett fehérjékből összeálló dolgok. Ráadásul a cikk arról beszél, hogy erre még külső hatások is hatnak, amik úgy hathatnak vissza a DNS-re, hogy azt az utódok örökölhetik. Ezek miatt gondolom úgy, hogy pöccre visszafejthetjük az emberi DNS-ben tárolt teljes információt, feltérképezhetünk minden bázispárt, sokkal előrébb nem fogunk jutni, mert ezeket a bonyolult folyamatokat képtelenek leszünk átlátni. Ezekre szerintem csak gépek lehetnek képesek ...  

http://ipon.hu/elemzesek/epigenom_%E2%80%93_a_genek_rendezoje/1755/2

#blog  





Epigenom – a gének rendezője
Az epigenetika tudománya az öröklés olyan formáival foglalkozik, amelyek nem köthetők a DNS szekvenciájának megváltozásához, hanem az egyes gének kifejeződésében bekövetkező változásokkal magyarázhatók.

2013. június 6., csütörtök

Chromium Embedded


A CEF lényege, hogy a segítségével Chrome-ot (WebKit, V8) ágyazhatunk alkalmazásokba. Például készíthetünk HTML + JS segítségével desktop app-okat. Jelenleg .NET, Java, Delphi, és Python port van hozzá. Annak idején én nézegettem, de még nagyon kezdetleges állapotban volt. Épp olyan megoldást kerestem, amiben nagyon egyszerűen és gyorsan lehetne desktop UI-t fejleszteni. Jelenlegi állapotában már ideálisnak tűnik a feladatra.  

#blog  

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





chromiumembedded
A simple framework for embedding chromium browser windows in other applications.

2013. június 1., szombat

Önellátó robotgazdaságok


Újra a fejembe rágta magát a gondolat, hogy vajon mi a konkrét technológiai akadálya annak, hogy önműködő élelmiszerfarmokat hozzunk létre. Egy ilyen farmot egy nagy üvegházként tudnék elképzelni. Az üvegház belsejében zárt ökoszisztéma működik. Zöldségek, gyümölcsök, esetleg kis halastavak, stb. Az ökoszisztéma működését számítógépek felügyelik. A termést robotok takarítják be, és állítják elő számunkra az élelmet. Az energiaellátásról napelemek, és szélerőművek gondoskodnak. A tápanyag utánpótlást pedig a visszavezetett szennyvíz, tárgya, és biológiai hulladék biztosítaná, ezzel egyben megoldva a szennyvíztisztítás kérdését is. Tulajdonképpen egy ilyen gazdaság olyan "fekete doboz" lenne, ami folyamatosan képes ingyen élelmet előállítani.

Igazából meg lehetne valósítani azt, hogy minden egyes ember alapvető szükségletei ki legyenek szolgálva teljesen ingyen. Állampolgári jog lehetne valamilyen alap lakóhely, annyi élelem amennyi elég, hogy senki ne éhezzen, és az alapvető szükségletek kielégítésére elegendő energia. Igazából csak a luxusért kellene dolgozni. A divatos ruhákért, a legújabb kütyükért, a finom kajákért, szebb lakóhelyért, stb. de a sima megélhetés nem lenne gond senkinek.

Az egészben a legfurcsább, hogy ha valaki feltenné a kérdést, hogy miért ne lehetne megvalósítani egy ilyen utópisztikus világot, nem tudnék rá válaszolni. Úgy érzem, minden technológia rendelkezésre állna a megvalósításhoz. Érdekes lenne csupán egy kis falut felépíteni kísérletként, ami így működik. Egyáltalán nem tűnik lehetetlen küldetésnek ... 

#blog  

2013. május 17., péntek

A gwtproject.org a GWT új, közösségi oldala

A gwtproject.org a GWT új, közösségi oldala. Úgy látom, kezd nagyon közösségi irányba tolódnia GWT, és igazi, közösségi open source projektté válni. Erre enged következtetni ez a saját oldal, illetve hogy minden fórumon próbálják nyomni, hogy a fejlesztők járuljanak hozzá a fejlesztéshez. Ennek talán az az oka, hogy az egyéb technológiák miatt talán kezd kicsit háttérbe szorulni a Google-nél a GWT. Erőteljesen tör előre a Dart, illetve a tiszta JS alapú technológiák, mint amilyen az AngularJS is. Például a Google+-hoz már nem használtak GWT-t, tisztán JavaScript-ben készült a kliens oldal. Ennek ellenére ez nem egy rossz technológia, és minél inkább megy nyílt irányba, nekem annál inkább szimpatikus. Ráadásul szerintem nagy kiaknázatlan potenciál van még a Java kód újrafelhasználhatóságában, mivel a GWT-s klienshez elkészített Java kód egy része felhasználható mondjuk az Android kliens megvalósításához, vagy J2ObjC-vel akár az iPhone-os kliens kialakításához is. Erre egy nagyon jó példa a PlayN, ahol elég egyszer implementálni a játékot, amit aztán lefordíthatunk JS-re, Android-ra, iPhone-ra, vagy éppen Flash-re tulajdonképpen minden módosítás nélkül. Úgy látom, hogy jelenleg a web fejlesztő és a mobil app fejlesztő két külön állatfajta, pedig lényegében ugyanarról van szó. Ha pedig egy cég több platformra fejleszt, és a kód egy részét újra tudja hasznosítani, az jelentős piaci előnyt szerezhet ez által. Én ebben azért látok fantáziát, így egyelőre semmiképp nem temetném a GWT-t. 

#blog  

http://www.gwtproject.org/


Embedded Link


This is a beta version. If you find errors, please report them or ...
Home; Articles. Overview · DOM Memory Leaks · Dynamic Host Page · Elemental · Fragment Merging · GWT iPhone · MVP Part1 · MVP Part2 · Security · Super Dev Mode · Testing · JSON & Mashups · GWT & Hibernate. Documentation. Latest. Overview · Accessibility · ClientBundle · Code Splitting ...

2013. május 1., szerda

Zebra (HTML5 Canvas Rich UI JavaScript Library)


Sosem értettem, hogy miért nem gyártanak Canvas alapú UI toolkiteket. Olyanokat, mint amilyen a Flash alapú Flex is volt, mielőtt a Flash-t elkaszálták volna. Annak idején nagyon szemezgettem a technológiával, mert nagyon jól kinéző UI-kat lehetett összerakni, és mivel Flash-en futott, ezért minden böngészőben pöccre ugyanúgy nézett ki. A hátránya, hogy ugye a keresők nem tudják feldolgozni, de nem is honlapokat kell ilyennel fejleszteni, hanem webappokat. A Zebra ebből a szempontból hiánypótló. HTML5 Canvas alapú RichUI toolkit JavaScript-ben szép OOP API-val, és néhány hasznos kiegészítéssel. Akár tekinthetjük a Flex újragondolásának is a mai igényekre szabva. Az oldal elmondása szerint minden modern böngészőben fut, legyen az desktop, vagy mobil. Bár az Android telefonomon nem sikerült életet lehelni belé, IE9-ben, FFoxban és Chrome-ban remekül futott. A sebességére sem volt panasz. A liszensze is "business friendly" LGPL, tehát így elsőre semmi kivetnivalót nem tudtam találni benne. Tehát a Zebra-nak köszönhetően ki lehet dobni a Flex (Flash) UI-kat, az Appleteket és JavaFX app-okat (akinek nem tetszik a JS, használhat GWT-t). Egyelőre nagyon tetszik.    

#blog  

http://www.zebkit.com/
https://github.com/barmalei/zebra





| HTML5 Canvas Rich UI JavaScript Library
Zebra brings fresh view and possibilities to develop WEB based Rich UI applications. The approach sits on top of HTML5 Canvas element what makes possible to render any imaginable UI. Zebra development...

2013. április 26., péntek

Felvásárolta a Parse-t a Facebook


A Parse (https://www.parse.com/) segítségével tulajdonképpen a teljes szerver oldalt bérelheted az app-odhoz, ráadásul nem kell hozzá különösebb szakértelem a szerver oldali dolgok terén. Az viszont meglepett, hogy a Facebook felvásárolta őket. Érdekes az irány, amerre terjeszkedni próbálnak. Lehet, hogy van valami átfogóbb koncepciójuk, és hosszú távon amolyan mobil közösségi alkalmazás platformmá akarnak válni (ahogyan a weben már most is azok). Erre utal az a hír is, hogy nemrégiben felvásárolták a Spaceport (http://spaceport.io/) fejlesztő gárdájának egy részét. Az ő megoldásukkal tulajdonképpen Flash (ActionScript) app-okból generálhatunk natív mobil alkalmazásokat. Ebből azért már nagyjából össze is lehet rakni egy teljes mobilos cross-platform alkalmazás platformot, ahol ActionScript-ben viszonylag könnyen, különösebb fejlesztői tapasztalat nélkül rakhatunk össze mobil Facebook app-okat. Adott a Facebook integráció, és a bérelhető szerver oldal, ami elintézi nekünk az adatok tárolását, a terheléselosztást, az esetleges mobil fizetést, stb. Ráadásul az egész rögtön elérhető Androidra, és iOS-re (gondolom nemsokára WinPhone is támogatott lesz) is. Úgy gondolom, ez nem egy rossz irány. Persze ez csak az én tippem ...  

#blog  

http://www.hwsw.hu/hirek/50179/facebook-parse-kozossegi-web-cloud-fejlesztes.html





Saját felhős mobilapp-backendet vett a Facebook
Saját felhős backendet vásárolt mobilos és keresztplatformos alkalmazásokhoz a Facebook. A vállalat tegnap bejelentette a Parse megszerzését, amely beolvad a Facebook Platformba.

2013. április 24., szerda

Tabris


Egy érdekes "öszvér" technológia kliens-szerver alkalmazások készítésére.  szerver oldalt Java-ban készíthetjük el, mint bármilyen webes Java framework esetén, viszont a kliens oldal nem egy böngésző, hanem egy natív alkalmazás, ami a szerver oldali történések alapján generálgatja/módosítgatja az UI-t. Tehát olyan mint bármelyik standard HTML alapú megoldás, csak a HTML-t egy sqját natív, SWT alapú réteggel helyettesítették. Így egyszerre van meg a natív alkalmazások és a webes alkalmazások minden előnye (és mondjuk hátránya is).

#blog  

http://eclipsesource.com/tabris/


Embedded Link


Tabris Mobile Framework
Meet Tabris. The first Java-Toolkit for cross-platform development of native mobile apps. Scroll Down. Native Experience. Single Codebase. Write your apps in Java; Have users enjoy platform-specific c...

2013. április 18., csütörtök

myBatis


A myBatist (https://code.google.com/p/mybatis/) egy barátom ajánlotta. Ez egy SQL mapping framework Java-ban. Azok számára lehet hasznos, akiknek már tele a hócipője a Hibernate-el, és a többi Java-s ORM frameworkkel. Az a gond ezekkel általában, hogy elsőre minden szép és jó, összerak az ember egy objektum hierarchiát, a rendszer pedig a háttérben elintéz mindent. A gond akkor jön elő, mikor bonyolultabb lekérdezéseket szeretne megvalósítani az ember, és beleütközik az ORM rendszer saját lekérdezőnyelvnek korlátaiba, vagy épp azt látja a logban, hogy a generált SQL messze nem optimális, feleszik a memóriát a proxy-k, és hasonló nyalánkságok. Ezzel szemben a myBatis célzottan nem a háttérben végzi a dolgokat. Kézzel megírt SQL kifejezésekkel végezhetjük a lekérdezéseket, módosításokat, és ezeket képezhetjük le, objektumokká, majd onnan vissza. Így megmarad a teljes kontroll az adatbázis felett, optimális lekérdezéseket végezhetünk, és a célnak jobban megfelelő adatmodellt építhetünk, hiszen az nem közvetlenül kötődik az adatbázishoz.

Köszi a tippet +Lóránd Somogyi -nak.

/cc +Richárd Kovács 

#blog     

http://www.ibm.com/developerworks/java/library/os-ibatis3/index.html





What's new in iBATIS 3
iBATIS is a project used primarily for data access object (DAO) and object-relational mapping (ORM). You can use it to easily work with Java objects and databases. The update for iBATIS 3 beta 9 was p...

2013. április 12., péntek

Xtend JSON


Készítettem egy pár soros Xtend libet, amivel könnyebben lehet Java-ból JSON fájlokat kezelni. Kb. olyan szinten, mint mondjuk JavaScript-ből. De a nehézkes JSONObject-hez képest bizonyosan egyszerűbb.

Pár példa (az ember nem is gondolná, hogy ez kiterjesztett Java kód):

var jo = new JSONObject(#{'users' -> #[
    #{'name' -> 'xxx', 'address' -> 'yyy'},
    #{'name' -> 'aaa', 'address' -> 'bbb'}    
]});
println(jo);

jo >> 'users' <<< #{'name' -> 'foo', 'address' -> 'bar'};
println(jo);

(jo >> 'users').forEach[
    println('name: ' + (it >>> 'name') + ' address: ' + (it >>> 'address'));
];

println(jo >> 'users' >> 1);

jo >> 'users' >> 1 <<< #{'name' -> 'fff', 'address' -> 'ggg'};
println(jo);

https://github.com/TheBojda/xtend_json

#blog





xtend_json
xtend_json - Simple Xtend JSON Extension

A Prezi mint munkahely


Jópofa amit a srácok csinálnak. Az a baj, hogy Magyarországon azért ezt nem engedheti meg mindenki magának. Én valahogy úgy szervezném ezt, hogy lenne egy ilyen nagy innovatív tér, amit egy külső cég üzemeltet. Ugyanilyen kis kukszlikkal, ingyen kajával, meg minden, és a startupok valamilyen /fő havidíjért ezt bérelnék többen, és ide járkálnának be a dolgozók. Így akár egy 5 fős kis startup is ilyen munkakörnyezetet teremthetne magának. És sok ilyen kis 5 fős startup szponzorálná az egész helyet. Sőt, én igazából szabadúszókkal dolgoztatnék, és azt sem kötném ki, hogy bejárjanak az emberek. Akkor dolgoznának, és onnan, ahonnan akarnak. Esetleg meetingre érdemes őket fixen összehívni, de szabadon járhatnak kelhetnek, ha akarnak, otthon maradhatnak, kommunikálhatnak online és offline is. A lényeg, hogy menjenek a dolgok, tartsák a határidőket, pörögjenek a koncepciók, és menjen a cég. A legtöbben úgyis bent lógnának egész nap (>8 órában), mert jó a kaja, jó a társaság, és amúgy is egy nagy játszótér az egész.   

http://index.hu/video/2013/04/12/prezi/

#blog  





Ötletszexszel versenyeznek a Google-lel
Egy magyar garázscégből olyan nemzetközi vállalat lett, hogy külföldiek költöznek miatta ide. A Preziben nincs munkaidő, de van saját kultcentrum, séf és külföldi befektető. Megnéztük az új, Google-ös...

2013. április 8., hétfő

Írtam DalvikVM-et Java-ban. :)


Egyelőre csak kísérleti dologról van szó. Pár utasítást programoztam csak le, de már fut rajta a Hello World. Arra voltam kíváncsi, mennyire bonyás összerakni egy ilyen VM-et. Elsőre elég hülye dolognak hangzik Java VM-et írni Java-ban (ráadásul interpretert), de szerintem nem feltétlenül az. Onnan jött az ötlet, hogy mobilra fejleszteni mennyivel macerásabb, mint webre. Egy PHP szkriptet, vagy egy JavaScriptet csak úgy átír az ember, refresh, és már lehet is próbálni. Ezzel szemben egy Android app-ot újra kell forgatni, újra kell telepíteni minden változtatás után, ha ki akarjuk próbálni telefonon. Erre jött az ötlet, hogy kellene írni egy VM-et, ahol szabadon össze vissza cserélheti az ember a kódot futás közben (még ha sokkal lassabb is minden), és a végén leforgatja az egészet. A késztől még nagyon messze van az egész. Sőt, jó eséllyel nem is lesz befejezve, ahogy magamat ismerem, de azért jópofa. :) 

#blog  

2013. április 4., csütörtök

Xtend


Egy Eclipse által fejlesztett új programozási nyelv, amit szerényen csak "better java"-ként minősítenek. Elsőre átsiklottam rajta, de tüzetesebben átnézve a doksit valóban nagyon jó kis eszköz. Olyasmiket tud, mint opcionális típushasználat, kompaktabb deklarációk, objektumok dinamikus kiterjesztése, stb. Tulajdonképpen ami hirtelen eszembe jutott, hogy nem szeretem a Java-ban, arra találtam benne megoldást, de ha valami újat szeretnénk, ki is lehet terjeszteni a fordítót. Ami azonban a legjobban tetszik benne, hogy nem bájtkódot, hanem Java kódot fordít, így később jól lehet debugolni, ha kell, bármilyen környezetben. Így például Androidra is fejleszthetünk vele.

+Lóránd Somogyi +Richárd Kovács nektek tetszeni fog szerintem. 

http://www.eclipse.org/xtend/

#blog  





Xtend - Modernized Java
Xtend is a statically typed programming language sitting on top of Java.

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