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

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.

, , , , — Nincs hozzászólás
24
jan 10

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
30
dec 09

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
24
nov 09

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 :)

, , , , , — 3 hozzászólás
20
nov 09

EventList: Ready for Sale

eventlist

Nemrégiben elkezdtem kóstolgatni az iPhone alkalmazásfejlesztés alapjait, majd annyira belejöttem, hogy össze is dobtam 2 alkalmazást amit az AppStore-ba szántam. Kicsit félve indultam neki az egésznek. Korábban elég rossz tapasztalatokat szereztem az Objective-C/Cocoa fejlesztés háza tájáról, nem igazán tetszett az Obj-C “kitekert” szintaktikája, a kilométer hosszúságú metódusnevek és hasonlók. Most, hogy csak az iPhone-ra fókuszáltam és konkrét célokat fogalmaztam meg a tanulási folyamat során sokkal kellemesebb tapasztalatokat szereztem és mostanra bátran merem állítani, hogy fekszik nekem az Obj-C és a Cocoa framework, jó barátok lettünk, megszerettük egymást.

Aggasztott kicsit az a rengeteg negatív kicsengérű hír amit az Apple jóváhagyási procedúrájáról és úgy általában az iPhone Developer Programról hallani lehet, de úgy tűnik eddig szerencsém volt. Az iPhone Developer Program jelentkezésemet bruttó 2 nap alatt fogadták el. Erről hallottam, hogy sok esetben több hétig tart, sőt hónapos várakozásról és hosszas adategyeztetésről is suttogtak a neten. Nem tudom, hogy szerencsém volt-e vagy csak szimplán javultak azóta a folyamatok, de a bruttó 2 nap teljesen elfogadható volt. Majd jött a jóváhagyási procedúra ami már legendásan hírhedtté vált a sok értelmetlen indokkal elutasított alkalmazással és a hosszú várakozással. Szeretném azt hinni, hogy nagyon szerencsés vagyok, hiszen az első alkalmazásom 9 nap alatt jóváhagyásra került. Valójában azonban lehet sejteni, hogy nem szerencséről van itt szó, hanem az Apple igyekszik felgyorsítani a jóváhagyási folyamatot a rengeteg kritika hatására.

A rövid kis kitérő után pedig a lényeg, hogy magyar idő szerint ma hajnalban (cupertinoi idő szerint tegnap délután fél négykor) “Ready for Sale” státuszba került az első iPhone alkalmazásom, az EventList és néhány órával később megjelent az AppStore-ban is. Ez egy egyszerű névnap alkalmazás, amely 16 ország névnapjait ismeri és a “beépített” névnapokon túl saját eseményekkel is (születésnapok, évfordulók, ünnepek stb.) bővíthető a lista.

Rövid időn belül várható további alkalmazások élesedése is az AppStore-ban, de azokról majd akkor…

A Webinhez kapcsolódó fejlesztéseknek a szerző egy külön twitter fiókot nyitott @webindev néven, ahol nem túl nagy intenzitással, de folyamatosan mikroblogolja az eseményeket. Tessék hát őt is követni, de izibe’!

← Régebbiek