“*Utils” classes can be a code smell: an example

You might have heard that “*Utils” classes are a code smell.

Lots of people have written about that before, but I tend to find the reasoning a bit vague, and some of us work better with examples.

So here’s one I found recently while working on this bug: you can’t know what part of the Utils class is used when you require it, unless you do further investigation.

Case in point: if you place a method in VariousUtils.js and then import it later…

var { SomeFunction } = require('VariousUtils');

it’ll be very difficult to actually pinpoint when VariousUtils.SomeFunction was used in the code base. Because you could also do this:

var VariousUtils = require('VariousUtils');
var SomeFunction = VariousUtils.SomeFunction;

or this:

var SomeFunction = require('VariousUtils').SomeFunction;

or even something like…

var SomeFunction;
lazyRequire('VariousUtils').then((res) {
  SomeFunction = res.SomeFunction;
});

Good luck trying to write a regular expression to search for all possible variations of non-evident ways to include SomeFunction in your codebase.

You want to be able to search for things easily because you might want to refactor later. Obvious requires make this (and other code manipulation tasks) easier.

My suggestion is: if you are importing just that one function, place it on its own file.

It makes things very evident:

var SomeFunction = require('SomeFunction');

And searching in files becomes very easy as well:

grep -lr "require('SomeFunction');" *

But I have many functions and it doesn’t make sense to have one function per file! I don’t want to load all of them individually when I need them!!!!111

Then find a common pattern and create a module which doesn’t have Utils in its name. Put the individual functions on a directory, and make a module that imports and exposes them.

For example, with an `equations` module and this directory structure:

equations
  linear.js
  cubic.js
  bezier.js

You would still have to require('equations').linear or some other way of just requiring `linear` if that’s what you want (so the search is “complicated” again). But at least the module is cohesive, and it’s obvious what’s on it: equations. It would not be obvious if it had been called “MathUtils” — what kind of utilities is that? formulas? functions to normalise stuff? matrix kernels? constants? Who knows!

So: steer away from “assorted bag of tricks” modules because they’ll make you (or your colleagues) waste time (“what was in that module again?”), and you’ll eventually find yourself splitting them at some point, once they grow enough to not make any sense, with lots of mental context switching required to work on them: “ah, here’s this function for formatting text… now a function to generate UUIDs… and this one for making this low level system call… and… *brainsplosion*” 😬

An example that takes this decomposition in files to the “extreme” is lodash. Then it can generate a number of different builds thanks to its extreme modularity.

Update: Another take: write code that is easy to delete. I love it!

How to write a talk

Hey Sole, you have spoken on a lot of places and go to a lot of conferences, so maybe you have some advice on how to write a talk?

Yes, indeed I do! In fact, this question comes up so often that I figured it would be super useful to share my method with more people, rather than just individually 🙂

Before we start, allow me to highlight that this is my method, and it might not suit you. Talks come in many formats and shapes depending on their content, the audience and many other factors. I usually talk about technical stuff, and this guide is about writing that type of talks.

Also, if you’re the TL;DR type, I made you a flow chart (using draw.io):

how to write a talk flow chart

Continue reading “How to write a talk”

The (Spanish) guide to working in London

I’ve been asked about this topic so many times that I’ve finally decided to write a post so that I can forward people to it next time I’m asked about it. Please skip it if you’re not Spanish or interested on working in London 🙂

~~~

Continue reading “The (Spanish) guide to working in London”

Open letter to my dear trolls

Dear trolls,

I really appreciate that you want to spend your free time sending insulting or stupid comments, but it’s not really needed. As you can see if you use some minutes of your cheap and inexpensive existence, there’s a disclaimer in the comments form which says "I will feel very free to ignore or delete your comments, if I don’t like them, or they are not useful or appropiate.".

Which could be understood as "don’t feed the troll". And I am really doing that.

So please, stop writing nonsense, because you look really ridiculous. If you don’t like this page, GO AWAY! There are thousands of trillions of pages where you can dump your mental dirt and maybe you can even get +1 Insightful moderating points.

Take care.

Salsa Scener X: Empezar en la escena programando

Me ha llegado un mail hace un rato de un (por ahora) anónimo scener que quiere empezar a hacer alguna demo (cómo motiva eso de los tatuajes), pero no sabe si empezar con C/C++ o ActionScript, y además tiene un portátil no muy potente.

Y como creo que es una buena ocasión para dar un par de consejos útiles y que no se pierdan en el éter de los foros de escena.org, he decidido hacer a este mail el protagonista de esta semana 😉

Lo primero, no hace falta un ordenador con demasiada capacidad de proceso para empezar a hacer algo. Al fin y al cabo, la demoscene se trata de explotar al máximo los recursos de la máquina, ¿no? Yo estuve mucho tiempo haciendo pruebecillas con opengl en un pequeño pentium II a 350Mhz, con una tarjeta gráfica de 4 megas (una ati no recuerdo qué modelo). Por supuesto, iban lentas de narices, pero puedes ir aprendiendo conceptos con ello. De hecho, hasta hicimos un pequeño juego de asteroides (que presentamos a una práctica voluntaria de la universidad, todo sea dicho) y también un paseo por una escena 3D que mostraba objetos generados por revolución. Todo esto funcionaba en aquel bicho, así que empezar, se puede empezar, con opengl o directX (aunque yo de directX no tengo mucha idea, lo siento).

Otra posibilidad sería darle al rollo oldskool. Por “antiguo” que sea tu portátil, seguro que puedes hacer cosas con tinyptc. Tinyptc es una librería que permite acceder a un buffer en memoria de manera directa. ¿Para qué? Pues para emular el funcionamiento de las antiguas demos de msdos que (a grandes rasgos) para pintar los píxeles escribían directamente en memoria de video. Esto no se puede realizar directamente con windows (te daría un error de QuéEstasHaciendoChaval!!!), así que la librería hace de intermediario entre windows y tus demos. De esta manera, puedes aplicar muchos tutoriales de antaño, de una forma mucho más sencilla que con opengl/directx.

La pena es que sea un portátil, ya que un ordenador de sobremesa suele poderse actualizar cambiando la tarjeta gráfica por una mejor -siempre que la placa base sea más o menos decentilla-. Yo misma actualicé el mío, poniéndole una geforce 440 baratilla, como comenté por aquí, y los resultados no eran nada despreciables, consiguiendo ejecutar muchas demos bastante recientes.

Sobre actionscript, es incluso peor que intentar programar directX o opengl, ya que no se compila, sino que se interpreta cada vez. Así que no se ejecuta directamente sobre la máquina, sino sobre el player de flash. Lo bueno que tiene, es que es mucho más manejable que C. No tienes errores de punteros, ni tienes que reservar memoria. Al ser amigable puedes ir haciendo tus pinitos en gráficos, especialmente con la última versión de flash, la 8, que tiene cosas maravillosas como un putpixel, y cosas así, que no estaban en capítulos anteriores y paraban mucho si querías hacer algo decente. Sobre esto trace ha hablado alguna vez en su blog, ya que está bastante interesado en flash, incluso está tratando de hacer un engine 3D en flash.

También está la posibilidad de utilizar Macromedia Director, que tiene un acceso mejor a la tarjeta gráfica de que dispongas, y permite que lo que se dibuje, se acelere por hardware si la tarjeta así lo permite. También permite jugar bastante con blendings y demás, según tengo entendido, así que se le pueden sacar bastantes resultados.

Finalmente, si como dices el portátil es poco potente, no sé si lo habrás visto, pero hay un par de dvd’s de demos descargables, titulados demo or die. Más información en el blog de trace, otra vez.

Si alguien tiene cualquier idea, sugerencia o aportación, no tiene más que ponerla por aquí.

Hale, a pasarlo bien aprendiendo 🙂