Hi ha gent que ha contactat amb mí per dir-me que no pot deixar comentaris al meu bloc. Ho sent-ho molt no està fet a posta, pareix que hi ha alguna cosa malament a la meva configuració del WordPress o que algun dels plugins anti-spam estan funcionant massa bé. Aquestes vacances miraré d'arreglar-ho, però no sé si me'n surtiré. El trastejar amb codi php i el WordPress no és cap de les meves prioritats principals, a saber: estar amb els meus meuts, llegir, estar amb la família, llegir un poc més, ... De totes maneres si a algú li ha passat quelcom semblant amb la seva instal·lació agraïria molt qualsevol sugeriment podeu utilitzar l'adreça del gmail o la de Bulma per posar-vos en contacte amb mi. La prova de què quelcom tenc malament en la instal·lació és que els Permalinks tampoc funcionen "com toca" ja que si els activ em qued sense poder gravar cap entrada al bloc :O

El Viajero de John Twelve Haws ens sumergeix en un futur proper, no hi ha naus espails ni res semblant, però la tecnologia hi la informàtica estan forçá més adelantades que en l'actualitat. La novela és una mescla d'acció, teologia, misteri, crítica social, lluita entre el be i el mal i el clàssic "chico conoce chica" en aquest cas "chica conoce chico"; en unes proporcions que fan que la novel·la sigui molt entretinguda i que "engantxi". Esperem que la continuació de la trilogia estigui al mateix nivell.

Sovint quan vaig a una pàgina web m'agrada obrir la pantalla de codi font i veure'n les butzes. Així puc saber quí la feta, com s'ha fet, conèixer en definitiva un poc la gent que hi ha al darrera. Darrerament i per motius professionals he anat a les webs d'un bon grapat d'Ajuntaments de Mallorca. Tal com va apuntar Benjamí a la bulmailing dins el codi d'un bon grapt d'aquestes web ens hi podem trobar aquesta perla: /************************************************** DESARROLLADO CON at4 picoCMS GRACIAS POR REVISAR NUESTRO CÓDIGO, PUEDES APRENDER MÁS EN: http://www.hotwired.com/webmonkey/ http://www.developer.com/ http://www.webcoder.com/ http://www.webreview.com/ **************************************************/ Molt lleig, befós, impropi! Realment saben els nostres ajuntaments que se l'estan jugant amb una empresa que no comprén els principis més bàsics que hi ha darrera Internet, que no comprenen que allò que fa la web és el compartir coneixements i no el fer befa de la gent que cerca saber-ne més? El més tritst però és que a la mateix pàgina he trobat més comentaris: /**************************************************************************/ /* : : : Bloc "El Temps als Països Catalans" : : : */ /* =================================== */ /* */ /* Copyright (c) 2003 de Kove (kove@mixmail.com) */ /* http://www.phpnuke-catala.org */ /* */ /* Aquest programa és software lliure. Pots redistribuir-lo i/o */ /* modificar-lo respectant els termes de la GNU (General Public License) */ /* com es publica en la Fundació de Software Lliure; */ /**************************************************************************/ Ara sí que ja no entenc res! Befa per un costat, codi tancat i per una altra ens aprofitam de codi GNU? Diu una vella dita que és millor no atribuïr a la maltat allò que es pot atribuïr a l'estupidesa.

Demà (bé, avui ja) es farà el sorteig de la Grossa de Nadal. Dessig mota sort a totes aquelles persones que juguin els mateixos números que jo }:D La llàstima de tot això és que no hi confio gaire amb aquestes coses. Amb això de sorteigs nadalencs, primitives i onces varis no he tingut mai massa sort i tenc el convenciment que si algún dia em veig a tenir doblers no serà per que m'hagi tocat la rifa, sinó perquè me'ls he guanyat fent feina... Mirem-nos però aquests tipus de sorteigs des d'una altra perspectiva. Què passa si als empleats d'una empresa els toca la grossa, o potser pitjor, si toca sols a una secció de l'empresa, a un departament d'informàtica per no anar més lluny. És un dels factors de risc que s'haurien de considerar a l'hora de fer un pla de contingència, ja que encara que sigui petita la probabilitat existeix i en alguns casos és més alta que la probabilitat de perdre el centre de dades per mor d'un terratrèmol, per exemple. Sovint el risc és minimitza diguent que sempre es pot contractar algú altre, però el problema real està en que potser no hi ha ningú per ensenyar a aquest altre o altres i per tant l'empresa es pot trobar creuant els dits i esperant que tot funcioni sense problemes fins que la gent nova s'hagi pogut familiaritzar amb els programes, la xarxa, els servidors, trobar les passwords d'administració, ... És per pensar-hi, no trobau?

Quartz és un gestor de treballs (job scheduling system) per Java de codi obert que es distribueix baix la llicència Apache 2.0. Segons la seva documentació s'integra perfectament tant amb aplicacións J2EE com amb aplicacions J2SE.

A la web de Quartz hi ha un bon grapat d'exemples per a la seva integració, però el que fa Quartz realment fàcil de fer anar és el bastiment Spring. Hi ha una secció de la documentació d'Spring dedicada a la integració de Quartz amb les nostres aplicacions Spring. La simplificació feta per aquest bastiment és fantàstica, i en pocs minuts podem tenir un completíssim cron a l'abast de la nostra aplicació web i executant les funcions Java que volguem.

Quartz és una d'aquestes coses que convé saber que existeixen i no tenir que anar reinventant la roda o fer pegats per tal de fer que la nostra aplicació realitzi tasques periòdiques. Per cert, s'ho paga llegir-se el tutorial de la sintaxi de cron que hi ha a la web. Clar i ben explicat.

Un dels bastiments per Python que estic provant (gràcies Morenosan per fer-m'hi caure) per al desenvolupament RAD d'aplicacions web és el Django. Aquest bastiment presenta una sèrie de característiques que el fan preferible per davant d'altres projectes semblants:

• Està molt ben documentat
• El tutorial es molt bó. T'engantxa tot d'una amb la potència del bastiment.
• La capa de persistència està molt cuidada i es pot fer anar independentment del bastiment web, amb la qual cosa s'agilita el testeig.

La part d'Ajax (un dels punts forts de Ruby on Rails) encara està molt verda, però si en fitxam en el ritme en que avança el projecte no m'extranyaria que en un parell de mesos ja tenguin quelcom funcional i a bon nivell.

M'ha impresionat com amb poquíssimes línees de codi (35) per ser exactes, tenc una aplicació funcionant amb dos manteniments del tipus mestre-detall, amb control d'accés, cerques, filtres i ordenació. A més m'ha permés definir l'estructura de les taules de la base de dades a partir d'objectes Python de manera que amb una sola comanda he pogut crear la base de dades.

Encara no he acabat el tutorial, vaig per la meitat de la tercera part i la feina feta representaria setmanes de treball de no comptar amb aquest bastiment. Hi veig un munt de possibilitats, tant per un producte final com per prototipat d'aplicacions.

Amb Django podem crear les interfíces per als manteniments de les nostres aplicacions web en qüestió d'hores i donar-les als usuaris per a que vagin fent. El problema ho tindrem a l'hora d'explicar-los el perquè una cosa tan potent no és la versió definitiva de l'aplicació. Ei! I per què no? :)

Quan hom es planteja un projecte informàtic la primera decisió que s'ha de prendre és quina metodologia seguirem a l'hora de desenvolupar el projecte. Bé, hi ha que dir que potser el que farem és començar passant de tota metodologia (code like hell, que en diuen) però com que aquest escrit anirà damunt metodologies i no damunt l'absència de la mateixa, doncs ho deixaré estar. :) De la mateixa manera que cada llenguatge de programació nou promet ser la bala de plata que acabi amb tots els mals de la programació i ser el llenguatge de programació definitiu, les metodologies de programació ens prometen poder dur el control dels nostres projectes, millorar-ne la gestió, poder entregar-los en els plaços acordats i deixar satisfet el client. Si algú ha trobat una metodologia que s'adapti a tots el projectes i a tots els equips i que faci tot això, per favor, avisau-me, però tot i així permeteu-me que no m'ho acabi de creure. En un món ideal el clàssic mètode en cascada seria el millor: analitzan els requisits, en feim un disseny preliminar, aquest s'aprova, feim un disseny detallat on tot està perfectament definit i es comença a codificar. Quan tot està llest s'entrega al client i aquest tot satisfet diu: "perfecte és exactament el que he demanat i és això el que volia". Però clar, això és exactament el que no passa i el que ha fet que s'estigui parlant des de fa temps de la crisi del sofware. Així doncs s'han anat cercant metodologies de programació que siguin molt més flexibles a l'hora de tractar amb clients reals on les especificacions són poc exactes i on el client no sap exactament el que vol. Estam parlant de projectes amb un risc molt gran, no per la seva gestió, sinó perquè hom no pot estimar la durada del mateix amb unes mínimes garanties. Així s'han de cercar metodologies que ens permetin gestionar l'incertesa, adaptar-nos el més ràpid possible als canvis, ... Les metodologies àgils, com l'extreme programming o el Feature Driven Development intenten ser una resposta a aquest problemes. Unit Test, desenvolupament iteratiu i incremental són pilars fonamentals d'aquestes metodologies Amb tot la majoria de les metodologies que conec, tant les clàssiques com les més noves tenen un problema fonamental en la seva aplicació: l'escalabilitat per avall. La majoria de metodologies estan orientades a tractar amb projectes grans, amb un nombre considerable de programadors (de l'ordre de cinquanta o més) i quan hom passa les seves indicacions cap a equips de programació petits, de l'ordre de cinc programadors o menys, les tècniques que s'aplicaven a projectes amb molts de programadors deixen d'aplicar-se. Moltes de les metodologies i els seus formalismes tendeixen a solucionar un dels problemes més importants en el desenvolupament de projectes amb molts programadors: la comunicació entre la gent i la seva coordinació. Aquest és un dels riscs més elevats en tot projecte gran i una de les raons de l'augment de la complexitat d'aquest projectes. Així tractant de miminitzar aquest tipues de problemes s'obliden dels projectes amb un nombre petit de gent. En aquests tipus de projectes podem aplicar tècniques que fan que el rendiment es multipliqui i que sovint no estan contemplades en les metodologies orientades a projectes grans. En un projecte on hi ha implicada poca gent:

• Els problemes de comunicació són mínims si podem situar els nostres programadors en un entorn adequat i pròxims entre si.
• Podem seleccionar millor els nostres programadors. Això vol dir que és més senzill trobar gent per damunt de la mitjana
• Podem aplicar tècniques basades en la regla del 20%. Es a dir, sols farà falta un 20% de la documentació que necessitariem en un projecte gran.
• Podem introduïr abans millores tecnològiques. No és el mateix formar a 50 persones que a 5.
• La consolidació de l'equip es crítica, però a la vegada també és més senzilla de fer.
• Es poden detectar abans els "egos problemàtics"
• Es pot establir una estructura de feina informal on es potencii l'iniciativa personal i la meritocràcia sense que hi hagi problemes de pèrdua de informació o de cohesió en el projecte.
• És molt més bo de fer conèixer a cada integrant del grup i saber-ne els seus punts febles i les seves mancances
• El grau de confiança entre la gent pot ser molt més gran. Més confiança implica millor ambient de feina, millor ambient implica millor productivitat.

En definitiva, ens podem recoltzar molt més en les persones que en la tècnica. La paperassa generada en els equips grans és sovint necessària perquè és sovint la única manera de tractar amb equips de gent on no tothom té la mateixa motivació a l'hora de fer feina (això no s'aplica a projectes voluntaris de codi obert, on la motivació personal és diferent). Aquesta paperassa, però, no és necessària en projectes amb poca gent i la metodologia de programació s'ha d'adaptar a aquesta situació. Per mi una possible recepta seria la següent:

• Lloga la millor gent que puguis pagar. Està demostrat que els bons programadors/es poden rendir fina a 10 vegades més de mitjana i el seu sou no és deu vegades superior
• La feina i l'ambient de feina ha de ser motivador i divertit. Als programadors ens agraden les coses noves. És molt avorrit programar sense innovar i l'avorriment mata la productivitat.
• És important disposar d'un bon equip i això s'ha de compatibilitzar amb el primer punt. La productivitat d'un equip pot ser fins a tres vegades superior a la de la suma dels individuos que el formen.
• La paperassa ha de ser la justa i necessària per l'envergadura del projecte i la gent que hi ha implicada. No hi ha perquè fer un model UML totalment detallat, tots els diagrames de seqüència, etc quan amb un diagrama de les classes de negoci i un parell de reunions formals n'hi ha prou.
• La utilització del CVS i un control d'errors per mi és fonamental. Ara per ara em seria molt difícil concebre un model de programació en grup sense un control de versions.
• La informació del projecte ha de ser pública i a l'abast dels programadors. Tant a nivell d'anàlisi, de les tasques que s'han de fer com dels plaços d'entrega
• S'ha d'establir un sistema de control d'error compartit. Els error s'han de registar per a que cada un pugui aprendre dels errors dels altres
• El codi és comú i la responsabilitat és compartida. Si ho romps ho arregles, però si no hi ets ho faig jo.
• La idea del Feature Driven Development en que que fa a la manera d'organitzar la feina és l'adequada per projectes on el client no sap massa bé el que vol o que hom prevegi que hi haurà força canvis. Dóna l'oportunitat de sempre tenir quelcom que funciona.

Per mi la clau de l'èxit d'un projecte informàtic no és el llenguatge de programació triat, la clau és la gent i com ens corportam els programadors i què ens motiva. Quan es proporciona un entorn adequat un grup cohesionat de programadors bons pot triplicar la productivitat individual pel mateix tipus de projecte. Què vol dir això? Poder abastar projectes destinats a un equip de 15 programadors amb un equip de cinc sense que els plaços d'entrega es multipliquin per tres i arribar a projectes que d'altra manera no s'hi podria arribar. La bala de plata potser no es trobi tant en la tecnologia, sinó en la gent que ha d'aplicar aquesta tecnologia, en la manera en que gestionam els recursos humans que tenim, en la manera en què seleccionam el personal, en la manera en què feim que aquest personal estigui content amb la feina que fa i amb l'empresa per la que treballa.

He de dir que m'agrada molt En Paul Graham, m'agrada la manera que té de veure la programació i com l'explica. A l'article damunt la Web 2.0 ens diu entre altres coses el perquè creu que la tecnologia Ajax s'està imposant en les aplicacions web i com afronten aquest canvi companyies com Microsoft o Google. Segons Graham la primera ja ha fet tard, Google per la seva banda n'és un pioner. Personalment també crec que les aplicacions web tenen un gran futur. Cada dia hi ha notícies de nous desenvolupaments que atraquen el món de les aplicacions web al món de les aplicions d'escriptori. Cada cop es poden fer més coses més fàcilment, això per una banda, i per l'altra crec que ens n'anam adonant que molts usuaris el que necesissten no són moltes opcions sinó aplicacions usables. Amb l'estat actual de la tecnologia ens podem plantejar gairebé fer qualsevol tipus de desenvolupament de gestió com a una aplicació web: una comptabilitat, una facturadora, un ERP, un CRM, ... La majoria de les limitacions lligades a les validacions, al temps de refresc de les pàgines o a les interfícies d'usuari s'han eliminat. Ara podem crear fàcilment estructures d'arbre, taules ordenables i paginades i un bon grapat de controls d'edició que gràcies al javascript són comparables als controls de les aplicacions de sobretaula. La tecnologia d'aplicacions web ha explotat i cada cop hi ha més gent que la fa servir, més gent que crea nous bastiments per fer la programació més fàcil. Aviat veure eines especialitzades un o altre bastiment, millors editors de Javascript, depuradors integrats en els nostres IDEs que alimentaran novament les aplicacions. Quina ha de ser la diferència entre les aplicacions web i les aplicacions de sobretaula? Bàsicament l'usabilitat, el pensar primer en l'usuari que en el màrketing, en la seva orientació cap els serveis vers en l'empaquetat de bits. És una de les raons del perquè el moviment opensource està fent molta feina en aquestes tecnologies: estan basades en estandars oberts: html, javascript, css i es pot estudiar el codi sense gaires problemes. D'aquí a que la solució sigui de codi obert sols hi ha un pas, que per una altra banda és del tot lògic. Però bé, me n'he anat per les bardisses, tornant al tema de l'encapçalament us remet a http://www.paulgraham.com/designedforwindows.html, esper que us faci tanta gràcia com a mi, però si voleu un consell, a més llegiu l'article de Graham per acabar de trobar-hi sentit a la foto i no us quedau tan sols en la part anecdòtica de la imatge.