DEV Community: Steve Brownlee

I am a Software Bootcamp Instructor, Ask Me Anything!

Steve Brownlee — Sun, 29 Sep 2019 23:00:52 +0000

I have been a coach for over 4.5 years now. I've been personally responsible for 17 different cohorts of students, run innumerable experiments, and learned countless lessons about the human mind, technology for beginners, and teaching.

If you are thinking of attending a bootcamp, considering instruction, or are an instructor, ask me anything!

React is finally JavaScript

Steve Brownlee — Sun, 29 Sep 2019 22:31:57 +0000

"Classes are the future of JavaScript because of React."

I heard this many times over the last few years, and I remained highly dubious because, I believed, use of classes in JavaScript was perfectly fine... until you understood JavaScript. Once you do that, using classes becomes clunky, uncomfortable, and awkward.

Finally, the voices of reason and "hey, let's use JavaScript the way it was intended" have been heard.

Hooks is functional composition well executed, and I finally feel comfortable using React.

When I'm in C#, I use classes/interfaces in a composition-based architecture because it's what the language is intended to be based on, and I love it.

When I'm in JavaScript, I use functions in a composition-based architecture because it's what the language is intended to be based on, and I love it.

Finding Love While Coding

Steve Brownlee — Sat, 29 Sep 2018 22:45:20 +0000

Tomorrow, I get to give short toast to two students that I taught at Nashville Software School. The groom 🎩 was in cohort 12. The bride 👰 in cohort 13. It all began when cohort 12 was presenting their client side capstone projects to cohort 13 on their first day at the school.

The future bride saw her future groom presenting his project and thought to herself, "That's the best looking guy in that class."

Two years later, they are getting married at the exact spot he was standing during that presentation. I think it's extremely cool. I'm honored to be a small part of their day, because I still consider them friends, and apparently I had just enough good moments when I was teaching them that they want to hear me talk at them one more time. 😄😄😄

I teach the vocation of software development to hundreds of people each year, Ask Me Anything!

Steve Brownlee — Sun, 09 Sep 2018 04:00:24 +0000

C# Generics and Delegates: A Simple but Real Example

Steve Brownlee — Mon, 03 Sep 2018 21:19:50 +0000

Originally published at Steve Brownlee

If you search for information about the C# Generics language feature, you see the same abstract code examples about making your own RedundantList<T> (but don't do this, it's just our example) over and over again. It's remarkably difficult to find content where someone shows how they actually used it to make their code more reusable.

Well, the topic of Generics came up in a discussion this week with my students in Day Cohort 26 of Nashville Software School so I went looking and realized that most of the content is unusable for a student. Of course, the purpose and usage of Generics is largely beyond the capabilities of a student with 4 months of development experience to understand, but I wanted show them why they are used with a straightforward example.

I've been using a simple CLI app to teach them the basics of the language syntax, LINQ, classes, OOP, and SQL. I'm just about to connect the dots for them by using Dapper ORM to query a small SQLite database.

In order to create the tables, and seed them with initial data, so that they can practice SQL, I created a DatabaseInterface.cs file with a series of static methods in it to perform those tasks.

Data/DatabaseInterface.cs

...

/*
    Purpose: Check the database to see if the `Exercise` table 
    has been defined. If not, create it and seed it.
*/
public static void CheckExerciseTable()
{
    SqliteConnection db = DatabaseInterface.Connection;

    try
    {
        // Select the ids from the table to see if it exists
        IEnumerable<Exercise> exercises = db.Query<Exercise>
            ("SELECT Id FROM Exercise");
    }
    catch (System.Exception ex)
    {
        /*
            If an exception was thrown with the text "no such table"
            then the table doesn't exist. Execute a CREATE TABLE
            statement to create it.
        */
        if (ex.Message.Contains("no such table"))
        {
            db.Execute(@"CREATE TABLE Exercise (
                `Id`    INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
                `Name`  TEXT NOT NULL,
                `Language` TEXT NOT NULL
            )");

            /*
                Seed the table with some initial entries
            */
            db.Execute(@"INSERT INTO Exercise
                VALUES (null, 'ChickenMonkey', 'JavaScript')");
            db.Execute(@"INSERT INTO Exercise
                VALUES (null, 'Overly Excited', 'JavaScript')");
            db.Execute(@"INSERT INTO Exercise
                VALUES (null, 'Boy Bands & Vegetables', 'JavaScript')");

        }
    }
}

...

I continue to do this for each table that I want in my database. For example, I then check the Instructors table.

Data/DatabaseInterface.cs

...

public static void CheckInstructorsTable()
{
    SqliteConnection db = DatabaseInterface.Connection;

    try
    {
        IEnumerable<Instructor> instructors = db.Query<Instructor>
            ("SELECT Id FROM Instructor");
    }
    catch (System.Exception ex)
    {
        if (ex.Message.Contains("no such table"))
        {
            db.Execute($@"CREATE TABLE Instructor (
                `Id`          INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
                `FirstName`   TEXT NOT NULL,
                `LastName`    TEXT NOT NULL,
                `SlackHandle` TEXT NOT NULL,
                `Specialty`   TEXT,
                `CohortId`    INTEGER NOT NULL,
                FOREIGN KEY(`CohortId`) REFERENCES `Cohort`(`Id`)
            )");

            db.Execute($@"INSERT INTO Instructor
                SELECT null,
                        'Steve',
                        'Brownlee',
                        '@coach',
                        'Dad jokes',
                        c.Id
                FROM Cohort c WHERE c.Name = 'Evening Cohort 1'
            ");

            db.Execute($@"INSERT INTO Instructor
                SELECT null,
                        'Joe',
                        'Shepherd',
                        '@joes',
                        'Analogies',
                        c.Id
                FROM Cohort c WHERE c.Name = 'Day Cohort 13'
            ");

            db.Execute($@"INSERT INTO Instructor
                SELECT null,
                        'Jisie',
                        'David',
                        '@jisie',
                        'Student success',
                        c.Id
                FROM Cohort c WHERE c.Name = 'Day Cohort 21'
            ");


            db.Execute($@"INSERT INTO Instructor
                SELECT null,
                        'Emily',
                        'Lemmon',
                        '@emlem',
                        'Memes',
                        c.Id
                FROM Cohort c WHERE c.Name = 'Day Cohort 21'
            ");
        }
    }
}

...

There are a total of five tables that I create and seed.

Instructor
Student
Exercise
Cohort
StudentExercise

That's five methods that all do the exact same thing, but just work against a different resource. To make the code more reusable, I went through a three step process.

Step 1: Create and Seed Static Methods

The first step was to move the commands for creating a table, and seeding the table, to static methods on the database models. This helps me implement the Single Responsibiliy Principle. Otherwise, the DatabaseInterface class has myriad reasons to change.

/Models/Exercise.cs

using System.Collections.Generic;
using Dapper;
using Microsoft.Data.Sqlite;

namespace nss.Data.Models
{
    public class Exercise
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string Language { get; set; }
        public List<Student> AssignedStudents { get; set; }

        public static void Create(SqliteConnection db)
        {
            db.Execute(@"CREATE TABLE Exercise (
                        `Id`       INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
                        `Name`     TEXT NOT NULL,
                        `Language` TEXT NOT NULL
                    )");
        }

        public static void Seed(SqliteConnection db)
        {
            db.Execute(@"INSERT INTO Exercise
                        VALUES (null, 'ChickenMonkey', 'JavaScript')");
            db.Execute(@"INSERT INTO Exercise
                        VALUES (null, 'Overly Excited', 'JavaScript')");
            db.Execute(@"INSERT INTO Exercise
                        VALUES (null, 'Boy Bands & Vegetables', 'JavaScript')");
        }

    }

}

This makes the CheckExerciseTable() method in the DatabaseInterface class cleaner and the application is more modular.

Data/DatabaseInterface.cs

...

public static void CheckExerciseTable()
{
    SqliteConnection db = DatabaseInterface.Connection;

    try
    {
        // This part still tightly coupled to Exercise type  :(
        IEnumerable<Exercise> exercises = db.Query<Exercise>
            ("SELECT Id FROM Exercise");
    }
    catch (System.Exception ex)
    {
        if (ex.Message.Contains("no such table"))
        {
            // Et voilà... Very cleaner! Much modular!  :)
            Exercise.Create(db);
            Exercise.Seed(db);
        }
    }
}

...

Step 2: Generic CheckTable Method

Next, I started the process of making a single method that would check for any table's existence, and create/seed it if needed.

public static void CheckTable<T>()
{
    SqliteConnection db = DatabaseInterface.Connection;

    try
    {
        // Coupling to Exercise type eliminated, but SQL still coupled  :(
        IEnumerable<T> exercises = db.Query<T>("SELECT Id FROM Exercise");
    }
    catch (System.Exception ex)
    {
        if (ex.Message.Contains("no such table"))
        {
            // Made it modular, but still coupled to Exercise type  :(
            Exercise.Create(db);
            Exercise.Seed(db);
        }
    }
}

By using the T generic type, I can now invoke the method and use the specified type for the List of results and the Dapper Query method.

Program.cs

DatabaseInterface.CheckTable<Exercise>();

My SQL statement is still querying the Exercise table, so I needed to pass the table name in as a parameter to make this method reusable. Then I refactored the SQL statement to use the parameter.

// When invoked with the code above, T = Exercise
public static void CheckTable<T>(string table)
{
    SqliteConnection db = DatabaseInterface.Connection;

    try
    {
        // More generic! Coupling eliminated here!  :)
        IEnumerable<T> resources = db.Query<T>($"SELECT Id FROM {table}");
    }
    catch (System.Exception ex)
    {
        if (ex.Message.Contains("no such table"))
        {
            // Still tightly coupled to Exercise type  :(
            Exercise.Create(db);
            Exercise.Seed(db);
        }
    }
}

Step 3: Action Delegates to Create and Seed

The last part that needs to be reusable is invoking the Create() and Seed() static methods on the appropriate type. Unfortunately, it is illegal in C# to invoke a static method on a generic type.

// T represents the type used (i.e. Student, Exercise, etc.)
T.Create(db);  // Illegal. Much sad.
T.Seed(db);    // Also illegal. Still frown.

The only other option I could think of in this situation is making a delegate; specifically, an Action delegate. Why?

Encapsulates a method that has a single parameter and does not return a value.

That perfectly describes the Create() and Seed() static methods that I have on the data models.

// Hey, look! This method has a single parameter and is void
public static void Create(SqliteConnection db)
{
    db.Execute(@"CREATE TABLE Exercise (
        `Id`       INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
        `Name`     TEXT NOT NULL,
        `Language` TEXT NOT NULL
    )");
}

What this mechanism will allow me to do is pass the reference to the correct static method to the CheckTable<T> method. Take a look.

public static void CheckTable<T>(
    string table,
    Action<SqliteConnection> create,  // <-- Delegate to the correct `Create()`
    Action<SqliteConnection> seed     // <-- Delegate to the correct `Seed()`
)
{
    SqliteConnection db = DatabaseInterface.Connection;

    try
    {
        IEnumerable<T> resources = db.Query<T>($"SELECT Id FROM {table}");
    }
    catch (System.Exception ex)
    {
        if (ex.Message.Contains("no such table"))
        {
            create(db);  // Invoke the Create() reference
            seed(db);    // Invoke the Seed() reference
        }
    }
}

Now I can use the CheckTable<T>() method to verify, create, and seed any database table that I want to use. I pass in the following parameters.

A string holding the name of the table I want to use in the SQL
A reference to a static Create() method on the corresponding class
A reference to a static Seed() method on the corresponding class

DatabaseInterface.CheckTable<Exercise>("Exercise", Exercise.Create, Exercise.Seed);
DatabaseInterface.CheckTable<Cohort>("Cohort", Cohort.Create, Cohort.Seed);
DatabaseInterface.CheckTable<Instructor>("Instructor", Instructor.Create, Instructor.Seed);
DatabaseInterface.CheckTable<Student>("Student", Student.Create, Student.Seed);
DatabaseInterface.CheckTable<StudentExercise>("StudentExercise", StudentExercise.Create, StudentExercise.Seed);

Simple and Real

No discussion about obscure data structures that nearly no one will ever use in their daily work. No abstract example code that doesn't convey any real value to a developer. Just a simple example of a real application used to train junior developers in the usage of C# and SQL, and how to use Generics to make the code reusable, and easier to read/maintain.

🍴Fork on Github: https://github.com/nss-day-cohort-26/student-exercises/tree/dapper-sql-advanced

React View Switching with Custom Events

Steve Brownlee — Sun, 19 Aug 2018 04:34:01 +0000

Originally published on stevebrownlee.com.

In my discussions with people in the Nashville community, I discovered that most teams are using some form of routing package that listens to URL changes to trigger view rendering. Because of this, we show students how to do view switching with the react-router-dom package.

Some don't use URL routing. Not every Single Page Application needs it.

While I've been playing around with React, slowly building up techniques for proper instruction to our students at Nashville Software School, I've tried my hand at several different mechanisms for view switching. Last night, while I was using the CustomEvent() constructor in another JavaScript project, a 💡 went off!

Instead of defining a function in the Matriarch component (that's what I call the component in every app that maintains application state) whose reference gets passed around, why not just listen for an event? Then any component that needs to switch the view based on user gesture, or other event, can simply dispatch an event with a data payload. The payload is optional, and contains any data the next view may need to do its job.

ViewManager

I created a simple module in my app whose responsibility is twofold - set up an event listener on a DOM element, and provide the ability to dispatch a custom event.

src/modules/ViewManager.js

const ViewManager = Object.create(null, {
    init: {
        value: function (selector, eventName, fn) {
            this.eventName = eventName
            this.element = document.querySelector(selector)
            this.element.addEventListener(this.eventName, fn)
        }
    },
    broadcast: {
        value: function (view, payload) {
            this.element.dispatchEvent(
                new CustomEvent(this.eventName, {
                    detail: {
                        view: view,
                        payload: payload
                    }
                })
            )
        }
    }
})

export default ViewManager

Main Application

In React, the main component is defaulted to App.js when using create-react-app. Your main component may be something else.

In the constructor, the ViewManager is initialzed with three things:

The DOM element where the event listener will be attached.
The name of the custom event that will be broadcasted.
The local function reference to handle the event.

src/App.js

import React, { Component } from "react"
import ViewManager from "./modules/ViewManager"


class App extends Component {
    constructor(props) {
        super(props)

        // Initialize ViewManager for switching main view
        ViewManager.init("#root", "changeView", this.switch)
    }

    switch = event => {
        const _viewProps = Object.assign({
            notifications: notes,
            exampleAdditionalInfo: localStorage.getItem("preferences")
        }, event.detail.payload)

        // Update state to trigger the view change
        this.setState({
            currentView: event.detail.view,
            viewProps: _viewProps
        })
    }

    ...

    // Returns a component to be rendered in the JSX below
    ShowView = () => {
        switch (this.state.currentView) {
            case "profile":
                return <Profile {...this.state.viewProps} />
            case "results":
                return <SearchResults {...this.state.viewProps} />
            case "home":
            default:
                return <Home {...this.state.viewProps} />
        }
    }

    render() {
        return (
            <React.Fragment>
                <NavBar {...this.state.viewProps} />

                {this.ShowView()}
            </React.Fragment>
        )
    }
}

Any Component

Any component can now import ViewManager and use the broadcast() method to trigger a view change. In this stripped down component, when the user clicks on a View Profile hyperlink, a custom event is dispatched and the App component's listener triggers and switches the view.

src/search/SearchResults.js

import React, { Component } from "react"
import ViewManager from "../modules/ViewManager"

export default (props) => (
    <div className="searchResults">
        props.foundItems.users.map(user =>
            <a href="#" 
                className="btn btn-outline-success"
                onClick={() => {
                    // Switch to profile view with a data payload
                    ViewManager.broadcast("profile", {userId: user.id})
                }}
                >View profile</a>
        )
    </div>
)

Building Teams that Learn

Steve Brownlee — Mon, 13 Aug 2018 04:23:25 +0000

Originally posted on stevebrownlee.com

There are many subtle things that go into being an instructor on our team. If you look at our courses on Github (which are open source), you only get the what of the entire experience. It's simply a listing of what we teach and the order in which we do it. That's about 20% of the entire experience.

A critical part of our course that isn't recorded anywhere is the group project experience. These projects are the forging fire of student knowledge and understanding. It doesn't come from the instruction staff. We just light the fire, and the students make the steel.

We will never achieve perfection, but we must constantly strive for it, else we end up settling for mediocrity.

Some Raw Data

One of the questions on our course feedback form is, "What aspects of this course were most useful or valuable for your learning?"

185 responses out of 412 mentioned the group projects. That's 45% of alumni who responded who explicitly state that group projects were the most beneficial part of the course. If I account for the fact that some students felt that way, but didn't mention it, I believe the number would easily be over 50%.

How we construct groups has been a long, sometimes painful, journey of discovering what does and does not work in a team. Before I get into our methodology, I want to share some of the anonymous feedback that we've received over the years from students about the group projects.

Some students felt that groups comprised of people where the delta of understanding was very small were not beneficial. It was never clear on why they felt this, but we have our educated guesses.

"Also, eliminate building super groups composed of the top students in the class."

"Less performant groups are a great learning experience, but I would have liked the opportunity to see if I could play at a higher level as well, and for there to be more transparency about the metrics that go into making those decisions."

"I already said this, but I really think we could all benefit from a mix of small delta and higher delta groups."

Some students offered concrete advice on how groups should be constructed based on their own experiences, albeit not in the learning environment.

"Every group needs to have at least 4 students: a highly-skilled leader, two middle-skilled students, and one lower-skilled student - and each should have a specific job. Always. Forever. The end. Yes, this places a lot of stress on the highly-skilled leader but again, tough."

"I often wondered why formal groups weren't put together with the people we were naturally working with anyway, or why we couldn't choose our groups for at least one project."

There were students who enjoyed their group experiences. Even if the strategies were a mystery.

"The group work is great. Definitely where I got the most practical experience."

"The group projects and sprints in back-end were helpful. It was great being in a group with the same people so we could put the retros to use."

"I think we all learn a ton on group projects. I've also learned a ton from practicing the exercises on my own. I can tell y'all have spent a lot of time planning out your curriculum, and I think you've done a great job."

"I don't know what the staff's strategy was like when they were making groups for group projects, but I always felt like I was being put with new people to challenge me both as a developer and a person in a group."

For some students, it was imperative that the group environment did not interfere with their own learner experience. If the experience caused any kind of conflict, or some members of the team didn't contribute equitably, then some students felt it took time away from learning in order to help another teammate.

"We had phenomenal coders and individuals on our team. However, we had one person on our team who was not as up to speed as the rest of us. If you were fast, you would gain more experience with the projects than the slow members."

"It's much more difficult to learn a programming language than it is to learn how to work in groups, or to adapt to a specific workflow. We should not be spending that much time working in groups and experience the agile methodology."

Cutting Through the Noise

The absolute worst possible group environment is a multi-layered team, with a large delta in understanding. It is an absolute disaster.

With all of these different interests, different opinions, and different motivations, we had to find a way that served the objectives of the group project: accelerated learning, and development team dynamics. Software development teams have specialized tools and processes that students must become familiar with quickly so that they can be proficient on day 1 when they get jobs. Students must know how to appropriately communicate with each other in the cadence of building an application together.

What Works

What we have found to work, through much trial and error, is when teams are constructed with small deltas of understanding. When teammates are generally around the same level of knowledge and understanding of the concepts being learned and have the same current ability to research and apply new knowledge, then the learning objectives are achieved with efficiency.

There are some subtle flavors to this recipe as well.

If the learning objectives for the group project are few and/or closely related, then having very small deltas provide the best possible experience. Everyone can move at the same, relative speed throughout the project and overall understanding is achieved the vast majority of times. These group projects last 1-2 days.

If the learning objectives are many, or are not closely related, then slightly broadening the delta works better. Since these groups projects take longer (3-5 days), bringing people who can learn, teach, and grow with each other as they explore the concepts more deliberately increases understanding.

What Doesn't Work

The absolute worst possible learning environment for our group projects is the configuration suggested by one of our students above - a multi-layered team consisting of one student with high understanding and an abstract mind, mixed with a few with lower understanding, and one or two that need considerable help, time, and mentorship to gain basic understanding.

It is an absolute disaster.

The students who want to move quickly get nothing done because their time is completely consumed by teaching fundamental concepts to their teammates. They don't actually get to spend time increasing their own knowledge on the concepts.

The students who require help likewise achieve nothing because significant time gets consumed on increasing understanding on more fundamental concepts, rather than the objectives of the current project. They are thrilled to have direct access to someone who can help them, so the distractions from the learning objectives keep piling up because their questions are myriad.

Why Some Students Don't Like the Small Deltas

One teammate had personally received feedback from some students about their feelings when they see a team comprised of people who all clearly understand the concepts more than the rest of their peers.

"I think a fair number of them don't actually want to be in the "supergroup" (although obviously, some do) -- it's more that the super group draws attention to the fact that the high flyers exist. One student said they imagined the high-flying group was "breezing through it" (not true) after seeing their finished product, which made them feel worse about their own process."

Another teammate offered more feedback from listening to other students.

"The context is typically 1) that it is clear that there is an ‘A’ team, making the rest ‘dud’ teams in their minds 2) that it is an odd allocation of resources, as though a company had development teams were comprised of all juniors and others with all seniors 3) that it actually portrays that human fear that people are judging you and putting you in a box because of your limitations (or perceived limitations)."

It does seem counterintuitive given most people's experiences in their lives with groups. However, our focus has to be on giving learners the best environment for learning. Not for getting the most work done. Not for ensuring a misguided sense of fairness.

Maximum learning is our objective.

Mindset

Given this feedback, then it's clear that some students are being completely overwhelmed by their fixed mindset, and that we must continue to help students attain a growth mindset. Students in a growth mindset see everything as a learning opportunity and applaud their teammates for their successes.

Conversely, one of the common traps of being trapped in a fixed mindset is seeing other people's accomplishment as a threat to your own success instead of being happy for them. Not everyone falls into the trap. It may be a fleeting, emotional, knee-jerk reaction, and then the reasoning part of your brain suppresses it.

Another trap is seeing other people surpass you in understanding, which leads to a student feeling they must be "stupid" by comparison. If someone is learning faster, they start to beat themselves up that they aren't smart enough, or good enough. It's a dangerous road because no matter how much we say that the difference between them is minimal, any difference can be misinterpreted as a deficiency that will be exposed when they start the job hunt.

Of course, neither of these cases are factually true, but the emotions are brutally real and we find ourselves constantly coaching students to battle those feelings, and own their own journey with a sense of pride and accomplishment.

Next Steps

We still have many experiments to run, and we need to constantly hone our craft of team building. We will never achieve perfection, but we must constantly strive for it, else we end up settling for mediocrity.

One major struggle we still have is how to provide the best environment for those students who still need significant coaching and time to work on concepts when it is time for a group project. Putting those students into their own group, simply because the delta is small, hardly ever works, and yet we haven't devised a strategy that does work.

This group of students gets frustrated trying to do even minimal work since their level of understanding at that moment is so low. This leads to an entire group of people who don't know how to start, how to design and organize their project, and get tripped up at the smallest obstacle. We need to find a way to help these students.

Pair programming
Individual projects
Live-coding and discussion with the instruction staff

These are all strategies that we will be attempting in the coming months to help set all of our students up for success.

People are hard. Teaching the tech is the easy part.

Custom Object Iterators in JavaScript

Steve Brownlee — Mon, 13 Aug 2018 04:06:24 +0000

Originally published on stevebrownlee.com

Imagine that you have an object in JavaScript that maintains a list of items, and you want the object itself to be iterable, but the object also has other important properties - such as metadata about the list of items.

Here's a fun and completely original example.

const se7enDwarves = {
    employment: "Miners",
    output: "Diamonds",
    members: new Map()
}

se7enDwarves.members.set(1, "Sleepy")
se7enDwarves.members.set(2, "Grumpy")
se7enDwarves.members.set(3, "Happy")
se7enDwarves.members.set(4, "Bashful")
se7enDwarves.members.set(5, "Sneezy")
se7enDwarves.members.set(6, "Doc")
se7enDwarves.members.set(7, "Dopey")

I now have an object that represents the seven dwarves. It holds their names in an iterable collection, but also other relevent data about them. I would love to be able to iterate over the object itself, instead of having to type in that horrible, troublesome property namespace of members.

I want to see the names of all the dwarves, so I use the spread syntax to iterate the object and place the items in an array.

[...se7enDwarves]

VM2417:1 Uncaught TypeError: se7enDwarves is not iterable
    at <anonymous>:1:5

JavaScript, in all kinds of holy righteousness, tells me that I can't iterate an object like that.

Hmph.

Luckily, JavaScript allows developers to perform what is called metaprogramming. It's a feature of the language that allows us to modify some of the default behaviors of the underlying data structures available to us. I can make an object iterable.

se7enDwarves[Symbol.iterator] = function* () {
  const states = se7enDwarves.members.values()
  let state = null
  do {
    state = states.next().value
    if (typeof state !== "undefined") yield state
  } while (typeof state !== "undefined")
}

High level overview... I made the object iterable. Thought I'd point that out in case it wasn't obvious from that "self-documenting code".

[...se7enDwarves]

(7) ["Sleepy", "Grumpy", "Happy", "Bashful", "Sneezy", "Doc", "Dopey"]

Try it Out on jsfiddle

I create a JSFiddle for you to play around with this code yourself.