Oi! Sou Linda Liu, uma caloura em ascensão no MIT. Passei os últimos três meses aqui na edX como estagiário de engenharia de software na equipe Mobile, durante os quais tive a oportunidade de trabalhar desde o lado do servidor até o desenvolvimento iOS e Android. Eu gostaria de falar sobre dois projetos – o primeiro, redesenhando o framework de controle de acesso edX, e o segundo, explorando o framework React e seu potencial para edX.
Estrutura de controle de acesso
Este projeto realmente começou como uma correção de bug sobre as datas de início do curso para o aplicativo móvel. Se um autor de curso não especificar uma data de início para seu curso, o padrão é 1º de janeiro de 2030. Na plataforma web, uma verificação é realizada para que o usuário veja “não agendado” em vez da data obviamente falsa. No entanto, o aplicativo móvel não realiza uma verificação equivalente, então os alunos estavam vendo que os cursos começaram em 2030.
A primeira possível correção que me veio à mente foi realizar uma verificação do lado do servidor no endpoint de inscrições do curso da API móvel para ver se a data de início era a padrão e fazer com que a API enviasse um nenhumvalor nesse caso. Essa correção foi boa porque não exigiria alterações no lado do cliente. No entanto, descobri que os aplicativos esperavam um carimbo de data/hora da API móvel e travaram quando essa expectativa foi quebrada. Assim, uma mudança puramente no lado do servidor não funcionaria.
Falar sobre as possíveis correções evoluiu para uma discussão sobre como as verificações de data de início são feitas na plataforma. A plataforma tem uma grande função chamada tem_acesso para este fim. Ele recebe um usuário, uma ação e um objeto e verifica se o usuário tem as permissões adequadas para executar a ação no objeto. Por exemplo, um uso desta função é verificar se um aluno tem permissão para se matricular em um curso. Na época, essa função simplesmente retornava um booleano – a Verdadeira se o acesso for concedido, Falso se o acesso for negado. Dado que existem muitas razões pelas quais o acesso pode ser negado e diferentes razões podem querer desencadear comportamentos diferentes, parecia que tem_acesso poderia se beneficiar de um tipo de retorno que contém mais detalhes. A API móvel poderia então enviar os resultados da tem_acesso cheque para o cliente, que então poderia usar as informações para exibir uma mensagem apropriada.
O próximo passo foi projetar o novo tipo de retorno. O novo objeto é chamado AcessoResposta. É um objeto Python que contém um booleano equivalente ao valor original tem_acesso teria retornado, um código de erro de string e mensagens de usuário e desenvolvedor. As subclasses dele representam os erros com os quais queremos lidar atualmente, ou seja, StartDateError (se o curso não tiver começado para o usuário), Erro de visibilidade (se o usuário não tiver os direitos de acesso necessários) e Erro de marco (se o usuário tiver um marco não cumprido). Implementei as mudanças em quatro solicitações de pull separadas: uma para cada “tem_acesso”, a API móvel, o cliente Android e o cliente iOS. Embora além do escopo original da correção de bug, essa alteração permite que as verificações de data de início passem do lado do cliente para o lado do servidor. Como efeito colateral, essa alteração facilita muito a implementação de recursos futuros (como marcos) no aplicativo móvel. Através deste trabalho, pude tocar em vários pedaços da base de código do edX, o que foi muito legal!
React Native para iOS e React.js
Meu próximo projeto foi de natureza mais exploratória, com menos objetivos concretos. Na edX, muitos recursos precisam ser desenvolvidos três vezes – uma para a web, uma para iOS e outra para Android. Houve uma variedade de ferramentas de plataforma cruzada para desenvolvimento móvel com o lema “escreva uma vez, use em qualquer lugar” para combater esse problema, mas eles tentaram padronizar muito o desenvolvimento – os aplicativos não podiam usar componentes nativos da plataforma, então eles surgiram parecendo páginas da web para dispositivos móveis glorificadas. O Facebook desenvolveu uma solução para esse problema: um framework chamado React Native que permite que os desenvolvedores criem aplicativos nativos usando React (uma estrutura de interface do usuário para a web).
A ideia por trás do React Native é “aprender uma vez, escrever em qualquer lugar”. Isso significa que as plataformas têm estruturas e estilos diferentes, então os desenvolvedores devem escrever aplicativos diferentes para cada um, mas com o React Native esses aplicativos podem ser escritos com as mesmas tecnologias subjacentes. Ele promete o melhor dos dois mundos – desenvolvimento eficiente e semelhante em todas as plataformas, mas ainda com aquela boa sensação nativa. Recentemente, o Facebook abriu o código-fonte da versão do framework para iOS. A esperança é que o React Native (uma vez que também é de código aberto para Android) e o React.js permitam que os desenvolvedores reutilizem o código e, assim, reduzam o trabalho necessário para desenvolver para as três plataformas.
Os XBlocks são um bom candidato para este projeto, pois são pequenas peças modulares e os aplicativos móveis atualmente não possuem implementações nativas deles. Especificamente, usei o XBlock de arrastar e soltar, porque as interações que ele usa (especificamente o movimento de arrastar) se beneficiariam da renderização suave que o React promete. Comecei fazendo uma simples avaliação de arrastar e soltar como um aplicativo iOS autônomo, para ter uma ideia do desenvolvimento com React Native. O React cumpriu sua promessa – a renderização foi muito suave, e os componentes e as informações foram organizados de uma maneira que realmente fazia sentido.
Esse experimento inicial gerou duas perguntas de acompanhamento: Com que facilidade o código poderia ser portado para uma avaliação de arrastar e soltar React.js para o navegador? Em segundo lugar, com que facilidade a avaliação de arrastar e soltar poderia ser integrada à estrutura XBlock de modo que a avaliação pudesse se comunicar com o servidor da maneira correta?
Passei as últimas semanas trabalhando para responder a essas duas perguntas. Eu fiz uma versão web do meu aplicativo iOS e, embora não houvesse uma tradução direta de iOS para web (React Native-to-React.js) do código, as informações são passadas e armazenadas da mesma maneira, e isso significava que muitas funções poderiam ser reutilizadas. Por exemplo, todas as funções que lidam com arrastar exigiram apenas alguns pequenos ajustes. Isso é promissor porque significa que podemos desenvolver XBlocks sob medida para diferentes plataformas, mas ainda assim podemos reutilizar a estrutura por trás do código.
Também trabalhei na integração da avaliação com o workbench XBlock, pois isso seria uma parte importante do trabalho com a plataforma. Isso envolveu a modificação do próprio XBlock de arrastar e soltar, bem como implementar as chamadas AJAX corretas do componente React, de modo que o servidor saiba quando um aluno abre ou tenta um problema. O React facilitou a realização das chamadas necessárias e agora temos uma versão React Native e React.js deste XBlock! Espero que o edX torne os componentes React uma parte permanente da plataforma no futuro.
Capturas de tela do React Native Drag and Drop XBlock
Esquerdo: a visão inicial de um usuário do problema. Certo: Dar feedback por meio de alertas do iOS.
Resumo
Adorei poder trabalhar em vários projetos neste verão em termos das tecnologias que usei e das pessoas com quem trabalhei. Aprendi muitas coisas concretas e também ganhei habilidades sociais, como me comunicar efetivamente em uma equipe de engenharia de software. Esta foi uma oportunidade incrível, e obrigado a todos que fizeram isso! Gostaria de agradecer especialmente aos meus mentores, Chris Lee, Akiva Leffert e Nimisha Asthagiri, ao restante da equipe móvel e aos outros estagiários.
