The hardware and bandwidth for this mirror is donated by dogado GmbH, the Webhosting and Full Service-Cloud Provider. Check out our Wordpress Tutorial.
If you wish to report a bug, or if you are interested in having us mirror your free-software or open-source project, please feel free to contact us at mirror[@]dogado.de.

Get Started

Dear Developers

{admiraldev} is a set of tools intended for you, the developer, to help make developing within the admiral family easier, consistently robust across all packages and maybe even fun!

Tools are loosely defined as follows:

Why have a separate development package?

As the {admiral} package function base has grown it was decided to create extension packages for use within companies and specific TAs to help with specific problems. We intended these extension packages to follow the same processes as {admiral} core, e.g. Unit Testing, Roxygen Documentation, Function Design. A standalone development package allows us to keep an up to date development process for all developers across the family. We also feel that a lot of the developer functions are not user-specific and gives us more freedom to create and release utility tools specific to our family of packages and reduces non-user facing functions within the admiral family of packages.

How to add new tools to {admiraldev}?

When to add a function to {admiraldev}?

Scenario One: {admiral} core

A developer working on {admiral} core implements a new type of derivation function for a BDS-Findings ADaM dataset. The new derivation function has two new assert custom checking functions for inputs as well as a helper function.

Loose guidelines:

  1. The derivation function should always live in {admiral} core.
  2. The helper function should be looked at to see it should be made available within {admiraldev} for other extension packages needs and so reduce repetitive coding across the family of {admiral}. If it cannot be generalized, then it should remain in {admiral}.
  3. The assert custom checking functions should always live within {admiraldev} to stay with the family of assertion functions.

Scenario Two: {admiral} extension

A developer working on {admiralonco} implements a new type of derivation function for adding certain parameters to an oncology specific ADaM dataset. The new derivation function has one new assert custom checking function.

Loose guidelines:

  1. The derivation function should be closely looked at to see if it can be generalized to other ADaM datasets. If that is the case, then it should be moved to {admiral} core. If the function is very specific to oncology needs, then it should remain in {admiralonco}.
  2. The assert custom checking functions follow a similar principle - if they can be generalized to other therapeutic areas then move to {admiraldev}, whereas if very specific to oncology needs, then they should remain in {admiralonco}.

These binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.
Health stats visible at Monitor.