‘Szoftver’ címkével ellátott bejegyzések

Traffic Rush

2011. szeptember 2. péntek

Van egy több éves, Traffic Rush nevű forgalomirányító játék iPhone-ra, melybe valamikor az utolsó frissítések alkalmával belekerült egy új játékmód is, ahol már nem csak autókat, hanem vonatokat is lehet irányítani.

Ha valaki csak frissítette a szoftver és nem indította el már jó ideje (így jártam én is), akkor az nézzen bele, érdemes. A Classic változattal ellentétben itt kaphatunk néhány bónuszpontot – feltéve ha a vonatok irányítása mellett még tudunk másfelé is figyelni. 🙂

Tetszik, hogy nem külön adták ki a játékot Rail Rush néven, hanem a már korábban megvásárolt szoftverbe került bele új menüpontként.

A játék amúgy nem drága, $0.99 kérnek érte. Akinek esetleg még nincs meg és érdekelné, az itt tudja letölteni.

Tipp PHP-s hibakereséshez Mac és Linux alatt

2011. szeptember 1. csütörtök

Biztosan minden webfejlesztőnek megvan a maga kis megoldása – a fejlesztés mondhatni legutálatosabb részéhez – a hibakereséshez. Ennek ellenére biztosan lesznek azért olyan olvasói is ennek az írásnak, akiknek segíteni tudok az itt leírtakkal.

Ebben a bejegyzésben arról lesz szó, hogy hogyan tudjuk a különböző, PHP kódok futtatása alatt keletkező adatokat, információkat, üzeneteket a böngésző ablaka helyett egy egyszerű egy naplófájlba kiírni, valamint hogy hogyan tudjuk ezt a fájlt megtekinteni.

Lássunk is neki: nyissuk meg a parancssort és hozzuk létre egy naplófájlt erre a célra (természetesen az elérési út is és a fájlnév is lehet tetszőleges):

touch ~/Sites/webdev.log

Ezzel létrehoztuk a naplófájlunkat. Ezek után nincs más dolgunk, mint elindítani a /Applications/Utilities/Console.app nevű programot, majd azzal megnyitni a fent létrehozott fájlt. A Console.app folyamatosan mutatja (és frissíti) a fájl tartalmát, így azt valós időben láthatjuk.

Akik a Terminal használatához vannak inkább szokva, vagy akik valamilyen Linuxot használnak, a Console.app helyett használhatják a parancssort, ahova a következőket kell beírni:

tail -f ~/Sites/webdev.log

A fenti parancs gyakorlatilag ugyanazt csinálja, mint a Console.app, így pusztán megszokás kérdése, hogy ki melyiket használja. Én azért szeretem inkább a Terminalt használni, mert az egyrészt általában amúgy is nyitva van már, másrészt pedig kevesebb helyet foglal az asztalon, mint a Console.app.

Egy apró megjegyzés: Mac-en és Linux alatt általában az alábbi könyvtárban találhatjuk a logfájlokat: /var/log

PHP kód a naplófájlba íráshoz

PHP-s fejlesztéseknél használom ezt a megoldást, de természetesen nem csak és kizárólag PHP alatt használható. Minden esetre én most közzéteszem az általam írt és használt néhány soros PHP függvény egyszerűsített változatát, ami kiírja az imént létrehozott fájlba a tartalmat:

<?php
function trace( $msg ) {
  $logfile = ‘webdev.log’;
  $msg = date( ‘M d H:i:s’, mktime() ) . ‘ ‘ . $msg . “\n”;
  if ( is_writeable( $logfile ) ) {
  $fp = fopen( $logfile, ‘a+’ );
    if ( $fp ) {
      if ( fwrite( $fp, $msg ) === true ) {
        $content = fread( $fp, filesize( $logfile ) );
        fwrite( $fp, $content );
      }
      fclose( $fp );
    }
  }
}
?>

Nekem ez az egész csak annyiban különbözik a fent bemutatott változattól, hogy van benne még egy plusz feltétel az elején, így a beállításoknál tudom szabályozni, hogy lefusson-e a függvény, vagy sem.

A rend kedvéért azért még leírom a használatát az unalomig ismételt „Hello World!”-el, bár aki ezt a fenti néhány sorból nem érti, az valószínűleg nem is nagyon fog hibákat keresgélni…

trace( ‘Hello World!’ );

A végeredmény pedig valami hasonló lesz a parancssorban és a Console-ban:

Megéri az elején ezt a néhány percnyi időráfordítást, mert utána nagyon megkönnyíti a fejlesztés alatti hibák keresését és nem utolsó sorban sokkal elegánsabb megoldás az ilyen dolgok logfájlba való küldése, mint az, hogy a böngészőben a tartalom közé küldi ki a PHP a fejlesztéshez / debug-hoz szükséges – csak számunkra fontos – információkat.

A Mac OS X ereje

2011. augusztus 14. vasárnap

Több, mint 73 nappal, 6 órával és 31 perccel ezelőtt kapcsoltam be a Mac-et. Most viszont eljött az ideje az újraindításnak, mert már jó ideje ott figyeltek az újraindítást is igénylő frissítések a Software Update ablakban. Ha jól rémlik, akkor Debian alatt valamivel több, mint 250 nap volt az eddigi uptime rekord (parancssoros környezet, web- ill. FTP szerver), Windows alatt pedig valami 2 hét körüli időre emlékszem.

A Mac-et ha nem használom, akkor csak sleep módba teszem, ahogy talán a legtöbb Mac felhasználó. Nagyjából 2 másodperccel az Apple menü Sleep menüpontjára való kattintás után már alszik is és kb. ugyanennyi időre van szüksége, hogy az óránként néhány wattot fogyasztó alvó állapotból felébredjen és az összes ablakot a tartalmával együtt a sleep előtti állapotban lássam viszont. Ez főleg akkor hasznos, ha előre láthatólag valamiért hosszabb ideig nem vagyok gépközelben (ez nálam azt jelenti, hogy kb. 20-30 percnél tovább).

Többen kritizálták már a sleep módban történő árampazarlást, de azt sokan nem tudják, hogy ez a fogyasztás ilyenkor minimális (tényleg csak néhány watt). Ha valakinél otthon egy órára véletlenül bekapcsolva marad a TV, akkor az gyakorlatilag több áramot elhasználhat, mint naponta egy Mac alvó állapotban…

Ahhoz pedig, hogy ennyi legyen az uptime, nem kell más, mint vagy egy kis szerencse (hogy hónapokig ne legyen áramszünet), vagy pedig egy szünetmentes tápegység – ahogy erről korábban már írtam is. Mondjuk a Security Update-eket sem a legjobb kihagyni, ezek viszont sajnos ilyen újraindítást igénylő dolgok.

Egyébként még mindig a Leopardot nyúzom és nem hiszem, hogy mostanában válatni fogok Snow Leopardra (pedig a polcon pihen egy az XMS-ből vásárolt páldány), Lionra meg főleg nem. Hiába számít réginek, vagy elavultnak a Leopard, egyelőre a stabilabb működést sokkal többre értékelem, mint a technikai újításokat. Természetesen, ha lenne egy valamilyen második Mac is a házban, akkor biztosan kipróbálnám a Liont, de így inkább egyelőre nem kockáztatom meg.

Gyorsan utána számoltam, hogy ha netán ismét uptime rekordot szeretnék dönteni, akkor mostantól kezdve nagyjából október végéig kellene mennie kikapcsolás és újraindítás nélkül. Ha pedig a következő 17 napban nem kell újraindítani, akkor elmondhatom magamról, hogy idén nyáron összesen csak két alkalommal kapcsoltam be a gépet… 🙂

Csoki Tools

2011. augusztus 1. hétfő

Ha egyszer megbarátkozunk a parancssorral, akkor lehet akár milyen csillogó-villogó operációs rendszerünk, időnként mégis vissza-vissza fogunk vágyni parancssoros módba, ahol ugyanazt a feladatot sokszor sokkal egyszerűbben és gyorsabban végezhetjük el, mint akármilyen GUI alatt. Az első lépést viszont ebbe az irányba – vagyis hogy megbarátkozzunk ezzel a felülettel – itt is magunknak kell megtennünk.

Már régebb óta szemeztem vele, korábban már le is töltöttem a wget és az mc csomagokat, csak mivel konkrétan nem kellettek eddig semmire, nem is telepítettem őket. A napokban viszont aktuális lett a dolog és úgy gondoltam, hogy megírom ezt a bejegyzést, hátha más is hasznát veszi.

Csokoládé Tools

A Csokoládé Tools oldala 2010. januárjában indult útjára. Az oldal azóta új dizájnt kapott és új helyre költözött, jelenleg a csokitools.tumblr.com címen érhető el. Bár én Linuxos környezetben az oldalon elérhető dolgok közül csak a wget-et és az mc-t használom rendszeresen, de a többi parancssoros szoftver is jól jöhet szinte bárkinek, különös tekintettel az egyszerűségre, a jó paraméterezhetőségre és nem utolsó sorban az ingyenességre.

A telepítés

A Csoki Tools oldal talán egyetlen hiányossága az, hogy a teljes telepítési útmutató csak a következőből áll: How to install: sudo unzip -d /usr/local [drag the zip file here]

Meggyőződésem, hogy egy kezdőt – aki eleve idegenkedik a parancssor használatatól – ez csak mégjobban elriaszt, hiszen egy hozzá nem értő ezzel a sorral semmit sem tud kezdeni. Persze nem sok esély van arra, hogy pont azok próbálják meg feltenni, akik amúgy sem értenek hozzá, de adjuk meg a lehetőséget azoknak is, akiknek ez jelenleg még gondot okozhat. Próbáljuk meg megszerettetni a parancssor világát azokkal, akik még nem ismerik, ugyanakkor érdeklődnek utána, viszont egyedül nem mernek belevágni, esetleg nincs kitől megkérdezni…

Úgy gondoltam, hogy az egysoros utasítás helyett inkább leírom azt a pár lépést, amit el kell végezni a fenti szoftverek használhatóvá tétele érdekében (nem kell megijedni az alábbi listától, nem olyan vészes, mint amilyennek látszik). Példának a wget-et fogom írni, de ez tetszőlegesen alkalmazható a többi csomagra is, csak ügyeljünk a terminal parancsok bemásolása vagy beírása közben a fájlnévre, esetleg az elérési utakra.

1.) Töltsük le a csokitools.tumblr.com oldalról a wget-et.

2.) Nyissuk meg a Terminalt, vagy egy tetszőleges alkalmazást, mellyel elérhetjük a parancssort. A bejegyzés további részében feltételezem, hogy a Downloads könyvtárba töltöttük le a fent említett csomagot.

3.) Írjuk be a parancssorba a következő parancsot (ezzel átmásoljuk a Downloads könyvtárunkból a /usr könyvtárba az imént letöltött tömörített fájlt):

sudo cp ~/Downloads/wget-1.12.zip /usr

4.) Ez után pedig csomagoljuk ki a tömörített fájlt úgy, hogy a benne lévő állományok egyből a helyükre kerüljenek:

sudo unzip /usr/wget-1.12.zip -d /usr

5.) Most töröljük az előbb átmásolt tömörített fájlt a /usr könyvtárból (csak a rend kedvéért):

sudo rm /usr/wget-1.12.zip

6.) Ennyi volt az egész. 🙂 Most már rendelkezésre áll a parancssorban az imént feltett alkalmazás.

A fenti csomagokat ellátták man oldalakkal is, melyek segítenek, ha nem lennénk képesek fejben tartani az összes kapcsolót és lehetőséget (már pedig nem vagyunk képesek). A man oldalak elérése a man <csomagnév> parancssal történik, tehát wget esetében: man wget

Ha elakadtunk, használhatjuk a <csomagnév> ––help parancsot is.

Lássuk egy példát, hogy mire jó ez a gyakorlatban

A napokban hirtelen szükségem lett egy olyan szoftverre, amivel egymás után tudom letölteni a megadott állományokat (a Safari a link Downloads ablakra húzásakor azonnal elkezdni letölteni a fájlt akkor is, ha már egy másik letöltés folyamatban van). Nekiálltam letöltésvezérlő szoftvereket keresgélni Mac-re, aztán a sok ronda GUI-val rendelkező, ill. a sok 20-25 dolláros szoftver között keresgélve beugrott, hogy ezt a wget is tudja. A wget-et pedig talán a legegyszerűbben úgy lehet Mac-re feltenni, hogy a Csoki Tools oldalról letöltjük és néhány karakter Terminálba pötyögésével már van is egy okos, ingyenes, jól paraméterezhető parancssoros szoftverünk a letöltésekhez. 🙂

Írok is egy példát a használatára, ami végtelenül egyszerű. A Downloads könyvtárba szeretnék letölteni egy szerverről mondjuk 3 db, 500 MB méretű fájlt. Választhatunk, hogy 1.) ott ülünk a Safari mellett és egyenként letöltjük őket, 2.) egymás után ráhúzzuk a Downloads ablakra a 3 db 500 MB-os fájlra mutató linket (nem túl elegáns megoldás, mert a Safari egyszerre kezdi el letölteni mindhármat), 3.) beszerzünk egy letöltésvezérlő szoftvert, vagy pedig 4.) egyszerűen a következő képpen leszedjük a fájlokat wget segítségével (az alábbi parancs valójában egy sorból áll):

wget -P ~/Downloads/ http://server.tld/file1.zip http://server.tld/file2.zip http://server.tld/file3.zip

A -P kapcsoló egy úgynevezett directory prefix, ami ebben az esetben azt jelenti, hogy segítségével megadhatjuk azt, hogy hova mentse a fájlokat. Ha nem használjuk ezt a kapcsolót, akkor a wget simán a home könyvtárunkba fogja letölteni a fájlokat.

Egyszerű ez, csak ne idegenkedjünk a parancssoros dolgoktól, helyette inkább bátran barátkozzunk meg velük… 🙂

Sweet Home 3D

2011. július 19. kedd

Nagyon jó kis szoftverre bukkantam az elmúlt héten egy ismerősöm jóvoltából. Van egy Sweet Home 3D nevű lakástervező és lakberendező szoftver melynek segítségével 2D-ben, bárki könnyedén megtervezheti meglévő vagy jövőbeli lakását (kb. ugyanúgy, ahogy egy milliméterpapíron), berendezheti a saját elképzelése szerint és tervezés közben már egyből 3D-ben láthatja a végeredményt. A 3D-s változat elforgatható és tetszés szerint tovább alakítható, módosítható.

A szoftver egyszerűen használható, többplatformos (tehát megy Windows, Mac és Linux-os környezetben is, ugyanis Java alapú), ingyenes, magyar nyelvű kezelőfelülettel is rendelkezik és mindössze 21.2 MB-os a Mac-es változata.

Ha mindez nem lenne elég érv valakinek ahhoz, hogy kipróbálja, akkor még megemlítek pár apróságot: a programban megtalálható dolgok mellett különböző 3D-s objektumok importja is megoldható (ágy, asztal, szekrény, autó, bármi) és ezeket valamilyen szinten textúrázhatjuk is. A különböző bútorok 3D-s változata (a szoftver egyébként OBJ, DAE, 3DS, LWS formátumokat támogat), letölthető az internetről, importálás után pedig csak meg kell adnunk a pontos méreteket, színt, esetleg textúrát és máris látni fogjuk, hogy hogy fér el az adott bútor a szobában és hogy azon a helyen hogyan mutat. Jó esetben valami ilyesmi lesz a végeredmény:

Töltsétek le és próbáljátok ki, nem fogjátok megbánni. Főleg akkor nem, ha a közeljövőben lakberendezésen töritek a fejeteket, vagy jobban érdekel benneteket a téma.

Egy kis kiegészítés: rengeteg ilyen előre elkészített, ingyenesen letölthető és használható modell található az interneten, érdemes utánuk nézni. Talán legegyszerűbb valamelyik keresőben rákeresni a „free furniture 3d models”, vagy hasonló kulcsszavakra.

A MySQL és a Mac OS X

2011. július 18. hétfő

Egy bejegyzés arról, hogy hogyan tudod használni Mac OS X alatt a MySQL-t (MAMP nélkül), ha a „gyári” telepítővel nem sikerült volna összehoznod a dolgot.

Régebben már próbáltam feltenni Leopard alá a MySQL-t, de mivel nem jött össze egyből és nem is volt rá túl sok időm, ezért akkor nem foglalkoztam tovább a dologgal. Szerencsére mindig volt és van a közelben néhány Linux alapú webszerver feltelepített MySQL-lel amit elérek, így nem volt annyira égető a kérdés. Aztán decemberben vásároltam egy Snow Leopard DVD-t, megpróbálkoztam a telepítéssel (nagyon negatív tapasztalat), de a szóban forgó adatbázis-kezelő az alatt sem jött össze. Bár nem a MySQL miatt, de pár órán belül visszatettem a Leopardot és folytattam mindent ott, ahol azelőtt (így gyakorlatilag lett egy teljesen újonnan telepített rendszer, ami alatt a MySQL még mindig nem akart működni).

Akik ismerik a Mac-et, azok tudják, hogy a világon talán Mac-re legegyszerűbb telepíteni bármit is. Az esetek 90%-ban megnyitjuk a .dmg fájlt, feljön egy ablak, ahol közlik velünk, hogy azt az egyetlen egy fájlt húzzuk az Applications könyvtárba és néhány másodpercen belül már indíthatjuk is a frissen telepített szoftvert. Bár néha azért előfordul, hogy parancssorban kell valamit kutyulni, de ezt egyrészt megszoktam Linux alatt, másrészt pedig nem szokott gondot okozni a parancssoros használat.

Néhány napja gondoltam egy merészet (hajnali három után néhány perccel) és kitaláltam, hogy most felteszem a MySQL-t, akármi is lesz a vége, vagy akármeddig is fog tartani. Olyan nincs, hogy nem működik rendesen. Hát tévedtem. Egy rosszul megírt alkalmazáson nem nagyon segít az, ha egy óra helyett ötöt töltünk el a telepítéssel és beállításokkal…

Mac-re – legjobb tudomásom szerint – kétféle képpen lehet feltenni a MySQL-t. Egyszer hagyományos módon fel kell telepíteni a mysql.com-ról letölthető „gyári” .dmg fájlt (csúnya kifejezés, de jelenleg nem tudok jobbat), majd a szükséges dolgokat be kell állítani. Ennek mérete (5.5.8-as MySQL) pedig kb. 82 MB-os. A másik módszer az, hogy feltesszük a MAMP-ot, ami szintén egy .dmg-ben tölthető le. Itt nem kell vesződni a beállításokkal és a MySQL mellé kapunk még jópár dolgot, viszont ez több, mint 160 MB-nyi helyet foglal (kicsomagolva több, mint 350 MB). Bár annak idején kipróbáltam a MAMP-ot, de úgy döntöttem, hogy mégegyszer nem teszek fel a gépre egy ilyen sok száz megás szörnyeteget, ne foglalja a helyet és az erőforrásokat.

Visszatérve a mysql.com-ról letölthető MySQL szerverre: a telepítéssel nincs gond, viszont a beállításnál már jobban oda kel figyelni, ugyanis az OS X alatt található Apache beállításaihoz képest a telepítő a socket fájlt teljesen máshova rakja, így eleve nem is nagyon működhet normálisan a rendszer. Aztán ha erre a logfájlok és/vagy az internet segítségével sikerült rájönnünk, akkor jön az, hogy a MySQL .dmg fájljában található MySQL.prefPane csak leállítani képes a mysqld-t, elindítani már nem (legalábbis nekem többszöri nekifutás után is ez volt a probléma). A MySQLStartupItem.pkg sem váltotta be a hozzáfűzött reményeket, így azt nem is tettem fel mégegyszer.

Tehát a lényeg, hogy socket fájlnak adjuk meg a rendes, valódi helyét az /etc/php.ini fájlban – ez a várakozásokkal ellentétben a /tmp/mysql.sock helyen található. Ezt írjuk is be a php.ini-be a következő helyre és a következő formában:

mysql.default_socket = /tmp/mysql.sock

Most adjuk ki parancssorban a

sudo apachectl restart

parancsot az Apache újraindításához, ezután pedig indítsuk el a MySQL kiszolgálót a

sudo /usr/local/mysql/bin/mysqld_safe

parancs beírásával. Most elvileg fut a mysqld. De hogy ne legyen minden ilyen egyszerű, ezért a leállítása sem olyan hétköznapi, mint Linux alatt:

sudo /usr/local/mysql/bin/mysqladmin –user=root -p shutdown

Nekem csakis a fenti módon hajlandó futni, a visszadobott hibaüzenetek számát pedig sikerült egyre redukálnom, a telepítés és beállítás több, mint 5, azaz öt órája alatt. Őszintén szólva el is ment a kedvem az OS X alatti MySQL telepítgetésektől egy jó időre…

Azért azt leírnám, hogy van olyan 2002-ben(!) írt fórumbejegyzés a neten, ahol kb. ugyanezekkel a dolgokkal küzdöttek. Magyarul kilenc év kevés volt a MySQL fejlesztőcsapatának ahhoz, hogy megváltoztassák a socket fájl default helyét és megoldják, hogy telepítés után egyből használni lehessen a MySQL-t ugyanúgy, mint sok ezer másik programot. Ezek után mindenki gondoljon ezzel kapcsolatban azt, amit akar…

Bonyolítsuk még picit, hogy később egyszerűbb legyen

Ha a telepítéssel és a beállításokkal megvagyunk és netán még a mysqld-t is sikerül elindítani / megállítani, akkor szánjunk még egy kis időt a további beállításokra, hogy később a kiszolgálót sokkal könnyebben tudjuk elindítani és leállítani.

Írjuk be a következő (valójában két sornyi) szöveget a felhasználói könyvtárunkban található .bash_profile nevű fájlba (erről bővebben az előző bejegyzésben olvashatunk).

alias mysql-start=”sudo /usr/local/mysql/bin/mysqld_safe”
alias mysql-stop=”sudo /usr/local/mysql/bin/mysqladmin –user=root -p shutdown”

Ezzel gyakorlatilag azt érjük el, hogy ha el akarjuk indítani a MySQL kiszolgálót, akkor elég lesz azt beírni a parancssorba, hogy mysql-start, a leállításához meg az, hogy mysql-stop.

A bejegyzésben említett telepítés Mac OS X Leopard (10.5.8) alatt történt, de gyaníthatóan 10.6 alatt is valami hasonló lesz a MySQL problémájára a megoldás. Minden esetre örülnék annak, hogy aki e bejegyzés alapján megpróbálja, az esetleg visszajelez egy komment vagy egy e-mail erejéig, hogy mire jutott.

Ha pedig valakinek ezek alapján sikerült életre keltenie a MySQL kiszolgálót OS X alatt, akkor egyet kattinthatna a tetszik gombra itt alul, mert nagy valószínűséggel épp most mentettem meg több órai szenvedéstől és felesleges próbálkozástól. 🙂

RockMelt, avagy a böngésző újragondolva

2011. július 4. hétfő

Hónapokkal ezelőtt próbáltam ki a RockMelt – akkor még – béta változatát, ami annak idején annyira nem is volt egyszerű, mivel meghívóra volt szükség a letöltéshez.

Azóta már bárki számára elérhető ez az újragondolt, másfaja közelítésből elkészített „közösségi böngésző”, mely a böngészés mellett az olyan dolgokat helyezi előtérbe, mint pl. a tartalmak egyszerű és gyors megosztása – legyen szó a Facebookról vagy akár a Twitterről. Itt egy kedvcsináló videó, azt hiszem, hogy ez többet mond el a böngészőről, mint néhány képernyőkép.

Biztosan lesznek, akiknek érdekes lesz ez az új, kibővített kezelőfelület és könnyen hozzászoknak majd, de egészen biztosan lesznek olyanok is, akik azt mondják, hogy ezt képtelenek megszokni. Minden esetre szerintem egy próbát megérhet mindenkinek, a RockMelt erről a weboldalról tölthető le.

Egyébként a böngésző a nyílt forráskódú Chromium projektre épül és a pár extra funkciót leszámítva ugyanúgy néz ki és ugyanúgy működik, mint a Google Chrome.

Amikor a gyorsítótár lassít…

2011. június 27. hétfő

Talán a legegyszerűbb módszer arra, hogy felgyorsítsuk a böngészőnket az az, ha időnként manuálisan töröljük a gyorsítótárat (cache), vagy kisebbre állítjuk a böngészőben megadott értékeket. Nem gondoltam, hogy egy napon pont erről fogok blogbejegyzést írni, de úgy veszem észre, hogy rengeteg ember nem is tud a gyorsítótárnak még csak a létezéséről sem.

Vannak napok, amikor bizony 24 óra alatt az általam meglátogatott weboldalak száma eléri a több ezret és sajnos – a nevével ellentétben – ilyenkor a böngésző gyorsítótára inkább csak hátrány, mint előny. Csak csendben megjegyzem, hogy eddig sajnos egyik böngésző sem tudott hosszabb távon (mondjuk 48 órán keresztül) megbirkózni az általam megtekintett oldalak mennyiségével (twitter linkek, RSS feedek, webfejlesztés, szakmai anyagok stb), érezhető belassulás nélkül.

A fenti okok miatt naponta, manuálisan (általában akkor, amikor a nap folyamán először a gép elé ülök) törlöm a gyorsítótárat és az előzményeket a Safariból (Chrome-ból, Firefox-ból, vagy ami épp a kezem ügyébe akad), azonban ezt a múlt héten valami oknál fogva sikerült kétszer is elfelejtenem egymás után. Az eredménye az lett, hogy a Safari elég érezhetően belassult és nehézkes volt már a böngészés.

Persze beállíthatnék egy kisebb értéket is az oldalak gyorsítótárazásánál, de mivel webre fejlesztek, ezért a fix szélességű betűtípuson és annak méretén kívül nem módosítom az alapértelmezett beállításokat. Pontosabban dehogynem, a Safarinak nem engedem meg, hogy használja a címjegyzéket, ill. az „Open ‘Safe’ files after downloading sincs kipipálva…

Mire való a cache?

A cache (más nevén gyorsítótár) tulajdonképpen arra való, hogy ha meglátogatunk egy webhelyet, akkor a már egyszer letöltött képek, ill. a webhely részét képező fájlok a merevlemezünkön eltárolásra kerülnek. Amikor pedig a következő alkalommal járunk ugyanazon a weboldalon, a böngészőnek nem kell újból letölteni az oldalt alkotó elemeket, hanem egyszerűen (az internetkapcsolatnál sokkal-sokkal gyorsabb) merevlemezről tölti be azokat, megspórolva ezzel akár több másodpercet, ill. akár több MB hálózati forgalmat is. Jól járunk mi (gyorsabban töltődik be az oldal), jól jár az internetszolgáltató (kisebb hálózati forgalom), ill. jól járnak a szerver üzemeltetői is (kisebb terhelés). Természetesen most itt ne egy olyan oldalra gondoljunk, ami mindennel együtt kitesz 2-3 MB-ot és van naponta 10 látogatója, hanem egy olyanra, ahol van napi százezer oldalletöltés (ez már ugye naponta több száz gigabájtnyi adatforgalmat is eredményezhet).

Ha viszont megnézünk néhány ezer oldalt és az ezekről eltárolt információkat később már nem használjuk fel, akkor azok csak feleslegesen foglalják a helyet a lemezen és feleslegesen lassítják a rendszert.

Tehát összegezve: azokat az oldalakat érdemes gyorsítótárban tárolni, amiket napi rendszerességgel (esetleg naponta többször is) meglátogatunk. Ilyenkor van leginkább értelme a gyorsítótár használatának. Az „ipari méretekben” történő böngészésnél / oldalletöltéseknél inkább hátrány, mint előny.

Egyébként én a magam részéről azt tartanám ideálisnak, ha beállíthatnám, hogy melyik oldalakat tárolja gyorsítótárban a böngésző (az összes többit ne). Sajnos ilyen böngészőt nem ismerek (tessék, itt egy jó ötlet a fejlesztőknek egy újabb funkció beépítéséhez, ami ma még nincs elterjedve). Az Opera beállításai mondjuk elég részletesek, de még az sem az igazi.

A teljesség igénye nélkül összeírtam, hogy az ismertebb böngészőkben hol kell a gyorsítótárat törölni, hátha többeknek hasznos lesz. Ez böngészőnként, operációs rendszerenként és nyelvenként eltérhet, de egy pici körültekintéssel bárki megtalálhatja akkor is, ha egy másik menüpontba lenne eldugva (az alábbi lista Mac OS X-re vonatkozik):

  • Safari
    Safari / Reset Safari…
  • Chrome
    Chrome / Böngészés adatainak törlése…
  • Firefox
    Eszközök / Előzmények törlése…
  • Opera
    Tools / Delete Private Data…

A Total Commander titka

2011. június 3. péntek

A napokban jelent meg az [origo] techbázis oldalán egy interjú Christian Ghislerrel, a Total Commander fejlesztőjével, Láthatatlan ember áll a Total Commander mögött címmel. A Total Commander elég távol áll a Macintosh-tól és a Linuxtól is, így most jogos a kérdés, hogy miért hoztam elő ezt a témát itt a blogon.

Azért hoztam elő, mert elolvastam az interjút és tetszettek Ghisler válaszai. Az első, ami számomra nagyon szimpatikus válasz volt, az ez (teljesen reálisan gondolkodik):

Sok ember, aki nem engedheti meg magának a Total Commandert, inkább más megoldást választana helyette. Nem az a stratégiánk lényege, hogy minimalizáljuk a nem regisztrált példányok számát, hanem hogy maximalizáljuk a megrendeléseket.

Természetesen nem azzal értek egyet, hogy warezoljunk amennyit csak lehet, a fejlesztők meg ne foglalkozzanak vele. Itt a hozzáállást értékelem, ill. azt, hogy ilyen higgadtan és jól látja át a dolgokat.

A másik pedig, amiből nagyon sok szoftverfejlesztő cég tanulhatna:

Nem, ahogy említettem, ellene vagyok a radikális változtatásoknak. Az emberek megtanulják, megszokják a funkciók használatát, ezeken nem érdemes változtatni, ha nincs rá nyomós okunk. Ennél fogva a Total Commanderbe sosem kerülnek forradalmian új funkciók, a szoftver evolúciósan fejlődik. Nem hiszem, hogy egy modern operációs rendszer fájlkezelőjének számottevően másképp kellene működnie, mint egy régebbiének.

Nagyon kevesen gondolkodnak így. Nézzük csak meg az 5-15 évvel ezelőtt megjelent kisebb programokat. Elkezdték fejleszteni ezeket minimális funkciókkal, majd az évek során egyre nagyobbra és nagyobbra duzzasztották őket, teletömve olyan extrákkal, melyekben a felhasználók nagy többsége elveszik és amire a legtöbb embernek semmi szüksége sincs. Így lett az 5-10 MB-os programokból az évek alatt akár 100-200 MB-os (!) úgy, hogy közben kb. ugyanazokat a gombokat és funkciókat használja a felhasználók legnagyobb része. A szoftverek viszont mára sokkal több helyet és sokkal több memóriát is foglalnak.

Ráadásul pedig sokszor indokolatlanul nagy változtatásokat is csinálnak a programokban, teljesen áttervezve a GUI-t (szándékosan nem hoznék fel példának most szoftvereket, de tudnék párat). A felhasználók pedig az új változat első indításakor azt sem tudják, hogy melyik gomb mire jó és mit hol találnak meg. Persze ugyanakkor lehetne néhány jó példákat is felhozni, amikor egy kezelőfelületet sokkal használhatóbbra sikerül csinálni.

Nem a szoftverek fejlődése ellen vagyok, mert haladni kell a korral és lépést tartani az igényekkel, de soha nem szabad elfelejteni, hogy a kevesebb néha több. Nem kell minden régi és jól bevált dolgot lecserélni csak azért, hogy valami új legyen helyette. Aki pedig azt mondja, hogy a billentyűparancsok elavultak (mint a fent említett cikk bevezetőjében is), az érdemi munkára eddig még nem igazán használhatta a számtógépet. 🙂

Egyébként – biztos vagyok benne, hogy – az az üzleti modell, amit Ghisler is használ (egyszer megveszed, utána pedig az összes változat ingyenes) is nagyban közrejátszik abban, hogy evolúciósan (nem pedig robbanásszerű újításokkal) fejlődik a szoftver.

Erőltetett menet

2011. április 13. szerda

Hamarosan a Mozilla is beáll azoknak a sorába, akik előre meghatározott időközönként fognak szoftvert kiadni. Egészen pontosan a Firefoxról van szó, ami jelenleg a négyes változatnál tart, de a tervek szerint még idén jön az ötös, a hatos és a hetes változat. Nem a Mozilla az első, aki ilyent csinál, így ebben nincs is semmi meglepő. Amin meglepődtem az az, hogy ők is átállnak az ilyen fix időközönként való kiadásokra.

Nyilván marketing szempontjából jó dolog, mert az átlagember számára is jobban hangzik, hogy nem a négyes változatnál tart év vége felé a Firefox, hanem mondjuk már a 7-est adják ki, csak éppen ettől még nem kerül bele több hasznos dolog és jobban összemosódnak a főverziók közötti különbségek. Ha pedig valamelyik újdonság fejlesztésével nem végeznének időben, akkor az majd a következő változatba fog belekrülni (a Firefox esetében 18 hetente terveznek kiadni egy-egy újabb főverziót).

Annak idején nagyon tetszett a Debian hozzáállása a kiadásokhoz: majd akkor adjuk ki a szoftvert, ha elkészül. Sajnos azóta ők is megváltoztatták ezt a gyakorlatot.

A szoftverfejlesztés nem olyan dolog – főleg nem az ilyen szoftverek esetében – amit ennyire pontosan lehet ütemezni, 18 hét ilyen szempontból nagyon rövid idő. Illetve ütemezni azt lehet, csak ha előbb kerül ki egy főverzió a felhasználókhoz, akkor értelemszerűen kevesebb újdonság kerül bele. Persze ezek csak számok, az adott szoftver funkcionalitásában és használhatóságában (elvileg) nincs jelentősége.

Nyilván megvan az oka, hogy miért döntöttek így a fejlesztők és biztos megint én vagyok maradi gondolkodású, de nekem mégis csak jobban tetszik az, ha egy szoftver főverziókat jelölő száma csak akkor ugrik egyet, ha az valóban indokolt és nem akkor, ha azt a marketing vagy bármi más úgy kívánja.