Ciao! Sono Linda Liu, una giovane in ascesa al MIT. Ho trascorso gli ultimi tre mesi qui in edX come stagista di ingegneria del software nel team Mobile, durante i quali ho avuto l'opportunità di lavorare in una gamma che va dal lato server allo sviluppo di iOS e Android. Vorrei parlare di due progetti: il primo, la riprogettazione del framework di controllo degli accessi edX e il secondo, l'esplorazione del framework React e il suo potenziale per edX.
Quadro di controllo degli accessi
Questo progetto in realtà è iniziato come una correzione di bug sulle date di inizio del corso per l'app mobile. Se l'autore di un corso non specifica una data di inizio per il proprio corso, l'impostazione predefinita è il 1 gennaio 2030. Sulla piattaforma web viene eseguito un controllo in modo che un utente visualizzi "non programmato" invece della data ovviamente falsa. Tuttavia, l'app mobile non esegue un controllo equivalente, quindi gli studenti hanno visto che i corsi sono iniziati nel 2030.
La prima potenziale soluzione che mi è venuta in mente è stata l'esecuzione di un controllo lato server nell'endpoint delle iscrizioni ai corsi dell'API mobile per vedere se la data di inizio era quella predefinita e fare in modo che l'API inviasse un messaggio Nonavalore in quel caso. Questa correzione è stata utile perché non richiedeva modifiche sul lato client. Tuttavia, ho scoperto che le app si aspettavano un timestamp dall'API mobile e si sono arrestate in modo anomalo quando tale aspettativa è stata infranta. Pertanto, una modifica puramente lato server non funzionerebbe.
Parlare delle potenziali correzioni si è evoluto in una discussione su come vengono eseguiti i controlli della data di inizio nella piattaforma. La piattaforma ha una grande funzione chiamata ha_accesso per questo scopo. Accetta un utente, un'azione e un oggetto e controlla se l'utente dispone delle autorizzazioni appropriate per eseguire l'azione sull'oggetto. Ad esempio, un uso di questa funzione consiste nel verificare se uno studente ha i permessi per iscriversi a un corso. A quel tempo, questa funzione restituiva semplicemente un booleano – I veri se l'accesso è concesso, Falso se l'accesso è negato. Dato che ci sono molte ragioni per cui l'accesso può essere negato e diverse ragioni potrebbero voler innescare comportamenti diversi, sembrava proprio così ha_accesso potrebbe beneficiare di un tipo di ritorno che contiene più dettagli. L'API mobile potrebbe quindi inviare i risultati del ha_accesso verificare al cliente, che quindi potrebbe utilizzare le informazioni per visualizzare un messaggio appropriato.
Il passaggio successivo è stato la progettazione del nuovo tipo di reso. Viene chiamato il nuovo oggetto Risposta di accesso. È un oggetto Python che contiene un booleano equivalente al valore dell'originale ha_accesso avrebbe restituito, una stringa di codice di errore e messaggi utente e sviluppatore. Le sue sottoclassi rappresentano gli errori che attualmente vogliamo affrontare, vale a dire Errore data di inizio (se il corso non è iniziato per l'utente), Errore di visibilità (se l'utente non dispone dei diritti di accesso richiesti), e Errore di traguardo (se l'utente ha un traguardo non raggiunto). Ho implementato le modifiche in quattro richieste pull separate: una per ciascuna "ha_accesso", l'API mobile, il client Androide il client iOS. Sebbene oltre l'ambito originale della correzione del bug, questa modifica consente ai controlli della data di inizio di spostarsi dal lato client al lato server. Come effetto collaterale, questa modifica semplifica notevolmente l'implementazione di funzionalità future (come le pietre miliari) nell'app mobile. Attraverso questo lavoro, ho avuto modo di toccare molti pezzi della base di codice edX, il che è stato davvero fantastico!
React Native per iOS e React.js
Il mio prossimo progetto era di natura più esplorativa, con meno obiettivi concreti. In edX, molte funzionalità devono essere sviluppate tre volte: una per il Web, una per iOS e una per Android. C'è stata una varietà di strumenti multipiattaforma per lo sviluppo mobile con il motto "scrivi una volta, usa ovunque" per combattere questo problema, ma hanno tentato di standardizzare troppo lo sviluppo: le app non potevano utilizzare i componenti della piattaforma nativa, quindi sono uscite sentirsi come pagine web mobili glorificate. Facebook ha sviluppato una soluzione a questo problema: un framework chiamato React Native che consente agli sviluppatori di creare app native utilizzando React (un framework dell'interfaccia utente per il Web).
L'idea guida alla base di React Native è "impara una volta, scrivi ovunque". Ciò significa che le piattaforme hanno strutture e stili diversi, quindi gli sviluppatori dovrebbero scrivere applicazioni diverse per ciascuna, ma con React Native tali applicazioni possono essere scritte con le stesse tecnologie sottostanti. Promette il meglio di entrambi i mondi: uno sviluppo efficiente e simile su tutte le piattaforme, ma con una buona sensazione nativa. Di recente, Facebook ha aperto la versione del framework per iOS. La speranza è che React Native (una volta open source anche per Android) e React.js consentiranno agli sviluppatori di riutilizzare il codice, riducendo così il lavoro necessario per lo sviluppo per tutte e tre le piattaforme.
Gli XBlock sono un buon candidato per questo progetto, perché sono piccoli pezzi modulari e le app mobili attualmente non ne hanno implementazioni native. Nello specifico, ho usato il trascina e rilascia XBlock, perché le interazioni che utilizza (in particolare il movimento di trascinamento) trarrebbero vantaggio dal rendering fluido che React promette. Ho iniziato effettuando una semplice valutazione drag and drop come un'applicazione iOS autonoma, per avere un'idea dello sviluppo con React Native. React è stato all'altezza delle sue promesse: il rendering è stato davvero fluido e i componenti e le informazioni sono stati organizzati in un modo davvero sensato.
Questo esperimento iniziale ha prodotto due domande di follow-up: quanto facilmente è stato possibile trasferire il codice in una valutazione di trascinamento della selezione di React.js per il browser? In secondo luogo, con quanta facilità è possibile integrare la valutazione drag and drop con il framework XBlock in modo tale che la valutazione possa comunicare con il server nel modo corretto?
Ho passato le ultime settimane a lavorare per rispondere a queste due domande. Ho creato una versione web della mia app iOS e, sebbene non esistesse una traduzione diretta del codice da iOS a web (React Native-to-React.js), le informazioni vengono trasmesse e archiviate allo stesso modo e ciò significava che molte funzioni potevano essere riutilizzate. Ad esempio, tutte le funzioni che gestiscono il trascinamento richiedono solo alcune piccole modifiche. Questo è promettente perché significa che possiamo sviluppare XBlock su misura per piattaforme diverse ma essere comunque in grado di riutilizzare la struttura dietro il codice.
Ho anche lavorato all'integrazione della valutazione con l'ambiente di lavoro XBlock, poiché sarebbe stata una parte importante del suo funzionamento con la piattaforma. Ciò ha comportato la modifica dello stesso XBlock drag and drop e l'implementazione delle chiamate AJAX corrette dal componente React in modo che il server sappia quando uno studente apre o tenta un problema. React ha reso facile effettuare le chiamate necessarie e ora abbiamo una versione React Native e React.js di questo XBlock! Spero che edX renda i componenti React una parte permanente della piattaforma in futuro.
Screenshot di React Native Drag and Drop XBlock
Sinistra: vista iniziale del problema da parte di un utente. Diritto: Fornire feedback tramite avvisi iOS.
Sintesi
Mi è piaciuto molto il fatto di poter lavorare su una varietà di progetti quest'estate in termini di tecnologie che ho usato e persone con cui ho lavorato. Ho imparato molte cose concrete e ho anche acquisito competenze trasversali, come come comunicare in modo efficace in un team di ingegneria del software. Questa è stata un'opportunità straordinaria e grazie a tutti coloro che l'hanno resa tale! Vorrei ringraziare in particolare i miei mentori, Chris Lee, Akiva Leffert e Nimisha Asthagiri, il resto del team mobile e gli altri stagisti.
