Getting Started With Google Web Starter Kit

Yesterday (Friday 20 Jun 2014) Google released its web starter kit. Here’s the formal overview of the project (GitHub):

“Web Starter Kit is a starting point for multi-screen web development. It encompasses opinionated recommendations on boilerplate and tooling for building an experience that works great across multiple devices. We help you stay productive and aligned with the best practices outlined in Google’s Web Fundamentals.”

The first thing that comes to one’s mind is – ‘Is this a bootstrap or foundation alternative?‘.

As per the developers the web starter kit is a very basic boilerplate to get started on web development and it is not developed to compete with bootstrap, foundation or any other such framework.

I tried to develop a basic webpage using the web starter kit. The first thing you realize is its very light weight. Its built on node, ruby, sass and gulp. It was my first experience with gulp and have to say I was impressed. The way it organizes the website assets and helps in testing with various browsers is amazing. It even takes care of minifying your css and js files.

Getting started

Getting Web Starter Kit

Get the framework directly by cloning it from github.

git clone

The working directory will be: web-starter-kit/app

Installing Dependencies

As mentioned above, web starter kit is built on node, ruby, sass and gulp, which means you need to have these on your system before kicking-off with the starter kit.

You can check the same with following commands:

node -v
ruby -v
sass -node -v
gulp -v

If these commands respond back correctly, you are good to go, else install them as follows:


sudo apt-get install python-software-properties python g++ make
sudo add-apt-repository ppa:chris-lea/node.js
sudo apt-get update
sudo apt-get install nodejs

Ruby (using rvm)

sudo apt-get install curl
\curl -L | bash -s stable
source ~/.rvm/scripts/rvm
rvm requirements
rvm install ruby
rvm use ruby --default
rvm rubygems current


sudo gem install sass


sudo npm install --global gulp

This will install Gulp globally. Next, install the local dependencies Web Starter Kit requires:

cd web-starter-kit
sudo npm install

Finally to build the project, go to web-starter-kit/app and run:


That’s it! We are good to go now.

Starting the server:

Start the server by typing:

gulp serve

This will load you application on the browser. With gulp serve running, start editing your application in a different tab and observe the changes instantly in the browser.

Here is the demo webpage I made using the web-starter kit. Clone it to get basic idea of how it works. Fork to contribute building a better demo app. 🙂


Taking localhost To Internet

There can be many situations where you may want to get your localhost to internet. I was working on a project recently that involved using stripe. When working with tools like stripe that involves money transfers you need to listen to all the events generated in the process. Solution to that is a webhook. However the problem is, when in development, webhooks cannot connect (POST data) to your localhost. Therefore you need a way to take your localhost (development environment) to the internet.

Other such instance can be when you are designing a website for some remote client. You have completed all the development in your localhost, but before hosting the site your client needs to review it. You again need to somehow take your localhost to internet so that your client who is sitting in the other part of the world can review it.  There can be many such occasions like these.

There are several tools available for this purpose. Some of the prominent ones are: ngrok, PageKite and ProxyLocal. I however use ngrok, so this post will explain only about using ngrok in the simplest possible way.

ngrok is simple to use and hardly takes a minute to get started. It comes both as a free as well as paid service, we however will focus only on the free service.  To get started, you need to download the binary file from here. As the official website says, “a single binary with zero run-time dependencies for any major platform” and that’s all you need to get started.

Download the file to any preferred location and unzip it. On unziping you will get a binary file named ‘ngrok’ and that’s it!

Now to get your localhost online simply run the file with the desired port number. In most of the cases the port number will be 80 (default HTTP port).  In such case run:

./ngrok 80

And done! Your localhost is now on the internet. The above command will output something like this:



The address mentioned as Forwarding is the one you can use to access the localhost on the internet. In this case:

Similary say you are working on a rails project. As webrick’s default port is 3000, you will run:

./ngrok 3000

The output will be like:

ngrok 3000


Also you may notice, ngrok provides a web interface too that can be accessed on address:

Stop the tunneling by: Ctrl + c

Hope this helps you! 🙂


Solving WordPress Pretty Permalink 404 Error

While working on a project recently I came across a weird error. I was examining the wordpress taxonomy tables for slugs when I realized pretty permalink was not working for my localhost wordpress setup. On making a few google searches I realized people face this quite often and yet I had to google and experiment for about 30 more minutes before solving the issue, and therefore I decided to write this post.


First thing to check:

When WordPress creates custom permalinks or slugs, it overwrites the server’s defaults setups in its own .htaccess file.  For those who don’t know what .htaccess file is, here’s a quick definition (wikipedia):

“A .htaccess (hypertext access) file is a directory-level configuration file supported by several web servers, that allows for decentralized management of web server configuration. They are placed inside the web tree, and are able to override a subset of the server’s global configuration for the directory that they are in, and all sub-directories.”

In simple words you describe your site specific server configurations in this file. As wordpress does most of such technical things all by itself, you should ideally not be worried about what goes in this file. However there may be situations when wordpress is not able to create/modify this file due to file permission issues. Make sure this is not the case.

Go to the wordpress folder. In my setup (debian/apache2) I go: /var/www/wordpress

To list all file permission do:

ls -al

Incase the file is not present. create a .htaccess file using

touch .htaccess

Now make sure wordpress has all the authority to modify it. If you are in your local system, you can safely do:

sudo chmod 777 .htaccess

To make sure this worked, re-enable to pretty permalinks from wordpress admin panel, save the settings and open the .htaccess file. It should contain something like;

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Meaning wordpress is able to modify it. Check if your issue is resolved.


Step Two

If 404 is still haunting your posts it means the problem is beyond the scope of your wordpress directory. We now need to look for master server configurations. You can find them in your httpd.conf file.simpson404

Note:  httpd.conf is empty (or nonexistent) in some distributions.

That was the case with me, so we can edit apache2.conf instead. Typically you can find this file here:


In the conf file, look for:

<Directory /var/www/>
   Options Indexes FollowSymLinks
   AllowOverride None
   Require all granted

As you can see the AllowOverride option is set to ‘None’, therefore it is blocking our .htaccess file to override the server configuration for our particular site. Replace ‘None’ with ‘All’ to fix this. conf file should now look like:

<Directory /var/www/>
   Options Indexes FollowSymLinks
   AllowOverride All
   Require all granted

Now restart the apache server by:

sudo service apache2 restart

Check the links in the browser. As we just edited the main server config file, our links should start working.


Still No Luck?

There maybe be possibility that your issue is still not solved. One explanation can be that this master configuration is getting overridden somewhere. Check the ‘sites-available folder’ inside apache2. Here: /etc/apache2/sites-available

In 000-default.conf make the same changes as above i.e. setting AllowOverride All

Restart the server again and check the links in the browser.

Incase its not working yet, we come to the last thing that can go wrong. mod_rewrite is yet not enabled. To enable mod_rewrite for Apache do:

sudo a2enmod rewrite

sudo service apache2 restart

Check the links and they got to be frigging working now!!


Creating, Exploding and Defusing – The Fork Bomb

A fork bomb is a simple, Japanese emoticon looking, notorious, malicious, destructive, yet beautiful code. The motive is simple – keep on eating the system resources until the system runs out of resources and crashes.

In unix and likewise systems fork is an operation where process creates a copy of itself. Basically fork is a primary source of process creating in unix(and likewise OS).



:(){ :|:& };:

If you try this on your terminal, your system may stall and eventually crash, proving the bomb did its work (i.e. exploded) successfully. This kind of attack is called Denial-of-Service attack. As the name suggests, the attack intends to make all the resources busy or unavailable to the authorized user, hence interrupting or suspending the service.



Understanding the Bomb

This bomb is essentially a function calling itself recursively and the pipeline is made background. That said, lets visualize our code in this format:

:()          # Define a function
{ :|:& };    # The body of the function
:            # Invoking the function

If its still not clear to you, here’s the thing, our function name is ‘:’. Lets replace it with something else, say bomb, to make our code more readable.

bomb() {
bomb | bomb&

The trick here lies in invoking the process recursively and putting it in background. The ampersand operator is doing that for us. Since the function is being called recursively it will keep on creating new processes  and background them which will eventually eat all the resources and crash the system. If we do not put the process in background and just keep calling it recursively, it will still mess up the system but all the processes will immediately end after a stack overflow, which any system can deal with easily. Making the process background, however makes it immortal.


Defusing the bomb

The problem with this program is that even if you get all the PIDs and run a kill command, by the time the command executes many new child process will get created, which makes it difficult to stop.

One way is to freeze all the processes and then running a kill command. This can be done as follows:

killall -STOP processWithBombName   # Freezes all the notorious processes
killall -KILL processWithBombName    # Kills all freezes processes

However, there’s obviously a time constraint after which nothing can be done except a reboot!