Posts

Repositories serve as a crucial component of the persistence layer within an application. Their primary purpose is to encapsulate the functionality provided by Rails' Active Record and expose a subset of simplified methods for querying and persisting data. By utilizing repositories, we can isolate Active Record operations to this subset, ensuring that other layers of the application only interact with the desired queries and methods. In the context of our application, the Bike Repository now handles all operations that were previously managed by the Bike Record....

When I started this project I thought the database would be the last stuff, and for whole development process, CSV files would be enaugh. But now I realize, it would be much simpler to follow want I want to achieve if switch to a regular database now. There are a lot of possibilities to choose from, a lot of databases, and since I don’t sync data from external services yet, probably I can make a mistake, and choose wrongly....

Today topic what is super simple if we are using any frameworks. Environments. It’s nice to split our configuration between different situations. If we have some external integrations, probably we are going to use different API keys at every environment. But even when we are thinking on local stuff, every environment should use different database By having multiple environments, you can isolate different stages of the application’s lifecycle and ensure that changes are thoroughly tested and validated before reaching the live environment....

Today nothing special. I created second CRUD based on first one. Components - our bikes have parts, so there would be bike_id. This is optional because we could have components not mounted to any bikes, but we still want to monitor their situation. So all code looks very similar but this time index should allow to filter by bike_id. def index(request) bike_id = request.params['bike_id'] components = read_database if bike_id filtered_components = components....

One of the most important parts of every repo is readme. I know that, but for some reason, I still don’t have it yet. I don’t want to describe what exactly I want to put in my readme, but I want to describe what readme should have. The main goal of having a README file in a project is to provide essential information and guidance to anyone who comes across the project....