CODING

• Found a nice Ruby gem (actually it was recommended to me in this Xitter thread) - procore-oss/blueprinter which seems to be a very nice serializer (JSON Object Presenter) for Ruby. As I was implementing API for Humadroid recently with Time-To-Market in mind, I’ve actually settled on Grape & Grape Entity, but when we’ll be creating v2 of it in bigger team, we’ll most likely look for alternatives and blueprinter looks like a solid contender.

Quick Learnings

PRODUCT

• Vacation policies can be hard. We’ve decided not to solve all the problems and leave some flexibility for the users. Automation is important, but people are people and sometimes just manual adjustment is worth more than covering any possible use case.

HARDWARE

Trying to restart this blog, one thing at a time. For quite some time I wanted to start publishing some smaller blobs I find interesting, but giving each and everyone a post seemed wasteful. That’s why I’ve decided to publish my weekly learnings and findings - some links, some thoughts from development, some API methods I haven’t used before. Without further ado, here it is for the first time.

This week I’ve learned:

Sometimes, when I read other companies’ blogs, I feel like they have it all figured out. They talk about big plans and cool ideas. But for me and Humadroid, it’s a lot messier.

How It Really Happens

Most of the time, new ideas for Humadroid come from everyday problems. Here’s how it usually goes:

Building Humadroid by myself is tough. I’m good at writing code, but coming up with new ideas for the app can be really hard when I don’t have anyone to talk to about it. Sometimes I write these blog posts just to help me think things through.

The Invitation Problem

The other day, my friend wanted to try out Humadroid. It made me realize something important: when someone signs up, they might not know what to do next. That’s a big problem for an app that’s supposed to help manage people! I spent a lot of time thinking about different ways to get people into Humadroid. Here’s what I came up with:

Kamal’s effectiveness is undeniable. Its integration with power-efficient bare-metal servers, such as those available on Hetzner.com, elevates its appeal, allowing for the simultaneous deployment of multiple Rails applications (or applications developed with other frameworks) on a single server. This setup can be further enhanced with the inclusion of additional components like PostgreSQL or Redis.

It’s important to note that while each service in this configuration operates within its own namespace, Traefik does not share this characteristic; only one Traefik service can be included in our setup. In my scenario, I’ve designated the Prograils service, which powers the prograils.com website, as the primary service. Below is the complete configuration for this setup:

Although there are some existing solutions to expose local port to the internet, I’ve decided to use self-hosted solution. I’ve prefered this over hosted one for few reasons:

1. I wanted to have some pre-configured subdomains
2. I wanted those subdomains to be fixed and/or reserved just for me
3. Custom domain was a nice addition
4. Cost of hosted solution was just too high to justify it.
5. It was just a fun exercise

Idea is simple - anyone accessing address like some_name.yourdomain.dev will actually access your dev environment on specific port, eg. localhost:3000. Overall cost of that will be 5$ for cheapest linode + domain cost.

Protobuf or more precisely Protocol Buffers is a data serialization format developer by Google and it is designed to be language-agnostic. What’s important (and what makes it a better choice than ie. JSON) is that it automatically provides validation of data, preserves order in arrays and provides pre-generated classes that do all the hard work with set of setters and getters. Magic is done by compiling .proto files with schema into language files.

Disclaimer - I found this solution thanks to my friend Piotr who needed it for different use case, described below.

Recently I had to use multiple repositories on one server with different deploy keys. Solution suggested by github docs was not viable, because I could not alter hostname easilly, as it suggest. It turns out, that actually you can use different keys on per directory basis, when using git. It’s doable thanks to git conditional includes:

It turns out, that I’ll will do hell lot of writing in weeks to come. So this is, what I’m focusing on now

• Writing for Engineers - this is great summary about writing in tech companies. At the end you can find few recommendations, eg. “Leverage small writing tasks as exercise” - and I find it super important. Email should be well strucutres, support ticket should well describe the problem to avoid confusion and bring understanding. And Slack messages are much better when though-though - at least I have this ugly habbit of writing many short messages, that might get hard to understand.
• Technical Writing  |  Google Developers - even google teaches about writing. If they’ve prepared their own course, it means how important this actually is.
• Blogging for busy programmers - it’s worthwhile mentioning that my old friends onec wrote a decent book about blogging as a developer.
• The productivity tax you pay for context switching - I’m still struggling with that. For now I try to be very aware when I switch between tasks and I try to do timeboxing - and it helped me a lot during last week. Don’t forget to read comments on HN