Amikor a Search&Replace visszanyal

Az IKEA katalógusban a következő szó: "epirosmény".

"Az igényeim telefonja" visszatekintés

Most olvastam vissza egy 2006-os írásomat egy korábbi blogomban az UnderConstruction-ön. A címe: "Az igényeim telefonja". Nézzük mit akartam akkoriban:

• A kijelzője legyen nagy, és nagyfelbontású, lehetőleg szélesvásznú (pl. 640×360);
• Touchscreen(?), bár nem tudom mennyire lehetne szerencsés ez egy telefonnál;
• Bluetooth és WLAN;
• Normális, szabványos böngésző Flash, JavaScript, CSS (és AJAX) támogatással;
• A kamerája tegye elérhetővé, hogy videohívásokat is tudjak lebonyolítani;
• Ebből következően legyen 3G kompatibilis;
• Skype támogatás a WLAN-on keresztül, ha elérhető a hálózat;
• Lehetőleg az OS ne Symbian legyen, bár nem tudom mi nyújthat még ekkora fokú bővíthetőséget;
• Office-dokumentum és PDF kezelő alkalmazás, lehetőleg írásra/olvasásra is;
• POP3 E-mail kliens, ami működik is(!);
• Minimalista megjelenés, nem kellenek vibráló LEDek, meg futófény és rajzolni sem szeretnék a fénnyel.

És most végigolvasva a listát, majd' teljesült a kívánságom. Már több, mint egy éve használom az első generációs iPhone-t, ami teljesíti a kívánságaimat! Ami érdekes, hogy az idő igazolta, hogy igenis használható a touchscreen. Az office dokumentumok módosítása pedig azóta mégsem hiányzik a videótelefonálással egyetemben.

step-by-step

Avagy, ha arra vetemedünk, hogyan is fogjunk hozzá a tanulásnak.

Webszerkesztő / sitebuilder:

1. Legyünk képesek a Photoshop használatára, legalább alapszinten.
2. Tanuljunk meg angolul, ugyanis minden(!), amire szükségünk lesz, angolul írják — maximum lefordították már magyarra / németre, de az soha sem pontos;
3. A web elengedhetetlen nyelve a HTML, ezért olvassuk át tüzetesen a w3c HTML referenciáját;
4. Mivel szemantikus és táblázatmentes oldalt akarsz csinálni, nem törődve az elavult technológiákkal, ezért szükséged van a Cascading Style Sheets alapos megismerésére;
5. Ezután, elképzelhető, hogy ki kell egészítened a készítendő oldaladat diszkrét JavaScript-tel (más néven ECMAScript), így annak sem árt, ha tudod, hol van a referenciája. Illetve, hogy hol vannak az MSIE specifikus dolgok leírva;
6. Fontos továbbá a DOM és az AJAX ismerete is, a jelenlegi tendenciát figyelembe véve, így ezek ismerése is hasznos lehet a további munkáid során.

Webfejlesztő:

1. Tanuljunk meg angolul, ugyanis minden(!), amire szükségünk lesz, angolul írják — maximum lefordították már magyarra / németre, de az soha sem pontos;
2. A web elengedhetetlen nyelve a HTML, ezért olvassuk át tüzetesen a w3c HTML referenciáját;
3. Nem árt, ha tudod, hol van a referenciája a JavaScript-nek (más néven ECMAScript). Illetve, hogy hol vannak az MSIE specifikus dolgok leírva;
4. Fontos továbbá a DOM és az AJAX ismerete is, a jelenlegi tendenciát figyelembe véve, így ezek ismerése is hasznos lehet a további munkáid során;
5. Ezekután jöhet az, amit tulajdonképpen tanulni is akartál, magának a programozási nyelvnek a megtanulása. Az mindegy, hogy Perl, PHP, Python, Ruby vagy ASP.
6. Kifelejtettem egy fontos dolgot, most pótlom. Tehát a komplexebb rendszerek kialakításához, ami kicsivel több már, mint egy “Hello World!” progi, általában szükséged van valami adatbázis használatára is. Ez többféle lehet, sokan használják a MySQL. Kisebb feladatokra ott van az SQLite, de ha jót, gyorsat, okosat akar az ember, akkor érdemes komolyabb adatbáziskezelőt használni, mint például postgreSQL.

Továbbá fontos lehet még pl. XML, XSL és XSLT vagy SOAP ismerete is és még sorolhatnánk, de azok már mind-mind feladatfüggő tudások, melyeket — persze feladattól függetlenül is, csupán kedvtelésből –, akkor kell csak megtanulnunk, ha szükségünk lesz rájuk.
És egy fontos dolgot ne feledj, mielőtt bármilyen kérdést is felteszel levelezőlistán, fórumon, chaten, bárhol, a manuálokban mindig minden benne van, csak a megfelelő helyen kell keresned. Gondold végig mit akarsz csinálni. Például mivel dolgozol — string, array, stb. –, és akkor a manuálnak egyből a megfelelő részén tudod keresni a megoldást. Ha netán nem lenne meg, vagy valami hibaüzenetet kapsz, hibajelenséget tapasztalsz, keress rá google.com-on, biztos, hogy az első pár találatban, de az első két oldalon ott lesz a megoldás a találatok között. Nem te vagy az első, aki belefutott ezekbe a problémákba, hiszen most kezdted az egészet. Nem fogod feltalálni a spanyolviaszt, még ha úgy gondolod is.

A listákról, fórumokról, csatornákról

Igen, akik segítenek, le fognak szólni, mert olyat kérdezel, amit te magad is megtalálhattál volna. Akik ott vannak, nem az a dolguk, hogy válaszoljanak. Ők egy közösség része, akik segítenek, ha úgy ítélik meg, érdemes az illetőn segíteni és látszik rajta a tanulásvágy!

Remélem tanulsz ebből is!

Képes inline gombok létrehozása sprite-tal CSS-ből

Gondoltam megosztom veletek, hogyan is szenvedtem végig, mire végre minden böngészőben ugyanúgy nézett ki.

Adott ez a HTML kód:

<a href="#">gomb</a>

CSS:

a {
    display: inline-block;

Sprite pozicionalasa a gombunknak.
    background: url(mysprite.gif) no-repeat 0 0;

A majdan kilogo szoveg elrejtese
    overflow: hidden;

A gomb mereteinek megadasa
    width: 16px;
    height: 16px;

Kitoljuk a szoveget a gombon kivulre
    text-indent: 16px !important;

Az elozo sorban levo !important azert kellett, hogy a "modern" bongeszok figyelmen kivul hagyjak a kovetkezo sort!
Internet Explorer 6 es 7 alatt is ha text-indent-et adunk egy inline-block elemnek, akkor azt margokent alkalmazza azt.
    text-indent: 0;

Firefox 2 nem ismerte meg az inline-block tipust.
    display: -moz-inline-box;

Firefox 3 alatt az 1px-es font meretet nem jelenitette meg, ha be volt kapcsolva, hogy minimum mekkora legyen a megjelenitheto betumeret. Emiatt megjelenhetett egy 1px magas "csik", ami a szoveg volt. Ez a betumeret eleg ahhoz, hogy a szoveg kicsusszon a kerning miatt.
    font-size: 100px;

Internet Explorer figyelmen kivul hagyja a height+overflow tulajdonsagokat, ha nagyobb a font meret a height-nel, es szethuzza a font meret megjelenitesehez szukseges meretre az elemet.
    line-height: 1px;

Amennyiben ez nincs megadva, Internet Explorer alatt osszevissza jelennek meg az elemek.
    vertical-align: top;

A tobb szavas szovegek becsuszhattak a megjelenitesbe Firefox 3 alatt.
    white-space: nowrap;
}

Apache Log Parser

Ma úgy hozta a sors, hogy szükségem lett volna egy Apache Log elemzőre PHP-ban, viszont nem találtam olyat, ami megfelelt volna, így megalkottam a sajátomat.

Ha szükséged van rá, használd egészséggel! Hiba esetén légyszíves írj mail-t a forrásban található e-mail címre, köszönöm!

A pixelben méretezett szövegeket az IE8 még mindig nem méretezi át

A 456Bereastreet.com legújabb cikkében arról ír, hogy az új IE sem fogja a szövegeket átméretezni, melyeket pixelben határoztunk meg.

Nem tudom, hogy mekkora haszna van ennek, főként, hogy hanyan használhatják. Én – nem hinném, hogy lustaságból –, pixelben adom meg a szövegek méretét. Mivel egy biztos, hogy az minden böngészőben és platformon ugyanúgy fognak megjelenni, nem függve attól, hogy a felhasználó pl. Windows alatt milyen dpi-t állít be a monitorára.

Ugyebár vannak módszerek:

body {
font-size: 62.5%;
}

És 1em az 10px lesz, viszont amikor eddig használtam, csak a baj volt belőle. Biztos bennem van a hiba…

Nincs megfelelő verziójú Office-om…

…legalábbis állítja az Office AutoUpdate által megtalált "Critical Update 12.1.5". De akkor miért találja meg a gépemen levő Office-hoz, ha utána az meg azt mondja, hogy nem is jó ez ennek a frissítésnek? Nem szeretem az ilyeneket!

A másik bug meg az, hogy ha átállítom magyarra a billentyűzet kiosztásomat, és írás után bármelyik navigációs gombot (nyilak) leütöm, visszavált angol kiosztásra. Hurrá, még mindig használhatatlan az Office!

URL-ek linkesítése szövegben

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( '/ (?<=\s|[^@a-z0-9]|>|^) # protocol (optional) (?:[a-z]+:\/\/)? # username:password@ (optional) (?:\S+?:\S+?@)? # ip address or domain name (?: # ip address (?:(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(?:25[0-5]|2[0-4]\d|[01]?\d\d?) | # domain name (?: # domain name without tld (?:[a-z0-9][a-z0-9-]*[a-z0-9]\.)+ # tld (?: ac|ad|ae|aero|af|ag|ai|al|am|an|ao|aq|ar|arpa|as|asia|at|au|aw|ax|az| ba|bb|bd|be|bf|bg|bh|bi|biz|bj|bm|bn|bo|br|bs|bt|bv|bw|by|bz| ca|cat|cc|cd|cf|cg|ch|ci|ck|cl|cm|cn|co|com|coop|cr|cu|cv|cx|cy|cz| de|dj|dk|dm|do|dz| ec|edu|ee|eg|er|es|et|eu| fi|fj|fk|fm|fo|fr| ga|gb|gd|ge|gf|gg|gh|gi|gl|gm|gn|gov|gp|gq|gr|gs|gt|gu|gw|gy| hk|hm|hn|hr|ht|hu| id|ie|il|im|in|info|int|io|iq|ir|is|it| je|jm|jo|jobs|jp| ke|kg|kh|ki|km|kn|kp|kr|kw|ky|kz| la|lb|lc|li|lk|lr|ls|lt|lu|lv|ly| ma|mc|md|me|mg|mh|mil|mk|ml|mm|mn|mo|mobi|mp|mq|mr|ms|mt|mu|museum|mv|mw|mx|my|mz| na|name|nc|ne|net|nf|ng|ni|nl|no|np|nr|nu|nz| om|org| pa|pe|pf|pg|ph|pk|pl|pm|pn|pr|pro|ps|pt|pw|py| qa| re|ro|rs|ru|rw| sa|sb|sc|sd|se|sg|sh|si|sj|sk|sl|sm|sn|so|sr|st|su|sv|sy|sz| tc|td|tel|tf|tg|th|tj|tk|tl|tm|tn|to|tp|tr|travel|tt|tv|tw|tz| ua|ug|uk|us|uy|uz| va|vc|ve|vg|vi|vn|vu| wf|ws| ye|yt|yu| za|zm|zw ) ) ) # port: 1-65535 (optional) (?::(?:[1-9]|[1-5]?\d{2,4}|6[0-4]\d{3}|65[0-4]\d{2}|655[0-5]\d|6556[0-5]))? # 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

print vs. echo, avagy szükség van mindkettőre?

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.

Újabb Flash bug(?) fragment-hez ugráskor

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?