STEAM for Kids Week 2: Across the River

In our first session, we build bridges to help the kids across The Austen Gorge. This week, we are building boats to get them across Tolkein River. Once again we will learn a little bit about boats in history then construct our own boats out of paper. Finally, we will test them in the water to discover how well they perform.

Here are the resources to help you run this activity at home with your kids.

STEAM for Kids Week 2 Coloring Page

STEAM for Kids Week 2 Instructions

STEAM for Kids Week 1: Across the Gorge

If you are coming here from the online STEAM program I am running through Willow Glen Public Library, then you may be looking for the extra documents from week 1. This includes a coloring page for kids to make their own paper puppets of Fred and Marian, and the first part of the treasure map. It also includes instructions for parents who want to pursue this activity at another time.

I know we’re all struggling to find educational opportunities at this time. I hope this helps.

There’s a long waiting list for the classes we’re running, and we hope to run more sessions to open them up to more people.

STEAM for Kids Week 1 Coloring Page

STEAM for Kids Week 1 Instructions

Also, for older kids, here are some documents to help parents talk about the physics of bridges.

Forces acting on different types of bridges

BUILDING BIG: Bridge Basics

Easy Transcriptions of Frozen II Songs Into the Unknown and Some Things Never Change

As I write this, the official sheet music for Frozen II is not yet available, but my daughters want to sing songs from Frozen II in their upcoming recital. So I transcribed their choices into a format that is easy for a single vocalist, and easy for me to play. I am sharing them here just in case this helps anyone else.

Notes

  • I did not transcribe the melodies. I play those by ear where necessary.
  • I removed key changes.
  • I transposed Into the Unknown down 3 half-steps to C-minor. It’s still very high.
  • I removed the interludes for other characters and for the chorus.
  • I don’t know if I got the modulation-heavy outro to Into the Unknown quite right in a different key, but it’s pretty close.

Into the Unknown: Frozen2_IntoTheUnknown

Some Things Never Change: Frozen2_SomeThingsNeverChange

Redux Explained in One Simple Sentence

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:

Single File Components are Good

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.

Don’t Use Amazon’s Forks of Open Source Software

This is a warning. Amazon’s forks of open source software are very poorly supported. If you switch to them, you will create problems for yourself. Here’s my three examples from personal experience.

Amazon Aurora

Amazon Aurora is attractive because it’s compatible with PostGreSQL and MySQL, and it is ready for sharding out-of-the-box. Don’t get sucked in though. The deploy and patching process is a poorly supported nightmare.

Recently, Amazon told us we had to have a forced upgrade patch on our Aurora instance. We don’t do downtime. Ever. But Amazon doesn’t provide a no-downtime version of the patch, and the alternative was too much of a time investment.

Amazon guaranteed us the deploy would only take 3minutes. So we decided to go forward with a little but of downtime. The first time it tried to patch it failed and took the database down for 10 minutes. Then it sat there for 15 minutes during which we could do nothing. Then it tried to patch again, taking the database down for another 10 minutes. And it failed again.

So at that point we were frantically calling Amazon support to try to stop it, but we couldn’t get through to anyone who was at all helpful. So the database went down a third time, and this time, fortunately, it worked.

All told, we had about an hour of downtime after Amazon guaranteed us only 3 minutes. The support was unhelpful, and didn’t really know how to help.

Amazon Linux

Do not use Amazon Linux. If that article isn’t enough to convince you, then here’s my story.

I like to try new technologies. I like to keep up to date with the latest thing. I use AWS in my every day job. So when Amazon started pushing their own version of Linux, I decided to try it on my personal website.

The major headache this has created for me is that the Lets Encrypt Certbot doesn’t work on Amazon Linux. So I can’t do automatic renewal of my SSL certificate. I have to step through the process manually each month.

But there are many other tools and packages that are incompatible too. Don’t use it.

Amazon’s Android

Amazon’s version of Android is awful for the same reasons. It’s extremely poorly maintained.

I loved the first Kindle device. It was perfect. It reduced waste, and allowed me to carry a library around with me. So I bought the initial devices, then carried on into the Kindle Fire and other tablets. That’s when the trouble began.

There are major bugs and performance issues on Amazon’s version of Android that have gone unaddressed for years.

The bug that caused me to switch to a Samsung tablet is one where, when I clicked on my most recent media item, it wouldn’t actually open my most recent item. So, for instance, if you are watching a show or reading a book, or switching between two things, then you are constantly opening the wrong thing. Because the performance is so poor, this is a problem that often takes minutes to resolve by clicking around and hoping it opens the correct item.

That seems like a critical bug to me. It should be one that gets fixed immediately, right? Well it existed for years.

Don’t Use Amazon’s Forks of Open Source Software

Don’t do it. That one feature they add isn’t worth it. Use the open source alternative.

Encores 2 by Nils Frahm, and the Joy of Live Music

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.

Remember Nina Simone

I recently read But What If We’re Wrong?: Thinking About the Present As If It Were the Past by Chuck Klosterman. The premise of the book is to predict the future by looking at how past predictions were wrong, and how they could have been right. As usual Chuck Klosterman takes on sports and culture, with some random asides about The Real World.

The most compelling section was where he tried to predict the future of Rock. He looked back at music of the past, pointing out that most people remember one person from each era of music. So most people know Bach from the baroque, Mozart from the classical, and Beethoven from the romantic era. He made the interesting point that surviving history is about being recognized by people who know nothing about the subject, rather than by people who are specialists. Specialists can name several playwrights from the 1500s, for example, but most of us can only name Shakespeare.

In the domain of rock, he said The Beatles are the logical choice to represent rock music. Still, he pointed out that it’s easier to remember a single individual whose story relates to the art itself. So Bob Dylan or Elvis Presley might emerge rather than The Beatles. Then he pointed to arguments for various rock musicians and why they might turn out to be true.

It was all very interesting, but it just got me thinking about jazz. In one hundred years, who might emerge to represent all of jazz?

Nina Simone at the piano

The obvious choice is Duke Ellington. His career spanned most of jazz, even though he retained his own distinct style throughout. He was influential as both a composer and a band leader.

Another choice might be Louis Armstrong. He invented the jazz solo as we know it today, and he performed a few of the most popular jazz tracks ever recorded.

After them, the waters get more murky. Benny Goodman made jazz popular music. Miles Davis sold more records than even Louis Armstrong. Marian McPartland brought jazz into the home long after most people had given up on it. Heck, maybe Johnny Costa will be remembered for his role as the music director of Mr. Rogers Neighborhood.

I think that it will probably be a composer. Prior to the late 19th century, the only recorded history of music was written down on paper. This is why we remember Mozart the composer, rather than the people who performed his music. We still tend to think people who write music are more important than people who perform it, even when we have recordings of great performers. That’s a big reason why it will probably be Duke Ellington who is ultimately remembered.

But this strikes me as wrong. Jazz is the first music that is truly a recorded music throughout its entire history. If humanity is around in one hundred years, then jazz recordings will still exist. So couldn’t it, perhaps, be the greatest performer who survives?

Also the focus of jazz is on the improviser. Jazz is a kind of folk music, where the performer subjugates the composition to his own interpretation. So perhaps the greatest interpreter of jazz will be remembered.

In either case, it has to be Nina Simone. No other performer expressed the full range of human emotions in a single performance. Even Louis Armstrong tended toward jubilation in his performances. He never reached the depths that Nina Simone explored in I Loves You Porgy or Willow Weep for Me.

There are two arguments against Nina Simone. First, that she was closer to a pop singer than a jazz singer. Second, that she isn’t known for her compositions.

Nina Simone wasn’t a pop singer. That’s what we would call her today because her category no longer exists. She was a cabaret singer. When she was unfairly rejected for a scholarship to study classical piano at The Curtis Institute in Philadelphia, she supported herself by playing popular music in bars and restaurants. She would sing and play whatever songs were on the radio. It was a very demanding job, and playing those songs night after night is what molded her into the greatest interpreter both as a vocalist and a pianist.

To the second objection, that she isn’t remembered for her compositions, I can only point to her unforgettable performance of Mississippi Goddamn, a composition of her own. With a cheerful piano accompaniment, and a melody that pushes the piece forward, she managed to write and perform a song that defines courage. The music is a beautiful, confident show tune that carries lyrics about one of the worst tragedies in American history. The effect is a better expression of the black experience in this country than any other performance in jazz.

So please, remember Nina Simone.

Here’s my playlist of Nina Simone’s best tracks to help her cause.

2018: The Year of the EP!

Well, the full length album is dead. It lived a long and brilliant life. Highlights included work from The Beatles, Pink Floyd, Joanna Newsom, Popol Vuh, AC/DC, and Galantis. But the fact is that nobody is listening to full length albums in 2018.

People are listening to playlists on Spotify, which are often made up mostly of singles from disparate artists. With the exception of the one percent of hardcore music listeners, nobody has the patience to listen to a full length album of music. Even the real music fans I know, who go to concerts with me several times a month, do not listen to full length albums.

But people do want more than singles.

So in 2018, we witnessed the explosion of a form that has come to be called “The EP”. It’s an extremely history-laden name for a short collection of music. An EP usually lasts at least ten minutes, and includes no more than seven individual tracks.

For me, personally, it’s what I listened to most in 2018. When I was listening to Discover Weekly and Release Radar on Spotify, I was seeking out experiences that were more than just a single piece of music, but an hour was usually too much music, even for me.

This is a format that works really well for indie musicians. It’s hard to write an hour of cohesive music that is strong from beginning to end. It’s much easier to write ten to twenty minutes of strong, cohesive music. And each EP can be different. EPs allow artists to explore more than singles or full length albums.

So here’s a playlist I made that consists of tracks from EPs I liked this year. It’s mostly indie electronic music, but there’s some Hip-Hop in there as well and a few tracks by well established artists.

Thanks for listening!