Ayer, un amigo que ha sido compañero de trabajo en ya dos empresas y de los que tiene la cabeza encima de los hombros, me comentaba mientras nos calzábamos unos buenos copazos que poco menos que se habían reído de él cuanto estaba explicando su solución técnica para gestionar cuentas de millones de usuarios porque usaba eval
Hace no demasiado, en la SpainJS (una conferencia de javascript), un chaval de Spotify decía, con cierto reparo, que usaban iframes. En la charla además explicó cómo se comunicaban y qué diferentes aproximaciones habían usado, lo que hizo que fuese, de largo, la mejor charla de la conferencia. Lo que se me quedó grabado es que casi pedía perdón por usar iframes. Se conoce que alguien en alguna parte dijo que los iframes no eran una solución elegante, que era cutre.
Estos son dos ejemplos, pero veo mucho más todos los días, gente aclamando que siempre debes hacer TDD, que lo más importante es que el código quede perfecto, discutiendo si tal o cual tecnología es una bazofia. A menudo se nos olvida que hay un factor que todos tenemos muy limitado, y es el tiempo. Y para hacer cosas en tiempo hay que hacer algunas cosas cutres, cosas mal vistas, dejar lo que ahora todos llaman deuda técnica que no deja de ser lo que toda la vida se ha llamado ingeniería, o dicho de otro modo, saber qué puedes puentear y qué debes hacer lo mejor que puedes. No se puede, bajo ningún concepto, hacer siempre lo mejor que puedes en un proyecto, porque estarías tirando tu tiempo.
Cada vez que haces algo cutre, es decir, cada vez que tomas una decisión técnica que no es la perfecta, sino la ideal para eso, alégrate, acabas de ganar un poco de tiempo de tu vida. Pero claro, para saber en qué debes apretar los machos y dónde dejar esa deuda normalmente tienes que tener una perspectiva que los programadores no solemos tener y lo tapamos con basura técnica. Y no se te olvide anotar que esas cosas las has hecho así por si viene algún espabilado después criticando lo que hiciste en su día (no te preocupes, puedes poner comentarios en el código, son bienvenidos).
No recuerdo cuando ni donde le escuché al mítico Javier Arévalo algo así como:
código cerrado >>>> código acabado
Cuando tienes un producto y vas a meter una nueva feature hay una distancia abismal entre tenerla acabada y en producción (cerrada). Vamos ser claros, lo de “say NO” es muy bonito cuando escribes libros pero la realidad es que el software requiere cosas nuevas de vez en cuando (de hecho muy de vez en cuando)
Digamos que tenemos una feature acabada, todo funcionando en desarrollo y podemos usarla sin problemas en un entorno “controlado” (staging o como lo llames). Pero eso es la punta del iceberg del trabajo. Una feature es como un hijo, no vale con “poner la semillita en mamá”, hay que llevarla por el camino correcto y dejarla ir cuando toque.
Estas son algunas de las cosas en las que deberíamos pensar (que no hacemos porque entraríamos en depresión):
Si eres desarrollador de sofware o estás cerca de ellos te sonará lo de “no puedo reproducir este problema” o el famoso “funciona en mi máquina”. Normalmente cuando vas a resolver un bug el flujo es el siguiente:
1) alquien lo reporta, normalmente con una descripción pobre y mal especificado
2) lo reproduces
3) lo fixeas
4) el que lo reportó o un QA prueba que efectivamente eso está cerrado
Dejando a un lado el tema del report de bugs, que muy poca gente sabe hacer bien (incluídos desarrolladores), hay muchas ocasiones donde el paso 2 es imposible o difícil: las condiciones de partida suelen ser diferentes, el entorno, etc. Cuando esto pasa te pasas horas tratando de ponerte en el pellejo del que lo encontró dando a menudo palos de ciego a ver si suena la flauta.
En estas últimas dos semanas por desgracia he tenido que solucionar bastantes bugs (culpa mía todos y cada uno de ellos) y uno de ellos surgió justo antes de tener que ir a coger el tren. Era más o menos urgente así y no podía utilizar el portátil para reproducirlo y arreglarlo, así que intenté resolverlo de memoria.
Tracear el programa sin tener claro como reproducir el problema viene a ser como hacer una raiz cuadrada de memoria. Lo mejor no es que ejercitas la memoria si no que mientras vas analizando cada caso concreto y como podría afectar a tu código encuentras posibles fallos, mejoras y WTF que hiciste cuando lo programaste.
Llevo haciendolo cosa de dos semanas y es especialmente interesante sobretodo cuando tratas de reproducir bugs en código ajeno.
Y es que al final la cabeza va mucho más rápido que la vista y los dedos buscando entre el código usando el editor. Antes de ponerse a mirar como un loco el código analiza 5 minutos sin tocar el ordenador qué puede estar pasando.
Agroguía es una pequeña empresa que monté hace ya 7 años y medio que se dedica a hacer productos para agricultores. Siendo realistas solo se dedica a hacer un producto que es lo que vendemos, sin embargo hemos hecho y hacemos otras cosas.
Agroguía nació como un “y si probamos” y todos y cada uno de los años, al finalizar la temporada agrícola, sabía que aquel año sería el último. Cómo iba una empresa de 3 fulanos en un poblado de Valladolid a sobrevivir, vendiendo sólo por internet. Todos y cada uno de estos años me he confundido, lo que viene a significar que hemos superado las espectativas con creces.
Hay que tener en cuenta que hace 8 años lo de las startup y estas modernidades no se llevaba, aquí salías a pecho descubierto, sin tener ni puta idea pero con un par de huevos. Agroguía nunca ha sido una startup, cuando la cree no fue para crecer mucho, ni para venderla al cabo de 3 años, ni para captar un VC. Símplemente necesitaba dinero por que básicamente estábamos [muy] metidos en la mierda (es lo que tiene ser hijo de agricultor sin tierras).
Es cierto que este año no hemos dedicado mucho tiempo, pero algunas cosas hemos hecho:
· Estamos rematando el nuevo producto que vamos a sacar. Escribiré un post acerca de este tema, de momento os dejo un video:
Me gustaría destacar que sólo hay una persona dedicada 100% en Agroguía, los demás (@jatorre, @saleiva y yo) hacemos cosas puntuales y echamos un cable en momentos concretos pero nos dedicamos a @vizzuality la mayor parte del tiempo.
Este año vamos a trabajar duro en la parte de tracking, consiguiendo más distribuidores y dando el puto mejor servicio que puedas tener si compras un sistema de guiado GPS agrícola.
If you are developing a medium/big javascript frontend application you do want to have a isolation mechanism for views. This is the only way to keep your application working as expected as its size grows.
For the moment HTML does not provide a native way to do this so you have to rely on javascript side to do this. Ok, that’s not totally true, iframes are a sandbox (spotify uses them to isolate views) and shadow DOM is not still there.
There are a lot of libraries to do this, in CartoDB we use Backbone, it’s simple, small enough to fully understand it, no magic, no extensions on top of HTML and provide a evented system to comunicate model and views.
The typical Backbone view looks like this:
var View = Backbone.View.extend({
initialize: function() {
this.model.bind('change:attr', this.render, this);
}
})
So every time attr changes the view is rendered. In current Backbone version you have listenTo method which tracks which objects are attached to a given one but when we started to use Backbone that method didn’t exist so we use the 3rd argument to know what object a signal is attached to. Easy but you have to remember to pass the this always you link a signal.
When a view is removed all those links must be removed, if it’s not done those views are going to last forever. That’s “only” a memory use but imagine the view have some side effects like saving another model to the server…
During last chrismas I decided to do a big refactor in some part of CartoDB (wizards if you know it), and some views had binding leaks. Find them is really hard and sometimes it takes hours to find them even if you have tools. For example, we have a checker to detect leaks while the app is running, just execute cdb.core.View.runChecker int the console and it will show a list of “missing bindings”. It works but only with the views that are currently created.
I though it would be better to find them in testing stage so I created a jasmine (*) helper:
it("should not have leaks", function() {
expect(view).toHaveNoLeaks();
});
What basically does is:
_subviews array to track them, but this is for another post)Really simple, easy to use in all the view tests. It saved me hours of in-app testing. The function itself is defined here if you want to take a look. It can be improved with a more smarter logic but it’s enough for the moment.
NOTE: this post is actually a mail I was going to send to frontend cartodb developers but I though it may result useful for someone else
(*) we use jasmine but I totally hate it