Mit jelent ez a mondat?

Option to behave as a meta-key

Hát nem azt, ami a bejegyzés címe!

Sokkal inkább azt, hogy “Az Option () használata meta-billentyűként“.

Miért fontos ez? Csupán azért, mert ha azt szeretnénk, hogy a Terminal felismerje a magyar billentyűzetről azt alt (Option, ) segítségével bevitt karaktereket, akkor ezt ki kell kapcsolni!

Néhány példa:

Ezek nélkül meglehetősen nehéz mondjuk a vi-ban programozni, cserébe viszont sok értelmetlen unicode fost írhatunk, miközben hasztalanul böngészzük a magyarra fordított Terminal beállításokat.

Hol lehet fordítási hibát bejelenteni az Apple-nek? Nem ez lenne az első.

Mi az a multitasking?

A számítástechnika egy bizonyos, nem is olyan távoli múltjában, úgy működtek a programok, hogy egyszerre mindig csak egy futhatott. Ez alatt azt kell érteni, hogy ha egy másikat szerettünk volna használni, akkor az aktuálisban el kellett mentenünk mindent, ki kellett belőle lépnünk és el kellett indítanunk a másikat, ahol meg kellett nyitnunk, amit szerettünk volna használni. Képzeljük el, hogy ebben a világban milyen lehetett egy telefonszámot átmásolni az email programból a naptár programba? Problémás.

A problémára megszületett a korszak megoldása, ami multitasking néven került be a köztudatba. Ez előző példánkat alapul véve, itt már egyszerre futhatott a levelező és a naptár program és egy egyszerű “task váltással” tudtunk egyikből a másikba lépni. Ez egy abszolút megoldás volt. Azaz a két program ténylegesen egyszerre futott, mindkettőnek megvolt a saját kibérelt processzor ideje és memória területe. Ebből következik ennek a megoldásnak a hátránya is, ha sok programunk fut egyszerre, azok sok erőforrást használnak, sok áramot fagyasztanak.

A mai operációs rendszerek mind így működnek, hisz a gépek erősek, a hálózati áram nem fogy el, és még a laptopokban is erőművek dolgoznak, meglehetősen nagy és nehéz akkumulátoroktól táplálva. Ezt így szépen megszoktuk.

Mi az én problémám? A mai okos telefonok már olyasmiket csinálnak, mint egy számítógép, de nem azok! Az emberek elmennek a lényeg mellett, mikor a kezükbe vesznek egy Apple telefont és azt mondják, hogy azon nincs is multitasking. Az Apple felismerte, hogy ennek a szónak ereje van, így használja, de valójában tényleg nem multitasking az, amit csinálnak. De a baj nem az, hogy az Apple annak hív valamit, ami nem az, hanem, hogy az embereknek nem azt akarják, ami kell nekik, hanem valamit, ami egy más környezetben egy hasonló problémára volt a megoldás.

Azzal kezdtem, hogy a multitasking egy megoldás egy problémára, úgy, ahogy a vonat megoldás két nagyváros közötti utazásra. A utasszállító repülőgép megoldás ugyanerre? Naná, de nyilván nem áll meg minden útba eső városban, viszont cserébe gyorsabb! Képzeljünk már el valakit, aki ül egy repülőn és azon sopánkodik, hogy “hát, jó-jó, de ez nem vonat, nem tudok leszállni félúton”.

Amit az Apple multitaskingnak nevez, az megoldás az eredeti problémára, és igazodik a telefonok erőforrás korlátaihoz. Mi a hátrány? Hogy a legtöbb dolog nem fog a háttérben folyamatosan futni, csak a zene, a helymeghatározás, push üzenetek fogadása, stb. Akinek ez nem elég, az pont olyan, mint aki a repülőn a vonat után sopánkodik.

Az egész média bullshit, a cikkekkel, hogy “höhö az iOS multitasking nem is igazi multitasking…” egy baromság! Naná, hogy nem az, ahogy a repülőgép sem vonat, FU! De ez így van jól!

Update: Eszembe jutott egy jó hasonlat: Van mondjuk egy betegség, amire kitalálnak egy gyógymódot és elnevezik X terápiának. Az emberek megtanulják, hogy X terápiával kezelik ezt a betegséget, sokan meggyógyulnak. Aztán jön valaki és azt mondja, hogy neki van egy másik megoldása. Az emberek szkeptikusak, ez nem az X terápia ez valami más… A valaki gondol egyet és azt mondja, ez is olyan, mint az X terápia és sokaknak ez elég, és használják és meggyógyulnak. Viszont mindig lesznek olyanok, akik azt fogják hangoztatni, hogy ez nem is igazi X terápia… de nem mindegy? A többség számára nincs különbség, mert mindkettőtől meggyógyulnak.
Szarrágók meg mindig lesznek, haters gonna hate!

Egy hosszabbacska dolog következik arról, hogy szerintem miért nem baj, hogy nem jött új design. Viszont előtte egy kis disclaimer:

Én eltökélt híve vagyok azoknak a dolgoknak, amik szerintem jók. Szeretem az iPhone-t, így boldogan racionalizálok bármilyen furcsa lépést, és aligha zavar, hogy talán becsapom magam, amíg ezzel azt érem el, hogy elégedett vagyok. Sok dologban nem vagyok ilyen határozott, de az iPhone kapcsán nincs bennem kétség. Szóval, amit alább írok az részben biztos fanboyság, de szerintem ha valaki kellően nyitott és velem gondolkodik, az megláthatja azt, amit én ebben jónak tartok. A többiek meg ne is olvassanak tovább.

Read the rest of this entry »

Én jóban vagyok az Oroszlánnal (Max OS X 10.7 Lion). Nekem indulás óta nem volt semmi komoly bajom vele… eddig.

Múlt hét végén arra kényszerültem, hogy belejavítsak néhány javascript állományba Codában. Vágtam, ragasztottam és azt vettem észre, hogy beillesztés után a (c)-ből © lett. Volt ugyanis copyright szöveg a file-ok tetejében commentezve. Undo, szépen visszacsinálta, nem is foglalkoztam vele többet, sőt(!) néhány file esetében nem is csináltam vissza, az a “copyright a commentben kit zavar?”

Az… senkit, na de a function(C) { ... } helyett a function© { ... } már kellőképpen bekavart a Firefoxnak, Chromenak (illegal character). Szerencsére rájöttem kis kódböngészés után és kijavítottam, de maradt a kérdés, akkor most ez már így lesz? Nem írhatok le (c)-t anélkül, hogy automatikusan © legyen belőle? Na, ilyen nincs, nézzünk csak utána.

Aha… Vázolnám:
1. Van egy rendszer szintű szimbólum behelyettesítés, amit ki kell kapcsolni a System Preferences-ben (Meg akkor más az autospellinget is, ugye).
2. Ezután, ha újraindítjuk a programokat, már nem fognak automatikusan javítani.
Kivéve, ha a program a Mail vagy a Safari, vagy az iChat, vagy bármely olyan alkalmazás, ahol ezt alkalmazás szinten is lehet kapcsolni.
3. Ezekben ugye alapból be van kapcsolva és egyenként kell kikapcsolgatni.

Természetesen, ha ezt mind ilyen egyszerű lett volna végrehajtani elsőre, akkor nem lennék most mérges, de sajnos itt ökörködtem vele fél órát mire rájöttem a fenti – egyébként fórumokban talált – megoldások mely helyes kombinációja után jutunk a kívánt eredményre, hogy sehol sem autojavít az Oroszlán.

Végül írtam a Coda fejlesztőknek (még a probléma megoldása előtt kezdtem a levelet), hogy ha lehet, blokkolják ezt a kedves Lion funkciót, mert ez így elég macerás.

Ha biztonságos kapcsolaton férünk hozzá az SVN-ünkhöz, előfordulhat, hogy változik az SSL tanusítvány. Ezt többek között a Coda nem kezeli valami jól, és hibaüzenetet kezd dobálni. A problémát úgy oldhatjuk meg, hogy Terminalban listázzuk az SVN-ünket, majd a feltett kérdésre (hogy elfogadjuk-e az új tanusítványt) a “p”, azaz permanens választ adjuk.

Volt egy érdekes problémám, vagy inkább idegesítő.

Arról van szó, hogy egy hírlevél küldő rendszerben az első lépés a címek kigyűjtése. Az én esetemben ez úgy nézett ki, hogy nagyjából 8000 visszaigazolt címet kellett összevetni az összesel (22000), kiválasztani a visszaigazolás óta ($fix_datum) bekerülteket valamit a visszaigazoltakat. Semmi gond. Létrehoztam egy $confirmed tömböt a visszaigazoltakból, majd szépen végigsétáltam az összesen és teszteltem:

Mi volt ezzel a baj? Hogy 10 másodpercig futott! Ez rendkívül idegesítő, főleg ha a hírlevél kezelőben is lefut, mikor szerkesztem. Na tennem kellett valamit. Első gondolatom az volt, hogy az email címek első X karakterei szerint kisebb tömbökre darabolom a visszaigazolt címeket. Nyilvánvaló volt, hogy a 8000 elemű tömbben való keresgélés a gond.

Az eredmény nem maradt el. X = 1 esetén 10-szeres, X = 2 esetén 32-szeres, X > 3 esetén pedig több, mint 70-szeres gyorsulás volt tapasztalható.

Feltételeztem, hogy egy ponton megfordul ez tendencia, szóval engedve a kisördögnek, elkezdtem feszegetni a határait. Nyilván nagyon nagy számot nem lett volna értelme megadni, mivel az e-mail címek mérete korlátozott, vettem tehát a legdurvább esetet, gyakorlatilag megfordítottam a tömbömet. A címek lettek a kulcsok, értéknek meg kapott mind egy true-t.

És jött a meglepetés! 100-szoros gyorsulás! Bizony, egy több ezer elemű tömbben a kulcsra való tesztelés 100-szor gyorsabb, mint az in_array().

A kísérletekből visszamenőleg látszik, hogy minél nagyobb számú X szerint bontottam a tömböt, annál kisebb altömbökön futott az in_array(), közben persze folyamatosan lépett be a kulcskeresés, amikor hivatkoztam az altömbökre ($confirmed[$keys]), míg végül csak az maradt.

Levonhatjuk tehát a tanulságot: nagy tömbök esetén az in_array() lassú!

Egy Stack Overflow-n feltett kérdésre kerestem a választ. Az ottani problémát kb. így lehetne leegyszerűsíteni:

Ki lehet-e nyerni egy globális regex mintaillesztés esetén a zárójelbe tett értékeket minden találatból?

Hát ki lehet, de nem egyszerűen. Problémák:

1. Először is erre nincs egy kimondott függvény, tehát meg kell keresni ezek megfelelő kombinációját. A pattern.exec(text) szépen visszaadja a zárójelezett részek tartalmát egy tömbben, viszont csak az első teljes találatét. A text.match(pattern) pedig megtalálja a teljes minta minden előfordulását, viszont csak ezeket adja vissza egy tömbben. No, de hát ez remek, hisz ennek a kettőnek a használatával megvalósítható a dolog.
2. Akkor hozzunk létre egy RegExp objektumot és ezzel futtassuk a fenti függvényeket. Igen ám, de egy regex minta objektumot csak egyszer tudtam felhasználni. Ha egyszer matchelt valamire, akkor ugyanaz a minta objektum már null-t adott minden további kísérletre. Erre is van megoldás, minden mintaillesztés előtt új objektumot kell létrehozni egy szövegesen tárolt minta alapján.

Végeredmény az alábbi kód, ami paraméterül várja a szöveget (text), amiben keresünk, a mintát (pattern) és a módosítókat (mod), amik viszont csak “i” és “m” lehetnek, mivel a “g”-t használja a függvény.

A kimenet sikeres találat esetén egy tömb, aminek minden eleme egy újabb tömb, amikben rendre megtalálhatóak: a teljes találat és a zárójelezett résztalálatok sorrendben egymás után.

Lecseréltem a MBP-t egy új iMac-re. Hogy miért? Azt lehet ugyanúgy nem írom majd meg sose, mint ahogy a MBP-ról se írtam eddig, pedig megígértem az előző postban. Na de, nem ez a lényeg, hanem, hogy:

Az Almárium Pro +2 év ráadás nem a magyar AppleCare Protection Plan!

Most akkor mi van?

Az van, hogy az Almárium Pro kitalálta, hogy azt a 2 év garanciát, amit egyébként kötelesek elismerni, ha ACPP-t veszel a gépedhez ők is árulni fogják. Ugyanannyiért. Kiterjesztik itthon a garanciádat, amit csak náluk lehet érvényesíteni, és… ennyi. Ez csak garancia, és csak a gépre. Mi van ezzel szemben a teljesen külön létező hivatalos ACPP-ben?

• +2 év teljes körű garancia a gépre ÉS minden olyan a géphez vásárolt perifériára, amire nincs külön ACPP (billentyűzet, egér, trackpad, stb.)
• telefonos helpdesk, igaz ez angolul, de megvetted, jogod van őket felhívni és nekik kötelességük segíteni
• egy DVD rajta hasznos diagnosztikai programokkal, mint pl.: TechTool Deluxe

Ezt a kiterjesztett garanciát, amit az Apple oldalán kellett regisztrálni, a világon mindenhol elismerik, szóval… éljen az ACPP!

Tavaly november 2-án vettem meg a 15″-os MacBook Prot. Nagy álmom volt, remek gép, de erről majd egy másik alkalommal. Amiről most akarok írni, az az első komolyabb beruházás a géppel kapcsolatban, nevezetesen a 3-évre kiterjesztett teljes körű garancia.

Ilyen komoly gépnél, ahol már a csere alkatrészek költsége vetekszik egy olcsóbb laptop árával, igencsak megfontolandó, hogy 1 vagy 3 évig tart-e a teljes körű garancia. Ugyanis az Apple számítógépekre gyárilag egy év garancia jár. Ezen felül van az ún. AppleCare Protection Plan, ami a vásárlástól számított 90 napon belül vehető meg a géphez és az USA-ban magában foglal +2 év teljes körű garanciát, illetve telefonos helpdesk szolgáltatást. Kis hazánkban nincs az Apple-nek fogyasztói szolgáltatása, vagyis a helpdesk nem játszik, de a +2 év garancia igen.

Az Apple hazai szerviz bázisa az Almárium-Pro Kft. Ők forgalmazzák nálunk a fenti (egyébként dobozos) terméket, “2 év ráadás” néven. Azért a más név, mert az Apple következetes cég, mást nem árul ugyan azon a néven, vagyis, ha nincs helpdesk, akkor ez már nem AppleCare, de mivel az egy éves alap garanciával teljesen azonos jogokat biztosít, a 2 év ráadás teljesen megfelelő.

A csomagok árai sávosan alakulnak. Míg a Mac minihez viszonylag olcsó ez a lehetőség, addig egy 15″-os MacBook Pro esetében már több, mint a kétszerese. Érthető ugyan, hisz a laptop alkatrészei nyilván drágábbak, ha javításra kerül a sor, mégis az ember erősen elgondolkodik, hogy megvegye-e. Erre a legmegfelelőbb az a 90 nap, ami rendelkezésre áll a vásárlástól kezdve.

Hogy döntsük el, kell-e ez nekünk, és egyáltalán, hogy zajlik ez az egész?
Read the rest of this entry »

Én már nem is emlékszem mikor kezdődött a dolog, de egyszer csak arra lettem figyelmes (már hónapokkal ezelőtt persze), hogy a VLC nagyon sokat gondolkodik az MKV videóim betöltése előtt. Talán azért törődtem bele, mert 720p-s videókról van szó főként, gondoltam ez így jó… de nem, hát akkor is rohadt sokáig tölt. Szóval utána jártam, és megtaláltam a megoldást:

1. Terminal.app
2. parancssorba: “sudo chmod 777 /usr/X11/var/cache/fontconfig”
3. itt kéri a root user jelszavát
4. utána betöltesz egy szokásos MKV-t, még most lassan fog töltődni
5. és kész, innentől minden MKV gyorsan meg fog nyílni

A legtöbb oldalon ezt a megoldást találtam. Működik, de sehol egy magyarázat. A legtöbb halandó, aki lehet most nyitja meg először a Terminalt, biztos nem is érti mi történt. Nekem azért van egy halvány sejtelmem, amit meg is osztok, azzal aki tovább olvas.

Read the rest of this entry »