This is Hiroyou – who does something interesting.

Git Pull vs Git Rebase

03.03.2012 (2:47 am) – Filed under: 開発 ::

ボクはgit rebase派です。正確にはgit pull –rebase origin masterを実行します。git pull origin masterは使いません、なぜならコミットの順番がおかしくなるから。

参考:git-pull、git-pull –rebaseをめぐる冒険+コンフリクトした場合の作業 – satoko’s blog – s21g

下記は、masterからb1, b2, b3ブランチを作成し、b1 (hoge.txtを追加), b2 (fuga.txtを追加), b3 (piyo.txtを追加)でそれぞれ1度pushを行った後、b3をmasterにmergeし、b1ではgit pull origin masterを、b2ではgit pull –rebase origin masterを、実行したときのコミットログです。

pullの場合

Date: Sat Mar 3 00:44:07 2012 +0900

Merge branch ‘master’ of github.com:Hiroyou/rebase into b1

Date: Fri Mar 2 07:42:25 2012 -0800

Merge pull request #4 from Hiroyou/b3

added piyo.txt

Date: Sat Mar 3 00:40:00 2012 +0900

added piyo.txt

Date: Sat Mar 3 00:25:27 2012 +0900

added hoge.txt

rebaseの場合

Date: Sat Mar 3 00:34:41 2012 +0900

added fuga.txt

Date: Fri Mar 2 07:42:25 2012 -0800

Merge pull request #4 from Hiroyou/b3

added piyo.txt

Date: Sat Mar 3 00:40:00 2012 +0900

added piyo.txt

rebaseの場合はpiyo.txt→fuga.txtの順、pullの場合はhoge.txt→piyo.txtの順になっており、rebaseの方が直感的じゃないでしょうか。masterをメンテしている人からすると、なんで勝手にコミットの順変えるの?却下!って感じになると思います。

ただし、この後 b1, b2のそれぞれでpushを行うと、b1の場合はうまくいくのですが、b2の場合は下記のエラーが出てしまいます。

$ git push origin b2
To git@github.com:Hiroyou/rebase.git
! [rejected] b2 -> b2 (non-fast-forward)
error: failed to push some refs to ‘git@github.com:Hiroyou/rebase.git’
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. ‘git pull’) before pushing again. See the
‘Note about fast-forwards’ section of ‘git push –help’ for details.

これはrebaseによって、ローカルのb2とリモートのb2とがnon-fast-forwardな状態になってしまっているからです。最新のmasterからの差分を確認した上で問題がないようであればgit push -f origin masterと-f (強制)オプションを付けて実行すればpushすることはできます。

ただし、、、

ここでエラーメッセージに従ってgit pull origin b2とかしてしまうと、下記のようになってもうわけがわからなくなりますのでご注意を。b2をb2にmergeするだとか、同じコミットが2回入っていたりだとか、悲劇です。

Date: Sat Mar 3 01:43:30 2012 +0900

Merge branch ‘b2′ of github.com:Hiroyou/rebase into b2

Date: Sat Mar 3 00:34:41 2012 +0900

added fuga.txt

Date: Fri Mar 2 07:42:25 2012 -0800

Merge pull request #4 from Hiroyou/b3

added piyo.txt

Date: Sat Mar 3 00:40:00 2012 +0900

added piyo.txt

Date: Sat Mar 3 00:34:41 2012 +0900

added fuga.txt

これがgit rebaseが危険だと言われる所以なのでしょうか?

でも大丈夫。こうなった場合でもgit reset b2^で元の状態に戻せます。その後、-fをつけてpushすれば万事OK

注)git show-branchとかgit guiでRepository > Visualize All Branch Historyとかを駆使して注意してやった方が良いです。あくまで自己責任でお願いします。

Web投票システムの限界にどう対処するか

03.10.2010 (4:00 am) – Filed under: 開発 ::

Web投票に関しては既にいろいろなところで議論がされているが、
まず知っておかなければならないのは一人一票を簡単には保証できないことである。

とりあえず以下の3つの注意点を気にしたい。

  • ユーザをCookieで判断することの注意点
  • ユーザをIPで判断することの注意点
  • ユーザの認証を要求することの注意点

ユーザをCookieで判断することの注意点:

  1. ユーザは自分でCookieを削除できる → 悪質票が出る
    Cookieを理解している人は多くはないだろうが、知っている人からすれば削除は容易。

ユーザをIPで判断することの注意点:

  1. (同じIPからの投票をブロックすると)共通のグローバルIPを使用している場合がある → 会社とか、マンションとか(潜在票を失う)
  2. (同じIPからの投票をブロックしても)異なる場所から投票できる → 同じ人が再投票できる(悪質票が出る)
    わざわざ異なる場所から投票をするのは物理的に大変だが。
  3. (同じIPからの投票をブロックしても)グローバルIPは変わりうる → 変わってしまえば再投票できる(悪質票が出る)
    変わる頻度はプロバイダ依存(MACアドレスで判断していて変わりにくいプロバイダもある)。そんなに頻繁には変わらないのではないか。

ユーザの認証を要求することの注意点:

  1. 投票をするまでのステップが増える → それを嫌って投票を諦めるユーザが現れる(潜在票を失う)
    例えば、投票する際にメールアドレスを入力してもらうようにすると、メールアドレスの正当性の確認が必要になる。つまりユーザは、メールアドレスの入力→ メール受信待ち→URLクリックのステップが必要になる。また、オープンIDの利用を考えるにしても、ユーザがオープンIDに対応したサイトでのアカウン トを持っているか/作る必要があるし、ユーザは数回のクリック(場合によってはログイン)を要求される。さすがにどこかのアカウントは持っていてもおかし くないが、年配者等になるとわからない。そして、実装の手間も他に比べて大きい。
  2. ログインアカウントはいくらでも作れる → 悪質票が出る
    Cookieの削除よりは手間がかかる。複数のサイトのオープンIDを使えば、数票は簡単に入れられる。新たにログインアカウントを作ってしまえばいくらでも投票できる。

個人的にはIPで判断するのがいいのかなと思うのですが、いかがでしょうか。

加えて、得票数を投票者に見せないのはひとつの作戦ですよね。それで他とどのくらい得票数に差があるか隠せるわけですし。

動かないRuby on Rails @ CORE SERVER

26.09.2010 (1:35 pm) – Filed under: 日記 ::

バージョン下げて動いたって言ってる人がいるけど、

ひとつ前に戻すとかそういうレベルの話じゃないので無理。

passenger使えば動いたって言ってる人がいたけど、

これはCORE SERVERの話じゃないし、

CORE SERVERにインストール出来ないしで諦め。

もうええわー

って感じ。

こうなると専用サーバか、自宅サーバか、PHPですかね。

とりあえず開発だけならローカルでも出来るし、PHPに手を出すのはまだいいや。