benmac

Discuss.io | Seattle, WA | Full Time | ONSITE

Discuss.io is a Qualitative Research Videoconferencing Platform. We integrate videoconferencing, telephony, video processing and focus group recruitment to provide a full market research solution to big brands and technology leaders. We've just taken $5million in Series A to take our platform to the next level.

We're hiring for the following roles: Front-end Developers (React) - Seattle Quality Assurance Lead - Seattle Engineering Manager - Brisbane, Australia

At Discuss.io you'll find React, Redux, Material UI, Jest, Enzyme, Mocha, Selenium, Terraform, Docker, MySQL, Redis, Node.js, Java, PHP, WebRTC, SIP/telephony, Dynamo, RDS, ECS, ElasticTranscoder, Step Functions, Lambda, Kinesis, Kinesis Analytics, Firehose, ElasticSearch and much more.

We'd love to hear from you - https://www.discuss.io/careers/

AWS has considerable defenses against DDOS attacks of all types - here's the video from Reinvent 2015 which introduces many of Amazon's defenses as well as best practices - https://www.youtube.com/watch?v=Ys0gG1koqJA

Interestingly, the presenter notes that Amazon had seen a drop in DNS as an attack vector in 2015. I asked the presenter (Product Manager) why they hadn't productized the DDoS attack dashboard so you could be aware if you were being attacked (and it was being absorbed by AWS) and his response was that there was insufficient demand at that point to justify the developer staffing. He gave me his card and asked to request the feature so he could us it to make the case internally.

Does anyone here have stories of being successfully DDoS'd on AWS (other than by their own staff :) ?

Given that so many of us are now hosting on AWS, I'd like to ask the question - who has been hit with a DDOS attack / extortion letter while is hosting on AWS? It would seem that there's many old-tech companies hosting in data centers that would seem to be far more vulnerable to non-TCP attack vectors than AWS-hosted systems. Is that who is generally targeted here? Are there any stories, anecdotal or otherwise, about people getting hit with DDOS attacks while using AWS. Here's a talk by AWS on their measures against attacks - https://www.youtube.com/watch?v=Ys0gG1koqJA. The only thing short of Silverline etc defense that they seem to be lacking is the reporting dashboard indicating when they've defended against DDOS attacks. So has anyone received a letter from DD4BC and other miscreants whilst hosting their domains on AWS?

Be very wary of signing up for Comcast business service. They have an auto-renewal policy that renews your contract every year even though you thought you'd signed up for a single year (with the expectation of month-to-month). When you come to leave Comcast Business they will charge you 75% of the outstanding balance you have on the current year ($485 for 10 months in my case) and they'll fight tooth-and-nail to get that money. They don't apply this policy for residential customers because consumer protections don't apply for businesses.

During the four years that I had Comcast Service I found it to be very reliable and well run - well, except they wired the wrong apartment by mistake the first time they came out.

It took me about 2 months of fighting until they relented. There was a magic cocktail of proposed complaints involving the BBB, the PUC in my state, social media and others that finally liberated me from their contract.

I faced the same challenge. Jon Kabat-Zinn removes religion from meditation and makes it sensible and accessible. I have gone on to read several of his works and now practice religion-free meditation with positive benefits. Probably the best introduction to his work is via his interview on the OnBeing podcast: http://www.onbeing.org/program/opening-our-lives/138

I wanted to love JRuby (Ruby 1.9 emulation) but bugs like this: https://jira.codehaus.org/browse/JRUBY-5529 causes HTTPS calls to services like Stripe to fail. That bug has been open for over one year now.

Other bugs like this: https://jira.codehaus.org/browse/JRUBY-6181 cause Capistrano deployments to fail (but there is a workaround).

Lack of a clean implementation of something as fundamental SSL libraries and the inability of the main committers to address those shortcomings pushed me back to a traditional Ruby approach.

That service (reputations from SO, Github, LinkedIn etc) is available: http://strictlydev.com/