Monday, September 24, 2012

Is the Future Functional? by Rob Harrop

Here are my notes on Rob Harrop's presentation about functional programming.

Functional is important because

1) Simplicity
  • it's declarative
  • you write what you want to achieve, rather than give instructions how to achieve it
  • express solutions, not worry about individual steps

2) Agility
  • functional fits well with Agile methodology
  • testing is much easier (because of purity, no side-effects)

3) Contentment
  • self-content while you are working

4) Concurrency
  • e.g. parallelization
  • often the reason why people switch to functional

Imperative vs functional languages

  • function application (calculations to data), not state change
  • immutable state (makes testing easier)

  • focus on decisions (instructions), and state change
  • mutable state

  • recursion not looping
  • descriptions (of solutions), not statements

Functional features

  • higher-order functions
  • pure functions (same args in always lead to same results)
  • recursion
  • type systems (Haskell: strong typing; Erlang, LISP: loosely typed)
  • strict/lazy evaluation

DDD: primary focus should be on the domain and domain logic

DDD concepts

  • ubiquitous language
  • strategic design (identify which bits are harder to model and put time on it)
  • models
  • context

Domain-driven with imperative programming leads to anxiety. Always wondering if you got your model right, because there are a myriad of ways to implement a solution.

Functional DDD

  • core concepts still apply
  • everything is just a function or data structure

Why is functional better?

  • fewer concepts (no factories, no patterns)
  • easier concepts
  • lower model overhead


  • UML doesn't really work for functional
  • fortunately, we all know how to model in functional languages

Thursday, September 13, 2012

Transferring Large Files: Easy And Free!

I needed to transfer a 4GB file the other day. Unfortunately, there is no easy free way to do it. So I went the tech way.

How to

Upload the file to my_server (e.g. your server slice) via scp:
scp my_large_file my_server:.

In case your connection breaks up, you can resume the upload like this:
rsync --partial --progress my_large_file my_server:.

Log to your slice and move the file to a directory of its own:
ssh my_server
mkdir public_data
mv my_large_file public_data/

Start a simple HTTP server on the port of your choice (in this case 8080) from that newly-created directory, by running:
python -mSimpleHTTPServer 8080 &

That's it! Your file is now available for download at:

If you want to have that HTTP server process running even after logging out, find out its PID by running the jobs command, and then you can disown that process from the shell like so (assuming the PID was 1):
disown %1


  • no need to go through the hassle of installing a FTP server on your own machine.
  • don't care about leaving your machine turned on because you don't know exactly when the other party will be fetching the file.
  • the other party is not slowed down by your ISP's upload limits while trying to fetch the file from you.

Tuesday, May 29, 2012

How to remove every n-th line from a file

A bit of googling made me read this article, which was about sampling a file. What I really wanted was to remove every fifth line from a file.

Here is the input file:

00:00:06,244 --> 00:00:09,004
The public has a very romantic idea of what wine's about.
Le public a une idée très romantique du vin.

00:00:09,984 --> 00:00:14,373
They think it's some little guy, like me, working in the cellar,
On pense que c'est un petit producteur, comme moi, qui travaille à la cave,

00:00:14,473 --> 00:00:16,741
working in the vineyard, bringing the grapes in.
qui travaille dans le vignoble, qui vendange ses raisins.

And I wanted to have that kind of output:
00:00:06,244 --> 00:00:09,004
Le public a une idée très romantique du vin.

00:00:09,984 --> 00:00:14,373
On pense que c'est un petit producteur, comme moi, qui travaille à la cave,

00:00:14,473 --> 00:00:16,741
qui travaille dans le vignoble, qui vendange ses raisins.

So this made the trick:

awk '{if ((count++ +2)%5!=0) print $0;}' >

Friday, March 30, 2012

JavaScript: The Good Parts by Douglas Crockford

I have really enjoyed reading JavaScript: The Good parts. It has been recommended to me by many friends, and I'm certainly not disappointed. Douglas Crockford did an excellent job.

The book is highly opinionated, and that's a good thing, given that the author is seen as a prolific and talented Javascript expert by his peers. Here is an excerpt that gives you an idea of the book's tone:
The best thing about JavaScript is its implementation of functions. It got almost everything right. But, as you should expect with JavaScript, it didn't get everything right.

Things to remember

  • The prototype link is used only in retrieval. If you set a new property on an object (not on the prototype), it sets it on the receiver only.
  • The hasOwnProperty method does not look at the prototype chain. It looks in the receiver only.
  • Objects are passed around by reference. They are never copied.
  • It is important to understand that the inner function has access to the actual variables of the outer functions and not copies.
  • Objects produced from object literals are linked to Object.prototype
  • Function objects are linked to Function.prototype (which is itself linked to Object.prototype).
  • JavaScript does not have block scope. JavaScript does have function scope.
  • The general pattern of a module is a function that defines private variables and functions; creates privileged functions which, through closure, will have access to the private variables and functions; and that returns the privileged functions or stores them in an accessible place.
  • If all of the state of an object is private, then the object is tamper-proof. Properties of the object can be replaced or deleted, but the integrity of the object is not compromised. If we create an object in the functional style, and if all of the methods of the object make no use of this or that, then the object is durable. A durable object is simply a collection of functions that act as capabilities.

  • It is best to declare all of the variables used in a function at the top of the function body.
  • One way to minimize the use of global variables is to create a single global variable for your application: var MYAPP = {};

Is this book for you?

If you are wondering if you should read that book, you could test yourself. If you fully understand the code snippet below, you can skip it. If not, then you might want to invest in some quality reading. It's an excellent book to beef up your Javascript understanding.

Function.method('bind', function (that) {

  var method = this,
  slice = Array.prototype.slice,
  args = slice.apply(arguments, [1]);

  return function (  ) {
    return method.apply(that,
      args.concat(slice.apply(arguments, [0])));

var x = function (  ) {
  return this.value;
}.bind({value: 666});
alert(x(  )); // 666

Wednesday, February 1, 2012

An Introduction to Procs, by Peter Cooper

I have just watched the 27-min introduction on Procs by Peter Cooper, which is really a short section of his RubyReloaded course.

Here are my notes:
  • blocs are essentially nameless functions
  • the block_given? method can be used to find out if a block was passed to the current scope
  • blocks are anonymous functions which can be passed around and called at will
  • one can only pass a single block to a method, but one can pass multiple procs around (as arguments of a method)
  • will create a Proc object if there was a block passed in the current context (otherwise it will raise an error)
  • In Ruby 1.9, there are 4 ways to call (or run) proc objects:

my_proc = do |e|
    puts "this is #{e}"
my_proc === 2

  • a lambda is a proc object which respects argument arity, much like an anonymous method
  • in 1.8, "proc" (surprisingly) created a lambda (and not a Proc object)
  • in 1.9, "proc" is the same as doing (as we would expect)
  • a return in a proc will try to return from the context where the proc was defined (and not from where it is executed)
  • in a closure, ruby keeps references to variables. You can thus modify a variable's value inside a proc even after the proc was defined. Thus this code will output "Marc":
def run_proc(p)

name = "Fred"
my_proc = proc { puts name }
name = "Marc"
run_proc my_proc

Tuesday, January 10, 2012

Architecture the Lost Years, by Robert Martin

I watched a keynote from Robert Martin during the Ruby Midwest 2011 conference. It's always fun to watch veterans from the field.

Here are some thoughts:


  • the whole talk is about decoupling
  • the web is just a "delivery mechanism"
  • Ivar Jacobson's use case driven approach
    • make the intent of your system obvious
    • architecture: boundary, interactor (app specific), entity (app agnostic)

  •  we should keep in mind that:
    • the delivery mechanism (e.g. the web) is "just a detail"
    • the database is "just a detail"


  • art of architecture: drawing lines
  • architecture is about:
    • drawing lines
    • when you have a line crossing another, it's a dependency
    • making sure all dependency lines goes into the same direction (when crossing a line)
    • once you have that you have a gem/plugin
  • a good architecture allows major decisions to be deferred
  • if the first thing you type is "rails new_app", you've lost it. Rather, you must think about your entities, interactors and boundaries
  • a good architecture maximizes the number of decisions NOT made
  • in software engineering, at the end of the 80s, we were on the verge to understand that software architecture needed a use case-driven approach. But then the web got us away from it. And now we seem to be in the process of remembering it.

Sunday, December 18, 2011

Ruby Object Model and Metaprogramming screencasts by Dave Thomas

I bought 6 screencast episodes of Ruby metaprogramming about 3 years ago and only recently have I watched them all. And I must say: it was quite worth it! Just a reminder that it's never too late :) See below for my notes (which have been approved by Dave Thomas himself).

Episode 1 - Objects and Classes
  • Think in terms of object-oriented programming instead of class-oriented programming
  • 2 ways to change self: 
    • by a method call with an explicit receiver
    • by a class or module definition
  • a class does not have a name until you assign it to a constant
  • classes are first-class objects
  • class methods don't exist: they are actually singleton methods on class objects
  • method calling always works the same way. The ruby interpreter:
    • identifies the class of the receiver 
    • looks up the method in that receiver's class
    • if it does not find it, it goes up the hierarchy, and looks up the method in the parent of that class
    • retries the last step until it finds it 

Episode II - Sharing Behavior
  • Object#clone() copies the singleton method too; Object#dup() does not
  • with a prototype, you can clone both the behavior and the state of an object (which is not the case with class-based inheritance)
  • one can subclass from any expression, e.g. class A < (rand > 0.5 ? B : C)
  • do something in the singleton class like so: class << self ; # ... ; end
  • modules have 3 distinct usages:
    • namespace
    • to create module methods
    • to create instance methods
  • module methods can still be modified even if they have been included in a class, by reopening the module
  • a method of an included module will come before a method defined in a superclass, during Ruby's method lookup
  • extend(module_name) actually opens the receiver's singleton class and sticks the content of  module_name in it
  • reason because Person < ActiveRecord::Base is conceptually wrong: the intention is not to build a hierarchy (a "is a" relationship), but rather to share behavior

Episode III - Dynamic Code
  • several ways to create blocks. Worth mentioning:
    • lambda cares about arity (just like a method), proc does not 
    • a "return" inside a proc exits surrounding context
    • a "return" in a lambda exits the lambda
    • a "return" inside a do/end block will exist the surrounding context
    • lambda : like an anonomymous method
    • : like inline code
  • a Kernel method is available everywhere in our program
  • eval() takes a string and evaluates it as ruby code
  • a binding encapsulates: 
    • self, 
    • local variables (including method params)
    • any associated block
    • return stack
  • a proc object always has an associated binding
  • nothing prevents you from defining a method within a method
  • define_method() is only available in modules and classes

Episode IV - instance_eval() and class_eval()
  • instance_eval() can be called on any object
  • class_eval() is an alias to module_eval
  • class_eval() can only be called on classes and modules
  • a method definition in class_eval() evaluates in the receiver's class (thus creating instance methods)
  • a method definition in instance_eval() evaluates in the receiver's singleton class (thus creating class methods)
  • "self" in a block of class_eval() or instance_eval() is set to the receiver's
  • include() is a private method
  • you can change the "self" of a block with instance_eval(&block), e.g.
class Robot
  def move(&block)
    instance_eval( &block )

  def up;  puts "u"; end

  def down; puts "d"; end

robot =
robot.move do
  up   # no need for robot.up()
  down # no need for robot.down()

Episode V - Nine examples
  • memoization: @memory[skus] ||= expensive_calculation()
  • interesting examples making use of several metaprogramming techniques seen in previous episodes. If there's one episode to watch, make it that one!

Episode VI - Some hook methods
  • returns a subclass of Struct
  • method-related hooks:
    • method_missing
    • method_added
    • singleton_method_added
    • method_removed
    • singleton_method_removed
    • method_undefined
    • singleton_method_undefined
  • Class and Module hooks:
    • inherited
    • append_features
    • included
    • extend_object
    • extended
    • initialize_copy
    • const_missing
  • Marshalling hooks:
    • marshal_dump
    • marshal_load
  • Coercion hooks:
    • coerce
    • induced_from
    • to_xxx , e.g. to_s, to_proc
  • advice: don't forget to call the original method when writin code in the hook method to preserve behavior