All posts (Page 106 of 121)
Travis is a continuous integration service which allows for running automated testing code everytime you push to GitHub. Hadley’s book about R packages explains how and why R package authors should take advantage of this in their development process.
🔗
The build matrix
Travis is now providing support for multiple operating systems, including Ubuntu 14.04 (Trusty) and various flavors of Mac OS-X. Jim Hester has done a great job of tweaking the travis R-language build script to automate building and checking of R packages on the various platforms.
...On April 21st and 22nd of 2016, we had 40 members of the R community gather in Brisbane, Australia, with the goal of reproducing the rOpensci Unconference events that have been running with great success in San Francisco since 2014. Like every event organisers ever, we went through the usual crisis: Where will it be? Will anyone actually show up? Is the problem space over venue, date, attendees, catering, sponsors convex? It it even possible to organise an event by only uttering TRUE statements?...
I’m happy to announce that I’ve started a project with rOpenSci under their recent award from the Helmsley Foundation.
My work with rOpenSci will focus on sustainability of the project itself. Sustainability can be defined as having the resources to do the necessary work to continue and grow rOpenSci. This is one of the most difficult challenges for rOpenSci and for many other research software projects.
rOpenSci has a very broad and very ambitious goal, as stated on their web site, “Transforming science through open data.” In practice, the work being done by rOpenSci is “creating packages that allow access to data repositories through the R statistical programming environment” with tools that “not only facilitate drawing data into an environment where it can readily be manipulated, but also one in which those analyses and methods can be easily shared, replicated, and extended by other researchers.” An interesting question is how much rOpenSci will choose to move beyond R to meet its goal, which I would encourage as much as possible. I actually might rephrase the goal as “Transforming science through open data and open software” better matching what is now happening in the project while not calling out R, since I would prefer to try to affect the non-R science community as well.
...Code review, in which peers manually inspect the source code of software written by others, is widely recognized as one of the best tools for finding bugs in software. Code review is relatively uncommon in scientific software development, though. Scientists, despite being familiar with the process of peer review, often have little exposure to code review due to lack of training and historically little incentive to share the source code from their research. So scientific code, from one-off scripts to reusable R packages, is rarely subject to review. Most R packages are subject only to the automated checks required by CRAN, which primarily ensure that packages can be installed on multiple systems. As such, The burden is on software users to discern well-written and efficient packages from poorly written ones....
Geospatial data input/output, manipulation, and vizualization are tasks that are common to many disciplines. Thus, we’re keenly interested in making great tools in this space. We have an increasing set of spatial tools, each of which we’ll cover sparingly. See the cran and github badges for more information.
We are not trying to replace the current R geospatial libraries - rather, we’re trying to fill in gaps and create smaller tools to make it easy to plug in just the tools you need to your workflow.
...
