Az Operának régóta sok gondot okoznak a nem szabványos, böngészőspecifikusan megírt, vagy éppen elavult oldalak. Ez ellen sokféle módon próbálnak védekezni, ma az oldalakat betöltődés közben javító browser.js-ről lesz szó.

Ez a bejegyzés az "Opera's site patching" című cikk fordítása. Az eredeti cikk 2009. április 7-én jelent meg a Core blogon.

Tudod, a web technológiák komplexitása kezelhetetlenné válik, amikor minden egyes oldal valami egyedi kezelést igényel. Képzeld el, milyen lenne az autóvezetés, ha minden új utcába bekanyarodáskor kicsit bütykölni kellene a motoron, vagy le kellene cserélni a kerekeket. A böngészőfejlesztés sokban emlékeztet erre napjainkban.

Szinte minden modern böngésző rendekezik valamilyen oldal-hibamentesítő eljárással arra az esetre, ha meg kell kicsit olajozni web kiszámíthatatlan elemeinek kitett szabványok fogaskerekeit:

• az IE8 egy kompatibilitási lista alapján IE7 módban jelenít meg bizonyos oldalakat
• a Google Chrome álcázza magát a Hotmail-en
• a Safari homályos, dokumentálatlan trükköket alkalmaz
• a Firefoxnak úgy tűnik, csak a böngészőazonosító-váltó kiterjesztése van - de az eléggé népszerű
• az Opera álcázást és browser.js-t használ

Minden oldalt külön kezelni? Elég őrülten hangzik. Egyértelműen lehetetlen. Kezdőknek: több milliárd weboldal létezik és mind különböző. És változnak is, hiszen millió sornyi kódot adnak hozzá, és cserélnek le minden áldott nap. Hogyan lehet ezzel egyáltalán lépést tartani? Mellesleg nem a szabványoknak kellene a megoldást szolgáltatniuk?

Ez a bejegyzés a "(re-)Introducing video" című cikk fordítása. Az eredeti cikk 2009. december 31-én jelent meg a Core blogon.

Ma [azaz 2010 január 1-én] a Desktop Team kiadta az év első Opera 10.5 pre-alfáját, ami már tartalmazza az új HTML5-ös video implementációnkat. Az Opera volt az első, aki javasolta a video elemet, és már 2007-ben elérhetővé tette az első demonstrációs célú (proof-of-concept) előzetest. Ebben a bejegyzésben az azóta végzett munkáról beszélnék, az általunk hozott döntésekről és a lehetséges folytatásról.

Kodekek

A kezdetektől fogva az egyik legfontosabb kérdés, hogy melyik audió- és videóformátumokat kellene használnia a HTML5-nek. A kérdés komoly vitákat indukált a web standard közösségen belül, de azóta sincs egyetértés. Mi úgy gondoljuk, hogy a webes platformnak nyílt szabványokon kell alapulnia, emiatt folytatjuk az Ogg formátumok támogatását: a Vorbis audió- és a Theora videóformátumot. Az alap WAVE PCM hanggal együtt ezek alkotják az "alap" kodekjeinket, amit minden platformon támogatni fogunk.

A nemrég megjelent Opera 10.5 pre-alfa verziójának sztárja egyértelműen az új, Carakan névre hallgató JavaScript motor volt. Úgy gondolom, hogy a fejlesztőik megérdemelnek annyit, hogy teljesítményüket bemutathassák, és azt mindenki megismerhesse. Át is adnám nekik a szót...

Ez a bejegyzés a "Carakan Revisited" című cikk fordítása. Az eredeti cikk 2009. december 22-én jelent meg a Core blogon.

Kicsi több mint egy év telt el azóta hogy elindítottuk a Carakan-projektet, ami az Opera ECMAScript végrehajtási sebességének drasztikus növelését célozta, és most jött el az első fejlesztői kiadás ideje.

Amit bő egy éve elkezdtünk implementálni, az - ahogy azt már a Carakanról szóló korábbi bejegyzésemben is írtam - egy új keresztplatform bájtkód-értelmező az új, regiszter alapú utasításkészlethez, egy új belső objektummodell automatikus osztályozással és belső tulajdonság-gyorsítótárral, és egy gépi kód generáló. És mi mindezt elkészítettük, sőt, ennél többet is.

Az új bájtkód-értelmező és az új objektummodell keresztplatform fejlesztés, ami azt jelenti, hogy minden hardveres platformon működik, amire az Operát átültetjük. Ezek önmagukban is jelentős teljesítmény-növekedést jelentenek a korábbi Futhark motorhoz viszonyítva, amiket a jelenlegi Operákban alkalmazunk.

Egy átlagos asztali gépen a Carakan bájtkód-értelmezője a SunSpider teszten körülbelül három és félszer gyorsabb, mint a Futharké, és korai tesztjeink az ennél kisebb teljesítményű processzorokkal üzemelő beágyazott rendszerek esetében még nagyobb előnyt mutatnak a Carakan javára.

Az optimális sebesség elérésére azonban a gépi kód generálás (másképpen JIT - Just In Time, [azaz futásidejű generálás]) a helyes megközelítés, és erre összpontosítottuk az optimalizációs munka nagy részét is.

A Carakant felszereltük egy forrópont (hot-spot) detektáló JIT fordítóval, ami olyan gépi kódot fordít, ami a legkomplexebbek kivételével minden utasítást képes végrehajtani a bájtkód-értelmező meghívása nélkül. Ez a technika ötvözi a kód fordítás-időbeli (compile-time) statikus analízisét és a bájtkód-motor futásidejű állítását az optimális bájtkód generálása érdekében, különös tekintettel az aritmetikai számításokra.

A motor funkció-beágyazásokat is végez (function inlining), mind a beépített funkciók (például Math.sqrt() négyzetgyök-vonáshoz), mind programozó által készített funkciók esetén. A JIT fordító jelenleg csak 32 illetve 64 bites x86-os gépi kódot generál, de idővel további architektúrákat is támogatni fog, az ARM-al kezdve a sort.

Ez a bejegyzés a "Test automation with OperaWatir" című cikk fordítása. Az eredeti cikk 2009. március 6-án jelent meg a Core blogon.

Annak érdekében, hogy még a termék kiadása előtt megbizonyodhassunk az Opera motorjának megfelelő működéséről, különböző konfigurációkon több, mint 100 ezer automatikus tesztet futtatunk le minden egyes összeállítás elkészültekor.

A futtatott tesztek között találunk (automatikus) vizuális, JavaScript, teljesítmény-, stabilitás-, memória- és öntesztet, sok egyéb mellett. Hiányzott viszont az olyan műveletek vizsgálata, amik valamiféle felhasználói aktivitást igényelnek, például űrlapok kitöltése, hivatkozásokra kattintás vagy az összetett webes alkalmazások használata.

Így volt ez - egészen mostanáig.

Jelenleg a Scope protokollon keresztüli vezérlés támogatásán dolgozunk. Ez az a protokoll, amit a Dragonfly nevű fejlesztőeszközünkben is használunk. Egy egyszerű szkript segítségével például arra utasíthatjuk a böngészőt, hogy automatikusan használja a Google keresőt, jelentkezzen be a Hotmailbe és küldjön el egy üzenetet, vásároljon könyveket az Amazonon, vagy keressen repülőjegyeket az Expedián.

Íme egy példa, hogy hogyan nézhet ki egy ilyen szkript:

require "operawatir"

browser = OperaWatir::Opera.new
browser.goto("http://www.google.com")
browser.text_field(:name, "q").value = "Wikipedia"
browser.button(:name, "btnG").click

browser.link(:text, "Wikipedia").click

puts "PASS" if browser.text.include? "Wikipedia"

A fenti kód a Watir API-t használja, ami egy eredetileg az Internet Explorerhez fejlesztett, Ruby nyelven írt tesztalkalmazás. Mostanra már Operára, és több más böngészőre is portolták.

Az alábbiakban szeretnénk összefoglalni a nemrég megjelent Opera Unite-al kapcsolatos kérdéseket és válaszokat. Segítségül - autentikus forrásként - az Opera hasonló oldalát vettük alapul, így igyekezvén kizárni a tárgyi tévedéseket. Az alábbiakban ennek a szabad fordítását olvashatjátok. Dőlt betűvel szerepelnek az általunk esetlegesen hozzáfűzött megjegyzések.

A cikk egy több részes sorozat harmadik része. Az első rész témája a Unite, úgy általában, a második rész pedig a Unite alkalmazásokról szól.

Mi a helyzet a biztonsággal?

Az Opera Unite egy "biztonságos homokozóban" fut, ahonnan csak az általunk megadott fájlok és mappák érhetők el. A számítógép további erőforrásaihoz nem férhet hozzá senki más. Csak egy megadott könyvtrhoz adsz elérést, más területeket nem érhetnek el. Ez a webszerverek egyik jellemző tulajdonsága, és az elv hosszú idő óta ismert.

Az Opera biztonságos böngészők terén elért kimagasló eredményei, és a kiterjedt tesztelés a fejlesztés teljes folyamata alatt magabiztossá tesz bennünket a Unite biztonságosságát illetően. Ugyanakkor, mint minden internetelérésre alkalmas szoftver esetén, nem szabad elfeledkezni az Opera legfrissebb verzióinak használatáról. Az Opera Unite mellett az Opera 10.10 tartalmaz egy beépített frissítéskezelő funkciót, amivel könnyedén biztosítható a legújabb gyors kiadások követése. Ha bármilyen kétség merülne fel a biztonságot illetően, javasoljuk a Biztonság és privát szféra (Security and Privacy) rovatunk tippjeinek olvasását.

Az Opera Unite és a minialkalmazások biztonságosságával kapcsolatban hamarosan érkezik egy részletes bemutató cikk.