Cache

One long standing issue that I’ve had with the LinkedIn GitHub page that I helped design was that it because it relied on the GitHub public API to fetch all the data, if the user accessed the page from a rate-limited IP address the rendered page would be blank as no data would be returned by the API. I had some time on my hands today and decided to fix this bug.

The simplest fix for this bug is to cache the GiHub API response in a file, and when you get rate-limited by the GitHub API fall back to reading from a cached API response. Since the raw API response contained lots of information that was not required to generate the website, I decided to add an intermediate filtering step to only extract the relevant information from the raw GitHub API response. The JSON data generated by this filtering step is the final cache used by the webpage.

To test the code I’d written and to make sure everything works as expected I needed to rate limit myself. This was easily done using the (amazing) Python Requests library.

You can find my fix for this bug here.

Update — I realized that my original patch failed to use the GitHub API response when the user was not rate limited. My last commit should fix this.

 

Help

Prior to heading out to MHacks I envisioned having the time to catch up on some tech and non-tech reading over the course of the event. However, this was not to be.

(And no, I’m not disappointed in the slightest that I was occupied the entire time)

I spent a majority of my time helping and mentoring teams participating in the event. I had volunteered to answer any web development related questions. Here are some of the problems I helped solve and technical concepts I explained:

  • How to architect a website that used in-browser video conferencing as a key component. I suggested using WebRTC as it is something that I’ve used in the past. The team chose to use the excellent PeerJS library as an abstraction over WebRTC.
  • How Ajax + callbacks work in JavaScript. The team’s algorithm needed nested callbacks (3 levels of nesting if I recall correctly) because of dependency issues, and the phrase “callback hell” did come up.
  • Given a set of documents, how do you determine, for a particular document, what are the similar documents? This is the problem of semantic similarity. I also explained some basic NLP concepts to the team.
  • How to create a website so that it has a responsive design. My suggestion was to use Bootstrap (I love this framework) and have it do the almost all the heavy lifting.
  • How to use Flask to build backends that are not coupled to the frontend (web v.s. text message)

This was probably the most mentoring I’ve ever done at a hackathon. It was a great experience, and I would definitely do it again.

 

M3

(All my MHacks posts have been terse because I’ve been either very busy or tired)

Helped and mentored teams at MHacks until 3.00am on the 13th. I was exhausted by the time I got back to the hotel.

We got back to the venue around 10:30am and I spent the rest of the day in final judging. It was lots of fun walking around and watching teams present their projects. There were a lot of very cool and impressive hacks.

Overall, MHacks was a phenomenal experience. I’m very happy that I got a chance to be a part of it.

IMG_4290

Deux

A few weeks ago I hit my two year mark of working at LinkedIn. Just as I wrote about my first year at LinkedIn I thought it would be interesting to capture my feelings and thoughts at the end of two years and briefly chronicle what has happened since that post.

IMG_4093

The biggest change that has happened in the past year is that I’ve moved to a different team. I started working at LinkedIn on the Service Infrastructure team where I worked primarily on Rest.li. Working on Rest.li was fun, and I learned a lot. I got to contribute to an open source project early on in my career which was incredible. I even got the opportunity to work on a Rest.li protocol upgrade for all our services, which was a non-trivial problem to solve. TL;DR — working on Rest.li was great. However, I wanted to learn what it was like to work on a lower layer of our technology stack. I’d heard very good things about LinkedIn’s distributed graph team and I knew they were working on solving interesting problems. I joined the distributed graph team in 2015 and I’m extremely happy with the decision that I made.

I had the opportunity to speak at a tech conference! Steven Ihde and I spoke at QCon 2014 on the evolution of LinkedIn’s service architecture. Never in my wildest dreams did I imagine that I would be speaking at a conference so early on in my career. It was an honor and a fantastic experience, and I can’t wait to do it again.

IMG_4095

I mentored two interns (one in 2014 and the other in 2015) as part of LinkedIn’s summer internship program. Mentoring is a rewarding and challenging experience. I would recommend everyone try it at least once in their careers.

While this might be hard to quantify exactly, I feel that I’ve become a better software engineer. I’m more confident about the code that I write and the technical decisions that I make. Part of this confidence can definitely be attributed to the great people that I work with who have helped me grow and learn.

Oh and I got promoted. That was very awesome. 😀

I can’t wait to see what my future at LinkedIn holds.

Documentation

I recently received a feature request for http://linkedin.github.io – one should be able to link to an external website hosting documentation for the project directly from the home page. I had some time tonight so I implemented this feature. It wasn’t hard to add at all, and it gave me a chance to exercise my Javascript muscles which have been dormant for some time now. I also identified sections in the codebase that I would like to refactor, and hope to get to doing that sometime within the next 2-3 months.