DEV Community: Thomas R. Koll

A Ruby DSL in Practise

Thomas R. Koll — Sat, 03 Nov 2018 08:05:46 +0000

I'd like to share some more knowledge and the concrete implementation I did for my specific problem.

The software I'm working on is a personal finance web app and to make the sign-up process and first steps as easy as possible, I'm using programmatic templates that I can use to fill out a few forms during sign-up. The users will have several of those templates to choose from.

I shorted the code a little bit in functionality and it's MIT licensed if you want to use it.

Let's start with the data input file, it is Ruby code and extremely easy to read and understand:

ledger "Ledger for #{Date.today.year}" do
  unit '€'

  # Looks verbose, but the first it the name, the second argument the type.
  # The app is in German so the name would differ there
  account 'Equity', 'equity'
  account 'Assets', 'assets'
  account 'Expenses', 'expenses'
  account 'Income', 'income'
  account 'Liabilities', 'liabilities'

  transaction 'Bank account' do
    date Date.today
    entry 'Equity:Current', -200
    entry 'Assets:Bank:Current'
  end
  transaction 'Car credit' do
    entry 'Equity:Car', 5000
    entry 'Liabilities:Car'
  end
  recurring_transaction 'Health Insurance', monthly: 3, day_of_month: 15 do
    entry 'Assets:Bank:Current', -1550
    entry 'Expenses:Insurance'
  end
  recurring_transaction 'Job', weekly: 2, day: :tuesday do
    entry 'Income:Job', -2350
    entry 'Assets:Bank:Current'
  end
  recurring_transaction 'Rent', monthly: 1, day_of_month: -2 do
    entry 'Expenses:Living:Rent', 650.23
    entry 'Assets:Bank:Current'
  end
  recurring_transaction 'Envolopes', weekly: 1, day: :monday do
    entry 'Expenses:Food', 40
    entry 'Expenses:Fun', 20
    entry 'Expenses:Other', 30
    entry 'Assets:Bank:Current'
  end
  recurring_transaction 'Savings', monthly: 1, day_of_month: 1 do
    entry 'Assets:Bank:Savings', 75
    entry 'Assets:Bank:Current'
  end
  recurring_transaction 'Ratenkredit', monthly: 1, day_of_month: 1 do
    entry 'Liabilities:Car', 350
    entry 'Assets:Bank:Current'
  end
end

And this is the TemplateProcessor that handles those input files and processes them into a Ledger with transactions, recurring transactions and accounts. Obviously there are some data models for Ledger, Transaction etc, in my case I'm using MongoId but the DSL is independent of this. My extended version of the TemplateProcessor also has a few lines for dry runs where no data is stored.

You can clearly see the instance_eval running the inner block for ledger and transaction.

Calls from the input file like date and unit are passed on to the respective objects via method_missing

require 'cleanroom'
module TemplateProcessor
  def self.process(template, user, ledger = nil)
    dsl = DSL.new
    dsl.user = user
    dsl.ledger = ledger
    dsl.evaluate(template)
  end

  class DSL
    attr_accessor :user
    attr_accessor :ledger
    attr_accessor :ledgers

    def method_missing(method, *args)
      if @transaction && @transaction.respond_to?(method)
        @transaction.send("#{method}=", *args)
        return
      end
      @ledger.send("#{method}=", *args)
    end

    def ledger(name, &block)
      @ledger ||= Ledger.new(name: name)
      @ledger.ledger_roles.new(creator: user, user: user)
      @ledger.save!
      instance_eval(&block)
      @ledgers ||= []
      @ledgers.push @ledger
      @ledger = nil
    end
    expose :ledger

    def account(name, account_type)
      account = @ledger.accounts.new(name: name, account_type: account_type)
      account.save!
    end

    def transaction(description, &block)
      @transaction = @ledger.transactions.new(description: description)
      @transaction.date = Date.today
      @amount = 0
      instance_eval(&block)
      @transaction.save!
      @transaction = nil
    end
    expose :transaction

    def entry(account_name, amount = nil)
      if amount.nil?
        amount = - @amount
        @amount = 0
      else
        @amount += amount
      end
      @transaction.entries.new(account_name: account_name, amount: amount)
    end
    expose :entry

    def recurring_transaction(description, rule, &block)
      @transaction = @ledger.recurring_transactions.new(description: description)
      @transaction.rule = IceCube::Rule
      rule.each_pair do |method, args|
        @transaction.rule = @transaction.rule.send(method, *args)
      end
      @amount = 0
      instance_eval(&block)
      @transaction.save!
      @transaction = nil
    end
    expose :recurring_transaction
  end
end

sitemap_generator using lastmod date from git repo

Thomas R. Koll — Fri, 02 Nov 2018 12:24:23 +0000

For my new project Budget Fox I added sitemap_generator even though it's just a few pages that I want indexed for now.

One thing I noticed when looking at the output was the lastmod date being the same for all entries. Can't be hard to fix that by pulling the date from the git repo I though.
Here's the code for this and as you can see, I did monkey-patch SitemapGenerator::Interpreter.

class SitemapGenerator::Interpreter
  def lastmod(view)
    date = `git log --date iso  -n 1 --format="%ad" app/views/#{view}*`
    if date.blank?
      raise "Missing file #{view}"
    end
    return date
  end
end

SitemapGenerator::Sitemap.create(default_host: 'https://budget-fox.com', compress: false, include_root: false) do
  add root_path, changefreq: 'weekly', lastmod: lastmod('welcome/index')
  add team_path, priority: 0.5, lastmod: lastmod('welcome/team')
  add features_path, lastmod: lastmod('welcome/features.html')
  add pricing_path, lastmod: lastmod('purchase/new.html')
end

Stimulus component: Calculator for input fields

Thomas R. Koll — Fri, 02 Nov 2018 10:19:19 +0000

Here's a small stimulusjs component at I wrote for Budget Fox.

It calculates the value of an input with basic arithmetic like 2 + 10/3
and shows the result in the result target.

When leaving the input or submitting the form, the input's value is
replaced with the calculated value.:w

If the result target is set its innerText will be replace with the
value while the user is typing numbers and restored on leaving the input.

<div data-controller="input-calculator">
  <label for="amount" data-target="input-calculator.result">Amount</label>
  <input name="amount" data-action="keydown->input-calculator#calculate keyup->input-calculator#calculate blur->input-calculator#calculate" />
</div>

The data-action has three event listeners simply because stimulus is opinionated about
what events to listen to. We need more to update the result on key-strokes (keyup)
and update it when the users hits enter to submit the form (keydown)

import { Controller } from "stimulus"

export default class extends Controller
  @targets: ['result']

  connect: ->
    if @resultTarget && @resultTarget.dataset
      @flipResult = true
      @resultTarget.dataset['oldInnerHTML'] = @resultTarget.innerHTML

  calculate: (event) ->
    val = event.target.value
    if @flipResult
      @resultTarget.innerHTML = @resultTarget.dataset['oldInnerHTML']
    if val.match(/[+\-\*\/]/)
      try
        val = eval(val)
        if event.type == 'blur' || event.code == "Enter" || event.keyCode == 13 || event.which == 13
          event.target.value = val
        else if @flipResult
          @resultTarget.innerText = val

The code if of course MIT licensed.

Rspec: Shared context for DRY controller tests

Thomas R. Koll — Fri, 02 Nov 2018 09:38:01 +0000

Best if I start with a confession: The number of shared context or share examples that I have in my spec is a low digit.
No idea why I missed that trend, but with budget-fox.com I promise to do better and cut down on repetition in my specs.

If your controller specs are a bit like mine they might look like this:

  # ...
  let(:user) { Fabricate(:user) }
  before do
    sign_in user, scope: :user
  end
  # ...

That's actually pretty slim but with this very same pattern repeated over a few dozen controller there's something in rspec-core that's useful: shared
context

If you repeat the same let and before calls over and over again, it's best to put them into your spec/support folder, in my case in sign_in_context.rb. The context is then included from the controller spec.

# only argument is:
# scope (defaults to :user)
RSpec.shared_context "sign in user", :shared_context => :metadata do |args|
  signed_in_scope = args.fetch(:model, :user)
  let(signed_in_scope) do
    Fabricate(signed_in_scope)
  end
  before :each do |c, a|
    sign_in self.send(signed_in_scope.to_sym), scope: signed_in_scope
  end
end

And in the controller spec:

RSpec.describe Admin::UsersController, type: :controller do
  include_context 'sign in user', model: :admin
  it "GET #index" do
    # ...
  end
end