14 Matching Annotations
  1. Nov 2022
  2. Aug 2022
    1. A review from the Technical Writing team before you merge is recommended. Reviews can happen after you merge.
    2. Each commit should meet the following criteria: Have a well-written commit message. Has all tests passing when used on its own (e.g. when using git checkout SHA). Can be reverted on its own without also requiring the revert of commit that came before it. Is small enough that it can be reviewed in isolation in under 30 minutes or so.
    1. Don’t make claims unless you can cite documentation, formalized guidelines, and coding examples to back those claims up. People need to know why they are being asked to make a change, and another developer’s personal preference isn’t a good enough argument.
  3. Jul 2022
  4. Jul 2021
    1. body script, body style {

      This doesn't work well with scripts (and style elements) injected by the Hypothesis bookmarklet or the Wayback Machine's toolbar. On that note, it's pretty poor hygiene on their part to (a) inject this stuff in the body to begin with, and (b) not include at the very least a class attribute clearly defining the origin/role of the injected content. As I described elsewhere:

      set the class on the injected element to an abbreviated address like <style class="example.org/sidebar/2.4/injected-content/">. And then drop a page there explaining the purpose and requirements (read: assumptions) of your injected element. This is virtually guaranteed not to conflict with any other class use (e.g. CSS rules in applied style sheets), and it makes it easier for other add-ons (or the page author or end user) to avoid conflicts with you.

    2. * Monospace fonts always render at 80% of normal body text for some * reason that I don't understand but is still annoying all the same.

      Dealing with it this way is a mistake. The only reasonable thing to do is to tell the user to adjust their browser's default font settings or deal with it. (This seems to only affect Firefox's default UA stylesheet/preferences, not Chrome.)

      Check out how the most recent iteration of the w2g streamline "client" https://graph.5apps.com/LP/streamline approaches styling.

  5. Apr 2021
  6. Mar 2021
    1. here is my set of best practices.I review libraries before adding them to my project. This involves skimming the code or reading it in its entirety if short, skimming the list of its dependencies, and making some quality judgements on liveliness, reliability, and maintainability in case I need to fix things myself. Note that length isn't a factor on its own, but may figure into some of these other estimates. I have on occasion pasted short modules directly into my code because I didn't think their recursive dependencies were justified.I then pin the library version and all of its dependencies with npm-shrinkwrap.Periodically, or when I need specific changes, I use npm-check to review updates. Here, I actually do look at all the changes since my pinned version, through a combination of change and commit logs. I make the call on whether the fixes and improvements outweigh the risk of updating; usually the changes are trivial and the answer is yes, so I update, shrinkwrap, skim the diff, done.I prefer not to pull in dependencies at deploy time, since I don't need the headache of github or npm being down when I need to deploy, and production machines may not have external internet access, let alone toolchains for compiling binary modules. Npm-pack followed by npm-install of the tarball is your friend here, and gets you pretty close to 100% reproducible deploys and rollbacks.This list intentionally has lots of judgement calls and few absolute rules. I don't follow all of them for all of my projects, but it is what I would consider a reasonable process for things that matter.
  7. Jan 2021
  8. Feb 2016