Skip to content

Malausinus/memcheck

 
 

Repository files navigation

Archi, specification doc, resources

  • The Application project defines what we want to display, not how we display it. So it returns raw data, not transformed for display.
  • The UI project defines how we display the data sent by the Application. The UI project is not allowed to see the model, it only sees the Application.
  • In the Web UI, the html pages never show data as returned by the Application, but as returned by the controllers. It is the job of the controllers to adapt the data for correct display.

Decks

  • By design, a card may not be twice in a deck

Naming

  • A card in the Unknown heap is a card to Learn. A card in the another heap is a card to Repeat.

Notes for doc

  • The DB schema prevents deletion of a card used in a deck
  • About confidentiality of contents, note that moderators will be able to access data to check that no unbearable content is added (such as porn), even though a card is marked as private.
  • Les labels sont des indicateurs pour vous aider dans vos recherches. Ils ne garantissent pas une qualité ou une continuité de style entre cartes. Les combinaisons de critères de recherche sont souvent le bon moyen pour trouver le lot de cartes qui vous conviendra pour un sujet donné (par exemple les cartes de telle personne avec tel label).

Comment débuter

Choisir des cartes pour découvrir MemCheck

  • MemCheck contient beaucoup de cartes sur des sujets très variés. Parcourir la liste des labels peut vous aider à vous faire une idée. Par exemple, si vous décidez d'apprendre le découpage administratif de la France en régions et départements, un lot de cartes existe. Une des façons de sélectionner ces cartes est de faire une recherche sur le label "xxx". Cette recherche liste beaucoup de cartes. Vous choisissez lesquelles vous voulez (on peut par exemple souhaiter savoir localiser une région donnée, mais pas lister ses départements).

Web resources

Display

  • On my phone, in portrait orientation, window.innerwidth = 424. In landscape, window.innerwidth = 809.

Azure

  • L'App service plan doit être sous Windows pour que le l'App service y soit aussi et qu'on puisse utiliser du web deploy depuis VS.
  • The web site is deployed in an Azure App Service (aka a web app)
  • Après création de la web app, pour obtenir toutes les infos de publication, dans l'overview de la web app, clicker sur Get publish profile, en haut. Il faut importer ça dans VS pour créer un profil de publication.
  • The db is deployed as an Azure SQL Database

Tags

  • Would you consider tag hierarchizing ? This would be convenient for such categories as "English vocabulary/Cooking". No. Tagging is in fact the sheer opposite of hierarchizing, allowing all combinations. Hierarchies quickly become a nightmare: why not Cooking/Vocabulary instead ?

Unit tests

  • My initial plan was to use an in-memory database for unit tests (see UserCardDeletionsNotifierTests.OptionsForNewDB). Unfortunately, I discovered that this is not at all a good substitute to mimic the prod db. For example:
    • It will accept null values for non-nullable fields, where SQL Server throws an exception.
    • Some foreign key constraints can be violated without failure.
    • Cascade delete behaves differently.

In progress

Vidéo à propos de Azure functions avec GitHub : https://www.youtube.com/watch?v=LHJIGmJoS0c Add telemetry to Azure function: https://docs.microsoft.com/fr-fr/azure/azure-functions/functions-dotnet-class-library?tabs=v2%2Ccmd

Notifications

Remove notifications on search page

Table RegisteredNotifications Un utilisateur peut être abonné à :

  • une carte (lorsqu'une nouvelle version est créée, lorsque la carte est supprimée, optionnellement lorsque l'évaluation moyenne de la carte évolue) : type CardNotification
  • une recherche (liste les cartes qui apparaissent dans la recherche) : type SearchNotifications

On se souvient de la date de dernière information

Notifications par mail seulement, sinon la gestion de l'état lu ou pas d'une notif est un sujet pénible

Pas oublier de gérer la suppression de la notif lorsqu'une carte est supprimée. Mais alors, en cas de restoration de la carte (undelete), les abonnements sero

Pour pouvoir faire des notifs sur l'évolution de rating d'une carte, il faut que UserCardRating ait le datetime de l'évaluation. Est-ce qu'on veut notifier de l'évolution de la note moyenne sur toutes les cartes que l'utilisateur suit, ou seulement sur celles dont il est auteur ?

Ne pas notifier un utilisateur de ses propres modifs

pouvoir s'abonner/désabonner dans le mode édition

cartes supprimées

Paramètres utilisateur:

  • Envoi de mail pour les notifs
  • Abonnement automatique à une carte lorsque vous créez une version
  • Intervalle de notifications pour les changements d'évaluations moyennes sur les cartes auxquelles vous êtes abonné
  • Intervalle de notifications pour les recherches
  • Intervalle de notifications pour les versions de cartes (je ne suis pas clair si on veut ou pas supporter la notif immédiate)

Bugs

To do, at little cost

  • Upgrade Vue
  • Check by unit test that when a card is created, if the visibility is not public, the version creator is in the visibility list.
  • Check by unit test that it is not possible for a user to learn a card he does not have access to (both in repeat and learn modes)
  • Effacement image si pas utilisée. Nécessite d'abord recherche avec une image donnée pour pouvoir remplacer, et affichage "Utilisée dans n pages" avec lien
  • Prevent modification of a deck with no or too long description, or duplicated descriptions for the same user (reuse what was done in create deck, without forgetting to check ownership)
  • After creating a deck, show a message such as "Congratulations, you have created a deck. Next, you probably want to browse the cards and select some to add to the deck." (browse the cards étant un lien)
  • Faire le cheminement d'un nouvel utilisateur, pas à pas, pour qu'il soit bien guidé
  • Translate all the pages of the identity area (and consider improving each)
  • Ignorer les accents dans les recherches (cartes, images, labels). Peut-être qu'il suffit d'utiliser InvariantCultureIgnoreCase. Idéalement la recherche de "Que signifie bâbord" devrait trouver "Que signifie bâbord". ça va dans le sens d'avoir un vrai moteur de recherche
  • Upon creating a new version of a card, warn that this will impact n users who have it in a deck.
  • Reducing the visibility of a card should not permit to make it invisible to a user who has it in a deck, or to the owner of a version. Introduce function card visibility can be reduced : true if no other user has the card in a deck or has another version of the card. See comment in UpdateCard.Request.CheckValidityAsync.
  • Vérifier si getcards dans learn affiche l'info si le chargement échoue
  • View NuGet package updates on each project (should be done regularly)
  • Afficher des stats sur la page d'accueil : xxx cartes de votre paquet vont expirer aujourd'hui

To do at medium cost

  • Mettre l'envoi de mail dans une Azure function ? Permet de faire ça en asynchrone ? Et pourquoi pas tout faire en Azuere function ? Eg, le rating par un utilisateur. Par exemple en utilisant un blob trigger, et le blob est ce qu'il faut traiter. Il y a plein de triggers différents (un autre exemple est le queue trigger).
  • De même que j'ai optimisé GetCardsToLearn qui faisait trop de Include, voir si on peut faire pareil pour ce qu'affiche la page de démarrage.
  • Search page: Improve the select all check box: should be able to select all in one click, not two (by clicking in the box)
  • Implémenter le diff de versions d'images
  • Implémenter le restore de versions d'images
  • Revoir le critère de recherche de cartes "Propriétaire". On peut imaginer un critère "Utilisateur contributeur", au sens utilisateur créateur d'au moins une version de la carte. Voir s'il faut mentionner dans la GUI un coût en perf.
  • Review the code of UpdateCard: it must not be possible to lower a card's visibility so that an author of a version can't see it.
  • Supporter les gifs animés : https://commons.m.wikimedia.org/wiki/File:Cardinal_W_Q.gif (cardinale ouest)
  • User reputation. Public reputation is the average of this user's public cards evaluation. Private reputation is the same, but for private cards only (this can be useful for working on cards before making them public)

To do at big cost

  • Card authoring: Have the user review his changes before saving a new version of a resource (card, tag, deck)
  • Review security on all verbs of the application. For example, if someone calls the delete deck page with a deck he does not own as argument, check that it fails. Create an abstract ancestor Verb<TRequest, TResponse>, with a sealed method Run, which begins with checking the request's validity, and returns a TResponse. A question not so easy is: should Run be async? Securize the application: check that the user has the rights for an operation on application side. Be sure that the user is actually authentified. Use a token security system? For example, in MoveCardToHeap, we should check that the user is the owner of the deck
  • search page criteria. All criteria should adapt to the selected deck if it is inclusive (eg if in this deck there are only cards with owner A and B, don't offer filtering on owner = c)
    • card rating
      • card language
      • creation date
    • last version date
    • expiry date
    • find cards containing a given image (by image name). When this is implemented, update the link in the image list page. Maybe even support with vs without image (ie "Any" image)
      • author (including "Your cards"). This searches for a card which has this user as author of any version? Implémenter le filtrage sur le créateur de version dans la page de recherche. Garde comme nom auteur, et ça veut dire auteur d'une version. Puis implementer filteringOnOwnerCurrentUser, en faisant gaffe à la redondance avec visibilité privée. Supporter Owner of current version et Owner of any version.
    • Revoir le filtre de visibilité dans la recherche de carte : Ignorer / Privée / Visibilité restreinte / Visibilité publique (dans la Doc : Visibilité restreinte signifie que la carte n'est pas publique ; il peut s'agir d'une carte complètement privée pour vous, ou d'une carte qu'un utilisateur vous partage, ou que vous partagez avec un ou des utilisateurs). La privée ne doit pas être accessible si on choisit un autre utilisateur comme auteur d'une version
  • Support sorting in the search view
  • Quand on passe d'une recherche d'image au mode édition, la return url pourrait contenir un object code (comme ce qui est fait dans l'authentication) pour que les critères de recherche ne soient pas perdus au retour. Puis faire de même pour les autres recherche.
  • To improve the speed of loading the search page, the getting of static data and the first runquery could be run in parallel?
  • Do we want to support a user's default deck, which is selected by default in the various pages?
  • Support multiple versions of images? Not sure this is useful. A new version could simply be a new image?
  • Support other media types? Video, sound
  • Personal notes about a card : a user may associate personal textual info, private, about any card he can access (eg card says something, but user wants to write But my mother used to say xxx)
  • Offer the possibility to create a tag in place (in the authoring view)
  • Use ValidateAntiForgeryToken
  • En fin de modification d'une carte, recharger la carte (pour le cas où on continue à la modifier) ?
  • If we implement a card view mode, which is not editing, on end of edit we could switch to this mode for the edited card.
  • How to assign the admin role? Use the app settings in Azure? See class MemCheckUserRole. What actions to reserve to admin only (eg create language, rename tag)? Forbid two languages with same name. Backup method. Export database as json? Trouver où sont les backups dans Azure
  • Tags garbage collector: delete a tag not used by any card for more than a month
  • Support tags on media?
  • Create metrics for each function of the application project, for perf & feature tracking
  • Since a tag doesn't have a owner, we currently have no info about who created one. That's bad. Find the good way to answer this problem. For the card language, I think we want to allow creating one for admin only. Since tags have now owner, some of their actions are reserved to admin?
  • Home page: In the multi deck display, the links to the learning pages should select the appropriate deck
  • Tag family: should we support a tag which includes other ones? Eg histoire de France could include R�volution fran�aise, Premier empire, Charles de Gaulle). Or use a dot as separator? Eg maths would include maths.college and maths.lycée, and we could have Histoire.Histoire de France.Période napoléonienne
  • Industrialization: Use a proper solution for building and deploying. Could be GitHub actions. Use this opportunity for better version numbering
  • Should we check that the user is allowed to see a card each time we load one for this user ? (And update the DB if we find a discrepancy)
  • ABout perf, review this page, and study ResponseCompression: https://www.syncfusion.com/blogs/post/10-performance-improvement-tips-for-asp-net-core-3-0-applications.aspx. https://docs.microsoft.com/fr-fr/aspnet/core/performance/performance-best-practices?view=aspnetcore-3.1
  • Introduire une notion de leçon ? Par exemple Régions, départements et préfectures Françaises. Départements dans région. Région de département. Nombre de départements dans région. Préfectures
  • Make MemCheck.Application a separate service (an API running as a standalone project). Will allow even better decoupling.
    • The GUI (the web site) should not see the domain, but only talk with the application.
    • The GUI (the web site) should not see the database, but only talk with the application.
    • Needs that interactions with the application are authentified. This will need investigation of authentification tokens, or something like this.
  • Use an emulator to check usability of site on iPHone. Drop downs may not be a good idea.
  • Review Site.js : where is this used? How often is it used? What is the impact on perf?
  • Use specific resource files for display on small screen, to have smaller texts. Eg replace menu entry texts with icons. I hope we can tweak localizer for that
  • Forbid uploading an image in an image in the DB already has the same blob (implement a crc, hash of the blob?)
  • Fix the information about versions of MemCheck assemblies in the Admin page. Could be related to some browser cache or cookie
  • Make the app work even if changes are made simultaneously in various sessions. We're mostly ok. The authoring window is wrong in saving the whole card. It should only update the fields the user has changed, so that for example if he has added tags in another window, this info is not lost.
  • Limit length of user name to reduce the risk of display glitches. Something like 30 to 50 chars sounds like a good limit.
  • In the profile window, the Save button is useless
  • support displaying images in various sizes according to screen size
  • See what we need to do about RGPD, data ownership, with a cookie
  • Multilingual cards: a card can have a link to a card in another language, meaning that it is its version in this language. This is not related to a version, but to the card.
  • A user should be allowed to download all his cards (after all, this is his data)
  • The code for using tags in the GUI is duplicated between search, authoring and learn (both in JavaScript and Html). See how to do better. A component?
  • User option to not present the same not known card to learn in 24h : Stash learning failure for 24 hours in the discard pile. Carte coincée dans la pioche
  • Do something about orphan cards: cards whose only user with view is a deleted account (ie previous cards). Delete them? (by making them Previous)
  • Statistics page. Option to filter on cards the user has created a version of. See : nb decks containing a card. Average evaluation of card. Nb versions of card. Age of card. Nb versions of card. Nb users who have created versions of the card

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • C# 60.2%
  • JavaScript 26.6%
  • HTML 12.0%
  • CSS 1.2%