A dedication to craft means always facing the fact that you could be better–and doing something about it when you see how.
Here's what I've been up to lately
RTL Udemy Course
Just finished up an awesome Course by Bonnie Schulkin on React Testing Library and Jest. It also integrated the context API and MSW for mocking server responses from axios calls. Feel free to check out the sample project code or view the live demo below.
One of my popular GitHub repositories was getting a bit stale! This post brings the tutorial up to date for ruby 3.2, rails 7 and newest version of devise & devise-jwt. I also created a GitHub template if you’d like to try it out as a starter!
I’ve been working on a site that allows developers to create a profile, share links to their social media profiles, and showcase their projects. The app uses a Rails API backend and a React client, with End 2 End tests written in Cypress.
When I interact with students, I like to integrate an interactive,
inquisitive approach that's focused on soliciting incremental feedback
driving towards a clear picture of the task at hand. When students are
struggling on their journey to learn how to code, I find that there's
usually something missing or lacking in their process and that
focusing on these 5 phases of inquiry can help them develop better
learning habits.
What am I trying to do?
Before starting to code, you want to be crystal clear on what success
looks like. Before you commit to code, or an approach, having a high
level picture of how the pieces will fit together is essential to stay
focused as you work through the rest of the phases.
What's happening instead of that?
Coming to grips with the current behavior of the code, and what the
feedback you're seeing means, is essential as a beginner. You don't
just stop at "it's not working :("–you pay close attention to what is
actually happening and compare that to what you want.
How can I explain what's currently happening?
Before trying to fix the problem or making the feature work or making
any change at all, the current behavior needs to be explained. As a
beginner, you need to make sure you understand the feedback you're
getting from the computer. Don't make a change until you can explain
current behavior.
Given my understanding, what change can I make to get closer to my
desired result?
After explaining why the code behaves the way it does, the next step
is to come up with a change that could take us closer to the desired
behavior. But, let's make things interesting here–if you make a
prediction about what should happen after you make a particular
change, you give yourself the opportunity to be right or wrong. If you
do this in a way where you can make the prediction and get instant
feedback about whether it was right or not, you'll be tying in your
brain's reward structure. When you're right, you'll get a hit of
dopamine that will get you addicted to thinking about that concept
correctly. When you're wrong, you get a visceral sense of it–and you know you've got some reading to do!
When I make the change, do I get the result I expected?
At this point, you want to re-anchor to the task at hand. If you got
the expected result, you can repeat the phases starting with the
first. If you didn't, then you want to return to phase three and
explain why you got what you did instead of what you expected.
