PHP – Patrón de diseño Singleton

Algunos recursos de aplicaciones son exclusivos, por ejemplo, la conexión a una base de datos a través del manejador de la base de datos es exclusivo.

Se comparte el manejador de la base de datos porque puede darse un “overhead” al estar abriendo y cerrando conexiones, en particular durante la petición a una sola página.

Un Objeto es un Singleton si la aplicación puede incluir uno y sólo uno de esos objetos a la vez.

PHP – Patrón de diseño Factory

En vez de usar new para crear Objetos, se usa una Clase Factory. Entonces, si se necesita el tipo de los Objetos creados, sólo se cambia la Clase Factory. Por lo tanto, todo el código que use la Clase Factory cambiará de manera automática.

En sistemas complejos, la mayoría del código confía en pocas Clases clave. Las dificultades surgen cuando se necesita cambiar esas Clases. Por ejemplo, si hay una Clase User que lee desde un archivo y se necesita cambiar el código para que más bien lea desde una Base de Datos. En este caso es cuando el patrón de diseño Factory se vuelve útil.

Esta variación usa Métodos Factory (static) en lugar de Clases Factory.

DRY: Encapsula el proceso de crear Objetos User en un sólo lugar, de ésta manera trozos de código complejo para inicializar Objetos no van a ser copiados y pegados una y otra vez por todo lado.

Configurar ambiente con GitHub

Generación de claves RSA

El primer paso consiste en crear el conjunto de claves RSA para usar en la autenticación con GitHub. A continuación vamos a crear nuestra propias claves SSH, una pública y otra privada:

mkdir ~/.ssh
chmod 700 ~/.ssh

ssh-keygen -t rsa -b 2048 -C "MY_EMAIL"

Entonces agregamos nuestra nueva clave al ssh-agent:

ssh-add ~/.ssh/id_rsa

Para más información sobre como agregar nuestra propia llave pública a GitHub, por favor consulte:

sudo apt-get install ssh-copy-id

man ssh-copy-id

De manera alternativa, se pueden pegar las llaves usando SSH, por ejemplo:

cat ~/.ssh/id_rsa.pub | ssh MY_USER@REMOTE_HOST "cat >> ~/.ssh/authorized_keys"

Configuración básica

git config --global user.name "MY_USERNAME"

git config --global user.email "MY_EMAIL"

git config --global push.default upstream
git config --global push.default tracking  (deprecated)

git config --global branch.autosetuprebase always

Rastreo automático de ramas

Por ejemplo, empujar la rama llamada “hotfix/issueShortName_issueID_username” en el “origin” remoto:

git push REPOSITORIO_REMOTO RAMA_REMOTA

git push -u origin hotfix/issueShortName_issueID_username

Para más información: Git Workflows.

Tracking” significa: una relación entre una rama local y una rama remota. Cuando se trabaja en una rama local que rastrea otra rama, se puede correr “git pull” y “git push” sin argumentos adicionales y git sabrá qué hacer.

Sin embargo, hay que recordar que por defecto “git push” empuja todas las ramas que tienen el mismo nombre remoto. Para limitar este comportamiento sólo a la rama actual, se debe configurar la siguiente opción:

git config --global push.default tracking

Lo anterior sirve para evitar “push” accidentales a ramas a las que no se está listo para empujar aún.

¿Qué es “origin”?

Es un alias dado a la URL que apunta al repositorio remoto.

Digamos que deseamos configurar una rama remota llamada origin/master para ser la rama de rastreo de nuestra rama local llamada master:

git branch --set-upstream  master origin/master

Si mi “repositorioLocal” declara a “repositorioRemotoRepo”, entonces estamos:

  • Pulling – Jalando del “upstream” llamado “repositorioRemoto”. Esto quiere decir que “repositorioRemoto” es “upstream” para mi “repositorioLocal” y mi “repositorioLocal” es “downstream” para “repositorioRemoto”.
  • Pushing – Empujando hacia el “upstream” llamado “repositorioRemoto”.

“origin” es el nombre del repositorio remoto donde deseamos publicar nuestros “commits”. Por convención, el repositorio remoto predeterminado se llama “origin”, pero se puede trabajar con diferentes repositorios remotos al gusto (con diferentes nombres) al mismo tiempo. Para más información, por favor consulte: gitref.org

Los Repositorios Remotos de manera general se almacenan un equipo aparte o en un servidor centralizado. Sin embargo, también pueden apuntar a un repositorio en la misma máquina. No hay nada de especial en el nombre de “origin”, pero existe una convención para utilizarlo como el repositorio centralizado primario (si los hay):

git remote

origin

Desplegar información sobre el repositorio remoto llamado “origin”:

git remote show origin

Rastrear una rama remota de otra persona

git checkout -t origin/feature/issueShortname_issueID_username

El comando anterior, crea y se pasa a la rama “feature/issueShortname_issueID_username” la cual rastrea a la rama remota “origin/feature/issueShortname_issueID_username”.

Una vez que un compañero del equipo nos comparte la rama en la cual estaba trabajando, necesitamos crear una rama local que nos permita hacer cambios sobre la rama del compañero. Por lo tanto, con este tipo de seguimiento establecido es que podemos hacer cambios y luego correr “git push” empujarlos remotamente.

Al empujar use “rebase” no “merge”

git pull --rebase

Si estamos en la rama “master” entonces realiza un “git fetch origin”.

Una historia de tiempo lineal

Debido a que la fusiones de ramas son grabadas con un “merge commit“, se supone que deben ser significativas, por ejemplo, para indicar cuando un “feature” haya sido fusionado a un “branch release“. Sin embargo, durante el flujo de un día de trabajo diario regular, donde varios miembros del equipo de continuamente sincronizan desde una sola rama, la línea de tiempo se contamina con micro-fusiones innecesarias al realizar “git pull“. Por otro lado, “rebase” asegura que los “commits” son siempre re-aplicados para mantener una historia de tiempo lineal.

Es posible configurar ciertas ramas para que siempre hagan lo anterior sin necesidad de usar la opción –rebase. Hacer que “git pull” en “master” siempre use “rebase“.

git config branch.master.rebase true

Rebase automático para todas las ramas rastreadas

Es posible configurar esta opción de manera global, para cada nueva rama rastreada:

git config --global branch.autosetuprebase always