lunes, 18 de abril de 2016

Control de versiones de tu proyecto con GIT + Bitbucket

Registrar un nuevo repositorio. Desde la pantalla principal de Bitbucket, navegá a Repositorios > Crear un nuveo repositorio. Ingresá un nombre y dale click a “Crear”.
mkdir ./DemoRepo
cd ./DemoRepo

Crear el directorio del proyecto en tu computadora. Abrí una terminal, dirigite a la ubicación donde te gustaría tener el repo, e ingresá:

Iniciar el repo en tu máquina local.
git init
git remote add origin https://tuUsername@bitbucket.org/tuUsername/demorepo.git

Incluí los archivos de tu proyecto en este directorio. Si ya iniciaste un proyecto, simplemente copiá y pegá los archivos a esta ubicación.

Comprobá el estado de tu repo. Desde la terminal:
git status

Ahi vas a ver listado todos los archivos que han sido modificados desde el último snapshot (o commit). Como este es el primero, vas a ver listado todos los archivos.

Aceptá los cambios y creá un commit:
git commit -am "This is the first commit. Please write something descriptive here!"

Si este snapshot es realmente importante y querés resaltarlo de otros existentes, podés usar tags. Estos tags se aplican al último commit en tu repositorio local. Para ello:
git tag -a v1.0 -m "Initial working version"
Y es muy importante que para que otros puedan ver estos tags cuando los subas al repo general, lo hagas mediante:
git push --follow-tags

Si te olvidás de ese parámetro, solamente vos vas a ver el tag en tu repo local. Este último comando, push, subió tu snapshot al repositorio general... o al menos lo intentó. ¿Por qué digo esto? Porque si mientras vos hacías estos cambios a la versión inicial, alguien más hizo otro cambio, subió al repositorio general, y las líneas que modificaron son las mismas, git no va a dejarte subir tu commit tan fácilmente. Vas a tener que hacer un merge. Pero eso lo vemos más adelante, porque probablemente aquí tengas que configurar algo más:

Configurar la acción por default de “push” sobre el repo remoto. Acá tenés dos opciones: matching o simple. La primera hará que cuando hagas push, todas las ramas (branches) que tenés en el repositorio se actualicen. La segunda, que solo se actualice la rama sobre la cual estás trabajando. Yo prefiero la segunda, sobre todo si laburás en equipo.
git config --global push.default simple

Si aún no podés hacer push, puede que aún debas configurar la rama maestra. Para ello basta con agregar los siguientes parámetros:
git push --follow-tags --set-upstream origin master


Tranca. Esto solo vas a necesitarlo la primera vez. Y si no tenés nuevos tags que actualizar, te va a bastar con un simple “git push” de ahora en más.

Especifića que archivos no deberían incluirseen el commit. Esto puede ser útil para excluir archivos temporales o clases compiladas. Para ello, en la raiz del repositorio, desde la terminar ejecutá:
git rm --cached
gedit .gitignore


Agregá la ruta a las carpetas y/o archivos que quieras excluir. Ojo, esto hace que no se suban al repo, no solo que no se "trackeen". Podés reemplazar "gedit" por tu editor de texto de preferencia.

Visualizá tus commits. 
Ahora solo tenés que laburar en tu proyecto y hacer commits y pushs cada vez que lo creas necesario. ¿Es bueno hacer commit cada vez que dejo de laburar en algo? Mmm… No. Nada te lo impide, pero es bueno hacer commits solo de versiones que tengan alguna nueva funcionalidad en buen estado, no a medias. Esto es tanto más importante para con los push. (no queremos joder a otros con constantes cambios). Pero en definitiva, es algo que seguramente vas a acordar con tus compañeros de equipo.

¿Que puedo necesitar de ahora en más?

  • Mergear commits
  • Hacer stasing, en lugar de commit
  • Volver atrás para comparar alguna versión vieja de un archivo o proyecto
  • Volver a laburar con una versión vieja de un archivo/proyecto (revertir commits)
  • Laburar con branches

domingo, 31 de enero de 2016

Instalando Moodle 3 desde Ubuntu 15

1. Instala Apache, MySQL y PHP.
El primero de ellos se trata de un servidor Web de código abierto, que nos permitirá levantar un sitio virtual. EL segundo es un sistema de gestión de base de datos relacional. El último se trata de un lenguaje de desarrollo Web. Este código es interpretado del lado del servidor, por lo cual es necesario que instalemos un módulo procesador de PHP, que genere la página Web especificada. Para todo esto:
sudo apt-get install apache2 mysql-server php5 php5-mysql
2. Instala paquetes adicionales:
sudo apt-get install graphviz aspell php5-pspell php5-curl php5-gd php5-intl php5-mysql php5-xmlrpc php5-ldap
3. Reinicia para que sean cargados correctamente:
sudo service apache2 restart
Otros comandos útiles son: start | stop | reload | status
4. Ingresa a http://localhost/ desde el navegador Web y verifica que el servidor esté en funcionamiento. Si es así, verás la Apache2 Ubuntu Default Page.

5. A partir de ahora, podemos crear páginas o sitios en /var/www/ y podrán ser accedidos desde localhost. Para ello, puede que requieras cambiar el owner de los directorios creados, para tener acceso ilimitado. Para ello:
sudo chown gabi:gabi -R /var/www
Donde gabi es el nombre de tu usuario
6. Descarga Moodle desde aquí, extraelo y copialo en /var/www/html

7. Accede a http://localhost/moodle (o como hayas llamado a tu carpeta de moodle) y sigue los pasos de configuración. Si en algún momento del proceso obtienes un "Upgrade error", ingresa esto mediante terminal y recarga la página:
cd /var/www;sudo ln -s /usr/share/moodle
8. Start playing!



viernes, 6 de noviembre de 2015

Desarrollando extensiones de Firefox

1) Instalar NPM:
sudo apt-get install npm

2) Instalar JPM:
sudo npm install jpm --global

3) Si nos encontramos con error, porque no se encuentra node, crear un symlink:
sudo ln -s "$(which nodejs)" /usr/bin/node

4) Instalar la extensión auto-installer:
https://addons.mozilla.org/es/firefox/addon/autoinstaller/

5) Crear un esqueleto:
jpm init

6) Modificar su código, y postearlo con:
jpm watchpost --post-url http://localhost:8888/

7) Para instalar extensiones, a partir de Firefox 42, el browser requiere que las mismas están firmadas. Para instalar la que estamos desarrollando, si no están usando la edición Developer o Nightly, tienen que entrar a
about:config 
y cambiar el valor de la siguiente entrada a false:
xpinstall.signatures.required


miércoles, 31 de julio de 2013

Instalando y utilizando Mercurial para crear un repositorio local

1) Agregar uno de los siguientes PPA, mediante terminal:
sudo add-apt-repository ppa:mercurial-ppa/stable-snapshots
sudo add-apt-repository ppa:mercurial-ppa/snapshots
Luego,
sudo apt-get update
2) Instalar Mercurial con:
sudo apt-get install mercurial

3) Crear un archivo llamado .hgrc en home, que tenga como contenido:
[ui]
username = Tu Nombre <tu@email>
editor = tuEditorDeTextoFavorito
[extensions]
hgext.purge=
#or, if purge.py not in the hgext dir:
#purge=/path/to/purge.py

4) Crear y/o cambiar al directorio donde se encuentra el proyecto a versionar:
cd /home/Gaby/SourceCode/MyProject01
5) Crear el repositorio. Con ello se creará una carpeta oculta llamada “.hg”:
hg init
6) Agregar archivos para el próximo commit.
Si la carpeta ya tenía archivos, sólo basta con registrarlos para que sean incluidos en el commit. En cambio, si se trata de un nuevo proyecto, se deberán crear los archivos y luego registrarlos. En ambos casos, existiendo ya archivos en el directorio, la forma de registrarlos es:
hg add
En caso de querer agregar sólo determinados archivos, se lo debe especificar de la siguiente manera:

hg add nombreDelArchivo.extensión
8) Mostrar los cambios que hubo en el Working Directory.
Esto indicará el estado de los archivos del proyecto, donde por cada archivo se indicará:
  • “A” significa “added”,
  • “M” significa “Modified”,
  • “R” significa “Removed”,
  • “!” significa perdido, desaparecido.
  • “?” significa desconocido (Mercurial aún no sabe nada acerca de ese archivo).
Se puede consultar el estado con cualquiera de los siguientes comandos:
hg status
hg st
Si tenemos archivos perdidos que realmente queremos quitar de la nueva versión, entonces se puede optar por hacer un

hg addremove
en lugar de un simple remove, que además de agregar los nuevos archivos quita los faltantes, o simplemente un
hg remove -A

9) Generar un commit
Se puede generar con alguno de los dos siguientes comandos:
hg commit
hg commit -m "Descripción del cambio realizado"
La diferencia está en que el primero abrirá un archivo en el cual se deberá escribir y guardar la descripción de la versión, mientras que en el segundo se especifica directamente en el comando.

10) Hacer algunos cambios en el proyecto y generar un segundo commit.

11) Consultar el historial de revisiones del repositorio
Mostrará los changesets (versiones) registrados al momento, ordenados del más reciente al más antiguo. También se puede limitar el número de entradas a mostrar.
hg log
hg log -l 5
hg log --limit 5

12) Volver a un changeset anterior
Se debe conocer el número del changeset al que deseo volver. Este id puede consultarse mediante hg log.
hg update 0
*donde 0 es el número de changeset

13) Hacer modificaciones nuevamente sobre uno o varios archivos del proyecto.

14) Revertir los cambios efectuados
Aquí se puede elegir entre revertir todos cambios de todos los archivos, con alguno de los siguientes comandos:
hg revert -a
hg revert --all
O sólo revertir los cambios efectuados a determinados archivos:
hg revert filename.ext

15) Limpiar los archivos .orig (generados cuando se hage un revert)
hg purge
16) Generar un commit

17) Ver las diferencias de un determinado archivo en diferentes changesets
hg diff -r 0:1 unArchivo.extensión
*donde 0 y 1 son números de versiones

18) Mostrar el resumen del estado del Working Directory
hg summary

Para un completo tutorial, visitar:

sábado, 25 de mayo de 2013

Documentando código Javascript con JsDoc3

JsDoc es un generador de documentación de código JavaScript que utiliza cierto formato de comentarios para auto generarla.

En primer lugar, descargaremos el zip de JsDoc desde aquí y luego lo descomprimimos en una ubicación donde vaya a ser "instalado". Por ejemplo /home/usuario/Development

Para saber si todo funciona correctamete, abrir una terminal, cambiar al directorio raiz de JsDoc (ej: cd /home/usuario/Development/jsdoc-master/) y correr la siguiente línea para ejecutar los tests de verificación:
./jsdoc -T
Si todo ha ido bien, tendremos un mensaje similar a este:

Finished in 6.475 seconds706 tests, 1594 assertions, 0 failures.................Finished in 0.028 seconds17 tests, 34 assertions, 0 failures

Otra forma de instalarlo es ejecutando en consola:
sudo apt-get install jsdoc-toolkit
Esta segunda opción trae algunos cambios, que se marcarán como [Op2].


Ahora, para generar algo realmente vamos a hacer una prueba con código. Para ello vamos a utilizar este archivo, donde se pueden encontrar algunos tags específicos para indicar la descripción de una clase, sus parámetros de entrada, su return, entro otros. La lista completa de tags que se pueden utilizar puede ser consultada aquí

Para generar la documentación se debe ejecutar la siguiente línea, siempre reemplazando los directorios por los tuyos (yo muestro un ejemplo según mi archivo y directorios): 

./jsdoc /home/usuario/Desktop/prueba.js --destination /home/usuario/Desktop/out

[OP2]:
jsdoc /home/gaby/Desktop/prueba.js --directory=/home/user/Desktop/out 

También puede generarse sin especificar el parámetro "--destination" o "--directory", en cuyo caso la documentación se generará y quedará almacenada en la carpeta /out del directorio de la aplicación JsDoc (en mi caso /home/usuario/Development/jsdoc-master/out).

Por defecto, JSDoc usará la plantilla "default" para convertir los comentarios en HTML, pero es posible editar esta plantilla para adaptarla a otras necesidades, o crear una plantilla totalmente nueva.


viernes, 24 de mayo de 2013

Registrar las tools del ADT de Android


Si ya tenés instalado el SDK de Android, saltea este paso. Sino, simplemente bajalo de http://developer.android.com/sdk/index.html y descomprimilo en una ubicación donde vayas a dejarlo "instalado". Por ej: /home/user/Development/

Para poder utilizar cualquiera de las herramientas dentro de /tools o /platform tools desde la terminal y desde cualquier ubicación, es necesario registrar la ubicación de las mismas. Sino, por ejemplo, cada vez que necesitemos utilizar el adb desde línea de comando necesitaremos:
/Development/adt-bundle-linux/sdk/platform-tools
./adb devices
Para evitar esto, creamos un par de paths en ~/.bashrc. Para ello, ejecutamos en terminal:
sudo gedit ~/.bashrc
Agregar las siguientes líneas al final del archivo abierto, editar los paths según la ubicación donde instalaste el SDK, guardar y cerrar.
# Android tools
export PATH=~/Development/adt-bundle-linux/sdk/platform-tools:~/Development/adt-bundle-linux/sdk/tools:$PATH
Por último, se debe ejecutar el siguiente comando para recargar el .bashrc:
source ~/.bashrc
Ahora se puede utilizar las herramientas sin necesidad de cambiar de directorio y tipear "./".

martes, 12 de febrero de 2013

Patrones de diseño

He abierto un nuevo blog exclusivamente para hablar sobre Patrones de Diseño. Quienes deseen leer sobre el tema, podrán acceder desde la siguiente URL o desde el vínculo permanente a mis otros blogs.

http://design-patterns-with-uml.blogspot.com.ar/