Año 2005, llega un contratista a una obra, se acerca a un chaval que está controlando una grúa -que no conoce de nada- y le dice “hola, soy menganito, vengo de la empresa TALCUALSA y me gustaría contratarte”. El chaval responde con educación que no quiere cambiar de trabajo y el contratista va a por el siguiente.
Imagínate eso cada día, varias veces a la semana. Imagina el ego del chaval, imagina la respuesta del personaje cuando venga el décimo contratista a ofrecerle trabajo. Piensa también en lo todo lo que podrá chulear delante de sus amigos y compañeros de trabajo.
Ahora no hace falta que imagines lo que pasa con ese chico en 2013.
Pues eso es lo que veo casi a diario en twitter con los recruiters. Son todo quejas sobre las veces que te contactan, lo “mal educados” que son o la poca idea que tienen del sector, sin darse cuenta que tal vez estemos buscando a esa gente dentro de 5 años. Son un síntoma de lo bien que está el sector, lo cual debe ser motivo de alegría, pero algún día llegarán las vacas flacas.
Hasta hace dos minutos tenía un mensaje en Linkedin bastante prepotente, lo he quitado y desde hace unos días trato de contestar a todas las personas que me contactan a través de esta red. Muchas de ellas no saben ni a lo que me dedico, tampoco pasa nada por responder de forma educada. Quién sabe.
Hoy hace un año si hubieses apuntado tu navegador a google.com hubieses visto un link, justo debajo de la caja de búsqueda, que linkaba a una web que hicimos en vizzuality, endangeredlanguages. El hecho de estar un dia en portada de google.com es para estar bien contento, pero todo el proceso que te lleva hasta ahí y aguantar eso no es precisamente un camino de rosas.
No voy a describir los detalles de implementación o los datos de tráfico, lo primero es muy aburrido y de los segundo seguro que hay algún papel que dice que no lo puedo contar.
Cuando comenzamos el proyecto ya había cierta presión adicional, el cliente era google y aunque era el tercer proyecto que hacíamos con ellos siempre acojona un pelín. Mucha gente me pregunta cómo es trabajar con google y siempre respondo lo mismo: no son super hombres, son como tú y como yo, pero están en una empresa de las que molan. Seguramente haya mega-cracks, pero en muchas pequeñas empresas también los hoy (y posiblemente con más mérito). El proyecto era un target muy concreto, lingüistas, así que cuando tome las primeras decisiones me base en aquello, un pequeño proyecto para google que no tendría muchas visitas. Nada apuntaba a que ese sitio tendría millones de usuarios cada hora.
Opté por algo standard, usar python con django (app engine lo soportaba sin tocar mucho) y mysql como base de datos (gooogle lo llama cloud sql). Obviamente teníamos que usar su infraestructura, así que aunque cloud sql estuviese en muy beta, no me tiró para atrás, después de todo mysql es algo bien probado y simplificaba el desarrollo una barbaridad. Total, no necesitabamos escalar, así que el key-value store que tiene google por defecto no tenía mucho sentido para nostros.
El proyecto era el típico web, todo transcurrió con normalidad hasta que un día, unos dos meses antes de la release, nos llega un correo diciendo que posiblemente estaríamos en portada de google. Imaginad hacer una casa para una familia y te venga una familia numerosa a celebrar allí una boda.
Se me pusieron los cojones de corbata, no había cacheado nada, no había pensado en ninguna forma de escalar absolutamente nada, es más, cada petición a la base de datos tenía un overhead de 10ms, imaginaos si cada página renderizada lanzaba 10 queries (ya sabéis que los ORM son la peste)
Esto se unía a que mi experiencia con sitios muy grandes era 0, hace unos años me publicaron en portada de microsiervos y meneame un pequeño mapa y tuve picos de salida de 6mbits… Jajaja.
Tener no tenía ni puta idea pero qué cojones, íbamos a tener otra oportunidad de tener un reto así?
Dicho así parece bonito y muy craftman, pero las discusiones por correo con la manager fueron para darnos de ostias, los correos a la gente de google pidiendo consejo técnico para tener algo donde agarrarme, los días enteros haciendo pruebas de carga recortando milisegundos fueron un verdadero infierno.
Finalmente opté por aprovechar al máximo lo que teníamos: instancias (aka CPU). Google app engine escala muy muy bien en máquinas, así que traté de usar todo lo posible los servidores frontend, incluso parte de la cache se hacía en cada una de las instancias. Había cache en varios niveles, tanto a nivel de request, a nivel de render HTML, acceso a base de datos… tenía tanta fe en el escalado de máquinas que la búsqueda para ese día la hice indexando todo en memoria y haciendo una búsqueda lineal por todo el índice. Finalmente en una máquina normalita cualquier página se renderizaba en menos de 10ms con un usuario autentificado, bastante decente. Bueno, después de un mes entero dedicado a optimizar tampoco es algo para estar muy orgulloso.
Contra pronostico y a pesar de que la gente de google no confiaba mucho en ello, pasamos todas la pruebas de carga, la revisión de código y la de seguridad.
Llegó el día, todo empezó bien, australia no era especialmente peligrosa. Recuerdo que Diego -el diseñador- me preguntó “pero tu crees que va a aguantar” respondí “ni con una aparición divina”. Increíblemente aguantó sin despeinarse todo el día, solo tuvimos que hacer dos hotfix, uno por un problema de las cachés de la internacionalización y otro por un fallo de seguridad en un endpoint donde se me olvidó comprobar el el token CSRF. Tuvimos que hacer un cambio justo en el momento con más requests por segundo (cuando lo americanos se levantaron) porque el servidor de picasa, donde teníamos las imágenes dejó de responder (os podéis imaginar el choteo).
Aquella semana, justo a los dos días teníamos la release de evolutionoftheweb así que no dio mucho tiempo a saborear el triunfo :). Hay muchas anécdotas que contar, como que casi nos hacemos un DoS nosotros mismos por un bucle infinito en una redirección en blackberry. Pero muchas de ellas solo las podré contar “face to face”, así que si quieres, avisame por twitter, y tomamos una caña, o vino o lo que sea.
A veces necesitas una Backbone.Collection tenga modelos de diferentes tipos normalmente derivados de uno base.
No hay problema si añades los modelos a mano:
var c = new Backbone.Collection(); c.add(new MyModel()); c.add(new MyOtherModel());
Sin embargo cuando los datos vienen serializados desde el API que estés usando Backbone internalmente genera los modelos, así que todos los modelos son iguales.
Hay varias formas de hacer que los modelos que se generen sean los correctos, una de ellas que es más o menos simple:
var C = Backbone.Collection.extend({
model: function(attrs) {
var t = {
'type1': MyModel,
'type2': MyOtherModel
}
return new t[attrs.type](attrs);
} });
var c = new C(); c.reset([ { type: 'type1', ...}, { type: 'type2', ...}, ])
Obviamente hay que hacer un override del método toJSON de los modelos para incluir el type.
Cada vez que veo algo tal que así:
void turn(float angle) {...}
algo muere dentro de mi.
Lo normal es que las aplicaciones usen radianes para los cálculos, sin embargo hay ámbitos en los que se trabaja en grados (por ejemplo, los GPS devuelven los ángulos en grados) y siempre hay que o revisar la documentación, mirar el código o tirar de prueba y error.
Una solución es poner un comentario
/* angle in degrees */
que está muy bien, pero lo mejor de todo es que hagas lo que debes hacer:
void turn(float degrees) {...}
Gracias
Mi hermano es mecánico. Como en todos los trabajos hay gente que los hace y gente que los disfruta, gente que cumple y gente que se esfuerza y trata de sacar el máximo.
Mi hermano es del segundo grupo, por eso al salir del trabajo se entretiene con otro amigo en pequeño taller donde preparan coches para competición (casera eso sí).
Está preparando un Golf MkII con un motor 1.8T de VW para ir a circuito al que suele ir, así que un día hablando con él le propuse hacer una aplicación de cronometraje usando GPS.
Tengo bastante experiencia con GPS, desde como configurarlo para obtener lo mejor de ellos en diferentes condiciones dinámicas, cómo obtener la mejor precisión en proyección y como gestionar todos esos datos a nivel de aplicación, así que por qué no?
En ratillos voy trabajando en la aplicación, intento mejorar un poco mis habilidades de diseño ( sin mucho atino para que negarlo) e a la vez aprender un poco más sobre proyecciones, cálculo con precisión, simulación, mezcla de datos de sensores y otras hierbas que siempre me han gustado y casi nunca tengo tiempo de trabajar en ellas.
En el video muestro el primer prototipo en una tablet android, es una reproducción de un pequeño circuíto que me he hecho en un polígono industrial abandonado al lado de casa (siempre velocidad legal, respetando la normativa vigente en seguridad vial y tomando las precauciones pertinentes).
Hay muchas cosas que mejorar, casi no he trabajado nada en el UI, pero toda la parte de cronometraje está muy desarrollada.
No veo el momento de ir al circuito a probarlo de verdad :)
Si estás interesado en el tema recomiendo empezar por una muy buena charla sobre los sensores disponibles en Android.