Mostrando entradas con la etiqueta framework. Mostrar todas las entradas
Mostrando entradas con la etiqueta framework. Mostrar todas las entradas

viernes, agosto 27, 2010

jQuery para Móviles a la Vuelta de la Esquina

"jQuery ahora en nuestros smartphones y tablets. Yuju! :D"

Recientemente me entero que la comunidad de desarrolladores de jQuery trae entre manos un prometedor proyecto que pretende llevar este popular framework a los browsers de los dispositivos móviles y sus hermanos mayores, las tablets. Este proyecto es denominado jQuery Mobile.

En el web existen pocos frameworks de javascript capaces de considerarse cross-browser y cross-device, especialmente cuando hablamos de dispositivos móviles. El equipo de jQuery tiene un gran reto en sus manos si quiere llevar a cabo este objetivo especialmente si consideramos que jquery no sobresale por su performance pero sí por su popularidad, su robustez en sus widgets de jquery-ui y por la gran cantidad de plugins que existen para extenderlo.

En este sitio ellos han publicado la lista de los browsers que actualmente existen para dispositivos móviles, clasificados según sus capacidades de ejecutar javascript y su compatibilidad con los estándares del W3C. jQuery planea soportar los browsers clase A y B, conformados por los smartphones de alta gama como iPhone, Blackberry, Dispositivos con Android, La serie N de Nokia, entre otros.

Los diseños que están planeando para el nuevo tema de jquery-ui para móviles se me hace muy similar a la interfaz y los controles del iOS en smartphones y al look and feel del MacOS y no era de esperar, ya que estas son en lo que a mi respecta las interfaces de usuario más amigables que existen a la fecha.

"Así lucirán los widgets de jQuery UI adaptados para smartphones"

Lo que distinguirá a este framework de los demás es que desde ya va pensado no solamente para smartphones sino también para tablets. Actualmente no conozco ningún framework para desarrollo web o aplicaciones nativas pensadas exclusivamente en el diseño y las capacidades de una tablet por lo que jQuery sería el pionero y la base para el futuro mercado de tablets que en un futuro no muy lejano pasarán a competir con el iPad.

Por el momento este proyecto aún se encuentra en fase de desarrollo y prometen liberarlo a finales del presente año por lo que habrá que estar pendiente de los avances de este prometedor proyecto de jQuery. Pueden seguir todos los avances en el blog del proyecto, en la cuenta de twitter de jQuery y en la wiki de jQuery Mobile, donde además pueden aportar ideas al proyecto.

jQuery para Móviles a la Vuelta de la Esquina

"jQuery ahora en nuestros smartphones y tablets. Yuju! :D"

Recientemente me entero que la comunidad de desarrolladores de jQuery trae entre manos un prometedor proyecto que pretende llevar este popular framework a los browsers de los dispositivos móviles y sus hermanos mayores, las tablets. Este proyecto es denominado jQuery Mobile.

En el web existen pocos frameworks de javascript capaces de considerarse cross-browser y cross-device, especialmente cuando hablamos de dispositivos móviles. El equipo de jQuery tiene un gran reto en sus manos si quiere llevar a cabo este objetivo especialmente si consideramos que jquery no sobresale por su performance pero sí por su popularidad, su robustez en sus widgets de jquery-ui y por la gran cantidad de plugins que existen para extenderlo.

En este sitio ellos han publicado la lista de los browsers que actualmente existen para dispositivos móviles, clasificados según sus capacidades de ejecutar javascript y su compatibilidad con los estándares del W3C. jQuery planea soportar los browsers clase A y B, conformados por los smartphones de alta gama como iPhone, Blackberry, Dispositivos con Android, La serie N de Nokia, entre otros.

Los diseños que están planeando para el nuevo tema de jquery-ui para móviles se me hace muy similar a la interfaz y los controles del iOS en smartphones y al look and feel del MacOS y no era de esperar, ya que estas son en lo que a mi respecta las interfaces de usuario más amigables que existen a la fecha.

"Así lucirán los widgets de jQuery UI adaptados para smartphones"

Lo que distinguirá a este framework de los demás es que desde ya va pensado no solamente para smartphones sino también para tablets. Actualmente no conozco ningún framework para desarrollo web o aplicaciones nativas pensadas exclusivamente en el diseño y las capacidades de una tablet por lo que jQuery sería el pionero y la base para el futuro mercado de tablets que en un futuro no muy lejano pasarán a competir con el iPad.

Por el momento este proyecto aún se encuentra en fase de desarrollo y prometen liberarlo a finales del presente año por lo que habrá que estar pendiente de los avances de este prometedor proyecto de jQuery. Pueden seguir todos los avances en el blog del proyecto, en la cuenta de twitter de jQuery y en la wiki de jQuery Mobile, donde además pueden aportar ideas al proyecto.

lunes, febrero 08, 2010

Adaptando tu Sitio Para Móviles - Parte 2

Esta es la segunda parte del post anterior de Adaptando tu Sitio Para Moviles - Parte 1, en el cual hablaba de los servicios que tea automatizan este proceso. Ahora explicaremos algunas librerías utiles para crear nuestros sitios móviles por nuestra cuenta.

Para crear una versión de tu sitio orientada a un dispositivo móvil debes considerar ciertas características de la navegación en móviles:

Ancho de banda: Entre estas, el hecho de que estos dispositivos se conectan por WiFi o 3g y el ancho de banda disponible puede ser mucho menor al de una computadora personal, por lo cual tendrás que evitar cargar las páginas con muchas imágenes y mucho contenido.

Contenido no soportado: Debes considerar también que no todos los dispositivos móviles soportan contenido rico como Flash (ehem, iPhones, iPods e iPads) así como tampoco no todos soportan Java, Silverlight, Active X o Adobe Air, entre otros. Hay muchos sitios basados en Flash que ni siquiera con la versión Lite, incluida en algunos móviles, pueden renderizar las animaciones de tu sitio. Especialmente porque, a diferencia de las imagenes y el contenido HTML habitual, las películas de Flash no se ajustan automáticamente al tamaño de la pantalla de tu dispositivo. Los que tienden a utilizar Flash para darle una gran vistosidad a su sitio como por ejemplo restaurantes, hoteles o páginas de artistas podrían considerar realizar estas mismas animaciones usando librerías Javascript como jQuery, Motools o Dojo y aun así no es recomendable colmar la página de tanto adorno y animación.

Procesamiento: El procesador de los dispositivos también te impedirá ejecutar mucho Javascript en tus páginas, es mejor dejar la mayor parte del procesamiento de información en el servidor web. Recuerda que en la actualidad los smartphones más avanzados poseen un procesador de no mas de 1Gz y la verdad es que en mi opinión, no necesitan mas de eso ya que tu smartphone no es una herramienta de trabajo que tendrá que realizar muchos cálculos en tu sitio. Su uso primordial es consumir/producir información, no procesarla.

Dimensiones de la pantalla: Las dimensiones de las pantallas en los dispositivos móviles, si bien hoy en día abarcan toda la superficie de los mismos, es mucho más reducida que la de un monitor de una PC(480x320px en un iPhone, 800x480 en un Nokia N900, 360x480 en un Blackberry Storm y 800x480 en un Google Nexus One). Esto te obligará a distribuir el contenido de tu sitio en un espacio más reducido quizá dividiéndolo en diferentes páginas o eliminándolo si no es tan necesario. En un blog, por ejemplo, ya no se deben incluir los típicos widgets contadores de visitas, shoutboxes, secciones de últimos comentarios, etc. Si se desea hacerlo, podria utilizarse una pagina aparte que sirva como "About".

Interacción con el usuario: Un usuario comunmente interactua con un Smartphone haciendo uso de sus dedos o un Stylus, haciendo "taps" en lugar de clics para abrir vínculos y haciendo "swipe" para mover las scrollbars y visualizar más contenido. Hay ciertos eventos que no se podrán producir desde un Smartphone, por ejemplo el drag&drop (basado en el evento mouseover), combinaciones de teclas con Ctrl-Shift-Alt, scrolling, etc. En esta tabla pueden encontrar una completa referencia sobre los eventos, tags HTML y atributos CSS soportados por la mayoria de navegadores web para móviles.

Librerías

En mi opinión personal, el dispositivo que más ha popularizado su sistema operativo, el cual además revolucionó las interfaces gráficas para dispositivos móviles es hasta la fecha el iPhone. Si deseas que tu aplicación web tenga la apariencia y animaciones similares a las de este dispositivo puedes hacer uso de la libreria jQTouch, la cual es en realidad un plugin para el popular framework de javascript jQuery que simula la apariencia y animaciones propias de las interfaces de un iPhone OS.

Acá puedes ver un demo de las caracteristicas de jQTouch (visualizarlo desde un smartphone) y a continuación puedes ver un vídeo de las features principales de dicha libreria:




"Features generales de jQTouch"

Segun comentan en su sitio, la YUI Library también funciona perfectamente en lo que ellos denominan browsers Grado A.

Otra buena libreria de javascript especializada en el desarrollo de sitios web para móviles es WebAppNet. Esta es otra libreria que simula la UI y animaciones del iPhone OS. Puedes ver un demo de sus features (desde un móvil preferiblemente) en este sitio. A continuación un preview de este demo, visualizado desde un iPod Touch:

"Aplicación Demo que muestra la apariencia y features de la libreria WebAppNet, visualizada desde un iPod Touch"


Por último los invito a leer el siguiente post recomendado para desarrolladores de sitios web para iPhone y otros móviles, con muchas otras ideas a tomar en cuenta a la hora de realizar nuestros sitios. En este otro sitio tambien pueden encontrar documentacion, patrones de diseño y guias para crear sitios para móviles. Además, no te olvides de comprobar la compatibilidad de tu sitio mediante este test del w3c especifíco para sitios web orientados a smartphones.

"Resultados de Mobile Safari en el Test de Compatibilidad de Browsers para Móviles, del w3c"

Si necesitas ofrecerle a tus usuarios algo mas que contenido y los navegadores para móviles no te lo permiten, siempre puedes optar por programar una aplicación específica para smartphones haciendo uso de los SDKs que provee cada productor de smartphones.

Adaptando tu Sitio Para Móviles - Parte 2

Esta es la segunda parte del post anterior de Adaptando tu Sitio Para Moviles - Parte 1, en el cual hablaba de los servicios que tea automatizan este proceso. Ahora explicaremos algunas librerías utiles para crear nuestros sitios móviles por nuestra cuenta.

Para crear una versión de tu sitio orientada a un dispositivo móvil debes considerar ciertas características de la navegación en móviles:

Ancho de banda: Entre estas, el hecho de que estos dispositivos se conectan por WiFi o 3g y el ancho de banda disponible puede ser mucho menor al de una computadora personal, por lo cual tendrás que evitar cargar las páginas con muchas imágenes y mucho contenido.

Contenido no soportado: Debes considerar también que no todos los dispositivos móviles soportan contenido rico como Flash (ehem, iPhones, iPods e iPads) así como tampoco no todos soportan Java, Silverlight, Active X o Adobe Air, entre otros. Hay muchos sitios basados en Flash que ni siquiera con la versión Lite, incluida en algunos móviles, pueden renderizar las animaciones de tu sitio. Especialmente porque, a diferencia de las imagenes y el contenido HTML habitual, las películas de Flash no se ajustan automáticamente al tamaño de la pantalla de tu dispositivo. Los que tienden a utilizar Flash para darle una gran vistosidad a su sitio como por ejemplo restaurantes, hoteles o páginas de artistas podrían considerar realizar estas mismas animaciones usando librerías Javascript como jQuery, Motools o Dojo y aun así no es recomendable colmar la página de tanto adorno y animación.

Procesamiento: El procesador de los dispositivos también te impedirá ejecutar mucho Javascript en tus páginas, es mejor dejar la mayor parte del procesamiento de información en el servidor web. Recuerda que en la actualidad los smartphones más avanzados poseen un procesador de no mas de 1Gz y la verdad es que en mi opinión, no necesitan mas de eso ya que tu smartphone no es una herramienta de trabajo que tendrá que realizar muchos cálculos en tu sitio. Su uso primordial es consumir/producir información, no procesarla.

Dimensiones de la pantalla: Las dimensiones de las pantallas en los dispositivos móviles, si bien hoy en día abarcan toda la superficie de los mismos, es mucho más reducida que la de un monitor de una PC(480x320px en un iPhone, 800x480 en un Nokia N900, 360x480 en un Blackberry Storm y 800x480 en un Google Nexus One). Esto te obligará a distribuir el contenido de tu sitio en un espacio más reducido quizá dividiéndolo en diferentes páginas o eliminándolo si no es tan necesario. En un blog, por ejemplo, ya no se deben incluir los típicos widgets contadores de visitas, shoutboxes, secciones de últimos comentarios, etc. Si se desea hacerlo, podria utilizarse una pagina aparte que sirva como "About".

Interacción con el usuario: Un usuario comunmente interactua con un Smartphone haciendo uso de sus dedos o un Stylus, haciendo "taps" en lugar de clics para abrir vínculos y haciendo "swipe" para mover las scrollbars y visualizar más contenido. Hay ciertos eventos que no se podrán producir desde un Smartphone, por ejemplo el drag&drop (basado en el evento mouseover), combinaciones de teclas con Ctrl-Shift-Alt, scrolling, etc. En esta tabla pueden encontrar una completa referencia sobre los eventos, tags HTML y atributos CSS soportados por la mayoria de navegadores web para móviles.

Librerías

En mi opinión personal, el dispositivo que más ha popularizado su sistema operativo, el cual además revolucionó las interfaces gráficas para dispositivos móviles es hasta la fecha el iPhone. Si deseas que tu aplicación web tenga la apariencia y animaciones similares a las de este dispositivo puedes hacer uso de la libreria jQTouch, la cual es en realidad un plugin para el popular framework de javascript jQuery que simula la apariencia y animaciones propias de las interfaces de un iPhone OS.

Acá puedes ver un demo de las caracteristicas de jQTouch (visualizarlo desde un smartphone) y a continuación puedes ver un vídeo de las features principales de dicha libreria:




"Features generales de jQTouch"

Segun comentan en su sitio, la YUI Library también funciona perfectamente en lo que ellos denominan browsers Grado A.

Otra buena libreria de javascript especializada en el desarrollo de sitios web para móviles es WebAppNet. Esta es otra libreria que simula la UI y animaciones del iPhone OS. Puedes ver un demo de sus features (desde un móvil preferiblemente) en este sitio. A continuación un preview de este demo, visualizado desde un iPod Touch:

"Aplicación Demo que muestra la apariencia y features de la libreria WebAppNet, visualizada desde un iPod Touch"


Por último los invito a leer el siguiente post recomendado para desarrolladores de sitios web para iPhone y otros móviles, con muchas otras ideas a tomar en cuenta a la hora de realizar nuestros sitios. En este otro sitio tambien pueden encontrar documentacion, patrones de diseño y guias para crear sitios para móviles. Además, no te olvides de comprobar la compatibilidad de tu sitio mediante este test del w3c especifíco para sitios web orientados a smartphones.

"Resultados de Mobile Safari en el Test de Compatibilidad de Browsers para Móviles, del w3c"

Si necesitas ofrecerle a tus usuarios algo mas que contenido y los navegadores para móviles no te lo permiten, siempre puedes optar por programar una aplicación específica para smartphones haciendo uso de los SDKs que provee cada productor de smartphones.

viernes, enero 15, 2010

JQuery Cumple 4 Años y lo Celebran con Muchos Releases

"Entre las novedades de jQuery presentan 14 días de releases continuos"

El día de ayer, 15 de Enero, jQuery celebró su cuarto cumpleaños de haber sido liberado y desde entonces los desarrolladores de este popular framework lo están celebrando a lo grande con la liberación de la verisón 1.4, un nuevo sitiopara la API, mejoras en el performance, QA en vivo, etc. En total serán 14 días durante los cuales tendremos nuevas sorpresas y releases relacionados con este framework, los cuales pueden consultar día a día en el sitio jquery14.com.

jQuery es un framework javascript open source que te ayuda principalmente a interactuar con el DOM de una página web de una forma muy práctica y con muy pocas líneas de código fuente. Además simplifica la comunicación vía ajax, el manejo de eventos, la creación y manipulación de controles para crear interfaces gráficas ricas, entre otras cosas.

Su gran popularidad y su capacidad de extensión mediante plugins ha permitido que muchos programadores lo hayan enriquecido con controles muy útiles como el datagrids, lightboxes, gráficos, skins, color pickers, por mencionar unos cuantos entre otros cientos de plugins que existen por ahí en la web.

"El plugin Flexigrid es de los más complejos y útiles que he utilizado con jQuery"

Lo que mas me encanta de usar jQuery es su facilidad para manipular el DOM. Como ejemplo, podemos ver el siguiente código fuente que utiliza sintaxis JSON de la nueva versión 1.4 para crear un DIV con id, propiedades CSS y una función para manejar su evento click para luego agregar este div al body de la página, todo de una sola vez:

 jQuery("<div/>", {
id: "foo",
css: {
height: "50px",
width: "50px",
color: "blue",
backgroundColor: "#ccc"
},
click: function() {
$(this).css("backgroundColor", "red");
}
}).appendTo("body");

Como muchos proyectos open source, jQuery sobrevive gracias a las donaciones altruistas hechas por los usuarios. Como parte de las sorpresas que los desarrolladores de jQuery nos han traido, también tienes la oportunidad de recibir un e-book gratuito por tu donación al proyecto.

JQuery Cumple 4 Años y lo Celebran con Muchos Releases

"Entre las novedades de jQuery presentan 14 días de releases continuos"

El día de ayer, 15 de Enero, jQuery celebró su cuarto cumpleaños de haber sido liberado y desde entonces los desarrolladores de este popular framework lo están celebrando a lo grande con la liberación de la verisón 1.4, un nuevo sitiopara la API, mejoras en el performance, QA en vivo, etc. En total serán 14 días durante los cuales tendremos nuevas sorpresas y releases relacionados con este framework, los cuales pueden consultar día a día en el sitio jquery14.com.

jQuery es un framework javascript open source que te ayuda principalmente a interactuar con el DOM de una página web de una forma muy práctica y con muy pocas líneas de código fuente. Además simplifica la comunicación vía ajax, el manejo de eventos, la creación y manipulación de controles para crear interfaces gráficas ricas, entre otras cosas.

Su gran popularidad y su capacidad de extensión mediante plugins ha permitido que muchos programadores lo hayan enriquecido con controles muy útiles como el datagrids, lightboxes, gráficos, skins, color pickers, por mencionar unos cuantos entre otros cientos de plugins que existen por ahí en la web.

"El plugin Flexigrid es de los más complejos y útiles que he utilizado con jQuery"

Lo que mas me encanta de usar jQuery es su facilidad para manipular el DOM. Como ejemplo, podemos ver el siguiente código fuente que utiliza sintaxis JSON de la nueva versión 1.4 para crear un DIV con id, propiedades CSS y una función para manejar su evento click para luego agregar este div al body de la página, todo de una sola vez:

 jQuery("<div/>", {
id: "foo",
css: {
height: "50px",
width: "50px",
color: "blue",
backgroundColor: "#ccc"
},
click: function() {
$(this).css("backgroundColor", "red");
}
}).appendTo("body");

Como muchos proyectos open source, jQuery sobrevive gracias a las donaciones altruistas hechas por los usuarios. Como parte de las sorpresas que los desarrolladores de jQuery nos han traido, también tienes la oportunidad de recibir un e-book gratuito por tu donación al proyecto.

miércoles, noviembre 18, 2009

Comparando Frameworks Web de Java

Para atender las crecientes necesidades de los programadores, que tratan de mantenerse a la par de la tecnología, existe una emergente gama de productos que se proponen solventar necesidades especificas (a veces de los autores más que de los usuarios finales) y emergentes. Muchos de estos productos (diseñados para hacer más llevadera la vida del programador) vienen en forma de "Frameworks", que tanto recomendamos por diversos motivos, como productividad, eficiencia, comodidad y mucha sanidad mental.


"Struts 2 es otro exitoso proyecto de Apache.org"

En el lugar donde trabajo, no utilizan un Web Frameworks en el proyecto en el que me encuentro, algo que por supuesto, reduce enormemente la productividad, trauma y molesta... mucho, realmente mucho.
Supongo que en varias empresas sucedera lo mismo, si es ese el caso, es una lastima, porque estan perdiendo el tiempo reinventando la rueda. Y recordemos que en las empresas, el tiempo es dinero.

Pero bien, regresando al caso, lo bueno es que hasta hace poco decidieron buscar el framework apropiado para utilizar al ambiente que se tiene ahí.
Naturalmente, emergen un sin fin de dudas y muchas situaciones que hay que tomar en cuenta, pues no es una decision enteramente basada en soporte de arquitectura, sino que la eleccion de un framework tambien tiene que ver con la gama de herramientas que lo soportan, que tan recientes son las librerias que emplea y de lo moderno que es en si la tecnologia que soporta.



"El framework del trabajo de grado :)"

En aquellos días en los que comenzamos la tesis Robertux, Hugol y su servidor, casi nos descabezamos para decidir que framework usar, y debo admitir de que en un principio no me gusto mucho la idea de utilizar ICEFaces, pero sinceramente no solo debo admitir de que ellos tomaron una excelente decision, sino que tambien ICEFaces es un framework que nos salvo la vida incontables veces a lo largo del desarrollo de nuestro trabajo de grado, a tal punto de terminarlo a tiempo y sin muchos problemas.

Pero aunque yo sea ahora un adepto confeso de ICEFaces, existe variedad de Java Web Frameworks para los gustos y las necesidades con las que ustedes se encuentren...

Voy a suponer que estan pasando por un proceso critico de modernizacion en donde trabajan, o alguien les pregunto sobre lo que pueden utilizar para determinado proyecto, o buscan que utilizar en su trabajo de grado. Con esta suposicion en mente, les quiero compartir dos excelentes recursos (actualizados) para elegir un web framework de Java.

El primero consiste en una encuesta realizada por Kimberly McClintock acerca Web Framework (la mayoría para Java) a un grupo de "expertos", a los que se les realizo una serie de preguntas para evaluar los frameworks en cuestión, el artículo completo se puede leer en: 10 Best Java Web Development Framework.


"OpenXava: El framework que te hace los CRUD automáticamente"

Y el segundo, consiste en una matriz comparativa de frameworks que utilizan la amena combinación de JSF + Ajax, esta matriz resulta de lo mas útil para los que están en la prisa de justificar porque usar uno u otro producto para un proyecto, así que recomiendo mucho que visiten la JSFMatrix.

Finalmente, para los que no quieren dar mucha vuelta o no tienen tiempo de leer, estos son los seis que yo puedo recomendar inmediatamente y sin mucha explicación:
Espero que estos recursos les sirvan para elegir correctamente el framework que les haga la vida más fácil. ¡Saludos!

Comparando Frameworks Web de Java

Para atender las crecientes necesidades de los programadores, que tratan de mantenerse a la par de la tecnología, existe una emergente gama de productos que se proponen solventar necesidades especificas (a veces de los autores más que de los usuarios finales) y emergentes. Muchos de estos productos (diseñados para hacer más llevadera la vida del programador) vienen en forma de "Frameworks", que tanto recomendamos por diversos motivos, como productividad, eficiencia, comodidad y mucha sanidad mental.


"Struts 2 es otro exitoso proyecto de Apache.org"

En el lugar donde trabajo, no utilizan un Web Frameworks en el proyecto en el que me encuentro, algo que por supuesto, reduce enormemente la productividad, trauma y molesta... mucho, realmente mucho.
Supongo que en varias empresas sucedera lo mismo, si es ese el caso, es una lastima, porque estan perdiendo el tiempo reinventando la rueda. Y recordemos que en las empresas, el tiempo es dinero.

Pero bien, regresando al caso, lo bueno es que hasta hace poco decidieron buscar el framework apropiado para utilizar al ambiente que se tiene ahí.
Naturalmente, emergen un sin fin de dudas y muchas situaciones que hay que tomar en cuenta, pues no es una decision enteramente basada en soporte de arquitectura, sino que la eleccion de un framework tambien tiene que ver con la gama de herramientas que lo soportan, que tan recientes son las librerias que emplea y de lo moderno que es en si la tecnologia que soporta.



"El framework del trabajo de grado :)"

En aquellos días en los que comenzamos la tesis Robertux, Hugol y su servidor, casi nos descabezamos para decidir que framework usar, y debo admitir de que en un principio no me gusto mucho la idea de utilizar ICEFaces, pero sinceramente no solo debo admitir de que ellos tomaron una excelente decision, sino que tambien ICEFaces es un framework que nos salvo la vida incontables veces a lo largo del desarrollo de nuestro trabajo de grado, a tal punto de terminarlo a tiempo y sin muchos problemas.

Pero aunque yo sea ahora un adepto confeso de ICEFaces, existe variedad de Java Web Frameworks para los gustos y las necesidades con las que ustedes se encuentren...

Voy a suponer que estan pasando por un proceso critico de modernizacion en donde trabajan, o alguien les pregunto sobre lo que pueden utilizar para determinado proyecto, o buscan que utilizar en su trabajo de grado. Con esta suposicion en mente, les quiero compartir dos excelentes recursos (actualizados) para elegir un web framework de Java.

El primero consiste en una encuesta realizada por Kimberly McClintock acerca Web Framework (la mayoría para Java) a un grupo de "expertos", a los que se les realizo una serie de preguntas para evaluar los frameworks en cuestión, el artículo completo se puede leer en: 10 Best Java Web Development Framework.


"OpenXava: El framework que te hace los CRUD automáticamente"

Y el segundo, consiste en una matriz comparativa de frameworks que utilizan la amena combinación de JSF + Ajax, esta matriz resulta de lo mas útil para los que están en la prisa de justificar porque usar uno u otro producto para un proyecto, así que recomiendo mucho que visiten la JSFMatrix.

Finalmente, para los que no quieren dar mucha vuelta o no tienen tiempo de leer, estos son los seis que yo puedo recomendar inmediatamente y sin mucha explicación:
Espero que estos recursos les sirvan para elegir correctamente el framework que les haga la vida más fácil. ¡Saludos!

sábado, octubre 24, 2009

Trabajando con Google Web Toolkit y Google App Engine


"Logotipo del framework Google App Engine"


Habiendo salido de mi tesis recientemente, me he interesado en buscar hobbies relacionados con programación y en plasmar muchas ideas de software que vinieron a mi cabeza mientras estaba ocupado haciendo el trabajo de grado. Uno de los inconvenientes que tenemos los desarrolladores Java es que no existen en internet tantas alternativas para hosting de aplicaciones así como la gran variedad disponible para el Stack LAMP (Linux/Apache/Mysql/PHP).

Además, cada programador Java está acostumbrado a trabajar con su propio Stack y es bastante diversa la gama de combinaciones que se pueden armar entre sistema operativo, application server y framework para el entorno visual así como la base de datos y el framework para la persistencia de los datos, esto sin mencionar las versiones de cada una de estas soluciones informáticas. Esto hace aun mas difícil encontrar entornos (pagados o gratuitos) donde alojar nuestras aplicaciones web a menos que nos decidamos a montar nuestro propio server.

Buscando en internet me dí cuenta que Google ofrece una alternativa sencilla y barata (gratuita hasta cierto punto) para alojar aplicaciones desarrolladas con Java: Google App Engine.

Este servicio de google te permite desarrollar aplicaciones relativamente sencillas y hostearlas dentro de los servidores que ellos mismos te ofrecen. Eso si, no puede ser cualquier tipo de aplicación y lo mejor sería desarrollar aplicaciones orientadas a esta plataforma de Google, ya que estos ya te ofrecen la alternativa para la persistencia de los datos y los frameworks visuales a utilizar.

La ventaja es que el soporte se ve bastante decente (te brindan un plugin para Eclipse que te hace la mayor parte del trabajo de configuración y el upload de tu aplicación) además que la documentación te explica el framework de una manera bastante sencilla. En la galería de aplicaciones puedes ver las aplicaciones que otros ya han publicado, notando que algunas pueden ser bastante complejas y de un acabado muy profesional.

Lo único a tener en cuenta es que nada mas puedes subir 10 aplicaciones como máximo, y no puedes borrar una aplicación que ya has subido al server de Google.

Otro tema que me llamó la atención al navegar entre las soluciones de desarrollo de google fue el GWT, Google Web Toolkit. Este es un framework visual para apps web que te permite desarrollar aplicaciones sin la necesidad de escribir HTML o Javascript, generándolo todo desde clases Java. Es un framework bastante joven comparado con JSF, Struts o Tapestry pero teniendo el respaldo de google puede llegar lejos, ademas la idea de no escribir HTML será un alivio para muchos desarrolladores web que no saben mucho de estructuración y decoración de sitios web con HTML/CSS y desean una solución rápida y sencilla para sus interfaces. Al igual que con el App Engine Framework, Google apuesta nuevamente por eclipse brindando soporte para la creación de proyectos de GWT mediante asistentes y el uso de un navegador embedido que te permite realizar pruebas de tus aplicaciones sin necesidad de hacer deploy.

"Aplicación de ejemplo de uso de GWT, creada a partir de un proyecto web de eclipse con el plugin de GWT y App Engine. En la captura pueden apreciar el browser embedido que incluye el framework de GWT."

Cabe mencionar que GWT puede ser usado nada más para generar el HTML/Javascript de un sitio, usando cualquier otro lenguaje de programación del lado del server. Como ellos bien lo mencionan, este puede ser usado para generar front-ends en aplicaciones Ruby, Python, etc. Además es full Ajax-enabled trabajando de forma transparente con invocaciones a código del lado del servidor hecho con Java y mediante el uso de XML-RPC para otros lenguajes.

Trabajando con Google Web Toolkit y Google App Engine


"Logotipo del framework Google App Engine"


Habiendo salido de mi tesis recientemente, me he interesado en buscar hobbies relacionados con programación y en plasmar muchas ideas de software que vinieron a mi cabeza mientras estaba ocupado haciendo el trabajo de grado. Uno de los inconvenientes que tenemos los desarrolladores Java es que no existen en internet tantas alternativas para hosting de aplicaciones así como la gran variedad disponible para el Stack LAMP (Linux/Apache/Mysql/PHP).

Además, cada programador Java está acostumbrado a trabajar con su propio Stack y es bastante diversa la gama de combinaciones que se pueden armar entre sistema operativo, application server y framework para el entorno visual así como la base de datos y el framework para la persistencia de los datos, esto sin mencionar las versiones de cada una de estas soluciones informáticas. Esto hace aun mas difícil encontrar entornos (pagados o gratuitos) donde alojar nuestras aplicaciones web a menos que nos decidamos a montar nuestro propio server.

Buscando en internet me dí cuenta que Google ofrece una alternativa sencilla y barata (gratuita hasta cierto punto) para alojar aplicaciones desarrolladas con Java: Google App Engine.

Este servicio de google te permite desarrollar aplicaciones relativamente sencillas y hostearlas dentro de los servidores que ellos mismos te ofrecen. Eso si, no puede ser cualquier tipo de aplicación y lo mejor sería desarrollar aplicaciones orientadas a esta plataforma de Google, ya que estos ya te ofrecen la alternativa para la persistencia de los datos y los frameworks visuales a utilizar.

La ventaja es que el soporte se ve bastante decente (te brindan un plugin para Eclipse que te hace la mayor parte del trabajo de configuración y el upload de tu aplicación) además que la documentación te explica el framework de una manera bastante sencilla. En la galería de aplicaciones puedes ver las aplicaciones que otros ya han publicado, notando que algunas pueden ser bastante complejas y de un acabado muy profesional.

Lo único a tener en cuenta es que nada mas puedes subir 10 aplicaciones como máximo, y no puedes borrar una aplicación que ya has subido al server de Google.

Otro tema que me llamó la atención al navegar entre las soluciones de desarrollo de google fue el GWT, Google Web Toolkit. Este es un framework visual para apps web que te permite desarrollar aplicaciones sin la necesidad de escribir HTML o Javascript, generándolo todo desde clases Java. Es un framework bastante joven comparado con JSF, Struts o Tapestry pero teniendo el respaldo de google puede llegar lejos, ademas la idea de no escribir HTML será un alivio para muchos desarrolladores web que no saben mucho de estructuración y decoración de sitios web con HTML/CSS y desean una solución rápida y sencilla para sus interfaces. Al igual que con el App Engine Framework, Google apuesta nuevamente por eclipse brindando soporte para la creación de proyectos de GWT mediante asistentes y el uso de un navegador embedido que te permite realizar pruebas de tus aplicaciones sin necesidad de hacer deploy.

"Aplicación de ejemplo de uso de GWT, creada a partir de un proyecto web de eclipse con el plugin de GWT y App Engine. En la captura pueden apreciar el browser embedido que incluye el framework de GWT."

Cabe mencionar que GWT puede ser usado nada más para generar el HTML/Javascript de un sitio, usando cualquier otro lenguaje de programación del lado del server. Como ellos bien lo mencionan, este puede ser usado para generar front-ends en aplicaciones Ruby, Python, etc. Además es full Ajax-enabled trabajando de forma transparente con invocaciones a código del lado del servidor hecho con Java y mediante el uso de XML-RPC para otros lenguajes.

miércoles, junio 10, 2009

Tu Sitio, Compatible en Todos los Browsers!

"Logotipos de los navegadores mas populares del mercado: Firefox, Internet Explorer, Safari, Opera y Chrome"


Todo diseñador-desarrollador web ha tenido que lidiar mas de alguna vez con el HTML, el CSS, el Javascript o el DOM de las páginas web, para retocar detalles de apariencia o el funcionamiento del lado del cliente. Aún bloggers con pocos conocimientos de desarrollo web se han aventurado a modificar el CSS de sus blogs para adaptar las plantillas a sus necesidades personales. Los que han pasado estas experiencias también sabrán lo molesto que es tener que comprobar que tus modificaciones se ven y funcionan igual en todos los browsers desde los cuales tus clientes-usuarios-lectores te visitan.

Porque sucede esto? Sucede porque no todos los navegadores web cumplen a cabalidad con los estándares definidos para el web. Además cada navegador quiere sobresalir implementando sus propios estándares para poder hacer más cosas que las demas. Ejemplo de ello son las propiedades CSS que inician con el prefijo -moz- o -webkit-

"Prueba del Acid3. Asi es como deberias ver esta imagen al visitar este sitio si es que tu browser cumple con los estándares aca impelemtados."

Para estar seguro que tu sitio se ve bien en cualquier navegador, sugiero estas tres alternativas:

  • Usa Frameworks que te Aseguren la Independencia del Navegador

    En la web estan disponibles una serie de frameworks para el manejo del layout del sitio usando CSS, el acceso al DOM via Javascript, controles capaces de mostrar datos de un server via Ajax, etc. los cuales prometen verse y funcionar de la misma manera en cualquier browser. Esta es mi recomendacion por defecto, ya que te ahorras tiempo y dolores de cabeza teniendo que arreglar ese div que se sale de lugar o esos mensajes Ajax que no llegan al server.

    Entre los frameworks para usar layouts prefabricados de CSS se encuentran:


    Entre los frameworks para el manejo de Javascript, controles HTML avanzados y el manejo del DOM se encuentran:

"Página de prueba de la alineación y apariencia de los elementos de un formulario, usando Blueprints"



  • Usa Herramientas para Probar tu Sitio en Multiples Navegadores/Arquitecturas

    En esta opción caes cuando prefieres hacerlo todo al estilo "do it yourself" o si en tu trabajo no te permiten usar nuevas librerías o frameworks sin la autorización de tus superiores. Puedes hacer uso de servicios en línea como Browsershots y Adobe BrowserLabs para obtener vistas previas de tus sitios web en diferentes navegadores y sistemas operativos. En un antiguo post mencioné algunas herramientas para depurar CSS y javascript en Internet Explorer y Firefox de manera que puedan mover elementos HTML, cambiar propiedades CSS, examinar variables Javascript, entre otras cosas, directamente en el navegador, por lo que se puede conocer a ciencia cierta el resultado final sin usar diseñadores visuales como Dreamweaver.


  • Crea una Versión Diferente de tu Sitio por cada Navegador/Arquitectura

    Esta opción es el último recurso que debes tomar, la opción también llamada "Por si todo lo demás falla...". Una de las diferencias más molestas entre los navegadores es que no manejan las mismas medidas para los pixels y no renderizan del mismo tamaño las fuentes o tipografías. Esto da lugar a que un div de 30px de ancho abarque más espacio en IE que en Firefox u Opera. Para ello, una técnica es utilizar un CSS cargado únicamente cuando el navegador del cliente es Internet Explorer, utilizando la etiqueta < link > dentro de una etiqueta especial propia de IE, llamada < ! --[IF IE ]-- >

    Mediante esta etiqueta podrán cargar un archivo .css preparado para Firefox u otro .css preparado para IE, decidiendo dinámicamente cual cargar según el navegador que esté usando el cliente.

    Otra buena razón para crear una página con un layout diferente es el hecho de poder adaptar tu sitio para ser visto desde dispositivos móviles como smartphones, en los cuales el tamaño y resolución de la pantalla difieren en gran medida de una PC, sin mencionar que la navegación se realiza por medio de la pantalla táctil, prescindiendo del uso de un ratón. Buen ejemplo de ello son las páginas web para móviles de Google, Twitter y Facebook.
"Versión mobil de Twitter, visualizada desde un Nokia n95"

Debido a estas diferencias entre los navegadores, existen muchos sitios que solo son capaces de funcionar o lucir bien en uno u otro navegador, de manera que cuando lo visualizas en cualquier otro el sitio es un completo desastre, como los listados en este sitio.

Conoces algun sitio importante que se solamente se vea bien en uno u otro navegador?

Tu Sitio, Compatible en Todos los Browsers!

"Logotipos de los navegadores mas populares del mercado: Firefox, Internet Explorer, Safari, Opera y Chrome"


Todo diseñador-desarrollador web ha tenido que lidiar mas de alguna vez con el HTML, el CSS, el Javascript o el DOM de las páginas web, para retocar detalles de apariencia o el funcionamiento del lado del cliente. Aún bloggers con pocos conocimientos de desarrollo web se han aventurado a modificar el CSS de sus blogs para adaptar las plantillas a sus necesidades personales. Los que han pasado estas experiencias también sabrán lo molesto que es tener que comprobar que tus modificaciones se ven y funcionan igual en todos los browsers desde los cuales tus clientes-usuarios-lectores te visitan.

Porque sucede esto? Sucede porque no todos los navegadores web cumplen a cabalidad con los estándares definidos para el web. Además cada navegador quiere sobresalir implementando sus propios estándares para poder hacer más cosas que las demas. Ejemplo de ello son las propiedades CSS que inician con el prefijo -moz- o -webkit-

"Prueba del Acid3. Asi es como deberias ver esta imagen al visitar este sitio si es que tu browser cumple con los estándares aca impelemtados."

Para estar seguro que tu sitio se ve bien en cualquier navegador, sugiero estas tres alternativas:

  • Usa Frameworks que te Aseguren la Independencia del Navegador

    En la web estan disponibles una serie de frameworks para el manejo del layout del sitio usando CSS, el acceso al DOM via Javascript, controles capaces de mostrar datos de un server via Ajax, etc. los cuales prometen verse y funcionar de la misma manera en cualquier browser. Esta es mi recomendacion por defecto, ya que te ahorras tiempo y dolores de cabeza teniendo que arreglar ese div que se sale de lugar o esos mensajes Ajax que no llegan al server.

    Entre los frameworks para usar layouts prefabricados de CSS se encuentran:


    Entre los frameworks para el manejo de Javascript, controles HTML avanzados y el manejo del DOM se encuentran:

"Página de prueba de la alineación y apariencia de los elementos de un formulario, usando Blueprints"



  • Usa Herramientas para Probar tu Sitio en Multiples Navegadores/Arquitecturas

    En esta opción caes cuando prefieres hacerlo todo al estilo "do it yourself" o si en tu trabajo no te permiten usar nuevas librerías o frameworks sin la autorización de tus superiores. Puedes hacer uso de servicios en línea como Browsershots y Adobe BrowserLabs para obtener vistas previas de tus sitios web en diferentes navegadores y sistemas operativos. En un antiguo post mencioné algunas herramientas para depurar CSS y javascript en Internet Explorer y Firefox de manera que puedan mover elementos HTML, cambiar propiedades CSS, examinar variables Javascript, entre otras cosas, directamente en el navegador, por lo que se puede conocer a ciencia cierta el resultado final sin usar diseñadores visuales como Dreamweaver.


  • Crea una Versión Diferente de tu Sitio por cada Navegador/Arquitectura

    Esta opción es el último recurso que debes tomar, la opción también llamada "Por si todo lo demás falla...". Una de las diferencias más molestas entre los navegadores es que no manejan las mismas medidas para los pixels y no renderizan del mismo tamaño las fuentes o tipografías. Esto da lugar a que un div de 30px de ancho abarque más espacio en IE que en Firefox u Opera. Para ello, una técnica es utilizar un CSS cargado únicamente cuando el navegador del cliente es Internet Explorer, utilizando la etiqueta < link > dentro de una etiqueta especial propia de IE, llamada < ! --[IF IE ]-- >

    Mediante esta etiqueta podrán cargar un archivo .css preparado para Firefox u otro .css preparado para IE, decidiendo dinámicamente cual cargar según el navegador que esté usando el cliente.

    Otra buena razón para crear una página con un layout diferente es el hecho de poder adaptar tu sitio para ser visto desde dispositivos móviles como smartphones, en los cuales el tamaño y resolución de la pantalla difieren en gran medida de una PC, sin mencionar que la navegación se realiza por medio de la pantalla táctil, prescindiendo del uso de un ratón. Buen ejemplo de ello son las páginas web para móviles de Google, Twitter y Facebook.
"Versión mobil de Twitter, visualizada desde un Nokia n95"

Debido a estas diferencias entre los navegadores, existen muchos sitios que solo son capaces de funcionar o lucir bien en uno u otro navegador, de manera que cuando lo visualizas en cualquier otro el sitio es un completo desastre, como los listados en este sitio.

Conoces algun sitio importante que se solamente se vea bien en uno u otro navegador?

viernes, marzo 27, 2009

Si no estas usando un framework...

Si no estas usando un framework para desarrollar software, probablemente estés re-inventando la rueda. La única validez que tiene el proceso de "re-inventar la rueda" es para conocer como funciona. Pero si te están pidiendo elaborar un sistema realmente amplio para una empresa, con una cobertura del 70% de las operaciones, y esa empresa NO se dedica a realizar software... entonces es una seria estupidez desarrollar software sin un framework.

"Cuidad, si re-inventas la rueda, podrías terminar así..."

Un framework, es una estructura de soporte definida mediante la cual, se desarrolla y organiza lógicamente una pieza de software. Entonces, el programa, modulo o sistema en cuestión, se apoya en un framework (en el marco de trabajo) para ser desarrollado. Un framework incluirá soporte para generar programas, una serie de librerías organizadas en módulos lógicos, y un lenguaje (que se ejecuta en una maquina virtual usualmente) para ayudar a desarrollar y unificar los módulos que conformen el proyecto.
El uso de un framework, es tan obligatorio en un proyecto de grandes magnitudes, como lo son las típicas practicas de desarrollo de software:
Para los estudiantes, o novatos en el tema, permitanme dar un sencillo ejemplo:
Imaginemos por un breve momento, que se quiere construir (de acuerdo a un plano) una casa de dos plantas, para tres personas, con cochera y jardín.
Este es el problema:
construir la casa de acuerdo a las especificaciones (del plano), construirla en un tiempo planificado y con la mayor eficiencia posible.
Bien, hay un par de caminos que podemos tomar, el primero consiste en:
1. Comprar ladrillos, cemento, arena, pintura, tejas, piso cerámico, defensas, hierro, contratar mano de obra calificada, comenzar la construcción....

"Niiiiceee...."

Al menos, eso es lo lógico, ¿no? Son los pasos "normales", lo "sano".
La misma lógica es aplicable al mundo del software.... sin embargo, existen personas que rechazan esta "linea de pensamiento" y cometen errores que en el contexto del ejemplo anterior, seria:

2. Construir la casa, desde CERO (literalmente), de manera que vamos a inventar nuestro propio cemento, pintura, techo, defensas, pisos. Vamos a usar herramientas que no estamos seguros si las vamos a aprovechar y vamos a gastar en cosas completamente innecesarias... como... flamingos rosados de mármol tallados a mano importados de la India para el jardín (wtf?).

"NOT so nice. NOT AT ALL."

Y para colmo, creen que se puede realizar la casa, en el mismo tiempo que lo haría de la manera "normal". Se que para muchos lectores, esto suena ridículo, ¡¿verdad?! suena muy ridículo. Es más, seria increíble pensar, que alguien proponga soluciones así.... pero les tengo una noticia...
Este es el caso que sucede SUCEDE en las empresas, y también SUCEDE en los equipos de desarrollo.
Casi a diario, se esta perpetrando este crimen. No solo es una perdida de tiempo, sino que también es un insulto al desarrollador de software que si tiene buenas practicas (o que intenta tenerlas). ¿Saben que es lo peor? muchos cometen el error de creer que con solo usar Java o .NET (y solamente eso), ya están usando un framework suficiente para hacer un RIA (Rich Internet Application) en 3 meses. Pues déjenme decirle, que si ese fuera el caso, no existiría Spring, Struts, IceFaces, MyFaces, ASP.NET MVC, Adobe Flex, RoR, Etc...
Lo terrible es que este suceso se sigue perpetrando, y es por simple ignorancia...

"¡Que pena ser ignorante!"

Empresas, por que rayos ¿no capacitan a sus gerentes de informática?, ¿a sus arquitectos de software?, ¿a sus team leaders?, ¿Por que no escuchan las voces de los programadores, que de cara a semejantes atrocidades, alzan la voz inmediatamente y proponen el cambio?
Ya lo dije antes, pero no me molesta volverlo a repetir...
"si un equipo de desarrollo, sumergido hasta el cuello de dificultades técnicas, pretende producir software: simplemente vamos a obtener software que es REFLEJO de las dificultades, problemas, ignorancia, malos requerimientos y mala administración en los que se vio envuelto el mismo".
Instruyace, no deje de leer, no se estanque, procure estar a la par (o solo un centímetro atrás) de la tecnología, y procure, sobre todas las cosas, escuchar a sus colegas, pero a los que saben.

Pero sobre todas las cosas, por favor, si no estas usando un framework.... ya es hora de que comience a usar uno.

¿Y tu, qué frameworks usas?

Si no estas usando un framework...

Si no estas usando un framework para desarrollar software, probablemente estés re-inventando la rueda. La única validez que tiene el proceso de "re-inventar la rueda" es para conocer como funciona. Pero si te están pidiendo elaborar un sistema realmente amplio para una empresa, con una cobertura del 70% de las operaciones, y esa empresa NO se dedica a realizar software... entonces es una seria estupidez desarrollar software sin un framework.

"Cuidad, si re-inventas la rueda, podrías terminar así..."

Un framework, es una estructura de soporte definida mediante la cual, se desarrolla y organiza lógicamente una pieza de software. Entonces, el programa, modulo o sistema en cuestión, se apoya en un framework (en el marco de trabajo) para ser desarrollado. Un framework incluirá soporte para generar programas, una serie de librerías organizadas en módulos lógicos, y un lenguaje (que se ejecuta en una maquina virtual usualmente) para ayudar a desarrollar y unificar los módulos que conformen el proyecto.
El uso de un framework, es tan obligatorio en un proyecto de grandes magnitudes, como lo son las típicas practicas de desarrollo de software:
Para los estudiantes, o novatos en el tema, permitanme dar un sencillo ejemplo:
Imaginemos por un breve momento, que se quiere construir (de acuerdo a un plano) una casa de dos plantas, para tres personas, con cochera y jardín.
Este es el problema:
construir la casa de acuerdo a las especificaciones (del plano), construirla en un tiempo planificado y con la mayor eficiencia posible.
Bien, hay un par de caminos que podemos tomar, el primero consiste en:
1. Comprar ladrillos, cemento, arena, pintura, tejas, piso cerámico, defensas, hierro, contratar mano de obra calificada, comenzar la construcción....

"Niiiiceee...."

Al menos, eso es lo lógico, ¿no? Son los pasos "normales", lo "sano".
La misma lógica es aplicable al mundo del software.... sin embargo, existen personas que rechazan esta "linea de pensamiento" y cometen errores que en el contexto del ejemplo anterior, seria:

2. Construir la casa, desde CERO (literalmente), de manera que vamos a inventar nuestro propio cemento, pintura, techo, defensas, pisos. Vamos a usar herramientas que no estamos seguros si las vamos a aprovechar y vamos a gastar en cosas completamente innecesarias... como... flamingos rosados de mármol tallados a mano importados de la India para el jardín (wtf?).

"NOT so nice. NOT AT ALL."

Y para colmo, creen que se puede realizar la casa, en el mismo tiempo que lo haría de la manera "normal". Se que para muchos lectores, esto suena ridículo, ¡¿verdad?! suena muy ridículo. Es más, seria increíble pensar, que alguien proponga soluciones así.... pero les tengo una noticia...
Este es el caso que sucede SUCEDE en las empresas, y también SUCEDE en los equipos de desarrollo.
Casi a diario, se esta perpetrando este crimen. No solo es una perdida de tiempo, sino que también es un insulto al desarrollador de software que si tiene buenas practicas (o que intenta tenerlas). ¿Saben que es lo peor? muchos cometen el error de creer que con solo usar Java o .NET (y solamente eso), ya están usando un framework suficiente para hacer un RIA (Rich Internet Application) en 3 meses. Pues déjenme decirle, que si ese fuera el caso, no existiría Spring, Struts, IceFaces, MyFaces, ASP.NET MVC, Adobe Flex, RoR, Etc...
Lo terrible es que este suceso se sigue perpetrando, y es por simple ignorancia...

"¡Que pena ser ignorante!"

Empresas, por que rayos ¿no capacitan a sus gerentes de informática?, ¿a sus arquitectos de software?, ¿a sus team leaders?, ¿Por que no escuchan las voces de los programadores, que de cara a semejantes atrocidades, alzan la voz inmediatamente y proponen el cambio?
Ya lo dije antes, pero no me molesta volverlo a repetir...
"si un equipo de desarrollo, sumergido hasta el cuello de dificultades técnicas, pretende producir software: simplemente vamos a obtener software que es REFLEJO de las dificultades, problemas, ignorancia, malos requerimientos y mala administración en los que se vio envuelto el mismo".
Instruyace, no deje de leer, no se estanque, procure estar a la par (o solo un centímetro atrás) de la tecnología, y procure, sobre todas las cosas, escuchar a sus colegas, pero a los que saben.

Pero sobre todas las cosas, por favor, si no estas usando un framework.... ya es hora de que comience a usar uno.

¿Y tu, qué frameworks usas?

Sunsetting Sr. Byte.

El Sr. Byte ha estado más de 5 años inactivo. Digamos que estaba en " code freeze ". Pero ahora es el último release. Quizas no...