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 🙂

0

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á

1

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.

2

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.

3

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:

4

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.

5

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.

6

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:

7

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.

8

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:

Ezért nem szeretem a jQuery-t

Mikor szóba kerül a jQuery, akkor majdnem mindig megkérdezik, hogy miért nem szeretem. Sok oka van, de a teljesítmény talán a legszembetűnőbb. Mivel a helyszínen sokszor nem tudom megmutatni, így nem is hisznek nekem, hogy mennyivel lassab egy-egy művelet vele.

Természetesen ez csak akkor jön ki, amikor valami nagyon nagy, főként kliens oldalon tevékenykedő kódot ír az ember. Sok könnyedséget ad, mert nagyon jól összeszedett. Még több öröm leli az embert, amikor talál valami plugin-t, ami pont kielégíti minden vágyát. A plugin meg amúgy is a rosszabbik fajta, de ezt most nem akarom elővenni, már csak azért sem, mert abban sokan egyetértettek velem, hogy a kiegészítő modulok nagy része nincs jól megírva.

Kód

Nézzünk is akkor egy gyors példát. Van egy div, amiben további kettő ezen mintára:

9

Írjuk át az item osztállyal rendelkező elemek tartalmát aszerint, hogy ezt kapjuk a végén:

10

Mi sem egyszerűbb ennél. Lekérdezzük az összes .item element, végighaladunk rajtuk, majd tartalmukat kicserélkül.

Nézzük sorra a jQuery, VanillaJs és természetesen egy bónusz vegyes kód, ami felhasználja mindkét kódot részben.

Hogy szó ne érjen beraktam még egyet a végén, ami nem a querySelectorAll metódust használja:

Hogyan mérjük?

Persze nekiállhatnánk írni egy új banchmark eszközt, de minek, ha már van. A Benchmark.js (v1.0.0) elég jól működik, jól konfigurálható és mindemellett a BestieJS része.

A logika egyszerű. Felsorakoztatjuk a kódrészeinket, majd szépen sorban lefuttatjuk őket, majd szépen elmerengünk az eredményen. Mikor ennek most nekikezdtem nem volt foglalmam róla, hogy mennyivel lassabbak vagy gyorsabbak az egyes kódrészek, de tudtam, hogy drasztikus lesz a különbség. Olyannyira az lett, hogy még én is meglepődtem.

Milyen gépről beszélünk

Persze ez nem mindegy. Aminél épp most ülök és amin nézem, az egy MacBook Pro. Mit tartalmaz? 2.6 GHz Intel Core i7 processzor, 8 GB 1600 MHz DDR3 memória. Google Chrome fut, mint böngésző és abból is a Version 28.0.1500.20 beta.

Természetesen ugyan ezen a gépen megnéztem más böngészőkkel is, de ezt majd lentebb látni lehet.

A mérés

Akkor mérjünk, hiszen ezért vagyunk itt. Miután leszedtük a Benchmark.js 1.0.0-ás verzióját, készíteni kellene egy oldalt, amin ezt leteszteljük.

És akkor az eredmények

Google Chrome (Version 28.0.1500.20 beta)

Start...
Vanilla x 868,471 ops/sec ±27.53% (75 runs sampled)
jQuery x 25,664 ops/sec ±6.36% (91 runs sampled)
jQuery with Vanilla x 233,890 ops/sec ±2.44% (90 runs sampled)
jQuery with Vanilla v2 x 31,845 ops/sec ±0.55% (96 runs sampled)
Vanilla old x 1,944,603 ops/sec ±0.68% (98 runs sampled)
Fastest is Vanilla old

Mozilla Firefox (21.0)

Start...
Vanilla x 360,292 ops/sec ±2.23% (89 runs sampled)
jQuery x 2,646 ops/sec ±1.52% (88 runs sampled)
jQuery with Vanilla x 11,772 ops/sec ±3.99% (88 runs sampled)
jQuery with Vanilla v2 x 3,572 ops/sec ±2.61% (85 runs sampled)
Vanilla old x 1,504,734 ops/sec ±6.73% (70 runs sampled)
Fastest is Vanilla old

Safari (Version 6.0.4 (8536.29.13))

Start...
Vanilla x 350,148 ops/sec ±6.72% (55 runs sampled)
jQuery x 20,689 ops/sec ±4.75% (61 runs sampled)
jQuery with Vanilla x 61,427 ops/sec ±4.71% (61 runs sampled)
jQuery with Vanilla v2 x 32,140 ops/sec ±3.68% (61 runs sampled)
Vanilla old x 1,652,603 ops/sec ±1.65% (64 runs sampled)
Fastest is Vanilla old

Értelmezés

Az ops/sec minél nagyobb annál jobb. Minden esetben jól látható, hogy a legygyorsabb a régi jól bevált getElementById és getElementsByClassName használata volt közel 2millió művelet másodpercenkénti sebességgel. Őt követte a querySelectorAll használata jóval kevesebb, de még mindig szép sebességet produkáló kódrész.

Ezek után jött az érdekes rész. jQuery három különböző használati mintával. Első esetben ugyebbár teljesen az ő függvényeit használtuk, így kiérdemelve a leglassabb díjat kicsit kevesebb mint 3ezer művelet másodpercenként. Hogy megnézzük mi is a gyorsabb és lassabb része, különszedtük és megnéztük, hogy milyen, ha csak az írást vagy csak az olvasást végzi a jQuery. Láthatóan ha csak a keresést végzi, akkor gyorsabb a lefutás, ezek szerint a DOM írás jQuery-vel jóval “drágább” művelet. A DOM írás amúgy is drágább, de jQuery-vel nagyon durván.

Kapcsolódó cikkek:

OpenSource, de miért?

A nyílt forrást (OpenSource) manapság azért szerencsére kezd elterjedni. Sokan még mindig félnek tőle, de egyre több cég nyitja meg szoftverének forrását. Vagy egy részét vagy egy régebbi verzióét. Amellett, hogy reklám, még haszna is van. A cikket +Laszlo Fazekas cikke inspirálta, Miért jó a nyílt forrás?! címmel. A cikk jól összeszedi, hogy gazdasági szempontból miért érheti meg forráskódunk megnyitása. A cikk viszont kevésbé tér ki a programozó világban betöltött jelentős előnyére, mégpedig arra, hogy miért éri meg egy nyílt forrású kódon segédkezni, miért éri meg saját otthoni fejlesztéseinket publikálni. Az ugye majdnemhogy egyértelmű, hogy senki se számíthat milliós támogatásra, ha csinál valami egyszerű kis programkönyvtárat vagy javít egy hibát valaki más kódjában. Akkor miért?

Bővebben

Kapcsolódó cikkek:

Grunt és Chrome kombó

Manapság már egyre több lehetősége van az embernek, hogy ne – úgymond – nyers CSS és JavaScript írásával kelljen eltöltenie idejének nagy részét. Persze mindegyiknek megvan a hátránya és az előnye is. Most nem is ezeket mutatnám be, hanem sokkal inkább azt, hogy miként lehet segítségünkre gyorsan és egyszerűen a Grunt munkánk során.

A cikk alján link a teljes forrásra.

Bővebben

Kapcsolódó cikkek:

Heroku megjött Európába is

A +Heroku elindította Európában is szervereit. Mostantól – bár egyelőre béta fázisban – létrehozhatóak olyan alkalmazások is, amelyek EU régióban futnak. Miért is jó ez nekünk? Mi is egyáltalán az a Heroku? Megpróbálom érthetően és röviden összefoglalni.

Bővebben

Kapcsolódó cikkek:

Google+ kommentek nem Blogger oldalon

Tegnap megjelent a Google+ Comments, ami egyelőre csak a Blogger rendszerében aktiválható elvileg. Mikor leültem tegnap a gép elé, pont akkor jelent meg előttem a hír. Szépen beúszott egy kis fade effekttel. Már abban a pillanatban tudtam, hogy bizony ezt nekem nagyon gyorsan ki kell operálnom és meg kell találnom a beágyazás módját.

Bővebben

Kapcsolódó cikkek:

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

Egy jó ideje volt már annak, hogy kikerült az első fejezet. Most úgy döntöttem, hogy mindenképpen lesz rá időm, akármi jöhet közbe, ma készen lesz a második rész is. Mi következik? És miért van ott az a macska? Az előző részben csináltunk egy primitív URL rövidítő oldalt pusztán HTML, CSS és AngularJS (JavaScript) használatával. Mielőtt tovább haladnánk, kellene hozzá valami háttér, ahol tárolva lesznek az URL-ek, ahol esetleg tudjuk tárolni, hogy mennyi kattintás történt. Tehát építsünk mögé egy Node.js keretet, ahogy azt már az előző részben is előre vetítettem. De mi is ez egyáltalán? És még most sem tudod miért van ott a kiscica?

Node.js alapok

Először is nézzük meg, hogy mi is ez a Node.js és mire való.

A Node.js egy szoftverrendszer, melyet skálázható internetes alkalmazások, mégpedig webszerverek készítésére hoztak létre. A programok JavaScript-ben írhatók, using eseményalapú, aszinkron I/O-val a túlterhelés minimalizálására és a skálázhatóság maximalizálására.

Wikipedia: Node.js

Az a using nem tudom mit keres ott, de hát ez csak egy idézet 🙂

Tehát az egész rendszer eseményvezérelt, ahogyan azt már megszokhattuk a JavaScript-től. Elsősorban a Google féle V8 motorra épül, de sok más könyvtár került beolvasztásra. Innen már úgy érzem érthető, hogy mi is ez. Röviden: Server oldalon futtatható JavaScript.

Használhatnánk PHP-t is, de most nem azt fogunk 🙂 Ha jól elboldogulsz böngészőben a nyelvvel, akkor itt még könnyebb dolgod lesz, mert nincs böngészőfüggő függvénykészlet és sokkal könnyebben modularizálható a kód. Ami a PHP-sokat meglepheti, de a Java vagy Ruby nyúzóknak teljesen normális, az az, hogy a Node.js önmagában webszerver is, tehát nem kell (sőt nincs is) külön mod_nodejs Apache-hoz, ráadásul nem is lesz. Apache sem kell hozzá.

Bemelegítés

Hogy értehtőbb legyen, hogy mi is ez csináljunk egy gyors “weboldalt”, ami szinte
semmit se csinál, csak megmondja nekünk, hogy péntek van-e és ha nincs, akkor azt is, hogy
hány nap van még addig.

11

Mit is jelent ez? Nézzük részletekben.

Betöltjük, ami kell

Először is találkozunk egy require sorral, ami sokat lesz használva. A require betölt nekünk egy libet vagy csak egy fájlt, de ezt a neve is jól mutatja. Itt máris megállnék egy kicsit. Összességében 3 lehetőség van, amikor betöltünk egy külső JavaScript fájlt.

  1. Simán beírjuk a lib nevét és az egy beépített lib, így nem kíván más teendőt, csak betöltöd és használod.

  2. Simán beírjuk a lib nevét és az egy külső (3rd party) lib. Ezeket telepíteni kell. Ruby nyelvészeknek ismerős lehet (gem).

  3. Beírod a nevet, de relatív hivatkozással, tehát .-al kezded a nevet, például require("./routes/url"), ami betölti az aktuális fájlunkkal egy szinten lévő routes könyvtárból az url.js állományt.

Jelen esetben mi a http libet hívtuk be, ami azért kell nekünk, hogy a szerver létezzen. Ennek a segítségével képes az alkalmazásunk figyelni egy porton és lekezelni a bejövő kéréseket.

Indítunk egy szervert

12

Meghívjuk az imént betöltött http lib createServer függvényét, aminek átadunk egy függvényt paraméterként, majd meghívjuk a listen függvényét, aminek megadjuk, hogy hanyas porton figyeljen az alkalmazásunk. Jelen esetben ez a 3000-es port. A createServer paramétereként kreált függvény fog lefutni minden oldallekéréskor. Két paramétere van, ami rendre a kérés (request) és a válasz (response) objektum. A kettőből most csak az utóbbit fogjuk használni.

Az érdemi kód

13

Gyorsan mindentől függetlenül tudatjuk a klienssel, hogy amit kapni fog az megvan és 200-as HTTP kódot tolunk át neki, amivel egy időben azt is megmondjuk, hogy a tartalom, amit kapni fog, egy sima egyszerű szöveg lesz, ami utf-8 kódolással lett írva. Jól látható, hogy a res objektumon keresztül kommunikálunk a klienssel.

14

Létrehozunk egy változót now néven, ami az aktuálus időt jelenti. Ez egy Date objektum, aminek mi a getDay függvényét fogjuk használni. A getDay megmondja nekünk, hogy a hét hanyadik napja van. A számozása nem “magyarbarát”, mert 0-val jelöli a vasárnapot, 1-el a hétfőt és így tovább egészen 6-ig, ami a szombatot jelenti.

15

Ebből eredően az 5-ös szám jelöli a pénteket. Ha az aktuális nap az 5. indexen helyeszkedik el, akkor péntek van. Ismét a res objektumhoz nyúlunk, hogy a kommunikálni kívánt adatot eljuttassuk a kliensnek. Most az end metódusát hívjuk meg, mert nem is lesz más, tehát le is lehet zárni. A későbbi sok else-if-else-if szórakozást elkerülve vissza is térünk ennek a kimenetével. Az, hogy ez a függvény mivel tér vissza, az teljesen mindegy, de mivel visszatérünk a kód többi része véletlenül sem fut le.

16

Aztán itt kell egy kis trükk, mert a 0. nap a vasárnap és a 6. nap a szombat, ami nálunk egyben a hétvégét jelöli. Tehát, az aktuális nap 0 vagy 6, akkor nem érdekes, hogy mikor lesz péntek, hiszen a kánaánt éljük meg.

17

Minden más esetben, amikor a fentiek nem szakították meg a return használatával a függvény futását hétköznap van és így ki is írjuk, hogy nincs péntek, továbbá azt, hogy mennyi nap van még hátra. Ezt ugyebár a legegyszerűbben úgy kapjuk meg, hogy kivonjuk az 5-ből az aktuális napot.

Az egész alkalmazást úgy tudjuk megnézni, hogy (tételezzük fel, hogy app.js-nek neveztük ez a fájlt) beírjuk konzolra (terminálra vagy ki hogy nevezi), hogy node app.js. Ez nem fog nekünk kiírni semmit (vagy hibaüzenetet ír ki, de azt nem szeretjük) viszont, ha megnyitjuk böngészőben, a http://localhost:3000/ oldalt, akkor megkapjuk az eredményt.

Express.js (kis “történelem”)

Kicsit hosszú lenne és bonyolult minden kisebb oldalt felépíteni (nagyobbakat méginkább) a http lib használatával. Pontosabban úgy, hogy csak azt használjuk. Most gyorsan megismerkedünk az Express.js-el, ami egy keretrendszer, a keretrendszeren, ami a keretrendszeren van. Nah jó ennyire nem gáz a helyzet, sőt…

Az egész onnan indul, hogy a Node.js úgy van felépítve, hogy maga egy keretrendszer tudjon lenni. Egyszer valaki megcsinálta hozzá ugyebár a már használt http libet, ami benne van a rendszerben.

A Sencha Labs úgy gontolta, hogy ez így macera lesz és megcsinálta a connect.js-t, ami a http-t használva ugyan úgy csinál nekünk egy webszervert, csak épp van benne Routing rendszer session kezelés és nagyon jól pluginelhető. Nagyon sok jó “gyári” middleware van hozzá, mint például a csrf (a neve jól mutatja mire való) vagy a compress, ami Gzip tömörítést teszi nekünk lehetővé, hogy minél kisebb legyen az adathalmaz, amit átküldünk a kliensnek. Persze ennél jóval több külső kiegészítő van hozzá, mint például a connect-auth, ami tulajdonképpen egy azonosítási rendszerrel egészíti ki a rendszert és nem is kicsit, hanem nagyon. A connect-auth segítségével HTTP Basic/Digest, Twitter, Facebook, Yahoo, Github, FourSquare, Janrain/RPX vagy bármilyen OAuth azonosítást tudunk pillanatok alatt bevarázsolni. (Persze említhetném itt a connect-jade middleware-t is, amit jómagam tákoltam össze, hogy a jade is támogatott legyen connect használata közben… Hopp meg is említettem [:)

No de, mi nem is ezt fogjuk használni, hanem TJ Holowaychuk munkáját, ami a connect.js-re épülő Express.js. Tulajdonképpen a lehető legjobb dolog volt az connect-re építkeznie, mert így a connect middleware-ek mind jók itt is 🙂 Ebben egy sokkal okosabb Routing rendszer van, sokkal durvább kiegészítők érhetőek el és nagyon kezes session kezelő jár hozzá.

Akkor jöjjön, amire vártunk

Ezen sok kitérő után jöhet a lényeg. Írjuk meg a hátterét az előző fejezetben elkezdett URL rövidítőnek. Legalábbis egy részét. Először is nézzük sorra. Az alkalmazásunk jóval összetettebb lesz, mint az előző.

Függőségek

A Node.js egy package.json konfigurációs állományon keresztül kezeli a függőségeket, így létre is hozzuk most ezt a fájlt.

18

A foly.am domainre már jóideje fáj a fogam, de nem olcsó így ezidáig nem sikerült beszereznem, de ennek a nevét fogom most felhasználni a példában, mint alkalmazásnév. (Ha valaki meg akar vele ajándékozni, akkor ne szerénykedjen nagyon fogok neki örülni)

Ez a fájl megmondja az npm-nek, hogy telepíteni kell az express, jade, stylus és mongoose csomagokat.

  • express: A keretrendszer, amit használni fogunk.
  • jade: Express-nek kell valami template motor, és a Jade az jó.
  • stylus: CSS helyett használatos. Én szeretem nagyon 🙂 Most ezt nem fogjuk használni.
  • mongoose: MongoDB lesz használva adatbázisnak és a mongoose nagy segítségünkre lesz ebben, de ez se lesz most használva, majd legközelebb.

Hogy később tudjon futni Heroku-n, csinálunk egy Procfile-t is, ami tartalmazza a processzeket (pl: web dyno).

19

A rendszer miután feltelepültek a függőségek létre fog hozni egy node_modules nevű könyvtárat, ami a külső libeket tartalmazza. Ezt teljes mértékben ki kell zárni a Git folyamatból, mert sok fájl van benne, nagy és bárhova viszed ott fel tudod (néha kell is) rakni a függőségeket egy parancssal, tehát ezt a könyvtárat minimum be kell rakni a .gitignore-ba.

20

Ha minden megvan, akkor egy npm install parancs kiadása után minden függőségünk fel van telepítve.

Az alkalmazás lelke

Most jön a programozás 🙂 Építsük fel az alkalmazás lelkét. Hozzuk létre az app.js-t. Természetesen ez lehet más is, de akkor a Procfile-ban és a package.json-ban is át kell írni a nevet.

21

A forrás mindenhol szépen kommentelve van, tehát ne ugord át 🙂 Ha megtetted, akkor görgess szépen vissza és nézd meg.

Routes vs Controllers

Még egy valami kell mindenképpen az alkalmazásunknak mégpedig a routes, amit betöltünk, de nem hoztuk létre. Hozzuk is gyorsan létre a routes nevű könyvtárat, amibe belepakolunk egy index.js-t. A require olyan érdekességgel rendelkezik, hogy elég a könyvtárat megadni neki, és ő betölti az index.js-t. Ez a kiváltság csak az index névre illik, minden mást nem tölt be így, hanem meg kell adni a fájl nevét is.

22

Adjuk hozzá a titkos A vegyszert

Van már cukor, só és minden mi jó a főzetben, de most adjuk hozzá az A vegyszert. Hozzuk létre a public könyvtárat, amit megadtunk, hogy ott lesznek a statikus tartalmak, azon belül pedig egy javascripts és egy stylesheets könyvtárat. Másoljuk át az előző leckéből a tartalmat ide és javítsuk ki apróbb hibáit a html-nek, ami ezután így fog kinézni:

23

Természetesen a többi fájlt is át kell másolni, mint main.css, angular.min.js és app.js. Még egy dolog hiányzik. Kelleni fog még egy views/error/404.jade. Ez fog betöltődni, ha olyan oldalt kérnek, ami nincs.

24

Vége?

Dehogy! Bár egyelőre igen. Ez a cikk elsősorban arra hivatott, hogy a hátteret megteremtsük a későbbi alkalmazásunknak. Így is elég hosszú cikk lett és nem akarok egyszerre több manát csepegtetni agyatokba, mert nem biztos, hogy elbírnátok 🙂 Nemsokára (most nem lesznek hosszú hetes szünetek) jön a következő fejezet, ahol összekötjük ténylegesen a két részt és el is mentjük az adatokat adatbázisba. Most tulajdonképpen szenvedtünk egy jó adagot, hogy elérjük ugyan azt, amit eddig is elértünk, viszont most már van mögötte egy Node.js szerver, amivel később tud beszélgetni a kliens oldali réteg. És persze egy csomó mindent tanultunk a Node.js-ről 🙂

Hja és persze a cica, róla egy szó sem esett. Múltkoriban csúnyán belémkötött pár ember, hogy milyen ellenséges vagyok a macskákkal. Nah ez a kép nekik került oda. Jól ábrázolja, hogy az aranyos kis munkánkat, amit eddig csináltunk, most jól beleraktuk egy burokba, házba vagy vázba. Tehát lássátok tudok én is macskát és kiscicát is kirakni, de nem osztok meg 40-et egy nap.

Kapcsolódó cikkek:

Google+ és Google API kapcsolat

Már egy ideje megjelent a Google Login mellett a Google+ Sign In is. Kicsit meg is lepődtem, mert bár minden cégnek van valami jó kis autentikációs rendszere, amit fel lehet használni azonosításra, de a legtöbb cég megmaradt, ahogy a Google is, az OpenID vagy az OAuth mellett. A Twitter OAuth rendszert használ, az Evernote szintén ezt az utat választotta, de még az Instagram is az OAuth mellett tette le a voksot. A Facebook mondjuk kilóg a sorból, hiszen ő a Graph API fejlesztésébe fogott annó és maradt is ezen a vonalon.

Persze most nem is ez a téma. A Google ahelyett, hogy szépen beillesztette volna a Google+ elérését a már meglévő azonosítási rendszerébe, úgy döntött, hogy csinál egy újat. Egészen idáig a Facebook rendszerét szidtam, de azt hiszem eljött a pillanat, hogy az új Google+ Sign In szidhatóbb. Lényegében egy webes alkalmazás számára teljesen értelmezhetetlen logikát követ. De először is nézzük meg, hogy eddig hogyan működött.

A jól megszokott régi idők

Eddig ugyebár, mint említettem OAuth v2.0-t használt a Google az azonosításra a külső fejlesztők számára biztosított API felületen. A legtöbb esetben ez úgy működött, hogy a webes alkalmazás (természetesen nem kívánom elemezni és bírálni az asztali réteget sem és a mobilos alkalmazások területén való működését sem) átirányította a kedves felhasználót a Google által biztosított jól megszokott bejelentkezési felületre, ahol engedélyt kért az alkalmazásunk az előre meghatározott adatok eléréséhez. A felhasználó miután elfogadta (mivel mást úgy sem igazán tehet, ha használni akarja a szolgáltatásunkat) átkerül egy olyan oldalra, amit szintén előre meghatároztunk, mint callback cím. Itt mi szépen lekezeltük az adatokat, majd átirányítottuk a felhasználót oda, ahova mi szerettük volna.

Mi a mostani logika?

Először is leszögezném, hogy szerény véleményem szerint a mobilpiacot kiszolgáló alkalmazások területén biztosan nagyon jó logika, de weben nem. Most kirakunk egy gombot. A gomb már önmagában indít egy validálási folyamatot, mivel amint lefut a hozzá kapcsolódó behívott JavaScript kódsor, már fel is szól az oldalunk a Google szervereire és ő meghívja nekünk a megadott callback függvényt.

Itt előre jelezném, hogy van benne egy pici hiba. Én előszeretettel “névterezem” a függvényeimet, így nem meglepő módon egy User.signInCallback nevű függvényt hoztam létre, ami történetesen nem jó, mert ha így adom meg akkor azt mondja, hogy nem található a függvény. Megoldásként meghagytam a szép kis objektumomat és csináltam egy var __signinCallback = User.signinCallback trükköt neki, amit már elfogadott. Nem kevés idő ment el, mire rájöttem, hogy miért nem találja a függvényt.

Tehát miután meghívja a mi callback függvényünket, mi szépen kapunk egy objektumot paraméterben, aminek van egy code és egy access_token kulcsa. Van még pár, de azokkal nem kell foglalkozni. Itt persze egyből jön a szépség, mert ha van code kulcsa a kapott objektumnak, akkor el kell rejteni a bejelentkező gombot. Ha jól megnézzük valamelyik irányba mindenképpen “villogni” fog a gomb azokon az oldalakon, ahol már megcsinálták az átállást. Vagy alapból el van rejtve és miután megkapjuk, hogy nincs engedélyünk megjelenítjük, vagy alapból megjelenítjük és amint megkapjuk, hogy van engedélyünk elrejtük. Tehát a callback valahogy így néz ki (nem cifráztam az biztos):

25

Meg is jegyezném gyorsan, hogy az egész oldal nem használja a jQuery remek függvénykészletét, csak és kizárólag ez miatt raktam be, mert miután már csak a függvény meghívásával elba jó sok idő elment, úgy döntöttem behívom, mert ki tudja mivel kerülök még szembe.

Ha nem futott le a kódunk első része, akkor biza még nincs jogunk. Itt kell a felhasználó, aki majd szépen megnyomja az el nem rejtett gombot. Miután megnyomta kap egy ablakot, ahol mindenféle jogok után érdeklődik a Google, hogy a kedves ügyfél azokat a részünkre bocsájtja-e. Természetesen igent mond, mert hát használni szeretné az oldalt. Ekkor ugyan ez a függvény hívódik meg, és most sikeresen lefut a kódunk első része, minek következtében elrejtődik a bejelentkezési gomb.

Hoppá! Itt jön a vicces rész. Az alkalmazásunk kliens oldalon már tudja, hogy be van jelentkezve a felhasználó, de legalábbis azt tudja, hogy van felhasználó. A szerver még nem tud semmit, de honnan is tudhatna. Most a szépen lekérdezett adatokat át kell juttatnunk a szerverre, de azzal se megyünk ám sokmindenre, mert emailcím, Google+ ID nem jön, ahhoz külön kérés kell. Tehát miután megkaptuk a jelet, hogy van jogunk, szépen lekérdezhetjük a felhasználó adatait, amikre amúgy vigyázni kell és a lehető legkevésbé utaztatni 40x oda vissza. Ha ez is megvan akkor ezt el kell küldeni a szerveren lévő háttérnek, hogy aztán ő is jól megkérdezze, hogy biztosan jók-e az adatok, mert a kliens azt küld amit akar ugyebár.

26

Ezek után mi akár el is menthetjük az aktuálisan átküldött Google+ ID-t, mint felhasználó, aki bejelentkezett, de ki garantálja, hogy azok valós adatok-e? Senki. Tehát most miután a szerver megkapta, amit akart… Végigmegyünk mégegyszer az egészen, ami annyit jelent, hogy akkor most szépen használjuk a régi OAuth2-es rendszert https://www.googleapis.com/auth/plus.login scope megadásával. Ha minden ok, akkor jelezhetünk vissza a kliensnek, hogy minden ok.

Miért kell ez a sok szívás és miért érdemes átállni mégis erre?

Két oka van. Az egyik vagányul néz ki, a másik pedig ütősen hangzik, de nem az. És persze ott a bűvös harmadik is: “Mert a főnök azt mondta.”

Ütősen hangzik, de nem az

Ha így azonosítasz, akkor csinálhatsz Moments bejegyzéseket, vagyis leegyszerűsítve már majdnem az, mint a Facebook. Csinálhatsz interaktív megosztást a felhasználó folyamjára. Viszont nem ez a leglényegesebb, hanem a következő pont.

Vagányul néz ki

Miután az alkalmazásod használja a Google+ Sign In rendszerét és össze is kötöd a Google+ Oldaladat az alkalmazással, a Google API Console felületén, megjelenik egy új menüpont a Google+ Oldalad adminisztrációs részén.

Connected Services

Mi van itt? Láthatod, hogy mennyien jelentkeztek be a rendszeredbe az alkalmazásodon keresztül és mennyi ebből az új.

Sign-In Activity

Továbbá az előbb említettem, hogy az interaktív posztoknak van azért előnye is. Itt láthatod, hogy mennyi interaktív megosztás született, mennyien látták azokat és abból mennyi átkattintás volt. No kérem ez viszont tényleg jól néz ki.

Interactive Posts

Mivel a képen létható oldalnál még nincs semmi, amit interaktívan meg lehetne osztani (sőt semmilyen interaktivitás nincs rajta… egyelőre) így minden érték nullán áll ezen a részen.

Végeredmény

Végigszívhatod az egész napodat, hogy a marketingesek kérésére látható legyen az új bejelentkezési lehetőség (nah jó azért Node.js-ben csináltam és ott se volt szörnyen hosszú, pedig oda nincs normálisan GoogleAPI lib). Ezen kívül pedig reménykedünk, hogy a későbbiekben bekerül valami értelmes elérés is, hogy több mindenre lehessen használni. És persze majdnem elfelejtettem még valamire felhívni a figyelmet. A dokumentáció (ahahahahha) melletti példa kódok nem egészen jók.

A PHP-s speciel átad 2 értéket a szervernek JavaScript-ből, de mást használ már a PHP kódban. Kicsit rosszul esett, hogy nem értem miért kellene működnie, majd még rosszabbul, amikor rájöttem, hogy ennek így 100%, hogy nem kellene, hogy működjön és valószínűleg copy-paste áldozata lett.

A Ruby-s verzióra vetettem a szememet, miután ezzel szembekerültem és ott sem igazán úgy van használva, ahogyan kellene. A “dokumentáció” elején levő gyönyörű, ám annál kevésbé olvasható, rajzocskáján pedig megint egy teljesen más logikát rajzol le.

Ezek úgy tűnik már azóta javítva lettek.

Sok sikert 🙂 Ha már szembe kerültél vele, akkor nyugodtan oszd meg velünk is a tapasztalataidat és esetlegesen további ajánlásokat, tippeket. Vagy csak szimplán szólj be, hogy hülyeséget írok.

Kapcsolódó cikkek:

Csapatmunka Github segítségével

Ez a cikk eredetileg +Sayanee Basu (Twitter: @sayanee_) munkája, amit a @nettuts oldalon publikált “Team Collaboration With Github” címen. Mivel úgy gondolom, hogy ez egy nagyon jól összeszedett cikk gyorsan engedélyt is kértem a fordításra Twitteren, melyre gyors válasz érkezett. Így aztán nekiláttam a fordításnak. Mivel a cikk sok olyan szót tartalmaz, amit nem lehet vagy legalábbis nincs értelme lefordítani, így ha valahol olyan hibát találsz, ami ebből fakad, akkor kérlek írd meg, hogy mi az, hol van és hogyan lenne jobb. (természetesen minden más hibára is örülök, ha írsz)

És itt kezdődik a cikk…

A Github lett manapság az Open Source közösségek, alkalmazások központja. A fejlesztők szeretik, itt dolgoznak együtt projektjeiken és jobbnál-jobb dolgokat készítenek közösen. Azon kívül, hogy a kódbázis tárolására ad lehetőséget, a Github az együttműködés terén kimagaslik bármilyen más hasonló szolgáltatás mellett. Ebben a leírásban felfedezzük, hogy miként is lehet csapatban dolgozni a Github-on, hogyan lehet hatékonyan és mindemellett fájdalommentesen használni és javunkra fordítani.

Bővebben

Kapcsolódó cikkek: