I posted recently about getting a promotion at Amazon and how different the new position is compared to my old position. I started my fifth week with my new team, called FXM for Fulfillment Exception Management, and thought I'd give a brief update. Week #Activities% of tasks for new team1Wrap up chores from previous position0%2AWS Hack Attack class5%3Finish job management system migration100%4Stability Week - Made sure stuff that needed monitoring was monitored, cleaned up some code, migrated a system or 2.100%Without getting into too much detail (maybe I already have) the stuff I did for the first two weeks on my new team had nothing to do with it. The third and fourth week went much better but I haven't written a line of code yet. Week 5 is much different. I'm actually starting a decent sized coding project so I should feel more like a developer by Friday! :)One last observation before I wrap up this post. In my last position I was in a large room with 3 or 4 other guys. As the Support Engineer position is very much a "junior developer" type roll having several people in the room with different backgrounds and experiences really helps to facilitate learning and growth at the company. The problem is that it can typically be difficult to get any work done when you're constantly interrupted for help with a problem, etc. Now I'm in an office with one other guy and we're pretty much always working. The interruptions are few and far between which helps us to get more work done. Fewer "context switches" equals more work done.
I've tried to use Maven during my Java development but have found it rather frustrating for a few reasons.
The documentation is a bit sparse - Most of what you need is represented but setting up your own settings, deploying artifacts a repository and other more advanced subjects are under represented. Deploying artifacts is painful - This mostly goes along with the first point. The syntax, once figured out is far from obvious and much to verbose for my taste. That's one of the drawbacks of extreme flexibility... extreme complexity.
Because I tend to be a perfectionist when it comes to code I write at home I had taken a break from coding Java for a while (except at work of course).
Recently I've had some really good ideas pop into my head as well as how to implement those ideas so I wanted to get started again with Maven. I was able to utilize the the Q4E project which is a Maven plugin for Eclipse which I've found more stable and consistent than the original M2Eclipse plugin (though I haven't tried it in a while so it may have improved). This combined with my already POM-enabled projects in source control made for a pretty easy return to Java development. Unfortunately there was some frustration just around the corner.
When my new application was getting bulky enough to start needing some logging I decided to start using log4j which is commonly used in Java development. All I needed to do was add it to my project's POM as a dependency and Maven should have taken care of downloading it and adding it to my CLASSPATH but unfortunately that wasn't the case. Maven wasn't able to figure out how to get 3 of log4j's dependencies. Usually in a case like this it gives good suggestions on where to download them. Unfortunately the links that were given kept redirecting me somewhere on the Java site that wasn't what I was after. After struggling with the issue for a few hours I gave up and started using the Java SDK's (inferior, IMHO) logging mechanism but not being able to use log4j continued to nag at me.
This morning I decided to give it another try and this time the first thing I did was a google search which brought me to this blog entry. While installing a separate piece of software, Artifactory for a Maven Repository Proxy, this was something I had done using Proximity in the past so I was pretty familiar with what to expect. As I already had a server machine setup and ready to run Tomcat I was able to install Artifactory pretty quickly. Once installed I followed the instructions in the blog post and in the Artifactory documentation for setting up Maven to look at the repository proxy first and 2 of the 3 missing dependencies were downloaded no problem. I had to do an explicit search for jms-1.1.jar to get the last dependency but I followed similar instructions for installing it into my new repository. Long story short I'm now able to use log4j in my Java coding. I can also easily deploy the artifacts I create to my own repository with ease.
Now I need to stop messing around with all this stuff and continue my coding.
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’t 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 “tool box” of skills. * Be able to create, read, update and delete posts. * Be able to tag posts so they’d 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’s be honest though, it’s usually just for me, apart from the occasional recruiter that contacts me on LinkedIn that mention my blog. I haven’t 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.
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’s 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’t just start a blog for the sake of doing so. You do it because you have some knowledge or experience to share. While I’ve been able to write a thing or two over the years that satisfy that requirement, I’ve never been able to do it consistently, both because I wasn’t spending a lot of my free time doing things that I felt like sharing, and because I wasn’t 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’s head for their own ideas, then I feel very rewarded.
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’s minimal at best. Most of what I do is back-end work, and it’s starting to move into the pure AWS space, as opposed to some AWS, and some internal Amazon stuff (though there’s still a lot of that). With my team starting to head in that direction, I’d like to be able to learn more about AWS services and how they can help solve the problems I’m 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’m hoping that my experience can help other people putting together similar projects. I’d also be keen on putting all the source code up on Github so others can benefit as much as possible.
I’ve already started on some of this work, and the rabbit hole is a bit deeper than this, but I’ll get to the other details in subsequent posts.I should note that I’m 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’t 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’s my high-level plan for putting this all together.
Except where otherwise mentioned, I’ll be writing most of the code for this project in Java, which is the language I’m most comfortable with. When using Java, most of the new stuff I’m 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’ll also be using Maven for dependency management.
The AWS CDK (Cloud Development Kit) was introduced in July, 2019. It’s 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’ve used this a bit for a small project at work and am smitten.
I’ll 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’t able to find one that works with API Gateway, and certainly not the CDK as it’s fairly new. It’ll require writing some custom code to generate the APIs using the CDK.
I’ll be using DynamoDB to store all the data needed for the blogs. While I’ve thought about blogs from a relational perspective, pushing the data into Dynamo will force me to think in a non-relational way.
Ever since SwiftUI was announced at WWDC earlier this year, I’ve been really excited to 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.
Along the way, I’m willing to wager that there are several other tools or technologies that I’ll 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’t 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.
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’ve previously heard. I don’t want to overcommit myself, which I’ve shown is something I typically do, especially when it comes to writing. To that end, I’m 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.
As a final note, since I’m most comfortable writing in Markdown, but my current blog implementation only understands mediawiki, I’ll be using Pandoc to convert to that format, until I get the current platform up and running. I’ll likely also use it to convert all of my existing articles over to Markdown. We’ll cross that bridge when I get there.