DEV Community: Sebastian Spiegel

The Gender Question

Sebastian Spiegel — Fri, 11 Jun 2021 18:37:50 +0000

Happy Pride everybody! Since it’s the month to highlight diversity and inclusion I wanted to talk about something that has been bugging me, especially as I fill out endless job applications.

It’s the gender question. Everywhere on the internet, you are asked for your gender. On signups for social media and websites, on e-commerce popups that aim to get the demographic for future marketing decisions, and on every single job application. In the US there are a series of questions required on every job application - gender, race, ethnicity, veteran status, and disability. I’m not going to go into the history of this and why these questions exist because that’s not the exact issue I want to bring up. I just want to focus on the gender question, as it relates to all of these things.

For 99% of the applications I have filled out, the options under gender are “Male”, “Female” and “Decline to identify”. My gender is not any of these things. I do not identify as “male” or “female” and I’m not specifically interested in declining the question, but that’s what I keep doing, as there are no other options. This doesn’t have to be the case, I know because of the 1% of applications I found where they added in “nonbinary” as an option. So it’s possible and within guidelines to add this option.

So why aren’t more companies doing it?

Especially since it’s pride month, I’ve seen a lot of companies changing their logo to rainbow and posting promises of acceptance and diversity within their ranks. And yet, an interested job seeker (me) finds an immediate derailment to those ideals when going to apply.

And it’s not just on applications, there are so many other places where users are asked for their gender. And plenty of social media sites have taken steps to increase the number of options, sometimes to the confusion or even hilarity of the groups they are trying to include.

So here are some thoughts from a nonbinary person about UX and gender:

If you don’t need to know, don’t ask. Honestly, the only person who needs to be concerned with what my gender is - is my doctor. Odds are most of the sites collecting that information aren’t doing anything with it. And targeted ads are so ridiculous that gender doesn’t actually end up helping the algorithms. So if you are building a user sign-up, maybe just skip the question altogether.

Keep it simple. And I don’t mean just having “Man, Woman, Other” as the only three options. Don’t other an entire portion of your userbase by signifying a group of diverse people as “Everybody else”.

Know what information you are really asking for. Do you want to know the gender identity of the user? Or their biological sex? Or just what pronouns to use for them? Be specific in what you’re asking for, and have your response options reflect that. If you ask for “gender” most people assume you mean gender identity, and if you ask for sex people will wonder why you are so interested in what their biological makeup is.

Ask for input, especially from non-cis people. If your options are “Man, Woman, Transgender” you are asking every binary-identifying trans person to decide if they identify primarily as trans or as a man or woman. Many trans women and trans men would prefer to just answer “man” or “woman” so if you think you’re collecting data on non-cisgender users - you’re not. Before you launch your form, get somebody to look at it. Explain to them the info you want to collect and why, and let them tell you how they would interpret the question and what information they would give.

Just make it a text input. There are more examples of what not to do than I could ever put in one blog. And there are a lot of different gender identities out there, and if you try to add them all to one dropdown it starts to look ridiculous. So, whenever possible, allow for direct user input, so a person can be as specific as they want.

But the biggest thing I want to come back to is that you probably don’t need to know the gender, so why are you even asking?

And if it’s a mandated question, please please just give more options than “man” and “woman”, especially if you are claiming to be supportive of LGBTQ employees and job seekers.

My First Hackathon

Sebastian Spiegel — Sun, 06 Jun 2021 16:56:04 +0000

Yesterday I completed my very first Hackathon! A few weeks ago I submitted an application to Out in Tech for their Pride Month Digital Corps Build Day and was extremely excited to be chosen to contribute. It was a full-day event that allowed me to give back to the LGBTQ community and work with some talented queers in tech.

The purpose of the event was to build websites for LGBTQ and BIPOC business owners. One hundred people were a part of the event with backgrounds in design, programming, project management - more than I could list without looking like a job board.

My group was 12 people and our client, Bronx Clay, was a Bronx-based pottery business. The owners wanted a website where they could sell their pottery and merchandise, and provide information about the classes.

We split up into 3 teams: design, content, and store. Since I have experience with eCommerce I volunteered to be on the store team. This was my first time building a WordPress website and my first time working with the plugin WooCommerce but I found both very easy to navigate. My other teammates also weren’t familiar with the frameworks so we spent some time figuring out exactly what we needed, then jumped on a call with the client.

The client awesome, not just for the work she does in the community, but was very easy to talk to and was able to answer our questions and communicate exactly what she was looking for. Having worked with clients who can’t even do one of those things, I think we lucked out!

The build day was 7 hours, including the hour-long intro, 30-minute presentation, and lunch break. So the fact that we built an entire site in what was only 5 hours is incredible and the entire thing looked amazing at the end. I can’t wait for it to fully launch and I hope that having the site means that Bronx Clay can raise more money for their community and expand to their own site quickly!

It’s been a while since I worked on a team like this, and the biggest thing I learned was that no matter the industry it’s all very much the same. 12 people is a pretty big team for one project, so it was very necessary we divide it up into the different components for smaller teams to take on. There was also a struggle with the hierarchy of the group, which I think came from it being a volunteer lead project, as opposed to a business where there would be clearly defined roles moving into a team.

There is a difference working in queer groups, that I’ve noticed across the board with my work in the community. You get more people who are used to being talked over, ignored, or just not taken seriously. So when marginalized people work together, they tend to hold collaboration and communication in high regard. Nobody wants to make anybody else feel like their input isn’t valued, so there is a lot more group consultation. This can be great, as it gives people space who don’t always get it, but it can also drag things and make simple decisions a lot harder. It’s a trade-off I’ve come up against many times, and it can be very frustrating. That being said, I still prefer it to the situations I’ve been in where people are so disheartened that they quit the team, or are made to feel like they are useless. Even if all that was left was the less glamorous, repetitive, or “easy” tasks, I knew I was contributing to my team and was appreciated for it.

I’m not sure if this experience is typical of hackathons, but now that I’ve got one under my belt I’m excited to do more! The experience and networking that I went in for were great, but getting to spend the day with a bunch of queers and make new friends is what made the day for me.

3 Ways to Spice up UX for Dummies

Sebastian Spiegel — Sun, 30 May 2021 14:22:49 +0000

Fun with DOM and JSX

Looking to jazz up an application? Not a designer or a UX expert? Here are my favorite simple, interactive elements I’ve added to my applications.

Flippin’ Card

I utilized this in an application where I was displaying a digital version of seed packets. On one side, the photo and name of the plant; on the other side, the planting and growing information. I utilized the npm react-card-flip, which is very easy to install and implement. I customized my version to be a click on the div element itself instead of a specified button, like so:

render(){
        return(
            <div className="card-hidden" onClick={this.handleClick}>
                <ReactCardFlip isFlipped={this.state.isFlipped} flipDirection="horizontal">
                    <div className="card" onClick={this.handleClick}>
                        <SeedCardFront seed={this.props.seed} handleClick={this.handleClick} />
                        <br />
                        {this.renderButton()}
                    </div>
                    <div className="card" onClick={this.handleClick}>
                        <SeedCardBack seed={this.props.seed} handleClick={this.handleClick} />
                    </div>
                </ReactCardFlip>
            </div>
        )
    }

With a few design adjustments, you can even get a nice 3D effect! To further customize, you could change the onClick to a mouseOver event, or even create a 3-sided digital object!

I love this specifically for decluttering the DOM. You have the option for twice the information without taking up as much space.

Drag-n-Drop

Draggable list elements are the main feature of my Story Peddler application. The purpose of this is for users to be able to rearrange story elements, which I refer to as plot points for the purpose of this version of the app. The feature is meant to replicate what many writers do in the real world: writing their plot points or chapters or whathaveyou on sticky notes or index cards, which they can then move around as they organize their structure. To replicate the same ease in the digital space I wanted draggable elements that save in their new order when dropped into their new position, like my favorite Apple weather app with locations.

I started with this article where you can find a ton of great drag-and-drop options. Play around with them all to find the one that fits your application the best!

Color Changing Buttons

While working on my first version of Story Peddler I utilized a free Bootstrap theme from Bootswatch called Sketchy, and found one of my favorite easy to implement design elements.

The applications colors of black and white were actually meant to evoke the idea of a whiteboard, so having the pops of color on their worked really well for this particular application, and it’s very easy to implement into any css folder, though I had never had cause to user the .hover tag before this.

Utilizing the hover tag can be very helpful for UX and visual accessibility (though keep in mind it won’t transfer to a mobile platform!) I’ve also used hover to thicken the border of a div element to highlight it. It’s a small detail you’ll find in many applications and sites, but for a project can really bring it to the next level visually.

Finding Inspiration for Coding projects

Sebastian Spiegel — Wed, 19 May 2021 13:20:43 +0000

When I was doing the software engineering bootcamp at Flatiron, the biggest struggle outside of the technical challenges was coming up with ideas for the many milestone projects. For some of them, I was able to come up with ideas fairly easily and jump right into coding. Others took me longer to piece together, and I ended up writing out different ways and places to find inspiration. For anybody else struggling with project ideas, whether for a bootcamp or just a personal project to level up your skills, here is what I came up with:

Create a digital version of something to use/do often

This is a popular one for early projects; I know many people who created basic digital board games like tic tac toe, checkers, or backgammon. It’s a great way to work on your UI and have fun with some design if you build out a frontend with JavaScript, or you can do a CLI version (I did a CLI two-player tic-tac-toe!).

You can also create digital planners or diaries, recipe books, even a family photo album. Just pick anything physical you interact with during the day, and think about a version of it that could exist digitally. There are a million different calendar apps in the world, but not yet one created by you!

I got the inspiration for my Tarot Dictionary when watching a friend flip through the guide that came with her deck. The goal to make it as easy as a few clicks to get to a specific card is what guided my build of the application. Others in my cohort make language dictionaries or basic translation apps for travel.

Recreate your favorite app

Speaking of apps that already exist, another often seen project is simply recreating popular apps! Twitter, Instagram, or just a simple blog are all great ways to get a deeper understanding of how these apps work from the inside. It doesn’t have to be an exact match, and odds are it’s not going to be anything that improved upon the original (though kudos if it is!), it’s all just about the practice.

If your favorite app is Co-Star, make your own version of an astrology program. If the most used app on your phone is Seamless, find an API that provides restaurants based on zip code and make your own Yelp! Even better if you can think of something to add that the others don’t, even if it’s not a feature that the majority would be interested in. “I always wished that this app included this feature, so I build my own” is a fantastic thing to tell somebody you’re explaining your work to, like an interviewer or recruiter.

Ask your family or friends

Many of my project ideas came from trying to solve real-world problems. I made a narrative organizer for a writer friend who wanted to be able to access notes when she didn’t have a notebook handy. I made a gardening application for my mom so she could organize her plants and easily look up all the planting information she needed.

I also started including crowd-sourcing into all my projects, when coming up with possible features. I posted the basic idea for the app and asked people to say what they would like to see included, what types of things would make them more likely to use or download that type of application. This is another great thing to include when explaining your app!

An application should have a narrative built into it, the way the user interacts with it being a seamless story from start to finish. But the way you built it is also a narrative, and recruiters love to hear it. Wherever the idea came from, expound on it when you explain your projects. And if you don’t have a good reason for why you picked a project idea, and especially if you’re not feeling particularly inspired by what you are building, that might not be the project you should work on. I built an application completely based on the Witcher game series simply because it was interesting to me, but the way I can talk about the application makes people want to hear about it, even if they aren’t familiar with the inspiration.

There is a lot of inspiration to be found for coding projects, and hopefully, if you are in the midst of a block these ideas have helped you!

Nav in Native

Sebastian Spiegel — Tue, 11 May 2021 21:21:46 +0000

This week I have been building my first React Native application. I started off with just changing the and styles, making sure I understood how ‘flex’ works and the different core components. To do this I made several component files and took turns returning them as I played with them. But in a real mobile app, which I intended to build, there is navigation, just like in a web app.

So clearly, this wasn’t going to cut it.

return (
    <Welcome />
    // <Index />
  );

Note: If you already have an app and want to incorporate React Native, it’s recommending to use the react-native-navigation library here

There are many libraries to install to use React Navigation. I’m using expo, so I installed using the following, but you can check out the documentation if you have a different setup for your app.

npm install @react-navigation/native
expo install react-native-gesture-handler react-native-reanimated react-native-screens react-native-safe-area-context @react-native-community/masked-view
npm install @react-navigation/stack

If you are familiar with vanilla React (which you really should be first), then the setup for navigation looks very similar to routes, just different words! The setup should happen at the top level of your app (usually App.js). You start off importing these two libraries:

import { NavigationContainer } from '@react-navigation/native';
import { createStackNavigator } from '@react-navigation/stack';

Inside of your App function, you then need to have a way to call upon the createStackNavigator function, using this line: const Stack = createStackNavigator();

That’s the setup! Now you have everything you need to use to wrap up the screens that you want to render. So now my App.js is looking like this:

return (
   <NavigationContainer>
     <Stack.Navigator>
       <Stack.Screen name="Welcome" component={Welcome}/>
     </Stack.Navigator>
   </NavigationContainer>

 );

The next time I had to figure out was using props, so I coud also get my Index component working. For the purposes of testing, I had all my data in the top level of my app (later I plan to replace that with a quick fetch to an API I’ve already picked out).

For React Native navigation, you can’t pass an inline function like: component={() => <HomeScreen />}
Instead, much like you would see for a Route in vanilla React, you wrap the component like so:

<Stack.Screen name="Index">
         {props => <Index {...props} cards={cards} />}
</Stack.Screen>

In order for my function to properly receive the props, I used memo (there are a few other options, but this worked well for me!)
So I changed this:

const Index = (props) => {
   return(
      // render here
   )
}

To this:

const Index = React.memo(function Index(props) {
   return(
      // render here
   )
})

My Index is using FlatList, so I was getting a warning on my simulator, which I believe is the Native version of the warning you get when you don’t give child components individual keys in vanilla React. So if you get this error:

Warning: Failed child context type: Invalid child context virtualizedCell.cellKey of type number supplied to CellRenderer, expected string.

Add this where you are rendering the components: keyExtractor={item => item.index_id.toString()}

Now I successfully had two different components, but only the top one will render when the app starts, and unlike a webpage, you don’t have the option of just putting in the URL to get to a different route. So I added a button to my Welcome screen, to navigate to my Index.

<Button color="white"
         onPress={() => {
           navigation.navigate('Index')
         }}
         title="Start"
       />

Note: for functional components, it’s a good idea to destructure props, but if you don’t want to do that remember to put props.navigation.navigate(‘Component’) instead.

If you want to navigate one page back you can use an easy back button like so: <Button title="Go back" onPress={() => navigation.goBack()} />
Though with native-gesture-handler the user can also swipe to move a page back.

So that’s the basics of how I set up navigation in my current React Native application! This is definitely the easiest way to get started, and there is so much more to learn further down the line.

From A Single Page Application to React

Sebastian Spiegel — Tue, 04 May 2021 13:24:05 +0000

(I previously blogged about building Story Peddler here)

What does a bootcamp grad work on when the bootcamp is over? (Other than the job search, LeetCode challenges, networking, hackathons, and endless DSA practice.) Well, a good place to start is with old projects, which is where I turned when I finished up with Flatiron a few weeks ago.

The idea for Story Peddler came from a friend of mine, who wanted to take her narrative planning to a virtual platform but wasn’t able to find an application that included an editable ordered list (for keeping track of plot points). The original application was a simple one-page JavaScript with a Ruby API backend that allowed a single user to create ‘Stories’ with associated ‘Characters’ and ‘Plot Points’. One focus while making it was for it to be flexible, just as usable for a person writing a novel as it could be for somebody writing a comic book, a film, or an arc for a table-top campaign. Within the time frame and parameters of this being a bootcamp project, I wasn’t able to incorporate user auth or other features I crowd-sourced from friends and twitter (like reference sheets for popular story structures).

I was thrilled to be able to return to this project with more time, and more skill. I especially enjoyed learning React for a separate bootcamp project and was eager to build on my knowledge of the framework. Here are a few things I did to set up Story Peddler 2.0(SP2) and what I have learned so far:

User Auth First

I set up a completely new repo for SP2, and the first thing I wanted to tackle was User Auth. Partially this was because I hadn’t yet incorporated User Auth using JavaScript and wanted to learn how to, and partially because I knew from experience that filling in authentications after the fact can be very complicated.

I read up on and incorporated JWTs, deciding to use local storage for my current user. In the past, with Ruby applications, I had only ever used sessions, so this was a new format for me. (For learning about JWT in a React/Rails app, I highly recommend this blog post)

Storing the user in the highest level means it’s easy to pass in that information to all other components, whether they are fetching associations of that user (for Story Pedder that would be any stories that the user has created) or if you are dealing with protected routes/authorizations on your front end (if a user is not logged in, my application will re-route them away from story creation forms back to the log-in/sign-up page).

Translating to JSX and introducing Routes

When setting up Story Peddler 1.0 the first thing I did was build out my three creation forms: New Story, New Character, and New Plot Point. In SP1 these forms were in the HTML file and a handleClick function made them visible on the DOM, or hidden again. For SP2 I gave them each their own route but was still able to copy the original forms to start with. Since React uses JSX I did have to change a bit of the code, like changing ‘class’ to ‘className’.

In SP1 I had all of my API requests in one class and the corresponding DOM control functions in another. For SP2 I moved the API requests into the component class rendering the form. Most likely to be refactored at some point, as having this many functions in one class can make it a bit bulky, but for building out it was a reasonable separation.

Another change I made was in the story view function. In SP1, I created a drop-down in the header where a user could select a story to view on the DOM. Since I now had user pages to play with, I decided to forgo the drop-down and instead created story cards for the user page. From the display of cards, a user can select one to view and from there gets their options to edit or delete elements in a story.

Having specified routes for each story fulfilled another function I had to previously leave out. Now a user can send a story to somebody else to view. In SP1, a story could only be viewed after selecting it from the dropdown (or after creating it, when it would automatically append to the DOM). Now, if a user knows their story id, they can go to /stories/:id or send that route to somebody else.

<Route exact path="/stories/new">
     <NewStory user={this.state.user} />
</Route>
<Route path="/stories/:id" component={ShowStory} />
<Route exact path='/characters/new'>
     <NewCharacter user={this.state.user} />
</Route>
<Route exact path ='/plotpoints/new'>
     <NewPlotPoint user={this.state.user} />
</Route>

Better Design

While I haven't entered the stage of the big design updates I have planned, I did take a few moments to review some of the feedback from SP1.

For example, here is my new story form from SP1 vs SP2:

Not perfect, but with just a few CSS tweaks the spacing looks so much better, and taking that time during the first iteration would have made a big difference.

More to come

So far Story Peddler 2.0 has been extremely fun to work on! Even though it’s an application I already built to completion, doing it in the React framework makes it feel completely new. At the time of this post I would estimate I’m just over halfway through, and excited to get the brand new Story Peddler 2.0 hosted and shared for all types of writers and creators!

All Applications are Stories

Sebastian Spiegel — Mon, 29 Mar 2021 15:24:20 +0000

I’ve always been a storyteller at heart. Whether producing a show or writing, my passion was always giving people a story to follow. I’ve found joy in programming coming from the same place. While most applications don’t include a story in the traditional sense, there is still a trail to leave. I like to build new applications starting at this point. When developing a concept a good question to ask is ‘What is the story of the user who would want this application?’ During my last build, I realized how important the story continues to be through the entire process. Not just the story that leads a user to an application, but the story of the user while using the application as well. For me, this became a map. An ugly, ugly map. I am a storyteller, but not an artist.

My name is Sebastian and I'm a recovering screenwriter

If you decide you want to write a screenplay (an unfortunate ailment that affects thousands a year) you'll find yourself with as many different ways to plan your script as there are people trying to write scripts. I know because I've written several myself, and over many years formulated my own way of doing the prep work.

I'm pretty proud of some of my breakdowns. I use a large piece of sketch paper, rulers, carefully printing by hand an easy-to-follow guide. I know that if I can complete the breakdown, I can write the story. I can show them to others and have them follow along. I can use them as examples to teach others my process.

But getting there took several years. My first few attempts? Crazed scribbles across pages of notebook paper, entire sections scratched out and illegible notes written into margins. Scholars will continue to debate exactly which language some of it might be for decades to comes. Figuring out your perfect method takes time and error. But in the end, I came out with something that was not helpful to the writing process but invaluable.

I find myself in the midst of a very similar process for planning out new applications. I've seen many examples of how others plan and map out their sites, but I know that it will take trial and error for me to figure out what it is I need to be successful. And it's not very pretty, but it's crucial.

Pirate : Treasure map :: Programmer : diagrams.net

There are of course people who have no trouble holding everything in their head or people who can follow along with their own hasty notes that skip around with no reference to what component or logic they are noting. I envy them and send my best wishes to their team members who do not possess this same skill.

For the rest of us, please trust me when I say: you need a guide. And as my own projects get bigger and more complex I find the only thing that can untangle my thoughts and help me navigate and focus is a visual map. At some point, I hope to get to the same point as my script breakdowns, something organized and clean that can help translate my thoughts to others as well as organizing them for myself.

For now, I have this:

This page is the only thing that kept me sane while building this application. If you squint, you can see the user story I was trying to build.

The initial landing page branches off into what is essentially my navbar, and then I’ve broken down those into the components that are included in those containers, with a few arrows to show how a user might get from one to another.

I’ve come back to this when I’m lost - that’s why I like to call it a map. “What am I doing, what is my goal right now?” is a question I find myself asking whenever I get frustrated with a bit of code. I think everybody has had a moment where you get so caught up in a bug that you forget what the original goal was, and sometimes the bug you working out is in a bit of code you don’t even need! The map helps to get me back on track and reminds me to put myself in the user’s shoes. What is my user expecting, what will they want to do from this point?

Become the guide

Finally, on the subject of putting yourself in the user’s shoes, if you hand a site over, even one with a ton of great and interesting functionality, a user isn’t going to know what to do on their own. A good site tells the user exactly what to do. Think of any social media site. There is usually a big log-in component right on the main page, and once a user is logged in that is replaced with whatever posting option that site has. It’s always front and center, usually prompted as well (though less so these days, but remember the OG facebook “I think…” prompts?). Users want to be told what they should do and what they can do, and in this way, you can lead your user through the application. Navbars are only part of the way to do this, but adding in prompts is better. Never underestimate how obvious your functionality is. “New Post” isn’t as dynamic as “Create a new post”. Try to phrase all functionality as a call to action, you can always pare them down later (a ‘like this post’ button can easily just be labeled ‘like’ thanks to the popularity of the feature).

Your user doesn’t get your map when they come to the site, so you should work to translate that map into a guide. Design can help a lot here, making the more important component stand out on a page, but how they are labeled can be just as important.

Epilogue

It still comes back to the story. In the end, you put that story into the user’s hands. What is the story they are telling? Is it a blog post about their day, or a photo of where they are at that moment, or their plan for their garden this season? Everywhere we travel on the web, we leave a story. A good application assists in this process, as well as protecting it to return to again.

So when you get lost in the complications of the code, remember to surface and check you are still on track. Is what you are doing helping you write the story you want to tell? And if you need a moment of zen, the song that inspired the title of this blog is ‘All Boundaries Are Conventions” from the Cloud Atlas soundtrack.

React routes for if you've already read all the other blogs on react routes

Sebastian Spiegel — Wed, 24 Mar 2021 16:50:16 +0000

This one is for beginners, so everybody else be warned.

I lost track of how many articles and blog posts I read while trying to set up an auto re-route, and absolutely none of them helped me. I kept getting bogged down by too many options and technicalities. They all included so much information about protecting your data, a million booleans to check authentications, just way more than what I was trying to do. If you want to do anything more complicated than 'click button, different web page', you should go read some of those other articles. This is more of an 'I honestly can no longer be bothered I just want you to do this one simple thing.'

The steps are:

First page loads
User clicks a button/link/whatever you wanna try adding an event listener to
The page redirects to the Second page

I used this to redirect from a submit to an index page (with no errors or backend authentications).

First, import Redirect like so:

import { Redirect } from "react-router";

Next, you'll need a function similar to this one, that will be in charge of adding a redirect key to state and setting the boolean to 'true'.

setRedirect = () => {
        this.setState({
            ...this.state,
            redirect: true
        })
    }

If you haven't dealt with state much or are just starting to use React, that spread operator is a very important habit to get into. Even if you're not doing anything else at all in this component, get used to putting ...this.state every time you setState().

So now you need a function that will check that boolean. Something like this:

renderRedirect = () => {
        if (this.state.redirect) {
          return <Redirect to='/seeds' />
        }
    }

Short and sweet, if you need no other validations before you redirect that's all you need.

The next step is to call renderRirect() in your return. If you are in a class component (it would be called something like class MyClassComponent extends React.Component) you'll do this inside the return of your render function. It will look like this:

render(){
        return(
            <div>
                {this.renderRedirect()}
                {/* Whatever link/button/etc you are putting your event listener on */}
            </div>
        )
    }

So now, when the page loads it will run the renderRedirect function, which in turn will check state and see if the Redirect is valid. The last step is to go to your event listener function and call setRedirect(). If you are in a class component make sure you're calling it using this:

this.setRedirect()

The page will re-render as it is want to do when an event listener is triggered, and the user will be automatically redirected!

If you are trying to redirect from a functional component (something like export default function FunctionalComponent(props)) there is also a very simple option, using history.push().

This is what I did for redirecting from an index to a show page. The user would be taking the same steps as before. The props I passed into my function were the objects (in this case a users gardens) being displayed, which included the object id.

First, import useHistory:

import {useHistory} from 'react-router-dom';

Then set a variable to call the useHistory() hook you've imported:

const history = useHistory()

Then in your event listener, you can call history.push. Here's what mine looks like:

function handleClick(){
        history.push(`/gardens/${props.gardenId}`)
    }

So you're basically telling your application "this is where I want to go when this event listener is fired".

To read more about these hooks you should check out this documentation: reactrouter.com. You'll the same exact code as before for useHistory, but less breakdown.

Again, this is all for beginners. Hi, hello, let's hold each other's hands and baby step our way through the most basic things until we understand them fully and completely. Otherwise, what's the point in even trying to tackle the harder stuff?

Also, so many things that happen when a user is interacting with a web app are invisible, so it can be very exciting to code something that actually an immediate visual result. I don't see why we don't celebrate every successful page render!

There are many, many ways to use routes and redirects in React. Probably better ways than this! To me, however, the best way is the way that 1) gets the job done and 2) that the programmer understands. If you just start copying and pasting from some article without knowing what any of it does, you'll be lost when you inevitably need to debug.

To be or not to be... a hidden HTML tag

Sebastian Spiegel — Sat, 20 Feb 2021 15:31:15 +0000

When updating the DOM with new information, you really get two options:

1) Have all the HTMl already sitting in your file, which you then can select and edit, or

2) Build from scratch and append it to the DOM.

In my latest application, I utilized both methods, sometimes at the same time. I'm not the ultimate knowledgeable source on the best method, but for getting started I have pulled together a few basic pros and cons.

Hiding in plain HTML view

One of the first things I created when I starting building were the forms I wanted to add new objects to the database. If you aren't sure what the HTML should look like, the easiest thing to do is just write it out directly in plain HTML. I also knew I didn't want the forms cluttering up the page all the time, so I added a 'hidden' attribute. This wasn't intended to be a feature of the application at all; I wrote the forms directly into the index file because it was easier than trying to JS code them in and then hide them because I wasn't ready to deal with them further.

But then I realized I kind of liked it like that. For some things, this might be a security issue, but any of these forms is unhidden with a simple click of a button, and there are validations for any data sent through. For these forms it seemed a safe enough bet to just have them there, hiding until the user wanted to create a new object.

The application at the start

The hidden attribute is removed with the click of a button

I followed the same system as I started to build out other parts of the application. Writing it in plain HTML, and then hiding it if I wasn't ready to work on it more or if I only wanted it to appear at certain times. It worked great for my forms, which remain static and never need to be changed. And it was so much easier than spending time finding every element and making sure it was appended to the correct parent, in the correct order.

The Jumbotron

For displaying all of the information for a specified object, I coded in a jumbotron in the middle of the page. I started off with almost all of the HTML hardcoded, with the idea that I would just select the elements I wanted to manipulate and edit them according to whichever object the user wanted to view. This is very possible but I ran into problems when switching to viewing one object to another.

If my objects were more identical in their structure, I probably could have kept on this way. But my structure allows for a user to have some, many, or no attributes for their object. One fix would be a series of 'ifs'. 'If this data is present, replace the element value, otherwise clear the element value.' But you know what's easier?

document.querySelect().innerHTML = ""

That little line of code became my new best friend. I started moving elements out of my index.html and creating them in my code instead.

Almost immediately I'd make a complete mess of the page. Finding the right parent, appending it in the correct order... I did not do these things correctly at first. But that's fine! It's all trial and error, right? But there is something that can make it smoother...

So it turns out 'div' elements actually are helpful!

Who would have thought! I built a nice little skeleton of HTML using div elements, and then it became a lot easier to put all the information in the correct place by just grabbing that div element and appending a new child element to it.

<div class="jumbotron" hidden="">
      <div class="storyInfo">
    </div>
      <p>Characters:</p>
      <ul class="list-group" id="storyCharacters">
      </ul>
      <hr class="my-4">
      <p class="lead">
        <div class="list-group">
          <ol id="plot-points">
            <li class="list-group-item list-group-item-action active">Plot Points:</li>
          </ol>
        </div>
      </p>
      <div class="buttons"></div>
    </div>

In this particular example, it doesn't look quite as barebones, because of the CSS tags I'm using (thanks bootswatch!) but trust me, this is a great middle man. As you can see, I'm still utilizing the 'hidden' attribute to hide the entire 'jumbotron' div element until I'm ready for it, and I've also got just a couple of specifics hardcoded in, that stays the same for any object that gets displayed.

You can't hard code for x

There were of course places where my hardcoded HTML is basically nonexistent. Some of my divs have nothing at all between them, but having the div there as a placeholder makes it way easier to append the element in the exact right spot.

Like for my character list here:

<ul class="list-group" id="storyCharacters"></ul>

There is no way of knowing how many items are going to be appended to the list. So even though each character object is getting 4 different elements created for it, in this instance it is better practice to create and append those in JS. Otherwise, you are hard coding in the list elements, then grabbing them to edit their values. If each user was only allowed to have 3 characters, I could make that work. But what kind of user experience is that?

let characterList = document.querySelector('#storyCharacters')
        characterList.reset

        let newLi = document.createElement('li')
        newLi.className = "list-group-item flex-column align-items-start"
        newLi.id = `${this.name}-${this.story_id}`

        let newDiv = document.createElement('div')
        newDiv.className = "d-flex w-100 justify-content-between"

        let charName = document.createElement('h5')
        charName.className = "mb-1"
        charName.id = `${this.id}-editName`
        charName.innerText = this.name

        let charDes = document.createElement('p')
        charDes.className = "mb-1"
        charDes.id = `${this.id}-editDes`
        charDes.innerText = this.description

        characterList.append(newLi)
        newLi.append(newDiv)
        newDiv.append(charName)
        newLi.append(charDes)

In addition to the li element, each character is getting its own div element, making it easier to ensure that the character name and description are appended correctly.

And now I've seen the #D3D3D3

Previously when coding HTML I didn't have patience for putting id tags on elements, or wrapping elements in divs. I really only would add on an id for styling purposes, and usually only after the fact. A couple of things helped me get into better practice with this application:

1) starting out with a good CSS file (thanks bootswatch!) meant that as I was adding elements to the dom, I already knew what I wanted them to look like and added the appropriate tags early on.

2) Coding with the next step in mind. If you know you're going to need to access the value of an input field, it's a good idea to go ahead and give it an id that makes sense (no 'input-tag-002' in this project). Of course, you can always use inspect to find that element you've misplaced, but I had a lot easier time using the same naming conventions throughout the project.

And honestly, these are two of the biggest takeaways I have from this application. Obvious? Possible. But once in a while, even a master needs a reminder that the simplest best practices make a world of difference

Scope methods, has_secure_password, and other things that are too powerful for comprehension

Sebastian Spiegel — Sat, 23 Jan 2021 20:16:33 +0000

The following reflects the experience of a new programmer using Ruby on Rails for the first time.

Anybody who says "you can never do too much" hasn't had enough experience with baking or coding.

If you've ever tried baking in a small batch when your normal recipe is meant to feed 10+, it usually doesn't go exactly according to plan the first time or so. With practice, you learn how much to divide or multiply the amounts, and there are bakers who can measure out enough for the exact number of cupcakes they intend to make without a drop of batter going to waste.

In coding, it's also easy to do too much. There's harmless if cluttered repetitious code, or extra validations just because you want to make good and sure no invalid users are traipsing down a certain path. There are the ones that end up canceling each other out.

There's also just straight-up making two different methods that do the same exact thing because you forgot you'd already made one and put it in your model and then you go and do the same thing and slide it into a helper.

Then there is just doing too much.

**Here's where we go off the rails**

Ok, let me see if I can backtrack and break this down.

The end goal is to display the name of the Location that has the most Monsters. A Contract includes both the location.id and the monster.id.

We start with a join table, linking contracts.location_id with locations.id, and then group them by location_id. Order that by the count of location_id (descending order), and the first one we get back is the location.id that has appeared the most number of times across all contracts!

Well, actually what we get back from running Active Record through a rails app is an array of two numbers. But we have a method in the Contract model that at least got us that far:

scope :location_with_most_monsters, -> {select(:location_id).joins(:location).group(:location_id).order("count_location_id DESC").count.first}

This took several hours. I made a note for myself: first number = location_id, second number = # of contracts out.

I stared at this for a while, trying to poke that array into being... any type of useable information. Then I went to bed.

New day! We have an array, and one of those numbers happens to be the id number of a location. I need that location name. I can't just give my client an id number, it would be meaningless.

So let's take that first method over to the location model, try to find that location. Luckily a full night of sleep helped me remember that I could call .first on that array to get back just that first number (good thing I left that note for myself). We can call .find on an integer, and this is the integer we want!

So we have our second model:

scope :with_most_monsters, -> { find(Contract.location_with_most_monsters.first) }

Now that we have the Location instance, we can take it over to the controller and save it to a variable for our view.

@dangertown = Location.with_most_monsters

So close! Of course, we can't just give our client this entire instance. They don't care about the date and time this was added to the database or the id number! They need a name. There are monsters and this particular location has a lot of them. Lives could be at stake.

So in the view, we provide that name:

Location with most monsters: <%= @dangertown.name %>

There you go! Hours of work, so much SQL, to get 4 lines of code so that a client knows which town has the most monsters.

HOURS of work. I can't actually say how many, only that when I started the sun was out and my roommate wasn't home from work, and when my headphones died and I couldn't listen to the Chez Baldwin playlist anymore, the sun was gone and my roommate was cleaning up their dishes from dinner.

Why would any sane person need to spend that much time to come out with so little code that does ONE thing?

Well, lives are at stake! Fictional lives, dealing with fictional monsters. But one day the lives might be real. At least next time it probably won't take me as many hours to figure out the logic.

Lives, and passwords, at stake

"Well", you might say "at least you didn't then go on to spend several hours coding something that you didn't need to code!"

"Oh," I might reply "but I did."

Security is important (lives might depend on that as well!), so adding a password confirmation for new users seemed like a good idea.

Ok, cool! Let's add a 'password_confirmation' field to the form, and then of course we'll need to add that to our permitted params and then--

You stop. You stop what you are doing right now because that's it. has_secure_password knows what it's doing. You do not need to go into the controller and put, idk, something like

if params[:user][:password] != params[:user][:password_confirmation]
flash[:message] = "Passwords do not match!"
render :new
else...

And then you really don't need to spend an hour figuring what went wrong. has_secure_password does the confirmation for you! And the error message! Stop doing so much work! Take a break!

And don't even get me started on nested forms

Are you currently trying to build a nested form? And is it broken? And is it broken in new and exciting ways every time you catch one thing?

Here's the most important thing to remember: Leave. The. Controller. Action. Alone. That create method is just fine and if you start doing weird params validations in that method you're just leaving these wonderful rails methods to sit around doing nothing!

I thought I had it all figured out with 'accepts_nested_attributes_for' but then I just had to go and add validations to my data. So now we have a show-off.

In one corner, models#contracts/ accepts_nested_attributes_for :monster, which is just doing its job of letting a monster be associated with a contract. "Yes!" it says to a new contract instance, "Wonderful that you have that little box on the form, let 'em all in!"

Well, not all of them? We don't want nameless monsters, after all! (What could be scarier than a nameless monster?) Or a duplicate. So in the other corner, we set up models#monsters/ validates :name, uniqueness: true, presence: true and it proceeds to do its job of traffic control, not letting those pesky nameless and duplicate monsters into the database.

But our user can choose an existing monster for their contract, OR create a new one. So if they choose an existing monster, the field for the possible new one is left blank, and we can't have a blank monster, so that issue hits the validation and now contracts aren't being created and monsters are running wild and we're back to lives being threatened while these two duke it out.

So before you go diving into that controller, begging it to please meditate, there's one more little bit you should consider. (And leave the controller out of it, this fight is between models only.)

reject_if: is your mediator in this situation. Link him up and you get something along the lines of

accepts_nested_attributes_for :monster, reject_if: proc { |attributes| attributes['name'].blank? }

Peace reigns. Contracts of all kinds are welcome in the database. Monsters are kept in check.

And now a train metaphor

I was told Ruby on Rails was powerful, but that didn't stop me from having a dozen of those head explosion moments every day working with it. And now with all these new and exciting things available for me, I find myself asking "How do you know you're done?" and I suddenly have a lot more sympathies for people working on actual live sites.

At least in a perpetual stage of development, I can keep working on the features of my app at my own pace, laying down tracks for a train that might never come, polishing them to a shine.

I can, in a state of questionable sanity, rip up my entire database and add in three new models with only two days until the project is due.

And then if the new tracks I put down are a bit crooked, I can just put down some nice blankets and pretend that part doesn't exist for a while.

I assume that's something you could do with a train track. If it was your train track and you controlled the trains on it, at least. Probably not a good idea to do on a live, public train track. Might end up putting some lives in jeopardy.

Building a queer movie database with Sinatra

Sebastian Spiegel — Thu, 10 Dec 2020 19:48:32 +0000

Long before I started coding, I was a film student. I supplemented my studies in screenwriting with classes like LGBT History, History of AIDS, and Classic Theater. I wrote papers about the queer themes of Shakespeare, the queerness of B-films pre-Hayes code, and finding the hidden LGBT characters in films during Hayes-code. Pre-COVID, I met with friends for a regular Queer Movie Night where chosen films ranged from Some Like It Hot to Midnight. I like to think I know a lot of LGBT movies and a lot about LGBT movies, but that doesn't mean I've seen them all.

Inspiration and community-built databases

When some people watch a movie for the first time and notice an animal on the screen, they will go to the popular site "Does the dog die" for a little reassurance before continuing. This site not hosts a number of warnings for all sorts of triggers and is an invaluable resource because of that.

When I watch a movie for the first time and catch of hint of a queer-coded character, I want to be able to do the same thing. At the moment I usually reach out to a friend who I know has seen it and ask something along the lines of "Is this going where I want it to go, or am I going to be disappointed?"

Much like people on "Does the dog die?" I don't necessarily want to be spoiled for the plot, or have to read through an entire synopsis. I just want an answer to a question: is it queer? Unfortunately, this question doesn't usually get a straightforward answer.

From the big picture to a manageable project

I thought about my ideal website, modeled after "Does the dog die?" where a database could be built by community additions and suggestions. I also thought about the rules for qualifying a film as 'queer' and after a day down a rabbit hole of complex algorithms and how to weigh different types of movies, I realized I still needed to build a program in a week.

So I simplified. A database of LGBT movies, still curated by the community. I started with the basic records you tend to see with ActiveRecord; users and movies. Movies belong to the users who add them, a user can have many movies.

Technical difficulties

"Why are you doing that? WHY are you doing THAT?" is something I tend to repeat to two different things in my life: my cat (the 'that' is usually clawing furniture and the 'why' is 'cause I'm a cat') and my computer. I keep trying to find ways to avoid the pitfalls of spending 20 minutes troubleshooting for one misspelling but so far I haven't been able to fully avoid it. I try not to keep a tally, but those 20 minutes add up. Every time it happens I say "Let this be a lesson to me! I won't fall for it again!" but after 5 minutes I've completely forgotten what it was I ended up fixing and inevitably I make the same mistake a half dozen more times that day.

So if these wasteful bouts of 20-minute chunks forever lost to my own foolishness can't be avoided then what can be done?

As my frustration builds and builds, troubleshooting and checking line by line through a growing number of files ("Remember when I only had to deal with 2 folders and maybe 3 files?" I ask myself fondly), that frustration has to go somewhere when it's replaced by the eureka of finally finding the problem spot. Sometimes it comes out as a triumphant shout, or a laugh, or just an "OH !@#$ ME!" that my roommates have grown to accept is part of life now. The important thing is, you can't stay mad. You have to move on, because the only real enemy here is yourself and, unfortunately, you have to keep coding with that person.

Challenging myself

Once I had the basic requirements for the project in place, I went to my list of additional features I wanted to try to include. The first new thing I tackled was error messages, which after an initial failed attempt was easy to get working once I got some help setting it up.

Then I added comments, which brought me a lot closer to the original design I envisioned. Now there was an opportunity for users to engage in dialogue on the page of the film and add additional details.

class Comment < ActiveRecord::Base
    belongs_to :movie
    belongs_to :user
    validates :content, presence: true
end

The next thing on my list was admin accounts and privileges. I went a little backward with this, first seeding an account with the username admin and then hard coding that this account was allowed to edit all instances of movies and comments. Obviously, that wasn't a good solution, but after making sure the logic was sound for allowing the logged-in user and an additional user with specific parameters to edit, I fixed it up nicer. I added an 'account_type' attribute to my users, users are automatically created with the type 'user' and at this point, the only way I could change it would be to do so by manually accessing the database, but for now, it works for what I wanted it to do! I even made an easy method to stick into my routes.

if @movie.user_id == session[:user_id] || admin_account
            erb :'movies/edit'
        else
            flash[:message] = "You cannot edit that movie."
            redirect '/movies'
        end

After I had the logic set up, I went to the design side. I didn't spend a ton of time on CSS other than making my comments line up in a nicer way, but I did want to make one change:

I started using CSS to trick my Edit link into looking like my Delete button. After about 10 minutes of tinkering, trying to get them to match, I realized there was a path of less resistance. If I wanted both of them to be the same, why not just make them the same? So I made my edit into a GET form, which after the fact seemed extremely obvious and was way easier than tinkering with rounded corners in CSS.

It seems simple, but it made me EXTREMELY happy just to see those matching buttons.

Takeaway

This application more so than others I started to feel very comfortable with messing around with things to see what happens. Using gems like 'tux' and 'shotgun' made this very easy to do. I could open up a port and watch in live time as I edited the CSS or drop into a tux session to test my logic. I also started off setting up a good amount of seed data that really made it so much easier to do testing.

I'm also happy with how I set up the order in which to do things for this application. I think the way I did it made it very easy and having that order kept me from feeling overwhelmed with the number of things I needed to do. It helps that there is a logical order when using Active Record; you need to set up your database and models before you can really tackle your controllers, so you can actually have real data to test with. Controllers and views go hand in hand, so I focused on building them together as I added them.

Altogether I was proud of how well I understood the logic going into this project and I'm excited to learn more so that eventually I can create the full program!

Building a Tarot Dictionary in Ruby

Sebastian Spiegel — Thu, 12 Nov 2020 22:57:08 +0000

I spent the last week building my first ever program using Ruby.

I built a simple program for looking up tarot cards, specifically the meanings associated with the cards in the popular Rider-Waite tarot deck. Seasoned Tarot readers learn how to interpret cards by personal association, but most beginners rely on books to look up each card as they do a reading, or spread. I had a friend in mind when I came up with the idea for the program. She relies on a book to check the meanings of cards; the type is very small and it can take a while to find one card. My goal for this program was to make it so a person is only a few keystrokes away from the information they are after, avoiding the hassle of flipping through pages.

Loops on loops

To achieve the goal of having easy accessibility within the program I had to build many navigational loops within my methods. I decided to go with simple keystrokes for input, going off my own experience of interacting with similar CLI styles. I also thought of beginners to Tarot, who might get confused by the suit they need or the common mistake of hitting the wrong button. The case of the input shouldn't have mattered - why frustrate a user who put in 'b' instead of 'B'? Originally I found myself doing a lot of input == "E" || or input == "e" before I remembered to take a look at the methods available for me and swapped out for a much simpler input.case. I also wanted to get back to the previous list or starting a new search to be accessible inside the program, and this was mostly achievable thanks to the relatively small size of the information that was being provided.

new_input = gets.chomp
            if new_input.upcase == "B"
                major_arcana
            elsif new_input.upcase == "M"
                main_menu_display
            elsif new_input.upcase == "E"
                exit_program
            else
                puts "Invalid selection"
                major_arcana
            end

I avoided having invalid input shoot users all the way back to the main menu by instead redirecting back to the start of the method they were already in

Another big hurdle was around the concept of making sure every method I wrote was handling one specific job. There were more than a few hours spent taking methods apart and writing new classes, new methods, new modules, worried that I needed to spread the load out, only to realize what I was actually doing was undoing the good work I had done. But the process made me understand my code and how parts of my code related to each other even more. I certainly would have been done writing my program a lot sooner if I had more confidence and second-guessed myself less, but I think it was worth it, in the end, to spend that much more time understanding what exactly was going on step by step.

def self.card_display(array, index)
        puts "------------------"
        puts "  Name: #{array[index].name}"
        puts "  Type: #{array[index].type}"
        puts "  Suit: #{array[index].suit}"
        puts "  Meaning: #{array[index].meaning_up}"
        puts "  Meaning reversed: #{array[index].meaning_rev}"
    end

I created a method for the code to display the information in an easy to read format so that I could reuse it anywhere in the program without repeating the same 8 lines of code over and over.

When I first started planning the program I set a very simple goal: just have the code return the basic information when requested. I also wrote down a few extra functions that would be fun, if I had the time. A mistake I made was laying the groundwork for some of those early, telling myself I would go back and actually build them. In the future, I would rather only write the code I actually plan on working with at that time, and when it comes time to add in extra stuff then add it. I ended up having to do a lot more cleanup when I later decided that certain functions were either beyond my capabilities or just unnecessary for the scope of the project.

Overall, I absolutely love my program. It may be simple but it does exactly what I set out for it to do. At some point, when I have a larger skill set, I think it would be fun to revisit and add in some of the things I came up with but had to set aside. For now, I am excited to show it to my friends who read Tarot