Fin de las contraseñas?

Hola,
Artículo de elpais.com
https://elpais.com/m/tecnologia/2014/12/26/actualidad/1419612652_594021.html
Lo tradicional se tiene que acabar, tanto por el nivel de seguridad como por el engorro que supone a los usuarios. Eso sí, robar una biblioteca de contraseñas va a seguir siendo lo mismo, sea en texto o sea una huella digital o lo que sea. Interesante entonces el concepto que se explica al final del artículo al respecto de que la contraseña no la almacene totalmente el servidor que realiza la autenticación. Podrás robar los datos, pero no tendrías así la llave entera.
Un abrazo!
Miguel

Buscando una arquitectura preparada para hacerse mayor.

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.
Cliente-Servidor
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.
 Extrayendo modelo de negocio
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.
Arquitectura Orientada a Servicios
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.

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.