murb ♥︎ ruby

It may not be the fastest programming language, nor is it the most popular language when it comes to the numbers game, but how can you not fall in love with:

 10.times { print "Hello!" }

(instead of something like for(var i=0; i<10; i++){ console.log("Hello!"); })

Do things with sets like:

["a", "b", "c"] & ["b", "c", "d"] # gives you ["b", "c"]
[1,2,3] + [4,5] # gives you [1,2,3,4,5]
["a", "b", "c"] - ["b", "c", "d"] # gives you ["a"]

Or (with a little (opinions differ on this one ;)) help of Rails):

10.days.ago

That offers you exactly what you would think it would return: the date of 10 days ago.

And no ;’s, only brackets when absolutely needed, everything is an object…

Yes, it’s actually a language a human might understand, and still: it is pretty powerful, powering some of the most popular sites on the web, like AirBnB, Shopify, Basecamp (they’re the creators of Ruby on Rails), Github, Kickstarter, Twitch, Strava and many more (most of the full stack projects I did & do are using ruby).

When to use x-objects?

An article, posted 3 months ago filed in ruby, rails, ruby on rails, service, architecture & when to use.

So I wrote a few short articles on when to use FormObjects and Jobs and ServiceObjects. The question is of course "it depends", but the leading principle I have is keep it simple. That being said, for inspiration, some suggestion for different layers to manage the application complexity from Vladimir Dementyev's talk on Railsconf:

Presentation

  • Controllers (standard Rails)
  • Channels (standard Rails)
  • Views (standard Rails)
  • Presenters
  • Form Objects
  • Filter Objects

Application

  • Authorization Policies
  • Jobs (standard Rails)
  • Event listeners
  • Interactors
  • Deliveries
  • Notifiers
  • Mailers (s…

Continue reading...

When to use Modules / Concerns?

An article, posted 5 months ago filed in ruby, rails, ruby on rails, service, architecture, when to use & modules.

Whenever your model gets too heavy?

The easiest way to clean up your classes might be to create smaller, more concise methods. The next easiest way of tiding up your models is moving stuff to modules (whether they are 'Concerns' or not). Modules can then be included in the final classes. It will lead to a crowded list of methods exposed on these classes, for which alternative solutions exist (Presenters, Decorators), but if you shield off private methods nicely and have a consistent way of naming things, I wouldn't be too concerned about that. Note that having many modules used in only a single class might be a code smell: perhaps you're trying to do too much with that single class.

Concerns or Modules?

When you're using Rails, you can make use of Concerns. They offer a few advantages over traditional modules, so use it whenever you're bothering recreating the same behaviour using plain old ruby Modules. I prefer consistency, so if you've adopted Concerns, use con…

Continue reading...

When to use Form-objects?

An article, posted 5 months ago filed in ruby, rails, ruby on rails, service, architecture, when to use, async, form & models.

When necessary.

It depends. By default I would advise against them; not creating Form objects to receive and validate data that could be validated by the Model directly. Even when you have a few nested attributes that belong to the main model modified, I would advise against Form objects. Keep It Simple.

But… sometimes you have more complex forms that don't fit the database-mirroring model as nicely.

Continue reading...

When to use Job (or Worker) objects?

An article, posted 5 months ago filed in ruby, rails, ruby on rails, service, architecture, when to use & async.

Always.

When you are able to do stuff async (not blocking the web-request), make it async. It will also reduce the need for a category of Service-objects. Worker or Job objects can often be called inline if desired.

Sidenote: I personally prefer the "Job" object name, a Job that needs to be performed. Worker is a name that was popularised by Sidekiq, but Sidekiq moved to Jobs as well.

Continue reading...

Tag descriptor

When to use...

An article, posted 5 months ago filed in ruby.

I've got some opinions about certain ways of setting up more advanced (mostly Rails) applications. These might be short 'posts' which I might return to later. Let's see how it goes :)

Continue reading...

When to use Service-objects?

An article, posted 5 months ago filed in ruby, rails, ruby on rails, service, architecture & when to use.

Never.

There is of course never an absolute answer to stuff but if you are running it in a background job anyway have you considered directly writing it in a Worker or Job-object? Note that you can always run jobs async when needed.

My main objection against service objects is that all too often they are ill defined as a category. So while having fat controllers or fat models may be a bad thing, just creating a bunch of somewhat arbitrary 'Services' is not making the code more manageable.

When considering adding a 'services' directory to your app, try to think of what class of problems you want to tackle. And when in doubt, just keep messing around with the somewhat fatter models & controllers.

Continue reading...

Tag descriptor

pupprb

An article, posted about one year ago filed in rubygems, ruby & gem.

pupprb is a simple wrapper around puppeteer, a tool maintained by Google Chrome engineers, which I primarily use to print PDFs. This gem simply wraps my default settings / approach in a relatively easy to reuse gem.

Source: @gitlab Rubygems: pupprb

Continue reading...

Tag descriptor

CentralLogin

An article, posted more than 2 years ago filed in ruby, CentralLogin, gem, rubygem, murb, authorization, authentication, roles, groups, resources, open source, mit, openid & oauth.

A simple OAuth provider. See below for more information, or check out the source of CentralLogin on GitLab. To integrate it with your ruby-apps, use the omniauth-central_login gem.

Continue reading...

Introducing CentralLogin, an OpenID Connect Provider

An article, posted more than 2 years ago filed in ruby, CentralLogin, gem, rubygem, murb, authorization, authentication, roles, groups, resources, open source, mit & oauth.

This app builds on the foundations of the Doorkeeper, Doorkeeper::OpenidConnect and Devise to provide a central login system.

While Doorkeeper supports other OAuth flows, CentralLogin focusses on OpenID Connect as it is a more complete, and hence useful standard, for most use cases where you want to support authentication & authorization.

This project builds on years of juggling with different authentication providers and implementations. It may cut corners to be a pragmatic and less flexible solution which you can host on your own. You don't have to tie your users to a closed authentication system such as Auth0, Azure Directory, Cognito (the horror, really, stay away from it) or something else. In the past I've been a happy user of Keycloak, which is definitely way more advanced than this project, but it in the end it is a Java application and hence harder for me to maintain and not focussed on what I think are the core requirements :)

So, are you in the market for:

  • a…

Continue reading...

Tag descriptor

Capistrano

An article, posted more than 2 years ago filed in capistrano, deployment, automation, ruby & docker.

Capistrano doesn't evolve as quickly anymore but it still delivers and is still being maintained. It dates from before docker & autoscaling kubernetes were in wide use. I still prefer the simplicity of the tool: Capistrano I can understand, it is just a nice layer on running scripts on a remote server. Below some posts I did on Capistrano.

Continue reading...

Installing ruby with Capistrano & rbenv

An article, posted more than 2 years ago filed in capistrano, rbenv, deployment, script, task, automation & ruby.

While we're supposed to create docker(y) images and deploy these to the cloud, I'm still comfortable deploying and maintaining quite a range of applications using Capistrano (this builds on the battle tested server management process that I outlined more than 7 years ago). But Capistrano and its plugins are typically aimed at performing application level tasks, and not so much about configuring the environment.

I typically install ruby using rbenv. To deploy ruby apps using rbenv a Capistrano plugin exist (capistrano/rbenv) but it is missing the commands to install and/or update the ruby installation.

This snippet presented here adds a few commands:

  • cap rbenv:install ## installs rbenv
  • cap rbenv:update ## updates rbenv & install…

Continue reading...

Introducing BrandingRepo (for Rails)

An article, posted more than 2 years ago filed in BrandingRepo, ruby, rails, gem, mit, open source, Git, design & clients.

Ever had the problem that you reuse the same project for a managemable number of clients? Too few to store branding materials in a database, but more than one making it hard to keep separate branches in sync?

Introducing BrandingRepo (for Rails)

The idea is simple: create a configuration file with those files that are specific to different brands/customers and store their mods in a different repository. Repository is quite a big word here: we simply create a config/brands folder in your current branch where you can push and pull your brand specific adjustments from. All managed in the same git repository.

What it is not:

  • it is not git within git.
  • it is not a design system, nor has it anything to do with it (I think perhaps with a few additional hacks it can be made to work with centrally managed gems/node-modules; like here: https://twitter.com/hopsoft/status/1451358882161332225?s=10)
  • it is not adding brand icons to your project

Installation

Add this …

Continue reading...

Should I use Ruby on Rails in 2021?

An article, posted more than 2 years ago filed in rails, ruby, ruby on rails, laravel, symfony, php, python, django, flask, hanami, comparison, enterprise & trust.

I'm still a big fan of Ruby on Rails. No other framework has ever made me as productive. And it is no a secret that it makes quite some other product companies very successful. Think of Shopify, Github, Basecamp, Hey, and others.

But if you'd look at at the list of most popular languages, the top 10 doesn't feature ruby anymore.

In their 2020 survey on most popular technologies, StackOverflow writes:

> Additionally, Ruby, once in the top 10 of this list as recently as 2017, has declined, being surpassed by newer, trendier technologies such as Go and Kotlin.

Also if you look at Google trends, ruby has always been negligible when compared to Python or PHP or Javascript, [the trend is downward for the ruby package manager](https://trends.google.nl/trends/explor…

Continue reading...

Using Jekyll in 2021

An article, posted more than 2 years ago filed in ssg, jekyll, review, ruby & static site generators.

I am currently selecting a static site generator for an upcoming project. I value technical simplicity (exit React based solutions), like ruby and in the Static Site Generator category Jekyll is an established name. But doesn't the project that started in October 2008 show signs of age?

Pro’s:

  • It is ruby based (whether that is a pro for you depends on your aesthetics)
  • It is simple
  • It is easy to extend
  • Format for posts is Markdown
  • Hosting it is simple

Con’s:

  • Liquid (a templating language developed by Shopify) is limiting, I’d preferred ERB as a template language.
  • “There is a plugin for that” disappoints, many are pre-bundler era (hence requiring copying code) and quality differs a lot.
  • Lacks even a simple asset pipeline for JavaScript; hence bundle minified JS files together or build the final JS in a separate webpack-process.
  • The builds won…

Continue reading...

Why I stopped inheriting from ruby’s core Array class

An article, posted almost 3 years ago filed in workbook, gem, rubygems, ruby, inheritance & performance.

Inheritance is considered bad practice for quite some time now (Gamma, Helm, Johnson & Vlissides, 1994). Little did I know when I started the ‘workbook’-project in 2012 (note that I don’t have a computer science background).

The main reason I wrote this workbook-gem was that I wanted the most predictable API for working with spreadsheet data (acting as arrays of arrays), not having to use a different API when reading XLSX or CSV files, nor when writing it.

After learning that inheritance is not always a good thing, I still often thought of a workbook as an array of arrays and hence an exception to the rule. But then I came accross a helpful post by Avdi Grimm: [Why you shouldn’t inherit from Ruby’s core classes (an…

Continue reading...

murb blog