日常

ケ・セラ・セラ

Railsdm 2019 で Charty on Rails というタイトルで発表しました

みなさん Railsdm 2019 お疲れ様でした。

僕は 2 日目 (3/23) に、"Charty on Rails" というタイトルで発表しました。

Charty に関する発表をするのは今回がはじめてでした。そういうこともあって、伝えたいことがたくさんありました。

Charty は Rails アプリケーションを書くに通常必要な技術の領域に対して、扱うもの (データ構造、plotting library, ユースケースや前提知識) が少々ニッチです。

なにから話せば伝わりやすいだろう、30 min という枠の中で、自分の言いたいことはなんだろう。この場で何を伝えて、発表後に得ていたいもの、発表後になっていたらうれしい状態はなんだろう。みたいなことにいつも以上に悩んだなあということを今思います。

これらはスライドにも書いたのですが、結果的に、今回自分はこういう発表をしたいんだなということが分かりました。

  • 自分が前に進むための発表
  • 自分以外の前に進みたい人が前に進みやすくなる発表
  • 開発に参加する人が増える発表

Charty のことを紹介したいが一番強くて、Charty の開発の過程というのは、他の方にも再現性のある成長の 1 パターンだと認識できたので、そういう内容までを含めました。上手く説明できたかどうかはまた別ですが。

そして、30 min (発表)後、こうなっていたら嬉しいと考えていることが分かりました。

  • Charty って、こういうものなんだ! (知ってもらう)
  • この人 (たち) は、そういう活動をしているんだね! (知ってもらう)
  • 私も開発することに興味はあるから、 参加してみよう! (思ってもらう)

なので、発表後や懇親会で Charty について色々と質問をくれたり、中でも Red Data Tools 行きますと言ってくれたりしたことは嬉しい出来事でした。ありがとうございます。

そうそう、次回の Red Data Tools の開発の集まりは 4/9 (火) ですよ。4/9 っていうともう RubyKaigi 直前ですねえー。

speee.connpass.com

AMA で頂いた質問に回答しました。 issei126 さん質問ありがとうございました。

railsdm.herokuapp.com

質問

Charty は gruff や Rubyplot のラッパーライブラリという認識でよいですか？ 直接それらを利用するのではなく、Charty を使うメリットはなんでしょうか？

回答

質問ありがとうございます。

  1. Data Abstraction Layer を用意したことにより、サポートしているデータ構造 (現在のところ Daru::DataFrame, Numo::NArray, NMatrix, ActiveRecord) であればどれでも同じように扱えること。

  2. Plotting Abstraction Layer を用意したことにより、サポートしている plotting library (現在のところ maplotlib, gruff, rubyplot) であればどれで統一されたひとつのインターフェースで扱えること。

  3. 1, 2 により、ユーザが使いたいデータ構造、Plotting library の組み合わせで自由に plot できること。

  4. Charty の用意している設定により、render メソッドを呼ぶだけで、"そこそこ良い感じ" の設定でグラフを描画できること (それぞれの plotting library で、きれいなレイアウトでグラフを出力したいとすると、細かなオプション指定を自分でする必要が生じます。その手間を省き、data plot のために時間を使うよりも、本来目的とするデータ解析に集中することができる状態になること) が、Charty を使うメリットです。 なので、手間をかけて詳細に plotting library のオプションを設定してでも、自分好みのきれいなグラフを出力したい。といった用途では、Charty を使わずに、直接自分の使いたい plotting library を使わなければ、やりたいことを表現できないことがあります。

この様な特徴を理解して Charty を使うとよいと思います。 また上記とは別に、 Charty がより多くのケースで便利に使える様に、引き続き改善を続けていきます。

幸運ではない出来事として、発表中に Mac がフリーズしてしまい、再起動のため発表時間が少なくなってしまいました。せっかく発表を聞きにきてくれたのにごめんなさい。Charty の開発という体験から伝えたいことがもう少しあったり、コードに触れる時間が無くなってしまいました。駆け足で飛ばしてしまった部分や、最後の方のまるっと現れなかった部分、言葉で説明出来なかった内容を文章をちょっとだけ加えて公開しました。

speakerdeck.com

参加者としても楽しみました。

Day 3 の時 ほどじゃないけれどいくらか写真を撮ったりしていた。

中でも金子さんの写真はかなりいい感じに撮れたと思うんですよ

treby さんありがとう！！

せりーぬさん、いそはたさん、りゅっくん、あんでぃ

僕は Speee の社員なのですが、今回 Railsdm 2019 のスポンサーの話を快く受けてくれたり、登壇や開催自体を喜んでくれたことが僕としてはかなり嬉しかったし励みになりました。

特に周りが無関心であっても自分がやりたいからやれはするんだけれど、社内で応援してくれる人がいると全然違いますよやっぱり。活動がしやすいし、モチベーションにもなります。

当日などはもっと多くの人に手伝ってもらったのですが、主に関わっていただいた方々には特に感謝しています。

せりーぬさんはめっちゃいい人で、とてもすごい人でたとえば、「(イベントの打ち合わせで) 松田さんと一回直接話した方が手っ取り早いのでは？今日 Asakusa.rb に行くと会えますが一度一緒に行きます？」「行きます！(即答)」 みたいな人で、なんらか活動している人が大切にしていることを理解することの大切さみたいなのを知っているんだなー。という感じの人で、めっちゃ応援してくれる。とてもすごい人。

いそはたさんは Railsdm の冊子や水のデザインなどをもりもり進めてくれたデザイナーの方で、実はこの作業で初めて僕は接点を持ちました。僕も案を出したりの辺りでちょっとだけ関わったんだけれど、目的や状況に応じて意味のあるものに具現化していく様子とか、さっと手を動かして作って、発注などの処理までやってしまう。考え方が枠にとらわれていなくて好きだし、作業の過程でずっとすごいなーと思っていた。色々と進めて頂いて本当にありがとうございます。

りゅっくん、あんでぃ。Speee のこととか、スポンサーとして伝えたいことを、限られた時間や、スペース、文字数の中には収まりきらないほどあるわけなのだけれど、それをどうしたら最大限伝えられるかとか、妥協せずに一番良いところを目指すという考え方、動き方がすごくて、登壇する側としてはとにかくありがたいし、僕は僕でやることちゃんとやろう。がんばろう。という気持ちになれました。ありがとうございます。

今後のこと

Charty に関する一回目の発表が悩みながらも今回できましたが、Charty の開発自体は続きます。より便利に使えるようにします。 今回を基準として、次回はもっと分かりやすく説明できるようにしたいですし、そうできるようなコードを書いて、発表技術の方も改善しないとなあ。ということを思っています。

今回初回なので、色々と詰め込みたくてどうしても話題が発散しがちになってしまったとも思います。機会があれば出来るように、Charty の技術要素のみに特化した発表の準備もしたいです。

そういうわけで、引き続きコードを書いてひとつずつ実現していこうと思います。

幸運にも、今年の RubyKaigi でも登壇することが出来るので、次はその場で良い成果を伝えられるように準備したいと思います。福岡でまた会いましょう。

rubykaigi.org

Measure What Matters (slack memo)

kazuma.furuhashi.284km [3:48 PM]
Measure What Matters memo (edited)
アンディグロープについて（google, intel など、過去の事例と共に）
要諦
絞り込む、目標はボトムアップで、押し付けない、常に柔軟な姿勢で、失敗を恐れない、手段であり武器ではない、辛抱強く決然と
ここまで２章

koichiro.oba [3:54 PM]
いいはなし

kazuma.furuhashi@speee.jp APP [3:55 PM]
Event starting in 5 minutes:
TelTel の UI について相談
Today from 4:00 PM to 4:30 PM at ラウンジ辺りの、適当な空いている場所で

kazuma.furuhashi.284km [3:56 PM]
４章まででそれらのもう少し詳細な話。
５章で、ケーススタディの話になった。一旦中断。

kazuma.furuhashi.284km [4:12 PM]
16:25 まで再開
6 章で印象的な部分は、「お願いだから OKR を作って！」と言い聞かせた。の辺り。社員から新のコミットメントを引き出すには、リーダーが率先垂範しなければならない。まず自分が示す。ということ。
７章は、会社全体の目標が定まった後の話。アラインメントについて強調している。
組織図と絡めた OKR の例があるので、イメージしやすいかもしれない。
上意下達で決まってしまった場合の弊害が生じるリスクとその説明。機敏性の欠如、柔軟性の欠如、コントリビューターが軽んじられる、組織の連携が一面的になる。
８章は、アラインメントに関するケーススタディ
９章は、垂直、水平的連携に関するケースすたティ
１０章は、計測すること（進捗を）と、責任の明確化
「われわれは経験からは学習しない （略）経験を振り返ることで学習するのだ」とか
11, 12 章で、量的なトラッキングなくして、ストレッチ目標を達成したことを確認することはできない。的なこと

kazuma.furuhashi@speee.jp APP [4:25 PM]
Event starting in 5 minutes:
【ぬりトラ！】ウィンセッション＆振り返り
Today from 4:30 PM to 5:00 PM at 500_黒崎5F セミナー

kazuma.furuhashi.284km [4:25 PM]
12 章はあとで２周めを読む。
１３，１４章で、ストレッチについてもう少し。と、ケーススタディ。ここがけっこう肝ですよね。と僕は思ってる。
１５章から第二部。またあとで読む。中断。

kazuma.furuhashi.284km [4:48 PM]
リリース出来るものを毎回作るってだいじだなー＠ぬりとらウィンセッション

kazuma.furuhashi.284km [5:06 PM]
再開。二部。対話、フィードバック、承認（CFR)（継続的パフォーマンス管理。を実践する手段）
何より重要んあこととして、OKR と CFR には相互に補強しあう性質がある。
人事評価精度のはなし、評定と目標管理を切り離す的なはなし。
CFRの踏み込んだ話。
承認は CFR のなかで最も過小評価され、最も理解されていない構成要素。
１６章、年次勤務評定を廃止するというアドビのケーススタディだった
17章の、OKR は本当に重要なことを達成する、OKRは規律を強める、OKRはエンゲージメントを強める、OKRは透明性を高める、OKRはチームワークを強める、OKRは対話を促進する、OKRは文化を改善する、OKRはリーダーを成長させる。とかは2周目を読もうと思う。
18章、文化。
プロジェクト・アリストテレス
OKR・CFR 文化の最大の特徴は透明性の高さだ。
19章　文化の変革で、OKR の再生の話がある。
OKR に再挑戦するなら、会社の全員に改めて研修を実施する必要がある。〜〜
19章も2周めを読もうと思う。
20 週は文化の変革を題材にしたケーススタディ。
情熱を測定する。というのはおもしろい。
どれぐらい情熱的なのか。
あなたが情熱的な活動家だとしよう。ではどれぐらい情熱的なのか。
OKRに弊害はないのだろうか？OKRを誤解すると、組織がきちんとしすぎる危険はあると思う。（略）破壊的変化を起こし続ける必要がある。
OKRという枠組みは、組織のなかの狂気やひらめきを制御する。リスクテイクと信頼の環境を与えてくれる。そこでは失敗は許されざる罪ではない。安心して自分らしくいられる場所だ。〜〜
21章 これからの目標
ストレッチ目標っていうのを、僕はもうちょっとなんかアレした方がよさそう感がある。
参考資料として、グーグルのOKR実践マニュアル　が書かれている。
コミットするOKR vs 野心的OKR。OKRには2種類があり、両者を区別することが重要である。〜〜
この使いわけを間違うと路頭に迷う感も実感としてある。
OKRを作成する際の落とし穴。ここは2週目読みながら自分のOKRとか見直してみようかな。
追加のリトマステストは、なるほどという感じがある。
参考資料２は、標準的なOKRサイクル。
参考資料３　パフォーマンスを話し合う
この辺も苦手というか面倒くさがるのでちゃんとしよう。という感じだなー。
参考資料４　まとめ、参考資料５　参考文献。で完。
本は library ni
本は library に返却しました。

今年なにやってたかとか、書く機会がなかったこととかを

今年なにやってたかとか、書く機会がなかったこととかを

今年はどうやって生きていたんだろうと思い、カレンダーを振り返ってみた。特に、今年の振り返りだとか来年の目標というわけではないけれど、会社を出るまでちょっと時間があるのでこういうのを書いてみる。たぶんこういうのを書いてみるのははじめてな気がする。

そういえば今年は忙しいタイミングが何度かあって、4月、12月なんかはそれなりに大変です。

  • 1月
    • 技術署典4 に申し込む
  • 2月
    • Ruby25 があったね
    • RubyKaigi proposal 提出
  • 3 月
    • 沖縄Ruby会議02 で発表
    • Rails Developers Meetup 2018 day1, day2 開催
  • 4 月
    • 技術署典4 無事完売
  • 5 月
    • RejectKaigi で発表
    • RubyKaigi 2018 LT 発表
  • 6 月
    • TokyuRuby会議 12 で発表
    • 技術書典5 に申し込む
  • 7 月
    • ひっそりと Speee 社員になる
    • Rails Developers Meetup 2018 Day 3 Extreme 開催の後、顧問になる（いまでもそうなのかな？）
  • 8 月
    • RubyConf proposal 提出
  • 9 月
    • 大江戸Ruby会議 07 で発表
  • 10 月
    • 技術署典5 新刊落とす
    • Rubyアソシエーション 開発助成金2018 に応募
  • 11 月
    • RubyWorld Conference 2018 初参加/発表
    • RubyConf 2018 初参加/LT失敗
  • 12 月
    • てんやわんや

次に、暫くブログ記事は会社ブログの方に書いていたのですが、特に RubyConf の記事とかは失いたくないものなので，ここらでいったんリンクをまとめておこうと思います。 ちなみに僕が何故会社ブログに書くようになったかというと、広報の生田さんの最初の巻き込み方とそのタイミングが上手だったからこういう結果になりました。人の巻き込み方、タイミングって大事だなと思いました。この辺は来年からはまた状況が変わるので、またどうなるかはまだわかりませんね。

最後に、書く/話す 機会とかが無かったことを脈絡ないですがいくつか

  • なにかが続くってことは、だいたいずっとやってる人がいて、だいたいどういう時にも継続したこと(そうできること自体も)がすごいと思っている。
  • Asakusa.rb, Red Data Tools, Rails/OSS パッチ会 からは多くを体験させてもらったなあと。

あー、書いてたらぼちぼち出発する時間なので、ここまで。来年も生きられるとよいです。それではよいお年を💓

写真で振り返る #railsdm 2018 Day 3 Extreme ✌

聞きに行った発表の登壇者を撮る。ということをしていました。良い感じの写真が撮れた時もあったのでひととおりそれっぽいものをまとめてみました。

発表直前の微妙に緊張感あるタイミングで最高の ✌ をありがとうございました。 準備や僕が行くタイミングを失敗したものはそういう感じの写真になってしまった。

今回は、自分が依頼したにも関わらず聞きに行けなかったセッションもあり、その点はごめんなさい。

しかし毎度思うが、僕の写真力低いな...。

techplay.jp

Ruby Hack Challenge の良さについて書いてみる

実際に参加したところとても良いイベントだったので、何が良かったのかという日記を書いてみようと思う。

僕が参加したのはこちらです。6/23 (Sat) にありました。Cookpad Ruby Hack Challenge #4 カバレッジ特別回

cookpad.connpass.com

そして、7/16 (Mon) にもイベントがありますね。高専カンファレンス Ruby Hack Challenge - Rails寺子屋特別編

rails-terakoya.connpass.com

まず本題である良かったことですが、

  • Ruby のカバレッジの取り方、見方を覚えることが出来た
    • それは、自分に出来ることが増えたということ（カバレッジを見てこの辺テスト足すかとか）
  • 実際にイベントの時間内に、イベントの趣旨に沿った PR を作れたこと (https://github.com/ruby/csv/pull/38)
  • 他にもけっこう多くの人が、Ruby にパッチを送ったり出来ていたので、これはすごいイベントだな...!! と思いました。(そして聞く限りでは、僕もそうだけどその方々も特別知識があったわけではなく、当日の説明やサポートを受けつつパッチ送るまで到達したらしい)

僕の状態を書いてみると、

  • プログラミングに興味があり、趣味で何かコードを書いたりします
  • Ruby のことは好きで、もうちょっと知りたいなと最近思っています
  • 仕事では Rails アプリケーションをいくらか書いたりしてきた

という感じになります。

上 2 つに当てはまる方はけっこういるのではないでしょうか？ そういう方はきっと参加したら楽しめるでしょうし、おそらく当日得られるものがあると思います。という感想を実際に参加することで持ちました。

3 つめの仕事のことはあてはまってもそうでなくても、あまりどうでもいいかなと思います。

Ruby のことをもうちょっと知りたいと言っても、なんか凄いレベルでなくて良くて、ちょっと何かやってみるかと思える程度の興味があれば十分ではないでしょうか。

実際僕も興味だけあって大して知識がありませんでしたが、笹田さん、遠藤さんが用意してくれていた資料があって、それに沿ってやれば Ruby のビルドが出来てカバレッジが取れて、カバレッジの見方も説明してもらえて、途中で何かにハマったり理解できていないところがあれば自由に聞くことが出来ますし、だいたい会場内にいる誰かが詳しかったりする環境なので（これもすごいことだ）まあその時点での知識は問題にならないのではないでしょうか。

現時点での知識よりも、興味が持てることの方が大事だと思っていて、何故ならその後も継続しやすいと思うからです。継続できると、なんだかんだ役に立つようになってきたり、楽しみ方も増えてくるような感触はあります。

自分がそうだったのでこう言いますが、参加してみて、自分にも出来そうなことが見つけられたりしたら、けっこうお得だと思います。

rails-terakoya.connpass.com

技術書典5 に申し込んだ

申し込んだのは何日か前。

5ヶ月ほど前には、4 に申し込んでいたみたい。

at284km.hatenablog.com

Ruby 以外の言語で書かれた良い感じのライブラリを、Ruby で便利に使おう！的な内容を考えています。 当選するかはわからないし、内容もそうなるかは未定ですが、そういう意気込みです。

techbookfest.org

表参道.rb #35 ~After RubyKaigi~

こちらも RubyKaigi のことなので、書きます。

omotesandorb.connpass.com

表参道.rb で発表するのは、30回以来だったようです。たしかに久しぶりという感覚がありました。

After RubyKaigi というテーマですが、僕は振り返りだけするというよりは、アレです。kaigieffect は大事だと思っていたので、それを言葉にして、小さくても RubyKaigi から得たことから新しい何かをしたかった。

そう考えて今回選んでみたのがライフゲームの実装の話でした。RubyKaigi でも何度か話題にあがったシーンがあったと思います。僕は過去の表参道.rb の発表で、まだ自分で実装したことがないけれど時間があったらやりたいヤツとしてあげていました。なのでちょうどよい。機運だ。と思ってやりました。

書いてみると、以外にそこから膨らませるようなおもしろそうな話を浮かばす、結局やりました！動かします！バーン！！というだけのオチになってしまってイマイチでしたが、何はともあれやりたかったことがひとつ出来ました。

https://284km.github.io/slides/20180607_omotesandorb35/slides/#/