This post is a continuation of my previous post about integration and unit testing practices. I encourage to read previous post first.

Web Application Architecture

Traditionally we were using MVC frameworks to implement our web applications. While this pattern worked great in a past it is not a case anymore. The problem is that our applications are fairly complex nowadays. We expose features via the HTTP, via REST/Json API’s, we are communicating with external API’s, sometimes we have more than one storage. The problem of MVC is that it was not designed to tackle growing application complexity.

In traditional MVC approach your business logic is implemented in models. However while the application is growing models are growing as well. If you won’t tackle the growth of an application you’ll end up with 6000-lines long models with hundreds of callbacks.

Concerns that were introduced to Rails do not solve the problem. They do not deal with complexity. Instead they just move complexity aside so that we do not see it when we open a model class. But issues remains the same as without using concerns.

For applications that require tackling growing complexity, we need something more than plain old MVC.

The Hexagonal Architecture aka Ports and Adapters

Hexagonal Architecture may help us to tackle growing application complexity. The basic architecture in Rails application context is depicted in a following figure:

We see that we have 2 boundaries in this architecture. The core is where all domain logic lives. Outside the core, but still within application boundaries, lives all code related to the framework (Rails) and everything that wraps calls to IO, file system, external services even libraries. Everything else is external to the application.

It is important to note that through each component (port) dependencies goes in a same direction. Controllers depends on the core, but core is not depending on controllers. Core depends on models, but models are not dependent on core, and so on.

Testing the core

As said core is all your business logic. I’ve intentionally left that as a placeholder instead of describing what components should core consist of. It is really dependent on the application specific requirements and your fluency in Object Oriented Design. You can apply Domain Driven Design principles, you can create simple service objects. Whatever works given the application domain and requirements.

Note that things like DDD were designed to tackle growing complexity. If your application is not fairly complex and level of complexity is not rising using DDD is overkill. Do a good judge picking the right tools!

Because you don’t know the exact architecture of an application core it is perfect place to drive its design by tests. You can easily replace components that do not belong to the core with test doubles and test core independently from framework.

You may ask how isolation helps testing core logic?. Isolation comes with a burden of mocks and stubs, is it worth the price? I strongly believe that isolation helps significantly (and not just because tests are running faster, that is for free!).

Firstly if you are isolated from framework you deal only with complexity of a problem that you are solving (we call that essential complexity). You don’t need to deal with additional complexity inherited from the framework (that’s accidental complexity). Well at least other than framework/s used for testing.

Secondly mocks and stubs gives you greater control over the different circumstances that may happen. It is especially helpful if you want to test different scenarios including connection timeouts, etc. It is much easier to tell a mock to throw an exception instead of trying to simulate similar behavior on a real object. Sometimes you don’t even have access to test or sandbox environments.

It is quite safe to use mocks and stubs when testing core. Everything that surrounds core belongs to the application, so you are mocking only components that you own. That is very important.

Those are two great benefits of testing in isolation. And I believe they are worth the price.

Testing the boundaries

All that belongs to the application but is not a core I classify as a boundary. Those components are much different than core components therefore they should be designed and tested differently.

There is no point in driving design of boundaries from tests. The design is already enforced by the framework, API’s, libraries (even standard). There is not much benefit that you can get from test driving that part of an application.

Also the complexity of those components is not changing. The wrapper for an HTTP client will remain the same no matter which library you will use under the hood (whether it be Faraday, RestClient, or Net::HTTP). If the complexity is not growing and is predictable you will gain no benefit in tackling it.

There is no point in testing boundaries in isolation. Boundaries are thin components that delegates messages either outside the application or into a core. They unwrap data from structures and wrap to another structures. Not much of a logic to test here. We won’t limit accidental complexity by isolating boundaries. In fact it will amplify its impact as mocking components that you don’t own leads to a very fragile tests. Also frameworks are designed to provide nice DSL’s or API’s which are not grateful when mocking (like ActiveRecord call chains).

Despite if you will test boundaries in isolation you will need to test it also in integration/acceptance/system tests. You must ensure that not only boundary components are doing what they should, but they are integrating well with outside world and a core. Integration tests will cover everything that you might test in isolation (given the fact that boundaries are simple classes without much logic inside). There is no point in testing same piece of functionality twice.

Also you can be less restrictive when testing boundaries. While testing core you will check each possible condition that you can imagine and simulate, when testing boundaries you don’t need to remove every possible mandatory parameter from a request to ensure that it will respond with bad request each time. You don’t need to test functionality that is provided by framework. You just need to ensure that it integrates correctly.

Recap

When dealing with application that is fairly complex and you predict that the complexity will grow you need something more than plain old MVC. Wrap your core logic and surround it with a shell of components isolating it from outside world. Let those isolating components be logic-less, simple delegators that transforms data structures. Test drive your core design and test it in isolation, you will deal only with essential complexity and will have greater control over different scenarios and conditions. Do not test drive code that does not belong to the core. Its design is driven by frameworks, libraries or protocols and it is not a complexity that you want to deal with. Make your ports simple so that their complexity is at low, stable and predictable level.

Lately we are experiencing a holy war between TDD followers and those that stands against it. As a strong believer in OOP principles I should consider myself a TDD follower. However I think that the truth, as always, lies somewhere in between. I practice TDD only in a parts of an application, that I think makes sense to drive its design from tests. I’m not trying obsessively write tests first, because sometimes I simply can’t. Also I’m not trying to unit test everything. I believe there are parts that can and should be unit tested and some not. I’m trying to get best from both worlds.

So I’ve decided to describe my understanding on how and what to test and when to TDD.

Application borders

The key to understanding what to test as an unit and what requires integration testing is knowing that each application has its borders. What lies inside the borders you can call a core of an application and what lies outside the borders you can call… well it doesn’t matter how you call it. The point is that the majority of your testing and design efforts should focus on the core of the application. Also it is very important to ensure that all dependencies cross borders in same direction. Dependencies should go from your core to whatever lies beyond application borders.

The core of an application is all the services, interactors, business objects, however you call it, that implements your domain, business logic. All other stuff like framework, routing, database, external API’s, file system, external libraries, presentation layer are just supporting your core.

Given that what you should TDD and unit test is all your core logic. And the reason behind that is not tests speed. The tests speed is a benefit that we gain for free when we unit test in isolation. The reason is that when you unit test in isolation you have greater control over all the conditions that may happen on the borders of a system that you mock. It is much easier to simulate certain situations. It is easier to instruct a mock object to return certain response than to instruct external API. Sometimes you don’t even have any sandbox/test environment which you can call in your tests.

TDD works well in designing your core application logic. Classes are small, decoupled and easy to test. Tests speed is for free.

In contrast everything that lies on and outside borders should be tested in integration. There is no point to unit test Rails controllers or views. Similarly there is no point to unit test ActiveRecord stuff like scopes. It really doesn’t matter that a scope creates a query that you’ve expected, by calling appropriate ActiveRecord methods, unless you execute that query against the real database and ensure it is valid and returns proper records.

The point is that you must ensure that your core application logic integrates well with the outside world. You really don’t need to test every single case that may happen, leave that for unit tests if possible. Ensure that everything together works fine and you’ve done with integration tests.

When application borders blur

I think this is the cause of all misunderstanding in the whole against TDD story. The problem is that Rails blurred application borders. In fact core logic lies either in controllers or in models. We can say that the framework drives our design.

It is fine for simple, small to medium sized applications and whenever you need fast prototype. If you are in this situation do not fight against the framework design instead embrace it. However if your business logic is complex and you expect that size of your application will be from medium to large driving application design by the framework is not a good idea. You will die somewhere between 2000 and 6000 line of code of User class with hundred callbacks.

When application borders are not clearly defined you shouldn’t unit test. Its pointless as mocking all the details will kill you (have you ever mocked chain of ActiveRecord calls?). Driving design by tests is also pointless as framework already drives your design and they will conflict.

However if your application logic is fairly complex you will need something that wraps the core logic and clearly defines borders. Concerns that were introduced to Rails are not a good answer to that problem in my opinion. Concerns, which are nothing else but mixins, are form of inheritance and you really want to avoid inheritance if possible (and use aggregation instead). Here driving core logic design with TDD is perfectly fine. Everything else doesn’t need TDD-ing.

Driving design by integration/system tests is pointless. They are too general. Too abstract.

Where are my borders?

In typical Rails application controllers are your borders. ActiveRecord models are borders. Everything that calls external API’s and filestem are borders. Calling a class from a gem may be considered as a border, but it is not always a case, so you need good judge in this regard.

None of the above is particularly good to unit test. And also you cannot drive the design as the framework or the API’s already picked design for you.

Models should be tested against the database, to ensure that queries works well. Routing and views are best tested via the tools like Capybara. There is no point to mock out HTTP protocol.

If you call gem’s like Faraday or RestClient, even standard Net::HTTP you really want to wrap those with your own object like HttpClient. The reasoning is that you want to mock (in your core) only classes that you own. If you mock things from the libraries (even standard) you may fall into a situation that all tests are passing, but the actual application doesn’t work. Also your tests will be more fragile to gem/API’s changes.

In some future posts I’ll describe some techniques that I’m mentioning here.

Conclusion

As in every conflict there is no single truth and holy grail. Application core, encapsulated and with clearly defined borders is where you should focus your testing efforts and TDD. Design of code that lies on and beyond the borders doesn’t need to be driven by tests. It is already driven by framework, libraries, API’s etc.

Don’t be obsessively to not write a single line of production code before the test. From the other hand it is much easier to do with integration/system tests as you write general test scenarios that covers more parts of an application and on a higher lever not caring about the implementation details. General tests do not drive application design though.

Not all application needs to encapsulate core logic. However it helps significantly in complex applications and when you’ll need to maintain application for a long time. Decision is yours and judge well.

Do not be afraid of indirections (despite what DHH says). Indirection doesn’t destroy your design. With proper naming. simple, clean classes design is even easier to understand as you don’t need to care about the implementation details. You can even say what the system is doing by scanning the names of modules and classes in your core logic.

Focus your efforts on things that matters - application core logic. Test and design it well. Ensure that you cross the application borders in a correct way, you don’t need to test every single case for code that is not core for your application. Tests for core already are doing that so don’t repeat yourself.

Every developer has heard terms like loose or tight coupling yet still a lot have problems maintaining coupling in their codebase. Let’s take a look into some code and try to identify where it is tightly coupled and refactor making it more maintainable and testable.

Facing a code

So here is a class:

class ListsUsbSupportedFiles
  def list_absolute_paths
    Dir.glob(pattern)
  end

  def list_relative_paths
    Dir.glob(pattern).map { |path| path.gsub(usb_path, '') }
  end

  private

  def pattern
    "#{usb_path}/**/**#{supported_file_types}"
  end

  def supported_file_types
    @file_types ||= "{#{Document::SUPPORTED_FILE_TYPES.join(',')}}"
  end

  def usb_path
    @usb_path ||= UsbKey.new.path
  end
end

A purpose of this class is simple - it should be able to list relative or absolute paths to all files that are stored in a USB drive and are of appropriate, supported file type. Now pause for a moment and take a look onto that class and try to identify all places where it is tightly coupled.

Problems are rising

The easiest way to identify coupling is finding all references to other classes. Each time you’ve encounter reference to other class you should ask yourself: is this class really needs to know all that about that other class?.

Our example references following classes: Dir, Document and UsbKey. Let’s try answering above question for each of them:

• Dir - it is a class from a Ruby’s standard library. There is in fact nothing wrong referencing classes from the std-lib and this kind of coupling can be safely left and refactored only if there is a good reason behind that.
• Document - that class provides us a list of supported files. But do we really need to know that this list is in a Document class?
• UsbKey - this class is used to get a path to a directory where USB is mounted. But do we really need to instantiate that class to just invoke one method on it?

So we can say that coupling to classes Document and UsbKey is tight. But there is one more subtle kind of coupling in this class.

Huston now we have a real problem

You can argue that referencing to Document and UsbKey classes is a big problem. Maybe, but let me ask you something. How you would write a test for that class? Think about it for a while. How you would test if this class correctly lists file paths?

Current implementation is not only tightly coupled with UsbKey class. It is tightly coupled with a USB itself. You will need to have an USB stick plugged into your machine to make tests passing! Of course you could try mocking and it will work but let’s check how it might look:

UsbKey = double unless defined?(UsbKey)

allow(UsbKey).to receive(:new).and_return(usb_key)
allow(usb_key).to receive(:path).and_return(path)

It will work. But just because it works it doesn’t mean it is good. Firstly this amount of mocking for such a simple class should be already suspicious. Secondly what this code is really doing is mocking class internals and you shouldn’t care about class internals. Burn it into your head: never, ever mock object internals. Never. Just don’t do it. Everybody will be more happy. By internals you should consider all private methods, state and all collaborators which are not injected into that class. If you ever need to mock one of these in order to make code testable it means that your design is wrong.

If you are more interested in why you shouldn’t mock object’s internal state (also called implementation detail) check Ian Cooper’s great presentation.

Decoupling for the win

So lets try to refactor that class this time doing it right. Let’s start with writing some tests:

describe File::FileList do
  describe '#absolute_paths' do
    it 'returns absolute paths to files'
  end

  describe '#relative_paths' do
    it "returns paths realtively to list's root path"
  end
end

We are expecting a class File::FileList to provide 2 methods one to return absolute second to return relative paths. Both should include only paths to supported files however I’ve skipped that for simplicity and in fact current specs will cover that. In production we could add appropriate examples for documentation purposes.

We need to setup some directory and files structure as a fixture:

spec/fixtures/lib/file/file_list_spec/
    subdir/
        file2.rb
        file3.py
        ignore2.exe
    file1.rb
    ignore1.exe

Now we can imlement example for #absolute_paths method:

ROOT_PATH = File.join('spec', 'fixtures', 'lib', 'file', 'file_list_spec')
ABSOLUTE_ROOT_PATH = File.expand_path(ROOT_PATH)

subject { File::FileList.new(ABSOLUTE_ROOT_PATH, includes: %w(rb py)) }

describe '#absolute_paths' do
  let(:absolute_paths) do
    [
      File.join(ABSOLUTE_ROOT_PATH, 'file1.rb'),
      File.join(ABSOLUTE_ROOT_PATH, 'subdir', 'file2.rb'),
      File.join(ABSOLUTE_ROOT_PATH, 'subdir', 'file3.py'),
    ]
  end

  it 'returns absolute paths to files' do
    expect(subject.absolute_paths).to match_array absolute_paths
  end
end

Time to move some code to our new class:

class File::FileList
  def initialize(root_path, opts = {})
    @root_path = root_path
    @includes  = opts[:includes].join(',') if opts[:includes]
  end

  def absolute_paths
    Dir.glob(pattern)
  end

  private

  attr_reader :root_path, :includes

  def pattern
    "#{root_path}/**/**#{supported_files}"
  end

  def supported_files
    "{#{includes}}"
  end
end

I’ve introduced a list of supported files via optional hash parameter (in ruby 2.x we would use keyword arguments) that should be tested in separate context, but I’m not gonna to do that in this post.

Given code passes the specs so we can implement example for #relative_paths:

describe '#relative_paths' do
  let(:relative_paths) do
    [
      File.join('file1.rb'),
      File.join('subdir', 'file2.rb'),
      File.join('subdir', 'file3.py'),
    ]
  end

  it "returns paths realtively to list's root path" do
    expect(subject.relative_paths).to match_array relative_paths
  end
end

Now we can move remaining code to a new class:

class File::FileList

  # ...

  def relative_paths
    Dir.glob(pattern).map do |path|
      path.gsub("#{root_path}/", '')
    end
  end

  # ...

end

And we’re done!

Conclusion

Let’s summarize work we’ve done in the refactoring:

• We’ve removed coupling to Document class by providing a list of supported files in a constructor.
• We’ve removed coupling to UsbKey class by providing a path in a constructor.
• We’ve removed coupling to USB mount location making a new class more generic and potentially useful in other cases.

But most importantly by making a class decoupled we made it perfectly testable without a need to mock any of its internals. Not only the class is more useful but the code is more maintainable now. And thats the real profit of making objects loosely coupled.

Each time you are instantiating a class within some other class think do you really need to know that object. If there is only one particular information you need from it or you want to call some method but you are not interested on object’s state, probably you can achieve the same by injecting that object and decoupling things. This way you could test classes with ease. Limiting collaborators is a great and simple technique to achieve testable and maintainable code without much hussle.

If you are using RuboCop and like me you are working with some legacy codebase you may be interested in running this tool only against the files you’ve modified. Following snippet will do exactly that:

git status --porcelain | cut -c4- | grep '.rb' | xargs rubocop

More convenient script may be found here.

Solutions for this issue can be found on the internet, but this will work basically as a reminder for myself.

The reasons for freeze during restarts could be some but in most cases it is caused because Linux (kernel) doesn’t know how to perform restart given the BIOS that is present on the machine. Fortunately kernel has a few methods to perform restarts from which we can choose one that will work for our PC. I was experiencing the problem on DELL Latitude with Ubuntu 13.10 system.

So to fix the issue we need to pass reboot parameter to the kernel at the boot time. To do so in Ubuntu we can edit /etc/default/grub file. We need to search for the following line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Here we can provide command line options that will be passed to kernel during boot. In my case following fixed the issue:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash reboot=pci"

It looks that option reboot=pci in general solves the issue for DELL laptops.

After you change the option you need to execute:

sudo update-grub

And reboot machine in order to make provided options to take effect. You can check that by executing:

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic root=UUID=b5fd9a8a-4675-4277-9843-56a5c44fefb4 ro quiet splash reboot=pci

Once you ensure that linux was booted with correct reboot option you can test if reboot is working.

Other options that can be passed are as follows:

• warm - don’t set the cold reboot flag
• cold - set the cold reboot flag
• bios - reboot by jumping through the BIOS (only for X86_32)
• smp (reboot by executing reset on BSP or other CPU - only for X86_32)
• triple - force a triple fault - init
• kbd - use the keyboard controller. cold reset (default)
• acpi - use the RESET_REG in the FADT
• efi - use efi reset_system runtime service
• pci - use the so-called “PCI reset register”, CF9
• force - avoid anything that could hang

In most cases bios, acpi or pci will fix the problem.

You can pass multiple parameters at the same time and let Linux kernel to try them in order specified. So if you want to check if any of the parameters will fix the issue try following:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash reboot=warm,cold,bios,smp,triple,kbd,acpi,efi,pci,force"

If this solves the restart issue you can binary search for the exact option that will work for your PC.

In most cases when I see if..else statement somewhere in the wild it is an incorrectly, or not fully applied one of the OOP paradigms. From my observations developers finds difficult to identify proper abstractions. Of course its not wise to blindly abstract everything just because it can be abstracted, but it is good to know when and how we can introduce an abstraction if problem is (or will get) more complex.

Following is a snippet of a code that I’ve encountered lately. The purpose of this class was to parse CSV file and return user records. Sometimes users were provided via email (in this case user should be created if doesn’t exist) or via an id (in this case it must exist). The class should return all users that were found or created.

class ParsesUsers
  def parse(csv)
    [].tap do |users|
      CSV.foreach(csv) do |row|
        users << user_from_email_or_id row[0]
      end
    end
  end

  private

  def user_from_email_or_id(cell)
    if is_number?(cell)
      # find user by id
    else
      # find or create by email
    end
  end
end

Obviously we we are violating Tell Don’t Ask Principle in user_from_email_or_id method. Also it looks that class has more than single responsibility even though it has just few lines of code. How we can refactor? The simplest solution would be to delegate logic from the user_from_email_or_id method to a User class:

def user_from_email_or_id(cell)
  User.find_or_create(cell)
end

But I’m not a big fan of this approach. The problem is that this logic is not really logic that is core to User model. It is a logic that is required by the process of parsing the CSV file or other source. We can say it is more related to importing process rather than to a User model.

User model should take care of persisting users, validation and stuff related to ActiveRecord. If we start putting all random business logic into a User class it will quickly growth out of control and became dreadful God Class. And this is a case that I most often encounter in Rails apps. Developers blindly follow fat model, skinny controller pattern putting all random unrelated business logic into model classes. What we really need is some intermediate layer between controllers and models as we have between models and views named presenters.

Introducing an Abstraction

So what we can do rather than bloating User class with random business logic? Well we have at least two options here. Either we build abstraction over a cell which represents a single value of a CSV file (or basically any input file). Or we build abstraction over a User.

Abstraction over a Cell

We can create a Cell class that will know how to create users from its value:

class Cell
  def initialize(value)
    @value  = value
    @number = is_number?(value)
  end

  def user
    if number?
      # find user by id
    else
      # find or create by email
    end
  end
end

class ParsesUsers
  def parse(csv)
    [].tap do |users|
      CSV.foreach(csv) do |row|
        users << Cell.new(row[0]).user
      end
    end
  end
end

So what we really did with this refactoring is that we moved the if..else statement to a Cell class. Thats true, but instead of 1 class with several purposes (parsing and finding or creating a user) we have 2 classes with single responsibilities. We can easily test the Cell class and we can reuse it in other classes that will parse other files.

Abstraction over a User

Alternative approach would be to build abstraction over a User model. We could call it IdentityUser:

class IdentityUser
  def initialize(identity)
    @user = load_by_identity(identity)
  end

  private

  def load_by_identity(identity)
    if is_number?(identity)
      # find user by id
    else
      # find or create user by email
    end
  end

  # delegations...
end

class ParsesUsers
  def parse(csv)
    [].tap do |users|
      CSV.foreach(csv) do |row|
        users << IdentityUser.new(row[0])
      end
    end
  end
end

This approach is similar to presenter pattern, where instead of a User model we create some kind of intermediate object and delegate calls to the real model.

Using this approach we have even more flexibility comparing to previous one. We are not bound to the parsing input with cells, we can reuse this class wherever we need. The trade-off is that we need to implement methods delegating calls to a user model, but we can implement them on demand as they are required (or using some metaprogramming tricks via method_missing).

Benefits of a proper abstraction

So what do we gain with proper abstraction? In either case we didin’t removed the if..else logic, and in most cases we are still violating Tell Don’t Ask Principle.

The main benefit is testability. In all cases we can very easy test the logic that we are abstracting. In our case it is a very simple logic, but usually things are more complicated. Often I see developers that have problems testing controllers. Extracting logic to a service object easily solves the problem.

Another benefit is that we have clean and reusable classes with single responsibilities. Especially if we build abstraction over a User model in our example. Also we can change the business logic when a user is found or created, test-drive that change, and have it working wherever we used our class without touching consumers implementations.

When to know that abstraction may be introduced?

The easiest way to find out that you might be missing an abstraction is when you scratch your head asking yourself: How the hell I’m gonna to test that?. It is in generall very good practice, if for some reason you are not doing TDD, asking yourself how are you gonna test the solution that you are implementing at the moment.

So pay attention when you encounter following:

• Test requires huge setup of stubs/mocks and data.
• In order to test logic you are invoking a method that is invoking a method you are testing.
• You are broading the visibility of a method in order to test it (sic!).

Last 2 points in general means that logic that you want to test is hidden somewhere deep in a tested class internals. And in fact you shouldn’t be testing internals at all. Extracting logic that you want to test is an only solution you can do to solve this problem. You can extract this logic as a Service, Policy or Strategy object.

Disclaimer

To be honest in our case we left original implementation and skip the refactorings. For us it was a temporal solution, that we wanted to replace with better one. Each time you want to apply refactoring you should consider if it is worth doing given the context. Sometimes simple, procedural implementation is good enough and there is no point to refactor it.

Also note that it is fine to violate some OOP principles. Given a context of course. Principles are guidelines but you shoudn’t apply them blindly. Personally there is only one rule that I apply blindly. It is Single Responsibility Principle. This principle allows me to write small, simple classes that can be easily tested which is a foundation to write better code.

Writing complex queries in plain ActiveRecord is sometimes cumbersome. We need to fallback to write SQL-ish queries as plain strings which could cause errors and is not a way we should query using ORM frameworks. However there is very interesting solution for this problem called Squeel. As its GitHub page says Squeel improves ActiveRecord by making the ARel awesomeness that lies beneath Active Record more accessible.

So according to its documentation we can rewrite this:

Article.where ['created_at >= ?', 2.weeks.ago]

into this:

Article.where{created_at >= 2.weeks.ago}

Pretty nice in my opinion.

Now lets look at some more complex example. We have presentations that belongs to conference either via direct relation (conference_id in Presentation model), or through some event (event_id in Presentation and conference_id in Event model). Presentation could also be not yet assigned to any conference. Now we have admin panel with admin users dedicated to manage certain set of conferences and we want to scope presentations on view to only those which belongs to managed conferences, or which aren’t yet assigned to any (BTW if you are using ActiveAdmin you can scope the queries using scope_to). We need proper scope for this task, and one could be easily written using Squeel:

# models/presentation.rb
scope :unassigned_or_assigned_to, ->(conferences) do
  includes(:sessions).where{ (conference_id >> conferences) |
    (events.conference_id >> conferences) |
    ((conference_id == nil) & (events.conference_id == nil)) }
end

Usage of such scope is straightforward:

# models/admin_user.rb
def managed_presentations
  if superadmin?
    Presentation
  else
    Presentation.unassigned_or_assigned_to conferences
  end
end

I’ll definitely consider using Squeel whenever I’ll need to write complex query.