51 reglas para hacer investigación

Recientemente leí una lista con 51 reglas para hacer investigación y me gusto tanto que la voy a traducir y poner aquí.

  1. Sé libre
  2. Come dulces
  3. No vayas a las clases en la universidad, usa la universidad para imprimir de gratis
  4. Resiste la jerarquía académica
  5. No te creas todo lo que los profesores digan
  6. Duda, siempre
  7. No escribas proyectos de investigación
  8. Mantén las distancias con las personas que obtengan becas por escribir proyectos de investigación
  9. Haz caminatas periódicamente (de tres a cuatro veces al día)
  10. Gasta tu día de forma coherente
  11. Ten amigos
  12. Mantén amistades, y se mantenido por amistades.
  13. Ve al cine y mira películas
  14. Baila y ve a actuaciones de baile
  15. Hable y encuéntrate con artistas
  16. Habla con animales (y con plantas)
  17. Organiza fiestas
  18. Diviértete
  19. Disfruta: nunca dejes de lado el placer
  20. Ten una rutina
  21. Sé un espíritu amador, quiere y besa (si es preciso)
  22. Confía en tus propias habilidades
  23. Cuidado contigo mismo: se consciente de lo que dices
  24. Ama a tus intuiciones con todo tu corazón hasta que se demuestre lo contrario
  25. Date por vencido contigo mismo
  26. No esperes
  27. Se elegante
  28. Nunca (nunca!) abandones el estilo
  29. Se breve
  30. Mide las oportunidades.
  31. Se un rock star
  32. Rechaza categóricamente mediocridad
  33. Pasa tiempo con tus hijos
  34. Nutre tus sueños profesionalmente
  35. Duerme y échate la siesta
  36. Procrastina periódicamente como si no hubiera un mañana
  37. Date tiempo
  38. Lee otras cosas que no sean artículos científicos
  39. Lee más, escribe menos
  40. Lee distintos textos a la vez
  41. Escribe distintos textos a la vez
  42. Pausa tu escritura para que puedas escribir
  43. Escucha a la gente, observa a la gente, habla a la gente
  44. No reconozcas la autoridad
  45. Deniega categóricamente la autoridad
  46. Se absolutamente igualitario: no hagas compromisos con la equidad
  47. Prepárate para el cambio en tu mente mientras permanezcas independiente
  48. Nunca cedas independencia
  49. Embriágate (con poesía, palabras, vino)
  50. Desobedece
  51. Sé radicalmente libre

Resumen de la charla: Como escribir una publicación científica increíble por Simon Peyton Jones

Prof. Simon Peyton Jones expone siete puntos que – en base su opinión – una publicación científica debería seguir. El vídeo en si dura 30 minutos en los que repasa los puntos más importantes a seguir al publicar un manuscrito. Prof Jones recomienda que se empiece a escribir el manuscrito antes de empezar a investigar. Durante la escritura intenta ser simple – pero no simplista – y entendible. Sigue una estructura lógica y “reparte amor”. Os dejo el vídeo al final del post. El vídeo está en ingles pero es muy recomendable.

La primera idea que expone es que normalmente cuando tenemos una idea, empezamos a investigar y cuando tenemos suficiente material condensamos los resultados en un paper. Basado en la experiencia de Simon lo que tendríamos que hacer es tener la idea, pero luego empezar a escribir y después a investigar y pulir el texto con los resultados.

Porque tenemos que empezar a escribir después de la concepción de la idea y no investigar? Si empezamos a investigar nos desviamos del objetivo. Al empezar a escribir y exponer el proceso dejamos constancia de los pasos a seguir para llegar al objetivo, plasmamos las ideas que tenemos para el proyecto, nos fuerza a focalizarnos evitando que divagamos con sub-proyectos que nos lleven a ningún sitio. La escritura nos ayuda a desarrollar la literatura y evitar que la idea ya este publicada. También nos ayuda a pensar profundamente en el proyecto, ya no es sólo una idea que puede funcionar. Ahora ya es una idea en la que le estamos poniendo foco y pensamientos, para concretar y delinear el ámbito

Al empezar a escribir tenemos que tener algo muy claro en mente. Tenemos que pensar que al escribir un paper no lo hacemos para nosotros mismos, escribimos papers para los demás. Con los papers pretendemos comunicar conocimientos a otras personas. Queremos transmitir la idea que tenemos en nuestra mente a otras mentes. Para transferir conocimiento satisfactoriamente, el articulo científico tiene que ser entendible para terceros. El “yo ya me entiendo” no vale. La idea básica tiene que ser fácimente asimilable. Declara el concepto del paper abiertamente y de forma directa, no esperes que tus lectores tengan que hacer trabajo de detective para averiguar que conocimientos quieres transmitir. Si tienes más de una idea no intentes ponerlas juntas en el mismo paper. Sepáralas en distintos papers. Obviamente tampoco pretendas dividir una idea en mini-ideas para que puedas publicar miles de papers a la vez. Intenta que la idea de un paper tenga suficiente consistencia pero sin intentar comprimir demasiada información a la vez.

Cuando expongas una idea en un paper hazlo de una forma fácilmente entendible. Hazlo del mismo modo que lo harías en frente de una audiencia. Empieza describiendo tu problema, porque es interesante, porque no esta solventado, expón tu idea, explica porque funciona (con explicaciones y información), y termina comparando tu solución con otras soluciones. Estos pasos se traducen a un esqueleto muy claro que el manuscrito va a seguir.

  1. Título
  2. Abstracto (4 frases)
  3. Introducción (1pag): Aquí vas a describir el problema y exponer las contribuciones que haces a la humanidad. Cuando expongas el problema que no te de pereza a personalizarlo con un ejemplo ficticio. Escribe las contribuciones temprano y re-escríbelas después. Ponlo en formato de bullet points para facilitar el escaneo y dejarlas claras. Cuando escribas las contribuciones de este modo puedes añadir referencias a las secciones en las que solventas el problema. De este modo podrías enlazar tus contribuciones con las soluciones facilitando el lector la ubicación de lo que busque sin desperdiciar su tiempo ni hacer un párrafo aburrido como la lista de la compra.
  4. El problema (1pag)
  5. Mi idea (2pag)
  6. Los detalles (5pag)
  7. Trabajo relacionado (1-2pag) Referencia otros trabajos y compáralos con tus aportaciones. Simon recomienda ponerlo en una ubicación tan avanzada dentro del manuscrito porque de este modo ya habrás tenido tiempo para exponer teorías y conceptos para entender las diferencias. Esto también impedirá que el lector gaste energía y concentración leyendo algo que “no aporta” ya que no hace referencia a tu trabajo ni tus contribuciones de manera directa. Cuando el lector llegue a este punto, el apartado va a ser un tramite mas ya que tendrá construido los conocimientos para seguir el apartado sin mayor complicación.
  8. Conclusiones & trabajo futuro (0.5 pag) Este apartado es cortito. A nadie le interesa leer que quieres hacer mas adelante. Y la idea ya ha sido descrita. Así que este apartado es conciso.

Cuando compares tu trabajo con el de otras personas no uses la máxima: “para que tu trabajo se vea bien tienes que hacer que el trabajo de los demás parezca malo”. Aquí es dónde tienes que “repartir amor”. Repartir amor no va a hacer que tu trabajo se vea peor. Usa frases como “este paper me ha inspirado”, “este paper han tenido una idea muy buena”, “la implementación de este es impecable”, etc. Los autores de los otros papers lo agradecerán y a la larga crearás menos hostilidades. Al comparar describe también tus debilidades. Nada es perfecto. La implementación puede ser mucho mas rápida pero un poco menos precisa, quizás esta sea un sacrificio que muchos estén dispuestos a hacer. Además te elevara a los ojos de los revisores ya que no les parecerá que estas ocultando cosas.

Cuando expongas la idea empieza con la intuición, un problema especifico y luego expande hacia la generalización. Si empiezas con la generalización para empezar el lector va a tener más problemas para entender la idea.

Al exponer la solución no vayas diciendo probé esto pero no funciono, probé lo otro y no funciono. Esto no sirve de nada. La gente quiere saber que hiciste para solucionar el problema. En algunos casos se pueden incorporar al paper ideas que probaste y no funcionaron, pero con una finalidad. A veces algo que parece muy obvio de entrada puede no funcionar. Si este es el caso, para evitar que otros caigan en el mismo error o los revisores sugieran otra implementación puedes exponer algunas ideas fallidas. Pero nunca lo hagas de modo sistemático y mucho menos con todas las ideas frustradas.

Si el proceso te ha llevado hasta aquí ya tienes todo el paper escrito. Ahora va a tocar pulirlo. Para pulir el manuscrito tienes que pedir ayuda externa. Otro par de ojos a menudo ven cosas que no hemos visto. Pregunta a amigos que lean el paper y te den consejos. Ten en cuenta que por definición cualquier persona va a poder leer el paper por primera vez  solo una vez. No pidas a todos que lean tu paper a la vez. Pídeselo a uno escucha el feedback, corrige y así sucesivamente. Una vez han leído el paper ya van a tener la idea en mente y les va a ser más fácil entender el manuscrito que si lo leen por primera vez.

Cuando pidas a alguien que lea tu articulo especifica en que quieres que se concentren/focalicen. Si lo has terminado de escribir lo importante es que sea entendible, ameno y no se pierdan. Una vez tengas estos problemas solventados sera importante que no tengas errores ortográficos, que uses una buena gramática y seas más detallista.

Cuando alguin no entiende el paper no es su culpa! Importante cuando alguien te de feedback úsalo como oro. No son ellos que son tontos eres tu que no te has explicado adecuadamente. Es mejor que sean tus amigos quienes te digan que no lo han entendido y no que el journal te rechace el articulo. Y aun así, cuando el journal te rechaza el articulo, te va a dar feedback, úsalo! Cualquier pieza de feedback es valiosa para intentar mejorar y avanzar. No lo hacen para joder o porque son malos.

Para finalizar también puedes pedir feedback a personas que has referenciado en tu paper. No abuses de esta técnica. Pero puedes mandar un email a algún autor que no conoces y decirle que lo has referenciado y que si le importaría comentarte que les parece el articulo. Lo dicho no abuses y trata cualquier pieza de feedback como oro. Ya que te están dando algo que nadie puede comprar, tiempo.

Espero que te haya gustado. Si conoces otra charla igual de interesante sobre como escribir artículos o tienes algún otro consejo no te olvides de dejar un comentario!

 

 

SCORE: Usando metodologías ágiles para gestionar equipos de investigación

Con la introducción al agile creé el primer post de la serie, seguido de los post explicando las distintas facetas del Scrum (con los roles y el flujo de trabajo) hoy vengo con una aplicación directa para los equipos de investigación. Los grupos de investigación son grupos de gente que trabajan en el plano de las ideas. Al igual que los desarrolladores de software al final del día no crean ningún producto tangible solo ideas, información, conocimiento, pero nada que puedas tocar.

Hace ya bastantes años algunos de los grupos de investigadores de la universidad de Maryland (USA) decidieron implementar una nueva metodología para la supervisión de sus estudiantes, ya sean de grado, máster, doctorado o post-doc. Una metodología que se adaptara a las necesidades de cada individuo y no a las del título que ostentasen.

Esta implementación vino dada debido a la falta de tiempo que empezaban a sufrir los profesores. Con el incremento de estudiantes y responsabilidades cada vez tenían menos tiempo para dedicar a los estudiantes. Así que decidieron crear e implementar la metodología SCORE. Score proviene de SCrum fOr REsearch.

La idea principal consiste en reducir la carga de meetings a los que los miembros del grupo están sujetos sin comprometer la calidad del trabajo. Para conseguir optimizar el tiempo que pasan los profesores con sus alumnos crearon dos tipos de meetings. 15min meeting y los 1 on 1 meeting on demand.

  • Los 15min meetings tienen sitio tres veces por semana y como indica su nombre duran 15 minutos. Estos meetings, al igual que scrum, se hacen de pie para asegurar la brevedad de este. Durante este tiempo es requerido que todos los miembros del grupo acudan presencialmente y a modo excepcional lo hagan por videoconferencia. En el meeting todos los asistentes tienen que responder a tres preguntas:
    1. Que has hecho des de tu último meeting?
    2. Que problemas te has encontrado?
    3. Que quieres hacer para el próximo meeting?

    Al ser meetings tan frecuentes no pasa nada si algunas veces se responde que no ha habido resultados significativos.

  • El segundo tipo de meetings son los 1 on 1 meetings on demand. Que traducido sería meetings a título individual pero que se tiene que pedir cita. Con este tipo de meetings la idea es intentar reducir los meetings periódicos que solo roban tiempo. No siempre se requiere la misma duración para un meeting. Algunas veces los meetings precisan 15min y otras 2h porque la tarea es más compleja. Al pedir el meeting ya sabes de lo que se va a hablar y no va a ser una pérdida de tiempo.

Los estudiantes parecen bastante satisfechos con la nueva organización del laboratorio. Los profesores también parecen satisfechos con el resultado. Y a mi personalmente me parece interesante que hayan suprimido el meeting semanal que muchos grupos tienen en los que se presenta a lo grande.

 

Referencias:

Que flujo de trabajo tiene scrum?

Siguiendo los posts anteriores en los que hablaba a modo general de las metodologías ágiles, luego en específico de scrum, y de sus roles. Esta semana toca hablar del flujo de trabajo de scrum. El flujo de trabajo (el workflow) son los pasos que sistemáticamente siguen los integrantes del equipo. En el caso de Scrum se puede decir que hay dos grandes partes. El sprint y el scrum diario. El segundo se repite a diario, como el nombre indica, para avanzar a la compleción satisfactoria del primero, el sprint.

 

File:Scrum process.svg

Sprint

Un sprint o iteración es una unidad básica de de tiempo de desarrollo en Scrum. No confundir con los code-sprints, estos son eventos no recurrentes para colaborar intensamente en un periodo te tiempo concreto. Un sprint en scrum tiene una duración especifica, conocida de antemano. Normalmente los sprints duran dos semanas aunque las hay de un mes. La duración se mantiene constante en cada equipo y en teoría es optimizada para un mejor rendimiento adaptándose a las circunstáncialas.

Cada sprint se empieza definiendo la lista de tareas (sprint backlog). En el proceso de definición de tareas se estima el tiempo en el que un integrante del equipo tarda en realizar cada tarea y la carga de trabajo general para el equipo. Una vez los días han pasado y el sprint se ha terminado se hace una retrospectiva en la que se define que se entrega a los clientes y se analiza lo que se puede mejorar para las próximas iteraciones (sprints).

Scrum diario

El scrum diario es un meeting informal pero con unas reglas marcadas. Se empieza siempre a la misma hora (aunque falte gente), se hace de pie (para evitar que se alargue innecesariamente) y esta limitado a 15min. Durante este tiempo cada miembro del equipo tiene que responder a tres preguntas

  • Que hice ayer que ayude al equipo a alcanzar el objetivo del sprint?
  • Que voy a hacer hoy que ayude a alcanzar el objetivo del sprint?
  • Hay alguna cosa que dificulte a mi o al equipo la tarea de completar satisfactoriamente el sprint?

Una dificultad puede ser dependencias que van retrasadas, riesgos, una suposición incorrecta, etc.

 

Que roles tiene Scrum?

Ya llevo un par de posts explicando que son las metodologías ágiles y que es scrum en especifico. En esta entrada voy a exponer los distintos roles que tiene un equipo de scrum. Por el bien de la simplicidad Scrum solo considera tres roles.

Product owner (dueño de producto)

El dueño de producto representa a las partes interesadas (stakeholders = los clientes y consumidores principalmente). Su principal tarea es crear una hoja de ruta para que el equipo entregue el mayor valor posible. Es el encargado de diseñar el producto teniendo el cliente en mente. Diseña las historias de usuario (user stories), las pone en la cola de tares y las prioriza dependiendo en la importancia y sus interrelaciones. Este rol no se puede llevar a cabo conjuntamente con el de scrum master ya que el jefe de producto es el encargado de lidiar con los clientes mientas que el scrum master es el encargado de de decidir el camino para la implementación técnica. En resumen, el dueño de producto es el proxy entre los desarrolladores y los clientes, por lo tanto este rol requiere buenas habilidades de comunicación.

Desarrollador

Como ya indica el nombre, el desarrollador es el encargado de desarrollar el producto. Los desarrolladores son los encargados de implementar partes de producto en cada sprint que puedan ser entregadas al cliente. Como subcategorías encontraríamos los desarrolladores (máquinas biológicas que transforman café en lineas de código), los testers, arquitectos de software, analistas, diseñadores, etc.

Scrum master

Es principalmente el encargado de quitar los impedimentos que tengan los miembros de su equipo (los desarrolladores) al implementar el entregable. Es el encargado de facilitar los meetings, evitar distracciones, y asegurarse que se siguen las reglas acordadas para la metodología. También es el encargado de asegurarse de cumplir con las fechas de entrega y ayudar al equipo a mejorar y superarse día a día. Por decirlo de otro modo es el encargado de manejar el backend del equipo, manejarse internamente.

De que hablan los desarolladores cuando mencionan Scrum?

La semana pasada hablamos de metodologías ágiles como concepto general. Esta semana vamos a profundizar con Scrum, una metodología ágil entre muchas. El Scrum hace especial énfasis en el desarrollo de software para equipos (idealmente) de 3-9 desarrolladores (que curiosamente, o no, sigue la regla de las dos pizzas). Los equipos pequeños tienden a obtener una mejor productividad en general. Los meetings son más directos y requieren menos interacciones. Si cada miembro de un equipo tiene que mantenerse en contacto con los demás miembros el número de interacciones entre participantes se incrementa exponencialmente con el número de integrantes del grupo.

Los integrantes del grupo tienen un tiempo definido para finalizar las tareas asignadas. El tiempo asignado depende de cada equipo. Normalmente se sitúan en 15 días, aunque puede llegar hasta los 30. Estos intervalos de tiempo son comúnmente nombrados “sprints”. Pero para seguir la evolución de las tareas y re-planificar si es necesario, Scrum incorpora standup meetings. Estos meetings son reuniones diarias en las que la duración aproximada es de 15 minutos y se hacen de pie. Los standup meetings tienen el nombre en clave de scrum diario (daily scrum).

La idea principal de scrum se basa en la colaboración plena entre miembros del equipo para la construcción del producto, contrario a otras metodologías más tradicionales. Previamente cada individuo hacia su tarea asignada en base a los requerimientos hecho que incrementaba las probabilidades de fracaso estrepitosamente. Cualquier error de planificación o falta de detalle era pagado con creces ya que a menudo el proyecto tenía que ser desarrollado de nuevo y a menudo requería desechar buena parte del progreso. Lo que intenta hacer Scrum es evitar justamente todo esto. Scrum intenta adaptarse a los cambios con facilidad y poder desechar partes sin que el coste total del proyecto se incremente prohibitivamente.

Implícitamente Scrum reconoce que los clientes no saben lo que quieren y que sus necesidades evolucionan continuamente adaptándose a las nuevas tendencias. A menudo los cambios son impredecibles y consecuentemente imposibles de planificar. Con todo este en mente, Scrum crea un marco en el que la adaptabilidad permite responder a los cambios emergentes, nuevas tecnologías y cambios en el mercado.

 

Que son las metodologías de desarrollo ágiles?

Hace ya algunos años que las metodologías ágiles están de moda entre ingenieros, especialmente equipos de programadores. Muchos hablan Scrum, pero hay otras como XP (eXtrem Programming), kanban, V-model, waterfall model, modelo espiral, y un largo etc. Frecuentemente estas metodologías son usadas como onanismo teórico. Recursos humanos frecuentemente recurren a las palabras “trending” para atraer talento. Pero del dicho al hecho hay un trecho.

Los métodos agile de desarrollo de software se adaptan al proyecto. Los requerimientos y soluciones evolucionan gracias al esfuerzo colaborativo entre miembros del equipo interdisciplinar de desarrollo y el cliente. Su objetivo principal es la adaptación y flexibilidad para desarrollar soluciones, entregar productos antes de tiempo, y mejorar continuamente el producto. Para los que queráis leer más sobre los principios de los métodos ágiles lo podéis encontrar un manifesto online.

Ninguna de las metodologías es perfecta. Cada una tiene un foco especifico y un objetivo concreto. Cada uno de los marcos de desarrollo intenta solventar alguno de los problemas que los equipos tienen. Algunos con más éxito que otros, pero al final una parte importante del resultado depende de las personas. Cada empresa y cada equipo tiene su blueprint para enfrentarse a problemas. Por lo que cada equipo tiene que entender la metodología y adaptarla para mejorar el rendimiento y no al revés.

 

 

Un doctorado sirve para continuar en academia o salir para industria

Un doctorado o PhD en si tiene muchas finalidades. Para lo que sirve hacer un PhD depende de cada persona y las aspiraciones que tenga cada uno en la vida. Si te quieres dedicar a la investigación o ser profesor universitario es la única salida. Pero en algunas empresas tener un doctorado conlleva una serie de connotaciones (mayoritariamente positivas). Una persona que se ha sacado el doctorado es una persona que ha trabajado duramente durante un largo periodo de tiempo para conseguir profundizar en un tema extremadamente especifico. Po lo cual una persona que ha conseguido dicho nivel de especialización puede resultar altamente atractiva para empresas que busquen un perfil muy concreto.

La otra alternativa es que tengas empresas pretendientes gracias a las soft-skills adquiridas durante ese tiempo. Por ejemplo, las empresas alemanas valoran los doctorados para posiciones directivas. A los alemanes les gustan los doctorados en el management porque son personas que en teoría tienen una buena ética de trabajo. Durante el PhD los estudiantes han tenido la oportunidad de pensar, y planificar proyectos, gestionar estudiantes y aprender organización general. También han aprendido a comunicar conceptos no triviales de la mejor manera posible, organizar las ideas de forma lógica y adquirir conocimientos ajenos de manera rápida. Finalmente gracias al requisito general de publicar los resultados de la investigación, los doctorados han aprendido también a expresarse de forma escrita de manera concisa y directa.

11 comandos para data scientists que quieran aprender a usar la consola

Algunas veces manipular datos puede resultar costoso. A menudo los data scientists tenemos que manipular grandes cantidades de datos por lo que es bueno conocer algunos tranquillos para optimizar el proceso. Aquí os dejo unos cuantos comandos con algunas opciones para trabajar más eficientemente.

head

head archivo.txt

Este comando imprime las 10 primeras lineas del archivo. Si queremos un numero distinto de lineas podemos usar la opción -n.

head -n 20 archivo.txt

Este último comando nos imprimirá las 20 primeras lineas del archivo. Al imprimir las primeras lineas de un fichero en pantalla nos ayuda a obtener la estructura global del archivo y algunos valores para hacernos una idea general del contenido del archivo.

tr

Este comando es perfecto para pre-procesar archivos. Por ejemplo podemos cambiar el archivo de tsv a csv.

cat tab_delimited.txt | tr "\\t" "," comma_delimited.csv

Algo muy interesante de “tr” son las clases. Las clases son funciones de elementos algo más “abstractos”. Aquí una lista de algunos:

[:alnum:] todas las letras y dígitos
[:alpha:] todas las letras
[:blank:] todos los espacios
[:digit:] todos los dígitos
[:lower:] todas las letras minúsculas
[:upper:] todas las letras mayúsculas
[:punct:] todos los caracteres de puntuación

y si los concatenas puedes hacer un script bastante interesante. También puedes usar las expresiones regulares. Aquí ejemplo para pasar de mayúsculas a minúsculas

cat filename.csv | tr '[A-Z]' '[a-z]'

wc

Este es un contador de palabras (word count). Basado en mi experiencia uso la opción -l a menudo. Esta opción cuenta el número de lineas en vez de palabras. Otras opciones

  • wc -m imprimer el recuento de caracteres
  • wc -L imprime la longitud de la linea más larga
  • wc -w cuenta el numero de palabras
  • wc – l cuenta lineas

split

Nos permite trocear archivos fácilmente para reducir su tamaño. El problema es que no añade la extensión del fichero a los nuevos documentos. Podemos trocear un fichero cada 500 lineas con el siguiente comando.

split -l 500 fichero.csv nuevo_fichero_

Si queremos poner una extensión a los nuevos ficheros tendremos que usar el siguiente comando en el directorio del output

find . -type f -exec mv '{}' '{}'.csv \;

Si queremos numerar los archivos partidos tendremos que usar el flag -d para indicar que el sufijo sea numérico.

uniq

Uniq solo opera con lineas contiguas idénticas. Motivo por el cual es interesante añadir el sort antes. El sort nos pone lineas idénticas contiguamente.

sort

# Ordenando la segunda columna alfabéticamente
sort -t, -k2 filename.csv
# Numericamente 
sort -t, -k2n filename.csv
# Orden inverso 
sort -t, -k2nr filename.csv
  • sort -f ignora el caso
  • sort -r ordena inversamente
  • sort -k especifica el identificador
  • sort -t usa la coma como separador
  • sort -R mezcla el orden
  • uniq -c cuenta el numero de apariciones
  • uniq -d solo imprime las lineas duplicadas

cut

Sirve para eliminar ciertas columnas en el archivo. Por ejemplo si nos queremos quedar con la primera y tercera columna

cut -d, -f 1,3 filename.csv

Pero si queremos todas las columnas menos la primera

cut -d, -f 2- filename.csv

puede servir perfectamente con otros comandos.

paste

este comando puede ser interesante ya que pone juntamente dos archivos. No pone uno al final del siguiente sino cada fila de lado.

Si tenemos dos ficheros

# names.txt 
adam 
john 
zach

y

# jobs.txt 
lawyer 
youtuber 
developer

Los podemos juntar usando el comando

# Join the two into a CSV 
paste -d ',' names.txt jobs.txt > person_data.txt

Consiguiendo el resultado

# Output 
adam,lawyer 
john,youtuber 
zach,developer

grep

Este es uno de los comandos mas famosillos en el mundillo y extremadamente poderoso. Grep busca expresiones regulares y las imprime. Es usado a menudo juntamente con otros comandos.

# Buscar recursivamente nombres de ficheros que contengan la palabra "word"
grep -lr 'word' .

Algunas opciones interesantes

  • alias grep=”grep –color=auto” hace grep más colorido
  • grep -E usa la versión extendida de las expresiones regulares
  • grep -w busca un mach completo de la palabra
  • grep -l imprme el nombre de los ficheros conteniendo la palabra
  • grep -v invierte el match

sed

Este comando también es uno de los más potentes. Trabaja linea a linea. La función más básica es s/old/new/g . Podemos eliminar las comas de los miles en un fichero csv

sed -i '' 's/\([0-9]\),\([0-9]\)/\1\2/g' data.txt 
# balance,name 
# 1000,john 
# 2000,jack

o eliminar una linea especifica

sed -i '' '/jack/d' data.txt 
# balance,name 
# 1000,john

awk

Este también es un comando de los más usados y el último de hoy. Tiene bastantes de las funcionalidades de grep en su ultima versión.

awk '/word/' filename.csv

En el siguiente ejemplo awk imprime la 3a y 4a columna de las filas que contengan la palabra word.

awk -F, '/word/ { print $3 "\t" $4 }' filename.csv

Es capaz de usar múltiples expresiones numéricas

# Print line number and columns where column three greater 
# than 2005 and column five less than one thousand
awk -F, ' $3 >= 2005 && $5 <= 1000 { print NR, $0 } ' filename.csv

puede hacer un sumatorio de las columnas para las filas que cumplan cierta condición

awk -F, '$1 == "something" { x+=$3 } END { print x }' filename.csv

Puede imprimir filas duplicadas

awk -F, '++seen[$0] == 2' filename.csv

O borrar duplicados

# lineas consecutivas
awk 'a !~ $0; {a=$0}']
# Lineas no consecutivas
awk '! a[$0]++' filename.csv
# Más eficiente
awk '!($0 in a) {a[$0];print}

Substituir valores usando gsub

awk '{gsub(/scarlet|ruby|puce/, "red"); print}'

Fuente: https://www.kdnuggets.com/2018/06/command-line-tricks-data-scientists.html

Tim Minchin: Las 9 reglas por las que vivir

“Las 9 reglas por las que es la mejor charla que me he encontrado recientemente. Tim Minchin presenta en la ceremonia de graduación las 9 reglas que cualquier persona debería seguir para tener una vida más feliz. El ponente es un comediante y músico australiano y la charla es de lo más inconvencional que he escuchado recientemente. Si elegís escuchar el vídeo directamente (en ingles, al final del post) os puedo asegurar que van a ser los 7 minutos mejor invertidos que hayáis tenido en mucho tiempo. No es la charla típica de sigue tu pasión, es una charla que te abre de miras y te hace reflexionar sobre todos los consejos que recibes. Os dejo un resumen para la posteridad. Para los que queráis ver el vídeo directamente os lo dejo al final del post.

1. No tienes porque tener un sueño

Si siempre has tenido ese sueño ve a por ello. Si es suficientemente grande te costara toda la vida, y quizás al final de la vida ya no tendrá importancia. Lo que Tim recomienda es perseguir apasionadamente objetivos a corto plazo. Trabaja con orgullo en la tarea que tengas en frente. Nunca sabes donde te llevara el destino. Las oportunidades suelen pasar en la periferia de tu visión, por eso se tiene que ir con cuidado con los objetivos a largo plazo. Si estas demasiado concentrado en un objetivo distante, pierdes la noción de lo que pasa en tu alrededor.

2. No busques la felicidad

Cita: La felicidad es como un orgasmo, si piensas demasiado en ello desaparece. Céntrate en hacer a los demás felices y tu encontraras la felicidad como efecto secundario. Nuestros antepasados complacientes fueron comidos antes de tener descendencia, no evolucionamos para estar satisfechos continuamente.

3. Todo es suerte

Entender que tus éxitos no te pertenecen,  son un resultado de la suerte y que los fracasos de los demás no son culpa suya sino de la mala suerte. Entenderlo te hará mas humilde y compasivo. La empatía es algo que puedes trabajar.

4. Haz ejercicio

Aunque seas filosofo y trabajes en planos metafísicos vas a necesitar tu cuerpo. Cuida de él. El ejercicio te va ayudar a dormir, pero a mantener tu mente sana. El ejercicio te revitaliza y previene depresiones.

5. Ten fuertes convicciones

Cita: Las opiniones son como culos, todo el mundo tiene uno. Pero las opiniones tienen que ser constantemente y cuidadosamente examinadas. Tienes que pensar críticamente, no solo con las opiniones de los demás, pero también con las tuyas. Se intelectualmente riguroso. Identifica tus sesgos, preferencias, y privilegios.

6. Se un maestro

Los profesores son un elemento clave de este mundo. Comparte ideas, disfruta lo que aprendiste y difunde conocimiento.

7. Definete por lo que amas

Tenemos la tendencia en definirnos por nuestras oposiciones pero trata de expandir tu pasión por lo que amas. Se demostrativo y generoso con aquellos que admiras. Manda postales de agradecimiento y ofrece elogios.

8. Respeta a la gente con menos poder

Basa tus elecciones sobre con quienes colaborar basándote en como tratan las personas menos importantes que ellos. No importa tu rango.

9. No te apresures

No necesitas saber que harás el resto de tu vida. La vida es corta. También puede parecer larga y dura. Algunas veces estarás feliz, otras triste. Cita: Solo hay una cosa para hacer en esta existencia vacía: llenarla. La mejor forma de llenar la vida es aprendiendo tanto como puedas, enorgullociendote de lo que hagas, teniendo compasión, compartiendo ideas, corre, se entusiasta, viaja, bebe vino, ten sexo, crea arte, se generoso.