vbali

Key-value observing

2013-04-08T11:13:17+02:00

Minden Objective-C oktatási anyag már a kezdetek kezdetén tárgyalja a KVO témakört, amely szorosan kapcsolódik a KVC-hez:

Key-value coding is a mechanism for indirectly accessing an object’s attributes and relationships using string identifiers. It underpins or is related to several mechanisms and technologies special to Cocoa programming, among them Core Data, application scriptability, the bindings technology, and the language feature of declared properties. (Scriptability and bindings are specific to Cocoa on OS X.) You can also use key-value coding to simplify your program code.

Az Observer pattern egy elég erőteljesen alkalmazott tervezési minta a Cocoa keretrendszerben. Amikor minden az elvártnak megfelelően működik, olyankor a KVO egy áldás, amely óriási terhet vesz le a fejlesztő válláról:

Key-value observing provides a mechanism that allows objects to be notified of changes to specific properties of other objects. It is particularly useful for communication between model and controller layers in an application. (In OS X, the controller layer binding technology relies heavily on key-value observing.)

Például: megváltozik az egyik objektum valamely tulajdonsága, amelyet az őt figyelő másik objektum észrevesz és ennek következtében frissíti valamely saját tulajdonságát. Ez utóbbit figyeli egy másik observer, amely mondjuk a UI megjelenítéséért felelős. Észreveszi, hogy változás történt a megfigyelt objektumban és frissíti a felületet. Külön kód megírása nélkül, automatikusan. Egy tulajdonság megváltozása értesíti a másik objektumot, amely értesít egy harmadikat stb. és végül a felhasználói felületen megjelenik a változás, mindenféle spagetti kód nélkül. Super simple!

Amikor azonban valami nem úgy működik ahogyan azt a fejlesztő szeretné, olyankor könnyen rémálommá válik az observer pattern használata, mert irtó nehéz nyomon követni, hogy pontosan mi történik a háttérben. Az objektumok üzengetnek egymásnak, ezáltal fel van építve egyfajta logikai riadólánc. Majd egyszer csak “eltörik” valami a kódban és nem frissül a felület, vagy nem az jelenik meg ami elvárt volna. Hol lehet a probléma? Sok fejfájást tud ez okozni, amikor már egy kicsit összetettebb az adatszerkezet.

A minap óriásit szívtam a fent említett példával. Kicsit változott egy adatszerkezet és valahol megszakadt a riadólánc. Egy bizonyos osztályban a KVO kifogástalanul működött, míg ennek a leszármazottjában valami rendellenesség lépett fel és a hozzá kapcsolódó felület nem reprezentálta a változásokat. Az NSKeyValueObserving protokollnak van egy osztálymetódusa, amely automatikusan regisztrál egy (vagy több) observert a paraméterben megadott tulajdonsághoz. Ha a megfigyelt tulajdonságok valamelyike változik, akkor azok automatikusan értesítést küldenek a változásról:

+ (NSSet *)keyPathsForValuesAffectingValueForKey:(NSString *)key

When an observer for the key is registered with an instance of the receiving class, key-value observing itself automatically observes all of the key paths for the same instance, and sends change notifications for the key to the observer when the value for any of those key paths changes.

Bár a megfelelő osztálymetódus létre volt hozva az osztály implementációjában, mégsem történt meg az automatikus KVO. Kis debuggolást követően kiderült, hogy a fent említett osztálymetódus eleve meg sem hívódik, így be sincs regisztrálva a megfelelő observer a tulajdonsághoz. De miért nem hívódik meg az osztálymetódus? Pár órás küzdelem után legyűrt a fáradtság és munkámat végezetlenül hagytam. Reggel ismét nekiültem, hogy kiderítsem a probléma okát. Átolvastam a kapcsolódó dokumentációt és pár percen belül kiszúrtam a nyilvánvalót, amely feketén fehéren le van írva a doksiban: When an observer for the key is registered with an instance of the receiving class …

OMG, egész egyszerűen nem volt regisztrált observer a UI frissítését végző osztályban az adott tulajdonsághoz, így az osztálymetódus meg sem hívódott, így az adott tulajdonság nem frissült automatikusan egy másik tulajdonság függvényében és így állt elő az anomália. A két soros javítás (observer regisztráció és felszabadítás) pár másodpercet vett igénybe és működik minden ahogy annak kell.

Erről beszéltem. Amikor minden az elvártnak megfelelően működik, akkor a KVO rengeteg időt és energiát spórol meg a fejlesztőnek, de az adatszerkezetek változásával ez könnyen megváltozhat, úgyhogy csak ésszel!

_MASReceipt

2013-04-05T09:39:05+02:00

A ReadKit kapcsán kicsit kutakodni kezdtem, hogy hogyan függetlenítették az App Store-tól a programot. Meglepő módon a binárist és minden egyéb, az alkalmazáshoz kapcsolódó állományt érintetlenül hagytak, mindössze egy könyvtárat (_MASReceipt) és annak tartalmát törölték ki az alkalmazáscsomagból.

Kipróbáltam, hogy mi történik az eredeti, MAS-ból letöltött alkalmazással, ha ezt a könyvtárat eltávolítom. Bár az áruházból letöltött alkalmazások DRM-mel védettek, ez csak a bináris módosíthatósága ellen véd. A könyvtár eltávolítását követően az alkalmazás probléma nélkül elindult bármelyik gépen. Kipróbáltam más csapatok által készített alkalmazásokkal a “trükköt”, ami néhány esetben működött, de a népszerűbb alkalmazások a módosítást követően nem voltak hajlandóak elindulni. Ebből sikerült levonnom azt a kézenfekvő következtetést, hogy a _MASReceipt-tel a fejlesztőnek kell kezdenie valamit. De mi is pontosan ez a _MASReceipt?

Amikor megvásárolunk egy alkalmazást az Store-ból, akkor a letöltési folyamat részeként az alkalmazáscsomagban létrejön a fent említett könyvtár egy receipt nevű állománnyal. Ez egy Apple által digitálisan aláírt állomány, amely az alkalmazásról (csomagazonosító, verziószám stb.), valamint a letöltő számítógépről (IOMACAddress) tartalmaz információkat. A receipt pontos leírását az ide vonatkozó Apple Developer cikk tartalmazza: Validating Mac App Store Receipts.

A lényeg, hogy a receipt ellenőrzése a fejlesztőre vár. Nincs arra vonatkozóan semmilyen előírás, hogy ezt az állományt ellenőrizni kell, de ha ezt mellőzzük, akkor a fent ismertetett egyszerű trükkel egyszerűen lehet függetleníteni az alkalmazást. Ha pedig beépítjük a megfelelő ellenőrzést, akkor a cracker ilyen módon oldja meg a problémát:

Akkor mégis mi lehet a megfelelő védelem? Egyszerű:

jó minőségű szoftvert kell írni,
megfelelően kell beárazni,
és meg kell hallgatni a felhasználókat.

Ha valaki nem akar, úgysem fog fizetni az alkalmazásért. A meglévő felhasználókra és a potenciális vásárlókra kell koncentrálni!

A két kalap

2013-04-04T17:27:06+02:00

Kevés dolog tud jobban zavarni a ”bűzlő kódnál”, pedig időnként együtt kell élni ezzel a kellemetlenséggel. Naponta szembesülök az újratervezés szükségességével amikor egy-egy új szolgáltatás megvalósításán dolgozok. Ebből kifolyólag gyakran esek abba a hibába, hogy nem tudom épp melyik kalapot viselem, az újratervezőét vagy a szolgáltatás bővítőét. Mivel a két tevékenység végzéséhez teljesen eltérő szabályokat kell alkalmazni, így egyáltalán nem mindegy, hogy épp melyik kalap van rajtunk.

Napok óta törtem a fejem, hogy hol olvastam erről a problémáról korábban, míg végül bevillant Martin Flower Refactoring című könyve:

Amikor szoftverfejlesztésre használjuk az újratervezést, két különböző tevékenység között osztjuk fel az időnket: a szolgáltatások bővítése és az újratervezés között. Amikor új szolgáltatásokat adunk a programhoz, nem változtatjuk meg a meglévő kódot, csak új lehetőségeket adunk hozzá. Előrehaladásunkat tesztek létrehozásával és működőképessé tételével mérhetjük. Amikor újratervezünk, akkor szándékosan nem veszünk fel új tevékenységeket, csak átépítjük a kódot. Nem készítünk új teszteket (kivéve ha egy korábban kihagyott esetet találunk), és csak akkor változtatunk meg egy tesztet, ha erre mindenképpen szükségünk van a felület megváltoztatásának kezelése érdekében.

A szoftver fejlesztése során valószínűleg gyakran kapjuk magunkat kalapcserén. Először megpróbálunk a kódhoz adni egy új szolgáltatást, és rájövünk, hogy ez sokkal egyszerűbb volna, ha más lenne a kód szerkezete. Tehát kalapot cserélünk, és egy ideig újratervezünk. Amikor a kódnak már jobb a szerkezete, kalapot cserélünk, és megírjuk az új szolgáltatást. Amint működőképes lesz, rájövünk, hogy túl bonyolultan kódoltunk, így ismét kalapot cserélünk, és újratervezünk. Mindez talán csak tíz percig tart, de fontos, hogy mindvégig tisztában legyünk vele, hogy éppen melyik kalapot viseljük.

Oké, mostantól tisztában vagyunk azzal, hogy ha kalapot váltunk akkor mindig észben tartjuk, hogy épp melyiket viseljük. Ám az újratervezés során mindig szembejön egy olyan korábban írt kódrészlet, amelyre - bár nem kapcsolódik közvetlenül az aktuális újratervezési folyamathoz, - mégiscsak ráférne egy kis átalakítás. Bár épp az újratervező kalapjában tevékenykedünk, mégsem tehetjük meg büntetlenül, hogy ész nélkül nekiesünk a szemünk elé kerülő összes problémás részletnek, ez ugyanis újabb virtuális kalapcserével járna, majd végül egy feneketlen rekurzióban találjuk magunkat. Tudom, ez elmondva egyszerűnek hangzik, a gyakorlatban nagyon nehéz ellenállni a kísértésnek.

Szerencsére az agilis fejlesztőknek minden problémára van egy alkalmazható szabálya, törvénye vagy javaslata:

Sose szakíts meg egy megszakítást

Kent Beck — Test-Driven Development

Adj ki korán, adj ki gyakran

2012-10-26T08:25:00+02:00

Az év elején elhatároztam, hogy nyilvántartást fogok vezetni a munkaidőmről. Egy egyszerű időnyilvántartó alkalmazásra volt szükségem amelyben nyilvántarthatom az elvégzett feladataimat és lekérdezhetem, hogy az egyes projektekkel illetve az egyes tevékenységekkel mennyi időt töltöttem ténylegesen és arányaiban. Nem feladatkezelőben és todo listában gondolkodtam, hisz olyanom már van ami jól bevált. Sokkal inkább egy olyan alkalmazást szerettem volna melyet a todo lista mellett, annak kiegészítéseként tudok használni és pontos képet ad arról, hogy milyen hatékony a munkavégzésem. Ezen túlmenően mindenképp egy natív Mac-es alkalmazás illeszkedett volna legjobban az elképzeléseimhez.

Hosszas keresgélést követően sem találtam megfelelő szoftvert. A legtöbb időnyilvántartó programmal az a baj, hogy az elszámolásra és a számlázásra megy rá. Ezzel semmi gond sincs, ha valakinek erre van szüksége, engem azonban sokkal jobban érdekelt, hogy az egyes projektjeimmel mennyi időt töltök és a munkaórák hogyan oszlanak meg az egyes projektek között. Ezt a gondolatmeneten tovább boncolgatva arra is kíváncsi voltam, hogy a munkaidő milyen tényleges tevékenységekkel telik és ezek a tevékenységek milyen arányt képviselnek napi, heti illetve havi bontásban. Mivel nem találtam ilyen megoldást, így szabad óráimban nekikezdtem a Durations alkalmazás tervezésének, majd a fejlesztésnek.

A projekt remek esettanulmányul szolgált. Egyrészt sikerült magam jobban belevetni a Cocoa mélységeibe, másrészt megtanultam, hogy amilyen korán csak lehet ki kell adni a szoftver első verzióját.

A programozók maximalisták, gyakran szélsőségesen. Hajlamosak egy megoldásra váró problémára sokkal több időt szentelni mint amennyit az ténylegesen megérdemel. Nem azért mert képtelenek az adott megoldással záros határidőn belül előrukkolni, inkább azért, mert nem találják az adott megoldást elég frappánsnak vagy letisztultnak, esetleg kicsit csúnya vagy bugos. Úgy gondolom, hogy ez így rendjén is van. Nincs azzal semmi gond, ha egy fejlesztő egészségesen törekszik a maximalizmusra, sokkal rosszabb ha valaki igénytelen a kódjára. Van azonban egy határ, melyet átlépve ez a törekvés már inkább hátráltató.

Van egy szoftverfejlesztési bölcselet, miszerint adjuk ki hamar, adjuk ki gyorsan. Ezen filozófia szerint adjuk ki a szoftver első verzióját amilyen hamar csak lehet, majd gyakran adjunk közre frissítéseket (az Apple jóváhagyási szokásait figyelembe véve ez akár problémás is lehet), s közben figyeljük a felhasználók visszajelzéseit. Ez az a filozófia melyet most, hogy a Durations hamarosan elérhetővé válik, sikerült magamévá tennem, tekintve, hogy az alkalmazás csaknem három hónapig porosodott, miközben olyan feature-ök hibáitól szenvedett, melyek nem is szerepeltek az eredeti célkitűzések között.

Mint említettem, a célkitűzés egy natív Mac-es alkalmazás elkészítése volt. Menet közben azonban felmerült, hogy milyen király lenne, ha a jövőben iPad-en és iPhone-on is lehetne mérni a munkaidőt, illetve riportálni. Ehhez azonban szükség lesz az adatok szinkronizálására, melyre a legkézenfekvőbb megoldás az iCloud. Bár nem első körös célkitűzés volt, mégis napokat öltem bele az iCloud szinkronizáció megvalósításába, amely végül nem váltotta be a hozzá fűzött reményeket. Mindez hónapokkal meghosszabbította az első kiadás elkészülését. Az iCloud szinkronizációhoz hasonlóan, eszméletlen mennyiségű időt fektettem a felület csiszolgatásába, csinosítására is. Bár a végeredménnyel elégedett vagyok és úgy gondolom, hogy az alkalmazás előnyére váltak ezek a finomítások, mégsem ez fogja meghatározni, hogy a szoftver sikeres lesz-e.

Szerencsére menet közben sikerült ráeszmélni, hogy rossz irányba halad a fejlesztés. Szükségem volt egy kis pihenőre, hogy ismét megtaláljam a fókuszt és a motivációt és megújult erővel folytassam a fejlesztést. Ebben a kis pihenőben készült el az iCacti for Mac. Mindössze az iOS-es feature set implementálása volt a cél, megfejelve a Mountain Lionban debütált Notification Center figyelmeztetésekkel. Ahogy Jason Fried mondja: Less is less.

A korai kiadásnak megvannak a maga előnyei és hátrányai, de ha mérlegre teszük ezeket az érveket, akkor nagy valószínűséggel a korai kiadás irányába billen a mérleg nyelve. Persze ez alól kivételt képeznek azok a speciális rendszerek, melyek emberéletekért felelősek: az orvosi műszerek szoftverei vagy például a légi közlekedést irányító rendszerek, de ezektől most tekintsünk el.

A Successful Software kellően kivesézte a témát. A lényeg:

A korai kiadás hátrányai

Szolgáltatások hiánya: felesleges azon rugózni, hogy a konkurencia szoftverében több olyan feature is van, melyet az enyém nem tartalmaz. Lehet, hogy a felhasználók nem is használják azt, vagy nincs akkora jelentősége, hogy hónapokra megakadályozza a kiadást.

Hírnév: a korai kiadás nem tesz rosszat a márkának? Természetesen egy rossz minőségű szoftverre nincs bocsánat. Nem a minőséget, hanem a funkciók számát kell alacsonyan tartani a kezdeti kiadásban. Előre meg kell határozni azt a minimális követelményt, amellyel a szoftver elstartolhat, miközben jól használható marad. A többi pedig jöhet majd a frissítésekkel.

Támogatási többletmunka: amint megjelennek a vásárlók, támogatást kell nyújtani a szoftverhez. Minél korábbi a kiadás, annál több dolgod lesz a támogatással.

Kiadási többletmunka: a frissítések kiadása rengeteg időt vesz igénybe, még akkor is ha a legtöbb részfeladat automatizálva van. Minél több szoftverfrissítés jelenik meg az alkalmazáshoz, annál több időt kell teszteléssel és honlapfrissítéssel tölteni.

A korai kiadás előnyei

Felhasználói visszajelzések: Minden termékbejelentés egy nagy kérdés. Ha sok a versenytárs, felmerül a kérdés, hogy a vásárlók számára mennyire lesz sikeres a termék a konkurenciával szemben. Ha nincs konkurencia előfordulhat, hogy nincs is piaca a terméknek. Az is kérdéses, hogy a termék mely tulajdonságait szeretik a vásárlók és mennyit hajlandóak fizetni érte. A válaszokat a felhasználóktól lehet megtudni. Amint megjelennek a vásárlók, biztos lehetsz benne, hogy a tudtodra fogják hozni, hogy miben várnak előrelépést.

Motiváció: a valódi vásárlók nagyon jót tesznek a motivációnak. Remeteként fejleszteni hónapokig vagy évekig, mindenféle visszajelzés nélkül, könnyen alááshatja a motivációt és a termékbe vetett hitet.

Korai bukás: minden szakértelem és törekvés dacára sok termék megbukik. A te terméked lehet a következő. Ha pedig bukásra van ítélve, akkor ez történjen meg amilyen korán csak lehet, hogy minél hamarabb bele tudj kezdeni valami másba, valami újba.

Megtérülés: minél korábban kezdesz el értékesíteni annál korábban megtérül a befektetésed.

As a rule of thumb, I would say that if you aren’t embarrassed by the lack of features in v1.0, then you didn’t release it early enough.

Successful Software

Effective programming

2012-10-18T18:38:00+02:00

A héten fejeztem be Jeff Atwood blogkönyvének, az Effective Programming: More Than Writing Code olvasását, amelyre Orcsik Antal bejegyzése hívta fel a figyelmemet. Jeff a Coding Horror blog szerzője, a StackExchange alapítója és igazi hardcore programozó, akit remek írási készséggel is megáldott a sors. A könyv, amely tulajdonképp a Coding Horror blogon megjelent bejegyzések kivonata, egy igazán lebilincselő olvasmány, szinte le sem tudtam tenni. Azokra a mindennapos kérdésekre keresi a választ, amelyek minden programozót érintenek, kezdve a megfelelő eszközök kiválasztásától (billentyűzet, szék, világítás), a hatékony programozási munkán át, egészen a marketing tevékenységig. Mindezt könnyen emészthető és olvasmányos formában, mellőzve minden Happy Talk bullshitet.

Korábban Jason Fried és DHH Rework könyvétől vártam hasonló élményt, de annál sajnos teljesen elmaradt a tűzijáték. Kicsit unalmas volt és leginkább a klasszikus self-help könyvekre hajazott, kevés konkrétummal, sok lelkesítő beszéddel. Szóval nem igazán tetszett. Ezzel szemben az Effective Programming szórakoztató, mégis kellőképp szakmai olvasmány, izgalmas, színes témákkal, melyek Joel Spolsky régi klasszikusait juttatták eszembe.

Tenni vagy nem tenni

2012-10-06T12:42:00+02:00

Jeff Atwood írt a héten egy bejegyzést Todon’t címmel, hogy miért nincs szüksége todo listákra, valamint, hogy miért tartja azokat működésképtelennek. Van igazság abban amit említ, mégsem osztom a véleményét. Wyctim is beszélt múltkorában a Háztáji Geekben az általa tapasztalt GTD problémákról, és az ő véleményével sokkal inkább tudok azonosulni:

“a GTD-vel az a baj mikor az eszközzel foglalkozol és nem azzal, hogy mit kellene csinálni.”

A todo appokkal alapvetően az a baj, hogy azt a hamis üzenetet sugározzák, hogy mindenféle erőfeszítés nélkül megoldják az ember szervezési problémáit. Jómagam legalábbis beleestem ebbe a hibába. Sokáig hittem abban, hogy a GTD és a GTD appok olyan csodaszerek amelyek nem igényelnek extra időbefektetést és egycsapásra megoldják majd a napi feladatok szervezését. A GTD-t lehet jól és lehet rosszul csinálni és a hozzám hasonló fanatikusok könnyen áteshetnek a ló túloldalára, mivel egy eszköztől várjuk a megoldást. Könnyen bele lehet esni a mikromenedzsment csapdájába és olyan szinten elbonyolítani a rendszert, hogy az már inkább akadályozza, mint segíti a produktív munkavégzést.

Fel kell ismerni, hogy a GTD nem mindenható. Igenis igényel némi extra időbefektetést a feladatlisták karbantartása, de meg kell húzni a határt. Teljesen felesleges triviális infókkal teletömni a rendszert. Értelmetlen nyilvántartani azokat a feladatokat amelyek elvégzése nyilvánvaló és garantált, hogy nem felejtődnek el. A több éves tapasztalatból és a rengeteg hibából tanulva ma már odafigyelek arra, hogy semmilyen felesleges zaj ne kerüljön a rendszerembe. Hajlamos vagyok elfeledkezni dolgokról, de nagyon jól ismerem magam ahhoz, hogy egy adott input megérkezésekkor el tudjam azt dönteni, hogy el fogom-e felejteni vagy sem. Amit biztosan nem felejtek el azzal nem zajosítom a feladatlistámat, amit elfelejthetek az megy a sorba. Igyekszek nem elbonyolítani a nyilvántartást. Általános, perspektíva alapú címkézést és határidőket használok, illetve minimális számú projektbe csoportosítom ezeket. Próbálom tisztán tartani a rendszert. Rendszeresen átfutom a listákat és szigorúan kigyomlálom belőle az értelmetlen vagy értelmét vesztett információkat.

Vannak még a rendszeresen ismétlődő feladatok és események. Ezek adják a magját a GTD rendszeremnek, mert ezekről különösen hajlamos vagyok megfeledkezni. Minden ilyen ismétlődő tennivalóm a rendszer részét képezi és mivel az évek alatt már többször is bizonyított így tökéletesen megbízok benne.

Mára már megtanultam, hogy nem a GTD tesz produktívvá. Ugyanúgy az egyszerűségre és az átláthatóságra kell törekedni, mert az biztosítja a rendszer működését.

Végezetül Jeff Atwood tollából, akinek nincs szüksége todo listára:

At least four times a day, I walk into a room having no idea why I entered that room. I mean no idea whatsoever. It’s as if I have somehow been teleported into that room by an alien civilization. Sadly, the truth is much less thrilling. Here’s what happened: in the brief time it took for me to get up and move from point A to point B, I have totally forgetten whatever it was that motivated me to get up at all. Oh sure, I’ll rack my brain for a bit, trying to remember what I needed to do in that room. Sometimes I remember, sometimes I don’t. In the end, I usually end up making multiple trips back and forth, remembering something else I should have done while I was in that room after I’ve already left it.

Coding Horror We Are Typists First, Programmers Second

Smart App Banners

2012-09-20T22:40:00+02:00

Az iOS 6 egyik újdonsága eddig teljesen elkerülte a figyelmemet, nevezetesen a Smart App Banners. Ez a feature lehetővé teszi az alkalmazásfejlesztők számára, hogy a mobil Safarival érkező látogatók számára megjelenítsenek egy bannert az oldal tetején. A banner tartalmaz egy hivatkozást az alkalmazás App Store oldalára illetve megjeleníti annak ikonját, az értékelést és a képernyőképeket is. A megvalósítás igazán egyszerű, mindössze egy HTML meta taget kell beilleszteni az oldal fejlécébe amely az App ID-re hivatkozik, a bannert a Safari ebből állítja majd elő:

<meta name="apple-itunes-app" content="app-id=9999999" />

Ha az alkalmazás már telepítve van az adott eszközön akkor a bannerből közvetlenül el is indítható illetve paraméter is átadható a program számára az app-argument mezőben. Szükség esetén affiliate code is átadható az iTunes hivatkozásnak az affiliate-data mező megadásával:

<meta name="apple-itunes-app" content="app-id=9999999, app-argument=xxxxxx" />
<meta name="apple-itunes-app" content="app-id=9999999, affiliate-data=partnerId=99&siteID=XXXX" />

Twitter kontó

2012-09-20T20:27:00+02:00

2009-ben regisztráltam Twitterre, de akkor a megszokott nickkem már foglalt volt, ezért egy underscore karaktert biggyesztettem a nevem elé, így lettem @_vbali. Mindig is ~~zavart~~ frusztrált ez a plusz karakter, miközben a hőn áhított usernevemet foglaló felhasználó sosem használta a Twitter kontóját. Nem volt sem követője, sem tweetje és ez az évek alatt ez nem is változott. Éppen ezért felvettem a kapcsolatot a Twitter supporttal és kérvényeztem, hogy mivel a nickemet “bitorló” user passzív, adják át nekem a fiókot. A mai napon érkezett meg a visszajelzés, hogy szabad a pálya, enyém a fiók. Mától @vbali néven vagyok rezidens Twitteren.

Sublime Text 2 - Szódával elmegy

2012-08-20T17:20:00+02:00

Miután könnyes búcsút vettem a TextMate-től, hozzáfogtam a Sublime Text testreszabásához. A Sublime Package Control volt az első kiegészítés melyet telepítettem. Hasonlóan a Linux disztribúciókból ismert csomagkezelőkhöz, a Sublime Package Control segítséget nyújt az editorhoz elérhető csomagok telepítéséhez, frissítéséhez és szükség szerint azok eltávolításához is. Bár az ST2 alaptelepítése is tartalmaz egy tucat általános kiegészítést, mégis szinte elkerülhetetlen, hogy ezeket tovább bővítsük a saját igényeinknek megfelelően.

Szinkronizáció

Mivel több Mac-et is használok, ezért visszatérő a következő probléma. Az egyik gépen gyönyörűen testre szabom az editor beállításait, feltelepítem a szükséges csomagokat, majd azokat is beállítom a saját igényeimnek megfelelően. Valamivel később letelepszek a másik gép elé és akkor szembesülök vele, hogy egészen más beállításokkal fut az editor. Természetesen nincsenek meg a másik gépre installált csomagok és a beállítások is mutatnak eltéréseket. Hamar meguntam, hogy mindkét gépen el kelljen végeznem a telepítést és a beállítást, ezért az ST2 csomag könyvtárait átmozgattam Google Drive-ra és onnan symlinkeltem vissza azokat az eredeti helyükre:

  mv ~/Library/Application Support/Sublime Text 2/Installed Packages \
  ~/Library/Application Support/Sublime Text 2/Packages \
  ~/Library/Application Support/Sublime Text 2/Pristine Packages \
  ~/Google Drive/AppData/Sublime Text 2/

  ln -s ~/Google Drive/AppData/Sublime Text 2/Installed Packages \
  ~/Google Drive/AppData/Sublime Text 2/Packages \
  ~/Google Drive/AppData/Sublime Text 2/Pristine Packages \
  ~/Library/Application Support/Sublime Text 2/

A Settings mappát szándékosan nem mozgattam át, mert az olyan gépspecifikus beállításokat is tartalmazhat (például az előzményeket), amelyek gépek közötti mozgatása nem biztos, hogy előnyös. Mivel az editor beállításai a Packages/User mappában találhatóak, így a Packages mappa symlinkelésével nem csak a telepített csomagok szinkronizálódnak a gépek között, de a felhasználó beállításai is.

Soda Theme

A legnagyobb kritika amely bennem is megfogalmazódott a Sublime Text kapcsán, az a rendszeridegenség. Ez nyilvánvalóan a platformfüggetlenség hozadéka és sajnos több fronton is tetten érhető. Egyrészről felfedezhető a program működésében. Ilyen például a projekten belüli keresési eredmények megjelenítése vagy az állományok átnevezése. Ezek megvalósítása teljesen idegen az OS X-ben megszokott konvencióktól és tartós használat után sem megszokható. Együtt lehet ugyan élni a program ezen betegségeivel, de mindig zavaró marad.

A program másik problémája a megjelenés. Több olyan apró kis részlete is van a felhasználói felületnek amely csúnyácska vagy hiányos. Ezeken szerencsére többé-kevésbé lehet segíteni. Elérhető a Soda névre keresztelt UI téma, amely javítja a Sublime Text megjelenésének legtöbb problémáját és kifejezetten szépre varázsolja annak megjelenését (bár retina kijelzőn adódnak még apró problémák). A Soda light téma telepítése óta sokkal barátságosabbnak érzem a program megjelenését és sokkal szívesebben ülök le elé dolgozni.

Mappa ikonok megjelenítése

A megjelenésnek van egy másik problémája amelyen pillanatnyilag a Soda téma sem segít és csak egy csúnya hekkeléssel lehet azt orvosolni: a sidebar nem jelenít meg ikonokat az állományok és mappák mellett. Pillanatnyilag ezt tartom a Sublime Text 2 legnagyobb problémájának. Találtam egy csúnya megoldást, melynek segítségével a könyvtárak neve mellé be lehet varázsolni a megfelelő mappa ikonokat. Tényleg nagyon csúnya a megoldás, de a mindennapi használathoz sajnos szükségét éreztem a könyvtárikonok megjelenítésének. Sajnos a megfelelő mime ikonok megjelenítése továbbra sem megoldott.

Ezekben a dolgokban a TextMate fényévekkel előbbre jár, de nagyon bízok benne, hogy az ST2 következő frissítéseinek valamelyikében orvosolják majd az ikon problémát.

TextMate, egy korszak vége

2012-08-12T18:40:00+02:00

A hét egyik legmeglepőbb bejelentése volt, hogy nyílt forráskódú lett a TextMate. A készítő, Allan Odgaard GPL 3 licensz alatt a teljes forráskódot elérhetővé tette GitHub-on. Régi nagy rajongója voltam az editornak, amely egyike volt azon kevés programnak amelyeket folyamatosan használtam azóta, hogy áttértem Mac-re. Az idők során többször is megrendült a továbbfejlesztésbe vetett hitem. Többször hangot is adtam eme elégedetlenségemnek. A TextMate egyfajta standard volt a maga súlycsoportjában és talán az okozta a legnagyobb problémát, hogy a maga nemében túl tökéletes volt és kevés perspektívát biztosított a továbbfejlesztéshez. Ezt a következtetést sikerült levonnom Allan korábbi és a friss bejelentés kapcsán megjelent nyilatkozataiból.

Marco Arment tökéletesen összefoglalta a TextMate lehetséges jövőjét illetve a pillanatnyi alternatív lehetőségeket, amelyből kiemelném a következő gondolatot:

I’ve now chosen my TextMate replacement, but before I reveal it, let me give a huge disclaimer: You will have your own opinion. It’s probably safer to talk about Jesus, gun control, Israel, global warming, parenting techniques, regional pizza styles, Linux distributions, why I don’t like cats, or my favorite PHP features.

Nagyjából hasonló lehetőségeket vizsgáltam meg amelyeken Marco is végigment. Korábban, aktív Linux felhasználóként a Vim volt az alapértelmezett szövegeditorom. Ez amolyan geek dolog és csak azok érthetik meg a Vim iránti szerelmemet akik megtapasztalták a benne rejlő lehetőségeket.

Egyszer, még a legelső munkahelyemen beleütköztünk egy problémába ami abból adódott, hogy két rendszer között kellett adatokat cserélni. A lehetőségeink elég korlátozottak voltak, az egyik program képes volt fájl exportra, a másik program pedig fájl importra, de még véletlenül sem beszéltek azonos nyelvet. Az export állomány formátuma sajnos nem felelt meg annak a programnak amelybe szerettük volna beolvasni az állományt, így természetesen konverzióra volt szükség. Mint említettem, akkoriban a Vim volt az alapértelmezett editorom és abban nyitogattam meg a különböző állományokat és vizsgálgattam azok tartalmát és alakítgattam azokat, hogy sikeresen lemenjen a beolvasás. A végeredmény egy komplett Vim szkriptben öltött testet, amely az exportált állományt automatikusan átalakította és előkészítette a másik programban történő importálásra. Eseti jellegű problémáról volt szó, így nem merült fel annak a gondolata, hogy általános és felhasználóbarát megoldást dolgozzunk ki. Végül a tervekkel ellentétben éveken keresztül, havi rendszerességgel kellett ehhez a kis Vim szkripthez folyamodnunk segítségért és az évek alatt tökéletesen ellátta a rá bízott feladatot. Persze ez csak egy kiragadott példa amely magyarázatot ad a Vim iránti rajongásomra.

OS X-en mindig is túlságosan rendszeridegennek éreztem a Vim-et így ott a kezdetektől fogva a TextMate-et használtam, kivéve a konzolt és a távoli szervereket, ahol a mai napig a Vim a default editorom. Természetesen az elmúlt években – főleg mikor kilátástalannak tűnt a TextMate jövője – voltak kísérleteim más népszerű és kevésbé népszerű szerkesztőkkel, név szerint: MacVim, BBEdit, Sublime Text, TextWrangler. A Sublime Text 2 volt az amely időről-időre visszaköszönt, de mindig felszínre tört egy megmagyarázhatatlan érzés amely elriasztott a tartósabb használattól. Talán csak a váltástól való félelem okozta ezt az érzést, elvégre a TextMate az évek alatt kulcsfontosságú munkaszközömmé nőtte ki magát. Ennek ellenére az utóbbi hónapokban már a Sublime Text 2 is telepítve volt a gépemen és egyre gyakrabban használtam azt a TextMate 2 alfája mellett.

Badarság lenne temetni a TextMate-et azért mert kereskedelmi szoftverből nyílt forráskódú projekté vállt, sőt akár valami komolyabb dolog is kisülhet belőle vagy valamelyik forkjából. Egy korszak lezárult a szoftver történetében és megjósolhatatlan, hogy a jövőben mi történik majd vele. A magam részéről úgy döntöttem, hogy a Sublime Text 2 szekerét tolom a továbbiakban. Pár hónappal ezelőtt megvásároltam a szoftvert és többé-kevésbé elégedett vagyok vele, illetve a fejlesztés ütemével. Alapértelmezett editorommá tettem azt pedig majd meglátjuk, hogy mit hoz a jövő.

Konvenció konfiguráció helyett

2012-08-08T13:37:00+02:00

Évekkel ezelőtt történt… Pár éves aktív PHP fejlesztést követően felmerült bennem az igény egy keretrendszer használatára, hogy az általános és ismétlődő megoldásokat ne kelljen újra és újra leprogramoznom vagy átemelnem a korábbi forrásaimból, hanem egy jól kidolgozott keretből kiindulva tudjak nekikezdeni egy új projekt megvalósításának. Olyan keretrendszert kerestem amely jól dokumentált, széles körben elterjedt és támogatott, valamint jól testreszabható.

Symphony vagy Zend?

Több lehetséges opció is kínálkozott, végül a Symphony és a Zend Framework akadt fenn a szűrőmön. Mindkettő jól dokumentált, széles körben elterjedt keretrendszer és átlépték már a nagykorúság határát, kinőtték gyermekbetegségeiket.

Miután mindkét keretrendszert teszteltem és próbáltam magamévá tenni, szembesültem azzal a ténnyel, hogy két gyökeresen eltérő filozófiával állok szemben. Míg a Symphony kódgenerátorokat használ, megszabott könyvtárstruktúrával és állománynevekkel, addig a Zend Framework inkább egy komponensgyűjtemény, melyben minden egyes modul egy probléma absztrakt megvalósítása.

Zend Framework

A Zend filozófiáját magamhoz közelebb állónak éreztem. Tetszett az az elgondolás, hogy komponens szinten is tudom a keretrendszert használni. Nem szükséges a teljes framework-öt működésre bírni, ha csak egy adott komponensre van szükség, például PDF állományok generálására (Zend_PDF) vagy adatbázis elérésére (Zend_Db). A legjobban a Zend MVC architektúrája nyerte el a tetszésemet és rengeteg időt töltöttem el annak megismerésével. Lényegében véve azért lett nekem a Zend a befutó keretrendszer, mert – szemben a többivel – sokkal rugalmasabbnak találtam és szimpatikus volt, hogy az utolsó csavarig testreszabható, ezáltal megfelelő mértékű szabadságot ad.

Miután kellőképp megismerkedtem és megbarátkoztam a Zend Frameworkkel, a megszerzett tudást elkezdtem alkalmazni a mindennapi munkám során. Folyamatban lévő projektjeim moduljait cseréltem le Zendes modulokra, új projekteket pedig – ha a feladat lehetővé tette – már eleve ebben kezdtem el fejleszteni. Ezzel egy jól dokumentált, tesztelt és folyamatosan karbantartott alapra építkeztem.

A Zend_DB problémája

Később kiderült, hogy a Zend által biztosított adatbázis-kezelő modul, nem képes maradéktalanul ellátni a feladatát. Indokolatlanul sok idő ment el az alkalmazások modelljeinek kiegészítésével és foltozgatásával, ami sokszor megakasztotta a fejlesztést, valamint a kód áttekinthetőségét is nagy mértékben rontotta. Ennek oka abban keresendő, hogy a Zend_DB a Table Data Gateway tervezési mintára épül, amely egy egyszerű sémát biztosít az egyes táblák és az azokban lévő rekordok elérésére és módosítására tábla szinten. Sima CRUD műveletek esetén ez nem jelent problémát, sőt kifejezetten kényelmes a használata, azonban egy kicsit is összetettebb rendszerben hamar túl kell lépni a tábla szintű gondolkodáson.

Abban a pillanatban, hogy domain objektumokról kezdünk el beszélni, a Zend_DB elveszti rugalmasságát és a modellek kódja egy nehezen emészthető masszává kezd összeállni, amelyhez a programozó csak remegő kézzel mer hozzányúlni. Ha pedig még egységtesztek sem készültek a modellek tesztelésére akkor ember legyen a talpán aki határidőre megbirkózik a feladattal.

Doctrine

Ekkor jött a felismerés, hogy a Zend_DB-t el kell felejteni és valami sokkal hatékonyabb és optimálisabb megoldást kell találni a probléma mielőbbi, fájdalommentes elhárítására. Ennek eredményeként kezdtem el használni a Doctrine 1.2-t, amit annak idején le is jegyeztem. A Doctrine legnagyobb előnye az, hogy remekül megbirkózik a bonyolult domain objektumok kezelésével anélkül, hogy ránk programozókra plusz munkát róna. Köszönhető mindezt azoknak a nagyszerű tervezési mintáknak, melyekre a Doctrine 1.2 építkezik, többek közt az Active Recordnak.

Egy webes keretrendszer két leggyakrabban használt és kihasznált komponense az MVC layer és az adatbázis-kezelő modul. Számomra a Zend ezzel az egyik alappillérét veszítette el, míg például a Symfony – amely a másik potenciális keretrendszer választásom lett volna – eleve a Doctrine ORM-re épült.

Konvenció konfiguráció helyett

Mindig is vonzottak a Rails nyújtotta lehetőségek, különösen az integrált automatizált tesztek nyújtotta biztonság valamint a prototípusok gyors elkészíthetősége, de távol tartott a rendszer “kötöttsége” melyre a ”Convention over configuration” tervezési minta is utal. A Rails – szemben például a Zend Frameworkkel – óriási hangsúlyt fektet a konvenciókra, ez pedig a keretrendszer minden porcikájában tetten érhető: a szigorúan meghatározott könyvtárszerkezettől kezdve a modellek nevében használt egyes- és többesszám használatán át, egészen a kapcsolt táblák elnevezésének pontos meghatározásáig. A Rails-szel történő fejlesztésnek tehát nem az alapul szolgáló Ruby programozási nyelv jelenti a nehézségét, hanem az előbb említett konvenciók megismerése.

A szigorú konvenciókövetés talán egy kicsit megnöveli a tanulási időt, mégis számos jótékony hatása van, mely által a befektetett idő többszörösen megtérül. Az elkészített kód egységes szerkezetű lesz és nem keverednek benne az eltérő gondolkodásmódból fakadó kifejezések. A Rails fejlesztők közös nyelvet beszélnek, azonos szabályokat követnek, emiatt pontosan tudják, hogy egy-egy funkcióért pontosan hova kell nyúlni. A közös szabályok elősegítik a rendszer kiegészítőinek fejlesztését is. Az sem elhanyagolható, hogy a Ruby fejlesztők webes keretrendszerért legnagyobb eséllyel a Rails-hez nyúlnak, nincs akkora szegmentáció mint a PHP alapú keretrendszerek esetén. És végül, a legtöbb PHP-s keretrendszer közvetve vagy közvetlenül a Rails-ből merített ihletet.

Minden a meta metájának a metája

Fél éven át nem tudtam aludni. Az inszomniásnak látomás a világ. Távoli vízió. Minden a másolat másolatának a másolata.

Harcosok klubja

Programozásra lefordítva a fenti idézetet: rég nem fejlesztünk már sima HTML-ben, dinamikus HTML van, PHTML, meg ERB. CSS-t nem szeretünk már közvetlenül előállítani, LESS van meg SCSS. A sima javascript is kezd kimenni a divatból, jQuery van, meg Prototype és lehet, hogy még ezeket is csak generáljuk, mondjuk CoffeeScript közbeiktatásával. Természetesen minden responsive. Minden a meta metájának a metája.

Ebben a felgyorsult világban kiemelt jelentőséggel bír a hatékonyság és a sebesség. Nincs sem idő, sem energia arra, hogy saját függvénykönyvtárakat és azokból saját keretrendszereket építsünk. A legtöbb mai framework – legyen az webes, mobil vagy desktop – kész megoldásokat kínál. A programozónak ma már nem egy programozási nyelv megismerése jelenti a nehézséget, hanem az, hogy az egyes keretrendszereket, azok filozófiáját, sajátosságait, erősségeit és gyengeségeit megismerje és a mindennapi munka során hatékonyan tudja ezeket használni, valamint legyen egy jó referencia amelyből könnyen segítséghez lehet jutni.

A fent említett technológiákban a Rails nagyon erős és fontos szerepet töltenek be a keretrendszer működésében, ezekkel is elősegítve a DRY tervezési minta megvalósítását.

Kódolási stílus

Herótom van attól, hogy sok PHP fejlesztő semmilyen kódolási stílust sem követ, ahogy esik úgy puffan alapon adnak nevet változóknak, függvényeknek, osztályoknak, össze-vissza tördelik a sorokat, mindenféle koncepció nélkül, persze a behúzást is állandóan változtatják 1 és 8 karakter között (véletlenszerűen!) a tabot és a szóközöket is variálva, de a fogalom nélküliség legjobb példája a kontrollerekbe ágyazott if (..): endif; kifejezések. Rémálom az ilyen kódot olvasni és értelmezni. Véleményem szerint maga a PHP nyelv is ludas a téves, szabályok nélküli elnevezésekben, ehhez elegendő átfutni a PHP string függvények listáját szabályok után kutatva. A Zend Framework egyébként egy jól alkalmazható és könnyen elsajátítható kódolási stílust javasol, de ez sem tudja teljes mértékben orvosolni a rossz tervezésből eredő problémákat.

A Rails konvencióinak egy része magából a programozási nyelvből fakad, mivel a Ruby ugyanúgy tesz javaslatot a stílusra vonatkozóan és ezeket következetesen be is tartják. A Rails-es konvenciók pedig megkerülhetetlenek, vagy legalábbis plusz munkával jár azok figyelmen kívül hagyása, tehát semmiképp sem éri meg elmenni mellettük.

Teszt alapú fejlesztés

Mindig is szerettem volna követni a teszt alapú fejlesztés (TDD) szabályait, de a körülményes előkészítés mindig elvette a kedvem a megvalósítástól vagy a karbantartásától. Pedig nincs annál rémisztőbb, mint amikor olyan kódot kell módosítani melynek kihatása van a program működésének több területére is és nincsenek egységtesztek melyek ellenőriznék a program helyes működését a módosítások elvégzését követően. Ilyenkor rendre előfordul, hogy a javítás során megfeledkezünk egy-egy érintett kódrészről és csak az éles környezetben derülnek ki a nem várt mellékhatások. Sokszor időpocsékolásnak tűnik az egység-, a funkcionális- és az integrációs tesztek elkészítése, pedig kettős céljuk is van:

ellenőrzik a program helyes és elvárt működését,
programozói “dokumentációként” szolgálnak és pontos képet adnak az olvasónak a program működéséről.

A Rails alkalmazásokhoz gyerekjáték teszteket gyártani és elgördít minden akadályt a fejlesztő útjából, csak a megvalósításra kell koncentrálni. Előkészíteni és alkalmazni a teszt adatokat (fixtures) épp oly egyszerű, mint az adatbázis-struktúra elkészítése és módosítása (migrations) vagy a parancssoros eszközök kezelése és kiegészítése saját funkciókkal (rake és rails).

Post-PHP

Több évnyi PHP fejlesztést követően igazi élmény a Ruby programozási nyelvvel és a Rails keretrendszerrel dolgozni. Ma még a PHP megkerülhetetlen a legtöbb webfejlesztő számára és vannak kétségbe vonhatatlan előnyei, mégis felüdülést jelent a Rails-hez hasonló megoldásokkal megismerkedni és dolgozni.

Végül fontos megjegyeznem, hogy ebben a bejegyzésben csak a Doctrine 1.2-ről tettem említést, miközben már rég elérhető a 2.0-ás verzió. A 2.0-ás ágban teljesen megváltozott a Doctrine szemlélete és az Active Record helyett a Data Mapper tervezési mintára építették. Nem volt még alkalmam közelebbi ismeretséget kötnöm vele, mert nincs közvetlen migrálási folyamat a korábbi verziókról így az aktív projektjeimben továbbra is az 1.2-t használom.

WWDC 2012

2012-06-10T15:35:00+02:00

Jövő héten kerül megrendezésre az Apple éves fejlesztői konferenciája a WWDC, a holnap esti keynote során pedig megtudhatjuk, hogy milyen hardveres- és szoftveres újdonságokkal rukkol elő a cég. Hónapok óta mennek a találgatások és pletykák mindenféle futurisztikus, várt és nem várt termékek megjelenésével kapcsolatban. Röviden megpróbálom összeszedni, hogy mit is várok az eseménytől.

Számomra a legfontosabb termékbejelentés az új MacBook Pro termékcsalád lenne, SSD-vel, optikai meghajtó nélküli vékonyabb kiszerelésben, nagy felbontású retina kijelzővel. Ebben reménykedem a legjobban. Ha nem lesz retinás, SSD-vel szerelt MacBook, MacBook Pro vagy Air, akkor bármit is jelent be a cég – legyen az akár rézfaszú bagollyal szerelt gigászi méretű iPhone 6, magyar gondolatfelismerős Sirivel vagy bármivel – számomra csalódás lesz az esemény. Az, hogy mi lesz a termék neve és pontosan hová lesz pozicionálva, az nagy kérdőjel. Retina nélküli MacBook és retinás MacBook Pro? Vagy talán 13-as retinás MacBook és szintén retinás 15-ös MacBook Pro? Talán retina nélküli Air és retinás Pro? Még a Time Capsule is retinássá válik aminek nincs is kijelzője, de mostantól lesz (NEM)? Bármit el tudok képzelni és még nem is beszéltünk az asztali gépekről, az iMac és Mac Pro vonalról.

Az iOS 6 és a Mountain Lion bejelentés (közvetve és közvetlenül) tulajdonképp már meg lett erősítve és ez egyébként is teljesen nyilvánvaló egy WWDC-n, ugyanakkor nagy kíváncsisággal várom, hogy milyen újdonságokkal rukkolnak elő az OS frissítésekkel. A mélyebb Facebook integrációs parasztvakításnál azért sokkal többet várok iOS fronton.

Ha már iOS, akkor adódik a kérdés, hogy lesz-e iPhone 6? Véleményem szerint nem. Igaz, hogy a múltban volt már iPhone bejelentés WWDC-n, mégis azt gondolom, hogy az őszi időszakra tehető az új telefon bejelentése és megjelenése. Bár logikusnak tűnik, hogy ha meglépi az Apple a 16:9-es képarányt akkor fel kell készíteni a fejlesztőket az új eszköz érkezésére, azonban a múltban erre sosem volt példa. Az iPad megjelenése előtt sem lett beharangozva, hogy “Gyerekek, hamarosan előrukkolunk egy táblával aminek ilyen paraméterei lesznek. Tessék elkezdeni a portolást az új eszközre, különben a kutya sem fogja vásárolni az új termékünket!”. Ehelyett megoldották, hogy az iPhona-ra írt alkalmazások fussanak a táblán, majd idővel mindenki lefejlesztette a saját iPad-es verzióját. Emiatt azt a WWDC-s analógiát, miszerint azért jelentik be most az új iPhone-t, hogy a fejlesztőket az elkövetkező héten kioktassák a 16:9-re való portolás lehetőségeiről, nem tartom helytállónak. Egyébként sem fejleszői oldalról jelent “problémát” egy új képarány megjelenése, hanem UI dizájn vonalon. Egy szó mint száz, nem várok új iPhone bejelentést.

Összegezve és listába szedve, amit várok:

MacBook termékcsalád frissítése processzorral, SSD-vel, retina kijelzővel, természetesen optika nélkül
Asztali gépek frissítése, talán új iMac, Mac Pro vagy mindkettő
Mountain Lion bejelentése pontos megjelenési dátummal a közeljövőben
iOS 6 beta bejelentése fejlesztőknek, őszi kiadási dátummal (természetesen az ősszel megjelenő iPhone-hoz időzítve).

Ha pedig WWDC akkor a kívánságlistámon szerepel a Cocoa Bindings bejelentése iOS platformra.

QWERTY

2012-06-04T10:28:00+02:00

Egy ideje ismét angol kiosztású billentyűzetet használok. Annak idején ezen az elrendezésen tanultam meg gépelni és programozni, de valami érthetetlen oknál fogva váltottam magyarra, amit később mindig is bántam. Egy hétbe telt mire biztonsággal használtam újra az angol kiosztást, de erre a programozás miatt mindenképp szükségem volt, mert könnyebben érhetőek el azok a speciális karakterek melyekre fejlesztés során állandóan szükség van, így OPTION+SHIFT helyett elegendő a SHIFT-et használni, vagy még azt se. Az angolra váltással együtt a QWERTY elrendezést is megszoktam, mert – a magyar QWERTZ-el ellentétben – az angol eszközön az a default. Úgy vettem észre, hogy sokkal kevesebb az elütés mióta váltottam, és a QWERTZ kiosztással is úgy vagyok azóta mint sündisznó a drótkefével.

Nagy bánatom, hogy az iPad-hez csatlakoztatott külső billentyűzetnek – magyar kiosztás esetén – nem állítható QWERTY layout, annak ellenére, hogy a szoftveres billentyűzet tudja ezt. Blogbejegyzések írásához gyakran szoktam az iPad-et használni, és bármennyire is kényelmes a szoftveres billentyű, a külső eszköz az, amivel megfelelő sebességgel és kényelemmel tudok gépelni. A számomra megfelelő kiosztás hiányában ez azonban rendszeres elütéseket eredményez és ha nem figyelem tudatosan, akkor az Y-t és Z-t állandóan felcserélem.

Apró, pici hiányosság ez, számomra mégis szinte teljesen ellehetetleníti a külső billentyűzet használatát olyankor, amikor magyar ékezeteket is használok. Ezért az én iOS 6 kívánságlistámon többek közt ennek a “hibának” a javítása szerepel. Baromi jó lenne továbbá, ha a külső eszközzel is lehetne a futó appok között váltani CMD-TAB-bal. Bízva abban, hogy az Apple meghallgatja a kis emberek véleményét is, egy radar bejegyzésben jeleztem az igényt a hibabejelentő oldalon. Sok reményt nem fűzök a dologhoz, de úgy gondolom, hogy egy próbát mindenképp megér.

Terminál tabok elnevezése

2012-05-28T20:54:00+02:00

Egyedi neveket adhatunk az OS X Terminal ablakának és az egyes taboknak, az alábbiak beillesztésével a ~/.bash_profile állományba:

function tabname {
  printf "\e]1;$1\a"
}

function winname {
  printf "\e]2;$1\a"
}

Használata egyszerűen:

$ winname "RoR"
$ tabname "SERVER"

RoR fejlesztés során például gyakran kell a terminált használni, így jól jön, ha a tabok egyedi névvel vannak ellátva.

forrás: The Lucid - Naming your Terminal tabs in OSX Lion

Reggel

2012-05-27T11:08:00+02:00

… fél ötkor kipattant a szemem. Odakint már világosodott. Éreztem, hogy az alvást nincs értelme erőltetnem, már nem fogok visszaaludni. Kiosontam a hálószobából. A feleségem és a kislányom még javában aludtak. Készítettem magamnak reggelit majd egy forró kávét és behúzódtam a dolgozószobába.

Éjszakai bagoly vagyok, nem is emlékszem mikor láttam utoljára napfelkeltét. Nyugodt minden, csend van és előttem áll még az egész nap. Nem érzem, hogy az elmaradt dolgaim után kellene rohannom. Épp ellenkezőleg. Nyugalommal tölt el, hogy egy egész nap áll még előttem, tele lehetőségekkel.

Ez mindig eredményesebbé tesz. Gyakrabban kellene élnem a lehetőséggel.

Ruby függvények és paraméterek

2012-05-25T15:09:00+02:00

az alcím az is lehetne, hogy egy kezdő Rubyist, hogyan döbben rá a nyelv furcsaságaira.

Objective-C finomságok

Amikor pár évvel ezelőtt elkezdtem ismerkedni az Objective-C programozási nyelvvel, akkor az egyik első furcsaság amivel szembe találtam magam, a metódusok hívásának módja volt. Az általam korábban használt programozási nyelvek objektum.metódus(param1, param2) szintaxisával szemben, az Objective-C a szögletes zárójeles (square bracket notation) jelölést használja, melyet Object Messaging-nek hívnak. Valahogy így:

[myRectangle display];

más nyelvekben ez általában így néz ki:

myRectangle.display();

A metódusoknak named parameter-en (nevesített paraméter???) keresztül lehet átadni információkat, valahogy így:

[myRectangle setOriginX:30.0 y:50.0];

ezt általában így szoktuk meg:

myRectangle.setOrigin(30.0, 50.0);

Nagyon hamar meg lehet szokni ezt a formát. Igaz, hogy sokkal több billentyűleütéssel jár a használata – melyet az Xcode ügyesen kompenzál az intelligens kódkiegészítéssel – cserébe viszont sokkal olvashatóbbá válik a forráskód, hiszen egy egyszerű metódushívásra tekintve azonnal látszik, hogy az egyes paraméterek mire vonatkoznak. Ez akkor válik különösen hasznossá, amikor 4 vagy annál több paraméter kerül egyidejűleg átadásra. Például:

Paraméter átadás Java-ban:

window.addNewControl("Title", 20, 50, 100, 50, true);

Ugyanez Objective-C-vel:

[window addNewControlWithTitle:@"Title"
                     xPosition:20
                     yPosition:50
                         width:100
                        height:50
                    drawingNow:YES];

A kezdeti furcsasága ellenére könnyen meg lehet szeretni ezt a formát és az Apple által javasolt konvenciók követésével igazán hatékonyan lehet így programozni, miközben a kód folyamatosan olvasható, szinte önleíró marad.

Metódus hívás Ruby-val

A Ruby programozási nyelv szintaxisa számomra nagyon megengedő. A metódus hívására a hagyományos objektum.metódus() formát használja, azonban a zárójelezés teljesen elhagyható, még akkor is ha paraméterátadás történik:

my_rectangle.display
my_rectangle.origin 30.0, 50.0    # my_rectangle.origin(30.0, 50.0)

Nagyon gyorsan lehet vele programozni, de a kód olvasása – különösen egy összetett kontextusban – elég nehézkessé tud válni. A Ruby Style Guide ezt javasolja:

Omit parentheses around parameters for methods that are part of an internal DSL (e.g. Rake, Rails, RSpec), methods that are with “keyword” status in Ruby (e.g. attr_reader, puts) and attribute access methods. Use parentheses around the arguments of all other method invocations.

The Ruby Style Guide Syntax

A kezdő Rails programozó rendszeresen szembe találja magát olyan kódrészekkel, melyek olvasása, értelmezése és magáévá tétele igencsak megnehezíti a dolgát:

validates :email, allow_blank: true, format: {
  with: EMAIL_REGEX,
  message: 'should be a valid e-mail address'
}

Mivel ez a Rails DSL része itt elő van írva a zárójelek elhagyása, valamint életbe lép egy másik szabály is, miszerint ha a paraméterátadás során az utolsó paraméter Hash akkor a kapcsos zárójelek elhagyhatóak. A fenti kód így nézne ki zárójelekkel:

A formázást szándékosan tördeltem szét ilyen aprólékosan, az átláthatóság érdekében

validates(:email,
  {
    allow_blank: true,
    format: {
      with: EMAIL_REGEX,
      message: 'should be a valid e-mail address'
    }
  }
)

Mikor már rááll az ember szeme, akkor az első forma könnyen olvashatóvá válik és valóban sokkal tömörebb mint a második esetben. Olyan ez mint az autóvezetés. A kellő rutin birtokában már nem kell gondolkodni azon, hogy mikor kell sebességet válltani.

Konkrét eset

Az előző példa egy konkrét esetemet reprezentálja. Nem értettem, hogy az allow_blank: true miért nem inkább a :format hash-ben került átadásra, így:

validates :email, format: {
  allow_blank: true,
  with: EMAIL_REGEX,
  message: 'should be a valid e-mail address'
}

A validates metódus definíciója nem sokat segített, mert az így néz ki:

validates(*attributes)

Írtam pár egységtesztet és kiderült, hogy mindkét forma tökéletesen működik és ugyanazt az eredményt hozza. Ez végképp összezavart, ezért elkezdtem mazsolázni a Rails forráskódját, hogy kiderítsem mi történik a háttérben. Baromi nehéz volt értelmezni, hogy mikor mi történik a rengeteg splat operátor mögé rejtett paraméterátadás során. Végül kiderült, hogy a külön írt :allow_blank-nek akkor van jelentősége, ha egyidejűleg több validáló paramétert kap a validates metódus. Ebben a formában bármelyik esetben lehet blank? az :email értéke:

validates :email, allow_blank: true, confirmation: true, format: {
  with: EMAIL_REGEX,
  message: 'should be a valid e-mail address'
}

Míg ennél a formánál csak a validates_format_of metódus hívása során:

validates :email, confirmation: true, format: {
  allow_blank: true,
  with: EMAIL_REGEX,
  message: 'should be a valid e-mail address'
}

A validates_confirmation_of nem engedi meg, hogy blank? legyen az :email értéke. A példa nem életszerű, de jól reprezentálja a problémámat. Végül kiderült, hogy a Rails API doksijában ez egyértelműen le is van írva:

Finally, the options :if, :unless, :on, :allow_blank, :allow_nil and :strict can be given to one specific validator, as a hash … or to all at the same time

Ruby on Rails v3.2.3 ActiveModel::Validations::ClassMethods

Konklúzió

Ha úgy vesszük, akkor tulajdonképp a Ruby a Hash-t használja név szerinti paraméterátadásnak. Objective-C-ben a függvény definíciója egyértelműen meghatározza az egyes paraméterek típusát és funkcióját, a Ruby függvények definíciója ellenben nem reprezentál ilyen pontos funkcióleírást, így a fejlesztő csak az API dokumentációjára, rosszabb esetben csak a forráskódra számíthat. Ez magyarázatot ad arra is, hogy miért nem létezik igazán jól működő kódkiegészítés a Ruby függvényekhez.

A fenti validates(*attributes) metódus elemzése során többször is eszembe jutott, hogy mindez Objective-C-ben mennyivel könnyebben értelmezhető lenne. Ugyanakkor nyilvánvalóan kevésbé lenne rugalmas és szabadon formázható, szemben a Rails keretrendszerrel és a Ruby nyelvvel. Egyik sem jobb a másiknál, egyszerűen csak más.

Két teljesen eltérő megközelítés, az egyik forma az olvashatóságot, a másik a rugalmasságot és tömörséget részesíti előnyben.

Coda 2

2012-05-24T17:32:00+02:00

A mai napon jelent meg a Coda 2 webszerkesztő alkalmazás a Panic gondozásában, melyet már sokan vártak. Óriási volt a hype amely a megjelenését megelőzte, ami nem is csoda, hiszen egy markáns frissítésen esett át a szoftver.

Soha nem használtam a Coda korábbi verzióit, de az promóciós videó igencsak felkeltette az érdeklődésem. A Coda 2 egy gyönyörűen megrajzolt és teljesen integrált webfejlesztői program lett, amely beépítve tartalmaz HTML-, CSS- és kódszerkesztőt, fájlböngészőt, MySQL szerkesztőt és terminált. A Coda 2-vel egy időben megjelent a kicsit butított iPad verzió is Diet Coda néven, hasonló tulajdonságokkal mint az asztali verzió, felvértezve az AirPreview-nak nevezett cukisággal, amely real-time jeleníti meg az asztali verzióban szerkesztett tartalom kimenetét, kvázi előnézetet ad.

Pillanatnyilag csak egy normális editort ismerek iPad-re, a Textastic-ot. Fantasztikus szoftver és mindent tud amire egy webfejlesztőnek szüksége lehet, ha épp csak egy iPad áll a rendelkezésére. A VCS támogatást hiányolom belőle, de a fejlesztő Twitteren már jelezte, hogy dolgozik a Git integrálásán (Hurrá!), illetve kicsit kényelmetlen, hogy az állományokat le-fel kell töltögetni a módosítások során.

A lényeg, hogy a megjelenés napján letöltöttem a Coda 2 próbaverzióját, illetve megvásároltam a Diet Coda-t az App Store-ból. Sajnos csalódás volt számomra. Ezzel senkit sem akarok megbántani, de véleményem szerint az egésznek nagyobb a füstje mint a lángja. Nincs semmi átütő vagy forradalmi a szoftverben a megjelenésén kívül, amit meg kell hagyni szemet gyönyörködtető.

Az iPad verzió ugyan mutat néhány hiányosságot, amely - egy magamfajta fejlesztő számára - nehezen megbocsátható:

nem lehet színsémát betölteni (hardcore fejlesztőként az életem felét ezekben az editorokban töltöm, hagy döntsem már el én, hogy mi nekem a jó, egyébként is Solarized addict vagyok)
nem lehet fontot választani, a beépített pedig problémázik a magyar ékezetekkel
a terminál nem hajlandó elfelejteni a legutóbb megnyitott session paramétereit, így ha több projektem is van különböző szervereken, akkor simán az elsőnek megnyitott SSH sessiont mutatja, hiába zárom be a projektet és nyitok egy újat. Nem kis problémát tud ez okozni éles környezetben, mondjuk egy rossz szerveren kiadott rm -r * parancs futtatásával.

Nem, nem azt mondom, hogy a Coda 2 és a Diet Coda rossz szoftverek lennének! Egy jól integrált, nagyon látványos és igényes webfejlesztő szoftver, amely mutat ugyan hiányosságokat, de ezeket nyilván javítani fogják a jövőben. A problémám az, hogy semmi olyan újdonságot vagy innovációt nem mutat amely indokoltá tenné a hatalmas hype-ot. A szoftver minden komponense, többé-kevésbé különálló alkalmazásokként megtalálható minden webfejlesztő eszközarzenáljában. Jobbnál jobb kódszerkesztők, forráskódkezelők, MySQL kliensek és terminál alkalmazások vannak, melyet minden fejlesztő használt eddig is és messzemenően többet tudnak. Bárhogy is csűrjük-csavarjuk, a Coda erőssége a marketingben és a dizájnban rejlik, ami természetesen nekem is sokat számít (a dizájn része), de fejlesztőként ennél nekem sokkal többre van szükségem.

Időről időre meggyűlik a bajom a TextMate-tel, mégis lenyűgöz, hogy már évekkel ezelőtt mennyivel többet tudott mint más hasonló editorok bármely platformon. A TextMate 2 alfája is mutat problémákat, annak ellenére, hogy több éves késéssel jelent csak meg. Mégis valahányszor eldöntöm, hogy elpártolok tőle, rövid időn belül visszahúz a szívem és a kezembe rögzült shortcut-ok. Íme egy kis TextMate pornó, Ruby on Rails refactoring:

Rails telepítés 4 lépésben

2012-05-14T12:59:00+02:00

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:

curl -L get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm install 1.9.3 --with-openssl-dir=$rvm_path/usr --with-gcc=clang
gem install rails

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:

curl -L get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm pkg install iconv
rvm pkg install openssl
rvm install 1.9.3 --with-openssl-dir=$rvm_path/usr --with-iconv-dir=$rvm_path/usr --with-gcc=clang
gem install rails

Kindle Touch

2012-04-23T16:29:00+02:00

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.

Miért van szükségem könyvolvasóra?

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.

Rendelés és szállítás

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.

A Kindle Touch

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.

Negatívum

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.

Readability

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.

Magyar könyvek hiánya

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.

iCacti klón

2012-04-20T17:02:00+02:00

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.