Wednesday 25 June 2014

Google I/O 2014

Este post empezó como un comentario de Google+, pero se extendió tanto, y se que voy a hablar de este tema en los días siguientes, así que preferí ir armando el camino en el blog.



Me encanta como todo el mundo piensa que van a mostrar un millón de cosas en la conferencia I/O de mañana. Para mi se ríen de todos nosotros y no muestran nada (?). Especulaciones que vi:
  1. Android L lanzado.
  2. Android L mostrado, lanzado en primavera.
  3. Android con 64 Bits
  4. Android Wear
  5. LG G Watch
  6. Moto 360
  7. Algo de Google Glass
  8. Algo con Nest y/o home automation en general
  9. Próximo smartphone Nexus
  10. Próxima tablet Nexus (Volantis, Nexus 9 de HTC, Nexus 10, whatever)
  11. Android Silver (programa que reemplaza a los Nexus)
  12. Android Auto Link (Android para automóviles)
  13. Android Health o algo así, para competir con Samsung, LG, Apple...
  14. Heads up notifications oficial (y no oculto)
  15. Quick settings mejoradas
  16. Notification cards apiladas
y podría seguir...

¿No será mucho? ¿Cuáles creen que anunciarán posta? Les puse número por si quieren votar en los comentarios.




Lo que si:

2) Porque +Sundar Pichai lo dijo. Más precisamente:

This year, Pichai will preview the next release (Lollipop? Lemonhead?) for the first time at I/O, rather than waiting until the fall. It’s a significant shift toward greater transparency. “I want the world to understand what we are doing sooner,” he says.

Y ojalá se llame Lasagna (si, ya se que no es un postre, pero who cares? Las cosas cambian).

Que rico Android

2) Porque es el paso natural a seguir, aunque no lo veo necesario. Como comenté en Google+, 2GB alcanzan, 3GB sobran. 4 o más, que es lo que te permiten los 64 bits hoy no hacen falta. Y precisión de cálculo tan alta en un smartphone tampoco se usa, pero bueno, no hay que negar ni coartar la evolución. Puede que con esto se desarrollen cosas que antes no se podían (me interesa mucho que aumente la capacidad de procesamiento para las fotos y videos, por ejemplo, que son cada vez más grandes y pesados).

Nexus Watch (?)

4, 5 y 6) Porque es el mejor momento. Ya se conoce un poco, la gente está interesada, los devs involucrados y el hype está en el aire. Además, dicen que a los que vayan al evento les van a "regalar" un LG G Watch (las comillas son porque la entrada de la I/O era carísima y para mi ya está incluído ese supuesto "regalo"). Buena onda para los devs que vayan, porque por más que a mi me guste más el Moto 360 por lo que se vio hasta ahora, aparentemente el G Watch sería el Nexus de Android Wear.

Shut up and take my money



Lo que ni (si, dije "ni", no dije "no"):

Lo demás no digo que no aparezca, pero me menos interesante/probable desde mi punto de vista. Los que pueden o no aparecer, pero no sería muy complicado, es el tema de Home Automation y Auto Link. No porque no sea interesante, sino porque personalmente, de acá a que yo pueda usar/tener/disfrutar algo de eso, va a pasar mucho tiempo, así que honestamente, mucho no me interesa (en 24 horas seguro me van a tener gritando como una loca por los anuncios, lo se).
El termostato de Nest (ahora de Google). Otro paso hacia la "Home Automation".

En cuanto a los smartphones, le tengo más fe al rumor de que no va a haber más Nexus y que aparece el programa Android Silver algo así como a fin de año o a principios de 2015, absorbiendo ambos a los Nexus y a los Google Play Edition. A eso le tengo mucha fe y ganas (es decir, que las empresas trabajen codo a codo con Google para desarrollar sus flagships, agregando su fork después sobre esa base, pero cumpliendo ciertas pautas para unificar un poco más aun el ecosistema Google/Android. 

15, 16 y 17 no digo que no estén, pero sería un agregado a la número 2 que ya dije que para mi va a estar.

Por fuera de #GoogleI/O2015, con la venida de ART por sobre Dalvik de forma definitiva como runtime default (y sin posibilidad de fallback), espero que nuestro amigo rovo89 logre hacer andar Xposed en ART, porque no me puedo mudar a un OS que me obligue a abandonar eso. Ya no puedo vivir sin ese framework.

De yapa, espero que anuncien algo sobre Dart (#Dartlang). Es un lenguaje de desarrollo web que parece que tiene bastante pinta. Es modernoso y me encantaría que anuncien cierto reemplazo o compatibilidad doble para programación para Android, en Java y en Dart (y bueno, si eventualmente desaparece Java para Android, también está bien, siempre y cuando ayude a que sea más fácil hacer de todo, cosa que noté ahora que empecé a programar Android. Aunque hablo desde un total desconocimiento sobre la plataforma (ojeé un poco y me gustó, nomás. Mi opinión puede cambiar 180º sin previo aviso).

Pero bueno, todo esto es pura especulación mía y habrá que esperar a mañana para enterarnos bien que se trae Google entre manos.

Ojalá no anuncien que van a dominar el mundo con robots asesinos de Boston Dynamics, drones aniquiladores de Titan Aerospace y bueno, nuestros teléfonos particulares, claro.

Sunday 8 June 2014

¿Retrocompatible? Si, cuando me pinta.

Hoy voy a hablar un poco de algo que me pasó en el laburo. Tuve un problema que resolver, y la primera vez, lo tiré abajo de la alfombra por un rato, hasta que volvió a surgir. Y lo tuve que atacar.

No me voy a extender mucho en los detalles, porque a quien le interese el tema, va a saber más o menos de que hablo, y al que no, ni siquiera lo va a leer. Si querés ir directamente al problema (y a la solución), podés saltar la próxima sección (el versito no fue intencional).



Con que estaba laburando
Sinatra 1.3.2
Sinatra is a DSL for quickly creating web applications in Ruby with minimal effort.
dice la documentación de Sinatra. Y es cierto. Usándolo para un par de cosas sencillas, pueden salir cosas muy fácil y rápido. Por otro lado:
Padrino is a ruby framework built upon the Sinatra web library. Sinatra is a DSL for creating simple web applications in Ruby. Padrino was created to make it fun and easy to code more advanced web applications while still adhering to the spirit that makes Sinatra great!
dice la documentación de Padrino. Pero más importante, dicen que Padrino tiene Sinatra Core, y que por lo tanto...:
Many people love the simplicity and expressiveness of Sinatra [...].
[...] Our goal with Padrino is to stay true to the core principles of Sinatra including a focus on simplicity and modularity.
Starting from this assumption, we have developed a different approach to a web development framework. We expand on Sinatra through the addition of standard libraries including helpers, components, and other functionality that are needed in a framework suitable for arbitrarily complex web applications.
¿Y qué es lo importante de todo esto? Se preguntarán. Que dicen que usa Sinatra Core y que expande Sinatra, es decir, que agarra Sinatra y le agrega cosas o lo mejora, pero no aclaran que también lo rompe un poco.
Que parezca un accidente, supongo. Padrino 0.10.3.
Así es. Uno espera que algo que extiende otra cosa, no rompa mediante dicha extensión, la primera. Es decir, lo mínimo que uno espera tener, es retrocompatibilidad (o compatibilidad hacia atrás). Si tengo una aplicación de Sinatra que anda, pero necesito algo más, y me paso a Padrino para tratar de rehacer lo menos posible, espero que al menos de entrada, lo que tenía, siga funcionando.



El problema

Supongamos que tenemos una ruta a una página. La misma tiene algunos parámetros que llamamosparamparam_opt y param_opt2(por ejemplo, si queremos listar posts de un blog, podemos hacer una ruta del estilo /:year/:year/:month/:year/:month/:day donde el mes y el día son opcionales, porque con dar sólo el año ya se puede obtener un resultado, y el mes y el día son para acotar los resultados). Como sus nombres declarativos (?) lo sugieren, el primer parámetro es obligatorio y los otros 2 son opcionales.

Óptimamente, uno no querría tener que atajar las rutas
hostname.com/:param
hostname.com/:param/:param_opt
hostname.com/:param/:param_opt/:param_opt2 
por diversas razones de comodidad y buenas prácticas. Hasta ahora lo único (y bastante) molesto es la repetición de los prefijos, pero supongan (y me pasó) que quieren agregar otro parámetro opcional, pero antes de param. Hay que agregar otros 3 casos para atajar dichas rutas. Y eso no está bueno, más aun si queremos mantenernos con filosofía DRY.



Como resuelve Sinatra

Realmente es sencillo. Luego de cada parámetro o caracter opcional, se puede agregar un "?" y eso determina que el parámetro (que puede ser un símbolo como lo describí antes) o caracter anterior, es opcional. Veamos un ejemplo. En:
hostname.com/:param/?:param_opt?
la segunda “/“ y el símbolo :param_opt son opcionales. En:
hostname.com/:param/?:param_opt?/?:param_opt2?
la segunda y tercer “/“ son opcionales, al igual que los símbolos :param_opt y :param_opt2.
Exactamente como queríamos. Sencillo, ¿no?

Seguro hago esto así en Sinatra, me queda re compacto y lindo, me paso a Padrino y anda, ¿no?

No.



Como resuelve Padrino

No tengo ni idea. Bueno, en realidad si. Como Rails. Un gran conocedor del mundo Ruby y compañero de trabajo (Demian) me lo hizo notar (y le estoy muy agradecido), luego de ver la cantidad incontable de horas que estuve buscando como hacer parámetros opcionales, sin éxito alguno.

No se si a nadie en toda la internet le pasó esto o que, pero no hay nada al respecto. Google te manda a resultados de Stack Overflow, relacionados con Sinatra, entre otras cosas, pero nadie dice que Padrino reemplaza, aparentemente, el router de Sinatra por el de Rails.

Demian sabía que en una aplicación de Rails que hizo había necesitado parámetros de URL opcionales, entonces como no había nada que perder, se fijó como se hacía, y lo probó así. Y funcionó.

La solución es poner parámetros opcionales estilo Rails 3, con paréntesis (sección 3.1 Bound Parameters).

Entonces teniendo:
hostname.com/:param
hostname.com/:param/:param_opt
hostname.com/:param/:param_opt/:param_opt2 
se soluciona aplicando los paréntesis correspondientes, quedando:
hostname.com/:param(/:param_opt(/:param_opt2))
De esta forma, /:param_opt2 es opcional dentro de /:param_opt, y a su vez, esta composición es opcional en la dirección entera. En este caso /:param_opt2 no puede aparecer si antes no hubo un /:param_opt. Si lo que queremos es tener varios parámetros independientes entre sí, en lugar de anidarlos o componerlos como hice ahí, simplemente se pone paréntesis individual a cada parámetro, quedando:
hostname.com/:param(/:param_opt)(/:param_opt2)


Conclusión

No se ustedes, pero para mi, cuando alguien basa un producto en otra cosa, la idea no es romper el producto original. O al menos, avisar y documentar bien en caso de haber alguna excepción insalvable.

Todavía no considero tener mucha experiencia en el área, y cabe la posibilidad de que el que se está equivocando al usarlo sea yo, pero para eso están ustedes y sus comentarios, para aclararme el panorama, o que nos juntemos a tomar mate e insultar a los desarrolladores.