Adventures in creating a personal site and blog the hard way
by Kurt van Bendegem
March 27th, 2017
If you're reading this, something has gone surprisingly right
This is the first of what I hope will be many blog posts. I've worked on this site over the course of the past few months to present a more up to date representation of my current skills and knowledge. I added this blog feature to give myself an outlet for writing about what I'm currently working on, which I feel will make me much more deliberate in the decisions I make for future projects. I would also love to extend this to things unrelated to development that matter to me.
Anyways, I'd like to use this post to outline the things I learned in the process of getting this darn thing up and running.
As a general intro, the full stack is: Node.js, Express, Handlebars, Redis.
NEHR definitely isn't as popular or catchy as MEAN or LAMP, but it worked pretty well for me. Handlebars provides just the right amount of logic and reusability in the markup, and Redis is pretty great for keeping data at your app's fingertips. Before we go any further, I want to address that I realize that this exact same site could be put together with a blog and everything using something like WordPress. I really wanted to code everything from scratch for the purposes of learning and to get one more project under my belt. I'm usually pretty stubborn in this way when dealing with things on the web. While it cost me a lot of time and greatly distracted me from school work, it was a super useful learning instrument and I took a lot away from it. I'll keep needlessly coding things from scratch until the day I die, dammit.
For this post I'm specifically gonna focus on 2 areas of the site that I learned a lot about:
Designing something pleasant to look at and easy to navigate
Using Redis as a back end data store
There are several other topics that I would love to write other posts about, such as writing well documented REST APIs and my experiences using Digital Ocean as a web hosting service. These will have to be posts for another day I suppose.
Design is a skill that I have always really admired and have found myself falling flat on my face with. For me, its a constant war between 3 things: simplicity, self expression, and what looks "cool". Regarding the latter, I've spent so many hours writing up crazy CSS just to throw it all away in the end. This is because things like a beautiful orange gradiant and spanning the entire page reveal themselves to be very jarring after the novelty wears off.
I've been told that for any artistic skill, one has to consume a ton of that medium to develop their taste, and then allow their skill to catch up to this. I agree with that to a large extent. A lot of improvement in my design skill has come from just perusing design sites like dribble or awwwards, although these are extremely talented people and nothing I create reaches this level. The issue with this is that the web is so idiom-based that sometimes it feels like I'm tempted to include so many things only because so many other sites do. I feel that should only be the case if I can see a clear reason for this feature or design decision (hamburger menus are a big example of this). Self-expression is definitely lost in this process. With this site, I wanted to try really hard to design something that I think looks like I made it, and also reminds me of how far I've come with regards to this skill.
More often than not, my desire for simplicity cannibalizes the other considerations I mentioned. Websites are really meant to be read as documents at the end of the day (although a lot of web applications are designed to make you forget this). I started thinking about this more towards the end of my time working on the site. I introduced much more whitespace and simplified the colours to only 2 shades of ornage and 1 shade of blue. Not only were things easier to read, but things actually looked way more pleasant. In terms of the layout of the site, my greatest asset was a pen and paper. I've never been a fan of digital mockups in photoshop, probably just because I'm really slow that kind of software. I iterated on the layout of the navbar and logo design many times using graph paper, and it really helped things go smoothly. As much as I love technology, there is no true replacement for the satisfaction of drawing something out on a physical medium. It's fast, its fun, and I can always pull out a notebook in the 10 minute chunks of time I have before a lecture starts which is a huge plus.
All that being said, I realize that this website is really simple design wise. It could have planned out far faster and look far nicer if a better designer had worked on it. But hey it's mine and I'm rather pleased with it. Now I get to spend the rest of time finding things that bother me and making minor soul sucking tweaks to CSS. Hooray!
Overall I think its a decent improvement over the following original design I had in mind, although not by much:
Meanwhile, on the back end ...
Redis proved to be perfect for storing blog text and metadata. I upload raw markdown text through a JSON REST API, and this gets converted into HTML using marked, which I also highly recommend. The rendering is done on the server side on each page load, so that the content on the page is immediately visible as soon as the page loads and will get spotted by web crawlers like Google. This is made more feasible by the awesome performance that Redis provides. On top of being well optimized It makes me so incredibly happy to see that they have asymptotic time complexity in their docs as well. Take the following exerpt from the SMEMBERS command, which returns all members of a set:
Available since 1.0.0. Time complexity: O(N) where N is the set cardinality.
I suppose it's not all that crazy since this is exactly the runtime you'd expect from this operation. I've just never seen this info included in an API before and I thought I'd provide them some applause for being so thorough!
One tradeoff with Redis is that there really isn't any structure or integrity to the data you stuff in there. The only schema in place is one that you implicitly maintain with your API, which is a bit anxiety inducing. However, problems that arise from this can often be solved with the really nice CLI tool they provide, or with the great backup features.
The biggest issue I faced with the blog specifically was escaping newline characters. These are super important to preserve on the server side so that the markdown is properly rendered into HTML. The issue is that when I enter a string of markdown text, Redis escapes all escaped newlines with a double escaped backslash and an n. I'm not complaining about this, since they have to interpret it one way or another and this way they assume as little about the context of the data as possible. In my case it just happened to be a pain in the butt since it took a while to locate the bug, and annoyingly the only fix was to parse out the double escaped newlines back into singly escaped ones upon rendering each HTML page.
Despite some hiccups, Redis is a tool that I'm really happy to have on my belt now and I'm excited to see its applications on some more data-driven projects that I'd like to work on in the future.
Overall I'm really happy with the result of this site. I've already gained a heaping pile of knowledge from developing it, and I'm really keen on using this blog to improve my writing and communication skills (plus I'll admit blogs always have a certain amount of self-indulgence associated with them, which is a feeling I'm certainly not resistant to). I hope you decide to check back in, either because you saw me share a post somewhere or stumbled upon it some other way. I'm real excited to get this thing going.