Arshika Lalan

Google Summer of Code Reunion Summit

2014-11-03T00:00:00+00:00

In celebration of the 10th anniversary of Google’s prestigious Summer of Code program, they organized a reunion summit for mentors and students from the past 10 iterations of Summer of Code in San Jose, California from October 23-26. I attended the event as a student and a representative of the OWASP foundation.

I arrived in San Jose early morning on 23rd and checked in at the Hilton. I knew I’d be staying at the heart of Silicon Valley but was nonetheless pleasantly surprised to see the Adobe HQ from my hotel room!

The event was to be held at the Marriot, which is a block away from the Hilton. The evening was spent registering for the event and socializing with other developers who had flown in from all over the world. It was a delightful experience to randomly bump into developers and get to know about their organizations and open-source projects.

Next day was a fun outing to Great America. Google had bought out the entire park for the whole day just for the summit attendees! The GSoC celebration event was in the evening at the San Jose Tech Museum of Innovation. It was a wonderful (semi-)formal gettogether, full of geek speak and inspiring talks. Among the speakers were Chris DiBona, Peter Norvig, Dirk Hohndel and Linus Torvalds! Chris talked about how he came up with the idea of Summer of Code and the immense impact it has had over the past 10 years as it continues to grow. Norvig’s short inspiring talk mentioned how a bad craftsman blames his tools and how a good one wouldn’t differentiate between the two. Hohndel emphasized the need and importance of valuing criticism. And Torvalds implored budding developers to develop good taste and to know what to keep and more importantly, what to throw. Needless to say, it was a crazy evening. Selfies with the guests followed alongside lavish drinks and buffet.

The unconference sessions started Saturday morning. I loved the idea of having spontaneous sessions with lots of free interaction rather than the rigidity that is usually associated with regular conferences. The first one I attended was by Grant Grundler on Chrome OS. He talked about the future of Chrome OS and Android, the development cycle of a hardware-based product such as a Chromebook, the support model of Chrome OS and ended with a Q&A.

Next up was one on data visualization libraries. People talked about the libraries they were using and the applications they’d built using them. Others asked questions and lots of new ideas came up. We even maintained a collaborative etherpad.

There was a session on Processing by Manindra Moharana, who I’ve personally known from my DCE days (2010-11), and Andres Colubri. They introduced Processing, demoed artwork developers had created using it and showed how easy it was to get started.

Among other sessions I attended were ones on bioinformatics (scope, ongoing work and future), artificial intelligence (again a brainstorming and ideation meetup), big data, robotics and Google Cardboard! There were several lightning talks going on alongside at the Ballroom where organization representatives introduced their projects in under 3 minutes, always fun to listen to and get familiar with their work.

Sunday morning began with the much awaited trip to the Googleplex.

Sessions continued till the afternoon after which we had to bid farewell. Carol conducted the feedback session and delivered the closing address.

It was an absolutely awesome event. The feeling of getting to meet FOSS superstars in person, people who I’d been following on GitHub or Twitter for a while, was inexplicable. The idea of having a sticker exchange as well as a chocolate room was perfect. And most importantly, the organisers got all the basic things spot on: get open-source developers from different backgrounds in one place and make it as comfortable as possible for them to interact and have productive discussions with each other (no shuttling between the conference venue and accommodation, free and fast WiFi, awesome food and drinks, a formal celebratory dinner, schwag, and so on). A big shout out to Carol, Chris, Stephanie, and the entire Google Open Source Programs team for an amazing event!

Gradient Descent is Hard

2014-09-20T00:00:00+00:00

Remember that time when you told yourself, “I am going to work continuously for six hours and get this thing done!” and it didn’t happen? That time when you went to bed at three in the night with the resolution that you’d get up at seven and work, only to wake up much later?

Gradient descent is almost how water flows downhill along the direction in which height decreases most rapidly. It’s about aligning your path towards the local minimum by taking steps proportional to the negative of the gradient or derivative.

The thing is, in life, it doesn’t always work.

Tackling problems head on is tempting. Everybody wants to make a definitive to-do list on a daily basis and strike off items one by one. Habitual changes don’t come about this way. Getting up early in the morning and fresh for work doesn’t happen by going to bed at three and setting ten alarms for seven. It might work for a day or two, but you’re more than likely to revert back to the old routine or start cheating on the rules by pushing the time to the next half-hour round figure, etc.

Similar is the case with concentrating for long hours. Deciding right at the outset that you’re going to work continuously for six hours is almost never going to work. It’s too ambitious a goal. There are bound to be distractions and interruptions in such a long time interval. It might even seem okay to take five-minute breaks now and then because you still have n hours.

Set short-term achievable goals. Getting yourself to work without distractions for an hour is a much more practical target to aim for. In my case, it almost always gets extended to two or three hours. It doesn’t work the other way round though, i.e. the ambitious pledge governing the commensurate outcome.

Waking up early means you have to finish work and be in bed by twelve to manage a good seven-hour sleep which in turn means that you have to finish socializing and dinner and other errands by ten.

The key lies in taking care of the tangential, individually inconsequential but necessary components first rather than a direct gradient descent approach. Bigger things will happen when you get the little things right.

Collegiate Cyber Threat Competition - Wave III

2014-05-06T00:00:00+00:00

Deloitte has been organizing the Collegiate Cyber Threat Competition every year for the past 3 years. SDSLabs has been fortunate enough to be the winning team three years in a row now. Although they change the format of the competition every year and will continue to do so, their main idea is to get students and industry experts together on the same platform, and discuss and tackle challenges in cyber security. Taking part in the competition is in itself an immense learning experience. This post summarizes my experience at this year’s CCTC.

Round 0

Since SDSLabs has been participating in the earlier two iterations of CCTC, we were looking forward to Deloitte coming to our campus this year as well. Round 0 was held at several college campuses across India in February, and involved a written quiz in teams of 3. The problems ranged from web application security to networking and were fairly straightforward. 3 teams were shortlisted from each campus to proceed to the following rounds. Our team, Legacy, consisted of Abhay Rana, Ravi Kishore and myself.

Round 1

Round 1 was an online jeopardy-style CTF. There were multiple categories of problems such as SQL injection, XSS, cryptography, network analysis, etc which had difficulty-based point values. We were to submit a flag obtained by solving the challenge, and the 1st two teams to solve every challenge were given bonus points. Solutions to most of the challenges are given here and we had a lot of fun solving them. We solved all but one challenge and were happy to be on top of the leaderboard before it was frozen, although we were later told that the final leaderboard was much closer than we expected. Top 5 teams from Round 1 were invited for the grand finals held in Hyderabad on May 1-2.

Round 2

Round 2 was organized at the Hyderabad International Convention Centre. We landed in Hyderabad on the evening of 1st May, checked in at the Novotel and had some time to freshen up before meeting the Deloitte team for dinner. We were under the impression that the finals would take place the following morning and we would enjoy a peaceful night’s sleep. They seemed to have other plans for us though. After dinner, the competition was declared open, and each team was handed 2 identical laptops with 2 VMs each which we were told were known to be compromised. We had all night to analyze the systems, identify the extent of compromise, the malicious files/processes, the changes (filesystem/registry) made by them, the network activity, etc. and were to deliver a presentation on our findings to a panel of security experts from the industry. This was for 400 points. In addition, we also had to submit a STIX document to share the security threat information with our peers (in a real-world scenario), which was for 200 points.

Both the VMs were Windows machines. We weren’t allowed to mess with the host machine, or transfer files from the VMs to the internet or external media. Initially, our attention was divided over both the VMs but we were very early to figure out that one of them was a decoy (thanks to Nemo’s intuition). We used a host of tools such as CurrProcess, Wireshark, RegScanner, ProcessActivityView, SmartSniffer, Malware Bytes, HijackThis, etc. We kept logging our observations and steps on a shared WorkFlowy list.

This round was very exciting, more so because we hadn’t taken part in this kind of a challenge ever before and the whole real-world scenario of working in a Cyber Incident Response Team was very new to us. Although we were far from discovering all the malicious files and processes, we did well enough in our analysis to be declared the winners and were awarded INR 120000.

We thoroughly enjoyed taking part in this version of CCTC. Both round 1 and round 2 had brilliant challenges and we learnt a lot in the process. We are looking forward to next year’s competition and we have been promised that it’ll be bigger and better.

Workflow Automation with Grunt

2013-11-13T00:00:00+00:00

I recently came across Grunt.js while working on Erdős at SDSLabs. It is a task-based command line tool similar to Brunch, Maven, Gradle, and I love it! It’s primarily used to automate repetitive tasks in the development workflow and any (lazy) developer would fall in love with it. It takes care of tasks like compilation, minification, concatenation, versioning, cache-busting, linting, unit testing, etc. It isn’t limited to JS-specific tasks either, and it’s fairly easy to leverage the power of Node by using child processes. Also, it is well supported by an extremely active plugin development community. There may be other Javascript task runner solutions, but I don’t know of any at the moment that are worth taking a look at. In this post, I’ll go through the setup and a few Grunt tasks that I find really useful.

The basic setup

As I’ve mentioned earlier, Grunt uses Node.js and is installed via NPM (Node Package Manager). Once you’ve got those ready, install the Grunt CLI globally.

npm install -g grunt-cli
grunt --version

The second command should output your current command line module version. Next, create package.json, which keeps track of the dependencies we’re using in our project so we don’t have to push the node modules when collaborating with other developers.

This is what the project directory looks like which I’ll be referring to throughout this post.

my-test-app/
|--assets/
|--|--dist/
|--|--style.css
|--|--main.js
|--|--jquery.js
|--index.tmpl
|--package.json
|--gruntfile.js

package.json

{
  "name": "Erdos",
  "version": "0.1.0",
  "author": "Abhishek Das",

  "devDependencies" : {
    "grunt": "~0.4.0",
    "grunt-contrib-cssmin": "*",
    "grunt-contrib-uglify": "*",
    "grunt-hashres": "*",
    "grunt-env": "*",
    "grunt-preprocess": "*",
    "matchdep": "*"
  }
}

Run npm install, and NPM will go fetch these for us and place them in a node_modules folder (which should ideally be under gitignore).

Tasks

Create gruntfile.js which defines the workflow and tasks for Grunt to execute. Inside gruntfile.js, all configuration is done by passing an object literal to grunt.initConfig().

module.exports = function(grunt){

  "use strict";

  /* Load grunt modules */
  require("matchdep").filterDev("grunt-*").forEach(grunt.loadNpmTasks);

  grunt.initConfig({

    /* All grunt tasks go here */

  });

  /* Public grunt tasks - to be called from command line */
  grunt.registerTask('default', ['cssmin','uglify','env:production','preprocess','hashres']);

};

CSS Minification

This is used to minify all the CSS files for use in the production environment.

cssmin: {
  production: {
    src: 'assets/*.css',
    dest: 'assets/dist/style.css'
  }
}

This task can now be executed by calling grunt cssmin:production on the command line.

Uglify JS

This takes care of javascript compression and minification, thus reducing file size which is important for websites to load fast.

uglify: {
  production: {
    files: {
      'assets/dist/main.js': ['assets/*.js']
    }
  }
}

This task can now be executed by running grunt uglify:production from the command line. It will concatenate and uglify jquery.js and main.js in one file.

Environment Configuration

This is a grunt task to automate environment configuration for other tasks. It can be used with the grunt-preprocess plugin to build index.html on-the-fly.

env: {
  development: {
    NODE_ENV: 'development'
  },
  production: {
    NODE_ENV: 'production'
  }
}

Preprocess

As mentioned earlier, Grunt can preprocess files based off environment configuration.

preprocess: {
  html: {
    src: 'index.tmpl',
    dest: 'index.html'
  }
}

This task can now be executed by calling grunt preprocess on the command line. Our layout.tmpl can have logical blocks. This is useful in including analytics only on the production build, throwing in some ascii art, changing static asset paths based on environment etc.

<!doctype html>
<html>
  <!-- @if NODE_ENV = 'production' -->
  <!--
        ,---,.
    ,'  .' |             ,---,
  ,---.'   |  __  ,-.  ,---.'|   ,---.
  |   |   .',' ,'/ /|  |   | :  '   ,'\   .--.--.
  :   :  |-,'  | |' |  |   | | /   /   | /  /    '
  :   |  ;/||  |   ,',--.__| |.   ; ,. :|  :  /`./
  |   :   .''  :  / /   ,'   |'   | |: :|  :  ;_
  |   |  |-,|  | ' .   '  /  |'   | .; : \  \    `.
  '   :  ;/|;  : | '   ; |:  ||   :    |  `----.   \
  |   |    \|  , ; |   | '/  ' \   \  /  /  /`--'  /
  |   :   .' ---'  |   :    :|  `----'  '--'.     /
  |   | ,'          \   \  /              `--'---'
  `----'             `----'

  -->
  <!-- @endif -->
  ...

Cache-busting

grunt-hashres is an extremely useful plugin that hashes js and css files and renames the <script> and <link> declarations that refer to them in my html/php/etc files.

hashres: {
  options: {
    encoding: 'utf8',
    fileNameFormat: '${name}.${hash}.${ext}',
    renameFiles: true
  },
  production: {
    src: ['assets/dist/style.css','assets/dist/main.js'],
    dest: 'index.html'
  }
}

This task can now be executed by running grunt hashres:production from the command line. It would change <link rel="stylesheet" href="assets/dist/style.css"> to <link rel="stylesheet" href="assets/dist/style.130fdfaa.css"> and <script src="assets/dist/main.js"> to <script src="assets/dist/main.9c4cc83e.js"> in index.html. It would also rename the corresponding CSS & JS files in the assets/dist directory. This is much better than using a timestamp because the hash only changes when a file has been updated.

Build

Public grunt tasks defined at the bottom of gruntfile.js can be called directly from the command line. The default task is executed by running grunt. Environment variables should ideally be picked up from the project configuration file. Here is the complete gruntfile for convenience. If everything went right, you should see the following output when you run grunt.

This was just a basic introduction and walkthrough to using Grunt. Actual usage would definitely be more robust and complex. Grunt comes with pretty much everything you’ll need to use it on a large project and can be extended as much as you want.

Google India Community Summit

2013-08-05T00:00:00+00:00

Back in May, Google initiated it’s Google Student Ambassador Program in India. Heads of institutes were notified of this program and asked to recommend potential students. I was fortunate enough to be recommended by Professor SP Gupta (Deputy Director) among 10 other candidates from IIT Roorkee. Next, I had to submit an application explaining my interest in Google products, the program and everything else I had been involved in at any point of my college life. I made it through this round of sieving and within a week had to appear for an interview over phone as the final round of shortlisting. The questions mainly revolved around my technical knowledge of Google products, prior experience in event management and passion for helping the community grow. The interview lasted ~20 minutes but it was undoubtedly one of the most important phone conversations I’ve ever had. I obviously made it through the interview. Obvious because otherwise this post wouldn’t be titled the way it is!

The mail I received on 1 July established me as a Google Student Ambassador. In total, there were 266 other GSAs from 245 institutes across India. I was to act as a point of contact between Google and the institute, and evangelize Google products and the web in and around my campus. Most importantly, I was invited to attend the Google India Community Summit to be held at The Leela, Goa from August 1-4, 2013.

Google is a crazy company. And I mean that in a big way. Anyone who has been even remotely associated with the company or has followed it for some time would agree without a second thought. And it has a culture that keeps everyone motivated and passionate to build great products and do the best work of their lives. Every session of the summit reflected this crazy thinking, passion and motivation.

Deepak Sridhar, head of the Google Student Ambassador Program in India, had been in touch with all the GSAs from the beginning and had meticulously planned out the entire event with his team. “Do Cool Things That Matter” was what he said when he first addressed the gathering.

The agenda of the summit ranged from sessions for developers to those on marketing, ethics, search engine optimization and designing guidelines to live product demos to photowalks with professional photographers to theatre workshops. Googlers had flown in from Egypt, Mountain View, London, Ukraine, France & Africa to engage with us. A few who couldn’t make it joined us on Hangouts.

Lighter side of things included the walks at the beach every night and the cultural evening. Standup comedy by the super-talented Kenneth Sebastian set the ball rolling for the cultural show. Performances by groups from different parts of India followed and it was an excellent showcase of talent.

Before the summit, I didn’t know what to expect and prepare for. I wasn’t even sure of my role as a GSA. I’m glad I learnt a few things at the summit, and made a lot of new friends. This was my first visit to Goa as well as my first interaction with Googlers, and I’m sure it definitely won’t be the last, for both!

Summer of Code

2013-08-01T00:00:00+00:00

This summer has proved to be a busy one for me. I’ve been working in parallel on two major open-source projects. One is Emory University’s Intensive Care Unit Visualization & Analytics project, for which I was selected as a Google Summer of Code developer, and the other is OWASP’s PHP Security Project. It has been a huge learning experience so far.

ICU Visualization & Analytics

The ICU Visualization & Analytics Project under Emory University mainly deals with the development of an intuitive web interface for clinicians to monitor patient state in realtime. The visualizations include the data coming in from all the sensors as well as results obtained from algorithms running on the raw data. My initial work included trying out a few of the graphing libraries out there including HighCharts, Rickshaw, D3, Cubism. While bare metal D3 gave me all the power and customization options I wanted, Rickshaw was specifically built for handling large amounts of time-series data. There was no point re-inventing the wheel and I decided to stick with Rickshaw.

The application is JS-heavy and the stack consists of Node, Socket.IO, Backbone, Underscore, Rickshaw, D3, Foundation & jQuery. Prior to working on this project, I had some experience in the Backbone + Underscore + Socket.IO stack from my HackFlowy days. The major obstacle has been the proper handling of raw data coming in at 240Hz. Any mismanagement and the application starts to lag excessively after 10-15 seconds. My project mentor, Dr. Sharath Cholleti, has been highly supportive & appreciative of my work. We have bi-weekly meetings over Hangouts or phone and we set short-term, achievable goals and so far, it has worked out well for both of us.

PHP Security Project

The PHP Security Project, on the other hand, demands a sound knowledge of PHP and web security. The project has about 10 developers onboard and the mailing list is always flooded with doubts, debates and discussions. It is a project that addresses the OWASP Top 10 list and provides decoupled libraries, and a demonstrative framework providing easy to use standard security practices for PHP applications. I’ve been actively involved in the development of the Database Communication library and the HTTP Request / Response handling library.

The next library I work on is going to be one that handles CSRF. While employing per-page & per-session tokens has been considered the classic way to prevent CSRF, recently a lot of security experts have come up with their own solutions. I’m going through some of these papers at the moment to decide on the most secure and future-proof solution. Later this month, I’ll get my hands dirty and work on it’s implementation. This is a very important library and has to be handled perfectly.

The Setup

2013-03-28T00:00:00+00:00

Who am I, and what do I do?

I’m Abhishek Das, a B.Tech. student at IIT Roorkee. I write code, kill mosquitoes and wear many hats. But most of my time at the keyboard is spent producing software. A lot of these are internal projects for SDSLabs (a student group constantly striving to innovate and foster technical activities @IITR) and the rest are on Github. I ♥ open-source.

I’m also a pianist and have qualified upto Grade 6 from Trinity School of Music. I’ve been playing the piano since I was 5, and I’m 21 now.

What hardware do I use?

These days, the only hardware you need to change the world is a laptop. I use a 15” Dell XPS L502X that I got in 2011. It has an Intel Core i7-2630QM processor, Nvidia GeForce GT 540M graphics card and 8GB of memory. It is hooked up to a 1TB Seagate Expansion Portable Hard Drive. When on the move, I carry a 32 GB Nexus 7 and a 32 GB iPod Touch. Apart from that, I also own an ancient Archos AV500 Mobile DVR and a 16GB iPod Nano. I keep shuffling between the Blackberry Bold 9900 & Nokia N95 8GB to answer calls.

I am an occasional Counter Strike 1.6 assaulter and use a Razer DeathAdder mouse and Sony MDR-XD100 headphones to pwn enemies.

I recently started experimenting with the Arduino Mega 2560 and Leap Motion Controller.

And what software?

I am currently using Ubuntu + Cinnamon on my laptop. I browse the web with Google Chrome. My most used command line tools are probably git (on steroids with SCM Breeze), ssh, node, curl and autojump. Vim (bundled with the Ultimate Vim configuration) and Sublime Text 2 (with the simple Flatland theme) are my favourite code editors. I use a combination of Dropbox, Copy, Google Drive and SpiderOak to maintain a backup of all my data in the cloud. WorkFlowy is my preferred cloud-based note-taking application. I love it so much I even built an open-source version of it!

My Nexus 7 runs Android 4.3 Jelly Bean. My most frequently used apps are Feedly, Evernote, Keep, Pocket, Mantano Reader Premium, OctoDroid, HootSuite, ConnectBot and Chrome. Installed games include Flow, Super Hexagon, NFS Most Wanted, Temple Run, Riptide, Cut the Rope, Angry Birds and Subway Surfers.

Most of my non-coding time across all of these devices, is spent on the web. I’m a Hacker News addict. Gmail, Google+, Twitter & GitHub are my most used web-apps.

What would be my dream setup?

I’m pretty happy with what I have, within the constraints of reality.

If we’re willing to throw that out, I’d love a laptop with the profile and weight of the Chromebook Pixel with days upon days of battery capacity. Lots of RAM, SSD, and a fast but (more important) energy-efficient ARM core.

And if we’re talking super crazy, I’ll take the thought-controlled software and wireless brain connection, too, please.