Skip to main content

Behind the Scenes: The Latest Humadroid Features Inspired by Reflection

Writing the Humadroid story for its blog was more than a trip down memory lane; it turned into a brainstorming session that brought two new features to light. It’s funny how reflecting on your journey can spark inspiration for the road ahead. Let me share with you what’s been brewing in my mind and how your feedback can play a part.

1. Capturing the Pulse of Team Changes

The first idea hit me while reminiscing about the teams we’ve built and evolved over the years. It’s essential, I realized, to not just know who is in which team at any given moment but to understand the journey of how they got there.

Humadroid Development Log: Tackling User Invitations

As the solo developer behind Humadroid, an all-in-one HRMS for small businesses, I often find myself wearing many hats. While coding and deployment come naturally, product development can be a real head-scratcher without a team to bounce ideas off. That’s where this blog comes in handy - it’s my virtual whiteboard for thinking out loud.

The Invitation Puzzle

Recently, a friend asked to test Humadroid. This simple request highlighted a crucial UX issue: new users might not know what to do after signing up. For an HRMS system, having users actually in the system is pretty important! So, I dove into exploring different ways to handle this:

Multiple apps on one server using kamal

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:

Self-hosting tunnel exposing local ports to the internet with custom domain

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.

Intro to protobuf (with ruby)

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.

git using different ssh key on per directory basis

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:

32nd week in review

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

31st week in review

Longer break, than initially anticipated and planned. Actually spent either on vacation or quite busy building… a treehouse for my kids. At some point I (probably) will share some photos and details about it.

  • Emery – personal workspace for busy people - this is… interesting. Testing this this week. As they call it - Personal workspace for busy people. Normally I use sort-of bullet journal, but I was missing something that could help me put my tasks on a calendar.
  • My Engineering Management Values - Luca Pette My two biggest take aways are:
    • developer book - well, we do have notion, but it’s messy. I have it in my pipeline to organize it better (first step - by creating new notion page…)
    • internal blogging - that’s something that Christof Damian suggested to me last week and I think it’s great idea we’ll try to put in place relatively soon (yes, we do have notion, but again - it’s messy)
    • lead by example - I need to learn how to schedule messages, rather that send them during weekends
  • Installing thermal pads on MacBook Air M2 - It’s seems that new M2 MacBook Air is the first one, I’ve actually opened and… tuned. If you can call adding some thermoconductioning tape “tuning”. Nonetheless those machines do not have any active cooling and M2 tends to overheat and throttle. For me it was an easy win.
  • Is your smartphone ruining your memory? A special report on the rise of ‘digital amnesia’ - there is this thing with taking photos - when you’re focusing on taking them, you’re actually allowing your brain to forget current situation, as it’s going to be offloaded to different source. It’s good to be aware, that there is much more to that.
  • John Carmack: Doom, Quake, VR, AGI, Programming, Video Games, and Rockets | Lex Fridman Podcast #309 - Lex Fridman hosted John Carmack. So far I was only able to start listening to this, but man… this IS good. And Masters of Doom is actually my favourite book about IT industry.

26th week in review

I wanted to have a break from normal, day to day stuff at the company (one or the other). But as soon as I got to our destination and I found out, that there is no network coverage nor internet, I started to feel unsafe. One of todays links is about our attention span. For me is also about how addicted to tech and connectivity are we.

  • Life is not short- “The most surprising thing is that you wouldn’t let anyone steal your property, but you consistently let people steal your time, which is infinitely more valuable” I’m not sure yet about how I feel about recent wave of stoicism, but this resonates with me. Life is long adventure and is up to us to take as much of it, as possible. Constant chase for money causes days and time to somehow leak, making false impression, that life is short.
  • On how smartphones fragment out attention span - I’m becoming more and more aware of this problem, haven’t addressed it yet. But when driving, I only drive. When walking, I try to only walk. Phones are taking more and more of our lives and the worst part is that at expense of most beloved ones. That’s one of the reasons why I don’t have Facebook nor Instagram on my phone.
  • Your body knows you’re burned out - there are few obvious points there, but I was not aware of few other. No spoilers, definitelly everyone should read it. And every manager should have this printed, framed and memorized.
  • Things I wish everyone knew about Git (Part I) - as in title. Last week I’ve shared the link to a book which will get you better with shell. And you’re probably using git as well, so it’s worth knowing how it works. Nice read - be sure to also go down the rabbit hole.
  • Red, white but rarely blue – the science of fireworks colors, explained - we’re moving away from fireworks, but next time you see blue explosion in the sky, be sure to appreciate anyone who created it.
  • Huawei MatePad Paper - I’ve just got this. With a little bit of luch I’ll write short summary (I already have some experience using remarkable 2 and Onyx Boox Note 3)

25th week in review

I’m on long overdue vacation, so this weeks set of links is shorter than I’d like it to be. Same as the next one (most likely) will be, as my connectivity is limited.

  • On traveling light - https://levels.io/carry-on-world-travel/ and https://vitalik.ca/general/2022/06/20/backpack.html. I’m a hoarder that would like to become minimalist. Or at least have less useless stuff. But in the end I still buy (or print) a lot of shit. Reading such posts every few weeks makes me think about making a change. And I believe, that someday such post will trigger a significant change. Not this time, but maybe soon.
  • Herman Martinus wrote about his experience of keeping a journal for 6 years. 6 years. Six. God damn it, that’s a lot. And gives fantastic perspective on looking at own life and decisions (or processes leading towards some most significant decisions). The idea of journaling resonates with me, but I never kept doing it for longer than a week. From personal experience it helped me go through some most difficult decisions and I regret being consistent with it.
  • Effective Shell - as console one of the core skills of a developer. It actually should be obligatory for anyone using terinal on day to day basis. Using bare bash might be of concious choice. But using up arrow to find one of previously run commands is not.