Recent content on Ruby under pressure by Robert Pankowecki
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…
Coding ≠ Engineering: Software Craftsmanship in the Age of AI Presentation from February 2026, Wrocław. Explores the tension between AI-generated code and genuine software craftsmanship. While gradient descent and “next-token thinking” can lead to less-than-ideal code, with proper prompting and engineering mindset we can steer AI toward CRAFT instead of SLOP. AI Powered Search: LLM…
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…
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…
pay_with_blik_code Agent Skill for integrating BLIK payments into AI agent platforms. BLIK is a Polish mobile payment system that generates temporary 6-digit codes via banking apps. The skill guides an AI agent through the payment flow: summarizing order details, requesting a BLIK code from the user, submitting it, and verifying the transaction. Because BLIK codes are time-limited and single-use,…
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.…
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…
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…