Entries Tagged 'Programació' ↓

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 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.

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.

Per sortir una miqueta del clàssic top ten, avui faré el top three de les extensions per Firefox, indispensables per a desenvolupar en un entorn web.

• “Firebug”:http://www.getfirebug.com/ :L’extensió ens ofereix tot un set d’eines per debugar les pagines, una consola javascript molt complerta, un navegador DOM… INDISPENSABLE
• “Web Developer”:http://chrispederick.com/work/webdeveloper/ :Aquesta barra ens proporciona infinitat d’opcions com un desactivador de la cache, simuladors de tamanys de pantalla… i fins i tot un editor de CSS a temps real. Es a dir que opts anar fent canvis d’estils i es van aplicant al mateix moment.
• “QuickDeveloper”:http://quickaddons.fastspace.biz/ :Ens afegeix una nova opció al menu d’eines per a poder reiniciar ràpidament Firefox. Molt útil si estas provant extensions.

Avui m’he trobat amb un problema curiós: intentava accedir a una pàgina web des de la funció fopen() del PHP per poder parsejar el codi però aquesta tasca en principi trivial era absolutament impossible amb la URL en concret que volia accedir (amb altres si que funcionava).

El curiós del tema és que des del navegador si que es podia accedir a la web en qüestió.

Quin era el problema? Que d’alguna manera és limitava la conexió HTTP des d’algo que no fos un navegador (que fa conexions GET). Cap problema, la solució era obrir una conexió mitjançant sockets i reproduïr manualment el protocol HTTP.

Quant ho estava fent, he trobat la classe HTTPRequest a la documentació oficial de PHP que precisament fà el que buscava i de forma molt elegant.
Reprodueixo el codi, per si es perd l’enllaç a l’original.
Continue reading →

Després d’uns quants dies de lowblogging (que estic segur que continuaran…) us passo l’enllaç d’un interessant article de la revista Mosaic (de la UOC) on és compara les dues tecnologies presumiblement competidores d’un mateix mercat.

AJAX vs Flash

Tanmateix reprodueixo els pros i contres segons l’autor de l’article, per cadascuna de les tecnologies:

AJAX

Lo bueno:

• Basada en HTML, en realidad en XHTML, por lo que debería ser fácilmente estandarizable.
• Accesible. La integración de lectores de pantalla, las posibilidades de modificar el tamaño del texto por el usuario, etc siguen sin tener comparación en Flash. (Por aquí hay disidencia: ¿AJAX accesible? Si te lee Stevie Wonder se le caen las gafas de sol. La propuesta es quitarlo tanto de aquí como de Flash)
• Integración con CSS. Es, por tanto, bastante sencillo separar datos de presentación, por lo que las aplicaciones son más escalables.
• Ligereza. Se supone que una página con sólo HTML es más ligera que un front-end en flash, aunque en realidad el Javascript necesario para funcionar no es tan ligero, por lo que finalmente se depende de mecanismos de caché en servidor.
• Javascript. Lenguaje interpretado en el navegador, sencillo, orientado a objetos (según a quién se le pregunte), especialmente orientado a manipular el DOM de las páginas.
• Motores de búsqueda. Al basar los interfaces en HTML, son fácilmente indexados por los motores de búsqueda. Siempre y cuando su contenido no sea producto de una petición de datos a servidor, claro está.

Lo malo:

• El usuario puede haber deshabilitado el Javascript en el navegador.
• Se depende de un objeto propiedad de Microsoft para las comunicaciones asíncronas. Lo malo de esto no es que ese objeto sea propiedad de Microsoft o de cualquier otro, sino que es propiedad de alguien.
• No es tan ligero como parece a primera vista.
• Burdo. Por mucho que se intente, el resultado final no es comparable al de una web en Flash.

Flash

Lo bueno:

• Player casi universal. Prácticamente todos los ordenadores del mundo lo tienen instalado, aunque eso no implica que el usuario de un ordenador en concreto tenga instalada la última versión del mismo, ni que no lo haya deshabilitado utilizando alguna extensión del navegador.
• Calidad visual. Sobre todo con el avance en el manejo de los textos en las últimas versiones del player de Flash.
• Animación, multimedia. La única forma solvente de incluir animaciones, contenido interactivo, vídeo, audio.
• Lenguaje de programación de alto nivel orientado a objetos, aunque también sea interpretado en el player.

Lo malo:

• Se depende de un plug-in, propietario.
• Se tiende a abusar de las animaciones.
• Integración con el botón de volver del navegador no es nada sencilla.
• Poco accesible, a pesar de que las últimas versiones de Flash suponen una mejora sensible en este aspecto.
• Está inevitablemente unido a dos cosas: el botón de “Skip intro” y los banners abusivamente invasivos.

Via Planeta Codigo he trobat un article que t’explica amb exemples, diverses tècniques d’SQL Injection. Per qui no sapiga el que és, només dir que és un tipus d’atac a formularis web que s’utilitzen per accedir a una base de dades (per exemple, el formulari del Google) i que permet executar codi arbitrari.

Per més info, llegiu l’article. Molt interessant