At rOpenSci, much of our code, content and infrastructure is hosted on GitHub over several organizations – described on our resources page.This post summarizes some steps we’ve taken to safeguard our GitHub organizations. Paying attention to access rights & individual security setup GitHub defines several possible roles for organizations.The principal ones are: Organization owners who have all rights;

Software unter Tage: Computer-Programme müssen regelmäßig aktualisiert werden, sonst drohen Sicherheitsrisikos und technische Schwierigkeiten. Doch wie archiviert man Software, so dass sie zukünftige Generationen als historische Quellen nutzen können? Welche Rolle spielen Klimawandel und Erderwärmung, wenn Dateien für Jahrhunderte konserviert werden sollen?

We have been working hard behind the scenes on the upcoming release of our new git package named gert, a joint effort from rOpenSci and the Tidyverse team. One of the main features of gert is the out-of-the-box authentication mechanism, which is provided via the new credentials package.

After soliciting, reviewing, and publishing over 100 blog posts and tech notes by rOpenSci community members, we have created the rOpenSci Blog Guide for Authors and Editors to address many frequently asked questions and frequently given suggestions. Technically, we structured the content as a bookdown gitbook.

“Continuous Integration” (CI) has become a standard for proper software development.Checking the integrity of software after changes have been made is essential to ensure its proper functionality.Also, CI helps catch problems introduced by dependencies early when executed on a regular basis (usually done via scheduled CRON runs). Multiple professional providers exist (Travis CI, AppVeyor CI, Circle CI, etc.) which offer CI services to the

I'm doing some work with Nicole Kearney (@nicolekearney) at the Melbourne Museum on the general theme of "linking all the things". It's the end of the first full week we've had, so here's a quick update of what we've been up to. Brainstorming The things we want to do are being captured as a project on GitHub. This is where we come up with ideas, comment on then, then try to figure out which ones can be done.

This post is something of a “how to” guide. The problem is how can you share code with a small team and keep it up-to-date? For ImageJ, the solution is simple. You can make an ImageJ update site and then push any updated code to the user when they startup ImageJ. For IgorPro, there is no equivalent. Typically I send ipf files to someone and they run the code, but I have to resend them whenever there’s an update.

Most of us who work in R just want to Get Stuff Done™. We want a minimum amount of friction between ourselves and the data we need to wrangle, analyze, and visualize. We’re focused on solving a problem or gaining insights into a new area of research. We rely on a rich, community-driven ecosystem of packages to help get our work done and likely make an unconscious assumption that there is a safety net out there, protecting us from harm.

This is a quick post about the punch card feature on GitHub. This is available from Graphs within each repo and is also directly accessible via the API. I was looking at the punch card for two of my projects: one is work related and the other, more of a kind of hobby. The punch cards were different (the work one had way more commits, 99, than the hobby, 22). There was an interesting pattern to them. Here they are overlaid.

A couple of recent projects have meant that I had to get to grips more seriously with R and with MATLAB . Regular readers will know that I am a die-hard IgorPro user. Trying to tackle a new IDE is a frustrating experience, as anyone who has tried to speak a foreign language will know. The speed with which you can do stuff (or get your point across) is very slow.