Kedves olvasóim, elköltöztem!

Amennyiben RSS-en keresztül olvasod ezt a bejegyzést, kérlek változtasd meg az új címre: http://adambrunner.blogspot.com/feeds/posts/default?alt=rss

Üdvözlettel,
adambrunner

Bent merült fel ismét a probléma, hogy hogyan lehet a legegyszerűbben lecserélni egy szövegben a benne található webcímeket (URL) kattintható HTML linkekre. A megtalálásuk igazából annyira nem volt bonyolult, aki írt már pár reguláris kifejezést (regular expression), annak szerintem egy 10-15 perces ujjgyakorlat:

/(?:[a-z]+:\/\/)?(?:\S+?(?::\S+?)?@)?(?:[a-z0-9][a-z0-9-]*[a-z0-9]\.)+[a-z]{2,6}(?:(?:\/|\?).*?(?=\s|<|$))?/imx

Viszont mi van azokkal az URL-ekkel, amik elé nem lett kitéve a protokoll azonosító (pl. http://)? Erre találtam ki azt, hogy – úgysem tudjuk elkerülni azt, hogy ne csak egy preg_replace() legyen – akkor minden href-be rakjuk bele egyből a "http://"-t az elejére és majd utána cseréljük le a "http://protokoll://"-t a "protokoll://"-re.

A kész és működő kód itt látható:

preg_replace(
    array(
        '/
        # protocol (optional)
        (?:[a-z]+:\/\/)?         # username:password@ (optional)
        (?:\S+?(?::\S+?)?@)?
        # domain name without tld
        (?:[a-z0-9][a-z0-9-]*[a-z0-9]\.)+
        # tld
        [a-z]{2,6}
        # path, query string, fragment (optional)
        (?:
            # path separator (slash) or query string separator (?)
            (?:\/|\?)
            # anything until a whitespace, tag opening character (<) or EOL or EOF
            .*?
            (?=\s|<|$)
        )?
        /imx',
        '/http:\/\/([a-z]+:\/\/)/'
    ),
    array(
        '<a href="http://$0">$0</a>',
        '$1'
    ),
    $text
);

Amennyiben találnál olyan URL-t, amire a fenti kód nem működik, kérlek tudasd velem és tovább finomítom. URL-ek, amiket próbáltam már (HTML tag-ek között is):

• username:password@example.com/path/file.html?queryString
• http://example.com
• https://username@example.com/path?foo=bar+baz#fragment
• sub.example.com?foo=bar

Tegnap eléggé összezavart egy PHP viselkedés, amiből bug report is keletkezett. Mikor reagáltak rá, logikussá vált a viselkedés, viszont még több kérdés merült fel bennem. Ma bent beszélgetem erről Zolival és benne is – remélhetőleg – ugyanazok a kérdések merültek fel, mégpedig: "mi értelme van PHP-ban a print nyelvi elemre?"

A probléma

Debugolás közben sok-sok if-elseif tesztelése közben, hogy egy helyre miért nem megy be, a következőt írtam be:

...
elseif (print($foo) && $foo == 'bar') {
...


Ennek hatására váratlanul megjelent egy "1"-es a kimenetben és az eddig kihagyott elseif ágba bele futott a program. Nem értettem! A végén a következő tesztig jutottam, amit végül reportoltam is:

var_dump(print('') && false); // int(1)

viszont ha a két feltételt megcseréltem, a kimenet bool(false) lett.

Valós működés

Szóval elmagyarázták, hogy igazából ilyenkor olyan, mintha a print után nem is raknánk a zárójeleket, tehát a példám a következővel egyenértékű:

print ('' && false); // ''

Viszont a print()-nek a visszatérési értéke int(1), innen a var_dump(); kimenete. És ekkor felmerült bennem a kérdés, mert igazából semmi nem indokolja a létezését:

1. nem használható ki, hogy "függvényként" használható;
2. nem adható neki több argumentum, csak 1;
3. lassabb, mert a visszatérési értéket is inicializálni kell;
4. félrevezetheti a fejlesztőket.

Van valaki, aki szerint bármi értelme is van?

Mellesleg ugyanez a helyzet az include/required nyelvi elemekkel is, azoknál sem kellene szerintem a zárójeles szintaktikát elfogadni, mivel ott is fennáll a fenti print()-es probléma!

Zoli amúgy arra tippelt, hogy azért "kellett", mert a C-ben is van, és hát azon alapszik – vagy valami ilyesmi.

Történt is mostanában, hogy szükség lett volna arra, hogy a Flash egy bizonyos anchor-hoz ugorjon – megszokott <a href="#header" /> megoldás HTML-ben –, szóval gondoltuk tök egyszerű lesz, hogy navigateToUrl('#header'); és boldogság!

Minden szépen és jól működött, amíg meg nem próbáltuk Safari alatt – OS X és Windows egyaránt –, és tapasztaltuk, hogy bizony az a fránya Flash valamiért az egész oldalt újratölti.

Megnéztem, ha HTML-ből egy link segítségével ugrok a #header-hez, akkor nem tölti újra, csak Flash Player-ből hívva, ebből is a következtetés, hogy Flash Player bug.

Ideiglenesen a navigateToUrl()-nek JavaScript hívást adunk át, így áthidalva a problémát, de szeretünk gondolni a JavaScript-et nem engedélyező látogatókra is!

Valaki valami megoldást?

Igen, ez a nagy kérdésem, hogy hogyan is lehetne ezt? Flash-ben bekövetkezett eseménykor szeretném, ha értesülne róla a JavaScript, tehát, hogy a beágyazott Flash Applet egy JavaScript event-et dispatch-eljen.

Valaki tud rá megoldást?

Nem, a fix metódusnév meghatározása nem jó, az nem Event driven megoldás lenne, és nekem nem is jó most!

Update: Kicsit kifejteném, mert kaptam visszajelzést, hogy nem eléggé érthető.

Amikor rákattintunk egy gombra, akkor az egy "click" típusú Event-et dispatch-el. Ugyanakkor lehetőségünk van arra is, hogy saját típusú Event-eket dispatch-eljünk, amikor csak akarunk. Ugyanilyen "tudással" bír az általunk beszúrt <object /> elem is, ami a fentebb említett Flash Applet-ünket tartalmazza. Na, én ebből a Flash Applet-ből szeretnék valahogyan az őt tartalmazó <object />-ünkön egy saját típusú Event-et dispatch-elni.

Ha valaki még mindig nem értené, szívesen elmagyarázom bővebben!

Igazából nem volt szó másról, minthogy egy oldal lekérésekor a teljes megjelenítési időnek:

• a 10%-a szerver-oldalon történik;
• a maradék 90% viszont a kliensnél, így ezen lehet a legtöbbet gyorsítani
  • a kliensnél 10% a HTML letöltése és feldolgozása
  • a maradék 90%-on osztozkodnak a JavaScript, CSS és egyéb média file-ok.

Az oldal felépítési optimalizációról később szeretnék majd írni, mivel úgyis kell belőle egy előadást tartanom a cégnél.

Ezen kívül sokszor elhangzott a widget kifejezés, mely most számomra új értelmet nyert. Itt most nem arról volt szó, hogy egy 3rd party widget-et szúrsz be az oldaladba, és ez tök jó lesz, hanem, hogy az oldalad felépítéséből adódóan — a HTML oldalak dobozokból épülnek fel — ezekre a dobozokra külön entitásként, widget-ként kell tekinteni, és egyesével érdemes őket lefejleszteni, kezelni. A közöttük fellépő interkaciót pedig ún. publish/subscribe módszerrel megvalósítani, ami a gyakorlatban event-ekre propagálást jelent JavaScript-ben.

Szó volt még a Client-side template-ekről, amiknek én nem nagyon látom értelmét, pláne, hogy azokat a szervertől kérnénk le minden esetben. Persze ha igény van rá, akkor kifejthetem!

• Architectures for scaling AJAX applications
• The Power of Refactoring
• Keynote — Web Standards to make life easier
• Ignore the DOM

Majd igyekszek írni mindegyikről, igérem!

Azt kell, hogy mondjam, a helyiek kitettek magukért rendesen! A szervezés nagyon jóra sikerült, a kaják és minden egyéb remek, azt hiszem a képek magukért beszélnek!

Bevezetés

Ma egy teljesen jó Keynote-on sikerült részt vennem.

A Kaazing.org egyik alapítója, Jonas Jacobi beszélt a jelenlegi HTTP hátrányairól. Legfőképp a Half-Duplex problémát és a ma egyre terjedő RI alkalmazások — számára a RIA "Richer, and Interactive Applications"-t jelenti — miatt felvetődött igényeket taglalta.

Előkerült, hogy a w3c és a HTML5-öt fejlesztő egyéb csoportok 2022-re tervezik kiadni a végleges specifikációt, ugyanakkor elmondta, hogy nem kell aggódnunk, azért is ilyen távlati időpontokat adnak meg egy-egy specifikáció véglegesítésére, mivel ha azt mondanák, hogy a specifikációt mondjuk 2010-re véglegesítenék, akkor azt megvárnák a böngésző-fejlesztők és ezzel önmagunkat hátráltatnánk. Emiatt viszont, hogy 2022-re tették a véglegesítés időpontját, a böngésző-fejlesztők apránként — ahogy az a <canvas> elemmel is megtörtént —, a véglegesítése előtt már implementálni kezdték.

Megoldás (?)

Hogy mi az, amivel Jacobi a megváltás reméli számunkra, RIA fejlesztőkre? A neve WebSocket. Igazából nem másról van szó, mintsem, hogy engedjék a böngészők, hogy hozzáférjünk a TCP réteghez, ami ugyebár a HTTP alapja, és így kétirányú, Full-Duplex kapcsolatot építhessünk ki.
var myWebSocket = new WebSocket('ws://my.example.com/application');


Ennyi a kód, amivel létrehozhatunk majd JavaScript-ben egy ilyen WebSocket-et. Ennek az objektumnak három Event Handler-t állíthatunk be:

• Open
• Message
• Close

Open

Amikor a kapcsolatunk létrejött hívódik meg.

Message

Minden, a szerver által push-olt üzenetkor hívódik meg. A kapott üzenetet az Event Handler-nek átadott event objektumon keresztül érhetjük el.

Close

A kapcsolat lezárásakor hívódik meg. Ezt a lezárást mind a kliens, mind a szerver kezdeményezheti.

A lényege

A WebSocket Server bármikor küldhet üzenetet a kliens számára, így nem kell a kliensnek a mai megoldásokkal időközönként ping-elni a szervert. Ezzel a megoldással időt, pénzt spórolhatunk meg:

• Időt és pénzt, mert az ilyen alkalmazások (IM, mail, tőzsdei figyelő, játékok, stb.) fejlesztési ideje töredékére csökken.
• Időt, mert az eseménykor azonnal megjelenik a kliensnél az eredmény, nem csak X idő múlva.
• Pénzt, mert felesleges sávszélességtől kíméljük meg a szerverünket.

Nagy jövőt látok a WebSocket-ben, szerintem hatalmas fejlődés lesz az internet történetében ez, az 1992-es HTTP modellt megújító megoldás! Mostmár csak a böngészőknek kell implementálniuk a WebSocket-et, amint lesz belőle draft specifikáció.

Kint vagyok, majd később írok is az itt látottakról, hallottakról. Két előadásonvagyoktúl, remélem a többi is ilyen jó lesz!

• IPC2008 — WebSocket az Internet új úttörője

..., mindezt tegnap vettem észre. Rég nem kellett már használnom, ezért sem tűnt fel, pedig az Apple még szeptember végén adta ki ezt a frissítést. Hát igen, mostanában — már vagy másfél éve — nem dolgozok itthon egyáltalán, emiatt sem volt a jEdit-re szükségem. Most is csak egy bent felfedezett Internet Explorer-es renderelési bugot akartam megfejteni, és írni róla ide, emiatt indítottam volna el. Nem indult! Google-ben keresés után akadtam rá erre a cikkre. Ami érdekes, hogy ha a jedit symlink-et a megfelelő útvonalra is módosítom, akkor sem fog működni! Vajon ez az egész helyzet amúgy most kinek a hibája? jEdit fejlesztők csináltak valamit szarul, vagy az Apple módosított önkényesen? A /System/Library/Frameworks/JavaVM.framework/Versions/ alatt egy rakat symlink (dőlt) és könyvtár található:

• 1.3 ⇒ 1.3.1
• 1.3.1
• 1.4 ⇒ 1.4.2
• 1.4.1 ⇒ 1.4
• 1.4.2
• 1.5 ⇒ 1.5.0
• 1.5.0
• 1.6 ⇒ 1.6.0
• 1.6.0
• A
• Current ⇒ A
• CurrentJDK ⇒ 1.5

A jEdit eredetileg a A/-ra mutatott, szerintem a legjobb itt is a Current/ lett volna, de szakértők szerint ez sem megoldás, mivel ilyenkor nem kapta volna meg az ott található JavaApplicationStub az eredeti könyvtárat, és emiatt nem működött a frissítés után a jEdit. Szóval a megoldás az az lett, hogy a JavaApplicationStub-ot át kellett másolni jedit néven. Bámulatos. És akkor most a következő Java VM frissítéskor mi lesz?

Megnéztem, és már az elejétől ámulatba ejtőek a képek, amik fogadnak. Végig kísérnek az élénk színek, a látványos elemek, a történet... és hát a mi kis hősnőnk, Alexandria (Catinca Untaru): tüneményes, aranyos, édes, megfogó! És remekül játszik!

Nemrég megjelent egy blogmark a weblabor.hu-n egy cikkről. A cikk írója szerint 10 ujjas gépelés nélkül nem lehet az ember jó fejlesztő. Szerintem pedig nem a gyors írás a jó ismérve a jó fejlesztőnek, hanem az, hogy jól működő —, hiba mentes — kódot írjon. Vagy talán nincs igazam?

Példálozzunk az Apple, vagy a Microsoft fejlesztőivel. Persze, tök jó lenne, ha "évente" jönnének az új OS X-ek, meg Windows-ok, de nem hiszem, hogy ezen múlik.

Vagy tanuljak meg én is 10 ujjal gépelni, nem csak 8-cal, és akkor én is tök jó leszek, minden háttérszemlélet nélkül?

Amint azt ígértem korábban, egy újabb felfedezett bug-ot írok le. Úgy egy héttel ezelőtt ráment egy egész délutánunk, hogy rájöjjünk a megoldásra.

Kitérő

Egy eléggé nagy oldalnak a sitebuildere vagyok, így eléggé érdekes dolgokba tudok belefutni. Egy más oldalakba beágyazható videólejátszót készültünk a publikum számára elérhetővé tenni, viszont a tesztek során — ami persze a fejlesztés során minden más böngészőben (fejlesztés alatt Mozilla Firefox és Safari böngészőket használok) jól működött — előjött, hogy Internet Explorer-ben természetesen nem működik tökéletesen.

Alap elgondolásban úgy működött volna az egész, hogy a felhasználó egy állandó kódot ágyaz be az oldalába, mert ezt természetesen később nem tudjuk megváltoztatni, ahogy a youtube.com sem tudja. Így a beszúrt lejátszó útvonala tartalmazta volna a videó azonosítóját és query string-ben egy szín hexa kódját, ami a videó háttérszínét határozhatja meg.

Ezután a megadott URL mögötti kis okosság tovább dobja a lejátszó aktuális címére, query string-ben a videó azonosítójával, a megadott színnel és egyéb paraméterekkel felvértezve.

Példában: <object/> forrásának ez van megadva: http://example.com/videoid?color=eeeeee, ami átirányit így: http://example.com/player.swf?id=videoid&color=eeeeee&foo=...

Szóval ez volt az alap elképzelés, de valamiért csak a color változót látta a lejátszó, és nem értettük! Végül rájöttünk!

Megoldás

Az ActiveX-es Adobe Flash Player valamilyen okból kifolyólag a beszúráskor, tehát a HTML-ben megadott query string-et veszi alapul flashvars-nak. Az átirányítást figyelembe veszi, tehát a végleges cél flash file-t fogja betölteni, de az ott megadott query string-et már nem fogja flashvars-nak beadni. Ez csak akkor történik így, ha a HTML-ben van query string. Ha nincs, akkor az átirányításkor megadott query string-et teljes mértékben felveszi a flash applet. Megoldásként tehát azt alkalmaztuk, hogy nem color=eeeeee, hanem a videó azonosítójához hasonlóan, az URL részeként kell átadni.

Példában: http://example.com/videoid/eeeeee és ezt már átirányíthatjuk az előbb megadott címre, és az applet is jól fogja lekezelni.

Szóval újfent azt mondom, hogy utálom az Adobe Flash-t!

Minden simán ment, amíg a flash applet nem akarta használni az ExternalInterface-t, ugyanis bár meghívta a JavaScript metódust, de annak visszatérési értékét már nem kapta meg. Internet Explorer alatt. Csini mi?

Három napi bugkeresés után rájöttem, hogy ha a jQuery append(), prepend() vagy html() metódusok egyikével szúrom be a generált HTML-t, akkor bizony nem működik, ha pedig innerHTML-lel, akkor igen. Az már külön hab volt korábban a tortán, hogy ha nem generálok Internet Explorer alatt az applet-nek ID-t, akkor ugyan nem kapja meg az applet ígyse-úgyse a visszatérési értéket, de legalább JScript hibát is dob.

Mostanában jelent meg az Adobe által megvásárolt Flash Player új, 10-es verziója. Szükség is volt az új verzió kiadására, mivel nemrég jelent meg a CS4, amit telepakoltak ugye új "jóságokkal", aminek sokan örültek, mert most majd húdejó csillivilli effektekkel tudják ellátni, az amúgy is lassan erőművet igénylő oldalaikat.

Értem én, hogy fejlődik a technika, újabb és újabb ötleteket gyártanak Adobe-nál is, amit szeretnének millió oldalon használva látni, és milliárd gépen futni látni. Viszont mi lesz majd azokkal a hibákkal, amiket — ugye egyrészt az új funkciókkal beletettek, és amiket — korábban benne hagytak?

Későbbiekben — eddig kettőt biztosan — fogok írni ezekről az idegesítő hibákról, amiket munkám során megtapasztaltam vele kapcsolatban. Ezek nem csak a Flash használatával, belső működésével kapcsolatos hibák lesznek majd, hanem a már elkészült applet-ek beszúrása kapcsán előtárulkozó idiótaságok is.

Szóval köszöntsük az új verziót, várjuk a hibajavításokat (9-es playerből 124 release készült, szóval lesznek)!

Szeretném a nyaralások alkalmával készített fotókat könyv formájában is a polcra helyezni. Erre annó ugyebár alpból a fotóalbumot használtuk. Kétoldali ragasztó, előhívva a fotó az ofotértben, és már ott is díszelgett.

Manapság a digitális időkben ez nem annyira móka, sokkal nagyobb az elvárásunk.

Normális fotóalbumot akarok, amit akár a könyvesboltban is árulhatnának. Erre több megoldás is létezik:

• Otthon kinyomtatom, könyvkötészetbe elviszem: hátulütője, hogy nem tudod jó minőségben kinyomtatni szerintem otthon, pláne nem tartósan, és nem olyan minőségű papírra. A borítót meg pláne nem tudod megcsinálni jól!
• Gyorsnyomda: nem érzem, hogy szintén jó minőséget produkálhatna, jó áron (egy példány).
• Digitális nyomda: jó minőség, valószínű egy példány miatt vagy nem állnak velem szóba, vagy horribilis áron.
• Online könyvrendelés: ez tűnik a megfelelőnek, de vajon melyik? Van kismillió, mint az interneten bármiből (Apple Book, Blurb, VioVio, MyPublisher, etc.)
• Apple Book: a választásom.

Azért is az Apple Book, mert a neten különböző blogokat olvasva ők nyújtják:

1. a legjobb minőséget;
2. elfogadható árat;
3. gyors teljesítést (állítólag 1 hét);
4. nagyon jó supportot (tapasztaltam már, tényleg jók!).

Vagy van valakinek más javaslata? Esetleg próbálta már valamelyiket?

Amit igazából szeretnék, az elvárásaim:

• kemény borítás;
• úgy 80-90 oldal;
• remek minőség.

Újra elérkezettnek láttam az időt arra, hogy megosszam a publikummal a véleményeimet, szenvedéseimet, ötleteimet, tapasztalataimat.

Remélhetőleg lesz majd itt szakma (web), fotó és új vásárlt dolgok által keltett érzésekről szóló bejegyzések is.

Ez egy blog szerűség, amit naplóként is szoktak emlegetni, szóval ha valakinek nem tetszik a véleményem, leírhatja — ha engedem majd —, vagy nem kell legközelebb ide látogatnia!