なんか書いていこうぜー .com

minami.rb が終了する というので、最初で最後のLT大会 に LT 申し込んで参加してきました。

雰囲気

終わるとかいう悲観的な雰囲気は一切なく、同窓会的な雰囲気のある感じでした。

特に何も持ってくる必要はない、と言われつつも、みんなおやつを持参してくるのが実に minami.rb っぽい。↑これが全部ではなかった…

参加者は、大阪で開催しているにもかかわらず兵庫、和歌山、神奈川、東京などから来ているという幅広さ。

会場は、糸屋町STUDIO というところで、もともと写真撮影に使うスタジオらしいのだけれども、こういう感じのイベントにも提供をしているんだそうな。

前半戦

一発目の発表者が遅れてくる(後半戦に結局やった)というハプニングが発生しつつ、飛ばして順番に LT をしていくスタイル。今回は 5 分は目安ということで進行していきました。

自分語りや、minami.rb の思い出・成長記録、テックトーク、エバンジェリストの活動報告などなど皆々様思い思いの LT を実施しておりました。

↓ 私の発表はこれ。

前半戦の〆として、辻田さんの LT。 minami.rb の歴史を振り返ってこれまでにやったことなんかを発表されておりました。

酒・飯

後半戦に入る前に、酒・飯です。これも minami.rb らしいところなんですが、日本酒を主として参加者がこんだけ酒持ってきました (全部は呑みきれませんでしたけどね)

他にも寿司とか、おでん、お手製のオードブル、(酒呑みらしく)漬物 などなど。 (料理もっと撮影しておけばよかったけど、忘れてた。。)

かなりみなさんご歓談しておりまして、後半の開始が遅れておりました。

後半戦

だいぶ酒入ってきたので、ゆるい感じになりつつ、LT を再開。 コミュニティに対する活動報告や、Rails を勉強してつまずいたところの復習、Rails で解決させた悩み、mruby の話や、3 分クッキングまで多種多様の楽しい LT がありました。

↓ 5 分の LT で、3 分間クッキング(例のBGMつき) をやってできたナポリタンを振る舞った跡

ファウンダの一人である、よしださんのモチベーションと学習方法についての LT で後半戦は終了となりました。

〆

後半戦があった後、食べ物、飲み物を胃の中に入れる時間があったので、みんなで食べ飲みしてました。 21 時に会が終了ということで、最後に辻田さんからお言葉をいただいて〆となりました。

最後に、minami.rb を終了する理由について語られて(後日ブログに書くとのこと)、参加者・関係者の皆様に感謝の言葉を述べられて終了となりました。

会場の片付けをした後、出口でメッセージつきのお菓子をいただきました(写真は控えます)

最後に

辻田さん、吉田さん、minami.rb の運営お疲れ様でした！

私含め、たくさんのメンバーが minami.rb に参加して、minami.rb から Ruby, Rails, お酒(w), その他技術やコミュニティに関する刺激を受けたと思います。 minami.rb は終了しますが、活動が止まるお二人ではないと思いますので、今後のご活躍をお祈りしつつ、応援しております。ありがとうございました

昨日、DeNA さんの若手(1年目の方々)と弊社アジャイル事業部の有志で LT 交流会がありました。

当日の tweet まとめは基調講演を行った @yucao24hours がまとめた こちら。

ここで 地域コミュニティのススメ というタイトルで LT しました。

もともと、取りまとめをしていた @takkanm から「コミュニティ」の話をしてほしい、と言われていたので、どうしたものか と考えて、基調講演と内容が被らないように唸りながらひねり出したのがアレです。

また地域 Ruby 会議ススメルおぢさんな感じになっているのですが、そこはご容赦を

資料つくって思ったこと

自分のこれまでを考えたときに、いろいろな地域の地域 Ruby 会議や RubyKaigi、勉強会みたいなイベントに参加してきたけど、 結局は「イベント」というよりは、その場で会ったり、話したりした「人」が印象に残っているなぁ、と思いました。

「つべこべ言わずにコード書け！」と言われると間違いなくそうなんですが、楽しんでそうしたいし、続くかたちでそうしたい。 そんなときに、コミュニティに頼ってもいいんじゃないかと。ライバルや師匠がいたほうが刺激があってよいし、刺激を与える側 になると、反応があったほうが楽しい。

Github みたいなリポジトリを中心にしてテキストのやりとりでも実現できるかもしれないけど、直接会って話したほうが伝わるし、 自分の思っていることも伝えやすいと思います。日常生活でも仕事でも、システム作っていても相手は人なので、人と交流して おくことは重要。全く関係ない人といきなり交流するよりは、同じようなものに興味のある人同士で交流したほうが楽で楽しい じゃないですか (休日は低機動型寝たきり二時間サスペンス廃人な私が言うことではないのですが…)

こう書くと、「頼る」だけな感じになってしまうのですが、恩返しというか**「刺激を返す」ことが最も重要**だと思います。

発表の内容はコミュニティ、イベントに頼る内容になってしまっているのですが、コミュニティやイベントが存続し続けるかと いうとそうではないんですよね。イベントが続くのは、参加者からの刺激があるから、主催者が刺激を受けられるから、というのが 大きいと思います。義務感や惰性だけで続けられるほど楽なものじゃないです。「刺激を受ける」側にいるだけじゃなくて、 「刺激を与える」側に回らないと、イベントやコミュティ自体が絶滅してしまう可能性だってあるんですよね。

いつまでもあると思うな、イベントとコミュニティ。続いている間に恩返しができるように、自分が成長できるように頑張らねば ならない、と思ったのでした。

(結局恩返しするために、コード書けよ、という話になるのか…)

さて、普段の仕事で HTTP status code とその意味が知りたくなったときに Wikipedia なんかをよく検索しにいくので、ローカルで検索できるように Rakeタスクにしてみた。

きっかけ

きっかけは、仕事で状態の更新タイミングによって遷移できない状態に陥った時に、なにかよい status code がないものかと探したことだった。 かねてから gem 作りたいという欲求もあったので、いきなり難易度高いものでなく、地味に役に立つものを作ろうとして着手してみた。

リポジトリは こちら

ハマったところ

以下の2つ。

1. Rack から status code とその説明が書かれた Hash はすぐにみつけたが、404 と :not_found を対応付けた定義があるところが見つからなかった。
2. Rails から使うときには、Rails::Engine を継承しないといけない、というのに気がつくのが遅かった。

1 のほうは、実は status code と説明が書かれた Hash の下に、その Hash から生成して定数にしているところがあったのだが、:not_found とかそういう文字列で検索していたので引っかからなかったのであった。

2 のほうは、意識してなかったというか、Rails 用の gem を作り慣れていないのがもろバレである。なんか似たような gem 探してソースみたらすぐわかったので、助かった。

折角作ったので活用していこうと思うけど、そんなに HTTP status code 直接使う作業って今のところないんだよ…API 作るときには活躍しそうな気がする。 あともうちょっと綺麗にしたい。

実は今年に入ってから、どこでもシート というのを壁紙に貼ってカンバンとして使っている。計画を遂行するために！とか大げさなものではなく、単なるTODOリスト・物忘れ防止に使い始めたのだが、思ったより役に立っている。

特に、月末日にふりかえりとしてカンバンの内容をもとにKPTを書いて翌月のふりかえりまでずっと貼っているのだが、これの効果が高い。

↓は2月のKPT。

日々を何気なく過ごしていると、何をやったかよく覚えてないし、やらないといけないことも忘れてしまってなんとなくやってたんだけども、カンバン使い始めて自分が頑張ってたのかサボっていたのかがいい意味でも悪い意味でもすぐわかるようになった

毎日見る壁に貼っているので意外に意識する。強制力はないものの気にして壁見るのである程度の強制効果はあるみたい。

ふりかえりも併せてやっていると前月の自分という比較対象ができるので、ちょっとだけやらねば感が増す。

KPTの結果を1ヶ月貼り続けているせいか、(続いてないものもあるけど)継続性が増している気がする。 実は1月にあげたKPTのTryに記録を残そうというのがあった結果、裏チャンネルでほぼ日で日記を書くようになった。まだ続いている。

これまではふりかえりをしてKPTを出して全員で共有して残す、ということまではしてきたけど、いつも見える場所に置いていなかった気がする。 前回やったこととか、問題として提起したものを次のふりかえりまで覚えていられる？と言われると、自信はない…逆に忘れている自信がある…

今回やってみてわかったことは、KPTをずっと掲示しておかないと人間目の前のことに必死になると以前にたてた課題を忘れるし何できてたかも忘れてしまう、継続して何かをしたり改善しようとするならば立てた課題や実施した成果をずっと見えるところにおいておいたほうが効果があるよ、ということだ。

KPT、常に見えるところに貼るとかどうっすかね？

何か作って勉強しないといけないな、と思ったので gem を作成してみる。

今のところはMySQL関連の何かを作ってみようかなぁと。ActiveRecordまわりをちょっと調べたいためです。

Gem を作るためにまず

bundle gem コマンドを打って雛形を作成する。ここらへんの手順については、パーフェクトRuby の 13章 gemパッケージの作り方 が詳しい。

作業をしようとしている適当なディレクトリで、bundle gem hoge コマンドを入力する。(hoge はgem名)

% bundle gem hoge
      create  hoge/Gemfile
      create  hoge/Rakefile
      create  hoge/LICENSE.txt
      create  hoge/README.md
      create  hoge/.gitignore
      create  hoge/hoge.gemspec
      create  hoge/lib/hoge.rb
      create  hoge/lib/hoge/version.rb
Initializing git repo in /home/muryoimpl/tmp/gems/hoge

もし、テストをrspecで書こうと思っているのであれば、bundle gem hoge -t とすると、spec の雛形まで作成してくる。

% bundle gem hoge -t
      create  hoge/Gemfile
      create  hoge/Rakefile
      create  hoge/LICENSE.txt
      create  hoge/README.md
      create  hoge/.gitignore
      create  hoge/hoge.gemspec
      create  hoge/lib/hoge.rb
      create  hoge/lib/hoge/version.rb
      create  hoge/.rspec
      create  hoge/spec/spec_helper.rb
      create  hoge/spec/hoge_spec.rb
      create  hoge/.travis.yml
Initializing git repo in /home/muryoimpl/tmp/gems/hoge

ちょっとgemspecを直す

gem を作成するためには、gemspec の内容を整える必要がある。

Gem::Specification.new do |spec|
  spec.name          = "hoge"
  spec.version       = hoge::VERSION
  spec.authors       = ["muryoimpl"]
  spec.email         = ["muryoimpl@gmail.com"]
  spec.summary       = %q{TODO: Write a short summary. Required.}
  spec.description   = %q{TODO: Write a longer description. Optional.}
  spec.homepage      = ""
  spec.license       = "MIT"

  spec.files         = `git ls-files -z`.split("\x0")
  spec.executables   = spec.files.grep(%r{^bin/}) { |f| File.basename(f) }
  spec.test_files    = spec.files.grep(%r{^(test|spec|features)/})
  spec.require_paths = ["lib"]

  spec.add_development_dependency "bundler", "~> 1.7"
  spec.add_development_dependency "rake", "~> 10.0"
  spec.add_development_dependency "rspec"
end

spec.name等は bundle gem コマンドを打った時に入っているはず。 author, email は git で設定しているものがすでに入っているはず。

spec.summary と spec.description にgemの説明を入れませう。

gemspec に依存関係を書く

下3行に以下のコードがありますが、このadd_development_dependencyは開発時に使うgemを書く。例えば、テストにしか使わない rspec は add_development_dependency に書く。

  spec.add_development_dependency "bundler", "~> 1.7"
  spec.add_development_dependency "rake", "~> 10.0"
  spec.add_development_dependency "rspec"
end

実際にgemを動かすために必要なgemは、add_dependency に記載する。 ActiveRecord と Mysql2 を使おうとすると、以下のように記述する。

  spec.add_dependency "mysql2"
  spec.add_dependency "activerecord"

  spec.add_development_dependency "bundler", "~> 1.7"
  spec.add_development_dependency "rake", "~> 10.0"
  spec.add_development_dependency "rspec"
end

だいたいこんなところで、準備ができているはず。

もし Github とかにソースを置くなら

bunlde gem コマンドが出力するものと、Githubでリポジトリを作成したときのものは少し違うので注意。

例えば、LICENSEはGithubは選択して出力できたりするが、bundle gem は MIT LICENSE が自動で出力されていたと思う。出力されるREADME の内容も違った。

bundle gem したもので構わないのであれば force push してしまえばいいし、いいとこどりをしたいのであれば、マージしてから push する。

すげー忘れるのが、README にある URL の変更だったりするので気をつけろ

1. Fork it ( https://github.com/[my-github-username]/hoge/fork )