NGROK, undocumentation

OpenCart on LocalHost via NGROK

OpenCart Ecommerce System has A LOT of flaws, apparently written by an army of unknown developers spread around the Russian OpenSource Community, it shows very little cohesion in the source-code (Read spaghetti).

One of the more tangible caveats of this is the way that everything is implemented multiple times and in different ways… and this leads me to this following issue:

It doesn’t observe the Host-Header HTTP parameter but instead uses a hard-coded configuration.

Since I have no interest and ambition in contributing to OpenCart, and to to get it to run through NGROK on the local-host, I found the easiest way was to change the configuration…

 

Docker, Gulp, Node-RED, undocumentation

Development of node-red nodes w. docker has one big issue

Its a common known design decision by the Docker team that they don’t want to have support for symbolic links in their volumes, which means that using the Node-RED docker images while developing Node-RED nodes has a critical flaw since it means that the approach recommended by the Node-RED team which involves creating symbolic links to the source directory from the root of the Node-RED runtime.

Gulp to the rescue… Just setup a pre-launch Gulp script to copy the contents into the root of the Node-RED instance.

import {Gulp} from "gulp";

let gulp:Gulp = require(‘gulp’);

gulp.task(‘default’, function () {
return gulp
.src([‘../../your_project/**/*’])
.pipe(gulp
.dest(‘./node_modules/your_project’));
});

undocumentation

Hacks to get Loopback App’s running on Heroku

To get Loopback App’s running on Heroku, a couple of hacks are required due to the way Loopback manages it’s configurations.

The first issue to solve is to get Loopback to take the port number from the environment since Heroku uses arbitrary port numbers to target different applications.

There is probably a more elegant way, however I first wanted to stay out of node_modules files, so I opted to just focus on modifying server.js.

It’s actually very easy, since loopback internally supports passing arguments to the listen function all the way out from the server.js file.
It does this by switching between automatic configuration and explicit configuration from the arguments passed to the listen function.

So, basically it’s just amending the “start” function to fetch the port number from the environment and pass it as argument to the listen function.

I have done it this way…

app.start = function () {
   // start the web server
   var port = process.env.PORT || 8000;
   return app.listen(port, function () {
      app.emit('started');
      console.log('Web server listening at: %s', app.get('url'));
  });
};
undocumentation

Using node-sass with latest version of io.js

When using node-sass together with io.js, one of the problems is that it’s not updated to work with the latest version of io.js (at the time of writing, v.1.6.2).
Currently node-sass only supports io.js until v.1.2.

This causes the installation of node-sass and any libraries that depends on node-sass to fail to fetch all resources during installation, which eventually causes processes that tries to use the node-sass library to fail.

The error message during installation is (in my case, using io.js 1.6 on a MBP) the following:

Can not download file from https://raw.githubusercontent.com/sass/node-sass-binaries/v2.0.1/darwin-x64-iojs-1.6/binding.node

The error message in the process trying to use node-sass:

Error: `libsass` bindings not found. Try reinstalling `node-sass`?

The failing part is when the node-sass library tries to fetch binding files which are necessary to connect to some of it’s libraries, the solution is therefore to either change the code where it fails (easy, but messy, not my recommendation) or simply download the binding files and manually add it to node-sass (easy, and also a bit messy, but at least we don’t change the code, so a bit easier to manage).

So, what I did, downloaded the file from here:
https://raw.githubusercontent.com/sass/node-sass-binaries/v2.0.1/darwin-x64-iojs-1.2/binding.node

and save it to the following location:
node-sass/vendor/darwin-x64-iojs-1.6/binding.node

Now, when you execute a process that uses node-sass, it will find the file, and even you are not running io.js 1.2, the binding still works (only tried with io.js 1.6).

It’s by no means a perfect solution, but it solves the problem immediately and it’s something easily automated since it only involves downloading and copying some files, not changing some code…