Skip to content

MichaelPaulukonis/PoeticalBot

Repository files navigation

NaPoGenMo2016

See output @ http://poeticalbot.tumblr.com/

National Poetry Generation Month 2016

my notes

running

LOCAL - node test/manualrunners/writepoem.js REMOTE - heroku run node index.js

TODO: index should take option to NOT publish TODO: some things log, some things don't - it's erratic and the logs can be confusing

testing

npm t

publishing

git push heroku master

TODO: look into automatic github hooks - https://devcenter.heroku.com/articles/github-integration

tumblr connection in .env

These config vars are used for local running. On Heroku itself, they will be config vars.

You can gt them from the heroku applications config, or from Tumblr

consumer_key=<OAuth consumer key>
consumer_secret=<OAuth consumer secret>
token=foo
token_secret=foo

poem generators

  • queaneau-buckets
  • jgnoetry (headless)
  • custom templates
    • TODO: on-the-fly generated templates
    • TODO: templates can have pre-populated text and spacing ?
    • TODO: rewire for multi-pass with saved-text (and post sequences)
  • Harvard Sentences drone
    • TODO: the drone structure seems like it would work for other generators, if they output sentences/lines.

transformers

  • random leading spaces
  • sort (ascending/descending)
  • mispelr
  • phonetic
  • rhyme appender
    • more proof-of-concept than anything.
    • existing implementation is sub-optimal

titles

  • first/last/random line
  • random-selection from most common words in poem
  • summary sentence (summary algorithm picks sentence)
  • fails poorly when there aren't enough sentences

corpus

  • lots of texts
  • sorted into folders
  • select with regex
  • a number of pre-selected combinations, plus random collections
  • randomize percentages for the jGnoetry model

Plans

  • Hybridizer
  • heijinian leading spaces
  • mesostics
  • news-text importer (one of the original ideas)
  • (optionally) replace the syllable-detection algorithm in jgnoetry
  • at a minimum, extract it for unit-testing

Boringly, I continue to work with unit-tests and code-coverage, and other dull things instead of the "cool" poetry generation all the time. So sue me.

It usually pays off in the long run, when I return to a project after a while not remembering how it works -- boom, the tests document usage! Also they run through so many scenarios I know when I do or do not break stuff (depending upon coverage).

some things to look at

Original ideas that did and did not work

So, I've been looking at the Lexeduct code that Chris Pressey started last year. I didn't look into it enough at the time, and my work with it was at cross-currents to its ideology (my work last year was in the gh-pages branch, and "worked", even though it doesn't fit the main model in the master branch).

I think wrangling that understanding and applying it to want I currently want to do will be too time-consuming (although profitable).

So, I'm going to do the Simplest Thing That Could Possibly Work.

  1. static text generator posts to Tumblr
  2. text generator becomes non-static
  3. elaborate and iterate on step 2
  4. end-goal includes ingestion of source material from online news

SO 1-3 HAPPENED THAT'S GOOD And 3 continues to happen....

About

National Poetry Generation Month 2016

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published