A blog about design, code and some other stuff

When I released JS-Signals I decided to create a document explaining the difference between different kinds of Observers and the possible pros and cons of each pattern, and as you can see on the document every approach has its pros/cons and depending on the scenario the recommended approach might change.

Before coding JS-Signals I was using a very basic EventEmitter “class” that could be used to listen/dispatch arbitrary events but ever since I released JS-Signals I almost didn’t used arbitrary events anymore (because of the benefits of using a Signal), but a couple weeks ago I had to propagate changes on my model classes to the UI and the changes are coming from many different inputs, so the easiest way to keep everything in sync was to dispatch events every time my model objects updated with a new value. In that case it is way easier to use a string ID for the event type than to create a new Signal object manually for each value, since the project was already using Signals everywhere I decided to code a simple EventEmitter that would use JS-Signals internal mechanism (so I could use the advanced features if needed) but still allow arbitrary event types.

Read more…

(not sure if the pirate image + caption was created by Zeh Fernando, he sent it to me a couple years ago, forgot to ask him…)

Another polemic subject and something that I’ve been delaying for a while, I’ll try to explain how I got to my conclusions and I’m sure a lot of people won’t agree until they experience the same problem or realize how often it may happen on a real project and specially if it does happen with a code you don’t “own” and/or can’t change without compromising future updates… The advice is mostly about JavaScript (since it’s what I’ve been coding more lately and where I think the issue is bigger) but it also fits other languages.

Not so long ago I had an opposite opinion about this subject - I would always set everything to private and only changed to protected/public if needed - try to understand what made me change my opinion and pay attention every time you find yourself “tied” or doing lots of hacks just because you can’t monkey-patch a simple function/variable.

Read more…

There are a lot of build tools that covers specific use cases and/or try to cover as many scenarios as possible, amongst the most famous ones are make, rake, Ant and maven. I’m going to talk about why I’ve been favoring plain Node.js scripts as my “build tool” and how to do some simple things. This work flow may not be the best one for you and your team, understand the reasoning behind it and pick the tools based on your needs and preferences.

Read more…

Lately I’ve been favoring SSH to upload/delete files from a server since it’s faster and I feel it gives me more control/power, but I still use a regular FTP client for most of my daily use (since I don’t have SSH access to all servers), this is just a very basic tip that some people may not be aware of and that can boost productivity and reduce downtime during updates.

The Workflow

1. Upload new files to a _swap directory.
2. Move current files to a _backup directory.
3. Move new files from _swap to the parent directory.
4. Test live files.
5. Delete files inside the _backup directory.
6. Win one free internet.

Why?

The main reason is because moving files on FTP is way faster than deleting them, specially if you are moving the files to a parent directory, it can reduce the downtime from a couple minutes to a few seconds depending on how many files you are updating.

Another reason is that you will have a backup of the current files on the server and you can easily revert the changes in case anything goes wrong. - You should also keep all source files on a version control system and make updates when the site has as few users as possible (usually from 9pm to 9am) to reduce the chance of ruining everything…

That’s it!

Lately I’ve been avoiding inline documentation specially because JavaScript is a very loose language and I feel that inline-docs add too much noise to the code… But since documentation is very important if you want other people to use your code or if you have a large codebase I decided to create a simple documentation generator using nodejs to parse external markdown files. I tried to find other tools but none of them had all the features I wanted so I decided to code mine.

So far it’s a little rough around the edges, code can be cleaned a lot (I coded it really fast) and it isn’t as flexible/polished as I want it to be, but it’s working fine for my current needs.

The project is on Github and repository contains some example files with comments, you can check the amd-utils documentation for a live example - amd-utils documentation uses a custom template but it’s very close to mdoc default template, only extra feature is the “specs” and “source” links (since other projects probably have a different file/folder structure).

I’m not sure when I will have time to improve it but I already added a couple feature requests to the issue tracker. Watch it, fork it and contribute! If you want to report bugs and feature requests please use the Github issue tracker.

That’s it!