Markdown is a great format. I use it a lot for documentation. It's much easier to keep documentation up to date by keeping it close to the code. Sure, Markdown has limited formatting features, but it helps to focus on the essential part, the content. But there is one feature missing: Drawing diagrams.
When working with Kubernetes, a question that will always come up is: "how to set up proper health checks"? The Kubernetes documentation provides some basic information about why you might want to use them and how you configure them. But, as with all things–it is a bit more complicated than that.
react-beautiful-dnd is a great package for building complex drag and drop behaviors of lists. If you want to reorder the items in a list or move them between lists, this is the go-to package. But the package has a problem: Atlassian has limited its maintenance to security fixes.
Testing is all about being confident that your changes to the software can be deployed to production without problems. While unit or integration tests help you to test details — like the results of a calculation, or whether two parts of your system are working together — you don't know whether all parts of your system are working together as they should. Systems are getting ever more complex and we try to cope with that by splitting it up into parts so that we can handle them or distribute the complexity over multiple teams. Teams develop and deploy small, loosely coupled Microservices that reassemble a bigger system. How do you know that everything works together and that a user can use it? This is where End-to-end (e2e) testing comes into play. And Cypress can be a nice tool for that.
Recently I wanted to create the effect of a cable for an application I'm working on. The cable should have a textile look, similar to a rope, which is quite common right now (for example the charging cable of the current MacBook Pro). I'm using SVG for rendering, so applying a pattern to a stroke path should be easy, right?
Every software development team depends on architectural decisions. But more than often, the results of architecture discussions are never written down. This is a seed for future conflicts and software bugs, that can (and will) lead to unhappy developers and broken team productivity in the long run. But it isn't actually too hard to create decision records that are not overly complex or hard to create.
We recently released the stable 1.0.0 release of our prometheus_client package — a way to expose Prometheus metrics in your Dart application. It's inspired by similar packages like the official client_java for Java or the community package prom_client for Node.js. We have several Microservices written in Dart where we use the package to provide observability. I want to share the experience we had while developing the package.
I recently wrote about my indicators that I use while choosing dependencies in the NPM ecosystem. After writing the post I thought, can you automate these steps to provide a quick view on package health? One tool that does that is the Snyk Advisor. I tried the advisor and want to summarize my experience.
In my previous post, I wrote about choosing dependencies wisely. The NPM ecosystem is known for its small packages with a lot of dependencies. You can quickly lose track about your dependency usage. Do you have all dependencies configured correctly? Are all of your dependencies still in use? I want to present you depcheck, a small utility to keep track of your dependency usage.
Open-Source software brings great opportunities through a huge ecosystem of reusable packages. The NPM ecosystem grows by millions of packages each year. With so many packages, there is one for everything! There are central server packages like express, famous UI frameworks like react, widely used build tools like @babel/core, or helpful utilities like lodash. But there are also very specific packages solving niche problems, like a video container format writer based on JSX or an xkcd API client. But not every package is a good pick, often they turn out as a bad choice later on. To avoid regrets when choosing Open-Source dependencies, here are some points to consider.
