Thursday, October 6, 2016

Speeding up NPM

NPM is slow. I mean it is really, really slow when downloading packages. Partially because it makes a ton of requests to remote servers. That can be made faster!

There are 2 options that you'll find useful:

They both create a local cache that npm is later on interact with instead of the remote repository.


This one is really easy to setup and use. Just do
npm install -g npm_lazy
and use npm with the local registry like so:
npm --registry http://localhost:8080 install


This is a bit more complex. Nexus can be started as a stand-alone app quite easily but I would recommend using Docker as it is a far easier experience. So to start Nexus you type:
docker run -d -p 8081:8081 --name nexus sonatype/nexus
Then navigate to http://localhost:8081, login as admin/admin123 and create an npm-proxy. Select "Repositories" from the list on the left hand side, then from the "Add..." drop down at the top select "Add proxy repository", fill in as follows:
  • Repository ID - npm-registry-proxy
  • Repository Name = NPM Registry Proxy
  • Provider - npm
  • Remote Storage Location -
and click on "Create repository".

Use it as follows:

npm --registry http://localhost:8081/content/repositories/npm-registry-proxy install

What's the gain?

Depending on the project you'll see a 30-50 percent speed boost when downloading packages. For the example project that I used here are the stats:
No proxy npm_lazy Nexus
1m43s 1m22s 57s

Have fun!

Wednesday, October 5, 2016

Guarding Ember's computed properties

Sometimes you hunt a bug that just won't show. It just literally won't allow itself to be found. Recently I've had one of those cases. This time it was just unimaginable what has actually happened. Someone, possibly by mistake, has overridden an Ember.ComputedProperty thus breaking the chain of updates. On top of that the app did updates to the model using websockets changing other properties of that model. This resulted in very strange flickering of values in an edit field. Very hard to diagnose.

After the bug was fixed I started looking at possible ways to guard it in the future and possibly to find other places where the same happens. There are 2 cases where this might happend:

  • using this.set('property', 'value');
  • using Handlebars template

One possible solution would be to reopen the Ember.Object class and to override the Ember.Object.set method. Unfortunately it only guards you from explicit calls to this.set(...) and all the overrides from Handlebars template remain silent.

But there is hope!

There is another class, Ember.ComputedProperty that is actually used as the tool to get and set computed properties. It also features a set method that can be monkey-patched to do our check:

(function() {
  var orgSet = Ember.ComputedProperty.prototype.set;

  Ember.ComputedProperty.prototype.set = function(obj, key) {
    if (obj[key] && obj[key]._getter && !obj[key]._setter) {
      console.error("Overriding computed property " +
        key + " on " + obj._debugContainerKey);
    return orgSet.apply(this, arguments);

In this way if you override the computed property in a handlebars template or in the code you'll know about it. I only wish this would be part of the core framework. It would shave about 10 mandays of my project...

Here is an example project with the fix applied.

Have fun!

Edit on October 6th, 2016

I have been made aware of an Ember addon by Stefan Penner that addresses the same issue called ember-improved-cp. Although the idea of not using private API of the Ember.ComputedProperty is nice using that plugin is invasive and means using addon-provided macros instead of those that are provided straight from the framework which adds to the already high complexity of Ember-based projects. If you have a small enough project with few developers and you can afford that inconvenience you should probably go with the addon. If you need a plug-play-unplug solution you're going to get where you need to be with the monkey-patched version of Ember.ComputedProperty.prototype.set much faster.

Wednesday, June 29, 2016

Getting started with React and Redux

This is going to be a quick post as I have already created the whole thing elsewhere.

React/Redux/Mocha/Webpack example project is ready! Check it out on GitHub! It has all the bells and whistles one would need to get started with a brand new project so if you're like me - go ahead!

Happy coding!

Wednesday, June 22, 2016

Running tests with Mocha - ES6 style

So you have an ES6 code base and you'd like to test it using Mocha? Let's do it!

npm install --save-dev mocha babel-register babel-preset-es2015
echo '{ "presets": [ "es2015" ] }' > .babelrc
mocha --compilers js:babel-register *.test.js

Easy, right?

Let's go through it line by line. In the first line we're installing mocha, the testing framework, babel-register which will enable babel transpiler and babel-preset-es2015 which is required for the es6-to-es5 transpilation.

Then in the second line we're creating a .babelrc file that will tell Babel how to transpile our code.

In the last line we're configuring Mocha to run our tests using Babel as the compiler for files with js extensions. It'll look for all files ending with .test.js and treat them as tests.

Happy testing!

Monday, June 13, 2016

Teaching Promises to take '5'

Sometimes it is beneficial to execute an action in the Promise chain with delay. A good example would be flashing fields after they have been updated as a result of an Ajax call by writing something like:

Teaching the Promise class to delay execution is very simple: you add a delay method to Promise.prototype that returns a new Promise that waits using setTimeout and then resolves with the arguments that have been passed to the call to then. Here's how it looks:

Neat, right?!

I have seen a similar approach in this post but I don't quite like the use of then to execute another function - however proper this is not looking as good as the Promise.delay :)

Happy coding!

Sunday, June 5, 2016

ReactJS - the way forward

Let me tell you a story...

A long time ago I was at a point where my beloved technology, Delphi, started to decay as a viable option for future development. It started to change into this giant big ball of everything point-and-click and the beauty of the Object Pascal language was lost in the process. From my time with Delphi one particular component has always been my favorite: the TDrawGrid. Imagine if you will a grid component that all it needs is a prescription on how to present data in cells. That's right - present data in cells, not specify what is in them through some intermediate state. In fact TDrawGrid was so awesome each and every project that had to do with presenting data in a grid that I wrote was using it instead of TStringGrid. Making text bold or drawing icons in cells was just simply a matter of defining the correct handler and that was it!

You'd think that the ease of presenting data in a fancy way was the best part of it but it was not. The best part was that if the underlying data changed all it took was to invalidate a cell and the refresh of content happened automagically!

Like I wrote before Delphi derailed a lot from what I liked and it was time for me to choose a different boat to sail from now on. Realistically speaking there were only 2 choices: .NET and Java. Since I was working in a Java shop at the time it was only natural to lean towards Java and so I did. I started working on web applications, remote Swing applications, backend services - you name it. That was the time when I was introduced to Java Server Faces - a technology I intuitively knew was just bad. I looked for alternatives and as it turned out Groovy and Grails was my salvation at the time. I spent a year working on an internal application that I created from scratch in Grails and I was having the best time of my life.

Forward a few years and I felt like shedding the burden of being a Java developer and turned my attention to Ruby, Python and JavaScript. I absolutely fell in love with Sinatra and that was why most of my time outside of work I spent learning the ins and outs of it learning Ruby along the way.

Interestingly enough life has thrown me in the direction of client-side applications. That obviously means JavaScript, HTML and CSS. I have worked with jQuery, a bit backbone, AngularJS, Ionic.. And at every single turn it felt like the MVC pattern while great when working on the server is a bit artificially jammed into the browser world. It just didn't feel right, you know? The apogee was when I started working with EmberJS a few months back. Although I think that having a framework that gives you pretty much everything is not necessarily a bad thing (see Ruby on Rails) my opinion is that if you want to create an application that will prove resilient over time taking an all-in approach is not necessarily the best way to go.

And so, a few weeks back I arrived at a presentation from 2014 (man! so many good things happened in 2014!!!) where a nice lady, stressed out like hell, was trying to convey a message that MVC seems to not account for a good, maintainable architecture in the browser. Luckily enough there was an alternative - ReactJS. I spent a couple of days watching videos on ReactJS and Flux and the biggest surprise was how similar it is to the TDrawGrid from Delphi! Finally there is a single source of data that had a simple way of being presented and the refresh is just there and you don't even have to think about it. No bindings, no mutators, no fancy conventions like Ember enforces - just a simple render method that spits out the prescription of how things should look like.

Just like JSF and SwingML/XwingML in Java I really hope that MVC frameworks on the client will one day be a bad memory that lingers to remind me of times before ReactJS. Who knows, maybe I'll even go as far as starting a one day like I did with Who knows :D

Thursday, May 19, 2016

Baibulo is born!

Howdy, folks!

As promised (although it took forever and then some) my first Node module is released! Baibulo (version in Chewa) is a very simple versioned content server backed by Redis. Check it out - the README should be enough to get you started but if that is not good enough there is a working example that you can basically take and play with :)

I know there's probably a ton of things that should be done differently. Please share if you think it makes sense or not. Feedback is very much welcomed!

Happy coding!