Posts Tagged ‘Java’


Si eres programador y sobre todo fanático de las herramientas que se instalan y ya funcionan, te habrá pasado alguna vez que sin razón alguna, uno de esos programas deja de funcionar como debe, sin que haya ocurrido problema alguno. Muy probablemente, lo que ha pasado es que se hayan malogrado tus variables de entorno, en especial la variable PATH.

Desde tiempos de DOS, las variables de entorno fueron un tema crítico. Configurar adecuadamente tu autoexec.bat y tu config.sys era básico para todo usuario que empezaba a usar mouse o que tenia la suerte de tener módulos de memoria adicional, querias crear discos virtuales o simplemente querias jugar Accolade o Digger en colores en tu super modern monitor CGA.

Para la gran mayoria de usuarios finales, estos conceptos simplemente son innecesarios porque la evolución de Windows es manejar todo en la parte gráfica y de preferencia en forma automática. Para los programadores la cosa es diferente porque simplemente no todo lo que usamos es visual.

Para tener en cuenta:

  • Las variables de entorno no tienen un máximo de longitud por si mismas, pero si todo el bloque de entorno. Además, ya que no hay ni un autoexec.bat (windows antiguo) o init_profile (Linux) tienes que ir a esta pantalla para organizar tus variables de entorno

environment

  • En este artículo se explica de forma práctica como es eso del límite en las variables de entorno, pero lo más importante es que nos dice que ya que si estamos usando esa pantallita que graba todo en el registro, hay un límite de longitud de 2048 caracteres. ¿Podría ser mas largo? si, teóricamente podríamos llegar hasta 32000 caracteres pero por usar el registro y la pantalla esa, no hay mas.
  • Las variables de entorno pueden llenarse y nadie te va a avisar. Por lo general los nuevos valores se agregan al final, pero he visto que algunos programas agregan valores al inicio. Consecuencia: rutas borradas de la variable
  • PATH es una variable de entorno muy importante, incluso programas “visuales” la siguen usando. Ademas, hay otras como JAVA_HOME,ADT_HOME y otros que afectan increiblemente el funcionamiento de algunos programas y si has llegado hasta aquí es porque eres programador y sabes de lo que hablo.

Con todo esto en la cabeza, pues será muy lógico seguir estos consejos:

  • Guarda un backup del contenido de tus variables de entorno. Si te toca jugar con Java, Perl, Ruby, Python y esas cosas pues te toca cuidar tus variables de entorno como oro.
  • Instala tus programas mas importantes en carpetas con nombres cortos. Hasta ahora odio al cliente de SQL server porque instala sus cosas en rutas larguisimas que van directo al PATH, mal.
  • Si tienes una ruta larga que se repite varias veces, crea una variable de entorno. Por ejemplo:
    • Tiene que agregar las rutas ‘c:\ruta muy larga\sub carpeta mas larga aun\bin’ y ‘c:\ruta muy larga\sub carpeta mas larga aun\tools’.
    • Crea la variable LARGO con valor ‘c:\ruta muy larga\sub carpeta mas larga aun’
    • A la variable PATH agregarás: %LARGO%\bin y %LARGO\tools

¿Porqué pasa todo esto? porque Windows incluso en la version 10, está orientado a la interacción visual, y un programador está orientado a todo tipo de interacción. En los sistemas operativos basados en Linux como Ubuntu o Mac OSX, esto de la configuración del entorno es pan de cada día y directamente a los archivos, en este caso no hay una pantalla tan amigable como la que tiene Windows que sin querer impuso el límite de 2048 caracteres.

Así que ya sabes, si por ahí tu Android SDK no funciona o tu Perl dejó de trabajar, revisa la variable de entorno PATH que seguro algún instalador la modificó.


http://venturebeat.com/2012/06/29/amazon-outage-netflix-instagram-pinterest/

 

Los problemas en los servicios de nube de Amazon, demuestran que no podemos depender de un solo proveedor en algo tan crítico como “Hosting mejorado” como es el tema de la nube. Amazon, guarda, ademas del almacenamiento de contenido estático, parte de la lógica del negocio de muchos servicios, implementado en el API que proveen para aprovechar su plataforma.

Si Pinterest quiere guardar la información de un nuevo usuario, pues utiliza el API de Amazon para comunicarse con la infraestructura para guardar esa información. Como es esta API no interesa, lo que interesa es que si luego Pinteres quiere pasarse a Microsoft Azure, tendrá que rediseñar esa parte de código para utilizar las API de Azure. Esto no es simplemente guardar algunas páginas en PHP o Java como era antes. Se trata de que cada servicio de computación en la nube tiene una capa de encapsulamiento que le añade complejidad al asunto de migrar de proveedor.

Ahora, para ser sinceros, un buen diseño hará que esta dependencia sea la menor posible, haciendo por ejemplo que la parte de interfase de usuario se ejecute en servidores convencionales, que pueden estar almacenados en servicios de hosting convencionales con un costo mucho menor y por sobre todo, pudiendo usar varios proveedores a la vez. El core del negocio sería el único que se ejecutaría en los servidores de nube. Esto haría que la cantidad de código a migrar sea mínima y un ahorro de costos  relativamente alto.

Si bien esto del diseño ayuda, no corrige un problema principal: Aún seguiríamos siendo dependientes de un solo proveedor de código “core”, sería un “hard core”.

Aquí viene una idea para los proveedores de nube abiertos: Un API universal para el manejo de múltiples “hard cores” que sería invocado por todos nuestros Front End ofreciendo una capa de abstracción a todas las llamadas que hagamos al hard core que esta vez, podría estar en múltiples servicios de nube. Un ejemplo:

Si tengo un metodo de crear usuario en Azure, pudiera implementarlo como un servicio REST, y haría lo mismo en Amazon EC2, y lo mismo en Google App Engine. Todos estos servicios estarían registrados bajo un mismo metodo de un servicio mas grande, pero mucho mas ligero, que habitaría en cada Front end donde exista un metodo CrearUsuario y que  elegiría el proveedor de hard core mas conveniente para cada llamada y que haría la gestión de la sesión, ya que el hard core tendría que ser sin sesión para asegurar la máxima redundancia y performance.

En temas de rendimiento, el concepto nuevo aqui es verificar la salud de cada servicio, para lo cual cada proveedor de nube tendría que entregar un método para verificarlo en todo momento. Nuestra capa de abstracción podría hacer esta verificación en un proceso separado y periódico a fin de no afectar el tiempo de procesamiento de cada llamada.

Sería como un MVC donde pondríamos una capa mas entre el V y el C.

Un API abierto tendría que considerar otras cosas como un servicio propio de Accounting , a fin de verificar cuanto se ha utilizado de cada uno de los hardcore, un control central para hacer un override de la inteligencia de forma remota, y tal vez un tema de gestión de los hard core.

Un API para generar “Agentes” que gestionen cada uno de los hard core que tenemos contratados con servicios de gestión remota sería un buen proyecto para los programadores que van por ahí haciendo cosas interesantes solo por diversión.

¿ En  qué lenguaje debe estar ? Java definitivamente porque es el único framework que nos asegura total libertad a la hora de buscar un servicio de hosting.





%d bloggers like this: