Science History Institute Digital Collections
In progress re-write of our Digital Collections application.
This one is based on the kithe toolkit, being developed in tandem.
To set up a development instance on your workstation.
- ruby installed (I like using chruby and ruby-build to install/manage rubies, some like rvm)
gem install bundleron new ruby installation
- (MacOS) XCode installed so C dependencies can be compiled
- Postgres installed and running -- on MacOS, I like https://postgresapp.com/
yarninstalled for webpacker -- on MacOS,
brew install yarn.
- vips installed -- on MacOS
brew install vips
$ git clone firstname.lastname@example.org:sciencehistory/scihist_digicoll.git $ cd scihist_digicoll $ bundle install $ yarn install $ rake db:setup
Run app with
./rails server, it will be available at
If you want to change defaults to our config/env variables (managed by
ScihistDigicoll::Env), you can set them in your shell ENV (via .bash_profile, on the command line, or otherwise), OR you can create a
local_env_development.yml file. The latter may make sense if you don't want your particular settings to effect the test environment.
For instance, you can switch between whether files are stored in dev-s3 mode, or in the local file system, with:
STORAGE_MODE=dev_file rails server
Or by putting in a local_env[_development].yml file:
- This is something of an experiment
var $ = window.jQuery;
- We are still using sprockets to control our CSS (scss), not webpacker.
- So at the moment our app includes both a sprockets manifest and a webpacker manifest in it's layout, and compiles both in dev and in production assets:precompile. Rails integration should make this just work. We have not at present experimented with running
./bin/webpack-dev-serverseparately in dev, we're just letting Rails do it the slower but just-works way.
Some references I found good for understanding webpacker in Rails:
We deploy to AWS, the deployment is done mostly automatically by some ansible playbooks:
There is some additional manual setup for S3 buckets:
We shouldn't have to use the rake tasks as much, since there is now admin web interface for creating and editing accounts. But they are still there, as they can be convenient for setting up a dev environment or perhaps bootstrapping a production environment with an admin account, or in general automating things involving users.
./bin/rake scihist:user:create[email@example.com] ./bin/rake scihist:user:send_password_reset[firstname.lastname@example.org] ./bin/rake scihist:user:test:create[email@example.com,password] ./bin/rake scihist:user:admin:grant[firstname.lastname@example.org] ./bin/rake scihist:user:admin:revoke[email@example.com] ./bin/rake scihist:user:admin:list
logins_disabled: true in
./config/local_env.yml, or somehow set a shell env variable
LOGINS_DISABLED=true -- then restart the app to pick up the changes. Now the app won't let anyone at all log in, and won't let anyone already logged in access protected screens.
This can be useful if we need to do some maintenance that doesn't bring down the public interface, but we want to keep staff out while it goes on, so they can't edit things.
This feature was in our v1 sufia-based app, we copied it over.