こんにちは！MITの3年生になるリンダ・リューです。ここ3ヶ月、edXのモバイルチームでソフトウェアエンジニアリングのインターンとして働いてきました。サーバーサイドからiOS、Android開発まで、幅広い分野に携わる機会に恵まれました。今日は2つのプロジェクトについてお話ししたいと思います。1つ目はedXのアクセス制御フレームワークの再設計、2つ目はReactフレームワークとedXにおけるその可能性の探求です。
アクセス制御フレームワーク
このプロジェクトは、モバイルアプリのコース開始日に関するバグ修正から始まりました。コース作成者がコースの開始日を指定していない場合、デフォルトで1年2030月2030日に設定されてしまいます。ウェブプラットフォームでは、明らかに誤った日付ではなく「未スケジュール」と表示されるようにチェックが行われます。しかし、モバイルアプリでは同様のチェックが行われないため、学生にはコースがXNUMX年に開始されたと表示されていました。
最初に思いついた修正方法は、モバイルAPIのコース登録エンドポイントでサーバー側チェックを実行して開始日がデフォルトかどうかを確認し、APIが なしその場合、値が正しく機能しない可能性があります。この修正はクライアント側の変更を必要としないため、非常に有効でした。しかし、アプリはモバイルAPIからのタイムスタンプを期待しており、その期待に反するとクラッシュすることがわかりました。そのため、サーバー側のみの変更ではうまくいきませんでした。
潜在的な修正についての議論は、プラットフォームでの開始日チェックの方法についての議論へと発展しました。プラットフォームは と呼ばれる大きな関数 アクセス権を持つ この目的のために、この関数はユーザー、アクション、オブジェクトを引数に取り、ユーザーがオブジェクトに対してアクションを実行するための適切な権限を持っているかどうかを確認します。例えば、この関数は学生がコースに登録する権限を持っているかどうかを確認します。当時、この関数は単にブール値を返していました。 ◯ アクセスが許可された場合、 × アクセスが拒否された場合。アクセスが拒否される理由は様々であり、理由によって異なる動作が引き起こされる可能性があることを考えると、 アクセス権を持つ より詳細な情報を含む戻り値の型があれば、モバイルAPIは アクセス権を持つ クライアントにチェックを送信し、その情報を使用して適切なメッセージを表示できます。
次のステップは、新しい戻り値の型を設計することでした。新しいオブジェクトは アクセスレスポンスこれは、元の値と同等のブール値を含むPythonオブジェクトです。 アクセス権を持つ 返されるはずのエラーコード、文字列エラーコード、そしてユーザーと開発者向けのメッセージです。そのサブクラスは、現在処理したいエラーを表します。 開始日エラー （ユーザーに対してコースがまだ開始されていない場合） 可視性エラー （ユーザーに必要なアクセス権がない場合） マイルストーンエラー （ユーザーが達成していないマイルストーンを持っている場合）。私は4つの別々のプルリクエストで変更を実装しました。それぞれ1つずつです。 「アクセス権あり」, モバイルAPI, Androidクライアント, iOSクライアントバグ修正の当初の範囲を超えていますが、この変更により、開始日のチェックをクライアント側からサーバー側に移行できるようになりました。副次的な効果として、この変更により、モバイルアプリへの将来の機能（マイルストーンなど）の実装が大幅に容易になります。この作業を通じて、edXのコードベースの多くの部分に触れることができ、とても刺激的でした！
iOS および React.js 向けの React Native
次のプロジェクトはより探索的な性質を持ち、具体的な目標は少なかった。edXでは、多くの機能を3回に分けて開発する必要がある。Web用、iOS用、Android用と、それぞれ1回ずつだ。この問題に対処するため、「一度書けばどこでも使える」をモットーとするモバイル開発用のクロスプラットフォームツールは数多く存在したが、それらは開発を標準化しようとしすぎていた。アプリはネイティブプラットフォームのコンポーネントを使用できず、まるでモバイルウェブページを美化したような仕上がりになっていた。Facebookはこの問題に対する解決策を開発しました。 React Nativeと呼ばれるフレームワーク これにより、開発者は React (Web 用の UI フレームワーク) を使用してネイティブ アプリを構築できるようになります。
React Nativeの根底にある理念は、「一度学べば、どこでも書ける」です。これは、プラットフォームごとに構造やスタイルが異なるため、開発者はそれぞれ異なるアプリケーションを開発する必要があることを意味します。しかし、React Nativeを使えば、これらのアプリケーションを共通の基盤技術で開発できます。React Nativeは、プラットフォーム間で効率的かつ類似した開発環境を実現しつつ、ネイティブの優れた操作性も維持できる、まさに両方のメリットを享受できると期待されています。最近、FacebookはiOS版のフレームワークをオープンソース化しました。React Native（Android版もオープンソース化されれば）とReact.jsによって、開発者がコードを再利用できるようになり、3つのプラットフォームすべてに対応した開発作業が軽減されることが期待されます。
XBlocksは小さなモジュールで構成されており、モバイルアプリにネイティブ実装されていないため、このプロジェクトに適しています。具体的には、 ドラッグアンドドロップXBlockなぜなら、Reactが使用するインタラクション（特にドラッグ動作）は、Reactが約束するスムーズなレンダリングの恩恵を受けるからです。まず、簡単なドラッグ＆ドロップの評価から始めました。 スタンドアロンのiOSアプリケーション、React Nativeを使った開発の感触を掴むために訪れました。Reactは期待通りの働きをしてくれました。レンダリングは非常にスムーズで、コンポーネントと情報は非常に分かりやすく整理されていました。
この最初の実験から、2つの疑問が浮かび上がりました。1つ目は、このコードをブラウザ用のReact.jsドラッグ＆ドロップ評価にどれだけ簡単に移植できるか、2つ目は、ドラッグ＆ドロップ評価をXBlockフレームワークにどれだけ簡単に統合し、評価がサーバーと正しく通信できるようにするか、という点です。
ここ数週間、この2つの疑問に答えるために取り組んできました。iOSアプリのWeb版を作成したのですが、iOSからWeb（React NativeからReact.js）への直接的なコード変換はできませんでしたが、情報の受け渡しと保存は同じ方法で行われ、多くの関数を再利用できることがわかりました。例えば、ドラッグ操作を扱うすべての関数は、わずかな調整だけで済みました。これは、異なるプラットフォーム向けにカスタマイズされたXBlocksを開発しながらも、コードの構造を再利用できることを意味するため、非常に期待できます。
また、評価ツールをXBlockワークベンチに統合する作業も行いました。これは、評価ツールをプラットフォームで動作させる上で重要な要素となるためです。ドラッグ＆ドロップ式のXBlock自体の修正に加え、Reactコンポーネントからの適切なAJAX呼び出しを実装し、学生が問題を開いたり、解いたりしたことをサーバーが認識できるようにしました。Reactのおかげで必要な呼び出しが容易になり、今ではこのXBlockのReact Native版とReact.js版が利用可能です。edXが将来的にReactコンポーネントをプラットフォームの恒久的な構成要素として採用してくれることを期待しています。
React Native ドラッグアンドドロップ XBlock のスクリーンショット
左派: 問題に対するユーザーの最初の見解。 右派: iOS アラート経由でフィードバックを提供します。
製品概要
この夏、様々なプロジェクトに携わることができ、使用した技術や共に働く人々との繋がりにおいて大変満足しています。具体的なことを学ぶだけでなく、ソフトウェアエンジニアリングチーム内で効果的なコミュニケーションを取る方法など、ソフトスキルも身につけることができました。これは素晴らしい機会であり、この機会を与えてくださった皆様に感謝いたします。特に、メンターのクリス・リー、アキバ・レファート、ニミシャ・アスタギリ、そしてモバイルチームの皆様、そして他のインターンの皆様に感謝申し上げます。
