DEV Community: Brenden Niedermeyer (he/him)

Rebuilding My Home on the Web - Update #3: Ship It!

Brenden Niedermeyer (he/him) — Fri, 23 Dec 2022 10:00:00 +0000

This post is part of a series. You can view the other posts here:

Original Post
Update #1
Update #2
Update #3 (You Are Here)
Update #4

Last week I hit the point where I felt pretty happy with where things stood, so I shipped the new version of the site to my primary domain! I let it run for a week and then decided to check it in PageSpeed Insights to gauge how successful I was with the changes.

Previously, this is where the page was sitting. Not super great perf wise.

And now with the new version its doing much better. A small bump in the A11y score to bring that to 100, and an even larger jump on performance. I attribute this mainly to not using the particle background anymore, but nevertheless I'm calling this a win!

There are a couple small tweaks I may make here and there, but for now I'm calling this done and starting prep for the next website - my resume.

Rebuilding My Home on the Web - Update #2

Brenden Niedermeyer (he/him) — Mon, 14 Nov 2022 12:00:00 +0000

This post is part of a series. You can view the other posts here:

Original Post
Update #1
Update #2 (You are here)
Update #3
Update #4

My current landing page, uses react-particles-js to have an animation running in the background.

I held off on re-implementing this until I was satisfied with the rest of the site because I wasn't ahead 100% sure I would keep it.

I ultimately decided to do away with the particles for a few reasons:

It made the page design look very busy. It easily draws the eye away from the content of the page and harms the overall experience, in my opinion.
Keeping it makes the site less accessible. With the particles, I'd have to add extra javascript this time around just to handle users who prefer reduced motion. In other places I can handle this with some straightforward CSS, and while I could probably do that here too it seemed like a lot of work when users would get a better experience by just not implementing it.
Performance. I've noticed in the past that the animations definitely behave differently on different devices. It wasn't horrible, but it was impacting some metrics like LCP on the page. By not including it, I can ensure better performance across a wider range devices.

But now the question was, what should replace the particles? Leaving it as it currently stood was a bit boring.

I decided to add a little depth via a gradient. This was fairly straightforward to do with tailwind. I just updated the styling of the background to be a gradient instead of a single color.

<main className="
      bg-gradient-to-r 
      from-sky-800 via-amber-100 to-primary-light 
      dark:from-primary-dark dark:via-cyan-700 dark:to-cyan-800">
</main>

After adjusting some of the font colors and weights it started to look much better, but was still feeling pretty flat.

I found a few great SVG backgrounds at Hero Patterns and, after adjusting them a bit so they weren't as prominent, added them via CSS to the page. I also decided that instead of just having one, I'll randomly select a pattern on page load and use that. To achieve that I created an array with the names of the patterns and on load, randomly selected the index of one of the patterns.


// done outside of the component since these are static
const backgrounds = ['gears', 'circuit', 'diamonds'];


function randomNumber(min, max) {
    return Math.floor(Math.random() * (max - min) + min);
}

// further down in the actual component

const [bgPattern] = useState(
    backgrounds[randomNumber(0, backgrounds.length)]
);

return (
<section
    className={`${styles[bgPattern]}`}
    id="intro"
>

With the added texture from the background it looks much better, and not as busy as it did the particles.

Rebuilding My Home On The Web

Brenden Niedermeyer (he/him) — Sun, 18 Sep 2022 18:50:46 +0000

I like using projects to learn new things and keep my skills up to date. Everyone has their own pet projects that they keep coming back to. For some it's a version of a todo app they rebuild in whatever tools their interested in at the moment, for others its their blog, or maybe a game. For me, it's my websites. Over the last few years, I've built my resume, blog, homepage, and calling card in a variety of tools. The last few weeks I've gotten that itch again, so decided to start yet another rebuild. At the same time the past few years I've really come to appreciate the idea of learning in public, but haven't taken part as much in the process as I'd like. So, instead of this post being a "Look at this thing I made!" post, this is more of a "Look at this thing I'm making" post. I'll post my plans here and updates as I progress with learnings I've gathered along the way.

The Plan

Over the past couple years, I've slowly started to migrate all of my websites into a monorepo powered by Nx. This project will see the completion of that work, pulling all projects under the same repository with tooling that encourages best practices. Here's the planned architecture :

❗note: these plans could change at anytime. I'll update here if they do.

The three websites will be built in three different front-end frameworks. My blog will be built with Astro (most likely using React within it), mainly because it's the new kid on the block and I'd like to get to know it a bit. The resume will be built with Angular, because even though I don't work with it every day anymore it still has a special place in my heart and I'd like to see the new standalone components in action and revisit Scully. My homepage will be built with Next because it's currently my daily driver at work and I'd like to strengthen my skills there and work more with the recent ISR tooling.

Those projects that have more dynamic content (e.g my blog, and online resume) will be using Storyblok as the CMS. Why? To be honest, I use Storyblok in my day to day work. It's great! I'm comfortable with it, but want the chance to explore some of the newer updates they've released since the 2.0 rollout last month in a lower-risk environment. I'm deploying my Next based site to Vercel for the same reason. The other two pages, are planned to be deployed to Netlify. I'm hoping by the end of this I'll get a nice refreshed comparison between what it's like to work with all these tools. In addition to the above I have the other goals in mind:

standardize my styling to use Tailwind across all projects
have live previews working within Storyblok, especially for blog posts
organize components and shared logic better via the libraries (mentioned in the above diagram)
incorporate A11y testing via end-to-end tests
add a feature to share interesting articles/books I've read on my homepage

At this time I'm not planning any large design change, unless I deem it necessary later on. Simply a rebuild and consolidation while learning a few new tools and I'll be happy.

Current Status

All my work can be found on this branch. I'll probably start opening PRs against it vs blindly pushing changes soon. My main landing page, brenden.dev, is mostly complete and can be found deployed on Vercel here.

I have no set schedule or timeline, but hope to have everything finished in the next few months while I work on it during my free-time. Here's hoping! Updates will be posted here, unless the update is huge, in which case I may split it off as a separate post.

CascadiaJS 2021: Building live experiences with Web Components

Brenden Niedermeyer (he/him) — Wed, 03 Nov 2021 12:58:32 +0000

Today is the first day of CascadiaJS 2021!

To celebrate, this post will be the first in a series talking about how we built out some of live experiences you will see on the web during the hybrid conference.

Goals

This year, we had two areas of our live stage that we wanted to update. Our Q&A experience and mirroring the chat in our Discord server (seen here outlined in red).

Q&A

The first was our Q&A section. This allowed attendees to submit questions for the speakers, and then vote on whichever ones they really wanted answers to. Last year, this was accomplished with a small React app that was dropped into the stage via an iframe. This worked great, but posed some limitations.

Since it was an iframe, it was difficult to interact with other aspects of the stage. We wanted to wipe the questions each time a new talk started and be aware which users submitted and voted for questions so that users could only vote for a specific question once. This was accomplished with query params passed to the iframe, but overall felt a bit hacky and was prone to error.
Because we were just using an iframe, we couldn't give any meaningful control around things like styling to the rest of our colleagues building the stage. This meant that if anything needed to change, we would have to open a pr against another project and release that before being able to test it. Not the worst thing, but the back and forth it caused when it came to development just wasn't as efficient as we would have liked.

Discord View

Last year, we hosted our live chat for the conference on Slack. This year we decided to shake things up and use Discord as our digital chat home for the conference. We still wanted to mirror the chat in the livestream channel, but because it's an entirely different platform, we would need to build out functionality similar to last year's. Additionally, we wanted to handle media and text a bit better. Discord allows you to embed gifs and auto-unrolls img links dropped in a chat. Discord can also handle text formatted in Markdown, so we wanted to reflect that in the mirror transcript as well. Like the Q&A section, we also wanted to supply a great base experience, but allow it to be overridden or extended if needed.

Open Source

CascadiaJS is a big believer in building in public and helping to share what we learn along the way. Any solution we built, we wanted it usable by the greater community. For this reason, we also decided to build the solutions as individual Web Components, so they could be used by any JavaScript project, regardless of framework (or lack thereof).

How we did it

In the end, we published our Web Components in two separate packages: @cascadiajs/discord-mirror and @cascadiajs/q-and-a. Later posts will go more in depth on how we solved specific problems, but here are the tools we ended up using.

Abbot

For integrating with Discord and syncing messages we used Abbot. Abbot helps you to build chatbots that work in Discord, Slack, or MS Teams. They take a lot of the pain out of building and configuring your integration with various chat platforms and let you interact with the different chat platforms in a nice, standardized way. They just launched a new feature, Patterns, that let you subscribe to messages within a specific channel that match a pattern. This worked great for our use case as it allowed us to subscribe to the #livestream channel people were chatting in while the talks happened. Read more about how Patterns work here.

Stencil

Both of the Web Components themselves were built with Stencil. Stencil is great because it lets you work with many tools/concepts you may already be familiar with using in other apps, like JSX, Typescript, and React-style data-binding, while giving you powerful tooling around things like, project and component generations, state management, and working with the Shadow DOM. Since our components were using the Shadow DOM, we were able to provide a base set of styles, but allow users to override them via Shadow DOM Parts. (More on this in a future post).

Firebase

Abbot helped us to get messages out of Discord, Stencil helped us to visualize those messages and allow users to ask questions to the speaker, but how do we go about connect them together? That's where Firebase comes in. With Firebase, we were able to write simple functions to accept the data we needed and load it into a Realtime Database. The best benefit to this was, thanks to the Firebase SDK, we could subscribe to any changes that would happen in the database within our components and have them reflected in the UI without needing to do repetitive polling.

What next?

Like I said earlier, this is the first post in a series I'll be publishing over the next weeks talking about different problems we faced and other learnings to take away from building these components. Some topics will include handling mixed media within messages, allowing customization of the components, providing user choice between different backend solutions, and others. If there's anything specific you want me to cover, reach out and let me know! Meanwhile, if you'd like to see the code for our Web Components, they can be found here:

Until then, ENJOY THE CONFERENCE! This really has been a labor of love for the organizer team, and we can't wait to see you all in person and online. If you see me hanging around in Discord or Gather, say hi!

Why I got involved with CascadiaJS

Brenden Niedermeyer (he/him) — Fri, 24 Jul 2020 12:40:32 +0000

CascadiaJS is one of my favorite conferences. Having grown up in the Pacific Northwest the conference, which focuses on the community and talent here, has a special place in my heart. Every year I leave the event feeling renewed and excited about the work we do as developers, as well as looking forward to all the great things my fellow attendees will achieve. I’ll be attending again this year remotely on September 1-2, and you should too! Here’s why:

The talks are amazing

I’ve been attending since 2018 and the one thing that I always look forward to are the talks. These aren’t your usual tech conference talks. In the past I’ve enjoyed talks covering a wide range of topics ranging from how to use machine learning to prevent people from hacking a Porg to scream when your build breaks to building VR experiences on the web, to addressing ableism in the developer community.

This year will be no different. There will be talks about integrating AI with robotics, building mental health support into our communities, how constraints can actually help stimulate creativity in web development, and deep dives into the impact of memory leaks (just to name a few). The talks I see at CascadiaJS blow me away every year and I expect this year to be just the same.

The community is top-notch

I think the picture of the CascadiaJS mission above says it all. Community is the heart of the conference. I always come away from my time at CascadiaJS feeling warm and fuzzy. Everyone in the CJS community is friendly, welcoming and love to support each other in getting better. No matter your experience level you’ll find people who want to chat with you about a huge range of topics and make you and the developer community in the Pacific Northwest better. The CascadiaJS Slack has channels where folks can get #virtual-coffee, ask for advice in #mentorship, or just keep each other company while working from home. That magic won’t go away just because the event will be online; the team is even working on ways to recreate the in-person hallway track that we all know and love.

A great example of the strength of the CascadiaJS community is the Opportunity Scholarship program they run. The team wants to ensure that anyone who wants to attend the conference has the ability and offer heavily discounted and free tickets to anyone who is a member of an under-represented minority in tech.

Learn more about the scholarship program and how to apply here!Want to help support the scholarship program? Donate here!

Fun conference events events and swag

Past events have ranged from having parties at the Living Computers Museum, renting out entire movie theaters for a special premier, karaoke get togethers and events focusing on mentorship.

This year will obviously be a bit different because of the remote aspect driven by the global situation with COVID-19, but word has it the team has some great surprises in store.You don't even have to wait until September to join in! There are events planned prior to the conference kick off (including a job fair the day before the conference).

Did I mention that you still get incredible swag just for buying a ticket? Just because we can't hang out in person doesn't mean we should miss out on all the cool conference stuff! This year all attendees who register before the 24th (that's today!) will get a coveted CascadiaJS hoodie, a bunch of stickers, and other really cool secret surprises in time for the conference. You really don't want to miss out on it, trust me.

// Detect dark theme var iframe = document.getElementById('tweet-1285595605625118722-439'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1285595605625118722&theme=dark" }

Want to join the fun?

Like I said, I’m counting down the days until CascadiaJS kicks off on September 1st. Want to grab a ticket so you’re not left out? Grab one here (don’t forget to register before the 24th so you get your swag). See you there!

Where We Publish Technical Writing

Brenden Niedermeyer (he/him) — Sun, 19 May 2019 12:40:32 +0000

This year at ng-conf, I took part in the Technical Writers Summit. I gave a brief talk where I wanted to talk about different places and strategies for publishing the technical blog posts that all of us attending the event write. As I prepared my talk and thought more on the topic I realized while I could talk about what I do, it might not be totally representative of what others do. So I threw together a small survey a week or so before the event and gathered as much input on the topic of where we publish, why we choose those places, and other related questions as possible. Here are some takeaways I found after digging into the data:

Most post to only one platform

This first one surprised me a little. With all of the options for people to publish their writing on, I assumed most would spread out across them much like many people do with social media. I suspect this may be due to difficulties cross-publishing to different places (more on this later).

Medium is still a powerhouse

Of all the different places that people post to, Medium grabbed the majority of those who only posted in a single place, followed by self-hosted blogs. That’s the same amount of people who say they only post to Medium as everyone who says they post to some combination of platforms combined. Medium was also the most used overall out of all the choices.

This also makes sense given the common thread in responses of wanting to post where the readers are. If we want people to read what we write to some degree we need to go to them. Right now, a large number of them are on Medium.

Pain points

I was also interested in the difficulties that some writers encountered when publishing their work. Code blocks/formatting/highlighting within the blog posts on different platforms was one of the points that were often mentioned. That’s understandable given that on some platforms it’s quite easy to feature blocks of code with the proper highlighting while on others, Medium, for example, you often have to choose between having easily embeddable code blocks without highlighting or managing one or more separate gists to embed code samples the way you would like.

Another common issue was how difficult it can be for cross-posting between the different platforms. Importing your content for a post is sometimes cumbersome and, in some cases, can drive traffic away from your intended target if not done properly due to the SEO weight of something like DEV.to or Medium vs your own personal blog.

Quick pro-tip: Both DEV.to and Medium allow you to set the canonical url for posts. If you’re new to cross-posting this is a good place to start.

Most write because they enjoy it

Just over 21% of those who responded have been paid for their writing while around 79% say that they write technical posts because it helps their understanding of the concept or because they just enjoy it. That’s fantastic (on both accounts)! I think that’s what makes the technical blogging community great - t’s full of people who want to share their knowledge with others while they develop their own skills.

Conclusion

This was an interesting exercise. Given the relatively small sample size that responded there are some interesting tidbits of information found in the responses. However, this is just a glimpse into the larger technical blogging community. I think I want to try this again in a year, see if we can grow the number of responses, and get an even better picture of the technical blogging community.

As promised at my talk, I’ve released the response data for others. You can find the link below. Take a look and see if there are any other takeaways that you can find!

https://docs.google.com/spreadsheets/d/12PKxiThkpbgm4L3CdqfBesm4aJ0P_7XoSCsafS_z6Uw/edit?usp=sharing

Getting Started Building Component Libraries with Angular CLI

Brenden Niedermeyer (he/him) — Sun, 03 Jun 2018 19:50:50 +0000

Photo by Samuel Zeller on Unsplash

One of the things that’s always had a higher barrier of entry in the Angular ecosystem is creating libraries of components that other Angular apps can use. The Angular team published guidance with things like the Angular Package Format and from that the community has created some fantastic tools, like generator-angular2-library, that make it easier. However, there was never a tool that generated opinionated implementations of the Angular Package Format the same way that developers who used the Angular CLI in their normal project workflows were used to.

With the recent release of version 6 for the Angular CLI, we now have access to tools that can help us build libraries while still taking advantage of other powerful aspects of the CLI, such as schematics, without leaving the workflows we are used to! I will show you how to the CLI to get started building your own component libraries.

We’ll cover:

Generating a library project with the Angular CLI
Building components for your library
Using your library in other applications
Publishing your library for others to use

Generating a library project with the Angular CLI

First thing’s first. We need to setup our project. If you don’t have the latest version of the CLI grab it from npm.

Now create a new project with the CLI. Nothing new here.

If you’re used to working with the Angular CLI you might notice a couple changes to the project structure you know and love. The most noticable of which is that the old angular-cli.json is gone and now replaced with a new angular.json file.

This file is the key to one of the biggest new features in version 6. Now the Angular CLI can create and work with workspaces that contain one or more multiple Angular projects. This angular.json file gives you control over the configuration of each of those projects. This is ultimately what makes building of libraries within the CLI possible because we need handle the building of libraries differently than we normally would for normal Angular apps.

Ok — so now we know a bit more about how libraries within CLI pojects work; let’s generate the library structure in our project. We do this with the generate command just like we would to create a component, service, module, etc...

This creates a new /projects directory with a new folder for your library and some example files.

The files to really take note of here are /src/public_api.ts, ng-package.json, and ng-package.prod.json. These files control the configuration for ng-packagr - the library that powers the packaging of your library. I encourage you to check out the project and familiarize yourself with how it works, but here is a quick and dirty overview:

public_api.ts is the new entry point for your library. If you have any files that you want accessable to consumers of your library (modules, components, etc...) you need to export them here in addition to exporting them from whatever modules are in your library.

ng-package.json and ng-package.prod.json control the configuration for the packaging process that ng-packagr performs. You can use them to change things like the destination build directory or defining a different entry point for your app. ng-package.json is used during your ng build command and ng-package.prod.json is used when you run ng build --prod. The only difference between these two files right now is that ng-package.json contains a deleteDestPath flag that will delete your destination directory before running a build. This will be helpful during development when you are constantly making changes.

Protip : if your library needs to do something like bundle an overall Sass file, you will need to include something like scss-bundle in your workflow. See here for more information

Building components for your library

Now we have the general structure for our library setup. It’s time to start building!

First add Angular Material to our project.

“Wait, why are we adding Material to my-app and not my-new-lib?” Good question. The easy answer to that question is that in this case Material is a peer dependency of our library. We don’t want it to be downloaded each time our library is installed somewhere — that can lead to things like huge final bundles when the application is built. Instead we want to mandate that whichever project is using our library needs to also have Material installed as well. For libraries that will be installed and consumed by third parties (hint, hint: ours) you’ll need to add things like Material to the peer depencies. There’s a good discussion about when to use peer vs. normal depencies here.

Additionaly, the ng add command for Material only works for standard project configuration, i.e. those generated by the ng new command. If you were to run ng add @angular/material --project my-new-lib you would get an error saying so. The schematic that is being run in the background to add Material assumes you are adding it to an existing Angular app and not a library so it won't understand since the structure inside angular.json that is setup for your library.

Go ahead and add to our peer dependencies now.

Let’s setup the module for our library. First, delete the example files that were generated by the CLI in src/lib and from public_api.ts. Then generate the module.

Since we will want others to consume this module we need to add it to public_api.ts.

For this example the library will have a component that consists of a button and a badge. Each time the button is clicked the badge will update and show the total number of clicks. For added complexity the component should also emit an event to let any parent component know that the count has changed and what the current count is.

First generate the component.

Export the component that was just created from our library. Also import the MatBadgeModule and MatButtonModule while you are here.

Also add the component to public_api.ts

Now add logic to the component to handle incrementing the count displayed whenever the button is clicked.

Next we’ll wire up the component to the template.

Now we have a component that we want other apps to use! But how do we make sure it works? We’ll handle that next.

Using your library in other applications

Alright, we have an awesome library ready for use — but how do we actually use it? There’s a couple of different ways.

The first is to use it within the application that was generated by the CLI when we first started our work. Remember, the Angular CLI doesn’t just generate a single app anymore; instead it generates what the CLI team refers to as a workspace. This means you can build multiple apps and libraries in the same directory and utilize what you built within other projects in the same workspace.

Open up tsconfig.json in the root of your workspace. You'll see a paths option that points to a dist/my-new-library directory.

What this does is allow you to automatically use your library, after it’s been built, in other apps in the same workspace. This works similarly to using libraries installed by npm in that you can just import your components and use in your library. This of course means that you must build any libraries that your app depends on before you build your app, and will need to rebuild it every time you make a change to the library before those changes will be reflected.

A sample workflow could work like this:

Now go ahead and build our library, then we will build an example of how to use it using the original app generated in our workspace.

This generates the dist/ directory mentioned eariler. If you open that directory and take a look you'll see that ng-packagr has generated FESM2015, FESM5, and UMD bundles of the library for consumption and generated a types file.

Now we are ready to use the library in our app!

Import the MyLibModule in src/app/app.module.ts

We want to demonstrate that the app is receiving the countChanged events from the library component so implement handleCountChanged() in src/app/app.component.ts.

Now add the CounterButtonComponent to src/app/app.component.html. Also add a div that shows the values being emitted from the component.

Let’s see our example app in action! Remember to build your library before serving the app.

Open the browser and you’ll see your component in action!

Using libraries like this is a great way for you to share code between multiple Angular apps in the same workspace. Additionally, if you are building something like a component library you could use the originally generated Angular app to build great working examples for your library.

Publishing your library for others to use

So, you’ve built an awesome component library and are using it in your own applications, but what if you want to share it so others can use it in their apps?

First, if you haven’t published anything on npm before go ahead and sign up.

After you sign into your npm account, build the library again. This time use the --prod flag so that the Angular CLI will perform some additional steps for optimization.

Now move into dist/my-new-library. If you want to test that your package will work in other apps you can link it to your local npm registry.

Now create a new Angular workspace and link your library to the project.

In the new workspace add preserveSymLinks to angular.json in the options object under projects/test-lib-app/architect/build. This allows the linking of your library to continue working when the app is served.

Use the library in the same way we did eariler and you see that it will work here as well! To remove the linked library you can use an npm remove my-new-library command in the test project and the npm unlink command in the directory of your built library.

If you are ready to publish your app to npm for others go ahead and run the below command inside of your dist/my-new-library directory.

From there you can use it as you would any other packages using npm install.

Next Steps

Congratulations! You have built your component library with Angular and have published it to npm for others to use. Go forth and build cool libraries to share! For next steps I also highly encourage you to dive into the documentation for ng-packagr to learn about more advanced topics regarding the library packaging process.

You can find the code used in the examples in Github here.