I have a few applications that I operate and monitoring them is a basic requirement. I utilized a script running on an EC2 instance
in a Docker container that pinged the services and pushed some values to CloudWatch. Then I added some alarms to let me
know if there is a problem. Even though it was also monitoring itself, it wasn’t a problem as the alarm went off even for
missing data.
When CloudFront goes to the origin to fetch a content it behaves like any other third-party service. In effect, by default,
whatever CloudFront has access to, everyone else has too.
The Origin Access Identity (OAI) is the primary way to make CloudFront access private content stored in S3. Without it, CloudFront is like an anonymous user, it only has access to content everybody
else has access to.
S3 signed URLs provide fine control over who can access private resources. It is flexible regarding both the
permission side and also on the ease of automation.
Why some projects are clean, easy-to-read, and performant, while others a convoluted mess? Why, when making a modification, in some codebases everything falls into place immediately,
while in others it’s more like walking on a minefield?
As WebPack 2 barrels forward, Tree Shaking — or more technically, the removal of unused exports using static analysis — is finding its
way to the mainstream. Developers are putting their hopes high, as it promises to solve the pressing problem of bloated packages. Usually,
only a fraction of code is actually needed from each dependency but their entire codebase is bundled, increasing the size.
There’s a lot of buzz about JVM optimizations and how it makes production code perform better
thanks to the Just-In-Time (JIT) compilation and various optimization techniques.
A lots of excellent research materials are available,
but I wanted to see for myself how these apply in practice,
so I decided to dig deeper and play around with some measurements.
