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.
Even with fast internet speeds, one key metric for improving initial page load times for websites or web apps is reducing the data transmitted over the wire. While you can optimize all kinds of assets, like styles and images, I want to focus on the size of the JavaScript bundles. Code size has an impact on download duration, but also on parsing and JavaScript execution. This can be measured as Total Blocking Time (TBT) or First Input Delay (FID), a metric suggested by Google to measure page performances as part of the Web Vitals.
I like Firestore because it's an easy-to-use database. Especially because it's easy to build queries that are just fast. It's designed to work at scale - by providing queries that have a constant time, regardless of the query conditions. But if you have worked with Firestore before, you will know that this limits the types of queries you can do. This can make range queries, for example for calendar applications, a challenge.
Creating a UI where a user can manually reorder items based on their needs is neat, but can be quite challenging to implement in the backend. One need to store the order of the items somehow. There are different approaches to doing this, but each of them has trade-offs when it comes to performance and scalability. In this post I want to explain my scenario, compare them, and choose the best implementation.
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.
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.
