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

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