Firefox 3.6.6 vs Flash 10.1.53.64 - percenként fagy

Az elmúlt hetekben egy hihetetlenül idegesítő hibára lettem figyelmes a Firefox-ban: bizonyos lapok, amelyek flash animációt tartalmaznak egyszerűen lefagyasztják a böngészőt, amely az "rendeltetésszerűen" kilép, feldobja a hibaküldő ablakot, majd felajánlja, hogy újratölti a session-t. Utánanéztem a fórumokon és háromféle variációval találkoztam:

• a Firefox 3.6.4-ben bevezetett plugin-container nem fér össze az új Flash-sel
• az új Flash úgy rossz, ahogy van, és megdögleszti a Firefox-ot
• az egész úgy sz*r, ahogy van, használj operát, ie-t, chrome-ot, safari-t, stb.

Az utolsó alapvetően jó megoldás, de azért csak van az embernek egy megszokott felülete, ahol a bookmark-jai ülnek, minden kézreesik, stb. főleg egy webfejlesztő esetében, ahol a plugin-ek garmadája van feltelepítve.

Az első kettő között viszont alapvetően nincs különbség, maximum jogilag (ami engem hidegen hagy, bár hajlamos vagyok az Adobe-ot hibáztatni - a Firefox esetében még nem nagyon tapasztaltam ilyen mérvű hanyagságot), hogy ki és miben hibázott. A megoldás egyszerű: mindenből fel az újat. Firefox 3.6.6, Flash 10.1.53.64. Fagy.

Ma nekifutottam még egyszer a történetnek, mert már végtelenül idegesített és ezt az oldalt találtam, ami a Mozilla Support hivatalosan. A benne leírt eljárás nekem bevált: kapcsoljuk ki az plugin-container-t és máris minden szép és jó. A képet azért idelinkelem:

Azért a kérdés még mindig áll: ki hibázott? Ha a hiba sok Firefox felhasználót érintett és ilyen körülményesen lehet, csak orvosolni, kíváncsi leszek a június végi globális böngészőhasználati statisztikákra. Szerintem meglepő lesz.

Froyo manuális frissítés

Nem bírtam kivárni, amíg a hivatalos Froyo aka Android 2.2 értesítés ideér. De nem is kellett, hiszen az első USA-beli hivatalos update-k után már el is lehetett érni a Google oldalán a manuális update-hez szükséges állományt. Sajnos ezt a google visszavonta - gondolom a kontrollálatlan elérések miatt -, de már késő volt. Aki neki kíván állni itt kezdje: Android Police.

Figyelem: csak szolgáltatófüggetlen telefonon működik az update!

Végigolvasva a hozzászólásokat szinte mindenkinek működött a manuális update, úgyhogy hajrá!

Az újdonságokról bővebben a Magyar Google Android portálon is olvashattok.

32 bites ORACLE ODBC Win7 64 bit alatt

Ma megint sikerült belefutnom egy általam eddig ismeretlen dologba. A feladat egyszerű volt: egy lekérdezést behúzni Excelbe egy távoli ORACLE adatforrásból. Aki eddig elolvasta pár bejegyzésemet az tudhatja, aki nem, annak leírom: jelenleg egy Windows7 Professional 64 bites oprendszert nyúzok. Munkám során elég sokszor kell ORACLE adatbázishoz kapcsolódnom és ezt vagy PHP-ből vagy PLSQLDeveloper-ből teszem. Sajnos a PLSQLDev nem ette meg a 64 bites ORACLE 11g klienst, ezért abból egy 32 bites verzió van feltelepítve, amivel tökéletesen működik. Gondoltam így lesz ez az Excel-lel is. Hát nem. Amikor megpróbáltam ODBC DSN-t létrehozni a feltelepített ORACLE ODBC driverrel a Win7 közölte, hogy "The setup routines for the Oracle in OraClient11g_home1 ODBC driver could not be found. Please reinstall the driver." Ami azért fura, mert ezt választottam ki a listából. Gondoltam egyből, hogy 64 bit problémába ütköztem, ezért nekiláttam guglizni, ahol is két teljesen különböző megoldást találtam a problémára, jelesül:

• Hogyan használjuk a 32bites ODBC adminisztrátort 64 bites rendszeren, forrás: http://robertoschiabel.wordpress.com/2008/02/28/windows-x64-32bit-odbc-vs-64bit-odbc/
• 64 bites és 32 bites ORACLE kliens telepítése egymás mellé, forrás: http://forums.oracle.com/forums/thread.jspa?threadID=1010383&tstart=0

Az első megoldást most nem fordítom, mert az nálam nem működött, hiszen az excel csak a 64 bites ODBC DSN-eket ajánlotta fel.

A második megoldás viszont meghozta a várt eredményt. A lényeg, hogy telepítsünk fel egy 64 bites instant klienst a 32 bites kliens mellé, ami pár egyszerű lépésből megtehető:

1. Töltsük le a 64 bites Basic és ODBC package-t az alábbi címről: http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/winx64soft.html
2. Tömörítsük ki őket egy könyvtárba. Nálam a 32 bites kliens a C:\Databases\ORACLE\ base könyvtárban van (\product\...), így az instant klienst a c:\Databases\ORACLE\instantclient_11_2\ könyvtárba csomagoltam ki.
3. Parancssorból futtassuk adminisztrátorként (én nem így futattam, de így is működött) az odbc_install.exe-t, amely jó esetben közli, hogy sikerült feltelepülnie.
4. Az instant kliensnek meg kell adni a TNS_ADMIN környezeti változóban, hogy hol találja a tnsnames.ora file-t. Nálam ez a 32 bites kliens jól ismert NETWORK\ADMIN alkönyvtárában található.
5. Élvezni munkánk gyümölcsét, hiszen a 64 bites ODBC adminisztrátorban megjelenik egy új ODBC driver, ami már valóban működőképesnek látszik:

Ennyi.

Subversion (SVN) telepítése CentOS-re

Ritkán kell bármit is telepítenem Linux alá - leginkább azért, mert be kell, hogy valljam némileg szakbarbár módon kezelem ezt a kérdést -, de egyszerűbb feladatokkal megbírkózom. Ilyen volt egy subversion szerver telepítése is. A régi szerverünkön a Kylix-os kódok miatt még egy RedHat AS 2.1-es fut, míg az újon, megszabadulva a kötöttségektől egy CentOS telepített jóságos rendszergazdánk. Terhelni viszont általában nem szeretem őt, csak akkor, ha számomra megoldhatatlan vagy megoldhatatlannak tűnő feladattal/problémával szembesülök. Egy sima svn szerver telepítése nem ilyen.

A lépések:

A yum jó barát, egyszerű, mint a faék, ezért a szerver telepítése egy sor:

yum install subversion.x86_64

Hozzuk létre az svn usert, megfelelő jelszóval

useradd svn

passwd svn

Ha ez megtörtént, hozzuk létre a repository root-ot:

mkdir /mnt/data1/subversion/repositories

Adjunk jogot az svn usernek erre az alkönyvtárra:

chown svn.svn /mnt/data1/subversion/repositories

Át is jelentkezhetünk svn user-nek és hozzuk létre az első projekt repository-t:

cd  /mnt/data1/subversion/repositories

svnadmin create proj1

Nincs más dolgunk, mint beállítani a projekthez tartozó hozzáférési beállításokat, amiket így tehetünk meg:
szerkesszük meg a proj1/conf/svnserve.conf állományt és szedjük ki a kommentjeleket az alábbi sorok elől:

anon-access = none
auth-access = write

password-db = passwd

Hozzuk létre a proj1-hez tartozó felhasználók táborát a passwd file-ban:

user1=jelszo

Ezen a ponton akár el is indíthatnánk az svn szerverünket, de én szeretem, ha service-ként fut, boot-kor elindul, ezért hozzuk létre root-ként a /etc/init.d/subversion állományt az alábbi tartalommal:

#!/bin/bash
#
#   /etc/rc.d/init.d/subversion
#
# Starts the Subversion Daemon
#
# chkconfig: 345 90 10
# description: Subversion Daemon

# processname: svnserve

source /etc/rc.d/init.d/functions

[ -x /usr/bin/svnserve ] || exit 1

# To pass additional options (for instace, -r root of directory to server) to
# the svnserve binary at startup, set OPTIONS here.
#
OPTIONS="-r /var/www/subversion/repositories"
RETVAL=0
prog="svnserve"
desc="Subversion Daemon"

start() {
        echo -n $"Starting $desc ($prog): "
   daemon $prog -d $OPTIONS
   RETVAL=$?
   [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
   echo
}

stop() {
   echo -n $"Shutting down $desc ($prog): "
   killproc $prog
   RETVAL=$?
   [ $RETVAL -eq 0 ] && success || failure
   echo
   [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog
   return $RETVAL
}

case "$1" in
  start)
   start
   ;;
  stop)
   stop
   ;;
  restart)
   stop
   start
   RETVAL=$?
   ;;
  condrestart)
        [ -e /var/lock/subsys/$prog ] && restart
   RETVAL=$?
   ;;
  *)
   echo $"Usage: $0 {start|stop|restart|condrestart}"
   RETVAL=1
esac

exit $RETVAL

Adjuk hozzá a service listához és indítsuk is el:
chkconfig --level 345 subversion on
service subversion restart

SVN kliensből az alábbi paraméterezéssel kapcsolódhatunk svn://[userame]@[hostname]/[project name] a fenti példa alapján: svn://svn@app1.server.com/proj1 - felhasználónévnek és jeszónak pedig használjuk a passwd állományban megadottakat.

Ennyi. Nekem működik.

Források: http://www.electrictoolbox.com/install-subversion-centos/ , http://behzad.nategh.com/install-subversion-on-centos-cpanel-vps-with-autostart-script-on-reboot/

Átállás (migráció) PHP 5.3-ra 5.2-ről

Számtalan weboldalt fejlesztettem/fejlesztettünk az elmúlt évek során. Azért, hogy a leghatékonyabban tudjunk dolgozni létrehoztam egy keretrendszert, ami mindenféle alap és sűrűn használt funkcionalitást tartalmaz és a keretet használó modulból pár sorban elérhető. Ilyenek a session kezelés, SQL futtatás, sablonok kezelése, callback rutinok és egyéb sablon-vezérlők alkalmazása. De ez a cikk most nem is erről szól. A fejlesztést még 4-es PHP-ban kezdtük, most jelenleg 5.2-es PHP alatt fut minden portálunk. Az elmúlt hónapokban debütált a PHP 5.3.2 és most az Windows-ra való átálláskor úgy döntöttem, hogy erre már ezt a verziót fogom felpakolni. Mondanom sem kell, hogy meglepő problémákba futottam. Az eddigi PHP verzióváltásokat a portáljaink alapvetően jól tűrték, egy-két beállítás után a php.ini-ben és minden makulátlanul működött. Nem úgy, mint most. A PHP 5.3-ra való átállás bizony migrációt (fejlesztést) jelent. Az 5.3-ból ugyanis számos eddig sokat használt (de azért már verziók óta elköszönőnek jelölt) eljárást bevontak a forgalomból, valamint egy-két ini beállítást is feketelistára helyeztek. Ezek a bevont (visszavont, deprecated) eljárások ettől még használhatók, de egy E_DEPRECATED hibát dobnak minden egyes alkalommal, amikor hozzájuk fordul a kód. Lássuk ezeket név szerint (hivatalos lista) és némi magyarázattal:

A visszavont ini paraméterek a következők:

• define_syslog_variables - a leírás szerint performanciális okokból "javasolják" az elhagyását, ha valaki mégis ilyet szeretne használni, arra ott van a define_syslog_variables() eljárás (ami szintén visszavont)
• register_globals - hát ezt csak támogatni tudom. Már évek óta "not recommended", hiszen a PHP legtöbb sebezhetősége ebből fakadt, ettől függetlenül mind a mai napig találkozom olyan kóddal, ami feltételezi, hogy be van kapcsolva. Igazából szinte csak időt spórolunk ezzel, hiszen milyen kényelmes, ha a HTTP hívás paraméterei egyből elérhetőek egy változóban, arra viszont sokan nem gondolnak, hogy ezzel a változó értékének tesztelését, inicializálását, stb. is kihagyják a kódból, így sérülékeny, esetleg törhető kódot gyártanak.
• register_long_arrays - ez is a HTTP változók betöltésének globális változóba történő kezelése, helyette illik a superglobal-ok használata, $_GET, $_POST, stb.
• safe_mode
• magic_quotes_gpc
• magic_quotes_runtime
• magic_quotes_sybase
• Comments starting with '#' are now deprecated in .INI files. - hogy miért, ki tudja? mostantól csak és kizárólag a pontosvessző használható erre a feladatra.

Lássuk az eljárásokat:

• call_user_method() (use call_user_func() instead) - már PHP 4.1 óta visszavont eljárás, remélhetőleg senki sem használja már. A call_user_func szinte ugyanazt a funkcionalitást hozza, más paraméterezéssel. A callback eljárásoknál használjuk, de számos módon segíti a munkát, hiszen stringként adható meg egy-egy eljárás neve és a hozzá tartozó paraméterezés.
• call_user_method_array() (use call_user_func_array() instead) - mint az előző
• define_syslog_variables()
• dl() - runtime tudott extension-öket betölteni, most már nem. Tessék az ini file extension eljárását használni.
• ereg() (use preg_match() instead) - reguláris kifejezés alapján keres mintát egy stringben. A probléma az, hogy a Perl stílusú reguláris kifejezéseket egy kicsit másképpkell írni, mint hagyományos társaikat, ún. elválasztó jeleket kell alkalmazni. Jelesül a Perl stílusú reguláris kifejezés mindig a delimiterrel kezdődik, ami bármilyen karakter lehet, de jellemzően per / jel. Ez utóbbiban ráadásul ún. tag-eket is lehet használni az utolsó delimiter után, mint például az i betű, ami a mintaillesztést kis-nagybetű érzékennyé teszi, mint az alábbi példában: 

"/^[a-z0-9][a-z0-9_.-]*@[a-z0-9.-]+\.[a-z]{2,4}$/i"

E-mail cím validáció tehát ezentúl:

function validate_email_deprecated($email) {
    if (!eregi("^[[:alnum:]][a-z0-9_.-]*@[a-z0-9.-]+\.[a-z]{2,4}$", $email)) {
        echo 'bad email';
    } else {
        echo 'good email';
    }
}

function validate_email($email) {
    if (!preg_match("/^[[:alnum:]][a-z0-9_.-]*@[a-z0-9.-]+\.[a-z]{2,4}$/i", $email)) {
        echo 'bad email';
    } else {
        echo 'good email';
    }
}

• ereg_replace() (use preg_replace() instead) - lásd. ereg
• eregi() (use preg_match() with the 'i' modifier instead) - lásd ereg
• eregi_replace() (use preg_replace() with the 'i' modifier instead) - lásd ereg
• set_magic_quotes_runtime() and its alias, magic_quotes_runtime() - nem nagyon értem ezt a magic_quotes mizériát, de ezt az eljárást kb. 5 perc alatt lehet megírni, és csak ott használni, ahol értelme van.
• session_register() (use the $_SESSION superglobal instead) - ahogy javasolja, használjuk a superglobal-t, már 4.1 óta így javasolják
• session_unregister() (use the $_SESSION superglobal instead) - ahogy javasolja, használjuk a superglobal-t, már 4.1 óta így javasolják
• session_is_registered() (use the $_SESSION superglobal instead) - ahogy javasolja, használjuk a superglobal-t, már 4.1 óta így javasolják
• set_socket_blocking() (use stream_set_blocking() instead) - 
• split() (use preg_split() instead) - lásd ereg
• spliti() (use preg_split() with the 'i' modifier instead) - lásd ereg
• sql_regcase() - ha erre valaha is szükséged lesz, használd a link alatt található hozzászólásokban található eljárást
• mysql_db_query() (use mysql_select_db() and mysql_query() instead) - egy adott query lefuttatása egy adott adatbázisban. A probléma az volt vele, hogy nem ideiglenesen váltott adatbázist, hanem véglegesen, ezért rengeteg hibára adhatott okot. Sokkalta célszerűbb, és okosabb fejlesztői üzemmód, ha az ilyen query-ket a fenti két eljárásra alapozzuk, talán jobban belénk vásődik, hogy ha egyszer kiadjuk a mysql_select_db utasítást, akkor onnan illik is visszaváltani (persze, ha kell), vagy egyszerűen használjuk a select * from database.table szintaxist, ami csak a lekérdezés erejéig használja a másik adatbázis sémát.
• mysql_escape_string() (use mysql_real_escape_string() instead) - ahogy írja, 4.1 óta célszerűbb az utóbbit használni.
• Passing locale category names as strings is now deprecated. Use the LC_* family of constants instead. - ez van, sosem használtam ilyet.
• The is_dst parameter to mktime(). Use the new timezone handling functions instead. - eddig ezzel lehetett állítgatni, hogy az eljrásr használja-e a nyári időszámítást vagy sem, amikor visszaadja a UNIX időt a megadott dátum alapján. Mostantól be KELL állítani a megfelelő timezone értéket a php.ini-ben, eféleképpen: date.timezone = Europe/Budapest a [date] szakaszban.

Én most állok neki PHP 5.3-sítani a keretrendszerünket. A fentiek közül kevés eljárást használok, de úgy érzem lesz vele meló, hiszen: tesztelni, tesztelni, tesztelni. A keretrendszert több mint 50 portál/weboldal használja jelenleg, és pl. a reguláris kifejezéseken alapuló eljárások cseréje, bár egyszerűnek látszik mégis a teljes keretrendszer funkcionalitását érinti.

A migrációt ezért valószínűleg úgy fogom kezdeni, hogy pl. minden ereg eljárást lecserélek egy ereg_migr-re, amit viszont már a fenti szabályok szerint fogok én megírni az új eljárásokkal és a régiekkel egyetemben. Így lehetőségem lesz egy darab konstanssal ki-be kapcsolni az "5.3-as üzemmódot", ha a tesztelés ideje alatt valamilyen oknál fogva mégis cserélnem kell azt az éles szerveren, ahol még az 5.2-es PHP fut.

Pl:

régi kód:

if (eregi("xy",...)) ...

új kód:

function phpMinV($v)
{
    $phpV = PHP_VERSION;

    if ($phpV[0] >= $v[0]) {
        if (empty($v[2]) || $v[2] == '*') {
            return true;
        } elseif ($phpV[2] >= $v[2]) {
            if (empty($v[4]) || $v[4] == '*' || $phpV[4] >= $v[4]) {
                return true;
            }
        }
    }

    return false;
}

$is53 = phpMinV('5.3');

function ereg_mig( string $pattern , string $string [, array &$regs ]) {

  if  ($is53) return preg_match("/".$pattern."/",...); else return ereg($pattern,...);

}


Azért előbb vagy utóbb érdemes kiírtani az ilyen kódrészeket...

Jó mulatást mindenkinek a migrációhoz!

Skype anomália Windows 7-en

A Skype telepítése után észrevettem, hogy az eddigi Vistás működéstől eltérően, amikor bezárom a Skype ablakát, az valahogy nem igazán tűnik el a taskbar-ról. Mivel egy olyan alkalmazásról van szó, amit az ember valószínűleg folyamatosan futtat fölöttéb idegesítő, ha állandóan helyet foglal a taskbar-on (illetve Win7-ben már Smartbar-on). A normál működés eddig az volt, hogy ha a főablakot bezárjuk, akkor a skype eltűnik a taskbar-ról, viszont becsücsül a traybar-ra. Ezt az évek alatt igen-igen meg lehet szokni. A megoldást a kompatibilitási jellemzők szerkesztése jelenti, magyarul a Skype.exe-nek meg kell mondanunk, hogy az bizony ne a natív Win7 módban, hanem pl. Windows Vista módban fusson. Az eljárás a következő:

• Ki kell lépni a Skype-ból, amit csak és kizárólag a traybar-on található ki ikon, jobb egérgomb, Skype bezárása menüvel lehet elérni, legalábbi én más megoldást nem találtam.
• Előkeríteni a Skype.exe-t a sajátgépben (általában C:\Program Files (X86)\Skype\Phone\Skype.exe)
• Jobb egérgomb, Tulajdonságok
• Kompatibilitás fül
• Pipa, hogy az alkalmazás kompatibilitási módban fusson és válasszuk alatta a Windows Vista SP2-t

 A skype újbóli elindításakor már jól, kell, hogy működjön!

CorelDraw X4 PDF nyomtatás anomália

Elég gyakran nyúlok a CorelDraw-hoz mostanában, de ma belefutottam egy kis turpisságba. Újonnan telepített Windows7-emen, amikor ki szerettem volna publikálni PDF-be egy elkészült művet, az hiba nélkül lefutott, de az elkészült PDF teljesen üres lett. WTF? Nekifutottam párszor, szét állítgattam a PDF publishing opcióit, de az eredmény mindig egy üres kb. 240 kbyte méretű állomány lett. 20 perc után feladtam, és nekifutottam, hogy akkor majd a Bullzip PDF printerével jól elkészítem. Nem sikerült, mert valami GhostScript-es hibát hozott az is. Őrület, google. Mint pár perces fórumozás után kiderült a baj a következő: a telepítéskor az előző oprendszereimtől eltérően a magyar regionális beállítást választottam, aminek az lett az eredménye, hogy az a nyüves Windows be is állított mindent, ahogy kell. Erről viszont a Corel-t nem értesítették, akik a PDF generálásakor az abban található számokat a regionális beállítások alapján formázzák!!!! Eddig úgy gondoltam, hogy a PDF az egy jól dokumentált szabványos formátum, aminek az utolsó bitje is kötelezően betartandó. Egyszóval a megoldás: a Control Panel\Regional Settings-ben állítsuk át a következőket, ezzel megfosztva magunkat a magyar formátumok szépségeitől:

• Decimal Separator (Tizedesvessző): . (pont)
• Digit grouping symbol (Ezres csoportosítás): space

Ettől a Bullzip PDF nyomtató is megjavult persze.

Samba megosztás elérése Windows 7 alól

A Windows 7 telepítése után első dolgom az lett volna, hogy az itthoni Linux szerveremen elérni a Samba megosztásokat, mert rengeteg telepítőm van ott tárolva. Címsorba beír a gép IP címe, semmi. Ping van, samba nincs. Volt már ilyen, hogy 2 évnyi folyamatos működés után leállt a samba, asszony gépe kinyit, samba van. Őrület kezd úrrá lenni rajtam, ezért Google.

A megoldás kézenfekvő: a Win7 alapvetően elvárja, hogy 128 bites titkosítással érje el a hálózati erőforrások egy részét, nem taglalom:

Control Panel - Administrative Tools - Local Security Policy
Local Policies - Security Options

Network security: LAN Manager authentication level
Send LM & NTLM responses

Minimum session security for NTLM SSP
Disable Require 128-bit encryption 

Ennyi. Fejből is mehetett volna...

Windows 7 telepítés

Úgy történt, hogy egyik reggel a notebook-omban a merevlemez nem pörgött föl. Most nem szeretném leírni azt a pszichés állapotot, amely úgy egy ezredmásodperc alatt kialakult bennem, de rég ijedtem meg ennyire. Becsületes redundáns adatmentő emberke vagyok, de mentésből visszahozni mindent az kb. olyan mint körömreszelővel fát vágni. Nem lehetetlen, de az ember kihagyja, ha lehet. Laptop vérmes ki-be kapcsolgatása meghozta a várt eredményt, merevlemez felpörög, hangja nincs, de az ijedtség maradt. Teljes merevelmez backup legyártása (természetesen és ezt mindenkinek tudom ajánlani - ilyenkor, ha külső winyóra mentünk NE írjuk felül az előzőt, nem tudhatjuk, hogy ez, az utolsó lefut-e normálisan, és nem dönti-e romba az előzőt.)

Elérkezettnek láttam az időt, egy új operációs rendszer telepítéséhez az alábbi okok miatt:

• Vista 32 bit - nem látja a 4 GB memóriát, illetve látja, de csak 3 GB-ot hajlandó használni
• csak ki kellene próbálni azt a Windows 7-et, mert ódákat zengenek róla és a munkatársaim lényegesen gyengébb hardverű gépein is vidáman cikáznak
• kb. 2 tonnányi szoftver újratelepítésével járó élmény - priceless

Szóval Windows 7 Pro EN 64 bit rendelése. Igen rendelése, miután nem találtam Budapesten olyan boltot, ami emberi áron készleten tartana egy angol 64 bitest. Az angolhoz ragaszkodom, sajnos vannak olyan alkalmazásaim (köszi IBM), amik fumigálják a magyar verziót. Na meg meg is szoktam már, a magyarban néha úgy eltévedek, hogy az hihetetlen. (Ja és itt említeném meg azt, hogy van egy ismerősöm, aki ismeri azt az embert, aki a Cancel gombot "Mégse"-re fordította "Mégsem" helyett). Természetesen új merevlemezt is beszereztem, a régi 120 GB-os helyett egy izmosabb 320 GB-osat. (A vista 47 GB-t foglalt a régin, a többi cuccom további 40-et.)

Volt egy extrém elképzelésem: felrakom az új Windows-t az új winyóra, a régi merevlemezből csinálok egy virtuális gépet (a Vista már vhd-ba backupol) és amíg a több napos áttelepítés zajlik, mindent tudok használni a régi gépről, csak elindítom azt. Az elképzelés szép volt és megvalósíthatatlan. Kipróbáltam mindent. A vhd elkezdett boot-olni, de Vista megfagy. Ezt kipróbáltam Microsoft Virtual PC 2007, a Win7 beépített Virtual PC-jével, a Sun VirtualBox-ával. Bootoltam recovery CD-ről, Linux alól, csesztettem a MBR-t, de az a nyüves csak nem volt hajlandó elindulni.

Ha valaki már migrált úgy oprendszert, hogy a másik gép nem elérhető, csak, mint merevlemez, az tudja, hogy az minden, csak nem mókás. Első nekifutásként a következőt javaslom, ha sikerül felbootolni a régi merevlemezzel (nekem sikerült):

• a registry-t kiexportálni egy szöveges file-ba. Nekem a következő méretű fileokat készítette:
• HKEY_CURRENT_USER/Software - 28 MB
• HKEY_CURRENT_USER - 135 MB
• HKEY_LOCAL_MACHINE - 244 MB
•  ha fut adatbáziskezelő, akkor full export file-ba
• ne törölj semmit, hagyd úgy, ahogy van, nem tudhatod mire lesz szükséged

Én a migráció alatt kb. 15-ször nyitottam ki text editorban (Notepad++) a 28 MB-os registry backup-ot, ami még ezen a hardveren sem pár másodperc, viszont ezzel a módszerrel megúsztam a további bootolást a régi rendszerbe.

Kicsit féltem, hogy mind a migrációkor, mind a telepítésekkor össze fog akadni a 64 bites Win7 és a régi 32 bites alkalmazások, de ezen félelmem alaptalannak bizonyult. Minden korrekten futott és mindent sikerült áthoznom a régi gépről. Egy hasznos tanács, szinte minden szoftverre találtam megoldást némi google-zéssel. A legbonyolultabb természetesen az Outlook áthozása volt, mivel kb. 6 mailboxom van benne, RSS-ek, stb. Ami kellemes meglepetés volt az a Firefox. 1 perc alatt áthúztam plugin-estül, bookmarkostul, mindenestül a régi gépről és mindenféle probléma nélkül elindult a megszokott környezetem.

És itt hadd ejtsek szót a Windows 7-ről. Tényleg sokkal "simább", mint a Vista. Minden 64 bites drivert megtaláltam hozzá (HP 8510w), és most, hogy a szoftverek kb 80%-a fel van telepítve 1 perc alatt bootol. Azért volt vele egy-két trükk, de ezeket egy következő post-ban fogom megosztani.

Virtualizációs kálváriám 2.

Új windows-om telepítése után úgy döntöttem, hogy bizonyos ritkán használt alkalmazásaimat virtuális gépre fogom telepíteni. Az első problémát a virtuális gép kiválasztása okozta, de erről részletesen egy másik, hosszabb írásban kívánok értekezni. A lényeg, hogy jelenleg a Sun (most már ORACLE) VirtualBox alkalmazását használom.Az elképzelés a következő volt:

• létrehozok egy Windows XP SP3 HU 32 bit rendszerrel egy virtuális gépet
• ha feltelepítettem rá minden létező service pack-ot és a virtuális gépben is nélkülözhetetlen alkalmazást (junction, total commander, stb.) az adott gépről csinálok egy másolatot, hogy mindig legyen egy "szűz" rendszerem
• feltelepítem rá az abban a gépben szükséges szoftvereket

Nem tűnt bonyolultnak a feladat, mégis sikerült belefutnom egy pár problémába. Csináltam egy virtuális drive-ot rutinosan 4,63 GB mérettel, hogy backupolni lehessen ha kell DVD-re is és feldobtam rá az XP-t. Örömöm teljes volt, szabad helyként kb. 1.5 GB maradt a lemezen. Itt hadd jegyezzem meg, hogy én még soha az életben nem láttam ennyi helyre felférő XP-t, de úgy gondoltam, hogy az alkalmazásokat, amiket fel szeretnék telepíteni egy külön drive-ra fogom rakni, amit NTFS-ként egy alkönyvtárba fogok mount-olni, úgyhogy a rendszer diszken csak az XP és a virtuális memória marad. A 1.5 GB üres hely 512 MByte virtuális memória beállítással (1.5GB fizikai RAM-ot kapott a host rendszer alól és egy komplett processzort, úgyhogy ennek elégnek kell lennie) kicsit meg is lepett, de ahelyett, hogy gyanút fogtam volna csendesen mosolyogtam. Aztán elkezdtem felpakolni a Windows Update-ről a kellő cuccokat. Mivel egy szép kerek, komplett windows-t akartam magamnak, a multimédiás csicsák kivételével mident letöltöttem és telepítettem. A mindenbe sajnos beleértettem a .NET 1-3.5 verzióját, ami feltelepítve kb. 1 GByte merevlemezt vitt el. Kezdtem megőrülni, de diszk még mindig volt elég és úgy gondoltam, hogy innen már nagy meglepetés nem érhet. Tévedtem.

Mielőtt nekiálltam volna az alkalmazások telepítésének csináltam egy gyors mentést a VDI file-ról, létrehoztam egy másik virtuális gépet és megpróbáltam csatolni az új diszket hozzá. A VirtualBox szemrebbenés nélkül közölte, hogy bizony-bizony, de egy hasonló UUID-dal rendelkező diszk már regisztrálva van, úgyhogy ezt bizony én hozzá nem adom a media-k listájához. Google. Mint kiderült a hiba nem hiba, hanem feature (innen is látszik, hogy amikor még nem is tudták, hogy az ORACLE megveszi a SUN-t, már akkor tudat alatt olyan szoftvereket gyártottak, amely beillik az ORACLE globális filozófiájába: this is not a bug, this is a feature :) ) és egyszerűen kezelhető. Parancssorból be kell csattogni a VirtualBox alkönyvtárába és egy egyszerű "VBoxManage.exe internalcommands sethduuid HdImageName.vdi" paranccsal lehet új UUID-et generálni az image-nek. (Forrás: http://forums.virtualbox.org/viewtopic.php?t=674) Így már valóban tökéletesen működik az új gép létrehozása.

Boldogan nekiálltam feltelepíteni a Borland (akkor éppen CodeGear) Delphi 2007-et, ami azzal kezdi, hogy a szükséges alapszoftvereket feltelepíti. Pontosan nem tudom mi az a kettő, de az biztos, hogy valami .NET csomag (amiről azt hittem, hogy már minden létező verzióját feltelepítettem) és természetesen nem kérdezi meg, hogy hova telepítse, beleömleszti a Program Files-ba. Illetve ömlesztette volna, ha felénél nem közli velem, hogy bizony a hely elfogyott a merevlemezen. Na ez király, gondoltam. Ismerem a standard eljárást: NTFS drive, ami ráadásul virtuális, ez szívás kategória. Google. A megoldás egy kb. 15 lépésből elvégezhető feladat amelynek a lépései:

• új VDI létrehozása, csatolása a rendszerhez
• Linuxos cél CD letöltése (GParted)
• volume klónozása az új diszkre
• volume méret megváltoztatása
• régi diszk törlése, új használata

A pontos leírást a my-guides.net-en találjátok, nagyon szépen, képernyőképekkel, természetesen angolul. Végignyomtam, sikerült. Egy ponton hibádzott csak a leírás, addig nem bírtam beilleszteni a régi partíciót, amíg meg nem mondtam az újnak, hogy az bizony egy MSDOS volume. A többi hibátlan.

Innen már nem ütköztem problémába, a szűz XP-m a dinamikus virtuális diszk kezelésnek köszönhetően még mindig felfér egy DVD-re, a Delphi is vidáman fut egy plusz diszk hozzáadásával.

Képletek szerkesztése a weben

Egyik jelenlegi projektem keretében olyan Word dokumentumokat kellett előállítanom, amely nem nélkülözte a bonyolultabb matematikai képleteket sem. Aki már dolgozott képletszerkesztővel, az tudja, milyen rafináltak is tudnak ezek lenni. Én például a Word-ét ki nem állhatom, mert grafikusan összekattintgatni képleteket szerintem igen-igen macerás, főleg akkor ha az ember már hozzászokott valamely más matematikai rendszer "nyelvéhez". Én eddigi pályafutásom és tanulmányaim alatt a legtöbbször a Derive alkalmazást használtam a dokumentálásra pedig a LaTex-et. Jelenleg egyiket sem használom és nem is kívántam feltelepíteni a gépemre, ezért néztem körül a neten. A legvalószerűtlenebb helyen bukkantam rá a megfelelő alkalmazásra, az iGoogle moduljai között. Konkrétan a www.sitmo.com oldal készített egy olyan iGoogle beépulő modult, amely közel LaTex kompatibilis. Az elkészült képleteket letölthetjük grafikaként és beillszthetjük word-be.

Weboldal tesztelése több böngészőben

A probléma valószínűleg minden webfejlesztőnek, tesztelőnek ismert, de érdemes a megrendelői oldalon elgondolkodni ilyen irányú tevékenységen. Ha az ember weboldalt fejleszt azt valószínűleg HTML+CSS+Javascript combo felhasználásával teszi (esetleg flash-ben, de az egy más ügy). Ezen nyelveknek az a sajátosságuk, hogy a különböző böngészők más és más módon értelmezik, jelenítik meg őket. Egy tapasztalt és minőségi munkát végző fejlesztőnek kötelessége (amennyiben a megrendelői igények nem mondanak mást) letesztelni az elkészült produktumot a legelterjedtebb böngészőtípusokban.

Hogy melyek ezek így 2010. elején? A listák itt találhatók:

• Browser Statistics a W3Schools jóvoltából, visszamenőleg egy pár évre
  
• Global Web Stats a W3Counter statisztikája

Mint ezekből jól látható a leggyakoribb böngészők a Microsoft Internet Explorer, a Mozilla Firefox és feljövőben a Google Chrome. Ha csak ez a három lenne nem is lenne gond a tesztelés, hiszen ezek simán megférnek egymás mellett. Viszont sajnos ezen böngészők különböző verziói is másként jelentítik a weboldalakat. Jelen állás szerint egy komoly weboldalnak az alábbi böngészőtípusokon kell jól működnie:

• Internet Explorer 6 (IE6) - a legrégebbi verzió, de sajnos rengeteg céges és régi gépen még mindig ezt a verziót használják
• Internet Explorer 7 (IE7) - lényegesen újabb verzió a Windows XP 1-es service packjától már a legtöbb windowson ez az alapértelmezett
• Internet Explorer 8 (IE8) - a legújabb és ezzel együtt legfejletteb Internet Explorer
• Firefox 3.5
• Firefox 3.6
• Chrome 4

A fenti listából én személy szerint az IE6-s böngészőkre már nem szoktam tesztelni, mert lassan lehetetlen olyan fejlett kódot írni, ami értelmes mennyiségű munkával IE6 alatt is életképes. De ez most nem is lényeges.

A feladat, hogy megoldjuk azt, hogy egy weboldalt a fenti lista mindegyik verziójával leteszteljük. A megoldáshoz számos út vezet:

• beköltözünk valamelyik magyarországi minisztériumba, ahol saját tapasztalatom szerint a világ összes verziójú böngészőjével, gépével, operációs rendszerével találkozhatunk
• valamilyen virtualizációs technológiával virtuális gépeket telepítünk és azokban teszteljük a weboldalunkat
• keresünk valamilyen alternatív megoldást

Az első értelemszerűen nem járható. A második már lényegesen kiforrottabb. Az IE különböző verziói alatti teszteléshez a Microsoft is ezt ajánlja, olyannyira, hogy letölthetővé tesz időkorlátos és lebutított virtuális meghajtóra telepített windows-okat. A leírása és a VHD-k letöltése "Internet Explorer Application Compatibility VPC Image" néven található.

Az alternatív megoldás: elég sokat keresgettem a neten ezügyben, de egy befutót találtam, amely azt tudja, hogy egy böngésző plugin segítségével létrehoz egy virtualizációs sandbox-ot, amiben a weboldalról kiválasztott több mint száz alkalmazás közül futtathatunk egyet. Ez a weboldal nem más, mint a spoon.net, ezen belül a különböző browser típusok a Internet/Browsers kategóriában találhatók.

A plugin mind Firefox 3.6, mind IE8-X64-ben tökéletesen futott (Windows 7 X64 EN).


Azt hiszem ennél maradok, egészen addig, amíg nem ütközöm valami olyan bug-ba, ami miatt újat kell keresnem.

Nyitány

Mint webfejlesztő, rendszerszervező nap mint nap találkozok olyan informatikai problémával, amely, hogy úgy mondjam "leküzdendő". Ezen problémák megoldása általában erős guglizással megoldható. Ezt a blogot azért nyitottam, hogy egyrészt összegyűjtsem ezen irányú tevékenységeimet, másrészt, hogy segíthessek a hasonló cipőben járó kollégáimnak, akik talán-talán ráakadnak erre a blogra, harmadrészt pedig azért, hogy ha ezt a blogot esetleg az adott téma szakértői is olvassák, akkor hozzászólás formájában pontosítsák az elképzeléseimet.

A problémák elég sokszínűek lesznek az adatbáziskezelőktől elkezdve a virtualizációig, mindenféle összefüggés nélkül, ahogy az élet hozza. Jó pár problémát előrángatok az "archívumból" is, hiszen ezek megoldása sem volt triviális és valószínűleg még mindig aktuális.

Nem célom más oldalakról fordításokat közölni, így a legtöbb cikk számtalan linkket fog tartalmazni, remélhetőleg a final solution linkjével együtt.

A felhozott témáknak sem szakértője nem vagyok, de talán a lelkes amatőrnek - így 15 évnyi fejlesztői munkával a hátam mögött - sem nevezném magam.