DEV Community: Stacie Taylor

The Collab Lab turns 4 soon! And with time comes change.

Stacie Taylor — Tue, 13 Jun 2023 03:22:42 +0000

As of August, it will have been 4 years since we kicked off the first-ever project at The Collab Lab. We just wrapped up our 61st team! As of today, we’ve helped over 230 early-career developers—from incredibly diverse backgrounds—learn how professional software teams collaborate, teaching practical skills including pair programming, giving/receiving code reviews, and how to demo work to stakeholders, all of the stuff that’s all but impossible to simulate when you’re studying on your own.

What’s changing

For the last 3 years or so, we’ve been following a cadence of one cohort per quarter where we run between 4 and 7 teams of 4 developers each. That worked well as long as we were content to execute the current program. What it didn’t allow us much time for was program and curriculum development.

Not for nothing, that model was a big improvement over the early days when we’d kick off the next team when the current one was halfway through. 🤪🫠

The existing structure served us well, as long as we didn’t want to make too many improvements to the program…

“We’ve been wanting to make some meaningful changes to the structure of the program to better serve our community and given that we’re volunteer run, we need the extra time between cohorts to make these changes.” —Me to the Collab Lab board members in Q2 2023 😅

Our program as it’s currently structured is 8 weeks long. About a year ago, we added an optional 2-week career development program to the end of each project term. That gave us just 2 weeks before the next round of applications would open up and we’d be back on the hamster wheel of providing direct service to the next group.

So, with the enthusiastic consent of our Board of Advisors (Chiamaka Umeh, David Baker, EJ Mason, Yolanda Haynes, Mindy Zwanziger, & Shelley McHardy), we have decided to move from offering 4 cohorts per year to 2.

Sometimes, less truly is more.

By giving ourselves some breathing space between cohorts, we expect to create the capacity to make substantive changes to the program that will allow us to scale horizontally in a way that’s tough to pull off today. We fully expect that by the end of next year we will be able to serve even more early-career developers than we do today and at a higher level of quality.

What’s staying the same

What will never change as long as The Collab Lab exists is our commitment to helping early-career developers from diverse backgrounds make the jump into tech. In the current jobs environment, this is as tall a task as it’s ever been and we are more committed than ever to doing everything we can to ease that transition for as many people as possible.

Git: Are you an over-committer? Squash those commits!

Stacie Taylor — Sat, 17 Apr 2021 22:28:09 +0000

Photo by Christin Hume on Unsplash

Are you an over-committer? Me too. Basically, anytime I complete some kind of task, I commit it with a message that details what I’ve done. I do this for a few reasons:

I’ve read over and over again: “Commit a lot, commit often”
I have kids and work at home. As I’m working, my kids could need me immediately at any second, and I want to make sure my work is saved.
Those crazy kids also sometimes get access to the computer and get happy fingers while my projects are open, so I want to make sure I’ve got it all backed up.
I often find myself working in short stints and having lots of commit messages helps me retrace my steps and offers me a sort of progress report.

I was recently told by someone who was reviewing my code that I commit too frequently. He suggested, “If you feel that it is helpful for you [to make incremental commits], I would recommend you check out squashing commits with Git.”

After researching what squashing commits even meant, I realized it was the perfect way for me to have my cake and eat it too! It allows you to make as many smaller commits locally as you feel necessary, based on your own preference and workflow, and then squash them down into one clean commit so that your remote repo’s commit history is nice and tidy!

Below, I’ve laid out a step-by-step guide on how to squash commits that can be followed by any Code Newbie!

Steps to squash your commits:

WARNING! Before you start, keep in mind that you should squash your commits BEFORE you ever push your changes to a remote repository. If you rewrite your history once others have made changes to it, you’re asking for trouble… or conflicts. Potentially lots of them!

Create and checkout a new branch where you will write your code: git checkout -b [your_branch_here]
As you work on your project, make as many commits as you’d like!
Find out how many commits you want to squash! You will need the number of commits so that you can tell Git how far to go back during your rebase. The command below will get you the log of commits not including any that are available to master and you can count how many you’d like to squash: git log [your_branch_here] — not master
Run an interactive rebase. In the sample below, replace X with the number of commits you want to squash. This will rebase you X commits back: git rebase -i HEAD~X
The text editor will pop up and list your commits. Shift + i to type. Replace pick with squash on the most recent commits. Make sure the first commit is still preceded with the pick command. This basically tells Git to squash all of your most recent commits into your first commit.

pick first_commit
squash second_commit
squash third_commit
squash fourth_commit

# Your text editor will give you a bunch of other instructions and options here. Check them out. There is some really helpful information.

esc to escape insert mode.
:wq to save your changes. (VIM)
Another text editor screen will pop up and allow you to write a new commit message that will sum up all of your previous commit messages. Comment out all of the previous commit messages and write your new one.

# This is a combination of X commits.
# The first commit’s message is:
# First commit message

# This is the 2nd commit message:
# Second commit message

# This is the 3rd commit message:
# Third commit message

# This is the 4th commit message:
# Fourth commit message

New commit message here

# Git will list some other instructions and the changes you’re committing here.

:wq to save and quit. (VIM)
You can double check that it worked by running git log again. You should see only your new single commit!

There are multiple variations of this process and countless workflows and commit preferences among us. I am really interested in how you commit and how you squash (if you do). Please share your experiences so that we can all become more productive and efficient developers and team players!

How to resolve merge conflicts with git

Stacie Taylor — Thu, 01 Oct 2020 00:26:48 +0000

Dealing with messy merge conflicts can be a bit like navigating heavy traffic. With a bit of patience, forward-thinking, and sometimes a pal, you can resolve any conflict you're faced with. Take a deep breath and follow the steps below to get those resolutions in place!

Step 1

Pull down all the latest code from the main branch of your remote repo.

git fetch

Step 2

Merge all that fresh new code into your feature branch locally.

git rebase origin/main

Step 3

[Optional] Run this to get a high-level look at which files have conflicts.

git status

Step 4

Fix all the merge conflicts in your project.

Go to those files in your editor. You will see that it shows you the code that lives on the HEAD and your branch's code.
Keep the good code that you need when it asks you to choose and delete the code you don't want. This can be the most challenging part because you might be seeing code from your team that you don't recognize -- pair with your pals to decide what code goes and what code stays if necessary.
When you see that the files that previously had conflicts are squared away, save them!

Step 5

Stage all the files that you fixed.

git add .

Step 6

Continue the rebase to see what's next.

git rebase --continue

Step 7

You may still have more conflicts to work through because the rebase is going to compare every commit that came down from the main branch to your feature branch. Keep the following steps 3-6 until you're taken back to your feature branch.

Step 8

Push your updated code up to your remote repository.

git push --force-with-lease

Note: --force-with-lease is a safer option than force because it will not overwrite any work on the remote branch if more commits were added to the remote branch. Read more here.

Team 9 Recap

Stacie Taylor — Tue, 29 Sep 2020 04:19:03 +0000

Every time a Collab Lab cohort wraps up, I swear it flew by faster than the one that came before it. The August 2020 cohort was no exception -- it went so quickly and I can’t believe we’ve tossed our tassels with another amazing group of developers! 🎓

In the early days of The Collab Lab we only ran one team at a time. We’ve grown up quite a bit since then and we’re not stopping anytime soon. Our August 2020 cohort included 3 teams and I was lucky enough to mentor Team 9 alongside Yves Gurcan, a first-time Collab Lab mentor and the head of our Tech Talk initiative, and Scott Bergler, a former Collabie who couldn’t get enough so he decided to hang around and offer his experience to help other developers grow!

Our participants included:

Leigh-Ann Crivella, whose organizational skills and forward thinking led the team to so much success and, without a doubt, played a role in her landing her first developer role! Congrats, Leigh-Ann. We’re so proud of you.
Lia Chen, who always demonstrates such curiosity when approaching code and tackles building new features and squashing bugs with great calculation. Nothing is gonna get by her!
Mabel Hernandez, who is incredibly thoughtful when it comes to solving problems and is always digging deep to understand her code. She is always ready to fill you in on the technical details during Q&A after demos!
Fabrice Innocent, who came to the team with such ambition and blew us away with his dedication and tenacity. Fabrice totally crushed learning a new programming language and contributed some wonderfully fresh perspective to the team.

This team’s collaboration skills were so impressive. They kicked off the program and immediately started building a solid team that worked together to organize the work that needed to be done, squash tricky bugs, and build a really fantastic app.

If you’re in search of some really incredible developers who have experience collaborating with great success in a remote and agile environment, these are your people. ✅ ✨ 👏

Cropping & Zooming in on SVGs with viewBox

Stacie Taylor — Fri, 14 Aug 2020 17:01:18 +0000

When you build an SVG, you build your own little world. And what's the point of creating something beautiful if you're not gonna take pictures of it and show people (note: I recognize I'm letting my inner millennial show here).

Within your <svg> tags, you can build your little world! It can be bursting with life and color and all the most beautiful things. But then, you have to decide what you want to show your friends by taking the pictures.

Think of the SVG's viewBox attribute as your camera lens. Which pieces of your world do you want to capture on your camera for people to see?

Take this image for example. This whole bakery might be what is inside the <svg> tag. But you don't really need to show people the entire bakery at this time, you just wanna zoom in on these tasty little donuts — the real star of the show!

So, when you think of an SVG, you should think that the actual SVG itself could potentially have an infinite canvas, but what us humans can actually see is what is within the viewBox that the developer has defined!

Your viewBox is what is in charge of zooming and panning your "camera lens" so we only show what we want to show.

The value of the viewBox attribute is a list of four numbers: min-x, min-y, width and height.

min-x and min-y are the top left corner of the viewBox and define it's position.

min-x: This will move your camera lens right and left — much like "trucking" in filmography.

min-y: This will move your camera lens up and down — much like "pedestal" in filmography.

width and height are set to the number on "units" that are visible inside of your viewBox. Changing these values will zoom in on our world!

width and height work off of each other, so you may need to work with both values depending on what you want to achieve.

There you have it! Now, with the power of viewBox attribute, you have to power to crop and zoom your SVG to show exactly what you want people to see. You might have also learned some new photography vocab as well that you can apply to your next Instagram story.

There is a great video on the viewBox attribute over here by DesignCourse.

And you can use a brilliant tool they've created to play around with the viewBox attribute on your own SVGs over here

Getting Started with SVGs

Stacie Taylor — Wed, 12 Aug 2020 23:24:12 +0000

Using Scalable Vector Graphics (SVG's) when building your web apps has some major benefits when compared to other graphic types!

Incredibly responsive:

If you've ever spent time battling with making a pretty little graphic look perfect on all screen sizes, I feel you. SVGs are incredibly responsive because they are resolution-independent, meaning, unlike other file types (JPG, PNG, etc), SVG's can scale to any dimension without losing quality. Browsers just recalculate the math behind the image so that it won't get blurry.

Raster images, on the other hand, can get blurry when we make them bigger because their small pixels are forced to stretch beyond their original size.

Super performant:

When we use PNGs and JPGs, we're usually dealing with some really hefty file sizes. SVG's, on the other hand, are just code, so if optimized properly, they can have very small file sizes making your web app lightning fast!

You can even take that speed a step further by swapping out your graphic for an inline SVG, reducing the number of HTTP requests being made.

Beautifully animated:

Because SVG's can move smoothly and freely, all while maintaining their perfect quality, we're able to make them dance around the page in ways that can help really tell a story and engage our users like never before!

Over the next 9 weeks, my pals and I are diving into learning more about SVG animation, but let's start with the basics of how to even create an SVG!

Creating an SVG

If you're going to build a really complex SVG, it's a good idea to use a drawing app that will allow you to export the SVG. But, really, it's all just code, so let's take a look at a really basic example!

1) Start with your root SVG element:

<svg></svg>

2) Then we need to give the SVG viewport it's height and width

<svg width="450px" height="100px">
</svg>

At this point, the SVG's canvas dimensions are the exact same as the viewport dimensions we defined.

3) Once we've got our SVG viewport created, we can start making it look pretty. Let's add a shape!

There are a number of predefined shape elements, but let's just test out a rectangle for now.

Start by using the rect (rectangle) element.
Then we need to tell it where on the SVG canvas it should start so we give it x and y coordinates.
Give it some shape by defining the width and height.
And finally add some style!

<svg width="450px" height="100px" viewBox="0 0 450 100">
  <rect x="10" y="5" width="90" height="90" fill="pink" stroke="orange" />
</svg>

At this point, you should have an SVG canvas (450px x 100px) with a square inside it (90 x 90) like this:

Excellent! We've got a nice little square, but there is so much more we can do here.

Up next we will take a look at how to scale SVG's with the viewBox attribute. Stay tuned!

Cohort 8 Recap

Stacie Taylor — Tue, 04 Aug 2020 03:10:29 +0000

Watching folx come to Collab Lab and grow their collaboration skills is, without a doubt, one of my favorite parts of life. We’ve just wrapped Cohort 8 and I am incredibly grateful to have gotten the chance to work on such a fun, ambitious team of developers!

The team:

The mentors:

Each member of this team is incredibly gracious and humble. Throughout their eight weeks together, they were always sharing credit for a job well done and lifting each other up! When it came to code reviews they were great about accepting and incorporating feedback and even proactively asking for it.

Shajia, Lily, Ali, and Luka are all strong technically, but completely understood the importance of learning good team practices. They consistently inspired me with their organized and thoughtful weekly demos and their teamwork was absolutely inspiring.

I enjoyed spending time getting to know each member of Team #8 and cannot wait to see what the future holds for them!

How to enable Preview Mode on an app powered by Next.js & Contentful

Stacie Taylor — Fri, 22 May 2020 04:00:29 +0000

What?

Fire up those IDEs: This article will walk you through how to enable Preview Mode on a Next.js powered website or app that's content is managed with Contentful.

Why?

You're probably here because you built your company a really dope Next.js powered app that manages it's content with Contentful.

Great work! But, now those folks who create your engaging, captivating, money-making content want a way to preview what their drafted work would look like when it's live before they publish it for all the world to see.

Great news! You're in luck because you chose to build with two tools that both want you to preview your work -- good lookin' out, friends. 🎉

How?

Of course, the configuration will vary based on all the intricacies of how you built your unique app, but this oughta give you a high-level of how Next.js & Contentful's preview features work together. So, let's take a look at a basic example on a blog site!

At a high-level, this is how Preview Mode is functioning on this example blog:

All of the blog’s pages are statically generated and we’re querying Contentful's Content Delivery API for the blog data at build time.
In Contentful, you can create a new unpublished blog post or make unpublished edits to an existing blog post.

If you want to preview the changes, click on the "Open Preview" button.

This will open a new tab in the browser, hit this blog's api/preview route (that we will build below) that will trigger two Next.js preview mode cookies to be added to the browser, then will redirect the user back to the URL of the blog post they intend to preview.
Any requests to Next.js containing these cookies will be seen as preview mode, and the pages that used to be statically generated (SSG) will now be served with server-side rendering (SSR). We are then able to query Contentful's Content Preview API rather than the Content Delivery API, which will pick up all those unpublished changes.
When the user is done previewing, you can build a handy dandy button in something like a Preview Mode banner so they can click to exit Preview Mode (which really just sends them through the blog's api/preview-disable route, removing those two Next.js Preview Mode cookies) and redirect them back to the blog's non-Preview Mode page.

Let's dig into the details!

Wanna know more about how exactly this was implemented? Read on...

Set up Preview URL in Contentful

Contentful's Preview URL Documentation
Inside Contentful > Settings > Content preview, set a preview URL on the content type that you want to preview.
That preview URL needs to pass through the preview API in your Next.js app (/blog in my case here) so that when that URL is visited, it will trigger preview cookies to be set that will tell Next.js to enable preview mode.
We then pass it the path to the content we want to preview (blog/{slug} for example).

Add the Preview Access Token to your code

The content preview access token for your Contentful Space will return every single thing that the content delivery access token will + DRAFTED CONTENT

Inside the app's next.config.js, we need to build the URL that will fetch data using the content preview access token like this:

module.exports = {
  env: {
    contentfulGraphQLUrl: `https://graphql.contentful.com/content/v1/spaces/${spaceId}?access_token=${accessToken}`,
    contentfulPreviewGraphQLUrl: `https://graphql.contentful.com/content/v1/spaces/${spaceId}?access_token=${previewAccessToken}`,
  },
};

Set up Preview Mode in Next.js

Next.js Preview Mode documentation
Create API route that will turn preview mode on
- In the aforementioned documentation, it will show you how to create your preview API route. Inside this api/preview file, you will call setPreviewData on the response object.
- This will set two preview cookies in the browser that will essentially "turn preview mode on". Any requests to Next.js containing these cookies will be seen as preview mode, and the pages that used to be statically generated (SSG) will now be served with server-side rendering (SSR)
- You can then route the user to the actual blog post they wanted once the setPreviewData has added those cookies and query Contentful's Content Preview API (rather than the Content Delivery API) and we will then be fetched the unpublished (draft) content so that we can preview it!

// api/preview.tsx

import { NextApiRequest, NextApiResponse } from 'next';

/**
 * Perform a server side redirect
 * https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering
 * https://nodejs.org/api/http.html#http_class_http_serverresponse
 */
function serverSideRedirect(
  res: ServerResponse,
  destinationPath: string,
  statusCode = 301,
) {
  res.writeHead(statusCode, { Location: destinationPath });
}

export default (req: NextApiRequest, res: NextApiResponse) => {
  // Calling setPreviewData sets a preview cookies that turn on the preview mode.
  // Any requests to Next.js containing these cookies will be seen as preview mode,
  // and the behavior for statically generated pages will change.
  res.setPreviewData({
    maxAge: 60 * 60, // The preview mode cookies expire in 1 hour
  });
  const { slug } = req.query;
  serverSideRedirect(res, paths.blogArticle(slug as string), 307);
  res.end();
};

Create API route that will disable preview mode
- Just like you created the preview route, you'll create a preview-disable route.
- Additionally: In the api/preview file, when setPreviewData is called, you can set a maxAge so that the preview mode will expire after one hour as a means of disabling the preview mode. See code above.
- I might also suggest building a Preview Mode banner to allow your content folks the ability to manually disable preview mode. When they click this button, they should be sent through the api/preview-disable route which removes the two Next.js Preview Mode cookies and redirects them back to the blog post's URL so that they will land on the published version of the post -- or hopefully a 404 if the content has never been published.


// api/preview-disable.tsx

import { NextApiRequest, NextApiResponse } from 'next';

/**
 * Perform a server side redirect
 * https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering
 * https://nodejs.org/api/http.html#http_class_http_serverresponse
 */
function serverSideRedirect(
  res: ServerResponse,
  destinationPath: string,
  statusCode = 301,
) {
  res.writeHead(statusCode, { Location: destinationPath });
}

export default (req: NextApiRequest, res: NextApiResponse) => {
  // Clears the preview mode cookies.
  // This function accepts no arguments.
  res.clearPreviewData();
  serverSideRedirect(res, req.headers.referer || '/', 307);
  res.end();
};

Dynamically choose the appropriate access token

When you request a page from a Next.js app that has getStaticProps with the preview mode cookies set (via res.setPreviewData), then getStaticProps will be called at request time (instead of at build time). WOWZA! Nifty hybrid, Next.js. High-five!
Furthermore, it will be called with a context object where context.preview will be true.
You can then pass that preview boolean over to where your client is being created to specify which client to use. I'm using urql (a blazingly fast, lightweight, and customizable GraphQL client) to make a client AND a previewClient and the value of that preview boolean will determine which client is used when we query Contentful.

export const previewClient = createClient({
  url: process.env.contentfulPreviewGraphQLUrl,
});

export const client = createClient({
  url: process.env.contentfulGraphQLUrl,
});

export const getClient = (preview: boolean) =>
  preview ? previewClient : client;

Query Contentful for preview data

Now wherever in your code you're querying Contentful for that specific content, you'll need to pull that preview boolean from the context object and pass it along to the query so that Contentful knows whether or not to send drafted content along with the data.

const blogArticleQuery = gql`
  query articleQuery($slug: String!, $preview: Boolean!) {
    article: blogArticleCollection(where: { slug: $slug }, preview: $preview) {
      ...
    }
  }
`;

This will mean that if preview mode is off and preview is false, the app will use the content delivery access token and URL. But if the preview is true, it should use the content preview access token and URL and will send true along with the query to serve that preview/draft data!

The end!

There you have it. That's how you give your content team the ability to preview their content! ✨

I realize this is a very heavy topic for such a short blog post, but I assure you Next.js & Contentful have incredible documentation on these processes. This article is intended to be a friendly little bridge between the two. When you start digging in, with the knowledge you have of your own app, I think you'll find it pretty exciting and fun to build!

And of course, your Twitter dev community loves to share knowledge. Hit me up with questions and I'll see how I can help ya. ♥️ @the_real_stacie

Disclaimer: don't try copy/paste with all this. It's totally picked apart to just hand over the basics. You'll want to understand what's happening in your code AND these codes snippets above well enough to know how it can fit into your masterpiece.