Articles
No pensis!
Escrit per Aaloy a 24 de June , 2007 a les 11:26 a.m.
Alguns professionals de les TI no deixen de sorprende'm, són capaços de contradir-se una frase després de l'anterior, intentant justificar l'injustificable. L'altra dia algú es queixava del complexe i costós que resulta fer les actualitzacions dels productes d'Oracle, que si has de fer venir una múnia de consultors, que si les dependències entre productes són tan complexes que quan actualitzes un producte has d'anar molt alerta amb com afecta a la resta de productes de la companyia, etc. Aquí a mi no me queda més remei que fer paleses les contradiccions: si és tan complexe de gestionar, si te ferma tant al proveïdor, com és que hi ha gent que encara s'entesta en fer nous desenvolupaments en una tecnologia que te ferma de manera que les simples actualitzacions de versions són un maldecap i amb un costs que són difícils de predir. L'excusa de que el denvolupament amb Forms i PLs és més ràpid s'enfonsen ràpidament davant mètriques que ens diuen que el nombre de línies per punt funció són comparables en Forms o en Html (42 i 43 línees de codi per punt funció respectivament) i per la part presentació, de 46 de PL/SQL als 35 de llenguatges de l'estil d'Smalltalk (Python per exemple). [1] i això sense considerar aspectes que afecten a la productivitat com la facilitat de depurar el codi, de fer feina en grup, o de fer tests d'unitat. Davant això, pareix que la raó fonamental de triar productes d'una companyia concreta com els d'Oracle, no són de menor cost o major facilitat de desenvolupament, sinó que pareix que són que així el responsable del projecte no té que pensar. No hi ha possibilitat d'equivocar-se a l'hora de triar l'arquitectura o els components perquè no hi ha arquitectura o components per elegir. Sols tenim el que els senyors d'Oracle han decidit que podem tenir, independentment de les necessitats reals que podem tenir. Això se diu com a FUD davant les eines i bastiments de programari lliure, on abans de començar el projecte s'ha de definir l'arquitectura que es farà servir i triar els components més adients per la feina. A mi que algú em digui que elegeix una eina o una altra perquè així no té que pensar em dóna angúnia. La responsabilitat del cap de projecte en primer terme i del responsable de IT en darrer terme és assegurar-se que té el millor equip i la millor tecnologia a l'abast del negoci, de manera que es puguin respondre a les necessitats del negoci amb rapidesa. S'ha d'estar pendent tant de l'evolució del negoci com de les tecnologies informàtiques que poden fer que la resposta del departament d'IT pugui seguir l'empresa. Que hi pugui haver gent a una empresa que en senti còmoda amb una solució que a mig o llarg plaç sabem que donarà problemes, que té molts costs ocults d'actualització i administració, que se senti còmoda amb el no pienses, nosotros pensamos por ti explica perquè empreses més petites, però amb gent que no té por a pensar cada cop més s'estan enduent més negoci o posant en marxa negocis innovadors. En el moment que els negocis comencin a adonar-se que necessiten innovació per avançar, quan comencis a mirar el perquè negocis més petits tenen més clients i fan més caixa amb un costs menors i se n'adonin de que el no pensar no és una alternativa podem viure un vertader d'altabaix a alguns departaments informàtics. Comencem a pensar, comencem a voler pensar, demà pot ser massa tard. [1] Font: http://www.qsm.com/FPGearing.html5 comentaris, 0 trackbacks (URL) , Tags: Informàtica
Anar a la feina
Escrit per Aaloy a 15 de June , 2007 a les 10:04 p.m.
Fins que el tema del teletreball no s'extengui més no hi ha més remei que anar a fer feina cada dia, i això a Mallorca significa en molts casos tenir que agafar el cotxe fins a Ciutat. El meu trajecte matinal és d'uns 25 kilòmetres des de casa al lloc on deix el cotxe. No puc anomenar-lo aparcament perquè seria otorgar-li una categoria un parell de cents de vegades superior a la que té. Diguem que és un troç de terra on hi podem deixar vehicles. El trajecte encara que curt, pot durar entre 15 minuts un dissabte o un dia d'estiu a 50 minuts un dia de pluja. Encara que no plogui, però sovint un trajecte que sol ser de 20 minuts es converteix en un trajecte de 30 o 35 minuts amb llargues coes per entrar a la rotonda que duu al polígon industrial on faig feina. Hom podria pensar que el tràfic està molt congestionat, però hi ha un fet que no és aleatori i que sempre hi és present: el municipal que regula el tràfic a la rotonda. Quan aquesta gent, amb tota la seva bona voluntat, es posa a regular el trànsit la fluidexa del mateix disminueix en picat. Mira en la direcció que miris d'entrada a la rotonda, sols hi veuràs coes. Cada dematí quan surt de casa em deman a veure si hi haurà sort i no hi haurà el municipal regulant el trànsit i si encara hi haurà els dos cotxes fet pols i a troços a l'aparcament i que la grua, tant diligent en altres llocs, no ha llevat. I no serà perquè ningú ho sàpiga, tanmateix el municipal de torn hi deixa el cotxe just aferrat a les ferralles aquellles.1 comentari, 0 trackbacks (URL) , Tags: General
Suro project management
Escrit per Aaloy a 01 de June , 2007 a les 10:33 p.m.
Sovint ens trobam que la gestió de projectes, amb les incidències, tasques a fer i prioritzacions és massa complexa. El cap de projecte de torn se pot sentir estressat o estressada en veure que ha de gestionar els tickets amb les indicències, prioritzar-les, treure'n informes i conclusions que ajudin a dur a terme el projecte. Per aquests casos s'ha desenvolupat una metodologia prou senzilla de fer anar, que de ben segur serà de gran ajuda pels caps de projecte massa que s'apuren fent servir un sistema de ticketing i gestió de projectes, fins i tot quan és tan senzill com el Trac. Vegem en què consisteix la metodologia: El primer que necessitarem serà instal·lar el servidor, el suroserver. Per això anirem a la tenda més propera i encarregarem un suro de 150 cm x 80 cm, dimensions més grans son inútils, ja que el cap de projecte no pot copsar tot el servidor d'una ullada, i dimensions més petites provoquen frustració al ser massa identificables en les dimensions d'una pantalla plana. Aquestes dimensions que proposa la metodologia i s'han demostrat les correctes en nombrosos estudis empírics i estan avalades per prestigiosos organismes dedicats a l'estudi d'aquesta metodologis. Una vegada en hem fet amb el servidor, necessitarem una broca del set, dos soquets i dos claus ganxos. La instal·lació la podem fer nosaltres mateixos si tenim els coneixements suficients, o podem donar-la a fer al nostre tècnic amic. Una vegada feta la instal·lació n'hem de verificar la consistència i la qualitat del servidor. El grau de porositat del suro és important, de manera que per aconseguir els resultats òptims que ens donarà aquesta metodologia, recomanat fugir de solucions casolanes i comprar directament suroservers certificats i amb DRM. (Digital Rustic Manouvering). Ara que ja tenim el servidor, sols ens queda comprar també el sistema de control d'incidències i canvis, i els tags que indicaran la importància relativa de cada ticket. Com que el sistema està orientat a que el ratio entre eficàcia i simplicitat sigui molt alt, defugirem de metàfores que confonen la gent i farem servir directament tickets. Se recomanen tickets de 12 cm x 8 cm tipus post-it i de color, de manera que encara que s'escrigui en ells sigui difícil veure el que hi ha escrit si estam a menys de 10 cm del server. Això ens dona una bon ratio de privacitat, ja que és molt fàcil detectar qualsevol intent d'intrusió en el nostre suroserver. Una vegada el cap de projecte tengui el suroserve instal·lat i els postit de colors seleccionats, donarà un d'aquests postits a cada usuari, analista o ens que tengui alguna cosa a veure en el projecte, i l'acompanyarà d'una capça de 20 xinxetes. No serveixen xinxetes qualsevols, convé que estiguin certificades pel suroserver, per la qual cosa es recomana adquirir els jocs al mateix distribuidor del suroserver. Pot sortir un poc més car, però la compatibilitat de llicències ens garanteix una experiència d'usuari més agradable. Quan l'usuari detecta una incidència, l'escriu en el sistema de ticketing del suroserver i la penja en el servidor. Una vegada més vegem l'absència total de metàfores que dificulten la comprensió. El ticket és efectivament penjat al suroserver. La importància relativa de cada ticketing ve donada pel nombre de xinxetes que té clavat, d'aquesta manera amb el seu joc de xinxetes l'usuari pot anar prioritzant fins a 20 tickets, o bé donar màxima prioritat a un o vàris tickets augmentant el nombre de xinxetes que aquest té clavaes. A més és un sistema totalment participatiu i democràtic en tant en quant l'usuari pot puntuar tickets que no són seus augmentant-ne la prioritat. El cap de projecte a cop d'ull pot veure quina prioritat té cada ticket, o reassignar prioritats fent que l'usuari que passi per allà canvii les xinxetes de lloc. Una vegada el ticket està tancat se cridarà a l'usuari per a que el retiri i conservi el seu joc de xinxetes. Per això és important que a cada ticket figuri a més del contigut l'usuari que l'ha reportat. El ticket s'arxiva definitivament al ticket-box, que es ven per separat, és modular i admet fins a 2000 tickets per modul. Limitacions de la metodologia:- Si la prioritat d'un ticket és molt alta el nombre de forats pot impedir la seva legibilitat. Una vegada més reiteram la importància de fer servir xinxetes certificades.
- El suroserver s'ha d'instal·lar a un lloc sense vent. S'ha demostrat que les condicions de vent o pluja intensa afecten negativament al suroserver fent desapareixer aleatòriament els tickets o fent-ne malbé els continguts.
4 comentaris, 0 trackbacks (URL) , Tags: Conyes marineres
Experiments amb Flickr
Escrit per Aaloy a 01 de June , 2007 a les 9:34 p.m.
Hem començat a treballar en el que serà la nova web del cunyat, nodiguisdois.com. El grup aviat treurà nou disc i convé que millori l'aspecte del seu lloc web, que s'ha quedat una mica anys noranta, per dir-ho suaument. El projecte és petit, però anirà damunt Django, tots esperam que el nou disc sigui un èxit i el lloc web s'enfonsi a visites, així que millor anam pensant en l'escalabilitat de la web. Una web d'un grup de rock no seria res sense les fotografies, i per això, i per fer-ne l'experiment, res millor que veure què tal es comporta el Flickr i com se pot integrar amb amb l'aplicació feta amb Django. Flickr té una API per integrar-se amb una gran quantitat de llenguatges i també hi ha APIs externes que fan la feina. Una d'elles és Flickrpy, i en principi l'he triada per ser una de les més completes que he trobat. Ara no necessit massa cosa, però en un futur qui sap, i sempre ve bé veure que la llibreria és capaç de anar per davant teu. La utilització de la llibreria és molt senzilla. El primer que hem de fer és posar la nostra clau de l'API de Flicker que ens dóna l'aplicatiu quan hi ens subscrivim. Per això hem d'editar el fitxer flickr.py i poca cosa més. A partir d'aquí la cosa és prou senzilla:
$ from flickr import *
$ fotos = photos_search(user_id='8564577@N07')
$ for foto in fotos:
... foto.getURL(urlType='source')
...
u'http://farm1.static.flickr.com/238/523531137_7c873aaa03.jpg'
u'http://farm1.static.flickr.com/232/523531135_7b87f0b889.jpg'
u'http://farm1.static.flickr.com/219/523531129_112401e1b9.jpg'
u'http://farm1.static.flickr.com/248/523531125_25c972c4c9.jpg'
u'http://farm1.static.flickr.com/241/523531123_a7a97bf6e9.jpg'
u'http://farm1.static.flickr.com/249/520338908_b58c519f0d.jpg'
$
on user_id és el vostre (en aquest cas meu) codi d'usuari.
L'API té possibilitat de pujar fotografies, posar-hi comentaris, titol, descripció, etc. I recuperar-ho és també força fàcil, en el nostre exemple:
$ calla = fotos[5]
$ print calla.title
calla
$ print calla.description
fent callar
Serà divertit!
0 comentaris, 0 trackbacks (URL)