Sugendran was here.

Yesterday was my first day at the London office for Yammer. And frankly I was (and still am) excited. For those of you who don’t know Yammer here is the elevator pitch: It’s the social network for your enterprise. It provides the visibility and openness that is killed by the email swarm.

Some backstory.

Back in February I had a Skype interview for Yammer. It was a brief-ish interview, about half an hour of personal fit questions and then some technical stuff. No writing code at this point. I found this odd at the time, but it does make sense not to over optimise on the ability to write contrived sample code. I left this interview feeling like I had failed the technical questions largely due to the fact that I completely rambled and didn’t answer one of the questions.

Shuffle ahead 24 hours. I get an email from HR saying that they want to get me over for a face to face interview. Wait, what! Yep, they wanted to do a face to face interview and were going to fly me from Sydney to London for this. After haggling to get some extra time to recover from the 24 hour flight prior to London my tickets were booked.

Two weeks later: SYD => LHR

Hardest whiteboard coding question I’ve had to do. Ever. I don’t remember what the first question was, but I did it too fast so they jumped right to the hard stuff. Dang. I’m not going to post the question here as it’s a good one and would like to keep using it in interviews. I spent about 45 minutes writing code on a whiteboard to answer the question. I’m amazed I was coherent after it all.

My interview lasted 4 hours in total, with 4 sessions of 1 hour each. It was pretty broad interview which made sense. They tested me on all parts of the job, but every single interviewer asked me questions to judge personal fit. This was very different to an interview I had done with another large tech company. Yammer placed as much importance on cultural fit as they did on ability.

Later that day: I got the job.

I still haven’t explained why I’m excited.

My excitement is two-fold.

Firstly, I’m excited to be working for a company who make a tech based product and value their engineering staff as intelligent beings capable of helping shape the product. Engineers are not a “resource” that some project manager can take from column A and put in column B. Right from the start the relocation package was amazing, it made me feel wanted. Then on my first day I get given a fully spec’d machine and get told that i can order any extra bits and pieces that I want, no serious limitations on what could be ordered. Even the project workflow gives the engineering lead the choice to remove things that they think are not minimal viable product. Amazing! I still don’t understand why more companies don’t realise that they hire some really smart people to create their products. And that if they empower these smart people their product will benefit from the extra care that these people put in.

Secondly, Yammer is owned by Microsoft. For the last 8 years I’ve wanted to work at Microsoft. Not as a contracter and not at one of the agencies. No I wanted to be a fulltimer and now I am. Career goal, ticked. For all you haters out there, Microsoft is in fact a great company. They’re large enough to fund some interesting research projects and open source quite a lot of things. They also surround you with a massive support network so that you can get your job done without having to worry too much about the logistics. 

I’m very excited about this next stage in my career and can’t wait to get my fingers into some code. 

Just last month there was inktober which is this awesome idea that artists sketch something in ink every day for the month of October. Everyone was tweeting their sketches, but I didn’t really want to have to search every day to see what was new. So I went looking for a service or code that would just auto retweet everything for me. I tried to follow the Yahoo pipes method and then found things weren’t quite what they seemed. Then I found a free service that would do it - just they had trouble scaling and would only do 1 tweet every 3 hours… WTF.

So I figured, heck I can just whip something up in node.js… yeah right! There are MANY twitter modules in NPM, and most of them are using the old API which twitter has since abandoned. After much trial and error I found tuiter which worked for my needs. Most of these twitter API wrappers have really poor documentation so after reading examples, tests and actual code I came up with a solution.

It works like this:

1. Create a stream to listen on 
2. Everytime we get a tweet on that stream make a decision about retweeting it
3. Retweet
4. Profit.

I’m not going to explain the code since I wrote comments in the index.js - if you just want to use it as is you can just replace the conf at the top of the file with your twitter API keys and search term(s). Code is over at https://github.com/sugendran/node-retweeter

For the last year I have been writing Node.js predominately on a project called Graphdat. It’s been a year of learning and pushing my skills further than ever before. The premise behind Graphdat is pretty straight forward, see how your application and servers are performing as a whole in realtime.

Yes, we invented perfmon, but here’s why. With cheaper virtual machines it’s much more effective to spread your application over a few low powered cheap servers instead of an over the top super computer. So how do you visualise your server farm? How do you look at the perfmon data for 5 machines and find a pattern? The reality is that it’s not so easy, and most of the solutions out there are still stuck in the 90s with their graphs and slow updates. 

Enter Graphdat. It has a 1 line install and works on most systems.

Within seconds of installing you should see your server’s metrics on your dashboard. And for those of you afraid of installing things without trying you can even see the actual data for our servers on the demo dashboard. We’ve spent quite a bit of time on the UI for the dashboard; you can scroll in and out, drag through time and then quickly jump back to realtime. All this so you can find little spikes in your application as your users do their thing.

The part that’s really exciting for us is the the graphing of request counts and response times along side your server metrics. See how the performance metrics for your server change as the number of users increase. See how much longer it takes you to serve content when the number of visitors double. Right now there are plugins for Node.js, Apache, IIS and nginx that will push these stats to your dashboard.

The Node.js module let’s us take it even further. Using the graphdat module you can add timers to your code so that you can see which parts of the code is contributing to performance issues on each route. All this in realtime and on the production server.

I will be doing a follow up post where I take an existing node application and instrument it  using Graphdat. In the mean time check out this quick start guide to using Grapdhat.