Formació interna en Python i Django

Escrit per Aaloy a 30 de September , 2008 a les 9:15 p.m.

L'altra dia una persona es va posar en contacte amb mi per a veure si li podia ajudar en un projecte, que resultà ser un deathmarch en tota regla.

La cosa és que l'home es queixava de que no trobava gent formada en Python i Django. Normal, la gent formada està fent feina i la tecnologia és prou nova com per a que encara sols la gent amb més inquietuds informàtiques hi estigui aficada.

Personalment crec que és part de la responsabilitat de l'empresa la de formar els seus treballadors, i la d'aquests aprofitar les formacions obviament. Per una empresa l'objectiu fonamental seria el de tenir treballadors capaços de autoformar-se, d'aprendre noves tecnologies ràpidament. Després de tot la tecnologia, especialment la tecnologia web, avança a un ritme tant alt que l'expert d'avui es pot convertir en l'inútil del futur.

En els darrers mesos he estat donant cursos de formació interns amb Python i Django a la gent que desenvoluparà tres dels propers projectes web. Gent que es reciclarà d'altres tecnologies i que té com a denominador comú les ganes i la capacitat d'aprendre.

De l'experiència actual n'he tret dues conclusions que vull compartir amb vosaltres:

La formació de 30 hores en Python i Django no és suficient. Em varen quedar molts punts que m'agradaria haver tractat. Tot i això crec que orientar la formació en vàries tandes en lloc de fer maratons seguits permet a la gent assimilar millor els coneixements i donar temps a la gent per a que pugui investigar i anar ampliant coneixements pel seu compte.

El seguiment és fonamental. El mentoring és una tècnica molt eficaç per assolir i transmetre coneixements i és quelcom que no he vist contemplat mai en cap dels cursos que he m'han donat. Les empreses pareix que suposen que una vegada donat el curs l'alumne ja pot volar sol, i realment no és així. El seguiment posterior, l'anar polint imperfeccions, la de fer petits monogràfics dins un projecte concret és una tècnica que personalment m'ha donat molts bons resultats en el passat i crec que aquesta no en serà una excepció. Això si, un acaba molt cansat quan els components de l'equip estan enfora (antiproductiu? sí, no us diré que no, però ja sabeu la dita del català antic, "donde hay patrón...")

La cosa està doncs que la gent comença a ser prou productiva com per fer avançar el projecte, i que tenir un projecte on pot començar des de zero, els ajudarà a fixar coneixements, no tan sols de programació, sinó de la manera pythònica de fer les coses.

Una vegada acabat el projecte sols em quedarà anar a Ca'n Paco i comprar-me unes sabates noves, hauré de passar el ticket a l'empresa :-P

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

En text pla per favor

Escrit per Aaloy a 28 de September , 2008 a les 9:16 p.m.

Ho he de reconèixer, tothom té els seus tics i un dels meus és la meva dèria per escriure ten text pla. Quan he d'obrir un editor de texts normals em fa molta peresa. Tot i conèixer com posar una negreta o una cursiva fent servir combinacions de tecles em pareix molt més natural escriure amb un editor com vim o Kate o en les vegades que he de fer servir Windows el notepad++.

Es pot dir que "vaig veure la llum" quan vaig tenir que escriure el meu primer document de més de 100 planes ple de taules i imatges incrustades. Aleshores el Word era la única opció i va ser un vertader malson fins que ho vaig enviar a fer punyetes i vaig decidir escriure el document fent servir LaTeX. Vaig poder dormir molt millor!

Després vaig descobrir les meravelles del RestructuredText per a escriure documents tècnics i la simplicitat de la sintaxis dels wikis. Pels apunts al blog m'he passat directament al Markdown.

El text pla ens permet llegir els nostres documents en qualsevol editor, transformar-los en diferents formats, posar-los sota un control de versions i veure'n les diferències des de la web o des de el nostre client preferint de subversion.

Com tot en aquesta vida no hi ha res perfecte, hi cada cosa hi té el seu lloc:

• LaTex: per documents llargs, i/o que necessiten d'una presentació final amb molta qualitat.
• RestructuredTex : per a la documentació tècnica que no necessita tenir una presentació final tan polida com la del document LaTex.
• Markdown per aquest blog.
• wiki per la documentació compartida al mediawiki o al trac.

De tots aquests formats el LaTeX potser sia que costa més d'aprendre al principi i que té un marcat que dificulta un tant la lectura del text. Els altres llenguatges de marcat estan pensat per a ser bons de llegir i d'interpretar semànticament amb tant sols obrir-los a l'editor.

Quan veig gent que duu el control de versions amb un document Word anomenat document_v1.0.293b.doc deixat a al carpeta v1 del directori documents o coses semblants no puc deixar de pensar en com se complica la vida la gent amb tal de no aprendre res nou. La d'hores que s'hauran perdut mirant si el document que tenen en les mans és la versió final o per veure les diferències entre una versió i una altra (òbviament lo del control de versions dels documents, per a què!).

La informació cada cop circula menys en paper i més en format electrònic, potser seria hora que les empreses es plantegessin si una manera d'estalviar temps i recursos seria la d'ensenyar als empleats a fer anar un control de versions, a passar d'un document tipus Rest a un Pdf, a que les darreres versions dels documents són les que hi ha al subversion. La majoria dels documents que circulen per les empreses són de consum intern i sols necessiten ser llegits i entesos, assegurant que la informació que contenen està actualitzada, cosa molt més fàcil d'aconseguir amb documents de text pla.

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

La zona

Escrit per Aaloy a 19 de September , 2008 a les 9:20 p.m.

Estar en la zona és estar en el nirvana de la programació, a l'estat mental en que les idees passen a línies de codi, on els dits es mouen pel teclat en un flux constant i quasi hipnòtic.

Estar a la zona no és fàcil però sortir-ne sí. Estar a la zona enganxa, de manera que una sortida de la zona sobtada sovint va seguida d'uns minuts de mala llet, dirigida contra el responsable d'haver pertorbat l'estat mental per excel·lència del programador.

Aconseguir l'estat mental adequat per entrar a la zona és una qüestió molt personal de cada programador, però ho podríem comparar amb els rituals de fan els esportistes abans de sortir a competir. Entrar a la zona significa complir amb un ritual, amb una lletania que ens ajuda a aconseguir les condicions de partida que ens han de dur al flux, a la zona. Per un és no tenir papers a la taula, per altres tenir la taula plena de papers, altres han de disposar totes les icones de l'escriptori d'una determinada manera, altres obrim les consoles que necessitarem abans de començar i les distribuïm entre els escriptoris de manera que ho tenguem tot distribuït tal com ens agrada, tal com ens va bé.

Quan un està a la zona el temps passa més aviat, a la darrera compilació li segueix una altra darrera compilació i així successivament, qui està a la zona se'n resisteix a sortir-ne i inconscientment voldria que l'estat de beatitud que es té duràs un poc més. Ja hi haurà temps per anar a dinar, "un moment que ara acab això...", "gairebé ja ho tenc,", frases típiques que a ben segur us haureu trobat dient-vos a vosaltres mateixos o a un tercer.

Per entrar a la zona s'han de donar les condicions adequades, l'ambient de treball hi influeix molt. Si hi ha interrupcions cada pocs minuts normalment ja ni s'intenta entrar a la zona, ja que sortir-ne una vegada hi has entrat és un petit trauma i les persones intentam evitar les experiències negatives.

Per això es recomana que els programadors tenguin els seus propis despatxos evitant telefonades, interrupcions i reunions innecessàries. L'estat mental productiu per a un desenvolupador és el de la zona, és l'estat que el motiva a anar a fer feina cada matí, és una llàstima veure departaments de programació "diàfans" amb telèfons sonant per tot, fins i tot n'he vist que a més de no tenir paret i despatxos estaven aferrats a la cafeteria.

La productivitat en el món de la programació passa per donar a la gent les condicions òptimes per fer feina. L'estructura organitzativa hauria d'estar orientada a que la gent que fa desenvolupament pogués fer-ho amb tranquilitat, gaudint de la seva estada a la zona. Potser per això la majoria gaudim més de la programació a casa que a l'oficina, a casa és més fàcil accedir a la zona i menys complicat mantenir-s'hi.

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

Llista de llenguatges de programació que conec

Escrit per Aaloy a 09 de September , 2008 a les 8:40 p.m.

En Corey Goldberg escriu al seu blog damunt la llista de llenguatges de programació que coneix, amb la qual cosa ha iniciat un memme? ;)

La cosa està en llistar els llenguatges de programació en el que un se n'ha desfet en un moment o altre de la seva vida. És a dir, no val dir que un coneix el llenguatge Petito si no ha passat de "hello world".

En el meu cas i per ordre cronològic

• GW-BASIC
• Turbo Basic/Quick Basic
• Assembler 8086
• Shell
• FORTRAN
• Pascal
• Icon
• Matlab
• Modula 2
• Object Pascal (Delphi)
• SQL
• Python
• Forté
• C
• VbScript
• Java
• Javascript

Ja no es podríen classificar com d'haver fet res seriós:

• Fast (un llenguatge que generava .com especialitzat en fer jocs).
• Lisp
• C++
• Groovy
• Ruby
• C#

El Deplhi és un dels llenguatges que més he disfrutat de programar, però em vaig cansar de les tonteries de Borland i vaig trobar Python, quina gran troballa! Des d'aleshores no l'he deixat mai al Python, encara que altres llenguatges també s'han anant fent el seu lloc, el Python sempre ha estat en primera línia, encara que fos per generar codi per altres llenguatges.

1 comentari, 0 trackbacks (URL) , Tags: Informàtica Python

Avaluació pererosa a Python: un exemple amb Django

Escrit per Aaloy a 04 de September , 2008 a les 3:16 p.m.

Aprofitant que tenc vacances (eps! una setmana i ja s'acaben) aprofitaré per comentar un codi que serveix tant per entendre un poc més Python com per fer feina amb Django. La idea és del blog themorge.org

class PersonForm(ModelForm):
       "Simple form for the Person model"
       class Meta:
           model = Person

def edit(request,id=None):
       """Edits the Person model"""
       formulario = PersonForm(request.POST or None, 
                    instance = id and Person.objects.get(id = id) )
       if request.method == 'POST':
           if formulario.is_valid():
               persona = formulario.save()
               return HttpResponseRedirect('/fitxa/guardada/%s/'%persona.id)
       return render_to_response('edit.html', {'formulario': formulario})
   

Això representa un formulari d'edició amb Django (versió trunk). Tenim definit als models de l'aplicació una classe Person i el que volem és crear un formulari d'edició a partir d'aquest model.

A la classe PersonForm podem veure com hem creat el formulari a partir de la definició del model. Podem personalitzar el formulari afegint-hi validacions específiques, canviar la manera que s'edita etc, però si volem una cosa bruta i ràpida amb quatre línies en sortim (sí, la documentació sí és necessària).

Definim ara la part d'edició en sí, en el meu cas l'he anomenada edit, i fa referència a una plantilla edit.html, que bàsicament conté

       <form action="." method="post">
           <table>
               {{formulario}}
           </table>
           <button name="submit" value="submit"  type="submit">Send</button>
           <button name="reset" value="reset" type="reset">Reset</button>
       </form>
   

L'embolcall de l'html ho deixo com a exercici pel lector.

Anem a veure què passa quan a través de la url anam a parar a l'edit. Tenim dos casos possibles inicialment, que vulguem afegir un mou registre o que en volguem modificar-ne un ja existent. En el primer cas se'ns ha de mostrar un formulari en blanc, i en el segon un formulari amb les dades omplertes del l'objecte Persona agafat de la base de dades per l'ORM de Django.

Els urls que jo he definit són

     (r'^edit/(?P\d+)/$','edit'),
     (r'^add/$','edit'),

Com veim hi ha dues urls que apunten al mètode edit, la primera agafa l'id com a paràmetre, per la qual coses les urls serien de la forma /edit/10/ i la segona no agafa cap paràmetre i per tant queda com /add/. De fet podríem no haver fet la distinció entre edit i add, però si la feim el codi html ens quedarà molt més bo de llegir, més semàntic.

Estudiem el cas add. Quan entrem al mètode edit, com que no li passam l'id agafarà el valor per defecte, a saber None ja que així ho me definit al mètode, i ara comença la part interessant...

Definim un objecte de tipus PersonForm, la inicialització de la classe agafa dos paràmetres, el primer són els valors inicials del formulari i el segon és la instància de la classe que volem modificar.

Quan seleccionam editar un registre o afegir-ne un de nou, el que feim és un GET i quan guardam el registre hem definit al nostre codi HTML que el que farem és un POST.

Així doncs, ara hem fet un GET. L'operador or en Python funciona de la següent manera: x or y primer avalua x, si x és vertader retorna x i si no avalua y i retorna el resultat. Fixem-nos que deim que és una avaluació pererosa perquè si x dóna vertader, y mai s'arribarà a avaluar. Com que hem fet un GET la primera expressió és False i n'avaluarà la segona, amb la qual cosa obtenim un preciós None com a resultat de la inicialització de valors.

Anem ara a la segon part, la que ens defineix la instància, en aquest cas tenim un and. L'and funciona de la següent manera: x and y primer avalua x si x és fals llavors retorna el seu valor i si no s'avalua y i es retorna el seu valor. En el cas doncs de que x sigui fals ja no s'avaluarà y.

En el nostre cas hem passat el valor id=None llavors ja no itentarà ni crear una instància de l'objecte, senzillament passarà None com a valor de la instància, és a dir, res, i això indicarà a Django que es tracta d'un registre nou.

Per tant, quan hem entrat via add que que obtenim és un formulari buid. Com que hem entrat per GET l'if no s'avaluarà i Django ens presentarà una plana html amb un formulari buid.

Suposem ara que feim un /edit/2/, en aquest cas també haurem passat per GET però el valor de l'id serà 2.

formulario llavors tendrà None com a valors inicials per la mateixa raó que abans, però ara el primer terme de l'and és vertader i se n'avalua el segon, això fa que obtinguem com a valor per la instància l'objecte Person que té id igual a 2. En aquest cas tendrem un formulari ple amb els valors del registre i Django ens presentarà un formulari amb les dades de l'objecte com a valors i lligarà la instància al formulari (això significa que podrem fer formulario.save() per guardar el registre).

Molt bé, ja tenim un formulari, ple o buid, tant fa, ara el que feim és afegir o modificar dades i pitjam damunt l'opció de guardar. Això farà un post i cridarà a la mateixa url (el punt a l'action així ens ho garanteix), això significa que per a la inserció l'id serà None i per afegir l'id serà un número, 2 en el nostre cas.

Ara entram per POST, la qual cosa fa que la primera part de l'or sigui vertadera, amb la qual cosa el formulari tindrà com a valors inicials el que hagem posat, perquè això? dons per si no hem passat la validació del formulari, si anam per POST i el formulari no passa la validació, anirem novament a la mateixa plantilla, però ara tindrem com a valors del formulari el que hem passat, és a dir, si no passam la validació tornarem a tenir un formulari ple amb les dades que hem escrit.

És important fixar-se que les dades inicials a diferència de les dades que passem per la instància no necessàriament han de ser vàlides, no passen pels mecanismes de validació de Django, i això és el que ens permet recuperar tot el que hem escrit encara que estigui malament segons la validació.

Seguim, si hem entrat per edit l'id serà None i per tant ja no es crea cap objecte Person, si hem entrat per add l'id tindrà valor i s'avaluarà el segon terme de l'and amb la qual cosa haurem recuperat el registre de tipus Person que té id igual al nombre passat i l'haurem lligat al formulari.

Com que és un POST i passam la validació el que se fa és guardar el registre (si estava inicialitzat farà un update, sinó farà un insert a la base de dades i ens retornarà la instància de la classe Person que s'ha guardat.

Ara, que ja s'ha guardat sols ens queda fer un redirect de manera que evitem problemes amb dobles pitjades i refrescs varis. En el meu cas vaig a una url que em presentarà la fitxa que tot just acabam de crear/modificar.

Esper que aquest exemple us hagi agradat tant com a mi quan ho vaig veure. És tot un exemple de l'expressivitat de Python i del ben pensat que està Django. Però el més important de tot d'aquesta història és que sempre es pot aprendre alguna cosa i que per aprendre és important dedicar temps a llegir codi dels altres.

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

Django 1.0

Escrit per Aaloy a 04 de September , 2008 a les 8:48 a.m.

La versió 1.0 de Django fa sis hores més o menys que ha sortit del forn, es pot veure ja el comunicat oficial a la plana web del projecte.

Els números són impressionants, de de la darrera versió estable s'han fet 4.000 commits, s'han resolt 2.000 errors i s'han afegit o llevat prop de 350.000 línies de codi. I el que trob un factor diferenciador de Django: s'han afegit 40.000 línies noves de documentació, pocs bastiments de codi obert dediquen tants esforços a la documentació.

Se m'ha acudit passar-li el sloccount a trunk del projecte

Totals grouped by language (dominant language first):

Total Physical Source Lines of Code (SLOC) = 71,411

Development Effort Estimate, Person-Years (Person-Months) = 17.68 (212.16) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC1.05))

Schedule Estimate, Years (Months) = 1.60 (19.15)

(Basic COCOMO model, Months = 2.5 * (person-months0.38)) Estimated Average Number of Developers (Effort/Schedule) = 11.08

Total Estimated Cost to Develop = $ 2,388,334

Si a més contam css, javascript i l'html amb una altra eina

 ./cloc-1.04.pl  --exclude-dir=.cvs,.svn --no3 .

    http://cloc.sourceforge.net v 1.04  T=11.0 s (80.8 files/s, 10177.7 lines/s)
    -------------------------------------------------------------------------------
    Language                     files          blank        comment           code
    -------------------------------------------------------------------------------
    Python                         739          15302           8184          83136
    HTML                           100            364             15           1725
    Javascript                      15            107            269           1547
    CSS                             15             83             82            505
    XML                             10             49              8            431
    make                             1             12              4             54
    SQL                              8              1              9             40
    Bourne Shell                     1              4              7             17
    -------------------------------------------------------------------------------
    SUM:                           889          15922           8578          87455
    -------------------------------------------------------------------------------

Hem d'agraïr la feina feta als desenvolupadors principals de Django i a la comunitat que s'ha format al voltant per tot l'esforç i la bona feina feta.

Django s'ha convertit per mi en un factor diferenciador en el que fa a productivitat i velocitat de desenvolupament, cada nova millora ha estat sempre orientada fer les coses més naturals per al programador, més pythoniques, molt en la línia del llenguatge de programació en el qual està fet Django, el Python.

Ara sols resta anar adaptant el codi per a incorporar les millores i les noves maneres de fer feina. Els canvis dels darrers mesos han estat tan grans i tan ràpids que sovint costava anar seguint el fil, però el resultat és un bastiment com per a sentir-se orgullosos.

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

Rei o ric

Escrit per Aaloy a 01 de September , 2008 a les 10:13 a.m.

Al blog de Carlos Blanco, en l'apunt realmente necesitas un inversor hi vaig trobar una frase que diu Aconsejo a los emprendedores que busquen inversión que primero se planteén si “¿Quiero ser Rey o Quiero ser Rico?“.

Estic traient la frase de context i no es ben bé la situació en que ens trobaríem, però crec que val la pena reflexionar-hi.

Quan hom munta una empresa ho fa amb una visió del que vol que sigui l'empresa, però sempre amb la sana intenció de poder-hi viure. Es a dir, fer pasta és una dels objectius de tota empresa mercantil, però això no lleva que a més hi pugui haver un objectiu social diferent.

A la pregunta de rei o ric podríem contestar: republicà! És a dir, hi ha diferents models i visions d'empresa que poden compatibilitzar el fet de guanyar-se la vida, fer diners i no plantejar-se la venda de l'empresa com un objectiu a priori.

La meva visió d'empresa se pareix molt a la que va dur a Joel Spolsky a fundar Frog Creek. Vull una empresa on la gent tècnica s'hi senti com a casa, que cada dia el motivi per aixecar-se del llit i fer feina, una empresa on es valori el talent individual i del grup. És a dir, aquell tipus d'empresa on a la gent amb talent informàtic s'hi pegui per fer feina.

A un seminari un consultor va amollar "motivado se viene de casa, no es la función de la empresa motivar a los empleados". No hi estic d'acord. És funció de l'empresa crear un entorn i unes condicions que motivin a la gent a fer-hi feina, i aquesta motivació no ha de ser una motivació externa (la pastanaga de doblers per objectius, per exemple) sinó una motivació interna, fruit de que la gent vulgui donar el millor de sí mateixa perquè així contribuirà a mantenir el lloc de feina on li agrada estar.

Accés a bon equipament, a la possibilitat de teletreballar, la possibilitat de trobar-te en un lloc de feina amb gent igual que tu, a que es valorin les opinions i les iniciatives, amb accés a les darreres tecnologies. Crec que això motiva més que cap altra cosa perquè fa que la motivació surti de dintre de la gent. Fa que pugui explicar als seus companys on fa feina i ho pugui fer amb orgull de ser part d'una empresa on la majoria hi voldrien fer feina.

I no m'interpreteu malament, el sou també és important, però no és el més importat a vegades. Suposem una empresa que te deixa teletreballar però que et paga diguem 200 Eur menys que una que té jornada partida i que està a 30 Km de casa. Una vegada has restat el dinar i la benzina resulta que la que fa teletreball te surt més rentable que l'altra, i si te paga el mateix ja hi estàs guanyant.

El consultors de RRHH intenten aplicar als tècnics informàtics les mateixes receptes que aplicarien a una cadena de muntatge, de manera que no se valora al tècnic i se'l té per intercanviable, no es valora el coneixement i el valor que pot aportar.

No és la meva idea d'empresa, i si algun dia, esperem que no molt llunyà, em veig a poder fundar la meva pròpia empresa vull que sigui tant per fer doblers com per demostrar que un altre model d'empresa és possible, que és possible anar a fer feina cada dia sabent que no ho fas sols per doblers, sinó perquè t'agrada estar allà i t'agrada el que fas.

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