DEV Community: MetaDave 🇪🇺

Oracle fragmentation

MetaDave 🇪🇺 — Sat, 07 Dec 2024 21:48:42 +0000

Ruby Value Objects for Sets

MetaDave 🇪🇺 — Tue, 05 Feb 2019 12:35:54 +0000

TL;DR

Sometimes a set of value objects has its own attributes in addition to the attributes of the individual values themselves.

Background

When we have a single value and we want to infer behaviour from it, for example when we have country codes and we want to be able to read the continent name, the currencies, or the key of the national anthem, then a value object is probably what we're looking for.

And when we have a set of such single values, such as a list of countries to be visited in a trip, then we also want to send messages to that list of countries.

At the simple end, we might have #count, or #uniq_count if countries can be present more than once, currencies (expecting a list of the currencies for all of the countries in the list to be returned), etc..

Quite often there are issues of compatibility or completeness involved in a set, and the code for detecting these issues needs a home.

That home is probably a value object.

class Countries
  def initialize(*countries)
    @countries = Array.wrap(countries)
  end

  delegate :count,
           :any?,
           :empty?,
           :entries,
           to: :countries

  def currencies
    countries.map(&:currencies)
  end

  def uniq_count
    countries.uniq.count
  end

  def compatible?
    etc
  end

  def closed_loop?
    countries.first == countries.last
  end
end

A bibliographic example

Consider an example: a code list that we at Consonance use a lot, the Thema subject categories for book publishing. A publisher assigns multiple codes to a book to inform third parties, such as sales agents, other publishers, distributors, retailers, and ultimately the potential buyer, what it is about and who might be interested in it.

You can see by browsing the list that there is a huge range in the subjects coding, reflecting that some books are intended for professional or academic practitioners, for children, for people with a general interest in pets, and there are also codes for place, time, and special themes (birthdays, seasonal holidays etc).

Many of these can be combined for a single book, and we expect all of them to be individually valid of course.

But some further questions can arise when you consider all of the codes assigned to a book:

Are codes being used which suggest that others should also be present, and if so are those others actually present?
- Do children's books have an age range?
- Do law books contain a geographical restriction? In general every professional law book relates to a particular geographical region.
- Is a book about archaeology also coded for both time and place?
Are there codes being used which are possibly not compatible with each other?
- Is a book about a scholarly subject also coded as being of interest to children under five years of age?
- Is a book coded for general interest also coded for professional interest?

So individual codes can each be valid, while the combination of them can be problematic in a number of ways.

The important point here is that these complete? and valid? attributes are of the set of codes, not of the individual codes themselves, and might be implemented as:

class ThemaSet
  def initialize(*set)
    @set = set
  end

  delegate :any?, to: :set

  def errors
    errors_of_incompatibility + errors_of_incompleteness
  end

  private def childrens?
    any?(&:childrens?)
  end

  private def professional_or_scholarly?
    any?(&:professional_or_scholarly?)
  end

  private def historical?
    any(&:historical?)
  end

  private def child_incompatible?
    childrens? && (professional_or_scholarly? || adult_themed?)
  end

  private def missing_time?
    !timed? && historical?
  end

  private def missing_place?
    !placed? && (historical? || legal?)
  end

  private def errors_of_incompatibility
    [].tap do |errors|
      errors << "codes incompatible with child coding are present" if child_incompatible?
    end
  end

  private def errors_of_incompleteness
    [].tap do |errors|
      errors << "codes should be accompanied by time coding"  if missing_time?      
      errors << "codes should be accompanied by place coding" if missing_place?
    end
  end

Back to the real world

So the pattern there is reasonably clear, I think.

The set-value object examines the attributes of the individual value objects in order to produce characterisations of the set as a whole.

Although the example given was quite specific to a business area, this pattern of complete? vs incomplete?, and compatible? vs incompatible?, leading to attributes of valid? and a list of errors is a common one.

And this makes it amenable to the use of the ValidValidator described here

In many cases the individual objects will not be plain value objects, but might be derived from an ActiveRecord-backed has_many association. But if the set of objects has its own attributes, then that is still a candidate for this technique.

class Book
  has_many :thema_codes

  def thema_set
    @_thema_set ||= ThemaSet.new(thema_codes)
  end

  delegate :valid?,
           :errors,
           to:     :thema_set,
           prefix: true
end

Further functionality

A variation on this can be used to answer the question, “what is the effect of a particular change to a set?”.

Given a current set and a candidate member of it, you can compare the original against the original + candidate-value, and ask of it "have I changed a property of the set by making this change, such as introducing (or solving) any errors?"

And the implementation of that is reasonably clear:

class SetComparator
  def initialize(set_object, new_value)
    @original_set = set_object
    @new_set      = set_object.class.new(set_object.entries << new_value)
  end

  def errors_added
    new_set.errors - original_set.errors
  end

  def errors_removed
    original_set.errors - new_set.errors
  end
end

Running Heroku CLI commands in an Heroku application

MetaDave 🇪🇺 — Fri, 01 Feb 2019 11:16:09 +0000

TL;DR

With the Heroku CLI buildpack you can execute CLI commands against an Heroku application.

Setting it up

Add the build-pack and redeploy code.

There are some security credential things you have to do, but they're documented here.

Don't forget that you can connect to your app using heroku run bash -app my-application to run the credentials commands to get an API key to store as the HEROKU_API_KEY environment variable, and to do testing.

What you can do with it

You can run command lines from your Heroku application to do whatever can normally be done from the Heroku command line.

You can run these commands from within your application itself, or by using the Heroku Scheduler add-on, and you with the appropriate credentials you can do this from a different application.

For example:

Run a manual backup of your PostgreSQL database.
Rescale your dynos without using an add-on.
Restart your dynos at a particular time every day, before the working day begins.
Run rake tasks from within your system using a one-off run dyno of an arbitrary size.

We are currently using this to scale down one system overnight and scale it back up again before the working day starts, and for restarting another system's dynos at 5am local time.

We do this through a separate application, issuing the commands through the Heroku Scheduler add-on.

Running rake tasks from within your application

I'm very interested in experimenting with this idea.

We have a particular type of batch job that can vary hugely in workload:

So small that it can be executed synchronously by the application in a couple of seconds.
Too big to be synchronous, but fine for a Standard-2X worker dyno to handle in the background.
Too big for a Standard-2X, and too time-consuming to allow a worker to be tied up. Maybe a one hour job on a Performance-M dyno.

I can see us adopting logic that allows us to judge which of these approaches is required, and executing the appropriate logic.

Summary

That's it.

Ruby Value Object Instance Caching

MetaDave 🇪🇺 — Fri, 25 Jan 2019 08:54:19 +0000

TL:DR

Value objects with few distinct values can be cached to save memory.

Problem

We love value objects, but they're not free of system impact. Each instance uses memory, and the less of that we use the better (looking at you ActiveRecord).

Some value objects would naturally be expect to have very many distinct values (ISBN, SSN, email address), and may even be unique, but some have very few. There are only a couple of hundred countries in the world to share among your 100,000 Customer records for example, and in practice you might only be using a small number of those.

If you wanted to categorise all of your customers according to country, or an attribute of the country, Customer.map(&:country).map(&:currency).uniq, then you would probably rather not initialise 100,000 instances of the Country value object.

Solution

Provide a caching mechanism, so multiple calls to Country.new("ES") return the same instance of the Country class.

One of the principles of value objects is that they be immutable, so this is fine.

class Country
  def self.new(code)
    @instance_cache ||= {}
    @instance_cache[code] = super(code) unless @instance_cache.key?(code)
    @instance_cache.fetch(code)
  end

  def initialize(code)
    @code = code
  end
end

Other memoisation techniques might be more pleasing to an individual. Choose one that works for you.

Calling Country.new("DE") causes:

@instance_cache to be set as an empty hash if it is not already defined.
@instance_cache to be checked to see if "DE" is already a key – if it is not a new instance of Country is initialised and added to @instance_cache.
The instance for "DE" to be read from @instance_cache and implicitly returned.

As a bonus, this is also slightly faster than instantiating a new instance.

Demonstration

Consider two value objects:

class CountryCached
  def self.new(code)
    @instance_cache ||= {}
    @instance_cache[code] = super(code) unless @instance_cache.key?(code)
    @instance_cache.fetch(code)
  end

  def initialize(code)
    @code = code
  end
end

class CountryUncached
  def initialize(code)
    @code = code
  end
end

2.4.4 :001 > class CountryCached
2.4.4 :002?>     def self.new(code)
2.4.4 :003?>         @instance_cache ||= {}
2.4.4 :004?>         @instance_cache[code] = super(code) unless @instance_cache.key?(code)
2.4.4 :005?>         @instance_cache.fetch(code)
2.4.4 :006?>       end
2.4.4 :007?>   
2.4.4 :008 >       def initialize(code)
2.4.4 :009?>         @code = code
2.4.4 :010?>       end
2.4.4 :011?>   end
 => :initialize 
2.4.4 :012 > 
2.4.4 :013 >   class CountryUncached
2.4.4 :014?>     def initialize(code)
2.4.4 :015?>         @code = code
2.4.4 :016?>       end
2.4.4 :017?>   end
 => :initialize 
2.4.4 :018 > 
2.4.4 :019 >   
2.4.4 :020 >   CountryCached.new("DE")
 => #<CountryCached:0x00007f8bff83b430 @code="DE"> 
2.4.4 :021 > CountryCached.new("DE")
 => #<CountryCached:0x00007f8bff83b430 @code="DE"> 
2.4.4 :022 > CountryCached.new("FR")
 => #<CountryCached:0x00007f8bff037ce8 @code="FR"> 
2.4.4 :023 > CountryCached.new("DE") == CountryCached.new("DE")
 => true 
2.4.4 :024 > CountryCached.new("DE") == CountryCached.new("FR")
 => false 
2.4.4 :025 > 
2.4.4 :026 >   
2.4.4 :027 >   
2.4.4 :028 >   CountryUncached.new("DE")
 => #<CountryUncached:0x00007f8bfe877a08 @code="DE"> 
2.4.4 :029 > CountryUncached.new("DE")
 => #<CountryUncached:0x00007f8bfe85f958 @code="DE"> 
2.4.4 :030 > CountryUncached.new("FR")
 => #<CountryUncached:0x00007f8bfe854670 @code="FR"> 
2.4.4 :031 > CountryUncached.new("DE") == CountryUncached.new("DE")
 => false 
2.4.4 :032 > CountryUncached.new("DE") == CountryUncached.new("FR")
 => false

For the cached value, the object ids for the two "DE" values is identical: 0x00007f8bff83b430. For the uncached value they are different: 0x00007f8bfe877a08 and 0x00007f8bfe85f958.

Note also one of the benefits, that the objects themselves are now directly comparable:

2.4.4 :023 > CountryCached.new("DE") == CountryCached.new("DE")
 => true

2.4.4 :031 > CountryUncached.new("DE") == CountryUncached.new("DE")
 => false

So to summarise then ...

Caching instances of value objects by overriding the class new method:

Is not very difficult
Improves memory usage
Makes objects directly comparable

Nice.

Rails Value Objects – One Validator to Rule Them All

MetaDave 🇪🇺 — Wed, 23 Jan 2019 14:16:00 +0000

TL;DR

Validation of all value objects can be achieved with a small custom Validator class.

Problem

When you define a value object in Ruby, and in particular in Rails, it is a natural part of its functionality that it should tell the difference between valid and invalid initialisation inputs.

So a value object would naturally have a #valid? method, and maybe an #errors method as well.

Since Rails gives you the ability to apply validations to attributes, do you also need one custom validator for each value object? Is there a succinct and efficient way of connecting Rails validators and your value objects?

Background

A value object can generally tell us whether it is valid or not. Indeed this might be a major reason for creating a value object, so that it can encapsulate all of the validation logic, and respond to valid? appropriately. @email.valid?, @zip_code.valid?, @isbn.valid?, etc.

For example consider a Country object that is initialised with a two-letter ISO country code such as "GB" or "FR". It can reference a valid codes list to define the list of valid country codes, and various attributes: its name, whether it currently exists or not, perhaps a capital city name.

So when input is accepted we need to check that the input value is valid according to the code list (and maybe we add something to clean up any easily corrected issues like lower case inputs or spaces).

Therefore we might fairly expect that Country.new("XA").valid? will respond with false, and Country.new("x1").errors should respond with ["Country codes must be a two-letter ISO 3166-1 alpha-2 code"]. And you're correct, I do write the best and most precise error messages in the world.

In many cases you will have sanitised the input in front-end logic of course, and for a code from a small list of values or for a simple algorithmic validation, that is always going to help. For more complex cases (is the ISBN in a range that we recognise to have been assigned by ISBN International, for example) we may defer the logic to the server, and rely on a value object for validation anyway.

We probably want to protect our database from invalid values, by using standard Rails validation in the model class:

  validates :country, erm what goes here?

Solution: The Valid Validator

If all of our value objects define the same responses, then the way is open to treat them the same way with a single custom validator.

Here is a class that we can use to validate any object that can enumerate its errors:

class ValidValidator < ActiveModel::EachValidator
  def validate_each(record, attribute, value)
    value.errors.each { |error| record.errors.add(attribute, error) }
  end
end

I think that we can all agree that that is an imaginative and accurate name, although I would also accept NoErrorsValidator.

All of the errors read from the value object are added to the record errors, and every value object that implements an errors method can be validated with this same class.

So here's how you use it:

  validates :country, valid: true

... with all of the usual options ...

  validates :country, valid: true, allow_nil: true

allow_nil: true causes the validation to be skipped if the value object responds to nil? with true, so make sure your value objects respond to that – see also Ruby nil value objects in this series.

And here we have it – one ActiveModel validator to rule them all.

  validates :country,             valid: true, allow_nil: true
  validates :construction_method, valid: true, allow_nil: false
  validates :height,              valid: true, allow_nil: false
  validates :occupancy_class,     valid: true, allow_nil: false

If by "all" we mean "value objects", that is.

Ruby Nil Value Objects

MetaDave 🇪🇺 — Tue, 22 Jan 2019 15:04:35 +0000

TL;DR

A value object can be much more concisely defined if you dedicate a different class to handling null values. The null value class can be a Ruby singleton, so only one instance is ever instantiated, saving memory.

Problem

So value objects in Ruby are great.

But not everything has a value all of the time. Nils are everywhere, and how do you efficiently handle them?

If you get it wrong then you're going to be staring at this sort of thing:

class ISBN
  def initialize(input)
    @isbn_string = input
  end

  def gs1_prefix
    if isbn_string.nil?
      nil
    else
      isbn_string[0..2]
    end
  end

  def checksum_number
    if isbn_string.nil?
      nil
    else
      isbn_string[-1]
    end
  end

  def valid?
    if isbn_string.nil?
      false
    else
      etc
    end
  end

  delegate :nil?, to: :isbn_string
end

... or maybe you rely on empty strings giving you the right behaviour throughout ...

class ISBN
  def initialize(input)
    @isbn_string = input.to_s
  end

  def gs1_prefix
    isbn_string[0..2]
  end

  def checksum_number
    isbn_string[-1]
  end

  def valid?
    etc
  end

  def nil?
    isbn_string.empty?
  end
end

An empty string is not a nil though, so this is a convenience that is also a little bit wrong.

A Solution

One solution to consider is an explicit “nil object” approach, which provides a response to everything that an instance of ISBN responds to, with the appropriate value for an ISBN that has no specified value or is missing.

As a bonus you only ever need one instance of this object, so you can use a Ruby singleton to represent it.

class ISBN
  class NilObject
    include Singleton

    def gs1_prefix
      nil
    end

    def checksum
      nil
    end

    def valid?
      false
    end

    def nil?
      true
    end
  end
end

... and your ISBN object's instance methods can be simplified to:

class ISBN
  def initialize(input)
    @isbn_string = input
  end

  def gs1_prefix
    isbn_string[0..2]
  end

  def checksum_number
    isbn_string[-1]
  end

  def valid?
    etc
  end

  def nil?
    false
  end
end

How to invoke this object? This works nicely ...

class ISBN
  def self.new(input)
    if input.nil?
      NilObject.instance 
    else
      super(input)
    end
  end

  def initialize(input)
    @isbn_string = input
  end

  etc
end

Yeah that's right, we overrode the new class method to return a different class. That's problematic if you enjoy type checking, but I don't think you should – you should perhaps care more that whatever is returned responds correctly.

Further thoughts

If that is not your style, see the initialisation methods considered here and consider:

module ISBNInitializerExtensions
  refine String do
    def to_isbn
      ISBN.new(gsub(/[^[:digit:]]/,""))
    end
  end

  refine NilClass do
    def to_isbn
      ISBN::NilObject.instance
    end
  end
end

This lets nil.to_isbn return a concisely defined singleton that has just the appropriate behaviour.

And why the #nil? method? You're going to need that for validations ... another post later.

Make sure you have code coverage of the nil object class, and that you have tested that it responds to everything it needs to respond to.

And lastly, other specialised object types can also be defined, so you might have ISBN, ISBN::NilObject, and ISBN::Invalid for complex cases where the behaviour of an object initialised with an invalid value differs from that of a valid value.

Flexible Ruby Value Object Initialisation

MetaDave 🇪🇺 — Mon, 21 Jan 2019 18:46:00 +0000

Problem

Value objects in Ruby are lovely things, and invaluable in a complex application.

But one issue that always seems to trip me up is correctly initialising from other objects, so while we might want to write:

class ISBN
  def initialize(value)
    @isbn_string = value
  end

  def etc
  end
end

... it turns out in practice that sometimes you're creating a value object based on string input, and sometimes it might make sense to store the value in the database as a numeric but you can be sure that a controller will receive it as a string, and other times it already is a value object.

Enough of all that nonsense – you need to be able to initialise your value object based on almost anything that might represent its value.

Making it so

So what do you think of this?

class ISBN
  def initialize(value)
    @isbn_string = if value.is_a? String
                     value.gsub(/[^[:digit:]]/,"")
                   elsif value.is_a? Integer
                     value.to_s
                   elsif value.is_a? NilClass
                     ""
                   end
  end
end

Pretty bad.

One of the principles of object-oriented design that you might pick up along the way is that this sort of code is A Bad Thing, because we're not supposed to care about what type/class an object is, only about what it can respond to.

Now if we were sending the a message #address to an object, we'd be fine – we'd just expect the Person/Company/Owner/Invoice etc classes to implement that method, and because they are our own domain objects and we write the code for them, we can define whatever behaviour we want on them.

But what do we do when the object is one of the Ruby core classes? String, Integer, or even NilClass?

One answer is to monkey patch, but by now I think we all know that that is Also A Bad Thing and that we should instead be implementing a refinement.

How about this?

module ISBNInitializerExtensions
  refine String do
    def to_isbn_string
      gsub(/[^[:digit:]]/,"")
    end
  end

  refine Integer do
    def to_isbn_string
      to_s
    end
  end

  refine NilClass do
    def to_isbn_string
      ""
    end
  end
end

It's not too bad, as the ISBN initialisation then becomes:

class ISBN
  using ISBNInitializerExtensions
  def initialize(value)
    @isbn_string = value.to_isbn_string
  end

  def etc
  end
end

We can scatter ISBN.new(obj) around the system and the ISBN class doesn't need insights into the cleansing for a string or a number. It assumes that the input value has implemented it.

But we don't do Integer.new("78") very much, do we? We like "78".to_i instead. (OK, we can do the explicit method, but only when we need the specific behaviour that that brings with it. Otherwise we just send #to_i).

We also need to know the name of the class that implements the ISBN object, and how to initialise it, but maybe that's not such a big deal.

Taking it a little further, what about:

module ISBNInitializerExtensions
  refine String do
    def to_isbn
      ISBN.new(gsub(/[^[:digit:]]/,""))
    end
  end

  refine Integer do
    def to_isbn
      ISBN.new(to_s)
    end
  end

  refine NilClass do
    def to_isbn
      ISBN.new("")
    end
  end
end

This module becomes the location in the system where we convert core Ruby classes to the application-defined class ISBN, and the only place where we need to do refactoring if we wanted to change the name of the ISBN class.

And we could implement similar logic for #to_zip_code, #to_country, #to_currency, etc., with similar benefits.

And then, secure in the knowledge that the classes which might need to return it have already implemented the clean-up, we can write:

class ISBN
  def initialize(value)
    @isbn_string = value
  end

  def etc
  end
end

And we're back where we started, with a nice, clean initialisation and the ability to:

  "978-3-16-148410-0".to_isbn
  9783161484100.to_isbn
  nil.to_isbn

.. as long as we have first added using ISBNInitializerExtensions to the class or module where we want to use it (which admittedly seems to make it tricky in Rails views for some reason).

For completeness, we can ...

class ISBN
  def initialize(value)
    @isbn_string = value
  end

  def to_isbn
    self
  end

  def to_s
    @isbn_string
  end
end

This does make value object definitions in Rails a thing of very little code:

class Book
  using ISBNInitializerExtensions

  def isbn
    @_isbn ||= self[:isbn].to_isbn
  end

  def isbn=(obj)
    self[:isbn] = obj.to_isbn.to_s
  end
end

Summary

So there are two options here:

Refine the clean-up of the parameters, taking them out of the initialiser, and letting us do ISBN.new(obj) for fairly arbitrary classes of obj.
Refine the complete transformation, allowing obj.to_isbn within any class or module where we have invoked the use of the appropriate refinement.

One further point: to more explicitly hint that this is our application's refinement on the behaviour of the object, would it be wise to have a naming convention that uses "as" instead of "to", for example 9783161484100.as_isbn? At a push you could claim that the "as" is an acronym for "application specific", if you really wanted ...

Do You Use Calculators or Programs?

MetaDave 🇪🇺 — Wed, 18 Apr 2018 13:25:02 +0000

I have just realised that I can no longer be bothered to find the calculator program on my Macbook, and instead just open an Interactive Ruby Shell (a.k.a. irb) to do my arithmetic.

I'm wondering if this is a common (dys)function, and does it vary by the language you use?

Are there, for instance, JS programmers out there who will just do a bit of casual arithmetic in their browser console?