On the Thursday of our engineering retreat, I found my new calling as a professional wrestler fighting my way to the top of the Luxor Hotel, in a live streamed pay-per-view event. All this to claim the coveted contract and millions of dollars. My teammates were right there with me, each showing off their skills in their gambit for the top prize.
Only it was a virtual Luxor, and we were playing The World Wide Wrestling roleplaying game (RPG). It was as ridiculous as it sounds, and we had a blast!
Our game day was one segment of a re-imagined retreat, after COVID-19 put the brakes on our in-person gathering in Vegas.
Our friend, Matthew Harris is the founder of sendwithus. He recently wrote an article for Venturebeat about social engineering - using a human interaction, like live chat, to trick people into providing security information.
In this follow-up article, Matt explains how the extra data his team populates in the olark UI helps identify customers and mitigate the risk of an intrusion via chat.
If you’ve done any sort of front-end engineering work over the past few years you’ve more than likely been inundated by the sheer volume of new technologies at your disposal. From Backbone.js to React, the rate at which new front-end technologies come out is rapid enough to make anyones head spin.
Staying abreast of the latest front-end technologies is hard, but determining which are suitable for your team and product is even harder. Here at Olark our front-end technology stack has evolved quite a bit over the past few years. From our early days of using vanilla JavaScript, to wrestling with large scale Backbone.js apps, to where we’ve landed today with React and Flux, our front-end stack has continuously evolved.
A little while ago we announced reaching 10,000 paying customers. It was, without a doubt, a huge milestone and we wanted to celebrate. Not only did we want to celebrate, but we wanted to celebrate with our customers who helped to make it all happen.
Hey there, guys! Aaron Wilson here, the ever-present but ever-invisible Olark Ruby Ninja Warrior. I'm coming out of the shadows to tell you a little bit about our fun journey with database backups.
Every day, Olark sees more than 3 million visits across thousands of different websites and browsers. We constantly have to ask ourselves: are we causing any issues or slowdowns on our customers' websites?
Knowing the answers to these questions is critical to our success.
A casual misstep means we could be silently breaking thousands of websites, halting transactions, angering the world, causing the next recession...you know, the usual.
TL; DR: Browser encoding can change from one request to the next. When you set content-type, be sure to also specify a charset. Being in the US, that great, wide birthplace of the Internet, it's very easy to take encoding for granted. Anyone who's not a web developer can happily inhabit ASCII for their entire lives, and at most raise a few eyebrows when they see funny mis-encoding like "fiancée" in a few Latin Extended words here and there.
Why care about third-party Javascript embedding?
Over the last five years or so, embedding Javascript code has become the norm. Much of this code is delivered by third-party services like Google Analytics and others. In fact, I just checked this morning and the Olark website embeds at least six separate third-party Javascript tools ranging from website analytics, to A/B testing frameworks, to commenting systems…and of course our very own chat box.