San Juan Island Food Coop – Membership Database
This is the membership database for the San Juan Island Food Coop. Aside from just managing membership records and data, the application is also designed to serve as a volunteer coordinator tool.
The application has the following structure – Everything centers around membership records. These membership records contain basic information about address, primary contact (email, phone) and basic volunteer interests. Membership records are also associated with individual member records and renewal records. Membership records in addition can also be connected to specific volunteer interests and have their own contact info as well.
The application features searching functionality which allows the user to select a field to search by and then enter a query for searching. Eventually, there will also be the ability to search by renewal dates. Searches, even for fields that belong to specific members, return membership object and not member objects. (technical jargon → this makes handling views easier – it may be worth reanalyzing this in the future)
The next phase of the application development is to expand upon the volunteer organization abilities. This ideally will include the organization of volunteer interests, shift organization, hours tracking and so on.
Under the hood
The rest of this document is intended for developers and maintainers.
Under the hood there are some worthwhile things to mention for future developers and maintainers. The app is a rails application running Rails 3. The meta_where plugin is integral to much of the querying and searching. Haml templating is opted for over ERB. Blah blah blah – look at the Gemfile to see what has been used here.
Specs are written using cucumber and rspec. Cucumber for most integration, view and controller stuff, rspec mostly for finer grained testing in models (especially search, at least for the moment). Eventually, as the application grows, it’s possible that more fine grained tests/specs on the controller/side will find there way into existence. The philosophy here is that BDD is great for helping focus the development process, and that specs are great to have around in case things break. However, the finer the grain of testing, more more inflexible the application becomes to desired changes in behavior, as the resulting test/spec code has to be changed alongside the application code. Therefore, to strike a balance (and also since I’m a volunteer), I’ve decided that a med-light testing depth is appropriate, with emphasis (as mentioned) on the cucumber integration specs to make sure that everything is orchestrating well. With all of this having been said, keep in mind that there are some auto-generated specs that are still left over that are running fine. As long as they are running, they are still worth having around, though they may eventually be cleaned up somewhat.
The data that was first loaded into this application to get things rolling with this app (on the membership side of things) was really a mess in a lot of ways, and involved a great deal of parsing and such. It also involved a great deal of analysis to figure out what was what in the way of renewal data, which in some cases had mismatched numbers of renewal dates and renewal amounts. In others there were years without months. In others just question marks (for both date and amount).
My approach in dealing with this data has been to analyze it as thoroughly as possible using some scripting tools I created (also constructed to make loading of the data automated as possible). I decided that I would take any questionable entries relating to renewals and do my best guesses, not including any information on renewal amounts if they were left blank, but making best guesses on dates and marking the entries with flags that had “fuzzy_dates?”. These flags (for now), will in general be hidden from the user, at least on the form side, though the flags will show up on the show views. This will make the interface as friendly as possible while still maintaining the best level of data integrity possible.
A note with all of this in mind is that since there are so many weird cases here from the early days of the coop, it may be well nigh impossible to place much in the way of validations on forms and such, as much as that pains me. Should someone want to do that in the future, be careful, because it could make editing records that have issues very difficult.
- Dependent destroy on member for memberships
- spec out membership deletion
- Fix stupid has_selector? bug
- Deal with blank entries
- Come up with a way to order entries?
- in queries?
- in index?
- Searching by renewal dates
- How to do this
- Clean up and spec search by membership number
- pagination for searches – (tie in with persisting forms)
- Similarly, have sortability of comments that persists between threads?
- current_members scope with a flag for showing current, non_current and all members in interface
- Check boxes on side that show or hide certain parts of the membership views
- session stores for saving what a particular viewer wants to see
- wants to receive newsletter
- Cancel button on form
- scoot radio buttons over a bit – there is overlap that is making clicking a problem
- Should consider cleaning up searching by phone
- Unique membership numbers?
- Separate lines by breaks and/or paragraphs in text field displays (notes)
- put something in for the “click here” to show info about fuzzy dates.
- Similarly, create help content item for sidebar
- Eventually hide fuzzy dates box?
- Cleaner handling in the future for displaying renewals?
- Asc? Desc?
- Have search by field maintain between searches
- Expanded search field when searching by complex?
- Ability to move members between memberships more gracefully
- Better handling for company memberships
- total amount payed in views?