Monthly Archives: szeptember 2008

Böngészőim harca

Az elmúlt héten két kedvenc böngészőmet, a Safarit és a Firefoxot illetően áttértem azok fejlesztői változatára, a WebKitre és a Minefieldre. A döntést egyik esetben sem bántam meg, mind a két esetben egy stabil és gyors böngészőt kaptam cserébe.

A Safari esetében a váltást az indokolta, hogy a WebKitbe épített fejlesztői eszközök jóval fejlettebbek, mint amit a Safaritól kapok, míg a Firefox esetében az új TraceMonkey JavaScript motort szerettem volna kipróbálni. Mind a két böngésző gyors, és jól használható, és nem is fagynak többször, mint stabil kiadású párjaik, de ahogyan a Chrome-nál sem, a felhasználói élményt illetően egyiküknél sem észleltem kiemelkedő gyorsulást.

Firefoxból a legfrissebb, TraceMonkey-t is tartalmazó változat letöltését javaslom a Mozilla FTP-jéről, minden operációs rendszerre megtaláljuk a legfrissebb változatot. A TraceMonkey-t engedélyezni kell a telepítés után, amit az about:config oldalon, a javascript.options.jit.content (esetlegesen a javascript.options.jit.chrome - ha magába a Firefoxban is szeretnénk a gyorsabb motort használni) változó true-ra állításával. Engem az új, a fülek közötti látványos váltás működése (miszerint nem a fülek között egymás után, hanem a legfrissebben látott fülek között egymás után lehet váltogatni a Ctrl-Tab segítségével) igencsak zavart, ezért még a browser.ctrlTab.mostRecentlyUsed változót is false-ra állítottam. Ezek után egy újraindítás kell, és voálá, máris lehet tesztelni.

A legfrissebb WebKit-et a http://nightly.webkit.org/ címről lehet letölteni, Mac OS X alatt problémamentes volt a telepítése, Windows alatt halvány emlékeim szerint egy már a gépünkön levő Safarit lehet felülvágni vele, egy script lefuttatásával.

A fejlesztői változatok nem csak a sebességben és funkcióikban tudnak többet, jobbat, de az újdonságokat is lehet próbálgatni velük.

HTML5, hamarosan a mozikban

Sőt, premier előtt is vetítik. Ian Hicks, a HTML5 mögött álló egyik guru prezentálta pár napja azt, hogy pár – főként béta állapotú – böngészőben már jópár lehetősége elérhető a HTML következő, a böngészőgyártókkal közösen fejlesztett változatának. A prezentáció videója elérhető a YouTube-on, a példakódok pedig a WHATWG honlapján.

A következőkről esett szó a prezentációjában:

  1. Az új <video> elem videó beágyazására (00:35)
  2. Cross-domain kommunikáció postMessage()-dzsel (05:40)
  3. Helyben tárolt adatok localStorage segítségével (15:20)
  4. Átmenetileg helyben tárolt adatok sessionStorage segítségével (21:00)
  5. Drag’n'Drop a Drag and Drop API-val (29:05)
  6. Webalkalmazás állapotkezelés az onhashchange segítségével (37:30)
  7. Az új form elemek (40:50)
  8. Az új <canvas> elem (56:55)
  9. Kliens oldali validáció (1:07:20)
  10. Kérdések és válaszok (1:09:35)

A prezentáció kifejezetten hosszú, másfél órás, ennek ellenére ajánlani tudom a megtekintését, már csak annak a stílusnak a megfigyeléséhez is, ahogyan élőben kódol. Ja, a canvas elem prezentációja sem lett randa…

Dinamikus vagy statikus?

A Google hivatalos webfejlesztőknek szóló blogjában arra kér minket, hogy a dinamikusan (értsd: adatbázis jellegű forrásból) kiszolgált tartalmakat ne rejtsük statikus (értsd: GET paramétereket nem tartalmazó) URL-ek mögé. Szerintem hülyeséget beszélnek (ingyensört osztogattak?), de ezt kiegészítem azzal, hogy érdemes figyelni egyes tanácsaikra.

A blogban definiálják azt, hogy szerintük mi a statikus, és mi a dinamikus webcím:

Mi a statikus URL?

A statikus URL nem változik, és tipikusan nem tartalmaz URL paramétereket. Így néz ki például: http://www.example.com/archive/january.htm. Statikus címekre a Google keresőjében a filetype:htm definiálásával tudsz keresni. Az ilyen oldalaknak a a frissítése időigényes lehet, főként ha a tartalom mennyisége gyorsan nő – minden egyes oldal ugyanis kézzel készül. Emiatt a sok oldalból álló, gyakran frissülő oldalaknak, mint például a webáruházak, fórumok, blogok és tartalomkezelő rendszerek, dinamikus URL-eket célszerű használnia.

Nem igazán értem, hogy 2008-ban miért kell a DOS-os időkből ránk maradt HTM kiterjesztéssel példálózni, és hogy mi köze van a dinamikusan előálló tartalmaknak ahhoz, hogy dinamikus címet kéne használnunk. De nézzük a dinamikus URL definíciójukat:

Mi a dinamikus URL?
Ha egy oldal tartalma adatbázisban van tárolva és onnan van kiszolgálva a felhasználó kérésére, dinamikus URL-ek használata a célszerű. Ebben az esetben az oldal alapvetően egy sablonként szolgál a tartalom számára. Általában egy dinamikus URL így néz ki: http://code.google.com/p/google-checkout-php-sample-code/issues/detail?id=31. Egy dinamikus URL-t a benne levő ? = & karakterek segítségével tudsz felfedezni. A dinamikus URL-eknek megvan az a hátrányuk, hogy a különböző URL-ekhez ugyanaz a tartalom tartozhat. Vagyis egyes felhasználók esetlegesen különböző címeket használnak ugyanarra a tartalomra való linkeléskor. Ez egy ok, amiért a webfejlesztők statikus címekké szeretnék alakítani az URL-eket.

Ezt a logikát nem értem (vagy az angolom bűn rossz, és teljesen félrefordítottam – lehet). A statikus-dinamikus URL definícióját el tudom fogadni, avagy ha vannak GET paraméterek egy URL-ben, akkor hívjuk dinamikus címnek, ha nincsenek, akkor pedig statikus címnek. Az, hogy ezek az oldalak éppen adatbázisból, lemezről, memóriából, TDK SA90 High-Bias kazettáról vagy éppenséggel a nagymama lyukkártyájáról érkeznek, azt viszont nem mosnám össze azzal, hogy hogyan néz ki a címük.

Az ma már elég evidens megoldás, hogy a nagyon kis, vagy speciális weboldalak kivételével szinte mindenhol dinamikusan, programkód segítségével történő oldalkiszolgálás van a háttérben. Az is biztos, hogy azokat a tartalmakat, melyek jellemzően nem változnak az idő során, célszerű statikus URL-eken kiszolgálni.

A Google tanácsát nem szeretném azonban megfogadni. A http://webakademia.hu/2008/09/dinamikus-vagy-statikus URL ugyanis bár dinamikusan van kiszolgálva, de statikus, a hozzászólások és az oldalsáv kivételével változatlan tartalmat jelöl, és ha a hozzászólásokat vagy az oldalsávot viszonylag ritkán indexeli le a Google, akkor sincsen nagy gond. Ez az URL emberbarát, linkeléskor látni hogy várhatóan milyen tartalom van a cím mögött, sőt, még azt is, hogy milyen régi az a tartalom. Hozzáteszem, maga a Google alakíttatta ki velünk ezt a címet, mivel az URL-ben levő szöveges információt is felhasználja, és pozitívan díjazza a tartalmak rangsorolásakor.

De ez csak a bevezetése volt a bejegyzésnek, még folytatódik:

Statikussá alakítsam a dinamikus címeimet?
Íme néhány pont ami szem előtt tartandó a dinamikus URL-ekkel történő munka során:

  1. Elég nehéz helyesen létrehozni és karbantartani azokat az újraírókat, melyek a dinamikus címeket statikusnak tűnő címekké alakítják.
  2. Sokkal biztonságosabb az eredeti dinamikus cím kiszolgálása felénk, és a problémás paraméterek felismerésének és kezelésének ránk bízása.
  3. Ha át szeretnél írni egy címet, a dinamikusnak tűnő címek kezelésekor távolítsd el a felesleges paramétereket.
  4. Ha statikus URL-en szeretnél kiszolgálni dinamikus URL helyett, hozd létre a statikus párját a dinamikus tartalmadnak.

Az első pont nettó hülyeség. Ma már szinte a kezdő programozó is le tudja kezelni a statikusnak tűnő, ember- (és kereső-, de psszt) barát címeket, és a legtöbb CMS rendszer támogatja is azokat. Nem nehéz.

A kettes pontot illetően szép, hogy a Google saját magából indul ki, de azért mégiscsak úgy érzem, hogy nem a Google robotjának kényelmét kellene kiszolgálnom akkor, amikor eldöntöm, hogy milyen URL-eken szolgálom ki egy weblap bizonyos tartalmát. Ráadásul nem tudom, hogy miért lenne biztonságosabb rábízni a Google-re ezt a feladatot, amikor nagyon sokat tudok nekik segíteni akkor, amikor jelzem hogy mi a stabil, állandó tartalom az oldalon (statikus URL), és mi az, ami viszonylag gyakran változik, és a tartalom nagyban függ az URL-ben levő paramétertől (dinamikus URL).

A harmadik és negyedik pont ebben a megfogalmazásban nehezen feldolgozható.

Ezután FAQ jellegűen megpróbálnak eloszlatni pár tévedést, melyet most nem idéznék, de összefoglalnék és hozzáfűzném a személyes véleményemet:

  • A bejegyzés írója szerint tévhit, hogy a statikus/statikusnak tűnő URL-ekből álló oldal indexelése könnyebb lenne. Ők is jelzik, hogy a statikus URL-ek előnyösek lehetnek mert felhasználóbarátabbak. Ennek ellenére jelzik, hogy a dinamikus címeket kellene favorizálnunk a statikus helyett. Valahol értem a logikát, azt, hogy egy dinamikus URL-ekből álló oldalcsoport leindexelése, feldolgozása könnyebb lehet, de az teljes homály számomra, hogy a felhasználóbarát megoldással szemben miért javasol egy olyan megoldást a Google, amely minimális előnyt jelenthet csak számukra (szerintem ugyanúgy kezelni tudják egy statikus URL-ekből álló oldal indexelését, mint egy dinamikus URL-ekből állóét, az algoritmusban egyszerűen mást kell dinamikus résznek tekinteni).
  • Szeretnék eloszlatni azt a téveszmét, miszerint a dinamikus URL-eket nem (illetve nehezebben) tudja egy keresőmotor leindexelni. Azt írják, hogy problémájuk lehet abból, ha egyes a Google számára értékes információkat hordozó paramétereket esetlegesen elrejtünk, és azt tanácsolják, hogy tartozkódjunk a dinamikus címek statikussá tételétől. A miértre nem adnak kielégítő magyarázatot.
  • Azt a tévhitet is cáfolják, miszerint a 3-nál több paramétert tartalmazó dinamikus URL-ek használata gondot okozna a robotoknak. Szerintem gondot okozhat, az lehet hogy az ő robotjuk bírja a strapát.

A folytatást hanyagolnám, ugyanaz, mint amiről eddig szó volt. Még azt is megtudhatjuk, hogy a session azonosítóknak, és a nulla információt hordozó paramétereknek nem az URL-ben a helye (tudtuk). Ez az egyetlen értelmes és hasznos mondanivalója a bejegyzésnek.

A zárás:

Reméljük ez a cikk hasznos volt és segít a dinamikus címek körüli kérdések megértésében. Csatlakott bátran a vitacsoportunkhoz ha további kérdésed van.

Nem, nem volt hasznos, és ez látható a hozzászólásokból is. Mindegyikben ott a kérdőjel. Oké Juliane és Kaspar, jó vicc volt, most már viszont ideje lenne törölni vagy megmagyarázni ezt a bejegyzést. Nem április elseje van.

Lemaradás

Komolyan lemaradtam különböző témákról, és sajnos most sem tudom bepótolni a bejegyzések megírását, de remélem ami késik, az nem múlik. Most csak egy rövid bejegyzés lesz összefoglalva az érdekesebb, engem érintő témákat összefoglalandó, aztán remélem a következő bejegyzések már ki is fejtik azokat.

Megjelent a Google böngészője, a Google Chrome, remélem előbb-utóbb kihozzák Mac alá is. Nem lesz az én böngészőm még egy ideig, de az azóta eltelt napokban kiderült, hogy pozitív hatásai vannak ennek a lépésnek. Ami a legtöbb embernek a Chrome-ban tetszik, az valójában a WebKit-ből, Safariból jön, a hiper-szuper JavaScript motorból pedig gyakorlatilag semmit sem lehet érzékelni. Ennek ellenére egy kiváló JavaScript implementációnak tűnik, nagyon-nagyon kevés hibája, hiányossága van. Érdekes, hogy a megjelenése után a WebKit és a Firefox is kihozott egy-egy gyorsabb JavaScript motort. Elég durva részesedést is sikerült összehozniuk, ami a webes szabványoknak, a WebKit/Safari elterjedésének mindenképpen jó, hiszen szinesíti a böngészőpalettát. A fejlesztőknek persze nem jó, mert épp annyi különbség van, hogy most már Chrome-ban is kell majd ellenőrizni a weboldalakat.

Megújult a Zoom.hu, a megjelenése bőven előnyére változott legalább egy nagyságrendet, s jók a videóik, fotóik is. Bár sajnos kevés a tartalmuk még mindig, és túl ritkán változik a címlap, de határozottan léptek egyet jó irányban. Vannak technikai hiányosságaik, de most már úgy gondolom hogy egy az igényeikhez jobban illő motor van mögöttük.

A Netvibestól lelépek, a NowPublichoz pedig csatlakozom éppen (Drupal alapú közösségi médiaoldal). A Netvibes-szal szakmai szempontokból is érdekes két évet töltöttem el, és most úgy tűnik, hogy a NowPublic berkeiben is lesznek kihívások. A melókeresés folyamata tanulságos volt számomra, jó ajánlatokat kaptam innen-onnan, erről is igyekszem majd írni egy kicsit.

Beindulóban a WordPress alapú prémium blogszolgáltatásunk, a WPress.hu is, s bár ott is vannak elmaradások de a rendszer mindenképpen jól vizsgázik. Jó lenne végre a Webakadémiát is költöztetni rá. Ügyfél már van, a számlázással (szokás szerint) el vagyok még maradva.

Ideje lesz azt is bevallanom, hogy a window.name alapú keresztdomaines kommunikáció kapcsán csúnyán benéztem a dolgot, és úgy ahogy leírtam, a window.name nem alkalmas a feladatra, s még egy extra trükköt is be kell vetni hogy működőképes legyen (az adott iframe URL-jét át kell állítani átmenetileg saját domainre, hogy kiolvasható legyen a window.name tartalma).

Hát ennyi, jövőhéten nekikezdek a lemaradás bepótlásának.