The Medical Memory
New Developer Onboarding
- Messaging, Basecamp-replacement for TMM
- AWS - the server(s)
- themedicalmemory.com DNS and static www site
- Repositories: themedicalmemory, tmm-server, tmm-server-cookbook, tmm-ops
- Agile JIRA
- Cloud logging for servers and devices
- Location of Android builds.
- SSL certificates
- TMMs Unused Stripe Account
- Production site
The Medical Memory software uses an Android application to upload video to an Amazon S3 bucket, in concert with a Ruby on Rails server for user and data management. The server also delivers an Angular front end app for browsing videos and managing users and data.
Bundler Rails project
Ruby on Rails dependencies are managed via bundler and the associated Gemfile.
Devise for authentication
Devise is used for mobile device and web session authentication. In order to use Devise with the Angular front end, angular-devise and various other libraries are required. Handle angular-devise changes in particular with care, as the library does not integrate trivially with Rails Devise.
[Android app details here - api level, target platform, supported platforms, special concerns].
Support for iOS devices is incoming.
tmm-ops stores mission critical files, data, and information for the administrator(s) responsible for handling deployment. Developers who are not required to make deployments theoretically should not have access.
- .pem files for ssh authentication
- bitbucket private key for deployment
- SSL certificates and private keys
- deployment instructions
This repository is used by AWS OpsWorks to create our RoR server instances. Newrelic is not used currently. The loggly recipe is the stdout->loggly pipe to allow all logging from our server be delivered to loggly.
- Loggly and Newrelic chef recipes
The server component of this software is a typical Ruby on Rails application, using MySQL and ActiveRecord. ActiveAdmin is used for the root-level admin power database reflection.
This server communicates with the Android application for session and upload metadata via JSON endpoints. The web application uses the same endpoints. All endpoints should use JSON data in their POST BODY, and expect JSON data for any other HTTP method. In some cases the server may also support form-field style POST data, but this should be avoided.
Note that Amazon Opsworks database configurations will overwrite the configuration you provide in
config/database.yml. RDS database configuration, via OpsWorks, determines the database(s) for each environment.
- v1 apis - Device only authentication
- v2 apis - Device or web app authentication
- traditional Rails structure
master always has the latest code in it. master is usually merged into qa on a weekly basis. If qa tester gives a thumbs up, qa is merged into production.
Development and qa are versioned according to the previous sprint number
I think we're on sprint 40 now
dev/qa was last deployed during sprint 39, so it is tagged with 0.38.1
the first time dev/qa was deployed during sprint 39 that commit was tagged 0.38.0
the next time dev/qa is deployed, since we are into sprint 40, it will be tagged 0.39.0 first
Production is on version 1.3.6 presently.
That means that there have been 3 significant releases since prod was originally deployed, and 6 hotfixes made to production during that time for whatever reason (like changing the SALES_FORCE_EMAIL_ADDRESS)
git checkout master git commit latest git tag <version> git push git push --tags git checkout qa git merge master git push
In general, create a branch for an issue that will take multiple commits. Any JIRA issue that is estimated 12h or greater is likely to satisfy this. Branch names should generally simply be the JIRA task number e.g. MM-824.
If a developer is working on a task that is likely to take a great many commits across multiple issues then it is reasonable to name their branch after the Epic containing the issues. Finally name a branch something unique with html-style hyphen word delimiting if the above rules do not apply.
Good reasons to push your local branch to remote/origin:
- Need to backup source due to long lifespan or storage instability.
- Pull requests.
- Other reasons to share code with another developer.
Always paste your code snippets during conversations with another developer using the code tags directly into Slack.
IntelliJ and Rubymine are excellent IDEs for Ruby on Rails projects due to the built-in debugger.
All log messages recorded by any TMM-controlled device in our pipeline should be sent to Loggly.
Use Chrome to debug Angularjs, with Developer Tools enabled, and "Disable cache" enabled under Developer Tools Settings.
Use of POSTMan is also recommended as a Chrome plugin for debugging HTTP endpoints.
Angular compiles all of the js files specified in application.js and app.js into a single app.js
angular module is injected into the document body, connecting the 'mm' module with the ng-app class.
Angular views stored in public/views. They're not compiled Rails assets though they could be.
- application.js configures the angular libraries
- Can the angular libraries in application.js be moved to app.js, and application.js removed?
- Chef recipes in tmm-server-cookbook
<script>links in index.html.erb
<h4 id="env">ENV vars</h4>
The following environment variables are for the development and qa environments. Do not, in general, change your local
RAILS_ENV away from test. If you want to run a command against a real environment, type in the
export RAILS_ENV=test export STRIPE_API_KEY=sk_test_4UgmCjS726NZHmE8ojBe3ul3 ## Development environment #export AWS_ACCESS_KEY_ID=AKIAIGKKSSPI3BUKVJZQ #export AWS_SECRET_ACCESS_KEY=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 #export AWS_S3_HASH=f1a4 #export AWS_PIPELINE_ID=1414427695862-x9trdp #export AWS_PIPELINE_PREVIEW_PRESET_ID=1409156750081-zb902y #export AWS_PIPELINE_SNS_TOPIC=tmm-development-pipeline-notifications ## QA environment export AWS_ACCESS_KEY_ID=AKIAJB56ETXJP2VGHFHA export AWS_SECRET_ACCESS_KEY=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 export AWS_REGION=us-west-2 export AWS_S3_HASH=f1a4 export AWS_PIPELINE_ID=1414427695862-x9trdp export AWS_PIPELINE_PREVIEW_PRESET_ID=1409156750081-zb902y export AWS_PIPELINE_SNS_TOPIC=tmm-qa-pipeline-notifications export SALES_FORCE_EMAIL_ADDRESSemail@example.com
# Angular dependencies and their load source # index.html.erb imports jquery 2.1.1 underscore 1.6.0 angularjs 1.2.21 angular-animate angular-resource angular-route angular-sanitize angular-touch angular-modal-service d3 nvd3 angularjs-nvd3-directives paginate-anything bootstrap 3.2.0 video.js # inserted into application.js jquery jquery_ujs turbolinks bootstrap tree # inserted into app.js angular-devise angular-ui-bootstrap-bower underscore.string/lib/underscore.string ./module.js tree # node_modules # Most or all could be moved into Gemfile karma phantomjs protractor ng-annotate # in tree our code d3 nvd3 angular-nvd3-directives paginate-anything angular-modal-service
- production (tmm-staging)
- Templates in /app/views
- Two .erb files - index.html.erb and tmm_email_template.html.erb
- .html files for Angular templates
<h3 id="pull_request">Code Review</h3>
- Fix most issues via a local branch named MMxxx (JIRA issue number)
- Push the branch to remote when it is fixed
- Go to the URL for the branch on bitbucket and click "Create pull request"
- Title should be MMxxx
- No description
- Assign to code review group (Bruce and Thomson)
- Click Approve if reviewing as a group
- Click Merge
- Close previous branch
- Do you use a password manager like 1password? You should for this project because of the many utilities that need to be integrated.
- Dont forget funny TmmPassword file containing auth to Linode (this should be in tmm-ops).
- ssh into servers
- use of rails console during ssh sessions