Tag: node.js
Nabin Nepal (Starx) docker docker-compose insecure-origin node.js service-worker udacity
June 30, 2016

How to run Witter app from Udacity “Offline Web Applications” course using docker?

This blog post shows how you can run the Wittr application from a Udacity course called ‘Offline Web Applications’ using docker. This is helpful if your development stack does not run on localhost and you want to overcome `insecure origin` issue of the browsers.

Note: This is blog post, so I have written a bit back story as well. If you don’t want to read about that clone https://github.com/starx/wittr.git run docker-compose up -d Done!

I was trying a course from udacity called “Offline Web Applications” and I got stuck in the point where I was trying to register the service worker. That was because the request to register the service worker was coming form an insecure origin. Nowadays, modern browser browswer have started to deprecate powerful web feature on insecure origin (more here)) and the course fails to address this issue because the developer’s stack can vary. So the question is What is secure origin?

In chrome “Secure origins” are origins that match at least one of the following (scheme, host, port) patterns: more here

(https, *, *)
(wss, *, *)
(*, localhost, *)
(*, 127/8, *)
(*, ::1/128, *)
(file, *, —)
(chrome-extension, *, —)

So it still supports developer in a way that is does not restrict request from localhost 127... or ::1. Which was another thing to fix because my development stack is not be the most common one as I don’t use localhost to test my work. I do these through vms, vagrant and nowadays from docker as well. This means that most of the time the test url is anything but localhost. So stuck on this for a while I tries several things, like trying to turn off insecure origin flag on flag, proxy, trying to point localhost to another ip is windows 10 bunch of bullshit which is just lost time. So I created a docker configuration to run the witter project.

file: Dockerfile

FROM node:latest

# Create app directory
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

# Install app dependencies
COPY ./* /usr/src/app/
RUN npm install

# Bundle app source
COPY . /usr/src/app

EXPOSE 8888 8889
CMD [ "npm run serve" ]

Simple enough for those who know docker basics. It binds with the ports in the host, so the project will run as localhost:8888 and localhost:8889 as the course wants. But if you want to know what it does, I am happy to explain it.

I have forked the course repo and have added this (with a docker-compose.yml as well) to the project itself at:

https://github.com/starx/wittr

Clone https://github.com/starx/wittr.git rather than the one provided in the course and run docker-compose up -d and continue with the course. I have also have created a pull request to help others but there is already 2 previous pull request pending without any comments, So I doubt it will be pulled.

Comments appreciated.

Nabin Nepal (Starx) asynchronous javascript node.js
March 10, 2013

Is it bad practice to shadow variables of a callback?

Question by hexacyanide

hexacyanidehexacyanide

Take the asynchronous Node function fs.stat() for an example. If I need to use fs.stat() on a file, then do it again later, the result is shadowed.

fs.stat(file, function(err, stats) {
  fs.stat(file, function(err, stats) {
  });
});

The err variable, as well as stats variable is shadow – does this even matter if I won’t be using the first callback inside the second? Is it better practice to rename the second callback variables?

Does overwriting these variables, once, or multiple times have any performance impact?

Answer by Starx

StarxStarx

Yes, it is bad practice. Depends on a developer viewing it of how bad it can get. If I got something like this, the first thing to pop in my mind would be

Why is he passing the err and stats to this callback?

fs.stat(file, function(err, stats) {
                        \    \
                         \    \
  fs.stat(file, function(err, stats) {
  });
});

When working in multiple instances of same function like you are doing right now. You have to make sure that all the variables can be accessed independently.

Unless you are sure one variable or construct is no longer is use, then you can re use that. But you have to mention this in a helpful comment to ensure another developer understands it.

Update:

Those variables on the callback functions have a scope limit, so they will not affect outside the function declaration.

An example of a valid case is:

  fs.stat(file, function(err, stats) {

  });

  //Another similar functions somewhere with same varialbes
  fs.stat(file2, function(err, stats) {
  });
...

Please fill the form - I will response as fast as I can!