Alex's Undercover Blog

In The Beginning

Way back in January 2012, when I started a new role at Amazon, I needed to learn how to code using Ruby and Rails. As a personal exercise, I decided to put together a simple blog platform using the language and framework not only to get my feet wet, but also because I didn\u2019t like the idea of using another platform like Wordpress; I wanted to have intimate knowledge of how it worked and be able to make changes to it on a whim if I wanted.

The requirements I had were pretty straightforward:

• Written entirely in Ruby and Rails.
• Learn something new to bolster my \u201ctool box\u201d of skills.
• Be able to create, read, update and delete posts.
• Be able to tag posts so they\u2019d be able to be categorized.
• Use a single blogging platform for multiple domains and have the posts that are shown for each domain be relevant for only that domain, including being able to show the same post across multiple blogs.
• Use media wiki to format the text. I used this format on a daily basis so it made sense at the time to use this.

Thus, my blogs were born: one for personal stuff (family and friends), and another for more technical stuff that I want to share with the world. Let\u2019s be honest though, it\u2019s usually just for me, apart from the occasional recruiter that contacts me on LinkedIn that mention my blog. I haven\u2019t written to them very often (my last post was in September of 2018, and before that it was 6 years earlier), but I do aspire to write more often than I do, which has caused me to give more thought into my blogs lately.

Defining the problem

There are a number of things that get in the way my writing posts, the least of which is having many commitments in my day-to-day (work and family mostly). It\u2019s also the lack of accessibility in writing them, however. Like every other hobby-like thing in my life, I need to be able to maximize the little time that I have which means planning and being able to make gradual progress; sometimes a few minutes here and a few minutes there. In a nutshell, being able to write posts where ever any free time presents itself. In order to do that, I would ideally have an app on my phone that would let me keep track of post ideas, and put them together and post them whenever I can.

Another, perhaps more important thing, is having something compelling to write about. You don\u2019t just start a blog for the sake of doing so. You do it because you have some knowledge or experience to share. While I\u2019ve been able to write a thing or two over the years that satisfy that requirement, I\u2019ve never been able to do it consistently, both because I wasn\u2019t spending a lot of my free time doing things that I felt like sharing, and because I wasn\u2019t in and found it difficult to get into the habit.

Finally, there are constantly so many cool things being done in the tech space, and being able to experiment with those things and do things that generally take me out of my comfort zone, will help keep me fresh and not stagnate in my career. The urge in me to continually learn new and interesting things is enough that rolling my own software is the best option. Being able to share those things with people is really exciting to me. If I can help show somebody the ropes, or to help plant a seed in somebody\u2019s head for their own ideas, then I feel very rewarded.

The Solution

While putting together a blog with Rails was a great exercise for me at the time, my career has been heading in a different direction the last 3 years or so. While my current role does include some front-end work, it\u2019s minimal at best. Most of what I do is back-end work, and it\u2019s starting to move into the pure AWS space, as opposed to some AWS, and some internal Amazon stuff (though there\u2019s still a lot of that). With my team starting to head in that direction, I\u2019d like to be able to learn more about AWS services and howthey can help solve the problems I\u2019m keen on solving (personally and professionally). This seems like a good opportunity to rewrite my blog platform using AWS services and other frameworks, languages, etc. to put together the full stack. This is not going to be a small amount of work, but I think it will be interesting enough that it will keep me engaged through to the end, and I\u2019m hoping that my experience can help other people putting together similar projects. I\u2019dalso be keen on putting all the source code up on Github so others can benefit as much as possible.

I\u2019ve already started on some of this work, and the rabbit hole is a bit deeper than this, but I\u2019ll get to the other details in subsequent posts.I should note that I\u2019m trying to design the full stack in such a way that it can essentially scale infinitely, though I realize that my blog in particular doesn\u2019t need to. As this point, most of the stuff that I have planned should be easily accommodated by the AWS free tier. To that end, here\u2019s my high-level plan for putting this all together.

Java

Except where otherwise mentioned, I\u2019ll be writing most of the code for this project in Java, which is the language I\u2019m most comfortable with. When using Java, most of the new stuff I\u2019m learning will be related to AWS services or different frameworks. There will be other components later on that will provide new learning in different languages. I\u2019ll also be using Maven for dependency management.

AWS CDK

The AWS CDK (Cloud Development Kit) was introduced in July, 2019. It\u2019s a framework that allows you to write code in Java, TypeScript, and others that generate Cloud Formation configuration to deploy your CFN stacks. It takes care of a lot of the heavy lifting for you, and adds very user-friendly APIs to manage permissions and other aspects of CloudFormation, not to mention the ability to auto-complete your code in whatever IDE that you use. I\u2019ve used this a bit for a small project at work and am smitten.

API Gateway

I\u2019ll start by defining the APIs that will be needed to create blogs, articles, tags, etc. via AWS API Gateway. Defining how you want to interact with a system is a great first step, which will help define the implementation details more formally. I want to use the OpenAPI specification to define the APIs and create the API Gateway end points to make the process as easy and maintainable as possible. While the group that defined OpenAPI has tools to generate code based on those specifications, I wasn\u2019t able to find one that works with API Gateway, and certainly not the CDK as it\u2019s fairly new. It\u2019ll require writing some custom code to generate the APIs using the CDK.

Dynamo DB

I\u2019ll be using DynamoDB to store all the data needed for the blogs. While I\u2019ve thought about blogs from a relational perspective, pushing the data into Dynamo will force me to think in a non-relational way.

Elm (for the web front-end)

I\u2019ve not had a huge amount of experience with functional languages and I\u2019m especially intrigued by Elm, which is a functional language for front-end development that compiles down to JavaScript. The plan is to write the full read-only front end in [https://elm-lang.org/ Elm] to call the API I\u2019ve defined in API Gateway, and serve up the site via S3 and CloudFront.

SwiftUI (for write access)

Ever since SwiftUI was announced at WWDC earlier this year, I\u2019ve been really excitedto jump into it to build an app. I think the blog platform will be the perfect opportunity to do so as it should be fairly straight-forward once the API is defined and implemented.

Bonus Stuff

Along the way, I\u2019m willing to wager that there are several other tools or technologies that I\u2019ll need to learn in order to implement the platform as effectively as possible. The fact that I already have a blog platform in place means I don\u2019t have to rush through this, but rather I can do it right. Beyond that there may be some other not needed but nice to have things I could learn such as setting up a continuous integration environment using AWS Code Commit, Build and Deploy. As the project grows, any sort of automation that I can implement may help save time in the long run (help me utilize my time as best as possible), and also be far more fun than doing things manually.

Writing Cadence

This is a pretty big project, and has a lot of bits and pieces that need to come together in order to make the whole. Turning anything into a habit can take quite a while; not the 21 days that I\u2019ve previously heard. I don\u2019t want to overcommit myself, which I\u2019ve shown is something I typically do, especially when it comes to writing. To that end, I\u2019m going to commit to writing an average of 12 articles over the next year that will gradually document the effort I go through to get all this stuff setup, including migrating all my previous posts from my Rails/PostgreSQL stack. Some of them will be longer than others, and I may even do more than that as I run into problems, or new tech that I want to take a stab at to solve a particular problem. Expect some tangents as I go.

In the mean time\u2026

As a final note, since I\u2019m most comfortable writing in Markdown, but my current blog implementation only understands mediawiki, I\u2019ll be using Pandoc to convert to that format, until I get the current platform up and running. I\u2019ll likely also use it to convert all of my existing articles over to Markdown. We\u2019ll cross that bridge when I get there.