¿Podrá Nora continuar su examen desde el celular?

Nora está comenzado un examen en la plataforma de aprendizaje en línea. Ha puesto en pausa su trabajo en casa por un rato para invertir tiempo en mejorar su carrera profesional y ahora está lista ante su laptop.

Le conceden una hora y cuarenta minutos para realizarlo.

Este es su segundo intento. El primero fue un desatino luego de otro y ella misma lo saboteó un poco más cuando desganadamente comenzó a responder aleatoriamente.

La segunda vuelta del examen iba a ser la definitiva. Ella Intensificó las lecturas y buscó videos y un par de libros para complementar el tema. Ahora si, está preparada.

Se toma tiempo suficiente para considerar cada respuesta. Algunas preguntas parecen capciosas. Las medita un poco más.

En cosa de 30 minutos ya ha respondido la mitad del examen. A este paso estará del otro lado de la evaluación con tiempo de sobra.

Este es el penúltimo paso para completar el curso y obtener un certificado. Se permite a sí misma anticiparse mentalmente un poco, ¿qué tal obsequiarse algo para festejarse el logro?.

Suena el celular.

Es de la escuela de su hija. La niña no se siente bien. “Ya mismo voy por ella”, dice. Hace su cálculo. Toma siete minutos llegar al metro. Otros veinte, cuando mucho, de trayecto. Un taxi, ni hablar. No en esta ciudad justo a esta hora.

Apuradamente se prepara para salir. Una ocurrencia providencial: podría continuar la evaluación en tránsito, desde su celular.

Con nerviosismo siente que el recorrido al metro consume demasiado tiempo. En la estación comprueba que no fue así, casi seis minutos. Aborda un vagón del metro e inicia sesión en la plataforma de aprendizaje.

Hay un problema. Los textos y los botones en la pantalla son ridículamente pequeños. Lo que está mirando es una miniatura de la página que estaba usando en casa. Los elementos importantes de la pantalla no están a la mano. Tiene que usar un par de dedos para ampliar o reducir los contenidos. Es incómodo. No es práctico. Se demora involuntariamente. Comete errores. Sin intención ha presionado botones que no necesita usar al tratar de cambiar la escala o intentando desplazar la pantalla.

Alguien a cargo de la plataforma de aprendizaje cometió una omisión tremenda.
¿Quién, en el área de TI, no sabe que la mayoría de las personas hace uso de servicios en línea mediante sus dispositivos inteligentes?. Pero los administradores de la plataforma de aprendizaje en línea la lanzaron a producción sin tomar la previsión de que fuera adaptable a pantallas menores.

Con varias preguntas aún por responder, Nora llega a la escuela por su hija. Parece ser una infección intestinal. La niña tendrá que pasar un pequeño rato de malestar, pero estará bien, le dice la doctora.

Nora obtuvo una calificación algo menor a la que aspiraba y le irrita recordar la experiencia. El grado de dificultad del examen no fue la causa sino la plataforma que le presentó una experiencia de uso complicada que consumió tiempo valioso.

***

¡Que se pueda usar en el celular!. Es una de las constantes de los clientes cuando nos piden la configuración de sistemas que van a operar en la web, como los sistemas de gestión de contenido, los de educación en línea, de eCommerce, de CRM y otras plataformas.

La mayoría ha pasado por la desagradable experiencia.

!Los visitantes se van cuando la página no se adapta al celular!. Manuel, un amigo y cliente, bastante expresivo, casi grita ¡Ya no estamos en los noventa!. Y lo entiendo. Los clientes ni siquiera deberían ser explícitos con este tema.

Cuando iniciamos esta empresa en 2013 ese fue uno de nuestros entendidos: La adaptabilidad de los contenidos y las aplicaciones para Internet tendría que ser una característica de facto. Para que no se repitan más situaciones como en la historia de Nora y su examen.

Agrega una nueva dimensión a tu información: Datos Geográficos

Luego de tomar su taza de café, Alberto consultó en su teléfono inteligente los resultados del día anterior. La mayoría de los representantes comerciales habían enviado, con puntualidad, su comprobación de presencia, dentro de las geo-cercas que les fueron asignadas. Solamente una decena de alertas amarillas se hicieron notar, lo que no está tan mal para un universo de mil colegas. Más adelante conversará con esos representantes para conocer sus incidencias.

Alejandra ha incorporado las más de 5 millones de unidades económicas, provistas por el INEGI, a su sistema de gestión de información, que ya incluye vialidades y usos de suelo. Realiza varias procesos de análisis de datos tomando en cuenta ubicación, actividad económica, tamaño de los establecimientos y prioridad de la vialidades para ayudar a sus clientes  a modelar un plan de mercado y selección de sitios para los siguientes 6 meses. En el primer día, los reportes resultantes les han servido para identificar un par de regiones con potencial y tomaron la decisión de migrar una sucursal.

Ángel recibe un reporte de las pruebas de entrega de su flota de transportes. Varios puntos rojos sobre el mapa le indican que la semana pasada fue difícil cumplir con puntualidad las entregas a varios clientes alrededor de Ciudad Sahagún. Ya se está dando cierta idea de la causa del problema y planea un par de estrategias para mejorar el servicio.

En la UNAM, Georgina le ha pedido al administrador de TI que agregue al sistema de gestión de contenidos un plugin para mostrar mapas. Su plan es publicar en el sitio web de su proyecto de investigación que, contrario a la noción común, una declaración de patrimonio cultural inmaterial de la humanidad por la UNESCO puede tener efectos negativos en ciertas poblaciones. En su caso, del pueblo p’urhépecha.

¿Qué piensas que podrías hacer con datos geográficos en tu organización?.

Comenzar a incorporar toda una nueva dimensión de información geográfica, puede comenzar por una columna adicional a la tabla de datos

Me dijeron unos emprendedores que no habían incorporado datos geográficos a su administración porque les parecía que solamente las empresas muy grandes podían costear la inversión en tecnología geomática.

Se desalentaron cuando recibieron los precios de las licencias de software de una empresa de renombre en el campo de los SIG. Regularmente son elevados. Y todavía faltaba el costo de los mapas digitales.

— Es posible que el sistema de gestión de datos que ustedes ya usan tenga soporte para geodatos — les dije. A partir de ahí, el resto es un proceso muy concreto y al alcance de casi cualquier organización. Les platiqué las historias que vienen al inicio de este texto. Son reales. Las personas que llevaron adelante esos proyectos no se detuvieron por causa de costos prohibitivos porque la tecnología que usaron estaba ya a su alcance.

Es verdad. Varias bases de datos de uso frecuente por las organizaciones ya son compatibles con información geográfica. Y cuando una organización aún no tiene una, el costo de adoptarla es moderado, si no es que muy bajo.

¿Cómo se hace posible que los geodatos comiencen a ser amigables con tu organización?. Puede darse un primer paso: agregar una nueva columna a cada tabla de datos. Una columna del tipo “geographic feature”, si nos ponemos algo técnicos. Ahí se pueden guardar diversos objetos gráficos comunes en los mapas: puntos, zonas y líneas.

Y los datos geográficos, ¿de dónde los tomamos?. Es como el cliché de comerse un elefante. Un bocado cada vez.

Iniciar con la producción de datos propios es el primer paso. Por ejemplo, convertir los domicilios de interés en coordenadas. Esto se puede hacer automática o manualmente.

Algunas apps podrían ser de ayuda para captar información en forma de puntos geográficos en el exterior.

E invertir en un especialista en SIG durante unas semanas para producir información complementaria de zonas y líneas es dinero bien aprovechado.

Eventualmente se pueden adoptar bancos de datos abiertos para conformar un conjunto que sea útil para procesos de análisis significativos. En México, INEGI ha puesto a disposición de los usuarios un amplio conjunto de datos geográficos y estadísticos. A nivel global, el proyecto OpenStreetMap se ocupa en capturar, afinar y compartir, con el apoyo de voluntarios, gran cantidad de elementos geográficos que se pueden explotar en cualquier sistema de información geográfica.

Después de adoptar un sistema de base de datos con soporte para información geográfica, es posible presentarlos y analizarlos con diversas herramientas de software disponibles en el mercado, algunas sin costo.

También, los navegadores web se han hecho amigables con los mapas, al punto en que nos es posible producir soluciones de front y back office que encapsulan visualización, procesamiento y automatización en una justa medida para las necesidades particulares de cada cliente.

***

En NFO Systems ayudamos a nuestros clientes a adoptar y gestionar tecnología de la información. Si piensas que tu organización se podría beneficiar de este tipo de servicios, te invitamos a conversar con nosotros.

Introducción al desarrollo de aplicaciones web con Rust y Rocket

Vamos a dar un vistazo a una de las opciones que el ecosistema de Rust nos brinda para el desarrollo de aplicaciones web.

Se asume que el lector ya conoce bien el lenguaje de programación Rust y que ya cuenta con un entendimiento básico de los fundamentes del desarrollo de aplicaciones web.

Rocket

Rocket, creado por Sergio Benitez, es un marco de trabajo para aplicaciones web que incorpora los elementos primitivos para el desarrollo de servidores y aplicaciones web con Rust. Rocket se enfoca en facilitar el ciclo de vida de las aplicaciones web y lo hace ayudando en cuatro áreas: el ruteo, la validación, el pre-procesamiento de peticiones, y el pos-procesamiento de respuestas.

Las tres filosofías de Rocket

  • Las declaraciones de funciones y tipos de parámetros deben contener toda la información indispensable para validar y procesar una solicitud.
  • El tipado de información al manejar solicitudes es obligatorio. Como la web y HTTP usan cadenas de texto, los valores dentro de las solicitudes y las respuestas deben ser transformados al tipo de datos que les corresponde. Rocket se hace cargo.
  • Las decisiones no deben forzarse. En otras palabras, Rocket no es una caja cerrada con todos sus elementos ocultos dentro de ella, los componentes para integrar la solución son opcionales. Plantillas, serialización, sesiones y otros componentes son acoplables e intercambiables.

Ejercicio: Hola, mundo

Vamos a crear un proyecto Rust con la herramienta Cargo. Necesitamos una terminal para introducir comandos:

cargo new --bin hola-rocket

Rocket requiere el uso de la versión nightly de Rust. Vamos a entrar en el nuevo directorio creado por Cargo y definiremos con Rustup que en este proyecto se use Rust nightly:

rustup override set nightly

Para asegurar el uso de la versión más reciente de Rust en este proyecto realizamos una actualización con Rustup y con Cargo:

rustup update && cargo update

Dependencias

Momento de trabajar con nuestro editor de código. En el archivo Cargo.toml vamos a agregar un par de dependencias para poder usar Rocket en nuestro proyecto:

[dependencies]
rocket = "0.3.17"
rocket_codegen = "0.3.17"

La primera ruta web de nuestra aplicación

Vamos a trabajar un poco para que nuestra nueva aplicación web nos responda “Hola, mundo” cuando visitemos la ruta “/” con nuestro navegador web. Para ello vamos a escribir un poco de código.

Nuestro archivo src/main_rs deberá quedar como sigue (hemos incluido comentarios que explican la finalidad de cada parte del código):

/*
    Vamos a necesitar un plugin de compilador para Rocket.
    Las siguientes dos líneas se hacen cargo de incluirlo.
*/
#![feature(plugin)]
#![plugin(rocket_codegen)]

// Incorporamos la biblioteca de Rocket en nuestro programa
extern crate rocket;

/*
    Declaración y función de una ruta index en "/", que va a responder
    una str estática diciendo "Hola, mundo".
*/
#[get("/")]
fn index() -> &'static str {
    "Hola, mundo"
}

/*
    Montaje de la ruta y la función index con Rocket.
    El servidor queda en espera de peticiones en "/".
*/
fn main() {
    rocket::ignite().mount("/", routes![index]).launch();
}

Ejecución de la aplicación

Volvamos a la terminal. “Lanzaremos” la aplicación con la herramienta Cargo:

cargo run

Esperamos un poco a la descarga de dependencias y compilación del programa. Si el proceso resulta exitoso tendremos en pantalla un mensaje como este:

🔧  Configured for development.
    => address: localhost
    => port: 8000
    => log: normal
    => workers: 8
    => secret key: generated
    => limits: forms = 32KiB
    => tls: disabled
🛰  Mounting '/':
    => GET /
🚀  Rocket has launched from https://localhost:8000

Para comprobar que la aplicación opera bien, en nuestro navegador web abrimos la URL https://localhost:8000 para ver nuestro “Hola, mundo”.

Para cerrar la aplicación, en la terminal usamos la combinación de teclas Control + c.

Un poco más, Hola + mi nombre

Demos un vistazo introductorio al trabajo con rutas y el paso de valores. Vamos a agregar una ruta “/hola”. También le daremos a la aplicación la capacidad de recibir una valor. En este caso, un nombre, por ejemplo: /hola/Mario. La respuesta de la aplicación será algo como “Hola, Mario”.

Necesitamos una nueva función de ruta en nuestro programa. Luego del cierre de la función index vamos a agregar la función hola:

#[get("/hola/<nombre>")]
fn hola(nombre: String) -> String {
    format!("Hola, {}", nombre)
}

En este ejemplo <nombre> será el parámetro que nos va a servir para construir el saludo que incluya un nombre.

Para montar esta ruta, dentro de la función main vamos a editar su única línea para que quede como sigue:

fn main() {
    rocket::ignite().mount("/", routes![index, hola]).launch();
}

Solamente hemos agregado el ítem hola, el nombre de nuestra nueva función, dentro de routes!.

En este punto podemos volver a ejecutar la aplicación con cargo run y en el navegador vamos a la ruta https://localhost:8000/hola/Mario (cambia Mario por el nombre que prefieras).

***

Esto fue un, muy escueto, vistazo inicial. Rocket contiene material suficiente para otro rato de aprendizaje. Hay mucho más que ver en relación al trabajo con solicitudes, respuestas, estados de la aplicación, pruebas, y configuración.

Si deseas continuar con esta exploración, el primer lugar para visitar es The Rocket Programming Guide.

Además, para éste y otros temas, es muy recomendable acercarse a la comunidad de Rust de tu región,  si la hay. Las comunidades de Rust en el mundo han ganado buena reputación en lo referente a su amabilidad, apertura y disposición para compartir conocimientos. Nos gustaría mucho contar contigo.

Por qué Rust no tiene Ternary Operator

Rust no tiene Ternary Operator. Lo tuvo hace mucho, pero fue eliminado. Y quizá eso es bueno.

El operador condicional o ternario, representado como ?:, es parte de las expresiones condicionales de algunos lenguajes de programación. Su uso permite evaluar una expresión y tomar una decisión, ambas cosas en una misma línea de código.

a ? b : c

Por ejemplo, esta línea en Swift, para una app en iOS:

view.backgroundColor = lightOn ? .white : .black

“Si el valor de lightOn es verdadero, el fondo de la pantalla deberá ser color blanco. De lo contrario, será negro.”

Es la misma funcionalidad que pueden brindar las expresiones If, pero el operador ternario tiene una sintaxis mucho más compacta.

La mayoría de los lenguajes de programación populares integran su propia versión del operador ternario (httpss://en.wikipedia.org/wiki/%3F:#Usage), entre ellos C y C++.

Rust contaba con operador ternario en sus versiones tempranas. El equipo del Core de Rust determinó que el valor de la expresividad, el minimalismo o la elegancia no estaría por encima de otros objetivos, siendo estas tres cualidades deseables, pero subordinadas.

No tener características de más es uno de los objetivos con mayor prioridad en Rust. En ese sentido, el ternario es un operador redundante.

En enero de 2012, Brian Anderson abrió el Issue 1698, en Github (httpss://github.com/rust-lang/rust/issues/1698), en favor de la eliminación del operador ternario, para cumplir con el plan de aligerar la cantidad de características del lenguaje.

Miembros de la comunidad, quienes participan en, o están al tanto de, la evolución de Rust, intercambiaron ideas a favor y en contra, en el issue 1698. Pesó más la remoción del operador ternario.

Para los días finales de enero de 2012, el operador estaba fuera del lenguaje (httpss://github.com/rust-lang/rust/pull/1705).

No es extraño que un programador habituado a otros lenguajes encuentre que Rust es escueto en sus características, y sin estar al tanto de la idiosincrasia rustácea en un primer impulso se exprese en favor de añadiduras. En 2015, dangerrust publicó, otra vez en Github (httpss://github.com/rust-lang/rfcs/issues/1362), que Rust había “olvidado” incluir el ternario dentro de su conjunto de operadores, para poder crear condiciones como la siguiente:

return value == 5 ? success : failure

En respuesta, dangerrust recibió un aluvión de comentarios de personas que gustan más de un lenguaje con menos “ruido”, que consideran innecesario tener múltiples maneras de hacer la misma cosa cuando ya existe una que es claramente legible.

En este punto, me resulta evidente que el Core Team de Rust y los rustáceos están en la misma sintonía, mayormente. Hay que familiarizarse con los motivos detrás del diseño de Rust como parte de la tarea de inmersión a su sintaxis.

Siendo Rust un lenguaje muy orientado a expresiones, este incorpora “implicit returns” (devolución implícita de resultados) en su diseño. Quizá quienes gusten de evaluar y devolver valores en una misma línea de código, a semejanza con el operador ternario, pueden escribir una última línea dentro de un función como sigue:

if value == 5 { success } else { failure }

O, cuando sea para asignar un valor a una variable:

Let howDidItGo = if value == 5 { success } else { failure };

***

En México existe una comunidad enfocada en el lenguaje de programación Rust:

Si eres programador o si deseas convertirte en uno, tenemos una invitación abierta para que te sumes a nuestra comunidad, queremos que cuentes con nuestro apoyo para ello y si eres un entusiasta de compartir tus conocimientos, quizá te puedas involucrar en este pequeño esfuerzo para extender la comunidad en el lugar donde vives.

7 cosas que quizá debes evitar al crear aplicaciones de Web Mapping

Quienes desarrollamos aplicaciones para la web podemos encontrar sorpresivamente que nuestras prácticas y nuestras herramientas de desarrollo de soluciones informáticas son ya obsoletas o retrógradas. Lo notamos especialmente en el web mapping, la técnica para llevar mapas dinámicos a los navegadores de Internet.

No todos los sitios web son acerca de temas y funciones que “atrapan” a los usuarios como Facebook o Twitter. El paso de los internautas en otros sitios es efímero y esporádico.

Un sitio web para mostrar mapas dinámicos debería ser una fuente efectiva de información y exponer realidades y escenarios eficazmente (este tema da para extenderse, pero no será en este texto). En el extremo opuesto están las aplicaciones en línea que son máquinas de ahuyentar visitantes. En NFO.io tenemos una lista negra de las prácticas que pueden hacer al web mapping aborrecible:

  1. No más ventanas emergentes o pop-up. De manera predeterminada los navegadores modernos evitan en la medida de lo posible la pesadilla de las ventanas que se abren espontáneamente, mismas que están muy asociadas con la publicidad invasiva. Cuando un mapa en Internet necesita abrir ventanas emergentes, las personas entran en estado de alerta, sus expectativas no son positivas, y podrían seguir de largo a otros sitios web. Una leyenda indicando que se debe habilitar el uso de ventanas pop-up para usar el SIG no incentiva a los usuarios, quizá los ahuyenta.
  2. ¡Responsive responsive responsive! Los usuarios usan por igual smartphones, tablets y computadoras de escritorio para navegar por Internet. En el caso de los dispositivos pequeños, que puedas reducir la página con dos dedos sobre la pantalla no es una solución. No lo es si los menús son unas breves líneas sin significado en la parte superior de una cuadro lleno de elementos gráficos diminutos. Si el sitio web no se adapta a los diferentes tamaños y resoluciones de las pantallas actuales sin perder de vista el mapa y sus herramientas principales, simplemente tendremos una experiencia nada llevadera y nuestro mapa estará destinado al desuso. Las tecnologías HTML5 y CSS brindan suficiente soporte para crear páginas adaptables. Si por el contrario, el engine de mapas, o la API que usas no lo facilita, entonces estás usando la solución equivocada.
  3. No obligues al usuario a descargar plugins. Simplemente no construyas soluciones basadas en plugins. No hace falta. Los navegadores de ahora son robustos. Saben dibujar toda clase de elementos gráficos y responden interactivamente a la mayor parte de los eventos que cada usuario pueda accionar. Cualquier plugin que se debe descargar es una molestia y puede llevar a una cadena de eventos que provoquen en los usuarios una frustración tras otra.
  4. El usuario no debería ser forzado a usar exclusivamente un navegador en particular. Cuando verse obligado a bajar plugins puede ser frustrante, tener que a usar un navegador en particular es peor, quizá más irritante. Si el motor de web mapping que elegiste impone el uso de un único navegador, puede ser que lleves ya varios años sin asomarte a la ventana a mirar las novedades en el mundo.
  5. “¡Mira qué poderoso, cuántas herramientas!” no más, por favor. Filas y filas de botones sobre barras de herramientas no hacen a una solución de web mapping más efectiva. No estamos cortejando a alguien enseñando nuestro brillante y esponjado plumaje. El espacio del usuario está invadido cuando debe estar despejado. Un usuario que hace consultas no debería tener en pantalla las herramientas de dibujo, o de ninguna otra clase a menos que tengan relación con el uso que le debe dar a la solución.
  6. La imagen institucional o la identidad corporativa no deben pesar más que el mapa. Las instituciones no quieren perder la ocasión de manifestar al mundo que ya han puesto manos en el asunto de la modernidad. Entonces, el producto que resulta consiste en una serie de rótulos invasivos con los nombres de la organización, la sub-organización, el departamento, la comisión a cargo, un gran escudo, las ligas a los sitios web de todos los departamentos de la institución, el mensaje del director avizorando la inminente llegada del futuro que será abrazado enfáticamente por su administración, las citas en cursiva de las congratulaciones de los lambiscones por este gran paso que nos lleva a la vanguardia … y un breve, muy breve mapa sobre la página.
  7. No se hacinen, gente, hay escalas y grupos de marcas para todos. El mapa se puede sobrecargar de elementos gráficos. Lo de menos es mostrarlos. Pero no cobra sentido que se amontonen los puntos. Se puede jugar con las escalas y con grupos de marcas o clustering.

¿Sabes de otros ejemplos en que la experiencia de web mapping se hace negativa?.