jollopre / carpanta Goto Github PK

Right now, for simplicity, this rake is only provisioning the following:

• first cluster defined (e.g. https://github.com/jollopre/carpanta/blob/master/infra/deploy/lib/deploy/commands/up.rb#L56)
• first task_definition defined (e.g. https://github.com/jollopre/carpanta/blob/master/infra/deploy/lib/deploy/commands/up.rb#L79) and
• first service defined (e.g. https://github.com/jollopre/carpanta/blob/master/infra/deploy/lib/deploy/commands/up.rb#L102)

We would like to be able to create every resource defined in the JSON file

A new environment for testing is crucial. That involves:

• Set a new target into Makefile
• Create a new docker-compose file
• Run RSpec for test
• Clean up db after every test (e.g. database_cleaner)

have an interface to select Task, date and price for a session

We would like to have some minimal data that is always loaded. These data will consist of:

• Tasks from Carpanta hairdresser services
• A couple of customers to play around

Any time the application is launched for test or development purposes, the seed must happen automatically

We would like to present the content for dates and currency based on the preferred language requested by the browser. For that, we will need to read the header Accept-Language (e.g. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language) and send the content accordingly. There is at least one place to change that behaviour:

• /customers/:id/ (which presents price and created_at for each client session)

We have seen that bundle install runs several times when the image is build for test.

We would like to introduce oauth2 mechanism to protect every incoming request.

We can use bundler-audit (e.g. https://github.com/rubysec/bundler-audit) to delegate those check and mark as failed a CI run.

We need a view to display the details for an appointment.

• The appointment details is navigated through the weekly calendar
• It should display id, customer information, offer and duration

We need to make sure that every view is properly rendered across devices from any form (small, medium, large) and for that we would need to:

• Replace the tables in favour of resizable components
• Review margins are respected when page are shrink or expanded
• etc

A new rake task named generate:migration is needed in order to reduce the burden of copying/pasting a migration skeleton. This task should:

• Create a new file under db/migrate
• Receive an argument 'filename' which will be used to generate a unique file with the format date_filename.rb where date is DateTime.current.strftime('%Y%m%d%H%M%S').

NOTE: The railties gem might help to build this feature (e.g. https://github.com/rails/rails/tree/master/railties)

There are two views that allow users to introduce data through forms, when the request does not produce a successful output, we are returning 422 which is meaningless for the end user.

We would like to render the form again and attach any error as close as possible to its property. If there are errors concerning multiple properties, we should display grouped somewhere in the page. The views to be addressed are those served through the following endpoints:

• post '/customers'
• post '/customers/:customer_id/appointments'

We need to implement a weekly calendar for appointments, starting at 06:00 and finishing 22:00. The calendar should have the following functionalities:

• Cursor to move back and forth between weeks
• The calendar is first rendered with the current week
• Possibility to create a new appointment by tapping/clicking in a 30 min slot within the calendar.
• New appointment overlay should have a typeahead to choose the customer, dropdown to select the offer, dropdown to choose the duration (30/60/90/120 min).
• There cannot exist overlapping appointments for a given date/time

We would like to introduce the practices from DDD (Domain Driven Design) to drive Carpanta application. For that, we need to make sure that all the domain class/modules are isolated from boundaries such as Application (e.g. Sinatra) and Infrastructure.

We need an interface that permits creating customers by introducing:

• name
• surname
• email (required)
• phone

as well as listing every customer in the system

We would like to have an automatic deploy for carpanta. For that will be needed:

• A mechanism to push docker image to docker hub
• Tooling for deploying images from docker hub into amazon ECS (e.g. Fargate)
• Production seeds with strictly necessary entities populated, i.e. just Offers
• Logging to STDOUT instead of file
• Considering volume for persisting database across deployments

The price for a session is stored in cents, however we would like to present the price with the adequate currency format. For that, we would need to:

• Format the price for the list of sessions for a client
• Format the input for price when a new session wants to be created

When a session form is presented, the UI should set the price based on the task selected.

DoD

• on task selection change, the price field must be updated
• the price field is editable
• a price edited is reset to default task price when task selection changes

Update README file to reflect the current status of the project

When we deploy into Aws carpanta. We create the following resources:

• cluster
• task definition
• service

In order to retrieve the public IP behind the task running in the cluster, we have to perform 3 requests (in strict order):

1. Lists the tasks running in the cluster (e.g. aws-cli ecs list-tasks --cluster <cluster_arn>)
2. Describe a task from a cluster (e.g. aws-cli ecs describe-tasks --cluster --cluster <cluster_arn> --tasks <task_arn>). This permits obtaining the ENI (Elastic Network Interface) id.
3. Retrieve details of an ENI (e.g. aws-cli ec2 describe-network-interfaces --network-interface-ids <eni_id>). This contains the public IP behind the Elastic Network interface attached to the running task.

Once we have obtained the Public IP, we should log into the output the IP in order to reduce the necessity of going to the AWS panel.

There are three properties that are hardcoded in infra/production.json which prevents any other usage apart from my AWS user account. The properties are:

• https://github.com/jollopre/carpanta/blob/master/infra/production.json#L13
• https://github.com/jollopre/carpanta/blob/master/infra/production.json#L56
• https://github.com/jollopre/carpanta/blob/master/infra/production.json#L57

We would to replace these hardcoded values with environment variables instead.

More details at: GHSA-vr8q-g5c7-m54m

We would like to be able to create customers. A customer should have the following info:

• First Name
• Surname
• Email
• Phone number

The email is the only required info and it must be unique across all the customers stored.

Deploy gem uses monads as an alternative to control flow of the program. Right now, if an exception occurs while executing methods from Aws::ECS::Client, we don't wrap it up with a result monad. This means, the program execution halts if any exception is raised.

We would like to control any exception raised within the client, an result result monad instead.

We need to offer the functionality of creating an appointment within a weekly calendar.

• Tapping/clicking on a calendar area opens a view where starting_at is already filled and a default of 30 min duration is set.
• New appointment view should have a typeahead to choose the customer, dropdown to select the offer, dropdown to choose the duration (30/60/90/120 min) and a calendar with date/time.
• Request test for new appointment
• Feature or integration test for creating an appointment

We would like to introduce a search mechanism that initially looks for customers given a surname or partial surname passed.

Explore the addition of standard gem for forcing ruby style across the project.

https://github.com/testdouble/standard

There are several files for which there is no need to be copied in the docker image created. Please, refer to https://docs.docker.com/engine/reference/builder/#dockerignore-file to better understand how to tackle this issue.

We would like to have a view that displays the gross income for different time scales:

• weekly revenue (current)
• monthly revenue (current)
• yearly revenue (current)

Note, this story does not include getting summary for a particular date inputted

More details at GHSA-2p68-f74v-9wc6

display all the tasks applied for a customer organised in descending order of session date

The views from Carpanta do not have any CSS styling yet. We would like to:

• use a CSS framework for a quick prototyping
• make it reusable across the different views

A customer attending to a salon wants to receive tasks performed by a hairdresser. We would like to:

• persist Date/Time for which a task gets applied to a customer (session)
• persist the price applied for that session (normally copying from the task price)
• allow repeating a task for a customer on different dates
• have an interface to select Task, date and price for a session
• display all the tasks applied for a customer organised in descending order of session date

We need to apply a set of color to display the different components allocated through the views. There are at least two colors that have to be present:

• Black
• Gold

We would like to charge for an appointment made. The action will create a payment in the system with the following properties:

• price (by default the price set under the appointment's offer)
• payment_method (cash or card)

Right now, when a task_definition is registered (e.g. https://github.com/jollopre/carpanta/blob/master/infra/deploy/lib/deploy/commands/register_task_definition.rb#L18), we don't setup a concrete retention period for its logs.

We would like these logs to have expiration setup in order to prevent unexpected billing costs

We would like to have logs in place for:

• The incoming requests
• The database activity

Each environment running Carpanta should have a different file under log (e.g. test.log, development.log and production.log)

Deploy gem is located under infra/deploy and contains a battery of specs that can be executed through make test.

We would like to integrate this command in the current travis configuration set up for the project