komagataのブログ

$ rvm install ruby-1.9.3-p125
Installing Ruby from source to: /home/deployer/.rvm/rubies/ruby-1.9.3-p125, this may take a while depending on your cpu(s)...

ruby-1.9.3-p125 - #fetching 
ruby-1.9.3-p125 - #extracted to /home/deployer/.rvm/src/ruby-1.9.3-p125 (already extracted)
Applying patch 'xcode-debugopt-fix-r34840' (located at /home/deployer/.rvm/patches/ruby/1.9.3/p125/xcode-debugopt-fix-r34840.diff)
Error running 'patch -F 25 -p1 -N -f <"/home/deployer/.rvm/patches/ruby/1.9.3/p125/xcode-debugopt-fix-r34840.diff"', please read /home/deployer/.rvm/log/ruby-1.9.3-p125/patch.apply.xcode-debugopt-fix-r34840.log

autoconfが必要らしいので入れる。

$ sudo apt-get install autoconf

こういう場合、普通にinstallするとパッチ当て損ないのソースをもう一度使おうとするらしく、reinstallする。

$ rvm reinstall ruby-1.9.3-p125

OK。

受託開発から離れた理由というエントリーを書きましたが、

「新卒の時からウォーターフォール開発じゃあ既になかった。」

というアジャイルネイティブ（コンチクショウ！）な方には少し分かり辛いかなと思い少し補足を。

受託開発から離れた理由 - komagata

（僕ら受託開発会社とクライアントの利害は必ずしも一致していない。エンドユーザーに至っては受託開発会社の利益と相反してるとさえ言えるじゃないか。）

「開発会社とクライアント（開発を依頼した会社）の利害が必ずしも一致してない」というのは極端に言えば下記のようなことがあるということです。

下記は全てフィクションです

開発会社が論文検索システムを4人月（1人月＝100万円）と見積り受注した。全文検索にはクライアントも知っている名のある商用パッケージを使う前提で見積もったが、土日で試してみたApache Solrを使えば半分の工数（というか土日で仕様の70%を満たしたプロトタイプが出来てしまった。）で出来そうだということが判明した。

当初の予定であった商用パッケージはより機能が豊富だが、今回の案件の規模にはオーバースペック気味で、検索UIには少し制限があり微妙に使い辛く、デザインがダサくなる。対応表明しているハードウェアやOSのバージョンが若干古く、運用も少し面倒そうだ。

要するに、「半分の値段・期間でより良いものが出来そうだ」ということが契約後に判明した。

見積りと契約にはクライアントも納得していたし、採用実績の多い商用パッケージに比べて初採用するならSolrを使うことには多少のリスクを伴う。

ちなみに現在期末であり、当案件の受注を獲得した営業担当にとっては受注金額の半減が決定した時点で今期目標の未達が確定する（笑）

さてここでこの開発会社が取るべき選択肢はどれ？

1. クライアントにも理解できる言葉で全てを説明した上で再度決定を促す。
2. わざわざ損を取る馬鹿がいるか。当初の契約通り行く。契約書の内容と照らし合わせても合法行為である。
3. ウヒョー！クライアントには「商用パッケージと同機能のオープンソースパッケージがありました。ライセンス料を考えたら後者をお勧めします。」と言ってライセンス料だけ引いた金額で再契約すれば、更に2人月別の案件に投入出来て売上アップだぜ！
4. この案件は既存の論文検索システムが使い辛いとのエンドユーザー（学会会員）からの多数のクレームから始まったシステムリニューアルの案件だ。エンドユーザーにとって一番使い易いシステムと柔軟なUIが構築できる可能性が高いSolrを採用した再提案をすべき。
5. 仕様も期間もそのまま、人月50万で下請けに流す。

ではどうすべきか

前述のエントリーは本文を読んでいただければわかりますが、「受託が嫌だから離れたよ」という話だけではなくて、「過去離れたけど今戻ってきて勉強中だよ」というお話です。

どの選択をすべきかという点については僕にはまだわかりません。

ただ、「開発者にとっては受け入れがたいが、ビジネス上反論できない選択肢が存在する」というジレンマがあるため、多くの開発者が悩み、それを解消すべくアジャイル開発などの方法論の開発や経営を含めた契約形態の模索が行われている。アジャイル開発には商売上、受託開発最大のメリットである「商品を作る前から買い手と値段が決まっている」という点と真正面から対立するというこれまたジレンマが存在する。という認識です。

既に、「昨今ではそういう問題は解決してて、普通はこうやってるよ。例えばこの本読めば分かるよ。」みたいなのがあれば教えていただけると非常にありがたいです。また、そういった勉強会を行われている方や実際に答えを持っている方が居らっしゃれば是非、お話を伺いに参りたいです！

rvmでruby-1.9.3-p125をinstallしたらエラー。指示に従ってmakeログを見てみる。

% lv /Users/komagata/.rvm/log/ruby-1.9.3-p125/make.log
[2012-03-20 05:12:02] make 
        CC = clang
(snip)

おお。平然とcコンパイラがclangになってる。ちょっとおっさん、軽く遠い目をしてしまいました。

% vi ~/.zshrc
export CC=gcc-4.2

コンパイラをgcc-4.2にしたら無事installできました。 clangって何か未来的な感じがしますね。今度勉強しよう。

数年前、受託開発の会社を辞めてこれから自社・製品サービスを作ってる会社で働こうと思い、会社を転々としつつ今（FJORD, LLC）に至ります。

上記のような事を思った切欠は下記の様なことがあったからです。

中規模の案件

その時、僕はコンシューマ向けのWebシステムの案件を５〜６人ぐらいのチームで取り組んでいました。データベースに保存されたデータをPHPでXMLを返すAPIを作り、Flashで表示するサイトで、時代が時代だったので「このトラフィックをPHPで構築するなんて。Javaでやるべきだ。」なんて言われてましたが今考えるとおかしいですね。

サーバーとFlashクライアントが連携するのでAPI（XMLのSchema）に関してはデザイナーとも結構密にやり取りしていたように思います。僕はガントチャートとにらめっこしながらも案件の後半になってもそれ程デスマという感じも無く、定時で帰れるメンバーも普通にいて、

「余裕という程では無いにしてもどうやら無事リリースできそうだな」

なんて考えていました。

そんな時、Flashクライントも担当していたデザイナーの@946さんから、

「この部分のUIはこう変更した方が使い易いのではないか？」

という提案がありました。それに対して僕は、

「確かに改善案はもっともですね。僕も使い易くなると思います。しかし、今までのやり取りの感じだとクライアントはその分の工数追加を認めないでしょう。」

と答えました。

そしてその後凄く落ち込みました。

（僕ら受託開発会社とクライアントの利害は必ずしも一致していない。エンドユーザーに至っては受託開発会社の利益と相反してるとさえ言えるじゃないか。）

受託開発という商売

商売の仕組みとして受託開発はとても凄い。ソフトウェアを開発する前から買い手と値段が決まっているんだから。皆がこぞってやるのも当たり前だ。世の中に需要が一定数あるかぎり、ローリスク・ミドルリターン？のとても手堅い商売だ。

僕もその時まではデマルコやワインバーグに始まってAgile関係の書籍を読んだり実践したりして、受託開発がより良く進化していくことに期待していた。しかし「はじめの契約形態、要は契約書になんて書くの？」が解決しない限り本質的に問題は解決しない。（何度か受託でAgile開発系のイベントに行って質問したが、決まって「業務請負契約にしてもらっています」という答えだった。これは僕には妥協に感じられた。）

実際に昨今では永和システムマネジメントの価値創造契約など、その問題に正面から取り組んだ企業出てきた。（これは僕のように逃げずに真正面から受託開発に取り組む本当に素晴らしい姿勢だと思う。）

しかし、そういった問題は経営から考え方を刷新しないと無理だ。その時点で平凡なプログラマーである僕には「まず確実に5年はこの状況がかわることは無いだろう」と考え（実際に5年たったが変わってない）、「ならばエンドユーザーと直接金銭をやり取りする自社製品・サービスを作る仕事をしよう」と考えて転職した。（要は逃げた）

そして現在

現在のFJORD, LLCでも自社サービス（怖話）で利益を上げようと頑張っているが、それだけで食べていける状態に達していないので受託開発も承っているが、僕は上記の様に受託開発を良くしようとする方法論の進化から遠ざかっていた。しかし、下記の2点からまた勉強を始めました。

• 5年ぐらいたっているので僕の知らないだけで上記の問題が解決しているのではないか？
• メンバー2人でもAgile開発の恩恵が無視できない。

「ニワカほどよく語る」と申しますが、恥をかくのは得意なので、Agile開発について勉強したこと、疑問なども書いていこうと思います。

追記

新卒時を除いて、僕の経験した受託開発とはほとんどがコンシューマー向けWebシステムなので、エンタープライズシステムのゼネコン体質などといった、更に難しい問題が無かったのは幸運でした。

どうしても先生という感じがしてしまうんだけど、jonesforthのRichard WM Jones先生が作ってるcron replacement。

whenjobs - a simple and powerful cron replacement

Two key advantages over cron are a simpler syntax for writing rules and a powerful dependency system that lets one job depend on variables set when other jobs run (allowing, for example, one job to run only when another job has finished successfully).

every 10 minutes :
     <<
       # Get the current load average.
       load=`awk '{print $1}' /proc/loadavg`
       whenjobs --set --type float load=$load
     >>

こんな感じで書けるのでシンプルでパワフルとのこと。

それはそうと、先生はRedhatの社員なんですね。whenjobsもRedhatのライセンスなので仕事の産物でしょうか。殆どがOCaml、Cちょっとって感じで書かれてます。

deviseはデフォルトでuserの更新(Devise::RegistrationsController#update)に現在のパスワード(current_password)が要る。

ソースを見てみるとmodelにupdate_without_passwordというのがあるのでこれかと思いきや、これはpasswordとpassword_confirmation無しでupdateするものだった。

自分でupdate_without_current_passwordを作る。

# app/models/user.rb:
class User < ActiveRecord::Base
  def update_without_current_password(params, *options)
    params.delete(:current_password)                                                                                  

    if params[:password].blank?
      params.delete(:password)
      params.delete(:password_confirmation) if params[:password_confirmation].blank? 
    end

    clean_up_passwords
    update_attributes(params, *options)
  end
end

controllerからもこれを使うようにする。

# app/controllers/registrations_controller.rb:
class RegistrationsController < Devise::RegistrationsController    
  def update
    @user = User.find(current_user.id)
    if @user.update_without_current_password(params[:user])
      sign_in @user, bypass: true
      set_flash_message :notice, :updated
      redirect_to after_update_path_for(@user)
    else
      render 'edit'
    end
  end
end

面倒ですね。

怖話ではさくらVPS512を使ってます。性能的にはまだ問題無いんだけど、HDD容量が20GBとちと不安。先日もproduction.logが1.7GBになってたのでちゃんとローテートする。

$ cat /etc/logrotate.d/kowabana 
/var/www/kowabana/shared/log/*.log {
  weekly
  missingok
  rotate 24
  dateext
  compress
  delaycompress

  lastaction
    pid=/var/www/kowabana/shared/pids/unicorn.pid
    test -s $pid && kill -USR1 "$(cat $pid)"
  endscript
}

newrelicのログとかunicornのログとかも一辺にローテートされるから楽でいいですね。-dをつければdry run。-fで強制実行。

sudo logrotate -df /etc/logrotate.d/kowabana

後は一日14MBぐらいずつ増えるDBのバックアップファイルを何とかしなきゃ。

インターネット中毒なので、@machidaさんと飯食ってる時などは大体「どいういうサービスがあったら便利か？」みたいなことを話す。（飯食ってる時以外はPCの前に居るのでサービスを作ってしまうので）

同業の人も大体そうだと思う。僕は現在、仕事時間中は怖話を作り、趣味のプログラミングはLokkaを作るので「新しく作るべきものを考える」という話は最近しない。

僕らが話す時よく前提となるのは、「2人でできるもの」「スケールするもの」「最初からマネタイズ方法が決まっているもの」「自分たちがオモロイもの」などだ。

前述の通り、当面の作るものはあるので先週飲みに行った時は逆の前提で考えてみた。

「とにかくでっかいこと」「世界を変えるもの」「世の中のためになるもの」「とても2人じゃできないもの」「マネタイズ方法は考えない」

いつもと逆であまり考えたことがない種類のサービスだったので僕も@machidaさんもろくなアイデアが出なかった。

• 軌道エレベーターを作る（@machidaさん）
• 軌道エレベーター用地に適した赤道直下の土地を買い占める（@komagata）
• 隕石を迎撃する何か
• 石油を作る藻？をいっぱい飼う
• ウィルスやスパム送信者を攻撃するウィルスを作る。
• 琥珀を買い占めて恐竜のクローンを作る（ジュラシック・パーク）

これはひどい。

結局最後に出たのは、「CPU vs CPUのファミスタの試合を毎日放送してゲーム内通貨を賭けるゲーム」「マイナーなプロレス団体とかスポーツ競技を中継してゲーム内通貨を賭けるゲーム」といういつも通りなアイデアになってしまった。

KFCで食ってたら隣の50代男性3人+女性1人の会話が気になった。

独特の雰囲気を発してるので宗教かネズミ講の勧誘かと思ったら、

（ロイヤルオーダー・・・）

（宇宙・・・）

（アダムスキー・・・）

などと言った単語が会話の節々から聞こえてくる。

議論に熱が入ってきて、思わずハゲたおっさんAが、

「ライト兄弟が飛行機を発明した年にチベットに行ってる。これはユーエフオー（UFO）ですよ！！」

と声を荒らげた。

ロイヤルオーダーというのはどうやら本の名前らしく、会員制ホームページに行けば全文が見れるとのこと。気になるなあ。

branch名を変更する

% git branch -m old_branch new_branch

git addしたが戻したい

git reset HEAD /path/to/file

色々変更しちゃったけど特定の変更に関するファイルだけ別のcommitにしたい

% git app -p

対話的なモードになるのでy, nなどでstageしたいものだけ選んでいく。最後に普通にgit commitする。

上記プラス1ファイル内に関係無い別々の変更点があるのでそれも別のcommitにしたい。

対話モード中に1ファイルのdiffが一気に表示されるがそこでs(plit)を押せば個別にy, nできる。後は同じ。