Forem: Nicole Zonnenberg

Code Hot Takes

Nicole Zonnenberg — Tue, 16 Apr 2024 12:43:31 +0000

What's your coding hot take?

I'll go first:

Readability is more important than efficiency when writing code.

i.e. Well written code can be picked up and understood by most software developers/engineers and does not require a lot of parsing or jargon understanding.

My Must Have VSCode Plugins

Nicole Zonnenberg — Thu, 14 Dec 2023 22:13:40 +0000

I was helping someone set up their computer for some L33T CODING 😎🤘 and after I left them to noodle around, I made a list of some of my preferred VSCode plugins that make my life easier.

Code Editing and Productivity

Auto Close Tag: Automatically generate and close HTML or XML tags as you type, reducing syntax errors and improving coding efficiency.
Auto Rename Tag: Automatically renames paired HTML/XML tags, ensuring consistency.
Code Spell Checker: Identifies and corrects spelling mistakes within code and comments, contributing to code quality, readability, and error prevention.

Version Control and Code History

GitBlame (part of GitLens): Provides detailed information about each line of code, including author, commit details and time stamp. (Usually you figure out the person who made the mistake was you all along.)

HTML and Markup Language Support

DotENV: Makes reading and writing .env files easier through syntax highlighting, auto-completion, and error detection.
HTML End Tag Labels: Enhances readability and code accessibility by visually labeling closing tags, aiding in quick identification and preventing syntax errors.
Indent Rainbows: Improves code indentation visibility by adding colorful highlighting to different levels of indentation, aiding in code readability, navigation, and error prevention.

Visual Enhancements and User Interface

Material Icon Theme: This is a personal preference but I find these icons much easier to recognize.
Rainbow Brackets: Improves the visibility of nested structures, aiding in quick identification, and helps prevent bracket-related errors.

What are some of your favorite plugins?

ReactJS Good Practices

Nicole Zonnenberg — Wed, 01 Nov 2023 15:03:57 +0000

Written as an exercise for my engineering cohort.

Introduction

React is a free and open-source front-end JavaScript library for building user interfaces based on components and state management. It is maintained by Meta and can be used to develop single-page, mobile, or server-rendered applications with frameworks like NextJS.

ReactJS is a highly flexible framework that offers a wide range of features and capabilities to create highly interactive and dynamic user interfaces. It gives developers the flexibility to choose the best approach for their specific case, allowing for highly customizable and scalable applications. However, with this flexibility comes the responsibility to follow good practices to ensure the code is maintainable, efficient, and optimized.

This document is a record of “good practices”–not “best practices”–as no project utilizing ReactJS has the same requirements or constraints. These are the methods we recommend that will produce good outcomes, but are not strict standards.

At the end of this doc, you’ll also find a list of additional materials–resources, repos, tools, and playgrounds–where you can learn more about ReactJS and play with it.

Our ReactJS good practices

Componentization

TLDR: Break your application into smaller, simpler, reusable components.

A component is an independent and reusable piece of code. It serves the same purpose as JavaScript functions, but works in isolation and returns HTML.

Each component should have a specific purpose and should only be responsible for rendering that particular functionality. A component should be reusable, easy to understand, and follow best practices for state management and separation of concerns.

Class vs Functional Components

Use functional components as much as possible, as they are simpler, more concise, and easier to test. Use class components when you need to implement lifecycle methods, stateful logic, or when you need to access refs when React Hooks does not support certain functions. For example: getSnapshotBeforeUpdate, getDerivedStateFromError (such as in Error Boundaries) and componentDidCatch (source).

Class Component

Similar to functional component but has some additional features. The functional component does not care about the components in your app whereas the class components can work with each other.

✔ Good Example - A class component that extends the Component class and has a render method that returns a simple JSX element.

class Welcome extends Component {
  render () {
    return <h1>Hello, {this.props.welcome}</h1>
  }
}

✖ Bad Example - The below example has a constructor method and binds the handleInputChange method to the component instance, which can cause unnecessary overhead. The component is also not reusable because it has hardcoded logic for setting the name state.

class Welcome extends Component {
  constructor(props) {
    super(props);
    this.state = {
      welcome: props.welcome
    };
    this.handleInputChange = this.handleInputChange.bind(this);
  }
  handleInputChange(event) {
    this.setState({ welcome: event.target.value });
  }
  render() {
    return (
      <div>
        <h1>{this.state.welcome}</h1>
        <input type="text"
               value={welcome}
               onChange={handleInputChange} />
      </div>
    )
  }
}

Functional Component

Functional Components are JavaScript functions. Efficient functional components are used only when the component is not required to interact with any other components or require data from other components. They can inherit variables when called.

We will often recommend functional components over class components, as functional components are simpler and easier to test.

✔ Good Example - Takes an object as an argument and returns a simple JSX element; is reusable and easy to understand.

function Welcome(props) {
  return <h1>{props.welcome}</h1>
}

Testing the above code would only require the test of the component’s single function (in this case, the welcome header).

✖ Bad Example - While the below code is equally as valid as the example above, it is more complicated and not single function. In this component, we’re not only dealing with showing the welcome header but also the input where the user can input a new name, the handling of that change, and state management.

Testing the code below would require not only the header, but also the input, the event handler, and the state change.

While that might seem manageable, code and applications can get complicated quickly. So for scalable purposes, keeping the components simple is a necessity.

function Welcome(props) {
  const [welcome, setWelcome] = useState('');
  const handleInputChange = (event) => {
    setName(event.target.value);
  }
  return (
    <div>
      <h1>{welcome}</h1>
      <input type="text"
             value={welcome}
             onChange={handleInputChange} />
    </div>
  )
}

Presentational vs. Container Components

Presentational and container components can be either functional or class components. What separates these two components is their function in the overall application.

Presentational Component

Presentational components are concerned with how things look. It receives data and behavior from parent components.

Container Component

Container components are concerned with how things work. They provide the data and behavior to presentational or other container components.

Function Types

General Rules (TLDR):

Use function in the global scope and for Object.prototype properties.

Use class for object constructors.

Use => everywhere else.

Arrow Functions

While any arrow function can be replaced by a standard function, there would be little to gain from doing so.

Why use arrow functions almost everywhere?

Scope safety: When arrow functions are consistently used, everything is guaranteed to use the same thisObject as the root. A single standard function in combination with arrow functions can mess up the scope.
Code readability: Arrow functions are easier to read and write. Also, when almost everything is an arrow function, any regular (named) function stands out for defining the scope.

✔ Good Example - The below is an example of code that is simple and readable. It’s not hard to understand what is happening.

var comments = [];
articles.getList()
    .then(articles => Promise.all(
      articles.map(article => article.comments.getList())))
    .then(commentsLists => commentLists.reduce((a, b) => a.concet(b)));
    .then(comments => {
        this.comments = comments;
    })
}

✖ Bad Example - The below code works the same as above and for all intents and purposes is perfectly reasonable code. However, there’s a lot of extra characters that make reading the code more difficult.

var comments = [];
articles.getList()
    .then(function (articles) {
       return Promise.all(articles.map(function (article) {
          return article.comments.getList();
       }));
    })
    .then(function (commentLists) {
       return commentLists.reduct(function (a, b) {
          return a.concat(b);
       });
    })
    .then(function (comments) {
       this.comments = comments;
    }.bind(this))

Named Functions

Why always use regular functions on the global scope or module scope?

To differentiate the functions that should not access thisObject.
The window object (global scope) is best addressed explicitly.
Many Object.prototype definitions live in the global scope (i.e. String.prototype.truncate, etc.). These generally have to be named functions and can help avoid errors.
Function declarations are hoisted (meaning they can be accessed before they are declared), which is useful in a static utility function.

Note: Named functions can double as object constructors.

Object Constructors

Note: If you don’t initialize state and you don’t bind methods, you don’t need to implement a constructor for components.

Typically constructors are used for two purposes:

Initializing local state by assigning an object to this.state.
Binding event handler methods to an instance.

Do not call setState() in the constructor(). Instead, if your component needs to use local state, assign the initial state to this.state.

constructor(props) {
   super(props);
   this.state = { counter: 0 };
   this.handleClick = this.handleClick.bind(this);
}

State Management

State should be managed in the component where it is needed, and props should be used to pass data and functionality between components.

Separation of Concerns

TLDR: Separation of concerns is the practice of separating different functionalities of an application into distinct and independent components, each responsible for a specific task.

This separation enables developers to manage and reason about different components independently, reducing the complexity of the application and making it easier to maintain and scale.

Keep State as Minimal as Possible

TLDR: State should only contain data that is necessary for the component to function.

Avoid using complex state structures to make it easier to manage and debug. There are multiple libraries to help manage complex state management such as Redux, Hookstate, etc.

React Hooks

React Hooks let you use state and other features within functional components. You must import individual hooks from react.

It is possible to create custom react hooks. Custom Hooks start with use (i.e. useFetch).

Hook Rules:

Hooks can only be called inside React function components.
Hooks can only be called at the top level of a component.
Hooks cannot be conditional.

Event Handling

React has its own event system. Avoid using native DOM events or directly modifying the state.

Event handlers can pass a data argument using arrow functions. This can help race conditions that can occur.

For example, useEffect has a clean up function that we can take advantage of in two ways:

If there are going to be several requests, but only want to render the last result, we can use a boolean flag.

useEffect(() => {
  let active = true;
  const fetchData = async () => {
     const response = await fetch(...);
     const newData = await response.json();
     if (active) {
        setFetchedId(props.id);
        setData(newData);
     };
  };
  fetchData();
  return () => {
     active = false;
  }
}, [props.id])

In the example above:

Changing props.id will cause a re-render.
Every re-render will trigger the clean up function to run (setting active to false).
When active is set to false, the older requests won’t update the state.

The above example will still have a race condition (multiple requests), but only the results from the newest request will be used.

If we don’t have users on Internet Explorer, we can use AbortController.

useEffect(() => {
   const abortController = new AbortController();
   const fetchData = async () => {
      try {
         const response = await fetch(..., {
            signal: abortController.signal
         });
         const newData = await response.json();
         setFetchedId(id);
         setData(newData);
      } catch (error) {
         if (error.name === 'AbortError') {
            // Aborting a fetch throws error
            // Cannot update state
         }
         // Handle other errors
      }
   };
   fetchData();
   return () => {
      return () => {
         abortController.abort();
      }
   }
}, [id])

In this example:

AbortController is initialized at the start of the effect.
AbortController.signal is passed to fetch as an option.
AbortErrors are caught in the try.
Abort function is called inside the clean-up function.

Unlike the former example, the abort function cancels the in-flight HTTP requests so it will only show the last successful request.

Type Checking

TLDR: It is recommended to use TypeScript when possible in addition to PropTypes for type checking. TypeScript should catch all errors in compile, but having PropTypes will catch anything that snuck through at runtime.

A robust application should check and confirm that it is receiving and returning the right types of data. One of the weaknesses of JavaScript is how easily variables can change types.

// The variable zero can be assigned the integer zero
let zero = 0;
// But then I can reassign it to a string
zero = "zero"

Two of the most common ways to check for type checking for React are PropTypes and/or TypeScript. Both can be used separately or together; both differ in how they work.

propTypes and defaultProps

The PropTypes utility is available through the prop-types package. It is a runtime type-checking tool for props in React Applications. With PropTypes, you can define types of props expected in a component.

However, PropTypes does not provide warnings in production applications. Warnings are only printed in development.

import PropTypes from 'prop-types';
const Component = ({ fullName, age, courses, enrolled }) => {
  ...
}
Component.propTypes = {
   fullName: Proptypes.string.isRequired,
   age: Proptypes.int.isRequired,
   courses: Proptypes.array,
   enrolled: Proptypes.bool.isRequired
}

TypeScript

TypeScript is a free and open-source programming language that adds static typing with optional type annotations to JavaScript. Unlike PropTypes, which does type-checking while the application is running in the browser, TypeScript does type-checking during compile time when the TypeScript is compiled in JavaScript. It shows errors in the integrated development environment (IDE) so the problems can be caught earlier.

Here is how the above example could be implemented in TypeScript:

import React from 'react';
interface ComponentProps {
  fullName: string;
  age: number;
  courses?: Array<string>;
  enrolled: boolean;
}
const Components: React.FC<ComponentProps> = ({
  fullName,
  age,
  courses,
  enrolled
}) => {
   // ...
}

This means that the application will not compile if the code tries to assign a variable that has been assigned one data type (re: a number) another data type (re: a string).

Note: Both TypeScript and PropTypes will not catch these issues in production.

Debugging

React Developer Tools

TLDR: Browser extension for debugging and inspecting React components. It helps visualize components and their state in real time.

The easiest way to debug websites built with React is to install the React Developer Tools browser extension. It is available for several popular browsers:

Testing

Recommended Testing Frameworks & Utilities:

Tips & Tricks

Avoid Copying Props to State

⚠ This is a common mistake:

constructor(props) {
   super(props);
   this.state = { color: props.color };
}

The problem is that it’s both unnecessary (you can use this.props.color directly) and creates bugs (updates to the color prop won’t be reflected in the state).

Error Boundaries

Class components that catch all errors/exceptions thrown at children component levels.

Note: ErrorBoundaries should be declared as class components because they do not support functional components.

// ErrorBoundary Component
class ErrorBondary extends Component {
  constructor(props) {
    super(props);
    this.state = {
      hasErrors: false
    };
  }
  static getDerivedStateFromError() {
    return { hasError: true };
  }
  render () {
    if (this.state.hasError) {
      return <ErrorMessage />;
    }
    return this.props.children;
  }
}

Linting

React Fragments

Individual components can only return a single element. With Fragment (imported from react), you can group elements together but it does not add any element in the DOM.

import { Fragment } from 'react';
const Frag = () => {
  return (
    <Fragment>
      <ComponentA />
      <ComponentB />
    </Fragment>
  )
}
// Or after Babel 7
const NewFrag = () => {
  return (
    <>
      <ComponentA />
      <ComponentB />  
    </>
  )
}

Additional materials

Official Resources

Certifications & Courses

Communities

Frameworks

Playgrounds

Interactive:
- https://playcode.io/react
- https://stackblitz.com/edit/react-playground-practice

Resources and Tools

Start a New React App
React-Redux Links - List of tutorials and resources for React/Redux.
React Developer Tools - Inspection of React component hierarchy
React Hook Form
React Hot Loader - Tweak React components in real time
React Loadable - A higher order component for loading components with promises
React Router
Storybook
tsdx - Zero-config CLI for TypeScript package development

The Best* Tech Interview

Nicole Zonnenberg — Thu, 09 Feb 2023 20:52:52 +0000

*At the date of this article.

I do not know many people who would claim to love interviewing for jobs. The interview process can feel like torture, especially when there are multiple hurdles to clear before the final hired/not hired answer. It has become the norm to talk with multiple people on different rungs of a company ladder, emphasizing not just about the job, but benefits, company culture, and possibly more.

In the tech industry, a necessary evil is the tech interview as a way to assess an applicant's technical skill. After tens of tech interviews, I can confidently say I have not experienced the same tech interview twice. They have ranged from understandable to infuriating, making me wonder how the interviewers could possibly know my skills well enough for the job I was applying to.

I have written out code on paper and white board; done quizzes; created a small app from scratch; live coded while one or more interviewers watched on; answered questions about hypothetical scenarios, to name a few types of technical interviews.

At best, I would remain neutral about the job; at worst, it would leave me discouraged about the whole interview process.

But this article is about one tech interview that was different.

Full disclosure: I didn't end up getting the job. But the interview has stuck with me. And I wanted to share what made it such a good experience so that other engineers could be on the lookout for similar green flags in the hiring process.

The Technical Interview:

The Process

After a 40 minute screening call with the recruiter, I was given the outline of the next part of my application process for a full stack engineer position. I would have two tech interviews, one for backend code and one for frontend. 48 hours (minimum) before the scheduled tech interviews, I would be given access to the relevant pull request (frontend or backend), that would mock code from a supposed teammate for me to review through asynchronous comments.

The technical interview would go over my background, my comments, and continue from there over the course of 90 minutes.

Step 1: Receive and review two Pull Requests before the respective interviews.

While I was told that I would have up to 48 hours for both pull requests (commonly known as PRs), I was given over a week with each pull request. Without even starting the actual PR reviews, the company was making sure I had some knowledge of git; that I could clone the repo with the PR branch down to my computer and run the code locally.

The exercise itself was clearly mimicking a regular task in the day-to-day for the job I applied for. By reviewing code, I was asked to read, interpret, and form meaningful opinions about the code and communicate those opinions through written comments. The instructions linked to a page for a preferred comment convention, which checked my attention to detail and ability to follow directions.

In practice, this task showcased my communication skills asynchronously and through text, a must for most collaborative coding projects nowadays. I made sure to offer solutions when I found ways the code could be improved. I also made sure to comment on what I thought the PR author did well or if I learned something from their code.

Overall, I was thrilled because I could take my time with it. The PRs were small and gave both myself and my interviewers an idea of what it would be like if I was a member of their team.

I also double checked whether or not my solutions worked locally before I made the comment. This really helped me in the next step:

Step 2: A 90 minute tech interview.

I have had technical interviews as short as twenty minutes and as long as three or more hours, so this was definitely on the longer side. For most of those interviews, I was lucky to even have an idea of what to expect. This was the rare occasion I felt incredibly prepared because of my previous task of reviewing the pull requests ahead of time.

The first 15 to twenty 20 was spent on introductions, a very light overview of what the interview would entail, and then a walkthrough of my comments and the code itself. I was given a chance to clarify and expand on any of my comments.

After that, we spent the majority of the time “pair coding” as I “took over” the pull request and applied the changes I had commented/recommended in the PR review.

I think this is a brilliant way to do a live coding interview. At this point, I already had a*t least 48 hours with this code* and took advantage of it. I had tried out several of my suggestions to make sure they worked before I left my comments. And, once again, it mimicked a real-life situation that I would probably experience on their team.

The interviewers were mostly silent, allowing me to “drive” or lead the live coding exercise. However, they were not completely passive. I was allowed (and did) ask questions as we combed through the code. In one situation, I clarified that I would ask the product/design team if there were any conventions when changing the layout on the frontend and confirmed that normally I would use an existing component library. I was able to convey that I understood the makeup of a tech team and how to work with different disciplines.

Another example of this interview giving a real pair coding experience is that the engineer was able to see that I understood the code and the end goal, but for whatever reason was not able to find the best answer for the framework. This allowed him to course correct, and I was not stuck for too long on a problem that I could have figured out given more time, but didn't let me wallow in fruitless internet searches.

This pair coding exercise was also a chance for me to get a feel for the company’s culture. Beyond the still present pressure of an interview, the facilitators treated the sessions like we were already teammates. They talked with me through my solutions, sometimes tweaking the parameters to see how I might solve a slightly different problem.

On more than one occasion, both interviewers were able to point out specific tricks that were unique to the frameworks or practices their team preferred. They were quick to affirm that I was on the right track and only helped me when it was obvious I would figure it out given enough time on my own, but wanted to see what I would do at the next step before time ran out.

Final Thoughts:

How often has a promising candidate been hired and started, only for their team to later learn that they’re unwilling to learn a new stack or practice? Or that they grate with other teammates or the scrum master? Or that they have a rigid way of thinking that makes any sort of communication painful?

Or, from the candidate’s side, how often does the interview feel like an honest representation of the company and the job they are looking to fill?

The process described above, while not perfect, left me feeling like I was able to show my range of knowledge and skills (both “hard”--writing code, problem solving--and “soft”--communication, teamwork). I was not frustrated and worried that I didn’t know what the company was looking for or wondering how I could have done better in the moment. While I was disappointed when I wasn’t offered the job, it was a valuable learning experience. I had a good idea of what skills to improve on.

I can only guess what it was like on the interviewer’s side, but I felt like they had the best picture of me as a candidate and potential employee/teammate. When they said no, they must have felt confident I wasn’t right for the job. And honestly? If that’s the case, I’m glad I didn’t get the job. That’s what a good hiring process is for; it’s a place where both the candidate and the company get to evaluate each other to make sure it’s a good fit.

Connect with Me

What are the best questions you can ask as an interviewee?

Nicole Zonnenberg — Wed, 20 Nov 2019 15:28:38 +0000

When you are interviewing for a job, what are some of the best questions you can ask to determine that if the company is a good fit for you?

This is a great way to communicate what you're looking for in a company. It's one of the few times you have almost full control in the interview. Not to mention, it can show the company that you are taking this as seriously as they (hopefully) are.

Some of mine include:

What is the turnover rate at your company?
Turn over is normal for any company, but I'm always wary of companies that have a high turnover rate or claim to have a very low or non-existent turn over. Some companies can be very upfront with having a high turn over rate, whether it's their industry or their culture.
Do you and your colleagues spend time together outside of work?
Or "Do you and your team eat lunch together often?" This (hopefully) conveys I'm looking for a good/healthy work relationship with my future coworkers.
Is there an opportunity for mentorship at your company?
Not a requirement, but it shows that a company has an interest in their employee's growth in their positions, skills, etc.
Is there an opportunity for continued education?
Working in tech, we are dealing with constant changes in languages, tools, and applications. Most companies I've interviewed with either provide a stipend or will subsidize classes, courses, and conferences. Again, not a deal breaker, but it shows the company is willing to invest in its employees.

Cover Your Base (Element)

Nicole Zonnenberg — Sun, 12 May 2019 13:51:25 +0000

The <base> tag is a child of the <head> tag that can pass down a specific URL to all link elements in an HTML document.

<head>
    // If the <base> tag contains a URL

    <base href="http://fakeurl.dev/">
<head>

You can write <a> tags as the following:

// A simple <a> tag without a specific 
<a>Link One</a>

// An anchor
<a href="#anchor">Link Two</a>

// A path from the original index.html of the URL
<a href="/fakepath">Link Three</a>

The links will direct as follows:

// A simple <a> tag without a specific 
<a href="http://fakeurl.dev/">Link One</a>

// An anchor
<a href="http://fakeurl.dev/#anchor">Link Two</a>

// A path from the original index.html of the URL
<a href="http://fakeurl.dev/fakepath">Link Three</a>

You can also pass down a specific attribute, such as a target.

<head>
    <base target="_blank">
    // will ensure that all links will open in a separate tab.
</head>

Note: There can only be one <base> tag in a head. If there is more than one it will recognize only the first href and target values.

My Bootcamp Experience

Nicole Zonnenberg — Thu, 11 Apr 2019 15:40:46 +0000

Before

The day before I started my coding bootcamp, this is what my car looked like:

Don't worry, my insurance covered it and I got it fixed before the end of the month.

This would not be my only car troubles over the course of the next three months, but it certainly would be the worst. I don't remember being angry or upset, just sighing and adding it to my very long to do list.

In less than 24 hours, I was going to start the Web Development Immersive at General Assembly (GA). Needless to say, I had a lot of other things on my mind. Like how for the next three months I was going to commute from Baltimore to DC, five days a week, for 9 to 5 classes where I would learn over 10 different programming languages and practices.

Over the course of 2018, I had been taking stock of my life, where I was, where I wanted to go, what I wanted. College had not answered these questions, so I was reluctant to go back to any formal schooling.

I had the benefit of being self taught in HTML, CSS, and some JavaScript, so coding and the logic was not completely foreign to me. I was, in fact, working as a freelance front-end/email developer when I applied to GA. I was enjoying the work, but didn't feel confident enough to apply to any full time positions.

After talking with friends who had completed similar programs for similar reasons (a.k.a. a complete overhaul in their career) and research into programs that met my qualifications (specifically, I wanted an in person experience), I applied and was accepted to GA.

During

To say that GA made sure we had realistic expectations is probably an understatement. While reviewing our HTML, CSS, and Javascript pre-work, they made sure that we understood what we had signed up for.

One way they chose to illustrate this is with a graph:

There were days where around 4pm I was so overwhelmed I could not take in any more information and had to listen to static or instrumental music on the train.

My class quickly learned that this wasn't going to operate like any other class setting we had experience with. The teachers could not afford to answer every question in depth until we were satisfied, otherwise we would not cover everything in the lesson and there was zero room in the schedule to recover any time lost.

If something wasn't covered in class, it was up to us to do the extra legwork in addition to whatever supplementary work was assigned for after hours.

After three solid months of this, I can now say with confidence that it was more like this graph:

I feel lucky to have had such patient teachers, who did try to answer our questions to the best of their abilities without digging into too much of our time.

Requiring us to learn the material on our own on some level helped instill a sense of self-reliance that we will carry with us throughout our developer careers.

Lessons Learned at GA

(That Wasn't Just Coding)

Sleep is important.

Sacrificing sleep may help to finish one or two assignments, it greatly decreased the likelihood I would be mentally present in a lesson. Not to mention the amount of times I went to sleep grumbling about a problem and then waking up, looking at it with fresh eyes, and solving it in minutes.

Make friends.

While I may be skeptical sometimes when authority figures tell me "This is the best class I've ever taught", I somewhat believed them when it came to my cohort. We were a strong mix of different strengths that complimented each other almost scarily well. Not only did it emphasize the strengths of team coding, but it also helped to have people to commiserate with when our lessons got particularly challenging.

Be Honest

With yourself. With your teachers. Know when the struggle is what's helping you vs. hindering you. Know your limits. Let your friends know how you're doing, and not just when things are going well.

Because here's the real truth: No one wants you to fail. Not your family, not your friends, not your bootcamp. Everyone wants you to live your best life, but they can't help you unless you tell them when you need help.

Before my time at GA even started, I told a good friend not in the program how I thought it would go.

"I'll probably start off super excited and killing it. Then will come the mid-slog where you won't see me for weeks, or if you do, I'll look like the undead. And then, just when I'm close to the finish line, when I'm almost done, I'll be ready to give up everything because I'll be impatient to move on to whatever's next."

And lo and behold, it played out almost exactly how I predicted. When I was two weeks out from graduation and pretty much over everything, my friend patiently reminded me that I had predicted all of this and gave me a much needed pep talk.

After

The relief that I felt after completing GA was quickly replaced with the anxiety of a job search. Now, you're probably going to roll your eyes when I tell you how long my search was, but searching for a job without any regular work to rely on for an income brought me to a very dark place. I suffer from anxiety and depression and when the rejections, however polite, started rolling in, it was difficult.

I relied a lot on my friends, who took great pleasure in reminding me how everything worked out when I happily accepted a job a mere two weeks after graduation.

I'm thrilled to be able to say that I accepted a position as a JavaScript Dev consultant with the US Coast Guard, which honestly feels unreal.

It also means DC isn't done with me yet!

I am so grateful for the experience at GA and everyone who supported me in any way. And I can't wait to see what this next chapter of my life holds.

Some Numbers

143 hours of transportation (roughly)
38 days of formal instruction
36 hours of audio books listened to
20 (ish) days dedicated to projects
5 days of being moderately sick
4 portfolio worthy projects
3 dance events where I was on staff
2 flat tires (so many car troubles!)
1 job in web development!

Making An Animated Timer With CSS & JavaScript

Nicole Zonnenberg — Mon, 25 Feb 2019 21:07:48 +0000

With my time at General Assembly rapidly coming to an end, there is less direct instruction and more encouraging us to play in the huge sandbox that is web development. Recently, an entire day was dedicated to us teaching ourselves either the beginnings of another language or skill not covered by GA's curriculum.

I chose to create a JavaScript Timer with CSS animations.

Why did I choose this subject?

I have an idea for my capstone project that would be greatly enhanced visually by CSS Animation triggered via JavaScript.

What problem does it solve? / Why does one use it?

It doesn't so much solve a problem but has the potential to make an existing project more aesthetically pleasing to the user.

Being visually pleasing makes user interface easier to understand and navigate as well as easier to sell to potential buys or users.

What are the alternatives?

I would have little to no styling or a static webpage where the only moving part is the JavaScript timer, which can look fairly unappealing or boring.

Teaching Myself

Step One - Making the timer.

Luckily the internet--in its vast wealth of information--has many examples of JavaScript timers. I used one from w3schools and modified it to my specifications (counting down from 1 minute).

Note: I also had it restart at 1 minute after the timer reached 0 in order to make sure the animation worked more than once in a page load.

Step Two - Add basic CSS styling.

Determine what a static version of my countdown timer will look like and define any necessary classes. (This was easy enough.)

Step Three - Learn About Animation.

Animation vs. Transition

A transition is applied to an element and specifies a change that happens gradually over a period of time.

An animation just runs in the background regardless of anything else happening via the user or the rest of the website.

At this point I realized that the title of this whole project (Making An Animated Timer With CSS & JavaScript) is a lie. What I am actually making is a Transitional Timer with CSS & JavaScript.

Step Four - Add animation independent of JS

I was able to add a div that would shrink over the course of a designated time in the CSS code.

.visual-timer {
    border-top: 50px solid #004D00;
    margin: 5% auto;
    width: 50%;
}

.width-change {
    /* Animation code */
    -webkit-animation-name: widthChange; /* Safari 4.0 - 8.0 */
    -webkit-animation-duration: 60s; /* Safari 4.0 - 8.0 */
    animation-name: widthChange;
    animation-duration: 60s;
}

@keyframes widthChange {
    from {width: 600px;}
    to {width: 0px;}
}

Step Five - connect the start of the animation with the start of JS function

By adding visualTimer.classList.add("width-change"); at the beginning of the function I am able to initiate the animation when the timer started to count down. However, it would only work once and then not re-initiate when the timer reset.

This was easily fixed by adding visualTimer.classList.remove("width-change"); when the timer reset, allowing the function to re-initialize the animation when the function looped thru.

What are the biggest conceptual hurdles (if any) you encountered when researching this?

At this point, I was still not happy with how the animation didn't reflect the timer exactly. It was not consistent so that it was over half way thru its countdown when the timer was at 30 seconds.

But then I found another way to breakdown the animation so that it did not go as quickly.

@keyframes widthChange {
    0%   {width: 600px;}
    25%  {width: 450px;}
    50%  {width: 300px;}
    75%  {width: 150px;}
    100% {width: 0px;}
}

This way it hit half way thru the length of the animation when the timer was at 30 seconds. However, the rate at which the width changes still isn't as consistent as I would like.

What article(s) or forum(s) was most helpful to you in learning this?

https://css-tricks.com/controlling-css-animations-transitions-javascript/
https://www.sitepoint.com/css3-animation-javascript-event-handlers/
https://www.w3schools.com/css/css3_animations.asp
https://www.w3schools.com/howto/howto_js_add_class.asp
https://gomakethings.com/two-ways-to-set-an-elements-css-with-vanilla-javascript/

For the Future

Aside from a more consistent animation, I would like to have the animation duration change based on the timer. So that if the timer was longer or shorter, the animation would speed up or slow down to match.

Possible solutions I have in mind are to integrate SASS or build the styling in the JavaScript itself and have the duration be variables. If anyone has any suggestions, they are welcome!

A modified version for CodePen

Basic Color Theory for Web Developers

Nicole Zonnenberg — Fri, 25 Jan 2019 13:37:16 +0000

You would be hard-pressed to find an art class without a color wheel hanging somewhere on its walls. If you’ve ever taken an art class, you might have been introduced to paints and mixing paints by creating one of your own.

You would have learned about primary and secondary colors. Maybe even tertiary colors if you continued to take art after elementary school.

But unless you studied art in any capacity at a high school level or higher, you probably did not realize that the color wheel is the simplest way to demonstrate color theory, the practice of mixing colors and the study of specific color combinations.

But what is color theory?

A brief history: Color theory emerged when impressionists like Edouard Manet, Edgar Degas, and Claude Monet (you might have heard of them) started experimenting with capturing light rather than a perfect likeness.

Monet's Haystacks

Short answer: It comes down to how the human eye translates light waves into colors. Colors that match have similar or complementary waves.

Color theory can get into the science of light waves, and why colors look the way they do. For the purposes of this article however, we are going to focus on the questions:

Why do certain colors match?
How do I pick the "right" colors?

Color matching seems to be a "you either have it or you don't" kind of thing. Or the longest, most excruciating part of designing a webpage or an app is determining which exact green to use for your background.

Whatever your color-related woes are, here's a little cheat sheet to look at:

Level One: Monochromatic

Monochromatic is simply one or various shades of one color.

In WebDev: This is choosing a single Hex Code and making it lighter or darker without effecting the hue.

This is the simplest way to color your webpage. Sites such as Facebook and Twitter use the (mostly) monochromatic color scheme to their advantage. Black, white, and a sky blue, this color palette is part of what makes these social media apps so easy to use.

The only differentiating colors come from users' avatars, links and photos, which can become recognizable to frequent users, making it easy to find posts by their favorite accounts.

If there were more colors on Twitter's webpage, it would be harder to differentiate separate posts and who posted what.

As a rule, even if you want more than one color, it's good to have one main color--either as the background color or the main header color.

Pro-Tip: If your webpage is only monochromatic make sure each shade is easily discernible from one another. Otherwise your webpage may not be user friendly if they cannot read text or separate the webpage's elements.

Level Two: Complementary Colors

But what if you want more than just different shades of orange? What if you want your links to stand out but not clash with the nav bar or the background color?

If we're following basic color theory, one of the best ways to choose a color for immediate emphasis is to look for a complementary color.

A complementary color of another can be found at the exact opposite of side of the color wheel.

Each primary color matches with one secondary color for their complementary color. An easy way to remember which colors to match is that the secondary color matches with the primary color it does not use. For example: red's complementary color is green, which is made out of blue and yellow.

Pro Tip: Add colors one at time and keep it simple. Do not sacrifice a clean, usable layout for a full rainbow. Otherwise you might accidentally channel the classic 90s websites like this.

Leveling Up

As you get more comfortable with your burgeoning design skills, feel free to push the envelope. Color should never be scary work to with. Always be on the look out for developers and designers who utilize color masterfully. Ask what you like about it, what you don't like, and why. This is how you build your own tastes and brand.

WebDev Hack

Create color combinations/palettes with their hex codes/RBG numbers on hand. Or if you're a fan of SASS, store them in files to import on bigger projects. Especially if your job is to create the structure, not the look (which is determined by someone else, a customer or manager), then just view these colors as place holders that make the website easy to look at.

Just make sure:

Everything is readable.
Links, headers, anything you want to put emphasis on is obviously different from plain text.
A user can easily discern different parts of your webpage (i.e. the nav bar, main content, separate the articles, etc.).

Online Tools

Shout out to Doug R. Thomas, Esq. for the following links:

Color.Adobe.com
WebAIM - Color Contrast Checker - makes sure that text is readable over backgrounds.
Coblis — Color Blindness Simulator - tests screenshots of layout with colorblindness filters to make sure your content is readable for all audiences.

Continued Reading

Hopefully picking a color or a color palette for your website, page, or app is less daunting after reading this article. If this topic interests you, I highly recommend reading more about the subject. We've only really touched the surface, but you can get into hues and shades and more.

Ultimately, there is no “wrong” answer when it comes to color, especially if you are making a project for yourself. Many assume taste is something you’re born with, but really it’s looking at successful designs and taking inspiration, trying different combinations, and finding what works best for you and your brand. Good luck and go create!

My First Bootcamp Project: Tower of Hanoi

Nicole Zonnenberg — Mon, 14 Jan 2019 02:25:23 +0000

Background

A little over one month ago, I quit my life and started a web development intensive at General Assembly. It has been a rollercoaster of emotion and feeling and an experiment of 'How Little Sleep Can I Survive On And Still Function'. On alternating days I have celebrated or wanted to tear my hair out, which I hear is like being a developer in real life, so I guess I'm doing something right.

This past week, my fellow devs in training and I tackled our first project: make a game using the skills we have learned over three weeks in HTML, CSS, and Javascript. We were given a list of five games to choose from (or could propose our own idea to be approved of by our instructors). I chose the Tower of Hanoi because it seemed simple a simple case of identifying divs and, in a click event, manipulate two out of the three divs that would be my towers.

However, true to form, I decided to add the extra challenge of using jQuery after finding this code:

tower.prepend($('<li class="disc disc-' + i + '" data-value="' + i + '"></li>'));

Which in tandem with this code in SASS:

@for $i from 1 through # {
    .disc-#{$i} {
        width: #px * $i;
    }
}

I could theoretically create a game where the player could choose the difficulty level by adding and subtracting the number of discs in the game. Which I have to mention at this point was not a requirement at all.

But at a glance, it did not seem too much of an extra hurdle and I already knew how I would build my tower with two additional buttons to add and subtract discs:

  function buildTower(tower) {
    $tower.html("");
    for (i = 1; i <= discNum; i++) {
      tower.prepend(
        $('<li class="disc disc-' + i + '" data-value="' + i + '"></li>')
      );
    }

I used the codes above to generate list items increasing in size. I struggled with bootstrap's established CSS code, but was able to figure out how to override it. However, once I built my first tower, the struggle began.

Building The Game

The real challenge was how to remove the top list item from the original list, then recreate it in another list. There were several iterations where I successfully cloned my full tower in each box, but then had three towers and could not erase them.

The trick was to create a variable deck = [] and assign it the first list item. Once I had assigned the first list item to them empty array, I could delete then create an identical list item in the new tower.

Then I was able to recreate the correct disc, only to have it placed underneath the larger discs. This made it impossible to play the game correctly.

After reading more about jQuery and jQuery methods, I was able to find the .append method which added a new list item at the beginning rather than at the end.

Now that I had met the requirements for a working game, I wanted to add one more feature: two buttons that could add and subtract discs to increase or decrease the difficulty level.

The logic was simple enough:

  // Increase/Decrease discNum (not working?)

  $(".ad").click(function() {
    if (discNum < 7) {
      discNum++;
      return DiscNum;
    }
  });

  $(".sub").click(function() {
    if (discNum > 3) {
      discNum--;
      return DiscNum;
    }
  });

Another learning curve and talking to my instructor, I realized I made a pretty beginner mistake.

  // Increase/Decrease discNum

  $(".ad").click(function() {
    if (discNum < 7) {
      discNum++;
      buildTower($tower.eq(0));
    }
  });

  $(".sub").click(function() {
    if (discNum > 3) {
      discNum--;
      buildTower($tower.eq(0));
    }
  });

For The Future

I definitely want to continue working on this game. Now that I did it in jQuery, I think there would be a lot of learning potential to translate to Javascript.

I would also like to add a timer element that starts with the first move and ends when the player finishes; a win scenario either lighting up the whole tower or having some sort of message appear saying the player one; add a move counter to see if the player can beat their personal best; and make it mobile responsive.

Overall, this was a pretty fun challenge that definitely had moments that made me have to walk away from my computer, but easy enough that (sometimes with a little guidance) I could figure it out and overcome obstacles.

I cannot wait to look back on this and see my growth as a web developer and compare it to future projects.

If you would like to play the game, you may do so here.

Thank you.

Warm Up For Developers: Recreating A Website, Breaking It Down, Building It Up

Nicole Zonnenberg — Mon, 07 Jan 2019 20:15:21 +0000

A warm up is considered essential for any type of strenuous activity. Athletes - both professional and amateur - will stretch and start with light physical movements before building to their full workout. Musicians will warm up their instruments and appendages with scales and tuning before attempting their next piece. Artists will do warm up sketches before jumping into their current endeavor. All of these groups are not only preparing their bodies, they are preparing their minds for the larger tasks at hand. They are getting into a rhythm before attempting harder, more strenuous challenges. In some cases, it is necessary to warm up in order to prevent injuries.

Coding, like the previously mentioned practices, also benefits from constant practice and warm ups. An excellent warm up for any web developer is to recreate an already existing website. Depending on your level, you can add certain challenges to stretch your code skills.

Pro Tip
Try adding a time limit. How much of a full website can you make in an hour? Thirty minutes? How functional do you want to try and make your mock-website?

Recreating a website can seem like a monumental task, especially for beginners. If you are someone who has attempted to recreate an existing website or create a website from scratch, you probably have realized that even the simplest website can require hundreds of lines of code.

What I hope to accomplish with this article is to help you look at a website and quickly break down its visual components and (hopefully) make the exercise a little bit easier.

The Warm Up

So you have picked your website, determined that it is not too difficult or too easy for your warm up goal, and you are ready to work! But where do you even start?

For this article’s example, I am going to look at Medium’s homepage and break it down.

It may look simple, but once you start diving into the code, you will realize that it is composed of divs within divs within divs. In fact, you may think it is divs all the way down.

One of the first things you may realize is that Medium is an infinite scrolling website. There is no “end” but it will keep regenerating articles for as long as you are willing to scroll. For the purposes of this article, I’m going to recommend adding a footer and limit yourself to ten articles in the content area.

Breaking It Down

When you first look at the page, think of the whole of the content as one block.

Does it go all the way from one side of webpage to the other? Is there a significant distance from the top of the webpage and the bottom when you scroll all the way down?

For Medium there are significant borders around the whole of the content, so in your <body> tag you will make a general <div> container that will be these specific dimensions using CSS or SASS.

That was easy. But now we have start looking inside the box and all the pictures and texts, right? Nope! Because, we can still break this big box into smaller boxes.

This is much more manageable and we’ve already created three more easily definable <div> tags inside that first much larger <div> container.

In fact your code--or psuedocode--should look very similar to:

<body>
    <div id=”container”>
        <div id=”header”>
            Header
        </div>
        <div id=”content”>
            Content
        </div>
        <div id=”footer”>
            Footer
        </div>
    </div>
</body>

All styling and positioning will be done in your CSS or SASS file(s) that are connected to the div id's. I recommend setting the dimensions and positions of each <div> as they are created. This makes it easier to problem shoot as you continue to add more elements.

Now we are going to break down each section’s individual components. Remember: it is <div>s all the way down.

Header

That's okay, but we can still break it down even more:

For a warm up or exercise, it does not really matter what you call each section in your code. You will have to remember what you named what section or div. If you have to go back and fix something or debug, it will be a nightmare to figure out which div to target.

I will also point out that the featured section is actually three columns, with the third column broken up into two more sections. It all depends on how small you are willing to let your <div>'s go.

Content

Once again, that is good. But we can do better.

My examples will stop here, but I hope that you can see just how specific you can get with just <div>’s or <section>’s in your code.

We are not going to worry about the footer here since it is a border we self-imposed onto this exercise. But if there was footer, we would break it down if necessary into its components. Footers usually contain a note about the company’s ownership of the website, some social media links, and some contact links.

In Practice

Use these exercises and warm-ups to experiment how many or few <div>’s or <section>’s you are comfortable working with. How many is too many? When does your code start to get incomprehensible?

The answers to these questions and more will depend on your preferences as a coder.

When you feel that you have broken down your website into the smallest and most manageable chunks--the key word being manageable--you are now ready to add content.

I would not recommend getting super caught up in replicating a site’s content for this exercise. Especially if you chose a site whose page(s) update regularly. However, you will need to insert text and pictures (if the site has pictures) in order to make sure that you are being honest in your recreation.

For pictures, here are some sites that I enjoy using:

http://unsplash.com
http://fillmurray.com

Final Thoughts

The brain, like any muscle, performs better when you practice skills--like coding--regularly. Even if you do not finish completely, taking a website and trying to recreate it will improve your skills as a coder; familiarize you with different layouts for different sites; and provide you with an open sandbox to experiment and challenge yourself in a safe environment.

I hope that this article has helped make breaking down and building up a website an easier task.