Así como en el post anterior estuvimos hablando de qué tecnología web debemos elegir a la hora de comenzar un proyecto, hoy vamos a hacer algo similar pero a la hora de elegir una arquitectura.
Vamos a poner varias restricciones al proyecto para hacerlo algo más real y voy a intentaros contar lo que a mi parecer sería la mejor solución al problema.
Pongamos que tenemos una aplicación de escritorio la cual queremos migrar a las íºltimas tecnologías del momento. Nuestra aplicación se nos ha quedado algo antigua y ya no queremos invertir más pasta en su mantenimiento, así que hemos decidido ponernos manos a la obra y buscar una solución arquitectónica adecuada a la información con la que contamos actualmente.
Nuestra aplicación de escritorio sigue al pie de la letra una arquitectura cliente-servidor, donde tenemos una base de datos central, ubicada en un servidor remoto a la cual conectamos para realizar transacciones centralizadas. Además, tenemos la posibilidad de en un momento dado, por una caida del servicio central, trabajar con varios módulos de la aplicación de forma local (almacenamos la información que gestionamos en una base de datos local y al recuperarse la conexión podremos volcar nuestros cambios a la base de datos central). Además, nuestra aplicación contiene toda la lógica de negocio, por lo que ante cualquier necesidad de actualización del mismo, debemos compilar nuevamente y distribuirla a todos nuestros clientes.
Incorporo un pequeño esquema para que os hagáis un poco más a la idea de todo.
Bien, pues entonces, entre las primeras posibilidades que tenemos para renovar la aplicación es mantener la misma arquitectura, coger su código que estaba programado en Pepito.CHUF versión 2.0 y reprogramar todo internamente mediante la versión 7.0 de Pepito.CHUF. Seguramente nos vamos a dar bastante prisa. Formulario a formulario, despacito y con buena letra al final podemos obtener algo muy similar. Y si encima de paso lavamos la cara un poco a la presentación, pues oye, el cliente más contento que chuflainas porque le da la sensación que tiene una aplicación íºltimo modelo de la tecnología.
El artículo parece que se va a quedar aquí, pero vamos a darle un poco de emoción a la cosa y vamos a pensar que nos llegan ecos de que parte de la aplicación debería ser accesible a través de web. Menudo problema ya que si necesitamos trabajar puntualmente de forma desconectada… vamos a necesitar obligatoriamente tener parte web y parte escritorio. De todas maneras todo esto son rumores, y como nosotros tenemos bastante prisa para desarrollar todo esto, tal vez lo mejor que podamos hacer es tirar todo para escritorio, pero, cubriéndonos un poco las espaldas con la arquitectura, preparándola para hacerse algo mayor si más adelante se requiriera. Además, de paso, vamos a dar otro gran salto de arquitectura, sacando todo el modelo de negocio de la propia aplicación fuera de ella.
A continuación otra foto para que os hagáis un poco más a la idea.
Como véis entre la base de datos y la aplicación cliente hemos colocado un servidor de aplicaciones con servicios web.
¿Ventajas? Pues unas cuantas, ante cualquier cambio de modelo de negocio no vamos a necesitar actualizar las aplicaciones cliente, haremos el cambio en el servicio web y listo. Pero la ventaja más gorda es que estamos preparados para crecer en cualquier momento y hacer accesible nuestro modelo de negocio a cualquier tipo de dispositivo y/o tecnología.
Por ejemplo, si mañana, o pasado queremos implantar alguno de los módulos de la aplicación a través de web (por ejemplo el módulo de administración), seguramente tendremos ya tres cuartos del trabajo hecho, y íºnicamente deberemos crear una nueva capa de presentación, pero esta vez web.
íšltima foto, esta vez la definitiva.
Como véis, añadiendo una aplicación web en otro servidor web ya disponemos de una capa de presentación web, la cual conecta con el mismo servidor de servicios web con el que sigue trabajando la aplicación de escritorio. Qué bien, nos hemos evitado tener que duplicar el modelo de negocio para trasladarlo a la web. Y además, por cierto, como podéis ver, la cosa ha evolucionado hasta el punto que alguno de los operadores de la aplicación es capaz también de acceder a la misma a través de un dispositivo móvil. ¿Cuál ha sido el esfuerzo de desarrollo para esto íºltimo? Pues crear la capa de presentación del dispositivo móvil, punto y final.
¿Os hacéis a la idea del esfuerzo que requiriría disponer de acceso independientemente del dispositivo si hubiéramos mantenido la misma arquitectura de la aplicación inicial? Y por cierto, por ahora íºnicamente hemos hablado de arquitectura y no de plataforma… mediante esta solución nuestra aplicación web podría estar hecha en JSP+STRUTS, mis servicios web en PHP, mi aplicación de escritorio en .NET y nuestra base de datos… pues la que más os guste. ¿Lo veis posible mediante la primera arquitectura?
Como véis, la idea feliz de todo esto ha sido que en un momento que existía cierta incertidumbre hemos invertido algo más en arquitectura, y esto nos ha permitido que la aplicación sepa hacerse mayor con un esfuerzo muy inferior.
Saludos.
Miguel.
Category: Web
Eligiendo tecnología web
Una conversación en la noche de ayer con un amigo ha inspirado este post, ¿cuál es la tecnología web más adecuada para mi proyecto?
Uf, ¡qué difícil pregunta! Como siempre una respuesta genérica a esta pregunta es, PUES DEPENDE. Y es que la verdad es cierto, va a depender de muchos factores. No pretendo sacar ningíºn tipo de conclusión al respecto después de haber terminado este post, pero sí almenos aproximar un poco los factores que bajo mi punto de vista afectan a nuestra decisión.
Antes de nada empezar diciendo que no existe una tecnología absolutamente mejor que las otras, habrá una tecnología que para los factores que rodean tu proyecto será mejor que las otras en un momento dado. Y digo en un momento dado porque ese es el primer problema a la hora de elegir, que contamos con las circunstancias y las previsiones del momento. Las previsiones y las planificaciones, pueden fallar, quedarse cortas o pasarse de largo… y si esto puede ser crítico a la hora de definir un requerimiento funcional imagínate al decidir la plataforma tecnológica sobre la que tu aplicación se va a asentar.
Pero bueno, vayamos al grano y pasemos a hablar un poco de los factores que pueden influenciarnos. Empiezo con los más típicos para luego ir dándole vueltas a otros algo más rebuscados.
Multi-Plataforma
Si tu proyecto tiene entre sus restricciones que sea publicable a través varias plataformas del mercado estás de suerte, almenos a la hora de tachar algunas de las opciones que estés barajando. De todas maneras, un humilde consejo en este aspecto es recapacitar realmente si es realmente necesario que sea multi-plataforma, porque muchos veces lo ponemos de restricción cuando luego al final trabajamos con una y listo. El concepto de multi-plataforma vende mucho, es un cartel muy bueno de marketing, ¿pero realmente lo necesitas?
Sin Coste Económico o de Coste Bajo
¿Puedes pagar licencias? ¿Quieres pagar licencias? Tal vez tengas presupuesto para ello, o tal vez no.
Alta Productividad
Cuidadín con este aspecto, existen plataformas tecnológicas que están directamente orientadas a la productividad, si este es uno de nuestro requerimientos principales, adelante con ellas.
Tamaño del Proyecto
No es lo mismo un proyecto de dos meses que uno de seis que uno de un año. Y aquí no juega sólo lo que tienes pensado hacer ahora, si no la previsión de crecimiento que crees que vas a tener. No es lo mismo estar convencido que vas a desarrollar un componente web que saber que si la cosa va bien vas a tener que empezar a agregar más módulos a la aplicación.
Formación de tus Recursos
Tal vez en tu equipo de trabajo cuentes con personas que tengan experiencia en una plataforma en concreto. Y aprovecho aquí para hacer un inciso: el llevar a cabo una formación de dos, tres semanas en una determinada tecnología para luego acometer un proyecto nada más salir no suele traer buenos resultados (retrasos sobre todo) si no acompañas el grupo de trabajo de algíºn recurso que ya tenga experiencia contrastada en ella.
IDE
.NET tiene Visual Studio, Java tiene Eclipse/NetBeans/Java Studio Creator, PHP tiene Zend Studio, Ruby on Rails tiene Aptana…
Seguridad
¿Te preocupa especialmente la seguridad? ¿La información que provee o captura tu web debe tratarse de forma especialmente segura?
Servicios Web, Ajax…
Existe plataformas que aportan más facilidades que otras para crear Servicios Web o trabajar con Ajax. Y vuelvo a aprovechar la ocasión para hacer otro inciso, cuidadín con el uso de Ajax, si queréis que vuestra aplicación web funcione como una aplicación de escritorio, no construyáis una aplicación web, construid una de escritorio. Ajax es una herramienta que nos puede ayudar puntualmente para resolver ciertos problemas, pero no se debe abusar, o se volverá contra vosotros.
Integración con el Sistema Gestor de Bases de Datos
Me explico, .NET está especialmente diseñado preparado para trabajar contra SQL Server, Java contra Oracle, PHP contra MySQL… Combinaciones del tipo .NET + Oracle o PHP + SQL Server pueden traeros problemas.
Comunidad, Soporte
Algunas plataformas tienen una empresa detrás que te puede dar soporte ante los problemas que puedan surgir, o una comunidad de usuarios más o menos amplia que te ayude a resolver las dudas.
…
Y aquí me paro, creo que por ahora ya quedan presentes algunos de los factores para echarles un ojo y darles alguna vuelta… pero antes de terminar quisiera comentar cuatro cosas sueltas más a la hora de encarar el desarrollo de una aplicación web.
1) Existen tecnologías satélite a las diversas plataformas del mercado y que son comunes a todas ellas. Estas tecnologías conviene conocerlas, saber cual es su función, para qué las podemos usar y para qué no. Me estoy refiriendo a Javascript, CSS, HTML, XHTML, XML, XSL, JQuery, JSON, AJAX, SOAP, WSDL… No me refiero a empollármelas todas, pero sí saber para qué son cada una de ellas y dónde les puedo sacar partido.
2) Desarrollar una aplicación de escritorio no es lo mismo que desarrollar una aplicación web. La gente que trabaja en web tiene muy fácil pasar a trabajar con aplicaciones de escritorio, cuando la historia es alrevés la penalización es más grande (pero no imposible claro está, estoy hablando de que se necesita algo más de tiempo para ubicarse).
3) Intentad definir un íºnico navegador y una versión del mismo para vuestro proyecto, o seguramente os volváis locos. Si trabajáis con una intranet o algo más cerrado os será viable definirlo así, si tenéis como requisito que vuestra web funcione con varios navegadores del mercado, almenos intentad marcar la versión de cada uno. No es lo mismo desarrollar para un Internet Explorer 6 que para un 7.
Fuf, cada vez me enrollo más en los post, voy a tener que empezar a recortar 🙂
Saludos.
Miguel.
Buenas Prácticas: Encapsular Construcciones Complejas
Supongo que estaréis acostumbrados a ver cosas como estas (código C#)
Response.Redirect(“~/home/pepito.aspx?idarticulo=” + idarticulo.toString() + “&idusuario=” + idusuario.toString() + “&idcategoria=” + idcategoria.toString() + “&activo=” + activo);
En el caso del ejemplo tenemos la instrucción response.redirect, la cual muchos de vosotros conoceréis, y que se encarga de redireccionar a nuestro navegador a la url que se le pasa por parámetro. Muchas veces vamos a necesitar pasar valores en la URL para que sean recogidas en la página de destino, y “no nos queda más remedio” que hacerlo de esta manera.
La verdad es que para redirecciones con urls sencillas aíºn es tratable, pero como tengamos que empezar a concatenar parámetros y más parámetros, te puedes volver loco. Por ello, una buena práctica resulta el encapsular todos estos oomportamientos para ayudar en la lectura del código y el posterior mantenimiento de la aplicación.
Os dejo aquí el comportamiento de hipotética clase que encapsula esta buena práctica, a ver si qué os parece (código C#)
Redireccion miURL = new Redireccion(“~/home/pepito.aspx”);
miURL.AddParameter(“idarticulo”, idarticulo);
miURL.AddParameter(“idusuario”, idusuario);
miURL.AddParameter(“idcategoria”, idcategoria);
miURL.AddParameter(“activo”, activo);
miURL.Ir();
¿Cómo lo leéis mejor? ¿Os hacéis una idea de lo que hace por dentro la clase, no?
AddParameter es un método sobrecargado donde el primer parámetro es el nombre y el segundo el valor. Podemos pasarle como valor diferentes tipos de datos, ya que está sobrecargado con el tratamiento para cada uno de ellos.
El constructor acepta un parámetro de entrada que es la base de la url a la que vamos a llamar, aunque podríamos instanciar la clase sin pasarle ningíºn parámetro, y luego usar la propiedad miURL.URLBase para definirla.
Por supuesto, y siguiendo las buenas prácticas, la clase Redirección debería encapsular también sus excepciones propias que lanzaría en los casos necesarios y que podrían capturarse desde fuera. Por ejemplo, ¿y si instanciamos la clase sin pasarle la URL base y tampoco la añadimos usando la propiedad? Al lanzar el método Ir() debería saltar una “NoHayURLBaseDefinidaException”, ¿no creéis?
Otro consejo para rematar, sería sobreescribir el método toString() de la clase, para que devolviera la URL generada hasta el momento, y así poder hacer cosas del tipo:
MostrarMensaje(“Esta es la URL Generada: “+ miURL);
Esta forma de encapsular las construcciones complejas es aplicable a otros campos, como por ejemplo para generar una secuencia SQL. Otro día os dejo un ejemplo.
Saludos.
Miguel.
DevJoker
Recomendado 🙂
https://www.devjoker.com
Saludos.
Miguel.
Desarrollador 5 Estrellas
No sé si conocéis el sistema de Formación/Certificación de Microsoft para Visual Studio 2005, llamado “Desarrollador 5 Estrellas”.
Se trata de una serie de cursos y exámenes que van desde un nivel de dificultad menor (1 estrella) hasta la máxima (5 estrellas). Por cada una de las estrellas existe un temario, con su correspondiente documentación, y unos exámenes tipo test. A medida que te vas viendo preparado tras leer la documentación puedes ir haciendo los test. Por cada test aprobado se abre la posibilidad de hacer los test de las estrellas superiores.
La verdad es que está muy muy bien, ya no sólo por “jugar” un poco y entretenerte si no que sirve bastante para aprender y probarte un poco. Si además añadimos que la documentación que ofrece por cada parte del temario está bastante bien, pues la suma de todo es que como poco váis a salir aprendiendo un montón.
Os dejo la URL
https://www.mslatam.com/latam/msdn/comunidad/dce2005/directory.aspx
Saludos.
Miguel.
El Ajax sin control… no sirve de nada
Y como ejemplo de una web donde a mi parecer se está usando Ajax de una forma muy coherente y correcta, tenemos la de AirEuropa https://www.aireuropa.com
No sé si estáis acostumbrados a comprar billetes de avión on-line, en mi caso es así (es lo que tiene haber nacido en una isla), y después de haber probado unas cuantas “engine” de reservas de billetes la que más me ha gustado con diferencia es la de AirEuropa. Tienes sus fallos, lo sé, hasta hace poco cascaba el diseño si entrabas con un Internet Explorer 7, y tiene unos pequeños problemas de usabilidad en el buscador inicial (si te olvidas de marcar que el viaje es íºnicamente de ida, una vez has seleccionado la fecha, te borra todo y tienes que volver a empezar).
Pero, la verdad, que la forma en que usan Ajax en la tramitación inicial de la reserva (lo que tiene que ver con la selección de origen-destino-fecha-billete), me parece realmente llamativa. Sobre la misma página no hay más que seguir tres pasos
1) Seleccionas billete ida o vuelta
2) Seleccionea Origen y Destino
3) Seleccionas Día
4) Seleccionas entre los vuelos disponibles ese día
La pregunta es ahora, ¿y qué tiene de diferente este flujo con el de resto de buscadores? En cuanto al flujo nada, pero la solución técnica con la que la han llevado a cabo me gusta mucho.
Aunque lo mejor será que lo probéis vosotros mismos, os cuento yo aquí mis sensaciones:
1) Selección de origen, te carga los destinos disponibles (Ajax, no hay recarga de página)
2) Selección de destino, en la parte inferior un calendario muy vistoso y claro se situa en el mes actual, los días que hay vuelo te marca en el día el precio más barato (Ajax, no recarga la página)
3) Selección del día, en la parte inferior aparece un listado con todos los vuelos de ese día, ordenado por horas, marcando el precio del billete de cada uno (Ajax, no recarga la página)
4) Una vez seleccionado el día, en la parte derecha marca el precio total, indicando el precio si eres residente balear (mi caso).
5) Aceptas y ya empezamos con la petición de datos personales, pago y blablabla…
Me parece realmente cómodo y bien diseñado, los pasos son los justos, la verdad es que invita a comprar desde allí.
Es uno de los ejemplos en aplicaciones comerciales y además con una concurrencia que debe ser alta (estamos hablando de la segunda aerolínea española), donde a mi parecer el Ajax se está utilizando en su justa medida, y se está utilizando para mejorar la experiencia del usuario sin pasarnos… una aplicación web no es una aplicación de escritorio, e intentar que eso sea así es para mi un error.
¿Tenéis experiencia en desarrollos con Ajax, podéis aportar vuestra experiencia? Da miedo aíºn el tomar la decisión tecnológica de usar Ajax en una aplicación web, ¿disponéis en vuestros equipos de trabajo de profesionales con experiencia con esta tecnología?
Saludos.
Miguel.
Ruby On Rails, Active Record + Andamiaje en acción
Profundizando un poco más en Ruby on Rails llegamos a otro de los innovadores conceptos que nos ofrece, el Andamiaje.
Para explicar lo que es el Andamiaje en RoR, nada mejor que utilizar un ejemplo en el cual además os habréis visto miles de veces.
En todas las aplicaciones en las que hayáis trabajado existirán una serie de tablas maestras en base de datos, y como siempre, para tenerlas “al día”, tendréis que haber dedicado su tiempo al mantenimiento de las mismas (vamos, lo de siempre, insertar, editar y borrar). Seguramente muchos de vosotros tendréis el proceso automatizado, por lo que al crear una nueva tabla maestra dispondréis de herramientas que vosotros mismos habréis creado para facilitar dicho mantenimiento.
La historia de todo esto es que Ruby On Rails os provee la posibilidad de automatizar los mantenimientos de tablas maestras de forma automática, sencilla y práctica. Como sabremos ya, RoR es un Framework Web asentado totalmente en MVC, por lo que para mostraros la potencia del andamiaje, se van a utilizar conceptos relacionados con el mismo.
Empezamos con el ejemplo, vamos a crear una tabla maestra que se encargue de almacenar coches, para ello, en lugar de irnos a la base de datos y crearlo desde allí, utilizamos Active Record para hacerlo (ya hemos hablado de Active Record en este blog).
ruby script\generate model Coches
Veremos que RoR ha creado una nueva migración y la ha dejado en /db/migrate/create_coche.rb
La editamos, para que muestra finalmente el siguiente aspecto
class CreateCoches < ActiveRecord::Migration
def self.up
create_table “coches” do |t|
t.column “nombre”, :string
t.column “fecha_alta”, :datetime
end
end
def self.down
drop_table “coches”
end
end
Sí, sí, aunque parezca mentira estáis definiendo vuestra tabla a través de código ruby. Y no sólo es eso, como veréis estáis definiendo como crear la tabla y como echarla “patrás” (contra-medidas). Esto es algo estupendo, vamos, estupendísimo, estáis creado los scripts de base de datos y sus contra-medidas de forma clara y totalmente automatizada, y lista para echarse para atrás en caso de ser necesario.
Bien, después de esto, ejecutamos el script (y todos los que hayamos necesitado crear)
rake migrate
A partir de aquí, magia, si consultamos nuestra base de datos veremos la tabla creada con los campos correspondientes, más un campo sorpresa que RoR genera de forma automática, el campo “id”, el cual crea como clave primaria de la tabla.
Bien, ahora si todo siguiera el curson normal tendríamos que dedicarnos a crear el mantenimiento de la tabla, pero… RoR nos va a volver a ayudar utilizando el Andamiaje. Para utilizar andamiaje lo deberemos hacer en el Controlador, y para ello
ruby script\generate controller Coches
Y añadimos el método “scaffold” al controlador
class CochesController < Application Controller
scaffold :photo
end
Y voila! Ya tenemos el mantenimiento creado… Podréis verlo levantanto WebRick (el servidor web del propio RoR) entrando en https://localhost:3000/Coches… veréis que podréis editar, actualizar e insertar nuevos coches 🙂 mola, no? 🙂
Eso sí, el interfaz gráfico deja mucho que desear, pero eso es algo que hablaremos más adelante 🙂
Saludos!
Formación .NET
Y siguiendo la formación… ahora le toca el turno a .NET.
Como no, recomiendo otro nuevo libro, que la verdad es que por lo que lo he podido ojear tiene buena pinta. El título ya dice bastante de cual es su objetivo “From Novice to Professional”.
Es algo que voy a poder contrastar los próximos días, ya que aunque yo ya llevo casi tres años detrás de .NET, alguno de mis compañeros van a dar sus primeras lecciones, por lo que vamos a poder comprobar de primera mano el valor de la información que aporta el libro (y la que puedo ir dándoles).
Como siempre, os dejo aquí las referencias:
Título: Beginning ASP.NET 2.0 in VB 2005: From Novice to Professional
Autor: Matthew MacDonald
Editorial: Apress
ISBN: 1590596218
Idioma: Inglés
Saludos!
Ruby On Rails
íšltima adquisición a la biblioteca.
Título: Ruby On Rails
Autores: Bruce A. Tate y Curt Hibbs
Editorial: Anaya Multimedia (O’Reilly)
ISBN: 978-84-415-2182-7
Idioma: Castellano
Estos 15 días de vacaciones estoy decidido a, por fin, tener un poco de tiempo para empaparme de Ruby On Rails. La verdad es que ya había leido algo anteriormente, pero estos días que he tenido algo más de tiempo la verdad es que lo que he podido ir viendo con algo más de profundidad me ha llamado bastante la atención, así que me fui a la Librería General aquí en Zaragoza en bíºsca de algo más profundo. Y hubo suerte!
La verdad es que me ha llamado tanto la atención que me da que el gestor de curriculums en lugar de estar hecho con PHP5 + Zend Framework voy a probar con Ruby On Rails. Me apetece bastante más, sobre todo estos días al tener más tiempo y la cabeza mucho más despejada.
Saludos!
El Jardín de Zen
“Atrás quedaron las maquetaciones HTML con Tablas”. “No utilice Tablas para realizar sus diseños”. “Maquete con capas”.
Estos son algunos de los slogans que se pueden leer en contra de las tablas HTML y en favor de la maquetación mediante capas. Entonces es cuando los que llevábamos de toda la vida maquetando con tablas nos tocó reciclarnos, porque estaba claro, era lo nuevo, era lo mejor.
El problema de todo esto es el de siempre, una imagen vale más que mil palabras, y por mucho que leas artículos y manuales al respecto, si no tienes a alguien cerca que te abra los ojos… tardas demasiado en descubrir algo que si alguien te lo explicara con las palabras adecuadas sabrías valorar en toda su potencia en 5 minutos.
¿Alguien necesita una verdadera prueba que le demuestre que maquetar con capas es absolutamente más avanzado que hacerlo con tablas? ¿Algo que lo motive de verdad?
Espero abrir vuestros ojos. A mi me resultó realmente impresionante.
https://www.csszengarden.com/tr/espanol/
Saludos.
Miguel.