Archive for Desarrollo web

septiembre 20th 2017

Medir rendimiento de sitio web

Número de lecturas: 262
{lang: 'es-419'}

A veces existe lentitud o complicaciones en los sitios web, para poder encontrar que puede ser lo que causa el problema o para tener una referencia de la velocidad se puede utilizar este sitio web:

https://tools.pingdom.com

 

septiembre 13th 2017

Automatiza tu manera de usar git con git-flow

Número de lecturas: 360
{lang: 'es-419'}

Git es probablemente el sistema de control de versiones más popular hoy en día debido a su gran flexibilidad a la hora de trabajar con diferentes ramas de nuestros proyectos, entre otras muchas otras cosas. Esta flexibilidad a la hora de crear diferentes ramas nos permite poder usar el flujo de trabajo que queramos a la hora de funcionar con git diariamente, lo que por otro lado también puede ser un arma de doble filo ya que si no tienes experiencia usándolo o ejecutamos algún comando en el orden que no es o con algún parámetro no deseado, podemos llevarnos algún susto.

Flujo de trabajo acertado

Vincent Driessen diseñó un modelo de ramas exitoso para sus proyectos, el cual decidió compartir con todo el mundo. No voy a entrar en el detalle de este modelo, pero en resumidas cuentas se basa en los siguientes puntos:

  • Tenemos dos ramas principales, master y develop, y varias de soporte para estas que podrán ser ramas de feature, release y hotfix.
  • La rama master es la que contiene la última versión de nuestro proyecto y usaremos para desplegar en producción.
  • La rama develop es la que contiene el último estado del desarrollo del mismo, es decir, hasta el último commit que hayamos hecho.
  • Las ramas de feature se usarán para desarrollar nuevas funcionalidades, se crearán a partir de la rama develop y al terminar con esta funcionalidad nueva, se tiene que fusionar otra vez con develop.
  • Las ramas release se usarán para lanzar una nueva versión de nuestro proyecto. Se usarán solo para los últimos retoques antes de liberar la nueva versión, como cambiar el número de esta, y crearán a partir de la rama develop y se fusionaran tanto con master (para poder ser desplegadas en producción) como con develop.
  • Las ramas “hotfix” se usarán para esos cambios rápidos que queremos realizar como arreglar un bug sencillo en producción mientras que al mismo tiempo estamos desarrollando una nueva funcionalidad y queremos desplegar este arreglo lo antes posible. Se crean a partir de la rama master y se fusionan con master y develop.

Con un poco que lo pensemos, tiene mucho sentido esta manera de trabajar, pero a la hora de la práctica puede parecer un poco complicado el saber que comandos o que flujo seguir para que todo funcione correctamente. Pero no os preocupéis porque Vincent ha creado una herramienta genial que nos ayuda a hacer todo esto de manera casi transparente para nosotros.

git-flow al rescate

Vincent define git-flow como una colección de extensiones de Git que nos facilita un conjunto de operaciones de alto nivel para trabajar con el flujo que antes hemos visto.

Para instalarlo en vuestro Mac OS o Ubuntu tenemos que lanzar la siguiente instrucción desde la consola:

# Para Mac OS X
$ brew install git-flow

# Para Ubuntu
$ apt-get install git-flow

Una vez instalado y desde el directorio raiz de nuestro proyecto, tenemos que inicializarlo:

$  git flow init

Esto nos hará una serie de preguntas sobre como queremos nombrar a las diferentes ramas y el prefijo de nuestras versiones. Si queremos usar las de por defecto, pulsamos intro en todas las opciones o podemos usar esta instrucción para inicializarlo:

$  git flow init -d

Ahora ya tenemos creada nuestra rama develop y estamos listos para empezar a trabajar.

Trabajando con features

Para empezar a desarrollar una nueva funcionalidad tenemos que crearla usando:

$ git flow feature start nombre_de_funcionalidad

Automáticamente te crea la rama feature/nombredefuncionalidad y te cambia a ella. Ahora después de varios commits decides que ya has terminado con esa funcionalidad:

$ git flow feature finish nombre_de_funcionalidad

Mirando la consola vemos que nos fusiona esta rama con develop, nos borra esta rama y nos cambia a develop automáticamente. Si en algún momento queremos ver que ramas de features tenemos actualmente, podemos hacerlo con:

$ git flow feature

Si quisiéramos retomar una de esas funcionalidades que estamos realizando, por ejemplo después de solucionar un hotfix, lo podemos hacer con:

$ git flow feature checkout nombre_de_funcionalidad

Trabajando con releases

Después de haber desarrollado unas cuantas funcionalidades y haberlas commiteado, queremos liberar una nueva versión de nuestro proyecto. Para crear esta nueva release tenemos que usar:

$ git flow release start version_1

Hacemos los cambios necesarios para la nueva versión y decidimos que está todo preparado:

$ git flow release finish version_1

Esto buscará cambios en nuestro repositorio remoto, fusionará esta versión con nuestras ramas master y develop, borrando la release y dejándonos todo listo para desplegar desde la rama master.

Trabajando con hotfixes

Si estamos trabajando en una funcionalidad y tenemos que cambiar algo que no funciona bien en nuestro entorno de producción, creamos una rama de hotfix:

$ git flow hotfix start error_en_produccion

Esta rama será creada a partir de nuestra master, ya que es lo último que hemos desplegado. Al terminar de arreglar el problema tenemos que:

$ git flow hotfix finish error_en_produccion

Esto fusionará los cambios tanto con develop como con master, teniendo la solución al problema listo para ser desplegado en producción.

Como veis git-flow automatiza muy bien la manera de trabajar con git, aplicando un flujo de trabajo más que probado y usado, adaptándose perfectamente a la mayoría de los proyectos. Espero que os ayude y facilite las cosas tal y como lo me lo ha hecho a mi.

Fuente:

codeloveandboards.com

septiembre 13th 2017

¿Qué es git-flow?

Número de lecturas: 328
{lang: 'es-419'}

Si ya conoces gitflow pero quieres conocer como trabajar puedes utilizar este enlace:

http://danielkummer.github.io/git-flow-cheatsheet/index.es_ES.html

Debes disponer de una máquina con git instalado:

  • Windows: msysgit que puedes descargar de este enlace
  • Mac: a través de homebrew o macports
  • Linux: a través del gestor de paquetes de tu distribución

Flujos de trabajo

Hace unos días participé en el Open Space de Calidad del Software organizado en Madrid este mes de febrero. En la reunión se abordaron varios temas que iban desde responder a preguntas como ¿qué se calidad del software? ¿cuánto cuestan los tests funcionales? o ¿cómo hacer testing de desarrollos para dispositivos móviles? pasando por otros tan exóticos como el Pirata Roberts, llegando incluso a plantearse hasta la eliminación de los responsables de calidad de la faz de la tierra.

En casi todas las conversaciones en las que tuve la oportunidad de participar había un denominador común: las ramas. Se hablaba de ramas para hacer hot-fixes urgentes, ramas para desarrollar nuevas versiones separadas de las ramas maestras donde está la versión en producción. Ramas para probar nuevas versiones, ramas y repositorios para trabajar con proveedores externos, ramas para hacer pruebas en pre-producción, ramas para que los departamentos de calidad hagan sus pruebas antes de liberar nuevas versiones. Con git podemos crear ramas “como churros” y ese fin de semana tuve la oportunidad de compartir con varios colegas de profesión cómo utilizar las ramas para hacer el bien. Sin embargo, esta facilidad para crear ramas también se puede utilizar para hacer el mal y sembrar el terror. Más de una vez he visto ramas creadas sin ningún criterio, sin ningún flujo de información detrás que las sustente. Esta situación suele llevar al repositorio al caos más absoluto.

Para no acabar en el caos, debemos establecer unas “reglas del juego” que todo el equipo debe respetar. Aunque a grandes rasgos casi todos los proyectos pueden utilizar unas reglas de base comunes, las reglas deben ser flexibles para adaptarse a los cambios que puedan surgir en el tablero de juego; al fin y al cabo, las necesidades y particularidades de cada equipo, empresa o proyecto no son las mismas.

¿Y cuáles son estas reglas base comunes? En enero de 2010 Vincent Driessen publicó en su blog un artículo en el que compartía con la comunidad un flujo de trabajo que a él le estaba funcionando: “A successful Git branching model”. Como él mismo cuenta en el artículo (te recomiendo encarecidamente que lo leas) Vincent propone una serie de “reglas” para organizar el trabajo del equipo.

Ramas master y develop

El trabajo se organiza en dos ramas principales:

  • Rama master: cualquier commit que pongamos en esta rama debe estar preparado para subir a producción
  • Rama develop: rama en la que está el código que conformará la siguiente versión planificada del proyecto

Cada vez que se incorpora código a master, tenemos una nueva versión.

Además de estas dos ramas, Se proponen las siguientes ramas auxiliares:

  • Feature
  • Release
  • Hotfix

Cada tipo de rama, tiene sus propias reglas, que resumimos a continuación.

Feature or topic branches

feature branches

fuente: nvie http://nvie.com/posts/a-successful-git-branching-model/

  • Se originan a partir de la rama develop.
  • Se incorporan siempre a la rama develop.
  • Nombre: cualquiera que no sea master, develop, hotfix-* o release-*

Estas ramas se utilizan para desarrollar nuevas características de la aplicación que, una vez terminadas, se incorporan a la rama develop.

Release branches

  • Se originan a partir de la rama develop
  • Se incorporan a master y develop
  • Nombre: release-*

Estas ramas se utilizan para preparar el siguiente código en producción. En estas ramas se hacen los últimos ajustes y se corrigen los últimos bugs antes de pasar el código a producción incorporándolo a la rama master.

Hotfix brancheshotfix branches

  • Se origina a partir de la rama masterfuente http://nvie.com/posts/a-successful-git-branching-model/
  • Se incorporan a la master y develop
  • Nombre: hotfix-*

Esas ramas se utilizan para corregir errores y bugs en el código en producción. Funcionan de forma parecida a las Releases Branches, siendo la principal diferencia que los hotfixes no se planifican.

¿Qué es git-flow?

Si queremos implementar este flujo de trabajo, cada vez que queramos hacer algo en el código, tendremos que crear la rama que corresponda, trabajar en el código, incorporar el código donde corresponda y cerrar la rama. A lo largo de nuestra jornada de trabajo necesitaremos ejecutar varias veces al día los comandos git, merge, push y pull así como hacer checkouts de diferentes ramas, borrarlas, etc. Git-flow son un conjunto de extensiones que nos ahorran bastante trabajo a la hora de ejecutar todos estos comandos, simplificando la gestión de las ramas de nuestro repositorio.

La flexibilidad de git…y el sentido común

Las “reglas” que Vincent plantea en su blog son un ejemplo de cómo git nos permite implementar un flujo de trabajo para nuestro equipo. Estas no son reglas absolutas, bien es cierto que pueden funcionar en un gran número de proyectos, aunque no siempre será así. Por ejemplo ¿qué pasa si tenemos que mantener dos o tres versiones diferentes de una misma aplicación? digamos que tenemos que mantener la versión 1.X, la 2.X y la 3.X. El tablero de juego es diferente así que necesitaremos ampliar y adaptar estas reglas para poder seguir jugando.

git es una herramienta que nos permite modificar estas reglas y, lo que es más importante, irlas cambiando y adaptando a medida que el proyecto avanza y el equipo madura. Una vez más, una buena dosis de sentido común será nuestra mejor aliada para responder las preguntas que nos surjan durante el camino.

Referencias:

Fuente:

aprendegit.com

septiembre 5th 2017

Ocultar Divs con css de acuerdo a la resolucion de Pantalla

Número de lecturas: 638
{lang: 'es-419'}

Para ocultar un div segun la resolucion de pantalla se puede utilizar este codigo:

@media handheld, only screen and (max-width: 767px) {
.search_and_share{
display:none;
}
}
 
@media only screen and (max-width: 1023px) {
.search_and_share{
display:none;
}
}

Fuente:
forosdelweb.com