Hacking the JAMstack

Hacking the JAMstack

Do you follow the Reclaim Hosting Blog? If not, now is a great time to subscribe as the whole team has been doing intentional learning topics each month and as Jim reminds everyone, The blogosphere is hot! I caught some of this late since my life is practically consumed by the arcade these days, but I wanted to participate so I joined the most recent meeting where the group reflected on files and folder structures on a hosting server. This next month is all about WordPress and the topic is timely as ever as Lauren notes that we're thinking through things like documentation and presentation in the Domain of One's Own interfaces we provide schools.

But this post is not only about WordPress, it goes a bit deeper down a rabbit hole that I've only just this past week entered in which I'm learning more about something called the JAMstack. Now, the idea is not wholly unfamiliar to me. It's very much built on the idea of the headless CMS and Jim and I got a great introduction to that via Tom, Matt, and Jeff at VCU when they showed us how they were using a blog on RamPages to drive a public VCU site on a server they had no control over as a static site pulling content from the blog via API. Jim wrote about that at https://bavatuesdays.com/headless-at-vcus-alt-lab/. So what's JAMstack? Well the term refers not to a particular CMS headless or not, but rather the idea of running static sites where the content is pregenerated. So in other words instead of pulling content on the fly via API (which might be fast for a small site, but perhaps not so when the API gives you thousands of results with a lot of stuff you don't need), a JAMstack setup would have the entire site generated as HTML and any new publish action would trigger a rebuild of that site. The files can then be stored in a git repository and hosted via CDN for performance. No PHP, Node, Go, or any other language necessary to run the site making it screaming fast and easy as hell to host.

Going back to some of the ideas driving this, it feels to me like a long running goal since even when I was at UMW was this idea of how we could share documentation across institutions via some type of centralized repository. Could we have a Github repo with tons of DoOO documentation written in Markdown and allow folks to contribute there or fork it for their own needs but also allow folks who want to use it in WP to do so but also offer static site variants for other needs? Seems a lofty goal, but I have to believe some of this technology is staring us in the face. I mean if Hugo is good enough for D'Arcy who am I to question it?! ;) I'm also taking a deeper look at the work Alan did with CC on their certifications as I think there could be some interesting stuff there.

Back to the JAMstack because this post really is an initial brain dump of where I am and not a tutorial or fully fleshed out post at all. A couple core tools that many are using for this stuff:

It's worth noting that a static site doesn't necessarily have to give up dynamic content in this scenario. The key to pulling in dynamic content (say allowing someone to search a term on your site) is using APIs to poll that specific content and inject the results into your static site using Javascript. Another huge benefit to this is security. When the end user is only interfacing with your content via a static intermediary it makes it much harder for a potential hacker to decipher how they might get access to that content.

This is super early stages but what better use of blogging than putting it all out there as a starting point to bounce off of? I've got a lot of reading and writing to do this coming month but my goal is to have some type of use case with DoOO Documentation living in Github and being served up via a static site with authoring happening in WordPress and perhaps other places as well. Let's see how this goes!

Hacking the JAMstack

Hacking the JAMstack

Do you follow the Reclaim Hosting Blog? If not, now is a great time to subscribe as the whole team has been doing intentional learning topics each month and as Jim reminds everyone, The blogosphere is hot! I caught some of this late since my life is practically consumed by the arcade these days, but I wanted to participate so I joined the most recent meeting where the group reflected on files and folder structures on a hosting server. This next month is all about WordPress and the topic is timely as ever as Lauren notes that we're thinking through things like documentation and presentation in the Domain of One's Own interfaces we provide schools.

But this post is not only about WordPress, it goes a bit deeper down a rabbit hole that I've only just this past week entered in which I'm learning more about something called the JAMstack. Now, the idea is not wholly unfamiliar to me. It's very much built on the idea of the headless CMS and Jim and I got a great introduction to that via Tom, Matt, and Jeff at VCU when they showed us how they were using a blog on RamPages to drive a public VCU site on a server they had no control over as a static site pulling content from the blog via API. Jim wrote about that at https://bavatuesdays.com/headless-at-vcus-alt-lab/. So what's JAMstack? Well the term refers not to a particular CMS headless or not, but rather the idea of running static sites where the content is pregenerated. So in other words instead of pulling content on the fly via API (which might be fast for a small site, but perhaps not so when the API gives you thousands of results with a lot of stuff you don't need), a JAMstack setup would have the entire site generated as HTML and any new publish action would trigger a rebuild of that site. The files can then be stored in a git repository and hosted via CDN for performance. No PHP, Node, Go, or any other language necessary to run the site making it screaming fast and easy as hell to host.

Going back to some of the ideas driving this, it feels to me like a long running goal since even when I was at UMW was this idea of how we could share documentation across institutions via some type of centralized repository. Could we have a Github repo with tons of DoOO documentation written in Markdown and allow folks to contribute there or fork it for their own needs but also allow folks who want to use it in WP to do so but also offer static site variants for other needs? Seems a lofty goal, but I have to believe some of this technology is staring us in the face. I mean if Hugo is good enough for D'Arcy who am I to question it?! ;) I'm also taking a deeper look at the work Alan did with CC on their certifications as I think there could be some interesting stuff there.

Back to the JAMstack because this post really is an initial brain dump of where I am and not a tutorial or fully fleshed out post at all. A couple core tools that many are using for this stuff:

It's worth noting that a static site doesn't necessarily have to give up dynamic content in this scenario. The key to pulling in dynamic content (say allowing someone to search a term on your site) is using APIs to poll that specific content and inject the results into your static site using Javascript. Another huge benefit to this is security. When the end user is only interfacing with your content via a static intermediary it makes it much harder for a potential hacker to decipher how they might get access to that content.

This is super early stages but what better use of blogging than putting it all out there as a starting point to bounce off of? I've got a lot of reading and writing to do this coming month but my goal is to have some type of use case with DoOO Documentation living in Github and being served up via a static site with authoring happening in WordPress and perhaps other places as well. Let's see how this goes!

Hacking the JAMstack

Hacking the JAMstack

Do you follow the Reclaim Hosting Blog? If not, now is a great time to subscribe as the whole team has been doing intentional learning topics each month and as Jim reminds everyone, The blogosphere is hot! I caught some of this late since my life is practically consumed by the arcade these days, but I wanted to participate so I joined the most recent meeting where the group reflected on files and folder structures on a hosting server. This next month is all about WordPress and the topic is timely as ever as Lauren notes that we're thinking through things like documentation and presentation in the Domain of One's Own interfaces we provide schools.

But this post is not only about WordPress, it goes a bit deeper down a rabbit hole that I've only just this past week entered in which I'm learning more about something called the JAMstack. Now, the idea is not wholly unfamiliar to me. It's very much built on the idea of the headless CMS and Jim and I got a great introduction to that via Tom, Matt, and Jeff at VCU when they showed us how they were using a blog on RamPages to drive a public VCU site on a server they had no control over as a static site pulling content from the blog via API. Jim wrote about that at https://bavatuesdays.com/headless-at-vcus-alt-lab/. So what's JAMstack? Well the term refers not to a particular CMS headless or not, but rather the idea of running static sites where the content is pregenerated. So in other words instead of pulling content on the fly via API (which might be fast for a small site, but perhaps not so when the API gives you thousands of results with a lot of stuff you don't need), a JAMstack setup would have the entire site generated as HTML and any new publish action would trigger a rebuild of that site. The files can then be stored in a git repository and hosted via CDN for performance. No PHP, Node, Go, or any other language necessary to run the site making it screaming fast and easy as hell to host.

Going back to some of the ideas driving this, it feels to me like a long running goal since even when I was at UMW was this idea of how we could share documentation across institutions via some type of centralized repository. Could we have a Github repo with tons of DoOO documentation written in Markdown and allow folks to contribute there or fork it for their own needs but also allow folks who want to use it in WP to do so but also offer static site variants for other needs? Seems a lofty goal, but I have to believe some of this technology is staring us in the face. I mean if Hugo is good enough for D'Arcy who am I to question it?! ;) I'm also taking a deeper look at the work Alan did with CC on their certifications as I think there could be some interesting stuff there.

Back to the JAMstack because this post really is an initial brain dump of where I am and not a tutorial or fully fleshed out post at all. A couple core tools that many are using for this stuff:

It's worth noting that a static site doesn't necessarily have to give up dynamic content in this scenario. The key to pulling in dynamic content (say allowing someone to search a term on your site) is using APIs to poll that specific content and inject the results into your static site using Javascript. Another huge benefit to this is security. When the end user is only interfacing with your content via a static intermediary it makes it much harder for a potential hacker to decipher how they might get access to that content.

This is super early stages but what better use of blogging than putting it all out there as a starting point to bounce off of? I've got a lot of reading and writing to do this coming month but my goal is to have some type of use case with DoOO Documentation living in Github and being served up via a static site with authoring happening in WordPress and perhaps other places as well. Let's see how this goes!

Reclaiming Jekyll (Two Years Later)

Two years ago Tim wrote a great post detailing how you can get Jekyll up and running in shared hosting on Reclaim Hosting.* I’m late to this party, obviously, but playing with Grav recently led me back into Github thanks to the Github Sync plugin. I had explored Jekyll back in 2014 briefly (almost 4 years ago now, really?!), but I forgot most everything. I wanted to see if my Grav repository in Github (synced with my Grav install on Reclaim) would allow me to run the Grav files through Github pages (which is powered by Jekyll). Is this all crystal clear now? Good.

Turns out I was on a fool’s errand. Grav is a flat-file CMS, but it needs PHP to dynamically those pages as a site—which I should have understood. So it will not run on Github Pages.  Grav Sync is first and foremost for forking and collaborating on specific Grav instances (which I did understand), but I was trying to understand if those files could be seamlessly archived/translated into Jekyll given it was a repository, but I see my foolish ways now. Thank you, Tim ? So while you can bring up individual pages from my Grav repository on Github, like the Welcome page:

But the site functionality of my Grav instance could not be reproduced. Lesson learned. But this did peak my interest in synching my locally installed Jekyll on Reclaim Hosting with my Jekyll on Github. So, I asked Tim and he suggested the following:

I’m not sure the exact steps but it would involve setting up the repo in Github and cloning it to your hosting account and > then you could use git commands like git pull to grab the latest from git (even setup a cron every 10-15 min to do that piece).

Turns out that was the exact approach—I wish I was that good. I took the Github repo I have at jimgroom.github.io (which maps to jimgroom.me) and clone it into the jekyll folder on my Reclaim Hosting account. I made sure to run jekyll build in the jimgroom.github.io folder so that it would build the site files in the _site directory. After that I pointed the DNS of the subdomain jekyll.murderinc.biz to the new directory, i.e. jekyll/jimgroom.github.io/_site and the same site at jimgroom.me on Github is cloned and also resolving through my shared hosting account at jekyll.murderinc.biz. The two things needed to sync changes made on Github is running the following commands in the jekyll/jimgroom.github.io folder on my shared hosting (making sure you are logged into command line through your virtual Ruby environment):

git pull

and then

jekyll build

Pull in any changes and then rebuilds the site so those changes are published to _site. None of this is new by any means, I am just playing catch up. Adam Croom went down this road two years ago in order to stick a fork in the LMS using Github, and I can say from firsthand experience that wrapping your head around Github can be intense, but that’s no excuse for an ed-tech to give up:

“An Ed-Tech spends her life getting into tense situations!”
-A Github Repo Man


*This setup requires CloudLinux, which we have installed on all our shared hosting servers. 

Domain Mapping on GitHub

Over the last couple of weeks a number of requests have come in at Reclaim Hosting from folks who what to map their domain (or a subdomain) on another service. I’ve been writing about domain mapping for years on the bava, and I never get tired of the magical idea of pointing your domain (or a subdomain) to another service in order to maintain your identity in relationship to a URL rather than a service. Two sites I have done this for  recently are GitHub and Squarespace, so I’ll document the process for these two and then transfer it over to Reclaim Hosting’s documentation. There are many more services you can map your domain  to including Tumblr, WordPress.com, Blogger, Wix, Google Sites, etc., but I’ll start with GitHub in this post, SquareSpace in the next, and then try and build out the rest over the next few weeks.

But first a bit about A Records vs. CNAME Records

When you are mapping aa domain on GitHub pages (or on any site really) an important concept you want to try and wrap your head around is the difference between A Records and CNAME Records. I’m getting closer to full comprehension, but a little help never hurts so I took the following definition from DNS Simple:

The A record points a name to a specific IP. For example, if you want blog.dnsimple.com to point to the server 185.31.17.133 you will configure

blog.dnsimple.com. A 185.31.17.133

The CNAME record points a name to another name, instead of an IP. The CNAME source represents an alias for the target name and inherits its entire resolution chain. Let’s take our blog as example.

blog.dnsimple.com.      CNAME	aetrion.github.io.

To summarize, an A record points a name to an IP. CNAME record can point a name to another CNAME...

It’s good practice to point domains using CNAME Records when possible because IP addresses can change, and when they do an A Record will break because it is hardcoded. You might think of CNAME Records as relative hostnames, hence the IP address can change regularly but the mapped domain will not break.

One issue is that root domains (sometimes called “zone apex” or “naked domain”) have to be setup as an A Record, not a CNAME. This means that with most DNS providers you can setup a subdomain CNAME  (blog.jimgroom.me) to point to a service like GitHub, but you cannot setup your root domain (jimgroom.me) as a CNAME. That root domain would have to be an A Record. Make sense? Good.

Mapping your Domain on GitHub

As you might have guessed from the above definitions, there are two methods for mapping a custom domain on GitHub: CNAME and A Records. You can get a good overview of how Custom Domains work on GitHub here. Mapping a subdomain using a CNAME is recommended so the domain doesn’t break if the server IP changes, which may very well happen. That said, we understand sometimes you just need that root domain mapped, so an A Record is nice and will suffice.

Mapping your Root Domain with A Records

For this example I’ll be mapping the root domain jimgroom.me onto a Github page. In terms of getting your Github pages setup for this see GitHub’s “Setting Up a Custom Domain with GitHub Pages.”

First you need to find the Advanced Zone Editor under the Domains section in CPanel.

Screenshot 2015-12-02 12.24.20

After that you need to choose the root domain you will be mapping. In the example screenshot below you’ll see I have several, but you may only have one which would be the default.
Screenshot 2015-12-02 12.24.30

Once you select the domain you need to create two A Records for it using the below screenshot as a template, through the Name will obviously be different depending on the root domain you are mapping. The two a Records will point to the following IP addresses on GitHub: 192.30.252.153 and 192.30.252.154.  You need to create a separate A Record for each of these IPs.

Screenshot 2015-12-02 12.26.31

Once you have created both A Records in the Advanced DNS Zone Editor you should be all set. GitHub has their own documentation with “Tips for Configuring an A Record with Your DNS Provider” that might also be useful. If you are having any issue see GitHub’s “My Custom Domain Isn’t Working” or contact us.

Mapping your Subdomain with CNAME Records

For this example I’ll be mapping the subdomain blog.jimgroom.com onto a GitHub Pages Repository using a CNAME Record. Head to Advanced DNS Settings.

Screenshot 2015-12-02 12.24.20

Once there, select the domain you will be mapping to if you have more than one.

Screenshot 2015-12-10 01.35.15

Now you name to add a CNAME Record with the subdomain you are mapping in the Name field and the URL of your GitHub account in the CNAME field.Screenshot 2015-12-10 01.35.08

After that you should be set. I found even if your repository is jimgroom.github.io/blog like mine is in this instance, you only need jimgroom.githib.io in the CNAME field.

GitHub provides a page with “Tips for configuring a CNAME record with your DNS provider” if you need more help, or feel free to contact us at Reclaim Hosting.

Reclaim and the Translation of EdTech


Jim Groom on Reclaim and the translation of edtech from UCalgary Taylor Institute on Vimeo.

D’Arcy Norman posted this one video that parts of a larger documentary project he started while at UMW for the Reclaim Your Domain Hackathon. I don’t get to see D’Arcy nearly enough, and unfortunately I was running around like the proverbial chicken all weekend trying to organize the hackathon which meant any focused time together was limited. I consider D’Arcy one of my oldest and dearest “edtech” friends, and sitting down with him for 15 minutes allowed me to try and articulate what’s important about the Reclaim movement for me.

This is my fourth Reclaim Your Domain event, the others being the MIT Hackathon March 2013, Atlanta Domain Incubator April 2014, and LA Reclaim Hackathon July 2014. These events have been by far the best professional development I’ve had over the last two years, and much of that is owed to the vision Audrey Watters and Kin Lane turned me onto near on two years ago. I’ve effectively been spending my copious spare time trying to wrap my head around things like Amazon Web Services, GitHub, and APIs. And as I suggest in the video, these are the platforms and technologies I’ve trying to understand so I can translate how they reflect some of the more seismic shifts in how the web works over the last few years. Kin and Audrey are a brilliant one-two punch in this regard, framing the technical, social, political, economic and more. Add to all this the IndieWeb movement, and Reclaim really feels vibrant and full of possibility. So, I want to thank D’Arcy, Andy Rush, David Kernohan, and Grant Potter for taking the time last weekend to try and capture some of it. Big Fan!