Disqus - Friends of arturogarrido

Re: Goodnight Fancite - My take away from being a Founder - Sunil Sadasivan

sunils34 — Fri, 31 Aug 2012 13:30:46 -0000

hey tom, good question.

We were just about ran out of money in the bank and we had no room to pay for hosting costs. The costs weren't huge, but they were decent enough for us to say we dont want to spend personal money keeping it up if we're not supporting it. I moved Fancite over to my own server just to show people what we built.

If you're curious.

http://fanciteproto.sunil.is

Re: Scaling Buffer in 2013

sunils34 — Mon, 05 Aug 2013 11:53:54 -0000

Hi Abhinav!

Thanks for commenting! I definitely agree. I love nginx and had a similar gunicorn+nginx setup in my previous startup. I do think that we may end up switching to nginx down the road as it's much easier to configure than apache. The main reason we're on apache is because AWS elastic beanstalk has been a very solid option for us to scale and have enough control over what's going on. Right now Elastic Beanstalk seems to work well with Apache for us (the default webserver). Down the road, as we have more resources to spare, we'll be looking at ways to boost performance (in terms of both development/configuration and response times). I'd love to hear more about the setup that you have!

Re: Scaling Buffer in 2013

sunils34 — Mon, 05 Aug 2013 12:02:38 -0000

Hi Martin! Thanks for sparking this discussion! I personally love Nginx and think it's great! We may end up switching down the road as it's easier to configure, but (as mentioned in the other comment above) this will be done when we have more resources to spare. As of now we actually haven't had any significant performance/scaling issues with Apache for us to prioritize the switch.

Re: Scaling Buffer in 2013

sunils34 — Sat, 17 Aug 2013 20:33:53 -0000

Hi Matthew! I'm so glad you brought this up as it got me thinking more about how suboptimal the worker set up is!

We use more small servers on our web and api environments because we're connection and bandwidth limited, and not limited by CPU or memory from m1.small servers. It's also for reliability/high availiability that we prefer to load balance across several servers.

I completely agree however that our workers are more so CPU/Memory bound and it makes more sense to use larger instances. For HA purposes, we're still going to want multiple servers, as our workers are critical (we'd prefer to over provision a bit more here). I'm going to do some more experimenting with numbers to see what makes sense! I'll report back my findings. Thanks for the great question here!

Re: Buffer security breach has been resolved – here is what you need to know

sunils34 — Tue, 29 Oct 2013 21:18:16 -0000

Hi Arturo, Thanks for asking these questions for us to clarify! We do not store our FB and Twitter API keys in our MongoHQ db. They're located in a separate place.

With how we originally set up our apps, the access tokens did not need the API keys to make a valid API request. Which is why the hacker was able to spew spam. We've changed our Facebook app to require an appsecret_proof, which checks the validity of the access token with our API key. Thus stopping the spammer from making valid requests. Unfortunately at this time, Twitter doesn't not have an equivalent of this extra parameter. This is why we had to invalidate all Twitter tokens and encrypt them ourselves.

Let me know if you have any more questions about this!
Sunil
Buffer CTO

Re: Buffer security breach has been resolved – here is what you need to know

sunils34 — Tue, 29 Oct 2013 21:20:08 -0000

Hi Kevin! I'm so sorry that you logged in today and saw a bunch of failed posts. That's not good.

We have an email setting that you can turn on which will email you every time a post fails for some reason. If you turn this on, we'll email you when we're not working :). https://bufferapp.com/app/a...

Hope that helps!
Sunil,
Buffer CTO

Re: Introducing 2 Step Login for Buffer: The safest social media publishing on the web

sunils34 — Tue, 26 Nov 2013 09:38:01 -0000

Hi Kray! That's a great suggestion! I've not heard much about those. I'll research this a bit more and see how quickly we can add support for Yubico and/or Toopher. They look like very secure options.

Re: Introducing 2 Step Login for Buffer: The safest social media publishing on the web

sunils34 — Tue, 26 Nov 2013 12:20:09 -0000

Hi Paul, You're right, we have not yet added this to our mobile apps. We'll be pushing out updates to our mobile apps sometime in the next few weeks with TFA support.

Re: Introducing 2 Step Login for Buffer: The safest social media publishing on the web

sunils34 — Tue, 26 Nov 2013 20:57:50 -0000

Hi Phil! Your 3rd party connections will work as expected, even if you've set up 2-factor authentication. You can always revoke access to third party apps here: https://bufferapp.com/app/a...

Re: Introducing 2 Step Login for Buffer: The safest social media publishing on the web

sunils34 — Wed, 27 Nov 2013 10:33:12 -0000

Hi there! That's awesome you're considering encryption! Email encryption is often something that's overlooked! We use a few different encryption methods. Depending on the use case, we use a mix bcrypt, xor encryption and mcrypt.

Re: Introducing Buffer for iOS 7: The Easiest Way to Manage Social Media On The Go

sunils34 — Wed, 09 Apr 2014 11:06:44 -0000

Hi Emily! Yup these new features are definitely going to be in the Android app. We're working hard to ensure they move to the Android app.

Unfortunately though, it's hard for me to give a more accurate timeline of when some of these features will make it to the Android app.

Re: How Buffer Has Reacted to the ‘Heartbleed Bug’ to Protect Our Customers

sunils34 — Thu, 10 Apr 2014 13:18:58 -0000

Hi There! That's a good question! The OpenSSL community is a large one and comprised of many top web companies (Google. What was concerning is OpenSSL is the de facto standard library that most sites on the web use for SSL encryption and that's why this was shocking. OpenSSL is well tested The engineers at Buffer did a deep review of the heartbeat vulnerability and the fix that was made with OpenSSL and our set up as well as dug deeper into the OpenSSL library to look for other potential vulnerabilities.

Unfortunately I don't think at the moment we'd be able to contribute as much as we'd like to OpenSSL development, however we'll definitely be more conscious of the software libraries that we use and ensure we're always up-to-date and jump quickly on any new known vulnerabilities.

Re: How Buffer Has Reacted to the ‘Heartbleed Bug’ to Protect Our Customers

sunils34 — Fri, 11 Apr 2014 03:55:07 -0000

Hey Rodrigo! Great question! We did reissue/re-key our SSL certificates with a new private key. We're working with our Certificate Authority to revoke the old SSL cert. Let me know if you have any more questions about this!

Re: Meet The Single Line of Code That Generates Nearly $4 Million a Year

sunils34 — Thu, 01 May 2014 11:22:48 -0000

This is a great idea! We have thought about providing a more estimated time your post will go out. It's been such a fun and unique challenge to provide more accurate guarantee of timings, and definitely something we think is solvable so this has really helped push us to get to a stable solution :).

Re: Buffer’s April Engineering Report: New Happiness Dashboard, New iOS App and 20+ Vulnerabilities Patched

sunils34 — Fri, 09 May 2014 12:22:19 -0000

That's a great question! We do try to link users based on twitter account, emails. We're lucky in that we know twitter handles and email addresses to link conversations to particular users. This is super helpful for our Happiness team to help out with specific user issues!

I think there's a lot more we can do with making those connections and learning from them!

Re: Buffer’s April Engineering Report: New Happiness Dashboard, New iOS App and 20+ Vulnerabilities Patched

sunils34 — Fri, 09 May 2014 12:23:13 -0000

It's so awesome to hear you're interested in seeing the dashboard. Our goal is to make this public. We haven't announced it yet because it's still fresh and a bit rough. Here's what the first version looks like!

happiness.bufferapp.com

Would love to hear your thoughts!

Re: Buffer’s April Engineering Report: New Happiness Dashboard, New iOS App and 20+ Vulnerabilities Patched

sunils34 — Fri, 09 May 2014 12:23:39 -0000

Thanks Eric! It means a lot to hear what you think about what we're doing!

Re: A Simple Guide to Measuring the Product-Market Fit of Your Product or Feature

sunils34 — Fri, 06 Mar 2015 07:33:23 -0000

Hey Abdul! Great question!

We use our own built solution for event tracking. We then store this in a Redshift DB and use Looker to slice and dice and learn about the usage. Here's a couple links of what we built!

How we track
http://blog.mongodb.org/pos...

How we measure
http://www.looker.com/blog/...

Re: What Michigan Wolverines Basketball Taught Me About Hiring at Buffer

sunils34 — Thu, 12 Nov 2015 17:51:28 -0000

Great question Mitchell!

Here's a little bit around how I interview :).
Typically what I do is first just ask them about their personal journey. I learn so much from those 10 mins of understanding where they come from and the experiences they've had. How they viewed learning and growing, what they think about themselves, how they view the opportunities life has afforded them all typically comes out here. I also love love hearing about side projects (of any kind) and the motivation behind those side projects. When candidates talk about a failure, maybe in a startup or side project they've built, that's a huge opportunity to gauge how they view those moments. The best ones I've seen, view those moments as hugely beneficial and focus on what they've learned when talking about that.

I'll next ask: If you were to join Buffer, describe to me what you envision would be the best role and environment for you. I learn so much from that question. I'd tend to like 'I want to work on something new to learn' over something like: 'I want to use my experience and help lead this area'.

I then go through a code walkthrough where they show me snippet of code they've written that they're proud of. The candidate talks me through understanding it. This tells me a lot about their coding style, communication. Most importantly, it also tells me what they're proud of. The best candidates I've come across often show something new or unique and their reason for showing me was because they learned something new in that process. They have an opportunity to show something safe that they've written many times or perfected, but if they're proud of some snippet they've written in which they've taken a risk to show me, that tells me a lot. Usually I've learned something new from the best candidates during the code walk through :).

I also often find myself saying things like 'describe me your motivation for...', 'walk me through what you were thinking when this happened'. I've found this to be a really great way to see through their eyes.

None of these questions are at all silver bullets. I definitely find that an hour long chat is not nearly enough time to get to know someone fully. So I think what's truly key for us is the 45 contract period where we work closely together.

Hope this is helpful! :)

Re: Are You Creating Forward Motion Or Stop Energy?

sunils34 — Mon, 14 Mar 2016 14:52:53 -0000

Thanks Liza!

Re: Are You Creating Forward Motion Or Stop Energy?

sunils34 — Mon, 14 Mar 2016 14:53:27 -0000

Wow great recommendation Daniel! Will def take a read, seems very similar and perhaps the same base principle to Stop Energy.

Re: Are You Creating Forward Motion Or Stop Energy?

sunils34 — Mon, 14 Mar 2016 14:54:25 -0000

That's such a great idea Marissa! Fully agree, I think we would learn a lot segmenting out different areas of Stop Energy as it relates to different demographics and teams.

Re: Are You Creating Forward Motion Or Stop Energy?

sunils34 — Mon, 14 Mar 2016 14:54:58 -0000

Awesome LeeAndra! Excited to have this perspective myself on gauging how fun and productive a team can be.

Re: Are You Creating Forward Motion Or Stop Energy?

sunils34 — Mon, 14 Mar 2016 14:57:36 -0000

That's such a great question and not sure if I have a validated solution to it. My hunch would be simply recognizing and talking about 'Stop Energy' is a first major step. I think a key challenge orgs may have is simply not recognizing why things move slower. I'd imagine if a bank has it in it's culture to recognize Stop Energy, that would be a huge step... it would require the awareness of several teammates to recognize it, and talk about it's effects and give feedback on it. My hope here was to bring awareness to our team on it, now teammates can give feedback to each other on their experiences of Stop Energy :).

Re: Building Slack /slash commands with AWS Lambda

sunils34 — Fri, 01 Apr 2016 17:02:08 -0000

Oh interesting, I'm curious, what's your Lambda timeout set at. I think we set ours to 10 seconds which helped ensure we don't see a slack timeout.