スキップしてメイン コンテンツに移動

良質な R package のコードを読むよ

突然ですが「シリーズ: 良質なR package のコードを読むよ」が俺のなかだけで始まりました。

良質のRコードといえば、Bioconductor (以下、BioC) ですね。ここでは BioC を読んでいきますが、すべての R ユーザに有益なはずです。あまり BioC だと気付かずに使っているパッケージもあるはずよ。R本体のコードを読む訳ではありませんので誤解なきよう。

目次


第1回: Bioconductor のパッケージについて知る
第2回: Bioconductor のソースコードを得る
第3回: Bioconductor にはS4で書かれたコードがどのぐらいあるか
(連載中)

なぜ Bioconductor を読むのか?


BioC は R を開発しているメンバーと重なっているのでコードの質が高い(と期待
コードレビューされているので質が高い(と期待
S4を推奨しているので S4 OOP な R コードが読める

なにをするのか?


BioCのコードを読み進めたときに書いたメモをアップしていきます。メモなのであまり読者を想定していません。よーわからん、という人は元の情報に当たるか、聞いてください。

BioCパッケージについて知る


さて本題です。今回は、R パッケージに求められることや、その構造を知るため、Bioconductor パッケージガイドラインパッケージサブミッションガイドを読みます。

あまり細かいことを書いてもしょうがないので、ざっくりとサマリを書きます。BioCは特にコードの質とドキュメンテーションについてこだわっていることがわかります。

BioCのパッケージは以下の条件を満す必要があります。すべて must です。

1. R CMD build, R CMD check が通ること


Windows, Mac, Linux の3つのプラットフォームでチェックが通る必要があります。

2. 重複がないこと


パッケージ名の重複をチェック
[code]
source("http://bioconductor.org/biocLite.R");
biocLite("mypackage")
[/code]

混乱を避けるためCRANとBioCの両方をパッケージを登録してはいけません。
またすでにあるパッケージやクラスの機能的を積極的に利用し、機能的な重複も避けるようにします。例えば、ExpressionSet や AnnotationDataFrame など。

3. ドキュメンテーション


すべてのメソッドに man page を書く必要があります。動作可能な example を含める必要があります。また、Vignette も含める必要があります。書きかたはこちら。1.4 Writing package vignettes. パッケージの更新情報は inst/NEWS に含めます。

4. NAMESPACE と DESCRIPTION を含める


前者がパッケージの名前空間を宣言するファイルで、後者が作者やライセンス情報などを記載するファイルです。

5. S4 class と method による実装


Google には dis られている S4 ですが、BioC では S4 こそ正義! といっても実際は BioC のなかには S4 じゃないコードもいっぱいあります。

6. 不必要なファイルの排除


Mac でありがちな、.DS_Store とか dot ファイル、.git, .svn などを含めてはいけません。

まとめ


以上、BioC、つまり、Rを作っている人達がどのようなパッケージを良いパッケージと考えているかがわかりました。一言で言うとドキュメンテーションと重複のないS4によるコードを重視しているということですね。個人的にはユニットテストについてルールがないのがどうかな、と思いました。

続きます。

コメント

  1. [...] Bioconductor には S4 で書かれたコードがどのぐらいあるのか [...]

    返信削除
  2. [...] 第1回: Bioconductor のパッケージについて知る 第2回: Bioconductor のソースコードを得る 第3回: Bioconductor には S4 で書かれたコードがどのぐらいあるのか 第4回: R package の構造 ← R package [...]

    返信削除

コメントを投稿

このブログの人気の投稿

シーケンスアダプタ配列除去ツールまとめ

FASTQ/A file からシーケンスアダプター配列やプライマー配列を除くためのプログラムをまとめてみる。 まず、配列の除去には大別して2つの方向性がある。ひとつは、アダプター配列を含む「リード」を除いてしまう方法。もうひとつは除きたい配列をリードからトリムする方法である。後者のほうが有効リードが増えるメリットが、綺麗に除ききれない場合は、ゲノムへのマップ率が下がる。 気をつける点としては、アダプター/プライマーの reverse complement を検索するかどうか。paired end の際には大事になる。クオリティでトリムできるものや、Paired-end を考慮するものなどもある。アダプター/プライマー配列の文字列を引数として直接入力するものと、multi fasta 形式で指定できるももある。 From Evernote: シーケンスアダプタ配列除去ツールまとめ TagDust http://genome.gsc.riken.jp/osc/english/software/src/nexalign-1.3.5.tgz http://bioinformatics.oxfordjournals.org/content/25/21/2839.full インストール: curl -O http://genome.gsc.riken.jp/osc/english/software/src/tagdust.tgztar zxvf tagdust.tgz cd tagdust/ make sudo make install rehash 使いかた: tagdust adapter.fasta input.fastq -fdr 0.05 -o output.clean.fastq -a output.artifactual.fastq 解説: 入出力形式は fastq/a が使える。リード全体を除く。速い。アダプター配列を fasta 形式で入力できるのが地味に便利で、これに対応しているものがなかなかない。Muth–Manber algorithm (Approximate multiple

DNAを増幅するサーマルサイクラーを自作してみたよ

DNAをPCR法で増幅するために必要なサーマルサイクラーを自作してみました。自作と言っても、いわゆる、PCの自作と同じでパーツを組み立てていく感じです。購入から組み立ての様子を簡単に紹介します。 モチベーション ラボには様々なレクリエーションがあります。例えば、単にどこかに遊びに行ったり、スポーツ大会したり、ひたすら合宿形式でプログレスのプレゼンをするミーティングするなどがあります。それもよいのですが、せっかくなので、普段の研究時間ではトライできないが、研究に関わる hack を行う、というイベントを企画してみました。夏休みの自由研究や社会科見学的なノリです。   うちのラボでは、PCRを使ったウェットの実験技術の開発をしてきました。しかし、サーマルサイクラーのハードウェアの仕組みを体験的に理解している訳ではありません。そこで、サーマルサイクラーを作ってみました。   欧米で始まっている、自宅のガレージやキッチンでバイオロジーを行うムーブメント、バイオパンク、DIYbio を体験しておきたいというのもありますし、Arduino などオープンハードウェア、Maker のムーブメントを体験するのも目的の一つです。ハードウェア開発が思っているほどハードルが下っていることを体験できて、かつ、将来、ウェットの開発だけでなく、装置開発などもできたら、ラッキー、ぐらいの気持ちでやってみました。   購入 今回作ったのは、組み立て式で、かつ、仕様などや設計図が公開されているOpenPCRというサーマルサイクラーです。ハードウェアの仕様・設計図、制御ソフトウェアなどの情報がすべて公開されており、部品からも自作することが可能です。今回は、「設計図から部品や回路のパーツを作り、それらを組み立てる直前のもの」を購入しました。   ChaiBio https://www.chaibio.com/   OpenPCR https://www.chaibio.com/products/openpcr   なぜか http://openpcr.org/  で購入できなかったので、eBay にある ChaiBio で買いました。   OpenPCR - eBay http://www.ebay.com/itm/111096418574   本体価格は

R でいまどきなパッケージ開発 (devtools, testthat, roxygen2)

追記 (2012/04/21): 以下のコードは S4 classes で書いていますが、R5 reference classes で書き直してみました。こちらもどうぞ。 http://blog.hackingisbelieving.org/2012/04/r5-reference-class-r-devtools-testthat.html R のパッケージ開発の情報があまりないので、自分はこんな感じでやってます、というのを書いてみます。パッケージ開発支援の devtools と単体テスト支援の testthat, そしてドキュメント生成支援の roxygen を使うのがいまどきっぽいです。 そもそもパッケージを作製しているひとをあまりみたことがないので、もっとこうすべき、というのがあれば教えてほしいです。 今回はデモケースとして S4 OOP で、Idol クラスを定義し、とある身体的特徴の統計量を計算するパッケージを作ります。R のプロンプトは > で、シェルのプロンプトは $ で示しています。 0. 準備 必要になるパッケージをインストールします。 $ sudo R > install.packages(devtools) > install.packages(testthat) > q() devtools の設定をします。~/.Rpackages に設定を記述します。 $ emacs ~/.Rpackages list(   default = function(x) {     file.path("~/Project/dev/R/", x, x)   },   "idol" = "~/Projects/dev/R/idol/idol" ) 以下の行は今回パッケージを作製する作業ディレクトリになります。   "idol" = "~/Projects/dev/R/idol/idol" 1. ともあれ実装を始める 作業ディレクトリに移動します。 $mkdir -p ~/Project/dev/R/idol $ cd ~