Suscribirse a canal de noticias Feed En casa del herrero Wordpress
El blog de los tecnilógicos
Actualizado: hace 1 hora 29 mins

Kuligraso: Tecnilógica quema calorías

Lun, 06/08/2015 - 18:00

KULIGRASO: nomenclatura comercial derivada de la original en esperanto, Kalkuli graso (“Calcular grasa”), que fue con la que empezamos a trabajar. Como os podréis imaginar, nos hace más gracia la actual.

En Tecnilógica ideamos un sistema que mostrara en una pantalla instalada en la oficina la distancia recorrida el día anterior por los empleados dados de alta en dicho sistema.

Para ello, se generó una plantilla de PosterDigital, nuestro CMS de Digital Signage, que recogía, al menos de entrada, los metros completados a pie. No obstante, en la base de datos almacenamos el tiempo total, el número de pasos, la fecha, y si esa distancia suponía un récord con respecto a fechas anteriores, permitiéndonos una escalabilidad en cuanto a métricas: podíamos mostrar los resultados por gráficos, evoluciones, etc. El alcance de los datos en cuanto a su recogida puede llegar hasta niveles más sensibles, tales como la glucosa, pero hay cuestiones de privacidad que podrían incidir en su tratamiento y su publicidad.

Para participar en Kuligraso, el usuario se da de alta en el sistema generando un ID de usuario y elige, usando la interfaz de Human API (que hace las veces de agregador multidispositivo y multiapp), la aplicación que utiliza habitualmente para monitorizar sus pasos. Por el momento hemos excluido lo recorrido en vehículos, como bicicletas o coches. Los datos generados por esas apps se recogen diariamente y se almacenan en la base de datos y se muestran por medio de la plantilla de PosterDigital. Más allá de las estadísticas y las gráficas cruzadas y relacionadas entre usuarios, se habilitan otras posibilidades de interacción entre participantes como la gamificación del ejercicio.

Con Kuligraso nos resultan especialmente interesante dos aspectos: por un lado, haber podido explorar las posibilidades de una herramienta tan potente como Human API, y por otro, haber sido capaces de integrarla con PosterDigital.

Famostrato: personajes históricos de las calles de Madrid

Mié, 04/22/2015 - 18:09

¿Qué es el “Famostrato”?

La idea del proyecto “Famostrato” surge con la intención de investigar las posibilidades ofrecidas por CartoDB, un servicio en la nube que permite crear y publicar mapas online de manera sencilla. Una excelente plataforma para mostrar información de todo tipo de manera muy visual por todo el globo terrestre o, como es nuestro caso, la Comunidad de Madrid.

Famostrato es un proyecto que permite enlazar las calles de Madrid que fueron nombradas en honor a un personaje histórico. Para ello, se hace uso de la información disponible sobre este personaje en la Wikipedia en español, y siempre utilizando CartoDb para la visualización sobre el mapa de las calles que disponen de esta característica.

Desarrollo del Proyecto

El proyecto parte de un conjunto de datos facilitados en la página personal del cofundador de CartoDB, Sergio Álvarez Leiva, concretamente el dataset “osm_madrid_lines”, que contiene las calles de Madrid obtenidas a través de openstreetmap.org.

Con esta información de base, el siguiente objetivo es obtener la palabra clave que correspondería a la página de la Wikipedia para después completar esta tabla con la información proporcionada por la API de esta. Todo este proceso de scripting se realizaría utilizando NODE.js para sincronizar las llamadas a los distintos servicios del proyecto.

La primera fase, por tanto, es convertir todos esos nombres de calles. Por tomar un ejemplo, de la Calle Alonso Cano deberíamos obtener “Alonso_Cano”, para poder enviarlo a la API de Wikipedia y que esta nos devuelva información en caso de que exista la página. Para ello, se trabaja con expresiones regulares que ayudan a eliminar los términos “Calle, Avenida, Glorieta, Plaza….” para al final usar el nombre de la página en cuestión de la Wikipedia.

Posteriormente se hace una llamada a la API de la Wikipedia, que en caso de tener una entrada devuelve un JSON con el contenido de la entrada en la página. Tras recibirlo, se procesa para comprobar que se trata de una persona. Para ello, en la respuesta de la Wikipedia se buscan los tags “nacimiento” o “biografía”, comprobando que no contiene el tag “desembocadura”, con el fin de evitar que los ríos se detecten como personas.

Una vez obtenidas las calles que representan a personas, hay que obtener una imagen thumbnail para añadirla a la ficha que surgirá al pinchar en la calle correspondiente, lo cual se consigue con otra llamada a la API de la Wikipedia preguntando por la imagen thumbnail de la entrada correspondiente.

Resultado

Una vez recogida toda esta información para cada una de las calles, ya se ha creado el mapa personalizado en CartoDB, listo para utilizar. Es entonces cuando se puede incrustar el mapa en la web del proyecto para mostrarlo al usuario, centrando dicho mapa en su localización (en caso de disponer de ella).

Ya está todo listo para poder aprender curiosidades sobre las calles de Madrid (y los personajes que dan nombre a las mismas) de manera fácil e intuitiva.

PosterDigital: nuestro CMS al servicio de la excelencia del DS

Vie, 04/10/2015 - 18:59

Según previsiones internas de Tecnilógica, y a partir del incremento observado en cuanto a estas instalaciones durante 2014, en 2015 seguirá creciendo significativamente la instalación de las soluciones de Digital Signage, las cuales impactan directamente en el crecimiento del volumen de ventas, generalmente entre un 20% y un 35%, especialmente en los sectores de retail, hostelero y de restauración. Una correcta estrategia de Digital Signage puede generar un aumento de 33% de ventas, según datos de Nielsen Research.

En cuanto al hardware, observamos la inevitable consolidación y auge de los displays con players integrados de tipo SoC (System on Chip), que son la tendencia de la industria en estos momentos. La utilización de dichas pantallas, que de esta forma tienen el player integrado, permite una reducción de coste de entre el 24 y el 31% frente al uso de players externos, algo que ayudará aún más al desarrollo emergente que está experimentando el mercado. Esta reducción de costes se materializa de manera espectacular en algunas de las partidas que conforman el mix de costes de cualquier negocio que basa en Digital Signage una buena parte de su actividad en el mercado, como por ejemplo en lo referente, por ejemplo al proceso de instalación y cableado, cuya disminución de costes alcanza entre el 70 y el 100%. La simplificación se extiende incluso a la posibilidad de usar la alimentación a través de Ethernet (Power over Ethernet, PoE), lo cual abunda aún más en esta reducción de costes.

A la par que la consolidación de estos displays con player integrado como tendencia que se abre un hueco indiscutible y que se lleva ya un trozo relevante del pastel, ya es generalizada la aparición de formatos de pequeño tamaño, con la posibilidad de que estos sean táctiles, permitiendo la creación de múltiples soluciones para los diferentes puntos de venta: catálogos, pantallas en espacios como ascensores, probadores… La programación a la carta de los contenidos y la maximización del espacio disponible son sólo las herramientas básicas de trabajo con las que el usuario cuenta al iniciar el despliegue de cartelería digital de su negocio. Cada vez que necesite añadir producto o modificar precio, puede trabajar con cualquiera de estos instrumentos desde su gestor de contenidos y decir adiós a los costosos y lentos cambios de su cartelería tradicional.

Esta versatilidad inherente a las nuevas tendencias dentro del DS permite al usuario acceder a la modernización de las dinámicas en el punto de venta creando nuevas interacciones. Ejemplo de esta adaptación a las nuevas experiencias del cliente es nuestra solución para Gucci, donde el contenido que se muestra en las pantallas es diferente en función del producto con el que interactúa el consumidor.

Instalación de PosterDigital en el Poncelet Cheese Bar de Barcelona

Tecnilógica ofrece desde hace más de 10 años su particular y propia solución de CMS orientado a cartelería digital: PosterDigital. La conjunción de este tipo de displays de player integrado con PosterDigital permite potenciar todo tipo de funcionalidades básicas para un proyecto de estas características: gestión remota de pantallas y contenidos, múltiples usuarios… La versatilidad y las posibilidades que ofrece el despliegue de contenidos en punto de venta a través de DS se multiplica con el CMS de PosterDigital, así como la posibilidad de personalizar al máximo el proyecto. Prueba de ello son los proyectos desarrollados por Tecnilógica para marcas tan prestigiosas como Coca-Cola, Mahou, el ya mencionado de Gucci, Senado de España o Poncelet.

Software para realizar animaciones basadas en HTML5 y CSS3

Mié, 02/18/2015 - 19:35

A lo largo de este año hemos ido probando varios programas de edición gráfica para hacer animaciones basadas en HTML5 y CSS3. Con la llegada de estas nuevas tecnologías se abre un amplio abanico de posibilidades para estas animaciones gráficas.

No hace falta tener elevados conocimientos de HTML y CSS ni tampoco saber programar, estos programas funcionan prácticamente con línea de tiempo y keyframes, y la interfaz es muy similar a la de Flash o la de editores de video de toda la vida como Premier, Final Cut, etc De momento la compatibilidad con navegadores de las animaciones que generamos mediante estos programas está soportada por los más modernos como Chrome, Safari, Firefox, etc. De las versiones antiguas de Internet Explorer ni hablamos a la hora de poder reproducir este tipo de animaciones.

Las herramientas más potentes que actualmente se encuentran en el mercado y hemos ido probando en los últimos meses son:

Adobe Edge animate

Es una herramienta de diseño interactivo y movimiento web que permite a los diseñadores introducir contenido animado en sitios web utilizando estándares web tales como HTML5, JavaScript y CSS3. A nuestro parecer es el más completo, fácil e intuitivo para aquellos que hemos trabajado alguna vez con Flash o editores de vídeo como Premier, Final Cut, etc.

Su precio es por suscripción mensual y existen versiones para Mac  y Windows.

Google web designer

Está en fase BETA y permite la creación de contenido animado en HTML5. Lo bueno que tiene es que es gratuito. Además, se pueden ajustar los estilos CSS y permite tocar código HTML y Javascript desde una ventana del mismo programa. Para exportar la animación, genera un código limpio y en su medida bastante bien estructurado. Por el lado negativo, hay que decir aún esta en beta y tiene algunos fallos a la hora de realizar animaciones de textos.

Su precio es gratuito y existen versiones para Mac  y Windows.

Tumult Hype

Es una de las herramientas más potentes que existen en el mercado. Solo disponible para Mac, es el software idóneo para gente que no tiene feeling con el mundo de la programación. Dispone de muchos recursos gratuitos que podemos utilizar para no dedicar mucho tiempo a nuestras animaciones. Destacamos de este programa su inspector, una de las partes más importantes de esta herramienta, desde la cual definimos muy fácilmente las propiedades de los elementos, acciones y eventos asociados (star/stop de escenas, clic, hover, etc).

Unas de las ventajas más llamativas de Hype es el control para gestos táctiles, la posibilidad de utilizar Google Fonts y la previsualización en directo vía Hype Reflect.

Esta aplicación únicamente está disponible para Mac, y su precio es de 49.99$. Desde su web oficial puedes descargar una versión de prueba de 30 días .

Sencha Animator

Esta es otra de las herramientas más completas que existen en el mercado y podría establecerse como el competidor directo de Hype. Es una de los más completas, y su forma de crear las animaciones es muy parecida a Adobe Edge y Hype. Desde esta herramienta, aparte de crear nuestras animaciones, podemos crear juegos, banners interactivos, etc. Lo que menos nos gusta de esta aplicación es su elevado precio y  los problemas a la hora de previsualizar cambios en las propiedades de los objetos en los diferentes puntos de la animación. Aquí tenéis una relación de clientes que trabajan con esta aplicación.

La aplicación está disponible para Windows, Mac y Linux a un precio de 199$. También ofrece una versión de prueba de 30 días descargable desde su web.

Conclusiones:

  • La mayoría de estos programas están enfocados a perfiles de diseñadores con algún tipo de conocimiento en HTML5, CSS3 o Javascript.
  • Se pueden llegar a crear animaciones más complejas con este tipo de programas, pero siempre teniendo conocimientos más amplios en JavaScript, sobre todo si queremos que nuestra animación, además de visual, sea interactiva con el usuario.
  • Todas estas aplicaciones ofrecen snippets que nos ayudan a generar nuestra animación en la que no tengamos que tocar nada de código.

Oculus oculi

Jue, 02/05/2015 - 17:48

Hace unas cuantas semanas nos dedicamos a investigar un poco con nuestra flamante Oculus Rift, a la cual incorporamos un Leap Motion. El engendro parecía sacado de un libro de Gibson, pero me lo puse en la cabeza y empecé a experimentar.

Lo que hicimos básicamente fue cargar un modelo 3D de nuestra oficina hecho con Unity y mediante el package de integración con Oculus lo hicimos funcionar. Los pasos que seguimos fueron los siguientes:

  1. Cargar un modelo 3D de nuestra oficinas en Unity.
  2. Instalamos dicho package de integración.
  3. Añadimos el Prefab OVRPlayerController a nuestra escena.

Voilà, con estos sencillos pasos ya teníamos una versión previa totalmente funcional en Unity. Inicialmente solo funcionaba con la versión de pago, pero en los últimos meses ya se puede utilizar con la versión gratuita.

El resultado de la visión con Oculus es realmente inmersivo. No obstante, aunque los requisitos para su funcionamiento no son especialmente exigentes según las especificaciones del producto: “running current generation 3D games at 1080p resolution at 75fps or higher”. Sí es cierto que en mi MBA se notaba bastante retardo en el movimiento y el número de fps no alcanzaba el mínimo para una experiencia perfecta.

En cuanto a la integración de Leap Motion, sí que hemos podido ejecutar algunos ejemplos que vienen en la página oficial de Leap, pero en cuanto a la integración con Unity no hemos conseguido resultados. La interacción entre los dos dispositivos está muy bien lograda, si bien requiere un aprendizaje previo hasta hacernos con el nuevo entorno.

Una última e importante cuestión es solucionar la sensación de mareo y desorientación después de un uso no excesivamente prolongado. Y creo que aquí está el verdadero reto. De los tres proyectos que actualmente se sitúan a la vanguardia y que pretenden ser competidores (si bien Samsung va de la mano de Oculus), al parecer ninguno de ellos ha conseguido aún solucionar este problema que va a ser determinante para el éxito del este tipo de productos.

 

Oculus Rift / Samsung Gear VR

Sony Morpheus

Enlaces de interés:

El oráculo hecho con un Arduino

Mar, 12/16/2014 - 18:20

Hace unos días se celebró FICOD (Feria Internacional de Contenidos Digitales), en la cual Tecnilógica tuvo un papel destacado por las distintas propuestas de innovación que mostró. En concreto, presentamos un proyecto en el que estábamos metidos desde hace algún tiempo. Se trata de un dispositivo de reconocimiento facial basado en Arduino y codificado con Processing. Para los “menos puestos”, Arduino es una plataforma de hardware libre consistente en una placa con un microprocesador y unos puertos de entrada/salida.

¿Qué elementos utilizamos para la realización de nuestro reconocimiento facial?

  • Placa Arduino Mega 2560
  • Sensor Shield V1.0
  • 2 Servos que harían la función de varillas
  • 1 Botón para sacar la foto
  • 1 Webcam

(Imagen: arduino.cc)

Durante la realización de las pruebas se nos quemó uno de los servos. ¡Horror! Bueno, no tanto. Gracias a este despiste nos dimos cuenta de que no se pueden tener conectados 2 servos a la placa si la fuente de energía es un cable USB conectado a un PC, así que para arreglar este desaguisado añadimos a la placa un shield al que conectar los 2 servos y el botón que sacaría la foto, además de una fuente de alimentación conectada a la red eléctrica.

¿En qué consiste esta locura?
A través de la webcam nos sacamos una foto y con Processing y el api de reconocimiento facial obtenemos nuestra edad, nuestro sexo, si tenemos los ojos cerrados, si estamos sonriendo o si llevamos gafas. ¡Lo que viene siendo un oráculo, vamos!

¡El oráculo se ha pasado tres pueblos con mi edad, así que dime cómo funciona!
La mecánica es simple. Una vez que te haces la foto, entra en acción Processing. La foto capturada se trata y se escala de la forma más realista posible para poder enviarla al api de reconocimiento facial, el cual tratará la foto y devolverá una serie de parámetros definidos.

Vale, y entonces, ¿cómo se mueven las varillas?
Aquí es cuando entra en acción el Arduino. Para mover las varillas tenemos que poner en comunicación los datos de Processing y Arduino. Esto es posible gracias al puerto serie.

Dentro de Processing tenemos que definir un puerto serie al que le enviaremos los datos que nos devuelve el api de reconocimiento. Para nuestro proyecto hemos usado los datos de la edad y del sexo. Hay que decir que al puerto serie se le pasa un carácter cada vez que queremos comunicarnos con el Arduino, para lo cual transformamos los datos de sexo y edad en caracteres entendibles por el Arduino.

Utilizamos los valores decimales de los números y las letras.
Por ejemplo: para el sexo transformamos el valor devuelto en 0 y 9. El 0 corresponde al sexo hombre y el 9 al sexo mujer. Para la edad, la transformación se hizo con el valor decimal de las letras y una escala predefinida.

En resumen, por el puerto serie estamos enviado, por ejemplo, los siguientes valores:

  • 0A
  • 0F
  • 9A
  • 9F

Para poder mover las varillas de los servos, debemos escribir un código a través del software del Arduino que esté escuchando a través del puerto serie lo que le estamos enviando. Lo que hace este código es transformar los valores que llegan de Processing en un ángulo X en cada uno de los servos para señalar el sexo y la edad que el api de reconocimiento facial nos ha devuelto.

Así pues, este es el experimento que hemos llevado a la feria, el cual ha sido todo un éxito.

Y recordad, ¡el oráculo no miente!

Tecnilógica en FICOD 2014

Vie, 12/12/2014 - 18:31

Los pasados días 2, 3 y 4 de diciembre tuvo lugar en el Palacio Municipal de Congresos de Madrid el Foro Internacional de Contenidos digitales (FICOD) 2014. En el evento se dieron cita empresas, emprendedores, inversores y estudiantes, todos ellos del sector audiovisual y tecnológico. Más de 4.000 personas interesadas por las nuevas tecnologías acudieron a la feria, donde encontraron decenas de expositores que mostraban lo más sobresaliente de su oferta. El impacto en las redes sociales, como era de esperar, fue protagonista durante la totalidad del evento, siendo #FICOD2014 trending topic en Twitter los tres días, logrando 70 millones de impactos. Asimismo, cerca de 20.000 internautas siguieron los distintos actos del evento por streaming.

Tecnilógica fue una de las empresas expositoras en el evento. El objetivo era mostrar material que reflejase las últimas acciones en innovación desarrolladas en nuestro seno. Así, por ejemplo, instalamos en el stand una aplicación de Smart TV desarrollada para una importante agencia de viajes. Dicha aplicación cuenta con un slider de imágenes con los destinos de esta empresa, así como información de las ciudades y precio de los vuelos. Para aumentar la experiencia de usuario, Tecnilógica ha incluido algunas interacciones con vídeos y envío de información al email del usuario, entre otras funcionalidades.

Por otro lado, Tecnilógica no podía dejar de mostrar su producto estrella en cuanto a cartelería digital: PosterDigital. Para ello colocamos un tótem compuesto por cuatro pantallas, el cual atraía hacia sí la mirada de nuestros visitantes según se acercaban a nuestro espacio. Aprovechando la versatilidad y la multifuncionalidad de PosterDigital, creamos varias interfaces adaptadas a los contenidos que creímos interesantes para el visitante de FICOD: agenda del evento, ejemplos de casos de éxito de Tecnilógica, el impacto de #FICOD2014 en Twitter, información meteorológica y otros datos prácticos.

Pero lo que llamó de verdad la atención, la auténtica sensación del stand, fue nuestro “juguete marciano”: el oráculo que adivinaba, tras presionar un botón rojo, diferentes datos sobre el usuario. Se trata de un dispositivo de reconocimiento facial construido a partir de un Arduino y codificado con Processing. Tecnilógica siempre se distingue por incluir en sus proyectos toda la innovación que surge del frikismo inherente a empresas como la nuestra, y el oráculo no es una excepción: lo que empieza como un cacharreo divertido terminará incorporándose a una solución real para un cliente. Este es el origen orgánico de la innovación que se promueve internamente: la participación común en esa generación de conocimiento.

La semana que viene, nuestro compañero Sergio Torres os contará con más detalle en un post del blog en qué consiste este “artefacto”, siempre desde un punto de vista más técnico.

También es importante destacar la charla que nuestro Ángel Barbero impartió dentro de la serie de ponencias, de y para profesionales, programadas en el evento: Always on: tu cliente está conectado. ¿Lo estás tú?. En ella, Barbero nos habló de la multicanalidad como concepto que debe informar la estrategia global de la empresa tecnológica. Asimismo, hizo un repaso por todos los factores de éxito a tener en cuenta en la implantación de esta mentalidad dentro de la empresa y cuál es su nivel de impacto interno en el producto, los procesos, las personas, la tecnología, etc. Aquí también os remito a un próximo post del autor de la charla en este blog, en el cual expondrá, entre otros conceptos, su visión sobre los múltiples contextos de interacción del usuario con la tecnología.

Como conclusión, y tratándose de un evento público de prestigio internacional como este, nuestro espíritu es el de estar siempre presentes para colaborar en la puesta en común de la tecnología que se está creando, al menos por nuestra parte. Además siempre es interesante participar en ferias en las que los visitantes están realmente interesados en los servicios que uno ofrece, como es el caso de este evento de contenido específico. La feria gira en torno al contenido digital, y Tecnilógica, a través de sus desarrollos, lleva a cabo precisamente eso en sus proyectos: hacer realidad esos contenidos por medio de la tecnología. Más allá de dedicarnos al desarrollo tecnológico, el contenido es algo que siempre está presente, ya que hay que reflejar en todo momento no sólo la forma sino el fondo que el cliente persigue, su puesta en valor, y ello hay que realizarlo bien sea a través de un dispositivo móvil como en una web, una gran pantalla o una smart TV.

Cómo afrontamos la crisis Shellshock

Mar, 09/30/2014 - 21:30

En los últimos días se ha producido bastante revuelo con una noticia acerca de un fallo de seguridad muy grave y que afecta a millones de ordenadores y dispositivos de todo el mundo. Os vamos a contar cómo lo hemos visto y nos/os hemos protegido desde Tecnilógica.

Empecemos por el principio: ¿qué es ShellShock? No es más que el nombre “comercial” de una serie de vulnerabilidades detectadas en un componente fundamental del sistema operativo de millones de ordenadores y dispositivos: el intérprete de comandos Bash. Este componente se puede encontrar tanto en servidores de alta gama de varios millones de euros como en los routers ADSL que cualquiera de nosotros tenemos en casa, en reproductores de Blu-ray, cámaras de vigilancia, teléfonos móviles, tablets, etc.

Desde que se hizo público, prácticamente todos los medios se han hecho eco de esta noticia debido a la gravedad del mismo, algunos de forma un tanto espectacular y grandilocuente:

- Shellshock: ‘Deadly serious’ new vulnerability found (BBC News)
- Shellshock: Panic at ‘worst ever computer bug’ sees governments race to protect critical infrastructure (The Independent)

Otros directamente han dejado de lado la realidad y se han lanzado a por el titular apocalíptico:

- Security experts are racing to destroy a virus called ‘ShellShock that’s targeting Apple computers (Business Insider)
Shellshock, el virus catastrófico (La Razón de San Luis)

En todo caso, una cosa es segura: los sysadmins de todo el mundo han pasado un fin de semana de lo más interesante.

Desde su descubrimiento, el pasado día 24 de septiembre por la tarde, se han publicado varios parches de seguridad que han ido solucionando las distintas formas descubiertas de usar ese fallo que podían comprometer un sistema y descargar software en él para después ejecutarlo y tomar el control de la máquina atacada, o para que esta sirva como puente para atacar a otras máquinas remotas, ocultando así la identidad del atacante.

Hay dos factores que amplifican enormemente la gravedad del fallo. En primer lugar, para los equipos que requieren un mantenimiento activo, tales como los servidores de internet, teléfonos o tablets, los parches de protección frente a este problema han estado disponibles desde los momentos iniciales de la crisis. No obstante, existen decenas de millones de dispositivos que no gozan de este mantenimiento y que son, y seguirán siendo por mucho tiempo, vulnerables a este fallo. El otro factor es la sencillez de la explotación del fallo y los distintos vectores de ataque. El más famoso hasta ahora y el primero que se empezó a usar es el de los navegadores web y las aplicaciones CGI, aunque se han hecho públicas otras formas de usar esta vulnerabilidad desde DNS, DHCP, email, SSH, etc. A ello se le suma la circunstancia de que no hace falta ser un ingeniero de sistemas ni un avezado hacker para poder comprometer un sistema: bastan unos sencillos comandos para conseguir que el sistema víctima ejecute los programas que deseemos.

Por ello, una de las perversas consecuencias de esta vulnerabilidad, prácticamente desde el día en que fue descubierta, es que ya se empezaran a detectar programas automáticos que escaneaban internet en busca de servidores vulnerables. Los servidores de Tecnilógica no fueron ajenos a estos intentos de ataque, aunque en todos los casos se toparon con servidores convenientemente actualizados y protegidos.

Gracias a nuestros sistemas de automatización de infraestructuras, pudimos actualizar el 90% de los equipos que mantenemos con solo una línea de comando, por lo que los parches se aplicaron tan solo unos minutos después de que estos fueran publicados por los desarrolladores. El resto de máquinas se actualizaron de forma manual tan solo unos minutos después.

Para una información más detallada, podéis realizar las siguientes consultas: CVE-2014-6271, CVE-2014-7169 y CVE-2014-7187.

Es de suponer que a partir de ahora habrá que estar preparado para que cada poco tiempo aparezca alguna noticia de un nuevo dispositivo, servidor o servicio que ha sido atacado con éxito debido a este problema. Entendemos que, en los próximos días, los distintos fabricantes de dispositivos sujetos a vulnerabilidad irán publicando actualizaciones para los sistemas afectados, por lo que habrá que estar pendiente para poner al día todo lo susceptible de contener Bash. No obstante, y como normal general, siempre es conveniente mantener los sistemas actualizados, ya sean servidores, equipos de sobremesa, teléfonos, etc… Este tipo de sucesos no hacen más que recordarnos la importancia de dicha política.

Y para acabar con algo que ayudará a la tranquilidad de muchas personas, si tu dispositivo conectado a internet depende de busybox (como algunos frigoríficos, lavadoras, routers, cafeteras, etc…), es casi seguro que no esté afectado por este fallo.

Gracias, UX Fighters

Mié, 09/24/2014 - 17:43

Como ya os contamos por las redes estas pasadas semanas, los días 13 y 14 de septiembre se celebró en el Matadero de Madrid la primera edición de UX Fighters, un punto de encuentro para profesionales y estudiantes del UX, empresas del sector tecnológico y demás personas vinculadas de alguna u otra forma a la experiencia de usuario, el diseño de producto y de servicio, y la innovación tecnológica.

Por la naturaleza y el calado del planteamiento del evento, Tecnilógica tuvo claro desde un principio que no podía faltar. Y no sólo como mero participante, sino como patrocinador. Nos parecía impensable no involucrarnos dando apoyo real a un encuentro en el que se dan cita todas las empresas clave del sector, y con quienes mantenemos una relación muy estrecha en el día a día, proyecto a proyecto, recogiendo el testigo de su trabajo y plasmándolo en el código.

Paso a paso, Tecnilógica se especializa cada vez más en seguir ofreciendo al cliente soluciones versátiles y multicanal, lo cual exige aportarle ese valor de UX y desarrollo como un discurso compacto, una única narrativa. Ese proceso lo llevamos a cabo a menudo de la mano de compañeros tan confiables y de tan larga y sólida trayectoria como, por ejemplo, Fjord y Designit, protagonistas, entre otros, de este encuentro.

Nuestro Ángel Barbero, dando paso a los ponentes de la mesa redonda “Las siguientes generaciones de usuarios: crear experiencias para niños y adolescentes”, patrocinada por Tecnilógica

¿Hemos obtenido lo que esperábamos de este evento? ¿Se han cumplido expectativas? Para responder a estas cuestiones, nos quedamos con un tuit de nuestro querido César Astudillo:

¿Había sitio para yet another evento de UX en España? Tras #UXF la preguunta se contesta sola.

— César Astudillo (@cesarastudillo) September 14, 2014

Nosotros somos de la misma opinión, por lo que sólo nos queda esperar, no sin cierta impaciencia, a la segunda edición del evento. Si la primera ha sido un éxito rotundo (¡#UXFighters fue TT en Madrid durante la celebración del derbi madrileño de fútbol!), la segunda romperá con toda seguridad las previsiones y las esperanzas que se pongan en ella. Queda más que demostrado que aún hay mucho espacio para este tipo de contenidos en Madrid, que los profesionales de este conjunto de disciplinas del diseño digital aún tienen mucho que decir (y que contarse unos a los otros, aun no siempre estando de acuerdo en todo), y que sirve también, de forma directa, de foro de comunicación entre séniors y júniors, y entre todos estos y las empresas, que tienen mucho que decir, ya que sin ellas, evidentemente, no hay proyectos en los que volcar todo este conocimiento.

Como conclusión, sentimos que estamos participando en algo positivo, constructivo, y que ya está mejorando y reforzando la calidad y la profesionalidad de los servicios de UX que se ofrecen en Madrid y en toda España. Nos enorgullece ser parte de este proceso de crecimiento, y precisamente por eso va desde aquí nuestro más sincero agradecimiento a todos aquellos que durante dos días han hecho posible todos estos conocimientos, todas estas historias compartidas y esa creación de comunidad que ha vertebrado UX Fighters. Gracias a todos los participantes, los profesionales (séniors y no tan séniors), los ponentes, los que han asistido a las charlas desde sus casas gracias al streaming… Pero sobre todo gracias a la organización, a Diga33!, y en especial a Luz y a Luis, quienes se han dejado la vida durante estas últimas semanas para que UX Fighters fuera una realidad.

Seguiremos contándonos historias en 2015. En la próxima edición de UX Fighters.

Swift a base de ejemplos: 2 – Teclado personalizado

Mié, 08/13/2014 - 15:58
Introducción

Una de las novedades de iOS 8 son las extensiones, unos módulos que amplían la funcionalidad de las aplicaciones: teclados personalizados, widgets en la vista “Hoy”, elementos que permiten almacenar en la nube sin usar iCloud, editar fotografías o compartir contenido… En la segunda entrega de “Swift a base de ejemplos” vamos a crear un teclado personalizado para indicar nuestro estado de ánimo con dos teclas: una para la flamenca y otra para la caca con ojos. El ejemplo está hecho en Xcode 6 beta 5 y el código final está disponible en nuestro repo de GitHub.

Creando la app

Apple no permite extensiones independientes: deben estar incrustadas dentro de una app, así que el primer paso es crear una app nueva, a la que añadiremos el teclado y, ya de paso, lo probaremos. Para ello, creamos un nuevo proyecto de tipo iOS > Application > Single View Application, ponemos como nombre swift_custom_keyboard, elegimos Swift como lenguaje e iPhone como dispositivo.

Como necesitamos probar el teclado, lo más sencillo es añadir un Text Field a Main.Stoyboard. Para centrarlo y que quede bonito, en el inspector de atributos del View Controller, cambiamos los campos “Size” y “Orientation” a “iPhone 3.5-inch” y “Portrait” respectivamente y centramos el Text Field a ojo, o bien no tocamos estos campos y añadimos unas constraints al campo de texto.

El teclado: primeros pasos

Con esto ya tenemos la aplicación. Ahora vamos a crear el teclado. Hay que definir un nuevo target, de tipo Custom Keyboard. La ruta para crearlo es File > New > Target > iOS > Application Extension > Custom Keyboard

Como Product Name indicamos FlamencacaKeyboard, como lenguaje, Swift y tanto en Project como en Embed in Application elegimos swift_custom_keyboard. Aparecerá una alerta preguntándonos  si queremos activar el esquema, le decimos que sí, y ya tenemos listo el esqueleto del teclado: un UIInputViewController al que añadir una vista.

El siguiente paso es crear una vista donde añadir las teclas: en el navegador de Xcode, dentro de la carpeta FlamencacaKeyboard, creamos un nuevo fichero de tipo View (File > New > File > iOS > User Interface > View) y lo llamamos KeyboardView.

Añadimos la vista al controlador. Para ello, en KeyboardViewController.swift, localizamos la función viewDidLoad() y justo a continuación de super.viewDidLoad() añadimos las siguientes líneas:

var views = NSBundle.mainBundle().loadNibNamed("KeyboardInterface", owner: self, options: nil) var keyboardView = views[0] as UIView self.view.addSubview(keyboardView) Instalación del teclado en el dispositivo

En este punto ya podemos comprobar que nuestro teclado funciona: seleccionamos como target “swift_custom_keyboard”, ejecutamos la app en el emulador o en el dispositivo, y salimos al Springboard. Allí seguimos la ruta Settings > General > Keyboard > Keyboards > Add New Keyboard… En el bloque “Third-party extensions” debería aparecer un teclado llamado “swift_custom_keyboard”.

Lo seleccionamos, volvemos a la aplicación y ya podemos utilizar nuestro teclado. De momento, lo único que aparece es el botón “Next Keyboard”, que es un botón que añade automáticamente Xcode y sin el cual no aprobarán la app.
Esta primera versión no es muy espectacular, pero al menos tenemos las vistas creadas y enlazadas. Vamos a seguir mejorando.

El teclado: ¡Ahora con más teclas!

Dentro de “KeyboardInterface.xib” redimensionamos la vista: de nuevo, podemos cambiar los campos “Size” y “Orientation” a “iPhone 3.5-inch” y “Portrait” o los dejamos como están y ponemos constraints a los botones. Creamos cuatro UIButtons: uno para la flamenca, otro para la caca, otro para borrar y otro para mejorar el aspecto del botón “Next Keyboard”

Además, en Placeholders > File’s Owner, abrimos el inspector de identidad e indicamos que la clase es de tipo KeyboardViewController. Así luego podremos asignar las acciones más cómodamente.
Si ejecutamos de nuevo la app, veremos que los botones ya aparecen. Antes de definir la interacción vamos a limpiar el código: borramos las funciones didReceiveMemoryWarning, textDidChange y textWillChange, la definición de nextKeyboardButton y todo el ladrillo de código que aparece en viewDidLoad() desde “// Perform custom UI setup here” hasta el final de la función.

Añadimos las funciones asociadas a cada botón (en un nada práctico pantallazo, ya que WP+ SyntaxHighlighter Evolved se lían con los emojis)

Y desde el KeyboardInterface.xib, creamos las conexiones de la manera tradicional, es decir, manteniendo pulsada la tecla ctrl, arrastramos desde el botón a la @IBAction correspondiente en KeyboardViewController.swift. El código es realmente sencillo: o bien vamos directamente al siguiente teclado utilizando una función proporcionada por Apple, o recogemos un proxy del texto e insertamos o borramos caracteres.

Últimos ajustes

Una vez que tenemos el teclado funcionando, podemos afinarlo un poco más. Por ejemplo, podemos ajustar la altura de la vista del teclado. Lamentablemente, hay un bug en la beta 5 y el ajuste no funciona. Esperemos que en la próxima revisión lo hayan arreglado. Lo que sí podemos hacer es mejorar los textos que acompañan al selector de teclado. Para ello, editamos el fichero de propiedades swift_custom_keyboard > Supporting Files > Info.plist y añadimos la siguiente entrada:

En el selector de teclados, Flamencaca aparecerá ahora como

Por ir terminando, que es tarde ya y estos señores se querrán ir a casa
  • iOS ofrece las funciones necesarias para pasar al siguiente teclado, insertar y borrar texto, pero no hay API para las mayúsculas automáticas, autocorrección, dictado… si las queremos ofrecer, las tendremos que programar de cero.
  • Un teclado personalizado no admite copiar, cortar ni pegar. Tampoco se pueden utilizar para escribir contraseñas: el sistema cambiará a un teclado estándar.
  • Si creamos un teclado personalizado, Apple nos obliga a incluir en él el botón “Next keyboard”. En otro caso, nos rechazarán la app.
  • Una aplicación puede impedir el uso de los teclados personalizados.
  • Los teclados personalizados usan un sandbox restrictivo para evitar el uso malicioso por parte de los desarrolladores. Se puede optar por uno más amplio, pero para ello hay que ceñirse a las App Store Review Guidelines.
  • El debug de las extensiones ha pasado de no funcionar en absoluto a funcionar mal. Hay que activarlo a mano y no ofrece todas las funcionalidades del debug de una app. Disponéis de más información al respecto aquí.
Bibliografía consultada

Trasteando con Google Glass

Mar, 07/22/2014 - 17:15

Hará más o menos un mes que nos hicimos con unas Google Glass en la oficina, el nuevo aparato de Google que, triunfe o no, va a significar que otras compañías también investiguen en esa línea, una línea muy interesante en la que la relación del usuario con el dispositivo es cada vez más natural. En esa relación se sintetizan las acciones para que con un par de palabras y dirigiendo nuestra vista algún punto tengamos a nuestro alcance multitud de funcionalidades como compartir una foto por chat o red social, añadirla a nuestro programa de gestión de tareas favorito, localizar el cajero automático más próximo, hacer una videollamada, saber cómo van nuestras acciones de Gowex… Un montón de posibilidades, que si bien ya están disponibles en los móviles, la naturalidad y sencillez con la que se llevan a cabo estas acciones en las Google Glass es lo que le dan un valor muy interesante. Aunque hacer que esto forme parte de nuestro día a día es algo a medio-largo plazo, hay ciertos perfiles para los que tendrán un gran valor y sin duda serán de gran utilidad. Todo esto tan bonito e idílico para el usuario final requiere bastante trabajo por parte del desarrollador, ya que Google, con su programa Explorer, ha dejado que sean los usuarios y, por ende, los desarrolladores, los que decidan para qué quieren utilizar las gafas. Por eso, aunque con cuentagotas, ha ido mostrando las formas en las que crear aplicaciones para las Google Glass, que es básicamente lo que pretendía contar en este post. A todos los desarrollos que tengan que ver con Glass se les llama Glassware, y se pueden llevar a cabo de dos maneras: a través del Mirror API, o con el propio GDK. Veamos qué significa todo esto. Mirror API: Podemos comunicarnos con las Glass a través de una API que ha habilitado Google a la que previamente el usuario ha tenido que dar permiso, como cuando se pide permiso a que una aplicación acceda a tu calendario de Google. Una vez hecho esto, la API nos permite publicar, modificar y eliminar tarjetas en el timeline de nuestras gafas para notificar los eventos que queramos. Estas tarjetas pueden contener imágenes o vídeos y se pueden maquetar con HTML+CSS, para personalizar nuestra notificación. He aquí un ejemplo de notificación con una imagen:

Tarjeta enviada con el playground de Google

Una opción con bastante potencial es la de suscribirnos a ciertos eventos que sucedan en las gafas, de tal manera que Google nos llama a un servicio que le digamos cuando un usuario cambia de localización, así podemos recomendarle los mejores restaurantes de la zona, tiendas con ofertas, curiosidades de una ciudad… lo que se nos ocurra. GDK: El Glass Development Kit nos permite acceder al hardware de las gafas, cámara, micrófono, sensores, gestos en la patilla… Supone una de las cosas más interesantes es la cámara, que no deja de ser lo mismo que se puede hacer con un teléfono, pero con la comodidad de que lo llevas encima. Con 2 o 3 palabras puedes escanear un código QR o ver qué cajero de tu entidad está más cerca, todo ello  sin tener que sacar el móvil del bolsillo. Para procesamiento de imágenes existe una librería llamada OpenCV, con la que se pueden llevar a cabo acciones tan interesantes como la detección y el reconocimiento facial o la detección de objetos. Con las Google Glass tendremos ese potencial en nuestras gafas.

Efecto canny con OpenCV

En cuanto a la política de uso, Google es estricto en cuanto a las cosas que no se pueden hacer. No viene mal darle un repaso cuando tengamos una idea rompedora si queremos que nuestra aplicación se publique por vías legales. En definitiva, las gafas están muy preparadas para compartir y comunicarnos con nuestros amigos a través de Google+ y  todo lo relacionado con Google. Se supone que, más adelante, cuando haya más aplicaciones, el abanico se vaya abriendo y nos permita algo parecido a lo que se puede hacer con los móviles Android en este sentido. Lo que está claro es que es un dispositivo muy personal; al fin y al cabo no dejan de ser una gafas, de ahí que todo gire en torno a Google+, aunque habrá que estar al tanto para ver cómo evoluciona. En Tecnilógica seguimos investigando y contándoos nuestras experiencias. Podéis visitar el perfil de Google+ que hemos habilitado para compartir los experimentos que vayamos realizando.

Tecnilógica at the DDays

Mié, 07/16/2014 - 13:51

Last May 19 and 20, Tecnilógica took part in the Digitisation Days, an event held at the National Library of Spain (BNE), in which techniques, tools and studies set aside for the digitisation of the cultural heritage were discussed.

The invitation to take part in this event came as a result of the Commendation of Merits awarded to Tecnilógica at the 1st Succeed Awards, which were attended by nearly twenty public and private institutions from all around the world. This conference was attended, among others, by Mario Vargas Llosa, Nobel Prize for Literature in 2010. Besides, in this two-day event, congresses and exhibitions about digitisation technologies and panel discussions were held, gathering experts from all five continents. 

The rest of the winners in the contest were the Hill Museum & Manuscript Library (based in Saint John’s University, Collegeville, USA) and the Centre for Advanced Renaissance Studies (Tours, France). Along with Tecnilógica, the other Commendation of Merits went to the London Metropolitan Archives.
Along with the Succeed project (led by the University of Alicante), the Digitisation Days have been organized by the IMPACT Centre of Competence in Digitisation, run by the Miguel de Cervantes Virtual Library Foundation, which comprises thirty-six institutions and companies, including the National Library of Spain.

It was precisely with the BNE with whom we started the project that has led us to this Commendation of Merits. We have previously told you about our project of digitisation of perforated discs, which we have carried out for almost two years in collaboration with the BNE. The origin of this project dates back to a visit from our colleagues Juan Alonso and Juan Antonio Casado to the sound and audiovisual archives of BNE, invited by José Carlos Gosálvez Lara, Music and Audiovisual Manager for the BNE. Through this guided tour they were delighted with said discs, and Gosálvez expressed his concern that those formats were to be forgotten, given the apparent impossibility to register their content permanently and in a long-lasting manner. Back at Tecnilógica’s premises, and from a photograph that one of our colleagues had taken from one of the discs, we rolled up our sleeves and started working on the creation of software capable of encoding the information contained in those media and moving it to a system of digitally readable notation. You can look up the whole process, as well as the technical details of the technology developed, in these two posts from our blog: I and II. Over the following months and backed by the BNE, Tecnilógica developed this technology, which has restored and saved for posterity the sounds of dozens of albums of public records.

Why does Tecnilógica embark on projects like this one, which a priori do not provide a tangible profit? It’s all about our chosen business paradigm. At first glance, this model of R&D may seem altruistic, but it’s not really “free” in any sense. We are generating something that every technology company should aim to create: knowledge. Knowledge that has produced results both for an audience of users of BNE’s sound files and for the company as an internal asset. Knowledge as an asset in the sense of corporate exploitation at the service of future projects that take Tecnilógica always a step further, to the point where we are always creating value every time we work for a client.

In this case, the Commendation of Merits recognizes a way of doing things, a philosophy that fills all the company levels. Without this philosophy, the basis on which the eleven-year evolution of Tecnilógica sits on is hardly understandable. In this case, we have reached the point of contributing to the country’s culture, but our goals are not always so ambitious… This approach to knowledge management and future profit is not only circumscribed to Tecnilógica’s environment, but open to any proposal of collaboration. On our part, any formula of partnership with anyone working on what at first sight might seem difficult is welcome, provided there is a possibility of generating knowledge that may result in a future profit for all parties in some form or another. With the BNE, the story began with a photo of a cardboard disc from the 19th Century. Who knows how the next one will start.

Aplicaciones móviles “ultranativas”

Lun, 06/23/2014 - 16:44

A la hora de afrontar un desarrollo móvil siempre surge la disyuntiva de elegir entre nativa o usar un framework que nos genere unos binarios para cada plataforma, habiendo desarrollado en un único lenguaje común. Estos frameworks, aunque cada vez más populares, no terminan de despegar o no tienen tanto éxito ya que pueden limitar un diseño que quiera marcar la diferencia o no conseguir una experiencia de usuario totalmente natural. Para solventar esto están apareciendo cosas bastante interesantes como Famo.us, un framework que nos ofrece una experiencia y animaciones muy fluidas, consiguiendo que nos olvidemos de que es una página web. Pero imaginemos que necesitamos o queremos una aplicación nativa, con un modelo de datos muy sólido. Si queremos hacer la aplicación para Android/iOS, tendríamos que implementar ese modelo de datos en ambas plataformas, haciendo dos veces el mismo trabajo (En eso consisten las aplicaciones nativas, en hacer la aplicación tantas veces como plataformas se quieran abarcar). Aquí es donde tendríamos la posibilidad de hacer un desarrollo común a todas las plataformas, ¿cómo?, programando un núcleo en C++ y que se comunique con los UIs, estos sí, cada uno de su padre y de su madre. Esto es lo que han hecho los chicos de Dropbox (ver), ahorrándose de esta manera los desarrollos y bugs del modelo de datos de cada plataforma, centrándose únicamente en un sólo desarrollo a la hora de afrontar estos problemas. Un desarrollo de este tipo podría valernos para las plataformas que podamos comunicar con un desarrollo escrito en C++, esto podría incluir perfectamente una aplicación escritorio escrita en QT por ejemplo, o incluso yendo más allá, podríamos hacer un núcleo que nos valiese para que nuestro lenguaje favorito de servidor (PHP, Ruby, Python…) se comunique con el modelo de datos que es el que accedería a la BBDD. Normalmente, en cuanto a dispositivos móviles se refiere, C++ se usa para los desarrollos que necesitan resolver algoritmos muy rápidamente, como puede ser un sistema de partículas en un videojuego o el cálculo de físicas, aunque como hemos visto también podemos aprovecharnos de la universalidad del lenguaje para hacer otro tipo de desarrollos, siempre que sea para hacernos la vida más fácil.   ¿Aprender C++ a estas alturas? A pesar de tener más de 30 años, C++ se sigue usando en multitud de aplicaciones al ser un lenguaje de medio nivel (esto es, alto y bajo nivel a la vez, por lo que nos ofrece mucha potencia y versatibilidad). Es un lenguaje en el que se pueden delegar algoritmos que necesitamos que se ejecuten muy rápidamente. Los actuales lenguajes de referencia en el desarrollo web , Java y Visual C#, beben directamente de C y C++, por lo que la sintaxis no debería ser gran problema, así como la semántica si estamos acostumbrados a trabajar con lenguajes de tipo estructurado o bien orientados a objetos. Si no conocemos estos lenguajes, el hecho de aprender C++ nos facilitaría el posterior entendimiento de estos. Para desarrollar aplicaciones de escritorio en un único lenguaje y exportarlas a los diferentes sistemas operativos nos podríamos valer de QT o Mono, frameworks que nos permiten desarrollar en C++ o ligeras variaciones de este, y que nos permitirían un único desarrollo exportable a varias plataformas   Aplicaciones desarrolladas en C++:

  • Windows (Visual C++, evolución de C++)
  • Algunas partes de OS X
  • MongoDB
  • MySQL

Más aplicaciones hechas en C++: http://www.stroustrup.com/applications.html

Nuestro paso por los DDays

Mié, 06/18/2014 - 21:54

Los pasados 19 y 20 de mayo, Tecnilógica participó en los Digitisation Days, un evento celebrado en la Biblioteca Nacional de España, en el que se debatió sobre las técnicas, las herramientas y los estudios destinados a la digitalización del patrimonio cultural.

La invitación a participar en dicho evento se produjo como consecuencia de la mención honorífica recibida por Tecnilógica en los I Premios Succeed, a los que concurrieron casi una veintena de instituciones públicas y privadas de todo el mundo. En estas jornadas se contó con la presencia, entre otras personalidades, de Mario Vargas Llosa, premio Nobel de Literatura en 2010. Asimismo, en este evento de dos días se celebraron congresos, muestras sobre tecnologías de digitalización y paneles de debate a los que acudieron expertos venidos de los cinco continentes. 

El resto de galardonados en el certamen fueron el Hill Museum & Manuscript Library (con sede en la Universidad de Saint John’s, Collegeville, EE UU) y el Centro de Estudios Superiores del Renacimiento (Tours, Francia). Junto con Tecnilógica, la otra mención honorífica recayó en el Archivo Metropolitano de Londres. Junto con el proyecto Succeed (liderado por la Universidad de Alicante), los Digitisation Days han sido organizados por el Centro de Competencia en Digitalización Impact, el cual está dirigido por la Fundación Biblioteca Virtual Miguel de Cervantes, del que forman parte treinta y seis instituciones y empresas, entre otras la Biblioteca Nacional de España.

Fue precisamente con la BNE con quien se fraguó el proyecto que ha cristalizado en dicha mención honorífica. Ya os hemos hablado anteriormente de nuestro proyecto de digitalización de discos perforados, que hemos llevado a cabo durante casi dos años en colaboración con la BNE. El origen de este proyecto se remonta a una visita de nuestros compañeros Juan Alonso y Juan Antonio Casado a los archivos sonoros y audiovisuales de la BNE, quienes acudieron por invitación de José Carlos Gosálvez Lara, Director del Departamento de Música y Audiovisuales de la BNE. En este paseo guiado se recrearon en dichos discos y Gosálvez expresó su inquietud por que esos formatos fueran a quedar olvidados, dada la aparente imposibilidad de registrar su contenido de forma permanente y perdurable. Ya en la oficina de Tecnilógica, a partir de una fotografía que uno de nuestros compañeros había tomado de uno de los discos, nos pusimos manos a la obra y empezamos a trabajar en la generación de un software capaz de codificar la información contenida en esos soportes y trasladarla a un sistema de notación legible digitalmente. Podéis consultar los pormenores de dicho proceso así como los detalles técnicos de la tecnología desarrollada en estos dos posts de nuestro blog: I y II. A lo largo de los siguientes meses y con el respaldo de la Biblioteca Nacional, Tecnilógica desarrolló esta tecnología, que ha permitido recuperar y guardar para la posteridad sonidos de decenas de discos del archivo público.

¿Por qué Tecnilógica se embarca en proyectos como éste, que a priori no aportan un beneficio tangible? Todo es cuestión del paradigma de negocio escogido. A simple vista,  este modelo de I+D puede parecer altruista, pero en realidad no es “gratuito” en ningún sentido. Generamos algo que toda empresa tecnológica debería aspirar a generar: conocimiento. Un conocimiento cuyos resultados ya se han difundido para el público usuario de los archivos sonoros de la BNE. Conocimiento también como activo interno, de aprovechamiento corporativo al servicio de futuros proyectos que impulsan a Tecnilógica siempre un peldaño más arriba, hasta ese punto en el que constantemente creamos valor cuando trabajamos para un cliente. En este caso, la mención honorífica sirve para reconocer una forma de hacer las cosas, una filosofía que informa todas las capas de la empresa y sin la cual no se entiende la base sobre la que se asienta la trayectoria de casi once años de Tecnilógica.

En este caso hemos llegado hasta el punto de contribuir a la cultura del país, aunque no siempre nuestros objetivos son tan ambiciosos… Esta forma de enfocar la gestión del conocimiento y del futuro beneficio no sólo la circunscribimos al entorno de Tecnilógica, sino que estamos abiertos a cualquier propuesta de colaboración. Por nuestra parte es bienvenida cualquier fórmula de partnership con quien quiera trabajar en lo que a priori parezca difícil, siempre y cuando haya una posibilidad de generar conocimiento que redunde en un beneficio futuro para todas las partes de alguna u otra forma. Con la BNE, la historia comenzó con una foto a un disco de cartón del siglo XIX. Quién sabe cómo empezará la siguiente.

Swift a base de ejemplos: 1 – El juego de la vida de Conway

Mié, 06/11/2014 - 15:35

Con este artículo comenzamos una pequeña serie de tutoriales titulada “Swift a base de ejemplos”. En vez de describir las características del lenguaje, queremos presentar pequeñas aplicaciones que hagan cosas (aunque sean pocas) y explicar qué problemas hemos encontrado.

Como primera aplicación, hemos optado por implementar el Juego de la vida, de Conway. No utiliza el lenguaje en todo su esplendor, pero nos vale para remojar un poco el pie en la piscina y saber de qué va la cosa. El Juego de la vida es una aplicación “Single View” compuesta de los siguientes elementos:

La clase Life, que es una subclase de UIView, y representa el tablero. Ahí se define el tamaño del tablero -que depende del tamaño del dispositivo-, el tamaño de cada celda y el mundo, como array de Int8. También definimos un reloj de tipo NSTimer y una variable auxiliar que indica si el mundo está corriendo o detenido.

Como vamos a añadir la vista directamente al storyboard (en vez de hacerlo pro programación), necesitamos el init con un NSCoder! . En ese init inicializamos las propiedades, llamamos al super.init y rellenamos el mundo al azar.

Algunas peculiaridades:

  • Hay que importar UIKit para manejar la clase UIView, y QuartzCore para llamar a CACurrentMediaTime() y sacar una traza del tiempo empleado en calcular cada generación.
  • Para calcular el alto de la pantalla, usamos UIScreen.mainScreen().bounds.height.
  • Para obtener números aletarios, usamos arc4random(), como en ObjectiveC.
  • En el método changeWorldStatus hay un ejemplo de cómo crear e invalidar un NSTimer.
  • En el método drawRect repintamos el canvas, obteniendo el contexto y dibujando las celdas.

Nota para los puristas: el algoritmo que calcula cada generación es el original, sin ningún tipo de optimización.

El storyboard contiene dos elementos: un botón para arrancar y detener los cálculos y una UIView de tipo Life

El ViewController tiene un outlet al UIView Life, para poder arrancar y parar el cálculo de generaciones con el botón incluido en el storyboard. Ya de paso, detectamos el “shake” del dispositivo haciendo un override del método motionEnded y comprobando que el movimiento es de tipo UIEventSubtype.MotionShake.

El código de la aplicación está disponible en https://github.com/tecnilogica/learningswiftwithtecni, donde iremos publicando otros ejemplos.

Web Components. La siguiente revolución tecnológica

Mié, 03/12/2014 - 00:58

Cuando ya parecía que nos habíamos acostumbrado al nuevo paradigma de aplicaciones web basado en JS pesado y frameworks MVC en cliente, resulta que aparece una nueva (realmente no tan nueva) forma de hacer las cosas: Web Components.

¿Qué son los Web Components?

Web Components are a collection of standards which are working their way through the W3C. Discover how this new concept formed by Templates, Decorators, Shadow DOM, Custom Elements, and HTML Imports will revolutionize the way we develop and interact on the web.

Zeno Rocha - vía WebComponents.org

El principio es muy sencillo: todo es un componente, y como tal puede invocarse declarativamente. La idea principal es que la complejidad ya no la tiene la programación de la aplicación sino cada uno de los componentes que la forman, no tenemos ni M, ni V, ni C sino unos componentes que, como por ejemplo la etiqueta <input>, saben lo que hacer en cada momento. En este aspecto estamos más cerca del paradigma de Custom Tags de Java que de los includes de PHP.

A la sombra del borrador de Web Componentes del W3C han ido apareciendo nuevos frameworks y librerías que utilizan este paradigma como base. Aparecen nuevos conceptos como Shadow DOM o Virtual DOM y debemos aprender a vivir con ellos dado que suponen cambios muy significativos en la forma en que se harán las cosas.

Y es que Javascript sigue buscando su estilo. Recordemos que aunque es una lenguaje con cierta solera no es hasta hace unos años cuando se ha empezado a usar intensivamente. La mejora y estandarización de los navegadores y la aparición de nodejs  ha dado un salto cualitativo en la forma de hacer las cosas y es ahora cuando estamos viviendo esta revolución.

Estos son los principales frameworks/librerías que han surgido (¡y estamos empezando!) a raíz de esta nueva vuelta de tuerca al desarrollo de aplicaciones web pesadas:

1. Polymer: Es un polyfill de Google que implementa la especificación de Web Components. Ya dispone de una amplia comunidad y gran cantidad de elementos disponibles.

2. X-tag: Es el proyecto de Mozilla para Web Components. Al estar basado en la especificación del polyfill de Polymer, si bien no está directamente asociado al proyecto,  es posible usar elementos de X-tag dentro de elementos Polymer.

3. React: Bajo el soporte de Facebook, React propone una forma un tanto diferente de construir componentes completamente encapsulados (y en algún caso con cierto engorro en su desarrollo). Pero los resultados son realmente asombrosos. La forma en la que se invocan los componentes no es exactamente declarativa pero recuerda mucho. Aunque esto se aleja de la especificación de W3C de Web Components me parece interesante ponerlo aquí. Incluso podemos hacer que convivan como ha hecho Vjeux en un experimento.

Sin duda estas nuevas tecnologías de desarrollo están aquí para quedarse, no creo que sustituyan a la vieja y buena manera de hacer las cosas (MVC) pero ciertamente van a  suponer una nueva nueva revolución y darán que hablar.

Por otra parte y haciendo un poco de abuelo Cebolleta, recuerdo que hace más de 7 años en la empresa donde trabajaba ya teníamos un catálogo de componentes Javascript completamente encapsulados que sabían qué hacer en cada momento y que se invocaban de forma declarativa. Posteriormente se utilizó Rhino para poder ejecutar este Javascript en servidor…. y bueno, yo estoy volviendo a vivir todo esto, pero eso sí con una comunidad mucho más amplia y una nueva manera de hacer (bien) las cosas.

La empatía

Mar, 03/04/2014 - 22:49

En este preciso instante, en alguna parte del mundo, estoy segura de que alguien está escribiendo su currículo y poniendo en la sección “Habilidades”: “facilidad para trabajar en equipo”. Todos lo hemos hecho. En el papel, supuestamente, todos estamos preparadísimos para trabajar en coordinación con otros, pero… ¿hasta qué punto es verdad?

Hace unas semanas en el 04×10, que se celebra todos los meses en Madrid, di una charla sobre los problemas de comunicación que a veces existen entre diseñadores y desarrolladores. Problemas que también darían para otra charla a la inversa: ¿hasta qué punto los desarrolladores van a favor de obra? ¿Hasta qué punto ven que las ideas de los diseñadores no son peregrinas y que, generalmente, cada cambio tiene una razón…?

A final de cuentas, un factor que hará que nuestros proyectos salgan adelante con mayor o menor éxito es la capacidad de empatía que tengamos. Suena hippie, lo sé, pero está claro que en desarrollo web cuánto más conscientes seamos de las necesidades de la persona que va a recibir lo que hemos diseñado, más fácil será su trabajo. Si somos capaces de ponernos en el lugar del otro (y viceversa), desarrollar productos sólidos y eficientes será bastante más fácil. Trabajo en equipo de verdad.

Lo mejor de esta idea es que parece que se está poniendo de moda. Hace poco menos de una semana ha surgido Lifetramp una red social que permite a sus usuarios ser la sombra de un diseñador, un desarrollador, un artesano o lo que busques durante un día. De esta manera, cualquier persona será capaz de realmente vivir cómo es el trabajo de otras personas y decidir si quiere trabajar de eso, aprender ese oficio o simplemente saciar su curiosidad.

Cada vez se impone más la idea de que, por más que juegues de 9, para meter goles no está mal saber cómo piensa un portero. Y viceversa.

El penoso estado digital de la Administración

Mié, 02/12/2014 - 17:16

Estos días, tras tener que hacer una serie de trámites online, he estado pensando en cómo está la presencia online de la Administración y, sinceramente, es para echarse a llorar.

Tenemos, por ejemplo, al registrador de .es enviando contraseñas en texto plano. Esto demuestra por una parte que están guardando las contraseñas de los usuarios en base de datos, no un hash. A estas alturas, en 2014. Lo cual, a su vez, evidencia una total falta de respeto por las normas más básicas de seguridad y buenas prácticas por parte de, ni más ni menos, el responsable de que cuando pones algo terminado en .es en tu navegador te lleve a donde quieres ir y no a cualquier otro sitio:

Claro que hay cosas más divertidas. A lo mejor no eres usuario de Windows, puede que seas un loco usuario de otros sistemas operativos “experimentales” como, no sé, MacOS X, iOS, Ubuntu… Pues bien, las webs de los organismos oficiales en España (dominios.es, o también madrid.org o la del Ministerio de Hacienda utilizan el certificado raíz de la FNMT y este organismo no se ha molestado en asegurarse de pasar el proceso de auditoría de navegadores como Chrome en estos sistemas operativos. No pasa nada, porque los usuarios de  sistemas operativos distintos a Windows ya sabemos que somos ciudadanos de segunda, gracias a la proverbial tozudez de nuestra Administración de no seguir un estándar ni aunque los estén ahogando, así que podemos ir a bajarnos el certificado raíz de la FNMT a su web e instalarlo en nuestro sistema operativo. El problema es que la web desde la que podemos bajar estos certificados está firmada, a su vez con el propio certificado raíz que queremos bajar (o sea, está autofirmada), cosa que puede hacer cualquiera, montando un ataque man-in-the-middle. Dicho de otra forma, no podemos bajarnos el certificado de la FNMT sin comprometer la seguridad de nuestro ordenador. Estupendo todo.

Por cierto, para acceder a la página de descarga del certificado, he preferido buscar en google que navegar por la web de la FNTM, porque la navegación en las webs de la Administración es tan mala que llegar al contenido que buscas parece más cuestión de suerte.

Por terminar por hoy, supongamos que eres un ciudadano de primera, con tu Windows actualizado y fiel usuario de Internet Explorer, en el que tienes instalados tus certificados, y decides montar tu negocio online. Vas a dominios.es y registras un nombre estupendo, no sé, prosa.es. Luego te pasas un par de años montando tu tienda de ebooks. Contratas a una buena empresa de desarrollo, gestionas una comunidad, te gastas un buen dinero en SEO y SEM… Cuando el negocio empieza a ir bien, tras muchos días de trabajar hasta las tantas, el Gobierno, en su infinita sabiduría, decide fundar el Patronato Regional de Ondas Sacras de Andalucía, declara que prosa.es es de interés general y te lo quitan. De un día para otro. Esto fue lo que le pasó a la empresa textil que era la registradora de sareb.es cuando se puso en marcha el banco malo. Y sí, es legal y nueva muestra de la falta de previsión y ceguera de la Administración hacia los más elementales estándares de funcionamiento, conducta y buenas prácticas en Internet.

Dan ganas de irse a vivir a Estonia.

Me enamoré de un robot

Lun, 01/20/2014 - 19:24

Este artículo es una adaptación de la charla “Me enamoré de un robot – Migración de aplicaciones iOS a Android” dada en DroidCon Spain el 10 de diciembre de 2013.

Me enamoré de un robot
Este artículo no pretende ser técnico. No tratará de frameworks, metodologías, librerías, stacks, fragmentos sino de la evolución del mercado de aplicaciones móviles.

A lo largo del último año, en Tecnilógica hemos visto cambiar el mercado de las apps. Los clientes demandan cada vez más aplicaciones Android que quieren desarrollar a la vez o en vez de la correspondiente aplicación iOS. Queremos mostrar diferentes argumentos que nos ayudarán a animar a nuestros clientes a potenciar esta tendencia, desarrollando primero la aplicación Android o, al menos, poder desarrollar las diferentes versiones simultáneamente.

No pretendemos avivar el fuego entre ambas plataformas. Tanto iOS como Android tienen unos aspectos que las hacen muy atractivas, así como en otros campos se quedan un poco cojas y hay espacio para la mejora. Curiosamente, parte de las ventajas y desventajas de cada plataforma viene de la filosofía “sistema abierto / sistema cerrado” que aplican a rajatabla, hasta las últimas consecuencias.

Primero para iOS
Hasta hace unos meses, cuando un cliente nos solicitaba desarrollar una aplicación, siempre empezaba por la versión iOS y si la cosa iba bien o le quedaba algo de presupuesto, a veces se animaba a hacer la aplicación Android.

No es habitual que el cliente conozca de primera mano el mercado, y en muchas ocasiones se rige por un conocimiento que puede resultar incompleto o sesgado. Así, el cliente escucha afirmaciones como que “el dinero está en iOS” o que “desarrollar una aplicación para Android es mucho más complicado” y no va más allá.

Es cierto que hay más dinero en iTunes: se calcula que cerca de dos veces y media más, pero, por otro lado Google Play está creciendo mucho más rápido. Y, respecto a las herramientas, es verdad que hasta hace muy poco tiempo el desarrollo en Android era bastante infernal, pero las herramientas han madurado mucho, facilitando las tareas de desarrollo y testing.

Otro factor a tener en cuenta, que trataremos más adelante, es el tipo de mercado en el que estamos. El cliente, cuando se informa, no siempre se da cuenta de que la información que le llega no tiene porqué servir para el mercado europeo o español, donde las condiciones son diferentes.

Estadísticas
Los clientes quieren apostar sobre seguro y para ello, lo primero que hacen es consultar cifras. Lamentablemente, hay una guerra tremenda de cifras así como multitud de estudios con resultados dispares: unos comparan el market share; otros, el número de teléfonos en uso… lo que nos lleva a preguntarnos si sirven de algo estos datos. Como referencia son útiles, pero conviene manejarlos con precaución, ya que frecuentemente nos dan una imagen de la realidad sesgada o incompleta. ¿Qué beneficios se obtiene con cada venta? ¿Qué dispositivos se están comparando? ¿Qué porcentaje de dispositivos está en uso?

Las cifras que se manejan en España es de tres terminales Android por cada terminal iPhone. A nivel mundial, diferentes estudios hablan de mil millones de terminales Android frente a setecientos millones de terminales iOS. Son unas cifras lo suficientemente importantes para presentarlas al cliente y aportarle una visión más amplia de la situación.

Filosofía: abierto y cerrado
Resulta curioso que lo que para nosotros es uno de los puntos fuertes de la plataforma Android, los clientes lo perciben a veces como una debilidad. Nos referimos al sistema abierto, que a veces es percibido como el salvaje Oeste, una plataforma sin ley donde, en cuanto te descuides, te has instalado un programa con malware. Y lo que es peor, a veces Android es el mayor enemigo de sí mismo:

  • Android, al ser un sistema operativo abierto, permite su distribución a las operadoras de telefonía. Así, los usuarios no tendrán que esperar por sobrecarga de los servidores cuando aparece una versión nueva del sistema operativo. Sin embargo, hay veces que las operadoras tardan en distribuir la versión nueva, o es una versión modificada con funcionalidad diferentes.
    Al ser fácilmente modificable, se da el caso de que los sistemas operativos se hacen la competencia entre ellos mismos: los diferentes “flavours” de Android compiten entre ellos. Esta situación peculiar no se da en un sistema cerrado, donde la experiencia resulta mucho más consistente.
  • Se ofrece una mayor variedad de hardware, lo que permite producir modelos muy personalizados. Como contrapartida, aparece una fragmentación que no existe cuando el hardware está controlado.
  • El proceso de aprobación de aplicaciones es prácticamente inexistente, lo que permite subir aplicaciones a la tienda en apenas una hora. Sin embargo, esto permite que programadores poco escrupulosos puedan subir aplicaciones que no hacen lo que dicen, con la posibilidad de encontrare con malware o un troyano.

Esta situación, la oposición entre sistemas abiertos y cerrados, no es nueva en absoluto. Un ejemplo equivalente ocurre en el mundo de los videojuegos: ¿qué es mejor, una consola cerrada y propietaria, con un sistema de aprobación de juegos estricto, o un sistema abierto, tipo PC, donde cualquiera puede vender su juego, independientemente de su calidad?

Hardware
Vamos a ver en detalle algunos de estos puntos. El primero de ellos es el hardware. Se estima que hay más de doce mil dispositivos Android diferentes, entre teléfonos, relojes, tabletas, lectores de ebooks y televisores. Por el contrario, el número de dispositivos iOS no va más allá de una docena. Esto hace que inicialmente sea más sencillo desarrollar para iOS: la variación de funcionalidad es mucho menor.

Sistema operativo
Entre los círculos técnicos, en cuanto sale una versión nueva del sistema operativo, corremos a instalarla. Sin embargo, un usuario estándar no está al tanto de las novedades, y actualiza el sistema operativo con mucha menos frecuencia.

En el caso de iOS, una vez estabilizado el sistema operativo, aproximadamente un noventa y seis por ciento de usuarios lo han instalado en sus dispositivos. Así, pasado cierto tiempo, podemos permitirnos abandonar la versión anterior sin graves repercusiones. Actualmente, cuatro meses después de la salida de iOS7, ya lo ha instalado un ochenta por ciento de usuarios.

Por el contrario, en el caso de Android, la tasa de actualización es mucho menor: aproximadamente un treinta y tres por ciento de los usuarios están usando la versión más reciente del sistema operativo, otro treinta y tres la anterior, y el resto, una versión dos iteraciones por detrás. Esta fragmentación dificulta la tarea de los programadores, y a su vez, potencia la idea de dificultad y complejidad del entorno Android.

Mercados
Como comentábamos antes, otro reto al que debemos enfrentarnos es desechar la información no pertinente, educando al cliente. Las noticias más espectaculares suelen venir de EE.UU., un mercado muy diferente del europeo y del español. Pero, lamentablemente, el cliente no suele filtrar esa información, por lo que tiende a malinterpretarla.

Software
Estos tres ejemplos muestran la diferencia entre mercados:

  • Instagram – empresa estadounidense – empleó dieciocho meses en tener disponible una versión para Android. Lamentablemente, esa es la información que recibe el cliente: han hecho primero una versión iOS y han tardado dieciocho meses en tener la de Android. Sin embargo, pocos saben que en las primeras veinticuatro horas la aplicación tuvo un millón de descargas en Google Play.
  • Vine – también estadounidense – empezó también como iOS y seis meses después sacó al mercado la versión Android.
  • King – empresa europea – lanzó la primera versión de Candy Crush Saga para Facebook y siete meses después, simultáneamente, lanzó la versión móvil para ambas plataformas.

Primero para Android
A pesar todo lo indicado anteriormente, Android tiene una serie de ventajas que le convierten en una primera opción totalmente viable, y que debemos recalcar al cliente, para que pierda el miedo:

  • El gran número de dispositivos vendidos (diez a siete en el mundo, tres a uno en España) lo convierten en una plataforma con una base de usuario muy amplia.
  • La curva de aprendizaje es menor, por lo que cuesta menos formar a un programador.
  • Las herramientas de desarrollo han mejorado enormemente.
  • La UI ha madurado en los dos últimos años, acortando distancias con iOS en unos aspectos, superándole en otros.

Filosofía (II): principios de diseño
Esta madurez de la UI, así como el cuidado por el detalle permite un acercamiento a ambas plataformas. Si leemos las recomendaciones de diseño, nos daremos cuenta de que, con distintos nombres, se buscan metas comunes: que el usuario disfrute usando el dispositivo, que vea sólo la información relevante, pero que se pueda acceder a la totalidad de la misma en caso necesario, que se utilicen atajos consistentes en todas las aplicaciones, que simplifique nuestra vida, que ayude a tomar decisiones…

Migración o adaptación
Hasta aquí hemos analizado la situación actual: dónde estamos y por qué. ¿Qué podemos hacer para ir cambiando la situación? Vamos a ver los pasos más habituales que se suelen dar en un desarrollo y cómo se pueden adaptar para conseguir una aplicación de tanta o más calidad que la aplicación iOS.

UX
El primer paso es el diseño del producto digital. Si estamos adaptando una aplicación de iOS, hay que tener presente las diferencias entre ambas plataformas.

  • Simplicidad. Si una operación que en iOS se se hace en dos gestos necesita siete en Android, es que esa operación no es adecuada. En vez de replicarla y complicar innecesariamente la interacción, es mejor sustituirla por otra que sea más sencilla.
  • Hay que tener en cuenta las diferencias de navegación y las interacciones. No hay que imitar, sino sustituir. Si una interacción no es habitual en Android, conviene sustituirla por una que lo sea.

Y podemos inclinar la balanza a nuestro favor si aprovechamos las funciones propias del sistema operativo, aunque no estén presentes en la versión original de la aplicación. Por ejemplo, incluir el reconocimiento de voz, que en Android es muy robusto, añadir la posibilidad de compartir información entre otras aplicaciones o crear un widget para la aplicación, funcionalidades que no existen o son muy pobres en iOS.

Diseño
Si nos limitamos a portar la aplicación sin más, vamos a obtener una especie de monstruo de Frankenstein, que ni es iOS ni es Android. No se trata de trasladar, sino de adaptar la aplicación, y eso implica rehacer los assets, teniendo en cuenta las diferentes densidades de píxeles y los tamaños de pantalla de los dispositivos. Igualmente, hay que modificar el interface gráfico para eliminar algunos botones necesarios en iOS, pero redundantes en Android, como el botón “atrás”.

Para lograr esta adaptación, la situación ideal es contar con un diseñador que conozca ambos mundos. Al disponer de una visión global de ambos interfaces, puede aportar las soluciones más adecuadas en cada caso. Y, si se trata de un desarrollo en paralelo, se puede diseñar desde el primer momento buscando una meta común.

Acceso a recursos
Otro punto a considerar son los botones físicos que hay en cada plataforma. Android nos ofrece un botón “Atrás”, un botón “Menú” y, en algunos dispositivos, un botón “Configuración”. Vamos a utilizarlos, eliminando los elementos redundantes del interface gráfico. Así podremos liberar un valioso hueco en la pantalla, algo imprescindible en dispositivos con pantallas pequeñas.

Y, al igual que tenemos en cuenta los diferentes botones, hay que tener en cuenta el resto del hardware. ¿Tiene GPS el dispositivo? ¿Bluetooth? ¿Acelerómetro? ¿Cámara? Un ecosistema tan abierto como el de Android nos obliga a comprobar la existencia de esas funcionalidades y adaptar el comportamiento de nuestra aplicación según existan o no.

Por ejemplo, y volviendo al tema de adaptar en vez de trasladar: ¿qué ocurre si el dispositivo donde queremos ejecutar la aplicación no tiene GPS? Si el GPS es imprescindible para el funcionamiento de la aplicación, tendremos que indicarlo así, pero si no lo es, quizás podamos ofrecer al usuario algo en su lugar (un mapa fijo, por ejemplo) que supla esa funcionalidad. Demos al usuario una alternativa viable, en vez de un pastiche sin sentido.

Desarrollo
Esta cosa de hablar así en abstracto es muy fácil, como si contáramos con recursos ilimitados. Por ejemplo, una situación ideal es desarrollar ambas aplicaciones en paralelo, con un único jefe de proyecto, un diseñador / UX y dos equipos de desarrollo. Así, tanto el jefe de proyecto como el diseñador tienen una visión global del proyecto, lo que permite a los equipos de desarrollo centrarse en su tarea, sin otras distracciones.

Y en cuanto a las herramientas, afortunadamente ya se puede prescindir del Eclipse, usando en su lugar el Android Studio, eso sí, siempre usando la Support Library, para mantener la compatibilidad con versiones más antiguas del sistema operativo.

API
Este consejo no es tanto orientado al desarrollo Android, sino al desarrollo multiplataforma. Si la aplicación que desarrollamos va a correr en diferentes sistemas operativos y la lógica de negocio implica cálculos complicados, una buena solución es crear un API para realizar las operaciones en el servidor. Es un consejo de sentido común que no se puede aplicar en todos los casos, pero en caso de que se pueda usar nos ahorrará bastantes quebraderos de cabeza.

Estamos desarrollando una aplicación de productividad personal llamada Hightrack (http://hightrack.me) En este caso, el cliente tenía claro desde el primer momento que quería aplicación web, aplicación Android y aplicación iOS. Montamos un API para traernos los datos y, al cabo de un tiempo nos dimos cuenta de que en cada versión estábamos haciendo por separado la lógica de negocio. No sólo estábamos repitiendo el mismo trabajo tres veces, sino que aumentaban las posibilidades de cometer un error.

Decidimos modificar el API para que los resultados ya estuvieran procesados, y nuestra vida mejoró notablemente: no se repite el trabajo, las pruebas son más fáciles de hacer y, si hay un error, basta con modificarlo en el servidor: las aplicaciones recibirán los datos correctos sin necesidad de subir una nueva versión a la tienda correspondiente.

Testing
El testing ha sido la bestia negra del proceso de desarrollo de Android. Si tenemos en cuenta el funcionamiento del emulador, el número de dispositivos, la diversidad de hardware, los distintos tamaños de pantalla… es natural delegar las pruebas en el usuario final y esperar a su feedback para hacer las correcciones necesarias.

Nunca se debe hacer algo así. Es un error muy grave sacar una aplicación a medio probar: no vamos a tener una segunda oportunidad y, si algo no funciona, el usuario lo borra y a otra cosa. Además, esta situación contribuye a la imagen que a veces tiene Android como algo desorganizado (el salvaje Oeste que comentamos anteriormente).

En este caso, el entorno iOS es mucho más robusto: el entorno de desarrollo incluye herramientas para comprobar el consumo de recursos, si se crean procesos zombies, si hay leaks de memoria, y permite hacer test de usuarios automatizados, algo que podemos hacer desde hace poco si utilizamos espresso.

Para mejorar esta situación es vital utilizar las nuevas funcionalidades de alfa y beta testing que se han implementado en Google Play, y así hacer un despliegue controlado al cliente, testers o compañeros y probar la aplicación en más dispositivos, pero de manera controlada. Una vez que haya pasado los ciclos de revisión necesarios, podemos abrirla al público.

Publicación
Ya para terminar, aunque no es parte estricta de la migración de aplicaciones, queremos – por completar – comentar la publicación en la tienda. Una vez más, las diferencias de filosofía entre ambas plataformas se hace patente.

Por un lado, la aproximación de Apple, controlando lo que se sube, mediante revisión, lo que incluye un retraso considerable a la hora de publicar, pero garantizando que la aplicación funciona y hace lo que se espera de ella. A nosotros, por ejemplo, tras seis días de espera, nos rechazaron una aplicación porque faltaba un logo en una pantalla. Lo corregimos en cinco minutos y seis días más tarde, la aprobaron: en total tardamos doce días en publicar la aplicación.

Por otro lado, la aproximación de Android, sin revisión salvo que haya quejas, permite tener una aplicación disponible para descargar en una hora. Eso sí, puede haber aplicaciones de baja calidad, malas copias o “cosas” que ni siquiera funcionan.

Otras alternativas
Una posibilidad para abaratar costes es utilizar herramientas que permiten reutilizar código, sin depender de la plataforma. Pueden ser una solución adecuada si se cumplen estos tres requisitos:

  • El proyecto tiene un gran alcance: necesitamos llegar a todos los dispositivos lo antes posible.
  • El presupuesto es reducido.
  • Estamos dispuestos a hacer sacrificios de usabilidad y diseño.

Ejemplo: Hightrack
El caso de Hightrack forma parte de la tendencia que hemos comentado. El cliente tenía claro desde el primer momento que quería una versión para ambas plataformas. Con un dispositivo de cada clase, pasó un tiempo manejando todo tipo de aplicaciones, hasta familiarizarse con el diseño, interacciones y propiedades de cada sistema. A partir de ahi, diseñó el interfaz adaptándolo a cada plataforma, respetando los diferentes tipos de navegación, animaciones, tipografía, para dotar a la aplicación de personalidad propia y evitar que parezca una adaptación apresurada.

Conclusiones
En resumen: tenemos en nuestras manos la posibilidad de hacer o adaptar aplicaciones de manera que entreguemos un producto brillante, mejor que el original. También contamos con la información necesaria para conseguir que el cliente evolucione de “iOS first” a “Android first” Consigamos que nuestros clientes también se enamoren de un robot.

Movember en Tecnilógica

Jue, 11/14/2013 - 22:56

Si has pululado algo por las redes sociales o por las oficinas de Tecnilógica estas últimas dos semanas (más concretamente desde que comenzó noviembre), te habrás percatado de que hay una fiebre masculina por el bigote. Aunque no sepas de qué va, es imposible que no te hayas cruzado con un hashtag:

#MOVEMBER

¿Qué significa y por qué está todo el mundo revolucionado con el asunto? El término es el acrónimo de dos palabras anglosajonas: “Moustache” (bigote) y “November” (noviembre). Su origen se remonta a finales de la década de los 90 y principios de la década pasada, cuando en Australia proliferaron acciones en las que grupos de hombres dejaban crecer sus bigotes (incluso también patillas, en un principio) durante el mes de noviembre para llamar la atención sobre el cáncer de próstata y la depresión en hombres, recaudando fondos para ONG que luchan por erradicar estas enfermedades, cristalizando en la Movember Foundation en 2004. Desde entonces, el movimiento se ha extendido y multiplicado exponencialmente cada año: se celebra regularmente en varios países (Canadá, Reino Unido, Estados Unidos y España entre ellos) y en cada edición son más las caras conocidas del mundo anglosajón que se suman a la iniciativa. En los últimos años, músicos como Snoop Dogg y Foster The People, o actores como Kevin Connolly y Nick Offerman han participado en calidad de embajadores en esta iniciativa de “cambiar la cara de la salud masculina”. En esta edición de 2013, de acuerdo con datos proporcionados por la Movember Foundation a través de su app móvil, hay casi 900.000 personas participando, las cuales han recaudado en poco más de 14 días más de 27 millones de euros.

Desde Tecnilógica, como no podía ser de otra forma, hemos visto siempre con muy buenos ojos la iniciativa, y pese a que en años anteriores alguno de sus miembros ha participado a título individual, en 2013 hemos querido entrar de lleno en el reto creando un equipo oficial al que se ha sumado la práctica totalidad de la plantilla. ¡Hasta nuestro logo se ha dejado bigote durante noviembre!

Además de apoyar una causa que a todos nos preocupa, aunar nuestros esfuerzos en torno a la iniciativa Movember supone una estupenda oportunidad de seguir reforzando nuestro espíritu de equipo. Un par de días antes de que arrancara oficialmente la campaña, el grueso de la plantilla tecnilógica se dio cita en una céntrica barbería madrileña para escenificar el pistoletazo de salida con un rasurado facial integral del equipo, consiguiendo con la publicación del evento y de las fotos del mismo en nuestro perfil de Facebook una interesante excusa para difundir nuestra implicación con la causa movembera. Todos estos esfuerzos han sido fructíferos: el equipo de Tecnilógica lideraba hasta hace escasos días la tabla de resultados de equipos españoles. ¡Ha tenido que irrumpir el mismísimo equipo de Google para arrebatarnos el primer puesto! Tecnilógica recaudó casi 1000 euros antes siquiera de que el reto Movember arrancara.

Como podéis comprobar, nuestra implicación en Movember incluye el bombardeo continuo en el entorno de trabajo.

Según Movember España, “el cáncer de próstata es uno de los más comunes entre los hombres españoles. A pesar de ello, el nivel de concienciación, entendimiento y apoyo para el cáncer de próstata queda muy atrás de las causas que apoyan la salud femenina.” Estas son algunas de las cifras generales que ofrece la Fundación en cuanto a esta enfermedad: en España

- 18.870 hombres son diagnosticados cada año, el equivalente a más de 50 por día.
- Un hombre muere cada hora y media en España de cáncer de próstata.
- En 2012, 5480 hombres en España perdieron su vida a causa del cáncer de próstata.

Estas preocupantes cifras son motivo más que suficiente para que todos actuemos de alguna u otra forma para apoyar la investigación sobre el cáncer de próstata y otras dolencias que aquejan hoy en día al hombre. En la web de Movember hay disponible más información al respecto de la salud masculina.

Desde Tecnilógica os animamos a todos, MoBros -“hermanos de bigote”-, a participar con nosotros luciendo vuestros mostachos, pero también, y esto es realmente importante, a que os hagáis exámenes de próstata y testiculares para evitar sorpresas desagradables, muchas veces de carácter irreversible. ¡Recordad que la prevención lo es todo en estos casos! Y tened en cuenta asimismo que ir al psicólogo si uno no se encuentra “muy fino” no es nada de lo que avergonzarse… ¡MoSistas, ayudadnos a animar a los hombres que nos rodean a que cuiden de su salud!

Así que ya sabéis, podéis dirigir vuestros donativos al equipo de Tecnilógica aquí. ¡Ayudadnos a adelantar a Google!

Páginas