I’m pleased to announce that Learn Enough Python to Be Dangerous is now available! As usual, the online course features both book-length text (approximately 450 pages print-equivalent) and embedded streaming videos (nearly 9 hours’ worth), as well as integrated progress tracking and over 100 exercises. It is also available as a print edition and ebook and as a standalone video bundle. The only prerequisites for Learn Enough Python to Be Dangerous are the developer tools covered by the Learn Enough Command Line, Text Editor, and Git tutorials.

In a previous post, we told you about the print version of Learn Enough Developer Tools to Be Dangerous (in partnership with Pearson Education), which combines the material in the Learn Enough ebooks on Command Line, Text Editor, and Git.

I’m now pleased to announce the availability of two more volumes, one combining the material from the Learn Enough tutorials on HTML and CSS & Layout and another with the contents of our JavaScript tutorial. That brings the number of print versions to three (the links are to InformIT, Pearson’s direct-sales website):¹

1. Learn Enough Developer Tools to Be Dangerous by Michael Hartl
2. Learn Enough HTML, CSS and Layout to Be Dangerous by Lee Donahoe and Michael Hartl
3. Learn Enough JavaScript to Be Dangerous by Michael Hartl

(Note that the contents of both the print versions and Pearson’s eBook versions are virtually identical to the materials available at the Learn Enough website, but this is a great option for anyone who prefers print editions.)

For a limited time, you can also get 45% off using the discount code BACKTOLEARN during checkout (Figure 1). (A couple of Learn Enough titles even made the front page of the Back to Learn promotion page Figure 2)!) After September 14, 2022, you can still use the code LEARNENOUGH to get 35% off (Figure 3).

Enjoy!

Figure 1: Entering the BACKTOLEARN discount code.

Figure 2: Learn Enough on the Back to Learn promotion page!

Figure 3: Entering the LEARNENOUGH discount code.

I’m excited to share the news that Learn Enough recently accepted an acquisition offer from a private equity firm run by entrepreneur and longtime Ruby on Rails community member Jonathan Siegel. As part of this, Learn Enough is teaming up to offer an accredited degree in computer science through recently founded Hamming College, for which I am serving as an advisor.

Although the other Learn Enough founders and I have handed over day-to-day operations of Learn Enough and the Rails Tutorial to Jonathan and his team, we have continued producing new tutorial materials, including the 7th edition of the Ruby on Rails Tutorial and a major new chapter + video on CSS grid. We have also signed a deal to publish our tutorials through Pearson Education, including print versions and videos through its online portal. Finally, I am currently working on Learn Enough Python to Be Dangerous and hope to release the book and accompanying videos later this year. Update: Learn Enough Python to Be Dangerous has been released!

A surprise inquiry

Jonathan Siegel and I have known each other for over 15 years. We first met in 2006 at one of the first Ruby on Rails training courses, taught by Mike Clark and Programming Ruby author Dave Thomas. Jonathan went on to found a series of successful Rails-based companies, while I ended up coauthoring a Rails tutorial called RailsSpace and then produced seven editions of the Ruby on Rails Tutorial. Jonathan and I kept in touch over the years, so when I heard from him a few months ago I wasn’t all that surprised. I was surprised, however, at the subject of his inquiry, which was to explore a possible acquisition.

My first step was to discuss the possibility with the other Learn Enough founders, Lee Donahoe and Nick Merwin. With the publication of the Learn Enough tutorials on CSS & Layout, JavaScript, and Ruby, and the publication deal with Pearson, we agreed that we’d reached a natural stopping point and were open to moving on to other things.

Our top priority was to make sure any potential acquirer really understood our business and was committed to doing right by our learners. In conversation with Jonathan and his team, we discovered that they were actually long-time learners at Learn Enough themselves, so they certainly understood what we are all about! Jonathan also has a passion for creating compelling educational opportunities, and we quickly determined that there was a good fit in terms of philosophy and values.

Having agreed that it made sense to move forward, we signed a Letter of Intent (LOI) and started the due-diligence process. It was a lot of work, but I’m pleased to report that it went about as smoothly as could reasonably be expected under the circumstances.

Hamming College

Part of Jonathan’s vision for Learn Enough and the Rails Tutorial was to take things to the next level by using the Learn Enough curriculum as part of the foundation for an accredited Bachelor of Science (B.Sc.) degree in Computer Science. The result is Hamming College, named after pioneering mathematician and computer scientist Richard Hamming, inventor of Hamming codes and winner of the Turing Award in 1968.

Here’s Jonathan’s account of how Hamming College was conceived:

Three years ago I joined the first ABA-accredited “interactive” law degree program—offered by Syracuse University. The students in the parallel residential program were unhappy with the idea that my cohort was avoiding “the Socratic method” and the somewhat cliche pressure-cooker environment of law school. When I started the mainly-online program, I was required to do the same reading, lecture hours and engagement that the on-campus students experienced—and to me, I was experiencing the pressure-cooker.

Fast forward 18 months—in the midst of COVID—and the entire campus went online. Those residential students and their instructors became fully online alongside our cohort. What I found was that my classes built for online were actually far better than the residential classes brought online. My lectures were built in bite-sized chunks, reasonably scripted and had frequent, calculated breaks to check my progress and encourage recall. My instructor class time was on Zoom, but jumped right into interactive discussion and every student had to be ready to be on call. Although the on-call feel was similar between both styles of instruction, the traditional lectures were just that—one-to-two hour long stream-of-consciousness with few interruptions. These were less enjoyable and less effective for learning—and I realized that maybe the residential students had it backwards—online learning done right can be far superior to campus learning.

With this in mind, we set out to build an online computer science program that combined the rigor of a traditional university (what I experienced in my undergraduate CompSci degree and a few years as a CompSci Ph.D.) with the joy of well-presented online material (like Learn Enough).

With the Learn Enough curriculum as a foundation, Hamming College is now offering an accredited degree in Computer Science, and is also working to offer independent college credit for Learn Enough courses.

Softcover

As some of you may know, Learn Enough is actually part of Softcover, a publishing platform for technical authors. There are no plans to change how Softcover operates, so authors of current Softcover books don’t have to do anything at this point.

If the Softcover service is ever going to be shut down, there will be ample warning and a generous sunset period. In addition, Softcover has no lock-in, so authors will always have the option to publish their works elsewhere.

I’ll continue to oversee the Softcover open-source project, which has a mature feature set and doesn’t require much in the way of further development.

What the future holds

Lee, Nick, and I are all staying around during a transitional period while I finish up the Python tutorial. I’ll also continue to serve as an advisor to Hamming College even after phasing out my day-to-day involvement in Learn Enough and the Rails Tutorial.

I have lots of ideas for projects going forward, including languages, philosophy, and reconnecting with my math and physics roots. Although I expect to take a little time off to recuperate from the push to finish Learn Enough Python, it’s likely I’ll have things to share publicly at some point. Please subscribe to my personal mailing list or follow me on Twitter if you’d like to keep in touch.

Acknowledgments

Thanks to Jonathan Siegel, John Cross, and all the other folks we worked with during this process. Everything at every stage was handled in good faith and with good cheer. A big thank-you to Josh Pigford for his generous advice and for an introduction to Joey Tran and Colby Gartin of Acceleron Law, who did a fantastic job on the legal side of the deal.

Of course, a huge thanks to my cofounders, Lee Donahoe and Nick Merwin. Finding good cofounders is extremely hard, and I got lucky. I remember thinking, shortly after I met them in 2007, “I could definitely work with these guys.” It took a few years for that to happen, but I’m glad it eventually did.

Finally, thanks to all our great learners, who have been a source of so much positive energy and inspiration over the years. Learn Enough is in great hands, and I’m confident there are good things ahead.

I’ve got an exciting announcement about Learn Enough CSS & Layout to Be Dangerous (part of a bunch of announcements alluded to in a previous post): We just released a special bonus chapter on a more recent and advanced layout technique known as CSS grid.

CSS grid is a system for making—you guessed it!—grids. The newly released grid chapter is over 100 pages long, bringing the full tutorial to over 600 pages of CSS & Layout goodness. The companion grid videos come in at nearly two hours (bringing the total for the CSS & Layout videos to almost 16 hours), and feature coauthor Lee Donahoe walking an occasionally clueless CSS newbie (me) through the many intricacies of grid.

Figure 1: Two types of layout covered by the chapter on grid.

This release is a free upgrade for previous purchasers of the CSS & Layout tutorial. Just go to your Downloads page to get the latest copy of the book or videos. It is also automatically available to All Access and CSS & Layout course subscribers on the Your Courses page.

For everyone else, there are two main ways to get the new material on CSS grid:

• CSS course subscription: The new chapter on CSS grid will be included in the individual course subscription.
• All Access subscription: The new chapter on CSS grid and the material from all the Learn Enough tutorials (including the Ruby on Rails Tutorial) are included in the Learn Enough All Access subscription. This option includes online text, streaming videos, progress tracking, exercise answers, and access to a private Slack chat group.

Figure 2: The culmination of the new chapter on grid.

No matter which option you select, we hope you enjoy the new material on CSS grid! Learn Enough CSS & Layout to Be Dangerous has always been designed to teach you how to build real-world, professional-grade websites, focusing on the most important techniques of CSS and page layout. With this new chapter on grid, it will continue to serve that purpose for many years to come.

The Ruby on Rails Tutorial is available as an online course and as a part of our All Access Subscription. Details below!

I promised in my previous post on the Rails Tutorial 7th edition that we have a lot of exciting announcements coming up. That was the first one—here’s the second one: I’m pleased to announce the publication of the print edition of Learn Enough Developer Tools to Be Dangerous, available now for Pre-Order. (If you click on that book link, be sure to use the discount code LEARNENOUGH to get 35% off when checking out. See below for details.)

Learn Enough Developer Tools to Be Dangerous, produced in cooperation with Pearson Education, combines the material in the Learn Enough ebooks on Command Line, Text Editor, and Git into one convenient volume.

Learn enough about…

• Running a terminal, entering and editing commands, and using man pages
• Manipulating and inspecting files: from basic copying to finding patterns
• Organizing files with directories
• Minimum Viable Vim and the Most Important Vim Command™
• Basic and advanced editing techniques with editors like Atom and VS Code
• Using the human-readable Markdown language for writing quick documentation
• Formatting source code and writing executable scripts
• Getting started with Git and GitHub
• Using key Git workflows: commit, push, branch, merge, and more
• Collaborating on Git projects and resolving code conflicts

Here’s how to get the print edition of Learn Enough Developer Tools to Be Dangerous:

1. Visit the Learn Enough Developer Tools page at InformIT (Pearson’s direct-sales website).
2. Select Pre-Order for the regular Book option (Figure 1). The Book + eBook Bundle is also a good deal if you don’t already have the ebooks for the individual Command Line, Text Editor, and Git tutorials, but just be aware that the contents are virtually identical to the ebooks available at learnenough.com.
3. When checking out, type in the discount code LEARNENOUGH and click the Enter Code button to get 35% off (Figure 2).
4. InformIT will automatically ship you a copy of the print edition when it comes out later this month (currently scheduled for May 26). Enjoy!

Figure 1: Selecting the print book (or Book + eBook bundle) at InformIT.

Figure 2: Entering the LEARNENOUGH discount code.

It’s been a while since I last reached out, but that’s not because we’ve been idle. Quite the opposite—we’ve been incredibly busy here at Learn Enough and have a bunch of exciting announcements to make over the next few months.

That includes my current announcement: the immediate availability of a full draft of the 7th edition of the Ruby on Rails Tutorial. For over a decade, the Ruby on Rails Tutorial has been one of the leading introductions to web development, and now it has been updated for the latest version of Rails.

After seven editions, the Rails Tutorial is pretty stable in almost every way, but there are still some great updates in the latest edition:

• Full compatibility with Rails 7
• New render status responses for compatibility with Turbo (see below)
• Improved integration tests with techniques for breaking long minitest tests into smaller pieces using Ruby classes
• Coverage of the latest (and we hope last!) way to integrate JavaScript with Rails using Importmap (no more NPM, Webpacker, or Yarn!)
• An introduction to Hotwire and Turbo for building fast and responsive sites rivaling “single-page” JavaScript apps

The first four chapters of the draft are available for free online here. Ebook and video screencasts are also available for purchase:

• The Rails Tutorial ebook (952 pages, PDF/EPUB/MOBI/HTML): Get the full draft and a free copy of the final version when it’s done. We’re offering a launch/upgrade discount of 20% off through the final launch (planned for next month).
• The Rails Tutorial ebook/screencast bundle: Get both the ebook and the video screencasts (currently in preparation). We’re offering a launch/upgrade discount of 33% off to make this valuable bundle more affordable. Note: Because the screencasts aren’t finished yet, there’s just a placeholder file for now, but with your purchase you’ll automatically get access to the downloadable video files when they’re done (probably sometime next month).

Edit: As of November 2022, we no longer offer individual purchases of ebooks/videos. Please refer to our Learn Enough page for available purchase options.

I hope you’ll take a look at the draft and let me know what you think. All bug and typo reports, no matter how small, are greatly appreciated. You can send such reports to michael@learnenough.com.

As always, we offer a 60-day, 100% money-back guarantee on all purchases.

Enjoy!

Update: The sites are back up. The problem was a breaking change in how Heroku handles DNS routing. (We hadn’t deployed a new version of our app in three days when the errors started to occur.) We have updated our configuration per a suggestion by Heroku customer support. Thanks to all our customers for their patience while this issue got resolved.

To activate closed captioning in the Learn Enough courses interface, simply go to a course video (Figure 1) and click on the CC in the video window to select “english CC” (Figure 2), with the result as seen in Figure 3. You can switch back by clicking “captions off” in the same place (Figure 4).

Figure 1: A Learn Enough course with streaming video.

Figure 2: Selecting “english CC” for closed captioning.

Figure 3: The caption itself.

Figure 4: Turning closed captioning off.

The captions are automatically generated, so there may be some minor errors compared to the audio, but they should be enough to give you the gist. Combined with the text itself, the addition of closed captioning makes the Learn Enough courses accessible to a much wider variety of people. Enjoy!

P.S. The captions aren’t currently included with downloadable videos like the Learn Enough Everything Bundle, but email us and we’ll be happy to give you copies of the generated files.

Learn Enough now has teams! Learn Enough for Teams lets members of your organization learn key software development skills at their own pace:

1. Get junior developers on the way to being senior developers
2. Train senior developers on specific technologies like Ruby and Rails
3. Teach non-developers like designers and project managers skills useful for working with developers
4. Get non-developers on the way to being developers

1 What’s included

Learn Enough Team Licenses include access to all of the Learn Enough tutorials: self-paced online courses with, streaming videos, progress tracking, exercises, and exercise answers. Subjects include the Unix command line, text editors, Git, HTML, CSS Layout, JavaScript, Ruby, and Ruby on Rails.

Team Licenses also include full download access to all of the Learn Enough ebooks and videos (a $452 value!). It’s basically the Learn Enough All Access Subscription with the ability to download course materials all rolled into one.

With Learn Enough’s OAuth integration, there’s also zero invitation management, and you’ll pay only for what you use.

Learn Enough for Teams

• Full access to all the Learn Enough courses (including the Ruby on Rails Tutorial)
• Full ebook and video download access for all team members (a $452 value!)
• Using Google OAuth means you pay only for the seats you use

2 Using Learn Enough for Teams

Getting started with Learn Enough for Teams is simple. Each team has a Team Owner, who can also be a subscriber but doesn’t have to be. The rest of this post will assume that you’re the owner in question.

2.1 Signing up

To sign up for a Learn Enough Team License, start by visiting Learn Enough for Teams and then log in to your Google Workspace account (formerly G Suite) (Figure 1).

Figure 1: Signing up for a Team License using Google OAuth.

Note: If your organization manages authentication using a different OAuth provider, please reach out to us at teams@learnenough.com so that we can get our team licenses set up to talk to your user management system.

You will be prompted to sign in with a Google account. Be sure to use the email address corresponding to your company’s Google Workspace account. For example, if I were starting a Team License for Softcover (Learn Enough’s parent company), I would use michael@softcover.io, as shown in Figure 2.

Figure 2: Selecting the account for Google OAuth.

After logging in, you’ll be redirected to the main Learn Enough for Teams signup page, where you should fill in your organization’s name, upload an optional logo, and include the number of a company credit card (Figure 3).

Figure 3: Filling in team details.

Once you complete your checkout (Figure 4), you’ll be forwarded to your team dashboard (Figure 5). Note that, as Team Owner, you won’t be charged anything initially—you pay only for the users who are invited and activated (Section 2.2). Learn Enough for Teams bills monthly and comes with a 60-day money-back guarantee.

Figure 4: Completing the Team Licenses checkout.

Figure 5: The initial team dashboard.

2.2 Inviting users

As Team Owner, you can invite new users by clicking on the Invite Users tab and entering the new member’s name and company email address (Figure 6). (Be sure to use an email address that’s part of the same Google Workspace account as in Section 2.1.)

Figure 6: Inviting a user to the team.

New users are added in a Pending state (Figure 7) and are sent an invitation to sign in using Google OAuth (Figure 8).

Figure 7: A pending team user.

Figure 8: A team user logging in with OAuth.

Upon signing in, the new user’s account is automatically activated and they are forwarded to their Learn Enough courses page (Figure 9). From there, they can start any course or download any book or video they like (Figure 10)—such as the first Learn Enough tutorial, Learn Enough Command Line to Be Dangerous (Figure 11).

Figure 9: The Learn Enough courses page.

Figure 10: Team Licenses include both courses and downloads.

Figure 11: The course for Learn Enough Command Line to Be Dangerous.

For future logins, team members can simply use the OAuth option on the login page (Figure 12).

Figure 12: The OAuth option on the login page.

2.3 That’s it!

That’s it! Your team now has full access to both the Learn Enough online courses and downloads for all of the Learn Enough ebooks and videos, including the full Ruby on Rails Tutorial.

Learn Enough for Teams is a relatively new feature that is under active development. If you have any feedback or suggestions, or would like an individual demo, please let us know at teams@learnenough.com. Thanks!

Team image used under the terms of the Creative Commons Attribution Generic 2.0 license.

As legendary Apple cofounder Steve Jobs once said: Real artists ship. What he meant was that, as tempting as it is to privately polish in perpetuity, makers must ship their work—that is, actually finish it and get it out into the world. This can be scary, because shipping means exposing your work not only to fans but also to critics. “What if people don’t like what I’ve made?” Real artists ship.

It’s important to understand that shipping is a separate skill from making. Many makers get good at making things but never learn to ship. To prevent this sad situation, the Learn Enough tutorials emphasize shipping along with making.

Shipping with a deploy script

Shipping is the real motivation for the deploy script mentioned in my previous post, “The Power of Scripting: A Deploy Script”. In particular, deploy is designed to lower as much as possible the friction associated with shipping.¹

In this spirit, this post will add a couple of the extensions proposed in “The Power of Scripting”, namely, pulling and pushing any Git changes associated with the project being deployed. The method I use in my own private version of the deploy script has always been called ship in honor of the philosophy discussed above.

Listing 1 shows where we left off (with the vertical ellipsis indicating omitted boolean method definitions). The structure of the main script is simple: we have a bunch of if-else statements that test for the project type and then issue the corresponding system command (using the Ruby system method). Our strategy in this post is to replace system with ship, and then have ship push and pull the Git repo before running the given command.

Listing 1: The final deploy script from “The Power of Scripting”. ~/bin/deploy

#!/usr/bin/env ruby
require "fileutils"

# Deploys a project.
.
.
.
# Returns true for a Git repository.
def git_repo?
  File.directory?(".git")
end

# The main script.
if softcover_book?
  system "softcover deploy"
elsif ruby_gem?
  system "rake release"
elsif ruby_web_app?
  system "git push heroku"
elsif jekyll? || git_repo?
  system "git push"
end

As it happens, all the project types supported by the deploy script in Listing 1 are typically Git repos as well. For the purposes of this post, then, we’ll assume that we can run git pull and git push with no ill effect. Handling exceptions to this case is left as an exercise to the reader.²

So, what should ship do? Since we don’t want to deploy a project without pulling in remote changes, we should run git pull first:

$ git pull

If that command succeeds, then we can run git push as well. The way to do this at the command line is using “and”, written with two ampersands:

$ git pull && git push    # Runs git push only if git pull succeeds

Finally, we can run the specific command needed by the project type in question:

$ git pull && git push && <specific command>

For example, for a Rails app, we would run this:

$ git pull && git push && git push heroku

The preceding discussion suggests defining a ship command as follows:

def ship(command)
  system "git pull && git push && #{command}"
end

This accomplishes exactly the task required: first we pull in any remote changes, then we push up any local changes, and finally we run the project-specific deployment command.

Replacing system with ship in Listing 1 then gives us the “shipping” version of our deploy script, as shown in Listing 2.

Listing 2: Deploying with ship. ~/bin/deploy

#!/usr/bin/env ruby
require "fileutils"

# Deploys a project.
.
.
.
# Returns true for a Git repository.
def git_repo?
  File.directory?(".git")
end

# Ships a product.
def ship(command)
  system "git pull && git push && #{command}"
end

# The main script.
if softcover_book?
  ship "softcover deploy"
elsif ruby_gem?
  ship "rake release"
elsif ruby_web_app?
  ship "git push heroku"
elsif jekyll? || git_repo?
  ship "git push"
end

At this point, running

$ deploy

will automatically sync up all relevant Git repos and then deploy the project to production.

By the way, you may have noticed that Listing 2 contains a minor redundancy: Jekyll sites and Git repos already have a git push as their deployment command. In that case, ship will run git push twice:

$ git pull && git push && git push

Luckily, this does no harm—running git push on an already-pushed repo just outputs “Everything up-to-date”:

$ git push && git push
Enumerating objects: 18, done.
Counting objects: 100% (18/18), done.
Delta compression using up to 4 threads
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 263.30 KiB | 26.33 MiB/s, done.
Total 11 (delta 7), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (7/7), completed with 7 local objects.
To https://github.com/softcover/learnenough-news.git
   3e7a7ff..53705ec  master -> master
Everything up-to-date

Here the first git push pushes up some changes (to GitHub, in this case), while the second git push gives the highlighted output shown.

Time to ship

That’s it! Time to make Steve Jobs proud and ship.³

To learn more about how to ship a wide variety of products, including Git repos, static Jekyll sites, dynamic JavaScript sites, and Sinatra and Rails web apps, check out the Learn Enough All Access subscription. 7-day free trial, 60-day money-back guarantee.

The specific example we’ll be looking at is an only slightly simplified version of a script that I use all the time, often multiple times per day. It’s called deploy, and its purpose is to deploy a wide variety of different project types using a method appropriate to each type. For example, deploy can be used to deploy books, static websites, Ruby gems, and Rails apps, all using the same command.

The language we’ll be using is Ruby, an elegant object-oriented programming language that’s excellent for writing shell scripts (among many other things). Because Ruby is generally easy to read, there’s a good chance you’ll be able to follow this post even if you don’t have much (or any) experience with the language. (If you’re interested in learning Ruby, check out Learn Enough Ruby to Be Dangerous and the Ruby on Rails Tutorial.) This is a useful aspect of technical sophistication: being able to read and generally understand a computer language you don’t necessarily know.

Note: In a post of this sort, it’s impossible to anticipate the exact background of every possible reader. Many clarifying links are provided, but some googling may be required; for a systematic introduction to all the relevant topics in a carefully designed order, see the Learn Enough All Access subscription (7-day free trial, 60-day money-back guarantee).

$ deploy

$ cd ~/bin             # Changes directory to bin relative to home dir ~
$ touch deploy         # Creates a new file called deploy
$ chmod +x deploy      # Changes the mode to make the script executable

$ deploy    # Doesn't do anything yet

#!/usr/bin/env ruby

File.directory?(".git")    # Returns true if .git is a directory

#!/usr/bin/env ruby

# Deploys a Git repository.
if File.directory?(".git")
  system "git push"
end

def git_repo?
  File.directory?(".git")
end

#!/usr/bin/env ruby

# Returns true for a Git repository.
def git_repo?
  File.directory?(".git")
end

# Deploys a Git repository.
if git_repo?
  system "git push"
end

if git_repo?
  system "git push"
end

if File.directory?(".git")
  system "git push"
end

def jekyll_site?
  File.directory?("_site")
end

def softcover_book?
  File.directory?("latex_styles")
end

#!/usr/bin/env ruby

# Deploys a project.

# Returns true for a Softcover book.
def softcover_book?
  File.directory?("latex_styles")
end

# Returns true for a Jekyll site.
def jekyll?
  File.directory?("_site")
end

# Returns true for a Git repository.
def git_repo?
  File.directory?(".git")
end

# The main script.
if softcover_book?
  system "softcover deploy"
elsif jekyll? || git_repo?
  system "git push"
end

require "fileutils"
Dir["*.gemspec"].any?    # Returns true if any files end in ".gemspec"

# Returns true for a Ruby gem.
def ruby_gem?
  Dir["*.gemspec"].any?
end

# Returns true for a Ruby-based web app.
# Matches Rails and Sinatra apps.
def ruby_web_app?
  File.exist?("Gemfile") && File.directory?("test") && !ruby_gem?
end

#!/usr/bin/env ruby
require "fileutils"

# Deploys a project.

# Returns true for a Softcover book.
def softcover_book?
  File.directory?("latex_styles")
end

# Returns true for a Ruby gem.
def ruby_gem?
  Dir["*.gemspec"].any?
end

# Returns true for a Ruby-based web app.
# Matches Rails and Sinatra apps.
def ruby_web_app?
  File.exist?("Gemfile") && File.directory?("test") && !ruby_gem?
end

# Returns true for a Jekyll site.
def jekyll?
  File.directory?("_site")
end

# Returns true for a Git repository.
def git_repo?
  File.directory?(".git")
end

# The main script.
if softcover_book?
  system "softcover deploy"
elsif ruby_gem?
  system "rake release"
elsif ruby_web_app?
  system "git push heroku"
elsif jekyll? || git_repo?
  system "git push"
end

$ deploy

#!/usr/bin/env ruby
require "fileutils"

# Deploys a project.
.
.
.
# Ships a product.
def ship(command)
  pull = "git pull"
  push = "git push"
  full_command = command == push ? "#{pull} && #{command}" :
                                   "#{pull} && #{push} && #{command}"
  puts   full_command
  system full_command
end

# The main script.
if softcover_book?
  ship "softcover deploy"
elsif ruby_gem?
  ship "rake release"
elsif ruby_web_app?
  ship "git push heroku"
elsif jekyll? || git_repo?
  ship "git push"
end

Ever since mighty Google came on the scene, every skilled website creator has had to know something about ranking well in search-engine results. Generally known as search-engine optimization, or SEO for short, this subject is generally considered to be fairly big and complex, with entire books and even companies dedicated to it. The core of SEO is actually quite small, though—(almost) simple enough to fit in a single tweet (Figure 1).

Figure 1: SEO in one tweet.

Because of Twitter’s (at the time) 140-character limit, I couldn’t literally fit all of SEO into a single tweet, but it’s only a slight exaggeration, and you can fit nearly all of it into one post. In line with the Pareto Principle (also known as the 80/20 Rule), you can get most of the benefits of SEO with a tiny fraction of the effort.

Two (easy?) steps

One of the reasons SEO books can run into the hundreds of pages is that they need to cover a lot of subjects, including HTML, web publishing, and website hosting. When you follow the Learn Enough tutorials, though, all the necessary subjects are automatically included. As a result, one post with two steps is all you really need.

Let’s recap the two steps from Figure 1:

1. Get the title, meta, and heading tags right.
2. Make something people want to link to.

Step 2 is up to you: undeniably a challenge, and beyond the scope of this post.

Luckily, with the right knowledge, Step 1 is relatively easy. And nearly all of it is included in Learn Enough CSS & Layout to Be Dangerous and its prerequisites, especially Learn Enough HTML to Be Dangerous. In fact, this post is adapted from an aside box called “SEO in one box” from Chapter 10 of Learn Enough CSS & Layout to Be Dangerous.

All of the HTML tags needed for a website with good SEO are discussed in Learn Enough HTML and Learn Enough CSS & Layout. The most important is probably the title tag (covered in LE CSS Section 10.3.1), which should contain a descriptive title that naturally contains the words you want to target. The next important tags are meta tags (LE CSS Section 10.3.2), which contain “meta” information that isn’t displayed to users but is readable by search engines. Finally, the page’s heading or “h” tags are important, especially the two top-level headings h1 and h2 (LE HTML Section 2.1).

Targeting the Tau

As a concrete example, let’s consider a math essay I published in 2010 that has become somewhat famous (some would say infamous) among math/science/computer nerds. The name of the essay is The Tau Manifesto,¹ and its subject is pi (the ratio of a circle’s circumference to its diameter) vs. tau (the ratio of a circle’s circumference to its radius). It also has an associated holiday, Tau Day, observed each year on June 28 (6/28 in the American calendar system).

In order to rank high on search terms like “pi is wrong”, “tau day”, “the tau manifesto”, and “michael hartl”, a good title might look something like this:

<title>
  Tau Day | No, really, pi is wrong:
  The Tau Manifesto by Michael Hartl
</title>

Next, we could add a meta tag with a more detailed description:

<meta name="description"
      content="The Tau Manifesto is dedicated to one of the most important
               numbers in mathematics…">

Finally, we could add could add h1 and h2 tags with text similar to the title:

<h1>
  No, really, pi is wrong
  The Tau Manifesto
</h1>
<h2>by Michael Hartl</h2>

(In the real site, there is a span tag to allow for styling the parts of the title differently, and the author attribution is an h3 for reasons I don’t recall. The principles, however, are the same.)

Putting everything together would give something like the HTML skeleton in Listing 1.

Listing 1: An HTML skeleton for The Tau Manifesto.

<!DOCTYPE html>
<html>
  <head>
    <title>
      Tau Day | No, really, pi is wrong: The Tau Manifesto by Michael Hartl
    </title>
    <meta name="description"
          content="The Tau Manifesto is dedicated to one of the most important
                   numbers in mathematics…">
  </head>
  <body>
    <h1>
      No, really, pi is wrong
      The Tau Manifesto
    </h1>
    <h2>by Michael Hartl</h2>
    .
    .
    .
  </body>
</html>

As noted before, making something people want to link to is up to you. Fortunately, The Tau Manifesto struck a chord (even literally), leading to a lot of inbound links. Together with its good HTML structure, this lead to ranking on the first page of Google results not only for things like “tau day” and “pi is wrong”, but even for the Greek letter “tau” itself.²

Domain keywords

If you have the luxury of tailoring your domain name to the keywords you’re targeting, an exact domain match can also help a lot. This step isn’t always possible, but when it is it can work exceptionally well, as it did with, e.g., the Rails Tutorial. And even if you don’t have an exact domain match, you can still get a lot of value out of “pretty URLs” (LE CSS Section 6.4) that include the keywords you’re targeting, such as learnenough.com/css-and-layout. Everything you need to get started with custom domains is covered in the free Learn Enough tutorial Learn Enough Custom Domains to Be Dangerous.

Off to the races

Everything in this post, although tailored a bit to search engines, is completely honest: there’s nothing in the HTML that’s not related to our site’s mission, and keywords aren’t repeated to excess. This philosophy applies even more to the main content of the page—if you’re actually writing about the subject whose keywords you’re targeting, the right word usage will emerge organically, so don’t worry about the details of your page copy. Indeed, search engines typically punish attempts to artificially manipulate the results, so any such efforts are likely to backfire.

Finally, when it comes to getting inbound links, quality content is king. Attempts to game search engines (with reciprocal link exchanges, link farms, etc.) are punished even more severely than attempts to manipulate the page copy, so don’t even try it.

SEO isn’t exactly rocket science. Using only the techniques in this post, we’ve made sites with highly ranked search results for the English words “softcover” and “coveralls”, the phrase “learn enough”, the competitive search term “rails tutorial”, the phrase “pi is wrong”, and (as already noted) even a letter in the Greek alphabet. With some work and a little luck (and maybe the Learn Enough All Access Subscription), you too could be off to the SEO races.³ Good luck!

The Learn Enough All Access Subscription includes access to all the Learn Enough tutorial courses. 7-day free trial, 100% money-back guarantee.

This is a special guest post from Kevin Gilpin of AppLand. Kevin reached out about an improvement to the Ruby on Rails Tutorial regarding an important type of database query optimization known as eager loading, which is the solution to a corresponding problem known as an “\( N+1 \) query”. I suggested he write up a post on the subject for the Learn Enough blog, and he happily agreed. I even updated the relevant section of the Rails Tutorial accordingly. Thanks to Kevin for the excellent contribution!

UPDATE: There’s now a video version narrated by Dan from AppLand!

Michael Hartl Author, the Ruby on Rails Tutorial

Working with any popular programming framework today typically means using an object-relational mapping (ORM) library like Rails’ Active Record to interact with the database. ORM systems are a definite plus for developer productivity and general happiness. They also allow a programmer to get by with a little bit less knowledge (sometimes a whole lot less) about what’s happening in between their code and the database. But that convenience comes with some pitfalls, including the common \( N+1 \) query problem. What does that mean? Read on to find out!

@user.microposts.paginate(page: params[:page])

Pitfall – The N+1 query problem

When we look under the covers, there’s a problem.

Suppose the HTML page template that uses @microposts looks something like Listing 1.

Listing 1: The Haml code to show microposts.

- @microposts.each do |post|
  %li
    = post.body
    %br
    created by
    = post.user.name
    %ul
      - post.attachments.each do |attachment|
        %li
        = attachment.url

(The code in Listing 1 uses the Haml syntax for representing HTML. Refer to the Haml documentation or use your technical sophistication to figure out the correspondence between Haml syntax and HTML tags.)

Using one of the techniques described in Box 1, we can observe the queries which are issued by this block of code. The first query that we see fetches the number of microposts for the user:

SELECT
  COUNT(*)
FROM
  "microposts"
WHERE
  (user_id = ?)

Next, there’s a query to fetch a page of microposts:

SELECT
  "microposts".*
FROM
  "microposts"
WHERE
  (user_id = 762146111)
ORDER BY
  "microposts"."created_at" DESC
LIMIT ? OFFSET ?

The LIMIT and OFFSET are the query clauses that select the page offset and the page size. Note that an ORDER BY is always required for pagination; otherwise, the OFFSET might not have the desired effect across multiple queries.

So far, so good.

But now there’s a problem. We see the two queries shown in Listing 2 and Listing 3 repeated many times—once for each micropost, in fact.

Listing 2: The SQL for finding micropost attachments.

SELECT
  "active_storage_attachments".*
FROM
  "active_storage_attachments"
WHERE
  "active_storage_attachments"."record_id" = ?
  AND "active_storage_attachments"."record_type" = ?
  AND "active_storage_attachments"."name" = ?
LIMIT
  ?

Listing 3: The SQL query for finding users associated with a micropost.

SELECT
  "users".*
FROM
  "users"
WHERE
  "users"."id" = ?
LIMIT
  ?

What’s going on? What we are seeing here is known as the \( N+1 \) query problem. The number of queries to fetch the data is not \( 1 \), as we would expect; rather, it’s \( 1 \) to fetch the page of microposts, plus an additional \( N \) queries for the users, for a total of \( N+1 \). (In this case, there are an additional \( N \) queries for the user attachments, so the total is actually \( 2N+1 \), which is even worse.)

When SQL is hand-coded, a programmer has control over which queries are issued. The downside is that there can be a lot of repetitive and mundane work (as well as security risk) required to perform simple tasks of saving and loading data. ORMs relieve programmers of that work and risk, making development faster and more secure. But because queries are issued automatically, we cannot tell by looking at one section of the code—in this case, the HTML template—which queries will be executed behind the scenes. Changes to one part of the code could change the SQL behavior of virtually any other part of the code. That’s pretty tough to handle. So, what to do?

Box 1. Active Record SQL

Figuring out what SQL your code is issuing can be tricky.

One useful tool is the mini_profiler Ruby gem. When you integrate and activate mini_profiler, it displays a breakdown of the time spent in your backend code. You can click into SQL for detailed timing of each query.

mini_profiler shows you all the queries, but it doesn’t show you which part of the code is responsible for each query. For visual debugging of web services, code, and SQL you can use the open-source AppLand framework, which consists of an open data format, data-recording clients, visualization libraries, and IDE integrations such as the AppMap extension for VSCode. The AppLand framework records the behavior of your code, either from test cases or from user interaction. The AppLand IDE extension displays the recorded data as interactive diagrams, graphs, tables, and visualizations. You can see exactly which function is generating each query, and you can navigate all the way down to the Ruby code level if you want to.

Here’s an example:

class User < ApplicationRecord
  .
  .
  .
  # Returns a user's status feed.
  def feed
    following_ids = "SELECT followed_id FROM relationships
                     WHERE  follower_id = :user_id"
    Micropost.where("user_id IN (#{following_ids})
                     OR user_id = :user_id", user_id: id)
  end
  .
  .
  .
end

Micropost.where("user_id IN (#{following_ids})
                 OR user_id = :user_id", user_id: id)

Micropost.where("user_id IN (#{following_ids})
                 OR user_id = :user_id", user_id: id)
         .includes(:user, image_attachment: :blob)

Finding N+1 query bugs

Figuring out when we have an \( N+1 \) query problem is tricky, because it’s not the type of problem that’s revealed by any mainstream testing strategy. Unit tests, functional tests, and integration tests will all happily pass whether the data is being lazy-loaded or eager-loaded. Performance tests may reveal an issue, but a single \( N+1 \) query problem, while inefficient, does not generally result in a really big performance penalty. Rather, \( N+1 \) queries are sort of like an extra weight or drag on our app, slowly adding more and more inefficiency until, as a whole, our app is noticeably slowed down.

An effective way to find \( N+1 \) query problems is to look ar the number of SQL queries that are performed in a realistic situation, such as an integration test, and compare this number with a “reasonable” expectation. Two tools, when combined together, will yield the query count for any test case in a straightforward way. These two tools are appmap-ruby and jq.

appmap-ruby

appmap is a Ruby gem that records the execution of code and writes it as a JSON file.

jq

jq is a lightweight and flexible command-line JSON processor. See the jq website for installation instructions on your system. (Mac users with Homebrew can install jq using brew install jq.)

appmap-ruby + jq

We can use the following procedure to count the number of SQL queries in a test case:

1. Run the test case with appmap-ruby enabled, which will create a JSON file containing the recorded code events.
2. Process the recorded code events through jq to count the number of SQL queries.

The steps below show how to update a generic Rails app with these tools. If you’d like to follow along with a concrete example, you can clone the Rails Tutorial sample app, follow the setup steps described in the README, and then check out the eager-loading branch:

$ git clone https://github.com/mhartl/sample_app_6th_ed.git
$ cd sample_app_6th_ed
$ git checkout eager-loading

The eager-loading branch of the reference app adds the appmap gem to its Gemfile, as shown in Listing 5.

Listing 5: Adding the appmap gem to the sample app. Gemfile

,
,
,
group :development, :test do
  gem 'sqlite3', '1.4.2'
  gem 'byebug',  '11.1.3', platforms: [:mri, :mingw, :x64_mingw]
  gem 'appmap',  '0.40.0'
end
.
.
.

To install the new gem, run bundle install as usual:

$ bundle install

A second change, already implemented in the reference app, is the addition of a YAML configuration file to be used by appmap-ruby, which appears as in Listing 6.

Listing 6: Adding an AppMap configuration file. appmap.yml

name: SampleApp
packages:
- path: app/controllers
- path: app/models
- gem: activerecord

Taking the steps shown above one at a time, the first step is to record a test case. Let’s suppose we have an integration test like microposts_interface_test.rb. Run the test with APPMAP=true:

  $ APPMAP=true bundle exec ruby -Ilib -Itest \
    test/integration/microposts_interface_test.rb

Because the sample app’s test_helper.rb file has been configured as described in the appmap minitest documentation, this test will automatically create a file called

tmp/appmap/minitest/Microposts_interface_micropost_interface.appmap.json

To get some insight into the application’s behavior, we can process this file through the jq query shown in Listing 7, which:

1. Enumerates all the code events that occurred during the test case. Code events include HTTP server requests, function calls, and SQL queries.
2. Selects just those code events that are SQL queries.
3. Counts the number of queries.

Listing 7: Processing test output using jq.

  $ jq '[.events[] | select(has("sql_query"))] | length' \
    tmp/appmap/minitest/Microposts_interface_micropost_interface.appmap.json
  237

237 queries is a lot for one test case!¹ I’ve recorded all of the 66 test cases in the Rails Sample App 6th Edition, and plotted the number of SQL queries in each test case as a histogram (Figure 1).

Figure 1: A histogram for unoptimized queries.

That 237 in Figure 1 really sticks out. Next, I have applied the eager loading fix and re-run the test cases. The number of queries drops to 72, as shown in Figure 2.

Figure 2: A histogram for optimized queries.

It’s still quite a few; maybe there is more room for optimization? I will leave that as an exercise for the reader!

(By the way, you may have noticed in Figure 2 that one of the query counts, around 120, is actually worse after being “optimized”. This is because there is a test case in the sample app, "feed should have the right posts", that loops through the posts of each of four users and checks that the user’s feed includes the post. The number of queries in this test is actually increased by adding eager loading because fetching a feed now takes three queries instead of one. But this is really an artificial scenario: the app itself never fetches \( N\times M \) feeds, and when it does fetch a feed it renders it in the view, which traverses the associations and hence benefits from eager loading.)

require 'test_helper'

class MicropostsInterfaceTest < ActionDispatch::IntegrationTest
  .
  .
  .
  test "micropost interface" do
    .
    .
    .
    # Valid submission
    content = "This micropost really ties the room together"
    image = fixture_file_upload('kitten.jpg', 'image/jpeg')
    assert_difference 'Micropost.count', 1 do
      post microposts_path, params: { micropost: { content: content,
                                                   image:   image } }
    end
    assert assigns(:micropost).image.attached?
    follow_redirect!
    assert_match content, response.body
    .
    .
    .
  end
end

assert_operator 50, :<, 100

events = AppMap.record do
    follow_redirect!
  end['events'].map { |event| OpenStruct.new(event) }

sql = events.select(&:sql_query)

assert_operator sql.count, :<, 100

require 'test_helper'

class MicropostsInterfaceTest < ActionDispatch::IntegrationTest

  def setup
    @user = users(:michael)
  end

  test "micropost interface" do
    .
    .
    .
    assert assigns(:micropost).image.attached?
    events = AppMap.record do
        follow_redirect!
      end['events'].map { |event| OpenStruct.new(event) }
    sql = events.select(&:sql_query)
    # Without the eager-loading optimization, > 100 queries are issued here.
    assert_operator sql.count, :<, 100
    assert_match content, response.body
    .
    .
    .
  end
end

$ rails test
66 tests, 344 assertions, 1 failures, 0 errors, 0 skips

class User < ApplicationRecord
  .
  .
  .
  # Returns a user's status feed.
  def feed
    following_ids = "SELECT followed_id FROM relationships
                     WHERE  follower_id = :user_id"
    Micropost.where("user_id IN (#{following_ids})
                     OR user_id = :user_id", user_id: id)
             .includes(:user, image_attachment: :blob)
  end
  .
  .
  .
end

$ rails test
66 tests, 349 assertions, 0 failures, 0 errors, 0 skips

$ irb
>> a = [1, 2, 3]
>> puts a
1
2
3
>> p a
[1, 2, 3]

One of the topics covered by the Ruby on Rails Tutorial is sending email with Rails. It can be difficult to find up-to-date resources on this subject, which is part of why I added a couple of chapters on it starting in the 4th edition of the tutorial.

For reasons described below, I’ve now updated the main chapter on sending email to make it 100% free:

• Chapter 11: Account activation
• See especially Section 11.4: Email in production.

The current service covered by the tutorial for sending emails in production is SendGrid. SendGrid has a generous free tier and generally works well for the purposes of the Rails Tutorial. There are two caveats, though:

1. SendGrid recently changed how they handle authentication, rendering the treatment of the subject in the print edition¹ obsolete.
2. I’ve had numerous reports of SendGrid accounts being immediately frozen, with long reply times from customer service. I’ve intervened repeatedly with SendGrid customer support on behalf of Rails Tutorial readers, and have also filed a ticket to find a more permanent solution. My hope is that we can find a way to preapprove Rails Tutorial–affiliated accounts, but the situation as it stands is unsustainable, and I might have to swap out SendGrid at some point. UPDATE: Based on a tip from a helpful reader and some googling around, I discovered SendGrid’s Single Sender Verification page, which explains how to add a verified Single Sender that I hope will prevent the problem described. I have updated the Ruby on Rails Tutorial accordingly.

Releasing Chapter 11 for free solves the first problem since the online version uses the latest SendGrid authentication technique (specifically, an API key in place of the previous username/password authentication).

You can consider Chapter 11 to be a general reference on sending email in production since even those not following the Ruby on Rails Tutorial can clone the sample app and check out the corresponding branch:

$ git clone https://github.com/mhartl/sample_app_6th_ed
$ git checkout account-activation

(See the sample app README for more information.)

In addition, if I end up having to swap out SendGrid for another email service, I can now simply update the freely available chapter with the new code. (I already have a working prototype using MailGun as an alternative.) Should that become necessary, I’ll plan to update this post with a note to that effect.

Please enjoy Chapter 11: Account activation and especially Section 11.4: Email in production as a free reference on sending email with Rails!

A Learn Enough reader recently reached out with this comment after finishing our first course, Learn Enough Command Line to Be Dangerous:

I feel as though I didn’t retain absolutely everything. Is that normal?

This is an excellent question. The answer is: Yes, absolutely! It’s completely normal not to retain everything the first time through.

But you need to remember things in order to use them, right? Yes, absolutely that as well. Luckily, Learn Enough has built-in methods for helping you do that.

Layers

The secret to helping you retain the material in the Learn Enough tutorials is that they are made like a layer cake, with one layer built on top of the next (Figure 1).¹

Figure 1: The Learn Enough tutorials are like a layer cake.

This means later Learn Enough tutorials reinforce the material in previous ones. For example, the second Learn Enough tutorial, Learn Enough Text Editor to Be Dangerous, uses the which command, which tells you where a particular command-line program is located on your system:

$ which ls
/bin/ls

Similarly, the third Learn Enough tutorial, Learn Enough Git to Be Dangerous, references the mv and rm commands, which are used at the command line to move and remove things, respectively. In both cases, the commands in question are covered in Learn Enough Command Line to Be Dangerous, so encountering them a second time later on reminds you what they do.

1 Cross-references FTW

But what if you already forgot about those commands the next time you encounter them? Couldn’t that be confusing? Indeed it could, which is why the Learn Enough tutorials also include lots of cross-reference links between tutorials. For example, the occurrences of which, mv, and rm mentioned above appear as in Figure 2 and Figure 3.

Figure 2: A cross-reference link for the which command in Learn Enough Text Editor to Be Dangerous.

Figure 3: A cross-reference link for the mv and rm commands in Learn Enough Git to Be Dangerous.

Those links go directly to the relevant sections of the corresponding tutorial (in this case, Learn Enough Command Line to Be Dangerous). This means that, if you’re following Learn Enough Git to Be Dangerous and need to read up on mv and rm, you’re only a click away (Figure 4). This design lets you quickly refresh your memory with the relevant material in the previous tutorial and then hit the “Back” button to continue where you left off.

Figure 4: The section in Learn Enough Command Line to Be Dangerous that covers mv and rm.

By the way, the same cross-reference technique is also used within the Learn Enough tutorials. This can be especially helpful in longer tutorials like the Ruby on Rails Tutorial. For example, an aside box in Chapter 3 of the Rails Tutorial discusses a particular aspect of the rails generate command, which is covered in a couple of sections in Chapter 3. Accordingly, there are cross-reference links to those exact sections, as shown in Figure 5.

Figure 5: Internal cross-references in the Ruby on Rails Tutorial.

How to get started with Learn Enough

One common question about Learn Enough is: Where should I start?

One possibility is to start with the first tutorial, Learn Enough Command Line to Be Dangerous. Even if you already know something about the Unix command line, you can still skim the material, skip ahead if you already know it, and then do the exercises as a refresher.

The discussion above suggests another possibility, though: just start with whichever tutorial looks most interesting or best seems to match your experience level. Whenever you run into something you don’t know, follow the cross-reference to learn about that particular subject, and maybe even decide to follow the earlier tutorial in its entirety. You can go then back and finish the one you first started. The Learn Enough course progress tracking (Figure 6) makes it especially easy to pick up where you left off.

Figure 6: The progress tracking interface for the Learn Enough courses.

No matter which way you go, you can proceed secure in the knowledge that the Learn Enough tutorials always have your back when it comes to retaining the most important material. Get started today with a 7-day free trial to the Learn Enough All Access subscription, which includes all 9 Learn Enough courses (including the full Ruby on Rails Tutorial)! Note: All Learn Enough products and courses come with a 60-day money-back guarantee.

• Chapter 1: WebSockets and Action Cable

The videos are useful by themselves and also give you a good idea of what’s included in the Learn Enough All Access subscription.

Learn Enough Action Cable is the last tutorial in the main Learn Enough tutorial sequence, so you can now find links to all the individual tutorial posts on the Learn Enough Courses page using the “Read full post” links.

The All Access subscription, available now with a 7-day free trial, includes online books and streaming videos for all the main Learn Enough tutorials. Enjoy!

• Chapter 1: From zero to deploy
• Chapter 2: A toy app
• Chapter 3: Mostly static pages

The videos are useful by themselves and also give you a good idea of what’s included in the Learn Enough All Access subscription.

The All Access subscription, available now with a 7-day free trial, includes online books and streaming videos for all the Learn Enough tutorial courses.

Enjoy!

• Chapter 1: Hello, world!
• Chapter 2: Strings
• Chapter 3: Arrays

The videos are useful by themselves and also give you a good idea of what’s included in the Learn Enough All Access subscription.

The All Access subscription, available now with a 7-day free trial, includes online books and streaming videos for all the main \href{https://www.learnenough.com/courses}{Learn Enough tutorials}.

Enjoy!

• Chapter 1: Hello, world!
• Chapter 2: Strings
• Chapter 3: Arrays

The videos are useful by themselves and also give you a good idea of what’s included in the Learn Enough All Access subscription.

The All Access subscription, available now with a 7-day free trial, includes online books and streaming videos for all the main \href{https://www.learnenough.com/courses}{Learn Enough tutorials}.

Enjoy!