Working with upcoming posts in Jekyll

We used to work on more than one post at a time and publish them in future. So you just want to test them while writing the blog, but you don't want publish them to your live blog immediately. There are 3 different ways to achieve this in jekyll.

1. With published settings

You can include a line in your post meta data to indicate whether a post is published or not:

published: true


published: false

Set published to false if you don’t want a post to show up when the site is generated.

To preview your site locally, you can --unpublished option

jekyll server --unpublished

When you want to make the post to live, just remove the published flag or set it to true.

2. With future dated posts

You can write your blogs with future dated. There is a setting which does something similar - show future dated posts.

To preview your site locally, you can --future option

jekyll server --future

Make sure that you have following setting in your _config.yml file. This will hide future dated posts from your live blog.

future: false

3. With drafts folder

As you know, Drats are the posts you’re still working on and don’t want to publish yet. To get up and running with drafts, create a _drafts folder in your site’s root. You can place your posts inside the drafts folder.

- _drafts/

To preview your site locally, you can --drafts option

jekyll server --drafts

Make sure that you have following setting in your _config.yml file. This will hide drafts posts from your live blog.

show_drafts: false

When you want to publish the post to live blog, move your post from _drafts to _posts folder.

I recommend drafts folder for upcoming posts. Because it is much cleaner and easy to maintain when you work with team. If you have any other tips, share it on comments.

View comments

JAWS: The Javascript + AWS Stack

JAWS is a stack from Amazon web services(AWS) to ease the development of massive scalable web applications.

It is trying to solve important problems in scalable web application development.

1. No Backend servers: All web and mobile application needs backend server and database server. Since the JAWS back-end is comprised entirely of AWS Lambda Functions, you don't need to write your back end server in Node, Ruby, PHP or python. A back-end comprised of Lambda functions comes with a ton of concurrency and you can easily enable multi-region redundancy. So there is no need for scaling/deploying/maintaing/monitoring servers again.

2. Cheap: Lambda functions run only when they are called, and you only pay for when they are run.

You can build your app using following AWS services




As we know, there is no backend servers. Everything is written as Lambda functions. In normal backend server, we used to write controller to handle the routes. Similarly, each of your API URLs points to one of these Lambda functions and they are completely isolated from each other enabling you to develop/update/configure/deploy/maintain code for specific API urls at any time without affecting other parts.

You can either use the AWS Management Console's API Gateway User Interface to create your API, or define your API in the api_swagger.json file and deploy instantly via AWS's Swagger Import Tool .


The lib folder/module contains re-useable code you can use across all of your Lambda functions, which can be thought of as your Models. It's an npm module that can be required into your Lambda functions, like any other.

You can can require in only the code that your Lambda function needs.

// This only loads code needed for the User Model
var ModelUser = require('jaws-lib').models.User;

This way, all of the changes in the lib folder will be instantly available in every one of your Lambda functions when you run/test them locally.


The stack comes with command line tool to test locally and deploy.

# Run A Lambda Function Locally
jaws run

# Deploy A Lambda Function
jaws deploy

# Start A Local Server from site folder
jaws server

The static assets can be uploaded and served from S3 for super fast response times. Definitely JAWS saves lot of development time. You can try and let me know your comments and feedbacks.

View comments

GitHub is blocked in India

GitHub is blocked in India along with pastebin and imgur.

Since 17th December Indian ISPs have started blocking the free Git hosting repository GitHub. No prior information, no explanations, no notice, simple block. The ISPs in India are setting a bad precedent of freedom of speech. Only one ISP, Reliance returned a message that GitHub has been blocked as per the instructions of competent authority.

The Indian government also asked telecom operators and ISPs to block the image sharing site imgur and popular paste hosting website, Pastebin.

It is really a bad news for the fast growing Indian economy. Hope, it will be resolved soon. If you are in India, you can use the following solution.

Add Google DNS Server

This can be solved by adding Google DNS server. If you are a Mac OSX user, following steps will help you

  1. Choose Apple menu > System Preferences, and then click Network.

  2. Select the Network connection service you want to use (such as Wi-Fi or AirPort or Ethernet, unless you named it something else) from the list, and then click Advanced.

  3. Select DNS tab

  4. Click + to replace any listed addresses with, or add, the Google IP addresses at the top of the list:

    • For IPv4: and/or
    • For IPv6: 2001:4860:4860::8888 and/or 2001:4860:4860::8844

When you’re finished, click OK and then Apply. Now you can access the blocked sites.

For Windows user, How to change DNS Servers in Windows 7

View comments