Como conectar tu wordpress con Mailchimp

MailChimp es una plataforma de email Marketing ( la mejor que conozco de momento ). A traves de ella puedes diseñar campañas recordatorio a tus clientes, usuarios o visitantes. Puedes enviarles ofertas, segmentandolos por intereses, por producto, etc.

Hoy vamos a usar un plugin de wordpress para registrar en mail chimp, las personas que realizan un comentario en nuestro blog.

Vamos a la seccion de plugins de nuestro wordpress y decimos agregar nuevo. Buscamos mailchimp y lo instalamos y activamos.

Una vez activado, vamos a la seccion de configuracion donde nos pide ingresar nuestro APIKEY de Mailchimp

Para buscar nuestra APIKEY, vamos a MailChimp a la seccion de Account API https://admin.mailchimp.com/account/api/  y creamos nuestra APIKEY

Y la copiamos en la configuracion de mailchimp de nuestro wordpress. Luego nos vamos a la opcion de Integracion de MailChimp en nuestro wordpress

Ahi podremos ver todas las opciones de configuracion que vienen por defecto. En este caso configuraremos el registro en los comentarios.

Aca, activamos el plugin ( Enabled yes ).

Decidimos si registramos en mailchimp a todos los que comentan o si lo hacemos solo si desean ser agregados. En nuestro caso, a todos. ( Implicit yes )

Nos indica en que lista de MailChimp los vamos a guardar, es conveniente seleccionar una lista ya que nos permite diferenciar los contenidos que reciben los usuarios en funcion de sus intereses.

Luego nos pregunta, si el usuario debe ingresar su email 2 veces para confirmar que es correcto. ( Double opt-in )

A partir de ahora cuando alguien realice un comentario en tu blog, Mailchimp le enviara un correo de invitacion a la lista de correo que le acabas de agregar. Si acepta, estara ligado automaticamente a tu lista de MailChimp.

Happy Mailing.

 

 

 

GIT y GIT Flow

Al trabajar con cualquier tipo de proyecto de software tenemos que resolver problemas como el guardar un backup de tu codigo, asi evitamos que una falla en disco eche a perder nuestro trabajo. Pero que sucede si en el proyecto de software que estamos trabajando llegamos a un callejon sin salida y tenemos que probar una solucion nueva ? Entonces, tendriamos que guardar muchos backups para poder volver a una version anterior. Y que sucede si creamos una copia del proyecto para una funcionalidad experimental como hacemos para integrar esas funcionalidades con la version de produccion ( sobre todo si ha seguido trabajando en paralelo en la version de produccion ). Como gestionamos que varias personas trabajen cada uno sobre una funcionalidad diferente y al final de cada una juntarlas para que funcionen adecuadamente ? Y si al momento de trabajar sobre una caracteristica nueva descubrimos algun problema en la version de produccion ? como volvemos a esa version antigua ? Y si usamos un codigo de backup como integramos esos cambios para no perderlos en la nueva funcionalidad ? Debemos volver a escribirlos ?

Para solucionar todos esos problemas ( y algunos mas ) existe GIT. Git es un sistema de control de versiones de codigo. Que nos permite volver a cualquier version del sistema.

Sin embargo, GIT es muy flexible permitiendonos trabajar en la forma que querramos. Tanta flexibilidad no es muy buena para proyectos y equipos grandes o desarrolladores novatos. Incluso para desarrolladores senior, el desorden puede causar problemas en el proyecto.

GIT FLOW es un flujo de trabajo ( recomendaciones a seguir ) para proyectos en GIT que nos permite usar herramientas simples para automatizar y organizar el trabajo usando GIT.

GIT FLOW nos indica que en todo proyecto debe existir una rama master que sera la encargada de contener el codigo de produccion y una rama develop que mantendra el codigo de desarrollo. Asi como algunas ramas auxiliares: feature, para las nuevas caracteristicas o funcionalidades del sistema, release, para preparar los cambios antes de pasarlos a produccion, y hotfix, para corregir rapidamente los bugs que se pudieran encontran en produccion.

Al iniciar un proyecto con GIT FLOW debemos iniciar la configuracion con el comando

git flow init -d

Este comando no realizara ningun cambio en tu codigo o ramas de GIT. Solo servira para configurar incialmente el proyecto.

Al ejecutar el comando, se crearan ( sino existen previamente ) las ramas master y develop. Las cuales seran usadas para contener el codigo del proyecto en produccion y el codigo del proyecto en desarrollo respectivamente.

Luego, cualquier nueva funcionalidad ( historia de usuario, caso de uso, tarea ) que queramos implementar crearemos una rama con el comando

git flow feature start <nombre de la historia>

En ese momento GIT FLOW, creara una copia del codigo de la rama develop y lo pondra en una rama feature/<nombre de la historia> donde se podra realizar los cambios necesarios. Si al final la caracteristica es desechada ( ya sea porque el codigo no funciono como se esperaba, o se prefiero no desarrollar al final esa historia ) podra eliminarse simplemente borrando la rama sin comprometer el resto del codigo

git branch -d <nombre de la historia>

Una vez termina la historia, para integrarla al resto del codigo simplemente debemos cerrar el feature.

git flow feature finish <nombre de la historia>

Al ejecutar este codigo, GIT FLOW hara un merge de la rama feature con el codigo que esta en develop y luego procedera a borrar la rama feature. En este punto si empiezas a trabajar con otra historia, al crear el feature usara el nuevo codigo en develop.

Al final del sprint cuando ya necesitar pasar todo el codigo funcionando a produccion, deberemos crear una rama release. Donde nos aseguraremos que todo este funcionando correctamente y podremos hacer los ultimos ajustes

git flow release start <version codigo>

Aca podremos hacer cambios, guardarlos en git con nuevos commits y cuando ya este todo listo indicarle a GIT FLOW que debe pasarlo ahora si a produccion.

git flow release finish <version codigo>

En este punto GIT FLOW, integra los cambios de la rama release a develop ( para que los nuevos desarrollos tengan esos ajustes ) y a master ( para hacer el pase a produccion ) y luego borra la rama release

Si en cualquier momento se detecta un bug en produccion ( puedes estar trabajando en otro feature o inclusive estar haciendo los ajustes para un release ) puedes crear una rama hotfix para hacer cambios sobre el codigo que esta actualmente en produccion.

git flow hotfix start <version codigo – numero correccion>

Una vez terminados los cambios se cierra la rama hotfix

git flow hotfix finish  <version codigo – numero correccion>

Ahi los cambios hechos en el hotfix, se copian a master para actualizar produccion y a develop para tenerlos disponibles para el desarrollo posterior.

PD: GIT FLOW es una herramienta agnostica, lo puedes usar tanto en github, en gitlab, o en tus propios repositorios de GIT.

PD2: si usas tus propios repositorios de GIT y aun no has visto el tema de permisos y seguridad, te recomiendo gitolite.

Modificar Fecha de Edicion de archivos RAR extraidos

Yo suelo ordenar mis archivos por fecha de modificacion. Ultimos primeros. Asi me es mucho mas facil encontrar las cosas que acabo de descargar o los documentos sobre los que he estado trabajando. Esto ultimo es particularmente importante para mi ya que mi carpeta de Downloads suele tener entre 500 y 1000 archivos.

Sin embargo, con los archivos comprimidos es otra historia. Aunque la descarga se orden segun mis requerimientos cuando los descomprimo, literalmente pierdo el contenido entre todos mis archivos. Me suele suceder mucho mas con el anime, pero igual fastidia.

Esto principalmente se debe a que los archivos contenidos en el RAR ya vienen con una fecha de creacion, y edicion previos a que fueran comprimidos, y al descomprimirlos mantienen esa informacion.

Para actualizar esa info al momento de descomprimirlos existe el siguiente comando

unrar e -ts-  “SNT09.rar”

El parametro -ts- actualiza todas las fechas de los archivos contenidos en el RAR por la fecha actual. Permitiendome ubicar facilmente el contenido dentro mi carpeta de Descargas.

Script Backup MYSQL Databases

En todo servidor propio es necesario preocuparse por disponer de los backups necesarios para restaurar los sistemas.

Esto incluye:

  • Codigo fuente ( GIT, github, gitlab )
  • Archivos producidos por los usuarios ( AWS S3 )
  • Base de datos

Mantener seguras, optimizadas y perfectamente backupeadas ( existe esa palabra ? ) las base de datos no es una tarea facil ni despreciable, sino preguntenle a @gitlab.

Existe varias formas de pago para realizarlo todas super optimas, pero de pago “extra”

  • Microsoft Azure, empezando desde 80USD mensuales
  • AWS RDS, empezando desde 10.5USD mensuales
  • Google Cloud SQL, empezando desde 8USD mensuales

Todas estas opciones nos permiten tener varias bases de datos y nos aseguran disponibilidad, seguridad y actualizaciones.

Si por el contrario nuestra configuración no va por disponer de un servidor de base de datos separado pues bien necesitaremos ocuparnos nosotros mismos de las operaciones de rutina del servidor, sobre todo de los backups.

El siguiente script es un procedimiento de backup automatizado que suelo utilizar

databases=`mysql -e 'show databases;' | tr -d "| " | grep -v Database | grep -v information_schema | grep -v performance_schema`

fecha=` date +%Y%m%d`
mkdir -p /backup/$fecha

fechaold=`date -d "7 day ago" +%Y%m%d`

rm /backup/$fechaold -R

for db in $databases; do
 
 if [ -f /backup/$db.clear ]; then
 mysql $db < /backup/$db.clear
 fi
 mysqldump $db > /backup/$fecha/$db.sql
 tar -czf /backup/$fecha/$db.tar.gz backup/$fecha/$db.sql
 rm /backup/$fecha/$db.sql
done

Ahora debemos configurar el script para que se ejecute todos los dias a una hora especifica

crontab -e

0 5 * * * bash backup.sh

Aunque el script ubique los backups en el directorio de mayor seguridad de nuestro servidor ( root ), es recomendable ubicar una copia en otro lugar para evitar cualquier contingencia. Este otro lugar, podria ser otro servidor encargado de gestionar los backups de varios servidores o incluso una maquina personal local.

Para configurarlo deberemos habilitar el acceso por ssh de la maquina que guardara los backups

0 6 * * * scp -r backup@servidor.com:/backup/`date +%Y%m%d` .

NodeJS mySQL NOT SUPPORTED AUTH MODE

Recientemente al actualizar mi maquina de desarrollo me tope con el siguiente error desde NodeJS

Error: ER_NOT_SUPPORTED_AUTH_MODE: Client does not support authentication protocol requested by server; consider upgrading MySQL client

Era evidente un problema de configuracion ya que dias atras la app funcionaba correctamente y no habia sido modificada.

Para solucionar este problema debes entrar en la consola de mysql:

sudo mysql -u root

Y ejecutar el siguiente comando

update mysql.user set authentication_string=password(''), plugin='mysql_native_password' where user='root';

Y luego proceder a reiniciar el servicio

sudo service mysql restart

Image

Adios PHP5

Oficialmente a finales del 2016 se termina el soporte para PHP5 tamiflu generic. Eso quiere decir que ya no habran correcciones ni mejoras pasada esa fecha. Luego de eso habra un soporte exclusivo para fallas CRITICAS que se extendera hasta el 2018.

Lo bueno es que todos los frameworks soportan perfectamente PHP7, asi que llego la hora del adios ya no hay nada mas que hablar ?

Para mayores detalles PHP.net