Destripando: Instants Chile Get! – Prueba de concepto (Parte II)

Este artículo es parte de una serie:

Voy a ser honestos con ustedes, no tengo idea de qué cosa significa exactamente una «prueba de concepto». La utilizo según lo que me parece que quiere decir, “probar” si es posible dar con una pequeña prueba para luego generalizarla. Claramente el objetivo de mi aplicación, es bastante general (descargar todos los archivos y decodificarlos). Por lo que antes de comenzar a ver como descargar todos los archivos, sería más prudente descargar alguno y ver si efectivamente puedo transformarlo en un formato audible que no sea swf. ¿Imaginan que logro dar con una fórmula para descargar todo y finalmente resulta que no puedo hacer nada con los archivos?.

Esto por supuesto, puede tener muchos acercamientos (incluso ni siquiera utilizar un prototipo), personalmente me gusta lo que pregona la metodología ágil (algún día hablaré de ello); que consiste básicamente[2] en trabajar en base a iteraciones y pequeñas metas, de forma de que cada cierto intervalo corto de tiempo (cada día por ejemplo) se avance algo, aunque signifique modificar y reparar el código más de alguna vez. Esto permite tener una percepción de “ir avanzando” y no quedarse “pegado” en soluciones complejas, además darle muchísimo más dinamismo.

Por otra parte, me parece mucho más simple dar con una solución única y luego buscar la forma de generalizarla que desgastarse en problemas más difíciles de abordar, especialmente cuando recién nos sentamos y parece abismante la cantidad de trabajo que queremos realizar.

Manos a la obra

Sigue leyendo

Anuncios

Destripando: Instants Chile Get! – Planificación (Parte I)

Hace algunas semanas les presenté Instants Chile Get Improved un script de Bash, que descarga todos los instants desde instants.cl y los transforma a mp3/wav; la idea ahora, es ir siguiendo los pasos que nos llevarían a desarrollar el script.

Al menos en mi percepción, lo más importante de la programación es saber abstraerse; si bien, todos los lenguajes tienen sintaxis, reglas y exigencias distintas a la hora de programar (que el “;” al final de cada línea, que la indentación, etc). Al final todos poseen ciertos denominadores comunes, como estructuras de control (if, else), bucles, iteraciones, etc. La idea de esta serie, si bien aprender algo de bash y scripting, es también aprender técnicas y/o sugerencias para ayudar a programar un poco mejor.

Luego de esta introducción, comenzamos la primera parte: la planificación.

Sigue leyendo

Acabo de salvar mi vida con git… Parte 3/5

(…viene de la segunda y primera parte)

Creando nuestro primer proyecto

Primero, tenemos que inicializar el proyecto en alguna parte. Digamos que en /home/david/docs/.

git init
git add .
git commit

Es decir, iniciamos el repositorio, agregamos todos los archivos que ya existen (si no hay ninguno, no importa), y creamos la primera copia. Ya tenemos una copia de nuestro proyecto con git. Ahora, cambiamos un par de archivos (eso me significa abrir OpenOffice.org y hacer un par de cambios en los HTML del proyecto, pero si es código basta con vim, emacs o lo que usen).

Sigue leyendo

Acabo de salvar mi vida con git… Parte 2/5

Viene de la primera parte.

Ahora sí, ¡comenzamos!

El dueño de la empresa quería tener acceso a los documentos que yo escribía, para revisarlos de vez en cuando. Ese de vez en cuando para cualquiera se traduciría en “casi nunca”. Para él, es un “mañana, tarde y noche”.

Lo que hice fue tomar uno de los diez ordenadores, ponerlo como firewall con una regla que conecta directamente el puerto de git (lo tengo funcionando como daemon) a mi servidor de documentación. Mi jefe usa un MacOS X y tiene git instalado (a veces descarga cosas desde github), por lo que lo único que debe hacer es:

git clone git@myserver.org

La configuración de git es un poco más compleja, dependiendo de la recepción de este artículo puedo compartirla, pero por lo pronto creo que es necesario aprender a usarlo nada más.

Ahora, cada vez que quiere leer lo nuevo, sólo debe entrar en el directorio donde tiene la documentación:

git pull

Pero yo que soy el que está documentando, tengo mucho trabajo.

De partida, git es distribuido; cada copia del directorio de proyecto tiene su propio repositorio (en un subdirectorio llamado .git), por lo que uno puede tener copias locales y remotas. También hay “repositorios desnudos” o “bare repositories” que no están adjuntos a una copia. Esto es lo primero que hice cuando decidí cómo hacerlo. Como tiene su propio repositorio, la división entre el tronco (trunk) y las ramas (branches) y hojas del repositorio están incluídas lógicamente, no como en Subversion en el que uno tiene que crear los subdirectorios trunk/, branches/ y tags/.

Configurando nuestro entorno

Bueno, no siempre documento yo. A veces hay cosas que documentan mis compañeros que están en el desarrollo y ellos también deben tener su copia de git. Pero, ¿cómo saber quién escribió qué? No, no es difícil. Con git hasta por e-mail podemos enviar cambios. Configuremos entonces nuestro nombre y nuestro e-mail.

git config --global user.name "Arie Deckelmann"
git config --global user.email "arie.deckelmann@gmail.com"

(Arie Deckelmann es uno de mis colaboradores, es una de las personas más inteligentes que conozco y fue el que me enseñó la gran mayoría de los trucos de git que ahora sé. Podría haberlos aprendido yo mismo, pero a veces simplemente no me da la cabeza para tanto).

También podemos mostrar colorcitos:

git config --global color diff auto
git config --global color status auto
git config --global color branch auto

Y con eso tenemos salidas de color. Quizás algún diseñador gráfico podría darnos una mano con ello, pero bueno…

Continúa en la tercera parte.

Foto:

Acabo de salvar mi vida con git… Parte 1/5

Domingo en la noche. Desde que estoy en Londres, trabajando con un par de desarrolladores geniales que me consumen la totalidad del tiempo (sí, también son buenos para beber), no he parado de darle al trabajo. Estamos documentando una plataforma complicada.

Trabajo como consultor en una empresa distribuidora de alimentos, en la que obviamente no tienen la menor idea sobre computadoras. La empresa se vendió a otra en que el dueño sabe mucho sobre sistemas no documentados (fracasó en un desarrollo, que tuve que salvarlo yo en 2006), y evaluó lo que existía en términos de… ¿infraestructura?

Toda la información de importación, exportación, compras, ventas y otros se ingresa a sistemas en RMCOBOL 85, que se comunican a través de Perl CGI con el exterior. La cosa funciona, pero los que conocen todo el sistema son unos señores de unos 40 años de edad, tan valiosos que si llegasen a tener una mejor oferta en el exterior echan por la borda todo.

Sigue leyendo

Programación Para Newbies: Fortran 6: Vectores y Arrays

Acá desarrollaremos el manejo más básico de vectores y arrays (también conocidos como arreglos en español) en el lenguaje Fortran.

A muchos les puede sonar conocida la palabra vector, para algunos, es un organismo que transmite enfermedades, para otros (los más matemáticos) es una cantidad dirigida, o un elemento de una estructura algebraica conocida como espacio vectorial, por lo tanto partimos definiendo ¿qué es un vector o un array en Fortran?.

Básicamente un vector (o array también) es una manera de manejar una gran cantidad de datos de manera más cómoda, ¿a qué nos referimos con esto? se preguntarán algunos, bueno, más especificamente un vector es un tipo de variable, que dentro de si contiene distintos valores.

Por ejemplo, en matemáticas, podemos definir el vector A=(x,y,z) en el espacio de 3 dimensiones, en Fortran es muy similar (recordemos que el objetivo del lenguaje es ayudar en tareas de matemáticas, ciencia e ingeniería), podemos definir vectores con cuantas componentes queramos. Los arrays son un poco distintos, estos trabajan (por dar un par de ejemplos) en distintas dimensiones, con esto me refiero a filas, columnas, etc, estas imágenes son más explicativas:

Sigue leyendo

Programación Para Newbies: Fortran 5: Subprogramas

Hasta el momento, hemos aprendido a trabajar con las distintas variables, y a usar estructuras para modificar el curso que toman nuestros programas, pero cuando nos enfrentamos a programas más extensos, que algunas veces necesitan ejecutar un mismo bucle para procesar ciertos datos, pero las variables no son las mismas, no es lo más cómodo copiar y pegar las mismas instrucciones varias veces, más todavía si tenemos que estar cambiando las variables cada vez que usemos el mismo algoritmo, para esto existen los subprogramas.

Un subprograma es una estructura que se agrega al final del programa y se puede invocar en cualquier parte del programa principal (perdonen que sea reiterativo con la palabra programa) indicando que variables participan dentro del subprograma, que cambios se les hacen, etc. Tenemos de dos tipos: functions y subroutines, sus diferencias son sutiles.

Una function (o función en castellano), son subprogramas que tienen 0 o más argumentos (variables) y que retornan un valor en el nombre, esto significa, por lo pronto, que su invocación debe estar al lado derecho de una asignación de valor a una variable y no puede formar una sentencia aislada dentro del programa. Ejemplificando:

variable=funcion(argumentos)

siempre va a la derecha la invocación de la función. La sintaxis para crear nuestras propias funciones en Fortran es la siguiente:

Sigue leyendo