This Website...

Matthew Louis / August 2024 (1266 Words, 8 Minutes)

As a first blog post, it felt on-topic to talk about how I actually set this website up, as I only finished it about a day ago. First off, let me say that my original intent was just to purchase a domain to host my GitLab server from on my raspberry pi, but it quickly became much more than that, and is now my “professional” landing page as well as an anchor point for all of my self-hosted services (like my self-hosted image client, i.e. my solution to running out of space on google photos), and my blog.

Jekyll

Once I discovered the power that having a domain gives you, I immediately thought of cool things I could host on my personal website. Aside from my servers, which allow me to git around GitHub’s filesize maximum and (puny) Git LFS bandwidth limits, etc., I figured out that it’s pretty popular for people to host their own technical blog (one notable source of inspiration was this fantastic blog), so I figured I’d give it a shot. Along these lines I wanted something that’d allow me to write blogs in essentially plain text (but with some bells and whistles for formatting latex, code, etc.) and I found that Jekyll was a great tool for doing just that. There’s also a vibrant community that produces themes that make your site look good right off the bat, assuming you’re willing to sacrifice some individuality. One theme that caught my eye was moonwalk created by Abinavs on GitHub, for it’s minimality and elegant design (and the cool support for dark/light mode in the top right if you haven’t noticed).

Although it’s great for getting a pretty blog up and running quickly, Jekyll is a static site generator, and for some reason I thought it was necessary to fully utilize the domain that I’d payed for (afterall I could’ve easily hosted a static Jekyll site using GitHub pages for free), so I wanted some dynamicism. And so began the weeklong journey of learning ruby on rails (or rails for short).

Rails

Rails is a web-application framework implemented in ruby, and it’s the framework on which some of my favorite tools were built (GitHub and GitLab). There’s plenty of options when it comes to making web apps like Django and Flask (which I won’t pretend to know anything about), but I chose rails because it’s implemented in ruby, and I thought it might be easier to interoperate with Jekyll. After having worked with it, I can confidently say that rails is incredibly powerful: after a week of fiddling, I have created a web app with a fully-fledged login system as someone who has little-to-no formal training in web apps or computer science in general… and that even scares me a little bit. It’s hard to say, because I haven’t had any experience with other frameworks, but Rails’ emphasis on convention over configuration really stands out to me - you just import the necessary gems, create some boilerplate, and it just works.

Jekyll on Rails

Now, my first objective to upgrade my blog was to add a comment system. There are some services for implementing this directly in a Jekyll site, like Disqs, but you have to pay for it, so I decided to make my own. I still wanted the website to be mostly static, but just implement some user authentication so people could sign in and leave some comments that would update the static portions of the site for everyone. Given that, the approach I took was simiar to Jesse herrick’s in this post: have a rails app that essentially controlls a Jekyll directory, and dynamically generates a static site to the public directory of the rails app (static content that’s shared across all clients of the rails app).

Authentication With Devise

To implement the authentication required for making a (hopefully) bot-free, and non-anonymous comment system, I decided to use devise. To be honest, I was struggling to implement any authentication, and I only heard about devise through this amazing tutorial, which was one of the few tutorials on setting up authentication for a rails app that I could actually get to work. If you actually watch that tutorial, you’ll see it’s specifically for setting up omniauth with devise. Omniauth is what allows you to use a pre-existing (in my case Google) account to authenticate with a given web appliction, while devise also allows users to create an account for your web-app without necessarily requiring an account with a third party. You’ll see the what all of this practically means if you head over to the sign in/sign out page.

A Custom Rake Task for Running Jekyll and Rails

To allow for rails and Jekyll to coexist, they both need to be running, so I decided to have a task that runs bundle exec jekyll build --watch in the jekyll subdirectory of my rails app (using the Gemifile therein)

# lib/tasks/jekyll.rake
namespace :jekyll do
  desc "Serve and watch Jekyll site"
  task :serve do
    Dir.chdir('jekyll') do
      # Ensure to unset BUNDLE_GEMFILE to avoid conflicts with Rails' bundle environment
      system("unset BUNDLE_GEMFILE; bundle exec jekyll build --watch")
    end
  end
end

and a task that runs the rails server (along with the jekyll build task)

# lib/tasks/server.rake
namespace :server do
  desc "Run both Rails and Jekyll"
  task :start do
    Thread.new do
      system("bundle exec rails server -p 4000")
    end

    Thread.new do
      Rake::Task['jekyll:serve'].invoke
    end

    sleep # Prevent the main thread from exiting unless one of the servers quits
  end
end

the end result is that Jekyll builds the website dynamically (i.e. as I edit a new blogpost, for example) to the public folder without hosting the website, and the website is hosted through the rails app on port 4000 (where the jekyll site would normally be).

Implementing the Comments System

In this rails app, the static portion of the site is hosted at the “root” (i.e. https://gitlab-matthew-louis-code.com), and all of the dynamic portions of the site are hosted in special routes configured in the routes.rb like /users which the static site links to and communicates to the rails app with. Users sign in at the /users route, after which devise generates a user model for them, which populates some information like their name, email address, and an avatar in a rails sqlite database. Once signed in, the user can then use the comments form at the bottom of any page to submit comments, which triggers a javascript callback that communicates with the rails app to see if the user is logged in, and if so, creates a new comment with the provided information, which is then stored in the rails database. Once a new comment is created, the rails app then triggers a dump of relevant comment data to the jekyll/_data/comments.yml, which the Jekyll template then uses to regenerate the page’s html and show comments on the static site. Each created comment then has an ‘edit’ form that users can use to edit their comments, which triggers a javascript callback that communicates with the rails app and authenticates the user and updates their comment in the database.

Thoughts and Future Projects

All-in-all, I thought this was a great experience, and although it postponed my “release” of this website by about a week, getting into rails was definitely worth it in retrospect, and I think the groundwork that I’ve laid will allow me to do some very cool things with this site in the future. Most immediately, I was thinking of implementing some sort of ENDF scrubber that shows a “cross section of the day” (for nuclear engineering people reading this) along with some cheeky qutoes or something. It might even be cool to have my own web-based game, like a simple 2D Mario clone (with an interesting twist) or something like that, although I guess on Chrome you get a game for free if you just disconnect your internet. Finally, I want to give credit to Gavin Ridley, whose personal website was what got me started building a website in the first place.

Comments

If you're logged in, you may write a comment here. (markdown formatting is supported)

Created at: August 16, 2024 01:05 PM (UTC)

anthony louis (anthonylouispaco@gmail.com)

Luke was here