• Minden hibátlanul működik, semmit nem kellett állítgatnom, mindent hibátlanul átvett a leo-tól.
• A gép gördülékenyebben hajtja végre a feladatokat, tényleg érződik az a sebességelőny amiről annyit írtak a marketingesek.
• Annak ellenére, hogy a processzek több mint fele 64 biten fut, több szabad memória marad!

Egyébként ilyet még eddigi kb 20 éves számítástechnikai előéletem alatt nem tapasztaltam. Mármint, hogy egy új oprendszer telepítőjét a régire ráeresztve: kapok 6 Gb szabad helyet (tényleg!), gyorsul a rendszer (legalábbis a reakcióideje – nincsenek érthetetlen homokórázások, zökkenések, beragadások), minden flottul működik nem kellett semmit sem “utánhackelni”.

Ezt az oprendszert tényleg összerakták, kár azért a majd’ két évért, amit vártunk rá.

Az első az AppCleaner nevű kis program.

MacOSX alatt pofonegyszerű egy alkalmazást telepíteni/leszedni. Akkor van gond, ha a letörölt program belekotorászott más mappákba is. Ilyenkor törlés után azok a fájlok ott is maradnak. Emiatt néha elég komoly mennyiségű “szemetet” hagyva a mindig szűkös merevlemezen.

Na ekkor jön az AppCleaner: kikeresi a letörlendő alkamazás kapcsolódó fájljait és azokat is kidobja a kukába. Viszont ezt nagyon kényelmesen csinálja, ha bekapcsolom a SmartDelete-et. Ekkor elindít egy háttérben futó kis daemon-t, ami minden törlést ellenőriz. Ha alkalmazást fedez fel, akkor feldob egy ablakot, hogy: “Helló, ezeket találtam még, töröljem?”. Szóval nem kell minden egyes alkalmazás törléskor elindítani az AppCleaner-t, hogy azon keresztül töröljem le azt a – gyakran egy darab – alkalmazást, automatikusan megoldja a dolgot. Igencsak ötletes és kényelmes. Tetszik!

A második okosság a Screen Sharing.

Ez már régóta benne van az OSX-ben, de Tiger alatt csak megosztani lehet a képernyőt, kliens alkalmazást nem tartalmaz a rendszer. (Külön megvehető Apple alkalmazás kell: Apple Remote Desktop. Nem is értem miért… mondjuk az is igaz, hogy mivel VNC alapú az egész, ezért egy VNC kliens is megteszi.) Leopard óta van “beépített” kliens is, mégpedig igencsak kényelmes módon, rögtön a Finder-ből elérhető. Én azt a kombinációt próbáltam, hogy a Tiger-t futtató MacBook-on bekapcsoltam az ott még Apple Remote Desktop-nak hívott Screen Sharing-et (System Preferences/Sharing) és megadtam milyen authentikációval lehessen rákapcsolódni. Ezek után Leopard alatt a Finderben a Shared listában meg is jelent a gép, kiválasztva pedig ott virított a Screen Sharing gomb is, amire bökve már bent is voltam a MacBook-omban. ÍÍÍzi!

(Zárójelben: A Screen Sharing kliens alkalmazás Leopard alatt külön is futtatható a /System/Library/CoreServices mappából. Ez akkor jön jól, ha a másik Mac nem látható a belső hálón, de IP alapján elérhető.)

A PDT megjelenése elég sok változást hozott a PHP fejlesztők életében. Az első verzió ugyan csak arra volt jó, hogy Eclipse környezetben is lehetett “normálisan” PHP kódot írni. Az igazi áttörés akkor történt, amikor megjelent az első olyan verzió, ami már teljesen támogatta a Zend Debugger-es remote debugging-ot. (Böngészőből indítható debug-ot.) Eddig ezt csak a – fizetős Zend Platform részévé váló, majd onnan kikerülő Zend Debugger-rel és a szintén fizetős – Zend Development Studio keretén belül lehetett megoldani. Úgy tűnik ez most már lassan a múlt homályába vész és végre lesz egy teljes értékű, ingyenes PHP debug megoldás a jól működő ingyenes PHP IDE (PDT) mellé… illetve úgy tűnik már van is!

Az első XDebug-ot támogató PDT-vel az volt a baj, hogy valami miatt lefogta az egész processzort és eléggé hektikusan működött: néha nem indult el a debug, néha ehhez újra kellett indítani az egész Eclipse-et. Emiatt hanyagoltam is az XDebug-ot, helyette bevetettem az időközben megint ingyenesen elérhető Zend Debugger-t.

Pár napja láttam, hogy a PDT-ből kiadták az 1.0.3-as verziót és nem olyan régen megjelent az XDebug 2.0.3-as verziója is. Hirtelen ötlettől vezérelve be is frissítettem őket (biztos nem véltlen, hogy 3-as végződik mindkét verzió, ugye…) és meglepődve tapasztaltam, hogy az XDebug procit felzabáló hajlama eltűnt, a PDT szépen tudja indítani a debug session-öket, minden flottul működik. Na ezen felbuzdulva gyorsan leírtam, hogyan is jutottam el ebbe az idilli állapotba:

Alapfeltevés: Van egy Apache alá installált PHP, fut az Eclipse-ben a PDT. Mindkét előfeltételre rengeteg doksival szolgál a Googel keresője.

1. Fel kell rakni az XDebug bővítményt PHP alá. Ennek egyik legegyszerűbb módja (ha Linux vagy MacOSX alatt vagyunk), hogy a PECL csomagkezelővel szépen befordíttatjuk. Erről van egy szép doksi az XDebug oldalán is, de röviden ezt kell begépelni a konzolban:

   pecl install xdebug

   Win alatt van bináris verzió, amit csak be kell másolni a PHP könyvtárába.

2. A php.ini-ben be kell olvastatni a lefordított xdebug modult és be kell kapcsolni a remote debug fícsört:

   zend_extension=/Library/PHP5/lib/php/extensions/no-debug-non-zts-20060613/xdebug.so
   xdebug.remote_enable=1

   Windows alatt is ez kell, csak .dll a fájl kiterjesztése.

3. Eclipse-ben be kell állítani egy debug konfigurációt, ehhez kell, hogy legyen egy PHP projekt, amire majd tudunk hivatkozni.
   • 
   • 
   • A bal fölül levő “New launch configuration”-ra kell kattintani, majd a megjelenő ablakban a Server fülön beállítani a következőket:
     • Server Debugger: XDebug
     • File: belapozni egy PHP projekten belül egy php fájlt, ami az indulási oldala lesz ennek az egész indítási konfignak
     • Auto Generate: ellenőrizni, hogy jó url-t rakott-e össze a PDT, ha nem, akkor kiszedni a pipát és kézzel javítani!
   • Advanced fülön:
     1. Start Debug from: beírni ide is azt az url-t, amit az előző fülön, ha vlami miatt mégsem az jelenne meg.
     2. Pipát rakj a “Continue Debug from This Page” elé, így a PDT nem bontja a kapcsolatot az XDebug-gal a megadott url letöltése után.
   • Common fül:
     1. Itt csak azt érdemes bepipálni, hogy a most összerakott launch config szerepljen-e a debug fav.-ok között.

Ezek után mehet egy Apply és ha minden jó, akkor a Debug gombra kattintva a PDT elindítja az Eclipse-ben beállított böngészőt a megadott url-lel (kiegészítve az XDebug session indításával).
Helyezz el breakpointokat és láss csodát, a következő oldal letöltésekor (a böngészőben lehet nyomkodni a linkeket, tölteni az újabb oldalakat) a PDT életre fog kelni, ha a program futása eléri a beállított breakpointot.

Innentől kezdve a PDT debug perspektívájában lehet nézelődni: látszódik a hívási verem, az elérhető változók, sőt a változók értékei módosíthatóak is!

Mindenkinek jó szórakozást hozzá!

• Firefox 2.0.0.11: 20643.0ms
• WebKit: 2767.6ms
• (Safari 3.11: 4390.6ms)
• (Opera 9.5: 7907.8ms)
• (UPDATE: FF3: 4274.6ms)

Akkor ezek szerint a WebKit 7,46x gyorsabb JavaScript futtatásban. Impresszív!

Gondolom Google tele van már ilyen tesztekkel, de jó látni, hogy egymásra licitálnak a “kis” böngészőgyártók. Várom a FF3-at jövő héten! A FF3 partiban van a legújabb Safarival! Igazán szép eredmény!

Múlt héten nézegettem a screencast-eket az RC2-es verzióról és tetszetősnek tűnt az új Dashboard, a szerkesztő, meg az egész kipolírozott admin felület. Így aztán nem sokat gondolkodtam az új verzióra való frissítésen, amint megláttam, hogy megjelent le is töltöttem és egy szinte fájdalommentes upgrade után be is üzemeltem.

Tényleg nagyon jó lett az új Dashboard és az egész admin felület, szép, következetes, átgondolt. Tetszik!

Sajnos a TinyMCE Advanced plugin nem működik még ezzel a verzióval, ami nem lenne olyan nagy baj, mert egész szépen átdolgozták a szerkesztőt is, de mivel az általam használt design “széles” és a beépített szerkesztő szinte minden CSS definíciót átvesz, ezért a szerkesztő rész rálóg a legfontosabb panelre. Emiatt nem tudom Visual módban menteni és publikálni a bejegyzéseket. Ezen segíthetne a TinyMCE Advanced plugin, mert ott meg tudom adni azokat a css osztályokat, amiket nem kérek a szerkesztőben. Remélem az elkövetkező pár hétben javítják ezt a dolgot és akkor minden szép is lesz. (Árgus szemekkel figyelem a Trac ticketeket.)

Kipróbálásra melegen ajánlom az új WordPress-t, látványosan nem csak egy ráncfelvarrás.

Hivatalos bejelentés: WordPress 2.5

Amint lesz még több tapasztalatom ezzel a verzióval (és persze lesz időm) nyomom tovább az infókat, mára ennyire futotta.

Jóéjet!

Ez így ment nagyjából 6 évig, amikor is végre megjelent a színen az új királyfi, az Internet Explorer 7. Ő úgy gondolta, hogy ez alatt az idő alatt annyit fejlődött már a ClearType^(tm), hogy igazán kikényszerítheti, mint alapértelmezett élsimítási technikát. Ki is kényszerítette minden esetben, hiába kértem pp. rendszer szinten ennek az ellenkezőjére, neki ez nem számított, beborított a homállyal.

A ClearType^(tm) valójában egy szóvicc, fekete humor… A ClearType^(tm) kifejlesztésében a világ összes optikusát és szemészorvosát tömörítő ördögi szervezet játszhatta a főszerepet. Garantáltan valamiféle látásromlást eredményez már rövid használata is. Tessék kipróbálni: olvass egy pár percig ClearType^(tm)-mel megjelenített szöveget, majd nézz el a monitorról, a szemed előtt hangyák rohangálnak majd és úgy érzed valami álomból ébredtél éppen.

Az IE7 nem adja könnyen magát, 6 év megfeszített munkájával sikerült megőrizni az IE6 szinte teljesen átláthatatlan internet beállítások menüjét. Élmény, hogy egy új szoftver őrzi elődei hibáit, a nem működő evolúció ékes példáját szolgáltatva. (Amerikában az emberek több mint fele úgysem fogadja el Darwin evolúció-elméletét.) Tehát ha ki szeretnéd kapcsolni a ClearType^(tm)-et, a következő helyen kell keresned:

Pár teljesen logikus érv, hogy itt keressem ezt a “fícsört”:

• Ha megadom op. rendszer szinten, hogy nem szeretném hasznélni a ClearType^(tm)-et, akkor persze ez nem jelent semmit, mert bármelyik alkalmazás felülbírálhatja.
• A böngészést befolyásoló paramétereket mindig egy “Speciális” nevű menüpont alatt kell keresni.
• A “Speciális” nevű menüpontban természetesen mindent egy listában kell felsorolni és ez a lista legalább 50 elemből kell álljon.
• A menüpontot tartalmazó ablak átméretezését le kell tiltani, nehogy el lehessen olvasni a jó hosszú és nehezen átlátható listaelemeket.
• A lista elemeit véletlenszerűen kell csoportosítani, a ClearType^(tm) egy kifejezetten NEM multimédiás opció.

Persze az egész dologgal nem lenne semmi gond, ha az elmúlt közel 7 év alatt a Microsoft-nál eljutottak volna a ClearType^(tm) 2.0-ig, ami teljesen új alapokat használna a szép élsimított karakterek megjelenítésére.

Egy rögtönzött összehasonlítás (balra az IE7 WinXP-vel, jobbra egy Navigator 9 MacOSX alatt):

Ingyenes DOMExplorer a Microsoft-tól! Nagy segítség ez, amikor azon bosszankodom, hogy miért nem jelenik meg rendesen a weboldal IE7 alatt. Sajnos csak DOMExplorer, javascript debugra még mindig nem tudok semmi épkézláb megoldást. Marad a Firebug lite.

A cucc teljes neve Internet Explorer Developer Toolbar.

		// Caching can be turned off
		$this->enable_cache = $enable_cache;

		// $MAGIC1 = (int)0x950412de;
		//bug in PHP 5.0.2
		//see https://savannah.nongnu.org/bugs/?func=detailitem&item_id=10565
		$MAGIC1 = (int) - 1794895138;
		// $MAGIC2 = (int)0xde120495; //bug
		$MAGIC2 = (int) - 569244523;
		// 64-bit fix
		$MAGIC3 = (int) 2500072158;

		$this->STREAM = $Reader;
		$magic = $this->readint();

		// to make sure it works for 64-bit platforms
		if ($magic == $MAGIC1 || $magic == $MAGIC3) {
			$this->BYTEORDER = 0;
		} elseif ($magic == ($MAGIC2 & 0xFFFFFFFF)) {
			$this->BYTEORDER = 1;
		} else {
			$this->error = 1; // not MO file
			return false;
		}

Biztos, ami biztos alapon, ide:gettext.php rakom a patchelt fájt is, csak írjátok felül a wp-includes-ban levőt.

Elkezdtem debug-olni. Első gyanúm, hogy valamit elcsesztem, tehát újra leellenőriztem minden telepítési lépést, de semmi. Aztán olvasgatni kezdtem a WordPress lokalizációs lehetőségeiről. Kiderült, hogy a népszerű gettext-et használja a fordítások kezelésére. Átnéztem a szerveren futó PHP-t, amin van gettext bővítmény, működik is. Akkor mi lehet?

Következő lépésként felraktam a saját gépemre is egy WordPress-t, beraktam a fordítást és minden ment szépen. Itt derült ki számomra, hogy nem is kell, hogy a PHP rendelkezzen a gettext bővítménnyel, mivel a WordPress egy PHP-ban megírt osztályt használ ennek kiváltására: PHP-gettext. Akkor elő a debuggerrel, nézzük hogyan jut el a fordításban szereplő szöveg a felhasználóhoz. Hosszú-hosszú hibakeresés következett, de végül minden ötletem kudarcba fulladt, a szerveren lévő WordPress sehogy sem jeleníti meg a fordítást.

Ekkor kezdtem a fordítási fájlt feldolgozó függvényekre koncentrálni, mivel az tisztán látszódott, hogy a fájl bekerül a memóriába, de a szövegeket a PHP-gettext nem tudja kiszedni. (A fordításokat tartalmazó fájl bináris.) Mivel nem akartam teljesen megérteni a PHP-gettext bináris feldolgozó eljárásait, megint jött a google és eljutottam a WordPress Trac changelog-jába, ahol a 4003-as revízióban érdekes dologra bukkantam. Ezek szerint a 64 bites gépeken nem tudja rendesen felolvasni a fordítási fájlt a WordPress-ben levő PHP-gettext. Elvileg áttértek az 1.07-es verzióra, ami ezt a hibát is javítaná, mégsem működik. Ekkor döntöttem úgy, hogy nem szarozok, kézzel befrissítem a PHP-gettext-et és CSODA történt! Megjelent a magyar fordítás!

Tehát aki hasonlók miatt szenved:

1. töltsd le a PHP-gettext legújabb verzióját
2. tömörítsd ki
3. lépj fel a szerverre, készíts biztonsági másolatot a wp-includes/gettext.php és a wp-includes/streams.php-ról
4. a kitömörített könyvtárból másold át a szerverre a gettext.php-t és a streams.php-t a wp-includes könyvtárba, felülírva a régieket
5. ha még nem csináltad meg a nyelvi fájl telepítési lépéseket, akkor tedd meg
6. kész vagy!

Nem tudom, hogy 100%-ban bugmentes-e a megoldás, de rövid tesztelés során, csak az admin felületen a Dashboard-on tapasztaltam némi hibát. Máshol minden ok. Elkezdem pedzegetni a kérdést a WordPress fejlesztőinél, kíváncsi vagyok mire jutok.

Először persze furcsa volt, hogy eltűntek a mappák, hiányzott a címkék hierarchiába szervezése. De kárpótolt a gyors működés, a letisztult felhasználói felület, a gyakorlatilag végtelen kapacitás (végtelen, mivel folyamatosan növekszik, nemrég szinte meg is duplázták nagyjából 4,7 gigára), a szinte szünetmentes működés és a profi keresési funkciók. Aztán persze jöttek a tweak-ek greasemonkey szkriptek formájában: GMail+Reader, GMail Label Colorer, GMail unlabelled. Ezek mind segítették a munkámat, de összességében nem adtak sok pluszt a GMail-hez. Aztán összefutottam a GTDInbox-szal és ha nem is rögtön, de szépen, fokozatosan minden megváltozott.

A GTDIndbox egy Firefox add-on, ami a letöltött GMail oldal tartalmát tweak-eli fel, ahogy ezt a greasemonkey szkriptek is teszik. Tehát jelenleg csak Firefox alatt érhető el, illetve még csak a régi GMail felületen. Utóbbi lassan változni fog – ha hinni lehet a fejlesztőknek – de időpontról egyelőre nincs semmi konkrétum.

Mi is az a GTD?

Lexikonszerűen: Getting Things Done rövidítése, magyar megfelelőjéről nem tudok. Alapvetően egy olyan egyszerű módszerről van szó, amivel könnyebben tudjuk szervezni a munkánkat és az életünket. Ahelyett, hogy nekiesnék leírni, hogy mi ez a GTD, inkább pár link:

Magyarul:

• http://nyenyec.blogspot.com/2007/07/knyv-getting-things-done.htm
• http://gaba.lenard.hu/category/getting-things-done/

Angolul:

• http://en.wikipedia.org/wiki/Getting_Things_Done
• http://zenhabits.net/2007/06/the-getting-things-done-gtd-faq/
• http://www.minezone.org/wiki/MVance/GettingThingsDone

Mit ad a GTDInbox a GMail-hez?

Elsőre nem tűnik többnek, mint egy kis ráncfelvarrás a felhasználói felületen. Pár új menüpont, a címkék csoportokba tagolódnak, levél olvasáskor könnyebben rakhatók fel-le a címkék, új keresést segítő select-box, stb… Aztán amikor kezded felfogni, hogy mi is az a GTD és hogyan segíti a napi munkádat, akkor jössz rá, hogy a GTDInbox rendkívül jó segítőtárrsaddá válik.

Én gyakorlatilag nulla GTD tudással estem neki a GTDInbox használatának. Elolvastam az oldalukon található bevezetőt, de első körben csak a felturbózott GMail felület tetszett meg. Aztán szép lassan egyre több infót gyűjtöttem be a GTD-ről és kezdtem tudatosan használni a GTDInbox lehetőségeit. Mai napig nem tudok sokat a GTD-ről, de a GTDInbox szinte teljesen hozzánőtt a napi munkámhoz.

Mindenképpen érdemes kipróbálni, ha másért nem, hát az ötletes tweak-ek miatt.