Análisis de redes en las VII Jornadas de usuarios de R

El pasado 6 de noviembre de 16 a 19 h impartí en las VII Jornadas de Usuarios de R el taller «Análisis de redes en R con el paquete igraph». Una conferencia en la que se dieron cita los miembros más activos de la comunidad de R, y con un conjunto de ponencias y talleres muy elevado.

Tenéis un resumen del taller en el blog del IIC, y los materiales que utilice para la impartición del mismos los podéis descargar directamente de la página de las Jornadas.

Brevísima introducción a las licencias software

El desarrollo software es un proceso creativo que genera un código fuente que está protegido por derechos de autor similares a otras obras. En términos generales se distingue entre quién es el autor del código y quién posee el derecho de decidir qué se puede hacer con él. La autoría del código se corresponde a una persona física siempre que se identifique cómo tal y se la pueda atribuir unívocamente. En caso de obras anónimas o producidas colaborativamente la autoría puede llegar a atribuirse a un conjunto de personas o en una persona jurídica.

Es importante tener claro que no tiene porqué coincidir el autor del código con la persona que tiene los derechos de explotación. Por ejemplo, en el caso de que el desarrollador sea un trabajador asalariado la titularidad de los derechos de explotación corresponderán, exclusivamente, al empresario, salvo que se recoja lo contrario en el contrato. Los derechos de explotación permiten establecer las condiciones de uso del software las cuales se recogen en un documento denominado licencia. Los distintos usos del mismo incluyen ejecución, distribución, modificación y copia, aunque no todos tienen que estar licenciados el usuario. En la licencia se incluye, además, si estos derechos se ceden de manera exclusiva o no exclusiva así como la duración de la cesión, que puede ser durante un periodo determinado o indefinidamente.

En la industria del software existe un tipo de licencia conocida como software libre que difícilmente se puede equiparar con otras licencias que se aplican a bienes materiales. Esta denominación se aplica aquellos programas que permiten acceder a su código fuente y cumpla ciertas condiciones de distribución, de manera que los usuarios, además de poder ejecutarlo, tienen derecho a leer el código, modificarlo, copiarlo o distribuirlo a un tercero. Hay que tener en cuenta que estos tipos de licencia no imponen restricciones en cuanto a la comercialización del software. Así, es posible vender software libre siempre que se cumpla con los requisitos de distribución del código incluidos en la licencia. Por el contrario hay modalidades donde el uso es gratuito pero no son software libre. Por ejemplo, estarían excluidos los programas “freeware” o programas con licencias de uso gratuito para fines no comerciales que no permiten el acceso al código fuente.

Dentro de las licencias de software libre existen dos grandes categorías:

  • Copyleft : el software derivado tiene que preservar la condición de software libre obligando a distribuir el código en los mismos términos que el código original. Existen distintas acepciones en cuanto a la extensión del copyleft dividiéndose en:
    • Copyleft fuerte (strong): la licencia se tiene que aplicar a toda la obra derivada a que incluya o use alguna parte del software libre. Estas licencias se denominan también virales siendo GPL y sus distintas variantes la más popular.
    • Copyleft fuerte (débil): Las licencias copyleft débiles imponen límites sobre qué partes de la obra derivada tienen que preservar la licencia y cuales no. LGPL es una licencia copyleft débil muy extendida que se aplica a bibliotecas de manera que permite enlazar código dinámicamente sin tener que adoptar la licencia. Sólo los cambios que se realicen sobre la propia biblioteca se ven afectados por la licencia original. De manera parecida actuan la Mozilla Public License (MPL) o en la Eclipse Public License (EPL).
  • Permisivas: en esta caso no se imponen restricciones al software derivado de las modificaciones que se realicen el código. El autor de las modificaciones puede decidir cómo licencia la nueva obra pudiendo incluso convertirla en software propietario. Entre las licencias más populares en esta categoría estarían ApacheMIT y BSD 3-clausulas.

Finalmente indicar que se pueden otorgar licencias distintas para mismo software. Por ejemplo distribuir gratuitamente como software libre y venderlo con otra licencia comercial

¿Qué licencia o licencias le pondrías a tus programas?

ESTE POST SE PUBLICA POR PABLO HAYA ”COMO ESTÁ”. EN NINGÚN CASO PABLO HAYA SERÁ RESPONSABLE POR NINGÚN DAÑO DIRECTO, INDIRECTO, INCIDENTAL, ESPECIAL, EJEMPLAR O CONSECUENTE O POR CUALQUIER TEORÍA DE RESPONSABILIDAD, YA SEA POR CONTRATO, RESPONSABILIDAD ESTRICTA O AGRAVIO (INCLUYENDO NEGLIGENCIA O CUALQUIER OTRA CAUSA) QUE SURJA DE CUALQUIER MANERA DE LA LECTURA DE ESTE POST, INCLUSO SI SE HA ADVERTIDO DE LA POSIBILIDAD DE TALES DAÑOS.

Para cualquier duda legal se recomienda consultar con su abogado de cabecera. Cualquier incorrección que encuentres, por favor, comunícamela o coméntala directamente.

Diferencia entre scanf, gets y fgets

La biblioteca estándar de C provee de varias funciones para introducir datos a nuestros programas. Estas son parte del módulo stdio.h. Vamos a ver la diferencia que existe entre tres de ellas (scanf, gets y fgets). Las tres nos permiten leer cadenas de caracteres introducidas por el usuario pero con importantes diferencias.

scanf es la más versátil de la tres dado que puede leer distintos tipos de datos (cadenas, enteros, reales…) según el formato especificado. En cambio, gets y fgets sólo leen cadenas de caracteres (nótese la ‘s’ final del nombre que hace referencia en este caso a string).

Veamos como leen cada una de ellas la entrada del usuario. Cuando se utiliza la consola, el programa no lee directamente el texto tal cual lo introduce el usuario si no que éste se almacena en una tabla intermedia que llamaremos buffer. Cada vez que el usuario pulsa el retorno de carro, se llena el buffer con la línea introducida (incluyendo el carácter '\n'). Las diferencias radican en cómo leen las tres funciones del buffer. Vamos a verlo con el siguiente ejemplo:

    int i1, i2;
    char s1[30], s2[30];

    scanf("%d", &i1);
    scanf("%d", &i2);

    gets("%s", s1);
    gets("%s", s2);

Supongamos que el usuario introduce “20\n30\npablo\n”, la secuencia de lectura sería la siguiente:

Entrada Buffer antes Instrucción Buffer después
20\n 20\n scanf("%d", &i1); \n
30\n \n30\n scanf("%d", &i2); \n
\n \n gets("%s", &s1);
pablo\n pablo\n gets("%s", &s2);

El primer scanf tiene que leer del buffer hasta que encuentra un número (%d). En cuanto encuentra el 20 termina de leer, y deja en el buffer un '\n'. El segundo scanf, tras la entrada del usuario, se encuentra con \n30\n, y tiene que realizar la misma tarea que el anterior, leer un número. Se salta el primer '\n', y lee 30, dejando de nuevo un '\n' en el buffer. La función gets es más simple, y lo único que hace es leer todo lo que haya en el buffer hasta que encuentre un '\n', y lo copia en la variable correspondiente. Así, el primer gets se encuentra un \n, lo consume pero no copia nada en s1. El segundo gets se encuentra pablo\n, así que lee todo lo que hay en el buffer y lo guarda en s2. Para permitir que pablo se copie en s1, una posibilidad es incluir una llamada a getchar() antes de emplear gets para leer s1. Esta función lee un carácter del buffer, consumiendo así el '\n' que impedía rellenar s1 con pablo.

Ahora bien, gets es una función insegura tal como lo indica el compilador (warning: this program uses gets(), which is unsafe.). El problema es que no puedes controlar el número de caracteres que introduce el usuario pudiendo ocurrir que se copien en la cadena más caracteres que los permitidos por su tamaño máximo. Por ejemplo, en el código anterior que el usuario introdujera más de 29 caracteres. Este comportamiento puede producir que el programa termine abruptamente. Su uso también puede producir fallos graves de seguridad al habilitar la posibilidad de ejecutar código malicioso.

La alternativa segura de gets es fgets que si permite establecer el máximo de caracteres que pueden leerse. Un ejemplo de uso sería:

    char s[30];

    fgets(s, 30, stdin);

Primero se establece donde se quiere copiar la línea leída. A continuación el máximo número de caracteres incluyendo el '' que se pueden leer. En el ejemplo, fgets lee del buffer hasta que encuentra un '\n' o hasta que haya copiado en s un máximo de 29 caracteres. La propia fgets se encarga de incluir el '' para finalizar la cadena. El última parámetro hace referencia de donde se obtiene los datos. Al igual que otras funciones como fprintf, fgets se puede emplear para leer de la consola, indicándolo con stdin (standard input), o de un fichero. Otra diferencia importante con gets es que el retorno de carro se copia también en la cadena.

Ejemplo de sencillo de compilación en C bajo GNU/Linux

Este sencillo ejemplo muestra como construir un programa que consta de un módulo principal (main) que utiliza funciones de otro módulo (frases). Si nos fijamos en el módulo main.c este incluye llamadas a las funciones saludo  y despedida cuya implementación se encuentra en el fuente frases.c.

Programa principal

#include <stdio.h>
#include "frases.h"

int main()
{
    printf("%s\n", saludo());
    printf("%s\n", despedida());
    return 0;
}

Este módulo se compone, además, de un segundo archivo frases.h donde se definen los prototipos de las funciones anteriores. El programa principal indica que emplea las funciones del módulo frase mediante la directiva #include "frases.h".

Para construir el programa principal, primeramente hay que compilar por separado cada módulo (opción -c del compilador). El resultado será un archivo objeto (.o) que incluye código máquina no ejecutable. A continuación se enlazan los distintos código objetos para obtener el ejecutable. En el siguiente ejemplo se muestra la compilación, enlazado y ejecucción del ejemplo que hemos visto.

$ gcc -c -Wall frases.c
$ gcc -c -Wall main.c
$ gcc -Wall main.o frases.o -o holamundo
$ ./holamundo
Hola
Adios

Recomendaciones para escribir en un foro

tres reglas de oro para participar en un foro:

  • Ser preciso: la pregunta tiene que ser lo más concreta posible. Si se incluye código tiene  estar los más acotado posible al problema. Cómo regla general incluir el mínimo código que pueda reproducir el error. Así mismo es muy útil adjuntar la salida del programa, y si se trata de una violación de segmento, la salida producida por valgrind.
  • Ser claro: tanto en la redacción de la pregunta (evitar errores ortográficos y gramaticales) como en el código. Si el foro al mostrar el código impide leerlo fácilmente (ej. la instalación de Moodle de la UAM) es altamente recomendable emplear una herramienta en línea que permita visualizarlo correctamente (ej. gist, pastebin.com).
  • Ser educado: y respetuoso con el resto de miembros de la comunidad. Ten en cuenta que nadie está obligado a responderte. La mayoría de las comunidades tienen una reglas de publicación que tienen que ser respetadas. Léetelas. Como regla general no preguntes algo que ya haya sido respondido anteriormente.

Introducción a las superficies multitáctiles

Transparencias (1MB aprox.) elaboradas sobre diseño de la interacción por Pablo A. Haya, Manuel García-Herranz, Pablo Llinás y Fernando Olivera. Este obra está bajo una licencia de Creative Commons Reconocimiento-CompartirIgual 3.0 Unported. (Texto en castellano). La licencia de las imágenes que no son propiedad de los autores tiene que solicitarse directamente a ellos.

Consulta en delicious las referencias y enlaces que se mencionan o recomiendan en las transparencias.

“Buscando canciones”: una actividad de Aprendizaje basado en proyectos

Esta actividad la he diseñado basándome en la metodología de aprendizaje basado en proyectos. Se precisa experiencia básica en el lenguaje de programación que se emplee (ej. C), y desenvolverse con cierta soltura en el manejo de herramientas de desarrollo (ej. gcc y make).

La actividad está preparada para equipos de 3 integrantes, 2 semanas de duración y con una dedicación de 6h/semana/integrante. Hay que dirigir a los integrantes para que practiquen la competencia de trabajo en equipo.

Se puede combinar fácilmente con metodologías de desarrollo ágil. La actividad está preparada para ser implementada en C pero su adaptación a otro lenguaje no requiere grandes cambios menores.

La preparación de la misma por parte del equipo se puede realizar mediante un puzle.

Descárgate el enunciado y la rúbrica de evaluación.

Consideraciones a la hora de escribir un informe técnico o memoria

Durante las prácticas, ya sea en Informática o en Teleco, se requiere la entrega de informes técnicos, o memorias, en los que se exponen los resultados de la práctica realizada. A continuación os dejo una serie (incompleta) de consideraciones a tener en cuenta en la elaboración de la misma.

Presentación

  • Tamaño Papel. DIN A4.
  • Papel reciclado. Dado el volumen de papel que se gasta es altamente recomendable presentar las memorias en papel reciclado. Ahora bien, en otros contexto (Proyectos Fin de Carrera, Informes en la empresa…), esta medida puede dejar de ser válida.
  • Doble cara. Imprimir, a ser posible, las prácticas en impresoras que permitan doble cara. De esta manera seguimos ahorrando papel.
  • Encuadernadas. Todas las hojas formarán un único documento. Al menos las hojas tendrán que ir grapadas. En ningún caso se entregará hojas sueltas o sujetas con un clip.
  • Filiación. El nombre de los autores, curso, grupo y pareja a la que pertenecen tienen que ser visible en la portada del documento.
  • Tipo de letra. Tamaño 12. Times New Roman, con párrafos justificado.
  • Tabla de contenidos. La tabla de contenido (incorretamente llamada índice) permite relacionar los apartados de la memoria con el número de página donde empiezan. Es necesario incluirlo al principio del documento.
  • Títulos en las secciones. Los títulos deben incluir una descripción concisa y clara del contenido del apartado, además de una referencia numérica. Por ejemplo, en vez de Ejercicio 2, queda más claro el título como 2. Diseño e implementación de un decodificador 3:8.
  • Subsecciones. Si la extensión de la sección lo requiere, se deberá estructurar.
  • Figuras
    • Las figuras tienen que ser claras y correctamente escaladas.
    • Deben tener un pie de figura que conste de la referencia de la figura y el título. Ej. 6.1. Implementación de un multiplexor 8:1 mediante puertas lógicas.
  • Encabezado. No es obligatorio. Se pueden incluir el nombre del apartado correspondiente a la página, de manera que sea fácil situarse en el documento.
  • Pie de páginas. Incluir, al menos, numeración de las mismas.
  • Referencias cruzadas. Cuando se quiere hacer referencia a una figura o a otro apartado se debe realizar empleando la referencia de la misma. Ej. véase la Figura 6.1 ó en el apartado 2.3.
  • Presentación de código fuente
    • Indentación. 2, 4 ó 8 espacios. Siempre emplear espacios en lugar de tabulaciones. La mayoría de los editores se pueden configurar para incluir es espacios cuando se pulsa la tecla de tabulación.
    • Tamaño líneas. 80 caracteres m‡áximo por lí’nea.
    • TIpo de letra. fuente monoespaciada (courier o similar).
  • Otros: incluir los núœmero de l’ínea, resaltado (a ser posible).

Redacción

  • Ortografía. El informe debe estar libre de faltas de ortografía. Se recomienda emplear correctores ortográficos automáticos.

Contenido

  • Para cada sección/apartado de la memoría hay que intentar responder implícitamente a las siguientes tres preguntas:
    • Qué. Describir cuál es el problema que se pretende resolver. En el caso de las memorias de laboratorio, este apartado debe ser breve, ya que el enunciado del problema viene dado ya en la propia práctica. En ningún caso se debe realizar cortar y pegar del enunciado.
    • Cómo. Realizar un análisis de la solución propuesta.
    • Porqué. Es importante que la memoria no resulte en una mera descripción de lo que se ha realizado, sino que, también, se tien que justificar todas las decisiones que se han tomado. Las valoraciones pueden ser tanto cuantitativas (Ej. Tiempo de ejecución, memoria ocupada, puertas lógicas empleadas…) como cualitativas (Ej. Claridad del código, sencillez del algoritmo, utilización de estándares…).