コラム

CTC教育サービス・ホーム　＞　コラム　＞　Ruby ＆ Rails　＞　第8回　とちぎRuby会議05に参加しました

Ruby ＆ Rails

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第8回　とちぎRuby会議05に参加しました (松永紘) 2013年10月

　今回は9/21（土）に行われた「とちぎRuby会議05」について、イベントリポートをお送りします。会場は那須塩原駅から5分ほど歩いたところにある東那須野公民館。のどかな風景が広がる場所で、「formal and casual」をテーマに開催されました。

招待講演「厳密な仕様を書くということ」

「仕様」。エンジニアであれば誰しも聞いたことがある言葉だと思います。「それは仕様です」という表現に代表されるように、ある種のネガティブな常套句をイメージされる方もいるかもしれません。
　酒匂さんは講演の冒頭で、仕様とは「課題（解決したいこと）」と「設計（その解き方）」を繋ぐものであると定義します。仕様が曖昧であるということは設計を見たときになぜそれでいいのか、その設計でなぜ課題が解決できるのかを説明できない。逆に厳密な仕様であることで、早期の検証が可能であったり、仕様段階のテストケースを実装のテストに流用できたりと様々なメリットがあるとお話されました。
　個人的な解釈が入っているかもしれませんが「厳密な仕様」とは、仕様（或いは仕様書）の中から「曖昧な部分を無くすこと」なのかなと感じています。その中には日本語の曖昧な表現（受け手によって解釈が変わる表現）を排除することも含まれているのだと思いました。

　講演の中盤からは厳密な仕様を作成するツールとして、形式仕様記述言語「VDM（*1）」のご紹介をされました。VDMを用いることで曖昧な表現を排除したり、VDMからソースコードやドキュメントが自動生成できたりと使いこなせば強力なツールとなりそうです。

　講演の後には質疑応答の時間が設けられました。いくつかの質問が出た中で特に印象に残っているものを一つご紹介します。
Q. 仕様を厳密にしすぎると仕様変更があった場合に大変なのでは。
A. 仕様を図として管理しているからではないか。図は説明のために使えばよく、仕様としては図に相当するセマンティックな定義を持つべきである。
　形式仕様記述言語を用いて検証可能な状態にすることで、仕様変更に対応できる。

一般講演

　1人10分のLT風な発表が行われました。

＜casualにRubyをパースしてみたい：早川さん（*2）＞

「思いやりプログラミング」から「自然言語の凄さ」、ひいては「無名の質を追い求めるプログラミング言語」のお話へと展開されました。
　正直、発表内容に終始圧倒されっぱなしで深いところまでついていけなかったのですが、何かを作る道具としてではないプログラミング言語の在り方もあるのかなあと考えさせられました。

＜パーフェクトRubyのつくり方：三村さん＞

「パーフェクトRuby（*3）」の宣伝ということで、おすすめポイントや実はパーフェクトではないところをお話しされました。おすすめポイントとしては「Ruby2.0に対応している点」や「他の書籍ではあまりみないコラムが充実している点」など、パーフェクトではないところとしては「テストに関する記述がない点」だそうです。
　発表の後半ではご自身の体験を基に、Rubyの学び方のコツとして「情報を得ること」、「コードを読むこと」、「実際に手を動かすこと」を重視したとお話しされました。

＜クックパッドの品質活動：高井さん＞

　クックパッド社のなかで品質に関する取り組みをされているという高井さん。クックパッドの品質目標は「毎日の料理を楽しみにすること」であり、作ったプロダクトが品質目標を満たしているかどうかはリリース後にしか分からない。リリース後の妥当性確認をいかに早く行うかが重要であるとお話しされました。
　その後は参加型セッションということで、「妥当性確認を早く回すためにテスト工程をなくしたい。そのためにはどうすればよいか」という質問を聴講者にされたのですが、残念ながらいいところで時間切れに。また機会があれば、是非聞きたいセッションでした。

＜Ruby2.1のすべて：笹田さん（*4）＞

　今年のクリスマス（2013/12/25）にリリースされるというRuby2.1のお話をされました。Ruby2.1は、2.0を使用している人にはちょっと便利になるくらいのバージョンアップだそうです。個人的には" r "や" i "、" f "のサフィックス追加はインパクトが強めな感じです。あと、Refinementsが正式な機能として取り込まれるみたいです。

＜モックアップとプロトタイプ：後藤さん＞

　モックアップとプロトタイプの違いから、それらを実際のプロジェクトで活用した際の失敗談へと展開されました。仕様や設計を詰める段階で活用したモックアップやプロトタイプを、そのまま製品に組み込もうとすると失敗するというのはかなり共感できるところ。設計や製造など各ステージにおいて、作る側と使う側、その他利害関係者が目的や成果物の意味をしっかりと共有することが大切であると感じさせられました。

＜カジュアルにテストして、フォーマルに検証する：福井さん（*5）＞

　最近よく耳にする「DevOps」という言葉ですが、福井さんは開発と運用の間に正しさを検証する（Verification）フェーズをいれた「DevVerOps」を流行らせたいとお話しされました。その後、検証自動化を行う「Turnip」を紹介されています。
　個々のクラスやメソッドをテストすることももちろん必要ですが、全体の品質を担保するという意味でエンドツーエンド検証の重要さを考えさせられました。

＜「～性」について考える：和田さん＞

　発表の冒頭で、シンプル（Simple）と簡単（Easy）という似たような言葉の違いをご説明されました。Simpleとはもともと「何かひとつのもの」という意味を語源に持つそうで、その視点は客観的である。対してEasyとは「すぐ近くにある、手元にある」という相対的で主観的な視点であり何かを作る上ではシンプルであることが重要だとお話されました。
　自分はこう使うはずだと思って作ったものでも、その使われ方は多様。シンプルに作って簡単さ（≒使い方）はユーザに委ねる方がいいというお話は、非常に考えさせられるものがありました。

Scratch

　講演内容ともRubyとも関係ないですが、講演時のタイマースクリプトに使われたScratch（*6）という言語が興味深かったのでご紹介しておきます。

　上のキャプチャーは"Pico"と呼ばれるキャラクターを歩かせているところです。表示される絵（コスチューム）を切り替えることで歩いているように見えますし、端までいくと反転して逆方向に折り返します。
　直観的でわかりやすい教育向けの言語ではありますが、並列処理などの高度なこともできるみたいです。インストール不要なWebアプリケーションとして提供されているところも気軽に試せるポイントかなと思います。

まとめ

　ご紹介した以外にもいつものtoRuby勉強会や懇親会など盛りだくさんの内容でした。Ruby以外のことに関する発表が多かったのも新鮮だったなあと思います。
　ここに記載していること以上に深い濃い内容でしたが、筆者の理解力や表現力が追い付いていない部分もあり全てを書けていません。見つけられたものに関しては注釈で発表スライドのURLを載せていますので是非ご覧ください。

　それでは、Enjoy Ruby!