I recently received a support ticket, not so much asking for support, but rather wondering about the status of https://community.reclaimhosting.com/ and why it wasn't promoted more. The person pointed out that it wasn't really linked anywhere or mentioned as far as they could tell, which was absolutely true. When Jim and I first started Reclaim Hosting the idea of building community was very much at the forefront of our minds. I fired up an instance of Vanilla Forums at the time probably only a month after Reclaim Hosting got off the ground. But I never visited there myself. I let it stagnate almost from day one. When Howard Rheingold started experimenting with Discourse I thought "now here's an interesting piece of software for conversing on the web!" and switched up the community site to run on that. I even used a WordPress plugin to make all comments from our blog get driven there as larger discussions. The result: well....nothing. As it not so surprisingly turns out, people don't just flock to new spaces because you hope they will.

The community site has been dormant for a long time now and often I've wondered if it was better to just nuke it into orbit. I had high dreams of folks sharing with each other there, asking questions about how they might approach a given topic, or even user-driven documentation on how to do a particular task on Reclaim. But building community takes so much more than just sitting back and hoping for something to develop. It takes real effort to draw people in, stoke conversations, and it takes a huge amount of good will in the early days. We've had no shortage of good will in building Reclaim Hosting from the community that has embraced us, and if a space to cultivate that is something that I want, something we want, then it's going to take work.

And so last week I rolled up my sleeves and got to work. There were some boring technical details I wanted to accomplish like getting the site to run on SSL thanks to Let's Encrypt support. For the first time I added a link within our client area. I grabbed the RSS feed and started showing the latest posts on our documentation site. And most importantly, I started seeding conversation and inviting folks to the party. You see, Discourse has this great feature that allows you to invite someone to a thread and when they click that link they can immediately start responding without having to go through the process of creating an account. It's a very powerful feature that I have been using a lot this past week to bring folks into the fold and cultivate....well...discourse. Discussions, ideas, tutorials, announcements.

We have a long way to go and it will often require me to get outside of my comfort zone and ask people to participate, be intentional in my actions to seed the space with new ideas and conversation. It's not something I'm used to doing, but it's incredibly important. There is no shortage of amazing people doing incredible work on Reclaim Hosting. And if our support system is any indicator then there are plenty of folks who could use a helping hand as well. We're always there for them, but I would love for that same generosity to extend to the broader circle of people who have trusted us to assist in helping them build their digital identity on the web.

Consider this post me breaking the ice and welcoming you in. I would love for you to come over and chat with us there. As time goes on we'll continue to figure out ways to generate new topics there but I ask that you not be shy and participate in what's happening there. After just one week of investing the time to cultivate the space I've already seen the rewards and it has renewed my efforts to see that space grow. And I now realize this is the investment that we (Reclaim) needs to make in each and every one of you to foster a sense of communal support, the idea that you don't rely on me, or Jim, or anyone else, but that we all can call on each other and have a space to openly share our thoughts. It's more important than ever to me now and I would love for you to join us in that effort!

This weekend I decided to experiment with a feature we have enabled on some of our servers that is sort of an unsung hero for advanced users (so advanced I hadn't taken the time to understand how it works!). Jekyll is a static site generator that has grown in popularity in large part due to its inclusion in GitHub Pages as well as a wider movement to have sites built from HTML based on Markdown templates. Plenty of folks today already run Jekyll sites but the process of using them with Reclaim typically involved generating the files locally on your computer and then publishing them to Reclaim because of Jekyll's requirement to run newer versions of Ruby than cPanel supports.

On many of our servers we now run a piece of software called CloudLinux. While the primary purpose of this software is to handle resource allocation (CPU/Memory/IO) per account, it comes with a stellar list of other features that allow a user to choose alternative versions of PHP, Python, and Ruby for their account. Python and Ruby are not languages I've played much in but I figured this was a perfect opportunity to see if I could install Jekyll and get it to run right inside my Reclaim Hosting account to remove some of the barriers to using it. And I'm happy to say I was successful! Here's how it works.

Looking at the requirements in the Jekyll install guide you'll note that Ruby 2+ is required (thankfully Jekyll 3 no longer requires NodeJS which would have been a dealbreaker here). So to start we'll create a Ruby application within cPanel under Software > Setup Ruby App

For the version I've chosen the latest available here, Ruby 2.2, and setup jekyll folders for the application contents and the public directory.

Click Setup and you'll have a generic Ruby application ready to go! Of course there's nothing there yet, it simply displays some basic information in cPanel and the URL shows a simple Hello World style page letting you know it's running.

The next step according to the install guide for Jekyll is to use the RubyGems installer to run gem install jekyll. Here's where things get interesting. You'll need to login to your shell account for these next steps, something we include by default with our accounts. But if I just login and try to run that command I get the following error:

This is because your Ruby application runs in a virtual environment that allows you to run different versions for different applications. So in order to work within our app we need to enter the virtual environment before doing anything else. If you look back at the application details a command was provided for entering the virtual environment, in my case source /home/towensne/rubyvenv/jekyll/2.2/bin/activate. So I'll enter the environment first and then run the command gem install jekyll from there.

Now we're cooking! We've got Jekyll installed in our account and should be able to use it to build a site. At this point I could grab a theme from somewhere but Jekyll also has a built-in site generator tool that can be used by running jekyll new myblog where myblog is the name of the folder you want it to create. In this case I'll navigate to my public_html folder (cd public_html) and run jekyll new blog to setup a blog folder for it. Keep in mind I need to stay in my virtual environment while doing this. The Jekyll command will not exist outside of it.

Yikes, ugly Ruby error. But have no fear, this is a pretty straightforward one to deal with. Our Ruby app is complaining that it needs something called "bigdecimal" in order to run. Similar to how we installed Jekyll we can just run gem install bigdecimal to get that package in place.

And now let's setup that blog again.

Score! If we look at the blog folder in our File Manager we'll have a better idea of what this looks like. This isn't meant to be a comprehensive introduction to Jekyll by any means, but you'll notice lots of folders and files in there and this structure is essentially a basic Jekyll site.

Now we've got our Jekyll site structure done but it's important to note that we haven't generated the HTML for the site yet. In fact if we go to towens.net/blog where I put this site you'd see just a bunch of code.

We need to run Jekyll's site generator in order for it to convert all the markdown and templates into a static HTML site. This is done back in our shell session by running jekyll build (make sure you change to your blog directory)

What this does is takes all those templates and turns it into an actual HTML site. From the printout you can see the site is generated in the _site folder (you can specify a different name for the folder using the --destination parameter, read more about the options at https://jekyllrb.com/docs/usage/). If we look at the _site folder you'll notice this looks a lot more like a regular HTML site than the Jekyll folder did.

Our last step is to setup a URL for the generated files and for this I'm going to create a subdomain in cPanel under Domains > Subdomains. I'll give it the subdomain blog.towens.net and we know that the files we want to server are in public_html/blog/_site so I'll set that as the Document Root for the subdomain.

Now if we've done everything correctly we should be able to load blog.towens.net and get our Jekyll site.

Booyah! Now all we need to do anytime we make changes to the Markdown files in our Jekyll directory is running jekyll build to rebuild the site. It will update _site with everything each time. For extra credit it's possible to setup a cron job that will schedule and run a build every X minutes. The command would look like this: source /home/towensne/rubyvenv/jekyll/2.2/bin/activate && cd /home/towensne/public_html/blog && jekyll build (obviously you'd need to replace the first part with the command to enter your virtual environment and update the path it changes the directory to).

So that's it! Certainly more advanced stuff than just publishing via WordPress or something like that but I know a lot of folks who have been itching to try Jekyll or use it more with their account and this is a great way to run it as a Ruby application directly from your Reclaim Hosting account without having to do all the building locally and publish the files as an additional step.

Ever had one of those events where your mind was spinning afterwards and attempts to write about it failed due to just how much there was to talk about? That's the place I'm at now following up on the wonderful Indie Ed-Tech Data Summit at Davidson College this past weekend put on by Kristen Eshleman and Adam Croom. Not only was it an incredible opportunity to connect and collaborate with a group of like-minded folks in and around the Ed-Tech scene, but the activities around which we worked were enlightening and rewarding. Below is an admittedly inadequate attempt at furthering the conversation of Indie Ed-Tech (hyphenated now and forevermore thanks to insight from Audrey!).

Labels in Ed-Tech

It's always personally rewarding for me to get a chance to hear Audrey Watters speak and this event was no exception. Her talk, I Love My Label, further expanded a metaphor of the moment we find ourselves in with educational technology in relation to music. Adam and Jim riffed on this idea last year at dLRN and so far, unlike too many metaphors, it's held up as a pretty good reference to approaching this space. In particular what resonates for me is the idea that we're in a moment where music and art can be personal. You can play to an audience of your peers in a living room and that in and of itself can be its own reward. We need not have stages filled with passionate fans, it's perfectly acceptable to build small, tight-knit communities that are personal and intimate.

Small Pieces Loosely Joined

In the afternoon Adam Croom led a brief conversation on the goals of the event. One thing he asked of all of us was what we wanted to see come of the event, to come of the idea of Indie Ed-Tech. During that time I voiced my concern of having been a part of too many conversations that became monolithic ideas that became hard to move forward. Like many I'm inspired by the SPLOT (Smallest Possible Learning Online Tool, or pick your own acronym) approach Alan Levine (present at Davidson for this event) and Bryan Lamb (who sadly couldn't attend and who was sorely missed) came up with last year. How could we break down these larger thoughts into smaller consumable tools for everyone? I'd hoped that whatever we imagined possible we could make equitable and accessible by resisting an urge to have it be any one big thing. A modular approach to Indie Ed-Tech is, in my eyes, absolutely necessary.

APIs Around Us

Kin Lane led a wonderful workshop on APIs and I'm so humbled anytime I get to learn from him. He put together an incredible resource through his domain on relevant APIs in use around us and how we could begin to approach their use within our lives. Kin has a way of taking a highly-technical field and distilling it to something consumable and this workshop was no exception. A key takeaway for me here was how the particular design of an API and what is and (more importantly) is not made available speaks to the goals of the company. For all the talk of IFTTT, we learned that they provide no API and no way to build your own hooks and resources on what they've done, which for a company built on the power of other APIs is poor form. As Kin said, "you have to be a good citizen in this space by paying it forward."

API Mix(er) and Design Sprints

Friday evening and all day Saturday we were led through a "Design Sprint" by Ben Werdmüller and Erin Jo Richey of Known. They helped us understand a design process that was fundamental to helping them build software as they continued refining Known through the startup accelerator Matter. The time was filled with several exercises like student interviews, feedback sessions, storytelling, more feedback sessions, and eventually pitches. We were split into 4 teams and came up with 4 separate ideas, many of which had some overlap but were still fairly distinct.

Being in a group that included both Phil Windley, enterprise architect at BYU, and Kin Lane meant that our idea would only naturally get at some of the lower-level technology underpinning this stuff. What we dreamed up was a drag and drop interface that teaches people to use APIs by allowing them to build, mix, and remix connections in a sandbox environment. What better way to build a deeper understanding of the technology that controls us (as Kin had helpfully framed out the day prior) than to put the tools to play with them in the hands of users. Let them mix up the different services and share those mixes with others. Today Kin pointed me to Dexter which seems very much in line with what they're thinking (and I still think something more, ahem, open source and community-backed would be wonderful in this space).

Next Steps

There aren't many closing thoughts when the end felt so much like just the beginning. Questions remain about sources of funding for innovation, but personally I'm less concerned about that than a deeper drive to continue building a powerful community that can contribute to this space in greater ways. This event reinforced for me that the conversations we're having are absolutely relevant and we're in a moment where the needs that exist and the people as well as the tools are out there to connect the dots. I'm looking forward to playing a part in mapping out the various ways we can continue to drive this effort in higher education and beyond.

A few years ago I switched this blog to using Ghost and decided it was a good opportunity to give my blog a name and image. I've never been big into fancy designs for what's essentially a space for me to think out loud, but there was some meaning behind "Throw Out The Manual" and the associated header image of tools. I've long been following the "Maker Movement" and actively encouraged efforts that led to the building of a Makerspace at the University of Mary Washington. For me there was something incredibly therapeutic about that hands-on learning. Perhaps as the antithesis of the day job that involves lots of terminal, code, scripting, and even these days business development.

3D printing was always an easy entryway into discussions of making and hands-on learning. There's something magical about taking the digital and making it physical and 3D printers are just so damn fun to play with (many get frustrated when they don't work right but I always loved troubleshooting them, for me the act of constantly improving and optimizing prints was a real joy). I miss that a lot since I left UMW and began working full time for Reclaim Hosting. So I recently decided to jump full on into a rather ambitious project to build a 3D printer.

Finding 3D printers is almost laughably easy these days. My wife pointed out to me as we walked into Barnes and Noble that they were selling one for $350. What a world to live in! What's much harder is deciding which printer to get. I'd encourage most except the wildly curious to steer clear of Kickstarter as it often ends in frustration (you're essentially paying someone to develop something with no promise it will work well or support will be there into the future). Ideally you want something that has a community using it, so those random ones you find at your local bookstore or hardware store are probably not the best bet either. If you're brand new to it picking a pre-built 3D printer with a name backing it like 3D Systems, Makerbot, Printrbot (a personal favorite), or Afinia is a decent bet. If you really want to learn how a printer works though the best way is to build one yourself. Even then a kit can be a very user-friendly way of approaching this and a variety of kits for printers exist where all the parts are sourced for you and your job is to simply assemble and tweak it. It's a great way to get a really good understanding of the mechanics involved, but it does require patience and time. I like this guide from 3DHubs for selecting some of the better brands both pre-built and kits.

I've taken both of those paths so I wanted a bigger challenge this time around. I'm also not in a hurry which is important, because this will be a long process. I'm sourcing all the parts to build a printer completely from an open source build specification. I've chosen the D-Bot, a "RepRap" style 3D printer that is completely open source. Some parts will need to be printed so I'll probably be borrowing time at UMW to get that piece done. But also finding things on eBay, Amazon, Open Builds Store, and other places to get everything. Procuring all the various parts alone will probably take 2 months given some things will be coming from China.

Perhaps I'm biting off more than I can chew, but to me there's a real thrill in the idea of gathering all the materials and putting something together that someone else has designed. You might be tempted to think this one-off design would lead to frustration because how many D-Bots exist? But in actuality the RepRap project has a huge community backing it and this printer is just one variation of many builds that others have done. They have active forums for support from the community and many processes are similar between various builds. What's also great is that since there's no vendor lock-in here I can modify the printer as much as I want, improve it over time, add and remove as I see fit. That's something you definitely don't get with Makerbot and other large companies (and I can understand if that also doesn't appeal to a subset of folks!).

So consider this the Hello World of my 3D Printer Build project. I'll be documenting thing along the way, sharing my challenges and successes as they happen.

One of the many roles I have a Reclaim Hosting is keeping an eye on our Twitter account and interacting with folks there. I'm no power-user on Twitter but it's a space I know and I'm happy to support and respond to folks there. On Saturday a tweet came in from a new user, Paul Hibbitts mentioning his beginning explorations with our service.

Trying out @ReclaimHosting - looks very promising to help other instructors flip their LMS. FTP servers @ institutions appear problematic.

— Hibbitts Design (@hibbittsdesign) January 9, 2016

I like to know who I'm talking to so I took a peak at his profile and ended up at his blog where he's doing some really interesting work bringing content out of the LMS and into his own domain using a piece of software that was new to me called Grav. Grav (which is short for Gravity) is a flat file CMS meaning there's no database to deal with. It uses Markdown for authoring content similar to the ever-popular Jekyll, but what struck me was not only how easy it is to install on a server (you just need PHP to make it run) but also that there were admin tools built in to allow an authoring interface, a configuration area, plugin and theme installation and updating, even backups.

I knew I had to play some more with it so I decided to give it a go. The install was dead simple, just drop the files in, setup a user by going to the site for the first time and creating one, and you're off and running. I figured as easy as that was, you'd still have to wrestle with FTP so why not build an installer for it using Installatron? So that's exactly what I did. In the process I was able move the user setup process out of the first page load and into the install itself by capturing that information and writing it to the necessary files.

In addition Grav offers "Skeletons" which are basically packaged versions of their application anyone can build that are bundled with a theme, plugins, and content to jumpstart a new site. Imagine wanting to setup a Photography site using WordPress and all the steps you might take to get there, this let's you skip all that are start up with an instance that already has everything pre-configured so you can start adding your content and playing around rather than spending hours fiddling with a bunch of settings and finding the right plugins and themes. So I grabbed a few skeletons and made it a dropdown option to choose one during install.

I have to say so far I'm super impressed. Not only is Grav fast since there's no database to make calls back and forth to, but it feels like incredibly modern software. There are some geekier options around the edges for power users (per-page front matter editing and YAML configs to name a few) but the presence of an admin plugin that puts the authoring tools right there on your domain is a huge step that's often absent in most flat file content management systems. And of course the big benefit to systems like this is since all the data lives directly on the file system your entire site is infinitely more portable. Moving to a new host or grabbing a backup is as simple as taking a copy of your files and away you go.

I spent so much time playing with getting the installer right I haven't had time to really dig into the software itself more than just a few quick tests but I have a lot of great plans for it. For one, our current documentation is built using Mkdocs but that requires external editing, pushing to the server, and then running a script to build the site each time a change is made. Converting it to Grav means we could author directly on the site and still push to our GitHub repo automatically and have both be in sync. And wouldn't you know there's an RTFM skeleton that looks heavily based on the ReadTheDocs theme we currently use with Mkdocs and looks perfect for documentation sites.

I'm looking forward to playing with Grav more to see what's possible and I know plenty of folks who have been interested in the idea of flat file systems like Jekyll that could appreciate an easy-to-use system like this. We pushed the installer out to our shared hosting systems over the weekend and I hope to get access for all our institutions in the coming week as we make some updates there. And I'm glad to have been curious enough to read Paul's bio and find out more about what he's up to with it as a starting point for my own explorations with the software. As always, Reclaim Hosting gives back to me as much if not more than what I give it.