roppongi.rb #3 "Rails x Frontend-Tech" まとめ

Speee技術顧問の id:gfx です。 2017/05/31 に Roppongi.rb #3 開催のためSpeee Loungeを提供いたしました。私も「RailsエンジニアがReactを始めてSSRとReduxを導入するまで」と題した発表をしましたが、普段使っているReactベースの環境とはまたったく別のAngualrやRiotなどの話を聞けましたし、大変すばらしい勉強会だったと思います。

セッション

オープニング by toshimaru

オープニングでは、主催者の @toshimaru_e さんからの挨拶に変えてRailsフロントエンド技術の今とこれからについてのエントリの紹介がありました。

Railsフロントエンド技術の今とこれから - Hack Your Design!

Rails x Frontend は今後ますます重要になっていく技術なので、上記エントリはいいまとめですね。

RailsエンジニアがReactを始めてSSRとReduxを導入するまで by gfx

私の発表で、最近のKibelaのフロントエンドで実践していることについて話しました。詳しくは次のエントリをご覧ください。

登壇エントリ: Roppongi.rb #3 で「RailsエンジニアがReactを始めてSSRとReduxを導入するまで」という発表を行いました - Bit Journey’s Tech Blog

社内で初SPAをAngularで完成させるまでとその後 by hatappi

弊社のエンジニアである@hatappiさんによる発表で社内でAngularでSPAを作成した話でした。 詳しくは次のエントリをご覧ください。

『社内で初SPAをAngularで完成させるまでとその後』という話しをRoppongi.rbで話してきた - hatappiのブログ

Universal JavaScript by mizchi

mizuchiさんによる発表でした。Sprocketsの殺し方やこれからのJavaScript bundle技術の行く末などに関するお話でした。nativeのES modulesがブラウザに実装されるとwebpackが廃れてるだろうという予言は私も同意します。

Universal JavaScript // Speaker Deck

片手間JS on Rails by tricknotes

tricknotesさんによる発表でした。フロントエンドのビルドツールは多様過ぎるし進化も早すぎるというのはよくいわれることですが、作るもの次第ではRails標準のSprocketsもそんなに悪くないよという話でした。実際のところ、KibelaでもSprocketsはまだまだCSS周りでも使ってますし、適材適所というのは本当にそのとおりだと思います。

片手間JS on Rails

そのSPA、本当に必要ですか? by nishaya

弊社エンジニアのnishayasさんによる発表でした。nishayaさんもSpeeeのエンジニアです。SpeeeのエンジニアのひとりはSPAを作った話をし、もうひとりは無闇にSPAにすべきでない話をするという結果になりました。攻めてますね。もっとも、「軽い気持ちでSPAに手を出さない」というのは私も同意します。

そのSPA、本当に必要ですか? // Speaker Deck

ReactをやめてRiotに移行した話 by pompopo

pompopoさんによる発表でした。Reactはデザイナとの協業が難しけどRiotだとデザイナに抵抗感少なく触ってもらえるというのが移行の理由ということですが、確かにそのあたりはReactの課題だとは思います。Reactを使い続ける場合でも、React Storybook のような仕組みを整備して抵抗感なく触ってもらえるなどの工夫が必要かもしれないですね。

ReactをやめてRiotに移行した話 // Speaker Deck

【PR】Speee Loungeについて

SpeeeではラウンジをIT技術に関する勉強会や交流会のために貸し出しています。詳しくは次のエントリをご覧ください。

Speee Lounge 会場貸出について - Speee DEVELOPER BLOG

勤怠打刻機をRaspberry Pi 14台で本気で作ってみた

こんにちは、プロジェクト推進室でエンジニアをやっている 山本 (id:bino98) です。

毎日のお勤め、お疲れ様でございます。皆さまが、日々の業務を行われる合間に

  • 有給休暇を取得したり
  • 遅刻の連絡をしたり
  • 出張の申請を行ったり…。

様々な場面で自身の勤怠をその組織のやり方で管理されていると思います。弊社では、今年4月初頭から 社内で開発した新しい勤怠管理システム「 SpeeePORT 」による勤怠管理が始まりました。

弊社の新しい勤怠管理システム(以下、PORT)に関する詳しい記事は、ITproさまがこちらの記事にまとめてくださいましたので、ご覧頂けますと幸いです。

今回、PORTの ウリ の1つの 打刻機 について、まとめました。Raspberry Pi で打刻機を作りたいという、結構ニッチな要求を持つ方のお役にたてれればと思います。

Raspberry Piで打刻機を内製した経緯

こちらの記事にあるように、打刻忘れの問題は以前から発生していました。PORTを利用前の勤怠管理システムでは、出勤・退勤打刻をWebブラウザ上で行う必要がありましたが、その存在は忘れられがちだったのです。

打刻が忘れられないように、ICカードによる打刻の実現が社内で強く求められ、 アップデートされてきた弊社の新しい勤怠制度に適合できる勤怠管理システムを内製で開発することとなりました。

Raspberry Piを利用した理由は、

  • 安価で入手容易である
  • 自分たちの用途に応じてカスタマイズできる
  • PasoriとRaspberry Piを連携された事例がインターネット上に存在する

などの理由で使用することを決めました。

打刻機の利用方法

まず、打刻機の種類の話からですが、PORTでは2種類の打刻機を用意しています。1つは、打刻機。 f:id:bino98ty:20170605101952j:plain

もう一つは、打刻登録機です。 f:id:bino98ty:20170605102119j:plain

打刻機を利用して、勤怠打刻を行うためにはユーザには下記のフローを実施してもらいます。

  1. 個人や会社で利用している 交通系ICカードを用意 してもらう
  2. 打刻登録機 にICカードをタッチしてもらう
  3. 画面にQRコードが表示されるため、手持ちのスマホ等で読み取ってもらう
  4. 読み取ると、カードの登録がされる*1ため、あとは 打刻し放題 になる

打刻登録機はカード登録時に必要ですが、頻度はきっと多くないはず。普段使いの打刻にはディスプレイもキーボードも不要ですね。故に、普段は極力小型で、低コストで量産できるRaspberry Piを用いた打刻機を利用してもらっています。

ピッとすると打刻される仕組み

f:id:bino98ty:20170605110135p:plain

打刻機と打刻登録機は実は使用しているアプリケーションは同じです。まず、Pasori*2を利用するためのライブラリnfcpyをPythonを利用した読み取りプログラムを記述し、そのプログラム上でPORTのAPIに打刻リクエストを送信します。カードが未登録の場合はその旨のレスポンスが返ってくるため、打刻機側でそれを解釈し、同一リクエスト内に含まれるワンタイムURLをQRコードにして、イメージファイルとして保存しておきます。打刻機の場合は、ここまでです。

打刻登録機の場合は、発行されたQRコードを表示するためのプログラムも起動しており、node + expressで動かしてます。nodeでは、QRコードが保存されるディレクトリを常に監視し続け、ファイルに変更があれば(すなわち、QRコードが新たに発行された場合)画面を再描画するような仕組みになっています。

十数台の打刻機があるとたまにサボるやつが居るものだ

Raspberry Piを用いた打刻機ですが、不意に停止してしまうことがあります。例えば、

  • WiFiとのコネクションが切れたまま、復旧せず打刻できなかったり。
  • 一定以上使われないと勝手にプロセスが閉じて打刻できなくなったり。

打刻をするタイミングは朝出社前がほとんどであり、その時間帯に「 打刻機動かんけど、どうなってるの? 」などとお問い合わせを受けると、なかなか辛くてお腹が痛くなると思います。

そこで、PORTの打刻機には監視プログラム、自己診断送信プログラム、再起動プログラムの3つの仕組みを作って対応しています。

監視アプリケーション

監視プログラムでは、読み取りプログラムと表示プログラム、自己診断送信プログラムの3つのプロセスが生きているかを監視し、生きていなかった場合再起動させます。これによって、例えばプログラムに不調が出ても、「Pasoriを一度取り外してもう一度打刻機に接続したらプログラムが正常に動く*3」状態を実現でき、万が一朝に問題が合っても利用者自身で打刻機のプログラムを再起動できるようになっています。

自己診断送信プログラム

自己診断送信プログラムでは、プロセスの状態やインナーIP、GitHubのリビジョンなどを定期的にAPIに送信し続けます。PORTには打刻機監視画面があります。その画面に、このプログラムから送信されてきたデータを基に打刻機が稼働しているか、異常が発生しているかの診断を行い、画面に表示させています。

f:id:bino98ty:20170605112625p:plain

万が一、打刻機が停止している場合は、Slackにその旨のアラートを飛ばし、山本が飛んで直しに行きます。

再起動プログラム

再起動プログラムでは、1時間に1度、読み取りプログラム、自己診断送信プログラム、表示用プログラムの3つを終了します。長時間プロセスを起動し続けると、時たまゾンビプロセス化するプログラムがあるため、定期的に終了しています。しかし、上記の監視プログラムがプロセスを監視しているため、自動で再起動します。

ユーザにどうやって打刻成否を伝えるか

打刻機にはディスプレイがないが、どのように打刻の成否を伝えるか。肝は です。スピーカーはディスプレイよりはるかに安価に調達できますし、打刻機から返されるレスポンスは、ディスプレイほどの情報伝達力を必要としない量のため採用しました。

スピーカーは、100均のモノラルスピーカーを利用するか、 アンプ内蔵のお手製スピーカー を利用します。100均で売られているスピーカーを使うと、Raspberry Piから音を最大音量で出力ししても、ちょっと音が小さいのです。そのため、アンプ内蔵のスピーカーを打刻機を設置する場所によっては採用しています。

アンプ内蔵のスピーカー

安価なアンプ内蔵のスピーカーは、その当時調べた限り、見つけることができませんでした。なので、こちらのパワーアンプキットと、こちらのスピーカーを調達し、自前ではんだ付けし、使っています。現実的な音量になるため、全ての打刻機をこのタイプにしたいのですが、できればはんだ付けしたパーツは使いたくないところ…(打刻機運用の引き継ぎのハードルが途端に上がる)。アンプ内蔵のスピーカーを探しているところです。

f:id:bino98ty:20170605114147j:plain f:id:bino98ty:20170605102237j:plain

音のユーザ体験

また、打刻音にもこだわりが。

当初、打刻音は 打刻成功時に一度「ピッ」となるだけ でした。しかし、打刻成功時だけではレスポンスが帰ってくるまでの1〜2秒を長く体感される方が社内には多く(と思うと、鉄道の改札機ってマジリスペクトするぐらい早く ピッ となってくれますよね)、API側でリクエストの負荷のかかる部分をメッセージキューイングさせ、応答時間そのものを早くしたり、プレ打刻音をならしたりして、ちょっとずつユーザ体験の質の向上を実施してたりします。社内で作っていると、すぐにユーザの反応を受け取れるので、やりやすいです。

無機質な電子工作感を脱したい

また、Raspberry Piをそのまま執務室エリアに置いておくと、いかにも電子パーツ感があるため、インテリアしづらいと思います。その電子工作感をなくすため、また100均でケースを買い込み、スプレーニスと電動ドリルで箱を作ってケースを作ったりしました。

f:id:bino98ty:20170605115817j:plain

チーム内でダサいという意見が頻出したため、このケースは採用されませんでした。 レゴでケースを作ったり、3DCADでモデリングしてたりしますが、まだどうするかは未定です。(Raspberry Piを包み込む人形を作るのはどうかという話もあります)

まとめ

内製で勤怠システムを作ったり、打刻機を制作することで、より弊社のニーズに合うプロダクトを作ることができ、ユーザが近いのですぐにその反応も伺えます。もっと簡単に勤怠管理できる日を目指して、引き続き改良を進めていきます。ご覧いただきありがとうございました。

*1:QRコードはカード登録用のワンタイムURLを発行しています。読み取ると、PORTにログインしているユーザのカードとして登録される仕組み

*2:PORTで利用しているICカードリーダー

*3:Pasoriを外すと例外を吐きプログラムが終了するようになっているため

Speee Lounge 会場貸出について

こんにちは!エンジニア組織推進室の中野です。
今回はSpeee Loungeの会場貸出についてブログを書いてみました! 普段私たちは、自社イベントもくもく会などでLoungeをフル活用しています。また、貸出をして少人数の勉強会から大規模なイベントまで多岐に渡って利用いただいてます。
参加・利用していただいた方より、「居心地がよかった」、「十分なスペース、設備があって使いやすかった」などご好評の声をいただくことが多くなり、せっかくだから積極的に貸出をしていこうと思い、今回ご案内をさせていただいております!
※Loungeでは様々なイベント・勉強会をやっているのですが、ここでは"エンジニア向け"の勉強会やイベント利用に限定して、話をさせてもらいます。

Speee Loungeについて

2015年12月に、社内外の"知"が集まるコミュニケーションスペースを創りました。
目的としては、仕事をしたり、社内外の打ち合わせをしたり、コーヒーを飲んでリフレッシュしたり、書棚にあるたくさんの本を読んだり、様々な用途においてLoungeを活用することで意図しない偶発的なコミュニケーションを増やしたいという思いがあったからです。
また、"知の共有場所"となるよう、社内向け/社外向け問わずイベントを実施したりと、"オープンなコミュニケーション"を通じた知の共有を目指しました。
詳しくは下記記事をご覧ください!

cd.zeroin.co.jp

雰囲気

コーヒーの香り漂うゆったりとした空間となっています。多種多様な書籍が所蔵されており、BGMがかかっているため、カフェにいるような感覚です。

f:id:kana-nakano:20170411133521j:plain

会場キャパ

MAX100人程度でしょうか。前スペースには70~80名程度、ソファが並ぶスペースには20~30名程度入ります。こんな感じです。

f:id:kana-nakano:20170411134345j:plain

使用条件

  • ITや技術がテーマの勉強会、交流会などの目的でご利用下さい。
    • その他のテーマでのご利用希望の場合はお問い合わせ下さい。
  • 原則22:00撤収
    • 22:00を超えるイベントの場合はお問い合わせ時にご相談ください。
  • 会場設営や現状復帰にご協力下さい。

できること

  • 飲食物の持ち込み(アルコールも可)
  • Wi-Fi、電源、プロジェクタ、MAC用コネクタ、マイク、演台の貸出
    • マイクは4本、可動式スライド2台、天吊りディスプレイ6台までご用意出来ます。
  • 自由なレイアウトでの会場設営(ソファは原則動かせません)

過去Lounge利用例(一部)

Q&A

  • 申し込み・問い合わせはどこからすればいいですか?

    • 右記リンクからお願いいたします。Speee Loungeの勉強会の会場 | Doorkeeper
      ※9/26更新 利用貸出の依頼が多数のため、一時受付を停止させていただきます。ご了承いただきますよう宜しくお願い致します。
  • 事前に見学はできますか?

    • はい、事前見学いただけます。上記リンクからお問い合わせ下さい。
  • 本当に無料なんですか?

    • 無料で貸出しております。飲食物等の手配は、運営者様にてお願い致します。

最後に

Speeeは技術が好きで、技術力をもっと伸ばしていきたい、技術で世の中を変えていきたいという意思や野望を持った人を応援しています!そんな方々にSpeee Loungeを活用していただき、会場提供・利用という枠を超えて、交流や情報交換が活発に行われるエンジニアコミュニティが形成される場所のひとつがSpeee Loungeだったらいいなと思っています。
ご連絡・ご相談お待ちしてります!

DataScience.rb ワークショップを開催し、PyCall を用いたデータ解析の実演をしました

開発部 R&D グループの村田 (mrkn) です。

2017年05月19日、Speee Lounge で DataScience.rb ワークショップ 〜ここまでできる Rubyでデータサイエンス〜 を開催しました。 f:id:mogmog2:20170522144449j:plain

このワークショップは当初、私が2016年10月から取り組んでいる PyCall の開発 *1 と、Ruby アソシエーション開発助成の支援の下で実施された西田さん、三軒家さん、芦田さんによるプロジェクトの成果報告のために企画されました。そんな中、クリアコードの須藤さんが2017年2月頃から Apache Arrow の Ruby バインディングを開発する Red Data Tools プロジェクトを開始されました。Apache Arrow は2016年頃から開始されたプロジェクトで、私は当初から Ruby の将来にとって重要な基盤になるはずだと思い注目していたこともあり *2、Red Data Tools プロジェクトの進展には期待をしています。そこで、私から須藤さんにお願いして Apache Arrow と Red Data Tools の話をして頂くことになりました。

ワークショップの全体の流れは次のようになりました。

最初に、このワークショップの位置付けについて説明しました。私は、2016年から2017年初めにかけて、カンファレンスで何度か「Ruby はデータサイエンスでは使えないプログラミング言語である」ことを強い表現で説明してきました。このようなネガティブな話をし続けていても Ruby がデータ解析で使えるプログラミング言語になるわけではないので、私はこのワークショップを起点に、ネガティブな話をせず開発を前に進めていくことに注力したいと考えていました。そこで、オープニングで「今日を Ruby でデータサイエンスをやっていく日々の始まり」にするために、次のことを宣言しました。

  • Ruby をデータサイエンスで使えるプログラミング言語にしていこう
  • ネガティブな話はもうやめよう
  • 過去や現在に囚われず、粛々と開発を進めよう

f:id:mogmog2:20170522144502j:plain

そして、Ruby をデータサイエンスで使えるプログラミング言語にするために3つの道があることを説明しました。

  1. 巨人の肩に乗る
  2. 既存の gem をなんとかする
  3. Ruby のための仕組みを整えていく

ワークショップ当日のコンテンツは、これら3つのそれぞれについての現状報告でした。オープニングの後、次の順にそれぞれ発表とデモを実施しました。スライドや Jupyter notebook ファイル、関連ブログ記事へのリンクを記載したので、当日参加されていて復習したい方も、参加できなかった方も合わせてご覧ください。

  1. 巨人の肩に乗る ⇒ 村田賢太「PyCallを使ってRubyでデータ解析をやってみよう」 [slide] [jupyter notebook]
  2. 既存の gem をなんとかする ⇒ 西田孝三、三軒家佑將
「Ruby Association開発助成で得た知見の共有と今後」 [slide] [jupyter notebook]
  3. Ruby のための仕組みを整えていく ⇒ 須藤功平
「RubyもApache Arrowでデータ処理言語の仲間入り」 [slide] [blog]

DataScience.rb は今後も開発の節目ごとにワークショップを開催していく予定です。私たちの取組に賛同し、開発に協力してくださる方は、SciRuby の Slack や Red Data Tools の gitter に参加してください。利用事例の報告、バグレポートなどお待ちしております。

Ruby をデータサイエンスで使えるプログラミング言語にしていく活動を、今後ともよろしくお願いいたします。

*1:2016年12月〜2017年3月まで、しまねソフト研究開発センターさまに支援していただきました

*2:将来的に daru のバックエンドに採用したいと思ってこのような issue を作ったことがあります

ECSを使ってPR毎に確認環境を構築する社内ツールをOSSで開発してます!

 Speee開発基盤部、兼ヌリカエエンジニアの森岡です。 今回は、ECSを使ってPR毎に確認環境を構築する社内ツールであるwebapp-revieee をOSSとして公開しましたので、そのご紹介をさせて頂きます。

作ったもの

f:id:selmertsx:20170515113712p:plain

 PRを作ると、そのPRに対応した確認環境がECS上に構築され、PRに構築した確認環境にアクセスするためのURLがコメントされます。 ここで構築された確認環境は、PRがcloseされると一緒に閉じられます。主にデザイナの画面確認や、制作物のPOレビューなどが捗ります。 この社内ツールは一つのプロダクトだけでなく、社内のすべてのプロダクトの確認環境を用意することが可能です。 この社内ツールは、Webapp Revieeeという名前で開発されました。

作った理由

 今回このような社内ツールを作った背景として、確認環境の構築に時間的、金銭的コストを掛けたくない。 という理由があります。私が所属しているヌリカエというプロダクトにおいても、 確認環境がいくつか存在しています。しかもそれらの環境は、常に誰かが利用していて、 順番待ちが発生することが少なくありません。

この問題を解決する外部サービスとして、Heroku review appsというものが存在します。 当初このサービスの利用を検討したのですが、下記の理由で断念しました。

  • Elasticsearchなどのミドルウェアのバージョンを指定できない
  • 他のdynoと直接通信できないため、microservices の確認環境を構築できない
  • 本番環境ともローカル環境とも異なる環境なので、Heroku特有の問題に悩まされることがある
  • Enterpise でなければ、IP制限を入れることができない

 また、OSSでもdtan4 さんが開発されているpausというものがあります。 こちらは docker swarmを使ってEC2上で動いているのですが、docker swarmのクラスタ管理が手間であったり、 containerのログ取得が出来ないといった問題が存在します。 現在ではECSやGKEを利用すれば、この問題に対応できそうだったので、僕たちは自作するという選択肢を取りました。 そして下記の理由からECSを採用しました。

  • GKEとECSでは、実現できる機能に大きな差異は無い
  • 弊社ではGCPよりもAWSを利用しているプロダクトが多い
  • ユースケースを踏まえて料金を見積もったときに、AWSの方が20%ほどやすかった

Webapp Revieeeの使い方(理想)

 Webapp Revieeeは、社内のプロダクトで単純なrailsアプリケーションならば、 webhookを受け取るためのbotをリポジトリに招待するだけで使えます。 また、ユーザーはdockerに対する知識が無くとも、簡単に確認環境を構築することが出来ます。

というシステムを作るという理想を持って、僕たちはWebapp Revieeeの開発を開始しました。

Webapp Revieeeの構成

f:id:selmertsx:20170510101103p:plain:w500

Webapp Revieeeの構成図を上に乗せます。Webapp Revieeeは、app server, nginx, ECS, mysql instance, ECRの5つの要素からなります。 各要素の役割について、コンテナのデプロイと、確認環境へのアクセスを例に説明していきたいと思います。

コンテナのデプロイ

f:id:selmertsx:20170510102443p:plain

  • app_serverは、GitHubにてPRが作られた際にwebhookを受取ります
  • app_serverはPRが持つbranch情報を、起動するtaskに渡し、ECSのinstanceにデプロイします
  • containerをデプロイした ECS instanceのIPと、containerのport番号を MySQL に保存します。
  • 確認環境にアクセスするためのURLをGitHubの該当PRにコメントする

上記操作によって、確認環境がECS上に構築されます。 このとき、コンテナのentrypointは下記のようにしています。

f:id:selmertsx:20170510101214p:plain

タスク起動時にPRのbranch名を渡すことによって、任意のbranchでコンテナが起動するようにしています。

確認環境へのアクセス

f:id:selmertsx:20170510102456p:plain

  • ユーザーは、GitHubのPRにてコメントされる確認環境のURLにアクセスする
  • nginxはURLに該当するcontainerのアクセス情報をMySQLから取得して、ユーザーをそちらに流す

nginxからMySQLへのアクセスにはluaを使っています。

Webapp Revieee の使い方(現状)

  • Docker Imageを作成しECRに登録
  • Task Definitionの設定ファイルを作成
  • GitHubリポジトリにbotを招待
  • PRを作成

 現状では、Docker ImageのECRへの登録をユーザーが行うようにしています。 理由としては、開発環境で必要な MySQL等の初期データ投入等、プロダクト側でImageの更新をハンドリングしたいからです。

 Task Definitionの設定ファイル作成もユーザーにやって貰っています。 Docker Imageを作成する課程で、ほぼほぼ docker-compose.ymlを作ってもらえているはずなので、 そのdocker-compose.ymlを元にecs-cliを使って、Task Definitionを作る方法もあります。 しかし、今回は下記の理由により直接書いてもらう方法に落ち着きました。

  • ecs-cli compose は現状では、docker-compose のver3に対応していない
  • memory制限やlogging driverの設定など、docker-composeの設定を手元とECS環境で書き分ける必要がある
  • 自動化する前に素朴な仕組みで実現し、データを集めることで自動化するべき方向性を見極めたい

そこまでユーザー側が設定を完了させたのちに、botをGitHubリポジトリに招待して貰うことによって、本サービスは利用が可能となります。

今後の展望

僕たちのWebapp Revieeeは、ようやく社内で利用され始めた段階です。 現状ではまだまだ荒削りな状態で、運用や設定において手間であったり、 痒いところに手が届かない部分はあるかと思います。 今後は、僕たちのサービスを使ってくれる現場の声を聞きながら、自動化するべき点は自動化し、 エンジニアがいじりたいところはいじれるようにし、より便利に使ってもらえるように開発を進めていきたいと考えています。

同時に、Webapp RevieeeはOSSで開発しておりますので、アプリケーションのコードだけでなく、 本システムを構築する上で必要な設定も、どしどし公開していきたいと考えています。 Webapp Revieeeに対する要望やコードのイケてない部分、より良い実装方法等ありましたら、issue等で教えて頂けると幸いです。

最後に

本OSSはクリアコードの須藤さんに見て頂きながら、開発を進めていきました。 そのときの様子などは、クリアコードさんのOSS開発支援サービス事例の記事 にも記載されておりますので、そちらの方を参照下さい。

須藤さんには、OSSとしての開発の仕方だけでなく、適切なコミットメッセージの書き方、 コードレビューの仕方、Rubyでの設計など、様々な方面でご指導して頂きました。 本当にありがとうございます!