Blaze's Trailblaze through Syntax Error X

Tue, 15 Oct 2024 00:00:00 +0000

A Journey Begins

As a fresher, I was passionate about development but lacked the experience and skills to back it up. I had been attending lectures organized by SDSLabs, and it was during one of those that I heard about their hackathon, Syntax Error. Curious, I decided to check out some of the projects from previous editions. The creativity and innovation behind those ideas blew me away. Without wasting any time, I called my friend and excitedly said, “We have to participate in this!”

So, we started looking for teammates and eventually put together a team of four. Then came the hard part—brainstorming. We spent hours coming up with ideas, but we couldn’t settle on a single one.

On the day of the hackathon, during the opening ceremony, we were still completely clueless about what we were going to build. There was an AMA (Ask Me Anything) session after the opening ceremony, and I rushed over to some seniors and admitted we still didn’t have a single idea. They told me to stay calm and assured me that it wasn’t too late—we could still come up with something during the hackathon. That’s when it hit me: I love music, so why not build something related to it?

That’s when I stumbled upon the Spotify API. I was impressed by how well it was structured and how easy it was to use. I pitched the idea to my teammates, and we started exploring different ways we could use it. After a lot of back-and-forth (and with the hackathon already well underway), we finally decided to combine all our ideas into one.

By the way, our team name was cout<<hello world;, which, if you’re familiar with C++, gives a syntax error—very fitting for a hackathon called Syntax Error, right?

Our Ideas

We had four core ideas:

Moodify: You share your mood, and we suggest a song to match it.
Quizzical: A music quiz where you guess a song’s genre after hearing it.
KeyDM: Every key you press creates a beat, so you can make your own music.
Lyricsage: You input a song, and it gives you a summary of the lyrics.

Now, here’s the kicker—we had never built a full-stack application before. We only knew how to make simple frontend pages, but I had recently learned Python. That’s when I discovered Flask, a Python backend framework. We all said, “Jai Mata Di!” and decided to go with Flask for our backend.

I made a pact with myself: no sleep for the next 36 hours. I downed espresso shots like they were water and got to work. I even skipped all my classes the next morning. By the evening, my teammates and I remembered that we had our departmental freshers’ party, but we quickly decided, “Nope, we’re skipping that too!” We stayed focused on the hackathon.

The Final Push

We somehow managed to assemble all the parts of our code that we had made individually and got it to work. There were definitely moments of disapproval and miscommunication within the team, but we pushed through and managed to make it work in the end. It was already around an hour or two left for submission, and we had to make a video for our project. We scrambled to put everything together and submitted it just in time.

After submitting, I crashed—hard. I hadn’t slept for over 50 hours at that point (thanks to the hackathon and the previous day). I locked my door and went into deep sleep mode.

Later that evening, I woke up to loud banging on my door. My phone had hundreds of missed calls from my teammates. I panicked, thinking I had messed something up. I opened the door, and my friends were there, telling me we had just 10 minutes to show our project to the seniors. We ran to SDSLabs immediately, and after a few rounds of interviews and demos, we got the news: We won!

Wrap-Up

It was unreal. This was my first hackathon, and it was honestly an unforgettable experience. I don’t think I’ll ever feel the same kind of thrill and excitement that I had during Syntax Error. It will always be my favorite hackathon.

I learned so much in such a short amount of time. From figuring out how to use the Spotify API to building a full-stack app with Flask. The whole experience felt like a rollercoaster—full of stress, exhaustion, but also excitement. Winning the hackathon was the cherry on top, but the real reward was the journey, the team spirit, and everything I got to learn along the way.

Participating in Syntax Error made me realize that even when you feel like you don’t know enough or that you’re not ready, just diving in and figuring things out as you go can lead to incredible outcomes. It pushed me out of my comfort zone, forced me to think on my feet.

Looking back, I can’t help but smile. That sleepless, chaotic, espresso-filled hackathon taught me more than I could have learned in weeks of traditional studying. It also showed me that the developer community is filled with supportive people who are there to help you when you need it.

Since then, I’ve been hooked on hackathons, but Syntax Error will always hold a special place in my heart as the first one that sparked my passion for development.

Symphony of Achilles

Tue, 15 Oct 2024 00:00:00 +0000

Beginning of Chaos

While I was still figuring out the whole “college life” thing in the first semester, SDSLabs announced Syntax Error, the hackathon that took over the entire first year like a fever. I barely knew how to write a basic program, let alone build a project from scratch. As a fresher, I was pretty clueless, but but determined to dive into the world of development. I teamed up with Shashank and Vatsal—two guys I met through a chain of “I know a person who knows a person.” Little did I know, they would go on to become my go-to hackathon team, Higure Rakshas (Team ka naam kaafi shinchan-esque tha, so I thought I should tell you that)

We met for brainstorming sessions in our rooms, but we ended up doing everything except that- jamming sessions, cracking jokes, and getting onto each other’s nerves. After a while, we were super tired and before we knew it, we had procrastinated our way into the next morning without a single idea.

Our first thought was to look at past projects, you know, to “get inspired” or maybe sneak in a little help. We even tried using ChatGPT, but we only ended up with a list of terrible ideas. One project that really blew our minds was from last year’s hackathon—an Air Guitar project that was just so cool. For a brief moment, we even considered making an Air Hand Cricket game, but after a lot of deliberation (and a few laughs), we dropped it.

The first 26 hours passed with us doing everything but coding (Yes, hum hackathon ke beech me classes gaye the 🙃) . We came up with weird, funky ideas and kept going to the seniors with them. They patiently listened to our madness and pushed us in the right direction. After what felt like a million brainstorming sessions, we finally returned to our very first idea: Symphony—a guitar-controlled keyboard. (Definitely not as crazy as it sounds)

Excited, we pitched the idea to the senior mentors at Labs, and to our surprise, they told us that this was something we can work on! But then came the reality check—we had only 16 hours left to build the entire thing.

Forging Symphony

None of us knew where to begin, so we spent the next few hours researching, trying to figure out how to bring Symphony to life. Exhausted and on the verge of giving up, we reached out again to the mentors who told us how to start the project.

We decided to use Python, mainly because it was easy to work with and had a wide range of libraries. At one point, our project required us to learn something called the Fast Fourier Theorem (FFT).

After struggling with wave theories for hours (I absolutely loathe wave theories now), we stumbled upon a Python library that handled everything in just two lines of code. ( Lesson of the day : Python has a library for everything 🙂)

With our project finally complete, we thought we could sleep. But just as we were catching our breath, we realized we still had to record a video, push our code onto GitHub, and write an introduction file (Literal sleep deprived, coffee-driven, half-dead people) . Thankfully, the hackathon was extended by 30 minutes, and we managed to submit everything just in time.

After staying awake for more than 20 hours, dead tired, we crashed into our beds—only to be woken up by a call saying we had to present our project. Anxious and exhausted, we dragged ourselves to the SDSLabs room to present Symphony in front of the seniors. It was nerve-wracking, especially after not sleeping, but we somehow managed to get through the technical questions and use cases they threw at us.

To our surprise, we were selected to present Symphony in front of the judges via a virtual Meet call. This was the big moment. We answered every question we could, justifying the “need” for our guitar-controlled keyboard like it was a “revolutionary” product. I’m pretty sure we made up some answers on the spot, but well, that’s how you win a hackathon 😉.

Finale

In the end, with just 168 lines of code, a whole lot of wave theories, a string of funny GitHub commits, and endless banter, we somehow pulled off a winning project. We annoyed our roommates, called each other names out of frustration, but through it all, we created something we were genuinely proud of.

Syntax Error, my very first hackathon, will forever be etched in my memory. It hooked me to coding in a way I never expected and taught me a valuable lesson: nothing is as difficult as it seems if you put your heart into it.

P.S. Its “a-kee-lees” not “ak-hi-lesh”, no matter what people tell you :)

Cyberboy's Hackathon Episode

Fri, 27 Oct 2023 00:00:00 +0000

Pilot

It was our online semester, and Syntax Error had just been announced. Hackathons were a new concept then, and we were told that we could build anything we wanted. The only requirement was to build something “cool”.The first thing I did was check out some of the older projects created in the previous iterations of Syntax Error. I WAS IN COMPLETE AWE OF THE PROJECTS I SAW. I thought I’d never be able to build something that amazing in such a short time!

Nevertheless, I sought out to look for a team. It was an online semester, so it wasn’t easy to randomly get in touch with people interested in forming a team with me. However, there was this one dude I had met on an online AMA session conducted by SDSLabs. He had some experience in developing applications. After contacting some common friends, I got his number and dialed it. “Vansh bhai, mai Ashutosh bol rha hu. Syntax Error ki team bana li kya?”… Then the call went on for more than an hour discussing potential ideas and teammates, and we finally had our team (he would later go on to become my best friend on campus).

Fast Forward 2 weeks…

We have procrastinated till the eleventh hour and desperately need an idea. I am on a trip in Rishikesh and in complete panic, and we quickly call a Google Meet to finalise an idea. Less than 4 days were left for the hackathon, and we did not even have an idea! Then, there came a ray of light. SDSLabs had released its alum track, where some ideas were suggested by the Alumni of SDSLabs. On going through the ideas, we saw one idea which piqued our interest… “AIR GUITAR”. This could be a pretty dope idea to work on. I knew how to play the guitar, so I could program the chord recognition part.

We researched potential solutions and found a few computer vision libraries. Jackpot! We had everything we needed: the idea, the language (python cuz its easy 🙃) to make the project in and the library. But there was one big problem… None of us had a clue how to start :P (There weren’t many projects and tutorials then as there are now). Vansh called me up and said, “Aukat ke bahar lag rha hai”, to which we both responded, “kya hi ja rha hai”. The hackathon started and the next two days involved long hours of coding sessions, sleepless nights and coffee (did I mention unhealthy amounts of caffeine intake during the hackathon is a prerequisite too?)

After almost two days, we had a somewhat functional application. We tried creating a frontend too, but failed miserably and gave up on that 👍. We were ready to submit, and it was about 3 hours to submission (oh btw it’s 5 A.M. and we haven’t slept a minute). Vansh found a small bug and wanted to fix it before submitting. He also had to write the README file for the project. I was happy and somewhat satisfied with what we had made. Maybe I got too relaxed… Because the next thing I knew, I woke up to 30 missed calls and it was 15 minutes to submission! I jumped out of bed and immediately dialed Vansh’s phone. He used certain words which probably won’t be appropriate to write here (but you can probably guess they weren’t pleasant). The thing was that as I had created the team, I was the only one who had the option to finally submit the project. After creating a hurried demo, we quickly uploaded our project with its description.

Finale

A day goes by, and I am chilling in Rishikesh. Vansh is travelling to Indore, and we are all eager for the results. I leave for home the next day and both of us are travelling. I get a call, “Hi, my name is Somesh Solanki from SDSLabs”, I gasp eagerly waiting for his next words… “Congratulations you have been selected for the next round of Syntax Error, you will have to present your project to our judges on a virtual meet in the next 2 hours”. I am overjoyed! But then it suddenly dawns upon me, that both of us are travelling and no one has a stable internet connection. What to do now???

Amidst this emotional roller coaster, my sister mentions that IIT Roorkee is on the way back home. Before she could even finish her sentence, I call Solanki and ask if I can present the project offline. Next thing I know I am entering IIT Roorkee with a visitor pass (pretending to be Solanki’s younger cousin). This is my first time entering the campus (none of the first yearites had been called to campus yet). I rush to the Student Activity Centre and locate SDSLabs. I find Raikou (Pragyansh) over there and he helps me set up my computer. I finally present my idea to the judges. It was finally over. We had somehow managed to create and present our project in this chaos. Syntax Error will definitely be one of my favourite core memories from IIT Roorkee. We made a cool functioning project, made amazing friends and, most importantly, had a lot of fun!

P.S. Cyberboy now goes by the name hashkat and does not like to be called by his former alias.

Percy meets Poseidon

Thu, 19 Jan 2023 00:00:00 +0000

Like most kids, I was just a naive freshman entering this institute awestruck. I had the misconception that I knew how to code in Python and SQL (which broke down shockingly fast when I started doing actual development. Turns out

for i in range(100):
    print(“Hello world”)

Can only take you so far.) I had tried my hands on data science in school, but that too was on a very superficial level, with some knowledge of NumPy. MatPlotLib and Pandas [All thanks to the Informatics Practices course I took in school] I tried attending the Intro Talks of most, if not all, technical clubs under the Student Technical Council(STC), but being the distracted soul I was, I used to zone out, doing my own thing while the host blabbered on. It was during the SDSLabs Intro Talk that I suddenly heard, “We were banned from Deloitte CTF for doing too well; Rootex is our very own 3D game engine”. I had no clue what a CTF or Game Engine was, but I knew it was a huge deal. That’s when I decided, “No way in hell will I ever get recruited in this club.” It was during this time that I met Ashutosh Shrivastav, an SDSLabs fanboy who used to rave on and on about how cool the club was. All the while, I was thinking, “Impossible that I ever get in.”

That’s when it happened, Syntax Error hackathon! SDSLab’s first big event and my first hackathon! Completely thrilled, me and Ashutosh made a team together. We created an Air guitar. When he first suggested this idea, I readily said yes (while on the inside thinking, “Isn’t this project wayyy too ambitious? Are we even gonna be able to pull this off?”). There I was, watching tutorials at 2x speed, reading random codes to figure out what was happening. We celebrated small victories, like when we were finally able to detect our hand moving up and down 😂 I still remember it was 3 AM in the morning, and I couldn’t get this music to play at all. That’s when we hopped into the SDSLabs Open discord server, where Archit (who is a year senior to me in SDSLabs) was there to help us. Finally, we made the project, gave a presentation, and…. Well, that was it. Then came the dreadful waiting period where we (im)patiently waited for the results to be announced. and YES, WE RANKED 2nd IN THE OVERALL CATEGORY! Well, that was a great memory, and I made a friendship that I would cherish for years to come.[Hopefully, I mean currently, it’s just been a year]

Then came the [“insert dramatic sound”]…

The Trials of Apollo

I was still unsure about my capabilities to become a part of SDSLabs, but Syntax Error gave me the confidence boost I needed. SDSLabs organizes many events where the winners get a chance for a direct interview to SDSLabs- Syntax Error, Makers, Winter of Code, NoobCTF, Beginner’s Hypothesis, and so much more! I participated in Syntax Error and Makers, and I still remember when I went to get my Makers’ project reviewed. I entered the SDSLabs room in SAC with shaky legs. I am not sure how to describe it. There was an aura of knowledge, discussions going on about topics I had no clue about but everything seemed so fascinating. It turns out that despite making a seemingly complex project (It was a contactless laptop), my code was breaking down due to a simple ‘if condition’ [When it was pointed out to me, I was so confused, “Am I that stupid?”]. That was my last interaction with SDSLabs, or at least that’s what I thought. I still remember the call, “Your interview is scheduled for tomorrow at 10 AM” I was so paranoid about missing it, I remember telling three of my friends to wake me up, and went to sleep at 11 PM sharp. I went for the interview, which happened in 2 rounds, first was problem-solving. I remember well that as all panels of round 2 were occupied, my round 1 dragged on. The second round was based on my interests and general development. As I knew just python, I was asked a bunch of questions about that, and other stuff. I remember being panicky as I always was, but a 3y CSE senior Angad Kambli who was in that panel, just kept smiling, giving me the confidence boost I needed that maybe I was not doing that poorly. I tried to answer the questions to the best of my capabilities. Then the recruitment test happened. I gave that, too, just to be sure. I answered the questions, tried to do my best, and kept my fingers crossed. Then suddenly out of the blue, I got a call, “Hello, your final interview is scheduled right now.” I remember I was in Govind Bhawan at the time and ran as fast as I could to Labs, out of breath, I entered the room and gave the interview. Cut to 24 hours later…

The Owl Arrives

I remember getting the call. Ashutosh had just called me a few minutes back about how he got into Labs. That made me think maybe all the calls are made, and alas, what I feared has happened. Suddenly an unknown caller. I shouted in the middle of the road, all excited, and confirmed twice if they were sure they had called the right person. When we went for our initiation the next day, I was convinced they would stop me midway, saying, “Wait, we think someone pranked you.” But nope, it was all so real! We had our Intro Chapo and were added to the Slack workspace. I chose my username to be “percy” being a huge Percy Jackson fan [Later, I learned that Lab’s own PC, where most of the heavy processing work happens, is named Poseidon, which I found a happy coincidence] Most of the 2nd semester was filled with lectures and assignments where we learned a lot. After the assignments, we were introduced to various ongoing Labs projects as well as previous projects. This actually opened my eyes to what all is out there, so much to learn, and just damn!

We were then assigned our minors [Basically we are assigned a small issue on an existing Labs project which we have to complete within 2 weeks], and I chose mine, which revolved around graphics and one based on reading some research papers. We were given two weeks to complete it. I remember sitting in labs with Pragyansh or Archit, trying to make the head or tail of the project. At one moment, we practically created the American Psycho meme, with me saying, “It’s just not possible!” and Pragyansh saying, “Why isn’t it possible you…..!?” [Paraphrasing, of course]

The Triwizard Tournaments

Next came the hackathons. We participated in some national-level hackathons, as well as organised an internal hackathon too. Those are some of the best memories I have of the members of Labs. Intense 24-48 hours coding sprints trying to create a complete product that is impressive and probably the best and fastest way I have learned stuff. I remember I had a team with Tanmay (EE 2y) and Pragyansh (CSE 3y), and while all the other teams making their own project, we started screaming at the top of our lungs because our code started working unexpectedly, and everyone was just looking at us. To date, I am open to anyone telling me what happened there 😂

The Quests

Then came the internal sprints. I remember sitting in Labs one day, trying out Cryptography when suddenly Aditya (CSE 3y) asks me, “Kya karr rha hai?” I reply nothing, just random stuff. “Sprint karega? Chapo Milegi”. That was enough to buy me. We sat writing the frontend code of one of our projects for 48 hours straight, aiming to complete about 50% of the website. The best part was we wrote it in Svelte, a framework that not just me but none of our seniors had ever tried. In fact, as I am writing this blog, another sprint is going on to finish a dev project. I am glad for these because the amount of intense learning that happens within the span of these 48 hours of coding is probably more than I, with my distractions, can ever accomplish in a week.

Camp Half-Blood

“We are more than a club. SDSLabs is a family.” This is something that I have come to believe in this period of 1 year. Whether it’s personal life ki BT, or some tech mishap, I can always rely on Labs members and alumni. Hell, I had an anxiety attack at 4 AM in the morning, and I wrote a huge rant to one of the Alums and asked him to guide me, and he helped me out so much. Whether it’s random yearning for walks around the campus, hankering for RKB Tapri Maggi at 4 AM, or anything. Maybe something very frivolous has been bothering me, they have always been there :) From Button smashing while playing Tekken 3, or playing Minecraft, or anything! SDSLabs is genuinely a place I always feel at home.

H(e)aven

I always yearned for a crowd or group with whom I could relate and have fun discussing random tech stuff. I couldn’t say that is the case with the entire IIT Roorkee, but absolutely true for Labs. This is a place where no matter how weird or random your interest might be, you will definitely find someone to talk to and vibe with. Random senior shouting, “Yaar mai kya genius hu”., At which moment you would go and ask them about this very cool thing they have achieved. You probably wouldn’t understand it, but you will get some of it, google most of it, ask more and more questions, and learn so so soooo much. Sometimes randomly, your senior, while preparing for an intern or placement test, will learn something new, and will teach you something cool!

Final Word

I had a fantastic year at SDSLabs. Just writing all of this, the memories came pouring back. I can’t express in words what this all meant to me and what it all was. Just amazing. I wouldn’t trade it for anything else. Looking back, I guess this is just 10-20% of my actual Labs experiences, but it’s pretty boring as is XD, so I’ll leave you to be. Bye!

Design Experience Blog

Wed, 23 Mar 2022 00:00:00 +0000

A confused freshie

Metallurgical and Materials Engineering

When I signed up for a B.Tech in Metallurgy, I was almost sure that I didn’t want to pursue any of the related fields. One semester of classes (offline) helped me reinforce this belief! 😂

Exploration and introduction to Product Design

So, Like every other freshie, I tried my hands on several things..

Coding, Finance, Machine learning, Web Development, etc

The idea of being able to build products seemed very compelling to me. (Mostly due to the impact that it had on people’s lives, and at scale)

A very dear friend and senior, Ayush Rajput, was kind enough to walk me through one of his projects. That’s it, and I got hooked into the world of product.

Recruitments and SDSLabs

WoC and my first design project

Randomly scrolling through Facebook during my end sem exams, I found SDSLab’s post announcing WoC. I decided to give it a shot, and luckily, my proposal was selected.

I spent the winter break making my first design project, BloodASAP.

Let’s not get into the details. 🙈

It proved to be good enough to get me an interview at sdslabs.

Interviews

After a few rounds of interviews, I was officially a member of SDSLabs!

I still remember that call from Nipun. (senior @SDSLabs) I was really, really happy! (and super excited) (see photo below)

Inside SDSLabs

The Intro Chapo

We introduced ourselves to everyone else, enjoyed each other’s controversial opinions, and loaded ourselves with an infinite pizza party. 🍕

Amazed by the humility I observed in the room, I felt really blessed!

The birth of “sofu”

Everyone at labs needs a unique slack handle. My legendary senior Yash Khandelwal had already taken up “yash” which required me to think of a new one.

Being the laziest person in the room, I just picked up “sofu” from some random anime I found on Netflix. Now, most of my friends call me by this name.

(Controversial opinion: Animes are not any different from cartoons 🌚)

First Contribution (Minor project)

After a few lectures and assignments by our seniors, I was keen to make my first contribution to the clan, and I worked on the admin panel for the study portal with Yash (Khandelwal)

Though my work could never see its first daylight, I was really happy about it! (at that point in time…hehe)

First Goodbye (Farewell)

Photoshoot, Cosplay, Skits, and many memories to cherish as we bid adieu to our 4th-year seniors. (photos below)

First rejection (Major project)

Next up, I got to design PlayCTF (An open-sourced CTF platform) as my major project.

After putting in diligent efforts into PlayCTF during two months of my summer break, the first thing I got was heartbreak. 🤣

My mentors Nipun and Milan helped me realize how much better I could’ve done and very frankly called out the bad and the ugly. All charged up, I spent another month and redesigned it from scratch again. You can read the story of designing it here

Designing and shipping beast was a fulfilling experience that I probably cannot do justice describing in words.

Trips, Chapos, GameJams, and a plethora of things…

We all grew together!

We got countless chapos from seniors, Went on trips, Pulled all-nighters to build games, Documented projects, Launched products under tough deadlines with mates.

For me, the most valuable thing that I earned was friendship. (That’d probably last for a lifetime 🤞)

Interns, Placements, and Career

During my summer breaks after my 2nd and 3rd year, I interned at UrbanYogi and 1mg respectively, and finally got placed at Flipkart.

Interns and Placements were probably just a by-product of what we’ve been doing for three years at labs, i.e., building products.

Getting an environment that lets you discuss product and design regularly, being with like-minded people, and constantly experiencing the software building process gives you an extra edge.

My 2 cents on college life

Whatever you do, do it with absolute honesty. Everything else will fall in place!
Make good friends.
Don’t forget to have fun.

See you soon in the interviews! 🤞

Working with shaders

Sun, 27 Feb 2022 00:00:00 +0000

In 3D graphics, shaders are essentially programs that describe a behaviour about a pixel or vertex. Vertex shader runs for every vertex of the mesh, whereas a pixel shader runs for every pixel of the object.

You can think of pixel shaders as HTML5 canvas. You can manipulate the color of every specific pixel. In this blog, we will focus mainly on Pixel Shaders.

The UV coordinates

Pixel shaders coordinate system is standard coordinates are normalized to fit in interval {0,1} so that the pixel shader could scale for any random texture, which is essentially a color map, i.e. it explains which pixel gets what color.

A pixel Shader can then take input of any texture irrespective of its size.

You can quickly write pixel shaders on SHADERTOY. You can focus on writing shaders as it handles the pipeline for you. You write the code in essentially GLSL; there are a few differences, but it’s nearly the same thing.

Circle

Since this assumes no prior knowledge of writing shaders, I thought the first example should be explained thoroughly and built from scratch. If you have written shaders before or are familiar with the structure, here is the code

void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
    // Getting the uv coordinates
    vec2 uv = fragCoord/iResolution.xy;

    // This gives the length of uv
    float dist = length(uv);            

    // Initializing col with black color
    vec3 col = vec3(0.0,0.0,0.0);   

    // Initializing a radius
    float radius = 0.5;                 

    // Starting an if block
    if(dist < radius)                   
    {
        col = vec3(1.0,1.0,1.0);    // Setting col to white
    }
    
    // this sets fragColor which is our retrun value
    fragColor = vec4(col,1.0);         
}

This is the basic structure.

vec2, vec3, vec4 are just arrays of the float of sizes $2$,$3$, $4$, respectively.
fragColor is the output color of the pixel of coordinate uv.
length() is a function that returns the magnitude of the vector.
iResolutionis called a constant buffer. This specific constant buffer is provided by default from shadertoy and gives the resolution of the used window. There are other constant buffers, too, e.g., iTime.

Logic is elementary; we set the col (a vec3) to have rgb values of black initially and update it to white if the dist (distance from the origin) is less than $0.5$.

Running this, you’ll see the circle is more like an ellipse is also not centred.

Hence we update the uv coordinates as such:

uv-=0.5;

To fix the ellipse issue, we change the distance as follows:

float dist = length(uv*iResolution.xy)/min(iResolution.x ,iResolution.y);

Final Result:

Rectangle

How do we make a rectangle?

Just write a function that contains a few if statements like this.

Result:

One can also use Manhattan distance as our distance function like here. I just used some good old matrix transformation for rotating it. Result:

We can also use smooth steps.

Water Shader

A straightforward water shader is just using distortion. We can use a du/dv map and move it to create distortion. We can then add two or three maps to our uv values and mixed reflection and refraction textures to give a satisfying result.

Let’s try to make something more cartoonish.

Meet Voronoi Diagrams.

Voronoi diagrams are excellent. Essentially color of a specific point in a plane depends on its nearest point. This coloring divides the plane into multiple segments.

We can also generalise it to any metric possible, giving aesthetically pleasing results. You only need a set of points and a metric, and for that, there would exist a unique Voronoi diagram.

They are cool do check them out

So let’s make a Voronoi diagram and have the points move! Color it, and there is your cartoonish water shader.

Fire Shader

I decided to use Fractal Brownian Motion on simplex noise for this. Then I added a gradient and have uv.y continuously decreasing, giving the illusion that the fire is moving upwards. Yeah, it’s certainly complicated, so let’s go over them one by one.

Noise is just a pseudo-random number generator where the output is differentiable.

Simplex noise is a type of noise, like Perlin noise. The function noise() in the fire shader generates this.

The Fractal Brownian Motion combines multiple steps of Simplex Noise (or another similar noise function), each with a different frequency and amplitude.

Here is the result left is simplex noise, and right is Fractal Brownian Motion.

We color this and we’re done.

Cel shader

Playing Legend of Zelda is an experience. The graphics are aesthetically beautiful. It just feels different, but why is that? One can tell it is not going for realistic looks but rather making it cartoonish. Graphics that don’t aim to be realistic but try to achieve a style are referred to as stylized graphics.

But before that let’s talk about shading a 3-d object. Most people use Phong Shading; normals are interpolated across polygon faces, and through interpolated normals, we now color the pixel using the new normal. This mathematical trick saves a lot of polygon count as now we can have a realistic-looking surface with a low poly count.

We need to quantise the number of colors it can have. You can even quantise the normal angles if you get the normal data. Here is the final shader

## Edge Detection Edge detection is one of the ways to implement an outline shader. As the name suggests, it creates outlines. ![](https://miro.medium.com/max/1400/1*I_GeYmEhSEBWTbf_kgzrgQ.png) But before diving into this, let’s talk about image convolution. Image convolution is a way to change images using kernels(basically a matrix). Here is how it works. Let's assume an image $$I$$. $$I(x,y)$$ gives the pixel color at location $$(x,y)$$, $$dx (= dy)$$ is the pixel width, and $$f$$ is the kernel of $$(2a+1)*(2b+1)$$. $$f(x,y)$$ gives the $$(x,y)th$$ element with $$x\in(-a,a)\ and\ y\in(-b,b))$$ . Then the new image $$H$$ can be formed by: $$H (x,y)= \sum_{dx=-a}^{a}\sum_{dy=-b}^{b} I(x,y)*f(x+dx,y+dy)$$ So okay, what does it have to do with anything? If you notice, this gives us the ability to have a new image. The new image will depend on how the image reacts to the kernel, i.e., every pixel in the new image contains the information of its neighbouring pixels. We can use that; we can thus extrapolate if there is a sudden change of color; if there is a sudden change of color, that means it might be an edge. [Sobel operator](https://en.wikipedia.org/wiki/Sobel_operator) is one such kernel. [Here is an outstanding video explaining the same](https://www.youtube.com/watch?v=8rrHTtUzyZA&ab_channel=TheJuliaProgrammingLanguage) We first run a gaussian blur to remove noises( can be achieved by a [Gaussian kernel](https://www.researchgate.net/figure/Discrete-approximation-of-the-Gaussian-kernels-3x3-5x5-7x7_fig2_325768087)). Then we run a Sobel filter. After this, we get the edges. You can also apply [canny edge detection](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.420.3300&rep=rep1&type=pdf), which goes a step further.

A new component in the Jam File

Fri, 25 Feb 2022 00:00:00 +0000

User Persona ft. Kritika (the Freshman)

The online semester meant attending all (special emphasis on ‘all’) lectures, asking questions, and completing tutorials for the typical ‘ghissus’. At the same time, none of these actually had a presence worth mentioning in the life of other students of our infamous ‘covid batch’.

While I identified myself as lying somewhere between the two extremes of this spectrum, my undying urge to try something new made sure that I attended most of the intro talks of the campus groups. So when I came to know about SDSLabs, I knew I must give it my best shot because I would be with people who are not only ‘machau’ but also understand why a few extra clicks on a website can be a little annoying.

Although I was a little hesitant at first because I considered myself to be a ‘noob’, when SDSLabs announced the Syntax Error Hackathon, I decided to participate in it after my seniors encouraged me because “even if you don’t win, you’ll definitely learn”. My first hackathon experience was great. Our project was shortlisted for the final round, and I vividly remember spending over an hour selecting the ‘right font’ with a fellow freshman team member (also in SDSLabs now!).

Making the cut

Shortly after our end-term exams, the problem statements for the recruitments were released. As I worked hard on my project, I felt really motivated as the seniors helped me with reviews and guided me whenever necessary. This reminded me of a blog by an SDSLabs alumnus that read, “Help shall be provided at SDSLabs to those who ask for it”.

After successful submission, I was called for rounds of interviews. A few hours after my last interview, when I got a call from a senior saying, “Congratulations, you got selected! So, are you in?”, I replied, “Of course, I am 110% in (~insert multiple exclamation marks, happy WhatsApp stickers, dancing GIFs, etc.~ )

Brainstorming begins!

My first online chapo at IITR was the SDSLabs Intro Chapo. After getting done with the initial onboarding process of being added to the Slack workspace as ‘critica’ (with a “Stay on chat” advice from almost every senior) and other teams on GitHub, Figma, etc., we had a series of lectures and assignments on Website design, Game design, design tools like Figma, Adobe Illustrator, etc.

We were also introduced to the various ongoing and released projects, and their aim, expectations, design philosophy, etc., were explained in detail. I remember being amazed upon realizing how vast our domain of work is and I was especially drawn to Rootex, our game engine (because seriously, how cool is that!)

Work Mode: ON

We kickstarted our work as SDSLabs members with our Minors, where we worked on minor fixes and issues in the ongoing projects under the guidance of our mentors. I worked on identifying the UI/UX issues on Accounts, the authentication system of SDSLabs, and with that, I learned the importance of documenting your work.

Then we had our Majors, where our scope of work and learning increased. We were assigned projects based on our interests as well as our performance in Minors, and I got to work on Backdoor, the CTF platform by SDSLabs.

We design nice posters, and I also got to try my hands on Adobe After Effects while working on the release video of our project Studyportal. Apart from the excitement of learning something new, the sheer joy of getting a ++ on slack (our internal motivation system in action XD) is unmatched.

There’s always happening a lot out there in the tech and design world, so how can the environment at SDSLabs be possible unaffected? We would know about some events or hackathons being organized, and with the slightest possibility of finding an opportunity to learn or build something cool (and often winning some awesome prizes too!), we would have a meeting, divide ourselves into teams, and just get going.

Not to forget that internal hackathons, sprints, and lectures are a regular practice at SDSLabs.

Fun Mode: They forgot to design an OFF button for that

We indeed had a lot of fun online with meets turning into ‘bakar sessions’ and a few chapos. Even online farewell for our seniors was as grand as it could possibly be made virtually. But the real fun began when we reached campus.

With many more chapos (for successful Minors, Majors, any small or big achievement or for no good-reason-at-all) being given either at the best eating outlets at Roorkee or stacks of Pizza boxes and cold drinks being delivered at the SAC Building, the ambiance at SDSLabs is always perfect for learning from your peers and seniors, coming up with crazy ideas and implementing them, or just going on random late-night walks if you feel low.

Also, if you think that everyone at SDSLabs is a tech-nerd (we’d rather take pride in being called tech-enthusiasts, but ok), prepare yourselves for pleasant surprises. You’ll meet budding poets, gaming gods, great to not-so-good singers and musicians and people with crazy dance moves. Not to mention, you may ocassionally find yourself amidst a conversation about great movies and songs or some adventurous trips!

A lot of us spend most of our time at SDSLabs, so whenever any of my friends see me leaving my hostel room with my laptop bag strapped on my shoulders, they almost always know where I was headed to!

Key takeaway

To sum it up in one line, my journey at SDSLabs so far has been better than what I could have ever expected. With seniors playing a great role as mentors guiding me not only in the professional sphere but helping me deal with the ups and downs of life as well, and my peers being just the right like-minded people to have conversations and discuss ideas with, SDSLabs has helped me grow.

So if you want to meet some of the most amazing people in the R-land in their natural habitat, drifting away with the music as their fingers move effortlessly on their laptops to bring ideas to life or just chilling on the bean bags waiting for inspiration of a great project from the heavens above, just drop by at SDSLabs :) Recruitments will be held soon. If you have the slightest interest in anything I have talked about so far, do not miss the chance!

insert into SDSLabs values ("Pragyansh")

Thu, 17 Feb 2022 00:00:00 +0000

The First Semester

The Freshman

Like most of us, I was a naive fresher. I had made some small games during schooltime. I had basic knowledge of Python, C#, SQL and HTML (very superficial).

I used to spend a lot of time on academics (your typical “ghissu”). But I tried to attend most of the intro talks held by STC and got to know about SDSLabs. I knew about the group from the freshman guide too and had checked out some of their apps and projects.

A couple of weeks later, SDSLabs announced the Syntax Error hackathon. It was the first big event that happened in my first year (and was my first hackathon too!) so I was pretty psyched about it.

I ended up creating a 2D space shooter for my submission. Though I didn’t make it in the top 10, It was still a great experience for me and is a fond memory (My first hackathon, first of many)

Around this time I started developing an interest in Information Security and CTFs too. I attended some workshops by InfoSecIITR and found the field quite exciting.

Fast Forward to…

The Recruitments

SDSLabs held many events for recruitments (Syntax Error, Makers, noobCTF) and a recruitment test. I attempted their recruitment test which was mostly problem solving and basic programming questions. There was a section on technological advancements and questions like “Why do you think coding is a superpower?”. I found this very interesting as this was not there in other groups’ test and though this section carried no weightage, I attempted it (as it piqued my interest).

A few days later, I got a call for interview. The interview was conducted in 2 parts. First one was basic problem solving, and we also discussed basic networking and webapp vulnerabilities.

The second round was based on my interests and my ability to tackle real world problems. I was asked to come up with high levels designs for Tic-Tac-Toe and a library management system. This was also a fanboy moment for me as one of the interviewers was Twarit Waikar (SDSLabs 2021 alumnus), a game developer who had worked extensively on SDSLabs’s game engines Rubeus and Rootex. I had read his blogs and looked at his games and the game engines and was thoroughly impressed by his work (Making a game engine seemed like a very huge undertaking to me). At the end of this round, I was given time to let loose with any queries I had for SDSLabs, an opportunity I made good use of. I asked them about game engines, game development and web security.

The Second Semester

The initiation

I got a phone call informing me about my induction to SDSLabs. We had an intro chapo (online, coz covid) and got to know everyone there. We were added on the workspace apps and this got the cart rolling.

The semester was filled with lectures on various subjects (Git, Bash scripting, Web development, Game development) and corresponding assignments. The assignments spurred me to learn about something new and implement it within a deadline.

After the assignment season was concluded, we were introduced to the active apps and projects in SDSLabs. We were briefed on the status for each project and a received an overview of the tech stack, ongoing work, future issues and overall vision.

Minors!!

The day came when we were asked to pick up a project from the ongoing ones to complete a minor issue in them. This was sorting-hat-esque where everyone looked at that spreadsheet of projects and open issues and put their name against any one of them. Minors were completed in less than a week.

The Third Semester

Hackathons

By now we started participating in various hackathons (and managing to win some of them!!). Members would come together, form teams among themselves (sometimes even our alumni joined us) and we would participate in the hackathons. Sitting through hours of code sprints and preparing POCs, those were exhilarating hours.

Majors

After the minors, we had to choose our Majors: solving a large issue or implementing something important in the ongoing projects. We again met for the sorting and were assigned the responsibilities.

Releasing a Project

When a project comes to fruition and is ready to be open-sourced, everyone at SDSLabs is pretty excited about it. Seeing the hardwork of our members getting released ittruly a moment to be cherished. I witnessed the release of ZapDB and Studyportal.

Not just Dev

It’s not always software develpoment that we work on. We also work on IoT projects to make our workspace smarter (like presence detection using computer vision, WiFi locks). We have members passionate about information security and Data Science. We also have paper discussions in which we all read a research paper on related to CS and discuss it with other members. I was a part of the SDSLabs CSAW CTF team where we stood 2nd in India in the finals.

Summing Up

Mentors

A big part of what I got from SDSLabs are the amazing seniors and mentors who are ready to help me in every way possible. Be it some code blocker or real life problems, I know I can rely on them to help me out. There are people with diversified interests (Research, Information Security, Data Science to name a few) and there is always someone I can ask for help while exploring something new.

Not just work

SDSLabs is not that all-work-ultra-serious place. We have our chill sessions where people play games, watch movies or just dance to music. For me, it’s the ideal workspace and I spent more time in SDSLabs than anywhere else on campus (sometimes even sleeping over there). Minesweeper showdowns, minecraft adventures and struggling in Nioh is a regular occurence here

Ultimate Geek Heaven

When I got into IITR, I imagined it to be a place full of people passionate about tech and geeky stuff. People who would drool over latest tech advancements and would be interested in trying them out. While this might not be true for all of IITR, but SDSLabs surely fits the bill. It is that ideal place I had imagined, the Ultimate Geek Heaven.

Concluding

I had a great year at SDSLabs. Hours of code sprints, participating in various hackathons, vouching not to eat or sleep until I finish the issue/challenge, chilling out with friends, ranting away in one of those 2AM random meet sessions, discussing new things we learned about and coming up with new project ideas; it was quite eventful and fun.

Arrivederci

SDSLabs Recruitment Drive 2022

Thu, 27 Jan 2022 00:00:00 +0000

It’s that time of the year again, isn’t it? An endless barrage of workshops, competitions, lectures, and of course, recruitments. The sheer amount of information floating around can be overwhelming. Don’t sweat it, we are here to spell it out for you!

SDSLabs recruits students every year, selecting the best minds from the IITR Junta to join our cause of fostering technological innovation in the campus.

How do you get in?

There are many ways to land an interview at SDSLabs during the Recruitment Drive. These methods are:

Being amongst the top teams at the SDSLabs’ Syntax Error Hackathon 2022
Completing SDSLabs’ Winter of Code 2022
Being amongst the top students at any of our competitions mentioned below
Being amongst the top students in the SDS Recruitment Test and Design problem statement submissions

Syntax Error

Syntax Error is a campus-level hackathon conducted by us where students form teams and work together to build some amazing applications from scratch.

We call first-year students who are placed in the top 3 teams in the overall category for a direct interview.

Winter Of Code 2022

Students who were selected for SDSLabs’ Winter of Code 2022 and were able to pass all their evaluations successfully will be invited for an interview at SDSLabs during the interview process.

Competitions

SDS organizes a variety of competitions for the 1st year junta at IIT Roorkee. We like to call the Top 3 students from each of these competitions for an interview:

NoobCTF
- Capture the flag competition
- Hosted at Backdoor with InfoSec IITR
Beginner’s Hypothesis
- Data Science competition
- Hosted at Cerebro with DSG IITR
Algophobic
- Competitive programming competition
- Hosted at Codeforces with PAG IITR
Endgame
- Mathematical problem-solving competition
- Hosted at Erdős

Freshers with an exceptional submission at the Global Game Jam 2022 might also get a direct interview call during the recruitment drive.

Recruitment Test and Design Problem statements

SDSLabs conducts a recruitment test for freshers, having various sections including logical reasoning, programming, software development, and an ad-hoc section to show off your geeky side.

We invite the top scorers from individual sections and the top scorers overall for an interview during the interview process. Needless to say, the evaluation will be done based on your performance in individual sections.

Design based problem statements are released a week before the recruitment test takes place to test your skills in various fields of design like UI/UX and graphic design. Design submissions will be considered for getting recruited as a Designer at SDSLabs.

Apart from this, we are always open to new members who may have missed their shot in our recruitment drive. Obsessed with coding? Building something new every week? We insist that you join us! Send us your resume, at: contact@sdslabs.co.in.

Hoping that this has addressed all your doubts, we look forward to your enthusiastic participation in our recruitment drive.

Best of luck!

SDSLabs Recruitment Drive 2021

Wed, 17 Mar 2021 00:00:00 +0000

We recruit students every year and select the best minds from the IITR Junta to join our venture for leading the technological innovation in the IIT Roorkee campus.

We are open to all years of students of IITR to apply in our recruitment drive. However, the majority of our recruits are in their 1st year of study.

Recruitment Process

We provide you with four different methods of landing an interview at SDSLabs during the Recruitment Drive. These methods are:

Being amongst the teams at the SDSLabs’ Syntax Error Hackathon 2021
Completing SDSlabs’ Makers 2021
Placing top at any of our competitions mentioned below
Placing amongst the top students in SDS’ Recruitment Test and Design problem statement submissions

Syntax Error

We call first-year students for an interview who placed in the top 3 teams in the overall category at Syntax Error.

Since the hackathon winners have already been announced, the respective teams will be called during the interview process.

Makers 2021

Students who developed on a project idea released during Makers 2021 or developed on their own project idea of a similar caliber will be invited for an interview at SDSLabs during the interview process.

Competitions

SDS organizes a variety of competitions for the 1st year junta at IIT Roorkee. We like to call the Top 3 students from each of these competitions for an interview:

NoobCTF
- Capture the flag competition
- Hosted at Backdoor with InfoSec IITR
Beginner’s Hypothesis
- Data Science competition
- Hosted at Cerebro with DSG IITR
Algophobic
- Competitive programming competition
- Hosted at Codeforces with PAG IITR
Endgame
- Mathematical problem-solving competition
- Hosted at Erdős

Recruitment Test and Design Problem statements

SDSLabs’ recruitment test has various sections, including logical reasoning, programming, software development, and an ad-hoc section to show off your geeky side.

We invite the top scores from individual sections and the top scorers overall for an interview during the interview process. Needless to say, the evaluation will be done based on your performance in individual sections.

Apart from all these methods, we are yearly open to wildcard entries. If you somehow are not able to make it this time, you can reach out to us at contact@sdslabs.co.in with your CV after the recruitment drive.

We hope we have made the entire recruitment process clear for all the enthusiasts out there. We look forward to seeing you test your skills at our Recruitment Drive this year.

Best of luck!

Designing a practice-session platform for Hackers — UX/UI Case Study

Thu, 07 May 2020 00:00:00 +0000

The following is a UX/UI Design Case Study describing how I designed a platform(PlayCTF) for the CTF players to help them focus on what they love doing- “Hunting down flags.”

Have you ever wondered how Cybersecurity experts and bounty hunters sharpen their axe? Yes, they participate in CTFs to do so.

PlayCTF is an open-source platform that can be used by anyone to host an individual Jeopardy-style CTF at a time, Currently under development at SDSLabs (A student-run campus group under Software Development Section, IIT Roorkee.)

But before we begin, let me get you some context.

What is a CTF?

CTF(Capture the flag) is simply a cyber-security game, and it consists of mini-challenges whose security the players need to break in order to get some secret strings(flags), which lead them to victory. This specific kind of CTF is called Jeopardy-style CTF.

A typical flag might look something like this.

My Role in the Team

We worked as a team of 1 UX/UI Designer(me) and 3 Developers.

Luckily the developers I worked with were all regular CTF Players and were always up for a chat.

My role was to understand the requirements of the user(CTF Player) and to provide the best possible experience to the user while taking into account our technical abilities and constraints. Key deliverables being High-Fidelity wireframes.

Understanding the Problem

Some organizations like cyber-security groups and recruiters need to organize tests/practice-sessions, but do not have a platform on which they could deploy their challenges. They either deploy these challenges on self-built quick and dirty websites or end-up paying giants like cftd.io or ctftime.org in order to organize these CTFs. How might we help them get this tedious work done without asking for much effort?

Knowing the Competition

I started using some common platforms like ctfd.io, ctftime, backdoor, etc. I tried to understand these products inside out and how our solution differed from these platforms. Also, where I could provide the user with a better experience than these products.

“We decided to build an open-sourced solution that anyone could use to organize an individual Jeopardy-style CTF using their own server.”

Understanding how players function - User Flow

Some of my friends participate in CTFs quite regularly, I used to observe them solving challenges.

CTF Players are usually quite competitive in nature and they -

Need to plan how to efficiently use their limited time.
Want to quickly solve challenges submit the flags.
Want to keep track of their progress and current standings.

Usually, a CTF challenge requires a player to -

Minimize the window

Hunt the Flag

Come back and Submit the Flag

In my opinion, this process where the user leaves the platform and again joins back needed some extra attention!

Ideating the Structure - Information Architecture

Wireframing

The heart of this product lies in the “Challenges Page,” this is where a CTF player would spend the maximum amount of time, switching between challenges, strategizing how to use his/her precious time and solving those challenges, and submitting the flags he/she acquired.

Throughout the wireframing, I focused on how to make this process easy and fast for the user(player). I ended up with a few iterations while taking continuous feedback from my friends who regularly played CTFs.

Iteration 1

I tried using cards for each challenge, which redirected the user to a Challenge Modal. Here the user could access all the essential info which is required to find the flag.

This approach seemed feasible at first because it presented the user with a large number of challenges without much scrolling.

Later I realized what mattered even more to our users was the ability to switch between various challenges and submitting flags as quickly as possible. This modal-based approach slowed it down quite a bit!

Iteration 2

I tweaked the card a bit by adding the option to submit the flag externally, even without opening the challenge description. Also, I provided the option to switch between modals(challenges) using keys or clicks. Maybe it didn’t remain a modal anymore.

Still, it did not seem to solve the purpose. (Speed) This was mostly due to the use of the “MODALS.” I decided not to use them for the next iteration!

Iteration 3 (Final Iteration!)

The final version, which I decided to settle with was a trade-off, it showed fewer challenges to the user(player) but significantly increased the ease and agility with which the user could now switch between challenges and submit flags.
It was somewhat a blend of the first two iterations I managed to come across.

Final UI

Now I’m presenting the final designs. SDSLabs design guidelines were followed while designing these screens. drumrolls

Although this was the default color scheme we chose to provide, but the color palette can always be changed by the admin to suit his/her needs like the ones shown below. (Open-Source perks)

One of my friends suggested me to try this color palette. (for fun)

Conclusion

This was my very first design project and I learned a lot of things along the way-

I had never worked on a product from scratch.
I didn’t know what was a style guide and how it could be used to achieve consistency.
I had to make illustrations. I learned a bit of Graphic design!
I had to collaborate with developers, make them understand what was inside my head.
And most importantly I understood how the iterative process worked when followed along with feedback.

Moreover, it taught me how to work well with people around me, to manage collective efforts, to meet deadlines, to not fall in love with my work, and to seek feedback open-heartedly.

Thanks for reading. ❤

Want to create something? I’ll be happy to help! Reach me at - ychoudhary@mt.iitr.ac.in

Easy Access Distribution using Keyhouse and Watchdog

Sun, 05 Apr 2020 00:00:00 +0000

Access distribution is always a problem. Every organization is looking for an easy way to do access management, but at the same time, also wants to ensure security. We at SDSLabs also need to ensure that the server which is responsible for access management is always live, or one might end up being locked out of the server. Hence we developed a tool to address this problem, which started as a couple of bash scripts but is now a Rust project. It is called Watchdog, and the ever-live database is called Keyhouse.

Motivation and Design

So what made us develop Watchdog? We wanted a tool that is -

Extremely easy to use Watchdog aims to be a tool that saves us from the hassle of adding and removing ssh keys from the authorized_keys file, and replaces it with simpler steps.
Has a simple and auditable codebase With just 700 lines of code, this tool is very easy to understand. Anyone can just casually look into the source repository to understand how it works. We also welcome your contributions :)
Non reliant on servers Access control should not be reliant on a machine that is prone to shutdowns or servers prone to high downtime.

What is Keyhouse?

What do we do if we cannot ensure a database that is almost always live? Well, host your database as a GitHub repository ;) That’s what we did, and it has worked very well.

The first thing to look at should be the structure of Keyhouse.

tl;dr the file keys contains the SSH Keys of all members, and the hosts folder contains a file for each server which contains access configuration.

Let’s have a look at Keyhouse.

To register yourself as a part of an organization (and get a username), add your SSH key to file data/keys in the format name|ssh-key. Make sure the name you choose doesn’t collide with someone else’s.

To gain access to user study in the server called ratchet, we edit the file data/hosts/ratchet to add the line name|study at the bottom, open a pull request

and get it merged by an admin.

As simple as that! You got access to study@ratchet (no, not really, we won’t give you access to our ratchet).

What is Watchdog?

As we mentioned it earlier, Watchdog is a rust binary installed on the server which communicates with the Keyhouse repository to check for privileges, and notifies of any login attempts, successful or otherwise, through Slack messages. As an added feature, we also notify you about any administrative activities like sudo.

It works by plugging callbacks to the commands sudo, su, and ssh using Pluggable Authentication Module (PAM) (to send messages to Slack) and SSH Authorization Keys Command (to authenticate with Keyhouse).

The Road Ahead

We are working on developing a simple web application for the Keyhouse repository, where a user can request access from admins by automatically making a PR to the repository by submitting a form on the webpage. We are also working on the issue that the sudo notifications don’t show which user invoked them. This issue is a priority for us at the moment.

Check out the project homepage at https://watchdog.sdslabs.co to set up Watchdog for your machine. You can also check out the source code for Watchdog at https://github.com/sdslabs/watchdog. We would love your valuable contributions and feedback to the project there. Up for a chat? Head to https://chat.sdslabs.co. Ciao!

Final recruitment list for 1st year (2020)

Sun, 19 Jan 2020 00:00:00 +0000

We interviewed 80 people before releasing the final list of selected people. It was a really tough job to filter down from the talented applicants to the final list. Sadly, we have limited vacancies and can only take in a limited number. But this is not the end of line for others, there’s still a way to join SDSLabs. We’ll continue taking open lectures on variety of topics. Stay connected with us on our Facebook page for the updates regarding this.

Developers

Angad Kambli (CSE)
Aryaman Behera (CH)
Aviral Jain (ECE)
Gaurav Genani (CH)
Gautam Bafna (ECE)
Ishaan Rawat (ME)
Mahak (CSE)
Meet Shah (CSE)
Nishanth R (PSE)
Smith Pereira (ECE)
Shreyaa Sharma (CE)
Sanjana Narayan (ECE)
Varun Gupta (CSE)

Designers

Amitesh Uppal (BT)
Lakshya Bajaj (PSE)
Saurabh Sangam (GT)
Stuti Lilani (ME)
Swastika (CH)

Team SDSLabs

UST Global Hackathon (d3code) 2019

Fri, 10 Jan 2020 00:00:00 +0000

Recently, UST Global announced the first edition of their d3code hackathon. It took place in 5 stages. The early three stages were online rounds, where basic programming questions were asked. The fourth stage was an interview, after which the top 20 teams got a chance to visit Kerala for the final round in UST Global’s headquarters.

We reached Thiruvananthapuram a day before the hackathon, and headed to their office the next day. The campus is phenomenal. Check out the following video for a glimpse of the headquarters - https://www.youtube.com/watch?v=Mk1NY9m6Hlw.

Upon entering the office, we were provided with breakfast. Following that, we were introduced to the d3code team and given our problem statements. There were three problem statements of which we were required to choose one. This hackathon was different from the others we usually participate in. Not only were the problem statements given to us, but each part of the problem was defined in detail. The judging process was very well defined so as not to be biased for anyone. There were pointers given to us based on which our projects were to be scored.

The hackathon was 24 hours long. It started at 9:30 in the morning. The first couple of hours were spent in deciding upon the problem statement. There were mentors available for helping us out in understanding the problems, and guiding us along the way in completing our project.

The three problem statements were from different domains. The first one was related to data, the second was a social media application, and the third was a live delivery app. We chose the first one, considering the skills it required were in resonance with ours.

We were essentially required to create a tool that parses data in CSV format and dump it into a relational database. There were other sub-parts of the problem, where we had to assign data types automatically, validate data for errors, and extract personal information from it. We also implemented a system where multiple CSV files could be uploaded together in topological order.

For the final presentation, we were given just 6 minutes. With limited time, we only focused on demoing our application rather than showing the PPT. We managed to finish the demo with 6 seconds to spare . A few hours later, the results were announced, and to our surprise, we won first prize.

Overall it was a great hackathon (mostly because of the prizes we won 😛). And the moment results were announced is something I’ll never forget.

Gasper - Your cloud in a binary (Part 1)

Fri, 10 Jan 2020 00:00:00 +0000

This blog is Part 1 of a series. It gives an idea of Gasper’s architecture, technical stack, and capabilities. The subsequent parts cover the detailed discussion of its various components.

Introduction

Providing simplicity without letting go of the necessities in deployments has always been a bottleneck for PaaS providers. Imagine you have a couple of Bare-Metal servers or Virtual Machines at your disposal (collectively called here as nodes) and you wanted to setup an application hosting service, such that the load is evenly distributed among all nodes.

Let’s face it; we have essentially two choices.

Manually Setup Everything:
Manually decide which application goes to which node, then use ssh/telnet to manually setup all of your applications one by one.

Kubernetes at the rescue:
Kubernetes takes away the load distribution problem with its intelligent clustering. But then again, it requires a lot (and yes a lot!) of configurations for each application. Besides, the pipeline for setting up the app still needs to be implemented.

Gasper - A New Hope

Gasper addresses all of the above problems and makes deploying applications just a breeze. The platform is modeled as a REST API, where the user just needs to provide the Github repository’s URL, build commands and some optional configurations, click the Create button and voila, your application is deployed!

Sounds cool? Let’s look at the amazing tale under the hood

Overview of the Architecture

Gasper is written entirely in Go - the language of the Cloud. It essentially has a microservices-based architecture. If you don’t know already, we have multiple software design paradigms. One is the monolithic architecture, the whole application as a single unit with multiple modules. These applications lose flexibility easily and are difficult to scale. Next, we have the microservices architecture. Each module is a separate unit and interacts only with APIs. Technically, we say that we have decoupled the modules. This can be scaled easily, and each module can be designed separately.

This choice of architecture was made right during the initial phase due to multiple factors. One of them being: this makes adding more modules dead simple. Suppose we need a service for internal DNS resolution. We create a separate module for that and just plug it in! Apart from this, as it scales and spans multiple servers, the services automatically handle the load distribution making everything a walk in the park.

The microservices in action

The journey from downloading the source code to its final deployment in Gasper involves the following microservices:

Kaze 🌪 (the master service responsible for managing all other services)
Mizu 💧(the worker service for creating/managing apps)
Kaen 🔥(the worker service for creating/managing databases)
Enrai ⚡️(the reverse proxy server)
Hikari 💡(the service for internal DNS resolution)
Iwa 🗿(the service that handles ssh into the containers)

Now that we are done with the architecture, let’s start from the very core itself: How to package? Multiple apps in a single node or one app per node. The former just sends security on a walk, and the latter one brings about a lot of hardware overheads.

H’re cometh Docker…

Docker is a service that deploys containers. Containers are a sort of OS-level virtualization. Docker comes with a plethora of configuration options, from limiting the allocation of CPU and Memory resources to managing security levels, and much, much more. It was a perfect solution to our problem; containers have a low resource overhead and implement isolation for configuration files and dependencies.

With docker containerization at its core, apps now can be packaged and built.

Alright let’s deploy, shall we?

The generic pipeline that Gasper follows for app deployment is as follows:

Download the application source code
Mount this source code as a volume for the container
Bind the ports of the host and the container
Start the docker container with this configuration
Install the dependencies
Fire up the application

And hola, your application is live!

Generally these build instructions are mentioned in a Dockerfile, which is quite robust per se. But we wanted to get rid of that nasty Dockerfile and the docker-compose heavy lifting, right? Let’s automate this pipeline.

Golang’s Docker Engine library was enough to handle steps 2 through 6. Gasper has two separate microservices, Mizu and Kaen, to manage the stepwise deployment of apps and databases respectively using these library functions. More details on them are in the next blog.

However, the whole process initially took a whopping 15s, even for simple boilerplate apps. We needed to optimize that.

Go, go, go… making thy w’rk easy

Go, besides the fact that it came from Google, is famous for its efficient realization of concurrency using Goroutines. And there it was, we took the two slowest processes, steps 1 and 4, and put them in goroutines. The deployment times came down from ~15s to ~5.5s. Further optimizations pulled it down to 1.5s. Phew! That was fast.

The final take:

The next we have Enrai, the reverse proxy server. Among all the services, only Enrai is given a public IP and the rest of the apps are proxied through it. Laying it down simply, it is a server that receives requests from clients and forwards them to the respective instances (containers in our case).
Gasper boasts an internal DNS resolution service, too, Hikari. It allots domain names to the apps and databases and maintains the DNS records, ensuring an even distribution.\

A lot things coming up altogether? This diagram might ease out things:

For those who prefer a hands-on deployment experience, Gasper provides SSH into the containers along with a virtual terminal for ease. Iwa plays its role here.

This marks the end of the deployment journey. The user is always able to restart/rebuild the app in case of failure, and there’s always SSH if they want to get their hands dirty 💪.

Part 2 of the series deals with the internal working of the services. In Part 3, we will discuss how we acquired logs and metrics, and how it actually builds your cloud with intelligent load distribution.

You can find the project here: github.com/sdslabs/gasper. If you happen to like it, a star on the repository is always welcome 😛.

SDSLabs Recruitment Drive 2020

Sat, 14 Dec 2019 00:00:00 +0000

We recruit students every year during the winters and select the best minds from the IITR Junta to join our venture for leading the technological innovation in the IIT Roorkee campus.

We are open to all years of students of IITR to apply in our recruitment drive. However, the majority of our recruits are in their 1st year of study.

Recruitment Process

We provide you with five different methods of landing an interview at SDSLabs during the Recruitment Drive. These methods are:

Being amongst the teams at the SDSLabs’ Syntax Error Hackathon 2019
Completing SDSLabs’ Winter of Code 2019
Completing SDSlabs’ Makers 2020
Placing top at any of our competitions mentioned below
Placing amongst the top students in SDS’ Recruitment Test and Design problem statement submissions

Syntax Error

We call students for an interview who placed in the top 2 first-year-only teams and the top second-year-only team at Syntax Error.

Since the hackathon winners have already been announced, the respective teams will be called during the interview process.

Winter of Code 2019

Students who were selected for SDSLabs’ Winter of Code 2019 and were able to pass all their evaluations successfully will be invited for an interview at SDSLabs during the interview process.

Makers 2020

Students who developed on a project idea released during Makers 2020 or developed on their own project idea of a similar caliber will be invited for an interview at SDSLabs during the interview process.

Competitions

SDS organizes a variety of competitions for the 1st year junta at IIT Roorkee during the winters. We like to call the Top 2 students from each of these competitions for an interview:

NoobCTF
- Capture the flag competition
- Hosted at Backdoor with InfoSec IITR
Beginner’s Hypothesis
- Data Science competition
- Hosted at Cerebro with DSG IITR
Algophobic
- Competitive programming competition
- Hosted at Codevillage with PAG IITR
Endgame
- Mathematical problem-solving competition
- Hosted at Erdős

Recruitment Test and Design Problem statements

SDS’ recruitment test has various sections, including logical reasoning, programming, web development (HTML/CSS/JS), and an ad-hoc section to show off your geeky side.

Design based problem statements will be released a week before the recruitment test takes place to test your skills in various fields of design like UI/UX and graphic design. Design submissions will be considered for recruiting into SDSLabs as a designer.

We hope we have made the entire recruitment process clear for all the enthusiasts out there. We look forward to seeing you test your skills at our Recruitment Drive this winter.

Best of luck!

Announcing Rubeus Engine 2.0

Sun, 13 Oct 2019 00:00:00 +0000

We are excited to announce that the Rubeus Engine that debuted on the 22nd December 2018 has had major improvements since the last edition and we have reached our goal for Rubeus Engine v2.0! Check out Rubeus Engine v2.0 on Github.

What’s new?

All the changes are listed in decreasing order of coolness.

New Project Manager

With Rubeus v2.0, we are introducing a brand new GUI project manager. You can now manage multiple projects using the Rubeus Engine at the same time, and choose which project should be worked on. A much-needed feature is finally here.

Messaging System for User Code

We have an exciting new message system ready and integrated into the engine with some default commands already implemented. Users can now expose their own functions as callbacks to user-defined commands, and the engine can call them asynchronously on the user’s demand allowing for much greater gameplay interactions amongst game objects. It provides a great scope for powerful message transfers between the different subsystems of the engine for more complex workflows.

Application Layer for Controlled Execution

We have introduced a new Application layer to the Rubeus game making procedure. Now all user-defined systems get to live in their own namespaces and have user-defined lifetimes. This allows the user to handle their own resources as and when required and encapsulate the code that talks to the Rubeus Engine from the code that works for their custom systems.

Z-Index for 2D colliders

Colliders can now be separated in different planes to allow for objects in the background to not collide with objects in the foreground. Assigning Z-index values is as simple as providing as a single integer value to every collider as an identifier of its Z-indexed layer.

Logging System for Debugging

Our new logging system allows the user to either log to the screen with varying degrees of severity levels, namely ERROR, ASSERT, and SUCCESS. Users can add more severity levels to their liking. What is a bit more exciting is that we now support colored error logging to the console that works on all supported platforms.

Users also can now log to files in a separate logging directory on their file systems. These logs can be used to allow for effective bug fixing after the game has been distributed to the players, where they can see the logs actively on their screens with a little digging. This helps post-distribution tech-support and in house development.

Game Object API Cleanup

The game object creation API has been made simpler by allowing for more flexible ways to provide the game objects with their data. We also cleaned up a lot of code at the user side of things to allow for a much less overwhelming interface to the engine.

Lesser Dependencies = Lesser Build Times

We have dropped our dependency on Vcpkg, the C++ package manager that we were using in v1.0. All dependencies are now distributed with the engine, except for some system libraries that have been mentioned in our setup procedure. You might see that our engine build times got reduced almost tenfold and we are glad about it.

Along with all these new additions, we have done a lot of bug fixes under the hood that help optimize the performance of Rubeus games and allow less open ground for bugs to creep in.

All the information regarding how to use these systems have been covered in our Wiki page available here under relevant Wiki entries.

Finally, we thank our team for bringing all the new changes and allow for a fast release cycle after v1.0.

How I learned to stop worrying and start pinging

Mon, 23 Sep 2019 00:00:00 +0000

We have regular hackathons to experiment with new fields/technology. We decided to write blogs on any shippable product that we created during the hackathon. This blog is first in the series, where we created an app that creates status pages.

Introduction

What is a Status Page?

Almost all organizations have a page where you can view the status (or uptime) of their services. For example, this is the SDSLabs Status page: https://statusv2.sdslabs.co/. A webpage that displays the uptime/downtime statistics of its services is called a status page.

Why do you need it?

A status page tells you whether an application is up or not. Suppose your Facebook notifications just stopped working. You might start to fiddle with the settings on your phone, but it may be that the Facebook servers that send notifications are down. A status page tells you exactly that. It is also pretty useful for companies too, making them aware of the downtime before a user has a chance to complain.

What did we make?

We made a web application that creates these status pages. Many others provide the same service, such as Freshping, Apex Ping, and Atlassian Statuspage. However, these services are either paid or provide limited free access. Moreover, there are no open-source alternatives to them. So, we made one on our own (and yes it’s going to be open-source).

Developing

Architecture

A status page consists of many services where it needs to check whether the service is working or not. However, what do we mean by the phrase “the service is working”? Usually, you ping the host, and if you receive a reply, the host server is up else it’s down. However, ping only tells you if your request can reach the server. The code may or may not function properly. For that, more parameters need to be checked, say, the status code of the response. A “200” status means your page is working fine, but any other status means you need to fix some issues.

Seeing that there might be so many parameters, we defined an abstraction called a Check. A check consists of the URL of the request, type of request, expected output, and any input sent by the user. For each kind of request, there are a limited number of request types and output types and correspondingly their values.

A page might contain some (and not all checks created by the user). A user might create multiple pages (each having a different set of checks). A page also needs to display any incidents that happened and if they were fixed or not. The app also has a feature to add collaborators to your page.

The diagram below illustrates the schema of the Database.

The biggest challenge in making the app was implementing how the checks would work. Since a user can request to check for uptime every 30 seconds, assuming a large scale, it’s unreasonable to expect one server to handle everything correctly. So we wanted the app to be scalable over multiple servers.

For this, we first thought of deploying a container for every check. We schedule this container in any of the nodes defined by us. Soon, we rejected the idea, given that there can be way too many checks and you cannot have a container dedicated to a check.

The next solution had a master that assigns checks to workers. The worker schedules the checks. Now, these workers can be scaled horizontally. This architecture was a much better optimization as compared to the previous solution.

There were some solutions that we thought about optimizing the process of scheduling the checks too, but each of them imposed some limitations on the functionality of the app (like limiting the choices of the interval of sending requests or increasing the minimum interval time after which we can send a request). Sacrificing functionality for the sake of minor optimizations was unacceptable.

Finally, we needed to manage the lifecycle of the workers. It’s relatively complex when managing containers across multiple nodes (servers). We chose to rely on Kubernetes than reinventing the wheel ourselves. Kubernetes allows you to create custom resource objects. We need to write the code that handles assigning of checks in various workers for multiple events, such as, when adding or removing a worker from the cluster and let Kubernetes handle the rest.

Due to a limited number of resources, first, we’re going to release a version without the described Kubernetes architecture. For the initial release, we’re aiming at an app which can spawn and manage workers on a single server.

Tech Stack

We chose Golang since it’s a compiled language and all my team members were comfortable with writing code in Go. Go being a compiled language was helpful because we could create binaries of agents that would run on worker containers. It’s also much easier to write as compared to C/C++.

Along with it, we used Docker Containers, and as mentioned above, Kubernetes for managing their lifecycle.

For storing metrics of the statuses, we needed a time-series database. Struggling between Prometheus and InfluxDB, we found out about TimescaleDB. It’s an extension of PostgreSQL, so anything that works with Postgres works well with Timescale too. There were even more benefits to this since we did not want to write queries specifically for InfluxDB, and Prometheus being a pull-based DB did not fit our needs. With Postgres, we could use a single database for both metrics and meta-data.

Many people don’t require all this functionality and just the metrics for a few checks. So there’s even a stand-alone mode where you can write a simple YAML file defining properties of checks, and it’ll do the job. Also, integrating with Prometheus was an easy job, so for the stand-alone user can plug in Prometheus too.

Hackathon

Organizing an internal hackathon turned out to be productive. Usually, the part of the process that takes much time gets completed in a matter of hours. It’s also encouraging to see everyone else around you working with such enthusiasm. It’s exciting to see all the products that others make in the end.

We had a formal presentation of the work everyone completed in two days. The winner was also awarded a prize from the final year. The best part was this being an internal hackathon, and we could decide the parameters for rating. So, we did include code quality as well as the number of hours spent on working on the project.

We finished most of the app during the weekend. There’s still some work left to ship the complete product (at least a version that works flawlessly with minimal functionality). You’ll hopefully see it on Github soon :)

Linux Party experience - Playing with your bootloader for fun and happiness

Fri, 20 Sep 2019 00:00:00 +0000

For a brief context, SDSLabs conducts an event called “Linux Party” in which our members help the freshers of IIT Roorkee install a Linux distro (mainly Ubuntu) on their systems.

The Motivation behind this blog

Linux is a whole new world for someone new to it; beginners(and even veterans!) find many intricacies/difficulties which start appearing right from the installation process. After installing linux on a lot of systems and experimenting a lot with ours we thought that it would be a great idea to post all our learnings that may assist someone trying to do it themselves person.

This writing will be mostly a collection of guides distributed across the internet and our experiences that we felt needed to be interwoven to make the installation experience smoother. Note that this is not an exhaustive guide and you would need to do some Googling along the way. Also, our guide will be specific to Ubuntu but should work for any Debian based distro.

How to use this guide?

First, give this a light reading. You wouldn’t want to be distracted by theory during the installation process. After skimming through, you should be able to figure out the parts that are relevant to you and follow them while installing.

Dual Boot vs VM

Why go through all the hassle of dual boot when you can simply run a VM?

VMs are resource-intensive, you need to have a beefy computer to have a smooth experience inside a VM
On using a laptop this will adversely battery life and hence limit a laptop’s portability

Here is a much more exhaustive list

Besides, this is also a great opportunity to learn about wacky terms like BIOS, UEFI, EFI tables, Bootloader, etc. that you may or may have not heard.

Preparing a bootable media

Ubuntu provides a great guide on how preparing a bootable media here

Here we would like to stress on point 4, Boot selection and Partition scheme. We recommend selecting MBR for the partition scheme; though you can give the other options a try, but they require more care during the installation process.

Understanding EFI tables and custom partitions

EFI tables- In layman’s terms, it is a partition(like the C: or D: drive on your windows) which stores ‘bootloaders’ of various OSs present on your system. ‘Bootloaders’ are programs that are responsible for starting up an operating system. On a Windows laptop, you probably have the Windows Bootloader installed by default on an EFI partition. You can verify this by opening Disk Management from the Start menu. Remember this bit of information, it will be useful later.

You may be used to the Windows partition scheme in there are different drives like C:, D:, etc., but Linux uses a different partition scheme.

/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── lib64
├── lost+found
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin
├── snap
├── srv
├── sys
├── tmp
├── usr
├── var

Linux has a more hierarchical file structure, wherein there are different directories inside a ‘/’(pronounced ‘root’) directory. What you see above is the list of directories that were in my root directory. Instead of having different drives for segregating data, Linux gives a master directory that contains everything. Each directory in the root directory has a specific purpose, and each directory can be mounted on a separate partition akin to Windows partitions. If you don’t allocate separate space for separate directories, they would share root’s allocated space by default.

This is a great video explaining the Linux filesystem in detail. Don’t worry if a lot of things go over your head. For starters, we are only concerned with /, /home and swap.

/home is where a user’s files are stored(similar to the C:\Users in windows) but you would have to allocate more space than what you might be using in C:\Users because ALL of the user files will be in /home and there would be no other D: or E: drive to store these files

swap is a ‘virtual RAM’ that is utilised to extend RAM beyond its physical capacity. With swap memory, an 8 GB RAM can ‘store’ much more data than 8 GB, though it would be significantly slower.

From our experience, a general space ratio of 40:60 between / and /home, and setting swap size to double the size of your RAM is a good composition. If possible, give root more than 20 GB of space apart from the space for /home for smooth operation.

The actual partitioning

There are three cases:

SSD only or HDD only
SSD + HDD
Optane + HDD

Now for HDD only laptops, the work is pretty straightforward. Shrink the required memory which you have calculated previously.

For SSD only laptops the process is the same as HDD only laptops except that you have to shift your SSD from RAID to AHCI using this. Step 5 of the previous link will vary with manufacturer, so explore your BIOS a bit (don’t go on changing any random setting!) and you’ll find the appropriate setting to switch or you can google for “ RAID to AHCI".

For SSD + HDD laptops, you would want to minimize stuff on the SSD as it is generally small. In this case, allocate space for / on the SSD(minimal boot time) and /home on the HDD.

For shrinking your Windows drives follow this guide for both SSD and HDD

Optane is rare so first check this to determine if you have Optane in use in case you are unsure. Installing Ubuntu on Optane is a bit complex so we won’t be going there; use this(disabling Intel Optane memory with Intel RST is enough, no need disable from BIOS!) and install Ubuntu, but remember to keep an EXTRA 10 MB unallocated space at the END of your HDD which is required by Optane, other than the memory used by Ubuntu. Then use the previous guide to re-enable Optane.

Use this to install Ubuntu and configure the partitions according to your needs. “/dev/sd*” type of names refer to HDD and “/dev/nvmp*” refer to SSD.

In Device for boot loader installation shown in the previous link select your SSD in case you have one or your HDD if you don’t.

GRUB

Remember the talk about bootloaders? Now GRUB is your new bootloader. Upon booting up your PC, you should now be greeted with a black or magenta screen with white text in a not-so-appealing font. Here is where you can select your OS using arrow keys.

In case GRUB is now showing up and you are directly booting into an OS(which should not happen if you followed the instructions), the issue can be subjective and your best bet would be to do google searches describing what is happening and you should find a solution(trust us, we’ve been there too). You can also reach out to us here and we would love to help!

Graphics Driver Errors

This is the main issue with most of the laptops that get ubuntu newly installed. A variety of errors are reported in this category.

Black screen on login
ACPI errors after GRUB
Corrupted display and many more…

This is mainly due to Nvidia graphics cards being present on a system and the need to manually install their drivers. If you face this issue (or miraculously don’t while owning an Nvidia graphics card), follow this(follow step 1, then step 3, and then undo step 1) Another error that you may encounter is that of Windows entry not showing up in GRUB. A variety of solutions are available here

To avoid this problem, you may install some OS that provides you graphics drivers pre-installed. We recommend Pop!_OS if you are interested in such an OS. It is based on Ubuntu, so all terminal interactions remain the same.

Issues after installing Ubuntu

Touchpad dysfunctional

Mostly a drivers issue, Run this on your terminal- sudo apt-get install xserver-xorg-input-synaptics

Internal Speakers dysfunctional

Run alsamixer in your terminal and using left/right and up/down keys raise all bars to max. Internal speakers generally do not perform to their maximum ability on Ubuntu but external speakers/headphones work fine.

Further Exploration?

So you have everything set up and want to know more about the world of this amazing piece of open-source software?

Then check these out-

Desktop Environments

Hot Distros

Everything is a file!

Terminal Commands Don’t go on memorising these, just know that they exist and you’ll learn them over time

Nano Text Editor

Vim text Editor

Practice and learn command-line skills

Rolling Out Your Own Game Engine and Beyond

Thu, 20 Jun 2019 00:00:00 +0000

The Rubeus Game Engine was released by SDSLabs on 22nd December 2018 with the vision to introduce the programmers of IIT Roorkee to game development and design. We received a ton of support with this release even from game development communities outside of R-land.

We saw multiple release threads pop up on HN and r/Gamedev which attracted people from the industry to review the codebase and constructively critic on the project. We are very happy with the general reception and in this blog, we want to discuss where we are trying to take Rubeus in the future.

It has been around 6 months since we released Rubeus, an in-house implementation of a beginner friendly game engine in C++. We have talked about our process in another blog entry. Check it out if you are interested in something like that.

The Motivation behind making Rubeus

We made Rubeus with an objective to help a beginner learn how games are made. Every 90s child who has been exposed to games at an early age has a dream to make video games someday or they at least have wanted to make a game at some point of time in the future.

We believe that one cannot understand something properly until they are able to explain it to a three-year-old. Brightly said by Einstein, it motivated us to have a try at making a game engine for satisfying the curiosity of not only us but also the beginner game developers out in the programming world.

What one should do with a game engine?

Obviously: Make games.

We made some small clones of some very basic games on Rubeus like Ping-Pong and Breaker. The Rubeus workflow we had developed was perfect for such prototypes. But we didn’t want to stop there.

We started to implement some advanced features in Rubeus like a multithreaded console, message-based communication between its sub-systems, a GUI for debugging and project management, an application layer that allows more control over the startup of the application, fixed countless bugs in Awerere which is the physics engine that we implemented by hand for Rubeus and other systems in the engine. However, very soon we realised that what we were trying to achieve with Rubeus was unrealistic indeed and we needed major changes in the current architecture.

The Future of Rubeus

We are still going to maintain Rubeus and it will still remain our solution to introducing beginners to game development. We plan to keep introducing new features to the engine and make them as accessible as possible to people who are still at the learning stage.

For the version 2.0 release, we have a Github Project tracking all progress here. We have listed all the upcoming features and bug fixes as issues.

Join the Rubeus Engine Discord server if you’d like to discuss Rubeus’ development/usage with us.

The Shortcomings of Rubeus

As much as we are proud of Rubeus, we accept that it has some architectural and enhancement issues due to partial oversimplification of concepts for making them accessible to our beginner audience.

What we are proud of in Rubeus

Cross-platform nature of Rubeus
High performance of in-built physics and rendering engines
Non-intrusive design
Use of custom tools like ImGUIs for debugging and broCLI for project management
Complete documentation and public user guides

What we are not proud of in Rubeus

High amounts of mechanical exposure to the user to facilitate learning
Closely bounded architecture with a lot of coupling with similar systems
2D only physics and rendering engine
Inflexibility in terms of customizability (for example, custom shaders are not allowed)

Introducing a newer, more advanced interactive simulation engine

We are very excited to kickstart a new publicly developing project, code-named as the ‘Rootex’ project.

We aim Rootex to be an interactive 3D simulation engine which will power an upcoming project yet to be announced. We are not calling it a game engine anymore, instead, we are targeting it to cater to a specific kind of simulation development with user interaction built into the application. It is currently in active development and a release date will be announced soon.

Why is making a custom engine still a viable choice?

Customized engines are better suited for cases when either your idea is too wild for any generic game engine to handle, or you want to just learn engine development by the hardest way possible. We lie in the middle of that spectrum.

We are actively looking for collaborating with other groups operating in IIT Roorkee that might want to join in this project with designing the game mechanics and game design aspects of this project.

Why not use Rubeus instead?

As mentioned above, we want the newer framework to be more robust, more flexible in terms of customizability and functionality and just cater to the specific project instead of a wide range of genres. We believe it makes the engine more focused to solving a problem and gives us more performance to work with. Our argument can be compared to when you require a Swiss knife instead of a butter knife made for children.

Final recruitment list For 1st year (2019)

Sun, 20 Jan 2019 00:00:00 +0000

We interviewed 90 people before releasing the final list of selected people. It was a really tough job to filter down from the talented applicants to the final list. Sadly, we have limited vacancies and can only take in a limited number. But this is not the end of line for others, there’s still a way to join SDSLabs. We’ll continue taking open lectures on variety of topics. Stay connected with us on our Facebook page for the updates regarding this.

Programmers

Adrij Shikhar (CH)
Aniket Kumar (CH)
Ashutosh Bhushan Bharambe (ECE)
Ayan Chaudhary (EE)
Ishita Kaul (ECE)
Karanpreet Singh (CSE)
Leshna Balara (CSE)
Manas Chaudhary (ME)
Nupur Agrawal (MSM)
Shubham Gupta (CE)
Subham Sahoo (EPH)
Shubhang Tripathi (CSE)

Designers

Parth Bahuguna (MSP)
Prakhar Kothari (AR)
Shivam Maan (MSM)
Yash Choudhary (MT)

Team SDSLabs

Winter of Code 2018 Results

Thu, 03 Jan 2019 00:00:00 +0000

Winter of Code (WOC) was a month long program organized in IIT Roorkee for the third time by SDSLabs to improve the open source exposure in campus and help first yearites get a taste of open source community with a GSoC like timeline.

We got a great response from IITR Junta. Cheers to all!

From a staggering 100 submissions, 14 were chosen to continue their projects under the mentorship of SDSLabs members (GSoCers themselves). It was a great experience for us to mentor such an enthusiastic crowd. Their dedication, hard work and passion makes us believe that they have a bright future in this field.

After a hectic 30 days of coding and 5 days of rigorous evaluation, we hereby present the list of students who have successfully passed the final evaluation:

Developers

Abhik Chakraborty (CSE)
Adrij Shikhar (Polymer)
Aniket Kumar (Chemical)
Bismita Guha (Metallurgy)
Harshit Verma (CSE)
Rochisha Agarwal (EPH)
Shourya Shukla (CSE)
Utkarsh (CSE)

Designers

Lakshya Singh (MSM)
Niharika Agrawal (CSE)
Yash Choudhary (Metallurgy)

Abhik Chakraborty, Adrij Shikhar, Aniket Kumar, Harshit Verma, Lakshya Singh, Utkarsh and Yash Choudhary will get a direct invite to the interview round of SDSLabs recruitment although we encourage them to also give the recruitment test to gain a little extra edge.

For those who didn’t get the direct invite, do not worry. Your performance in WOC will be considered during the selection procedure. All you have to do is give your best in the recruitment test :)

We wish all of you the very best for your future endeavors. Happy Coding!

To Organise is to Design

Sun, 30 Dec 2018 00:00:00 +0000

What is Syntax Error

We at SDSLabs (Software Development Section Laboratories), a student-run technical group of IIT Roorkee, constantly try to promote innovation and foster technical activities in the campus.

Syntax Error is one step towards this. It’s a campus level hackathon where students come up in teams and work together to build some amazing applications from scratch. It’s 60-hours all about coding, coffee, designing, brainstorming, snacks and finally presenting the output.

The main aim of this event is to indulge the freshers and tech enthusiasts of the campus to work together and learn from each other.

Organising the event

As the organisers of this hackathon, our focus was to get more and more enthusiastic people to participate. In the course of the event, we had to ensure the following things were performed smoothly:

Promoting the event on the campus to generate more and more awareness among the people.
Conveying general information regarding the hackathon like prizes to be won, who can participate, how to form teams, etc.
Providing a platform to register in teams.
Conducting the hackathon and keeping the participants charged up by a dose of snacks, coffee and most importantly guiding them as they work.
Announcing the results and giving away prizes.

The Design Part

In the previous versions of Syntax Error, held in the past years, Facebook posts were used to promote and convey the information. For registration, an online form was used. Everything went according to the plans but there was something that we missed. Each step was existing good on its own, but what we lacked was a unified approach.

This time, we were planning to go bigger by including sponsored prizes as well. This was the right time where we could create a visual language to carry everything together. What we needed was promoting Syntax Error using a brand identity.

Branding

Branding is the art and science of defining and differentiating yourself to the public. A brand identity is not just about pretty design elements. The more important thing is conveying the values associated with it.

Branding is what sticks in your mind associated with a product, service, or organisation.

It was important to know what we were trying to convey through this brand identity. The values chosen would be helpful to stick the brand components along a direction.

Spark of creativity
Enthusiasm
Promoting teamwork
Learning by doing

The branding included the following components, together building up a system which was aligned with the values chosen.

Colors

Orange was chosen as the primary color as it best represents creativity and enthusiasm. It was toned more towards the yellow shade as it gives a sense of togetherness or teamwork.

Logo

Brand is like a human being and logo is like the uniform it wears!

The logo is the most important part of a brand identity. It is like a face to the system we are building.

We derived the basic concept of the logo from the previous version and molded it according to our brand identity.

Typography

To impose a creative feel rather than a formal one, Montserrat was used as the major font throughout the brand elements. It creates a majestic yet fun look and evokes a modernist style.

Illustrations

The illustration style consisted of simple shaped elements with an emphasis on the brand colors. Stroked outlines and spilled fill colors convey innovative thinking and experimental approach to doing.

Posters, Invitations, Certificates

Promotion posters on social media, certificates for winners and invitations for professors and judges were designed such that they all formed a relationship that they belonged to Syntax Error.

The Landing Page

We followed an approach of connecting the landing page to the promotion campaign. We ensured that everything on the page conveyed the same message and gave the same feel as defined by our brand values. In doing so, users feel comfortable that they have reached the right place.

The conversion goal of the landing page was to make people register for the hackathon while also conveying the must-know and nice-to-know information regarding the event.

Source: Dribble

Upon clicking the CTA, the user is directed to fill the form of registration.

A confirmation mail is sent after she finishes the registration.

The website was made responsive to work nicely on mobile devices as a majority of users would be using a mobile phone to visit the page.

How it went

The hackathon saw huge participation of students with over 100 teams registering. People worked on several technologies like machine learning, game development, information security etc. and built some amazing applications in the 60-hour sprint. We saw a great involvement of freshers who were enthusiastic and willing to learn.

Altogether, the hackathon was a great success. Receiving prizes was surely a great motivation for the winners and for others, they took an awesome learning experience with them.

How SDSLabs works - 2018

Fri, 28 Dec 2018 00:00:00 +0000

SDSLabs is roughly run as two cells (programming/design) that collaborate with each other on everything. This blog post will take a look at the various tools, technologies, and applications that we use on a daily basis. It is our hope that some other groups in the campus might be interested in this. We’re open to the inquiry about any of this, and you can reach us anytime at chat.sdslabs.co or contact@sdslabs.co.in.

Mailing List: Our mailing list, like most other groups’, runs on Google Groups. All notifications regarding discussion of projects or general meetings are sent over the mailing list. We didn’t want to disturb our alumni over our regular meetings, so we now have separate groups for current members and the alumni.

Facebook Group: Like everyone else, we too have a private Facebook group too. Unlike most other groups, we hardly ever use it. We find the Facebook notification system terrible, and the comments system broken for serious discussion. Hence we limit discussion on Facebook to bakar (random chit-chat) and taking jibes at each other. We also keep a document with our internal lingo here.

Slack: As a software development team, having around 50 members who work on various projects, a central communication platform is a must. This is our primary means of communication. Every member is aware of the discussion going on on every project and thus can give inputs which are equally valued. We are completely transparent regarding our working, and encourage everyone to communicate only in public channels. As a student group, it is not feasible for us to pay the hefty monthly fees for Slack premium, but the free version has almost all the features we need, be it the option to add a number of integrations, or infinite members.

Hubot: We built ourselves a bot around hubot, written on CoffeeScript and hosted on Heroku, to serve our daily needs: plus-plus (a positive reinforcement for doing something great, and a primary driver of work in Labs), keeping track of embarrassing aliases, information about any member, knowing which people are in lab at any moment, and much more. Recently, we added a score counter for the number of messages sent by every member in a week to encourage members to interact on a daily basis. The one with the highest gets a plus-plus. The bot is highly customizable, and only a script file needs to be added for a new feature.

Presence: It is a tool that is primarily aimed at increasing people’s presence in Labs. We maintain a competitive board wherein we keep the score as the number of hours spent by a person in the lab. It also helps our bot determine who all are present in the lab at any given moment (we also have a spycam, just in case). It works by identifying users based on the mac addresses of their devices which are requested using a arp scan. A script is used which logins on our TP-Link router’s portal and fetches the mac addresses and for other router’s since they can not provide mac addresses of connected devices natively, we had to patch the router firmware in order to do so. This mac address scans is a cron which runs every minute. And every five minutes, the leaderboard is updated. As for the spycam, we have another cron job set up which takes pictures of the lab every 15 mins, or whenever requested by the bot at any time.

Watchdog: Managing people’s access to servers was one hell of a job. Asking for their public key, copying it over to the server, and deleting it when access needed to be revoked. So, we built ourselves a little (yet powerful) tool to ease the process. Whenever someone tries to log in to a server, Watchdog checks a repository for whether that person has access to that particular user on that particular server, and denies or grants access based on that. Anyone seeking access to a server needs to open a pull request on that repository, and access is granted after it is approved and merged. A simple commit is all we need to grant or revoke access. We also added extra feature of keeping track of who is accessing what and at which level of privilege, and all that information is posted by a bot on a channel on our slack. So, it is out in open for everyone what everyone is up to. The whole idea of watchdog is based on how linux uses PAM modules for authentication purposes. We built our custom modules and added them to predefined sudo, su and sshd modules.

Dropbox: Our designers primarily share their work through Dropbox. All our designs, past and present are stored in Dropbox. We also use it to share documents. A new Facebook feature for Dropbox sharing within Facebook groups was actually a great boon for us as we use both products together.

Github: We host all our repositories on Github. We have unlimited private repositories, and though we encourage open source, we prefer to keep some of our applications private. We extensively use Github features, such as issue labeling, milestones, and projects, to keep track of work needed for a project to be shipped on time and with perfection. We go by one rule master should always be deployable.

Trello: We use trello boards for keeping track of the current status of a project. Since we started using this we have experienced a great acceleration towards the completion of our projects.

Workflowy: We use a custom account at Workflowy with a shared list to easily manage lots of things. We find that the list system of workflowy is an excellent place to chalk out ideas and hold brainstorming sessions in writing. Workflowy keeps track of most of our administration related stuff, with tenders, management contacts, and events of various subgroups, etc. being stored there. A daily log of our changes on workflowy is forwarded to our google-group so everyone is kept in the loop about any changes made there.

Making a game engine from scratch

Sat, 22 Dec 2018 00:00:00 +0000

Today we are proud to announce ‘Rubeus’! Rubeus is an open-source 2D game engine written purely in C++17 and is designed with a vision to inculcate the spirit of game development amongst the general public (specifically the IIT Roorkee junta). You can check out Rubeus at https://github.com/sdslabs/Rubeus.

What is a game engine? How is it different from a game?

A game engine, in its most mature form, is a platform that provides tools and utilities to game developers for designing and developing games based on their ideas.

To provide some comparisons, some of the most well-received games in the market have been Ubisoft games from the likes of the Assassin’s Creed franchise and the Watch_Dogs franchise. These games look and feel very similar to each other as both of these franchises have a stealth mechanic deeply rooted at their heart.

The stealth mode mechanic in Watch_Dogs 1 takes a whopping 100,000 lines of code in the game. It is not only economically impossible to regenerate and reintegrate that much amount of code for each and every game that gets released under the franchise, but would also take up a lot of the developers’ time. This is why Ubisoft has engraved the stealth mechanic in their game engine and they keep reusing it in their newer games with appropriate modifications.

Why make an entire game engine and not a game?

In reality, the development of most games at game studios starts with developing a game engine first. Creating a game without a game engine can be considered as hard-coding functionalities in a crude form. This means that if you happen to work on another project (perhaps a sequel of the previous game), you will have to again work on laying down the basic layer of functionalities that all types of games work on. It is likely that whenever you start working on a new project, a significant part of your code will be repeated every time. This practice of writing the same code every time you work on a new game is incredibly inefficient and this is a problem that we, at SDSLabs, intend to solve.

Making a game engine is a complex task and this is why most casual developers overlook the possibility of using a game engine to realize their game ideas. However, there are a lot of free alternatives out in the market. For example, you might have heard about Fortnite and the latest Tekken 7, both of which run on Epic Games Studio’s Unreal Engine 4. It has, in fact, made it possible for the Tekken franchise to finally hit the PC market. There are plenty of game engines out there but we decided to put ourselves up to the challenge of creating one for ourselves and releasing it to the public for everyone to use.

How to even start with making a game engine?

The starting days of Rubeus in the month of May 2018 were full of reading sessions. The best websites to look up information on topics that we found were related to game development are probably Gamedev.net and Gamasutra. We also recommend following r/gamedev on Reddit, which is a booming community of game developers from both indie and AAA studios.

The beginning of something amazing

One of the first hurdles that we faced was how we should implement the Rubeus engine’s architecture. We had zero levels of abstraction in our codebase and we were trying to create an API out of it that should be useful to even a newbie. This made us take a step back and we started to work on the individual modules of the engine rather than the API.

Any game engine works on a concept of what is known as the ‘Game Loop’. In the most general sense, games are recurrent programs. They do not normally shut down after their execution is complete. Instead, they often keep on repeating a particular set of instructions over and over unless the game shuts itself down or when the player has pressed the QUIT button. This is the concept of an ‘Application Loop’.

Now, let us see how game engines modify this concept so as to suit most closely to an actual game. A general game engine loop looks a bit like this:

The engine update function above consists mainly of the physics engine update and the calling all the tick functions.

A tick function is some user-defined logic that the user wants to run at every frame in the game. It may contain all of the game logic or just a frame counter to measure the FPS. Coming to the physics engine update, it is also just a function that gets called once every frame but it checks for collisions every frame, and if it finds any collisions happening then it defines what change of velocities of the colliding game objects take place in that frame.

The most important parts of making a game engine are implementing the physics update function and the render function (also known as the drawing step). These two functions are implemented independently inside the physics engine and the rendering engine. The render function just renders the scene. It applies no game logic to the scene. All logic is covered inside the update functions. Render functions tend to take care of what visual effects the user requires at a certain moment in the game.

A typical single-threaded game engine update loop should look like this:

Taking all these bits of information together, we started building Rubeus function by function. We first listed down the basic components of a game engine. To give a gist of how and what we started to work on, below is some documentation on our process of building a game engine.

Graphics Components:

A window module that talks to the OS and generates a window which allows OpenGL drawings to be rendered on the screen

This had to be done in an OS-independent way because to keep the engine cross-platform. One such library that eases this task is GLFW(“OpenGL Framework”). GLFW makes the task of drawing to the screen independent of the OS using OpenGL completely hassle-free.

A rendering module that abstracts all objects appearing in the game with the specific image/color that they use to get rendered to the screen

It is also the renderer’s job to use the specific shaders that allow the objects to get colored in a way that the shader governs. In a nutshell, shaders are bits of code (written in OpenGL Shading Language a.k.a. GLSL, in our case) that tell the GPU where each vertex is present in the 3D space and what sort of algorithms should be used to color every pixel along with what sort of effects should be applied to the rendered image.

For example, 3D games nowadays have started using a ‘Bloom’ effect to highlight bright objects on the screen.

Bloom effect is a lighting illusion that is used to make objects appear brighter than the maximum brightness of the monitor.

This particular effect i.e. Bloom effect is implemented inside shaders and the renderer uses these shaders to output graphics on the screen.

During the development of Rubeus’ renderer, that we proudly named the ‘Guerrilla Renderer’, we ran a benchmark at rendering 14,560 sprites (a.k.a. 2D objects) at 450 FPS on a GTX 1060 (6GB). We tried to crank the numbers higher and somehow managed to choke our own engine by displaying 122,300 sprites at 4 FPS. A quick reminder: No real-life game ever reaches these numbers of objects being displayed at a time. We had also tested Guerrilla only in Debug mode without any form of inlining of C++ code.

This is a test run from another benchmark that we ran.

Multithreading:

We were aware of the fact that even if we may not ever make Rubeus multithreaded in the first place, we may require the need to perform asynchronous responses such as implementing a console, or a debug menu for the user that use Rubeus to make a game for their players.

Multithreaded programs are exactly what they sound like. They are able to follow more than 1 flow of execution of code at a certain moment in time. Beware that such systems can be incredibly hard to build because improper sharing of resources and also just overuse of threading will also give a negative hit to the performance of the engine.

We have implemented a multithreaded messaging system inside Rubeus that we plan to release in v2.0. More information on this type of an architecture can be found in this wonderful article about making different types of game engine architectures.

By the time we were done with the multithreading architecture and the Guerrilla renderer, it was already mid-July and we had started to realize that this project might take a while to get completed. Not because of any lack of development times but the sheer size of this project. It was about time we started to really speed things up or Rubeus would be seeing the light of the day not before 2019 or maybe even not at all.

A Physics Engine:

Rubeus’ physics engine, nicknamed ‘Awerere’ (pronounced as “auror”) is also what it sounds like. Awerere is a physics engine that works inside Rubeus and allows simulation of life-like collisions and physics of game objects.

The physics engine is an essential part of bringing any form of realism in a game. It is responsible for figuring out what objects are colliding with each other, what objects are not colliding with each other and if they are colliding, what velocities do they move away with and if they have collided, should they repel like rigid bodies or do they release some form of energy (likes of what we see in inelastic collisions amongst rigid bodies).

All these questions are what the physics engine has to find the answers for. Sometimes the user can define some customized response to collisions. For example, the user would like to open a door to another doorway if the player shoots a particular switch on the wall.

Currently, Awerere supports shapes such as boxes, circles, and planes. It handles collisions amongst all of the permutations of these objects and assigns them their final physical state after the collision. Designing Awerere and implementing the different collision algorithms was a treat because we personally like studying and realizing rigid body physics with the help of real-world physical laws.

Inputs and Sounds Manager:

In this part of the development cycle, we were slowly approaching the release date and we had already implemented and debugged the hard parts of implementing a physics engine.

We have used the popular ‘Simple and Fast Multimedia Library’, often known as just ‘SFML’ to provide Rubeus with cross-platform access to the sound devices in an organized sound manager. Rubeus now supports loading both long audio tracks like ambient and background music in addition to short pieces of audio like footsteps, gunshots, etcetera.

When we had selected GLFW for generating windows on all OSs, we also had to keep a note of how GLFW handled getting inputs from the input devices. It also provides keyboard presses along with mouse button presses, scrolling, and just plain cursor positions. But all of this is done in an asynchronous response that GLFW provides the engine. We have implemented a system that keeps track of what keys have been pressed and what keys have been released at the starting of every frame. This made up the base of creating the Input manager which we further abstracted to work by creating keybindings for each control. Multiple keys are now assignable to a single keybinding/control.

Bringing everything together

Near the end of November we were ready with all subsystems and modules that were required to make up Rubeus. But we still did not have an API or a gateway that the user could interact with.

This is when we came up with broCLI, which stands for ‘Rubeus on Command Line Interface’. broCLI is a CLI tool implemented in Golang which helps create a project structure for Rubeus. It was the perfect idea for Rubeus to use a CLI tool instead of a GUI so that users get a feeling of doing some heavy work while working with Rubeus. The user persona for Rubeus was always a beginner programmer from the start of May 2018. A CLI is probably something that they will be seeing a lot in their coming days.

Rubeus may have a GUI later but for v1.0, we are focusing only on a CLI.

Fast forward to this day

We are happy that we were able to implement such a complex piece of technology with elegance and now, we invite others to partake in this endeavor into the realms of game development.

If you are interested in game engineering then you are more than welcome to help us take Rubeus further and contribute to the project. Otherwise, please have a stop by at the Github repository https://github.com/sdslabs/Rubeus and try to make something amazing with it. We will be honored to see you create something beautiful with Rubeus and we look forward to your support.

P.S. We maintain a public list of awesome projects that we find to be built on Rubeus. You can be featured on it too!

package SDSLabs > import Vaibhav

Tue, 18 Dec 2018 00:00:00 +0000

`var vaibhav = new Student()`

Like most of you, I was a beginner when I came here. I had managed to teach myself HTML and CSS, but I had no idea about any other language or how to make software.

I started off with C++ (as it was part of our course). During our practical classes, I used to solve problems on Codechef. Fortunately, the TA did not mind. In my winter vacations, I read up on HTML and CSS. The best thing about the web is that it does not constrict you to a particular flow of knowledge, and while learning about something, you get to learn a lot about other things too. While exploring, I found out about Github and Github Pages. I immediately made an account, followed the steps and put up my webpage. It was still a work in progress when the vacations ended.

`SDS.test(vaibhav)`

My proposal for Winter of Code was not accepted. I gave the recruitment test like everyone else. A couple of days later, I received a call for the interview. The interview was in half an hour when I received the call. I rushed to take a bath, got on my cycle and left from Rajendra Bhawan. I was in such a hurry that I even forgot where the Hobbies Club was. Nonetheless, I made it on time.

The interview took place in two stages. First, a few problems were given to me. They were similar to the ones in the test. The next stage focused on my way of thinking a solution. I was asked to design a system for a Library. I couldn’t do it all by myself, but what mattered was the way I tried to solve the problem. Everyone liked the webpage that I had made. It was a huge point in my favour for getting selected.

`SDS.addMember(vaibhav)`

One day after the interview, I received the news that I had been selected as a member of SDSLabs. The next day, everyone gathered in the Hobbies Club (that’s where the old lab was). We were introduced to this whole new world that day. My mailbox was full of invites from Slack, Dropbox and other SDSLabs accounts.

It’s a tradition here to order pizza from Dominos and go to Georgia and eat there. The Intro-Chapo took place after a couple of weeks. It was quite an evening. We got to know and interact with everyone. Of course, there were snacks, dinner and a lot of dance.

I don’t know about other sections, but here at SDSLabs, we get Chapos almost regularly. Be it someone winning a hackathon or someone getting an internship, you get a Chapo one way or the other. And if significant time had elapsed without one, we usually found some senior ready to give one in Govind canteen.

Lectures were held for us at the beginning regarding various topics starting from HTML/CSS and PHP to more advanced topics like Networking, MVC architecture, etc. We were introduced to various languages including Python, JavaScript, and technologies like Git and Node. It is still hard for me to believe that I made a fully dynamic website in just ten days when a few days before starting, I knew nothing.

Be it completing a tutorial or watching a movie, everyone encourages us to come to the lab. It was hard for me to believe how much difference it could make until I experienced it myself. There is someone in the lab almost all the time, someone you could talk to, learn stuff from or discuss any sort of ideas with. The best part is that everyone wants to be challenged, everyone wants to be asked about something they don’t know. It simply gives one an opportunity to learn something new.

It is this kind of an environment that motivated me to apply for GSoC in the first year itself. I did not get selected but I had the courage to sit through and select organisations to contribute to. I gained the motivation to learn new technologies and draft a proposal. Not to forget all the help I got from my seniors.

`SDS.assignProjects(vaibhav)`

Coming towards the end of the semester, everyone was assigned a project. Mine was to make a python package to aid some functionality of Muzi (our very own music player). After the exams, I chose to continue to work on Muzi during my summer vacations. During that course, I learnt many new technologies like Node, React, Redux and Sass.

Everyone at SDSLabs is open to new ideas, no matter how ambitious or silly they might be. There is a General Body Meeting held every week where we discuss the progress of our projects. If anyone comes up with a new idea, people are eager to work on them. This usually leads to everyone working on multiple projects. I guess the best thing about working in Labs is that the projects are essentially yours, blessed with the inputs of so many diverse minds.

`vaibhav.closeWriting()`

I missed the annual trip. Looking at the pics, I really regret missing it. Ultimately, the best part of being a part of SDSLabs is being with people who are weird like you, people who think differently.

The recruitment test will be held in January. Do give it a try even if you are remotely interested in software development. Believe me, you do not want to miss this chance.

Creating an ML competition platform for students

Sat, 15 Dec 2018 00:00:00 +0000

About Cerebro

A machine learning competitions hosting platform created for the students of IIT Roorkee where they can share the latest news, blogs, links to research papers and their approaches and can also practice or compete along with other students to work on their skills.

How it all started?

The idea started when there was an increasing number of ML enthusiasts on the campus. Suddenly there was a boom and students started learning different aspects of machine learning (ML) be it predictive learning, computer vision or NLP. For this growing community there started a lot of groups like Data Science Group (IIT Roorkee), Computer Vision and Language under ACM chapter IIT Roorkee and various paper discussion groups. Students and professors started using various applications of ML in their research. Now they are even introducing Deep Learning in their research fields.

Many resources of learning data science, machine learning, and deep learning were introduced and shared. The popular ones like the Kaggle, Analytics Vidhya and Data Camp. Few courses from Coursera, EdX and MIT open courseware were the new things people were focussed on.

The amazing thing was that all the students accepted this change and shifted from competitive coding and started looking at these courses and apply their knowledge in various competitions like Microsoft Code.Fun.Do, American Express data science, ZS Associates etc.

Statistics, Financial mathematics, Artificial Neural Networks, Fuzzy theory were the popular courses students started learning on their own from the help of these sites. Apart from these courses many programming languages apart from the traditional culture of Java and C++ came like Python, R came into light. We were amazed at the rate people were learning them and applying them.

To hold this much amount of information which students were having from different resources there was no proper platform inside the campus to share and to check where they stand in the competition. Students were reading and learning a lot of things but without application of these studies, there was no point in just reading stuff.

There has been a drastic increase in the field of Machine Learning and Data Science in the corporate industry as many companies are working on using this for their products to remove human error and improve the product. With an increase in the career opportunities in ML from various big companies during the internship/placement season, it became an important objective for people to practice their skills and to know their knowledge in respect to the other students.

The one solution to practicing questions was to rely on one popular platform to hold competitions for which we require sponsors and money. To share knowledge about different research papers, blogs, and other learning material everyone had to rely on various facebook groups on ML, Data Science, Deep Learning which was generally a lot of trouble to keep a track of and bookmark them. So, there was a need for a college-focused competition website to conduct proper test practices, competitions, hackathons and spread ML and data science knowledge.

With keeping these important points in mind, at SDSLabs IIT Roorkee, we started with a project to create a platform with main objectives -

Practice and improve skills on various kinds of questions.
Hold competitions to work on the new questions.
Share as much information as possible, like, research papers on new techniques or their work/ blog on a question they solved in a different competition.

The long journey -

After getting the idea of a platform, we began from the most important thing, research.

Research Process

We were clear on our users. The user idea in general.

A student in college, in an age group of 18–23, looking for practicing questions and share information. He/She has joined various Facebook groups and has an account on popular platforms to practice. He/She is making time to study these courses and doesn’t want any more time waste. You know… like a regular student. :P

So to create a platform for this user, we started by trying to understand their current process.

A user had to go through multiple sources to figure out about data science and practice on the international leaderboard of Kaggle and take participation in contests on AV. They also join multiple groups on FB to take guidance on ML and data science.

After understanding the current process, the problems for a beginner in this process is —

Not a common platform to post, save and look at shared blogs/links etc.
Local leaderboard for college based competitions.
Practice questions of different levels.
No team to contact or support directly.

So, to overcome we decided to build free of cost competitions holding website and a local leaderboard to understand their ranking in the college level for placements and share a common community for exchange of information. The user’s requirements include a leaderboard, competition website, share information on a common platform of college which is maintained by DSG IIT Roorkee.

Information Architecture/ Wireframes

Then after this, we started looking at why people are so much inclined towards kaggle.com for their competitions. Turns out that people were not only interested in the level of questions there or the number of genius solutions. They have a very simple style of competition website. They have various badges for different profiles. They have a really cool design.

We decided to make the same structure for this website keeping this thing in mind that if students come to this website, they should feel familiar to the process and do not find any problem in understanding. It’s like if you buy a new bike and if the handle buttons are changed then you will find it difficult to understand and you will have a bad experience. Although, you won’t give up on your bike, of course. :P

The header consisted the of Home, Practice, Competitions, Leader-board and a Profile photo (consisting of profile section and logout option).

The website was divided in the header into different sections focusing on major questions like these —

How to make sharing links/blogs/articles easy?
How to help in practice questions and promote it for beginners?
How to keep competitions very distinct and not mix with the practice?
Should leader-board be a distinct section in the header?
Is profile section important and if it is then what are the main reasons why people will use it?

Answering these questions helped to decide what, why, where the different sections should be kept and how much importance each hold?

Sharing links/blogs/articles were kept at the home as it was all about focusing on the beginner students to help with various content on ML. So a News Feed section was created at the home from where people can post their material. Users can also save the post they like and delete their post directly from the screen.
Practice and Competitions were kept as different sections to make a pseudo boundary and keep it easy for the users.
To share various information there was a slider on the main page. The slider consists of information about new competitions or any kind of notice which is to be told to students.
The importance of the Profile section will be just to reach out to the saved posts, update details etc. But most importantly users might like to look at their small details like the number of questions they did, posts they created etc. For this, we decided to keep a small card in each section at the top consisting of these details.

Front-end Development

Languages used include HTML/CSS and Javascript. It was in MVC architecture. As the site is dynamic, the front-end was done on using the powerful virtual DOM of ReactJs library.

Features

Posting links, blogs and any other material with a ‘Post’ section which contains markdown options. Reason being that most links are shared or code is shared which can be introduced easily in a markdown format.
Adding team to complete a project. As some of the competitions require a team to participate. Team request, invites can be sent.
Some of the posts which a user likes can be saved and be looked later in the profile section by clicking on the ‘star’ button. Similarly, posts created by one can also be deleted.
The user can add his personal details to introduce himself in a better way by mentioning his/her social links and writing a bio.
Banner is added on the landing page to introduce or promote any sort of competition or notice through a carousel format.

Design

Homepage

As the homepage consists of the main feature of posting stuff, saving them and deleting them. It also contains carousel which contains information and news feed which contains information from other users.

Practice

The practice section consists of a list of problems with a direct button to their individual problem page.

Problem Page

Problem page consists of 4 sections in case of practice and 5 sections in case of competition problem. These sections are-

Description
Data Set
Rules
Submit
Leaderboard

Competitions

The competition section contains one card specifically for the latest competitions. So to emphasize it, the card is placed centrally above all the other competition questions. The ‘+’ button is to add the team. When clicked it opens up a team create and join modal as shown earlier.

Leaderboard

This section consists of the overall rank and the points scored of the latest 5 questions so that the key users who are in good positions are always aware of the new questions.

Profile

The profile section contains lots of information about the user where he/she can upload his/her social links and also check other details like ranking, saved posts, individual problem score.

UI style guide

Illustrations

Logo making is the best part in designing. It allows you to take up random ideas and convert it into something so simple that it makes sense. For us, its more like trying to explain something in a very simple manner or explaining its core values. For Cerebro, we tried to explain the basic working of machine learning and what it means in one line. We converted that idea into a logo.

The logo presented has a very crude meaning about what is Machine Learning. Machine Learning for a rookie is defined as a black box technique. It helps to generate a conclusion regarding a problem either by solving classification problems or regression problems. Here, this logo is a fusion between the two ideas of Black-Box and a result from it.

Several other illustrations made for the same website

What’s next

With the launch of Cerebro towards the end of October, we have already held a week-long competition ‘Melodious Medley’ which saw more than 200 submissions and 100% uptime. We also have two more competitions in the pipeline this semester based on Computer Vision and Natural Language Processing. With initial goals being reached, we look for what’s next. Recommendation System? Way to early for that! New metrics and data visualizations? That sounds much cooler. So stay tuned for v1.1 :)

HackInOut 5.0

Thu, 13 Dec 2018 00:00:00 +0000

Hackathons are an integral part of a developer’s journey. They help us experiment, grow and meet a beautiful mixture of talented people. We present a recollection of our winning experience at India’s biggest community hackathon, InOut.

It all started on September 1, 2018 when word got around the campus of IIT Roorkee that InOut was going to hold its 5th edition. InOut is the largest community driven hackathon in India comprising of 150 participants chosen from approximately 4500+ applicants, both students and professionals, all over India. SDSLabs being a forerunner in technology, decided to participate in this glorious event. 4 teams from SDSLabs got selected for InOut 5.0. My team TrojanHash comprised of Anish Mukherjee(me), Nikhil Kaushik and Harsh Jain.

Fast forward 1 month, and we found ourselves in Bangalore on October 12, 2018 at CoWrks for HackInOut 5.0. InOut was conducted at the best workspace we’d ever seen. The venue, CoWrks, was a co-working space as the name suggests. It had a large hall with rows of desks for most of the area. There were couches towards the front where you could relax. The environment really brings out the hacking spirit lying dormant within one’s soul. I remember sleeping for only 2 hours for the entire duration of the hackathon (36 Hours).

CoWrks, New Indiranagar, Bangalore

Members of SDSLabs on the verge of unveiling the mysteries of the universe

The hackathon kicked off with talks by various companies that were part of the sponsorship roster for the event. These are not usually very interesting talks. But we decided to sit through, and guess what? We enjoyed them. One of the speakers suggested that we aim to optimise our time spent in brainstorming. A little too less could result in a slouchy end product, and a little too much would leave less time for implementation. Unlike previous hackathons we didn’t arrive on the scene with an idea discussed beforehand which we could bend to fit the event theme. Thus, the new aim for us was to have a pure hackathon experience and brainstorm from scratch using insights we got from the talks.

“The creation of something new is not accomplished by the intellect, but by the play instinct arising from inner necessity. The creative mind plays with the object it loves.” - Carl Jung

One of our crucial goals was to try to get our hands on technology, language or domain which we were unfamiliar with or which sounded really cool. Blockchain was the one! Matic, a blockchain startup, also one of the sponsors of InOut 5.0 had announced a special prize for a Bill Splitting application based on blockchain at the beginning of the hackathon. We almost instantaneously decided to contest for the special prize.

We had to make a bill splitting application on blockchain using Dai Stable Coin as the cryptocurrency. We did what every professional developer does at the beginning……Google !!!

We got to know that Dai was a cryptocurrency quite different from the conventional bitcoin and ether. Unlike bitcoin or ether, Dai was backed by collaterals. Like how someone registers his land or house as collateral when applying for a loan, and failing to repay the loan within the stipulated period of time, he/she must repay the balance amount with the registered collateral, Dai operated on similar principles. Dai is backed by collaterals such as ether. If a user fails to repay another with Dai, the balance amount will be paid with ether(ETH) which was registered by the original user when purchasing the Dai stable coin. The ether is registered as collateral when purchasing Dai through a concept called CDP(Collateralized Debt Position).

Collateralized Debt Position (CDP) allows you to lock your crypto assets (only ETH, for the time being) into a CDP vault and gives you a loan of 66% of DAI (1 DAI = 1 USD) against the deposited amount. If you want to get back access to your locked crypto, you will just simply repay your borrowed debt in Dai. Hence, if someone fails to return the borrowed Dai on time, it will be paid to the lender from the CDP Vault.

The conventional bill splitting applications such as Splitwise only kept records of transactions amongst peers. It didn’t give any assurance for the balance amount to be settled among the peers in the future. We finally understood what Matic really expected from participants. It was not a Bill Splitting Application in essence, but a Currency Borrowing and Lending Application.

Enough chit-chat, time to code. We read the principles of Dai and implemented the smart contracts which is the logic pertaining to the transactions in Solidity. Solidity is the primary language for building apps on blockchain and is one of the worst languages in terms of how easy it is to debug. After that we used Truffle.js to compile those smart contracts and deploy them to Ganache, a blockchain platform that can be hosted locally. After that, the contracts can be called with the help of Web3.js, a javascript client-side library for interacting with the blockchain.

We had just started building the web-interface when a flash of inspiration ran through our minds. Building a blockchain application is cool and all, but won’t it be cooler to build an entire ecosystem, something which can blow off their minds?

Two questions arise:-

Why?

We decided to build something better than what was asked of us. Using Web3.js, the transaction logic had to handled in the frontend itself. If we built the UI using Web3.js for web and Web3j for Android( we were also going for a mobile version ), it would have been too much work and we could not have completed it in the given time. Also why not build it in such a manner that even other developers could build something from a part of it? Moreover, at that time, there was no medium which implemented Dai smart contracts and provided an easy-to-use interface that could be integrated across all devices. Hence, we went for an ecosystem instead of an application.

How?

Long live REST APIs. If we shifted the entire logic regarding transactions to the backend, and exposed endpoints pertaining to specific operations, then we could have made the entire ecosystem highly extensible.

Endpoint Examples:-

Operation - Get your current Ethereum Balance
Request Type - GET
Endpoint - /getEthBalance
Request Params - address(The address of the user account on the blockchain)

Operation - Convert Ether to DAI tokens
Request Type - PUT
Endpoint - /convertEthToDai
Request Body :- 
address( The address of the user account on the blockchain )
privateKey ( The Private Key of the user )

Now, we don’t have to write the business logic twice ( one for web and another for android ). Just use the API and get your work done easily. And now the application could be extended very easily to even iOS, smart watches, etc. This was one of the major factors which led to our victory.

By now, you must be wondering by using a REST API as the communication medium we have essentially destroyed the “decentralised” nature of blockchain. This is a valid argument considering the fact that the API becomes a single point of failure in the entire ecosystem and blockchain boasts of “no single point of failure”. We already considered this and hence we designed the API to be “stateless”. No user information is being stored in any of the API hosting servers. So even if one server fails, another one can easily take its place. Hence, in this the entire system has no single point of failure. The current architecture looks like this:-

I started building the REST API while Harsh started building the UI for Web with React.js and Nikhil, UI for Android. As soon as I completed a portion of the business logic, I would test the API endpoint with Postman and if everything went according to the plan(which it never did),I would share the API endpoint with my teammates via Postman Collections who in turn used that endpoint route and designed the portion of the UI pertaining to that accordingly. This process continued, we skipped meals, some cool sub-events during the hackathon and slept for only 2 hours during the entire 36 hours timespan. In fact we were so tired that we slept like a log on our return train journey and we missed our station (but that is a story for another time).

Finally after overcoming lots of hurdles, our ~~application~~ ecosystem was completed.

Then came the presentation phase. We were a nervous wreck. We felt that the time was too less to be able to present our idea in its full glory. But somehow, our presentation proceeded quite smoothly. The judges were delighted with our approach and implementation. We went along with the flow and even showed them the source code of our pride, The REST API. ProTip:- Never waste time by showing the source code during a hackathon presentation because only the end product matters. We were lucky that our presentation had already left an impact before we reached that point, so yeah, a narrow escape.

Conventionally, the prize ceremony would have followed, but sadly, not for us. We had our flights, so we left the venue before the prize ceremony took place. We were later informed by the HackInOut team that we had bagged the Matic First Prize and that they would be contacting us soon. Going by tradition, a commemorative photo is in order, so here you go

Left to Right : Nikhil Kaushik, Anish Mukherjee(me), Harsh Jain

The source code is available at GitHub https://github.com/harsh-98/splitDai. If you are intrigued then go have a look :)

Optimizing Webpack for Production

Fri, 26 Jan 2018 00:00:00 +0000

As a part of SDSLabs, I had been involved in building the official website of Cognizance, the annual technical festival of IIT Roorkee and also Asia’s second largest technical fest!

Brief Background

The website is built on ReactJS and Node.js It is a typical end to end application.

I will focus on the react part of the application which is one of the client of our Node API.

n00b steps

Now, as you might know, when webpack does its magic on the code, it generates a single huge bundle file, that contains all the code required for front-end function. Because we are working with single page applications here, this means that browser will fetch all code at once which can lead to slower page loads which can be a bad experience for end users.

Being 4 months into the development, we now have 3 different react apps served on three different namespaced routes, almost complete, but wait, bundled size of all three of them in production is around 900 KB, woot, not feasible for deployment.

From the above production build, we had three apps with average size of 1 MB.

Over 60% of our user base are mobile users and around 40% of them are using degraded internet (around 70 kbps) and we just could not afford to make them wait 10 seconds. We needed to reduce bundle size.

Correcting some mistakes

First step was to remove unnecessary npm modules (or unused). Doing a thorough investigation of package.json and the codebase and removing unnecessary imports and corresponding packages was another tiresome job but it proved to be fruitful. package.json can get get dirty when you blindly install some packages for testing and then forget to remove them from dependecies. However, it took us one full day to remove those unwanted packages.

This practice reduced the bundle sizes by around 120 KB.

The introduction of async await

Stumbling upon reducing bundle size, I came across the concept of async await.

Async/Await 101

It is a new way to write asynchronous code. Previous available options were Promises and callbacks. They are non blocking just like promises.

const a = async () => {
  // console.log will wait till b resolves
  console.log(await b())
  return "Done"
}

a()

An async function returns a promise implicitly, and the resolved value of the promise will be whatever we return from the function.

More Details

Back on track

The main idea is to first break the components into finer components and then load these components when needed.

First step was to create a wrapper that would take a component, and return another component. These wrappers are called Higher-Order Components (HOC).

Our HOC is an async container:

// AsyncContainer.jsx

import React, { Component } from "react"

export default function asyncContainer(importComponent) {
  class AsyncContainer extends Component {
    constructor(props) {
      super(props)

      this.state = {
        component: null
      }
    }

    async componentDidMount() {
      const { default: component } = await importComponent()

      this.setState({
        component: component
      })
    }

    render() {
      const A = this.state.component

      return A ? <A {...this.props} /> : null
    }
  }

  return AsyncContainer
}

The asyncContainer function takes a component as input and renders it when the importComponent resolves. This can be implemented in routes as:

// routes.js

...
import asyncContainer from './Containers/AsyncContainer'

const Base = asyncContainer(() => import('./Components/Base'))
const WelcomeContainer = asyncContainer(() => import('./Containers/WelcomeContainer'))

const routes = {
  component: Base,
  childRoutes: [
    {
      path: '/',
      component: WelcomeContainer,
    },
    ...
  ],
}

Everytime the asyncContainer is called, it will dynamicaly import the passed container. In other words, when we visit / route, then a chuck file is loaded dynamically containing the WelcomeContainer.

This concept can be extended to individual components too. Suppose we have an header that can be split into two components RightHeader and LeftHeader. So, previously when header was mounted, both of these components used to come within the Header chunk, but now walking on our new path we can make them mount dynamically thus separating the view blocking components.

An example of how header is rendered

// Header.jsx

...
async componentDidMount() {
  const { default: RightHeader } = await import('./RightHeader')
  const { default: LeftHeader } = await import('./LeftHeader')
  this.setState({
    RightHeader: <RightHeader />,
    LeftHeader: <LeftHeader loading={false} />,
  })
}

We implemented this on every route, login/signup modal, headers, various containers and many more small components.

The mighty webpack config

import path from 'path'
import webpack from 'webpack'

import UglifyJSPlugin from 'uglifyjs-webpack-plugin'

export default {
  entry: {
    app1: './src/app1',
    ...
  },
  output: {
    ...
    filename: 'js/[name].bundle.js',
    chunkFilename: 'js/[chunkHash].[name].bundle.js',
    ...
  },
  module: {
    rules: [
      ...
    ],
  },
  resolve: {
    extensions: ['.js', '.jsx'],
  },
  plugins: [
    new webpack.optimize.CommonsChunkPlugin(),
    new webpack.DefinePlugin({
      'process.env': {
        'NODE_ENV': JSON.stringify('production')
      }
    }),
    new webpack.optimize.OccurrenceOrderPlugin(),
    new webpack.NamedModulesPlugin(),
    new webpack.NoEmitOnErrorsPlugin(),
    new UglifyJSPlugin(),   // This further reduced the bundle size
    new webpack.IgnorePlugin(/^\.\/locale$/, /moment$/),  // If you are using moment
  ],
}

Now on running

 $ cross-env NODE_ENV=production webpack -p --progress --config webpack.prod.config.babel.js

Production build webpack created around 40 chunks (because of use of async/await), that will be dynamically loaded when needed.

This practice greatly reduced the main bundle size and we were under 100KB for app1 (our landing page), this meant max 2 second for landing page loading (Achievement Unlocked).

You also have to include babel-pollyfill because async/await are not included in browser by default.

Final Production Deployment

It’s not at all important to get it right the first time. It’s vitally important to get it right the last time.

When served with gzip the bundle futher compresses from 383 KB to 87.2 KB. Yay!

After applying all the above techniques, we were able to reduce the page load time to 4 seconds and first visible button at 2.1 seconds. These stats were acceptable for the time being.

Final Problem

Now, after the successful deployment, the next major problem is the build time. With current config the build time was around 93 seconds, too much!!. We are still working on improving the build speed, but its on hold because of other feature addition to the application.

I will talk about how to reduce the build time in future. Till then,

Patience is a conquering virtue. - Geoffrey Chaucer

2-D Game Design Process for Beginners

Fri, 19 Jan 2018 00:00:00 +0000

Game design, thinking of it makes us to think mostly about COD, Assassin’s Creed, Batman: Arkham Asylum and many such amazing graphic games. But there are other games as well which were a part of our childhood and we still play them i.e. 2-D games.

2D games have taken a special place in gaming industry mainly because of the kind of different ideas and simplicity it has plus they are easy to make in respect to 3D games and many famous mobile games are 2D or 2.5D (as unity says). Examples of such games are Angry Birds, Candy Crush and many more.

As a beginner in game design field , I found it difficult for me to find some good sources to learn how to make simple games and thus wanted to share my experience as a beginner to simplify the process for others who like games not just to play but to create their own world and find it amazing as an industry and wish to learn. So, even I started with a 2-D game design as my first game. The game is called ‘Enroute’. The article aims to make a simple path to create basic games for beginner game designers.

Enroute — game by SDSLabs

Basic 4 steps in game design —

1) Ideation, where we develop and work over the idea. It’s like the spine of the game which tells us what exactly we are going to make in the game.

2) Story and Narrative development, where the main idea is to work on a story relating your protagonist and antagonist and involving your world/ environment with them. Here we write the complete story line with each and every twist we believe to put in.

3) Character and World design, where we work on designing the characters as per the requirement of the story and the kind of game we are making like in 2-D game and considering it moving in one direction, I made my character like this.

4) Play-testing and Prototyping, which is an important part of designing the game. Play-testing helps you out in knowing much about the various loopholes in your game and we can even note down the reaction of our players as in which part affects them in which way. Surprised or bored or what twists you were expecting and how they respond to it.

Therefore, following these four steps helps you keep your work in an ordered manner and reduces time delay and helps keeping balance in the game plus making the process simple at the same time.

Using the 4 steps above in Enroute Design ing—

I proceeded with my game in this manner only which surprisingly helped me to complete its design at a good speed and keeping everything ordered.

1. Starting with ideation

The game was coded over in a night in a gaming hackathon conducted within SDSLabs where the theme was to create simple 2D games. The idea of the game was simple as to keep avoiding obstruction and move forward. So after the game was coded it used to look like this :

First look after the Hackathon

2. Story Development

This is where my actual work started. As I was given something like that image and I was to make it at least interesting for the player so even if he looks at it once he tries to play it. With this motive I started working on the story and believe me the more inspirations you think of the easy it gets for you to search a story. The inspirations for you can come from various comics, movies, novels, cartoons or anything you like in your dream world anything like that. The game design is a place where you can make people see things from your perspective and this is the coolest things. Many of your ideas for story may come from some dreams. But not in my case, I am a big ‘star wars’ fan and my story was also something on the spaceship and exploration.

3. Character and World Design

Now as my story was complete I started working on how to display my character and I was very impressed by the ‘KetchApp Games’ and observed how they make games. Most of their 2-D game have two sections. One character and the things it can interact with and the other one is the world which is mainly in background. The world is generally colored and the character and its surroundings is kept generally black.

So my main character (protagonist) is an alien invasion spaceship which is landed on this planet Tokoyoo and is moving through it. The blockings in the game are (antagonist).

The reason to make my character look like flying object and a little sci-fi I made it something like this.

Main Character (An alien spaceship)

The world design was also thought out to be of some different because my world was supposed to look like some other planet and give a different feeling. I went for inspirations for the world design from various online sites like Pinterest. Thus, I worked on the background mainly on sky and mountains. Their natural color is somewhat different and I made it something like this.

Structure Generation

After color & detailing

4. Play-testing

It was the most amazing part because this is where you test your own made game for the first time. I asked my friends and seniors at SDSLabs to play it and I noted their reactions and difficulty they faced. Then I worked on the music and decreased the speed of the antagonist to make it better.

A lot of information is collected from play-testing like how much colors affect the game-play and what reaction player has with respect to your game. Is he bored or is it too difficult for him. This helps you keep balance in the game.

Statistics —

The day after it was launched, I was curious to know the stats and it was never publicized much so I wasn’t expecting much of the output but it showed really good performance for the first day itself.

The mixpanel filter was used to get the analytics of the game and this filter gets blocked by the AdBlock app in the browser.

Statistics of the game on the launch date

Conclusion —

This is how I designed my first game. Right now, you can play the game here at ‘Enroute’. As a part of experiment, this game was never developed further no more changes were done like changing background just to make sure that the user feels like that the time is running in the virtual world and many other important changes. But despite being monotonic which everyone feels after playing it for a few times, it made me aware about a lot of things in designing games and helped me learn this process.

There is this small video of the game and all of the game design details can be seen over Behance. The game can be played over here.

So thank you for reading it till the end, I hope all the beginners like me out there find it interesting and will soon start creating their own worlds and don’t consider it to be a tough fight.

Pramit Singhi

Final recruitment list For 1st year (2018)

Sun, 14 Jan 2018 00:00:00 +0000

We interviewed 75 people before releasing the final list of selected people. It was a really tough job to filter down from the talented applicants to the final list. Sadly, we have limited vacancies and can only take in a limited number. But this is not the end of line for others, there’s still a way to join SDSLabs. We’ll continue taking open lectures on variety of topics. Stay connected with us on our Facebook page for the updates regarding this.

Programmers

Harsh Kumar Bhartiya (CSE) 17114036
Harshit Maurya (CSE) 17114037
Hritvi Bhandari (CSE) 17114039
Kanav Gupta (CSE) 17114042
Nikita Singh (CE) 17113077
Palak Goenka (ECE) 17116050
Piyush Sethia (CSE) 17114057
Saksham Kukreja (IN) 17310015
Supratik Das (ECE) 17116071
Twarit Waikar (CSE) 17114074
Vaibhav (CE) 17118077

Designers

Kshitiz Kashyap (MSM) 17312013
Tanvee Moghe (GT) 17410029
Yash Khandelwal (CE) 17113133

Team SDSLabs

Working at SDSLabs (14)

Thu, 28 Dec 2017 00:00:00 +0000

Before SDS

Like most of the people after JEE, I too didn’t know much about computers and programming, though I was curious enough to explore it. After coming to IIT Roorkee, the biggest question was from where should I start? I was advised by seniors in ice-breaking sessions to explore various fields and make use of opportunities available here. Initially, programming seemed so diverse that I found it overwhelming. So, I started learning HTML and CSS, as I had somewhat learnt it in class 10. Through this, I was able to get into NSS Technocreative Web-Development cell. Apart from that, I was able to learn Java in my Object-Oriented programming course.

From the beginning, SDSLabs was continuously organising various competitions on Erdős, Codevillage and Backdoor. Through these, I got to know about SDSLabs and became more inquisite in software development. Then, I decided to look into full-stack development during the winter break and get into SDSLabs.

Entry to SDSLabs

I still remember, it was 2 o’clock on the last day of SDSLabs’ interview, and the list of selected members was to be declared by the day end. Selected students were getting called by SDSLabs .On the other hand, I wasn’t even called for interview round. (inner me , “bhai ka fir kat gya”).Then I decided to give it one last shot, called a senior and found out that due to some confusion with names, my name was struck off even before getting to interviews. They asked me to come in 5 mins and took my interview, it was conducted in two stages. First round was about general programming and critical thinking, the main motive of this round was to galvanize me. Next round, was more or less a discussion, and to my enjoyment (and to my relief) they were asking about my point of view on certain problems, and it was really fun.

Two hours later, they announced the final list and my name was there.

Journey Begins

When I entered SDSLabs, among the first things which grabbed my attention was the pink interior (there’s an interesting story behind that ), which were lined up with achievements of the members and alumni. I was both impressed and inspired by them, and how they were able to achieve so such within such a short timespan at IITR. At labs, we were expected to be complete beginners and a recap of some basic but important topics was provided. Lecture on various topics ranging from HTML/CSS to networking, and emerging fields like bitcoins and blockchain were held. Through projects we are able to apply it for creating awesome and useful applications. While going through this cycle of learning and testing our knowledge, seniors guided us and helped with our silliest doubts.

During that time in February, Microsoft organised “code.fun.do”, my first hackathon, with some help of seniors and spending sleepless nights, a small but full blown application was ready. That encounter with new technologies, developing application and it’s delivering was astounding.

SDSLabs is at its peak when most of the members are there, discussing and developing together. This makes the whole atmosphere very energetic, and most of the time scrutiny is over various topics like unix, devTools and sysadmin stuffs. Through this bombardment of knowledge, I have got to learn a lot. Sometimes, we compete for most hours spent in labs to maintain workaholic environment. Often I have returned at 2-3 o’clock (and fellas, its A.M.), and sometimes even spent the night over there. One of my favorite nights is when we conducted the internal hackathon to develop some of our own applications, got to work in a team and that trifling competition, including the most entertaining part of flying kira’s drone.

Sometimes, gyan sessions from seniors are necessary to keep ourselves motivated. Resources and direction provided by them help in maintaining swift workflow. Following reddit, hackernews and medium has become a part of my daily routine. Without even realising, I have gained so much from labs each day that such exposure wouldn’t be possible anywhere else.

Fun and Trip

Chapos is one of the in-built features of SDSLabs. Within labs, whenever someone does something great, it means a time for chapo. Every group in IITR has chapos but the frequency and level with which SDSLabs has, are unmatched. We also have an annual trip, last year it was to Rishikesh. Packed with trekking, camping and rafting, along with a lot of fun, it was a complete package. Playing mafia, sharing our life experience, listening to others and late night horror stories made it more memorable. The following day’s rafting and cliff jumping was thrilling.

Last year that I spent here has taught me so much; fun and entertainment helped in easing this process and kept me motivated.

Recruitments

We are going to have recruitments within the first half of January and will be looking for some of the most curious and energetic minds of the younger IITR junta. These recruitments are a way of knowing our juniors and letting them know about us.

Waiting eagerly for you. (inner me, “aaye aapka intezaar hai”).

Working at SDSLabs (13)

Sat, 23 Dec 2017 00:00:00 +0000

Noob-ish Beginnings

Before starting life in IIT Roorkee, I was an ultra noob in computer programming. I remember writing some BASIC programs in standard 8, but it’s a fleeting memory. Plus, I’d taken physical education as my optional subject for boards because its supposedly easier to score in. The result was that I could knock off names of different yoga asanas and tell you what not to eat before expected cardiovascular exertion, but had very little idea of how the internet works. However, starting off with an empty head did prevent me from having any preconceived notions(good or bad) about programming.

I’d heard about SDSLabs while looking up pros and cons of IIT Roorkee after JEE results, and it sounded like a fascinating group to get into. During first semester, I learnt some basic c programming, and then extended to c++. I learnt OOP in java in one of our courses. During winter break, I dabbled a bit in android development while coding an application for Droid Wars 2016.

Alohomora Lab!

After the recruitment test in January 2017, I got called up for an interview at around 12.30 am, which lasted for 2-3 hours. I was elated on getting a call at around 4.30 am that confirmed my selection. From the first day itself, the lab seniors made us feel very comfortable. There isn’t any visible hierarchy in SDSLabs, the group functions with a collective aspiration of its members to create and innovate. I personally felt a sense of responsibility to somehow contribute in carrying forward the group’s legacy after listening to narrations of the various exploits of our alumni in their campus days. I’m sure everyone else feels the same way, and that is essential for SDSLabs.

Work Cuture

In the initial days, we had lectures on topics like web development, bash commands, version control and networking. Staying in lab for long hours became routine, and I loved every moment of it. Cycling back to RJB at 4am is a chilling experience, but well, it was worth it. I remember a lecture on MVC starting at 10pm and ending at around 7am the following day! People at SDSLabs are always receptive to answering your doubts, even the seemingly foolish ones. We have members with interests in various fields like data science, competitive programming, os development and infosec, so there is always someone to guide you in your field of choice. Seniors at SDSLabs are always open to holding discussions/lectures on different topics and seeing their level of expertise in different fields is a truly humbling experience.

After the first few weeks, minor projects are assigned under a mentor. The nature of work at SDSLabs involves bug fixing/feature addition on existing applications as well as developing a new application or a version of an existing one. Code bases are large and similar to what one might experience in industry. The code size can be overwhelming initially, but my time in lab taught me that reading large volumes of code, not exactly reading but glancing long enough to get the gist of it, is an art in itself.

One of my biggest takeaways from time spent in lab is that I could acknowledge the pain people have gone through over the years to make life easier for future developers. How simple fluctuations between two voltage levels, or in binary terms 0 and 1, were somehow exploited to create complex systems that play such fundamental roles in our lives, is truly mind-boggling. Computer science as a field earned my respect, and for that I shall remain grateful.

All Work & More Play

We had an amazing annual trip to Rishikesh; playing mafia, sharing anecdotes and life experiences next to soft embers of a fireplace along the banks of the Ganga, under a starry sky. There are regular chapos, often to celebrate someone winning a hackathon or getting a cool internship. We have countless running jokes, some of them a bit stale, but they get recycled after prolonged use! Life at SDSLabs is fun, and it is far from monotonous.

A Lifelong Association

A member’s association with SDSLabs doesn’t end after graduating. We maintain strong contact with our esteemed alumni through our Slack organization and constantly look up to them for advice and guidance. In fact, a plusplus(its an internal appreciation thing) from an alumnus is greatly valued, and nearly every post from an alumnus on Slack is showered with love reacts!

Recruitments

SDSLabs holds recruitments annually for first year students in January. Do try to give it your best shot. It’s great if you make it; but even if you don’t, feel free to contact us, for as rightly said by the greatest wizard of our time, “Help shall always be provided at SDSLabs to those who ask for it.”

SDS Hackathon 2017

Tue, 05 Sep 2017 00:00:00 +0000

I want you to go out and observe a random group of bees dancing in total chaos. Now, I want you to look at a beehive, appreciate its structure and understand the perfection which went into building it. The process which guides such a random crew into making things which personify perfection is what truly describes the purpose of a hackathon.

Participating in SDS Hackathon was a very nice experience for us and winning the competition makes it even better. Besides this, the process that goes into taking a brainstormed idea to a working project was an experience that taught as a lot. I was a member of the team named HackOverflow and we optimised the OCR process to make it compatible with mobile processors and to make it capable to recognise text from live camera stream. So, here is a glimpse of the entire process from brainstorming to the final presentation.

Brainstorming the idea

Though this part marks the beginning of any hackathon but this is also one of the toughest part. The problem being originality and the X-factor.

Our team had a few members who were fluent enough in Android Development, so the choice of the platform was easy. We began by exploring various android apps particularly those developed by Google. One of the members was obsessed by Google Keep and so to tease her we started to find flaws in the app. After fighting over some random shit, we realised a genuine feature which was missing in the app - the ability to read text from the camera (OCR).

Well, exploring this feature was then inevitable. We found some libraries which could read text from static images. So just adding the ability to read text from a static image was child’s play (credits to the awesome Google Vision Library). So we decided to extend this feature to incorporate live camera stream and add this to a note taking app like Keep.

The development process

The main motive of the hackathon was to make freshies aware of the various domains of the technology and to make them comfortable with the process of software development.

Each of our team member was on a seperate ground as far as Android Development was concerned. So making them work together (Being careful of the fact that the first yearites do not lose their interest owing to the intimidating nature of the project) at the same level was a near Herculean task.

We began by dividing the tasks by carefully analysing the prior knowledge of a particular member and their capacity to learn new stuff in the given time frame and assigning respective tasks to them.

The constant help from the members of MDG and SDSLabs proved to be a great enthu booster. There were times when we felt that our idea was infeasible and that we would not be able to complete the project. But the perks of winning and the thought of achieving something which could be of great potential was sufficient enough to raise our morales and to put our asses to work. Finally, the best part was infinite food and drinks which were provided by the organisers.

Finishing and presenting the app

We worked continously for 36 hours skipping food and sacrificing sleep. But all the hardwork paid off when we first took out our app for testing and it read the word Nescafe perfectly from the top of a Latte Pack. We were so happy after achieving what we aimed for.

Screenshots

So here is a glimpse of what our app actually does. It can read text from live camera stream !! Be it a video or a static image or a random poster you saw while driving, it can read them all.

Then came the presentations. We had to present our application, first to the members of SDS and then to the Professors who were the final judges of the competition. The presentation part too was quite interesting as we were introduced to a plethora of new ideas from fellow contestants. The entire audience took interest in the presentations and there were a large number of enlightening questions, both from the jury as well as the audience.

Results

The results were declared soon after the presentations. We kept our fingers crossed as the results were declared. The judges summarised the attractive points of all the selected projects and then declared the winners who were later presented with the trophies.

Overall it was a fun and enlightening experience to mentor a bunch of freshies to learn and create new stuff and syncing them with the experienced developers to create technologies of the future.

Final recruitment list For 1st year (2017)

Sun, 15 Jan 2017 00:00:00 +0000

Programmers

Aaushi Kamble (ECE) 16116027
Anish Mukherjee (ME) 16117015
Ankit Kataria (ECE) 16116006
Deepesh Pathak (ECE) 16116018
Harsh Jain (CSE) 16114028
Harsha Sharma (EPH) 16122010
Karan Shrivastav (EE) 16115059
Kartikey Pandey (ECE) 16116029
Kriti Singh (CSE) 16114036
Manan Jain (CH) 16112040
Nikhil Kaushik (CSE) 16114040
Shiva Gupta (EE) 16115104
Utkarsh Shukla (CSE) 16114068
Vedansh Bhartiya (CH) 16112100
Yash Dev Lamba (ECE) 16116079

Designers

Ashutosh Gupta (CE) 16113022
Chirag Sharma (CE) 16113026
Divya Mangal (CH) 16112023
Milan Maheshwari (CH) 16112045
Samar Singh Karnawat (ECE) 16116056

Team SDSLabs

To and fro SDSLabs

Mon, 09 Jan 2017 00:00:00 +0000

I want you to close your eyes & imagine the most satisfying experience you have had. It feels good doesn’t it? Even if it’s all in your brain. For me, that experience is perpetual. It’s learning.

That is the most fulfilling and rewarding experience one can get. It’s when you’re curious about something, when you have a ton of questions - every one of them starting with How or Why! And you scratch & pick your brain to get your head around them, for days, all in vain. And then suddenly, on one such day, comes the moment of realization & delight when you get to the bottom of it. It is that I’m talking about.

Believe it or not, I just described how each of my visit to SDSLabs feels like!

The journey so far

A year ago I was just another tech crazed enthusiast. I liked fiddling with computers and I liked to wonder. Although that’s describing what everyone here does (in a very minimalistic way)! But you get my point - every time I fork a child process to retrospect my time here, it transfigures to a human torso giving me two thumbs up! Such a spellbinding time it has been!

No question (as the seniors said when I first came) is silly, if it can’t be answered! Or there is nothing like a stupid doubt. It is here that I have grown from being a naive freshie that I was, wondering about what happened to the data when we clicked submit to working with technologies like Laravel, message queues and Docker. There has been much to learn in these past 11 months. At this very time last year, in a similar blog post, Ashish says, “all discussions are open to all lab members and it is this lack of bureaucracy which makes lab a very comfortable place to be in “. I couldn’t have said it better. Being here has taught/made me aware of a few very important things e.g. how to look for help to help yourself (read stackoverflow), introduced me to the world of OSS (read filing PRs) & taught me how to stay updated in a rapidly evolving and tremendously dynamic field of software development (read HN).

Every time I walk in, I’m surrounded by fellow members brainstorming an idea or a design or trying their hands on some fancy new dev platform. And as I’m about to sit and open my laptop I look at the wall in front of me embellished with markers showing the bounties and glory our senior members have reaped for the group and the milestones we have reached. It is both motivating and humbling.

Neither Jack nor dull

Once in a while, someone would win an Xbox for a change and as you can imagine it goes fantastically well with the 40” TV!

Being here is definitely fun. Now you don’t get to crash servers often, do you? In a few hackathons that I and other members participated over the year in places like Jaipur and Surat we have had people who recognised SDSLabs and that’s rousing!. Once in a while, someone would win an Xbox for a change and as you can imagine it goes fantastically well with the 40” TV! With the fun yearly trips that I’ve been to and the sheer number of cheese bursts I’ve had, I can say, with utmost conviction that this is the quintessential campus group.

Pièce de résistance

Innovation and collective learning go hand in hand. SDSLabs has been at the very core of cultivating and nurturing a computer programming culture in the campus for several years now, acting on the aforementioned philosophy. It is indeed a very gratifying, humbling and a matter of pride when we as members see the effect SDSLabs has had as group in opening up I.I.T. Roorkee as a whole, to the vast sea of tech enthusiasts all around the country and out. It might seem to you as if I’m over emphasising, which I’m not. The competitions which we hold on our platforms witness participation from top teams across the world with our dedicated servers handling hundred thousand requests at a time! And that is no overstatement. As Paras Chetal says in his blog, it feels good when we see random people around the world recognising our platforms.

I can start listing the tech giants from Google MTV to Facebook and universites from M.I.T. to N.Y.U. where the alumini base of this group has expanded to, but that (although motivating) will be being boastful, which does not serve the purpose I talk about when we started.

Circa 2015…

It is then I knew that this is the place which could provide me with the pleasure I talk about in the very beginning!

There (generally) is a lot of fuss & confusion among the latest lot of students about what this group is, what it does in the campus. Unlike many, I came to Roorkee with no previous knowledge (or bias) of this or any other campus group for that matter. I knew that I enjoyed programming and hence attended the intro talk of every other tech group. SDSLabs being one of them. And it is after seeing all the applications it had for the masses and the vast variety of fields the members worked in, I knew this is the place that could provide me with the pleasure I talk about in the very beginning! I let the work of SDSLabs influence me not what they talk about it.

Pens Down!

As we are browsing Facebook and quickly arriving at judgements whilst being in the warmth of our bed, from the little NAT-enabled bubble of comfort (called Internet), we forget that the roots of this group lie in the time when people didn’t have access to the world of fuss outside. It is then, Muzi was born (still boasting a collection of 180,000+ songs) and Live and D.C.. This just goes on to show that unlike the common perception, SDSLabs is one of the most open group, all our secrets just a click away! I have been fortunate enough to be a part of this group and hope I can keep adding to the legacy.

So long. Till next time.

Winter of Code 2016 Results

Fri, 06 Jan 2017 00:00:00 +0000

Winter of Code (WOC) was a month long program organized in IIT Roorkee for the first time by SDSLabs to improve the open source exposure in campus and help first yearites get a taste of open source community with a GSoC like timeline.

We got a great response from IITR Junta. Cheers to all!

From a staggering 100 submissions, 8 were chosen to continue their projects under the mentorship of SDSLabs members (GSoCers themselves). It was a great experience for us to mentor such an enthusiastic crowd. Their dedication, hard work and passion makes us believe that they have a bright future in this field.

After a hectic 30 days of coding and 5 days of rigorous evaluation, here we present the list of students who have successfully passed the final evaluation:

Vishal Sharma (ECE)
Vishwas Mittal (CSE)
Suyash Gupta (EE)
Suyash Mahar (ECE)
Yash Dev Lamba (ECE)
Deepesh Pathak (ECE)
Aviral Verma (CSE)

We wish them the very best of luck for their future endeavors. Happy Coding!

Working at SDSLabs (11)

Thu, 05 Jan 2017 00:00:00 +0000

`grep SDSLabs`

I got to know about the existence of SDSLabs, much like most of the people do, through the infamous JEE rank list they had released. Before coming to Roorkee I had looked at their portfolio and some of the applications they had launched and was thoroughly impressed. In fact, I was so impressed that my decision to take up Computer Science at IIT Roorkee instead of some other branch at some other IIT was perhaps even biased because of SDSLabs’ existence.

`pacman -Sy recruits`

Throughout my first semester I kept hearing about the amazing things the members of SDSLabs were working on and though I did not understand most of them, it only motivated me further to be a part of the group. I attended the lecture series they had organized, worked on few infosec challenges on Backdoor, independently learnt python and coded a couple of projects during my winter vacations and put them up on Github. By the end of my first semester here, I was pretty confident in what I had learnt. Remember this, I did not have much knowledge about programming before coming to IIT Roorkee. So, in fact, most of what I have learnt about software development in such a short time is directly/indirectly due to SDSLabs. This is what I like most about SDSLabs, that it has been successfully able to raise from scratch, a whole new culture of software development at IIT Roorkee! And not just that, SDSLabs has even played an indispensable role in promoting fields like information security, competitive programming, machine learning etc. in the campus (and beyond!). Every student here at IIT Roorkee should be grateful to SDSLabs for this.

Coming back to the recruitments, I got shortlisted directly to the interview round by winning the n00bCTF16 among the freshers. The interview was one of a kind! I remember sitting in Labs for around 4 hours being interviewed by different people in different skillsets. I got to know so many different things just being interviewed by these people in this duration than I had learnt in my entire first semester!

When I got a call from SDSLabs that I had been selected, I was ecstatic of course. But I had worked towards this end for quite some time, and it did not come to me as a shock.

`init`

I had realized during the recruitment interviews themselves that I barely knew anything. That was confirmed within the first few months of interacting with the seniors. I, slowly but surely, was getting better through the lectures and assignments that the seniors used to give, and even by just talking to them. Conversations around the dinner table during the frequent parties would be of things like UNIX, FreeBSD, and other such terms I had only heard of before. The initial few weeks were a humbling experience for sure.

`kworker`

I started working on Backdoor a few months later after getting familiar with the code base and understanding how it worked. It is written in PHP and it took a bit of getting used to, but it was fun nevertheless. A lot of work I did here at SDSLabs was also oriented towards sysadmin stuff. Getting the servers up and running, updating them, making sure the challenges on Backdoor were working properly etc. For this latter part, I learnt about docker containers, chroot jails, xinetd and how best to automate the entire process of secure deployment of challenges. Read about it here.

In my 3rd semester, I traveled to Surat to participate in the InOut 3.0 hackathon where we were shortlisted for the final rounds for making an in-sync music player: stroom. It was an amazing experience and I got to meet a couple of SDSLabs alumni there too!

The seniors are always ready to help you out, whether be it for SDSLabs related things or otherwise. Like I said before, most of what I learnt is directly or indirectly due to the seniors and other members.

`cowsay “Do you even chill\?”`

Oh yes, we do! We went on the annual trip to Rishikesh a few weeks after the recruitments where we camped near a stream, trekked a bit, played Mafia, sat around a bonfire and listened to horror stories. We had multiple gaming and movie nights in which we would watch movies and play computer games all night long. Since the SDSLabs seniors were always winning something or the other, the parties were frequent too. We dance like crazy! We have many inside jokes about the members and some applications.

After the farewell party, we stayed up all night just listening intently to the final-year seniors talk about SDSLabs. It clearly showed on their faces how much they cared for it and it’s members. I don’t think I’ll ever forget that night.

`CTRL-R`

Looking back, being in SDSLabs for this past year has been a great experience. SDSLabs has changed me. Browsing hackernews and productive subreddits has become a part of my daily routine now. It makes my day when I read about a random stranger on reddit recommending Backdoor to practice security challenges, or when someone lets us know on chat.sdslabs.co that he wants to use it for a presentation he has to give.

I hope that I too am able to contribute to this culture that SDSLabs’ seniors have pioneered here at IIT Roorkee. I, therefore, encourage all interested freshers to give your best shot for the recruitments. We will be recruiting in January. For more details, visit join.sdslabs.co .

Final recruitment list For 1st year (2016)

Sun, 17 Jan 2016 00:00:00 +0000

Programmers

Abhay Gupta (EE)
Ayush Maheshwari (ME)
Deepak Verma (EE)
Ketan Gupta (CSE)
Manish Kumar Dangi (P&I)
Mohan Agrawal (Engg. Phy)
Mugdha Jadao (EE)
Nisha Agarwal (EE)
Paras Chetal (CSE)
Utkarsh Gupta (ECE)
Utsav Mangal (CSE)

Designers

Naman Rajput (GT)
Pramit Singhi (EE)
Tanmay Joshi (P&I)

Team SDSLabs

Working at SDSLabs (10)

Mon, 04 Jan 2016 00:00:00 +0000

The Initial Launch

Being a non-coder during my school days, I had never expected to be a part of one of the most technical groups of the campus. It was in July 2014, when I was first introduced to SDSLabs via their famous JEE listing. It was then that I knew it would be awesome working in this group. I got in SDSLabs in January 2015, after an interview that lasted half an hour at 3 in the morning (Yes, in the morning!) during the campus recruitments that year. I never thought I’d get selected considering the fact that I accepted in my interview that I had no prior experience in development. And this is one misconception everyone needs to get over. To be in SDSLabs, you only need to be eager to learn.

The First Few Days

After all the glamour and appreciation faded away, came the time to start developing and learning. January was filled with tonnes of lectures on web development. I remember in particular a lecture on php that took 6 long hours to finish, after a 9-5 schedule of classes that day. But it was always fun. It was the first time that I was interacting with seniors with such freedom and it was a wonderful experience altogether. All this was followed by picking up our own projects and start working on some real life applications.

The Technology

Right after joining SDSLabs I was introduced to technologies like git, node, scala, jquery, laravel, lumen, three.js and many more. These opened up an entirely new world of technology for me, being a complete newbie in these things. I shifted to Ubuntu, one of the best OS you could have. I learned game development, creative arts, design as well as web development along my journey.

Srishti

In March arrived Srishti, the cultural festival of the Hobbies Club. I took up a project on 3-D projection mapping called “Kakashi” and remember missing all my classes and sleeping in lab for 3 consecutive days at that time. It was the most interesting time I had in lab. The project involved shooting all of the lab members singing “Animals” by Maroon 5, and projecting them on 3-D face maps for an exotic virtual feel. We demoed the google cardboard, made games on the Leap motion device and had a lot of fun along the way. That was the most exciting time I had that semester.

The Trip

Exactly one week before the mid terms, we planned to go to Rishikesh for the Epic Lab Trip. I have to say it was the best time I had in IITR by far. Late night bonfire and Mafia was followed by Rafting in the morning. The interaction level boosted and we all became a part of a family after this trip.

The People

At SDSLabs, I got to meet some of the most creative minds at IITR. The level of interaction is immense and you get to meet people working on every field in Computer Science and Technology. The Kandoi sessions, teasing Sopan, body tips from Aditya, GSoC tips from vampire, the Aps and Divij Chicken Chapos and the Palai Gyan have all made the journey more and more special along the way. Lab has been the most interesting time that I had at IITR and I can’t imagine my life at IITR without these people.

The Farewell

Bidding seniors off good bye is always hard but is fun too. We made sdslabs.co/farewell in half an hour, made individual invitation cards and made the whole experience memorable.

Recruitment

SDSLabs will be recruiting in January. If you want to be a part of Lab you can find further details here. And remember you only need to be eager to learn to get into lab.

“Stay hungry, Stay Foolish!”

Working at SDSLabs (9)

Fri, 25 Dec 2015 00:00:00 +0000

This post is a continuation to SDSLabs’ now customary series of posts before the recruitment in January where we write about our experience with lab.

It has been 11 months since I joined lab in January and I find it difficult to distill down all the experiences in this post. But I’ll try.

It is very amusing to me as I reflect back on the changes that SDSLabs has brought in my life so far. Checking emails and Slack and Hacker News has taken a precedence over Facebook and Reddit, Elementary OS has replaced Windows, and python has replaced video games. Lab is the place where I was first introduced to the fascinating realm of open source software. I had always loved using software since the NES games days but actually starting to make it myself has been nothing short of a revelation to me. Thanks to SDSLabs for that!

Learning Experience

The first month was spent in lectures and getting up and running with the essential tech. After that I picked up Backdoor and worked on a new feature. Then Srishti, hobbies club’s annual tech-exhibition arrived and I managed it’s website and also made a rock-paper-scissors game with the Leap Motion device we have in lab. In the summer break I worked on some small side projects. Other than that, participating in a hackathon allowed me to try out a crazy but fun idea. My major project was on Backdoor’s behind the wheels automation which introduced me to some very exciting technologies. I have written about it in detail in another blog post.

Work Culture

Work culture in lab is literally what it’s motto says: Think. Build. Ship. You can work on any existing project that you like or even a new one. Senior members in lab are some of the best mentors you can get in campus. There are a lot of things to learn everytime you talk to them, be it best practices in writing software, or some new interesting tech, or even what you should google if you want to do . Not to forget the code reviews from time to time. Slack, with its amazing addons has now become an integral part of lab's culture. Every commit message, code review, new issue, and deployment status goes straight to our Slack. We have this system of `++` and `--` that keeps the score of every lab member and we use it as a tool to punish bad deeds (seriously, those `--` hurt so much; btw I am about to hit 100 for the first time, unless someone resets it yet again while testing their custom bot scripts). One important aspect that has also been mentioned many times in previous posts is that all discussions/code is always open to all members. This lack of bureaucracy makes lab a very comfortable place to be in.

Fun

Like most campus groups in IITR, we also have our annual trip. Last time we went to Rishikesh. Playing Mafia late at night on the banks of Ganga (my n00b level in this game is over 9000) and the river rafting next day made it memorable. We also have our fair share of chapos. Working in lab is fun.

Recruitment

SDSLabs goes recruiting this January. Visit join.sdslabs.co for more info and keep an eye on our Facebook page for important announcements.

Dockerizing Backdoor

Fri, 27 Nov 2015 00:00:00 +0000

Backdoor is a long-lived Capture The Flag style competition run by SDSLabs. For the uninitiated, in Capture The Flag (CTF) style events in network security, participants have to solve questions in various categories like cryptography, web, binary exploitations etc. Backdoor hosts CTFs from time to time having duration ranging from 6 hours to 1 day.

On the basis of how challenges are presented on Backdoor, there are two broad categories:

Webpage-based (hereafter referred to as public type):
These challenges are accessible from a web browser. Example: JUDGE, MEDUSA.
Interactive challenges (hereafter referred to as script type):
These challenges are accessible over netcat. Example: CLOSED, RAPIDFIRE

Then there is the third type where the challenge requires both types. Example: TEAM.

Previous architecture:

The public-type challenges were served by an Apache server running at https://hack.bckdr.in. The script-type challenges were run in chroot jails and served using the xinetd super-server. chroot operation is used to mimic the current directory as the root directory of the system ([change]root). More can be learned about this from this post by Dhaval Kapil.

Problems with the previous architecture:

For public-type challenges, the same structure has been retained. Earlier, all challenges had the same virtualHost but now each challenge has its own. This was done to better implement challenges that required custom rules or a custom domain name.

Script-type challenges, however, had some major problems:

The aim is to run all script-type challenges in chroot jails but adding new environments to the jail is a huge pain.
There is a big problem of redundancy. Because each challenge runs in a separate jail, each of them had their own copy of the necessary environment. This can be solved by creating a common jail for all challenges, but that puts other challenges at risk in case one of them gets compromised.
Automated monitoring of challenges’ deployment status is not easy because there is no standardization.
Deployment takes up a lot of time. Shifting challenges from one machine to another and ensuring they work fine required a lot of manual labour given that we have 70+ challenges and many of them require an elaborate setup.

Tackling the problems:

Initially, I started working on problem 4 but figuring that out was turning out to be insanely difficult because of no standardization in the challenges. It was obvious then that a restructure was necessary. Looking for alternatives, I found Jails in FreeBSD. While these jails did solve problem 1 with their ease of setup and adding new environments, problem 2 still persisted. I came across Docker while learning about jails and after spending some time in containers, Docker became the obvious choice.

How Docker solves these problems:

The description on the Docker website reads:

Docker allows you to package an application with all of its dependencies into a standardized unit for software development.

And that’s precisely what we need!

Setting up a new environment is as easy as docker pull python which effortlessly sets up a python image for us. And we can make our own Docker images to be used and combined with other images.
Each Docker image consists of a series of layers. Docker makes use of union file systems to combine these layers into a single image. These layers are where the magic lies. If you want to update an image, instead of updating the whole image, only the relevant layer is updated. And these layers can further be used to stack images one over the other! So we can just build a python environment once and use the same for building secondary layers without redundancy thus solving problem 2.

With the major problems sorted out, lets look at the new architecture.

The new architecture:

The flowchart below explains how we build layers upon layers to reduce redundancy.

First we build an image hack-base that is based on an Ubuntu 15.04 image itself. We use this image to install various packages that will be required by multiple challenges and thus reducing redundancy. We follow the same approach as we move up the chart. We make separate images for each type of primary environment (nodejs/python etc) and further build an image for each challenge + images for any external dependency they need (like redis/mongodb). Then we create what are called containers that are instances of the challenge images and link containers of external dependencies, if any. It’s worth noting that the user cannot modify the image itself. The user is provided with a writable layer over the container. You may as well run rm -rf /* in an Ubuntu container and it will delete all your commands and system files but only from that instance. So you can just close the container and spin up one more in less than 2 seconds and whamm! you get the vanilla system back!

As for the networking to and fro from the container, we have to expose the ports that we want to map to the system. Say if a challenge based on python listens on port 8999, we expose this port from within the container and map it to a port on the system (usually the same as the one in the container). The Docker documentation provides good examples for this. Then we use the xinetd super-server to listen to the requests to the specified ports and spin up a disposable container accordingly.

The deployment tool:

To solve problem 4, we created a tool named Beast. Beast is written in python and performs all the tasks from syncing the challenges with the production server to building the challenge images and setting up the xinetd service. It can be used to deploy challenges locally or to multiple remote machines at once. After any action is performed, our Slack channel receives a notification from Beast about the deployment.

Beast also monitors the resource usage of running containers using google/cadvisor and raises an alarm if something looks bad. It also exposes an API to check the challenge deployment status.

One important feature of the new architecture is the standardization it brings. Now each challenge specifies a setup file that is used as a deployment guideline by Beast. Let’s take a look at a sample challenge pytest that is a mixed-type challenge. The setup file for pytest is shown below.

The keys used are self-explanatory. Note that the challenge creator can also specify bash scripts for elaborate deployment (like if some challenge requires composer install).

Here is a sample of how the tool works:

What’s next?

We have some really cool ideas in store for Backdoor in the coming months. Stay tuned for more!

Note: This post is also available at Dockerizing a CTF.

Launching Hubble

Wed, 02 Sep 2015 00:00:00 +0000

Today, we launched a new application called Hubble.

Well first, what is Hubble?

Simple answer, Hubble is a link sharing platform for IITR junta where they can share resourceful links.

Whenever you come across something catchy online and feel that it’s pretty interesting, what do you do? I guess, you share it on Facebook or Google+. But, as you might have noticed, these resources get buried under the pictures and status updates of your friends. Hardly does anybody open Facebook when in a mood to read about something insightful.

So, we decided to create a platform where you can easily share links to articles and videos that you think will help others, being sure that it is read by right minded people.

Whenever you read a trendy/mind-blowing post, a pathbreaking scientific research article or an interesting UI/UX article and want to share it not only among your friends, but also to a larger audience having similar interests, Hubble is your place to go. It is not only about sharing links but you can also start a discussion around something through comments.

Ask Hubble: Do you want to ask the users’ opinion on certain topics?

Yes, you guessed it right. You can also post questions (without links) where the users can answer or give their opinions. All you have to do is go to the Add page and start asking your question with Ask Hubble: as the prefix, or you can click on the link in the suggestion text above the input field, and it will insert this prefix for you.

Ensuring that the resources shared by people do not end up being spam, we are restricting to an invite based Sign up system. This is to ensure that the links posted are worth your time and do not link to adult or religiously inclined content. Also, you might not want to read insensible or irrelevant comments. Not that we are trying to enforce anything. Only that at present it lacks moderation, so we had to restrict the sign up in some way.

You are still free to use Hubble without Signing in. The Signin restriction is only for engagements like voting, posting and commenting.

We will also be distributing invites to users based on their activity. They can then invite their friends.

Now lets talk about some technical aspects of Hubble.

The technologies used while building and in running Hubble are:

The backend is on PHP using Slim (a microframework)
The backend follows the MVC code architecture pattern.
We are using Twig as the html templating engine.
We are using SCSS and hence made our CSS life a bit easier
We also delegate boring tasks to our faithful CLI tool Grunt.
We are using Mailgun for mailing.

Announcing phoenix

Sat, 04 Apr 2015 00:00:00 +0000

As part of the recently conducted BackdoorCTF ‘15, we developed a redis based queue taskrunner for phantomjs tasks called phoenix that we are open-sourcing today. This blog post is about the problem we faced and the solution we developed and how it can help you.

problem

As part of two challenges in the CTF (MEDUSA, JSHUNT), we wanted a browser solution that could automatically open the webpages for the challenge in a safe environment after each submission. These challenges are web challenges and require techniques such as XSS, which means that they can only be exploited in a real browser.

Unfortunately, running a full browser such as Chrome/Firefox is not feasible in such sitations. Instead, we decided to use the most popular headless browser phantomjs for our task. Using phantom is hard, though. It has its own API, which uses JS, but is completely different in its own manner (too many synchronous methods, for one).

As part of the CTF, we had to build a queue system as well, which would do the following:

Setup a new webpage
Start a new phantomjs instance that visits that particular page
Store the result of the run (log id) somewhere and report it back

Since a lot of this is common to both the tasks, we decided to create a small tool that helps us run these jobs.

phoenix

phoenix handles the following for you:

setup a common configuration for a task
start multiple jobs on that task, each with a slight variation
jobs are run on phantomjs
store logs of each run
report back log id to the task queue

This is all done via a mix of redis, phantomjs and nodejs.

configuration

phoenix is configured via a config.yml file, which is expected to be present wherever phoenix is run. You can see the sample config file for a list of configuration options that phoenix supports. These include things like user agent support, custom headers, request body (in json or post format), basic authentication support.

Another thing we support is the ability to run custom javascript before the page visit starts. This allows you to set default variables (such as tokens and secrets) that will be available in the JS context once the page visit is made.

page visit

We have a lot of sensible defaults for phantom, which include a maximum timeout of 10 seconds, and extended timeouts for whenever a web request (such as image/script/ajax) is made.

logging

All jobs that start get their own id, and create their own directory with three files: config.json, page.log, and browser.log. The first holds the complete configuration object that is passed to phantom. The second is the console log of the web page (which means any console.log statements made in the web page context). The third is a higher level log containing browser events such as redirects, web requests and timeout extensions.

We plan to make the logging format configurable, but for now it is file system based.

job config

It is assumed that (generally) each job will have its own url, slightly differing from the task’s standard url. This is handled in two ways:

You can pass a query parameter, which is sent along with the url specified in the config
You can pass a valid http/s url that will be visited as it is

queueing

To push a job to a queue, you do the following:

Generate a queue id by RPUSH to a channel:queue list in redis
Publish the queue id on the channel in redis

log in redis

For each job, the job id (generated randomly) is stored in the channel:log:id key in redis. This can be polled to check whether the job has finished or not.

As you can see, phoenix is a very robust mechanism to handle a variety of job queues. It is available on npm today as the phantom-phoenix package, which sets up a binary called phoenix. Further instructions on usage etc can be found on the repository.

We hope it will be useful to people looking to setup a queue system based around phantomjs instances. Since it uses redis as the queue mechanism, it can be easily scaled to multiple machines as well.

Backdoor Internet Launch and scytheCTF

Wed, 04 Mar 2015 00:00:00 +0000

Last year, in March, we organized BackdoorCTF’ 14. BackdoorCTF is a jeopardy style capture the flag competition. It reflects our aim to foster participation in the field of competitive Computer Security.

Last summer, we discussed the idea of converting Backdoor into a year round platform for computer security hackers. Things started to get interesting. We were excited to kickstart the project development. Before anything else, we knew that designing challenges around real world scenarios was critical for platform’s success.

Slack played a major role for discussing both design and structure of the code. An overview of the application’s user experience design and interaction can be seen here. By the end of October 2014, we had Backdoor deployed over the intranet of IIT Roorkee.

The initial aim was to launch Backdoor over the internet. We want it to be accessible to any inquisitive mind. Following a major refactor of the codebase, to modularize its backend, we made Backdoor accessible over the internet starting 24th February 2015.

Backdoor is accessible at backdoor.sdslabs.co. Challenge designers can be found hanging around at chat.sdslabs.co

In order to make sure we have a stable and robust platform ahead of time, we organized scytheCTF. For this we invited participants from both IIT Roorkee and outside. It started at 4 pm on 26th February and lasted for 8 hours. scytheCTF saw a decent participation, enough for us to nail down bugs and issues. We have already fixed any major reported bug. With this we make way for our flagship capture the flag event ie. BackdoorCTF ‘15.

dcua won the competition.

Techical Details

Backdoor Challenges are hosted over a separate domain and on a different server to avoid cross-site scripting and ensure isolation
An inhouse tool is used for automating the process of deployment
Backdoor’s backend is written in PHP using Toro as the framework.
All the services on the server are running in a chroot jail thereby preventing access to the parent directory and files.

Muzi was down - Incident Report

Sun, 15 Feb 2015 00:00:00 +0000

The Situation

Muzi is one of the most popular application in campus, that boasts of thousands of all time users and thousands of listens per day. The songs collection of Muzi resides in a single Hard Disk of 2 Terabytes in size. This drive has a collection of 1,69,000 Hindi tracks and 72,000 English tracks.

On 13th February 2015 at 6:30PM, the hard disk died.

The drive showed signs of bad sectors which we suspect has been because of continuous read/write operations that happen 24X7 on this disk.

Impact on services

The workstation containing this disk also hosted couple of our services, thankfully in another hard disk. Muzi backend server was hosted on another Virtual Machine totally different from the storage drive. This means the muzi frontend website was available at all times, but the songs themselves were not reachable. We are really sorry for the outage. We regret as much as you do.

The other services running in the machine include Presence, our own lab tracking system and a gitolite instance that hosts all of our source code. These applications didn’t use the muzi hard disk, but suffered downtime as we had to perform hardware upgrades to the machine in order to rescue the bad disk.

Rescue Method

We immediately detached the disk from the CPU cabinet and checked for the actual losses. We analysed that most of the data could be backed up thanks to Windows Disk Analyzer. We further observed that when the disk attempted to read the bad sectors, it borked and did not allow us to read anything further.

We searched for alternative storage to transfer the 1.6Tb of data. That being a very large size, we had to divide the size into parts and transfer them to backup locations either by using a USB-Hdd adapter or by manually mounting it into other workstations that had enough free space.

We closed in selecting two workstations having free space of around 1Tb each and transferred the data into them. Note that this was a highly attention seeking task, since the transfer was to be restarted everytime a bad sector was found. We were doubtful to use any disk repair tools fearing a loss of nearby data.

14th February 2015 2:30PM

Thus at speeds averaging 20MBps transfer, we could succesfully recover almost all of the data. It took us 18 hours in the process of transfer.

Later we retired the defective drive and took another 2Tb hard disk and transferred back the tracks into it, which would then be the replacement.

15th February 2015 1:30AM

This disk was then put back into the same workstation hosting the previous disk and thus Muzi was revived!

Permanent Losses and Recovery

In this recovery process, we lost a total of 2000 songs, 34 of Hindi and rest of them of English. We are determined to get them back and in the next few days, we will cross verify our database dumps for the missing songs and get them back.

Thanks to Teracopy for humane copy controls and good error reporting in this regard.

Future Thinking

We are totally moved by this situation and will go to any lengths to make sure such an incident never happens again.

We have already drafted an initial plan of building our own Network Attached Storage housing massive space in 10s of Terabytes so that, we will never be short of space and resort to hacky methods for backup. We aim to shift all the storage intensive application to this NAS in the near future and take regular backups, however large the data may be.

Final Recruitment List For 1st year (2015)

Sun, 11 Jan 2015 00:00:00 +0000

Programmers

Aashaka Shah (CSE)
Abhinav Kaushal Kesari (ECE)
Akashdeep Goel (CSE)
Amit Manchandana (ECE)
Anuma Rathore (ECE)
Arpit Singla (EE)
Ashish Chaudhary (ECE)
Asutosh Palai (CSE)
Harkirat Singh (CSE)
Indroneil Kanungo (MSP)
Punit Dhoot (CSE)
Tanmay Tiwari (CSE)
Vaibhav Gosain (CSE)

Designers

Aviral Borah (CHE)
Amandeep Duhan (CE)
Parinishtha Yadav (B.Arch)

Team SDSLabs

Working at SDSLabs (8)

Thu, 01 Jan 2015 00:00:00 +0000

Introduction

This post is eighth in the series of blog posts written by members of SDSLabs over the years on their experiences and lifestyle in lab. Everyone has gained from being in SDSLabs in some or the other way and this is how the students from upcoming years can have a peek into the workflow of lab.

The Beginning

Like many other students when I initially stepped into IITR as a first yearite, the most prominent two words(other than my hostel’s name) I heard were “CGPA” and “SDSLabs”. On digging more into these two words, I got to know that these are the two most valuable things one can possess here. And naturally thus I wanted to be a part of SDSLabs, to further my zeal to learn. I had developed an interest in Web Development before coming for the recruitments, as I had tried my hands at it just to find out that I really liked it. After some time, I was finally recruited through a long but interesting procedure of a series of written tests and an interview.

I had to face a hard time letting the classiness of being in SDSLabs waft over me, because that is the point where you stop learning and start flaunting. I started getting over this and actually got down to learning pretty soon. As the immediate pre-requisite of being a programmer in SDSLabs is Linux, I had Ubuntu 13.04 replace my super common Windows 7, and this has been one of the best transitions of my life yet. I was made to learn git, PHP, JS, AJAX, Linux Command Line etc. within 2 months of joining lab. As I continued work I got to learn more things about frameworks, MVC, REST and web security. Now that it’s almost an year, Sublime Text and the Terminal are the first applications I open in my laptop, also the last one’s to be closed. When within lab, knowledge is like in the air. People are always found discussing and you are sure to catch one or two valuables if you listen to them. Most of the learning in lab comes along this way.

What I worked on

Echo

I did some feature additions in echo, the e-book search application of SDSLabs like the Admin Panel and the Book Upload form that have to be used internally by the administrators for book moderation. It was built on the framework Limonade and used Solr for indexing. It was mostly written by one of my very helpful seniors, who later on proved to be one of my best mentors. As it was my first project I gradually learnt good coding and commenting practices commonly used among developers.

Comments

I also worked on comments, which is a SDSLabs clone of Disqus and intends to act as the commenting system across all SDSLabs applications. It was instantiated with the simple thought of providing better speeds which couldn’t be harnessed while using an online application(here Disqus). It uses Slim as it’s framework and is planned to be finished soon.

The Fun

I was astounded at the number of Chapos(IITR lingo for treats) we had here. We had regular Dominos’ orders, Alumni sponsored treats, Convocation chapos, Placement chapos and what-not-for-no-reason chapo. We also have an annual trip to the most peaceful cities around. The Seniors here are so helpful and friendly that you can ask them almost anything(they’ll obviously omit what they want to though). The group interaction level is so high, that after some time you forget who you’re supposed to call ‘sir’ and who’s supposed to call you ‘sir’. We choose to omit the word ‘sir’ from our conversations instead.

The Environment

At SDSLabs we have really diligent seniors who answer even the silliest of our questions, encouraging us to participate in the discussions and taking up responsibilities for lab. I have peers, each good at what they were selected for. One of my peers for example has crashed his ubuntu around 4-5 times and is now an expert in matters concerning ubuntu. One of them has his own version of bomberman that he wrote in class 11th, cooler than most of the student-made games I’ve seen. One of them has applications ranging from captcha breaker to network manager, and is undoubtedly one of the best developers of my year. Amidst such hardworking and dedicated people, all you feel like doing is become like them, the zeal to learn keeps growing. All these people have been greatly contibuting in my learning process from day one, inspiring me to push harder.

Recruitments

If you feel that such an environment is what you long for, do sit for our recruitments coming January. I hope it’ll be a pleasure for you going through the recruitment process, and an even greater pleasure if you join us. Visit join.sdslabs.co for more details on the recruitment procedure and dates.

Working at SDSLabs (7)

Wed, 24 Dec 2014 00:00:00 +0000

This post is seventh in the series of blog posts that members of SDSLabs’ write every year to give an insight into what SDSLabs is all about. For people interested in joining SDSLabs but are not in first year, please read this post on how to join SDSLabs

Introduction

For the past year, I have been part of an amazing student group in the campus known as SDSLabs. Little did I know an year ago but now that I think of it, SDSLabs has become an integral part of my life and identity. It has been an eventful 308 days with a lot of things happening. Everyday I have got to learn something new. While going through this journey, I have performed every possible role, right from a programmer to a managerial one. I have learnt things from various programming languages to different networking architectures in such a short span from the fantastic people in lab.

Timeline

In my first year, I was way too excited to join lab. I appeared for the recruitment test but wasn’t able to clear it. I didn’t lose hope though, as I was told by Abhishek Das that SDSLabs recruits people from any year and so I continued to program and learn on my own. After seeing their blog post on lateral recruitment, I applied for an interview and this time I got through. My initial few days were spent catching up but everyone helped through it. The effect of lab was so prominent that my productivity and learning speed increased by 5 times. This exposure has also directly affected my coding style. It has made me a far better coder and introduced me to various design architectures. By the semester end, I was actively involved in managing various projects too. Since that interview, I haven’t looked back, keeping myself constantly motivated and learning with help of everyone in lab.

Learning Experience

I have learnt a tremendous amount of stuff as a member of SDSLabs. After I joined, one of the first thing I learnt was networking architecture. With multiple apps running under one banner and for same set of users, some level of architecture is needed that you won’t come across in a single project. Another really great thing I found was that every code/design/discussion on any project in lab was open to anyone, so you could just jump in and start contributing to any one of them. I contributed two small bug fixes to Codevillage, then moved on to rewrite the complete Play app (Lab’s internal music player), including addition of some features. My first major project was Experiences, this app had been into development for about 2 years. Many people had worked on but it wasn’t complete. It’s code was in a messy state, but we were finally able to launch it this semester. I also worked on JEE ranklist 2014 along with Ravi Kishore Rachuri, Divij Bindlish and Dhaval Kapil. Along with these projects I also added new features to Muzi, including auto updation of song database. Through all of these, I got to learn many concepts and new languages like Node.js, Go and Ruby.

Apart from applications, I got to participate in quite a few CTFs along with other lab members and this has given me a thorough understanding of security and an experience in CTFs which I now use to create questions for Backdoor.

Inside Lab

Work

Work culture in lab is just like that of a startup. There is lot of learning, hard work, innovation and inventions. You can work on any kind of project that you like. We have people who are proficient in many diverse fields right from machine learning, networking to cryptography to disassembly. We have regular discussions on every aspect of our work including long talks on UI/UX of a website to database designs. We have regular lectures and talks on various new technologies. Recently we also started have discussions on interesting research papers every few weeks. We also tend to open-source as much as we can to contribute back to the community. Overall, twelve members from SDSLabs have participated in Google Summer of Code.

People

For a lot of us SDSLabs is a home away from home. No matter what you want to discuss, you will find someone or the other with clever insights, whether it is CG, electives, anime, earthquakes or even biologically mutated rats! Even the fun filled sessions at lab are productive.

Technology

At SDSLabs, we use a plethora of technology. While most of lab projects are built upon PHP, MySQL and JavaScript stack, we have also explored many other areas. Many subprojects have been built in Node.js and Go. Python is also extensively used for writing scripts.

We use Slack and Google Groups to keep in touch. If you want more insight into how lab works go through [this post] (https://blog.sdslabs.co/2012/12/how-does-sdslabs-work/) (it is slightly outdated).

Fun

Fun is at the core of lab. From our own bot to our human bot (Abhay Rana), everybody is fun-loving. We have regular chapos including the ones to Hometel and Dominos. We have our annual trip around February. We regularly participate in hackathons and other technical meetups around India. We watch movies together on our 42” LCD TV on beanbags. It’s definitely more than just work.

Recruitment

We are recruiting this January. Visit join.sdslabs.co for more information. Some points worth noting:

If you feel you are highly interested and motivated about app development, lab is the place for you.
Try to find a bug in one of our applications, make sure to mention it in written exam. Just write it on the last page.
Willingness to learn is more important than CG, branch and technical prowess.

Lab has become an important part of my life maybe it will become yours too. If you feel like SDSLabs is where you should be, just come and give our test. If you have any kind of queries, come chat with us.

Working at SDSLabs (6)

Tue, 16 Dec 2014 00:00:00 +0000

SDSLabs will be having recruitments the coming January. We welcome promising developers and designers. This post is a continuation of the series of blog posts( 1, 2, 3, 4, 5 ) that we have written over the years to tell people about the culture and the working here at SDSLabs.

About

SDSLabs is a student group that works on many software projects. They are mainly web-based but as such there is no restriction. We have developed many applications for the IIT-R intranet. Lately, we have also launched a few of them on the Internet which have got a pretty good global response. We also manage the activities of SDS (Software Development Section) which is an open proficiency for all.

Learning Experience

Being a member of SDSLabs is a journey involving a tremendous amount of learning. I was initially introduced to various technologies like PHP, Javascript, AJAX, NodeJS, Python, MVC, git, etc. Even though we may have launched mostly web applications, I got to learn about many different things regarding Linux, networking, server management, security, etc. We have some of the brightest and most helpful people of IIT-R working at SDSLabs. Every visit to lab has provided me with knowledge about new concepts or some information regarding upcoming technologies.

Even though I am a part of many other campus groups, I can say that SDSLabs has been an immense source of knowledge and played an integral part in shaping my life here at IIT-R.

The most important thing in lab is that the source code is open to everyone and you are free to work on any project of your interest. Also, unlike other groups you can start working on major projects directly from your first year.

My Work

Erdős

A few weeks after my recruitment in lab I was asked to add some minor feature in Erdős. Abhishek Das was my mentor. Working under him and on his code was a great experience for me. I was introduced to proper MVC Architecture. This was the first time I had ever worked on someone else’s code. Erdős’s code is perhaps one of the best written code I have seen in lab. I learnt how to properly document my code and structure it alongwith some common coding guidelines.

Backdoor

By the end of my first year I was given the task to develop Backdoor into a proper application. The existing code was quite haphazardly written. It was pretty much disorganized. After pondering over a bit I decided to rewrite the backend completely. Abhishek Kandoi helped in laying down the foundation for the application. With constant help from Ravi Kishore Rachuri I rewrote Backdoor during the summer break. Although a little late, we were able to launch it at the end of October. I got to know many things about dynamic web applications starting from the initial setup to the final deployment stage. Apart from that I learnt more and more about security.

JEE Ranklist

As part of the custom(laid by Abhay Rana, aka nemo), SDSLabs released the JEE Advanced 2014 Namewise Rank List. I helped in getting the ranks, parsing the results and in developing the final website.

Culture in Lab

The culture in lab is pretty awesome. You can enter/leave lab anytime during day or night. There is a lot of interaction within the group resulting in a strong bond between the members. Even the alumni remain in contact with us through mails and slack(our internal group chat). We have chapos “regulary” at Olive, Hometel and Dominoes! We also go for an annual trip. Apart from the fun that we have we cling to our motto:

iDream. iCode. iInnovate.

Our goal is to turn dreams to reality through our projects.

Activities

We hold regular lectures and meetings regarding web technologies and Linux. We also organize hackathons like Syntax Error to promote development within campus. We hold competitions on CodeVillage, Erdős and Backdoor regulary.

We also participate in various competitions. A team from SDSLabs has been winning the Deloitte Collegiate Cyber Threat competition consecutively for the past 3 years at a national level. Last year a team from lab qualified for Microsoft Code.Fun.Do held within campus and went further to win the nationals! We were also the runners up in Angel Hacks International Series, Delhi edition. Twelve members of our section have cleared the prestigious Google Summer of Code program.

Recruitment

We have our recruitments in January. Visit here for more details. Some points worth noting:

If you are thinking of applying just for a high package in your future please turn back.
We are more interested in people willing to learn rather than somebody who just happens to know more.
Your branch is irrevelant to us. Currently we have just 15 members in CS whereas 36 non CS members.

Google Summer of Code Reunion Summit

Mon, 03 Nov 2014 00:00:00 +0000

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!

Launching Backdoor

Fri, 31 Oct 2014 00:00:00 +0000

Backdoor is a platform for the hackers out there to showcase their talent in a competitive environment. Currently it has been launched only within the IIT Roorkee campus.

It is a Capture the Flag styled event. A flag (basically a string) is associated with every challenge. Once you have solved a particular challenge you would get the hidden flag which you need to submit back to us for getting points.

History

In March 2013, SDSLabs organized the first ever Capture the Flag event by IIT Roorkee under the banner of Cognizance, the technical festival of IIT Roorkee. 80 teams participated in it from all over the world with Team dcua(currently ranked 9 at ctftime winning it.

Encouraged by its success, SDSLabs was back with BackdoorCTF ‘14 the next year during Cognizance. We had a participation of whopping 460 teams from 68 different countries.

Inspired by all this, we decided to develop Backdoor not only as an annual CTF, but as an application that consists of challenges available for the user anytime of the year, more like a continuous learning environment, a cyber security playground. Apart from this, we shall be hosting competitions frequently.

Challenges

The challenges in Backdoor will range from web, security, network, binary, crypto, etc. Each of these will have a score associated with them. We have tried to simulate real world applications so as to give a hands-on experience. To solve these challenges you would need to exploit some vulnerability.

Practice Arena

Backdoor has a Practice Arena where users can test their skills by solving various challenges. Each challenge will be tagged for easier accessibility. Users will be ranked based on their scores.

Competitions

This is where we would be hosting our competitions. There will be team participation as is the case with many other CTFs. Each competition will be open for a particular amount of time only and there will be a separate leaderboard for each one. Challenges will be shifted to Practice Arena soon after the competition ends.

Technical details

The challenges are hosted on a different server so that the main Backdoor platform is free from any exploits.
We even have a different domain for the challenges so as to prevent an XSS vulnerability in one of the challenges leading to the hijacking of the SDSLabs account of the user.
Backdoor’s backend is written in PHP using Toro as the framework.
All the services on the server are running in a chroot jail thereby preventing access to the parent directory and files.

Launching Experiences

Sun, 26 Oct 2014 00:00:00 +0000

Experiences is a collection of posts by the Indian Institute of Technology Roorkee alumni. It aims to guide as well as enlighten the new generation. The idea is to bring all this content together on a single platform and make it easily accessible for everybody.

It is always hard for current students of the institute to get in touch with the alumni. As such, there is a gap between these two realms. We have curated a list of blog posts by IITR alumni from various streams and years. We hope all this content can inspire a new generation of students to bridge that gap.

Experiences features a simple functionality to fetch content from existing blog posts. You just need to sign up and give us a link to your existing post, and it will be quickly added to Experiences.

We hope to see active participation from alumni as well as students to create a large pool of experiences that they had had at IIT Roorkee. If you want a post to be added to Experiences on your behalf, you can log in to Experiences and add one or you can mail us with a link to your blog post at contact@sdslabs.co.in.

Experiences is live at experiences.sdslabs.co on the internet.

Screenshots

Technical Details

Experiences has been in our kitchen for quite a while and needed a polish before launch.
PHP based backend using Limonade framework and JavaScript for DOM side manipulations.
Readability API for parsing blog posts.

Feedback & Chat

Fri, 17 Oct 2014 00:00:00 +0000

At SDSLabs, we take user feedback very seriously. This is why, we had a feedback application right from day 1 of our launch. If you’ve ever tried contacting us with a bug report, chances are you’ve heard back from us. We can’t reach our goal walking aimlessly. In SDSLabs we feel the users should define how they want to use our apps.So we change as you demand.

So it’s completely you people who define how close we are from our goal or what else is to be achieved. Your feedback is the one of the core elements of our motivation.

Software development is not easy, especially when you have lots of different projects, and only a few people managing them all. One of the things that makes it substantially easier is user feedback. To improve this feedback loop we are launching a mini-chat and a new feedback application today.

Comment anonymously or create private issues if it contains sensitive information, follow any issue to keep yourself updated via email notifications, upvote ideas and issues to help us prioritize tasks. Our new feedback application aims at providing all the required features so that you can easily state your ideas and convey the issues you face.

Chat with SDSLabs is a simple chat service that lets you chat with SDSLabs members. You can drop in to say Hi, or to report a bug, or perhaps even to clarify some doubts on a problem in Erdős or CodeVillage. The application is anonymous; so as to allow you to chat more easily, and so that we can interact with users from around the world. Messages from the SDSLabs team are highlighted, so you can easily notice important messages.

We are always looking for feedback to make our products better, and there are more upcoming changes in the pipeline that will help us with that.

You can check it out at chat.sdslabs.co. Just type a nickname, and you’ll be ready to go. We look forward to talking with you.

Our feedback application is also live at feedback.sdslabs.co.in.

Erdős: Search, Activity, πrates, etc.

Wed, 08 Oct 2014 00:00:00 +0000

Erdős is now an year old and has come a long way from when it was launched back in October 2013. As it continues to gain popularity among math geeks the world over, we have been silently working super hard to make it even better. Today, we’re unveiling lots of big improvements to Erdős!

Search

Tucked away neatly in the topbar, the search bar is accessible from everywhere and helps you discover users, problems, tags easily. This includes full-text search within problem statements as well as searching for a particular tag using square brackets, like this.

Searching for a user by name or username would return links to relevant user profiles as well as problems created by that user.

Searching for a tag would list all problems with that tag. For example, here we search for combinatorics.

It works just like you’d expect it to. Go give it a try.

Activity

In addition to activity across all problems on Erdős, you can also view recent submissions by a particular user or for a particular problem.

User Profiles

Lists were taking up too much space. Green highlights save space and look delicious.

Public profile information is now editable in profile settings.

We’re starting a newsletter service for Erdős. This will have upcoming competition details, new problems, feature additions and more. No spam of course. You can subscribe to it here.

Logo

Yes, we have a shiny new logo as well.

πrates

We are hosting πrates this weekend. It’s a 24-hour online contest with problems set by PAG and ₹7000 hard cash up for grabs, sponsored by Thomso!

Technical Details

We’ve shifted to a custom Opauth-based multi authentication framework which enables us to support Single Sign-On across all our internet applications.
Our newsletter service is powered by TinyLetter.
We’re using Monolog to log all actions made through our robust admin panel.

That’s all for now. Head over to Erdős and give it a try if you haven’t already. More updates soon. Cheers!

How does the sdslabs.co.in domain name work?

Sun, 27 Jul 2014 00:00:00 +0000

A very common asked question is about our domain name and how does it work locally. When we launched filepanda, and our preliminary homepage a long time ago, we had been using the easy to remember IP address https://192.168.208.208.

Now, however we are using the domain name sdslabs.co.in for all our services, including DC. To understand how this works, you will have to understand how the name resolution of a domain name takes place.

The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities.

Wikipedia

DNS is basically a service which resolves domain names to IP addresses. If you own a domain name, you can point it to wherever you want. This is usually done in the administration panel of your hosting services. We have setup multiple domains on our nameserver (mitsu.in as of the moment) to point to the IP address 192.168.208.x.

For instance sdslabs.co.in points to 192.168.208.208, echo.sdslabs.co.in points to 192.168.208.204 and so on. This is done via updating something called A records (this is the part of resolution which transaltes to IPv4 addresses).

The benifits of having such a system in place are enormous:

Users don’t have to remember IP addresses, and can easily remember the site address.
We can move around services, applications over different machines, and it will only take a single update to change the name resolutions
We could add alternative fallback servers easily (by having multiple A record entries) for a domain. We could even use this to point sdslabs.co.in domain to something that is hosted online, for instance.
We can have catchy, and simple to remember urls for eg https://sdslabs.co.in/login, and https://sdslabs.co.in/logout

Also, we are running all our services on https, which is not dependent upon the visibility of the website. Even though the site is hosted locally, the process of certificate signing remains exactly the same as any other site. Once we aquire a SSL certificate and attach it to our web-server, the visibility of the domain does not matter to the browser at all.

Note: For the benifit of those not in IIT Roorkee, we are running multiple web-service on the domain sdslabs.co.in, which is only served locally, as it resolves to a local IP address (192.168.208.208)

Collegiate Cyber Threat Competition - Wave III

Tue, 06 May 2014 00:00:00 +0000

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.

SDSLabs moved to Slack for communication

Sun, 06 Apr 2014 00:00:00 +0000

I don’t know of any other campus group that uses team chat tool. Most of them don’t need it. But SDSLabs is a software development team. We have around 50 members across 5 years who work on various projects with around 1 or 2 on each project. While we live in the same city inside the same campus of same college, it is still tough to stay connected with what’s going on. When this group started off around 4 years ago, the then members used google groups as mailing list and a Facebook group for staying connected. But this was never enough. Discussions used to happen through private messages on GTalk/FB Chat, when if the same discussion took place in public medium, others could also gain a lot of insight. We knew about Campfire/HipChat etc but their free tier limited the number of people you could have in a team. As a student group it was just not feasible for us to pay the hefty monthly fees, not everyone could afford it. We ended up using Partychat that was built on top of GTalk. With Hubot integration it was very good for us. At all times a few people were always online. It worked fine for us until Google Hangout came out which did not use an open protocol which was needed by Partychat. Even after that there was still a workaround through imo.im but then they announced that they are shutting down support for 3rd party chats. That was the final nail in the coffin for partychat and we needed to move out fast.

Right when this happened Slack came out of private beta and the best part was that they had a free tier which did not limit the number of people in a team. So we gave it a shot and Slack turned out to have everything we could have dreamed of. The biggest drawback of using Partychat was the lack of rooms/channel. All the conversation, meaningless time pass and technical discussions, happened in the same chat window. So people who were busy working preferred to close the window. With Slack, we have multiple channels: #general, #incubator, #design, some project specific channels and some private channels. Slack even supports different levels of notification triggers on a per channel basis. This has proved to be the best feature, at least for me.

Slack has way too many integrations available. Being on the free tier, we are restricted to 5. We have Hubot enabled because we can’t live without it. We are also exploiting the “incoming webhooks” integration for a variety of purposes.

One really interesting feature is that even if you leave the Slack web client open and leave your laptop unattended, it still detects that inactivity and sends you a mail in case of mentions. Slack is full of such small but really thoughtful features that make using it an absolutely wonderful experience. Since moving to Slack I have found that we are able to have more conversation and the friction to starting a discussion has reduced a lot since there’s an appropriate channel for everything. We are not a company or a startup with a remote team but we are totally in love with Slack. It remains pinned in Google Chrome for me. After college, if I ever go on to start up Slack will be the first thing I’ll be investing in.

If you liked this post and are interested in trying out Slack, use this referral link in order for both of us to get 100$ free credit

BackdoorCTF '14

Sat, 05 Apr 2014 00:00:00 +0000

After all our work on software development, testing and security analysis, the time prompts us to showcase what we have learnt. Over the years we have found that the best way to teach people how to build secure systems is by giving them practical experience with problems that are rare to encounter otherwise. Backdoor is our public facing computer security competition. Leveraging Backdoor as a platform for the same is in itself an interesting task. This is the second time SDSLabs has organized such a competition over the internet. We must say that the knowledge we gained while organizing it is immense.

For those who missed out, Backdoor is a jeopardy style capture the flag competition organized by SDSLabs. That is, it involves multiple categories of problems, each of which contains a variety of challenges of different point values. Corresponding to each problem is a hidden flag (basically a string) which must be submitted to us as a proof of having solved the problem. Keeping the interests of both beginners as well as advanced users in mind, we designed a series of interesting challenges to get hands-on practical experience.

An active participation of teams from over 68 countries made Backdoor a huge event. It witnessed an overwhelming participation of over 460 teams, with more than 330 teams submitting atleast one flag. The competition took place over a period of 36 hours during Cognizance 2014, the annual technical fest of IIT Roorkee. We faced a few glitches during the contest (teams being awarded twice the actual points for a flag), but overall the contest went smooth.

While designing the challenges we picked some of the problems that we actually faced while working on our applications whether it be related to SQL Injection, network analysis or cryptography. We tried to frame the challenges around these concepts, simulating real world applications. Solving the challenges required deep understanding of a wide array of topics such as reverse-engineering, network sniffing, protocol analysis, web security, system administration, and cryptanalysis. For instance, one of the challenges was based on the RSA encryption algorithm, and it was really essential to know the working of the algorithm to be able to solve the challenge.

As an aside, BackdoorCTF reflects a lot of what we’ve learned while building applications at SDSLabs. If you’re interested in this kind of a thing, have a look at how to join SDSLabs, drop us an email at contact@sdslabs.co.in and we’ll make sure you aren’t disappointed.

We will be coming up with a bigger, better and more challenging one next year.

Technical Details

For SQL injection based problems we created a new MySQL user with only SELECT privilege (on a separate database) so as to prevent any possible security leak
A custom script was written in Python to generate the two random 110bit (~10^33) prime numbers (p and q) for the RSA encryption challenge. The primality was tested using a modified miller-rabin test.
aircrack-ng was used to design the WPA PSK password cracking challenge.
Some of the challenges were hosted on Heroku to ease the load on our server, as well as to run the challenges in isolation for security reasons.
One of the challenge involved github webhooks to add users to a common github organization and ping the server with commit details.

Nano. Playlists. Recommendations. And more of Muzi.

Thu, 27 Feb 2014 00:00:00 +0000

Muzi has consistently been our most popular application, and we’ve worked on it continously over time to make it even better. Today, we announce a slew of new features that we’ve brought to muzi. We hope these features will help you use Muzi more extensively. As always, we are open to feedback regarding these new features or any bugs you may face.

Nano

For those of you who have created lots of playlists on Muzi, we bring you Nano, a specially crafted light version of Muzi. It was designed from the ground up to be lightweight, minimal, and above all easily usable. It does not boast of all the features that Muzi has, but it more than makes up for it with its beautiful interface. Just hit https://sdslabs.co.in/nano/ (you must be logged in), choose a playlist, and you’re all set. Repeat is enabled by default in Nano, and you can turn on shuffle at will. The share link is available directly in Nano for you to use as well. The controls (including keyboard shortcuts) for Nano are same as that of Muzi

Shared Playlists

Muzi now includes support for shared playlists. You can share any of your playlists by just right-clicking on it and clicking on “Share”. Shared playlists are accessible to all muzi users by the “playlist” button in the top bar.

Music Recommendation

This is one feature we’ve been working on for a long while, and are proudly announcing today. Whenever you’re listening to a song, our recommendation engine will crunch the numbers and provide you with a “Similar” button (in bottom bar). Click on it to get a list of songs similar to the one you are currently playing. Our recommendation engine currently only supports English tracks due to technical reasons, but rest assured, we are working on removing this limitation. Alternatively, you can also right-click on any track in the middle or right pane and choose “Similar” to see similar tracks of any song.

History Playlist

Even though Muzi logs every song you listen to and shows it to you in tickr, there wasn’t any way for a user to get access to that data. Until now, that is. Starting today, if you are logged in, you will see a special “History” playlist in your list of playlists. Click on that to get a playlist of all songs you’ve ever listened to in Muzi. This playlist is sorted chronologically, unlike the rest of the playlists, so that you can find that one elusive song you listened to a while ago.

Animated Background

As a tiny improvement in how we make our awesome background even more engaging, artist backgrounds are now animated. This gives a mesmerizing effect to the viewer, and it looks totally awesome!

Collection Play

We’ve made all track collections in the middle pane playable or addable by adding two new buttons on top of the middle pane. They will be visible whenever you are seeing a track collection. This includes things like “Tickr”, “Top Tracks”, “Similar tracks”, or top tracks by a particular artist.

Random Play

We’ve added a new button in Muzi’s bottom bar called Random. Its a simple feature that helps you discover new music, randomly. Just click on it, and feast as a random song is added to your playlist.

Bug Fixes

This release also fixes some minor bugs such as an issue with the download button, and a certain double play bug. We’ve also removed some old unused code & updated to using a minified version of all javascript in main Muzi. Clicks on the left button now first seeks the song to start, and then plays the previous track on a second click. This behaviour makes muzi more consistent with most other music players.

Technical Details

We are using k-means clustering and cosine similarity as the base for our recommendation engine, which is written in Python.
We handle History playlists similar to the root user in linux. A special playlist id of 0 is used for the history playlist.
Our background animations are powered by css3-transforms and are functional in both Firefox and Chrome.
The minification process is based on grunt, which is an excellent tool for these kind of tasks.
Nano uses howler.js as the library for playing songs. We prefer the HTML5 Audio mode, which allows us to stream audio directly.
Nano is a #nobackend application, which has zero lines of backend code. It uses the existing Muzi backend to perform all of its tasks.

Code.Fun.Do '14

Thu, 13 Feb 2014 00:00:00 +0000

The best and the most creative ideas lie somewhere in the minds of sleep deprived, college students, locked in a small and dark corner of their minds. A Hackathon provides a platform to these people to code unique solutions to general problems and allows them to transform their ideas to websites, mobile applications or in some rare cases, cool robots. Code.fun.do is a series of hackathons organized by Microsoft to foster creativity and promote innovation in the best institutes across the country.

The first ever Code.fun.do hackathon took place at IIT Kharagpur in November 2012. A large number of hackathons have since been conducted in the top institutes all across the country. This was the first time that the hackathon was organized in IIT Roorkee and the response was more than stellar. A total of 228 people participated in the event which was almost 1.5 times the number of participants in other institutions. Building on top of that, a record breaking 45 apps were submitted bringing the submission rate to an amazing 70% compared to only 50% for other institutions.

The event started on 7th February, 2014 with workshops and hands-on sessions for students on how to build software applications for a range of devices such as Windows 8 tablets / PCs, Windows Phones and Kinect, connected and integrated across platforms and network boundaries through Windows Azure. Another session was conducted the next day about design and UX and it’s importance in the rapidly changing application development market.

SDSLabs, being at the forefront of software development in the campus took part in the event and one of our teams (yes, we had multiple teams) won by making Air Maps, an application to navigate google earth using gestures and voice commands. The winning team included Abhishek Das, Ravi Kishore Rachuri, Durgesh Suthar and Divij Bindlish, all members of SDSLabs, studying Electrical Engineering in the campus.

The Air Maps application creates a flying simulation over any city across the globe and the view is controlled using gestures. The application also shows educational places like museums, parks and national monuments on the city. You can pause at any location and see corresponding history and information about it. Relevant tweets are also displayed for that location. It also supports voice commands which allows a user to directly fly to a different city by saying “Fly to New York”. The application also supports street view to create a simulation of standing at a particular point inside a city. The view changes on when the user turns or moves in space.

All the four members of the top two teams won a Nokia Lumia 520 each. Apart from this, the 5 shortlisted teams get to be a part of the Finalists Forum, run by Microsoft where they are mentored by technology experts, both from within and outside Microsoft, to build impactful apps, over a period of approximately three months. These teams get to compete on a national level where the competition is much better and more fierce.

With an amazing response by the students and the professors of IITR, the crew from Microsoft was more than happy. Thus, we can expect them to show up next year as well with a bigger event with more workshops and better prizes. This is just a starting step which in the long run, will help the campus become more technology oriented.

Technical Details

The winning application, AirMaps was a web based application with a server and client. A Kinect device was connected to the server. Data was crunched in C# and the corresponding result was sent to the front end using a custom modified Alchemy C# websocket server. User’s gestures and voice was recognized using robust SDKs provided by Microsoft and appropriate actions were defined for certain gestures and voice commands. This was built on top of the Kinect WPFViewers framework for faster development. The front-end utilized Google’s Earth, Maps, and Street View APIs to render the 3D landscape of a city and viewing street images. Apart from this, Twitter API was also used to display relevant popular tweets about any city or location.

Final Recruitment List For 1st year (2014)

Mon, 13 Jan 2014 00:00:00 +0000

393 people appeared for our written test this year. We interviewed 56 people before selecting the final 12 programmers. It was a really tough job to filter down from the 56 talented applicants to the final 12. Sadly, we have limited vacancies and can only take in 12. But this is not the end of line for others, there’s still a way to join SDSLabs. We’ll continue taking open lectures on variety of topics. Stay connected with us on our Facebook page and group for the updates regarding this.

Programmers

Aditya Prakash (CSE)
Aniket Gupta (CSE)
Aryan Raj (Civil)
Avishek De (EE)
Dhaval Kapil (CSE)
Kanu Priya (EE)
Rishabh Chhabra (ECE)
Rishi Devgan (P&I)
Sopan Khosla (CSE)
Vikas Yadav (CSE)
Vishrut Mishra (EE)
Vertika Bansal (MT)

We will be releasing the final list of designers on 15th January, 2014.

Team SDSLabs

How to Join SDSLabs

Mon, 13 Jan 2014 00:00:00 +0000

Recruitment is one of the most important events that we conduct year-round. We take the whole process very seriously and invest a lot of time and effort in it. Every problem in the recruitment test is a result of hours of brainstorming, every question asked in the interview aims to push the candidate to think from a different perspective, every selection made is absolutely critical and data-driven. We want an amazing environment of passionate and creative people and we don’t shy away from going to any lengths (or sleepless nights) possible to achieve that.

Yet, we understand that the process is not bullet-proof, and we often miss out on worthy candidates and it disappoints us. Recruitment is also conducted as a once-in-a-year event, and is open to first years only, thus increasing our plight.

We pride ourselves as being an open group. We often talk about the tools we use internally, the tech behind our applications, our involvement in open-source and go as far as to conduct open lectures and meetups on every topic we discuss internally. As an extension of this open culture, we want to clarify that contrary to common belief, we are always open to new members irrespective of year and branch. Even if you are an awesome designer in your second year, or a kick-ass developer in your third year, we are always open to new additions to our group. We look for self-motivated doers who have initiated and finished projects on their own.

PROGRAMMERS

Obsessed with coding? Build something new every week? We insist that you join us! It will be nice if you have a GitHub profile with a few projects.

Requirements

Love for coding, in any language
Knowledge of Version Control (git) and/or Linux
Effective communication skills
Few projects to demonstrate the above points

DESIGNERS

Have an eye for clean, well-crafted and simple experiences? We insist that you join us!

Requirements

Clear grasp of typography, layout, colour, motion and behaviour
Comfortable sketching out ideas, and translating them into Photoshop/Illustrator mockups
Effective communication skills
HTML/CSS/JS skills will be bonus
Few projects to demonstrate the above points

SDSLabs is not a company, and members aren’t paid. It’s passion that drives us, not obligation. That’s why it’s an amazing place to learn and get inspired. If you feel it’s the right place for you too, drop us a mail at contact@sdslabs.co.in to say Hello, and we’ll make sure you aren’t disappointed.

On Working at SDSLabs (5)

Fri, 27 Dec 2013 00:00:00 +0000

This January, we at SDSLabs would be going in with our recruitment drive for budding programmers and designers from first year students at IITR. This would be the fourth time after few inspired people came together and founded SDSLabs, that we’ll be doing such a thing. Over the years, the interest in joining the group has seen a steep rise with more than 300 students appearing for our written test last year. Hence, we started a series a blog posts( 1, 2, 3, 4 ) to give an insight to what working at SDSLabs would be all about, this post is one of them.

It’s tough to put down how much and in how many ways I have benefited being a part of the group. I was in the first batch of students who were recruited, so have seen much of it’s progress being a member over time. Back then, this group used to function from a small Hobbies Club committee room. The challenge was that we didn’t have much to show when we used to knock doors of people who matter and ask for support for our much ambitious plans and there was no shortage of people who used to come with similar promises. Inspite of that, we did well, perhaps due to the enthusiasm shown by lab members that closely resembled that of a startup. Our lab soon became functional from its current location. There was growth and when started showing results, we were rewarded generously with more funds. These were utilized to make a fun place to work, so much as some may classify the lab as a luxurious place in IITR’s standards.

Learning

My mentor in initial lab days was Abhay Rana(a.k.a. Nemo). If you have ever interacted him, you’ll know about his technical prowess. While it was exciting working on the same project, it was also a bit scary(no kidding) to ask him an easy question(He did answer them, but a good amount of them used to be lmgtfy links). The best part was that you’ll understand how to go about things and he’ll always give you ample resources to check out and learn.

A year later, I found myself giving lectures to the next batch which joined us. It was no easy task, because I had to be prepared to answer their questions without a second thought and later mentor them for new projects, living up to high standards that Abhay and Harshil had set. The culture has so developed that even today if you participate in any discussion, leave apart the lectures, you’ll learn something new, every time.

Work

Conventionally, you are assigned a project in accordance to where your interests lie. However what makes it different is that we promote an open culture. All discussions/mock-ups/code base is available to everyone in the group. Which practically means one can alter the functionality of any app as he/she wishes. In addition to that, no project is an individual project, every project is shaped by constructive ideas and thoughts by others in the group.

Since the beginning, we have had a hack-ish culture of going about developing applications. There’s freedom, and then there’s rapid development. I was writing code in a Hackathon(codename:Syntax Error) even before I had completed a month as a part of SDSLabs. Although the spaghetti code written by me then never went into production, it in a way inspired an idea for an application which we launched last sem.

One thing, I feel should be mentioned here is that the re-naming of the section from Web Development to Software Development isn’t supposed to be superficial. As the founders of the lab would say, our domain isn’t limited to Web only, we would love if you want to work on any field related to computers that you feel has a lot of scope of innovation and application. Our only condition would be, be amazing.

Competitions

We love to grab the first opportunity we get to participate to participate in events and contests, and luckily, someone from lab end up going well in almost all competitions we have ever participated. Whether it was playing with phonegap for Adobe Express Apps, or cracking different levels in a CTF, or writing a research paper for Deloitte CCTC, we do participate. I believe this keeps the competitive spirit alive in the group where we strive to be the best.

Winning of course, is always special. I was a part of the lab team that went specially to IIT Delhi to participate in Yahoo HackU!, and our app was adjudged the geekiest hack. We did try to convince them to add IITR in the future, and hopefully we’ll see something positive in this regard. I’m also part of the lab team in the finals of Google Cloud Developer Challenge, hopefully we make the best of it.

Over the last year, we have taken a step forward from only participating in competitions to hosting them as well. We conducted a handful last march, during cognizance, one of them was Backdoor, our very own CTF. Cracking problems is one thing but framing problems with varying difficulties is an experience of its own. Recently, we did also organize Syntax Error, read more about our organizing experience here. It was the first major event me and Abhishek had planned after being selected as Google Student Ambassadors of IITR, something we got courtesy of being members of SDSLabs

Group Culture

We spend considerable free time we get in our lab among others from the group. Add to it, our internal group chat, which ensures that we remain connected is what makes our group close knit. This association isn’t limited to the time one spends during their stay at IIT Roorkee. Statistically speaking, the highest number of mails(which is large number itself) on our current year’s mailing list is from an alumni, just speaks of the strong bond.

Joining SDSLabs

If everything you’ve read above excites you and you picture yourself being a part of SDSLabs, come write our test in January. It’s been a dream ride so far, join us in that journey as we continue to grow. All you need to succeed is willingness to learn and a mindful of creative ideas.

Working at SDSLabs (4)

Mon, 16 Dec 2013 00:00:00 +0000

It was a cold January evening when I received the news that I was selected in SDSLabs. Back then, I didn’t know about the effect that phone call would have, but here we are, 11 months later and now, SDSLabs has become a central part of my identity here at IITR. It’s in here, that I met some of the most hard working and talented people in the entire campus and it has been an absolute pleasure working with them.

The Learning Experience

After joining, I was introduced to a lot of new stuff like Git, Node, Python, Backbone.js, Design Patterns, Javascript, MVC, AJAX, jQuery, Angular, CSS, Stylus, LESS… I could go on and on. I started using Linux (after using windows for the past 10 years) and have since fallen in love with it. The point is that lab is a center for learning, you learn something new every time you are here. It provides a place to learn without any kind of restriction. The lab is open 24 hours a day so you can come and go as you please. Everybody is extremely helpful and will consistently point you in the right direction as to what you should learn or try next. You get to learn how websites that you visit daily and how the applications you use on your mobile actually work. Every last detail.

Another great thing about the environment is the geek-speak that flows about. Just listening to all the conversations in the lab will tell you something new about an open source library, why the new application for android is really cool, why a new startup is bound to fail etc. This list is endless as well.

My Work

Muzi

I first tried using Muzi back in my first semester when one of my friends told me about this awesome web portal for the campus that provides an amazing music player. Since then, I have used it almost everyday. It has been a great joy to actually work on the application and see your changes live on the final deployed version that people across the entire campus use everyday. I worked on the new UI for displaying top tracks for each artist which helps a user to find good music a lot quicker. I also did some work on debugging the application, fixing the infamous double play bug, that used to play two songs at the same time. The part that I liked best was that there was absolutely no restriction for me to work on any of the existing projects. All of the source code was available to me and I could make any modification that would make the overall experience better for the user.

API

I worked on the central API that supports all of our applications on the portal. Through this project, I got to learn how a web portal should be structured. This project involved making few changes across all applications and as a result, I got to know what are the best practices that should be followed. I also learned about cross domain resource sharing and preventing attacks that use the same. The main point is that working on any lab project teaches you something that you do not know and helps you to become better. Other lab members, sometime from the same year, will always be there to guide you whenever you are stuck.

Group Activites

SDSLabs started primarily as a group of web developers who, over a period of two years, developed the web portal as we know it today. For the past one year, the group has branched out and has been involved in various activities across the campus ranging from regular meetings of the Linux User Group to organizing Syntax Error, IITR’s first hackathon. As a member of the group, I was able to participate in and help organize such activities over the past year. I participated in the Linux User Group and helped people from all years, even M.Tech students, to install Ubuntu on their laptops. I also took some of the public lectures of the group to introduce eager students to web development and help them get started. And although I was not a part of the organizing committee for Syntax Error, I did have a lot of fun in the all night coding session for the hackathon. Such activities have provided me a learning experience of a different kind which wouldn’t have been possible without the group.

What Else?

Frequent interactions with our alumni. Any member can have a chat with any of our alumni at any time. They constantly respond to all the emails as if they are still part of the group. This goes to show the effect that lab has on all it’s members.
Amazing chapos. This semester, we have had a lot of chapos, almost one chapo every week. That includes Domi chapos with your huge order coming on a rickshaw, to hotel chapos in Prakash or Divine.
Your regular home away from home. A lot of the members choose to spend their nights at SDSLabs, rather than staying at their hostels. Some people even leave for their classes directly from the lab itself!
A 42” TV. The best place to view all your sports matches from the Cricket World Cup to the UEFA Champions league whilst sitting comfortably on a bean bag ( that’s right, bean bags ).

Recruitment

Coming January, SDSLabs is recruiting. If you feel like you belong here, head over to join.sdslabs.co to get started.

Workflow Automation with Grunt

Thu, 14 Nov 2013 00:00:00 +0000

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']);

};

Matchdep

We are using matchdep to load all the grunt-modules in a single line instead of loading them sequentially. That is to say that instead of using:

grunt.loadNpmTasks('grunt-contrib-cssmin');
grunt.loadNpmTasks('grunt-contrib-uglify');
grunt.loadNpmTasks('grunt-contrib-env');
grunt.loadNpmTasks('grunt-contrib-preprocess');
grunt.loadNpmTasks('grunt-contrib-hashres');

We are using the matchdep module to retrieve the dependency list from package.json, filter it for grunt-*, and load all those modules in grunt using:

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

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.

Launching Study Portal and Echo v2

Thu, 24 Oct 2013 00:00:00 +0000

Following on the heels of Erdős and CodeBot, SDSLabs is proud to announce Study Portal, and a revamped version of Echo

Study Portal

For a long time education in IITR has been a uni-directional flow: Professors upload files to LecTut and students download them. But the handouts provided by the professors are not the only reference material needed for a course. A lot of students come across OCW/NPTEL courses which have more informative slides. Students also use files that have been handed down by their senior batch who were given those files by their senior batch and so on. Normally, such sharing involves Dropbox/Google Drive for sharing files and FB/Google groups for posting links etc. This process takes place every single year.

IITs are supposed to be hubs of excellence and not boring repitition. So we decided to fix the situation.

Study Portal allows anyone to upload files to courses that are taught in IITR. These files can be professor’s handouts, practical manuals, tutorial solutions, class notes etc. And these files are going to outlast your tenure in the lands of IITR.

If a course is not listed in the uploads page, you can request its addition. You can upload files to a course that you have requested as well as share the permalink to the course even before it is approved. Once it is approved by Team SDSLabs, it will be listed in the left bar.

While we have uploaded over 600 files to a multitude of courses for launch, the sole purpose of this app is to enable sharing. We hope that with user contribution, the app will soon be the knowledge base of IIT Roorkee.

Check out the application at Study Portal

Echo

There are very few amongst us who do not enjoy the pleasure of sinking into the depths of a book. Searching for books, however, has always been a real pain. We seek to fix this problem, therefore we are launching Echo, a fast and powerful ebook search engine which is designed to help you find the books you want instantaneously.

Echo has been completely revamped, with an all-new look, and significant improvements in search relevance and user experience. New features, like the option to read books in the browser itself without the need for downloading them, have been added too. You can also search for books by any favourite author of yours.

Echo boasts of a collection of over 35,000 novels, academic journals and other books. A whole myriad of options exists for you, with wide-ranging categories like economics, algorithms and fantasy. Spend a weekend reading classics like The Great Gatsby, and another brushing up your programming skills for an upcoming interview.

The collection of books is being updated regularly.

We’d also appreciate contributions from the community. If you’d like to upload your own collection of books, or if you have suggestions for books you think should be available on Echo, please contact us.

We hope you have a great reading experience with Echo!

Check out the application at Echo

Technical details

Echo

Apache Solr is used to maintain our index of books, and perform search queries.
This app uses Limonade PHP framework

Study Portal

This app uses Toro PHP microframework.
The ajax layouts are generated using Handlebars.js

Syntax Error '13

Tue, 22 Oct 2013 00:00:00 +0000

SDSLabs organized IIT Roorkee’s 1st hackathon, Syntax Error, on 19-20 October, 2013. It was a Google Cloud Developer Challenge promotional event and saw great response from the geeks of IITR. Here are a few numbers: 150+ registrations, 101 participants, < 24 hours, 36 hacks, 491 commits, 1029325 lines of code. Participants were spread across all years (Yes, we had teams from 1st year as well) and branches. This was also the 1st time GitHub supported an Indian university in organizing a hackathon.

The event was kicked off with a talk on Google App Engine by Rohit Gupta & Anudeep Sai, Google. The session lasted almost an hour and the Googlers covered various verticals of the Google Cloud Platform and went on to talk about the Google Cloud Developer Challenge. This was followed by a Git classroom hangout by Jordan McCullough, GitHub. It was an extremely thorough session. Jordan started right from the basics and went on to advanced topics. Soon after, Abhishek Das, Google Student Ambassador IITR, introduced the participants to the format of the event and explained the rules and judging criteria.

The hackathon clock started at 9PM on Saturday. Developers were free to code from anywhere they wished and had time till 4PM Sunday to complete their hacks. Once the hackers were done with their code, judging them was no simple task. The esteemed panel consisted of Prof. Balasubramanian Raman, Prof. Durga Toshniwal, Prof. P. Sateesh Kumar from IITR and Pranav Gupta from Tavant Technologies, who were aided with the feedback from techcrew. In the end, out of the 21 hacks demoed, winners of Syntax Error ‘13 were:

1st position - Trip Note by Ed-Edd-Eddy (Pawan Kumar D, Lalit Khattar, Nitesh Kumar)
2nd position - Super-robot-monkey-team-hyperforce-go (Jayant Jain, Rushil Nagda, Nisha Chandramoorthy)
3rd position - Rekishi by Nautilus (Abhay Rana, Shashank Mehta, Ravi Kishore)
Most Innovative Hack - Mad Frets by Unbreakables (Prakhar Singh, Abhinav Tushar, Kushal Saharan)
Best Designed Hack - Crash (Ishaan Bhola, Sonesh Jain)

Congratulations to all the winners and kudos to all hackers for coming up with your brilliant hacks! You can check out all the hacks on GitHub. A big shout out for the organizing team comprising of Ashwini Khare (Google Student Ambassador IITR), Abhishek Das, Durgesh Suthar, Abhishek Kandoi, Ankita Shukla, Shagun Sodhani and all other folks who made this event a feather in the hat for SDSLabs!

We would appreciate it if you take 10 minutes to fill the feedback form. Be brutally honest, it would help us improve in coming years.

See all the photos that we took at our G+ event.

Launching Erdos and CodeBot

Thu, 17 Oct 2013 00:00:00 +0000

We are proud to announce two new applications from SDSLabs: Erdős and CodeBot. Both are immediately available to all users. While Erdős is currently an internal application, CodeBot can be used by anyone across the world.

Erdős

Erdős is an application for Math Geeks to try out new mathematical problems and keep track of who solves what. Named after one of the most prolific mathematician of all times, Paul Erdős, it is a portal for users to test their mettle on various mathematical problems, some of which may require users to write code.

The design of Erdős is clean and card-based, with a focus on user-interaction above everything else. Go give it a try at https://erdos.sdslabs.co.in and let us know what you think.

Lots of exciting features such as gamification (badges), more analytics & visualizations, contests are in the pipeline and will be public soon!

CodeBot

Many of you may have heard of Project Euler, a collection of various mathematical problems ranging in difficulty from easy to extremely hard. CodeBot is a stylized, terminal-style alternative interface to Project Euler. It is an online application, available for everyone at https://codebot.sdslabs.co.in/. You can create a new account and submit solutions to the Project Euler problems. The problems are re-used from Project Euler under a Creative Commons licence.

With the introduction of CodeBot and Erdős, we are now discontinuing CodeMatics, some parts of which were re-used for CodeBot. We also plan to hold regular contests on Erdős, similar to the CodeBlitz contests we have on CodeVillage.

Technical Details

Both Erdős and CodeBot emerged as weekend hacks, which were then polished over to iron the kinks before their public launch.
CodeBot uses node.js for the backend, and redis as the storage mechanism, while being hosted on Heroku.
Programming and Algorithms Group (PAG), IITR has agreed to help us out in keeping Erdős updated with new problems.
Erdős uses Chart.js to generate all the awesome visualizations.

GNU Conference

Mon, 07 Oct 2013 00:00:00 +0000

The best way to spend time is to do the things that you love. And last weekend of September was spent doing exactly that. I had the opportunity to attend the GNU 30th anniversary conference which was being organised at Massachusetts Institute of Technology. Well, when you know that Richard Stallman would be giving a talk at the conference, can you control your excitement? It was a pleasure to meet all the people about whom you had just read in news articles. It is overwhelming to meet the people you had been admiring ever since you had stepped into FOSS.

The Conference

The conference was nothing less than amazing.

It started with the welcome address from John Sullivan who explained why Free and Open Source Software is of ever increased importance. Most people have very little idea of how much personal data they have put up online and how many of the places which they have trusted with their data are actually providing backdoor to the government or other agencies. A lot of action with our data is taken without our consent. We are constantly being forced to use some particular software and are being denied the freedom to install other software on our own machines (you know what I am talking about). The various projects of GNU and other organisations were introduced.

Well, no open source conference is complete without a hackathon. The aim of the hackathon was to introduce their projects to each other and the new-comers. I must admit that I was one of the few new-comers. The hackathon had the following projects:

coreboot
GNU Octave
GNU FM
GNU social
GNOME
Gnash
GNU mediagoblin
Tor
Tahoe-LAFS
Commotion
Guix

The hackathon started off quite good with a few hours being spent at helping people setup the project on their laptops. The conference also had a cryptoparty where they were helping people get started with GnuPG, an open and complete implementation of OpenPGP standard as defined by RFC4880. It was fun to get to know more about cryptography and why people are actually using it. The Tor people were going around the various projects trying to figure out any security vulnerabilities these projects may have. It turned out that almost all the projects had some issues which wouldn’t be visible until someone devoted a lot of time figuring it out. Well, that is what crackers would do. So, the conference just made FOSS much more safe.

I got started with GNU FM development during the hackathon. Turns out that it would be a nice alternative to last.fm in some time.

Let us come to what Richard Stallman talked about during his address at GNU 30. It was a pleasure to listen to his experience about bringing up GNU which revolutionised the way FOSS was perceived. Richard was quite instrumental in demonstrating to the big companies that most open source software are much more economical for them instead of what we all prefer to call, bloated proprietary software difficult to customise according to our own needs. We owe a lot of our progress in science and technology to FOSS. It is very important for us to realise why software which restricts our freedom is detrimental to our progress, because progress and freedom are very closely related to each other. Every single thing that is taken without our content can be used against us. We should not be tracked without our consent. But this is happening every single moment. Richard emphasized on the need to raise more money for FOSS because like everyone in the world people working in FOSS also need money to improve their products. Unfortunately, not many people are willing to donate to FOSS which is hampering the development. When you have people with a lot of money competing with you, you also need a bit of money apart from your good work.

It is difficult to say which part of the conference was the best. I had a chat with several core developers of the various projects participating in the conference. Their approachability is absolutely brilliant. Several of them expressed interest in helping the Linux User Group in fulfilling its aim - promotion of FOSS on campus. The most overwhelming of all chats was the one with Nick Mathewson, one of the three original developers of Tor. It was extremely humbling to meet someone who knows so much about the web, its shortcomings, advantages, vulnerabilty. These people could have used their knowledge to exploit the common users without our knowledge and could have earned huge sums of money from the exploitation but well, they are acting as our protectors.

How I got there?

Well, travel to a foreign soil is usually expensive business. Free Software Foundation had awarded me a travel scholarship, taking care of most of my travel cost. And the credit for this goes to Marina, the coordinator of GNOME’s Outreach Program for Women. She had invited the women participants of GSoC interns in the organizations that were also running Outreach Program for Women in parallel with GSoC.

To be honest, there is no greater joy than being invited to such a great conference, being awarded a travel scholarship for the same and then meeting exceptional people. I would like to thank SDSLabs for leading me to this point.

LUG Meet 16th August 2013

Tue, 03 Sep 2013 00:00:00 +0000

When we started IITR Linux Group a few years back there were about 5 people in it. Yes you read that right. The situation was pretty sad. All systems in Institute Computer Center run Windows, even most of the iMac’s in IITR’s library run Windows.

The numbers didn’t really faze us though. We kept at it and now we are very happy to report a turnout of over 100 people for the first LUG meetup of this semester, conducted on 16th August. While the iMacs and other systems are still running Windows, we are sure we’ll get there eventually and make our campus Linux friendly soon.

While we have pretty grand plans for LUG and the whole developer environment in IITR in general, we are aware that we’ll have to take things slowly. Hence, the first meetup, which was targeted towards freshers, was mostly an introduction to the world of Linux. Abhay Rana of SDSLabs, popularly known as Capt. Nemo, gave a talk on who uses linux and why ‘You’ should use linux. The talk was well received, or so we hope!

The idea for a Linux User Group was given by Shobhit Singh, founder of SDSLabs. The idea was to promote the use of open source softwares and open source development in the campus. The meeting was about introducing IITR developers to the Linux universe. Much of the technological progress in the last decade has been brought about by Linux in various sectors; despite its small market share in the desktop market. (It rules in other markets, including Super Computers, Servers, and Mobile Devices)

Since the agenda was introduction to Linux, the meet wouldn’t really have lived up to that if we had not introduced the saintly, the almighty, the great, TERMINAL! A team from IMG (Pramod & Pawan) went through the basic commands and tried to give an idea of what all can be done via the terminal (basically everything). Then Abhishek Das of SDSLabs showed off his command line-fu. He ‘cut’ and ‘grep’ped through a huge file containing all JEE ranks demonstrating the speed and ease of command line.

The talk and demonstration were followed by a small question answer session. SDSLabs members fielded a variety of “I can do this on windows too” questions. We are sure we managed to convince most of the people to atleast give Linux try.

If you have any doubts about using Linux, please join us on our Google Group, where we will

be more than happy to help you out with your issues. Also, feedback is always welcome. Drop us a mail on contact@sdslabs.co.in or just post it in the LUG google group.

What’s next? Linux Installation Party! Join us on 4th September at Hobbies club, between 5 PM to 7 PM.

–
Team SDSLabs

Muzi updates

Sat, 31 Aug 2013 00:00:00 +0000

Back when we launched Muzi on 11/11/11, we had no idea that it would get this popular. Ok, we did have some idea! Since then, we have been working on it continuously and have even rewritten it a few times to give you a better experience. We have added several new features to Muzi that have just been deployed to the live version:

Downloads

We are pretty sure you like listening to your favorite tracks on the go. Muzi now allows you to download the current playing track via the newly-minted Download button.

Music is social, or say the plethora of startups in the music business. Sharing was a highly requested feature and many people wanted to share the current track they are listening to. Now it’s possible. Click on the “share” button while playing any track and it will take you to the share-box where you can copy the Share links from. The “track” link in particular will start playing that track automatically. Genius, right? So make sure to share those links high and wide via whatever medium you want.

New artist look (Top Tracks)

With daily listens averaging around 2,000 per day, we have a lot of data for every artist. Being data nerds ourselves, we think it is so much better if you get to see the top tracks by an artist rather that their entire discography. Now, browsing to an artist via the left pane takes you to a brand new list of “Top Tracks” by that artist, showing the Play Count and Album to which those tracks belong. Now stop wasting your time and listen to good music!

Auto-saving Playlists

The save-playlist flow has not been that good, but now we’ve gone ahead and completely re-done it to bring you auto-saving playlists. Each time you add or remove a track from a playlist, we’ll make sure to save it to the backend so all your precious songs can sleep safe and sound when you are not around.

Router

The Sherlock wannabes might have noticed that Muzi now changes the URL in the address bar based on its interaction with you. We’ve shifted the JS observer pattern from event-triggers to URL routing. So now, most browsing events in Muzi take place using the onhashchange event. How does this help you? Well, you can now share link to ticker directly or maybe bookmark a link like https://sdslabs.co.in/muzi/#/band/7111/30-seconds-to-mars to quickly return to a particular band.

Technical Details

The downloads button is powered using the HTML5 Download Attribute which allows us to rename the file being downloaded.
We are using JavaScript side routing for creating the shareable links and giving you a better browsing experience. The routing library we are using is called Director
We run a Beta Version of muzi up at https://beta.sdslabs.co.in/muzi/ where you can checkout the latest (possibly buggy) version with cool new features. Features appear on the beta version 1-2 weeks before we launch it on the production version.

–
Team SDSLabs

PS: Carefully curated an amazing playlist? We may have something for you soon. ;)

GSoC 2012 Experience

Fri, 12 Apr 2013 00:00:00 +0000

Roughly the same time last year I was caught in a dilemma of what to make of my summer. Given my low interest in departmental courses, I was not so convinced about going for an industrial internship with just one year knowledge of relevant courses. Research domain was beyond me to say the very least and whole idea of mailing exhaustively professors with little or no idea of research topics, just for the sake of a free holiday did not amuse me much.

In short, I was looking for something more substantial and widely recognized. I ended up being a part of Google Summer of Code 2012 program, this post is a brief introduction about the program for the uninitiated who take programming as a passion and are willing to step it up for real world applications

Google Summer of Code Introduction as on their official page :

Google Summer of Code(often abbreviated as GSoC) is a global program that offers post-secondary student developers ages 18 and older stipends to write code for various open source software projects.

Anyone who is above eighteen and enrolled in an university (as of May, 27th for this year) whatever his/her major may be, is eligible for applying
Google only sponsors the open source development done during the three months. Which means you would not be working for Google but you would be working for an Open source organization where your contribution being funded by Google

Open Source development is what one does if accepted in this program. Many of your favorite softwares you might be using are open sourced ,ie, majority of their code base is public and community driven. Anyone who wishes to contribute can request a feature or fix a bug. It’s quite amazing to know how these organizations work given they hardly interact physically, credit must be given to how well they plan their roadmap, maintain their code repositories, and have a dedicated group of programmers who keep their projects running

All open source projects have well structured documentation, sophisticated bug-tracker and a majority of them use Internet relay chat(irc). A quick word about irc : IRC is an instant chat service for groups, full of people who would be more than happy to help you out. As IRC ports are blocked on the IITR network, you may use a web client as an alternative.Here’s a nice overview of IRC by Mozilla - https://quality.mozilla.org/docs/misc/getting-started-with-irc/

While Google Open Source Office has broken down the evaluation in two stages, being accepted as a student developer is the tough part. Formally, acceptance requires interested students to write a proposal on one of various ideas which the participating organization floats for the year, although one is not restricted and can suggest an idea of their own as long as it is relevant.

This proposal is a brief overview of what you intend to do to achieve your targets, your strategy for solving the issue, and a brief background about you your skill-set and past contributions in relevant projects. Although a good proposal might appear to be the obvious judging ground, most organizations count on student’s past participation which may be in form of bug fixes or general participation in public discussions, hence it’s always advised to start early as to blend in a big organization takes time. Some organizations also prefer to have an interview, although the major weight-age is always given to the former factors.

Coming back, what makes SoC different from what you may think of an internship is the fact the entire thing is done online. It doesn’t matter from where you work on as long as you can contribute on a regular basis. People from different parts of the globe with diverse backgrounds come together the fact that the chances are you will never physically meet your fellow developers or your mentor are quite high.

This year 177 mentoring organizations have been accepted into the program, of which 40 organizations have been accepted for the first time. My mentor organization for last year was Statistics Online Computational Resource(SOCR) at UCLA. My project was to create a portable application that demonstrates the concepts of statistical resampling, randomization and probabilistic simulation. More details about my project can be found at https://wiki.stat.ucla.edu/socr/index.php/SOCR_Resampling_HTML5_Project . My project was more about application of fundamental statistical concepts. This is another speciality about this program that one gets an opportunity to work on wide range of topics from genetic engineering to kernel design.

Owing to the popularity of the Summer of Code program several other programs on similar lines have been initiated. Outreach Program for Women in FOSS is the most recent and intended to promote girl participation in Open Source Porgrams.

Some resources have been mentioned in the end which I believe will be useful if you are interested to apply this year. If accepted, you are in for summer full of learning, collaborating with the best, a starry bullet in your resume and a fat paycheck. Are you game?

Resources:
https://www.google-melange.com/gsoc/homepage/google/gsoc2013 https://groups.google.com/group/google-summer-of-code-discuss https://flossmanuals.net/GSoCStudentGuide/
https://blog.vmsplice.net/2011/03/advice-for-students-applying-to-google.html https://developers.google.com/open-source/soc/

Competitions Galore

Thu, 04 Apr 2013 00:00:00 +0000

We were involved in organizing quite a few online competitions in March during Srishti and Cognizance. All of them occurred in the same week. This resulted in a very hectic, but fun experience. Here’s a brief overview of the contests.

backdoorCTF - A Jeopardy Style CTF Event

SDSLabs organised the first ever Capture the Flag (CTF) event by IIT Roorkee from March 9th to 11th as an event in Cognizance, the technical festival of IIT Roorkee. The idea was proposed by Vaibhav Gautam from the Saharanpur Campus. CTF are cyber security events which focus on a plethora of problems found in the real world. The event saw participation from contestants all over the world, with some really experienced hackers participating in the contest.

On our side, we had a lot of fun putting the event together. It was great to host and we learnt as much as the teams that participated. With mid terms ending on 4th, we had only 4 days to put the whole event together. We divided ourselves into groups based on categories of questions and got hacking. Three sleepless nights later, we had ourselves something to speak of.

Not knowing what kind of participation to expect, the questions that we set varied across difficulty levels.The challenges for this CTF spanned from simple trivia questions to questions that required detailed knowledge of modern computer security techniques. We also held interactive discussion with the participants on the irc channel # backdoorctf.

There were some really nerve-wracking moments in the final 6 hours of the contest. The competition saw multiple leadeboard changes, with it ending in a nail biting finale where Team dcua (World Rank 15 on CTFTime) snatched the lead from team v3l0cityz3r0 in the final moments. Team h34dump (World Rank 46) brought up the rear, taking the third place. We are proud to add that Team v3l0cityz3r0 included a student of IIT Roorkee among others.

In conclusion, we would like to congratulate all winners and those who participated, helping us make this event a grand success! We will be back with a bigger and better backdoorCTF next year, we promise.

Codematics

Codematics is a Project Euler-style mathematical puzzle solving competition, held annually as an event in Srishti, the Hobbies Club exhibition. It was organized by the Programming and Algorithm group, under SDSLabs.

The competition consisted of multiple levels of difficulty, with the challenges of a certain level only being accessible after the preceding levels had been completed. There were a wide variety of problems, and solving them required high mathematical and computational skills. Incidentally, the final problem did full justice to its name (beta, tumse na ho payega), and remained unsolved till the end of the competition.

The competition attracted widespread participation, with students from both outside and within the campus participating. Archit Sachdeva (MCA 2nd year,IIT Delhi) was the winner, whereas Saurabh Paliwal (CS 3rd year) was the campus winner.

Insomnia

Insomnia is IIT Roorkee’s annual algorithmic problem solving event, organized by the Programming and Algorithms group, under SDSLabs. Insomnia involves all kinds of algorithmic challenges, ranging from string manipulation to complex dynamic programming. It is the biggest online event in Cognizance with participation from all over the world.

This year Insomnia was held on SDSLabs’ very own app, CodeVillage, for the first time. It gave us a chance to step up CodeVillage from the intranet to the internet. Our homegrown code-checker, called ‘CodeRunner’ was used as the grader.

The competition saw great participation from all over the world. 8 out of the first 10 ranked teams were from outside India. Anton Lunyov, from Ukraine and flashmt from Singapore took ranks 1 and 2. ‘:P‘ (yes, that’s their team name), a team comprising of Dipit Grover and Tarun Goyal won the campus prize.

Organising competitions at an International scale has been an honor for us. We hope to continue bringing forward events of these level, if not more, in the future!

Team SDSLabs

The final recruitment list for 1st year (2013)

Sun, 13 Jan 2013 00:00:00 +0000

Congratulations to everyone who got in. We were overwhelmed by the amount of talent and aptitude these people brought on board. If we did not select you, it was because we had limited vacancies, not because we didn’t like you. Each of the rest was as equally likely and capable be to be selected. And each time we took someone’s name off the list, we were stricken with guilt.

Programmers

Abhinav Tushar (12115005)
Abhishek Kandoi (12114003)
Ankita Shukla (12114012)
Deepali Jain (12115034)
Divij Bindlish (12115037)
Gautam Arakalgud (12115042)
Mohite Kishor (12114041)
Kshitij Bathla (12114036)
Prakhar Singh (12213014)
Satyam Vijay (12114061)
Shubham Gupta (12114062)
Shubham Roy (12119053)

Designers

Kushal Saharan (12116029)
Rishabh Yadav (12115090)
Viplov Kumar (12114073)

Team SDSLabs

Recruitment Shortlist (First Year)

Sat, 12 Jan 2013 00:00:00 +0000

The following students have been shortlisted for interviews. The time slots are given below as well. Please come 15 minutes before your allotted time. The venue for all interviews is SDSLabs, Hobbies Club.

Programming Interviews

Day 1 (12th Jan, Saturday)

Aakash Agarwal (CE): 12:00 - 12:20
Aarushi Bagga (GPT): 12:20 - 12:40
Abhijeet Gaur (CSE): 12:40 - 1:00
Abhijeet Kumar (BT): 1:00 - 1:20
Abhinav Kumar (GT): 1:20 - 1:40
Abhinav Tushar (EE): 1:40 - 2:00
Abhiraj Sharma (CE): 2:00 - 2:20
Abhishek (CSE): 2:20 - 2:40
Abhishek Kandoi (CSE): 2:40 - 3:00
Aman Kumar (CHE): 3:00 - 3:20
Aman Kumar Kedia (CSE): 3:20 - 3:40
Ankita Shukla (CSE): 3:40 - 4:00
Ankur Garg (CSE): 4:00 - 4:20
Anshuman Singh (CSE): 4:20 - 4:40
Anubhav Bindlish (CSE): 4:40 - 5:00
Archit Garg (CSE): 5:00 - 5:20
Ashish Dwivedi (ECE): 5:20 - 5:40
Astuti Sharma (CSE): 5:40 - 6:00
Chavi Choudhary (MMT): 6:00 - 6:20
Deepali Jain (EE): 6:20 - 6:40
Dipesh Gujnani (CHE): 6:40 - 7:00
Divij Bindlish (EE): 7:00 - 7:20
Gautam Anakalgud (EE): 7:20 - 7:40
Kishor Mohite (CSE): 7:40 - 8:00
Krishna Khandelwal (CE): 8:00 - 8:20
Kshitij Bathla (CSE): 8:20 - 8:40
Kushal Sharan (ECE): 8:40 - 9:00
M Karthick (MMT): 9:00 - 9:20
Namit Ohri (ECW): 9:20 - 9:40
Pankaj Gudlani (CSE): 9:40 - 10:00
Piyush Kumar Gupta (ME): 10:00 - 10:20
Prakhar Gupta (CSE): 10:20 - 10:40
Prakhar Singh (ECW): 10:40 - 11:00
Prakhar Varshney (MMT): 11:00 - 11:20
Shivanshu Madan (CHE): 11:20 - 11:40

Day 2 (13th Jan, Sunday)

Ishu Goyal (CSE): 10:20 - 10:40
Mahim Agarwal (EE): 10:40 - 11:00
Meghana Agarwal (CSE): 11:00 - 11:20
Mehak Gupta (MMT): 11:20 - 11:40
Mikul K Patel (ECE): 11:40 - 12:00
Palak Gupta (BT): 12:00 - 12:20
Priyanshu Sheth (CSE): 12:20 - 12:40
Purvi Gupta (CY): 12:40 - 1:00
Rashika Ramola (BT): 1:00 - 1:20
Rohan Kalia (MMT): 1:20 - 1:40
Rohan Sarkar (EE): 1:40 - 2:00
Satyam Vijay (CSE): 2:00 - 2:20
Shubham Gupta (CSE): 2:20 - 2:40
Shubham Roy (PI): 2:40 - 3:00
Shubham Singh (CSE): 3:00 - 3:20
Srijan Jindal (BT): 3:20 - 3:40
Srishti Gupta (CHE): 3:40 - 4:00
Sumit Joshi (CE): 4:00 - 4:20
Suyash Singh (MMT): 4:20 - 4:40
Varid Gupta (CE): 4:40 - 5:00
Varun Syal (CSE): 5:00 - 5:20
Vikas (CE): 5:20 - 5:40

How does SDSLabs work

Mon, 31 Dec 2012 00:00:00 +0000

SDSLabs is roughly run as two cells (programming/design) that collaborate with each other on everything. This blog post will take a look at the various tools, technologies, and applications that we use on a daily basis. It is our hope that some other groups in the campus might be interested in this. We’re open to inquiry about any of this, and you can reach us anytime at contact@sdslabs.co.in.

Updates: Since this article was published, we’ve switched from Partychat to Slack. We’ve also launched a separate Feedback and Chat portal that helps us communicate with our users better.

Mailing List : Our mailing list, like most other groups runs on Google Groups. This is our primary means of communication. We send out a heavy amount of email each day and email-overload is an actual problem for people who just join.

Facebook Group : Like everyone else, we too have our own facebook private group. Unlike most other groups, we hardly use it. We find the facebook notification system terrible, and the comments system broken for serious discussion. Hence we limit discussion on facebook to bakar, and taking jibes at each other. We also keep a document with our internal lingo here.

Partychat : We have a partychat account that we use as our personal chatroom . We would have used Campfire, but its cost raises some barriers. Partychat, on the other hand creates a chatroom within gtalk chat for free. Partychat helps us remain in continous communication with everyone, while moving non-serious stuff away from email. We all hang around at partychat, and most of our bakar sessions have shifted from facebook to chat. Partychat is a special kind of group-chat, which allows everyone to see logs, and it works without having to invite everyone again & again (like gmail group chat)

Hubot : Our partychat server includes hubot, our own personal robot. He announces cricket scores, keeps track of who is working on what, announces if anyone makes a commit, and helps us out with lots of stuff. We prank around lots of things with bot. We use it to answer commonly asked questions, like who is in lab, and someone’s mobile number, or to urgently call out someone. It is integrated with most of our other internal services, and we plan to use it for even more stuff.

Let’s you act all innocent when you need it
Pictures are worth more than words
Keeps track of scores for us and also lets us correct those fingers of slips
Gives us details of members, if you ask politely (yoda = Abhishek Das)
For those times when we are too lazy to open google.com
And for those times when we are too lazy to open “Compose mail”
And sometimes the bot chooses to troll us

Dropbox : Our designers primarily share all their work through dropbox. It is all continously synced with dropbox, and available on Redmine for offline access. All our designs, past and present have a place in dropbox. We also use it to share documents, and work on some side projects till we can shift to github/redmine for code hosting. A new Facebook feature for dropbox sharing within facebook groups was actually a real good helper for us as we use both products together.

Redmine : Redmine is a project management system running on rails. We use redmine extensively for code hosting(integrated with gitolite), issue tracking, and wikis. (add screenshots and more). Our git server is running gitolite and all our code is version controlled in git. We shifted to git from ftp based systems about a year ago, and it has been working out awesome for us.

WorkFlowy : We use a custom account at workflowy.com with a shared list to easily manage lots of things. It is an easy-going tool which we find useful for quick edits, lookups and at times when creating a google-doc or an issue in redmine would be an overkill. We find that the list system of workflowy is an excellent place to chalk out ideas and hold brainstorming sessions in writing easily. Workflowy keeps track of most of our administration related stuff, with tenders, management contacts etc stored there. A daily log of our changes on workflowy is forwarded to our google-group so everyone is kept in the loop about any changes made there.

Presence : Presence is our automated presence detection system. A very common question we found on chat was asking “who all is in lab?”. It became so common to ask this, that we turned to using technology to solve our problem. Presence answers this question for us. As mentioned earlier, our work culture is focussed on using personal laptops instead of workstations. Presence detects the presence of any device that you might own, and logs it down. We turn to presence anytime we want to check up on who all is present in lab. It uses lan, wifi, and bluetooth scans to sniff around people in general. It even takes a photo that refreshes every one minute to let us see what state the lab is in. We are looking to open-source presence in the near future in hopes it will be useful to others as well.

Llama : Llama is our in-house deployment/management system that helps us run services and deploy them easily. We have very loose access rules in place. Every lab member has access to the source code for every project, which leads to higher transparency in whatever we do. Llama allows anyone to deploy anything whenever they want. It takes out the pain of uploading/moving stuff manually to the server and restarting processes and so on. With just a single command to llama, it will automate the deployment process for us.

StatusBoard : We try our best to keep as good of an uptime as possible, but there are lots of issues that we just cannot handle. As such, we’re working on status-board, our own status server, that helps us keep track of all our services and their health at a glance. It keeps a continous track of which services are up/down and for how long. You can check the public version at https://status.sdslabs.co.in.

Play : We have our music player internally for lab, which plays our songs on the lab speakers. We have open sourced it and it is available on github. Play takes care of the problem we had in playing music over the speakers in lab. Anyone can send play a request, which may even be a youtube video link and play will play it faithfully. As for the people who get distracted by music during work, we have our own “Silent Room”, which anyone in lab can use, any time (We encourage using it for studies as well).

We also run our own internal server for cdnjs, use piwik for statistics, and continue working on more amazing stuff. We do not limit ourselves to any technologies, and have work in php, js, node.js, ruby, scala, cpp and some other technologies as well. Our servers run on Ubuntu 10.04 LTS and we’re upgrading them to 12.04 already.

We will be recruiting for designers and programmers from first year in January. Any interested second yearites can send a mail to contact@sdslabs.co.in mentioning prior work done.

Working at SDSLabs (3)

Thu, 27 Dec 2012 00:00:00 +0000

Introduction

For the past two years, I have been involved in a student group in our campus called SDSLabs. It has been the most fun two years of my life. I have acted as programmer, developer, manager, monkey-coder, event-manager and all other roles one might expect in a startup. However, I have never really blogged about any of this. Someone pointed it out recently to me, the truth is I have been meaning to write this since a very long time, but its kind of hard to put down in words. I’ll try my best. This post is highly specific to iit roorkee (you have been warned).

Chronology Of Events / Timeline

Back in my first year, after joining something called SDS as a proficiency in the campus, I was learning PHP. With no-one to guide me, I had only attended a single talk by Shobhit Singh where he talked about dynamic websites. I was instantaneously hooked. I did something called lion, a twitter clone and it won 3rd prize in Srishti. It had follow, unfollow, messages, tweets, and groups (one feature which set it apart from twitter).

The code was a mess of php and inline html, and I have never looked upon it since. I did a couple more projects by myself , learning the in and outs of php (I was still to hear about ruby/python). At the end of my first year, I did a project management system under Kumar Shashank who taught me about MVC and the need of architecture in a software application.

At the very end of the project, a group called SDSLabs was formed. Along with a few people Shobhit sir had found, we founded SDSLabs. Everyone in the group was passionate about building things. And somehow, magically, I was in it. And there began the most beautiful chapter of my life..

Coding & Learning

After completing the PMS (Project Management System), I moved on to work on Filepanda, and then the entire framework application for SDSLabs. All our applications are powered by a single API, which I wrote. Meanwhile, Harshil was working on DC++, and other awesome things. I met pranav sir, and was introduced to the thousand-quirks-of-css. It shifted to mint, and then to ubuntu. I learned the ins-and-out of managing a linux system. Back then SDSLabs was limited to the small committee room in Hobbies Club (with Shobhit Sir working tirelessly on funding for a better lab).

And I met Ishan Sir. If you are reading this, thank you for teaching me how to learn. I had tons of night-outs with him discussing things I barely remember now. I became a creator. I executed on tons of ideas. Most never saw the second day in their lives, but I still have them with me, as memento of the past and what was to be. Ishan Sir was a gold-mine for learning. Everything I could ever ask, and he’d hand over a resource. Some of my most productive learning days were spent with him.

Recruitments

After a single semester of work, we held our first recruitments. I wrote my first blog post for the lab at the time noting down my amazing reaction to the awesome people that had joined the lab.

It is difficult to distil into words the awesome learning experience I had with all these people. Going to chapos, thinking about how we could expand. What else awesome stuff we could do? One night hackathons, where we coded awesome stuff.

And I started to work on muzi, which was to be my application. It stands at 811 commits today, with over 200 issues in our project management system. I went into the development knowing PHP and bits of AJAX, and came out a JQuery fanboy. Muzi has been my primary music player for almost an year now. It feels awesome to listen to music on a music player you coded. The initial version was based on Zune’s design on Windows. We kept on improving it till it was exactly what we wanted. Today, people have listened to almost 1 lac songs on Muzi, and it feels awesome to have been behind something that is so widely used (within the campus).

Launch

The next semester involved our actual launch (11-11-11) of all our applications. We had all converted into semi-breathing coding machines cum zombies by that time though. Sleepless and exhausted, we did prevail, and launched a few hours early. The Launch was appreciably recieved in the campus, although I had to leave for the Deloitte CCTC Contest the very same day(which we won!).

I ended up doing a rewrite of Codematics (codename CodeBot) in node for the launch. It has a geeky, command line interface which was inspired by goosh and xkcd’s unix interface. Along with that, Muzi was launched to huge appreciation as well.

Recruitments Again

This was the semester where our group actually expanded. Our count is almost 42 now, and nothing could make me more glad than actually being with all these people.

I donned lots of hats teaching, guiding, coding, and managing people. Linux became one of my top skills, and I learnt a lot. We shifted to Redmine for management, and I ended up doing a lot of server-administration related stuff (gitolite,redmine,vhosts ,apache,varnish etc).

It has almost been a year since our last recruitment. We have been working of tons of things; some of which will be launched soon. I took lectures on far apart topics from “Usability Designing” to “Software Development 101” I mostly worked on internal features, improving our API, and something called Presence. We also participated in two hackathons, and we won both of them.

Where, now?

Our group is still nascent, and although I have not mentioned every project that the group (or even I) have done for fear of making this post too long. That itself speaks volumes about what we’ve done in a short span of two years. Our tagline reads “iDream. iCode. iInnovate”. I wish for the group to continue on that path. Develop things that make life easier; for everyone around the world.

People

Throughout this journey, there have been lots of people, without whom this blog post would never have been written. You all know who you are. Keep being awesome.

Skills

I used to call myself a programmer, but now I’m in a more management-esque role in SDSLabs. Its my share of the work to manage projects, and track progress. That does not mean that I’ve given up coding, and I still do code a lot for our internal projects. I have also become somewhat of a UX enthusiast, taking care of most ux work done in lab. I have also found myself becoming an avid learner, and have Ishan Sir to thank for that.

Anecdotes & Stories

This post already reads more like a things-i-did-at-sdslabs, which is something I was hoping to avoid, instead of why-i-love-sdslabs, which is what i wanted. So I’m gonna stick a few moments and events that stand out to me…

We have a board with three defining people on it: Steve Jobs, Dennis Ritchie, and Linus Torvalds.
We have had mind-blowing pizza chapos. So many pizzas that they were brought in 2 rickshaws from dominos. Yup.
I am known as the bot in lab. Mostly because of my highly rational unemotional responses, and other things. There is another person, who is trying to get that title, though.
I am famously known for turning down “writing a letter that could have fetched us lots of funding” for coding instead. (In my defense, there were other people who could have handled it better than me, and we didn’t need it badly at the time)
Almost every group in the campus describes their group as a second home. But in our case it is partially true. We spend almost all our free time in lab. I spent close to 500 hours in the lab in this semester alone. Where does this all this time go? Talking, discussions, development, teaching, lectures among other things.
SDSLabs feels more of a startup than an actual student group to me (and Shashank as well). We have to fight for our funding, manage people, and develop products.
I have done way too much copy-editing to be called “just a developer” anymore. I have spent hundreds of hours fighting Pinta and its numerous bugs.

It has been a great experience working with all these people. I can just hope that the group keeps moving to better innovation, and grander ideas in the future. We are recruiting from first year in upcoming January. If SDSLabs feels like a place you’d enjoy, just come over and take our test. It changed my life, maybe it will change yours too.

– Abhay Rana, 4th Year, P&I

Working at SDSLabs (2)

Tue, 11 Dec 2012 00:00:00 +0000

The first post on this topic can be read here

If you have ever spoken to me in real life or follow me on twitter or are in my friend list in facebook or instagram or ….. you get the point, then you must have seen my posts related to a certain something known as SDSLabs. It’s been 11 months since I joined this student group in IITR and it has more or less become a part of my identity. Before I write anything more I should probably explain what is SDSLabs.

A Student Group

IITR has a very vibrant culture of student groups with there being a group for nearly everything, right from Robotics, Electronics to Philately and even Gardening! While not all of them are active and often give the feeling of having been started by few enthusiasts who have long since left and now no one is ready to carry it on, there are a few groups who are actively changing the scene in their field. SDSLabs is one of them. SDS (Software Development Section) is an official hobby section and anyone can be a member of this. SDSLabs is the core team that manages SDS apart from working on various projects in the software field (moving into hardware too now). I came to know about SDS through their open for all lecture series that they conducted in my first year. Then in November, 2011 they launched their intranet portal and that’s when I knew that I had to join this group.

Recruitment Process

SDSLabs’ recruitment process for first years started off in the second week of January. A two and half hours of written test and a nearly three hours of interview later I was in. I was one of the 13, out of nearly 200 people who had applied, to be chosen in the programmer category (Design being the other). The process was long and ardous but the end result has been wonderful. The last 11 months in SDSLabs have been amazing.

What’s it like inside of SDSLabs

The first thing that you realise is the level of service and infrastructure available inside the lab. A fingerprint scanner based entry, 42 inch TV, an enterprise level server, bean bags, AC, radiator are just a few among many other things available. Funds have never been a problem for us, courtesy IITR administration, with another server in the line and along with a Nexus 7 for android development. It’s more like a startup inside college with people even sleeping inside lab! Anyways, looking beyond things that you can buy with a Mastercard, the best part of the lab is the people in there. A conversation with a senior leaves you with wealth of knowledge each time unless, of course, it is a bakkar conversation. SDSLabs was the first place where I could talk about Hacker News without getting clueless looks. It was also the first place where when I complained about unnecessary clicks on a website people actually understood because it is in their system to create user friendly apps.

Technology

After joining lab I was introduced to git(version control system), redmine(project management system), php, js, ajax, sass, bash, jquery, node.js to name a few. Few people are also using ruby and scala. I have since fallen in love with git and wherever I can use vcs, I do. As a result, I have also fallen head over heels in love with Github, so much so that I queued up to avail their free student plan the moment I came to know about it (although nearly all my projects are in redmine and gitolite combo). I have also moved to using Ubuntu full time since. I have seen 11.10 and 12.04 come and go. I have become fearless when it comes to partition tables and experiments. And all this happened over the last 11 months along with the load of regular college and other extra-curricular activities. I have also met some absolutely brilliant people like Abhay Rana, Harshil Mathur, Shobhit Singh. They are so brilliant that I could probably end up writing separate blog posts for each one of them and even then I doubt I would be able to do justice to their brilliance! All in all, it’s safe to say that lab has become my home away from home with countless hours spent sitting on a bean bag with a laptop and arguing about the merits and demerits of various frameworks.

The work

The best part of SDSLabs is that you are free to come up with a project idea and work on it. The project does not have to be a web app as is the common misconception, it can be related to mobile development, linux development or even a windows 8 app. If you are interested in hardware+software solutions, then even that is possible. If you don’t have an idea you are most welcome to work on other projects. Any member can see the code of any project. Any member can contribute code to any project (something like github’s pull request). We also work on few official projects that are taken up by the lab. These include making the websites of IIT Roorkee’s technical festival and website for some international conference that is going to take to place in IITR. If official projects don’t interest you then you are under no obligation to be a part of them. Since this is not a job, there’s no check in time or check out time. The lab is opened whenever needed and remains open well into the night (sometimes people leave directly next day morning for breakfast!).

The Fun

Dine Out’s sponsored by seniors is part of the culture now. Alumnis of our group also give us huge Dominos treats now and then and when I say huge I mean huge (imagine three delivery boys coming from dominos just for your order!). We also have a few gaming sessions. ProTip: Stay away from abhshkdz. The group also goes for camping once every year. The 42’ TV is put to good use, trust us!

Recruitments plug

It’s December and come January, SDSLabs will start recruiting again. If you are a fresher in IITR and are interested in joining SDSLabs then the next few lines are for you.

We don’t care which branch you are in. Out of the three people I named above only one was in CS. In my year there are only 2 in CS, out of the 13.
We don’t care about how much programming you know right now as long as you can convince us that you can do it and you have the aptitude for it. I did not know programming when I applied.
If you think that joining SDS is going to get you a high paying job in some software company 4 years later then please stay away. No I’m not saying SDS does not give an advantage (it does) but we don’t want people who only and only care about package.
If you are a CS undergrad and are applying just because it is something in your field, please stay away! We want self motivated people.
If you are a bond, don’t apply, just COME TO LAB!

– Shashank Mehta
IInd Year, ECE
https://shashankmehta.in
This post has been cross posted from the author’s blog

Response to security concerns raised by GeekGazette

Mon, 12 Nov 2012 00:00:00 +0000

Some of you may have read the latest GeekGazette issue. It includes an article on “Campus Surveillance”, which errs on the side of being a FUD article. If you haven’t already, you can read the article online. The article says, “Managing personal data gives immense power to the authorities and members of IMG and SDSLabs.” Surely this warrants a response.

CCTV Cameras

As far as I am aware, most of the CCTV cameras installed on the campus are networked. None of these include any form of face recognition. Sure, being tracked by these infringes your privacy, but they are also useful in the case of tracking any wrong-doers as well. Pointing out that our institute has cctv cameras, and leaping to the conclusion that we are being watched everywhere, NSA style, is just plain rubbish.

Personal Data

The only personal data available to SDSLabs are the email address and phone numbers, which are provided by the users themselves upon registration itself. The institute provides us with no data at all. This means that all data we have is either provided by the user’s consent itself or publically available (We use course data from 192.168.121.2/studentlist to help users during their registration). We don’t have anybody’s weight/height/bloodgroup/photographs/passport/driving licence/grades/passwords as mentioned in the article. We assure you that we have no interest in selling the limited amount of personal data we have on file (phone/email) and it is only accessible by limited members of our team. Furthermore, our services are protected by HTTPS security to mitigate sniffing and other nefarious activities

DC++

As of now, DC++ is being run in an open mode, which means it does not need any form of registration. We personally log very little data (mostly chat) on the DC network. In truth, the actual downloads themselves are P2P (Peer To Peer) and are not trackable. To track a user download, while theoritically possible, would a) require huge resources, and b) caught immediately as a fake peer.

Web Monitoring

As of now, the browsing activites in campus are not monitored by ISC. They can do it in future but don’t do it as of now. Even if they did, it wont be accessble to student/student groups in any case and will be done just for sake of security. Currently if someone hacks a government website from inside the institute, the institute has no reliable way to identify the hacker.

In conclusion, this article mis-represents the truth, tries to build fear in the mind of its readers, and builds upon little facts to visualize an environment which is completely out-of-reality. However, when the article says “Rest assured, everything can be hacked”, we tend to agree with them. As a result, we are now coming up with our “Security Disclosure Policy”, which we hope will help us in the long run. If you like working in security, or learn about ethical hacking, feel free to try to hack us. As long as you follow our disclosure policy, that is. And, if anyone else has similar doubts regarding the data we have and how we secure it, you are free to approach us via mail or personally and we will surely sort them out.

– Abhay Rana

Muzi Widget, Facebook Chat & Team page

Tue, 06 Nov 2012 00:00:00 +0000

Today we are rolling out a couple of shiny new updates:

If you go over to our homepage, you’d see a small searchbox that appears at the bottom of the Muzi tile. Not just search, it is a full-fledged Muzi add-on which works without actually opening Muzi in a separate window, right from the homepage. Really easy to use, just search for a song/album and start listening, or hit that tiny arrow on the left to see a list of the top tracks and albums. You can even play songs from the list of top tracks in the right pane. Just click on a song, and it plays without a fuss in the widget. Pretty neat eh? You bet it is! Go on, give it a shot!

Facebook Integration in Chat

Facebook chat is now accessible from our native chat application. Listen to your favourite music alongside chatting with your cool dude on Facebook at the same place or enjoy the night accessing Facebook chat exclusively even after 2AM!

Team

And we finally have our team page ready. The design is simple and every member’s social links are available when you hover. Don’t worry if someone is right at the bottom, refreshing the page might get him on top!

Technical Notes

All the animations are done using jQuery and CSS3 Transforms, and SoundManager is used to play audio, just like Muzi. It is a JavaScript API that uses HTML5 audio and falls back to Flash wherever needed, hence delivering reliable cross-platform audio.

Facebook Integration in Chat

We have used Websockets and Node.JS for chat. Websockets is a considerably new method which we have chosen over PHP long polling to make the process quick, uninterrupting and care-free.

Filepanda Favorites & Lyrics in Muzi

Thu, 11 Oct 2012 00:00:00 +0000

We’re launching two new features today that we hope you’d like to use more and more:

Lyrics in Muzi : This was a highly requested feature that took us some time to get to. We’re glad we got it done, and we’re glad at how it turned out. As of now, Muzi features lyrics for almost all english songs. We’ve pre-fetched the lyrics for all songs, which means that you don’t need to wait for them, either. If lyrics for a song are available, you’d see a small “Lyrics” button in the control bar, which you can then use to browse the lyrics. We’re thankful for all the feedback and requests for this feature, and hope we’ve implemented this well enough.
Favorites in Filepanda: We’ve implemented favorites in filepanda so that you can mark softwares as your favorites, and browse them later. This would help you to prepare your own list of softwares that you use, and check it easily, for instance.

You can favorite a software by going to its download page, and marking it as favorite. All favorites are listed on your “Favorites” page. The page is visible only to logged in users, so you will have to login before you can use this feature. This is a minor, but important feature in our plans for Filepanda. Stay tuned for more updates, because they are coming, and will bring many more such things.

As always, you can reach us for feedback via Facebook, email, or our Feedback page. We continuously monitor all new feedback, and reply to it as soon as possible.

Ubuntu Meetup at IIT Roorkee

Sat, 06 Oct 2012 00:00:00 +0000

This blog post has been coming for some time now. The First ever Ubuntu Meetup was conducted on campus in collaboration with IMG. This was held to bring out the local linux user community to get together and talk about their lives in working with Open-Source . The main purpose behind the meet was to get a Ubuntu/Linux group started in the campus. We are happy to announce that, the meetup was a success, and was attended by more than 70 people, including the members of SDSLabs & IMG.

The meetup started with a brief presentation which outlined the various aspects of the ubuntu operating system and also listed the linux user group as open to all. A couple of seniors who’ve been roughing it out for a couple of years now shared the reasons that made them switch over to linux based Operating Systems. This included Vivek Prakash, Abhay Rana, and Giridaran Manivannan who talked of their own experiences in using Linux as their primary OS for the past few years.

The audience was mostly comprised of people who have already had their first bytes of Ubuntu. Almost everyone had some experience in using Ubuntu. In hindsight, this made the introductory aspects of linux that were discussed obsolete , but goes to show the linux user community is bigger than we initially imagined. This is definitely a sign that the campus is ready for advanced topics to be discussed in later meetings.

A Google Group has been setup for linux users in the campus, and it has already started showing some signs of life. Please join the google group if you’re interested in learning more about Ubuntu/Linux. We’re proud to have been a part of such a beginning.

Thanks to everyone who attended the meetup . Here’s to many more such meetups in the future.

Cheers!

Pics

More pics were uploaded on the IMG Facebook Page

Remember Me and more updates

Mon, 01 Oct 2012 00:00:00 +0000

We’ve finally gotten around to launching one of the most asked for features, ‘Remember Me’. This means that the you do not have to login every time you want to use our portal, and we’d keep you logged in for a long amount of time.

So now you can quickly solve a puzzle on Codematics, browse through your problem solution status on Codevillage, enjoy your Muzi playlists as well as Last.fm scrobbling all the time without having to login again and again.

Speaking of Muzi, we’ve finally launched it on the Chrome Web Store, so if you are using Google Chrome, you should check it out! We plan to improve it with a lot more features soon.

We’ve also updated Muzi to be able to handle the computer’s default Media Keys. This means that you can use your keyboard’s inbuild Play/Pause/Previous/Next buttons to control muzi. However, it might not work on all browsers (we tested it on Chrome on Windows), since binding media keys is not available across all browsers at the moment. We are still launching the feature, in hopes that our users will find it helpful.

Team SDSLabs wins Yahoo! HackU

Wed, 26 Sep 2012 00:00:00 +0000

Hackathons are a rarity in India. Surprising really, seeing that most guys in college claim to be the most productive in the night. Here at SDSLabs we confess to be night owls. Some of our best apps exist thanks to all-nighters. So naturally, when we came to know that Yahoo! India was organising a hackathon by the name of HackU in IIT Delhi, we wanted something similar in our beloved IITR. Multiple emails were exchanged with the Yahoo! employees but we could not convince them to hold one here in Roorkee. What a bummer.

As I said in the opening line, hackathons are a rarity in India. So what if we could not convince them to come to Roorkee, we’ll travel to Delhi! And that we did. Team SDSLabs included:

Abhay Rana who is better known to the public as Captain. Nemo and as Bot to members of the lab. He specialises in anything that can be accessed/altered/twisted/bent/hacked through the codez.
Ashwini Khare who found this trip to be the perfect opportunity to play Temple Run undisturbed.
Abhishek Das, popularly known as Yoda, famous for teaching Obi-Wan to use the source.
Shashank Mehta who is typing this thing. I found this trip as the perfect opportunity to catch up on my sleep lost due to those all-nighters. Ironic?

The event was scheduled from 16th to 19th August. The actual hackathon started at 11pm, 18th August, after series of lectures on Yahoo Developer Network offerings (YQL, YUI, BOSS, CAP, DAPPER). BOSS was particularly very impressive. Yahoo has some really good stuff in their developer network. Brainstorming sessions were also held before the actual event where Yahoo employees helped in formulation of ideas. But we did not need this. We had our brainstorming sessions during the journey to Delhi with Temple Run music setting the mood. (Thanks Ashwini!)

We had decided to work on Google Hangout-esque app that allowed people to video chat. Why, you ask? Because we could come up with nothing better and all this world really needs is another video chat application, if you ask me. But then, the world really does need our video chat because we did not copy Google Hangout, we made something better. When you try to video chat with someone, you and your friend both connect to a server. This server receives messages from both of you and pushes them accordingly. But what if both of you are on the same network? The server could be in the opposite part of the world. It makes no sense for your message to travel around the world before being delivered. We used a new protocol called webRTC which creates peer to peer connections. Difference? You connect to the server only to get the address of your friend. After that all your messages are directly sent to your friend. How does this help you ask? On the same network this is equivalent to video chatting over lan, which will be way faster than using an intermediatory server.

Through the 3 day event, we became oblivious to our surroundings as we sat down to code. It was a fun-filled event, where we did manage to finish our application and polish it beyond our expectations. We added text chat and collaborative doc editing that supports markdown and these two features work on iPad, iPhone and android devices too. Each team was alloted 2 minutes to demo their hack on the last day. We demoed our app on 3 laptops and an iPad! One of the laptops was placed on the judges table and they got to play with the hack themselves. This was a masterstroke.

We were awarded winner in the geekiest hack category and the top-scoring team for the event. We probably also managed to convince Yahoo! to visit IITR next year. Let’s see how it pans out.

This is just a glimpse of what being at SDSLabs entails. If this feels like something you’d be interested in doing, send us a mail at contact@sdslabs.co.in clearly mentioning your existing work or if you’re in first year, make sure you sit for the selection test in January.

Our application can still be used at hackview.sdslabs.co.in and the source code is up on github for your browsing pleasure.

Technical Notes

Our application was a web based offering, running on a new protocol called webRTC, and was made using node.js and express. We also used stuff like JQuery and Twitter Bootstrap to fasten our development.

Muzi is now even faster & better

Fri, 21 Sep 2012 00:00:00 +0000

We’ve upgraded muzi to support slow connection networks, added last.fm integration, and a auto-updating Hindi collection. We also have a live tickr that shows you songs as people are listening to them.

Slow Connection Mode

Ever since we launched muzi, our aim was to make it The Music Player of the campus. Due to the way our network infrastructure is designed at IIT Roorkee, we have an effective split of the visitors muzi recieves. One comes from the faster lan bhawans (Radhakrishnan, Rajeev, Kasturba) while most of the rest comes from the wifi bhawans.

Most of the songs in muzi are encoded at 320kbps, with the Hindi average being 128-160kbps. Since the songs are buffered while being played, bandwidth requirements are scant, but can often be a cause for slow-down in wifi equipped bhawans. To combat this issue, we have introduced a slow connection mode in muzi.

The slow connection mode allows people with low bandwidth to enjoy muzi. Behind the scenes, muzi works hard to encode the tracks on-the-fly to a lower bitrate to make the file-size smaller, effectively reducing bandwidth.

If you are listening to muzi from a wifi-hostel, please enable the slow connection mode in settings.

After you enable the slow connection mode, all songs you listen to are encoded on-the-fly to a lower bitrate with slight reduction in quality.

Last.FM Integration

Last.FM is a popular music service that helps people keep track of what you’ve listened to. Its “scrobbler service” is cross-platform and available as a plugin for various music players and services. We’ve now integrated muzi with last.fm, so if you are listening to music on muzi, it will automatically be added to your last.fm library.

To, get started, you’d need to create an account on last.fm. After you get an account, you can go to muzi, and click on the “Connect to last.fm” option:

A click on that link would take you to last.fm authentication screen, where you’d be asked to give permissions to muzi to access your account.

Once you grant the permissions, you will be redirected to muzi, where a notification should notify you about your successfull last.fm integration.

After this, every song you listen on muzi will be scrobbled back to last.fm and added to your library.

Live Tickr

We’ve always wanted to take muzi to the next level for music listeners and make it more social. Today, we’re taking the first step in this direction by launching our live tickr. The live-tickr is a continous stream of music that people are listening to right now. Just click on the tickr button in the top bar, and see who’s listening to what on muzi.

Bug Fixes & New Songs

This update also brings lots of bug fixes, and an improved drag-drop experience. We’ve also updated hindi songs, so you can listen to all the latest hits from 2012 as well. We’ve also worked hard on keeping the songs permanently updated, so new Hindi Releases are automatically added to muzi within a day. If you feel muzi to be lacking in its music collection, please let us know of your choice using the request feature in muzi.

We are continously improving our services, and are always open to feedback. As always, you can reach us for feedback via Facebook, email, or our Feedback page.

Technical Notes

Slow Connection Mode

For the technically inclined, we are converting the music on-the-fly using lame using the following configuration:

--vbr-new (Use the new vbr algorithm, which is much faster)
-V 7 (convert at quality 7 on a scale of 0-9)
-f (fast mode conversion)
-B 96 (maximum bit-rate of 96 kbps)

So as to avoid audio degradation, only files larger than 3MB are converted, since they are (usually) already at a low enough bit-rate. M4A files are converted using faad to wav, which is processed by lame. Additionally, the audio file is stripped of all id3 tags causing a large size reduction in some cases (such as where the file includes 2 large cover arts).

We are aware that this on-the-fly conversion causes audio quality to go down substantially, but this is a trade-off we are leaving to the users. You can enable/disable this feature any time you want, and muzi will remember you choice for the next time.

Live Tickr

We are using a new HTML5 API called Event Source/Server-Sent Events. This allows us to recieve events from the server on a large number of devices without resorting to other alternatives like long-polling or websockets. This also means that users of some browsers(for instance Opera < 12) will be left out of this feature. We gracefully degrade in that case and remove the tickr button if that happens.

Solving the Internet Issue at IITR

Sun, 26 Aug 2012 00:00:00 +0000

The issue with the ultra slow speeds of IITR internet, more specifically in the wifi bhawans, is something troubling the IITR ocupants since a lot of years. Over the years a lot of solutions have been proposed to this issue from router replacement to server replacement but so far there has been no change in the speed.

Current Situation:

The network structure of IITR is somewhat like the one shown below (only for wifi hostels).

As seen from the above figure, there are two primary bottlenecks in the network that reduce the speed.

Bhawan Server/gateway: Its an old P4 computer in most bhawans. It is the main culprit since all the traffic load passes through this. But is replacing it the only solution?
Access Points: Secondary Bottleneck. Replacement is the only solution in this case but the effect will be limited unless changes are also made at the higher level.

Solution to the Gateway Problem:

The first solution that everyone thinks of is replacing the bhawan server with a costly, bigger server but the simplest and better solution is often overlooked. There is a lot easier, better and long term solution with Rs 0/- cost for this problem. And the solution is not adding in anything but in removing what is already present. Surprised? Lets see.. The server performs three functions:

NATing: This seperates the bhawan network from the institute central network.
DHCP: Gives Ip address to all the users.
Security and Authentication: Secures the network so that unauthorized person may not enter it.

The solution:

Instead of NAT, create a VLAN for the bhawan in the central switch which essentially performs the first function of gateway. (a similar thing already exists for the LAN bhawans).
Remove the server from the middle of the connection between bhawan and central switch.
Attach the same server/switch to the internal bhawan network anywhere.
Continue perform DHCP and authentication using the same server.

In short, remove the server from the connection between user & internet.

New Network:

Why this Network is better?

The first bottleneck i.e. the bhawan server is now out of main network between clients and internet.
It is only connected to once just for getting IP (DHCP), and for authentication. that takes approx. 2 minutes and only once for a new connection.
Since both of these are meager tasks, no processing is required and hence no need to purchase or replace the existing box.
It is actually better than buying a new box, because a new server no matter how fast it is will be slower than a simple wire between two points so removing it from network will increase the speed by maximum value.
Also, any server is bound to get old with time, and will need replacement causing further cost to institute while this is a permanent solution.
Interbhawan services like DC++ will start working which will sharply reduce the load on the institute internet and further increase the network speed.

The Second Bottleneck:

The Wifi routers/access points are the second bottleneck. The problem here is that they are very old (2005 model) and this era of technology things go old with 2-3 years, this is 8 years old. The solution to it is only replacement with latest access points which can be carried out one bhawan at a time.

Further Improvement:

Further a lot more additional things are required, which will improve the network even further (again no additional costs required) like VLANing and proper configuration of internal switches to reduce the broadcasting of packets, collisions and improve the speed and security. This is also required in the LAN bhawans to improve the speed further.

Conclusion:

The solution of the primary bottleneck which just requires some effort from the side of administration will solve a lot of problems. It is the easiest, cheapest and quickest solution. After that the purchase of new access points can be carried out which may take time because of the official procedures but till that the students will be able to get at least some improvement. I have personally submitted this method to the director (with help from SAC), as well as to the ISC and had a long heated discusssion with the network manager at ISC on the benefits of this structure. Though they were convinced that they should adopt this, I still don’t get the reason for its non adoption. Well, I had done my part in preparing and submitting the solution, I can even help the ISC people in implementng this and anyways implementation would take a day at max because no new equipment is needed.

–Harshil Mathur

Muzi Updates

Wed, 25 Apr 2012 00:00:00 +0000

Muzi has been updated with lots more features. This has been hard work for the team, and we hope you enjoy them.

Radio

Now you can listen to online radio from within Muzi. We have tried to make the experience as seamless and easy as possible. As of now the following radio streams are available:

Radio Mirchi
Retro Mirchi (Purani Jeans)
Radio City
Bombay Beats
Capital FM
Virgin Radio

Along with this, we have also integrated Campus Beats Radio as well.

To start using the radio feature, just click on the Radio button in the topbar, choose a radio, and click on whatever you want to listen to.

More Updates

We have also updated our Hindi songs collection, and added album arts for all Hindi albums. A major color scheme change means that muzi is now easier to use than ever, with background album arts for various artists. Try clicking on “Avril Lavigne” to see it for yourself.

As always, you can reach us for feedback via Facebook, email, or our Feedback page.

FilePanda new version launched

Fri, 13 Apr 2012 00:00:00 +0000

We are proud to announce the launch of the new version of Filepanda. This version brings a cleaner, modern layout to the forefront.

For this version, the most important goals were a better, faster UI, and an easier experience for the user. To this end, we’ve updated our homepage to show the top downloaded softwares for each category.

This version also rewrote a major version of the backend, fixing a few bugs in the process. If you had faced problems downloading certain softwares earlier, they have now been fixed.

The online version of filepanda has also been updated with the current version as well. You can browse the online version here.

As always, we welcome all feedback. Please send us your thoughts at our feedback page, by email, or via Facebook. We shall be delighted to hear from you.

Pics from the new update

Filepanda and Live Streaming

Sat, 18 Feb 2012 00:00:00 +0000

We’ve been busy here at SDSLabs. The last week was marked by two new launches. Filepanda was launched on the internet on the 6th and live streaming on the sdslabs portal was launched on the 13th.

Filepanda

Filepanda is now on the internet. It can be accessed at https://filepanda.sdslabs.co. from any computer outside the campus.
Filepanda is the SDSLabs self updating software repository. ‘Self Updating’ because it’s just that.
Filepanda automatically updates itself. Every piece of software on filepanda is the always the latest version. So next time you find yourself in need of an anti virus or a new media player, a quick search through the repository should give you the goods.

Live Streaming

Tired of going to the TV room or UG Club to watch Sachin bat? Wanna grab the united game right from your room? Well we hear you. SDSLabs launches live streaming using which you can grab any live action from the comfort(well somewhat :P) of your hostel room.

Live streaming can be accessed at https://sdslabs.co.in/live/.

The final recruitment list for 1st year (2012)

Mon, 09 Jan 2012 00:00:00 +0000

Congratulations to everyone who got in. After checking the examination papers of 196 candidates, we were overwhelmed by the amount of talent and aptitude these people brought on board. If we did not select you, it was because we had limited vacancies, not because we didn’t like you. Each of the rest was as equally likely and capable be to be selected. And each time we took someone’s name off the list, we were stricken with guilt.

Developers

Abhishek Das
Shagun Sodhani
Shashank Mehta
Durgesh Sudhar
Himanshu Chawla
Richa Jain
Jayant Jain
Siva S.V
Nitish Sharma
Aarti Dwivedi
Mannat Gupta
Rushil Nagda
Ravi Kishore

Designers

Apoorva Mudgal
Chetty Arun
Saket Sarupria
Nupur
Jitin Singla

The introductory meeting will be held at 9th January 2012 at SDSLabs, Hobbies Club.

Team SDSLabs

Recruitment Shortlist (First Year)

Sun, 08 Jan 2012 00:00:00 +0000

The following students have been shortlisted for selections. The interview slots are given below as well. Please come 15 minutes before your allotted time. The venue for all interviews is SDSLabs, Hobbies Club.

Programming Interviews

Abhishek Das - 9:00am
Adurv Surya Kiran - 9:20am
Aman Mittal - 9:40am
Archit Agarwal - 10:00am
Aarti Kumari Dwivedi - 10:20am
Areeb Usmani - 10:40am
Arpit Jain - 11:00am
Avijit Singh Yadav - 11:20am
Avinash Modi - 11:40am
Shashank Mehta - 12:00am
Shagun Sodhani - 12:20pm
Saurabh Suman - 12:40pm
Akshita Sukhlecha - 14:00pm
Chamandeep Singh - 14:20pm
Durgesh Suthar - 14:40pm
Shruti Lal - 15:00pm
Sameer G Shanoy- 15:20pm
Neha agrawal - 15:40pm
Himanshu Chawla - 16:00pm
Jayant Jain - 16:20pm
Richa Jain - 16:40pm
G Praneeth Reddy - 17:00pm
Vishu Goyal - 17:20pm
Suyash - 17:40pm
Sukhbarshan Singh Sani - 18:00pm
Siva Samhitvaddiparth - 18:20pm
Mannat Gupta - 19:00pm
Manush Gupta - 19:20pm
Mohammad Aqib - 19:40pm
Nitish Sharma - 20:00pm
Rohit Jangid - 20:20pm
Ravi Kishore R - 20:40pm
Rushil Nagda - 21:00pm
Sahil Singhal - 21:20pm
Harshdeep singh - 21:40pm
Kamaldeep Singh Arora - 22:00pm
Akash Agarwal - 22:20pm
Kaushtabh Kulkarni - 22:40pm

Design Interviews

Divya Khandelwal - 12:00am
Apoorva Mudgal - 12:30am
Itisha Jain - 13:00am
Saket Sarupria - 14:00pm
Rahul Meena - 14:30pm
Ishaan Bains - 15:00pm
Jitin Singla - 15:30pm
Chetty Arun - 16:00pm
Priyajeet Dev - 16:30pm
Mohit Tanwar - 17:00pm
Atinder Pal Singh - 17:30pm
Ujjwal Vasisht - 18:00pm

In case you think you deserve to be one of us and your name is missing from the above list, please send us a mail at contact@sdslabs.co.in answering “Why you’d like to join SDSLabs?”

Team SDSLabs

On working at SDSLabs(1)

Wed, 04 Jan 2012 00:00:00 +0000

The SDSLabs homepage carries a nice “Goes Recruiting” ribbon near the top bar this week. Clicking the overlaid image shows you the detailed recruitment poster. As the first years ready themselves for the recruitment process, I thought it fit to write about the work, culture and work-culture of our lab, located on the right wing (no pun intended) of the hobbies club.

From the small, clumsy room that once was near the Cogni office, Hobbies Club, SDSLabs, with Shobhit Sir to guide, has come a long way, in an admirably short span of one year.

The Work

The best part, doubtless, is that you get to work on anything that captures your fancy. As newbies, we were first introduced to each of the projects that were then underway and that you now can see, on the homepage and asked to choose. Nothing is appreciated better than having your own project ideas, in which case everyone in the team devotes their time for them(the ideas) to achieve fruition. We believe in an open, “no-rules” environment to enhance productivity.

yes, everything you say is swell, but what is it that you do?

What work and how

Broadly, Web development. More broadly, mobile and web development and Design. In the process, however, the work fans out to different areas. The lab is never the pressure pan with little leeway for errors, nor does it stagnate and radiate leisure. On one day, everyone is coding away, while simultaneously enjoying “yerushalayim shel zahav” on surround speakers and on another we are all playing “crux”, the IEEE online treasure hunt.

Another ordinary day ends in a few people pulling off an all-nighter with some issues filed up in redmine (PMS), as the agenda. Development Marathons with coffee-breaks, tons of geek-speak and the normal banter, several lectures and the perpetual availability of workplace mentors make you learn a lot of things that is hard to come by,when you are on your own.

Echo

Echo, the brainchild of Ishan Sir(CS 2006-10 Batch) started developing first in java, over one year ago. People at SDSLabs could be the subject of a separate post, and without digressing much here, I would say that Ishan Sir is one among those I will always be honoured to have known. The first version of Echo that you see, on the home page has a backend written in scala and uses some of the very latest from the world of web technologies. And even as of now,many ideas are still in the process of gestation.

Echo is actually a recursive acronym in which Creed(C) is the recommendation engine, H(Hash) and O(onyx) are the names of the hashed storage on a dfs and the indexer and searcher, respectively. I joined team Echo soon after recruitment in the second semester and have seen its development since. Almost all of it, including refactoring, was done by Ishan Sir and Neeraj, and most of it in November last year and I, for one, managed to learn a thing or two.

There is an awful lot to learn when you delve deep into anything and the web/computers/technology is no exception. In the jump from java to scala, in the addition of sinatra as the middleware, in using lucene and reading up clustering algorithms, I was taught, some of it in vain, about efficient programming practices, a little about scalable architecture, natural language processing and of course, other things like using github and hordes of other open source software.

Finally, Why

The point is that, every visit to the lab, teaches you one thing or the other. With the likes of Abhay around, there is a continuous passing-on of a range of diverse information, in a way you would like and appreciate. Just eavesdropping on nerdy exchanges will teach you how to set a proxy on the terminal or how to run parallels on a mac, what to expect from windows 8, which is the best editor and for what, what Linus Torvalds does on github and such like.

Are you game?

If you are in your first year and do value this kind of a learning experience, do participate in the recruitment process, because at SDSLabs, you get to:

have fun coding and ask geeks for help, when stuck.
receive tech updates for free!
learn how stuff works ,in a free environment
think on the white board,watch webinars on a big plasma screen and look at a copy of Jonathan Livingston Seagull for inspiration.
play with cruft like old monitors and motherboards, to make useful things like skynet and much more!

To get started, visit https://sdslabs.co.in/recruit/.

Nisha C ,Second Year,Mech

Muzi Development Blog Post

Mon, 02 Jan 2012 00:00:00 +0000

Muzi is an online music player application developed by Team SDSLabs. This blog post will go into the development of the application.

The first ray of light that the application’s development saw was in January 2011, with a few mails being exchanged in our Google Group regarding the lack of an online music player that could offer the same experience as a Desktop Player. A few core features were identified, including :

Ability to browse albums via any categorization (including Albums, Artists, Genre and Year)
Easy searching of songs.
Well tagged songs.
Use of Album Artists instead of Track Artists
Easy and usable interface, which reminds people of a desktop player.

Whenever in doubt, we looked at three different desktop players - Zune, Windows Media Player, and iTunes.

A few mockups from early February :

The design was iterated several times, leading to the design that you see today.

Several other iterations were discussed, such as this one, which was ultimately ruled out as being too complicated :

A current pic of the application is given below as reference.

The application was written using JQuery for easier Javascript syntax and several plugins, SoundManager 2 for music playing capabilities. We also worked on using HTML5 Canvas for visualizations, but ultimately dropped it for the current version, as it was slowing down muzi. We had, from the very beginning tried to keep muzi as fast as possible. In fact, we were adamant about not adding JQuery until later in the project, when it became a necessity.

For future developers, here are a few tips :

Don’t think that your project will be done in a weekend. Any project of good size and scale takes time to mature, and takes up much more time than you can possibly estimate correctly.
JQuery makes Javascript easy. And better.
Don’t be afraid of using Plugins and 3rd party code. They are far more tested than anything you can cook up in a shorter amount of time.
Even though we did not use it (we were not aware at that time), I would highly recommend using Backbone.js, Underscore
Having a simpler experience with fewer features is better than having a feature bloat with confused users.
Software Development is an iterative process. Treat it as such. Work at one feature at a time, test it and then move to the next one. For beginners, I would recommend reading Head First Software Development

A few fun facts about Muzi :

Major keyboard controls from VLC work in Muzi as well. Here’s a list of the most common ones :

a. Ctrl+Up/Down to increase/descrease Volume. Works even without the control key.

b. Left/Right changes the current track.

c. Shift+Left/Right skips the current playing track

d. m mutes the current track, while space pauses/plays it

e. The home key takes you to the default view of muzi

f. Ctrl+s takes your input to the search box immediately
Two Developers worked on this application primarily with everyone else open to contributions. Input was regularly recieved from the entire Team and went into deciding major portions of the app.
Muzi uses latest web technologies, including HTML5 and CSS3, leading to its inability to work in older browsers. For that, we apologize to users with a smile and ask them to get a better browser.

For any queries regarding muzi, or SDSLabs in general, you can always contact us at contact@sdslabs.co.in

Happy New Year

Sun, 01 Jan 2012 00:00:00 +0000

Team SDSLabs wishes all our readers a very Happy New Year. May this year bring lots of happiness and joy in your lives.

Team SDSLabs

To Launch and Beyond

Fri, 11 Nov 2011 00:00:00 +0000

Hello everyone! Change is the only constant in this world. To quote Issac Asimov, “The only constant is change, continuing change, inevitable change, that is the dominant factor in society today” and staying true to the words, now, IIT Roorkee is about to witness a defining and epic change with the introduction of the SDSLabs portal. To those who are not yet familiar with SDSLabs, we are a small group under Hobbies Club with an aim to improve the technical level of institute multifold. It has been more than a year since the formation of SDSLabs and the journey since then has been nothing short of incredible. Last year in October we started our journey with tiny but steady steps. And since then, we have organized countless lectures and workshops which have constantly witnessed anywhere between 25 to 50 students each and every time, a clear sign of the zeal of learning in the students of IIT-R.

Last November, we launched Filepanda sans much fanfare. In March this year, we displayed India’s World Cup final matches live on the very big screen and rejoiced with all of you in the victory of Indian cricket team. And now, this time, we bring to you our next and biggest offering to date, a plethora of intranet applications. We have worked hard and worked fast, incessantly striving to produce awesome results, as you are going to witness now.

The main aim of this launch is to ease the campus life of students in IIT Roorkee and make their campus experience even more cherishing while establishing our intranet presence in the campus. We aim to increase the interaction between students exponentially as it is our fundamental belief that intranet is the best medium for student interaction and this launch is a monumental step in that direction.

We are also focusing on applications which will help in improving programming capabilities of students at IIT Roorkee thereby directly helping them in improving their coding skills and hence, helping them in placement at innumerable software companies visiting the campus. Also, no service can be complete in nature without a serious fun element in it and friends, be assured, for we are not going to disappoint you. For we bring to you some excellent applications that serve this very purpose. Moreover, if searching for ebooks proved to be a pain in the past, then we have got just the right application for you! On top of all, we are also launching the first completely free group SMS service on campus to improve the communication between members of a particular group or society, so this time you don’t miss anything happening around you in the campus.

Throughout the course of the development, we have always remained faithful to our motto “iDream, iCode, iInnovate”, which has not only served as a guide through the entire process but has been present at the very foundation of all our working practices, our working ideals, our working beliefs.

And finally the moment has arrived,so gear up, and fasten and your seatbelts, because it’s time to Blast OFF!

Team SDSLabs

Recruitment Results for 2nd Year [Programmers]

Mon, 19 Sep 2011 00:00:00 +0000

The following students have been selected after the interviews :

Priyanshi Goyal (ECE)
Soumitr Pandey (CSE)
Rohan Arora (GT) For the list of selected designers, please see our previous post.

With more than 50 applications coming in from second year alone, it was very difficult for us to shortlist people. The shortlisting criteria was on what people had written down in their application form. Few people who were shortlisted were interviewed later as well; but we only had room enough for a few.

If your name is not on the list, please do not get disheartened, continue what you are doing. If your passion is programming, don’t give up. Learning is a continuous process, and it never stops as such. If you are still willing to learn, we are here to help you whenever you need it. Software Development Section, as an open proficiency under Hobbies Club tends to all such queries. Just join the google-group for this year. The group is open to all, whether or not you are a proficiency holder.

Congratulations to everyone who got selected.

Team SDSLabs

SDSLabs Recruitment Results

Fri, 16 Sep 2011 00:00:00 +0000

The recruitment results for second year are out. Congratulations to all the designers who got selected.

The following designers have been recruited:

Nitesh Kumar (MSc. Maths)
Mayur Karodia (Archi)
Vignesh (P&I)
Mohit Kumar (CSE)

For the Programming interviews, the following candidates have been shortlisted. The interview date is 17th Sep (Saturday).

Please arrive 10-15 minutes before your slot. There was an error in the time slots earlier. It only applies to Gaurav Singh. Please come in time.

In case you did not make the shortlist, it was because you did not fill sufficient information in the application form. If you want your application to be reviewed again, please mail us by Sept. 17 midnight at contact@sdslabs.co.in. Please state your reason, past experience, work done in the mail.

Our recruitment experience

Thu, 15 Sep 2011 00:00:00 +0000

As all of the readers of this blog (if there are any) will know, SDSLabs had a core team recruitment of first yearites recently. There were altogether 150 people who took our written test, which we had designed to test mental aptitude, coding, HTML, and design appreciation (and some other things as well). The test was well received and we shortlisted 32 people, some of which had chipped in really cool answers. Try this one for example:

How can you open a link in a new browser window?

The most amusing answer we received was this:

Right click on the link, and click “Open in new window”

Unfortunately, we couldn’t give the person involved any extra marks for that, but that was some out of the box thinking, especially considering that the question was preceded by 6 HTML questions, which demanded you to write code.

And the blank space question got in some more amusing responses, ranging from people who had told us why we should select them to people who had written cryptic math equations or a puzzle for us to solve, or simple batch file scripts, and even a paradox (VOID, we thought it might have been better as void* though). Nonetheless, we tried to keep ourselves objective and formed no prejudices about any of the shortlisted candidates.

And then we had to face the actual interviews. There’s only one way to describe them. It was pretty much like falling in love with IIT again. OK, that was not so apt, but we were blinded by the sheer exposure to pure awesomeness (Po’s words, not mine).

Like every other section at IITR, we had a lengthy discussion and debate about our hiring procedure for girls. Despite so many people asking us, we would never have gone ahead & just said yes to all of them. And by probabilities, we thought there might be 1 or maybe 2 who will fit the bill. But we were to be proven wrong by a girl who gave us an almost bug-free recursive shuffle program in 5 minutes, and another who explained to us what a chicken is in OOP terms so brilliantly. And even though we had decided that this test was meant for programmers, we found someone with such a sharp understanding of design principles that we had to take her.

And other than these we found someone who had never heard of a database, but gave us an awesome idea combined with an equivalently good db design. There were people who wrote their code as they thought it, and yet even more who gave us some really cool algorithms to do even cooler stuff.

So all in all, we were surrounded all day and night (from 1100-0100) by ideas, codes, problems, questions, and algorithms. The results will be out soon (we got delayed due to a minor totalling problem with one person, it seems they happen everywhere). And even now, our minds are so full of ideas that we can’t wait to sit with these people and work them out. We only had a small opening, since we want to remain a closed knit group (we’re still in single digits if you want to know). And not choosing any of the rest was a tough decision, believe me. If we had a single more opening, each one of the rest would have been equally apt to get in. And each time we took someone’s name off the list, we were stricken with guilt. There are so many with such great potential, and yet there’s no one to guide them. And that is exactly why we have lectures @SDS. If you want to learn something, come to us, we are more than happy to help you any time. Don’t lose hope if we didn’t select you. It was because we don’t have enough space, not because we didn’t like you.

In the following days, we will be redefining ourselves and enter a new era. And we have Shobhit Sir to thank for that. Thanks to Sagar for managing the entire recruitment, and Ankush sir for the power boosts and pep talks, just when we needed them. Also we believe we will be challenged to our limits by such a brilliant ensemble. We’ll be looking forward to working with them this semester in high hopes.

Team SDSLabs

(The final list of selected candidates will be uploaded by 22:15 tonight)

Recruitment Results for 1st Year

Sat, 10 Sep 2011 00:00:00 +0000

After much heartache and postponing of results, this is the final list. If you’ve not been selected, please don’t be disheartened. If we did not select you, it was because we had limited vacancies, not because we didn’t like you. Each of the rest was as equally likely and capable be to be selected. And each time we took someone’s name off the list, we were stricken with guilt.

There are so many with such great potential, and yet there’s no one to guide them. And that is exactly why we have lectures @sds. If you want to learn something, come to us, we are more than happy to help you any time.

Team SDSLabs

SDSLabs Final Selection List

Aditya Garg (Civil)
Ashutosh Singh (CSI)
Ashwini Khare (Civil)
Divyanshu Upreti (App.Maths)
G. Sethu (Electrical)
Nisha C. (BT)
S.Priya App.(Maths)
Shreya Bhardwaj (Archi)
Shubham Garg (ECE)
Siddharth Maheshwari (CSE)
Tarachandani Sukun Ramesh (Electrical Dual)
Vishal Mittal (CSE)

Note: The first SDSLabs meeting will be held tomorrow (11/01/11) at 6:30 pm.

Recruitment Shortlist 1st Year

Sat, 08 Jan 2011 00:00:00 +0000

Finally after after a night out and lots of head-banging over the preparation of shortlist, we have finally reached a consensus over the students to be interviewed. The following is the list of the shortlisted candidates along with their time slots…. Please arrive well before time.

But before peeking a look before we want to thank everyone who came to give the test. The enthusiasm of students for learning programming and coding stuff has really surprised us and further motivates us in our zeal to promote computational activities in campus. So while if any of you might not have been selected, don’t lose heart!!! Feel free to approach us with any doubt you might have in this field.

We will try our best to answer your queries. Plus as is the purpose of Software Development Section in Hobbies Club, we will carry on from where we left last semester and continue organizing lectures on broad ranging topics.

Thanks Team SDSLabs

You can download the list here

PS : Venue for interviews is Committee Room, Hobbies Club.

We want you to join us

Wed, 05 Jan 2011 00:00:00 +0000

Recruitment Posters available here.

First of all, Happy New year wishes to all of you. SDSLabs has had a great first semester, with quite a few services and applications under our belt already. But what we’ve done so far is tiny compared to our plans for the future. And in our planning for this, we had envisioned a core team of our section (web-design). And now, we have decided to finally recruit first-yearites for this core-group.

This core group will be responsible for most of our work; including but not limited to our intranet services, maintaining our Internet presence, and working on outsourced projects as well. Even though our section has been in existence for a long time, but it is only recently that we have been seeing some real progress (in terms of infrastructure, funding, and other administrative help).

Recruitments for 1st year will be done on the basis of a written test, and a follow up interview, quite similar to what the Programming & Algorithm Group has already done. The written test will include questions in programming, logic, and web design (html/css). We need people who can think on their feet, work out logical problems in their head, & enjoy working. Ideally you should be fluent in at least one of the major programming languages (c++, java, perl, php etc). However we may take an exception to other talented people out there as well… You may want to read w3schools for a bit of brush-up of your skills. We’ve got a local copy of w3schools at our server as well.

In other news, we recently celebrated Shobhit sir’s birthday , whom we have to thank for all the funding (read new server). After a more than a month of dormancy during the winter vacations, several of our projects are on right track again, and FilePanda has got a big performance boost. We’ve finalized designs for our pms system, which should soon bring a better control to our workflow process. CodeVillage has got its new Grader as well, which will soon be available on the website, after a few rounds of testing. We’ve got permission to start working on implementing DC (Direct Connect File Sharing) in the campus, which was technically an impossibility till now. But beating the impossible is what makes our work so challenging and interesting.

And for those, who are interested in knowing what else is there down the pipeline, meet us at our lab, between 6-12pm any day of the week. We’re open 24 hours, by the way. We’ve got some great web services, and desktop applications lined up. Of course if you join us, you will be free to work on your own ideas as well. If you’re up for the task, check out our recruitment posters over here.

Team SDSLabs

Hello World!

Sun, 14 Nov 2010 00:00:00 +0000

First of all, thanks for visiting the portal. This web portal is an initiative by SDS Labs. SDS Labs stands for Software Development Section Laboratories. Those of you not knowing, Software Development Section is part of Hobbies Club. It was earlier named Web Designing but has been rechristened as Software Development Section this year. SDS Labs is the core group of Software Development Section which manages its affairs and is responsible for timely completion of undertaken projects

“Hello world!” has been a catch phrase for quite some now. It first appeared in the classic book “The C Programming Language” by Kernighan and Ritchie. Since then it has been used in many books teaching programming languages as being the output printed by the first program. A great insight can be gained into the language by just explaining the process of printing “Hello world!” on the screen. In fact, in the past, these two words have been credited as being the epitome of learning new languages. Thats why we announce the arrival of this web portal on IIT Roorkee intranet through this blog post titled “Hello world!”.

For long, we felt a need for a community in the college to look after its coding requirements. It was not just the coding requirements but rather the absence of a group promoting the cause that had saddened us in the past. But since the start of this semester, we have worked hard to put a proper team in place for looking after the promotion of coding and computer related activities among the IITR junta.

We have been holding regular lectures mainly among the students of first and second year on as diverse topics as Web Designing, Linux Programming, Game Development, Mobile Apps Development and so on. Some meetings have seen students to the tune of hundreds while some had a niche audience of around five. While large numbers do give us confidence, its the enthusiasm and spirit of the students that encourages us to do more. In fact if at the end, even a small percentage of people come out with wonderful products developed on their own, then that gives us immense satisfaction and pleasure, and reaffirms our faith in the whole process.

This web portal has been developed by the SDS Labs as a small initiative to facilitate campus life of the students.

Filepanda“ is a self updating local software repository which contains most of the daily use softwares. In essence, you dont need to download a software from internet every time a new version is released. Currently it has around 300 softwares but some plans for its expansion are in the pipeline.

Campus Omegle is a web application on the lines of the popular website omegle.com. This app randomly pairs any two online people on the campus for the chatting purpose. The chat is completely anonymous and we dont archive your chats in any way!

Popcorn Moviesis a local movie repository which makes available the download of recently released movies. Note that the purpose is not to store all movies but only the recently popular ones. It has got some really cool features. We hope that this will cause a reduction in the effort by students to download new movies from internet thereby leading to a decrease in the amount of bandwidth wasted for the purpose.

Codevillage” is a application promoting programming that automatically compiles, executes and matches the output of submitted solutions hence judging them as being wrong or correct and much more. Currently, it is a little buggy and in beta phase but we hope to release a much better version later.

Thats all folks! We hope that you enjoy the portal. If you have anything to say do drop us a mail at contact@sdslabs.co.in. We would love to hear from you.

Thanks Team SDSLabs