strengejacke

// save to windows-user directory

linters: with_defaults(object_name_linter = NULL,
                       object_length_linter(50),
                       commented_code_linter = NULL,
                       object_usage_linter = NULL,
                       line_length_linter(120),
                       cyclocomp_linter = cyclocomp_linter(50))

nischalshrestha

# test file
sample_chunk <- "
```{r hello, testing=as.logical(1), another=1 + 1}
1 + 1
```"
file = "sample.Rmd"
writeLines(sample_chunk, con = file)
foo_hook <- function(before, options, envir) {
  # note: this returns raw knitr chunks in list format
  # has attribute of "chunk_opts"

tatianamac

Speaker Rider

by Tatiana Mac

Last updated 14 April 2021

What is a speaker rider?

As speaking comes with immense privilege, I have crafted a speaker rider to set expectations and boundaries around my engagement. I am grateful to all the conference organisers who have brilliantly hosted me. I would love to continue to exercise this privilege to speak at conferences, and use this privilege to make the landscape more accessible and beneficial to tech's most historically excluded and marginalised communities.

Considerations

😫 I provide a lot of explanations for those of you who never had to consider these things. Most thoughtful conferences I've attended check most of these boxes intrinsically, particularly when conference runners are experienced speakers. They get it.

carceneaux

#!/bin/bash
#
# Written by Chris Arceneaux
# GitHub: https://github.com/carceneaux
# Email: [email protected]
# Website: http://arsano.ninja
#
# Note: This code is a stop-gap to erase Job Artifacts for a project. I HIGHLY recommend you leverage
#       "artifacts:expire_in" in your .gitlab-ci.yml
#

Pakillo

https://github.com/brentthorne/posterdown

https://github.com/rstudio/pagedown

https://github.com/GerkeLab/betterposter

https://github.com/pzhaonet/postr

https://github.com/odeleongt/postr

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

noamross

#' Use the data editor for a CSV file
#' 
#' This function loads a CSV file, lets the user edit it in the native data
#' editor, then re-saves it, prompting the user for a new file name if desired.
#' 
fix.csv <- function(file, new.name=TRUE, sep=",", comment.char="") {
  tmpframe <- read.csv(file, sep=sep,quote="", colClasses="character",
                       stringsAsFactors=FALSE, comment.char="",
                       blank.lines.skip=FALSE, na.strings="")
  tmpframe <- edit(tmpframe)