Un posible futuro para Internet (en dos partes)

Muy recomendable la serie de dos videos acerca del Futuro de Internet que he visto vía Youtube.

Ciertamente se trata de continuas presunciones e hipótesis a medio plazo como poco (tecnológicamente hablando), pero el escenario que nos muestra es bastante interesante. Un concepto por encima de todos los demás : la inteligencia colectiva y de forma asociada la importancia de Internet como herramienta, como vehiculo de transmisión de información.

Me gusta mucho el final de la segunda parte donde se centra fundamentalmente en uno de nuestros posibles caminos de evolución en la Red de Redes, aunque por momentos parezca ciencia ficción ciertamente no lo es ni mucho menos como posibilidad. Y si no, al tiempo.

Primero lo importante fue el hardware. Posteriormente el software. Luego la conectividad como bien citan en algún momento del documental.

Los videos están subtitulados al castellano aunque el idioma original es inglés.

Primera Parte

Segunda Parte

Sigo vivo

Pues sí, en efecto, aunque llevo un tiempo fuera de mi faceta de blogger. aquí ando.

Demasiados proyectos, demasiadas cosas.

Seguiremos informando. Espero que a partir de la próxima semana retomar el ritmo normal :)

El síndrome NIH

Desde el blog de Juanjo Navarro he llegado casualmente a una entrada sobre el síndrome NIH (Not Invented Here), consistente en el caso de la informática (aunque aplicable en muchos campos) en rechazar desarrollos creados “fuera de casa” por razones como los distintos orígenes de estos desarrollos, fiándose siempre más (en muchos casos sistemáticamente) del clásico “Bah, esto me lo pico yo en un par de días”.

Hay alguna razón más en el artículo original, pero sobre todo las siguientes tres me han llamado mucho la atención porque me parece que siempre hay que vigilarlas y es bastante sencillo caer en ellas:

1. Nunca es tan sencillo como parece. Empiezas pensando que lo puedes hacer en dos días, y acabas invirtiendo meses. Literal. Conozco varias historias y frases memorables de este tipo.
2. Probablemente no es la guerra en la que deberías estar. Sería mejor invertir ese tiempo en tu negocio que en hacer algo que ya existe. Bien es verdad que el tiempo que no te tomas creando tú algo, te lo tomas entendiendo lo de los demás. Aquí en este caso hay que analizar mínimamente cada situación. Tampoco es un axioma en mi opinión.
3. Mucha gente lo ha intentado antes y falló. Todos nos creemos los programadores más listos sobre la tierra, pero es para pensarlo. También literal. Siempre pasa. Y cuando digo siempre, es SIEMPRE.

Personalmente podría añadir otra razón que me parece sumamente importante, y es la siguiente:

Un desarrollo que ya está usando mucha gente y hace algo (aunque sea mejorable) como poco está más testeado / probado que tu nuevo desarrollo. En muchos casos, si es Open Source y uno cree que puede mejorarlo, es posible colaborar además.

Vacaciones en EEUU (Nueva York, Niagara y Washington)

Pues si, en tres días comienzan mis vacaciones de verano (1 de Agosto). Este año toca visitar la Costa Este de Estados Unidos, en un viaje que por momentos nos ubicó en lugares tan dispares como Croacia, la costa Oeste o Egipto.

Estos días toca cerrar tareas pendientes, delegar algunas cosas y salir pitando para coger un avión muuy tempranero el viernes (salimos a las seis de la mañana de Barajas).

El viaje dura once días así que volveré a la actividad normal el día 12.

El viaje consta de un mini tour (no vacacional, alquilando un coche  y “carretera y manta”) por los destinos de Nueva York, Washington, Atlantic City y Cataratas del Niágara. Posibilidades hay muchas dentro de la Costa Este y hay mucha gente que recomendaba ver Boston, Filadelfia o Miami. En fin, quiero ver la parte positiva y así me dejo razones para volver en su momento :p porque ciertamente no hay “tiempo para más” y tampoco queremos agobiarnos en un viaje con demasiados kilómetros de carretera y poca “chicha”.

Parece un buen momento para viajar a Estados Unidos, no tanto porque estén las cosas allí más baratas (que hay casos que también), sino porque los europeos tenemos la suerte de contar hoy con un gran cambio euro-dólar.  Las compras neoyorquinas parecen tener pinta de ser uno de los referentes desde nuestara llegada.

Qué visitar ? Pues ciertamente no nos va a sobrar tiempo: El Empire State, la Casa Blanca, el Capitolio, el monumento a Jefferson, la Zona Cero, ChinaTown, las propias cataratas del Niágara,  Broadway y sus musicales,  el Moma, la Estatua de la Libertad con su ferry asociado, …

Espeor poder contar mis impresiones a la vuelta del viaje, aunque prefiero no asegurarlo porque es un propósito en el que alguna otra vez ya he fallado :p.

Maven y librerías de terceros (jms, jmxri, jmxtools, …)

Un problema común que podemos encontrar al usar Maven es que Sun no permite distribuir sus jar, por lo que oficialmente no se puede poner simplemente la dependencia en nuestros ficheros pom.xml usando repositorios públicos como hacemos con la mayoría. De ese modo, en los repositorios maven que hay por el mundo, no están estos jar de Sun MicroSystems, así que maven no se los puede bajar, al menos automáticamente. Hay que bajárselos a mano y ponerlos en tu repositorio local de maven (o en uno a nivel departamental, corporativo, … esto ya depende de la configuración concreta que tengamos en Maven).

Bien, ¿Cómo instalar un jar de terceros en nuestro repositorio? Podemos encontrar más información al respecto en la siguiente página:

http://maven.apache.org/guides/mini/guide-installing-3rd-party-jars.html

Por ejemplo, para el caso de jms.jar, jmxri.jar, y jmxtools.jar, de las que en nuestros IDE nos encontraremos con bonitos errores del estilo: “Missing Artifact required …” las líneas quedarían del siguiente modo:

mvn install:install-file -Dfile={RUTA_JAR}/jms.jar -DgroupId=javax.jms -DartifactId=jms -Dversion=1.1 -Dpackaging=jar
mvn install:install-file -Dfile={RUTA_JAR}/jmxri-1.2.1.jar -DgroupId=com.sun.jmx -DartifactId=jmxri -Dversion=1.2.1 -Dpackaging=jar
mvn install:install-file -Dfile={RUTA_JAR}/jmxtools-1.2.1.jar -DgroupId=com.sun.jdmk -DartifactId=jmxtools -Dversion=1.2.1 -Dpackaging=jar

siendo {RUTA_JAR} la ruta física donde nos hemos descargado los ficheros jar correspondientes.

Otro tema distinto es que tengamos problemas con la librería tools.jar. En este caso, el proyecto se quejará de esta dependencia:

com.sun:tools:jar:1.5.0 (la versión puede diferir según el entorno).

Y claro, esa dependencia no existe en ningún repositorio. ¿Cuál es el problema? El problema es que Eclipse está usando para compilar un JRE, no un JDK. Para resolverlo nada más simple que decirle que use el JDK que queramos:

Windows -> Preferences -> Java -> Installed JRE’s -> Add

Y añadimos una nueva entrada que apunte a la ruta del JDK y la marcamos para que la use por defecto.