Damián Culotta

Usando múltiples cuentas en GitHub

Damián — Mon, 07 May 2012 03:30:53 +0000

Con la adopción de GitHub como servicio por parte de muchas empresas, es muy probable que nos toque algún proyecto en el cual no podamos usar nuestra cuenta personal.

Con esto se nos presenta un inconveniente: usar múltiples cuentas al mismo tiempo.

Para resolver este escenario, lo primero será crear un nuevo par de claves, sin perder las que ya estamos usando. Abrimos la consola y ejecutamos:

damian@linux:~$ ssh-keygen -t rsa -C "damian@ejemplo.com.ar"

A continuación veremos lo siguiente:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/damian/.ssh/id_rsa):

Acá es importante cambiar el nombre de la clave para evitar pisar las que ya tengamos en nuestro sistema.

Enter file in which to save the key (/home/damian/.ssh/id_rsa): /home/damian/.ssh/id_rsa_ejemplo

Luego seguimos con la generación como siempre.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/damian/.ssh/id_rsa_ejemplo.
Your public key has been saved in /home/damian/.ssh/id_rsa_ejemplo.pub.
The key fingerprint is:
cd:d0:3f:15:41:21:40:c6:e5:52:fe:53:74:f2:07:71 damian@ejemplo.com.ar
The key's randomart image is:
+--[ RSA 2048]----+
|           .=+O+E|
|         . . o.**|
|        . .   .+=|
|         + . ...+|
|        S o o  ..|
|             .   |
|                 |
|                 |
|                 |
+-----------------+

Hasta acá, ya tenemos nuestro segundo par de claves creado y no hemos perdido nada de lo que ya teníamos.

El siguiente paso es ingresar a nuestra nueva cuenta de GitHub y agregar la nueva clave.

Accedemos a las opciones de nuestra cuenta.

Seleccionamos la opción SSH Keys.

Luego nos queda agregar la clave.

Una vez guardada, ya tendremos nuestra clave asignada a nuestra cuenta.

El problema ahora es cómo indicar en nuestro equipo que en un caso vamos a usar nuestra cuenta personal y, en otro caso la cuenta que tenemos para un proyecto o para una empresa.

Para esto, necesitamos crear el archivo config (si es que no existiera) dentro del directorio .ssh. En este archivo vamos a indicar qué clave usar para un caso y cuál para otro.

Una vez creado, vamos a agregar el siguiente contenido.

#Default GitHub
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa
 
#Ejemplo
Host github-ejemplo
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ejemplo

Veamos ahora qué hemos hecho.

En el primer caso, aquí llamado “Default GitHub”, tenemos las directivas para nuestra cuenta personal. Lo que estamos indicando es que cuando git utilice el host github.com, aplique la clave ssh llamada id_rsa.

Ahora bien, en el segundo caso hemos duplicado el contenido pero con dos pequeños cambios que son los encargados de resolver nuestro problema. Por un lado, cambiamos el nombre del Host, por el otro, indicamos la clave ssh que debe utilizarse. El resto de los valores permanecen igual.

En cuanto a configuración, ya tenemos todos los pasos listos. Los últimos cambios los vamos a ver al momento de comenzar a trabajar con los repositorios.

Si trabajamos con nuestra cuenta personal, haríamos un clone de la siguiente forma:

git clone git@github.com:miusuario/repositorio.git carpeta_local

En cambio, cuando estemos utilizando nuestra segunda cuenta, vamos a cambiar el nombre del host.

git clone git@github-ejemplo:empresa/repositorio.git carpeta_local

El nombre el host en este caso coincide con lo que hemos indicado en el archivo config.

Como detalle final, deberíamos ajustar la configuración de los repositorios para que el usuario que se asocia al commit sea el correcto y no estemos mezclándolos.

Para esto, vamos a setear 3 variables locales del repositorio. Parados dentro del mismo ejecutamos:

git config user.name "Damián Culotta"
git config user.email "damian@ejemplo.com.ar"
git config github.user damian-ejemplo

De esta forma, en lugar de utilizarse los valores globales (que en mi caso sirven para mi cuenta personal), el repositorio usará las configuraciones específicas.

Si necesitáramos, por algún motivo, más cuentas, tendremos que repetir estos pasos.

A lo mejor te interese leer

Magento 1.7.0.0 (poniéndose los pantalones largos)

Damián — Wed, 25 Apr 2012 10:16:04 +0000

Como era de esperar, en el día de ayer, se publicó la versión estable de Magento 1.7.0.0 CE (y la versión estable de Magento 1.12 EE).

En cuanto a las novedades, cambios y mejoras, la lista definitiva quedaría más o menos de la siguiente forma.

Mejora el filtro de precio en el layered navigation.
Se agrega Captcha nativo para los formularios.
Precio por grupos de usuario.
Generación automática de múltiples códigos de cupón para una regla de precios.
Mejoras en el sistema de backups. Se implementan rollbacks.
Validación del código VAT.
Soporte para DHL Europa.
Mejoras en el sistema de índices.
Rediseño del tema mobile usando HTML5.
Posibilidad de definir símbolos de moneda.
Limpieza de archivos viejos de cache a través de cron jobs.
Soporte para memcached.
Actualización de la librería drag&drop de Scriptaculous a la versión 1.9.0.
Mejoras en la librería Curl de Varien.
Primera versión de la API con soporte REST.
Ajustes en el manejo de cookies para cumplir con la normativa de la UE.
Se agregan los métodos de pago Cash on Delivery y Bank Transfer como opciones nativas.
Gestión de los logos de los correos electrónicos desde el backend.
Visualización opcional del campo Region para las direcciones.

La lista completa y detallada pueden verla en el changelog correspondiente.

Dada la cantidad de mejoras y cambios, es este un buen momento para considerar un upgrade.

A lo mejor te interese leer

Mage::log()

Damián — Mon, 23 Apr 2012 03:50:01 +0000

Este pequeño post peca de obvio, aunque sólo busca funcionar como recordatorio.

Para testing, para generar un log propiamente dicho o para depurar código, en Magento podemos utilizar Mage::log() en lugar de la función nativa error_log de Php.

En primer lugar, para que se generen los logs, necesitamos activarlos. Para esto, desde el backend, vamos a System -> Configuration -> Developer.

Una vez activados, como bien indica la pantalla de configuración, vamos a encontrar los logs (una vez que se comiencen a ejecutar las llamadas) en var/log/system.log.

Si bien el método funciona con sus valores por defecto, nosotros podemos usarlo cambiando algunos de sus parámetros, incluso, podemos usarlo sin que los logs estén activados.

Como mencionaba al comienzo, la forma de registrar valores en los logs de Magento es invocando la función Mage::log(), a la cual se le pasa un valor como parámetro.

Cualquier valor que le pasemos será registrado de la siguiente forma.

2012-04-12T21:11:12+00:00 DEBUG (7): Mi valor.

Nosotros podemos indicar el nivel del log pasándolo como segundo valor en la llamada del método. Bien podríamos utilizar los valores numéricos para definir el tipo de mensaje o, en su lugar, llamar a las constantes de la clase Zend_Log, ubicada en /lib/Zend/Log.php.

De esta forma, si lo que quisiera es generar un log informativo, podríamos invocar a Mage::log de la siguiente manera:

Mage::log('Mi mensaje', Zend_Log::INFO);

El tercer parámetro que podemos pasar es el del nombre del archivo en el cual se guardará el log.

Por ejemplo:

Mage::log('Mi mensaje', Zend_Log::INFO, 'depurando-mi-modulo.log');

A partir de esto, nuestro log se guardará en var/log/depurango-mi-modulo.log.

Por último, existe un cuarto parámetro que puede ser útil cuando necesitemos comprobar algo en tiendas en producción. Se llama $forceLog y lo que hace es generar el log incluso si por configuración no está activado.

De esta forma, siguiendo el ejemplo, la llamada quedaría así.

Mage::log('Mi mensaje', Zend_Log::INFO, 'depurando-mi-modulo.log', true);

Con esto, lograríamos generar el log sin importar la configuración de la tienda.

A lo mejor te interese leer

Magento 1.7.0.0-rc1 (alabado seas REST)

Damián — Mon, 23 Apr 2012 03:30:23 +0000

A fines de marzo se hizo pública la versión 1.7.0.0-rc1 de Magento.

Aquí nos encontramos con varios cambios, pero personalmente destaco uno: soporte REST nativo para la API.

Las mejoras comentadas (que se suman a las ya mencionadas) en el post oficial son:

Primera versión de la API REST.
Tema mobile basado en HTML5.

El changelog no es muy extenso, lo cual está bien (no estaríamos ante una RC si así no fuera).

Ahora sólo nos resta esperar un poco ya que, seguramente, se estará haciendo el lanzamiento de la versión estable en las próximas horas.

A lo mejor te interese leer

Magento 1.7.0.0-beta1 (mucho nuevo bajo el sol)

Damián — Mon, 23 Apr 2012 03:15:14 +0000

A comienzos de marzo se publicó la versión 1.7.0.0-beta1 de Magento.

Según el anuncio, los cambios destacados de la versión son:

Mejora el filtro de precio en el layered navigation.
Se agrega Captcha nativo para los formularios.
Precio por grupos de usuario.
Generación automática de múltiples códigos de cupón para una regla de precios.
Mejoras en el sistema de backups.
Validación del código VAT.
Soporte para DHL Europa.
Mejoras en el sistema de índices.
Rediseño del tema mobile.

La lista completa de cambios, como siempre, está disponible en el changelog de la versión. Si la revisan un poco, hay unas cuantas cosas interesantes.

La lista de correcciones es bastante grande, pero en las mejoras se enumeran cosas como:

Posibilidad de definir símbolos de moneda.
Limpieza de archivos viejos de cache a través de cron jobs.
Soporte para memcached.
Actualización de la librería drag&drop de Scriptaculous a la versión 1.9.0.
Mejoras en la librería Curl de Varien.

Algunas capturas de pantalla de las nuevas funcionalidades.

Sin dudas, hacía un buen tiempo que una nueva versión no incluía tantas nuevas funcionalidades.

Seguramente estaremos viendo el anuncio de la versión estable estos días en el Magento Imagine.

A lo mejor te interese leer

Magento 1.6.2.0 (pequeñas correcciones)

Damián — Mon, 23 Apr 2012 03:01:07 +0000

Con bastante demora, pero para mantener la costumbre de las revisiones, vuelvo a retomar el blog después de meses de locura laboral.

El 11 de enero se anunció, de forma bastante tímida, la versión 1.6.2.0 de Magento.

En este caso, se trató en realidad de una versión que vino a corregir algunos temas. No fue una nueva versión en si misma.

La lista de pequeños cambios de la versión fueron:

Mejoras para el proceso de reindexado.
Se aplicaron las configuraciones para PayPal Japón.

Además, hubo una pequeña lista de correcciones, la cual puede verse en el changelog.

A lo mejor te interese leer

Magento 1.7.0.0-alpha1 (y las versiones se encontraron)

Damián — Thu, 05 Jan 2012 09:10:45 +0000

El 30 de diciembre se hizo pública la versión 1.7.0.0-alpha1 de Magento.

Si bien vamos a encontrar nuevas funcionalidades, lo que más se destaca es la cantidad de fixes que se han estado haciendo.

Mejora para el layered navigation.
Se agrega Captcha para algunos formularios.
Auto generación de códigos de cupones (hay que ajustar el archivo adminhtml.xml del módulo SalesRule para que funcione)
Una gran mejora para el módulo Backup.
Se implementó DHL Europa.
XmlConnect actualizado a la versión 22.1.
El theme para iPhone fue rediseñado.

Para mayor detalle, el changelog tiene la lista completa de cambios.

Estas son algunas de las nuevas funcionalidades u opciones que vamos a encontrar.

Versión alpha, motivo por el cual ni tendría que hacer falta avisar que NO debe usarse para una tienda productiva.

A lo mejor te interese leer

Mejorando el SEO de nuestros módulos en Magento

Damián — Mon, 07 Nov 2011 13:30:28 +0000

Hoy vamos a ver dos pequeños trucos para lograr una mejor presentación de nuestros módulos.

El primero está relacionado con el SEO y el segundo con la navegación.

Para no perder la costumbre, vamos a partir de un módulo hecho por el Generador de Módulos. Además, para seguir manteniendo la línea, el módulo ha de llamarse Dc_Test.

Si intentamos acceder al controlador de nuestro módulo en el frontend, vamos a encontrarnos con lo siguiente.

Si vemos el código fuente, vamos a notar que hay 3 tags que no se están usando correctamente: title, description y keywords.

La idea del tip de hoy es aprovechar algunas funcionalidades de Magento para darle a nuestro módulo un poco de SEO haciendo uso de los tags html y del breadcrumb.

Si miramos el controlador que se generó automáticamente, vamos a encontrar el siguiente código.

class Dc_Test_IndexController extends Mage_Core_Controller_Front_Action
{
    public function indexAction()
    {
        $this->loadLayout();
        $this->renderLayout();
    }
}

Lo primero que vamos a agregar serán los valores para los tags html.

Para esto, luego del loadLayout, agregamos el siguiente código.

class Dc_Test_IndexController extends Mage_Core_Controller_Front_Action
{
    public function indexAction()
    {
        $this->loadLayout();
        if ($head = $this->getLayout()->getBlock('head')) {
            $head->setTitle('Mi título');
            $head->setDescription('Contenido del tag Description');
            $head->setKeywords('mis,keywords,para,la,pagina');
        }
        $this->renderLayout();
    }
}

Lo que estamos haciendo aquí es validar si el bloque head existe en el layout. En caso afirmativo asignamos valores para las 3 keys que nos interesan (al menos en el ejemplo).

El segundo paso será agregar el breadcrumb para nuestro módulo. Nuevamente, vamos a tener que agregar algunas líneas en el controlador.

class Dc_Test_IndexController extends Mage_Core_Controller_Front_Action
{
    public function indexAction()
    {
        $this->loadLayout();
        if ($head = $this->getLayout()->getBlock('head')) {
            $head->setTitle('Mi título');
            $head->setDescription('Contenido del tag Description');
            $head->setKeywords('mis,keywords,para,la,pagina');
        }
        if ($breadcrumbs = $this->getLayout()->getBlock('breadcrumbs')) {
            $breadcrumbs->addCrumb('home', array(
                'label' => Mage::helper('test')->__('Inicio'),
                'link'  => Mage::getBaseUrl()
            ))->addCrumb('test', array(
                'label' => Mage::helper('test')->__('Título de la página')
            ));
        }
        $this->renderLayout();
    }
}

Una vez guardados los cambios, actualizamos la página y ya van a verse los cambios.

De más está decir que el ejemplo tiene, justamente, ese fin.

Si nuestro módulo utiliza varias acciones, será más correcto tener un método privado en el controlador que se invoque dentro de cada una de ellas para manipular los distintos valores.

A lo mejor te interese leer

Magento 1.6.1.0 (el primero después de ver Magento 2)

Damián — Mon, 07 Nov 2011 02:59:45 +0000

El 19 de octubre se hizo pública la versión estable de Magento 1.6.1.0 (si, recién hoy la instalo para probar).

Sin muchos cambios con respecto a lo visto en los pre-release, la lista de cambios a destacar es:

XmlConnect actualizado a la versión 22.0.
Cambio en el circuito de reseteo de contraseña.
Se puede utilizar la tecla Shift junto con el click para seleccionar un rango de valores en las grillas del backend.
Más y mejor integración con PayPal.
Se eliminó la integración con TheFind.
Se quitó GoogleOptimizer (ya vimos que en Magento 2 vuelve a formar parte de las funcionalidades nativas).
Mejoras para los cupones de descuento.
Lo módulos que más han sido modificados (ya sea por correcciones o cambios de estilo) siguen siendo: PayPal, Sales y Tax. Por supuesto, XmlConnect ha sido actualizado por completo.
Actualización de la API.

En el changelog van a encontrar los detalles sobre todos los cambios de la versión.

A lo mejor te interese leer

Magento 2 (let’s play)

Damián — Sat, 15 Oct 2011 08:45:21 +0000

Magento 2 comenzaría a ver la luz en el tercer cuarto del 2012 y, tentativamente, ser estable en el último cuarto del mismo año.

Para los que hacía ya un buen tiempo no nos alegrábamos con una nueva release, ya es posible comenzar a jugar con la versión 2.0.0.0-dev1.

Si bien estéticamente no veremos cambios, lo que si ya vamos a poder ver es la nueva estructura de código (tal como se comentara en la Innovate 2011).

Definitivamente, mucho para empezar a jugar, probar y romper.

Algunas capturas para llenar los ojos.

Para empezar, la estructura de archivos, claramente, cambia.

Así se comienza a perfilar la nueva estructura para los skins.

Sólo por tomarlo de ejemplo, el módulo Mage_Catalog se ha convertido en:

Con el cambio de la estructura de los skins, la configuración sufre una pequeña modificación también.

Y vuelve al ruedo Google Website Optimizer.

Ahora toca tomarse un tiempo para comenzar a jugar, modificar, armar módulos custom y ver cuánto de lo que ya sabíamos sigue siendo útil y qué nuevos cosas vamos a encontrar.

Para los que tengan ganas de ponerse a jugar: http://mage2.magentocommerce.com/svn/public/