gitでリポジトリからのチェックアウト時に文字コードを変換する » tune webの続きです。
【未解決】VisualStudioとgccでコンパイルできるソースのエンコーディング » tune webでも書きましたが、問題はVisualStudioはUTF-8 BOM有のみ、gccはUTF-8 BOM無しのみ扱え、両者で問題なく扱える文字コードが存在しない事でした。gitにあるsmudge/cleanを使うとチェックアウト/ステージ時に任意のフィルタを通すことができ、BOMの除去をここでやれば出来そうなのですが、文字コード変換ソフトのnkfではBOMの有り無し以外も書き変わってしまうことがあるため実用に使えなかったのがこれまででした。

git smudge/cleanはPro Git – Pro Git 7.2 Git のカスタマイズ Git の属性に詳しく解説されています。
git smudge/cleanの設定は前の日記に書きましたが、ここでも引用しておきます。

まず.gitconfigファイルに以下を追加

[filter "fixbom"]
clean = “/usr/bin/bom_util -a”
smudge = “/usr/bin/bom_util -d”

これでsmudgeでUTF-8 BOM無し、cleanでUTF-8 BOM有りになります。

これだけではダメで、フィルタ処理をかけるファイルを指定する必要が有ります。
gitの管理フォルダである.gitがあるトップディレクトリに.gitattributesファイルを以下の内容で作成し、git checkout -fします。

*.c filter=fixbom
*.h filter=fixbom

/usr/share/git-core/templates/info/attributes を作って上記内容を書いておくとclone時に.git/info以下にコピーされてgit cloneしただけで文字コード変換が動くようになります。

上記で指定している、BOMをつけ外しするプログラムは結局自作しました。単にファイル先頭のBOMを検知して追加・削除をするだけです。ハマったこととしてgit smudge/cleanのデータは標準入力から渡され、標準出力へ書いた内容で差し替えられます。外部コマンドとして起動されるのかと思っていましたが異なるようです。
BOMをつけ外しするプログラムを下に貼っておきます。(gistはこちら→gist: 386410 – GitHub)

#!/usr/bin/ruby

require "optparse"

mode = :help

opt = OptionParser.new
opt.on("-a", "Add BOM"){|v| mode = :add}
opt.on("-d", "Delete BOM"){|v| mode = :delete}
opt.parse!(ARGV)

case mode
when :add
 STDOUT.binmode
       lines = readlines
       unless lines[0] =~ /^\M-o\M-;\M-?/ then
               print "\xEF\xBB\xBF"
       end
       print lines

when :delete
 STDOUT.binmode
       lines = readlines
 lines[0].sub!(/^\xEF\xBB\xBF/, '')
 print lines

when :help
       STDERR.puts opt.help
end

VisualStudioでの開発をメインにしているので、リポジトリ内のソースをUTF-8 BOM有、改行コードをLFCRにして運用しています。
これでLinux環境での開発がひとつやりやすくなりました。

photo credit: drdaeman

makeplex salon：あなたのスキルで飯は食えるか？　史上最大のコーディングスキル判定 (1/2) – ITmedia エンタープライズを解いてみました。ソースはtune’s itmedia_makeplex at master – GitHubに上げてありますのでリビジョンも見れるようになってます。最初のコミットを上げるまでに、面子の表示順の違いを抑えるところで詰まってチンイツの待ちを出力するプログラム – 107143955443560を参考にしました。参考にしましたというよりもC++のソースをRubyに移植しましたと言う方が近いほど同じ処理です。基本的なアルゴリズムは最後まで踏襲しています。

最初のコミットまでが3時間ぐらい、リファクタリングに1時間ぐらいです。ちょっと時間がかかりすぎですが、日常的に書いてないRubyで、日常的にプログラムしてない家のMacパソコン、プラグインが古いのか5分に1回落ちてしまうMacVimで時間がとられたと言い訳しておきます。ただの実力不足です、ごめんなさい。

成立する可能性がある面子を減らしながら、総当たりで探索しています。面子の順序違いによる重複表示を避けるのが結構面倒ですね。刻子を優先して探さなければならず、色々試行錯誤してみたのですが、参考にさせていただいたid:staebchenさんよりも良さそうな方法に達しませんでした。もっといいやり方があると思いますが、参考まで。

#!/usr/bin/ruby

class Array
  def sum
    s = 0
    self.each do |v|
      s += v
    end
    return s
  end
end

class Fixnum
  # 刻子
  def anko
    num = self+1
    "(#{num},#{num},#{num})"
  end

  # 順子
  def shuntsu
    num = self+1
    "(#{num},#{num+1},#{num+2})"
  end

  # アタマ
  def atama
    num = self+1
    "(#{num},#{num})"
  end

  # 単騎
  def tanki
    num = self+1
    "[#{num}]"
  end

  # リャンメン(ペンチャンも兼ねる)
  def ryanmen
    num = self+1
    "[#{num},#{num+1}]"
  end

  # カンチャン
  def kanchan
    num = self+1
    "[#{num},#{num+2}]"
  end

  # シャボ
  def shabo
    num = self+1
    "[#{num},#{num}]"
  end
end

#
# 雀牌を表す数字列を解析し、0〜8の配列に与えられた個数を入れて返す
#
def parsePai(str)
  pai = Array.new(9, 0)
  str.split(//).each do |p|
    pai[p.to_i-1] += 1
  end

  # 入力の妥当性チェック
  if pai.sum != 13 then
    # 与えられる牌は13枚
    raise RuntimeError
  else
    pai.each do |val|
      if val > 4 then
        # 1種類の牌が4枚より多いことはない
        raise RuntimeError
      end
    end
  end

  return pai
end

#
# 手牌を再帰的に解析し待ちを表示する
#
# 順子を刻子に優先して探索する。
# 順子はfromが9〜18の時に探索される
#
def analyzeTehai(pai, from=0, mentsu=[])
  shuntsu_phase = 9
  skip_anko_check = false

  if from >= 9 then
    skip_anko_check = true
    from -= shuntsu_phase
  end

  if pai.sum > 4 then
    # 面子を揃える

    # 刻子
    unless skip_anko_check then
      from.upto(8).each do |i|
        if pai[i] >= 3 then
          tmp = pai.dup
          tmp[i] -= 3
          analyzeTehai(tmp, i+1, mentsu+[i.anko])
        end
      end
    end

    # 順子
    from.upto(6).each do |i|
      if pai[i]>=1 && pai[i+1]>=1 && pai[i+2]>=1 then
        tmp = pai.dup
        tmp[i] -= 1
        tmp[i+1] -= 1
        tmp[i+2] -= 1
        analyzeTehai(tmp, i+shuntsu_phase, mentsu+[i.shuntsu])
      end
    end

  else
    # 残った4枚から待ちを絞る

    # アタマを探す
    0.upto(8).each do |i|
      if pai[i] >= 2 then
        tmp = pai.dup
        tmp[i] -= 2
        analyzeMachi(tmp, mentsu+[i.atama])
      end
    end

    # 面子(刻子 or 順子)があれば単騎待ち
    # 刻子
    unless skip_anko_check then
      from.upto(8).each do |i|
        if pai[i] >= 3 then
          tmp = pai.dup
          tmp[i] -= 3
          analyzeTanki(tmp, mentsu+[i.anko])
        end
      end
    end

    # 順子
    from.upto(6).each do |i|
      if pai[i]>=1 && pai[i+1]>=1 && pai[i+2]>=1 then
        tmp = pai.dup
        tmp[i] -= 1
        tmp[i+1] -= 1
        tmp[i+2] -= 1
        analyzeTanki(tmp, mentsu + [i.shuntsu])
      end
    end
  end
end

#
# 4枚から待ちを絞る
#
def analyzeMachi(pai, mentsu)
  0.upto(8).each do |i|
    # リャンメン(ペンチャン)
    if pai[i]==1 && pai[i+1]==1 then
      puts mentsu.sort.to_s + i.ryanmen
    end

    # カンチャン
    if pai[i]==1 && pai[i+2]==1 then
      puts mentsu.sort.to_s + i.kanchan
    end

    # シャボ
    if pai[i]==2 then
      puts mentsu.sort.to_s + i.shabo
    end
  end
end

#
# 単騎待ちの数字を調べて待ちを表示する
#
def analyzeTanki(pai, mentsu)
  # 単騎待ち
  0.upto(8).each do |i|
    if pai[i] == 1 then
      puts mentsu.sort.to_s + i.tanki
    end
  end
end

# 以下実際の処理
pai = parsePai ARGV[0] unless ARGV[0] == nil
analyzeTehai(pai)

という問題が職場であったのでそのメモ。Releaseモードだとすぐ処理出来るのにDebugモードだと無限ループに陥ったかのような挙動を示す質問をもらったので調べてみました。priority_queueというのはある値に戻づいて順序が保たれるqueueです。便利ですね。

再現コードはこれでOK、C++編（標準ライブラリ）　第７章　priority_queueを参考にさせて頂きました。

#include
#include
using namespace std;

int main()
{
    priority_queue qu;

    // 要素を追加
    for(int i=0; i<100000; i++){
        qu.push( i );
    }

    // 先頭要素を取り出して出力
    cout << qu.top() << endl;

    return 0;
}

VisualStudio2005で試したところDebugモードだと動いてはいるのですが、とにかく時間がかかります。途中で処理を止めたところpushに時間がかかっているようです。そこでpushの先を追って行くと下記のようなコードが見つかります。

_Vector_iterator()
       {       // construct with null vector pointer
       }

#if _HAS_ITERATOR_DEBUGGING
_Vector_iterator(pointer _Ptr, const _Container_base *_Pvector)
       : _Mybase(_Ptr, _Pvector)
       {       // construct with pointer _Ptr
       }

#elif _SECURE_SCL
_Vector_iterator(pointer _Ptr, const _Container_base *_Pvector)
       : _Mybase(_Ptr, _Pvector)
       {       // construct with pointer _Ptr
       }

#else
_Vector_iterator(pointer _Ptr)
       : _Mybase(_Ptr)
       {       // construct with pointer _Ptr
       }
#endif /* _HAS_ITERATOR_DEBUGGING */

これを見るとdefineの定義状況によって、毎回値の妥当性チェックが呼ばれているようです。
これが過度にパフォーマンスが落ちていた原因でしょう。

_HAS_ITERATOR_DEBUGGINGはデバッグビルドでのみ有効になるようですが、_SECURE_SCLはリリースビルドでも残るようです。何用の定義なのかは軽くググッた限りではわかりませんでした。2007-07-04 – 新言語 Xtalを作る日記が見つかったぐらいです。

回避策としては両defineを0に設定すれば動かなくなり、通常のRelease/Debugの時間差で収まるようになります。

ラベリング処理というのは入力画像に対して、連結する画素(同じ色とか、同じ領域とか)ごとに同じ番号を割り振る処理のことです。領域別に処理する際の前処理に使ったり、画像中の微小領域のサイズを測定してノイズ除去に使ったりと色々と有用です。アルゴリズム入門 : 第 3 章 画像処理入門 1を読むとイメージが湧くかと思います。

ラベリング処理は1970年代から知られている処理ですが、高速なアルゴリズムが意外と知られていません。ネットで検索すると大学の授業での説明資料が見つかる程度で、文献をあたっても解説があまりにも少なく多くは役に立ちません。

古い本でラベリング処理のアルゴリズムが詳しく説明されたものを見つけたので多くの人に有用と思い、ここに書いておきます。参考にした本は近代科学社発行の長尾真さんによる「デジタル画像処理」で、1978年に発行されています。ラベリング処理の紹介は360ページ〜361ページに有ります。

１：値を隣接する画素に伝搬させる

Sの成分をラベル付けする簡単な手続きは、探索と”伝搬”からなるものである。1が見つかるまでSを走査し、その値をまだ使われてない最初のラベルの値、たとえばvに変える。そしてvを1に向けて繰り返し(必要なら並列に)伝搬させる。すなわち、vを近傍として持つ1をvに変える。もはや変化の可能性がなくなったとき、明らかに最初のvに連結した1は全てvになっている。ここでさらに走査を続ける。別の1が見つかれば、これはv成分には属してないので、新しいラベルを付けて同じ手続を繰り返す。

Sが処理対象の画像、ラベル付けする対象が1、割り振るラベル値がvです。
この手法は「この手続は簡単ではあるが、非常に時間がかかる。各々の伝搬の過程は、たとえ並列に処理しても、図形の面積の次数だけの反復を要するからである。」と紹介されています。最初に紹介したMSのサイトで使われているのがまさにこれです。おすすめできません。

２：境界線を抽出し、輪郭内部に同一の値を割り振る

成分のラベル付けの別な方法としては、9.1.2節で述べた境界を見つける手法を、いくつかの外側境界(すなわち、Sの成分でこれを囲むS^の成分に隣接している境界。演習9参照)を別々にマークを付けるよう修正し、各成分の外側境界に異なったラベルを用いる。これが済むと、必要に応じて外側境界のラベルを成分の内側へ”伝搬”させることができる。これを並列に行うなら、たかだか図形の半径に等しい反復数を要する。

手当たりしだいに伝搬させるのではなく、まずは領域の輪郭にユニークなラベル番号を付与し、必要であれば内側に値をコピーする。1番よりは効率的ですが、「外側境界のラベル付けの手続きは時間がかかる
」処理であり、図形の面積につれて増加する多数のステップを有します。

３：行毎に横のつながり(ラン)を求め、上下の対照表をもとにつなげて行く

たいていの目的には、境界よりむしろ1のランを追跡してラベル付けをする次の手法が最良策である。図形の第１行目において、各ランに異なったラベルを与える。第２(とそれ以下の)行では、１のランを調べて前行のランと位置を比べる。ランρが前行のどのランとも隣接していなければρに新しいラベルを付ける。ρが前行のちょうど１つのランに隣接しているなら、そのランのラベルを付ける。ρが前行の２つ以上のランに隣接しているなら、ρにはこれらのらべるの(たとえば)最小値を付けるが、これらのラベルはすべて同一成分に属することも控えておく。図形がこのようにしてすべて走査されたとき、控えを分類して等しいラベルの集まりを決定できる。必要なら、図形を再走査し各ラベルを、たとえば等価な最小の値のラベルに置き換えることが出来る。

ということで、3番目がおすすめです。処理時間が画像サイズに依存して決まるし、ラスタ走査のみなのでメモリ上のキャッシュも有効に動いてくれるでしょう。

上の説明文を素直に実装すれば効率のよいラベリング処理を実現出来るでしょう。

• ディジタル画像処理 (1978年)

TDD Boot Campに行ってきました。

◯t-wadaさんのTDD話
いつものように資料があとでアップされるのではないかと思います。
個人的にとってたメモを以下に載せておきます。

会場ではt-wadaさんのテスト駆動開発本が見れるようになっていました。かなり読み込まれた形跡があって、TDD愛が伝わります。訳がいまいちというAmazonレビューで躊躇していましたが購入して読んでみようと思います。

◯Test Drivenの作者 Lasseさんの講演
レシーバーが足りなそうだったので英語を聞きとるのに必死になってしまい、話の所々がフォローできず。
twitterの#tddbcタグを見る方が参考になるかも。
内容はレガシーコード改善ガイドの紹介と、Coberturaのライブハッキング。Eclipseのコードさばきが見事すぎて見とれてしまいます。

◯TDD実践編
ペアを組んでサイズ制限付きのハッシュを作成しました。
いつもだとつい実装を先に書いてしまい、テストが後回しになったり、テストに抜けや不足ができてしまうのですが、ペアプロだったこともあって、TDDの基本的な流れが改めて抑えられたと思います。

ソースはgithubに上げてあります。

http://github.com/tune/lrucache

TDDを知るには完成形のソースではなくて、その過程を学ぶことが大事ですね。gitを途中から使っておきながらあまりコミットできてません。次はもうちょっと気を配らないと。

周りにすごい人もたくさんいました。

• ペアプロでのソースの受け渡しをgithub/gistでやっちゃう
• gistにソースあげたし、CIもやるか→ローカルHudsonでCIまで
• 一人で時間あったしやってみたよとLasseさん、しかもJavaとRubyの2言語。Rubyのテストをみんなで見たけどテストが完結で読みやすい、ここまでできるのかと目から鱗でした。

会社ではC言語なのでCUnitを使ってテストは書いていますが、我流になっているところがあって、今日は行けてよかったです。

• テストも製品ソースと同じく綺麗に書く → 主張はよく耳にするけど実際にLasseさんやその他の人のソースをみると上には上がいて、きちんと実践できてます。
• 言語でテストの読みやすさ、書きやすさに差ができるわけではない。Javaでも簡潔にかけるし、Rubyでもどうしようもないコードはかけてしまう。

楽しいイベントを開催していただきありがとうございました。

[Agile]イテレーティヴとインクリメンタルの違い | Ryuzee.comを読んで思うところがあったので少し出遅れたけどメモ変わりに。

インクリメンタルだと最初から完成した姿を見越してI/Fを完全に作り込むのはあまりに難しく、かといって完成した部分に都度手を入れていては差分開発による工数の削減にならず、スケジュールが問題化してしまう。だったら前に完成したところは触らず、追加分で黒魔術を駆使しようという勢力が優勢になり、バージョンを重ねるにつれて継ぎ接ぎ部分が問題化する。機能もソース規模も雪だるま式に増えていく一方で、全体最適なソフトを作ることはきっとできない気がする。

差分開発というキーワードは一般的だけど、自分たちが取り組んでいるのは「イテレーティブ型」で、将来にわたってソフトウェアが最大の価値を生めるようにしているからだと主張しないと、ソフトウェアアーキテクチャの設計が悪いから差分開発が徹底できてないと評価を下されてしまう。

マネージャー層の階層を上がるほど「インクリメンタル」を念頭に置いている人が多いような気がします。機能が一通り揃ったら開発を収束させて、別なソフトに触手を伸ばすのもインクリメンタルな発想ありきなマネージメントかな?

UTF-8だと一見どっちも対応しているように見えるんだけど、VisualStudioはBOM有のみ、gccはBOM無しのみ対応しています。

んで、対策として取ったのが gitでリポジトリからのチェックアウト時に文字コードを変換する » tune webだったんですが、今日仕事中にこんなページを見つけました。
GOGA – 数式の夢とコンピュータの現実: UTF8のソースコードをgccとVCで共有すること

なんだ、VisualStudioの方は警告さえ抑えれば普通にコンパイルできるのかとさっそくやってみたのですが、見事に失敗しました。VisualStudioでコンパイルするとエラーが山ほどでてダメでした。
調べてみるとVisualStudio2003まではいけたらしいんですが、自分が使っているVisualStudio2005ではNGでした。今の最新版は2008ですし、来年には2010もでます。VisualStudioのバージョンによらず簡単な解決法を模索したいところなのですが、困りました。

「VisualStudio2008/2010ならBOM無しのUTF-8も扱えるよ」という情報をお持ちの方がいらっしゃいましたらぜひ教えてください。

→2010年5月2日 解決しました Windows/Linux両環境で動作するC言語ソースの一元管理をGitで行う » tune web

ようやく実現できたのでやり方をメモ。
設定ファイルで拡張子に基づくフィルタリングをすればOK。

ProGitの情報によるとリポジトリから取ってくるときをsmudge、リポジトリに突っ込むときをcleanと呼ぶらしい。

以下はリポジトリ内のソースファイルがUTF-8 BOM有、改行コードがLFCRの場合の設定例。文字コード変換はnkfを使っています。
WindowsのVisualStudioに合わせると上記設定が望ましいが、Linux環境でgccを使うにはBOM無しにして、改行コードをLFにする必要がある。
まず.gitconfigファイルに以下を追加する

[filter "fixencoding"]
clean = “/usr/local/bin/nkf -w8 -Lw”
smudge = “/usr/local/bin/nkf -w -Lu”

これでsmudgeでUTF-8 BOM無し/LF、cleanでUTF-8 BOM有り/LFCRとなる。

これだけではダメで、フィルタ処理をかけるファイルを指定する必要が有る。
gitの管理フォルダである.gitがあるトップディレクトリに.gitattributesファイルを以下の内容で作成し、git checkout -fする必要が有る。

*.c filter=fixencoding
*.cpp filter=fixencoding
*.cxx filter=fixencoding
*.h filter=fixencoding
*.hxx filter=fixencoding
*.txt filter=fixencoding
Makefile filter=fixencoding

/usr/share/git-core/templates/info/attributes
を作って上記内容を書いておくとclone時に.git/info以下にコピーされてgit cloneしただけで文字コード変換が動くようになる。

動かすにあたって問題となったのはgitでチェックアウトしただけで編集されたことになってしまうファイルが多々発生したことです。原因はいろいろあったのですが
リポジトリインデックス内のファイル文字コードがバラバラだった(BOM無しファイルが紛れ込んでいた とか)
ファイル内の文字に半角カナがあるとダメらしい。
ファイル内の文字に機種依存文字(実際にあったのは丸数字)があるとダメらしい。

git statusなどで編集が有ったかどうかはインデックス内の状態と比較するからcleanして元々の状態と変わってしまうと当然チェックアウトしただけで編集されたと勘違いされてしまうファイルができてしまう ということですね。
WEB DB Press Vol.50で解説されていたgitの内部データ構造を知ってようやく理解できました。

Subverisonだと文字コードをうまく変換する機構も無いのでgitをかましてやるのが便利ですね。

64bit OSで動かすと32bitの時と処理結果が異なるプログラムで悩んだメモです。

調べていくとfloatを使った浮動小数点演算で誤差が出ることがわかりました。分からなかったのが、IEEE754でfloatの演算精度は32bitと規定されているのになぜ同じソースから作ったプログラムで結果が違うのかということです。

x86では浮動小数点演算にx87を使うのですが、この演算精度は32bitや64bitではなく、80bitで行われるそうです。この辺の話は 浮動小数点演算ではまった話 – bkブログとかBK通信に詳しく載ってます。要約すると32bitの精度で誤差が生じる計算が含まれていても”たまたま”うまく計算できることがある ということです。

たまたま精度よく計算できるプログラムをx86_64に持っていってコンパイルしようとします。このとき、x86_64では必ずSSEが使えるため、コンパイラはデフォルトでSSEを使うようにコンパイルします。SSEで浮動小数点演算を行うと演算精度がx87の80bitよりも悪くなるため、本来生じるはずだった演算誤差が表面化することになります。

高林さんがBK通信で書いているMac OSで演算結果が違うというのも、Mac OSが64bitOSであることが関係している気がします。

バイナリーハックス買おうかな。

Binary Hacks ―ハッカー秘伝のテクニック100選

posted with amazlet at 08.12.09

高林 哲 鵜飼 文敏 佐藤 祐介 浜地 慎一郎 首藤 一幸
オライリー・ジャパン
売り上げランキング: 23306

おすすめ度の平均:

ハードコア？なソフトウエア
大工さんにおける電動工具の紹介本
当然教科書ではない。でも、とても参考になります。
バイナリアンの基本

Amazon.co.jp で詳細を見る

#map_yxdijbqs" />

gullery photo gallery via kwout

Rubyできれいなグラフが書けるライブラリ、仕事で数値を扱うのに使いました。使うにはImageMagickとRMagickが必要です。

リンク先のグラフはどれも洗練されていて美しいのですが、データがちょっと多かったりすると見た目が悪くなって困り者です。なんだかんだ言って細かな調整ができるExcelの方がまだ使い勝手がいいです。
細かい所に手が届かないのも問題ですが、使い方のサンプルが少なくてちょっと分かりにくいかな。

Railsでも使えるみたいなんで、もうちょっと情報が出てくるといいですね。

Gruff Graphs for Ruby | Ruby on Rails for Newbies

‥

追記、Railsならhtml5jp_graphsなんてのもあるらしい。こっちの方が細かい所まで手が届く感じ。

会社で Buildbotを設定していた困ってしまったのですが、この手のCIツールはディレクトリの移動ができないのでしょうか?

CatalystアプリをbuildbotでContinuous Integration – dann@catalyst – Catalystグループを参考にBuildbotの設定ファイルを書いていたのですが、Subversionリポジトリからtrunkを引っ張ってきてトップディレクトリにあるmakeファイルを使ってプロジェクトをビルドする設定は

from buildbot.process import factory
from buildbot.steps import source,shell
f1 = factory.BuildFactory()
f1.addStep(source.SVN,
svnurl=source_code_svn_url,
mode=”clobber”)
f1.addStep(shell.ShellCommand, command=['make'])
f1.addStep(shell.ShellCommand, command=['make', 'test'])

と書けますが、自分が設定していたプログラムのMakefileは”project/Makefile”にあったのでcdコマンドを加えれば行けるのかと

f1.addStep(shell.ShellCommand, command=['cd', 'project'])
f1.addStep(shell.ShellCommand, command=['make'])
f1.addStep(shell.ShellCommand, command=['make', 'test'])

と書いたところBuildbotがエラーを吐いて止まってしまいました。作業ディレクトリ変更用の機能があるのかとマニュアルを一通り見てみたのですがどこにも見当たりません。

確かにConfigureスクリプトやMakefile、インストールプログラムはプロジェクトのトップに置くのが一般的なので問題になった自分のプロジェクトが変なだけかもしれません。

ビルドテスト用スクリプトを自作するか、プロジェクトの構成を変更してしまうか悩んでいるところです。
自作はさけたいんだけどなぁ。

オレンジニュースでlog5j – Google Codeが紹介されていたので、log4XXって各言語にあるのかなと気になったので調べてみました。

• log4c: Log4c : Logging for C Library(C)
• Log for C++(C++)
• Log4cplus Project Page(C++)
• log4cxx – About(C++)
• Apache log4j 1.2 – log4j 1.2(Java)
• log5j – Google Code(Java)
• Apache log4net – Apache log4net: Home(.NET)
• log4php – Apache log4php(PHP)
• Log4r – Manual(Ruby)
• SourceForge.net: Log4Py(Python)
• perl.com: Retire your debugger, log smartly with Log::Log4perl!(Perl)
• Log4js – The Logging Framework for JavaScript(JavaScript)
• Log4E – Home(Eiffel)

思いつく言語で見つかったのだとこんな感じかな? 他にもご存知の方がいましたら教えて下さい。

• 最もタメになる「初心者用言語」まとめ – UK is not Britonish – ハチロク世代

本気の人もネタの人もいるようですが、みんなプログラミング言語に一家言あるんですね。個人的にはakiyanさんのあなたがプログラミングの初心者なら、友人知人が使っている言語にするといい : akiyan.comに賛成です。何を最初にやってもそんなに大差ないと思うし、聞く人が近くにいたほうがいいと思うし、職場や仕事によって言語はある程度限定されてしまうのでその中で使える言語を選択していくことになるかと思います。

最初に学ぶ言語としては上に述べたとおりですが、学んでよかった”最もタメになった言語”となると話は変わってきます。自分は大学でプログラミングを始めて

C言語(授業)→Perl(アルバイト)→Java(アルバイト)→PHP(アルバイト)→(Ruby)→C#(アルバイト)→C++(社内研修)→C言語とRuby(今)

と流れてきています。この中で選ぶとすると学んでよかった言語はRubyが1番でした。Javaが完全なオブジェクト指向でないと知ったのもRubyだし、”イテレータ便利!!!”って知ったのもRubyだし、プログラムは工夫次第で読みやすくなると知ったのもRubyでした。”初心者用言語”を書いてる皆さんが本当に学んでよかった言語って何なんでしょう? 聞いてみたいですね。

ちなみに今はふつうのHaskellプログラミング ふつうのプログラマのための関数型言語入門を読んでいて、関数型言語に興味を持っています。まだ半分ぐらいですがRubyを学んだときと同じくらいの学びが関数型言語にはありそうです。

Selective C PreProcessor(選択的 C プリプロセッサ)の略で、特定のディレクティブのみを処理できるCのプリプロセッサです。これを使うと不要な#ifdef～#endを除いたソースを作り出すことができます。内部開発用に入れておきたいコードがあるんだけど外部へのリリースには忘れず取り除かなくてはならない・・・といった用途に力を発揮してくれそうです。

仕事でも少し前に必要としていて探したんですが探し方が悪かったみたいです。このソフトはWindowsで動作するものなんですが残念ながら商用利用はできないとあるので仕事で使うのは無理そうです。でも

scpp (selective C preprocessor – 選択的 C プリプロセッサ) と呼ばれるソフトの Win32 移植版です。

ということはscppの実装は他にもいくつかあるんでしょう。

他の実装をご存じの方がいらっしゃいましたらコメントで教えてくださいm(_ _ )m

• scpp (selective C preprocessor) 0.1 (Win32 版)

デジタル信号処理のライブラリ一覧、目的別にかなりの数がリストアップされています。

今は使う予定はないけど車輪の再発明をしないように”いつか使う”。

はてなのid:higeponさんの今日の日記 ひげぽん OSとか作っちゃうかMona- – 雑談で知ったのですが、 ひらメソッドというソースコードを読む手法があるんですね。

上記URLで読んだ情報によると、ソースを細かい単位から読んでいくことで、分からない処理、分からない関数を極力減らすことにポイントがあるようです。たとえば　func1()がfunc2()を呼び出してfunc2()の中でさらにfunc3()を呼び出している

func1()→func2()→func3()

という状況ならfunc3を最初に読んで、次にfunc2、最後にfunc1を読みます。

ついでに各関数を読んでいるときにWikiを使って調べた内容を書き留めておくことも奨励されています。Wikiなら書くのも楽だし、向いているかもしれません。

ついでに見つけたのがGNU GLOBALの解析結果のHTMLにひらメソッド用で活用できるよう書き込みをできるようにした CodeReadingWikiです。Windows環境を前提として作られているようですが、ほぼ自動でWikiページの作成までしてもらえるのは便利ですね。

はてなのid:higeponさんの今日の日記 ひげぽん OSとか作っちゃうかMona- – 雑談で知ったのですが、 ひらメソッドというソースコードを読む手法があるんですね。

上記URLで読んだ情報によると、ソースを細かい単位から読んでいくことで、分からない処理、分からない関数を極力減らすことにポイントがあるようです。たとえば　func1()がfunc2()を呼び出してfunc2()の中でさらにfunc3()を呼び出している

func1()→func2()→func3()

という状況ならfunc3を最初に読んで、次にfunc2、最後にfunc1を読みます。

ついでに各関数を読んでいるときにWikiを使って調べた内容を書き留めておくことも奨励されています。Wikiなら書くのも楽だし、向いているかもしれません。

ついでに見つけたのがGNU GLOBALの解析結果のHTMLにひらメソッド用で活用できるよう書き込みをできるようにした CodeReadingWikiです。Windows環境を前提として作られているようですが、ほぼ自動でWikiページの作成までしてもらえるのは便利ですね。

Google Japan Blogで紹介されていたGoogleが公開しているプログラミング用ライブラリです。コマンドラインオプションをパースするのに使うgetoptよりも高機能で手軽に使えるようです。main関数に手を入れることなく、defineの定義の追加でオプション指定ができるのは便利ですね。

このライブラリのライセンスは修正BSDライセンス(New BSD Licence)です。著作権の表示と、無保証、免責をクリアすれば使えるかなり制限が緩いライセンスとのことです。これなら会社でも使えるなぁ。

• google-gflags – Google Code
• New BSD License || OSS iPedia

はてなブックマークで知ったmasuidriveさんのプロジェクトの方針を読みました。
masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針

作業スクリプトまでSubversionに入れて管理ってのはこれまで考えたことも無かったので新鮮でした。Tracのチケットというのも使ってみたいのですがこれはちょっと敷居が高そうに感じます。

職場でも使ってみたいですが、うちの場合は徐々に導入することになりそうです。

C言語の何かを調べている途中で見つけました。様々なデバッグのパターンをまとめているページです。読んでいると”あー、こういうことあるある”と納得することが多いです。

プログラミング初級者が読むと学ぶことは多いんじゃないでしょうか。

• モノーキ～デバッグパターン

netswitch! | netswitch!さんで知った RubyInlineが気になります．Rubyのソースでネックとなる箇所をインラインのC言語記述で置き換えることで高速化できるようです．

RubyにはC言語で作ったライブラリを組み込む機能が元々あって，大学時代の研究用プログラムで一部使っていましたがやっぱりインラインで書ける方が便利でいいですね．機会があったら使ってみたいと思います．

研修の内容が今日から変わってWDM(Windows Driver Model)になりました．Windowsで動作するドライバの作成方法を学びます．
- WDMとは 【Windows Driver Model】　─　意味・解説 ： IT用語辞典 e-Words

これまでのプログラミングとは違って地味です．動作も地味ですし，記述内容も工夫の余地が少なく決まった定型文を書くことが多いように感じます．おそらく今後ドライバを書くことは無いかと思いますが授業を受けていて新鮮な感じでした．

そしてWDMのプログラミングをしているとしょっちゅうブルースクリーンが見れます．研修が終わるまでに向こう3年分くらいのブルースクリーンが見れそうです．

現在研修でC++の勉強をしています．

独習C++

posted with amazlet on 06.09.05

ハーバート・シルト トップスタジオ 神林 靖
翔泳社 (2002/11)
売り上げランキング: 7,570

おすすめ度の平均:

C言語理解者には良書
ちと難しい気が・・・
良くも悪くも中級者向けの良書

Amazon.co.jp で詳細を見る

プログラミングはいろいろやりましたが独習シリーズに特にお世話になりました．この本は現在の研修のテキストでもあるので改めて全部読み直しましたが，前はよく分からなかった演算子のオーバーロードやテンプレートの使い方が今回はとても良く理解できました．でも今見るとサンプルソースコードのレベルがいまいちにも感じます．C++の文法は詳しいけどC++らしいプログラムを学ぶには向いていないようです．

Effective C++ 原著第3版

posted with amazlet on 06.09.05

スコット・メイヤーズ 小林 健一郎
ピアソン・エデュケーション (2006/04/29)

Amazon.co.jp で詳細を見る

そして，今読んでるのがこれです．研修の副読本として位置づけられているのですが読んでいて目からウロコがぽろぽろこぼれ落ちます．頑張っても1日100ページも読めません，内容が濃い本です．

これからはC++をメインに使っていくことになるので次はSTL周りの本を読もうと思ってます．良い本知ってたら教えてください．

naoyaのはてなダイアリー – 無線LANブリッジのIPアドレスを探せのソースコードを見て知ったのですが，標準出力に色を付けるライブラリがPerlにはあるんですね．見やすくなっていいなと感じました．

自分はRubyを使う機会が多いので，Rubyでも似たようなライブラリを探してみたところ Term::ANSIColor for Rubyというのを見つけました．

使い方は以下の通りです．
>>
require ‘term/ansicolor’

include Term::ANSIColor
print red, bold, “red bold”, reset, “\n”
< <

またはこんな書き方もできます．
>>
include Term::ANSIColor
print red(bold(“red bold”)), “\n”
< <

ブロックを使ってresetが自動で行われるようにする書き方もできます．
>>
include Term::ANSIColor
print red { bold { “red bold” } }, “\n”
< <

Mixinして既存クラスの機能を拡張することも可能とのことです．
>>
class String
include Term::ANSIColor
end
print “red bold”.red.bold, “\n”
< <

これは便利ですね．これから書くプログラムで積極的に使っていきたいと思います．

○追記
PHPでは PEAR :: Package :: Console_Colorがあるみたいです．