njha7 / flamingov2 Goto Github PK

Expected Behavior

• there should be code

Current Behavior

• there's no code

Possible Solution

• add code

Steps to Reproduce

1. view repo
2. there's no code

Context (Environment)

• Prod

Detailed Description

• I don't want to write one

Possible Implementation

• javascript or swift idk

A pasta which can take arguments.

Example:

~pasta_template get nice! "Tyler is a Java Chad"
from: [email protected]
subject: Tyler is a Java Chad
body:
nice!

Right now, all the code is housed in the main package. While this is mainly due to Go's shitty workspace limitation, I think we can improve upon this while reducing overall clutter. I suggest that you create contextual subfolders (services, commands, resources, etc.), as independent packages, to promote a better separation of concerns. This repository will not scale to 200+ developers if everything lives in the main package.

Commit messages are not nearly descriptive enough. I want to know EXACTLY what you ate, did, and who you talked to that led to the changes in code

Each instruction in a Dockerfile adds an additional layer to the output image, as referenced in the multi-part build documentation. You should try to combine the two RUN instructions into a single && based line to avoid adding an unnecessary layer to your Docker image.

You're using tabs instead of spaces, so when I open it up in my editor where tabs are 8 spaces wide, it looks awful

Add the functionality to randomize the selection of a pasta and post it on a daily basis.

The bot optionally should allow admins to specify a custom channel for output.

You could utilize multi-stage builds to avoid using the Go Docker image as it's fairly large. You should be able to compile the Go binary on the Golang image and then copy it to an Alpine image for a smaller footprint.

Service clients log errors and return 500s to users on failed commands. Should emit metrics to track frequency and alarm.

i have no idea what your contributions are doing

fix this

1: H-hewwo is anybody thewe

2: cave slowly begins to fill with water

1: H-hewwo pwease somebody hewp me H-ewwo!!

2: you can feel the surface of the water barely lapping at you

1: Nononono hewwo!! Hewwo! Hewp me

2: God wwest youw soul

1: Hewwo! Ma'am why awe you doing this to me Hewwo!! Hewp me pwease

2:

1: M-mr obama is that you Hewwo! Pwease hewp me i seem to be in a wittle bit of twubble mr obama hewwo H-hewwo

2: <picture of Obama; zoomed in slightly>

1: @( ◕ x ◕ )@

1: Pwease Mr Obama Pwease save me i downt wanna die

1: H-hewwo mr obama awe you still thewe

2: <picture of Obama; zoomed in slightly more>

1: M-mr obama pwease im drowning H-hewwo im scawed

1: Ill do anything fow you mr obama pwease hewp

2: Anything?

1: Anything for you mr obama :3

2: Then perish

2:

1: D:

The lines of code in the linked snippet will not scale well if additional commands are added. If another feature were to be added, the linked function would easily span 100+ lines. I would suggest the following design strategy:

Strategy 1

• Have each Command Service (Currently Strike, Pasta Service) inherit from an interface CommandService.
  • CommandService should implement the following methods:
    • canHandleRequest(request []string) - Used to determine if a Command Service can run the command. For example, the pasta service CAN run ["pasta", "get", "top_prestige"] but it cannot run ["strike", "tdorno"].
    • executeRequest(request []string) - Used to execute the request. For example, ["pasta", "list"] will execute the pasta list command on the Pasta Service.

The strategy for running:

1. Keep a list of Command Services that are running in a list []CommandService
2. For every input command, split it into a list of strings by splitting on new line characters and spaces. In this example, let's call the resulting []string requestParameters
3. For each command service in the list described in (1), check commandService.canHandleRequest(requestParameters)
4. If the above check is successful, run commandService.executeRequest(requestParameters)

This methodology allows for multiple services to be able to execute on one command while keeping holding up SOLID design principles. Single Responsibility OP.

Alternative Strategy

• Keep a map from String -> Void Lambda Function in memory
  • This Lambda function should map to the appropriate Command Service function.

Why this isn't the main strategy

Lambda functions would be annoying to deal with in golang if they do not conform to a common interface. For example, some commands might need string parameters, while others might not. However, if you believe the Command Services this system provides in the future will always be of type name(args []string), this strategy is fast in execution due to map get calls being O(1) asymptotically.

I might still suggest putting such behavior in a separate class (CommandHandler?) to uphold SOLID principles.

Keep up the scalable work!

I'd like the peace of mind that the bot has sufficient redundancy to support crashes and outages. A docker swarm or docker compose YAML would be great.

(see issue title)

Please delete stale branches once they are merged to master

https://www.niceme.me