Branches - Vi & C. Gutierrez

[CEsGutierrez]

slack.rb

Congratulations! You're submitting your assignment!

You and your partner should collaborate on the answers to these questions.

Comprehension Questions

Question	Answer
How did you go about exploring the Slack API? Did you learn anything that would be useful for your next project involving an API?	Vi: Using postman was really helpful to see what input should look like, and since each API expects something unique, I saw the importance of using it. C. Gutierrez: I used the documentation to see what additional methods there might be, and did some testing using Postman to check the methods we’d actually have to use for the project. I learned that when working with an API, the “url” that one person may be talking about isn’t necessarily the same “url” that another person is talking about so specificity is necessary.
Give a short summary of the request/response cycle. Where does your program fit into that scheme?	The request/response cycle currently has our program, and our project workspace as the Clients, and the Slack API as the Server. Upon initializing, our program makes a GET request of Slack API to get information about all of the users and channels in the project workspace. This request is answered by a response. If the user prefers, the program can also send messages in which case our program is the first Client, the POST request goes to the Server which in turn sends a message to the desired recipient. For that interaction, the Slack API is acting as the client and the recipient is acting as the server. Upon getting confirmation of a received message, that message is passed along back to the original client to acknowledge success.
How does your program check for and handle errors when using the Slack API?	We check to make sure the API request returns a 200 “ok” code. Our program does not address errors when interacting with the Slack API beyond sending a failure message to the user if a sending-message request was not successful.
Did you need to make any changes to the design work we did in class? If so, what were they?	We intended to use inheritance with the Recipient class, however, in practicality, we ended up flushing out the Channel and User classes independently and then adding the inherited methods back after we knew that the redundant versions would work.
Did you use any of the inheritance idioms we've talked about in class? How?	Recipient is an Abstract class. It’s only template method is for “details”. In addition, as part of its initialize, it checks the classes for Slack_ID and Name being passed into a recipient, and these checks are borrowed for practical use in User and Channel
How does VCR aid in testing a program that uses an API?	It makes it possible to make changes to the code and continue testing without making additional API calls, rather storing the information from one call to use as reference for identical subsequent requests.

[CEsGutierrez]

May have accidentally closed the request.

[jmaddox19]

slack.rb

What We're Looking For

Feature	Feedback
Core Requirements
Git hygiene (no slack tokens)	X
Comprehension questions	X
Functionality
List users/channels	Yes! Love the way the messaging walks the user through the flow!
Select user/channel	Yes
Show details	Yes
Send message	Yes
Program runs without crashing	Yup!
Implementation
API errors are handled appropriately	No (See my comment on your api_call_list_users method)
Inheritance model matches in-class activity	Somewhat. "self.get" and "send_message" are absent from Recipient, and "self.list" is absent from Recipient (as an abstract method) and from Channel and User.
Inheritance idioms (abstract class, template methods, polymorphism) used appropriately	The limited extent to which it is used, yes.
Methods are used to break work down into simpler tasks	Yes. :)
Class and instance methods are used appropriately	Yes :)
Tests written for User functionality	Yes!
Tests written for Channel Functionality	Yes!
Tests written for sending a message	Yes!
Overall	Great job overall! The code is generally thorough and testing is as well. I'm concerned about the apparent limited comfort with inheritance and/or instance methods that seems to be indicated by how much functionality is in the Workspace class that is meant to be in the Recipient, User, and Channel classes. Also want to make sure y'all are comfortable handling error codes from apis moving forward since I don't see that in this assignment.

[jmaddox19]

I'm curious to understand why y'all chose to put these methods (api_call_list_channels and api_call_list_users) here rather than as self.list in User and Channel. I assume this was your solution because you had some problem with creating self.list. Glad y'all problem-solved but curious what the problem was.

[jmaddox19]

The return value here isn't being read when it's called so it isn't serving any purpose. Instead of handling this with a boolean return, this is where you raise a SlackApiError like is in the design scaffolding. I'm happy to talk more about that in person, if this feels too vague.

[jmaddox19]

Love the thoroughness of edge-case handling and testing.