I really like Test-Driven Development (TDD) and apply it almost always. The problem with TDD is that it focuses too much on working software.
One reason I really like the serverless architecture approach is being pretty selfish: one has to care only about what matters - the code. Well, I know code is not everything, but as a developer I'm just having more fun coding than scripting infrastructure in YAML or similar. For people like me is the serverless model a dream come true. But how to do serverless without turning the dream into a nightmare?
Distribution of a task among several threads means horizontal scaling - the more computing resources (processors) the less time to work the task out. Sharing data among threads brings the need to synchronize which kills the scaling capability of the computing. How to proceed when shared data are needed?
Binary data shouldn't be a part of the codebase. This is pretty well-known practice. But how to proceed when we do need binaries in our codebase, for instance as test data?
Write your tests once and run them twice - as both unit and integration tests - sounds like a good deal, let's take a look at this practice.
Black-box testing is testing of a component via its API without any knowledge of its implementation details. As the opposite there is the white-box testing. And it about testing implementation, right? Well, no...
Continuous delivery (CD) brings a lot of ideas essential for a modern software product deployment. In this article we discuss how to follow CD principles by building CD pipelines with an example in AWS.
Nothing new, but I keep seeing this bad practice around again and again... Let's explain why this is incorrect:
Automated infrastructure (Infrastructure as Code) is essential to succeed (not only) in the cloud. AWS provides its own service for managing resource stacks: AWS CloudFormation. What are the options to manage dependencies between stacks, how to use them and which pros & cons they have?