Skip to content

posts🔗

  • 1 min read

My Job

Acted like I wasn't going to go to work today with my 4 year old daughter.

  • 7 min read

Pulumi Round 2

This is not a comprehensive article, but more a log of the issues and wins as I work through Pulumi adoption.

tl;dr

  • Pulumi is pretty powerful.
  • Once you get beyond the basics, it requires a lot of effort since the tooling doesn't have as many examples as I'd hope. This is especially true for Kubernetes. It's a lot easier to get moving on other providers.
  • 1 min read

Helm Is Like Hugo

Turns out helm is pretty intuitive if you already have been working with something like Hugo, which is Go template driven.

Was able to convert an entire K8 stack to helm with a couple hours of work and render everything.

I have this problem of trying to avoid percieved complex tools in an attempt to reduce "another tool" syndrome for others I work with. Sometimes, it's important to keep in mind who is editing and doing the majority of the work, and not worry as much about the long-term solution over delivery.

That's always a tough balance since I tend to think outside the scope of a single team due to the style of work I've done. I think I'm slowly getting there. 😀

  • 2 min read

Go R1 Day 86 - Wrap Up!

Finished!

Done! I've pretty much done above and beyond 100 days, but finding the blogging format to take a lot more effort to keep up when I'm doing a mix of puzzles, courses, and work.

Since my full-time job has Go development as a part of it now, I've exceeded this and going to track any future training goals in a lower overhead way, such as GitHub issues or such.

Was It Worth It?

Yes, it was worth it. It helped me break down a large amount of learning back into a daily rythm of dedicated study. For me, doing full time development, I found it was hard since I do code a big chunk of the day to document all the time.

What would I do differently?

Probably would minimize the effort of documenting the process itself. While it's great to save notes and articulate things, I feel either saving the notes as part of the git log or algorithm style repo would be less trouble. Also, some of the work is in various platforms like Leetcode, which aren't easy to straight extract. Reduce the overhead and focus on documenting core principles or concepts that would be useful in a wiki style format, but not log as much.

Using Github Issues might work really well too, because you could post them to a log later in bulk, but otherwise the cli driven creation and kanban board approach would minimize the overhead. That would be cool too cause you could have bots run todos, stale items, and other cool things for you.