Zum Hauptinhalt springen

IntelliJ Plugin

caution

Diese Seite ist in Arbeit und gerade noch sehr chaotisch.

Anmerkungen​

  • GUI Designer von IntelliJ nicht nutzen
    • braucht Bytecode-Instrumentierung
    • ist mit Gradle nicht so einfach einzurichten.
  • Error Handling
    • Zentrale Fehlermeldungen bzw. Fehlerbehandlung in ErrorAdvice umsetzen
    • ErrorAdvice entspricht catch-all (Globaler Exception Handler) für Fehler, auf die nur mit Logging/Fehlermeldung reagiert werden kann
    • try-catch mit ErrorAdvice in jeden Einstiegspunkt in das Plugin einbauen. Nicht vorher, um den Code nicht unnötig zu verunreinigen

Konfiguration​

Das IntelliJ-Plugin ermöglicht die hochfrequentierte Erfassung von Daten zum Programmierprozess von Studierenden. Hierfür wird Trustee-Based Encryption eingesetzt. Für die Verschlüsselung muss der öffentliche Schlüssel (z.B. ss24.der) unter src/main/resources/encryption abgelegt werden. Anschließend in src/main/resources/application.properties konfigurieren:

fides.encryption.key = encryption/ss24.der
fides.encryption.enabled = false

Persistierung​

Daten werden im Homeverzeichnis des Benutzers ($HOME/.subato-intellij) gespeichert. Somit werden die Daten für jedes Benutzerkonto getrennt gespeichert. Zudem bleiben die Daten bei der Deinstallation des Plugins, der Deinstallation von IntelliJ oder einem IntelliJ-Update bestehen.

Theoretisch sollte das IntelliJ Configuration Verzeichnis diese Anforderungen erfüllen. Im IntelliJ-SDK können bestimmte Klassen (wie z.B. com.intellij.ide.util.PropertiesComponent) verwendet werden um Daten zu speichern. In der Vergangenheit gab es jedoch einige Berichte (1 2 3) darüber, dass dieses Verzeichnis bei IntelliJ-Updates nicht kopiert wurde, obwohl es das eigentlich tun sollte. Um die Datenerfassung somit nicht zu verfälschen werden diese Klassen nicht verwendet.

Post-Processing​

Die erfassten Daten müssen nach der Erfassungsperiode aus folgenden Gründen bereinigt werden:

  • SessionStopEvent kann fehlen wenn der IDE-Prozess abstürzt oder manuell gekillt wird. Auch muss berücksichtigt werden dass einige Benutzer den Laptop zuklappen ohne die IDE zu schließen.
  • Die Insertion-Reihenfolge der Events repräsentiert aufgrund des Throttling-Mechanismus von PluginDocumentListener nicht die tatsächliche Reihenfolge der Events. Die Insertion-Reihenfolge ist insgesamt nicht zuverlässig, da Events serverseitig in der Reihenfolge abgespeichert werden, in der sie hochgeladen werden. Jedes Event enthält mit occuredAt den tatsächlichen Zeitpunkt an dem es aufgetreten ist. Demnach muss über dieses Attribut nachträglich sortiert werden.
  • Viele Events (z.B. FileSaveEvent oder CompileEvent) erfassen immer den vollständigen Inhalt von Dateien ohne den vorherigen Inhalt zu berücksichtigen. Dadurch kommt es zu Duplikaten in Bezug auf den Inhalt von Dateien.