! Caliﬁcación · Álvaro Román Bengoechea, ETSIST, UPM Junio de 2015 Índice de ﬁguras Fig.1....

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA Y SISTEMAS DE TELECOMUNICACIÓN

PROYECTO FIN DE GRADO

TÍTULO: APLICACIÓN MÓVIL MULTIPLATAFORMA PARA EL APRENDIZAJE DE LENGUAJES DE PROGRAMACIÓN. CASO PRÁCTICO CON SWIFT

AUTOR: Álvaro Román Bengoechea

TITULACIÓN: Grado en Ingeniería TelemáIca

TUTOR: Antonio da Silva Fariña

DEPARTAMENTO: Departamento de Ingeniería TelemáIca y Electrónica

VºBº

Miembros del Tribunal Calificador:

PRESIDENTE: Juan Carlos González de Sande

VOCAL: Antonio da Silva Fariña

SECRETARIO: Ana Belén García Hernando

Fecha de lectura:

Calificación:

��

Álvaro Román Bengoechea, ETSIST, UPM Junio de 2015

Resumen

En este proyecto se ha estudiado el abanico de posibilidades que las plataformas web y

móviles ofrecen para aprender lenguajes de programación compilados. A continuación, se ha

realizado el diseño y la implementación de una plataforma para el aprendizaje de lenguajes de

programación desde dispositivos móviles, con posibilidad de compilación remota desde la

aplicación desarrollada, analizando el proceso y las elecciones de desarrollo tomadas. Así, se

ha desarrollado una app mediante la plataforma de desarrollo Cordova, que puede ser

distribuida para todas las plataformas móviles que esta soporta, incluyendo las más

populares: iOS y Android. Para la parte servidora se ha utilizado un servidor Apache (PHP) y

el sistema NoSQL MongoDB para la base de datos.

Para mayor facilidad en la gestión del contenido de la app, se ha desarrollado en paralelo un

gestor web de la base de datos, el cual permite añadir, editar y eliminar contenido de la misma

a través de una interfaz agradable y funcional.

�3


�4


Abstract

In this project I have studied the range of possibilities that web and mobile platforms offer to

learn compiled programming languages. Next, I have designed and implemented a platform

for learning programming languages from mobile devices, giving the possibility of remote

compilation within the developed application. In this terms, I have developed an app with the

Cordova development platform, which can be distributed for all the mobile platforms Cordova

supports, including the most popular ones: iOS and Android. For the server part, I have used

an Apache (PHP) server and the NoSQL database system MongoDB.

In order to offer a more usable system and a better database management, I have also

developed a web manager for the database, from which database content can be added, edited

and removed, through a clear and functional interface.

�5


�6


Glosario

DB : (DataBase) Base de datos

AJAX : (Asynchronous JavaScript And XML) Método de comunicación web por peticiones

HTTP asícronas.

HTML : (HyperText Markup Language) Lenguaje de marcado para la elaboración de páginas

web.

CSS : (Cascading Style Sheets) Lenguaje web para dar estilo a las páginas web.

JS : (Javascript) Lenguaje de programación web empleado en el lado cliente.

PHP : Lenguaje de programación web en el lado servidor.

API : (Application Programming Interface) Conjunto de funciones que ofrece un sistema o

biblioteca informática para que terceras partes hagan uso de las mismas.

MVC : (Model-‐View-‐Controller) Patrón de diseño de aplicaciones.

DOM : (Document Object Model) API web utilizada para la representación de documentos

HTML y XML, en forma de árbol que puede ser recorrido.

JSON : (JavaScript Object Notation) formato de presentacíon de datos utilizado en tecnologías

web.

BSON : (Binary JSON) Serialización binaria de un documento JSON.

SHA-‐1 : (Secure Hash Algorithm 1) Una de las funciones hash de la familia SHA.

SQL : (Structured Query Language) Lenguaje de acceso a bases de datos relacionales.

NoSQL : (Not only SQL) Sistemas de bases de datos no relacionales.

LMS : (Learning Management System) Sistema de gestión del aprendizaje.

SCORM : (Sharable Content Object Reference Model) Modelo de referencia de objetos de

contenido compartible.

�7


�8


Índice

Resumen 3 Abstract 5 Glosario 7 Índice 9 Índice de figuras 11 Introducción 13 Estado del arte 15

Codeschool 15 Tutorialspoint 17 Kodify 18 Swifty 19 LMS e interoperabilidad 20 Swift 22

Objetivo del trabajo 25 Desarrollo de la aplicación 27

Despliegue 27 Cliente 28

1. Introducción 28 2. Alternativas de desarrollo 28 3. Ionic y AngularJS 30 4. Funcionalidades, estructura de datos y diseño de la app 33 5. Estructura de archivos 40 6. Comunicación con el servidor 42

Servidor 43 1. Tecnología servidora 43 2. Base de datos 45

Manager 49 1. Introducción 49 2. Desarrollo 49 3. Diseño y vistas 52

Compilación remota 61

�9


Conclusiones y trabajo futuro 65 Trabajo futuro 66 Referencias 67 Anexo: Instalación del entorno de desarrollo 69 1. Ionic 69

npm 69 Ionic 70

2. MongoDB 74 Brew 74 MongoDB 74

�10


Índice de figuras

Fig.1. Página web de CodeSchool 16 Fig.2. Página web de TutorialsPoint 17 Fig.3. Kodify: app para móviles 18 Fig.4. Swifty: app para móviles 19 Fig.5. Diagrama de despliegue de CODEiT 27 Fig.6. Botones en Ionic 30 Fig.8. Vista de la sidebar de CODEiT 34 Fig.9. Vista de un lenguaje de CODEiT 34 Fig.10. Vista de una lección de CODEiT 35 Fig.11. Componente de texto de CODEiT 36 Fig.12. Componentes de imagen de CODEiT 37 Fig.13. Componente de ejemplo de código de CODEiT 38 Fig.14. Componente Playground de CODEiT 38 Fig.15. Componente botón de enlace a Playground de CODEiT 39 Fig.16. Interfaz de la aplicación Robomongo en Mac OSX 46 Fig.17. Tabla de peticiones de manager al servidor 51 Fig.18. Vista de lenguajes del manager de CODEiT con la barra lateral desplegada52Fig.19. Vista de lenguajes del manager de CODEiT 53 Fig.20. Vista de creación de un lenguaje del manager de CODEiT 53 Fig.21. Vista de edición de un lenguaje del manager de CODEi 54 Fig.22. Vista de eliminación de un lenguaje del manager de CODEiT 54 Fig.23. Vista de lecciones de un lenguaje del manager de CODEiT 55 Fig.24. Vista de creación de una lección del manager de CODEiT 55 Fig.25. Vista de edición de una lección del manager de CODEiT 56 Fig.26. Vista de eliminación de una lección del manager de CODEiT 56 Fig.27. Vista de capítulos de una lección del manager de CODEiT 57 Fig.28. Vista de creación de un capítulo del manager de CODEiT 57 Fig.29. Vista de creación de un capítulo del manager de CODEiT - Componentes de texto y código añadidos 58 Fig.30. Vista de edición de un capítulo del manager de CODEiT 58 Fig.31. Vista de eliminación de un capítulo del manager de CODEiT 59 Fig.32. Vista de opciones de usuario del manager de CODEiT 59 Fig.33. Vista de la miga de pan del manager de CODEiT 59

�11


Fig. 34. Instalación de npm en el Terminal de Mac OS X. 70 Fig. 35. Fin de la instalación de Ionic. 71 Fig. 36. Estructura de un proyecto Ionic en blanco. 72 Fig. 37. Ionic Creator. 73 Fig. 38. Ejecución del demonio mongod. 75

�12


Introducción

El mundo de las aplicaciones móviles o apps, como son conocidas, se ha convertido, para bien

o para mal, en una marea de software omnipresente en el mundo de la tecnología, que genera

millones de euros de bene]icio si se sabe jugar bien las cartas y se logra crear una necesidad

en un público concreto.

Tal ha sido la masi]icación de las apps, que una empresa no parece haberse subido al carro

tecnológico sin una página web y una app diseñadas a medida y con las últimas tendencias en

diseño grá]ico.

Por otro lado, las apps son una herramienta muy potente para profesores y estudiantes, sin

que estos roles vengan acompañados por un título para desempeñar dicha labor, simplemente

personas que desean transmitir conocimiento y personas que desean recibirlo. Gracias a estas

tecnologías y, en especial, a Internet, el aprendizaje de lenguajes de programación se ha hecho

más popular que hace unas décadas, cuando sólo los per]iles más técnicos contaban con los

conocimientos y herramientas necesarios para programar. Pero a pesar de esta serie de

ventajas tecnológicas que presenta nuestro tiempo, descubrimos con sorpresa que las pocas

apps de aprendizaje de lenguajes de programación cuentan con un diseño vago, poco claro y

obsoleto y que no permiten compilar y ejecutar nuestro código. Si bien es verdad que todo

programador acaba programando en un ordenador, también es cierto que cuesta más al

principio: cuando no se sabe nada. Y qué mejor que probar nuestro código según aprendemos

a programar; como casi todo en la vida, a programar se aprende programando.

Es por esto que, con los conocimientos adquiridos tras varios años de aprendizaje y de

descubrimiento de tecnologías y aplicación por separado de las mismas, me he propuesto

juntar las tecnologías aprendidas (cliente, servidor, web, transacciones y bases de datos) e

indagar en las soluciones más e]icaces y modernas para el desarrollo de aplicaciones móviles

para así crear una base para una aplicación que permita aprender lenguajes de programación,

potenciando el diseño grá]ico de la misma y la capacidad para compilar código.

�13


�14


Estado del arte

Las herramientas de aprendizaje online suponen importantes ventajas para el estudiante y

para el profesor con respecto al aprendizaje tradicional en soporte de papel. La interactividad

de los contenidos, la facilidad en el acceso, el alcance y , en muchas ocasiones, el precio, hacen

que estas herramientas de teleenseñanza hayan tenido un éxito abrumador y que hayan sido

capaces de desbancar a los medios tradicionales. [1]

No es de extrañar que, tras el boom de las aplicaciones para dispositivos móviles que hemos

experimentado en los últimos años, hayan aparecido numerosas apps para facilitar el

aprendizaje de un amplio abanico de disciplinas, entre ellas los lenguajes de programación.

De entre las aplicaciones web que podemos encontrar para el aprendizaje de un lenguaje de

programación, podemos distinguir dos grupos diferenciados: aquellas que simplemente

permiten conocer las características y la sintaxis del lenguaje que se desea aprender, con

textos, vídeos, imágenes y ejemplos de código; y aquellas que, además de proporcionar todo

esto, dan la posibilidad de compilar código de manera remota. Si bien las primeras son

comunes y fáciles de encontrar, las últimas no abundan tanto, puesto que requieren una

arquitectura software más compleja: necesitan un potente cliente y un back-‐end en la parte

servidora más avanzado. Tanto es así, que resulta muy complicado encontrar una aplicación

web con compilación remota y con una interfaz grá]ica de usuario que resulte atractiva,

funcional y que esté a la vanguardia en términos de diseño grá]ico.

De entre las aplicaciones web de aprendizaje de lenguajes de programación que podemos

encontrar, este estudio se va a centrar en aquellas que permitan aprender algún lenguaje

compilado, como Java, C, Objective-‐C o Swift y no así JavaScript, HTML o CSS. Llaman la

atención las siguientes:

Codeschool

Codeschool es sin duda la web de aprendizaje de lenguajes de programación más completa

que podemos encontrar y que además cuenta con un diseño muy atractivo y moderno. Todos

�15


sus cursos son en inglés y algunos parece que sí cuentan con compilación remota a primera

vista pero en seguida se puede reconocer que no es así, puesto que el código que tecleamos y

enviamos está sujeto a los patrones que establece cada lección y no se permite codi]icar

libremente. Además, en Codeschool sólo podemos encontrar un curso de un lenguaje

compilado: Objective-‐C y gran parte de las lecciones de los cursos son de pago. La gestión de

los cursos es interna y propietaria de la web.

Fig.1. Página web de CodeSchool

Codeschool cuenta con una app para móviles pero con funcionalidad restringida. A través de

ella sólo podremos acceder a las lecciones en vídeo de lo cursos que cuenten con dichos vídeo-‐

tutoriales.

�16


Tutorialspoint

Tutorialspoint ofrece una gran variedad de cursos online de programación de lenguajes

compilados: C, Java, Swift, C++, Objective-‐C, etc. Su grandes desventajas son el diseño,

sobrecargado, farragoso, anticuado y lleno de publicidad; el precio de algunos cursos, de entre

40 y 60 euros y que, aunque sí que cuenta con compilación remota, esta no es accesible de

forma intuitiva y rápida. Por otro lado, los cursos de programación básicos son gratuitos y

todos los cursos son en inglés.

Fig.2. Página web de TutorialsPoint

�17


Tutorialspoint también cuenta con una apeara dispositivos móviles, aunque esta no es más

que una encapsulación de la propia página web, sin contar con un diseño adaptado a

dispositivos de estas características.

En las tiendas de apps para smartphones también podemos encontrar aplicaciones para

aprender a codi]icar, si bien ninguna nos permite la compilación remota bajo una interfaz

adaptada al dispositivo destino. Aun así, cabe destacar algunas de estas apps:

Kodify

Kodify permite aprender a programar sin tener

ninguna noción previa de programación. Como

muchas otras apps y webs de este tipo, el lenguaje

que se aprende es Javascript, dada la simplicidad y

versatilidad del mismo. No posee funcionalidades de

compilación remota, pero sí que ofrece campos que

el estudiante puede rellenar o seleccionar dentro de

fragmentos de código. Esta es la manera

“interactiva” que tienen esta y las demás apps de

aprendizaje de programación para ofrecer

dinamismo y participación del estudiante en el

código. Un mecanismo que, en mi opinión, no

desarrolla las habilidades de programación del

estudiante, aunque sí que le ayuda a comprender

conceptos muy básicos.

Fig.3. Kodify: app para móviles

�18


Swifty

Para concluir, nos encontramos con Swifty en la App

Store. Swift nos ayudará a aprender el nuevo

lenguaje de programación de Apple: Swift, pero sin

posibilidad de compilar y ejecutar nuestro código.

Cuenta con el mencionado mecanismo de

interactividad de relleno de limitados campos

dentro de segmentos de código y sólo la primera

lección es gratuita. Se trata de la única app que

permite aprender este lenguaje en las tiendas de

apps a fecha actual.

Fig.4. Swifty: app para móviles

Bajo esta perspectiva de aplicaciones didácticas, resulta evidente concluir que no existe una

aplicación web y móvil que permita aprender lenguajes de programación compilados, que

permita compilar y ejecutar nuestro código de manera interactiva sin un entorno

extremadamente controlado y que cuente con un diseño a la vanguardia de las tendencias

grá]icas actuales.

�19


LMS e interoperabilidad

Los sistemas de gestión de aprendizaje, LMS, son sistemas basados en tecnologías web que

dan soporte al aprendizaje no presencial, aportando una serie de funcionalidades:

Control de acceso basado en roles y seguimiento del proceso de aprendizaje.

Gestión de los recursos de aprendizaje y actividades de formación.

Gestión de servicios de comunicación como videoconferencias, foros, sistemas de

mensajería, etc.

Realización de evaluaciones.

Generación de informes.

Estos sistemas han tenido un elevado grado de aceptación en los centros de enseñanza a lo

largo de los últimos años, convirtiéndose en fundamentales tanto para el profesorado como

para el alumnado, debido a facilidad en el acceso a los recursos y a la gran diversidad de

recursos de apoyo a la formación (cuestionarios, test, encuestas, subida de documentos,

noti]icación de eventos, mensajería, etc), todo ello gracias a las potentes tecnologías web

actuales.

Tales son las ventajas y el grado de aceptación, que no sólo los centros de estudios superiores

han implantado sistemas LMS, sino que muchos colegios se apoyan en estos sistemas y

plataformas para servir de apoyo a las lecciones presenciales, permitiendo el hasta hace unos

años vetado uso de dispositivos electrónicos en las aulas.

Por otro lado, una de las grandes desventajas de los sistemas LMS es la carencia de

interoperabilidad entre distintos sistemas, ya que cada sistema utiliza un formato propietario

de representación de los datos. Para solventar este problema, existe la norma SCORM

(Sharable Content Object Reference Model). Se trata de una norma que permite la importación

de contenidos creados en un determinado sistema en otros sistemas que también soporten la

norma SCORM. [10 y 11]

�20


En el caso de la Universidad Politécnica de Madrid, donde he cursado mis estudios

universitarios, el sistema implantado es la plataforma de telenseñanza Moodle, que

proporciona todas las funcionalidades mencionadas. De entre ellas, cabe destacar la

realización de exámenes desde la plataforma, en forma de test [2]. Esto se aplica en muchas de

las asignaturas de los grados de Telecomunicación del Campus Sur de la UPM, como Sistemas

de Transmisión o Procesado Digital de la Señal, donde se realizan tests de evaluación de cada

práctica de laboratorio, impulsando al alumno en el correcto progreso de su aprendizaje y

favoreciendo el a]ianzamiento de los conocimientos de cara al examen escrito [2 y 3].

Como ya se ha comentado, el objetivo de este trabajo está centrado en la investigación de la

capacidad de compilación remota de recortes de código proporcionados por el alumno a

través de la app para dispositivos móviles. Para ello, se usará como caso de estudio el lenguaje

Swift, del cual se analizarán los aspectos más interesantes a continuación.

�21


Swift

Para poner en marcha este primer prototipo de la app, se ha poblado la base de datos con

lecciones del lenguaje de programación Swift. Swift es el nuevo lenguaje de programación de

Apple, anunciado en 2014 y orientado a objetos, para la creación de aplicaciones para Mac OS

X y iOS, que permite utilizar librerías programadas en el lenguaje que se ha utilizado hasta

ahora en los entornos Apple: Objective-‐C y que también permite llamar a funciones de C.

El objetivo de esta sección no es la de realizar una guía de aprendizaje de Swift, pero sí resulta

interesante comentar algunas de las características más llamativas de este nuevo lenguaje de

programación: [4]

Los puntos y comas y los paréntesis son opcionales. No es necesario ]inalizar las

sentencias con punto y coma, a no ser que se quiera escribir otra sentencia a continuación

en la misma línea. Los paréntesis, por ejemplo, a la hora de escribir una sentencia if,

tampoco serían obligatorios, aportando una gran ]lexibilidad al escribir código.

La declaración de los tipos de las variables es opcional. No estamos obligados a

especi]icar el tipo de dato que va a almacenar una variable, puesto que el compilador sabrá

dicho tipo de dato con la primera asignación de la variable. Para declarar variables

utilizaremos el pre]ijo var y para constantes, let.

Comparador ternario (===, por ejemplo), para comparar direcciones de memoria,

mientras que el comparador clásico (==, por ejemplo) compara el contenido de la variable.

Rangos. En Swift existe la posibilidad de declarar un rango de valores, por ejemplo: 0..50.

Este rango comprende los valores entre 0 y 50, incluyendo ambos. Esta característica

resulta particularmente útil en bucles.

Estructuras (struct). De forma similar a C, las estructuras de datos juegan un papel

importante en Swift. Las estructuras no permiten herencia o contador de referencias para

la gestión de memoria, ya que siempre son pasadas por valor, es decir, son copiadas en

�22


memoria. Si deseamos todas estas características que no posee el struct, debemos utilizar

las clases convencionales.

Extensiones. Las extensiones de Swift nos permiten añadir funcionalidades a clases de

objetos, incluyendo las clases del propio lenguaje, como un entero (Int en Swift). Al añadir

una extensión a Int, por ejemplo, todos los Int declarados en la aplicación contarán con

dicha funcionalidad adicional.

Unicode. Swift nos permite utilizar cualquier caracter Unicode, tanto como contenido de

una variable, como para las de]iniciones de variables, funciones, etc. Esto incluye los

famosos emoticonos o emojis.

Swift es el fruto de un estudio de los lenguajes de programación de los últimos veinte años,

tomando características interesantes de muchos lenguajes, con una predominancia de C y

Objective-‐C, de los que evoluciona Swift. A continuación, vamos a analizar varias

características que Swift ha tomado prestadas de otros lenguajes de programación:

Diccionarios de JavaScript: Swift ha tomado los array con claves de cadenas de caracteres,

también conocidos como tablas hash, para incorporarlos bajo el nombre de diccionarios.

Tipos de datos inferidos: Como ya se ha mencionado, en Swift no es necesario ser explícito

con el tipo de dato que almacenará una variable. El propio compilador de Swift analiza y

determina el tipo de dato que una variable va a almacenar y nos indicará incompatibilidades.

Esta característica podemos observarla en lenguajes como Haskell, Opa, Scala o Microsoft .Net.

Declaraciones de tipos en estructuras de datos: Al igual que en C# y en Java, en Swift se

puede especi]icar el tipo de datos que almacenará una colección entre los símbolos < y >.

Generación de cadenas de caracteres: Swift nos permite insertar variables dentro de una

cadena de caracteres, dentro de los símbolos \( miVariable ). Esta es una práctica muy común

�23


que podemos ver en lenguajes como JSP y que resulta de gran utilidad dado el arduo trabajo

que puede suponer la generación y concatenación de strings y variables.

Puntos y coma opcionales: de igual manera que en JavaScript y Python.

Protocols: los protocolos en Swift tienen la misma función que las interfaces Java. Proveen

una estructura básica o patrón que han de implementar las clases que deseen proveer la

funcionalidad de la interfaz.

Tuplas: al igual que en los lenguajes Lisp y Python, Swift permite el uso de tuplas, es decir,

una serie de valores que son pasados al mismo tiempo y que son de gran utilidad cuando hay

que devolver más de un valor.

ARC (Automatic Reference Counting): es el equivalente al recolector de basura de Java, unas

rutinas que constantemente analizan la memoria para determinar qué bytes no están ya en

uso. Esta funcionalidad, que ya tenía Objective-‐C, podemos observarla en C# también.

Enteros con signo y sin él: muchos lenguajes han evitado esta complejidad a la hora de tratar

con enteros. Pero Swift, al igual que Objective-‐C o C#, ofrece enteros ]irmados y no ]irmados

de uno, dos, cuatro y hasta ocho bytes.

Closures: los closures son trozos de código que pueden pasarse como funciones, de igual

manera que en JavaScript.

�24


Objetivo del trabajo

Ante este panorama en el mundo de las aplicaciones, resulta muy atractiva la idea de

desarrollar un proyecto que permita al estudiante aprender, en cualquier lugar y mediante un

dispositivo móvil, lenguajes de programación. Y no sólo eso, sino que pueda ejecutar su código

a medida que aprende nuevos conceptos.

Además, tras la reciente llegada del nuevo lenguaje de programación de las plataformas de

Apple: Swift, parece el momento idóneo para utilizar este lenguaje como caso de desarrollo e

incorporarlo a este proyecto como primer lenguaje ofertado en la plataforma que se ha

desarrollado.

Así, los objetivos del proyecto son los siguientes:

Diseñar una base de datos que almacene los lenguajes de programación, junto con todas

sus lecciones, que se mostrarán al estudiante.

Diseñar una interfaz grá]ica de usuario agradable, limpia, sencilla, funcional y que siga las

tendencias actuales en diseño grá]ico.

Desarrollar una aplicación cliente para los principales sistemas operativos de dispositivos

móviles, iOS y Android, que permita el aprendizaje de lenguajes de programación.

Desarrollar una serie de componentes básicos que permitan realizar los objetivos

descritos más arriba (componentes de texto, ejemplos de código, zonas de edición de

código, etc)

Desarrollar una aplicación servidora que gestione y procese las peticiones de compilación

remota realizadas desde la aplicación cliente.

Diseñar y desarrollar una aplicación web para poder gestionar, de manera amigable, los

lenguajes de programación almacenados en la base de datos.

�25


�26


Desarrollo de la aplicación

Despliegue

Fig.5. Diagrama de despliegue de CODEiT

Como se observa en el esquema superior, el despliegue del sistema bautizado como CODEiT,

es relativamente sencillo. Se trata de un despliegue tradicional, con un único servidor

vinculado al dominio codeit.no-‐ip.org.

El servidor tendrá que ser un ordenador de Apple (Mac) puesto que ha de compilar código

escrito en Swift y sólo los Mac tienen esta capacidad. Además, cuenta con dos partes: un

servidor Apache y un sistema de base de datos MongoDB. Dentro del servidor Apache, se

pueden distinguir tres componentes: el de compilación, encargado de gestionar las peticiones

que requieran compilar, ejecutar código y devolver el resultado; el componente de conexión

con la base de datos mongo, que gestiona cualquier interacción necesaria con la base de datos

(lectura, inserción, actualización y eliminación de contenido); y el componente asociado al

gestor web de la base de datos, orientado a los profesores que desean añadir, modi]icar o

eliminar lenguajes y lecciones. Este último componente se encarga de generar las páginas web

para la parte de gestión de los lenguajes de programación y sus lecciones, así como de

gestionar las peticiones asíncronas (AJAX) que le lleguen de las mismas. Para ello, necesita

comunicarse con la base de datos a través del componente “DB”. El código de estos

componentes se ha desarrollado en php.

�27


Las peticiones que le llegan al servidor podrán haber sido lanzadas por el cliente móvil, tanto

iOS como Android, o por la web de gestión desde cualquier navegador.

Cliente

1. Introducción

La aplicación cliente de CODEiT es una aplicación diseñada para dispositivos móviles, que

permite el aprendizaje de lenguajes de programación no sólo interpretados, como es el caso

de la mayoría de los lenguajes orientados a la web: HTML, CSS, Javascript, PHP, etc, sino

también compilados, como Java, C, C++, Objective-‐C o Swift. En el caso de los lenguajes

compilados, la app adquiere un valor diferenciado que favorecerá considerablemente el uso de

la app y el aprendizaje por parte del alumno, ya que permite compilar y ejecutar código

escrito en la propia app por el estudiante en tiempo real. El estudiante visualizará los

resultados de la compilación/ejecución para así desarrollar habilidades con el lenguaje que

esté aprendiendo.

2. Alternativas de desarrollo

A la hora de comenzar a diseñar un producto software para dispositivos móviles, es decir, una

app, hay que tener en cuenta varias consideraciones. Si obviamos las consideraciones

monetarias que van ligadas a (casi) todo proyecto de software, las más importantes son el

tiempo de desarrollo del que se dispone y el número de desarrolladores con los que contará

proyecto. En el caso de este proyecto, tanto el tiempo de desarrollo como el número de

desarrolladores son bastante limitados. Por este motivo hay que analizar concienzudamente

las posibilidades de desarrollo de la app en cuestión, para seleccionar la que más se ajuste al

proyecto y así llegar a una ]inalización satisfactoria del mismo sin demasiados problemas ni

demoras.

Al tratarse de una app, se presentan dos vías de desarrollo muy diferenciadas:

�28


Un desarrollo nativo para una o varias plataformas. Este tipo de desarrollo está ligado a los

conocimientos que el desarrollador tenga de la plataforma, al lenguaje de desarrollo y al

alcance y conocimiento de las APIs que ofrezca la plataforma. Cuando se habla de

plataforma móvil se está re]iriendo a los entornos móviles iOS y Android. Estos entornos

son totalmente diferentes, tanto técnica como ]ilosó]icamente hablando. Me explico.

Técnicamente, estamos ante entornos opuestos. iOS está pensado para funcionar con un

hardware concreto, reduciendo así las probabilidades de fallos e incompatibilidades y

aumentando la ]luidez del software. Además, el software, tras ser debidamente compilado,

se ejecuta sobre el microprocesador directamente. En el caso de Android, el lenguaje

empleado es Java, que es ejecutado sobre una máquina virtual y esta es la que ejecuta

órdenes sobre el microprocesador. Esto supone una capa intermedia entre el código y el

microprocesador, añadiendo la ventaja (o desventaja, dependiendo del punto de vista) de

que puede ejecutarse sobre cualquier hardware, aunque el rendimiento, la usabilidad y la

sensación por parte del usuario no sean óptimos. Pasando a la parte más ]ilosó]ica del

asunto, iOS es un entorno cerrado, donde Apple no permite que desarrollemos cualquier

cosa. El desarrollador ha de ajustarse a una serie de directrices que la compañía establece

para que nuestra app sea publicada en la App Store. No ocurre así en Android. En Android,

el desarrollador puede gestionar el dispositivo como superusuario o root, abriendo el

abanico de posibilidades software. Sin ánimo de entrar en más detalle o debate tecnológico

sobre qué plataforma es mejor, está claro que el coste temporal y de recursos humanos

para tener nuestra app en ambas plataformas desarrollando de forma nativa es muy

elevado. Por tanto, hay que explorar otras posibilidades.

Esas otras posibilidades se reducen a Cordova, también conocida como PhoneGap. Cordova

es una plataforma de Apache para construir aplicaciones móviles utilizando programación

web con HTML, CSS y Javascript. De esta forma, Cordova permite empaquetar la aplicación

desarrollada como web para varios entornos nativos, como iOS, Android o Windows

Phone. Utilizando Cordova como plataforma de desarrollo, se consigue agilizar el

desarrollo software de manera considerable.

Debido a las características de este proyecto, se ha elegido Cordova como plataforma de

desarrollo. Además, se ha elegido Ionic para el desarrollo.

�29


3. Ionic y AngularJS

Ionic es una plataforma de desarrollo de front-‐ends que se apoya en Cordova, aportando una

serie de componentes para facilitar el desarrollo, como scroll-‐views, botones, barras laterales,

pestañas, etc. Los componentes Ionic cuentan con un diseño elegante y atractivo, muy similar

a los componentes de iOS. Además, Ionic cuenta con una interfaz de línea de comandos (CLI)

muy potente, desde la cual crearemos la plantilla base para nuestro proyecto,

empaquetaremos el código para generar un proyecto iOS o Android y ejecutaremos nuestra

app.

Con el siguiente comando crearemos una plantilla vacía

para nuestro proyecto:

| $ ionic start miApp blank

El siguiente comando nos sirve para empaquetar nuestra

aplicación Ionic/Cordova y generar un proyecto de iOS:

| $ ionic build ios

Para añadir un nueva plataforma a nuestro proyecto, por

ejemplo Android, simplemente ejecutaríamos el siguiente

comando:

| $ ionic platform add android

Fig.6. Botones en Ionic

Ionic utiliza AngularJS. AngularJS es un marco o entorno Javascript mantenido por Google que

utiliza el patrón de diseño software modelo-‐vista-‐controlador (MVC) y cuyo objetivo es

simpli]icar el desarrollo y las pruebas de aplicaciones web escritas en HTML, CSS y JavaScript.

�30


En otras palabras, AngularJS es una librería escrita en JavaScript que lee nuestro código HTML,

en el que hemos escrito ciertos atributos propios de AngularJS en las directivas HTML, como

ng-‐repeat, para facilitar ciertas tareas como puede ser rellenar el árbol DOM con contenido

extraído de una variable JavaScript. AngularJS nos permite separar la vista de nuestra app, en

forma de documento HTML (estilizado con CSS); el controlador de dicha vista, en forma de un

documento con extensión .js y los datos necesarios para proveer de información nuestra vista.

El controlador quedará asociado a una vista HTML y pedirá los datos al modelo, que es

también un documento con extensión .js, para así rellenar el árbol DOM de forma recursiva o

para añadir contenido a elementos HTML sueltos. Ahí es precisamente donde reside el

verdadero potencial de AngularJS.

Para ejempli]icar lo anteriormente descrito, podemos analizar el siguiente ejemplo sencillo de

HTML y AngularJS:

| <!DOCTYPE html> | <html> | <head> | <script src=“angular.min.js”></script> | <script src=“controller.js”></script> | </head> | <body ng-controller=“MyController”> | <h2>{{buttonTextLabels.length}} botones:</h2> | <ul> | <li ng-repeat=“label in buttonTextLabels”> | <button ng-click=“miClick()”>{{label}}</button> | </li> | </ul> | </body> | </html>

Si comenzamos ]ijando nuestra atención sobre el elemento <li>, podemos ver el atributo de

AngularJS ng-‐repeat. Con este atributo, se generarán tantos elementos <li> como elementos

contenga el array JavaScript buttonTextLabels. Además podremos utilizar el valor de cada

posición del array llamando a la variable label que creará AngularJS al ejecutarse. Así, se

generarán los elementos en un lista HTML y cada elemento contendrá un botón cuyo texto

será el valor de cada posición del array mencionado. Al hacer click en un botón se llamará ala

�31


función miClick(). El array y la función miClick() están de]inidos en el controlador asociado a

este HTML, que hemos llamado controller.js:

| angular.module('controller', []) | .controller('MyController', function() | { | this.buttonTextLabels = [“Uno”, “Dos”, “Tres”, “Cuatro”]; | | this.miClick() = function() { alert(‘¡Me has pulsado!’) }; | });

También se ha utilizado jQuery, que es una librería escrita en JavaScript para simpli]icar las

sentencias JS y facilitar el desarrollo.

�32


4. Funcionalidades, estructura de datos y diseño de la app

Al iniciar por primera vez la app, se muestra una pantalla donde aparecen los lenguajes

disponibles. En ella se le pide al estudiante que elija el lenguaje que desea aprender.

Independientemente de su elección, el estudiante podrá acceder a cualquier lenguaje desde la

barra lateral (sidebar) de la aplicación.

La app cuenta con una barra lateral que aparece al pulsar un botón en la esquina superior

izquierda. En esta sidebar se muestran los lenguajes de programación disponibles. Al pulsar

un lenguaje, en la vista principal se mostrará la información del mismo y una lista con las

lecciones del lenguaje, así como el progreso del estudiante en tanto porciento de cada lección.

�33

Fig.7. Vista inicial de la app CODEiT


Fig.8. Vista de la sidebar de CODEiT

Fig.9. Vista de un lenguaje de CODEiT

�34


Fig.10. Vista de una lección de CODEiT

Al pulsar en una lección, se muestra el contenido de la misma, organizado en capítulos. Si el

capítulo tiene activada la opción de Playground, se mostrarán en la parte superior de la

pantalla dos pestañas para poder acceder a los capítulos y al Playground. El Playground es una

zona que cuenta con un área de edición de código con numeración de líneas y desde donde se

puede enviar código a compilar al servidor. Al recibir el resultado de la compilación/ejecución,

este se mostrará debajo de la zona de edición de código. Este resultado serán las trazas de la

compilación, en caso de que el código no sea correcto. Si el código es correcto, se mostrará el

resultado de la ejecución del mismo. Si este resultado está vacío, porque el código no imprima

nada en consola, se le mostrará un mensaje al estudiante indicando que su código sí que ha

compilado bien. Al ]inal de cada capítulo se encuentran los botones para avanzar al siguiente

capítulo o retroceder al anterior, así como un índice de los capítulos de la lección.

�35


Para el desarrollo de la app, se han diseñado cuatro componentes básicos:

Texto: un componente de texto que facilite la lectura y resulte agradable estéticamente.

Cuenta con un título opcional.

Fig.11. Componente de texto de CODEiT

�36


Imagen: un componente que muestra una imagen y que, al pulsar sobre él, muestra dicha

imagen a pantalla completa. Con la imagen en pantalla completa se puede hacer zoom y

moverse por la imagen.

Fig.12. Componentes de imagen de CODEiT

Ejemplo de código: se trata de un componente que muestra ejemplos de código dentro de

una etiqueta <pre> de HTML. Este componente cuenta con un analizador léxico para

colorear correspondientemente cada palabra, tal y como sucede en los editores de código

más populares. Esta funcionalidad se ha implementado mediante expresiones regulares en

JavaScript, mediante las cuales se detectan patrones léxicos, es decir, sucesiones de

�37


palabras y/o símbolos. Al detectar un patrón que encaja con una de las numerosas

expresiones regulares programadas para el tema de un determinado lenguaje, se

encapsula el texto coincidente en una etiqueta div a la que se le añade una clase

determinada para así aplicarle unos estilos CSS concretos. Puesto que el caso práctico del

proyecto es el lenguaje Swift, se han diseñado las expresiones regulares y las reglas CSS

adecuadas para este lenguaje.

Fig.13. Componente de ejemplo de código de CODEiT

Playground: como ya se ha explicado, el Playground es un componente que cuenta con

una zona de edición de texto (implementado como una etiqueta <textarea> de HTML) y a

la que se le ha añadido numeración de líneas. Cuenta con un botón para enviar a compilar

el código y una zona de visualización de los resultados que aparecerá al recibir los mismos.

Fig.14. Componente Playground de CODEiT

�38


Botón de acceso directo a Playground: un componente sencillo que nos llevará al

Playground de la lección que estamos visualizando.

Fig.15. Componente botón de enlace a Playground de CODEiT

Las interfaces y los componentes de la aplicación cliente han sido diseñados para crear unas

vistas sencillas, minimalistas, funcionales, centradas en el contenido y con unos patrones de

diseño que siguen las líneas más recientes de diseño grá]ico. Así, con un diseño claro se

consigue centrar al usuario en lo realmente relevante. Una interfaz clara y moderna hace que

el usuario se sienta a gusto y disfrute mientras aprende. De esta forma se puede conseguir un

mayor tiempo de uso de la app por parte del estudiante.

�39


5. Estructura de archivos

La estructura de archivos de la aplicación cliente desarrollada con Cordova es la típica de un

proyecto web, añadiéndole una serie de librerías web:

index.html css img js

app.js controllers.js services.js

lib

ionic ngCordova

templates

start.html sidemenu.html lessons.html lesson.html

En el archivo index.html se cargarán todas las librerías javascript y las hojas de estilo CSS de

nuestro proyecto. En el cuerpo (<body>) del documento se indica el nombre de la app para su

identi]icación en AngularJS (en el atributo HTML ng-‐app) y el componente Ionic de jerarquía

superior, que en este caso es el componente <ion-‐nav-‐view>, el cual proporciona una

estructura para mostrar vistas navegables. Estas vistas son muy comunes en arquitecturas

móviles: la vista principal contiene una lista de elementos y, al pulsar en uno de ellos,

aparecerá la vista detalle con un botón en la esquina superior izquierda para volver a la lista.

Esta estructura se puede ir encapsulando hasta el nivel que se desee (listas dentro de listas,

etc).

| <body ng-app="pfg"> | <ion-nav-view></ion-nav-view> | </body>

�40


Serán Ionic y AngularJS los encargados de rellenar la directiva ion-‐nav-‐view con el contenido

de la aplicación web. Dicho contenido será generado tomando las plantillas HTML de la

carpeta templates. AngularJS poblará dichas plantillas HTML con el contenido que se

especi]ique en las expresiones de AngularJS (denotadas entre corchetes curvos dobles -‐ {{ }}) y

en los atributos ng-‐repeat, como se ha explicado en el apartado 3 de este documento. El papel

de Ionic en este proceso será el de proveer los componentes HTML con los que se poblará el

árbol DOM del cuerpo de nuestra aplicación.

En el archivo controllers.js se encuentran los controladores AngularJS del proyecto. Cada

vista de la app, representada mediante las plantillas HTML localizadas en la carpeta templates,

está asociada a un controlador mediante el archivo app.js. Este archivo contiene la

con]iguración de la app (teclado, status bar, y demás plugins de Cordova que deseemos

utilizar) y las asociaciones url-‐plantilla-‐controlador.

Dentro de cada controlador escribiremos el código JavaScript necesario para implementar las

funcionalidades que deseemos en la vista HTML asociada al controlador. A continuación se

muestra la sintaxis de un controlador de AngularJS:

| .controller('SideMenuController', function($scope, $rootScope, Languages) | { | // Código Javascript | }

Por último, el archivo services.js contiene una factoría de AngularJS. Las factorías nos ayudan a

aislar el modelo de datos en nuestra aplicación, siguiendo el paradigma MVC mencionado. Es

en este archivo donde se recogen todos los datos de cada lenguaje de programación, en forma

de objeto JavaScript (JSON). A esta factoría, bautizada como Languages, se le puede solicitar

la información de todos los lenguajes; la de uno en particular, indicando el nombre del

lenguaje; la de todas las lecciones de un lenguaje y la de una lección en particular de un

lenguaje. Para solicitar información a la factoría, escribiremos lo siguiente:

| .controller('SideMenuController', function($scope, $rootScope, Languages) | { | Languages.all(); // Todos los lenguajes | Languages.lesson(‘Swift’, 1); // La lección con ID=1 del lenguaje Swift | }

�41


6. Comunicación con el servidor

La app cliente ha de comunicarse con el servidor en dos ocasiones para realizar dos

operaciones distintas:

Operación de descarga de los lenguajes de programación y toda la información de cada uno de

ellos. En esta operación se solicita todo el contenido de la base de datos en un único JSON que

será parseado por JavaScript y posteriormente guardado en el cliente en localStorage.

LocalStorage es un objeto JavaScript incorporado al tiempo que HTML5, que nos permite

guardar cadenas de caracteres en el navegador. Y es que no hemos de olvidar que, aunque se

trate de una aplicación móvil, no es más que una web que se incrustará en una vista de

navegador de una app en la plataforma correspondiente del dispositivo (iOS o Android). Los

datos almacenados en localStorage, a diferencia de los almacenados en sessionStorage, no se

borrarán al cerrar la ventana y, a diferencia de las cookies, no tiene un tamaño limitado de

memoria. Es en el archivo services,js donde se solicita este objeto JSON, de donde

posteriormente los controladores extraerán la información que mostrar al estudiante.

Operación de compilación/ejecución. En esta operación se solicita al servidor que compile y

ejecute el código que se le envía en formato JSON. La operación se lanza desde el controlador

asociado a la vista de una lección, cuando se pulsa el botón de ‘TEST’ de un Playground. La

compilación remota es tratada y explicada en detalle más adelante en este documento.

Estas operaciones se solicitan enviando una petición HTTP-‐POST de manera asíncrona,

mediante AJAX. De esta manera el usuario no percibe una recarga en la web, proporcionando

un servicio más transparente y dinámico. En el cuerpo de la petición viaja el contenido de la

solicitud, donde se indica qué operación se está solicitando en el parámetro “action” del POST.

Este parámetro podrá tomar los valores “lans”, para la primera operación y “compile” para la

segunda. Las respuestas son igualmente HTTP-‐POST y en el cuerpo viaja el contenido

solicitado en formato JSON.

�42


Servidor

1. Tecnología servidora

Para este proyecto se ha levantado un servidor Apache, capaz de interpretar y ejecutar PHP. El

servidor tendrá las funciones de responder a las peticiones de solicitud de los lenguajes,

lecciones y capítulos de la app; a las peticiones del gestor web, generando dinámicamente las

páginas y devolviendo los archivos que estas necesiten (imágenes, archivos CSS y archivos

JavaScript) y a las peticiones de compilación/ejecución de código de la app.

También se ha obtenido el nombre de dominio gratuito codeit.no-‐ip.org para facilitar el

acceso al servidor.

Para el desarrollo del lado servidor de CODEiT, se ha empleado la tecnología PHP. Aunque se

han analizado otras opciones, como la tecnología servidora Servlet con Java o NodeJS, el

rápido aprendizaje y la facilidad de programación de partes complejas del lado servidor

(como la gestión de sesiones) hacen de PHP un lenguaje muy cómodo a la vez que extendido.

Es por esto que PHP cuenta con una enorme cantidad de recursos web de ayuda, como

ejemplos, APIs documentadas o tutoriales.

La tecnología servidora con Java (Servlets) fue descartada por dos motivos. El primero, que no

todos los servidores web que se pueden alquilar son capaces de ejecutar Java Servlets. El

segundo, que al tratarse de un lenguaje compilado, no así como PHP que es interpretado, hay

que compilar el servidor con cada cambio realizado y esto ralentiza considerablemente el

proceso de desarrollo.

Por otro lado, NodeJS es una tecnología servidora muy reciente desarrollada en JavaScript y

basada en eventos. Al tratarse de una tecnología joven, no existe tanta documentación de

ayuda online como en Java Servlets y PHP. Además, su asincronismo hace que sea más

complicadas ciertas transacciones web que requieren respuesta para cambiar el estado del

servidor y poder continuar con otras operaciones.

�43


Así, PHP es un lenguaje abierto, con una curva de aprendizaje muy baja, una sintaxis clara y

simple y cumple con los requisitos mínimos de la programación orientada a objetos,

convirtiéndose en la tecnología servidora elegida para este proyecto.

�44


2. Base de datos

La base de datos del proyecto ha sido desarrollada apoyándose en una tecnología que está

actualmente en auge: las bases de datos NoSQL. El sistema NoSQL elegido es MongoDB. A

continuación voy a explicar, de forma resumida, qué es un sistema de base de datos NoSQL, así

como una comparación de sistemas SQL y NoSQL y analizaré las ventajas que supone el uso de

MongoDB.

Los sistemas NoSQL (Not only SQL) son sistemas de bases de datos no relacionales, es decir,

no distribuyen la información en tablas donde cada columna es un atributo, sino que la

información queda distribuida de manera distinta, sin seguir este modelo de relaciones

tabuladas. Al no seguir un esquema o estructura ]ija (tabulada) de datos, las bases de datos

NoSQL permiten a los sistemas para los que almacenan información ser mucho más ]lexibles y

adaptados al caso de uso particular, puesto que es el diseño de la base de datos el que se

adapta al contenido y no al contrario, como ocurre en los modelos SQL. [5 y 6]

Al no tener un conjunto de datos separados que han de ser uni]icados mediante relaciones, los

sistemas NoSQL son mucho más rápidos a la hora de realizar consultas que requieren realizar

JOINs (uni]icaciones) de varias tablas. En este estudio [7] podemos comprobar que,

efectivamente, MongoDB (NoSQL) supera a MySQL en tiempos en la mayoría de los test

realizados. Además, los sistemas NoSQL son más escalables, especialmente si se trata de

almacenar Big Data.

Atendiendo al modelo empleado a la hora de almacenar los datos, podemos distinguir cuatro

tipos de sistemas NoSQL: modelo clave-‐valor, como el sistema Redis; modelo documento (en

formato JSON comúnmente), como MongoDB; modelo orientado a columnas (modelo

avanzado del modelo clave-‐valor), como el sistema Cassandra y modelo grá]ico (similar a los

objetos de programación, con relaciones entre objetos), como OrientDB. A pesar de esta

clasi]icación, pueden existir soluciones particulares híbridas de sistemas NoSQL.

Por otro lado, los sistemas NoSQL presentan ciertas desventajas frente a los tradicionales SQL.

La principal desventaja es que, a pesar de su alto rendimiento y escalabilidad, los sistemas

NoSQL pueden presentar problemas de consistencia al no seguir una estructura de datos ]ija.

�45


Para este proyecto, se ha utilizado MongoDB, uno de los sistemas de bases de datos NoSQL que

podemos encontrar. Se trata de una solución open source orientada a documentos, que guarda

la información en formato BSON (Binary JSON). Se ha elegido este sistema por su alto

rendimiento, compatibilidad con JSON, que es el formato de presentación de datos elegido

para toda la aplicación, por su compatibilidad con PHP y por su facilidad a la hora de realizar

consultas. En MongoDB, las tablas de datos de sistemas SQL se traducen en colecciones de

documentos y las tablas, en documentos JSON, que son guardados posteriormente en formato

BSON. A partir de ahí, se puede almacenar cualquier estructura de datos JSON, con el grado de

encapsulación que se desee.

Para una cómoda gestión grá]ica de la base de datos, se ha utilizado el cliente Robomongo, por

su facilidad de uso y su interfaz clara y usable.

Fig.16. Interfaz de la aplicación Robomongo en Mac OSX

�46


Para la base de datos de CODEiT, se han creado dos colecciones en MongoDB: Languages y

Users.

Languages contiene documentos JSON que a su vez contienen la información de cada uno

de los lenguajes de programación, lecciones de cada lenguaje y capítulos de cada lección,

siguiendo la siguiente estructura:

Languages

id

name

mainColor

secColor

lessons [ ]

id

name

description

chapters [ ]

content (HTML)

Los campos marcados con [ ] son arrays.

Users contiene documentos JSON con la información de los usuarios. Para gestionar el

control de acceso en futuras versiones de la aplicación, se ha añadido el campo role. Para

poder entrar en el gestor web de la aplicación, el usuario deberá tener un rol de

administrador. La estructura de cada documento JSON de esta colección es la siguiente:

Users

username

password

role

�47


�48


Manager

1. Introducción

Con el objetivo de simpli]icar la lectura, inserción y eliminación de contenido de la base de

datos del sistema, se ha diseñado e implementado un gestor web de contenidos. De esta

forma, el profesor puede gestionar fácilmente los lenguajes, lecciones y capítulos de cada

lección. A este gestor se accede mediante un usuario y una contraseña.

2. Desarrollo

El desarrollo de este gestor web se ha realizado en dos etapas. Primero se ha realizado el

diseño grá]ico de la web y la implementación del mismo en HTML5, CSS3 y JavaScript,

utilizando también jQuery. A continuación se han implementado las funcionalidades del lado

servidor necesarias para realizar las acciones descritas anteriormente: lectura, eliminación e

inserción de contenidos de la base de datos.

Por motivos de seguridad, al realizar el login, no se envía en ningún caso la contraseña en

claro, sino que se realiza un resumen de 20 bytes con el algoritmo hash SHA-‐1 del patrón

“usuario:contraseña”. El servidor, al recibir esta petición, toma el nombre de usuario de la

petición (que si viaja en claro), extrae la contraseña de la base de datos, realiza el resumen del

mismo patrón con SHA-‐1 y compara lo recibido con lo recién obtenido. En caso de que

coincidan, el usuario queda logado correctamente.

Las transacciones cliente-‐servidor que se han implementado para el manager se muestran en

la siguiente tabla:

�49


Nombre URI TIPOPARÁMETROS

DESCRIPCIÓN / RESPUESTA

NOMBRE VALOR

login index.php POST

actionusernamepassword

loginnombre de usuarioresumen con SHA-1 de “usuario:contraseña”

Si los datos son correctos, página de lenguajes, sino, devuelve un mensaje de error que es mostrado.

logout index.php POST action logout Cierra la sesión y vuelve a la página de login

listar lenguajes lans.php GET - - Página con los lenguajes

abrir lenguaje lans.php GET lan índice del lenguaje Web con las lecciones del

lenguaje seleccionado

eliminar lenguaje lans.php GET remove_lan índice del lenguaje

Elimina el lenguaje indicado y devuelve la web de lenguajes

nuevo lenguaje lans.php GET new_lan 1 Web de creación de un

lenguaje

añadir lenguaje lans.php POST

add_lannamemainColorsecColor

1nombre del lenguajecolor principalcolor secundario

Añade el lenguaje nuevo y devuelve la web de lenguajes

editar lenguaje lans.php GET edit_lan 1 Web de edición de un

lenguaje

actualizar lenguaje lans.php POST

edit_lannamemainColorsecColor

1nombre del lenguajecolor principalcolor secundario

Actualiza los datos del lenguaje indicado y devuelve la web de lenguajes

abrir lección lan.php GET lesson índice de la lección

Web de la lección, mostrando los capítulos de esta

nueva lección lan.php GET new_lesson - Web de creación de una

lección

�50


Fig.17. Tabla de peticiones de manager al servidor

añadir lección lan.php POST

add_lessonnamedescriptionplayground

1nombre de la leccióndescripciónañadir playground

Añade la lección nueva y devuelve la web del lenguaje

editar lección lan.php GET edit_lesson - Web de edición de una

lección

actualizar lección lan.php POST

edit_lessonnamedescriptionplayground

1nombre de la leccióndescripciónañadir playground

Actualiza los datos de la lección y devuelve la web del lenguaje

eliminar lección lan.php GET remove_lesson 1

Elimina la lección seleccionada y devuelve la web del lenguaje

nuevo capítulo

lessons.php GET new_chapter índice de la lección Web de creación de un

nuevo capítulo

añadir capítulo

lessons.php POST new_chapter contenido HTML del

capítulo

Añade el nuevo capítulo y devuelve la web de la lección

editar capítulo

lessons.php GET edit_chapter

chapter-índice del capítulo

Web de edición de un capítulo

actualizar capítulo

lessons.php POST

edit_chapterchaptercontent

1índice del capítulocontenido HTML del capítulo

Actualiza los datos del capítulo y devuelve la web de la lección

eliminar capítulo

lessons.php GET remove_chapter

chapter1índice del capítulo

Elimina el capítulo seleccionado y devuelve la web de la lección

Nombre URI TIPOPARÁMETROS

DESCRIPCIÓN / RESPUESTA

NOMBRE VALOR

�51


3. Diseño y vistas

A continuación se muestran las diferentes vistas de la web de gestión:

Fig.18. Vista de lenguajes del manager de CODEiT con la barra lateral desplegada

Para futuras expansiones del sistema, se ha implementado una barra lateral que se oculta al

hacer click en el botón con tres rayas horizontales en la parte superior.

�52


Fig.19. Vista de lenguajes del manager de CODEiT

Fig.20. Vista de creación de un lenguaje del manager de CODEiT

�53


Las tablas tienen pequeños botones de acción en la última columna de cada ]ila. Al pulsar en el

botón de editar lenguaje, accederemos a la siguiente vista:

Fig.21. Vista de edición de un lenguaje del manager de CODEi

Fig.22. Vista de eliminación de un lenguaje del manager de CODEiT

�54


Fig.23. Vista de lecciones de un lenguaje del manager de CODEiT

Fig.24. Vista de creación de una lección del manager de CODEiT

�55


Fig.25. Vista de edición de una lección del manager de CODEiT

Fig.26. Vista de eliminación de una lección del manager de CODEiT

�56


Fig.27. Vista de capítulos de una lección del manager de CODEiT

Fig.28. Vista de creación de un capítulo del manager de CODEiT

�57


Fig.29. Vista de creación de un capítulo del manager de CODEiT -‐ Componentes de texto y código añadidos

Fig.30. Vista de edición de un capítulo del manager de CODEiT

�58


Fig.31. Vista de eliminación de un capítulo del manager de CODEiT

Fig.32. Vista de opciones de usuario del manager de CODEiT

Al pulsar nuestro nombre de usuario en la esquina superior derecha del gestor, se mostraría el

panel anterior, desde donde se puede cerrar la sesión. Este panel se ocultará al cabo de 20

segundos para volver a mostrar nuestro nombre de usuario.

Para facilitar la navegación por el contenido del gestor, se ha implementado una “miga de pan”,

desde donde se puede acceder a todos los lenguajes y al lenguaje y lección actuales,

dependiendo de donde nos encontremos:

Fig.33. Vista de la miga de pan del manager de CODEiT

�59


�60


Compilación remota

Como se ha mencionado, uno de los objetivos más importantes del proyecto es poder subir al

sistema lecciones de lenguajes de programación compilados, es decir, lenguajes de

programación cuyo código necesita ser traducido a lenguaje máquina por un compilador para

poder ser ejecutado. En esta sección se va a describir cómo se ha realizado el proceso de

compilación remota en la aplicación desarrollada.

El mayor hándicap con el que nos encontramos a la hora de enfrentarnos al problema de la

compilación en dispositivos móviles es que no podemos suponer que contamos con un

dispositivo con permisos de administrador. Si bien en Android es posible ser administrador

(root), en la mayor parte de los casos es un proceso que hay que realizar de forma manual con

la ayuda de programas de rooteado. En Apple tampoco se contempla esta posibilidad. Por

tanto, la opción de acceder a la consola del terminal para instalar por código compiladores de

diversos lenguajes no es viable en el entorno móvil.

Así, la opción más e]icaz es la de la compilación remota. Esto es, la compilación de código por

una máquina ajena a aquella en la que se ha escrito el código. En el escenario de este proyecto,

la máquina que compila el código es el servidor y la que envía el código es la app cliente.

El código se envía al servidor en un documento JSON con el siguiente formato:

| { | “action”: “compile”, | “language”: “Swift”, | “code”: “var hello = \”Hello World!\”\nprintln(hello)” | }

El código, que se escribe dentro de un elemento <textarea> de HTML, ha de ser primero

pasado por un ]iltro que reemplace ciertos caracteres especiales (saltos de línea, retornos de

carro, comillas, etc). Por ejemplo, un salto de línea ha de enviarse como el caracter \n de

�61


forma literal para ser interpretado correctamente en el destino. De esta forma, el código es

analizado y encapsulado en un documento JSON.

Cuando el servidor recibe una petición de compilación, identi]icará el lenguaje que se desea

compilar y llamará a la herramienta de compilación correspondiente por línea de comandos,

pasándole a dicha herramienta el código que ha de compilar. El servidor toma la salida de

consola del resultado de la compilación y ejecución del código y la encapsula en un documento

JSON que será devuelto a la app cliente para que muestre el resultado. Este documento de

respuesta tiene el siguiente formato:

| { | “action”: “compile_result”, | “language”: “Swift”, | “message”: “Hello World!” | }

En Swift, existe el mandato de consola “swift” que permite compilar y ejecutar código

pasándole un archivo. Por tanto, el servidor ha de crear un archivo temporal al recibir una

petición de compilación con el código extraído de la petición y pasarle ese archivo al mandato

de consola para luego recoger el resultado. Esta misma ]iloso]ía se puede aplicar a muchos

compiladores, como el popular compilador de C: gcc.

A continuación se muestra un ejemplo del código en PHP implementado para la compilación

de código en Swift:

| function compileSwift() | {

| $file = fopen("in.txt", "w"); | fwrite($file, $_POST["code"]); | fclose($file); | | $output = shell_exec('swift /Library/WebServer/Documents/SwiftCompiler/in.txt 2>&1'); | $output = str_replace('/Library/WebServer/Documents/SwiftCompiler/in.txt:', '', $output); | | |

�62


| $return = array | ( | "action" => “compile_result", | "language" => $_POST[“language"], | "message" => $output | ); | | echo json_encode($return);

| }

De esta manera logramos compilar el código deseado de forma remota, con una simple

transacción HTTP y un compilador instalado en el servidor que tenga un mandato de consola

para poder compilar y ejecutar código.

�63


�64


Conclusiones y trabajo futuro

Este Proyecto de Fin de Grado es la base del desarrollo de una aplicación móvil

multiplataforma para facilitar el aprendizaje de lenguajes de programación a través de una

interfaz grá]ica amigable, clara, sencilla, funcional y acorde con las nuevas tendencias de

diseño grá]ico, que permite al profesor gestionar el contenido de forma rápida y sencilla y que

permite al alumno compilar y ejecutar su propio código a medida que avanza en su

aprendizaje.

Para lograr desarrollar este proyecto, primero se han diseñado los componentes grá]icos de la

aplicación conforme a los requisitos del sistema. A continuación, se han estudiado las

tecnologías más apropiadas para la duración y objetivos del proyecto. Se ha desarrollado la

app cliente para dispositivos móviles con la plataforma Cordova-‐Ionic, utilizando las últimas

tecnologías y lenguajes web (HTML5, CSS3, JavaScript y AngularJS). Después, se ha creado una

base de datos con el sistema NoSQL MongoDB y se ha desarrollado el servidor web que

atiende a peticiones de solicitud de lenguajes de programación y de compilación remota, todo

ello aplicado al caso práctico del nuevo lenguaje de Apple: Swift. Por último, se ha

desarrollado un gestor web de la base de datos, con control de acceso basado en roles, para

agilizar y facilitar la creación, modi]icación y eliminación de contenidos del sistema

desarrollado.

De esta forma, se han empleado las últimas tecnologías de desarrollo de software para agilizar

el proceso de desarrollo y despliegue de la aplicación, basándose en tecnologías del mundo

web y logrando completar desarrollos para distintas plataformas móviles (iOS y Android) en

un periodo de tiempo muy inferior al que correspondería a un desarrollo nativo para dichas

plataformas.

A pesar de haberse logrado la implementación de los objetivos y requisitos de esta app base,

se proponen a continuación las líneas de desarrollo futuras, con el objeto de continuar el

desarrollo y evolución de CODEiT.

�65


Trabajo futuro

Adaptar la app cliente a una versión web para ordenadores.

Adaptar el contenido de las lecciones a la norma de interoperabilidad SCORM.

Implementar la posibilidad de evaluar los conocimientos adquiridos en forma de tests.

Implementar desa]íos de código, en los cuales se proponga un ejercicio o problema al

alumno, donde se espera un resultado concreto. Mediante expresiones regulares, se podría

evaluar el resultado de la ejecución del código del alumno y también comprobar el código

en sí para veri]icar que tanto este como el resultado son los adecuados para marcar el

desa]ío como superado.

Implementar funciones de gami]icación en la app, obteniendo logros, medallas y puntos

conforme el alumno evoluciona en el aprendizaje de un lenguaje, de forma que pueda

desbloquear contenidos con su progreso. También resultaría interesante implementar

funcionalidades de interacción con las redes sociales para que el alumno pueda publicar

sus logros en Facebook, Twitter, etc.

�66


Referencias

[1] Elena Verdú, Luisa M. Regueras, María J. Verdú, José P. Leal, Juan P. de Castro, Ricardo

Queirós. A distributed system for learning programming on-‐line. Agosto, 2011.

[2] Juan Carlos González de Sande, Juan Ignacio Godino-‐Llorente, Víctor Osma Ruiz, Rubén

Fraile Muñoz, Juana María Gutiérrez Arriola, David Osés del Campo, Luis Arriero Encinas.

Cuestionarios online como herramienta de aprendizaje: comparación de resultados con

diversos modelos de cuestionarios. Departamento de Ingeniería de Circuitos y Sistemas,

Escuela Universitaria de Ingeniería de Telecomunicación de la Universidad Politécnica de

Madrid. 2011.

[3] Juan Carlos G. de Sande, Víctor Osma-‐Ruíz, César Benavente-‐Peces. Moodle tests for digital

signal processing. Circuits and Systems Engineering Department in the EUIT de

Telecomunicación at the Universidad Politécnica de Madrid (SPAIN). Julio, 2011.

[4] Apple. The Swift Programming Language. Obtenido en febrero de 2015 a través de la Mac

iBookStore. Consultado de febrero a mayo de 2015.

[5] Albertas Krisciunas. Bene]its of NoSQL. 20 de mayo, 2014. Consultado en marzo de 2015.

https://www.devbridge.com/articles/bene]its-‐nosql/

[6] Nicholas Greene. The Five Key Advantages (And Disadvantages) of NoSQL. 2013.

Consultado en marzo de 2015.

http://greendatacenterconference.com/blog/the-‐]ive-‐key-‐advantages-‐and-‐disadvantages-‐of-‐

nosql/

[7] Publicado por el usuario macool. MySQL vs PostgreSQL vs MongoDB (velocidad). 4 de

febrero, 2013. Consultado en marzo de 2015.

http://macool.me/mysql-‐vs-‐postgresql-‐vs-‐mongodb-‐velocidad/04

�67

https://www.devbridge.com/about-us/albertas-krisciunas

https://www.devbridge.com/articles/benefits-nosql/

http://greendatacenterconference.com/blog/the-five-key-advantages-and-disadvantages-of-nosql/

http://macool.me/mysql-vs-postgresql-vs-mongodb-velocidad/04


[8] Documentación y API de Ionic. Consultado de febrero a mayo de 2015.

http://ionicframework.com

[9] Documentación y API de MongoDB. Consultado de febrero a mayo de 2015.

http://docs.mongodb.org

[10] Advanced distributed learning. Consultado en marzo de 2015.

http://www.adlnet.org/

[11] Ana M. Fermoso García, Alberto Pedrero Esteban. Mobile learning and SCORM. Case Study

for Educational Contents Reuse. Faculty of Computer Science of Ponti]ical University of

Salamanca Salamanca, Spain. Diciembre, 2013.

�68

http://ionicframework.com

http://docs.mongodb.org

http://www.adlnet.org/


Anexo: Instalación del entorno de desarrollo

Este documento tiene como ]in explicar el proceso de instalación de los elementos del entorno

de desarrollo escogidos para la realización de este proyecto: Ionic, MongoDB y un servidor

Apache.

1. Ionic

Para poder desarrollar y desplegar apps para iOS con Ionic, es necesario tener un Mac. Por

este motivo, esta guía de instalación, que puede encontrarse parcialmente en la web de Ionic

[8], detalla los pasos necesarios para instalar Ionic en un Mac.

npm

La instalación de Ionic se realiza a través del Terminal de Mac OS X, el cual puede encontrarse

en la ruta: Aplicaciones > Utilidades > Terminal. Para poder instalar los paquetes de Ionic,

necesitaremos primero tener instalado el gestor de paquetes JavaScript npm. Si hemos

instalado NodeJS alguna vez, ya tendremos instalado npm, puesto que es el gestor de paquetes

por defecto en NodeJS. Para instalar npm teclearemos lo siguiente en el Terminal:

| $ curl -O -L https://npmjs.org/install.sh | sudo sh install.sh

Debemos obtener la frase “It worked” al terminar de ejecutar el mandato. Para comprobar la

correcta instalación tecleamos el siguiente mandato que debe indicarnos la versión de npm

que tenemos instalada:

| $ npm -v

�69


Fig. 34. Instalación de npm en el Terminal de Mac OS X.

Ionic

Una vez instalado npm, podemos proceder a la instalación de Ionic tecleando:

| $ sudo npm install -g cordova ionic

Podemos comprobar la versión de Ionic tecleando:

| $ ionic -v

�70


Fig. 35. Fin de la instalación de Ionic.

Con la plataforma de desarrollo Ionic correctamente instalada, procederemos a crear un

proyecto Cordova dentro de la carpeta “miApp” en la ruta en la que estemos posicionados en

Terminal:


�71


Este mandato nos generará la siguiente estructura de carpetas:

Fig. 36. Estructura de un proyecto Ionic en blanco.

Ionic proporciona tres plantillas de inicio:

Blank: genera un proyecto de app en blanco.


Tabs: genera un proyecto de app con una vista de navegación de pestañas en la

parte inferior de la pantalla de la app.

| $ ionic start miApp tabs

Sidemenu: genera un proyecto de app con una vista de menú lateral.

| $ ionic start miApp sidemenu

�72


Una vez tenemos creado nuestro proyecto Cordova/Ionic podemos añadir las plataformas

(sistemas operativos) en los que deseamos desplegar la app, compilar el proyecto y emularlo,

siempre que estemos situados en la carpeta de nuestro proyecto en el Terminal:

| $ ionic platform add ios | $ ionic platform add android | $ ionic build ios | $ ionic emulate ios

A partir de aquí, el desarrollo es en HTML, CSS y JavaScript, por lo que se puede realizar con

cualquier editor de texto plano que deseemos, ]ijándonos en la API de Ionic para utilizar

correctamente los componentes HTML que la plataforma nos provee. Para previsualizar

nuestra app sólo hemos de abrir el archivo index.html con un navegador web.

Existe también una aplicación web para agilizar el proceso de diseño de la app: Ionic Creator.

Con esta herramienta podemos diseñar las vistas, arrastrar los componentes Ionic a un canvas

donde previsualizamos la app y ]inalmente exportar el proyecto Ionic a nuestro ordenador.

Fig. 37. Ionic Creator.

�73


2. MongoDB

A continuación se detallan los pasos que hay que seguir para instalar el sistema de bases de

datos MongoDB en Mac OS X. Las guías de instalación de MongoDB en Mac, Windows y Linux

se pueden encontrar en la web de MongoDB [9].

NOTA: para instalar MongoDB 3.0 o superior debemos tener como mínimo OS X 10.7.

Brew

Vamos a realizar la instalación de MongoDB a través del Terminal de Mac OS X, mediante el

mandato brew. Brew es, al igual que npm, un gestor de paquetes. Para instalar brew, tecleamos

lo siguiente:

| $ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

A continuación actualizamos la base de datos de los paquetes de brew:

| $ brew update

Instalamos el paquete MongoDB:

| $ brew install mongodb

MongoDB

Para alojar la base de datos, hemos de crear la estructura de carpetas /data/db en la ruta que

deseemos para tener la base de datos de nuestro proyecto aislada y poder hacer copias de

seguridad de la misma:

| $ mkdir -p data/db

�74


Los siguientes mandatos ejempli]ican la ejecución del demonio de MongoDB, mongod, sin

especi]icar la ruta de la base de datos y especi]icándola:

| $ mongod | $ mongod --dbpath <ruta a la carpeta data>

Una vez esté el demonio mondo corriendo, nuestra base de datos podrá recibir y ejecutar

consultas a través del puerto 27017.

Fig. 38. Ejecución del demonio mongod.

�75

! Caliﬁcación · Álvaro Román Bengoechea, ETSIST, UPM Junio de 2015 Índice de ﬁguras Fig.1....

Documents

Transcript of ! Caliﬁcación · Álvaro Román Bengoechea, ETSIST, UPM Junio de 2015 Índice de ﬁguras Fig.1....