I recently helped a team improve the performance of one of their services. They had already invested some time, but over time the performance was getting even worse! Their Node.js service was suffering from slow response times. At some point, the team added performance tracing using performance.mark() and performance.measure() to understand why the response time was so long. Little did they know that this would make things even worse…
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.
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?
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.
If you are using react and test your components (you should!), then you are probably using the Testing Library. Testing helps to be confident that your components work as expected — especially in corner cases that are harder to test manually. The learning curve for a library can be steep, but doesn't have to!