2011. április havi archívum

Google Chrome ikon lecserélése Mac-en

2011. április 30. szombat

Már vártam – pontosabban szólva reménykedtem, hogy minél később következik be a dolog – hogy a Google Chrome lecseréli a saját ikonját, de tegnap megtörtént. Természetesen az első dolgom az volt, hogy előkerestem a régi ikonokat és egyből visszacseréltem őket a régiekre.

Ebben a bejegyzésben ezt a folyamatot szeretném bemutatni, lépésről lépésre.

Először is szükségünk lesz a régi ikonokra, amik Mac OS X alatt .icn kiterjesztésű fájlok és az alkalmazáson belül találhatóak meg). A Google Chrome.app valójában két ilyen fájt is tartalmaz: az egyik magának az alkalmazásnak az ikonja, a másik pedig azoknak a dokumentumoknak az ikonja lesz, melyek a Chrome-hoz vannak hozzárendelve.

Első lépésként töltsük le a régi Chrome ikonokat tartalmazó tömörített fájlt innen.

Ha ezzel megvagyunk, akkor nyissuk meg a Findert, majd navigáljunk el az Applications könyvtárba, ott pedig keressük meg az előbb említett Google Chrome.app fájlt. Klikkeljünk rá jobb egérgombbal, majd válasszuk a menüben a Show Package Contents lehetőséget:

Ekkor megnyílik egy új ablakban a Google Chrome.app fájl tartalma. Egyetlen könyvtár van benne Contents néven, amit szintén nyissunk meg, majd utána lépjünk be az abban található Resources könyvtárba.

Itt látni fogjuk a két fájlt, ami az új ikonokat tartalmazza: app.icns és a document.icns. Ezt a két fájlt fogjuk felülírni az imént letöltött fájlokkal.

Ha eddig nem tettük volna meg, akkor most tömörítsük ki az imént letöltött old-google-chrome-icons.zip-et és a benne lévő két ikonfájlt húzzuk be ebbe a könyvtárba.

Valószínű, hogy ezt nem fogja szó nélkül hagyni az OS X, ezért a felugró ablakban válasszuk a Replace, a következő felugró ablakban pedig az Authenticate lehetőséget, majd adjuk meg jelszavunkat.

Ha ezzel is megvagyunk, akkor lecseréltük az új Chrome ikont a régire, az viszont elképzelhető, hogy pl. a Dockra húzott Applications könyvtár még a régi ikont mutatja. Ezt a problémát az alábbi módon lehet a legegyszerűbben megoldani: nyissuk meg a Terminalt és írjuk be parancssorba a következő parancsot:

killall Dock

Mostantól ismét a régi ikon ül a Dockon a Google Chrome neve alatt és ezt látjuk az Applications könyvtárban is. A fenti módszerrel természetesen szinte bármilyen más alkalmazás ikonja tetszőlegesen lecserélhető.

Frissítés: mivel a fent említett ikonok a Google Chrome.app-ban vannak tárolva, ezért amikor a Chrome frissíti magát, az ikonokat is visszacseréli az újakra. Ilyenkor újból végig kell csinálni a fenti műveleteket (másodszorra már sokkal gyorsabban fog menni). 🙂

Apró figyelmesség a Twittertől

2011. április 27. szerda

Valamilyen okból kifolyólag a Twitternek nem sikerült kiküldenie részemre egy (vagy több) e-mailt és amikor legközelebb beléptem a webes felületre, ez az üzenet fogadott:

Alapjában véve semmi extra dolog nem történt, azonban mi, akik webes fejlesztésekkel foglalkoznak tudjuk, hogy az ilyen apró figyelmességek elkészítése mennyi plusz munkával jár egy oldal fejlesztésekor, hiszen rengeteg ilyen apróságra kell(ene) odafigyelni. Az eredményét pedig a felhasználóknak sokszor csak nagyon kis százaléka látja – mint például ezt is.

A legtöbben nem tudják, hogy egy weboldal elkészítésére fordított időből csak egy elég kis hányad az, amit a „látható” részekre fordítunk fejlesztés során (most itt tekintsünk el a CMS alapú, sablon segítségével készített egyszerűbb oldalaktól). A fejlesztésre fordított idő nagy része olyan dolgoknak az elkészítésére megy el, ami a működés során a háttérben zajlik szépen csendben, a felhasználók tudta nélkül (az adatbázis-műveletektől a beviteli mezőkbe beírt adatok ellenőrzéséig). A felhasználó pedig csak annyit lát az egészből, hogy „működik” az oldal.

Ez a fenti is egy ilyen apróság, én kb. az utolsó helyre tenném a tennivalók listájában a lepattanó vagy visszaérkező e-mailek figyelését (nem beszélve arról, hogy a megrendelők zöme meg sem fizetné ill. fizeti az ilyen fejlesztéseket). Jó dolog azt látni, hogy vannak, akik odafigyelnek ilyen dolgokra is.

Valamivel gyorsabb lesz a hazai domainek regisztrációja

2011. április 22. péntek

Korábban már írtam arról, hogy hazánkban mennyire túl van bonyolítva a domain-regisztráció – már ami a .hu-s végződésű domaineket illeti. Most ezen a két hetes várakoztatáson enyhítettek, de még így is hihetetlenül bonyolult és körülményes pl. egy .eu-s domain bejegyzéséhez képest. Sőt, valójában nem is egyszerűsödik, mert maga a folyamat a korábbinál szerintem még bonyolultabb lesz, csak valamivel előbb juthatunk hozzá az áhított domainhez.

A domain 2011. június 1-től a regisztrációs folyamat elindításakor nem egy kéthetes várólistára, hanem “feltételes használatba adásra” kerül, így már néhány napon belül használatba tudjuk venni. Persze nem Magyarországon lennénk, ha ezt XXI. századi módon oldották volna meg, a technikai vívmányait kihasználva, online megrendelési lehetőséggel, pár perces időráfordítással, SMS-es értesítéssel. Dehogy. Az igénylőlap is megmarad és biztos ami biztos, felteszik egy 8 napos várólistára is, aminek a világon semmi értelme sincs.

Természetesen ennek a változásnak is örülni kell, de úgy érzem, hogy elég messze vagyunk még attól, hogy ez a dolog normálisan működhessen. Persze semmi gond, megszoktuk az ilyeneket, hiszen Magyarországon élünk.

Csaba’s blog a Facebookon

2011. április 21. csütörtök

Nagyjából másfél hete regisztráltam egy Facebook oldalt a blognak, de csak most hajnalban jutottam el oda, hogy élesítsem (befűzzem azt a pár sornyi kódot a blogba). A blogon és a Facebook oldalon található tartalomban a tervek szerint elég sok átfedés lesz, de mégsem lesz a kettő teljesen azonos. Vannak olyan anyagok, amikről nem írnék itt egy külön bejegyzést, de a Twitteren való megosztásuk 140 karakteren meg mégis csak kevésnek bizonyul. Ezek az apróságok kerülnének a Facebook oldalra.

Kipróbálom, kap valamennyi időt és esélyt a dolog, aztán ha nem váltaná be a hozzá fűzött reményeket, akkor nem foglalkozom a tartalmak ilyen formában történő megosztásával tovább.

Az oldal egyelőre itt érhető el: Csaba’s blog a Facebookon, a bejegyzések alatt pedig ki lehet nyilvánítani az esetleges tetszést a Tetszik gomb megnyomásával:

The Mountain

2011. április 18. hétfő

Parányi utazók vagyunk a minket körülölelő univerzumban. Itt vagyunk, élünk, létezünk és sokszor elfelejtjük, hogy mekkora ajándék számunkra az a csoda, amit életnek hívunk.

Szánd rá a videóra azt a három percet, nézd meg teljes képernyős és HD módban. Hidd el, hogy nem fogod megbánni.

Ezt a fotókból összeállított videót Handrás blogján találtam és ugyanaz a srác csinálta, aki a másik nagy kedvencemet, ezt itt.

A phpMyAdmin alapértelmezett betűméretének beállítása

2011. április 17. vasárnap

Apró, azonban annál bosszantóbb dolog, amikor a böngésző előzményeinek törlése után a phpMyAdmin ismét az alapértelmezett betűmérettel jeleníti meg a tartalmat. Ennek az oka az, hogy a phpMyAdmin nem felhasználónévhez kötve tárolja ezt a beállítást a kiszolgálón, hanem egy sütiben, a felhasználó gépén.

Szerencsére elég egyszerűen megváltoztathatjuk az alapértelmezett betűméretet – feltéve persze ha tudjuk, hogy hol tárolták el ezt az értéket a phpMyAdmin készítői. 🙂

Keressük meg a szerveren (vagy a saját gépünkön) a phpMyAdmin könytárát, majd ott lépjünk be a libraries alkönyvtárba. Ezután nyissuk meg a Config.class.php fájlt és keressük meg az alábbi szakaszt (nekem a 765. sor környékén található az alábbi rész):

} elseif (! $this->get(‘fontsize’)) {
  // 80% would correspond to the default browser font size
  // of 16, but use 82% to help read the monoface font
  $this->set(‘fontsize’, ‘82%’);
}

Írjuk át a 82%-ot arra az értékre, ami nekünk a legjobban megfelel, majd mentsük el a változásokat. A következő belépésnél már az általunk megadott betűnagyság fogad minden felhasználót, akiknek nem tárolt el a gépén sütit a phpMyAdmin, vagy akiknek eddig is az alapértelmezett méret volt beállítva.

Természetesen a betűméret továbbra is megváltoztatható marad a phpMyAdmin felületén található legördülő listán, a fenti módosítások csak az alapértelmezett méretre fognak vonatkozni.

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.

Biztonsági kockázatot növelő változtatás a Firefox 4-ben

2011. április 1. péntek

A Firefox 4-es verziójába több, a böngésző grafikus felületét érintő változtatás is belekerült. Ezek közül az egyik érinti a felhasználó weboldal általi értesítését szolgáló dialógusablakok megjelenését is, melyeket a JavaScript alert(), confirm() és a prompt() függvényeivel érhetjük el.

A Firefox 4 előtti változatokban – ill. a többi böngészőben – az ilyen ablakok kinézete megegyezik az adott operációs rendszer grafikus felületének stílusával. Ameddig a többi ilyen ablakot drag and drop módszerrel akár a böngésző ablakán kívül is elhelyezhetjük, addig a 4-es Firefoxban lévő változat egyáltalán nem mozgatható és minimális időráfordítással bárki készíthet ilyen stílusú párbeszédablakot, pusztán JavaScript és CSS segítségével.

Ennek az egésznek a veszélye abban nyilvánul meg, hogy az átlagfelhasználók hozzászoknak az ilyen ablakokhoz és nem fogják tudni megkülönböztetni a böngészők és pl. a kártékony kódot tartalmazó weboldalak által küldött üzenetet, ezért könnyen vissza lehet majd élni egyes felhasználók bizalmával. Márpedig ha vissza lehet élni, akkor lesznek olyanok, akik ezt meg is teszik.

Láthattunk már hasonló trükköket az iPhone-on futó Safarival kapcsolatban, amikor az eredeti címsort kicserélve megtévesztik a felhasználót akár a webcímek valódiságát, akár a kapcsolat biztonsági fokát (http/https) illetően. Szerintem nagyon rossz és nem átgondolt ötlet volt a Mozilla részéről a GUI ezen részének ilyen irányú módosítása, sok probléma lehet még ebből.