In the early years of web development, there were three standard fundamentals upon which every website was built: HTML, CSS, and JavaScript. As time passed, web developers became more proficient in their construction of fancy UI/UX widgets for websites. With the need for newer ways of crafting a site coming in conflict with the relatively slow adoption of newer standards, more and more developers began to build their own libraries to abstract away some of the technical details. The web ceased being a standard: now your website could be a React site, or an Angular site, or a Vue site, or any number of other web framework that are not interoperable with each other.

Web components seek to...

In this post, we will cover changes coming to Chrome (and other browsers) that affect how third-party cookies are handled—specifically SameSite changes, how to test to see if your site is impacted and how to fix it.

Blog post cover image showing a jar with cookies in it

What is SameSite and why the big change?

Back in May 2019, Chrome announced its plan to develop a secure-by-default model for handling cookies. This initiative highlights Chrome’s promise of a more secure and faster browsing experience. Chrome's...

As part of our Blackhat Europe talk “Reverse Engineering and Exploiting Builds in the Cloud” we publicly released a new tool called Terrier.

Announcing Terrier: An open-source tool for identifying and analysing container and image components.

In this blog post, I am going to show you how Terrier can help you identify and verify container and image components for a wide variety of use-cases, be it from a supply-chain perspective or forensics perspective. Terrier can be found on Github ...

This blog post is adapted from a lightning talk by Ben Fritsch at Ruby on Ice 2019.

There can be a number of reasons why your application performs poorly, but perhaps none are as challenging as issues stemming from your database. If your database's response times tend to be high, it can cause a strain on your network and your users’ patience. The usual culprit for a slow database is an inefficient query being executed somewhere in your application logic. Usually, you can implement a fix in a number of common ways, by:

Update: On closer inspection, the lock type was not on the table, but on a tuple. For more information on this locking mechanism see the internal Postgresql tuple locking documentation. Postgres does not have lock promotion as suggested in the debugging section of this post.

I maintain an internal-facing service at Heroku that does metadata processing. It's not real-time, so there's plenty of slack for when things go wrong. Recently I discovered that the system was getting bogged down to the point where no jobs were being executed at all. After hours of debugging, I found the problem was an UPDATE on a single row on a single table was causing the entire table to lock, which...

Browse the archives for engineering or all blogs Subscribe to the RSS feed for engineering or all blogs.