Monthly Archives: október 2008

Aktuális: OpenID, oAuth

Az authentikáció kérdése elég érdekes manapság, mivel már nem csak a “bekérem a felhasználónevet, jelszót” változatot kell jellemzően megvalósítani, mikor hitelesíteni akarjuk a felhasználó személyét. Az OpenID és oAuth protokollok úgy biztosítanak hitelesítést, hogy az oldal nem tudja meg a felhasználó jelszavát, az egy harmadik félnél van. A dolog nálam egyéb okokból is aktuális, de az OpenID azért is jöhet a képbe, mert most már mind a három nagy támogatja: a Yahoo!, a Microsoft és a Google is.

Kimazsolázni a különbséget a két megoldás között nem feltétlenül könnyű, én is csak most ismerkedem ezekkel a protokollokkal (ha van tipp, jöhet!), de a lényeg, hogy az OpenID segítségével alapvetően annyit lehet kiszedni a szerverből, hogy sikeres volt-e az authentikáció, vagy nem, míg az oAuth további adatok biztonságos forgalmazását is lehetővé teszi (gondoljunk itt egy API-ra). Mind a két megoldás alapja egy authentikációs szerver, ahol nyilván van tartva a felhasználói azonosítónk és jelszavunk (vagy más formában kínál azonosítási lehetőséget), s ezt a szervert használva léphetünk be különböző oldalakon úgy, hogy közben a céloldal nem fogja megtudni sem az azonosítónkat, sem a jelszavunkat. Hozzáteszem, az OpenID-nak van egy kiegészítése, mely segítségével lehetőség van személyes információkhoz (pl. az azonosító) történő hozzáférésre (akár azok megváltoztatására is), az oAuth keretében pedig magának a protokoll használatának keretében dönthet úgy a szolgáltató, hogy biztosít olyan interfészt, ahogyan ez megtehető. Nyílt protokollokról van szó: ingyenesen használhatóak, és nyílt szabványokra, algoritmusokra épülnek.

Egyik protokollra sem mondanám, hogy egyszerű, mindkettő ide-oda üzengetést tartalmaz, jellemzően a biztonságot szem előtt tartva aláírva valamilyen algoritmussal az üzeneteket. Az OpenID authentikáció kiegészítője az OpenID tulajdonságcsere, ezekkel a doksikkal érdemes kezdeni egy átfogó kép kialakításához, majd mondjuk megnézni egy gyakorlati dokumentációt. Kész kódok is rendelkezésre állnak különböző nyelvekhez, de ehhez már jellemzően érteni kell magát a protokollt, vagy legalábbis a főbb elemeit. Az oAuth-tal történő ismerkedést is az oAuth specifikáció segítségével lehet érdemes kezdeni. Ezután szintén egy gyakorlatibb útmutatót, majd kész kódok nézegetségét tudom ajánlani.

Amit eddig még nem mondtam el, hogy miért is jó nekünk, ha ezekkel megismerkedünk (persze mindenki döntse el maga). Az OpenID kapcsán ha lehetővé tesszük annak használatát oldalunkon, akkor megkönnyíthetjük a felhasználók regisztrációs folyamatát mind fizikailag (pár kattintással túl tudnak lenni rajta – nincsen emailes megerősítés), mind lelkileg (nincs jelszó megadás, és gyors a folyamat). Ez sokat jelenthet, hiszen a felhasználónak megspórolhatunk pár percet – ami nagyon sok, ha azt nézzük, hogy 5 másodpercet sem szoktunk kivárni egy oldal letöltésekor.

Az oAuth akkor jó, hogy olyan webszolgáltatást írunk, mely együtt szeretne működni más szolgáltatásokkal a neten. A régimódi megoldás erre hogy bekérjük a másik szolgáltatás felhasználónevét, jelszavát ha szeretnénk a felhasználó más szolgáltatásnál tárolt adataihoz hozzáférni, ez azonban nem igazán bizalomgerjesztő, hiszen azt le kell tárolnunk: ha hozzánk betörnek, a másik szolgáltatáshoz is nyitott az út, illetve az sem nyugtatja meg a felhasználót, hogy látjuk ezeket az adatait.

Jó irányba megy a WebKit

A WebKit böngészőmotor (aki nem ismeri a történetét, a Wikipédián elolvashatja), mely többek között a Safari és a Chrome megjelenítőmotorját biztosítja elég jó ütemben, és jó irányba fejlődik. És ami a webfejlesztők számára kiemelten érdekes lehet, a Web Inspectort erőteljesen feltupírozták, s így egy elég jól használható hibakereső eszközt hoztak ki belőle, mely részben meghaladja a Firebug képességeit is (részben viszont hiányolok párat).

A WebKit blogjában el lehet olvasni a hogy mi változott: Web Inspector Redesign, én pedig inkább arról írok hogy mi tetszik, és hogy mi az, ami még hiányzik. A WebKit legfrissebb napi buildjei a tapasztalataim szerint stabilak, jól használhatóak (legalábbis Mac-en), érdemes kipróbálni hogy mit tud a böngésző (nagyon gyors is). A Safari és a Chrome következő változatával pedig hivatalos kiadásban is kipróbálhatjuk azokat, amikről most írni fogok.

A Web Inspector segítségével a Firebug-tól megszokott szolgáltatásokat kapjuk: van az adott weblap HTML-jének böngészését lehetővé tevő Elements fül, egy a letöltött oldalelemeket felsoroló, azok letöltési idejét, méretét jól áttekinthetően megmutató Resources fül, JavaScript debuggolást lehetővé tevő Scripts fül, egy teljesítménymérést (melyik függvény hányszor lett hívva, mennyi ideig tartott a ftása, stb.) nyújtó Profiles fül, továbbá egy az adott oldal helyi (lásd HTML újdonságok) adatbázisait elérhetővé tevő Databases fül. És az egészet kiegészíti egy konzol, ahol JS parancsokat adhatunk ki, hasonlóan a Firebug “parancssorához”.

A fejlesztések (amikről azt kell tudni, hogy nagy részük önkéntes munkából, különböző fejlesztők felől érkezett) igen sokat javítottak az Web Inspector használhatóságán, gyakorlatilag egyetlen egy gondom van: az összetett objektumok konzolban történő megjelenítése. A Firebuggal szemben ugyanis nem kapok betekintést az adott objektum tulajdonságaiba sem DOM objektumnál, sem pedig egy általános objektumnál. DOM objektumnál a helyzet ennél egy kicsit jobb, mert ha a kurzorral a konzolban felé megyek, akkor az Elements fül segítségével összeszedhetem azokat a tulajdonságokat, amiket keresek.

Jó dolgok viszont vannak dögivel (ezek egy része persze a Firebugban is megvan, de nem feltétlenül így), az eszköz kialakítása ami az interfészét illeti szerintem nagyon jól sikerült, lehet az adott oldalba “dokkolva” és külön ablakban is használni. A konzolban működik egy egész jónak tűnő kódkiegészítés, az oldal HTML-je élőben szerkeszthető, az idő/méret szerinti nézet a Resources fülön üt. A helyi adatbázis elérése is egy nagyon fontos lépés, előbb-utóbb a fejlesztők elkezdik használni ezt a lehetőséget, így egy nagyon hasznos eszköz lehet majd.

A WebKit letöltését és kipróbálását már ajánlottam a múltkor is, és most is csak ajánlani tudom.

Külföldre dolgozni

A NowPublicról szóló bejegyzésem kapcsán vetette fel PP, hogy jó lenne ha írnék röviden arról, hogy hogyan is lehet külföldre dolgozni, már ami a technikai részleteket illeti. Íme pár gondolat. Ha valaki jobban tudja, ne fogja vissza magát, nagyon szeretném ha kijavítana! :)

Csak cégként

A hazai és/vagy nemzetközi jogszabályok tudtommal nem teszik lehetővé, hogy alkalmazotti vagy ahhoz hasonló viszonyban dolgozzon valaki külföldre. A pontos okokat nem tudom, de azt hiszem, hogy a kritérium amin megbukik az ügy, az a helyben történő munkavégzés. A lényeg, hogy mindenképpen kell lennie egy cégednek, ha külföld felé szeretnél munkát végezni Magyarországról, akár esetileg, akár hosszútávon.

Számlázás az EU felé

Az EU-s szabályok alapján ahhoz, hogy európai úniós külföldi cég felé számlázhass, rendelkezned kell egy EU-s adószámmal. Ezt az APEH-től lehet kérni, és azt hiszem hogy nem kerül semmibe, csak 30 napba. Erre tehát érdemes előre felkészülni ha számlázni szeretne az ember. Szintén EU-s szabály, hogy nem csak a saját adószámot, hanem a számlát befogadó fél adószámát is fel kell tünteni valahogy a számlán.

Az EU-s adószám valójában semmi extra, egy HU előtag, plusz a magyar adószám első kötőjelig tartó részlete, de ennek tudatában sem szabad számlát kiállítani anélkül, hogy az APEH ezt megadta volna nekünk.

Számlázás angolul

Külföldi partnerek szeretik érteni a számla tartalmát. A magyar számla pedig magyarul van. Ezt az ellentmondást egy mini szótár mellékelt elküldésével, vagy a számla kézzel történő feliratozásával, esetlegesen egy kétnyelvű számla kiállításával (ha tud ilyet a számlázószoftver) lehet feloldani. Hozzáteszem, ezzel nem csak a külföldiek vannak így, magyar könyvelőm is feliratozta az APEH-nek a külföldről érkezett számláimat.

ÁFA nélkül

Külföldre történő számlázáskor ha a két ország között van ilyen megállapodás (jellemzően van), akkor 0%-os ÁFA érvényes, attól függetlenül, hogy az adott terméknek, szolgáltatásnak milyen adó vonzata van. EU-s ország, USA és Kanada felé ez biztosan így van. Ez elég szívás EVA esetén, aholis a bruttó összeg alapján történik a számolgatás, de hát ez van.

Bankszámlaszám

Jellemzően partnerünk távmunka esetén nem készpénzben szeretne fizetni, hanem az utalást fogja választani. Nemzetközi utaláshoz kelleni fog neki pár adat a bankszámlánkat, illetve a bankunkat illetően. Ez az úgynevezett IBAN és a bank SWIFT kódja.

Az IBAN az International Bank Account Number rövidítése, a bankszámlaszámunk nemzetközi megfelelőjét jelöli. HU-val kezdődik, aztán egy két számjegyből álló ellenőrzőösszeg, és végül a 24 jegyű bankszámlaszámunk következik. Néhány banknál ezt meg lehet tudni online, mert van IBAN kalkulátor, a többieknél nem tudom hogy zajlik ennek a számnak a megtudása (netbankból lehet hogy ki lehet nyerni?). További információkért kérjük keresse fel kezelőorvosát, bankárját.

A SWIFT kód, mely BIC kódként is ismeretes, a Bank Identifier Code, vagyis a bankunkat azonosítja be. Banktól függően ez is megtudható a weblapról, vagy ugyanonnan, ahonnan az IBAN kódunkat beszereztük.

Euro/USD számla

A kiállítandó számlán, és a szerződésben is jellemzően euroban, vagy dollárban szerepelnek az összegek (legalábbis nagyrészt nem forintban…). Ez ugye szívás mikor brutál erős a forint, és jól jöhet, ha nagyon gyenge – nagyobb összegeknél bizony ez több tízezer forintot is jelenthet. Ezen nem szabad sokat búsúlni, inkább el kell fogadni hogy így van.

A bankunknál nem kell valuta alapú számlával rendelkeznünk, de ha játszani szeretnénk az árfolyamokkal: tudjuk, hogy most az éppen nagyon erős forint nem hat ki jól a zsebünkben landoló összegekre, akkor nyithatunk valutaszámlát is. Ha forint alapú a számlánk, akkor a pénz beérkeztekor aktuális középárfolyamon átválta jelenik meg az összeg a számlánkon.

Szerződéskötés

A szerződéskötés jellemzően távolról zajlik le külföldi partnerek esetén. Úgy tudom, hogy a magyar törvények szerint pár éve már a faxon történő szerződéskötés is elfogadott, de postán is megoldható a dolog. Egyszeri együttműködésnél nyilván a faxot, vagy a beszkennelt és emailben elküldött szerződéskötés tűnik a célszerűnek.

Az eddig kötött szerződéseim jellemzően nem voltak se szigorúbbak, se bonyolultabbak mint a magyar partnerekkel kötöttek, és angolul születtek a franciák és a németek felé is.

Szabadságok, ünnepek

A szerződéses viszony jellemzően azt jelenti, hogy nincsen sem szabadságunk, amivel gazdálkodni tudunk, hanem havi fix munkanapnyi munkára szerződünk. Ekkor egy 1-2 hetes szabadság meglehetősen drága mulatság lehet, de ez is egy olyan dolog, amit gondolkodás nélkül célszerű elfogadni. Hozzáteszem hogy az adott céggel szóban meg lehet egyezni másképp is, de a szerződésbe szabadság valószínűleg nem fog belekerülni, hiszen nem alkalmazotti, hanem szerződéses jogviszonyról beszélünk.

Az ünepek kérdése is érdekes, a magyar és az adott ország ünnepei jellemzően még véletlenül sem fedik egymást, a néhány olyan kivételtől eltekintve, mint az újév és a karácsony. A keresztény ünnepek, mint a húsvét is országonként változó, hogy szabadnapot jelentenek-e, a magyar jellegű ünnepeket (pl. augusztus 20.) a külföldiek nem fogják ünnepelni, mi meg nem ünnepeljük a második világháború megnyerését, vagy a függetlenség napját. Hogy a munkavégzés hogyan zajlik, az szintén megállapodás kérdése lehet. A végeredmény függhet a cég piacától, és attól is, hogy mennyire nélkülözhetetlen a munkánk a másik fél munkanapjain. A Wikipédiában kellemesen össze vannak gyűjtve az állami ünnepek országonként. A franciáknál egyébként van valami olyan szabály is az alkalmazottak felé, hogy a nyugdíjasokkal történő szolidaritás miatt (nem, ezt én sem értem) egy állami munkaszüneti napon kötelező dolgozni, és még fizetés se jár. Ez logikusan a szerződéses munkavállalót nem érinti.

Hello NowPublic!

Kicsit sokáig tartott, de beígértem: leírom hogy hogyan jutottam el a NowPublichoz, hátha másnak is hasznos lesz. Persze hatalmas újdonságokkal nem szolgálhatok, főként hogy egy részét már leírtam a múltkori, erről szóló bejegyzésemben.

Ahogy írtam is a múltkor, jópár irányban elindultam, s végül kaptam jobbnál jobb ajánlatokat is. Végül úgy döntöttem, hogy a részleteket ezzel kapcsolatosan nem írom le (melyik cég, milyen pozíció), de ha valaki hasonló profilban keres állást mint én, szívesen megadom neki, hátha még egy-kettő aktuális.

Az álláskeresés legelején felkerestem egyik volt főnökömet a Netvibesnál (aki felvett), de végüls abból az irányból nem lett semmi, mert főként megbízásos melókat tudott volna, én pedig jelen helyzetben nem szerettem volna abba az irányba elmenni.

Ezután két állásajánlatot kaptam, mindkét cégnél alapvetően vezető JavaScript fejlesztő lettem volna, de más feladatok is párosultak volna a dologhoz, az egyiknél például általában a cég irányvonalában is segédkezni, a másiknál pedig a már meglevő csapatot összefogni. Mindkét esetben budapesti irodában kellett volna dolgozni, és a fizetési ajánlatok is átlag felettiek voltak.

Közben beérkezett még egy ajánlat egy nagyobb magyar cégtől, ott a JavaScript + sitebuild vonal mellett meg kellett volna a Ruby-val is ismerkedni, és ebbe az irányba azt hiszem én se akartam elmenni, másrészt pedig ők sem tudták erre a pozícióra azt a fizetést megadni, amit kértem volna. Később viszont ugyaninnen beérkezett egy nagyon érdekes ajánlat, mely keretében egy izgalmas funkció bevezetésében segédkezhetnék a cég által fejlesztett egyik ismert oldalon, ebben viszont döntés nem tudott a részükről születni még.

A két vezető JavaScript fejlesztő pozíciót végül nem fogadtam el, bár igen nehéz volt a döntés, mert mindegyik izgalmas feladatokat jelenthetett volna. Az ok végülis az volt, hogy az izgalmas feladatok mellett 200%-os teljesítményt (ha nem is feltétlenül munkaidőben, de agyban) is megkövetelt volna, amibe most nem akartam belemenni.

Jött még kettő másik ajánlat, az egyik egy magyar, de külföldre dolgozó cégtől (a pozícióban egy olyan ügyfelükkel dolgoztam volna együtt, akiknek már fejlesztettem a Netvibes-nál widgetet – érdekes lett volna) JavaScript + sitebuild jellegű pozícióra, a másik pedig a NowPublic-tól, JavaScript, sitebuild és részben Drupal fejlesztést illetően. A NowPublic-kal való gyors ismerkedést az is segítette, hogy a DrupalCon idén Szegeden volt, így a csapat nagy részével tudtam találkozni (és bulizni egy nagyot) személyesen is (a csapat egy része magyar). Ezek szintén jó fizetési ajánlatok voltak, az eddigi legjobbak, végül azért döntöttem a NowPublic mellett, mert gyakorlatilag hasonló megoldásban tudok náluk tovább dolgozni, mint a Netvibes-nál: nincs reggeli és esti utazás.

A NowPublic egy Drupal alapú közösségi híroldal, ahol az oldal felhasználói saját híreket tudnak beküldeni. A cégnek Vancouverben van a legtöbb alkalmazottja, de amúgy amerikai tulajdonú. Van pár érdekes funkció az oldalon (pl. a scan – itt éppen Drupal témában), és várhatóan egyes Miner.hu-n szerzett tapasztalatot, és a Netvibes-nál összeszedett UWA tudást is hasznosítom a cégnél. A Drupal tudásomat sem árt majd felfrissíteni, emiatt is egy érdekes kihívás a cég. Hello NowPublic!

Exkluzív: a magyar blogbiznisz

Amikor az exkluzivitásról írt _original a blogján, kicsit elgondolkodtam azon, hogy mi lenne az a tartalom melyről úgy tudnék írni, hogy még sehol máshol sem jelent meg. A Miner.hu-val a lehetőség adott: vizsgáljuk meg hogy hogyan alakult a magyar blogbiznisz az utóbbi két évben. Látogatottsági statisztikákat lehet nézegetni a Webauditon, a friss bejegyzés számokat pedig közzétesszük a Miner.hu statisztika oldalán, de van még mit kigyűjteni, mutatni.

Első körben kigyűjtöttem, hogy a négy nagyobb blogszolgáltató bejegyzései összesítve hogyan alakultak a Miner szerint. Az adatokról annyit kell tudni, hogy csak a freeblog.hu, blog.hu, blogol.hu és a blogter.hu bejegyzésekről szól, sem az egyéb szolgáltatók, sem pedig a független bloggerek bejegyzéseit nem foglalja magában. Ez utóbbit azért nem, mert a Minerbe folyamatosan kerülnek be a független blogok, így ezek a számok igencsak torzak lennének ha a hazai blogbejegyzések számának alakulását szeretnénk vizsgálni.

A számokról nem gondolom, hogy pontosak lennének, a cél sokkal inkább az, hogy a trendeket láthassuk. Az egyes napi tüskék a legtöbb esetben valószínűleg mutatnak valamit, de sok esetben előfordulhat az is, hogy csak zajként foghatóak fel. A freeblog.hu, blog.hu, blogol.hu számai a három blogszolgáltató visszajelzése, illetve a velük történő együttműködés kapcsán nagyságrendileg pontosnak mondható, a blogter.hu számai szerintünk pontosak, a szolgáltató szerint pedig nem. Mindesetre bontás egyelőre nincsen, csak összesített adatok.

A képre kattintva az egyes számokat is meg lehet tekinteni, de mégegyszer hangsúlyozni szeretném: inkább csak a trend lehet a lényeg.

Ha a bejegyzés tetszést fog aratni, további infókat is ki tudunk nyerni az adatbázisból — hogy mit próbáljunk meg lekérdezni, azt illetően szívesen veszünk tanácsokat.

Az igen randa, de hasznos Online Helyesírási Szótárnak köszönöm hogy megnézhettem az exkluzív szó helyesírását. Tibornak köszönöm az ötletet. Nektek pedig hogy blogokat írtok, olvastok.