-
Notifications
You must be signed in to change notification settings - Fork 1
Final Report S2020
Time spent meeting with community partner: 0hrs
Time spent meeting with alumni mentor: 1hr (1 sprint meeting)
Time spent working on deliverables: 7hrs
Time spent developing technical skills: 1-2hrs
The Mayflower Dining group has partnered with Scott Gruhn from the Mayflower Community to design a prototype of a web app to help staff and residents keep track of what food will be served on any given day. The Mayflower Community provides meals for Mayflower Community residents with 3 dining-hall locations.
The long-term goal of the project is to create an online service where residents of the Mayflower Community can view upcoming meals, and where staff can view a list of portion sizes and other data helpful in the preparation of the meals (and potentially recipes and ingredients for each dish). Residents (unlogged in users) should be presented with a menu for the given day as well as a calendar that allows other days' menus to be viewed as well. The menu must be accessible for the residents to easily know what food will be served and when.
The website should also provide tools for staff to help with the planning and preparation of the meals. This includes the ability to change menu items, both temporarily and permanently.
The project is being developed as a prototype to refine the specification and user interactions of the proposed system so that Mayflower can use the prototype to contract professional developers to create the full system.
The Mayflower Community has two permanent 49-day cycle menus, although they do offer some temporary options on special occasions. The project at its current state includes database models and pages to view, edit, or add dishes to the menu (but not from the user UI yet). It also includes a base menu page with a JS calendar for navigating which day’s menu to display, as well as user authentication and management features.
The Sorcery gem is used for user authentication and management. Since this feature is fully implemented, you should hopefully not have to mess around with Sorcery too much. There is a controller which manages sessions (i.e. keeping track of when a user is logged in) and a controller which manages the creation, deletion, and updating of users. There are two types of users, admin and staff. Admin users have the ability to make changes to the dishes, menus, and other users, while staff users just have the ability to see the production sheet.
Minitest (unit tests) and Capybara (integration tests) are used for testing the application. Both have fairly good documentation most of the time, so you should be able to resolve most simple questions via their websites or looking at our existing tests as an example.
Once remote (thanks Corona) we would generally have one stand-up meeting a week (2 per sprint). The first sprint meeting would involve sprint planning and adding things to the Kanban, and the second meeting in the sprint is with our alumni mentor to keep them updated and ask them questions about our current tasks. We worked fairly independently, with each of us gaining a deeper knowledge about one portion of the system. This allowed us to effectively delegate tasks across the system to the person who had the most knowledge in that area. This is not to say that we did not all understand how the app works, just that each of us had a portion of the project that we were an expert on so that problems that arose in that realm had at least one expert. We still haven’t found a perfect way of remote pair programming, so that was certainly missed. If this next semester is remote, teams should put substantial effort into figuring out ways to remotely pair program.
Dont heck it up. ;)
We used Github projects Kanban board setting as our TODO list. You can find it here on github projects You will probably want to start your own new project with tasks and goals that you want to work towards but feel free to either use our existing project page or to model your own after ours (or go completely your own way).
Getting started should hopefully be fairly straightforward with instruction in the README, but if you come across troubles, please update the README to reflect your fixes/changes to the installation procedure.
Obviously, this is not yet a completed project (though it is significantly far along). There are many things that remain as TODOs for this project before it reaches Minimum Viable Product status. Primarily, the production sheet feature needs to be brushed up and completed, and there should be some way to temporarily (as well as permanently) edit a daily menu for special events, like Thanksgiving (perhaps this could be done with a changelog, of sorts). For more detailed information, see the Github wiki page
One remaining “hidden” issue (that is not a future/incomplete feature) is that the UI isn’t super flexible. We currently set a hard-coded width for the app window as a dirty hack, and for some computers, it looks great. Unfortunately, it doesn’t always look great (though it does look passable) so if this issue could be fixed, that would be ideal. This seems like a simple issue to fix (and hopefully for you, it will be) but there is A LOT of junk CSS in the background, and it’s hard to understand how it all fits together because a lot of it was copied from the Mayflower official website CSS.
The project also has a few new and updated gems (that were already mentioned above). We changed the user system from Devise to Sorcery. This adds significantly less bloat to the system since Sorcery has you write the controllers for users and sessions so that you can tailor exactly how they work. Logging in is handled by the Sessions controller, authentication, and password encryption is handled by Sorcery, and all relevant views are in app/views. As for managing privileges, the most common way is to use Rails’ before_action :action at the top of a controller which should only be accessed by logged in users. If you want to restrict an action to staff or admin users, simply put before_action :require_login, which is provided by Sorcery. If you want to restrict to only admin users, we added our own action, :authenticate_admin, to the application controller. For more about the workings of Sorcery, with examples, see https://github.com/Sorcery/sorcery.
Some additional testing gems that were added were Capybara (minitest) and Webdrivers. Capybara is a gem for integration (black-box) testing that allows you to navigate your website in tests just like you (or a user) would. However, Capybara only fetches page HTML by default, so the Webdrivers gem was added to run a browser (currently headless chrome) during select tests to execute (and allow testing of) JavaScript code. Running a browser (even in headless) is much slower than your regular Capybara tests, so only enable it when necessary. An example can be seen in {project_root}/test/integration/calendar_integration_test.rb.
We were happy to complete a refactor of the backend this semester to cut out vestigial data and make data we do care about more easily accessible. We got rid of three models / tables: menu, ingredient and recipe. We removed the menu table because after discussing with customer, we realized all the properties it used to have, such as “dinner or supper” should actually belong to dishes, and thus menus become nothing but an index, and we simply use one integer in the dishes_menus table to indicate which menu the dish belongs to. We removed recipe and ingredients tables because the way they were implemented was not compatible with what the user really wanted. Some properties of ingredients such as mech soft and puree should actually belong to dishes. We removed them for now and will add them back in the future when we start to implement the recipe webpages. Currently, we have a dish table and a dish_menu table, where the dish table contains all the properties that particular dish has, such as portion size and puree. Dishes_menus table contains the properties one particular dish on one particular day has, such as the preparation size and the leftover size of that dish on that day.
Additionally, we switched the user management system from the Devise gem to the Sorcery gem. The effects of this are that we have a more user-friendly User Management page that we designed ourselves, and does not have all other heavy-weight junk that comes with Devise. The management page for users can serve as a template for the management of other resources that an admin might want to have access to (e.g. dishes, menus, recipes, inventory, etc.)
In my personal opinion, W3Schools is invaluable for learning some quick CSS, HTML, and JS knowledge if you don’t have those skills already. The best way to get up to speed with Ruby on Rails is to just use it. It’s confusing and crappy until you have some idea of how it works. Unless you are really good at playing around with code you’ve never seen before, I would recommend working on your individual project to get a grasp of basic RoR topics and features before really diving into the group project. Furthermore, once you have a basic grasp of Rails, the Rails Guides are an invaluable resource for both tutorials and API documentation.
Don’t forget to test the code! Write new tests for your new features, and don’t forget to actually run the existing tests when doing a code review.