レビューフレンドリーな開発のしかた - tomykaira makes love with codes
2013-09-02 レビューフレンドリーな開発のしかた git dev 最近は多くのチームでレビューの習慣が定着してきました。おもにレビュアーとしての仕事を依頼されることもあります。 コミット・ブランチの作りかた一つでこのレビューのしやすさが格段に違ってきます。 自分が普段の開発でこころがけていることをまとめてみます。 前提 レビュイーとレビュアーの間に上下関係があるわけではないですが、レビュイーは多少手数が増えても、レビュアーのことを最大限配慮すべきです。 なぜなら、レビュイーはその機能の開発に集中して取り組んでいますが、レビュアーはすこし見るだけです。 なにかするとしたら、レビュイーがやったほうが時間も手間も少なくなります。 レビュアーはレビュイーよりも、変更について詳しくありません。 レビュイーは開発にいろんな部分を見てまわり、他のモジュールとの関連性や実装のこまかな意図を把握して
Fluentdとはどのようなソフトウェア「ではない」のか - tomykaira makes love with codes
2013-12-04 Fluentdとはどのようなソフトウェア「ではない」のか Fluentdとはどのようなソフトウェアなのか - たごもりすメモに触発されて。 設定が簡単なのに惹かれて Fluentd を利用したら、ひどい目にあった。 でもそれは我々のソフトウェアへの理解が不十分だったから。 最初の段階で気が付いていたんだけど、 quick fix で動きそうだからそのまま突き通してしまい、結局ダメになった。 自分でつかってみた人は、だれもそんな使い方しねえだろって思うだろうけど、噂しか聞いていない人はおなじ間違いすると思う。 Fluentdとはどのようなソフトウェア「ではない」のか Fluentd は「リアルタイム転送のためのツールではない」。 リアルタイム処理のためにつかったら破綻する。 なぜ使えないか そもそもの転送速度が低速 (MQ 系や memcached のプロトコルと比較し
git push 前に自動でテストを回そう - tomykaira makes love with codes
2013-07-14 git push 前に自動でテストを回そう git git push する前にテストを回しわすれ、 pull request が CI にはねられて悲しい思いをすることが多かったので、忘れないように自動化した。 git には pre-push hook が 1.8.2 から導入された。 以前 temporary なコミットが含まれる場合、push をやめるというのを作ってとても重宝した。 git-now したコミットの誤送信をふせぐ - tomykaira makes love with codes テストを回すのはチェックに時間がかかるけど、それで円滑な開発と綺麗なコミットグラフが促進されるなら、30秒ほどまつ価値はあると思う。 .git/hooks/pre-push の内容は次のような感じ。以前のに足したところから、関係なさそうなところを消したので、余計なものが混
continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました - tomykaira makes love with codes
2013-07-13 continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました Scala Git いままで git rebase -i に何度泣かされたことでしょう。 git は最高のツールですが(他の SCM に勝るという意味ではありません)、あれは非常に出来がわるい。 テストを回すたびに自動コミットする continuous commit のプラクティスを採用している私達にとって、 interactive rebase は頭痛の種でした。 (continuous commit については Continuous Commit (kyon_mm さんの発表資料)、最近の git の使い方について - tomykaira makes love with codes など)。 git-rebase--interact
Rails の validation 論争批判 - tomykaira makes love with codes
2013-07-10 Rails の validation 論争批判 Rails 容赦なく批判するので、気分悪く思う方は読まないでください（後半だけよむといいかも）。 twitter での議論は、徳丸さんがまとめられている分はみましたが、それ以外は見落としがあるかもしれません。 TL; DR: これまでの議論は教条的であり、技術を誤解したうえで過信している。 バリデーションは広い意味をもつが、重要なドメインについての観点が見落とされている。 技術者として、なにが必要で、どう実装すべきか自分の頭で考えよう。 validation (バリデーション) とは バリデーションとは 【validation】 〔バリデート〕 - 意味/解説/説明/定義 ： IT用語辞典 検証(する)、実証(する)、認可(する)、妥当性確認、などの意味を持つ英単語。ITの分野では、対象がその仕様や文法などに照らして適切
Rails のモデルはどうあるべきか - tomykaira makes love with codes
2013-07-05 Rails のモデルはどうあるべきか rails TL;DR: Rails の model が太りやすいのは、生まれつき責務過剰だから。開発者が設計段階で責務を絞り、食べる量を減らしてあげよう。 Rails の model というのは、概念も実装も、とても奇妙な使われ方をしている。 いささか不気味だし、実害もある。 fat model はずっと Rails 界で話題になりつづけている。 すでに Rails のプロフェッショナルは抜け出せているのかもしれないが、まだ議論の余地のある話題ではあるようだ。 なぜ model が太るかというと、なんでもかんでも model に食べさせるからである。 一日中食べてれば元々どんなにスレンダーでも太るに決まってる。 コードのダイエットは食べる量を減らすか、外に出すしかない。 太ってから外に出すのがリファクタリングである。 後知恵的に
Rails、あんたなんか嫌いよ - Rails での OO 設計について - tomykaira makes love with codes
2013-06-25 Rails、あんたなんか嫌いよ - Rails での OO 設計について ruby rails 最近はずっと Rails 書いてるんですが、書けば書くほど嫌いになってくるんです。 倦怠期的なやつなんですが、 Rails さんの悪いところばっかり見えてきて、もう一緒にいたくないんです。 でも別れるほどじゃないし… という愚痴にみせかけた Rails での設計についての議論です。 長いけどコードは一切出てこないので通勤中にでもよんでください。 注意 一部にはげしい言葉遣いがでてくるので、読んで不快になるかもしれません。 不快になったとしても責任は負いかねます。 次のような方の期待に沿う結論はでません。残念でした。 Sinatra, Padrino の人 関数型の人 静的型付けの人 C の人 TL;DR Rails にだまされない。 自分の道を見定める。 欺瞞にみちた Ra
RSpec を効率的に記述するために yasnippet 紹介 - tomykaira makes love with codes
2013-06-18 RSpec を効率的に記述するために yasnippet 紹介 ruby rspec rspec は testing framework のなかでは簡潔な記述ですが、それでもテストを書いていると繰り返しが多くなる。 とくに its の連続などはなかなか手でやっていると大変。 私は基本的に emacs で補完をつかって書いている。 hippie-expand と yasnippet を併用しているが、 yasnippet のスニペットは rspec 環境で悩んでいる人に役立ちそうなので公開する。 https://github.com/tomykaira/rspec_yasnippets タイトルが key で展開先が code block という形でいくつか紹介してみる。 一行展開系 it や describe before などの非常に頻繁に使うメソッドを展開する。
git + percol(anything on terminal) が便利 - tomykaira makes love with codes
2013-05-12 git + percol(anything on terminal) が便利 git percol git ではよく sha-1 を入力させられる場面がある。 branch や tag がついている場合はそちらを使えばいいが、たとえば「さっきのコミットでなにを変更したかみたい」というような場合、 一度 git log を起動し、commit id を確認するなり、 HEAD からの距離を確認して、 git show を再度実行するということになる。 HEAD からの距離がとおいと sha-1 指定することになり、わざわざマウスに手をのばしてコピー&ペーストしなきゃいけないかもしれない。 はじめから HEAD^^ みたいに指定できればそれでもいいが、2つ以上前になると、大体いくつ前だかわからないし、まちがって何度も再実行するのもイライラする。 見るだけなら gitk な
人様の git リポジトリを milkode で簡単に管理するインタフェース「gitomb」を作った - tomykaira makes love with codes
tomykaira/gitomb Milkode は数万のファイルでも軽々動く、ソースコード検索エンジンです(製作者は id:tuto0621 さんです）。 しかし、数万ファイルもあるリポジトリなんて管理しますか?普通。 ソースコードを検索する回数がもっとも多いのは、既存のライブラリの使い方がよくわからないときに、ドキュメントに乗っているメソッド名を手掛かりに検索して、望みの機能を発掘していくような時のはずです。いままで、ライブラリのコード検索をしようとおもったら、 ライブラリを落としてくる そのディレクトリに移動する git grep かなんか ヒットしたファイルをエディタで開いて、まわりを見回す 見付かるまで検索をくりかえす みたいなことをやっていました。milkode web を使うと、次のようになります。 ライブラリを落としてくる そのディレクトリに移動する milkode
非 Rubyist に送る、失敗しない ruby 実行環境構築方法 - tomykaira makes love with codes
OS や、動かしたいアプリケーションに依りますが、ruby の実行環境の構築は大変です。 というのも、ruby 本体、rubygems、各 gem などのバージョン指定が交錯していて、ruby の ecosystem に慣れていない人にとっては、なにがなんだかわからないからです。 こっちのツールを動かそうとすると、こっちが動かなくなる、みたいなことになります。rubyists は、バージョンの問題を吸収するためのツールを使ってこの問題に対処していますが、ruby に詳しくなくて、ただ ruby 製のツール(たとえば Redmine)を使おうとしている人は分からないでしょう。 そういう人が ruby に挫折しないように、事実無根な中傷をしないように、最近流行のツールで、バージョンミスマッチの問題をおこさない方法を説明します。この説明が対象としているのは UNIX,LINUX 系の環境だ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
