Posts

What’s the point of buying TRMNL device if what it displays does not make you happy? I am not saying that all the plugins need be pretty, but for something that becomes an integral part of your home, it’s nice to have something that was made with taste. Here are a couple of plugins in no particular order that I find particularly beautiful and inspiring. If you plan to implement your own plugin, I highly recommend browsing their integration and recipes catalog to get inspired and to discover which ones you like the most, and which are closest to your sense of aesthetics. Building something pretty is much more fun and rewarding than building something that just works. It will keep you motivated and proud. ...

There are a lot of examples of Claude Skills out there which include separate code files that Claude can use to execute something. But Skills can be just a single SKILL.md file describing and algorithm and/or a way to communicate with some API, its schema, authorization and authentication patterns, error handling etc. Considering that Claude already knows how to make external requests with curl or fetch etc, you don’t necessarily need to code the API interactions themselves. Sometimes that might be beneficial if you want to hide certain aspects such as token management, error handling, retries, logging, etc. But for most simple cases describing the solution in SKILL.md might be sufficient, especially when prototyping. ...

Exploring how we built AI Powered search in Rails. This AI workflow included: semantic/vector search with Elastic, using LLM for extracting semantic and non-semantic criteria from user’s query, expanding query based on application context, re-ranking results with LLM. The presentation also touches on the challenges of non-deterministic aspect of LLMs and prompt testing.

This presentation explores a powerful technique to get AI Assistants to write the kind of code you want. By treating them as amazing at mimicry, pattern matching and transforming based on existing project conventions in your application, you can achieve great coding speed and alignment with your codebase conventions.

Discussing the challenges of fitting aggregated data into GraphQL paradigm in a clean way. Showcasing the implementation and conceptual problems with our initial solutions and describing the journey towards a conclusion that aggregated calculations often must be treated as a new “resource”, no matter if in GraphQL or REST.

I’ve been recently working on a Slack bot and Slack delivers all events (webhooks) to the same URL that you can configure. That means you need to distinguish between different events types based on the payload (request body). In the past, I’ve seen that Rails apps usually reimplement their own “slack routing” within a single controller action. I wanted to share a different solution that I came up with. Let’s do routing in rails routing. ...

I was working on a Hono project where I needed to convert a JSX element to a string. I couldn’t find an easy way to do it in the official documentation. It turned out to be rather easy, even though all the LLMs were clueless :). const component = <MatchesList matches={matches} /> const htmlString = component.toString() Now, I will remember.

Testing GraphQL APIs can be challenging due to their flexible nature. While clients can request data in countless ways, we need a testing strategy that remains robust regardless of how the API is consumed. And one that can scale with the growth of your app. The main pillar are proper, exhaustive type specs so I want to focus on that together with a couple best-practices that you can establish. First, we want our tests to be integration tests that go through all the involved layers (GQL types, database, authorization policies, etc, as much as possible). ...

Today I wanted to share with you a trivial pattern, that I call “technical key”. In rails apps, we typically use surrogate keys (autoincremented ids without any business meaning) as a primary key for database tables. However there are cases where our code depends on database data. In my previous article, I shared the case where the code assumed certain team exists and finds it in the database. There are many cases like that in Rails apps, where we give users the power to configure certain aspects of the app via UI and the configuration is stored in the database. ...

Over the years of working with large, mature, monolithical Rails applications, I realized a subtle problem. Many, even experienced teams put their constants in suboptimal namespaces. On one hand such placement is logical, but on the other it leads cluttered code that mixes low-level and high-level concepts. It does not help with keeping our monolith modularized either. Consider a common scenario in a Rails application: the Team class. As your application evolves, you might find yourself adding constants like this: ...