日常

ケ・セラ・セラ

名古屋Ruby会議04 と名古屋観光日記

6/7 (金) に名古屋へ行き、6/8 (土) に帰宅。さすがに一日では多くは回れないものの、大いに名古屋を楽しんで来ました。

今回は、これまでと継続しての目的 (上 2 つ) に加え、3 つ目のやつを加えて Pragmatic Charty というタイトルで発表しました。

  • Charty を知ってもらいたいなあ
  • (Charty に限らず) 一緒にコード書く人が増えたらうれしいなあ
  • そろそろ実用的な例を示していきたいなあ

speakerdeck.com

発表準備的には、色々考えたりちょっとした挑戦だったりしたわけですが、カッコいいタイトルにしたのでその名に届く内容をお届けできたかと言うと物足りない部分はあったなあと思います。 この点では、Real-world なデータで説明する。というのが次に発表するに当たってまず早いところ用意したいものだなと感じました。こういうことが出来ますというサンプル用のサンプルデータだとしても、それが現実のデータで、なんのためにどう整理されたデータが最終的に今ここで plot されて、こういう見方が出来るからこういうことが分かっちゃったりするんです。みたいにしないと、なんかふわっとしちゃうのだと思った。 なのでそれを用意して、引き続き必要な機能を加えたり、今月辺りで既存の実装の整理をひととおり終えて、その後インターフェイスを FIX してリリースして、サンプル集を意味のあるデータで置き換えて push して、ぐらいまではこの次一気に進めたいなとか考えています。実際に Charty が使われている例とかも、徐々に紹介できる状態にしていきたいところです。

今回に関しても、やっぱり一番嬉しかったのは、発表の後で Charty に興味があるんですけど。と声をかけてもらえたことです。名古屋Ruby会議04 をきっかけに ggplot2 の対応が進んだ話とかがその内表に出せたらいいですよねー。

まあ、やりたいことはたくさんあるのですが、ひとつずつなるべく速くなるべく楽をしながらやろうと思います。

で、そういえば名古屋と言えばにせれぶさんに伝えようと思っていたけれど結局伝え忘れてしまったなとさきほど思い出したことがあって、六本木のよく行っていたお店(地下の方です)の方からにせれぶさんに会ったらよろしく言っといて!と言われていたのでした。次に名古屋でにせれぶさんに会った時には今度こそ直接伝えようと思います。 あの内径 35m のギネス記録らしいすごいプラネタリウムなどは行きたいので、また来るほかないです。

以下は写真とか。次回は RubyConf Taiwana 2019 のことを書きたいわん。台湾は始めてなので楽しみわん。

2019.rubyconf.tw

RailsConf に初めて行った時の話

4/29 出発、5/6 帰宅。なスケジュールで、RailsConf 2019 に参加してきた。帰りの飛行機の中で文章を書くはずだったところ、色々とあってそうはいかず時間が経ってしまった。

RailsConf のことは書くに難しくて、色々あったのだけれどあまりここに書くことがないなぁという感じ。

行く前後の差分で、主に後の状態について書いてみる。

  • 実際に行って、実際に現地でいろいろと体験したこと
  • だから RailsConf を現実のこととした上で、僕が話したい人と会話することができる
  • ちょっと慣れた。まだ続くわけだし
  • お金が 50 万円ぐらい減った
  • こういう働き方もあるかー
  • とか、こういう選択肢も取れるんだ
  • とかいう発想は向こうで人と話してもらったもの
  • ミネアポリスでバスに乗ることができる
  • ミネアポリスでレンタル自転車に乗ることができる
  • ミシシッピ川に触ったことがある
  • 飛行機の乗り継ぎに間に合わない時のやり方をいくらか知った
  • この作者が、この実体か。といくらか紐付いた。
  • こういうこと考えているのか。とかも
  • 総合すると、楽しかったですね
  • 行ってよかった
  • 行ってよかったと言えるだけの得たものがあった
  • あらためて、RubyKaigi すごいと思ったり
  • 手荷物はもうできる限り預けない

書くにあたって、これらを詳しく説明することを諦めた。

より英語でのコミュニケーションがマシになると、より楽しめそうなのでそこは、モチベーションになっていて良いです。

そういえばなぜ行ったかという話を補足すると、(以前書いた気がするけれど)、yahonda さんと話してもう行くことは決まっていたので、実際に行ってきた感じです。

LT は、今回もできなかったわけですが進歩していて前回 (RubyConf) は 28 番目だったところ今回は 20 番目に名前を書き 19 人目まで順番が回ってきた。おしい。この調子で行くと次回は成功する。ちなみに今回は 11 番目の平野さんことカルパス氏が LT 成功していますね。

f:id:at284km:20190521130626j:plain
RailsConf 2019 LT

今回は自費だったのだけど、宿代は yahonda さんと折半したり、僕が一日長く残る都合で (そうするとなんと帰りの飛行機代が 10 万円ほど安くなった!! )、最終日の宿は、koic さんも RailsConf 2019 に参加していて、幸運なことに永和さんにまたしても宿スポンサーをして頂きました。本当にありがとうございます。

最後にこちらは、RailsConf 一日目に行われた Ruby Tuesday Meetup の様子で、これは Matt's Bar での写真です。

mattsbar.com

次はおそらく、名古屋 Ruby 会議 04 のことを書きます。

regional-gh.rubykaigi.org

RubyKaigi 2019 で発表しました日記

みなさんお疲れ様でした。今は飛行機の中ですのくだりで書き始められた形跡がありますが vim で書きかけのままもう木曜日でした。

blog を書くまでが RubyKaigi 。ということで、日記を書きます。

僕は 2 日目 14:20 からの枠で、須藤さんと CSV に関する発表を、2 日目 afternoon brake の直前の枠で、RubyGrant 2018 で開発した Charty に関する発表をしました。

今回の発表にあたっては、書いてきたコードはもうあるので、自分と、一緒に登壇する須藤さんと、聞きに来てくれた人達が楽しめて、あわよくば仲間が増えたらうれしいなーということを考えてやりました。

slide.rabbit-shocker.org

speakerdeck.com

vim で開きっぱなしのファイルにはなんか色々書いてあるけど、読んでも何言っているかよくわからない...。使える文章がまったくないので自分で書きますが、

なんだろう、closing で松田さんが言っていたと思うけれど、We code です。僕は前回の RubyKaigi からも幸いなことにコードを書き続けて生活してくることができました。これはラッキーだなと思っています。

福岡は非常においしい場所で、1 週間程度の滞在ではおよそ足りないという感じでした。良い場所を知ることができたし、また来たいですね。

で、来週は RailsConf に行ってきます。始めてです。次の月曜にはもう出発ですが、またそのことについてなにか書けたらよいなと思います。

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 など、過去の事例と共に)
要諦
絞り込む、目標はボトムアップで、押し付けない、常に柔軟な姿勢で、失敗を恐れない、手段であり武器ではない、辛抱強く決然と
ここまで2章

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]
4章まででそれらのもう少し詳細な話。
5章で、ケーススタディの話になった。一旦中断。

kazuma.furuhashi.284km [4:12 PM]
16:25 まで再開
6 章で印象的な部分は、「お願いだから OKR を作って!」と言い聞かせた。の辺り。社員から新のコミットメントを引き出すには、リーダーが率先垂範しなければならない。まず自分が示す。ということ。
7章は、会社全体の目標が定まった後の話。アラインメントについて強調している。
組織図と絡めた OKR の例があるので、イメージしやすいかもしれない。
上意下達で決まってしまった場合の弊害が生じるリスクとその説明。機敏性の欠如、柔軟性の欠如、コントリビューターが軽んじられる、組織の連携が一面的になる。
8章は、アラインメントに関するケーススタディ
9章は、垂直、水平的連携に関するケースすたティ
10章は、計測すること(進捗を)と、責任の明確化
「われわれは経験からは学習しない (略)経験を振り返ることで学習するのだ」とか
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 章はあとで2周めを読む。
13,14章で、ストレッチについてもう少し。と、ケーススタディ。ここがけっこう肝ですよね。と僕は思ってる。
15章から第二部。またあとで読む。中断。

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

kazuma.furuhashi.284km [5:06 PM]
再開。二部。対話、フィードバック、承認(CFR)(継続的パフォーマンス管理。を実践する手段)
何より重要んあこととして、OKR と CFR には相互に補強しあう性質がある。
人事評価精度のはなし、評定と目標管理を切り離す的なはなし。
CFRの踏み込んだ話。
承認は CFR のなかで最も過小評価され、最も理解されていない構成要素。
16章、年次勤務評定を廃止するというアドビのケーススタディだった
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とか見直してみようかな。
追加のリトマステストは、なるほどという感じがある。
参考資料2は、標準的なOKRサイクル。
参考資料3 パフォーマンスを話し合う
この辺も苦手というか面倒くさがるのでちゃんとしよう。という感じだなー。
参考資料4 まとめ、参考資料5 参考文献。で完。
本は 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