Un dels problemes que té el manteniment de una plana web dedicada a la física, matemàtiques o altres ciències, és com escriure i mantenir les fórmules i que quedi bé la cosa.

Per escriure fórmules res com el TEX o el LaTeX, que encara que hi hagi gent que digui que fent clic amb el ratolí va millor, quan un ha d'escriure moltes fórmules, numerar-les i mantenir-les no hi ha res com el poder teclejar. La gent d'OpenOffice manté un editor de fórmules per línia de comandes i curiosament els seus detractors diuen que és una mancança. Jo ho veig com un avantatge i una utilitat per gent que realment pica moltes fórmules o fórmules complexes dins el document.

Quan parlam de texts amb un fort component matemàtic i de fórmules a les planes web la cosa encara es complica més. Tradicionalment per representar fórmules complicades s'optava per scripts de conversió de TEX cap a imatges, amb una qualitat que la majoria de vegades era molt pobre i amb una integració amb la plana no massa encertada.

Hi ha però una alternativa molt bona, el jsMath que utiltizant javascript ens permet mostrar dins les nostres planes HTML fórmules amb qualitat professional.

He estat mirant els exemples i jugant amb l'editor interactiu de jsMath:

És una imatge i la qualitat no és ni la meitat de bona que la que s'aconsegueix amb el javascript, com podreu comprovar si anau al la plana de jsMath i en visualitzau els exemples.

Una de les coses que fa Django potent com a bastiment és la seva extensibilitat, és força senzill extendre el llenguatge de plantilles amb nous filtres i nous tags.

Avui tenia la necessitat de generar un nombre aleatori, semblant a l'exemple d'Ajax d'un post anterior, pero aquesta vegada volia que no fos necessari cridar a cap vista.

Això seria molt senzill de fer passant el valor com a paràmetre, però pot servir com un exemple més de com crear els nostres propis tags.

Crear un tag en Django requereix de dues passes: crear la funció de compilació i crear la classe que renderitzarà el trag mostrant el text que volem.

Una vegada fet això basta registrar el tag i per això el mateix Django ja ens facilita un decorador.

La randomCode és la que agafa el tag i els paràmetres del tag i en far el parseig. En aquest punt hem de caçar els errors de sintaxi del tag i informar a l'usuari de com es fa server.

La classe randomCodeNode agafa el valor que li passa la funció anterior i fa les operacions necessàries per a tonar-nos una cadena de text presentable en una plana web.

L'esquelet ens pot servir com a base de tags molt més complexos, per exemple tags que incloguin automàticament llibreries javascript , o que facin més senzilla la seva utilització, ...

Per fer servir aquest tag n'haurem de carregar l'arxiu dins la nostra plantilla, com en el cas del filtres això se fa amb un {% load arx %} on arx és el nom de l'arxiu que conté el tag que acabam de crear.

   from django import template
   import string
   import random
   CODE_CHARS = string.ascii_uppercase+string.digitsregister = template.Library()

@register.tag(name="randomCode")

def randomCode(parser, token):
    try:
       # split_contents() knows not to split quoted strings.
       tag_name, num = token.split_contents()
    except ValueError:
       raise template.TemplateSyntaxError, "%r tag requires an integer as a single argument" % token.contents.split()[0]
    if not (num[0] == num[-1] and num[0] in ('"', "'")):
       raise template.TemplateSyntaxError, "%r tag's argument should be in quotes and be a positive integer" % tag_name
    try:
       value = int(num[1:-1])
       if value <0:
           raise template.TemplateSyntaxError, "%r tag's argument must be a positive integer"
    except:
       raise template.TemplateSyntaxError, "%r tag's argument must be a positive integer" % tag_name
    return randomCodeNode(value)

class randomCodeNode(template.Node):    def init(self, num):
       self.num = num
       def render(self, context):
       try:
           codi = random.sample(CODE_CHARS,self.num)
       except ValueError, e:
           raise template.TemplateSyntaxError, "tag's argument must be a lower than %i" % len(CODE_CHARS)
       s = ''
       return s.join(codi)

El Wordpress no és gaire bo amb el codi, podeu trobar-ho millor colorejat a Djangosnippets

N'Enrique Dans es demana a un article ¿Alguien ha visto un programador? i en Ricardo Gali li diu que yo he vistos unos pocos. Particularment he de dir que jo sí que n'he vists de programadors i de bons, però com tot el que és excepcional un bé escàs i en el cas dels programadors he d'afegir que és un bé poc valorat.

A l'article d'Enrique Dans ens diu que el desenvolupament tecnològic d'Espanya s'està alentint perquè no hi ha bons programadors de PHP, Java, Python, Perl o RoR per a dur a terme els projectes d'Internet. Ho sento, no hi puc estar d'acord, els projectes d'Internet a més de pels programes i els programadors tenen un factor limitador que és el cost del hosting i de l'ampla de banda. Si comparam el que costa hostejar un projecte ambiciós a Espanya i ho comparam amb el que costa fer-ho a altres indrets veurem que el programador Espanyol ja no es planteja desenvolupar perquè tanmateix ja sap que les seves possibilitats de créixer són molt limitades, ja que ben aviat els costs pujaran per damunt dels guanys.

L'ampla de banda de les connexions domèstiques tampoc ajuda, la velocitat de pujada de les connexions ADSL fa rialles i el cost de més velocitat és prohibitiu. Sempre ens queda la solució de fer el hosting a països més barats, però això ja està penalitzant la velocitat d'accés si el negoci ho vols fer per començar al mercat Espanyol i perds el control que te donaria tenir els programes al teu propi datacenter, encara que aquest pugui ser tan petit com un servidor o dos col·locat al destpatx de casa. En aquest moments i amb les connexions actuals l'inversió necessària per tenir un grapat de servidors dedicats amb prou ampla de banda a Espanya, fa que els costs fixes siguin tan alts que cal pensar-s'ho molt a l'hora de montar un negoci tecnològic a l'estil del que ens tenen acostumats emprenedors americans.

Així doncs, l'endarreriment en noves tecnologies no és tant per l'absència de bons programadors, sinó que tot el teixit tecnològic que hi ha a la nostra societat o l'absència del mateix, fa que encara que aquests hi siguin, no es donin les condicions per a que prosperin. Empreses poc donades a la innovació, departaments d'I+D+I inexistents, costs de les comunicacions prohibitius, empreses que donen més importància a les aparences, a l'estar que al fer i una gran mancança de cultura informàtica en el que fa al desenvolupament de programari i a la gestió d'equips tècnics són tant o més responsables de l'endarreriment que patim.

Per una altra banda quan parlam de noves tecnologies al perfil del bon programador, del tècnic se li ha d'afegir la de la capacitat de treball en equip. Avui en dia i en projectes d'Internet és impensable dur a terme alguna cosa mitjanament grossa sense la col·laboració de programadors, dissenyadors i tècnics de sistemes. Trobar perfils compatibles ajuda moltíssim (de 3 a 10 vegades) al projecte i augmenta les possibilitat d'èxit, i això xoca amb processos de selecció basats en la força bruta, és a dir, en un "pongame aquí 20 tios que ...", el nombre no és tan important com la capacitat d'autocoordinació, la iniciativa i la capacitat tant individual com del conjunt.

Potser falten bons programadors, però també falten i molt empreses que vulguin bons programadors, fins i tot empreses que vulguin un equip de bons programadors i que entenguin el perquè una vegada un equip s'ha format i funciona s'ha d'intentar mantenir i evolucionar.

La tecnologia i el programari s'ha convertit en una part fonamental de les empreses, però la figura del programador enlloc d'estar cuidada està denostada. Els cursos per fascicles de "programar es fácil" no han ajudat gens a la valoració de la professió. La capacitat de fer mals programes és infinita, la capacitat de fer-los bé està sols a l'abast de la gent amb passió per la seva professió, una passió que el motiva i que el duu cada dia a superar-se, a fer millor les coses, a aprendre.

Sovint però el que trobam és el programador que programa per menjar. És l'antítesi del tipus de gent que fa que les tecnologies de la informació passin de les idees als fets. Programar per menjar implica dedicar-se a programar sols perquè és una feina on no et banyes quan plou, on un fa el que toca i fins a on li han dit i res més, sense plantejar-se si se podria fer millor, sense cercar avançar sinó tot el contrari, procurant que la feina que fa duri molt per tal de no haver d'aprendre coses noves.

Els programadors dels que parlen Enrique i Ricardo no programen per menjar, programen per viure. L'aspecte econòmic és important per viure però encara que tinguéssin que dedicar-se a altres feines per subsistir programarien.

Un bon programador ha de ser també inconformista, crític i perquè no un tant freaky. Crec que tot va lligat, l'inconformisme ens duu a cercar altres maneres de fer les coses, a pensar alternatives. El pensament crític ens ajuda a millorar i el freakisme ens fa part d'un club selecte, forma lligams i fa equip.

Bons programadors? En conec un grapat, però on són les empreses que tenen les condicions per a que aquests desenvolupin tot el seu potencial?

Bé, no són exactament 10, però si 9.800.000 llargs de registres que hi tenim a una taula d'una base de dades Postgresql que en el seu conjunt pot tenir fàcilment quatre o cinc vegades aquesta quantitat de registres. I el motor de BD ho mou tot sense despentinar-se, sense requerir complicats tunnings de bases de dades i amb uns temps de resposta a les consultes que es mesuren en milisegons.

No vull ni imaginar el maquinari, el cost en llicències i en administració que requeriria moure això fent servir bases de dades privatives.

La millor manera de desfer FUD és veure que a ca un altre funciona.

Seguint la línia d'assajos com "How to write unmaintainable code" o el refuctoring, ens arriba un assaig que revolucionarà la vostra manera d'entendre la programació: l'abject-oriented programming.

En el seu assaig Greg Jorgensen introdueix novetosos conceptes que sovint ens hem trobat en el codi, com les fragile base class, aquella classe o mòdul, que fa molt de temps que està a l'aplicació i que qualsevol canvi que s'hi faci romprà tota l'aplicació.

Interessantíssima també la seva recomanació pel control de versions, encara que he de dir que hi ha molt "previous art", l'he vista aplicada nombroses vegades en tota mena de documents word i fulles de càlcul.

En definitiva, un entreteniment estiuenc per passar l'estona.

http://typicalprogrammer.com/programming/abject-oriented/

A casa faig servir el Kdevelop, vi o Kate per programar amb Python. L'Eclipse per PPC em dona massa problemes i va massa lent com per a ser una eina pràctica, així que m'he avesat a fer moltes coses que faig amb l'Eclipse de manera menys integrada, és a dir, a maneta i amb línia de comandes.

Una d'aquestes coses és el subversion. Encara que hi ha força clients gràfics per subversions cap s'atraca als que proporcionen els plugins d'Eclipse, així que m'he acostumat a fer les operacions habituals en línia de comandes aprofitant la shell que tenen tant Kate, com Kdevelop. Les comandes més habituals que faig servir són:

• svn ci Em permet pujar els canvis
• svn update Baixar-me els canvis que han fet els companys
• svn add <arxiu> Afegeix un arxiu al control de versions
• svn status em permet veure es canvis pendents

La cosa està en que el subversion no suposa res respecte als arxius amb els qui fas feina. Per defecte no posa l'arxiu sota control de versions a no ser que tu li diguis. Així la combinacióde svn status i svn add és força habitual quan es tracta de pujar els canvis que hem fet. Amb svn status podem veure el que s'ha modificat i al llistat que ens proporciona marca amb interrogants aquells arxius que encara no s'han afegit al control de versions, per exemple:

?      apslweb/www/__init__.pyc
?      apslweb/www/logger.pyc
?      apslweb/www/models.pyc
M      apslweb/db

Com que els arxius de compilació no ens interessa posar-los a subversions resulta que la comanda svn status ens està mostrant molt de renou, per a evitar-ho subversion ens permet ignorar els arxius que nosaltres li diguem d'un directori, en el nostre cas, desde apslweb si feim

svn propedit svn:ignore www

Ens apareixerà un editor (el vim en el meu cas) que ens permetrà afegir-hi els arxius que volem que no apareguin al llistat de l'status, afegint *.pyc ja ho tenim.