en in macland

A változatos és igényes iphone app kínálatot elnézve, kedvem lett egy kis app elkészítésére, terepfelmérés céljából. Persze az apple fanatikusoknak gyárt nem ügyfeleknek, úh pár nap folyamatos szívás után azon ponton vagyok, hogy feladjam. De ne ugorjunk a végére.
Kezdődött azzal, hogy elmentem letölteni az iphone sdk-t, kezdjük a kályhától ugye, node ahhoz először regisztrált developernek kell lenni. Ok, legyen, mit számít az a név, email, postai cím és telefonszám, végülis egymás között vagyunk (plusz 10 millió hacker), szívesen, miért ne. Ez kb. 20 perc mert a spamnyelő freemailes fiókomba érkező konfirmáció sem siette el. És ekkor derül ki, hogy hülye aki iphone softwert nem osx alól akar fejleszteni, cél a világuralom ugye, nem érdekes hogy alig használják. A bemutató videók is csak itunesszal akartak elindulni, amihez pár éve volt szerencsém, úh no, thanks.
Rendben, plan B: vmware. Viszonylag gyorsan sikerült egy 30 napis trialt összevadászni és két installt is betolni a torrent feedbe, az egyik egy amds hack, a másik kifejezetten vmware image. Persze, az utóbbi jött sokkal lassabban úh az amdvel kezdtem. A kezdeti pár óra szívás, ami a nem megfelelő dvd/hdd vmware konfig miatt lehalások miatt voltak (a satat szereti amit nem tud a vmware, de scsi is megfelel, ha a hdd és dvd külön csatornán vannak, illetve az install dvdt nem a vmware mountolja, hanem a host oprendszerben futó külső progi pl a jól bevállt daemon tools), elindult az install. Korai volt az öröm, ugyanis úgy elhalt hogy még a daemon tools is kihalt tőle - reboot, ezt eljátszottuk párszor, aztán elmentem aludni, mikor vmi fórumon olvastam hogyhát az nvidias chipsetet nem túlságosan szereti (a dolog bája ugye hogy az amds chipsetek túlnyomó része nvidia).
Reggelre lejött a másik image is. Mount vmwarebe és boot. Itt megjelent egy alma logó, és szépen pörgette a kis vackot úgy 1.5 órán keresztül, mikor meguntam. vm->restart guest. Az azóta eltelt 1 óra után ugyanott tartunk.
A plan C egy inteles (sajnos nincs itthon core2) gép, amihez meglehet hogy egy harmadik install kell, vagy xp installal összekötött móka lesz a nasként használt inteles gép ideiglenes átszerelésével. i'm a mac. lol.

nerd stuff

Ha egyáltalán érdemes blogokat olvasni, akkor a Joelé ilyen. Mármint ha sw területen nyomul az ember. Kicsit szószátyár, kicsit beképzelt (európai szemmel mindenképpen), kicsit offtopic, ha az ember nem a small enterprise-win-web háromszögben mozog, de nagyonis ottvan néha. És ezekért érdemes elolvasni azt a fennmaradó 70%-ot is, ami ha nem is nagyon releváns, találni egy-két magvas gondolatot bennük.

Rövid történelem: pár Microsoftnál eltöltött év után saját céget alapított, és grafomániáját a blog illetve mindenféle könyv kiadásában éli ki. Az írások nagy része elérhető a weben is, és azt is érdemes tudni, hogy a könyvei nagy része ezekből készült (talán van kivétel).

A megírás alatt lévő Great Design c. könyve is a követni érdemesek közé tartozik, figyeljünk oda rá néha.

collation

Adva van egy egyszeű feladat: két stringet kell összehasonlítani. Régebben ugye a még nem ennyire globalizált világban ennyi volt:
int str_comp(const char* str1, const char* str2)
{
while(*str1 && *str2)
if(*str1++ != *str2++)
break;
return *str1 < *str2 ? -1 : (*str2 < *str1 ? 1 : 0);
}

Ha még ennél is hatékonyabbat akartunk, akkor ott volt az assembly, valami ehhez hasonló: repnz cmpsb, s aztán a végén je, jl, jg. Még igényesebbek persze nem szarakodtak byteonként, ha ismert volt a stringek hossza, hanem cmpsb/cmpsw-vel a duplaszóhatárig hasonlítottak, aztán onnan repnz cmpsd. Természetesen a cmpsb is sokkal gyorsabb az utóbbinál ha nem ismertek a hosszak, ugyanis nem érdemes megszámolni, túl időigényes.
Aztán változtak a dolgok, és nem lett sikk gyors kódot írni, mindenki a különböző class libraryk stringosztályait használta, ami végülis az assembly nyelvű string comparehez nyúlt le előbb-utóbb, végülis majdnem olyan gyors kódot eredményezve mintha mi írtuk volna az összehasonlítást, ellenben sokkal kényelmesebb.
Aztán a fokozódóan globalizálódó világban egyre inkább szükség volt lokalizációra, ebből születtek a kódlapok, majd a unicode. Naaztán ezzel végetért az asszembly vagy az általunk összehekkelt stringcomparálás és muszály volt a nyelv/class library által adott lehetőségekre támaszkodni.
Ezzel szívtunk ma. Mostmár collationnek hívják az összehasonlítást, és a lényege az, hogy a sorrendet táblázatokból veszi, amelyek minden nyelvhez és localehez egyediek (is) lehetnek, de akár egymásét is használhatják. Ezeknek a rendszereknek az a hasznos tulajdonságuk, hogy nem feltétlenül az aktuális locale szerint kell mindent összehasonlítanunk, hanem meg is adhatjuk, h pl mi magyar rendezést szeretnénk, és akkor az lesz, függetlenül a user kínai localejától. Elméletileg csak, ugyanis az általunk használni akart localet támogatnia kell az oprendszernek is, nem elég ha a nyelv, framework támogatja.
Nos, a Symbian külön világ. A dolgok addig szépen mennek amíg nem akarsz semmi extrát, csak a kis stringjeidet összeengedni, aztán győzzön a nagyobbik, de ha te meg is akarod adni, hogy milyen locale szerint, akkor két lehetőséged van. Mindkettő vérrel és verejtékkel szennyezett: megadhatsz egy általad felépített localet, ahol minden olyan, ahogy te szeretnéd, vagy lekérdezed a rendszer által támogatottakat és azokból a kedvedrevalót használod. Gondolom mostmár sejtitek mi fog következni: az első a mazochistáknak van, akik minden támogatott nyelvre le akarják bütykölni a 100k-s collation táblát. A második már felhasználóbarátabb, tök helyes kis metódus: CollationMethodByIndex() vagy CollationMethodById(), amikkel le lehet kérni valamely metódust. Azonban 2 órás source és helptúrás után sem sikerült rájönni, hogy az ily módon megkapott metódusok milyen nyelvhez tartoznak. Sőt, amikor már egy K nevű class után túrtuk a filesystemet, de csak KK-t találtunk, kevés kevés mentette meg a monitorom. Aztán meglett a K is, de semmivel sem vitte előre a kis invesztigációnkat. Mert egy függvénytömb és egy count volt benne :((
Második felvonás holnap, most megyek inni.