<![CDATA[Throw Out The Manual]]>https://blog.timowens.io/Ghost 0.8Sun, 07 Aug 2016 05:12:53 GMT60<![CDATA[Investing in Community]]>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

]]>
https://blog.timowens.io/investing-in-community/48a19bc4-12f2-4d2f-b0d8-49c88ecbd093Sun, 07 Aug 2016 05:12:34 GMT

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!

]]>
<![CDATA[Federated Choral Explanations for Documentation]]>I've recently been thinking more and more about documentation and the ways in which Reclaim Hosting as well as the growing number of schools doing Domain of One's Own answer the common "How do I X?" questions that come up. While there are certainly plenty of unique scenarios that require

]]>
https://blog.timowens.io/federated-choral-explanations-for-documentation/c978339e-f297-499a-b0ff-725436cbd3b2Thu, 28 Jul 2016 15:48:38 GMTI've recently been thinking more and more about documentation and the ways in which Reclaim Hosting as well as the growing number of schools doing Domain of One's Own answer the common "How do I X?" questions that come up. While there are certainly plenty of unique scenarios that require a nuanced answer, in many more cases we have communities that are striving to learn more about common topics and asking similar questions. As a result various Knowledge Base Silos have arisen to meet that need. We have http://docs.reclaimhosting.com/, Emory has http://docs.emorydomains.org/, OU has http://create.ou.edu/docs/, and the list just keeps growing. Finding models for powerful reuse here would be a huge boon for a lot of folks.

When I was at UMW we approached the reuse problem by setting up a Dokuwiki install with the thinking that a flat file system would make it much easier for someone to grab all of our documentation and drop it in as a kickstart to building out their own Knowledge Base (such a goofy term that is). I even managed to have it syncing with GitHub at one point https://github.com/DTLT/dooo. That method has driven at least some reuse with other schools like Emory and OU. At Reclaim we built out a site using Grav so that regular markdown files would be used and integrated that with GitHub as well https://github.com/reclaimhosting/docs. These approaches start to get at a solution, but never get very far. Forking a doc site will give you the kickstart you need, but as soon as that fork happens it's much more difficult to pull in new work while keeping the institutional-specific knowledge you've added in the meantime.

It's with that lens that I read Mike Caulfield's Choral Explanations and OER post. While it's long, I encourage you to spend the time digging into it as there are many great gems and I think Mike does an incredible job of explaining the hard problems and where we are currently. His lens is OER but for me the documentation use case kept creeping back in. Mike and I actually explored some of this back when I was at UMW with the Dokuwiki approach and had looked at some federated wiki type plugin approaches to sharing content between installs. Since that time I know Mike has done a lot with Smallest Federated Wiki and is now building Wikity to accomplish similar goals.

So I find myself wondering what this tool might look like for my needs. Perhaps I need to play with Wikity to see if that could work here. Or maybe it's something else entirely. Maybe this is a problem that's just hard to crack in a federated way and a more centralized approach is necessary. Maybe it's Maybelline. But this post is my attempt at talking out loud and starting that conversation. It's something I've been thinking I might suggest as a potential unconference discussion during DigPed at UMW as I know Amy Collier will be there who is not only running Domain of One's Own at Middlebury but also has been experimenting with Wikity herself. I'd love to get feedback from others and start to really figure some of this out.

]]>
<![CDATA[🔎💾.ws]]>So apparently emoji domains are a thing, though a complicated one at that. I blame equal parts boredom and Bud Hunt (a very persuasive individual) for registering one last night. Here's the skinny on the how and why.

First, how do you even do this? Well emoji can be rendered

]]>
https://blog.timowens.io/emoji-domains/ea0e1c71-e5c1-44bf-965f-1d12a6e7441dWed, 25 May 2016 19:13:03 GMTSo apparently emoji domains are a thing, though a complicated one at that. I blame equal parts boredom and Bud Hunt (a very persuasive individual) for registering one last night. Here's the skinny on the how and why.

First, how do you even do this? Well emoji can be rendered in a browser in what's called "Punycode". So in fact when you type the URL 🔎💾.ws in what you actually get is http://xn--6s8h5e.ws/. That's the domain I actually registered, it just happens to render as emoji and work (though not everywhere!). Turns out .ws is one of very few (perhaps only?) top level domain registrars that will support these characters in a domain name, so forget getting your 💩.com on. I tried to register the domain via our own registrar interface at Reclaim Hosting first, our billing system balked at it. Ok, how about Namecheap? "Kindly be informed that, unfortunately, we do not support the registration of IDN domains for .ws extension." Last stop by way of a few tutorials out there was http://iwantmyname.com/ and although there was a hiccup in the ordering process their support fixed it up and I had my own domain.

Adding it to my existing cPanel account was as easy as adding it as an Addon Domain (keep in mind still using the Punycode format that has the domain as actual text). Then I was free to host whatever I wanted on there. I decided I fun URL shortener would be a good idea (get it, "search and save"....). As it so happens YOURLS is available as a one-click install on Reclaim Hosting, think of it kind of like running your own bit.ly. So I set that up and then parked a standard landing page on the main domain using cPanel's Site Publisher feature. Done and Done.

Why do this? I can think of a lot of reasons not to actually! There's poor support for it, most of the time these links aren't even clickable. Slack breaks them by converting the emoji to their markup format :magright::floppydisk:.ws. Facebook you can't click them but copy/paste works. Twitter surprisingly works out of the box. But these are also hard to type, and essentially it's just redirecting/rending a different URL anyway. I guess why I wanted to do this was to explore some of the limits of what's possible. And in truth Bud made a great point on Twitter, at what moments in history do we get a chance to play with a brand new language when its still somewhat nascent? Doing that at the very intersection of the domain/hosting business I find myself a part of is all the more reason to experiment and play.

Do I trust this domain will live forever? Not really, which probably makes using it as a link shortener a really bad idea. But for now it's a fun thing to play around with and I can say I got in on the ground floor (well maybe the lower levels at least) of the right-facing magnifier/floppy disk domain empire. Here's to more silly experiments!

]]>
<![CDATA[Running a Jekyll Site on Reclaim Hosting]]>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

]]>
https://blog.timowens.io/running-a-jekyll-site-on-reclaim-hosting/6c6f3a7d-9494-45c7-8e6f-df640ef50149Mon, 23 May 2016 15:45:22 GMT

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

Running a Jekyll Site on Reclaim Hosting

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.

Running a Jekyll Site on Reclaim Hosting

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.

Running a Jekyll Site on Reclaim Hosting

Running a Jekyll Site on Reclaim Hosting

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:

Running a Jekyll Site on Reclaim Hosting

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.

Running a Jekyll Site on Reclaim Hosting

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.

Running a Jekyll Site on Reclaim Hosting

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.

Running a Jekyll Site on Reclaim Hosting

And now let's setup that blog again.

Running a Jekyll Site on Reclaim Hosting

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.

Running a Jekyll Site on Reclaim Hosting

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.

Running a Jekyll Site on Reclaim Hosting

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)

Running a Jekyll Site on Reclaim Hosting

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.

Running a Jekyll Site on Reclaim Hosting

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.

Running a Jekyll Site on Reclaim Hosting

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

Running a Jekyll Site on Reclaim Hosting

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.

]]>
<![CDATA[Reclaim Your Domain Web Series]]>A few weeks ago I decided to start putting together some targeted screencasts from the standpoint of building a website from scratch using Reclaim Hosting. It's one thing to have lots of written documentation (and we've got that in spades at http://docs.reclaimhosting.com/) but another to sit back

]]>
https://blog.timowens.io/reclaim-your-domain-web-series/f7a625f5-db77-4262-82b7-ecf36e73f9fbFri, 20 May 2016 19:59:20 GMTA few weeks ago I decided to start putting together some targeted screencasts from the standpoint of building a website from scratch using Reclaim Hosting. It's one thing to have lots of written documentation (and we've got that in spades at http://docs.reclaimhosting.com/) but another to sit back and watch someone work through all the various aspects of building out a web presence. What I love most is that even I learn a thing or two in the process!

Below is a quick recap of the first 4 episodes that are already out. Each on is attached to an ongoing playlist and you can subscribe to our YouTube channel to see them when they come out as there will definitely be more!

Episode One: Signing Up

In this episode I walk through the process of getting a domain via Reclaim Hosting. What was interesting to me is just how hard it is to find a unique domain these days! I edited out a lot of trial and error there, haha.

Episode Two: The Client Area

While most people use our client area as a quick way to get into cPanel or handle billing there are also other useful management tools available in there I cover in this episode.

Episode Three: Site Publisher

cPanel's Site Publisher is brand new and I figured it was a great way to show how you can get a quick landing page on your domain up and running in a matter of minutes.

Episode Four: Folder Structures, Subfolders, and Subdomains

Here we dive into the File Manager to understand how folders and files live on the server and how that correlates to what you actually see when you type in your domain.

If you've got other ideas for future videos I'd love to hear them! Hoping over time to build out an archive that can cover all the various features of Reclaim Hosting that folks can take advantage of in building out their web presence.

]]>
<![CDATA[Site Publisher for cPanel]]>As a company, Reclaim Hosting is heavily invested in the cPanel software to drive a decent user experience for building on the web. It's been interesting to see them evolve the product after what honestly seemed like years of stagnation. The x3 theme which was still the default just a

]]>
https://blog.timowens.io/site-publisher-for-cpanel/d9b9f88e-73d7-4215-8177-eff9f2d88002Tue, 03 May 2016 19:23:31 GMTAs a company, Reclaim Hosting is heavily invested in the cPanel software to drive a decent user experience for building on the web. It's been interesting to see them evolve the product after what honestly seemed like years of stagnation. The x3 theme which was still the default just a few years ago and felt straight out of the 90s has been replaced with Paper Lantern, a responsive theme built with Bootstrap, Angular, and jQuery. I've also kept a close eye not just on the user-facing features but also the administration tools. I love that they openly welcome discussion (and participate themselves!) in their Feature Request area and you can see as things develop and are coming down the pipe.

All that being said cPanel is a big piece of software and so change is gradual and slow (which is understandable) but they have now released a rather important new feature that will no doubt be of great use to a lot of people. The latest version of cPanel includes a Site Publisher.

Image of Site Publisher

Let me start by pointing out what Site Publisher is not. The Site Publisher feature is not a replacement for WordPress, Squarespace, Weebly, or any other true content management system. In fact it's not meant to be the primary means of driving most websites at all. The ability to edit or customize is incredibly restrained. Folks who take advantage of it should understand from the start the reason for these limitations and treat Site Publisher as a possible jumpstart to something better rather than the end solution.

Site Publisher at it's core is a series of templates and forms that allow someone to throw up a static website quickly. cPanel will ask for some basic information like your name, email, social media links, etc. And they take that information and dynamically inject it into a prebuilt HTML template and publish those files to your domain. At that point you're free to continue editing the site but would need to edit the HTML to do so, or you could later replace the existing site with a more full-featured CMS like WordPress.

So why is this useful? Some immediate uses I can think of are parked domains. You bought a great domain but you're not sure what to do with it yet. Site Publisher has a simple "Coming Soon" template that you could throw up there with a few clicks. A lot of folks also love https://about.me/ as a destination for a simple Bio Site and Site Publisher has a simple theme that would meet that need. The simple idea is to make it easy to throw something on your domain while you think you through possible next steps.

What's also great is that cPanel has approached this feature in a way that is extensible to web hosting companies like Reclaim. We're able to build custom templates and make those available to our community. I've played around a bit with that and we've already got two themes available today:

Aerial

Screenshot of Aerial Aerial is very much in the spirit of a minimal "About Me" type site. Just a form with some basic information about yourself and your links to social media and you've got a pretty great looking website. This theme is provided with a Creative Commons license from HTML5 Up

Clean Feed

Screenshot of Clean Feed As I was experimenting with building templates I thought it would be cool to utilize Feed2JS to dynamically pull content from an alternative source. A remote blog of sorts. So Clean Feed does exactly that by taking an RSS Feed and converting it to a simple Blog site that updates dynamically. The theme is taken from Start Boostrap

We're making all of our templates available on GitHub with open source licensing to make it easy for other hosting providers that use cPanel to make use of them. How useful this stuff is I'm still trying to work out, but it seems like some low-hanging fruit to domain management that was missing previously and it's been fun to start playing around with and see what's possible. If nothing else it provides a short-term win for someone diving into hosting and domains to throw up a simple website while they start thinking through future plans.

]]>
<![CDATA[Embracing a Quantified Self]]>I'm equal parts fascinated and horrified by the "Internet of Things" movement. As someone who can't resist playing with the shiny, I love the idea of connected devices. In practicality it leads to situations like this:

]]>
https://blog.timowens.io/embracing-a-quantified-self/ad617030-79ab-4ca0-ba9b-6dca04e0071bThu, 14 Apr 2016 16:30:02 GMTI'm equal parts fascinated and horrified by the "Internet of Things" movement. As someone who can't resist playing with the shiny, I love the idea of connected devices. In practicality it leads to situations like this:

Imagine the locksmith's curious look when we told him it was the deadbolt that we needed him to open. So yeah, sometimes the IoT turns on you, but my wife is patient and knows who she married so I can't help but continue to play.

I recently purchased a Fitbit as we've become quite a bit more active and even signed up for several runs and I wanted a better way to track that stuff than having to use apps on the phone. When I found out they have a pretty robust API my mind began to turn to the movement to track your own data known as The Quantified Self. For many folks these kinds of data are incredibly intimate and privacy is a huge concern. For me, I get a real thrill out of having my heartbeat be public and easily tracked. I'm strange like that.

I had been looking for an excuse to change up my main domain timowens.io and this seemed like the perfect playground to start building APIs and connect to the devices I use. To start I built a page at https://timowens.io/activity/ that connects to the Fitbit API to pull in semi-realtime (at least whenever the device syncs to my phone) data. I also got to play with Google Charts for the first time. For now that data is not stored on my site, I'm just pulling today's information and it resets every morning. Eventually I'd like to cache and store this data in the database.

Image of Activity Data

I also had a revelation as I was building that page, that perhaps I could create my own personal API that interfaces with Fitbit so that the pages on my site call my own API rather than Fitbit directly. You can see an example of this at https://api.timowens.io/activity/heartrate/day/. While incredibly rudimentary and essentially a lot of hand-coded work, the idea behind it is one that we've talked a lot about in the Indie EdTech circles and I liked the idea of prototyping this idea on my own site with something relevant to me.

Automatic Car Adapter

Next up was more or less a toy that I bought, the Automatic adapter for my car. This device tracks your trips, mileage, fuel costs, even warns you of engine light issues and how to resolve them. Their API gives you a lot of data but for now I was mostly interested in two numbers, total mileage and total fuel costs which I display at https://timowens.io/driving/. The map is just a static image for now, no realtime GPS coordinates (yet!).

There's so much I love about all this. I get to hack on my own site with things that are relevant to me and my interests. I get to play with APIs and understand what data I have with third parties that is and isn't available to me. I get to make parts of myself public (whether or not people care about it is a whole other question). And I'm keenly interested in understanding more about whether awareness of this data would lead to change in habits. For now I'm enjoying the sandbox and working to see how much of myself I get make machine-readable. Should be fun!

]]>
<![CDATA[Reflections on Indie Ed-Tech]]>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

]]>
https://blog.timowens.io/reflections-on-indie-ed-tech/51459fde-d1fe-428d-923a-2488e0cf0bb9Thu, 24 Mar 2016 01:09:57 GMT

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.

]]>
<![CDATA[Praise for Disqus]]>When I decided to ditch WordPress for my blog here and start playing with other blogging engines, one of the things I wanted to make sure of was that content could live on no matter what platform I was using. I don't subscribe to a complete archivist point of view

]]>
https://blog.timowens.io/praise-for-disqus/4e6a767e-d0b4-4cc3-8765-9e5d1ee07a81Tue, 01 Mar 2016 05:05:12 GMTWhen I decided to ditch WordPress for my blog here and start playing with other blogging engines, one of the things I wanted to make sure of was that content could live on no matter what platform I was using. I don't subscribe to a complete archivist point of view where every URL that ever lived has to live on for eternity (it's a noble vision mind you, just one I don't find all that realistic) but I do my best. I've switched the software on this site on 3 different occasions moving from WordPress to Anchor to Ghost which is the platform I use currently. Anchor didn't offer a migration strategy for content so I kept my old WP site humming for old posts but when I moved to Ghost I wanted to consolidate everything here.

Awhile back I had decided to switch from WordPress's built-in commenting in favor of using Disqus. I liked the features it offered and it seemed just as good as anything else (and if there's any theme you'll find on this blog it's that I just like playing with stuff). I didn't know at the time how important it would be for migrating content between platforms. Anchor had a built-in mechanism for comments as well but I never used it and opted to throw my Disqus embeds there as well. With the final move to Ghost which had no commenting system at all it just made sense, and that's where the idea of having a portable commenting system became really powerful.

Disqus has the big downside of course in that it's a company and while I can use this open source software Ghost as long as I want, the same won't be true for Disqus. But they have a variety of tools at your disposal including export options so I'm confident I can always move on to something else in the future. For now it's great that I can drop a commenting system in place and keep rolling regardless of whether the software I'm using has support for comments natively. It's also been nice to not have to worry about spam without a handful of plugins (hint hint WordPress). Integration isn't too hard, they provide some basic code and if you have a good-enough understanding of how your CMS handles URLs and post IDs you can figure out how to setup the embed code for custom platforms as well.

I'm sure at some point Disqus will get bought out by some large company, rolled into their feature set, and disappear as a free service. But for now it's a great tool for adding comment options and it's given me freedom to migrate platforms here with relative ease which is worthy of praise.

]]>
<![CDATA[Back to Building]]>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

]]>
https://blog.timowens.io/back-to-building/13c8532b-dcd2-45a1-98ad-394acaf5901bMon, 29 Feb 2016 23:14:15 GMT

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.

]]>
<![CDATA[WordPress.com v/s WordPress.org]]>I've often seen folks run into issues understanding the difference between WordPress.com and WordPress the software. Plugins like JetPack that require WordPress.com logins make the waters even muddier unfortunately so the confusion is absolutely understandable.

WordPress is a piece of software, similar to an app on your phone

]]>
https://blog.timowens.io/wordpress-com-v-s-wordpress-org/331d0dab-bc0b-476d-95a0-785cbbb3e76fTue, 16 Feb 2016 20:40:03 GMTI've often seen folks run into issues understanding the difference between WordPress.com and WordPress the software. Plugins like JetPack that require WordPress.com logins make the waters even muddier unfortunately so the confusion is absolutely understandable.

WordPress is a piece of software, similar to an app on your phone or a program on your computer. This software runs on Reclaim Hosting on our servers so when you "install" WordPress with us you're downloading a copy of the software and installing it directly to your domain. You can view information about the software and project at WordPress.org.

Screenshot of WordPress.org

The company that participates in the development of the software, Automattic Inc., also runs a hosting company specifically for WordPress. And here's where it can get confusing. They named their site WordPress.com.

Screenshot of WordPress.com

Now there are pros and cons to choosing where to host your WordPress site. WordPress.com is free for basic needs. They'll give you a *.wordpress.com URL and you can run a site there at no cost. Additional options like a custom domain, backups, and other fancy things come with a fee and it's how they make their money. Free sites are ad-supported which is a potential negative there, and the environment is not flexible in that you can't run your own plugins and themes there, only what they make available to you. But they keep things completely up-to-date for you and if your needs are simple it can be a good option at a low cost.

Running a WordPress site on Reclaim Hosting gives you the added benefit that you're running the full software and as the administrator you have access to all WordPress themes and plugins that are publicly available (both free and paid). The flip side is that you'll be responsible for keeping them as well as WordPress up-to-date and since you'll need a domain to run WordPress on in addition to hosting, there's no free option here (though I believe the cost is about as low as possible with us!).

So the easiest way to think of these are two different ways to run WordPress with two different companies. Here's where things get tricky. Automattic, Inc, the company that runs WordPress.com, also makes a few very popular plugins that are open source and available to be installed on any WordPress site. Akismet and Jetpack are two perfect examples. These plugins, unlike most that you'll encounter when running WordPress on your own with Reclaim Hosting, require you to "activate" them with a WordPress.com account.

Wait what?

I know, just when it seemed clear these were separate spaces entirely there's now a reason to have an account with both. You don't need to necessarily create a site at WordPress.com, but you do need to have a login there in order to use the Akismet or Jetpack plugins. Akismet handles spam protection and Jetpack is a nice suite of tools (think of it like a swiss army knife all-in-one kinda plugin). When you activate either of these plugins in your own installation it will require you to login to WordPress.com to use them similar to how Pinterest will let you login with Facebook.

So while we personally believe there's a lot of great power in running your own version of WordPress at Reclaim Hosting, it's still possible that you might find it useful to have a WordPress.com login to take advantage of the tools they provide to enhance your site. But the two spaces are distinct in that you'd be running your actual site at one or the other.

]]>
<![CDATA[Cleaning a Hacked WordPress Site]]>As I sit here painfully waiting on Godaddy's slow servers to download all of a customer's files so I can migrate them to Reclaim Hosting I figured I'd write up some thoughts on how I approach the problem of cleaning up a site that's been hacked. Not all WordPress hacks

]]>
https://blog.timowens.io/cleaning-a-hacked-wordpress-site/6c0f9ce5-9934-4d73-b4ab-b2fb3fb0bbdcFri, 15 Jan 2016 04:15:38 GMTAs I sit here painfully waiting on Godaddy's slow servers to download all of a customer's files so I can migrate them to Reclaim Hosting I figured I'd write up some thoughts on how I approach the problem of cleaning up a site that's been hacked. Not all WordPress hacks are equal, but understanding how the files that make up a WordPress install are organized will help with cleaning one up. So let's look at the directory structure and break it down.

WordPress 4.4.1 Directory Structure

Here we have a clean WordPress install that hasn't yet been setup. I know this because a file wp-config.php isn't present at the root directory. In addition to several files at the root of the directory that handle logging in, serving up content, and mail delivery, we also have 3 main folders: wp-admin, wp-content, and wp-includes. Here's a brief description of each:

wp-admin - When you login to the dashboard of WordPress you might notice the URL is /wp-admin. The wp-admin folder stores all WordPress files necessary to display and interact with the backend of WordPress.

wp-content - This is where the files and folders unique to this particular install will end up. Plugins and Themes have a place here as well as all images that are uploaded to WordPress.

wp-includes - General php classes and any javascript files and libraries that WordPress relies on are located here.

In addition to all those files your WordPress install has a database. This is typically only going to be seen through an admin area of your hosting provider. At Reclaim Hosting we provide phpMyAdmin through cPanel to view the databases in your account. The database stores all of the actual content (your posts, pages, site information, etc).

Knowing all of this we can start to understand what the unique aspects of a WordPress install are versus the files and folders that can easily be replaced. The unique content of a WordPress install consists of:

  • A wp-config.php file that has our database information.
  • A wp-content folder with our plugins, themes, and uploads.
  • A database

That's surprisingly it! Everything else can be replaced with a fresh copy from WordPress.org and your site would still be there. So now we've narrowed down the number of potentially hacked files, but we can go even further. For example we know that plugins and themes are all available in the WordPress repository so we can download fresh copies of those as well (if you use premium themes or plugins you'd need to get access to those again of course). That can be a time consuming process but wouldn't you rather spend the time now getting this right?

When cleaning up a site I also take that as an opportunity to check and see if there are any plugins or themes I don't need. For example if I'm running a non-default theme I can easily delete all of the TwentyX themes provided by WordPress. Remember we're trying to remove as many potential targets for exploits as possible.

Finally when all is said and done and you're back online the last thing to do is run a full scan of your install. I personally like the Wordfence plugin which makes this a straightforward process and can also protect your install from future malicious activity. There are options to check all plugins and themes as well as files outside of your WordPress install in the Wordfence settings, both of which I recommend turning on before doing a scan.

Cleaning up hacked installs is never a fun process and with WordPress powering over 25% of the web now it's become somewhat a large target. But hopefully these tips help you understand how to get a site back online and cleaned up in no time.

]]>
<![CDATA[Get Your Grav On]]>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

]]>
https://blog.timowens.io/get-your-grav-on/433ae339-28e7-44ed-8570-4797b25e2945Tue, 12 Jan 2016 04:20:44 GMT

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.

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.

Get Your Grav On

Get Your Grav On

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.

Get Your Grav On

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.

Get Your Grav On

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.

Get Your Grav On

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.

]]>
<![CDATA[Where Did All My Disk Space Go?]]>Sometimes you may find that you just plain need more disk space. Perhaps you're regularly uploading large files to build an online archive for a project or you work with video files that need to be stored locally. As Reclaim Hosting has grown over the years we've consistently increased our

]]>
https://blog.timowens.io/where-did-all-my-disk-space-go/fd4655af-8eee-401e-89e0-23678294b2d1Wed, 23 Dec 2015 21:30:46 GMTSometimes you may find that you just plain need more disk space. Perhaps you're regularly uploading large files to build an online archive for a project or you work with video files that need to be stored locally. As Reclaim Hosting has grown over the years we've consistently increased our storage options and luckily upgrading is an easy process! That being said we always encourage folks to diagnose the source of disk space issues to be sure there's not any other issues at play. Automated backups you weren't aware of in a folder on your account because of a plugin, or a log file that has grown rapidly could be the source and simply deleting a few files could free up large amounts of space in your account. But how to find that large needle in the haystack?

cPanel has a rudimentary tool in the control panel called Disk Usage which is found under the Files section. Disk Usage will calculate the size of every folder in your account and display it in a nice graph. However the biggest caveat that makes this a poor solution is that the Disk Usage tool will not let you navigate to subfolders. More often than not you'll find that the public_html folder which houses all your web content is the largest, but that could still leave you searching blindly for more information on where within that folder the culprit is.

Disk Usage in cPanel

Disk Usage Detail View

Because of the limitations of this tool we add a program to our servers called Ncdu. Ncdu runs from the command line so you'll need to be logged in via terminal with your SSH account, however you'll find the interface pretty friendly. Once logged on simply navigate to the folder you want information about and type the ncdu command to get a text-based graphical representation of the largest folders.

ncdu

Because the folders and files are ordered by size I recommend starting at the root of your account and running the tool. You can use the arrow keys to move up or down and enter to navigate into a folder and get a readout of the size of its contents. In our experience it makes quick work of analyzing disk space issues and finding any opportunities to clear out the cruft. When you're finished simply hit the q key to quit.

We've added ncdu to many servers but if for some reason it's not available in your account on Reclaim Hosting put in a support ticket and we'd be happy to make sure it gets added.

]]>
<![CDATA[Using Google Apps with your Domain]]>Managing e-mail can be one of the harder parts of reclaiming your space on the web. While building a web presence is easier with modern applications like WordPress, the state of email clients and protocols is much less advanced. You'll have to grapple with getting your IMAP accounts setup and

]]>
https://blog.timowens.io/using-google-apps-with-your-domain/7e313c37-188c-4ca0-8311-226a02488fd1Wed, 23 Dec 2015 17:07:17 GMTManaging e-mail can be one of the harder parts of reclaiming your space on the web. While building a web presence is easier with modern applications like WordPress, the state of email clients and protocols is much less advanced. You'll have to grapple with getting your IMAP accounts setup and all the settings correct, webmail options are limited in functionality, and deliverability is always a concern with shared hosting servers.

Many users for this reason decide to use a service like Google Apps with their domain. Google Apps allows you to have email addresses based on your domain but completely powered by Google using Gmail as a webmail interface and connecting to any Google-supported client. Luckily it's absolutely possible to push mail to Google while still maintaining complete control of your domain for building out content on Reclaim Hosting. This is done by editing several MX Records which are a type of record for your domain that tells our servers who is in charge of handling email for the domain.

Google outlines the necessary records for setting up Google Apps on your domain at https://support.google.com/a/answer/33915?hl=en. Essentially we'll be editing the MX records to reflect the following:

Priority Mail Server
1 ASPMX.L.GOOGLE.COM.
5 ALT1.ASPMX.L.GOOGLE.COM.
5 ALT2.ASPMX.L.GOOGLE.COM.
10 ALT3.ASPMX.L.GOOGLE.COM.
10 ALT4.ASPMX.L.GOOGLE.COM.

To make these changes you'll log into cPanel and navigate to the Email section and choose MX Entry.

Email Section in cPanel

By default cPanel creates a single MX entry that points to your main domain as the server for email (so if your domain is hosted by Reclaim Hosting mail will be routed through the server your domain is on). We'll need to change that to take advantage of Google Apps for email. Each MX record has two items, a Priority number which tells the server which order to check for email records, and a Destination which is a domain that will serve the email.

MX Entry Editing Interface

You'll need to edit the existing one (or remove it) and then add a few additional ones from the table above. When you're done the records should look like this:

Completed MX Records

You're all done! Keep in mind changing records can take 24-48 hours to begin working, though it typically will happen much sooner. Once the records have propagated globally all email will be routed to Google and you can use their system to handle all of your email functionality while still maintaining control of your domain from Reclaim Hosting.

]]>