Avui he llegit una anecdota molt interessant al blog de Pensamientos Agiles, en un post que parla de llibre col.laboratiu que publicarà O’Reilly: “97 Things Every Software Architect Should Know“.

El text diu:

“Las entradas que hay ahora mismo son realmente interesantes, y por comentar una, la más votada de todas (No pongas tu curriculum por encima de los requisitos) me ha recordado a un Arquitecto de Software con el que coincidí y que no dudaba recomendar el utilizar WebSphere MQ y Coherence para una determinada tarea porque le apetecía aprender esas tecnologías. No cabe lugar a duda de la validez de las tecnologías, pero en este caso estas tecnologías no se escogieron, para suerte para el bolsillo del cliente y para las personas que tendrían que lidiar con éstas y disgusto de esta persona en particular.”

Certament, un cas com aquest tots l’hem trobat. Fins i tot jo l’he viscut en la meva etapa més “junior” on deixant-me portar per hypes del moment he arribat a aconsellar productes que han dificultat el desenvolupament del projecte. Evidentment que en un projecte aprendrem coses, però diguem que no és l’espai més adequat per testar noves tecnologies ja que aquesta formació no és (o no hauria de ser) imputable al client i no dominar les eines ens pot fer errar de bastant les nostres estimacions de carrega de treball.

A part, també hi ha el tema dels recursos humans: Sempre serà més fàcil trobar programadors especialistes en alguna de les tecnologies conegudes que d’altres tecnologies hype del moment.

Actuellement j’ai comme mission la maintenance et évolution d’un progiciel chargé de stocker les différents produits multimédia de mon client. Cet système est développe avec une mélange de technologies dont personne dans chez le client les maîtrise: Java, Spring, Tapestry, CRX, log4j… C’est le problème de faire un appel d’offre, accepter un fournisseur et casser la relation avec lui avant de recevoir un produit fini avec ça documentation. Mais bon: c’est comme ça.

Un des problèmes que j’ai trouvé dernièrement c’est de paramétrer une url via un fichier xml. On a besoin de ça parce que pour le moment on était obligé à livrer 3 versions différents pour chaqu’un des serveurs (recette, preproduction et production). La difficulté étais en faire arriver le valeur à l’interface (Tapestry) et à différents composants.

Finalement ma solution a été la suivant (et pas forcement la meilleur):

1. Utiliser la dependency injection de spring pour lire un fichier XML et créer un Bean simple (getters et setter). J’ai fais l’appel juste après de valider l’utilisateur et le mot pass, dans le fichier .java.

ApplicationContext ctx = new ClassPathXmlApplicationContext("chamin/au/fichier.xml");

BeanLien lien = (BeanLien) ctx.getBean("BeanLien");

2. Avec la URL du lien, initialiser une variable de session crée par Tapestry.

setLien(lien .getLien());
...
// getters et setters en abstract sont implémentes pour Tapestry automatiquement
@Persist
public abstract String getLienBOPRO();
public abstract void setLienBOPRO(String value);

3. Utiliser la variable dans le templates via ognl.

<a jwcid="@Any" target="_blank" href="ognl:lien">

4. Configurer le fichier .page pour pouvoir utiliser la variable lien.

<property name="lien" persist="session"/>

Je ne sais pas si cela est la meilleur solution mais pour le moment ça fonctionne. Le grand problème avec Tapestry est d’arriver comprendre l’architecture pour pouvoir faire de choses un peu plus complexes.

Disclaimer: je comprend que c’est article-la peut être de la charabia pour un personne non-technique mais je l’ai écrit surtout pour moi et pour me souvenir en un avenir au même temps que pratique mon français écrit.

Aquest és el missatge que porta martiritzant-me tota la setmana. Aparentment tenim alguna part del codi mal feta, on no tanquem els fitxers oberts, però per més que ho reviso, la veritat és que no trobo res.

L’unica possibilitat està en l’utilització de la llibreria vfs d’Apache que l’utilitzem per llegir uns fitxers enzipats. No sabem si és que quant obrim un zip de mes de 500 fitxers, per a començar atractar-los, aquest son comptats com a fitxer obert pel S.O.

Però el que és més curiós és que el mateix codi s’ha provat en diferents maquines, inclòs una màquina de pre-prod que és una replica exacte de la màquina de producció i aquest funciona correctament.

Tanmateix em queda una llarga jornada demà monitoritzant i retocant diferents parametres que podem trobar a /proc/sys/fs/ del linux.

En concret interessent els fitxers file-max (nombre maxim de fitxers oberts) , file-nr (fitxers oberts actualment) i d’altres fitxers sobre inodes…

Buff ja veurem.

Fa uns dies vaig parlar en un altre post sobre la usabilitat de les webs on es demana registar-se per a utilitzar el servei.Avui he trobat un enllaç a Get Elastic, un blog d’e-commerce on es parla una mica més sobre el tema. A la secció d’articles relacionats es poden trobar altres posts molt interessants.  

Aquest cap de setmana vam estar filosofant amb el Xavi via gTalk sobre el tema de l’autenticació en webs. Si, ja se que molts pensareu que és un tema molt “apassionant” ;-p però la veritat és que a mi m’interessa i que a tots aquells que utilitzen regularment serveis d’internet i els agrada provar-ne de nous, els hi afecta d’alguna manera o altre.

La qüestió és que trobo que s’abusa del registre d’usuaris a internet i que per utilitzar la gran majoria de serveis web, per molt petits que siguin, se’ns demana un usuari i un password com a mínim. Entenc que hi ha serveis, com el correu web o els servis de pagament, on l’autenticació és necessària a la vegada que bàsica, però quina és la raó per obligar a registrar-nos per accedir a un fòrum o posar un anunci, per exemple.
Algunes de les raons que s’esgrimeixen són:

• Evitar l’spam. Un registre l’evita? Avui en dia és gratis i molt senzill crear comptes de correu. Doncs no és gens difícil de crear robots que es registrin en sites per a publicar spam. L’única cosa que ho evitarà serà passar filtres.
• Evitar estafes. Pel mateix argument que he dit en 1, qualsevol persona pot crear N identitats a inet, per tant, un registre no et garanteix ni soluciona res.
• Saber que qui escriu és realment qui diu que és. Estic d’acord en aquest argument però no en tots els casos. Estic d’acord que en sistemes on es fomenta la reputació o el “karma” dels participants es protegeixin els noms dels usuaris sota un registre, però aquesta no hauria de ser la única possibilitat de participació. Quantes vegades hem hagut de registrar-nos en un fòrum per a poder fer una pregunta especifica un dia puntual i no hem tornat a entrar més?
• La base de dades d’emails és un negoci. Pel punt anterior, les bases de dades d’emails generals serveixen de poca cosa a no ser que et vulguis dedicar a l’spam. Llavors segur que la teva web deixa de ser visitada.
• Millor seguiment dels usuaris. Perquè? Si aquest poden crear-se múltiples identitats, al final si els vols identificar has d’acabar comparant les ip’s!

Hi ha webs de publicació d’anuncis on només es demana les dades referents als mateix anunci que es vol publicar (sense registre) i dona l’opció de posar un email per si més endavant es vol administrar la notícia. Que pot passar si t’has equivocat en el redactat i no has inclòs l’email: doncs que hauràs d’escriure’n un altre com a cosa més greu.

El que jo proposo és que abans d’incorporar un sistema de registre en el nostre servei analitzem realment si és necessari o no. Moltes vegades es pot deixar l’acces obert per aquelles visites esporàdiques i per enganxar a la gent en l’us del teu aplicatiu, i un sistema de registre per a usuaris mes avançats (no dic “premium” per les connotacions de pagament que comporta). La diferència és que serà l’usuari qui voluntàriament és voldrà registrar en el nostre servei perquè realment li aporta alguna cosa i no el sistema que l’obliga a ser-ne membre per a poder entrar i veure que hi ha.

Per cert, avui l’Enrique Dans parlava de l’OpenID que seria la següent etapa un cop haguéssim decidit que el nostre aplicatiu necessita un registre: un servei de registre únic, obert i descentralitzat. Recomano la seva lectura.

Properament a http://www.geoditia.com

Ja fa uns mesos que em vaig obrir un compte a Second Life per provar que tal estava i tot i que no em va decepcionar ja que no m’esperava massa cosa, tampoc em va semblar la panacea tal com sortia publicat als mitjans de comunicació.

Tot i així si que em va agradar el concepte de mon obert on qualsevol persona pot desenvolupar continguts i crear els seus tinglados com ho faria a la vida real i a sobre poder guanyar diners Linden que per més història, son intercanviables per diners reals.

L’altre dia visitant una llibreria tècnica aquí a Paris, vaig veure que hi ha publicats diferents llibres sobre el món SL tant a nivell tècnic com a llibres per emprenedors a Second Life.

Això, junt amb l’article de l’Enrique Dans sobre la publicitat on-line m’han fet que una idea que em rondava pel cap prengui cada vegada més força: un tipus de publicitat dins del mon de Second Life en forma de roba atractiva pels avatars amb unes característiques una miqueta especials. De moment estic investigant que a nivell tècnic es pugui fer i estic en contactes amb un publicitari per veure si el producte es podria vendre.

Potser la cosa acaba en un no res o potser no, però el que està segur és que aprendré alguna cosa de tot plegat.

Per cert, la fotografia és la de l’avatar que em vaig crear. Els comptes inicials no et deixen fer masses virgueries amb el teu personatge però té la seva gràcia.