On this episode of Exception Perceptions, Bret Fisher, Docker Captain and creator of the popular Docker Mastery series on Udemy, helps us master Docker Compose. Watch the episode, and read more of Bret’s suggested best practices. Then go and get all of his Docker resources.
Peanut butter and jelly, donuts and coffee, Wendy’s Frosties and french fries — these combinations just work. We don’t ask why; we accept nature’s gift and enjoy. We hope you also accept and enjoy our gift of another great pair: Sentry and GitLab. In fact, Sentry and GitLab already go together so well that users who have installed this integration successfully resolve issues triaged in-platform 73% of the time.
Netlify functions are a quick, easy and powerful tool, but like most serverless platforms, they can be even more difficult to debug and monitor than traditional server applications. It’s a hard environment to precisely recreate locally, there’s no machine you can SSH into in a pinch, and no built-in error notifications. Your code is going to break eventually, and you need the tools to fix it.
As you probably know, source maps allow you to view source code context obtained from stack traces in their original, untransformed form. This view is particularly useful when attempting to debug minified code (like UglifyJS) or transpiled code (like TypeScript or ES6). We’ve made the analogy before, but source maps act as the decoder ring to your secret (minified or transpiled) code.
When I tell people that Sentry is open source, they nod, understanding that this is known to be a good, noble thing. Then, they have questions. Many questions. “You mean open core?” they ask. No. Open source. “So you sell professional services?” No. Head scratching, then a pause. “Then… how do you make money?”
If you’re reading this, it means you’re at least mildly interested in Sentry and would likely be interested in some exciting new features that we’ll be releasing very soon. You can get the details on all these new features below. Also, if you’re currently in our Early Adopter program, you can potentially access these features right now. Not part of this program? Your organization can opt in at any time with the flip of a single switch found in your org settings.
It’s February, which means it’s the perfect time for us to publish our 2018 year in review. Other organizations publish these in January or even December, and they are wrong to do so. February is the best month for this, except for those years when we publish it in March. 2016 was a big year for us. 2017 was even bigger. You know what that means: 2018 was the biggest yet. How big was it?
We get it — errors suck. And you don’t want to spend too much of your time fixing them, dealing with them, investigating them, etc. In our Workflow blog post series, we’ll help you optimize your, well, workflow, from crash to resolution. To quote “the second-most frequently quoted writer in The Oxford Dictionary of Quotations after Shakespeare,” Alexander Pope, “to err is human.” There will always be errors, even in code written by the best developers.
Bugs are dumb. They’re also inevitable. However annoying that may be, it’s more productive to accept the existence of bugs in our workflows than to panic-spiral every single time they pop up. Part of the acceptance process is keeping bugs (or at least the ones you care to fix) top of mind by paralleling your error monitoring and your sprint planning.
