mediafinger

# filename: single_page_rails_app.ru
# RUN via: `rackup single_page_rails_app.ru`

require "bundler/inline"

gemfile(true) do
  source "https://rubygems.org"

  gem "rack", "2.2.9"
  gem "rails", "~> 7.1"

mediafinger

# Example code to allow instances of the `User` model to have multiple `roles`:


# Migration -------------------

class AddRolesToUsers < ActiveRecord::Migration[7.0]
  def change
    add_column :users, :roles, :text, array: true, default: [], null: false
  end
end

mediafinger

GeoJson Markdown

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "id": 1,
 "properties": {

mediafinger

Draft

Ich schreibe mal runter, wie ich mir den Prozess vorstelle, ohne mir die SLOC API Docs anzuschauen:

• wir starten den SyncSlocSensorsJob
• der nimmt sich alle Sensoren die in den letzten X Stunden nicht gesynct wurden last_synced_at
• bei den am längsten nicht gesyncten anfangend, ruft er die SLOC API in Batches of 10 ab
• bei erfolgreicher Response
  • wird last_synced_at in den 10 Sensoren updated nachdem
• die Werte in der DB gespeichert wurden

mediafinger

Mastodon

mediafinger

Packwerk

Is a Ruby gem to help separate concerns inside a Rails monolith.
https://github.com/Shopify/packwerk

Treat data modeling for packages like data modeling for network-isolated services:
hold foreign IDs referencing models across package boundaries, but do not hold strictly enforced foreign database keys and do not use ORM associations that would hide the separation of concerns.

Following the upper advise would be quite a change for our models. But less dependent: :destroy | :nullify | nil decisions could actually make our lifes easier and our data more consistent (or just more fault tolerant). And not to forget that Packwerk allows to start small and increase its checks file by file.

mediafinger

Refactoring Example

I’ve found some confusing code in a project and would like to explain how and why I refactored it. As this is a small, very focused refactoring one can do in a "drive-by" manner while implementing another small change in this method, I think it serves well as an example.

Before

The first thing that confused me was that our frontend is not sending the parameters we explicitly permit in the route_event_params method (see below), instead it is sending *_uuid parameters...

And yes, this project unfortunately has id as primary_key and later added uuid which is the one known to the frontends.

mediafinger

Fancy UUIDs

UUID v4 UUIDs have the big drawback of being non-sortable. Fancy UUIDs encode the timestamp (just one digit short of microseconds) on the first bits and are therefore sortable.

They also encode a shortname of the generating model class, to make them globally identifiable.

Compatibility

Fancy UUIDs are just UUID v4 UUIDs - PostgreSQL and any other tool will be able to treat them like any other UUID v4 UUIDs.

mediafinger

Ok, I've refactored the service to not use the connection_pool, but to use a new connection instead.

And this also satisfies the rspec tests. I still don't understand what the issue was, but this is a working solution,
and as far as I see it also prevents us from blocking more and more connections, but instead closing them reliably.

This is the new code:

class ExecuteSqlService
 class << self

mediafinger

How to Update a Ruby on Rails app

To safely update the Ruby and Rails version, your app should have a proper test suite you can rely on. But even with a great test suite, I always recommend running a rake task, starting the rails console and starting the rails server and using your app in the browser, before opening a PR and asking for reviews.

Ruby updates

Do it incrementally, don't skip any minor versions.

Which means, if your app is still on Ruby 2.7.x, then first update to the latest 2.7.X version, before updating to the latest 3.0.Y version and only when this has been done successfully, upgrade to the latest 3.1.Z version.