Woman on Rails

In today’s fast-paced digital landscape, building an app goes far beyond writing code. From understanding user needs and incorporating feedback to the critical role of service design, we’ll explore the various components that contribute to a successful app launch. Discover how a small team can deliver meaningful features, engage users through community building, and maintain a strong focus on sustainability - all while meeting the challenges of rapid development. I will illustrate these points using the Indyx app, a digital wardrobe solution.

Testing is critical in any system, especially asynchronous applications. It’s important to test each component in isolation, while carefully managing the communication between them. It is essential to ensure that everything works together seamlessly. For this reason, I would like to share with you the approach we take to testing in our Event-Driven system.

It’s a good practice to remain independent of external tools, gems, or libraries. Of course, in many cases, we do rely on external code, and that’s normal. Otherwise, we’d end up doing things like HTTP requests or user authentication ourselves, and that would distract us from the real needs of our customers. So the balance between using external tools and creating custom solutions is crucial. The real question is how can we use external tools and still have enough flexibility in our code? That’s what we’ll focus on today, using our integration with RailsEventStore as an example.

The Programmer’s Dilemma: As a dedicated developer, you care deeply about your project. You actively perform updates, refactor code, write tests, and more. At some point, however, you realize that a gem you rely on at the core of your system has become obsolete. Its last update was several years ago, and it no longer supports the latest version of Ruby. What do you do? Do you pressure the gem’s maintainer to fix the problem? Do you take over maintenance of the gem yourself? Do you switch to an alternative solution, or even create your own? In this RailsEventStore series, I will show how we transitioned from the wisper gem to the rails_event_store gem in just three months.

Do a quick online search for “Rails Default Scope” and you will get a ton of articles: why you should not use default scope at all, why default scope is the root of all evil, how to remove default scope from your project. These articles often have a strong negative opinion about default scope. But is default scope really that bad? The default scope discussion has been going on since at least 2015, almost a decade of Rails development, and people are still talking about it.

Have you ever thought about the to_a and to_ary methods for the Array class? Are they the same? Why do we have two similar methods? What is the difference? What about implementations of these methods in classes other than Array? In this article I want to answer these questions. So let’s get started!

From time to time, when I create a code, people ask me: Is this working? , or they tell me: I didn’t know that. Being in those situations allows me to understand that something normal for me can be new for someone else. So, today I would like to share with you some Ruby tips and tricks. I hope you will like them.

A few days ago, I worked on a customer project, and I wanted to use one line map but with an argument for a method inside this map. I never had this need before. Normally in one line map, I do something like .map(&:next). This time I needed something else. So, I did a short research on how can I do that. The results of this research were so interesting to me that I decided to create an article about this topic. So let’s get started!