2014. január 31., péntek

Conky: Gmail szkript

Eljött az ideje, hogy lecseréljem az ősrégi Conky olvasatlan emailszám kijelző szkriptemet, mely egy nem teljesen erre a célra készített Perl szkript volt eddig. Megírtam tehát alig pár sorban Python3 segítségével az új verziót, mely körülbelül kétszer gyorsabb, mint az eredeti Perl szkript, valamint hálózati kapcsolat nélkül sem száll el.

Telepítéséhez szükség lesz a python-requests csomagra:

$ sudo apt-get install python-requests

Majd hozzunk létre egy fájlt, és illesszük be a szkriptet:

$ mkdir -p ~/.scripts
$ touch ~/.scripts/gmailToConky.py
$ chmod +x ~/.scripts/gmailToConky.py
$ gedit ~/.scripts/gmailToConky.py

Itt a szkript:

Így használhatjuk Conky-ban:

You have ${texeci 300 python ~/.scripts/gmailToConky.py} new gmail(s).

Megjegyzés: a korábbi Conky-hoz való szkriptjeim is frissültek (The Old Reader szkript, Google Calendar szkript), használatuk kis mértékben változott a Python3-ra való áttérés miatt.

2014. január 28., kedd

Hypermedia API

A mostani cikk kevésbé kapcsolódik a Linux-hoz, viszont egyfajta tutorialként felfogható és mint egy általános paradigma platformfüggetlenül felhasználható, így itt is megjelenhet a blogon. :)

Eredetileg megjelent a Kir-Dev oldalán

Bevezetés

Az informatikai rendszerek architektúrájában egy evolúciós lépés a szolgáltatás-orientált programozás (SOA), melyet gyakran webszolgáltatások formájában implementálnak. A SOA architektúra azonban önmagában nem a webre született, így kialakult az erőforrás-orientált architektúra (ROA), mely inkább programozási paradigmának, vagy megvalósítási stílusnak nevezhető. A ROA lényege, hogy a szoftvert erőforrások formájában tervezzük meg és az alkalmazást alkotó szolgáltatások REST interfészen keresztül kommunikálnak.

Két gép kommunikációjához valamilyen protokollra és adatformátumra van szükség. Az erőforrás-orientált programozás során használt REST a HTTP protokoll webes szemantikáját terjeszti ki azzal, hogy az alkalmazás állapotát HTTP kérésekkel lehet lekérdezni, illetve módosítani. Ez webszolgáltatások esetén sokkal könnyebben használható, mint a SOA, ami sokáig egyet jelentett a SOAP-pal. A REST-ben megfogalmazott vezérelvek nem határoznak meg konkrét adatátviteli formátumokat, így webszolgáltatások esetén felhasználástól függően különböző formátumokat használnak, mint például XML vagy JSON.

Hagyományos SOA rendszereknél egy távoli lekérdezés adatokkal tér vissza, ROA esetén viszont az alkalmazás további állapotaiba vezető átmenetek is a visszatérési érték részét képezik. Az alkalmazás állapota részletesen leírható a hypermedia formátumok metaadat leíró képességével, az állapotátmenetek pedig könnyen reprezentálhatóak a hypermedia adatformátumokban meglévő linkekkel: innen ered a technológia elnevezése a Hypermedia API. Használatával a klienseknek csak linkeken keresztül kell kommunikálnia a backend szolgáltatással, így weben rendkívül jól használható. Segítségével valóban vékony kliensek hozhatók létre, amik nagyon keveset tudnak a háttérben dolgozó szolgáltatásról. A szolgáltatás részleteinek változásakor nem kell változtatni a kliensen, ezért a Hypermedia API könnyebben használható programok számára és azokat így könnyebb is karbantartani.

Adatformátumok

Lényegében bármilyen adatátviteli formátumot használhatunk, de a legelterjedtebbek, melyeket HTTP protokoll felett használnak a HTML, XML és a JSON. Más lehetséges formátumok például a CSV, YAML, Markdown, ATOM, de ezek kevésbé elterjedtek ilyen célból. Koncentráljunk a három legelterjedtebbre, és lássuk melyiknek milyen előnyei vannak.

XML

  • (+) Rendkívül kiforrott formátum és nagyon sokféle támogató technológia érhető el hozzá. Például transzformáció (XSLT), lekérdezés (XPath, XQuery), validáció (XSD, DTD).
  • (+) Szabványos és minden programozási nyelvből elérhető.
  • (-) Kliens oldalon nehezebb használni.
  • (-) Nehézsúlyú: kommunikációs overhead.
  • (-) Nincs natív állapotátmenet reprezentáció kiterjesztés nélkül.

JSON

  • (+) Kliens oldalon könnyű használni.
  • (+) Könnyűsúlyú.
  • (-) Nincs szabványos lekérdezés, validálás.
  • (-) Nincs natív állapotátmenet reprezentáció kiterjesztés nélkül.

HTML

  • (+) Kiforrott formátum, sok támogató technológia.
  • (+) Kliens oldalon használata triviális.
  • (+) Javascript segítségével módosítható.
  • (+) Natív állapotátmenet reprezentáció.
  • (+) Jól jön, ha olvashatónak kell lennie az API-nak.
  • (-) Nem mindig készíthető egyszerűen el az alkalmazás állapotának reprezentációja.

Néhány példa

Labirintus

Labirintus játék API XML felhasználásával:

  • Különféle labirintusok közül választhatunk a collection listából.
<maze>
    <collection href="...">
        <link href="..." rel="maze" />
        <link href="..." rel="maze" />
    </collection>
</maze>
  • A kiválasztott labirintusba beléphetünk, vagy visszaléphetünk a labirintus-listához.
<maze>
    <item href="...">
        <link href="..." rel="collection" />
        <link href="..." rel="start" />
    </item>
</maze>
  • Járkálhatunk a különböző cellákon (cell), újrakezdhetjük a labirintust, vagy választhatunk másik labirintust. Megjegyzés: természetesen nem mindig lehet minden irányban lépkedni, itt az összes lehetőséget felsoroltam.
<maze>
    <cell href="...">
        <link href="..." rel="north" />
        <link href="..." rel="south" />
        <link href="..." rel="east" />
        <link href="..." rel="west" />
        <link href="..." rel="exit" />
        <link href="..." rel="maze" />
        <link href="..." rel="collection" />
    </cell>
</maze>

Todo app

Todo alkalmazás API-ja JSON+Collection adatformátumot használva (itt az items tömbben vannak az adatok eltárolva és queries-ben a lehetséges műveletek):

{
  "list" : {
    "link" : {
      "href": "{collection-uri}",
      "rel": "list" 
    },
    "items" : [
      {
        "link" : {
          "href": "{item-uri}",
          "rel": "item" 
        },
        "title" : "First task",
        "description" : "start JSON implementation of the list",
        "date-due" : "2010-05-01",
        "completed" : false 
      },
        ...
    ],
    "queries" : [
      {
        "link" : {
          "href": "{query-link}",
          "rel": "today" 
        } 
      },
      {
        "link" : {
          "href": "{query-link}",
          "rel": "open" 
        } 
      },
      ...
    ]
  }
}  

Tervezés

A Hypermedia API-k tervezésének lépései:

  1. Üzleti logika vizsgálata
  2. Állapotgép készítése
  3. Adatreprezentáció készítése

Az ábrázolás részletei a választott adatformátumtól függnek, de sok közös vonás van, amik megegyeznek az egyes formátumok között, közös elnevezésük angolul H-Factors. Ezek a tényezők alapvetően két részre bonthatók: vannak a link factor-ok, melyek a kliens-szerver kommunikáció létrehozásáért felelősek; és vannak a control factor-ok, melyek a metaadatok részleteit módosítják. Lássuk hogyan épül fel belőlük egy API, mely HTML-t használ adatformátumként:

Egy adott URL-en lévő tartalmat be kell olvasni és az adott helyen megjeleníteni, más néven beillesztés.

<img alt="..." src="..." />

Egy adott URL-en lévő tartalmat ki kell olvasni és egy új nézetben megjeleníteni, más néven navigáció.

<a href="...">...</a>

Egy adott URL-en lévő tartalmat valamilyen klienstől származó információkkal paraméterezve kell kiolvasni.

<form method="get" action="http://www.example.org/">
    <input type="text" name="search">
    <input type="submit" />
</form>

vagy

<a href="http://www.example.org/?search={searchParam}"></a>

Idempotens metódusok, melyek többszöri végrehajtása ugyanazt az eredményt adja, mint az egyszeri végrehajtás. HTTP protokoll esetén ezek a PUT és DELETE verb-ekkel végrehajtott kérések. HTML-ben csak Javascript segítségével megvalósítható.

Nem idempotens metódusok, ilyenek a HTTP protokoll esetén a POST verb-ekkel végrehajtott kérések.

<form method="post" action="http://example.org/comments/">
    <textarea name="comment"></textarea>
    <input type="submit" />
</form>

Control factors

CR (Read controls)

Az adatok olvasását befolyásoló tényezők. Ilyenek HTTP protokoll esetén a fejléc (header) változók, mint például a Content-Type.

CU (Update controls)

Az adatok olvasásának befolyásolását segíti ez a tényező. Ilyen HTML esetén a formokban található enctype attribútum, mely a kéréshez tartozó Content-Type fejlécet tudja módosítani.

<form method="post" action="http://example.org/comments/" enctype="text/plain">
    <textarea name="comment"></textarea>
    <input type="submit" />
</form>

CM (Method controls)

Az adatkezelés módjának megváltoztatását segíti ez a tényező. HTML esetén a method attribútum erre szolgál.

<!-- frissítés -->
<form method="post" action="..." />
...
</form>

<!-- olvasás -->
<form method="get" action="..." />
...
</form>

Egy node annotációjával is módosíthatjuk egy URL-en található tartalom értelmezését. Ilyen HTML esetén a link tag rel attribútuma.

<link rel="stylesheet" href="..." />

Konklúzió

Egy rövid bevezető után láthattuk hogyan épül fel a Hypermedia API, megismertük a főbb jellemzőket. Láthattuk hogy:

  • hogyan csökkenti a csatolást a kliens és a szerver oldali kód között a paradigma a belső megvalósítás függetlensége miatt (nincs konkrét url-től, paraméterektől való függőség)
  • hogyan lesz könnyebben használható kliensek számára
  • hogyan lesz olvashatóbb felhasználók számára

Egy szóval linkek használata az API-ban egy jó dolog, próbáljátok ki a GitHub API-ját! Akit továbbiakban is érdekel a téma itt találhat 3 teljes implementációt XML, JSON és HTML nyelven, valamint teszt klienseket is hozzájuk.