JBUG岡山で「心理的安全性」について学ぶ

2019年10月19日、倉敷のアイネットさんで開催された「JBUG岡山 #4 プロジェクトテーマパーク、心理的安全性ゲームから学びを得よう」に参加してきました。 実はJBUGという勉強会自体は知っていたのですが「Backlog使ってないしなぁ」という理由で参加してませんでした。しかし今回テーマに惹かれて参加してみると「プロジェクト管理」というテーマに沿っていればある程度何をやっても良い会とのこと。ゆるーい感じが良いですね。

心理的安全性ゲーム

安井 力（やっとむ）さんが作った4-5人で遊べるカードゲームです。 カードは大きく分けると「状況カード」と「発言カード」があります。

参加者は順番に「プロジェクトに波風立てる人」となり「状況カード」を出します。その状況カードに対して、他の参加者が「発言カード」を出します。「発言カード」の中には辛辣な事が書かれていることもあり、そのまま出すと明らかに空気が悪くなりそうなものもあります。

そんなときは、一言加えて出すと場の雰囲気が良くなります。

例えば、

状況カード：「クレーム発生！この件誰が担当するの？」

に対して

発言カード：（そもそもこんなのクレームに値しないよね。対応するだけ）「ムダだね」

みたいに前半を付け足すと否定から同調にがらりと変わります。もちろん、実際の仕事の現場だとそれなりに権限がある人が発言しないとムダでしょうけど。

さて、一通り発言カードを出し終えたら、状況カードを出した人はその時の気持ちを話します。

「この言葉はキツかった。でも、他の人が同調してくれたので頑張れそう」みたいな感じです。

その後、ボード上にこのチームは将来どうなっていくのかを考えながら石を置きます。参加者全員が石を置き終わったらゲーム終了です。ボードにはチームの将来図が描かれているはずです^ ^

なお、上の例では発言カードに言葉を付け加えて出していますが、付け加えずそのまま出す縛りを設けるのもアリです。

心理的安全性とは？

このイベントに参加するまでは「言い出しにくい事柄を用意に言える雰囲気を作っていく事が心理的安全性だ」というふんわりとした考えがありました。しかし心理的に安全で安らかな状態は「刺し身にタンポポを乗せる仕事」のように学習が無い状態です。人の仕事を手伝ったり知らないことを調べていく行為が学習へと繋がっていくことを今回の勉強会で学習することができました。自発的に心理的安全性を作り出せるようになるまでこのゲームで理解を深めていくのも面白いなと感じました。

参考リンク： games.yattom.jp

仕事をする上で普段考えていること

はじめに

今の会社に転職してはや8年。Ruby on Railsのプログラマーからスタートしたキャリアだけど、1年半前から前任者の引き継ぎというカタチで管理職をやってる。管理職と言っても100%マネージメントに振っているわけではなく、コードも書くしインフラ構築もするような状況。チームメンバーも増えマネージメントについて意識する機会も増えてきた。世の中の流れ的にも「エンジニアリングマネージャ」にフォーカスする書籍やイベントも増えてきて、私と似たようなキャリアを歩み疑問にぶち当たっているのかなという印象を受ける。最近マネージメントについて意識して仕事する機会も増えてきた。 そんな中で普段から仕事について意識してることについて語ってみる。

自分にしかできないと思っている仕事こそ移譲する

「この仕事は私にしか分からない」そう思っていた時期が私にもありました。実は私にしか分からない訳ではなく、他人に教えるのが面倒なだけだったりした。 手順書を一通り揃えれば自分が思っていたより遥かに楽に仕事を移譲できることが分かった。ついでに私より効率の良いやり方でやってくれる事があることも分かった。

ストレス無く仕事する方法

何がストレスかって言うと長期的な段取りが必要なタスクをぼんやりと考えているとき。あのプロジェクトを進めるにはあの人と打ち合わせして、この資料を作成して... ああ、でもあっちの締切のほうが優先度高いからこの資料を先に作って...なんて考えるのが一番ストレス。無駄に時間が過ぎていく。しかも、家族との団らんやクルマの中でリラックスしてるときに急に思い出してイライラしてしまう。 これを解消するためにGTDという手法を随分前から取り入れている。タスクを実行可能な領域(「Excelシートを開く」・「PDFを読む」など)まで細分化して記録、それを日々振り返りながら実行するべきタスクをその場で決めている。リラックス中にふと長期タスクを思い出しても「ああ、これはとりあえず月曜日に資料読むところから始めればいいや」って思える。 随分長い間 Doit.imというサービスを使ってたんだけど、数年前からメンテナンスされなくなってしまい、現在は Trelloを使ってカンバンで管理している。間違えないでほしいのがGTDは「タスクを効率的に処理する」方法では無く「タスクをストレス無く処理する」方法なので、頭の良い人やストレス耐性高い人はもっと別の効率的な手段があると思う。興味のある人は全面改訂版 はじめてのGTD ストレスフリーの整理術を読んでみてほしい。

TrelloによるGTD。パニガーレのリアタイヤが見えてればまぁまぁタスクはこなせてる

コミュニケーションツールの特徴をよく理解する

Chatwork・Teamsなどのチャットツール、Redmine・GithubのIssueなどのタスク管理ツール、メール、電話(ボイスチャット、TV会議)など会社では様々なツールを使ってコミュニケーションを取っている。それぞれ特徴があり相手や情報の内容によって使い分けるべきだと思ってる。

• チャットツール(Chatwork、Teams)
  • 非同期のコミュニケーションで良い場合に選択。タスクを決定するまでに感情を挟まない論理的な会話ができる場合、つまりはほとんどはこれでOKだと思う。表情が伝わらないので顔文字や口調はとても重要。
• Redmine
  • 詳細に記載されたタスクの内容、ボールが誰にあるのかを認識するときに必要。初めの頃は他人にタスクを割り当てるのが苦手な人が多いけど「だれのボールか明確にすることが重要なので容赦なく私にアサインしちゃってください！」と他部署の人には説明している。
• メール
  • WebサービスからのNotificationとしか機能しなくなった感じがあるメールだけど、相変わらず社内外問わず使われている。可能であればチャットツールの世界に引きずり込んでるけど、難しい場合もある。せめて相手の事を考えてタイトルは工夫して送るようにしよう。工夫と言っても大したことは無く先に本文を書いてから3行目をコピペするだけ。簡単でしょ？

    

    メールのタイトルは本文からコピペする

• 電話(ボイスチャット、TV会議含む)
  • 利点が2つある。
    • 一つは相手の声色を伺うことができるし、こちらの感情を伝えやすいから。障害発生時はもとより頼みづらいと自分が感じているタスクを遠隔地の人にお願いするときは大抵電話を添えている。仕事は相手の気持ちになって考えることが重要。声から相手の気持ちを感じ取ってほしい。
    • もう一つは相手の出方によって条件が複数分岐する内容を話し合うとき。if,then,elseぐらいで処理できる2パターンならRedmineのIssueで議論するのも良いが、予めif文が3つ以上登場することが想定される場合は電話のほうが手っ取り早いし効率的である。
  • ただし、声での会話は後に残すことができない。会話の後にはチャットやRedmineなどで「さっきの電話で話したことを共有します」と内容を共有するようにしょう。

20代の若い人に伝えたいこと

• いまはがむしゃらにタスクをこなしていけば良い
  • 仕事の内容を考えるのは上司の仕事。与えられた仕事をそのままこなしてくれれば良い。もちろん自分に合う仕事、合わない仕事はあると思うので、ちゃんと上司に伝えよう。一番良くないのが不満の矛先が社外に向いてしまうことだと思ってる。そうならないようにコミュニケーションの場は提供しているし、その場を大切にしてほしい。
• 分からない事はちゃんと調べよう
  • 求められた結果を出すことに注力しすぎて、その過程を疎かにすると後々苦労することも。プログラミング中に詰まってQiitaに書かれている別のやり方で回避するのも時には良いだろう。しかし、自分が本来やりたかったやり方ではなぜダメだったのか。本来どう処理するのが正解だったのかを追い求めてほしい。
• 会社でやるべきことの線引
  • 業務時間中に本を読んで学習するのも、新しいWebサービスを試すのも良いと思う。その際に一つ気にかけてほしいことがある。それは「今やっていることが会社のためになっているか？」 という点。別に利益を上げることを最優先で考えろと言っているわけではないが、我々は価値あるサービスをお客さんに提供し、お客さんはその価値をお金として会社に支払ってくれている。私達の給料は会社から出ているわけではなくお客さんのお金だということを考えなければいけない。なので、「今何やってるの？」と聞かれたときに「会社の価値をこういう方向で高めてます！」って胸を張って言えるように準備しておいてほしい。その言葉さえあれば大抵の上司はOKするんじゃないかな。

JAWS-UG Okayama 2019 × SORACOM-UG Okayama vol.1に参加してきた

倉敷物語館で8/17に開催された「JAWS-UG Okayama 2019 × SORACOM-UG Okayama vol.1」に参加してきました。 午前中はAWSの技術をテーマにした勉強会JAWS-UGで、午後からはSORACOM LTE-Mボタンを使ったハンズオンという感じでした。

JAWS-UG Okayama 2019

今回から「第n回」ではなくタイトルに年が入るようになりました。年次イベントに格上げです（違）。 印象的だったお話をいくつか。

AWS での機械学習

AWSジャパンの藤原さんから、AWSで利用することができる機械学習関連のソリューションを紹介していただきました。

Amazon Rekognitionを使えば、顔認識や有名人の認識、アダルトコンテンツの認識など画像解析ができるそうです。動画にも対応しているのが素晴らしい。

また利用者自身の機械学習の理解を深める仕組み作りもAWS DeepLensやAWS DeepRacer取り揃えているところがすごいですね。

私は偶然にも前日にSoftware Design9月号の「ひとりで始めるPythonプログラミング入門」を読んでいたので、「Jupyter Notebook使ってる人？」という質問に胸を張って手を上げることができましたよ！（理解しているとは言ってない）

機械学習をバリバリ使いこなすつもりは無いですが、作業の流れや用語は仕事をする上でも抑えておく必要があるなぁと最近感じています。

ECSとSQSでスケーラブルなバッチを作った

ツイートがアッコにおまかせ!で取り上げられたことで有名な、クラスメソッドの吉田タカさんの発表。

お客さんの情報を安全に扱うために、客先アカウントでIAMを作るのではなくRoleを作って、自社アカウントからSwitch Role（って理解で合ってるかな？）したり、AWS SSMを使って機密情報を安全に格納したり、クラメソ内の安全性を確立する手順がよく分かる良い発表でした。

また、SQSを使った大量データの処理についても、Dead letter Queを正しく使うことで不正なデータを正しく扱うことができることを学べました。

AWS DMSを利用した今風DBリファクタリング

オミカレの高橋さんからRDSのMySQLからPostgreSQLへDMSを使ってデータを移行している話を聞かせていただきました。

ざっくり書くと、

DBのリファクタリングをトリガーを用いてやりたい。ただSQLでトリガー処理は書きたくないのでJavaScriptが使えるPostgreSQLが使いたい。だからMySQLからPostgreSQLにDMSを利用してリアルタイムにデータを移行している。

という内容でした。IT系勉強会では新しいものを作る発表はよく聞くのですが、実業務の世界では既存システムを新しい仕組みにじっくりゆっくり合わせていく作業が必要不可欠です。中国地方DB勉強会ではこういったお話がたくさん聞けるので好きなのですが、JAWS-UG参加メンバーの心にもきっと響いたと思います。

まだまだ完全移行まで闘いは続くようですが、頑張って欲しいです！応援してます。

Jets ~Rubyで始めるServerless生活~

ソニックガーデンの遠藤さんからRuby on RailsライクなサーバーレスフレームワークJetsのご紹介でした。 ご本人様は「発表とか苦手でして...」って言われていましたが、Jets愛を感じる熱い発表でした！

AWSでサーバーレスでWebサービスを作ろうと思うと次のようなツラミがあります。

• リクエストごとにLambdaのプログラムをアップロードしないとだめだよね。
• リクエストごとにAPI Gatewayの設定も必要だよね。

Jetsを使えば、ローカルではまるでRuby on RailsのようなRubyコードを書くだけで、デプロイ時に自動でLambdaへのプログラムの設置、API Gatewayの設定を行ってくれるそうです。また、静的なファイルはs3に置いて、HTMLからは自動でそちらを見に行くように設定もしてくれるとのこと。まさに神！

あと、CloudWatchを使ってcronライクな動作を設定できたりAWS上の様々なサービスと連携できる点が素晴らしいですね。しかも、めんどくさいYAMLやらJSONを書かなくてよいのがなお良いです。

私も近いうちにJetsを試してみようと思います。

SORACOM-UG Okayama vol.1

株式会社ソラコム テクノロジー・エバンジェリストの松下さんからソラコムのサービスの説明とLTE-Mボタンを利用したハンズオンがありました。 通常の携帯電話の通信では

• 端末→インターネット→AWS

ですが、ソラコムの場合は

• 端末→AWS→インターネット

というようにダイレクトコネクトを利用して直にAWS内に接続しているそうです。こうすることで、セキュアな通信でもhttpsという重いプロトコルを使うことなく、少ない通信量（バッテリーの持ちも良くなる）で送信できるというわけです。

他にもIoTソリューションを構築する上で必要な様々な仕組みを提供されていました。懇親会では松下さんからLTE通信の興味深いお話が聞けてとても楽しかったです。

さて「LTE-Mボタン」ですが、先に発売されている「AWS IoT エンタープライズボタン」の通信がLTEになったようなデバイスです。AWSからはIoT エンタープライズボタンと同等に扱われます。

面白いのがAWS IoT 1-Clickからはデバイスがどこの プレイス にあるか設定できるという点です。IoT エンタープライズボタンはWiFi接続しかできないので「台所」とか「リビング」とか設定するのでしょうが、「LTE-Mボタン」は電波が入ればどこでも使えます！プレイス＝地球と言っても過言ではありません。

LTE-MボタンでLambda経由でメール送信してるところ

こんな感じでボタンを押すことでlambda経由でメールを送ったり、IFTTT経由でLINEしたり楽しく実験することができました。

「ボタンを押すことしかできない」というのは多様性が無く、一見不便なようにも思えますが、アイデア次第でシンプルに問題を解決することができる面白い仕組みだということが分かりました。

MacBook Pro 2019のThunderbolt 3ポートが2つのモデルはおすすめしない！

先日会社で購入したMacBook Pro 2019の下位モデルがイマイチだったのでご紹介しておきます。

ポート数の違い

左がMacBook Pro (13-inch, 2019, Two Thunderbolt 3 ports)
右がMacBook Pro (13-inch, 2018, Four Thunderbolt 3 Ports)

ハードウェア的な違いは2つ。

一つは名前の通りThunderbolt 3のポート数

MacBook Pro 2019の下位モデルの右側にはThunderbolt 3 ポートは無い

MacBook Pro 2018の右側にはThunderbolt 3 ポートが2つ

この情報はオンラインのアップルストアからも見て取れます。

2019年下位モデルがイマイチな理由

ファンがうるさい

普段Ruby on Railsで開発したりExcelやWordを使って文章書いたりしているのですが、なにか処理をするたびにファンがうなりをあげます。rbenvでRubyのインストールを行ったり bundle install する際にファンがうるさくなるのはしょうがないとして、rails sするだけでファンが高速回転するのはおかしくないですかね？

キーボードが熱い！！

2018年モデルもTouch Bar周辺が熱くなるのですが2019年下位モデルではキーボードの右側がとても熱くなります。キートップはかろうじて触ることができますが、キーの間の本体金属部分はやけどしそうなぐらい熱くなります。

違いは本体下部のスリットの有無

2018年モデル

2019年下位モデル

なんと2019年下位モデルには本体下部にスリットがありません。このせいで排熱が間に合わず本体内部に熱が滞っているのではないですかね？

まとめ

ブログを書いたりWebを見て回るだけならともかく、プログラムのコンパイルや写真現像など重い処理を行う予定がある人は2019年上位モデルをおすすめします。そもそもMacBook Proは「プロ」向けのハズなんですけどねぇ。世の中には私が知らない分野でいろんなプロがいると思いますけど、アップルが想定するプロが分からないです☺️

sakura.io体験ハンズオン@岡山に参加してきた

2017年9月2日、岡山のKLabさんで開催されたsakura.io体験ハンズオンに参加してきました。 ▲利用したキット一式

ハードウェアシロートの私は今回のハンズオンに参加する前にIoTについて次のように考えていました。

• IoTというからにはあらゆるものがInternetに繋がるはず
• 電源が確保できない場合はバッテリーで動作させる必要がある
  • と、なると消費電力の点からRaspberryPiよりArduinoがよいかな？
• ネットワーク接続はワイヤレスLANかLTE
  • でもArduinoで使うC言語でネットワークの制御までできるのかな？

参加してみて感じたのはsakura.ioは一番面倒なネットワークの制御をいい感じに面倒見てくれるソリューションだという事です。

▲温度センサーを接続

右の緑色のカタマリは3層構造になっています。一番下はArduino、一番上はLTE通信モジュール、真ん中はその2つを接続するための「シールド」という基盤です。

ArduinoもArduino IDEも初体験だったのですが、Arduino IDEがとても良くできていて、ネットワーク経由から必要なライブラリを簡単にダウンロードすることができます。おまけにライブラリに付属するサンプルコードを実行するだけで、ある程度動くものができてしまいます。ライブラリの仕事はセンサーを制御することなので、できることが非常に限られているわけです。 今回も温度センサーとsakura.ioのライブラリをダウンロードして付属するサンプルコードを実行するだけで、センサーが取得した値をsakura.ioまで届けることができました。

▲sakura.ioのWeb画面でセンサーが取得した値をJSONで表示しているところ

ここからがsakura.ioの面白いところで取得したデータをどのように利用するか、あらゆる手順が用意されています。今回は特定の企業のWebサービスではなく汎用的に利用できるWebsocketを利用して、現在の温度をツイートするところまで作成しました。

Arduino + さくらLTE
↓
(LTE)
↓
sakura.io(Webサービス)
↓
(Websocket)
↓
さくらクラウドに立てたNode-RED
↓
Twitterでツイート

Node-REDを利用することでWebsocketで受け取ったJSONを加工してTwitterでつぶやくところまでをほぼノンコーディングで実現することができました。

さくらインターネットのハンズオンで温度情報を取得中！ただ今の現地温度は25.8度だよ。やっと正式サービスが始まりました、今後ともよろしくお願いします！ #sakuraio #さくらインターネット

— Yamamoto Kazuhisa (@kazuhisa1976) 2017年9月2日

質疑応答で感じたWeb系とモノづくり系の違い

最後の質疑応答で活発な意見が交わされました。 特にシビアなコンディションで利用された場合の課金、時刻の誤差、通信のリトライ等、Webに関わっている人間からすると、正直細かすぎるのでは？という内容が多かったです。 しかし、どんなサービスでも長期間利用していると想定外の事態が発生するものです。ハードウェアは容易にアップデート出来ないため、事前に様々な事態を想定して利用する必要があるのだと感じました。

まとめ

個人的な印象ですがarduino側ではセンサーから取得した値を投げることに徹して、sakura.ioから先で様々な集計・分析を行うのがうまい使い方かなと感じました。極端なシビアコンディションでの利用を考えなければWeb系エンジニアだけでも一気通貫でIoTを実現できる世界がやってきた！と実感できました。

【バイク】防振素材入りMOTORHEAD メッシュグローブを購入しました

以前から使っていた、コミネのメッシュグローブの代わりとしてMOTORHEAD メッシュグローブを購入しました。 driverstand.com

コミネのグローブは手のひらに振動防止素材があるおかげでロングツーリングでも手が痺れず快適だったのですが、手に汗を書いたり雨で濡れるとインナーメッシュがひっくり返って、手にはめるのにとても苦労するのです!

niwakabike.blog.fc2.com

↑同じ苦労をしている人のブログ

新しいグローブを選ぶにあたり、バイク用品店で色々探したのですが、手のひらに防振素材が入っているタイプってほとんどありませんでした。 そんな中、２りんかんでいい感じのグローブを発見したので購入してみました。

ほら、手のひらにちゃんと防振素材が入っています。 また、インナーメッシュのようなものも存在しないため、ひっくり返る心配も無さそうです。

RubyKaigi2016に参加してきました

2016年9月8日から10日にかけて国立京都国際会館にてRubyKaigi2016が開催されました。地域Ruby会議ではなくThe Ruby Kaigiが関西圏で開催されるのは初めてだと思います。RubyKaigi2015はスケジュールの関係で参加することができませんでしたが、今回は岡山から近いこともあり3日間参加してきました。 印象に残ったセッションについて感想を書いておこうと思います。

1日目

Ruby3 Typing(Yukihiro "Matz" Matsumoto)

基調講演はRubyのパパであるまつもとゆきひろさんから、主にRubyの型についてのお話でした。Javaのようにきっちりと型を指定せずとも型推論等を用いて、ストレス無く静的型付けの恩恵をうけることができる言語が最近増えてきています。それを受けて完全な動的型付けであるRubyが今後どのように進化を遂げようとしているのか、その方向性を示す内容でした。

静的型付けのように何度も型を書くのはDRYではないので、絶対にやりたくない。しかし、動的型付けは実行してみるまでエラーが発生しない。静的型付けのような型チェックもできるけど、動的型付けのような柔軟性もほしい。そのために、実行結果を記録し型データベースのようなものを作ってはどうかとのこと。 確かにこの方法であれば完璧ではないにしろ、静的型付けの恩恵は受けることができそうです。私の想像ですがGemで提供されるライブラリにも型データベースが添付される時代が来るのかもしれません。

「前に進むことについてはなんでもやる」と力強く言われていたのがとても印象的なキーノートでした。

dRuby in the last century.(Masatoshi SEKI)

Rubyの分散オブジェクト技術であるdRubyの歴史についてのお話でした。個人的にはRails開発でかつて利用していたSporkで使われていた技術という認識でしかありませんでしたが、分かりやすいデモを交えた発表内容でよく理解できました。前職では.NET リモーティングを使ったプログラム開発を行っていたのですが、dRubyはそのRuby版という印象を受けました。10年ほど前は「ネットワーク経由で遠隔地のオブジェクトをオブジェクトのまま扱いたい」っていう需要もしくはブームがあったのかな？ 遠隔でRubyを操作というとAPIサーバー立てて、httpで操作させるかな...という発想になりがちですが、改めてdRubyの利便性を感じることができました。

Unifying Fixnum and Bignum into Integer(Tanaka Akira)

Ruby2.4系からFixnumとBignumがIntegerに統合されることについての説明でした。

（手元のRuby2.3.1と2.4.0devで検証した結果）

# v2.3.1
p 1.class
=> Fixnum
p 4611686018427387904.class
=> Bignum

# v2.4.x
p 1.class
=> Integer
p 4611686018427387904.class
=> Integer

変更の理由としては

• 32bit/64bitのCRuby/JRuby実装によってFixnumの範囲が異なる
• ISO/JISの規格では明確に範囲が決まっていない

といったことが挙げられます。現実的にはBignumとFixnumはプログラマはあまり区別すること無く利用していたわけです。また次のように互換性も保持されているようです。 （手元の2.4.0devで検証した結果）

1.class == Fixnum
=> true

このためコードの変換は基本的には不要だと思われますが、自作のGem等は早めの対策を行って欲しいとのこと。その際にメジャーバージョン(1.2.3の1の部分)ではなくマイナーバージョン(1.2.3の2の部分）をバージョンアップするように要望がありました。

メジャーバージョンだとGemfileで~>で指定している場合にバージョンアップされないし、仕様変更を嫌ってなかなか導入されないためだそうです。仕様変更を行った際に、こういった細かな気遣いを同時に行うことで変更を世に広める事ができるんだなと妙に納得してしまいました。

2日目

Fearlessly Refactoring Legacy Ruby(Justin Searls)

sutureというgemのお話でした。 メソッドの実行状況を一度DBに保存し、下位互換性をチェックしながら新しいコードに差し替えていくという手法でレガシーコードをリファクタリングしていくことができるようです。実況状況を保存するという手法は、外部へのhttpアクセスを保存して、それをテストで利用するvcr.gemに似てると思ったのですが、対象が外部アクセスではなくRubyのメソッドで、かつテストだけではなく開発環境や本番環境で利用できるのが面白いと感じました。

How DSL works on Ruby(SHIBATA Hiroshi)

Rakeを取り上げ、RubyでDSLがどのように実装されているかの解説でした。DSLとは特定のドメイン領域の問題解決に特化した言語だそうです。Rakeは当初Ruby版Makeを作る思想で作られたそうです。普段RailsでRakeタスクを定義している時にタスクごとの依存関係を簡単に解決できるので、なるほどこれが「特定のドメイン領域か」と理解できました。メタプログラミングを利用してDSLをどのように定義することができるのか初心者にもわかりやすく解説されていたのが印象的でした。

Ruby Reference Manual 2016 Autumn(okkez)

Rubyのリファレンスマニュアルであるるりまのお話でした。Ruby2.4.0では次の点が大きく変更となるようです。

• Tk関連の組み込みライブラリのGem化
• FixnumとBignumの統合

特にFixnumとBignumの統合はドキュメントのメンテが大変に感じました。

Modern Black Mages Fighting in the Real World(Satoshi "moris" Tagomori)

「現代の黒魔術師が現実世界で戦う」というタイトルです。ここでいう「黒魔術」とはダックタイピングの事。Fluentdの0.12から0.14へのバージョンアップでいかにして下位互換性を保持したままNameSpaceを整理していったかという話でした。この黒魔術のおかげでv0.12用に作成されたプラグインはv0.14で問題なく利用できるそうです。 Twitterで「バージョンを1に変更して下位互換性を切り捨てれば？」という意見もありましたが、Fluentdほど無停止が要求され多くの環境で利用されている仕組みにとって、互換性はとても重要なのだと思います。

ただ、個人的にはv0.14でv0.12のプラグインを利用している時には何らかのWARNINGを出さないといつまでもv0.12のプラグインが利用されてしまうような気がしました。私のプロジェクトでも言えますが、メンテが難解な黒魔術を今後どうやって取り除いていくかが課題となる気がしました。

3日目

Ruby Committers vs the World

Rubyコミッターによる座談会でした。様々な話題が飛び出したのですが私が気になったのは次の3点です。

• Stringリテラルのデフォルトをfreezeにしないのか？

  Ruby2.3から次のようなマジックコメントをファイルの先頭に書けばデフォルトでStringオブジェクトがfreezeされた状態となります。

# frozen_string_literal: true

会場からこの動きをデフォルト動作にしないのかという質問がされましたが、会場に「このコメントを普段書いている人」と手を上げてもらったところ、大多数の人が書いていないという状態でした。 おそらく大多数の人が書くようになればfreezeがデフォルトとなるのでしょう。

• Githubで開発はしないのか？

  たとえソースの管理がGithubに移ったとしてもisssueは使わないとのことでした。すでにredmineとsvnの間でいくつもの連携スクリプトが動作しており、そこを自分たちで変更してまで移行するメリットが見いだせないとのお話でした。

• Ruby3では並行性・並列性のサポートをしてほしい

  Rubyコミッターの笹田さんからの要望でした。同RubyKaigiで新しい並列実行モデルであるGuildの発表をされています。まつもとゆきひろさん曰く「何らかのサポートは取り入れていきたいが、それがGuildになるかどうかは分からない」とのことでした。

Web Clients for Ruby and What they should be in the future(Toru Kawamura)

同氏が2014年のRubyKaigiで発表されていたHypermedia: the Missing Element to Building Adaptable Web APIs in Rails はサーバー側のアーキテクチャに関係するものでしたが、今回はAPIにアクセスするクライアントに関係するお話でした。現在FacebookやTwitterなどWebサービスごとに様々なクライアントGemが存在しています。使い方はGem毎に異なり、それぞれのドキュメントを読む必要があります。その理由としてはWeb APIごとのJSON構造の違いや4xxより細かいWebAPI固有のエラーがあります。またAPIを1回呼び出すことと、機能を実行することにはギャップがあり、機能が使いたいわけであってAPIを呼び出したいわけじゃないとの事です。

これを打破するためには状態管理が必要なWebクライアントが必要とのこと。この発表ではFaradayを用いてミドルウェアを作成し、サービス固有のGemを作成せず汎用的な設計にするテクニックが紹介されました。

It's More Fun to Compute(Julian Cheal)

Rubyを用いてコードで音を奏でる発表を行われていました。まず、様々な波形による音の違いが説明されFM音源世代のおじさんたちは大喜びでした。バブルソートとクイックソートのアルゴリズムの違いを音で表現したのは素晴らしかったです。

まとめ

今回は会場の素晴らしさが印象に残るRubyKaigi2016でした。毎年ですがスタッフのホスピタリティあふれる活躍のおかげで3日間楽しく過ごすことができました。

さて昨今、言語仕様としては多言語に押され気味なRubyですが新しい並列実行モデルや、動的型付けのカジュアルさを引き継いだ型推論の考えなどまだまだネタに尽きないなぁと思い安心しました。今後どのようにRubyが進化していくのか楽しみです。