DEV Community: Ashley Kolodziej

Exploring circular text in CSS and SVG

Ashley Kolodziej — Sun, 26 Jun 2022 01:05:32 +0000

I decided I'm sick of the grid. I want to align some text to a circle.

As it turns out, it's not so hard to do this with SVG. You don't even need a complicated path element. Just grab yourself a <circle>, like so:

With this pen, I wanted to explore depth, so I adjusted the placement, opacity, and size of the text in each circle.

And of course, if you know me, you know I'm into my colors. So I thought, well, rainbows are sort of a circle too.

Writing creative CSS

My best moments in CSS are when I find out something new, and just keep riffing on it endlessly. I've got a whole site dedicated to this rainbow situation here:

This is how you learn in design school. You take a piece of paper, and you cut it up and really focus on how the shapes or colors or just one piece of it is interacting with the rest. And then, you figure out the best bits.

Build an idea generator from scratch, part 4: Speed up the page by caching API results [Video]

Ashley Kolodziej — Thu, 17 Jun 2021 23:58:28 +0000

Hello again folks! This week's installment of the Idea Generator Tutorial focuses on performance and caching. We'll examine cookies and localStorage as possibilities, and how to ensure users still get fresh results periodically even with caching data. We'll also reinforce good programming practices by breaking up our functions into smaller, easier parts to manage and debug.

If you're new to this series, catch up by checking out my post on the first tutorial in this series.

This video covers:

How to create localStorage data with expiration times so data stays fresh for returning users
The difference between save and save-dev in npm packages
How to troubleshoot common errors and importing with ES6 syntax

... and, as usual, a number of other fun tidbits that will help you work more effectively.

The final product

In this series, we’ll be working toward this idea generator as our final product.

Code links

Follow along by cloning or forking the main branch here: https://github.com/ProfessorKolodziej/idea-generator

You can also start on your own project by using my Student Site Boilerplate template: https://github.com/ProfessorKolodziej/student-site-boilerplate/

Catch the new video over here. Happy coding!

I'm always happy to connect!

🐰 @ashleykolodziej on Twitter
🐰 Subscribe to Professor K Explains on YouTube

Build an idea generator from scratch, part 3: Create dynamic HTML from data [Video]

Ashley Kolodziej — Thu, 10 Jun 2021 21:12:42 +0000

Hello again folks! This week, for our Idea Generator Tutorial, we'll be focusing on HTML markup. Which tags should you choose? How do you plan your class naming and IDs while thinking of your functionality? And of course - we'll be connecting that data we pulled from the API last time to our markup as well.

If you're new to this series, catch up by checking out my post on the first tutorial in this series.

This video covers:

How to create a solid HTML markup structure for your JavaScript app
How to move that markup into templates you can use in your JavaScript
How to connect the data from an API call to your page
Some fun new explanations on professional Git development workflows
Thinking through functionality and writing it down

... and, as usual, a number of other fun tidbits that will help you work more effectively.

The final product

In this series, we’ll be working toward this idea generator as our final product.

Code links

Follow along by cloning or forking the main branch here: https://github.com/ProfessorKolodziej/idea-generator

You can also start on your own project by using my Student Site Boilerplate template: https://github.com/ProfessorKolodziej/student-site-boilerplate/

Catch the new video over here. Happy coding!

I'm always happy to connect!

🐰 @ashleykolodziej on Twitter
🐰 Subscribe to Professor K Explains on YouTube

Build an idea generator from scratch, part 2: Writing an authenticated fetch request [Video]

Ashley Kolodziej — Sat, 05 Jun 2021 17:56:41 +0000

It's a new week and a new opportunity to learn! This week's section of the Idea Generator Tutorial focuses on Fetch and authenticated API calls in JavaScript.

If you missed my last post, catch up by checking out my post on the first tutorial in this series.

This video covers:

How to write a basic fetch request to an API with JavaScript
Strategies for debugging errors in fetch requests
How to review API documentation and decide what endpoint to use
How to add parameters to your fetch calls to narrow down data
How to use the new for loop syntax in ES6 to log out individual results from an API call

... and so much more!

The final product

In this series, we’ll be working toward this idea generator as our final product.

Code links

Follow along by cloning or forking the main branch here: https://github.com/ProfessorKolodziej/idea-generator

You can also start on your own project by using my Student Site Boilerplate template: https://github.com/ProfessorKolodziej/student-site-boilerplate/

Catch the new video over here. Happy coding!

I'm always happy to connect!

🐰 @ashleykolodziej on Twitter
🐰 Subscribe to Professor K Explains on YouTube

Build an idea generator from scratch, part 1: Project setup with Github and dotenv [Video]

Ashley Kolodziej — Fri, 28 May 2021 01:32:45 +0000

So as I was finishing up teaching my web development class last year, I really wanted to give my students something to help them continue growing and learning. I decided to build an idea generator with HTML, CSS, and JavaScript using the raindrop.io API, and now, I’m finally getting around to posting the process recordings. Woohoo! I’ll be posting a new recording each week.

In this first part of the tutorial, we'll set up a Github repository, get our template code set up, and install dotenv, a library which will help us make an authenticated call to the API securely. You'll also see your first introduction to Git Flow. I use Tower to make things a little easier, but you can use any method of interacting with git you like. This would be a great intermediate JavaScript challenge for someone looking to practice ES6 syntax!

This video covers:

How to set up a new repository in Github using a template
How to clone a remote Github repository to your computer
How to use Git Flow to create a feature branch
How to make an authenticated call to an API using JavaScript
How to use dotenv to store access tokens and other sensitive information in your app without committing it to your codebase

... and so much more!

The final product

In this series, we’ll be working toward this idea generator as our final product.

Code links

Follow along by cloning or forking the main branch here: https://github.com/ProfessorKolodziej/idea-generator

You can also start on your own project by using my Student Site Boilerplate template: https://github.com/ProfessorKolodziej/student-site-boilerplate/

Catch the new video over here. Happy coding!

I'm always happy to connect!

🐰 @ashleykolodziej on Twitter
🐰 Subscribe to Professor K Explains on YouTube

Back to basics: Why excellent markup is the foundation of accessible content

Ashley Kolodziej — Fri, 21 May 2021 17:50:25 +0000

Happy Global Accessibility Awareness day, my friends!

One of the things I didn't learn until late in my career as a frontend developer was just how important HTML is to accessibility. When I first started learning to write code, HTML felt like a means to an end - something I just needed to get out of the way in order to be able to write CSS.

How wrong I was.

This post is for all the newbies out there who might be tempted to skip the fundamentals of HTML. Today, we're going to look at what exactly it is HTML does, and why that's so important for making your websites accessible.

What is HTML, really?

HTML is a language of intent - the bridge between what you mean to say, and how the computer interprets it.

Okay, I realize that sounds a little weird. But hear me out. As a markup language, HTML is all about telling a computer how your content is structured.

Why should you care about how a computer understands your content?

Computers are the interface between your content and the rest of the world. This comes up in two contexts: search engine optimization, and accessibility.

Search engines and screen readers are both computer-based interfaces that help people access information they might not otherwise be able to access. They do two different jobs, and are aimed at two different use cases, but fundamentally, they are the same: computers that interpret human intent in content. This is why so many best practices for accessibility also happen to coincide with good SEO practice.

Using semantic HTML tags in your layout helps these tools understand your intent in organizing the content, and how to navigate it.

Think about what it's like to navigate a new neighborhood.

Imagine if you suddenly placed in an unfamiliar neighborhood that you've never been in, and needed to find out how to get to the nearest store to buy a drink.

You might ask someone for directions.

You might think about some rules you know are usually true - the sun sets in the west. Streets are normally in a grid pattern. Usually, they intersect about once every block.

You might look for street signs, or traffic signals. These help you understand where you are.

Why is HTML so important for accessibility?

HTML provides these types of rules and structure to make it possible to navigate content using a computer. Using a screen reader, you can ask HTML for directions - landmarks around the content. Where's the nearest main content? What are some of the most important pieces of information in this article, and where can I find them?

HTML also has some rules that are usually true. Well-formatted HTML headings are always ordered from h1 to h6, without skipping levels. Skipping a level is kind of like when a road you thought was straight suddenly veers off into a bunch of confusing curves. It can make it difficult to understand where you are in the neighborhood, relative to where you started.

How do I write more semantic HTML?

The simple answer is to always ask yourself if your non-semantic HTML elements are really the best choice for your content's meaning. Could your div be a section instead? In some cases, you need to add HTML to style something in a purely decorative way, and that tag doesn't have any new meaning. But in many cases, section, aside, and other elements are much better choices.

There are over 100 elements in HTML - it's easy to get overwhelmed. The videos above will introduce you to the most common semantic HTML elements, so if you're not sure where to start, start with those.

I'm always happy to connect!

🐰 @ashleykolodziej on Twitter
🐰 Professor K Explains on YouTube

The Golden Rules of Code Review Etiquette, as explained by teeny tiny bunnies

Ashley Kolodziej — Wed, 19 May 2021 03:00:43 +0000

Inspired by this #DevDiscuss on Twitter:

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

This is the advice I gave folks in my department when starting our code review process up, and three years later, it's still going strong.

Bunny gifs are critical to the messages that follow and are included here for improved understanding of the rules.

Keep your review requests small and focused.

This helps your reviewer get feedback to you in a timely manner.

Try to get to a review the same day it is requested.

Most folks depend on code for upcoming meetings, releases, and to keep moving on our ideas. Don’t let review requests sit.

Approve or request changes, but never comment only.

Comments don’t give the author clear direction on whether or not they can move forward. They’re great for discussion, but it’s important to be clear about next steps too.

Be clear about what needs addressing.

If you request changes, be clear about what types of changes are required for approval, and what aren’t, in the overall description for your review.

Review with teaching in mind.

Code review is about helping each other and sharing our knowledge. Phrase your feedback and ideas in a way that helps others around you to learn more about your area of expertise! Don’t make assumptions or get frustrated. Help your coworkers improve instead.

Review with empathy.

Deadlines are hard. Being new is hard. Learning is hard. We are all working to be the best people we can be, so take extra care to call out the cool ideas you see and be positive with your feedback. Use fun and appropriate emoji liberally! 🐰 Be aware of your voice and tone - humor is easily misinterpreted in text.

Review with common sense.

If you get a review the same morning as a meeting or the week of launch, approve it, but leave your feedback anyway for when the designer or developer won’t be scrambling to improve things. Be deliberate about what’s okay to leave for later.

Be aware that changes introduce bugs.

Each change that has to be made can impact the stability of the code. Keep this in mind as you review around tight deadlines.

Don’t require perfection.

Your job as a reviewer is to act in the best interest of the code and the people you’re working with. Early on, asking someone to refactor repetitive or overly complex CSS or JS is a good call. During QA, it is not.

This list was taken from a code review training I ran for my department a few years ago. Check out the full training on Google Slides.

7 HTML debugging tips for complete beginners

Ashley Kolodziej — Sat, 15 May 2021 19:54:52 +0000

I teach introductory web development classes to students who don't have any programming experience whatsoever, and one of the questions I always get is - how do I debug my code when I don't even really know how to write it just yet?

Debugging can be overwhelming if you're new to coding or a particular language. Luckily, you don't need to know a language by heart to debug your code. Debugging is just a method of thinking and checking things step by step, one at a time, until you've discovered what's happening. Anyone can do it with the right checklist!

So with that in mind, here are my tips for debugging in HTML, including a practice problem and video explanation at the end.

Tip 1: Talk through what you expected

When you're stuck, one of the best things you can do is to try talking through what you expected to see, step by step. Talking through what you expected is a great way to start identifying some of the places something might have gone wrong in your code. You can also try writing down some key words while you talk so you don't forget them, such as what elements aren't working like you thought they would. This will help you down the road if you need to Google it.

Tip 2: Make sure your code is properly indented

Once you've identified the problem and talked through what you expected to see, the next thing that you can do to help get unstuck is to make sure all your code is properly indented. This is a great step to take because it will force you to go line by line and make sure everything makes sense to you, and it will naturally get you to work on the next tip, which is...

Tip 3: Make sure all tags are closed

There's nothing like a missing close tag in HTML to throw you off! When styles are applying to more of the page than you think they should, or your layout is acting especially wonky with no clear reason in the CSS, a missing close tag is almost always the culprit. The best time to check this is while you are fixing your indentation.

Tip 4: Check for syntax errors

HTML is pretty permissive when it comes to syntax, but you can still run into trouble if you don't have quotes around your attribute values, or you forget an equals sign, or even miss a closing > on a tag. These types of errors are called syntax errors - errors that stop your code from running correctly (or in some cases, from working altogether!). The w3c has a simple explanation of HTML syntax that can help you double check for these types of errors.

Tip 5: Use an HTML validator

Tips 1 through 4 will get the majority of HTML problems solved if you have sharp eyes. But what if you miss something, or you've written a tag that is syntactically correct, but doesn't actually exist in HTML? This is where a validator can really help you out. Validators automatically check for things like missing close tags, syntax errors, and even tags that don't exist.

So why not just jump straight to a validator? You can, but you might find some of the errors a little daunting at first. Going through these other preliminary steps can help get you in the right mindset to read and understand error messages in a validator.

The w3c's validator service is a great tool for this that you'll want to bookmark.

Tip 6: If the error looks weird and unfamiliar, double check your approach

If an error comes up in the validator that just plain does not make sense to you, it might be a good time to start doing some Googling and double checking your approach. Do you understand what the code is doing? Can you explain it line by line? You may have inadvertently used the wrong kind of tag. It's surprisingly easy to do!

Alternately, you may find there are no syntax errors, in which case, it's time for...

Tip 7: Use rubber ducky debugging

If worse comes to worse and you just don't know what's going on, try explaining the problem to your nearest inanimate object - or friend. Even if they don't know how to write HTML, if you can explain your problem to someone who knows nothing about what you're doing, it might help you discover a logical error - or an error in the way that your code is built that isn't necessarily wrong or broken, but also doesn't solve the problem you intended to solve in the first place. If you've ever heard the term "rubber ducky debugging", this is what that is!

Code along and practice debugging

The best way to learn debugging is to practice and see how others debug. If you want to try some of these steps out, check out my video, 7 Beginner-Friendly Tips for HTML Debugging on YouTube. I've included a CodePen practice problem in the description, and I recorded myself explaining these tips step by step as I solve the problem. Try debugging your way first, and then compare it with how I did it, and see how far you can get in solving it.

Happy coding!

Tip: use the WordPress code editor to pass attributes to your Gutenberg block variations

Ashley Kolodziej — Sun, 11 Apr 2021 02:00:02 +0000

I’ve been learning Gutenberg block development lately, and one of the things I was struggling with was trying to figure out what parameters I could pass on to blocks defined in block variations. I was looking all over the place for documentation on the parameters each block takes, such as font size and color. Little did I know I had all the documentation I needed right in front of me, in the form of the WordPress code editor.

Wait, what’s a variation?

A block variation is an easy way of leveraging WordPress core blocks (and even custom blocks you build) to create your own sets of blocks without writing any React code. You’ll need to write a bit of JavaScript, but it’s a lot like writing an array or object. If you can do that, you can write a block variation.

I like using block variations to create recommended sets of content and help guide my users in content entry. You can nest blocks in block variations, and do things like pre-set the background or font size on them.

Use the editor to speed up block variation development

My new workflow with block variations is to build the variation just the way I like it in the visual editor, and then switch over to the code editor to grab the attributes I need from there. This lets me set hard-to-remember parameters the right way, like gradients, without having to guess and check, like so:

Once you identify the block you want to model your variation off of in the code editor, just grab those attributes and bring them back into your block variations code. Here’s what that looks like in my final code.

This works for both your variations and your innerBlocks. Here’s an example in my final code of how I used this in a nested block.

Block variations are a low key way to get into Gutenberg block development and get familiar with the ecosystem without getting into React or the more complicated bits. Check it out if you’re new to Gutenberg and looking for a place to start.

Full tutorial

If you’re new to JavaScript or Gutenberg, I recorded my full process of building block variations using this method in a beginner-friendly way here. I also put together sample code below in Github you can use to get started with a new block variation.

ashleykolodziej / professorkexplains-block-variations

Block Variations tutorial

These are companion files to my Build Your First Block Variation tutorial on YouTube.

To use these files, download them, and then unzip them to the directory of your choice. In my tutorial, this directory is called variations-example.

You can view the final code from the tutorial on the solution-code branch.

You can also see exactly what changed codewise from the beginning of the tutorial to the end of the tutorial by taking a look at this pull request.

View on GitHub