2013.03.05

Mout & Modularity

Discussions about modularity are recurrent. Some people say that each function should be a separate module/file/package; others say that methods should be contained by a package and grouped by similarity/concerns; and there is still a 3rd group that thinks that a single namespace is the way to go. I will try to explain the design decisions that influenced the creation and current structure of moutjs and why single function packages are not always the best solution.

Read more…


2012.12.10

Travis CI : Continuous Integration Made Easy

This weekend I spent some time improving the structure of some of my open source projects repositories and also finally decided to add a Travis-ci hook to the most active/newest ones.

Travis is a free continuous integration server for open source projects that can be used to automate tests and help you deal with projects that have multiple contributors. If you are familiar with GitHub you probably seen their build status icons on a few projects before (on the image above). It can be used to test multiple languages like JavaScript, PHP, Python, Ruby, Java and many others. It also have options to notify the project maintainers every time the build status changes or on each commit. (email, IRC, campfire, etc)

It is really easy to setup it if your tests are already executed on the command line. If the tests needs a browser to work you can hook a headless browser like PhantomJS. - For my projects I’m just executing the tests on node.js for now since that should be enough to catch most errors. - Having a headless browser can help to double check if the code works on multiple environments.

Travis documentation is very clear and the amount of boilerplate is minimal, for a regular node.js project you just need a file named .travis.yml on the root folder containing:

 language: node_js
 node_js: 0.8

Read more…


2012.12.07

esformatter & rocambole

Yesterday I pushed 2 new projects to github, was unsure if I was going to do it since maintaining opensource projects can demand a lot of time but heck, I’m looking for contributors and they can be useful to more people, so why not?

I used editors/IDEs that had a good code formatter for a while and ever since I started doing more JavaScript development I missed a code formatter as powerful/flexible as FDT. I know WebStorm has a very good support for JavaScript but nowadays I’m a Vim user and it’s really hard to make the switch. I wish I could have the same amount of settings on a command-line tool, that way it could be hooked into multiple text editors (Vim, Emacs, SublimeText, Cloud9, etc…), have an external configuration file (so it could be shared between team members) and used to batch-process files. Being written in JavaScript would also be a plus (so it could be used inside the browser and have more contributors).

Read more…


2012.11.21

nodefy: convert AMD modules to node.js

I’ve been using amd-utils on almost all my projects and sometimes I find myself wanting to use some of the methods on my node.js programs as well, so I decided to write a tool to convert the modules automatically.

The tool uses Esprima internally so it will keep the indentation, comments and it should work as long as the code can be parsed by Esprima. It will do as few replacements as possible to avoid undesired side effects.

Check the project repository for more info and please use the issue tracker for feature requests, bug reports and questions/feedback.

Related


2012.01.16

Signal Emitter

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…