Hello again, world!

Second first entry!

Update: This post was migrated from GitHub Issues which used to be the back end for the previous version of my personal site. The entire site and blog has been redesigned but I've decided to keep the old blog entries to sort of pay my respect to that younger, oh so ambitious Nick. With that out of the way, enjoy something from the archives.

Hello and welcome back to my blog! So, what the hell is this? What is this cheap, cliché of a second blog post title supposed to be all about? Well it certainly is cheap and cliché, I'll give you that, but more than that it's symbolic of the refactoring that has gone into this website since the last blog post. Many things have changed about the website since that last post and I realize that I didn't talk about anything really technical in that post. So, I figure that having finally pushed a stable release for the new version of the site, I will talk more about the development that's gone into all of this and where things are at now, because why not?!

In my previous post, I briefly discussed the motivation for the website, part of that being to experiment with certain tools to make a blogging system. In that design, my idea was initially as simple as creating markdown files for blog posts in a certain directory of the repository, and have the website recognize all files in that directory as blog posts, thus listing them on the blog page with links to render them in full. It didn't really seem like a complicated task when I thought it up, so I imagined that GitHub pages would do the trick perfectly, what with it not supporting server-side development. Once I got started with the actual planning, I needed to think of how I would actually interface with the files in the GitHub repo. Luckily, GitHub has a fairly developed API, and it was all too easy to get what I wanted (sort of).

Using GitHub's API, I was able to make use of a route for getting repository contents at any path within the repository. This returned a bunch of data about all of the files within my special blog directory, but when I had accomplished this, I noticed that something was off... One thing I wanted out of the use of this API was to get creation and update dates for the blog posts, since I consider that some fairly important information for a blog site to have, trivial as it may be. The contents response contained no such date information on repository items. I did some research on the subject and I suppose this actually makes sense from a Git perspective. The contents of a repository aren't exactly files to begin with, but lucky for me commits themselves have dates associated with them. So the next step was to get the first and/or last commit associated with all of the contents of my blog directory. It wasn't too hard to do at all, but I will admit that I felt like I was doing things the hard way... It simply felt sloppy. Even so, I continued on and finished the little system, building a page that listed the blogs in descending order sorted on creation date. I then moved on to filling out the other pages of the site, but I could not relieve myself of a lingering discontentment with the blog system.

As I had just about finished all the work I had planned on doing for the site, having just pushed likely one of my last updates, I got a random idea. I went to my GitHub profile, went to one of my projects for which I had more actively used the issue board, and then I opened up one of the issues and just stared at the page as my mind began running wild with new ideas. As the crazed look on my face reached the peak of its exaggeration, my jaw swung open to let slip the words "oh my god" and at that moment again I was off. With fingers tapping like lightning on the keys, chrome tabs exploding into existence one after the other fulfilling countless consecutive google queries, and alt+tab's being dropped between each second to swap from chrome to atom, the project had only just begun again...

Now before going on, I'd like to apologize about the shift in writing style in that last paragraph. Sometimes when reflecting on experiences of such magnitude, I become swept up in passion and bring the heat of that moment to this one right now, but I digress. Put simply, what I had realized was that GitHub's issue system made for a perfectly rich and complete blogging system right out of the box. All I needed to do was look into the API support for GitHub issues before proceeding, and what would you know? What I found was an API which worked exactly the way I needed it to, no funny business, no shenanigans. A simple route to get all issues for a repository, sorted on creation date, in descending order, returning only issues with the label 'blog' was enough to allow me to tear out about twenty-five lines of code right off the bat. Contained in the response, an array of objects containing issue titles, bodies in plain text, creation and update dates, identifiers, various URLs for issue comments and other relevant things, and even a nested object with information for the user who posted the issue. I realize that this is all very basic and isn't really too much to ask for, but after already having gone through kind of a mess to get things going before, this all looked magical to me. It took less than a day to change the existing content to use issues. From there, my plans were to expand to create a commenting system.

Part 2: Hell and back again, and back to hell again

I have to say that when I learned about the potential of using issues instead of what I already had implemented, my primary incentive was to add comments to blog posts. If it weren't for that possibility, I simply wouldn't not have even bothered changing things, but after all, what's a blog site without the capability for comments, right? Before getting started on the commenting system, I took about a week break from development. This was definitely a good thing, because I fear if I hadn't given myself this break, then I probably would have ended my life under the stress. An exaggeration, but on a very serious note ALWAYS MAKE TIME FOR BREAKS. It can probably save a life.

Continuing on, I started with some front end stuff for comments. I knew that I was going to have to deal with some authentication shenanigans, and I knew it would suck, so I put it off to do more visual stuff. Also I'm pretty bad at the visual stuff (HTML and CSS), so it was a nice change of pace. At one point or another though, it had to be time to bite the bullet.

When I finally came around to it, I started looking into web application flows for authenticating with GitHub to get an OAuth access token. I had already created a GitHub application for the site, and I had manually generated an access token with no scope just to plop in the repository for clients to use to raise the GitHub API request rate limit (remember, every time opening the blog page on the site, there would be at least one API call). As such, I was at least a little bit familiar with how it all worked, but boy was I naive. Recall that GitHub Pages only provides users with the ability to host static HTML pages. Well, I wanted to exclusively use GitHub Pages for this whole project. But I looked, searched, grasped at every straw, and found that it is IMPOSSIBLE to securely complete an authentication flow with a client-side-only application. The reason for this is that you simply cannot get around sharing you client secret with the client, and as per the name, that's supposed to be a secret from the client!!

I accepted defeat and moved on with my life. I decided that it wouldn't be too much trouble to setup a dumb little server to work and carry out my API calls to get a user authenticated. Holy crap, this ended up being my mental undoing. I was familiar with using Azure and already had a couple of running Node.js apps hosted on there. I went ahead and created a new Azure instance and started getting down to business, only to be bitten by an entirely new annoyance. SSL, baby! SSL! For some reason, I was dead set on keeping that HTTPS enforced protocol that GitHub provides me with, but guess what. You CANNOT make a request from an HTTPS hosted application to an HTTP address! (Can you tell the rage is coming back? Don't worry, I'm only going to be scratching the surface in this blog post.) I mean, sure, this is a good thing, and it makes sense. But come on, just let me be done with this thing and move on with my life! No... no, I wasn't going to give up, and I was going to at least try to do things properly. I tried all sorts of things. Microsoft really charges up the butt for everything on Azure, including SSL certificates, so I tried looking into ways to get around that. I was able to use Let's Encrypt's certbot in manual mode to pass the ACME challenge and prove I owned the domain name I was using. That granted me a certificate for like a month or something, which I tried using on the server. It didn't work though, and to be honest I didn't bother to really look deeply into why it didn't work. All I really did was change my node.js app to start the server using the https module instead (which did work locally), but at that point I didn't care and just blamed it on Microsoft, assuming they wanted to force me to pay for more things. Besides, forcing things to work that way would have meant that I'd need to then somehow come up with my own custom job to run on the server to re-validate the certificate with Let's Encrypt whenever one expired. That would have been a whole other pain in the ass and may not have even been possible since Microsoft wants you to use all of their pretty Azure stuff which costs money. A quick aside: don't misunderstand, I actually really like the Azure portal interface and I like the services provided with it, but the simple fact is that I'm not rich and I wasn't intending to spend a nickel on hosting this website.

To rush a bit through the final chapters of this battle, I ended up switching to Google Cloud as the hosting provider, since they host using HTTPS by default. I then faced a few more minor challenges along the way, but for the most part, things were smooth sailing. Finally, on this morning of the fifteenth day of June in the year 2017, I am reporting to the world about my struggles, in the form of this blog post, which will be published to the functioning results of my labor. That is to say, I did it! Nearly an entire week and a cargo barge load of stress to get something done which I estimated would be a rather simple task, but I am proud nonetheless. I learned a lot along the way and ultimately had fun!

So that's it. That's the story of how this website came into the state it is in now. In the future, I still plan to add some additional features, like making use of GitHub's issue reactions API to add some extra flair to my blog posts, but I'll leave that for later. I hope that you enjoyed this read. Thanks for coming to check out the site and I will try to continue writing. As some parting words of wisdom, I'd like to just say that if you're passionate about something, make sure to try your very best and put every ounce of effort into it, even if it puts you through hell, because when it's all over you'll be able to proudly say that you did your best and gained some experience from it.

Cheers!