Evan X. Merz

What a year.

I remember the year we had our second child, Leta. That was a difficult year. Having a two year old and a newborn in the house was not easy. Ultimately, I failed that test in many ways. I don't think I failed as a father, but I did a lot of damage to myself in order to get through the year.

I changed jobs shortly after Leta was born, but I was never able to succeed at that job. The anxiety from the birth and changing jobs just took over my life. I developed ulcers and other health issues that took me years to beat.

This year was harder. I know I'm not alone when I say that I felt like I was drowning. With the virus ravaging the country and a president who insisted on calling it a hoax or downplaying its effects, it felt like the world was closing in on me.

And that's what produced this album. I wrote it in the first few months of lockdown, when there was much false hope, but no real hope for an end to the unfolding tragedy.

This music differs from most of my other music in many ways. For one, there's only one collaborator on it, unlike my other recent work which has featured many other collaborators. Also, it's much darker. It's a bleak, synthesized hellscape that chokes off the light. It's violent and dark and lonely.

Just like 2020.

I'm proud to say that I didn't fail this year. As the world was melting down around me, I didn't drown. I swam. I was promoted at my job. I took a leadership position in my community. I volunteered at the local library. I made things. And I didn't come out with any new health problems.

But still, the year mostly felt like I was drowning.

Thanks for listening!

Jazz isn't necessarily the first thing you think of, when you think of California. You might think of surfing, Dick Dale, the Golden Gate Bridge, or Hollywood. But California has a rich history in Jazz.

Don't forget that California made Benny Goodman a star, and made swing music into popular music. After the war, dozens of amazing soloists were made in California, including Dexter Gordon, Lester Young, Art Pepper, and Eric Dolphy. Household names like Dick Brubeck, Stan Getz, and Cal Tjader all started their careers in California.

I put together this playlist to celebrate the great jazzers from CA. Listen to the end to catch some more modern artists who stand tall with the rest of these greats.

Due to the air quality, they closed the pool this weekend, so Erin and I didn't know what to do with the girls. It occurred to us that we've never really taken them out to weekend yard sales before. So we looked up a few local yard sales and drove around to each one.

At the Eagles Club rummage sale, I found a storage container full of power tools on one side, and stacks upon stacks of framed prints on the other side. In my head I said, "I bet if I sort through all of this, I will find one piece that is worth taking home."

And boy was I right. Buried under empty frames, and some nice decorative pieces, I found this beautiful Pete Martinez etching.

I didn't know Pete Martinez off the top of my head, but when I saw the etching I knew it was better than all the other stuff in the storage container. It had a reasonable price of $125 on it, but they were selling everything for 75% of, so I got it for a cool $31.

Pete Martinez was actually Pedro Pablo Martinez. He was born in California in 1894, and he worked as a cowboy, ranch hand, and show rider for much of his life. He made his living driving cattle in the summer and creating art in the winter. He fought in the first world war, and retired to his own ranch in later life.

Got lucky today. Found this Pete Martinez print at a yard sale for only $30. Gonna hang it over my desk. pic.twitter.com/616TRyrWQG

— FYNIX (@EvanXMerz) August 22, 2020

Redux is a very simple tool that is very poorly explained. In this article, I will explain Redux in a single sentence that is sorely missing from the Redux documentation.

Redux is a pattern for modifying state using events.

That's it. It's a dedicated event bus for managing application state. Read on for a more detailed explanation, and for a specific explanation of the vocabulary used in Redux.

1. Redux is a design pattern.

The first thing you need to know is that Redux is not really software per se. True, you can download a Redux "library", but this is just a library of convenience functions and definitions. You could implement a Redux architecture without using Redux software.

In this sense, Redux is not like jQuery, or React, or most of the libraries you get from npm or yarn. When you learn Redux, you aren't learning one specific thing, but really just a group of concepts. In computer science, we call concepts like this a design pattern. A design pattern is a group of concepts that simplify an archetypal task (a task that re-occurs in software development). Redux is a design pattern for managing data in a javascript application.

2. Redux is an extension of the Observer Pattern.

I think this is the only bullet point needed to explain Redux to experienced developers.

The observer pattern is the abstract definition of what programmers refer to as events and event listeners. The observer pattern defines a situation where one object is listening to events triggered by another object.

In javascript, we commonly use the observer pattern when we wire up onClick events. When you set up an onClick event, you are saying that an object should listen to an HTML element, and respond when it is clicked. In this scenario, we are usually managing the visual state of the page using events. For example, a switch is clicked and it must respond by changing color.

Redux is a dedicated event bus for managing internal application state using events.

So redux is a way of triggering pre-defined events to modify state in pre-determined ways. This allows us to ensure that state isn't being modified in ad hoc ways and it allows us to examine the history of application state by looking at the sequence of events that led to that state.

3. Actions are event definitions. Reducers are state modifiers.

The new vocabulary used by Redux makes it seem like it's something new, when it's really just a slight twist on existing technology and patterns.

Action = Event definition. Like events in any language, events in Redux have a name and a payload. Events are not active like classes or methods. They are (usually) passive structures that can be contained or transmitted in json.

Reducer = Event listener. A reducer changes application state in response to an action. It's called a Reducer because it literally works like something you would pass to the reduce function.

Dispatch = Trigger event. The dispatch method can be confusing at first, but it is just a way of triggering the event/action. You should think of it like the methods used to trigger exceptions in most languages. After all, exceptions are just another variation on the Observer pattern. So dispatch is like throw in Java or raise in Ruby.

4. Redux manages local state separately from the backend.

Redux is a pattern for managing only the internal state of the application. It does not dictate anything about how you talk to your API, nor does it dictate the way that your internal state should be connected to the backend state.

It's a common mistake to put the backend code directly into the Redux action or reducer. Although this can seem sensible at times, tightly coupling the local application state with backend interactions is dangerous and often undesirable. For instance, a user may toggle a switch three or four times just to see what it does. Usually you want to update local state immediately when they hit the switch, but you only want to update the backend after they have stopped.

Conclusion

Redux is not complex. It is a dedicated event bus for managing local application state. Actions are events. Reducers modify state. That's it. I hope that helps.

Here are a few other useful links:

https://alligator.io/redux/redux-intro/ https://www.tutorialspoint.com/redux/redux_core_concepts.htm https://redux.js.org/introduction/core-concepts/

I was reading the Vue.js documentation recently, and I came across a very compelling little passage. The passage was explaining the thinking behind single file components. In a single file component, the template, javascript logic, and perhaps even styles, are all collocated in the same file.

Putting all the parts of a component into a single file may seem odd to some programmers. After all, shouldn't we be separating logic from templates? Shouldn't we be separating styles from logic too?

And the answer is that the right thing to do is situation dependent, and this is something that a lot of modern programmers don't understand. A lot of programmers seem to think that there are rules, and you must follow the rules. They don't realize that rules should only be followed when they are helping you.

So the core question is this: is separating a single view into several files really helping your development process?

Here's what the Vue documentation says.

One important thing to note is that separation of concerns is not equal to separation of file types. In modern UI development, we have found that instead of dividing the codebase into three huge layers that interweave with one another, it makes much more sense to divide them into loosely-coupled components and compose them. Inside a component, its template, logic and styles are inherently coupled, and collocating them actually makes the component more cohesive and maintainable.

So the argument from the Vue developers is that keeping all the code related to one view inside one file is actually more maintainable than separating them.

I tentatively agree with this.

Obviously, it's good to separate certain things out into their own files. Foundational CSS styles and core JS helper methods should have their own place. But for all the code that makes a component unique, I think it's easiest for developers if that is in one file.

Here are the problems I face with breaking a view into multiple files.

1. What is each file called? Where is it located?

When you separate a view into multiple files, it becomes difficult to find each file. It's fine to have a standard for naming and locating files, but in any large software project, there are going to be situations where the standard can't be followed for one reason or another. Maybe the view was created early in development. Maybe the view is shared. Or maybe the view was created by a trainee developer and the mis-naming was missed in the code review. Whatever the cause, file names and locations can be stumbling blocks.

At my workplace, we have hundreds of templates named item.js.hamlbars. That's not very helpful, but what's more troublesome is when, for whatever reason, a list item couldn't be named item.js.hamlbars. In that case, I'm left searching for files with whatever code words I can guess.

2. Where is the bug?

When you separate a view into multiple files, you don't know where a bug may be coming from. This is especially troublesome if you are in a situation where conditional logic is being put into the templates. Once you have conditional logic in the templates, then you can't know if the bug is in the javascript or in the template itself. Furthermore, it then takes developer time to figure out where to put the fix.

Single File Components are a Bonus

Putting all the code for a single view into a single file is not only logical, but it also doesn't violate the separation-of-concerns ethos. While the pieces are all in the same file, they each have a distinct section. So this isn't the bad old days of web development, where javascript was strewn across a page in any old place. Rather, collocating all the code files for a single view is a way to take away some common development headaches.