formalités administratives

Paperwork - Solution OpenSource de prise de notes et d'archivage alternative à Evernote, Microsoft OneNote et Google Keep

Voir le projet sur GitHub

Formalités administratives

OpenSource prise de notes et archivage

Rejoignez le chat

Paperwork est une alternative open-source et auto-hébergée à des services comme Evernote®, Microsoft OneNote® ou Google Keep®.

Version 2

Cette branche contient la deuxième itération de Paperwork, qui est une réécriture complète. Non seulement est-il basé sur un autre cadre - il est basé sur une pile technologique complètement différente. Il est dans sa phase de développement très précoce et n'est pas encore utilisable .

Si vous recherchez la version 1 de Paperwork basée sur Laravel, veuillez consulter cette section .

Contexte

La toute première version de Paperwork a été lancée en juillet 2014 comme un projet favori par ce type , principalement par frustration à propos des services existants (Evernote & autres), la peur enflammée par les révélations Snowden et la curiosité de savoir si l'effort aboutirait à quelque chose. les gens seraient intéressés. Et apparemment, il l'a fait. :) Bientôt, plus de gens formidables ont rejoint le projet et ont contribué .

Cependant, à l'origine, la technologie utilisée pour construire la toute première version (PHP 5, MySQL, Laravel 4, Angular & Bootstrap) a été choisie pour simplifier les choses et permettre une itération rapide. L'objectif principal du projet était le résultat réel, plutôt que toute sorte de finesse technologique.

Au fil du temps, deux observations concernant la technologie choisie ont été faites:

Alors que nous avions essentiellement du mal à mettre en œuvre les fonctionnalités les plus demandées, non seulement en raison de la dette technique due à de mauvaises décisions techniques en premier lieu, le projet est lentement devenu inactif.

Avec l'effort de refondre Paperwork sous sa forme actuelle (par exemple nettoyer le code sur le front et le back-end, mettre à jour vers la dernière version de Laravel, mettre à jour vers la dernière version de PHP, nettoyer le schéma de base de données, refactoriser l'API ...) étant significatif et une force claire sur le côté JavaScript du projet étant observable, il semble plus logique de reconstruire Paperwork à partir de zéro, en plus d'une architecture qui permet plus de flexibilité, une itération plus rapide, une meilleure structure et finalement un plus grande facilité d'utilisation / contribuer.

Alors, quoi maintenant?

Cette branche contient une toute première suggestion sur la façon dont la deuxième itération de Paperwork pourrait ressembler. Comme vous pouvez le remarquer, un changement majeur est la séparation claire des composants, faisant de cette branche (et j'espère bientôt l'ensemble du dépôt) une seule pièce du puzzle. Actuellement, il ne contient que le composant back-end - ou mieux, l'un d'entre eux - et n'inclut pas les composants frontaux que ce soit. L'idée est de construire la deuxième itération d'une manière plus modulaire et diversifiée, en choisissant le bon outil pour la tâche plutôt que de construire un monolithe qui est plus difficile à maintenir plus il grossit.

Toute personne intéressée à se mouiller les pieds est la bienvenue pour participer à la discussion et à la planification autour de Paperwork 2.

D'accord, cool. Mais qu'est-ce qui vous a pris si longtemps pour arriver à ce point?

Financement. Fondamentalement, ce point a été planifié et dirigé vers le milieu de l'année 2016. Depuis lors, différentes tentatives ont été faites pour obtenir du financement pour ce projet, à travers des individus mais aussi des programmes comme Prototypefund . L'idée générale était d'accélérer le développement en vous payant, les contributeurs, en utilisant une approche de type source de prime. Malheureusement, aucune de ces tentatives n'a abouti à un financement ou un investissement réel. À ce stade, mettre l'effort dans le développement actuel, au lieu de poursuivre des discussions et des applications pour de tels programmes semble avoir plus de sens.

J'aimerais aider!

N'hésitez pas à consulter cette section et à vous impliquer avec ce qui existe déjà pour avoir une idée de l'orientation de Paperwork. Consultez également le tableau du projet pour voir ce qui doit être fait ou suggérer quoi et comment faire.

N'hésitez pas à participer activement à la salle de discussion ou à envoyer un courriel à la liste de diffusion dev de Paperwork .

Usage

Ce référentiel structure et fédère tous les composants requis pour Paperwork.

$ git clone git@github.com:twostairs/paperwork.git

Docker Compose

L'installation est divisée en plusieurs fichiers de composition pouvant être exécutés individuellement. Cependant, pour que les servicefichiers de composition fonctionnent, le infrastructurefichier de composition doit être en cours d'exécution.

La composition de la composition dépend d'un réseau de recouvrement crypté à créer. Pour cela, votre environnement de docker doit avoir un essaim activé. Vous pouvez le faire en exécutant:

$ docker swarm init

Il n'y a pas besoin de rejoindre plus de membres. Seulement avec swarm activé le infrastructurepeut être lancé:

$ docker-compose -f ./docker-compose.infrastructure.yml up --build

Après la infrastructuremise en service tous les services peuvent être démarrés individuellement.

Service aux utilisateurs

Pour démarrer le service users ( service-users), exécutez la docker-composecommande suivante :

$ docker-compose -f ./docker-compose.service-users.yml up --build

Cela permet d'exécuter chaque service en tant que conteneur docker entièrement construit ou en tant qu'instance de développement. Par exemple, service-userspourrait également être exécuté localement, via npm run dev, à côté du infrastructurefichier de composition. Cela permettrait service-kong(à l'intérieur infrastructure) d'atteindre l'instance de développement local service-userset de permettre un développement facile sur des services individuels.

Afin de rendre un service local disponible à l'intérieur de docker, le devproxyest requis. Le programme devproxys'exécute automatiquement à l'intérieur de l' infrastructureinterface, expose le port 2222sur l'hôte et fournit un moyen de transférer les ports de développement locaux dans l'environnement docker. Afin de transférer le service-usersport local dans l'environnement docker, un port SSH est requis:

$ ssh -o "UserKnownHostsFile /dev/null" -o "StrictHostKeyChecking=no" -p 2222 -R 3000:127.0.0.1:3000 root@127.0.0.1

Le mot de passe root est root. Cela transmet le port local 3000dans le devproxy, de sorte que service-kongpourrait passer à service-userstravers devproxy:3000. Pour ce faire, l' environnement local service-usersdoit avoir la SERVICE_USERS_URLvariable d'environnement définie http://devproxy:3000, car il utilise cette variable pour configurer le kong en amont service-users.

Développer / contribuer

Veuillez vous reporter aux dépôts des composants afin d'obtenir plus d'informations sur la façon de contribuer.

Liste des composants

Texte d'origine