February 2016 Summaries

We use PostgreSQL at Sentry as our core database, with two clusters operating cold-standby replicas. Most data is stored in SQL, except for large event blobs which are written to Riak. We see a pattern of heavily-duplicated errors and unique errors creating new aggregates. To alleviate locking contention, we take a buffered writes approach, aggregating writes over time and flushing them after an interval of 10 seconds. This allows us to greatly increase our throughput by sacrificing strong consistency. We use Redis as a buffer to store the pending writes, with a simple schema that stores entity attributes and keys in two structures: a hash per entity and a set of hashes which need flushed. The Redis implementation ensures that only a single row in SQL is being updated at once, alleviating most locking contention.

Crash reporting is a critical programming practice that involves capturing and reporting unexpected, non-ideal events that cause code to stop functioning, regardless of whether it actually causes a true crash. This can include errors, unresponsive websites or servers, and other issues that occur during application execution. To handle crashes, developers use frameworks, middleware, and logging mechanisms to capture and report errors in a way that ensures the application continues to run smoothly while still providing valuable insights into system performance and behavior. The Sentry platform provides a comprehensive solution for crash reporting, offering abstractions such as passthru and logging to help developers capture and report errors effectively, while also allowing for flexibility and customization to suit their specific needs.

Sentry is hosting its second Happy Hour in San Francisco, where attendees can meet the community and get help with JavaScript errors, learn about Python debugging basics, and understand how to handle PHP exceptions. The event will take place on February 9th at 6 PM at The Willows, located at 1582 Folsom St.

In this article, function wrapping in JavaScript is discussed as a common practice used in various scenarios such as binding `this`, profiling, mixins, code coverage, hiding complexity, cross-platform code, and partial applications. Writing bulletproof function wrappers is crucial to ensure they can wrap any conceivable function without breaking anything. Key points include using `apply` and `arguments` when writing function wrappers, preserving arity by redeclaring variables, and considering the impact of function wrapper implementation on code that inspects a function's length property. The article emphasizes the importance of safeguarding against problematic behavior when writing function wrappers, especially for library authors or scripts operating in unknown environments.