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 DeepLensAWS DeepRacer取り揃えているところがすごいですね。

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

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

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

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

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

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

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

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

ざっくり書くと、

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ボタン」は電波が入ればどこでも使えます!プレイス=地球と言っても過言ではありません。

f:id:tech-kazuhisa:20190818143503p:plain
LTE-MボタンでLambda経由でメール送信してるところ

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

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

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

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

ポート数の違い

f:id:tech-kazuhisa:20190815095345j:plain
左がMacBook Pro (13-inch, 2019, Two Thunderbolt 3 ports)
右がMacBook Pro (13-inch, 2018, Four Thunderbolt 3 Ports)

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

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

f:id:tech-kazuhisa:20190815095408j:plain
MacBook Pro 2019の下位モデルの右側にはThunderbolt 3 ポートは無い

f:id:tech-kazuhisa:20190815095404j:plain
MacBook Pro 2018の右側にはThunderbolt 3 ポートが2つ

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

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

ファンがうるさい

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

キーボードが熱い!!

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

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

f:id:tech-kazuhisa:20190815095507j:plain
2018年モデル
f:id:tech-kazuhisa:20190815095515j:plain
2019年下位モデル
なんと2019年下位モデルには本体下部にスリットがありません。このせいで排熱が間に合わず本体内部に熱が滞っているのではないですかね?

まとめ

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

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

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

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

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

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

f:id:tech-kazuhisa:20170903094526j:plain ▲温度センサーを接続

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

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

f:id:tech-kazuhisa:20170903095337j:plain ▲sakura.ioのWeb画面でセンサーが取得した値をJSONで表示しているところ

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

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

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

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

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

まとめ

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

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

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

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

niwakabike.blog.fc2.com

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

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

f:id:tech-kazuhisa:20170709154020j:plainf:id:tech-kazuhisa:20170709154026j:plain

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

RubyKaigi2016に参加してきました

f:id:tech-kazuhisa:20160909131955j:plain 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を取り上げ、RubyDSLがどのように実装されているかの解説でした。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は使わないとのことでした。すでにredminesvnの間でいくつもの連携スクリプトが動作しており、そこを自分たちで変更してまで移行するメリットが見いだせないとのお話でした。

  • 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にアクセスするクライアントに関係するお話でした。現在FacebookTwitterなど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が進化していくのか楽しみです。

Kansai RubyKaigi 06に参加してきた

参加してきた!

7月11日 (土)にKansai RubyKaigi 06がエムオーテックス新大阪ビルで開催されました。場所はビルの名前の通り新大阪駅近くで、非常に便利の良い場所です。 セッションは映画館みたいな大会議室で行われました。参加者は200名以上で大変な盛り上がりでした! f:id:tech-kazuhisa:20150711095345j:plain

以下、気になったセッションのメモです。

Rubyにみるプログラミングスタイルの進化(まつもとゆきひろさん)

早口のMatzのセッションにしては珍しく、スライド上でうさぎがカメを追いかけてる状態が長かったです。I/Oを読んでる17歳の時の写真から始まり、ポケコン、紙のノート上でのプログラミング、SONY NEWSワークステーションでのRuby開発の話とMatz自身の人生を垣間見ることができました。 印象的だったのがGitの利便性についてMatzの口から説明があったこと。これって珍しいですよね。 あとは、静的型付けの話。型があるのが嫌なわけではなく、いちいち書くのがめんどくさいとのこと。この辺りの話は「オープンソースの代弁者」としてセミナーでスーツ組に対して話をする白Matzとは異なり、いきいきしていました(笑)。 今でもRubyMineなどのIDEではかなりいい感じにコード補完がされるので、さらにPCの処理能力が進化し、言語側から型情報のサポートを受けることができれば、さらに楽ちんなプログラミングができる世界がやってくるのでは、と感じることができたセッションでした。

Readable RSpec(株式会社spice life)

LT枠でのお話でした。RSpecの書き方についてのあれやこれや。 let(:user)をどこで定義するのかは確かに難しいですね。私はスコープが狭くなることになるべくこだわりたいので、同じ定義を2箇所で書いてしまうこともあります。DRYに書けるのがRSpecの利点と思いますが、見通しが悪くなるくらいならDRYは捨てます!

Railsガイドを支える技術(@yasulabさん)

railsguides.jp

Railsガイドを和訳したときのノウハウについて。Gitのコミットログをスキャンして変更点を探し出すという手法が素晴らしかった。私自身、この手のガイドは1箇所でも情報が古ければ全体的に古く感じてしまうこともあり、情報の鮮度へのこだわりをひしひしと感じました。

スモウルビー1.0:小学3年生から始めるRubyプログラミング(@takaokoujiさん)

Scratchベースのプログラミングツール「スモウルビー」でプログラミング少年団という活動を行っているお話。素のScratchはブロックを組み合わせるだけで、その後のアップグレードパスが用意されていないけど、スモウルビーを動かすためにはRuby + Railsが必須なので、より複雑なプログラミングを行う環境が自然にできあがるとのことでした。 我々も同じことが言えて勉強会で意識が高まったけど、家や会社で試そうとすると環境構築でつまずいてしまうパターンが多いので、この取組はとても理にかなっていると思います。スモウルビーはScratchをRubyのコードに変換することもできたと思うので、そのあたりデモンストレーションで見たかった気もします。

RSpec、Minitest、使うならどっち?(伊藤 淳一さん)

偉い人がRSpecを使いたがらない風潮は私も以前から感じていました。今回の発表では機能やスピードをわかりやすく比較してRSpecに優位性があることが証明されました(って理解でOKよね?)。とはいえ、Githubでプルリク出したりForkしたソフトウェアの修正時にMinitestの知識が必要になってくることもあるので、基本的なことは抑えておこうと思いました。 余談ですがMinitestがランダムな順序でテストを実行するがデフォルト動作なのは良いことですね!「手元で動かしてOKで、CIでコケる」というテスト組み合わせ問題の単純な解決方法になりそうです。

API server/client development using JSON Schema(@izumin5210さん)

単なるテキストファイルであるJSONに制約を付けてバリデーションを行うことができる仕組みを「JSON Schema」と言うそうです。今回はじめて知りました。私自身、仕事でAPIを作ることが多いので調べてみようと思います。 発表の中で「RailsではStrong parameterがあるのに JSON Schema必要?」みたいな話があったのですが、JSON Schemaの一番の利点はクライアント・サーバー両方のテストが容易に書けることだそうです。 具体的なコードが少なく話しの後半はちょっとついて行けてなかったのであとで調べてみます。

キーワードパラメータを支える技術(笹田 耕一さん)

Ruby2.1から2.2に変わったタイミングでキーワード引数が大幅にスピードアップしたそうです。今回の発表ではどのような取り組みで高速化したのかをわかりやすく説明されていました。 通常Rubyの高速化の話はC言語で語られることが多く、私にはチンプンカンプンなのですが今回はRubyで作られた擬似コードによる説明で非常に分かりやすかったです。

def f3
  3
end

def foo(k1: 1, k2: eval(“k3”)), k3: f3())
  p k1, k2, k3
end

foo

この場合、一見 1, 3, 3 と表示さそうですが、Rubyのコードは左から実行されるのが大原則なので、 1, nil, 3 と表示されるべきなのだそうです。めったに書かれないこのコードを実現するために複雑な処理が入っているとのこと。 懇親会の居酒屋でもノートPCを開いてこの点を丁寧に説明して下さり、より理解が深まりました。ビール片手にRubyコミッターから言語の仕様の話を聞かせてもらえるという貴重な体験ができました。

まとめ

大阪や東京で開催されるRubyイベントに何度か顔を出すうちに、親しくお話させてもらえる方も増えてきました。こういったイベントでの話はブログやSNSでは得られない生の声を聞くことができるので楽しいですね。 最後になりましたがスタッフの皆さんお疲れ様でした。楽しい時間をありがとう! 来年はOkayamaRubyKaigiを開催しようかな?

RubyKaigi2014に参加してきた(2日目、3日目)

1日目はこちら

2日目

Coming soon…(Yukihiro "Matz” Matsumoto)

  • 2001年にRuby2の話をしている
    • VirtualMachineが入る
      • 6年後
      • 笹田さんがきちんと実装してくれた
    • M17N
    • Native thread
    • Generational GC
  • RubyConf 2005
    • Stabby lambda ( -> )
  • RubyConf 2006
    • Bikeshed argument encouraged
      • 自転車小屋の色を何色にするかは盛り上がってすぐに決まるが、原子力発電所をどこに作るかは有識者の間で勝手に決まってしまう
  • 22のアイデアのうち7つは入らなかった
  • オープンソースコミュニティはサメのようなものなので泳ぎ続けないと死んでしまう
    • 燃料を投下したい
  • Ruby 3.0のアイデア
    • Concurrency
    • JIT(LLVM?)
    • Static typing
  • 最近登場した言語はスクリプト言語でありながら静的な型を持っている
    • TypeAnnotation
      • def connect(r -> arg) -> Fiber みたいな
    • パフォーマンスのためのStatic言語が必要なわけではない
      • 思い込み
    • コンパイルタイムの短縮
    • 型を導入すると柔軟性が減る
      • ダックタイピングと相性が悪い
    • Documentation
      • 今はnumと書いてたら数字というルール
      • メソッドに何を渡せばいいか型宣言をみればわかる
    • RubyがStatic Typingを持っていない理由
      • なくてもなんとかなる
      • ダックタイピング
    • 静的な型を導入するとしてもOptionalな仕様になる
      • 型ありの世界から型なしの世界に渡すと情報が失われる
        • ごく一部だけの型チェックしか行われない
      • TypeScriptは頑張ってすべての型を指定している
      • すべてを型指定したRubyRubyじゃない
      • 型が推測できるようなコードを書いている
        • いちいち型宣言したくない
        • ベストエフォートな型チェックをする技術
          • Duck Typing的に型を推測する
      • コンパイラに型を教えるのではなくて、コンパイラが「こう思って書いてるんですよね?」という推測を行ってほしい。IDEやエディタから補完できるようになる。
      • Two language is one.

感想:Ruby3.0に導入されるかもしれない機能のお話。私はPythonのように、制約はないけどDocumentとして引数の型を書いておくという手法はアリかなと思う。けど、まつもとさんはとにかくコード量を減らしたい仕様にしたいみたい。コードの文脈からしてこのメソッドの引数にはintが入るであろうことは、言語が判断すべき。わざわざ型を指定しなくても、文脈で判断できるのが良いコードという認識なんだと思った。現在RubyMineとかのコード補完やチェックはかなりのレベル(ホント、どうやってるのか不思議なくらい)まで来ているので、言語側がサポートしてくれればより精度の高いコーディング補助が可能になると思う。今後Rubyがどのような進化をとげるのか楽しみ!

<%= link_to "bundle", "update" %> - Make "bundle update" more fun to review(Kensuke Nagae)

  • bundle update
    • Gemfile.lockが更新されるが、各Gemがどんな変更が行われているかを見たい。
  • Compare Linker
  • GithubからCompare Linkerがwebhookを受け取る

感想: bundle updateする→Gemfile.lockがなんか更新されてる→いつ更新してるんだろうとRubyGemsを見に行く→何が変わってるんだろうとGithubを見に行く... という流れは私もよく体験する。これを自動化してGithubに変更点のDiffを見ることができるリンクをpushする仕組みを作ったお話。3回同じことをやったら自動化しろとはよく聞くが、この複雑な処理を自動化したのは素晴らしい。

ServerEngine: a framework for multiprocess servers in Ruby(Masahiro Nakagawa)

  • fruentd
    • ログ収集ソフトウェアのメイン開発
  • System programs
    • Chef
    • Serverspec
    • Apache Deltacloud
  • Network server
  • Log Server
    • Fluentd
  • サーバープログラミングで考慮すべきこと
    • マルチプロセス、マルチスレッド
    • エラーハンドリング
    • ログ
  • ServerEngineを作った
  • 何ができるか
    • Unicornみたいなサーバーを簡単に作れる
    • Worker moduleとServer moduleをユーザーが作る
  • 3層構造
    • Supervisor
      • ユーザーがあまりいじる箇所はない
    • Server
    • Worker
  • USR2 signalでリロードできる

感想: 操作感はまさに慣れ親しんだunicornそのもの!webrickも非常に便利なWebサーバーだが、ServerEngineを使えば大規模アクセスにも対応したunicornライクなサーバーを作ることができそうだ。

3日目

おはようRails

  • (あまりの面白さにメモ取ってなかった)

    感想: tubolinksはみんな消してるんだなー、とか今の若い子は「Railsは業務で使うもの」だと思ってるとかなかなか刺激的な内容だった。正直、私はあまりサービス志向のプログラマじゃないので(社会人としてそれはどうなんだというのはさておき...)Rails使ってサービスを素早く立ち上げるって点はあまり興味ないかも。自分が楽しめる仕事をやっていきたいなーと思っております。

Speeding up Rails 4.2(Aaron Patterson)

  • ManageIQ
  • Rails no one commiter
  • Rackはもう終わり。楽じゃない
  • Rack 2.0
    • the_metalはrack2.0のプロジェクト
  • Rack 1.xの問題
    • hashのkey
    • ストリーミングの制御がめんどくさい
  • Adequate Record
  • URL PATHは短いほうが速い
    • 配列的な構造を定数に変換することでスピードアップ

感想: たこ焼き仮面ことAaronの日本語での発表はとても楽しく聞くことができた。特にスライド内のジョークを日本人のセンスに合わせているところがGood! 発表内容としてはAaronさんの地道なRails高速化についてのお話がメイン。長く運用するシステムでは長期的に見ると細かい点が積み重なり問題を引き起こすことがあるので、このような改善はとてもありがたい。「存在しないコードが一番速い」というのは名言だと思った。

Everything is Broken: A Story of Hope(Jonan Scheffler)

感想: あまりRubyに関係がある内容では無かったが、公開鍵暗号の仕組みを色の混ぜあわせで解説する方法はとてもわかりやすかった。私も他人に説明するときは使わせてもらおう。

以上が3日間でビビッときた発表でした。 RubyKaigiはいつもネット上でしか交わらない方とリアルでお話することができる素晴らしいイベントです。この3日間の熱を冷まさないように、岡山での活動につなげていかねばっ!と思いました。