== Tessitura {}[https://travis-ci.org/danascheider/tessitura] {}[https://codeclimate.com/github/danascheider/canto] {}[https://coveralls.io/r/danascheider/canto] {}[https://gemnasium.com/danascheider/tessitura]

Tessitura is a web-based career management app for classical singers. It provides a variety of functionality tailored to the specific needs of opera singers. This repo contains the code for the back-end Sinatra API. The API uses MySQL with the Mysql2 adapter and with the Sequel gem handling ORM functions. The front end is being developed in {another repo}[https://github.com/danascheider/tessitura-front-end] using Backbone.js.

=== Models For the most up-to-date information about models and their attributes, see the most recent schema file in the +/db/schema_migrations+ directory.

==== Users

Users can be regular users or admins. Users own task lists (and by extension, the tasks on the lists), and have a many-to-many relationship to programs (which act in this context as recommendations). They also have a many-to-one association with Fachs. Users are assumed to be classical singers and have the following attributes:

• ID
• Username
• Password
• E-mail address
• First name
• Last name
• Birthdate
• Fach ID
• City
• Country
• Created at
• Updated at

Ultimately, user attributes will be used to provide the users with relevant information and recommendations.

==== Task Lists

TaskLists are owned by a user and contain tasks. They currently do not have a very prominent place in the app, and will soon either be modified to serve a more important organizational function, or replaced with another model that fills such a role. Task lists have the following attributes:

• ID
• Title
• User ID
• Created at
• Updated at

==== Tasks

Tasks belong to TaskLists, which are owned by a User. Users can have multiple lists. Tasks have the following attributes:

• ID
• Task list ID
• Title
• Status:
  • 'New'
  • 'In Progress'
  • 'Blocking'
  • 'Complete'
• Priority:
  • 'Urgent'
  • 'High'
  • 'Normal'
  • 'Low'
  • 'Not Important'
• Description
• Deadline
• Created at
• Updated at

==== Organizations

An organization is any organization offering programs of interest to Tessitura subscribers. They may be, among other things, opera companies, churches, government agencies, universities, and foundations. Each organization can own multiple programs. Organizations have the following attributes:

• ID
• Name
• Address 1
• Address 2
• Country
• Region (or state)
• City
• Postal code (ZIP)
• Web address
• Contact name
• Contact phone 1
• Contact phone 2
• Contact email 1
• Contact email 2
• Fax
• Created at
• Updated at

When an organization is destroyed, all the programs it owns are destroyed with it.

==== Programs

Programs are any of a variety of types of events or activities of interest to Tessitura subscribers. The Program model stores data about a program that remains consistent from year to year (e.g., geographic region, age restrictions, etc.). Each program is owned by an Organization and associated with many Users who have been matched with the Program by an algorithm handling recommendations (not implemented yet). The association between Users and Programs is coordinated through the programs_users join table.

Programs are typically cyclical in nature, revolving around semesters, seasons, fiscal years, or some other recurring period of time. Data specific to a particular cycle is stored in the Seasons table. Each program can have many seasons.

Programs have the following attributes:

• ID
• Organization ID
• Type
• Minimum age
• Maximum age
• Web site
• Contact name
• Contact phone
• Contact e-mail
• Name
• Country
• Region (or state)
• City
• Created at
• Updated at

==== Seasons

Seasons contain data about Programs that is specific to a period of time, such as a fiscal year, season, semester, or other recurrent cycle. Each Program has multiple Seasons, and each Season belongs to a single Program.

Seasons own both listings (one-to-one) and auditions (one-to-many). Seasons have the following attributes:

• ID
• Program ID
• Start date
• End date
• Early bird deadline
• Priority deadline
• Final deadline
• Payments
• Program fees
• Peripheral fees
• Application fee
• Stale (boolean applied to seasons whose deadlines have passed)
• Created at
• Updated at

==== Listings

Listings are audition listings. Listings have a many-to-many relationship to users, allowing them to be treated as recommendations to a certain user. They also may be associated with one or more auditions (representations of auditions by time and place, along with other audition-specific information). Currently, they have the following attributes:

• ID
• Season ID
• Title
• Created at
• Updated at

==== Auditions

Auditions are representations of physical audition times and places. They also store information specific to a given audition time or location, such as the deadline for submitting an application to participate in that audition (which may be different from the deadline for other auditions for the same opportunity). Auditions are owned by listings and are destroyed when their listing is destroyed. Auditions currently have the following attributes:

• Date
• City
• Region (or state)
• Country
• Deadline
• Fee
• Pianist provided (boolean)
• Can bring own pianist (boolean)
• Pianist fee
• Created at
• Updated at

==== Fachs

Fachs store the characteristics of voices. They have the following attributes:

• Type (soprano, mezzo-soprano, contralto, countertenor, tenor, baritone, or bass)
• Quality (lyric or dramatic)
• Coloratura (boolean)

Fachs belong to users and will also eventually be associated with repertoire. The nature of fachs is such that they will not be created dynamically and, in fact, Tessitura does not provide endpoints for creating, editing, or deleting them. Instead, they are entered into the database as seed data.

=== Development Approach

This app is being developed using a rigorous behavior-driven approach, meaning test-first, agile work-flows. I aim for 100% test coverage and Code Climate rating >= 3.8 for classes and modules other than Tessitura itself*. Refactoring both app code and tests is a major part of the workflow on this project. Everything should stay as DRY as possible.

At this point, development is happening on the following git branches. Additional temporary branches may be created and destroyed along the way, particularly if things get messy when adding new features or modifying architecture. ==== not_passing This is the branch where new tests are written. The code stays here until all the tests pass*. Refactoring also happens on this branch ==== staging This is the branch where code gets pushed to verify it is passing before it gets pushed to +master+. ==== master When code passes, it gets merged to +master+. Non-passing code should not be merged.*

There is an additional branch for each versioned release. I do not change things on these branches after the release.

* At this point in development, it should be noted that Cucumber tests marked @integration are permitted and expected to fail due to problems with the test configuration that don't appear to reflect the functionality. These tests should be marked pending so as not to break Travis builds.

=== Contributing While contributions are welcome and appreciated, I ask contributors to keep in mind that this app will most likely be taken closed-source in the future. As the app grows, I will spin off helper modules into gems as I am able, which will then be made open-source and available on https://rubygems.org. Since these will continue to be available to the community, they are where I recommend you focus if you would like to contribute.

* CodeClimate support has informed me that CodeClimate does not recognize DSLs. Consequently, the rating of the Tessitura class may be worse than is deserved. The rating has been improved - quite appropriately - by separating routes into their own modules that are then registered on the +Tessitura+ class.

=== Versioning

Version 0.1.0.alpha1; no stable release available.