, — Nincs hozzászólás
2010
11
márc

MacBook Pro frissítés

wpid-mbp-unibody.Up0knerEFIdQ.jpg
Már 10 napja annak, hogy az új MacBook Pro-t használom és most jött el az ideje annak, hogy beszámoljak eddigi tapasztalataimról. Az unibody széria már tavaly debütált, nálam azonban még csak most érkezett el az ideje annak, hogy újítsak. Több dolog is közrejátszott ami miatt úgy döntöttem, hogy frissítem a pont 2 éves MacBook Pro-mat.

Az iPad bejelentése első körben nem nyűgözött le, de mélyebben átgondolva a dolgot arra jutottam, hogy remek kis eszköz lenne a nappaliba. Olvasásra, netezésre teljesen el tudom képzelni. Igaz, hogy nagyságrendileg ugyanazt nyújtja mint az iPhone, de a méretes kijelző mégiscsak gazdagítaná a felhasználói élményt. (Btw, bárki bármit is mond, az iPhone – a képernyő méretéből kifolyólag – könyvolvasásra egyszerűen alkalmatlan.) Szóval elkezdtem kacérkodni a gondolattal, hogy milyen frappáns is lenne, ha az iPhone fejlesztésből befolyt összeget stílszerűen iPad vásárlásra fordítanám, ezzel megfinanszírozva a további fejlesztések hardveres oldalát. Már-már rá is szántam magam, hogy a büdzsében elkülönítek egy összeget az eszköznek, de ekkor bevillant, hogy annyi ismeretlen tényező van még ami megakadályozhatja vagy megnehezítheti a vásárlást, hogy a tényleges beruházásig akár még egy év is eltelhet. Arra gondolok, hogy hazánkban mikor lesz hozzáférhető (legálisan), ki fogja értékesíteni (ha mobilszolgáltató akkor milyen kondíciókkal) és az első szériának milyen hibái derülnek ki a megjelenést követően.

Néhány hete a laptopom egy furcsa jelenséget kezdett el produkálni. Valahányszor a beépített hangszóró megszólalt egy magas frekvenciás sípoló hangot kezdett el sugározni, egészen addig amíg a hangszórót – pár másodperc elteltével – a gép ki nem kapcsolta. És ez így ment valahányszor egy e-mail érkezett vagy megszólalt a Startup Sound. Hosszú távon nem volt zavaró, mert ha hozzászokott a fülem a sípoláshoz – úgy mint az óra ketyegéséhez – akkor már fel sem tűnt az egész, de valahányszor megszólalt akkor akaratlanul elvonta a figyelmemet. Volt egy másik probléma is a géppel, mégpedig az akku élettartama. Igyekeztem nagyon vigyázni a gép akkumulátorára – az első MacBook-om vásárlásakor egy posztot is szenteltem neki – de hiába. Az utolsó mérések szerint 50%-os volt a kapacitása és ezt egy valószínűsített cellazárlat tovább súlyosbította. Hiába az odafigyelés, a havi kalibrálás és a 80 töltési ciklus (2 év alatt!!!) a cucc erősen kezdte magát megadni, kb. 2 órára csökkent az élettartama.

Mindezek mellett már nagyon időszerű volt egy memória upgrade is, mivel a megvásárlás óta az alap 2GB RAM-mal használtam a gépet, amit már kezdtem nagyon kinőni. Mindezeket összevetve arra jutottam, hogy idén inkább laptop vásárlással áldozok az Apple oltára előtt. A RAM és az akku cserére nem volt kedvem túl sokat költeni, a szervizelés gondolatától pedig rázott a hideg. Bele sem mertem gondolni, hogy mennyi ideig kellene a feleségem laptopjával dolgoznom, amíg az enyém le van adva javításra. Grrrrrrr!

Összességében ezek a dolgok vezettek oda, hogy ismét a laptop csere mellett döntöttem. iJoe – a fentiek ismeretében – nagyon méltányos ajánlatot adott és immáron 10. napja az új MacBook Pro 15”-t nyúzom. Az eddigi tapasztalataim nagyon kellemesek, szembeötlőek a változások (nem csak a külsőt tekintve). Az új gép észrevehetően csendesebb mint a régi volt, sokkal kevesebbet tekeri a ventilátort (vagy csak egyszerűen csendesebben teszi azt). A laptop felülete is sokkal hűvösebb, nincs az a kellemetlen érzés, hogy izzad a tenyerem a billentyűzet fölött. A billentyűzet fényévekkel kényelmesebb mint a régi volt a glossy kijelző viszont kissé zavaró. Ha hátulról kapom a fényt akkor erőteljesen tükröződik és keményen be kell neki árnyékolni vagy pozíciót kell váltani.

Az akkura most igyekszem az eddiginél is jobban odafigyelni. Legújabb információim szerint nem árt neki, ha egy-két naponta járatjuk egy kicsit töltő nélkül is, de ez úgyis csak hosszú távon derül majd ki. Összességében nagyon elégedett vagyok a cserével.

, , , — Nincs hozzászólás
2010
28
jan

Mi lesz az iPad?

Tegnap történelmi eseménynek lehetett szemtanúja az Apple legendásan híres rajongói tábora. A cég bejelentette az iPad névre keresztelt táblarendszerét amely valahol az iPod Touch és a MacBook között fog elhelyezkedni a termékpalettán. Mivel jó ideje nem lehet élő videóközvetítésen követni a tegnapihoz hasonló Apple eseményeket így erre szakosodott híroldalakról lehetett követni a Keynote történéseit. Hazánk fiai hordákba verődve várták a nagy bejelentést, több helyen online streamelték is a Keynote bulit. Én a távolból, a Plastikon követtem az eseményeket.

Már a bejelentés előtt is tudta mindenki, hogy ma egy Apple tábla kerül bemutatásra. 3 éve ezt várta minden Apple fanatikus, hogy Steve kijön a színpadra, előhúzza a tábálát és demózni kezd, mi pedig ámulunk és bámulunk, miközben hitetlenkedünk, hogy micsoda korban élünk. Még a (táblával szemben) szkeptikusok is mint én azt fogják mondani a Keynote után, hogy “Húú bazmeg, ilyen kell!”. Mégis valahogy felemás érzésekkel álltam fel a monitor elől. Nem titok, ugyanazon a véleményen voltam mint majd’ mindenki akivel az esemény során beszéltem: az iPad csak egy óriás iPod Touch. Mivel lehetett számítani az iPad bejelentésére így nekem konkrét kérdéseim voltak melyekre választ szerettem volna kapni. Ezek egy részére a demózás során meg is érkezett a válasz és persze van olyan is amit csak tapasztalati úton fogok megtudni (pl. mennyire válik maszatossá a kijelző a mindennapi használat során). Maradt azonban egy nagyon nagy kérdőjel. Megválaszolatlan maradt számomra, hogy ki a célközönsége az eszköznek? Mire tervezték az iPadot? Internettáblának? E-book readernek (mint Kindle-killer)? Játékgépnek? Esetleg üzletemberek játékszere lehet a cucc? Nekem olyan, mintha a fókusz egy kicsit elment volna. Ahelyett, hogy az iPad egy valami lenne, inkább minden akar lenni.

Úgy érzem, hogy nem vagyok megtalálható annak a két halmaznak az uniójában ahol az iPad és annak a célcsoportja található. A célcsoport valahol tényleg ott lehet ahol Kobak és Wyctim is említette Twitteren: geek feleségeknek és anyukáknak való az eszköz, ahol a termék egyszerűsége és használhatósága hatványozottan kijön. Mintha a Keynote-os demózásnak is lett volna egy olyan rejtett üzenete, hogy ezt a terméket otthon, a fotelban kell használni notebook helyett. Itt pedig felmerül bennem egy másik fontos kérdés, a fejlesztők. Az okostelefonban az a fantasztikus, hogy olyan mobil eszköz amely mindig ott van a tulajdonosánál. Így a rajta tárolt adatok és a programok mindig kéznél vannak. Hurcoljuk magunkkal a munkába, az ágyba, a budira, egyszóval mindenhova. Ez persze hatalmas lendületet ad a fejlesztésnek is. Milliónyi ötletet lehet megvalósítani, amelyre korábban nem igazán létezett platform, majd egycsapásra megszülettek az eszközök amelyek biztosítottak mindent ami a jó kis ötletek megvalósításához kell. Internet, navigáció, mobilitás, nagy kijelző, mozgásérzékelő. Ezt nem látom az iPad esetén és ezért nagyon kíváncsi vagyok, hogy az iPad-ra készült alkalmazások ugyanolyan sikeresek lesznek-e mint azok amelyek az iPhone-t vették célba (itt persze tegyük félre az átjárhatóságot az iPhone -> iPad között, ami nagyon dicsérendő megoldás). A másik nagyon fontos dolog, hogy az iPhone “kicsiny” kijelzőjét könnyű megölteni tartalommal. A jól átgondolt és megtervezett navigációs felület segítségével könnyűszerrel implementálható majd’ minden funkcionalitás. A fejlesztő egyik szeme sír a másik meg nevet. Nevet, mert az iPad méretének dimenzióiban már sokkal több tartalmat és funkcionalitást lehet elhelyezni egyetlen képernyőnyi méreten, de sír, mert nem az a platform ahova feldobok egy beviteli mezőt és egy gombot és már adom is ki az 1.0-ás verziót az alkalmazásból, hogy dőljön befelé a rengeteg dohány. Persze félreértés ne essék, nem a nagy kijelző és a jól kidolgozott, minőségi alkalmazások ellen kampányolok. Dehogyis! Csak arra gondolok, hogy előfordulhat, hogy az iPad platform nem lesz annyira vonzó a fejlesztők számára mint amennyire az iPhone és iPod Touch. Ha pedig ez így lenne, akkor Phil Schiller rohangálhat körbe a színpadon, hogy “Developers, developers, developers…”. Persze nagyon valószínű, hogy sok iPhone fejlesztő most egyből rárepül a lehetőségre, hiszen az új “aranybányából” senki sem szeretne kimaradni.

A Kindle-killer funkcióról egyelőre nem is érdemes beszélni. Az Amazont még egy Apple méretű cégnek sem lenne egyszerű lenyomni. Persze többször megcsinálta már az Apple a lehetetlent, de szerintem itt egyáltalán nem arról van szó. Egyszerűen csak terjeszkednek a hosszú farok területén és teljesen kézenfekvő, hogy a zene és a videó után a könyvpiacon is otthagyják a kezük nyomát. Azt pedig úgyis csak hosszú távon fog kiderülni, hogy mennyire működőképes a koncepció, hogy van-e hely az Amazon mellett (és nem helyett). Minden esetre én örülök az iBooks store-nak, de nekem az lesz a befutó eszköz amelyik először fogja biztosítani a magyar nyelvű könyvek megvásárlását.

Azt gondolom, hogy az iPad célcsoportja alapvetően nem az alkalmazásbuzi réteg lesz. Ha az iBooks könyváruház megfelelően beindul akkor egy remek kis könyvolvasó válhat belőle, amely mindamellett, hogy kiváló céleszköz – a könyvolvasásra – még internetezési és alkalmazásfuttatási lehetőséget is biztosít. Ha tényleg ez a fókusz akkor azt mondom fasza. Ha beérik akkor jó áron, jó kis eszköz. Nagyon homályos ez még számomra. Egyelőre inkább a háttérből figyelem az eseményeket.

, , , , — 2 hozzászólás
2010
24
jan

Doctrine és Zend Framework integráció

Jó ideje Zend Frameworkkel gyártom a “kontentot” és az elmúlt két év tapasztalatából azt a fájdalmas konzekvenciát kellett levonnom, hogy a Zend MVC-jének modell rétegével kínkeserves meló egy korrekt Domain Modell leprogramozása, a modell változásainak követése és karbantartása. Amikor a feladat szükségessé teszi egy komolyabb adatbázis-struktúra kezelését akkor a Zend_Db időről-időre csődöt mond. Hiába próbáltam hosszú időn keresztül elkészíteni a tökéletes adatbázis absztrakciós réteget, sajnos sosem jártam igazi sikerrel. Kipróbáltam mások elképzeléseit is (Model Infrastructure, Domain Model Programming With the Zend Framework) de hosszabb távon, az igények növekedésével ezek a megvalósítások mindig zsákutcának bizonyultak. Nem arról van szó, hogy a Zend modell rétege nem működne, sőt egyszerű modellek esetén nagyon kényelmes és gyors is. Arról van szó, hogy egy megfelelően bonyolult domain modell karbantartása indokolatlanul sok feladatot hárít a fejlesztőre, így sokszor a napi maintenance munka nagy része azzal megy el, hogy az alkalmazás működésében vagy az adatmodellben bekövetkezett változások miatt az domain modellt kell püfölni. Egy agilis fejlesztési folyamat során ez sajnos nem megengedhető, túlzottan sok időt és energiát emészt fel.

A legutóbbi nagyobb projekt során az egyik kolléga hívta fel a figyelmet arra, hogy a jelenlegi – Zend_Db-vel készült – modell struktúra enyhén szólva is kurva bonyolult és átláthatatlan. Mivel napi szinten benne voltam a modell karbantartásában és fejlesztésében ez szinte fel sem tűnt, de amikor bármi miatt módosítani kellett az egy rémálom volt. A javításról nem is beszélve. Eldöntöttük, hogy ideje nyugdíjazni a Zend_Db-t a projekt keretein belül és alternatíva után kezdtem kutakodni. Így került képbe a Doctrine, amit már jó ideje figyelemmel kísértem és konkrét tapasztalataim is voltak vele, de Zend Framework integrációval még sosem próbálkoztam. Találtam egy remek bejegyzést Eric Leclerc blogján Doctrine 1.2 is Zend Framework friendly címmel, valamint a zendcasts.com-on (Podcast) található egy screencast sorozat is a témában:

A Doctrine egy object relational mapper (meg sem próbálkozok a fordításával) amely tulajdonképp az adatbázis absztrakciós réteg tetején ül és integrálódik az OOP-s környezetbe. A parancssori interfész segítségével képes adatbázis sémákból php modelleket generálni (és vica versa), tesztadatok betöltésére vagy akár unit tesztelésre is. Szóval tényleg nagyon erős kis eszköz, igazán szerethető. A Symfony projekt is ezt használja például alapértelmezett ORM-ként a Propel mellett. Ami pedig a legszebb, hogy nagyon gyorsan megtanulható és üzembe állítható. Ezt mi sem bizonyítja jobban, mint az imént említett projekt, ahol a Zend_Db alapú modellek elkészítése több hétig tartott, a Doctrine migráció pedig mindösszesen egyetlen napig (bár az is igaz, hogy egy meglehetősen hosszú nap volt).

Lássuk, hogyan is történik ez integrálás a gyakorlatban. A standard Zend projekt fában a képen látható mappaszerkezetet kell létrehozni. A Doctrine projekt honlapjáról letöltött csomag lib könyvtárából másoljuk be a komplett Doctrine és vendor foldereket a projektünk library könyvtárába a Zend mellé valamint a doctrine.php-t szintén a library folderbe. Ezt követően az application.ini-ben kell némi konfigurációt elvégezni:

autoloadernamespaces[]      = "Doctrine_"
doctrine.connection_string  = "mysql://user:password@mysqlhost/dbname"
doctrine.data_fixtures_path = APPLICATION_PATH "/../doctrine/data/fixtures"
doctrine.models_path        = APPLICATION_PATH "/models"
doctrine.migrations_path    = APPLICATION_PATH "/../doctrine/migrations"
doctrine.sql_path           = APPLICATION_PATH "/../doctrine/data/sql"
doctrine.yaml_schema_path   = APPLICATION_PATH "/../doctrine/schema"
doctrine.generate_models_options.pearStyle              = true
doctrine.generate_models_options.generateTableClasses   = false
doctrine.generate_models_options.generateBaseClasses    = true
doctrine.generate_models_options.baseClassesDirectory   = null
doctrine.generate_models_options.classPrefixFiles       = false
doctrine.generate_models_options.classPrefix            = 'Model_'
doctrine.generate_models_options.baseClassPrefix        = 'Base_'

Majd a Bootstrap.php-ban kell a Doctrine-hez kapcsolódó initet elkészíteni, hogy az alkalmazás szintjén müködjön:

public function _initDoctrine()
{
    require_once 'Doctrine.php';
    $autoloader = Zend_Loader_Autoloader::getInstance();
    $autoloader->registerNamespace('sfYaml')->pushAutoloader(array('Doctrine', 'autoload'), 'sfYaml');
    $doctrineConfig = $this->getOption('doctrine');
 
    $manager = Doctrine_Manager::getInstance();
    $conn = $manager->openConnection($doctrineConfig['connection_string']);
    $conn->setCharset('utf8');
    return $manager;
}

Az application/cli_bootstrap.php-ba a következő kerül:

<?php
// Define path to application directory
defined('APPLICATION_PATH')
    || define('APPLICATION_PATH', dirname(__FILE__));
 
// Define application environment
defined('APPLICATION_ENV')
    || define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV') : 'production'));
 
set_include_path(implode(PATH_SEPARATOR, array(
    realpath(APPLICATION_PATH . '/../library'),
    get_include_path(),
)));
 
/** Zend_Application */
require_once 'Zend/Application.php';
 
// Create application, bootstrap, and run
$application = new Zend_Application(
    APPLICATION_ENV,
    APPLICATION_PATH . '/configs/application.ini'
);

Készíteni kell a projekt mappában egy scripts/doctrine-cli állományt a következő tartalommal:

#!/usr/bin/env php
<?php
define('APPLICATION_ENV', 'development');
require realpath(dirname(__FILE__) . '/../application/cli_bootstrap.php');
 
$application->getBootstrap()->bootstrap('doctrine');
$options = $application->getOption('doctrine'); 
 
$cli = new Doctrine_Cli($options);
$cli->run($_SERVER['argv']);

Majd futtathatóvá kell tenni. Ez lesz a parancssori interfész amelyen keresztül utasításokat lehet adni az ORM-nek. Ezzel a Doctrine teljesen beágyazódik a Zend Frameworkbe és a projekt honlapján lévő dokumentációk alapján már lehet is gyártani a szebbnél szebb modelleket és tolni a kódból a DQL-t :)

, , , , , — Nincs hozzászólás
2009
30
dec

iCacti – Szerver monitorozás iPhone-on

iCacti

Újabb példánnyal bővült a Webin névvel fémjelzett alkalmazások köre az AppStore-ban, ami azért meglepő mert alapvetően webes fejlesztésre orientálódtam. Tegnap hagyta jóvá az Apple az iCacti nevű alkalmazásomat (iTS link), amely kevesebb mint 24 órát várakozott a queue-ban mielőtt megkapta a ‘Ready for Sale’ státuszt. Ennek a hátterében vagy az van, hogy az Apple személy szerint nekem szeretett volna kedvezni – bár ennek nagyon örülnék azért mégsem tartom túl valószínűnek – vagy pedig valami történik a háttérben és egyszerűen felgyorsult a jóváhagyási procedúra. Ez utóbbit megerősíti az is, hogy a tegnap beküldött 1.2-es verziószámú EventList frissítés néhány óra alatt ‘In Review’ állapotú lett (erre korábban ~1 hetet kellett várni).

icacti_history

Korábban is tettem már említést a Cactiról (itt és itt) ami egy webes rendszer monitorózó megoldás. Az elmúlt évek során jól megismernem és nagyon megszerettem. Nem igazán találtam még ehhez hasonló webes szerver monitorozó eszközt ebben az árfekvésben (nem az ingyenességre gondolok). Talán a Munin ami még hasonló képességekkel bír, de az nekem egy kicsit fapados a Cactihoz képest.

Gyakran böngészgetem a szerver állapotát megjelenítő grafikonokat, hogy az automatikus riasztásokon túl az esetleges rendellenességekről, terhelésről időben értesüljek és ha szükséges még időben lépni tudjak. iPhone-on ez a tevékenység kicsit körülményes. Reggelente, a rutinfeladatok elvégzése közben szoktam megejteni a szerver ellenőrzését és – bár minden funkció tökéletesen működik a mobil Safarival – mégsem túl kényelmes azt használni amikor gyors áttekintést szeretnék kapni az aktuális állapotról. Ezért merült fel bennem egy natív iPhone alkalmazás elkészítésének a gondolata, amely képes kapcsolódni a Cacti szerverhez és az ott tárolt információkat megjeleníteni a telefonon. Az iCacti pont ezt tudja, se többet, se kevesebbet. Megjeleníti a monitorozott szerverek állapotát (up, down, maintenance), az uptime-ot százalékosan és természetesen a grafikonokat (amelyeknél beállítható, hogy mely időintervallumból gyűjtse le az adatokat). A telefont “elfektetésével” pedig nagyobb méretben lehet böngészni.

Kijelenthető, hogy ez az alkalmazás egy szűk felhasználói réteg igényeit elégíti ki, de azoknak – akik Cacti és iPhone használók is egyben – ez egy hiánypótló megoldás lehet. Elvégre pont azért készült.

, , , , , — 7 hozzászólás
2009
24
nov

BetStock: Második nekifutásra

iPhone_Planning

Még az EventList előtt küldtem be jóváhagyásra a BetStock nevű iPhone alkalmazásomat, ami tulajdonképp egy tőzsdei árfolyamfigyelő és portfóliókezelő program. 5-6 nap várakozás után “In Review” státuszba került az AppStore jóváhagyó gépezetében. Kalkulációim szerint 2-3 nap múlva lett volna esedékes a jóváhagyás.

A kalkuláció helyesnek bizonyult, azonban a programnak nem sikerült átverekednie magát a boltba mivel elutasításra került. A programot elemző szakember azt kifogásolta, hogy internetkapcsolat hiányában a program nem jelzi a felhasználónak, hogy szüksége volna internetelérésre az adatok frissítéséhez. Ez megzavarhatja a felhasználót és nem illeszkedik az iPhone Human Interface Guidelines-ban megfogalmazottakra ezért ezt a “hibát” javítsam.

A hibajavítás kb. 5 perc alatt meg is történt. Lementek a tesztek és minden az elvártaknak megfelelően működött, így a javított binárist ismételten a jóváhagyás rögös útjára eresztettem. A procedúra újraindult és ismét “Waiting For Review” állapotba került a program. Második nekifutásra már mindent jónak találtak és a BetStock ma éjszaka – magyar idő szerint – éjfél előtt néhány perccel jóváhagyásra került és megjelent az AppStore-ban.

Nagyon fontos megemlítenem, hogy a program ikonja Benke Zsolt keze munkáját dicséri. Volt olyan rendes, hogy felajánlotta a segítségét az ikon elkészítésében. Én elmondtam neki, hogy nagyjából mit szeretnék, majd nem sokkal később jelentkezett az elképzelés első-, majd nem sokkal később a második verziójával. Ezeket követte a jelenlegi verzió ami a végleges alkalmazás ikonja lett. Véleményem szerint @wyctim szuper munkát végzet így ezúton is big respect neki!

Végezetül, azt hiszem nem árulok el nagy titkot azzal, hogy további fejlesztések is vannak folyamatban, bár állandóan küzdök az időhiánnyal. Másodállásban, délutánonként és éjszakánként jutok oda, hogy az iPhone fejlesztésekkel foglalatoskodjak, ez pedig gyakran éjszakázással jár, ami 8-10 óra PHP után nem mindig fenékig tejföl, de furcsa is lenne már ha egyszer kipihenten ébrednék :)

← Régebbiek