Quepid fait de l'amélioration des résultats de recherche de votre application un processus d'ingénierie reproductible et fiable que toute l'équipe peut comprendre. Il traite de trois problématiques :
Notre collaboration est mauvaise. Faire des progrès holistiques en matière de recherche nécessite une collaboration approfondie et interfonctionnelle. L'envoi d'e-mails ou le suivi des exigences de recherche dans des feuilles de calcul ne suffiront pas.
Les tests de recherche sont difficiles. Les modifications de recherche sont transversales : la plupart des modifications poseront des problèmes. Les tests sont difficiles : vous ne pouvez pas exécuter des centaines de recherches après chaque changement de pertinence.
Les itérations sont lentes. Avancer semble impossible. Pour éviter de reculer, les progrès sont lents. Beaucoup abandonnent tout simplement la recherche, privant les utilisateurs des moyens de trouver des informations critiques.
Pour en savoir plus, veuillez consulter le site Web Quepid et le wiki Quepid.
Si vous êtes prêt à vous lancer, vous pouvez utiliser le service Hosted Quepid dès maintenant ou suivre les étapes d'installation pour configurer votre propre instance de Quepid.
Vous trouverez ci-dessous des informations relatives au développement du projet open source Quepid, principalement destinées aux personnes souhaitant étendre ce que Quepid peut faire !
Le provisionnement à partir d’une machine déjà construite prend environ 3 à 4 minutes. Le provisionnement à partir de zéro prend environ 20 minutes.
Assurez-vous d'avoir installé Docker. Allez ici https://www.docker.com/community-edition#/download pour les instructions d'installation. Et l'application Docker est lancée.
Pour installer à l'aide de Brew, suivez ces étapes :
brew cask install docker
brew cask install docker-toolbox
REMARQUE : vous pouvez recevoir un avertissement concernant la confiance en Oracle dès le premier essai. Ouvrez les Préférences Système > Sécurité et confidentialité, cliquez sur le bouton Autoriser Oracle, puis réessayez d'installer Docker-Toolbox.
Exécutez le script de configuration local basé sur Ruby pour configurer vos images Docker :
bin/setup_docker
Si vous souhaitez créer des cas contenant des centaines et des milliers de requêtes, procédez comme suit :
bin/docker r bundle exec thor sample_data:large_data
Ceci est utile pour les tests de résistance de Quepid ! Surtout l'application front-end !
Enfin, pour exécuter les notebooks Jupyter, vous devez exécuter :
bin/setup_jupyterlite
Lancez maintenant Quepid localement sur http://localhost :
bin/docker server
La réponse du serveur peut prendre jusqu'à une minute car il compile tous les actifs frontaux lors du premier appel.
Nous avons créé un script d'assistance pour exécuter et gérer l'application via Docker qui entoure la commande docker-compose
. Vous aurez besoin d’installer Ruby. Vous pouvez toujours utiliser docker compose
directement, mais pour les éléments de base, vous pouvez utiliser ce qui suit :
bin/docker server
ou bin/docker s
bin/docker bash
ou bin/docker ba
bin/docker console
ou bin/docker c
bin/docker run [COMMAND]
ou bin/docker r [COMMAND]
bin/docker daemon
ou bin/docker q
bin/docker destroy
ou bin/docker d
bin/docker r rails test:frontend
bin/docker r rails test
Lors de l'exécution de l'application sous Foreman, vous ne verrez qu'un journal des demandes. Pour une journalisation plus détaillée, exécutez ce qui suit :
tail -f log/development.log
Il existe trois types de tests que vous pouvez exécuter :
Ces tests exécutent les tests du côté Rails (principalement des contrôleurs API et des modèles) :
bin/docker r rails test
Exécutez un seul fichier de test via :
bin/docker r rails test test/models/user_test.rb
Ou même un seul test dans un fichier de test en passant le numéro de ligne !
bin/docker r rails test test/models/user_test.rb:33
Si vous devez réinitialiser la configuration de votre base de données de test, exécutez :
bin/docker r bin/rake db:drop RAILS_ENV=test
bin/docker r bin/rake db:create RAILS_ENV=test
Affichez les journaux générés lors des tests, définissez config.log_level = :debug
dans test.rb
, puis suivez le fichier journal via :
tail -f log/test.log
Pour vérifier la syntaxe JS :
bin/docker r rails test:jshint
Exécute des tests pour le côté angulaire. Il existe deux modes pour les tests de karma :
bin/docker r rails karma:run
bin/docker r bin/rake karma:start
Remarque : Les tests de karma nécessitent que les ressources soient précompilées, ce qui ajoute beaucoup de temps à l'exécution du test. Si vous apportez uniquement des modifications aux fichiers test/spec, il est recommandé d'exécuter les tests en mode surveillance ( bin/docker r bin/rake karma:start
). La mise en garde est que chaque fois que vous apportez une modification aux fichiers de l'application, vous devrez redémarrer le processus (ou utiliser le mode d'exécution unique).
Pour vérifier la syntaxe Ruby :
bin/docker r bundle exec rubocop
Rubocop peut souvent corriger automatiquement de nombreux problèmes de peluches rencontrés via --autocorrect-all
:
bin/docker r bundle exec rubocop --autocorrect-all
S'il y a un nouveau "Cop", comme ils appellent leurs règles, que nous n'aimons pas, vous pouvez l'ajouter au fichier ./rubocop.yml
.
Si vous souhaitez exécuter tous les tests en une seule fois (avant de valider et de pousser par exemple), exécutez simplement ces deux commandes :
bin/docker r rails test
bin/docker r rails test:frontend
Pour une raison quelconque, nous ne pouvons pas exécuter les deux avec une seule commande, même si nous devrions pouvoir le faire ! .
Si vous souhaitez créer BEAUCOUP de requêtes pour un utilisateur à des fins de test, exécutez
bin/docker r bin/rake db:seed:large_cases
Vous aurez deux utilisateurs, [email protected]
et [email protected]
avec lesquels tester.
Si vous souhaitez tester les blocs-notes Jupyterlite ou travailler avec un cas et un livre « réels », exécutez
bin/docker r bundle exec thor sample_data:haystack_party
Vous disposerez de nombreuses données utilisateur provenant du livre de notation Haystack et de l'affaire avec lesquelles travailler. Ces données proviennent du cas public https://app.quepid.com/case/6789/try/12?sort=default et https://app.quepid.com/books/25
Le débogage de Ruby dépend généralement de la situation, le moyen le plus simple est d'imprimer l'objet sur STDOUT :
puts object # Prints out the .to_s method of the object
puts object . inspect # Inspects the object and prints it out (includes the attributes)
pp object # Pretty Prints the inspected object (like .inspect but better)
Dans l'application Rails, vous pouvez utiliser le logger pour la sortie :
Rails . logger object . inspect
Si cela ne suffit pas et que vous souhaitez exécuter un débogueur, la gemme debug
est incluse pour cela. Voir https://guides.rubyonrails.org/debugging_rails_applications.html#debugging-with-the-debug-gem.
Nous disposons également de la gemme derailed
qui vous aide à comprendre les problèmes de mémoire.
bin/docker r bundle exec derailed bundle:mem
Lors de l'exécution de l'application, vous pouvez déboguer le javascript à l'aide de votre outil préféré, comme vous l'avez toujours fait.
Les fichiers javascript seront concaténés en un seul fichier, à l'aide du pipeline d'actifs Rails.
Vous pouvez désactiver cela en activant l'indicateur suivant dans config/environments/development.rb
:
# config.assets.debug = true
config . assets . debug = false
à
config . assets . debug = true
# config.assets.debug = false
Parce qu'il y a trop de fichiers Angular JS dans cette application et qu'en mode debug
, Rails essaiera de charger chaque fichier séparément, ce qui ralentit l'application et devient vraiment ennuyeux en mode développement d'attendre le chargement des scripts. C'est pourquoi il est désactivé par défaut.
PS : N'oubliez pas de redémarrer le serveur lorsque vous modifiez la config.
Veuillez également noter que les fichiers secure.js
, application.js
et admin.js
sont utilisés pour charger toutes les dépendances JavaScript et CSS via le pipeline Rails Asset. Si vous déboguez Bootstrap, vous aurez besoin de fichiers individuels. Remplacez donc //= require sprockets
par //= require bootstrap-sprockets
.
docker-compose.override.yml.example
peut être copié dans docker-compose.override.yml
et l'utiliser pour remplacer les variables d'environnement ou travailler avec une copie locale de la bibliothèque JS splainer-search pendant le développement défini dans docker-compose.yml
. Un exemple est inclus. Mettez simplement à jour le chemin vers splainer-search
avec votre caisse locale ! https://docs.docker.com/compose/extends/
Cette application propose deux manières d'exécuter des scripts : rake
& thor
.
Rake est idéal pour les tâches simples qui dépendent de l'environnement de l'application et pour les tâches par défaut fournies par Rails.
Alors que Thor est un outil plus puissant pour écrire des scripts qui prennent en compte les arguments bien mieux que Rake.
Pour voir quelles tâches de râteau sont disponibles, exécutez :
bin/docker r bin/rake -T
Remarque : l'utilisation de bin/rake
garantit que la version de rake
en cours d'exécution est celle verrouillée sur le Gemfile.lock
de l'application (pour éviter les conflits avec d'autres versions qui pourraient être installées sur votre système). C'est l'équivalent du bundle exec rake
.
Tâches de râteau courantes que vous pourriez utiliser :
# db
bin/docker r bin/rake db:create
bin/docker r bin/rake db:drop
bin/docker r bin/rake db:migrate
bin/docker r bin/rake db:rollback
bin/docker r bin/rake db:schema:load
bin/docker r bin/rake db:seed
bin/docker r bin/rake db:setup
# show routes
bin/docker r bin/rails routes
# tests
bin/docker r rails test
bin/docker r rails test:frontend
bin/docker r bin/rake test:jshint
Voir les tâches disponibles :
bin/docker r bundle exec thor list
Une documentation supplémentaire se trouve dans la documentation d'exploitation.
Vous devrez configurer Elasticsearch pour accepter les requêtes du navigateur à l'aide de CORS. Pour activer CORS, ajoutez ce qui suit au fichier de configuration d'elasticsearch. Habituellement, ce fichier se trouve à proximité de l'exécutable elasticsearch dans config/elasticsearch.yml
.
http.cors :
enabled : true
allow-origin : /https?://localhost(:[0-9]+)?/
Voir plus de détails sur le wiki à https://github.com/o19s/quepid/wiki/Troubleshooting-Elasticsearch-and-Quepid
En général, vous feriez simplement :
bin/docker r yarn add foobar
ou
bin/docker r yarn upgrade foobar
qui installera/mettra à niveau le module Node, puis enregistrera cette dépendance dans package.json
.
Ensuite, archivez les fichiers package.json
et yarn.lock
mis à jour.
Utilisez bin/docker r yarn outdated
pour voir quels packages vous pouvez mettre à jour !!!!
En général, vous feriez simplement :
bin/docker r bundle add foobar
qui installera le nouveau Gem, puis enregistrera cette dépendance dans Gemfile
.
Vous pouvez également mettre à niveau une gem qui n'a pas de version spécifique dans Gemfile
via :
bin/docker r bundle update foobar
Vous pouvez supprimer une gemme via :
bin/docker r bundle remove foobar
Ensuite, archivez les fichiers Gemfile
et Gemfile.lock
mis à jour. Pour faire bonne mesure, exécutez le bin/setup_docker
.
Pour comprendre si vous avez des gemmes obsolètes, exécutez :
bin/docker r bundle outdated --groups
Décommentez dans docker-compose.yml
le paramètre - RAILS_RELATIVE_URL_ROOT=/quepid-app
puis ouvrez http://localhost:3000/quepid-app.
Ces étapes devraient vous permettre d'exécuter localement une version de production (par rapport à la version de développeur) de Quepid.
docker build -t o19s/quepid -f Dockerfile.prod .
Cela pourrait entraîner une erreur lors de la première exécution. Réessayez si cela se produit
docker tag o19s/quepid o19s/quepid:$QUEPID_VERSION
docker compose up -d mysql
docker compose run --rm app bin/rake db:setup
Mettez à jour votre fichier docker-compose.prod.yml pour utiliser votre image en mettant à jour la version de l'image dans l' image: o19s/quepid:10.0.0
Démarrez l'application soit en tant que démon (-d), soit en tant que conteneur actif
docker compose up [-d]
Il existe un répertoire .ssl
qui contient les fichiers de clé et de certificat utilisés pour SSL. Il s'agit d'un certificat généré auto-signé destiné à être utilisé UNIQUEMENT en développement !
La clé/certificat a été généré à l'aide de la commande suivante :
openssl req -new -newkey rsa:2048 -sha1 -days 365 -nodes -x509 -keyout .ssl/localhost.key -out .ssl/localhost.crt
PS : Il n'est pas nécessaire de recommencer.
Le fichier docker-compose.yml
contient un proxy inverse nginx qui utilise ces certificats. Vous pouvez accéder à Quepid sur https://localhost ou http://localhost. (Quepid sera toujours disponible via http sur le port 80.)
Ajoutez des documents de développement ici !
Le déploiement par le développeur des informations d'identification de la console d'administration Keycloak est admin
et password
.
Voici un exemple de génération d'une migration :
bin/docker r bundle exec bin/rails g migration FixCuratorVariablesTriesForeignKeyName
Suivi de bin/docker r bundle exec rake db:migrate
Vous devez également mettre à jour les données d'annotation du schéma en exécutant bin/docker r bundle exec annotations
lorsque vous modifiez le schéma.
Modifiez le fichier Gemfile
puis exécutez :
bin/docker r bundle install
Vous verrez un Gemfile.lock
mis à jour, allez-y et vérifiez-le ainsi que Gemfile
dans Git.
Nous utilisons Angular 1 pour l'application interactive principale et, dans ce cadre, nous utilisons le package angular-ui-bootstrap
pour tous nos composants d'interface utilisateur. Ce package est lié à Bootstrap version 3.
Nous importons le CSS Bootstrap 3 directement via le fichier bootstrap3.css
.
Pour le reste de Quepid, nous utilisons Bootstrap 5 ! Cela est inclus via le package.json
en utilisant NPM. Voir admin.js
pour la ligne //= require bootstrap/dist/js/bootstrap.bundle
.
Nous utilisons actuellement Rails Sprockets pour tout compiler, mais nous rêvons de passer à Prop Shaft, et peut-être au js-bundling.
La police aller provient de FontSquirrel et le .ttf est converti au format .woff2.
Exécutez le ./bin/setup_jupyterlite
pour mettre à jour le fichier d'archive ./jupyterlite/notebooks.gz
. Cela configure également les fichiers statiques dans le répertoire ./public/notebooks
. Cependant, afin de ne pas archiver des centaines de fichiers, nous ignorons ce répertoire de Github. Au moment asset:precompile
nous décompressons le fichier ./jupyterlite/notebooks.gz
à la place. Cela fonctionne sur Heroku et l'image Docker de production.
Pour mettre à jour la version de Jupyterlite, modifiez Dockerfile.dev
et Dockerfile.prod
et mettez à jour la version pip install
.
Question? Jupyterlite fonctionne-t-il dans localhost ????
Consultez cet excellent article de blog : https://keygen.sh/blog/how-to-implement-api-key-authentication-in-rails-without-devise/.
Il existe un pipeline de déploiement de code sur le site http://quepid-staging.herokuapp.com qui est exécuté en cas de validation réussie sur main
.
Si vous avez des migrations en attente, vous devrez les exécuter via :
heroku run bin/rake db:migrate -a quepid-staging
heroku restart -a quepid-staging
Les comptes suivants sont créés via le processus bin/setup_docker
. Ils suivent tous le format suivant :
email: quepid+[type]@o19s.com
password: password
où type est l'un des éléments suivants :
admin
: Un compte administrateurrealisticActivity
: Un utilisateur avec divers cas qui démontrent Quepid, y compris le cas et le livre de démonstration Haystack Rating Party, et est membre de l'équipe 'OSC'.100sOfQueries
: Un utilisateur avec un cas Solr qui a des centaines de requêtes (généralement désactivées)1000sOfQueries
: Un utilisateur avec un cas Solr qui a des milliers de requêtes (généralement désactivées)oscOwner
: Un utilisateur propriétaire de l'équipe 'OSC'oscMember
: Un utilisateur qui est membre de l'équipe 'OSC'Consultez le fichier de mappage de données pour plus d'informations sur la structure des données de l'application.
Reconstruisez l'ERD via bin/docker r bundle exec rake erd:image
Consultez le fichier de structure de l'application pour plus d'informations sur la structure de Quepid.
Consultez le fichier de documentation d'exploitation pour plus d'informations sur la façon dont Quepid peut être utilisé et configuré pour votre entreprise.
Quepid ne serait pas possible sans la contribution de nombreux individus et organisations.
Plus précisément, nous souhaitons remercier Erik Bugge et les gens de Kobler pour avoir financé la fonctionnalité Only Rated publiée dans Quepid 6.4.0.
Quepid n'a pas toujours été open source ! Consultez les crédits pour une liste des contributeurs au projet.
Si vous souhaitez financer le développement d'une nouvelle fonctionnalité pour Quepid, contactez-nous !