永遠の命題でもあるんじゃないのかな、と思います。
結論から言っちゃうと、見る人が好きに見ればいいと思います。
楽しくやれればそれでいいです。
その人が仕様について気になってるなら、仕様の漏れがないかとかを重点的に見ればいいし、
好きにやっちゃえよ！！！と最近思ってます。
ただ、少なくともコードとして正しいか（仕様ではないですよ）は見る必要があるのかな、と思ってます。
前の時も書きましたけど、規約に従ってるかってのは基本ちゃんとやってる前提で半分くらいで見ればいいと思うんですよ。
んでですね、色んな人が見ればいいと思うんです。

集まらなくてよくね

なんて言いますか、昔ながらのみんなが集まってレビューする、ってのはあんまり効率がいいとは思えないんです。
あとで書くけど、みんなでわいわいやるのは楽しいので否定しません。
集まって重苦しい空気の中でやるのは断固否定！
晒し上げみたいに集まって、書いた人が延々コードの説明していく。
ダメ、絶対。
つまんなくね？
開発するのは楽しくないといけんばい。

そこでプルリクでしょ！

色んな人が見る、誰が見てもいい、いろいろケチつけたりこりゃ違う、いやいやいや…、とかそういうことのやり取りをする。
これが重要だと思います。
血の通わない議論ほどつまらんものはない。
まあ血が上った議論はいろいろつらいからやめたいけど。
そんなわけで、誰が見るとかは一応決めるんだけど、誰が見てもいい、くちだしてもいいという環境って必要だと思うんです。
それがGitHubとかそこらへんで使われてるPull Requestかと。
GitLabだとMergeRequestって呼び方ですね。
同じ事です。

～Web上にて～ A：こういう機能作ったから取り入れてよ、Bさん！
B：おー、どれどれ。ここダメじゃね？冗長だろ。
A：マジっすか…。これはどうすればええんや！
B：自分で考えろ
A：orz
C：いやいや、それは酷だろー。こうすればよくね？コミットしといたわー。
B：OK！これで使えるぜ！

とか、こういうことができますね。
Cさんが勝手に直しちゃうのはどうかとも思いますけど、アリですね。
なんかちょっと違う気もするけど、とにかくPull Requestが発生したことを起点にみんながコードを見るわけです。
見たらやっぱりなんか内容が気になるじゃないですか。
見ちゃうじゃないですか。
そうでもないですか？

まずは見ることから。
そこから生まれるコミュニケーション。

いいと思います。

楽しくやるために

まあとにかく、レビューしてみて好き勝手突っ込めばいいと思います。
例えば社内のリポジトリでやるなら、まあそこまで無茶苦茶言わないでしょ。
いつの間にか誹謗中傷になってたなんてことになったら悲惨ですけど、たぶん大丈夫。
僕は性善説派です。

なので、楽しくやるためには、たまにレビューしといてとリクエスト投げたあとにみんなランチでもしながら議論すればいいと思いまーす。

またまとまらない結論

楽しくやろう（ここが第一）
観点についてはみんなが好き勝手見ればいい。なんでもいい。
そのためにやれること。今ならプルリクかな。

そんなわけで、みんな楽しくやろうよ！！！（最後なんかぶん投げてるなあ…）

2013-01-29

kaminariを使ってみたら少しハマって、すぐ戻ってきたの巻

ruby rails ハマログ

今作ってるアプリでページネーションをkaminariに任せようとしました。

そして動かしてみたら、pageってメソッドがない、current_pageってメソッドがないなど怒られまくりました。
そんなわけで今回はその解決策。

原因は至って簡単です。
取得してきたモデルがfindで取得してきて戻り値が配列だったからです。
じゃあどうしましょうか。

Kaminari.paginate_array(Model.find(:all, :conditions => ['']))
.page(params[:page])
.per(3)

こんなかんじで行けます。
要は、paginate_array です。
素敵ですね。

2013-01-16

Gitで串

Git

プロクシ通さないと外に出れない環境なので、GitのHTTP通信を通すために設定しました。
具体的に言うと、Githubのソースコードが欲しい時に使ってます。

git config --global http.proxy [proxy]:[port]

こんな感じ。
SSL通信の場合は、

git config --global http.proxy [proxy]:[port]

これでいけるはずです。
んだらば。

2012-12-31

コードレビューについて思うことを書いてみたよ（思ってることだけだよ）

レビュー

WEB+DB PRESS Vol.72

作者: 近藤宇智朗,生井智司,久保達彦,道井俊介,飯田祐基,中村知成,規世やよい,後藤秀宣,天野祐介,奥野幹也,Dr.Kein,tokuhirom,森田創,中島聡,堤智代,A-Listers,はまちや2,竹原,川添貴生,WEB+DB PRESS編集部
出版社/メーカー: 技術評論社
発売日: 2012/12/22
メディア: 大型本
購入: 10人クリック: 86回
この商品を含むブログ (5件) を見る

今月は半分放浪の旅をして、半分は引きこもっていたせいで、そもそもはまるようなことがありませんでした。
そんなわけでしばらく放置してましたが、大晦日と言うことでとりあえずWEB+DB PRESS Vol.72の記事にコードレビューについて書いてあったのでこれを読んで思った事書きます。
大して役に立ちませんよ。思った事書いてるだけですから。

初めてはレビューする側だった

僕が初めてコードレビューというものを体験したのは、前の前の会社（新入社員で入った会社です）で2年目くらいでしたね。
しかも、レビューされる側ではなくなぜかレビューする側。
あのときはなんだかよくわからないうちにリーダー的なポジションにされてたので、お前みんなのコードレビューやってと言われてやりました。
コード書いてる人とかって、上の人とかがいっぱいいて、しょーもないやつもいたんですけど、非常に勉強になりました。
ああ、こうやって書くんだ、こういう書き方もあるんだ－、的な。
正直、コードの品質として向上したかどうかはよくわかりませんが、ここでレビューやらせてもらった経験はけっこうでかかったな、と思ってます。

レビューされる側になってまたレビューする側に

その後、前の会社に入って自分が書いたコードをレビューされたわけですが、大体ここらへんでコードレビューちゃんとやろうと思ったわけですね。
人から言われるのってまあなんかイヤなんですけど、あーここは見落としてたなあとかちゃんと素直に反省するべきところとかあってよかったなあ、と思ってます。

コードレビューのメリット

なんだかコードレビューの効能が勉強的な作用を前面に出して話しちゃってますが、これはこれで必要なんじゃないかな、と思ってます。
特にそんなにみんなのレベルが高くないところでは。
自分が言うのも何ですが、今までいた会社はそんなにレベルは高くなかったです。
全体の底上げをするという意味でコードレビューをして、後々それが綺麗なコード、バグりにくいコードってのになるので、即効性はないかもしれませんが、勉強的な作用を前面にしたコードレビューってのは必要なのかな、と思います。

ソースコードの共有

あと、本でも書かれてるんですが、コードの共有ってのはけっこう大きいですね。
僕は関わってるプロジェクトのほとんど全てのコードにレビュアーとして関わらせてもらってました。
そのため、実際には作成してないんだけど大体どこのコードがここにあってバグったときにここ直せばいいというのはほぼ把握できてました。
これなら作った人が仮にいなくなってもレビューした人がいたらすぐに対処できる！というわけですね。
ま、僕はいなくなりましたけど。
共有ってのは非常にメリットあるな、と思いましたね。

どんなレベルでやるか

これってすげえ難しい。
レビューだけやって、って言われて入ったら、そもそもここ設計おかしくねえか？と言うと相手がムッとしちゃう。
いやあ、ムッと思わせたいわけじゃないんだけどね、だっておかしいじゃないですか…。
大体そういうときはもう最初からある程度変な設計になってても言わなかった。
設計レベルで指摘するのは自分が設計から関わってるもしくは実装を自分もやってる時にしてた。
よくないレビュアーですね。

改修案件って

改修な案件って、これまた難しいんですよね。
改修した部分それだけを見ればいいのか、作り的な部分からちゃんと見るのか。
もちろん、後者の方がいいに決まってるんだけど、「既存をいじると…」とかお決まりのやらない理論が飛び出すわけです。
うん、困ったね。
メンバーの力量がわかってる場合は、それでもがんばればできると思えばやれよ、と言います。
まあそれでもやらないわけですけど。

結局それって…

テストがちゃんとできてないとか、CIな環境が整っていないとかなんで、しょうがないんですよ。
それはある意味で正しい。
けど、間違ってもいるわけで。
レガシーなプロジェクトはほとんどそうなんですよ。
これってたぶんこれからもずっとそうで、よほどリニューアルしますとかじゃない限りそんなん構築できませんよ。
既存に影響を与えないように作り替える方法なんていくらでもあるんだけどね。

あのう、レベルの話は…

はい、あれです。
その時々です！
新規でやってるんだったらフルで言います。
設計レベルから、実装レベル、規約レベル etc...
改修である程度環境が整ってるならできる限りレビューします。
ここらへんも時々ですね。
レガシーなプロジェクトは、やれる範囲ですね。
あんまり設計レベルにまで落とし込まないかも。
単純に実装で論理的なおかしいところとかのレビューになるのかな。
書いてて思ったけど、これだと大して意味ないし、やる側も楽勝ですね！
ま、フルでやらなければそれがずっとつきまとって負債となるんですけどね。

ホントはやりたくないけどやらざるを得ないこと

ホントはしょうもない命名規則違反のコードとかは指摘したくないんですよ。
だから最初に規約とかはちゃんと覚えとこうね。

まとまらないまとめ

そんなわけでコードレビューについて思うこと。

規約は覚えとこう
団体の技術レベルによっては教育的意義が強い(こういうところ多いと思います)
コードの共有は重要
状況によっててかげんしちゃう
レビューは絶対必要だってばよ

とまあこんな感じでした。

WEB+DB PRESS Vol.72

作者: 近藤宇智朗,生井智司,久保達彦,道井俊介,飯田祐基,中村知成,規世やよい,後藤秀宣,天野祐介,奥野幹也,Dr.Kein,tokuhirom,森田創,中島聡,堤智代,A-Listers,はまちや2,竹原,川添貴生,WEB+DB PRESS編集部
出版社/メーカー: 技術評論社
発売日: 2012/12/22
メディア: 大型本
購入: 10人クリック: 86回
この商品を含むブログ (5件) を見る

2012-11-07

C#のリソース開放

いや、まあこれ常識なんですけどね。。。
何年前の話だ？って言われてもおかしくないネタですが、
Javaerに.NETやらすとこうなります、と言うことで会社の人には知っとけよ、
と言う意味で書きます。

詳しくは以下に書いてあるわけですが…。
＠IT：.NET TIPS 確実な終了処理を行うには？ - C#

要は、リソース開放が必要なものはIDisposable実装しなさいって話です。
んで、使う時は using 。
何はなくとも using 。
自分でCloseしない！
Disposeに任せろ！！！
IDisposableを実装していないクラスを using で囲むと怒られます。
なのでわかりやすいんじゃないかと。

using (Stream reader = new FileInputStream(file)) { ... }

2012-11-07

C#で非推奨コードの記述

Javaで言うところの@deprecatedアノテーションですね。
いつも忘れちゃうのでメモ。

[Obsolute("メッセージ", false)]
public void Main() { ... }

第一引数には非推奨の理由などのメッセージ、第二引数にはそのメソッド使ってる場合にコンパイルエラーとするかどうか。
true…コンパイルエラー
false…警告

今やってるコード、これつけるのがすげーいっぱいあるのよねえｗ

2012-10-27

git svn で取り込んだブランチとかタグのお話

Git

git-svnを使用してSVNからGitに移行した時、SVNでいうところのtrunkやらbranchesやらtagsを指定します。
今回は取り込んだあとのお話。
特にタグの話。

git-svnのコマンド

最初にSVNからcloneするわけですが、ログが多い場合途中でミスるケースがあります。
これがイヤなので、一度初期化してfetchするといいと思います。

よく紹介されてるコマンド

$ git svn -s [URL] hoge

オススメコマンド

$ mkdir hoge
$ cd hoge
$ git svn init -s [URL]
$ git svn fetch

-s は、オーソドックスなルートディレクトリ以下が trunk, branches, tags の構成になっている場合のオプションになります。
ちなみに、ここでブランチ名のプレフィクスもつけられます。

$ git svn init --prefix svn/ -s [URL]

わかりやすいようにつけといた方が良いと思います。

trunkのお話

trunkで指定した場所はそれがGitブランチのmasterブランチになります。
もし移行時にメインで動かしているブランチがtrunkではなくブランチ分けてた場合、
まあ普通はtrunkにマージするんだろうと思いますが、そうしないでそのまま行く場合は、
trunkにそのブランチを指定してください。

$ git svn init --trunk branches/develop [URL]

こうすると、リモートリポジトリ名がtrunkになります。
また、fetch後のmasterはリモートリポジトリのtrunkのものになります。
まあ大して変わらないので、ブランチのまま取り込んであとからmasterにマージでも全然かまわないと思います。。。

branchesのお話

branchesは複数指定できます。
例えば、階層が深くなって複雑になっている場合に指定します。

$ git svn init --prefix svn/ --trunk trunk \
> --branches branches/user2/experiment1 \
> --branches branches/usr \
> [URL]

ここで指定したブランチは普通にGit上でリモートブランチとして認識されます。

tagsのお話

tagsは、タグといいつつGit上ではリモートブランチになります。
たしかに、SVN的にはただのブランチですもんね。
(少なくともリポジトリブラウザ的なものでの見た目は…)
そんなわけで、SVN上のtagsが以下のようになっているとしましょう。
tags
　　|- ver1.1 　　|- ver1.0
　　|- ver1.2
　　|- ver2.0

これを取り込みます。

$ git svn init --tags tags [URL]

こうすると、ver1.1などのリモートブランチができちゃいます。
なので、ここから本当にタグにしたい場合は、

$ git tag ver1.1 remotes/ver1.1

とこんな感じで地道にタグ打ちしてください。
また、SVN上ではタグ分けした時点でそのブランチのコミットは止まって
以降のブランチとは独立したものになってしまうので、
Gitのリビジョングラフを見ると完全にそこで途切れているように見えると思います。
そこはしょうがないと言うことで…。
実際そうなんだし…。

2012-10-25

Pysqlite インストールしようとしてできない時

ハマログ ReviewBoard linux

Review BoardをCentOSに入れようとしています。
その中で、SQLiteを使うためにPysqliteを入れないといけないのですが、はまったのでロギング。

easy_install pysqlite

ReviewBoard公式サイトのインストール手順に従うとこのコマンドですが、以下のメッセージが出てインストールできませんでした。

Searching for pysqlite
Reading http://pypi.python.org/simple/pysqlite/
Reading http://pysqlite.googlecode.com/
Reading http://code.google.com/p/pysqlite/downloads/list
Best match: pysqlite 2.6.3
Downloading https://pysqlite.googlecode.com/files/pysqlite-2.6.3.tar.gz
.....................
src/module.c:296: error: ‘SQLITE_DETACH’ undeclared here (not in a function)
src/module.c: In function ‘init_sqlite’:
src/module.c:426: warning: implicit declaration of function ‘sqlite3_libversion’
src/module.c:426: warning: passing argument 1 of ‘PyString_FromString’ makes pointer from integer without a cast
/usr/include/python2.6/stringobject.h:63: note: expected ‘const char *’ but argument is of type ‘int’
error: Setup script exited with error: command 'gcc' failed with exit status 1

なんかおかしい。
これ、ダウンロードしたファイルのヘッダーがおかしいんだろーか。
うーん。
調べてると自分でダウンロードしてきてインストールしてみろとのこと。

pysql

$ tar xvfz .tar.gz $ cd $ python setup.py build_static install

言われるがままにダウンロードしたURLはこちら。
http://pysqlite.googlecode.com/files/pysqlite-2.6.3.tar.gz
うーん、一緒だなあ…。

そんなわけでとりあえずインストールしてみると…、

できました！

build_static があるところがポイントっぽいですね。

2012-10-18

historyに実行日時をつける

linux ちょこざい技

まあ～、なんていうかね。
コマンドの実行時刻を見たい時ってあるじゃないですか。

そんなわけでこれをやりましょう。
ユーザーの .bashrc でも .bash_profile を編集します。

HISTTIMEFORMAT='%y/%m/%d %H:%M:%S ';

これを最後に追記してください。
割とサーバーに必須の設定だと思うんだけど、意外と取りざたされていないと思うのは当たり前すぎるからかな？

おわり。

【追記】
ちなみに、これの設定前の日付はhistory実行時の日時が出てきちゃいます。
たぶん。
正確に言うと、別セッションの以前の履歴はhistory実行時の現在日時になるっぽい。(CentOS6.2)
変更を加えた自セッション分の日時はうまいこと出てました。
ちがってたらごめんよー。

スパゲッティコード

色々やりたいので書いてこうと思います

大東京トイボックス面白いよ

大東京トイボックス熱いよ

ゲーム業界も大変だあ

「仕様を一部変更する！！！」

とにかくね、すげえ熱いの。

もう一個レビューについて思ったこと

どんな観点で見るか