Az OS X előtelepítve tartalmazza a Ruby-t, de sajnos csak egy régebbi 1.8-as verziót. Az újabb 3.2.0 verziószámú Rails keretrendszerhez már az 1.9.3-as Ruby-t javasolják a fejlesztők. A következő 4 parancs segítségével telepíthető a legfrissebb Ruby on Rails ha az Xcode 4.2 (vagy frissebb) van telepítve a rendszeren:
1 2 3 4 | |
Update
Sajnos a fenti módszerrel segfaultol a Rails az openssl és iconv miatt, ezért ezeket is telepíteni kell. A lépések száma ezzel 6-ra emelkedik:
1 2 3 4 5 6 | |
Nemrég érkezett meg az Amazontól a könyvolvasóm, egy Kindle Touch. Valamivel több mint egy hetes használat után itt az ideje, hogy összefoglaljam eddigi tapasztalataimat a termékről.
Pár éve iPadet használok, amin egy tucat könyvet elolvastam már. Ezt megelőzően, gyakran olvastam számítógépen is, de a papír alapú könyveket részesítettem előnyben. Mikor megtapasztaltam, hogy milyen kényelmes az elektronikus eszközön az olvasás, hamar rákaptam az ízére és ez teljesen átformálta az olvasási szokásaimat.
Soha nem éreztem fárasztónak az olvasást iPaden. Sokan hozzák fel ellenérvként, hogy a megvilágított kijelző mennyire fárasztó a szemnek. Nekem ellenben ez pont pozitívum volt, sötétben sem okozott problémát az olvasás. Egészen mással gyűlt meg a bajom, a fókuszálással. Nem fizikai, hanem mentális értelemben.
Ha leülök olvasni egy könyvet, annak ellenére, hogy maximálisan leköt az olvasmány, a gondolataim cikáznak. Eszembe jutnak dolgok, melyeknek hirtelen utána szeretnék nézni, vagy csak simán fel kell jegyeznem valamit ami bevillant és félek, hogy később elfelejtem. Ilyenkor pillanatok alatt a böngészőben találom magam, onnan pedig már kiszámíthatatlan, hogy mikor szabadulok. Az eredetileg tervezett olvasásnak itt vége szakad és azon veszem észre magam, hogy weboldalakat nézegetek, programkódot olvasok vagy épp e-mail írok és fogalmam sincs, hogy hogyan keveredtem ide.
Leggyakrabban munkával kapcsolatos dolgok viszik el a fókuszt, de mióta a Kindle-t használom olvasásra, azóta kevésbé szembesülök ezzel a problémával. Ez annak köszönhető, hogy a Kindle nem alkalmas böngészésre, vagy levelezésre, annak ellenére, hogy található benne egy kísérleti jellegű böngésző. Egyszerűen nem érzek kísértést, hogy taszkot váltsak. Amikor könyvolvasóval a kezemben jön a késztetés, hogy de jó lenne most gyorsan ránézni valamire a neten - de nincs a közelemben az iPad - akkor visszatérek az olvasáshoz. A másik dolog várhat, ha pedig elfelejteném, akkor nem is volt olyan fontos.
Pillanatnyilag csak az amerikai Amazontól rendelhető az általam kiszemelt Kindle Touch, 135 dolláros áron. Erre még jött mindenféle szállítási és vámkezelési díj, ami kb. 50 dollár körül mozgott. Kedden rendeltem meg a Kindle-t az Amazon oldaláról, ahol fel volt tüntetve, hogy előre láthatóan következő hét hétfőn érkezik majd meg. Teljesen korrekt szállítási határidő a tengeren túlról. Szerdán kaptam egy értesítést, hogy sajnos szállítási problémák miatt nem sikerült útnak indítani a csomagot, így a várható szállítási határidő hétfő helyett keddre módosulna. Minden további nélkül elállhatok a rendeléstől, ha az új határidő nem felelne meg. Már miért ne felelt volna?
Szerdán el is indult a csomag az USA-ból melyet az Amazon rendelések között, online lehetett követni és minden egyes mozgást percre pontosan rögzítettek. Csütörtökön már feltűnt Németország a listában. Gondoltam, hogy innen pillanatok alatt megérkezik Magyarországra, majd jön a vámkezelés, miegymás és keddre valóban kézhez vehetem a terméket. Még azon a héten pénteken csörgött a telefonom és a DHL futár hívott, hogy csomagot hozna, mikor jöhet. Kedden adtam le a rendelést, pénteken délben már a kezemben volt az új Kindle Touch. El sem akartam hinni.
Korábban nem láttam még E Ink kijelzőt, így nagyon kíváncsi voltam rá, hogy milyen lesz. A Kindle Touch első ránézésre kisebb, mint amilyenre számítottam, annak ellenére, hogy korábban pontosan utánanéztem, hogy milyen dimenziókkal rendelkezik az eszköz. Az iPad után nagyon picinek tűnt, de egy pár perc használat után ez az érzés teljesen elillant. Az E Ink kijelző bámulatos és valóban a papír alapú könyvek hangulatát idézi. Pont megfelelő méretű az eszköz pedig nagyon könnyű. Most tapasztaltam meg igazán, hogy az iPad kézben tartása egy hosszabb olvasmány során mennyire fárasztó, ha összevetem a Kindle Touch élménnyel. Ugyanez mondható el a háttérvilágítás, E Ink összevetéséről is. Tényleg sokkal kényelmesebb és natívabb élmény az e-könyv olvasó használata.
Azon vettem észre magam, hogy esténként szívesebben ülök le olvasni mint tettem azt korábban, bár ebben nyilván benne van az új eszköz iránti rajongás is. Az akku kapacitásáról még nem sokat tudok nyilatkozni. Tíz nappal ezelőtt töltöttem, amikor kézhez kaptam, azóta kb. 30%-ot merült. Ez a 30% szerintem nevezhető extrém igénybevételnek is, mert az első napokban indokolatlanul sokat nyomkodtam. A mindennapi, üzemszerű használat mellett szerintem nem lesz ekkora a fogyasztás.
Két negatívummal sikerült szembesülnöm a használat során. Nem olyan rettenetes probléma, de elég zavaró, hogy csak az eszközön lehet gyűjteményekbe szervezni a könyveket, mégpedig egyesével. A használatba vétel során találomra rátöltöttem úgy 30-40 könyvet, majd elkezdtem azokat a megfelelő gyűjteményekbe rendezni, hogy ne egy 4-5 oldalas listát kelljen lapozgatni (ami az E Ink kijelzővel nem túl gyors). Ezt azért nem tartom olyan nagy problémának, mert normális esetben úgysem töltögetek ilyen mennyiségű olvasnivalót az eszközre, csak a használatbavétel során.
Ennél sokkal zavaróbb a következő: a Kindle Touch ki/be kapcsoló gombja a kijelző alatt, az eszköz alján található, a lehető legrosszabb helyen. Az elmúlt napokban már többször is előfordult, hogy olvasás közben véletlenül megnyomtam az egyik ujjammal amivel alulról támasztom ki a Kindle-t, de olyan is volt, hogy olvasás közben áthelyeztem a combomra és ezzel a mozdulattal sikerült is kikapcsolnom. Érthetetlen, hogy miért pont ide tervezték ezt a gombot, egyáltalán nem logikus és még zavaró is.
A Readability-t használom ha belebotlok valamibe amit később el szeretnék olvasni, de épp nincs időm vagy kedvem, hogy nekiessek. Általában hosszabb blogbejegyzések vagy cikkek kerülnek ebbe a listába és épp a terjedelem nem teszi lehetővé, hogy rögtön elolvassam azokat. A Readability-nek van egy remek szolgáltatása Kindle tulajdonosoknak: a későbbi olvasásra megjelölt írásokat azonnal vagy napi rendszerességgel, magazinos formában át tudja küldeni a könyvolvasóra, ahol az alkalmas időpontban, kényelmesen hátradőlve lehet lapozgatni az olvasnivalót.
Korábban gyakran 15-20 bejegyzés is szerepelt a listámon, amit el szerettem volna olvasni. Mióta a Kindle-t használom ez a lista 0 és 5 közé redukálódott. Két-három naponta, esténként átfutom, hogy mit gyűjtöttem össze az elmúlt napokban és mindent elolvasok.
Az angol nyelvű könyvekből bőséges a kínálat mind az Amazon, mind az iBooks áruházában. A magyar nyelvű irodalomról ez sajnos egyáltalán nem mondható el. Egyszerűen nem tudom felfogni, hogy a magyar kiadók miért nem képesek előállni egy 21. századi megoldással. Örömmel költeném a pénzem magyar nyelvű e-könyvekre. Őszintén bízok benne, hogy meg fog változni a kiadók gondolkodásmódja a témában és nem az lesz amit a zenével csináltak.
Az imént futottam bele egy frissen megjelent alkalmazásba az App Store-ban, amely szerverek monitorozására alkalmas. Mivel magam is jelen vagyok az áruházban hasonló alkalmazással így gondoltam vetek rá egy pillantást, hogy lássam mivel rukkolt elő a konkurencia. A legnagyobb meglepetésemre ismerős kép fogadott és hirtelen azt gondoltam, hogy talán a saját alkalmazásom adatlapjára tévedtem :) Természetesen nem ez történt, az iCacti klónjába sikerült belefutnom.
Az, hogy a klón hasonló funkcionalitást kínál nem meglepő, hiszen az adatokat és a grafikonokat a Cacti szolgáltatja. Az viszont már sokkal meglepőbb, hogy milyen hasonlóságok fedezhetőek fel a megjelenésben. Ezért is nevezem klónnak, mert egyértelműen látszik, hogy az iCacti inspirálta a fejlesztőt a felület elkészítésekkor. Annak megítélését, hogy ez jól sikerült-e, már a vásárlókra bízom.
Három éve fejlesztem az alkalmazást. Az első verzió még csak iPhone-ra volt elérhető, az iPad-et akkor még be sem mutatták, majd folyamatosan bővült a támogatott Cacti verziók és funkciók köre, csakúgy mint a támogatott eszközöké: jött az iPad, a retina iPhone, majd nemrég a retina iPad is. Közben az alkalmazás magja teljesen újra lett írva és egy komolyabb ráncfelvarráson is átesett.
Az igazat megvallva vegyes érzések fogtak el amikor szembesültem a ténnyel, hogy próbálják másolni az alkalmazást. Az egyik oldalról bosszantó, hogy jön valaki és gátlástalanul felhasználja más munkáját, a másik oldalról ezt egyfajta groteszk elismerésnek tekintem.
Az elmúlt időszakban, egy új alkalmazás fejlesztése során, igyekeztem megismerni az iCloud technológiát fejlesztői szempontból. Célul tűztem ki, hogy az alkalmazás fájdalommentes szinkronizációt fog biztosítani az iOS-es eszközök és a Mac OS X között, erre pedig pillanatnyilag az iCloud tűnik a legjobb megoldásnak. Az alkalmazás egyetlen központi SQLite adatbázist használ az adatok megőrzésére. Ezt a felépítést az Apple library-style (vagy shoebox) névre keresztelte. Ezen kívül még további két iCloud adattárolási megoldás ismert: a dokumentum alapú, amit például a Pages és Numbers használ, illetve a key-value store, ami elsősorban alkalmazásbeállítások szinkronizálását biztosítja.
Az adatbázisok több eszköz között történő szinkronizálása több problémát is felvet. A tárolt adatoknak konzisztensnek kell maradnia. Ha az egyik eszközön hozzáadok egy új rekordot az adatbázishoz, annak a többi eszközön is meg kell jelennie, ha törlök egyet annak mindenhol törlődnie kell, ha pedig módosítás történik annak is ugyanúgy kell megjelennie minden eszközön. A változásoknak belátható időn belül kell átvándorolnia egyik helyről a másikra. Ez a sebesség szempontjából kritikus tényező. Egy több száz MB méretű adatbázis másolgatása a felhő és az eszközök között nem nevezhető hatékony és gyors megoldásnak és a konzisztencia szempontjából sem biztos, hogy tökéletesen kivitelezhető. Szinte biztosan elkerülhetetlen lenne az adatvesztés, ami valljuk be, nem megengedhető.
A fenti problémák kezelésére az Apple egy remek megoldást dolgozott ki a library-style alkalmazások számára. Minden egyes adatbázis tranzakció egy log állományban tárolódik az iCloud konténerben. Az alkalmazás - az egyes eszközökön - figyeli a konténer tartalmát, és ha érintetlen tranzakciós logot talál akkor azt feldolgozza. A konfliktuskezelésre - amikor azonos rekord egyidejűleg módosul több eszközön - azt az egyszerű, de nagyszerű megoldást találták ki, hogy mindig az utolsó módosítás a prioritásos és az kerül megőrzésre. Nem hozzuk döntési helyzetbe a felhasználót, nem abajgatjuk kérdésekkel, hogy akkor most melyik változatot szeretné megtartani. Az utolsó módosítás marad, aszt kész.
Az Apple mérnökei úgy álmodták meg az iCloud API-t, hogy a szinkronizálás beépítése az alkalmazásokba egyszerű és könnyen megvalósítható legyen. Ezt a célt szolgálja az előbb említett konfliktuskezelés is, ami nemcsak a felhasználó szempontjából előnyös, de a fejlesztőknek is kényelmes. Mindössze pár sor kódot kell beilleszteni az alkalmazásba ahhoz, hogy az iCloud adatcsere működésbe lépjen.
Igazság szerint a fejlesztőnek nincs is sok beleszólása a folyamatba, maximum annyi mozgástere van, hogy a tranzakciós logok számát és méretét befolyásolja a mentések gyakoriságával. Minden más automatikusan történik. Fejlesztőként nincs is lehetőség arra, hogy befolyásoljuk az adatcsere folyamatát és idejét, de még csak arra sem, hogy lekérdezzük annak állapotát. A program futása során mindez a háttérben, a színfalak mögött történik, mindössze egy nem túl rövid, de annál informatívabb nevű értesítés jelzi, ha történt valami változás a konténeren belül:
NSPersistentStoreDidImportUbiquitousContentChangesNotificationEzt a tényt nem fájlalnám annyira, ha a megoldás nem igényelne beavatkozást.
Sajnos a jelenlegi iCloud API több sebből is vérzik. Gyakran mutatnak eltérő állapotot az egyes eszközökön tárolt adatbázisok, és nem - vagy hibásan - dolgozzák fel a szükséges tranzakciókat, melyek a konzisztens állapotot elérését hivatottak leírni. Nem tisztázott, hogy mi történik ha egy alkalmazás menet közben kapcsolódik be a felhőbe és nem üres adatbázissal indul. Az sem egyértelmű, hogy a tranzakciós logok meddig tárolódnak a konténerben. Tapasztalatom szerint ezek az állományok gyakran sokkal több tárhelyet foglalnak mint maga az adatbázis, a feldolgozásuk pedig néha gyötrelmesen lassú és kiszámíthatatlan. Ez a felhasználói élményt óriási mértékben rontja.
Mint fejlesztő valamelyest tudom követni, hogy mi történik a program futtatása során. Ha az alkalmazás egy másik példányát, egy másik eszközön elindítom, akkor tudom, hogy kell egy rövid idő amíg az iCloud konténer helyi másolata összeszedi a módosításokat, feldolgozza a tranzakciókat, majd frissíti a felületet és megjeleníti az aktuális, frissített állapotot. Normális esetben erről a felhasználó semmit sem tud, ő csak azt szeretné ha olyan állapotban látná az adatait a telefonján ahogyan azt a laptopján hagyta. Ehhez pedig sok, időigényes folyamatnak kell lefutnia a háttérben, amelyről nincs semmilyen visszajelzés a felhasználói felületen. Megtévesztő.
A library-style alkalmazások felhősítésére vonatkozóan, sajnos rendkívül kevés, hiányos és pontatlan dokumentáció áll pillanatnyilag a fejlesztők rendelkezésére, a félig-meddig működő példaprogramok számát pedig egy kezemen meg tudnám számolni. Nagyon várom, hogy az elkövetkező időszakban bővüljön az elérhető fejlesztői dokumentációk részletessége és információtartalma. A technológia és az irány nagyon jó, de a részletekben bújik meg az ördög, ezen pedig bőven van még mit javítani. A magam részéről pillanatnyilag parkolópályán állok a témával kapcsolatban. Nem szeretnék hekkelős, idegesítő, csak félig működő megoldást szállítani, inkább türelmesen megvárom, hogy az Apple megmutassa a helyes irányt és pótolja azon hiányosságokat amelyek egy valóban jól működő implementációhoz szükségesek.
A mai nappal leszámoltam a WordPress blogmotorral és egy új megoldásra váltottam, az Octopress-re. A WordPressel már hosszabb ideje az volt a bajom, hogy utáltam bejegyzéseket szerkeszteni a beépített szerkesztőjében. Tökéletes mint tartalom kiszolgáló, de a szerkesztő rész mindig is távol állt tőlem. Az utóbbi időben már nem is használtam, offline írtam meg a bejegyzéseket, majd utólag töltöttem fel és szerkesztettem a megjelenést. Azonban iPad-ről ez meglehetősen nehézkesen ment, a szerkesztőben nehézkes volt a navigálás.
Már a blog életének korai szakaszában is volt egy kósza kísérletem arra, hogy HTML helyett valami kényelmesebb szintaxissal szerkesszem a bejegyzéseket. Az utóbbi időben rengeteg alkalmazás jelent meg mind iOS-re, mind desktopra melyek támogatják a Markdown szintaxist, és egyébként is kényelmes számomra ez a szerkesztési forma így végül az Octopress mellett tettem le a voksomat.
Az Octopress - azon túl, hogy megemészti a Markdown kifejezéseket - azért is tetszik, mert nem használ adatbázist a tartalom kiszolgálásához, hanem a beléje pakolt .markdown állományokat olvassa fel és generálja le belőle a statikus tartalmat. Ezáltal a kiszolgálás sebessége összemérhetetlen a dinamikusan renderelt tartalommal.
A blogmotor cseréjével egyúttal felhelyeztem a koronát azon korábbi törekvéseimre, melyek az egyszerűsítést célozták. Ennek eredményeként a hozzászólások és a sidebar-on elhelyezett photostream estek az áldozatául. A hozzászólások eddig sem töltöttek be komolyabb szerepet az oldal életében, a fotó folyam azonban szerves részét képezte az utóbbi időben tett erőfeszítéseimnek, ezért az egy külön menüpontot kapott, amely a Flickr photostream-re linkel.
A legutóbbi, WordPressben használt design már eléggé letisztult volt, mentes mindenféle zavaró elemtől. Az új megjelenés ezt az irányt viszi tovább. Mivel jellemzően szöveges tartalmat osztok meg, néhány képpel kiegészítve így a szöveges megjelenítés kapja a legnagyobb hangsúlyt. Itt lép a képbe egy másik szívemhez közel álló tulajdonság melyet az Octopress szolgáltat: a kódrészletek szerkesztése és megjelenítése egyszerű, ízléses és jól olvasható.