Peticiones HTTP asíncronas con AngularJS

Esta es una forma de hacer peticiones Get asíncronas con AngularJS:

angular.module('TestApp').
controller('MainCtrl', ['Async', function (Async) {     
  Async.get(<URL>).then(
      function(data) {
          console.log("OK:",data);
      }, function(error) {
          console.log("ERROR:", error);
      });
}]).
// Servicio que encapsula operaciones asíncronas
factory('Async', ['$http', function($http) {     
  return {
      get: function(url) {
        var promise = $http.get(url).then(function (response) {
          // Devuelvo el body
          return response.data;
        });
           
        return promise;
      }
  };
}]);

He creado un servicio llamado Async con una función "get" que devuelve un objeto "promise". Este objeto promise es consumido de forma habitual por el llamante, en este caso un controlador llamado "MainCtrl"

Si la respuesta es correcta, se devuelve al controlador el body del mensaje http. En el caso particular que el body sea una cadena JSON, Angular la convierte automáticamente a un objeto.

Si la llamada acaba en error, se devuelve al controlador el objeto de error con el status y el mensaje de error, entre otra información.

Javascript prototypal inheritance with Object.create

An advantage that can turns out in disadvantage is that Javascript is a very expressive language. You can do something in very different ways. In this case I'll show a way to model inheritance using Object.create (ECMAScript 5).

In the following example, two objects are created: parent and child. These both objects are like "classes" in lenguajes with classical inheritance as Java. From those objects, I create two instances using Object.create: Pepe (the parent) and Pablo (the child). In this case, Pablo prototypically inherits from Pepe.


// In case of using IE 
if (typeof console === 'undefined') {
  console = {
  log: function(text) {
  alert(text);
  }
  }
}
    
// In case of using IE<10
if(typeof Object.create !== 'function') { 
  Object.create = function (o) { 
    function F() {}; 
    F.prototype = o; 
    return new F(); 
  }; 
}
    
// Helper to add properties to an object
function extend(obj, props) { 
  for(prop in props) { 
    if(props.hasOwnProperty(prop)) { 
      obj[prop] = props[prop]; 
    } 
  } 
}
    
    // Parent object
var parent = {
talk: function() {
console.log("I'm "+this.name);
},
work: function() {
console.log("I'm going to work");
},
init: function(name) {
this.name=name;
return this;
},
create: function(name) {
return Object.create(this).init(name);
}
};

// Child object
var child = Object.create(parent)
extend(child, {
work : function() {
    console.log("I can't work, I'm a child!");
}
});

// Parent instance
var pepe = parent.create("Pepe");

// Child instance
var pablo = child.create("Pablo");

pepe.talk(); // I'm Pepe
pepe.work(); // I'm going to work

pablo.talk(); // I'm Pablo
pablo.work(); // I can't work, I'm a child!

I2Talentia - Ya estamos en fase de pruebas

Ya por fin tenemos una versión beta de la plataforma I2Talentia, nuestra innovadora plataforma de aprendizaje adaptativo.

Si quieres ser  betatester solicita tu código en info@i2talentia.com

Próximamente la abriremos para el público.

¡Esperamos que os sea de utilidad!

Cómo una maleta fea hace vender más

Hace unos meses fui a comprar una maleta a un centro comercial. Me mostraron un nuevo modelo de una marca que todo el mundo conoce. Este modelo estaba disponible en dos colores y curiosamente a dos precios distintos. Por un lado estaba el modelo negro digamos a 100€ y el modelo azul  a 60€. Realmente la maleta en color negro era bastante bonita al contrario que la azul que, aún siendo el mismo modelo, resultaba algo fea.

Me resultó curioso la diferencia de precio porque se trataba de un modelo nuevo. Es normal que para liquidar restos de productos se bajen los precios, pero en este caso no me cuadraba.

¿Por qué ponen la misma maleta con colores distintos pero con los mismos costes de producción, a precios distintos?

No tengo certeza del motivo aunque puedo intuir un motivo. Podemos hacer un pequeño ejercicio (muy simplista):

Supongamos que existen dos tipos de personas, un tipo con presupuesto holgado (PH) y otra con presupuesto limitado (PL). ¿Cuál sería la facturación jugando con los distintos precios de las maletas?

Negra 100€, Azul 100€
En este caso, la persona con presupuesto holgado compraría la negra. Sin embargo, la persona con presupuesto limitado seguramente comprara una maleta de otra marca más económica.

Facturación = 1N*100€ + 0A*100€ = 100€

Negra 60€, Azul 60€
En este caso, ambas personas comprarían la negra que claramente es más bonita.

Facturación = 1N*60€ + 1A*60€ = 120€

Negra 100€, Azul 60€
En este caso, que es el real, la persona con presupuesto holgado compraría la negra. Sin embargo, la persona con presupuesto limitado posiblemente comprara la azul ya que preferiría sacrificar el aspecto visual a favor de la calidad y prestigio de la marca.

Facturación = 1N*100€ + 1A*60€ = 160€

Vemos como en este último caso se maximizan los beneficios.

La moraleja de todo esto es que a veces interesa complementar un modelo "bonito" con un modelo más "feo" pero más barato para que personas con menos presupuesto compren y, además, asegurar que las personas que pueden gastar más sigan comprando el modelo más caro.

¿No os ha pasado nunca ir a comprar una camiseta y resulta que la que más os gusta, que encima está a buen precio, le han puesto un estampado, dibujo, o algo por el estilo que la hace más fea? y, os preguntáis "¿Para qué le habrán puesto esto? Si no se lo hubieran puesto estaría más bonita".

Bueno, pues posiblemente para que si tenéis presupuesto holgado os compréis la otra camiseta que está al lado que no tiene ningún estampado pero es más cara.

Simplifying graphs with Neo4j and Cypher

Something important in a knowledge map is that is has to be as simple as possible.
For example, let's say the node A depends on node B and node B depends on Node C:

A->B->C

This tree is identical, in the context of a knowledge map, to this more complex one:

A->B-C
|->C

In this case, the brach from A to C is reduntant as this relation is contained in the branch A->B->C.

A way to simplify this second tree is using Neo4j and Cypher.

We can create the tree this way:

create (nodeA{name:'nodeA'}), (nodeB{name:'nodeB'}), (nodeC{name:'nodeC'}), (nodeA)-[:DEPENDS]->(nodeB), (nodeB)-[:DEPENDS]->(nodeC), (nodeA)-[:DEPENDS]->(nodeC)

To simplify it just execute this Cypher query:

match a-[r:DEPENDS]->c
where a-[:DEPENDS*2..]->c
delete r

Here we are deleting all the DEPENDS relations that connect two nodes where there is another longer path connecting them.

In this case, the relation to delete is A-C as there is another longer path: A->B->C
Try it yourself: console.neo4j.org

Hipótesis nula, significación estadística, valor p, et al.

Voy a comentar cómo entiendo yo (se aceptan correcciones) todos estos términos, más que nada para acordarme en un futuro ya que no son conceptos con los que trabaje todos los días.

Digamos que quiero probar si un nuevo medicamento sirve para tratar la alergia.

Hipótesis nula (H0): El medicamento no sirve para tratar la alergia

Hipótesis alternativa (H1): El medicamento sirve para tratar la alergia

Tal como se observa, la hipótesis nula es la negación de la hipótesis que realmente queremos validar, asumiendo que no hay relación entre el uso del medicamento y la mejora de alergia. Es decir, que no hay relación entre dos fenómenos observados.

Para validar la efectividad del medicamento se trata de validar H1 rechazando H0.

Si nos fijamos ambas son mútuamente exclusivas, si se cumple H0 se rechaza automáticamente H1 y viceversa.

Por ejemplo, hay 1000 pacientes, a 500 que forman el grupo 1 (G1) le suministro el medicamento y a los otros 500 que forman el grupo 2 (G2) le suministro placebo.

Calculo un parámetro en ambos grupos que represente la mejoría, por ejemplo la reducción media de crisis alérgicas (u). En este caso tendremos u1 y u2.

Por lo tanto, las hipótesis se pueden formular de la siguiente manera:

H0: u1<=u2  (La mejoría en ambos grupos en similar o incluso el grupo tratado con el medicamento G1 empeora)

H1: u1>u2 (El grupo tratado con el medicamento G1 mejora)

Imaginemos que:

u1 = 0.2 (el grupo 1 ha experimientado de media un descenso del 20% en el número de crisis alérgicas)

¿Esto qué significa? ¿Podemos anunciar el éxito del medicamento? Para resolver esto entra en juego la significación estadística, es decir, vemos que que existe mejoría pero ¿es realmente debida al medicamento? o por el contrario ¿se debe al azar?

Para dar por válida nuestra hipótesis H1 (el medicamenteo es efectivo) se trataría de rechazar H0 (no hay mejoría por el uso del medicamento). Para ello, en primer lugar calculamos el valor p (p-value) que es la probabilidad de obtener un resultado al menos tan extremo como el que se ha obtenido suponiendo que la hipótesis nula es cierta. 

En este caso se trataría de calcular el valor p que podría plantearse como: ¿Cuál es la probabilidad de que cogiendo a 500 personas al azar y administrándole placebo se observe una mejoría del 20% o mayor? Decir que se administre placebo es suponer que la hipótesis nula es cierta, no existe relación entre la toma del medicamento y las mejorías observadas. A continuación, por convención se dice que si el valor p es menor de 0.05 (umbral representado por la letra alfa), se rechaza la hipótesis nula H0 afirmándose que la hipótesis de partida H1 es cierta.

Para calcular en este caso el valor p, obviamente se necesitan datos que desconozco, pero imaginemos los siguientes valores p:

p=0.01

En este caso estamos diciendo que seleccionando a 500 personas al azar a las que le administramos placebo, la probabilidad de que se observe una reducción mayor de un 20% en el número de crisis alérgicas es del 1%. Como 0.01<0.05, rechazamos la hipótesis nula que vendría a decir que el 20% de mejoría observado al administrar el medicamento es altamente improbable que se deba al azar y por lo tanto se debe al medicamento.

p = 0.9

En este caso, existe una probabilidad del 90% que seleccionando 500 personas al azar y administrándoles placebo consigan reducir el número de crisis alérgicas al menos un 20%. Es un ejemplo "irreal" que representa un caso extremo. En este caso no se puede rechazar la hipótesis nula ya que 0.9 no es menor de 0.05. Sin embargo tampoco se puede aceptar. Lo que estaríamos diciendo es que es bastante probable observar descensos del 20% en el número de crisis alérgicas en grupos de personas seleccionadas al azar tras administrar placebo. Por lo tanto, que suministremos un nuevo medicamento y observe un 20% de mejora no es significativo (parece deberse al azar, es decir, con placebo también se observaría).

Adapted Bayesian Knowledge Tracing (Brute Force) BKT-BF

I adapted the original Bayesian Knowledge Tracing (Brute Force) BKT-BF code (www.columbia.edu/~rsb2162/BKT-BruteForce.zip) to allow data in chronological order but not necessary sorted on Skill and Student (can be mixed). Moreover, the dataset can have free number of columns in any order and any separator (coma, tab, etc.)

I didn't tested it thoroughly but at least it works for my needs.

Parameters (1 is the first one): 

  skillPos = Skill column position 

  studentPos = Student column position

  rightPos = Right column position

  separator = Separator (comma(,) , tab(tab), etc.)

$> java ComputeKTparamsAll ./data.txt 4 3 6 tab

In  this example, it gets the model from the data.txt dataset where the skill column is the 4th, student column is the 3rd, right column is the 6th and the columns are separated by tab.

ComputeKTparamsAll.java

ComputeKTparamsAll.class