¿¡¡Windows Mobile se esta mueriendo!!?

  Acabo de llegar a casa y he recibido, con agrado, mi publicación periódica de Smartphone & Pocket PC Magazine. Sobre la portada principal venía enganchado en forma de aviso en tamaño completo una nota en la que comenzaba con:

Dear Smartphone & Pocket PC magazine Subscriber:

Mal vamos, a ver que ha pasado, pensé. Seguidamente después de explicar un resumen de los cerca de 11 años que lleva la publicación en el mercado, nos notifica qué en el mes de noviembre será la última publicación y seguidamente se suspenderá. Dicha suspensión es debida a la poca esponsorización y clientes de Windows Mobile. 

La nota no para aquí. Seguidamente anuncian que seguirán una nueva publicación llamada Smartphone Magazine's iPhone Life ya que consideran oportuno apostar por un teléfono cuyo acogimiento por parte de los usuarios le augura un gran futuro y, evidentemente, es totalmente lícito.

Para finalizar citan textualmente que ven un futuro muy negro a Windows Mobile, y que pese a los esfuerzos de algunos fabricantes y de la propia Microsoft por apostar por nuevos dispositivos, deciden apostar por el iPhone por cuestiones de negocio.

Esto es un fiel retrato de lo que está sucediendo en EEUU y que muy probablemente empiece a notarse en Europa con la llegada, desde hace ya unos meses, del iPhone. Además de preocuparme por aquellos que han ampliado la hipoteca para poder adquirir uno y ligarse de por vida con Telefónica, me preocupa la comparación iPhone-Windows Mobile que tiene lugar en algunos rincones de la red. Bajo mi punto de vita no existe comparación posible entre un dispositivo físico (cerrado y no tiene Copy&Paste) y un sistema operativo (que debió de haberse reciclado mucho antes); sí lo aceptaría entre iPhone- HTC Diamond, por ejemplo. 

Pero está no es la cuestión; no escribo este post para criticar o alabar. La cuestión es que de los más de 1.000.000.000 -mil millones- de móviles  que se vendieron en el mundo en el 2006, la mitad de la tarta correspondía a Nokia y a Motorola. Nokia será lo que será pero manda en el mercado; a mí no me gustan, pero están ahí. Motorola por otro lado hace sus finitos con Windows Mobile pero el afán de competir con las Blackberry & Cía, (creo -no tengo datos-) no ha dado muchos frutos. En este punto es dónde me interesa saber ¿Qué es lo que no está consiguiendo Microsoft con los fabricantes?  Por si fuera poco, esta semana se presentó en España en el Google Developer Day el G1 de HTC, el primer móvil que saldrá al mercado para la operadora AT&T en EEUU. Uno más al grupo. Este además, ha aprendido de los errores del iPhone, más la legión de seguidores de SO Linux y la amplia comunidad de desarrolladores que la promueven, se va a convertir seguro en el gran rival de Windows Mobile, me refiero a Android. ¿Qué pasará con el iPhone? ¿Conocéis un sistema llamado Mac que empezó por allá los 70?

De todas formas, creo que pese a que Windows Mobile 7.0 lo tendrá difícil, ofrecerá gratas sensaciones. Además es un sistema operativo basado sobre el núcleo multimodular Windows CE 6.0 con unos cuantos años a sus espaldas, punto que no comparte ningún otro SO. Me pregunto si los fabricantes y operadores también las tendrán.

La herencia entre clases, ¿a ti te deja dormir?

Una de las malas prácticas más comunes que solemos acusar los desarrolladores es el abusivo uso de la herencia entre clases. De hecho, yo mismo en mis primeros pasos en OO con Java en la universidad, asociaba erróneamente la OO a la herencia, es decir si no hay herencia no hay OO. El supuesto o teórico despiece que debe permitir la reutilización de código gracias a la flexibilidad de esta propiedad, lo confundía con descuartizarlo de tal forma que obtenía un rompecabezas lógico de clases inmanejable e ineficiente; eso sí, el diagrama estático en UML quedaba muy bien (en apariencia visual claro).

Hace relativamente poco, hablando con un ex profesor sobre el tema en cuestión, me comentó acerca de la existencia de un principio, el Principio de Sustitución de Liskov  (LSP), el cual permite confirmar la eficiencia (no eficacia) de una herencia entre clases. LSP recibe el nombre de Barbara Liskov quién lo presentó en un seminario de OO. En la herencia se establece la subclase como “es un” (“is a”) -especificación- de la clase base y Barbara argumentó que además de “ser un”, la subclase debía “comportarse como” . Andy Hunt y Dave Thomas (The pragmatic programmer) resumieron LSP como: “Las subclases deben ser usables a través de la interfaz de la clase base sin que el usuario tenga la necesidad de conocer la diferencia.”. (Más info)

Esta misma tarde, ha tenido lugar un Webcast de Bruno, en cual he participado como oyente. Más allá del Webcast en sí, el cual ha sido brillante como no podía esperar,  Bruno ha hablado sobre el mal uso que se hace –de forma genérica- de la herencia, la cual cosa me ha llamado la atención y me ha dado pie a que, posteriormente, una vez finalizado el Webcast, le hiciera una pregunta a acerca del uso de test unitarios basados  específicos para evaluar la eficienciade la herencia, ya sea por LSP u otros técnicas. La respuesta fue buena: destacó la abstracción de interfaces –efectivamente como una aproximación válida-  y de un principio que comparto absolutamente con él: el Principio del Sentido Común.

Ahora bien, ¿Qué factores influyen en el sentido “más común” del sentido común? La experiencia, la capacidad de abstracción, los conocimiento teóricos sobre el tema,,,,, Cuando oí hablar por primera vez del LSP instintivamente analicé código hecho por mí para verificar si se cumplía dicho principio y encontré una herencia en cuestión –estoy convencido que hay más- que no lo hizo, sin embargo, dicho código forma parte de una solución funcional, está en producción. Luego, ¿es incorrecto pese a que funciona? ¿Es eficaz, pero no eficiente? ¿Podría encontrarme problemas si decidiera o requiriera extender las clases? Si es así, ¿Debo tener en cuenta al pie de la letra el LSP u otros mecanismos cada vez que confeccione un diagrama estático de clases?

Ojo, no pretendo discutir el LSP, faltaría más. La herencia llevada de forma eficiente  reduce la complejidad al desarrollador al poderse centrar únicamente en los atributos genéricos evitando tener que entrar en detalles; LSP es un principio, no como axioma sino lógico, que determina el nivel de eficiencia de la herencia entre clases y, por consiguiente, es un principio válido. Me refiero más a la línea que marcan los principios y las doctrinas académicas y las necesidades y realidades actuales.

Probablemente en este punto entre en escena las técnicas de calidad y demás. Ahí no voy a entrar; en esta comunidad hay gente que sabe mejor que yo del tema; más bien me gustaría saber vuestra experiencia u opinión al respecto, anécdotas y situaciones paranormales más allá de los libros.

En fin, ahí se queda; el próximo sábado por la noche saldré, beberé, fumaré hasta perder el conocimiento; la herencia no me quitará el sueño ;-)

SQL Server Compact 3.5. Buenas prácticas

Desde el pasado mes de abril hasta hoy he realizado varias charlas y he mantenido algunas conversaciones acerca de SQL Server Compact 3.5. De todas ellas, lo que más me ha sorprendido es que aún se relaciona la edición Compact con la antigua SQL Server CE y por consiguiente se da por hecho que el uso de base de datos SQL Server Compact está únicamente restringida a plataformas Windows CE. Lo cierto es que una de las características que, bajo mi punto de vista, va a suponer un antes y un después es precisamente que éstas puedan ser utilizadas tanto en plataformas Windows Desktop y Windows CE desde su aparición "como tal" a partir de la versión 3.1 (codename Everywhere).

SQL Server Compact 3.5 es un gestor de base de datos relacional orientada específicamente para cliente ligeros (SmartClients) en sistemas ocasionalmente conectados. De hecho, los Servicios de Sincronización para ADO.NET (Sync Services for ADO.NET) fue presentado junto a las primeras betas como versión 1.0 (fuera del runtime de MSF). El objetivo era el de presentar una tecnología que, pese a que despunta por su alta -relativa a las tecnologías actuales- flexibilidad, pretende marcar un antes y un después en soluciones de sincronización para cliente ligeros con bases de datos Compact. ClickOnce es otra tecnología de despliegue específica para este tipo de clientes.

En realidad todo esto son piezas tecnológicas cuya sinergia conjunto derivan en un potente conjunto de herramientas de desarrollo que facilitan la creación de soluciones ocasionalmente conectadas junto con todos los aspectos, peculiaridades y características que presentan.

Probablemente la pieza angular esta situada en la propia base de datos, un "simple" archivo sdf del cual recae todo -o una parte muy importante- del peso de la solución. El modelo de desarrollo empleado para este tipo de bases de datos no es muy diferente al que utilizamos habitualmente en aplicaciones escritorio pero sí tiene su peculiaridades, de hecho, es una base de datos que puede ser utilizada en una aplicación para Windows Vista y Windows CE, o lo que es lo mismo .NET Framework y .NET Compact Framework, luego si existen estas peculiaridades y la madurez de la tecnología actual lo permite, ¿porque no crear componentes de acceso a datos multiplataforma genéricos?, esto es, para .NET Framework y .NET Compact Framework.

En realidad esto tiene sus pros y sus contras, evidentemente. .NET Compact Framework es aproximadamente la equivalencia del 30% de .NET Framework y afrontar el desarrollo de componentes multiplataforma es posible, con sus "peros", pero posible. Un ejemplo lo tenemos en el uso de operaciones transaccionales, como novedad desde la versión 3.5 éstas pueden residir bajo ámbitos establecidos por el administrador de transacciones ligeras (Lightweight Transaction Manager) a través de las clases expuestas en System.Transaction, sin embargo, únicamente bajo plataformas Windows Desktop; he aquí un ejemplo de "peculiaridad para el código multiplataforma".

Pese a que SQL Server Compact no ha sido concebida como base de datos de gran capacidad de almacenaje y procesamiento no debemos descuidar la escalabilidad de la aplicación, conocer qué tipo de índices están disponibles y como sacar el máximo partido de ellos de cara a facilitar la tarea al optimizador de consultas, así como conocer, mínimamente, las diferencias de éste respecto su hermano mayor. Una característica que me gustaría destacar es que SQL Server Compact ofrece unas propiedades de gestión de excepciones, a través de las clases específicas distribuidas dentro de System.Data.SqlClientCE, basadas en códigos de errores nativos tipificados y errores HResults, propagados desde las capas más bajas de abstracción del Sistema Operativo, que bajo mi punto de vista son excepcionales si sabes cómo manejarlos.

Durante los más de 14 meses en los que estado inmerso en el estudio y búsqueda de modelos de desarrollo específico para SQL Server Compact, he tratado de sintetizar lo más importante para que el desarrollador iniciado con el este tipo de bases de datos parta con cierta ventaja antes de sus desarrollos, plasmándolo en un libro electrónico de poco más de 110 páginas y cuyo editor, SolidQ@Press, ha editado y ya está disponible.

Desarrollo de aplicaciones con SQL Server Compact Edition: Buenas Prácticas, no pretende ser un guía de referencia, sino un libro vertical, que trata todas y cada una de los aspectos más destacados que hay que tener en cuenta para la creación de aplicaciones consumidoras de la ‘mini' de la familia SQL Server, de forma directa, llana y sin introducciones.