DEV Community: Jennifer Lyn Parsons

A Refactoring Breakdown

Jennifer Lyn Parsons — Mon, 21 Oct 2019 22:54:41 +0000

I thought it would be interesting and potentially useful to others, to work my way through a refactor. It's not a topic I've run across very often and, especially early on in one's career, it can be challenging to understand exactly how to refactor something. Once code is written and working, trying to see areas where it can be improved can be tricky.

In addition to showing how a refactor can work, this is giving me a chance to see how much I've been learning. For the purposes of brevity, I'm going to limit this to a single file on a fairly basic project.

I set up a link directory about a year ago, based off of my Firefox bookmarks. There were plenty of challenges in building the app, not the least of which was that I was relatively new to React, though not to JavaScript or web development in general. In building the app, I focused on just getting the job done and working, even if it meant sacrificing a lot of the more DRY or frankly better ways I could have written it.

A year on, I've decided to go back to the project and clean it up, give it better structure, and implement my more refined development process. Let's dive into one of these files and see where it goes!

Our starting point

The file I'll be using as an example is the list of links that appears under each topic. When I opened the file up, this is what I found:

import React from "react";
import { Link } from "@reach/router";
import { LinkListProps } from "../../interfaces";

 class LinkList extends React.Component<LinkListProps, {}> {
  linkElement(linkID,linkURI, linkTitle) {
    if (linkURI) {
      return (<li key={linkID}><a href={linkURI}>{linkTitle}</a></li>);
    } else {
      return ""
    }
  }
  render() {
    return (
      <ul>
        {this.props.links.map(link => {
          return this.linkElement(link.id link.uri, link.title)
        })}
      </ul>
    );
  }
}

 export default LinkList;

Okay, this is not so bad, but I can see some immediate places this can be improved. There's a lot of extra syntax in general, for example. Let me break down the changes I'm making.

Swapping Typescript for PropTypes

I've stopped using Typescript in my personal projects over the last year. I think it's awesome and for projects that have a team larger than one and a project significantly more complex than this one, I would argue it might be essential. However, at this level of complexity, Typescript is heavy-handed and adds more to the maintenance time for the project. I would swap it out for more simplified PropTypes.

import React from "react";
import { Link } from "@reach/router";
import { PropTypes } from "prop-types";

 class LinkList extends React.Component{
  linkElement(linkID,linkURI, linkTitle) {
    if (linkURI) {
      return (<li key={linkID}><a href={linkURI}>{linkTitle}</a></li>);
    } else {
      return ""
    }
  }
  render() {
    return (
      <ul>
        {this.props.links.map(link => {
          return this.linkElement(link.id link.uri, link.title)
        })}
      </ul>
    );
  }
}

 export default LinkList;

 LinkList.propTypes = {
     links: shape({
         id: PropTypes.string.isRequired,
         uri: PropTypes.string.isRequired,
         title: PropTypes.string.isRequired
     })
 }

Logic Streamlining

Time to look at the logic itself. In this case, the changes I make aren't going to improve performance in any measurable or meaningful way. It will make the file a little easier to read, which is important. It also reduces the lines of code, which also reduces the tests we'll need to write.

In retrospect it looks very verbose to have the linkElement function there when all it actually does is process some simple logic. Originally this had been set up with the anticipation of needing to add more functions to the component and this would separate concerns a bit. However, I've moved toward avoiding premature optimization in my code so this separation is now overkill.

I'll also note that there's nothing inherently wrong with this code. It compiles properly and the browser does what I would expect it to do with the logic as it's written. With the changes I'm making, what I'm looking to do is improve the readability. I want other developers to be able to read my code as easily as the computer does. So, the changes are about style, more than about substance.

Before I delete the function entirely, let's see what it would look like cleaned up a bit. Here's our current version:


linkElement(linkID,linkURI, linkTitle) {
    if (linkURI) {
        return (<li key={linkID}><a href={linkURI}>{linkTitle}</a></li>);
    } else {
        return ""
    }
}

I would handle this with a ternary as the "else" of the statement is an empty string and even the "if" result is contained on a single line. Let's see what that looks like:


linkElement(linkID,linkURI, linkTitle) {
        return linkURI ? (<li key={linkID}><a href={linkURI}>{linkTitle}</a></li>) : "";
}

That definitely looks even more unnecessary now, right? Okay, now I'll clean up the rest of the file to reflect that change and remove the function. Also note that I don't need to do an explicit return anymore either since I'm using the ternary.

import React from "react";
import { Link } from "@reach/router";
import { PropTypes } from "prop-types";

 class LinkList extends React.Component{
  render() {
    return (
      <ul>
        {this.props.links.map(link => linkURI ? (<li key={linkID}><a href={linkURI}>{linkTitle}</a></li>) : "" )}
      </ul>
    );
  }
}

 export default LinkList;

 LinkList.propTypes = {
     links: shape({
         id: PropTypes.string.isRequired,
         uri: PropTypes.string.isRequired,
         title: PropTypes.string.isRequired
     })
 }

Wrap Up

The end result of this refactor accomplishes two major goals:

Brings the file inline with how I construct my projects now.
Reduces the amount of code in the file, making it more readable, easier to refactor further as needed, and less prone to bugs.

The logic itself is all still there, the functionality of the code didn't change. To the end user, everything will appear exactly the same. The biggest benefit is that the next time a developer (including my future self) opens the file, the level of complexity is much lower, hopefully making it also easier to understand at a glance.

What makes this a refactor and not just a modification of code? I read this quote from Martin Fowler a while back that sums it up:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

So in this case, though the file was small to begin with, I've drastically restructured it while maintaining the external behavior either in how it interacts with other components or in how the user receives the rendered component in the browser.

With my code cleaned up, I can move on with confidence that my code is as clean as I can make it. I hope this brief overview helps clear away some of the mystery around what a refactor looks like in real life.

A few ways I use Bash

Jennifer Lyn Parsons — Thu, 17 Oct 2019 16:58:33 +0000

Bash is an underrated power tool in most developers toolbox. Here's a few ways to make it work for you.

I've got a short, simple Bash profile on each of my machines that helps me get my job done. It's low-friction with easy to remember commands set up that not only save me a few keystrokes, but make things a little more fun, too. Today, I'm going to go over a few of them and talk a bit about why I set them up and ways you can customize them for your own use.

Before I start breaking my setup down for you, if you've never used a Bash command before, I'll direct you to a few useful links to help get you started:

Shell Scripting Crash Course - Beginner Level

The Bash Academy

Command Line Basics

While writing Bash in the command line is useful on its own, I find it most powerful when I set up commands in a .bash_profile file. This is where the magic starts!

Variables & Basic Aliases

Okay! Now that you have a bit more knowledge about Bash in general, I'll show you my favorite uses for the language: variables and creating aliases!

In Bash, variables can be used to point to various folders and make the functions we write more DRY. They're defined without a $ at assignment, but are called with $ when used.

mainrepo='main-repo-name'

$ cd $mainrepo
// navigates to "main-repo-name"

Distinct from variables, but with similar usage, are aliases. They can contain commands as well as paths, variables, and function calls. They can also contain other aliases!

alias dev="npm run dev"

$ dev
// runs the "npm run dev" command

Building Aliases

I use aliases to build up a set of tools that make navigating folders, opening applications, and launching local environments much easier for myself.

I'll outline an example here to show you how this might work.

alias cuppa="code $HOME/Projects/cuppa"

This will create an alias called "cuppa" (the name of my current side project) and when I run that command, it will open the project folder in VS Code for me. Note that $HOME variable? That comes for free on Unix-based environments and points to the current user's home folder.

Okay, so that opens my project files into my text editor, but what about the terminal itself? I have an alias for that as well:

alias current="cd; cd Projects/cuppa"

Here the alias called "current" is set to do two things (it's starting to get magical now!). First it will cd into the home folder to make sure the shell doesn't get confused on where to look for the folder. Then it will navigate via cd Projects/cuppa so that folder is currently active.

Once I'm inside that folder, I've got aliases that help me run my npm scripts more efficiently:

alias coverage="npm run coverage"
alias dev="npm run dev"

Here I'm using the alias coverage to enable me to run my Jest tests with coverage reports. In this case we've got some alias inception going on because coverage is a script in my package.json that is a shortcut for jest --coverage --colors.

Similarly, npm run dev is a shortcut for concurrently \"npm run server\" \"npm run client\" and inside that, even server and client are shortcuts!

Any of these can be set up as Bash aliases as well. To give an example of what we're saving in commands and keystrokes, here's what I would have to type in the command line to get my Cuppa app up and running without aliases:

$ code $HOME/Projects/cuppa
$ cd
$ cd Projects/cuppa
$ concurrently
$ nodemon server/server.js
$ webpack-dev-server --config ./webpack.config.js --mode development

With my aliases setup, this is what I type instead:

$ cuppa
$ current
$ start

Next Level Aliases

Hopefully you've seen some of the power of Bash and aliases. But when I look at that shortcut setup, I start wondering if I can make this even easier. Well, we can string aliases into a new alias! It looks something like this:

alias goodmorning="cuppa; current; start;"

$ goodmorning

Now when I type the command goodmorning I tell my shell to open my project in VS Code, navigate into the project folder, and start the local server up! With just a single word (you can even make an alias a single letter!) I'm up and running and ready to start working. MAGIC!

Note the ; between each command. That's essential so the shell doesn't try to run the entire alias as a single command. The semi-colon takes the place of the enter key in this case.

Tips and More Examples

I have a few tips for creating a Bash profile:

Don't forget to reload your profile whenever you make changes! If you're wondering why an alias isn't working, it's possibly because the shell needs to reload to reflect your changes. As you might expect by now, I've created an alias to help me with this!

alias reload=". ~/.bash_profile"

Keep your alias names simple and easy to remember. Having an arcane system that you don't remember off the top of your head will make this considerably less useful.
Don't just limit yourself to folder navigation. You can use aliases to set settings, start servers, and do other powerful things.
You can update the aliases as often as you'd like. I have a current alias for my most often opened current project, but when that changes, I'll update my profile to reflect the new project. Variables are a great way to hold this bit of information to be used across aliases.
Most importantly, figure out what's going to be most useful for you. There's no reason to copy any of my examples if your workflow is different from mine.

Here are a few more examples of what's possible with your Bash profile:

Start a simple server in the folder you `cd` into, just pass in a port

alias simple="python -m SimpleHTTPServer"

$ simple 8000
// This opens a local web server at port 8000

This shortens the bash command line status, and includes the current directory name and git status

alias short='export PS1="\\$\[\e[36m\]\W\[\e[m\]\[\e[35m\]\`parse_git_branch\`\[\e[m\] "'

Note that there's a call to a function parse_git_branch. While I didn't go into functions in this article, they're a powerful way of making your Bash profile even more useful!

This can be run to open your bash file for easy editing. Change "code" to your choice of IDE (code opens VS Code)

alias open="code $HOME/.bash_profile"

This echoes the message out to the terminal to confirm that the bash profile has been loaded.

echo '************************************************'
echo '************* Bash Profile Sourced *************'

While this isn't an alias (the echo command only writes its value to the command line) it's useful in confirming that changes made to the profile have been loaded.

Show/Hide hidden folders

alias showhidden="defaults write com.apple.finder AppleShowAllFiles YES"
alias hidehidden="defaults write com.apple.finder AppleShowAllFiles FALSE"

On the Mac, option + click on the finder icon and relaunch finder for this to take effect.

Final Notes

I hope you can see the possibilities here are limitless. I personally think Bash automation is one of the most underrated skills in software development and something we can use to make our dev time more efficient so we can get on with the fun stuff.

I've only showed you a few of the ways I personally use my Bash profile to make my day run more smoothly. If you'd like to see more, you can check out evolvingbash, my open-sourced bash profile.

Now go forth and make use of that magical terminal!

Resources

bashoneliners.com

Easy Bash PS1 Generator

Bash Infinity Framework

Nathaniel Landau's Bash Profile

A guide to basic CSS resources

Jennifer Lyn Parsons — Wed, 16 Oct 2019 15:00:46 +0000

CSS is a broad topic as the styling language is more complex than it appears at the surface. The more modern additions of grid, flexbox, and various animation tools (not to mention preprocessors!) has made the topic difficult to sum up in a guide such as this. That said, for this guide I have selected the courses, articles, and other resources that I've found most helpful or return to on a regular basis.

Basic Introductions

MDN: CSS: Cascading Style Sheets

The MDN guide is the defacto standards documentation for web developers.

The Odin Project Introduction to CSS

"Here we'll cover each of the foundational CSS concepts in greater depth than you probably have before."

CSS Basics

"You've heard the buzz about the separation of style from content, but you are stuck in the world of nested tables and deprecated markup. If so, you have come to the right place!"

Learn CSS in 20 Minutes

"In this video we will cover everything you need to know to get up and running with CSS in only 20 minutes."

CSS Crash Course For Absolute Beginners

"In this video I will cram as much as possible about CSS. We will be looking at styles, selectors, declarations, etc."

How To Learn CSS

"You don't need to commit to memorizing every CSS Property and Value, as there are good places to look them up. There are some fundamental things, however, which will make CSS much easier for you to use."

Flexbox

New flexbox guides on MDN

A list of the MDN guides and a useful syllabus for learning flexbox.

What the Flexbox?!

"A simple, free 20 video course that will help you master CSS Flexbox!"

Flexbox CSS In 20 Minutes

"In this quick video we will go over the CSS Flexbox model."

Flexbox Fundamentals

Another brief course on flexbox

Flexbox Froggy

"Welcome to Flexbox Froggy, a game where you help Froggy and friends by writing CSS code!"

Grid

MDN: CSS Grid Layout

A series of guides and references for CSS Grid

CSS GRID.

"Learn CSS Grid with Wes Bos in 25 pretty good videos"

CSS Grid Layout Crash Course

"In this video we will look at the new CSS Grid layout and how to create grid based layouts and alignments."

Learn CSS Grid in 5 minutes - A tutorial for beginners

"Grid layouts are fundamental to the design of websites, and the CSS Grid module is the most powerful and easiest tool for creating it."

Animation

MDN: Using CSS animations

The MDN resource guide on animations

Hello, animation!

"Welcome to our CSS Animation course curious CSS explorer!"

CSS Animation

"CSS animation articles, tips and tutorials."

CSS3 Animation & Transitions Crash Course

"This is a beginner friendly crash course on CSS animation using keyframes as well as CSS transitions."

Organization

Methods to Organize CSS

"Developer Ben Frain once remarked that it's easy to write CSS code, but it is hard to scale and support it. This article describes the set of solutions out there to deal with this problem."

CSS At __

"A collection of styleguides or approach to CSS at different companies"

CSS Architecture: CSS File Organization

"Part of a good CSS architecture is file organization."

Performance & Organization

"Having the ability to write HTML and CSS with a solid understanding is a great expertise to have."

Preprocessors

CSS preprocessor

The MDN glossary definition, with a few links to the most popular preprocessors.

An Introduction to CSS Pre-Processors: SASS, LESS and Stylus

"CSS Pre-processors are in our development life for years. In their first implementations, they had few features. But nowadays, they are the key ingredients and must have tools for CSS development."

SCSS & Sass

A thorough overview of SCSS and Sass, arguably the most widespread preprocessor.

CSS Preprocessors

The Free Code Camp guide to preprocessors.

Additional Resources

CSS Tricks

This is probably the most premiere source for all things CSS.

CSS Protips

"A collection of tips to help take your CSS skills pro"

CSS Reference

"A free visual guide to CSS"

Batificity

"Not the css specificity guide you deserve, but the one you need right now."

Relearn CSS layout

"If you find yourself wrestling with CSS layout, it's likely you're making decisions for browsers they should be making themselves. Through a series of simple, composable layouts, Every Layout will teach you how to better harness the built-in algorithms that power browsers and CSS."

An absolute beginners guide to web development resources

Jennifer Lyn Parsons — Tue, 30 Jul 2019 16:27:45 +0000

If you've never coded before but are interested in learning some of the basics, I have a few resources for you. I've provided a small number of introductory links as well as a few more thorough course options. I did my best to choose just enough options to not overwhelm you, but still provide choices that will hopefully fit your learning style.

Coding is a challenging, interesting skill that can take years to gain mastery. HOWEVER! The basics can be learned and used to enrich your life and help you understand how to use the tools and technology of our modern world. Just like learning how to change the oil and keep the tires filled on a car helps you use it better, learning just a bit about how code and the internet works helps you be a more knowledgeable citizen of the good ol' World Wide Web.

Basic Introductions

How Computers Work - Khan Academy

"Learn everything from what makes something a computer in the first place, how computers use electrical circuits to store and process information, and the ways hardware and software work together."

Internet 101 - Khan Academy

"In six short, introductory videos, you’ll get an inside look into foundational concepts of everything from wires to websites"

How Does the Web Work? - The Odin Project

"These concepts provide a more holistic understanding of the ecosystem in which you will be working and will enable you to talk intelligently with other developers about your work."

Beginner Coding Courses

Free Code Camp

"You'll learn to code by completing coding challenges and building projects. You'll also earn verified certifications along the way. We also encourage you to join a study group in your city so you can code in-person with other people."

This is my personal favorite and yes it really is free.

The Odin Project

"Our full stack curriculum is free and supported by a passionate open source community."

This curriculum builds on other resources around the web, curating a thorough code education.

Traversy Media

An excellent source of courses and youtube tutorials that include crash courses to get a brief overview of various coding topics.

Codecademy

Codecademy has a mix of free and paid courses and is a viable alternative to Free Code Camp if that doesn't fit your style.

Learn Enough to be Dangerous

"Learn Enough is based on the idea that you don’t have to learn everything to get started—you just have to learn enough to be dangerous."

I don't get any kickback for these paid courses, but can recommend them for beginners.

What I've learned about testing React applications

Jennifer Lyn Parsons — Tue, 30 Jul 2019 12:47:57 +0000

TL;DR Testing on the front end is one of the most personalized aspects of development, with a variety of shifting tools and opinions, particularly for the React ecosystem. Be patient with yourself when you're learning how to test. In my experience, it's one of the more challenging things to teach yourself.

I spent a lot of time recently digging into React testing and came away with more knowledge than when I started, though I still have some lingering confusion. I did, however, develop a system that feels workable to me and makes my tests make sense with how I work. Currently, it seems that's the best we can ask for as React testing is evolving at a rapid pace.

While it can be frustrating that best practices for testing React are in such flux, I'm hoping this article will shed a little light on the various options and be a step toward some kind of consensus.

General thoughts

Before I dive into the React-specific information, I thought I would share a few general thoughts about testing. Words of wisdom, if you will, based on my experiences. They serve me as reminders of why testing is important and the reality of what writing tests is really like.

Yes, you're basically writing a stripped down version of the logic of your app all over again in a different framework.
There are some loose best practices that have been inherited from the backend, but folks seem to be even more splintered on how testing should be handled than they are on which framework you should use. What works is something you'll have to decide with your team.
Writing tests requires thinking very differently about your app than you usually do, and will have you rethinking how you're handling data.
Coverage is an imperfect gauge for quality. If you have not written "unhappy path" code (else statements, catch blocks, etc.) your coverage will be inaccurate. You can't test code you haven't written.
Writing tests does indeed increase the amount of time, code, and effort it takes to write an app. That's not an illusion and it's something to be accepted as part of the process because...
It saves an unseen amount of time and effort you would have put into debugging, especially during refactors. You won't know how much you've saved because you won't be doing that work. This is easy to forget.

Tools

When it comes to testing React applications, there are choices depending on how you approach your testing. Do you want to focus on integration tests? Unit tests? Or do you prefer functional tests? And yes, those terms have different definitions depending on who you ask. Learning about these options was a good reminder that React is technically a library and not a framework. That means there is a lot of customization possible and that is abundantly clear with testing.

Basic testing

ReactTestUtils: React's own built-in testing utility, which is no longer recommended even by the React team.
Jest: the defacto standard library for React testing, built by Facebook specifically to test React applications.

Built on Jest

React Testing Library: the currently recommended component testing library, it tests components the same way your users use them.
Enzyme: a widely used testing library and competitor to RTL. It allows you to traverse and manipulate your components' output.

Integration

Cypress: end-to-end testing with time travel, snapshots, and a browser-based interface.
Puppeteer: end-to-end testing that runs headless Chrome and allows you to write tests that interact with the browser without running it.

Alternatives

Mocha/Chai/Karma: since React is really just JavaScript, these stable, venerable testing tools can be used as well.

A few other options can be found in the React docs' Community section.

That covers most of the options for basic testing. There are also numerous supplemental tools that can be used, depending on your application. For example, redux-mock-store is often used to mock the redux store and moxios can be used to mock axios for API testing, though there are other options for testing both of these tools.

Documentation & Notes

I found the documentation for most of these tools to be very dense, referring to concepts that are fairly complex without significant prior knowledge. When I tried applying the lessons from the basic tutorials I found, I was quickly frustrated that they did not align with the more complex code base I was trying to test. By "more complicated" I mean that I was using Redux and React Router on top of React, so in the real world, not actually all that complicated.

There were a few important concepts that were not clearly explained in the various documentations I read. Here's what I've gleaned from the docs and learned from others who are also trying to figure this all out:

Individual files are run in parallel (unless you enable the runInBand option). So it is not safe for multiple test files to share a mutable data store. All describe and test blocks within a file always run in serial, in declaration order. This is important to note if you are mutating data between tests.
React Testing Library does not rerender the component when props change if you are working outside the redux store, even if you try to feed in new props. Anything to do with a lifecycle method other than componentDidMount will not be run. You can manually pass in updated props and manually rerender the component, but that's not the same as testing the result of a redux call. For that kind of testing, Cypress may be a better choice.
If you have any links from React Router or want to test that redirects work on your component, RTL's standard render function will not be enough. You must use the renderWithRouter function found here: React Router · Testing Library
Named arrow functions in class properties aren't in the prototype so unit testing them is challenging. A fat-arrow assignment in a class in JS is not a class method; it's a class property holding a reference to a function.
Snapshots, despite being presented as a first step in most testing libraries' documentation, are not as useful as they seem at first glance and are generally avoided by many developers.
Mocking can be challenging without a full understanding of how it works and what can be expected from it. I've written a separate article specifically on mocking covering some of the basics, though it's important to note that Promises add an additional layer of complexity.

With all that said, documentation is still a solid place to start when learning testing. Reading it through thoroughly and then following up with research into any new terminology will enable you to ask better questions.

I found it helpful to search for any errors that come up as well. Discovering what was a problem with my tests vs. my code vs. a configuration issue was challenging, but with each issue I refined my knowledge of how the pieces fit together.

I also highly recommend joining the communities of the various testing libraries and reading through the issues in their github repos. Many questions I had were answered in these places more efficiently than in the documentation, especially when it came to the complexity added by using Redux, thunk and other non-native React tools.

My own system

Currently, I've chosen to use the following setup on my side projects:

Jest
React Testing Library
redux-mock-store

I also have a "test" folder where all of my test data is stored in fixtures along with a few testing utilities. For reference, the test utilities are stored in a gist. The fixtures and other setup details can be viewed in one of my side projects. (I have a boilerplate in the works that will include this style of testing)

Guidelines

Fixtures and utilities are stored in the root level test folder.
Use fixtures for data unless it is a small amount (less than line) of single-use data.
Prefer reusable test data and utilities. Keep tests DRY, too!
Tests exist alongside the elements they are testing. Each component folder should contain a __tests__ folder and tests should be named to match their component.

Tests

Structure of a test file

Not all test suites require all of the structure outline below, but this is the preferred order for each of the files.

Imports
- React
- React Testing Library
- Other required packages & libraries
- testUtils
- routerTestUtils
- data fixtures
- connected container component
- unconnected container component
Constants
Mock Functions
Variables for beforeEach
beforeEach/afterEach setup/teardown functions
Describe block
- test block
- variables (including spies)
- store.dispatch
- fireEvent
- expect

Notes on my testing style

Data fixtures are not aliased to variables unless needed for mocking purposes.
The first describe block for any test suite is the basic render of the component with the connected store or a test that the function or object being tests exists.
The second describe block tests basic interactions.
All other tests come after the first two.
Multiple expects are acceptable in a single test as long as they are all related to the same functionality and relevant to the test.

Wrap up

I hope some of this information is helpful to those also interested in developing a solid testing strategy. Perhaps one day we'll have more standardized approaches for testing on the front end, but until then, I encourage you all to share your own findings and experiences working with tests.

Xpath for you and me

Jennifer Lyn Parsons — Mon, 29 Jul 2019 13:38:31 +0000

I learned XPath a few years ago and always found myself frustrated with the documentation for it. There were a few basic concepts that seemed to trip me up on it as I learned it. My hope with this brief article is that I can make it a little easier for the next person who needs to learn this small but mighty tool.

What is XPath?

XPath stands for XML Path Language

XPath is designed to be used to point to parts of an XML document. We use it to do pattern matching between DOM nodes. It is used in XSLT, Selenium and other areas where DOM navigation is useful.

When looking at the syntax of an xpath query, view it as if the DOM is a file hierarchy that we are navigating, similar to URL paths. It intuitively makes a bit more sense that way. Each parent element is a "folder" that can contain other folders (child elements).

The general syntax is similar to regex and CSS selectors as well.

XPath query structure

XPath queries are made up of four parts.

The prefix determines the starting point of the query.
The axis refers to the relationship of the context node.
The step is also the context node, the identifier of the element we’re referencing.
The predicate makes the step more specific

Note: The less specific XPath queries are the more expensive they become, performance-wise. Similar to CSS selectors, there is a balance between specificity vs. flexibility and performance.

Parts of an XPath query
//	ul	/	a[@id ='link']
Prefix	Step	Axis	Step with predicate

Axis selector examples

Axis selectors allow us to "drill down" into the structure we're processing to access the node we're looking for.

Axis selector	Examples	Context
`//`	`/section/div//a`	Anywhere in the document when prefix (This will set the context to any descendent element)
`./`	`./a`	Child relative to the current node
`/`	`/html/body/div`	Start at the root (This will also select the context to any child element)
`.`	`.`	Self node
`..`	`..`	Parent node
`*`	`./*`	Any node

Navigation

XPath also allows you to navigate up and down the hierarchy of the DOM, just like with folder navigation.

Selectors can be chained and can include some limited logic. They are based on various pattern matching criteria, similar to regex.

relationship (child, sibling, preceding, self)
attributes (id, class name, href)
order (first, last)
content (contains string “xyz”)

Selector examples

Example	Context
`//ul/li/a`	Relationship selector, matches a direct child relationship
`//input[@type="submit"]`	Attribute selector
`//ul/li[2]`	Order selector, selects second child `<li>`. Note: this is not zero indexed.
`//button[contains(text(),"Go")]`	Contains text, in this case matching a substring
`//a[@name or @href]`	Or logic
`//ul/li/../../.`	Selects the parent of the `<ul>` (for example, a `<div><ul><li> </li></ul></div>` structure)
`//h1[not(@id)]`	Not selector. This example selects any `<h1>` without an id
`./a[1][@href='/']`	An example of chaining. Here we’re selecting the first `<a href=”/”>` within the current context

A note about contains(). This selector is rather loose and will select any string that contains the string parameter that is passed to it. This can cause unexpected results. In the example above, any button with the string Go in it will be selected, in this case Go Home and Go to Next Page would both be selected. Combining the various selectors can produce the results you seek.

Resources

MDN
https://developer.mozilla.org/en-US/docs/Web/XPath

Devhints.io
https://devhints.io/xpath

Scrapy documentation
https://doc.scrapy.org/en/xpath-tutorial/topics/xpath-tutorial.html

A bit about Jest mocks

Jennifer Lyn Parsons — Fri, 07 Jun 2019 20:28:32 +0000

I've been learning Jest and applying it to a side project built in React. As I run across various challenges I've cobbled together some things that I thought might be helpful for others new to testing. A few bits of information here were a challenge to locate. I came by them via my network and some asking around and trial and error. This post is my way of paying that forward.

My plan is to give a very brief overview of mocks in general, a few examples from my real life codebase, and provide a few resources for further information.

Mocks in general

From the Jest docs:

"Mock functions make it easy to test the links between code by erasing the actual implementation of a function, capturing calls to the function (and the parameters passed in those calls), capturing instances of constructor functions when instantiated with new, and allowing test-time configuration of return values."

That's a mouthful. What it basically means is that a mock replaces a function call within the test with a fake version. That means you grab the name of a function and replace it with a different implementation.

Does this mean you're just rewriting that function inside the test? I can see where you might think that. However, with this mock version of the function, you only need the bare minimum of code. It can return a basic value and should not include any logic. You aren't testing how this function works after all, instead you're testing the function that calls this function.

Mocks in Jest

Jest has a couple of built-in methods for creating mock functions. The most basic is jest.fn(), but I haven't found that useful on its own so far. In my codebase, which is a MERN stack project using Redux, I've found that method most useful inside other mocks. Your mileage may vary, as they say.

I've used a couple of Jest mocks in my own tests. I'm going to give the examples here and walk through them as best I can.

The jest.mock() function call takes two arguments. The first is a string that contains the path to the module that contains the function being called (or the name of the Node module). The second is an optional function that is used in place of the original function.

Mocks in Jest also have a special set of assertions. Since they are not intended to provide the same functionality as the original function calls, mocks are generally used only to assert that a function has been called. We can determine how many times it's been called or what arguments are used to call it, but that's about it.

Examples

The code for the tests and the code being tested (in stripped down versions) can all be found in this gist.

Mocking a module function

This is a mock I have set up to provide a faked function call. The pathname is given and then the result of that call is faked with () => jest.fn(), a function that returns a function. This reflects the structure of the setAuthToken function and for the test, that's all we need.

jest.mock("../../utils/setAuthToken", () => jest.fn());

That mock is used in the test below soley to ensure that inside of my loginAction() action creator, the setAuthToken function has been called. Elsewhere, I've tested that setAuthToken returns the expected response, but this is a unit test, so I'm only looking to ensure the call is made.

test("it sets the JWT token to the response from the POST", async () => {
  await store.dispatch(loginAction(mockLoginData));
  expect(setAuthToken).toHaveBeenCalledWith(mockResponse.token);
});

Mocking a Node module

This mock sets up the jwt-decode node module fake so that when it is used in the next test, I can be sure that I once again am getting a call out to the correct function.

jest.mock("jwt-decode");

Here is the test where that is used. Note that I'm only looking to ensure that .toHaveBeenCalledWith is a true assertion.

test("it decodes the token with jwt_decode", async () => {
  await store.dispatch(loginAction(mockLoginData));
  expect(jwt_decode).toHaveBeenCalledWith(mockResponse.token);
});

Mocking an API call

This mock is being used to fake an API call, in this case, a post that returns a Promise that is resolved with some fake data. Note the function inside it does a bit more than the first example. Here I'm not just returning an anoymous function wrapped around jest.fn(). Instead, here I'm returning an object which currently has a post key and the jest.fn() function which contains an anonymous function that returns a Promise. Whew!

Additionally, note that the object it returns can be filled out with the rest of the API methods in comma separated multiple key/value pairs.

jest.mock("../../lib/api", () => ({
  post: jest.fn(() => Promise.resolve(mockResponse))
}));

Here's what the test that uses that mock looks like. I've faked the API.post property in the mock. The original version of that function takes two arguments, the path for the call and the data passed to the backend. Here I'm checking that, once again, the function was called with the correct data. In this case, I am also checking that returns a resolved Promise.

test("it calls 'post' on the API with the correct path and the user data", () => {
  store.dispatch(loginAction(mockLoginData));
  expect(API.post).toHaveBeenCalledWith("/users/login", mockLoginData);
});

Mocking with a default implementation

This mock combines a few of the mocks above, with an added twist! Here I'm mocking the react-router-dom node module, just like with the jwt-decode module. However, I do not want to mock out the entire module. I need to keep Route intact and only mock Redirect. To accomplish this, I am using a method similar to the API.post mock above and returning an object. I'm using the requireActual() function to grab all of the original, real methods in the module. Inside the return, I'm first using the spread operator to add those original methods. I'm then overwriting only the Redirect method.

Did you see the little new twist on Redirect? It's the .mockImplementation() call. Because unlike the first example where I only needed a function and unlike the API call where I only needed a resolved Promise, in this case I need some kind of returned value. It doesn't have to be a value that matches what would be return in the original code, but I do need to return something. The intent of .mockImplementation() is to create an actual, if fake, implementation.

jest.mock("react-router-dom", () => {
  const original = jest.requireActual("react-router-dom");
  return {
    ...original,
    Redirect: jest.fn().mockImplementation(() => null)
  };
});

Here is the test where that mock is used. In this case I'm making sure that when the user is logged out that they are redirected somewhere else. Because I'm not trying to test react-router-dom itself, it's enough to know that a redirect has happened without worrying about where to.

test("PrivateRoute should redicted to the login page if user is logged out", () => {
  const store = makeMockStore(loggedOutState);
  let wrapper = mount(
    <MemoryRouter initialEntries={["/dashboard"]} initialIndex={0}>
      <PrivateRoute
        path="/dashboard"
        component={GenericComponent}
        store={store}
      />
    </MemoryRouter>
  );
  expect(wrapper.find(Redirect).exists()).toBe(true);
});

Spies!

Spies work a little differently, but are still a type of mock. From the official docs: "Creates a mock function similar to jest.fn but also tracks calls to object[methodName]. Returns a Jest mock function." What this means is that the function being tracked must exist as a method name on an object. For example, in this case, I'm exporting my methods from authActions.js like this:

const authActions = { loginAction, registerUser, logoutUser, setCurrentUser };

export default authActions;

I did this in order to track that the setCurrentUser method was being called inside the loginAction method. The reasons this was necessary are beyond the scope of this article, but there's a really great explanation here. The tl;dr is that it has to do with the way Babel compiles JavaScript.

.spyOn also calls the spied method and does not allow you to overwrite the original implementation.

There is no separate mock for this one, I'm using .spyOn directly in the test. The function takes two arguments, the object where the function exists and the name of the function. I can then check that when loginAction, which also lives inside the authActions object, is called, it calls setCurrentUser one time.

test("it sets the current user action", async () => {
  let currentUserSpy = jest.spyOn(authActions, "setCurrentUser");
  await store.dispatch(authActions.loginAction(mockLoginData));
  expect(currentUserSpy).toHaveBeenCalledTimes(1);
});

Summary

Jest mocks, and mocking in general, can be a tricky but they're useful in unit testing because they allow you to test the code you've written without worrying about dependencies. I hope a few of these details clarify some things for you and that by sharing this information someone else might have a little bit easier time learning to write tests.

Please let me know if you find any errors, I'm looking to learn more!

Resources

I also want to thank the gang over at WeAllJS for their invaluable help as I figured this all out.

Early Returns in JavaScript

Jennifer Lyn Parsons — Sun, 29 Jul 2018 18:30:30 +0000

A couple of articles related to how early returns work crossed my path recently, enough to pique my curiosity. Learning about early returns in JS has been not only a challenging technical exploration, but also pretty fun. In researching the concept, I remembered how much I enjoy learning something for it's own sake, not just as a means to an end. Sure, the information I gathered is useful and the technique is something I'll likely employ in the long run, but it was just as valuable enjoying following the trail of breadcrumbs that led to my final conclusion.

What is an early return?

In short, an early return provides functionality so the result of a conditional statement can be returned as soon as a result is available, rather than wait until the rest of the function is run.

Surprisingly, I hadn't seen this kind of pattern in JS before, though I'm used to seeing it in Ruby, where it's quite common. I was curious as to why that was. A bit of research showed me that returning only after the rest of the code had run, whether it was needed or not, was a holdover from older imperative programming languages where it was required to return at the end of a function to ensure the code ran in the correct order.

The only answer I could really find to why I hadn't run into this pattern before is that even now this is not taught nor talked about enough for folks to start using it regularly, dropping the imperative style. A few newer devs have started the conversation and argue quite strongly that it's clearer to read.

I still had questions

I was unsure about the readability of this style. I'm so used to reading if/else statements with a variable set at the top of the function that gets returned at the end. Having multiple returns or even multiple if statements (rather than if/else) felt like it would be more challenging to understand at a glance.

More important than readability, I wondered how performant it was versus the single point/end of function returns. My gut told me it was probably faster because, in theory, less code was being run. In researching this, I found a pre-2012 article hinting it might actually be less performant but didn't find any information after that supporting one style or the other.

It would be interesting to discover that a single return was faster and if it was, why that was so. I decided to run some benchmarks to see what our winner was.

Benchmarking early returns

Here are my benchmark tests: JavaScript benchmark playground

As you can see when you run the tests, there are only 10s of milliseconds difference in speed between the various options, fairly negligible. While I get slightly different results each time I run the benchmarks, with the old imperitive style comes out on top every time. Not what I was expecting! Generally, it looks like "early return within an if/else" comes in second to "early returns with single statements", though it's pretty much a wash between them.

Conclusion

In comparing these examples, I find I prefer a single if/else for readability, regardless of whether it's an early return or single return. While early returns feels less cumbersome than setting up a variable just to have a return value as in single return, knowing that there's a performance hit as well means I'll be likely sticking with the old style. Additionally, having a series of statements inside a function as in the "early returns with single statements" version abstracts the fact that they're consequentially connected to each other and to me, that's less readable.

All in all I feel like I've gained a deeper grasp on some of JavaScript's inner workings, with the bonus of trying out some benchmarking and learning a bit of programming history as well.

Resources

Software as a Tiny House

Jennifer Lyn Parsons — Mon, 04 Dec 2017 15:12:17 +0000

I love the idea of living in a tiny house, something portable and just big enough to fit the essentials. While I don’t know if I would be happy living in one myself, I do love learning about them.

I was watching some video tours of tiny houses recently and some of the things the folks who lived in and built them had to say resonated with me. However, it didn’t have anything to do with my own living situation. Instead, I found quite a few insights that could be applied to software and website architecture and design. In fact, just the idea that we use those same two terms in both house construction and building software makes me sure the concepts are a natural fit.

While I’m still pondering these connections, here’s what I gleaned so far from watching those tours:

What do the people living there need?

(don’t build useless spaces, repurpose spaces that are underused)

There are essentials, things that every house and piece of software needs to have to make it useable in general. There are always exceptions, but a kitchen, bath, bed, and living space are all important in a house, even if they all exist in the same room. The same can be said for software. An interface, storage, and functions that process the interactions between the data and the user, are all pretty standard in working software.

It’s good to ask if a new space or functionality is necessary, and seeking new ways to repurpose the same things in other areas is key to making efficient use of both space and code.

What’s the most economical way to do it?

(in energy & resources, not just money)

Tiny houses are often built from recycled materials when possible. It saves cost and is also lower impact on the planet. While any app’s power efficiency (unless you’re Amazon or something) is likely to be small already, looking for ways to make the code run more efficiently is a good practice all around.

Additionally, when thinking in terms of resources, it’s good to recognize the cost in people hours as well. Solid planning and an understanding of the problem you’re trying to solve will save time and help stem the tide of burnout that’s far too rampant in our industry.

What’s healthiest for the whole person?

(make it simple to move through, don’t make things hard to reach, does it breathe)

A tiny house that makes you climb into a loft doesn’t work if you have certain health issues. Large windows might be less energy efficient than small ones, but the benefits gained from the sense of space makes the trade off worth making.

With software, a strong designer is essential here. If things are difficult for a user to accomplish or are unintuitive or cramped, their experience will be lesser. In some cases, this can mean the loss of return visitors and for some sites and software, those users are critical to success. If your software is meant to be a help to others, than making it difficult to use puts an extra toll on someone who is already compromised.

Get to know your space and what you need it to be.

(requires self-exploration as well as trial and error, make it what it needs to be but no more)

For a tiny house, knowing that there needs to be a priority on the kitchen because the owner is a cook is a vital piece of information. They may ask for a full four-burner stove. Perhaps instead they really only need a two-burner and a portable hot plate, leaving room for a larger sink that will make their living experience more pleasurable in general.

Knowing who you are building your software for and anticipating their needs is not easy. It takes work and thought and research, but the end result will be a smoother experience.

Be willing to let the materials guide the building.

(recycled materials, clever use of non-traditional tools, etc. will change everything)

Tiny houses have limits on them. Size restrictions based on building code or road regulations delineate what is possible to build. That’s where creativity comes into play, maximizing the space in unexpected and clever ways.

Here an understanding of the tools at your disposal as a developer comes in handy. Rarely does any developer get to choose the libraries or languages they’re working in. Frequently a developer is asked to build something that a language doesn’t necessarily do well. A deep understanding of tools, of architecture, of the language of choice is a great asset in these situations, allowing for a creative use of the resources at hand and providing a satisfying challenge.

A small footprint and low power requirements keep it sustainable.

(will it still work off grid?)

Many tiny houses can work perfectly well off the grid. No power or water hookups needed, they are designed to work well when those options are unavailable.

Software gets bloated easily. When space is virtually free and libraries are limitless in availability, there’s very little incentive to put any constraints on how the code is actually written. However, with each new layer of complexity from another library and every megabyte of storage used to hold the software, maintenance becomes an issue. Cost, too, can become troublesome, either in the form of server space, energy costs, and environmental impact over time.

It’s also useful to ask if your software is still useful to someone who has no or limited access to the internet for some reason. What can be done to keep things running at low (or no) latency?

Multi use, purpose built functional things solve some problems more efficiently.

(customization can maximize space and ease of use)

Most things in a tiny house have multiple uses. Very often a couch will also be a storage bench, a table is also a desk. This maximizes both space and utility.

It’s a useful exercise, at least, to consider the benefits of writing a series of functions to fill a need rather than installing an entire new library of functions that may or may not be used. Testing to make sure that every area of a program is running most efficiently will help reveal code that can be reused or refactored. What functions can be made universal?

Ease of use and at hand vs the thought process behind it.

(is everything within reach and as intuitive as possible?)

A tiny house works best when its owner can move effortlessly through the space and use it as best pleases them. For some, an origami folding cabinet that houses layers of functionality works best. For others, it’s more comfortable to make as few changes to their space as possible day to day.

Just because a piece of software can do five different things if you change various settings doesn’t mean it should. Users shouldn’t have to think to hard about how to navigate through the tool in front of them. If complexity is required, then ease of use becomes a higher priority.

The same goes with building the software itself. If a function is difficult to understand and use because it does many things at once, it is not “at hand”. The balance of making something easy lies in the difficulty in creating that ease. More thought is required before code is written and the initial effort’s worth has to be weight against the end result’s usability.

Beauty and a sense of space even when there isn’t much actual space is vital to livability.

(the culmination of all the planning and building needs to be a livable space that’s comfortable)

Windows are a massive factor in a tiny house. Those with few or very small ones tend to feel tighter, more cramped, less livable. Beauty is an even more important factor here than in a larger home, where the lack can be compensated for with furniture, decor, and other additions.

Software, too, needs to have a sense of space and beauty in the both the interface and in the code itself. Cramming too much functionality into an interface makes it feel less useable. Writing code that tries to do too much with each function becomes not only fragile, but also difficult to debug and maintain, never mind adding new features.

All of the work put into building a piece of software, regardless of the platform, needs to result in a code base that’s maintainable and flexible and a UI/UX that meets a user’s needs and guides them through the process of getting there without unnecessary work or distraction.

I hope this exploration gave you something to think about as you sit down to write that next line of code. I know it has me thinking differently as I approach my day to day work and also as I prepare to start any new projects in the future. Compact, concise, beautiful, usable, the tiny house philosophy turns out to be a great way to write software, too.

(originally published on http://jenniferlynparsons.github.io)

Let’s Talk About HTML Hierarchy

Jennifer Lyn Parsons — Wed, 01 Nov 2017 22:57:09 +0000

Okay, this is our meat and potatoes, right? HTML is the backbone of how we put a website together. At some point, no matter what framework, JS, Ruby, etc. fanciness we’re using to build a site, we’re going to spit HTML out at the end to be ingested by some sort of browser.

We don’t know what kind of browser will be reading our code. We only know that it will be able to read it. Firefox, Chrome, Internet Explorer and Safari are usually what pop into people’s heads when you say the word “browser”. It might be desktop or mobile, but there are many other browsers out there. In particular, the ones that get forgotten most often are screen readers, those browsers that are accessible to those with visual limitations of one from or another.

What these limited browsers also do, in addition to being incredible tools for the visually impaired to gain access to the internet, is also display the power and importance of using semantic elements in our HTML structures.

Frankly, we should all be more concerned about accessibility (myself included) but even if you’re not for some reason, this information is useful to everyone for another reason: this is also how search engines read your page. Want better page rankings? Using HTML properly will help you out. The bots will be able to determine what the most important information is on the page. This, in turn, tells the search engine what your page is about and whether to serve your link up higher on the results page when someone searches for something related to your page.

There is a third important reason to write your HTML semantically: it makes it easier to write CSS and you’ll have to write less of it. I’ll get into that at another time, but suffice to say that there is magic sauce in the mix between semantic HTML and the power of the cascade.

So, with all that said, what does it mean to write “semantic HTML? It means that the content that we’re adding to our page has context. It has hierarchy, levels of importance that help tell the browsers what to emphasize and what to deemphasize. It helps describe the data that we’re displaying on the page so our users (don’t forget the users!) don’t have to think too hard about what they’re looking at. We want them to intuitively understand our page as much as possible.

Okay, perhaps an example here would be helpful. Take a look at this chunk of information:

And now this one:

Yes, you may have parsed out that the bit of this wikipedia article is about the Drabble fiction form Drabble - Wikipedia, but what was less clear was that “Criteria is a subsection of “55 Fiction”. In both examples above, that’s raw html rendered in Firefox, by the way. No CSS or anything fancy other than setting a width for the body so I could take a nice screenshot.

In the first example, all the chunks of information are wrapped in p tags. In the second, we have a structure that looks like this:

<h1></h1>
<p></p>
<h2></h2>
<p></p>
<h2></h2>
<p></p>
<h3></h3>
<p></p>

Which, if we were to think of this accurately and with some indenting to clarify the hierarchy, is a page outline and could be thought of like this:

<h1>Title</h1>
    <p>information related to the title</p>

    <h2>Subtitle</h2>
      <p>information related to the subtitle</p>

    <h2>Subtitle</h2>
      <p>information related to the subtitle</p>

      <h3>Sub Subtitle</h3>
        <p>information related to the subsubtitle</p>

The only reason in the first example that you can discern the headlines is because they are short and they are in separate p tags, which by default in Firefox have margin around them.

Two slightly more extreme examples for you. The first, which uses only div elements, which are rendered by default as blocks similar to p tags, but without any margins. They are “styleless by default:

The second contains only span tags, which are inline elements really meant for styling and grouping data with similar attributes such as phrases that are in a different language:

Yeah, things are starting to get hard to parse now, right? And yet, in both these examples, there are the same number of html tags, wrapping the information in exactly the same way as in the first two examples.

It has been argued to me that tags like h1 and article, etc. only encode style. In theory, this may be true. Tags are just an abstract way of displaying information in organized chunks and their names don’t matter. If we had collectively decided to identify semantics with class names, div.h1 would have the same importance as h1. However, this is not the paradigm we work in and so h1 still holds more semantic weight in the page hierarchy and browsers are engineered with stylistic defaults to match that hierarchy.

Semantic HTML goes beyond just headers and paragraphs. section, article, header,footer, and a few other special tags all help not only organize your content and make it easier to style, but also contribute to making your HTML make more sense both to the browser and to the user reading your page. While they don’t have any default styling associated with them, once again, screen readers and SEO concerns benefit greatly from proper usage of these tags.

I hope this has helped clarify a few things about how the HTML hierarchy works and how you can use it to provide your users with a better experience. To help you along the way, I’ll be posting a follow up on some tips for writing better code that outlines some common mistakes I’ve seen and more thoughts on writing cleaner, more performant HTML.

Some final notes and resources:

I highly recommend reading this article for a brief but thorough overview on screen reader capabilities and how semantics can improve the experience for the visually impaired:
WebAIM: Designing for Screen Reader Compatibility

Want to go more in depth in understanding semantic HTML? This is a great resource:
Semantic HTML Tutorial | HTML & CSS Is Hard

For a bit more nitty gritty overview of the various tags mentioned here, as well as plenty others, there are few better resources than the MDN. Their list of tags conveniently breaks them down by intended usage:
HTML element reference - HTML | MDN

A few updates:

Too often framework users make everything a div. That's bad for users, search engines, and even devs making changes!
Jason Stumpf

As I thought a bit further about the topic, I also thought of a few more use cases you may not have considered:
â€¢ print/pdf versions of your page (and epub if you do that kind of thing) are much easier to generate when a proper page hierarchy is used.
â€¢ RSS readers ingest the html sent over without any styling attached. If you’d like your headlines and general page structure to translate into other interfaces with clarity, semantic HTML is the way to go.

I learned a lot, but how much?

Jennifer Lyn Parsons — Sun, 15 Oct 2017 03:53:34 +0000

We’re often told in programming that personal projects are, in addition to being a great way to build a portfolio of work to show prospective employers, a method for learning new things. That’s totally true. Personal projects, especially if we’re working solo, can provide challenges that will help us learn combined with the freedom to pursue this work at our own pace and in whatever area we’re interested in exploring.

So, how do we tackle a personal project? We sit down, plan it, code it, tweet about it and then after boatload of work and the excitement of launching, we’re done, right? I often have had the sense that I learned “so much by working on something.

Sure. But what exactly have we learned? Has this been useful to us beyond the project existing for ourselves and others to use? How do we gauge the value of this experience in terms of our education and growth?

For me, the answer lies in something many of us who work in Agile paradigms are already familiar with, but with a slightly different focus: The retrospective.

Fairly recently I’ve started doing a retrospective session to see what I got out of doing a particular personal project. If you wanted, you could even do a solo sprint and retrospective pattern of work as well. These retrospectives help me to gain insights into what worked, what didn’t, etc. Surprising things turn up as I write about the project I just completed.

When I’m done I have an immediate and thorough understanding of what I’ve just done and what I learned along the way. An added benefit is that as long as I keep doing this, I’ll have a record I can look back on of what I was thinking in the moment and what the most distinct aspects of the project were for me at the time.

I also take a little time to reflect on what I learned about myself as a person in doing the project. What kind of choices I made, how I reacted to the challenges and hurdles I encountered, and what parts were satisfying or interesting to me. This can help lead my choices for future projects as well as areas that might be interesting to pursue in my study and work choices.

It does take a bit of extra time and effort to do this, but not overly much and it’s been worth doing so far. If you’d like to try it out yourself, here’s my template to use as a starting point for your own:

Challenges going into the project:
What resources did I have to mitigate these challenges? (People, books, sites, etc)
How did I prepare for the project?
Challenges during the process:
Where did I get really stuck?
How did I overcome those hurdles?
Could I have done it better and what would that have taken?
If this project exposed knowledge gaps, what do I need to learn?
What did I learn from this project?
- Technologically:
- Personally:

Hi, I'm Jennifer Lyn Parsons

Jennifer Lyn Parsons — Sat, 11 Mar 2017 19:56:40 +0000

I have been coding for 6+ years professionally, 16+ years as a hobbyist. Though I did spend some time with BASIC back in the early 80s so 34 years, depending on your definition.

You can find me on GitHub as jenniferlynparsons

I live in New Jersey (don't look at me like that).

I mostly program in these languages: HTML/CSS, JavaScript (vanilla, JQuery, React)

I am currently learning more about Clojure, OOP, functional programming, Python, back end technologies, and how to be a better version of myself.

Nice to meet you.

DEV Community: Jennifer Lyn Parsons

A Refactoring Breakdown

Our starting point

Swapping Typescript for PropTypes

Logic Streamlining

Wrap Up

A few ways I use Bash

Variables & Basic Aliases

Building Aliases

Next Level Aliases

Tips and More Examples

Start a simple server in the folder you cd into, just pass in a port

This shortens the bash command line status, and includes the current directory name and git status

This can be run to open your bash file for easy editing. Change "code" to your choice of IDE (code opens VS Code)

This echoes the message out to the terminal to confirm that the bash profile has been loaded.

Show/Hide hidden folders

Final Notes

Resources

A guide to basic CSS resources

Basic Introductions

Flexbox

Grid

Animation

Organization

Preprocessors

Additional Resources

An absolute beginners guide to web development resources

Basic Introductions

Beginner Coding Courses

What I've learned about testing React applications

General thoughts

Tools

Documentation & Notes

My own system

Guidelines

Tests

Structure of a test file

Notes on my testing style

Wrap up

Xpath for you and me

What is XPath?

XPath query structure

Axis selector examples

Navigation

Selector examples

Resources

A bit about Jest mocks

Mocks in general

Mocks in Jest

Examples

Mocking a module function

Mocking a Node module

Mocking an API call

Mocking with a default implementation

Spies!

Summary

Resources

Early Returns in JavaScript

What is an early return?

I still had questions

Benchmarking early returns

Conclusion

Resources

Software as a Tiny House

What do the people living there need?

What’s the most economical way to do it?

What’s healthiest for the whole person?

Get to know your space and what you need it to be.

Be willing to let the materials guide the building.

A small footprint and low power requirements keep it sustainable.

Multi use, purpose built functional things solve some problems more efficiently.

Ease of use and at hand vs the thought process behind it.

Beauty and a sense of space even when there isn’t much actual space is vital to livability.

Let’s Talk About HTML Hierarchy

I learned a lot, but how much?

Hi, I'm Jennifer Lyn Parsons

Start a simple server in the folder you `cd` into, just pass in a port