Aplicaciones javascript que uso de referencia

Aplicaciones javascript que uso de referencia

Llevo desarrollando en javascript casi exclusivamente 2 años y pico, posiblemente sea el lenguaje que más he usado de continuo en mi vida profesional. A pesar de ello no conozco cada detalle del lenguaje, cuando eres más jóven te entretienes en conocer cada aspecto y uso de cada cosa que usas, quizá pensando que eso es saber programar. 

En este tiempo sin embargo me he intentado centrar en mejorar la arquitectura y organización de las aplicaciones. Hay cosas que son comunes a todos los lenguajes pero es inevitable aprender ciertos patrones concretos del lenguaje que estás usando, y javascript tiene unos cuantos.

Javascript no tiene un sistema de gestión de módulos. Eso es un gran problema, ya que no hay una forma de importar módulos, de hacer sandboxing (de una forma coherente), etc. Casi todos los lenguajes lo tienen, mejores o peores, pero todo el mundo usa la misma forma y simplifica mucho las cosas. Y esto parece una gilipollez suprema, pero modula muchísimo el uso del lenguaje.

Cuando haces una aplicación javascript grande, la organización del código, de módulos, la separación y todas esas cosas que todos sabemos que hay que hacer bien pasan a ser fundamentales. Por esa razón la mejor forma de hacerlo bien es coger ideas de otras aplicaciones que ya están funcionando.  He visto algunas presentaciones y librerías donde te explican como modularizar todo, organizarlo con un buses, eventos, patrones, pero en general, no se basan en experiencia real.

Algunas de las aplicaciones que uso como referencia para coger ideas son las siguientes (todas ellas en producción, con millones de usuarios en algunos casos):

- DocumentCloud: es posiblemente la primera aplicación hecha con Backbone (por los creadores obviamente) y es interesante por dos razones: 1) la organización de la aplicación 2) el uso de Backbone. Como nota adicional, conocí a Jashkenas y además de ser un tío inspirador me quedó bastante sorprendido de algunas decisiones tomadas en Backbone.js, sobretodo relacionadas con cambios a lo largo de su historia.

Se ha quedado un poco obsoleta (usa backbone 0.4 o algo así)

- prose: posiblemente no lo conozcas, es un editor de contenidos basada en github. Usa Backbone también, pero esta está mucho más actualizada y tiene algunas cosas interesantes que cuentan los magos de mapbox en su blog.

- iD: es el nuevo editor por defecto de OpenStreetMap. Tiene la peculiaridad de que está construido todo con d3, no usan jQuery y tienen un sistema modular para los widgets algo diferente. Tom MacWright lo explica en su blog con detalle (este post es un must). Muy bueno el documento de arquitectura en su repo.

- CartoDB: vale, esta aplicación es la que desarrollamos en Vizzuality, pero que la hagamos nosotros no significa que no tenga cosas interesantes. Seguramente haga un post detallado de la arquitectura frontend de CartoDB, pero hay algunas cosas interesantes que puedes ver, por ejemplo la gestión de vistas, o como organizamos las diferentes partes de la app

Seguro que hay muchas más, pero estas son las que me han parecido más realistas, interesantes y por supuesto en producción. Nunca me fio de algo que no está en producción 

A cortar cojones se aprende cortando cojones

No sé exactamente si esta es la expresión correcta, creo que el refrán original es “a capar se aprende cortando cojones”. Lo bueno de los refranes es que aunque los versiones los entiendes perfectamente.

Me quedo embobado todos los días de Dios con el making of de las cosas, de hecho lo normal es que me interese más el como se hace que el resultado final, desde como pasa lo que compras la cajera del mercadona (ese estilazo colocando los códigos de barras), como limpia el pescado el pescadero o como con solo escuchar el sonido de un coche un mecánico es capaz de saber el problema de un coche.

El factor común es que todos tienen los huevos pelados de hacer eso. Seguro que hay gente portentosa que en 5 minutos es capaz de hacer maravillas, pero si eres normal te va a costar trabajo y mucho esfuerzo dominar algo. De hecho el repetir una tarea no basta, hay que analizar el proceso y el resultado, cada vez, variar y analizar, todas las santas veces. 

Por eso cada vez que veo a alguien que profesionalmente admiro, que hace las cosas como me gustaría hacerlas, me pregunto como fueron sus inicios y trayectoria, las horas que ha echado mejorando, las veces que la ha cagado y sobretodo las que ha pensado en mandar todo a tomar por culo.

Y todo esto viene por este video.

Internal guide to report a bug

This is the mail I sent to the internal mailing list in vizzuality some weeks ago when we started to prepare the next big release of CartoDB (probably it will be live when you read this post) with some guidelines to report bugs while manual testing is performed. I think it might be useful for you:

Hey,   The following days we will report lot of bugs (I hope not …) and there are some things we can do to improve the time they take to be resolved:

• We assume we work on chrome/osx. If you are using other browser/OS report it, specially IE/windows. 

• Sometimes the bugs can’t be reproduced easily, don’t worry, just report it and write all the things you did, every detail is important and write you can’t reproduce always. This is very important because if you don’t say that we will mark it as invalid and we will spend some time discussing it

• Please, don’t use “gets crazy”, “crash”, “does not work”, they don’t provide information and make developers feel bad, really.

• Spend time reproducing and reporting the bug, if a bug report is good the resolution is easier.

• Open developer tools (or similar) when you are testing, if you see a javascript error, report it in the ticket. In some cases resolution time is 100x faster.

• Do not assume things work in the way you think, please report the expected behavior

• Be smart reporting bugs. Maybe that wrong padding is important, but if there are 200 tickets with real important things that does not work report it and add to a different milestone. Tickets are like inventory, keeping inventory cost money: http://www.joelonsoftware.com/items/2012/07/09.html

and the last one but not less important:

• We all feel bad when something does not work, especially when you are working so hard, so comments like “this is shit”, “this shit does not work”, complains and all “demotivational” stuff are not welcomed.

Thanks

Linkedin

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.

Como aguantamos una portada de google

El día que aguantamos una portada de google

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.