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.

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` .

PHP Frameworks Benchmark

Llevo mucho tiempo desarrollando en PHP usando diferentes frameworks, profesionalmente he usado Kohana, CodeIgniter, Simfony. Incluso hubo un tiempo que mantenia mi propio framework ( alla por el año 2006, cuando los frameworks en PHP aun no eran tan populares ), inclusive he trabajado con Rails y Django ( buscando tambien aprender sus buenas practicas ).

Actualmente estoy trabajando con CodeIgniter 3 ( y quejandome de sus carencias ), sin embargo ultimamente decidi darle una oportunidad a un framework nuevo LARAVEL.

Lo primero que debo decir que es soy un hater Simfony … que Laravel sea un derivado de Simfony es uno de los motivos por lo que no quize probarlo antes.

Tambien debo decir, que mi primer PC fue un 486 con algo de 256 RAM ( sino me equivoco ). Aprendi a programar en esa PC y durante mucho tiempo la velocidad de ejecucion fue mi principal objetivo.

A la hora de escoger un framework considero se debe tener en cuenta lo siguiente:

  • Documentacion ( casi todos los frameworks actuales son muy competentes en este punto )
  • Facilidad de Uso ( aunque CodeIgniter es bastante facil, mis principales quejas son la inexistencia de un ORM propio, y las limitaciones de su sistema de routing )
  • Velocidad de Ejecucion

Al revisar Laravel, mi premisa es que era lento. Es más, al indagar sobre el encontre que tiene un subframework Lumen que es una version minimalista y mas rapida que Laravel. Que un framework tenga una version más ligera de si mismo solo quiere decir 2 cosas: O es lento, o su dev-team son unos obsesos de la velocidad, #likeme. Sin embargo, he de aclarar que el hecho que las versiones Lumen y Laravel sean compatibles entre si es un punto a favor.

Encontre entonces una gran cantidad de benchmarks entre Laravel y CodeIgniter donde mostraban a Codeigniter como un 20% mas rapido que Laravel. Un 20% es una cantidad significativa, pero si es mas facil y rapido escribir codigo en Laravel que en Codeigniter como que no tiene mucho peso.

Sin embargo, esos mismos benchmarks mostraban otro framework que me habia pasado desapercibido: Phalcon. Aproximadamente 5 veces mas rapido que Laravel.

php-benchmark

Revisando la documentacion de Phalcon, maneja un sistema propio de ORM (punto a favor).  Permite la gestión de rutas ( en este punto me parece que Laravel todavia es mas flexible que Phalcon … ). Sus vistas implementan el mismo modelo que CodeIgniter ( el cual aunque es el mismo template de PHP no por eso es menos eficiente ). Su manejo de dependencias utiliza composer, permitiendo asi un facil manejo de las mismas.

Los puntos en contra de Phalcon que he podido observar es que al ser un framework escrito en C necesita acceso a root para instalarse. NO CORRE EN HOSTING COMPARTIDOS. Pero en mi caso ese no es un problema.

Creo que ha llegado el momento de aprender un nuevo skill … Phalcon y comprobar en carne y hueso si sus ventajas son reales o si por el contrario tiene carencias insalvables.

Como anecdota, inicie esta investigación ya que queria aprender Laravel, luego me llamo la atencion Lumen ( Laravel MicroFramework ) y termine en Phalcon. 😀

 

 

Maximizar una ventana a la mitad de la pantalla

En mas de una ocasion en el area de desarrollo debemos tener diversa informacion en la pantalla al mismo tiempo y a veces más de una ( nuestro IDE, la consola para ver los logs, documentacion e inclusive nuestra web app ).

La mejor solución de todas es disponer de varias pantallas al mismo tiempo, sin embargo esto no siempre es posible. Felizmente en ubuntu existe una opcion para con un par de teclas maximizar la ventana actual en tan solo la mitad izquierda o mitad derecha de nuestra pantalla (como se muestra en la siguiente imagen).

half-screen

Para activarla debemos instalar el editor de configuracion avanzada de Ubuntu

sudo apt-get install compizconfig-settings-.manager

Luego lo lanzamos desde nuestro dash

CompizConfig Setting Manager

o desde la linea de comandos

ccsm

Y buscamos en la seccion de Window Management y activamos el modulo Grid

compizconfig-windowmanagement

A partir de ahora, si queremos maximizar una ventana solo en el lado izquierdo de nuestra pantalla debemos presionar Ctrl + Win + LEFT y si queremos maximizarla al lado derecho Ctrl + Win + RIGHT

Disfrutenlo y que tengan un muy provechoso coding

El fin de las notificaciones por SMS

Google acaba de anunciar que su servicio de Google Calendar, dejara de enviar recordatorios por SMS de tus actividades en Google Calendar y empezara a usar notificaciones Push. La verdad es un cambio que Google a demorado DEMASIADO en realizar.

Los recordatorios por SMS eran muy poco amigables con el usuario. En primer lugar no me brindaban toda la informacion completa del evento. Si queria ver algun detalle del mismo debia ir por mis propios clicks a la app de Google Calendar o entrar a la web sino tenia la app. En segundo lugar, no se si solo sucedia en Peru o tambien en otros paises, pero el mensaje de aviso venia en 2 SMS. Es decir me lo hacian incluso mas dificil de leer.

Bueno a partir del 27 de Junio, Google ya no enviara mas esos molestos avisos en SMS y utilizara en su lugar las notificaciones de su aplicacion. Eso quiere decir que si deseas que el celular te avise de tus reuniones, deberas instalar la app de Google Calendar price of tamiflu.

 

Como evitar ataques de China

China con su 20% de poblacion con acceso a internet representa sin embargo casi el 40% de usuarios de internet en el mundo.

36bfda6e1d2ee33f7a83133d034acf04 (1)

 

Tanto asi que no solo en lo economico, sino tambien en lo tecnologico si China estornuda … nosotros nos enteramos. Lamentablemente, dado que una actividad importante que proviene de las redes Chinas son los ataques a servidores es necesario evitar el mas minimo contacto con China. ( La verdad, atender un servicio web de un cliente con visitas desde China seria cuando menos complicado )

Limitar accesos a lo indispensable

Cuando hablamos de servidores  ( ya sea si estan en un datacenter de un tercero o si tu mismo los administras al interno de tu institucion ) debemos evitar que este disponible cualquier servicio que no haya sido explicitamente requerido.

Es mas, todos los puertos no utilizados deben ser activamente bloqueados. Esto porque en tu servidor hay 65K puertos disponibles, si ellos no estan bloqueados, tus atacantes trataran de acceder a ellos una y otra vez aumentando tu trafico de red. Si tienes tu servidor en un datacenter externo, eso significara una mayor factura Read More Here. Y si lo tienes en tu propia insitucion, dada las velocidades de conexion que ofrecen Telefonica y Claro, eso significara que tu servidor no sera accesible por otras personas.

Por ejemplo, si tenemos un servidor web que solo atiende por el puerto 80

iptables -I INPUT -p tcp –dport 80 -j ACCEPT
iptables -I INPUT -p tcp –dport 22 -j ACCEPT

iptables -I INPUT  -j DROP

Hemos incluido el puerto 22, ya que es necesario para seguir configurandolo.

 

Configurar acceso SSH por Keys

Hoy en dia el acceso SSH es la unica forma de realizar mantenimiento y supervision de tus servidores. Existen dos formas de tener acceso por SSH a un servidor:

  • Utilizando un password, lo que implica teclearlo cada vez que necesites realizar una operacion. El password debe ser lo mas complicado posible para que otras personas no accesan sin permiso a tu servidor y lo mas sencillo posible para que no te estes equivocando al momento de ingresarlo.
  • Utilizar una SSH Key, las ssh key son unicas por maquina y nos permiten acceder sin utilizar una clave.

 

Bloquear accesos no autorizados

Si ya tenemos acceso por SSH KEY, nuestro nivel de error al tratar de acceder por SSH se vuelve 0. En este momento cualquier acceso por SSH erroneo ( que se equivoque en la clave ) es un acceso no autorizado y mal intencionado.

Para esto podemos usar el paquete fail2ban. Este paquete lo que hace es detectar cuando alguien ha tratadode realizar un acceso no autorizado al servidor y lo bloquea por un tiempo determinado. En este caso, puede ser desde minutos, horas, semanas o incluso para siempre.

 

Bloquea todo acceso desde China

Seamos sinceros, no todo el mundo le vende a China, entonces para que exponerte a tus botnets ? Para bloquear acceso a todo un pais debes obtener todas las ips asignadas a ese pais. Esta informacion necesita actualizarse de tanto en tanto y ademas es muy probable que no sea 100% exacta.

Ademas, tambien es posible que los chinos esten utilizando servidores externos ( previamente hackeados ) y tengan ips de otros paises.

Desde IPDeny podemos descargarnos la lista de ips asignadas por pais.  En esa lista cada linea representa un numero determinado de ips. Y debemos ejecutar un comando de iptables por cada linea de ese archivo. Para China son 5500 lineas, para hacer mas productivo este proceso simplemente lo programamos en  bash

#!/bin/bash
# Simple iptables IP/subnet block script
# ————————————————————————-
# Copyright (c) 2004 nixCraft project <http://www.cyberciti.biz/fb/>
# This script is licensed under GNU GPL version 2.0 or above
# ————————————————————————-
# This script is part of nixCraft shell script collection (NSSC)
# Visit http://bash.cyberciti.biz/ for more information.
# ———————————————————————-
IPT=/sbin/iptables
SPAMLIST=”spamlist”
SPAMDROPMSG=”SPAM LIST DROP”
BADIPS=$(egrep -v -E “^#|^$” /root/deny.china)

# create a new iptables list
$IPT -N $SPAMLIST

for ipblock in $BADIPS
do
$IPT -A $SPAMLIST -s $ipblock -j LOG –log-prefix “$SPAMDROPMSG”
$IPT -A $SPAMLIST -s $ipblock -j DROP
echo $ipblock
done

$IPT -I INPUT -j $SPAMLIST
$IPT -I OUTPUT -j $SPAMLIST
$IPT -I FORWARD -j $SPAMLIST

Se que no hace falta aclararlo, pero por si las dudas. Nunca bloquees las IPs del pais donde te encuentras. Seras inmediatamente expulsado del servidor y no podras conectarte a repararlo. ?