La situación es la siguiente: Tenemos un repositorio remoto en Bitbucket que es el principal, y después tenemos una bifurcación (fork) para cada desarrollador, los cuales suben sus cambios mediante solicitudes de integración (pull request). El problema surge al intentar sincronizar ramas entre los distintos repositorios y aparecen conflictos en remoto.

Solucionar este tipo de conflictos en local es sencillo mediante por ejemplo NetBeans, por lo que la solución pasa por convertir el conflicto remoto en un conflicto local.

Supongamos que la rama conflictiva es feature/nueva-funcionalidad

1. Configuramos el repositorio principal como repositorio remoto

git remote add upstream https://Usuario@bitbucket.org/Propietario/Repositorio-principal.git
git fetch upstream

2. Nos situamos en nuestra rama local

git checkout feature/nueva-funcionalidad

3. Obtenemos los posibles cambios desde nuestro repositorio remoto bifurcado

git merge origin/feature/nueva-funcionalidad

4. Obtenemos los cambio del repositorio principal

git merge upstream/feature/nueva-funcionalidad

5. Aquí aparecerán los conflictos que nos impedían hacer el merge entre repositorios remotos. Resolvemos los conflictos y los anotamos (commit). Al terminar ya podemos subir los cambios a nuestro repositorio remoto bifurcado.

git push origin feature/car-insurance-alert

El mensaje de error completo es este:

Severity: Warning
Message:  curl_setopt(): CURLOPT_FOLLOWLOCATION cannot be activated when an open_basedir is set
Filename: src/Mandrill.php
Line Number: 68

Este es un problema conocido de la API PHP de Mandrill, y existe un Pull Request con la solución creado en abril de 2014, pero por el motivo que sea, no han añadido la corrección al repositorio principal.

Yo utilizo Composer y Packagist para gestionar las dependencias en mis proyectos, por lo que como solución temporal puedes modificar el fichero Mandrill.php con las correcciones, pero esto significa repetir el mismo proceso en todos los entornos de desarrollo, y es fácil olvidarse de hacerlo cuando han pasado unos meses.

Como solución más robusta, he creado un fork the la librería de Mandrill, y la he subido a Packagist para que pueda ser usada. Es tan sencillo como añadir esto a tus “require” en el composer.json:

"carlos_llongo/mandrill": "dev-master"

O también puedes usar:

composer require "carlos_llongo/mandrill:dev-master"

Tan fácil como mirar el fichero /etc/passwd

Aquí vemos el listado de usuario con la terminal que tienen asignada. Si la terminal no existe, como por ejemplo /bit/false, el usuario será desconectado inmediatamente al hacer login.

Para solucionarlo, editamos el fichero y le damos un terminal válido, como por ejemplo /bin/bash

La solución original en StackOverflow.

AngularJS tiene un módulo para guardar cookies, pero por desgracia no permite establecer la fecha de expiración de la cookie, por lo que la cookie es borrada al final de la sesión.

Hay plugins para AngularJS y para JQuery que permite crear cookies de forma sencilla y establecer la fecha de expiración, pero no quería añadir una libraría más solo para guardar una cookie. Así que esta es la forma de hacerlo usando únicamente JavaScript puro:

var dExpirationDate = new Date();
dExpirationDate.setTime(dExpirationDate.getTime() + (365*24*60*60*1000));
var sExpirationDate = "expires=" + dExpirationDate.toUTCString();
document.cookie = "cookieName=cookieValue; " + sExpirationDate;

Evidentemente esto solo funcionará en páginas estáticas, pero más de una vez me he encontrado con alguna librería de PHP o JQuery que no mostraban ninguna fecha de última actualización en su web. Para esas situaciones, podemos abrir el Firebug y en la consola escribir lo siguiente:

javascript:alert(document.lastModified)

Saltará una alerta con la fecha de la última modificación.

Esta es la situación: Queremos ejecutar un plugin de JQuery sobre un elemento que se crea dinámicamente con un ng-repeat dentro una plantilla de AngularJS. Es decir, no podemos inicializar el plugin hasta que se ha cargado la plantilla y se han creado los elementos.

Tenemos un controlador específico para dicha plantilla, por lo que realizando la comprobación aquí, solucionamos la primera parte del problema. Investigando un poco, veo que la solución más popular es asignar una directiva al ng-repeat, que detectará cuando se ejecute la última iteración y lanzará un evento para ser recogido por el controlador, y entonces ya podríamos ahí ejecutar el plugin.

En Stackoverflow tenemos un ejemplo de esta aproximación, y en Nodewiz.biz tenemos otro ejemplo muy similar.

El caso es que esta aproximación me parece tremendamente rebuscada, aunque no dudo que cumple con el espíritu de AngularJS. Mi aproximación es más sencilla, aunque sospecho que no es del todo correcta, y me gustaría mejorarla con el tiempo:

$scope.bTooltipsterExists = false;

$scope.$watch(
function(){
    if(angular.element('.tooltipster').length){
        $scope.bTooltipsterExists = true;
        return true;
    }

    return false;
},
function(){
    if($scope.bTooltipsterExists){
        $(".tooltipster").tooltipster({
            trigger: 'click',
            delay: 0
        });
    }
});

Básicamente tengo un $watch que lo que hace es observar una función. Esta función busca los elementos que se crearán con el ng-repeat y tendrán la clase .tooltipster. La segunda función es la que se ejecuta cuando hay un cambio en el valor devuelto por la primera función. Es decir, cuando la primera función pase de devolver false a devolver true, se ejecutará el plugin.

Añado una segunda comprobación con la variable $scope.bTooltipsterExists porque la primera vez que se ejecuta el $watch, como no tiene una variable de referencia anterior, siempre se ejecuta la segunda función, y con esto lo evitamos.

Últimamente tenía muy abandonados los videojuegos. Estaban saliendo pocas cosas para Xbox 360 y mi PC no da para jugar, así que hace un par de meses me compre una Playstation 4. Mi objetivo es poder pasarme un juego cada mes e iré comentando por aquí mis impresiones de cada uno.

Empiezo con Destiny, un juego que tenía un expectación brutal y que estaba destinado a echarle horas y horas jugando con amigos. Esto se cumplió al principio, el sistema de juego es excelente, los gráficos son increíbles y jugando con amigos es muy divertido. El problema es que Destiny deja de ofrecer nuevas experiencias muy rápidamente, y entonces se convierte en una tarea muy repetitiva. Sigue siendo entretenido, de esa misma manera en la que te puedes poner a ver la tele y desconectar un rato, pero siendo que mi tiempo de ocio es limitado y tengo que repartirlo entre múltiples aficiones, repetir lo mismo una y otra vez en Destiny me parece una pérdida de tiempo.

Si hay algo que me decidió a dejar el juego, fue el sistema de loot (los ítems que sueltan los enemigos derrotados). Puedes pasar horas y horas sin obtener nada relevante. Todo el sistema parece estar diseñado para obligarte a invertir una cantidad de tiempo descomunal para lograr una mínima mejora en tu personaje. Todo con el fin de hacerte pensar que el juego es más largo de lo que es, intentando ocultar su falta de contenido.

¿Lo recomiendo? NO

En resumen, lo que queremos hacer es un checkout de una o varias ramas del repositorio remoto. Para ello seguimos los siguientes pasos:

1. Crear una carpeta donde tendremos nuestro entorno y entrar en ella.

2. Inicializamos el repositorio:

git init

3. Añadimos la ruta al repositorio remoto:

git remote add origin https://[usuario]@[repositorio]

4. Obtenemos las ramas/tags remotos. En este punto nos pedirá la contraseña del repositorio remoto:

git fetch

5. Hacemos el checkout de la rama con la que queramos trabajar:

git checkout develop

Y listo! A trabajar!