En PHP las cosas se suelen hacer “a manubrio”, cada maestrillo tiene su librillo y se lo monta como puede: includes por aquí, procesar_peticion() por allá…

Sin embargo, hay opciones que, para proyectos medianos o ya algo grandes, pueden ahorrar mucho tiempo y quebraderos de cabeza. Seguramente en proyectos muy pequeños sean más un incordio que una ayuda… pero cuando las cosas son algo serias, conviene mirarlos. Estos son algunos de los que yo he conocido:

- Cake: Es una reacción a Ruby on Rails… intenta plasmar su modo de funcionamiento en PHP, aunque con algunas diferencias e innovaciones. Lo que no me gusta es que no aprovecha las capacidades que le podría dar PHP 5, ya que pretende ser compatible con PHP4. Es su punto débil en mi opinión.

- Symfony: Es similar a Cake, pero para PHP5. Es muy potente, me gusta bastante, aunque no he hecho ningún proyecto gordo sobre él, así que no sé hasta dónde se quedará corto. Su capa de acceso a datos es muy cómoda de usar.

- Zend Framework: Es el oficial de Zend, la gente que “hace” PHP actualmente. Es muy grande, y extremadamente flexible. Lo que ocurre es que no dicta una manera concreta de hacer las cosas… a mi me encanta, estoy haciendo Webs con ella y me parece muy interesante, pero no creo que sea lo más adecuado para principiantes, o para sitios donde no hay nadie haciendo un seguimiento de las metodologías y arquitecturas utilizadas. En realidad, son librerías que sirven para montarte un framework , pero en sí yo no lo consideraría un framework como otros.

- Dreamweaver: No es un error. Creo que Dreamweaver, con su modelo de servidor PHP_MySQL, sus asistentes y su modelo de programación, es un “Framework”. Usaría el modelo de servidor PHP_MySQL Dreamweaver para mantenimientos SENCILLOS en páginas de usar-y-tirar: backoffices de webs sencillas programadas a mano sin framework… mantenimientos que no van a sufrir grandes evolutivos… La calidad del código no es buena, pero genera código muy probado y es bastante seguro (al menos en las últimas versiones): quotea entradas antes de pasarlas a base de datos… el manejo de sesión es sensato…

- Prado: Es ASP.NET sobre PHP5. Es un modelo de programación radicalmente distinto, basado en controles y eventos. Se trata de programar Web casi ignorando que se trata de Web. Es útil para intranets, aplicaciones Web (no sitios Web) y cuando hay un background de programación RAD orientada a controles y eventos (especialmente si se viene de ASP.NET). Lo hemos utilizado con éxito en proyectos en el pasado, y el resultado fue muy satisfactorio. Ha evolucionado a Yii, un framework similar que abraza un poco más el modelo “Web”, pero yo prefiero PRADO.

Esos son los que más conozco. De momento, mi elección es Zend Framework para sitios Web, PRADO para intranets y Dreamweaver para mantenimientos usar-y-tirar.

Van a hacer casi 6 meses que estoy en mi nuevo trabajo. El saldo es, hasta el momento, no-bueno. No quiero decir que malo, porque hay cosas buenas (pocas); por ello, diré simplemente que es no-bueno.

De entre las cosas buenas:

• Compañeros
• … creo que nada más

De entre las cosas malas:

• Proyectos
• … nada más

Tan simple como eso. Estoy rodeado de gente mayoritariamente “maja” y buenos profesionales (entre ellos, alguno realmente SOBRESALIENTE en su profesión),  pero los proyectos/clientes en los que participo son horribles y sacan lo peor de mí.

No creo que una cosa pueda suplir a la otra… así que ya veremos.  Lo último que quiero es “echarme a perder” en lo profesional. En este sector, si estás desconectado de lo último un tiempo y las cosas dejan de apasionarte, te quedas descolgado.

Además, si estás haciendo 8 horas al día algo que no te gusta, joer… un día tiene 24 horas… si pasas 1/3 * 5/7 de las horas tu semana (40 horas, vamos) haciendo algo que no te gusta  ¿no es demasiado tiempo perdido?

EEEEEEEEEEEN fin

Volviendo a mis orígenes! Dejo temporalmente la arqueología de software Java para dedicarme a la arqueología de scripts PHP que ni el peor de los diseñadores metido a programador podría soñar en hacer tan mal :))))

Desde el año 2000 (bastante antes, en realidad) llevo en el mundo profesional en las tecnologías de la información, en todas sus variantes: cacharrería micfroinformática, sistemas, programación, análisis, arquitectura, gestión de proyectos, dirección de un departamento de sistemas…

En todo este tiempo puedo decir que he tenido suerte: me ha apasionado mi trabajo. No me importaba que fuera domingo (o me importaba poco), porque no me importaba ir al día siguiente a trabajar. De hecho, en ciertos momentos, me encantaba.

Y llegó el ocaso. Hace poco comencé una nueva aventura profesional. Me decidí por ella porque me creí el proyecto, y me gustaron las perspectivas. Además, podía servirme de “puente” hacia pastos más verdes todavía. El tema pintaba muy bien, pero…

… Nada más lejos de la realidad: me dedico, en vez de a participar como actor privilegiado en el modelado de una arquitectura SOA para una empresa de referencia en su sector (los planes iniciales), me dedico a rebuscar y escarbar en software hecho (y muy mal hecho, la verdad) hace muchos años, probándolo sobre plataformas nuevas y añadiendole funcionalidades.

Supongo que todo esto tiene mucho valor de negocio para el cliente de mi empresa, pero para mi no tiene ninguno: me aburre, me hastía, me echa a perder y me hace ir a disgusto a trabajar.

Tras pensar mucho al respecto, he llegado al convencimiento de que la única forma de que me sienta bien con mi trabajo es trabajar en algo que tenga tanto valor para mí como para el cliente. Esta reflexión, mirando hacia atrás, tiene sentido: las épocas más productivas de mi carrera (y más divertidas) eran aquellas en las que, primero, me gustaba lo que hacía, y, además, tenía impacto directo sobre el negocio del usuario (fuera quien fuera éste)

Por ello, mis objetivos a partir de ahora van a ir en esa dirección. Tengo que encontrar un proyecto (ya sea en mi actual empresa ó fuera de esta) que me interese en ese sentido tanto como pueda interesar al “cliente” (interno, externo, yo mismo… who knows). Donde la tecnología tenga impacto en el negocio, donde el efecto “Wow/guau” pueda tener lugar, y donde pueda estar en la primera línea (no en la trastienda) sin dejar de hacer lo que me gusta.

Se aceptan propuestas!

¿Cómo se te ocurre dejarme escribir en tu blog…? Tú te lo has buscado.

Lo que parece que se va a llevar ahora, tras la era de la justificación de la monetization de cualquier proyecto con presencia web mediante funcionalidades asociadas a las redes sociales es nada menos que el CROWDSOURCING. Jeff Howe, editor de Wired ha publicado en Julio de 2008 “Crowdsourcing. Why the power of the crowd is driving the future of business “. Mas información en su blog.

Mientras espero que me llegue el libro, sobre el que no puedo opinar todavía, he podido ver los fantásticos vídeos que Jeff Howe y Wired han hecho para promocionar el libro, a su autor y sus conceptos. No te los pierdas; muuuuyyyy profesional. Resumiendo: Jeff se dedica a convencerte de que los ejemplos de las comunidades virtuales como iStock y otros servicios como etsy - venta de cosas hechas a mano- demuestran que el poder está en la masa apasionada y entregada a sus hobbies, capaz de transformar una actividad laboral más o menos estándar en un negocio bastante respetable a partir de una “llamada abierta” e “indefinida” a la comunidad de enganchados al tema. El outsourcing a la crowd, vamos. Jeff ya se dedica a recorrer el mundo firmando ejemplares y dando conferencias.

¿Será éste el próximo palabro que los business consultants adoptarán e incluirán en sus ppts para que llenemos nuestros proyectos de iniciativas de crowdsourcing? Pues parece que tiene bastantes números, después de la web 2.0 y las entelequias acerca del valor de las social networks, aunque esto suene a comunidades virtuales de las de toda la vida, pero de las que funcionan y reparten $$$.

Es un gran palabro, sin duda. Jeff va a dar muuuuuchaaaas conferencias.

Propongo una cosa: Anotemos el tiempo transcurrido desde hoy hasta que nos encontremos el palabro en una presentación. ¿Cuánto crees que tardará?

Cuando un post en theserverside.com obtiene más de 100 comentarios, quiere decir que algo pasa. O se han enganchado los de JBoss a discutir con los de Spring, o la comunidad se ha puesto a rajar viva al visionario de Tapestry, o cosas así. Todos estos asuntos no suelen acabar teniendo la mayor trascendencia, pero éste último sí que la puede tener, en mi opinión:

http://www.theserverside.com/news/thread.tss?thread_id=50727

Esta vez es algo que nos afecta a muchos de los que apostamos en su momento por una estrategia de desarrollo más sensata, sencilla, fácil, testable e integrada, y nos decidimos a usar Spring.

Para quién no lo conozca, Spring es un framework con cuatro áreas funcionales bien separadas en mi opinión:

• Proveer un Contenedor IoC (Inversión de Control), para hacer desarrollos más testables y menos acoplados, y aumentar la cohesión del código. No interfiere en el código de la aplicación
• Proporcionar funcionalidad transversal no de negocio, tal como transaccionabilidad, “tuberías”, mensajería, remoting… No interfiere en el código de la aplicación, normalmente (puede hacerlo).
  
• Proporcionar clases base, templates y herramientas para facilitar el uso de tecnologías Java comunes (JMS, JDBC, JCA…) Sí interfiere en el código de la aplicación
• Proporcionar frameworks completamente dedicados, como el Spring MVC. Obviamente, sí interfieren en el código de la aplicación.

Spring es modular y uno puede elegir si usa uno u otro módulo sin problemas… lo que ocurre es que cuando uno decide usar uno, es más fácil que se acabe usando otro y otro… haciendo de Spring al final una pieza fundamental en la aplicación.

Lo que ha ocurrido para revolucinar tanto a la comunidad de desarrolladores y arquitectos es que la empresa propietaria de SpringSource (antes interface21) ha publicado una nueva política de liberación de versiones, que restringe a los usuarios sin contratos de mantenimiento el acceso a los parches incrementales de las versiones no “current” a únicamente tres meses.

Es decir,pongamos que yo uso Spring 2.0.2 en una aplicación que lleva N meses en producción, y la versión actual es Spring 2.5(.1), desde hace más de tres meses. En esto, me aparece un “bug” en la aplicación debido a un fallo en Spring 2.0.2. Me dispongo a arreglarlo, pero al no tener contrato de mantenimiento no tengo acceso a la versión corregida 2.0.3, sino que tendría que actualizarme a Spring 2.5.2. Obviamente, si tengo esta aplicación en producción, me hará muy poca gracia cambiar de versión “major” del framework sobre el que he desarrollado mi aplicación.

Los “mantenimientos” tienen sentido en algunas cosas… pero en el framework de inversión de control de tu aplicación? es rizar el rizo… y qué hay de las aplicaciones que usan spring y tienen su propio modelo de licencias? ahora debes incluir también a spring en el stack a licenciar y mantener por el cliente (oracle + sistema operativo + cluster + servidor de aplicaciones + mi aplicación + el framework de inversión de control) ? No se si es muy lógico…

Imagino que interface21 está intentando “capitalizar” la ubiquidad de su framework y rentabilizar la inversión (enorme) que ha hecho en  él, pero no sé si es la mejor manera. Ahora, muchos de los que usabamos Spring extensivamente, y que lo hemos hecho tan popular, vamos a pensarnoslo muy mucho antes de volver a elegir la pastilla roja y volver creer en una empresa que hasta ahora había sido un bálsamo para la comunidad de desarrolladores Java. Spring seguirá teniendo una calidad técnica excelente y una cantidad enorme de seguidores, pero esto va a allanar el camino a otros frameworks, como los EJB 3.X estándar, Seam, o Guice.

Yo voy a ser conservador, y si tengo que acometer nuevos desarrollos en Java seguiré confiando en Spring, pero lo haré como se debe hacer: sin casarme con él, utilizando sus funcionalidades transversales y “de contenedor”, pero sin permitir que contamine mi código; o si lo permito, me preocuparé de encapsularlo bien y acotarlo defensivamente para que aparezcan “imports” de org.springframework sólo en sitios concretos.

Lo hare así porque las alternativas no están al nivel adecuado, en mi opinión. Con EJB 3 tienes mucho pero no “todo”… EJB 3.1, cuando venga, será una gran mejora e igual sí permite plantearse confiar únicamente en estándares (ya veremos)… Seam aporta mucho (los scopes conversacionales son una gran idea) pero no me convence del todo su modelo, y además, al usarlo, uno se casa con él más que con Spring… y por último Google Guice es demasiado sencillo, no tiene todo lo que uno necesita, “contaminas” el código con montones de imports para las anotaciones y además tiene carencias importantes en el modelo de componentes basado en clases en vez de en objetos con “id” o “nombre”.

En fin, veremos como se suceden los acontecimientos

Aixó mateix!

Esta semana he decidido retomar mi blog.

No vale la pena adentrarse en los motivos del parón, dado que esto no lo lee nadie y por tanto sería perder el tiempo; tan sólo diré que hay que saber poner límites al trabajo y no dejar que se “coma” el espacio personal no-profesional que todos deberíamos tener.

El caso es que vuelvo, en breve empezaré a escribir de nuevo sobre las frikadas y rayadas que se me ocurran. Podría empezar por ejemplo pelando de nuevo a Velneo, pero todavía no ha salido la V7 esa famosa, así que no hay mucho nuevo que decir… tan sólo que tengo sinceros e inocentes deseos de probar su nuevo engendro.

También podría empezar a hablar contando mi opinión acerca de las empresas cárnicas-serrano-bodyshopping, con las que tanta relación he tenido en los últimos meses, pero me canso solo de pensar en mi ex-trabajo… si, ex-trabajo! Hace 2 jueves acabé en mi trabajo de los últimos 4 años… y estoy más agusto que un arbusto!

Pues eso, que ya veré de qué hablo

Si alguna vez necesitas importar/exportar archivos en .NET, un tío muy majo llamado Marco y sus amigos te hacen la vida mas fácil con una librería llamada FileHelpers (http://www.filehelpers.com).

Esta librería permite importar y exportar registros, que se definen como clases .NET (VB.NET o C#) con anotaciones. Importa/exporta a ficheros de texto delimitados por comas, por tabulaciones, ficheros excel, bases de datos SQL Server, OleDB genéricas, Access…

Es una gozada. La importación/exportación Excel requiere tener instalado el Excel en el servidor, pero la próxima versión no tendrá esta necesidad, lo que hará todavía mas útil este pedazo de software.

Sólo le veo una pega de diseño… no te permite definir “mapeos” complejos, con lo que las clases que definas deberías usarlas solamente como DTOs entre la capa de importación/exportación y el resto de tus capas (bueno, sólo si eres un quisquilloso de las arquitecturas de software como lo soy yo).

Por lo demás, un gran trabajo. Lo usamos a base de bien en uno de nuestros proyectos, y seguro que más adelante seguimos usándolo… se ha convertido en una herramienta básica para mi y para mi equipo.
Ah, es gratis y de código abierto

Viendo blogs ajenos me he encontrado con un post genial, que creo que ejemplifica muy bien (y critica, jeje) la realidad de muchos entornos laborales. Aquí lo dejo para quién le interese: http://epsilondelta.net/2006/10/19/are-you-on-a-pleasantville-team/

Hoy hace 2 semanas compré 3 libros por internet que siempre me habían llamado la atención pero que nunca me había animado a leer… Se trata del ciclo de trántor, los tres primeros libros de la saga de fundación de Isaac Asimov. En la wikipedia hay algo de info de ellos… http://es.wikipedia.org/wiki/Ciclo_de_Tr%C3%A1ntor. El caso es que no me llegan, porque les falta el segundo y lo han pedido a la editorial.

Exijo q me lleguen! los quiero! me he encaprichado !

Y por fin sale Spring 2.0 (http://www.springframework.org); El framework que ha cuestionado el stack J2EE, que ha popularizado patrones tan básicos hoy para todos como la Inversión de Control o la programación orientada a aspectos, o que ha hecho mucho más fáciles de usar y accesibles un buen montón de frameworks y tecnologías.

Es la leche, en serio, si programas en Java tienes que conocerlo. Y si no programas en Java, también, la versión .NET (http://www.springframework.net) es mucho mas simple y menos avanzada pero lo mas básico (la IoC y la AOP) funciona bien.

La versión 2.0 trae una característica nueva que me pone cachondo, y es que te permite definir tú nuevos manejadores de ciclo de vida de los beans java… la de cosas chulas que voy a poder hacer con esto

Parece que mejora también el soporte de JMS… una de las tecnologías más majas del J2EE, dulcificada y simplificada por Spring.

Lo que no me gusta demasiado - o no me gustaba en la 1.2, tendré que verlo mejor en la nueva - era su framework Web, Spring MVC. Hoy día quiero pensar que los frameworks Web deben aportar un manejo de estados sensato y un modelo de componentes de interfaz de usuario potente (en plan ASP.NET, JSF, Tapestry, PHP Prado…). No para todo ni en todos los casos, está claro, los frameworks estilo “model 2″ como Struts o el Spring MVC aun tendrán su mercado… pero para el 95% del desarrollo J2EE que se hace por ahí, considero que es un estilo anticuado. Si la gente de Spring se “mojara” más con Wicket, Tapestry, JSF y demás… uhmmmM

Puede que este post resulte algo hiriente para cierto colectivo de gente, usuarios de la plataforma que voy a rajar viva. Me da igual, estoy harto de ella y es mi blog, así que posteo lo que me da la gana. Además, no entiendo el sectarismo seguidista que hay hacia esta plataforma.
Empiezo. La mayoría de los que leáis esto no conoceréis un conjunto de “entorno de desarrollo + base de datos + servidor de aplicaciones” llamado Velazquez Visual, recientemente rebautizado como “Velneo” (De “neo” nada, sigue siendo igual de castaña que en el 96).
Velazquez/Velneo es un entorno de desarrollo visual, que integra dentro una base de datos bastante rapidilla (tan rápida consultando como lenta en recuperarse cuando casca). La idea es muy interesante, y hay que reconocer que la base de datos incorpora abstracciones de alto nivel que para modelos de aplicación orientados a registros, tablas y filas (sí, eso tan de los 90) resultan interesantes (Singular del plural, hermano contiguo, historicos y alguna cosilla mas). Además, al estar todo integrado, en teoría debería dar pocos problemas, y para cosas sencillas sería una buena solución, no? NO. ERROR. No hay que caer en el error de querer hacer más fáciles de lo necesario ciertas cosas, y en el mundo velazquez es todo tan mágicamente fácil y tonto que te hace sospechar.. con razón.
Primero te acercas a Velneo con curiosidad. Además, es software español, y hay que dar una oportunidad a la industria del software patria, que tan mal está…

A primera vista es pontentillo pero limitado: Permite hacer cosas sencillas muy rápido, pero hay que dar *MUCHAS* vueltas para hacer otro tipo de cosas, muy sencillas de resolver en un entorno de desarrollo tradicional. Y como quieras integrar algo externo, olvidate de COM, ActiveX, DCOM, .NET y cualquier otro modelo de componentes o middleware moderno: Solo tienes DLLs “stdcall” puras, “a la antigua”… ahí, ahí, como los hombres de verdad.
Profundizas un poco y empieza lo incomprensible, empiezas a ver que algo no encaja y que el entorno solo sirve para hacer aplicaciones poco integradas con el mundo exterior… con un modelo de datos irremediablemente pegado a una aplicación (Cuando está demostrado que el modelo de datos casi siempre sobrevive a la aplicación)… con unas herramientas para hacer tu trabajo útiles pero imposibles de extender… no se, un entorno que para cierto tipo de aplicaciones lo podrías hasta considerar, pero que ni de lejos va a desplazar lo más mínimo a los “stacks” típicos Java, .NET, Windows DNA, LAMP o entornos Host. No tiene capacidad para ello, sencillamente.
Al final te hartas. Te hartas de:

- Programar Webs de la forma más friqui, estúpida e improductiva que has visto nunca. Te parecerá que el ASP de antes era avanzado comparado con esto.
- No poder acceder a la base de datos más que a través de tus “mapas” Velneo (un “mapa” es una aplicación + una definición de modelo de datos + alguna cosa más).
- No poder extender por donde quieras tu programa, ni usar un modelo de componentes , ni aplicar patrones y buenas prácticas estándares para el desarrollo de aplicaciones.
- Funcionar con nomenclatura estúpida, metodologías y patrones imbéciles y conceptos artificialmente diferenciados de los estándares.
Pero sobre todo sobre todo, te hartas de la CASTAÑA que resulta ser el servidor de aplicaciones. El servidor de aplicaciones es lo que sirve tu base de datos, tu Web y tu aplicación. Es algo así como un SQLServer+IIS+entorno de WinForms, si lo comparas con .NET. Todo ello por un protocolo propietario y maravilloso llamado VATP que los de velazquez se vanaglorian de haber hecho lo suficientemente distinto del resto de protocolos que la IANA les ha asignado un número de puerto.

Eso si, tanto avance tecnológico (según ellos) y no son capaces de separar servidor de administración, por lo que el servidor no puede correr como servicio de Windows y tienes que tener el escritorio “logueado” para que funcione, con el velazquez ahi minimizadito. Muy avanzado, sí señor, de la época de windows 95
Lo peor de todo, dentro de lo malo que es casi todo lo referido a este entorno, es que el servidor de aplicaciones tiene la mala costumbre de caerse. No se cae por una aplicación mal programada, no. Se cae porque está Mal Parido. Además, una aplicación no puede tirar a su contenedor (como mucho por falta de recursos… y me parecería mal), lo digan los de Velneo o quien sea, me da igual.
Imagina que tienes una aplicación Web corriendo sobre un servidor de aplicaciones JBoss y una base de datos Oracle. Imagina que tu aplicación está tan tan mal programada que consigues tirar al JBoss (complicado de conseguir, pero bueno, pongamos que tienes poca memoria y lo consigues).
Bien, se ha caido tu JBoss y tu aplicación no funciona. Pero… afecta eso a tus datos? Yo diría que no. Tu Oracle sigue viva? A ver q mire… Si, no? Y levantar el JBoss es cuestión de un par de comandos y pocos segundos… menos de un minuto y la gente sigue trabajando (eso si no lo tenías en cluster, cosa que Velneo ni conoce ni conocerá).
Pues con Velazquez/Velneo NO. Con velazquez se cae tu servidor de aplicaciones y en un porcentaje muy elevado de las ocasiones, si había alguna transacción en marcha (y suele haberla porque suelen quedarse pilladas), tu base de datos empezará a reconstruirse. Si tienes muchos datos puede tirarse horas y horas reconstruyendo índices y áreas de datos. Porque él lo vale, si señor (para qué aplicar un WAL? Claro que así igual la base de datos no sería tan rápida… anda!)
El caso es que ese día puedes dar vacaciones a tu gente, porque no van a poder trabajar con la aplicación. Ni consultar un solo dato. Ni siquiera manualmente, dado que no puedes lanzar consultas a la base de datos.
No se, en ciertos entornos elegir un sistema que te deja tan indefenso y que falla tan estrepitosamente y tan fácilmente, sería un buen motivo de despido.

Scenario: R&D area in a small voice&data carrier. Being a telco, we consider ourselves a heavy UNIX (& Java) shop. We’ve developed many in-house tools and applications in unix, java and some script environments which work reliably and reasonably well. Actually, these systems are mission-critical components in our company’s revenue chain, and we’re quite happy with them.

In such a scenario, why would we want to try .NET in our next project - a web-based telco billing app?

Our new project constraints:

• Short time-frame for development: Our current platform is causing lots of organizative problems and has many technical shortcomings, so we do have to get rid of it as soon as possible.
• Our app should have a heavy, rich and responsive web-based ui. We have branch business offices over all the country, but only a central location with 24×7 support, disaster recovery facilities and a really good datacentre infrastructure, so going Web seems natural for us.
• We’re a very small team (4 people).
• Our app has to be very scalable.
• Our app has to be easily maintainable. In the past the company invested a lot of time and money in tools which finally we weren’t able to maintain and extend. Thus, we emphasize in having a loosely-coupled well-defined architecture which doesn’t compromise current or future needs.
• It is a critical app, but not a 24×7 app: if our app isn’t available during five minutes we don’t lose any income. That isn’t the case of many of our other in-house unix&java applications!

Having these constraints we could have gone the Java way, but what kind of Java way?

• Traditional J2EE+Struts stack? No Way. We’re three people here, so we have no time to spend creating lots of XML, deployment descriptors, JSPs and all these dot-com-era artifacts. Also, we wanted to use a component-based UI development. Developing in such enviromnet would have been so 2000′ish…
• New JEE 5? No way. When we started our project (June ‘06) it was simply not mature enough. Also, the tooling it has isn’t good enough for considering it real RAD. JPA is quite limited, too. In addition, while JSF is component-based, developing custom compound components for it is a real pain.
• Alternative frameworks (Spring+Hibernate+Wicket/Tapestry/Echo2)? This was a good option. I really like Spring (not as MVC fr., tought) and Hibernate. In fact, sometimes when I suffer from VS2005’s instability, I wish I had choosen this path. But one of our constraints was that we had a short time to market,and these UI frameworks require heavy investment in development time to create the rich components we’d need. Had we have more time, I’d probably have choosen this path, in order to develop our custom rich ui components instead of buying them from 3rd parties (telerik rocks). It’s a pity there isn’t a market of commercial components for - at least - Tapestry or Wicket.

We could also have gone the scripting way, but… which one?

• PHP5+PRADO (http://www.pradosoft.com): We have used this in some other (smaller) projects. Devel time is quite good, and the PRADO component-based framework allows following an easy development workflow for the UI. But what about the back’end? PHP ORM tools are very simple and I don’t like any of them. The one I’d like the most (EzPDO) has a ‘feature’ which makes me forget about using it: it uses custom tables for relationship, instead of trusting DB foreign keys. Then we tried code-generating a DAO layer. We achieved a good level with custom code-gen tools, but that wasn’t a real ORM. Right now, we don’t conceive developing our app without an ORM, so we finally had to discard PHP.
• Ruby on Rails? Let me check… not component-based UI, not real ORM (ActiveRecord pattern is great but not real ORM)… scaffolding doens’t work with foreign keys and inheritance (our custom code-gen tool does)… discarded

So, we finally came up with a solution which - more or less - is what we’ve been looking for:

• .NET Framework 2.0
• ASP.NET
• NHibernate (!!)
• SQL Server 2005 (including Reporting Services)
• Spring Framework.NET (!!!!!)
• Telerik Component Suite (!!!!!!!!!!!!!!)
• MSMQ (async processing)
• Java-based custom code-gen tools

We’re really happy with this environment.

I don’t like traditional .NET architecture, it seems ackward if you’re coming from a Java background. But I really like ASP.NET’s component model. It’s easy to understand, and it’s very easy to develop components on it.

In addition, C# 2.0 is good enough. I preffer Java 1.5 (I hate having to declare methods virtual all the time), but C# 2.0 has really good generics support, and delegates are good too (I still preffer anonymous classes, but).

By using Spring.NET we’ve achieved a very loose coupling between layers. By using NHibernate, we’re coding against an object domain model and not against a relational model. We’ve also achieved 97% database independent code (still some SQL in a few modules). And we have a rich domain model which hasn’t any pollution (persistence code, forced inheritance).

By using Telerik Component suite, the person which develops the UI here has been able to create really good screens. Our app is very responsive and easy to work with.

By using SQL Server 2005 we get a quite good database. I don’t like the fact that it hasn’t deferrable constraints, but its partitioning feature is quite good. Also, analysis services and reporting services are a bonus we’re happily taking advantage of.

Finally, MSMQ is a good-enough easy-to-use JMS-alike message oriented middleware, which we use for async, deferred and/or scheduled processing. We’ve suffered from some annoying .NET generic collection serialization problems, but these have been solved easily, and in the future we’ll try to enlist SQL 2005 and MSMQ transactions in a global transaction to achieve almost-JTA reliability.

So, we’ve sold our soul to the devil. We’re Unix&Java guys who have gone the .NET way! I guess our app won’t scale the same as a Java solution would. Also, our app has been developed from scratch… it doesn’t need any integration to legacy datasources, two-phase commits, strange messaging integrations or connecting to foreign EIS’s. If it needed such features, going .NET would have been insane.

Quien vea nuestros proyectos en .NET, enseguida adivinará que venimos de un fuerte “background” Java… En parte por el estilo de programación (contrato contra la interfaz siempre) pero sobre todo por los frameworks y patrones que usamos. Uno de ellos es un framework de ORM (Object-Relational-Mapping) llamado NHibernate, que es un port de la versión Java (Hibernate).

Un Framework de ORM es algo que suena a complicado cuando te lo explican, pero es brutalmente simple cuando ves un ejemplo:

Pongamos que yo tengo la tabla PERSONA (PERSONA_ID, NOMBRE) y la tabla DIRECCION ( DIRECCION_ID, PERSONA_ID, TEXTO_DIRECCION), con sus PKs correspondientes.

Con .NET, tradicionalmente me crearía DataSets, DataReaders, Commands y Connections para acceder a la base de datos. Sin embargo, con cualquier ORM de Java o .NET, lo que haría sería definirme las clases de las dos entidades, las mapearía con unos ficheros XML cada una a su tabla, y trabajaría únicamente con Objetos.

Las ventajas de esto son varias. Por un lado, el código de los objetos no depende de la capa de acceso a datos (NHibernate), por lo que tenemos menos acoplamiento. Por otro, no ensuciamos las distintas capas con cosas que no le conciernen (no devolvemos datasets a la capa de presentación, sino que devolvemos objetos — separation of concerns lo llaman los guiris).
Pensar en objetos que ya están relacionados estáticamente es mucho más sencillo que pensar en conjuntos de datos y tablas de base de datos cuyas relaciones se crean desde la misma consulta mediante joins. Esto se nota mucho cuando vas a hacer consultas con NHibernate. En NHibernate el lenguaje de consultas principal no es SQL (aunque se puede utilizar, con algunas restricciones), sino que es uno propio llamado HQL. El HQL es un SQL orientado a objetos… esto puede sonar raro, pero ahi va un un ejemplo:

“Obtener Todas las personas cuya dirección contiene la palabra ‘calle’ ”
SQL: SELECT p.* FROM PERSONA p, DIRECCION d WHERE p.PERSONA_ID=d.PERSONA_ID and d.TEXTO LIKE ‘%calle%’

HQL: from Persona p where p.Direccion.Texto like ‘%calle%’

En un ejemplo tan pequeño parece que son pocas las diferencias, pero imagina que el modelo de datos es mucho más extenso…

HQL: from Producto p where p.Catalogo.Temporada.Responsable.Edad<30

La versión SQL crecería y se haría enorme, mientras que la versión HQL se aprovecha de que las relaciones están bien definidas y son estáticas,permitiendo que sea mucho más sencilla,
Además, al usar HQL y ser éste un lenguaje de consultas genérico independiente del motor de BD que usemos ( luego NHibernate lo transforma al SQL nativo de cada base de datos), no hay problemas de portabilidad de las sentencias SQL entre bases de datos. Una misma aplicación hecha con NHibernate puede funcionar sin modificaciones en MySQL y en MS-SQL, sin repetir una sola consulta, incluyendo paginaciones, joins, agregados…
Hay un articulo muy sencillo, un quickstart, que explica mucho mejor que yo todo lo necesario para empezar con NHibernate: http://www.hibernate.org/hib_docs/nhibernate/html/quickstart.html

Me ha tocado integrar en un sitio Web un TPV Virtual de una entidad bancaria española cualquiera.

Hace años, en mi anterior trabajo, vi cómo funcionaba el tema … el funcionamiento era sencillo pero chapucero, y nada previsible. Eran otros tiempos y sólo se valoraba que funcionasen las cosas sin importar cómo… también es cierto que los estándares Web de la época eran otros y bastante anticuados…
Por eso, cuando me he puesto con esto en Septiembre del 2006, esperaba encontrar grandes mejoras. Esperaba encontrar un uso extensivo de los servicios Web, de WDSLs, esquemas XML y de todas esas cosas tan complicadas, aburridas y previsibles cuyo uso se ha generalizado en los últimos años.

Pero NO! eso era demasiado esperar. Me he encontrado con los mismos métodos chapuceros de integración. Un POST por allí, campos hidden mágicos por allá que contienen fechas, números y texto en el formato el-que-a-mi-me-de-la-gana….

A decir verdad, sí que ha habido alguna mejora, pero se la podían haber ahorrado: Un servicio Web SOAP de un sólo método que toma como parámetro una CADENA que contiene un XML (cuyo formato se especifica en un DTD!), y que devuelve otra CADENA con otro XML del DTD: Señores de *******, ¿Para q c*j*nes quieren vds. un SOAP si solo lo usan para añadir un poquito de parafernalia por delante y por detrás al mensaje XML? ¿Por qué no dan WSDLs y XSDs com Deu mana y así facilitar el trabajo de los que implementamos aplicaciones contra sus penosamente diseñados sistemas?
Lo peor es que te instan a usar su “”"”WSDL”"”" en plan “Los comercios que deseen desarrollar un servicio SOAP deben ajustarse a esta WSDL. A partir de ella y, mediante herramientas de generación automática de código, se puede desarrollar el esqueleto del servidor SOAP de forma cómoda y rápida“. Collons! si el WSDL solo contiene un “cadena Metodo(Cadena parametro)”!

Es tan “2000′ish” todo esto…

¿ Es sólo la banca española la que acaba de entrar en el siglo 21 mientras los demás llevamos 6 años definiendo estándares, buenas prácticas y patrones de diseño de sistemas de integración? ¿ O la de fuera es igual? Que mal.

Hace más de un año que utilizamos Subversion en la empresa, y hoy día creo que a pesar de ser un equipo de desarrollo pequeño, no seríamos ni la mitad de eficientes si no fuera por él.

Subversion es un sistema de control de versiones; es decir, un sistema de gestión de código fuente que controla las versiones de cada archivo, y agrupa cada cambio a uno o varios archivos en unidades atómicas y transaccionales. Almacena el histórico de cada archivo, de forma que puedes ver siempre el histórico de cambios de todos y cada uno de los archivos del proyecto. Funciona integrado con el Apache o como servidor independiente, aunque yo lo prefiero con Apache por varias razones. Subversion se parió para sustituir a un sistema de control de versiones llamado CVS, muy usado “antiguamente”, pero que tenía muchas deficiencias que subversion corrige:

• Los cambios son atómicos; es decir, o guardas todos los cambios de todos tus archivos en el repositorio al hacer “commit” o no guardas ninguno
• Cuando renombras un archivo del proyecto o lo mueves de sitio (parte del proceso de refactorización), conserva el histórico de cambios (en CVS es como si borraras y crearas otro archivo).
• Subversion es mucho mas rápido; se pretendía que las operaciones masivas sobre el repositorio de código tuvieran un coste constante (con CVS no ocurría asi).
• Subversion puede meter “meta-datos” libres a los archivos (propiedades clave-valor que uno quiera; por ejemplo: “archivoauditadoyseguro: true”

Aquí está la bestia: http://subversion.tigris.org/

Y aquí un tutorial para usarlo en windows con un cliente gráfico muy bonito llamado TortoiseSVN: http://svn.haxx.se/users/archive-2006-05/att-0593/SVN-Apache-SVNNotify-HowTo-En.pdf ( la sección del Perl y del notify os la podéis saltar tranquilamente).

Para integrarlo con Visual Studio: http://ankhsvn.tigris.org

Para integrarlo con Eclipse: http://subclipse.tigris.org/

Para integrarlo en Windows directamente: http://tortoisesvn.tigris.org/

Para integrarlo en Dreamweaver (de $pago$ pero baratito): http://www.grafxsoftware.com/. (Aunque con el TortoiseSVN y las carpetas ignoradas de dreamweaver, si tienes un poco de experiencia con el puedes usarlo sin este plugin sin problemas

Y más cosas sobre subversion en http://www.subversionary.org/, con tutoriales y artículos varios.

Aquí empieza mi Blog. Este es el primer post, y no se si será el último… depende de cómo me dé. El caso es que hace tiempo que tenía ganas de montar un sitio donde “pastear” las cosas interesantes que me voy encontrando, las ideas y opiniones que vayan surgiendo, y también las tonterías que me vaya dando la gana colgar aquí :). Me he decidido a raiz de ver lo “fácil” que le ha sido a una ex-compañera (http://sitiogeek.wordpress.com) montarlo y empezar a postear cosas… me ha dado envidia básicamente
Ah, aviso, tengo cero idea de blogs, así que seguramente haré varias cosas mal, pero me da igual