15 Matching Annotations
  1. Jun 2017
  2. Oct 2015
    1. So rather than waiting further we decided to instrument the existing web interface — not a terribly elegant or reliable solution but it works for now.

      Sigh, it looks like we'll need to do something similar for H in order to automate the Firefox extension build process unless APIs are ready soon.

  3. Sep 2015
    1. The configuration file itself can be treated as an extension if it contains a setup() function.

      This can be used to embed H in readthedocs pages

    1. The project also adheres closely to the Google Python Style Guide.

      The style guides moved to GitHub. Links should be updated

      JavaScript - http://google.github.io/styleguide/javascriptguide.xml Python - http://google.github.io/styleguide/pyguide.html

    2. We use a combination of [JSHint](http://jshint.com) and [JSCS](http://jscs.info) for helping confirm code style conformance.

      Couple of minor links to fix.

    3. Please stick to strict, 80-column line limits except for small exceptions that would still be readable if they were truncated. Eliminate trailing whitespace wherever possible.

      The .editorconfig file doesn't have rules for this at the moment, though they could be added

    1. Copy your extension’s ID from the chrome://extensions page. Chrome generates this ID the first time you install the extension and will reuse it each time your rebuild or reinstall the extension

      Need to check whether this is actually still necessary or not. The extension ID can be fixed in the manifest to avoid the need for this dance.

    1. Add a node symlink. This is needed because the node binary from Ubuntu is called nodejs but many packages will try to run it as node:

      Might be worth recommending installation of Node from nodejs' website instead.

    2. Please consult the administration documentation for more information on accessing the admin dashboard.

      Should be a link to appropriate admin docs

    3. Once installed, running nsqd in its default configuration should suffice for integration with h in a development environment

      Running make dev currently succeeds with no warnings or errors if nsqd is not running.

      How do I verify that H is able to communicate with nsqd?

    4. The h project uses ElasticSearch (v1.0 or later) as its principal data store for annotation data, and requires the ElasticSearch ICU Analysis plugin to be installed

      Sounds obvious, but should have a note here about making sure that ES is actually running.

    5. Using the bookmarklet or otherwise embedding the application may not be possible on sites accessed via HTTPS due to browser policy restricting the inclusion of non-SSL content.

      I think this is out of date?

    6. If you don’t have your h/node_modules/.bin directory on your PATH then you’ll get errors because the Node modules you’ve installed can’t be found (for example: Program file not found: uglifyjs). To add the Node modules to your PATH:

      This isn't something you would normally expect to need to do with a node project. Any gulpfiles, Makefiles or other tools should usually reference the binary in ./node_modules/.bin directly. Any particular reason for this?

    1. If you want to annotate a site that’s served over https then you’ll need to serve h over https as well, otherwise the browser will refuse to launch h and give a mixed-content warning.

      Might be a good idea to make this the default recommendation since so much web content is served via HTTPS nowadays.

  4. Sep 2013
    1. Now, I observe that you, with all your cleverness, do not venture to contradict your favourite in any word or opinion of his; but as he changes you change, backwards and forwards.

      Setting the stage, he claims the high ground, putting Callicles on the defense.