Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Bun is a new and ambitious JavaScript toolset and runtime. Early adopters have been reporting that Bun is incredibly fast — so fast that it has been touted by some as a Node.js killer. Curious, I decided to check out Bun for myself and benchmark it against the competition.
Is it as fast as people are saying? How stable is it? Is it really better than Node? And can I use it with continuous integration?
A microservice application is a group of distributed programs that communicate over networks, occasionally interfacing with third-party services and databases. Microservices, by their networked nature, provide more points of failure than a traditional monolith. As a result of this, we need a different, broader approach to testing.
So, how do we test a microservice application? Does the testing pyramid still work? How do we test when third-party services are involved, and network disruptions are a possibility? We’ll attempt to answer all these questions in this post.
Microservices are the most scalable way of developing software. But that means nothing unless we choose the right way to run them: processes or containers? Run on my servers or use the cloud? Do I need Kubernetes? When it comes to microservice architecture, there is such an abundance of options, and it is hard to know which is best.
As we’ll see, the perfect place to host a microservice application is largely determined by its size and scaling requirements. So, let’s go over the 5 main ways we can deploy microservices.
Imagine a microservice application consisting of dozens of continuously-deployed autonomous services. Each of the application’s constellation of services has its own repository, with a different versioning scheme and a different team continually shipping new versions.
Riddle me this: How can I tell the (whole) application’s version? Being that the change history is scattered among dozens of repositories, what’s the most efficient approach to keeping track of changes? And how do we manage application releases?
Your team decided it’s time to get rid of that old, clunky monolith (finally!). You had a good run with it, but the monolith has grown so big that you're spending more effort maintaining it than adding features. It's time to try a different approach.
It seems microservices are very popular these days, so maybe it makes sense to dig a bit deeper there and see what all the fuss is about?
Next in the list is to brush up your technical skills because knowing your technical stuff will make you stand out. Questions (like the ones in this article) are a great way of testing your knowledge. To help you, we’ve collected and answered 30 common CI/CD interview questions. How many can you answer?
CI/CD interview questions may include version control and Git as a topic.
You want to start a blog, or perhaps you already have one and want to improve your style. Maybe you’re writing documentation and struggling to make it concise and clear. Whatever the case, you have a blank screen in front of you and a head full of ideas. How do you start? How do you write a blog that other developers will enjoy?
Here are 13 things I’ve learned over my years of writing for developers.
Introduced by Mike Cohn in his book Succeeding with Agile (2009), the pyramid is a metaphor for thinking about testing in software. It’s an idea that has caught on so strongly that, to this day, it’s still the industry standard in engineering circles.
The pyramid attempts to visually represent a logical organization of testing standards. It consists of three distinct layers:
I picked some of my favorite books at my company, Semaphore — books that have profoundly influenced the company’s engineering culture. This list contains a mixture of classic, timeless texts and a fair share of modern game-changing publications, aimed at senior engineers and devs. But you don’t have to be a senior engineer to benefit from the books on this list, anyone interested in software development would enrich their skillset by reading them.
We hope you enjoy reading this list as much as we enjoyed making it.
The word “test” originally referred to “a small vessel used in assaying precious metals.” This meant that testing was a method of ascertaining the quality of gold or silver. It was also used in the process of refining valuable alloys, such as tin.
Later, the term was adopted in other fields, and these days it’s common to find it in contexts such as education, medicine, or software development. Its essence, however, has not changed: testing is used to refine end value.
I start with this story because I don’t want you to think that I do not value tests. I do. Very much. I believe we can’t live without them. But you can have too much of a good thing. However vital water may be, too much of it results in a flood.
Tests are living documentation, messages to other developers (and our future selves) about what the code is supposed to do. Tests enforce requirements and provide feedback, telling us when something breaks.
From a management standpoint, Test-Driven Development (TDD) can be a difficult sell. It involves a relatively large upfront investment, has no obvious business benefits, and (most important of all) the customer is paying for functionality, not tests.
Tempting as it is to cut testing in order to reach the next milestone in the project, it is a mistake because, as we’ll see, TDD can help us accelerate development and reduce costs over a project’s lifecycle.
From developers to testers, from business analysts to management, everyone in your organization must be committed to keeping tests in top condition. If you have an extensive test suite, you’ll need a plan to focus the effort. Check out our 5-step framework for identifying and optimizing slow tests if you’re not sure where to start.
Software development is modulated by the tools supporting it. Of these, testing is the most widespread and has the largest impact. Keeping tests fast and responsive leads to improved productivity, better code quality, and higher deployment frequency.
Professional software development is a feedback-based process — each new iteration is informed by past results. Feedback is powered to a considerable degree by tests.
Slow tests affect development. Engineering teams lose momentum and become frustrated because they can’t meet their goals. A slow test suite puts the brakes on CI/CD, making release and deployment more difficult. This often means that organizations can't ship out products on time, and risk losing their competitive edge.
Think of a world where you don't need a separate testing environment, where you can test everything in production and capture valuable data that helps you improve along the way. The secret ingredient: feature flags.
Features flags is a software engineering technique that lets developers integrate code constantly into the main trunk. It involves shipping incomplete features into production, which remain dormant until ready. Feature flags also take part in software delivery; when the feature is complete, the code can be activated at the flick of a switch.
