The shuttle project and a PR on github

This week I explored the shuttle crate a bit. It looked pretty promising and I liked the fact that one can quickly scaffold a service and everything that's needed for it. The most remarkable thing is how easy it is to set up a database in a shuttle project directly through code. One only has to specify which kind of database they want to use and the shuttle-runtime automatically spins up a docker container with the desired resources. There are other nice features which I wasn't able to explore yet though.

Since I wanted to craft something with axum and diesel I figured building a small example project in shuttle was perfect. There was just one major issue: shuttle only supported one type (as in type system) of postgres database pool and it's not the diesel one. Out of the box there was only support for sqlx::PgPool. Since it was a good opportunity, I took a look under the hood of shuttle and it didn't appear to be too difficult to create a PR for integration of diesel. So this is what I did here. It was surprisingly easy actually and it worked out of the box, first try. So I have to say: Well done shuttle team! It's a good code base if PRs are that easy.

Just for fun I created a funny (meme-y) little app called todosurfer with their software and deployed it.

Bevy run conditions

I spend a lot of time with a topic close to my professional work this week. I really began to discover the power of bevy 0.10s run conditions. They give us as authors of bevy apps a lot of control over when systems run. I noticed that a lot of code in our work codebase could be refactored in smaller, atomic systems which only do one job. This creates both more clarity when naming and describing what a system does as well as easier to comprehend systems due to less system parameters and less lines of code.

Overall it was a really enjoyable work week and a bliss to work on a new feature, carving out systems which are only as big as they need to be.

Picking good names

This is yet another excerpt from the insightful book A Philosophy of Software Design (Chapter 18)

Let's keep it short and sweet here. Picking good names in software development is one of the two most difficult tasks in the job as the old saying goes. And it's not only included in the saying to make the joke funny or to express how annoying it can be from time to time to pick a name for a variable. It actually matters in software development, because it is another tool to increase what is most needed when creating software: Clean comprehendible designs which are as easy to read as possible.

Good names serve the following purposes:

• make code easier to understand
• make it easier to spot errors
• at times replace the need documentation

Conversely, bad names can:

• increase the complexity of code
• create misunderstandings
• lead to ambiguities which may result in bugs

A few guidelines when choosing names are:

• Create an image in the mind of the reader. If the name is read in isolation without any context, how close does it describe the thing it is there for?
• Names should be precise. E.g. If you use (variable) names like val for a value that's not precise. Try to specify what kind of value it is (temperature_val, height_val, ...). Another example is count. What are you counting?
• The importance of names grows with the scope of the underlying entity. If a variable is used 100 lines after it's definition, it's name should be so comprehendible that a reader doesn't have to scroll back to the definition to find out what it was defined for and what information it holds

Red flags

• If a name is broad enough to refer to many different things at once, then it doesn't convey much information to the software developer and the underlying entity is more likely to be misused
• If it's hard to pick a name for an entity, then that can be a hint that this entity may not have a clean design yet