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

Let's write something good

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年に向かってみよう。

2014年のふりかえり(思い出す編)

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

2014年、皆様お疲れ様でした。そして、お世話になりました。 ちょっと2014年にあったことを振り返ってみようかな、と思います。

全体的にみて

今年はちょっとした転換の年だった気がします。 実際に転職して住居も大阪から東京に変わっているので、変化は大きかったと思います。

ただし、よく「馴染んでる」とは言われるもののまだ本人は「慣れてはいない」感覚があるので、2015年の早い段階でこれは解消していきたいところ。 「きっかけ」だけだと思うんだけど、と本人は思ってるんですが、まだよく見えてはいない感じです。

仕事

  • 出入り業者としてお客さんのところで作業してた(1-6月)
    • 東京への短期出張(4ヶ月 + 2週間)
    • 客先に常駐という働き方
      • 実は客先常駐初体験
    • レビュー大事
      • フルボッコ体験
      • 時間はかかるが、コードの品質上がる
      • プログラマ同士のコミュニケーション、意図の共有ができる
        • コードへの理解進む
        • 知見の共有
        • 良い/悪いを判断できるようになっていく
        • 1プロダクトに対して、議論・試行錯誤が言葉や文字になってされるのが一番良い点だと個人的に思う
    • 頼りにされる、というのは楽しいし、辛い
      • 「青学の柱になれ」
      • ちょっと時間足りなかったけど、6月楽しかったねーという話しをした。(確かに楽しかった)
        • バグ残して迷惑かけた emoji-bow けど、自分たち主体で作ってた感あった
        • システムだけでなく、ビジネスもうまくいってると聞くと嬉しいもんですね
    • 最後に社内Kaigiしたね
  • 2ヶ月ニートしてた(7-8月)
    • 何もしてなかったわけではないけど、思考の整理くらいしかできてなかったなー
    • 直前の仕事が気になってた
    • 前の会社のメンバーが気になっていた
    • 職場どうしようか、アピールできるとこってどこよとかばかり考えていた気がする
      • キャラかよ……
    • 福井に呑みに行ったりしたね、何故かね
  • 永和システムマネジメントへ転職(9月-)
    • 緊張ガッチガチで出社
    • やはりいろいろいじられる……よね
    • 永和二中
    • 一斉会議で自己紹介LTした
    • “馴染んだのは過去最速じゃないですか?”
      • ん……犠牲的キャラだからね……
    • 出入り業者時代の現場へ
      • メンバーはだいぶ変わってた
      • お客さんの体制も変わってた
      • 今もいる
    • 面白い運営の仕方してるなぁ、と思った
      • まさに「下からの突き上げが厳しい」体制
      • 「ふつう」に運営できるように考えたらこうなったのかな?
    • キャラだけではいかんのだよ……
    • 合宿行ったね!
      • 入社順とか言われておっさん迷わず一番後ろに並んだね(当時入社2ヶ月目)
      • 水がもう冷たかったよ
      • “マッスル・ドッキング”

コミュニティ活動

  • Ruby 関西
    • 私、身体が違うとこにいっちゃったね……
      • 関わり方が難しくなったなぁという率直な感想
      • 外側からの意見しか出せないからなぁ
        • 中の人からすると、求めているのはそういうのじゃないんだよ感、になるのでは
    • LT 1本だけかしらん
  • 大江戸Ruby会議04
    • 出張してる間に行けた
      • 豪華すぎなのでは……
  • XP祭り2014
    • 初XP祭り参加
    • 同僚がいっぱいおった
      • 参加者としては多かったらしい
  • Yokohama.rb
  • RubyKaigi, RubyHiroba
    • 参加者でした
    • 英語力……
    • 全国のRubyistに再び会えたかんじ
    • あいかわらず(なところがすごいのであるが)圧倒的コンテンツ力
    • 今年は飛び込みでHirobaでLTした
  • るびま
    • 前半はいるようないないような感じでした…… emoji-bow
      • 主にプルーフリーディングな参加しか……ウッ
    • 0049号の進行役をしてみた
      • 一般 Rubyist が進行役してみてもいいんだぞ、と
      • いろいろ難しいと思うこともあった
      • うまく伝えられないし伝わらないもどかしさ
        • 力が欲しい感あった
  • 地域 Ruby 会議
    • 大江戸しか行けなかったな

その他

  • 初めてgemをpushしてみた
    • パーフェクトRubyと、Bundler とその他インターネッツに助けてもらってみた
    • もっと有用なものを作りたいな。代表作大事
  • emoji-white_large_square - 以後、この呪いと付き合っていくことになる - 笑いのネタになったり、されたり - 「muryoimpl、杏仁豆腐辞めるってよ」って言われてるけど、だいたい言った人がいじってきたりする - 割りと代わりになるちゃんとしたコンテンツを産み出さないと呪縛から解放されない危機感はある
  • 27inchディスプレイとキーボード
  • 電子書籍のリーダーを iPod mini にした
    • コードが載る書籍を読むにはそれなりのサイズが欲しかった
    • リーダー以外にも使えるし
      • 実際音楽流しながら読むこと多いのでよかった
  • KPTとかふりかえり用のシートを買った
    • どこでもシート
    • 本当に壁に静電気でくっつく。ホワイトボードマーカーで字も書ける。
    • 適当にcurrent, done, backlog, icebox エリア作って付箋貼ってる
      • やること、やったことの視覚化によい
      • trello とか pivotal よりも “やった感” が強いのがよい
      • 目につくし、操作も簡単なので
    • KPTシートも貼って使ってみてる。なかなかよい
      • 薄いので、貼って剥がしてみたいなことするにはあまり向いてないかも。
      • 付箋貼る分には全く問題ない
    • 年明けから 2スプリント目の運用開始
  • 開発に対する考え方がちょっと変わった
    • 「つくらなければ」から「つくりたい」へ
      • 変な義務感がなくなった
      • 少しずつだけど手が動くようになった
  • なんだかんだ言って、今年は結構LTしてるね
  • 勉強会、meetup 等にもう少し行きたい
  • 古いハードでもゲームするの、よい
    • 結構いい気分転換になる
    • やる気が戻ってくるのがよい
      • ゲームをやることが目的にならなければ、の話

感想

ざっと書いてみたらこんだけ書けた。 生活環境が変わって 1Q 経ったので、そろそろちゃんと動きをみせないとなぁ〜

メッセージプレビューあるある

2014-11-23
  • Share on Facebook
  • Tweet
  • Add to Pocket

メッセージ機能で実際にあったお話。

メッセージを送るのに、以下のように preview で内容のバリデーションをしつつ見た目の確認をし、create で保存、かつ、通知メールを出す、という処理があったとする。 (実際のコードは書けないので、かなり適当にサンプルコードは書いてる。。。)

class MessagesController < ApplicationController
  def new
    # 略
  end

  # メッセージのプレビュー
  def preview
    @message = Message.new
    @message.attributes = message_params

    return if @message.valid?

    render :new
  end

  # メッセージ作成
  def create
    @message = Message.new
    @message.attributes = message_params

    Message.transaction do
      @message.save!

      UserMailer.message_notification(@message.receiver)
    end
  end

  private

  def message_params
    # 略
  end
end

※実際の処理には、Message モデルの validation で利用可能文字の制限や文字列の長さ制限をしている。

普通の使い方をしていれば、preview -> create の間に validation エラーになるようなものは発生しない…はずだが…問題が起こることがある。 実際に下記のことが発生していた。

文字コードの誤判定

おそらくブラウザの文字コード誤判定か何かだと思うのだけど、UTF-8で書かれるべき文字列がSJISと思われる化けた文字で送信されていた。

※「と思われる」というのは再現できたけど、ユーザがそうしたかどうかわからないから。ログには化けた文字が送信されていることが記録されていた。

↑の理由により、利用可能文字制限にひっかかってsave! による例外発生で、システムエラーになっていた。

ブラウザの文字コード変換機能を利用するとたしかに再現できた。(見た目も化けるから普通おかしいと思って送信しないとは思うけど…)ので、preview しているとはいえ、validation にひっかかる値が混入する可能性がある。

対応

とりあえず、create のときも、validation でエラーになることを想定し、エラーの場合は編集画面に飛ばすということをしています。

class MessagesController < ApplicationController
  # 略

  # メッセージ作成
  def create
    @message = Message.new
    @message.attributes = message_params

    begin
      Message.transaction do
        @message.save!

        @message.sent_notification(@message.receiver)
      end
    # ここで save! で例外が発生したときは編集画面に戻す
    rescue ActiveRecord::RecordInvalid
      render :new
      return
    end
  end

  # 略
end

まとめ

preview で安心せずに、create でもバリデーションエラーに備える。