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


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

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

Functional:
  • 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

Modelling

  • 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:
http://my_server_hostname:8080/my_large_file

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

Advantages

  • 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:

1
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.

2
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,

3
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:
1
00:00:06,244 --> 00:00:09,004
Le public a une idée très romantique du vin.

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

3
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;}' input_file.srt > output_file.srt

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.


Advice
  • 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

Friday, March 16, 2012

The Rails Community Has Reached the SOA Level

The Service Layer as the New Meme

I have read recently a bunch of articles about service-oriented architecture. Or at least that's how I like to call it.

A few months ago, there was the much-discussed Moving on from Rails (and then its follow-up).

More on the concrete side, Nicholas J Henry has written a nice blog post about the architectural aesthetics of extracting the core logic of your application into a service layer in a Rails-based project. His post can be summarized in one of his tweet:
Rails is not your application. It might be your views and data source, but it's not your application. Put your app in a Gem or under lib/.
Jared Carroll wrote an excellent article on when to use service objects. He recalls that Evans defined 3 types of services:

  • application (for a use case necessitating non-infrastructure operations, e.g. CSV export)
  • domain (for a use case requiring multiple domain objects whose responsibility is beyond a single object)
  • infrastructure (for a use case encapsulating access to external system, e.g. email or message queue)

I would summarize his blog post by saying that most applications do not need a (general) service layer (living in between your controllers and your models) when every request to your app goes through your service layer. Instead, your controllers act as the interface to the outside world and should constitute the service layer. In other words:
Most apps will typically have an HTML client and a few additional clients, for example, an iPhone and a console app, but the same controllers will serve both HTML and JSON. In a way, the controllers have become the services because all clients talk to the app over HTTP. 

Rails' Natural Evolution

I spent a few years of my life crafting (web and desktop) Java applications. And in the Java world, everybody knows about service layers. That's probably due to the fact that Java developers usually deal with relatively large code base, and if you don't have decoupled modules with their proper API (in other words, service layers), it's arguably impossible to maintain your codebase.

It might also due to the fact that Java has been there for quite some time, and Java-based web frameworks like Spring have seen quite a few springs by now. The goal of modularity so essential to the DataMapper's guys at the time reminded me all the emphasis put on the inversion of control pattern back in the early days of Spring. By injecting your dependencies, you could have plenty of different modules and could pick only the ones you like (as opposed to dealing with a monolithic framework as that was the case in the early days of Spring). But more to the point, based on my experience, almost all Java-based web applications will have controllers which talk to a service layer which talks to DAOs which talk to an ORM. That was 10 years ago.

And I think that's where the Rails framework is at: it's discovering service layers. More and more people are now using Rails for relatively large codebase, and as a result, they feel the lack of built-in support from their framework. There is a realization of the need for services. It feels like it's a milestone in the natural evolution of a web framework.

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)
  • Proc.new 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 = Proc.new do |e|
    puts "this is #{e}"
end

my_proc.call(2)
my_proc.(2)
my_proc[2]
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 Proc.new (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)
  p.call
end

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:

Decoupling

  • 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"


Architecture

  • 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.