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.

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

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

No adivinis, mesura

Escrit per Aaloy a 24 de February , 2008 a les 5:58 p.m.

A l'hora de fer estimacions de projectes una de les regles bàsiques que hi ha és que si existeix algun tipus de dada mesurable és millor això que res, i que és millor tenir una dada objectiva i reproduïble que tirar d'arts adivinatòries.

Això és aplicable també a altres àmbits de la programació: en lloc de dir "aquest algoritme crec que millora el rendiment" mesurem els seus efectes abans i després, sols d'aquesta manera podrem avaluar objectivament les millores que tenim.

En lloc de dir "el rendiment en producció serà millor", comprovem-ho, agafem-ne mostres i facem extrapolacions. Comprovem els canvis que feim quan posem cachés, optimitzam la base de dades, augmentam la memòria del sistema i documentem-ho tot.

La informàtica és una ciència i com a tal les afirmacions si no són demostrables i reproduïbles sols tenen sols el valor que els vulgui atribuir cada un segons la solvència de la persona que les fa. Si les afirmacions van acompanyades de mesures i dades, ja no és cosa de creure o no, és cosa de comprovar. Potser per això a tots ens agraden tant els benchmarks.

1 comentari, 0 trackbacks (URL) , Tags: Gestió de projectes

Integració contínua

Escrit per Aaloy a 10 de February , 2008 a les 5:50 p.m.

Recentment he estat fent un poc de recerca per veure com podia aplicar els conceptes d'integració contínua als nostres projectes. El conjunt d'aplicacions que tenim ha anat creixent al llarg del temps i les dependències entre les llibreries i les aplicacions també ho ha fet.

La idea de la integració contínua és que hi ha un mecanisme automàtic que recull les actualitzacions dels diferents repositoris de control de versions que es tenguin i aplica els tests d'unitat per comprovar que tot funcioni i que els tets passen. D'aquesta manera, i si s'han fet els tests, podem minimitzar l'impacte d'un canvi d'una llibreria en les aplicacions, és a dir, si pel que sigui canviam una llibreria i els canvis impacten a una aplicació de manera no prevista, quan construïm l'aplicació no passarà els tests.

El programari d'integració contínua permet seguir els tests, treure'n estadístiques i veure manera integrada què és el que ha fallat o comprovar que tot ha anat bé. A més es pot utilitzar el programari per a la construcció de l'aplicació i el seu desplegament als entorns de proves. Fet i fet, aquest tipus de coses es poden fer molt bé amb scripts i ens asseguram que en tot moment tenim la nostra aplicació a punt.

En entorns on hi ha molta gent, la integració continua garanteix que si algú "peta" l'aplicació amb commit que no passa els tests, aquest fet es descobrirà prest i es podrà minimitzar el seu impacte. La majoria de sistemes que he avaluat a més permeten a més dels tests unitaris, passar tests al codi font per intentar detectar errors, veure que se segueixen les regles d'estil, etc.

Per a les meves necessitats volia que el sistema d'integració contínua fos capaç de fer feina amb Java (la majoria ho compleixen) però que a més pogués passar els tests de Python i que en general pogués fer des de la construcció de l'aplicació, passar els tests i fer-ne el desplegament.

El que més m'ha agradat per ara és un sistema anomenat Hudson. Hudson és una aplicació recent, feta en Java, fàcil de desplegar i de fer anar. La interfície està molt cuidada i té tot el que necessit per començar. A més hi ha un article de com fer la integració per Python, que m'ha anat molt bé per començar.

Hi ha moltes més alternatives, a mi Hudson me va molt bé perquè té tot el que necessit per aquesta etapa del desenvolupament i és prou extensible com per a que pugui cobrir les nostres necessitats del futur proper. Hi ha altres sistemes a on triar, la gent de Confluence n'ha fet una taula comparativa. Mirau i comparau, però si teniu les mateixes necessitas que jo, no deixeu de fer una ullada al Hudson.

0 comentaris, 0 trackbacks (URL) , Tags: Java Gestió de projectes

Projecte mascota: NDD

Escrit per Aaloy a 07 de December , 2007 a les 9:15 p.m.

Hi ha uns tipus de projectes, normalment petits, que serveixen per provar nous conceptes i idees, que els anglosaxons, sempre tan ocurrents amb els noms, anomenen projectes mascota: els pet projects.

Aquest tipus de projectes estan molt lligats als programadors que els fan, se'ls agafa "carinyo", a força de bregar amb ells provant noves idees. Els pobres però, també solen ser un conjunt de pegats, ja que no es caracteritzen per una arquitectura ben definida i elegant, sinó per ser un conjunt de proves de concepte i de noves rutines que el programador vol provar.

Aquests darrers dies he posat en marxa el meu pet project: a partir de la necessitat de refer una web he començat a desenvolupar el que serà el nou lloc web de No Diguis Dois. Té tot allò que el caracteritza per ser un projecte mascota:

• No hi ha implicació econòmica, la família és la família.
• Es fa a hores lliures
• Hi vaig provant tot el que se m'acud :)

La idea és acabar amb un lloc web on el grup pugui posar la seva biografia, cançons, fotografies i mantenir als fans al tanto de les seves actuacions.

El projecte correrà damunt Django, bé de fet ja corre, però sols a la meva màquina per ara ja que s'han de pujar molts continguts i m'ha servit per provar tot un grapat de pluguins i idees:

• Photologue: és una aplicació Django molt senzilla que s'integra dins l'administrador i que ens permet mantenir galeries de fotos. L'he adaptada un poc per a que estigui en català i per a que s'adapti a les meves necessitats, però m'ha estalviat molta feina, ja que tot el manteniment i les plantilles venen donades.
• jcarousel: Una vegada ja tenim les fotos convé presentar-les bé. Jcarousel és un afegitó per jQuery que ens permet mostrar galeries de fotos. Com que a més volia mostrar la foto en gran, he optat per l'estàndard
• ThickBox : No hi ha prou lloances per aquest afegitó de jQuery que és cada dia millor. En dues potades tenia connectada la galeria de jcarousel amb la presentació del ThickBox. L'exemple del jcarousel ha fet més nosa que servei ja que està molt lligat a mostrar sols una galeria, però sigui com sigui ara puc mostar diverses galeries de fotos i quan se'ns selecciona una passar a la presentació de ThickBox.
• He provat els inclusion tags de Django. Una virgueria de fa poc. El problema era que volia mostrar a cada plana contingut dinàmic i a la mateix vegada no perdre la potència de les vistes genèriques. Els inclusion tags permeten definir en dues potades tags per a la nostra aplilcació, de manera que ara tenc un {% show_components %} com a tag que em permet generar sempre que vulgui la llista de components. Això m'ha permès treballar amb sols amb una plantilla i que totes les altres n'heretin, fins i tot les vistes genèriques i disminuir l'acoblament de les aplicacions com photologue de l'aplicació que he generada per la gestió del lloc web de No Diguis Dois.
• També he fet servir el nou tag per les cachés de Django. Aquest tag ens permet definir una caché sols per un tros de la pàgina web. En el meu cas l'he fet servir per mantenir els menús, part dels quals es genera dinàmicament. El tema de les cachés en Django està força ben aconseguit, es pot cachejar part de la plana, la plana sencera, les dades, o qualsevol cosa que vulguem, ja que tenim accés a l'API, i no tan sols això, sinó triar si volem fer servir la memòria, el sistema de fitxer, la base de dades o el memcached per a gestionar-la.

Encara em queden força coses més a provar, com l'edició en línia dels continguts, però no sé si serà per aquesta versió. Ara els plans són sortir en quant tinguem llests els continguts i netejar un poc el codi i pujar-ho a un repositori subversion public, per si algun altre grup de rock ho pot aprofitar.

Supòs que la web es llançarà poc abans del nou disc, i esper tenir el codi prou netejat com per a poder-ho publicar en condicions. És el que té un pet project, que a la que et descuides te mossega els calçons.

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

L’analista

Escrit per Aaloy a 25 de November , 2007 a les 6:32 p.m.

Tret del llibre Software requirements,

L'analista és la persona que ajuda als qui han demanat el projecte [1] a trobar la diferència entre el que ells diuen que volen i el que realment necessiten.

[1] stakeholders a l'original

M'ha feta gràcia la definició perquè és quelcom que sovint és perd al rol d'analista. L'analista ha de poder dir la seva en el projecte, proposar solucions, millores i expressar sense por el perquè troba que el que s'està demanant no funcionarà, o no és necessari.

Encara que se pugui dir que el client sempre té raó, si duim aquesta frase a les seves darreres conseqüències en el desenvolupament de programari, estarem pervertint la feina de l'analista.

És potser el mateix que quan un demana un disseny web i li diu al dissenyador des de com vol el format, les fotos, els colors i la tipografia. Llavors per a què vols un dissenyador web?

Pel que es veu aquest tipus de situacions no és sols pròpia d'analistes o dissenyadors web. Parlant amb un arquitecte em deia que té clients que ja li venen amb els plànols fets i que no atenen a raons, són els que solen acabar amb el bany aferrat a la cuina. També vaig viure una situació semblant amb un interiorista, el client li deia com ho volia tot, col·locació, llums, decoració, fins que l'home l'hi va tenir que dir que aquells temes eren precisament la seva feina.

Potser ens ho tendríem que plantejar de tant en tant allò de dir: "escolta, això és la meva feina, si la vols fer tu endavant però després també t'has de responsabilitzar dels resultats".

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

Què torbes a corregir un error de producció?

Escrit per Aaloy a 18 de November , 2007 a les 4:34 p.m.

Trobar un error al teu codi és un emprenyo. Poder començar la depuració en 30 segons, trobar l'error 2 minuts, pujar-ho al subversion i actualitzar la versió de producció de manera que als 5 minuts d'haver detectat l'error estigui corregit no té preu.

Això és el gran avantatge dels llenguatges d'script, que el temps que passa des de que trobes un error a poder-ho corregir és molt curt (llevat d'excepcions amb errors difícils de trobar i depurar, clar). Curt perquè normalment posar en marxa l'entorn de desenvolupament no duu més que uns pocs segons i ja pots començar a depurar.

Si tot està ben organitzat el codi estarà a un repositori subvesion i l'entorn de producció no serà sinó un client de subversion, de manera que fer una actualització una vegada trobat un error que no afecti a la base de dades, és bàsicament

• svn ci
• ssh al servidor
• svn update

L'experiència amb Java és que ja directament és necessiten els 5 minuts sols per posar en marxa l'entorn, 5 o 10 minuts més per depurar i si hi ha sort i sols era un error de jsp 2 mintus més actualizar i forçar la compilació del jsp per a que el proper usuari no vegi en enlentiment en la pàgina. Normalment més del doble per a corregir el mateix tipus d'error.

Si la correcció de l'error implica canviar codi que no sigui jsp o html les diferències són encara més grans i sovint pot implicar tenir que reiniciar el servidor, la qual cosa ens obligarà a tenir sempre dos servidors balancejats si no volem tenir als usuaris aturats durant 5 minuts. L'Apache es recarrega en segons, i tot i que sempre és bo tenir-ho tot duplicat i balancejat, la necessitat no es tan forta com en el cas anterior.

Personalment m'agrada molt Java i les llibreries que s'han desenvolupat en aquest llenguatge, però si el nostre negoci depèn del ràpid que puguem actualitzar la nostra aplicació web hi ha entorns i llenguatges amb més avantatges que Java o .Net.

4 comentaris, 0 trackbacks (URL) , Tags: Gestió de projectes

Llegir codi

Escrit per Aaloy a 09 de September , 2007 a les 1:36 p.m.

Aquests darrers dies estic llegint el llibre wxPython in Action de Robin Dunn i Noel Rappin. El llibre és un tutorial de com escriure aplicacions fent servir la llibreria wxPython i com fer servir cada component (widget) que la llibreria inclou.

En el que és la explicació de cada component i els exemples hi ha una gran quantitat de llistats de codi font i comentaris damunt aquests llistats. Això m'ha fet recordar el capítol en que Glass tracta la importància de poder llegir codi. Diu, i estic completament d'acord, que a programar no se n'aprèn sols coneixent la sintaxi del llenguatge de programació, sinó també escrivint programes i sobretot llegint codi que ha escrit altra gent, i que aquesta capacitat de llegir codi s'hauria de cultivar més a les universitats i escoles tècniques.

Sense aquesta capacitat de llegir codi d'altres també ens trobam que llegir tutorials com el de wxPython es fa pràcticament impossible, si no som capaços de llegir el codi, interpretar mentalment que fa i imaginar-nos la sortida, no ens queda més remei que picar el codi i executar-ho per aprendre, la qual cosa fa que l'avanç en el domini de la llibreria sigui molt més lent.

Ser capaç de llegir el codi d'un altre ens permet aprendre noves tècniques que potser no estan explicades en el llibre, normalment perquè no és el seu objectiu, i ens permet la lectura a llocs allunyats de l'ordinador: al sofà, a la fresca a la terrassa,...

El programari lliure ens permet llegir codi que ha fet altre gent, veure com funciona, aprendre noves tècniques o veure el que s'ha fet malament o maneres de millorar-ho. Aquesta capacitat és fonamental a l'hora d'aprendre el funcionament d'una nova llibreria, de fer inspeccions de codi abans de posar en test un programa, o a l'hora de depurar o modificar codi que ha fet una altra persona.

Les èpoques del programador solitari que ho feia tot han ja queden lluny. El més normal actualment és que els programes és desenvolupin en equip i la gent acostumada a llegir codi ho té molt més fàcil per a adaptar-se a la feina en equip.

Si una persona sols ha fet feina fent servir programari tancat no haurà tingut l'oportunitat d'aprendre el que significa poder veure codi de tercers i per tant la seva evolució com a programador serà menor que aquells que estan acostumats, bé per necessitat o bé per convicció, a llegir el codi font d'altres persones.

Com vaig sentir a dir a Ricardo Gali a una conferència de Bulma, el codi és una font en sí mateixa per emmagatzemar i transmetre coneixement.En els cas dels programadors això també es tradueix en possibilitat d'aprenentatge i amb minimitzar el nombre d'errors i tasques de depuració.

1 comentari, 0 trackbacks (URL) , Tags: Llibres i revistes Gestió de projectes

Software project survival guide

Escrit per Aaloy a 14 de August , 2007 a les 8:26 p.m.

Titol: Software project survival guide Autor: Steve McConnell Editorial: Microsoft Press ISBN-13: 978-1-57231-621-8 Pàgines: 288

Sofware project survival guide és un llibre damunt la gestió de projectes en general, no entra a explicar cap metodologia concreta, sinó que és un conjunt de consells i llistes de coses a comprovar en els projectes, però sense mullar-se ni anar al detall.

Al contrari d'altres llibres de McConnell he de dir que aquest no està a l'alçada, pareix més un llibre d'aquells que es fan per pagar factures i que s'aprofita de la fama dels que l'han precedit.

Tot i això he ha coses aprofitables: alguns "survival checks", una mena de llistat de coses a tenir en compte o a fer per dur endavant el projecte, i és un recordatori del cicle de vida d'un projecte.

L'estil tampoc és el que acostuma McConnell, molt més amè de llegir. Aquest m'ha costat acabar-ho, ja que li passaven per davant tots els altres llibres que he anat comprant aquesta temporada.

En el que fa a l'edició, el llibre té una edició amb una tipografia de cos dotze amb molt de marge per tot i amb un doble espai generós. Amb una altra tipus d'edició el llibre no passaria del centenar de pàgines.

En definitiva, si us ho regalen o el trobau de segona ma agafeu-lo, però no val la trentena d'euros que costà.

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

Filtres de selecció de personal

Escrit per Aaloy a 13 de August , 2007 a les 10:12 p.m.

Trobar bona gent és difícil i trobar-la que a més es pugui integrar en un equip ja format encara ho és més. A les respostes d'anuncis de feina s'hi pot presentar molta gent i en poques preguntes sovint s'ha d'intentar esbrinar si la persona que tens al davant serà bona tècnicament i a la vegada la seva manera d'entendre la feina serà per l'estil de la que hi a al grup.

Encara que soni molt a tòpic hi ha una sèrie de regles heurístiques que quan parlam de programació web ajuden a fer-se una idea d'ambdues coses:

• Adreça de correu amb domini propi : suma un punt. Per mi vol dir que al manco hi ha una preocupació per cercar-se la vida i potser haver donat d'alta un domini. Tenir un domini implica que també es pot cotorrejar abans de la selecció i veure quins temes preocupen al possible candidat o candidata.
• Adreça de correu amb Hotmail: resta dos punts. Sovint també vol dir que estàs engantxa al messenger i/o que no ets capaç de diferenciar el tenir un correu per usos lúdics d'un per usos professionals. Serveix per a diferenciar la gent que el primer que intentarà fer és posar-se el Messenger.
• Edició d'HTML. Si el sols es sap fer servir el Dreamweaver resta de cop 2 punts. Implica que d'entrada es tendran problemes quan es tracti de modificar planes webs fetes a troços, pràctica habitual en la programació web. Si utilitza un editor amb resaltat de sintaxi suma un, si a més sap fer servi el vi/vim suma dos punts. Si no ha fet mai una plana web resta cinc punts de cop.
• Coneixements de CSS. Si ha maquetat pàgines amb CSS i sap perquè ho ha fet suma 2 punts. Si no sap perquè ho ha fet sols en suma un. Si no sap què és resta un punt. Tenir coneixements de CSS ajuda a saber el que es podrà fer en la pàgina.
• Coneixements de Javascript. Si els sap fer servir mitjanament suma un punt, si a més coneix alguna llibreries de les típiques suma un altre punt. Si sols coneix el que posa el Dreamweaver lleva un punt. Tot es pot aprendre, però si un ja té experiència en Javascript vol dir que realment ha programat per la web. Si a més abans ha dit que utilitzava un editor "per programadors" començarà a agradar-me força.
• Si sap què és l'arbre DOM suma un punt. Si no ho sap i ha dit que ha manejat força Javascript ens haurem de plantejar sèriament si ha està decorant el currículum.
• Si sap què són els estàndards W3C suma un punt.
• Si sap que és un sistema de control de versions suma un punt, si a més l'ha fet servir suma un punt més.
• Utilitzar Linux suma dos punts. Per una part vol dir que encaixarà millor en el grup, però objectivament vol dir que serà capaç de modificar una plana que no està al servidor local, estarà acostumant a que els noms dels arxius són diferents en majúscules i en minúscules, sabrà què és l'UTF-8, etc. I sobretot demostra ganes de fer coses i de no conformar-se amb el que fa la gran majoria.
• Utilitzar Firefox com a eina de desenvolupament. Suma un punt. En suma un altre si coneix dos plugins indispensables per al desenvolupament web.
• Conèixer un llenguatge de programació d'script suma un punt. Si aquest es Python o Perl en suma un altra. PHP o Ruby no puntuen més. Un perquè a un que fa programació web se li suposa un mínim coneixement de PHP i Ruby perquè no es pot distingir de si es fa per moda o per convenciment.
• Conèixer el patró MVC i saber-ho explicar suma un punt. El patró MVC s'ha convertit en omnipresent per la web i conèixer-lo i fer-ho servir indica que es una formació en programar pensant en la separació entre capes.
• Conèixer SQL suma un punt. No fer-ho en resta un. No puc concebre que algú faci webs dinàmiques i no tengui idea d'SQL.
• Conèixer els bastiments i llibreries utilitzades a l'empresa suma dos punts.
• Ser membre actiu de Bulma o algun LUG suma un punt. Indica que el candidat s'implica en el que fa i contribueix amb les seves aportacions.

Hem de dir que d'entrada el possible candidat ha de conèixer el bàsic que se li demana, és a dir, si l'oferta és per programador Java-J2ee, si ja no es sap cap de les dues coses doncs el més probable és que el seu currículum ja no passi pel filtre de RRHH. Si ho fa llavors ens trobam davant un currículum que pot ser vàlid o estar especialment decorat per l'ocasió.

Un currículum amb una puntuació d'entre 17 i 20 és algú que s'ho paga entrevistar amb més profunditat. Entre 13 i 16 convé fer-hi una ullada però no hi ha massa possibilitats així d'entrada, i si és menys que aquest valor doncs potser és millor no perdre-hi més temps.

Tant les opcions com les valoracions són elegides ad-hoc sabent d'entrada el tipus de gent que m'agrada i que potser encaixarà bé en el grup, empreses i grups distints poden tenir valoracions distintes. Segurament una persona amb una puntuació de 20 no encaixarà en un ambient poc dinàmic i que no tengui capacitat d'innovació.

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

Programar per menjar

Escrit per Aaloy a 12 de July , 2007 a les 10:22 p.m.

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?

1 comentari, 0 trackbacks (URL) , Tags: Gestió de projectes

D’hores-home i E-Factor

Escrit per Aaloy a 05 de January , 2007 a les 11:27 p.m.

En la literatura de gestió de projectes és habitual trobar-nos amb el concepte d'hores-home per expressar la unitat de mesura de projectres, com a una unitat que expressa el temps necessari per a desenvolupar un projecte. Així 100 hores-home indica que el cost de projecte seria equivalent al de 100 hores d'un sol programador.

El problema de les hores-home és que es presten a confusió quan el nombre d'hores-home passa cap a gent no tècnica, que té que aprovar un pressupost o dir en quant de temps s'ha de fer un projecte.

a) Pot donar a entendre que les hores de programació són intercanviables. Es a dir, 100 hores-home per fer un programa poden ser fetes per 100 programadors treballant una hora, com per 10 programadors treballant deu hores, com per dos únics programadors que s'hi dediquen 50 hores.

b) Suposa que totes les hores de treball són efectives. És a dir, suposa que un programador és capaç de ser productiu des de el mateix segon que es posa a pensar en el programa.

Per evitar el primer problema el nombre d'hores-home ha d'anar acompanyat amb temps mínim de realització i el temps més probable, de manera que es pugui veure que l'augment del nombre de programdors a l'equip no implica necessàriament que es reduexi el temps necessari per entregar el projecte, és a dir, que quedi molt clar que hi ha un temps mínim per sota del qual no és possible entregar el projecte.

Molt més problemàtic és explicar el tema de la no intercanviabilitat de la gent. El més normal és explicar-ho en termes de coses que el nostre interlocutor ja conegui, indicant que hi ha gent especialista en cada cosa i que no es pot substituir fàcilment una gent per una altra. Comparar programadors amb metges és força efectiu, podem explicar que quan et fa mal un queixal no vas al proctòleg sinó al dentista. Els dos poden ser metges i molt qualificats, però cada un té la seva especialitat.

Atacar el segon supòsit implica no presentar la valoració del project en termes d'hores-home, convé anar cercant una altra unitat de mesura que ens permeti expressar millor el que és una hora de programació efectiva.

El concepte d'hores efectives està tractat molt bé al Peopleware, on es dedica tot un capítol complet al tema de les hores de treball ininterromput vers les hores de permanència a l'oficina. És el que anomena E-Factor, i ens dona una idea del treball que es perd per no tenir un ambient de feina que permeti tenir prou hores sense interrupcions.

Quan feim una estimació en termes d'hores-home poques vegades es considera la correcció que ve de l'E-Factor, de fet potser ni tan sols se'ns sap el valor, ja que ningú s'ho ha plantejat mai, sols se sap que els projectes es retràssen i no se sap ben bé perquè.

Per una altra banda, la metodologia de l'Extreme Programing proposa que les valoracions de les tasques es facin en termes d'Ideal Engineering Hours (IEH). És a dir, que les valoracions s'expressin en termes de temps sense interrupcions necessari per a completar dita tasca.

Particularment m'agrada molt la idea de tenir una unitat per expressar la dedicació necessària per fer un programa que implícitament té en compte que la feina es pot allargar més o menys en funció de les condicions laborals i de les interrupcions que es tinguin.

Fent servir les IEH com a unitat de valoració en lloc de les habituals d'hores-home estam transmetent la idea de que el desenvolupament de programari és una tasca on les interrupcions tenen un impacte molt gran en la productivitat dels programadors i per tant en el cost del projecte.

De retruc potser algú es demanarà el perquè d'aquest canvi i tal volta es plantegi poder calcular l'E-Factor.

Amb tot això ara quedaria discutir quina és la validesa de les estimacions de programari, és a dir, s'han de realitzar estimacions per saber el cost aproximat del projecte, però ens queda per saber com n'és de bona aquesta estimació o si ha d'anar lligada a que hi hagi una especificació completa del projecte, com si de fer un edifici es tractàs. Quan parlam de programari la comparança amb la construcció d'un edifici ens enfonsa la metàfora, però bé, això són figues d'un altre paner i ja miraré de parlar-ne més endavant.

Ara per ara potser alguns ja us estigueu plantejant presentar les vostres properes estimacions en termes d'IEH o anar calculant el vostre E-Factor particular, si ho feis m'agradaria conèixer quin és, que els estudis de productivitat en programari són més aviat rars en aquestes contrades i potser entre tots puguem treure'n alguna conclusió.

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