Code

I’m sure there’s already a way to do this, but here goes. OR maybe this is an anti-pattern. Either way, this is me, asking the stupid question. I ran into this a few hours ago: Sys.unsetenv("ENTREZ_KEY") library(brranching) mynames <- c("Poa annua", "Salix goodingii", "Helianthus annuus") phylomatic_names(taxa = mynames, format='rsubmit') No ENTREZ API key provided Get one via taxize::use_entrez() See https://ncbiinsights.ncbi.nlm.nih.gov/2017/11/02/new-api-keys-for-the-e-utilities/ No ENTREZ API key provided Get one via taxize::use_entrez() See https://ncbiinsights.ncbi.nlm.nih.gov/2017/11/02/new-api-keys-for-the-e-utilities/ No ENTREZ API key provided Get one via taxize::use_entrez() See https://ncbiinsights.ncbi.nlm.nih.gov/2017/11/02/new-api-keys-for-the-e-utilities/ [1] "poaceae%2Fpoa%2Fpoa_annua" "salicaceae%2Fsalix%2Fsalix_goodingii" "asteraceae%2Fhelianthus%2Fhelianthus_annuus" The brranching package uses the taxize package internally, calling it’s function taxize::tax_name(). The taxize::tax_name() function throws useful messages to the user if their NCBI Entrez API key is not found, and gives them instructions on how to find it. ...

The longer you do anything, the more preferences you may develop for that thing. One of these things is making R packages. One preference I’ve developed is in limiting package dependencies - or at least limiting to the least painful dependencies - in the packages I maintain. Ideally, if a base R solution can be done then do it that way. Everybody has base R packages if they are using R, so you can’t fail there, at least on package installation. ...

I occasionally think about these various topics and ping back and forth between them, thinking I’ve got to make a package more user friendly, then back to thinking oh, I really should make this package easier to maintain, but what if that makes it less user friendly? I’ve wanted to get these thoughts written down for a while now, so here goes. User friendliness and code fragility It’s an unassailable good to make your code more user friendly. There’s no point of making your package harder to use unless you really don’t want people using it. ...

Measuring use of open source software isn’t always straightforward. The problem is especially acute for software targeted largely at academia, where usage is not measured just by software downloads, but also by citations. Citations are a well-known pain point because the citation graph is privately held by iron doors (e.g., Scopus, Google Scholar). New ventures aim to open up citation data, but of course it’s an immense amount of work, and so does not come quickly. ...

Code in journals, that is, code you would type to do some programmatic operation in say R or Python, is kind of a mess to say the least. Okay, so you can SEE code in papers, but code is not formatted in a way that facilites reuse. If an author in a paper writes out some code for software they create, or an analysis they do in the paper, wouldn’t it be nice for a reader to be able to copy and paste that code directly into whatever environment that code should execute in, and actually work. Of course there is dependencies, etc. for that software to worry about, but here I am just concerned with the code formatting in articles. Code is displayed as an image in some cases (gasp!). Additionally, there’s this thing called the internet, and we can use color, so let’s highlight code already. At least in one of our recent rOpenSci papers in F1000 Research, they do use syntax highlighting - w00t! ...

I recently engaged with a number of tweeps in response to my tweet: Rule number 1 wrt science code: DO NOT post your code on your personal website That tweet wasn’t super clear, and it’s difficult to convey my thoughts in a tweet. What I should have said was do post your code - ideally on Github/Bitbucket/etc. Here goes with a much longer version to explain what I meant. The tweet was just about where to host code, whereas the following is about more than that, but related. ...