domingo, 28 de julio de 2013

Un breve acercamiento a SoapUI



Una vez que se comienza a trabajar con servicios web, uno de los primeros inconvenientes con los que se topa un desarrollador viene a la hora de realizar pruebas funcionales sobre éstos servicios web (especialmente si están basados en SOAP). Al tratarse de un protocolo particular y una nomenclatura de mensajes un tanto engorrosa, el realizar programas clientes de prueba se vuelve tedioso.

Es en ese ámbito en donde encontramos al aplicativo llamado SoapUI, que básicamente nos brinda una interfaz cómoda e intuitiva para realizar pruebas funcionales de servicios web basados en SOAP sin la necesidad de escribir largas rutinas de código para el consumo del servicio web.

Es necesario recalcar que SoapUI nos sirve para realizar pruebas funcionales, no pruebas de carga, como es el caso de JMeter. La diferencia básicamente es que en JMeter se puede lanzar a ejecutar el mismo servicio web con configuraciones específicas de iteraciones y recolección de información estadística muy avanzada. Sin embargo, esto no quiere decir que SoapUI es irrelevante, sino que como veremos en entradas posteriores, ambos se pueden complementar.

Las ventajas que nos ofrece SoapUI son las siguientes:
  • Interfaz intuitiva y fácil de usar.
  • Generación automática de peticiones SOAP para cada método. (Esto es lo que nos servirá en un futuro para realizar pruebas de carga de servicios web con JMeter)
  • Es gratuito


SoapUI puede ser descargado de su sitio oficial, sin embargo aquí encontrarán el link directo para la descarga de la versión gratuita del aplicativo.

La instalación del aplicativo resulta ser muy sencilla, con opciones de selección típicas: directorios de instalación, localización de accesos directos, etc.

Una vez que está instalado, seguiremos los siguientes pasos para realizar la prueba funcional de un servicio web:

1. Crear un nuevo proyecto SoapUI
Un proyecto en SoapUI es un set de métodos que corresponden a una definición WSDL. Es decir que un proyecto de SoapUI estará atado a un WSDL específico y nos servirá para probar los métodos que se encuentren publicados en ese contrato.

Entre las principales propiedades que vamos a editar están:
  • Project Name.- Aquí ingresaremos el nombre del proyecto.
  • Initial WSDL/WADL.- Aquí ingresaremos la URL del contrato WSDL.
  • Create Requests.- Nos aseguraremos de que esta casilla esté activada. Permitirá que SoapUI genere automáticamente los mensajes SOAP necesarios para realizar las peticiones de cada método del servicio web
Para crearlo, seguiremos estos pasos:

Nuevo Proyecto SoapUI

Establecer las propiedades del Proyecto SoapUI

Proyecto SoapUI generado exitosamente

2. Abrir la solicitud de un método de servicio web
Una vez que tenemos generado el proyecto, podremos que debajo del árbol de proyectos se crea una rama con el nombre de nuestro proyecto, y dentro de ella varias ramas, una por cada método que el contrato del servicio web haya descrito.
Cada método tendrá un elemento llamado Request1, éste es básicamente el mensaje SOAP que el aplicativo generó para invocar una solicitud del respectivo método. Ahora lo único que nos resta hacer es seleccionar el método que deseamos probar, y abrir con doble clic su respectivo "Request1".

Para abrir, seguiremos estos pasos:

Seleccionar la petición generada del método deseado

3. Probar un método de servicio web
Una vez abierta la respectiva petición, podremos visualizar una ventana nueva con una división. En el lado izquierdo estará el mensaje SOAP de petición y el lado derecho en blanco. En la parte superior de esta ventana divisaremos un botón de flecha verde, el mismo que servirá para poder ejecutar la petición del método.
Ahora podremos darle clic a la flecha verde y esperar por la respectiva respuesta del método. En este ejemplo invocaremos un método que simplemente retorna la cadena de caracteres "Hello world".

Para ejecutarlo, seguiremos estos pasos:

Abrir y ejecutar la petición correspondiente

Visualizar la respuesta SOAP correspondiente

4. Probar un método de servicio web con parámetros
Si el método del servicio web requiere parámetros de entrada, podremos setear sus valores desde el lado izquierdo de la pantalla de petición SOAP. En este ejemplo invocaremos un método que recibe por parámetro un nombre como cadena de caracteres y devuelve la frase "Hola <nombre_recibido>"

Para ejecutarlo, seguiremos estos pasos:

Abrir la petición correspondiente

Editar los parámetros de la petición correpondiente y ejecutarla

Visualizar la respuesta SOAP correspondiente

Si les ha parecido interesante la entrada, tienen comentarios, u opiniones acerca de este tema o alguno relacionado, siéntanse en la libertad de comentar. La meta es aprender.

lunes, 24 de junio de 2013

Comunicación entre procesos Java y .Net a través de "named pipes"


Pues bien, el concepto de la comuncación entre procesos (IPC) no es nuevo, y la internet posee mucha información acerca de ese tema. Básicamente el concepto se refiere a cualquier canal de comunicación que pueda existir entre dos procesos que corren simultáneamente en la misma computadora, o entre computadoras diferentes conectadas en una red.

Existen varias técnicas que se han desarrollado para lograr esto, una de ellas es la ya muy conocida comunicación a través de sockets: un proceso que posee una subrutina para escuchar información entrante por un puerto TCP o UDP y otro proceso que le envía información. Este acercamiento funciona muy bien en casi la mayoría de ambientes, sin embargo suelen existir ambientes muy específicos cuando por diversos temas, es necesario buscar otra solución. 

Pensemos un momento en el siguiente escenario: Tengo un proceso que posee una lógica muy especial para una tarea muy específica, y necesito reutilizar su funcionalidad desde una aplicación nueva que correrá en la misma computadora. Necesitamos una comunicación local entre estos procesos y no podemos pensar en soluciones a gran escala como aplicaciones o servicios web, ya que su implementación y la plataforma que necesitan se traduce en demasiado esfuerzo. Hasta este punto puedo pensar en comunicar estas dos aplicaciones por sockets, sin embargo el nivel de seguridad que se necesita no permite abrir puertos en dicho computador. Y para adornar un poco más las cosas, éstas aplicaciones están escritas en lenguajes diferentes. 

Reconozco que el ejemplo expuesto es muy poco trivial, y talvez ya tengan una solución válida y coherente completamente diferente a la que les voy a explicar, sin embargo, procederemos con este supuesto. Luego de ver y entender las principales bondades de utilizar "named pipes" estoy seguro de que ustedes podrán apropiarse de la técnica para situaciones suyas mucho más reales y válidas.

Pues bien, un "named pipe", lo que utilizaremos para comunicar éstas dos aplicaciones, no es otra cosa que un componente que se crea como una tubería entre varios procesos. En Windows, cada una de éstas tuberías tiene un comportamiento parecido al de un socket, y tienen que ser accedidas como si se tratasen de archivos. Así mismo, los named pipes deben ser montados sobre un sistema de archivos diferente a los que los comunes mortales conocen conocidos. Un named pipe en Windows, se monta sobre la unidad especial: "\\.\pipe\".

A continuación muestro un ejemplo de comunicación entre una aplicación escrita en C# (que va a actuar como un servicio oyente de información) y una aplicación escrita en Java (que va a actuar como una aplicación cliente de envío de información) a través de un named pipe con nombre "canal".

Primero veamos la rutina en C# necesaria para escuchar por un dato a través del named pipe:
while (true)
{
 //Crear la instancia del named pipe
 NamedPipeServerStream pipeServer =
 new NamedPipeServerStream("canal", PipeDirection.InOut, 4);
 Console.WriteLine("==> Hilo del Servidor NamedPipe creado.");
 //Esperar por una conexión cliente
 Console.WriteLine("==> Esperando por la conexión de un cliente...");
 pipeServer.WaitForConnection();
 Console.WriteLine("==> Cliente conectado.");
 try
 {
  // Flujo para las solicitudes. 
  StreamReader sr = new StreamReader(pipeServer);
  // Flujo para las respuestas. 
  StreamWriter sw = new StreamWriter(pipeServer);
  sw.AutoFlush = true;
  // Leer la solicitud desde el flujo. 
  string mensaje = sr.ReadLine();
  Console.WriteLine("==> Mensaje del cliente: " + mensaje);
  // Enviar la respuesta por le flujo de salida.
  sw.WriteLine("==>: " + mensaje);
  pipeServer.Disconnect();
 }
 catch (IOException e)
 {
  Console.WriteLine("==>Error: {0}", e.Message);
 }
 pipeServer.Close();
}

Como podemos ver, lo único que hará la aplicación servidor en este ejemplo, será el esperar un mensaje de un cliente, escribirlo en la consola y devolvérselo al cliente como un eco.

Ahora veamos la rutina en Java necesaria para enviar un dato hacia la aplicación servidor (escrita en C#) a través del named pipe:
try {
 // Conectarse al NamedPipe
 RandomAccessFile pipe = new RandomAccessFile("\\\\.\\pipe\\canal","rw");
 String echoText = "Hola mundo de NamedPipes\n";
 // Escribir en el NamedPipe
 pipe.write(echoText.getBytes());
 // Leer respuesta
 String echoResponse = pipe.readLine();
 System.out.println("Response: " + echoResponse);
 pipe.close();
} catch (Exception e) {
 e.printStackTrace();
}

Esta sección de código nos deja ver que para acceder a un NamedPipe desde Java podemos hacer como si se tratase de un archivo de acceso aleatorio, cuya localización está dentro de la unidad especial: "\\.\pipe\".

Al ejecutar el cliente podrán ver que su comportamiento es el esperado, y no hace otra cosa que enviar una cadena de texto y recibir la misma cadena de texto como respuesta.
Funcionalmente este ejemplo no es muy útil, sin embargo es justo lo necesario para que podamos ver y deducir a partir de aquí cómo podremos armar un esquema de comunicación robusto entre dos aplicaciones heterogéneas.

A continuación les dejo los links en donde encontré esta información, con el ejemplo original (que es idéntico al expuesto aquí), y así mismo un link desde donde se podrán descargar los dos proyectos para que los pueda correr y probar. (.Net => Visual Studio 2010, Framework 4.0 y Java => Eclipse Juno, JDK 1.6)

Fuentes:
Rutinas de intercomunicación .Net - Java
Named Pipe en Wikipedia

Archivos:
Proyectos .Net y Java

domingo, 9 de junio de 2013

Pruebas de carga con el incomprendido JMeter - Parte 1.


Bueno, antes de comenzar a leer esto, si son curiosos y si no habían escuchado nunca sobre JMeter, mínimo ya lo han buscado en Google para revisar de qué se trata. De todas maneras lo explicaré desde cero para poder ir entendiendo algunas cosas interesantes que he aprendido acerca de esta herramienta en las últimas semanas.

JMeter es una herramienta OpenSource que permite realizar pruebas de carga sobre nuestras aplicaciones. Las pruebas se pueden realizar sobre casi cualquier elemento de software de nuestra aplicación (una función/procedimiento de base de datos, un método Java, un servicio web, una página web, etc.) y a través de diversos protocolos (TCP/IP, HTTP, JDBC, etc.). Esta herramienta ha sido desarrollada sobre Java y su versatilidad ha sido bien aprovechada pudiendo llegar a tener una herramienta sumamente personalizada para nuestras pruebas de carga.

Una prueba de carga, también conocida como prueba de estrés, o (load test), es una prueba cuya finalidad es medir el rendimiento de nuestra aplicación en escenarios de extrema concurrencia. Cuantos requerimientos simultáneos puede llegar a responder mi servicio web sin que el tiempo de respuesta se vea afectado? Cuantos usuarios simultáneos podrán acceder a mi página web antes de que el servidor web colapse? Las respuestas a este tipo de preguntas que a simple vista son difíciles de conocer, son el objetivo de las pruebas de carga sobre una determinada aplicación.

Bien, lo primero que necesitamos, es tener instalado un JRE (Java Runtime Environment), con la finalidad de poder ejecutar la aplicación que como dijimos anteriormente, está desarrollada en Java. Si tienes alguna duda acerca de lo que es el JRE o cómo instalarlo, puedes revisar esta entrada antes de continuar.
Con un ambiente de ejecución de Java instalado, lo único que necesitamos es el programa. Jmeter puede ser descargado desde su sitio oficial: http://jmeter.apache.org/. Al seguir los vínculos: Download -> Download Releases, encontramos los enlaces a la descarga del programa en dos formatos: tar.gz y zip. En el momento de esta publicación la última versión estable es la 2.9. Así que al descargar el programa (yo prefiero el zip), tendremos un archivo como: apache-jmeter-2.9.zip.

Al descomprimirlo, tendremos el programa listo para ser utilizado. Dentro de la carpeta: "apache-jmeter-2.9\bin" podemos encontrar el archivo "jmeter.bat", que básicamente es el archivo que permitirá ejecutar el programa. (Para poder ejecutarlo sin problemas es necesario tener instalado como mínimo el JRE 1.6. Si no sabes qué es eso, puedes chequear esta entrada para salir de las dudas).

Ahora tenemos a JMeter listo para correr una prueba de carga sobre alguna víctima algún sitio de prueba. Para nuestro primer ejemplo, lo que haremos es "probar" el sitio oficial de JMeter.

Lo único que configuraremos es un escenario que simule 5 peticiones simultáneas al sitio "http://jmeter.apache.org" y ver cómo se comporta cada petición realizada. Para esto seguiremos los siguientes pasos en la aplicación de JMeter:

1. Configurar un Grupo de Hilos
El elemento Grupo de Hilos es el punto de partida de cualquier Plan de Pruebas. Todos los controladores y muestreadores deben estar dentro de un Grupo de Hilos. Como su nombre lo indica, este elemento controla el número de hilos que va a ejecutar nuestra prueba.

Entre las principales propiedades que vamos a editar están:
  • La cantidad de hilos.
  • El tiempo de subida (El tiempo que JMeter tendrá para levantar la cantidad de hilos configurados).
  • La cantidad de veces (iteraciones) que se ejecutará la prueba.
Para configurarlo, seguiremos estos pasos:

Nuevo Plan de Pruebas

Crear nuevo Grupo de Hilos

Configurar el Número de Hilos

2. Configurar una petición HTTP
Este elemento se comporta como un muestreador. Y su función principal es la de realizar una solicitud HTTP hacia un servidor web.

Entre las principales propiedades que vamos a editar están:
  • El nombre del servidor o dirección IP.
  • El método HTTP que se va a usar para realizar la solicitud.
Para configurarlo, seguiremos estos pasos:

Agregar nueva Petición HTTP

Configurar el Servidor web y el Método HTTP

3. Configurar un reporte "Árbol de Resultados"
Este elemento se comporta como un receptor. Y permite visualizar a manera de árbol cada una de las respuestas obtenidas por la ejecución de los muestreadores. Además se puede ver el tiempo que le tomó obtener la respuesta y algunos códigos de respuesta.

Para configurarlo, seguiremos estos pasos:

Agregar nuevo Árbol de Resultados

Luego de esto procederemos a darle click al botón de la flecha verde (Arrancar) para iniciar nuestra prueba. En ese momento, el grupo de hilos lanzará 5 hilos (en nuestro caso) haciendo cinco peticiones HTTP simultáneas al servidor configurado. Los resultados de cada una de esas peticiones podremos verlo en nuestro elemento Árbol de Resultados:

Código de respuesta de cada petición

Datos de respuesta de cada petición

Pues bien, hasta este momento hemos configurado un Plan de Pruebas que lanza 5 peticiones simultáneas a la página inicial de un servidor web. Realmente no estamos probando el servidor web con una carga realmente pesada (Podríamos aumentar la cantidad de hilos o las iteraciones del Grupo de Hilos) y tampoco tenemos resultados descriptivos acerca del comportamiento del servidor frente a cargas pesadas (Podríamos usar un receptor más especializado para esto como el Gráfico de Tiempo de Respuesta), éstos puntos y otros más los cubriremos en la siguiente parte de pseudo-tutorial de JMeter.

Fuente: http://jmeter.apache.org/usermanual

Si les ha parecido interesante la entrada, tienen comentarios, u opiniones acerca de este tema o alguno relacionado, siéntanse en la libertad de comentar. La meta es aprender.

jueves, 16 de mayo de 2013

Qué es la JVM, el JRE y el JDK? Y con qué se come todo eso?

Una vez leí algo como: "Si te preguntan algo y la respuesta solo le servirá a quién te preguntó, dísela. Pero si la respuesta le servirá a muchos, escríbela en un blog y publica el link". Así que aquí estoy con la intención de poder explicar un poco mejor qué significan cada una de estas siglas y poder resolver algunas de las dudas más comunes que tiene la gente que empieza a aprender Java.

A continuación muestro una imagen que tenemos para ilustrar un poco la interacción de algunos componentes de los que hablaremos y su interacción con los componentes del computador.

Esquema conceptual JRE

Como se puede observar en la Figura 01, Cuando hablamos del JRE, hablamos de un componente de software instalado sobre el sistema operativo (que puede ser por ejemplo: Windows, Linux, Solaris, etc.), el mismo que a su vez puede estar instalado en hardware de distintos fabricantes (por ejemplo: Intel, Motorola, etc.).

El JRE, o Java Runtime Environment, como su nombre lo indica es el ambiente de ejecución de aplicaciones Java. Es decir que es el requerimiento mínimo de software que debe tener un equipo para poder ejecutar o correr aplicaciones desarrolladas en Java. Este componente JRE está compuesto básicamente por: La pila de clases Java (las clases que conforman el API) y un componente muy especial llamado Java Virtual Machine.

El API de Java son todas las clases que componen el ambiente de Java y son las clases básicas que al ser utilizadas desde la aplicación podrán ser interpretadas y ejecutadas por la máquina virtual de Java. Un acercamiento a esta pila de clases puede ser encontrado aquí, en la documentación oficial de Java.

Por otra parte, la JVM, o Java Virtual Machine, es justamente un componente de software que actúa como una máquina virtual o un espacio virtual de memoria en donde se ejecutarán las aplicaciones Java. Cada aplicación java ejecutada en un proceso diferente se iniciará en una instancia diferente de la máquina virtual de Java. Y es justamente éste componente el que se encarga de interpretar cada una de las líneas de código "compilado" en Java (bytecode). 

La JVM es la que traducirá cada una de las sentencias del bytecode de Java en sentencias que entienda el sistema operativo y hardware del equipo. Es justamente éste componente el que permite que un código escrito en Java pueda ejecutarse sobre cualquier sistema operativo y hardware, siempre y cuando exista instalada sobre el equipo. De ahí el motivo de que existan tantas versiones del JRE (por lo general una para cada familia de sistemas operativos de 32 y 64 bits). Aquí podrán encontrar las versiones del JRE que actualmente ofrece para descarga el sitio de Oracle.

Muy bien entonces, podemos ver que el JRE es lo que tengo que tener instalado en mi máquina para que pueda ejecutar mis aplicaciones Java (apoyadas en el API de clases y gestionadas en tiempo de ejecución por la JVM). Y, lo más probable es que cualquier equipo que se conecte y navegue por internet ya tenga instalado este componente ya que el mismo, sigue siendo necesario para ejecutar o visualizar correctamente uno que otro sitio de internet.

Entonces, qué es el JDK? El JDK, o Java Development Kit, no es otra cosa que un componente de software que embebe todo lo que posee el JRE pero además de eso, trae las herramientas necesarias para el desarrollo de aplicaciones Java: el compilador, empaquetado de archivos JAR, etc. Aquí podrán encontrar las versiones del JDK que actualmente ofrece para descarga el sitio de Oracle.
En un equipo puede haber varios JDK (de distintas versiones) instalados, y éstos pueden ser utilizados a voluntad siempre y cuando se configure correctamente la herramienta de desarrollo (por ejemplo: Eclipse), sin embargo, el sistema operativo por lo general únicamente poseerá el JRE más nuevo. Es decir que si yo tengo instalado en mi máquina el JDK 1.6 y JDK 1.7, el JRE que utilizará el sistema operativo para ejecutar las aplicaciones en Java general será el JRE 1.7.

Muchas herramientas de desarrollo, contenedores web (por ejemplo: Tomcat) para su ejecución requieren estrictamente un JDK instalado, debido a todas las operaciones de compilación y despliegue que realizan durante su ejecución.

Si les ha parecido interesante la entrada, tienen comentarios, u opiniones acerca de este tema o alguno relacionado, siéntanse en la libertad de comentar. La meta es aprender.




jueves, 25 de abril de 2013

API para el manejo de archivos de propiedades (Properties)


Una de las funciones más utilizadas en Java (y otros lenguajes de programación) es la de poder guardar parámetros de configuración (o propiedades, como deseen llamarlo) en archivos de texto plano. En Java, estos archivos reciben el nombre de "Property File" o "Archivo de propiedades", y se encargan de almacenar información como pares "clave - valor". Por ejemplo:

//clave=valor
Default.IPServidor=127.0.0.1
Default.PuertoServidor=8081
Default.UsuarioBaseDeDatos=hr
//…etc.

En Internet se pueden encontrar muchos tutoriales para poder aprender y comenzar a utilizarlos, la verdad, no es nada del otro mundo. Sin embargo, algo que es también conocido y resulta muy repetitivo es el hecho de que el desarrollador debe encargarse de toda la lógica para poder: ubicar el archivo de propiedades, validar su existencia, cargar el archivo en memoria, validar la existencia de los parámetros en el archivo, y todo el manejo y propagación de excepciones que esto conlleva.

Es ahí donde entra el pequeño API que encontré en una de esas tardes en que la necesidad golpea tu mente y piensas “alguien más también tuvo este problema y de seguro lo resolvió” (uno de los principios de un buen desarrollador es aprender a copiar y pegar, siempre tratar de no reinventar la rueda).

El API se llama “OWNER” y lo que permite básicamente es abstraer toda esa lógica nombrada anteriormente, y orientarse a desarrollar una interfaz simple de Java, que con ayuda de unas cuantas anotaciones queda lista para poder ser un objeto configurado al que le podemos solicitar las propiedades que deseemos las veces que queramos. Únicamente lo que debemos hacer es:

  1. Crear una interfaz Java que me represente los métodos de obtención de valores. Un método por cada propiedad. 
  2. Configurar la o las rutas de los archivos de propiedades desde los cuales se encargará de tomar los datos. 
  3. Configurar para cada método la “clave” o propiedad cuyo valor se encargará de ofrecer. Y de ser necesario, un valor por defecto, en caso de que no encuentre el valor en ninguno de los archivos cuyas rutas han sido configuradas. 

A continuación les dejo la dirección de la página oficial del API en mención que ya he comenzado a probar y me ha dado buenos resultados. Espero en una futura entrada poder hacer un pequeño tutorial acerca de la utilización de este API. (Pese a que en su página se muestra de una manera bastante clara y sencilla su utilización).


Vale recalcar que la descarga del sitio oficial, son archivos fuentes. Tomé la libertad de tomar estos fuentes y crear un JAR para poder facilitar la transportación de estas clases y la librería de OWNER como tal. Esto simplificará la tarea de utilizar este API en cualquier proyecto (únicamente agregando el JAR en el destino necesario).

El link al JAR es el siguiente.

Si les ha parecido interesante la entrada, tienen comentarios, u opiniones acerca de este API o alguno relacionado, siéntanse en la libertad de comentar. La meta es aprender.

martes, 23 de abril de 2013

Bibliografía infaltable para iniciar en Java


Como podrán ver se me ocurrió que una buena idea para un primer post (funcional, porque el de bienvenida no aporta mucho que digamos...) sería el de publicar un buen material base para iniciar en este mundo conocido como Java.

No se me ocurrió uno mejor que el que aquí les presento. Hace un par de años llegó a mis manos y desde el principio me pareció excelente, no solo por el alto nivel didáctico que posee sino por la calidad del contenido. (Es uno de los libros recomendados para la Certificación de Programador en Java J2SE). El libro es de la editorial O'Reilly, que ya es ampliamente conocida por la gran aceptación de sus trabajos en el mundo de IT.

¿A qué me refiero por "contenido didáctico"? Pues a lo que se imaginan: a juegos, imágenes, globitos de pensamientos, sopas de letras, dibujitos explicativos, etc. Si, lo sé, resulta difícil de creer que un documento del calibre que se requiere para una certificación sea así de "informal", pero eso es un punto en lo que se destaca O'Reilly. Incluso habrá personas que se sientan tratadas como estudiantes de primaria mientras lo leen, pero les confieso que con toda la experiencia que tengo en Java, desde el primer capítulo comencé a aprender cosas nuevas, conceptos e ideas que tal vez no se necesiten para programar aplicaciones medianas en Java, pero que llegan a ser la diferencia entre conocer el resultado de nuestro programa y, conocer qué es lo que esta pasando y no estamos viendo durante la ejecución de nuestro programa. Recordemos que los principiantes saben “cómo” y los profesionales saben “cuándo”, pero los maestros saben “porqué”.

La única desventaja característica especial es que está en inglés; aún no encuentro una versión en español, y sinceramente no creo que exista, por lo menos hablando del libro completo, pero espero que el público que lea esta entrada se encuentre en buenas relaciones con el inglés, para los que no, les aconsejaría de la manera más sincera que vayan haciendo las paces con el idioma mencionado. En el mundo de TI y la programación todo avanza tan rápido que la información que va apareciendo en páginas en idioma español ya está desactualizada en el momento de su publicación, lamentablemente no nos podemos dar el lujo de esperar a que la información esté en nuestro idioma natal para poder acceder a ella. En el último de los casos, recuerden que de todas maneras, siempre contaremos con nuestro amigo Traductor de Google.

El link al archivo, es el siguiente.

El inicio


Desde hace mucho tiempo tengo ganas de comenzar un blog pero muchas dudas acechan y siguen acechando... Los temas a discutir, la calidad de mi escritura, el compromiso que estoy adquiriendo, todos éstos puntos dan vueltas en mi cabeza y han hecho que tarde en decidirme si comenzar o no el blog. Al final, creo que las ganas de querer compartir información por sencilla o superflua que me pudiere parecer le ganaron a la indecisión.

Soy ingeniero en sistemas computacionales, y tengo unos cuantos años de experiencia en el desarrollo de aplicaciones Java, lenguaje que dicho sea de paso, me agrada no sólo por su naturaleza de libertad sino por todo el ecosistema que ha logrado llegar a representar en los últimos años. Es un lenguaje que abarca desde aplicaciones de escritorio hasta aplicaciones del lado del servidor, pasando por aplicaciones para móviles (BlackBerry, Android), etc. Como todo lenguaje de programación, posee sus ventajas y desventajas, pero es innegable la cuota de mercado que ha llegado a abarcar.

Últimamente desempeño mis tareas en el área de arquitectura e innovación de la empresa en donde trabajo, brindándome la oportunidad de poder ejecutar proyectos en donde básicamente el aprendizaje nunca termina, si lo ven como yo, me pagan por aprender. Cada día encuentro uno que otro tópico interesante sobre el cual compartir, alguna experiencia que me recuerda que existen ciertos puntos que por su importancia, deben siempre tenerse en cuenta. No digo que la línea del blog vaya a ser siempre Java, sin embargo lo más probable es que la mayoría de entradas vayan orientadas hacia ese lenguaje.

Mi objetivo será siempre el de compartir información que me ha sido útil, y que muchas veces, por las barreras del idioma no se pueden entender o simplemente parecen intimidantes. Lo único que espero es que todo lo publicado aquí sea de ayuda para quien la necesite. Y si se trata de aprender de experiencias de otros, pues los comentarios de los lectores siempre serán bienvenidos.