JAVA DISTRIBUIDO VS JAVA WEB
Hace muchos años, cuando comence de adolescene a meterme en todo esto de la programación, un profesor de matematica computacional me dijo que todo se resumia a 2 conceptos: prendido y apagado y a 10 palabras reservadas en el lenguaje ensamblador para poder desarrollar cualquier aplicación. Me hacia la comparación de los número ordinarios que desde el 0 al 9, podríamos definir infinitas convinaciones y complejos de formulas matematicas.
A que vengo con todo esto?. Acordarme de cuantas palabras reservadas tiene JAVA es un tema. Saber cuantas clases de terceros y de JAVA hay para desarrollar una aplicación es otro tema; pero acordarme de todos los benditos tags desde el html, pasando por muchos framework y hasta llegar a jsf es otro, muy diferente tema. Y si a esto le sumamos la dificultad de depurar las aplicaciones, definitivamente un desarrollador se pasa mas tiempo pensando donde encajar una pieza de un rompecabeza inmensamente grande en un complejo de invensiones raras que ofrecen los proveedores para desarrollar aplicaciones empresariales en internet. Como que te pasas 2 hora para hacer una pantalla y 5 minutos para las reglas del negocio.
La pregunta del millón es que debe estar equilibrado o medianamente nivalado los tiempos para que un esquema de desarrollo sea viable y rápido.
Me resisto a desarrollar un template que lo voy a usar 10 veces y no más. Me resisto a perder 30 minutos para centrar un etiqueta. Me resisto a que me digan como tengo que ordenar mi página o mi pantalla de desarrollo. Si quiero que no tenga cabecera, que no la tenga. Si quiero que tenga un solo costado, que lo tenga.
Veamos los layouts de JAVA, te permite hacer lo que quieras, ordenarlos como quieras pero al mismo tiempo te da la opción que todos los componentes esten centrados y que sean fáciles de migrar a otras dimensiones de contenedores, sin que ello implique volver a colocar los componentes en nuevos lugares. Esta verdaderamente padre.
Ahora. imaginemos algo. Imaginemos una aplicación que toma un desarrollo en JAVA DESKTOP y migra automaticamente a páginas JSF o lo que es lo mismo a XHTML. Y hablamos de desarrollos empresariales, así que incluimos en esto los accesos a la base de datos y las capas intermedias de HIBERNATE. La pregunta inmediata que se nos viene es: PUEDE FISICAMENTE UNA PAGINA WEB RESOLVER TODA LA ERGONOMIA DE UNA PANTALLA DESKTOP?. Y si en realidad pudiera. QUIEN QUERRIA DESARROLLAR EN WEB CUANDO ES MAS FACIL EN DESKTOP Y DESPUES MIGRAR A WEB?.
Y frente a todo esto, nos olvidamos de los cambios unilaterales que hacen los proveedores para que volvamos a gastar dinero en actualizar a las nuevas versiones. Lo digo por experiencia. Yo llevo dos proyectos muy grandes. Uno en WEB con JSP y JSF versión anterior y otro en JAVA DISTRIBUIDO DESKTOP CUMPLIENDO EL CONCEPTO DE GRID-COMPUTER. El primero ha tenido en 5 años 3 actualizaciones tecnolgicas, más esta nueva de JSF 2.0 que se esta desarrollando. En el segundo caso, en 7 años, nunca fue necesario de cambiar de tecnologia, sino simplemente agregar nueva tecnología. En el caso de las opciones que nos daba el JAVA 1 al 2 y de la version 5 hasta la 7. Pero nunca fue necesario volver a programar una sola linea de codigo. Cuanto ha costado el primer proyecto, muchos dinero. Cuanto el segundo, ni un sólo centavo.
Un caso más avanzado de como manipulan la integridad de JAVA de SUN y los intereses de los proveedores de tecnologia, son las aplicaciones moviles. Pregunto: donde hay una aplicación JAVA 100% natural, que corra en un dispositivo movil. Desde las versiones open source de JAVA, pasando por ANDROID y hasta llegar a las aplicaciones de IPHONE, todas son JAVA pero modificadas para cada uno de los proveedores. Cuestión que nada es compatible, excepto que vayamos a desarrollos WEB. No les parece esto algo muy pero muy oscuro?.
La pregunta que le hago a la comunidad de desarrolladores de JAVA de MEXICO es: Porque no desarrollar un EXPLORADOR de CODIGO DESKTOP con capacidad de procesamiento distribuidor GRID-COMPUTER que puedan corrar nuestras aplicciones en forma natural en todo dispositivo tecnologico conocido?. Sería lo mismo pero con la gran ventaja que la programación web sólo quedaria para la salida de la información.
Quiero dejar algo aclarado, no soy un enemigo de las aplicaciones WEB. Creo que la WEB nació para exponer, desplegar y buscar información, pero no para generar transacciones y de alli la complejidad de la persistencia de datos, de la seguridad y de los benditos conceptos de petición, aplicación, vista y sesiones.
Les dejo esto para pensar y estoy abierto a sus comentarios.
- amohr's blog
- Inicie sesión o regístrese para enviar comentarios
Por que de esa forma no se
Por que de esa forma no se podría aprovechar al máximo lo que cada plataforma ofrece. Como se vería un sitio ... no sé como facebook si pareciera una alpicación de escritorio? O como se vería mmhh no sé Office ( estoy diciendo cualquier cosa eh ) si se viera como una aplicación web.
Dadas las circustancias actuales me parece que es más probable que pase exactamente al contrario, que las aplicaciones web se inserten dentro de aplicaciones de escritorio ( vía un componente com WebKit para mostar el HTML ) a que pase lo opuesto. Pero esto es solo una tendencia. Eventualmente podría pasar lo contrario.
Lo importante a recordar es que no importa lo fácil o dificil que sea desarrollar la aplicación, pues en el desarrollo de software eso no es relevante ( al menos no es lo principal ) lo importante es el usuario que la va a usar.
De no ser así aún seguiríamos usando aplciaciones de linea de comandos ( o peor aún algo como Windows 95 ) ... o seguiríamos en la Web1.0. Estos esfuerzos que los productos hacen por sorprender a sus usuarios y/o para hacerles más fácil la vida, son los que generan la evolución en el desarrollo de software.
el usuario siempre tiene la razon...
cada tipo de aplicacion tiene sus limitaciones y sus potencialidades pero depende del entorno en el que se despliega, ese lo dice todo, es decir para que fue hecho en que ambiente se usará. Ademas tiene que ver con la experiencia de los developers, aunque muchos digan que no tienden a aferrarse a la tecnologia que conocen.
si quisieras utilizar multiagentes con jade
tendría que ser un ambiente distribuido y aparte estaría mejor funcionado x App .. no vi lo que pusieron pero se me hizo bueno comentar
ni un sólo centavo?
Uno de esos dos desarrollos que mencionas no costó un solo centavo? Wow. O sea que todos los programadores involucrados donaron su tiempo, lo hicieron en ratos libres, etc y si hubo alguien dirigiendo el proyecto lo hizo también nomás así de buena onda, nadie recibió un centavo por trabajar en ese proyecto.
Y las aplicaciones para iPhone no son Java. Puedes hacerlas directamente en ObjC o usar algun otro framework como AIR y cosas así, pero que yo sepa no existe una sola manera de que se pueda ejecutar código Java en un iPhone.
No entendí qué tiene que ver grid computing con que una aplicación pueda correr en "todo dispositivo tecnologico conocido". Tal vez lo que intentas describir es algo similar a Chromium o como se llame el sistema de las chromebooks?
LA SOBERBIA ES EL PECADO DE LOS IGNORANTES
Mi querido ezamudio.... cómo dice un viejo refrán el tiempo y los hijos dirán si tenías razón. Este mensaje lo haz hecho hace 6 años. Nosotros ya en ese tiempo trabajábamos en investigación y desarrollo en aplicaciones distribuidas y modulares en Multi plataforma, incluso en iOS. Pasó el tiempo y hoy resulta que una herramienta como Gluon ha podido correr y podemos correr aplicaciones java en dispositivos apple. En vez de haber perdido nuestro tiempo con personas como tú, decidimos aplicarlo en hacer nuestra empresa. Ojalá y Dios quiera que tú también hayas aprovechado el tiempo, haya sido un poco menos negativo y pesimista y hayas creado tu propia empresa o, de perdido, una proyecto a tu futuro. Y sí muchos trabajamos "gratis" como dices para cosechas los frutos después. Respecto a tus opiniones, como por ejemplo el Pool de Base de datos, discúlpame decirte que no es correcto. Aún incluso teniendo las librerías para un Pool, nosotros usamos de Oracle, debes hacer varias cosas para optimizar y controlar los hilos, procesos, transacciones, etc. No es sólo conectarte a la base de datos, incluso con Hibernate y cuantas cosas crees que "ya están hechas" hay más árboles detrás del bosque. Mi querido amigo, si me dejas darte una sugerencia, intenta trabajar tu humildad. Nosotros estamos abierto a mostrarte que mientras estos 6 años estuviste trabajando para otros, nosotros trabajamos para nosotros y hoy contamos con más de 2000 clientes que nos provee los ingresos necesarios para mantener a nuestra familia. gracias.
.
Mal entendido
Creo que se malentendio el comentario del buen ezamudio.
Sobre lo del coste, creo que intento decir que ningun desarrollo es realmente "gratis", por que hay que invertir tiempo, esfuerzo, recursos, etc;
Y al contrario, noto en tu post cierto desprecio por personas que trabajan para otros (empresas) y presumes que tu ya tienes una por haber trabajado para ti en lugar de trabajar para otros. Al final uno siempre trabaja para otros (clientes) y al menos yo no decidi dedicarme a esto por el dinero (eso es una consecuencia de), lo hago por que me gusta, me apasiona, resolver problemas, buscar soluciones.
La respuesta es contradictoria
Con respecto a lo que comentó Enrique de que nadie trabaja gratis; pues lo compruebas tu diciendo que ya tienes ingresos; es decir fue un proyecto a largo plazo.
Después de que comentas que a Enrique le falta humildad presumes de que tienes empresas y no se cuanto más.
Del mismo modo no puedes decir "nosotros trabajamos para nosotros y hoy contamos con más de 2000 clientes ..." ya que usted mismo dice que tienen clientes y ya con esto se entiende que trabaja para ellos; para cubrir sus demandas y necesidades; de echo todos trabajamos para cubrir las necesidades de nuestro usuario fina(cliente).
Interesante
Es muy interesante leer posts de hace años, y los comentarios que hicimos en el momento.
La verdad no quiero dedicarme ahorita a hacer arqueología de software y ver cuándo empezaron a salir cosas como rubyMotion, Cordova, Gluon, Electron, Xamarin, etc etc etc. En particular he visto apps hechas con Gluon y funcionan muy bien. En el JavaOne de 2016 la app oficial de Oracle era nativa de Android mientras que otra empresa sacó una con Gluon y esta última funcionaba mucho mejor que la nativa.
En cuanto al tono de tu último comentario, sobre todo en lo que comentas personalmente hacia mí, wow... Hasta mencionas algo de pools de conexiones a base de datos, cosa que no veo que se haya discutido por ningún lado en este post, lo que me hace suponer que hablas de otros posts o comentarios que he escrito en el sitio. Me halaga que lean lo que he publicado aquí, pero no encuentro la relación, y si me vas a decir que está mal, pues sería bueno que lo demuestres, porque llevo ya muchos años haciendo todo mal según tú, y pues la verdad sí me interesa corregir esos errores y no volver a cometerlos.
Dices que estuve trabajando 6 años para ustedes; te paso mi CLABE para que me pagues lo que me debes de todo ese trabajo? Ah pero me vas a decir que trabajé gratis para ti. Me gustaría saber cómo fue eso.
Por último, me encantaría que tú o alguien de las personas con las que hiciste este proyecto que mencionas, se animara a dar una plática al respecto en el meetup de la comunidad JVMMX. Si realmente lograron llevar grid computing a dispositivos móviles, sería realmente muy interesante escuchar cómo lo hicieron.
Tenemos un repositorio en github en donde pueden registrar su propuesta, para que los programemos en un próximo meetup. Nos reunimos el último lunes de cada mes. Espero ver su propuesta, de verdad.
GWT!
Cómo pude olvidarme de GWT y Vaadin! Bueno es que me enfoqué más a mencionar cosas para desarrollo multiplataforma móvil, pero ahorita leyendo el post original, supongo que GWT y Vaadin tampoco habían salido en 2012, o al menos yo no las conocía.
Lo cierto es que para web hoy todo es JS. Y a pesar de que no me gusta ni tantito JS, creo que es mejor esa separación que hacemos ahora y que ya no estamos generando HTML desde el backend sino que solamente se manejen datos. La ventaja obvia de eso es que se reutiliza mucha de esa funcionalidad para las apps móviles.
Con el nombre oficial de Vaadin, en 2009.
Si mi memoria no me falla, Vaadin inició con otro nombre al rededor de 2002-2006, pero oficialmente con el nombre de Vaadin fue lanzado en el 2009.