This section contains small updates to how i view my learning plan entering into bootcamp
While I have no specific destination or job I hope to land post dev academy, one of the most important things for my future pathway is ensuring personal development. A part of myself holds a lack of confidence in being able to dive headfirst into a coding heavy role which I believe is based on fear originating from my failure to learn coding in the past and my self conscious comparisons with other peers within the course regarding the quality of their outputs. My studies at university had geared me up towards a more strategic and design approach to the tech sector rather than a hands-on coder. Based on this, part of me wants to use these dev academy skills to help facilitate that approach, however, with past failure to find a job in this realm for someone with no experience, I feel I must reevaluate my approach and perhaps face my fears of getting my foot in the door through the more hands on coding approach. Ultimately I do hope that my time on campus with course staff and peers will help me discover the avenues i have open to me.
Quite similarly to my learning plan at the start of foundations (found below), I still believe my strongest set of skills throughout Bootcamp will be my ability to work with others and collaborate, its a skill that has been recognised in the past and one I hope to utilise and build on throughout bootcamp. With my struggle to learn coding at university in the past (all be it, in a vastly different learning environment), I fear that a limitation of mine will be keeping up with others technical ability. While reflecting on this fear I can rationalise that that is not likely to be the case, my previous experiences do hold a somewhat firm grasp on the preconception i have of myself. This idea of "keeping up with others" is not regarding getting behind on course work, more so in environments such as peer coding where my approach to a section of code may be unorthodox or more complicated than it needs to be, or perhaps I may get simple syntax wrong which slows down the coding process.
I think one of the more likely challenges I will face is aligning my style of collaboration and group work with others, as it is something that has tripped me up in the past at university. However, considering my peers (as far as I can tell from foundations) are far more engaged than some of my peers were at university, I believe that this, on top of ensuring we kick group work off all on the same page, won't be a significant issue.
As stated in my initial learning plan, I would still like to develop my public speaking skills as I feel they have become a tad rusty in the last year or two. Besides this, I would also like to further develop my articulation skills when conveying ideas to others, stripping the filler to create clear, concise conversation. Self-awareness would be another skill I hope to hone as I feel confident when self-awareness is focussed solely on myself but less so when practising self-awareness in contexts of interacting with others.
I think patience is something I would expect and value from the Bootcamp team along with an understanding of students different capabilities. I also think this goes hand in hand with the ability to listen (like in our listening and looping exercises) to our queries or concerns and assist in whatever way feasible to overcome our challenges.
I would expect timeliness and punctuality from myself, being on time and ready to learn when the time comes. Furthermore, starting and completing work as soon as possible in order to allow a buffer period for work taking longer than expected. I would also expect myself to have my full attention towards my learnings, meaning that I am well-rested, nourished, and am on top of my well being to the best of my ability.
My long-term goal in a nutshell would be working in a personally enriching role with a company that cared about my personal development. By personally enriching I mean a job/role that worked towards delivering multiple types of projects, with a decent amount of variation, variation that would allow me to apply and learn skills in different contexts. The best example I could think of to help me explain my thinking would be along the lines of a consulting job, or working on projects alongside a project manager, one where I would have different challenges placed in front me, and more importantly one that didn’t have me heading into the office to compete the same work from 9-5 for 5 years. Personal development is another important factor for a career path, I want to know that through my time with a company I will be able to grow as a person for the better
Discussed more in depth in my values, strengths, and limitations blog post, my strengths around learning would be my commitment to excel when I’m interested and engaged in what I’m doing. For example, I really enjoy creating my website and happily spend hours on end trying to get it closer to what I envision for it. On the other hand, tasks like “spend 10 hours learning HTML and CSS” present them selves as a massive daunting hill to climb and after several hours started to become tedious and less engaging. these scenarios are definitely less likely to produce work that I would consider I exceled at, yet I also have a strong commitment towards completing the work in the given time frame regardless (really driven by a deadline), just perhaps not to a standard as high as if I were engaged.
Another skill I would say I have is knowing when to reach out for help. I am comfortable to research and perceiver for a while in an attempt to overcome what I’m stuck on but equally I have no trouble reaching out when that doesn’t produce any results, the way I see it is why would I spend two hours trying to overcome a problem if I can reach out to my peers/teaching staff and discuss the problem with them. In the worst-case scenario, I would do both, and conduct my research while I wait for a reply.
One of my main limitations relates quite closely to the first strength I talked about. That being procrastination when I am not engaged and have deadline further away than the time it will take to complete the task. There is actually a term for this known as Parkinson’s law which states that the time to complete work expands to fill the time allotted. In my case however, when not engaged in the task, this rarely means it will be completed to a higher standard and instead incorporates more procrastination
Without patting myself on the back too much I would actually say that I am quite strong in the human skills front. I have always excelled in work when that includes working with others (evident through my feedback and grades from school and university), which was ultimately built off of my relatively extensive involvement in the performing arts through my later high school years. My family’s journey with mindfulness had also incorporated a decent amount of focus on emotional quotient (intelligence) which I think has been a great asset in this field. That being said these skills are ones of continual improvement with no limit so naturally I believe this will develop for the better throughout my time at EDA. If I was to give a specific skill however I would probably like to build on my presentation/public speaking abilities as I feel these have become a bit rusty recently.
The main focus for myself at EDA is definitely the technical skills as from my experience my lack of experience within the tech sector (at the lower entry level end rather than my skills based on strategic and design studies) have been a limiting factor in my ability to find work, which is at the most basic level, is the reason I signed up to EDA.
I think firstly it’s important to understand the weeks workload and plan my Monday to Friday in accordance with that, this naturally allows a buffer of the weekend if anything is taking longer than expected or I’m struggling with work. having a broken-down plan like this helps enforce a routine to ensure that I’m eating well, getting enough sleep, and ultimately have the best chance physically to work productively and safely. I also imagine, based on experience, that when bootcamp starts and we are on campus surrounded by like-minded individuals and ‘more direct’ or easily accessed support avenues that my main limitation of lack of engagement will diminish.
At the point that I deem my workload to be building to more than I can handle then I will reach out within 24 hours of making that decision. If I decided the workload was building too much and I didn’t have access to speak in person (for example it was the weekend) then I would reach out via email. Preferably if circumstances allowed then I would meet in person either on the same day or next day so that a more thorough discussion of my work and workload can be discussed.
At the point of reaching out I would expect compassion and understanding from the facilitation team if my work has been building up (assuming the explanation is reasonable), and more importantly would expect the focus of any discussion around the topic to steer towards how we move on from here, and how I can be supported. I would also expect follow ups over the weeks towards how a decided plan of action is working out and whether any further methods or plans to overcome the obstacle need to be put in place.
I have no planned commitments that may clash with scheduling, however any unplanned activities that must be undertaken (such as bereavement or medical appointments) will be communicated on my part at the earliest I can. I would also expect support regarding catching up or structuring work around these commitments.


Everyone can help.
io.js
adheres to a Code of Conduct, and contributions, releases, and contributorship are under an open governance model.
To get started, there are open discussions on github, and we'd love to hear your feedback.
Becoming invloved in discussions is a good way to get a feel of where you can help out further. If there is
something there you feel you can tackle, please make a pull request.
In addition, using Nodebug.me is a good way to help Triage the issues in the backlog.
There is an #io.js channel on Freenode IRC. We keep logs of the channel here.
Open source governance advocates the application of the philosophies of the open source and open content movements in order to enable any interested party to add to the creation of the end product, as with a wiki document. Legislation is democratically opened to the general citizenry, employing their collective wisdom to benefit the decision-making process and improve democracy. [source]


gbm: Generalized Boosted Regression Models
An implementation of extensions to Freund and Schapire's AdaBoost
algorithm and Friedman's gradient boosting machine. Includes regression
methods for least squares, absolute loss, t-distribution loss, quantile
regression, logistic, multinomial logistic, Poisson, Cox proportional hazards
partial likelihood, AdaBoost exponential loss, Huberized hinge loss, and
Learning to Rank measures (LambdaMart). Originally developed by Greg Ridgeway.
| Version: |
2.1.4 |
| Depends: |
R (≥ 2.9.0) |
| Imports: |
gridExtra, lattice, parallel, survival |
| Suggests: |
knitr, pdp, RUnit, splines, viridis |
| Published: |
2018-09-16 |
| Author: |
Brandon Greenwell [aut, cre],
Bradley Boehmke [aut],
Jay Cunningham [aut],
GBM Developers [aut] (https://github.com/gbm-developers) |
| Maintainer: |
Brandon Greenwell <greenwell.brandon at gmail.com> |
| BugReports: |
https://github.com/gbm-developers/gbm/issues |
| License: |
GPL-2 | GPL-3 | file LICENSE [expanded from: GPL (≥ 2) | file LICENSE] |
| URL: |
https://github.com/gbm-developers/gbm |
| NeedsCompilation: |
yes |
| Materials: |
README NEWS |
| In views: |
MachineLearning, Survival |
| CRAN checks: |
gbm results |
Downloads:
Reverse dependencies:
| Reverse depends: |
BigTSP, bst, ecospat, gbm2sas, mma, personalized, twang |
| Reverse imports: |
aurelius, biomod2, bujar, EnsembleBase, EZtune, gbts, horserule, inTrees, IPMRF, lilikoi, mvtboost, Plasmode, scorecardModelUtils, SDMPlay, spm, SSDM, tsensembler |
| Reverse suggests: |
AzureML, BiodiversityR, caretEnsemble, crimelinkage, DALEX, dismo, featurefinder, fscaret, imputeR, MachineShop, mboost, mlr, opera, pdp, plotmo, pmml, preprosim, subsemble, SuperLearner, vip, WeightIt |
Linking:
Please use the canonical form
https://CRAN.R-project.org/package=gbm
to link to this page.


class DataBuilder
This builds the variables that are found in view-vars.php config for a devise page.
It uses a ViewComposer (found in this directory) to inject in the data that is built using this class.
Methods
|
__construct(DataCrawler $DataCrawler)
Construct a new data builder |
||
| array |
compile($queue)
Injects data from config into the current view |
|
| array |
setData(array $data)
Set the data that will be used by a view composer |
|
| array |
getData()
Get the data for the view composer |
|
| array |
getValue($options $options)
Gets the value of the view variable from options by parsing the options string and also any parameters for this specific variable. |
Details
at line 40
public
__construct(DataCrawler $DataCrawler)
Construct a new data builder
at line 50
public array
compile($queue)
Injects data from config into the current view
at line 63
public array
setData(array $data)
Set the data that will be used by a view composer
at line 73
public array
getData()
Get the data for the view composer
at line 87
public array
getValue($options $options)
Gets the value of the view variable from options by parsing the options string and also any parameters for this specific variable.


Implements the Bayesian paradigm for fractional polynomials in generalized linear models, described by Held, Gravestock, Sabanes Bove (2015) <doi:10.1214/14-STS510>. See package 'bfp' for the treatment of normal models.
| Version: | 0.0-51 |
| Depends: | R (≥ 2.12.0) |
| Imports: | survival, rms, statmod, methods, coda, Runuran (≥ 0.12), Rcpp (≥ 0.11.6) |
| LinkingTo: | Rcpp, RcppArmadillo |
| Suggests: | MASS |
| Published: | 2017-08-03 |
| Author: | Isaac Gravestock [aut, cre], Daniel Sabanes Bove [aut], David Maisonave [ctb], Terry Therneau [ctb], R Core Team [ctb] |
| Maintainer: | Isaac Gravestock <isaac.gravestock at uzh.ch> |
| License: | GPL-2 | GPL-3 [expanded from: GPL (≥ 2)] |
| NeedsCompilation: | yes |
| Citation: | glmBfp citation info |
| Materials: | ChangeLog |
| CRAN checks: | glmBfp results |
| Reference manual: | glmBfp.pdf |
| Vignettes: |
glmBfp: Bayesian fractional polynomials for GLMs |
| Package source: | glmBfp_0.0-51.tar.gz |
| Windows binaries: | r-devel: glmBfp_0.0-51.zip, r-release: glmBfp_0.0-51.zip, r-oldrel: glmBfp_0.0-51.zip |
| OS X binaries: | r-release: glmBfp_0.0-51.tgz, r-oldrel: glmBfp_0.0-51.tgz |
| Old sources: | glmBfp archive |
Please use the canonical form https://CRAN.R-project.org/package=glmBfp to link to this page.


How To - Edit a Datapoint
This article describes the steps to edit a datapoint in the What-If Tool.
- Select a data point of interest in the custom Datapoints visualization by clicking on it. A list of all features and values associated with that datapoint will appear in the Edit module.
-
To change a feature value, click on it. This should highlight the value with a yellow stroke around it.
-
To delete a feature value, click on it to highlight. Then click on the delete icon to delete the feature value.
Deleting a feature value
Deleting a feature value can be tricky business. Missing feature values can cause some models to behave erroneously, unless they are set up to handle missing feature values.
- To get model predictions, click on the Predict button in the Infer module. This is known as a Run. Additionally, clicking the predict button will return predictions for multiple edited data points in a batch run. Until a prediction is available, any prediction-related features utilized in the Datapoint visualization are removed from the datapoint.
-
To restore an edited datapoint to its original values, click on the revert icon in the toolbar in the Edit module, and then click on the predict button in the Infer module to return model predictions.
-
To duplicate a selected datapoint, click on the duplicate icon in the toolbar. A new instance of the datapoint should be added to the Datapoints visualization. Click on the predict button in the Infer module to return model predictions.
Tracking edited data points
The unique datapoint identity in the heading of the Edit module is handy when tracking an edited datapoint when working with a large dataset. The Infer module displays prediction results for all runs associated with a datapoint, highlighting the difference between two consecutive runs. However, it isn’t possible to save this information outside of the What-If Tool.


You can use TrackingObserver to run an automated measurement of tracking on the Web.
Designate a file containing a list of URLs to visit (one on each line), and TrackingObserver will open a new tab and automatically visit each URL in turn.
You can specify how long you'd like each page to stay open, giving sufficient time for trackers to load on the page.
If you'd like to stop mid-measurement, simply close the tab in which TrackingObserver is automatically loading pages. Unfortunately, the parallelism changes seem to break this working cleanly. In principle, it should still work. If it's a problem, let Adam know.
Please note that starting a measurement will clear all stored tracking data.


--- layout: page title: Oops! ---
Our sophisticated engineers are already looking into the problem, as seen above. Meanwhile, why don't you visit home or use the search feature.


| Created: | 5/2/2012 11:43:49 AM |
| Modified: | 5/5/2019 1:38:34 AM |
| Project: | |
| Advanced: |
| Attribute | ||
|
Public TM_Instant issueTime |
||
Details:
|
||
|
Public AirportHeliport aerodrome |
||
Details:
|
||
|
Public TM_Instant observationTime |
||
Details:
|
||
|
Public MeteorologicalAerodromeObservation observation |
||
|
Details:
sequenceNumber=4
|
||
|
Public MeteorologicalAerodromeTrendForecast trendForecast |
||
|
Details:
sequenceNumber=5
|
||
|
Public Boolean automatedStation |
||
Details:
|
| Tag | Value |
| byValuePropertyType | false |
|
Details:
Values: true | false
Default: false Description: Create a property type that requires that the instance is encoded inline (applies to ISO 19136:2007 encoding rule). |
|
| isCollection | false |
|
Details:
Values: true | false
Default: false Description: Identifies the feature type as a feature collection. |
|
| noPropertyType | false |
|
Details:
Values: true | false
Default: false Description: Surpress creation of a standard property type that supports inline or by-reference encoding (applies to ISO 19136:2007 encoding rule). |
| Constraint | Type | Status |
| @reportStatus != 'AMENDMENT' | Invariant | Approved |
|
Details:
Pattern ID: METAR_SPECI.MeteorologicalAerodromeObservationReport-1
Description: A METAR or SPECI report cannot have a reportStatus of 'AMENDMENT'
Assertion: ( @reportStatus != 'AMENDMENT' )

|
||
| Mandatory items in a report that failed translation | Invariant | Approved |
|
Details:
Pattern ID: METAR_SPECI.MeteorologicalAerodromeObservationReport-2
Description: A report that failed translation should have as a minimum appropriately filled elements including Iwxxm:issueTime, iwxxm:aerodrome and iwxxm:observationTime
Assertion: ( if( string-length(@translationFailedTAC) gt 0 ) then( exists(iwxxm:issueTime) and exists(iwxxm:aerodrome) and exists(iwxxm:observationTime) ) else( true() ) )

|
||
| Mandatory items in a Nil report | Invariant | Approved |
|
Details:
Pattern ID: METAR_SPECI.MeteorologicalAerodromeObservationReport-3
Description: A 'Nil' report should have appropriately filled elements including Iwxxm:issueTime, iwxxm:aerodrome, iwxxm:observationTime, iwxxm:observation (empty with nilReason) and iwxxm:trendForecast (missing)
Assertion: ( if( (empty(iwxxm:observation/*) and iwxxm:observation/@nilReason = 'http://codes.wmo.int/common/nil/missing') and string-length(@translationFailedTAC) eq 0 ) then( exists(iwxxm:issueTime) and exists(iwxxm:aerodrome) and exists(iwxxm:observationTime) and empty(iwxxm:trendForecast) ) else( true() ) )

|
||
| Mandatory items in an ordinary report | Invariant | Approved |
|
Details:
Pattern ID: METAR_SPECI.MeteorologicalAerodromeObservationReport-4
Description: An ordinary report should have appropriately filled elements including Iwxxm:issueTime, iwxxm:aerodrome, iwxxm:observationTime and iwxxm:observation
Assertion: ( if( string-length(@translationFailedTAC) eq 0 ) then( exists(iwxxm:issueTime) and exists(iwxxm:aerodrome) and exists(iwxxm:observationTime) and exists(iwxxm:observation) ) else( true() ) )

|
||
| if( ends-with(cloud/@nilReason, 'notDetectedByAutoSystem')) then( @automatedStation = 'true' ) | Invariant | Approved |
|
Details:
Pattern ID: METAR_SPECI.MeteorologicalAerodromeObservationReport-5
Description: When no clouds are detected by an automated station, this report must be an automated station report
Assertion: ( if( empty(iwxxm:observation//iwxxm:cloud/*) and ends-with(iwxxm:observation//iwxxm:cloud/@nilReason, 'notDetectedByAutoSystem') ) then( @automatedStation = 'true' ) else( true() ))

|
||
| if( ends-with(layer/@nilReason, 'notDetectedByAutoSystem')) ) then( @automatedStation = 'true' ) | Invariant | Approved |
|
Details:
Pattern ID: METAR_SPECI.MeteorologicalAerodromeObservationReport-6
Description: When both cloud amount and base are not detected by an automated station, this report must be an automated station report
Assertion: ( if( empty(iwxxm:observation//iwxxm:cloud//iwxxm:layer/*) and ends-with(iwxxm:observation//iwxxm:cloud//iwxxm:layer/@nilReason, 'notDetectedByAutoSystem') ) then( @automatedStation = 'true' ) else( true() ) )

|
||
| if( ends-with(amount/@nilReason, 'notDetectedByAutoSystem') ) then( @automatedStation = 'true' ) | Invariant | Approved |
|
Details:
Pattern ID: METAR_SPECI.MeteorologicalAerodromeObservationReport-7
Description: When cloud amount is not detected by an automated station, this report must be an automated station report
Assertion: ( if( empty(iwxxm:observation//iwxxm:cloud//iwxxm:layer//iwxxm:amount/*) and ends-with(iwxxm:observation//iwxxm:cloud//iwxxm:layer//iwxxm:amount/@nilReason, 'notDetectedByAutoSystem') ) then( @automatedStation = 'true' ) else( true() ) )

|
||
| if( ends-with(base/@nilReason, 'notDetectedByAutoSystem')) then( @automatedStation = 'true' ) | Invariant | Approved |
|
Details:
Pattern ID: METAR_SPECI.MeteorologicalAerodromeObservationReport-8
Description: When cloud base is not detected by an automated station, this report must be an automated station report
Assertion: ( if( empty(iwxxm:observation//iwxxm:cloud//iwxxm:layer//iwxxm:base/*) and ends-with(iwxxm:observation//iwxxm:cloud//iwxxm:layer//iwxxm:base/@nilReason, 'notDetectedByAutoSystem') ) then( @automatedStation = 'true' ) else( true() ) )

|
||
| CRS requirements for iwxxm:aerodrome | Invariant | Approved |
|
Details:
Pattern ID: METAR_SPECI.MeteorologicalAerodromeObservationReport-9
Description: If a geometry is defined for iwxxm:aerodrome//aixm:AIP with the provision of attribute srsName, attribute srsDimension must equal to 2 and attribute axisLabels must be non-empty
Assertion: ( if( exists(iwxxm:aerodrome//aixm:ARP) ) then( empty(index-of(iwxxm:aerodrome//aixm:ARP//gml:pos/(ancestor-or-self::*[exists(@srsName)])[last()]/(@srsDimension='2' and exists(@axisLabels)), false())) ) else( true() ) )

|
| Object | Type | Connection | Direction | Notes |
| «featureType» Report | Class | Generalization | To | |
| «featureType» METAR | Class | Generalization | From | |
| «featureType» SPECI | Class | Generalization | From |


{{+bindTo:partials.standard_nacl_api}}
| int32_t | x |
| int32_t | y |
The PP_Point structure defines the integer x and y coordinates of a point.
| int32_t PP_Point::x |
This value represents the horizontal coordinate of a point, starting with 0 as the left-most coordinate.
| int32_t PP_Point::y |
This value represents the vertical coordinate of a point, starting with 0 as the top-most coordinate.


Design of the OpenNMS Docker Environment
This is the Docker Environment for the open source network managament plattform OpenNMS. It is designed for testing purposes and smaller production setups and provides the following software:
-
OpenNMS
-
PostgreSQL
-
Nginx
-
Alarmforwarder
-
Cassandra
-
Grafana
-
yourDashboard
The environment is based on Docker Engine and Docker Compose. All related Docker Images are provided on Docker Hub.
The script container_generator.py creates an environment based on a few questions (e.g. which images should be used, which passwords should be set for OpenNMS, …). The result contains a generated docker_compose.yml file and an init directory, which contains some configuration, that will be loaded on the environment’s first start.
The environment’s base is OpenNMS, PostgreSQL and Nginx. Nginx provides a central SSL reverse proxy for all webservers of the environment (e.g. OpenNMS WebUI, or Grafana WebUI,…). A management container can be accessed via SSH to change configuration files.
Supported Hostsystems
The Docker Environment (especially the setup of Docker Engine and Docker Compose) was tested with CentOS 7. It should also run on other distributions, maybe some changes on the setup of Docker Engine/Docker Compose are required.
Limitations / Known Issues
The following points are known limitations and issues:
- Only small/medium sized environments
-
The Docker Environment has only been tested with running all the containers on one physical host. So, it is designed and tested for small and medium sized OpenNMS environments, where all the software can run on one host. In the future, there may be a cluster support.
- OpenNMS Horizon only
-
Currently, only OpenNMS Horizon is supported, but in the future, Meridian support will be available.
- Cassandra support for testing only
-
Cassandra support is only for testing purposes at the moment, as there is only one container which handles all the data.
- IPV6 NAT support
-
IPv6 support is provided with the ipv6helper container, which provides IPv6 NAT from the particular containers to the outside world. At this time, an incomming IPv6 connection from outside to the containers is not supported.
Setup
Generation of a Docker Environment
For the generation of the Docker Environment, the software Docker Engine and Docker Compose should be installed. After that, simply use the env_bootstrap/docker_compose.yml file to start the Generation Environment:
cd env_bootstrap
docker-compose up -d
You can then connect to the started container via SSH using the following command and the password secret1234:
ssh -p 2223<EMAIL_ADDRESS>In the box, start the script container_generator.py:
cd /opt/opennms-docker-env/scripts/container_generator/
./container_generator.py
The script asks for some parameters for the generation of the environment and creates an output directory which contains the following data:
-
docker-compose.yml
-
init directory for initializing of the defined containers
-
if defined: download of the docker images
-
if defined: download of the required software (Docker Engine, Docker Compse)
-
if defined: install.sh for Docker Images and Docker Engine/Docker Compose setup
Setup of the generated Environment
The generated environment can be installed on any latest Linux distribution. It has been tested under Centos 7. Simply use the files from the output directory. Execute install.sh to install Docker Engine, Docker Compose and the required images:
./install.sh
You can now start the generated environment with docker-compose:
docker-compose up -d
optional: Change network of docker0
By default, Docker Engine creates a network interface named docker0 with an IP address <IP_ADDRESS>/16. If you need to change it, please create the following configuration file /etc/docker/daemon.json:
{
"bip": "<IP_ADDRESS>/24"
}
optional: Move RRDs to another partition
Sometimes, it is required to move the OpenNMS RRD data to another physical disc, to improve the I/O performance. To do so in the Docker Environment, find the mountpoint of the RRDs with docker volume inspect:
docker volume inspect <opennms volume>
After that, stop the environment, move the RRD files to the other disk, create a symbolic link and start the environment again. For example, if the mountpoint of the OpenNMS RRD volume is /var/lib/docker/volumes/output_rrd/_data, and the mountpoint of the other physical disk is _/mnt/opennms-rrd, you’ll can do the following:
docker-compose down
mv /var/lib/docker/volumes/output_rrd/ /mnt/opennms-rrd
ln -s /mnt/opennms-rrd /var/lib/docker/volumes/output_rrd/
docker-compose up -d
Management of the Environment
The Docker Environment can be managed by using the management container. It provides an SSH server which can be acccessed with the following command and the password chosen during the setup:
ssh -p 2222 root@host
It contains some nice tools (e.g. ping, traceroute, telnet, snmpwalk, …) and access to the data and configuration files of all containers in /data/all-containers. It also contains a docker client to start/stop containers.
Operating
The following section describes the operational concepts of the Docker Environment.
Migration of an existing OpenNMS installation
To migrate an existing OpenNMS installation into the new Docker Environment, the following steps are required:
-
Back up the existing installation
-
Setup the OpenNMS Docker Environment, but do not start the environment yet
-
Place the (migrated, if necessary) data of the existing installation in the init directory of the Docker Environment
-
Start the environment
At first, the data of an existing setup must be secured. For OpenNMS, there are the configuration files, a database dump, RRD files and (if necessary) further files. If a version upgrade should be done with the migration, the secured data must also be migrated for the new version.
After that, the OpenNMS Docker Environment must be installed, but should not be started yet. The environment has the directory init, which contains a subdirectory for every container. The data for initializing of the environment must be placed there. Please see the section Import and Export of Data to see the directory structure for each container. On the environment’s first start, these data will be imported one-time (they will be copied and can be deleted from the init directory). The environment with the imported data can now be used.
Configuration Changes
Configuration changes for OpenNMS and the other provided software can be done with the management container. You can connect via SSH into the management container and find the data of all other containers in /data/all-containers/<container name>. Simply change the configuration files you like and restart the required container by using the docker commands:
docker ps
docker stop <container-name>
docker start <container-name>
A docker ps returns a list with all running docker containers. You can also find the container name in the list. The docker start/stop commands will stop and start the container.
Backup
A manual backup of the Environment can be done by executing the following command in the management container:
/opt/managerscripts/command_for_all.sh export
When the backup has finished, the exported data are located in /data/export (in management container or on the named volume) and can be copied to an external storage medium.
A daily backup to a SMB fileserver or FTP server can also be done automatically using a cronjob. Simply use the environment variables of the management container:
CONF_BACKUP_ENABLED = TRUE
CONF_BACKUP_URL = smb://user:password@server/share/directory
#or in case of a FTP server:
CONF_BACKUP_URL = ftp://user:password@server/directory
A daily cronjob will execute the backup at 09:00 p.m. to the configured target.
| The container_generator script will also ask you for the parameters above and can create the required configuration. |
Restore
A restore of the whole environment on a new hardware requires the following data:
-
supported operating system
-
generated Docker Environment in the original version (Docker Engine, Docker Compose, Docker Images, docker-compose.yml and the init directory)
-
backup of the environment
The generated Docker Enviroment consists of the following directoy structure:
docker-compose.yml
/init
/opennms
/postgres
/<...>
The following steps has to be done for a restore:
-
setup of the operating system
-
setup of the generated Docker Environment (Docker-Engine, Docker Compose, images, configuration)
-
replacement of the init directory of the generated environment with the backup
-
start of the environment
Major Update
A major update contains a change of the major version of OpenNMS. The database schema and configuration files needs to be migrated. For a major update, the following steps needs to be done:
-
preparation within a testing environment
-
creation of a new version of the Docker Environment
-
data export from the existing environment
-
migration of the exported data in the testing environment
-
-
update on live system
-
creation of a new version of the Docker Environment with the migrated data
-
stop of the old environment
-
start of the new environment
-
First of all, a testing environment with the new version of the Docker Environment will be created. After that, a data export from the existing environment will be done. The following command needs to be executed on the management container:
/opt/managerscripts/command_for_all.sh export
In the testing environment, the exportet data will now be migrated step by step (e.g. OpenNMS configuration files, but also files from further containers). The intention is, to create the Docker Environment in a new version with the following directory structure:
docker-compose.yml
/init
/opennms (1)
/postgres (2)
/<...>
| 1 | migrated data for container OpenNMS |
| 2 | migrated data for container Postgres |
If the migration has been finished and all tests have been passed successfully, the created environment with the migrated data can be installed in the live system. It is very important, that the parent directory for the new Docker environment has an other name as the parent directory for the existing environment. For example:
/opt
/onmsenv
/v1 (1)
docker-compose.yml
/init
/opennms
/<...>
/v2 (2)
docker-compose.yml
/init
/opennms
/<...>
| 1 | version 1 of the Docker Environment. Will also be used for the name prefix of named volumes. |
| 2 | version 2 of the Docker Environment. Will also be used for the name prefix of named volumes. |
| The name of the parent directory (e.g. v1 or v2) will also be used as prefix for the names of named volumes. Because of the diffetent names, you can switch between the environments on any time during the following steps. |
The old Docker Environment can now be stopped on the live system with the following commands:
cd /opt/onmsenv/v1
docker-compose down
Now, the neu version can be started:
cd /opt/onmsenv/v2
docker-compose up -d
If all tests have beed passed successfully and the new environment is stable, the old names volumes can be deleted:
docker volume rm v1_opennms v1_postgres [...]
The update has been done.
Minor Update
A minor update only contains a change of a minor version of OpenNMS or further add-ons. Existing data does not need to be migrated. Thus, the preparation in a testing environment is not required and the update can be done in a simpler and faster way.
| Also a minor update should be prepared carefully und the general process should be tested in a testing environment. |
The following steps needs to be done for a minor update:
-
creation of a new version of the Docker Environment
-
setup of the environment on the live system
-
data export from the existing environment
-
replacement of the init directory of the generated environment with the export
-
stop of the old environment
-
start of the new environment
The particular steps correspond to the steps described in section Major Update
Import and Export of Data
The import of data into the OpenNMS Docker Environment will only be done during the initializing on the container’s first start. All files in the directory data/init of the container will be included. Every container will only import his own data. For example, the OpenNMS container does only import the OpenNMS configuration files, while the OpenNMS database will be imported into the Postgres container. The structure in /data/init depends on the given container and will be described in the next sections of this document. The environment created by container_generator has the following structure:
docker-compose.yml
/init
/opennms (1)
/postgres (2)
/<...>
| 1 | Will be mapped in container OpenNMS to /data/init |
| 2 | will be mapped in container Postgres to /data/init |
Data export of the Docker Environment will be done by executing the following command in the management container:
/opt/managerscripts/command_for_all.sh export
This will execute the script /opt/containerscripts/export.sh in every container of the docker environment. The export.sh script exports the data for the particular container into the /data/export/<container>/ directory. In the generated Docker Environment, the directory /data/export/ mapped into all container as named volume.
| The structure of /data/export matches with the structure of /data/init, which can be used to import data into a new environment. So, exported data can be reimported easily. |
The following sections describe the import of data for the containers.
OpenNMS
The following directories can be used to initialize the OpenNMS container:
docker-compose.yml
/init
/opennms
/etc
/rrd
/lib_add
/web_add
etc
In etc, OpenNMS configuration files can be placed for an import. Please consider the following points, when importing configuration files:
-
differences between OpenNMS versions
-
in some config files, the full path of the configuration directory is hard coded(e.g.: /var/lib/opennms/rrd vs. /opt/opennms/share/rrd)
-
some configuration files in the Docker environment may not be overwritten, this is
-
java.conf
-
rrd
The directory rrd contains RRD files to be imported. The following directory structre needs to be met:
/rrd
/response
/snmp
lib_add
Additional JAR files for /opt/opennms/lib can be placed in lib_add. Also, existing files in the OpenNMS Docker image can be overwritten.
web_add
In web_add, additional files for the OpenNMS WebUI (/opt/opennms/jetty_webapps) can be placed. Existing files will be overwritten.
PostgreSQL
The container PostgreSQL is the database server for the environment. The import of data can be done with SQL dumps. The following directory structure can be used:
docker-compose.yml
/init
/postgres
/sql
sql
Database dumps (e.g. from an OpenNMS or AlarmForwarder system) can be placed in the sql directory. Every dump must be created with specific options (--create and replacement of specific characters) and be named with the file extension *.sql. Please see the following examples for the creation of an OpenNMS and AlarmForwarder dump:
pg_dump --create -U opennms > db_opennms.sql && sed -i "s/LC_COLLATE = '.*' LC_CTYPE = '.*'//g" db_opennms.sql
pg_dump --create -U alarmforwarder > db_alarmforwarder.sql && sed -i "s/LC_COLLATE = '.*' LC_CTYPE = '.*'//g" db_alarmforwarder.sql
| The schema of an imported OpenNMS database will be updated automatically to the version used in the Docker image.(the OpenNMS version must not be older than the version where the database dump was created). |
Nginx
For initializing of Nginx, the following directory structure can be used:
docker-compose.yml
/init
/nginx
/etc
/ssl
etc/ssl
SSL certificate (name proxy.crt) and key (name proxy.key) can be placed here for an import.
Management
For the import of data into the management container, please use the following directory structure:
docker-compose.yml
/init
/management
/etc
etc
The etc directory can contain a configuration file for the automatic backup of the environment. The configuration file should have the name backup.conf.
AlarmForwarder
Most of AlarmForwarder’s data were hold in the AlarmForwarder database, which will be imported into the Postgres container. The configuration can be imported usinig the following structure:
docker-compose.yml
/init
/alarmforwarder
/etc
etc
The AlarmForwarder configuration alarmforwarder.conf can be imported using this directory.
Cassandra
| Cassandra support within the Docker Environment is experimental at the moment and for testing purposes only. |
Existing data can be imported using the following structure:
docker-compose.yml
/init
/cassandra
/schema
/snapshot
schema
This directory contains the schema definitions for the particular keyspaces of a cassandra database. These could be created with the following command:
CQL="DESC KEYSPACE ${KEYSPACE};"
cqlsh -u ${CASSANDRA_USER} -p ${CASSANDRA_PASSWORD} -e \"${CQL}\" ${HOSTNAME}" > ${SCHEMAFILE}
snapshot
This directory contains snapshots of cassandra tables. Please see an example script for the creation of snapshots:
/opt/cassandra/bin/nodetool snapshot -t export
SNAPSHOT_PATHS=`find /opt/cassandra/data/data/ -name "export" -type d`
for SNAPSHOT_PATH in ${SNAPSHOT_PATHS}
do
SNAPSHOT_SUBDIR=${SNAPSHOT_PATH#/opt/cassandra/data/data}
TARGET_SUBDIR=${SNAPSHOT_SUBDIR%/snapshots/export}
if [[ $TARGET_SUBDIR != /system* ]] ;
then
TARGET_DIR=${DUMPDIR}/snapshot/${TARGET_SUBDIR}
mkdir -p ${TARGET_DIR}
cp ${SNAPSHOT_PATH}/* ${TARGET_DIR}
fi
done
/opt/cassandra/bin/nodetool clearsnapshot -t export
Grafana
The following directories can be used to initialize the Grafana container:
docker-compose.yml
/init
/grafana
/conf
/data
conf
The directory conf contains the configuration files of Grafana (<Grafana-Home>/conf directory)
data
The data directory contains an existing data directory of Grafana (<Grafana-Home>/data)
PRIS
For the import of data in PRIS, please use the following directory structure:
docker-compose.yml
/init
/pris
/requisitions
requisitions
The requisitions directory contains the definitions for Provisioning Requisitions, which are placed in <PRIS-Home>/requisitions in PRIS.
yourDashboard
Use the following structure for an import of configuration files in yourDashboard
docker-compose.yml
/init
/yourdashboard
/etc
etc
Configuration files for <yourDashboard-Home>/etc can be placed in etc. Theses files will be imported on the container’s first start.


Introduction
I came across a study (on the internet, not peer reviewed) that had the goal of evaluating how long coffee beans should rest after they’re roasted before they’re ground and tasted for quality. The full study report is here: https://cafekreyol.com/research/post-roast-rest-study/. For a little background, when coffee beans are roasted, CO2 gets trapped in the beans, and then escapes over time as the coffee beans rest. It is generally well accepted that coffee beans need to rest at least 24 hours, since the amount of CO2 in the beans right after roasting prevents the coffee from tasting as good as it can. However, after a certain number of days, the coffee will begin to taste stale.
When assessing roasted bean quality, the industry standard is to let coffee beans roast for about 24 hours. This study wanted to see if quality improved with an even longer rest time.
Study Design
I thought this study was very nicely designed (although I will discuss at the end on how I think it could potentially be improved). On day 0, they roasted 21 different coffee beans. They used a roaster that produced identical roasts for each of the beans, and they roasted each coffee 5 times. After this roasting, they had 105 (21 times 5) bags of coffee. The idea is that they would taste (cup) each of the coffees on days 4, 8, 11, 17, and 22 post-roast. One day before each tasting (days 3, 7, 10, 16, and 21), they roasted each of the coffees again, so that they could have a 24-hour rested control sample for each coffee and tasting.
The tasting was extremely standardized (down to water temperature and grind size), and each cup was blindly tasted by 3 expert raters. Each rater evaluated the coffee using a standardized scale (https://atlanticspecialtycoffee.com/wp-content/uploads/SCAA-Official-Cupping-Form.pdf), with a potential score between 0-100. However, cupping scores are usually between 80-95. The study has only publicly posted the average score for each coffee across the 3 raters.
Study Analysis
I think it is helpful to visualize the study data to get a better handle on what it looks like. I’m not going to go into data cleaning, although you can see how I did it using this github link.
You can see that each coffee was tasting twice at each tasting. For each of the coffees, one of the cups had brewed coffee that had been roasted on day 0 (the “Multi-day Rested” in blue), and the other cup had brewed coffee that had been roasted 24-hours previously (the “Control (1-day rested)” in red.) Note that for Coffee #1, the 4-day rested coffee was not evaluated because there was a defect unrelated to the rest-time. I think this plot emphasizes the paired nature of each tasting, in that we can compare the rested coffee at each time point to a control sample that had been roasted 1-day before, but was (blindly) tasted at the same time.
The original study analysis proceeded as follows. First, they averaged the control sample scores for each coffee across each of the 5 tastings, rather than comparing the treatment (more resting time) coffee to the control coffee within each tasting. I find this interesting, as it seems that they set-up having 1-day rested coffees for each day to serve as an internal control, but then totally ignored this in the analysis (more on this later). For each coffee, they noted which day had the highest score, with the day 1 score being the average of all the roasted coffees. For each day they calculated the percentage of coffees where the beans with that rest time had the highest score, and they compared these percentages across days, finding that the majority of the 68% of the coffees peaked on either day 4, 8, or 11.
While this analysis is not totally unreasonable, especially for a non-academic study, statisticians have shown that its preferable to not dichotimize the data before doing the analysis–that is, by reducing each coffee to saying which day it peaked, rather than looking at the magnitude of the peak, we lose a lot of information.
For our first analysis, we will ignore the paired nature of the rested and control beans, and treat all of the control coffees as if they were tasted on day 1, since each of the controls were only tasted 1 day after they were roasted. This is essentially what the original analysis did. We can visualize this assumption and compare it to the study design plotted above.
We see that this treats the data as if there were 5 scores for the 1-day rested beans, and then 1 score for the multi-day rested beans, for each coffee. To analyze this, we will use a random-intercept model, where each coffee gets a random intercept, and then each rest-day is a fixed effect. By using a random intercept model, we are saying that each coffee has its own baseline (day-1) score–some coffees are better than others, of course–but then we expect each of the changes from that baseline, due to rest time and tasting session, to be the same for all of the coffees. Here is how we would fit that model in R, and then show the estimates, standard errors, p-values, and 95% confidence intervals for our coefficients of interest.
library(lme4)
library(lmerTest)
library(emmeans)
### Show what data looks like
head(d_long_unpaired, 10)
## # A tibble: 10 × 6
## coffee group day score number day_factor
## <fct> <fct> <dbl> <dbl> <dbl> <fct>
## 1 #1 Caribbean Washed Multi-day Rested 4 83.1 1 4
## 2 #1 Caribbean Washed Multi-day Rested 8 84.4 1 8
## 3 #1 Caribbean Washed Multi-day Rested 11 83.1 1 11
## 4 #1 Caribbean Washed Multi-day Rested 17 84.4 1 17
## 5 #1 Caribbean Washed Multi-day Rested 22 83.1 1 22
## 6 #1 Caribbean Washed Control (1-day rested) 1 NA 1 1
## 7 #1 Caribbean Washed Control (1-day rested) 1 84.1 1 1
## 8 #1 Caribbean Washed Control (1-day rested) 1 84.1 1 1
## 9 #1 Caribbean Washed Control (1-day rested) 1 83.9 1 1
## 10 #1 Caribbean Washed Control (1-day rested) 1 84.1 1 1
unpaired_model <- lmer(score ~ day_factor + (1 |coffee), data = d_long_unpaired)
coef_table <- coef(summary(unpaired_model))[,-c(3:4)]
coef_table <- cbind(coef_table,confint(unpaired_model)[-(1:2),] )
| Estimate | Std. Error | Pr(>|t|) | 2.5 % | 97.5 % | |
|---|---|---|---|---|---|
| (Intercept) | 84.57 | 0.31 | 0.00 | 83.94 | 85.20 |
| day_factor4 | 0.33 | 0.19 | 0.09 | -0.05 | 0.71 |
| day_factor8 | 0.70 | 0.19 | 0.00 | 0.32 | 1.07 |
| day_factor11 | 0.26 | 0.19 | 0.18 | -0.12 | 0.64 |
| day_factor17 | 0.09 | 0.19 | 0.65 | -0.29 | 0.47 |
| day_factor22 | 0.29 | 0.19 | 0.13 | -0.08 | 0.67 |
In the table above, the intercept represents the mean score for coffees that have been
rested for 1 day. day_factor4
represents the average difference in cupping
score for coffees that have been rested for 4 days vs 1 day, day_factor8
represents the average difference in cupping score for coffees that have been rested for 8 days vs 1 day, and the rest of the coefficients are interpreted similarly. We see
that this model finds a significant increase in cupping scores for coffees
that have been rested for 8 days vs 1 (estimated increase of .70, 95% CI of (.32, 1.07)), and does not find evidence that the cupping scores increases for other
days of rest. This is what was suggested in the original study, but now we come to this
conclusion through more a rigorous analysis that also gives us an effect size estimate.
We will now run an analysis which takes into account the paired nature of the tastings. This model will have a random intercept for each coffee, as before, but now our model will estimate the average control score for each tasting, as well as the average difference between the rested coffee and the control coffee at each tasting. This is essentially subtracting the rested beans and control beans score for each coffee, and estimating the mean for this at each tasting. As opposed to our first analysis, this analysis importantly does not assume that the scores for the control coffees tasted on one day can be switched for the scores of the control coffees tasted on another day–you might recognize this as not assuming exchangeability between control samples. This also importantly assumes that on average, each of the control coffees experience the same shift in scores within a tasting, which could happen from tasters on one day perhaps all giving higher scores than on another day.
### Show what data looks like
head(d_long_paired, 10)
## # A tibble: 10 × 6
## coffee group day score number day_factor
## <fct> <fct> <dbl> <dbl> <dbl> <fct>
## 1 #1 Caribbean Washed Multi-day Rested 4 83.1 1 4
## 2 #1 Caribbean Washed Multi-day Rested 8 84.4 1 8
## 3 #1 Caribbean Washed Multi-day Rested 11 83.1 1 11
## 4 #1 Caribbean Washed Multi-day Rested 17 84.4 1 17
## 5 #1 Caribbean Washed Multi-day Rested 22 83.1 1 22
## 6 #1 Caribbean Washed Control (1-day rested) 4 NA 1 4
## 7 #1 Caribbean Washed Control (1-day rested) 8 84.1 1 8
## 8 #1 Caribbean Washed Control (1-day rested) 11 84.1 1 11
## 9 #1 Caribbean Washed Control (1-day rested) 17 83.9 1 17
## 10 #1 Caribbean Washed Control (1-day rested) 22 84.1 1 22
paired_model <- lmer(score ~ group*day_factor + (1 |coffee), data = d_long_paired)
coef_table <- coef(summary(paired_model))[,-c(3:4)]
coef_table <- cbind(coef_table,confint(paired_model)[-(1:2),] )
| Estimate | Std. Error | Pr(>|t|) | 2.5 % | 97.5 % | |
|---|---|---|---|---|---|
| (Intercept) | 84.59 | 0.35 | 0.00 | 83.89 | 85.29 |
| groupMulti-day Rested | 0.31 | 0.25 | 0.23 | -0.18 | 0.80 |
| day_factor8 | 0.18 | 0.25 | 0.47 | -0.31 | 0.67 |
| day_factor11 | -0.12 | 0.25 | 0.64 | -0.61 | 0.37 |
| day_factor17 | -0.03 | 0.25 | 0.90 | -0.52 | 0.46 |
| day_factor22 | -0.14 | 0.25 | 0.58 | -0.63 | 0.35 |
| groupMulti-day Rested:day_factor8 | 0.18 | 0.36 | 0.61 | -0.51 | 0.87 |
| groupMulti-day Rested:day_factor11 | 0.05 | 0.36 | 0.89 | -0.64 | 0.74 |
| groupMulti-day Rested:day_factor17 | -0.21 | 0.36 | 0.56 | -0.90 | 0.48 |
| groupMulti-day Rested:day_factor22 | 0.11 | 0.36 | 0.77 | -0.58 | 0.79 |
The coefficient interpretation is now different. The groupRested
coefficient estimates the average difference in tasting scores between
4-day rested coffees and 1-day rested coffees. day_factor8
, day_factor11
,
day_factor17
, and day_factor22
estimate the average difference in control
cupping scores comparing days 8, 11, 17, and 22 to day 4, respectively. The complicated
part of this model is the interpretation of the interaction effects. For example,
the groupRested:day_factor8
, coefficient estimates
the difference between the differences of coffees rested 8 days compared to 1 day vs
coffees rested 4 days compared to 1 day. To get the the we actually want–
the differences between coffees rested 8, 11, 17, and 22 days vs 1 day–
we can use the emmeans package.
contrasts <- emmeans(paired_model, specs = pairwise ~ group|day_factor, type = "response")$contrasts
| contrast | day_factor | estimate | SE | df | t.ratio | p.value |
|---|---|---|---|---|---|---|
| (Control (1-day rested)) - (Multi-day Rested) | 4 | -0.3067079 | 0.2548417 | 179.0353 | -1.2035231 | 0.2303629 |
| (Control (1-day rested)) - (Multi-day Rested) | 8 | -0.4895238 | 0.2513840 | 179.0000 | -1.9473149 | 0.0530616 |
| (Control (1-day rested)) - (Multi-day Rested) | 11 | -0.3571429 | 0.2513840 | 179.0000 | -1.4207064 | 0.1571417 |
| (Control (1-day rested)) - (Multi-day Rested) | 17 | -0.0990476 | 0.2513840 | 179.0000 | -0.3940092 | 0.6940432 |
| (Control (1-day rested)) - (Multi-day Rested) | 22 | -0.4123810 | 0.2513840 | 179.0000 | -1.6404423 | 0.1026693 |
While the emmeans package flips the comparisons around (i.e. a negative number means a higher score for multi-day rested coffees), we see again that we still estimate that coffees rested 8 days have the higher score. However, the estimated difference is now lower than when we did the unpaired analysis, and the p-value is just above the .05 significance level. Thus we this analysis does not allow us to conclude that there is a significant effect of resting coffee for more than 1-day, although I would not be surprised to see if a slightly larger future study were to find this out. In addition, this analysis does not show that there was a “tasting” effect, as the average score of the control coffees were similar across each tasting session.
Conclusion and Recommendations for Future Studies
I thought this was a really nicely designed study. The authors clearly thought carefully about controlling all factors that might contribute to variable cupping scores, which is more than you can say about most experimental designs. The conclusion from a statistical analysis depends on what you’re willing to assume about exchangability of control sample scores across the different days. If you ignore the fact that each control coffee was scored on a different day, in conjunction with a multi-day rested coffee, then you see some evidence that resting coffees does result in higher cupping scores. However, we fail to see that if we take into account the paired nature of the experiment.
If this experiment were to be repeated, I would change the design just a bit. Rather than roasting all coffees on day 0, and then doing 5 different tastings, I would only have 1 tasting (if possible). I would then do 6 different roast sessions–one 22 days before, one 17 days before, one 11 days before, one 8 days before, one 4 days before, and one 1 day before. Then for each coffee and rest-time, I would have multiple samples to be evaluated. Because the roasting is more controlled than the cupping, this eliminates the variability of each cupping being performed on different days, so we don’t have to make as many assumptions for the analysis.
Of course, there are other ways you could analyze this data, so I’d be interested to see what other people recommend and conclude–I expect that some people would want to do a Bayesian analysis. I think this is a great dataset for teaching as well, since it teaches about experimental design, the importance of assumptions in analysis, coefficient interpretation, and random effects.


Toggle navigation
Your Brand
About
(current)
CV
my posts
Tutorials
Web Design
Data Science
Computational biology
Cooking receipts
Research
Motif discovery
Population genetics
Something else here
Separated link
Others
Action
Another action
Something else here
Separated link
Please write a sentence here!
Put your content HERE
my keyword1
my keyword2
my keyword3