Posted on

Los ingenieros y Cervantes

Facebooktwitterredditpinterestlinkedinmail

Este año hemos conmemorado los 401 años de la muerte de Cervantes y Shakespeare. Qué mejor momento para escribir este tocho-post sobre la importancia de la capacidad de comunicación en la ingeniería (y en cualquier otra profesión).

[Traducción: empecé a escribir este post en 2016, y no he podido acabarlo hasta ahora 😉 ]

En mis asignaturas le doy mucha importancia a la correcta redacción de informes escritos; posiblemente mis alumnos dirán que soy un poquito jartible con el tema 🙂 Pero es que no es una neura mía: son muchas las asignaturas de diferentes programas universitarios españoles que recogen esta competencia, y lo mismo ocurre con las universidades extranjeras. ¿Por qué? Pues porque expresarse de forma adecuada, tanto oralmente como por escrito, es un requisito para muchos puestos: vuestro trabajo en el mundo real va a implicar, sí o sí, tener que redactar informes y/o hacer presentaciones orales (y lo digo por experiencia propia, que también he trabajado en la empresa privada).

Por eso, aquí os dejo algunas ideas sobre el tema que creo que os pueden ayudar.

  • La ortografía es importante. Sí, lo es, de verdad. Todos respetamos el lenguaje matemático y seguimos sus normas, así que con el idioma debe ocurrir lo mismo. Y, por favor, que a ninguno se le ocurra decirme eso de que yo es que soy de ciencias, que me pone de muy mal café, igual que cuando escucho a alguien que no se maneja con matemáticas básicas decir lo de yo es que soy de letras. Los de ciencias y los de letras somos todos universitarios y debemos tener unos conocimientos elementales de lengua y matemáticas. Ideas a tener en cuenta:
    • Confiar ciegamente en el corrector ortográfico del procesador de texto que uséis es la receta segura para obtener un documento con las tildes mal puestas. Caso típico que nos puede ocurrir a los de Informática: práctica y practica son términos perfectamente válidos, el corrector no os va a avisar, y vais a entregar un informe de laboratorio con un hermoso “en esta practica hemos abordado…”
    • La RAE es tu amiga, y su diccionario online más aún 🙂 También es útil consultar la web de Fundeu.
    • Faltas de ortografía son todas, no sólo las “gordas”: hay que tener cuidado con las tildes también.
    • Respecto al uso de la tilde en los pronombres interrogativos y exclamativos, os remito a este completísimo enlace de Gabriella Literaria, donde se explica de forma clara y sencilla cómo deben acentuarse esos pronombres (nota: al final de ese post encontraréis la gloriosa regla cani que nunca falla ;))
    • También os recomiendo 70 trucos para sacarle brillo a tu novela: corrección básica para escritores, de la misma autora. La primera parte del libro se dedica a cuestiones de escritura general que nos vienen muy bien a todos.
  • Antes de entregar cualquier trabajo hay que leerlo. Parece un consejo del Capitán Obvio, pero es así.
    • Si es posible, además, es mejor leerlo en papel: las erratas destacan más, y es más fácil entender la estructura que hemos querido dar al texto (Mabbett I. W. (2007) “Writing History Essays. A Student’s Guide”, Palgrave MacMillan.)
    • Si es posible, es mejor dejar reposar el texto unos días y retomarlo después: veréis cómo aparecen (nuevas) erratas, y seguramente se os ocurrirán mejores formas de estructurarlo.
    • Si es posible, es conveniente que lo lea otra persona, aunque no tenga conocimientos técnicos: os puede decir si entiende lo que habéis escrito o no, y seguro que además os encuentra varias erratas (sí, otra vez).
  • Redactar no es lo mismo que hablar. Cuando hablamos, nuestro lenguaje corporal, expresiones faciales y entonación aportan información que no se percibe en un texto escrito. Además, el contexto es importante: en clase y en el laboratorio empleamos (todos, yo la primera) un lenguaje muchas veces informal, porque lo que nos interesa es entendernos en ese momento. Pero esa informalidad no puede trasladarse a un documento, mucho menos si es técnico:
    • No es nada conveniente incluir expresiones coloquiales. Si creéis que es imprescindible para explicar algo (aunque sería raro), entrecomilladlas.
    • Hay que vigilar mucho que usamos el lenguaje propio de nuestro campo de conocimiento. Por ejemplo, los alumnos de Informática debéis tener claro qué significan y cómo se usan conceptos básicos como variable, constante, tipo, algoritmo:

– “Realizar código”: no, el código se escribe o se implanta.
– “expresión matemática” no es lo mismo que algoritmo.
– “nº en positivo”: nº positivo.

  • Antes de escribir siempre es conveniente hacer un pequeño esquema con papel y lápiz (sí, esas herramientas analógicas tan obsoletas 😉 ). Ese esquema contendrá la estructura básica de apartados del documento, y las principales ideas que queráis contar en ellos. Es decir, primero hay que tener claro qué se quiere decir, y después ya se puede empezar a escribir.
  • La redacción debe ser lo más simple posible, sin sobrecargar el texto con explicaciones superfluas ni frases complejas (a mí, por ejemplo, esto me suele costar trabajo). Solución: primero redactas, y luego podas como si no hubiera un mañana.
  • Escribir bien es una habilidad que se va mejorando y puliendo con el tiempo, así que no hay que agobiarse inicialmente, sino aplicar estas ideas básicas. Y a partir de ahí, practicar, practicar y practicar.
  • Por si no lo he repetido lo suficiente a lo largo del texto, vuelvo a hacer hincapié: Murphy no descansa. Repasaréis diez mil veces el texto, lo dejaréis reposar, lo repasará alguien más… y una vez entregado, os daréis cuenta de que hay una errata. La probabilidad de que eso ocurra está muy próxima a 1. Pero, aun así, la diferencia entre un texto escrito a zorrombullón y un texto escrito con esmero y dedicación es enorme. Así que ya sabéis qué tenéis que hacer 🙂

[ACTUALIZACIÓN: Ya le he pillado al post una errata y una tilde mal puesta. Ains.]

Posted on

Let’s talk

Facebooktwitterredditpinterestlinkedinmail


[In English]

Aquí van algunos consejillos que suelo dar a mis alumnos cuando van a presentar sus TFGs/TFMs, aunque creo que pueden servir para cualquier presentación más o menos reglada que vayan a dar.  Disclaimer: están basados en mi experiencia a los dos lados de la tarima, es decir, como ponente y como oyente, y como es mi experiencia, no todo el mundo tiene que estar de acuerdo, así que al que no le gusten, que no los use 🙂

  • Ensáyala mucho (pero mucho, mucho) para ajustarte al tiempo que tienes, demo incluida. Cronométrate para estar seguro de que cumples el tiempo, y si tienes a alguien a mano para torturarlo y ensayar con público, mejor.
  • Recuerda que la presentación la tienes que hacer mirando al tribunal, no a la pantalla de proyección.
  • En la primera transparencia tienen que aparecer el título del TFG/TFM, titulación, autor, y directores.
  • La última transparencia puede ser igual que la primera, y así se queda como fondo elegante mientras el tribunal te pregunta.
  • Si el presidente del tribunal, al introducir el acto, lee en voz alta el título del TFG/TFM, tu nombre, etc. , no los repitas tú al empezar la exposición.
  • La presentación debe seguir el mismo orden de apartados de la memoria.
  • Procura que en las transparencias haya un índice visible en alguna parte (a la izquierda, o arriba del todo, pequeñito en ambos casos). Así el tribunal sabe en todo momento dónde está.
  • No cargues mucho de texto las transparencias; pon la información básica imprescindible (imágenes incluidas), y el resto lo dices de viva voz.
  • Sé astuto: para aquellos puntos que te resulten más complicados de memorizar o explicar, deja en la transparencia la información que te resulta difícil. Vamos, que la transparencia sea como una chuleta (negaré haber dicho esto ante un juez ;))
  • Cuidado con las animaciones, no se trata de que la presentación sea una feria que agobie al tribunal.
  • Transparencias con fondo claro y letras oscuras, o con fondo oscuro y letras claras: como prefieras. Ten en cuenta, de todas formas, dónde vas a leer (Sala de Grado, aula, etc.). Quizás sea más seguro usar la primera opción, que suele dar menos problemas en todas las situaciones.
  • Si durante la presentación muestras algún vídeo de los resultados de tu trabajo, debes hablar mientras se está reproduciendo, por ejemplo comentando aspectos importantes del mismo o cómo se corroboran los resultados teóricos alcanzados. Lo más importante es no quedarse callado mientras el vídeo está corriendo.
  • Es muy normal que el tribunal esté tomando notas mientras estés hablando. No te agobies pensando que están anotando fallos. Lo más normal es que estén recogiendo algunas dudas que les surjan durante tu exposición para acordarse de preguntártelas después (y posiblemente no te las pregunten todas). Y también puede ser que estén anotando las cosas que les han gustado para felicitarte por tu trabajo 🙂
  • Durante la presentación, si te pones nervioso (todos nos ponemos nerviosos, no pasa nada), ten a mano una botellita de agua. Si es botella grande, asegúrate de tener también un vaso.
  • Finaliza la presentación dando las gracias al tribunal e indicando que quedas a su disposición para el turno de preguntas.
  • Deja que los miembros del tribunal acaben de formular sus preguntas sin interrumpirlos (incluso aunque estés deseando contestar porque te requetesabes la respuesta :))
  • Lleva siempre una copia de seguridad de la presentación en un pendrive, porsiaca 🙂


[En español]

Here you can find some little tricks I usually give to my students when the moment comes to defend their Bachelor or Master thesis, though I think they could be useful in any formal presentation. Disclaimer: they are based on my experience on both sides of the story, that is, as speaker and as listener; since it is my own experience, not everybody will agree, so if you do not like them, simply do not use them 🙂

  • Rehearse a lot (I mean it, a lot), including a real demo of your work in case you also show it. Measure exactly how long it takes you to deliver the presentation; it would be great if you can find someone you can torture and rehearse with public.
  • Remember that you have to deliver your presentation looking at the committee, not to the projection screen.
  • The first slide should include the title of your Bachelor/Master thesis, the degree/master program, the author and the advisors.
  • The last slide could be exactly like the first one, so you have a nice background while the examiners ask their questions.
  • Your presentation should follow the same outline that the written dissertation report.
  • If the president of the committee reads aloud the title of your thesis, your name, etc. do not repeat them again when you begin to talk.
  • You should keep an index on the slides (tiny, on the left or at the top), so the committee can keep track of which point of your dissertation you are talking of.
  • Do not text-overload the slides; show only the basic essential information (including images), and explain the supplementary information aloud.
  • Be smart: those points of your presentation that are difficult to remember or explain should be written in your slides. To cut a long story short, the slides should be your cheat sheet (I will deny to have said this in a court ;))
  • Be careful with the animation of your slides: you don’t want to overwhelm the committee with a lot of special effects.
  • Design your slides with light background and dark fonts, or dark background and light fonts, as you wish. Anyway, you should consider the location where you are going to deliver your presentation. Maybe it is safer to choose the first option, that usually adapts to the lightning conditions of every place.
  • If you include a video showing the results of your work, you should talk while the video is playing; for example, you can comment the most relevant points of the video, or how your theoretical results are confirmed. The key point is not to be in silence while the video is still playing.
  • It is quite common that the committee jots some things down while you are talking. Do not get stressed thinking that they are recording your fails. They usually are gathering some notes about the doubts that arise during your dissertation, so they can remember them properly (and perhaps they do not ask all of those doubts). They also could be writing down those things they have liked the most of your work, so they can congratulate you for your achievements 🙂
  • If you are nervous during dissertation (it’s ok, we all get nervous in those situations), get a little bottle of water. If it is a big one, it is fine too, just use also a glass to drink.
  • End your dissertation saying thank you to the committee and saying that you are ready for the questions they might ask you.
  • Do not interrupt the committee members when they are asking you a question (even though you are willing to answer because you are going to nail it :))
  • Always have a backup of the presentation in a pendrive, you know, just in case 🙂
Posted on

Scorbot days

Facebooktwitterredditpinterestlinkedinmail

Siento no aparecer mucho por aquí… clases, clases everywhere 🙂 Para compensar, este es el vídeo que he preparado para la práctica basada en Scorbot de la asignatura Programación de Robots.

I’m afraid I’m not writing too much lately … teaching, teaching everywhere 🙂 To compensate, here is the video I have prepared for the Scorbot-based lab session of our robot programming course.

Posted on

R + Arduino + ROS + ultrasonic sensor HC-SR04

Facebooktwitterredditpinterestlinkedinmail

Con el objetivo de ilustrar el uso de frameworks robóticos de programación en la asignatura “Programación de Robots”, y aprovechando el trabajo previo que comenté aquí, este curso voy a incluir un ejercicio de clase que consiste en que un sónar HC-SR04 conectado a un Arduino envíe las medidas de distancia a un nodo ROS que mueve la tortuguita en función de la cercanía a los obstáculos, y además las distancias se leen y representan gráficamente usando R. Espero que a mis alumnos les guste 🙂

In order to explain how to use robotic frameworks in a “Robot Programming” course, and reusing the previous work I commented here, I have prepared a class exercise where an ultrasonic sensor HC-SR04 connected to an Arduino sends distance measurements to a ROS node which moves the turtle according to how close the obstacles are detected, and also the distances are read and drawn using R. I hope my students enjoy it 🙂

ros1ros2

Posted on

R + Arduino + ROS

Facebooktwitterredditpinterestlinkedinmail


[In English]

Como ya comenté en un post anterior, es posible integrar Arduino dentro de ROS. Por otra parte, hay un paquete rosR muy interesante que permite crear scripts R trabajando también en ROS; la documentación del paquete es completa y cubre tanto la parte ROS como la parte R:

Combinando ambos paquetes se pueden hacer cosas majas. Por ejemplo, en el vídeo al final del post se muestra cómo un nodo ROS envía las lecturas de un sensor FSR conectado a un Arduino (Duemilanove, en este caso) por un topic al que está suscrito un script R que muestra un plot con esos valores sobre la marcha. El código del sketch y del script, basados en los ejemplos proporcionados en la documentación de ambos paquetes, están en mi Github.

En este caso, he usado la máquina virtual Nootrix con ROS indigo 32, ya que me resulta útil por motivos docentes. La misma combinación Arduino-R también funciona correctamente en un Xubuntu 14.04.3 de 64 bits con ROS indigo instalado.

Por probar, he compilado la versión 64 bits de rosR en un Ubuntu Mate 15 con ROS jade distribuido entre un portátil y el netbook del Turtlebot, y también funciona… ¡¡Turtlebot, R te espera :)!!


[En español]

As I commented in a previous post, it is possible to use Arduino with ROS. Furthermore, there is a very interesting rosR package that allows to build R scripts also in ROS; the documentation of this package is complete and covers the ROS point of view as well as the R perspective:

You can build nice things using both packages. For example, the video at the bottom of this post shows how a ROS node sends the readings of a FSR sensor connected to an Arduino (Duemilanove, in this case) through a topic; a R script which is subscribed to that topic plots those values on the fly. The code of the skecth and the script, based on the examples provided in the documentation of both packages, is in my Github.

You can see in the video that I use the Nootrix ROS indigo 32 virtual machine, since I find it useful due to teaching reasons. The same Arduino-R combination also works fine under a Xubuntu 14.04.3 64 bits with ROS indigo.

I tried to compile the rosR 64 bits version under Ubuntu Mate 15 with a ROS jade distributed between a desktop and the Turtlebot netbook, and it also works… Turtlebot, R is waiting for you 🙂

Posted on

WidowX + Arbotix + ROS Indigo

Facebooktwitterredditpinterestlinkedinmail


[In English]

Estamos trabajando con el brazo WidowX instalado en nuestro Turtlebot 2. El brazo utiliza los drivers de Arbotix para ROS Indigo. Estas son las diferencias encontradas con la documentación original de la web:

  • La instalación desde apt-get no funciona, ya que cuando se crea el paquete aparecen errores. Es mejor descargar los drivers desde el github de Vanadium. Si se va a escoger sólo una parte de los drivers, es necesario asegurarse que se bajan todos los paquetes ROS necesarios; por ejemplo, no debería faltar el paquete de mensajes de arbotix.
  • El código fuente se copia al directorio de trabajo de ROS (en mi caso, que uso el directorio típico creado por ROS, /home/catkin_ws/src). Luego se crea como cualquier otro paquete ROS usando catkin_make .
  • El paquete arbotix_python también presenta diferencias con la documentación de ROS. Una vez creado el paquete, en el directorio_de_trabajo/src/arbotix_python/bin aparecen tres ficheros: arbotix_driver, arbotix_gui (en lugar de controllerGUI.py) y arbotix_terminal (y no terminal.py)
    • arbotix_terminal debe lanzarse tal cual, es decir,  ejecutando  ./arbotix_terminal sin lanzar roscore.
    • arbotix_driver y arbotix_gui necesitan lanzarse en ROS, es decir, con roscore ejecutándose.
    • arbotix_gui, además, parece venir preparado para un modelo URDF/XACRO concreto que no encuentra, ya que al ejecutarlo no aparecen las articulaciones del brazo en el interfaz gráfico que se abre, y en la ventana de comandos se muestra el error No URDF defined, proceeding with defaults. Bicheando un poco en el código, he visto que arbotix_gui llama a la función getJointsFromURDF, que está en directorio_de_trabajo/src/arbotix_python/joints.py y que carga el parámetro robot_description con el modelo URDF que utilizará. He intentado modificar este parámetro robot_description con otro modelo llamando a rosparam set /directorio_del_modelo/modelo.xacro (roscore debe estar lanzado), pero, aunque getJointsFromURDF sí encuentra este nuevo modelo, el resto del código de la función no está, aparentemente, preparado para él, así que por ahora voy a dejarlo y a centrarme en la programación del brazo que realmente necesitamos.


[En español]

We are working with the WidowX arm set on our Turtlebot 2. This arm uses the Arbotix drivers for ROS Indigo.  These are the differences with the documentation in the web:

  • Installation from apt-get does not work: errors arise when the package is created. The best option is to download the drivers from the Vanadium repository at github. If you download just a subset of the drivers, make sure that you choose all the basic ROS packages; for example, don’t forget to download de arbotix messages package.
  • All the source code should be copied to the ROS workspace (for example, I use the default workspace created by ROS, so I put it into /home/catkin_ws/src). After that, the package is created like any other ROS package with catkin_make .
  • arbotix_python package has also differences with ROS documentation. Once the package is created, three files are stored in your_workspace/src/arbotix_python/bin folder: arbotix_driver, arbotix_gui (instead of controllerGUI.py) and arbotix_terminal (not terminal.py)
    • arbotix_terminal runs “stand alone”, i.e.,  calling to  ./arbotix_terminal without a launched roscore.
    • arbotix_driver and arbotix_gui must be run within ROS, i e., with a running roscore.
    • Furthermore, arbotix_gui waits for a specific URDF/XACRO model that cannot find: the gui does not open all the joints of the arm, and the command window shows error No URDF defined, proceeding with defaults. Tracing the code, I found that arbotix_gui calls to function getJointsFromURDF in your_workspace/src/arbotix_python/joints.py, which in turn loads the robot_description parameter, that stores the URDF model used by this function. I tried to set another model in this parameter, running  rosparam set /model_folder/model.xacro (roscore must be running), but, though getJointsFromURDF does find this new model, the rest of the code of this function is not prepared to work handle it, so by now I am going to skip this question and move to the programming of the arm that we really need.

 

Posted on

Android Studio + NDK + Windows 7

Facebooktwitterredditpinterestlinkedinmail


[In English]

Estos son los pasos necesarios para instalar Android Studio y NDK sobre Windows 7 (en colaboración con Juan Antonio Fernández Madrigal)

Consideraciones previas

  • No es posible instalarlo en una máquina virtual, ya que el emulador necesita para funcionar virtualización, no disponible dentro de una máquina virtual.
  • Hacen falta bastantes gigas de disco para instalarlo todo, así que hay que asegurarse de tener suficiente espacio.
  • Aquí pueden encontrarse tutoriales para aprender a programar con Android Studio.
  • Bibliografía disponible en Jábega (catálogo de la Biblioteca de la Universidad de Málaga)
    • El Gran libro de Android : [actualizado a la versión KitKat y Android L Preview] / Jesús Tomás Gironés
    • Building Android apps / Mike McGrath
    • Manual imprescindible de desarrollo de aplicaciones para Android. Edición 2015/ Joan Ribas Lequerica
    • Profesional Android open accesory programing with Arduino[Recurso electrónico]/ Andreas Göransson,
    • Android Studio application development [Recurso electrónico] / Belén Cruz Zapata.

Primer paso: instalación de Java

  1. Obtener de el Java jdk 8 (a partir del 7 ya vale), no el jre, que sólo es el entorno de ejecución. En Windows 7 simplemente se baja y ejecuta el instalador .exe. Después es necesario incluir manualmente el path de Java (y de su directorio bin) en la variable de entorno de Windows 7 Path; si alguien no encuentra el path de Java, puede buscar dónde se ha realizado la instalación en Java Mission Control, el programa de configuración de Java que se instala también.

Segundo paso: instalación de Android Studio 

  1. Descargar Android Studio Bundle de la web (para Windows es un ejecutable), ejecutar el .exe y aceptar todo en la Standard Installation.
  2. Una vez instalado, ejecutar Tools -> Android -> SDK Manager  y marcar para instalar las build-tools 21 y la API 21. También es necesario instalar Froyo (2.2. API 8). Esto puede tardar bastante, sobre todo por wifi.
  3. En Configure->Project Defaults->Project structure completar los paths del SDK y de Java. Volver hacia atrás y empezar un nuevo proyecto (Blank Activity) que use la API 8 (Froyo). En el desplegable del rendering de la aplicación, usar la 21 en vez de la 22.
  4. En File -> Settings -> Build, Execution, Deployment -> Build Tools -> Gradle, activar la casilla Offline work (si no, la compilación y ejecución son lentísimas). El problema de la lentitud de Android Studio en Windows 7 y esta solución se comentan en este enlace de Stackoverflow.
  5. En Tools -> Android -> AVD Manager añadir, al Nexus 5 API 22, un Samsung Galaxy con la cámara trasera emulada. Desactivar la opción Use Host GPU. Es especialmente lento el arranque la primera vez y cuando se crea una nueva aplicación y tiene que empezar el indexado.

Tercer paso: instalación de NDK

  1. Este paso es muy sencillo: en Tools ->  Android -> SDK Manager-> SDK Tools -> Android NDK

Desarrollo de aplicaciones


[En español]

These are the steps to follow in order to install Android Studio and NDK on Windows 7 (post written in collaboration with Juan Antonio Fernández Madrigal)

Preliminary requests

  • This software cannot be installed on a virtual machine, since the emulator requires virtualization tools, which are not available in a virtual machines.
  • Both programs are quite demanding in hard drive space: be sure you have enough before you begin the installation.
  • Here you can find several tutorials to learn how to program with Android Studio.
  • Brief list of suggested readings (all of them available at Jábega, the catalogue of the Library of Málaga University)
    • El Gran libro de Android : [actualizado a la versión KitKat y Android L Preview] / Jesús Tomás Gironés
    • Building Android apps / Mike McGrath
    • Manual imprescindible de desarrollo de aplicaciones para Android. Edición 2015/ Joan Ribas Lequerica
    • Profesional Android open accesory programing with Arduino [Recurso electrónico]/ Andreas Göransson,
    • Android Studio application development [Recurso electrónico] / Belén Cruz Zapata.

First step: installing Java

  1. Get Java jdk 8 (though it works from jdk 7); it is important to choose jdk and not jre (jre is just the running environment). For Windows 7 just download and run the .exe file. After that, you have to manually add the path (and its bin folder) to the Windows 7 environment variable Path; if you do not know which is that Java path, you can check it using Java Mission Control, the Java configuration application that has been installed along with Java.

Second step: installing Android Studio

  1. Download Android Studio Bundel from the web (for Windows is an executable file), run the .exe and accept every default option of the Standard Installation.
  2. After that, go to Tools -> Android -> SDK Manager and check for installing the build-tools 21 and API 21. You also have to install Froyo (2.2. API 8). This can take a long time, especially if you are connected through a wifi.
  3. Go to Configure->Project Defaults->Project structure and add the paths of the SDK and Java. Go back and start a new project (Blank Activity) with API 8 (Froyo).  Choose, in the dropdown control  for rendering, version 21 instead of 22.
  4. In File -> Settings -> Build, Execution, Deployment -> Build Tools -> Gradle, check the Offline work box (if not, compilation and execution are painfully slow). This issue about Android Studio being so slow under Windows 7 and its solution are explained in this link at Stackoverflow.
  5. Add, using Tools -> Android -> AVD Manager, a new Samsung Galaxy device with emulated back camera. Uncheck the box Use Host GPU. It is especially slow when you run the emulator for the first time, and when a new app is created and Android Studio has to index from scratch.

Third step: installing NDK

  1. This step is a piece of cake:Tools ->  Android -> SDK Manager-> SDK Tools -> Android NDK

Applications development

 

Posted on

Vuelta al cole / Back to school

Facebooktwitterredditpinterestlinkedinmail


[In English]

Para plantearme objetivos suelo tener dos momentos al año: el uno de Enero para los personales, y el inicio del curso académico para los profesionales. En ambos casos, muchos se repiten año tras año ;), pero aún así creo que es bueno pensar qué cosas se pueden mejorar, e intentarlo una y otra vez hasta lograrlo (espero).

Este verano he descubierto varios blogs dedicados a la labor docente universitaria. Aunque están orientados al ámbito anglosajón, diferente en muchos aspectos al español, me parece que se pueden sacar muy buenas ideas. En este post de Conditionally Accepted se pueden encontrar los enlaces a los demás; de todos ellos, me han gustado particularmente Get a Life, Ph. D. y Pearls of Wisdom de The Professor is in.

Mezclando ideas tomadas de ellos, y de lo aprendido en varios libros de productividad, mis objetivos para este curso son:

  • Eliminar de una vez por todas la multitarea, ya que los efectos sobre la concentración son muuuuuy malos 🙁
  • Revisar el correo en momentos concretos del día y no conforme llega (me va a costar trabajo).
  • Ésta no la he probado aún: escribir todos los días (artículos, blog, lo que sea) y mantener el hábito.
  • No dispersarme, escogiendo uno/dos temas de docencia, investigación y formación. Esta me va a costar muchíiiiiiisimo: me gustan muchas cosas, y hay mucho libro y blog y curso chulísimo suelto por ahí 😉

Para los que estén interesados en cuestiones de productividad, es muy fácil encontrar libros y blogs sobre el tema. Si alguien extremadamente productivo quiere ahorrarse la lectura :), aquí van los tres trucos básicos que aparecen en todas esas referencias: ejercicio, buena alimentación, y dormir lo necesario. Es así y es verdad. A partir de ahí, ya pueden desarrollarse los demás; podéis encontrar muchos (y muy buenos) en este post de Gabriella Literaria.

Me gusta trabajar escuchando música, pero escogida con cuidadito porque, si no, me resulta imposible concentrarme. En esta entrada de Think Productive y en esta otra de Science Alert pueden encontrarse enlaces a música para mejorar la productividad. Con Noisli se pueden mezclar sonidos de la naturaleza a gusto de cada uno.

Bueno, eso es todo por ahora. Feliz vuelta al cole 😀


[En español]

I usually choose two moments every year for setting new goals: January 1st for personal goals, and the beginning of the academic year (September 1st in Spain) for professional ones. In both cases, many of these goals appear on my list year after year ;), but yet I believe that is a good idea to think about which aspects I could improve, and try and try again until (hopefully) I achieve them.

This summer I have found several blogs devoted to higher education teaching. Though they focus on the anglo saxon realm, which differs in many aspects to the Spanish system, I think that they offer very good ideas. In this post in Conditionally Accepted you can find the links to all those blogs; among them, I really like Get a Life, Ph. D. and Pearls of Wisdom in The Professor is in.

So, I have mixed some of those ideas and some tricks I have learned in several books about productivity, and these are my goals for this academic year:

  • Get rid, once and for all, of multitasking: it has a really really bad influence on concentration 🙁
  • Check the e-mail only at fixed moments of the day and not on the fly (I know this is going to be hard).
  • I have not tried this yet: write everyday (papers, blog, whatever) and keep the habit.
  • Do not disperse my attention. I will choose one/two issues on teaching, research and training. This one is going to be really hard: I like (almost) everything, and there are zillions of cool books and blogs and courses out there 😉

For the interested reader, it is really easy to find books and blogs about productivity. For the extremely productive reader who wants to spare the reading :), here you have the three basic tricks in all that literature: exercise, healthy food, and good sleep habits. Simple and true. From here on, you can develop any other productivity ideas; you can find a lot of (really good) examples in this post in Gabriella Literaria (in Spanish, but includes the link to the English original post by Niall Doherty).

I like listening to music while I work, but it has to be carefully chosen because, if not, I loose my focus. In this post in Think Productive and in this other in Science Alert you can find links to music for improving productivity. With Noisli you can mix and combine different sounds of nature as you like.

Well, that’s all for now. Happy back to school 😀