Cuando comencé este blog como continuación de mi viejo blog uno de mis propósitos era poner muchas más entradas sobre mi ciudad natal, Betanzos. Pero la verdad es que con el cambio de ciudad, ahora estoy mucho más alejado de mi ciudad (sí, desde el 1467) de lo que me gustaría.
Por suerte hay una serie de recursos en Internet que ya hacen el trabajo por mi, y me mantienen actualizado. el pasatiempo es probablemente uno de los más actualizados, con posts bastante frecuentes. A partir de ahí, hay otra serie de blogs con diferentes contenidos. Podría recopilarlos aquí, pero ya lo han hecho por mi.
El caso es que no deja de ser curioso como el movimiento de los blogs, reciente donde los haya, ha hecho aumentar exponencialmente el número de páginas relacionadas con Betanzos, cuando hace varios años se contaban con los dedos de una mano. Aún más curioso es ver como muchos de los blogs tienen una clara tonalidad política, para un lado, para el otro, o para el medio. No es algo que me moleste especialmente, aunque sí que confieso que no leo ese tipo de posts.
En fin, de cualquier modo aprovecho para desearos a todos los que os pasáis por aquí un Feliz Año 2007. Por mi parte toca ir a cenar ya, tomarse las uvas, y un año más salir por una de las mejores ciudades (sí, desde el 1467) españolas para celebrar el fin de año.
¡Feliz 2007!
domingo, diciembre 31, 2006
miércoles, diciembre 27, 2006
Cuatro años bloggeando
miércoles, diciembre 27, 2006 por Martín
Pues parece que sí, llevo ya al menos cuatro años bloggeando. Leyendo el siempre interesante weblog de Aitor, me enteré de que él lleva cuatro años bloggeando. Tras eso me entró un poco la melancolía recordando todo lo hecho en los últimos años, los congresos, las charlas representando a javahispano por España, los proyectos iniciados en jh, los que salieron bien, los que salieron mal, y todas estas cosas.
El caso es que al final me pregunté: Y yo, ¿cuánto tiempo he estado bloggeando? Y cual fue mi sorpresa al descubrir que ¡mi cuarto aniversario fue ayer! La verdad es que no me esperaba que fuese hace tanto tiempo, pero se ve que el tiempo pasa muy rápido. Mis comienzos fueron curiosamente (no creo) los mismos que Aitor, pidiendo de prestado en freeroller.net. Mi final, sigue siendo de prestado pero ahora en blogger. Mi camino es mucho menos traceable que el de Aitor porque siempre ha sido muy irregular, de hecho he alternado blogging en inglés y español, y en diferentes servidores. Atrás queda un ya irecuperable blog en blog-city (¡no me acordaba de eso!), otro en javahispano, otro más, éste en inglés, en jroller, otro que está ahora mismo en estado de coma en blogspot (el hermano de éste, pero en inglés), y por último éste que estáis leyendo.
Que emocionante leer los posts de hace cuatro años. En cierto modo es como cuando hace años leías cartas que habías recibido o que no llegaste a enviar. En fin, ¡que recuerdos! :)
El caso es que al final me pregunté: Y yo, ¿cuánto tiempo he estado bloggeando? Y cual fue mi sorpresa al descubrir que ¡mi cuarto aniversario fue ayer! La verdad es que no me esperaba que fuese hace tanto tiempo, pero se ve que el tiempo pasa muy rápido. Mis comienzos fueron curiosamente (no creo) los mismos que Aitor, pidiendo de prestado en freeroller.net. Mi final, sigue siendo de prestado pero ahora en blogger. Mi camino es mucho menos traceable que el de Aitor porque siempre ha sido muy irregular, de hecho he alternado blogging en inglés y español, y en diferentes servidores. Atrás queda un ya irecuperable blog en blog-city (¡no me acordaba de eso!), otro en javahispano, otro más, éste en inglés, en jroller, otro que está ahora mismo en estado de coma en blogspot (el hermano de éste, pero en inglés), y por último éste que estáis leyendo.
Que emocionante leer los posts de hace cuatro años. En cierto modo es como cuando hace años leías cartas que habías recibido o que no llegaste a enviar. En fin, ¡que recuerdos! :)
domingo, diciembre 24, 2006
Vacaciones y Irish seals
domingo, diciembre 24, 2006 por Martín
El pasado sábado comenzaron mis vacaciones de invierno, así que me esperan unos días muy, pero que muy, relajados. Ayer, me acerqué al puerto de Dún Laoghaire para intentar comprar algo de marisco fresco (y barato) en el puerto. El caso es que cuando llegué, ya no había nada de lo que buscaba (aunque sí que había buen pescado fresco) así que me acerqué a una pescadería de la zona. Por cierto, aquí el marisco no es demasiado caro, al menos en comparación con otras cosas. Un kilo de cigalas (pequeñas) y un kilo de mejillones me han salido por 16 euros, y las cigalas se movían por lo que no me parece una barbaridad.
Bueno, dejando a un lado el marisco, lo que realmente me sorprendió es que cuando estaba en el puerto me acerqué a la orilla porque oía unos ruidos y me encontré frente a frente con este personaje:
Fue muy simpático porque yo había oido ruidos, pero me esperaba algún pescado chapoteando, no una genuina Irish seal. Las focas irlandesas son una especie autóctona de aquí pero aún no había tenido la oportunidad de ver una, y la verdad es que me pilló desprevenido. Esto no hace más que reafirmarme en mi opinión de que no pienso ir a bañarme el día 25 de Diciembre después de ir a misa, como algún amigo de la oficina me ha propuesto. No por las focas, sino por la temperatura del agua.
El caso es que he subido el video a YouTube para hacer famosa mi amiga la foca. :-)
Bueno, dejando a un lado el marisco, lo que realmente me sorprendió es que cuando estaba en el puerto me acerqué a la orilla porque oía unos ruidos y me encontré frente a frente con este personaje:
Fue muy simpático porque yo había oido ruidos, pero me esperaba algún pescado chapoteando, no una genuina Irish seal. Las focas irlandesas son una especie autóctona de aquí pero aún no había tenido la oportunidad de ver una, y la verdad es que me pilló desprevenido. Esto no hace más que reafirmarme en mi opinión de que no pienso ir a bañarme el día 25 de Diciembre después de ir a misa, como algún amigo de la oficina me ha propuesto. No por las focas, sino por la temperatura del agua.
El caso es que he subido el video a YouTube para hacer famosa mi amiga la foca. :-)
martes, diciembre 19, 2006
Juegos en la empresa
martes, diciembre 19, 2006 por Martín
Sin lugar a dudas, una de las formas más originales de probar un producto, y que he tenido la oportunidad de experimentar este año, es la de jugar con él. Sí, jugar, habéis leido bien. Intentaré explicar el concepto en los siguientes párrafos.
Cuando un producto está llegando a su fecha de lanzamiento empieza el periodo estresante de pruebas exhaustivas. Normalmente, el producto se cerrará en cuando a código fuente y a partir de ahí entrará en proceso de integración y pruebas por parte del equipo de tests. Una vez que termine este período, podremos lanzar nuestra tan esperada versión. Obviamente, nos interesa que cuando el producto llegue a manos del cliente, éste se encuentre impecable y totalmente libre del más mínimo error, problema de rendimiento, agujero de memoria, o cualquier otro efecto indeseable.
Si nuestro proceso de pruebas e integración es extraordinario, todo irá como la seda. Pero la realidad es que las cosas no suelen ser así. Aunque nuestro proceso de pruebas sea perfecto desde el punto de vista formal, la realidad es que siempre existe un factor importantísimo que no podemos controlar: el factor humano.
El factor humano es importantísimo a la hora de probar un producto, porque por muchos tests unitarios, de integración, de rendimiento o funcionales que tengamos, ¿saben realmente nuestros desarrolladores lo que están probando? Es más, ¿saben nuestros desarrolladores como funciona el producto?, ¿saben como es el interfaz de usuario?, ¿saben como se comunican los componentes?, ¿se han puesto alguna vez en la piel del usuario final? Probablemente la respuesta a todas estas preguntas sea afirmativa si estamos hablando de un producto pequeño, pero sin embargo, cuando hablamos de un equipo de cientos de desarrolladores, de productos con decenas de módulos diferentes, y de grupos de desarrollo diversos (incluso deslocalizados), entonces la respuesta será un conjunto de noes.
Una de las formas de afrontar este problema es jugar. Sí, jugar, como leéis. Dependiendo de la aplicación se podrán crear diferentes tipos de juegos. No todas las aplicaciones son "jugables". Unas lo son más que otras. Por ejemplo, si estamos creando un juego para un periódico nos será sencillo el crear un juego virtual dentro de la empresa; si estamos trabajando en un producto para invertir en el mercado bursatil, podremos crear un juego de inversión en bolsa; si estamos creando una tienda online podemos crear un juego en el que ganaría el que más compras realize, o el que más dinero gaste, o cosas así; si estamos creando una aplicación de gestión de un servicio médico, podemos premiar a los que más pacientes traten o examinen completamente, a los que más informes creen, etc. etc. En fin, hay muchísimos ejemplos, unos más sencillos, otros más complejos.
Una vez que tenemos definido el juego es importante crear el entorno de ejecución del mismo. Este entorno debería simular de algún modo el entorno de producción real. Como la carga de usuarios será menor, se debería escalar este sistema para alcanzar algún tipo de relación con la carga de usuarios esperada. En general el sistema será mucho más pequeño que el de producción, pero debería ser lo suficientemente significativo como para generar problemas que podrían aparecer en producción.
Una vez que tengamos definido todo esto, llega el momento de jugar. Pero bueno, a estas alturas estaréis pensando, pero éste realmente se piensa que la gente va a ponerse a jugar con todas las cosas que tienen que hacer. Tenéis toda la razón del mundo. Todo esto no es suficiente si no se toman algunas medidas muy importantes:
Como apunto en la lista, el juego debe tener obligatoriamente premios, y si es posible debería haber premios en metálico para todo el mundo. Por ejemplo, en el ejemplo de la tienda, se podría ofrecer a los empleados el 5% del importe de todo lo que compren hasta un límite de 1000€; o en el juego de la bolsa, pues el 5% de las ganancias que consigan + 5€ por operación realizada hasta 1000€.
Tener premios sin duda estimulará a la gente a participar. Una opción interesante es contactar con el cliente para conseguir ese dinero en metálico. Este tipo de juegos suele atraer la atracción del cliente final, ya que muestra que existe una intención real de hacer una prueba extensiva del producto. De hecho, si el cliente final es una organización, probablemente les interese a ellos mismos realizar un juego interno posterior dentro de la propia compañía.
También es muy importante que el juego sea obligatorio. Este tipo de prácticas ofrecen una enorme oportunidad para simular el comportamiento real de la aplicación, con personas reales y en un entorno similar al entorno de producción. Por eso es tan importante que participe la mayor cantidad de personas como sea posible. Adicionalmente, este tipo de juegos sirve para que los desarrolladores se familiaricen con la aplicación, para que entiendan como funciona, para que se pongan en la piel del usuario final y se enfrenten al interfaz de usuario, para que se den cuenta ellos mismos de los diferentes problemas. En fin, son demasiado valiosas como para que no se realicen. Por ello debe obligarse a los desarrolladores (y a testers, y soporte técnico, y managers, y a todo el mundo) a participar en el juego.
La participación no tiene porque ser constante, ya que también queremos que las personas trabajen. Se pueden organizar periodos de participación durante el día, o quizás ofrecer herramientas que automatizen el juego para que no haya que estar todo el día mirando para la pantalla para ganar.
Este año, he tenido la oportunidad de participar en uno de este tipo de juegos y la verdad es que la experiencia fue increiblemente positiva, y todo el mundo coincidió en lo mismo. Son experiencias que no sólo te ayudan a aprender como funciona el producto, sino que ofrecen un enorme abanico de posibilidades a la hora de probar realmente las aplicaciones.
Me pregunto si alguien tiene expriencias que compartir sobre este tema que personalmente me parece muy interesante. Ahí queda la oferta.
Cuando un producto está llegando a su fecha de lanzamiento empieza el periodo estresante de pruebas exhaustivas. Normalmente, el producto se cerrará en cuando a código fuente y a partir de ahí entrará en proceso de integración y pruebas por parte del equipo de tests. Una vez que termine este período, podremos lanzar nuestra tan esperada versión. Obviamente, nos interesa que cuando el producto llegue a manos del cliente, éste se encuentre impecable y totalmente libre del más mínimo error, problema de rendimiento, agujero de memoria, o cualquier otro efecto indeseable.
Si nuestro proceso de pruebas e integración es extraordinario, todo irá como la seda. Pero la realidad es que las cosas no suelen ser así. Aunque nuestro proceso de pruebas sea perfecto desde el punto de vista formal, la realidad es que siempre existe un factor importantísimo que no podemos controlar: el factor humano.
El factor humano es importantísimo a la hora de probar un producto, porque por muchos tests unitarios, de integración, de rendimiento o funcionales que tengamos, ¿saben realmente nuestros desarrolladores lo que están probando? Es más, ¿saben nuestros desarrolladores como funciona el producto?, ¿saben como es el interfaz de usuario?, ¿saben como se comunican los componentes?, ¿se han puesto alguna vez en la piel del usuario final? Probablemente la respuesta a todas estas preguntas sea afirmativa si estamos hablando de un producto pequeño, pero sin embargo, cuando hablamos de un equipo de cientos de desarrolladores, de productos con decenas de módulos diferentes, y de grupos de desarrollo diversos (incluso deslocalizados), entonces la respuesta será un conjunto de noes.
Una de las formas de afrontar este problema es jugar. Sí, jugar, como leéis. Dependiendo de la aplicación se podrán crear diferentes tipos de juegos. No todas las aplicaciones son "jugables". Unas lo son más que otras. Por ejemplo, si estamos creando un juego para un periódico nos será sencillo el crear un juego virtual dentro de la empresa; si estamos trabajando en un producto para invertir en el mercado bursatil, podremos crear un juego de inversión en bolsa; si estamos creando una tienda online podemos crear un juego en el que ganaría el que más compras realize, o el que más dinero gaste, o cosas así; si estamos creando una aplicación de gestión de un servicio médico, podemos premiar a los que más pacientes traten o examinen completamente, a los que más informes creen, etc. etc. En fin, hay muchísimos ejemplos, unos más sencillos, otros más complejos.
Una vez que tenemos definido el juego es importante crear el entorno de ejecución del mismo. Este entorno debería simular de algún modo el entorno de producción real. Como la carga de usuarios será menor, se debería escalar este sistema para alcanzar algún tipo de relación con la carga de usuarios esperada. En general el sistema será mucho más pequeño que el de producción, pero debería ser lo suficientemente significativo como para generar problemas que podrían aparecer en producción.
Una vez que tengamos definido todo esto, llega el momento de jugar. Pero bueno, a estas alturas estaréis pensando, pero éste realmente se piensa que la gente va a ponerse a jugar con todas las cosas que tienen que hacer. Tenéis toda la razón del mundo. Todo esto no es suficiente si no se toman algunas medidas muy importantes:
- Premios en metálico.
- El juego debe ser obligatorio.
Como apunto en la lista, el juego debe tener obligatoriamente premios, y si es posible debería haber premios en metálico para todo el mundo. Por ejemplo, en el ejemplo de la tienda, se podría ofrecer a los empleados el 5% del importe de todo lo que compren hasta un límite de 1000€; o en el juego de la bolsa, pues el 5% de las ganancias que consigan + 5€ por operación realizada hasta 1000€.
Tener premios sin duda estimulará a la gente a participar. Una opción interesante es contactar con el cliente para conseguir ese dinero en metálico. Este tipo de juegos suele atraer la atracción del cliente final, ya que muestra que existe una intención real de hacer una prueba extensiva del producto. De hecho, si el cliente final es una organización, probablemente les interese a ellos mismos realizar un juego interno posterior dentro de la propia compañía.
También es muy importante que el juego sea obligatorio. Este tipo de prácticas ofrecen una enorme oportunidad para simular el comportamiento real de la aplicación, con personas reales y en un entorno similar al entorno de producción. Por eso es tan importante que participe la mayor cantidad de personas como sea posible. Adicionalmente, este tipo de juegos sirve para que los desarrolladores se familiaricen con la aplicación, para que entiendan como funciona, para que se pongan en la piel del usuario final y se enfrenten al interfaz de usuario, para que se den cuenta ellos mismos de los diferentes problemas. En fin, son demasiado valiosas como para que no se realicen. Por ello debe obligarse a los desarrolladores (y a testers, y soporte técnico, y managers, y a todo el mundo) a participar en el juego.
La participación no tiene porque ser constante, ya que también queremos que las personas trabajen. Se pueden organizar periodos de participación durante el día, o quizás ofrecer herramientas que automatizen el juego para que no haya que estar todo el día mirando para la pantalla para ganar.
Este año, he tenido la oportunidad de participar en uno de este tipo de juegos y la verdad es que la experiencia fue increiblemente positiva, y todo el mundo coincidió en lo mismo. Son experiencias que no sólo te ayudan a aprender como funciona el producto, sino que ofrecen un enorme abanico de posibilidades a la hora de probar realmente las aplicaciones.
Me pregunto si alguien tiene expriencias que compartir sobre este tema que personalmente me parece muy interesante. Ahí queda la oferta.
lunes, diciembre 18, 2006
Irlanda: Otro mundo en cuanto a Internet
lunes, diciembre 18, 2006 por Martín
Llevaba tiempo queriendo escribir algo sobre esto, y es que la verdad es algo que me ha sorprendido mucho desde que estoy aquí en Irlanda. La verdad es que sí, cuando vienes aquí piensas que lo normal será que estén más avanzados en cuanto a tecnologías de la información, ya que aquí se encuentran prácticamente toda las empresas importantes no sólo de Europa sino también del mundo, pero desde luego no te imaginas la adicción que tiene esta gente por esto de Internet.
Una de las cosas que más me ha sorprendido es que prácticamente todo el mundo tiene su página web. Que vas al gimnasio, tienen página web. Que vas a la iglesia, tiene página web. Que tienes que comprar pescado, el pescadero tiene página web (obviamente no llegan al nivel de la compra online, pero al menos sabes donde está). Tu pub preferido, todos tienen página web. El de las cortinas, página web. Te pasas por el centro comercial y recoges el periódico gratuito de la zona, y todo los anuncios que salen vienen con su página web. Y es que aquí tienen muy claro que si tienes un negocio, tienes que estar en Internet.
Y es que no en vano Irlanda es el pais de Europa que que más se dinero se gasta en la compra online, llegando a gastar el doble que cualquier europeo. Nada más y nada menos que un 24% de los usuarios de la web en Irlanda afirman comprar en Internet, y un 47% planean hacer la compra estas navidades. Y es que como se puede leer en el informe State of the net este es un negocio en el que una compañía de procesado de transacciones online puede llegar a mover 15 millones de euros diarios.
Claro, a eso ayuda que prácticamente el 50% de la población esté conectado a la red y que de ese 50% el 78% de los usuarios de internet estén utilizando banda ancha, algo que no sucede en todos los paises.
Una de las cosas más curiosas que también he notado es la adicción que tiene esta gente a eBay. Todo el mundo en mi trabajo compra cosas en eBay. Vale, comprar en eBay no es algo raro, pero, ¡¿qué todo el mundo compre?! Y es que aquí hay auténticos profesionales de la compra online. De hecho no es raro encontrar alguna tienda en la que simplemente dejas tus cosas y ellos te las venden en eBay.
Una de las consecuencias de todo esto es que uno tiene la sensación de que hay oportunidades realmente interesantes. Probablemente Irlanda sea uno de los mejores paises para crear un negocio online realmente productivo. Y es algo que lo notas constantemente, en la calle, en el metro, en la televisión. Tienes esa sensación de que realmente Internet es un canal de marketing y ventas realmente importante.
En fin, que es una cosa a analizar :)
Una de las cosas que más me ha sorprendido es que prácticamente todo el mundo tiene su página web. Que vas al gimnasio, tienen página web. Que vas a la iglesia, tiene página web. Que tienes que comprar pescado, el pescadero tiene página web (obviamente no llegan al nivel de la compra online, pero al menos sabes donde está). Tu pub preferido, todos tienen página web. El de las cortinas, página web. Te pasas por el centro comercial y recoges el periódico gratuito de la zona, y todo los anuncios que salen vienen con su página web. Y es que aquí tienen muy claro que si tienes un negocio, tienes que estar en Internet.
Y es que no en vano Irlanda es el pais de Europa que que más se dinero se gasta en la compra online, llegando a gastar el doble que cualquier europeo. Nada más y nada menos que un 24% de los usuarios de la web en Irlanda afirman comprar en Internet, y un 47% planean hacer la compra estas navidades. Y es que como se puede leer en el informe State of the net este es un negocio en el que una compañía de procesado de transacciones online puede llegar a mover 15 millones de euros diarios.
Claro, a eso ayuda que prácticamente el 50% de la población esté conectado a la red y que de ese 50% el 78% de los usuarios de internet estén utilizando banda ancha, algo que no sucede en todos los paises.
Una de las cosas más curiosas que también he notado es la adicción que tiene esta gente a eBay. Todo el mundo en mi trabajo compra cosas en eBay. Vale, comprar en eBay no es algo raro, pero, ¡¿qué todo el mundo compre?! Y es que aquí hay auténticos profesionales de la compra online. De hecho no es raro encontrar alguna tienda en la que simplemente dejas tus cosas y ellos te las venden en eBay.
Una de las consecuencias de todo esto es que uno tiene la sensación de que hay oportunidades realmente interesantes. Probablemente Irlanda sea uno de los mejores paises para crear un negocio online realmente productivo. Y es algo que lo notas constantemente, en la calle, en el metro, en la televisión. Tienes esa sensación de que realmente Internet es un canal de marketing y ventas realmente importante.
En fin, que es una cosa a analizar :)
sábado, diciembre 16, 2006
Comet, reinventando términos
sábado, diciembre 16, 2006 por Martín
Uno de los términos técnicos del que más se ha leído durante este año es el de Comet. Este término se ha asociado con el mundo de AJAX aunque la realidad es que es un concepto que viene desde mucho más atrás.
El streaming HTTP es la técnica más básica de cualquier compañía que se dedique al mundo de la bolsa, comercio de divisas, o en resúmen cualquier mundo en el que se necesita empujar datos al cliente a velocidades de vértigo. Por ejemplo en el mundo del intercambio de divisas todos los interfaces se basan en este concepto ya que la volatilidad del mercado es brutal y cuando estas operando con monedas con mucha volatilidad, unos pocos segundos pueden significar cientos de miles de dólares.
El streaming HTTP se puede realizar tanto desde un cliente web como desde una aplicación de escritorio tradicional. No es algo que esté ligado para nada con AJAX. Por ejemplo, puedes tener tu aplicación de escritorio interactuando con un banco a través de HTTP y mantener dicha conexión abierta para que el servidor te esté continuamente haciendo streaming de datos. Como he dicho, esto es algo que se ha estado haciendo durante años. En estos casos, el usar una técnica como esta y mantener la conexión habierta es algo básico ya que es físicamente imposible el soportar una comunicación mediante polling. Si alguno se está preguntando porque utilizar HTTP, simplemente debe pensar que estamos hablando de bancos, y los firewalls son muy importantes en los bancos :-), especialmente cuando tu objetivo es el retail, es decir, el público de a pie.
Existen muchos recursos actualmente sobre Comet, AJAX, NIO, etc. y este año ha sido uno de los mejores para este terreno. Servidores web como Jetty o Apache Tomcat 6 soportan ya el mantener conexiones persistentes con el cliente a través de Java NIO, pero el caso es que la historia no se ha acado todavía ahí. El problema más importante ahora mismo es que aunque escales en la capa Servlet, todavía tienes que escalar en el Apache que los bancos te suelen ofrecer como entrada, ya que no sirve de nada liberar threads en tu contenedor web si están bloquedas en el servidor HTTP. Existen opciones como Grizzly, que es un servidor HTTP que utiliza NIO por debajo, pero la realidad es que es poco probable que estas organizaciones te permitan instalar este tipo de software en su puerta de entrada al mundo exterior.
Ante esta situación sólo queda esperar. Probablemente el próximo año se harán muchos avances en este sentido, así que promete ser un año emocionante.
El streaming HTTP es la técnica más básica de cualquier compañía que se dedique al mundo de la bolsa, comercio de divisas, o en resúmen cualquier mundo en el que se necesita empujar datos al cliente a velocidades de vértigo. Por ejemplo en el mundo del intercambio de divisas todos los interfaces se basan en este concepto ya que la volatilidad del mercado es brutal y cuando estas operando con monedas con mucha volatilidad, unos pocos segundos pueden significar cientos de miles de dólares.
El streaming HTTP se puede realizar tanto desde un cliente web como desde una aplicación de escritorio tradicional. No es algo que esté ligado para nada con AJAX. Por ejemplo, puedes tener tu aplicación de escritorio interactuando con un banco a través de HTTP y mantener dicha conexión abierta para que el servidor te esté continuamente haciendo streaming de datos. Como he dicho, esto es algo que se ha estado haciendo durante años. En estos casos, el usar una técnica como esta y mantener la conexión habierta es algo básico ya que es físicamente imposible el soportar una comunicación mediante polling. Si alguno se está preguntando porque utilizar HTTP, simplemente debe pensar que estamos hablando de bancos, y los firewalls son muy importantes en los bancos :-), especialmente cuando tu objetivo es el retail, es decir, el público de a pie.
Existen muchos recursos actualmente sobre Comet, AJAX, NIO, etc. y este año ha sido uno de los mejores para este terreno. Servidores web como Jetty o Apache Tomcat 6 soportan ya el mantener conexiones persistentes con el cliente a través de Java NIO, pero el caso es que la historia no se ha acado todavía ahí. El problema más importante ahora mismo es que aunque escales en la capa Servlet, todavía tienes que escalar en el Apache que los bancos te suelen ofrecer como entrada, ya que no sirve de nada liberar threads en tu contenedor web si están bloquedas en el servidor HTTP. Existen opciones como Grizzly, que es un servidor HTTP que utiliza NIO por debajo, pero la realidad es que es poco probable que estas organizaciones te permitan instalar este tipo de software en su puerta de entrada al mundo exterior.
Ante esta situación sólo queda esperar. Probablemente el próximo año se harán muchos avances en este sentido, así que promete ser un año emocionante.
Pruebas proactivas, tests de integración y equipos de tests
sábado, diciembre 16, 2006 por Martín
Hay un dicho que suele decir que un poco de prevención vale más que un mucho de curación. Personalmente, este dicho lo aplicaría al mundo de las pruebas de software para crear el concepto de pruebas proactivas.
¿Qué es una prueba proactiva? : Una prueba proactiva es aquella cualquier prueba que no tendríamos obligatoriamente que realizar pero que nos permite adelantarnos a los acontecimientos. La principal ventaja de las pruebas proactivas es que nos permiten crear software mucho más sólido previniendo problemas no esperados desde un punto de vista unitario, integracional o funcional.
Ejemplos de pruebas no proactivas serían aquellas que es obligatorio realizar para mantener un software saludable, como los tests unitarios, tests de integración o tests funcionales.
Ejemplos de pruebas proactivas pueden ser los tests de rendimiento, tests de carga y tests de integración.
Ahora bien, si miráis la lista veréis que los tests de integración están tanto en la lista de pruebas proactivas como en la lista de pruebas obligatorias. ¿Por qué? El problema es que los tests de integración yacen en el limbo de los tests.
En una empresa normalmente tenemos diferentes equipos de desarrollo que trabajan con diferentes componentes. Los desarrolladores de estos equipos tienen la responsabilidad de ofrecer componentes lo suficientemente probados a través de tests unitarios. Por otra parte, hay muchas empresas que tienen un equipo completo de testers que se encargarán de realizar todas las pruebas funcionales de cara al usuario final.
El punto más peliagudo es el de los tests de integración. Los tests de integración se encargan de comprobar que los diferentes componentes de nuestro sistema funcionan como es debido, y que interactuan como se espera dentro de sistemas que imitan al entorno de producción que nos vamos a encontrar. Nótese que la palabra integrar aquí adquiere un significado algo ambiguo y se refiere tanto a integrar dos piezas de software que se deben comunicar entre sí, como a integrar esas piezas de software en un entorno de ejecución determinado.
¿Quién hace y cómo se hacen estas pruebas de integración? Sin lugar a dudas, lo ideal es mantener un equipo de desarrollo de tests de integración que se encargue de desplegar los componentes en un sistema similar al de producción y de probar la integración de estos componentes. Aquí es donde entra la proactividad. Estos equipos de producción deben realizar el test del producto olvidándose del usuario final. Esto permite eliminar la dependencia de los casos de uso y alcanzar una cobertura mucho mayor en nuestro software, ya que incluso aunque estuviésemos cubriendo el 100% de los casos de uso definidos en la arquitectura, la realidad es que probablemente los casos de uso no estan cubriendo el 100% de las acciones que nuestros usuarios realizarán.
El problema de mantener los tests de integración orientados al usuario final es que uno no puede realmente estar seguro de que su software es sólido y fiable. Es muy común por ejemplo en los entornos de tests el realizar las pruebas de integración utilizando robots web o robots de GUI, que se encargan de simular el comportamiento del usuario final. ¿Es esto una prueba de integración real entre componentes? No. Esto son pruebas funcionales, y nunca se deberían tratar como pruebas de integración. El problema es que se tratan como tales debido a falta de presupuesto para contratar equipos de test de integración, a falta de conocimiento por parte de los equipos de testing funcional o a falta de tiempo por parte de los desarrolladores para asumir semejante carga.
En resúmen, ponga un equipo de ejecución y creación de tests de integración en su vida y será mucho más feliz :-)
¿Qué es una prueba proactiva? : Una prueba proactiva es aquella cualquier prueba que no tendríamos obligatoriamente que realizar pero que nos permite adelantarnos a los acontecimientos. La principal ventaja de las pruebas proactivas es que nos permiten crear software mucho más sólido previniendo problemas no esperados desde un punto de vista unitario, integracional o funcional.
Ejemplos de pruebas no proactivas serían aquellas que es obligatorio realizar para mantener un software saludable, como los tests unitarios, tests de integración o tests funcionales.
Ejemplos de pruebas proactivas pueden ser los tests de rendimiento, tests de carga y tests de integración.
Ahora bien, si miráis la lista veréis que los tests de integración están tanto en la lista de pruebas proactivas como en la lista de pruebas obligatorias. ¿Por qué? El problema es que los tests de integración yacen en el limbo de los tests.
En una empresa normalmente tenemos diferentes equipos de desarrollo que trabajan con diferentes componentes. Los desarrolladores de estos equipos tienen la responsabilidad de ofrecer componentes lo suficientemente probados a través de tests unitarios. Por otra parte, hay muchas empresas que tienen un equipo completo de testers que se encargarán de realizar todas las pruebas funcionales de cara al usuario final.
El punto más peliagudo es el de los tests de integración. Los tests de integración se encargan de comprobar que los diferentes componentes de nuestro sistema funcionan como es debido, y que interactuan como se espera dentro de sistemas que imitan al entorno de producción que nos vamos a encontrar. Nótese que la palabra integrar aquí adquiere un significado algo ambiguo y se refiere tanto a integrar dos piezas de software que se deben comunicar entre sí, como a integrar esas piezas de software en un entorno de ejecución determinado.
¿Quién hace y cómo se hacen estas pruebas de integración? Sin lugar a dudas, lo ideal es mantener un equipo de desarrollo de tests de integración que se encargue de desplegar los componentes en un sistema similar al de producción y de probar la integración de estos componentes. Aquí es donde entra la proactividad. Estos equipos de producción deben realizar el test del producto olvidándose del usuario final. Esto permite eliminar la dependencia de los casos de uso y alcanzar una cobertura mucho mayor en nuestro software, ya que incluso aunque estuviésemos cubriendo el 100% de los casos de uso definidos en la arquitectura, la realidad es que probablemente los casos de uso no estan cubriendo el 100% de las acciones que nuestros usuarios realizarán.
El problema de mantener los tests de integración orientados al usuario final es que uno no puede realmente estar seguro de que su software es sólido y fiable. Es muy común por ejemplo en los entornos de tests el realizar las pruebas de integración utilizando robots web o robots de GUI, que se encargan de simular el comportamiento del usuario final. ¿Es esto una prueba de integración real entre componentes? No. Esto son pruebas funcionales, y nunca se deberían tratar como pruebas de integración. El problema es que se tratan como tales debido a falta de presupuesto para contratar equipos de test de integración, a falta de conocimiento por parte de los equipos de testing funcional o a falta de tiempo por parte de los desarrolladores para asumir semejante carga.
En resúmen, ponga un equipo de ejecución y creación de tests de integración en su vida y será mucho más feliz :-)
martes, diciembre 05, 2006
¿ Debería despedir a su arquitecto ?
martes, diciembre 05, 2006 por Martín
Realmente polémico el post de David Linthicum en Infojobs. Debe ser una persona bastante influyente (ignorante de mi, no lo conocía), ya que rápidamente otra serie de gurus se han lanzado a responder vorazmente ante el provocativo post en Infoworld.
A pesar de que estoy de acuerdo con él en algunos puntos, por ejemplo el 1, el 5 y el 6 (no en los despidos), espero que no despidiesen a alguien por no confiar demasiado en SOA ;)
Todo esto via nuevamente InfoQ.
A pesar de que estoy de acuerdo con él en algunos puntos, por ejemplo el 1, el 5 y el 6 (no en los despidos), espero que no despidiesen a alguien por no confiar demasiado en SOA ;)
Todo esto via nuevamente InfoQ.
Ron Jeffries sobre metodologías ágiles
martes, diciembre 05, 2006 por Martín
En InfoQ han publicado una entrevista a Ron Jeffries que resulta realmente interesante, ya que no se limita a alabar las metodologías ágiles, sino que adopta un enfoque mucho más realista, mostrando como estas metodologías se comparan con las metodologías más conservadores, y explicando cómo si obviamos el lanzar versiones frecuentes y el probar nuestras funcionalidades el resultado puede ser mucho peor que el que se obtendría mediante un método más tradicional.
Es una entrevista no demasiado larga que se hace bastante amena gracias a las explicaciones que Ron Jeffries va dibujando en su pizarra.
Es una entrevista no demasiado larga que se hace bastante amena gracias a las explicaciones que Ron Jeffries va dibujando en su pizarra.
viernes, diciembre 01, 2006
Interfaces de usuario: ¿Construcción manual o automática?
viernes, diciembre 01, 2006 por Martín
En varios sitios web se ha reabierto el debate sobre si es más adecuada la construcción de interfaces de usuario a través de herramientas de generación de código, o si por el contrario es mejor elegir una aproximación más artesana y construir todo el código manualmente.
La verdad es que este es un tema recurrente sobre el que creo que cualquiera pude opinar, ya que asumo que todos los que estamos en este mundillo del software hemos desarrollado algún interfaz de usuario en algún momento de nuestras carreras, ya sea hace años cuando los Visual Basic era una revolución a la hora de crear aplicaciones, ya sea más recientemente en Java con herramientas como Matisse, o ya sea en el mundo web con los diseñadores visuales para frameworks Java Server Faces. Asimismo, probablemente todos hemos en algún momento determinado creado, o intentado crear, esas mismas interfaces de un modo manual, ya sea porque nos apetecía, porque no teníamos otra cosa a mano, o por cualquier otra razón.
Ante una situación como esta, donde cada cual tiene su propia opinión en base a su experiencia, creo que es un poco inútil el caer en discusiones sobre ésta u ésta otra tecnología es mejor, así que intentaré describir lo que en mi opinión son los tres factores más importantes a tener en cuenta, en orden de importancia, a la hora de elegir uno y otro camino:
En esta lista los dos primeros puntos son excluyentes y decisivos. Si no tenemos gente experta, lo mejor es ir a las herramientas, mientras que si nuestro interfaz va a ser muy complejo y personalizado, lo mejor es ir al código manual. En caso de empate en esos dos puntos, el tercero debe decidir.
Me dejo muchos aspectos deliberadamente, porque la verdad es que este sería todo un tema para un libro. Otro aspecto importante podría ser la volativilidad del equipo. Por ejemplo, si hoy tengo un equipo muy bueno, y la gente se me va, mañana quizás un equipo menos experimentado tendrá que mantener el código del primer equipo, y en ese caso el trabajar con un diseñador visual facilita las cosas porque para los segundos les será sencillo ver lo que han hecho los primeros. Pero, por ejemplo, por el contrario, forzar a los programadores a no utilizar un diseñador, es equivalente a forzarlos a aprender como funciona una determinada API, lo que siempre es bueno porque aporta conocimiento sobre la plataforma.
En fin, sea como sea, ante todo lo más importante es ser consistente con la decisión tomada. Si elegimos utilizar una herramienta, debemos utilizarla y cuidarnos de que los interfaces se puedan seguir manteniendo con esa herramienta. Si comenzamos a crear pantallas, y posteriormente añadimos mucho código personalizado a estas pantallas, seguramente no las podramos volver a editar gráficamente. La consecuencia es que parte de nuestro interfaz gráfico se modificará con un editor y la otra parte se modificará manualmente, lo que no deja de ser un desastre.
Y para acabar me mojo. Yo prefiero no utilizar herramienta. Siempre que comienzo algún proyecto, intento empezar con alguna, pero al final acabo escribiendo todo a mano. Que se le va a hacer :)
La verdad es que este es un tema recurrente sobre el que creo que cualquiera pude opinar, ya que asumo que todos los que estamos en este mundillo del software hemos desarrollado algún interfaz de usuario en algún momento de nuestras carreras, ya sea hace años cuando los Visual Basic era una revolución a la hora de crear aplicaciones, ya sea más recientemente en Java con herramientas como Matisse, o ya sea en el mundo web con los diseñadores visuales para frameworks Java Server Faces. Asimismo, probablemente todos hemos en algún momento determinado creado, o intentado crear, esas mismas interfaces de un modo manual, ya sea porque nos apetecía, porque no teníamos otra cosa a mano, o por cualquier otra razón.
Ante una situación como esta, donde cada cual tiene su propia opinión en base a su experiencia, creo que es un poco inútil el caer en discusiones sobre ésta u ésta otra tecnología es mejor, así que intentaré describir lo que en mi opinión son los tres factores más importantes a tener en cuenta, en orden de importancia, a la hora de elegir uno y otro camino:
- Experiencia de la gente que disponemos: Lo más importante que se debe tener en cuenta es el tipo de gente con la que contamos en el equipo de UI. Y ante este punto lo más importante es ser realistas y recordar que no debemos elegir en base a nuestras preferencias si no en base a su experiencia y habilidad.
Si en el equipo de UI cuento sólo con personas con poca experiencia, que no han hecho interfaces visuales previamente, o que vienen de otros lenguajes y no conocen Java, o .NET, o lo que sea, entonces en este caso no tendría demasiado sentido forzarles a programar todo manualmente, ya que les resultará muy complicado. Incluso aunque a nosotros nos parezca una tarea muy fácil, la realidad es diferente: para ellos no lo es.
Por otra parte, obligar a un grupo de expertos programadores a utilizar un diseñador gráfico puede ser contraproducente, ya que estas personas pueden no sentirse cómodas con estas herramientas, pueden tener ya una serie de procesos que los hagan más productivos y el añadir una herramienta nueva puede significar reemplazar todos esos procesos por algo totalmente nuevo, y finalmente esto puede llegar a causar frustración y desánimo en el equipo. - Complejidad del interfaz de usuario: El siguiente punto a tratar sería la complejidad del interfaz que estamos planeando. Los diseñadores visuales suelen soportar un conjunto limitado de componentes, y en cuanto añades componentes que no esperan el resultado puede ser diferente al que no esperamos. Si nuestro interfaz va a utilizar componentes personalizados, entonces debemos plantearnos seriamente la posibilidad de utilizar una aproximación híbrida o simplemente olvidarnos de utilizar ninguna herramienta.
Mediante una aproximación híbrida, diseñariamos la mayor parte de componentes con herramientas visuales y posteriormente añadiriamos los componentes propios. El punto crítico aquí es que el proceso de añadir componentes propios debe ser lo menos intrusivo que sea posible, ya que de otro modo las probabilidades de que la herramienta gráfica sea incapaz de volver a recear nuestro interfaz son muy altas.
Si el número de componentes personalizados es alto; o si estos componentes personalizados se encuentran muy arriba en la jerarquía de componentes ( no es lo mismo personalizar un frame que un botón ), entonces lo mejor sera olvidar directamente las herramientas visuales. - Valorar entre diseñadores visuales y frameworks: Hoy por hoy los diseñadores visuales son muy potentes. Por ejemplo, en Java, hay diseñadores excelentes tanto para Swing como para SWT. Por otra parte, tenemos que de manera alternativa siempre aparecen una serie de frameworks que ofrecen un enorme valor añadido, como pueda ser JGoodies en Java (o incluso los componentes de futuros jdk que van apareciendo en java.net). La mala noticia es que los diseñadores visuales no suelen soportar estos componentes, lo que significa que si realmente necesitamos alguno de estos componentes, entonces tendremos que abandonar la idea de utilizar el diseñador.
Si por el contrario, no hay ningún framework que nos ofrezca algo realmente valioso, entonces la opción de usar diseñadores vuelve a adquirir valor.
En esta lista los dos primeros puntos son excluyentes y decisivos. Si no tenemos gente experta, lo mejor es ir a las herramientas, mientras que si nuestro interfaz va a ser muy complejo y personalizado, lo mejor es ir al código manual. En caso de empate en esos dos puntos, el tercero debe decidir.
Me dejo muchos aspectos deliberadamente, porque la verdad es que este sería todo un tema para un libro. Otro aspecto importante podría ser la volativilidad del equipo. Por ejemplo, si hoy tengo un equipo muy bueno, y la gente se me va, mañana quizás un equipo menos experimentado tendrá que mantener el código del primer equipo, y en ese caso el trabajar con un diseñador visual facilita las cosas porque para los segundos les será sencillo ver lo que han hecho los primeros. Pero, por ejemplo, por el contrario, forzar a los programadores a no utilizar un diseñador, es equivalente a forzarlos a aprender como funciona una determinada API, lo que siempre es bueno porque aporta conocimiento sobre la plataforma.
En fin, sea como sea, ante todo lo más importante es ser consistente con la decisión tomada. Si elegimos utilizar una herramienta, debemos utilizarla y cuidarnos de que los interfaces se puedan seguir manteniendo con esa herramienta. Si comenzamos a crear pantallas, y posteriormente añadimos mucho código personalizado a estas pantallas, seguramente no las podramos volver a editar gráficamente. La consecuencia es que parte de nuestro interfaz gráfico se modificará con un editor y la otra parte se modificará manualmente, lo que no deja de ser un desastre.
Y para acabar me mojo. Yo prefiero no utilizar herramienta. Siempre que comienzo algún proyecto, intento empezar con alguna, pero al final acabo escribiendo todo a mano. Que se le va a hacer :)
martes, noviembre 28, 2006
SOA, la buzzword más despreciada
martes, noviembre 28, 2006 por Martín
Y el ganador de la buzzword más despreciada es: SOA!
Es curioso como otra histórica buzzword como Web Services sólo acapara un 4% en el índice de desprecio. Los servicios web han pasado la barrera de buzzword a realidad, y poco a poco se van implantando. Eso sí, nada que ver con lo que nos vendían hace años.
Es curioso como otra histórica buzzword como Web Services sólo acapara un 4% en el índice de desprecio. Los servicios web han pasado la barrera de buzzword a realidad, y poco a poco se van implantando. Eso sí, nada que ver con lo que nos vendían hace años.
Por fin etiquetas
martes, noviembre 28, 2006 por Martín
Por fin puedo tener tags en mi weblog. blogger.com ha actualizado la versión de su software y ahora todo está un poco más organizado.
domingo, noviembre 26, 2006
Sobre menus, elecciones y Microsoft
domingo, noviembre 26, 2006 por Martín
Joel se queja de que el nuevo menu desplegable que ofrece Windows Vista para salir del sistema es demasiado farragoso, y Moishe, que fue uno de los miembros del equipo de desarrollo de esa funcionalidad de Windows Vista, expone las verguenzas del proceso de desarrollo de software utilizado en este sistema operativo.
jueves, noviembre 23, 2006
Scrum en 5 minutos
jueves, noviembre 23, 2006 por Martín
Jeff Sutherland cuenta en su blog que normalmente utiliza en sus presentaciones un PDF creado por SoftHouse y que se titula Scrum in five minutes.
Este PDF está pensado para presentar rápidamente las bondades de Scrum, especialmente a analistas de negocio, directivos, jefes de departamento, que no tengan tiempo para asimilar todas los detalles de la metodología. El documento realizan un análisis muy visual y didáctico de las características de Scrumm, así que siempre será bueno tenerlo a mano :)
Este PDF está pensado para presentar rápidamente las bondades de Scrum, especialmente a analistas de negocio, directivos, jefes de departamento, que no tengan tiempo para asimilar todas los detalles de la metodología. El documento realizan un análisis muy visual y didáctico de las características de Scrumm, así que siempre será bueno tenerlo a mano :)
Multi-core CPUs y Java
jueves, noviembre 23, 2006 por Martín
Billy Newport analiza en esta entrada de su blog las posibles consecuencias que puede tener la ubicuidad de los procesadores multi-core. El problema que Billy plantea es que normalmente estas arquitecturas multi-core se presentan con varias CPUs teniendo cada una de éstas una frecuencia de reloj considerablemente menor.
La lectura resulta muy interesante, no sólo el post principal sino también las respuestas. Personalmente, no creo que esta arquitectura sea mala para Java sino todo lo contrario. Obviamente, los productos que hayan sido diseñados deficientemente deberían sufrir teóricamente una bajada en su rendimiento. Pero probablemente muchos productos mejorarán, incluidos servidores de aplicaciones, servidores web, las propias máquinas virtuales y sus algoritmos de recolección de basura, etc.
Java fue el primer lenguaje que apostó seriamente por explotar la concurrencia de las aplicaciones desde que fue creado. Y esto hará que la evolución no sea tan complicada como podría ser para otros lenguajes. Al final, lo cierto es que con ese artículo me ha entrado el gusanillo por uno de estos multi-cores :)
La lectura resulta muy interesante, no sólo el post principal sino también las respuestas. Personalmente, no creo que esta arquitectura sea mala para Java sino todo lo contrario. Obviamente, los productos que hayan sido diseñados deficientemente deberían sufrir teóricamente una bajada en su rendimiento. Pero probablemente muchos productos mejorarán, incluidos servidores de aplicaciones, servidores web, las propias máquinas virtuales y sus algoritmos de recolección de basura, etc.
Java fue el primer lenguaje que apostó seriamente por explotar la concurrencia de las aplicaciones desde que fue creado. Y esto hará que la evolución no sea tan complicada como podría ser para otros lenguajes. Al final, lo cierto es que con ese artículo me ha entrado el gusanillo por uno de estos multi-cores :)
sábado, noviembre 18, 2006
Java es libre, ¿y ahora qué?
sábado, noviembre 18, 2006 por Martín
Hay ciertos acontecimientos en la vida que te hacen mirar para atrás y de pronto te das cuenta de que rápido pasa el tiempo. Hace cuatro años (creo), recuerdo que yo y Alberto, comenzamos una cruzada personal para promocionar Java en España. Eran otros tiempos, cuando ambos estabamos involucrados en javahispano, y cuando realmente no había demasiado conocimiento de la plataforma Java en España.
Recuerdo haber viajado al menos por Santiago, Madrid, Barcelona, Gandía, Alicante, Cáceres y Madrid hablando sobre las maravillas de Java, y por qué era interesante esta plataforma para las empresas y los usuarios individuales. Intentando eliminar el mito de que Java en sí no era libre (lo siento, lo que han liberado son las herramientas de Sun, bueno y Duke). Que tiempos aquellos, mostrándole a la gente que no era tan sencillo el decir "Java no es libre, no lo uso"; que había otras máquinas virtuales alternativas; que el modelo de especificación era abierto y había organizaciones de software libre como Apache trabajando ya en él.
Supongo que este pasado Lunes esto ha terminado. Punto final. La discusión se ha acabado. ¿Y ahora qué? Pues por el momento habrá que esperar acontecimientos. Por ahora el JDK (que es lo realmente interesante) no se liberará hasta la versión 6 y 7, pero es que la versión 6 ya está a la vuelta de la esquina, así que no tardaremos mucho en verlo. Pronto se incluirá el JDK de Sun y Glassfish ( el servidor de aplicaciones ) dentro de las distribuciones de Linux, aunque habrá que ver si con el nombre de Java (ya que las marcas no han sido liberadas) o con otro nombre clave diferente, lo que se podría decir que marcaría el primer fork.
Será muy interesante ver también lo que pasa con otras implementaciones libres. Ahí están los kaffe, classpath o Harmony. Especialmente este último resulta interesante por algunas de las funcionalidades que ofrece y que no están presentes en las implementaciones actuales de Sun (por ejemplo Harmony es muy modular, está basado en osgi y puedes desplegar una máquina virtual sólo con ciertas partes de la misma). Por otra parte, no deja de estar bastante claro que Harmony ha sido uno de los detonantes de la reacción de Sun, ya que es una máquina virtual que aunque no terminada, si que está muy cerca de la certificación; y sin lugar a dudas la participación de IBM en este proyecto también habrá espoleado de alguna manera a los responsables de Java en Sun.
Desde el punto de vista de negocios, el movimiento de Sun ha sido magistral. Si hubiera esperado más habría llegado tarde. Java estaba en un momento de declieve en estos momentos en comparación con otros lenguajes Open Source como Python o Ruby, siendo este último claramente el lenguaje de moda. No es un secreto que ahora mismo existe actualmente una migración de talentos desde Java a Ruby, y el movimiento de Sun ayudará a aumentar todavía más la base de usuarios de la plataforma.
Sun ha sido listo también con la licencia aplicada al JDK. Ha escogido GPL v2 (+ classpath, para algunas partes), lo que le permitirá que ninguna empresa privada pueda distribuir "sabores" de Java sin que los desarrolladores puedan ver su codigo fuente. Es decir, si alguien quiere distribuir otro JDK, tendrá que mostrar el código fuente, así que los desarrolladores estarán avisados de antemano si alguna compañía se ve tentada a crear un engendro diabólico que acabe con la fama de la plataforma.
IBM ya ha mostrado su descontento por la licencia escogida. Ellos querían adoptar la licencia de Apache, o algo más libre. En cierto modo no deja de ser una pelea empresarial. Harmony ya tiene licencia Apache, y ahora podrá avanzar más rápidamente, así que si lo desean podrán tener su propio JDK con licencia Apache en relativamente poco tiempo. A este nivel empresarial, cuando eres rival de alquien, es dificil llegar a un acuerdo, porque tiene muchas consecuencias (le estoy dando la razón, reconozco que hacen bien las cosas). Y seguramente lo mismo sucederá por parte de Sun, y alguna influencia habrá tenido la opinión de IBM. Emitir juicios en este sentido siempre es algo arriesgado.
Sea como sea, los desarrolladores estamos de enhorabuena.
Recuerdo haber viajado al menos por Santiago, Madrid, Barcelona, Gandía, Alicante, Cáceres y Madrid hablando sobre las maravillas de Java, y por qué era interesante esta plataforma para las empresas y los usuarios individuales. Intentando eliminar el mito de que Java en sí no era libre (lo siento, lo que han liberado son las herramientas de Sun, bueno y Duke). Que tiempos aquellos, mostrándole a la gente que no era tan sencillo el decir "Java no es libre, no lo uso"; que había otras máquinas virtuales alternativas; que el modelo de especificación era abierto y había organizaciones de software libre como Apache trabajando ya en él.
Supongo que este pasado Lunes esto ha terminado. Punto final. La discusión se ha acabado. ¿Y ahora qué? Pues por el momento habrá que esperar acontecimientos. Por ahora el JDK (que es lo realmente interesante) no se liberará hasta la versión 6 y 7, pero es que la versión 6 ya está a la vuelta de la esquina, así que no tardaremos mucho en verlo. Pronto se incluirá el JDK de Sun y Glassfish ( el servidor de aplicaciones ) dentro de las distribuciones de Linux, aunque habrá que ver si con el nombre de Java (ya que las marcas no han sido liberadas) o con otro nombre clave diferente, lo que se podría decir que marcaría el primer fork.
Será muy interesante ver también lo que pasa con otras implementaciones libres. Ahí están los kaffe, classpath o Harmony. Especialmente este último resulta interesante por algunas de las funcionalidades que ofrece y que no están presentes en las implementaciones actuales de Sun (por ejemplo Harmony es muy modular, está basado en osgi y puedes desplegar una máquina virtual sólo con ciertas partes de la misma). Por otra parte, no deja de estar bastante claro que Harmony ha sido uno de los detonantes de la reacción de Sun, ya que es una máquina virtual que aunque no terminada, si que está muy cerca de la certificación; y sin lugar a dudas la participación de IBM en este proyecto también habrá espoleado de alguna manera a los responsables de Java en Sun.
Desde el punto de vista de negocios, el movimiento de Sun ha sido magistral. Si hubiera esperado más habría llegado tarde. Java estaba en un momento de declieve en estos momentos en comparación con otros lenguajes Open Source como Python o Ruby, siendo este último claramente el lenguaje de moda. No es un secreto que ahora mismo existe actualmente una migración de talentos desde Java a Ruby, y el movimiento de Sun ayudará a aumentar todavía más la base de usuarios de la plataforma.
Sun ha sido listo también con la licencia aplicada al JDK. Ha escogido GPL v2 (+ classpath, para algunas partes), lo que le permitirá que ninguna empresa privada pueda distribuir "sabores" de Java sin que los desarrolladores puedan ver su codigo fuente. Es decir, si alguien quiere distribuir otro JDK, tendrá que mostrar el código fuente, así que los desarrolladores estarán avisados de antemano si alguna compañía se ve tentada a crear un engendro diabólico que acabe con la fama de la plataforma.
IBM ya ha mostrado su descontento por la licencia escogida. Ellos querían adoptar la licencia de Apache, o algo más libre. En cierto modo no deja de ser una pelea empresarial. Harmony ya tiene licencia Apache, y ahora podrá avanzar más rápidamente, así que si lo desean podrán tener su propio JDK con licencia Apache en relativamente poco tiempo. A este nivel empresarial, cuando eres rival de alquien, es dificil llegar a un acuerdo, porque tiene muchas consecuencias (le estoy dando la razón, reconozco que hacen bien las cosas). Y seguramente lo mismo sucederá por parte de Sun, y alguna influencia habrá tenido la opinión de IBM. Emitir juicios en este sentido siempre es algo arriesgado.
Sea como sea, los desarrolladores estamos de enhorabuena.
viernes, noviembre 10, 2006
¿Son útiles las certificaciones?
viernes, noviembre 10, 2006 por Martín
A raiz de una noticia salida en eweek se han podido leer comentarios en varios blogs acerca de lo inútiles que pueden ser las certificaciones. Que si no significan nada, que si los programadores inteligentes no tienen tiempo para certificarse, etc. Así que como certificado que soy, no puedo resistir el poner aqui mis comentarios.
Personalmente creo que las certificaciones son algo muy útil, tanto para las plataformas, como para las empresas, como para las personas. Pero antes de exponer porque, me gustaría decir que para mi el estudio de eweek apenas tiene valor. Yo no creo que el valor de las certificaciones esté en que vas a ganar más dinero. De hecho yo nunca le pagaría más dinero a alguien por el mero hecho de estar certificado en algo. Yo tengo varias certificaciones Java y conozco mucha gente que sabe muchísimo más que yo.
Beneficios para una plataforma: Las certificaciones son una buena medida de la salud de una plataforma. En cierto modo es un círculo vicioso. Las personas buscan certificarse porque ven que una plataforma es activa y hay demanda en las empresas, y las empresas demandan una plataforma porque ven que hay movimiento en la misma y gente interesada. Normalmente las certificaciones más exitosas y con más gente certificada, te indicará las plataformas que más éxito tienen. Claros ejemplos de esto son Cisco o Microsoft.
Si una plataforma, digamos Eclipse que está muy de moda, saca un camino de certificación, lo normal es que la gente comience a certificarse. Esto llevará a las empresas a valorar estas certificaciones, lo que a su vez llevará a más personas a certificarse, y a más personas que no conocían la plataforma a interesarse por ella por verle salida laboral.
Beneficios para las personas: Una certificación puede darte un trabajo. Así de claro. Puede que no te de un gran sueldo, y seguramente no te va a dar más dinero que otras personas (al menos mucho más), pero una certificación siempre es un punto adicional en el curriculum, que directa o indirectamente se valorará en algún punto del proceso de contratación en una empresa.
Las certificaciones tienen otra serie de beneficios en cuanto a formación, que a veces no se tienen en cuenta. Las certificaciones te proporcionarán una introducción a una tecnología, ya que normalmente se centran en los aspectos básicos. Para las personas como yo, que siempre están con mil cosas, son además un modo de obligare a centrarte en algo y estudiar, lo que siempre es beneficioso. Eso sí, es importante no hacer trampas. Por ejemplo, en su época (no sé si ahora es lo mismo) las certificaciones de microsoft fueron famosas porque las respuestas las podías encontrar en cualquier parte.
Beneficios para las empresas : Para una empresa siempre es bueno que vengan personas con certificaciones a las entrevistas. Estas personas no tienen que ser muy inteligentes, o superestrellas. No existen las certificaciones-para-super-estrella-de-la-programación. Muchas personas no certificadas, atacan a las certificaciones con el argumento de que no demuestran la inteligencia de las personas, que no quiere decir que sean mejor que ellos, etc. Esto no dejan de ser llantos de colegial. Claro que no lo hacen. Las certificaciones no son para demostrar que yo tengo algo que demuestra que soy más listo que tu. Las certificaciones son para garantizarle a una empresa que una persona ha estudiado algo; que al menos tiene unos conocimientos básicos; y sobre todo, y por encima de todo, que una persona no está mintiendo cuando dice "conocimientos de Java".
Ahí está el verdadero valor para las empresas. Hoy en día, cuando te llegan montones de curriculums de gente buscando encontrar trabajo, el tener curriculums con certificaciones significa que al menos esas personas no están mintienedo. Significa que en cierto momento de su carrera estudiaron algo. Eso ya es algo importante. Ahora bien, ¿son inteligentes?, ¿valen para el trabajo? Eso ya lo veremos cuando tengan que venir a la entrevista. Pero vamos, que algún comentario que he leido del estilo "yo no miro para nada las certificaciones, a mi eso no me interesa, las paso por alto". Pues bueno, todo el mundo es libre de pasar por alto la información que quiera, pero hay pocas cosas que te certifican algo como las certificaciones, valga la redundancia.
Por otra parte, el disponer de perfiles con certificaciones es un beneficio para algunas empresas que ofrecen servicios. Esta es la razón de que muchas de ellas obligen a las personas a certificarse. Si la empresa puede ir a un cliente diciendo tengo 100 perfiles certificados en .NET, siempre será indicativo para el cliente. Como decía arriba, quizás no sean 100 cracks, pero por lo menos son 100 personas que cuando dicen que han estudiado algo, no mienten.
Bueno, espero no tener que volver a escribir sobre esto, porque es un tema tan repetido y recurrente. ¿Alguna vez se acabará esta eterna discusión?
Personalmente creo que las certificaciones son algo muy útil, tanto para las plataformas, como para las empresas, como para las personas. Pero antes de exponer porque, me gustaría decir que para mi el estudio de eweek apenas tiene valor. Yo no creo que el valor de las certificaciones esté en que vas a ganar más dinero. De hecho yo nunca le pagaría más dinero a alguien por el mero hecho de estar certificado en algo. Yo tengo varias certificaciones Java y conozco mucha gente que sabe muchísimo más que yo.
Beneficios para una plataforma: Las certificaciones son una buena medida de la salud de una plataforma. En cierto modo es un círculo vicioso. Las personas buscan certificarse porque ven que una plataforma es activa y hay demanda en las empresas, y las empresas demandan una plataforma porque ven que hay movimiento en la misma y gente interesada. Normalmente las certificaciones más exitosas y con más gente certificada, te indicará las plataformas que más éxito tienen. Claros ejemplos de esto son Cisco o Microsoft.
Si una plataforma, digamos Eclipse que está muy de moda, saca un camino de certificación, lo normal es que la gente comience a certificarse. Esto llevará a las empresas a valorar estas certificaciones, lo que a su vez llevará a más personas a certificarse, y a más personas que no conocían la plataforma a interesarse por ella por verle salida laboral.
Beneficios para las personas: Una certificación puede darte un trabajo. Así de claro. Puede que no te de un gran sueldo, y seguramente no te va a dar más dinero que otras personas (al menos mucho más), pero una certificación siempre es un punto adicional en el curriculum, que directa o indirectamente se valorará en algún punto del proceso de contratación en una empresa.
Las certificaciones tienen otra serie de beneficios en cuanto a formación, que a veces no se tienen en cuenta. Las certificaciones te proporcionarán una introducción a una tecnología, ya que normalmente se centran en los aspectos básicos. Para las personas como yo, que siempre están con mil cosas, son además un modo de obligare a centrarte en algo y estudiar, lo que siempre es beneficioso. Eso sí, es importante no hacer trampas. Por ejemplo, en su época (no sé si ahora es lo mismo) las certificaciones de microsoft fueron famosas porque las respuestas las podías encontrar en cualquier parte.
Beneficios para las empresas : Para una empresa siempre es bueno que vengan personas con certificaciones a las entrevistas. Estas personas no tienen que ser muy inteligentes, o superestrellas. No existen las certificaciones-para-super-estrella-de-la-programación. Muchas personas no certificadas, atacan a las certificaciones con el argumento de que no demuestran la inteligencia de las personas, que no quiere decir que sean mejor que ellos, etc. Esto no dejan de ser llantos de colegial. Claro que no lo hacen. Las certificaciones no son para demostrar que yo tengo algo que demuestra que soy más listo que tu. Las certificaciones son para garantizarle a una empresa que una persona ha estudiado algo; que al menos tiene unos conocimientos básicos; y sobre todo, y por encima de todo, que una persona no está mintiendo cuando dice "conocimientos de Java".
Ahí está el verdadero valor para las empresas. Hoy en día, cuando te llegan montones de curriculums de gente buscando encontrar trabajo, el tener curriculums con certificaciones significa que al menos esas personas no están mintienedo. Significa que en cierto momento de su carrera estudiaron algo. Eso ya es algo importante. Ahora bien, ¿son inteligentes?, ¿valen para el trabajo? Eso ya lo veremos cuando tengan que venir a la entrevista. Pero vamos, que algún comentario que he leido del estilo "yo no miro para nada las certificaciones, a mi eso no me interesa, las paso por alto". Pues bueno, todo el mundo es libre de pasar por alto la información que quiera, pero hay pocas cosas que te certifican algo como las certificaciones, valga la redundancia.
Por otra parte, el disponer de perfiles con certificaciones es un beneficio para algunas empresas que ofrecen servicios. Esta es la razón de que muchas de ellas obligen a las personas a certificarse. Si la empresa puede ir a un cliente diciendo tengo 100 perfiles certificados en .NET, siempre será indicativo para el cliente. Como decía arriba, quizás no sean 100 cracks, pero por lo menos son 100 personas que cuando dicen que han estudiado algo, no mienten.
Bueno, espero no tener que volver a escribir sobre esto, porque es un tema tan repetido y recurrente. ¿Alguna vez se acabará esta eterna discusión?
domingo, noviembre 05, 2006
J2SE 6.0
domingo, noviembre 05, 2006 por Martín
Este fin de semana he leido el libro Java 6 Patform Revealed del que probablemente sea el escritor Java más mítico John Zukowski. El libro, no es precisamente una maravilla. Nada que no puedas encontrar online, es decir, descripciones por encima y mucho código fuente. Pero cumple su labor de darte una idea de lo que va a venir (aún así no me gustan demasiado este tipo de libros, ya que me parecen muy "oportunistas").
Sea como sea, yo no quería escribir sobre el libro en sí. Al acabar de leerlo, he recordado hace seis o siete años cuando leias sobre el JDK 1.1 y el JDK 1.2, y vaya, ¡como ha cambiado todo! Incluso si comparamos Java 6, con el JDK 1.4, la diferencia es abismal. Soporte de lenguaje de scripting, las APIs de servicios web, JAXB, XML streaming, XML Digital Signature, el API de compilación, las novedades de Swing, las nuevas anotaciones y el soporte para crearlas, ...
Uno llega a plantearse si esto es realmente racional. Quizás es que llevé muchos años programando con el JDK 1.4 (incluso con las APIs de XML que tantos problemas dan), pero parece que desde ese momento las cosas no han hecho más que complicarse para los desarrolladores nuevos. Incluso cuando el objetivo principal de cada una de las nuevas releases siempre ha sido incrementar la productividad y hacer la plataforma más fácil. Pero lo cierto, es que yo cada vez dudo más que lo hayan conseguido.
Que no se me entienda mal, ahora por ejemplo tengo la oportunidad de programar con el JDK 1.5, y me lo paso en grande. Disfruto como un enano con las nuevas funcionalidades; y probablemente en unos años pase lo mismo con Java 6. Pero si uno se pone a pensar en las personas que entran al lenguaje. ¡Vaya!. Afrontar Java 6 no es como afrontar Java 1.2. Al final supongo que realmente será todo una cuestión de marketing y competencia. ¿Realmente necesitamos que las APIs de servicios web estén en el paquete completo? ¿Realmente hace falta que el soporte de firma digital de XML esté en el JDK?
La verdad, es que después de leer el libro, te das cuenta de que los principales cambios de Java 6 se produjeron ya al menos un año atrás, y que Java 6 lo que hará será incluir todos esos JSRs en lo que poco a poco se está convirtiendo en un enorme bundle cada vez mayor.
Lo cierto es que hace años te podías estudiar varios libros y decir soy un experto en JavaSE. Con el JDK 1.5 nos pusieron las cosas un poco más difíciles, pero tampoco demasiado, porque ni el API de profiling o la de JMX molestan demasiado. Pero lo cierto es que ahora, con todas estas APIs, va a ser difícil que alguien pueda decir, lo sé absolutamente todo sobre J2SE. Pero bueno, eso creo que era algo que prácticamente ya no se podía decir desde hace muchos años.
Sea como sea, yo no quería escribir sobre el libro en sí. Al acabar de leerlo, he recordado hace seis o siete años cuando leias sobre el JDK 1.1 y el JDK 1.2, y vaya, ¡como ha cambiado todo! Incluso si comparamos Java 6, con el JDK 1.4, la diferencia es abismal. Soporte de lenguaje de scripting, las APIs de servicios web, JAXB, XML streaming, XML Digital Signature, el API de compilación, las novedades de Swing, las nuevas anotaciones y el soporte para crearlas, ...
Uno llega a plantearse si esto es realmente racional. Quizás es que llevé muchos años programando con el JDK 1.4 (incluso con las APIs de XML que tantos problemas dan), pero parece que desde ese momento las cosas no han hecho más que complicarse para los desarrolladores nuevos. Incluso cuando el objetivo principal de cada una de las nuevas releases siempre ha sido incrementar la productividad y hacer la plataforma más fácil. Pero lo cierto, es que yo cada vez dudo más que lo hayan conseguido.
Que no se me entienda mal, ahora por ejemplo tengo la oportunidad de programar con el JDK 1.5, y me lo paso en grande. Disfruto como un enano con las nuevas funcionalidades; y probablemente en unos años pase lo mismo con Java 6. Pero si uno se pone a pensar en las personas que entran al lenguaje. ¡Vaya!. Afrontar Java 6 no es como afrontar Java 1.2. Al final supongo que realmente será todo una cuestión de marketing y competencia. ¿Realmente necesitamos que las APIs de servicios web estén en el paquete completo? ¿Realmente hace falta que el soporte de firma digital de XML esté en el JDK?
La verdad, es que después de leer el libro, te das cuenta de que los principales cambios de Java 6 se produjeron ya al menos un año atrás, y que Java 6 lo que hará será incluir todos esos JSRs en lo que poco a poco se está convirtiendo en un enorme bundle cada vez mayor.
Lo cierto es que hace años te podías estudiar varios libros y decir soy un experto en JavaSE. Con el JDK 1.5 nos pusieron las cosas un poco más difíciles, pero tampoco demasiado, porque ni el API de profiling o la de JMX molestan demasiado. Pero lo cierto es que ahora, con todas estas APIs, va a ser difícil que alguien pueda decir, lo sé absolutamente todo sobre J2SE. Pero bueno, eso creo que era algo que prácticamente ya no se podía decir desde hace muchos años.
Lo difícil que es comenzar en una empresa de software
domingo, noviembre 05, 2006 por Martín
Este post no va sobre mi, aunque pudiese parecerlo inicialmente por el título, sino de muchos de los compañeros de mi empresa. Nuestra empresa ha recibido una inyección muy importante de fondos este año, lo que ha hecho que de repente este verano hubo muchísimas incorporaciones nuevas.
Hace unos días, tuvimos el "induction course", que básicamente consiste en irnos presentando a los nuevos, los diferentes managers que hay en la jerarquía de la empresa. Al terminar este curso, los nuevos tuvimos la oportunidad de expresar nuestras opiniones, en corro, al más puro estilo alcohólicos anónimos. Lo más destacado de los comentarios que hubo, fue el ver que prácticamente todo el mundo se quejaba de lo difícil que resultaba ser productivo en los primeros meses de nuestra empresa. Eso tiene una consecuencia muy importante, ya que al pasar tres meses te tienen que valorar tu trabajo para decidir si pasas el periodo de pruebas. Como consecuencia, había mucha gente que decía que tras dos meses en la empresa, sólo habían podido empezar a rendir después de los dos primeros meses, y que por lo tanto la medida podía resultar bastante injusta.
La verdad es que puedo dar fe de que no mienten. La cantidad de esfuerzo que hay que hacer para configurar nuestro sistema es enorme (de hecho, una de mis labores de la que hablaré en cuanto tenga un rato fue la de hacer una herramienta para la creación automática de clusters Weblogic) en cuanto a tecnologías que tienes que aprender, en cuanto a conocimientos, en cuanto a configuración del entorno (varios productos, varias versiones y subversiones, +100 proyectos Eclipse, ...). Y a todo esto le tienes que sumar todas las APIs que tenemos definidas: sistema de caché, notificaciones distribuidas, replicación, y el resto de APIs que tienen que ver con el negocio.
Una vez explicado el escenario voy a hablar de lo que yo creo que es el problema en este caso. En mi opinión, en las empresas de software, parece que hay una tendencia a pensar que los programadores son auténticas máquinas de conocimiento, personas que por el mero hecho de programar un ordenador, ya lo saben absolutamente todo. Esta tendencia hace que cuando una persona llega a una empresa se le diga "ahí tienes tu PC, ahora te decimos todo lo que tienes que configurar y empiezas a trabajar". ¿Cuántas veces habéis visto esto? ¿Cuántas veces habéis visto que al nuevo se le da su PC, se habla con el una horita, y a trabajar?
Curiosamente, esto no sucede, o no parece suceder, en otros entornos. Si vas a un banco, verás que al nuevo no le dejan dar dinero, o recoger ingresos, o ... nada; si vas a un hotel verás que al nuevo no le dejan hacer una entrada, o una salida, o ... nada; si vas a una recepción verás como el nuevo está detras de otro recepcionista atentamente escuchando y mirando lo que pasa. Así podría seguir con otros ejemplos. El caso es que en todas estas situaciones, la persona pasa por un proceso de aprendizaje, que puede durar días, o incluso varias semanas. ¿Por qué en el mundo del software, el nuevo puede empezar a tocar código sin recibir ni siquiera unas simples directrices? ¿Somos realmente tan buenos los programadores para poder darnos ese grado de confianza ciega?
La solución es simple, aunque estemos hasta el cuello de trabajo, habría que dedicar al menos una semana en explicar todo lo que "el nuevo" necesita saber para ser realmente productivo en su trabajo. Esa semana, se puede dividir entre los diferentes miembros de un equipo, pero sería muy importante que durante esa semana se hiciera una experiencia del estilo "pair programming", igual que en otros sitios hacen "pair recepcioning", "pair banking", o "pair hotelling". A la larga, estamos perdiendo un poco de productividad a corto plazo, para obtener una productividad mucho mayor, porque con un poco de suerte esta persona podrá empezar a ser productiva tras esa semana de entrenamiento.
Hace unos días, tuvimos el "induction course", que básicamente consiste en irnos presentando a los nuevos, los diferentes managers que hay en la jerarquía de la empresa. Al terminar este curso, los nuevos tuvimos la oportunidad de expresar nuestras opiniones, en corro, al más puro estilo alcohólicos anónimos. Lo más destacado de los comentarios que hubo, fue el ver que prácticamente todo el mundo se quejaba de lo difícil que resultaba ser productivo en los primeros meses de nuestra empresa. Eso tiene una consecuencia muy importante, ya que al pasar tres meses te tienen que valorar tu trabajo para decidir si pasas el periodo de pruebas. Como consecuencia, había mucha gente que decía que tras dos meses en la empresa, sólo habían podido empezar a rendir después de los dos primeros meses, y que por lo tanto la medida podía resultar bastante injusta.
La verdad es que puedo dar fe de que no mienten. La cantidad de esfuerzo que hay que hacer para configurar nuestro sistema es enorme (de hecho, una de mis labores de la que hablaré en cuanto tenga un rato fue la de hacer una herramienta para la creación automática de clusters Weblogic) en cuanto a tecnologías que tienes que aprender, en cuanto a conocimientos, en cuanto a configuración del entorno (varios productos, varias versiones y subversiones, +100 proyectos Eclipse, ...). Y a todo esto le tienes que sumar todas las APIs que tenemos definidas: sistema de caché, notificaciones distribuidas, replicación, y el resto de APIs que tienen que ver con el negocio.
Una vez explicado el escenario voy a hablar de lo que yo creo que es el problema en este caso. En mi opinión, en las empresas de software, parece que hay una tendencia a pensar que los programadores son auténticas máquinas de conocimiento, personas que por el mero hecho de programar un ordenador, ya lo saben absolutamente todo. Esta tendencia hace que cuando una persona llega a una empresa se le diga "ahí tienes tu PC, ahora te decimos todo lo que tienes que configurar y empiezas a trabajar". ¿Cuántas veces habéis visto esto? ¿Cuántas veces habéis visto que al nuevo se le da su PC, se habla con el una horita, y a trabajar?
Curiosamente, esto no sucede, o no parece suceder, en otros entornos. Si vas a un banco, verás que al nuevo no le dejan dar dinero, o recoger ingresos, o ... nada; si vas a un hotel verás que al nuevo no le dejan hacer una entrada, o una salida, o ... nada; si vas a una recepción verás como el nuevo está detras de otro recepcionista atentamente escuchando y mirando lo que pasa. Así podría seguir con otros ejemplos. El caso es que en todas estas situaciones, la persona pasa por un proceso de aprendizaje, que puede durar días, o incluso varias semanas. ¿Por qué en el mundo del software, el nuevo puede empezar a tocar código sin recibir ni siquiera unas simples directrices? ¿Somos realmente tan buenos los programadores para poder darnos ese grado de confianza ciega?
La solución es simple, aunque estemos hasta el cuello de trabajo, habría que dedicar al menos una semana en explicar todo lo que "el nuevo" necesita saber para ser realmente productivo en su trabajo. Esa semana, se puede dividir entre los diferentes miembros de un equipo, pero sería muy importante que durante esa semana se hiciera una experiencia del estilo "pair programming", igual que en otros sitios hacen "pair recepcioning", "pair banking", o "pair hotelling". A la larga, estamos perdiendo un poco de productividad a corto plazo, para obtener una productividad mucho mayor, porque con un poco de suerte esta persona podrá empezar a ser productiva tras esa semana de entrenamiento.
lunes, octubre 30, 2006
¿Hay algo mejor?
lunes, octubre 30, 2006 por Martín
Alberto se queja en el weblog de Linking Paths de lo complicado que puede llegar a ser el obtener el personal adecuado a través de sitios de trabajo como puedan ser infoempleo, infojobs, etc.
Pero, ¿y si el problema no está en esos sitios web? Y si el problema es simplemente que la gente que busca trabajo en la actualidad no es como la gente que buscaba trabajo hace diez años. Yo pertenezco a una generación en la que creo que la gente soñaba con ser programador, con poner a tus pies estos aparatos que en muchísimos de nosotros hasta no nos podíamos permitir. Para mi, ir a clasede informática de niño, era lo mejor que me pasaba en la semana porque podía tener en mis manos un aparato que ni en sueños podríamos comprar. Con ese aparato lo máximo que podías era programar en basic, editar textos con el wordstar, poner algún casette con algún juego cuando los profes te dejaban, ... era tan bonito.
Pero me temo que si miras la situación de la cantera informática del futuro (10..20), me temo que la cosa está muy negra. Ahora mismo hay tantos juegos, tanto software, que probablemente a un chaval se le quiten las ganas de "quiero hacer eso". Una persona "quiere hacer eso" cuando es algo especial, pero hoy por hoy, me temo que hacer programas ya no es algo tan especial como hace años. Esto ayuda mucho a que se haga más débil el concepto de "vocación".
Por otra parte, hoy por hoy los ordenadores y las videoconsolas se han convertido en el centro de ocio de la juventud, superando claramente a la televisión. Las personas se pasan horas, dias o meses chateando compulsivamente, jugando a decenas de juegos, divirtiéndose en mundos imaginarios y tremendamente adictivos como los de los MMORPGs, etc. En esta situación, es muy difícil que la gente se dedique a aprender. Hace años un joven con un ordenador, probableente fuera lo suficientemente avispado como para crear un bonito programa de contabilidad con su turbo pascal y divertirse con ello. Hoy, lo que se lleva es tratar de descargarse la mayor cantidad de películas posibles y echar unas partidas con tus colegas al world of warcraft.
No creo que esto sea un arrebato de "nosotros eramos los mejores". Comentando con amigos de mi época y que ahora son profesores de Universidad, todos comentan lo mismo. Ha habido un bajón enorme en la calidad de la enseñanza que se daba en las universidades de informática, y no porque los profesores sean malos, sino porque los alumnos no pueden asumir la información que podían asumir antes. Y con el tiempo, esto se tiene que notar en el mercado laboral. Obviamente, sería estúpido generalizar, siempre hay gente apasionada como la que busca Joel, pero me temo que la situación pinta muy mal en estos momentos, al menos en el mercado español.
Pero, ¿y si el problema no está en esos sitios web? Y si el problema es simplemente que la gente que busca trabajo en la actualidad no es como la gente que buscaba trabajo hace diez años. Yo pertenezco a una generación en la que creo que la gente soñaba con ser programador, con poner a tus pies estos aparatos que en muchísimos de nosotros hasta no nos podíamos permitir. Para mi, ir a clasede informática de niño, era lo mejor que me pasaba en la semana porque podía tener en mis manos un aparato que ni en sueños podríamos comprar. Con ese aparato lo máximo que podías era programar en basic, editar textos con el wordstar, poner algún casette con algún juego cuando los profes te dejaban, ... era tan bonito.
Pero me temo que si miras la situación de la cantera informática del futuro (10..20), me temo que la cosa está muy negra. Ahora mismo hay tantos juegos, tanto software, que probablemente a un chaval se le quiten las ganas de "quiero hacer eso". Una persona "quiere hacer eso" cuando es algo especial, pero hoy por hoy, me temo que hacer programas ya no es algo tan especial como hace años. Esto ayuda mucho a que se haga más débil el concepto de "vocación".
Por otra parte, hoy por hoy los ordenadores y las videoconsolas se han convertido en el centro de ocio de la juventud, superando claramente a la televisión. Las personas se pasan horas, dias o meses chateando compulsivamente, jugando a decenas de juegos, divirtiéndose en mundos imaginarios y tremendamente adictivos como los de los MMORPGs, etc. En esta situación, es muy difícil que la gente se dedique a aprender. Hace años un joven con un ordenador, probableente fuera lo suficientemente avispado como para crear un bonito programa de contabilidad con su turbo pascal y divertirse con ello. Hoy, lo que se lleva es tratar de descargarse la mayor cantidad de películas posibles y echar unas partidas con tus colegas al world of warcraft.
No creo que esto sea un arrebato de "nosotros eramos los mejores". Comentando con amigos de mi época y que ahora son profesores de Universidad, todos comentan lo mismo. Ha habido un bajón enorme en la calidad de la enseñanza que se daba en las universidades de informática, y no porque los profesores sean malos, sino porque los alumnos no pueden asumir la información que podían asumir antes. Y con el tiempo, esto se tiene que notar en el mercado laboral. Obviamente, sería estúpido generalizar, siempre hay gente apasionada como la que busca Joel, pero me temo que la situación pinta muy mal en estos momentos, al menos en el mercado español.
sábado, octubre 28, 2006
Futbol gaélico
sábado, octubre 28, 2006 por Martín
Están echando por la tele las International Rules Series, que viene a ser un partido de fútbol gaélico que se celebra desde hace tiempo aquí en Irlanda, entre los equipos internacionales de Irlanda y Australia.
La verdad es que esto del fútbol gaélico es una auténtica religión aquí en Irlanda. Ahora mismo acaba de acabar el partido e Irlanda ha ganado 48-40 a Australia. Por ahora no hay videos de esta final, pero si alguien no conoce como se las gastan estos equipos, que le eche un vistazo a este video.
La verdad es que esto del fútbol gaélico es una auténtica religión aquí en Irlanda. Ahora mismo acaba de acabar el partido e Irlanda ha ganado 48-40 a Australia. Por ahora no hay videos de esta final, pero si alguien no conoce como se las gastan estos equipos, que le eche un vistazo a este video.
El martes es Halloween
sábado, octubre 28, 2006 por Martín
Pues sí, el martes se celebra Halloween aquí en Irlanda, que quizás no todo el mundo sepa que es una fiesta que proviene de la cultura celta aquí en Irlanda, y que se trasladó a Estados Unidos (donde seguramente es más conocida) a través de los inmigrantes irlandeses. (http://es.wikipedia.org/wiki/Halloween).
Será mi primer Halloween aquí en Dublín, y hay que reconocer que aquí lo viven. Lo que no tengo todavía muy claro es cuando se celebra, porque curiosamente el día festivo aquí es el lunes, y no el martes 31.
Y es que esto es una de las cosas que me ha chocado aquí en Irlanda. Todos los festivos (salvo Navidad y Epifanía) se mueven siempre al lunes de la semana en la que se celebre el festivo. No está mal la fórmula, de hecho hay mucha gente que así aprovecha y coge el viernes anterior y se va de vacaciones. Además, como sabes que eso pasa así con todos los festivos, pues puedes planificar viajes bastante interesantes a largo plazo.
Esperemos que no vengan muchos niños por la puerta, porque con eso del "o me das algo o te hago una travesura", pues casi que va a haber muchas travesuras por aquí :-)
Será mi primer Halloween aquí en Dublín, y hay que reconocer que aquí lo viven. Lo que no tengo todavía muy claro es cuando se celebra, porque curiosamente el día festivo aquí es el lunes, y no el martes 31.
Y es que esto es una de las cosas que me ha chocado aquí en Irlanda. Todos los festivos (salvo Navidad y Epifanía) se mueven siempre al lunes de la semana en la que se celebre el festivo. No está mal la fórmula, de hecho hay mucha gente que así aprovecha y coge el viernes anterior y se va de vacaciones. Además, como sabes que eso pasa así con todos los festivos, pues puedes planificar viajes bastante interesantes a largo plazo.
Esperemos que no vengan muchos niños por la puerta, porque con eso del "o me das algo o te hago una travesura", pues casi que va a haber muchas travesuras por aquí :-)
Lo importante de saber cuando ser ágil.
sábado, octubre 28, 2006 por Martín
Uno de los peligros de las tendencias como las metodologías ágiles es que rápidamente hay gente que las aplica por conveniencia. No le ha pasado a nadie últimamente el encontrarse con algo que parece muy simple, y de pronto una persona que lo ve complicado se escuda en el "debemos hacerlo más simple como mandan las metodologías ágiles".
La verdad es que esto es algo con lo que me he encontrado varias veces, pero esta semana me ha hecho mucha gracia. Estabamos rediseñando un modelo de datos y básicamente yo promovía un modelo de datos algo más abstracto basado en interfaces y clases abstractas para intentar escudar un poco la implementación, mientras que mi compañero simplemente prefería tener implementaciones planas. Y resulta que todo esto era porque no le gustaba ver muchas clases en el entorno de desarrollo, que era un lío, que era muy fácil perderse, y que las metodologías ágiles decían que las cosas tienen que ser lo más simples posibles.
Asombrado me quedé. En fin, ante estas situaciones supongo que lo mejor es ser diplomático e intentar buscar una solución intermedia como la que encontramos, pero no me deja de ser curioso algo como esto. En definitiva, ágil no quiere decir trivial, y creo que eso es importante a la hora de diseñar sistemas.
Por suerte, al final el diseño quedó bastante bien :)
La verdad es que esto es algo con lo que me he encontrado varias veces, pero esta semana me ha hecho mucha gracia. Estabamos rediseñando un modelo de datos y básicamente yo promovía un modelo de datos algo más abstracto basado en interfaces y clases abstractas para intentar escudar un poco la implementación, mientras que mi compañero simplemente prefería tener implementaciones planas. Y resulta que todo esto era porque no le gustaba ver muchas clases en el entorno de desarrollo, que era un lío, que era muy fácil perderse, y que las metodologías ágiles decían que las cosas tienen que ser lo más simples posibles.
Asombrado me quedé. En fin, ante estas situaciones supongo que lo mejor es ser diplomático e intentar buscar una solución intermedia como la que encontramos, pero no me deja de ser curioso algo como esto. En definitiva, ágil no quiere decir trivial, y creo que eso es importante a la hora de diseñar sistemas.
Por suerte, al final el diseño quedó bastante bien :)
sábado, octubre 21, 2006
Finalmente, desde Dublín
sábado, octubre 21, 2006 por Martín
Despues de algo más de dos meses, por fin me encuentro lo suficientemente asentado como para continuar este blog. Han sido un par de meses realmente emocionantes. Si alguien no ha experimentado todavía la sensación de pegar un volantazo a su ritmo de vida, cambiando de trabajo, de lugar de residencia o incluso de pais, yo le animaría a hacerlo. Para mi está siendo una experiencia realmente enriquecedora.
Finalmente estoy escribiendo esta entrada sentado en mi casa, y ya era hora, porque ha resultado que obtener una línea de Internet en esta ciudad, no es algo tan sencillo como me imaginaba. La verdad es que tienes un monton de opciones: modem tradicional, cable por TV, ADSL, wireless, satelite. Pero el proceso de darse de alta es realmente retorcido.
Sea como sea, aqui estamos, con una conexión de 3Mb y 100 canales de TV (de los que se salvarán 2, como en España), por 30 y pico euros, que creo que no está nada mal.
Bueno, poco a poco iré hablando sobre como es la vida aquí, el trabajo, etc. No quiero que este blog se vaya a convertir en un diario sobre la vida en Dublín, pero empezaré a dejar caer cosillas por aquí.
Hasta pronto.
Finalmente estoy escribiendo esta entrada sentado en mi casa, y ya era hora, porque ha resultado que obtener una línea de Internet en esta ciudad, no es algo tan sencillo como me imaginaba. La verdad es que tienes un monton de opciones: modem tradicional, cable por TV, ADSL, wireless, satelite. Pero el proceso de darse de alta es realmente retorcido.
Sea como sea, aqui estamos, con una conexión de 3Mb y 100 canales de TV (de los que se salvarán 2, como en España), por 30 y pico euros, que creo que no está nada mal.
Bueno, poco a poco iré hablando sobre como es la vida aquí, el trabajo, etc. No quiero que este blog se vaya a convertir en un diario sobre la vida en Dublín, pero empezaré a dejar caer cosillas por aquí.
Hasta pronto.
domingo, agosto 06, 2006
Cambio de aires: ¡Porco killin!
domingo, agosto 06, 2006 por Martín
Después de más de cuatro años en el mismo cliente, con la misma gente, y prácticamente se podría decir que en la misma empresa hace unas semanas tomé la decisión de darle un giro drástico a mi carrera.
A veces es muy difícil tomar este tipo de decisiones. Sobre todo cuando tienes un horario envidiable, un buen salario, un buen ambiente de trabajo, cuando careces de presión laboral, cuando tu cliente te da total libertad para realizar labores extralaborales o incluso pagarte de su bolsillo la formación, cuando tu empresa deposita su confianza en ti y te otorga responsabilidad. En fin, podría seguir con la lista de ventajas de mi todavía trabajo actual.
Pero lo cierto es que las personas parece que nunca tenemos suficiente. Desde hace años tenía muchísimas ganas de ir a trabajar al extranjero, y al final es lo que he decidido hacer. Me voy a Dublin a trabajar a una compañía importante dentro del mundo de las finanzas y la bolsa. Cambio tranquilidad por estrés, horario de mañana por horario europeo con alguna hora más, buen ambiente por ambiente indeterminado, una gran confianza por empezar desde cero, y tranquilidad por aprendizaje.
Empiezo una época de aprender. Hacía muchos años que no me sentía como me siento ahora mismo, con una ilusión enorme por ir a trabajar. Y es eso lo que me dice en cada momento que he hecho lo adecuado. Esa sensación de descubrir un nuevo mundo, de aprender nuevas cosas, de experimentar nuevas sensaciones, de tener que coger diez libros que no conocías y empezar a empaparte de cosas nuevas. Todo eso que hice cuando empezaba en mi actual trabajo y que estoy deseando volver a hacer.
Eso sí, quizás al final resulta que todo se viene abajo y que las cosas no eran tan bonitas como parecían. Entonces será igual, será como recibir una catalización de formación. Experiencia.
Por cierto, me llevo muchos recuerdos a Irlanda. El Viernes fue mi comida de despedida con mis compañeros. Los mejores compañeros del mundo. Y gracias a ellos voy a ir con mucha fuerza a Dublin. Me los voy a comer a todos. Porco killin!
A veces es muy difícil tomar este tipo de decisiones. Sobre todo cuando tienes un horario envidiable, un buen salario, un buen ambiente de trabajo, cuando careces de presión laboral, cuando tu cliente te da total libertad para realizar labores extralaborales o incluso pagarte de su bolsillo la formación, cuando tu empresa deposita su confianza en ti y te otorga responsabilidad. En fin, podría seguir con la lista de ventajas de mi todavía trabajo actual.
Pero lo cierto es que las personas parece que nunca tenemos suficiente. Desde hace años tenía muchísimas ganas de ir a trabajar al extranjero, y al final es lo que he decidido hacer. Me voy a Dublin a trabajar a una compañía importante dentro del mundo de las finanzas y la bolsa. Cambio tranquilidad por estrés, horario de mañana por horario europeo con alguna hora más, buen ambiente por ambiente indeterminado, una gran confianza por empezar desde cero, y tranquilidad por aprendizaje.
Empiezo una época de aprender. Hacía muchos años que no me sentía como me siento ahora mismo, con una ilusión enorme por ir a trabajar. Y es eso lo que me dice en cada momento que he hecho lo adecuado. Esa sensación de descubrir un nuevo mundo, de aprender nuevas cosas, de experimentar nuevas sensaciones, de tener que coger diez libros que no conocías y empezar a empaparte de cosas nuevas. Todo eso que hice cuando empezaba en mi actual trabajo y que estoy deseando volver a hacer.
Eso sí, quizás al final resulta que todo se viene abajo y que las cosas no eran tan bonitas como parecían. Entonces será igual, será como recibir una catalización de formación. Experiencia.
Por cierto, me llevo muchos recuerdos a Irlanda. El Viernes fue mi comida de despedida con mis compañeros. Los mejores compañeros del mundo. Y gracias a ellos voy a ir con mucha fuerza a Dublin. Me los voy a comer a todos. Porco killin!
martes, agosto 01, 2006
Escoge tu modelo de datos
martes, agosto 01, 2006 por Martín
Alguien ha estado recopilando una librería con modelos de datos para diferentes negocios y situaciones. No lo he repasado con profundidad, así que no estoy seguro de lo exactos que pueden ser. A primera vista parecen bastante genéricos sin entrar en muchos detalles concretos, pero no deja de ser algo interesante.
El Maradona de Amsterdam
martes, agosto 01, 2006 por Martín
Después de un pequeño lapso de tiempo vuelvo a la actividad en el blog. Sé que no he avisado, pero me he tomado unas vacaciones de un par de semanas en las que tuve el placer de visitar Flandes y Amsterdam. Flandes es espectacular, intentaré poner algunas frotos en breve, y Amsterdam es la fiesta personalizada.
En Amsterdam, como en otras ciudades, es muy común encontrarse con personas que realizan actuaciones callejeras para ganarse algún dinero. En los cuatro días que estuve en esa ciudad pude ver grupos de música, actuaciones de capoeira, payasos, solitas, duetos, pero el que más me impacto fue sin duda al que en YouTube denominan como el Maradona de Amsterdam.
Este es un enlace a un video subido a YouTube con la actuación de esta persona. Es realmente espectacular lo que es capaz de llegar a hacer con un balón. Y os puedo asegurar que todo es verídico, incluso la parte final que es simplemente impresionante.
Disfrutarlo.
En Amsterdam, como en otras ciudades, es muy común encontrarse con personas que realizan actuaciones callejeras para ganarse algún dinero. En los cuatro días que estuve en esa ciudad pude ver grupos de música, actuaciones de capoeira, payasos, solitas, duetos, pero el que más me impacto fue sin duda al que en YouTube denominan como el Maradona de Amsterdam.
Este es un enlace a un video subido a YouTube con la actuación de esta persona. Es realmente espectacular lo que es capaz de llegar a hacer con un balón. Y os puedo asegurar que todo es verídico, incluso la parte final que es simplemente impresionante.
Disfrutarlo.
jueves, julio 13, 2006
El outsourcing en decadencia en Estados Unidos
jueves, julio 13, 2006 por Martín
En esta noticia de eweek se afirma que el boom del outsorcing en Estados Unidos ha terminado según estudio de la firma de Chicago, DiamondCluster. En este estudio se puede leer que las compañías americanas están realmente descontentas con el rendimiento de los sistemas externalizados a través de outsourcing, resultando en cifras tan alarmantes como la de que el 47% de los encuestados tuvo que rescindir algún contrato en los últimos 12 meses debido al bajo rendimiento.
Pero quizás los más preocupante del estudio es la tendencia, según DiamondCluster, de estos clientes de outsorcing a mover los proyectos fuera de su país migrando a un modelo offshore. Según esta compañía los clientes encuentran más beneficios en los sistemas offshore debido a sus bajos costes y a la facilidad para conseguir certificaciones como CMMI por ejemplo.
En el estudio se puede leer también que los destinos más atractivos para externalizar fuera de Estados Unidos están siendo China y Europa del Este, y con un sorprendente aumento también de sistemas migrados hacia Canada.
¿Veremos esto en España? Parece poco probable siendo uno de los países más baratos de la Europa occidental.
Pero quizás los más preocupante del estudio es la tendencia, según DiamondCluster, de estos clientes de outsorcing a mover los proyectos fuera de su país migrando a un modelo offshore. Según esta compañía los clientes encuentran más beneficios en los sistemas offshore debido a sus bajos costes y a la facilidad para conseguir certificaciones como CMMI por ejemplo.
En el estudio se puede leer también que los destinos más atractivos para externalizar fuera de Estados Unidos están siendo China y Europa del Este, y con un sorprendente aumento también de sistemas migrados hacia Canada.
¿Veremos esto en España? Parece poco probable siendo uno de los países más baratos de la Europa occidental.
miércoles, julio 12, 2006
MySpace, el rey de las redes sociales
miércoles, julio 12, 2006 por Martín
Hace tiempo comentaba una conocida consultora y formadora americana y blogger del mundo Java que su hija le había dicho lo siguiente: "Mamá, si no estás en MySpace, no eres nadie."
Y es que según lo que he leido hoy en esta entrada de GurusBlog, parece que es verdad. MySpace se ha convertido en la web más visitada en Estados Unidos. Si señor, ni un periódico, ni un buscador, ni un portal de servicio, sino que una red social. Los datos de estadística son simplemente impresionantes y me tomo la licencia de copiarlos aquí:
* Más de 75 millones de usuarios
* 15 millones de usuarios únicos diarios
* 250.000 nuevos usuarios por día
* 30.000 millones de páginas vistas diaris
* <10.500 páginas vistas por segundo
* >Como hemos visto anteriormente, 4,45% de todas las visitas en las webs de EE.UU, superando a Yahoo Mail, Yahoo Hone page, Google y MSN Hotmail.
* Crecimiento del 4300% en el número de visitas de los dos últimos años, y del 132% en el último año.
* MySpace ha capturado casi el 80% de cuota de mercado de las “redes sociales”, seguido muy de lejos por Facebook con un 7,58%, y Xanga con un 3,81%…La red
social de Yahoo, 360.yahoo.com, sólo alcanza un paupérrimo 1,13%, y la de Google, Orkut, se queda en un 0,30%.
* El tráfico generado en internet por la búsqueda de términos relacionados con MySpace (myspace, myspace.com, my space, www.myspace.com, myspace layouts), representan el 1,85% de todas las búsquedas, estando las 5 entre los 20 términos más buscados.
¿Por qué no acaban de despuntar estas cosas aquí? Pues probablemente porque no hay todavía esa cultura de ordenador entre los adolescentes. Pero eso cambiará en cinco o seis años. Ahora son pocos los que no se conectan al messenger a menudo, y pronto darán el salto tecnológico a las redes sociales. Entonces triunfarán.
Y es que según lo que he leido hoy en esta entrada de GurusBlog, parece que es verdad. MySpace se ha convertido en la web más visitada en Estados Unidos. Si señor, ni un periódico, ni un buscador, ni un portal de servicio, sino que una red social. Los datos de estadística son simplemente impresionantes y me tomo la licencia de copiarlos aquí:
* Más de 75 millones de usuarios
* 15 millones de usuarios únicos diarios
* 250.000 nuevos usuarios por día
* 30.000 millones de páginas vistas diaris
* <10.500 páginas vistas por segundo
* >Como hemos visto anteriormente, 4,45% de todas las visitas en las webs de EE.UU, superando a Yahoo Mail, Yahoo Hone page, Google y MSN Hotmail.
* Crecimiento del 4300% en el número de visitas de los dos últimos años, y del 132% en el último año.
* MySpace ha capturado casi el 80% de cuota de mercado de las “redes sociales”, seguido muy de lejos por Facebook con un 7,58%, y Xanga con un 3,81%…La red
social de Yahoo, 360.yahoo.com, sólo alcanza un paupérrimo 1,13%, y la de Google, Orkut, se queda en un 0,30%.
* El tráfico generado en internet por la búsqueda de términos relacionados con MySpace (myspace, myspace.com, my space, www.myspace.com, myspace layouts), representan el 1,85% de todas las búsquedas, estando las 5 entre los 20 términos más buscados.
¿Por qué no acaban de despuntar estas cosas aquí? Pues probablemente porque no hay todavía esa cultura de ordenador entre los adolescentes. Pero eso cambiará en cinco o seis años. Ahora son pocos los que no se conectan al messenger a menudo, y pronto darán el salto tecnológico a las redes sociales. Entonces triunfarán.
viernes, julio 07, 2006
Programadores baratos en barcos por California
viernes, julio 07, 2006 por Martín
Parece que hay una nueva tendencia en los cruceros para este verano, se trata de recoger programadores de la India y paises del Este y llevarlos a realizar un crucero por las costas californianas. De paso, mientras disfrutan de sus vacaciones, pueden realizar su jornada laboral.
Evidentemente, lo del crucero es ironía, la realidad es que SeaCode, la compañía que trata de alterar el modelo de contratación offshore lo que intenta es abaratar el coste para las empresas americanas al tiempo que evitar la burocracia de tener que obtener visados para los trabajadores.
Vaya .... esto ..... despreciable.
El enlace a la noticia.
Evidentemente, lo del crucero es ironía, la realidad es que SeaCode, la compañía que trata de alterar el modelo de contratación offshore lo que intenta es abaratar el coste para las empresas americanas al tiempo que evitar la burocracia de tener que obtener visados para los trabajadores.
Vaya .... esto ..... despreciable.
El enlace a la noticia.
miércoles, julio 05, 2006
martes, julio 04, 2006
Software bajo demanda de verdad
martes, julio 04, 2006 por Martín
Y otro sobre Eclipse. Buscando descargas de Callisto me he encontrado con esto: Yoxos Eclipse on Demand. Es de lo mejorcito que me he encontrado en cuanto a descargas y configuración de entornos de desarrollo.
Vaya, que si vais a la página de Yoxos os encontraréis con una especie de Eclipse en web (mucho AJAX hay ahí) en el que podéis seleccionar todas las partes de Callisto que queréis y configuraros así vuestro entorno de desarrollo preferido. Por si fuese poco, en la parte de abajo podréis encontrar montones de plug-ins de terceros para de este modo crearos una super-distribución-personalizada-de-Eclipse. ¡Y encima el sistema te chequea las dependencias de manera automática!
Enhorabuena para Yoxos. Gran sistema, gran idea y gran producto.
Vaya, que si vais a la página de Yoxos os encontraréis con una especie de Eclipse en web (mucho AJAX hay ahí) en el que podéis seleccionar todas las partes de Callisto que queréis y configuraros así vuestro entorno de desarrollo preferido. Por si fuese poco, en la parte de abajo podréis encontrar montones de plug-ins de terceros para de este modo crearos una super-distribución-personalizada-de-Eclipse. ¡Y encima el sistema te chequea las dependencias de manera automática!
Enhorabuena para Yoxos. Gran sistema, gran idea y gran producto.
Eclipse pone en evidencia a Microsoft
martes, julio 04, 2006 por Martín
La Fundación Eclipse lanzó hace unos días (el 30 de Junio) la versión 3.2 de la platforma Eclipse, con el nombre en clave de Callisto. Bajo este lanzamiento se recogen actualizaciones para 23 de sus proyectos liderados por 10 equipos de desarrollo diferente.
Eclipse, mucho más que un entorno de desarrollo de Java (sistemas embebidos, arquitectura, C/C++, PHP, ...) está metiendo cada vez más presión al entorno de desarrollo de Microsoft, Visual Studio. Según datos de la consultora Evans Data, Eclipse es ahora mismo el segundo entorno entorno de desarrollo más utilizado, por detrás de la suite de herramientas de Microsoft.
Pero mientras que los productos de Microsoft como Vista o Microsoft Office acumulan retraso tras retraso, la Fundación Eclipse ha conseguido coordinar todos sus equipos de desarrollo para realizar un lanzamiento con puntualidad británica. Mike Milinkovich, CEP de la fundación afirmó a The Register que la plataforma Eclipse debe ser ante todo predecible y fiable, y que con este lanzamiento lo han demostrado. Erich Gamma y John Wieland ofrecieron una presentación en la Java One 2006 en la que se explican los esfuerzos necesarios para coordinar este tipo de lanzamiento distribuido.
¿Debe tomar nota Microsoft?
Eclipse, mucho más que un entorno de desarrollo de Java (sistemas embebidos, arquitectura, C/C++, PHP, ...) está metiendo cada vez más presión al entorno de desarrollo de Microsoft, Visual Studio. Según datos de la consultora Evans Data, Eclipse es ahora mismo el segundo entorno entorno de desarrollo más utilizado, por detrás de la suite de herramientas de Microsoft.
Pero mientras que los productos de Microsoft como Vista o Microsoft Office acumulan retraso tras retraso, la Fundación Eclipse ha conseguido coordinar todos sus equipos de desarrollo para realizar un lanzamiento con puntualidad británica. Mike Milinkovich, CEP de la fundación afirmó a The Register que la plataforma Eclipse debe ser ante todo predecible y fiable, y que con este lanzamiento lo han demostrado. Erich Gamma y John Wieland ofrecieron una presentación en la Java One 2006 en la que se explican los esfuerzos necesarios para coordinar este tipo de lanzamiento distribuido.
¿Debe tomar nota Microsoft?
viernes, junio 30, 2006
Forrester: Proyectos Open Source en el 2006
viernes, junio 30, 2006 por Martín
La compañía Forrester ha publicado un estudio donde ha evaluado la repercusión de 13 proyectos líderes dentro del mundo del Open Source durante el segundo cuarto del 2006. Los resultados son los siguientes:
Los proyectos líderes:
Por cierto, si alguien quiere acceder al informe completo pues tendrá que pagar los US$1995.00 que cuesta el acceso. Vaya, que el dólar está bajo pero que todavía no tanto para que me lo pueda permitir.
Los proyectos líderes:
- MySQL
- Eclipse IDE
- Apache HTTP Server
- Apache Tomcat
- JBoss Application Server
- PHP
- Hibernate
- Apache Velocity
- PostgreSQL
- Spring Framework
- Apache Struts
- Apache Cocoon
- Apache Geronimo
Por cierto, si alguien quiere acceder al informe completo pues tendrá que pagar los US$1995.00 que cuesta el acceso. Vaya, que el dólar está bajo pero que todavía no tanto para que me lo pueda permitir.
miércoles, junio 28, 2006
Ganas de probar pentaho
miércoles, junio 28, 2006 por Martín
Pentaho es una plataforma de productos Open Source de Business Intelligence. Algunos de los productos que forman la platforma son JFreeReport, JPivot, Mondrian o Kettle. La verdad es que pentaho se está convirtiendo en el Alfresco del Business Intelligence y cada vez hay más y más gente que habla de este producto, así que cada vez me pica más el gusanillo por probarlo.
Pero bueno, la verdad es que ya no recuerdo las veces que habré bajado mondrian y jpivot y que nunca los probé. Creo que la primera fue hace dos años, cuando eran productos cuasi-abandonados. Realmente me ha sorprendido como estos dos productos han ascendido de las cavernas de sourceforge.net hasta conertirse ahora mismo en productos de moda. Lo más seguro es que fueran productos internos de algunos de los miembros de la actual pentaho y que éstos últimos decidieran dar el salto y fundar su compañía, dándole un importante acelerón al código fuente base, porque la verdad es que la diferencia en cuanto a actividad, marketing y movimiento ha sido enorme.
En fin, que habrá que probarlo tarde o temprano porque parece muy interesante. Por cierto, en TodoBI tienen tres artículos sobre el tema: Introducción a Pentaho, Pentaho 1: reporting y Pentaho 2: Análisis OLAP.
Technorati Profile
Pero bueno, la verdad es que ya no recuerdo las veces que habré bajado mondrian y jpivot y que nunca los probé. Creo que la primera fue hace dos años, cuando eran productos cuasi-abandonados. Realmente me ha sorprendido como estos dos productos han ascendido de las cavernas de sourceforge.net hasta conertirse ahora mismo en productos de moda. Lo más seguro es que fueran productos internos de algunos de los miembros de la actual pentaho y que éstos últimos decidieran dar el salto y fundar su compañía, dándole un importante acelerón al código fuente base, porque la verdad es que la diferencia en cuanto a actividad, marketing y movimiento ha sido enorme.
En fin, que habrá que probarlo tarde o temprano porque parece muy interesante. Por cierto, en TodoBI tienen tres artículos sobre el tema: Introducción a Pentaho, Pentaho 1: reporting y Pentaho 2: Análisis OLAP.
Technorati Profile
Programadores, marketing y weblogs
miércoles, junio 28, 2006 por Martín
Hoy he leido una noticia en TheServerSide que me ha hecho escribir algo que ya tenía en mente desde hace tiempo. El artículo cuenta algunas de las diferencias que ha encontrado el autor entre los programadores y los comerciales.
El caso es que en algunas de las entradas pone:
Y es que los weblogs se han convertido en un método de auto-promoción increible. Ahroa mismo cualquiera puede crear un weblog, comenzar a escribir de algún tema técnico específico, escoger los canales de promoción adecuados, y de pronto tendrá grandes posibilidades de obtener buenas ofertas de trabajo sin siquiera ser un programador brillante.
La verdad es que a mi sólo me pasó una vez. Me ofrecieron una muy buena oferta para trabajar en Londres en un banco, pero bueno, no era el momento de saltar el charco. Lo que sí que me ha pasado más veces es recibir correos de recruiters buscando gente interesada en algún puesto de trabajo en concreto (supongo que eso indirectamente se podrían considerar como ofertas a mi).
En fin, que bravo por los que sean listos. Los demás seguiremos trabajando :-)
El caso es que en algunas de las entradas pone:
- A diferencia de los programadores mediocres, los comerciales mediocres en ocasiones tienen fortuna. Cuando lo consiguen acaban con un éxito que les permitirá alardear durante toda una generación. Pero eso no significa que lo vuelvan a conseguir.
Y es que los weblogs se han convertido en un método de auto-promoción increible. Ahroa mismo cualquiera puede crear un weblog, comenzar a escribir de algún tema técnico específico, escoger los canales de promoción adecuados, y de pronto tendrá grandes posibilidades de obtener buenas ofertas de trabajo sin siquiera ser un programador brillante.
La verdad es que a mi sólo me pasó una vez. Me ofrecieron una muy buena oferta para trabajar en Londres en un banco, pero bueno, no era el momento de saltar el charco. Lo que sí que me ha pasado más veces es recibir correos de recruiters buscando gente interesada en algún puesto de trabajo en concreto (supongo que eso indirectamente se podrían considerar como ofertas a mi).
En fin, que bravo por los que sean listos. Los demás seguiremos trabajando :-)
martes, junio 27, 2006
Quiero esta formación
martes, junio 27, 2006 por Martín
Vía el ya archiconocido podcast the javaposse me he enterado de que necesito formación en Java:
Come attend training in the Java Programming Language surrounded by beautiful beaches, warm weather and great food. Bring your family along and spend quality time with them alongside excellent learning.
Se trata de unos cursos que se realizan en la isla de Creta y en los que en el precio se incluye el alojamiento en un hotel de cinco estrellas con desayuno incluido. Eso sí, el vuelo y coche no se incluyen en el precio. Por si queréis intentar convencer a vuestro jefe, podéis ver las razones que argumentan.
Yo casi que no voy a probar ;)
Come attend training in the Java Programming Language surrounded by beautiful beaches, warm weather and great food. Bring your family along and spend quality time with them alongside excellent learning.
Se trata de unos cursos que se realizan en la isla de Creta y en los que en el precio se incluye el alojamiento en un hotel de cinco estrellas con desayuno incluido. Eso sí, el vuelo y coche no se incluyen en el precio. Por si queréis intentar convencer a vuestro jefe, podéis ver las razones que argumentan.
Yo casi que no voy a probar ;)
lunes, junio 26, 2006
Motivación: Jefes de proyecto con valor añadido
lunes, junio 26, 2006 por Martín
Hace ya algo de tiempo conocí un caso en el que a una persona la iban a colocar como jefe de un proyecto dirigiendo a un equipo de unas seis u ocho personas porque se le daba muy bien tratar con la gente, trabajar con el project, manejar hojas de cálculo, crear informes, etc...
Hace menos conocí otro caso de una persona que dejaba su empresa para ir a trabajar en un camping porque le salía más rentable: cobraba más y se lo pasaba mejor.
Estos dos sucesos, aunque no lo parezca, tienen una relación. ¿Cómo puede motivarse un equipo de desarrolladores mal pagados para que permanezcan en la empresa durante un tiempo razonable?
Las metodologías ágiles promueven una serie de medidas para solucionar estos problemas como el realizar jornadas de trabajo de las horas necesarias, no realizar horas extras, mantener un buen ambiente de trabajo, trabajar en equipo, etc. etc. Todo esto está realmente bien, especialmente para no engañar a los trabajadores ( no es lo mismo cobrar 300€ a la semana por 40h que 300€ por 48h ), pero quizás donde algunas metodologías ágiles no se adentran todo lo necesario es en la figura de jefe de proyecto y sus consecuencias para el equipo. Algunas metodologías incluso promueven los equipos autónomos, sin ningún jefe de proyecto real que marque pautas, iteraciones, tareas, etc., pero bueno, eso ya es otro tema.
Muchas empresas se ven obligadas a contratar personas con unos salarios irrisorios, por diversas razones en las que tampoco voy a entrar. La cuestión es, ¿cómo mantener a estas personas en nuestra empresa cuando la realidad es que pueden cobrar más en cualquier camping y pasarse un verano fenomenal? Vaya, visto así, no parece demasiado sencillo, ¿verdad? :-)
La clave para mi está en la motivación, y uno de las personas que tiene la responsabilidad de tratar de motivar a estas personas es el jefe de proyecto. ¿De qué sirve tener un jefe de proyecto que sepa gestionar muy bien las tareas si no le va a ofrecer nada a sus desarrolladores? Normalmente estas situaciones terminarían en comentarios como "pepito no tiene ni idea", "tengo que hacer esto pero no me han dicho con qué", "vaya con el pepito, tenemos que resolver esto, le hemos preguntado como, y dice que lo busquemos en google".
La relación entre la empresa y el empleado en este caso ha de ser un acuerdo en el que los dos ganen algo. Ya que el empleado no va a cobrar mucho, al menos debe sacar otros beneficios. Por suerte, la época en la que la mejor quiniela en España era un trabajo ha pasado, al menos en este momento en el mundo de las TI. El acuerdo podría ser algo del estilo: "Mira, lo siento, me encantaría poder pagarte más pero ahora mismo es imposible. Nuestra oferta es para trabajar en este proyecto donde no vas a cobrar mucho pero vas a aprender un montón, trabajás con tecnologías actuales y se respetará el horario laboral".
El único modo de satisfacer esta propuesta es tener al mando de los equipos de desarrollo personas que realmente sepan lo que hacen, con un nivel técnico alto a la vez que capacidades de gestión de equipos. Poniéndome en el papel de una persona que cobre un salario bajo y que entre a trabajar en una factoría de software, o en cualquier cliente, bajo el mando de un jefe de proyecto, esto es lo que me gustaría encontrarme para que realmente me compensase el no irme a la playa a trabajar:
No sé si me he olvidado de algo, pero creo que es un ladrillo suficientemente grande :-)
Hace menos conocí otro caso de una persona que dejaba su empresa para ir a trabajar en un camping porque le salía más rentable: cobraba más y se lo pasaba mejor.
Estos dos sucesos, aunque no lo parezca, tienen una relación. ¿Cómo puede motivarse un equipo de desarrolladores mal pagados para que permanezcan en la empresa durante un tiempo razonable?
Las metodologías ágiles promueven una serie de medidas para solucionar estos problemas como el realizar jornadas de trabajo de las horas necesarias, no realizar horas extras, mantener un buen ambiente de trabajo, trabajar en equipo, etc. etc. Todo esto está realmente bien, especialmente para no engañar a los trabajadores ( no es lo mismo cobrar 300€ a la semana por 40h que 300€ por 48h ), pero quizás donde algunas metodologías ágiles no se adentran todo lo necesario es en la figura de jefe de proyecto y sus consecuencias para el equipo. Algunas metodologías incluso promueven los equipos autónomos, sin ningún jefe de proyecto real que marque pautas, iteraciones, tareas, etc., pero bueno, eso ya es otro tema.
Muchas empresas se ven obligadas a contratar personas con unos salarios irrisorios, por diversas razones en las que tampoco voy a entrar. La cuestión es, ¿cómo mantener a estas personas en nuestra empresa cuando la realidad es que pueden cobrar más en cualquier camping y pasarse un verano fenomenal? Vaya, visto así, no parece demasiado sencillo, ¿verdad? :-)
La clave para mi está en la motivación, y uno de las personas que tiene la responsabilidad de tratar de motivar a estas personas es el jefe de proyecto. ¿De qué sirve tener un jefe de proyecto que sepa gestionar muy bien las tareas si no le va a ofrecer nada a sus desarrolladores? Normalmente estas situaciones terminarían en comentarios como "pepito no tiene ni idea", "tengo que hacer esto pero no me han dicho con qué", "vaya con el pepito, tenemos que resolver esto, le hemos preguntado como, y dice que lo busquemos en google".
La relación entre la empresa y el empleado en este caso ha de ser un acuerdo en el que los dos ganen algo. Ya que el empleado no va a cobrar mucho, al menos debe sacar otros beneficios. Por suerte, la época en la que la mejor quiniela en España era un trabajo ha pasado, al menos en este momento en el mundo de las TI. El acuerdo podría ser algo del estilo: "Mira, lo siento, me encantaría poder pagarte más pero ahora mismo es imposible. Nuestra oferta es para trabajar en este proyecto donde no vas a cobrar mucho pero vas a aprender un montón, trabajás con tecnologías actuales y se respetará el horario laboral".
El único modo de satisfacer esta propuesta es tener al mando de los equipos de desarrollo personas que realmente sepan lo que hacen, con un nivel técnico alto a la vez que capacidades de gestión de equipos. Poniéndome en el papel de una persona que cobre un salario bajo y que entre a trabajar en una factoría de software, o en cualquier cliente, bajo el mando de un jefe de proyecto, esto es lo que me gustaría encontrarme para que realmente me compensase el no irme a la playa a trabajar:
- Altos conocimientos técnicos: Puede llegar a ser difícil respetar a una persona que teóricamente es tu jefe y que sabes que no tiene los conocimientos técnicos para abordar el trabajo que tiene asignado.
Del mismo modo, un proyecto necesita realizar una serie de decisiones técnicas, no sólo a su inicio, que no se deben delegar en terceras personas no relacionadas con el proyecto o incluso en el equipo de desarrolladores que quizás no tengan la experiencia necesaria para abordarlas.
No confundirme en este último punto. Siempre se debe tener en cuenta la opinión del equipo de desarrollo. Esto es fundamental. Pero, en mi opinión, la decisión debería ser un consenso entre ambas partes. Sea como sea, es muy importante que el jefe de proyecto sepa realmente de lo que se está hablando.
- Hacer ingeniería: Es importante que un jefe de proyecto sea capaz de forzar buenas prácticas, patrones de diseño, que sea capaz de enseñarle a sus desarrolladores a adaptarse a una metodología, que siga buenas costumbres como la integración continua o el desarrollo orientado a pruebas. Todo esto hará realmente que los desarrolladores vean su trabajo como lo que es, como un arte, y no como una chapuza de tres al cuarto.
- Mantenerse al día: El jefe de proyecto debería ser el encargado de guiar a los desarrolladores y de saber discernir entre las últimas tendencias realmente útiles a los proyectos y los bluffs. Es muy importante que los proyectos utilizen tecnologías fiables, al tiempo que lo suficientemente novedosas para mantener alto el espíritu del equipo. ¿A quién no le gusta estar trabajando con lo último de lo último? Ahora bien, hay que saber distinguir el "último de lo último" que puede ser realmente útil al proyecto del mero artefacto de marketing.
- Capacidad de formación: El jefe de proyecto debería ser capaz de compartir sus conocimientos con las personas que tienen a su cargo. Esto hace que las personas se sientan bien porque están aprendiendo cosas y por lo tanto no sentirán que están perdiendo su tiempo en un lugar donde no se aprende nada.
El estar trabajando con una persona que ves que cada día te ofrece algo nuevo y de la que continuamente estás aprendiendo algo, es una de las mejores sensaciones que puede tener una persona que comienza en esto de la informática, experiencia, por otra parte, probablemente extrapolable a cualquier otro sector.
- Ser capaz de bajar al nivel más bajo: Ser capaz de pringarse. Sí. Ser capaz de coger un ordenador, descargarse el código fuente del proyecto y mostrarle a un desarrollador del proyecto los errores que ha cometido. Esto evidentemente no quiere decir que el director tenga que solucionarle los problemas a los programadores, corrigiendo sus bugs, etc. Pero está muy bien el sentir la sensación de que hay una persona detrás de ti que tiene esa capacidad, lo que debería aumentar el respeto y la confianza del equipo de personas que está trabajando para ti.
- Habilidades como gestor de equipos: En todo equipo pueden surgir riñas, discusiones, conflictos, peleas, etc. que el jefe de proyecto debe ser capaz de afrontar y solventar. De nada sirven unas altas capacidades técnicas si después no eres capaz de mantener un buen entorno de trabajo.
- No forzar horarios: Y esto va en línea con todas las metodologías ágiles. Cuando tu equipo de personas ya se encuentra en una situación bastante precaria, de nada va a ayudar el hacerlos trabajar dos horas más al día.
Sí, es cierto, a lo mejor resulta que el proyecto tiene que estar para ayer. Pero forzar la situación puede hacer que se te vaya de pronto la mitad del equipo a la competencia, así que igual la solución al problema está en otra parte de la jerarquía de la empresa.
Evidentemente esto exige que el jefe de proyecto se deba a su equipo, sea un compañero más, y se encargue de velar de la estabilidad de la jornada laboral de sus subordinados
No sé si me he olvidado de algo, pero creo que es un ladrillo suficientemente grande :-)
sábado, junio 24, 2006
Noite meiga
sábado, junio 24, 2006 por Martín
Las hogueras en San Juan son una tradición en Coruña. Fiesta local y fiesta de interés turístico nacional, atrae miles de personas al paseo marítimo de Coruña para disfrutar de una noche de diversión en un marco incomparable, las playas de Riazor y del Orzán. La gente disfruta toda la noche, en la playa, comiendo, bebiendo, cantando, bailando, y en definitiva, disfrutando una noche mágica.
Ayer había especialmente mucha gente. Ayudó mucho la marea llena. He buscado fotos en flickr, pero se ve que nadie estaba todavía lo suficientemente recuperado como para subir algo, así que he recuperado alguna foto del año pasado para los que no conozcan la fiesta.
Ayer había especialmente mucha gente. Ayudó mucho la marea llena. He buscado fotos en flickr, pero se ve que nadie estaba todavía lo suficientemente recuperado como para subir algo, así que he recuperado alguna foto del año pasado para los que no conozcan la fiesta.
viernes, junio 23, 2006
El modelo de negocio Second Life
viernes, junio 23, 2006 por Martín
Ya había oido hablar alguna otra vez sobre Second Life, pero sólo hasta ayer tuve la curiosidad de ver como era el modelo de negocio de este juego online. Y la verdad es que me ha dejado impresionado. Como otros bloggers ya han dejado plasmado en sus publicaciones: Eso es exactamentel o que me habría gustado hacer a mi.
Para los que no conozcan Second Life, resumiendo un poco, se trata de un juego de realidad social, donde las personas crean un personaje y se dedican a interactuar con un mundo que puede ser modelado. Así las personas pueden alquilar una casa, tener un trabajo y comenzar a ganar dinero... virtual... ¿o no?
Dicho así, parece el clásico juego masivo multijugador y online. ¿Pero cual es la diferencia y la clave del negocio?: Que el dinero virtual lo puedes canjear por dinero real y viceversa. Y ahí está lo genial del modelo de negocio. Más de 200.000 personas jugando en un mundo en el que se genera dinero de verdad. Gente que cambia decenas, cientos o miles de dólares para poder comprarse una casa virtual, o gente que se dedica a especular inmobiliariamente en un mundo virtual obteniendo dinero real.
Tal ha sido el impacto de este negocio que compañías reales han abierto sucursales virtuales para así darse publicidad y, por qué no, ganarse unos duros, de los que les gustan, de los reales.
Imaginaros las ganancias que puede estar generando, y que generará, esta idea para los creadores de este juego, los creadores de un mundo virtual donde se mueve dinero real...
Para los que no conozcan Second Life, resumiendo un poco, se trata de un juego de realidad social, donde las personas crean un personaje y se dedican a interactuar con un mundo que puede ser modelado. Así las personas pueden alquilar una casa, tener un trabajo y comenzar a ganar dinero... virtual... ¿o no?
Dicho así, parece el clásico juego masivo multijugador y online. ¿Pero cual es la diferencia y la clave del negocio?: Que el dinero virtual lo puedes canjear por dinero real y viceversa. Y ahí está lo genial del modelo de negocio. Más de 200.000 personas jugando en un mundo en el que se genera dinero de verdad. Gente que cambia decenas, cientos o miles de dólares para poder comprarse una casa virtual, o gente que se dedica a especular inmobiliariamente en un mundo virtual obteniendo dinero real.
Tal ha sido el impacto de este negocio que compañías reales han abierto sucursales virtuales para así darse publicidad y, por qué no, ganarse unos duros, de los que les gustan, de los reales.
Imaginaros las ganancias que puede estar generando, y que generará, esta idea para los creadores de este juego, los creadores de un mundo virtual donde se mueve dinero real...
Nuevo blog, nuevos aires
viernes, junio 23, 2006 por Martín
Hola, me llamo Martín y comienzo mi andadura en blogger.com
Llevo varios años como blogger, de hecho tengo un par de blogs en español e inglés activos. El caso es que estos blogs están en otro proveedor, difícil de mantener, y están muy orientados a temas técnicos, así que he decidido abrir otro blog más donde poder tratar otras temáticas diferentes. Además, parece que blogger es un sistema que funciona bastante bien, y a mi me encanta eso de que las cosas funcionen y no tener que tocar nada :-)
Otra de las razones importantes para esta andadura es el volver a comenzar con algo de anonimato. Seguramente este anonimato se perderá muy pronto, pero esto me da libertad para tocar temas que de otro modo no podría tocar. Es un poco difícil bloggear cuando tus amigos, compañeros de empresa, y jefes, se dan vueltas por tu blog.
Así que ala, echas las presentaciones, ahora toca comenzar a escribir.
Llevo varios años como blogger, de hecho tengo un par de blogs en español e inglés activos. El caso es que estos blogs están en otro proveedor, difícil de mantener, y están muy orientados a temas técnicos, así que he decidido abrir otro blog más donde poder tratar otras temáticas diferentes. Además, parece que blogger es un sistema que funciona bastante bien, y a mi me encanta eso de que las cosas funcionen y no tener que tocar nada :-)
Otra de las razones importantes para esta andadura es el volver a comenzar con algo de anonimato. Seguramente este anonimato se perderá muy pronto, pero esto me da libertad para tocar temas que de otro modo no podría tocar. Es un poco difícil bloggear cuando tus amigos, compañeros de empresa, y jefes, se dan vueltas por tu blog.
Así que ala, echas las presentaciones, ahora toca comenzar a escribir.
Suscribirse a:
Entradas (Atom)
