ローファイ日記

出てくるコード片、ぼくが書いたものは断りがない場合 MIT License としています http://udzura.mit-license.org/

RailsGirls Fukuoka の準備を支えた技術

このエントリは、 pepaboアドベントカレンダー の10日目の記事です。1日遅れすみません! 前回は... gyugyuさん...

RailsGirls Fukuoka やりました。

さっそく本題ですが、今年7月に @murasakipinko さんと shiho さん、 vareal の寺本さん を オーガナイザーに、九州最初らしいRailsGirlsワークショップ、RailsGirls Fukuokaを開催しました。ペパボつながりでは、ペパボはRailsGirlsを継続的に支援している企業の一つとなります。

railsgirls.com

イベントレポートは以下も是非ご覧になってください!

blog.railsgirls.jp

この準備にあたって、福岡のアンクル事務(と言いつつ会計という一番苦手なやつはshihoさんにまかせっきりでしたが...)として、「準備の基盤づくり」に奔走していましたので、他の地域でこれから開催していくオーガナイザーの皆さんや、福岡でもう一度!という方のためにアドベントカレンダーの機会を借りてここに残しておきます。


GitHubに「実況」をする

まずは、GitHubの活用についてです。

そもそも、日本国内でRailsGirlsを開催する場合、RailsGirls JPという組織が全面的にバックアップをしてくれます。そのためオーガナイザーは一番肝心な「どういうワークショップにしたいか」に集中しやすくなると思います。

そのバックアップの一環として、GitHubRails Girls Japan · GitHub オーガニゼーションの配下にプロジェクトを作ってもらえて、それを準備のために利用することが可能となっています。

RailsGirls Fukuoka 1stでは、このGitHubのプロジェクトを全面的に活用していきました。

具体的には、「やるべきこと」ごとにIssueを立ててならべ、その件に関して何かしたらなんでも(やったこと、思ったこと、困っていること)どんどん書き込んで実況していくというスタンスで利用しています。

f:id:udzura:20151211182014p:plain

これ、一時期に「分報」というのが流行っていましたが、それに近い感じがあります。

c16e.com

  • 自分が何をしているのか、書き下すことで冷静に整理できる
  • 状況を他のオーガナイザーやコーチにシェアできる

というメリットを重視した感じですね。

オーガナイザーの方は、必ずしもエンジニアではないので、ことGitHubとなると初めは面食らうと思いますが、最終的にエンジニアではない方々もちょこちょこと進捗をメモしていたように思います。

Slackを全力で活用した

他の地域の方々(最も参考にしたRailsGirls Tokyo含め?)はFacebookグループを使うことが多いようなのですが、今回はSlackを使いました。

Slackを使う上で最も重視したのは、その豊富な連携機能でした。いくつかの工夫を紹介します。

GitHubの通知

RG FukuokaのGitHubイシューについて、コメントなどは基本的に全部流すようにしていました。Slack通知のいいところは「タイムライン」として眺めて把握できるところかなあと思います。

doorkeeperのメール通知の共有

参加者募集はdoorkeeperで行いました(https://railsgirls-fukuoka.doorkeeper.jp/events/26233) が、募集状況や質問などにすぐ気づけるように、それらのメールを受信したらIFTTT経由でSlackに通知されるようにしました。

f:id:udzura:20151211183513p:plain

具体的には、doorkeeperに登録しているGMailで、以下のようなフィルターを作り、doorkeeperからのメールには全てタグ RGFukuoka をつけるようにします。

f:id:udzura:20151211193811p:plain

そして、そのタグがついたメールを、「特定のラベルを付けたメールをslackに通知」レシピを使ってSlackに流している、という感じです。

IFTTT Recipe: 特定のラベルを付けたメールをslackに通知 connects gmail to slackifttt.com

なお、この仕組みは、Slackのメール連携機能がリリースされる前に作った記憶があり、そのためIFTTTを挟むなど少し複雑になっています。doorkeeperのメールアドレスを他のものと兼用している場合などには使えるかと思います。

くじびきbot

おかげさまでたくさんの応募をいただいたため、残念ながら何名かの方を落選という形にしないといけませんでした。 公正になるよう、LitaというRubybotフレームワークを使い、Slack上で当落のくじを引く形をとりました。

f:id:udzura:20151211183451p:plain

今見ると、なんか方言間違ってますね......。

このbotソースコードは以下に公開しています。

github.com

Windows上で直接Ruby on Railsを走らせるのは、今回は諦める

RG Fukuokaでは、非エンジニアであるオーガナイザーの意見も聞いて、Windows環境で直接Ruby on Railsチュートリアルをするのは断念しました。

その代わり、VirtualBox上にUbuntu Linux(Desktop版)の環境を作り、そこで作業をしていただくという方針にしました!

一般的に、学習に必要な概念が増える(今回はPC仮想化であったり、VirtualBoxというツール)のは望ましくないので、他の地域ではWindows環境でのRoR環境の構築を選択していると思いますが、今回は、

  • PC仮想化という概念自体は理解していただけそうな生徒さんが多いこと(非エンジニアの方でも、IT系のサポートの職の方などが多かったです)
  • 難し目の手順が増えるWindows構築より、Linuxさえ立ててしまえばほぼ素直にデバッグできる方が結局トラブルが少ないのでは?と考えたこと
  • 非エンジニアであるオーガナイザー的にも、新しいツールに抵抗を感じないのではないかと思われたこと

結果として、ほとんど全員herokuなどへのpushまでたどり着いています。これはなかなかの成果だと思います。

一方で、純粋にマシンパワーが足りないような(「いんてるせんとりの」、と書かれていました...)Windowsラップトップをお持ちした生徒さんもいて、その方はかなり苦戦、というかいちいちレスポンスが遅くて大変だったようでした。

ほかにも、32bit版のWindowsの存在(Ubuntuも32bitになり、Atomが動かないとか...)など、ちょこちょこと困った点が出てきていました。

Nitrous のようなクラウドでの環境構築ができるツールの検証を進めても良かったかもしれません。

コーチ向けのマニュアル、地域の手順向けのマニュアルをつくる

上記にも関連して、幾つか自分たち向けのマニュアルを作ってみています。

公式のRailsGirls Guideも、もちろん生徒さんと一緒に見るものとして活用しますが、「教える側のメンタルモデル」に沿ったマニュアルがあると便利かなあということで、Guideを通した際に一緒にメモ書きしたものがその一つです。

もう一つ、Ubuntu on VirtualBoxの環境構築のマニュアルを @monochromegane さんの手で作ってもらいました。当日は大変役立ったそうです。

これらについては、公式ドキュメントや coach.info に順次共有するといいかな...と思いつつまだまだなのでした...

KPTについて

以上のように工夫をこらし、当日を迎えましたが、やはりどうしてもうまくいかなかった点、逆に存外良かった点などが出てきました。

KPTという形で後日まとめています。その一部はこんな感じです。

Keep

  • 番長制度(LLイベントの準備でやっている技を盗みました...)を導入し、お弁当番長、会場設営番長など、ざっくり役割を分担した。「担当」という感じではなくみんなで頑張る、けど一番がんばる人、ぐらいのニュアンスを「番長」という言葉で出せた気がする
  • 月一でリアルミーティングを開いたのは良かった
  • フリーコーチという形で、他地域のコーチ経験者を中心にグループに入らないで全体を見て回る係を用意した。いい感じのフォローができた気がする
  • オーガナイザー・コーチでなく、当日動ける人がいると大変ありがたい。今回は、 WANさん という学生団体の皆さんにお手伝いしていただいています。当日レポ

Problem

  • 1日目のインストール、終電もあるので、人によってはある程度で見切りをつけるのも必要だったかも。
  • Facebookなどでもいいが、「その場でコーチと生徒さんが情報共有できるオンラインツール」が欲しかった
  • ミーティングは、オーガナイザーなど企画を考える人とコーチとで別々に行っても良かったかも。コーチはあくまでコーチなので、直接関係ない話も多い......
    • 一方、コーチは人数も多くなるので、当日初めて顔をあわせる人が多いと困ってしまう。全体で集まる機会を事前に作れれば良かった?

Try

  • Google Docsなどをちゃんと使い、運営側の参加者リストも早めに用意する。
  • PC(Mac)貸し出しができないか考えてみる
  • FacebookグループでもOSSチャットツールでもSlackでもいいけど、当日のオンラインコミュニケーションツールがあると良かった。用意する。

他地域でも参考になるかと思います。

最後に

オーガナイザーの3人を始め、同僚でもありコーチとして全面協力をしてくれたmonochromeganeさん、ほかコーチとして様々な検証をしてくださったYukinari3poさん、E-Zuka Railsの主催者として、コーチのほか、コミュニティ的な観点で色々アドバイスをくださった谷口さんには大変お世話になりました。

また、個人的に日本のRailsGirlsの中心人物でもあると思ってるRG Tokyo 2nd(私が最初にコーチをした回ですね)のオーガナイザー、@yotii23さん、前職でもお世話になった藤村さん、Osakaのオーガナイザーでもある@satomicchyさんを始め、経験者の皆様に準備/当日ともに多くのアドバイスをいただきました。

マインド含め一番影響を受けているyotii23さんの地元、福岡でこうして開催できたのは感慨深いと思っています。

その他、スペースの関係で皆の名前を出せませんが、様々な方々の助けを借り、無事成功したと思います。ありがとうございました。


ということで駆け足となりましたが、RailsGirls Fukuokaを支えたかもしれない工夫などを紹介しました。

明日(今日...)は @kurotaky メンバーの記事です(そういえば彼もTokyoのコーチですね)!

雑にTOTPを試してみる

2要素認証でおなじみのTOTP。Railsなどでどう使えばいいか。雑に試す。

Gemfile

今回はrotpというgemと、二次元バーコード(QRコード、というと商標なのでポリコレな表記をしていr)の表示のためにrqrcode_pngを使う

gem 'rotp'
gem 'rqrcode_png'

TOTPを試す

コンソールで:

totp = ROTP::TOTP.new("hogehogefugafuga")                                           
#=> #<ROTP::TOTP:0x007fd5fad22850 @digest="sha1", @digits=6, @interval=30, @issuer=nil, @secret="hogehogefugafuga">
totp.now
#=> "241886"
loop { p Time.now; p totp.now; sleep 1 }
2015-11-27 18:26:50 +0900
"579205"
2015-11-27 18:26:51 +0900
"579205"
2015-11-27 18:26:52 +0900
"579205"
2015-11-27 18:26:53 +0900
"579205"
2015-11-27 18:26:54 +0900
"579205"
2015-11-27 18:26:55 +0900
"579205"
2015-11-27 18:26:56 +0900
"579205"
2015-11-27 18:26:57 +0900
"579205"
2015-11-27 18:26:58 +0900
"579205"
2015-11-27 18:26:59 +0900
"579205"
2015-11-27 18:27:00 +0900
"703388"
2015-11-27 18:27:01 +0900
"703388"
2015-11-27 18:27:02 +0900
"703388"
...

確かに1分単位で変わっている様子がわかる。

これをデバイスに送りつけるための二次元バーコードを生成。

url = totp.provisioning_uri "udzura@auth.udzura.jp"
#=> "otpauth://totp/udzura@auth.udzura.jp?secret=hogehogefugafuga"
png = RQRCode::QRCode.new(url, size: 10, level: :h).to_img
#=> <#ChunkyPNG::Image>
png = png.resize(200, 200)

ChunkyPNG、ファイルに書き出さなくても、data URLを吐き出すメソッドを持っているので便利。

png.to_data_url 
=> "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAMgAAADIAQAAAACFI5MzAAAEcUlEQVR4nO1Xv27iTBCfjZGW5jB0sWTHlngCOiNZsjue4+Me4DBpaL7YThqaGPIAl3sOOltC8nbUVyCtgyXoYpPGK2H2Wx4A5bT5ytvOGs14/v1mfnPDr70buPb+Sv5/CUdIRbnviY92HjJjmrYqhELZ/7g8SgBSYROcR9jd2RTxk7TXrMVHzktmTu1b5dlrjYkFqfWFHKDVegLrIGFNiOkrpn+ic13CR33DawLvUIxF3tgf6VyT4BOq9DHoQLjSy+gDOOBSaWspCrz162DftQ9aSZwjbgLUkrWGOC/xsMqaEm7hlcHSpirn0h0..."

表示されている様子です

この画像をGoogle Authenticatorなりなんなりで取り込んで、

loop { p Time.now; p totp.now; sleep 1 }

このループの表示と見比べて満足して今日は終わり。

Devise との連携

github.com

こういうのがあったが、果たして。

Nishitetsu.rb をやります。という話

以前より id:nagachika さんとやろうと言っていたミートアップ、今年ついにやります。

fukuokarb.doorkeeper.jp

ジョイナス

で、Nishitetsu.rbっちなん?

という方も多いと思うのでバックグラウンドを説明すると、

  • Tokyu.rb | Doorkeeper というコミュニティが東京にある
  • Tokyu.rbは、Tokyu沿線のRuby技術者がオフラインで集まって、お酒やご飯を楽しもう!というイベントとなっています というもの
  • 同じようなコンセプトのルビースト会合を福岡でもやりたいね
  • 向こうがTokyuならこっちはNishitetsuでは??

という感じです。Nishitetsuであれば、沿線はもちろん、福岡全土にバスが走っていますので、福岡だいたい全土のRubyistのご参加をお待ちしております。

今回は、Rubyらしく火鍋(会場も西鉄薬院駅近くですね)ですが、今後美味しいお店と聞けばNishitetsu沿線かバス停沿いのどこでも開催できればなあと思っていたりします。

ジョイナス

RubyWorldConference 2015 でOpenStack Ruby Wrapperの話などをした

話しました。

www.slideshare.net

111枚、なんとか収まりましたと言いつつ後半は早口...

書いてある通り、OpenStack Ruby Wrapper "YAO" と、その周りのツールたちとで、まずはペパボ周りの人たちのためのOpenStackエコシステムをOSSで作ってるみたいな話です。

github.com

バージョンも地道に 0.2.1 となり、対応APIも増えてきました。ロゴも、5人いるカレー四天王の一人 id:Horaotoko によるものを採用し、何だか勢いが出てきた感じします。

horaotoko.hatenablog.jp

この分野でセカンドシーズンをやり始めている経緯はスライドに書いてある通りです。ぜひご利用ください!パッチ、事例紹介もウェルカム!です。


松江、久しぶりだったんですが、街と自然が美しく、良いなと思いました。懇親会の食事も美味しかったです。まあ福岡もおいしいんですが。とにかく日本海最高です。

久しぶりに会うRubyist、ついにお会いできたRubyist、インターネットの妖精だと思っていた人にひょっこり遭遇する、などなど、出会いと再会に恵まれるイベントでした。

Let's use computer!!!

fluent-plugin-json_expanderというものを作ったんだ

github.com

やりたいこと

  • データとして流れてくるJSONの中身を見て、動的にアウトプットを編集したい。

こういうことができます

こういう設定を書いておく。

<match access.summary>
  type json_expander
  subtype growthforecast

  <template>
    gfapi_url http://127.0.0.1:5125/api/
    graph_path ${data[mothor_host]}/${data[vhost]}/${key_name}
    name_keys count_2xx,count_3xx,count_4xx,count_5xx
  </template>
</match>

すると、こういうデータが流れてきたときに、

// tag = access.summary
{
  "mother_host": "kvm001.udzura.jp",
  "vhost": "front.udzura.com",
  "count_2xx": 1234,
  "count_3xx": 567,
  "...": "..."
}

受け取って、内部でtemplateからこういうoutputを生成して、そこに流し込んでくれます。この場合はout_growthforecastに受け流す。

type growthforecast

gfapi_url http://127.0.0.1:5125/api/
graph_path kvm001.udzura.jp/front.udzura.com/${key_name}
name_keys count_2xx,count_3xx,count_4xx,count_5xx

オプションなど詳細は READMEをどうぞ。

背景、作ってみて思ったことなど雑感

hb.matsumoto-r.jp

松本リーなんとかさんがこういった検証を進めていて、その一環でぼくに"""圧"""がきたのでgrowthforecastの設定がより便利になるよう作った。もちろん、vhostごとに集約先のログファイル名を変えたい、しかも動的にやりたいんだ!!1、といった場合にも有効だと思う。

プラグインの製作の過程では、 id:tagomoris さんの先行実装、というかforestがめちゃくちゃ参考になった。感謝してもしきれません...。

github.com

このへんとかですね。

おかげで、Fluentdの内部実装にも若干詳しくなり、なるほど綺麗な設計だなと思うなどした。いつかまとめるかもしれない。。

制限事項

レコードごとに内部でアウトプットを作る(または使い回す)、という実装のため、いったんEventStreamとChainをその都度その都度ダミーで作って流し込む、という実装方針にしている。

このへんです

このおかげで、多分タグやレコードをつかけえてフォワードする系のやつがうまく動かないかもしれない。一方、先ほどのout_growthforecastのような、データの流れの終端となるようなoutput pluginはちゃんと動くと思われる。この辺り、もっといい感じの実装方針があれば是非プルリクいただきたいところ。

稼働実績

先ほどの記事の通り、 id:matsumoto_r さんの自宅サーバで動作している。なのでプロダクション投入されていると言って差し支えないだr

メモリが太りそうな感じもするけど、いまのところそういうことは起こっていない模様。人柱求む。


そんな感じで、今月めちゃくちゃコードを公開した気がする。。