-
Notifications
You must be signed in to change notification settings - Fork 7
Home
-
GitHub/Wiki (YOU ARE HERE)
Anything that is mostly relevant to engineers, and only engineers.
-
GitHub/README
Basic setup and usage information.
-
GitHub/Issues
Engineering-related discussion.
-
Features and bugs for progress tracking, with occasional cross-links to Basecamp for specs.
-
Business- and design-related discussion.
-
Roadmaps and retrospective voting.
Tahi is a platform for submitting and revising academic manuscripts. It is owned by the Public Library of Science (PLOS) and developed by a variety of consultants, including Neo (located in NYC and SF), MutuallyHuman (located in Columbus), and a few others.
Tahi's users are not only non-technical employees at PLOS and its constituent journals, but also their developers, who will have access to the open-source Tahi codebase, making them able to tweak and write their own journal-specific extensions.
images/tahi_architecture.png Enlarge
The core Tahi application is built with Rails and EmberJS.
The Rails asset pipeline has been eschewed in favor of ember-cli's include_ember_script_tags().
Ember-specific code lives in the client/ subdirectory.
PostgreSQL is the ActiveRecord store of choice in all environments.
Slanger and web sockets are used to perform live updates for conversations and workflow updates.
Sidekiq is used for background jobs such as generating epub and pdf files, and sending e-mails.
Redis is a dependency of both Slanger and Sidekiq, and must be running for the app server to function.
Most Tahi interface functionality is implemented in the form of Rails plugins.
It's preferred to make a separate repository for plugins. Right now, some standard functionality is stored in the Tahi repository in the engines/ subdirectory, but it will be transitioned to external repos.
One of Tahi's core features is the ability to upload DocX files (the lingua franca of academic publishing) and automatically translate them to HTML editable within Tahi itself.
Since manuscripts can contain everything from images to complex mathematical formulae, this is a more complex operation than you might expect. It is handled by a separate tool called iHat.
Standard rspec-rails is used for testing Rails components.
Capybara is used for browser tests, which live in the spec/features/ folder.
QUnit is used for Ember tests, which live in the client/tests/ folder.
Capybara tests are older, and will be mostly eventually phased out in favor of QUnit integration tests.