I'm a software engineer (at Customer.io) during the day and indie hacker by night. I blog about my ideas, and journeys into building products.

How I passed AWS Developer Associate certification

I have always been interested in Devops, tinkering with servers, writing some bash scripts and always grabbed the chance to get my hands dirty in server side stuff. Despite my interest, I hadn’t dug deeper into cloud computing to get a full picture of how everything comes together and that irked me. In the course of building a side project and giving serverless architecture a real go I discovered I wasn’t knowledgeable to a level of comfort so I decided to get a better understanding of AWS. After finishing the course, I am so glad I took it and will share my learnings in future blog posts as I document the making of my new sideproject, nroute (more on that later). For now let’s discuss how I planned and passed it.

Seriousness

I am a huge Arsenal supporter. I started loving the club because they wore a shade of red I liked when I was young. As the years rolled by with Arsene Wenger as coach, I got to like his approach and method of putting the club’s values first, before victories. Arsenal was one of the clubs that could lose beautifully which would leave a conflict of emotions in supporters after a game, yes points would have been lost but you would also recall special, magical moments created on the field which would make you overlook the final result. Since Wenger left though, the club has been in a bit of a tailspin. Unai Emery who took over about 2 years ago failed to win the fans over because of an unattractive style of play and few victories which eventually culminated in his sacking. In his place, Mikel Arterta, a former captain was put at the the helm. While watching his first video as Arsenal coach the idea of this blog post came about. It was refreshing to hear how clear he was about what it takes for Arsenal to get back to greatness. One theme that I took away, is how serious he approaches his work and the level he requires of everyone who will contribute.

On belief:

…I want to start working with them (the players), I want to start looking in their eyes…

On culture:

…I know what a winning culture is and should look like, which is for me, the most important thing.

Leaving awesome OneSheep

This is a post that I didn’t foresee myself writing for the last 3 or 4 years. It is amazing how long but short that time has been. Every day was always so fresh and full of promise, all because of the wonderful folks I was working with. I remember it like yesterday when I got the offer to become a full time contractor at OneSheep. Having been a Drupal contractor 2 years prior, I jumped at the chance to work on some awesome (and very diverse projects) and what a whirlwind it’s been with so many great memories made!

Ignore changes to specific git files

There are times when you are working on something that should not be committed even though it has changed. In this instance, it’s not wise to add the changed files to .gitignore:

  • maybe because the file(s) should always remain in the repo
  • or suppose it’s a config file with your private key for a service you are using locally, not everyone on the team even uses it.

Whatever the case, git has an easy way for this: git update-index! Here is how it works:

git update-index --assume-unchanged [path_to_file]

This simple rule will delist/hide all changes on that file in future commits. That means you are free to edit the file locally and the changes won’t be staged nor pushed upstream! Listing the file again is straightforward:

git update-index --no-assume-unchanged [path_to_file]

Whilst the commands are handy, they do not come with an easy way to untrack an entire folder, which is not-great. However, this can be easily done by a bash command that can list all files you want to “untrack” locally and transverse that list, updating each file’s entry in the git index.

Update-index is a command that does exactly what it describes, it tells git to update its index for the tracked file it is given. When we set that entry of the file in the index to assume-unchanged what that does is tell Git to simply ignore anything that happens to that file. This results in performance gains via unburdening Git from doing unnecessary indexing on files we no longer care about. However, keep in mind that should the file be changed upstream, when merging commits, Git will still ignore it locally so it does introduce an extra step to be aware of.

Lastly the commands are pretty long. An easy way I use to set them to something friendlier is by aliasing them in my gitconfig file as follows:

[alias]
assume-unchanged = update-index --assume-unchanged
assume-changed = update-index --no-assume-unchanged

After this change, you can easily call: git assume-unchanged [file]!

As always thank you for reading, if you have tips or advice or other ways you handle this, please fire away in the comments below.

i agree with boring

I couldn’t help but nod my head the entire length of the blog post written by Jeremy Wagner on make it boring. It’s not often that I find someone literally following my train of thought so succinctly, albeit from their own unique angle. The principle behind the post is that boring things are the big stones to be put in first.