Bevezető Levágása Reguláris Kifejezéssel

Pár napja munkahelyen (nah jó hetek óta) azzal vagyok elfoglalva, hogy kiganézzam a forrást. Rengeteg hülyeség van benne, de a legtöbb olyan, amire mindig felhívtam mindenki figyelmét, hogy ne használja. Node nem is erről akarok írni.

Bővebben

Kapcsolódó cikkek:

Heroku és a PHP

A Heroku ma bejelentette, hogy frissítették a PHP-s buildpack-et. Úgy látszik végül beadta a derekát és komolyabban veszi, mert nagyon sok PHP-s projekt került az elmúlt időszakban hozzájuk hosztingra. Mit kaptunk? Először is egy új Buildpack-et, amit így lehet elérni:

Bővebben

Kapcsolódó cikkek:

Google+ profil látogatottsági adatainak mentése

Nem is olyan régen a Google+ kihelyezte minden profilra (Page és magánszemély), hogy mennyien nézték meg. Az senkinek sem tiszta, hogy pontosan mit tartalmaz ez a szám, de az biztos, hogy állandó az ami alapján számolja. Egy oldalnak (Page) hasznos információ lehet, hogy ez a szám miként változik az idő folyamán. Miért? Ha például 4 napig senki se látogatta, akkor valami nem ok és valamit változtatni kell.

Bővebben

Kapcsolódó cikkek:

Reguláris kifejezés: Gyorstalpaló

A reguláris kifejezés nem mondanám, hogy fiatal. Nagyon kevés ember ismeri őket és még kevesebb úgy igazán. Gyakran előfordul, hogy megkeresnek ennek kapcsán emberek. Itt most nem 1-2 emberről van szó. A postafiókomban rákerstem a reguláris kifejezésre, ahol nem én vagyok a küldő és az elmúlt 6 hónapban 84 levelem van. Ez mind magyar levél és igen nagy százalékban kérdés.

Bővebben

Kapcsolódó cikkek:

Google Analytics API: report lekérdezés

Nagyjából mindenki ismeri a Google Analytics-et. Nagyon hasznos és tényleg sok energia lehet benne, mint fejlesztés. Szinte minden weboldallal rendelkező használja, mert nagyon hasznos információkat tud adni. Mennyien nézték az oldalt, honnan, mikor, mennyi ideig voltak ott és még sok, nagyon sok más információt.

Ez a cikk most arról fog szólni, hogy miként lehet ezeket az adatokat magunknak lekérdezni. Milyen hasznos lenne, ha nem kellene megírni egy “legtöbbet nézett” oldal listához, hogy mennyien nézték meg, ebből mennyi egyedi, visszatérő és hasonló. Nagyon összetett tud lenni egy ilyen, főleg ha nem csak azt akarjuk számolni, hogy hány oldalbetöltés volt.

Bővebben

Kapcsolódó cikkek:

JavaScript hibakeresés Táblázattal?

Mindenki jól ismeri a Chrome vagy a Firefox fejlesztést segítő eszközeit. Van egy általános objektumunk, ami a console névre hallgat. A console.log talán mindenki által jól ismert. A console.error és a console.warn függvényeket is ismertek sok helyen. Ezek a kedves barátok sokat segítenek, amikor JavaScript kódunkban szeretnénk megtalálni, hogy hol a hiba.

Bővebben

Kapcsolódó cikkek:

Hogyan lett 10 ponttal jobb a Mobile PageSpeed?

Manapság a mobil netezők száma igen nagy, ezért fontos, hogy gyorsan töltődjön be az oldal. Mobil felületen még inkább szembetűnő, ha nem gyors a weboldal. Ott jobban fáj mindenkinek. Tudjuk jól, hogy a tartalom felszolgálása az elsődleges és hogy annak minél előbb ott kell lennie a kijelzőn. Pár napja írtam egy cikket JavaScript: Google mondja! De igaza van? címmel, ahol azt taglalom, hogy milyen megoldások vannak JavaScript kódunk betöltésére. Hogy néz ki ez a valóságban? Éles példán keresztül nézzük most meg.

Úgy gondoltam, ha már ilyen szépen összeszedtem és bemutattam, hogy melyik módszer milyen hatással van a betöltési sebességre, ami ugyebár a keresők számára sem utolsó, akkor ránézek a [Dev] Folyam.info és a Folyam.info oldalakra is. Olyan 72 és 75 körül mozgott az átlagos Mobile PageSpeed index, ami nem mondom, hogy rossz, de azért nem is jó.

Első lépésben ami nagyon piros volt, mi lett volna, ha nem a JavaScript állományok betöltése. Ezek durván megfogták a böngészőt. Írtam, hogy az onLoad eseményre való betöltés sokat segíthet az oldal sebességének drasztikus növelésében. Legalábbis érzetre, mivel ugyan annyi idő lesz betöltenie a böngészőnek, de a különböző JavaScript fájlokat már csak akkor tölti be, ha az oldal betöltődött. Végülis milyen igaz, amíg nincs ott a tartalom minek Google+ komment, +1, Facebook like meg minden egyéb.

Alap JavaScript struktúra

Mivel a legkevesebb ACK-t akarom elérni az oldal betöltéséig, így a legfontosabb scriptrészeket egyből beágyaztam az oldal aljába. Ez nem más, mint egy nagyon alap Application objektum, aminek van egy delegate és egy init függvénye. Ezen kívül pedig az onLoad lekezelését valósítja meg. A delegate függvénnyel lehet új kódrészt hozzáadni az oldalhoz. Amik ide bekerülnek, azok csak azután futnak le, miután az onLoad esemény elsütését követően betöltődött az összes előre megadott JavaScript fájl. Ezek után szépen végighalad és meghívja mindegyiket.

0

Delegáció

Ezek után szépen felsoroltam a nekem kellő JavaScript kódokat, melyeket nem pakoltam külső fájlba, mert éppen nem érte meg nekem ezért a pár sorért. Lehet Egyszer kikerülnek, így nem is lesz használva, de az mindegy is most. Egy pár példa:

1

Töltsünk be mindent, ha kész az oldal

Már csak az egészet elindító onLoad esemény figyelését kell beállítani és kész is vagyunk. Ez hasonlóan egyszerű kód, hiszen hova bonyolítsuk. Itt gyorsan bele is futottam, hogy az én delegált kódjaimnak csak azután szabad lefutnia, miután már az összes külső fájl betöltődött, így logikusan a scriptek onLoad-ját is figyelni kell, de ezután jött, hogy nekem az összes után kell nem az első után. Nomeg aztán eszembe jutott, hogy a betöltésük sorrendje sem mindegy, mert ha például a jQuery-t használom és akarok hozzá egy kiegészítőt, akkor annak utána kell betöltődnie. Gyorsan el is mentem a Require.js oldalára, de mire betöltődött már fel is fogtam, hogy nem akarom ezzel is lassítani a rendszert. Csak azért, hogy a jelenlegi alacsony számú fájlomat kezeljem felesleges.

Nem maradt más, mint a rekurzió. Imádom és talán őrültje is vagyok, mert ahol lehet használom. Lehet néhe nem kellene, de akkor is. Tehát mikor elsül az oldal onLoad eseménye, akkor meghívok egy függvényt. Ez meghív egy újabb függvényt, ami kiszedi az első elemét a fájllistát tartalmazó tömbből és azt betölti. Beállítja onLoad-ra önmagát, így ha betöltődött az első elem, akkor betölti a tömb első elemét újta, de ugye az előzőt kiszedtem már, így az eredetileg második elem lesz most az első. Az egész függvény persze úgy indul, hogy ha üres, akkor meghívja a paraméterben kapott callback függvényt, amit jelen esetben az eredetileg meghívott downloadJSAtOnload definiált és nem más, mint az Application.init meghívása.

2

Mi történt ezután?

Tulajdonképpen nem lesz gyorsabb a teljes oldal betöltése és nem lett kisebb sem tőle az egész, de túlzottan nagyobb sem. Viszont most nem szórakozik a böngésző a Google, a Facebook vagy a jQuery betöltésével, amíg be nem töltött a tartalom, aminek köszönhetően az oldal betöltési ideje drasztikusan csökkent. Az eredetileg 72/75 pont helyett immáron 85 és 87 pont között mozog.

Egy kis plusz

Az összes képet, amit feltoltam a cikkekhez S3-ra optimalizáltattam az ImageOptim nevű ingyenes alkalmazással. Így nagyon sokat spóroltam az adatmennyiséggel.

imageoptim

Így végül elértem (Heroku ingyenes használattal belassíthatja néha neki) a 91/95 pontos éréket is. Így végülis 20 pont növekedést értem el vele. De a cikk elsősorban a JavaScript részről szólt 🙂

Te milyen praktikákat követsz? Mi az ami szerinted nagyon sokat ronthat az oldal betöltési sebességén és mégis sokan elkövetik a hibát?

Kapcsolódó cikkek:

Git Hooks: Automatikus generálás

preview-150x150 Manapság teljesen bevett szokás, hogy a CSS és JavaScript fájlokat tömörítjük.

Mikor a branchek között mozog az ember, akkor le kell futtatni egy plusz scriptet, hogy ezeket legenerálja. Ugyan így a CSS generáló nyelvek használata, mint a StylusLESS vagy az Sass. Az, hogy ki mit preferál az teljesen egyén és projektfüggő. Én például ha lehet Stylus-t használok, de Bootstrap használatánál sok esetben Less-t használok inkább, mert elérhető hozzá és könnyebb így testre szabni. De miként lehet egyszerűsíteni a folyamaton a Git segítségével?

Bővebben

Kapcsolódó cikkek:

Dropbox Datastore könyvjelző

Megjelent egy új szolgáltatás a Dropbox palettáján. Röviden összefoglalva adatbázisként is tudjuk használni mostantol. A legjobb, hogy JavaScript API kliens is jár hozzá, amivel később nagyon jól össze lehet hozni mondjuk az Angular.js-es alkalmazásukat.

Ez egy remek lépés volt tőlük, mert ha valaki ezt használja, mint fejlesztő, akkor rákényszeríti a felhasználóit, hogy rendelkezzenek Dropbox fiókkal. Most akkor készítsünk egy egyszerű könyvjelzőalkalmazást.

Első lépések

Miután persze már van egy Dropbox felhasználónk, létre kell hoznunk az alkalmazásunkat egy dedikált felületen, az App Console

Itt sok dolgunk nincsen. Kiválasztjuk a Dropbox API App lehetőséget, kiválasztjuk, hogy mihez szeretnénk hozzáférni. Jelenleg elég lesz a Datastore only opció is. Fájlokkal is lehet játszadozni, de azt most nem vizsgáljuk meg. Ha megvan, akkor adnunk kell egy nevet az alkalmazásnak. Jelen esetben ez a FolyamBookmark. Dropbox-ban egészen jól fejleszthető, mert csak https:// címeket fogad el, mint átirányítási cím. Ez alől csak a localhost kivétel. Tehát a legegyszerűbb, ha létrehozol egy fájlt (vagy letöltöd az itt elkészültet) és feltöltöd valami publikus könyvtárba Dropbox-on. Kapsz hozzá egy publikus címet és azt bemásolod mint Redirect URL. Egyedül a App key, amire szükségünk lesz egyelőre.

HTML

Gyorsan vázoljuk fel a html struktúránkat. Nem lesz sok nem kell félni 🙂

3

Nem hazudtam, mert tényleg nem sok 🙂 A lényeges pont a végén a JavaScript betöltés. Ez ugyanis a Datastores API kliens. Jelenleg még béta címkét kapott, de majd szépen átlendül ezen a fázison. Addig is nyugodtan lehet használni. Bár vigyázz, mert akinek nincs Dropbox fiókja az nem fogja tudnk használni, amíg nem csinál.

Alap JavaScript hozzá

4

Két lényeges pont látható. Jelen példánkban, ha valaki nincs bejelentkezve, akkor egy üres lapot lát maga előtt. Ez azért sem fájdalmas, mert gomb nélkül egyértelműen bejelentkeztetjük a felhasználót, mert most nem akarunk szívni mindenféle dekorációval.

A másik a kliens meghívásakor paraméterben átadott key. Ezt az előző lépésből jól megjegyeztük. Nem? Akkor lapozzunk oda, másoljuk át.

Ha sikeresen bejelentkezett a felhasználó, akkor kiírjuk, hogy ki is ő, nehogy véletlenül ne tudja. Milyen dolog lenne már?

Mielőtt továbbmennénk csináljunk neki valami arcot is. A <title> tag alá (de még a head zárótag főlé) másoljuk be a stílust.

5

A lényeg

Itt az ideje, hogy a már bejelentkezett felhasználónk érjük el az adatbázist. Nem olyan bonyolult ez, mint amilyennek hangzik. Mikor betöltődik az alkalmazás egyből megpróbáljuk azonosítani a látogatót. Ha sikerült, akkor betöltjük a felhasználó információit, majd kiiratjuk. Ezek után inicializáljuk az adatbázist és minden elemet kikérdezve beillesztünk egy li elemet minden linknek. Minden link mellé rakunk egy törlés gombot, hogy lehessen őket törölni. Az egész alatt egy beviteli mező ékeskedik és jelzi számunkra, hogy ide tudjuk beírni a kívánt címet. Ha itt egy entert ütünk, akkor elmentjuk adatbázisba, majd beillesztjük a li elemet.

6

Elnézést a simán csak összecsapott bemutatóért, de ezt most gyorsan le akartam rendezni, hogy +Robert Cartman ezzel kapcsolatos kívánsága mielőbb teljesülhessen.

A végeredmény használható formában elérhető Dropbox-on keresztül, amint átengedik a szűrőn. Publikáláshoz ki kell tölteni egy egyszerű formot, amiben megadod, hogy mi ez és hol érhető el. 🙂

Kapcsolódó cikkek:

URL rövidítő 3. rész

Ugye szeretnénk csinálni egy URL rövidítő alkalmazást. Nincs ezzel semmi baj, mert azt mindenki szeret csinálni. Leginkább azért, mert mindenki más ToDo alkalmazásokat csinál 🙂

Az első részben megtudtuk, hogyan működik az AngularJS. Ezek után, a második részben raktunk mögé egy Node.js-t, hogy erre tudjunk építkezni. Itt az ideje összekötni a kettőt. Amikor beküldünk egy linket, akkor a szerver állítson elő egy rövid címet hozzá. És itt jön a harmadik rész.

Szerver oldali rész

Természetesen mindenkinek ott figyel a gépén az eddigi kód. Akinek mégsem az eléri a Bitbucket tárólót és le bírja tölteni. Létrehoztunk egy /routes/index.js fájlt, amit nem használtunk. Legalábbis nem sok minden volt benne. A jelenlegi tartalma így néz ki:

7

Most akkor itt az ideje okosítani rajta. Ezt a függvényt békén is hagyjuk egyelőre, hogy a későbbiekben ne zavarjon meg minket az elnevezés. Hozzunk létre egy másik függvényt mondjuk addLink néven. Ezen kívül ugyebár hasznos lenne generálni is egyből egy rövid azonosítót neki. Tehát létrehozunk egy Link “Objektumot” is. Az, hogy most nem csak egyszerűen generálunk, később lesz hasznos, amikor majd adatbázisban tároljuk, mert akkor amúgy is ilyen formában fogjuk kezelni.

8

Az elején lévő sok kommentelt részt azért másoltam be, hogy látható legyen hova kell rakni. Az az 5 sor már most is ott van a kódban. Most tulajdonképpen megadtuk, hogy ha az alkalmazásunk kap egy POST kérést, aminek a célja a /link, akkor hívja meg a routes.addLink függvényt és majd az teszi a dolgát.

Ha készen van, akkor futtathatjuk az alkalmazást a jól megszokott node app.js parancssal. Tesztelni, hogy működik-e a legegyszerűbb, ha terminálból meghívjuk az url-t. Ebben nagy segítség tud lenni a curl nevű nagyszerű csomag.

9

Láthatóan szépen visszatért mind a rövid, mind pedig a hosszú linkkel, ha pedig nem adtunk meg linket, akkor a hibával.

Kliens oldali rész

Miután megcsináltuk, hogy a szerver tudjon mit kezdeni majd a kliens kéréseivel, jöhet a kliens. Ehhez nem kell más csinálnunk, csak megmondani az Angular.js-nek a /public/javascripts/app.js fájlban, hogy küldje fel a szerverre, majd az alapján írja ki a linket. Van most jelenleg egy ilyen szép controller-ünk:

10

Nah ezt kell kicsit megokosítani. Most ugyebár csak fixen beírjuk, hogy mik a link adatai és kész. Ezt kell megoldani, mert ez hoszú távon (más a második linknél) problémát okozhat.

11

Hosszúnak tűnik, de nem az csak telepakoltam hasznos kis kommentekkel. Tehát mi történik? Miután meghívódik az addLink függvény egyből elindítunk egy POST kérést. Az Angular.js $http modul függvényei nem paraméterként kérik be a callback-et, hanem úgynevezett ígérettel térnek vissza. Ennek az a logikája, hogy megígéri, hogy ott lesz adat és az ígéretnek van státusza, miszerint még nincs adat vagy van, eseteg hiba történt.

Jelen esetben, ha lefutott, akkor meghíva az általunk megadott callback függvényt, ami két paramétert vár (meg is fogja kapni), ami az adat és a válasz státusza. Egyből meg is nézzük, hogy mi a státusz és ha az nem 200, akkor hiba történt (például 500, 404). Ha nem volt hiba és 200-as kódot kaptunk, akkor megnézzük, hogy van-e error tulajdonsága a kapott adathalmaznak. Ha van, akkor a szervernek nem tetszett valami. Jelen esetben egy ilyen van, ha üres volt a link. Ha ilyen hiba előfordul, akkor szólunk a felhasználónak. Persze lehet kultúráltabban is, mint egy szép alert ablakot feldobatni, de most jó lesz ez is, lévén az oldal többi része se néz ki túl szépen. Ha készen van, akkor majd húzunk rá valami szép felületet is 🙂 Megígérem.

Ha nem volt hiba sehol, akkor a kapott adatokból a short értéket felölírjuk, mert most csak egy 7 karakter hosszú azonosítót tartalmaz, amiből valós linket kellene készíteni. Erre már ott van az App.utils.url.get függvényünk, azt nem is bántjuk most. Egyelőre. Ha megvan, akkor betoljuk a $scope.links tömbünk elejére, aminek hatására megjelenik az oldalon is.

Összefoglaló

Tudom, hogy megint nagyon sokat kellett várni a következő részre, de lassan megszokom, hogy buzgálkodjak ezzel is rendszeresebben. Míg egy “sima” cikk írása elsősorban kutatás, olvasás és írás, addig itt elő is kell állítanom közben a kódot.

Persze nem is arról szólt a cikk, hogy miért tartott ilyen sokáig. Az eddigi kliens és szerver oldali részt most összekötöttük. Persze még mindig nem mentettük el adatbázisba, meg úgy sehova sem az adatokat, de már legalább a két réteg beszélget egymással. Haladás.

Holnap vagy holnapután (tényleg) pedig rakunk bele egy MongoDB-t, amibe elmentjük az adatokat, persze előtte jól leteszteljük, hogy már létezik-e vagy sem.

Kapcsolódó linkek:

A forrás elérhető itt: https://bitbucket.org/folyam/url-r-vid-t

Demo: http://url-rovidito.folyam.info/

Kapcsolódó cikkek: