Shaumik is an optimist, but one who carries an umbrella. An undergrad at Indian Institute of Technology Roorkee and the co-founder of The Blog Bowl, he loves writing, when he's not busy keeping the blue flag flying high.

Shaumik's articles

  1. Debugging in Git with Blame and Bisect

    When you are working with a huge code base, you may discover bugs in your code (or worse, in someone else’s code) that prevent you from proceeding any further in your development. You can checkout to an old commit to see if the bug was present there — but this is often the worst way of doing so. Imagine you have a hundred commits to check — how much time would be wasted?

    Thankfully, Git has two tools that help you with debugging. We will have a look at both and try to understand their use cases. Let us start by intentionally introducing a bug into our code:

    Adding an error line intentionally

    I’ve added a line to the file my_file that is unwanted and assumed to cause the error. I also add a few commits after that to bury the faulty commit. Let us verify that the faulty line has been added to the file by running the following:

    [code language="shell"]
    cat my_file
    [/code]

    Faulty file

    Notice the “Unwanted line” that is supposedly causing the error.

    Debugging with Blame

    Once you have discovered a bug, you may or may not know the location of the faulty code. Let’s say that you do. In our case, let’s say that you know my_file is causing the trouble. In that case, we can run the following command to get more information about the lines in the files, and the commits those lines belong to.

    [code language="shell"]
    git blame my_file
    [/code]

    blame contents of a file

    If you look at the output of git blame, you can see that commit 0bf63b53 is what introduced the bug (“Unwanted line”). If you want to check what else was changed in that commit, or want more information about the same, you can run the following:

    [code language="shell"]
    git show 0bf63b53
    [/code]

    running git show on the bad commit

    There you go — we now know which commit caused the error and what else was changed in that commit. We can proceed to fixing the error.

    Debugging with Bisect

    git blame helps you when you have some idea about what is causing the problem. What if you had no idea what is causing the error and there are hundreds of commits before you can go back to a working state? This is where git bisect comes into play.

    Imagine git bisect as a wizard that takes you through your commits to find out which commit brought in the error. It performs a binary search to look through the commits, before arriving at the one that introduced the bug.

    To start off, we need to select a “good” commit, where the bug is not present. We then need to select a “bad” commit where the bug was present (ideally the latest commit that contains the bug, so you can assign it as “bad”). Git then walks you through recent commits and asks you whether they are “good” or “bad”, until it finds the culprit. It’s essentially a binary search algorithm over the array of commits to find which commit was the first “bad” commit.

  2. A Web Scraper’s Guide to Kimono

    Being a frequent reader of Hacker News, I noticed an item on the front page earlier this year which read, “Kimono – Never write a web scraper again.” Although it got a great number of upvotes, the tech junta was quick to note issues, especially if you are a developer who knows how to write […]

  3. Create a Static Ghost Blog with Buster

    If we were in the mid 2000s, the unanimous choice to start a blog would have been WordPress or Blogger. The last few years have seen a rise in the number of blogging platforms, making this a great time for someone who likes to experiment. One such option, that was released to the public late last year, is Ghost.

    The best part about Ghost is the support for Markdown — which lets you focus on writing. However, if you are still skeptical, you should look at David Blane’s comparison of Ghost’s features to the big three.

    If you agree that you should give Ghost a try, there is a small hiccup. If you want to use Ghost.org for hosting your blog, the basic plan starts at $5 per month, restricting you to 10,000 page views (which you can easily reach if your post has a good day on Hacker News). If you download the source code, you would need to host it on a separate server, something that requires some expertise.

    But we can overcome those issues. In this post, I will show you an easy way to use Ghost for your blog, yet host it for free.

    What are Static Websites?

    A static site is a set of HTML documents or static web pages, nothing more, nothing less. It means that irrespective of the user requesting the site, the content would remain the same. On the contrary, for a dynamic site, the same URL might show different content to different users (for example, https://twitter.com would show me something entirely different to what it would show you, assuming one of us is logged in).

    A static website is often cheap or free to host as compared to a dynamic website. But, to generate and update a static site, you would need some specific skills. Unless, of course, you have Buster.

    What is Buster?

    Buster is a “brute force static site generator for Ghost”. Buster lets you preview the generated static blog and deploy to GitHub for hosting your site. It’s written in Python and it’s easy to install. You can either download through pip or clone the repository and install.

    The process that we will follow is something like this:

  4. 10 Essential Sublime Text Plugins for Full-Stack Developers

    When I started with web development a few years ago, Vim was my first choice of text editor. It was easy to work with and I could get the basics done without much hassle. Also, many developers like terminal based text editors because they get the same environment in both their local development machines and […]

  5. How I Set Up My Development Machine

    Every developer has a set of tools that make their life easy, without which their development life feels crippled! Over the years, I have developed my own set, which I describe in this post. The primary OS for my development related tasks is Ubuntu, and I would assume that you have one of the latest versions of Ubuntu (12.04+).

    When I started off developing, I only knew basic PHP. Setting up a development machine was as easy as installing PHP5, MySQL and changing the home directory of Apache2.

    But over the years I have changed as a developer and the tools that I use have evolved too- so it’s safe to say that next year, I will probably read this and smile, full of new tips and tricks.

    Except for Google Chrome and Sublime Text, everything else in the list can be installed through the command apt-get. Therefore, I have written a simple bash script which installs them in sequence. Note that a few (like mysql-server) require you to set certain options (like a password for the root user) before the installation can be completed.

    Here’s what I absolutely need in a development machine:

  6. 15 Little-Known Unix Commands

    Every developer needs to gain a certain mastery over the terminal. It’s not always possible to be physically present near the computer you are going to work on, in which case, you would need to remotely log into the machine. And while it’s true that GUI applications are available to accomplish this, they are often not as fast as getting terminal access (after all, it’s just the exchange of some text!).

    Regardless of whether you are a beginner or an experienced user of the terminal, I’m sure you like to pick up new tips and tricks. In this post, I’ll introduce 15 Unix commands you might not have heard of before.

    Note: For this post, I will use square brackets to denote any variables. When you actually run the command, you should substitute it with the actual value, with the square brackets removed. For instance, our first example, man [command] can be used as man cd or man grep.

    1. man

    Let’s start with a simple one. The man command stands for “manual”, as in documentation. If you want to know about any Unix command, you can run the following:

    [code language="python"]
    man [command]
    [/code]

    The simplest use case for man is to view the manual of the man command itself:

    [code language="python"]
    man man
    [/code]

    man is not necessarily itself a little-known command, and you would probably find it in any Unix tutorial. However, there are certain special uses which I would like to highlight that likely wouldn’t be in a common tutorial.

    If you need to know more about your ASCII characters, try this.

    [code language="python"]
    man ascii
    [/code]

    ASCII manual page

    Ever been confused whether pico- or femto-) is smaller? Try the following to get info on unit prefixes:

    [code language="python"]
    man units
    [/code]

    Man Units page

    There are many more such manual pages, and some of them are really funny too! (Tip: Try man xkill.) I will leave you to fiddle with that. Meanwhile, let’s move on to some more commands.

    2. cd -

    If you are working in a directory and accidentally changed to another one, there is an easy way to get back to the old one. Just run the following to get back to the last working directory:

  7. Using .htaccess to Prevent Web Scraping

    Web scraping, known as content scraping, data scraping, web harvesting, or web data extraction, is a way of extracting data from websites, preferably using a program that sends a number of HTTP requests, emulating human behaviour, getting the responses and extracting the required data out of them. Modern GUI-based web scrapers like Kimono enable you […]

  8. Scrolljacking and Accessibility: Are we Breaking the Web?

    Big brands have always started new trends and fads. A hundred years ago Kelloggs hit on the idea of marketing their cereals to children — a previously ignored sector in cereal marketing — by including a ‘prize’ with the box. Almost overnight the new ‘kids cereals’ category was created. Recently, Apple came up with the […]

  9. 10 Tips to Push Your Git Skills to the Next Level

    Recently we published a couple of tutorials to get you familiar with Git basics and using Git in a team environment. The commands that we discussed were about enough to help a developer survive in the Git world. In this post, we will try to explore how to manage your time effectively and make full use of the features that Git provides.

    1. Git Auto Completion

    If you run Git commands through the command line, it’s a tiresome task to type in the commands manually every single time. To help with this, you can enable auto completion of Git commands within a few minutes.

    To get the script, run the following in a Unix system:

    [code language="python"]
    cd ~
    curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.bash
    [/code]

    Next, add the following lines to your ~/.bash_profile file:

    [code language="python"]
    if [ -f ~/.git-completion.bash ]; then
    . ~/.git-completion.bash
    fi
    [/code]

    Although I have mentioned this earlier, I can not stress it enough: If you want to use the features of Git fully, you should definitely shift to the command line interface!

    2. Ignoring Files in Git

    Are you tired of compiled files (like .pyc) appearing in your Git repository? Or are you so fed up that you have added them to Git? Look no further, there is a way through which you can tell Git to ignore certain files and directories altogether. Simply create a file with the name .gitignore and list the files and directories that you don’t want Git to track. You can make exceptions using the exclamation mark(!).

  10. What’s New in Git 2.0?

    At the end of May, Git’s primary developer, Junio C Hamano, announced on their mailing list the much awaited release of Git 2.0. If you go through the release notes, you will find that there are quite a few changes that have been welcomed by the community.

    Git 2.0

    In this article, I’ll provide an overview of these changes. We will see two big changes that are creating waves, followed by a few miscellaneous ones.

    git push Default Behaviour

    If you use Git for your projects, you should know that the general format for pushing code looks like the following:

    [code language="python"]
    git push [remote_name] [local_branch]:[remote_branch]
    [/code]

    If you are a disciplinarian and use this syntax, you would not even notice this change in Git. However, if you were lazy and just executed git push, you would have probably received the following message:

    [code language="python"]
    warning: push.default is unset; its implicit value is changing in
    Git 2.0 from 'matching' to 'simple'. To squelch this message
    and maintain the current behavior after the default changes, use:

    git config --global push.default matching

    To squelch this message and adopt the new behavior now, use:

    git config --global push.default simple
    [/code]

    In Git 1.x, the default behaviour is set to matching. This means that all your local branches that have matching branches on the remote are pushed. However, in Git 2.0, the default is changed to simple, which would push only your current branch to the remote branch with the same name. If you want to continue with matching, as in 1.x, you can always change the default.