El Internet of Things o Internet de las cosas es una red de cosas conectadas: dispositivos, vehículos, edificios y otros objetos, que tienen en común tener una electrónica, software y sensores para intercambiar datos. El objetivo es hacer que todas esas cosas se comuniquen entre sí y, por consiguiente, sean más inteligentes e independientes. Para ello, es necesario el empleo de protocolos específicos y el desarrollo de numerosas tecnologías que actualmente están siendo diseñadas por las principales compañías del sector.
El Internet de las Cosas ha evolucionado tanto en los últimos años que prácticamente a día de hoy abarca cualquier campo de la vida que podamos imaginar... Por esta razón, en el Campus Tecnológico Virtual hemos querido incluir en nuestra oferta docente un curso sobre el Internet de las Cosas con el que aprenderás a desarrollar tus propios dispositivos para IoT.
En este curso...
- Entenderás los campos de aplicación del IoT.
- Identificarás la tecnología que lo compone.
- Desarrollarás arquitecturas de Internet de las Cosas.
- Programarás dispositivos IoT.
- Harás uso de plataformas web para generar servicios.
- Serás capaz de identificar los protocolos de comunicación necesarios.
Confiamos en que este curso dirigido tanto a aficionados y estudiantes como a quienes desean desarrollar actividad profesional con Internet de las Cosas pueda resultar muy útil y oportuno.
Más información: https://cursointernetdelascosas.es
Una vez has aprendido un lenguaje tienes facilidad para aprender
otros, sólo hay que fijarse en la sintaxis propia de cada lenguaje y
desde ahí construir un aprendizaje.
Mi consejo, en caso de empezar de cero y no querer acudir a uno de
los típicos programas enfocados a aprender a programar (Scratch, por
ejemplo), sería acudir a Python. Sus estructuras de código son sencillas
y eso acelera el aprendizaje. Además, se trata de un lenguaje
multipropósito que es usado en el ámbito profesional. Si la parte
gráfica es un problema podéis empezar con Python en Processing.
Lo importante es esforzarse en enseñar en profundidad y no en
extensión. No sirve de nada enseñar 5 o 6 lenguajes y no utilizar
ninguno realmente.
Bajo mi punto de vista trabajar de forma magistral con un grupo
amplio de personas que tienen delante un ordenador es un infierno. No le
desearía ni a mi peor enemigo tratar de avanzar al mismo ritmo con 30
alumnos adolescentes y una pantalla en sus manos. Es cierto que tiene
que existir una introducción guiada y algo más magistral, pero el error
está en centralizar esa introducción en una única persona y un único
tiempo.
Personalmente creo que deberían trabajar los alumnos de forma
individual, por parejas o en el peor de los casos por trios,
compartiendo un ordenador. Si no es posible hacerlo así el proceso se
dificulta bastante y habrá que pensar en un método que haga que todos
los alumnos tengan sus momentos de desempeño con el ordenador.
Mi consejo es que se trabaje por retos o pequeños proyectos tras una
primera fase de aprendizaje de las bases y aspectos relevantes. Para
ello prepararía un guión de unos primeros ejercicios explicando la base
en texto, vídeo o cualquier otro medio. Hay que conseguir que cada uno
de los alumnos o grupos puedan resolver sus dudas y avanzar a su ritmo.
Es un hecho que el medio educativo habla mucho de favorecer diferentes
ritmos de aprendizaje pero en este caso es indispensable.
Una posible forma de trabajar sería:
- Los grupos de trabajo tendrán un pequeño guión inicial a seguir
para entender los conceptos básicos. Digamos que sería como el tutorial
inicial de cualquier videojuego antes de lanzarse a la aventura.
- Tras completar el “entrenamiento” cada alumno o grupo tendrá una
serie de retos que tendrán que ir resolviendo a su ritmo. Desde el
principio se dejará claro que cantidad mínima de retos habrá que superar
pero no se pedirá un número a partir de ahí, sino que se buscará que
cada grupo avance a su ritmo.
- Lo idóneo sería que los retos tuviesen una resolución abierta, de
forma que cada grupo pueda acometer su resolución de diferentes maneras y
favorecer la riqueza de soluciones en el aula. Esto no quiere decir que
no se pueda permitir que todos lo hagan de la misma forma, sino que no
se enfoque a la solución directamente sino que se plantee un problema
que haya que resolver y el cómo hacerlo quede más a la elección de cada
alumno o grupo de trabajo.
- Los retos deberán pedir diferentes cosas, no siempre un script, de
forma que haya que ir presentando diferentes soluciones (un diagrama de
flujo, un programa comentado, un script…).
- Los alumnos deben tener una webgrafíadonde puedan acudir a
solucionar todos sus problemas, el profesor debe dejar de ser la figura a
la que acudir para resolver dudas. Es importante trabajar en ello y, al
principio, será un poco desastroso porque suelen estar muy
acostumbrados a preguntar sin pararse a intentar buscar la solución. Por
ello tenemos que recoger una serie de páginas con ayudas para el
lenguaje que elijamos, tutoriales de gente que enseñe cómo resolver
problemas, etc. En última instancia estará la búsqueda por internet para
intentar resolver un problema. De conseguirlo estarán aprendiendo mucho
más que a programar.
- Para evitar que pregunten por preguntar se puede dar una serie de
“créditos” a cada grupo y si te hacen una pregunta que está resuelta en
el material que les has entregado les quitas créditos por resolverla, y
si no les quedan créditos no pueden preguntar más. Evidentemente, si la
pregunta es inteligente, no está resuelta o es complicado que lo
consigan solos no tendremos que quitarle créditos. Una opción más
compleja sería que pusiesen un fundo por grupo de trabajo (algo
simbólico, un euro en monedas de 10 céntimos, por ejemplo) y que por
cada pregunta tengan que pagar una cantidad. Lo recopilado por preguntas
absurdas se puede destinar a material para el aula o algo así...
Es importante no centrarse en el acto en sí de programar sino
favorecer el aprendizaje de la utilidad de la programación. Por ello los
retos deben cumplir unos aspectos básicos para aprender a ubicar la
programación en un ámbito y no simplemente aprender a picar código.
Veamos algunos aspectos relevantes:
- Aprendizaje - servicio: los retos deben resolver alguna situación
que tenga sentido y utilidad. No tiene porqué ser algo social, puede
resolver cuestiones de ocio (por ejemplo una parte en concreto de un
videojuego que hay que programar), pero es importante que se plantee una
situación que entraña un problema a solucionar.
- La forma de presentar el reto debe ser variada. De esta forma se
acostumbrarán a tener que entrenar su capacidad de identificar un
problema que puede ser resuelto programando. Podemos plantear retos
escritos, retos en vídeo, un audio, un problema que se percibe en una
imagen, una mera idea expresada en modo esquema, un diagrama de flujo…
Una buena idea es indicar cada persona o grupo serán una empresa que
tiene que dar respuesta a peticiones comerciales, de esta forma la
manera de presentar los retos puede ser diversa y el cliente sólo
quedará satisfecho y si se le entrega lo que está pidiendo. Esta idea se
puede extender a la creación de un nombre y logo y realizar un blog
dando las respuestas…
- El enfoque debe ser neutro o compensado. La programación
actualmente tiene un marcado toque masculino y es importante buscar
retos compensados, que fomenten todos los intereses y no sólo se centren
en mundos tradicionalmente vinculados a los hombres (por ejemplo
siempre hablar de videojuegos, deportes y robots de combate hace que el
sector femenino pierda interés). Podemos plantear retos neutros y/o
retos más femeninos y más masculinos de forma compensada.
- Lo que se pide en el reto debe ser, así mismo, diverso. No siempre
habrá que programar sin más, en ocasiones se puede pedir que expliquen
una programación, que la comenten, que la corrijan, que la modifiquen
para usarla en otro ámbito o problema, que la esquematicen, que hagan un
diagrama de flujo, que terminen una programación ya iniciada, que
adivinen que quería hacer alguien que empezó un programa...
- Cuidado con los tiempos. Las clases tienen una duración reducida,
los retos no deben ser inabarcables, pues entonces estaríamos hablando
de proyectos y todo lo anterior no tendría sentido. Trabajando de forma
individual o por grupos pequeños los retos no deberían ocupar más de una
o dos clases.
- De cara a la evaluación: no trates de evaluar subjetivamente los retos, lo más sencillo es elaborar una serie pequeña de aspectos de la resolución del reto que se puedan evaluar con un simple correcto/incorrecto y con una nota asociada a cada uno de esos aspectos. Digamos que sería una rúbrica pero sin grados de consecución, simplemente o está o no está bien hecho. Los aspectos a evaluar pueden ser:
1- ¿Está resuelto?
2- ¿Entrega la solución en la forma que se pide?
3- La solución es idónea
Un reto puede estar resuelto pero no en la forma idónea y también
puede estar resuelto pero no presentar lo que estamos pidiendo (por
ejemplo un diagrama de flujo, o un programa sin comentarios cuando los
pedíamos). No tiene sentido enfrascarse en corregir y corregir, si los
alumnos resuelven unos 10 retos y de cada uno evaluamos dos o tres
aspectos estamos tomando bastantes notas y el resultado será bastante
fiel a cómo ha sido el proceso de aprendizaje.
Por último, hay que tener cuidado de que no copien las soluciones de
otros grupos, este aspecto es complejo, pero quizá aleatoriamente se
pueda preguntar a miembros de algún grupo sobre la resolución de un reto
que han presentado y si no saben explicarlo directamente no les cuenta o
algo así. Aun así, mi experiencia me ha demostrado que si están
motivados no quieren la solución de otros compañeros, quieren la suya.
A esto podemos sumar alguna pequeña prueba donde preguntemos aspectos
básicos o nos contesten a algunas cuestiones (un típico examen o test) o
la exposición de alguno de los retos frente al grupo…
Para la nota total podemos decidir que se empezará a evaluar a partir
de una cantidad de retos resueltos, los cuales tendrán una nota media y
el resto de retos extra que se hagan serán ponderadores de la media,
sumarán alguna cantidad o algo así. No es buena idea favorecer un ritmo
de aprendizaje diferenciado y evaluar con menos nota a los que trabajen a
un ritmo más lento por sus capacidades. Hay que premiar el esfuerzo, no
sólo el resultado. Con ello no quiero decir que tenga que tener un 10
el que no hace casi nada, simplemente habrá que poner una cantidad de
retos óptima como nota y el que trabaje más allá de eso podrá ir sumando
más nota. También podemos poner un baremador por tiempo, si entregas
más tarde de una fecha va bajando la nota que tendrá tu reto…
Como ves, elaborar tu propuesta de aula es complejo y seguramente las
primeras veces salga más bien regular. Es lo normal, todo proceso nuevo
conlleva un aprendizaje y hay que ir haciendo el medio idóneo para la
personalidad del docente, no todos podemos trabajar de la misma forma ni
tampoco es ello positivo para el alumno, la diversidad le enseña mucho
mejor cómo es el mundo en el que va a trabajar en el futuro.
Medio de trabajo
Me decanto claramente por Google Drive. Los alumnos pueden crear
cuentas (siempre informando a las familias, que tendrán que crearlas si
los alumnos son menores) y se puede compartir desde el docente una
carpeta a cada grupo y ahí pueden ir colgando sus retos. El entorno
Drive permite crear documentos, presentaciones, hojas de cálculo, subir
archivos .py, fotos, vídeos… De esta forma se puede trabajar muy bien
con ellos. Además, queda registro de los cambios y eso es bueno por si
deciden hacer cambios fuera de plazo o incluso fastidiarse entre ellos.
Hay una herramienta muy buena para “editar” código en un documento de
texto de google, se llama Code Pretty y te permite editar código si
está incluido en tablas dentro del documento.
Si hay algo que va a determinar cómo va a ser el proceso va a ser el
principio, las primeras clases. Es importante plantear unas primeras
sesiones motivadoras, que vinculen al alumno con lo que va a aprender,
si no el proceso será mucho más complicado. Una gran parte del éxito del
proceso viene determinado por la primera impresión que tenga el alumno
de lo que va a suceder en el aula en sus clases de programación. Por
ello sería muy bueno que al principio los alumnos viesen el potencial de
la programación, sintiesen ganas por empezar. Obviamente todos sabemos
que es complicado que una acción motivadora surta efecto en todos los
alumnos, pero cuanto más esfuerzo hagamos en motivar más fácil será el
camino posterior.
Intenta crear un medio en donde los alumnos aprendan cómo resolver
sus propias dudas, acudiendo a información o incluso a otros alumnos que
ya han logrado resolver esa duda.
Deja que aprendan a su ritmo, intentar que todos avancen al mismo tiempo y de la misma forma es garantía de fracaso.
No te atormentes con la evaluación tradicional, busca pequeños indicadores de consecución de objetivos y haz que la suma de muchos de ellos determinen la nota.
Alfredo Sánchez Sánchez
Graduado en Ingeniería de Edificación por la Universidad Politécnica de Madrid, máster del Profesorado en la Universidad Camilo José Cela. Ha trabajado en el departamento educativo de BQ. Actualmente es profesor de matemáticas y tecnología en ESO. Entusiasta de la pedagogía y el mundo maker, intenta motivar el cambio en el sistema educativo.
Actualmente imparte un curso de programación para profesores de secundaria o bachillerato en el Campus Tecnológico Virtual: Curso Python