¡Hola! Soy Linda Liu, estudiante de tercer año en el MIT. Pasé los últimos tres meses aquí en edX como pasante de ingeniería de software en el equipo móvil, durante los cuales tuve la oportunidad de trabajar en una gama que va desde el lado del servidor hasta el desarrollo de iOS y Android. Me gustaría hablar sobre dos proyectos: el primero, el rediseño del marco de control de acceso de edX y el segundo, la exploración del marco React y su potencial para edX.
Marco de control de acceso
Este proyecto en realidad comenzó como una corrección de errores sobre las fechas de inicio del curso para la aplicación móvil. Si el autor de un curso no especifica una fecha de inicio para su curso, por defecto es el 1 de enero de 2030. En la plataforma web, se realiza una verificación para que un usuario vea "no programado" en lugar de la fecha obviamente falsa. Sin embargo, la aplicación móvil no realiza una verificación equivalente, por lo que los estudiantes vieron que los cursos comenzaron en 2030.
La primera solución potencial que se me ocurrió fue realizar una verificación del lado del servidor en el punto final de inscripción del curso de la API móvil para ver si la fecha de inicio era la predeterminada y hacer que la API enviara un Ningunovalor en ese caso. Esta solución fue buena porque no requeriría cambios en el lado del cliente. Sin embargo, descubrí que las aplicaciones esperaban una marca de tiempo de la API móvil y fallaron cuando se rompió esa expectativa. Por lo tanto, un cambio puramente del lado del servidor no funcionaría.
Hablar sobre las posibles correcciones se convirtió en una discusión sobre cómo se realizan las comprobaciones de la fecha de inicio en la plataforma. La plataforma tiene una gran función llamada tiene acceso para este propósito. Toma un usuario, una acción y un objeto, y verifica si el usuario tiene los permisos adecuados para realizar la acción en el objeto. Por ejemplo, un uso de esta función es verificar si un estudiante tiene permisos para inscribirse en un curso. En ese momento, esta función simplemente devolvía un valor booleano: Cierto si se concede el acceso, Falso si se niega el acceso. Dado que hay muchas razones por las que se puede denegar el acceso y diferentes razones pueden querer desencadenar diferentes comportamientos, parecía que tiene acceso podría beneficiarse de un tipo de retorno que contiene más detalles. La API móvil podría entonces enviar los resultados de la tiene acceso comprobar al cliente, que luego podría utilizar la información para mostrar un mensaje apropiado.
El siguiente paso fue diseñar el nuevo tipo de devolución. El nuevo objeto se llama AccesoRespuesta. Es un objeto de Python que contiene un valor booleano equivalente al valor original tiene acceso habría devuelto, un código de error de cadena y mensajes de usuario y desarrollador. Las subclases de él representan los errores que actualmente queremos tratar, a saber Error de fecha de inicio (si el curso no ha comenzado para el usuario), Error de visibilidad (si el usuario no tiene los derechos de acceso requeridos), y Error de hito (si el usuario tiene un hito sin cumplir). Implementé los cambios en cuatro solicitudes de extracción separadas: una para cada "tiene acceso", la API móvil, el cliente de Android y el cliente iOS. Aunque está más allá del alcance original de la corrección de errores, este cambio permite que las comprobaciones de la fecha de inicio pasen del lado del cliente al lado del servidor. Como efecto secundario, este cambio facilita mucho la implementación de funciones futuras (como hitos) en la aplicación móvil. A través de este trabajo, pude tocar muchas piezas del código base de edX, ¡lo cual fue realmente genial!
React Native para iOS y React.js
Mi siguiente proyecto fue de naturaleza más exploratoria, con menos objetivos concretos. En edX, muchas funciones deben desarrollarse tres veces: una para la web, otra para iOS y otra para Android. Ha habido una variedad de herramientas multiplataforma para el desarrollo móvil con el lema "escribe una vez, usa en todas partes" para combatir este problema, pero intentaron estandarizar demasiado el desarrollo: las aplicaciones no podían usar componentes nativos de la plataforma, por lo que salieron sintiéndose como páginas web móviles glorificadas. Facebook desarrolló una solución a este problema: un marco llamado React Native que permite a los desarrolladores crear aplicaciones nativas utilizando React (un marco de interfaz de usuario para la web).
La idea principal detrás de React Native es "aprender una vez, escribir en cualquier lugar". Esto significa que las plataformas tienen diferentes estructuras y estilos, por lo que los desarrolladores deben escribir diferentes aplicaciones para cada una, pero con React Native esas aplicaciones se pueden escribir con las mismas tecnologías subyacentes. Promete lo mejor de ambos mundos: un desarrollo que es eficiente y similar en todas las plataformas, pero aún tiene esa buena sensación nativa. Recientemente, Facebook abrió la versión del marco para iOS. La esperanza es que React Native (una vez que también sea de código abierto para Android) y React.js permitan a los desarrolladores reutilizar el código y, por lo tanto, reducir el trabajo necesario para desarrollar para las tres plataformas.
Los XBlocks son un buen candidato para este proyecto, porque son piezas modulares pequeñas y las aplicaciones móviles actualmente no tienen implementaciones nativas de ellas. Específicamente, usé el XBlock de arrastrar y soltar, porque las interacciones que utiliza (específicamente el movimiento de arrastre) se beneficiarían de la representación fluida que promete React. Comencé haciendo una simple evaluación de arrastrar y soltar como una aplicación independiente de iOS, para tener una idea del desarrollo con React Native. React estuvo a la altura de su promesa: el renderizado fue realmente fluido y los componentes y la información se organizaron de una manera que realmente tenía sentido.
Este experimento inicial arrojó dos preguntas de seguimiento: ¿Con qué facilidad podría trasladarse el código a una evaluación de arrastrar y soltar de React.js para el navegador? En segundo lugar, ¿con qué facilidad podría integrarse la evaluación de arrastrar y soltar con el marco XBlock para que la evaluación pudiera comunicarse con el servidor de la manera correcta?
He pasado las últimas semanas trabajando para responder a estas dos preguntas. Hice una versión web de mi aplicación para iOS y, aunque no hubo una traducción directa de iOS a web (React Native-to-React.js) del código, la información se transmite y almacena de la misma manera, y esto significaba que se podían reutilizar muchas funciones. Por ejemplo, todas las funciones que manejan el arrastre requirieron solo unos pequeños ajustes. Esto es prometedor porque significa que podemos desarrollar XBlocks adaptados a diferentes plataformas y aún así poder reutilizar la estructura detrás del código.
También trabajé en la integración de la evaluación con el banco de trabajo XBlock, ya que sería una parte importante para que funcione con la plataforma. Esto implicó modificar el XBlock de arrastrar y soltar, así como implementar las llamadas AJAX correctas desde el componente React, de modo que el servidor sepa cuándo un estudiante abre o intenta resolver un problema. ¡React facilitó la realización de las llamadas necesarias y ahora tenemos una versión React Native y React.js de este XBlock! Espero que edX haga de los componentes React una parte permanente de la plataforma en el futuro.
Capturas de pantalla de React Native Drag and Drop XBlock
Izquierda: Vista inicial del problema por parte de un usuario. Derecha: Dar retroalimentación a través de alertas de iOS.
Resumen
Me encantó que pude trabajar en una variedad de proyectos este verano en términos de las tecnologías que usé y las personas con las que trabajé. Aprendí muchas cosas concretas y también adquirí habilidades blandas, como cómo comunicarme de manera efectiva en un equipo de ingeniería de software. ¡Esta ha sido una oportunidad increíble, y gracias a todos los que lo hicieron así! Me gustaría agradecer especialmente a mis mentores, Chris Lee, Akiva Leffert y Nimisha Asthagiri, al resto del equipo móvil y a los demás pasantes.
