Oleg Andreev

Start with algorithms

— I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.

— Can I summarize your thinking as “find the [generic] data structure inside an algorithm” instead of “find the [virtual] algorithms inside an object”?

— Yes. Always start with algorithms.

An interview with Alexander Stepanov, author of STL

Usually you start deciding what components your application consists of, then you write some code to glue them together. Later, you face a change in the requirements and start “fixing” the object model with a scotch tape. When you run out of tape you finally redesign your object model to fit the algorithm. Otherwise, if you focus on the algorithm instead of data structures, you’ll spend less time on (re)writing the code.

OOP, however, is orthogonal to this idea. Objects still encapsulate code (algorithms) and data (requirements). Requirements are set through the object’s interface. The only difference is that you should design objects from the algorithms perspective, not the abstract data relations. This is why relational database should be normalized, tuples should have as little number of fields as possible, object should do only one job etc.

Kaganov on security

Very good post (google translation) on airport security improvement and security strategies in general.

object.or { default_value }

class ::Object
  def blank?; false end
  def or(default = nil)
    blank? ? (block_given? ? yield : default) : self 
  end
  def and
    blank? ? nil : yield(self)
  end
end
class ::FalseClass
  def blank?; true end
end
class ::NilClass
  def blank?; true end
end
class ::Array
  def blank?; compact.empty? end
end
class ::String
  def blank?; strip.empty? end
end
class ::Hash
  def blank?; values.empty? end
end

"   ".or "Untitled"  # => "Untitled"
"   ".or { calculate_value } # => "42"
[nil].or { ["apple", "orange"] } # => ["apple", "orange"]

"data".and {|data| Wrapper.new(data) } # => wrapper
"  ".and { ... } # => nil

DRY and evolution

When you up to implement a feature similar to what you already have, there’s a huge temptation to refactor and abstract existing code right away. Sometimes you even have a perfect idea how it should be done.

Nevertheless, Don’t Do That.

Take an existing class, copy it, rename and update to meet your needs. Test, tweak, test again. You will see clearly how it is different from the original code. Don’t rush to extract common code, let yourself test/tweak more. Of course, don’t let it stay unDRY for a long time: it may become hard to refactor them later when you forget what you were actually doing.

In other words you should let your code evolve in a natural way like Darwin prescribed. Replicate and mutate the code: you will see better solution among the options. Then according to the Rule Of Survival Of The Fittest delete everything not worth living.

In many-many cases this technique helps to avoid wasting time on fitting code into wrong abstractions built on pure imagination.

[Blames himself for the mistakes of the past.]