Oleg Andreev



Software designer with focus on user experience and security.

You may start with my selection of articles on Bitcoin.

Переводы некоторых статей на русский.



Product architect at Chain.

Author of Gitbox version control app.

Author of CoreBitcoin, a Bitcoin toolkit for Objective-C.

Author of BTCRuby, a Bitcoin toolkit for Ruby.

Former lead dev of FunGolf GPS, the best golfer's personal assistant.



I am happy to give you an interview or provide you with a consultation.
I am very interested in innovative ways to secure property and personal interactions: all the way from cryptography to user interfaces. I am not interested in trading, mining or building exchanges.

This blog enlightens people thanks to your generous donations: 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo

Interfaces in dynamic object-oriented languages

Object interface is a set of messages with defined behavior the object should respond to.

In statically typed languages, interface is required by type declaration. In dynamically typed languages this is done by telling object of unknown type to cast itself to the desired type.

# User's code expects object responding to #to_page
# when casted to page, we expect proper #render and #size behavior
class SomeController
  def process(object)
    page = object.to_page
    page.render
    page.size
  end
end


# 1. Page class with #to_page interface returning self
class Page
  def to_page
    self # return self since it is already a page
  end

  # page public api

  def render 
  end

  def size
  end
end

# 2. Non-page class with #to_page interface
class AtomicBomb
  def to_page
    # return a relevant article
    Page.wikipedia_article("Nuclear weapon")
  end
end

# 3. Class without #to_page, but with #render method
# fails with "object does not respond to #to_page" exception
# and does not cause undesirable side effects
class Foo
  def render
    # very specific nasty rendering method
  end
end

# 4. Class without #render
# fails with "object does not respond to #to_page" exception 
# rather than with less descriptive "object does not respond to #render"
class Baz
end

This technique minimizes duck typing collisions by reducing the number of exposed methods to a single “to_{unique_type_name}” method. It also protects you from inventing obtrusive method names with type prefixes such as “page_render” or “page_size_in_characters” (see example above).

The rule of thumb:

1. When API consists of more than one method, introduce #to_my_type method

2. Whenever you receive an object from an unknown source (e.g. defined in a different file), use explicit type casting with #to_some_type method.

Note: never ever make others ask about the kind of an object using #respond_to?. This method should be used for legacy code and indicates possible duck typing issues.

Also, #is_a?(SomeAbstractInterfaceModule) is considered badly designed compared to #to_* methods.