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

Let's write something good

DeNAさんの若手の方々とのLT大会でLTした話

2015-03-26
  • Share on Facebook
  • Tweet
  • Add to Pocket

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

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

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

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

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

資料つくって思ったこと

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

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

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

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

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

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

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

http_status_task という gem を作った

2015-03-05
  • Share on Facebook
  • Tweet
  • Add to Pocket

さて、普段の仕事で 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 作るときには活躍しそうな気がする。 あともうちょっと綺麗にしたい。

KPTの掲示

2015-02-28
  • Share on Facebook
  • Tweet
  • Add to Pocket

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

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

↓は2月のKPT。

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

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

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

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

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

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

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

Gemを作成する準備

2015-02-08
  • Share on Facebook
  • Tweet
  • Add to Pocket

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

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

Gem を作るためにまず

bundle gem コマンドを打って雛形を作成する。ここらへんの手順については、パーフェクトRuby13章 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.summaryspec.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 の変更だったりするので気をつけろemoji-exclamation

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

2014年のKPT

2014-12-30
  • Share on Facebook
  • Tweet
  • Add to Pocket

さて、2014 年の KPT のようなものを。

Keep

  • 開発の継続

    • Github上のリポジトリを増やす
    • 作ったもののメンテナンス
  • 読書するぞ/したぞ
  • 貼るホワイトボードの活用
  • 新しい地での、コミュニティ活動
  • ゲームによる気分転換

Problem

  • blogとかほぼ日とか足りてない

    • 記録に残すことがちょっと疎かになってるなぁ
    • 記憶はあてにならんからね
  • 運動してない

    • 歩く距離を延ばすか、もっと負荷上げるかしよう
    • 痩せてないからね……
  • いただいたものの消化が疎かになってますよ

    • 賞味期限あと1ヶ月……
  • 休日の寝たきりを少し減らそう

    • 人との交流が足りないのでは……
  • コミュニティへの参加回数が少ないのでは?

    • 機会はあるのに参加できてない
    • 平日だって参加していいんですよ?

Try

  • 代表作を作る

    • 経過をblogにすると、Problemの解決が捗るのでは?
    • blog にコードが載るようにしたいな
  • いろんなジャンルの本を読もう

    • jsとかcssとか、Ruby以外の言語とか
    • ペースを上げる方法を見出す
  • 西東京への遠征

    • 東東京にとどまりすぎるのはよくない
  • ほぼ日がほぼ月なので、まずほぼ週にする
  • 開発環境の整備を何か一つはしたい
  • ラードの量を減らそう

    • 普段の開発が仕事に活きるように
    • 読む量も増やそう
  • emoji-white_large_square の撲滅

    • もっとよいもので名前を売ろうね
    • 魂は売っちゃダメだね

こんな思いを秘めて2015年に向かってみよう。