DEV Community: Justin Hunter

How To Build and Host a Hugo Site

Justin Hunter — Sat, 25 Jan 2025 23:26:04 +0000

Hugo is a static site generator that first launched in 2013. While many static site generators are built in Node.js, Hugo is built using Go. The open source project has gained a ton of traction over the years and currently has over 77,000 stars on Github.

Today, we’re going to build and host a Hugo site using Orbiter. Orbiter is the fastest and easiest way to get static websites online.

Getting Started

Since we’re going to build a site using Hugo and we’re going to host it using Orbiter, you’ll need a few things:

A free account on Orbiter. You can sign up here.
Install Hugo (you may also need to install Homebrew depending on your operating system and how you choose to install Hugo)
A code editor like VSCode or Zed or really anything
Git needs to be installed (this comes on most computers, but here’s a guide if you need it)

That’s it! Now, we can get into creating our Hugo site. Assuming you have already installed Hugo, let’s make open the terminal application on our computer and navigate to the folder where we keep our projects.

Run the following command to initialize a new Hugo project:

hugo new site hugo-orbiter

You can call your site whatever you’d like. I called mine hugo-orbiter.

Now, we need to change into the new project directory. Run this command:

cd hugo-orbiter

Now, we need to install a Hugo theme. We’re going to use Git submodules to do that as it’s recommended in the Hugo quickstart guide. So, run the following command:

git init

Then run:

git submodule add https://github.com/theNewDynamic/gohugo-theme-ananke.git themes/ananke

Now, we need to tell Hugo to use that theme. We can do that with this command:

echo "theme = 'ananke'" >> hugo.toml

To see our site, we need to run a local Hugo server. You can do that with this command:

hugo server

The site will be available in the browser at http://localhost:1313. This is a start, but we want to add some content before we host our site. To do so, you can use Hugo to create the markdown scaffolding of a blog post like this:

hugo new content content/posts/my-first-post.md

This will create a markdown post in the content folder of your project. To see this, open the project in your code editor of choice. Open the content folder, and you’ll see a posts folder inside. Inside that, you’ll see the markdown file. Right now, there’s not much in the file, but we can change that.

Update your markdown file to look like this:

+++
date = '2025-01-20T15:32:29-06:00'
draft = false
title = 'My First Post'
+++

## Hello, Orbiter!

This is a simple example post that will be part of my Hugo site. It will be hosted on [Orbiter](https://orbiter.host).

Now, we need to tell Hugo to build the site with new files. If your Hugo server is still running, you can stop it with crtl + c. Then, run this command:

hugo server -D

Now, when you visit the site in the browser, you should see your post and can click the read more button. It should look something like this:

We have the basics of a site. Let’s see about hosting it on Orbiter now.

Hosting the site

Hosting a Hugo site on Orbiter is as simple as uploading files. Let’s make sure we have the right files to upload though first. Shut down the local Hugo server and run this command:

hugo

This will build your site and output the static pages in a folder called public. That’s the folder we will use to upload to Orbiter.

Log into your Orbiter account and click the Upload Site button. Drag your public folder into the modal or click the Select Folder button then choose your public folder. Give your site a subdomain, and click Create.

In a few seconds, your site will be online and ready for you to share with the world! If you’d prefer to work at the command line level, you can also use the Orbiter CLI. The docs can be found here.

And that’s it. You’ve hosted your Hugo site on Orbiter in just a few clicks and spent just a few seconds doing it. Updating your site is just as simple. Click the gear icon next to your site, choose Update Site, and then upload a new version of the public folder.

Conclusion

Hugo is one of the most popular static site generators on the market. Hosting your Hugo sites can be as simple as an upload. Go from generated site to hosted site in seconds. Get started today!

How To Build and Host a Gatsby Blog

Justin Hunter — Sun, 19 Jan 2025 17:08:41 +0000

Gatsby is one of the most popular static site generators available. Started in 2015 as an open source project, with a company being formed a few years later around hosting services, Gatsby has seen thousands of developers build sites on the React-based site generator. In 2023, Netlify acquired Gatsby and has been integrating the hosting services into their platform since.

While Netlify is a great solution for web application and static site hosting, if you want something simpler and something specifically built to bring back control and fun on the web, Orbiter is a great solution for hosting Gatsby sites. In this guide, we’ll walk through hosting a simple Gatsby blog on Orbiter.

Getting Started

As mentioned, Gatsby is a static site generator built on top of React. We won’t need much, but you will want to make sure you have the following:

A free Orbiter account. Sign up here.
Node.js v18 or later. This comes installed on most computers, but you can download it if necessary here.
A code/text editor - I use VSCode and Steve uses Zed, but anything will do.

Now, we need to fire up the terminal application on our computer. For Mac that’s Terminal, and for Windows and Linux, it could be a few different things. Here’s a quick guide on finding and using yours. With ther terminal application open, change into whatever directory you want to keep your project:

cd my-projects-folder

Then, we need to initialize our Gatsby project. To make things as simple as possible, we’re going to be using a pre-made blog template for Gatsby. In your terminal, run the following command:

npx gatsby new gatsby-starter-blog https://github.com/gatsbyjs/gatsby-starter-blog

This will set up the project and install dependencies. You’ll see a message printed with the next instructions. It should look like this:

  cd gatsby-starter-blog
  gatsby develop

Follow those instructions. Run this command in your terminal:

cd gatsby-starter-blog

Then, run this command to start the local version of your blog:

gatsby develop

If you open http://localhost:8000 in your browser, you should see something like this:

This is the default blog template with some temporary post placeholders. Let’s edit our site to make it more personal, though.

Editing the site

Open the project in your code editor and find the gatsby-config.js file. It should look like this:

module.exports = {
  siteMetadata: {
    title: `Gatsby Starter Blog`,
    author: {
      name: `Kyle Mathews`,
      summary: `who lives and works in San Francisco building useful things.`,
    },
    description: `A starter blog demonstrating what Gatsby can do.`,
    siteUrl: `https://gatsbystarterblogsource.gatsbyjs.io/`,
    social: {
      twitter: `kylemathews`,
    },
  },
  plugins: [
    `gatsby-plugin-image`,
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        path: `${__dirname}/content/blog`,
        name: `blog`,
      },
    },
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/src/images`,
      },
    },
    {
      resolve: `gatsby-transformer-remark`,
      options: {
        plugins: [
          {
            resolve: `gatsby-remark-images`,
            options: {
              maxWidth: 630,
            },
          },
          {
            resolve: `gatsby-remark-responsive-iframe`,
            options: {
              wrapperStyle: `margin-bottom: 1.0725rem`,
            },
          },
          `gatsby-remark-prismjs`,
        ],
      },
    },
    `gatsby-transformer-sharp`,
    `gatsby-plugin-sharp`,
    {
      resolve: `gatsby-plugin-feed`,
      options: {
        query: `
          {
            site {
              siteMetadata {
                title
                description
                siteUrl
                site_url: siteUrl
              }
            }
          }
        `,
        feeds: [
          {
            serialize: ({ query: { site, allMarkdownRemark } }) => {
              return allMarkdownRemark.nodes.map(node => {
                return Object.assign({}, node.frontmatter, {
                  description: node.excerpt,
                  date: node.frontmatter.date,
                  url: site.siteMetadata.siteUrl + node.fields.slug,
                  guid: site.siteMetadata.siteUrl + node.fields.slug,
                  custom_elements: [{ "content:encoded": node.html }],
                })
              })
            },
            query: `{
              allMarkdownRemark(sort: {frontmatter: {date: DESC}}) {
                nodes {
                  excerpt
                  html
                  fields {
                    slug
                  }
                  frontmatter {
                    title
                    date
                  }
                }
              }
            }`,
            output: "/rss.xml",
            title: "Gatsby Starter Blog RSS Feed",
          },
        ],
      },
    },
    {
      resolve: `gatsby-plugin-manifest`,
      options: {
        name: `Gatsby Starter Blog`,
        short_name: `Gatsby`,
        start_url: `/`,
        background_color: `#ffffff`,
        // This will impact how browsers show your PWA/website
        // https://css-tricks.com/meta-theme-color-and-trickery/
        // theme_color: `#663399`,
        display: `minimal-ui`,
        icon: `src/images/gatsby-icon.png`, // This path is relative to the root of the site.
      },
    },
  ],
}

This has a lot of things you can edit about your site. Let’s start with the top section called siteMetadata. Go ahead and change the title of the site to whatever you want your blog site to be called. Then, change the author information. I changed mine to look like this:

siteMetadata: {
  title: `Justin's Gatsby Tutorials`,
  author: {
    name: `Justin Hunter`,
    summary: `Co-founder of Orbiter, writing (hopefully) interesting things on the internet`,
  },
  description: `A blog site full of Gatsby tutorials.`,
  siteUrl: ``,
  social: {
    twitter: `polluterofminds`,
  },
},

Note: I removed the siteUrl, but you could replace that with your expected Orbiter site URL which would be: YOUR_CHOSEN_SUBDOMAIN.orbiter.website

If you check out your browser window after saving your changes, you’ll see the updates reflected immediately. However, the author image is still wrong. Let’s fix that. In the src folder, find the images folder. Inside that, you’ll see the profile-pic.png file. We need to replace this with our own image. Delete that file. Grab your own author image and rename it to profile-pic.png then place it in the images folder.

Now, it’s starting to look like your own site! Let’s work on the blog posts, though. In your code editor, find the content folder. Inside that folder is another folder called blog. This is where the markdown files are that represent your blog.

Markdown is a common syntax for writing that is easily converted into HTML. You can read more about markdown from its creator here. Each blog post file you put in this blog folder will be converted to HTML and rendered on your site. Right now, there are three posts in the folder. Delete two of them and keep one (doesn’t matter which you pick). It should be noted that Gatsby expects each blog post to be represented by a folder that matches the post name, i.e. hello-world and then inside that folder is the markdown file (index.md) and any assets associated with the blog.

We’re going to edit the remaining post we left. Open the index.md file for the post. If you’re not yet comfortable with Markdown, you can use a tool like Static to get a WYSIWYG (what you see is what you get) interface that will save the file back to the correct location. Either way, we want to edit this file to put our own content in. I’m going to edit it to include the contents of this tutorial so far.

When you’ve done this and saved the file, you can see the changes on your local blog site at http://localhost:8000. Here’s mine:

And if you click the link to the blog post, you’ll see the content:

This is great, but there’s one thing we should change. If you look at the main page, the preview text for the blog post hasn’t been updated. This is powered by what’s called frontmatter. The frontmatter is also where you would change your blog post’s title and other information.

In your index.md file, you should see the frontmatter at the top. You’ll see a description property. Edit that to say whatever you want the preview text on the main page to say. Here’s mine after the change:

You can create new posts and follow the same format. With that, you have the basics down and you have your own personal Gatsby blog. Now, we need to host it.

Hosting your blog

Fortunately, Orbiter makes hosting your blog simple. First, from your terminal, run the following command:

npm run build

This will ensure your blog site is output into a format with the correct HTML and other assets. Now, we’re ready to host.

Log into your Orbiter account and click the Upload Site button. You can drag and drop the correct folder here or you can click the Select Folder option.

But what is the correct folder? With Gatsby, you’re looking for the public folder. Go ahead and upload that, then give your site a subdomain. Click create, and within a few seconds, your blog site will be online! It’s that simple. Any time you update your site (make changes, add blog posts, etc), just run the build command again, then in Orbiter, click the gear icon and choose Update Site. You’ll be able to upload the new version of the public folder and see those changes online in seconds.

Here’s my site: https://gatsby-blog-tutorial.orbiter.website/

Conclusion

Gatsby is a popular framework for generating static sites, especially static sites with a blog. It’s built on top of React, so if you already know react, customizing a Gatsby site is going to be smooth for you.

Hosting a Gatsby site couldn’t be simpler with Orbiter. Just drag and drop or select your public folder, and you’ve got your site online. Get started with Orbiter today!

Why Good Commit Messages Matter, Even For Solo Developers

Justin Hunter — Mon, 06 Nov 2023 18:03:58 +0000

In a dimly lit room, Alan, a solo developer, feverishly typed away on his keyboard. His project, a nifty new JavaScript library, was growing more intricate by the day. But as he committed his code, his messages were brief snippets: "fix", "update", "done". It was just him, after all. Who else needed to understand his hurried notes?

Fast forward a few months. Alan decided to revisit a previous module in his library, but he was greeted with a labyrinth of cryptic commit messages. What had "quick fix" meant? Why had he made that "important update"? The decisions that seemed obvious in the heat of coding had vanished from his memory.

The tale of Alan is all too common among solo developers. The value of comprehensive commit messages is often overlooked, especially when you're flying solo. But in reality, they can be a lifeline in many scenarios. Let's dive into the reasons.

A Digital Diary for the Coder's Mind Your commit messages act as a running diary, charting the journey of your project's evolution. Detailed commit messages allow you to jump back in time, understanding the why behind every change. It's the difference between opening a dusty diary filled with evocative entries versus one that only reads, "Did stuff."
Fostering Future Collaboration Today, you might be a solo developer. Tomorrow, you might decide to open-source your project or bring in a collaborator. Comprehensive commit messages ease the onboarding process, sparing your collaborators from countless hours of trawling through code to decipher its evolution.
Faster Debugging and Problem-Solving Imagine discovering a bug that traces back a few months. Without informative commit messages, identifying when (and more importantly, why) that bug was introduced can be akin to finding a needle in a haystack. However, with a well-documented commit history, you can quickly pinpoint and understand past changes, accelerating the debugging process.
Code Reviews and Knowledge Sharing Even for solo developers, reviewing your own code after intervals can provide fresh perspectives. Here, meaningful commit messages act as guiding posts, offering context and insights. You might even discover patterns in your coding or areas for optimization, all thanks to the detailed story your commits narrate.
Enhancing Professionalism and Discipline Writing articulate commit messages cultivates discipline. Just as a researcher wouldn't publish a paper without footnotes, a developer, solo or not, shouldn't push code without explaining the rationale. Such practices not only uplift your coding ethos but also reflect professionalism and preparedness for collaborative environments.

In the Midst of Coding, Pause and Reflect In our tale, Alan eventually realized the importance of meaningful commit messages. He began to approach them as mini-essays, capturing the essence of his decisions. Over time, he found himself referencing them regularly, saving time and avoiding frustration.

It's tempting to treat commit messages as an afterthought, especially when no immediate audience is in sight. But remember, the most crucial audience you're addressing might just be a future version of yourself. Solo developers aren't exempt from the trials and tribulations of revisiting past code. By giving commit messages the attention they deserve, you're setting yourself up for smoother, more informed coding journeys. After all, every line of code tells a story; make sure yours has a detailed narration.

Changeup helps automate the creation of changelogs.

How To Monitor Events in Your Svelte App

Justin Hunter — Mon, 11 Oct 2021 11:53:30 +0000

It seems there is a new JavaScript framework launched everyday. And while that is largely true, some standout above the rest. When Svelte first came out, it would have been easy to write it off as "yet another JS framework." However, Svelte quickly found its community. It has passionate supporters, great contributors, and was recently named the most-loved web framework.

Svelte differentiates itself from other JavaScript web frameworks by NOT including a virtual DOM. Basically, it is the antithesis to React. Direct DOM manipulation was once the norm with plain old JavaScript and jQuery, but its since been replaced by the many many frameworks out there that implement a virtual/shadow DOM.

With Svelte taking a different approach to JavaScript web frameworks, we should explore how (if at all) handling events and monitoring those events works in Svelte. Open-source ❤️ open-source, so we'll use the open-source event monitoring tool, Exceptionless alongside our Svelte app.

What you'll need:

Node.js v12 or higher
A free Exceptionless account
Text editor

Getting Started

We'll get started by signing up for Exceptionless. Note, you can also run this locally by grabbing the source code and following the instructions here. When you have signed up, you'll be prompted to create a new project. As we create the new project, we'll be prompted ot select the type of project. For this choose "browser application":

This will give you the install instructions, but don't worry, I'll provide those here as well. Next, click Manage Project and you'll want to grab your API key from the API keys tab.

Now, we can generate our Svelte project. We'll use deget so that we can get a full project scaffolding set up easily. Read more about that here.

npx degit sveltejs/template exceptionless-svelte
cd exceptionless-svelte

npm install

Now, our last step before opening up a code editor is to install the new Exceptionless JavaScript client. You can do so by running this from inside your project directory:

npm i @exceptionless/browser

Now, you can fire up the app by running:

npm run dev

Don't worry about how it looks, we're going to instead focus on how to capture events and errors in the app using Exceptionless. Let's dive into that!

Handling Events With Exceptionless

Svelte, like other JavaScript frameworks, allows you to build apps through a collection of components. However, to keep this tutorial simple, we will keep everything in out App.svelte file. So, let's start there. Open your exceptionless-svelte project in your favorite code editor, then find the App.svelte file.

You'll notice that with Svelte, we have a normal-looking script tag at the top of the file and then some HTML. This is because there is no virtual DOM. We're really just dealing with templating, reactive state, and plain JavaScript—which is pretty fun.

Let's import Exceptionless at the top of our script tag, and then let's start Exceptionless up.

import { Exceptionless } from "@exceptionless/browser"
Exceptionless.startup("YOUR API KEY");

Notice that we had to wrap our startup call in a function. This is because Svelte doesn't yet support to-level awaits. If it did, we would simply call await Exceptionless.startup("YOUR API KEY").

This App.svelte file doesn't have a lot going on, so let's change that. Let's make the name variable you see in our code above dynamic. We're not going to go deep into state/props with Svelte, but if you look in the main.js file, you'll see a prop variable called name. We also have that variable at the top of our App.svelte file. Changing it is as simple as assigning a new value. Which is exactly what we'll do. This is not the reactive way of handling state variables, so I encourage you to check out the docs here.

So, first, in the HTML, between your main tags, change things to look like this:

<main>
    <h1>Hello {name}!</h1>
    <p>Type a new name below to change the name variable.</p>
    <input on:change={handleChange} placeholder="new name" />
</main>

Then in your script tag, add a handleChange function like this:

const handleChange = (e) => {
  name = e.target.value;
}

Save your code, then visit localhost:5000. Type a new name in the input field and you'll see Hello World change to Hello ${new name}. Very cool. But we came here to montior events and take names!

Let's change our handleChange function to track that event with Exceptionless. This is a feature of our app, and Exceptionless includes a nice feature usage method in its JS client. We'll use that.

Change the handleChange function to look like this:

const handleChange = async (e) => {
  name = e.target.value;
  await Exceptionless.submitFeatureUsage("Name Change");
}

We are submitting the name change event to Exceptionless and tracking it as a feature usage event called "Name Change". Let's take a look at how this looks in our Exceptionless dashboard. Log in again and click on the Feature Usages tab on the left. Then click on Most Frequest. Here you'll see your new Feature Usage events.

Pretty cool, huh! There's a lot more you can layer in, including user details. This is powerful when you want to see how often particular user cohorts use a particular feature.

Now, we can't talk about event monitoring without talking about errors, right? Let's see what error handling looks like in Exceptionless and Svelte. Let's first start by adding a button to our app and some code that will throw an error when that button is clicked.

Under the input element in your main html tags, add this button:

<div>
  <button on:click={unhandledError}>Throw Error</button>
</div>

Then in your script tag, add the unhandledError function:

const unhandledError = async () => {
  throw new Error("You shouldn't be clicking that!");
}

We aren't even doing anything to handle this error. What?! That's because Exceptionless will automatically send unhandled errors through so you can track them.

Go ahead and click the button. When you do so, nothing will happen. You can wire up your app to show some message if you want, but what we're really focused on is capturing the error in Exceptionless. Head over to your Exceptionless dashboard and click on Exceptions then Most Frequent. You should see something like this:

The beauty of this is you can click all the way through that exception and see the details of the error:

Now, what if you do want to handle errors and add in some additional context? Exceptionless has you covered. Create a new function called handleError:

const handleError = async () => {
  try {
    throw new Error("Handled error");
  } catch(error) {
    await Exceptionless.createException(error).addTags("handled").setUserDescription("joe@email.com", "power user").submit();
  }
}

You see in our catch we are adding a lot more info to the event. We are adding a tag letting us know this was a handled error (you would have much better tags, I'm sure). We are also adding a user with a description to the event.

Let's create a button in the app and test this:

<div>
  <button on:click={handleError}>Handled Error</button>
</div>

Now, when you click that and go back to Exceptionless, you'll see your event come through. When you click into the details, you'll see the tags and the user information. Pretty cool, huh?

Wrapping Up

Exceptionless is a powerful, flexible, and open-source event monitoring service. It works well with any language, but with the new JavaScript client, it works especially well with JavaScript apps and frameworks. In just a few lines of code, we were able to automate the collection of feature usage data and send errors to our Exceptionless dashboard.

But it doesn't stop there. You can track just about anything you can imagine with Exceptionless. Svelte plus Exceptionless work...uhhh...exceptionionally well together. Give them both a try today!

How To Use Error Boundaries in React With Error Monitoring

Justin Hunter — Thu, 19 Aug 2021 12:27:06 +0000

Backend engineers have all the tools. Nice error handling. Reporting. Metrics. What about us frontend devs? Sure, we can catch errors in our functions, but what about errors in our presentational code? Take React for example. Write some bad code in your function component and the whole app crashes.

Fortunately, frontend devs are getting more and more tools to help them with error handling. In fact, with the release of React 16, a new tool was added to the toolbox designed to specifically handle errors in components. Error Boundaries allow developers to catch and handle errors in the presentational layer of React applications. From the React team's announcement:

In the past, JavaScript errors inside components used to corrupt React’s internal state and cause it to emit cryptic errors on next renders. These errors were always caused by an earlier error in the application code, but React did not provide a way to handle them gracefully in components, and could not recover from them.

That all changed with React 16. However, if you wanted to recover from a presentational layer error AND report it, there wasn't anything out of the box to help you. This is where Exceptionless (an open-source error handling and monitoring tool) and React work really well together.

Let's run through a quick tutorial that creates a React app that does the following:

Creates an Error Boundary

Forces an error in a function component
Recovers from that error
Reports it to our monitoring service (Exceptionless)
Getting Started
For this tutorial, you will need to have the following installed:

Node.js v12 or greater
NPM
Text editor
Free account on Exceptionless

With those things in place, let's generate our React app. From the command line, run the following:

npx create-react-app error-boundary-example

When your app is created, change into the directory and install the Exceptionless React package:

cd error-boundary-example && npm i @exceptionless/react

This should get you set up with an app and the required package. Now, let's write a bit of code to show off the functionality. We'll walk through setting up an Error Boundary first.

Creating an Error Boundary in React

The first thing we need to do is create an Error Boundary file. This will act as a wrapper component for the rest of our application. In src folder of your React application, create a new file called ErrorBoundary.js. This will allow us to render a fallback when we hit an error in our component. We'll use Exceptionless's built-in Error Boundary to actually handle reporting the error. You'll see that soon, but let's focus on rendering the fallback for now.

Inside your new file, add the following:

import React from "react";

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  render() {
    if (this.state.hasError) {
      return (
        <div>
          <h1>Uh oh!</h1>
          <p>
            This wasn't supposed to happen. If you continue to see this message,
            please reach out to support.
          </p>
        </div>
      );
    }

    return this.props.children;
  }
}

export default ErrorBoundary;

This file will, again, wrap our main application code. So it will work throughout all of our components. If there's an error in a component, rather than totally crashing the application, it will render what we have in our render method here. You can change this to include whatever styling and information you'd like. I kept mine pretty simple.

Now, we need to connect this to our application components.

Wrapping The App Component
You may have many providers in your application that all wrap your main App component. That's OK. This new Error Boundary component will simply wrap everything at the top level. Go to your index.js and update your file to look like this:

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';
import reportWebVitals from './reportWebVitals';
import ErrorBoundary from './ErrorBoundary';

ReactDOM.render(
  <React.StrictMode>
    <ErrorBoundary>
      <App />
    </ErrorBoundary>
  </React.StrictMode>,
  document.getElementById('root')
);

reportWebVitals();

Now, before we handle reporting the error to Exceptionless, let's make sure this code works. Start up your application with npm start. We need to force an error. So, go into your App.js file and add an undefined variable into your component body:

import logo from './logo.svg';
import './App.css';

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <p>{undefinedVariable}</p>
        <img src={logo} className="App-logo" alt="logo" />
        <p>
          Edit <code>src/App.js</code> and save to reload.
        </p>
        <a
          className="App-link"
          href="https://reactjs.org"
          target="_blank"
          rel="noopener noreferrer"
        >
          Learn React
        </a>
      </header>
    </div>
  );
}

export default App;
You can see I've added undefinedVariable into the component. Because that variable is, well, undefined, the component will break. Save your code and check out the app. You'll see...

...an error message still. What gives?

Well, in development mode, React is going to try to help you out by rendering the error on screen. If you refresh the page, you should see your fallback component render for a split-second before the error appears on screen. When this code is deployed to a production environment, the error won't be displayed on screen. You know this because you've seen your production React apps crash. We all have. It shows a white screen. That's it. Now, though, your app will show the fallback screen.

Pretty cool!

Now, we need to make sure the error is reported back to our monitoring system. We will surely get emails from customers about this, but having the details handy might help us solve the problem before our support team can even get to those emails.

Capturing Errors

Now that we can display a message, Let's work on capturing the error and sending it to our reporting system—Exceptionless.

The Exceptionless React package includes an Error Boundary helper called ExceptionlessErrorBoundary. All we need to do is import this into our index.js and wrap our App component with it. You'll need to grab yourself an API key from your Exceptionless account for this. You can follow this guide to do so.

Let's take a look at what the code looks like. This is what you should update your index.js file to look like:

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';
import reportWebVitals from './reportWebVitals';
import {
  Exceptionless, 
  ExceptionlessErrorBoundary
} from "@exceptionless/react";
import ErrorBoundary from './ErrorBoundary';

const startExceptionless = async () => {
  await Exceptionless.startup((c) => {
    c.apiKey = "YOUR API KEY";
    c.useDebugLogger();

    c.defaultTags.push("Example", "React");
  });
};

startExceptionless();

ReactDOM.render(
  <React.StrictMode>
    <ErrorBoundary>
      <ExceptionlessErrorBoundary>
        <App />
      </ExceptionlessErrorBoundary>
    </ErrorBoundary>
  </React.StrictMode>,
  document.getElementById('root')
);

reportWebVitals();

Now go back to your React app and re-load. You won't necessarily see it there, but the error event was sent to Exceptionless. Open up your Exceptionless dashboard and take a look at the Exceptions events:

You can click into your exceptions to get more details. In this case, we will see what the variable was and the full stack trace for our React app.

Wrapping Up

Error Boundaries in React are powerful tools in helping you debug and quickly fix your applications. You can see how quickly we set this up to not only render a fallback UI and to report to an error monitoring service. You could write even less code and only report the error if you wanted to, but I'll leave that up to you.

There are plenty of error monitoring services out there that you can plug this into, but if you're interested in an open-source solution, get started with Exceptionless today.

How to Build a Custom Go Client For a REST API

Justin Hunter — Mon, 29 Mar 2021 13:16:25 +0000

Exceptionless is powered by a REST API. When you interact with the dashboard UI, when you use the .NET client, and when you use the JavaScript client, you are interacting with the REST API. It is well-documented, and it can be used without any client libraries. This paradigm makes it simple for developers to create their own wrappers around the API. In fact, we recently started work on building an official Go client for Exceptionless. Along the way, we learned some tips and tricks that may be helpful for others that want to build clients and SDKs in Go that wrap RESTful APIs.

First, a little about Go. Go is a statically typed language, built originally by the folks at Google. Go, while close in syntax to many other statically typed languages, differs in that it is no object oriented. Go is also very well suited for gRPC APIs, but that does not prevent it from being used with REST APIs, as we'll see here today.

Getting Started

In order to build our Go client, we will need to have Go installed. Honestly, this can be the hardest step as it involves setting environment variables and updating your profile source PATH. So rather than risk confusing you with the steps to install Go and get started, I'm going to simply point you to Go's official install instructions.

You can find those instructions here.

Once you've installed Go, you will need to have a text editor handy so that we can write our new Go code. From the command line, create a new folder and call it "go-rest". Change into that directory, and let's start writing some code.

The Main File

In Go, you will always have a main.go file which acts as the entry point for your source code. We need to set that up first, so let's do that now. In the root of your project folder, create your main.go file. Inside that file, let's start by declaring our package and importing a module. Add the following:

package main

import (
    "fmt"
)

Your file won't do anything yet, but we're laying the groundwork. We have declared our package as main, and we have imported the built-in fmt library from Go for formatting.

Next, we need a main function, so let's create that. Add the following below your import statement:

func main() {
  fmt.Println("Hello, world")
}

This is the example program Go's example docs show, so we might as well run it. From your command line, inside your project directory, run this command:

go run .

You should see Hello, world printed in the command line terminal window.

Now that we have the fundamentals down, let's talk about how Go works so that we can build our REST API client. You can include as many functions in your main.go file as you'd like and you can call those function from within other functions. But, like any other programming language, it's probably smart to separate code to make it easier to work with.

Creating an API Helper

The nice thing about Go is that when you create a new file, that file is automatically available from any of your other files as long as they share the same main package.

Since we are building a REST client, it probably makes sense to create a file that would handle all our API routing request. So, create a file in the root of your project called api.go.

Inside that file, make sure to reference the main package at the top like this:

pacakage main

We are also going to import a couple packages here as well, so your file should look like this:

package main

import (
    "bytes"
    "log"
    "net/http"
)

These packages are all built into Go itself. You can install external packages as well, and we'll explore that soon.

Now that we have the start of our API file, it's good to think about what our client needs to do. With a REST API, you may have the following request methods:

GET
POST
PUT
DELETE
PATCH

You may not need all of these for your client, but it's good to know that they exist. In our case, we are going to implement the GET and POST methods and with those as a template, you should be able to extend your code to implement PUT, PATCH, and DELETE.

Let's start by building the POST method since its the backbone of our client. In your api.go file, below the import statement, add the following:

//Post posts to the Exceptionless Server
func Post(endpoint string, postBody string, authorization string) string {
    baseURL := "YOUR API URL/"
    url := baseURL + endpoint
    var jsonStr = []byte(postBody)
    req, err := http.NewRequest("POST", url, bytes.NewBuffer(jsonStr))
    req.Header.Set("Authorization", "Bearer "+authorization)
    req.Header.Set("Content-Type", "application/json")
    client := &http.Client{}
    resp, err := client.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    return string(resp.Status)
}

In our real-world use case, we are making requests to the Exceptionless API, so we know the post body needs to be a JSON string. This is why the postBody is of type string. If your API is expecting a different format, make sure you type your variable properly here. The other two arguments in our Post function are pretty self explanatory. The endpoint string is the endpoint on your API you want to call. The authorization string is the token/API key needed to authenticate into the API. You could choose to handle the authorization differently, if you wanted. For example, if your API expected basic authentication, your authorization variable might be a string mapping of username and password.

One of the tricks here is if you are sending JSON to your REST API, you will need to convert the body into a format the http client library within Go can handle. We're doing that with the bytes.NewBuffer(jsonStr) call.

Now, let's put together our GET function:

//GET makes api GET requests
func Get(endpoint string, authorization string) map[string]interface{} {
    baseURL := "YOUR API URL/"

    url := baseURL + endpoint

    httpClient := &http.Client{}
    req, err := http.NewRequest("GET", url, nil)

    if err != nil {
        fmt.Println(err)
    }

    req.Header.Add("accept", "application/json")
    req.Header.Add("Authorization", "Bearer "+authorization)

    res, err := httpClient.Do(req)
    if err != nil {
        fmt.Println(err)
    }
    defer res.Body.Close()

    body, err := ioutil.ReadAll(res.Body)
    if err != nil {
        fmt.Println(err)
    }

    var result map[string]interface{}
    json.Unmarshal([]byte(body), &result)
    return result
}

Much like out POST request, our GET request takes in arguments. We only need the endpoint and the authorization arguments for this function. This function is pretty straight forward. However, if you want to read the response as JSON, you need to take an extra step as I've shown above.

You will want to a string mapping by unmarshaling the JSON returned by the API. Of course, your API may not return JSON, so use this accordingly. If you do need to unmarshal the JSON, you simply need to pass the response body into the json.Unmarshal() as shown above.

These two functions should help you build your other REST-related functions. Now, let's take a look at helper functions that will make your client easy to use while sending the correct data to your API.

Convenience Functions

A good SDK or client API wrapper will include helper functions so the developer using it doesn't have to still manually build requests to your API. The best way to build helper functions is to start with your data model. Let's say, for example, your API expects a JSON payload like this:

{
    "BookTitle": "The Great Gatsby", 
    "Author": "F. Scott Fitzgerald", 
    "Rating": 7
}

In this case, we'd probably want to create a struct type variable that we can use to build our payload for the reqest. That might look like this:

type BookRating struct {
    BookTitle       string
    Author          string
    Rating                  uint
}

A quick note on Go variables and functions. If the variable or the function name is capitalized, it is exported and available throughout your program.

Now that we have a struct we can use, we can start to build a helper function that would build a payload for our API. In keeping with the example in the JSON and the struct above, let's pretend our API take a POST request to rate a specific book. For some reason, our API needs the string title and string author of the book, and it needs an interger for the rating. You might create a helper function like this:

func RateBook(title string, author string, rating uint): bool {
    newRating := BookRating{
        BookTitle: title, 
        Author: author, 
        Rating: rating
    }

    json, err := json.Marshal(newRating)
    if err != nil {
        fmt.Println(err)
        return false
    }

    resp, err := Post("rateBook", string(json), "API KEY")
    if err != nil {
        fmt.Println(err)
        return false
    }   

    return true
}

In the RateBook function, we are allowing the developer to simply pass in the title, author, and the rating. We then build the JSON payload for the developer and send it to the Post function we created earlier. When we are building the JSON payload, we must use json.Marshal to convert our struct to a type that can be used with our REST API.

You'll note, the authorization argument in the above example is "API KEY", but a good SDK will have stored that API Key when the client was initialized. I'll leave it up to you on how you'd like to handle this, but it could be as simple as calling Configure function with the developer's API Key and storing the key in memory.

Wrapping Up

This is a simple example of how you might build a Go client for a REST API. The concepts are general, but they hopefully help you if you find yourself needing to build your own client. Exceptionless will be launching its own Go client soon. If you haven't tried Exceptionless for your application's event monitoring, give it a shot now.

How to Debug Electron Apps

Justin Hunter — Tue, 23 Feb 2021 14:59:54 +0000

Electron is a great framework that makes developing cross-platform desktop applications easy. If you're a JavaScript developer, it is probably the first thing you'll reach for when you decide to build a desktop application. I know I did. In building my first and second desktop applications, I used Electron. In that process, I learned some tricks to help the development process go a little smoother. One such trick is how to better debug issues that may arise in the packaged, production version of your Electron app that you won't see in development.

If you're not familiar with Electron, it is a framework that allows you to write apps with web technologies and use them on the desktop. This is accomplished by packaging your app within its own dedicated Chromium-based application. Think of a web browser. All it is is a desktop application that allows you to explore web apps and web pages. That's what Electron does for your app. It creates a one off desktop browser. In doing so, you get access to native desktop functionalities that are not available to traditional web applications.

Like with many software projects, you might find that your local development experience doesn't exactly match what happens in production. When an app is minified, built, compiled, and packaged for production use, there can be subtle changes that can break the experience of the application or break the app entirely. This is especially true when dealing with desktop applications that have more access than you might be used to with web apps. Debugging problems when your application works locally but doesn't work in its production state can be frustrating. This becomes even more frustrating in Electron when you only have access to the web application's JavaScript output in production and not the underling Electron code's output. Fortunately, we can solve this by using an error monitoring service.

We're going to be making use of Exceptionless and the Exceptionless JavaScript client to debug and monitor our Electron application. Exceptionless is free to get started and totally open-source. Let's get started.

From within your Electron app's project directory run npm i exceptionless.

Now, we can configure the Exceptionless client and use it anywhere. This means we can use it in both the "front end" (web app) code and the "back end" Electron code. For the sake of this tutorial, we are only going to be focusing on the Electron code. Inside your main.js file, add the following below your other import/require statements:

const { ExceptionlessClient } = require("exceptionless")
const client = ExceptionlessClient.default.config.apiKey = "YOUR API KEY"

You can get your project API key in the Exceptionless project settings page.

Now, with the client configured, you can start using Exceptionless to log events. The cool thing is these don't need to just be errors. If you want to log when a particular function is called within your main Electron code, you can use client.submitLog("Function called") but with something more descriptive. By submitting log events for particular functions, you will know for sure the function is being called. Of course, you can and should also track errors. This is as simple as calling client.submitException(error) with your error.

This is all very abstract, though. So, let's look at a practical example. Let's say your Electron app is listening to some event in order to write some data to the computer's hard disk. We need a trigger to come from our "frontend" html/js code, and then we need to read that trigger and take some action. In Electron, we use ipcMain to listen for events from the frontend code. An example of this might look like:

ipcMain.on("Save File", async (event, message) => {
  try {
    await fs.writeFileSync("/path/to/where/you/want/to/store/the/file", message)
    client.submitLog(`Wrote file successfully with the following content: ${message}`)
  } catch(e) {
    client.submitException(e)
  }
});

I added a log event that is sent to Exceptionless in the try and I catch the error and send that to Exceptionless in the catch. The beauty of this is we know when the event is successful, which is comforting, but we also know when it fails and why. This is important, because a failure here would be a silent failure in your app.

Let's say the file path you think you're trying to write to does not exist after your Electron app is built and packaged (a common issue is that PATH variables exposed by default to applications can be different than what you use and have available in your development environment). If that path did not exist, the writeFileSync command would not work. You would have no idea why, and your users would only know it when they tried to fetch the file that should have been written.

Imagine trying to debug that without error and event monitoring. You'd fire it up locally on your machine, run some tests, try to replicate the steps exactly as the user did them. And everything would work. You wouldn't see the error because your development environment is just different enough from the production environment to keep you from realizing that the write path in production doesn't exist.

There are a million other ways your Electron app can fail silently. By adding error and event monitoring, you can quickly debug problems that would otherwise have you banging your head off your desk.

Saying Thanks to the Open Source Community Through Sponsorship

Justin Hunter — Wed, 27 Jan 2021 17:27:03 +0000

Exceptionless has always been committed to the open-source software ecosystem. In fact, Exceptionless is entirely open-source, and we try our best to make it easy for anyone to host their own instance of our software. Our main repository has nearly 2,000 stars on Github and has seen contributions from 26 different people. Across all our repositories, we've seen hundreds of issues opened, dozens of pull requests, and countless comments. And for all of that, we are so appreciative. But we wanted to show our appreciation by doing more than just saying thanks.

Thanking Open Source Contributions Through Sponsorship

Today, we're excited to announce that we have sponsored Ben Adams through the Github Sponsors program. As you all know, we are huge fans of .NET, and Exceptionless is one of the only monitoring tools built around the .NET ecosystem first. Ben, like us, cares deeply about open-source software and the .NET community. We hope that by sponsoring him, we will be giving back in a tangible way, not just to Ben but to the sustainability of open-source.

Before diving into more about who Ben is and why we're sponsoring him specifically, it might be good to reflect on the importance of sustainable open-source development. Exceptionless survives through a hosted service, but many open-source projects don't have that option. This leaves maintainers in the unenviable position of having to write software, fix bugs, and respond to issues while receiving nothing more than "thanks" as payment.

"Thanks" doesn't pay the bills. Exposure doesn't pay the bills.

We don't want to see open-source developers shut down their projects. We want developers to have optionality. A quote from Kitze, the founder of Sizzy and other products, really illustrates this sentiment well:

Open source, writing blog posts, and playing with tweaking lint settings and editor themes all day are completely fine until your landlord knocks on your door or you’re at the checkout at the grocery store.

It's not just the viability of creating open-source software that becomes a problem, it's also the long-term sustainability when larger companies use that software. When we see companies like Amazon abuse open-source contributions, we see a door closing on the viability of software that is designed to survive through community and contribution.

So, while Exceptionless might not change the world by itself with its sponsorship, we want to lead by example. As Kitze said, Github stars don't pay the bills, but money does. So, we're opening our wallet and helping Ben Adams do what he's done so well for years.

Ben Adams

Ben has been working on open-source projects for years. He has thousands of contributions across dozens of repositories. In fact, he is so prolific in his .NET contributions that everyone else with more contributions than him are Microsoft employees. It doesn't get more impressive than that. Here's a quick summary of Ben's open-source contributions:

His projects have 2,600 Github stars (which, again, don't pay the bills 😉)
He has over 20,000 commits
He has contributed to 25 different projects
He's opened over 1,500 pull requests

It should be clear by now that Ben knows his stuff. As mentioned before, Ben cares a whole lot about .NET, and so do we. So, this sponsorship makes perfect sense for us.

For the gamers and the game developers, Ben has you covered too. He is the CTO of Illyriad Games which makes Age of Ascent. Age of Ascent is a real-time MMO that puts players in the cockpits of fighter ships in space. As you might expect, the game's tech stack makes heavy use of .NET and other Microsoft-related services.

Other people recognize Ben's contributions too:

Since the beginning of the .NET Core journey we’ve had some amazing contributors but I seriously enjoy working with
@ben_a_adams!
-David Fowler

There's smart, then there's crazy. Then there's Crazy Smart. That's Ben (and he's a lovely chap, too)!
-Rich Turner

Junior .Net Developer
Senior .Net Developer
Ben Adams .Net Developer
😁 😁 😁
-Marco Rossignoli

How Does Sponsorship Work?

Github Sponsors allows each developer to define what comes along with sponsorship at various levels. Ben was gracious enough to offer his own development time to Gold Level sponsors, and we simply could not pass that up. While we would be happy to simply sponsor Ben's work, having him contribute code to our open-source repositories will help Exceptionless take a major step forward.

Sponsoring open-source developers is not a new concept, but having it built into Github has help elivate the visibility of portential sponsorship opportunities. We hope that by having companies like Exceptionless sponsor (and publicize those sponsorships) developers, it will encourage others to do the same. Open-source sustainability still has a long way to go, but any step forward we can help the ecosystem take, we're willing to do it.

Thanks so much, Ben! We look forward to working with you and following your continued contributions across the open-source community.

How to Use React Hooks to Monitor Events in Your App

Justin Hunter — Tue, 19 Jan 2021 14:58:59 +0000

The introduction of Hooks in React was a game-changer. Developers now had options when it came to creating stateful components. It used to be that if you had a stateful component, you'd have to use a class component, and if you had a presentational component, you could choose between a class or a function component. Now, with hook, state can be managed inside function components. But that's not all Hooks did for React developers.

Hooks introduced a better way to reuse stateful functions. Today, we're going to explore how to build a custom React hook that will allow us to monitor events in our application. Those events can be errors, messages, feature usage, logs, or anything you want. There are plenty of error monitoring services out there, but we're going to make use of Exceptionless for three reasons:

Real-time updates
It's open-source
The Exceptionless JavaScript client gives us a singleton option (which makes for a good example in this post)

Let's get started by starting a new React project. You'll need to have the following available on your machine:

Node >= 8.10
npm >= 5.6
Text editor

Assuming you have that ready, open up a terminal. To create a new React project, simply run:

npx create-react-app Monitoring-App

Replace Monitoring-App with whatever you'd like to call your project. When everything is done, change into your new application's directory (cd Monitoring-App). Now, we need to install the Exceptionless JavaScript client.

To do so, simple run:

npm install exceptionless

When that's done installing, start your app (npm start) and open your project directory in the text editor of your choice.

What are Hooks?

React's docs have the simplest definition of Hooks and I think it's worth calling that out here:

Hooks are a new addition in React 16.8. They let you use state and other React features without writing a class.

The popularity of classes in JavaScript in general has oscillated greatly. However, within the React ecosystem, it was the ONLY option for creating components that could actually do anything. Because many JavaScript developers do not like and do not want to use classes, the option to write function components was a huge step forward. But outside of developer preferences, React Hooks open up new ways to write code in React apps, and hopefully help you reduce your code footprint in the process.

Hooks introduced a new way to handle lifecycle events in React as well. Gone are the componentDidMount and componentDidUpdate methods. In is the simple and elegant useEffect function.

You can read a lot more about the logic behind React's introduction of hooks here, but for the sake of this tutorial, I think that's enough of an intro.

Creating our first Hook

A hook is just a function that returns a value. The big gotcha with Hooks, though, is that they can only be called within the body of a function component. Keep that in mind as we progress. It's still relatively early in the life of Hooks, but there are some standards and conventions in place. Convention is to house your custom hooks in a folder called something like hooks. Let's do that.

Create a folder within the src directory of your project called hooks. Inside that folder, we're going to create a file using another convention within the React Hooks community. Developers will generally name their hooks with a useFunctionPurpose type of pattern. For example, if you were building a Hook that determined whether a navigation bar should show up or not, you might name the Hook file useNavigation. For us, we're going to call our file useMonitoring.

Create that file inside the hooks directory, and then we can begin building the function. We'e going to go line by line and then I'll show the whole file in one snippet. Let's start by importing the necessary functions from React.

import { useState, useEffect } from 'react';

I briefly touched on useEffect. It can be thought of in the same context as componentDidMount or componentDidUpdate. We'll make use of this to handle some logic in the setup of our Exceptionless client. useState can be thought of like this.state and this.setState in React class components.

Next, we'll get access to the Exceptionless JavaScript client like this:

import { ExceptionlessClient } from "exceptionless/dist/exceptionless";

Note: it's important to reference the /dist/exceptionless file because Exceptionless targets multiple environments and we want to make sure to import the right one.

Next we're going to handle something I mentioned earlier. Exceptionless is a class-based client. This means we have the option of instantiating that class everytime we use it, or we can make use of a singleton provided to us out of the box by Exceptionless. We set up the singleton patter first and then we will use some logic to handle situations where that singleton may not need to be used. Go ahead and grab the default client from Exceptionless like this:

const defaultClient = ExceptionlessClient.default;

If you haven't done so, get yourself an API Key from Exceptionless. You can sign up for a free account here. Once you have that, we're going to provide that key to to the default Exceptionless client. I like to make use of environment variables even when using keys that are safe to expose in the browser. So mine looks like this:

defaultClient.config.apiKey = process.env.REACT_APP_EXCEPTIONLESS_API_KEY;

Now that we've handled all our imports and initial configuration, we can frame out our hook function. The bare bones function looks like this:

export const useMonitoring = ({ config, useDefault }) => {
  // Code goes here
}

That's not much to look at, but there are two things I want to call out. The function name follows the convention I mentioned before, and this function takes two props: config and useDefault. If we are making use of the default singleton instance of the Exceptionless client, useDefault would be true and config would be null. However, if we are creating a custom instance of the Exceptionless client, config would be an object and useDefault would be either null or false.

Let's handle that logic. At the top of your function add the following:

const [client, setClient] = useState(defaultClient);

We are making use of the built-in useState hook here. We are simply defining a client state variable, defining a function that will be used to update that variable (setClient), and setting a defualt value for our variable. As you can see, we set the default value to use the default client from Exceptionless. Makes sense, right?

Next, we're going to use the built-in useEffect hook to determine what client should be returned for use in the particular part of the app that requested it.

useEffect(() => {
    if(useDefault) {
      return client;      
    } else if(config) {
      config.apiKey = process.env.REACT_APP_EXCEPTIONLESS_API_KEY;      
      setClient(new ExceptionlessClient(config));
    } else {
      throw "Please pass useDefault as true or a config object in";
    }
  });

In this case, it's best to think of our useEffect function in the same way you think of componentDidUpdate. Any update to the component that called our useMonitoring Hook will trigger another event within our useEffect function.

If you wanted this useEffect method to operate more like componentDidMount, you would structure it like this:

useEffect(() => {

}, []) // <-- This array says only run this function once when the component mounts

The empty array in the above example can be filled with a list of dependencies. Say, for example, you want your useEffect method to run everytime some specific variable changes, you would just pass that variable name into the array.

Ok back to our useEffect method. You can see we are checking the useDefault prop I mentioned before. If it is truthy, we return the client state variable. We had already set that variable to use the singleton Exceptionless client, so all we have to do is return it. If useDefault is falsey, we then check for the config object. If it's there, we add the apiKey to whatever values were passed into the config object, and then we instantiate a new Exceptionless client.

If no config object is provided, we throw an error. You could take this a step further and check if the config prop is actually of type object, but, hey, that's what Typescript is for, right? We're living dangerously in this crazy, crazy dynamically typed world.

The final thing you need to do in your useMonitoring function is return the client. Just as easy as it sounds:

return client;

Here's the whole, complete file:

import { useState, useEffect } from 'react';
import { ExceptionlessClient } from "exceptionless/dist/exceptionless";
const defaultClient = ExceptionlessClient.default;
defaultClient.config.apiKey = process.env.REACT_APP_EXCEPTIONLESS_API_KEY;

export const useMonitoring = ({ config, useDefault }) => {
  const [client, setClient] = useState(defaultClient);
  useEffect(() => {
    if(useDefault) {
      return client;      
    } else if(config) {
      config.apiKey = process.env.REACT_APP_EXCEPTIONLESS_API_KEY;      
      setClient(new ExceptionlessClient(config));
    } else {
      throw "Please pass useDefault as true or a config object in";
    }
  });
  return client;
}

Ready to use this bad boy?

Using your custom Hook

We created a basic React app, so let's just make use of what comes out of the box. Open your App.js file, and import your new custom Hook.

import { useMonitoring } from "./hooks/useMonitoring";

You'll also need to import the built-in useEffect Hook from React:

import { useEffect } from 'react';

Now, withing the main App function, you can use your new custom Hook:

const exceptionlessClient = useMonitoring({ useDefault: true });

How can we test this now? Well, let's make use of the useEffect function to throw an error as soon as the component mounts.

useEffect(() => {
  throwException();
}, []);

As you remember, the empty array at the end of the function says this should only run once when the component mounts.

Now, define the actual throwException function like this:

const throwException = () => {
  try {
    throw new Error("Whoops, it broke"); 
  } catch (error) {
    exceptionlessClient.submitException(error);
  }
}

Ready to test this out? If you previously started your React app, it probably already has worked. If you haven't started the app, go ahead and do that now.

You won't see much beyond the default starter React boiletplate. But that's OK. Open up your Exceptionless dashboard, and you should see an exception has, in fact, been captured.

If you click into that exception, you'll get a bunch of additional, useful, information. You can start to see how this can be helpful.

Now is the time where I remind you, our custom Hook can only be used within the body of your component functions. If you were to try to use your Hook in a Redux action function, you'd see an error. The beauty is, even if you're using Redux or something else, you can still throw errors back to your component and handle the error with your useMonitoring hook.

But Exceptionless is more than just errors. Let's build a quick, more practical example.

Usage Tracking

In your App.js file, we're going to remove all the boilerplate and add some ugly buttons. No styling in this post. This is what your App.js file should look like now:

import { useMonitoring } from "./hooks/useMonitoring";

function App() {
  const exceptionlessClient = useMonitoring({ useDefault: true });

  const handleButtonClick = (planName) => {
    exceptionlessClient.submitFeatureUsage(planName);
  }
  return (
    <div>
      <button onClick={() => handleButtonClick("Free")}>Free Plan - Learn More</button>
      <button onClick={() => handleButtonClick("Starter")}>Starter Plan - Learn More</button>
      <button onClick={() => handleButtonClick("Premium")}>Premium Plan - Learn More</button>
    </div>
  );
}

export default App;

You can see we have what might be a pricing page in an app. There are three buttons, one for each plan. We have wired up a button that will call a function that ultimately sends a feature usage event to Exceptionless. Go ahead and try clicking the buttons.

If you go to your Exceptionless dashboard and click the Feature Usage link on the left, you'll see these events have been captured in a dedicated section that makes it easy for you to track, well, feature usage. This may not replace your analytics provider, but it goes a long way.

Wrapping up

There is a lot more you can do with Exceptionless. For example, you may have noticed, we have only passed in the useDefault prop to our custom Hook. You can completely customize your Exceptionless configuration and pass in a config prop instead. I would encourage you to read up on the options here.

Exceptionless provides a lot of methods built into its JavaScript client that will make debugging, logging, and tracking easier.

Debugging a .NET Serverless App

Justin Hunter — Tue, 12 Jan 2021 15:35:31 +0000

Serverless development has become the hot thing in tech. Renting time on a virtual machine only when you need it saves money and resources. However, there are many gotchas that can make working with serverless technology difficult if you're not prepared. One such gotcha is event handling.

Unlike a Web Server applications, events in a serverless function act very similarly to console applications. Take AWS Lambda, for example. A Lambda function is going to spin up, execute, and spin down as quickly as it can. You want this. This is one of the key selling points of serverless, and how developers can ultimately save money. However, this can lead to problems when trying to process asynchronous events. We'll cover how to solve that in this post.

Today, we're going to build a simple .NET Hello World serverless application and we're going to implement event handling to log errors and other events. We're going to use the dotnet cli to install a new Lambda template, but first we need to make sure we have the Amazon Lambda Templates Package.

Once that's installed, create a new directory. I'm calling mine MyFunction, but you can call yours whatever you'd like. Change into that directory and run the following command:

dotnet new lambda.EmptyFunction --name MyFunction

This will create your new serverless function project in .NET. If you open up your project in Visual Studio or whatever IDE or code editor you prefer, you'll see your main file is Function.cs. You'll also have a very helpful README, and a json file with some default configuration. We're not going to be editing anything besides the Function.cs file, but it's good to know what's provided out of the box when generating a new lambda project.

We now need to add Exceptionless to the project. Exceptionless is an open-source event monitoring service available to all programming languages, but dedicated to .NET. Let's install it by running this command at the command line:

dotnet add package Exceptionless

This will install the most recent version of Exceptionless and is the foundation to you adding event handling in your serverless app. Once Exceptionless is installed, we can take a look at our code and see about where we might want to utilize Exceptionless.

Open up the Function.cs file again and add the Exceptionless namespace like this:

using Exceptionless;

Now, let's take a look at the function itself. It's a pretty simple function that returns a string in its uppercase form. We're going to change this around to instead return "Hello" plus the string passed in. Of course, that's not the focus of the tutorial, so we're going to also wire up error handling and event processing.

So, let's start with error handling. We can manually force an error that will fall into the catch block of a try/catch by not passing in a string to our function. Update your function to look like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Exceptionless;

using Amazon.Lambda.Core;

[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]

namespace MyFunction
{
  public class Function
  {

    public string FunctionHandler(string input, ILambdaContext context)
    {
      var client = new ExceptionlessClient(c =>
        {
          c.ApiKey = "YOUR EXCEPTIONLESS API KEY";
        });

      using var _ = client.ProcessQueueDeferred();

      try
      {
        if (input == null)
        {
          throw new Exception("input value is required");
        }
        return "Hello, " + input + "!";
      }
      catch (Exception ex)
      {
        client.SubmitException(ex);
        return ex.Message;
      }
    }
  }
}

We've added the Exceptionless namespace, we've converted the function to take in a string and return a hello world string.

To test error handling, we have set up a try/catch that will throw if no string is passed into our function. If that happens, we send the exception to Exceptionless.

Because we need to make sure events are sent to Exceptionless before the function ends, we are using the Exceptionless method ProcessQueueDeferred().

Now, it's time to test. Fortunately, there's a super easy way to test our code before we deploy to AWS. In your root directory, find the test folder. Nested in that folder is a test file called MyFunction.Test.cs. We're going to edit this file a bit and run our tests from the command line.

Update the file to look like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;

using Xunit;
using Amazon.Lambda.Core;
using Amazon.Lambda.TestUtilities;

using MyFunction;

namespace MyFunction.Tests
{
    public class FunctionTest
    {
        [Fact]
        public void HelloWorldFunction()
        {
            var function = new Function();
            var context = new TestLambdaContext();
            var upperCase = function.FunctionHandler("John", context);

            Assert.Equal("Hello, John!", upperCase);
        }
    }
}

This test should pass and we should not be sending anything to Exceptionless. To test it, switch into MyFunction/test/MyFunction.Tests and run dotnet test.

If your test passed, you're in great shape! But we don't just want to test our function. We want to make sure errors are sent to Exceptionless. So let's force an error.

Add the following to your test file:

 public class ErrorTest
{
    [Fact]
    public void ErrorFunctionTest()
    {
        var function = new Function();
        var context = new TestLambdaContext();
        var helloworld = function.FunctionHandler(null, context);

        Assert.NotEqual("Hello, John!", helloworld);
    }
}

The test should pass because we don't get a response of "Hello, John!". But what we want to do is check to see if the exception was sent to Exceptionless.

Open up your Exceptionless dashboard and you shoud see something like Exception in FunctionHandler input value is required. If you click on it, you'll see more details like this:

There are three tabs on the details page. In the above screenshot, I have selected the "Overview" tab. However, if you explore the other tabs, you'll see value data captured for you automatically.

Cool, so we created an exception. What about something a little more complex?

Let's say we want to track the usage of our new serverless function. We can do that pretty easily with Exceptionless. Let's change the current try/catch block to look like this:

 try
{
  if (input == null)
  {
    throw new Exception("input value is required");
  }
  client.SubmitFeatureUsage("Serverless Function");
  return "Hello, " + input + "!";
}
catch (Exception ex)
{
  client.SubmitException(ex);
  return ex.Message;
}

Here we are sending a feature usage event to Exceptionless as soon as the serverless function is triggered and we're sure the input is not null. The nice thing about this is that it doesn't rely on any errors being thrown and the rest of your function can continue to execute.

Let's run our tests again. We should get the feature usage event as well as an additional error because, remember, one of our tests forces a null exception.

In our dashboard, if we look at all event, we will see our feature usage event logged.

Conclusion

These types of events (features, logs, errors) because especially useful in serverless environments. Often, default logging in a serverless environment is either non-existent or much more difficult to set up. By dropping Exceptionless into your serverless application, you can track just about anything you're interested in. If you'd like to see full examples of Exceptionless in Lambda functions, check out our examples here and here.

How to Create a Custom Table Component in React

Justin Hunter — Mon, 04 Jan 2021 15:24:28 +0000

Tables are everywhere. Even if the web (thankfully) moved away from using tables to layout sites, you will still find tables in many places. Many lists are built from tables. User grids, preferences, favorites, feeds, etc. Because tables are everywhere, you, as a React developer, will find yourself doing one of two things: Using a library to build tables or manually building your own. If you fall into the latter category, this post is for you.

We're going to create a custom, reusable table component in React. In order to do so, we need to establish some high-level goals. These are the goals I applied to tables in my current project, Perligo, and I think they apply across all projects.

The table must be usable multiple times in different contexts (this one seems obvious, but putting it here to be sure).
The table should take in two data properties: the table head labels and the table body data.
The table should allow for custom classes to be applied depending on where the table is used.

With that in mind, let's get started. I'm not going to go through the whole set-your-react-project-up process. But, you'll obviously need a React project to continue.

Our table component will actually be a container that holds two other components: TableHeadItem and TableRow.

The Table Component

The table component is most important because it is what you will import into the pages you plan to use your table. Let's create it now.

import React from "react";
import TableRow from "./TableRow";
import TableHeadItem from "./TableHead";

const Table = ({ theadData, tbodyData, customClass }) => {
    return (
        <table className={customClass}>
            <thead>
                <tr>
                    {theadData.map((h) => {
                        return <TableHeadItem key={h} item={h} />;
                    })}
                </tr>
            </thead>
            <tbody>
                {tbodyData.map((item) => {
                    return <TableRow key={item.id} data={item.items} />;
                })}
            </tbody>
        </table>
    );
};

export default Table;

You can see we are importing the TableHeadItem and the TableRow components. We haven't built those yet, but we will shortly.

The Table component takes in three props: theadData, tbodyData, and customClass. The customClass prop satisfies the last requirement from my list of requirements for our reusable table component. If one is passed through, the table element will have that class. Otherwise, the class will be undefined.

The other two props, theadData, and tbodyData are both arrays. Remember, we want our table component to be reusable and not to care about the data being passed in. For that to work, we need to standardize the data props. Arrays work best for tables. As you'll see soon, the theadData should be an array of strings, and the tbodyData should be an array of arrays.

You'll see how this works soon. Let's move on to the TableHeadItem component.

The TableHeadItem Component

import React from "react";

const TableHeadItem = ({ item }) => {
    return (
        <td title={item}>
            {item}
        </td>
    );
};

export default TableHeadItem;

Not much to it. If you remember, we're mapping our theadData array inside the Table component, so the result passed through to the TableHeadItem component is a string that we just need to render.

Finally, let's build the TableRow component.

The TableRow Component

import React from "react";

const TableRow = ({ data }) => {
    return (
        <tr>
            {data.map((item) => {
                return <td key={item}>{item}</td>;
            })}
        </tr>
    );
};

export default TableRow;

Again, this is a pretty simple component. If you remember, tbodyData is an array of arrays. In our Table component, we're mapping over the root level array and returning a single array to each TableRow component that gets rendered. Within the TableRow component, we map over that individual array and return the columns for the row.

Putting It All Together

We've now built everything we need. Let's connect the component and pass it some data. You can do this from any component where you'd like to render tabular data. Let's start with the shape of the data:

const theadData = ["Name", "Email", "Date"];

const tbodyData = [
{
  id: "1", 
  items: ["John", "john@email.com", "01/01/2021"]
}, 
{
  id: "2", 
  items: ["Sally", "sally@email.com", "12/24/2020"]
},
{
  id: "3", 
  items: ["Maria", "maria@email.com", "12/01/2020"]
},
]

You'll note that my tbodyData variable is not actually an array of arrays. It's an array of objects, each with an array nested in the object. This is simply because I prefer to use a unique identifier for my key prop in React when mapping over data. You don't have to do this. You could just as easily, strip out the object and return just an array of arrays as I suggested originally.

Inside the component where we'd like to render the table, you can do something like this:

import React from "react";
import Table from "../../Reusables/Table";

const Example = () => {
    const theadData = ["Name", "Email", "Date"];

    const tbodyData = [
        {
            id: "1",
            items: ["John", "john@email.com", "01/01/2021"],
        },
        {
            id: "2",
            items: ["Sally", "sally@email.com", "12/24/2020"],
        },
        {
            id: "3",
            items: ["Maria", "maria@email.com", "12/01/2020"],
        },
    ];
    return (
        <div>
            <Table theadData={theadData} tbodyData={tbodyData} />
        </div>
    );
};

export default Example;

You can optionally pass in a customClass prop to your table component as well. This table component is now very reusable, quick to drop in, and prepping the data that you send through as props is easy.

I am using this custom component in my app (not yet released, but pre-release sign-ups are available), Perligo. You can see how nicely the tables render with data passed in exactly as I structured it above.

Conclusion

There are plenty of libraries and frameworks that are dedicated to table components or offer a full array of components. However, if you want a lightweight, customizable solution, building things yourself is always a valid approach. I hope this quick tutorial was helpful.

Why You Should be Practicing Exception Driven Development

Justin Hunter — Mon, 07 Dec 2020 16:21:30 +0000

You've heard of test-driven development. You've heard of behavior-driven development. Maybe you've even heard of acceptance-driven development. But you probably haven't heard much about exception-driven development. Let's take a look at what that type of development process is and why you should be practicing it.

Exception Driven Development

Jeff Atwood, of Coding Horror, wrote a blog post almost 12 years ago about this topic. In those dozen years since his post, the need for exception-driven development has only increased, but developers and companies need a clear understanding of how and why to practice this type of development.

At a high-level, exception-driven development is simply the practice of monitoring for exceptions in your code and shipping fixes quickly. To ensure you are monitoring the right things and shipping the right fixes, all without burdening your users, you have to make sure you are collecting the right data.

Contextual data is the key to exception-driven development. Arbitrary data from various points of input may not be useful. Data that is highly contextual to user actions, user experiences, and points in time during the use of your app will allow you to target better solutions and ship faster.

With your contextual data in hand, you can start to fix issues. But here's the rub: You can't wait until you "have enough" fixed for a deployment. Part of the exception-driven development process is deploying often. Have a single bug that took one line to fix? Cool, ship it. Know that you'll have additional features to put out in a few days and you're considering holding your bug fix for that deployment? Don't. Ship the bug fix, then ship the features.

Exception-driven development isn't a mysterious new process for most developers, but it is a mindset shift within many organizations. Bug fixes, listening to the data, and responsiveness must take priority if you are to transition to an exception-driven development cycle. While it may not take much effort to change your company's internal process, it may still take some convincing. So, why should you and your company practice exception-driven development?

Why Exception Driven Development

The first reason you should care is the most obvious reason. Your code has bugs. It does. No matter how good you are, you're going to ship bugs and you need to be ready to fix those bugs. Jeff Atwood probably said it best in his post about exception-driven development:

The question isn't how many bugs you will ship but how fast you can fix them.

Bugs are a part of code. Some never get fixed. But the ones that need to be fixed need to be fixed quickly. The trouble, of course, is that if you are relying on your users to tell you about these bugs, you've already taken too long to fix the issue.

Wait, what?

It's true. If your users have told you about bugs through email or Slack or Discord, you have already taken too long to resolve the issue. This is where the heart of exception-driven development comes in. You need to know about issues the second they arise.

You don't want to end up like this guy, right?

Think about it this way. How many lines of code does your application have? Got that number in mind? Ok, now divide it by 1000. Take your resulting number and multiply it by 15. That is possibly how many bugs you have in your software right now. Knowing this, don't you think it's important to try to find these bugs before your users have to tell you about them?

By practicing exception-driven development, you make your customers happier which protects your brand image. Do you want to be the brand that has a ton of bugs or do you want to be the brand that solves problems? You also make your developers happier. Would you rather fix a bug on a piece of code shortly after you were working on it, or do you want to try to fix it six months later after you've long forgotten about that code?

Customer retention, customer conversion, productivity, morale, and more are the reasons exception-driven development is important. Convinced yet? Good, now how do you do it?

How to Practice Exception Driven Development

If you remember, the first step of exception-driven development is to collect contextual data. Contextual data means data more than the stack trace itself. You should be collecting those traces, but the stack trace is just part of the picture. Some of the questions your contextual data should be answering include:

What user had this problem?
Where in the application did the problem occur?
Has the problem occurred previously?
What actions did the user take leading up to the issue?

You can probably think of other questions you'd like answered to help you with the bugs that come in. But notice that the suggestion here is not to collect this information directly from your users. Don't wait for an email from them. Don't follow-up with questions about their operating system and browser. Collect that information upfront without the user having to take action, and you will have your contextual data. Services like Exceptionless make this easy.

But why use a service like Exceptionless? You're a developer, you can just build the solution yourself. Sure you can, but then you have to manage that solution. You have to fix bugs on that solution while also fixing bugs you've found from your actual production application. You're not in the business of running an error monitoring service. But Exceptionless is.

Once you've collected your contextual data, you should know what to fix, where to fix it, and why it needs to be fixed. So, the logical thing to do is—well—fix it. The trick, though, is not to allow code creep to slow your release down. It's easy (trust me we all do it) to say, "oh, I'll just add this little feature or change this one other thing" when you're trying to fix a bug. You have to fight that urge, fix the bug, commit the code, and ship it. Then, you can go back and work on the shiny thing that almost distracted you.

Once your code is shipped, if you are using Exceptionless, you can mark the version that fixed the bug right within your dashboard. By doing this, you'll automatically know if you have any regressions. Exceptionless will track new occurrences of the error and compare the occurrence against the version of software the user is using and the version you marked as solving the problem. If those versions match, it's a regression.

Conclusion

The whole flow of collecting data, analyzing the data, writing code, and shipping should not be foreign to you. Yet, exception-driven development is still not practiced everywhere. Hopefully, this article helps you understand why you should change your ways and how to do it.