Ports - Jillianne & Laneia

[jillirami]

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?	We learned that it is very difficult to produce tests for code that is within a while loop.
Give a short summary of the request/response cycle. Where does your program fit into that scheme?	We have a request from our user through the menu to be able to call a method that accesses the API, and that is responded by the API.
How does your program check for and handle errors when using the Slack API?	The program cycles through the menu for the user depending on user input.
Did you need to make any changes to the design work we did in class? If so, what were they?	We did not utilize a workspace at first and instead included this function in our main file.
Did you use any of the inheritance idioms we've talked about in class? How?	We only used the SlackAPIError inheritance.
How does VCR aid in testing a program that uses an API?	It keeps a record of the results of an API request so that amounts of API calls can be lessened/costs lessened.

[CheezItMan]

slack.rb

What We're Looking For

Feature	Feedback
Core Requirements
Git hygiene (no slack tokens)	Not very many commits and your commit messages focus on waves. Instead write commit messages that describe the functionality you added.
Comprehension questions	Check, Sorry you had a tough time writing tests.
Functionality
List users/channels	Check
Select user/channel	Check
Show details	NOT WORKING for users
Send message	Check
Program runs without crashing	It crashes if I select a user or channel and ask for details.
Implementation
API errors are handled appropriately	You aren't really handling errors from the API
Inheritance model matches in-class activity	NOPE
Inheritance idioms (abstract class, template methods, polymorphism) used appropriately	NOPE
Methods are used to break work down into simpler tasks	A lot of your methods are a bit large and unwieldy.
Class and instance methods are used appropriately	You are greatly overusing class methods and not really creating instances effectively at all.
Overall	Not great, but not terrible either. You got the application to mostly work, but you have minimal testing and a really awkward inflexible design. I'd like you to take a look at the instructor reference design and let me know what questions you have. I realize with Laneia's trip time was an issue here, but I hope you learned some things here about how to structure an application.

[CheezItMan]

Your recipient class doesn't have an instance method called details. You made a class method instead.

[CheezItMan]

Your Channel class here is just a collection of class methods. It would be better if you had a class to represent a channel with instance variables etc. The get_channels method could then return an array of channel instances. That would also allow you to have an instance method to send messages, or get details.

[CheezItMan]

You are also mixing the presentation parts of the program with your business logic. It's advisable to put the parts that deal with data and application logic separate from code that presents an interface to the user.

[CheezItMan]

This method would make more sense as an instance method where you could get the details of that specific instance of Recipient.

[CheezItMan]

You'll notice the code for this class is pretty repetitive. That's a clear sign that you can refactor this method to simplify the logic a bit.

Check out the instructor reference design and ask me questions if you have them.

[CheezItMan]

BTW thank you for letting me select a letter for an option rather than typing out the entire "list users" etc.

[CheezItMan]

This class has a lot of the same issues Channel has.