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.

0

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

1

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

2

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.

3

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.

4

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.

5

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.

6

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.

7

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).

8

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.

9

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.

10

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.

11

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:

12

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.

13

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):

14

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.

15

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.

(tovább…)

Kapcsolódó cikkek: