Reading time: < 1 minute He montat un generador de codis QR al servidor de casa i que és usable des d'internet. Si a algú li fa falta és tan senzill d'usar com:
per exemple:
sortida:
Reading time: 4 – 6 minutes
Abans de parlar de CouchDB, si no heu sentit a parlar mai de les bases de dades NoSQL, és important que sapigueu que no són bases de dades ralacionals, ni orientades a objectes. Sinó que es basen en un paradigme diferet, són orientades a documents.
Doncs bé, CouchDB és un projecte de la fundació Apache i és OpenSource, és clar. Algunes de les seves característiques són:
Actualment estic estudiant si usar aquest producte en un dels projectes que estic treballant. De fet, encara no tinc clar si aplica al 100% a les necessitats que tinc en el projecte però a priori s’ajusta prou bé. Perquè no penseu que això és una raresa que no coneix ningú informar-vos que Ubuntu One usa couchDB com a backend, pels que no conegueu el servei jo el vaig descobrir gràcies a l’article d’Ars Technica: Code tutorial: make your application sync with Ubuntu One.
Inicialment volia fer un manual de les funcions bàsiques de CouchDB però degut al munt de documentació que he trobat he pensat que era una tonteria re-inventar la roda, així doncs a continuació faré una ressenya de les fonts d’informació que he usat per coneixer aquesta base de dades:
CouchDB is a “document-oriented” database where document is a JSON string (with an optional binary attachment). The underlying structure is composed of a “storage” as well as multiple “view indexes”. The “storage” is used to store the documents and the “view indexes” is used for query processing.
Enllaços orientats a les consultes:
Abans d’acabar comentar que personalmentel que més m’ha costat d’entendre de tot plegat és el tema map/reduce especialment la part de reduce, ja que no acabava de veure al 100% com funcionava i quina finalitat tenia. Potser l’error més gran que he comès és intentar buscar un paral·lelísme directe entre SQL i NoSQL. Sota el meu punt de vista no són tecnologies substitutories, més aviat complementaries ja que cada una s’ajusta a un tipus de solucions diferents. Per tant, abans que res recomano que confronteu la vostre problemàtica amb cada un dels paradigmes: orientat a objectes, bbdd relacionals i orientat a documents.
A vegades quan estem fent un programa ens interessa que el nostre codi pugui ser extés sense haver de tocar la seva estructra, fins hi tot el que ens pot interessar és que aquest codi sigui extés en algunes ocasions i en d’altres no. Un altre requeriment que podem tenir també seria que qui l’extengui no siguem nosaltres. Sovint tot això i molt més s’acostuma a fer amb el que anomenem Plug-ins, per cert, sempre m’ha fet molta gràcia la traducció al català de la paraula: ‘afegitons’.
Doncs bé, com que jo de programació no hi entenc gaire li vaig demanar al Pau que m’ajudés a entendre els models de plug-ins que implementaven alguns programes fets amb Python, ja que m’ineressava integrar aquesta funcionalitat en una serie de codis que estic desenvolupament. En aquest post intentaré explicar com funciona el paradigma dels plug-ins que usa Trac.
Primer de tot cal tenir en compte que Trac usa un patró de desplegament d’objectes anomenat Singleton, o sigui que totes les instàncies d’un objecte es refereixes a la mateixa instància. De fet, no sé dir fins a quin punt és necessari que el codi segueixi aquest patró per usar el sistema de plug-ins; tot i que jo diria que almenys les parts del codi que vulguin ser exteses pel model de plug-ins de Trac l’han de seguir.
Els plug-ins de Trac tenen les següents característiques:
Per tal d’incorporar la filosofia que té Trac per suportar Plug-ins al nostre codi cal importar el component ‘trac.core’, d’aquest component usarem el següent:
Abans de seguir explicaré que s’enten per contracte. Un contracte és en escència una classe de tipus interficie (python no té aquest model com a tal) que defineix quins mètodes (o altres classes) poden ser extesos dins el component original. O sigui, que cal no només definir quin és el contracte que s’ofereix sinó també documentar-lo el millor possible, explicant quines són les entrades i sortides que s’esperen de cada un dels mètodes/classes.
Perquè tot plegat s’entengui millor el Pau em va posar el següent exemple:
Imaginem que tenim una classe del tipus DNI que implementa una base de dades de DNIs, on té un metode que ens permet entrar DNIs a la base de dades:
class DNI(trac.core.Component):
dni_checks = trac.core.ExtensionPoint(IDNIInput)
def __init__(self):
self._dnis = []
def add(self, dni):
assert not dni in self._dnis, "DNI ja existeix"for dni_check in self.dni_checks:
if dni_check.check(dni) is False:
print "El dni %s sembla no ser correcte" % ( dni )
return
self._dnis.append(dni)
def llista(self):
print self._dnisCal fixar-se que la línia:
dni_checks = trac.core.ExtensionPoint(IDNIInput)el que fa és carregar els plug-ins que extenen la funcionalitat del codi original. A més cal que ens fixem que el paràmetre que usa la funció és la classe que defineix el contracte sobre el que es fan els plug-ins:
class IDNIInput(trac.core.Interface):
def check(dni):
""" Es cridada cada cop que s'entra un nou dni, espera que es retorni un valor boleà"""Com es pot veure el contracte només defineix un mètode: ‘check’ que ha de tenir un paràmetre d’entrada i espera un valor boleà de sortida.
Cal fixar-se en que la classe DNI cada vegada que afegeixi un element a la base de dades (en aquest cas una simple llista), cridarà a tots els plug-ins que compleixin el contracte per l’ordre en que s’han instanciat (s’han importat al codi original) mitjançant el següent codi.
for dni_check in self.dni_checks:
if dni_check.check(dni) is False:
print "El dni %s sembla no ser correcte" % ( dni )
returnUn exemple de plug-in sobre el codi anterior i que compleix el contracte especificat podria ser aquest:
import trac.core
import dni
class ValidDNI(trac.core.Component):
trac.core.implements(dni.IDNIInput)
def check(self, dni):
if type(dni) is not type("str"):
return False
if len(dni) != 9:
return False
return TrueEs pot veure com la classe és una instància de ‘trac.core.Component’ (model Singleton) i implementa la interfice ‘dni.IDNIInput’. A nivell funcional el que es fa és ben simple, comprovem que sigui una cadena de texte i que tingui una mida de 9 caràcters, si això es dona retorna un ‘True’ o sinó un ‘False’.
Un exemple de com quedaria el codi principal seria:
import trac.core
class IDNIInput(trac.core.Interface):
def check(nom):
""" Es cridada cada cop que s'entra un nou dni"""
class DNI(trac.core.Component):
dni_checks = trac.core.ExtensionPoint(IDNIInput)
def __init__(self):
self._dnis = []
def add(self, dni):
assert not dni in self._dnis, "DNI ja existeix"
for dni_check in self.dni_checks:
if dni_check.check(dni) is False:
print "El dni %s sembla no ser correcte" % ( dni )
return
self._dnis.append(dni)
def llista(self):
print self._dnisExemples d’ús:
>>> import trac.core
>>> from dni import DNI
>>>
>>> dni_bd = DNI(comp_mgr)
>>> dni_bd.add("38135009C")
>>> dni_bd.add("38135009")
>>> dni_bd.llista()
['38135009C', '38135009']
# importem el plug-in check_dni
>>> import check_dni
>>> dni_bd.add("11111111")
El dni 11111111 sembla no ser correcte
>>> dni_bd.add("11111111A")
>>> dni_bd.llista()
['38135009C', '38135009', '11111111A']Definim el codi ‘log_dni’ que serà un altre plug-in:
import trac.core
import dni
class LogDNI(trac.core.Component):
trac.core.implements(dni.IDNIInput)
def check(self, dni):
print "Nou dni entrat %s" % (dni)Seguim amb l’exemple anterior:
# importem ara el plug-in 'log_dni'
>>> import log_dni
>>> dni_bd.add("22222222B")
Nou dni entrat 22222222BA aquestes altures ja s’han carregat dos plug-ins que treballen un després de l’altre i s’ha pogut apreciar la simplicitat i potència del model. Obviament es poden trobar coses a faltar com per exemple algún element que defineixi el llistat de plug-ins disponibles i que permeti alterar l’ordre en que aquests s’executen però això ja s’hauria de desenvolupar a part.
Espero haver-ho descrit de forma entenedora i sent el més fidel possible a les explicacions del Pau, al que he d’agrair-li l’esforç i dedicació per explicar-me aquest model de Plug-ins de Python.
Reading time: 3 – 5 minutes
Aquestes últimes vacances a madeira he aprofitat per utitlizar una eina que fins ara incorporaven els mòbils que tenia però que fins ara que m’he passat a Android no m’he decidit a expremer, estic parlant d’htc footprints. És una eina que a partir d’un simple formulari permet registrar llocs emblemàtics, bonics, interessants, curiosos o que simplement volem recordar. Aquest formulari guarda coses com una fotografia del lloc, un títol, la posició del GPS, la direcció, pots afegir-hi comentaris de text i fins hi tot de veu; potser hem deixo algún detallet del que pots afegir-hi per cada entrada a footprints però escencialment això és tot el que fa. Obviament el bo del tema és que gràcies a les tecnologies que incorpora el telèfon omplir el formulari és ben senzill, ja que la foto, posició del GPS o gravació de veu es fan amb simples clics, com sempre el més molest és escriure text.
L’interessant del tema és que després això es pot exportar a un fitxer .kmz (tot el contingut del footprints) o un fitxer .kml (només una entrada del footprints). El .kmz conté en escència un paquet amb un fitxer kml i els arxius externs del footprints, per exemple, les fotografies o l’audio. Pel que fa al format del fitxer .kml es tracta d’un fitxer XML amb el contingut del formulari que he comentat anteriorment. Aquests fitxers són directament importables al Google Earth i a moltes altres eines de la saga de Google. Però el que a mi m’interessa comentar en aquest article és la llibereria libkml, també de google, la que vaig usar per parsejar el fitxer kmz de les vacances a Madeira.
A través d’un simple codi amb python vaig generar el codi en format dokuwiki necessari per montar-me l’esquelet de la web de les vacances a Madeira. De fet, el codi no esta gens polit i esta extret d’snippets d’exemple que he trobat per la web, però pel que jo volia era més que suficient. Al final del post hi teniu un enllaç.
Fa dies que en aquesta línia dono voltes a la idea de montar-me un servei que després de fer una entrada al footprints amb el mòbil enviï automàticament el fitxer .kmz/.kml per email a una direcció reservada que parsegi el correu i que automàticament doni d’alta aquest contingut a alguna de les seccions d’oriolrius.cat, de fet, encara no tinc clar si la millor idea és injectar-ho com a post o com a entrada del wiki, el que si que tinc clar és que això després s’haurà de referenciar al meu lifestream perquè així quedi constància de llocs interessants que coneixo i que sempre que vols recordar ja has oblidat. Si algú té idees de com millorar aquesta idea, ja ho sap, que m’avisi.
Referències:
NOTA: el codi del dokuwiki usa el plugin de google maps.
pkg-config és una eina que ens ajuda quan hem de compilar aplicacions i llibreries. Permet descobrir les opcions que s’han d’afegir al compilador.
Alguns exemples ràpids de coses que podem fer:
# descobrir llista de llibreries que tenim instal·lades:
pkg-config --list-all
# cflags per una lliberia concreta
pkg-config nom_llibreria --cflags
# llibreries a incloure al compilador per una llibreria concreta
pkg-config nom_llibreria --libsSovint faig molts scripts de sistema usant python com a llenguatge de programació, doncs bé, sobretot quan aquests scripts s’han de llençar usant el ‘crontab’ va molt bé tenir un bon ‘log’ per saber com van les coses. Així doncs, la setmana passada vaig decidir posar-me a fons amb el tema ‘logging’ de python i ara la forma de fer ‘logs’ que uso per defecte en els meus scripts és:
Snippet de codi python que poso als scripts:
import logging,logging.config
# logging
logging.config.fileConfig('script_logging.ini')
#logger = logging.getLogger('errorpantalla')
logger = logging.getLogger('errorfitxer')
logger.setLevel(logging.INFO)Després d’importar la llibreria de ‘logging’ es recuperar el fitxer de configuració on estan definits els paràmetres de ‘logging’. Un cop carregat, descomento una o les dues línies que hi ha a continuació en funció de si vull logs per pantalla o només contra un fitxer. La última línia només indica fins a quin nivell de depuració he de fer mostrar logs.
El fitxer de configuració:
[loggers]
keys=root,errorpantalla,errorfitxer[handlers]
keys=fitxer,pantalla
[formatters]
keys=form01
[logger_root]
level=DEBUG propagate=1 channel= parent= qualname=(root) handlers=
[logger_errorpantalla]
level=DEBUG propagate=1 channel=errorpantalla parent=(root) qualname=errorpantalla handlers=pantalla
[logger_errorfitxer]
level=DEBUG propagate=1 channel=errorfitxer parent=(root) qualname=errorfitxer handlers=fitxer
[handler_fitxer]
class=handlers.RotatingFileHandler level=DEBUG formatter=form01 filename=paht_to_log_file/log_file mode=a maxsize=0 backcount=1 args=(‘paht_to_log_file/log_file’, ‘a’, 0, 1)
[handler_pantalla]
class=StreamHandler level=DEBUG formatter=form01 stream=sys.stderr args=(sys.stderr,)
[formatter_form01]
format=%(asctime)s %(levelname)s %(message)s datefmt=
A més vaig trobar un petit script, que carrega una GUI per generar les configuracions dels fitxers de configuració dels ‘logs’, realment útil i simple d’usar:
Aquesta GUI l’he trobada al paquet: logging-0.4.9.6.tar.gz concretament al directori ‘tests’. Si no voleu buscar tant també podeu descarregar-lo directament: logconf.py.
Reading time: 6 – 9 minutes
Des de fa uns mesos m’he posat a fons amb Clutter, es tracta d’una API més una ABI programada en C per crear interficies d’usuari. Malgrat tractar-se en escència d’una API per crear espais 3D amb objectes 2D, té la capacitat de poder moure els objectes en la coordenada Z. Així doncs, és pot aprofitar la potència d’OpenGL de forma transparent i senzilla i sense haver-se de preocupar de com representar objectes 2D en espais 3D, cosa gens senzilla per un neofit en el món dels gràfics com jo.
Clutter usa el seu propi reactor d’events, però en certs casos pot usar Gobject, Glib i Gtk també. És fàcilment integrable amb DBUS i amb GStreamer. En escència m’ofereix tot el que em cal per un projecte que porto entre mans. Pels que encara no ho tingueu clar, l’interficie gràfica que usa Moblin esta programada amb Clutter com a llibreria gràfica. De fet, és aquest projecte el que li ha donat molta força a Clutter que disposa de 29 programadors a temps complet, dels quals 14 no són d’intel (intel és qui promociona amb més força ‘moblin’).
Bé doncs, aquest impuls que ha patit moblin l’han portat a la versió 0.9.8 que és realment potent i ja gairebé igual que la versió 1.0 que hauria de sortir en breu. Tot i que fins ara Clutter s’ha caracteritzat pel retard en la sortida de les noves versions esperem que aquest cop no sigui així.
Abans d’entrar a definir quins són els elements que té aquesta llibreria, comentar que també disposa de binding de python cosa que pels ‘no-programadors’, com jo, és tota una alegria. També s’ha de dir que a dia d’avui, no hi ha bindings oficials per la branca 0.9 de Clutter que és l’experimental, o futura 1.0. Així doncs, jo només he provat el Clutter fins a la seva versió 0.8, malgrat la segueixo amb lupa la versió 0.9.x; a l’espera de poder començar a fer coses amb ella quan tingui els bindings de python.
Anem al motiu central de l’article, repassar els conceptes que usa Clutter fins a la verió 0.8:
Per fer aquesta referència m’he basat amb la informació de la guia ‘Programming with Clutter‘ escrita per Murray Cumming.
La idea que es persegueix al usar múltiples esquemes en un sol projecte és la de poder usar múltiples bases de dades en un sol projecte. La idea sembla molt senzilla, però a través de la documentació oficial del projecte Symfony la veritat és que no he sabut trobar la solució. En l’explicació per portar a terme aquesta funcionalitat hem referiré tota l’estona als fitxers .yml i no als .xml equivalents, però suposo que la idea és totalment exportable.
Es tracta de deixar d’usar el fitxer schemal.yml i passar a usar diferents fitxers anomentats nomarbitrari_schema.yml, si encomptes d’un nom voleu usar un número tampoc hi ha problemes per fer-ho, per exemple, 1_schema.yml i successius.
Pel que fa al contingut d’aquests fitxers és el de sempre, tot i que jo ús recomanaria usar petites ajudes com aquesta:
nombasededades:
_attributes:
package: lib.model.nombasededades
Aquest nombasededades l’usarem després per especificar les dades de connexió al fitxer databases.yml, però potser el més interessant és fixar-se en el paràmetre package que ens permet que tot el model de dades quedi guardat dins de lib/model/nombasedades. O sigui, que tot queda molt més ben organitzat i fàcil d’accedir.
Cal que vigileu si dues bases de dades tenen dues taules que s’anomenen igual, ja que si això passa llavors hi haurà un conflicte en els models de dades que es generen, perquè aquestes tindran el mateix nom. Això és fàcilment solucionable simplement a l’schema heu de dir-li que el nom de la classe que representa les dades d’aquella taula de la base de dades és un nom diferent al de la taula, o sigui, el nom escollit per defecte.
Pel que fa al fitxer databases.yml el seu contingut és el de sempre, simplement cal que penseu que cal descriure la connexió de cada una de les bases de dades que heu anat declarant als diferents fitxers d’schema.yml, un exemple:
all:
nombasededades1:
class: sfPropelDatabase
param:
...
nombasededades2:
class: sfPropelDatabase
param:
...
Un cop ben configurat tot això ja podem fer un típic symfony propel-build-model i llestos.
Per fi he trobat un plugin de highlighting que m’agrada, l’he trobat avui a través del blog del François Zaninotto. Llàstima que el plugin és força antic, no hi ha actualitzacions des de l’any 2006. Quan l’he instal·lat al WordPress 2.5.1 m’ha donat un problema amb els permisos malgrat estava com a administrador. Així doncs en un moment li he fet un workaround, o sigui, com que el blog només l’uso jo ara mateix i no uso els usuaris m’he saltat la validació que fa de si tinc permisos. D’aquesta manera l’he pogut configurar com pertoca.
Per si algú vol fer el mateix, al fitxer syntax_hilite.php li he comentat les línies que podem veure a continuació:
[php num=268]<br>//function for the Admin GUI<br>function igSynHilite_GUI() {<br>global $user_level, $igWpVersion;<br>get_currentuserinfo();<br>//if user is not an admin equalling/above level 8, then don't give any GUI<br>/*<br>if ($user_level < 8) { ?><br><div class="wrap"><br><h2>iG:Syntax Hiliter(v<!--?php print(IG_VERSION); ?-->) Configuration</h2><br><!--?php _e("<br><br><div style="color:#770000;">You are not a <strong>LEVEL 8</strong> or above USER &<br ?--> hence you cannot configure <strong>iG:Syntax Hiliter</strong>. If you are a <strong>LEVEL 8</strong> or above USER,<br>then please Logout & Login again.<br><br></div><br>"); ?><br><br><?php return; } */ if(!empty($_POST['igsh_plainTxt'])) { [/php]A més, els directoris que crea el fitxer .zip de la pàgina del plugin no són compatibles amb el WordPress 2.5.1. O sigui, que adjunto un .tar.gz amb els fitxers que he posat a BLOG_HOME/wp-content/plugins.
Per cert, el look’&’feel del plugin és el que podeu veure en el codi que hi ha aquí dalt.
Reading time: 4 – 6 minutes
Aquest matí l’Alfredo m’ha informat que reddit ha obert el seu codi. Doncs bé després de mirar-me cada un dels components que ha explicat que esta usant m’ha faltat temps per passar-me per cada una de les pàgines web de les aplicacions per mirar-me a veure què tal. A continuació ús faig una llista del que més destaco, obviament són les aplicacions més inusuals i menys conegudes.
S’ha de reconeixer que han fet molt bones eleccions aquesta colla, a més s’ha demostrat que són realment escalables i que la seva disponibilitat és envejable. Un bon exemple de com fer les coses bé i senzilles des del principi. La gent de twitter en podrien prendre bona nota. Si ús fa il·lusió un dia d’aquests ús explicaré les meves idees de com fer que twitter sigui molt escalable i no s’enfosi amb els 2M d’usuaris que té diariament, la qual cosa no em sembla cap exageració amb un bon disseny darrera segur que en Pau pateix molt més amb els seus milions de megues a indexar diarimant.