In Access Denied, I wrote about how I almost never create public getters and setters for my objects. When I decide that an accessor is necessary, I do everything I can to avoid using the get and set prefixes for them.

Several weeks ago, I wrote about Globalizing Redux Selectors. At the end of the post, I showed an implementation using Ramda that works for selectors taking any number of arguments. I later discovered that the solution doesn’t allow globalized selectors to be called as curried functions. Let’s fix that.

When we’re writing automated tests for our code, it’s easy to accidentally write a test that says exactly the same thing as the code does. This kind of test is a “tautological test”, and it’s important to watch out for them.

Sometimes it’s nice to be able to visualize the dependency structure of an application or a set of packages. I recently had a need to do this in two different contexts and found a way to automate the generation of a diagram using a few handy tools.

When developing software, we’ll sometimes need to replace some code with something that can do the same job in a different way. There are several ways to do this, but one of the safest is The True Lies Pattern.

In a recent post, Modular Reducers and Selectors, we ended up with each module exporting localized versions of its selectors by name, and an object containing the globalized versions of the selectors as the default export. In that post, we wrote the globalized selector by hand. However, it can be helpful to write a generic utility function that globalizes the selectors for us.

If you’ve been using Redux for long, you’ve probably used its combineReducers function to create your application’s root reducer. But you may not have thought of using it in your sub-reducers as well. Let’s see how we can take advantage of combineReducers to simplify our code.

I recently took a trip with my wife to celebrate our 25th anniversary. This trip gave us time to reflect on our marriage and our relationship. We talked about what’s working and what we need to improve. From this background context, I started applying these ideas and discussions to the software I build.

I’ve just returned from an 11-day getaway with my wife to celebrate our recent 25th anniversary, so I don’t have a normal post this week. Instead, I have a follow-up to my recent post, Learning as a Team.

I’ve been using git for version control for several years now. While I’m comfortable using it from the command line, there are times when it’s handy to have a GUI tool available. My current tool of choice is the GitHub Desktop app.