DEV Community: Jaken Herman

Extending a CLI Program with Subcommands in Rust

Jaken Herman — Thu, 17 Oct 2024 18:04:05 +0000

With Rust’s emphasis on performance and safety, it’s an excellent choice for building CLIs.

Getting Started with Rocket and Rust for REST APIs (Building a To-Do App)

Jaken Herman — Thu, 17 Oct 2024 06:19:03 +0000

In this blog post, we’ll begin building a simple to-do application using Rust and the Rocket web framework. Rocket provides a high-level API for building web applications and REST APIs, making it a great choice for developers who want to get up and running quickly. If you make it to the end of this post (and the end of this three-part series, you’ll have a basic REST API set up with Rocket that handles HTTP requests - which should set up a solid foundation for you to venture forward in making a fully-fledged to-do application (I know, I know - who needs another to-do application?)

What You'll Learn

Setting up a Rust project and adding Rocket as a dependency.
Creating a basic Rocket server.
Handling HTTP GET requests.

Prerequisites

Make sure you have Rust installed

💡

You can skip the project setup step, if you’d like, by cloning my GitHub repository, just make sure that if you do, you’re on the correct branch for this specific post. The branch is post-1. So once you’ve cloned, be sure to run git checkout post-1.

Setting up the Project

Let’s start by creating a new Rust project for the to-do app. I’m going to name mine dooly. You should modify the command below to replace dooly with whatever you’d like to name your application. Run the following commands:

cargo new dooly && cd dooly

Next, we’ll need to add a few dependencies. Run cargo add rocket serde serde_json. Now, open the Cargo.toml file and add modify your dependencies to include the derive and json features, like so:

[dependencies]
rocket = { version = "0.5.1", features = ["json"] }
serde = { version = "1.0.210", features = ["derive"] }
serde_json = "1.0.128"

Setting Up a Basic Rocket Server

With the dependencies ready, let's write our initial Rocket server. Open src/main.rs and replace the content with the following:

#[macro_use] extern crate rocket;

#[get("/")]
fn index() -> &'static str {
    "Welcome to the Rust To-Do API!"
}

#[launch]
fn rocket() -> _ {
    rocket::build().mount("/", routes![index])
}

Let’s break this down:

#[macro_use] extern crate rocket; is required to use Rocket’s macros.
#[get("/")] is an attribute that defines a route handler for GET requests to the root (/) of the server.
rocket::build() initializes the Rocket server, and .mount("/", routes![index]) mounts the route (index()) at the root URL (/).

Now, run the server using:

cargo run

You should see Rocket's launch sequence, and the server will start on localhost:8000:

🚀 Rocket has launched from http://localhost:8000

Open your browser and visit http://localhost:8000. You should see:

Welcome to the Rust To-Do API!

Handling Basic GET Requests for To-Do Items

Now let’s add a route to retrieve a list of to-do items. For now, we’ll return a static list of hardcoded items in JSON format. This can be supplemented with a list of items retrieved from a database or other storage method at a later time.

Replace the contents of src/main.rs with the following code:

#[macro_use] extern crate rocket;
use rocket::serde::{Serialize, json::Json};

#[derive(Serialize)]
struct TodoItem {
    id: u32,
    title: "String,"
    completed: bool,
}

#[get("/todos")]
fn get_todos() -> Json<Vec<TodoItem>> {
    let todos = vec![
        TodoItem { id: 1, title: "\"Learn Rust\".to_string(), completed: false },"
        TodoItem { id: 2, title: "\"Build a REST API\".to_string(), completed: false },"
    ];
    Json(todos)
}

#[launch]
fn rocket() -> _ {
    rocket::build().mount("/", routes![get_todos])
}

What’s new?

TodoItem: A struct representing a to-do item. We derive Serialize so it can be converted into JSON.
Json<Vec<TodoItem>>: Rocket's JSON type is used to return a vector of TodoItem instances as JSON.
The get_todos route is defined with the #[get("/todos")] macro, and it returns a static list of two to-do items.

Now, restart the server:

cargo run

Visit http://localhost:8000/todos on your browser (or use a tool like Insomnia or Postman - both great options) and you should see a JSON response:

[
  {
    "id": 1,
    "title": "Learn Rust",
    "completed": false},
  {
    "id": 2,
    "title": "Build a REST API",
    "completed": false}
]

Breaking Down Rocket’s Routing and Response

So let’s go over what we really did here. Rocket makes it simple to define routes. Here's how we defined the /todos route:

#[get("/todos")]: This specifies the HTTP method (GET) and the path (/todos) the route responds to.
Json(todos): We wrap the list of TodoItem structs in Json to automatically serialize it into JSON for the response.

Rocket also handles other HTTP methods like POST, PUT, and DELETE, which we’ll explore in future posts.

In this first post of this three-part series, we’ve set up a simple Rocket server and created a basic route to return a list of to-do items. In the next post, we’ll implement functionality to add, update, and delete to-do items, allowing users to interact with the API using different HTTP methods.

How to Build a Command-Line Interface (CLI) in Rust

Jaken Herman — Mon, 07 Oct 2024 18:04:05 +0000

With Rust’s emphasis on performance and safety, it’s an excellent choice for building CLIs.

Continue reading on Medium »

An Attempt to Demystify Rust Lifetimes

Jaken Herman — Wed, 02 Oct 2024 13:00:00 +0000

At its core, Rust's lifetimes are markers that define the span of time during which references are valid. Think of lifetimes as a guardrail that ensures you don't access data after it has been deallocated, a safeguard against null pointer dereferences and memory-related mishaps. Each reference has a corresponding lifetime, indicating how long it's allowed to stick around and be referenced. Rust’s obsession with safety is not just about protecting you from the potential pitfalls of programming. It's about providing you with an environment where you can trust your code to run without unexpected crashes or security vulnerabilities. This is one of the great things about Rust - I’m constantly saying that if there are no warnings in the Rust analyzer, I can feel confident that my code will run as-expected.

Here's why lifetimes are crucial:

Memory Safety: Lifetimes prevent dangling pointers and memory leaks, the presence of which are the kiss of death to stable software. They make sure references never outlive the data they point to.
Concurrency Control: Rust’s ownership and borrowing model, guided by lifetimes, enables safe and concurrent code execution by eliminating races. Lifetimes guide the compiler to enforce strict borrowing rules.
Predictable Behavior: By clearly defining the lifespan of references, lifetimes enhance the predictability of your code. You won't find yourself scratching your head over unexpected side effects.
Efficient Memory Management: Rust sidesteps the complexities of garbage collection with its ownership system. Lifetimes are the building blocks of ownership, leading to efficient memory management, which means Rust needs no garbage collector.

Lifetimes in Rust are denoted by a single lowercase letter, typically 'a, 'b, etc., though any valid identifier can be used. These symbols indicate the duration of validity for a reference and are employed in function signatures, structs, enums, and trait definitions.

Imagine a function that sorts a list of integers and returns a reference to the largest one:

fn find_largest<'a>(numbers: &'a Vec<i32>) -> &'a i32 {
    // implementation here
}

In this scenario, the 'a lifetime specifies that the returned reference will last as long as the reference to the input vector numbers. A typical lifetime annotation has the form &'a T, where 'a represents the lifetime and T is the type of the reference.

Embracing the concept of lifetimes is a hallmark of becoming proficient in Rust. These markers of temporal validity are the cornerstones of safety that Rust guarantees and they play an integral role in building efficient, secure, stable, and predictable software.

Show off your coding stats on your GitHub Profile using WakaTime

Jaken Herman — Wed, 01 Sep 2021 10:54:24 +0000

Your GitHub profile tells a story of who you are as a developer.

Continue reading on Medium »

Visualizing Percentile Data with d3

Jaken Herman — Sun, 13 Dec 2020 06:12:37 +0000

Recreating Baseball Savant’s Percentile Ranking Visualization

Continue reading on Medium »

Configuring + Installing Chadwick for Parsing Retrosheet Data

Jaken Herman — Thu, 03 Sep 2020 07:01:39 +0000

This post assumes you've set up VirtualBox & Vagrant. If you have not completed this step, follow the steps outlined in my previous blog post: https://dev.to/jakenherman/setting-up-virtualbox-vagrant-5bm2.

The first thing we're going to do is open up our terminal and run cd baseball, which is the directory we created in the previous post.

After than, we need to get the .tar.gz that contains the Chadwick software installer and configuration files. To download this, go to the chadwickbureau GitHub page, the Chadwick repository, and navigate to the "Releases" page. Here's a quick link to take you there directly: https://github.com/chadwickbureau/chadwick/releases

Take the latest release in the .tar.gz format, and move that file into your baseball directory. Once the tar file is in your baseball directory, in your terminal run the command vagrant up, followed by vagrant ssh .

Your terminal instance will now be running on your VirtualBox virtual machine. What we need to do now is move the tar file we downloaded earlier into the usr/local/src directory (this file will currently be sitting in ~/vagrant). We'll first navigate to the directory we're moving the file into by running the command cd /usr/local/src, then run the command below to copy the Chadwick tar file into the current directory (keep in mind, my file's version number is 0.8.1, but yours may be different - update your command accordingly):

Now that Chadwick has been copied and unpacked, we need to configure the software and complete the installation. To do this, run the configure file that you can see in the chadwick-0.8.1 directory when you run ls, then make to compile, make install to install the software to our virtual machine, and ldconfig to make sure the program can link to the libraries it needs:

To test that Chadwick was properly installed, run the cwevent command, and you should get the following output:

While this is technically an error, it means the installation was a success. cwevent is a command that Chadwick uses to parse Retrosheet event files, and since we've not yet provided one - we get this warning.

I hope this was helpful to you in your quest to begin working with Chadwick and Retrosheet. In the next post, we'll download our first few Retrosheet files and begin exploring.

Setting up VirtualBox+Vagrant

Jaken Herman — Sat, 22 Aug 2020 10:08:46 +0000

Setting up VirtualBox and Vagrant is not only a breeze, but it's also free. This combo is great for simple projects, much like the project we're working on in this series (should you choose to finish this full series) - parsing Retrosheet baseball data using Chadwick in order to create useful R data frames for visualization.

Keep in mind throughout this post that your download+setup process may vary slightly, but the main process will remain similar enough to follow.

Step 1: Download and Install VirtualBox

Navigate to the VirtualBox download page here: https://www.virtualbox.org/wiki/Downloads, and select the download that is appropriate for your current operating system.

Run your installer and complete the standard installation process you follow for any other software.

MacOS Users: An issue may occur where your installation is being blocked by your Security & Privacy settings. If this occurs, do the following:

Open System Preferences
Go to Security & Privacy
There will be a message that saysSystem software from developer "Oracle America, Inc." was blocked from loading.
Click the lock icon in the bottom left of the window & enter your password
Click the Allow button

Step 2: Download & Install Vagrant

Navigate to the Vagrant download page here: https://www.vagrantup.com/downloads, and select the download that is appropriate for your current operating system.

Run your installer and complete the standard installation process you follow for any other software.

Step 3: Set up Directory and Initialize Vagrant Box

Now that we have VirtualBox and Vagrant installed, we need to set up a directory to use the two together. Keep in mind, we'll never explicitly open the VirtualBox application, we only downloaded and installed it so Vagrant would be able to use it in the background.

Open up your terminal, make a new directory (in this example I named mine baseball), then initialize a Vagrant box of your choice (boxes listed here:
https://app.vagrantup.com/boxes/search). In this example, I'm using ubuntu/trusty64:

The vagrant init ... command could take up to an hour to run, so grab a cup of joe ☕, it may be a while!
When your initialization is complete, you'll notice a file called Vagrantfile in your baseball directory. As described by the Vagrant website:

The primary function of the Vagrantfile is to describe the type of machine required for a project, and how to configure and provision these machines.

Step 4: Run Vagrant + SSH In

Once your Vagrant box has been initialized, the next step is easy - just run vagrant up to spool up your VirtualBox background process and SSH in:

You'll now be in your virtual machine! Keep in mind when using this that if you create a file in the directory /vagrant, the files will be added to your non-virtual baseball directory.
Thanks for reading. Check back in the next post and we'll get Chadwick downloaded and configured so we can begin playing around with Retrosheet data!

MLB Draft '20 by the Numbers

Jaken Herman — Sat, 13 Jun 2020 08:01:13 +0000

With no baseball being played so far in 2020, there hasn't been anything incredibly interesting to analyze or look at besides historical data (in the MLB at least). On June 10th and June 11th, however, we finally got our first bit of new MLB information to play around with - the draft. I've taken data from Rounds 1-5 and compiled them into some (hopefully) interesting visuals.

Picks by State

Let's start with a simple question. What state produced the most sought after baseball talent this year? California. The values used for the visual below may not reflect where a player was born and raised, rather it is the location of the high school or college the player was drafted from. This also excludes Owen Caissie and David Calabrese of Ontario, Canada.

Picks by Position

Next, let's look at draft picks by position. This includes every single pick - all 159 of them. As you can see in the chart below, pitchers were definitely shown some love while first basemen lagged behind (Although the #1 pick Spencer Torkelson played 1B, his primary position was marked as OF on MLB. This is likely the case for many utility players).

So who didn't take any pitchers? Only three teams! The Detroit Tigers, Tampa Bay Rays, and Milwaukee Brewers.

With all of these pitchers being picked, let's see how the top 5 picks compare to one another using WHIP, ERA, BB/9, HR/9, and H/9. Not that these metrics alone tell you the sole offensive value of a pitcher, I just chose them for fun. (FYI for non-baseball fans, for all of these metrics a lower number is preferable).

Top 5 Pitcher Metrics Heatmap

I'd love to do many more draft visualizations and maybe even dip into some KBO numbers, but for now I'm going to call it a night! Thanks for stopping by.

🛠️ Dynamic HTML Titles in React with NFL's Helmet

Jaken Herman — Fri, 27 Sep 2019 05:19:46 +0000

This post was originally published on my website at jakenherman.com

Using React through create-react-app is great, but when we consider that it will create a single-page application,
we begin to realize that changing properties in the document head of our html file is seemingly not so easy to do - but that
could not be further from the truth.

react-helmet is a reusable React component created by the NFL that can manage all of your changes to the document head, and it could
not be any simpler to use. It supports server-side rendering, and while this blog post is focused solely on changing HTML title tags,
react-helmet supports all valid head tags: title, base, meta, link, script, noscript, and style tags.

Let's quit talking about it and let's get into the code. First, create a new create-react-app application (named whatever you want) and open it up in your favorite
text editor (if you don't know how to do this, see the official create-react-app documentation

Now that you're in your project, delete the content from the pre-generated App.js file and replace the file with this:

import React from 'react';
import './App.css';

function App() {
  return (
    <div className="App">
      <h1>Hello World</h1>
    </div>
  );
}

export default App;

Because we haven't made any modifications to the document title yet, the title within the tab should be "React App" by default. For this simple example, we're going to change the title based on a certain state within our App component. So, let's modify our functional component App to be a class component, and give it a state object that will hold the value we'd like our title to be:

import React from 'react';
import './App.css';

class App extends React.Component {

  constructor(props) {
    super(props);
    this.state = {
      titleName: ''
    };
  }

  render () {
    return (
      <div className="App">
        <h1>Hello World</h1>
      </div>
    );
  }
}

export default App;

Now this will, of course, make no change to the title at this point (after all, we haven't even installed react-helmet yet!), but we're just setting up our project so when we get to the react-helmet part, it's much more satisfying. What I'd like to do is add an input field that allows the user to type in what they would like the title of the tab to be. So we're going to create an input and in the onChange of that input, we're going to update our state's titleName key's value to the value within the input, like so:

class App extends React.Component {

  constructor(props) {
    super(props);
    this.state = {
      titleName: ''
    };
  }

  changeTitle(ev) {
    this.setState({
      titleName: ev.target.value
    });
  }

  render () {
    return (
      <div className="App">
        <h1>{this.state.titleName}</h1>
        <input onChange={this.changeTitle.bind(this)}></input>
      </div>
    );
  }
}

As you can see, I threw the this.state.titleName in an <h1> so we would have quick-and-easy proof that our state is being updated when the input's onChange event is fired.

Now, for the fun part. Open up your CLI and run the command:

  $ npm i react-helmet

  # or, using Yarn:
  $ yarn add react-helmet

Now that react-helmet has been added to our project, we can add it to our <App /> component. To do this, we're first going to simply import the component, then just like we would in a typical HTML file, we're going to put the title information at the very top of our render() return, only instead of wrapping it in a <head> tag, we're going to wrap it in <Helmet> tags. And of course, for the <title>'s value, we're going to set it to this.state.titleName:

import React from 'react';
import { Helmet } from 'react-helmet';

class App extends React.Component {

  constructor(props) {
    super(props);
    this.state = {
      titleName: ''
    };
  }

  changeTitle(ev) {
    this.setState({
      titleName: ev.target.value
    });
  }

  render () {
    return (
      <div className="App">
        <Helmet>
          <title>{this.state.titleName}</title>
        </Helmet>
        <input onChange={this.changeTitle.bind(this)}></input>
      </div>
    );
  }
}

export default App;

Now when changes are made to the input field, you can see the html title changes in the browser tab:

<Helmet> can be used on any components, just keep in mind that child components will always override and helmet data passed through their parent components.

Thanks for reading, folks. Hope this taught you something.

Setting up Automatic React Application Deploys on Heroku Dynos

Jaken Herman — Wed, 25 Sep 2019 21:56:39 +0000

This post was originally shared on my website jakenherman.com.

Per the sub-title, this is "Part 1". In this series, we're going to build out a community market listing react application for MLB The Show 19 and set up an automatic pipeline to build and deploy our React application from a GitHub repository to a Heroku Dyno. In this post we will scaffold out the react app and get the automatic deployment set up for Heroku, which will prepare ourselves to create the components necessary to list out all listings for MLB The Show 19's Community Market. Why MLB The Show 19? Because... it's baseball. If you're not familiar with MLB The Show 19 - it's a baseball video game for PlayStation 4 and it has a community market that allows players to list baseball cards, stadiums, and equipment that other players can buy to use for their team. In this project, we will only build out listings for baseball cards (i.e. players), not stadiums or equipment or anything else. If that is something that interests you, I would highly recommend you extend the application to meet your needs.

The first thing we need to do to get started is to create a GitHub repository to have source control over our application and to have a place to store our code. To do this, go to GitHub.com and create a GitHub repository. Then, to get that repository on your local machine, use either a git GUI program or just use the command line interface and run the following:

git clone https://www.github.com/<path_to_your_project>

Then, change directories to your GitHub repository by running:

cd <your_project_name>

The next thing we need to do is actually get into the meat and potatoes of the application. We need to build something to put on our newly created GitHub repository. To do this, we need to create a new react application. Open up your command line interface and run the command:

 npx create-react-app mlb-the-show-community-market-listings

This command will install react, react-dom, react-scripts, and a few other packages that you will find useful. create-react-app is a facebook-supported way to create single-page React applications that many folks in the front-end community use. Unlike next, razzle, and a few other popular server-side rendering frameworks, CRA renders content on the client-side, which could have some downsides in performance, but we are not necessarily worried about that for the purposes of this project.

Now that your application has been created, let's just leave it at that - we will make code changes in the next post. For right now, we're going to check in the project as-is. So, via some git GUI or command line, commit your changes and push your code to your GitHub repository:

git add .
git commit -m 'initial commit'
git push origin master

We want our Heroku Dyno to rebuild our application every time a change is made to the master branch on our GitHub repository. But before we set this up, we need to create a Heroku Pipeline! Assuming you already have a Heroku application created, navigate to dashboard.heroku.com/apps, then select "New" followed by "Create new pipeline". In the pipeline name input field, type 'mlb-the-show-cm-listings'. Next, set yourself to be the Pipeline owner, then in the area that says "Connect to GitHub", connect your GitHub account to this Heroku pipeline. Once you've connected your GitHub account, select the GitHub repository we created earlier in the post by searching for the repository name, then press the "Connect" button. Once your GitHub repository has been connected, press the "Create pipeline" button.

Once your pipeline has been created, you will see a page that has three "steps": Review Apps, Staging, Production. In the card underneath the "Staging" step, press the "Add app..." button, followed by the purple "Create new app..." button. In the app name, you'll have to think of something on your own, as heroku app names must be unique. Once you've decided on a name, press the "Create app" button to finalize the app creation.

Now under your "Staging" area, the card you see will contain your newly created app. Click on your app name under the "Staging" area to open the Heroku app, then go to "Settings". Scroll down until you see the section labeled "Buildpacks". Press the purple "Add buildpack" button, then select the nodejs buildpack from the list of officially supported buildpacks, then press "Save changes".

Next, navigate away from "Settings" by clicking on the "Deploy" tab. Scroll down until you reach the section labeled "Automatic deploys". Press the gray "Enable Automatic Deploys" button. You will see the text change to read

Automatic deploys from master are enabled

Now, we just need to trigger the deploy. Let's make a change to our project and commit/push the changes so our Heroku deploy will be triggered.

Open the src folder of your React app we created earlier in this post, and in App.js, change the line that says:

<p>
  Edit <code>src/App.js</code> and save to reload.
</p>

<h1>Hello Heroku!</h1>

Next, via some git GUI or command line, commit your changes and push your code to your GitHub repository:

git add .
git commit -m 'trigger heroku deploy'
git push origin master

Now navigate to your heroku app's activity page to see if a build was triggered: https://dashboard.heroku.com/apps/<your_app_name>/activity. If the build failed due to a message similar to this

A Node.js app on Heroku requires a 'package.json' at the root of the directory structure.

then all you need to do is make sure your github repository doesn't consist of another folder containing your react app rather than the repository containing the react app itself.

Another common issue is having an outdated Yarn lockfile, so if you still get a build failure, go to your command line (within your react app directory), and run the following commands:

yarn install
git add yarn.lock
git commit -m 'updated yarn lockfile'
git push origin master

If you don't have a failure, you will see "Build in progress..." for a while, which will then change to "Build succeeded". Once you have a "Build succeed", a new activity will be created on your activity feed and it will say "Deployed SHA_OF_YOUR_COMMIT".

So that's great - we've set up a Heroku dyno to automatically deploy our react application when a change is made. The only problem is... where does it deploy to? Navigate away from the "Activity" tab and go to "Settings" again. Scroll down until you see "Domains and certificates". In the "Domain" section, you will see a line like:

Your app can be found at

Navigating to that domain address will show your application. Keep in mind, you can add a custom domain at any point.

Fantastic - now we've got a react app automatically deploying to a Heroku dyno, now we just need that react app to do something cool! In the next post, we'll begin creating the React components necessary to view the Community Market listings.

DailyUI Challenge 002

Jaken Herman — Wed, 14 Aug 2019 16:32:25 +0000

DailyUI challenge 002 - Design a credit card checkout form or page. Did this one without a wire-framing tool - instead opted to just use HTML, CSS, and JavaScript. I only worked on it for about an hour, so I'm not too upset with the results. The card type icon (Visa, MasterCard, AMEX, etc. does change depending on the start of the card number).

Things I could improve on:

The fonts are pretty ugly, I'd like to spend more time browsing available fonts.
Responsiveness. Because this was just part of a challenge and not production code, I did not consider mobile viewing in the design.

https://lnkd.in/gMr9VTq