Interesting Talk: "Software Naturalism - Embracing the Real Behind the Ideal"

This is an interesting talk by Michael Feathers in which he "analyzes real code bases concluding that code is not nearly as beautiful as designers aspire to, discussing the everyday decisions that alter the code bit by bit":

• Software Naturalism - Embracing the Real Behind the Ideal

Calling an assembly function from C passing parameters by reference

In a recent post I showed how to call an assembly function from C. In that example we passed the exponent and base parameters by value to an assembly function, p_pow.
In this example, we'll see how to pass parameters by reference.

This time, instead of using the RAX register to return the result of the p_pow function, we pass a third parameter by reference that will hold the result.
This is the calling C code:

#include "stdlib.h"
#include "stdio.h"
#include "assert.h"

// Assembly function declaration
extern void p_pow(int, int, int *);

int main(void) 
{  
  int result;

  p_pow(2, 2, &result);
  assert(4 == result);
  
  p_pow(3, 2, &result);
  assert(9 == result);
  
  p_pow(5, 2, &result);
  assert(25 == result);   
  
  p_pow(6, 2, &result);
  assert(36 == result);   
  
  p_pow(3, 3, &result);
  assert(27 == result);      
  
  p_pow(3, 0, &result);
  assert(1 == result);
  
  p_pow(1, 5, &result);
  assert(1 == result);
  
  p_pow(-2, 2, &result);
  assert(4 == result);
  
  p_pow(-2, 3, &result);
  assert(-8 == result);

  printf("All tests passed!\n");
  return EXIT_SUCCESS;
}

Look at the prototype of the p_pow function.

extern void p_pow(int, int, int *);

We want to pass result by reference. Since in C everything is passed by default, to pass a parameter by reference what we actually do is passing by value the memory address where result is stored. That's why we've used a pointer.
This is the assembly code:

section .data          
  
section .text                

  ; Make the function name global so it can be seen from the C code
  global p_pow              

p_pow:
  push rbp
  mov rbp, rsp ; Stack initial state is stored
  
  push rdx     ; Store initial value of RDX 
               ; (memory address where the result will be stored)
               ; because RDX can be modified by MUL operation
  
  ; The base (b) is being passed in RDI register
  ; and the exponent (e) is being passed in RCX register
  
  mov eax, 1   ; Register RAX will hold the result temporarily
  
  cmp esi, 0   ; if (e == 0) -> b^0 = 1, and we're done
  jle pow_end   
  
  mul_loop:
   mul edi     ; eax*ebx = edx:eax (when operating 
               ; with ints, edx is not used).
   dec esi     ; esi = esi - 1
   jg mul_loop ; If esi > 0, it continues iterating
  
  pow_end:
  
  pop rdx      ; Restore initial value of RDX
               ; (memory address where the result will be stored)
  
  mov [RDX], dword eax ; Copy final result in memory
  
  mov rsp, rbp ; Stack initial state is restored
  pop rbp                     
  ret           

Now we compile, link and execute the program and we get:

$ yasm -f elf64 -g dwarf2 pow.asm 
$ gcc -g -o pow pow.o pow_c.c
$ ./pow
All tests passed!

Note that in the assembly code, the RDX register is holding the memory address where result is stored. That's how the assembly program is able to change its value. As I explained in a previous post, in the calling convention of the System V AMD64 ABI the registers RDI, RSI, RDX, RCX, R8 and R9 are used for integer and pointer arguments.
To see it better, we'll use gdb.
This is the content of the registers in the first call to p_pow right after executing mov [RDX], dword eax:

(gdb) info register
rax            0x4 4
rbx            0x0 0
rcx            0x0 0
rdx            0x7fffffffe0fc 140737488347388
rsi            0x0 0
rdi            0x2 2
rbp            0x7fffffffe0e0 0x7fffffffe0e0
rsp            0x7fffffffe0e0 0x7fffffffe0e0
r8             0x7ffff7dd7300 140737351873280
r9             0x7ffff7deb5f0 140737351955952
r10            0x7fffffffdf50 140737488346960
r11            0x7ffff7a76c90 140737348332688
r12            0x400460 4195424
r13            0x7fffffffe1e0 140737488347616
r14            0x0 0
r15            0x0 0
rip            0x400568 0x400568 <pow_end+3>
eflags         0x246 [ PF ZF IF ]
cs             0x33 51
ss             0x2b 43
ds             0x0 0
es             0x0 0
fs             0x0 0
gs             0x0 0

The RDX register contains the memory address of result and the content of that memory address is 4:

(gdb) x/d $rdx
0x7fffffffe0fc: 4

We've seen how by passing its memory address by value, we were able to change the content of a variable from inside an assembly function, as though we were passing the variable by reference.

Books I read (January - April 2012)

January
- Estructura de la informació. UOC. (2nd time)
- Estructura i tecnologia de computadors. UOC. (2nd time)

February
- Working Effectively with Legacy Code, Michael Feathers
- La acabadora, (Accabadora) Michela Murgia

March
- Thinking in C++, Volume 1, 2nd edition, Bruce Eckel
- Refactoring: Improving the Design of Existing Code, Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

April
- Midnight's Children, Salman Rushdie

Interesting Talk: "Rethinking Unit Testing in C++"

This is a very interesting about how unit testing in C++ should be done:

• Rethinking Unit Testing in C++ by Kevlin Henney

Articles and Posts read

Inspiring
María Moliner la mujer detrás del diccionario
Enrique Meneses: “El futuro son los bloggers”
Do Hard Things

Learning and Software Craftsmanship
Towards A More Empirical Understanding of The Effects of TDD (That Really Matter)
It’s Not About The Number Of Hours You Put In
Fight the Dragon
Learn to Read the Source, Luke
This is Why You Spent All that Time Learning to Program
10 Reasons to Avoid Test Driven Development
TDD: Big leaps and small steps
Programming expertise, it’s all about the turtles
Mock Objects Despoil Your Tests
Just Observe
Stop Chasing Exit Strategies And Start Chasing Great Software
Compartir la visión de equipo
5 Lessons Learned While Being a Freelance iPhone Developer
TestCoverage

Agile and Lean
Enough With The Movements! Movements Are Stupid.
The Best-Kept Management Secret On The Planet: Agile
Moving fast requires good communication
Which Part of the Glass Are We Talking About?

C++
Los grandes proyectos informáticos se programan en C y C++
Talk + panel online: “(Not Your Father’s) C++” + “Native Languages” Panel
The Programming Languages Beacon
C++ at Facebook
C++ Renaissance
std::string, SSO, and Move Semantics
The Lost Decade?
Efficient Abstraction
Gestión segura de datos sensibles en memoria

JavaScript
A Baseline for Front-End Developers
¿Por qué JavaScript?
Book Review: Test Driven JavaScript Development

Functional Programming
The Downfall of Imperative Programming

Entrepreneurship and Management
Respondiendo a verdades y mentiras de montar una empresa en Inglaterra
La verdad (y los números) detrás de 560.000€
La verdad (y la técnica) detrás de 560.000€
Profound Shift In Focus
Los beneficios de trabajar en casa los viernes
El Gobierno reducirá en un 48,8% las ayudas al autoempleo y la creación de empresas
La influencias de las nuevas tecnologías en la destrucción y creación de empleo
La tecnología detrás de un acortador de URLs, Karmacracy al desnudo
Así es el pequeño competidor español de Samsung
Botado en Vigo el oceanográfico más avanzado del Mundo

Science
Un as en la manga: Los fagos de Tiflis
Evolution has given humans a huge advantage over most other animals: middle age
Persistent myths about open access scientific publishing
España de nuevo en Science por culpa de los recortes y la fuga de cerebros
Duro varapalo a la hipótesis de la precognición de Daryl J. Bern y al método científico
Reproducing papers

Blogging
This isn’t a recipe.

Web Development
The future of Web development isn’t MVC, it’s MVM

NoSQL
A Year with MongoDB

Python
Python Scientific Lecture Notes

Open Source
How A Geek Dad And His 3D Printer Aim To Liberate Legos

New tools
Koding – Un antes y un después en la vida de los programadores
Light Table - a new IDE concept

Spain and Europe
El suicidio económico de Europa
Carta de un investigador al rey don Juan Carlos
El fraude del modelo alemán y el mito de su “proyecto político”
"Para vivir peor con el euro que con la peseta, mejor dejarlo"
Distintas ante la ley
"O hay una movilización ciudadana o a España le esperan 10 o 15 años de crisis"
¿Nos van a obligar a salir del Euro?
El problema de la Eurozona no está en la periferia sino en el centro: Alemania

Using Mocha to test a Backbone application on Node.js

@remosu and I are working on a backbone single page application (SPA).
We started using Jasmine to write our specs, but we felt it a bit awkward for asynchronous testing, so we decided to try with Mocha.

Mocha is a feature-rich JavaScript test framework which promises making asynchronous testing simple and fun. Since the goal of this backbone SPA is just learning, we decided to add node to the game: we’d run Mocha on node.

This post will describe how we set up our environment to test our Backbone code using Mocha on node.

First of all we installed node following this useful link.
Once node was up and running, we installed npm following the instructions in this link.
npm is a package manager for node that we used to install all the modules required to run our tests.

This is the code of our tests:

var should = require('should');
var jQuery = require("jquery");
var Backbone = require('backbone');

var BMModel = Backbone.Model.extend({
    idAttribute: "_id"
});

var BMCollection = Backbone.Collection.extend({
    model: BMModel,
    url : "nn"
});

describe("BMCollection", function(){
    var bmcollection;
    beforeEach(function(){
         bmcollection = new BMCollection({url:'collection_tests'});
    });          
    it("is defined", function(){
        bmcollection.should.not.equal(undefined);
    });
});

describe("banana", function(){
    var bmcollection;

    describe("read all", function(){
        beforeEach(function(){
            bmcollection = new BMCollection();
            bmcollection.url = '/collection_tests/';
        });

        it("gets contents from banana", function(){
            bmcollection.fetch();
        });
    });
});

The second describe is not testing anything yet, we just wanted to run it to confirm that our environment was correctly set up. But it did not worked, because it couldn't find some dependencies.
To make it work, we had to install the following node modules: mocha, backbone, jquery and should.
Ok, but where should they be installed?
The nmp FAQ explains what should be installed locally and what should be installed globally:

I installed something globally, but I can't `require()` it
Install it locally.
The global install location is a place for command-line utilities to put their bins in the system PATH. It's not for use with require().
If you require() a module in your code, then that means it's a dependency, and a part of your program. You need to install it locally in your program

So we installed should, jquery and backbone locally using:

$ npm install should
$ npm install jquery
$ npm install backbone

whereas we installed mocha (that was being used as a command) globally:

$ npm install -g mocha

Having done that we tried to run our tests again doing:

$ mocha --reporter spec test/acceptance/*.js

but we got an error saying that an ajax object was undefined in fetch.

That puzzled us for a while. We had to check the backbone source code and think for a while (we are just beginners with JavaScript) to realize how to fix it.
This is a fragment of the backbone source code:

var root = this;
...
var $ = root.jQuery || root.Zepto || root.ender;

We think that the problem was that backbone was not setting its $ variable properly, probably because this was not referencing the global object when called from mocha in node.
After some trial and error, we used the setDomLibrary() method to inject jQuery as the DOM manipulation and Ajax calls library in backbone:

var should = require('should');
var jQuery = require("jquery");
var Backbone = require('backbone');
Backbone.setDomLibrary(jQuery);

This is not necessary when using backbone directly because the $ is initialized by default to jQuery, Zepto or Ender.
In this case it was failing because the this object wasn’t the global object.
Now, finally, the tests run and we were ready to start coding.

Calling an assembly function from C: simple example

This semester I'm studying AETC in ETIS in the UOC.
For one of the course assignments I had to use some C mixed with assembly.
To make things simpler in this first assignment, we were asked to use only global variables to pass information between the main C programs and the assembly subroutines.
Since I wanted to know how to do it without global variables, I started to explore a bit.

After some googling and reading several blog posts I found out that, first of all, I needed to identify which calling convention to use. There are many different calling conventions, which one you use depends on your architecture, language or even operative system.
I was using a x86-64 architecture in a 64 Bit Linux, so checking this Wikipedia list of different x86 calling conventions I finally found out that the one I needed to use was: the System V AMD64 ABI convention.
From Wikipedia:

System V AMD64 ABI convention
The calling convention of the System V AMD64 application binary interface is followed on Linux and other non-Microsoft operating systems. The registers RDI, RSI, RDX, RCX, R8 and R9 are used for integer and pointer arguments while XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6 and XMM7 are used for floating point arguments. For system calls, R10 is used instead of RCX.[9] As in the Microsoft x64 calling convention, additional arguments are pushed onto the stack and the return value is stored in RAX.

Once I knew how to pass parameters to an assembly function from C, I coded a simple integer power computation to test it.
This is the calling C code (pow_c.c):

#include "stdlib.h"
#include "stdio.h"
#include "assert.h"

// Assembly function declaration
extern p_pow(int, int);

int main(void) {  
  assert(4 == p_pow(2, 2));
  assert(9 == p_pow(3, 2));
  assert(25 == p_pow(5, 2));   
  assert(36 == p_pow(6, 2));   
  assert(27 == p_pow(3, 3));      
  assert(1 == p_pow(3, 0));
  assert(1 == p_pow(1, 5));
  assert(4 == p_pow(-2, 2));
  assert(-8 == p_pow(-2, 3));
  printf("All tests passed!\n");
  return EXIT_SUCCESS;
}

And this is the assembly code (pow.asm):

section .data          
  
section .text                

; Make the function name global so it can be 
; seen from the C code
global p_pow              

; Function that computes the power of an integer.
; The base (b) is being passed in RDI register
; and the exponent (e) is being passed in RSI register
; The result is returned in the RAX register
p_pow:
 push rbp
 mov rbp, rsp ; Stack initial state is stored
    
 mov eax, 1   ; Register RAX will hold the result
 cmp esi, 0   ; if (e == 0) -> b^0 = 1, and we're done
 jle pow_end   
  
 mul_loop:
  mul edi     ; eax*ebx = edx:eax (when operating 
              ; with ints, edx is not used).
  dec esi     ; esi = esi - 1
  jg mul_loop ; If esi > 0, it continues iterating
 pow_end:
  
 mov rsp, rbp ; Stack initial state is restored
 pop rbp                      
 ret

To compile the assembly code I used Yasm which is a rewrite of the NASM assembler under the “new” BSD License. If you have it already installed, you just need to open a console and write this:

$ yasm -f elf64 -g dwarf2 pow.asm

Doing this you'll get an object file: pow.o
Actually only yasm -f elf64 pow.asm is needed to get an object file, but I added -g dwarf2 to obtain debug information so I could use gdb to debug the program.
The elf64 object format is the 64-bit version of the Executable and Linkable Object Format. DWARF is a debugging format used on most modern Unix systems.

To compile the C code and link it with pow.o:

$ gcc -g -o pow pow.o pow_c.c

which produces the executable pow, that when executed yields the following output:

$ ./pow
All tests passed!

Beginning with Haskell

I've recently started to become interested in functional languages, so I decided to give Haskell a try.
To begin with, I'm reading this book:

• Learn You a Haskell for Great Good!

So far, I'm amazed with the elegance with which Haskell can be used to solve some problems. For instance, at the end of the "Starting Out" chapter, we can find this example of a problem that combines tuples and list comprehensions:

"Which right triangle that has integers for all sides and all sides equal to or smaller than 10 has a perimeter of 24?"

And this is the solution in Haskell:

ghci> [ (a,b,c) | c <- [1..10], b <- [1..c], a <- [1..b], a^2 + b^2 == c^2, a+b+c == 24]
[(6,8,10)]

Beautiful!

Once I finish this book (this will go slow because of UOC and other projects), I have several other links to continue exploring Haskell:

• Real World Haskell 
• Learn Haskell Fast and Hard 
• The String Calculator Kata in Haskell 
• Bowling in Haskell: A response to Ron Jeffries

Interesting Talk: "Seven Secrets Every Architect Should Know"

I really enjoyed this talk by Frank Buschmann:

• Seven Secrets Every Architect Should Know

Interesting Talk: "(Not Your Father’s) C++"

Interesting talk by Herb Sutter about C++11 in Lang.NEXT 2012:

• (Not Your Father’s) C++ 

Its goal is to answer the following questions:

"What makes ISO C++11 "feel like a new language"? What things that we know about past C++ do we need to unlearn? Why is C++ designed the way it is – historically, and in C++11? Finally, what is the difference between managed and native languages anyway, and when is each applicable?"

Codemotion 2012

Hace unas semanas fui a Madrid para asistir al Codemotion.
CodeMotion es un evento para técnicos, desarrolladores y estudiantes de todas las comunidades y lenguajes que ya lleva 5 años celebrándose en Italia con bastante éxito, y que este año se celebraba por primera vez en España.

Había programadas 56 charlas repartidas en 7 tracks y varios talleres (ver Agenda), y participaron mas de mil personas venidas de toda España.

Asistí a 8 de ellas. En algunas sesiones me fue bastante difícil elegir (quien fuera el Doctor Manhattan). Casi todas las charlas a las que asistí me parecieron muy interesantes, sólo la de justo después de comer se me hizo pesada.

Estas fueron:

• Tuenti release workflow por Diego Muñoz Pérez.
  Viniendo de un grupo de desarrollo pequeñito, me resultó muy interesante ver como trabajan en una empresa grande. La organización y el trabajo de los grupos de operaciones y de sistemas cobrán una importancia capital para mejorar la productividad.
• Despegando con Grails y desplegando en la nube por Mamen González.
  Aprendí sobre la nube en general y sobre diferentes plataformas para Java en particular. La charla se centró sobre todo en Cloudbee, que parece una alternativa muy interesante.
• The H Hour: Hadoop, the awakening of the BigData por Ruben Pertusa.
  Esta fue especialmente interesante. @irrati0nal y yo estuvimos luego discutiendo sobre como podríamos usar Mahout en algún proyecto de bioinformática.
• Single Page Application con Backbone por Julien Castelain y Denis Ciccale.
  Dieron una buena introducción y muchas referencias para seguir aprendiendo. La única pega es que la "promoción" inicial de la empresa, para mi gusto, se extendió mucho.
• Los Lenguajes de la JVM por Arturo Herrero.
  Esta charla presentaba los lenguajes más populares que corren sobre la JVM: Groovy, Scala y Clojure. Fue justo después de comer y se me hizo un poco dura... En los ratos que conseguí estar despierto, me llevé una muy buena impresión de Scala y me picó la curiosidad sobre Clojure.
• Automatización de Unit Testing por Tomás Corral.
  Esta fue una de las charlas que más me gustó. Las explicaciones fueron muy claras y salpicadas de anecdotas y ejemplos prácticos. Descubrí JsTestRunner y Sinon, y una referencia muy buena: Test-Driven JavaScript Development de Christian Johansen
• Agile at Enterprise Scale: Lessons for Successful Agile Software Delivery por Alan Brown.
  Otra charla muy interesante sobre como ser ágiles en empresas muy grandes con grupos distribuidos. También de las que más disfruté.
• TDD y Continuous Integration para aplicaciones Android por Marcin Gryszko.
  Me pareció muy interesante para aplicarla en algún futuro pet project. Descubrí Robotium.

En definitiva fue una experiencia muy buena y espero poder repetir la próxima vez que se celebre.

Articles and Posts read

It's been a while since my last record of articles and posts, so I had to left some out of it. If you want to see the whole list, I'm sharing them on Google+.

Inspiring
Adrian Hands, el impresionante ejemplo de un programador que usaba el Morse para escribir código
It is what you do, not what you own
¿Generosidad para cambiar las cosas?

Interesting
Noan Chomsky: El objetivo de la educación
C. S. Lewis on reading old books
Susan Cain: The power of introverts
Pensar, un trabajo a veces necesariamente introvertido
Why the world needs introverts
No, You're Not an Impostor
Numerous studies have confirmed …

Learning and Software Craftsmanship
Taking a Journey - with Corey Haines (Part I)
Taking a Journey - with Corey Haines (Part II)
Taking a Journey - with Corey Haines (Part III)
Too Much Specialization Is Making Programming a Poorer Experience
Take Control of your Development Career
On Learning
Books Programmers Don't Really Read
Programming - A Life Long Challenge
Tell Above, and Ask Below - Hybridizing OO and Functional Design
Coding: Wait for the abstractions to emerge
Defensive Programming: Being Just-Enough Paranoid
“Being Very Good at Anything Involves Being Somewhat Addicted”: Hard Truth on the Sheer Difficulty of Making an Impact
Pairing is Conversation
4 Reasons Developers Resist Code Review (and Why They Shouldn’t)
Psychology of Tests, Testing and TDD
¿Dejar de programar? Mal!
Not all TDDs are created equal.
Fellow Tribe Members
Code review. Just do it.

Agile and Lean
Compartir la visión de equipo
Occupy Agile
Is Agile Stifling Introverts?

Open Source
Múnich se ha ahorrado 4 millones de euros tras su migración a Linux y OpenOffice
All of Iceland's public administrations moving towards open source

Science
El fascinante caso de dos países que invirtieron en Ciencia
Why It Took So Long to Invent the Wheel
Cómo tirar dinero público buscando bichos en lagos amarillos

Entrepreneurship and Management
Crear una spin-off universitaria. Lo bueno, lo feo y algún consejo
If you don’t have a mobile strategy, you’re probably doomed.
Why I Love Employees Who Ask 'Why'
Don't Wish for Obedient Employees

Spain and Europe
Recorte del 34% en las inversiones en programas de investigación
Recortes en Ciencia + Deudas del fútbol = Vergüenza nacional
Alemania aumentará de manera considerable en 2013 su gasto en educación e investigación
¡Que exporten ellos!
Billete de ida ¿y vuelta?
Lo que significa Grecia
Alarmante Crecimiento de la Pobreza en España.
La sanidad española en tres gráficos

Interesting Talk: "Design sense deep lessons in software design"

This is a great talk I've just seen:

• Design sense deep lessons in software design by Michael Feathers