C√≥mo compartir datos listos para analizar

Seguro que hab√©is oido que el 80% del tiempo de un proyecto de datos se dedica a organizar y limpiar los datos, y el resto a analizarlos, ¬Ņo era el 90%? Desde luego cualquiera que se haya puesto manos a la obra, habr√° experimentado que es una cantidad de tiempo no despreciable.

Lo que sigue es una serie de consejos que tienen como objetivo crear conjuntos de datos m√°s ordenados para facilitar la tarea del analista, y reducir, as√≠, el tiempo para obtener resultados. Son recomendaciones b√°sicas orientadas a datos estructurados (tablas) aunque algunas recomendaciones tambi√©n aplican a datos con texto libre. Si se te quedan cortas puedes encontrar √ļtil otras gu√≠as m√°s avanzadas [1].

Tened en cuenta que muchas de las aplicaciones y lenguajes de programación han sido desarrollados con el idioma y la cultura anglosajona en mente, lo que hace que algunas de las recomendaciones pueden sonar un tanto peregrinas vistas desde la perspectiva latina.

Primeramente, incluyo un resumen con los puntos que hay comprobar antes de compartir un conjunto de datos, y seguidamente se desarrollan cada una de estos puntos.

Resumen

Si hubiera que resumir en un √ļnico consejo sobre c√≥mo organizar los datos ser√≠a:

Sigue tu corazón pero, por favor, sé consistente en tus decisiones.

Además, antes de compartir el conjunto de datos mi recomendación es que revises que cumplas los siguientes puntos:

  • Datos tabulares organizados en un fichero por cada tabla
  • Formato del archivo CSV (separado por , o por ;), o TSV (separado por tabuladores).
  • Nombre del archivo relevante.
  • Los datos en cada tabla tienen que cumplir:
    • Primera fila reservada para la cabecera.
    • Nombre de las variables relevantes sin incluir espacios.
    • Utilizar el punto como separador decimal.
    • No incluir el separador de miles.
    • Los valores de las variables categ√≥ricas deber√≠an ser descriptivos.
    • Codificar correctamente los valores perdidos.
    • Utilizar una representaci√≥n los m√°s est√°ndar posible para codificar fechas (YYYY-MM-DD) y horas (hh:mm:ss).
  • Codificaci√≥n del texto UTF-8.
  • Documentaci√≥n del conjunto de datos.
  • No incluir informaci√≥n que pueda identificar personas directa o indirectamente.

1. Organización del conjunto del datos

Las tablas son la manera más habitual de organizar datos estructurados. Una tabla es una estructura en dos dimensiones que se compone de filas y columnas. Cada fila se corresponde con una observación, y cada columna con los valores de distintas variables relativas a esa observación. Si tuvierais conjuntos de observaciones distintas tendrían que organizarse en tablas separadas y almacenarlas en un fichero por cada tabla. Esto es lo que se conoce como tidydata [2].

1.1 El formato de archivo más recomendable para compartir tablas es CSV (Comma-Separated Value). Los separadores de campos deberían ser , o ;

Ejemplo de archivo CSV

Altura,Peso,Genero
1.65,59,F
1.80,85,M
1.72,95,M
1.83,68,F
1.66,70,M

Una alternativa muy interesante es el formato TSV (Tab-Separated Value) que emplea el tabulador como separador.

Si no es posible obtener un archivo en CSV √≥ TSV, y dado su enorme popularidad, otra alternativa son los formatos nativos de Excel, XLSX, o XLS. En este caso, es imporante que se incluya una √ļnica hoja por archivo, y no se a√Īada informaci√≥n de formato (por ejemplo, no incluir colores, o formatos condicionales) ni f√≥rmulas. √önicamente el puro dato siguiendo las indicaciones de esta gu√≠a.

También se puede compartir un enlace a una hoja de cálculo en Google Drive.

En el caso de que los datos no estructurados (texto libre) o con una estructura compleja, los formatos preferidos son JSON y XML.

Si el archivo es pesado, hay que comprimirlo en formato ZIP, y si fuera muy pesado separarlos en¬† m√ļltiples archivos. Evitar utilizar otras extensiones como RAR.

1.2 El nombre del archivo del conjunto de datos deber√≠a ser un resumen relevante¬†de su contenido. No incluyais espacios dentro del mismo, acentos, ni nuestra querida √Ī.

Ejemplo

2019-calificaciones-cienciadatos.csv

mejor que:

misdatos.csv

2. Organización de una tabla

Una serie de reglas b√°sicas que tiene que cumplir cada tabla que compartamos:

2.1 La primera fila se denomina cabecera, y se reserva para el nombre de las variables. Siempre se incluye la cabecera, y no se incluyen más filas antes de la cabecera (ni tan siquiera vacías), ni al final de los datos. La cabecera tiene que comenzar en la primera columna, es decir, no dejar columnas vacias a la izquierda de la primera variable.

En el ejemplo anterior la cabecera es:

Altura,Peso,Genero

Un ejemplo incorrecto de archivo sería:

1.65,59,F
1.80,85,M
1.72,95,M
1.83,68,F
1.66,70,M

ya que no tiene la cabecera.

Tampoco sería válido:

Archivo que incluye distintas medidas de peso y altura 
Altura,Peso,Genero
1.65,59,F
1.80,85,M
1.72,95,M
1.83,68,F
1.66,70,M

ya que incluye una primera línea antes de la cabecera.

El siguiente ejemplo también es incorrecto debido a que aparecen filas adicionales después de los datos.

Altura,Peso,Genero
1.65,59,F
1.80,85,M
1.72,95,M
1.83,68,F
1.66,70,M
Media=1.74,Media=75.4
F=2, M=3

2.2 El nombre de las variables tiene que ser descriptivo, sin incluir espacios, y empleando √ļnicamente caracteres anglosajones (sin acentos, ni √Ī).

Ejemplos v√°lidos

RentaPerCapita, Rentapercapita, RENTAPERCAPITA, Renta_per_capita

mientras que habría que evitar:

Renta per capita, Renta, RPC

El primer ejemplo incluye espacios dentro del nombre de la variable. El segundo ejemplo es un nombre poco claro ya que no se sabe a qué tipo de renta se refiere. Si se utilizan siglas y abreviaturas, hay que asegurarse que son aceptadas y conocidas por la amplia mayoría de los usuarios del datos.

Eligamos nombres en inglés si nuestro conjunto de datos tienen vocación internacional.

2.3 Utilizar el punto (.) como¬†separador decimal. Este es un problema muy t√≠pico cuando se exportan datos de un programa como Excel y la configuraci√≥n del idioma est√° en Espa√Īol, ya que por defecto utiliza la coma como separador. Desde 2010, la RAE recomienda utilizar el punto en lugar de la coma con el fin de unificar criterios [3].

Así, el siguiente ejemplo sería incorrecto:

Altura,Peso,Genero
1,65;59;F
1,80;85;M
1,72;95;M
1,83;68;F
1,66;70;M

2.4 No incluir el separador de millares. Cuando escribimos un n√ļmero en un texto, habitualmente se separa en grupos de tres cifras para faciltar la lectura del mismo. En cambio, de cara al an√°lisis de datos este separador no tiene ninguna funci√≥n, es m√°s dificulta el an√°lisis independientemente del separador que se use (espacio en blanco, coma o punto) ya que hay que eliminarlo antes de poder utilizar el dato.

Por ejemplo, su en una celda el dato es cien mil, la √ļnica manera v√°lida de representarlo es:

100000

Por el contrario, las siguientes representaciones son incorrectas:

100 000
100,000
100.000

2.5 No incluir la unidades de medida en la misma celda que el dato. Es fundamental indicar las unidades de medida de cada variable (v√©ase el punto 4) pero nunca acompa√Īando al propio dato.

El siguiente ejemplo es incorrecto:

Altura,Peso,Genero
1.65 m,59 kg,F
1.80 m,85 kg,M
1.72 m,95 kg,M
1.83 m,68 kg,F
1.66 m,70 kg,M

2.7 Los valores de las variables categ√≥ricas deber√≠an ser descriptivos, y tener el mismo formato. Una variable categ√≥rica es aquella que puede tomar un n√ļmero limitado y fijo de valores como, por ejemplo, g√©nero, colores, o paises.

Las variables categóricas suelen ser fuente de errores, y hay que ser cuidadoso para asegurar que una  categoría no se representa con distintos valores.

Tres comprobaciones b√°sicas

  • Elegir nombres descriptivos de las categor√≠as. Si se emplean siglas o abreviaturas, tienen que ser ampliamente aceptados. Hay que evitar codificar con n√ļmeros estas variables, as√≠ mejor F y M, que 0 y 1.
  • Asegurarse que todos los valores se escriben con el mismo formato de min√ļsculas y may√ļsculas. Escogamos un formato (FEMENINO, femenino, √≥ Femenino), y mantengamos fiel a √©l en todas las variables categ√≥ricas.
  • Revisar que una misma categor√≠a no tiene distintos valores. La casu√≠stica es variada. Por ejemplo, puede ocurrir que se hayan cometido errores ortogr√°ficos (ej. femnino), que se hayan utilizado sin√≥nimos (ej. varon, masculino), que se hayan combinado nombres y abrevituras/siglas (ej. masc, masculino), m√ļltiples combinaciones de las anteriores, o nuevas alternativas que se me pasan.

El siguiente ejemplo contiene errores en la variable categoríca:

Altura,Peso,Genero
1.65,59,Femenino 
1.80,85,Masc 
1.72,95,Masculino 
1.83,68,Femenino 
1.66,70,Masclino

Cuando se establece un orden entre las categorías se denominan variables ordinales, como por ejemplo, intervalos en una medición (bajo, moderado, alto), calificaciones (suspenso, aprobado, notable sobresaliente), o medallas (oro, plata, bronce).

En este caso aplican las mismas reglas que hemos visto para las variables categ√≥ricas con la salvedad que algunas variables ordinales se representan correctamente con valores n√ļmericos. Por ejemplo, la posici√≥n en una competenci√≥n es mejor codificarla num√©ricamente (1, 2, 3…) que utilizar los cardinales (primero, segundo, tercero…).

2.8 Codificar correctamente los valores perdidos. Es posible que nos dispongamos datos de todas las observaciones, y que algunas celdas se nos hayan quedado vacias. Ahora bien, tambi√©n es com√ļn codificar estas celdas con alg√ļn valor num√©rico fuera del rango de posible valores en vez de dejarlas vac√≠as, por ejemplo, 0, -1o 999.¬† Esto puede llevar a dos errores:

  1. El valor empleado para codificar el perdido realmente también sea un valor válido, y estamos codificando dos informaciones distintas de la misma manera. Por ejemplo, en una variable como RentaPerCapitapuede pasar que el 0represente que la persona no haya querido revelar sus ingresos, o que no tenga ingresos.
  2. En el proceso de elaboración del conjunto de datos se comete un error, y se baila o se cambia una cifra del valor perdido, y se convierte en un valor válido, o viceversa.

El siguiente ejemplo ilustra este problema codificando los perdidos con 999:

Altura,Peso,Genero
1.65,59,F
999,85,M
1.72,99,M
1.83,999,F
1.66,70,M

En la tercera fila de datos, ¬Ņes el 99un valor v√°lido, o se han olvidado un 9al incluirlo?

Es preferible, dejar las celdas vacías, o utilizar una etiqueta como NA (Not Available) que identifique inequivocamente que es un valor perdido.

M√°s claro en el siguiente ejemplo:

Altura,Peso,Genero
1.65,59,F
NA,85,M
1.72,NA,M
1.83,NA,F
1.66,70,M

Y, por supuesto utilizar la misma manera de codificarlos en todas las variables.

2.9 Utilizar una representaci√≥n los m√°s est√°ndar posible para codificar fechas y horas. Existe un reportorio de formatos para representar fechas y horas que incluso llegan a dificultar muchas veces la propia comprensi√≥n del dato 03/11/1978¬† ¬Ņhace referencia al 3 de noviembre, o al 11 de marzo? Pues depende de la nacionalidad de a qui√©n le preguntes. Adem√°s, esta variedad incluye elegir entre distintos s√≠mbolos para separar los campos, sustituir los meses del a√Īo por su nombre o abreviaturas de los mismo.

Reglas b√°sicas

  • Como m√≠nimo, y no me cansar√© de decirlo, deber√≠amos ser coherente y emplear la misma representaci√≥n en todo el fichero.
  • Evitar utilizar los nombres de los meses ya que son dependientes del idioma.
  • Representar los a√Īos con cuatro cifras.
  • Restringuirse al gui√≥n (-) o la barra (/) como separadores.
  • Indicar en la documentaci√≥n cualquier particularidad que pudiera tener la representaci√≥n escogida. Por ejemplo, la posici√≥n de los d√≠as y de los meses.

El siguiente fichero incumple las reglas anteriores:

Altura,Peso,Genero,FechaNac
1.65,59,F,19 de marzo de 1982
1.80,85,M,3-11-1978 
1.72,95,M,18/Jan/1996
1.83,68,F,7/4/14
1.66,70,M,15 de Febrero, 2001

Idealmente deberíamos seguir el formato establecido en el estándar internacional ISO 8601 [4].

En esta representaci√≥n, las fechas se codifican como YYYY-MM-DD siendo YYYYel a√Īo entre 0000 y 9999, MM el mes entre 01 y 12, y DD el d√≠a entre 01 y 31.

Ejemplo, el 23 de marzo de 2019 sería:

2019-03-23

Podr√≠amos omitir el d√≠a, si quisieramos representar s√≥lo a√Īo y mes, y seguir√≠a siendo una fecha en formato v√°lido:

2019-03

Con las horas tenemos también nuestro quebraderos de cabeza aunque son menos frecuentes. Principalmente, hay que tener en cuenta que las horas siempre se representan bajo el sistema de 24 horas, nunca se emplea el sistema de 12 horas donde se divide el día en dos mitades mediante los marcadores AM (Ante Meridiem) y PM (Post Meridiem) para hacer referencia a la hora antes o después del mediodía.

En ISO 8601, la información horaria tiene el siguente formato hh:mm:ss siendo hhlas horas entre 00 y 23, mm los minutos entre 00 y 59, y ss los segundos entre 00 y 59.

Ejemplo

18:03:45

Si queremos representar informaci√≥n horaria en diferentes zonas horarias emplearemos el est√°ndar UTC (Coordinated Universal Time)¬† [5] que refleja la diferencia relativa respecto a la zona horaria de referencia (UTC¬Ī00:00, meridiano de Greenwich) [6].

Por ejemplo, M√©xico se encuentra oficialmente en UTC-06:00, es decir, seis horas menos que la zona horaria de referencia, mientras que la Espa√Īa peninsular se encuentra en UTC+01:00. Para a√Īadirle m√°s complejidad al tema, algunas paises cambian sus horarios en verano, cambiando en consencuencia su desplazamiento respecto a la hora de referencia que es fija. As√≠, M√©xico en verano se convierte en UTC-05:00, y la pen√≠nsula en UTC+02:00.

En ISO 8601, se representar√≠a la hora de la zona horaria de referencia (UTC¬Ī00:00) y el desplazamiento que hay que sumar o restar para obtener la hora local. El formato ser√≠a hh:mm:ss¬Īhh:mm. En el caso de la hora de referencia se sustituye el desplazamiento por una Z.

Ejemplo

Las diez y ocho (10:08) de la ma√Īana en UTC¬Ī00:00 ser√≠a en horario de inverno las 4:08 en Ciudad de M√©xico (UTC-6), y las 11:08 en Valencia (UTC+1). En formato ISO 8601:

10:08:00Z
10:08:00-06:00
10:08:00+01:00

Finalmente, indicar que se pueden combinar fechas y horas separ√°ndolas por una T.

Ejemplo

2019-03-23T18:03:45

3. Codificación del texto

La codificaci√≥n del archivo deber√≠a ser UTF-8. Existen m√ļltiples codificaciones que organizan la informaci√≥n de un archivo de manera distinta. Cuando se abre un archivo es preciso indicar la codificaci√≥n correcta, ya que en caso contrario ciertos caracteres, como las vocales acentuadas, o la √Ī pueden aparecer mal.¬† Este es un tema que trae muchos dolores de cabeza, ya que distintos programas guardan la informaci√≥n con distinta codificaci√≥n. Afortunadamente cada vez m√°s se tiende a que los archivos se distribuyan con esta codificaci√≥n.

4. Documentación

Es muy √ļtil incluir un archivo con informaci√≥n adicional que contenga la descripci√≥n y significado de cada variable. Este archivo deber√≠a contener, al menos, para cada variable: nombre,¬† tipo, unidades de medida, rango de valores permitidos, y descripci√≥n.

Un posible ejemplo de fichero de documentación:

Relación entre altura y peso por género
5 Observaciones, 3 Variables

RESUMEN:

Este conjunto de datos contiene medidas de la altura, peso, y 
genéro de cinco individuos (3 hombres y 2 mujeres).

FUENTE:

Las medidas fueron realizadas, inicialmente, por Pablo A. Haya a 
cuatro compa√Īeros ficticios de trabajo seleccionados al azar. 
Posteriormente, se a√Īadi√≥ una medida adicional de un compa√Īero 
ficticio igualmente seleccionado al azar.  

DESCRIPCI√ďN DE LAS VARIABLES:

Altura   (continua)   Altura del individuo en metros. 
Peso     (continua)   Peso del individuo en kilogramos. 
Genero   (categórica) M - Masculino o F - Femenino

FORMATO:

CSV separado por comas con valores perdidos codificados con NA

5. Datos de caracter personal

En ning√ļn caso, se debe incluir informaci√≥n de car√°cter personal (nombres, NIF, direcciones IP, cuentas de correo electr√≥nico, usuarios de redes sociales‚Ķ). La manera m√°s segura de proceder es eliminar los campos de car√°cter personal del conjunto de datos.

Si es necesario preservar las columnas, un primer paso es disociarlos, sustituyendo los datos personales por valores autogenerados, por ejemplo, cambiando los NIF por n√ļmeros aleatorios, o los nombres por nombres escogidos al azar de una lista.

Si tenemos variables tablas relacionadas por un dato de caracter personal (ej. NIF) es necesario preservar la coherencia entre ambas, de manera que en el proceso de disociacion el n√ļmero que escogamos para sustituir el NIF de un individuo sea el mismo en las dos tablas.

Hay que tener en cuenta que seg√ļn el Reglamento General de Protecci√≥n de Datos (RGPD) de la UE [7], dato personal es toda informaci√≥n sobre una persona f√≠sica identificada o identificable ya sea directa o indirectamente. Es posible que hayas eliminado todos los identificadores personales, y aun as√≠ sea posible inferir la identidad de una persona. Por ejemplo, a partir de las variables de nuestro ejemplo (Altura, Peso, Genero) podr√≠amos localizar un individuo concreto si conocieramos y tuvieramos bien acotada la poblaci√≥n de donde hemos seleccionado la muestra.

Con todo esto, si tienes en tu poder datos de caracter personal, lo primero que tendr√≠as que hacer es asegurarte que cumples con la RGPD, ya que, entre otras m√ļltiples consideraciones es preciso que dispongas del consentimiento expl√≠cito e informado de estas personas para disponer y tratar sus datos.

Referencias

1. How to share data with an statistician from Leek group guide to data sharing [Acceso: 2019-08-10] https://github.com/jtleek/datasharing

2. Tidy Data. Hadley Wickham [Acceso: 2019-08-10] http://vita.had.co.nz/papers/tidy-data.pdf

3. Ortograf√≠a de la lengua espa√Īola (Versi√≥n beta) de la Real Academia Espa√Īola y Asociaci√≥n de Academias de la Lengua Espa√Īola (2010). Edici√≥n en l√≠nea (www.rae.es). [Acceso: 2019-08-10] http://aplica.rae.es/orweb/cgi-bin/v.cgi?i=fuRhOImVQKYykcp,

4. ISO 8601 ¬ęElementos de datos y formatos de intercambio ‚ÄĒ Intercambio de informaci√≥n ‚ÄĒ Representaci√≥n de fechas y horas¬Ľ [Acceso: 2019-08-10] https://es.wikipedia.org/wiki/ISO_8601

5. Coordinated Universal Time from Wikipedia, the free encyclopedia [Acceso: 2019-08-10] https://en.wikipedia.org/wiki/Coordinated_Universal_Time

6. List of UTC time offsets from Wikipedia, the free encyclopedia [Acceso: 2019-08-10] https://en.wikipedia.org/wiki/List_of_UTC_time_offsets

7. Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE (Reglamento general de protección de datos) [Acceso: 2019-08-10] https://www.boe.es/buscar/doc.php?id=DOUE-L-2016-80807

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 d√©bil (weak): 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¬†Apache,¬†MIT¬†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 las 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 sino 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(s1);
gets(s2);

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

EntradaBuffer antesInstrucciónBuffer después
20\n20\nscanf("%d", &i1);\n
30\n\n30\nscanf("%d", &i2);\n
\n\ngets(s1); 
pablo\npablo\ngets(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.

Si quieres seguir aprendiendo C, te recomiendo el MOOC Introducción a la programación en C de la Universidad Autónoma de Madrid.

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.

Dise√Īo de la interacci√≥n

Transparencias (1MB aprox.) elaboradas sobre dise√Īo de la interacci√≥n por Pablo A. Haya y Estefan√≠a Mart√≠n. 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.