If someone were to ask you who the consumer of your service/app/program/whatever I’m sure you would have a clear answer (or at least I hope you know exactly who the consumer is) but have you ever thought about who is the consumer of the actual code you’re writing and the repository that it lives in? This is something that I think most developers don’t ever really consider until they’re just starting on a new code base and have complaints about the documentation or build process.
At some point in the software development lifecycle you’re going to find yourself writing tests (we’re gonna gloss over the TDD debate) and these tests almost always need test data of some sort. Most developers that I’ve worked with tend to go for the tried and true method of just hard coding the data that they need either right in the test code itself or in a separate data file that gets included or read in during the test.
Edit (2023-003-12) This is now a feature that is built into VS Code: https://code.visualstudio.com/docs/editor/profiles
Recently I decided I wanted to try and split up my Visual Studio Code environment between how I want to write code for work and how I want to write code for pleasure. Examples of why this is useful are:
I can enable features that wouldn’t be safe for work (like Github Copilot) I can have my work configuration synced to a different location than my personal settings I can experiment and be willing to break my personal code environment without impairing my work environment What’s the game plan?
This is a pretty simple blog post tackling a problem I’ve seen a few times on React projects. There are quite a few ways of tackling it (Redux for example) but this is a simple, no dependency option. I’m also going to point out what should be obvious, the code here is just example code and is missing lots of things production code would have. All that aside, on to what the problem actually is!
Recently I started work on redoing all my dotfiles in preparation for setting up my new desktop computer. I wanted everything to be slick, streamlined, automated, and simple. Things are so far looking much better than they were before. I have documentation on how to get things setup and I have Ansible playbooks for setting things up in a repeatable way. One of the frustrating things though is that setting up Ansible requires having some kind of Python installation on the host.
Containerized applications are becoming more and more common in production applications of all sorts. They are significantly easier to deploy, provide better repeatability, and can offer some security benefits over other deployment options. One thing I’ve noticed from working with other developers, is that many people don’t know how to create good container images. The biggest problem here is that you have to have a basic understanding of what happens when creating images and understand what the goals are with containerizing.
From time to time I like to go back to the fundamentals and play around with basic concepts. This serves to keep myself sharp as well as provide an opportunity to explore some concepts in greater detail than what I was able to do previously. I was doing that recently with an implementation of an immutable list in JavaScript (similar to what you would find in immutablejs). Things were going well enough with my super basic implementation when I started thinking about how you would hide implementation details and how you could implement an iterator for my list data structure.
The Continuation… In a previous episode we looked at a way to solve the problem of running multiple services that might need to talk to each other in a sane way. The solution was to run each service in a Docker container and to put any container from the service that you want exposed on a common network that is accessible via a proxy service. We also came up with a list of three possible proxy services to use and tested them out (as well as we could at the time anyway) and decided on two options to continue experimenting with.
