HTC Hero

Ő lett az áldozatom, most vizsgaidőszak van, de írok majd egy bejegyzést róla, most, hogy már kb. 1 hónapja gyűröm :)

Jézus Krisztus él!

Boldog Pünkösdi Ünnepeket!

"Egy nap megkérdi apját a fia: "Apu, részt vennél velem a maratonon?" Az apa szívbeteg, de mégis igennel válaszol.... és így közösen elhatározták, hogy beneveznek a maratonra...
Nem sokkal később kérdi a fia az apját: "Apu, mit gondolsz jelentkezhetünk az Ironman-ra?"
Az apa igennel felelt.."igen,......de ez a legnehezebb triatlon a világon, melyet évente Hawaii-n rendeznek, ahol a versenyzőknek 3,86 km-t kell úszni, 180,2 km-t kerékpározni, 43,19 km-t futni a szigeten keresztül.."
Apa és fia egy testté váltak, hogy részt vehessenek a versenyen... most pedig nézd meg a filmet.......

http://www.youtube.com/watch?v=VJMbk9dtpdY

I CAN do all things through.
Him who strengthens me.

Mindenre van erőm Krisztusban
Aki engem megerősít.

GXT + ViewPort. Biztos ez kell nekem?

A minap elkezdtem azon gondolkozni, hogy jó úton halad-e a jelenleg garázs-módba tett wiki projektem. Biztos, hogy úgy kell neki állnom, ahogy elkezdtem?

Adott egy böngésző -> benne a content. Jelenleg a root widgetem egy Viewport ami illeszkedik a belső méretre, tehát tulajdonképpen egy alkalmazás. De egy wiki-nek biztos erről kell, hogy szóljon a dolog? Szerinten nem.

A külső csak egy kis fűszer a wiki tartalom mellett, nem szabad, hogy nagyon erre menjen rá a játék. Sok hű-hó a semmiért...

Tehát, amin gondolkozom, hogy az alap oldal az simán HTML-ből épüljön fel. És csak kicsi interakciók legyenek közben. Természetesen legyen layout, ami szépen modulárisan van felépítve. Könnyen lehessen lépkedni a view-k között, de ne erre menjen ki a játék és az erőforrások 90%-a.

Tehát most egy ideig tervezői állásba vonul a projekt és neki látunk majd kicsit később, újult erővel.

iPhone 3G vagy T-Mobile G1?

A két címszereplő közül lenne érdemes választani (tekintve a platformokat), de sajnos nem lehet, még nincs itt az ideje.

Az Apple terméke szép és jó, ahogy azt megszoktuk, nagyon csinos. DE:

• Zárt platform, csak az Apple-ös srácok fejleszthetik
• Nem elég szoros integráció az általam mélyen tisztelt Google-termékekkel (nem csoda)
• Fejlesztés Objective-C-ben történik, nekem jobban tetszik az Android megoldása: Java és tökös API-ek.

A G1-nek is vannak jó oldalai, de a rosszak:

• HTC a gyártó: nem hiszem, hogy hosszú távon jól bírja a ki-be nyitogatást
• Túl vastag a kütyü
• Maga a platform jó úton halad, de vannak még benne hiányosságok, de mivel nyílt, nem hiszem, hogy sokáig tart majd ezeket befoltozni (pl.: maga a rendszer is kezelje az elforgatást, és ne csak a billentyűzet kinyitásánál váltson landscape-re)

A pozitívumokat nem emelem ki, mert azokból elég sok van, és a jó nem ronthatja el a választást :)

Szerintem: az Android platformban van a jövő, de várni kell a többi gyártóra, akik szintén benne vannak az Open Handset Alliance-ben, mert a G1 nem igazán nyerő mint hardware.

Google Code: Mercurial támogatás

Ahogy már biztos olvashattátok, a Google Code támogatja a Mercurialt (Hg) a Subversion mellett.

Egyenlőre csak projekt alapon kaphatnak az emberek meghívást a tesztelésre, vagy jelentkezni lehet itt. Főleg olyan projekteket keresnek, ahol 2-nél több fő fejlesztő. Többekben felmerülhet a kérdés, hogy miért a Mercurialt támogatják a Git, vagy esetleg a Bazaar helyett? Ennek két fő oka van:

1. Nagyon hasonló a parancs-rendszere az SVN rendszeréhez, így a meglévő Subversion fejlesztők könnyebben át tudnak állni Hg-ra. Illetve elég jó frontendek vannak hozzá (pl. Tortoise Hg)
2. A Google Code rendszere HTTP-alapú szolgáltatásokra lett építve, és ezt a Mercurial tudja a legjobban kihasználva (tekintve a protokollját és a teljesítmény karakterisztikáját)

A srácok analízisét ezzel kapcsolatban megtekinthetitek itt. Az összefoglalás:

• Implementációt tekintve a könnyedsége miatt Mercurial a nyerő és nagy előny, hogy hatékony a HTTP protokollja.
• Szolgáltatásokban jobb a Git, de ezzel bonyolultabbá válik a használata is.

Ahogy a Subversion implementáció, így a Mercurialé is a Bigtable-re épül. Valószínű, hogy majd rá fogok nézni a Hg-ra is, ha nyílt lesz mindenki számára a használata a Google Code-on (nem kizárt, hogy akkor majd a wiki, ha már lesz olyan állapotban, akkor a Google Code-on lesz hostolva a forráskód, Hg-ban) Az eredeti bejegyzést elolvashatjátok itt.

GAE/J és full-text search/index

Ahogy közeledek a tényleges használathoz (mármint a GAE/J-t tekintve), megint találtam egy komolyabb hiányosságot: a GAE for Java nem támogatja natívan a full-text search-öt. Ti mit szóltok ehhez?

Max. 500 karakter hosszú Stringet lehet tárolni a datastoreban, ha ennél több kell, akkor azt már mint Text tudjuk eltárolni, de ezt nem indexeli... Szóval akkor mit lehet tenni?

1. Várunk, míg támogatást kapunk erre a Googletől (ki tudja, ez mikor következik be)
2. Megpróbálkozunk ezzel: http://www.kimchy.org/searchable-google-appengine-with-compass/
   
   A hozzászólások közt van 1-2 érdekes dolog, hogy vajon ez meddig megy, mennyire skálázható, hány entitásnál dobja el magát (ahol már túl sok erőforrás kell az indexeléshez - CPU, read/write stb.)

Valószínűleg a 2)-vel fogok megpróbálkozni, aztán meglátjuk, hogy bírja a témát.
Az is lehet, hogy ha ez nem opció, akkor maradunk a címkéknél, és amíg nem lesz beépített támogatás erre (ami azért a Googletől furcsa, hogy pont a keresés nem megy úgy ahogy kéne :D), addig csak címkék segítségével lehet majd hatékonyan keresni.

Google App Engine és a "Key"

Mi nap, úgy néz ki, hogy befejeztem az app engines alkalmazásom alap UI-át, meg eljátszottam a nemrég megírt XML-to-UI progimmal és hát akkor elkezdtem csinálni a wiki rendszer sava-borsát...

Ugye nem árulok zsákbamacskát, ha elárulom, hogy szükségem lesz a Datastore API-ra, hiszen nyilván szeretnénk adatokat megőrizni, pl. magukat a wiki oldalakat.

Fater a minap mesélt az UUID-ről (végre tudom mik azokat a csúnya GUID-k a Visual Studio projektfájljaiban) és gondoltuk, hogy szuper lenne ez a wiki rendszerben is. Több előny is van (teljesség igénye nélkül):

• Az alkalmazás generálja magának az ID-t, nem pedig az adatbázistól kérjük le, ez eléggé hasznos tud lenni, illetve alkalom adtán megspórolunk egy lekérdezést
• Ha netalán-tán export-importra lesz szükség (miért ne lenne? egy kis backup?), akkor nem kell tökölni az ID-kkal, hogy most a két adatbázis különbözik, mi legyen, hogy legyen, minden kapcsolatot egyeztetni... Egy az egyben mehet az import. Kicsi az esélye a konfliktusnak.

Nah igen, és ezt hogy tehetnénk be Google App Engine alá? Gondoltam magamban, nagyon egyszerű: generálunk egy java.util.UUID-t és ennek a String reprezentációját eltárolom, mint elsődleges kulcs.

Itt jött a bukta. A Google App Engine nem engedi olyan String-ek kulcsként való használatát, ami számmal keződik, vagy 2 darab aláhúzás karakterrel kezdődik és végződik (__*__). Hogy miért? Ne kérdezzétek, nem értem. A Python SDK-nál volt erről valami kis bejegyzés:

A key_name is stored as a Unicode string (with str values converted as ASCII text). A key_name must not start with a number, and must not be of the form __*__ (start and end with two underscores). If your application uses user-submitted data as datastore entity key names (such as an email address), the application should sanitize the value first, such as by prefixing it with a known string, to meet these requirements.

De nekem ez nem elég magyarázat. Java SDK doksija egy szóval nem is említi ezt a tényt. Mindenestre beküldtem, mint bugot és várom a magyarázatot, hogy ez miért van. Ha van valódik oka ennek, akkor nem lenne gond, de nekem ezzel miért kell fogalkoznom? Csinálja meg helyettem GAE...

To be continued...