Salut! Je suis Linda Liu, une junior montante au MIT. J'ai passé les trois derniers mois ici à edX en tant que stagiaire en ingénierie logicielle dans l'équipe Mobile, au cours desquels j'ai eu l'opportunité de travailler dans une gamme allant du côté serveur au développement iOS et Android. J'aimerais parler de deux projets - le premier, la refonte du cadre de contrôle d'accès edX, et le second, l'exploration du cadre React et de son potentiel pour edX.
Cadre de contrôle d'accès
Ce projet a en fait commencé comme une correction de bogue concernant les dates de début des cours pour l'application mobile. Si un auteur de cours ne précise pas de date de début pour son cours, celui-ci est par défaut le 1er janvier 2030. Sur la plateforme web, une vérification est effectuée afin qu'un utilisateur voie « non programmé » au lieu de la date manifestement fausse. Cependant, l'application mobile n'effectue pas de vérification équivalente, de sorte que les étudiants voyaient que les cours avaient commencé en 2030.
Le premier correctif potentiel qui m'est venu à l'esprit consistait à effectuer une vérification côté serveur dans le point de terminaison des inscriptions aux cours de l'API mobile pour voir si la date de début était la valeur par défaut, et à ce que l'API envoie un Aucunvaleur dans ce cas. Ce correctif était agréable car il ne nécessiterait aucune modification côté client. Cependant, j'ai découvert que les applications attendaient un horodatage de l'API mobile et plantaient lorsque cette attente était rompue. Ainsi, un changement purement côté serveur ne fonctionnerait pas.
Parler des correctifs potentiels s'est transformé en une discussion sur la façon dont les vérifications de la date de début sont effectuées sur la plate-forme. La plateforme a une grande fonction appelée a_accès dans ce but. Il prend en compte un utilisateur, une action et un objet, et vérifie si l'utilisateur dispose des autorisations appropriées pour effectuer l'action sur l'objet. Par exemple, une utilisation de cette fonction est de vérifier si un étudiant a les autorisations pour s'inscrire à un cours. À l'époque, cette fonction renvoyait simplement un booléen - Vrai si l'accès est accordé, Faux si l'accès est refusé. Étant donné qu'il existe de nombreuses raisons pour lesquelles l'accès peut être refusé et que différentes raisons peuvent déclencher différents comportements, il semble que a_accès pourrait bénéficier d'un type de retour contenant plus de détails. L'API mobile pourrait alors envoyer les résultats de la a_accès vérifier au client, qui pourrait alors utiliser les informations pour afficher un message approprié.
L'étape suivante consistait à concevoir le nouveau type de retour. Le nouvel objet s'appelle Réponse d'accès. C'est un objet Python qui contient un booléen équivalent à la valeur d'origine a_accès aurait renvoyé, un code d'erreur de chaîne et des messages d'utilisateur et de développeur. Les sous-classes de celui-ci représentent les erreurs que nous voulons actuellement traiter, à savoir ErreurDateDébut (si le cours n'a pas démarré pour l'utilisateur), Erreur de visibilité (si l'utilisateur ne dispose pas des droits d'accès requis), et Erreur de jalon (si l'utilisateur a un jalon non atteint). J'ai implémenté les modifications dans quatre demandes d'extraction distinctes : une pour chacune "a_accès", l'API mobile, le client Android et le client iOS. Bien qu'au-delà de la portée d'origine du correctif de bogue, cette modification permet aux vérifications de la date de début de passer du côté client au côté serveur. En tant qu'effet secondaire, ce changement facilite grandement la mise en œuvre de futures fonctionnalités (telles que les jalons) dans l'application mobile. Grâce à ce travail, j'ai pu toucher à beaucoup de morceaux de la base de code edX, ce qui était vraiment cool !
React Native pour iOS et React.js
Mon prochain projet était de nature plus exploratoire, avec moins d'objectifs concrets. Chez edX, de nombreuses fonctionnalités doivent être développées trois fois - une fois pour le Web, une fois pour iOS et une fois pour Android. Il existe une variété d'outils multiplateformes pour le développement mobile avec la devise "écrire une fois, utiliser partout" pour lutter contre ce problème, mais ils ont tenté de trop standardiser le développement - les applications ne pouvaient pas utiliser les composants de la plate-forme native, alors ils sont sortis se sentir comme des pages Web mobiles glorifiées. Facebook a développé une solution à ce problème : un framework appelé React Native qui permet aux développeurs de créer des applications natives à l'aide de React (un framework d'interface utilisateur pour le Web).
L'idée directrice derrière React Native est "apprendre une fois, écrire n'importe où". Cela signifie que les plates-formes ont des structures et des styles différents, de sorte que les développeurs doivent écrire des applications différentes pour chacune, mais avec React Native, ces applications peuvent être écrites avec les mêmes technologies sous-jacentes. Il promet le meilleur des deux mondes - un développement efficace et similaire sur toutes les plates-formes, mais qui conserve cette bonne sensation native. Récemment, Facebook a ouvert la version du framework pour iOS. L'espoir est que React Native (une fois qu'il sera également open source pour Android) et React.js permettront aux développeurs de réutiliser le code, et ainsi de réduire le travail nécessaire pour développer pour les trois plates-formes.
Les XBlocks sont un bon candidat pour ce projet, car ce sont de petits éléments modulaires et les applications mobiles n'en ont actuellement pas d'implémentation native. Plus précisément, j'ai utilisé le glisser-déposer XBlock, car les interactions qu'il utilise (en particulier le mouvement de glissement) bénéficieraient du rendu fluide promis par React. J'ai commencé par faire une simple évaluation par glisser-déposer comme une application iOS autonome, pour avoir une idée du développement avec React Native. React a tenu ses promesses - le rendu était vraiment fluide, et les composants et les informations étaient organisés d'une manière qui avait vraiment du sens.
Cette expérience initiale a généré deux questions de suivi : avec quelle facilité le code pourrait-il être porté dans une évaluation par glisser-déposer React.js pour le navigateur ? Deuxièmement, avec quelle facilité l'évaluation par glisser-déposer pourrait-elle être intégrée au framework XBlock de sorte que l'évaluation puisse communiquer correctement avec le serveur ?
J'ai passé les dernières semaines à travailler pour répondre à ces deux questions. J'ai créé une version Web de mon application iOS, et bien qu'il n'y ait pas eu de traduction directe iOS vers Web (React Native-to-React.js) du code, les informations sont transmises et stockées de la même manière, et cela signifiait que beaucoup de fonctions pouvaient être réutilisées. Par exemple, toutes les fonctions qui gèrent le glissement ne nécessitaient que quelques petits ajustements. C'est prometteur car cela signifie que nous pouvons développer des XBlocks adaptés à différentes plates-formes tout en étant capables de réutiliser la structure derrière le code.
J'ai également travaillé sur l'intégration de l'évaluation avec l'atelier XBlock, car ce serait une partie importante de son fonctionnement avec la plate-forme. Cela impliquait de modifier le glisser-déposer XBlock lui-même ainsi que d'implémenter les appels AJAX corrects à partir du composant React afin que le serveur sache quand un étudiant ouvre ou tente un problème. React a facilité les appels nécessaires et nous avons maintenant une version React Native et React.js de ce XBlock ! J'espère qu'edX fera des composants React une partie permanente de la plate-forme à l'avenir.
Captures d'écran de React Native Drag and Drop XBlock
Gauche: vue initiale du problème par l'utilisateur. Des: Donner des commentaires via des alertes iOS.
Résumé
J'ai adoré avoir pu travailler sur une variété de projets cet été en termes de technologies que j'ai utilisées et de personnes avec qui j'ai travaillé. J'ai appris beaucoup de choses concrètes et j'ai également acquis des compétences non techniques, telles que la façon de communiquer efficacement dans une équipe d'ingénierie logicielle. Cela a été une opportunité incroyable, et merci à tous ceux qui l'ont fait! J'aimerais particulièrement remercier mes mentors, Chris Lee, Akiva Leffert et Nimisha Asthagiri, le reste de l'équipe mobile et les autres stagiaires.
