Forem: Ceora Ford

Next.JS in a Nutshell: Rendering

Ceora Ford — Tue, 05 Dec 2023 16:58:00 +0000

Next.JS is one of the most popular modern React frameworks out there. I’ve spent the past few months building with Next.JS and learning the ins and outs of the language. Next.JS caught my eye initially because it offers a more seamless experience by abstracting away some of the tedious tasks that come with working with React like bundling and compiling. These are the things that usually make me want to pull my hair out so I had to try out Next.JS when I discovered that these things are automatically configured for you.

As I’ve been building, I’ve learned a lot along the way and I wanted to wrap my findings up into a blog post series that will cover a few things:

Core concepts in Next.JS
- Server side rendering vs Client side rendering
- Pages Router vs App router
What to do after learning the basics
Helpful resources

This post will specifically focus on rendering. We’ll cover routing and next steps in the future posts. My goal is to give you an introduction to Next.JS and a place to start so you can move forward and learn more on your own! I’m also happy to write more articles on specific Next.JS topics. Feel free to leave any requests in the comments!

Core Concepts👩🏾‍💻

Next.JS is built around some React concepts that you’ll be familiar with if you’ve worked with React before. But there are obviously a few things that make Next.JS a bit different. Next.JS has some enhancements that give it an added edge over React or other frameworks. I already mentioned the compiling and bundling improvements. Next.JS also comes with image and font optimizations that enhance user experience and site performance. Images are lazy-loaded and automatically resized based on device size. You can read more details on font optimization in the Next.JS documentation.

Next.JS's main claim to fame is how rendering and routing are handled. Even if you haven’t worked with Next.JS before, you’ve probably at least heard terms like “Server-side rendering” and “Client-side rendering”. It’s really important to understand these concepts when you’re building applications with Next.JS. So let’s dive in.

Server Side Rendering vs Client Side Rendering⚙️

In Next.JS, you can choose where you want your components to be rendered: on the server side or on the client side. Next.JS is all about performance optimization and for that reason, Next.JS uses server side rendering by default. Server side rendering improves performance in a few ways:

Data fetching → When data fetching is done on the server side, the time it takes to retrieve data is reduced since the server is architecturally closer to the data source
Caching → When you render on the server, results can be easily and quickly cached which leads to faster response times for future requests.
Bundling → Large dependencies can now be kept on the server which reduces the size of your bundle on the client side

There are other benefits but I think these 3 really highlight how server side rendering can improve performance. These changes might seem small but they add up quickly. If you want to know more about the mechanics of server side rendering, check out this documentation.

Static rendering, dynamic rendering, and streaming🔧

Server side rendering can be done in 3 ways: static, dynamic, or streaming. Static rendering is the default. Information is rendered at build time meaning it’s preloaded before a request is made and cached. This is perfect for data that doesn’t need to be customized per user. Any information that is the same for every user can be statically generated. Again, this is a huge performance optimization. With dynamic rendering, data is rendered on each request. This is good for data that is unique to each user or for information that changes quickly.

When I first learned about static and dynamic rendering, I panicked a bit because I assumed that I would have to decide how each possible route and every piece of data on my site should be rendered. The great thing is that Next.JS automatically chooses for you. You still have control when you want to because you can specify when to cache or revalidate certain data. You can also choose to stream some data in your UI.

Streaming is a new feature of Next.JS that’s only available with the App Router (which we’ll dive into soon). Streaming allows you to progressively render data from the server. Using this rendering method allows you to keep displaying parts of a page immediately while the streamed data is still loading. Instead of the whole page loading and forcing your user to stare at a blank screen, streaming allows you to pinpoint the data that needs more time to render while still displaying the rest of the page.

To put all of this into context, an About page would be statically rendered since the information won’t change no matter who’s viewing it. Components on a profile page that can be changed such as display name or status would be dynamically rendered. For large amounts of data that can take time to load such as product reviews, posts on a social media feed, and the like, streaming can be used.

Client side rendering🔨

Now, what about client side rendering? Client side rendering is rendered on the client side at request time. Server side rendering is the default so in order to use client side rendering, you have to opt in. Next.JS automatically handles whether server side components will be rendered statically or dynamically but it doesn’t do the same for client components. You have to manually specify when you want client side rendering to be used.

When should you use client side rendering? Since you can use state and event listeners with client components, it’s perfect for interactive components that are meant to produce an immediate result for users. So think of liking a post or comment on a social media site. This kind of feature could be built with client components since liking something involves interactivity, data that changes quickly, and displaying said data to users immediately.

Conclusion👩🏾‍🏭

So we’ve covered the basics of rendering in Next.JS. This is an overview and there’s obviously more that goes into rendering especially under the hood. If you want to learn more of the nitty gritty details, check out some of these resources:

The main take away you should walk away from this post with is: Next.JS really prioritizes performance. Relying primarily on server side rendering is done to enhance performance and user experience. If performance is important for the project you're working on, Next.JS might be the right choice for you!

I’ll post part 2 of this series shortly! The information is already drafted so don’t worry it’s coming soon! If you have any questions or comments, please leave them below! I’ll try to get to as many of them as possible! Thanks for reading :)

My Favorite Resources for Learning GraphQL

Ceora Ford — Thu, 17 Mar 2022 18:25:11 +0000

I recently held a Twitter Space where I discussed how I learned GraphQL during my first few months as a developer advocate here at Apollo. I went over the strategies I used which can be really helpful regardless of what language, framework, or tool you’re learning on the job. If you're interested in checking out the recording, I’ll leave a link at the end of this article.

For now, I want to focus more on what I used to learn GraphQL. So here’s a quick list of my favorite resources for learning GraphQL. This list includes courses, videos, tutorials, and more. So no matter your preferred medium for educational content, you’ll find something that fits your style.

1. What is GraphQL YouTube Video

If you don’t know much about GraphQL or what problems it solves, this is a great video to start with. It covers the fundamentals of how GraphQL works and how developers benefit from using it.

2. GraphQL Odyssey Course

This is the main course I relied on when I was first learning GraphQL. This is free and it includes tons of great information and interactive coding exercises. And once you finish all 5 modules, you get a certificate!

3. GraphQL Is for Everyone Workshop

I was able to attend this workshop shortly after joining Apollo and it was amazing! This workshop is led by Eve Porcello and I love the way she teaches. All the information is delivered in a fun and approachable style. This is a great workshop to attend especially if you’re completely new to GraphQL.

4. GraphQL Email Newsletter

This email newsletter is also created by Eve Porcello. It’s an easy, low-stakes way to learn more about GraphQL. I’m a huge fan of Eve’s teaching style and this email course is just as great as everything else she creates.

5. Full Stack GraphQL Tutorial

This Full Stack GraphQL tutorial is a great way to start building with GraphQL. I’m a huge proponent of project-based learning. But it can be intimidating to start a project with a new language all on your own. So this is a great way to have a guided learning experience as you begin working with GraphQL.

6. Everything I Learned in My 1st Year as a SWE: GraphQL Article

I really enjoyed this article because hearing the perspective of another GraphQL newbie really resonated with me. It was nice to read about parts of Camila’s learning journey that mirrored my own. It also helped me to recognize areas of confusion that I, as a developer advocate and GraphQL educator, could help fill.

7. Getting Started with GraphQL Article

This is an article that’s quite similar to this one. It includes an explanation of what GraphQL is and additional resources for learning. Shruti is a pillar in the GraphQL community so I’m sure you’ll find something useful in that article.

8. GraphQL Glossary

I have to include this glossary because it was so helpful for me! I used it as a handy reference along with my courses and tutorials so I could easily check my understanding of unfamiliar terminology.

Conclusion

If you have any recommendations for GraphQL learning resources, please feel free to leave them in the comments below. Like I said, these are resources that I personally used and enjoyed. I’m sure that there are so many more out there.

If you’re interested in actual learning tips, you can listen to the recording of the Twitter Space. I plan on doing more Spaces about GraphQL, developer advocacy, and working at Apollo. So let me know if you have any suggestions. Thanks for reading💜

Behind the Scenes of Our "What is GraphQL" Video

Ceora Ford — Tue, 08 Mar 2022 16:01:18 +0000

Everyone has their own learning style. Some people prefer to read educational content. There are some developers who like to skip the reading and go straight to building and breaking things. Lots of people really enjoy video content. Then there are people like me who switch between all learning styles and content forms depending on the subject.

The developer experience team at Apollo realized we wanted to focus more on creating video content. It’s our job to create educational content that will appeal to developers and we want that to include videos. We recently released our first of many YouTube videos called What is GraphQL.

It took a lot of hard work from the whole team. I wanted to talk about the process we went through to create and release this video. Our process is going to change and evolve over time. We’ll probably look at this first behind-the-scenes view and marvel at how much we’ve improved!

So let’s pull the curtain back a bit and go over how we went about creating this video!

Coming up with ideas

Of course, everyone on the team had a ton of ideas for our videos. GraphQL is such a broad topic and there are so many creative things you can do with videos. To narrow down our focus, we had to think about a few things.

Videos can be hard to update and edit post-release. Apollo and GraphQL (and just tech in general) are constantly changing. It’s inevitable that some content will become deprecated in the long run. So for our more polished, high-effort videos, we decided to stick with concepts that are relatively constant and stable.

What is GraphQL fits this really well! The fundamental features of GraphQL probably won't change any time soon. Plus, what better way to kick off our new video initiative than starting from the very foundation of everything!

After deciding on what our first video would be about, we went on to write out our script.

Creating the script

Scripting is not easy. It reminds me of what it’s like to write a talk or an article. Coming up with the script and storyline for the video was a painstaking process. We wanted to be sure that our video was technically sound and worded just right. So we edited and edited and edited some more.

Of course, at one point and time, we had to stop ourselves. We weren’t aiming for perfection. We wanted something that would be really good and useful to the community. So after we finalized the script, our video team came up with some creative concepts to help us really get our ideas across.

Next, we assigned lines to different team members. We wanted this video to reflect the people who make up the developer experience team at Apollo. If you’ve watched the video, you probably noticed how we switch up between narrators to do this. All of this was written into the script and gave each of us a chance to rehearse our individual lines so we could be prepared for the next step.

Filming our video

Now onto filming. We got our fancy cameras and fancy lighting and started filming. And then we were done!

If you’ve ever filmed any kind of scripted video content, you know it wasn’t that simple. We had to learn how to properly set up all our fancy video equipment. After we figured that out, we had to get everything in just the right spot. This took a lot of adjusting. We had to make sure our microphones, lights, and camera angles were in the right place to give us the results we wanted.

Now we press record... and suddenly I can’t remember any of my lines. Remembering what I had to say was much harder than I expected. Once I could finally remember without messing up, I had to say my lines in a bunch of different ways to convey the tone we were going for. I had to make sure to look directly at the camera and smile.

We eventually got enough good takes to wrap up filming. Each of my team members who are featured in the video went through a similar process. Once each of us finished recording, our video team expertly stitched everything together, adding in amazing graphics and effects.

What’s next?

At the end of this process, we were able to release our video to the world! And the results have been amazing!! I'm incredibly proud of our team and I'm glad to see our hard work paying off.

Now we’re working on our next video. We’re already planning ahead for future concepts by gathering ideas and writing scripts. We would love to hear from you if you have any suggestions! Feel free to leave them in the comments below.

Keep an eye out for our next video and in (the most non-cliche way possible) subscribe to the Apollo GraphQL YouTube Channel so you'll know when it drops!! Thanks for reading.

How to Maintain Your Skills as a Developer

Ceora Ford — Thu, 13 May 2021 17:28:13 +0000

It’s no secret that the tech industry is always changing. New frameworks are always emerging and new features are constantly being added to the languages and frameworks that already exist. This can be exciting but sometimes it can be hard to keep up. Some people work in environments that don’t welcome change. Not everyone’s team is looking to implement the latest innovation.

Zachariah, CEO and CTO of SquadCast, had this experience. In episode 3 of the Version One podcast, he talked about an experience he had early on in his career. He was in a position that didn’t allow for much growth. So how was he able to keep his coding skills up to par?

So what I did was I used that time to contribute to open source projects, research, sharpen my skills, [to] kind of stay sharp.

As Zachariah mentioned, there are many things you can do to stay sharp. This post will explain 5 ways you can maintain and grow your coding skills.

Read other people's code

When it comes to getting better at a certain coding language or framework, we usually think that we need to work on some fancy, new project. While that isn't a bad idea, reading other people's code is another very helpful step. Reading other people's code can often be overlooked but it's a great way to familiarize yourself with new and old syntax and to test your ability to understand unfamiliar codebases.

Where can you find projects to read through? A great place to start is GitHub. Check out your favorite open source projects and products. Casually read through the code and see what you can learn. Is there a feature that you're curious about? Try to find out how it was implemented. You can also search for projects by language. If there is a language you want to brush up on, you can check out some of the most popular

Work on top of already existing code

Work on existing projects. You can find your own projects and iterate on them, adding new features or changing the structure of your code. You can also search for open source projects on GitHub. Find a project that's in a language you would like to brush up on and find an issue you can tackle. If you're not quite comfortable with making open source contributions, you can either stick to your own existing projects or read this helpful, step-by-step guide.

Working on existing code is great because it presents new challenges. You have to figure out code that may be deprecated or hard to understand, even if it’s your project. By doing this, you'll train yourself to navigate unfamiliar codebases. This is a very valuable skill to gain since oftentimes in professional settings, you’ll have to add to code that already exists instead of starting something from scratch.

Watch other people code

Watch other people code on platforms like YouTube and Twitch. Through videos and live streams, you can see other developers code and problem solve out loud. You can follow their thought pattern and see how they fix and tackle bugs and other problems in their code. There’s so much you can gain from watching this process. You can learn new syntax, learn how to approach and solve problems, and learn how to implement new features.

Do coding challenges

Try completing coding challenges and exercises. There are tons of websites out there like HackerRank and CodeWars that present problems that you have to solve with your code stack of choice. These challenges are made to be short and to the point while also forcing you to solve complex problems. They’re a great way to stay sharp and keep up with any language.

Read articles about code

There are tons of developer blogs out there. Developer blogs are full of gems. There’s so much you can learn from reading articles. If there’s a topic you want to learn more about, do a quick Google search or search on sites like dev.to for articles that can help.

Reading articles written by other developers is another way to see how other people think and problem solve. As mentioned earlier, this is invaluable and can add to your skills and knowledge. So when you come across an article that covers a topic you’re interested in, take the time to read through it. And make note of any points that stood out to you.

Conclusion

Tech moves fast but even so, growth can sometimes feel stagnant. If you feel like you’re at a standstill, try these tips. By doing these things, you’ll be able to stay sharp and grow your skills. There’s still more you can learn from Zachariah and his journey to becoming a CEO and CTO of SquadCast. Make sure to give his Version One episode a listen to find out more!

How to Make Your First Open Source Contribution

Ceora Ford — Thu, 06 May 2021 16:25:37 +0000

Open source software is a huge part of the tech industry. Over and over, we hear about the power of open source. In episode 2 of The CodeSandbox Podcast, guest Elizabet Oliveira discussed open source and how it has impacted her career. This article will focus on getting you up and running as an open source contributor. Let's start by discussing why you should be interested in getting involved with open source.

Why you should start contributing to open source projects

I think, yes [open source has helped me in my career], because I think it's easier to have interviews... And also I ended up talking in react conf in Las Vegas. And after that, I started talking in other conferences. And so I think it opened a lot of doors.

We don't have an infinite amount of time and I'm sure there are tons of things on your to-do list. So you might be wondering why you should even be thinking about contributing to open source software. Is it really worth the time and effort?

There are many benefits of contributing to open source projects. Assess your career and development goals and you might be able to accomplish them by contributing to open source software. Here's a brief and non-exhaustive list of some of the benefits of getting involved with open source:

Familiarize yourself with Git
Gain experience
Get attention from employers and recruiters
Connect with other developers in the community

Learn Git and GitHub Basics

Before you can go scouting for an open source project to work on, you should know the basics of Git and GitHub. You don't need to be an expert. But there are a few commands you should definitely know and understand:

git init
git clone
git checkout -b
git branch
git add
git commit -m
git merge
git push
git pull

This article won't discuss what these commands do or how they work. This is a checklist for you to measure your understanding. If you are unfamiliar with any of these Git commands, check out this helpful Git cheat sheet. To make sure you understand when and how to use each command, I suggest you create your own project locally using Git and push your project to GitHub. This will help you to become familiar with how Git and GitHub work together. Once you feel comfortable, you can move on to the next step.

Find a project you feel comfortable working on

This step may seem intimidating at first. Sometimes, you see a project that can seem complex or beyond your skill level. Some projects on GitHub are very robust and extensive. Not to mention the sheer number of open source projects on GitHub. How can you find something to work on that interests you and fits your skill level?

There are a few ways to do this. You might have already found an open source product or project that you're interested in. If this is the case check for Issues with the good first issue or first timers only tag. These have been specifically marked for beginners or those with little open source experience. If you don't already have a project in mind, check First Timers Only and the Awesome for Beginners repository for more options. You can also ask other developers that you know or people in the community for suggestions.

Once you find a project, there's still more you need to do to make meaningful contributions to a project. You'll need to know how to communicate when getting involved with a project.

Communication guidelines

First and foremost, make sure that you're being polite and kind when talking to anyone involved with the project. This rule goes for all online communication. It's important to remember that maintainers are busy people and may have multiple responsibilities to tackle at one time. So be patient with them and always communicate respectfully.

Most projects will have communication guidelines specifically outlined for the project. These can usually the found in the README.md or CONTRIBUTING.md file. Make sure to read through the whole document and when the time comes to actually contribute your code to the project, be sure that you're following the structure and guidelines that maintainers have specified.

Aside from reading and following the CONTRIBUTING.md guidelines, here are some general rules that you should try to adhere to when opening up issues, submitting pull requests (both of which will be covered soon), and any other communication between you and others involved in the project:

When you open an issue, be sure to thoroughly describe the bug or problem you've run into. Include information that will help maintainers or others to reproduce the bug locally on their end.
It's also good to provide a possible solution if you have one in mind. This streamlines communication and will help maintainers to quickly determine whether or not your possible contribution fits the direction of the project.
Try including comments in your code. Other people working on the project likely aren't familiar with your coding style or how you think. Including explanatory comments in your code will make your logic clear and thus, others will be able to quickly understand how your code works.

When you have chosen the project you would like to work with and you've read the CONTRIBUTING.md and/or README.md thoroughly, you're ready to actually contribute your code to the project.

Contribute to Your First Project

With your open source project already chosen, there are a few ways you can decide on what you would like to add to the project. You can work on pre-existing issues which can be found under the "Issues" tab on GitHub.

When going through existing issues, you can look for things marked with the good first issue or first timers only tag (as previously mentioned).

If you find an issue that you're interested in, it may be useful to leave a comment on the issue outlining the solution you would like to implement.

You can also create an issue based on a bug you've noticed or a feature you think needs to be improved. Do this by clicking the "New Issue" button.

If you decide to open a new issue, be sure to provide relevant information that will allow maintainers to understand the bug you've run into and/or the feature you would like to add or improve and why. Remember the communication tips that were mentioned earlier.

You can skip creating an issue and just submit a pull request. This will cut out some communication that goes with creating and submitting an issue. This means you can get right to work. But keep in mind that the project maintainer may decide to decline your pull request. So the work you've done may not be used in the end. If this is the route you'd like to go, you can move on to the following steps which will cover the process of submitting a pull request.

Of all the options, I recommend working on a pre-existing issue. Make sure that you follow the guidelines set out by maintainers in the README.md and CONTRIBUTING.md files no matter what route you decide to take.

1. Fork your project of choice

On GitHub, fork the repository you've chosen to work with.

This will create a copy of the project that will be saved under your GitHub account.

2. Clone your fork

To clone the fork you've created, click the "Code" button and copy the URL that's provided.

In your terminal, change into the directory that you want to hold your forked project

cd <directory_name>

Now clone your forked repository using git clone and the URL you just copied

git clone <url>

Change into the folder that was just created. This will likely match the name of the project you forked. So if we're using the Sandpack repo as an example, that would be [sandpack]:

cd <project_name>

3. Create a branch locally

Before you start working, create a separate branch that will hold all the code that you add or edit.

git checkout -b <branch-name>

4. Make your changes

Now you can finally code! You may also be editing copy, fixing grammatical errors, or improving documentation. Whatever changes you're looking to make, you can finally do it at this step!

5. Commit and push your changes

Before you commit and push your changes, make sure to run and test your code. Once your sure that your code is functioning as desired, you can commit and push your changes to GitHub.

git add .
git commit -m 'commit message here'
git push -u origin head

6. Create a pull request

Go to the original project on GitHub and you should see a prompt encouraging you to open a new pull request from the branch you created. Click the "Compare and pull request" button.

Once you do this you will be shown a text editor. Fill this in with all the relevant information needed to understand the work you've just done. When you do this, click the "Create pull request" button.

Once you create your pull request, you'll have to wait on maintainers to respond. If the work you've done is error free and fits the scope and direction of the project, maintainers might merge your work into the project. They may request that you make changes to the work you've done. They might also decide to reject your pull request. If this happens, don't be discouraged. Maintainers will probably have a good reason for doing this and it's likely that will let you know. You can decide to work on another issue in the same project or you can find a new project to work with.

Conclusion

Open source can seem intimidating. But once you dive into it, you'll see how rewarding it can be and you'll quickly reap the benefits. Here's a quick summary of the steps you need to take when you contribute to open source:

Thoroughly read through the README.md and CONTRIBUTING.md
Fork the project repository
Clone the project locally
Create a feature branch for your work
Once you finish make changes, commit and push your work
Open a PR

Once you've done this, you'll officially become an open source contributor! If you'd like to prepare yourself more before getting started or if you want to learn more about open source, here are some resources I found very useful.

Additional Resources

This Month on CodeSandbox - April 2021 Edition

Ceora Ford — Wed, 28 Apr 2021 15:58:13 +0000

Welcome to the first edition of This Month on CodeSandbox. This is a series where I'll be highlighting some of the amazing work being done by people in the community. As you can tell from the title, this will be a monthly series and, typically, the work I share will center around a certain topic or technology. I'll share work from CodeSandbox along with other platforms too. You can also find out what we've been working on so you can keep up to date with the CodeSandbox team.

This edition is all about animation. Animations are great because they can be created with a variety of different technologies like React and Three.js and they can take your design to the next level. Lots of people use CodeSandbox to create and share some really fascinating animations and it’s mind-blowing! Here are a few I've come across that I really loved.

Community Spotlight

Playground by Fabio Ottaviani - This mesmerizing 3D animation was built with Three.js and react-three-fiber. Three.js and react-three-fiber together make building 3D animations in React applications possible. I'm already thinking of ways I want to use this in the future!

Rotating Stars by Twan Mulder - This is the kind of animation that would make a great addition to a portfolio, blog, or even a product site. You can recreate this with just HTML and CSS so it's the perfect way to spice up a project.

Cell Fracture by Paul Henschel - This animation may seem deceptive at first glance. You only see the word "Hello" in simple black text. But click once to see "Hello" burst into colorful pieces. Cell Fracture was built with Three.js.

Around the Web

12HR+ YouTube Coding Bootcamp 2021! by Ania Kubów - This isn't really related to animation. But I just had to share this. Ania created this free, 12-hour coding boot camp, all taught using CodeSandbox. She covers HTML, CSS, and JavaScript through project building.

Your First CSS Animation by Twan Mulder - If you like "Rotating Stars" animation, then you'll really enjoy this article. Twan gives a step-by-step explanation of how to recreate his rotating CSS animation.

A Dive Into React And Three.js Using react-three-fiber by Fortune Ikechi - A few of the projects featured earlier were built using Three.js and react-three-fiber. If you're interested in learning more about these technologies, this is a great place to start.

What We're Up To

These announcements aren't really related to animation. But I'm still very excited to share some of what we've been doing at CodeSandbox.

This month, we launched two new podcasts - Version One and the CodeSandbox Podcast. Version One dives into the product development journey of some really amazing online tools while the CodeSandbox Podcast focuses on members of the community and how they use CodeSandbox.

Episodes for both podcasts are released twice a month. So episodes one and two of Version One and the CodeSandbox Podcast are already available! Find the latest episodes below.

Why Community is Important for Developers

Ceora Ford — Tue, 27 Apr 2021 15:54:36 +0000

There are a plethora of developer communities out there. Countless times, I've been encouraged to join some online or in-person community for developers and I'm sure you have too. After listening to the episode 2 of the Version One podcast, I was reminded of the value of community.

The second episode of the Version One podcast features guest Guillermo Rauch, CEO and Co-founder of Vercel. When discussing how he started coding, Guillermo mentioned an online forum which played a huge part in his growth as a developer. As Guillermo's experience demonstrates, community can be a huge catalyst for growth as a developer. By why is that the case? And where can you find said communities?

Why you need to invest in community

Coding isn't always an easy task. There are multiple hurdles that many people confront along their developer journey. Running into difficult errors, dealing with difficult coding concepts, job searching, career growth- the list could go on forever. It becomes so much easier to deal with these things when you have a helpful community to lean on.

I started finding different communities that were helping me figure things out. And that also, whenever I would figure something out, I would contribute back, too.

When you find a community that fits your interests and career goals, you'll have a place where you can turn to ask questions and get advice from developers all over the world. You can also share your own insights and help others along the way. As time goes on, your developer network will continue to grow and you'll become a better developer. This is why it's so important to invest in community, no matter what skill level you're at.

Where to find the right community for you

Now that you know community is so valuable, it's time to actually find one for yourself. You don't need to be part of every single one you come across. That can easily become overwhelming. Focus on actively participating in just a few.

If it's safe to do so in the area where you live, you can look around for local meetups and communities. Check websites like Meetup and search for groups using keywords that are related to whatever language or technology you would like to be more involved with.

Thankfully, we have social media and platforms like Discord and Slack which enable remote community building. Twitter is a developer hot spot. It's a great place to go to share what you're working on and learning and to ask and answer questions. It's good to know, though, that Twitter isn't always a safe space. But it still holds a ton of value.

To find Discord and Slack communities, search "[insert language or tech stack of interest] communities on Discord/Slack" on Google. It also helps to ask developers you already know for recommendations. When you find a community that matches your interests, keep an eye out for active moderators and a Code of Conduct. Both of these things ensure the safety of community members. Of course, this isn't absolute and people with bad intentions may still slip in. But having moderators and a Code of Conduct that is heavily promoted means that your online safety is being prioritized and that's very important.

Conclusion

It's clear that being part of a community can do wonders for your growth as a developer. Searching for, joining, and participating in developer communities online or in-person (if it's safe) will be well worth the effort and time you invest. Guillermo's podcast episode reminded me of this. There's much more to learn from his journey to becoming a startup founder. So make sure to give his Version One interview a listen.

A Beginners Guide to Project Building

Ceora Ford — Mon, 19 Apr 2021 17:15:16 +0000

Building projects is a great way to learn and grow as a developer. There are always new skills to learn and we also need to maintain the skills we already have. Project building is a great way to do that.

We recently got to chat with Charlie Gerard, senior front end developer of Netlify, about project building on the CodeSandbox Podcast and it got me thinking. Many of us probably have a long running list of projects we want to start or have started and never finished. It’s pretty common for developers to have several domain names without any finished project to use them on. How can you start to tackle this problem? How do you actually start and finish projects?

This article will answer those very questions. If you want to know what steps you can take to successfully start and finish projects, keep reading!

Establish a goal

Before starting, you should establish what your main objective is. What do you want to accomplish with your project? Try to be as specific as possible, including what languages or frameworks you want to build with and what new things you would like to learn. Here’s an example of a great project goal: "Build a gif search engine with JavaScript using the GIPHY API".

Make a game plan

Now that you have your project goal in place, you have to make a plan.

" Once I have my question and I know what I want to prove, then I can break down the project into small chunks that are doable in my schedule."

Break your project down into small, actionable steps. Again, try to be as specific as possible.

I typically create a Notion document for each project I build. I create a checklist of all the steps I think I need to take to complete my project. Of course, the scope of your project may change over time. So adjust your game plan as needed.

Having a clear cut plan in place will make project building go smoothly for you.

Start small and iterate over time

The size of your project will depend on what your main objective is. After creating your project plan, you might realize that your project will be a big undertaking. This can be intimidating. To overcome this, you should try starting small and iterating over time.

Think about what your MVP or minimum viable product is. What is the most basic form of your project? Aim to create your MVP first and iterate on your project over time. You can include possible iterations and improvements in your project game plan.

Celebrate small wins

Progress can sometimes feel slow, especially with larger projects. At this point, you should have small actionable steps in place to help move things along. Each step that you complete is worthy of celebration!

Try sharing your progress with others. Twitter is a great place for this. When you complete a step in your game plan, take time to reflect on what you’ve learned and how you’ve improved. You can take this and write articles, Twitter threads, or even make video content to share with others.

Adjust project scope if needed

This was a point Charlie made in her podcast episode and I think this is a step we often overlook.

"Maybe I pause that project and then I know that I'll get back to it later when I have more knowledge or when I re-frame the question in a way that it can actually be achieved. So to me, that's my way of finishing things."

It's okay to adjust the scope of your project. Learning that your project goal was too ambitious or having a busy schedule that doesn't allow for lots of project building is completely normal. It's an inevitable part of being a developer who builds side projects.

If you run into an issue like this, your first inclination may be to just abandon your project. But that isn't always necessary. This might be an opportunity for you to adjust the scope of your project. Go back to your plan and see where you can make some changes. Making project goals smaller or cutting your plan short can be helpful at this stage. This can be upsetting at first but there will always be time and opportunities in the future. Time and more experience may be what you need to move your project ahead so adjusting your project scope to allow for this isn't a failure by any means.

Conclusion

Project based learning is one of the best ways to keep sharp as a developer. But it's also important to know how to finish the projects that you start. So remember these 5 points:

Establish a goal
Make a game plan
Start small and iterate over time
Celebrate small wins
Adjust project scope if needed

This is just a portion of the helpful insights Charlie shared on the CodeSandbox Podcast. Make sure to give her interview a listen and learn more about the awesome work she does.

What I Learned From Bombing My Technical Interview

Ceora Ford — Thu, 12 Nov 2020 14:21:42 +0000

So... I embarrassingly bombed a technical interview yesterday. It was... BAD. In all honesty, this interview had the potential to be great. Both people interviewing me were very calm and kind. And I had the opportunity to show off my own project and add a new feature to it. If you've ever done a technical interview before, you know this is one of the best case scenarios (aside from no technical interview at all). And yet, I totally blew it.

I rambled A LOT. I forgot key terminology. When I was adding a new feature to my web app, I forgot key steps and I explained what I was doing poorly. I ended up ending the interview early because I was getting so stressed out and nervous.

This was a position I really wanted. I was really disappointed in myself and I felt like trash to be completely honest. I was kind of thinking about switching professions for a minute too😂

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

But, I want to look back on this experience and point out some of things I could have done better and will do better next time. So if you have a technical interview coming up, this one's for you!

1. GET ENOUGH SLEEP THE NIGHT BEFORE

This is number one for a reason. I pretty much pulled an all nighter the night before. I was practicing what I was going to say, preparing for an upcoming workshop I'm hosting, and watching Marvel movies. Basically, a recipe for disaster.

I thought I was in high school again when I used to pull all nighters and take a test the next morning and still get a near perfect score. My brain doesn't work like that anymore. So I will never be doing that again. I'm convinced this is the main reason why my explanations were all over the place and pretty much nonsensical.

So make sure you get enough sleep before your interview! In my case, I probably would have been better off sleeping than practicing like I had done. Without sleep, all that practice was pretty much useless.

2. Do a mock interview with a friend

I'm a huge believer in mock interviews. I've done one for almost every technical interview I've had... except for this one. I'm positive that walking through my code with a trusted friend or colleague would have helped me immensely.

I wasn't sure what feature I should build to impress the interviewers so I was really scattered. I was jumping between two features and I'm sure that didn't look good. If I had practiced with a mock interview, I would've asked for feedback and seen what feature I should have implemented during the interview. A mock interview also would have helped me to fine tune my explanations. So yes, next time I will be doing a mock interview with someone.

3. Take notes before the interview

The more I think about this interview, the more I realize how chaotic my brain was at the time (see point number one). Now that I think about it, it's actually kind of funny. Just a few minutes before the interview started, I thought it might be a good idea to write down the steps I needed to follow to add my desired feature. This was a good idea I think except I wrote them on sticky notes and the sticky notes somehow got scattered out of order all over my desk. Can you feel the chaos??

This obviously made things worse for me since I got so flustered that I completely blanked on what I was supposed to be doing. And the sticky notes were all over the place and I couldn't get them back in order. Now I know that it's probably best to either write them down on a sheet of paper or type the steps out in a markdown file.

4. Talk a LOT

This usually isn't very hard for me because I'm a naturally talkative person and I actually enjoy talking through my code. This time was different though. I couldn't get my thoughts straight (again, see number one) and I had a lot of awkward pauses. For technical interviews, it's best to just voice you're thoughts even if you're not exactly sure what's going on.

5. Use tons of pseudocode

Again, this is something I LOVE to do. Using pseudocode helps me to get my thought process straight and point out flawed logic quickly. It's also a great way to show your interviewer how you think and approach problems. I didn't use pseudocode enough during this interview but I'll make sure to utilize this technique during my next one.

6. Don't drink coffee before the interview!

Disclaimer: this is purely my personal preference so please feel free to disregard this completely This is something that might surprise you. But I tend to get a little jittery whenever I drink coffee. So whenever I have to do something that's nerve racking, I make sure to avoid coffee at all cost. I did not do that for this interview. I drank coffee because I hadn't slept and I thought it would help. But it just made me super jumpy and of course, I got the jitters. This made me more nervous and that made me panic. So yeah, as you can imagine, it was a disaster. Note to self: don't drink coffee before an interview.

7. Don’t put too much pressure on yourself

This one is hard. Most of us need to work and if you’re out of work, that makes any job interview very high pressure. For me, I really, really wanted this job. I was excited about the role and the people I would get to work with. So I put a lot of pressure on myself to impress and perform well. But all that pressure made me do the opposite. This is a tough one to follow but I’m going to try not to do this next time. I’m still figuring out how to get pass this reaction I have to any opportunity I’m excited about. If you have any tips, please share!!

As you can see, a lot of my mistakes stemmed from lack of sleep. I'm not going to say that I'm the best at technical interviews. But I've never performed like this. There are some things I know how to do well and I just didn't do them this time around. And I'm 100% positive it's because I didn't get enough sleep. So if there's one thing you take away from this, it should be this: Sleep is very important! So please try to get enough rest before your interview!!

Now, to be clear, I'm not writing this article to overly criticize myself. Thinking about what happened still stings but I'm done beating myself up about it. I'm sure I'll think about this some day and laugh. But I'm writing this now to learn from the situation and maybe even help someone else! So please learn from my mistakes!

Lots of lovely people have been kind enough to give me some technical interview tips. I plan on putting all those together in a more comprehensive blog post! So stay tuned for that. Feel free to leave any tips you have in the comments! You can also share your own interview horror stories if you like😆 Thanks for reading!

Wait... Serverless Isn't Actually Serverless?

Ceora Ford — Fri, 30 Oct 2020 08:54:27 +0000

Before we get into the topic of this article, I want to tell a little story. I started learning more about cloud engineering and AWS a few months ago. I had finally wrapped my head around what cloud actually was. Then I was introduced to this concept of serverless computing and... I was thoroughly confused to say the least.

// Detect dark theme var iframe = document.getElementById('tweet-1296188715417636866-284'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1296188715417636866&theme=dark" }
I finally started to understand some AWS foundational concepts and resources and now I was learning about serverless. This absolutely threw me for a loop. You might relate to how I felt a few months ago. If so, this post is just for you.

I'm going to break down what serverless computing actually is. I'll also point out some essential AWS serverless resources to know. But to understand serverless computing, it's good to first understand cloud computing. So let's begin by first establishing what cloud computing is.

What is cloud computing?

Your code needs to be hosted on a server. Depending on the size of your code and the amount of users you expect to use your product or website, you might need many servers. Companies used to have their own facilities and warehouses that held their servers and many still do. But for many, this is not ideal.

Servers can be difficult to maintain. I'm not sure about you but sometimes when I have a lot of tabs open and lots of apps running on my laptop, my laptop starts to act a little funny. Sometimes if I'm using my computer on my bed where vents are blocked by blankets, my computer starts to act strange. You’ve probably experienced the same thing before. Something similar happens with servers too.

Servers may begin to malfunction when there is lots of code running and many users accessing that code. Servers are also affected by changing temperatures. Maintaining servers and the buildings that house them can become expensive too. Over time, these issues can become hard to manage. That's where AWS and other cloud providers come in.

Cloud computing is basically renting out servers and data storage that's owned by someone else. With AWS, that means using servers owned by Amazon. This cuts out the need to buy and maintain physical servers. The issues I mentioned earlier are no longer a problem. AWS offers more than storage which is obvious as their list of services seems to never end. Through AWS, you gain access to resources like storage services, servers, networking, analytics, AI, and more.

Aside from the wealth of resources cloud computing allows you to access, there are many other benefits:

You pay only for what you use. This can be very cost effective.
You can easily spin up and use new servers when needed, allowing you to scale quickly.
You can deploy applications globally.
All of this leads to quicker development and deployment.

Cloud computing might seem great and it is (for the most part). So where does serverless computing come in? And why is it necessary? What even is it? Let's start there first.

What is Serverless?

With cloud computing, you don't have to worry about server maintenance. But you can decide what type of server to deploy, how much computing power you'll require, how many servers you want, and much more. You don't own the servers but you still have a lot of control over them.

Serverless takes cloud computing to the next level. You don't have to worry about the servers at all. Here's one key thing to remember: serverless does not mean there aren't any servers. Check the meme I shared in the intro for a reminder. You still need servers to host and run your code. With serverless computing, you let go of the responsibilities and control you have with cloud computing. This means that you can completely focus on your code without having to configure your servers to meet your needs.

This is really powerful! You don't have to learn any infrastructure to deploy code using serveless computing. All your time can be spent focusing on your code and you still get many of the benefits of cloud computing. Serverless can be very low cost and it's super easy to scale up or down with serverless. Of course, like everything, there are some drawbacks to going the serverless route. It may not be the best option for you depending on what your needs are. But we won't get into that right now. (Maybe in a future edition of Learn AWS With Me?)

At this point, you now know what past me struggled with! You know the difference between cloud computing and serverless computing. You also know that serverless isn't actually serverless. Now, let's cover some of the serverless resources AWS has to offer.

AWS Serverless Resources You Should Know

AWS has a lot to offer. So, as you can imagine, there are a lot of serverless resources available. I'll point you to the ones I use the most and the ones you might be interested in too!

Lambda AWS Lambda is super useful! This service allows you to run serverless functions. You only pay for the time your code runs. I've used AWS Lambda to run Twitter bots. There are tons of things you can do with AWS Lambda.
S3 S3 stands for Simple Storage Service. S3 offers you simple, secure storage. This is a great resource to play around with. Try hosting a static site with S3. This was my first AWS project and it's a great place to start!
DynamoDB Amazon DynamoDB is a noSQL database service. I haven't gotten to work with DynamoDB (yet). But this What is DynamoDB? article from the DynamoDB guide site is a great place to learn from!
SNS SNS stands for Simple Notification Service. This service allows you to automatically send emails or text messages based on certain occurrences within your AWS account. We used SNS in the Never Get an Unexpected AWS Bill Again! lesson. If you want to get a better idea of how SNS works, follow along with the lesson and create your own billing alarm.

If you want to experiment with some of these resources, check out this article with 3 serverless projects you can start working on.

Conclusion

To sum all this up, no, serverless is not actually serverless. Now that I understand what serverless is, I find it really fascinating! I'm now able to utilize serverless resources offered by AWS and other companies and it honestly makes my life so much easier (most of the time😂). With this new knowledge, you can jump into building and deploying amazing things! If you do, make sure to share with me!

If there's an AWS topic you'd like me to cover, feel free to let me know in the comments below! Thanks for reading!!

How I Learned JAMStack

Ceora Ford — Tue, 20 Oct 2020 15:03:07 +0000

In July, I was asked to participate in a panel for GraphQL Summit and talk about JAMStack. I was so hype and excited!! I was going to have the opportunity to talk with some really cool people at a really cool conference. But there was 1 problem. I didn't know much of anything about JAMStack.

HOW WAS I SUPPOSED TO LEARN JAMSTACK IN ENOUGH TIME TO TALK ABOUT IT AT A CONFERENCE WITH EXPERTS???????

Well there were a couple things I did so that I could hold my own in the conversation. Here's a quick run down of the resources I used and things I did to learn JAMStack fast.

1. I read a few articles

These are all of the articles I read to get a good idea of what JAMStack actually was.

Because I had a time constraint, I couldn't spend a whole lot of time compiling a bunch of articles to read and study. This forced me to stick to a small number of articles which was actually a good thing. No matter what you decide to learn, don't bog yourself down with a gigantic list of resources. Doing that usually prolongs getting your hands dirty and building stuff.

2. I watched the freeCodeCamp JAMstack course on YouTube

I admittedly didn't watch the whole thing. But I watched just enough to get me started with Eleventy. Phil Hawthorne explains things really clearly and despite being experienced, I think he also breaks things down in a beginner-friendly way. He makes sure to explain some of the terms that are unfamiliar to those new to JAMstack.

The only thing about this video is that it's really long. But there are time stamps in the video description so you can jump around if you want to. And you can always pause and pick up where you left off later. Or you can be like me and just not finish it. Whatever works best for you!

3. I built projects

Or I should say, I started projects. If you watch the panel, you'll notice that I specically mentioned two projects I started: my blog and dayintheline.dev. I didn't have enough time to actually finish either of them before the panel.

My blog is done now (obviously) and I'm still working on dayinthelife.dev. Building a project allowed me to explore some of the different static site generators out there. (Eleventy is my favorite if you care.) I got to see how JAMstack works after learning what it is. Having this experience helped me to talk about JAMstack like I kind of knew what I was doing.

What you can take away from this

You might be reading this if you're interested in learning JAMstack. But I think my experience can be applied to any tech stack or coding language. There are a few things I did right in this situation that you can apply to almost any discipline:

I stuck to a handful of resources and didn't get caught up in hoarding articles, courses, videos, and everything else out there
I built something with what I learned
I talked about what I learned (aka practiced learning in public)

That last part might seem intimidating since I was on a conference panel. To be quite honest, it was EXTREMELY intimidating for me. But speaking at a conference isn't the only form of learning in public. You can stream on Twitch. You can write articles. You can make videos. You can even talk to a family member or friend about what you've learned and built! Just take the opportunity to teach someone else what you've learned!

Never Get an Unexpected AWS Bill Again!

Ceora Ford — Tue, 08 Sep 2020 16:37:41 +0000

One of the things that prevents a lot of people from exploring AWS is the cost. Some AWS services are very expensive. Accidentally forgetting to cut something off and getting charged is the worst feeling. Trust me, I know.

Is this an irrational fear? Is this something people think of just as an excuse for not getting started? Absolutely not. This is definitely, 1000% a valid fear. I'm sure most people involved with AWS have a horror story about getting charged unexpectedly. The great thing is that there are steps you can take to prevent this from happening. For the first installation of Learn AWS With Me, I'm going to cover 3 things you can do to make sure you don't get billed unexpectedly.

1. Cut Things Off IMMEDIATELY

This might seem really obvious but I mean it. Seriously. This is something you should get into the habit of doing early. If you're just practicing and you want to make sure you know how to navigate the AWS console, make sure to undo your work immediately!! Did you just spin up an EC2 instance? Great!! SHUT IT DOWN!! You just figured out how to use RDS? Amazing! Shut. It. DOWN!!!!!

Not all AWS services are expensive. AWS Lambda is one example. Leaving a practice lambda running won't cost you a whole lot. But this definitely isn't always the case. I mentioned EC2 and RDS earlier because I know from experience that those two can be VERY expensive. So, again, MAKE SURE TO SHUT THINGS DOWN ONCE YOU FINISH PRACTICING.

2. Set Up Billing Alerts

Did you know that you can set up billing alerts on AWS? I didn't learn this until it was too late (more on that later). Setting up a billing alert can save you sooo much pain, heartache, and most importantly, money. Follow these steps to set up billing alerts right now!

In the AWS management console, search for a service called CloudWatch
On the left hand corner of the CloudWatch dashboard, click Billing
Click Create Alarm
For Step 1, we have to track a metric. We want this alarm to track EstimatedCharges as our metric. Set the currency to whatever fits your location.
At the bottom of the page, you can define your price limit. You can set the limit to 0 if you don't want to go past the free tier limits. After you've defined your price limit, click Next
For Step 2, define what kind of notification you want to receive. You should set this to In Alarm
For Select an SNS topic click Create new topic.
You can SNS topic whatever you like. I chose, 'toomuchmoney'. Now set it to whatever email you want the notifications to be sent to. Click Create Topic.
Click Next on the bottom right-hand corner.
For Step 3, choose alarm name next. You can give this the same name as your topic if you like. You can also add a description for this alarm if you want to.
Step 4 is just previewing what you've already done. If everything looks good, you can finish things off by clicking Create alarm

Now you have an alarm that will tell you whenever you get close to passing your price threshold.

3. Open a Support Case

What if you're past the point of no return? What if you already got the email from AWS telling how much you'll be charged? Does it sound like this is something I'm remembering? Well, that's because this happened to me recently and I was devastated. Thankfully, there is something you can do to fix this.

You can open up a support case! How?

Click on the Support button in the top right hand corner and choose Support Center. You can also search for support in the AWS Management Console.
Click Create Case and click Account and billing support
Fill out the details that best fits your situation.

It's important to keep in mind that you don't want to take advantage of this method too often. I've only had to submit a support case once and someone from the AWS support team got back to me within a few days and waived my bill. But I have heard that they aren't always so forgiving after the first time. So don't rely on this feature too much. It might not turn out well for you all the time.

Conclusion

AWS can be expensive. But I don't want that to stop you from learning how to use some of the services AWS has to offer. If you follow some of the advice outlined in this post, you can be sure that unexpected costs won't be something you have to struggle with. And if you slip up, you can always try option 3. Look out for the next Learn AWS With Me post coming soon! If you want to be notified when that drops, follow me here. And of course, if you have any requests, leave them in the comments below. Thanks for reading!