Impresiones de Mix06

Esta semana tuve oportunidad de asistir a Las Vegas a Mix06, evento organizado por Microsoft dirigido principalmente a desarrolladores web, diseñadores, y tomadores de decisiones del mundo online.

En orden de más a menos, estos son los temas que me perecieron más interesantes:

1. ASP.NET Atlas

Atlas es un marco para desarrollar rápidamente aplicaciones con el modelo AJAX. Esta tecnología ya tiene una licencia GoLive! para usarse en sitios públicos. Me parece de aplicabilidad inmediata para mejorar la interactividad y respuesta de sitios web.

2. WPF

Windows Presentation Foundation es un nuevo motor para definición y presentación de la capa de interfaz de usuario en aplicaciones. WPF simplemente va a modificar dramáticamente las expectativas de los usuarios de aplicaciones tradicionales (Smart Client). La interfaz se puede definir en código tradicional o en un nuevo lenguaje declarativo llamado XAML. La introducción de este lenguaje declarativo facilita enormemente la cooperación entre diseñadores y desarrolladores en un proyecto de smart client. WPF en mi opinión va a revolucionar la facilidad de uso de nuestras aplicaciones. También creo que un conocimiento temprano de WPF puede ser un factor diferenciador muy importante cuando todo mundo continua haciendo aplicaciones basadas en formas.

3. WPF/E

Este es un subconjunto de WPF (la /E significa "Everywhere") para multiplataforma. Esta tecnología, aunque interesante, me parece que no es muy relevante por ahora ya que se liberará hasta principios (¿mediados?) de 2007. Para sitios públicos creo que va a ser difícil y va a tomar mucho tiempo para que se utilice esta tecnología en lugar de Flash por ejemplo.

Se presentaron algunas otras cosas interesantes como el Expression Intercative Designer con el cual diseñadores pueden crear interfases y contenido para WPF de una manera muy simple y poderosa. También son atractivos el API de Windows Media Center de Vista y los servicios de Windows Live.

Reflexiones sobre Mis Viajes a Taiwán

En los últimos dos años he tenido oportunidad de viajar varias veces a Taiwán, siendo la más reciente apenas la semana pasada. Como Mexicano en cada viaje tengo una buena oportunidad para comparar un poco nuestra sociedad con la Taiwanesa.

Taiwán es muy diferente a México. Es un país donde el ingreso per capita es el doble que en México y el porcentaje de población que vive por debajo de la línea de pobreza es menor al 1%. Las diferencias en el nivel de ingreso son mucho menos marcadas que en México y el nivel de educación promedio es mucho mayor. La población en su mayoría es étnicamente china, de los Chinos que perdieron en la revolución comunista de la China continental.

Viniendo acá parece que salieron ganando con lo que han logrado hacer en esta isla. Este es un país que en los sesentas soñaba con alcanzar el nivel de desarrollo que México tenía en ese momento. Apostaron al futuro (a la industria de las tecnologías de información) y tomaron las medidas necesarias para convertirse en uno de los “tigres asiáticos” y hoy prácticamente son ya una economía desarrollada.

En mi experiencia tratar con un Taiwanés es siempre agradable, independientemente de si es para temas de negocios o simple amistad. He hecho un par de buenos amigos aquí. Siempre son amables y tienen muestran una humildad muy particular. Eso sí, trabajan como locos, toman muy pocas vacaciones y muestran una tenacidad pertinaz para todo lo que sea negocio. Una experiencia que me impactó fue conocer a un tipo dueño de una empresa de tecnología de buen tamaño que me presumía de cómo en 20 años sólo había tomado tres días de vacaciones y tenía una casa de 5 millones de dólares (¿para que puede alguien querer una casa de ese precio si nunca toma vacaciones?).

El éxito económico de Taiwán es innegable. Aún así, como Mexicano relativamente afortunado que soy de vivir con bastante comodidad (y que toma mucho más vacaciones), al hacer una comparación entre nuestras sociedades prefiero evitar saltar a la tan mentada conclusión sobre como tenemos que aprender de los tigres asiáticos. En ciertos aspectos sin duda habrá mucho que aprender, pero ¿hay que vivir para trabajar o trabajar para vivir?

Seguridad en Nuestros Desarrollos

La seguridad es un tema que debe interesarnos como programadores profesionales. Basta con leer los titulares cualquier día en un sitio de tecnología (como http://www.news.com/) para darse cuenta de la gravedad del problema.

La realidad es que la mayor parte de los problemas de seguridad pueden evitarse con adecuadas técnicas de programación e incorporando la seguridad como un requerimiento de diseño en nuestros proyectos.

El día de hoy tuve la oportunidad de ofrecer un par de talleres dentro del evento WebSec. El primero sobre desarrollo seguro con C++ y C# y el segundo sobre desarrollo seguro con .NET. Las láminas de las presentaciones de estas pláticas están disponibles aquí y aquí en el sitio de emLink, empresa donde trabajo.

¿Ustedes qué opinan? ¿Por qué nos es tan difícil como programadores poner atención al asunto de la seguridad en nuestros desarrollos?

Plática sobre Windows Forms 2.0 en el lanzamiento de VS 2005 en México

Voy a tener el gusto de dar una plática sobre "Clientes Inteligentes" en el evento de lanzamiento de Visual Studio 2005 el próximo 15 de Noviembre en el Centro Banamex a las 19:00 hrs. Voy a hablar 30 minutos sobre esto y los también MVPs Microsoft Miguel Muñoz y Haaron González hablarán de desarrollo con ASP.NET 2.0. Esta es la liga para inscribirse al evento.

Platicas Sobre SQL Server Mobile en México y Guadalajara

Una vez más tuve el honor de dar un par de pláticas. En esta ocasión sobre SQL Server Mobile (antes conocido como SQL Server CE versión 3.0). Los eventos fueron en la reunión de la Comunidad .NET de la Ciudad de México y en el Microsoft DevDays de Guadalajara.

Es un avance muy importante el de esta versión contra las anteriores.

Lo que más me ha llamado la atención es:

• La capacidad de SQL Mobile para trabajar con apps en el .NET CF 1.0 (en VS 2005 Beta 2). Es decir, no solo funciona con el .NET CF 2.0.
• La integración al SQL Server Management Studio de SQL Server 2005. Este tema realmente simplifica las cosas en desarrollo móvil:
• Podemos editar bases de datos de SQL Mobile en la PC.
• Contamos ahora con un analizador de consultas para SQL Mobile.
• Podemos llenar una base SQL Mobile usando DTSs.
• Lo mejorado y simplificado de la replicación entre SQL Server 2005 y SQL Server Mobile.
  
• La configuración, diagnóstico e implementación de replicación (merge replication) es sin exagerar un orden de magnitud más sencilla que antes.
• El desempeño es mucho mejor gracias al rastreo de cambios a nivel de columna además de renglón.
• Podemos hacer mucho mejores interfases de usuario en el dispositivo móvil gracias al manejo asíncrono y a los eventos que expone el motor de sincronización.
• El desempeño de las consultas en el dispositivo móvil gracias al nuevo SQLResultSet que evita que tengamos dos copias en la memoria de los datos (como ocurre con un DataSet) pero al mismo tiempo es más flexible que un DataReader.

Hay muchas otras mejoras, pero estas son las que me parecen más interesantes.

Del lado negativo, hay algunas cosas que falta pulir (espero que así sea para la liberación final más adelante este año):

• El desempeño del despliegue a los dispositivos o a los emuladores cuando estamos depurando en Visual Studio 2005 es muy malo ya que siempre redespliega todo el .NET CF 2.0 y el SQL Server Mobile. Esto no debiera ser así y quizá se deba a algún problema de configuración. Si encuentro una solución la podré aquí.
• El consumo de memoria de almacenamiento en el dispositivo de la combinación de el .NET CF 2.0 y el SQL Server mobile es demasiado alto, dejando al dispositivo (si tiene 64MB) con muy poca memoria libre.

También al estar explorando este tema he tenido oportunidad de irme familiarizando con la funcionalidad de Visual Studio 2005. Me parece también un salto importante y hablaré de esto en un futuro post.

Si te interesa más este tema puedes bajar las láminas de mi presentación y el código ejemplo desde el sitio de noticias de emLink.

Plática sobre Desarrollo con .NET CF en la Facultad de Ciencias de la UNAM

Mañana voy a dar una plática sobre desarrollo con dispositivos móviles en la UNAM. Agradezco mucho a Octavio Telis la invitación. La plática va a ser muy similar a una de fines del año pasado que dí en el grupo de MSDN sobre este tema.

Me produce cierta emoción (positiva) asistir a la UNAM. No deja de tener el peso de ser la máxima casa de estudios de México.

Las diapositivas de la plática las pueden encontrar en el sitio de emLink en la sección de noticias a partir de mañana.

Visual Studio 2005 Beta 2

A partir de este Lunes Microsoft hizo disponible en MSDN (para suscriptores) el segundo beta de Visual Studio 2005 (antes conocido como Whidbey).

Desde ayer lo estamos bajando (son más de 3GB) y próximamente voy a estar posteando acá mis impresiones.

El Beta 1 lo he usado muy poco ya que era conocido que habría muchos cambios entre el Beta 1 y el 2. Además, la primera vez que lo instalé me causó serios problemas (lo se, esto hay que hacerlo en máquinas virtuales: es Beta)

Lo primero que voy a explorar es el Visual Studio Tools for Office 2005, luego las funcionalidades del team system y finalmente el nuevo compact framework y otras áreas. Mientras hago eso voy a ir viendo los nuevos aspectos de C# tanto en el lenguaje como en el editor. Dejen aquí sus comentarios si les interesa un tema en particular. No prometo conceder deseos pero serán tomados en cuenta.

Algo muy interesante es que este Beta ya trae la licencia Go Live! que permite poner aplicaciones en producción cubriendo ciertos requisitos.

Aplicaciones de Mapeo y Uso de GPS

Últimamente he tenido la oportunidad de participar en algunos proyectos para la industria de transporte de pasajeros que involucran interacción con GPS así como con servicios de mapeo.

En cuanto a la interacción con GPS, hemos encontrado algunos puntos que es importante tener en cuenta:

1. La precisión del GPS para ciertos temas es limitada.

1.1 Cuando leemos la velocidad, el GPS tiene cierto margen de error. Pudiendo marcar una velocidad aún cuando nos encontremos detenidos.
1.2 El cálculo de odometro a partir de coordenadas GPS también tiene limitaciones importantes debido a la misma imprecisión. Estamos haciendo pruebas en campo del margen de error y pronto compartiré los resultados aquí.

2. A veces es necesario que más de una aplicación pueda leer el GPS.

2. Cuando más de una aplicación quiere usar el GPS, hay que desarrollar una mecánica para que dos procesos puedan compartir el puerto serial. Hemos desarrollado un SDK que permite hacer precisamente esto. Un proceso escucha al GPS y retransmite las coordenadas a las aplicaciones que se han suscrito a la información. Para esto tenemos desarrollado un componente .NETCF que facilmente nos permite usar la info del GPS.

Por otro lado, bajé el SDK del servicio web de Mappoint y cree una cuenta de prueba. (Puedes obtener el SDK aquí).

Para mi sorpresa, encontré que la Ciudad de México está bastante bien "mapeada". Estoy en el proceso de hacer pruebas pero todo el concepto del servicio de MapPoint me parece muy interesante. Es un excelente ejemplo de aplicaciones orientadas al servicio. Recomendado como opción a explorar para aplicaciones geográficas.

10 Tips para el Desarrollo de Aplicaciones Móviles (Parte 2)

6. Prueba a Fondo tu Aplicación y Después: Pruébala De Nuevo

Aplica todo lo que sabes de pruebas formales y agrega: prueba tu aplicación sobre el dispositivo real que vas a desplegar. El emulador sólo es aceptable en etapas iniciales de tu proyecto (aunque va mejorando la tecnología de emulación). Exige un laboratorio de pruebas idéntico a la infraestructura de despliegue en todas las variables relevantes. Prueba la sincronización de datos simultánea conforme a tu carga máxima esperada.

Considera un etapa de prueba piloto siempre con pocos usuarios (combinando entusiastas y rejegos) para que pulas tu aplicación antes de liberarla a todos. No voy a repetir aquí las mejores prácticas de pruebas para desarrollo de aplicaciones en general. Sólo considera que en aplicaciones móviles muchas veces debes cuidar la calidad y mitigar tus riesgos algo más de lo que haces normalmente.

7. Utiliza el Principio KISS (Variante Francesa)

KEEP IT SIMPLE, STUPID. Variante Francesa porque en aplicaciones móviles esto es todavía más intenso. Todas las veces (¡TODAS!) que he participado en una aplicación móvil se le quita funcionalidad entre la primera y la segunda versión para simplificar su uso. Libera la mínima unidad funcional posible primero y estudia el efecto en el campo. Este principio aplícalo en todos los aspectos de tu aplicación. Buenas preguntas son: ¿Realmente necesitamos capturar este dato? ¿Necesitamos desplegar esta información? ¿Es indispensable bajar este elemento del sistema central? ¿Vale la pena automatizar este caso excepcional?

8. Considera las Limitaciones de Memoria y Velocidad de Proceso

Establece como requerimientos formales los volúmenes de información que debes manejar y los tiempos de respuesta máximos aceptables de tu aplicación para cada caso de uso. Separa tiempo en tu proyecto durante la etapa de análisis para hacer algunas pruebas de concepto que te permitan saber con certeza si es posible y de que forma. No asumas nada. “Si, seguro cabe el catálogo de 20,000 productos en 64MB.” Haz un pequeño programa de usar y tirar para validar esto antes de abrir la bocota. O vas a acabar teniendo que justificar (y quizá absorber) el costo de expansiones de memoria para todos tus usuarios. Bueno, para sus dispositivos móviles al menos.

9. Elige el Tipo de Dispositivo Adecuado

No todos los dispositivos móviles son iguales. De hecho, en este campo la variabilidad es mucho mayor que en el caso de PCs. Con o sin: Teclado, touch screen, wi-fi, bluetooth, cámara. De uso rudo, semirudo o estándar. Con diferentes capacidades de memoria, procesadores, opciones de expansión, etc. Incluso puedes mandar a hacer tu propio dispositivo si vas a requerir un volumen importante.

Con base en lo que encuentres en el campo, estudia tus opciones de tal forma que maximices tu retorno de inversión. Llévate las opciones a la calle en operación real y pruébalas con algún prototipo sencillo. Mantén abiertas tus opciones de software para el equipo. Es fácil caer en la tentación de que “el proveedor de la handheld de $3,000 dolares cada una nos va a regalar el software”. Mantén tus opciones abiertas como en el caso de tu infraestructura de PCs. Elije equipo al que le puedas poner la aplicación que se te de la gana cuando se te de la gana.

10. Planea Pruebas de Concepto para Areas Nuevas o de Alto Riesgo

Es altamente probable que conforme desarrolles experiencia tus aplicaciones móviles vayan aumentando de complejidad. Una de las áreas más comunes es la integración a otros dispositivos como impresoras, escáners, cámaras, etc. Es muy importante que dejes tiempo en tu etapa de análisis para hacer pruebas de concepto de las áreas nuevas que no hayas usado antes.

Una prueba de concepto es normalmente un pequeño programa de código que luego tirarás a la basura pero que te sirve para conocer si lo que tienes en mente es válido. En realidad este concepto aplica para todo tipo de aplicaciones, pero en las móviles puede ser más frecuente necesitarlas.

10 Tips para el Desarrollo de Aplicaciones Móviles (Parte 1)

En diferentes ocasiones he tenido la oportunidad de visitar clientes para conocer y opinar sobre diferentes aplicaciones móviles.

Independientemente de la funcionalidad específica de cada aplicación, la mayoría de estas visitas me hacen reflexionar sobre lo común que sigue siendo el diseñar soluciones móviles como si fueran una variante “chiquita” de aplicaciones en PC.

No tomar en cuenta las particularidades de una solución móvil desde su diseño puede provocar con facilidad que una buena idea de negocios no dé los resultados esperados. Por esta razón, decidí escribir esta lista de 10 tips a considerar para compartir algunos elementos de nuestra experiencia. Esta semana publico los primeros 5:

1. Conoce la Operación en el Ambiente Real

Esto es indispensable. Hay que “ensuciarse las manos”. Mientras más alejado está un elemento de operación de las oficinas centrales de una empresa, más variantes vas a encontrar entre la forma como los jefes dicen que funcionan las cosas y la realidad. Cliente tras cliente nos hemos encontrado con esto. El personal de campo siempre va a descubrir formas de optimizar su trabajo de acuerdo con sus objetivos específicos y es indispensable entender esto. Tómalo en cuanta para tu aplicación cuando tenga sentido de negocio y oponte firmemente a diseñar una aplicación de alguna forma sólo porque el jefe dice que así debe ser. Súbete a la camioneta, sal a caminar con él, pregunta de todo y analiza que está pasando. Debate tus opciones con el dueño de tu presupuesto y llega a acuerdos que permitan que cuando salga al campo tu aplicación realmente de el beneficio de negocio esperado.

La mayor parte de los procesos en campo se dan con estrictas limitaciones de tiempo ya que las empresas (en la mayoría de los casos con razón) relacionan el número de visitas realizadas con el nivel de productividad de su personal en campo. Entiende y conoce las “mañas” que se desarrollan para ahorrar tiempo o simplificar el trabajo. Busca una forma de que tu aplicación le agregue valor y/o le simplifique el trabajo al personal que la va a operar. De otra manera la resistencia al cambio cuando sea momento de desplegar va a ser mucho mayor.

2. Estudia la Plataforma que vas a usar y sus Capacidades

El desarrollo para dispositivos móviles es cada vez más fácil. Las herramientas de software convergen con las de escritorio. Hoy puedes usar Visual Studio 2003 y trabajar en C# o en VB.NET para dispositivos móviles. En Visual Studio 2005 lo podrás hacer también con C++.

Sin embargo, a veces esto puede ser una trampa. Nos venden la idea de que podemos empezar a trabajar en dispositivos móviles sin ningún esfuerzo. No es así. Es necesario tomarse el tiempo para estudiar las diferencias entre la plataforma de escritorio y la móvil. Así diseñarás mejor y te ahorrarás mucho tiempo después (“es que ya vi que el Compact Framework no trae el XML Serializer y me estoy atrasando…”)

Por ejemplo, ¿sabías que si escribes una función que al compilarse mida más de 64K en el Compact Framework te va a provocar una falla general de protección de memoria (GPF)? ¿piensas que sólo un loco escribiría una función tan grande? ¿has pensado que ese loco puedes no ser tú, sino el diseñador de formas de Visual Studio 2003?

La misma idea aplica en otras plataformas de desarrollo móvil como J2EE vs. JME.

3. Planea la Sincronización de Datos

La gran mayoría de las aplicaciones móviles para corporativos son extensiones de sistemas existentes. Aplicaciones de ventas, CRM, mantenimiento, servicio, etc. Todas deben conectarse a sistemas centrales y sincronizar la información.

¿Está la información disponible? Verifica como la vas a extraer/depositar en sistemas centrales. Checa si los datos que extraes son validos. ¿Necesitan alguna limpieza? ¿Hay alguien que sabe como sacar la información? ¿Está documentado o tenemos que hablarle al experto que hizo el sistema original en RPG?

Combina bien la sincronización planeada con las capacidades de los sistemas de negocio. ¿O vas a poner pedidos en línea vía GPRS para que se suban en batch diariamente al ERP?

El tema de sincronización da para varios artículos completos. Asegúrate de investigar, planear y probar el desempeño. Hazlo fácil para tu usuario. Que tu meta siempre sea que para el usuario se transparente; que no tenga que hacer nada. Si, nada. No, apretar un botón no es nada. NADA.

4. Diseña una Interfaz Adecuada para Dispositivos Móviles

Este punto parece sencillo pero no lo es tanto. La mayoría de nosotros estamos acostumbrados a desarrollar para una PC, cada vez con mayor espacio en la pantalla para presentar nuestra interfaz y con los usuales dispositivos de entrada: teclado, mouse, etc. La primera reacción ante las limitaciones de un dispositivo móvil (Como una PDA) suele ser intentar hacer lo mismo pero “en chiquito”. Esto puede provocar serios problemas. ¿Han intentado atinarle a la flecha de scrolling en una PocketPC? ¿Qué tal capturar un texto largo? Es indispensable pensar diferente cuando trabajamos en estas aplicaciones y una buena forma de hacerlo es intentar usar nuestra propia PDA cada vez más para actividades de nuestra vida diaria y preguntarnos continuamente ¿Cómo podrían haber hecho esta aplicación más fácil de usar?

Algunos lineamientos generales son: minimiza la captura, piensa como la usarías si se te pierde la pluma, simplifica la navegación, estudia los controles gráficos especiales para PDA y sácales provecho, muestra sólo la información realmente indispensable, y trata de integrarte cuando haga sentido con las aplicaciones de la PDA con las que el usuario ya está familiarizado como el calendario o el cliente de correo electrónico.

5. Piensa en el Soporte a tu Aplicación Móvil

“Ya desplegamos nuestra aplicación móvil y estamos vendiendo a través de ella. Es una maravilla tecnológica y acabamos el proyecto antes del tiempo planeado, la primera vez que usamos el .NET Compact Framework 2.0. Tenemos 150 vendedores en todo el país. Todo es felicidad. Vamos a sacar una nueva versión con varias mejoras. Para desplegarla mandamos un mail a todas nuestras sucursales con la nueva versión. Total, ya entrenamos a nuestro personal de soporte en todos lados y saben instalar la nueva versión. LOL. Nos tardamos 15 días en instalar la nueva versión. Y un mes en el caso de la sucursal de Tijuana que se resuelve hasta que mandamos a alguien en avión a hacerlo. Bueno, no importa, valió la pena; la nueva versión funciona bien, todo mundo feliz porque las ventas van en aumento. Es el día primero de Abril. Ehem, la aplicación truena porque tiene una pequeña falla que solo se manifiesta cuando la fecha es el día primero de mes y no probamos ese escenario. No se alarmen, es una línea de código. Ya está. Toda la fuerza de ventas deja de hacer pedidos y los captura a mano. Los clientes cancelan. Le decimos al Director Comercial que ya dominamos el proceso de despliegue y esta vez nos tardaremos cuando mucho dos semanas en actualizar todo. Nos invita a pasar a recursos humanos por nuestra liquidación.”

Evita repetir esta historia. No es fácil actualizar dispositivos dispersos por todos lados. Desarrolla un mecanismo automatizado de actualización y soporte o mejor aún, evalúa una opción existente que se adapte a tus necesidades. Support Everywhere es un ejemplo que podría funcionar para ti.