Day 1

2017/12/11

The plan

Created a new Asana board with all the tasks Alan and I have on our plate for the immediate future (Barbara & Alan World Domination):

Asana Board - Day 1

The goal is to get the small things off our plate first (SSOS and SSP release blog posts and SSP support ticket), so we can then invest more focused time into proxyrec, which will be harder. We also tentatively set the goal of working on articles/documentation 1 day per week. Last, but not least, we should always spend the first 10 min of each pairing session, looking at the board and grounding ourselves in where we are and what needs our attention the most.

Some things we did

  • Brainstormed on Alan’s rstudio::conf talk (see Asana task), which also led him to remember this talk on performance by Dan Luu:

  • Wrote SSOS and SSP blog post. (Asana task)

  • We spent some time going over a few Shiny Server issues. Alan also gave me a crash course on what is an application server/container/platform and its requirements, including, for example, identity authentication (often - and historically - provided by LDAP). (Main Asana task)

Lingo

Canary build

We talked about this in the context of pool and its compatability with DBI (whose CRAN version and Github master version can sometimes diverge and create breaking changes in pool). There might be such an issue at the moment (see pool#55).

A gazillion years ago, I did set up a recurring Travis build that fetched DBI devel and ran pool’s R CMD check againt it. I found this approach not to work very well and to be difficult to maintain (it required two separate git branches, one of which would have to be contantly rebased). So, Alan suggested a simpler approach, with two steps:

  1. Check if the current version of DBI devel is different from the last time this test ran. If not, do nothing.
  2. If so, run a canary build. If that fails, manual action is required (to see if it is a false positive or a genuine new bug).

More info

From https://featureflags.io/canary-testing/:

“Canary” was chosen because canaries were once used in coal mines to alert miners when toxic gases reached dangerous levels. In other words, if dangerous gases such as carbon monoxide collected in the mine, the gases would kill the canary before killing the miners, thus providing a warning to exit the tunnels immediately. As long as the bird kept singing, the miners knew their air supply was safe. A dead canary signaled an immediate evacuation.

The word canary was selected to describe the code push because just like canaries that were once used in coal mining to alert miners when toxic gases reached dangerous levels, end users selected for testing are unaware they are being used to provide an early warning. Canary tests, which are often automated, are run after testing in a sandbox environment has been completed. Because the canary is only pushed to a small number of users, its impact is relatively small should the new code prove to be buggy and changes can be reversed quickly.

Maybe Alan and I will set this up for pool once it rises to our top priorities. (Asana task)

Miscellanea

  • Dan Luu’s blog (highly reccomended reading by Alan)

  • Helium: an app to allow you to multitask with ease. Helium is a floating browser window that allows you to watch media while you work. Your content will never fall behind your other windows even as you switch tasks.

  • Vimium: a Chrome extension nicknamed “the hacker’s browser.” Vimium provides keyboard shortcuts for navigation and control in the spirit of Vim.

More info

For more information about rebinding your keys and how to use many of Vimium’s features, see the repo on Github. Modifier keys are specified as <c-x>, <m-x>, <a-x> for ctrl + x, meta + x, and alt + x respectively.

Navigating the current page:

  • ?: show the help dialog for a list of all available keys
  • h: scroll left
  • j: scroll down
  • k: scroll up
  • l: scroll right
  • gg: scroll to top of the page
  • G: scroll to bottom of the page
  • d: scroll down half a page
  • u: scroll up half a page
  • f: open a link in the current tab
  • F: open a link in a new tab
  • r: reload
  • gs: view source
  • i: enter insert mode (all commands will be ignored until you hit esc to exit)
  • yy: copy the current url to the clipboard
  • yf: copy a link url to the clipboard
  • gf: ycle forward to the next frame

Navigating to new pages:

  • o: Open URL, bookmark, or history entry
  • O: Open URL, bookmark, history entry in a new tab
  • b: Open bookmark
  • B: Open bookmark in a new tab

Using find:

  • /: enter find mode (type your search query and hit enter to search or esc to cancel)
  • n: cycle forward to the next find match
  • N: cycle backward to the previous find match

Navigating your history:

  • H: go back in history
  • L: go forward in history

Manipulating tabs:

  • J, gT: go one tab left
  • K, gt: go one tab right
  • g0: go to the first tab
  • g$: go to the last tab
  • t: create tab
  • x: close current tab
  • X: restore closed tab (i.e. unwind the ‘x’ command)
  • T: search through your open tabs

Additional advanced browsing commands:

  • ]]: follow the link labeled ‘next’ or ‘>’. Helpful for browsing paginated sites.
  • [[: follow the link labeled ‘previous’ or ‘<‘. Helpful for browsing paginated sites.
  • <a-f>: open multiple links in a new tab
  • gi: focus the first (or n-th) text input box on the page
  • gu: go up one level in the URL hierarchy

Vimium supports command repetition so, for example, hitting 5t will open 5 tabs in rapid succession. ESC (or <c-[>) will clear any partial commands in the queue and will also exit insert and find modes.