DEV Community: Rach Smith

Lerp

Rach Smith — Thu, 06 Apr 2023 20:12:00 +0000

When CodePen blogs were a thing I added a bunch of posts to mine. Some of the content still holds up in 2023 so I decided to repost my favourites on this site.

Today I want to talk about a little animation trick that I use all the time called lerp. Lerp is the nickname for Linear Interpolation between two points. It's a fairly simple effect to implement but can really improve the look of your animations if you're moving an object from a point A to point B.

How does it work?

Given you have a current position for an object, and a position you want to move that object towards - you can linearly interpolate to a percentage of the distance between those points, and update the position by that amount on each frame.

// to run on each frame
function lerp(position, targetPosition) {
// update position by 20% of the distance between position and target position
  position.x += (targetPosition.x - position.x)*0.2;
  position.y += (targetPosition.y - position.y)*0.2;
}

By doing this, the amount the object moves becomes smaller as the distance between position and target decreases. This means the object will slow down as it gets closer to its target, creating a nice easing effect.

Lerp in action - some examples

Here is an example of a ball following the user's mouse or touch. If we make the ball move to the place the mouse is as soon as it moves, the ball movement can be very fast and/or disjointed. We might also be able to see separate "ball frames" if we move our mouse really fast.

Here's the same demo, except this time we're using lerp. Instead of moving the ball right to the mouse position, we'll move it 10% of the distance towards that position on each frame.

Notice the ball movement is a lot smoother and an overall more pleasing effect.

Here's another example of using lerp. This time we've got a scrolling indicator that updates as you scroll down the "page".

If we add lerp to this example we're lerping the indicator towards the scroll percentage instead of pointing it at the actual position - this smoothes out the movement of the indicator.

So, the lerp "trick" is a great tool to have up our web animation sleeves to combat linear or jagged movement.

Content Collections are a welcome addition to my Astro setup

Rach Smith — Wed, 29 Mar 2023 13:15:00 +0000

All of the notes on this site are built from markdown files in an Astro static site. As of Astro 2.0, you can effectively add type validation to your markdown files, via a feature called Content Collections.

I must confess I don't enjoy TypeScript all that much. I can see how and why it is helpful in certain circumstances, but I'm not in the "make everything TypeScript because TyPeScRiPt iS tHe fUtUre" demographic.

It makes sense for this usecase of improving the experience of debugging issues in your markdown files. I'm currently working on a little redesign of this site, and having the note content typed has made working on it faster and easier.

How I upgraded my site to use Content Collections

Updated Astro

npm install astro@latest

Moved all the notes to `src/content/notes`

Previously there were in a a directory at src/notes, but Content Collections need to be kept in the content directory.

Added type definitions

For my notes collection in src/content/config.js

// 1. Import utilities from `astro:content`
import { z, defineCollection } from 'astro:content';
// 2. Define your collection(s)
const notesCollection = defineCollection({
  schema: z.object({
    title: z.string(),
    tags: z.array(z.string()),
    added: z.string(),
    updated: z.string(),
    excerpt: z.string().nullable(),
  })
});
// 3. Export a single `collections` object to register your collection(s)
// This key should match your collection directory name in "src/content"
export const collections = {
  'notes': notesCollection,
};

Replaced the usage of `Astro.glob` with `getCollection`

The old way of getting all my notes:

const notes = await Astro.glob(`../notes/*.md`);

The new way:

import { getCollection, getEntryBySlug } from 'astro:content';

const notes = await getCollection('notes');

Astro.glob returned an array objects with a frontmatter property. getCollection returns an array of objects with a data property, so I had to update the places where I was accessing the frontmatter.

For example

note.frontmatter.title

is now

note.data.title

Using regex with make find-and-replace in VS Code

Rach Smith — Tue, 21 Mar 2023 20:20:00 +0000

The context for how and why is too niche for me to go in to here, but I had a bunch of files where I needed to change all instances of this:

'FileClient:1643853467530'

to this:

'PenVersionFileClient:{"cpid":"1643853467530"}'

Except for each instance, the id value (the number) was different.

I wanted to keep the number in there, but change the text that wraps it.

Because I needed to replace text on either side of the number, a simple find-and-replace term wasn't going to work. I needed regex.

To turn on search using regex, you want to make sure this option is selected:

To replace the text on either side of text, you want a regular expression that follows this pattern:

/BEFORE_TEXT(.+?)AFTER_TEXT/

where BEFORE_TEXT and AFTER_TEXT match the text on the left and the right of the text you want to wrap-replace.

Then, in the Replace input of the Search UI, you add a $1 to wherever you want the original text to go.

NEW_BEFORE_TEXT$1NEW_AFTER_TEXT

For my case above, I used this:

Search : 'FileClient:(.+?)'

Replace : 'PenVersionFileClient:{"cpid":"$1"}'

Create a rainbow-coloured list with :nth-of-type()

Rach Smith — Mon, 20 Feb 2023 20:03:00 +0000

This is my favourite thing to do with the :nth-of-type() selector:

First, you need some colour values. I like to store them in CSS custom properties so it easy to order them the way you like later.

:root {
  --red: #f21332;
  --orange: #f27225;
  --pink: #e20b88;
  --yellow: #f2ad24;
  --green: #00b249;
  --blue: #1844b5;
  --purple: #a033b3;
}

Then you want to add an :nth-of-type declaration for each colour. The functional notation for each :nth-of-type is in the format of An+B, where A is the total number of colours you have, and B is the position of each colour. So as I have 7 colours, my functions look like 7n+1, 7n+2, 7n+3 and so on...

li:nth-of-type(7n + 1) {
  color: var(--red);
}

li:nth-of-type(7n + 2) {
  color: var(--orange);
}

li:nth-of-type(7n + 3) {
  color: var(--pink);
}

li:nth-of-type(7n + 4) {
  color: var(--yellow);
}

li:nth-of-type(7n + 5) {
  color: var(--green);
}

li:nth-of-type(7n + 6) {
  color: var(--blue);
}

li:nth-of-type(7n + 7) {
  color: var(--purple);
}

You can never have too many rainbows.

Reading code is a different experience to writing code

Rach Smith — Mon, 30 Jan 2023 07:18:00 +0000

When writing code, the first thing I focus on is making it do the thing I want it to do. After that is achieved, I might end up with a large file or method. Once I reach the point where I know what the code is doing, I kind of wish it would get out of the way.

Enter: abstraction. If I could take out all these lines of code and abstract them into neat little functions, I could make the main method read like a book!

The CodePen Rails codebase went through an era of organising code this way, so we have many methods that look like this.

  def new
    @new_user = User.new
    @init_data['__pageType'] = 'signup'

    set_owner
    set_pay_ownable_tier
    set_current_interval

    @team_user_pending_invite = find_team_user_pending_invite

    store_request_session_return_to

    respond_to do |format|
      format.html do
        render(layout: 'signup-and-login')
      end
    end
  end

When you're the person authoring this sort of code, it is satisfying to look at. Look how neat this is; all the implementation details are tucked away in places that are not right here. I don't need to see those details because I'm confident they are doing what they should. I wrote it.

When you're the person reading this code three months, nine months, or three years down the track, you can't be confident that everything is doing what it should. You can't be sure that the function names tell you everything you need to know about this code. You have to jump to their definition and see what's inside them.

And when you're in a codebase that has been abstracted to high-heaven, having to "Go To Definition" up to six times before you arrive at the actual logic in a program is maddening.

We've been moving our CodePen backend from Rails to Go. When I first started using Go, I found it to be "disgustingly verbose". It seemed the "Go way" to write code was to err on the side of leaving logic "in-line" rather than abstract it to another location. "A little copying is better than a little dependency."

When working with Go, my gut reaction was to dislike having to look at all that code. I also missed all the helper functions available in JavaScript and Ruby, for doing things like finding items in arrays.

However, when I returned to reading the old Rails code, I found myself missing the simplicity and verbosity of the Go code. When I switched from code writer to code reader , clever abstractions were far less appealing, no matter how well they were named.

As my experience as a developer grows, I realise that if my goal is to write clear code, I should put myself in the perspective of the person who has to come back and read the code later, whether that is a team member or myself in 6 months.

Just a big brain developer trying to be a grug brain
Clever Code Considered Harmful by Josh Comeau

Remove Shorts from your YouTube Subscriptions feed with :has()

Rach Smith — Thu, 19 Jan 2023 15:28:00 +0000

I have nothing against short-form video content. TikTok is a lot of fun! YouTube shorts are... not it. I hate having them show up in my subscriptions feed! Today I figured out how to remove them from the feed with one line of CSS.

I wanted to set display: none on all items in the feed that had a child element that signified it was Short. Previously I'd have to go to JavaScript to do this sort of thing, but now we have the :has() selector I can do it with CSS. This means we can use a CSS-injecting extension like User CSS or Stylebot.

I'm using Arc as my browser, which has a CSS injection feature built-in via Style Boosts.

Here's the CSS to add to your extension (or Boost if you're using Arc ) to hide all the Shorts:

Update: Jon Campbell pointed out the snippet I had here doesn't work on grid view of the subscriptions page, only the list view. I've updated it so shorts are hidden on both views. To get a snippet that hid the correct things on list view without breaking grid view needed a combination of :not() and :has(). I've definitely learned some things about :has() during this process!

/* Grid View */
#items.ytd-grid-renderer>ytd-grid-video-renderer:has(ytd-thumbnail-overlay-time-status-renderer[overlay-style="SHORTS"]) {
  display: none;
}

/* List View */
ytd-item-section-renderer:not(:has(ytd-grid-renderer)):has(ytd-thumbnail-overlay-time-status-renderer[overlay-style="SHORTS"]) {
  display: none; 
}

Hooray for the patchability of the Web!

Learning in public isn't so easy when you're buried by layers of engineering

Rach Smith — Wed, 18 Jan 2023 20:15:00 +0000

I've come to appreciate that unless you're a full-time content creator who can devote hours to polishing, the only way to publish regularly is by embracing the approach of "working with the garage door up" or "learning in public". Show Your Work! as Austin Kleon says.

TIL-style posts about what you've been working on are a great type of content for your developer blog. And if your work is straightforward enough, the writing is straightforward enough too. A CSS developer could share how they use a new language feature. A UI developer could share their opinions on a React component pattern.

But as the scope and complexity of your role grows, the harder it is to write something about your day. At least this is how I've experienced it.

Take one of my work days recently. I was struggling with something and thought writing a note about it might help. The problem was that the "something" was generating TypeScript types from GraphQL files using GraphQL Code Generator in a Next.js project using a custom webpack config, that lives in a monorepo powered by Lerna. There were ...seven tools or technologies in that sentence. My potential note is niched down so hard, it feels like there is maybe one other person in the world who can relate. His name is Geoff and chances are he's not reading this site¹.

A way to rise to this challenge is to work on the skill of abstracting something more generic/simple from your complex work situation. A "minimal, reproducible example" via blog post if you will. Chris Coyier is good at this, turning what is layered work at CodePen into simpler hypothetical scenarios.

Say you have some JSON data like this....

Or, you could turn complaining about this challenge into post content instead, as I have here.

Geoff, if you're reading, we should talk. ↩

The hardest part of being a Junior Developer

Rach Smith — Mon, 16 Jan 2023 05:49:00 +0000

Even though it was 12 years ago, I still remember what the most stressful part of being a junior developer was. I was reminded of it when I saw this meme in my Twitter timeline yesterday:

In my first developer job, I had no previous experience - just some basic front-end coding and design classes at Uni. I had been hired by an advertising agency to animate flash banners and code marketing emails. The work atmosphere was fast-paced but I enjoyed the challenge. There was a lot to learn but I was loving everything I was learning. A lot of the people who worked there - 'ad people' were intense personalities but I grew used to working with them.

I loved that job, and couldn't believe I was being paid more to do it than in any hospitality role I had worked prior. There was just one part that stressed me out: knowing how long I should work on figuring out something by myself vs. asking for help. I had no context for how long anything should take. I didn't want to be judged harshly for asking too many dumb questions, but I also didn't want to appear to be slow. I had the added pressure of feeling like I was representing my entire gender with my performance.

My manager at the time must have noticed my anxiety around this, and he did a wonderful thing. He made the timing aspect of it super explicit for me. He would do things like give me my next task and then say "try and get this done, if at any point you have spent an hour without making any progress, come and ask for help". Then I knew how long was too long to spin my wheels on something on my own. Most of the time, I could keep figuring things out on my own, but when I couldn't I could approach my manager without worrying whether I was bothering him "too soon".

By the time I moved on from that job, with the help of that manager, I had enough experience to be able to judge when it is time to ask for help on something and didn't have to worry about it again.

As I've always worked on small teams, I haven't had the opportunity to manage a green developer that needs a lot of direction. But I thought I would just share this in case it is useful to anyone who does. Try and be very specific when you share your expectations around timing, it might help them out. It certainly helped me.

Don't want to fix that bug? Here are 6 things you can do instead

Rach Smith — Sat, 07 Jan 2023 19:52:00 +0000

Look, coding is hard. Every time you start to solve a problem or fix a bug you run the risk of not being able to do it and then feeling like you aren't as smart as you thought you were. That sucks! Here are some things you can do instead.

Choose a new font for your IDE

My paid favourites are Berkeley Mono, Operator Mono and Dank Mono. But there is a whole set of free monospace fonts on Google Fonts that you can try out, one by one until you find one you like, or don't.

Change your terminal

I've heard warp is good?

Choose a new theme for your IDE

Some of my favourites: Moonlight II, In Bed By 7pm and Houston. But there are hundreds (thousands?) of options to choose from. Try them out. Use each for half an hour before you decide to change back to the same one you've had for the last 3 years.

Decide you're going to learn all the keyboard shortcuts in VSCode

Pretend you're improving your productivity when you're actually procrastinating! Check out the Keybindings reference or if you're too lazy for that, watch some videos on people'sfavourite VSCode shortcuts.

Buy a new keyboard

Your code is going to be so much better when you have the ultimate keyboard. Research is important so make sure you head back to YouTube to find out which is the best. Now instead of doing the work that makes you money, you are spending money. Amazing!

Redesign your personal website

I mean it has been at least 6 months since you overhauled it. And the fact it doesn't include a dark/light theme switcher is frankly, embarrassing. Check out other people's sites for some inspo. Bonus: you can go back to Google Fonts!

How Supabase fits into your stack

Rach Smith — Fri, 09 Dec 2022 09:20:00 +0000

Recently I considered replacing the Talkyard comments solution on my notes here with something I've built myself. To do that I need a database. I was looking at different Postgres hosting options when I recalled I had seen buzz from developers on Twitter about Supabase. I wondered if that could be my database host?

Supabase's tagline starts with "Supabase is an open source Firebase alternative." That didn't tell me much because it has been years since I used Firebase and I could barely remember how it worked or what it offered. I've done some reading of the Supabase docs and thought I would share my understanding of how Supabase can help on a new project.

When I think about how a website or app is set up, it looks something like this:

The server renders the page.
The client sends subsequent requests to a back-end application on the server.
The application connects to a database and retrieves/writes data, and returns a response to the client.

Or, in the case of this particular project I was designing:

The Astro SSR page is rendered via a Netlify function.
The client sends subsequent requests to an API provided by a Netlify function.
The serverless function code connects to a database and retrieves/writes data, and returns a response to the client.

In both cases, it's the same client -> server -> DB flow, except serverless functions are standing in for an app on a server in the second case.

I was looking for something to fulfill the database section of that design, and Supabase does provide Postgres DB hosting, but it is also trying to remove the need for you to code a server-side application to control the flow of data in your project. You can write code on the client that interfaces directly with the database via the API provided by Supabase.

When I saw that the flow of information in a Supabase Project goes from client to DB (via a thin ready-made API layer), my first thought was, what about authentication? Don't you need to write server-side code to make sure the person who is sending the data is allowed to put that in the database? Supabase allows you to set policies on DB table rows so you can control access to reading, creating, updating and deleting rows on tables.

On the subject of authentication... one of the features of the Supabase JS client is that it provides shortcuts to building "Sign Up and Log In" solutions for your app. That's pretty cool as most apps require user authentication and it is a tedious thing to get right when you're coding it from scratch.

Anyway, I think I will use Supabase as the DB solution for my new project. Even if I don't go all-in on client-side functionality with the Supabase JS client (I'm trying to make progressive enhancement a priority), I can use their REST APIs with Astro SSR functionality. It still looks like an easy enough (and affordable) option for adding a Postgres database to my project.

Can't you hear that

Boom, badoom, boom, boom, badoom, boom, bass?

He got that super bass

Thanks for reading this post via RSS! Let me know your thoughts by leaving a comment on the original post, send me an email, or Tweet at me.

Do what you say you're going to do

Rach Smith — Wed, 23 Nov 2022 09:28:00 +0000

If you want to impress people you work with/for, do what you say you're going to do. Be reliable and deliver what you have promised (almost) every time.

The key to achieving this isn't to hustle and crush it week upon week - It's becoming adept at managing expectations.

Do what you say you're going to do.

can also be phrased as:

Only say you're going to do something you know you can do.

People get this backwards and think that other people are impressed by how much work they promise or intend to do. They are not. They remember what you delivered, or annoyingly, what you failed to deliver.

CodePen has a flat structure. We define our goals as a team but the individual work people do on a day-to-day basis is self-directed. Each week we have a meeting where we essentially commit to doing something in the following week. I am conservative with my commitments. I leave space for hitting a roadblock or two at work or a daycare emergency at home. Why? So I can show up the following week and say I did what I said I was going to do.

What if you're not sure if you can do something, but you'd like to give it a try? Communicate that. I use these words all the time in discussions with my coworkers: "I'm not sure if that is possible, but I'll try to make it happen". Then after I'll either report that I made it work or explain how I tried to make it work. I promised to try. I delivered on my promise.

Moving from problem adder to problem solver

Rach Smith — Sat, 19 Nov 2022 07:00:00 +0000

From one of James Clear's newsletters:

One type of person approaches a situation with the mindset of, “How can I make this work?” Another type seems to approach each circumstance with the mindset of, “What are all the reasons this wouldn’t work?”

Both people will be forced to deal with reality, but the first person will only have to solve problems that actually occur while the second person will often avoid taking action entirely because of the potential problems they have dreamt up before starting.

There will always be reasons to not do something. Be a problem solver, not a problem adder."

Of course, sorting all people into two buckets like this is nonsense, that's not how humans work. But I think people fall on a spectrum from "problem adder" to "problem solver".

My natural inclination is to be a problem adder. When someone describes an idea to me my mind immediately goes to the 15 reasons why it wouldn't work. It is just how I'm wired. I'm always willing to give things a try and attempt to solve the problems of course, but I can't help but be aware of them.

Enter my boss: founder of CodePen Alex Vazquez. Alex is at the opposite end of the spectrum. He is an incredibly optimistic and ambitious problem solver. We used to have conversations where he'd describe his ideas to me and I would start listing off the reasons it may not be possible. He'd say: "forget about that, assume all that is solved". Excuse me? Just assume these problems are solved?! This was nonsensical to me.

Over time and many conversations, and us reaching the outlandish goals he'd set, I saw the real value in being a problem solver. I stopped thinking so much about all the reasons why something wouldn't work and instead started assuming we could solve them. Even better, Alex taught me how to look for ways to remove the problems altogether. Instead of thinking "what could go wrong" I am now more likely to think "what if it were easy? how would that work?".