Tip:
Highlight text to annotate it
X
(Matthew Cullough) This is Writing Tools on the GitHub Platform,
and that means that we are going to extract
some of the Git knowledge
and turn it just to the web flow today.
This is a training class that we're looking at offering
perhaps in the future on a more recurring basis,
getting a little bit additional to our core look at pull request
and forking and working with code
and instead today, focusing on this one specific area,
which is in support of great software:
building great documentation that supports great software.
This is something that I've invested in in part of my career here.
And as I've worked in the Java space and built applications
and thought a lot about continuous integration
and Git as version control,
it is certainly important to think about how your version control system,
the one we're looking at today, Git, and your platform for storing that code,
GitHub, supports great software because if you don't know
how to start a project, you need documentation
to fulfill that understanding.
If you need to know how to bootstrap an existing project,
that probably belongs in the Readme.
If you want to understand how a future or dev environment works,
more reason for a great use of documentation
living alongside the source code in your repositories.
We're going to begin today's talk with an important format.
So we're going to look both at platform features
as well as some specific file formats.
And the first one that we begin with today
is called “Markdown”.
Now many of you maybe familiar with this, having dabbled with it on GitHub,
but there's a lot to it, and I hope to be able to show you
a real richness of this language.
I'm going to toggle over here to this GitHub Pages site that I have,
this pages site that I have up.
And this is where we're ultimately heading to today.
We're going over here to look at this website generator
that is able to use Markdown and even the framework
called “Jekyll”.
But we need to start at the beginning,
as Lewis Caroll would say, and it is with a definition
of this GitHub Flavored Mardown right here.
We have a page for this.
It's an article in our help guide, but it's so understandable
that I literally can just begin with an example
and talk you through it from creating a file in this format.
I'm going to create a new repository like so,
and I'm going to choose in this case with githubstudent
to call this a “markdownsample”.
If you want to try some of these stuff today,
certainly feel free to create a repo along with me.
But if you're mostly just in absorption mode,
I'm definitely just kind of soak in the knowledge
about what the platform provides.
Public, markdownsample, we'll all be able to see this repository,
and I'll tell it to go ahead and start with the Readme in this,
create the repo, and now you see that this Readme
is rendered right alongside potentially other source code
that we would put in the project.
Now having these pieces in place, I want to enhance this Readme,
and I'll use the GitHub Webflow to do that.
I'll drill into this file with the .md extension
signalling that it is a markdown, click into the Readme like so,
and click 'Edit' from here.
Now that's a Markdown syntax that we could use for some headers,
but I'm going to turn it into what I like as a little bit simpler format.
There are two variations for some of the header marks.
I'll call this “Header 1”, and I'll call this “Header 2”.
I'll call this “Bullet 1”, “Bullet 2”,
and then I'll put a paragraph text here
and see what we get.
Let's just use the default commit message and commit those changes.
And here we have a rendered Readme, and at the top of the repository,
Readme is from any directory,
whether at the very root of the project itself
or subfolders are automatically rendered alongside that folder's contents.
You can imagine that this amplifies the value of writing a good Readme
both for the project itself as well as for any subdirectories
that have specific behavior or things to make people aware of.
A great example would be for me to open up a new tab
and to go to something like github.com/rails/rails
and take a look and see what this says
and what they've put in their Readme.
They provide a welcome to the project itself
and a few instructions about getting started.
That's the critical piece giving you the ability
to get started with the project easily,
and that's what belongs in a well-factored Readme.
Now you notice that they have some bits here
that look like programming syntaxes, kind of in that fix width block
and maybe even wrapped in a pretag. So let's see if we're able to do
that same thing. We're going to come back over here
to the file that we were working on just a moment ago,
we'll drill into that, and we'll try this out ourselves.
We'll put a fence, three back ticks like so,
and you see that these are already syntax highlighted,
and then we'll put a little text inside here.
We'll say, “this is code”.
And maybe even to make this look a little more like what you'd expect,
maybe a PUTS and wrap that in " "
and maybe a IF THIS kind of block here
for a bit of code, then that, we'll see what happens,
what this does in terms of syntax.
I bet it's just going to be straight up gray at this point
but still formatted as code.
Let's commit those changes, take a look, and there we go.
We have something that looks like a code block,
but it'd be even better if this could be syntax highlighted.
So let's go back in again, and use an extension
of GitHub Flavored Markdown here
and tell it that it is a specific programming language.
If we do that and we mark it as Ruby, for example,
we can then do another commit to these changes
and see that we'll get a little bit of syntax highlighting on the code
for anything that is supported by the linguist syntax highlighter and parser.
That's a wide variety of languages, but most of the standard ones are covered
is what you usually care about.
Java, HTML, CSS, Ruby, PEARL, Python, PHP,
those all have good coverage.
So this lightweight formatting,
you could say, “Great, I can put this in Readmes."
"And Matthew, I'll start taking advantage of this for my repos.”
But it goes even further because if we toggle our way back over
to the Rails project and we look down here – scrolling down,
looking at their getting started, looking at their build code
and looking at their code status over here we notice that there are hyperlinks.
And hyperlinks are easy to create and critically important
to well-formed Readmes because I think you need to point out to, for example,
the license. That's something that I feel strongly about
and perhaps over even to the build system.
So what would it look like to put a few hyperlinks into our projects?
Well, if somebody puts a link here into the chat room
and Jordan's already done that to our office hours
that comes after this, so I'm going to take and copy that to my clipboard,
I'm going to get that URL, just use that for a little bit of fun here,
and slide back over to the page, click on Edit and come down here
and call it “office hours” and say,
"You can attend our free office hours..."
"...ask me anything with a quick..."
"...registration at this link, this page."
And so I'll wrap this in square brackets, a little bit of parentheses and the URL,
and you are now viewing the syntax for hyperlinking something
in Markdown.
Let's go ahead and commit that once again,
and now we see that indeed, I can click this link
and be taken over to registration for office hours.
There is even more that you can do
with that square bracket and parentheses notation.
If you put an exclamation point in front of the square brackets,
it is an image.
But I wish to show you that there is a way to take really easy advantage
of putting this in other places in the GitHub system.
For example, now that you've been exposed
to a little bit of Markdown, maybe you're even playing with this
on a sample open source repo right now that you've created,
you could further use this syntax that you've just become accustomed to
when creating new issues.
If we were to say,
“A critical color bug..."
"...in the main user interface,”
for example, we could say,
“When browsing to the homepage of this product..."
"...I noticed the corporate logo..."
"...was blue instead of red.”
Well, that's great that you described what the problem is,
and I could clearly just submit that new issue,
but it would be really helpful
if we could have a screenshot of the same.
So let's go out to images.google.com or Standby for something like this,
and let's take a screenshot of, say, this portion of the user interface.
I saved that to my desktop. And having saved that to my desktop,
I might want to put it into this markdown.
But you're thinking, well, how would I get the file up there,
and would I then need to remember the syntax
that you just mentioned a moment ago?
So what I'm going to do is to drag and drop this JPEG file
that's on my desktop,
and when I pull this over into the comment window.
And when I do so, let me make sure I hit the right target this time
when I pull it back into here, when I drag and drop it
into this window, you'll see that it will automatically create
an upload of this image.
If I want to go old school to this, too, so I kind of want to show you
both ways depending on your browser's support for this
I could potentially go out to the desktop
and try something like this
and select it with the typical file browser.
In either of those two scenarios, whether it's, say, Safari or Chrome
that support drag and drop
or whether it's Firefox and Internet Explorer
that select by the file browser here,
in either case, it creates a markdown, a bit of syntax.
There's our exclamation points, square brackets, curly print
or curly braces or parentheses there for wrapping that syntax,
and we can click over to preview
just to be sure that that is as we wanted it to be.
And I could then do a little bit of markup on this and say,
“Bug Screenshot” just on a nice big H1 and put that comment in.
And now we have screenshots of the defect.
So this is a great way to be able to use the syntax to augment things
besides just the written pros like the Readmes
and the documentation of the project but even things like bugs.
GitHub Flavored Markdown supports one other thing that some people find
extremely enhancing to their conversations
that happen around code and changes, and that is 'emoji.'
If we use the colon character, you'll start to see
some of the completions here, but the full vocabulary is over
at emoji-cheat-sheet.com.
And if you open up this page, you'll see all the different bits
that you can use all wrapped in the colons
as I mentioned just a moment ago.
And if we come back over here, the one that I like the most
is the plus one that turns into a thumbs up like so.
So let's recap where we are before we turn the page
to the next topics that we'd like to cover today.
We understand that GitHub, the platform, has some specialized support
for this Markdown language.
Markdown is possible in files, in the repository,
possible in pull requests, comments, issue comments,
and even authoring this is a bit supported by drag and drop
for things like image selection or selecting them
from the file chooser box so that we're not always demanded
to memorize the syntax.
The cheat sheet is only a small click away right over here in the margin
of most of the comment boxes on the site.
So it's easy to access, it's easy to get to
and there are some easy references.
Further, the thing that some projects take this to is to put badges
of the build itself in the Readme.
You can link to images, and if you think creatively about this
so let's say, T-W, Twitter, let's go over here
and look at some of their projects like scalding, for example.
Some of these projects who use build integration here
put little badges that you might see from time to time in their Readme.
Now in the case of this one, you see that they've just listed out
their current version.
That's probably an artifact of their build process.
But if we look over here for, say, the Twitter bootstrap project
let's see T-W-S, bootstrap, go over to this URL
let's take a look at this one and see what's in the Readme here
just to kind of get a sense of what people tend to put in here.
We saw licenses.
This one lists out the important files that you care about,
points you over to documentation and even can use these little bits.
You see these little link icons so that you can give a link
to a specific place in these longer forum markdown documents.
That's when you hover, you click on those,
you see that there's an anchor up here in the address bar that's changing.
So the longer the document, the more important it is
to be able to use these long form references
with the anchors that are automatically generated
for each of the H1s in the document.
So let's look at another format for a moment. Let's toggle back
over to slides for a second, and let's talk about
what's possible beyond the Markdown that we've been viewing so far.
Well, we can take and put this markdown
beyond the traditional repository that we were just talking about.
Yes, yes, Matthew, I heard you put it in issues,
pull requests and comments.
But I want to extend this to the Gist platform,
which is not commonly a part of our introductory classes.
If we go over to gist.github.com, you'll see an ability to create a file
or multiple files but with much less ceremony
than that of creating an entire repository.
For example, I could say something
like my todo-list.md and make a simple list
over here using Thing 1 and Thing 2 and Thing 3.
Let's create a public gist in this case.
You notice that it's detected it as markdown by the file extension,
and so you say, “Oh, okay. Well, that is a lot easier if I just needed..."
"...a quick list that I could share with somebody else..."
"...for a very lightweight flavor of documentation.”
But I want to extend this idea beyond the simple thought
of markdown and beyond the simple bulleted list
that we just created.
There is an addition that occurred last year
to this called Task List, and we're going to do
a little bit of toggling of the syntax over here.
Let's play with this for just a second.
So we're still using some dashes to kind of indicate a bulleted list.
We're using some square brackets around this. And when I used
this special syntax, you'll notice that I can check the checkbox
and that is persisted in the backing markdown format
by putting these Xs in these square brackets over here.
It becomes a GitHub Flavored Markdown taks list.
The checkboxes themselves are creating revisions in the repository.
Do you see this say six plus such that if I refresh the page,
every one of these is making a commit to the repository to this case
in just the gist, the simple kind of one-file format repositories.
But this is also possible with files that you create on repositories
but most specifically, the one that I care about,
is I use these a lot in the first block of an issue that I file on GitHub.
And you'll notice that some hovers of any other hyperlinks
that you make to the issues that includes those tasks
will even show you the number of the tasks that are complete
and checked off.
So it's a nice way to make a progress list,
perhaps to shift a feature or something like that,
a quick checklist to say we need to do these seven things before it's done.
You don't really feel that they all belong in individual issues
so make just a simple task list at the top
and check them off as you go.
It's pretty exciting to see that because it's a very small
and lightweight thing, but it has such a tremendous impact
because you can use it across the GitHub ecosystem.
Another flavor in another format that is of increasing importance
in the software documentation world though,and note,
I'm transitioning away from talking about issues,
pull request comments and rather to the files
that comprise documentation of a software project is Asciidoc.
There is an engine behind this called AsciiDoctor,
humorous RubyGem name, that is starting to be included
in a lot of products that generates really interesting doms
and then can emit different outputs for this input format.
It is still a lightweight markup language,
and it shares some characteristics with Markdown. But its goal,
in my opinion, is to produce longer form pieces
where you have control over footnotes, potential citations,
some control over page breaks and can emit things
like doc book and generate PDFs from these.
So this is a stronger, more powerful format,
and I'd like to show you what it looks like
by first taking you over to one of the reference pages here.
This methods.co.nz page tends to be the one
that people often find for the Asciidoc homepage.
It's a lot of the documentation over here. And if I take this format,
just for example, I'm copying a little bit of this
to the clipboard, I'm going to go back over here and create yet another gist
to see what GitHub's support for this.
So I'm going to say, test.asciidoc as an extension.
You notice that it detected the proper format over here
and in fact, already has syntax highlighting for it in the editor itself.
I'll create a public gist for this, and let's see what it looks like.
Oh, wow! We even have the ability to create tables, much more control
over the sections and numbering that we do with Markdown,
and as you can see down here, foot references at the bottom
that appropriately situate themselves at the bottom of the page.
Full books have been written on this, and my experience with it is phenomenal.
I've had a great experience. I've written several books
for O'Reilly entirely in this format,
and they had a continuous integration process in the background
that constantly emitted MOBI and EPUB and a PDF file.
And the project that you're looking for, if this particularly interests you,
is Git-scribe.
It still needs a little bit of work and there may be a competitor emerging
to this soon in the field.
We'll have to see and cross our fingers.
There's a little bit of open source work on it.
But the idea is to turn this into a local tool chain as well.
It's really cool to see how this appears and renders on the website.
But what would you do if you wanted to build it locally or offline
or in your own CI system?
And that answer may be Git-scribe.
This is a tool chain that allows you
to emit those EPUBs, PDFs and MOBI files from Asciidoc
and while still all getting the same benefit
of hosting those files up on GitHub.
If you put them in a repo, you can click into them
and render them just as I did with that file a moment ago in Gist.
Now having given attention to a couple of file formats,
I want to talk about what happens as you make changes
to this text over time.
Now Prose Diff is a feature that we recently launched,
and it makes writing on this platform tremendously easier.
For example, when we're writing this file
and we make a small change to it, it's unlike code.
We don't wish to see all of the changes on a line
or an entire line marked as difference or,
in many cases, even the block of text in the raw format itself
shown as changed.
It's very hard to visualize what the end result would be
of those changes. So instead, we have this small little button
over here that makes you think about it
not just as source code but rather as its omitted form
and to see more easily what type of changes
have been made over time.
This is something that is best served by looking at an example.
So let's close down a few of these tabs
that we've been working on for a moment
and head our way back over to the text that we started
in the beginning in the markdown sample.
We have this bit of text in the Readme itself,
and I think that we should look back through some of the changes
that we recently made.
So let's go back to the series of commits,
and let's look back specifically at the most recent change
that we did.
And you notice right over here, with no effort whatsoever on my part
other than to browsing to a specific change,
you can see the rendered view of what's changed.
Now this is not that interesting yet because we added a block of text,
and that's certainly not the most complex form of change
that we can do.
So let's head back into the file and try to make this more challenging
for the diff engine. For example, let's add a hyperlink over here
on text to let's do
http://prose.io
a nice, other tool that we can reference,
and let's change this to lowercase office hours
in that situation, and for the bullet,
let's just take out this particular word.
So we're trying to make this as challenging
and have as much variety as possible with some simple text changes.
We'll commit these changes and having looked at this,
let's go back over to our top level series of commits.
I want to kind of drill back from the top series of commits,
the most recent change that we just made.
There's the #5db, and then let's look at the rendered view of this
because that's the more interesting one.
You see that the word is struck out and replaced with a simpler form.
You see that there's a small little hint underneath the block of text,
and when I hover over it, it says it has a new hyperlink,
href to prose.io and a new tag, an A tag in this case.
You notice that the single characters are struck through
in the upper to lowercase transition down here at the bottom,
which then if I give you the contrast with if we thought about this
as source code is so much easier to parse and understand
how you're altering that end result.
That rendered view is automatically enabled
on anything that is Markdown or AsciiDoc
that has changes in any repository.
There's no trick or tip or toggle to turn it on,
simply browse through a set of changes
and the Rendered button will be shown there.
That is tremendously helpful when working with this type of text
and something that I wanted to mention right alongside it.
Dare I say, it's cousin, is that there is
a soft line wrap support as well so that if you are trying
to accomplish that type of diff view and you have somebody who thinks
that hardline breaks make more sense and other people who don't wrap
the line breaks at all and somebody reformatted the file
with hardline breaks, all of that is taken into account
and wherever possible, eaten, because we don't end up
usually caring about the hard line breaks.
So the rendered view, again, continues to provide
what is the material change to the document,
not so much a view of what changed in the source code
since text and prose written in this form
deserves very special behavior
different than our code itself.
The last piece that I want to show you today is GitHub Pages.
And this would be a phenomenal opportunity
for you to put your newfound markdown skills to use.
Now GitHub Pages is a static hosting feature
that we supply at GitHub.
And we're talking about some really incredible sites
that have been created with this.
The templates that are provided have an association with a repository
and are often thought about in terms of creating documentation
or an advertising site that goes alongside
with an open source project.
But they can certainly be used for anything.
When I say anything, let me give you some examples of just what has been
created and hosted on this platform.
If I go to presentationpatterns.com, you would not necessarily think
of this as something being generated from simple static content
in a GitHub repo, but it is.
If I went to training.github.com, you might be surprised and shocked
to know that this is largely Markdown with just some really solid style sheets
behind it. This, again, is GitHub Pages.
But if I go to the honest goodness page over here,
you'll see even better examples,
things like Semantic UI, the brackets text editor;
Octopress' homepage itself, a tool that works with Jekyll
and with GitHub Pages; and even the Bootstrap website
for Twitter Bootstrap are all Markdown and HTML blended together,
hosted on this platform.
This is a great place to host some writing.
Now Jekyll is the engine.
There's a little bit of vocabulary here that we should all become familiar with.
I'll open up a new tab, and I'll go over
to this Jekyllrb site right here.
Jekyll is the engine that is being run on the GitHub site
whenever you push to a GitHub repository
that has a specially named branch called “GH-pages”.
There are a few simple directory structure rules
and file structure rules over here that make this easy to use
and that make it as simple as pushing a change
of a markdown file into a repo.
But if we want to get started with the sample site,
and we're not even interested in learning Jekyll today,
but I do say that it is a great investment of your time.
How would we do that?
Well, let's go back and look at a real example once again.
I'll start a new repository this time, and I'll call it “pages-demo” in this case
Now there's a special naming convention that I'm going to talk about
before I press Enter on this repo.
When you have a top-level repository
named “githubstudent.github.io”,
that will be hosted at this very domain name.
You notice that the first portion is my username on GitHub,
and you get one of these.
It's a specially named repository that looks just like the domain name
that it will be hosted at.
If you'd like to host anything beneath that as subfolders, we could call it
something like “test-pages” and that would be hosted at
githubstudent.github.io/test-pages.
So you can create as many sub projects, if you will, as you like.
We're going to try this top-level one now
for the sake of the example and we'll initialize it
with a Readme this time and we'll make this repository public
and create the repo and then use a GitHub Pages generator
to get ourselves the starting template to this project.
I'm going to click on the Settings tab over here, scroll down just a little bit,
and look at this, perhaps, new to you button
that is the automatic page generator.
Now we have enough time left in class, and almost everyone in here, if you wish,
can be successful in trying this out.
It'd be a great way to kind of lock in some knowledge
from today's class.
We're going to click on the automatic page generator,
and then in this body over here. This is our first little template editor
You now recognize what all this syntax means
from the very beginning of class.
We've got welcome to GitHub Pages with three hash marks.
Oh, that's an H3.
Here's our favorite hyperlink to GitHub Flavored Markdown.
I recognize that.
This down here in the body is a fence around some code sample.
We could even say that this is, perhaps, a shell
if we wanted its syntax highlighted in this specific format there.
And then a few more H3s down here, some hyperlinks to some usernames.
And let's go with this.
The idea is to get something live and hosted.
We could use the specialized editor over here, and you can repeat
this process as much as you like, and it replaces the files
that are in your repository each time you run this automatic page generator.
Any incremental changes would be done through the normal file editing process.
I'm going to choose something minimal like this one,
and, having got that one selected, I can get a preview over here
on the right-hand side.
Maybe I'll switch it out for one that's got a little bit more color on it.
Let me try this one for example. Yup, I like that.
So then I'll say publish, and it will now tell me
at the top in a little flash message at the top of the page
that within the next ten minutes or so githubstudent.github.io will be live.
And that is hyperlinked so it's easy to get to that page.
And you might say, “Okay, great. This is associated with the project."
"This is actually an easy way to host some static content."
"But what if I wanted to run something like you did, training.github.com..."
"...or Presentation Patterns?”
Well, those can all be done by putting a special file
in the root of this repository called “CNAME”,
all capital C-N-A-M-E, and in there placing the domain name
that you'd like this associated with and then just a tiny little bit
of configuration on the registrar that you host your domain name with
and point that over to GitHub Pages' IP addresses.
This is all documented and even hyperlinked
from the settings over there.
In our help article, it walks you step by step if you want to wire it
to that custom domain name, but the nice part is that
a lot of projects just host on the standard github.io
and they don't require this additional configuration that I just mentioned.
You're looking for examples. So let me show you.
Twitter.github.io in this case is a great example here.
This is kind of the advertising page for all of the open source
that Twitter hosts on our platform.
Well, what about netflix.github.io?
This is all the open source that Netflix hosts
on our GitHub platform.
They've even created little banners or advertising pieces that I think
are styled very uniquely for each of these open source projects,
and to click on one of these
takes you over to the GitHub project itself.
It's a nice front to advertise open source
in a way that's more friendly than just a repository itself.
So lots of good examples, many of these are open source
that you could borrow from.
Your markdown skills absolutely apply over here.
You have the ability to generate one of these very simply
from that settings link on the right-hand side
using the automatic page generator.
Then when you decide that you want to graduate to something
a little bit more complex, you can start structuring the files
in your repository according to the Jekyll standards.
This even has a command line engine that will migrate over from WordPress
if you wanted to bring some existing content over from,
say, a blog that you potentially host.
There's a lot of documentation on the Jekyll site,
but know that all of the core Jekyll functionality
is supported by GitHub Pages. It's just some standards to follow.
You can run this engine on your local disc,
which means that you can even preview what the changes would look like
before you push them up to GitHub if you're familiar with either
the Mac GitHub Desktop Client, Windows Desktop Client
or the command-line Git tools, and then in that repo
you can simply check what you're changing,
live view it in a local host 4000 view from your browser,
and then when satisfied with the changes,
do a Git commit and a Git push
and see those just moments later.
show up live hosted on one of these custom domain names.
That is the core of the tour
that I wanted to spend time with you on today.
And if you've enjoyed this, we'd love hearing from you
at training@github.com.
Send us some feedback on this class and if it hit the mark today.
The idea was to make this very domain specific.
And I hope that if you're interest was in writing on the GitHub platform,
you got exposed to some file formats that are supported,
Markdown and Asciidoc;
understand all the different places that those can be used,
whether issues, pull requests, files in the repo or even gists;
the ability for the platform to render these changes
in a meaningful way showing you a difference that's not just the source
but actually the rendered edition that works both for Markdown and Asciidoc,
thereby making the changes that happen to these documents over time
much more understandable.
We saw that some of it was focused specifically on tasks
with GitHub Flavored tasks, Markdown and Task Lists,
where with that simple - [ ] we can provide lists
of things that we can check off by just clicking a checkbox
and having that automatically make a commit or a change,
we can use that throughout issues or in gists.
It's quite widely supported.
And finally, we took our prose skills of things like Markdown
and we looked how those can be hosted for free on a static page,
typically one that represents advertising to an open source project
and many other cases, a blog.
There's well over a quarter million of these now hosted on GitHub.
And there's an automatic page generator that would get you started
with that process so that your first publish
of one of these pages looks really nicely styled,
and that gives you a place that you can then start practicing
your revision control skills, your ability to pull requests
on that same repo, and your ability to see those changes just moments later
live on the website.
I'd like to see if we've got success in seeing this published just yet
as a nice little crescendo to the end of class.
I know it hasn't been a full ten minutes, but I was hopeful that perhaps
it had hit just slightly before then.
But soon after class, githubstudent.github.io
will go live, and I hope that you took the opportunity
either in class or shortly after, while the knowledge is still fresh,
to try out this page generator yourself
on one of these specially formatted domain names.
It'd be really cool even if you sent us a link to that
or put it in the chat or brought more questions about this
over to our office hours over in the chat window,
and Jordan will paste this in just one more time for us again.
But at training.github.com, there is a link to our free web classes,
and at the top of the next hour, we are going to take
all of your questions in kind of a radio show like format.
So it is our office hour, bring any question
that you have around GitHub Pages or using GitHub, the platform,
using Git, very specific, narrow, deep questions about integrating
with continuous integration are also welcome.
And that is a separate event because some people choose to bring
one or two questions over to office hours
whereas they didn't need or felt like they're already up to speed
on the topic that we offer for this free class hour.
So these are distinct events. They're always back to back.
And if you have questions about GitHub Pages,
I'd love to see you in 20 minutes' time in that link that Jordan just posted.
So thank you very much for joining, and I look forward to seeing you
in a future class.
If you have suggestions or ideas on that topic,
again, I'll put up this bit of contact information
and leave this up for the next few minutes after class.
I'm going to go grab myself a cup of water
and prepare for that office hour
and hope to see many of you over there in that session.
Thanks again! See you soon.