Solving Shrink-Ray/ Iltorb issues in Yeoman Angular-Fullstack

We had a team meeting for a project recently where the objective was to learn how to use the Yeoman Angular-Fullstack scaffolder. Unfortunately my team and I spent the entire two hours debugging the generator, particularly the shrink-ray, iltorb and node-zopfli modules. I’m not sure what the issue is with these modules, but this seems to be a pretty common problem, so I hope it’s officially fixed soon. Until then, we discovered some workarounds that might be helpful temporarily.

These fixes have not been tested rigorously to see if they break the scaffolded app. Use at your own risk.


If you get an “ELIFECYCLE” error, this fix might work for you.

      1. Install Anaconda for Python (this step is not necessary but I find it a lot more convenient to do things this way).
      2. Run
        conda create --name snakes python=2
      3. Navigate to the folder in which you want to scaffold your app and run
        source activate snakes
      4. Now scaffold your app using
        yo angular-fullstack
      5. You should get errors showing up. Run
        rm -rf node_modules/
      6. Navigate to package.json. Remove the line that says shrink-ray.
      7. Run
        npm install
      8. Run
        npm install shrink-ray --save

And “gulp serve” should work! It did on most of the Macbooks I tested it on (around 4).


In windows we got a weird Windows SDK missing error. None of the fixes worked until we removed shrink-ray, node-zopfli and iltorb from package.json, reran npm install, and manually copied the three folders (from a working installation) into node_modules/. This is a terrible solution for many reasons (least of all that you don’t get regular updates), but it worked as a temporary fix. It’s probably fine if you just want to play around with the generator.


The GitHub issues page for this generator suggests using “compression” instead of “shrink-ray” for the problem I described, but I haven’t tried that method myself. Either way, I hope the issue is fixed with the generator soon!

The unKnocki – DIY Kickstarter Clones Part 1

The Knocki is a device that released on Kickstarter a while back and has (as of writing this article) received over half a million dollars in funding. The premise behind the Knocki is that it allows us to access different functions around the house using knocks on different surfaces. The Knocki is meant to be something that uses the context of the location to enable intuitive functions, for example knocking on your bedside table in the morning should turn off your alarm, or knocking on your kitchen counter should turn the microwave on. The idea is to reengage ourselves with technology in a more tactile way. Everything sounds good, right?

Not so much. While the idea is terrific, each Knocki costs $69 (at the Kickstarted super-early bird price) and will probably cost almost $100 at retail. The biggest issue with this is it limits someone who doesn’t have $300-$400 of spare cash to a single Knocki (atmost). But a single Knocki cannot deliver the full experience of connecting with technology around the house in a tactile manner. So my friend and I decided to create a DIY version of the Knocki that works just as well, but costs much less. The end product of our design (with miniaturization taken into account) cost approximately $70 for 3 “unKnocki’s” all costs taken into account. Adding each unKnocki only requires $8-$10 because we only add a transmitter module and use a common command center. For those of you interested in building your own, view the full instructable here.

We faced a number of challenges in the week or so that it took us to build the unKnocki. The first aspect we had to design was the detection of the knock. It seemed simple enough to detect one knock using a Piezo Buzzer and the Arduino, using the tutorial on the Arduino website itself! However detecting multiple knocks was slightly harder. Our first approach was to send all the serial data to python and then log the time difference between consecutive peaks. However due to serial connection issues (and other problems we simply didn’t understand) we ditched that idea. In the end, it was a simple “while loop” that ended up working, although it took us nearly 4 hours of work before this (obvious) fact dawned on us.

The second problem we ran into was the transmission of data. Our first idea was to use the 433 MHz radio to send the number of knocks from each transmitter directly to the Raspberry Pi. We tried this at first and were able to get the RFSniffer code from the 433Utils detecting the radio signals, albeit on the Linux terminal. No matter what we tried (which included VirtualWire, pi-switch-python, wrappers for RFSniffer, external libraries), we weren’t able to output this data to a python file for further processing. While this is something I would still love to do, we decided to move on to a simpler solution of having an Arduino connected to the Pi deliver data through the Serial port. This worked like a charm, and ticked another box off our list.

We also made a slight coding mishap in our initial code. We were using the Arduino millis() function to get the current time and store it as an integer to determine the time between knocks. However the program often stopped working after 2 to 3 minutes, because of an integer overflow issue i.e. the integer was no longer able to hold the value of the millis() function. We switched the variable over to an unsigned long which gives us approximately 50 days of runtime before any errors pop up.

The next issue was relatively minor – finding the right IFTTT channel to use for triggering events. We started off with Twitter, which had a 30 second delay between the knock and the event on the phone. We then used the Pi to send a Telegram message which was delivered almost as soon as the table was knocked. However Telegram was not compatible with IFTTT. We finally saw the solution in the form of the Maker Channel for IFTTT, which lets you make PHP requests to trigger actions. This was exactly what we needed!

And that’s it. A weeks work, summarized in four paragraphs and one instructable.

We are not saying a DIY solution is necessarily better than the Knocki. For the average person who may not be interested in electronics, the Knocki is a convenient easy way to get started. We simply offer a much cheaper solution with immense applicability due to our integration with IFTTT. All hail the unKnocki!

Mathematical Single Divs

Creating shapes from single divs using purely css is a fun way to see how much you can really do with css, and has even inspired amazing projects like this and this. My tryst with CSS has been brief and I don’t have nearly as much experience to create those kinds of divs. However, I recently read this article about using the CSS3 shape attributes to create polygons from a single div. I decided to use the magic of jQuery and CSS togethor to create mathematically accurate single divs. You can view the full project implementation here, and play around with a few functions yourself. I’ve put some photos of divs below for you to look at!






Using External Webhosting To Deploy Your Heroku App

When I had to add a custom domain to my Heroku app, it seemed like such an easy task. Atleast that’s what the tutorials promised me. They told me that it was as simple as adding the custom domain to Heroku through the command line (or through the Heroku Dashboard) and adding a CNAME record to my DNS provider. So I got to work and bought my domain at NameCheap, and sure enough once I followed all the steps herethings worked perfectly.

But I wanted to transfer the domain to my EcoWebHosting account because I got a free three year subscription there through my Udemy courses. Plus, that account gave me free email, which NameCheap wanted me to pay extra for. How hard could switching over be, right?

Wrong. I couldn’t understand for the life of me what I was doing wrong when I edited my DNS records on my EcoWebHosting domain manager. Now, I must warn you, this might purely be my incompetence speaking because the solution is breathtakingly simple. But just in case its a more common problem that I think it is, I thought I should put this guide out there.

Step 1

Go to the site from which you purchased the domain and find the setting that allows you to change your DNS provider. Under that choose custom DNS and set your nameservers to those provided by your hosting site. For EcoWebHosting the name servers are

Step 2

Login to your hosting service and create a new hosting package, and enter in your domain name. Once that is created, a navigate to Manage Domains and select DNS management.

Step 3

Under DNS management, look for the CNAME or AAAA record associated with www. Delete that record. Next add your own CNAME record with sub-domain www and CNAME

Step 4

Next login to your Heroku Dashboard and under the settings tab for your app, add the custom domains

After a while, this may take a day or two (though for me it was quite fast), you should be able to access your site through the domain. Just typing may not take your to your site, but might show you an index placeholder page generated by your hosting company.

Step 5

If you can access your site through the domain but not simply by typing, follow these next set of steps. Ideally, you should add another set of CNAME Records for the subdomains “” (first value left blank) and “*“. However, for hosting sites like EcoWebHosting, this can’t be done as the mail servers are already using these ID’s. The following is a simple workaround.  

Go into your file structure (accessible from cPanel through the Manage Your Hostings link on the site). Navigate into the folder containing a file called index.html. Inside this folder create a new file called .htaccess and type the following inside it

Redirect /

What’s happening here is that every time your site is opened through the domain, it is redirected to the domain.


And that’s it. It is a simple process, but one that I found no documentation for. Hopefully this lets you get your app running on a custom domain easily enough!