Erin Bush

Static Methods for Javascript Classes 🎈

2019-09-20T01:00:07.845000Z

The other day I started a new project at my job. I was setting up the repo and adding all of our usual linters to hold ourselves to a consistent standard. Once I had eslint set up with the latest versions, something popped up that I hadn’t had to think about in a while: static methods.

We had a javascript class with a mix of intense methods and some that yes technically should be considered static methods.

As a refresher (from MDN Web docs):

Static methods aren’t called on instances of the class. Instead, they’re called on the class itself. These are often utility functions, such as functions to create or clone objects.

So what does this mean? Static methods hold logic that do not interact with an instance of the class (ie. this)

For example:

class Person {
    constructor (name) {
      this.name = name;
    }

    static sayHello (name) {
      alert(`Hello ${name}!`);
    }
}

sayHello is a static method because it does not involve an instance of Person (it does not call this). We can call sayHello by doing something like:

Person.sayHello(‘Denzel’)

Now, if we want to add another method to our Person class, that calls sayHello, we could need to call it as a property of the constructor. Static methods are not directly accessible using the this keyword from non-static methods.

class Person {
    constructor(name) {
      this.name = name;
    }

    interact() {
        this.constructor.sayHello(this.name);
    }

    static sayHello(name) {
      alert(`Hello ${name}!`);
    }
}

You can however call a static method from inside another static method using this as this represents the class itself, not the instance.

class Person {
    static interact(name) {
       this.sayHello(name);
    }

    static sayHello(name) {
      alert(`Hello ${name}!`);
    }
}

Person.interact(‘Denzel Washington’);

I hope that clarifies static methods! I was blinding following the linter rules and neglected to realize how static methods truly work. For more information, check out this
reference

TIL about NPM check updates

2019-02-25T19:44:53.124000Z

Do you need to update a bunch of packages? Do they all have a similar scope* or name?

npm-check-updates checks the packages listed in your package.json file, and prints out a list of the packages that can be updated to the latest version.

To install:

npm install -g npm-check-updates

Then, run it in your project folder:

ncu

You’ll get some output that looks a little something like this:

If you want it to automatically bump the versions in your package.json file you can pass in the update parameter:

ncu -u

You can also run it with a regex string if you are just curious about a certain scope or package:

ncu '/^@npm.*$/' -u

Remember to run npm install afterwards to actually install the packages since npm-check-updates will just update your package.json file!

*PS: scopes in npm are useful if you need to group packages by your organization. In the following example "npm" is the scope.

@npm/package-name

Being Intentional With Git Commits

2019-02-23T22:20:34.593000Z

The other day I was poking around in a github repository and came across this commit message:

Not that I needed to know that much about what this person was committing at the time, but I couldn’t help but think how unhelpful this commit message would be if someone needed to understand the project.

At my work we started using commitizen and it took a minute to get used to but after a few days, I could see how much value it was adding to the code base.

First, because it breaks commits down into categories, it forces you to only add relevant files to one category. Buh-bye editing 30 files and committing them all in one go. I mean you still could do that but you will feel a slight pang of guilt every time you add a feature file in with your test files.

After using the tool for a few days, I started thinking about good stopping points in my work to commit so that I could make my messages make the most sense. For example, when working on a feature that also included some refactor work, I would try to just do the refactor first, commit that, and then start working on the new functionality. Looking back at the commit messages when browsing files and seeing the type of change that was made, helps so much for granularity and for knowing what to expect from a certain commit.

Secondly, while other people on the internet might have already been splitting their commit messages into shorter and longer descriptions (ie. subjects and bodies), I was not. And I’ve realized, the longer description is so helpful for describing the nuances of the changes you have made. Even if its just for you to go over before you make your pull request, it will help you understand why you did what you in a way more thorough way - provided you add a thorough description.

At my work, we’ve gone a step further to create a custom command line tool that makes your pull requests for you on Github. The pull request description is a list of your git commits. At first, I was worried this wasn’t enough. How could 100 character commit messages tell you everything you need to know about the code changes? But then, I had a lightbulb moment. The commits already ARE supposed to tell you everything about the code changes. I just wasn’t making my commits well enough. Once I started breaking things down by commit category and providing better commit messages (mainly through the longer descriptions), my pull requests were back up to the level they used to be before when I would write the description myself and have subpar commit messages.

I encourage everyone to set up commitizen and try it out for a few days. I think it will make future you way happier when you are looking back at your code and thinking, "What the heck was I thinking?"

Free Website Template 💰

2019-02-25T19:32:19.062000Z

A month ago I noticed a few people had cloned the repo for my personal website, so I built a website template for ya'll that you can download for freeeeee

You can check out a live preview of it here:
www.erinbush.ca/rubiks

And can clone the repo here:
github.com/erin-bush/rubiks

A Practical Guide for Making your Monolith Accessible

2019-02-15T22:40:12.599000Z

When we set out on making our app accessible, I had a hard time finding out how other companies tackled this. We started at the very beginning of this process and really had no idea where to go. I hope this guide helps you out - no matter what stage of the accessibility journey you are on.

1. Give a lunch and learn on accessibility and start generating empathy.

You can check out the slides from the lunch and learn I gave here:
https://github.com/erin-bush/a11y-cat
. Before I had given this lunch and learn, accessibility really wasn’t on anybody’s mind.

2. Don’t stop talking about accessibility

Make sure everyone at the company knows what accessibility is and why its important

3. Create a mega list of customers asking for compliance with standards.

We found that once we started tagging customer tickets, we had a surprising number of people having issues with our platform and struggling to make their content accessible.

4. If you have a huge app, drill down the most critical user paths that need help first.

For our application, we provide course creators with the tools to make their own online courses. We found that our customers’ students were the ones affected the most by our lack of web accessibility and the student signup to course completion ended up being our critical paths.

5. Put in time outside of work to compile a list of all the known issues.

I recommend using the chrome plugin aXe on every page on your site to generate a list of accessibility issues. Alternatively, you can use the built in chrome lighthouse audits

If you can get buy in from your company to do this, great! We found that as no one knew where to start, and we didn’t yet have buy in from management, we had to take it upon ourselves to make a list of ways we can improve

Note: There will still will be other things that need to be fixed that can’t be automatically tested - this is where manual QA testing process comes in later (see #9)

6. Continue to talk about it.

We found a good way was to keep bringing accessibility to the front of mind of the product team by giving devs a 5 minute fix that they can implement easily as they do their work and highlight a different fix every month.

7. Run an Accessibility Jam after work to fix all of the easy stuff as a group (offer lots of tequila)

We had a ton of things that needed to be solved after we had run the aXe plugin on our user’s critical paths. As we weren’t getting assigned dev time to work on this, we decided to organize our own Accessibility Jam were we wrangled a bunch of developers, designers, and qa people to come to work on the massive list together (with tacos provided 🙂). Both pull requests and alcohol were flowing.

Remember to publish the stats from the jam to keep people motivated!

8. Get the customer support team on board to gather more information from customers who write in about accessibility issues.

We found that videos were the most informative, but even just in depth descriptions of the problem and some information about the screen reader type and browser version they are using.

9. Get accessibility processes integrated into the company’s OKRs.

Our company operates around OKRs, and the next step after getting buy in from management was to find a way to integrate accessibility into our quarterly plans. We tried to attack it from both the process side (checklists for developers, QA and designers) and from the implementation side but found that it would have been better to start with process in one quarter and then work on implementing in the next quarter.

10. Create a list of things devs, designers, and QAs need to accomplish to meet standards (ie. fix the pipeline first, then go back and fix the other stuff)

Once the OKRs were fleshed out we had to actually come up with our processes that enable our upcoming features to be accessible. I recommend taking a look at the vox checklist as they break it down by role.

11. Create a company philosophy on accessibility

We have yet to do this but I believe it is integral to have accessibility written into the policy so that when we are questioning if we have time to work on something or not, we can refer back to the policy as law

12. Automate some accessibility checks.

We have yet to this step but there are a few tools that can help you automate your accessibility compliance checks:
1. Git plugin for your pull requests: lighthouse bot or accesslint
2. Precommit hook for sass: set up a precommit hook that runs stylelint-a11y or add as a plugin to your code editor
3. eslint jsx a11y plugin
4. Integrate dev checklist into github PR checklists: set up a PR template that includes the checklist items from the list you made in step 10

13. Add in an accessibility feedback link to get first hand information on issues.

At the bottom of the page, include an accessible link that allows people to give feedback directly, possibly in the form of a type form.

14. Fix fix fix!

Keep pushing to have old accessibility issues integrated into feature work that touches currently inaccessible parts of the code.

15. Get an audit (could also be done earlier) to get access to people who use screenreader and assistive technology all 👏 the 👏 time 👏 to find issues you can’t automate

There are a few companies that do this but one that we like is Fable

16. Run a show and tell to update the rest of the company of your phenomenal efforts 🙌

Tons more resources available here: https://a11yproject.com/resources

npm link/unlink clarity 🤙

2019-02-06T21:05:04.671000Z

I kept getting confused with the link/unlink order mostly because I was getting myself into weird situations with permission issues where I would have the package not available anymore.

There are some good resources out there for linking but I was struggling at first to find the documentation for unlinking. I’ve written down the exact steps for both so that future devs never struggle like I did.

Lets say we have an npm package that we are working on locally, lets call it cowabunga. Our project structure looks something like this:

And it’s package.json file looks something like this:

You’ll notice that this package has its own node_modules folder - this is where I kept getting tripped up. I would switch branches (where my package lived) and the node_modules folder would disappear. When I would go to unlink, npm was throwing permissions errors that went something like this:

npm ERR! enoent ENOENT: no such file or directory, access ‘my_project/node_modules/cowabunga/node_modules/react’

In order to avoid this, you have to follow the linking/unlinking order otherwise npm will try to unlink folders that no longer exist. Seems pretty basic but it was surprisingly tedious to figure out.

Linking:

First, in the cowabunga folder (where package.json is):
npm link

Then in the project you want to include cowabunga in:

npm link cowabunga

Unlinking:

Before switching branches and/or removing any node modules from the package itself (in my project, this includes running learn clean which removed the node_modules folders)

First, in the project:
npm unlink --no-save cowabunga

Second, in the package:
npm unlink

Note: order is important!

Where I kept running into issues is switching branches and then the symlink couldn’t find the package anymore so you were stuck in this weird state where you couldn’t link anything or unlink anything because the folders don’t exist. When this happens, check out your original branch and start from the beginning with linking the package and the project.

🤙

Bonus:
You can also run
npm install -g i .
in your package folder to install it globally 🎉

TIL: The importance of importing a module explicitly with React Apollo

2019-01-22T17:30:44.870000Z

While trying to write some tests for a React component that makes use of Apollo, I was getting increasingly frustrated when I couldn’t actually access the component. I had a big lightbulb moment when this Stack Overflow told me to simply use the exported component instead of the default export. I was testing the component as a whole and Apollo was adding some extra functionality on top that made testing a challenge, and in order to actually unit test my component, I don’t need the Apollo garnish.

Here’s what I had:

// UsersImport.js

export class UsersImport extends Component { 
  ...
}

export default compose(

  ...
)(withApollo(UsersImport))

// UsersImport.spec.js

import UsersImport from './UsersImport'

Here’s what I actually needed to do:

// UsersImport.spec.js

import { UsersImport } from './UsersImport'

That way, I have access to the first export (UsersImport) and not the entire module that includes Apollo.

Useful Github Shortcuts 💅

2019-01-22T17:33:13.612000Z

Inspired by this post, I made a handy table for all your github shortcuts.

Keyboard Shortcut	Location	Function
`t`	Repository view	Fuzzy file search - use arrows to navigate through files, enter to open the file
`t`	File view in pull request	Jump to a function/symbol
`y`	File or directory view	Convert URL to a permalink
`b`	File view	Show blame
`/`	Anywhere	Search all code in repository
`ctrl . + ctrl 1`	Adding a comment	Insert the first saved reply
``` suggestion `# make this change` ```	Adding a comment	Create a suggestion that someone can commit to their PR
`g` + `p`	Repository view	Opens the pull request tab
`u`	Pull request list view	Filter by author
`l`	Opening a pull request	Apply a label
`a`	Opening a pull request	Add an assignee

React Code Snippets✂️

2019-01-15T21:57:22.188000Z

Figured I should start walking the walk with this whole "giving back to the dev community thing" so I made a gist of the react Visual Studio Code snippets that I use regularly.

To install them in your VS Code, go to File > Preferences > User Snippets (or Code > Preferences for Mac) then select New Global Snippets File. You can then name it and copy-paste these snippets into that file.

To create your own code snippets you can follow the instructions here

Tech Specks Week #6💧

2019-01-15T20:09:39.307000Z

Over the last few weeks I’ve taken a bit of a break from the usual tech specks to relax over the Christmas break and also to think about my goals for the year. I’m trying out a new format here on the blog, one detailed summary and a list of the other 4 articles I’ve read over the week. If you are interested in the rest of the summaries, hop over to my course and check it out. I’ll be updating it every week!

#1 How to apply SOLID principles in React applications

Single Responsibility Principle

The component should have one and only one reason to change (like if the react component should update or not): should just be a header component or just a footer, shouldn’t do both unless its a wrapper

Have functions passed in as props that handle data mutations.

Have a presentation component that encapsulates html and styling of components.

Open Closed Principle

Software entities (classes, modules, functions, etc) should be open for extension but closed for modification

Use component composition (displaying children nested in components) to reorder/change structure of the child elements without changing the parent.

Shouldn’t have to change the render function

Liskov Substitution Principle

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program

If extending a component, it needs to act the same as the parent (initialized the same)

Interface Segregation Principle

We should not depend on things we don’t need

Only pass in props that are used (not the whole object if you don’t need it - but not just limited to props)

Dependency Inversion Principle

We should depend on abstractions not concretions

A high level module should not depend on low-level details, both should depend on abstraction (ie. create an interface to fetch data).

Should have no knowledge of HTTP, SOAP or other protocols

Resources

For more information on logging for debugging purposes check out loglevel

What I learned in a 3 hour meeting ⏰

2019-01-12T01:17:50.509000Z

This week, I was involved in a meeting that got a little heated, and the discussion ran on pretty long but I feel like overall it was a success. I wanted to share the behavioural pieces I noticed the more senior people in the room did that enabled conversation to continue in a focused direction and allowed people to feel like they walked away with something accomplished.

Is it helpful to go around and say examples of ___?

At one point we were trying to define this super vague idea of an "aha moment" in our platform and all of us were struggling to pin it down. We went around in circles a little bit until we were able to each say our experience of an aha moment as a customer of the platform. It caused us to zoom in for a brief moment instead of waxing philosophical for a long time.

What is the problem we are trying to solve?

At this time, the conversation had gotten pretty specific and a little off topic. Once again trying to zoom in on what we were trying to solve and give to customers gave the conversation a focus.

Lets all give our summary of the meeting.

After spinning wheels for a little bit and running over time, we decided to call it for the day but first had everyone go around and state their main take-aways. It ensured we were all on the same page and knew what to chew on for the next follow up meeting.

That’s it! I feel like these are all simple questions to think about and integrate into the next passionate discussion you have ✌️

My Reading List for 2018 📖

2019-01-07T16:59:06.375000Z

As mentioned in my last post, I made it to 71 book this year 🤓 Here’s the final list - If it has a star beside it, I highly recommend it:

The Immortal Life of Henrietta Lacks - Rebecca Skloot
The Penelopiad - Margaret Atwood
Hiroshima - John Hersey ⭐
Boy Snow Bird - Helen Oyeyemi
The Orenda - Joseph Boyden
Full tilt - Dervla Murphy
Oryx and crake - Margaret Atwood ⭐
Let’s Pretend This Never Happened - Jenny Lawson
Braving the Wilderness - Brene Brown
Weapons of Math Destruction - Cathy O'Neil ⭐
Sh*t My Dad Says - Justin Halpern
The beauty myth - Naomi Wolf
Dept. of speculation - Jenny Offill
Hope in the dark - Rebecca Solnit ⭐
A Room of One’s Own - Virginia Woolf
Barrelling Forward - Eva Crocker
The Year of the Flood - Margaret Atwood
Hunger - Roxanne Gay ⭐
Young Jane Young - Gabrielle Zevin
The Notorious RGB - Irin Camrom, Shana Knizhnik
The Clay Girl - Heather Tucker
MaddAddam - Margaret Atwood
The Red Parts - Maggie Nelson
Coralline - Neil Gaiman
Men Explain Things to Me - Rebecca Solnit
Heart Burn - Nora Ephron ⭐
The Circle - Dave Eggers
The Color Purple - Alice Walker
Bloomability - Sharon Creech
What Happened - Hilary Rodham Clinton
Modern Lovers - Emma Straub
The Alice Network - Kate Quinn
The Nest - Cynthia D’Aprix Sweeney
The Muse - Jessie Burton ⭐
Modern Romance - Aziz Ansari
Hygge: The Danish Art of Happiness - Marie Tourell Søderberge ⭐
The Nix - Nathan Hill ⭐
The Vagina Monologues - Eve Ensler
Stone Mattress: Nine Tales - Margaret Atwood ⭐
The Gypsy Moth Summer - Julia Fierro
Your Heart is the Size of Your Fist - Martina Scholtens ⭐
The Course of Love - Alain De Botton
The Hitchhikers Guide to the Galaxy - Douglas Adams
The Book of Joan - Lydia Yuknavitch
All We Leave Behind - Carol Off ⭐
Why I’m No Longer Talking to White People About Race - Reni Eddo-Lodge ⭐
The Argonauts - Maggie Nelson
Shrill - Lindy West
So You Want to Talk About Race - Ijeoma Oluo
The Power - Naomi Alderman ⭐
Shrewed - Elizabeth Renzetti ⭐
The Rosie Project - Graeme Simsion ⭐
The Fifth Season - NK Jemisin ⭐
Heart Berries - Theresa Marie Mailhot ⭐
The Obelysk Gate - NK Jemisin
The Rock Warriors Way - Arno Ilgner
Barbarian Days - William Finnegan
Crazy Rich Asians - Kevin Kwan
A Man Called Ove - Fredrik Backman ⭐
Between the World and Me - Ta-Nehisi Coates
Meaty - Samantha Irby
Like a Mother - Angela Garbes
The Nightingale - Kristin Hannah
This Will Be My Undoing - Morgan Jerkins ⭐
The Best Laid Plans - Terry Fallis
When Breath Becomes Air - Paul Kalanithi ⭐
The Goldfinch - Donna Tart
Hyperbole and a Half - Allie Brosh

2018 In Numbers 🍪

2019-01-07T16:59:21.675000Z

2018 was a great year! I took a moment to reflect on all that I’ve accomplished in just 365 days:

📄 12 blog posts published
🛩 5 trips
💻 1,821 Github contributions
👩‍🏫 1 conference attended
📖 71 books read
🎧 38,725 minutes listened on Spotify
📈 4 ETFs invested in
⚙️ 1 open source project contribution
☕️ too much coffee consumed

#GOALS #2019 👩‍💻

2019-01-11T18:31:54.102000Z

I’m a little late to the resolution game but over the last week I’ve been doing some serious reflection (while on a ski trip in Nelson, BC) and have realized I’ve come a long way from when I first started my developer journey almost 8 years ago. This year a main theme for me is engaging in the developer community and sharing some of the skills I’ve been building over the last few years.

Build out my React knowledge

I learned react almost 2 years ago but working on a weird edge case made me realize I still have a ways to go with my React understanding before I can call myself an expert. I don’t want to limit what React-related a I focus on but a good start would be on performance and a more in-depth look into higher order components

Continue to read a technical article a day

A few months ago I made a commitment to reading one technical article a day and started putting the summaries of articles into a newsletter-style course.

Connect with the developer community more

I signed up for dev.to in the hopes to engage more with developers and to find more technical articles to read to expand my knowledge. I also want to start attending local meet ups at least once every 3 months.

Be a thought leader in the company on accessibility measures and follow through on implementing automated and manual accessibility checks

This goal has been in the works for a while but I want to formally commit myself to pushing our company forward on all things accessibility related and to providing a decent accessible experience for all users of our application.

Master GraphQL subscriptions

This is a also to push me to learn more about GraphQL and all the cool opportunities it provides. I see a real use case in our app for implementing subscriptions and I intend to follow through on it.

Understand Redux and explore React Context as an alternative

Redux is a magical black box to me right now and I would love to have a better understanding of its implementation and use cases.

Follow up

This is how these goals actually translated into my 7Geese personal OKRs for the quarter at Thinkific:

Here’s to another great year! 🍻

I Made an Online Course! 📚

2019-01-15T18:43:44.133000Z

Being a developer at Thinkific for almost 2 years, I decided it was high time to make my very own online course. I’ll be moving my tech specs over to the course for the time being. I’ll make one article summary available on the blog per week and the 4 other articles will be available in the course.

If you are interested in enrolling here is the link: diy-developer.thinkific.com

This course came about from me wanting to help others work on their technical knowledge as well. If you remember from my goals blog post in September, I wanted to work on my technical expertise. While I feel like we are never done learning new technical skills, I think an important next step is to share what I have learned and also help others work on their technical knowledge as well.

Happy 2019 all!

Commenting over Requesting Changes ☠

2018-11-20T21:50:10.555000Z

It took me 3 business days + a weekend to find the courage to stand up to my boss after he requested changes on my pull request.

How? How does this happen? I am usually a very opinionated person who will definitely tell people how I feel about a situation - especially at work. Its my job to have an opinion.

One of my goals for the year is about building technical confidence. I’m reading one technical article a day in order to expand in depth and breadth of knowledge. I attended a front end conference to do just the same thing. I’m actively planning lunch and learns and discussions on how to bring what I’ve learned into our product. So why, WHY, was it so hard to tell a senior dev that I disagreed with his tactic.

To set the stage, in the past, this developer has never approved one of my PRs on first look. Even for suggestions, he very liberally uses the "request changes" feature of the Github pull request method. That’s fine. That’s not the issue. I love getting feedback. Most of the time I agree with him that it could be done better. 90% of the time we end up going with his suggestion.

This time around, I read an article about the very issue we were talking about. And while nothing is set in stone, I felt pretty confident that I had the right approach before I created my pull request. Not expecting any suggestions on this little number, I made the PR and happily went along with my day.

The email notification came in with a hefty subject of "{Senior Dev} requests changes on your pull request". Not surprised (remember, this happens every time), I go in and see his suggestion. I craft a thoughtful response that I think very nicely summarizes why I think my approach is better, submit, and then see another comment come in that is his exact words, but rephrased. He thought I didn’t understand his approach. I understood, I just didn’t agree. And this is where the waiting period began.

I knew he thought I was going to make the changes, I knew he was expecting it. I also know that he sometimes goes in after someone has done work and will refactor their changes. I had this paralyzing fear that if I didn’t make his changes, he’ll just go back to it in a month and make the changes he wanted in the first place.

I’m not saying that I am always right. I am NEVER saying that I always have the right approach, but in this situation I knew that I did not agree with his suggested changes. I am not going to make the changes. Making the changes feels like loosing.

It just feels like I always walk away from PRs with my tail between my legs despite having grown as a developer (this is my 3rd year as a dev, I am far from beginner). I should have an opinion. I am paid to have an opinion. But changing a power dynamic is hard. And telling someone with 6+ more years of experience than you that you think they are wrong is also hard. I know it was unprofessional to leave his comment and my PR sitting there for almost a week but I didn’t know how to start. Isn’t "request changes" just that? A request? Its not "mandate changes", its also not "we have held a fair trial and the ruling is that there must be changes".

When I review someone’s pull request, maybe because I am still partially unsure, or maybe just constantly conditioned to be unsure, but if in someone’s pull request something is a little off but not a necessary change and there aren’t any obvious errors, I use the "comment" and not the "request changes". I feel this opens people up for discussion on something you, yourself is not fully sure of. Why can’t we all start discussions about someones work instead of deciding they don’t know what they are doing?

My 2 cents ✌️

Tech Specks Week #5 ⛷️

2018-12-31T04:47:58.191000Z

#1 On Being a Senior Engineer [Part 1]

Senior engineers should be mature engineers
- Seek out constructive criticism of their designs
- Understand the non-technical areas of how they are perceived
- Doesn’t matter how smart you are if no one wants to work with you
- Be the engineer everyone wants to work with
- Should still offer feedback on code - it doesn’t have feelings and shouldn’t be your baby
- Do not shy away from making estimates and try to get better at making them
- Have an innate sense of anticipation
* how long will this thing last before it needs to be rewritten? Is it readable? Am I making things easier?
not every project will be glamorous
lift the skills and expertise of others around them
* teaching to fish - requires patience and a perspective fo investment in the rest of the organization
Make trade-offs explicit when making judgements and decisions
* cannot be efficient and thorough at the same time - most projects exist on a n axis of optimality and brittleness - problems are either acute or chronic
* immature engineers discover tradeoffs in hindsight, mature engineers spell them out at the onset of a project, accept them and recognize them as a part of good engineering
don’t practise CYAE ("Cover Your Ass Engineering")
* don’t through people under the bus if your work doesn’t work
be empathetic
* recognize that all stakeholders goals are different
* see the project from other people’s perspective
don’t make empty complaints
* express judgements based on empirical evidence and bring options for dealing with them
* don’t go to your boss with a problem without at least one solution
* be aware of cognitive biases
* we are unaware of when we are interpreting things differently in our own brains in ways that defy empirical data
* self serving bias: if something is good, its because of something I did, if its bad, its someone else’s fault
* fundamental attribution error: the bad results someone else got are because of who he is (sloppy, stupid…), if I get a bad result, its because of my context/situation
* hindsight bias: tendency to view the past more simply than it was in reality
* outcome bias: it a damaging outcome, the decisions that came to that action are judged to be very stupid/reckless
* planning fallacy: being more optimistic about forecasting the time required for a project

#2 On Being a Senior Engineer [Part 2]

10 Commandments of Egoless Programming
1. Understand that you will make mistakes - you should just try to find them early
2. You are not your code - don’t take things personally
3. Know matter how much "Karate" you know, someone else will always know more - ask them to teach you some moves
4. Don’t rewrite code without consultation - know the difference between "fixing code" and "rewriting code"
5. Treat people who know less then you with respect, deference and patience
6. The only constant in the world is change, be open to it and accept it with a smile
7. The only true authority stems from knowledge, not from position - if you want respect in an egoless environment, cultivate knowledge
8. Fight for what you believe, but gracefully accept defeat
9. Don’t be the "coder in the corner" - this person has no voice in an open, collaborative environment
10. Critique code instead of people - be kind to the coder, not to the code - make all of your comments positive and oriented to the code (site local standards, program specs, increased performance, etc)

Novices Vs Experts
Novices are deeply subject to local rationality and adhere to rigid rules or plans
Experts are context driven and do not see problems as one thing and solutions as another, they act wholistically

Mature engineers know that how people feel (sometime irrationally) about technology is still important. People’s experiences with technology influence their opinions about it. Mature engineers understand this when making the case for using a specific technology as a solution.

Mature engineers hold the success of the project much higher than the potential praise they might get for working on it.

#3 Designing Accessible Navigations

Navigation also involves moving from section to section in addition to switching pages. To improve usability for everyone:

Allow users to skip content: include skip links (only visible when tabbed to) that allows users to bypass navigation
* important because otherwise users are forced to tab through all of the navigation every time they come to the page

Add an Accessibility Menu:
Reduces the amount of effort it takes for impaired users to access your content
an altogether different navigations to simplify an impaired individual’s experience
* Facebook provides dropdown that allow users to jump to different sections and includes a keyboard shortcut to access it anywhere

Consider Keyboard Shortcuts:
Offers users the opportunity to navigate the site and perform actions with one button - significantly reduces frustration
Lets users skip content they think is irrelevant
Show users a modal with all the possible shortcuts
Add hotkeys for the main pages in your app
* Have a goal for adding shortcuts and don’t just add them randomly

Properly Structure and Label Elements:
Apple’s VoiceOver supports Rotor which pops up a modal that shows the user all of your Headings, Articles, Links, Form Controls, Landmarks, and etc
Having all your sections have descriptive labels that can be used as landmarks and having proper type hierarchy allows users to confidently know what they are skipping

#4 Using Flow for Static Type Checking

Static type checking: types are known at compile time
Dynamic type checking: types aren’t known until runtime (javascript)

With a static type checker, bugs are caught earlier

Implicit Type Coercion: in JS we can reassign values to a variable that are not the same type - if it was a number, you can reassign it a boolean

Flow catches these types of errors.

Even though JS doesn’t check type, its always in the developers mind to reason about the code.

Why use Flow over TypeScript? Flow is easier to use, not a new language - just add /* @flow*/ to the top of a file.

#5 Designing for accessibility is not that hard

Myth: making a website accessible is difficult and expensive - fixing a site that is already inaccessible may require some effort though. Most problems aren’t hard to correct.

Why design for accessibility? Need to create a better experience for all users regardless of ability, context or situation, which usually results in a better experience for everyone.
* studies show that accessible websites have better SEO, a bigger audience, faster download times, encourage good coding practises, and have better usability
Seven easy things you can do:
1. Add enough colour contrast - contrast ratio needs to be at least 4.5 to 1 (conformance level AA) - use WEbAim colour contrast checker
2. Don’t use colour alone to make critical information understandable - use text or patterns
3. Design usable focus states - if you remove the browser focus state, you need to replace it
4. Use labels or instructions with form fields and inputs - don’t use just placeholder text! and don’t make the label disappear when they focus on the input
5. Write useful alternative text for your images and other non-text content - try to describe what’s happening in the image and how it matters to the story rather than just saying "picture". If you definitely don’t need alt text because the picture is redundant, adding an empty <alt> attribute will make screen readers skip it.
6. Use correct markup on your content - the components and structure of a page are what arranges an accessibility tree which powers screen readers
7. Support keyboard navigation - people who don’t have precise motor control (and power users!) rely on keyboards - pay attention to the tab order of elements - provide ARIA landmarks to make navigation easier

Tech Specks Week #4 🏎

2018-10-25T22:11:14.819000Z

More webpack and javascript fun!

#1: Caching (with webpack)

Need to configure webpack to ensure files produced by webpack can remain cached unless their contents has changed

can use build-specific chunk hashes -> filename: ’[name].[chunkhash].js'
runtimeChunk: split out runtime code into separate chunks - also good practise to do a vendor chunk (eg lodash/react) -> cacheGroups
adding one module in your app will change the module.id in vendor files - use the NamedModulePlugin to use the module path instead of a numerical identifier

#2: How to escape async/await hell

What hell is: people write multiple statements one after the other and put an await before a function call
- Causes performance issues - many times one statement doesn’t depend on the previous one

What if we don’t use the await keyword?
- We get an unresolved promise (which we can use later)
- The compiler won’t wait for the function to execute properly

What can we do?
- Get the promise and then wait for it in another line

Steps to get out of hell
1. Find statements which depend on the execution of other statements - make things as parallel as possible
2. Group-dependent statements in async functions
3. Execute these async functions concurrently - take advantage of the event loop to run these async non-blocking functions concurrently

#3: BigInt: arbitrary-precision integers in JavaScript

Lets you store/operate on large integers even beyond
Makes it possible to correctly perform integer arithmetic without overflowing (eg. financial technology)
Usually represent large integer ids/timestamps as string because the ints lead to lots of bugs - BigInt fixes this
Big Int could lead to BigDecimal!

js decimal problem (0.1+ 0.2 !== 0.3)

> 0.1+0.2
<- 0.30000000000000004

Previously had to use libraries to do big int calculations - can now use native BigInt which will reduce load time, parse time, and compile time + have run time performance. Still need to polyfill BigInt

Number:
- Number type in js are represented as double-precision floats = limited precision
- Doing calculations on integers outside of the safe integer range (from Number.MIN_SAFE_INTEGER to Number.MAX_SAFE_INTEGER) potentially loses precision

BigInt:
- Can safely do things outside of the limit for Number
- To create a BigInt, add n to the end of any integer literal (eg. 123 -> 123n), can also use BigInt(123) === 123n
- Safe integer limits don’t apply to BigInt

eg:

BigInt(Number.MAX_SAFE_INTEGER) + 2n; //will be accurate

A New Primitive:

    typeof 123n 
// -> "bigint"

BigInt is never strictly equal to a number (42n !== 42) - to compare them, will need to convert (42n === BigInt(42))
When coerced to a boolean, BigInts follow the same logic as numbers (0n is falsey)

Operators:
- BigInts support most common operators, bitwise operations (|, &, <<, >>, and ^) perform bitwise arithmetic assuming a two’s complement representation for negative values (just like for numbers) - Two’s Complement
- Unary - works to make bigint a negative but, unary + is not supported because asm.js expects +x to always produce either a number o an exception
- Can’t mix operations between bigint and numbers (Bigint(2) + 2.5 -> ??? results in a TypeError)
- >>> (unsigned right shift does not work for BigInt because they are always signed

#4: Removing jQuery from Github Frontend

Why:
- Sometimes tech debt grows around dependencies that slowly loose value
- Some of the jQuery syntax doesn’t show intent properly - jQuery will select all of one type (did the author intend this?), and jQuery also silently skips expressions if they don’t match anything on the page
- jQuery is not compatible with Flow (or other static type checkers)
- Removing jQuery means you can rely on web standards more

Incremental Decoupling:
- Monitor number of jQuery calls
- Don’t allow importing jQuery into new code - use eslint to error
- Disable all subsequent eslint errors - shows devs its not up to coding standards
- People see the eslint disable in code reviews and prompts people to fix it
- Static type checking added confidence when refactoring code to vanilla js
- replace $.ajax with fetch()
- Incrementally remove jQuery modules that were no longer being used (creates a custom jQuery) - sped up JS
- Dropped old IE support and then didn’t have to worry about polyfills
- Only used JS as a progressive enhancement so that it would still work with JS disabled in the browser - then didn’t have to rewrite support in JS - could get rid of it altogether

Custom Elements:
- Component library native to the browser - nothing for the user to download, parse, compile
- Focussed on progressive enhancement when making elements

Polyfills:
- Use specific polyfills only when they are necessary for the user and not all the time (ie. to outdated browsers)

#5: Optimize your Application Bundle Size with Webpack

Use webpack-bundle-analyzer to visualize how big your project dependencies are.

First, install with npm install webpack-bundle-analyzer. Then, modify your webpack.config.js by adding:

var BundleAnalyzerPlugin = require(‘webpack-bundle-analyzer’).BundleAnalyzerPlugin;

//…
plugins: [
  new BundleAnalyzerPlugin(),
  new webpack.DefinePlugin({
    ‘process.env.NODE_ENV’: ‘"production"’
  }),
]
//…

However you start your server, it should serve you a new page at http://localhost:8888 that has your projects visualizations and should be for the production version of your code.

When importing dependencies use:

import groupBy from ‘lodash/groupBy’

instead of:

import loads from ‘lodash'

Remove your source map for production to save on space by using: devtool: ‘eval-source-map’ instead of devtool: ‘eval’

gz compression: use compression-webpack-plugin - compresses assets and generates .gz files
de-duplicating: use dedupe-plugin - removes duplicates of equal/similar files from output, has overhead for entire chunk but can reduce file size
minimizing JS: use uglifyjs-plugin - minimizes all JS output of chunks
only include what’s necessary from module: use ignore-plugin - import selective modules

Tech Specks Week #3 😎

2018-10-25T22:11:14.626000Z

I focussed this week on Webpack and some React-y things. Lots of learning going on over here.

#1: Lazy Loading with Webpack (follow up to code splitting)

only load code when the user requires it - speeds up initial loading of the app (some blocks may never be loaded)

button.onclick = e => import(/* webpackChunkName: "print" */ './print').then(module => {
  var print = module.default;
  print();
});

Note: when using import() on ES6 modules, you must reference the .default property as it’s the actual module object that will be returned when the promise is resolved

#2: React and Code Splitting

Incrementally downloading the app
- packages: webpack, babel-plugin-syntax-dynamic-import and react-loadable

babel-plugin-syntax-dynamic-import
- syntax-only plugin meaning babel won’t do any transformation
- allows babel to parse dynamic imports so webpack can bundle them as a code split

react-loadable
- higher-order component for loading components with dynamic imports
- makes code splitting easy!

import Loadable from 'react-loadable';
import Loading from './Loading';

const LoadableComponent = Loadable({
  loader: () => import('./Dashboard'),
  loading: Loading,
})

export default class LoadableDashboard extends React.Component {
  render() {
    return <LoadableComponent />;
  }
}

Then use LoadableDashboard and it will automatically be loaded and rendered when you use it in your application
- loading is a placeholder component to show while the real component is loading

react-loadable also has suggestions for server-side rendering

#3: File Bundling and HTTP/2: Rethinking Best Practices

HTTP/2: based on Google’s SPDY protocol - intent is to improve page load latency and security
- binary protocol not text based (more compact, efficient to parse and less prone to errors)
- multiplexed: multiple files can be transferred on a single connection
- server push: allows the server to transfer resources to the client before they’re requested (pre-filling the cache

HTTP/2 and JS developers
- concatenating multiple files into bundles makes it difficult for the browser to effectively cache our code
- the whole bundle needs to be redownloaded if one line of code changes
- since HTTP/2 can multiplex (making requests inexpensive) we can split code into smaller bundles and make use of caching (better experience for users)

web servers also have limits on how efficiently they can serve a large number of files (so we shouldn’t endlessly split files)

#4 webpack and HTTP/2

Still is protocol overhead for each request compared to a single concatenated file
The compression of the single large file is better than many small files
Servers are slower serving many small files than a single large file

Changing one module invalidates the cache for one bundle which is only a part of the complete application - the remaining application is still cached. Need to find a balance.

More bundles = better caching but less compression

AggressiveSplittingPlugin (from webpack)
- Splits the original chunks into smaller chunks (you specify the size)
- To combine similar modules, they are sorted alphabetically (by path) before splitting - modules in the same folder are probably related to each other and similar from compression point of view - with this sorting they end up in the same chunk

We need to reuse the previously created chunks
- When AgressiveSplittingPlugin finds a good chunk, it stores the chunk’s modules and has into records (web pack’s concept of state that is kept between compilations)
- AggressiveSplittingPlugin tries to restore the chunks from records before trying to spit the remaining modules (ensures reuse)

The application using this optimization will have multiple script tags to load each chunk in parallel
- The browser can start executing older files in cache while waiting for the download of most recent files
- HTTP/2 Server push can be used to send these chunks to the client when the HTML page is requested - best to start pushing the most recent file first as older files are more likely already in the cache
- The client can cancel push responses for files it already has, but this take a round trip
- When using code splitting for on demand loading, w ebpack handles the parallel requests for you

#5: 6 Reasons Why JavaScript’s Async/Await Blows Promises Away

Async/await makes asynchronous code look and behave a little more like synchronous code. Any async function returns a promise implicitly and the resolve value of the promise will be whatever you return from the function

Why is it better?
1. Concise + clean (no more .then, no more nested code)
2. Error Handling: can handle synchronous and async errors with the same construct (try/catch) - previously, try/catch won’t handle errors inside the promise
3. Conditionals: simplifies cause it makes multiple promises easier
4. Intermediate Values: no more crazy nesting promises or using promise.all
5. Error stacks: especially in production environments with large promise chains
6. Debugging: much easier - promises were annoying because you couldn’t set breakpoints in arrow functions that return expressions (no body)
- Doesn’t step through .then statements because it only goes through synchronous code
- With async/await you can step through like its synchronous

Harder things:
- More difficult to spot asynchronous code

I'm a Node.js Contributor!🏅

2018-10-25T20:35:29.813000Z

I attended the Node+JS Interactive conference last week in Vancouver. I found that every session I went to sparked some kind of idea for ways we can improve our product and workflow at Thinkific, and also for some personal projects I want to get started on. The only problem is deciding what I want to start first because there is so much 🙈

There was a strong female speaker presence which was refreshing (although it shouldn’t be surprising since its 2018). I also appreciated that there were no all-male diversity panels and all of the female speakers were discussing technical topics, not "what its like being a female developer 🙄". So good job Node+JS Interactive (even though its 2018 and I shouldn’t have to be congratulating you on this).

The last day of the conference they did a workshop where they had about 300 people contribute to the Node.js project. I was v impressed with how streamlined it was - I built Node locally, ran the tests, got a tiny task to work on, submitted a PR and was approved all in about 2 hours. And now I can say that I contribute to the open source community 🙃 I’m very proud of my pull request.

The talks that got me the most jazzed were:

Leaving the CDN Behind: Building a JavaScript SDK in a Serverless World - Daniel Brain

Main Takeaways: Dynamically compile relevant code used by a component and cache it for speed. SDK is available at a url that specifies the component. Stays evergreen so you don’t have to worry about versioning and maintaining older versions
Slides

Automated Performance Testing - Christian Bromann

Main Takeaways: You should come up with performance metrics for your app (ie. it should be interactive in less than 5 seconds) and integrate automated testing in your CI/CD workflow. One option for tooling is WebDriver.
Slides
Video

Machine Powered Refactoring: Leverage AST’s to Push your Legacy Code (& the Web) Forward - Amal Hussein

Main Takeaways: You can make custom linters and refactor old code using ASTs. We just did a tiny little dive into the world of ASTs but it seems very powerful. I can definitely see applications for creating custom accessibility linters that we’ve been meaning to build out to make accessibility a priority for developers.

Talks that I didn’t make it to that I still want to see

Talks that seem cool but don’t have videos yet

Offline First: Making your App Awesome When the Network Isn’t - Teri Chadbourne

Slides

Zero to Production with the Serverless Framework - Diana Lee

Slides

Tech Specks Week #2 🐳

2018-10-18T20:12:30.214000Z

I managed to hit 5 articles this week 🙌 I’m already finding a lot of value re-reading all of the blurbs on Fridays. This week I focused on Webpack and some Async/Await fun.

#1: A Beginner’s Guide to Webpack 4 and Module Bundling - Part 1

Webpack: module bundler for JS but can be used for HTMl, CSS and images
- can give you more control over the number of HTTP requests your app is making
- can easily consume packages from nom
Can create an npm script for running webpack -> npm run develop (dev mode) or npm run build for production
- production is minified and file size is much smaller - optimizes for execution speed at runtime and output file size
- dev mode optimizes for build speed and debugging

ES Modules (split your program into many small, self-contained programs
- importing modules from npm don’t uses a relative path but all of your own imports do need a relative path

Tree Shaking
* in dev mode, webpack includes whole packages but in production mode all of the unused modules are removed from bundle

Loaders
* let you run preprocessors (eg. babel) on files as they are imported - allows you to bundle resources beyond js
* loaders can be chained to gather into a series of transforms

CSS in JS
import ‘./style.scss’
* needs the style-loader npm package which outputs the string tiny an embedded <style> tag
* Makes it easier to bundle assets together (images, css, HTML)
* dead code elimination: when the JS component is no longer loaded, the CSS file will also not be loaded
* css modules: local CSS with unique classes to avoid css overwriting
* this allows us to decrease HTTP requests by bundling/splitting code cleverly

Images (eg package: file-loader)
* store the source of images as strings inside js - preloads them and the browser doesn’t have to fetch them with separate requests later

import imageExample from ‘./image-example’
img.src = imageExample

this will include an image where the src attribute contains a dataURI of the image itself
background images in CSS are also processed by file-loader

#2: A Beginner’s Guide to Webpack 4 and Module Bundling - Part 2

Dependency Graph
- loaders build a tree of dependencies among your assets and compiles single static assets

Code Splitting
- allows you to split code into bundles that can be loaded on demand or in parallel (faster load time)

button.onclick = () => {
  import(/* webpackChunkName: "chat" */ "./chat").then(chat => {
    chat.init()
  })
}

We can import the webpack chunk when we click the button (lazy loading)

Plugins
* loaders operate transform on single files, plugins operate across larger chunks of code
* help split code in clever ways and optimize for production
* webpack plugin "mode" lets us use dev and production specific plugins (eg: UglifyJsPlugin)

Production
* need a config file for dev, and prod (webpack.common.js, webpack.dev.js, webpack.prod.js - use common file in both dev and prod file)

Split CSS
* best practise is to split CSS from JS when bundling for production (use ExtractTextWebpackPlugin) and add the css file to your html as a link
* allows for parallel loading of JS and CSS so it will be faster

Generating HTML
* html-webpack-plugin updates our index.html file to reference new file paths

Development
* webpack-dev-server provides a simple web server with live reloading
* HotModuleReplacement swaps module at runtime without the refresh

HTTP/2
* webpack gives you control over how assets are fetched as well
* HTTP/2 allows multiple files to be delivered in a single request (so concatenation isn’t a silver bullet anymore)
* Could be more performant to cache several small files

#3: Code Splitting

Code splitting allows you to split code into various bundles to load them on demand or in parallel

3 Approaches:

Entry Points - manually split code using entry configuration
in the webpack.config.js file, list the modules by their js files

module.exports = {
    mode: ‘development’,
    entry: {    
        index: ‘./src/index.js’,
        another: ‘./src/another-module.js’
    }

Pitfalls:
* If there is duplicated modules between chunks, they will be included in both bundles
* Can’t be used to dynamically split code

Prevent Duplication - use the SplitCHunks to deduce and split chunks
- extract common dependencies into a separate chunk

optimization: {
    splitChunks: {
        chunks: ‘all
    }
}

other code splitting modules: mini-css-extract-plugin (split css out of main app), bundle-loader (split code and lazy load the resulting bundles), promise-loader (similar to bundle-loader but uses promises)
Dynamic Imports - Split code via inline function calls within modules
- use import() syntax (uses promises so need the promise polyfill for older browsers)
  return import(/ webpackChunkName: "lodash" / 'lodash').then(_
- webpackChunkNAme in the component will cause our separate bundle to be named loads.bundle.js
- import() returns a promise so ti can be used with async functions

Prefetching/Preloading modules
Use inline directives when declaring imports allows webpack to output "Resource Hint" which tells the browser that for prefetch (probably needed for nav sometime in the future) and preload (resource might be deemed in the current nav)

import(/* webpackPrefetch: true */ 'LoginModal');

This creates: <link rel="prefetch" href="login-modal-chunk.js"> (browser will prefetch)

Prefetch: webpack will add the prefetch hint once the parent chunk has been loaded

Preload vs prefetch (browser support could be different!)
* preload chunk loads in parallel to parent and prefetch loads after parent
* preloaded has medium priority and is instantly downloaded, prefetch loads in browser idle time
* preloaded instantly requested by parent, prefetch is used anytime in the future

Bundle Analysis:
* useful to analyze code splits to check where modules end up (use like webpack-chart and webpack-visulizer or webpack-bundle-analyzer)

#4: Async Function

An async function operates asynchronously via the event loop - uses a promise to return its result

function doesTheWork() {
    return new Promise(resolve => {
        setTimeout(() => {
            resolve(‘resolved’);
        }, 2000);
    });
}

async function asyncCall() {
    var result = await doesTheWork();
    console.log(result) // "resolved"
}

asyncCall()

Async functions can contain an await expression that pauses the execution of the async function and waits for the passed Promise’s resolution, and then resumes the async function’s execution

The await keyword is only valid inside async functions - you will get a SyntaxError otherwise

Options:

//sequential start - takes 2 + 1 seconds

async function() {
    const slow = await resolveAfter2Seconds(); 

    // if the value of the expression following the 
   //await operator is not a Promise, it’s converted to a resolved Promise
    const fast = await resolveAfter1Second();
}

//concurrent start - takes 2 seconds total - this can also be done with Promise.all (might be better if you have
//to wait for more than 2 promises 

async function() {
    const slow = resolveAfter2Seconds();
    const fast = resolveAfter1Second();

    console.log(await slow);
    console.log(await fast); // doesn’t log until slow is done!
}

The async function is implicitly wrapped in Promise.resolve so you don’t have to put an await on the return statement in an async function

#5: Async/await

async: a function will always return a promise (js will automatically wrap the return statement in a promise
await: only works inside the async function - makes js wait until that promise is resolved, and then evaluates the expression

the waiting doesn’t cost CPU resources because the engine can do other jobs in the meanwhile
similar to promise.then but easier to read/write

// wait 3 seconds
await new Promise((resolve, reject) => setTimeout(resolve, 3000));

await accepts thenables (any function that 

class methods can also be async:
class Waiter {
    async wait() {
        return await Promise.resolve(1);
    }
}

new Waiter().wait().then(alert); //1

Error Handling:
- await Promise.reject(new Error("Whoops!"))
- await waits for the promise to resolve then throws the error
- Can use in a try/catch as per usual
- if not in a regular try/catch, the promise is rejected and we can do something like: f().catch(alert);

Resolving Conflicts in Real Life 🔪

2018-09-25T23:02:00.309000Z

In any workplace, conflicts will arise. However, in a workplace where you are one of 4 female developers on a team of 20, there will be lots of opportunities to say something about not okay situations, and the key is to not have it turn into a conflict. Which, turns out, is really frickin hard.

A few weeks ago, myself and the a few other female devs watched a webinar on resolving workplace conflict put on by Tech Ladies. It was short and sweet but there were a few key takeaways that stayed with me.

Positions Vs Interests

Positions are someone’s solution to an issue. Interests are someone’s concerns they want to resolve. The key is to move everyone from positions to understanding all interests. Its easier to find a good solution when you understand people’s objectives.

“I"-statements are also positions, eg: “When you offer everyone except me a donut, I feel left out". (I found this interesting to learn because you hear so much about using them to not lay blame on others but its not an effective way of communicating during conflict).

Relationship Building

Often, its not about the solution, its about building relationships and getting on better terms.

There are 3 types of mediation (two of which value relationships):
1. Evaluative: has a fast timeline and requires quick action. Success criteria is the settlement itself.
2. Facilitative: opportunity to develop skills and resolve future conflict. Success criteria is the settlement and relationship building.
3. Transformative: the outcome is minor and the relationships are critical. Success criteria is prevention and self management.

Separate People from the Problem

Dealing with problems is often aggravated by people misunderstanding each other or taking things personally. Work on leaving negative emotions out by using clear communication, taking breaks to let people cool down, and discussing each others perceptions.

Tech Specks Week #1 🐙

2018-09-25T22:51:02.617000Z

A main element of my goals for the next year are to level up my technical knowledge both in terms of breadth and depth of particular topics. I thought a fun, achievable step towards that goal is to read one technical article a day and write a quick summary of what I’ve learned from it. So far I only had time for 4 articles this week, but I’m aiming for 5 a week.

So here we are, the first in a series of weekly updates of short summaries of technical articles:

#1: Introducing the Single Element Pattern

Reliability: not needing to open the file and look at the code to understand how it works.

Rules for reliability: (really only works for primitive elements)
1. Render only one element
2. Never break the app:if missing proptypes, show as a warning instead of breaking rendering
3. Render all HTML attributes passed as props: instead of passing an object that renders html props (such as src and alt), make these the prototypes for the react component and then just render the propose the primitive as {…props}
4. Always merge the styles passed as props: use object spread to merge style and className props
5. Add all the event handlers passed as props: always apply the event handler coming from the prop (your choice if it replaces the internal one or both are called)

Suggestions:
1. Avoid adding custom props

For example: if you have a rounded version of the same element, don’t add a prop that is rounded, create a new element that is ElementRounded that rounds the edges

Receive the underlying HTML element as a prop

Make your element more flexible - rendering a button as an anchor tag

#2 How JS works: an overview of the engine, the runtime, and the call stack

The JS engine:
- Google’s V8 engine is used in Chrome and Node.js
- Consists of two main components: the memory heap (where memory allocation happens) and the call stack (wirer your stack frames are as your code executes
Runtime: web APIs provide things like setTimeout (not provided by the engine) and is supplied by the browser (eg. DOM, AJAX and setTimeout)

Call Stack: JS is single threaded so it has a single call stack (can only do one thing at a time)
- Call Stack is a data structure that recourses basically where in the program we are
- Stepping into a function puts at on the top of the stack and returning from a function we pop off the top of the stack
- Stack traces are the state of the call stack when the exception happened
- “blowing the stack" - when the number of function calls in the stack exceeds the actual size of the call stack (recursively calling a function with no termination)

Concurrency & the event loop:
What happens when you do a large resource intensive task that blocks the rest of the app from executing? browser may not be responsive for a long time + might prompt you to close the page
So how do we execute heavy code without blocking the UI? -> asynchronous callbacks

#3 React Fragments

JSX turns <div>s and <MyComponent> into React.createElement() calls so when there are multiple elements instead of a single one, it doesn’t know what tag name to render with.

Solutions:
- wrap elements in a div
- use the render method to return an array of nodes (clunky + non-jsx-y)- the transpolar is putting together an array of React.createElement() calls and affixing them to the parent element as children

render () {
    return [
       <p>hi</p>
       <p>there!</p>
     ]
  }

Best: React Fragment - behaves like the array method

  render () {
    return (
      <React.Fragment>
        <p>hi</p>
        <p>there!</p>
      </React.Fragment>
    )
  }

OR: more concise syntax

  render () {
    return (
      <>
        <p>hi</p>
        <p>there!</p>
      </>
    )
  }

#4 Understanding React’s setState()

setState() is the only legitimate way to update state after the initial state setup (don’t update state directly because the component won’t re-render) - component is re-rendered with that state -> this process is called ‘reconciliation’ (how React updates the DOM)
React creates a new tree containing the reactive elements in the component and the updated state
This tree is used to figure out how the component’s UI should change (compares the updated tree with the previous tree)
* React only updates the part of the component that have changed (makes it fast fast)

Can’t call setState multiple times in a row (eg. trying to increment a value 3 times in a row)

handleIncrement = () => {
    this.setState({ count: this.state.count + 1})
    this.setState({ count: this.state.count + 1})
    this.setState({ count: this.state.count + 1})
}

This is equivalent to:

Object.assign(
    {},
    { count: this.state.count + 1 },
    { count: this.state.count + 1 },
    { count: this.state.count + 1 },
)

Object.assign is used to copy data from a source to a target object but if the data (being copied from the source to the target) all have the same keys, the last object wins.

What will work is using a function within setState() - React will queue the functions in the order they are made and update the entire state once it is done:

handleIncrement = () => {
    this.setState((prevState) => ({ count: this.state.count + 1}))
    this.setState((prevState) => ({ count: this.state.count + 1}))
    this.setState((prevState) => ({ count: this.state.count + 1}))
}

Accessing previous state:
- can’t always trust this.state right after setState() has been called - should be treated asynchronously
- Need to use an updater - like what is in the previous example (using a function that has prevState as an argument)

#GOALS 👩‍💻

2018-09-25T22:36:37.925000Z

Now that it is solidly fall in Vancouver I thought I would mimic all the trees around here and shed some leaves in preparation for new things. First up, change of season haircut, but after that, there are a bunch of things professionally that I want to change. The main theme being immersing myself in the tech community and deepening my technical knowledge. So here we are, my professional goals for the next year:

Build Technical Confidence

Write (or participate in writing) a tech spec for each mid sized project I work on (larger than 1 week)
Find 3 areas of the product (product == Thinkific) to improve and investigate possible solutions
Present a lunch and learn on a technical topic

Get More Involved in Tech Community

Attend 1 meet up every 2 months
Commit to participating in mentorship outside of Thinkific (either as a mentor or mentee)

Increase Technical Expertise

Read 1 technical article a day and write a short summary paragraph on it
Complete 1 short course every month (less than 5 hours)

Thats it! Time to get reading…

Becoming Enough 👏

2018-09-25T22:36:37.921000Z

Last night I went to a meet up on Imposter Syndrome that opened with a panel discussion. I’ve been to other panels before and while they have always been informative, I found myself walking away from last night internalizing so many eye opening pieces of advice. There is so much to apply to my life, not just in the workplace. I scrambled to scribble down the major takeaways from the event as there was so much. Here is what I found were the most valuable:

Imposter syndrome has a bodily aspect to it (make yourself smaller)
Imposter syndrome is failing to internalizing your own achievements
Society loves the wonderkid and you don’t see successes that incorporate a lot of failure (impossible to achieve overnight success)
Behind the feeling of imposter syndrome is how we learned the idea of failure and our relationship with the learning process
Don’t avoid writing code because you are scared to ask for help
Everyone brings something to the table even if they don’t have traditional education
Maybe Imposter Syndrome just one side of the human spectrum
Imposter Syndrome is an internal/external thing - your reaction and other people’s reaction
If you are looking for clues that you aren’t good enough, the world will definitely provide - change your focus to proof that you ARE doing a good job
We get asked insurmountable things that feel impossible when we are starting out but everyone has that feeling

✨Advice✨

Put your feelings and emotions on hold and put the projects and groups objectives before your own of inadequacy
Remember that you are here for a reason and things didn’t just fall into your lap
If you don’t know how you are doing - ask for feedback because it will be way more constructive than worrying
Compare yourself today to where you were yesterday
Coach people on what their value is - you can grow into positions

Light Dusting 🚀

2018-09-25T22:36:39.213000Z

This month

Spring cleaning is in full force and I’ve had an interesting mix of trying to get some heads down time at work and getting inspired to dig into issues that resonate with me. I gave a talk about how cool CSS is at the first ever Vancouver Django Girls event and tried to convince some women that software development is fun ✨ I celebrated International Women’s Day at the most inclusive work environment I have ever been a part of (shoutout to Thinkific). I also decided to recommit myself to blogging about my experiences as a web developer in 2018 and at the very least do a monthly newsletter style update.

I'm reading

A reflection on the stages of being a software developer. A flow chart on how to further your dev skills. How to cleanup my docker images. What doors are opened by using HTML5 semantic elements. Why we shouldn’t test private ruby methods and in contrast, if you have no choice but to test the private method, how do you do it? Google’s new javascript style guide. Some interesting results from Stack Overflow’s survey - particularly the gender-based results. A lack of interest in community building by the growing tech bro culture in my hometown. Tending to yourself as gently as you would plants. In celebration of March being Women’s History Month, a reminder for young women everywhere to be large.

📚 Book Alert 📖 But her emails! A heartbreaking account of blatant misogyny and how messed up journalism in the 2016 election was: What Happened by Hillary Clinton.

I’m interested in

Becoming/being a mentor at The Glass Ceiling Demolition Co. Based in Vancouver with the goal to connect young women with experienced mentors in any field.

I’m listening

#metoo: 5 women discuss sexual harassment from the same man.

I’d like to credit this blog format to Ann Friedman, who’s newsletters lovingly find their way into my inbox each week.

🌟