Ich bin Ben McMorran, ein aufstrebender Junior, der Informatik am Worcester Polytechnic Institute studiert. Die letzten zwölf Wochen habe ich als Praktikant im Bereich Softwareentwicklung im Team Lehren und Lernen (TNL) gearbeitet. Dies ist mein zweiter Sommer als Praktikant hier bei edX. Obwohl es viele Aufgaben gibt, an denen ich während meiner Zeit hier gearbeitet habe, gibt es zwei Hauptprojekte, die ich hervorheben möchte.
API- und Front-End-Entwicklung für Teams
Das erste Projekt, an dem ich gearbeitet habe, war die Teams-Funktion für das LMS, die sich noch in der Entwicklung befindet. Diese Funktion erleichtert es den Schülern, sich in kleinen Gruppen zu verbinden und miteinander zu unterhalten, und erhöht die Viralität von edX-Kursen. Die Entwicklung für diese Funktion umfasste die Verwendung von Front-End-Arbeiten Backbone (Rückgrat) und API-Implementierung mit der Django-Rest-Framework (DRF). Während ich Backbone von der Verbesserung des Kursveröffentlichungs-Workflows im letzten Sommer kannte, war die API-Arbeit neu für mich.
Während der gesamten Entwicklung lag ein starker Fokus auf der Schaffung entkoppelter, wiederverwendbarer Komponenten. Ein Beispiel dafür ist die Art und Weise, wie wir Paginierungssteuerungen für Team- und Themenlisten entworfen haben. Wir haben mehrere entwickelt generische, wiederverwendbare Paging-Steuerelemente kompatibel mit den Seiteninformationen, die DRF zurückgibt:
Diese Steuerelemente, wie oben abgebildet, lassen sich in der zukünftigen Entwicklung einfach in andere edX-API-Endpunkte integrieren.
Die erweiterbare Felder Ich habe zur Unterstützung der Team-API ein weiteres Beispiel für wiederverwendbaren Code erstellt. Kunden können im Rahmen der Erstanfrage angeben, zu welchen Feldern sie weitere Informationen wünschen. Beispielsweise könnte eine Anfrage nach Teaminformationen angeben, dass das Benutzerfeld erweitert werden sollte. Anstatt nur Benutzernamen bereitzustellen, würde die Antwort dann Details zu jedem Benutzer im Team enthalten. Dies reduziert die Anzahl der Anforderungen, die der Client stellen muss, oder reduziert die Größe der Antwort, wenn die Felder unnötig sind. Erweiterbare Felder lassen sich einfach in jede DRF-API integrieren, indem das Feld als angegeben wird ExpandableField und Bereitstellen eines Serializers für den reduzierten und erweiterten Zustand. Mit dem Wachstum der edX-Plattform wird dieser Fokus auf wiederverwendbare Komponenten nur noch wichtiger.
Diskussionsforen Leistungsverbesserungen
Ich habe auch mehrere Wochen damit verbracht, die Leistung unserer Diskussionsforen zu verbessern. Wir verwenden New Relic, um die Server zu überwachen, auf denen edx.org läuft. Anfang dieses Sommers erfasste die Überwachung eine Spur, die zeigte, dass es über 40 Sekunden dauerte, einen Kommentar in einem bestimmten Kurs zu posten, was weitere Untersuchungen veranlasste.
Ich habe den problematischen Kurs in meine lokale Entwicklungsumgebung geladen und versucht, einen Kommentar zu posten. Die Profilerstellung ergab, dass der Server die überwiegende Zeit damit verbrachte, ein Analyseereignis auszusenden, das gegebenenfalls das Diskussionsthema enthält. Das Thema einer Diskussionskomponente bietet eine Möglichkeit, Diskussionsthreads zu filtern und zu gruppieren. Beispielsweise haben alle Threads in einer Inline-Diskussionskomponente dasselbe Thema.
In der Diskussions-App werden Kommentare basierend auf einer Diskussions-ID erstellt, die vom Kommentardienst verwendet wird. Das Diskussionsthema zu einem bestimmten Kommentar wird jedoch im Rahmen des Kurses im Diskussionsmodul gespeichert. Diskussionsmodule kennen ihre zugeordnete Diskussions-ID, aber es gab keine effiziente Möglichkeit, das Thema der Diskussion zu erhalten, wenn Sie nur die Diskussions-ID kannten. Der problematische Kurs hatte fast 1000 Diskussionsmodule. Erstellen des Analyseereignisses geladen jeder einzelne um das Diskussionsthema zu entdecken!
Mein erster Gedanke war, der Diskussions-ID einen Index hinzuzufügen. Dies erwies sich als problematisch, da es mehrere Persistenzmechanismen für Kurse in der edX-Plattform gibt (alte Mongo-, Split-Mongo- und XML-Kurse). Die Verwendung eines neuen Index würde drastische Änderungen erfordern. Stattdessen habe ich eine erstellt Zuordnung von Diskussions-IDs zu zugehörigen Modulen. Diese Zuordnung wird in der MySQL-Datenbank zwischengespeichert, wenn ein Kurs veröffentlicht wird. Da sich Kursdaten selten ändern, aber oft darauf zugegriffen wird, sind die relativ hohen Kosten zum Erstellen der Kartierung durch Durchqueren des gesamten Kurses akzeptabel, da dies selten vorkommt.
Nachdem mein Fix implementiert war, musste ich ihn durch Lasttests verifizieren. Dieser Prozess war ganz neu für mich. Obwohl es an sich keine Herausforderung war, brauchte ich eine Weile, um auf Touren zu kommen. Ich lief die bestehenden Foren Heuschrecke Tests gegen den problematischen Kurs, bevor und nachdem mein Fix angewendet wurde.
Vor dem Fix dauerte es etwa 20 Sekunden, um über die halbe Stunde Lasttest einen Kommentar zu erstellen. Beachten Sie die große Anzahl von MongoDB-Abfragen, 1320, in der Aufschlüsselungstabelle, wenn jedes Diskussionsmodul im Kurs geladen wird.
Nach dem Fix dauerte es etwa vier Sekunden, um über die halbe Stunde Lasttest einen Kommentar zu erstellen. Beachten Sie, dass die Anzahl der MongoDB-Abfragen jetzt nur noch 6.75 beträgt.
Die Reaktionszeiten waren etwa fünfmal schneller und die Anzahl der MongoDB-Abfragen wurde mit dem Fix erheblich reduziert. Es befindet sich jetzt im Hauptzweig der edx-Plattform und sollte bald auf edx.org bereitgestellt werden.
Zusammenfassend…
Meine Erfahrung als edX-Praktikant war fantastisch. Eingebettet in das TNL-Team fühlte es sich an, als wäre ich ein Vollzeitangestellter. Ich konnte echte Tickets annehmen und die Auswirkungen meiner Arbeit auf der Plattform sehen. Die Entwicklung eines Open-Source-Projekts ist großartig. Ich möchte Andy Armstrong, Christina Roberts, dem gesamten TNL-Team und edX dafür danken, dass sie diesen Sommer zu einem großartigen Erlebnis gemacht haben!
