Using npm for browserify and uglify

May 24, 2015

Previously I use gulp.js a lot; I’ll have a gulp file that does everything.

Why you should keep gulp tasks to the minimal

  • Gulp provides another interface to your actual toolchain, it’s much easier to understand the command line since those are pretty well documented.
  • You can trapped by the version of your toolchain supported by the gulp friendly plugin. For example, gulp-less may have an older or newer version of LESS.js that you want to use.
  • Lesser dependencies is makes things neater.

You should keep gulp where more complex tasks comes in.

Using just command line

Here’s an example of my typical toolchain. Let’s start with LESS.

LESS to CSS generation

This one is pretty straightforward:

I didn’t need JS and Internet Explorer compatibility and I want to be able to compress the CSS. This requires you to do:

Browserify

Browserify is a module bundler. I use React.js and browserify brings in the dependencies into one file.

The command itself:

You can also run the corresponding watchify command

Minifying JavaScript through uglify

You can uglify using the following command. The following command does compression and mangling:

Using npm to manage your scripts

You can put the less, browserify and uglify script into package.json’s scripts.

Now that they are in the scripts, you can do these:

Notice that you are also combine npm script commands by using &&.

If you use React.js, you will need babelify as well. You can add the following transform in package.json:

Browserify will use the transform in package.json and you do not need to specify the transform in the command line all the time.

In React.js you should compile the production version this way.

Using uglify, you can remove dead code.

io.js and node merging

May 17, 2015

I’m really excited for this:

io.js and Node.js is merging. io.js agreed to move into the Node Foundation and rename the “iojs” org on GitHub to “nodejs”. It will take some time to reconcile and it all is promising.

io.js TC Meeting 2015-05-13 stand up. We do that at Tremor Video too but it feels so different.

Initial thoughts on Strongloop’s loopback

May 17, 2015

Web development in Node.js is constantly evolving and my work as a frontend engineer pretty much ties me to Express.js most of the time.

This time I am looking for something that is more full-featured that has an authentication module built in.

Pros

It has a really sane folder structure to start with. It’s close to how I would have organized files as well. It has a pretty standard server, common, and client structure which made me feel at home.

What’s clever is also the Loopback explorer which gives you a quick view of your API.

Loopback explorer

I like how easy to see what the available API points are and it makes me comfortable to build an application that is fully REST.

What’s cool is also the slc commands which is reminiscent of Ruby on Rails. In the commands are Strongloop Arc (under slc arc) and adding persistent models.

Cons

Which brings me to the downsides. For Strongloop Arc, it bothered me a little that the GUI is proprietary. I’m not sure how pluggable is Arc but think it will be eventually necessary to write your own services to monitor the application. Either that or run your own tools over Arc.

It also took me a while to get the MySQL part working. I created the models and but I can’t seem to migrate the tables into my database. To migrate your tables in, you need to do this:

I created a file and save it to ./server/boot/create-models.js. This wasn’t immediately obvious to me. Once your tables are created based on what is in your models, you need to comment out this file so that it doesn’t run again. I’m probably doing this wrong.

I’m also a bit confused with the conventions too. For example, should the models be capitalized? Even the documentation seem to give examples differently. It didn’t help that Loopback changed quite a bit through the major version upgrade and documentation and Stackoverflow may not have the most up-to-date information.

Conclusion

Loopback’s still promising, I want to continue exploring it and if it works out, I’ll build something on top of this.

Making Travis build more efficiently

March 15, 2015

If you use open-source projects, I’m sure you’ve encountered Travis CI. Travis CI builds at every single commit. Each build can take up to a couple of minutes. I imagine Travis need to deploy the instance and run your build.

Here are some tips to speed that up.

Use Docker containers

Consider using Travis’ Docker containers as they’re much faster. I observed it shaved of 30% of my build time.

You can do that by setting sudo to false.

Caching your dependencies

If you use Bundler or Node, you can easily cache your dependencies as well.

Example in Node:

Example in Ruby:

Skipping the commit’s build

If it doesn’t need to be built, don’t build it. Add “[ci skip]” without quotes in your commit messages to skip a CI build.

That’s all

My typical .travis.yml.

And remember to give io.js some love as well. :)

CI is tremendously helpful. I use a combination of Travis and Codeship.io most of the time. I’ll write more on Codeship if there’s interest. Hope this helps.

How much of a web page is on React.js

March 1, 2015

This is pretty cool — curious how much a page is using React.js?

One the Web Inspector and run the following:

Source: Pete Hunt

New jsdom released with Node.js support

February 23, 2015

So the new jsdom no longer supports v4.0.0. I can’t say I am too excited over this!

This release relies on the newly-overhauled vm module of io.js to eliminate the Contextify native module dependency. jsdom should now be much easier to use and install, without requiring a C++ compiler toolchain!

Note that as of this release, jsdom no longer works with Node.js™, and instead requires io.js. You are still welcome to install a release in the 3.x series if you are stuck on legacy technology like Node.js™.

From GitHub

Underscore 1.8.0 released

February 21, 2015

Announced in Twitter:

You can see the full changelog.

There are some aliases that are now needed in Lodash for Underscore 1.8 methods as detailed here. I think it’s probably not worth maintaining parity to Underscore. Lodash clearly has proven itself as being more consistent and developer-friendly. It’s what an ideal open-source project should be, they have almost zero issues in the backlog and I appreciate they make decisions in the open through Github issues.

Underscore served me really well in the past but it’s time to move on.

jQuery shuts down plugin registry

February 20, 2015

…And endorses the npm approach. This is just so great:

The jQuery Plugin Registry is in read-only mode. New plugin releases will not be processed.

We recommend moving to npm, using “jquery-plugin” as the keyword in your package.json. The npm blog has instructions for publishing your plugin to npm.

jQuery plugin registry served well in the past but with more modern dev practices today, this approached has seemed outdated.

Some key advantages of using npm:

  • Easier to manage releases. Through semver you can indicate the likelihood to your release breaking a previous release.
  • Github centered. A common site where most devs are at. People can collaborate and post issues there.
  • Well integrated with CI. Most CIs (continuous integration) has support for npm and if you’re on Github and your repository is open-source, you can use Travis CI.

Resolving weekly php5-fpm crashes

February 20, 2015

My php5-fpm has been crashing for unknown reasons and this solved it for me! Thanks to this site — Puccinelli Digital — the author discovered what went wrong.

There was something wrong with logrotate and this is changed by an additional check whether php5-fpm is running.

This is my old configuration:

%d bloggers like this: