booze-hound's People
booze-hound's Issues
Replace FontAwesome link with Booze Hound account version
Background
We're currently using Kenny's FontAwesome profile for Flash Chord as a temporary solution, but we need to setup an account on FontAwesome for Booze Hound, which is free for what we'll need.
Acceptance Criteria
- A FontAwesome account is setup for Booze Hound
- The FontAwesome include references are updated to use the Booze Hound account
- The FontAwesome account is configured to limit use to the Booze Hound domain(s)
Approach
- Wait until we have a domain and email setup, then use an email address to create a free FontAwesome account
- Setup the FontAwesome account and configure it for Booze Hound domains only
- Up date the JS references in the foot include to use the Booze Hound account version of FontAwesome
Notes
This is technically not needed for functionality, but it's likely a terms of use issue that we should resolve.
This is dependent upon #79 as we need the vanity domain to setup email and then we can use that email to register the (free) account with FontAwesome.
Allow for toggling between light- and dark-mode UI
Background
Many modern sites allow users to
Acceptance Criteria
- Users, both account holders and casual, can select from light-mode or dark-mode themes
- The setting is saved across sessions (depending on the answer to the questions below)
Approach
- Use Bootstrap's dark mode color scheme changes and JavaScript to toggle between the two
- (See questions below) ...and store the setting as needed
Notes
Questions:
- For casual users who simply search, do we want to store the setting on the user's compute with a cookie so they don't have to re-set it each time?
- For users with an account, would we store this in the user profile?
Add issue template to .github directory
Background
There is currently no template for GitHub issues (feature request and bug), so we should have templates for easy issue creation. :)
Acceptance Criteria
- A template exists for GitHub issues (feature requests and bugs)
- Charles has approved the templates and the PR is merged into
main
Approach
- Create issue templates for feature requests and bugs in
/.github/ISSUE_TEMPLATE
:feature-request.md
bug_report.md
- Commit/push to the
github-config
branch and issue a PR intomain
Notes
Public release notes and changes page
Background
To keep users informed, we should setup a page (or section of a page) with a list of updates to the site (like a mini blog) with changelog posts.
Acceptance Criteria
- A page (or section of a page) exists with a list of site update posts that can include changelogs in the body, when appropriate
- Each post contains the following fields:
- Title
- Date published
- Published status
- Body
- Author (this may not be necessary as author can just be "admin" or "Booze Hound" or "Tipsy McStagger")
- Images (we may want to attach images to reference changes)
Approach
- Decide where update posts and changelog messages should be posted
- ...probably a subpage of About
- Create a method for publishing posts with the fields mentioned above, but this can be manual via code push rather than a web interface for authoring as we'll be the only ones publishing these and it will (probably) coincide with a production push of code changes anyway
[UI] Create profile page - read only mode
Background
Belongs to #124.
Our users need a profile page for displaying their user information. Edit mode will come later.
Acceptance Criteria
- A user profile page exists that displays
- User name
- First name
- Last name
- Followed bottle categories
- Link to followed bottles
- Link to followed stores
Notes
For later implementation:
- Home zip code
- Search range (distance from zip code in miles)
Update dependencies, including Rails 7.1
Background
Update all the dependencies to the latest versions. Normally, I don't bother with a ticket, but Rails might be a big-ish issue.
Acceptance Criteria
- All dependencies are updated.
Approach
- Dependabot has already opened PRs for most/all of them.
- I don't think Rails 7.1 will be a problem, but we never know. It's been 2 years since 7.0
- Look at the current version of Ruby, while we're there. Version
3.3
will come out at Christmas, but we won't jump on it immediately.
Notes
Prototype new UI
Background
The site has been created without any specialized UI, so we need to develop a full UI/theme. The first step will be to create a static prototype before breaking it up into components and using Ruby's templating framework.
Acceptance Criteria
- A (possibly temporary) logo exists
- A static HTML prototype exists which:
- Themes/styles the overall page wrapper for the site
- Themes/styles the content for the existing pages on the site
- Charles has approved the static UI prototype
- An issue has been filed to implement the new UI as Ruby templates
Approach
- Use the
ui-dev
branch with the/tmp/ui-dev/
directory for development - Use Twitter Bootstrap 5.3 with CDN links (i.e., not built-via-NPM)
- Review with Charles for approval
- File a follow-up ticket for templatizing the new UI with Ruby's templates
Uptime monitoring
Background
We want to know if the application is having issues preventing users from using it. Do we need uptime monitoring for the application or is Google Analytics (#72) sufficient?
Acceptance Criteria
- Uptime monitoring with alerting is configured for the application
Approach
- Determine if we need uptime monitoring in addition to GA4
- If yes, implement uptime monitoring with alerting (email, text, Slack?)
Add the ability to list all bottles in a category
Background
We should be able to list all the bottles in a category (e.g., rum) for browsing. It's an easy query.
Acceptance Criteria
- There's a button (or other control) somewhere to click to get the list of bottles, sorted by name.
Approach
- Add an option to the
index
method of the controller. (That method is getting kinda crowded.)
Notes
The possible rub is that I feel like the bottle listing is getting overloaded. Originally, we just listed the bottles a user followed. Then I added the ability to search by name for bottles and get a list. Then there's list ticket, and #107 will add the ability to add a bottle in a category we're not following. I feel like we're adding lots of bottle functionality in a very haphazard manner - I'm just hacking it in wherever my limited HTML skills will allow.
RSS feeds for bottles, stores, distillers, and user's feeds
Background
Users may wish to subscribe to an RSS feed to get updates for new bottles, new stores, and new distillers so they don't have to actively check the site. Similarly, users may wish to have an RSS feed for the specific things they follow.
Acceptance Criteria
- RSS feeds exist for:
- Bottles
- Stores
- Distillers
- User's favorite bottles
- User's favorite stores
- User's favorite distillers
- Booze Hound updates/changelog (see #74)
- Non-user-specific feeds are published on the site
- User-specific feeds are technically public, but they include a UID in the path and the paths are only published on the user's page when signed in
Approach
- Create RSS feeds for bottles, stores, distillers, Booze Hound updates
- These are published on the site in completely public locations
- Create RSS feeds for user's favorite bottles, stores, and distillers are published only on the user's personal pages with a path such as
booze-hound.com/user/[some user ID]/feeds/bottles
- This may imply the need to create a page under the user's profile section for feeds or maybe we just include the links on some other page
Get Docker running for development environments
The goal is to have a one-step command to build and run the app in a Docker container. @KCarlile created the origin/docker-local
branch with an initial cut from his projects. Get that working for real. Issues include:
- The Dockerfile is hard-coded for the
production
environment (for fly.io). We want to build an image fordevelopment
. - Related: the
bundle install
should include development and test libraries - The Docker compose needs to mount the database file into the running container.
Implement real multiple users and login
Background
The modeling of stores and bottles is all in terms of the User
model, but there isn't any way to support multiple users - i.e., no way to login as a different user. Right now, everything is based on the first user in the DB.
Adding this will make the app more "secure" out on the internet.
Acceptance Criteria
- The system supports multiple users that are selected by logging in, like a real app.
Approach
- Start by looking at the Devise gem.
Notes
[Epic] UI pre-launch improvements
Background
This ticket is effectively an epic for UI changes in the pre-launch phase (for Milestone v1.0).
Tickets in this Epic
Update README.md with technical details
Background
The README.md
file has very little detail and could be updated to include meta data, product data, and technical data.
Acceptance Criteria
- The repository's
README.md
is updated to contain:- Meta data
- Product information
- Technical information
Approach
- Meta data should include:
- Author/owner
- Contributors
Product information should include: - Product description
- Vision/intent
- Scope
Technical information should include: - Dependencies (Ruby, SQLite, Twitter Bootstrap, jQuery, etc.)
- Local development setup
- Hosted setup for dev and production
- Domain/DNS
- Deployments, CI/CD setup
Support paging of recent events
Background
Allow the user to see more than one page (20) of commits.
Acceptance Criteria
- The UI allows the user to page forward and backward through events
- Does this need some sort of request/controller spec?
Approach
- Add an optional parameter to the GET request for the home page that includes the page number. (For the time being, we will just rended the whole home page again, but in some plastic-fantastic world of JavaScript there would be a separate controller for the events, and the home page would hit it to fetch just the events.)
- Add next/previous links to home page to page through the events. Don't bother with a count of the number of pages.
Notes
- Should the number of results per page be configurable by the user?
- Maybe that's a v2.0 feature for which we can file a ticket once this is done.
Design information architecture
Background
We need to understand the structural elements of the site from the user's perspective, so we should design the information architecture with intention.
Acceptance Criteria
- A hierarchical map of the site exists to inform navigation and information architecture
- This design should include all navigable pages for the user and administrators
- In the case of dynamic pages, such as store or bottle listings, a placeholder can represent all of those individual pages
- This design should include all navigable pages for the user and administrators
Approach
- Build a visual representation of the site's information architecture including user pages and admin pages
- Some indicator should specify which pages are placeholder/template pages that represent multiple pages, such as for stores, bottle listings, etc.
- This information architecture design will inform the UI/UX design
Notes
- Use Mermaid Workflow diagrams (see this GitHub page about Creating Diagrams)
- This is not a sitemap (visual) or sitemap.xml (text-based for search engines)
Information Architecture Diagram
Home
graph LR;
Home-->About;
Home-->Login([func:Login]);
Home-->SignUp([func:Sign-up]);
Home-->Find;
Home-->Stores;
Home-->Bottles;
Home-->Brands;
Home-->Admin;
subgraph groupAdmin["Admin Content"]
Admin-->MngSettings[Manage Settings];
Admin-->MngUsers[Manage Users];
Admin-->MngBottles[Manage Bottles];
Admin-->MngStores[Manage Stores];
Admin-->MngBrands[Manage Brands]:::future;
end
Home-->User[User Profile];
subgraph groupUser["User Content"]
Login-->User;
SignUp-->User;
User-->Settings:::maybe;
end
subgraph FindBrowse[Find/Browse]
Find;
Stores;
Bottles;
Brands:::future;
Find-.->Stores;
Find-.->Bottles;
Find-.->Brands;
end
subgraph "Stores"
Stores-->MyStores[My Stores]:::user;
Stores-->AllStores[All Stores];
end
subgraph "Bottles"
Bottles-->MyBottles[My Bottles]:::user;
Bottles-->AllBottles[All Bottles];
end
subgraph "Brands"
MyBrands[My Brands]:::user;
AllBrands[All Brands];
end
subgraph "About Content"
About-->Updates:::maybe;
About-->Help;
end
Stores[Store Listing];
Brands[Brand Listing]:::future;
Bottles[Bottle Listing];
classDef maybe stroke:#ffa500,stroke-width:2px,color:#fff
classDef future color:#fff,font-style:italic;
classDef user stroke:#0000ff,stroke-width:2px,color:#fff
style groupUser fill:#00001a,stroke:#0000ff,stroke-width:2px
style groupAdmin fill:#1a0000,stroke:#ff0000,stroke-width:2px
Legend
- Style
- Italic: some future state
- Colors
- Orange outline: could be done in this phase or in some later phase
- Blue outline: user content
- Shapes
- Rectangle: page
- Round: function
- Rectangle with ends: link
- Groups
- Blue background: user-authenticated content
- Red background: admin-authenticated content
Daily update should update "random" bottles
Background
The daily update process will update all bottles in the categories that were are following. Feature #107 makes it easy to add bottles that aren't in those categories. Such bottles would not be updated daily - e.g., price or description. (Inventory will still be updated.)
Acceptance Criteria
- All bottles, including random ones, will be updated daily.
Approach
- Could create a new method to identify randos (outside the tracked categories) and update them.
- Alternatively, it could be done during inventory if the bottle isn't in a tracked category. But, that blurs the inventory update.
Notes
Repository protection
Background
The Booze Hound repo should be configured properly to protect against mistakes.
Acceptance Criteria
- The Booze Hound repository and its branches are protected against accidental or malicious changes and enforce the correct procedures for development and contributions
Approach
- Ensure that the
main
branch is protected against direct pushes without going through a PR - Ensure that PRs require review prior to merge
- Ensure that any other security/permission issues are properly handled
[UI] Create login and sign up pages
Background
Belongs to #124.
Once we have the user functionality setup correctly, we'll need pages for creating accounts and logging in to the system.
Acceptance Criteria
/user/sign-in
exists for users to login (username and password) to their existing account with links for forgot username and forgot password/user/create
exists for users to create an account with the following fields- First name
- Last name
- Email address
- Username
- Password
Notes
Application logging
Background
We will need the ability to review logs for the application, not just the dependencies (Ruby, Rails, Apache, SQL, etc.) in order to debug issues or audit activities.
Acceptance Criteria
- Application logging is available to admins
- Page-level logging in the UI is available for admins only
Approach
- Application logging should write to log files on the server
- Page-level logging should also be written to a collapsible textarea on the page that is visible only to admins when logged in
Sort user's favorite stores
Background
Sort the list of the users favored stores. It's currently unordered.
Acceptance Criteria
- The list is sorted.
Approach
- Create a service object for the query so that it's easy to mock. See bottles.
Notes
Add any additional notes go here, such as reference links.
[UI] Replace faux-auth/anon functionality with real auth check
Background
Belongs to #124.
The auth/anon content is faked right now, but we need to clean that up.
Acceptance Criteria
- Auth/anon UI guidance is removed, including red and green borders
- Auth/anon split leverages faux-auth-check function to be created
Notes
- Charles to create a function for a faux-auth-check to use in the UI in #128
Bottle detail page should include the category
Background
It's usually obvious what category a bottle is (rum, domestic whiskey, etc.), especially for a booze hound using the app. However, I found an oddball new bottle, that's probably a rum, but I'm not sure. It's easy to add.
Acceptance Criteria
- The category is display in the (currently ugly-ass) bottle detail page. Ideally, it wouldn't be ALL CAPS.
Approach
- Add it to the
show
ERB file.
Notes
Docker dev workflow is broken in DB migrations
Background
Running server-cal.sh loaddb
blows up running migrations.
== 20231004202603 AddFollowersCountToOlccStores: migrating ====================
-- add_column(:olcc_stores, :followers_count, :integer, {:default=>0})
-> 0.0059s
== 20231004202603 AddFollowersCountToOlccStores: migrated (0.0059s) ===========
== 20231005212011 InitializeStoreFollowersCount: migrating ====================
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
undefined method `favorite_store_ids' for nil:NilClass
/rails/db/migrate/20231005212011_initialize_store_followers_count.rb:9:in `up'
/usr/local/bundle/gems/activerecord-7.0.8/lib/active_record/migration.rb:908:in `public_send'
/usr/local/bundle/gems/activerecord-7.0.8/lib/active_record/migration.rb:908:in `exec_migration'
/usr/local/bundle/gems/activerecord-7.0.8/lib/active_record/migration.rb:889:in `block (2 levels) in migrate'
/usr/local/bundle/gems/activerecord-7.0.8/lib/active_record/migration.rb:888:in `block in migrate'
Destroying the DB and rebuilding it from scratch seems excessive. There should be a way to just update the DB. Dogmatically, we should always be able to rebuilt everything from scratch, but it shouldn't be required.
Acceptance Criteria
- The
loaddb
command works correctly. - Look at the developer workflow. Do we need something better?
Approach
- This smells like an issue with ordering migrations. OTOH, it works/worked fine in test. Why is it breaking now?
Notes
Determine business model
Background
What is the business model for this site? F/OSS? Ad-supported? Paid membership for users? Paid membership for stores and distillers? The state-run data aspect of this complicates it somewhat.
Acceptance Criteria
- A business model exists for this endeavor which may or may not include revenue
Approach
- Research and discuss possible business models
- Determine the best approach and assess feasibility (including legality)
- If F/OSS, create a ticket to implement a license in the repo
- If any other models, make the repo private
- Implement the business model
Notes
Possible models:
Model | Pros | Cons |
---|---|---|
Free and Open Source Software | Feels good, no complications | No step 3 (profit) |
Advertisements - Google | Easy to setup, if it passes checks | Probably wouldn't pass checks due to alcohol and state |
Advertisements - Solicited | We decide who advertises | We have to become sales people |
Paid user membership | Volume model | Critical mass required to see profits at volume |
Paid store/distiller membership | Deeper pockets | We have to become sales people and these are harder to sell |
Others ideas...? |
Add a link from an inventory event to the store
Background
We create events for new bottles as well as bottles arriving at stores. When a bottle arrives, the message is arrived at Dallas
. The name of the store (Dallas
) should be a link to the store.
Acceptance Criteria
- The name of the store (
Dallas
) should be a link to the store.
Approach
- Just add the link to the home page's view. One line change.
Notes
Follow up work from adding bottle by ID
Background
While working on #107, I found a couple of things that I wanted to fix, but I wanted to just finish that ticket.
Acceptance Criteria
- Add error message function to
AppService
- Remove the
old_item_code
from the API client andLoadBottle
because it doesn't seem to be needed. - Convert exceptions from
OlccWeb
to use a custom exception class rather than string.
Approach
Notes
My scrawl notes about the error message:
# error_message
# error_message=(msg)
# reset_error_message
# The key is class name + error_message
# Hitting Thread.current[key] - thread-local variable
When looking at a bottle you donβt follow, make an inventory request for it
If you don't follow the bottle, there shouldn't be any inventory records for it (especially while the system is still single user). It's not really helpful to say it isn't in any stores. So instead, make an inline call to OLCC to fetch the inventory using the existing library function. Don't persist the inventory records retrieved.
Note: this will be "slow" to make a synchronous request to OLCC. That's fine for the moment.
Model per-user categories
Background
At the moment, we only track two categories (domestic whiskey and rum) because that's all I care about. Eventually when there are multiple users (e.g., after #122) different users will have different preferences.
Acceptance Criteria
- There needs to be a relationship between
User
and the categories of bottles. It's not a real M:N DB relationship because categories are an enum rather than a table. (There's no need to change that.) - A user only sees new bottle events for categories s/he cares about - that's the primary driver
- The daily job currently hard-codes the two categories we follow. That needs to moved to function that selects all categories followed by all users.
- This ticket does not require a UI to configure the categories for users. Let's handle that later as some sort of user preference.
Approach
- Could remove the hard-coding into a method as a first baby step.
- It's not a real M:N DB relationship because categories are an enum rather than a table. (There's no need to change that.)
- We can test this all in unit tests (different users with different preferences), but we'll need a way to configure the User's categories in the DB somehow.
Notes
Audit and refactor app paths
Background
Paths such as /olcc_bottles/
and /olcc_stores/
are not very user-friendly or SEO-friendly and we probably don't want "OLCC" in the path. These, for example, should just be /bottles/
and /stores/
or something like that.
Acceptance Criteria
- App paths make logical sense for users, SEO, and desired terminology/nomenclature
- Any non-conforming paths are refactored
Approach
- Audit the app's paths and determine which ones need to be modified
- Refactor app paths as necessary
-
/users/profile
-->/user/profile
-
/user/1
-->/user/
-
Notes
...
Fix user data formatting
Background
<%= @user.first_name %>
prints charles
, but this should print Charles
.
Acceptance Criteria
- User fields are formatted properly, including:
- First name
- Last name
- (Any other fields that we have right now that need proper formatting)
Notes
- Kenny has removed the
capitalize()
function from the home page where it used to be<%= @user.first_name.capitalize() %>
, so this is now relying on proper capitalization from the user object. (That will be changed in #125.)
Inventory for Hayman's Old Tom gin is wonky
Background
I follow Hayman's as a one-off (we don't follow the gin category). As of 9/18, the bottle details says it's not at any stores, and the detail for South Salem (olcc_stores/1198
) doesn't list the bottle. However, the OLCC site says there are 4 bottles in South Salem. What gives?
This seems like it's related to #56
Acceptance Criteria
- Bulleted list of what would constitute this bug being resolved
Approach
- Bulleted list of steps to take in order to achieve this feature
Notes
I don't know if it's related, but last nights daily run
https://github.com/cander/booze-hound/actions/runs/6221168450/job/16882616552
Says
There are now 0 new inventory records
Clearly, there are inventory records.
Data error for Eagle Rare and 1792 Small Batch
There is a data error for Eagle Rare and 1792 Small Batch (in production, at least) where the app reports there are no bottles at my store, but there are bottles (or at least there were at the time I saw the issue - Eagle Rare is no longer in Dallas.)
As of 8/25/23, there 1792 isn't in any stores, but it's available in Dallas, Independence, and several Salem stores.
To handle it, probably need to open a console to production (document that in operations.md
if it isn't already) and run queries. Might be able to duplicate it locally. Try to figure if there are other bottles affected.
Check the daily job. Do we have any/enough log output. If not, create another issue for that.
Setup Google Analytics (GA4)
Background
To track site usage, we should setup Google Analytics (GA4) on the site in Production.
Acceptance Criteria
- GA4 has been setup for the production site
- Dev and local environments are excluded from tracking
Approach
- Wait until we have the site on a www.vanity-domain.whatever
- This may also require configuring ownership of the property in Google Search Console
- Setup GA4 for the production site (www only) and that dev and local environments are excluded from tracking
- Ensure that Kenny and Charles both have access
In the detail view of a bottle, the stores should be sorted
Background
Just go into any bottle that's carried in several stored and look at the list of stores.
Acceptance Criteria
- The stores are sorted alphabetically increasing
- No need for any user control of it (yet)
Approach
- Add an
order
clause onto the SQL.
Notes
[UI] Improve mobile experience for My Links submenu
Background
Belongs to #124.
In mobile view, the My Links submenu drops below the main content, which is undesirable.
Acceptance Criteria
- User links (those from My Links) appear in a main nav dropdown β
- User link (just the top-level) also appears in the footer nav β
- "Become a Hound" signup is moved above the main nav for the anonymous page β
Create a way to add a bottle using just the bottle ID from OLCC
Background
To keep the scope, resources, and API calls to a minimum, we currently only follow two categories of booze: rum and domestic whisky. So, those are the only categories that create events about new bottles, and we can only search for bottles in those categories. Sometimes there are bottles that I'm interested in beyond those categories - e.g., a gin or liqueur.
In the very short term, I'd like a hack to just add a bottle. I have a command line tool to do that, but I'd like to do it from the web, in part because getting to the console for the production system is a slight challenge.
See the notes below for a larger discussion of the functionality and options.
Acceptance Criteria
- Just add an input of the favorite bottles page to add a new bottle by ID.
Approach
- The controller can call the same code to call OLCC that the rake task uses - it should be in a service object, move it if not.
Notes
Thinking about this in a larger, non-hacky scope:
- I could just load all the bottles from all of the categories now, but only fetch updates from the same categories I do now. That would allow me to find a gin or tequila I care about today.
- In the end-state, we should be following all categories, but I don't want to be inundated with events about categories I don't care about.
- That implies that a user should have the option to follow/unfollow categories.
- When events are shown, they should be filtered by categories that the user follows. So, the events would need a category on them (which would be denormalized) or the query needs to join events and bottles to filter on the bottles' categories. (I think there's an
include
from event to bottle - should be ajoin
.)
- This (adding bottles from "foreign" categories) could be an admin function now, but in the end-state, we'd be following all the categories, and it would just be automatic. We could make it an admin function for now, but we have nothing in place for admin operations.
I'll think about this a bit more before acting on it.
Setup linting
Background
The Booze Hound repository should perform linting for the languages used to ensure best practices in coding.
Acceptance Criteria
- All files are scanned for linting issues on code push and/or PR
- (Optional) Local linting is also configured for scanning prior to pushing to GitHub
Approach
- Configure GitHub Actions to perform linting for all languages (Ruby, HTML, CSS, JS, etc.)
Notes
- Question: Should linting happen on code push, PR, or...?
- Question: Can we also setup local linting as part of the repo or does that require too much unique local setup?
Design and implement initial logo, tagline, branding, etc.
Background
Branding is important to any project for memorability and conveying the attitude of the product. Booze Hound should have a logo with the name, a possible mascot (separate from the logo), a tagline, and any other branding elements necessary.
Acceptance Criteria
- A location within the repo has been identified for storing branding collateral (files) that will not be deployed with the product
- A logo exists with the stylized product name
- [Optional] A mascot exists that represents the attitude of the product
- A tagline exists that reflects the usage of the product
- Any other identified and necessary branding elements are created, such as:
- Small logo for favicon
Approach
- [] Decide where in the repo to store collateral (source files, not rendered files for including within the application) to be excluded from deployments
- [] Design drafts of the logo, mascot, tagline, and favicon
- [] Review with Charles for approval of designs before final iterations are completed
- [] Finalize designs and collateral (files)
Notes
- Collateral (source files for branding) should be stored in the repository, but not in the deployable code directories at the following location:
/path/to/be/determined/
Add follow/unfollow for stores
Background
Add the ability to follow stores and later unfollow them. For the moment, we will assume that the stores will be manually added by the administrator - i.e., we don't need to query all stores from OLCC (although that sounds like a cool feature for later).
Make it work like the bottles. "Stores you go to" would list the stores the followed stores. There would be a form box where you could enter a city name, and that would list all the stores we know about in that city. Then, you can start following new stores or unfollow from that list.
Acceptance Criteria
- Buttons to follow/unfollow are shown in the store detail page
- Daily update inventory job ignores inventory in stores that aren't followed
- Add some unfollowed stores to the DB to show it's working
- Specs for model/service doing this work, of course
Approach
- It looks like I don't have a cached counter on stores the way I do for bottles - i.e.,
followers_count
. Will need to add that and the functions onUser
to increment/decrement that. - Will want a Service object to orchestrate this change, just like bottles.
- Add
update
to the stores controller - Add follow/unfollow forms to the show view for store
Notes
Once we have stores in the DB that aren't being followed, donβt update inventory for non-followed stores. (Maybe the system already does that.)
Select and configure vanity domain name and email addresses
Background
Once we decide on the official production name (maybe it's Booze Hound), we need to setup that domain and email for contacts, registering services, etc.
Acceptance Criteria
- A vanity domain name is selected, purchased, and configured
- Email addresses are configured as needed (email forwarding is fine)
Approach
- Select a domain name
- Purchase the domain name on Google Domains with free anonymous registration
- Configure www and dev subdomains
- Configure email addresses:
- info@, support@, etc.
- Email forwarding to our personal Gmail accounts is probably fine as we don't need full email accounts
Notes
Domain name ideas:
- Booze Hound
- LiquOregon
- ...others?
Create a helper function for user authentication check
Background
We need a way to check to see if the user is logged in to branch the UI between authenticated and anonymous content.
Acceptance Criteria
- Prior to the real user authentication method being created, a helper function exists to check if the user is logged in and is available in the UI and returns a boolean for the logged-in status.
- The function name and return type are documented here.
Notes
- Enables #127
Enable Booze Hound v1.0 project in booze-hound repository
Background
To track the status of issues in the booze-hound repository, we need to setup a project. Kenny doesn't have access to setup a project in this repo, so Charles needs to do it or grant access to Kenny.
Acceptance Criteria
- Charles has setup a project named Booze Hound v1.0 (or similar) or he has granted access to Kenny to setup the project
- The project is then configured with the following settings:
- Type: board
- Project Name: Booze Hound v1.0
- Description: Project for tracking the initial release of Booze Hound (v1.0)
- Visibility: Private
- Manage Access: add Kenny and Charles as Admins
- States (the following are listed as label text color, description)
- Pending, gray, This item isn't yet ready to be worked
- Ready, pink, This item is ready to be worked
- In Progress, orange, This is actively being worked on
- In Review, green, This item is ready to be reviewed
- Done, blue, This has been completed
- Issues destined for v1.0 are added to the project
Approach
- Determine if Kenny can be promoted to a role that allows for project creation or, if preferred, Charles can just create the project
- Implement the configuration outlined above in the Acceptance Criteria
- Add the issues for v1.0 to the project for tracking
Investigate missing index on olcc_bottles
Background
While working on #58 I discovered an issue with schema.rb
. I'm showing a diff (locally) for the olcc_bottles
table:
@@ -32,7 +32,6 @@ ActiveRecord::Schema[7.0].define(version: 2023_06_15_223946) do
t.decimal "bottle_price"
t.integer "followers_count", default: 0
t.string "description"
- t.index ["name"], name: "index_olcc_bottles_on_name"
(Kenny also saw this when we were setting up the Docker env.)
That line got added to schema.rb
in e6bd4cd. I was doing some performance tweaking with indexes right before I took some time off. That commit adds 3 indexes in schema.rb
but the migration only contains 2 of them. Why?
Acceptance Criteria
- Determine if we need an index of bottle name
- Create a migration to recreate the index, if needed.
Approach
- Is the index in production or only dev? That would inform us about usefulness.
Notes
Price in the store inventory is poorly formatted
Background
Prices on the store inventory (maybe other pages) are not really currency-oriented, meaning they're lame:
![image](https://private-user-images.githubusercontent.com/223165/271684046-3d1befa2-8819-495b-89b2-c57a877071c0.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjMzNTk0MzgsIm5iZiI6MTcyMzM1OTEzOCwicGF0aCI6Ii8yMjMxNjUvMjcxNjg0MDQ2LTNkMWJlZmEyLTg4MTktNDk1Yi04OWIyLWM1N2E4NzcwNzFjMC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwODExJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDgxMVQwNjUyMThaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1lNGU4MzQ5YzJlZGNiMWY3ZWZiYTkyMGZhNjIzZGMyZDVkOTlkYTkxZDQ4N2M5YjcwMzRjOTdmYjRhZDdlYzJhJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.XjIwB6MwH561d09_qvwMWaETkKwYYc3Ofr-edDeh9M8)
It's trivial to add a $
before the number, and .0
isn't how we write amounts.
Acceptance Criteria
- Fix this page.
- Fix any other pages that display the price of a bottle
Approach
- This seems like the sort of thing that Ruby/Rails might/should have a good built-in function for. For for something like that.
Notes
In-app user help documentation (help page)
Background
Users will need help documentation to assist in how to use Booze Hound. This is likely an issue to be resolved much later in the development lifecycle, but it should be considered throughout.
Acceptance Criteria
- In-app help documentation for users exists and covers the necessary instructions for proper use
- This documentation is available to end-users and is easily discovered, such as in a top-level navigation item
Approach
- Write user help documentation (instructions) and include them in the app so users have easily discoverable documentation
Notes
Depending on how extensive the documentation is, we can just write it directly in HTML or we could write it in markdown and transform it into HTML.
Update Ruby version
Background
Update the version of Ruby to the latest 3.2.x version
Acceptance Criteria
- App runs under latest version for both dev and prod
Approach
- Start with the
.ruby_version
file - Update production
Dockerfile
- Update
Dockerfile
for development environment in #89
Notes
Add any additional notes go here, such as reference links.
Setup sitemap.xml and robots.txt
Background
To enable better search engine optimization, we need to have sitemap.xml
and robots.txt
configured.
Acceptance Criteria
sitemap.xml
exists with correct data and is discoverable by search enginesrobots.txt
exists with correct configuration and is discoverable by search engines
Approach
- See if we can automate the generation of
sitemap.xml
or, if it's too much work, just generate the basic static page URLs by hand (we may not need to map out every store, bottle, and distiller) - Determine what needs to go into
robots.txt
for proper scraping
Enable GitHub bot integration with Slack channel
Background
The owner of the repo has to enable toe GitHub Slack bot to allow for integration with a Slack channel.
Acceptance Criteria
- The GitHub bot is enabled in the EchoNW #booze-hound channel for notifications
Approach
- Charles runs
/github subscribe cander/booze-hound
in the #booze-hound Slack channel - The bot is configured for notifications on issues, PRS, deployments, etc.
Look into source data access
Background
Scraping the OLCC data from the website is doable, but risky as any changes would instantly break our app. We should see if it's feasible/possible to get access to the source data itself.
Acceptance Criteria
- The feasibility of accessing the source data from OLCC is determined
- A plan is made based on the results of the investigation of feasibility
Approach
- Determine how we can CAREFULLY inquire about access to the source data from the OLCC
- Figure out next steps based on the results of the inquiry
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.