Assumptions
As software developers it is our job to test our assumptions. So how do you go about knowing, testing, and rethinking them?
As software developers it is our job to test our assumptions. So how do you go about knowing, testing, and rethinking them?
In my last post, Strategy First, I explored the importance of having principles behind technical strategy. Starting with guiding principles is important, but team members can feel left adrift if they are only left with principles and no specific actions. Will Larson suggests: ...executives are generally directionally correct but specifically
Technical strategy is not about technology choices. It is about the principles we use to guide our technical decisions.
🎓I am working in Kotlin for the first time. I'm using Kotlin examples in this post to get used to the syntax. See a mistake? I'm still learning! You can treat the examples here as pseudo-code. Happy to hear about better ways of doing things. Composition
I was working on a project recently that had a set of tests titled "Benchmark Tests." "Oh, nice," I thought, "someone was thinking about performance when they wrote this." Then I ran the tests and realized that they were testing that the web server&
GraphQL Tools is a powerful library and has a great handbook to get you started. I wrote a workshop to help people build an understanding of the basics of schema stitching. Follow the README in the workshop below and you'll learn how to merge types, stitch queries across
Ah, morning tea. My favourite. Plug the kettle in and get it going. Oh! How about some toast to go with that. Plug the toaster in and pop a nice slice of sour dough bread in. My favourite. 💥 Power goes out. What happened? "The toaster flipped the breaker!"
Subschemas in this project often share types, meaning these types need to be merged into the superschema for the gateway. When these types are merged, we have no easy way of knowing which service each field comes from.
Middleware is a piece of code that mediates the request and response to the application server.
Postgres 11 and higher has a feature called Row Security Policies, or Row-Level Security, which is a great feature for restricting access to rows in a tabel on a per-user basis. However, if you’re not careful, you can drag down performance with a bad policy. The post below comes
One day in your coding journey you might run into a linting error like this: RSpec/MessageChain: Avoid stubbing using receive_message_chain Uh, oh. What happened here? This is the Ruby community's best effort at enforcing The Law of Demeter. While this linting rule doesn't
Have you ever opened up a file in an older piece of software and seen this? # rubocop:ignore Metrics/CyclomaticComplexity def complex_method(x, y, z) if x > 0 if y > 0 if z > 0 return "All positive" else return "z is not positive&