Author’s Note: I’m currently in the process of migrating old blog posts to this new system. That may mean some links, syntax highlighting, and other details are broken or missing temporarily. Sorry for the inconvenience!
We'll do it live!
On Monday, we talked about HTML, and some of what we lose when we step away from plain old text files. We'll get back to that in a later post, but first we need to talk a little bit about website hosting in general.
I want to keep this website deliberately simple. I don't want to just drop in a bunch of tech without talking about it in a blog post. As I said in the first post, I love the idea of "bootstrapping" - the blog itself should dictate the technology of the blog.
But we're not really starting from scratch
If you go to cheerskevin.com at the time of this writing, the site is just a directory listing. There are some text files, and there are some HTML files. You can click on those links and read the content, but where does that directory listing come from in the first place? If I right-click and view-source on the directory listing, I get the following code:
<html> <head><title>Index of /</title></head> <body bgcolor="white"> <h1>Index of /</h1><hr><pre><a href="../">../</a> <a href="notes/">notes/</a> 21-Dec-2016 01:07 - <a href="index.txt">index.txt</a> 19-Dec-2016 21:41 5105 <a href="what-is-html-anyways.html">what-is-html-anyways.html</a> 21-Dec-2016 00:59 4642 <a href="what-is-html-anyways.txt">what-is-html-anyways.txt</a> 21-Dec-2016 00:59 4642 </pre><hr></body> </html>
But who wrote that code? It wasn't me! In fact, it's generated automatically by a web server called NGINX. When it sees a request for a directory, it will first look for a file called index.html. If that file exists, NGINX will use it. Otherwise, it'll simply list all of the files I have in that directory.
*(Okay, actually, it won't do that by default. You have to set
on; in your NGINX configuration, but let's ignore that part for now.*
Because that's all the web server really is doing. It just gives you a file. The only reason it renders as a webpage instead of downloading to your downloads folder is because the browser thinks it knows how to render it. Each URL here maps to a particular folder path on my server.
The point is, we already have a web server. Every valid URL here corresponds to a file I have in a particular folder. So how do the files get into those folders?
This one time, in college...
I starting doing software work in college, and right around that time, I had a PC die on me. I couldn't afford to buy a new tower, so I started doing work on an Asus Eee PC that I had bought to play with. I wish I could remember precisely which model, but this was one of the devices that really kicked off the netbook craze. Now, of course, we generally have larger but thinner screens, but for its time, the Asus held up incredibly well.
But while the netbook was wonderfully portable, it wasn't a hugely strong device. More often than not, I found myself remotely logging into a server and working directly there. And because we didn't set up any fancy deploy tools, that's what I've been doing here too.
I've been logging in and writing these files directly on the server.
We'll do it live!
I spent most of my computer time in the terminal. That is, a world of simple plain text, and no fancy diagrams. That makes it a bit easier to do things remotely. But I'm still noticing a fair bit of lag. A half-a-second between typing a key and seeing it show up on the screen starts to get a little frustrating.
But on the other hand, there's something I really do like about writing things live — it's all there for you to snoop around! There's a notes folder where I'm writing this draft as we speak! ...erm, write! Every time I save my progress, you could refresh and see what I'm up to. That's fun. That's authentic. It's immediate.
So is there a way that I could still edit things on the site in real-time, but
without dealing with the lag? Absolutely! It's called
rsync is a nice little program. Like a lot of cool software, it's
old. In fact, it's 20 years old this year. Here's how I can use it:
rsync someFile.txt cheerskevin.com:/some/folder/structure/someFile.txt
I tell it to take a file, and put it over on some other server, in some particular directory. One really nice thing that rsync does is compare the file if it already exists. If most of the file has already been uploaded, it will only send the chunk that needs to be changed.
I can also tell it to synchronize *recursively*, meaning that it should upload all files in a directory. And I can tell it not to overwrite *newer* files (in case I do add stuff from elsewhere). Finally, I can tell it to delete stuff when I do! So here's what my use case now looks like:
# Pull the files down from the site to my local machine for editing rsync -ru --del cheerskevin.com:/var/www/cheerskevin.com/ . # Push up my changes directly to the site! rsync -ru --del . cheerskevin.com:/var/www/cheerskevin.com/
Who watches the watchers?
One small problem here: now things aren't live anymore! Sure, I can type
without delay, and push stuff out when I'm done, but where's the immediacy?!
Stuff only gets sent out when I type
rsync -ru --del .
cheerskevin.com:/var/www/cheerskevin.com/, and that's a bit of a
mouthful, let's be honest.
What we really need is something that I can run in the background, which can immediately upload stuff whenever it detects a file change.
Filewatcher is a really nice little tool. You can look through the documentation at the link if you like, but here's what I'm running right now as I write this post:
filewatcher -s '**/*' 'rsync -ru --del . cheerskevin.com:/var/www/cheerskevin.com/'
Let's break that down real quick:
filewatcher- run the filewatcher program
-s- show a little spinner, so I can tell that it's running
'**/*'- watch any file in any folder, starting at the current folder (the double-asterisk means it can look in nested folders)
'rsync -ru --del . cheerskevin.com:/var/www/cheerskevin.com/'- the thing to run whenever it detects a change to one of the files
With that running in the background, the content shows up on the site less than a second after I hit "save", but I get to edit the files on my own machine. All thanks to two wonderful command line tools.
Now we're getting somewhere. We'll be set to start sprucing up the place by diving into more HTML and maybe even some CSS next time. But now I can still keep the site updated in real-time, without the frustrating delay!