When installing Mafalda packets, a problem I’ve suffered several times are install times, specially since I’m using git dependencies. I tried to reduce times by publishing some of the most common packages to npm, so removing need to install and compile development dependencies like Typescript, but still install times were huge for no reason, so I needed some way to measure the install time of each one of the dependencies. This lead out options like UNIX time command or tools like slow-deps, so just by change, I found on StackOverflow a reference to gnomon.

I’m advocate of automatization, and that includes not only CI/CD pipelines, but also I wanted to do it for documentation publishing. Mafalda is split in a lot of packages (currently more than 30!), so I wanted to have a single place where to publish the documentation of all of them. Github Pages allows to host a website for your organization or username by free (this blog and personal site already makes use of it), and it can also host automatically a website for each repository as sub-paths of your username/organization main website. Problem is, that it only works for open source repositories or for paid plans, and most of the Mafalda SFU repositories are private ones. So since the Mafalda SFU project website is already hosted on Github Pages as a public repository, I decided to store and serve from it all the other repositories documentation as well… doing it in an automated way :-)

Recently I’ve been involved in a new Typescript project all of my own where I would end up deploying it on production on a raw AWS machine, so no help from dev friendly PaaSs environments, as I usually prefer to work.

At Dyte we are now 44 persons, most of them developers, and each one has his own personal code style. This has lead sometimes to huge code conflicts when doing merges that create some annoyances and delays, so we decided to create an unified linting code style for all of Dyte projects (including a Jira ticket too!), just only we have been procrastinating it due to some other priorities. So, after the last merge conflict in a new project just created some days before, we decided to fix that issue once for all. Come and follow us to see how at Dyte we take code quality serious, and how at Dyte we don’t just simply apply a linter to our source code.

If you have a folder with multiple repositories that you want your commits use a different email account, but keep using your (personal) one for anything else, you can do it in two steps:

An exception happens when something we expected that should happen, didn’t. We can log them, but printing logs everywhere add a lot of noise, so it’s better to throw errors and handle them in upper levels. Also, a thrown error is easy to check and test, but a log message is not, so they are better for unit testing.

I’m a bit obsesive with code and architecture quality, and having them done like they could be put down on a textbook, or at least about they being used by others as reference of how things can be done right. I’ve always feel a bit frustrated that newcomers get and perpetuate bad habits, just because they learned them that way on the first place by thinking that was the way to do the things… Later, if things are working, people don’t give a sh*t on thinking about if there’s a better way to do it, both to improve their work quality or processes, or for learning and improve themselves, they just move on… So it’s better to do things right from the beginning, since later they are more difficult to fix, or simply you forget to do it. And at the end, just by doing things right on a first aproach, you get used to it and does them that way by default :-)

Javascript don’t have the concept of abstract classes, but it’s fairly easy to implement: don’t allow to instanciate them :-) Just check if the constructor of the instance we are creating is the own class instead of one of its childrens, and don’t throw an error if it is:

Respecto a arquitecturas WebRTC, no hay una bala de plata. Dependendiendo de cual sea el caso de uso, la arquitectura óptima puede variar de un proyecto a otro. Por este motivo, voy a explicar las principales arquitecturas de red que suelen aplicarse en proyectos basados en WebRTC (y principalmente aplicadas al streaming de video), y cuales son los pros y contras de cada uno de ellos.

Long time ago I talked about a pattern I use (a lot!) abusing the functional methods of Javascript to earn some memory and CPU usage. I promised to create a blog post, and almost 4 months after (too much energy draining work…), here is it.