bumblepie / haikubot Goto Github PK

Add some integration tests for better coverage

Once #57 is complete, add a command to cull haiku which no longer conform to the new syllable counting

A haiku is made up of three messages, each of which has an author. Thus, a haiku should be able to have up to 3 authors rather than just one.

Ensure the use of graphql best practices when handling errors in requests to the api. This is also an opportunity to reflect on other graphql best practices and ensure they are being followed, and proper http responses.

Add a command that will return the number of sylables in a certain line for testing/debugging purposes.

Once an MVP is complete and in a production environment, set up automated testing and CI via Travis CI, Jenkins or similar.

Currently the timestamp in the embed is the current time, not the time that the haiku was created. The data is currently being saved to the database, it's just not part of the graphQL type, so it should be fairly simple to update.

Add a readme file for the overall project.
Should have:

• overall goal of project, what subprojects do
• instructions on what tech is needed (ie node, any dbs etc)
• instructions on how to run whole thing

Allow users to search for haikus based on various criteria

For example:

• Keyword search
• Creation date
• Author

This would be really nice for making the haiku look artistic:

Example:

     breakfast burrito
big ol' breakfast burrito
    in my tummy tum

                - R. Authorson

Use the CMU dictionary before falling back to the syllable library

It's no fun having to guess at IDs hoping they're from your server.

Use a lib like winston to standardise and clean up console output

The discord client should now integrate with the graphql api, saving the haikus and fetching them when appropriate via the api.

Currently, a message such as "Blah blah. Blah blah? Blah." will be considered a single message with 5 syllables. I think it would be better to split up sentences and multi-line messages (ie newline characters acting as fullstops) for better recognition of haikus. Once complete, a single message consisting of three sentences with the right number of syllables would be considered a haiku, and messages consisting of multiple sentences per haiku-line would not be considered haikus.

Add a command to allow haikus to be deleted

Prefixes such as "!" or "?" are kinda messy - there's the potential for overlap with other bots and it's unintuitive when a new user joins a server - use mentions as the prefix for consistency and simplicity.

To allow users to browse haikus at random, a new command which fetches a random haiku from the server they are in would be useful

Mentions currently look like this: <@1243141> to the bot, but like this @username to the users. This creates a disconnect when a haiku containing a mention is made and the mention counts as zero syllables. Additionally, we want to just save the in time display names (within the haiku lines) if we do this, as nicknames change over time, so things might make less sense and the syllable count might be off. It also means people don't get mentioned if they're mentioned in a haiku and it gets looked up.

• Make prefix 'haikubot' by default
• Allow changing of prefix via [oldprefix] changeprefix [newprefix] cmd
• Make commands case insensitive

Add logic for processing sequences of messages (corresponding to a channel in discord) to the discord client project. It should be able to process multiple channels at the same time (ie if messages are sent to different channels, it should be able to track both of them, it doesn't have to be performant yet).

The discord client should be able to respond to a trigger such as !haiku {id} and respond with the correspinding haiku, or an appropriate message if the haiku cannot be found.

Currently the SQL queries for the SQlite and MySQL backed repositories are created via formatting strings, which leads to SQL injection vulnerabilities. As much as I would like to see a DROP TABLES haiku, changing these to prepared statements would make the system safer.

Integrate the discord bot with the api - it should:

• process messages in channels the bot is in
• correctly respond when a haiku is detected

Currently the api "cheats" - it simply stores the haikus in memory. Look at something like Amazon Dynamo DB (with a view to move towards serverless infrastructure) to properly persist data.

You should only be able to reference a haiku from within the same server it was recognised for safety, thus ids should only be unique per server. Each haiku needs the server id as well as its existing fields.

The bot currently recognises its own messages as haikus, causing it to enter an infinite loop where it will keep recognising its own haikus over and over.