Elixer style pipes in ruby.

Pipes that are like mappings can already be reproduced in Ruby using the map method. Elixer allows you to treat the item as the first argument of a function call. This is an experiment with inserting arguments into procs.

class Proc
  def <<(*args)
    -> (*items) { self.call(*items, *args) }
  end
end

adder = -> (*args) { args.inject(&:+) }

puts [1,2,3,4,5]
  .map(&adder << 1)
  .map(&adder.<<(10, 100)).inspect 

A more Elixer style chain with class methods by monkey patching the Method class.

class Method
  def <<(*args)
    -> (*items) { self.call(*items, *args) }
  end
end

class Mathx
  def self.product(*args)
    args.inject(&:*)
  end

  def self.division(*args)
    args.inject(&:/)
  end
end

puts [1,2,3,4,5]
  .map(&Mathx.method(:product) << 4)
  .map(&Mathx.method(:division) << 2).inspect

Dashlane to KeePassX on OSX

KeePassX-2.0 is missing a lot of nice features on OSX, such as importing xml or csv files. Here is how to get around this ommission.

Open Dashlane and click File -> Export -> Unsecured CSV

Save the CSV

Run this ruby script to generate a KeePass0.4 compatible xml file.
https://gist.github.com/kwstannard/6135f77608690c51d0c3

Download KeePassX-0.4.3.dmg from here:
https://www.keepassx.org/releases/

Open KeePassX-0.4.3 and click File -> Import -> From XML

Select ~/pwds.xml to import

Enter a password for this imported DB. You should see your passwords in KeePassX-0.4.3

Save the imported database and close KeePassX-0.4.3. Remember where you saved it.

Open KeePassX-2.0 and click Database -> Import KeePass 1 database

Select the database that you just saved.

Use the same password as above to open the DB. You should now have your passwords in KeePassX-2.0

*** Delete the CSV, XML, and kdb files! ***

Maintaining keyword arity is hard

You know, sometimes you just can't bother with explicitly stating what keyword arguments that you want to pass.

DRY up your class definitions

Have you ever felt vaguely annoyed at typing the class name in the file name and then typing it again inside the file as well? Have you ever changed a class name and forgotten to change the file name?

Well I have good news for you!


Here is the code! This class allows you to condsolidate the declaration of class names into the file name. It also handles namespacing based on the file path if you are using Rails autoloading.

This works with the single exception of constant lookup via nesting, so you will need to replace constants with variables and methods.

How to reverse an array in Ruby in O(1)

class ReverseArray < Struct.new(:array)
  include Enumerable
  def each(&blk)
    i = array.length - 1
    while i >= 0 do
      yield array[i]
      i -= 1
    end 
  end
end

array = (0..10000).to_a
reverse_array = ReverseArray.new(array)

array.last == reverse_array.first
=> true

Superlet

Lets say you are testing your app superhero in RSpec:

RSpec.describe Superhero do
  subject(:superhero) { Superhero.new }

  it { is_expected.to be_super }
end

This superhero is sad because he has no powers though. So lets try giving him x-ray vision:

RSpec.describe Superhero do
  subject(:superhero) { Superhero.new }

  it { is_expected.to be_super }
  it { is_expected.not_to have_xray_vision }

  context "when given x-ray vision" do
    subject(:superhero) { Superhero.new(:xray_vision) }
    it { is_expected.to have_xray_vision }
    it { is_expected.to be_super }
  end
end

And now we want x-ray vision and flight:

RSpec.describe Superhero do
  subject(:superhero) { Superhero.new }

  it { is_expected.to be_super }
  it { is_expected.not_to have_xray_vision }
  it { is_expected.not_to have_flight }

  context "when given x-ray vision" do
    subject(:superhero) { Superhero.new(:xray_vision) }

    it { is_expected.to be_super }
    it { is_expected.to have_xray_vision }
    it { is_expected.not_to have_flight }

    context "when given flight" do
      subject(:superhero) { Superhero.new(:xray_vision, :flight) }

      it { is_expected.to be_super }
      it { is_expected.to have_xray_vision }
      it { is_expected.to have_flight }
    end
  end
end

This test looks pretty nice, but we would like it to be dry in case we want to change the names of the powers to fight a new supervillain. First lets use the power of arrays and the splat:

RSpec.describe Superhero do
  subject(:superhero) { Superhero.new *powers }
  let(:powers) { Array.new }

  it { is_expected.to be_super }
  it { is_expected.not_to have_xray_vision }
  it { is_expected.not_to have_flight }

  context "when given x-ray vision" do
    let(:powers) { [:xray_vision] }

    it { is_expected.to be_super }
    it { is_expected.to have_xray_vision }
    it { is_expected.not_to have_flight }

    context "when given flight" do
      let(:powers) { [:xray_vision, :flight] }

      it { is_expected.to be_super }
      it { is_expected.to have_xray_vision }
      it { is_expected.to have_flight }
    end
  end
end

Next we can use the super power of lets, super():

RSpec.describe Superhero do
  subject(:superhero) { Superhero.new *powers }
  let(:powers) { Array.new }

  it { is_expected.to be_super }
  it { is_expected.not_to have_xray_vision }
  it { is_expected.not_to have_flight }

  context "when given x-ray vision" do
    let(:powers) { super() << :xray_vision }

    it { is_expected.to be_super }
    it { is_expected.to have_xray_vision }
    it { is_expected.not_to have_flight }

    context "when given flight" do
      let(:powers) { super() << :flight }

      it { is_expected.to be_super }
      it { is_expected.to have_xray_vision }
      it { is_expected.to have_flight }
    end
  end
end

Woah, now we have perfectly dried up our tests, but how on Krypton does this work?

#describe and #context are aliases and both create classes descended from RSpec::Core::ExampleGroup, but the magic is that each example group is also a subclass of the example group that it is contained in so any methods defined within an example group can be accessed by its children. The innermost example group defined above will return this if you ask for its ancestors:

[RSpec::ExampleGroups::Superhero::WhenGivenXrayVision::WhenGivenFlight, RSpec::ExampleGroups::Superhero::WhenGivenXrayVision, RSpec::ExampleGroups::Superhero, ...]

The other half of this equation is that #let defines a method on the example group it is contained within. This means that every one of the classes listed in that ancestor list has the method #powers defined on it, and through the power of inheritance you can access #powers on the parent example group with the call to super().

RSpec Advanced Subject

So, as we all know, we shouldn't use subject. But what if you really like one liner syntax?

I am working on an attempt to make subject more dynamic and allow the use of one lines in more places. I am doing this by parsing describe arguments and adding a couple new blocks in order to build the subject dynamically.

For example:

describe Object do
  describe '#nil?' do
    it { should be_false }
  end
end

Will be parsed to know that the subject under test is the following: Object.new.nil?

What about class methods and methods with arguments?

describe File do
  describe '.read' do
    when_passed 'file.txt' do
      it { should eq('contents of file.txt') }
    end
  end
end

This will be parsed as File.read('file.txt'). This works by storing the method, what the method is called on, and what is passed to the method and putting it all together within a proc that is called as the hidden subject. A period before the method indicates it is a class method and a hash indicates it is an instance method.

Finally there is a way to pass variables to the initializer:

describe Array do
  when_initialized_with 2 do
    it { should eq [nil, nil] }
  end
end

This is just the basics and I am looking for feedback and more feature ideas. Currently I am trying to figure out passing blocks and how #let fits in.

rspec-advanced_subject