Evan X. Merz

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.

It's difficult to unpack my feelings about Nils Frahm as an artist. I remember, a few years back, hearing rave reviews about one of his albums. I can't recall which album it was. I listened to it, and it reminded me of the type of "scholarly" music that is being produced at every college music department with an electronic music program in the country. It didn't strike me as anything special.

Then I listened to The Noise Pop Podcast, or maybe it was Switched on Pop, and one of the hosts was overwhelmed by Frahm's 2018 album All Melody. So I listened to that, and I felt about the same.

Maybe it was a sign that I was cynical, jaded, or just plain old. Or maybe Frahm and I went through similar music educations. Maybe he was the most successful version of all the dudes making quiet, semi-ambient electronic music at all the schools I attended. Although, glancing through his wikipedia, I don't see any references to universities. So maybe that isn't the case either.

But as of last year, my general feeling toward Frahm was a qualified "meh."

Still, when I saw he was playing at a club that was walking distance from my house, I had to buy tickets. I invited my friend Brian along, and we caught him at The Ritz in San Jose.

It was at that concert that my feelings toward Frahm changed.

The Ritz is a fantastically intimate venue. It's compact enough to reach out and touch the performer from the front of the audience. It's small enough to only hold maybe two hundred people standing.

Frahm had an absolutely massive setup. He had several antique organs, numerous synthesizers, and enormous old fashioned amps the size of small cars.

But he had no band and there was no opening act. He came out alone. He performed alone, and the show was about him and his music. It was pure, and almost sacred in its tone at first. But as it went on he got more and more loose.

Frahm has a charming on-stage personality. Between each track he talked about his music and his writing process. He opened up his soul a little bit, and opened up about his music a lot. He got more talkative as the show progressed, until by the end he was talking about chord progressions and audience expectations. For people with a little bit of musical training, which I suspect was most of the audience, it was a magical night where we jointly worshipped at the altar of music.

On January 25th, 2019, Frahm released a new EP titled Encores 2. Does it feel like his show? Would his magical show change the way I perceived his music?

No. The album is more slow, quiet sonic meditations that owe a great debt to Brian Eno. It's still an enjoyable album to listen to while at work, or on the train, or perhaps while making dinner.

But if you get the chance, you should definitely catch him live.