Forem: Gerard Hynes

Resources for Learning Scala

Gerard Hynes — Thu, 07 Apr 2022 16:27:57 +0000

Recently, I've been learning Scala and when I first searched for resources for learners I was a bit worried by how few came up, and how many of them weren't very good. There were barely any YouTube tutorials, many of the blog posts were years old, and some of the conference talks required way more Mathematics than I had.

Compared to languages like JavaScript or Python, or even Java, Scala is much more niche, with far less material for beginners. It also has its own quirks and a steeper learning-curve than some other programming languages, but Scala is definitely worth learning, and there are good resources out there.

Why learn Scala?

A multi-paradigm language, Scala combines features of both object-oriented and functional programming. It runs on the Java Virtual Machine (JVM), and so can be used anywhere Java can run (it can even use Java libraries), but has a much more concise and “human readable” syntax.

It's statically typed, so you'll catch more errors before you ship your code, and most of the time the compiler will infer the types for you so you don't need type annotations everywhere.

Scala is especially used for high-performance distributed systems and large-scale data processing. Scala powers Twitter, DisneyPlus and The Guardian. Netflix, Spotify, and Amazon all use it for data analytics.

If you want to learn Scala, here are some resources that I've found helpful. None of these links are affiliates, they're just resources that helped me on my learning journey.

Video Resources

Scala at Light Speed

Link: https://youtu.be/-8V6bMjThNo

A two hour crash course introduction to the language by Daniel Ciocîrlan from RocktheJVM that will give you a feel for whether you want to dive deeper into Scala. It does assume you have some familiarity with languages like Java, but Daniel's explanations are clear and the short course will quickly give you a good overview of the language, from the basic syntax to futures, pattern matching and higher order functions. From there, Daniel has many more videos on more advanced features of Scala, as well as tools and libraries like Akka, Cats and Doobie.

Effective Programming in Scala

Link: https://www.coursera.org/learn/effective-scala

If you'd like a more thorough course with a college-semester like structure, this is a good option. Provided by the École Polytechnique Fédérale de Lausanne (which operates the Scala Center open source foundation), this Coursera course regularly opens for new enrollments and doesn't cost anything to audit. The lectures are clear and concise, explaining concepts in bite-sized stages. While the assignments can be a bit of a jump compared to the lecture content, the regular quizzes will help you retain what you're learning.

The course uses Scala 3 (which is still very new) but the instructors give examples in Scala 2 where the syntax is different. The course also forms the first part of Coursera's Functional Programming in Scala Specialization, so if you want to take your learning further, there's a clear curriculum ahead of you.

Written Resources

The Official Scala Docs

Link: https://docs.scala-lang.org/

The official documentation for languages isn't always accessible for learners, but the Scala docs are genuinely great: detailed, well-designed and written in pretty accessible language. The Scala Book provides a friendly introduction and overview of the language in about 50 lessons.

Daniela Sfregola, Get Programming with Scala

Link: https://www.manning.com/books/get-programming-with-scala

Too many Scala resources assume two things: that you are already an experienced Java developer and that you are comfortable with university-level mathematics. Daniela Sfregola's excellent book assumes neither. It's written in a very accessible style with short chapters, exercises and projects to practice what you're learning. It's also very comprehensive, covering everything from getting started with sbt, the Scala build tool, and going over object-oriented and functional programming, to setting up a HTTP server, handling concurrency, serializing JSON and testing with ScalaTest.

This Week in Scala

Link: https://medium.com/disney-streaming/tagged/scala

This newsletter by Petr Zapletal, Principal Engineer at Disney Streaming, aims to share the latest news from the world of Scala. While it does recommend learning resources, it's mostly a handy way to keep an eye on developments in the Scala ecosystem and learn about how the language is used in industry.

Practice

Exercism

Link: https://exercism.org/tracks/scala

There aren't a lot of resources that let you practice your Scala skills with exercises, which makes Exercism's Scala track particularly valuable. There are more than 90 challenges, which you solve locally, run tests on, and push your solutions to Exercism to share with other learners. The difficulty levels ramps up quite quickly from “Hello World” to solving tricky mathematical problems by making use of the ins and outs of the language.

The ability to look at solutions by other learners is especially helpful, often revealing a much simpler or more efficient solution than the one you came up with. I haven't used their volunteer mentoring feature yet but the opportunity to give and receive one-on-one feedback sounds really promising.

Forums

Scala Users

Link: https://users.scala-lang.org/

The official Scala forum. It's mostly used by experienced Scala developers but I've found the community to be generally quite friendly and willing to answer questions from learners.

Scala Subreddit

Link: https://www.reddit.com/r/scala/

As with any subreddit, this can have its share of strong opinions and arguments about things that really aren't important, but you can also find useful recommendations and sometimes answers to your very specific problems.

If you're learning Scala, good luck and I hope you find these resources helpful.

How To Overcome CORS with Serverless Functions

Gerard Hynes — Wed, 01 Sep 2021 14:41:21 +0000

The Problem

Recently I was working on a Frontend Mentor challenge, an app where you can input an IP address or url and fetch and display information about it.

Things were going well. I got the layout sorted, I set up a custom map using React Leaflet and Mapbox.

When it was time to fetch the data from the API, however, I ran into problems.

Frontend Mentor had suggested using the IP Geolocation API by IPify to get information based off an IP address or domain.

If you sign up for a free account with IPify and paste https://geo.ipify.org/api/v1?apiKey=YOUR_API_KEY into your url bar, it'll send back JSON with information about your IP address, your location, and your ISP provider.

But if you try to make a HTTP request to this API from your client-side code, you'll get a message about CORS.

What is CORS?

CORS (Cross Origin Resource Sharing) is a mechanism that uses HTTP headers to give a browser permission to access resources from a server that's different from the server of the website making the request.

It exists for a very good reason: security. You don't want some random website to be able to ping your server and get sensitive data from it. To prevent this, browsers restrict cross-origin HTTP requests initiated from client-side scripts by default.

You need to specify which urls can access data from your server by making sure the correct CORS headers get sent with each request. But you can't just change the CORS settings on someone else's server because that would defeat the whole point of CORS as a security layer.

CORS Proxies

The solution that most resources recommended is to use a proxy, another server that will receive the request from your browser, pass it on to the server you're trying to access, and then pass that server's response back to you. This way the entire request response process occurs server-side and isn't subject to CORS.

There are a number of CORS proxies you can use, such as crossorigin.me or CORS Anywhere.

But I didn't want to rely on a third-party proxy. After all, they can see all the data that you pass to them and could stop working at any time. I also didn't want to run and manage my own Node app just to act as a proxy.

While doing some research, I came across a blog post by Jim Nielsen about setting up a CORS proxy with Netlify that promised to solve CORS issues using Netlify redirects without having to run your own proxy server or rely on some random one.

Redirects

Using redirect rules to proxy to an external service is something that Netlify actively supports. For example, you can set things up so that any requests to /api/search will be redirected to https://api.example.com/search. The Netlify docs explain how to do it.

You can set redirect rules in a _redirects file:

/api/*  https://api.example.com/:splat  200

Or you can include them in your netlify.toml file which sets the configuration for your entire app on Netlify.

[[redirects]]
  from = "/api/*"
  to = "https://api.example.com/:splat"
  status = 200
  force = true

If you want to test this out locally before deploying it, Netlify Dev lets you run Netlify locally on your machine.

Armed with this information, I added the redirects rules to my netlify.toml file, ran the netlify dev command and it worked!

Relieved to be making progress, I deployed the app to Netlify... and ran into a new issue.

Everything worked locally but once the app was deployed I kept getting a 502 Bad Gateway response, meaning that the proxy server received an invalid response from the server it was proxying to.

Netlify have really great Support Forums and the good people there pointed me to potential solutions - setting specific headers on my redirects, checking for differences between my local environment and the build environment on Netlify. But none of this made a difference.

A Netlify engineer was able to confirm that the problem was that the API was not responding to the request within 30 seconds. For proxy rewrites, Netlify closes the connection in 30 seconds and since the request wasn't complete by then, it returns a 502. They suggested I move my code into a serverless function and see if that would resolve the issue.

Solution - Serverless Functions

Serverless functions let you write server-side code that can work like an API endpoint, run automatically in response to events, or process complex jobs in the background, all without managing your own server.

Netlify Functions make setting up and running serverless functions pretty straightforward.

You create a functions directory in the root of your project and, inside that, a javascript file with the name of your function.

base-directory/
|- package.json
|- node_modules
|- functions/
   hello.js

In the function's file, you export an async handler function which returns a status code and a body. These functions can carry out tasks such as fetching data from an API, sending automated emails, or validating user input, before sending back a response.

exports.handler = async (event, context) => {
  return { statusCode: 200, body: JSON.stringify({ message: "Hello World" }) };
};

By default, to call a serverless function you make a request to .netlify/functions/your-serverless-function. But you can also use redirects in your netlify.toml to make this more concise.

[build]
  functions = "functions"

[[redirects]]
  from = "/api/*"
  to = "/.netlify/functions/:splat"
  status = 200

Now, requests to /api/hello will be the same as .netlify/functions/hello.

Customizing Requests

I moved the API request into a serverless function, ran Netlify Dev, and was immediately able to get back IP information.

But for this particular project, I needed to be able to vary the requests I sent to the API.

A request to https://geo.ipify.org/api/v1?apiKey=YOUR_API_KEY will send back information about the IP address that sent the request.

On the other hand, a request to https://geo.ipify.org/api/v1?apiKey=YOUR_API_KEY&ipAddress=SOME_IP_ADDRESS will return information about the specified IP address.

And finally, a request to https://geo.ipify.org/api/v1?apiKey=YOUR_API_KEY&domain=SOME_DOMAIN will return information about that domain.

But how was I going to pass this data to the serverless function?

Well, thankfully, Ben Hong has a helpful tutorial on customizing the request with serverless functions.

Basically, I used fetch to make a POST request to the serverless function, passing the search input's value as the body of the request.

// App.js
const res = await fetch(`/api/getIpInfo`, {
  method: "POST",
  body: JSON.stringify({
    searchTerm: ipAddress,
  }),
});
const ipInfo = await res.json();

Then in the serverless function, I extracted the search term from the body, used validator.js to check if it was an IP address or domain, and appended it to the API endpoint.

// getIpInfo.js
const fetch = require("node-fetch");
const validator = require("validator");

exports.handler = async (event, context) => {
  const eventBody = JSON.parse(event.body);

  // Check for IP Address or domain
  let extension = "";
  if (eventBody.searchTerm) {
    const { searchTerm } = eventBody;
    if (validator.isIP(searchTerm)) {
      extension = `&ipAddress=${searchTerm}`;
    } else if (validator.isURL(searchTerm)) {
      const domain = new URL(searchTerm);
      extension = `&domain=${domain.hostname}`;
    }
  }

  try {
    const res = await fetch(`${API_ENDPOINT}${extension}`);
    const data = await res.json();
    return { statusCode: 200, body: JSON.stringify({ data }) };
  } catch (error) {
    console.log(error);
    return {
      statusCode: 500,
      body: JSON.stringify({ error: "Failed fetching data" }),
    };
  }
};

Success! Thanks to serverless functions, my app can now make requests to the IP Geolocation API from the browser without running into any CORS issues.

Try It Yourself

If you are running into CORS issues when making HTTP requests from the browser, try proxying via redirects and, if that doesn't work for you, there's never been a better time to learn about serverless functions.

Ben Hong's Up and Running with Serverless Functions is a great place to get started.

The code for my project is available on GitHub. You can also try out the deployed app.

Further Resources

Ania Kubów, Create your first Netlify Serverless Function! - YouTube
Ben Hong, Up and Running with Serverless Functions - Jamstack Explorers
Cross-Origin Resource Sharing (CORS) - MDN Web Docs
Jim Nielsen, Setup a CORS Proxy With Netlify - jim-nielsen.com
Phil Hawksworth, Exploring Netlify Redirects - Jamstack Explorers

How to Get Unstuck When Following a Programming Tutorial

Gerard Hynes — Thu, 29 Jul 2021 15:14:38 +0000

You know the feeling, right? You're following a programming tutorial, pouring new knowledge and skills into your head. Life is good. And then, suddenly, it's not.

Something breaks. Your screen is covered in a less-than-helpful error message, your terminal is printing warnings about things you've never heard of, and your code has fallen over in a heap.

Even with the most well-paced and clear tutorials, you will get stuck. I still do, all the time.

It's frustrating, but it's not the end of the world. It might not feel like it, but it can be a great opportunity to learn.

With experience, I've gotten better at getting unstuck, and I'd like to share a few methods I've collected for pushing through these challenges and getting back on track.

Read, Search, Ask

I've learned debugging tips from a wide range of sources but the foundation of my process for getting unstuck comes from freeCodeCamp's Read, Search, Ask methodology.

When you get stuck, their advice is to:

Read the documentation or error
Search Google
Ask your friends for help

This is a good strategy for three reasons:

It will minimize the amount of time you spend stuck,
It will maximize your chance of learning from the problem,
It will help you to be respectful of other people's time when you ask them for help.

This is still the core of my process for getting unstuck but I want to expand on what exactly I do when I Read, Search and Ask.

1. Read

Read the Error Message

Is there an error message yelling at you? Great! It might not seem it, but error messages are there to help you. It would be worse if your code just failed silently and left you none the wiser.

Yes, sometimes error messages will be totally unhelpful, giving you no more information than "something went wrong". But other times the error message will point you on your way. If you see TypeError: Cannot read property ‘length’ of undefined, check the variable that's showing up as undefined.

Look at the filename and line number and see what's going on there. But, bear in mind, where your code crashed is where the error happened, not necessarily where the problem was first introduced. Maybe the error happened in your getUsers() function, but the problem started in a checkAuthentication() function that then called getUsers(). Follow the call stack and see how far you can get.

If the error message contains things you don't understand, don't panic, that's when you turn to Google (more on this below).

Read Your Code

Sometimes it feels like 90% of bugs are caused by one character being wrong; a typo in a variable or function name, a missing closing parentheses or bracket. Look for these. Extensions like Bracket Pair Colorizer can make this easier to spot.

If the code you can see looks ok, try to surface the values that aren't immediately visible. Maybe a value is updating in the UI but isn't getting saved to the database. Drop a console.log() into both your frontend and backend code. If the value changed, or failed to change, at some point, work backwards and try to find where the disconnect happened.

Read the Instructor's Code

It's always helpful when an instructor provides a GitHub repo or includes downloadable files. If you have this, open it up and start comparing your code and theirs.

Download their code and open it in your editor. Sometimes seeing their code with the same syntax highlighting as yours can help to make the differences stand out. Diffchecker is also useful when you're comparing two versions of the same code line by line.

Narrow down the amount of code you need to read. Comment out all the code you just wrote. Uncomment it step by step and see when it breaks again. If you're working with components, comment out every component and gradually reintroduce them. Maybe it was the Header rather than the RegistrationForm that was causing the problem.

Read the Documentation

When you're learning a technology for the first time, going from a tutorial to the docs can feel like diving into the deep end. Not all docs are well written or organized. Not all docs have good search functionality. But this is where a lot of your learning will happen.

Reading the docs forces you to try to understand the technology you're using rather than just passively copying the tutorial. This is harder but also much more beneficial.

The docs are a lifesaver when the syntax or the API has changed since the tutorial was created. You could have banged your head on the keyboard for hours but it turns out that you just need to change if (process.browser) to if (typeof window !== "undefined").

Check which version of a library or framework the tutorial was using. If version 3.0 has replaced version 2.0, look for a migration guide to help you get your code up to date. Now you'll not just have a working project again, but you'll have a better understanding of the underlying tools and technologies.

2. Search

Ok, you've read your code, the instructor's code and the docs. Time to turn to Google.

Thankfully, you are almost certainly not the first person to run into this specific problem. If a technology has existed long enough for there to be tutorials, then other people have already run into problems with it and written questions and answers that you can find.

Don't feel guilty about googling. Every developer does it, from newbies to veterans.

Colt Steele has a great video on The Google History of a High-Paid Senior Engineer which shows how often skilled and knowledgeable engineers google even basic concepts.

Googling is a skill that you will develop with time and practice. There's a useful post from Juan Cruz Martinez on how to get better at googling as a developer.

Here, I'll focus on four ways to search more effectively:

Be as specific as possible
Include the error messages
Limit it to the last year or two
Search within specific sites

Be as specific as possible

You're following a tutorial on a specific technology. Put that at the start of your search. If you're using just JavaScript, start your search with "JavaScript". If you're using React or Vue, start with them. If you're using Next or Nuxt, put them as your first keyword. Be specific.

One pattern I've seen is to structure your search like this: LANGUAGE/FRAMEWORK VERB KEYWORDS. This seems to provide better autocomplete suggestions from Google.

If you're having an issue with a font not loading in a Gatsby site that uses styled-components, search for something like styled-components Gatsby load fonts.

If you're getting irrelevant results, you can use - to remove unwanted terms from your search: KEYWORD -UNWANTED_WORD.

For example, if you're stuck on a Ruby tutorial, include -jewellery, or -jewelry if you prefer, in your search to filter out results about the precious stone rather than the programming language.

Include the error message

If you got an error message and it wasn't enough to tell you what was wrong with your code, it might still prove useful in helping you find a resource that can help you.

Now, error messages will often include a lot of information that is specific to your application or your machine. Remove this or it might prevent you from finding similar results. Don't copy the entire error message with the stack trace.

James Roe offerd this advice:

error code -> error message -> language -> library -> syntax would be my general guide, in descending order of usefulness with other keywords.

I would recommend including the library/framework you are working with. For example, Node.js is used in a lot of build tools and you might get similar looking error messages even though you're using different technologies on top of Node. Search for Nextjs ERROR_MESSAGE rather than just ERROR_MESSAGE.

Say you get this error message from a React app:

Uncaught Invariant Violation: Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops.

I would search for React Uncaught Invariant Violation: Maximum update depth exceeded. The rest of the error message and the stack trace is React helping you to debug your code but it's too much detail to make for a good Google search.

Limit it to the last year or two

Programming resources go out of date fast and material from a couple of years ago might no longer be helpful to you. Using :before and :after in your search will limit the results to before of after a specific date: KEYWORD after:DATE

I usually limit my searches to the last two years and sometimes just to the last month to check if some recent change to the library of framework may be causing the issue.

Search within specific sites

You can use Google to search within a specific site even if that site doesn't have a built-in search feature: KEYWORD site:WEBSITE_URL. This can be handy if you're trying to search through documentation.

If the tutorial is on a site with comments (such as YouTube, Medium or Dev.to), look there. Several times I've crossed my fingers and scrolled down, hoping someone else had already run into the same issue and gotten an answer.

If the learning resource you're using has a forum, Slack or Discord, search them. Include the section or video title in your search terms. These will also be great places to ask questions (more below).

I've found GitHub issues to be particularly useful when I run into problems with libraries and frameworks. If you're experiencing a problem with React, Angular or Vue, someone else likely has too. That said, when you find your exact problem in an open GitHub issue, with no sign of being resolved, it can be a bit demoralizing, so your mileage may vary.

3. Ask

Asking for help can be intimidating. You're exposing yourself to the scrutiny of others. Maybe you're worried about wasting someone else's time or worried about looking foolish if the solution turns out to be "obvious" in hindsight. Imposter syndrome can rear its head here.

If you're intimidated to post a question online, try Rubber Duck Debugging first. Explain your code line by line out loud to your cat, a desk lamp or the ceiling. Sometimes, explaining a problem can jolt your brain into offering a solution.

Remember, if you've made a genuine effort to understand a problem before asking for help, you have no reason to feel embarassed or guilty.

Some sites - I'm thinking of Stack Overflow and Reddit - can be hostile, but there are others that are much friendlier for learners.

If you're looking for a safe place to ask questions, head to the places where other learners are.

Learning resources often have a forum - freeCodeCamp, Treehouse, and Codecademy all do - and I can speak from experience that there are plenty of people there who are happy to help you get unstuck with those courses.

If you're following a tutorial on YouTube, Dev.to or Medium, post your question in the comments. If the instructor doesn't get back to you, one of the other learners might.

I have to admit, I'm often reluctant to ask questions online. I don't want to look inept or to annoy anyone. So when I do ask questions, I try to do the following:

Include specific details
Share what you've tried
Make your code available

Include specific details

Don't write "My app's not working. Help!". Try something more like "I've gotten to the part of the tutorial where we add the ability to update todos. I can mark a todo as completed in the app interface but when I reload the page it shows it as not completed. I've looked at the React developer tools and the state is updating so I think the problem is that the data's not getting saved to the database. It might be an issue with my updateTodo function. Has anyone else run into this?"

I try to follow the pattern:

Here's what's meant to be happening.
Here's what's going wrong.
Here's what I've tried to fix it.

Share what you've tried

Sharing the steps you've tried is important for two reasons:

It shows that you're not wasting people's time by asking for help without having done any work yourself
It gives other people an idea of what you've already ruled out

People will be much more likely to pitch in and help you if you show that you've given the problem your best and aren't expecting them to solve it for you.

Sharing your steps will also help them to get up to speed with your code and save them from having to ask you several basic questions.

Make your code available

It will be much easier for someone to help you if they can see your code for themselves.

By all means focus on the part of the code where you think the problem is, but also give them a link to the full project so they can read your code in context.

There are so many services that let you share your code for free. Provide a link to a Codepen, repl, CodeSandbox, or GitHub repo so they can view it for themselves.

If you're having issues with a build on Netlify or Vercel, give them the full error message and stack trace as well as a link to your project.

It can also be really helpful to include clear screenshots of the problem, whether that's the error message or the weird layout problem you're encountering.

The more context you can provide, the easier it will be for someone else to understand your code and offer help.

Getting Stuck is Normal, and Can Be Beneficial

Being frustrated is a natural part of programming and of learning any topic. If you never run into an issue, how do you know you're not just copying code without actually learning? It might be more enjoyable to follow a tutorial and have everything work first time, but you will learn the topic much more effectively and thoroughly if you are forced to think about what you are doing. Have a look at the theory of deliberate practice to find out more about this.

When you get stuck, it's ok to get frustrated, but don't stay frustrated. Take a break, go for a walk and clear your head.

When you come back, work the problem. Remember that you have the skills and resources to get yourself unstuck. And remember, too, there are a lot of people who are more than happy to help you if you put the work in first.

I hope this post was helpful. Best of luck with the next topic you're learning.

More Resources

Amy Haddad, How to Get Unstuck When You Hit a Programming Wall - freeCodecamp
Ben Awad, How to Google Search Error Messages - YouTube
Beth Qiang, Read, Search, (Don’t Be Afraid to) Ask - freeCodeCamp
Bolaji Ayodeji, How to Ask Effective Questions: A Practical Guide for Developers - freeCodeCamp
Colt Steele, The Google History of a High-Paid Sr. Engineer - YouTube
Juan Cruz Martinez, 11 Tricks To Master the Art of Googling as a Software Developer - BetterProgramming
Swyx, How To Google Your Errors - Dev.to

How to Connect a Node App to MongoDB Atlas

Gerard Hynes — Thu, 29 Jul 2021 15:02:52 +0000

MongoDB is a popular NoSQL database choice for Node apps. There's a reason that the acronyms MERN stack, MEAN stack and even MEVN stack exist to describe an app built on MongoDB, Express, a JavaScript framework (whether React, Angular or Vue), and Node.

If you're learning how to work with MongoDB and Node, setting up a database on your own computer can be a little bit of a headache. Thankfully, MongoDB offer a cloud-based database platform, MongoDB Atlas.

I recently built a few projects with Node and MongoDB Atlas and felt it might be useful to write up a quick guide to how to get the two to talk to each other.

Step 1 - Set up your MongoDB Atlas Account and Cluster

First things first, go to the MongoDB Atlas website and create a free account. You can choose whatever name you want for your organization and project. Choose JavaScript as your preferred language.

Next choose a free shared cluster. This will be enough for demos and small personal projects.

When you're invited to create a starter cluster, you can leave the Cloud Provider and Region as the defaults (unless you have strong feelings about them) and click Create Cluster.

You'll now be brought to your admin dashboard. Click on Create a New Cluster. This can take a couple of minutes.

Once your cluster is ready, click on the Connect button in the sandbox.

Allow access from all IP addresses. This would be a terrible idea in production but this is just a demo for learning purposes.

Next, create a new user for the database and choose a password. Store these somewhere safe, like your password manager.

Now click on Choose a connection method.

Select Connect your application

Under Add your connection string into your application code you'll see a URI with the format mongodb+srv://<username>:<password>@<cluster-name>.mongodb.net/<db-name>?retryWrites=true&w=majority. The username, cluster-name and db-name fields will be automatically filled out.

Copy this URI to your clipboard. You'll need it in a minute.

Step 2 - Make a Node App if you don't already have one

If you don't have a Node app to hand, you can download the starter code for a very basic Express app from this repo.

Run npm install to install Express, the only dependency.

Your app.js file should look like this.

// app.js
const express = require("express");
const port = 3000;

const app = express();

app.get("/", (req, res) => {
  res.send("Hello World!");
});

app.listen(port, () => {
  console.log(`Your app is listening on port ${port}`);
});

In your command line, run node app.js and you should see the confirmation message that your app is listening on a particular port.

Step 3 - Store Environmental Variables

Remember your MongoDB Atlas URI? You don't want to just paste that into your code where it could get committed to Git and potentially publicly exposed.

Instead, we're going to save it as an environmental variable.

Install the dotenv package with npm install dotenv.

Create a .env file in the root of your project, paste in your URI, and assign it to a DB_URI variable. Make sure your version includes your password as well as your username, cluster name and database name.

// .env
DB_URI=mongodb+srv://<username>:<password>@<cluster-name>.mongodb.net/<db-name>?retryWrites=true&w=majority

Step 4 - Configure your Database Connection

To keep things organized, I keep my database config in its own file.

In the root of your project, create a db.js file. This will contain all the configuration for connecting to your database.

We're going to use Mongoose to handle connecting to our database.

Install Mongoose with npm install mongoose and import it into db.js.

Import your database URI as db from process.env.DB_URI.

Create a connectDB function. Make sure you mark it as an async function as it will take some amount of time to connect to your database.

Inside connectDB, create a try-catch block to handle any errors that occur.

In the try block, await mongoose.connect(). Pass it the db variable and a settings object. In the settings object, set useNewUrlParser and useUnifiedTopology to true. This will prevent Mongoose from giving you warnings. Mongoose explains the warnings in their documentation.

It's also a good habit to console.log a success message to tell you you've connected to your database. I once spent an hour trying to debug a database connection simply because I wasn't telling myself it was connected.

In the catch block, console.error any error you receive and use process.exit(1) to terminate the process if an error occurs.

Finally, export the connectDB function.

Your db.js file should now look like this.

// db.js
const mongoose = require("mongoose");
const db = process.env.DB_URI;

async function connectDB() {
  try {
    await mongoose.connect(db, {
      useNewUrlParser: true,
      useUnifiedTopology: true,
    });
    console.log("MongoDB connected");
  } catch (error) {
    console.error(error.message);
    process.exit(1);
  }
}

module.exports = connectDB;

Step 5 - Time to Connect to Your Database

In your app.js file, require dotenv and call the config method on it.

Import the connectDB function and call it.

// app.js
require("dotenv").config();
const express = require("express");
const connectDB = require("./db");
const port = 3000;

// Connect to database
connectDB();

const app = express();

app.get("/", (req, res) => {
  res.send("Hello World!");
});

app.listen(port, () => {
  console.log(`Your app is listening on port ${port}`);
});

Congratulations, your Node app is now connected to your MongoDB Atlas cluster. If you run node app.js, you'll see two messages printed to your console: that your app is running and that you've connected to your database. From here you can start to write schemas and perform CRUD operations with your data.

If you ran into any issues, the code for this demo app is in this repo.

More Resources

MongoDB Atlas Documentation
MongoDB, Getting Your Free MongoDB Atlas Cluster - YouTube
MongoDB, MongoDB Atlas Tutorial – How to Get Started - freeCodeCamp

Turning a Personal Site into a Portfolio

Gerard Hynes — Thu, 29 Jul 2021 14:48:53 +0000

Personal websites are often neglected. In my case, my old site hadn't had a redesign in 2 years 😬. Since then I've built dozens of small projects and learned a number of new technologies. But my site didn't reflect any of that.

The old site and its problems

The old site was a pretty accurate snapshot of my technical abilities at the time. It was a purely static site, with just a little bit of JavaScript for interactions and Sass for styling. I was in the middle of learning CSS Grid and about to start a long period of getting better at JavaScript. I hadn't even touched a frontend framework like React.

The main problem was that the site didn't have a clear message. The old landing page said "I'm a self-taught web developer and programmer". That's fine, but it's pretty generic, and doesn't really tell the visitor what I do or where my interests lie.

The site also failed the "show, don't tell" rule of writing. I did what everyone else seemed to be doing and listed the technologies I had experience with and linked to some projects. But I failed at properly demonstrating those skills or explaining why these projects mattered, how I had built them, or what I had learned.

Fixing these problems

After thinking about it, I decided that a portfolio site should quickly convey three things:

Your personality
Your professional interests
Your technical skills

In the last year I've fallen down the JavaScript rabbit hole and gotten really interested in the Jamstack as an architecture for building sites and web apps. My new landing page reflects this: "I make fast, modern sites and apps using the Jamstack and fullstack JavaScript".

When I rebuilt the site I intended for it to better demonstrate my current interests and technical skills, so clearly it should have a much greater focus on JavaScript. I settled on a Jamstack site built with:

Gatsby helps make the site fast by default, with built-in code splitting and image optimization. Markdown provides a pretty pleasant writing experience (at least for me), and MDX gives me the option to embed React components if I ever want to include videos, graphs or Codepens. styled-components offer many of the benefits of Sass, such as code organization, nesting and variables, with the added advantage that the CSS is scoped to individual components.

Sure, this might be overkill for a personal website, but I took comfort from Colby Fayock's post, when he says You're Allowed to Overengineer Your Blog, especially in order to solidify the technologies you're learning.

I've also made a concerted effort to update my personal projects from basic detail cards into proper case studies. Here I followed Josh W Comeau's advice on making a more effective portfolio, by fleshing out the project's goals, tech stack, any pain points encountered, and the lessons learned.

Lastly, in an attempt to write more, I added a writing section. If you've read Barbara Oakley's A Mind for Numbers or taken her excellent course on Learning how to Learn, you'll know that trying to explain concepts clearly in writing is a really effective way to check if you actually understand them and also make those concepts stick. Some of these posts might even prove useful for other people.

I've heard that if a podcast can make it past 7 episodes, it'll probably survive. Let's see if I can write more than 7 posts here.