(Others) 電脳 Ruby プロジェクト・製品の問題点

電脳 Ruby プロジェクト・製品の問題点を集積しています. 問題に感じた点, それに対する改善提案がありましたらご自由に記入ください.

記入にあたっての注意

後から開発者が詳細を問い合わせられるよう、発言末尾には自分の名前あるいは参考資料を記入してください (発言者の書かれていない議題案は, ページ末尾の参考資料をまとめたものです).

その他

作成時点では, 2012/03/04 の電脳ミーティングに先立つ, 議題の事前共有や簡単なブレインストーミング、議論の場としての利用を想定しています.

ただし, それ以降も問題点の集積所 (いわゆる目安箱) として運用できるような構造にしています.

納多案 (2012/02/13 作成)

注:「Live DVD 作成期限」は 2012/03/06 に九州大学で行われる「3/6 dcmodel/davis hands-on チュートリアル実習」で教材に用いられる Live USB メモリ/DVD のことを指します.

• Live DVD 作成期限まで
  • チュートリアル実習の資料作成、進め方を優先的に議論する
• Live DVD 作成期限からミーティング当日 (2012/03/04) まで
  • チュートリアル実習以外のことを事前討論する
• ミーティング当日
  • 今後の方針の決定など, 直接会話が必要なものに集中する

チュートリアル実習 (Live DVD 締め切りまで優先的に議論)

• 問題点
  • 専用の実習資料がない (?)
    • 電脳 Ruby のページはあるが, 講師があちこちサイトを渡り歩いたら, もう覚えられない
      • 参加者は慌てて URL を書き留めなくてはならない
    • 参加者は講師の真似をして打ち込むだけで精一杯, ストレスフル
      • 講師が何かを説明しても聞いている余裕はない
      • 「Ruby, GPhys は辛いもの」という悪いイメージが植えつけられる
      • 「気軽に止めてください」は機能するとは限らない. とくに学部生には敷居が高い.
    • 資料がないと, 復習も難しい
  • 量が多い (納多)
    • Dennou-Ruby Tutorial をそのままやるのは量が多い. あとあとの可視化に必須な最低限のものだけに選抜すべきで, 残りは自習してもらうようにする
  • 最初の Ruby の演習の段階でつまづくこともある
    • Fortran77 で育った人にはいきなりメソッド, クラス, モジュールの区別はつかない. 混乱のもと. 知らなくてもお絵かきはできる.
    • そもそもなぜ Ruby なのか (.or.でなければならないのか) をもっと強調できればよいかも (辻野).
  • 実習が NetCDF 形式のデータメインで話が進む (辻野).
    • 最初の方に少し他のデータフォーマットの話が出てくる程度.
    • 研究対象や手法によっては, 他のデータフォーマットをメインにしている人も多いと思われるので, 他のデータフォーマットでも同じことができますよということをもっと大々的に主張した方が...
• 改善提案
  • 電子資料 (必要に応じて紙も) を事前に配布し, その通りに進める.
    • 資料に書いてあるコマンドをコピーペーストできるようにすれば, タイピングが苦手な人でもついて行ける.
    • あちこちサイトを渡り歩く場合は, 資料に URL を書いておく. 実習本番でも, 資料に書いてある旨を伝える.
  • 一番最初にゴール (どういう絵を描くか) を見せてモチベーションを上げてもらう
    • ゴールが想像できれば, 後で多少難しくなっても挫折しにくいはず
  • 次に, とにかく門前の小僧として一番簡単な描画をやってもらい, 自信をつけてもらう.
    • GPhys チュートリアル内にある, irb で 2 行打ち込めば可視化できる例
  • Ruby の実習はその後. 量が多いので部分的な抜粋で十分.
    • Dennou-Ruby Tutorial は詳しいので, それを見て後で自習してもらえばいい
  • GPhys, RubyDCL のご利益を体感して, 習得したいと思ってもらうようなデモを中心に構成する (納多)
    • 学部生としては, 世界地図の上にカラートーンとコンターが乗った図がさくっと描けると「すごい!」と思ったりしないだろうか
  • 実習の動画も撮る (納多)
    • 「作業しているところを取っても意味がない」と否定的な意見もあるが, 講師が説明・デモをしているところだけを切り取ってつなげれば立派な入門動画になる.
      • 念頭にあるもの: 地球流体セミナー作業風景
      • 検索などで電脳 Ruby のサイトにやってきた人にはこれを見てもらえば, 百聞は一見に如かずで, 多少は敷居が低くなると思われる.
    • この場合, 撮影者は実習に充分参加できるか? (辻野)
      • カメラを動かさないで撮ってみるのはどうか. 撮影者は最初と最後に操作するだけでよい (納多)
  • 実習の進め方として, 先生と助手という 2 人構成で進める. (辻野)
    • 助手のパソコンをスクリーンに映し, 先生がここはこうですという風にスクリーンを差しながら解説. 助手は言われたとおりにコマンドを実行し, 聴衆は助手と同じようにコマンドを入力. などという掛け合い形式の方がよいのでは?
      • このとき, 助手として採用するのがどのレベルの人かが重要となる. 全くの素人でもよい (この場合, 実習速度は非常に遅くなるが, その場にいる初心者代表なので, 初心者がついていくにはよいかも).

宣伝

• 他の数値モデルとの連携
  • 他の有名な可視化ツールは, 有名なモデルの可視化に使われている例が充実している
    • モデルとの抱き合わせ. 解析ツールが充実しているからモデルを選ぶ, という選択を行うユーザもいる?
      • そういうユーザはごく稀だと思われる. まずモデルありき. 可視化ツールはその付属品という認識なのでは? (辻野)
      • 大部分のモデルユーザにとって, 可視化は目的のための手段でしかないので, そんなに重きを置いていないはず (辻野).
    • WRF のページに NCL のマニュアル? <URL:http://www.mmm.ucar.edu/wrf/users/graphics/WRF_NCL/NCL.htm>
  • 改善案
    • dcmodel のページに GGraph で可視化したサンプルコードと絵を大量に並べる
    • 電脳 Ruby のページにdcmodel や他のモデルの出力を可視化するサンプルコードと絵を大量に並べる
      • 天文などの他分野のユーザからもサンプルをいただけないか? (納多)
        • 他分野だと, その分野に特化した別の描画ソフトがまた存在するので, そもそも他分野で Ruby-DCL 関連は使用されているのか? (辻野)
        • 天文 (惑星科学) 分野で使っている人を一人知っています (納多)
• ウェブサイトが検索エンジンに優しくない
  • Meta タグの記述やサイトマップファイルの設置を行う
• 縦長のページにページ内リンクを貼る方法は, iOS の Safari では動作しないことがある?
  • 納多が iPod touch で確認した
  • 一般的にそうなのか動作確認例を求む
• デモ動画を作成, 公開する
  • 動画の作成手順は「プレイ動画 作成」などで検索すればたくさん出てくる
  • 動画の作成手順は公開して, ユーザ側からも非公式デモ動画を発信してもらいやすいようにする.
  • 納多に余裕があれば, 納多がミーティングの日の小ネタとして話すかもしれない
  • CPS mosir は公式デモ動画の置き場所として活用させていただけるか? (納多)
    • mosir の杉山さん曰く, セミナー動画以外にユーザが気軽に動画をおける場所の作成を検討中

Web ページの構成

• Backgournd / Goal が白紙なのはまずすぎる
  • メンテナンスされてない印象を与える
  • 取り急ぎ, 学会発表資料などから抜き出して作るべき
• 日本語ページがない
  • GPhys など
  • 日本語ユーザによって開発されたソフトウェアのメリットである「日本語ドキュメントがある」がない
• 謹製品 ページは製品が並列に並んでいて, それぞれの位置づけが分かりにくい. しかも英語なので敷居が高い
  • 「何がしたい人は何を使うべきか」が書かれていないので, 一見さんはどれを使えばいいか分からない
    • 例えば, 初心者にお薦めの製品は何か?
  • 電脳 Ruby 的には RubyDCL と GPhys を前面に押し出す (具体的には, ページ上部に置いて字を大きくするなど) べきではないか
  • GGraph の下請けが RubyDCL であることももっと明示したほうがいい
    • 使いはじめの頃にこれを知らず, RubyDCL に降りればすぐ解決するような場合も "GGraph" ばかりで検索して時間を浪費したことがある (納多)
• トップページからすぐたどれる場所に, 他のツールにない特徴を主張したほうがいい
  • おまかせ可視化で変数タイトルや軸名が表示される, など
    • この機能は NetCDF の機能ではないか? (辻野)
    • もしそうだとすると, NetCDF に対応しているほとんどの可視化ツールと同じ. (辻野)
  • gave のような GUI ベースのツールが存在することは結構, 他のツールよりアドバンテージとなっているのでは... (辻野)
• 電脳 Ruby 製品で何ができるのか, 一見しただけではわかりにくい
  • 一見さんがまず知りたいのは「このツールで何が出来るか?」「自分の描きたい種類の絵は描けるか?」だろう
  • GMT のように, ページ左のフレームに Examples を作って RubyDCL のデモページに飛べるようにしてはどうか
• 訪問者が迷子にならないような構造が必要 (納多)
  • トップページのフレーム左上からサイトマップ (一見さん向け, 新設ページ) を参照できるようにするだけでも迷子は減らせるのではないか
  • 一人行うのは無理なので複数人が更新しやすい仕組み (Wiki?) が必要
  • これに加えて一度 HP を整理した方がよいかも (辻野).
    • 賛成. コンテンツの再配置に加え, ページに統一感を持たせた方が良い (納多)
• 開発への参入の手引き, のようなページがあると敷居が低くなるかもしれない (納多)
  • おそらく, Goal がないのもあいまって, 電脳 Ruby がどういう組織なのか見えにくい
  • 「あなたの参加をお待ちしています」だと人によって受け取り方が違うので,
    • GPhys の場合だと, 「コアの部分は堀之内さんの独断, それ以外の部分は比較的自由にコミットしてよい」とのこと. こういう情報が示されていると嬉しい.

インストール

• 現在, ライセンス問題に対処中なので, 新たに議論することはない?
• こんな話があった
  • 自分が管理者でないマシン (スパコン) に入れようとして 丸一日格闘して挫折した学生 (台湾大の伊藤さん談)
  • ソースからのインストールももっと容易にできるといい
    • Ruby製品についてはやはり gem を用意するのがよいのでは? 西本さんがやりかけてくれてたような. もう一息? (神代)
      • narray_miss, ruby-netcdf, ruby-dcl については gem を作成しています。ただ、ruby-dcl は DCL-C に依存しているので、DCL-C をパッケージに組み込めたらもっと敷居が下るのになあ。GPhys の gem は作成してみます。（西本）
    • そもそも Ruby がインストールされていない非管理者マシンではどうするか? (辻野)
      • 管理者に頼む, しかないですかねえ. 最近はたいてい入ってることが多いでしょうか. (神代)
    • 製品そのものの数を減らすことを考えてもいいのでは. たとえば, numru-misc, numru-units, met あたりは GPhys に含めてしまうとか. dcl-C を ruby-dcl に含めるとかもアリ? (神代)

ドキュメント・サンプル

• GPhys には「ごくらく」「らくらく」に相当するドキュメントがない
  • 不完全でよいので, 「逆引き」(機能からメソッド, オプションを探せる) できるドキュメントを作成する
    • 「○○するにはどうしたらいいか」が探せずに挫折するケースもあると思われる
  • 開発者に余裕がないなら, Wiki などにしてボランティアが参入しやすい仕組みを作ってはどうか
    • 参考: 逆引きRuby
    • せっかくここに Wiki あるんだし, このページみたいに活用していっては? 小物置き場は小物置き場じゃないとダメ? (神代)
      • もう1つ Wiki 立ち上げるにしても, dennou WWW 本家でやるより, 実験的な位置付けの davis サーバ(ココ)でやったほうがいろいろとやりやすいと思う. (神代)
      • 「小物置き場」という名前が良くないと思います. 一見さんがその名前からドキュメントが置いてあると想像できるかが心配です. ナビゲーションを工夫すれば問題ないかもしれませんが. (納多)
      • (Document) カテゴリが欲しい (納多)
    • tips をためていくだけなら良いが, 「ごくらく」「らくらく」レベルのドキュメントを複数人で 作っていく場合はバラバラになったり重複が出たりしないように調整が必要. (納多)
  • 納多が GPhys/GGraph チートシート (非公式) を作ってみた
• GPhys チュートリアルページ
  • 内容的にマニュアルとチュートリアルが混ざっているので, チュートリアルらしくない
    • 説明はいいのでとにかく早く手を動かすようにしたほうがよい
    • 詳しい説明はマニュアルに移動したほうがよい
  • 「最速描画」が最速らしくない
    • 「最低 7 行も入力しないと動かないのか」という悪印象を与える
      • gnuplot の "plot x" に大きく見劣りがする
    • 行番号は不要. コピーペーストですぐ動かせるようにして, 早くメリットを実感してもらう
    • チュートリアル序盤の改善提案

      • 以下のように, 最初に irb 使う方法から始めてはどうか?

        1. サンプルの .irbrc をダウンロード, 設置 (チュートリアル実習では最初から設置しておく. 「最初だけ行うおまじない」とだけ説明.)
        2. irb 起動
        3. 以下のニ行を打ち込むと絵が表示される. おわり.

        gphys = GPhys::IO.open('T.jan.nc', 'T')
        GGraph.tone( gphys )

      • irb を使う方法は, 一行一行確認して実行できるのでデバッグに不慣れな初心者には敷居が低い
        • 初心者に長いコードを打ち込ませると, 高い確率で typo するので失敗する. 一番簡単なはずの例で嵌ると, 難しいという印象を抱いてしまうので良くない.
• 具体的サンプルが少ない
  • 初心者は最初, サンプルコードの改変やサンプルからのコピペで学ぶことも多いはず. コードと図のセットだけでもいいので, 何かしら動くコードを並べておいたほうがよい. 検索に引っかかってユーザが助かることもある.
• チュートリアル実習で学部や修士に単位が出るようにし, レポート代わりに小物置き場にサンプルを置いてもらうのはどうか (納多)
  • いたずらにアカウントを増やすとセキュリティ的によくない?
• 良い資源があっても閲覧性が悪くて探しにくいことがある (納多)
  • 重み付き平均の例が「高速化」のページにある
  • irb での history 機能のソースが「補間，座標変換」のページにある
    • history 機能については、GPhysチュートリアル、スタートアップファイルの利用に詳しい記述があります。でも、資料が分散して置いてあるのが問題ですね。（西本）
• 開発者や上級者が SNS や小物置き場で, 具体的なコードやログ、つまづいた点と解決法 (整理されてなくてもいい) を流してほしい.
  • 具体的に動くコードは中級者のヒントになる
  • 置いた本人以外がまとめてくれる可能性もある
  • 検索にも引っかかる

GPhys の使い勝手

• 普段よく行われる操作で長いものがある. 標準のメソッド化しておくべき
  • たとえば「チュートリアル」にある「非GPhysデータの書出し -- GPhysオブジェクトを一から作る」は本当は一つのメソッドとしてまとめるべき
  • コードが長くなると, 他のツール (gnuplot など) 流れがち
    • 初心者は GPhys や Ruby にどういうメソッドがあるか, どんな機能があるかを熟知しているわけではないので, すぐに書ける気がしない
    • テキストデータを折れ線グラフに表示する例 (納多が書いた場合)
      • gnuplot: 1 行 (plot "hoge.dat" with lines)
      • GPhys/GGraph: 14 行 (テキストデータ読み込み, GPhys オブジェクトの作成, 折れ線グラフの表示)
  • 「自作メソッドを作れば良い」という批判はあるだろうが, 各ユーザにそれをさせる理由が分からない
  • 納多が関数やテキストデータを gphys に一発変換するメソッドを作ってみた
    • (Library) GPhys オブジェクト作成支援ユーティリティ
  • とりあえず, gnuplot のように, テキストデータを折れ線で描画するスクリプトは作成 (辻野; dclplot).
    • ただし, Gphys の機能は一切使っていない純正 Ruby-DCL 仕様.
• irb は history 機能に乏しく, 「今描けた絵を描くスクリプトが欲しい」というときに不便
  • 一応 <URL:http://ruby.gfd-dennou.org/products/gphys/Recipes/recipes_j/irbrc_ggraph.rb> はある.
  • gnuplot の save のように, 履歴を一発でダンプする機能が欲しい
    • 納多が試作中
• gnuplot のような interactive help があると嬉しい
  • リファレンスマニュアルを抜き出せばそれらしいものができないか?

Ruby の小物置き場

• タイムアウト時間が短い (納多)
  • 1 時間くらい?
  • 長文を編集していてタイムアウトになるとやる気がなくなる
  • 提案: 24 時間くらいに長くするか, 投稿前にバックアップをとることを促す注意書きを書いておく (できれば保存ボタンの上に)

ML

• ML は敷居が高い
  • チュートリアル実習で学部や修士に単位が出るようにし, レポート代わりに ML に疑問点を投げてもらうのはどうか (納多)
    • その後の質問の敷居も低くなる?
    • 開発側が, 初心者がよくつまづく場所を収集できる
  • Twitter など SNS の活用

Ruby 環境

• Ruby 環境支援 (便利そうなものを tips 的に紹介)
  • Ruby のマニュアル
    • yhara/myrurema - GitHub
    • EmacsWiki: anything-rurima.el
  • emacs Ruby Flymake
    • 書いている傍から文法違反を指摘してくれる
• irb より pry のほうが高機能なのでよいのでは? (納多)
  • gem install pry で入る
• Ruby, NArray のチートシートがあると嬉しい (納多)
  • NArray.to_na などよく使うもの
  • self.class などデバッグ時によく使うもの
  • メソッド一覧の表示方法

開発

• Fortran なので開発者視点ではもう古い?
  • Ruby科学データ処理ツールの開発 NArrayとPwrake 61 ページ参照
• 開発者の顔, プロジェクトの進む方向が見えない (納多)
  • web ページに「ゴール」がないので, 自分の貢献したい方向とプロジェクトの進みたい方向が一致しているか分からず, 開発に参入しにくい
• 「小物置き場」の資源は本家にマージしていく, あるいは本家へのコミットを受け付けるべきでは? (納多)
  • よく使われるであろう, 便利な小物は本家に取り込んで充実させていくべき
  • 主要開発者が忙しいのであれば, 貢献者が自分でコミットできるように開発者用ドキュメントを用意すべき
• 将来的には trac のような プロジェクト管理ソフトウェアを使うことも視野に入れるとよいかもしれない (納多)
  • 優先度は高くない. wiki での管理が破綻しそうになってから考えれば良いだろう.

• ＧＰｈｙｓはなんでブレイクしないのか？ - Togetter
• GPhys はなんでブレイクしないのか? その 2 - Togetter
• Gphysライブラリマニュアル日本語版（非公式） (九大 對馬さん作成)
• ささやかな構想のメモ (同志社大 村上さん作成)