DEV Community: Brian P. Hogan

Split Changes into Multiple Commits

Brian P. Hogan — Sun, 20 Jul 2025 17:55:14 +0000

When working on a project, you might make several changes before you commit. However, these changes might relate to different features or bug fixes. For example, you might change a file to fix a bug, but you might see something else in the file that bugs you, so you fix it while you're there.

Committing all changes at once can lead to a messy, hard-to-understand commit history or a more complex code review process. Git lets you selectively stage parts of your changes instead of adding the whole file. Using this feature, you'll get a cleaner history with smaller units of work for peers to review, as well as a chance to deal with any out-of-scope work you still want to keep but commit elsewhere.

In this tutorial, you'll explore this feature by creating a small HTML project and staging your changes interactively.

What You Need

Git installed on your local machine.

Creating a Git project

To start, create a new directory and initialize a Git repository:

$ mkdir interactive-commit-demo
$ cd interactive-commit-demo
$ git init

Then create a basic HTML file called index.html:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Interactive Commit Demo</title>
  </head>
  <body>
    <h1>Welcome to My Website</h1>
    <p>This is a paragraph.</p>
  </body>
</html>

Add and commit the file to your repository:

$ git add index.html
$ git commit -m "Initial commit with basic HTML structure"

Now make two distinct changes to the file; change the title and add a new paragraph to the body of the page:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Interactive Commit Tutorial</title>
  </head>
  <body>
    <h1>Welcome to My Website</h1>
    <p>This is a paragraph.</p>
    <p>This is a new paragraph we'll commit separately.</p>
  </body>
</html>

You made two changes to this file, but putting them in the same commit might not be best. For example, the paragraph may be a change you can get approved quickly, but the page's title might need approval by SEO experts, and you don't want it to block the publication of the paragraph.

Adding Lines Interactively with `git add -p`

Use Git's Interactive mode to add only the lines you need.

Run the following command to start an interactive commit:

$ git add -p

You'll see the patch on the screen:

diff --git a/index.html b/index.html
index 7b6e59a..0d63f4e 100644
--- a/index.html
+++ b/index.html
@@ -3,10 +3,11 @@
   <head>
     <meta charset="UTF-8">
     <meta name="viewport" content="width=device-width, initial-scale=1.0">
-    <title>Interactive Commit Demo</title>
+    <title>Interactive Commit Tutorial</title>
   </head>
   <body>
     <h1>Welcome to My Website</h1>
     <p>This is a paragraph.</p>
+    <p>This is a new paragraph we'll commit separately.</p>
   </body>
 </html>
(1/1) Stage this hunk [y,n,q,a,d,s,e,?]?

Press s to split the patch into separate pieces. The screen updates to show just the title change:

Split into 2 hunks.
@@ -3,8 +3,8 @@
   <head>
     <meta charset="UTF-8">
     <meta name="viewport" content="width=device-width, initial-scale=1.0">
-    <title>Interactive Commit Demo</title>
+    <title>Interactive Commit Tutorial</title>
   </head>
   <body>
     <h1>Welcome to My Website</h1>
     <p>This is a paragraph.</p>
(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?

Now press y to stage the title change. The next change appears, which is the change to the paragraph:

@@ -7,6 +7,7 @@
   </head>
   <body>
     <h1>Welcome to My Website</h1>
     <p>This is a paragraph.</p>
+    <p>This is a new paragraph we'll commit separately.</p>
   </body>
 </html>
(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]?

Press n to skip this change for now. You'll return to your prompt.

Use the git status command, and you'll see that there are staged changes as well as unstaged changes:

$ git status

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   index.html

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   index.html

Commit the title:

$ git commit -m "update title"

You'll see one line added and one line deleted, representing the title you changed:

[main 41d01ad] update title
 1 file changed, 1 insertion(+), 1 deletion(-)

Now, use the same process again to add the paragraph change. Execute the following command:

$ git add -p

This time, the paragraph change patch appears:

diff --git a/index.html b/index.html
index e0059db..0d63f4e 100644
--- a/index.html
+++ b/index.html
@@ -8,5 +8,6 @@
   <body>
     <h1>Welcome to My Website</h1>
     <p>This is a paragraph.</p>
+    <p>This is a new paragraph we'll commit separately.</p>
   </body>
 </html>
(1/1) Stage this hunk [y,n,q,a,d,e,?]?

Press y to stage the change.

When you return to your prompt, commit the change:

$ git commit -m "add paragraph"

Verify your commits with git log:

$ git log --oneline

You'll see your initial commit along with the two additional ones you made:

bb403d9 (HEAD -> main) add paragraph
41d01ad update title
aaa6f92 Initial commit with basic HTML structure

Using this approach, you were able to split the changes you made to a single file into two separate commits.

Sometimes, the lines may be too close together to use the automatic split feature, but you can manually edit the patch information. Consult the Git documentation on editing patches for more.

Conclusion

Splitting your changes into multiple commits gives you fine-grained control and lets you maintain a cleaner, more logical commit history, making your project easier to understand and manage.

Jump to Git Repository Root

Brian P. Hogan — Sun, 20 Jul 2025 17:51:27 +0000

If you're working on a project in the CLI and you've navigated to a subfolder, you might want a quick way to navigate back to the project root. You can use a combination of pushd and popd to jump around your shell, but there's a faster way if your project is a Git repository.

What You Need

Git installed on your machine.

Creating a Custom Command

The command git rev-parse --show-toplevel will tell you the path to the top-level directory of a repository. You can feed the result of that command to the cd command to jump to that folder:

$ cd $(git rev-parse --show-toplevel)

That command is way too long to remember, so create an alias for it.

With the Bash shell, add an alias by adding the following line to ~/.bashrc on Linux or ~/.bash_profile on macOS:

alias cdr='cd $(git rev-parse --show-toplevel)'

If you use zsh, add the alias to ~/.zshrc.

When you open a new terminal window or source your configuration file, you can use the command cdr to jump to the project root.

Conclusion

When working in a large monorepo with subprojects, like sample code for a book or course, this is a huge time saver.

Getting Page Titles for URLs with Ruby

Brian P. Hogan — Fri, 22 Apr 2022 02:21:43 +0000

If you have a URL and you'd like to get the title for the page, you'll need to fetch the URL, parse the source, and grab the text from the <title> tag. If you have a large number of URLs, you'll want to automate this process.

You can do this with a few lines of Ruby and the Nokogiri library. In this tutorial you'll create a small Ruby program to fetch the title for a web page. Then you'll modify the program to work with an external file of URLs. Finally, you'll make it more performant by using threads.

Fetching the Title from the URL

The Nokogiri library lets you use CSS selector syntax to grab nodes from HTML, and the URI library lets you quickly read a file from a URL like the cURL command does.

To do this, install the nokogiri and uri gems:

gem install uri
gem install nokogiri

Create a Ruby script called get_titles.rb and add the following code to load the libraries, open a URL as a file, send its contents to Nokogiri, and extract the value of the <title> tag:

require 'nokogiri'
require 'open-uri'

url = "https://google.com" 
URI.open(url) do |f|
  doc = Nokogiri::HTML(f)
  title = doc.at_css('title').text
  puts title
end

Save the file and run the program:

ruby get_titles.rb

The result shows the page title for Google:

Google

To do this for multiple URLs, put the URLs in an array manually, or get them from a file.

Reading URLs from a File

You may already have the list of URLs in a file, which may have come from a data export. Using Ruby's File.readlines, you can quickly convert the file into an array.

Create a new file called links.txt and add a couple of links. Make sure one of them is a bad URL; you'll make sure to handle errors.

https://google.com
https://devto

Save the file.

Now return to your get_titles.rb file and modify the code so it reads the file in line-by-line, and uses each line as a URL:

# get_titles.rb
require 'nokogiri'
require 'open-uri'

lines = File.readlines('links.txt')
lines.each do |line|
  url = line.chop
  URI.open(url) do |f|
    doc = Nokogiri::HTML(f)
    title = doc.at_css('title').text
    puts title
  end
rescue SocketError
  puts "#{url}: can't connect. Bad URL?"
end

Each line from the file will have a line break at the end, which you remove with the .chop method before storing the value in the url variable.

The URI.open method will throw a SocketError if it can't connect, and so you rescue that error with a sensible message.

Save the file and run the program again:

ruby get_titles.rb

This time you see Google's page title for the first URL, and the error message for the second:

Google
https://devto: Can't connect. Bad URL?

This version isn't the fastest when your list gets large. On a file with 200 URLs, the process took 2 minutes. A lot of the time was the network latency. Each request takes some time to resolve and get the results.

Let's make it faster.

Processing URLs Concurrently

To make this process more efficient, and much faster, you'll need to use threads. And if you use threads, you'll need to think about thread pooling because if you use too many threads you'll run out of resources.

The concurrent-ruby gem makes this much less complex by giving you promises in Ruby, which have their own pooling mechanism.

Install the concurrent-ruby gem:

gem install concurrent-ruby

To use it, you'll create a "job" for each line in the file. Each job is a promise which takes a block containing the code you want to execute. Then, following the loop, you collect all of the promises and call the value method, which blocks until the promise is complete. The pattern looks like this:

# Create a job for each line
jobs = lines.map do |line|
  Concurrent::Promises.future do
    # do the work
  end
end

# get all the jobs, blocking until they all finish.
Concurrent::Promises.zip(*jobs).value!

Modify the program to include the concurrent library and create a promise for each URL read. Then get the results:

# get_titles.rb
require 'nokogiri'
require 'open-uri'
require 'concurrent'

lines = File.readlines('links.txt')
jobs = lines.map do |line|
  Concurrent::Promises.future do
    url = line.chop

    URI.open(url) do |f|
      doc = Nokogiri::HTML(f)
      title = doc.at_css('title').text
      puts title
    end
  rescue SocketError
    puts "#{url}: can't connect. Bad URL?"
  end
end

Concurrent::Promises.zip(*jobs).value

In this version of the program, you're printing the results to the screen. But you could return a value instead and print those.

This time, a file with 200 URLs took around 3 seconds to process. That's a significant speed improvement and demonstrates why concurrent processing is important for these kinds of tasks.

Conclusion

In this tutorial you used Ruby to get page titles from URLs, and you then optimized it using the concurrent-ruby library to take advantage of threads and thread pooling.

To keep exploring, read in the data from a CSV file and use the program to generate a new CSV file with the URL and the title in separate columns.

Then see if you can pull additional information out of the URLs, such as the <meta> descriptions.

Like this post? Support my writing by purchasing one of my books about software development.

Getting Good

Brian P. Hogan — Wed, 20 Oct 2021 17:21:00 +0000

So you want to get good at something in a creative field like music, writing, or even coding? Folks might tell you that you need thousands of hours of study. But that's not necessarily true. The key to getting good at something is to do it over and over while incorporating feedback along the way.

Think of the one thing you're amazing at. How long did it take you to get to your level of skill?

There are no shortcuts, but there is a strategy.

Daily Practice

Whatever you're doing, practice it daily. 30 minutes. Every day if you can.

30 min a day is 3.5 hours per week which is 182 hours a year.

It adds up. So does your skill.

If you want to write, write every day. Even if it's crap nobody sees. Write. Learning to draw? Draw every day. You don't have to show or even keep everything you do.

Want to learn to play guitar? Play every day. Nobody has to hear you all the time. It's ok to play alone.

Learning a new framework? Spend 30 minutes a day working toward that goal. You might not produce some output every day. But that's ok. You're improving your understanding and making progress. After some time, you'll get more confident and your output will improve.

I have over a thousand unfinished songs that nobody will ever hear. I do some kind of musical composition every day because I want to get better at it, and daily practice is how you do it.

Some folks say that they'd rather dedicate a day a week and have a long block of time. That's dangerous because something might come up that causes you to have to skip that day. A soccer game for your kids, a family outing, someone gets sick, or you just feel awful. If you miss that day, you lost a weeks' worth of practice. IF you do your work over the course of a week, you can miss a day and you've only lost 30 minutes.

Practice. Every. Day.

Get Feedback

Get feedback on your progress and act on it. Learning happens through feedback AND practice. Practice alone doesn't level you up, and feedback is useless if you don't incorporate it.

Writing a book? Get peer reviews along the way. Work with an editor. Have these folks check your facts as well as your writing.

Composing music? Share your progress with other musicians and ask them to tell you what they like and what they might suggest to make it better.

Learning a framework? Use your network to find people willing to give you feedback on your progress. Share your code with them and ask them for suggestions.

Get as many perspectives as you can on your work. If you've practiced enough, this will be less painful. If you haven't been practicing, this can be harder.

Then take that feedback, sit on it, digest it, and identify common themes. A trusted friend or coworker or mentor can help a lot here, helping you identify common themes. This is one of the most valuable things my editors have done with me when I write a book. I get a bunch of feedback and then together we look at places where lots of folks get stuck, or where folks disagree.

Some feedback might not be helpful, or you may disagree with it, and it's up to you how you want to act. You don't have to incorporate every piece of feedback, but you should act on it, either by using it or discarding it.

Feedback is a gift. If you ask for it, be respectful of it, even if it stings a bit.

Do more than you watch or read

Watching hours of videos of playing guitar, or mixing and mastering, or buying every coding course under the sun is not helping you get leveled up. Watching or reading hours of material to understand concepts is called passive learning and it's only part of the learning process. Passive learning, including lectures, is good for getting introduced to a topic, or for seeing how an experienced person does something. And it feels like learning.

But it's not all of learning. Remember, learning happens through practice and feedback. I can watch all the React courses out there, but if I don't do the practice of writing the code, and I don't get feedback, I won't get better. The same goes for any other skill. YouTube has videos on hanging and mudding drywall. And they're quite informative. But if you've ever tried to do this, you'll find that you can't just upload that info to your brain. You'll have to screw up quite a few areas of drywall before you start getting good at it.

So, watch the video and follow along. Then practice that part over and over. Move on to the next lesson when you're comfortable. Make the move from passive learning to active learning.

Conclusion

You don't need thousands of hours to learn a new skill. Dedicate time every day to the thing you want to do, get feedback on it, and be sure you DO more than you WATCH.

Develop a good practice plan for yourself. Put your 30 minutes on your calendar every day. Decide which days are your "passive learning" days where you'll watch videos or read papers. Then decide which are active days. Or maybe you'll do a little of both.

Finally, give yourself a break. Everything you are good at now didn't happen overnight. It happend over a lifetime with little bits at a time, where you absorbed new concepts and got practice and feedback on them. This is how we learn, and there are no shortcuts. So don't get frustrated if you don't see immediate results. You know the process now. Follow it and then, one year and 182 hours later, look back on your accomplishments.

Good luck!

Like this post? Support my writing by purchasing one of my books about software development.

Creating Unlisted Content in Hugo

Brian P. Hogan — Wed, 12 Aug 2020 14:33:02 +0000

You may want pages that are available via a direct link, but not displayed in list pages, related content, or feeds. By default, Hugo collects all content into collections that themes use to build list pages.

You can do this by adding a new piece of front matter to your pages, and then altering your themes to filter those pages out. In this tutorial you'll see exactly what queries to change, and how to change them, so you can publish your own unlisted content.

Filtering Unlisted Pages From Queries

Creating unlisted pages involves two steps: adding the front matter field, and modifying any iterations in your theme to ignore them.

In this example, we'll use unlisted: true in the front matter for a page. Create a new page called unlisted.md using the hugo command:

$ hugo new unlisted.md

Open contents/unlisted.md in your editor and change the front matter to include a new unlisted: true field. And make sure that draft is false so Hugo generates the page:

---
title: "{{ replace .Name "-" " " | title }}"
date: {{ .Date }}
draft: false
unlisted:true

You'll add this new field to any pages you wish to hide.

Now locate your template that lists pages in your site. The default one is usually located in your theme folder in layouts/_default/list.html. You'll find logic that looks like this:

 <ul>
    {{ range .Pages }}
      <li>
        <a href="{{ .RelPermalink }}">{{ .Title }}</a>
      </li>
    {{ end }}
  </ul>

This logic iterates over all the Pages in the site. It might say RegularPages or .Site.RegularPages, depending on who created the theme.

To filter out the unlisted pages, change the range query to use a where function to filter out any pages where the unlisted field is set to true:

 <ul>
    {{ range (where .Pages ".Params.unlisted" "!=" "true") }}
      <li>
        <a href="{{ .RelPermalink }}">{{ .Title }}</a></li>
    {{ end }}
  </ul>

If you have more specific templates, you'll need to change the scopes there as well. For example, a template that iterates through posts might have a range query that looks for a type of posts, rather than all pages on the site. Here's an example of that:

{{ range (where .Site.RegularPages "Type" "in" "posts").ByDate.Reverse }}

Hugo's query language doesn't support AND operations, so you'll have to nest the where functions to ensure that both conditions apply:

{{ range (where (where .Site.RegularPages "Type" "posts") ".Params.unlisted" "!=" "true").ByDate.Reverse }}

Some themes display the most recent blog posts on the site's home page. In your site's index.html template, you might have a snippet that pulls in the most recent posts, like this:

{{ range first 3 (where .Site.RegularPages "Type" "in" "posts").ByDate.Reverse }}

This is another place you'll want to add the nested where function to filter out the unlisted content:

{{ range first 3 (where (where .Site.RegularPages "Type" "posts") ".Params.unlisted" "!=" "true").ByDate.Reverse }}

You'll want to carry these changes through to any other specific list templates in your theme, including ones for tag lists and category lists.

Once you've adjusted your general range queries, you'll want to address pagination and related content.

Removing Unlisted Pages from Pagination and Related Content

If you're paginating your content, you'll use the same approach you've used before. A paginator for posts in your current theme may look like this:

{{ $paginator := .Paginate (where .Pages "Type" "posts") }}

Add the unlisted filter with a nested where:

{{ $paginator := .Paginate (where (where .Pages "Type" "posts") ".Params.unlisted" "!=" "true") }}

Finally, Hugo has a built-in feature for displaying related content on your pages. You may have a partial that looks like this:

{{ $related := .Site.RegularPages.Related . | first 5 }}
{{ with $related }}
<h3>You might also be interested in...</h3>
  <ul>
    {{ range .ByDate.Reverse }}
      <li><a href="{{ .RelPermalink }}">{{ .Title }}</a> (Published {{ .PublishDate.Format "January 2, 2006" }})</li>
     {{ end }}
  </ul>
{{ end }}

To ensure that the unlisted content is filtered out, wrap the .Site.RegularPages.Relatedfunction with a where clause:

{{ $related := (where (.Site.RegularPages.Related . ) ".Params.unlisted" "!=" "true") | first 5 }}

Now the related content excludes the unlisted content. But you might be exposing that content in your feeds.

Fixing Your RSS Feed

You've excluded your unlisted content from your pages, but don't forget about your site's RSS feed. Hugo has a default RSS template that you can override, but if you don't, Hugo uses this built-in default. That means you may accidentally expose your unlisted content through your feeds.

To override this file, create the filelayouts/_default/rss.xml in your site or in your theme and modify it to exclude the unlisted pages just like you've done with other queries.

The default template creates a $pages variable and populates it based on various conditions, such as whether this is the home page, or if the content should be limited to a certain number of records:

{{- $pctx := . -}}
{{- if .IsHome -}}{{ $pctx = .Site }}{{- end -}}
{{- $pages := slice -}}
{{- if or $.IsHome $.IsSection -}}
{{- $pages = $pctx.RegularPages -}}
{{- else -}}
{{- $pages = $pctx.Pages -}}
{{- end -}}
{{- $limit := .Site.Config.Services.RSS.Limit -}}
{{- if ge $limit 1 -}}
{{- $pages = $pages | first $limit -}}
{{- end -}}

The quickest way to hide the unlisted pages is to apply the where clause after the limit:

{{- if ge $limit 1 -}}
{{- $pages = $pages | first $limit -}}
{{- end -}}
{{- $pages = (where $pages ".Params.unlisted" "!=" "true") -}}

Be sure to use the {{- -}} notation here to suppress space before and after the line.

The entire RSS feed template with the changes looks like this:

{{- $pctx := . -}}
{{- if .IsHome -}}{{ $pctx = .Site }}{{- end -}}
{{- $pages := slice -}}
{{- if or $.IsHome $.IsSection -}}
{{- $pages = $pctx.RegularPages -}}
{{- else -}}
{{- $pages = $pctx.Pages -}}
{{- end -}}
{{- $limit := .Site.Config.Services.RSS.Limit -}}
{{- if ge $limit 1 -}}
{{- $pages = $pages | first $limit -}}
{{- end -}}
{{- $pages = (where $pages ".Params.unlisted" "!=" "true") -}}
{{- printf "<?xml version=\"1.0\" encoding=\"utf-8\" standalone=\"yes\"?>" | safeHTML }}
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>{{ if eq  .Title  .Site.Title }}{{ .Site.Title }}{{ else }}{{ with .Title }}{{.}} on {{ end }}{{ .Site.Title }}{{ end }}</title>
    <link>{{ .Permalink }}</link>
    <description>Recent content {{ if ne  .Title  .Site.Title }}{{ with .Title }}in {{.}} {{ end }}{{ end }}on {{ .Site.Title }}</description>
    <generator>Hugo -- gohugo.io</generator>{{ with .Site.LanguageCode }}
    <language>{{.}}</language>{{end}}{{ with .Site.Author.email }}
    <managingEditor>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</managingEditor>{{end}}{{ with .Site.Author.email }}
    <webMaster>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</webMaster>{{end}}{{ with .Site.Copyright }}
    <copyright>{{.}}</copyright>{{end}}{{ if not .Date.IsZero }}
    <lastBuildDate>{{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}</lastBuildDate>{{ end }}
    {{ with .OutputFormats.Get "RSS" }}
  {{ printf "<atom:link href=%q rel=\"self\" type=%q />" .Permalink .MediaType | safeHTML }}
    {{ end }}
    {{ range $pages }}
    <item>
      <title>{{ .Title }}</title>
      <link>{{ .Permalink }}</link>
      <pubDate>{{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}</pubDate>
      {{ with .Site.Author.email }}<author>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</author>{{end}}
      <guid>{{ .Permalink }}</guid>
      <description>{{ .Summary | html }}</description>
    </item>
    {{ end }}
  </channel>
</rss>

If you have other alternative formats, like a JSON feed, be sure to exclude the content in a similar way. And remember to add the unlisted: true entry to your front matter.

Conclusion

You can now add a new front matter field to your content and have it excluded from Hugo's generated content lists, but still have the pages published so you can provide people with direct links to the content.

Remember that in order for this to work, you'll need to change any place that iterates over your content, including lists for alternative content types, such as your site's automatically-generated sitemap or XML feed. Check and double check your site to ensure your unlisted content is truly unlisted before you publish.

Like this post? Support my writing by purchasing one of my books about software development.

Creating a Magic 8 Ball Game with HTML, Canvas, and JavaScript

Brian P. Hogan — Wed, 15 Apr 2020 00:14:14 +0000

The "Magic 8 Ball" is a toy shaped like the "8" ball in billiards, created in 1950. You ask a "yes" or "no" question, shake the ball, and look at the answer it provides, which you see through a window on one side of the ball.

In my book Exercises for Programmers, one of the exercises is to use arrays and random numbers to create your own Magic 8 Ball game:

Create a Magic 8 Ball game that prompts for a question and then displays either “Yes,” “No,” “Maybe,” or “Ask again later.”

One of the additional challenges in the exercise is to implement this as a GUI application. In this tutorial, you'll do just that by using HTML, JavaScript, and the Canvas API. When you're done, you'll have a Magic 8 Ball game that shows you answers when you click the ball. The end result will look like this:

The finished ball

The Canvas API lets you create 2D raster (pixel) graphics using JavaScript. You define a canvas element on the page, grab a reference to the element in JavaScript, and then use various API methods to draw lines, rectangles, and arcs to create shapes.

You'll draw the ball using the Canvas API, and then use an event handler to display random text when you click the ball. You can't modify the canvas directly once you've drawn something, so each time you click, you'll redraw the entire ball with new text.

Let's get started.

Drawing the Ball

The ball will consist of three elements: a black circle for the ball itself, a blue triangle to represent the area where the text appears, and the text itself. You'll draw the ball and the triangle first, and the

First create a new file called 8ball.html and add the following code to define a basic HTML5 skeleton with a <canvas> element in the <body> tag:

<!DOCTYPE html>
<html>
  <head><title>8 Ball</title></head>
  <body>
    <canvas height="300" width="300" id="canvas"></canvas>  
  </body>
</html>

The canvas element has a height and width defined, and an ID attribute so you can grab it with JavaScript, where you'll do all your drawing.

Next, add a <script> tag below the <canvas> element that grabs a reference to the canvas using getElementById, and a ctx variable that holds a reference to the 2D context of the canvas. This is what you'll use to draw the ball.

<canvas height="300" width="300" id="canvas"></canvas>  

<script>
const canvas = document.getElementById('canvas');
const ctx = canvas.getContext('2d');

</script>

Next, create a drawBall function to hold the logic to draw the ball on the canvas. The function accepts a string which contains the text that will appear on the ball. Add the following code to define the function and then invoke it so that the ball will eventually appear on the page:

function drawBall(words){
  // code goes here.
}

// Draw the empty ball
drawBall();

Next, write the code to create the ball itself. Start by adding the following code which draws a black filled circle on the canvas:

function drawBall(words = ""){
  // circle
  ctx.fillStyle = 'black';
  ctx.beginPath();
  ctx.arc(150, 150, 150, 0, 2 * Math.PI);
  ctx.fill();

}

This sets the fill color to black and then creates a circle using the arc function. The arc function takes the x and y coordinates for the center of the circle, followed by the radius, the starting angle, and the ending angle in radians. So in this case, you're creating the circle at 150 over, 150 down, with a radius of 150, a starting angle of 0 (the top), and an ending angle of PI * 2. JavaScript has Math.PI available out of the box.

The fill function then fills in the circle with the color set with fillStyle. The words argument has a default value of an empty string so you can call drawBall with no arguments so the ball won't display any words. This is how you'll initialize the game.

Save the file and reload the file in your browser. You'll see a black ball:

The ball

Now define the blue triangle which will contain the words. Set the color to blue, move the starting point to 150 pixels over and 50 pixels down. Then draw lines from the starting point to 50 across and 200 down, and then to 250 across and 200 down. Draw the third side by making the line end at the original point of 150 across and 50 down. Then fill the space:

function drawBall(words = ""){
...
  // triangle
  ctx.fillStyle = 'blue';
  ctx.beginPath();
  ctx.moveTo(150, 50);
  ctx.lineTo(50, 200);
  ctx.lineTo(250, 200);
  ctx.lineTo(150, 50);
  ctx.fill();

}

The triangle appears inside the ball once you save the file and reload the page:

The ball and triangle

Now let's write the game logic.

Choosing the Random Phrase

The Magic 8 Ball game logic boils down to having a list of possible phrases and choosing one at random, which you can accomplish with a very small amount of JavaScript code.

Below the const canvas line in your script block, add a constant called choices that holds the possible choices that will appear in your 8 ball. You can add more choices if you'd like.

<script>
const canvas = document.getElementById('canvas');
const choices = ["Yes", "No", "Maybe", "Ask Again"];
</script>

Then create a getRandomAnswer function that selects a random value from the array using Math.Random:

// select an answer
function getRandomAnswer(){
  let randomIndex = Math.floor(Math.random() * choices.length);
  return choices[randomIndex];
}

This generates a random number and uses it as the array index. The Math.Random() function returns a random number between 0 and 1. The index you use to select an entry in the array needs to be between 0 and the last index of the array, so you can take the length of the choices array, multiply it by Math.random(), and then round the answer down with Math.floor().

Now when you call getRandomAnswer(), you'll get a random value from the choices array. Let's hook this up to the interface.

Displaying the Result

When you click on the ball, you want the text to show up inside the triangle. To do this, you'll need to add code to the drawBall function to display the text, and create an event listener that fetches the random answer and draws the ball.

First, add the code to display the text in the triangle. Inside the drawBall function, add the following code to display the text if the words argument contains any text:

function drawBall(words = ""){
...

  // the text
  if (words !== ""){
    ctx.fillStyle = '#fff';
    ctx.font = '20px sans-serif';
    ctx.textAlign = "center";
    ctx.fillText(words, 150, 150);
  }
}

This creates a centered text area placed at 150 across and 150 down, which is in the middle of your ball.

Now tie it all together by adding the event listener.

After the call to drawBall(), add this code which listens for click events and redraws the ball, passing in the value from the getRandomAnswer() function:

// The click event that redraws the ball
canvas.addEventListener("click", (event) => {
  drawBall(getRandomAnswer());
});

Your complete project should look like the following code:

<!DOCTYPE html>
<html>
  <head><title>8 Ball</title></head>
  <body>
    <canvas height="300" width="300" id="canvas"></canvas>  
    <script>
    const canvas = document.getElementById('canvas');
    const ctx = canvas.getContext('2d');
    const choices = ["Yes", "No", "Maybe", "Ask Again"];

    function drawBall(words = ""){
      // circle
      ctx.fillStyle = 'black';
      ctx.beginPath();
      ctx.arc(150, 150, 150, 0, 2 * Math.PI);
      ctx.fill();

      // triangle
      ctx.fillStyle = 'blue';
      ctx.beginPath();
      ctx.moveTo(150, 50);
      ctx.lineTo(50, 200);
      ctx.lineTo(250, 200);
      ctx.fill();

      // the text
      if (words !== ""){
        ctx.fillStyle = '#fff';
        ctx.font = '20px sans-serif';
        ctx.textAlign = "center";
        ctx.fillText(words, 150, 150);
      }
    }

    // Draw the empty ball
    drawBall();

    // select an answer
    function getRandomAnswer(){
      let randomIndex = Math.floor(Math.random() * choices.length);
      return choices[randomIndex];
    }

    // The click event that redraws the ball
    canvas.addEventListener("click", (event) => {
      drawBall(getRandomAnswer());
    });
    </script>
  </body>
</html>

When you save and reload the page and click the ball, you'll see one of the phrases:

The finished ball

Conclusion

In this tutorial you created a basic implementation of a Magic 8 Ball game using the Canvas API. From here you can try the following additional exercises:

Instead of a solid black color, use a radial gradient for the ball. Check out the CanvasGradient documentation for more.
You can animate the canvas. Rework the code that displays the text so that it fades in and fades out. Remember that to animate the canvas, you need to redraw the canvas, so you'll need to do some kind of animation loop.
Try implementing this same application as a command-line tool in your favorite language, or as a mobile app.

Like this post? Support my writing by purchasing one of my books about software development.

Creating a Layout with CSS Grid

Brian P. Hogan — Fri, 21 Feb 2020 21:07:31 +0000

CSS Grid lets you create layouts with pure CSS, rather than relying on a third party framework.

In this tutorial you'll use CSS Grid to create a two column layout with a header and footer that looks like the following:

The two column layout you'll create

First, create a new HTML page with a typical HTML skeleton with a viewport for mobile devices:

<!DOCTYPE html>
<html lang="en-US">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>My layout</title>
  </head>
  <body>

  </body>
</html>

Inside the body tag, add a div with the class container:

<div class="container">


</div>

This container will hold the rest of the elements. You'll use CSS to constrain the container's width too.

Inside of the container, add code to define the page's header, navbar, main content region, a sidebar full of related links, and a footer:

<div class="container">

  <header class="header">
    <h1>Banner</h1>
  </header>

  <nav class="nav">
    <a href="#">Link</a>
    <a href="#">Link</a>
    <a href="#">Link</a>
    <a href="#">Link</a>
  </nav>

  <main class="main">
    <h2>Main Content</h2>

    <p>
      Lorem ipsum dolor sit, amet consectetur adipisicing elit. 
      Iste culpa vitae, sunt fugit porro magni, eos non 
      mollitia officia accusantium alias illum totam eaque 
      atque sapiente reprehenderit assumenda. Nemo, modi.
    </p>
  </main>

  <section class="sidebar">
    <h2>Related content</h2>
    <ul>
      <li>Lorem</li>
      <li>Ipsum</li>
      <li>Dolor</li>
    </uL>
  </section>

  <footer class="footer">
    <small>Copyright notice</small>
  </footer>

</div>

Each element uses an appropriate HTML sectioning element and has a class that identifies the region so you can create very specific CSS rules. You could use IDs for these, but it's a common best practice to use classes for design work and reserve IDs for elements that you'll manipulate with JavaScript.

On small screens, the default browser styles will ensure that the content is readable. There's actually nothing you need to do to define this layout to work with small screens.

Add a style element to your page in the header section to hold the stylesheet. In a larger app you'd use an external stylesheet, but keeping everything in a single file makes this project something you can reference later:

<head>
...

  <style>

  </style>
</head>

Inside the style tags, add a media query that looks for a minimum width of 700 pixels:

@media only screen and (min-width: 700px)  {


}

You'll define your layout here. All screens 700 pixels and wider will use these rules, while smaller screens won't be affected. Designing for the small screen first and then adjusting things with min-width media queries often results in much less CSS code for you to write and maintain.

The CSS Grid specification lets you define grid areas which you can then reference to position your elements. Inside the media query, add this code to define grid areas for your header, nav, main, sidebar, and footer elements:

  /* Name your sections for your grid */
  header.header { grid-area: header; }
  nav.nav {grid-area: nav;}
  main.main { grid-area: main; }
  section.sidebar { grid-area: sidebar; }
  footer.footer { grid-area: footer; }

You can name the grid areas whatever you like, but in this tutorial you'll use the same name as the CSS classes. The CSS selectors reference the element and the class, ensuring a more specific match.

Next,, define the container region with display: grid, a width, height, and margin:

  .container {
    display: grid;
    width: 80%;
    margin: 0 auto;
    height: 100%;
  }

Now use grid-template-areas to define how you want your layout to work by specifying your section names in the order you want them to appear:

  .container {

   ...

    /* Drow your grid! */
    grid-template-areas: 
      "header header"
      "nav nav"
      "main sidebar"
      "footer footer";
    }

When using grid-template-areas, you repeat the name of the region if it spans multiple columns. In this case, the header, nav, and footer regions span two columns, while the main and sidebar regions each span one.

Next, define the column widths for the grid. The main content region should be twice as wide as the sidebar. Rather than use pixels to do the math, use the fr unit, which stands for "fractional unit".

.container {
...
    grid-template-columns: 2fr 1fr;
}

Now define the heights of the rows. Set the header to 100 pixels high, the navigation bar to 30 pixels high, and the footer to 80 pixels high. The main region and sidebar should take up the remaining space. so use 1fr for that:

.container {
...
    grid-template-rows: 100px 30px 1fr 80px;
}

The complete rule looks like this:

  .container {
    display: grid;
    width: 80%;
    margin: 0 auto;
    height: 100%;, 

    /* Drow your grid! */
    grid-template-areas: 
      "header header"
      "nav nav"
      "main sidebar"
      "footer footer";

    grid-template-columns: 2fr 1fr;
    grid-template-rows: 100px 30px 1fr 80px;

  }

Save your file and test it out. You'll see your two column layout.

Conclusion

In this tutorial you created a two column layout using a small amount of code. Unlike many CSS layout libraries, CSS Grid doesn't require you to add additional HTML markup or classes. The code is cleaner and it's easier to maintain.

You can also place grids within grids. Use the same approach you used in this article to define your inner grids. Set display: grid on one of the inner elements, and define your own grid regions. You can also combine CSS Grid with Flexbox, which is a great way to style your menu.

Like this post? Support my writing by purchasing one of my books about software development.

Creating a Navigation Bar with Flexbox

Brian P. Hogan — Fri, 14 Feb 2020 01:09:43 +0000

Creating a navigation bar for a site used to be challenging, especially when you want a horizontal navigation bar on large screens. You'd need to do the math to split up your elements, account for padding and margin width, and then hope nobody wanted changes later.

With Flexbox widely available in browsers, creating your navigation bar involves much less code.

In this tutorial you'll build a navigation bar with elements evenly-spaced on large screens, and vertically stacked on small screens, and you'll build it all with minimal HTML and CSS.

Creating the HTML

Create a new HTML file called nav.html and place the following HTML skeleton in the file:

<!DOCTYPE html>
<html lang="en-US">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>My Navbar Example</title>
  </head>
  <body>

  </body>
</html>

This template defines the document's language, the character encoding, the viewport size, so mobile devices will zoom and scale the page appropriately, and the page's title.

In the <body> of the page, add a <nav> element that contains a few links:

<nav>
  <a href="#">Home</a>
  <a href="#">About</a>
  <a href="#">Products</a>
  <a href="#">Support</a>
</nav>

This navigation element only contains <a> tags. It does not contain an unordered list or other markup like you might have seen in other menu examples. This is all the markup you need to define your menu, as Flexbox can handle all of the alignment and styling. If you need to develop a more complex menu, with sections, submenus, and other elements, you might benefit from additional structural elements, but that's not the case here.

Now let's add the styles.

Styling the Menu

Styling the menu involves two steps:

Defining the placement of elements
Defining the appearance of elements

Start by defining the placement. The goal for this menu is that it displays vertically on small screens and horizontally on large screens. You'll end up writing less code if you build your CSS "mobile first"; in other words, style everything for the small screen first, and then add media queries for the larger screens.

In your nav.html file, add a <style> element to the <head> section.

<head>
...
  <style>

  </style>
</head>

In a larger project, you'd use an external stylesheet with a <link> element, but for this example, keep everything in one file so you can reference it later when you're working on your own projects.

Within the <style> section of the page, add a new definition for the nav element that defines it as a flex container, ensures its child elements are spaced apart evenly, and that the elements are stacked vertically:

nav {
  display: flex;
  justify-content: space-between;
  flex-direction: column;
}

The justify-content option ensures there's even spacing between child elements, while flex-direction determines whether child elements are displayed vertically stacked (column), or horizontally placed (row). Stacking elements vertically by default follows the "mobile first" philosophy.

Next, add a media query that targets larger displays and defines flex-direction again, but this time using the row value:

@media only screen and (min-width: 768px) {
  nav { flex-direction: row; }
}

This media query looks for screens with a minimum width of 768 pixels. In your own projects, use your browser's developer tools to simulate mobile devices and adjust the width and identify a width that works for you.

The flex container is defined, so the next step is to style the individual elements. The flex container settings you specified in the nav element's style definition apply to direct child elements only. That's one reason this code doesn't use additional markup like bulleted lists. If you did that, you'd have to make the list the flex container instead.

Add the following style definition to evenly space your elements:

nav a{
  flex: 1;
  text-align: center;
  margin: 0.25em;
  padding: 0.25em;
}

The flex property defines how the element will shrink or grow. Using flex: 1 on all of the <a> elements makes them all take up the same size. If you wanted one of the elements to be twice as wide as the others, you'd specify one of those to use flex: 2.

text-align: center centers the text inside of each element. The margin and padding ensure there's even spacing inside and outside of each element.

This defines the placement of the elements. Now define the appearance. Add a border around each navigation item, change the color, and remove the underline:

nav a{
  flex: 1;
  text-align: center;
  margin: 0.25em;
  padding: 0.25em;
  border: 1px solid #ddd;
  text-decoration: none;
  color: #555;
}

Your menu is complete. Your entire file should look like this:

<!DOCTYPE html>
<html lang="en-US">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>My Navbar Example</title>
    <style>
      nav {
        display: flex;
        justify-content: space-between;
        flex-direction: column;
      }

      @media only screen and (min-width: 768px) {
        nav { flex-direction: row; }
      }

      nav a{
        flex: 1;
        text-align: center;
        margin: 0.25em;
        padding: 0.25em;
        border: 1px solid #ddd;
        text-decoration: none;
        color: #555;
      }

    </style>
  </head>
  <body>
    <nav>
      <a href="#">Home</a>
      <a href="#">About</a>
      <a href="#">Products</a>
      <a href="#">Support</a>
    </nav>
  </body>
</html>

Verify that it does, and save the file. Open the file in your browser and you'll see your horizontal navbar:

The horizontal navbar

Shrink the browser window below 768 pixels and you'll see the vertical menu:

The horizontal navbar

Conclusion

In this tutorial you explored the Flexbox feature of CSS. Flexbox lets you build a navigation element with much less code than you could in the past, but you can also use it for things like image galleries, user interface panes, or other elements you need to align horizontally or vertically. You could even use it for entire layouts. Explore Flexbox and see how you can fit it in to your next project.

Like this post? Support my writing by purchasing one of my books about software development.

Improving tutorials with "The Code Sandwich"

Brian P. Hogan — Wed, 05 Feb 2020 23:25:09 +0000

When you're writing a tutorial that involves a lot of code, you can help your readers understand the code better by using an approach I call the "code sandwich", which looks like this:

A brief high-level description of the code.
The code itself.
A deeper dive into the tricky bits of the code.

This approach lets the reader know what they're doing and why they're doing it, and keeps them motivated and engaged.

When I'm editing content, I often come across sentences like this:

Create a new file in your editor called index.html and paste in this code:

This sentence is then followed by a large chunk of code without much context at all. The reader can certainly copy and paste the code, but the author hasn't given the learner a chance to understand what they've done. Some learners will stop here and dig in to the code, trying to figure it out themselves, while others will give up entirely.

Replacing this with the "code sandwich" approach provides two benefits:

It provides the context the learner needs
It slows the author down and gets them to think about what they're actually trying to teach.

That second bit is important; in order to teach something, you have to be able to understand it well enough to explain it. Going through the act of explaining it will then improve your own understanding of the topic. Everyone wins.

Here's an example of the "code sandwich" in action. Let's start with something you might typically see which does not follow this approach:

Create the Dockerfile in your editor and paste in the following content:
FROM nginx:alpine
COPY index.html /usr/share/nginx/html/index.html

This example provides the code, but it lacks the explanation a learner might need. Here are questions some learners might have:

What's nginx:alpine and why are we choosing this over nginx:latest or another image?
Why are we copying index.html into the /usr/share/nginx/html folder?

When you're writing technical content, you're not there to answer the learner's questions, but you can use your experience to anticipate them.

So here's how I'd recommend rewriting it using the "code sandwich" to provide the motivation, context, and detail:

Create a new text file called Dockerfile in your editor. Add the following code which defines a new Docker image that bundles your index.html page with the Nginx web server:
FROM nginx:alpine
COPY index.html /usr/share/nginx/html/index.html
This Dockerfile uses the nginx:alpine image, based on the popular Alpine Linux project. Using this image as a base results in a smaller image. By default, Nginx serves files from the /usr/share/nginx/html directory. By copying the index.html file into that directory, you don't have to modify Nginx's configuration files to point to your content.

This "code sandwich" version provides the details a reader may need to understand both what and why you're having them add the code to the project.

The next time you're writing a tutorial and you're asking someone to add some code to their project, consider using this approach. Examine the code, consider why you're having the reader add it, and explain what it does before you ask them to add it. Then dive deeper into the nuances. If you follow this pattern, your readers will have fewer questions, and you'll help them be more successful. After all, that's why you're sharing your words and code in the first place!

Make Your Writing More Approachable for Learners

Brian P. Hogan — Fri, 31 Jan 2020 03:12:45 +0000

If you're creating technical content in order to teach others, you might be tempted to use words like "easy", "simple", or "straightforward" because you want to put the learner at ease. Unfortunately, those words can have the opposite effect.

How "easy" something is depends on the learner's frame of reference. It's relative to their existing experiences. When a learner encounters something that they hear is easy, or simple, or straightforward, and they encounter a problem, they tend to internalize it; "This is easy... why am I struggling? I'm not cut out for this!" This cancels out all the good intentions you had.

When I'm editing a document, article, book, or script, I have a list of words and phrases that I try to eliminate right away. I call them "bad words". Here are some of the words that tend to be demotivational.

basically
easy
just
obvious
obviously
straightforward
simple
simply

I flag these and remove them, as in most cases they're not necessary. For example:

Simply reboot the server.

Remove "Simply" and the sentence loses no meaning and becomes tighter:

Reboot the server.

Sometimes I'll ask the author to add the context that might be missing. A lot of times, authors are making assumptions about the experience the readers have. Consider this passage:

Using Okta is a simple way to add authentication to your app. Just add it to your project. Much easier than writing your own authentication.

If you look at the documentation for Okta, it's anything but simple. And you don't "just" add it to your project. You need an account. You need to create users. You need to import the appropriate libraries, and integrate the code into your codebase.

If you've done this a hundred times, you may indeed find this easy. As an author, you have to remember that you're writing something like this to teach others. You want them to be successful. So you may have to share the details so the learner has the right frame of reference, and can make the call if it's "easy" for themselves. Consider this version instead:

Okta lets you add authentication to your app instead of writing your own logic, which will be more complicated and more prone to security vulnerabilities. In this tutorial you'll sign up for an Okta account, obtain the API keys you need, create your users, and integrate Okta's JavaScript code with your app.

This version tells the reader what's in store, including an explanation as to why Okta is a good choice over writing your own implementation.

Yes, it's much more text. But readers can skip it. Assume your readers are as smart as you. Give them all the pieces and let them decide what's easy, and what they can skip.

I suggest adding words like "easy", "simple", and others to your text editor's spelling dictionary as misspelled words so they show up as you're writing or editing.

You can also install plugins for your editor that focus on improving writing. The write-good plugin for Visual Studio Code is handy, and you can find similar plugins for Vim and Emacs. These will find some of the words I listed, among other phrases and words that cause your writing to be weaker than it could be. Be warned though; these plugins have opinions of their own, and may ignore some words while flagging others. Tweak them to find what works best for your learners. After all, you're writing for them, not just for yourself.

Using the tree Command for Software Projects

Brian P. Hogan — Wed, 22 Jan 2020 12:56:16 +0000

The tree command is a handy tool for visualizing directory structures. The default options recursively show all the files and directories in the current directory.

In this article you'll explore some of tree's options and create an alias for the tree command that you can use to visualize your software projects.

To follow along, create a Node.js project with a directory structure like this:

files
├── bin
├── src
│   └── components
└── test

Use the following command to build that structure quickly:

$ mkdir -p files/{bin,src/components,test}

Use the tree command to verify that the structure you created looks like the structure specified previously:

$ tree files

files
├── bin
├── src
│   └── components
└── test

4 directories, 0 files

Switch to the project directory:

$ cd files

Make it a Git repository, which will create a hidden .git directory:

$ git init

Use npm to create a package.json file:

$ npm init -y

Then, install Webpack as a dependency, which will create and populate the node_modules directory:

$ npm install --save webpack

Now you have a project you can use to explore tree in more detail.

Run tree on your project now and you'll see too many files to fit on the screen due to the number of files in the node_modules directories. But that's not even showing you the full story, as the tree command doesn't show hidden files by default.

Use tree -a to see everything. And since there's so much to see, pipe it to the less command so you can view the results one page at a time:

$ tree -a | less

Press Space to page through the results or press q to quit and return to the prompt.

There's a lot of output you probably don't need to see all the time. The -I flag lets you supply a list of directories to ignore:

The following command runs tree but ignores the .git directory:

$ tree -a -I '.git`

By using the pipe (|) character, you can ignore multiple directories. To ignore both the .git and node_modules directories, execute this command:

$ tree -a -I '.git|node_modules'

Now the output is more manageable:

.
├── bin
├── package-lock.json
├── package.json
├── src
│   └── components
└── test

4 directories, 2 files

The --dirsfirst option lists the directories first, then the files. If you have a project with many files in the root, this option might be useful. Run the following command:

$ tree -a -I '.git|node_modules' --dirsfirst

The output now shows the package.json and package-lock.json at the bottom of the list:

.
├── bin
├── src
│   └── components
├── test
├── package-lock.json
└── package.json

4 directories, 2 files

The command's gotten pretty long, and it'll be even longer if you need to pipe the results to the less command. To make it easier to use, use a shell alias.

If you're using Bash, add an alias to your ~/.bashrc file on Linux or your ~/.bash_profile on macOS. If you're using ZSH, add the alias to the ~/.zshrc file.

alias devtree="tree -aC -I '.git|node_modules|bower_components' --dirsfirst | less -FRX"

The -C flag for the tree command ensures that tree displays colored output. Some operating systems colorize the output by default through its own alias. The -F flag on less tells less to exit if there's only one page of results, while the -R and X flags preserve colors and other terminal characters from the tree command.

With the alias in place, you can open a new Terminal session and use the devtree command to execute the command. Navigate to the files directory you specified and run the command to try it out.

In this tutorial, you used several tree command options to customize its output, and then combined it with the less command to ensure it'll be readable. Using shell aliases, you saved the long command so it's more usable.

If you enjoyed this tutorial, check out Small Sharp Software Tools, my book on command-line tools.

Implementing "Who's in Space" with Vue

Brian P. Hogan — Tue, 14 Jan 2020 13:32:55 +0000

One of my favorite practice exercises from my book Exercises for Programmers is the "Who's In Space?" problem:

Did you know you can find out exactly who’s in space right now? The Open Notify API provides that information. Visit http://api.open-notify.org/astros.json to see not only how many people are currently in space but also their names and which spacecraft they’re on.

Create a program that pulls in this data and displays the information from this API in a tabular format.

I like this program for a few reasons. First, it's a little more challenging than "Hello World". Second, it's a chance to pull data from a remote source that doesn't require authentication, so I get to practice consuming data without having to worry about getting an API key. Finally, it's just plain fun.

Let's implement a solution to this in Vue.js. To fetch the data, we'll use Axios, a promise-based library for making web requests.

This will be a single HTML page; we don't need Vue's CLI tooling for this. We'll link to the Vue and Axios libraries in the HTML page.

Let's get started.

First, explore the API. When you make a request to http://api.open-notify.org/astros.json you'll see results that look like this:

{
  "people": [
    {
      "name": "Christina Koch",
      "craft": "ISS"
    },
...
  ],
  "number": 6,
  "message": "success"
}

The API returns an object with three keys:

people, containing the list of people in space
number, containing the number of people in space
message, containing a status message

Our app will take the people field and display it in an HTML table.

Create a new file called space.html and add an HTML template:

<!DOCTYPE html>
<html lang="en-US">
  <head>
    <meta charset="utf-8">
    <title>Who's In Space</title>
  </head>
  <body>
    <div id="app">

    </div>
  </body>
</html>

The div with the ID of app is where you'll connect your Vue instance.

Within the div tags, add an HTML table for the results:

    <div id="app">
      <table>
        <tr>
          <th>Name</th>
          <th>Craft</th>
        </tr>
      </table>

After the table, add a link to the Vue library itself:

...
    <script src="https://cdnjs.cloudflare.com/ajax/libs/vue/2.6.10/vue.js"></script>
</body>

After that line, add a link to Axios:

  <script src="https://cdnjs.cloudflare.com/ajax/libs/axios/0.19.1/axios.js"></script>

Now that the libraries are loaded, add a new script block and define a variable called url to hold the URL to the API:

  <script>
    const url = 'http://api.open-notify.org/astros.json';

  </script>

Then below the const url line, add the following code to define a new Vue instance:

    new Vue({
      el: '#app',
      data () {
        return { people: null }
      },
      created () {
        // Fetching data here
      }

    })

The el field connects, or "mounts" this Vue instance to the DOM element with the ID of app.

The data section returns an object with a field called people, which is set to null by default. The created section is where you'll fetch the data. created is one of Vue's lifecycle hooks. It fires before the Vue instance is actually connected to the DOM.

Within created, use Axios to make the request to the API and store the results in the people field of your Vue instance:

      created () {
       axios
          .get(url)
          .then(response => (this.people = response.data.people))
      }
    })

Axios gets the results and stores them in response.data. Remember that the API's response contains three keys: people, number, and message. Since you only need people, you pull down only that part of the results using dot notation.

Now that you have the data, display the results. Use Vue's v-for directive to iterate over the results, creating table rows that display the person and the craft:

    <div id="app">
      <table>
        <tr>
          <th>Name</th>
          <th>Craft</th>
        </tr>
        <!-- add this -->
        <tr v-for="person of people">
          <td>{{ person.name }}</td>
          <td>{{ person.craft }}</td>
        </tr>
        <!-- add this -->
      </table>
    </div>

The completed solution looks like this:

<!DOCTYPE html>
<html lang="en-US">
  <head>
    <meta charset="utf-8">
    <title>Who's In Space</title>
  </head>
  <body>

    <div id="app">
      <table>
        <tr>
          <th>Name</th>
          <th>Craft</th>
        </tr>
        <tr v-for="person of people">
          <td>{{ person.name }}</td>
          <td>{{ person.craft }}</td>
        </tr>
      </table>
    </div>

    <script src="https://cdnjs.cloudflare.com/ajax/libs/vue/2.6.10/vue.js"></script>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/axios/0.19.1/axios.js"></script>

  <script>
    const url = 'http://api.open-notify.org/astros.json';

    new Vue({
      el: '#app',
      data () {
        return { people: null }
      },
      created () {
        axios
          .get(url)
          .then(response => (this.people = response.data.people))
      }
    })


  </script>
  </body>
</html>

When you view the page in your browser, you'll see the results:

This implementation doesn't have any styling, but the functionality is there. In the full book, there are some additional challenges for this exercise, as well as 56 other exercises you can tackle in any language you choose.

Now that you have this working in Vue, try implementing it with another language or framework.

DEV Community: Brian P. Hogan

Split Changes into Multiple Commits

What You Need

Creating a Git project

Adding Lines Interactively with git add -p

Conclusion

Jump to Git Repository Root

What You Need

Creating a Custom Command

Conclusion

Getting Page Titles for URLs with Ruby

Fetching the Title from the URL

Reading URLs from a File

Processing URLs Concurrently

Conclusion

Getting Good

Daily Practice

Get Feedback

Do more than you watch or read

Conclusion

Creating Unlisted Content in Hugo

Filtering Unlisted Pages From Queries

Removing Unlisted Pages from Pagination and Related Content

Fixing Your RSS Feed

Conclusion

Creating a Magic 8 Ball Game with HTML, Canvas, and JavaScript

Drawing the Ball

Choosing the Random Phrase

Displaying the Result

Conclusion

Creating a Layout with CSS Grid

Conclusion

Creating a Navigation Bar with Flexbox

Creating the HTML

Styling the Menu

Conclusion

Improving tutorials with "The Code Sandwich"

Make Your Writing More Approachable for Learners

Using the tree Command for Software Projects

Implementing "Who's in Space" with Vue

Adding Lines Interactively with `git add -p`