Archive for the ‘Java’ Category

Articles

Java vive y dará la pelea.

In Desarrollo Software,Java,Noticias del Software,Rails,Software Process Improvement on noviembre 4, 2011 por racar

Duke, the Java Mascot, in the waving pose. Duk...

Image via Wikipedia

El mes que pasó, en la Java One, se dio el lanzamiento de la version 7 de java y se anunció la 8, animándome un poco a presentar el early upgrade de la recién salida versión 7, encuentro  dos cosas que me llaman la atención: que los cambios son significativos (de hecho java 8 esta proclamada como una revolución), y que dichos cambios están influenciados por el extraordinario éxito de los lenguajes dinámicos con que disponemos para programar actualmente en la plataforma. Hoy por hoy sobre la plataforma java es posible construir programas escritos en una variada gama de lenguajes funcionales y dinámicos: groovy, jruby, scala, jphyton. ¿En que momento llegaron a competirle a java en su propia VM? ¿Que causó esta disrupción? Bueno, he aquí un análisis resumido de la posible respuesta:

En el principio de los tiempos (en la JVM) solo se compilaba java…. los lenguajes de programación dinámicos, de alto nivel y orientados a objetos ya sea Python o Ruby, no tenían la influencia actual porque eran considerados “peligrosos” por el Status Quo corporativo. Debido a su característica dinámica resulta más difícil detectar bugs  y los errores se detectaban “in run time”; también son débilmente tipados y los todo poderosos IDES no pueden realizar sugerencias de autocompletado precisas y no pueden hilar eficientemente los trazos del stack de ejecución, sobretodo en las closures. Estas propiedades de los lenguajes dinámicos no permiten hacer debuggers eficientes.

Pero algo cambio:

Primera singularidad: Agile manifesto y extreme programming.  A finales de los 90’s, un grupo de revolucionarios llegó con ideas nuevas; hastiados de la burocracia corporativa que impuso la separación entre los managers/arquitectos y los “mortales” (desarrolladores), se fueron lanza en mano contra la metodología en cascada. El manifiesto ágil fue una proclama de mejores formas de construir software y trajo consigo las practicas que revolucionarían la profesión: el extreme programming. XP trajo varias practicas, entre ellas destaco dos: Test-Driven Development y Continuous integration. El primer golpe a la burocracia corporativa en torno al desarrollo de software se había dado.

Segunda singularidad: La filosofía “Getting Real” y el nacimiento de Rails. Casi 5 años después, en el 2005 aparece la máxima expresión de la metodología de desarrollo ágil de software, evitando la metodología predicativa formal esta se enfoca en crear aplicaciones útiles, innovadores (con alto valor creativo) y sencillas a partir de entregas pequeñas y continuas. Rails había nacido y trajo consigo totalmente integradas las practicas de XP y varias practicas mas: estructura robusta de testing, estructura fija de configuración sin XML, filosofía DRY o favorecer el re uso evitando las tareas repetitivas, estructura MVC y toda una serie de herramientas (ActiveRecord p. e.). Con esto, los desarrolladores se enfocan en crear la lógica del negocio y la parte creativa/innovadora de las aplicaciones. Con TDD y C.I. ya no se necesita el debugger y la fase de compilación. El segundo golpe, aun más fuerte.

La filosofía agile, va en contra del status quo corporativo y revoluciona o resiste la tendencia burocrática que favoreció los lenguajes estáticos como Java, también fomenta las practicas como TDD y continuos integration que derriban la teoría de la necesidad de un compilador y un debugger para detectar errores. Además de todo esto, añaden alta productividad al fomentar la automatización de tareas de desarrollo.

Cualquier desarrollador encuentra atractivas las ideas (y frameworks) detrás de los lenguajes dinámicos. Sin embargo Java ha respondido al cambio y después de un letargo, esta adaptándose al futuro en su versión 7 (coin) y sobretodo en la 8 (lambda). Java vive y dará la pelea!!.

Anuncios

Articles

Jquery y el lado del servidor.

In c#,Java,jquery on febrero 11, 2011 por racar

Asychronous JavaScript And XML is AJAX

Image via Wikipedia

En aplicaciones Web el modelo MVC no se puede cumplir estrictamente, generalmente el modelo se convierte en algo como M-VC, es decir, la lógica de la aplicación va ha estar muy ligada a la GUI construida en HTML. Cuando utilizamos javascript, jquery o cualquier otra librería en aplicaciones empresariales, la interacción con el lado del servidor es un reto importante. Parte de la lógica se nos va a quedar en el cliente. La primera sugerencia que tengo es que si bien javascript soporta el paradigma OO, es un lenguaje bien particular que toca aprender muy bien para no caer en la “trampa” de tratarlo como si fuese un lenguaje de origen “empresarial”: java o c#. Los buenos hábitos dependen del lenguaje. (Lenguajes como javascript,  ruby, perl, phyton, php fueron creados por programadores con otro objetivo en mente: productividad).

Lo otro es cuando comunicamos el servidor con el cliente Web, que sea en un formato “amable” con javascript, ya el pobre cliente tiene que lidiar con el DOM del navegador como para que lo pongamos a interpretar más XML.

Por ultimo, la sesión del cliente es diferente a la sesión del servidor. Y aunque esto aparentemente es obvio, hay que tener cuidado porque tecnologías como asp.net o jsf en jee tienen una manera diferente de interpretar los componentes, el id de un elemento html no necesariamente es el id que se interpreta del lado del servidor. Asp.net utiliza una combinación de los atributos id y name, por ejemplo, y jsf genera un id completamente nuevo. Son sesiones diferentes y cuando interactuamos con un componente del lado del servidor con javascript, los cambios se van a reflejar en el request o la petición http, y tienen que ser capturados “manualmente”.

Articles

En la nube con Google App Engine

In Cloud Computing,Computación en nube,Google App Engine,Java on abril 27, 2010 por racar

Hoy publique mi primera “aplicación?” en “la nube”. Aparentemente, la publicidad tuvo su efecto, la tarea era probar como va el AppEngine de google. Desde mi punto de vista y a groso modo, al realizar un survey de las plataformas y su documentación, el AppEngine de Google es la opción mas facil y accesible  por curva de aprendizaje y precio.  Azure por lo que vi, no deja subir una aplicación prueba.

Amazon WS  está en otra categoría, esta plataforma  se enfoca en la infraestructura, al proveer una serie de servicios y una VM que las aplicaciones pueden utilizar, a diferencia, en AppEngine se construye una aplicación y la plataforma provee el entorno de ejecución. Los términos utilizados para estos dos modelos de Cloud computing (SaaS)  son Infraestructure as a Service (IaaS) y Plataform as a Service (PaaS). Las ventajas de una sobre la otra es  flexibilidad vs complejidad en el desarrollo.

La aplicación demo es esta: http://senderotech.appspot.com/

El tutorial de google esta muy claro y es fácil iniciarse.  Después de subir la aplicación, aparecen muchos datos de consumo, peticiones y demás muy interesantes, google me deja impresionado. Acá pongo unas pantallas.