events

Pitagora Meetup 2019-02

概要

• 日時： 2019年2月5日（火）10:00 〜 18:30
• 場所： 理化学研究所革新知能統合研究センター (東京・日本橋) 会議室5
• 連絡先： 大田 t.ohta [at] dbcls.rois.ac.jp
• Skype ID：pitagora-network (最新バージョンのSkypeの使用を推奨)

タイムテーブル

途中参加、途中退出は自由です。ランチの時間は部屋に誰もいなくなる可能性があるので、施錠の関係上、この前後にお越し頂けるとスムーズです。

Time
10:00-10:15	今日の作業確認
10:15-11:30	開発とディスカッション
11:30-12:30	ランチ
12:30-18:00	開発とディスカッション
18:00-18:30	ラップアップ

ミートアップの主旨

• データ解析ツール・ワークフローを共有する
  • ソフトウェアをコンテナ化する
  • Galaxy や CWL などを使ってツール定義、ワークフロー定義を書く
  • ドキュメントを書いて GitHub で公開する
• 共有されたツールやワークフローを実行する
  • うまくいったこと、うまくいかなかったことを記録する
• 技術情報を共有する
  • twitter に post する
  • ブログを書く
• 関連OSSプロジェクトにコミットする
  • SNSで質問する
    • hashtag をつけて twitter で
    • プロジェクトの Gitter channel があればそこで聞く
  • Issueを立てる
  • Pull Request を送る
• その他データ解析に関わる人々の日々の暮らしが豊かになる開発を進める

まとめ

参加人数: 10人 エア参加人数: 1人

大田

• 続・DRY解析教本
  • コンテナ化/CWL化？
  • 求む協力者
• 薬師寺さんに CWL-metrics の成果を共有した
  • RNA-Seq のパイプラインいろいろあるが何が違うのか
• DDBJ workflow execution service Code: Sapporo の設計についてすえたけくんと話をした
• すえたけくんが出した cwltool への issues にコメントしたりした
• リバイズ遅々として進まず
• 今年はGoかRust書く
  • D…

志波

• Nanopore関係のツールがGalaxyにあるか調査
• Docker版Galaxyにナノポア関係のツールをインストール
• QIIME2のラッパーを調査
  • qiime2_wrappers
    • QIIME2自体がインストールされていない
      • conda経由でインストールする形になっているがBiocondaにQIIME2無し
• メタゲノム解析関係のラッパーXMLを更新
  • centrifuge_kreport

末竹

• 年末から作っている Workflow 実行システムが一応動くようになった
  • https://github.com/suecharo/SAPPORO/releases/tag/V0.1
• これのデプロイ方法やもう少し Production としての環境を整えていた
  • workflow を追加する際のフロー
  • Flask や Django を uWSGI や nginx で wrap したりとかを頑張ってた
• 今度デモしたい

山中

• 浅井さんをヘルプしようとしてできなかった（詳細は浅井さんの項を参照）

松尾

• お仕事してました…
  • 社内の解析環境整備のための予算取り
• コード書きたい

浅井

• 既存の Docker で動かないツールを実行できるようにしようと山中さんに手伝ってもらってひたすら頑張ってました。
  • docker galaxy コンテナの上に jupyter コンテナを立てて、そこでツールが実行されるようにしたかった（出来なかった）。
  • 志波さんや石井さんに教えてもらって job_conf.xml の編集をしたが、ジョブの実行すらされなくなったので後で検証する。

石井

• エア参加の丹生さんと、CWLのテストの話をすこし
• Galaxy のツールを docker で動かす方法
• STARを動かすときに気をつけたいこと - Qiita

那須野

• (途中離脱)

池田

• nextflowを利用してdeepvariant を動作させてみた
  • testの実行を行っただけだけどhttps://qiita.com/percipere/private/977fe6e38c2cf0cc85a7
• Local toolshedを起動しようとしてみた
  • docker コンテナを利用して単純に./run_tool_shed.sh では動作しない
  • tool_hedの定義ファイルをコピー
    • cp config/tool_shed.yml.sample config/tool_shed.yml
    • config/tool_shed.yml の　http: 127.0.0.1:9009 をhttp: :9009に変更
  • galaxyの起動
    • /usr/bin/startup &
  • tool_shedの起動
    • ./run_toolshed.sh &

薬師寺

• STARを動かすのに必要なメモリ数について勉強した。
• 自前のlaptopでできる解析内容、またサーバーに繋いで解析すべき内容についても勉強した。目的とデータの種類に応じて使い分けるようにしたい。
• 職場に導入されるGalaxyサーバーの運用をできるだけ頑張っていきたいです。ど素人にどこまでできるか…。

丹生 (エア参加)

• LSP の publishDiagnostics 実装の前哨戦として、ValidationException と戦うための武器を用意した
  • マージされたので、残り14個分のテストケースを用意する
• 「環境によっていい感じに出力が変わる」ような処理は基本的には書いてはならない！
  • e.g., ** や == で文字列を装飾するとか、いい感じにスペースを入れて行頭を揃えるとか
  • CI で実行されるまでテストすべき状況 (比較すべき文字列など) がわからなくなるため、実質的に事前テスト不可能になる
    • 今回の場合:
      • テスト対象のファイル名が装飾などに影響を与える
      • CI ではファイル名のフルパスなどは制御不可能
      • -> CI 上でテストが実行されないと、どんな文字列が生成されるかわからない…
  • 宗教上の理由でどうしてもそのような処理を書かなければならない場合には:
    • 関数などで完全に切り分けて個別にテストができるような形にしておくべき！！！！
    • パラメータの自動調整系のテストと、パラメータが決まった時に「いい感じになる」テストの二種類を書けるようにしておくべき！！！！！
      • e.g., 「ファイル名が hoge.txt の場合には、num_aster は 4 に調整される」(パラメータは一意に決まるようにする)
      • e.g., 「num_aster = 4 の時にはこの文字列が生成される」(生成される文字列は一意に決まるようにする)
• Go や Rust に負けずに D を流行らせる