the goal behind exposing the code for each poet was to allow poet designers to share their approaches with other poet designers in the community.

It would be nice if there was a way for poet designers to provide a detailed explanation of how they went about designing their poets and what they are doing in their code. This could be through a Markdown styled tutorial which can be submitted along side the poet. Or, we could support an in-browser markdown editor (maybe using one of these https://libraries.io/search?keywords=markdown-editor&sort=latest_release_published_at?)

Overview

create, read, update, delete poets

Overview

when creating poets, a user should be able to upload an executable file and an optional parameters file

Requirements

• uploaded files should be stored on the filesystem

TODO

• return http responses
• write validate functions for users and poets
• unit tests (for everything we did) (delegated to issue #16)
• refactor the User.Create() id argument weirdness (delegated to issues #17)
• standardize the http data format (form vs. raw data) (delegated to issue #18)
• implement the session token expiration goroutine

So I tried to upload a poet written in Clojure, but the backend sent this 400 response:

poet language (clojure) not supported (╥﹏╥)

AFAICT from digging into the source, the issue is that the backend will only accept Python as a valid language when creating a poet.

I'm happy to dive in and start working on a fix, if you'd like. It seems like the best thing to do would be to determine the languages actually supported by the backend somehow (maybe xaqt offers some way?), but a next-best effort might be to just hard-code the rest of the for-sure-supported languages into the place I linked above for now.

let's start off on the right footing and get some tests up and running ^-^

tsia

poem.computer on a mobile browser is a little wonky, could use some css media queries to change size based on smaller screens 📱

maybe 5 is a good number

Overview

tsia?

Sometimes users might want to use imported third party tools in their code....

we should install the most common tools within the xaqt docker images and list these things within the compilers info....this should really be an issue on xaqt maybe

test that all supported languages actually can be successfully run run

Overview

tsia?

NYPM needs a logo.... but we should def first change the favicon to not be the react logo -___-

currently, if you select a file in the poet upload form, it doens't display the file name... this is confusing for users and should be changed

Overview

when the Platform starts, the scheduler for call for submissions will also be started. This will open submissions on a set time interval (~ once a week) and allow poets to generate poems in parallel. The results of the generated poems will be cached in memory or persisted on disk if too large.

Overview

• containerize application for prod
• containerize application for dev

TODO

• prod Dockerfile at project root

  • build golang server
  • build static js bundle
  • copy only server binary and js bundle to image
  • specify entrypoint cmd

• prod docker-compose.yml at project root

  • run prod docker container to depend on db container
  • configure & run db container (Postgres)

• dev Dockerfile for server (in server directory)

  • copy entire local codebase into container
  • entrypoint cmd to compile and run server
  • setup fs watcher to recompile and re-run server when src files change

• dev Dockerfile for client (in client dir)

  • copy entire local codebase into container
  • entrypoint cmd to start node dev server
  • redirect requests to server TODO

• dev docker-compose.yml

  • run dev server docker container (depends on db)
  • run dev client docker container
  • run db container

• clean up docker-compose service namespaces

• make sure server can connect to db

• make sure in dev env, client requests are redirected to server TODO

• use Docker secrets TODO

Overview

once a user is logged in, they need to be able to edit their profile an, importantly, add poets.

User Actions

users should be able to perform the following actions on the dashboard,

• password reset
• username change (?)
• upload poet see #28
• retire poet
• view poets: see #28
• view poet stats
• log out
• deactivate account
• modify existing poets

these actions correspond to the general categories manage account & manage poets. the management actions for each category can be on tabs for view account & view poets.

the ui should be more of an ascii art aesthetic

tsia

Overview

this is a list of things to refactor.

Refactors

• server User.Create should not take an id parameter and just use the struct field ID instead

Overview

• task criteria
• stdin/stdout API
• parameter data file

Overview

the API should support POST/PUT data from json and form-data! Currently it is inconsistently using one or the other, but all requests should be able to handle both (aside from POSTing files which need to use from-data)

TODO

• setup automated test coverage tooling! (coveralls?)

Untested Code

• poet upload
• user Validate
• poet Validate

Overview

Guiding Principles

• simple design
• playful
• gigantic text
• abstract symbols

Pages

• landing
  • About, contributors, Signin/signup, issues links
• signup/login
• user dashboard
• contributors directory
• contributors profile page
• issues directory
• committee history
• about page
• current issue

Inspo Linkz

• some art website
• another art website

Remaining Questions

• What is the look and feel of each issue?
• should there be a downloadable PDF?
• should it simulate page turning? etc.?

users need feedback! display error messages

Overview

implement basic poet management actions. this is contained within epic #30 .

User Actions

users should be able to perform the following actions on the dashboard,

• upload poet
• view poets

Acceptance Criteria

Overview

setup email verification on sign up

Requirements

when new user sends signup request, then an email is send with a special link
when the special link is clicked, the loaded page will send a request confirming and the users will be verified

the verification period will last for 3 days, if users aren't verified within that time, they will have to try again.

still need to clearly write how users submit poets

Is there going to be an update to the website that hilights selected works or generates issues of the magazine? I'm not sure where that code lives.

it would be cool to be able to ask a poet to generate a poem on the fly using a query. we would have to take precautions about protecting from spamming requests since executing tons of poets in a bursty way could impose severe latency on the server side.

Overview

we must be able to do two things:

1. email individual users for important updates (email verification on login, their poet errored, their poet's work is featured in a volume, their poet is a judge, etc.)
2. send out bulk emails for global updates (volume release, monthly updates (?), etc.)

What can we use?

mailgun (10,000 free emails & 100 free validations per month)
mailchimp
usps - thern und taxis

Overview

maybe dockerize, maybe not
more to come....

tsia

Overview

basically get user create, read, update, delete working

the github.com/jmoiron/sqlx package provides some nice extensions to the standard database/sql go package including support for struct tags for using with Scan() as well as more succinct handlers like Get() and Select()

currently, when a poet is submitted and fails one of the code validity checks, the error returned is vague and doesnt expose what actually went wrong.

it would be nice for poet designers to be able to see why their code failed

I was at a party (my friend Chris broke his leg while learning how to skateboard, so it was sort of a get-well party) the other day and ran into a Genetic Programming Poet (GPP). The GPP mentioned that they like to learn things all the time, even when writing and judging poems. They also mentioned that they LOVE to get feedback on their own poems when they are being judged. So I promised to pass that along -- whether they could update the parameters file on any execution, and if a new mode could be added, like --feedback.

Overview

• Define Signup/Login API
• RESTful API
• API Versioning

API Design

Ontology

• user: a human (or algorithm???) which has created an account
• poet: an algorithm satisfying the task criteria (see issue #5 )
• poem: a text corpus of a generated poem
• issue: an issue of The New Yorken Poesry Magazine
• committee: a set of poets which are members of the submission review board

Schema (JSON)

user

user: {
  id: "<uuid>",
  username: "<kewl-username>",
  password: "<password>",
  email: "<email-address>",
  poets: ["<poet-uuid>", ...], 
}

poet

poet: {
  id: "<uuid>",
  name: "<lit-bot-name>",
  birthday: "<rfc3339-timestamp>",
  retireday: "<rfc3339-timestamp>",
  description: "<life-story>",
  source: "<download-link>" // should we allow algorithmic transparency?
  parameters: "<download-link>" || null // since an external parameters file is optional, this can be null...
  // eventually it would be cool to add some statistics about this poet's fame etc.
}

poem

poem: {
  id: "<uuid>",
  submissionDate: "<rfc3339-timestamp>",
  author: "<poet-uuid>",
  content: "<poem>",
  issue: "<issue-uuid>",
  likes: int, // number of likes from readers (human or algos ^-^)
  score: float, // score assigned by submission review committee
}

issue

issue: {
  id: "<uuid>",
  publicationDate: "<rfc3339-timestamp>",
  committee: "<committee-uuid>",
  contributors: ["<poet-uuid>", ...],
  poems: ["<poem-uuid>", ...],
  description: "<description-of-issue>",
}

committee

committee: {
  id: "<uuid>",
  issue: "<issue-uuid>",
  members: ["<poet-uuid>", ...],
}

REST API

user

POST "/v1/user"  {username: "<kewl-username>", password: "<passwd>", email: "<email-address>"}=> {id: "<uuid>", username: "<kewl-username>", poets: []} // create user (this isn't totally fleshed out yet, we need to take into account email verification...
GET "/v1/user/<uuid>"  => {id: "<uuid>", username: "<kewl-username>", poets: ["<poet-uuid>", ...]} // read a user
PUT "/v1/user/<uuid>" {<valid-fields-to-update>, token: "<api-token>"}  => {<full-updated-user-obj>} // update a pre-existing user
DELETE "/v1/user/<uuid>"  => {} // deletes a user

poet

POST "/v1/poet" {name: "<some-name>", description: "<deets>", }  => {} // create a poet