thoughtbot / carnival Goto Github PK

https://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/

In Safari and presumably firefox we're not able to add comments because our server does not support the "Preflight" check.

It looks like Chrome doesn't try this, but Safari does. So it's sending OPTIONS before trying to POST a comment to verify the CORS headers.

It looks like it can't connect to the production database:

2014-06-19T20:43:03Z app[postgres.13616]: [TEAL] connection authorized: user=postgres database=postgres
2014-06-19T20:43:17.701518+00:00 app[web.1]: carnival: SqlError {sqlState = "", sqlExecStatus = FatalError, sqlErrorMsg = "FATAL:  password authentication failed for user \"udbhna2luj09us\"\nFATAL:  password authentication failed for user \"udbhna2luj09us\"\n", sqlErrorDetail = "", sqlErrorHint = ""}

I don't know why that login is not working, it matches what is in the heroku config for production, and I'm able to connect to that database with heroku pg:psql -r production

I was not able to successfully deploy to staging using the instructions in the read me or a variety of other techniques found in the build pack readme.

I tried manually building the build pack with anvil build and it looked like the build succeeded (after about 45 minutes) and then failed when it was trying to Put slug in the cache, with error code 22.

I tried building several times with both heroku build and anvil build but nothing succeeded and each built took 45 minutes.

From Heroku:

However, since it is an issue that has come up for other customers as well, one of my colleagues on the TAM team, Mike, has spent some time working with teams internally to develop a workaround process. It involves using the Heroku Platform API so it's 100% scriptable for you. As such, it is likely a good fit for a CI workflow. I'm including the details below; if it's not clear or you want specific information let me know.

Please note that I'd strongly recommend testing without deploying to your production app before adding that to your workflow. Once you've set up your compilation app, you can send me the app name so I can make sure it has both the 30 min build timeout as well as the PX build dynos.

Also, be aware that I don't know exactly your local setup so I have made some assumptions. I'm not positive this will help in your situation, but wanted to share in case it is. As I mentioned previously, I'm happy to enable extended compile times and PX build dynos for any apps you need it on.

1. You will create a new Heroku app. For now I will name it 'thoughtbot-compilation-app'. The sole purpose of this app is to run your compilations. You won't need to access it via a browser and it need not run any dynos; nor will you ever delete it. You will need to tell me the app's name so I can flag it into both the PX build dynos and extended compilation timeout.
2. You will push a branch to Github, named 'thoughtbot-branch-name'. Your GitHub repo is named 'thoughtbot/thoughtbot-app'.
3. You will use the Heroku Platform API to build the branch on a thoughtbot-compilation-app. The syntax will look like:

$ curl -n -X POST https://api.heroku.com/apps/thoughtbot-compilation-app/builds -d '{"source_blob":{"url":"https://github.com/thoughtbot/thoughtbot-app/archive/thoughtbot-branch-name.tar.gz", "version": "optional-your-version-reference-you-could-use-the-git-commit-hash"}}'

This is documented here
I have used curl -n as I assume your API key will be available in your .netrc file. If it is not then you can append -H "Authorization: your-auth-token" to the request.
For clarity, I have omitted -H 'Accept: application/vnd.heroku+json; version=3' -H "Content-Type: application/json". Their equivalents could be written into your .curlrc file.
For private GitHub repositories, you will include authentication in the URL. See here.

1. Your POST will return a JSON response which will look like the below. You will parse the JSON for the build id.

{
  "created_at": "2014-05-09T19:43:56+00:00",
  "id": "22f637e2-05ab-4e71-bb8a-8ea65c88577b",
  "source_blob": {
    "url": "https://github.com/thoughtbot/thoughtbot-app/archive/thoughtbot-branch-name.tar.gz",
    "version": "optional-your-version-reference-you-could-use-the-git-commit-hash"
  },
  "slug": {
    "id": null
  },
  "status": "pending",
  "updated_at": "2014-05-09T19:43:56+00:00",
  "user": {
    "email": "[email protected]",
    "id": "xxxxxxxxxxxxxxxxxxx"
  }
}

Note you can have multiple builds happening in parallel.

1. You will check the build/compilation status using the build id using the following syntax:

$ curl -n https://api.heroku.com/apps/thoughtbot-compilation-app/builds/22f637e2-05ab-4e71-bb8a-8ea65c88577b

1. You will know when the build has completed, because the JSON response to step 5 will change status from 'pending' to 'succeeded'. You will also have a slug id.

{
  "created_at": "2014-05-09T19:43:57+00:00",
  "id": "22f637e2-05ab-4e71-bb8a-8ea65c88577b",
  "source_blob": {
    "url": "https://github.com/thoughtbot/thoughtbot-app/archive/thoughtbot-branch-name.tar.gz",
    "version": "optional-your-version-reference-you-could-use-the-git-commit-hash"
  },
  "slug": {
    "id": "361d1603-1fb4-4189-a3d7-cbc46967e21f"
  },
  "status": "succeeded",
  "updated_at": "2014-05-09T19:44:04+00:00",
  "user": {
    "email": "[email protected]",
    "id": "xxxxxxxxxxxxxxxxxxx"
  }
}

1. You will copy your successfully compiled slug from 'thoughtbot-compilation-app' to 'thoughtbot-production' using the following syntax:

$ curl -X POST -d '{"slug": "361d1603-1fb4-4189-a3d7-cbc46967e21f"}'https://api.heroku.com/apps/thoughtbot-production/releases

1. The app is now ready for use. It has been built entirely via a scripted API.

Would it be possible to give more space for the comments? Right now there is just a tiny column, so longer comments read weird.

Medium works like this:

I don't think this should block release, but thoughts on making this the default and offering a way for authors to publicize comments?

• Install gravatar
• Update info returned for #18 to include image url

• Install yesod-markdown
• Update commentBody to be Markdown
• Provide appropriate FromJSON/ToJSON instances
  • Note: parseJSON should strip '\r's.
• Included rendered markdown in Comments toJSON function ("body_html"?)

I clicked + Leave a note and the textarea opened. Decided I didn't want to leave a comment and couldn't close the form. Tried to force it to close by opening another comment group and the form was still open. Not a huge deal but I found it annoying.

The text area is resizable which the user can mess with. Not critical but might want to lock that down.

Use this to populate name/email/gravatar/whatever in the front end.

https://github.com/begriffs/heroku-buildpack-ghc

• Add a record to App to hold the key/secret
• Update makeFoundation to set these from env vars or hardcoded development fallback
• Update authPlugins to use the key/secret from the app value (the currently discarded first argument)

Currently, we rely on auto-incrementing IDs to ensure things are ordered correctly when created and requested back. We should at least start storing created_at to give us the flexibility to use it later.

Basically Gemfile.lock

https://github.com/benarmston/cabal-constraints

Right now if someone leaves a comment, we have no way of knowing.

This could be a notification to either the author or the entire team.

It could be a webhook to get piped into Slack, if we wanted.

Not sure what the best way is.

The /comments endpoint should take both thread and article as filtering parameters.

Logging in directly on carnival-staging is working, but when the login happens from robots-staging it just 401s on the follow up /user call (which is not handled gracefully either).

This is becoming commonplace in web applications (GitHub, Gmail, Trello, etc, etc).

Now that we're displaying the comments bodies as Markdown, we don't have that body_html for a newly created comment.

The best way to deal with this is probably to return the json for the newly created comment upon successful creation. This will be nice because we'll be sure to have any other data as well (like username, gravatar, etc)

• Update query to join against user table
• Return array of a new data type (CommentWithUser or something) with a JSON instance that includes username

We use the text of a paragraph to create a unique id that the comments will be saved against.

However, if a paragraph contain only an image there is nothing for us to create this id from and the id ends up being blank.

Hovering over a comment which aligns vertically with a "Add comment" section causes strange flickering.

Carnival causes extra space above images inside the blog post. An example of this can be seen here: http://robots-staging.herokuapp.com/ios-text-kit-basics

Who owns this? Does the API just return flat comments (with "in-reply-to" attributes) and let the js put together a threaded UI, or should the API work out a multi-dimensional list of comments? Seems like a presentation concern, but building threads from a list feels right in Haskell's wheelhouse.

• Update model layer
• Update presentation layer

My thought is that we'll have normal pages visible at /comments?thread=x&section=y which can be pulled onto consumer pages via jQuery.load(). A few things need to happen:

• Update getCommentsR to return either JSON or HTML depending on Accepts (this is built into the framework)
• Make an embeddedLayout (or something) which foregoes the usual html and head tags of defaultLayout.
• Add the required templates etc

Why "Save" for the button?

What are we asking readers to do? How do we want them to interact?

Potentially: https://github.com/ollieh/yesod-session-redis

We'll have to move away from the simple markdownToHtml API and use functions that allow us to pass a WriterOptions. Then we can enable the auto-linking extension.

Just clicking save allows me to save blank comments

embed.coffee currently hardcodes the server url to localhost:3000. This should be an interpolation of the current server's url.

After updating some of our dependencies, it seems that the JSON responses in test have their values html-encoded. This had always been the case in real JSON responses (and works fine in practice), but having that occur in test causes a mismatch in our existing assertions.

Not sure the best way to fix.

Was expecting the normal Mickey Mouse glove cursor that's standard for hyperlinks.

After clicking "Leave a note", a new window popped up asking me sign in or auth through GitHub. After doing so, I was redirected to my Learn timeline (within this same popup), which I find a bit odd.

I expected to be signed in (after I give my permission) and have the popup closed automatically so that I can go back to trying to leave a note.

I do not think the error is our fault:

$ export PATH=/usr/local/ghc/$(ghc_find 7.8.2)/bin/:$PATH
/home/travis/build.sh: line 231: ghc_find: command not found

Not sure if there's anything we can do but wait.

The grid alignment of content and footer is thrown off when comments are visible

This is as easy as adding requireAuthId to the Handler(s). We'll probably also want to add a UserId to Comment (which will require developer-intervention at next load/migration of the app) as part of this, and store who the comment is for.

At the current size, comments wrap after only 2-4 words, which makes them really hard to read. They occupy the same amount of space regardless of the width of my browser.

I think @cpytel has started on this. It can probably be broken down further too.

• Something (script, iframe, etc) that can be loaded on the consumer's page which...
• Brings in jQuery (probably), our own js, our own css, etc
• Finds sections or ps and attached a comment UI to each them
• The comment UI should...
• Be invisible unless activated
• Load in the views from #6
• Handle adding new comments, edits, deletes, etc

None of the comment UI is visible in Firefox.

Similar to #6, add an HTML partial that can be pulled in via jQuery.load().

May be rendered as part of the /comments HTML response, or pulled in separately.

On this post, there are two code "paragraphs" which are being detected as the same paragraph, so the comments are showing up in both places. http://robots.thoughtbot.com/external-posts-in-jekyll

Right now we disable Carnival on anything less than 760px wide.

I would like to eventually enable comment viewing and commenting for mobile devices and skinny browsers.

I'm thinking it should be thoughtbot red.

I think the color should change on hover over the indicator and also when the indicator is selected, exposing the comments.