Protocol Buffer

Escrit per Aaloy a 08 de July , 2008 a les 10 p.m.

Protocol Buffer és una llibreria d'intercanvi de dades que Google ha alliberat i que segons promet és de 20 a 100 vegades més ràpida que l'XML (i ja no parlem de SOAP) per a l'intercanvi de dades entre aplicacions.

Lo de la velocitat s'haurà de comprovar, però el que sí pareix clar és que és prou senzilla per ser abastable, la documentació és bona, i ja va dirigida als tres principals llenguatges de programació (C++, Java i Python).

Com que en faig servir dos habitualment, doncs es cosa de fer-hi una ullada i algunes proves d'stress a veure si realment és tant ràpida com diuen.

La cosa no sé si s'imposarà com a format d'intercanvi entre llocs d'Internet, però el que sí tenc clar és que si és més ràpid pot ser ideal com a format per a tecnologies SOA dins de la mateixa empresa. Una reducció d'un factor 10 ja seria prou bona, amb l'avantatge de que es podrien crear (com ara, per cert) serveis en un llenguatge i consumir-los en un altre, però sense tenir que pagar el preu que suposa en termes de rendiment fer-ho en format WSDL.

Es prest, per donar-ne una opinió amb més fonament, però pel que he vist de la documentació i els exemples, crec que aquest format i jo ens durem bé :)

2 comentaris, 0 trackbacks (URL) , Tags: Informàtica Python Java


Django i oracle

Escrit per Aaloy a 06 de July , 2008 a les 1:10 p.m.

Aquesta setmana ens hem vist amb la necessitat de crear una aplicació que havia de connectar amb un web service i agafar les dades de l'aplicació legacy que està feta en Oracle.

Hi havia dues alternatives, l'opció de salvemos el culo que implicava fer-ho tot en Java i no arribar a temps, o jugar-nos-la i fer-ho en Python i Django, i aquí el Boogeyman [1], no ens havíem trobat mai amb la necessitat de connectar directament Django amb Oracle, així que el primer de tot va ser veure com es podria fer i si ens trobaríem algun problema.

Per connectar amb Oracle, s'han de fer servir una llibreria anomenada cx_Oracle i de les llibreries d'Oracle mateix. Com que no vaig trobar les llibreries per la meva versió d'Ububuntu, doncs a compilar toca!. Vaig trobar una guia força bona a la web, sols vaig necessitar instal·lar una llibreria addicional a Ubuntu - si no la teniu en executar us petarà per a que no la troaba, i posar les llibreries d'Oracle a l'ldconfig.

Així doncs, vençut el Boogeyman, tota la resta era conegut i controlat: els serveis web amb ZSI encara que pot resultar un poc embullat al principi, quan li agafes el què, és molt potent. Si a més li posam una façada per adaptar-ho al que volem, consumir serveis web fets amb SOAP deixa de tenir misteri. Per una altra banda la part de manteniment web amb Django ja està força controlada, i la part de consola que també havia de tenir l'aplicació tampoc era nova. Python de fet té una utilitat anomenada Cmd o també es pot fer servir una utilitat de tercers anomenada cmd2 que hi afegeix algunes característiques interessants.

L'important d'aquesta història, però, no és la batalleta, no és tant veure que es pot fer feina amb Oracle amb Django i Python, sinó adonar-se de que per a que un projecte es pugui dur a terme amb garanties una de les coses més importants que s'han de fer és descobrir aquelles coses que sabem que no sabem i a ser possible descobrir el més aviat possible allò que no sabem que no sabem.

Si en aquest projecte s'hagués començat per altres tasques ens hauríem pogut trobar en dificultats a l'hora d'accedir a les dades i la feina feta serviria ben poc, o si més no, el projecte s'hauria endarrerit. Controlant el primer de tot el que pot donar dificultats augmenta les nostres possibilitat d'èxit.


[1] El Boogeyman representa allò que desconeixem i que ens fa por. Als projectes és important descobrir el primer de tot els monstres ja que ans al contrari ens poden donar un ensurt en fases on ja no hi podem fer res.

0 comentaris, 0 trackbacks (URL) , Tags: Informàtica Gestió de projectes


Sigues dinàmic

Escrit per Aaloy a 29 de June , 2008 a les 3:53 p.m.

L'altra dia vaig fer un petit prototip per veure amb quines dificultats em trovaba a l'hora de connectar amb Python contra l'LDAP de l'empresa (un Notes) i contra l'Active Directory. Aquesta funcionalitat ja la tenia desenvolupada en Java, però com que l'aplicació que estava plantejant es faria amb Python, vaig començar a mirar els tempes més problemàtics: l'autentificació i com imprimir els pdfs.

La connexió amb l'LDAP i la funcionalitat que volia, per tal d'obtenir tota la informació del l'usuari que es connectava no va ser gens problemàtica, en total 76 línies de codi davant les 350 llargues de Java, o el que és el mateix en Python vaig haver d'escriure un 80% menys de línies per a tenir la mateixa funcionalitat. D'això no poden concloure que sempre els programes en Python seran un 80% més curts, però és una evidència més del que parlam quan deim que s'escriu molt menys codi i que és més ràpid fer-ho.

El perquè en aquest cas concret, dóna peu a aquest apunt, presentarem la manera de tractar amb Python dues situacions bastant comuns quan ens hem de connectar a altres sistemes o fer servir llibreries de tercers: la transformació de diccionaris en objectes i el com tractar el cas en que tenim múltiples paràmetres opcionals.

Diccionaris a objectes

La situació és la següent: tenim un diccionari que volem passar com a paràmetre i fer servir les seves claus com si fossis propietats de la classe, de tal manera que si una clau no existeix ens dóni el valor per defecte.

Aquesta situació me la vaig trobar connectant a l'LDAP. La llibreria de Python en interroga l'LDAP torna un diccionari i volia que aquest diccionari formàs part de la classe Usuari que havia de contenir tota la informació de l'usuari que s'estava connectant a l'aplicació.

Suposem doncs que el diccionari que ens retornen és:

dades = {'nom': 'Antoni Aloy',
         'telefon': '555 55 55 55',
         'localitat': 'Binissalem',
         'email': 'aaloy@example.com',
         'blog': 'http://trespams.com'
    }

El que volem és posar tota aquesta informació dins una objecte de tipus Usuari de tal manera que sigui fàcilment manipulable i entendible. És a dir, que puguem fer usuari.telefon,

       class Usuari:
           "Exemple de com transformar les claus d'un diccionari en propietats"
           def init(self,ldap_prop = dict()):
               self.__propietats = ldap_prop

    def __getattr__(self, name):
        "Obtenim l'el valor de la propietat del diccionari"
        try:
            return self.__propietats[name]
        except:
            return "No assignada"

    def __str__(self):
        "Representació textual de l'usuari"
        return "%s - %s" % (self.nom, self.email)

    def propietats(self):
        "Retorna la llista de propietats"
        return self.__propietats.keys()

Ho podríem fer servir amb el codi següent:

    if __name__ == "__main__":
        u = Usuari( ldap_prop = dades)
        print "Nom %s" % u.nom
        print "Telefon %s " % u.telefon
        print "Provincia %s " % u.provincia
       print u

El nostre cas era prou senzill, si volem quelcom més complexe podem anar a a una recepte de Michael Foord, on podem veure com s'extén l'objecte diccionari per a fer el mateix que hem fet en el nostre exemple i a més permetre la utilització de paràmetres normals.

Parametrització

Tenim una classe amb una gran quantitat de paràmetres que es poden modificar. Per defecte tots aquests paràmetres tenen un valor per defecte. Volem que l'usuari pugui actualitzar els valors i obtenir-los. A més hi pot haver paràmetres que són sols de lectura.

Aquesta situació me la vaig trobar instanciant classes de Reportlab. A l'hora d'utilitzar la llibreria ens trobam en aquesta situació: tenim una gran quantitat d'atributs que podem assignar, però la major part del temps els valors per defecte ja ens estan bé. Vegem com ha resolt la situació la gent de Reportlab:

    class BaseDocTemplate:
        """...."""
        _initArgs = {   'pagesize':defaultPageSize,
                        'pageTemplates':[],
                        'showBoundary':0,
                        'leftMargin':inch,
                        'rightMargin':inch,
                        'topMargin':inch,
                        'bottomMargin':inch,
                        'allowSplitting':1,
                        'title':None,
                        'author':None,
                        'subject':None,
                        'keywords':[],
                        'invariant':None,
                        'pageCompression':None,
                        '_pageBreakQuick':1,
                        'rotation':0,
                        '_debug':0}
        _invalidInitArgs = ()
    
        def __init__(self, filename, **kw):
            """create a document template bound to a filename (see class 
                documentation for keyword arguments)"""
            self.filename = filename
    
            for k in self._initArgs.keys():
                if not kw.has_key(k):
                    v = self._initArgs[k]
                else:
                    if k in self._invalidInitArgs:
                        raise ValueError, "Invalid argument %s" % k
                    v = kw[k]
                setattr(self,k,v)
    
            p = self.pageTemplates
            self.pageTemplates = []
            self.addPageTemplates(p)
            ...

A l'hora de crear la classe BaseDocTemplate els atributs es defineixen dins un diccionari _initArgs, a la inicialització de la classe l'únic paràmetre obligatori és filename, però perfectament podem fer

myTemplate = BaseDocTemplate(filename="test.pdf", showBoundary=1, author="aaloy")

A l'init el que fa es repassar-se tots els atributs que hem definit al diccionari, si els paràmetres que s'han passat no coincideixen amb la clau del diccionari es crea un nou atribut a l'objecte amb el valor que té al diccionari (el valor per defecte). En canvi si hi és, verifica primer que no sigui un paràmetre de sols lectura, comprovant-ho a _invalidInitArgs i en cas que no ho sigui crea l'atribut amb el valor que li passam com a paràmetre en lloc del valor per defecte que té definit al diccionari.

D'aquesta manera ens permet utilitzar i assignar valor molt fàcilment i sols inicialitzar allò que necessitam.

La quantitat de codi que ens estalvien aquests deus receptes és proporcional al nombre d'atributs que tengui la nostra classe si la fessin en un llenguatge de programació no dinàmic.

4 comentaris, 0 trackbacks (URL) , Tags: Python


No estàs sol

Escrit per Aaloy a 26 de June , 2008 a les 8:15 p.m.

"When the productive have to ask permission from the unproductive in order to produce, then you may know your culture is doomed."

Llegit a un apunt de James Carr que a la seva vegad ho havia llegit del lblog de Reg.

Pels que els costa un poc més llegir l'anglès que el català:

Quan els productius han de demanar permís als improductius per tal de produïr, llavors saps que la teva cultura està condemnada.

On diu cultura, posau-hi empresa o la vostra organització altament jerarquitzada, sí, aquella que posen sempre d'exemple quan es parla del principi de Peter.

2 comentaris, 0 trackbacks (URL) , Tags: General Conyes marineres


La meva experiència amb Django

Escrit per Aaloy a 22 de June , 2008 a les 12:03 p.m.

En Maties Bonet ens va escriure un e-mail a mi i a Guillem demanant-nos per la nostra experiència en l'ús de Django.

Amic Maties, bona cosa has demanat! Pepara't perquè aquest apunt pot ser llarg :)

La meva relació seriosa amb Django ja té més de dos anys, és difícil estimar la data, però si en tingués que donar una seria la del 3 d'agost del 2006, data del primer commit del major projecte que hem fet amb Django fins ara,amb actualment més de 12.000 línies de codi

Aquest projecte inicialment estava desenvolupat en PHP, però necessitàvem més funcionalitat i essent les nostres filies més tendents cap al Python que cap a altra cosa, començarem a investigar els bastiments que començavent a surgir. Cercàvem quelcom que permetés una bona escalabilitat, facilitat de desenvolpament i una separació molt clara entre codi i capa de presentació. A més una de les restriccions inicials era que el servidor que tenia que dur tot això no havia de ser massa potent, un host virtual baratet hauria de ser suficient per començar.

Amb Juan avaluarem un grapat d'opcions. Anàvem mirant frameworks i en discutíem els avantatges i inconvenients. Férem una ullada a Pylons, a TurboGears i alguns altres, fent algun prototip i discutint-ne els resultats.

TurboGears estava força bé, i Pylons representava gairebé l'estat de l'art en quant a integració de componentes, però Django tenia una avantatja per a nosaltres fonamental: la seva integració entre els distints components (integració que a més no compromet a res), una documentació fantàstica i el ser un bastiment que s'havia fet servir en projectes grans, en projectes que estaven funcionant. Es podria dir que no era sols una idea sinó que el funcionament del framework era una realitat.

Així doncs ens decidirem per Django. Mesos després Guido Van Rossum com el framework que li agradava més. Un any i mig després veuríem Django com un bastiment suportat per Google. Això vol dir que tenim bon ull per les tecnologies? Segurament, però vist en perspectiva l'elecció de qualsevol dels altres dos bastiments també ens hauria anat força bé.

Django, però té aquell quelcom que et fa sentir content i satisfet amb la programació que fas. És entenidor i abastable i quan t'enfrontes a un problema de la vida real trobes que hi ha una solució en Django, per una raó molt senzilla: el bastiment es va crear per resoldre problemes de la vida real, com una resposta a la necessitat que tenien els seus creadors de tenir un bastiment que els proporcionàs una gran rapidesa en el desenvolupament i al mateix temps una gran escalabilitat.

Una vegada vàrem veure la potència del bastiment, junt amb la potència de Python i ho compararem amb el que teníem i feiem en Java, el pas següent va ser lògic: utilitzar el que sabíem en la feina diària per a l'empresa per la qual treballàvem, una multinacional del turisme. Sense deixar Java del tot, ara podíem incorporar una nova eina que ens permetria poder desenvolupar webs a la velocitat que li agradava al negoci.

Posar Django i Python a una empresa molt tradicional no és senzill, "aquest tipus de la web sempre fent coses rares!" Però l'evidència s'imposa i amb un poc de ma ampla del nostre director d'informàtica anterior començarem a fer els nostres primers projectes amb Django per a l'empresa. És una tasca que avui en dia encara costa. Quant més consultors externs té l'empresa més difícil és aquesta tasca. Aquests suposats experts no tenen idea de què és Django i de les seves possibilitats, i tampoc els convé, ja que després de la consultoria hi sol haver un desenvolupament i com que el desenvolupament és més ràpid i ells cobren per hores, doncs que no convé gaire. Però això és una altra història i també serà un altra apunt.

Actualment doncs, feim/faig servir Django i Python en quatre grans tipus de projectes:

  • projectes on no s'ataca a la base de dades "legacy" de l'empresa, sinó que s'han desenvolupat des de zero.
  • projectes on hi ha una gran part de continguts i a més lògica de negoci senzilla.
  • projectes que consumeixen web services en SOAP que estan a la seva vegada desenvolupats en Java.
  • el nostres projectes particulars, com aquest blog.

Els resultats són molt bons, un exemple: fa dues setmanes ens telefonaren del dimecres per a un projecte crític, s'havia de crear una web completa per a un client que havia d'estar llesta el divendres al matí de la mateixa setmana. El dimecres horabaixa en tendríem més detalls.

L'horabaixa ens defineixen un poc millor el projecte: bàsicament contingut que se'ns aniria passant en format word i que segurament aniria sofrint modificacions damunt la marxa.

Tot just penjar el telèfon ens posarem en marxa. La gent de sistemes creà el repositori subversion pel projecte (no importa la pressa que tenguis, sempre, sempre un control de versions) i inicià la configuració del nou domini.

Una hora després ja teníem el domini intern funcionant i la primera versió del codi dins el subversions. Havíem reaprofitat la funcionalitat que teníem per a la gestió de continguts i ara sols era cosa de crear el disseny, passar-ho a plantilles i posar el contingut. El que ens feia més por era no tenir els DNS replicats per l'hora d'entrega.

El dijous al matí el disseny ja estava llest i es comença a maquetar i pujar continguts. Es crearen algunes plantilles per a fer que les opcions de menú canviessin dinàmicament i s'anava pujant tot al servidor de producció mitjançant un update del subversions. El temps de pujada d'una nova versió era aproximadament de 30 segons, versió que ja pujava testejada gràcies a que amb Django pots anar provant l'aplicació amb el seu servidor integrat (i amb recàrrega automàtica).

Ens sobraren un parell d'hores del temps limit. Total del projecte 35 hores-home. Entregable: aplicació amb subdomini propi, tipus portal de continguts, multi-idioma, amb menús desplegables, i la maquetació a partir de documents word de l'equivalent a una trentena de planes web amb una mescla de text, fotografies i descàrrega d'arxius. Rendiment de l'aplicació: generació d'una plana web en 1,2 segons sense caché.

Si ho haguéssim tingut que fer en Java encara estaríem muntant el CMS o pujant els continguts. Amb les plantilles de Django i la possibilitat d'herència que tenen, poguérem crear el nostre lloc web amb molt poc temps i passar els continguts a HTML de manera molt més ràpida que l'equivalent a crear el disseny en un CMS clàssic de PHP o Java (ja no en parlem de fer el mateix amb Java i sense CMS).

El millor de tot és que encara que no sabíem que se'ns demanaria estàvem raonablement segurs de que si no era res molt complexe es podria fer, ja que el bastiment no ens fermava (com sovint fan els CMS més habituals) sinó tot el contrari.

La meva experiència amb Django? Fantàstica i demostrable. Fins al punt que quan veig el que puc fer en aquest entorn em fa molta peresa tornar cap a Java, els temps d'espera tot i que desenvolupam en local resulten molests, les posades en producció s'eternitzen. I això que gràcies al nostres administradors de sistemes ho tenim tot que va com una seda a l'entorn J2EE i les posades en producció són ràpides, però quan ho compares amb un pocs segons tot resulta lent.

Consider Django com un avantatge competitiu: ens permet fer desenvolpaments molt ràpidament i a més sabem que escalaran bé. Com que no estam lligats a cap bastiment de javascript concret podem incorporar el que necessitem segons el projecte: jQuery, extjs, res... i la separació que es fa en capes de l'aplicació també es pot fer a l'hora de desenvolupar i permet treballar en paral·lel a la gent de sistemes, disseny i programació.

I així doncs, quan voleu que posem Django a la vostra empresa?

4 comentaris, 0 trackbacks (URL) , Tags: Python Django


A la pregunta de Servo ....

Escrit per Aaloy a 15 de June , 2008 a les 7:20 p.m.

Al comentari del darrer apunt de Servo es demanava el perquè el Set hauria de ser més ràpid si el primer algorisme és d'ordre N.

El codi dels sets es molt semblant al dels diccionaris, però està una mica més optimitzat, a l'igual que els diccionaris està implementat com una taula hash, però a diferència d'aquests els conjunts sols guarden el parell clau/hash en lloc de la tripleta clau/valor/valor del diccionari.

Com que els sets guarden els parells clau/hash, totes les operacions binàries, com la intersecció s'executen sense cap cridada al mètode _ _hash__ dels elements individuals. Això és molt més ràpid que el codi equivalent que fa servir diccionaris.

També resulta que quan feim un bucle damunt un set Python (CPython) directament recorre la taula hash en lloc de fer ús d'un iterador (que seria un poc més lent).

La pregunta ha servit per fer un poc de recerca, de fet la meva resposta és la traducció d'una resposta molt completa l'he trobada a Python in Science .

Però no ens conformem amb això, fem un "show me the code" a la plana citada anteriorment hi ha un exemple que ens anirà bé per començar. Es tracta de trobar la intersecció de dos conjunts, però ho podem adaptar per fer les cerques al diccionari:


import random
import time
REPETICIONS = 1000

## Generam els valors
seta = set([random.randint(0,100000) for n in xrange(10000)])
setb = set([random.randint(0,100000) for n in xrange(10000)])

print "Cerques a conjunts"

t0 = time.clock()
    for i in xrange(REPETICIONS):
    total = seta.intersection(setb)
print "Intersections - Time: %s seconds"%(time.clock()-t0)

t0 = time.clock()
for i in xrange(REPETICIONS):
    total2 = []
    for element in seta:
        if element in setb:
            total2.append(element)
print "Fent el bucle Time: %s seconds"%(time.clock()-t0)

## I ara el nostre cas

print "Cerques amb diccionaris"

## Generam els valors
dicta = {}
dictb = {}
for i in xrange(10000):
    dicta[random.randint(0,100000)]=i
    dictb[random.randint(0,100000)]=i

t0 = time.clock()
for x in xrange(REPETICIONS):
    total2 = []
    for valor in dicta.keys():
         if dictb.get(valor):
            total2.append((valor, dicta[valor]))

print "Bucle - Time: %s seconds"%(time.clock()-t0)

t0 = time.clock()
for x in xrange(REPETICIONS):
    total2 = [ (repe,dicta[repe]) for repe in   set(dicta).intersection(set(dictb))]

print "Set intersection - Time: %s seconds"%(time.clock()-t0)

I aquí el resultat


Cerques a conjunts
Intersections - Time: 0.94 seconds
Fent el bucle Time: 6.11 seconds
Cerques amb diccionaris
Bucle - Time: 11.63 seconds
Set intersection - Time: 6.97 seconds

En el primer cas estam davant un algorisme d'ordre N² davant un algorisme NlogN sin o record malament de la intersecció de conjunts.

El nostre cas és una mica menys clar en el que fa a l'ordre de l'algorisme, però amb el codi es pot veure com el resultat final s'obté és un 60% més ràpid.

Tot i això fixem-nos amb que per a obtenir el resultat en segons he tingut que fer 1.000 iteracions i que hem fet servir un conjunt de 10.000 elements, sols per a que quedi clar de que potser ambdós algorismes són prou ràpids per a la nostra tasca diària. Sols hem de tenir clar que quan cerquem maneres d'optimitzar el nostre codi, mirar si feim aquests tipus d'algorismes moltes vegades

0 comentaris, 0 trackbacks (URL) , Tags: Python


Trobar elements repetits

Escrit per Aaloy a 15 de June , 2008 a les 12:37 p.m.

Tenim el següent problema: "tenim dos diccionaris amb dades i volem trobar els elements d'una diccionari que estan també dins l'altra"

Suposem, per exemple que tenim:

x = {'a':1,'b':2,'r':3}
y = {'a':1,'r':3, 'c':14}

La opció més directe pareix ser la de recorre els elements de la primera llista i veure si hi són a la segona, una cosa com

for valor in x.keys():
    if y[valor]:
        print valor, y[valor]
a 1
r 3

o bé una altra opció més curta:

for repe in set(x).intersection(set(y)):
     print repe, x[repe]

o si m'apurau

[ (repe,x[repe]) for repe in set(x).intersection(set(y))]
[('a', 1), ('r', 3)]

Ara quan algú us demani que és això de que Python ve amb les piles incloses ja teniu un exemple més per a mostrar.

4 comentaris, 0 trackbacks (URL) , Tags: Python


Millores al blog

Escrit per Aaloy a 08 de June , 2008 a les 11:30 a.m.

De tant en tant faig feina al blog, no per escriure-hi sinó per afegir-hi noves funcionalitats. Encara hi ha moltes coses que m'agradaria posar-hi i millorar, però a poc a poc esper anar arribant-hi.

A la darrera actualització he fet algunes millores que recomanaven al Google Webmaster Tools com la d'afegir descripcions úniques per apunt. Django a les seves plantilles té el filtre truncatewords_html que m'ha anat fantàstic per això.

Una de les millores que volia fer també era la d'amagar un poc tota la llista de mesos que hi ha. Aquest blog té apunts des del 2004 i la llista començava a ser molt llarga. Ara veureu que sols apareixen els anys (sempre que tingueu el javascript activat clar) i que en pitjar damunt ells es despleguen els mesos. Fer això ha estat entretingut perquè ha implicat jugar amb dos tags més de Django, el for per obtenir si estava a la primera posició del bucle o a la darrera, per tal de poder tancar els divs, i el tag ifchanged que ens permet saber si una variable (en el meu cas l'any) ha canviat o no respecte al seu valor anterior.

Amb aquestes eines ha estat possible muntar l'estructura necessària per a utilitzar un el Animated Collapsible DIV, una petita utilitat per jquery que permet ocultar i mostrar divs a voluntat, agrupant-los per categories si convé.

Ara la plana principal al meu entendre queda un poc més neta i amb prou espai a la columna lateral esquerra per anar afegint més coses.

0 comentaris, 0 trackbacks (URL) , Tags: Informàtica Python Django


Capa de negoci a Django

Escrit per Aaloy a 28 de May , 2008 a les 11:55 p.m.

Del post anterior em quedava el tema de tractar el tema de la capa de negoci en els llenguatges dinàmics. Com en el cas anterior faré servir Django com a exemple i deix al lector la feina d'extrapolar cap el seu llenguatge dinàmic+bastiment preferit.

En Domingo diu que els llenguatges dinàmics mostren molta de la seva potència a la capa de presentació, que és allà on en treuen més profit. Això és veritat però es queda curt. És a dir, quan un usuari demana un canvi, el més habitual és que aquest s'acabi reflexant en la capa de presentació,però això no vol dir que no se canvii la capa de negoci. El fet però és que anar des de la capa de persistència, passant per negoci i mostrar el resultat al navegador, té un cicle de temps més curt en el llenguatge dinàmic, interpretat, que en el compilat, ja que sol ser molt més curt fer els canvis (gearing factor i totes aquestes herbes) i necessitea un temps més curt de desplegament, però no ens enganem, és tot el procés que és curt, si no afecta a capa de presentació el que passarà és que el desenvolupament serà encara més ràpid.

Sovint amb les aplicacions del tipus crea el teu blog en 10 minuts en Django, Rail o qualsevol altra, es dóna una idea equivocada del que se pot fer, donant la imatge de que aquestes aplicacions van molt bé per fer webs que depenen d'un conjunt de taules senzilles i que tenen una lògica de negoci poc complexa.

Bé, supòs que podríem demanar-li a Ricardo, que és un exemple que tenim ben aprop,de com s'ho fa per calcular el karma de Meneame o per saber si una notícia ha de sortir en portada o quan ha de deixar de ser-hi. Tot això es lògica de negoci, està feta en un llenguatge interpretat, el PHP.

En el cas de Django no oblidem que el que tenim per davall és Python i que l'ORM que ens proporciona Django ho podem fer servir o no, substituir-ho per un altre, fer les cridades directament a BD o senzillament, utilitzar-ho com a part del nostre model de negoci i posar-i les regles que ens convenguin.

Segons la nostra aplicació podem anar afegint custom managers que ens permetran definir regles damunt les dades que volem obtenir, mètodes de classe per definir les funcionalitats que vagin damunt tots els elements de la taula, i missatges que ens ajudin a manipular la informació i les seves relacions.

Això ho podem fer directament des de la classe de l'ORM, el model, o bé, recordem que tenim Python a la nostra disposició, crear un nou paquet, crear una classes o un conjunt de classes i utilitzar el model per aplicar les regles de negoci que vulguem quan aquestes s'hagin de convertir en registres de la base de dades o la seva informació hagi de venir de la base de dades. Per cert, i abans que algún ho demani, sí hi ha transaccions!

Això vol dir que podem fer servir els llenguatges dinàmics per a modelar la nostra capa de negoci, doncs sí, ho podem fer. Això vol dir que la nostra aplicació ha d'estar escrita en un llenguatge dinàmic sempre? No, depèn de l'aplicació. Potser per una aplicació concreta amb un requeriments concrets tenir un contenidor EJB amb transaccions distribuïdes serà el que necessitam, el que vull dir és que no podem descartar fer l'aplicació en un llenguatge dinàmic sols perquè ens hem quedat amb la idea de que sols va bé perquè el seu ORM te crea molt fàcilment les taules i els CRUDs.

De fet la part d'administració de Django va molt bé com a eina administrativa, però no és una eina d'usuari final. Com a desenvolupador te va molt bé perquè pots fer cerques ràpidament, començar a omplir les dades del manteniments mestres i anar directament a les butzes de les dades, però no hem de confondre això ni amb l'aplicació final i amb que és tot el que se pot fer amb els llenguatges dinàmics.

I encara hi ha un punt que no hem tractat, el tema de la integració dels llenguatges dinàmics amb els llenguatges compilats (jpython, jruby, groovy, etc). Segons la nostra aplicació i els nostres usuaris, tenir un llenguatge interpretat, fins i tot creat per al domini de la nostra aplicació pot ser una opció molt interessant. Permeteu-me una batalleta: fa un grapat d'anys vaig desenvolupar el programa de gestió d'excursions de l'empresa on feia feina (Delphi + IBObjects + Firebird), una aplicació client servidor clàssica amb un grapat de procediments amagatzemats quan feia falta. La cosa és que hi havia excursions que tenien ofertes que el proveïdor donava i que s'havien de cotitzar, ofertes del tipus: "si es reserva una excursió per dos adults i un nin, el nin tendrà un 25% de descompte damunt la tarifa" o "el tercer adult es gratis i els nins no paguen" etc. Això ho podria haver desenvolupat amb un bon conjunt de camps de la base de dades i tenir previstes les condicions, però la solució hagués estat visualment atractiva però mala de programar i molt propensa a errors. Per contra vaig optar per a modelar-ho con si fos una fórmula de una fulla de càlcul, a la que els meus usuaris estaven acostumant on es podia jugar amb el preu per data, amb sumes, restes, if i tant per cents i parèntesi, un mini intèrpret pensat per a tractar amb fórmules matemàtiques. Les condicions així posades eren flexibles i amb unes possibilitats pràcticament il·limitades respecte al que haurien estat si ho hagués fet amb una "interfície amigable". En aquest cas, integrar un intèrpret a l'aplicació va ser la millor solució.

Com no me cansaré de repetir, no es tracta de dinàmics/interpretats respecte d'estàtics/compilats. Es tracta de perdre la por i els perjudicis i poder triar en cada cas aquella tecnologia que millor s'adapti al problema a resoldre de manera que aquest es pugui resoldre amb el menor cost actual i futur per al nostre client, en alguns casos aquest llenguatge serà C, C++, C#, Java o el que sigui, però en altres, en molts altres un llenguatge dinàmic serà la millor opció per als nostres clients.

5 comentaris, 0 trackbacks (URL) , Tags: Python Django Gestió de projectes


D'errors i línies de codi

Escrit per Aaloy a 26 de May , 2008 a les 9:30 p.m.

En Domingo al seu blog fa una referència al meu apunt damunt llenguatges dinàmics i un bon grapat de bones reflexions.

Això de no creure's el que dic és una postura molt sana, sobretot perquè en la redacció d'un apunt me puc deixar detall i dades que són interessants. Una postura crítica ajuda a reflexionar i a completar les frases que d'altra banda s'haurien deixat com a dogmes de fe. Jo sóc del mateix tarannà, hi ha coses que me crec i coses que a poc que vegi indicis de contradiccions, doncs cerc més informació o deman explicacions. Això, he de dir també, m'ha causat força problemes en el món empresarial, on sovint el "no pensis" és una qualitat que ajuda a progressar.

Bé, però no me'n vull anar per les bardisses, o sí, ja que hi sóm, aprofitaré per dir perquè no faig servir el Twitter: no hi ha espai abastament :)

Afirmació: El nombre de línies de codi que escriu un programador al dia és una constant. Això és un efecte estadístic. Fa temps es parlava de que un programador escriu cinc línies de codi sense errors al dia. Està clar que és una dada estadística i fins i tot controvertida, ja que que és molt complexa definir què és i que no és una línia de codi i de que les línies de codi no s'han de fer servir per mesurar el rendiment. Tot i això podem trobar referències capítol 5 de Software estimation de McConnell on a la Taula 5.1 torbam la relació entre les línies d'un projecte i les línies de codi per programador i any. Això no vol dir que tots els programadors escriguin les mateixes línies de codi (de fet la productivitat entre programador pot arribar a un factor 10 -Peopleware-, però sí que en mitja i per a una organització i projecte, el nombre de línies de codi que s'escriu en promig és constant. A Sofware Mesurement and Estimation diu "Studies have shown that a proficient programmer can programm aproximately the same number of debugged lines of code per day regarless of the language". D'aquí que gent com QSM o David Consulting Group facin comparatives entre llenguatges per a comparar l'expressivitat de cada llenguatge. Per exemple C té un gearing factor de 128 i Java de 53. Això vol dir que una funció que en C necessita 128 línies de codi en Java en necessitarà en promig 53. Si un programador experimentat escriu, essent optimistes 10 línies de codi depurat al dia, llavors necessitarà 13 dies en C i 6 en Java (nombres redons).

D'aquí llavors que els llenguatges dinàmics, al necessitar menys línies de codi per fer el mateix poden completar els projectes en un temps més curt. Com que el temps significa doblers, implica que els projectes surten més barats.

Afirmació: el número de errores directamente proporcional al número de líneas que se escriben Aquí també entram en temes estadístics. De fet es parla de nombre d'errors d'un programa per mils de línies de codi. De la mateixa manera que en el cas de les línies de codi que escriu un programador, hi ha moltes diferències, però Casper Jones a "Program Quality and programmer Poductiviy (1997)" va recopilar algunes dades, que també cita en McConnell. També Reifer en va fer estudis, per exemple per la part Web estudià 65 projectes, i trobà que el ratio és de 6 errors per KESLOC (KESLOC Kilo (Thousand) Equivalent Source Lines of Code). Aquest nombre depèn força del tipus del projecte i de l'organització, però és estadísticament significatiu. Per tant, si donam com a bo el que els llenguatges dinàmics necessiten menys línies de codi per expressar el mateix que els llenguatges compilats tradicionals (Java, C, C+, ...) tendrem que el nombre d'errors en valor absolut també serà menor.

He trobat també una comparativa entre el nombre d'erros per Java i C++ a un paper de Geoffrey Phipps anomenat Comparing Observed Bug and Productiviy Rates for Java and C++, me l'he d'acabar de llegir, però conclou que amb un 95% de confiança C++ té 9,7 vegades més defectes per KLOC que Java i que a més els defectes en Java són més fàcils de corregir. D'aquí a fer una extrapolació cap a la banda dels llenguatges dinàmics hi ha sols un pas, sols falta que algú s'animi a fer l'estudi.

En Domingo també demana l'opinió damunt els llenguatges dinàmics per la capa de negoci, però això crec que dóna per un apunt per ell sol, així que ho deixaré per la propera vegada, però promet, amenaç, amb tractar-ho.

0 comentaris, 0 trackbacks (URL) , Tags: Informàtica Python Django Gestió de projectes


Llenguatges dinàmics

Escrit per Aaloy a 25 de May , 2008 a les 11:18 a.m.

Link to Llenguatges dinàmics

Al blog de Ricardo he esta llegint l'apunt anomenat "Lenguajes dinámicos, programadores y FUD" així com els seus comentaris. Tot i que hi he deixat allà un comentari amb la meva opinió, crec que com a programador en llenguatges dinàmics i tradicionals he de dir la meva.

El primer de tot que voldria fer és evitar el FUD damunt els llenguatges dinàmics, per una raó molt senzilla: la realitat és molt cruel i estam cansats de veure i de llegir damunt projectes web realitzats en Python, Ruby o PHP que estan triomfant i que no desapareixen o exploten per mor de no tenir un llenguatge compilat al darrera. Per tant, la primera cosa que hem de tenir clara és que la teoria pot estar molt bé, però la realitat ens està dient dia a dia que és possible escriure i mantenir programes en llenguatges dinàmics. A un li poden agradar més o menys aquests tipus de llenguatges, però el que no es pot fer és negar la realitat.

També m'agradaria focalitzar l'àmbit de discussió: estam parlant de programes web. Per programes d'escriptori no tenc dades abastament, potser perquè els llenguatges dinàmics brillen en el desenvolupament web més que en la part d'escriptori, llevat de que considerem el Visual Basic com a llenguatge dinàmic, clar.

La cosa està en que amb les màquines actuals els llenguatges dinàmics son ja prou ràpids com per ser competitius amb els llenguates compilats. Això no vol dir que siguin més ràpids, sinó que són prou ràpids per fer la feina i que la diferència de velocitat que hi hagi no sigui rellevant. Que PHP ens serveixi una plana en 1 segon i en Java la serveixi en 0,98 segons, doncs no és rellevant ja que per l'usuari de l'aplicació no significarà cap diferència en l'espera.

Això vol dir que ens hem de passar ja a programar en un llenguatge dinàmic i deixar els compilats? No. Vol dir que és necessari que a més d'un llenguatge tradicional convé que tinguem al caixò de les eines un llenguatge dinàmic. D'aquesta manera quan ens demanin una aplicació podrem sospesar els pros i els contres i fer-la en el llenguatge que s'adapti millor al projecte. Fins i tot si el nostre projecte es farà en un llenguatge tradicional, tenir un llenguatge dinàmic se pot integrar al projecte en forma de rutines de generació de codi, scripts de testeig, etc.

Dit això, i considerant l'àmbit de les aplicacions web, anem a veure avantatges i inconvenients d'elegir un llenguatge dinàmic per al nostre projecte, com que el que més conec és el Python, em permetreu la llibertat de donar els exemples i les referències en aquest llenguatge, in en Java en el cas de llenguatge compilat, en el ben entès que segur que hi ha el mateix tipus de solucions en Ruby, PHP o el vostre llenguatge dinàmic preferit i en C, C++ o .Net, etc.

Cicle de desenvolupament Agafem una aplicació web típica Java desplegada a un servidor Tomcat i la mateixa aplicació feta en Python. El cicle al primer cas és: escriure codi, compilar, corregir els errors de sintaxi, desplegar-ho al servidor, provar i iniciar novament tot el cicle, bé per escriure nou codi o bé per corregir els errors. A l'aplicació Python+Django tendríem: escriure codi, provar i tornar a escriure el nou codi. L'augment de productivitat la tenim no per el fet de no tenir que corregir errors, sinó pel fet de no tenir temps d'espera en el desplegament i per haver d'escriure menys línies de codi.

Errors de sintaxi. Aquí algun haurà pensat, "s'ha deixat els errors de sintaxi", efectivament, ho he fet perquè vull dedicar-lis el seu propi apartat. El compilador caça els errors de sintaxi i ens n'informa, però això vol dir que hem d'executar el compilador, és veritat que això els IDEs com Eclipse ho fan automàticament, però tot i això s'ha de fer. Realment podem fer el mateix amb eines com Pylint o Pychecker i a més el primer a més és capaç de treure tot un conjunt d'estadístiques damunt la qualitat del codi, talment com ho fan eines Java com PMD. El pylint per exemple és el que fa servir PyDev per a indicar els errors de sintaxi i donar avisos damunt el codi. Està clar que aquests errors potser no seran tan acurats como els dels compiladors, però són prou bons com per fer la feina, amb l'avantatge, però que ho podem llançar quan nosaltres vulguem i que no s'ha de passar necessàriament pel compilador per a executar el programa.

Per una altra banda, que el compilador o pylint ens caci els errors de sintaxi ens pot donar una falsa sensació de seguretat, el errors de sintaxis poden fer petar l'aplicació, és veritat, però els errors més greus solen ser els errors en la lògica de negoci de l'aplicació. Quan aquests se detecten el que s'ha de fer és corregir-los el més aviat possible, i en aplicacions web entram en

La fase de desplegament El temps que necessitam per posar una aplicació en producció seria anecdòtic si les aplicacions no tinguessin errors. Necessitar 30 minuts o 10 minuts per una aplicació que es posi en producció i que estigui mesos o anys sense modificar-se no és significatiu. Però, si l'aplicació sofrirà canvis o els errors que es detectin s'han de resoldre el més aviat possible, una diferència de 30 minuts en el desplegament pot marcar la diferència. En el cas d'un error en la lògica de l'aplicació que afecti a un .jar, significa en el millor dels casos compilar l'aplicació o el jar corresponent, substitur-ho i reiniciar el servidor d'aplicacions o l'aplicació, cosa que pot dur entre uns 30 segons y un bon grapat de minuts, depèn del que hi hagi desplegat. El el cas d'un llenguatge dinàmic sovint basta actualitzar els arixus afectats (svn update per exemple) i fer un reload del servidor Apache que tenguem. Cosa d'un parell de segons tot plegat. Està clar que podem minimitzar el primer cas amb servidors redundants i configuracions d'alta disponibilitat, però a un cost major de complexitat.

L'orientació a la tasca Les aplicacions web tracten fonamentalment amb text i produeixen text. Agafam dades de formularis, les tractam, obtenim dades de les bases de dades i les manipulam per a presentar-les a l'usuari en una sortida HTML, etc. Tractar cadenes és part fonamental de les aplicacions, i això és una cosa que els llenguatges compilats fan en general força malament des del punt de vista del nombre de línies de codi que s'han de picar. Els llenguatges dinàmics són força bons tractant informació textual. Posaré un exemple que ens pot servir per il·lustrar aquest fet: les plantilles. En Java tenim tres llenguatges de plantilles principalment: JSP-EL (ja ho sé està agafat pels pels però acceptau-me'l), Freemaker i el venerable Velocity i en general són força infumables. Comparem-ho amb el que hi ha per Python i veurem la diferència (Django, Web String, Cheetath, Mako, Jinja, ...). No crec que sigui anecdòtic, la diferència és que és força senzill manipular text en Python i per tant és força senzill crear-te el teu propi llenguatge de plantilles.

Productivitat El nombre de línies de codi que escriu un programador al dia és una constant. Això vol dir que si volem tenir més productivitat s'ha d'anar cap a llenguatges que ens permetin escriure més funcionalitat en menys codi. Donat el boom que viuen actualment els llenguatges dinàmics encara no hi ha molta literatura al respecte in encara no hi ha ni Ruby, ni PHP ni Python al QSM, però sí que hi ha forces comparatives, una de les més interessants és la d'Stephen Ferg que senyala que programar en Python és de 5 a 10 vegades més productiu que fer-ho en Java.

Diversió i motivació Els llenguatges dinàmics són sexy. Permeten al programador un alt grau de realimentació. Pot provar les seves idees molt ràpidament i això el motiva molt més que tenir que esperar a que el compilador acabi per poder fer les proves.

Pel demés, els llenguatges dinàmics també necessiten unit tests (sols que es poden escriure més ràpidament i amb menys línies), una gestió acurada dels projectes, planificació del que volem fer i refactorització del codi.

La conclusió de tot això és que deixem de banda FUDs que no duen a res i a l'hora d'avaluar un projecte considerem també si és apte per a ser fet en un llenguatge dinàmic, si ho és endavant, el nostre cul no perilla per dita elecció, ja que tant Python, com Ruby com PHP seran prou capaços de fer la feina.

3 comentaris, 0 trackbacks (URL) , Tags: Informàtica Python Django


vim ide per python

Escrit per Aaloy a 17 de May , 2008 a les 9:22 a.m.

Aquesta setmana i gràcies a l'entrada del blog de sontek he retornat al vi com a editor principal per a la programació en Python.

Periòdicament estic canviant entre vim, kate o Eclipse amb PyDev, segons la màquina en que faig feina i el que estic fent, però pas gran part del temps fent feina amb la consola i trobar la configuració que permet tenir el millor de els entorns gràfics a vim m'ha sorprès gratament.

Amb la configuració i el conjunt de plugins que ha seleccionat sontek tenim un editor que permet tabs, autocompletat, plantilles, integració amb subversion i tota la potència d'edició de vim. El tema del depurador integrat està un poc més verd, però tampoc l'he trobat massa a faltar.

A un dels comentaris hi havia la recomanació per a la instal·lació a més de NERDTree un navegador de fitxers integrat al vim que facilita molt la vida, i també ho vaig posar. També he adaptat les plantilles que venen per Django per a que agafi la sintaxi del trunk i he afegit algun retoc més com que posi la codificació als fitxers i coses així, les plantilles són tan bones de modificar que me pareix que puc acabar amb un bon repositori de codi :)

Tot i que no poseu la configuració crec que és interessant fer-hi una ullada a com ha organitzat Sontek (John M. Anderson) el seu fitxer de configuració per veure un exemple del que es pot fer amb vim i de com es pot incloure codi Python dins l'arxiu de configuració. Una de les maneres d'aprendre a programar és llegir codi d'altres (bon codi si és possible) i en l'arxiu de configuració de vim podem dir el mateix: llegint configuracions d'altra gent podem arribar a personalitzar l'editor fins a límits insospitats.

4 comentaris, 0 trackbacks (URL) , Tags: Python Django


Tras el incierto horizonte

Escrit per Aaloy a 11 de May , 2008 a les 11:02 a.m.

Ahir vaig acabar de llegir Tras el incierto Horizonte de Frederik Pohl. La novel·la està força bé per als que com a mi ens agrada la ciència ficció dura, és a dir, amb força referències científiques i tecnològiques, i aquesta novel.la n'està farcida: intel·ligències artificials, forats negres, astronomia, referències a les constants universals...

La trama és també molt bona, lligant a poc a poc les subtrames que hi ha, com l'origen del Patriarca o els Primitius i com a bona novel·la de ciència ficció deixant-te amb més interrogants que respostes.

De totes maneres val a dir que se li nota un cert pas del temps, hi ha que pensar que l'escrit original és de 1980, quan fa referència a quantitats monetàries (1 mil·liò de dòlars per exemple donen per moltes coses a l'època i no ara) i en algunes referències als ordinadors: un gigabit és una gran quantitat de memòria, ordinadors amb aquesta memòria que omplen una nau ... Tot i això, entra també en la manera de programar les intel·ligències artificials i en el concepte de pagament per us de potència informàtica, propi dels anys 70-80 i que ara amb Google i Amazon torna a estar vigent.

El llibre es pot llegir independentment de la nove·la anterior, Pórtico, ja que les referències s'expliquen prou bé i no interfereixen gaire en la trama principal.

Deu euros ben gastats i un bon grapat d'hores de diversió!

0 comentaris, 0 trackbacks (URL) , Tags: Llibres i revistes


Pont blanc

Escrit per Aaloy a 05 de May , 2008 a les 9:40 p.m.

Com molta gent jo també m'he agafat el pont. Han estat un grapat de dies per descansar un poc, desconnectar un poc (no me'n vaig endur el portàtil) i gaudir de la companyia de la família i els amics (Pere, Marga, Aina i Neus) que amablement ens van acollir a casa seva i ens feren de guies per l'illa d'Eivissa i Formentera.

Es veu que en aquesta època encara no hi ha molta gent pel mig i es pot gaudir de les illes com toca, sense massificacions, a poc a poc i anant un poc més enllà del turisme de discoteca, bauxa i platja. Són illes fantàstiques, amb unes vistes meravelloses i on encara et pots sentir sols i acompanyat a la vegada.

Deixant els aspectes més bucòlics, dir que em va sorprendre agradablement el viatge amb Balearia (no pos l'enllaç a la plana, perquè la veritat, no li fa justícia a la comoditat del viatge i tanmateix no funciona massa bé) i desagradablement el Chevrolet Kalos que llogarem (a l'oferta d'Internet posava Peugot 206 o equivalente). Resultà un cotxe sense gens d'acceleració, de mel i sucre, amb un cosum molt més alt que el que em pensava (amb el Saxo he de dir que estic molt mal acostumat) i el que és pitjor, amb un disseny que feia que amb quedàs sense vissibilitat a les corbes d'esquerra. Per acabar-ho de rematar el volant esta disposat de tal manera que tapa el contaquilòmetres. Bé, al manco ja sé quin cotxe no compraré.

Passades les vacances es pot dir que comença un nou cicle. L'empresa per la que treball viu un procés de fusió que en aquests moments, sigui per unes raons o altres, ha degenerat en una fuga de capital humà cap a altres empreses (director general, director financer, director d'informàtica, directors regionals, etc. etc) i on la política oficial respecte a sous i possibilitats de promoció és la de no pujar l'IPC i on se'ns va dir que per promocionar el millor que es pot fer es canviar de feina cap a altres empreses (bé, al manco no es podrà dir que no es predica amb l'exemple!).

Com no podria ser menys també estic a la recerca activa de feina, per les mateixes raons que altres companys que ja han deixat l'empresa, però en el meus cas me trob que he d'entrevistar a gent per a cobrir els llocs buids.

Un és un professional i faig la feina el millor que sé i puc, mirant de trobar les millors persones per la feina entre els currículums que m'han arribat. Tot i això, des del punt de vista ètic em sent violent entrevistant gent quan jo mateix estic cercant feina, quan el futur és incert a l'empresa, quan qui entri en plantilla es trobarà a poc amb que el seu poder adquisitiu ha baixat a l'any següent i quan no m'atrevesc a recomanar la feina a amics i coneguts amb feina per por a fer-los la putada de la seva vida.

El que sí veig és que ara per ara, la majoria de gent que ens està arribant (i llevat d'alguna excepció) és gent que no s'ha molestat gens en aprendre res pel seu compte, que veu la informàtica i la programació com aquell que posa maons, que li han de dir com es fa una cosa i llavors la fan, però que no se molesten en veure si hi ha coses millors, ni tan sols s'ho plantegen. No és el tipus de perfil que m'agrada, però pareix que és el tipus de perfil que ara per ara vol canviar de feina i veu en el mercat àvid de programadors Java l'oportunitat de progressar econòmicament encara que professionalment no tengui el tarannà, l'experiència o els coneixements que haurien de tenir.

Potser, però, aquest sigui el tipus de perfil que l'empresa espanyola demana o que sigui el perfil que està disposada a pagar. L'emperò és que aquest tipus de perfil acomodatici i institucionalitzat no rendeix, no innova, no evoluciona, i si el teu negoci es basa en un component tecnològic important, com és el cas de la web, fotuts estam.

Aquests dies de vacances m'han fet reflexionar, plantejar-me el futur i decidir-me de l'espera passiva a l'espera activa, sigui amb un canvi de feina, sigui donant una empenta major al projecte d'empresa o senzillament fent de freelance si el projecte és prou interessant. El que tenc clar és que no m'agrada tenir conflictes ètics, no tenc edat.

6 comentaris, 0 trackbacks (URL) , Tags: General


Dos llibres

Escrit per Aaloy a 26 de April , 2008 a les 10:21 a.m.

Mentre esperàvem al vol de tornada vaig aprofitar per anar de compres per l'aeroport, a una llibreria com no pot ser d'altra manera :) Vet aquí el que vaig comprar:

  • Tras el incierto horizonte, de Frederik Pohl, editat per Zeta. M'agrada la ciència ficció i ja fa un bon grapat d'any vaig llegir Pórtico, així que vull provar sort amb la continuació. De Pohl llegit també "Mercaderes del espacio" i "La guerra de los mercaderes" i també m'agradaren força. Esper que aquesta novel·la, de 362 planes, estigui al nivell de les altres.

  • Sun Tzu. El Arte de la Guerra. Comentat per Tao Hanzhang, de l'editorial Bresca. Per allò que és un llibre molt citat (a el juego de Ender per exemple) i també recomanat per les escoles de negocis. En la situació actual potser un títol del tipus "El último que apague la luz" de l'editorial Melaspiro o "Maricón el último" de A. Hisus Quedais hagués estat més adient, però bé un poc de culturilla, sempre va bé.

2 comentaris, 0 trackbacks (URL) , Tags: Llibres i revistes


Alfresco Community Conference

Escrit per Aaloy a 25 de April , 2008 a les 9:37 p.m.

El dia 22 d'aquest mes vàrem assistir a l'Event d'Alfresco Community Conference a Barcelona. Per a qui no ho conegui Alfresco és un DMS (Document Management System) lliure que ha agafat molta volada darrerament, encara que és un producte molt jove.

Per anar-hi agafàrem un vol molt prest, no eren encara les set del matí, i això vol dir aixecar-se a les cinc del matí. En favor de la gent d'Alfresco he de dir que les conferències varen ser prou interessants com per a mantenir-me despert, encara que no puc prometre que se m'escapàs el cap alguna que altra vegada.

A nivell organitzatiu les conferències varen estar molt bé: la sala molt ben preparada, amb traducció simultània fins i tot i la intendència (la teca) prou bona. Sols em va quedar el dubte de perquè un recinte amb capacitat amb tanta gent té uns excusats com els que té. Mai havia anat a un lloc on els tios fessin coa per anar al bany.

Punts anecdòtics a part, he de dir que vaig sortir força content de les conferències. Vàrem veure cap a on apunten les novetats d'Alfresco i de pas també es pogué veure cap a on desenvolupa la gent. Els d'Alfresco estan deixant els JSF, segons ells fan que les aplicacions siguin molt males de mantenir, i vàrem poder veure dues aplicacions, una feta per un desenvolupador independent i una altra oficial d'Alfresco, que tenien una cosa en comú: estar desenvolupades amb Extjs. Els d'Alfresco han fent una aposta molt forta per la comunicació de l'aplicació amb json, xml, rest, webdav, etc i segons vàrem poder veure han fet que sigui força fàcil poder publicar la informació en aquests formats.

Potser sigui autoconvenciment, però la cosa és que el tema del JSF no m'ha acabat de convèncer mai. Massa enrevessat i mal de mantenir, però és el que empreses com Oracle estan recomanant per fer el canvi tecnològic de Forms cap a la web, l'excusa és que hi ha dissenyadors visuals per JSF, però em fa por que amb l'excusa de la productivitat a l'hora de pintar pantalles s'estigui optant per una tecnologia que aviat quedarà obsoleta. La gent té tendència a anar cap a coses que agumenten la productivitat, deixen fer coses i els faciliten la vida, d'aquí que bastiments com Spring i Hibernate triomfin on els EJB varen fracassar.

La gent d'Alfresco pareix que ho veu clar i que s'estima més retirar-se ara i apostar cap a una altra tecnologia més mantenible per la capa de presentació. Potser va ser una de les millors conclusions que en vaig poder treure de la conferència.

0 comentaris, 0 trackbacks (URL) , Tags: Informàtica Java


Aquest blog ja té calendari

Escrit per Aaloy a 19 de April , 2008 a les 2:16 p.m.

Una de les coses que li faltava al blog (entre d'altres) era la d'un calendari mensual on es poguessin veure els dies que hi ha apunts.

Trob que és una bona cosa que el calendari estigui a la plana principal, ja que serveix per donar una idea del ratio de publicació d'apunts al blog, i a més ens permet una navegació molt ràpida a les entrades del darrer mes.

Per posar el calendari inicialment he intentat fer servir un snippet però no m'acababa de fer el pes. A més tenia que lligar-ho amb el dia d'avui per defecte i amb el mes o dia que estigués vegent l'usuari del blog. Així que he acabat per fer el meu propi template tag. Aquest agafa una variable del tipus datetime que estigui al contexte de la plantilla i renderitza el calendari, anant a cercar si hi ha apunts en cada dia.

El tag no ha quedat molt genèric, ja que està acoblat a blog, però és prou senzill d'adaptar per fer un calendari genèric. El que m'ha duit gairebé més feina és la part d'estils. Com veureu encara queda un tant "cutre", però com que ja fa la feina, doncs a publicar-ho i ja ho aniré polint.

També vaig posar una altra xorrada l'altra dia, un gràfic que fa servir l'API de Google i que permet veure un diagrama de pastís amb la classificació d'apunts per tag. Si feis clic damunt la paraula tag ho podreu veure.

0 comentaris, 0 trackbacks (URL) , Tags: Django


Primeres modificacions al blog nou

Escrit per Aaloy a 15 de April , 2008 a les 9:11 p.m.

Link to Primeres modificacions al blog nou

Avui he fet les primeres modificacions al Blog. Ja us deia que això de posar en producció les coses et força a trobar i corregir els errors més ràpid.

M'he trobat que els RSS no funcionaven. La idea era mantenir la compatibilitat amb els RSS de Wordpress, de tal manera que els vells subscriptors no notassin el canvi, però me vaig deixar una s i no anaven. El canvi ha esta molt senzill, però ha sigut cosa d'esperar a arribar a casa per fer les modificacions.

De pas he aprofitat per arreglar quatre etiquetes que no estaven ben posades i posar una validació als comentaris de manera que "peti" en posar un comentari buid. La part de comentaris és potser el que menys m'agrada, ja que encara fa servir les llibreries de oldforms de Django i jo ja estic molt acostumat a les noves. El canvi de oldforms a newforms serà de les primeres coses que vull fer. El que em frena un poc és la part de control de l'spam, però miraré si puc fer servir algun component per a connectar amb l'Akismet i fer-ne el backoffice per a controlar-ho.

De les coses que més m'agraden del nou programa és la possibilitat de fer servir el Markdown per a escriure els posts. Al Wordpress segurament se deu poder fer alguna cosa per l'estil, però no m'hi he volgut barallar mai. Vaig posar també javascript per a colorejar codi Python, així que ara veureu que els articles que tenguin codi quedaran un poc millor presentats.

0 comentaris, 0 trackbacks (URL) , Tags: Python Django


Powered by Django

Escrit per Aaloy a 14 de April , 2008 a les 9:24 p.m.

Link to Powered by Django

Un dels propòsits del 2008 pareix que ja s'ha complert. Gràcies a Bernat avui hem canviat el blog vei en wordpress que quedarà a blog.trespams.com, més que res per si alguna cosa anàs malament mentre es fa el canvi.

El nou blog està en fase beta, però seguint els principis del la programació àgil, he preferit posar-ho en producció i anar polint els detalls que queden. Com podeu veure pel titol el blog és Django powered. Corre damunt un servidor dedicat que tenim per APSL dins un entorn chroot que en Bernat ha montat.

El codi font del blog està disponible al repositori de google code, com a una branca amb suport unicode del blogmaker, així que tothom és benvingut a col·laborar-hi i a posar-hi tickets pels errors que segurament hi trobareu.

Al codi font també hi ha l'importador de Wordpress cap al blog, de manera que veureu que els articles de l'antic lloc, comentaris i trackback estan inclosos en el nou. La importació no ha estat massa complexa i s'ha fet a partir de l'exportación en format RSS que fa el Wordpress. Tot i això hi ha petites millores a fer, com les de tractar millor els paràgrafs. Alguns articles encara no han passat per la modificació i les lletres es veuen molt atapides, fruit de la combinació de l'importado i de la fulla d'estils que he fet servir per a contruir el lloc, el multiflex.

Encara queden cosetes a polir, veig que m'he deixat el peu del "powered by django" per exemple, la part d'agraïments, etc. etc. que aniré posant durant els propers dies i setmanes. El d'avui és una beta, gairebé alfa, però com us dic, crec que l'important és perdre la por i posar-ho en producció i anar-ho millorant dia a dia.

6 comentaris, 0 trackbacks (URL) , Tags: Python Django


Python for Scientists

Escrit per Aaloy a 13 de April , 2008 a les 12:49 p.m.

L'altra dia a la llista de Python announce vaig veure que hi havia una comunicació de P.Raybaut on deia que havia llançat el Python (x,y), una distribució de Python orientada al món científic.

A mi, pel meu passat en això del càlcul numèric i científic,per mor de un bon grapat d'assignatures de càlcul numèric de Físiques, la idea m'agrada molt i es d'agrair l'esforç que ha fet aquest senyor per triar i integrar un bon grapat d'eines que de ben segur ajudaran a la gent que tengui que fer càlculs numèrics i manipulació de dades.

A part de que hom faci servir la distribució o no (està força orientada al món Windows per exemple), el que és també interessant és veure la selecció de llibreries i programes que s'ha fet. Permet fer des de processament de senyals amb SciPy a manipulació del port paral·lel o sèrie per l'entrada de dades, sense oblidar que inclou la integració del dissenyador de les Qt i les PyQt mateixes.

En Ricardo al seu blog apuntava que havia canviat la introducció a Perl per una introducció a Python i Django. Potser l'aparició de paquets com Python (x,y) servirà per a que el càlcul numèric sigui molt més amè per les noves generacions de físics, matemàtics i estadístics. En el món de la física el FORTRAN és el rei del càlcul numèric encara, però amb eines com aquest la cosa pot anar canviant. Si més no la combinació de Python i interfícies cap a llibreries FORTRAN pot donar-nos el millor d'ambdós mons, amb permís, això sí, de projectes com Parallel Python, del qual esper poder parlar-ne un altra dia.

0 comentaris, 0 trackbacks (URL)


Ja tenim el compte d’Appengine

Escrit per Aaloy a 11 de April , 2008 a les 11:37 p.m.

Doncs això, fa poques hores he rebut el missatge que diu que ja puc fer coses amb l'Appengine de Google, en morenosan en va dir ahir que havia rebut també el seu, així que pareix que estan obrint el grifó bastant de pressa.

Ara es cosa d'anar pensant què es pot fer. De totes maneres no es tant l'aplicació en sí, com poder provar l'entorn i començar a veure les seves possibilitats, com s'hi fa feina, quines diferències hi ha entre poder fer l'ORM de Google i el de Django, veure les limitacions que ens imposa...

Temps al temps!

1 comentari, 0 trackbacks (URL) , Tags: Python Django


El millor IDE per Python i Django

Escrit per Aaloy a 10 de April , 2008 a les 10:28 p.m.

Amb tot el rebumbori del llançament de l'appengine supòs que aviat tendrem una munió de gent demanant-se quin IDE és el millor per desenvolupar en Python i Django, peticions de recomanacions, etc. Vull tractar d'adelantar-me a les peticions, així que us diré quin es per mi el millor entorn de desenvolupament per Python i Django: es diu Gnu-Linux i dues pantalles panoràmiques de 20".

Python és un llenguatge interpretat que et permet fer proves molt ràpidament, sovint el que fas es obrir una consola (recomanació mirau IPython com a consola) i començar a provar les idees que tens. Va molt bé per provar la sintaxi, fer petites proves, depurar, etc). Per tant el que necessitam és un entorn que ens permeti tenir un sistema de consoles potent on sigui fàcil llançar l'intèrpret i tener tantes consoles com volguem. Aquí els Linux sobresurten i veureu que es una eina molt potent de programació.

Si a més hi posam Django ens trobam que necessitam llançar el servidor i veure'n les traces així que necessitam una consola addicional que és convenient que estigui visible mentre anam fent els canvis i les proves. Per aquí ja podeu veure el perquè dels dos monitors de vint polzades. Així en una pantalla podem tenir l'editor que facem servir (ara hi aniré a això) i a l'altra podem tenir la consola del servidor, el navegador i alguna consola addicional per anar culetjant.

Del navegador supòs que no farà falta dir que per desenvolupar res millor que el Firefox amb les extensions del Firebug i el Web Developer, veritat?

Passem doncs a l'editor. Personalment l'elecció de l'editor té a veure amb l'ús que n'he de fer a la sessió de treball. Si la previsió és que desenvoluparé una bon grapat d'hores faig servir Eclipse amb el plugin PyDev a la pantalla d'edició, l'altra com us dic, queda reservada pel navegador i la consola de Django. Si sols he de fer petites modificacions o vull provar alguna cosa l'elecció principal és el vim i sovint faig servir el Kate, ja que té un afegitó que permet executar, sí ho heu adivinat, una consola.

Idependentment de l'editor que a cada un li vagi millor, és molt útil manejar-se mínimament amb el vi/vim, ja que ens permetrà fer modificacions ràpides als servidors de producció, modificacions que s'hauran d'integra dins el sistema de control de versions (SCM), que tot val a dir-ho és imprescindible i ha de formar part del nostre entorn de desenvolupament. L'elecció del sistema de control de codi depèn també de les preferències personals de cada un, però per començar no és una mala elecció anar cap el subversion, ja que hi ha interfícies gràfiques força ben fetes que ens ajudaran en la tasca, un parell de plugins d'eclipse i una linea de comandaments prou potent que ens permetran treballar amb el sistema de control de versions sigui quina sigui la nostra elecció d'editor, tanmateix sols es cosa d'obrir una consola.

El millor IDE per mi no és un programa, és la combinació de programari, maquinari i millors pràctiques que fan que la nostra experiència de programació en Python i Django sigui productiva i divertida, sense perdre mai de vista la potència que ens dona la línia de comandes. Si en el teu projecte Python depens de les facilitats que te dona un editor determinat per a escriure codi, segur que estàs fent quelcom malament.

0 comentaris, 0 trackbacks (URL)


Bons temps per Python

Escrit per Aaloy a 09 de April , 2008 a les 12:03 a.m.

La blogosfera en va plena Google ha llançat el seu appengine , un servei que permet hostejar aplicacions de fins a 500 Mb d'espai i 5 milions de visites mensuals que Google ha llançat i que té com a llenguatge vehicular el Python.

Per a accedir-hi un s'ha d'apuntar a la llista d'espera, ja que pareix que els comptes en fase beta s'han esgotat, i tot i les limitacions del sistema en el que fa referència als accessos als sistemes de fitxers, limitacions de la part de base de dades, que no es puguin llançar subprocessos i coses per l'estil, obre la possibilitat a tot un ventall d'aplicacions web.

On la notícia ha impactat més és a la comunitat Python: un llançament espectacular de Google, amb Guido pel mig, am Python com a protagonista i amb Django com a estrella convidada, ja que Django, encara que la versió "estable", ve de sèrie en el sistema.

Si encara no ho heu fet és un bon moment per aprendre Python i Django (ueps, tal volta seria un bon moment per publicitar-ne cursos :-P ) ja que un dels emperòs més grans que hi havia és que no se disposava d'un servidor a preus assequibles on poder fer anar les aplicacions. Ara amb el llançament de Google, les possibilitats de fer desenvolupaments amb Python i Django es multipliquen, limitats a les possibilitats de l'entorn que proporciona Google, sí, però permetran en breu començar a fer aplicacions web i hostetjar-les a un preu inmillorable.

Amb això esper a més que els hostingaires de sempre es posin les piles i donin a preus raonables allotjament per Django, proporcionant a més el servei que ara Google no ofereix: el de tenir una base de dades relacional pròpia al darrera.

I és que un dels grans problemes de l'oferta de Google és que no ets ben bé l'amo de la teva base de dades i algunes coses que permet fer l'ORM de Django molt fàcilment a l'ORM substitutiu de Google no es poden fer.

És clar que no totes les aplicacions necessiten d'una base de dades relacional al darrera, així que l'appengine de Google és per una part un bon banc de proves per veure com va això de la programació web amb Python i Django i per una altra una manera ràpida i econòmica de posar en producció projectes web que d'altra manera tendrien un cost prohibitiu pel programador mig.

2 comentaris, 3 trackbacks (URL) , Tags: Informàtica Python Django


onAIR2008

Escrit per Aaloy a 02 de April , 2008 a les 7:49 p.m.

El dilluns vaig anar a la presentació de l'onairtour d'Adobe, on es presentava la tecnologia air i flex mitjançant un bon grapat de conferències.

L'organització va estar força bé, el comentari que ho resumeix seria el de "he estado en bodas peores" (en madrileny a l'original), ja que cada dues conferències hi havia sessió de tapeo.

De la part tecnològica doncs un sabor agredolç. Per una part una tecnologia que no saps ben bé si és oberta o tancada, si serà realment multiplataforma de bon de veres o sols lligada a uns sistemes operatius concrets, i per l'altra tens el veure que per certes aplicacions el que es presentava tenia moltes possibilitats.

La idea en sí és bona i crec que Adobe ha fet un bon ús de les possibilitats de webkit. El problema és que ja sabem com les gasta aquesta empresa i jo sóc un bon exemple, ja que no hi ha visor de flash per Linux PPC, així que per molt interessant que em paregui la tecnologia ara per ara ni és del tot lliure ni és totalment multiplataforma.

Per una altra banda, les APIs pel que digueren encara estan força verdes, amb molts canvis d'una versió a un altre.

La idea d'Adobe és que la gent pugui aprofitar els seus coneixements de Javascript per fer aplicacions d'escriptori i fins i tot fer aplicacions que puguin fer feina desconectats de la web i això mateix és el que pretén també Google amb Gears, així que ens esperen temps interessant en aquesta tecnologia.

El problema que hi veig en tot això és que s'està tornant a reinventant la roda. Ara el cool és fer aplicacions d'escriptori programant amb Javascript. Què voleu que us digui, si tenc que fer una aplicació d'escriptori multiplataforma ara per ara pegaré a Python i les pyQt o les wx. Si a més la vull per web, doncs ja n'hem de parlar un poc més, però no crec que l'objectiu final sigui fer aplicacions client-servidor en Javascript.

Aquest tipus de tecnologia segur que té grans avantatges si la teva aplicació ha de permetre't poder fer feina desconnectat de la web. L'emperò és que cada vegada la gent viu connectada i no desconnectada, de manera que la necessitat de tecnologies d'aquest estil cada vegada serà menor.

L'altra "novetat" és que air ens permetrà accedir directament a la màquina de l'usuari, se suposa que amb totes les precaucions (signat de certificats - pagant clar). Coneixent l'usuari mig, que no llegeix els diàlegs i es limita al "siguiente-siguiente", doncs supòs que d'aquí poquet podrem veure els primers virus escrits en javascript per air.

En definitiva, una presentació molt bona, una organització excel·lent, unes cadires que te deixaven el cul que no sabies si era teu i una tecnologia que t