アイデアを形にする（「アイデアの９９％」を読んで）

「アイデアの９９％」を読むまで、自分のタイプを自覚できていなかった。厳密には、自覚はあっても、どうすべきかまでは思いが至らなかった。自分のタイプは、興味があちこちに移り、ひとつの事に集中できないと思えば、他の事が頭に入らないほど考え込んでしまったりで、夢追い人。片づけ魔では無い。
くどくて退屈な本「イノベーションの神話」には、死蔵していったアイデアの話が載っており、何か特別なアイデアが適切なタイミングで実現されなければいけないような事が書かれていたから、思い違いをしていたのだ。
アイデアを実現する＝ビジネスで成功する＝スタートアップで成功する＝政策を実現する＝日本を変える＝...とにかく何でも良い。そのためには、適切なアクションを起こすための仕組みを作る事だったのだ。アクション・メソッドに落とすとは、プロジェクト管理をキッチリと行う事に他ならない。アクション・メソッドとは、アイデアを実現するために、誰か(協力者・社員・パートナー・下請けなど)にわかる形(作業指示書)へ分解して推し進める単位である。
日本にはビジョナーがいないのではなく、プロジェクトを組んで仕事をするノウハウが足りないだけなのではと思う。

　自分の視点が変わったせいか、ひとつの事に取り組む姿勢を指摘した書き物が目につくようになった。しかも、ここ最近、よく目にする。一種のシンクロニシティを感じているところなのだ。これは決して偶然なのではなく、社会的な要請が、そこにあるからだと思う。（つい最近、目にしたものでは、瀬戸内寂聴先生の本で、政治家が「あれもやりたい、これもやりたい」と八方美人的に語っているのを叱責するもの。Software Design の震災でうまくいっているプロジェクトの特徴を述べたもの。など）

　日本の文化として、１７条憲法にあるように「和を以て貴しと為す」が根底にあるのかどうかしらないが、和を歪曲しているからなのかもしれない。あれも良いよね？うんうん、でも、これも良いよね？うんうん。でも、あれをこうしたら良いんじゃない？うんうん。良いよね談義で終わってしまっているのではないか？思い返せば、学校教育からしてひどかった。「何々についてどう思いますか？」「何々だと思います。」「何々してはいけないと思います。」「何々しないように気をつけましょう。」終止抽象的な話で終わって、これがアクション・メソッドにブレークダウンされるような事は無かった。アクション・メソッドは有っても、プロジェクトを組んで自分の頭で考える訓練なぞ皆無ではなかったろうか？お上ならぬ大人の考えたプログラムを実行する訓練ばかりでは無かったか？

　何事かを成すためには、一見、たいした事がないように思える事でも、多大なリソースが必要なのだ。特にグローバル競争で、中途半端なものは生き残れない。だから余計に最後までやり抜く覚悟が必要なのだ。やり抜くためには、実現するための具体的なアクション・ステップ（プロセス）に落とし込み、プロジェクト管理を行って、一歩一歩前進しなければならない。

　ソフトウェア業界に目を移せば、TPPで仕事がグローバルになっていけば、アイデアを形にするためのプロジェクト管理という手法は必須であり、避けて通れない問題になっていくでしょう。海外では、ファンクション・ポイント法により見積もりを作成し、予算と期間を決めて契約を行う時には、インセンティブ契約というのを結ぶ事もあるそうです。このインセンティブ契約とは、定数人員で期間が短工期に仕上がった場合、受注金額の残工期分を、発注側と受注側で折半するというもの。これでは、プロジェクト管理をしっかりとハンドリングし、本当に実績を上げているグローバルな会社と競争した時に勝てるはずもない。これは何もソフトウェアだけに限った話ではなく、官僚丸投げの政治家にも言える事であります。マネジメントされていないプロジェクトの行き着く先は、不幸そのものです。

　逆算で考えて行くと、アイデアを形にするためには、プロジェクト管理が必須であり、プロジェクト管理をするためには、何をゴールとするか明確なビジョンに落とし込む作業が必要なわけです。そのためにはマネジメントが必要で、ビジョンを伝え共有し、共有されたビジョンが何らかの形でプロジェクトの血となり肉となる必要があります。アイデアを形にするために足りないリソースがあれば、外部から持ってくる(調達）。これが、プロジェクト・チームとなるわけです。アライアンスの時代と言われていますが、１＋１＝３なのではなく、"H" + "e" + "l" + "l" + "o" = "Hello" な時代というのが本質では無いかと思います。

　それでは、どんなアイデアを形にすべきか？闇雲にアイデアを形にしていったとしても、事業として成り立たない可能性だってあります。俗に言う「スタートアップは、どんな問題を解決するのか？が明確でなければならない」とは、世の人々のために役立ち支持され、事業として成立するようなアイデアですか？を端的に問うたものです。ITにより様々なルールが変更され、従来のビジネスモデルが成立しない中、何を選択し、何に集中していくのか？マネジメントに携わる人は、本当に厳しい課題を突きつけられていると思います。

　尚、多数の本に登場するイノベーションを生み出す企業というのは、レベルが高すぎて一般企業の参考にはなりません。そういう意味では、ここで述べた論は、最低限の一歩を踏み出すためのものです。

追伸：技術者としての生き方についての考えは、後日、改めてエントリーにするかもしれません。

ブログの役割（時代は、やっぱりソーシャルなのかもしれない…）

Bloggerのレイアウトを元に戻した。動的ビューは、全体を見渡すには良いのだが、コード等が読みにくい。で、統計を見てみたのだが、投稿の内容によって閲覧のバラつきが顕著である。自分のポストする内容も、ごった煮なので波長の合う投稿と合わない投稿の格差が激しいというのも考えられるのかも..
　ブログの時代は終わった…とする煽り記事を目にする事もあるが、ブログに求められる役割が変わりつつあるのではないか？という気がしている。

• Twitter をやる人ならば、ちょっとした事は呟けば良い
• 今日こんな事があったよ。それいいね！共感を得たければ Facebook にポストすれば良い
• なんか知らんけど、ワーッと固まって騒ぎたければ Google+ にポストすれば良い

　Facebook というのは、連帯感を演出するには良いが、私には、ちょっと息が詰まる感じがして、そんなに楽しく無い。今はまだ、G+民というのは、どことなくギークっぽい人が多くて面白い。もしかしたら各サービスの役割が既に定着しているので、G+では、カテゴライズされたサークルを形成するというのが G+の役割なのかもしれない。嫁さんのブログの使い方だと、半分匿名のような緩い繋がりがあるようである。ただ、この繋がりは Twitter,Facebook,G+ 等に侵食されている気がしてならない。こうやって考えると、やっぱりソーシャルなのかな？と思う。ソーシャル、ソーシャルつうけど、元々、人間は社会的な生き物なので、その本質がデジタルになっただけなのだろう。

　では、ここでブログの役割について考えてみよう。

• 独り言日記
• ある分野に特化した情報
• 密度の濃い情報
• 距離を置いたマスメディア的な繋がり

と、こんなところに集約しつつあるでは？
相互的な繋がりが薄れている以上、トラックバックを削るという動きは、仕方が無いのか？
役割が絞られてきた以上、ページビューを稼ごうと思ったら、ブログに書くテーマは絞った方が良いだろう。逆に自分のスタイルを貫き通すのならば、ページビューに拘ってはいけない。

と、偉そうに分析してみたけど、どうブログを書こうと自由な事に変わりは無い。

インテル ソフトウェア カンファレンス 2011 札幌に参加してきた

札幌JRホテルで開催され、昼食付きで、「Cilkがやってきた」という本まで貰って、高速並列化の話まで聞けて凄いカンファレンスでした。なのに、席が空いている…。これはもったいないです。2012年も開催したいそうなので、札幌のC++の技術者は是非とも参加するようにしましょう。

　最初のセッションは、intel CPU Sandy Bridge の最適化について、SSEの流れを汲むベクトル・エクステンションのバス長が２倍の２５６に拡張されたAVXというものが登場とか、１次キャッシュ～３次キャッシュの構造やら、分岐予測の話やら、ロード＋演算の組がμops になった話、最初からレジスタにZEROを割り当てるゼロ・イディオムの話、プリフェッチ・キューの話やら、深良い話が聞けた。ハイパースレッドでは、コアで、キャッシュを共有するよなんてのは知らなかったです。
　tipsぽい話では、Sandy Bridge では、ローテーションとシフトの速度が逆転してますよとか、16bit命令と32bit命令を混在させるとペナルティ食らいますよとか、ロードバンク衝突があるので先にロードを済ませましょうとか、将来的には、CPUによる乱数生成命令がサポートされますよとか、RSDTC の拡張命令として、コア番号と経過クロックの組を返す命令がサポートされますよとか…。こうやって振り返ってみると、結構ボリュームがあります。

　続いて、インテル Parallel Studio XE の使い方から、コンパイラ・オプションの話。これまた、ためになる内容が盛りだくさん。普通はインテルのコンパイラを使うだけで、何もしなくても 30%ぐらいは速くなるから、人を導入して速度アップをするぐらいならコンパイラ買った方がマシって事になるみたいです。デモの内容を見ても、実際速くなってました。C++のコードを使って、OpenMPやら、自動ベクトル化(SSE命令)をしてマルチスレッドによる高速化なり、ベクトル演算による高速化なりを実現。コンパイル・オプションで最適化のヒントなんてのもあって、/Qguide4 とかすると、コンパイラが、「ここのベクトル化に失敗したでー」「ここのループは、マルチスレッドで並列化した方がいいでー」とか、べらべら羅列してくれて、面白い。

　インテル Cilk Plus によるソリューションというセッションが、また面白かった。OpenMP を使って並列化させる事は、できるけども職人技が必要で、速度を上げる事は難しい。例えば、並列化するにあたって、ジョブの割り当てを工夫しないと１つのスレッドに負荷がかかって他のスレッドが遊んでしまうとか、メモリ・キャッシュを考慮して処理単位をメモリが集中している粒度に分けて並列化するとか、奥が深い。これらの問題をもっと簡単に書けるようにしましょうというのが、Cilkだ。
　ちなみに GCC の次期バージョンでは、Cilkが実装されると決定しているようなので、決してインテル独自の仕様に留めるつもりでは無いようです。Cilk の特徴は、大きく３つあるように思います。

　１つ目は、MapReduce のように、並列化をサポートするための仕組みをサポートする事。下のコードは、動作検証していないので、雰囲気だけ味わってください。

cilk::reducer_list_append<char> res;
  cilk_for(int i = 'A'; i < 'Z'; ++i ) {
    res.push_back( static_cast<char>(i) );
  }

　こうする事で並列化しながら順序を保って処理がされます。cilk::reducer_opadd<int> とかを宣言して、合計の計算を並列化してみたりできます。

　２つ目は、副作用の無いループ中の演算表現。関数型言語を勉強していると、ピンとくるかと思います。私は、こう解釈しましたが、本当は、コンパイラがSSEの命令を使って最適化しやすい表記を考えたら、こうなったって事なのかもしれません。これも動作検証は未です。

y[:] += a * x[:];

　配列に対して、レンジ演算が記述できます。

　３つ目は、自動負荷分散。処理の単位をCilkが自動で分割し、スレッドへの処理割り当てを自動化してくれます。

　特別講演は、ディジタル・ワークス株式会社さまのインテル・コンパイラー導入事例紹介。TBB の allocator とか、tbb::concurrent_hash_map,tbb::concurrent_queue とか、速くていいです！との事。

　最後にインテル・アーキテクチャにおける並列分散処理のための技術交流サイト IA Software User Society がオープンしたので、皆さん是非参加してくださいとの事でした。会員になると、特別な資料とかも用意されています。無料です。

　インテル・ジャパンの皆様、XLsoftの皆様、ディジタル・ワークスの皆様、ありがとうございました。楽しかったです。

追記：Cilk は強烈で、今後を占う上で重要な役割を担いそうな印象を持っているのだが、この書き込みは人気が無いようだ…。

Unity MonoDevelop 文字化け備忘録

結構探したのに、なかなか情報が無くて困った。

補足すると、
/Applications/Unity/MonoDevelop.app/Contents/Frameworks/Mono.framework/Versions/Current/etc/gtk-2.0/gtkrc
のファイルを修正する。

私の場合は、
font = "Lucida Grande 12"
ではなく
font = "Lucida Grande 14"
であった。
これは、最後の gtk-font-name = "Lucida Grande 12" の部分ではなく、途中に記述されている部分なので、注意が必要だ。
これの後に、
font_name ="Hiragino Kaku Gothic Pro 10"
を追加する。

近況など

時間がとれなくて、コーディングできてません。破綻してると思います。「アイデアの９９％」最高に良いです。
　時々、自分の本の選び方とか、出来すぎてると思う事があります。あと、札幌ITリーディング(もうちょい戦略を持てという札幌市のIT企業強化事業)にて、都合良く、プロジェクトマネジメントのセミナーを受けて、３乗効果でインスピレーションを得たので、ビジョンを実現する事について書く予定です。
　休みの日は、坊ちゃんの相手で、趣味のコーディングどころか、読書すらままなりません。それは、それで、楽しいのですが...。
　と、まぁ、こんなところです。

WSDL2Ws Tool で再チャレンジ

WSDL2C で変換に失敗したスキーマを WSDL2Ws で再チャレンジ。結果は、やっぱりダメでしたが、まだ、こちらの方が希望が持てた。

　WSDL2Ws.java 中に以下のコメントが残されていたからだ…。

  //TODO the code require the attributes name at extension base types
  //different, the WSDL2Ws do not support it having same name at up and below.

  // The names of the inherited parms are mangled
  // in case they interfere with local parms.
  // String mangle = "";
  //if (i > 0) {
  // mangle = "_" +
  //  Utils.xmlNameToJava(te.getQName().getLocalPart()) +
  //  "_";
  //}

　ひっかかっているのは、xsd ファイル中の以下のような定義だ

   <xsd:element name="Add" type="ogc:BinaryOperatorType"
      substitutionGroup="ogc:expression"/>
   <xsd:element name="Sub" type="ogc:BinaryOperatorType"
      substitutionGroup="ogc:expression"/>
   <xsd:element name="Mul" type="ogc:BinaryOperatorType"
      substitutionGroup="ogc:expression"/>
   <xsd:element name="Div" type="ogc:BinaryOperatorType"
      substitutionGroup="ogc:expression"/>
   <xsd:element name="PropertyName" type="ogc:PropertyNameType"
      substitutionGroup="ogc:expression"/>
   <xsd:element name="Function" type="ogc:FunctionType"
      substitutionGroup="ogc:expression"/>
   <xsd:element name="Literal" type="ogc:LiteralType"
      substitutionGroup="ogc:expression"/>

まさに、type 属性が同じだけど、name 属性が異なるってやつだ。
はて、どうしたものか…。こいつら、大抵 enum で置き換えれそうだが、ソース吐き出すところまで全般に渡って手を入れないとダメそうだ…。とりあえず、スキーマを simpleType に置き換えて、後から enum にセコセコ修正する感じで逃げちゃうか？

axis cpp があった

　どうもリサーチ不足感は否めない…。よくよく探せば、Axis C++ バージョンがあった。

どいつもこいつも、ジェネレータが出力するコードが C なんで、階層が深いと、入れ子のメンバー要素を取得｜生成して、その入れ子の要素を取得｜生成して、そのまた入れ子のメンバー要素を取得｜生成して、そのまた入れ子の要素を取得｜生成してってーーーーー長いっちゅうねーーーーーーーーーーーーーん。

　こいつら全部ポインタです。しかも型が全部違うんで、再帰もできません。C 死ね。C 死ね。C 死ね。C 死ね。
C 死ね。C 死ね。C 死ね。C 死ね。
C 死ね。C 死ね。C 死ね。C 死ね。
C 死ね。C 死ね。C 死ね。C 死ね。
C 死ね。C 死ね。C 死ね。C 死ね。
C 死ね。C 死ね。C 死ね。C 死ね。

　それで、WSDLからのコードジェネレータは、どこにあんねーーーーーん！って、探したら、ありました。WSDL2WS-Tool です。

　という訳で、振り出しに戻ってます…。

cスタイル整形備忘録

自動生成されるコードの修正を結構やらなきゃいけない場合、スタイルが無茶苦茶だとしんどい。
astyle を使用する。

apt-get install astyle

とりあえず、K&R スタイルで整形するなり…

#!/bin/bash
for file in *.c
do
  astyle --style=kr -s2 -cc < $file > ${file%c}cc
done
for head in *.h
do
  astyle --style=kr -s2 -cc < $head > ${head%h}hpp
done

boost 勉強会 in 札幌に参加してきた

　講師陣の皆様、ありがとうございました。まずは、お礼を申し上げます。
まず最初は、cpp_akira さんの boost::geometry の話。コンセプト・ベースの部分は、設計の思想を知らないと使えないので、非常に為になる話でした。余談ですが、仕事上、geometry 系は使ってはいます。ただ、データ構造の関係でインナーポリゴンを一筆書きで扱っている事もあって、どちらかというと、boost::polygon の方でないと現状と合わないので、導入には至っていません。他には、図形の演算はデリケートな面があり、特にユーザさんが入力するデータや既存のデータには、恐ろしい構成点の組み合わせ（例:ポリゴンが閉じてるけど１点オーバランしている、穴空きポリゴンを一筆書きで表現しているが回しがねじれていて時計回りでも反時計周りでもない）への対応をしている。などがあります。挙動が変わると、まずいので、なかなか、切り替えるのも大変だったりします。後で、函数型のparaisoが刺激的で面白かったよという話をしたのですが、一応リンクをはっときます。

　で、uskz さんによる圏論のお話...圧倒的に会場を置き去りにして（と思う）、熱くHaskellいいよとまとまりました。個人的には、c++にはstd::cout やglobal 変数を更新するという恐ろしい函数の副作用がありますという次に、World が出てきたところがウケてました。先の並列化という面で考えれば、concept ベースのデータ構造に依存しない設計アプローチは、SIMDのような並列化とは相性が悪いのかな？と漠然と考えてました。

　fadis_さんのContainerFacade、微妙に違いのあるコンテナに対して、なるべく少ない手数でアルゴリズムを実装できるようにしようという話でした。ベースにあるのは、stlではイテレータを介してコンテナにアクセスしているから、コンテナの要素を挿入／削除するような事ができない、そこで、なるべく多くのコンテナに対してコードの補完ができるようにしようというものです。聞いてて思ったのは、リンクドリストのような構造のものに２分探査のアルゴリズムを実装しても全くの無駄なので、このアプローチは便利なように見えて、実は良くないだろう...でした。この辺に対して考慮をし、合わないアルゴリズムは、コンセプトを満たしていないからエラーにするといった改良を加えれば、面白いのかなぁという感想です。すかさず、cpp_akiraさんが、ダメ出ししていたので、さすがだと感じました。

　DigitalGhost さんの Template MetaPrograming as 式 DigitalGhostさんワールドが展開されていたような...質問も無いですよね？で終了されてたのが、ウケてました。

　主催者のhotwatermorningさんのPStade.OvenとEggの実装を読む ソースの追い方がデジャヴな感じで、面白かったです。あっち読んで、こっち読んで、考えて、またあっち読んで...確かに、Eggを読むのはしんどそうです。

egtraさんの char32_tとBoost.Xpressiveと、char16_t, char32_t ができたので、それを使いましょうという話で、文字コード変換が iconv か ICU 以外に特にライブラリが無くてどうしよう？という切実な訴え...道化師さんの babel もあるけど...不便には違いないです。windows に限定すれば文字コード変換のようなアプローチもあります。wconv.hpp は最初に書いた時点からは、若干設計が変わっていて、特殊化によってUNICODEとコードベース間の変換コードがカスタマイズできるよう考慮が加わってます。xpressive の対応の話も興味深かったです。これも、余談ですが、Linux で FreeType2 を利用した時は、char16_t でないと使えなくて、-fshort-wchar オプションを使用しました。

　Kikairoya さんの 組み込みでこそC++を使う100の理由 C++偏執狂には、面白すぎて、爆笑しまくり。楽しかったです。組み込みの世界のわからないチップの話を質問されて、例外とRTTIをオフにすれば、ooバイトぐらいに収まるので大丈夫ですと即答されていたのには、スゲーと感心してました。懇親会では、別の方KさんからチップセットのコンパイラがC++に対応していない実情もあるのでやむを得ない場合もあるけど、c++のコンパイラに通すと、型チェックを行ってくれるので有効な手法に間違いないという情報も得ました。

　redbolzさんの Boost.MSMの使い方 白状すると、ユースケースの中で、ステートチャート図だけは、何を書いていいのかさっぱりわかんねぇ状態の私には、耳が痛い話でもあり、有用な話でもありました。UMLからBoost.MSM のひな形コードを生成するツールに興味のある方は、ちょっと飲み会で話をしましょうとの事でした。

　ライトニングでは、道化師さんの #include の話、#include だけで、あそこまで話を引っ張れるのが凄いです。何でも、後から５分だよと聞かされて、ボリュームを減らしたのだとか...(^^;
懇親会でも、いろんな方と話ができて楽しかったです。

　皆さん、ありがとうございました。

追記：ひとつ、思い出しました。boost base64 への変換の実装は、iterator を利用しています。そのため、最終のバイト境界が３バイト以外では、終端を正しく終える事が出来ていません。Fadis_さんの ContainerFacade のアプローチならば、これをうまく扱えるのではないか？と感じました。

いろいろ

　毎度の事ながら、いろいろで...
「東電陰謀説は、実は文部科学省〜経済産業省の引き起こしたブーメラン効果」というエントリーを上げようとしたけど、見つからないリンク先とかあって、めんどくさくなり、ポストするのをやめた。教育、広告、広報活動、手の込んだやらせ、歪曲した推進のための資料など、こんだけやってれば、ブーメランで返ってくるだろうという趣旨。記録に残っているものとしては、ウィキペディアのホルミシス効果の編集履歴などを見れば、面白いのではなかろうか、お暇な人はどうぞ。

　考えてもみれば、ローカルBBS時代から、「朝のガスパール事件」など、この手のネガティブな芸風は確立されていたわけです。文字だけの対話には、ニュアンスの情報が無い上に記録に残されるので、受け手のちょっとした感情が増幅されてしまうのではないか？とも思います。もしかしたら、ニュアンスに文脈が託された日本語固有の問題なんじゃ？という気までします。梅田望夫さんが、日本残念と語った背景は、案外こんなところなのかも？と感じる今日この頃です。

　東京出張で、地方自治情報化推進フェアと全国SaaSベンダー連合会に行ってきました。クラウドビジネスは、もう定着しつつあると感じました。かなりレッドオーシャンな感じです。そろそろ違う事も考えないと、駄目そうです。変化、速すぎ。出張レポートをまとめつつ、現実逃避の書き込み...です

　本を買ってきました。
「アイデアの９９％」成功しないアイデア（ビジネス）には、何の価値も無いという事を肝に銘じよう

「任せる技術」代替できない部分は置いて、代替できそうな部分は任せないと...苦手な部分は再考しよう

「AsOne」本当は、こんな組織を目指さなきゃ駄目なんだろうなぁという趣旨

「リーダーの条件が変わった」現状の再確認

「年金は本当にもらえるのか？」河野太郎先生の指令、国民も勉強しましょう。

「BCG流経営者はこう育てる」参考のため

「諸行無常を生きる」震災をテーマにした本。大震災を前にして、諦めるという態度は、前向きに強く生きるという態度でもある。この言葉に惹かれました。

　今週末の土曜日は、札幌 Boost 勉強会。なんか、いいネタ無いかなと思いつつも、移り気で、何一つものにならず...（汗）余裕無い中、講師陣の皆さん、今頃、必死こいてるのかな...


　

C++でSoapは、マイノリティ？

ここんところ、プラットフォームに依存しない Soap ライブラリというテーマで、どハマリしてます。axis2 の wsdl2c では、xsd ファイル中の、abstract が処理できませんでした。GML の Filter も曲者でして、abstract な choise で４つのタイプに派生して、それぞれが、また、abstract で複雑に派生していきます。中には BinaryOp, UnaryOp とかもあって、SentenceStatement(文)とExpression(式)までXMLで表現しているので、人手でコードを補完して書くレベルを超えてます。あわよくばパッチを当ててやろうか？と思って、SchemaCompiler.java を読んでみたもののパッと修正できる代物では無さそうでした。C++ のコードは、XSLT を使って処理しているようでしたが、xsd:include を使ってないので、ごった煮でコードが読みにくい。
　で、まともに処理できたのは、gSOAP でした。SOAP Toolkit を使って ISAPI Extension を記述し、mod_isapi を利用するという手もあるとは思いますが…。
　はたと、思い出したように akaxsio2 引っ張り出してみたんですが、コンパイル通りませんでした。strcpy とか使っている部分は、string.h を include する。アドレス計算している部分は、int から stddef.h の ptrdiff_t に変える。unsigned int でなく size_t を使うといったあたりまでは、パッチを当てれそうでしたが、mutable output_file& の部分が、ちょっと厳しくて挫折しました。const output_file& に変えて、const_cast 使えば、なんとかなるかも…。でも gml のスキーマを通すのは、並大抵の事ではなく、akaxiso2 も通さなかったような記憶があります。akaxiso もちょろちょろソースを見たのですが、相当な大作です…。今なら、fusion とか使って、もっとクールに表現できそうな気もするけど、xml ライブラリは、しんどいですわ。
　お前、OpenSoap にパッチ当ててたやん？どないしてん？と思っている方もいるかもしれないので、触れておくと、ComplexType と array がサポートされていないので、使えませんでした。

放射能の航空測量の結果感想

　10月に入って、東京も含めて航空測量の結果が公表されているようである。久しぶりにデータを見てみたが、その感想を述べてみようと思う。静観すると書いておいて、何故言及するか？というと、ヒステリック過ぎる人が多いからで、書いておいた方がいいかなと思ったからである。現在はセシウムの分布もだいぶ落ちてきており、福島を中心とした一部が高いだけである。日本の気候は雨が多いので、だいぶ流れたのではないかと思う。
　また、除染の効果なのか、野菜のベクレル数も下がってきているので、３～６月ほど気にする事も無くなってきたように思う。魚に関しては、引き続き注視したいが、全体としては、良い方向に流れているのではないだろうか？
　東京などは、トンデルの論文でも有意な結果かどうかわからない程度の量である事がわかる。
　今頃になって、大騒ぎしているが、正直、反応が遅すぎるだろうと思う。もう線量は落ちてきていて、外部からちょろっと被曝する分には、どうって事は無いと思う。そういう意味では、つくづく事故直後の対応が残念でならない。SPEEDIの結果を有効活用できたはずである。発表してたとしても、せいぜい「痛いニュース」で大騒ぎされたぐらいで、日本ではパニックになる事は無かっただろうに…。
　尚、汚染の高い地域に関して、安全と言えるのかどうかについては、また別問題である。これについては、引き続き静観しようと思います。

XMLのschemaに日本語の要素名は、いい迷惑 on apache axis2c

正常な前処理トークンとなりませんの続き
要素名が日本語になっている部分を修正し、文法上エラーにならないようにして、wsdl2c で生成したソースファイルの中で、axis2_extension_mapper.c に対して、マッピングの修正をかける事にします。自動生成なので、コピペ・コーディングの変数名に修正をかけるのは、ちょっとしんどいので、boost preprocessor の出番です。

        /**
         * axis2_extension_mapper.c
         *
         * This file was auto-generated from WSDL
         * by the Apache Axis2/Java version: 1.6.1  Built on : Aug 31, 2011 (12:23:23 CEST)
         */

        #include "axis2_extension_mapper.h"

        #include "adb_foo_type0.h"
        #include "adb_foo_type1.h"
        #include "adb_Bar.h"
        
        // ここ
        #include <boost/preprocessor.hpp>
        #include <boost/preprocessor/cat.hpp>
        #include <boost/preprocessor/seq/for_each.hpp>
        #include <boost/preprocessor/tuple/elem.hpp>
        #include <boost/preprocessor/stringize.hpp>

#define TYPE_LIST \
(("要素名に","adb_要素名に",foo_type0))\
(("日本語を","adb_日本語を",foo_type1))\
(("使うなゴラー","adb_使うなゴラー",bar))

#define ADB_CREATE_MACRO(r,data,elem)  \
   if(0 == axutil_strcmp(type, BOOST_PP_TUPLE_ELEM(3,0,elem))) { \
       return (adb_type_t*) BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_create(env))); \
   }

#define ADB_CREATE_DEFAULT_MACRO(r,data,elem) \
   if(0 == axutil_strcmp(default_type, BOOST_PP_TUPLE_ELEM(3,0,elem))) { \
       return (adb_type_t*) BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_create(env))); \
   }

#define ADB_FREE_MACRO(r,data,elem) \
   if(0 == axutil_strcmp(adb_type_get_type(_object), BOOST_PP_TUPLE_ELEM(3,1,elem))) { \
       return BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_free_obj))( \
              (BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_t))*) _object, env); \
   }

#define ADB_FREE_DEFAULT_MACRO(r,data,elem) \
   if(0 == axutil_strcmp(default_type, BOOST_PP_TUPLE_ELEM(3,1,elem))) { \
       return BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_free_obj))( \
              (BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_t))*) _object, env); \
   }

#define ADB_DESERIALIZE_MACRO(r,data,elem) \
   if(0 == axutil_strcmp(adb_type_get_type(_object), BOOST_PP_TUPLE_ELEM(3,1,elem))) { \
       return BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_deserialize_obj))( \
              (BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_t))*) _object, env, dp_parent, dp_is_early_node_valid, dont_care_minoccurs); \
   }

#define ADB_DESERIALIZE_DEFAULT_MACRO(r,data,elem) \
   if(0 == axutil_strcmp(default_type, BOOST_PP_TUPLE_ELEM(3,1,elem))) { \
       return BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_deserialize_obj))( \
              (BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_t))*) _object, env, dp_parent, dp_is_early_node_valid, dont_care_minoccurs); \
   }

#define ADB_SERIALIZE_MACRO(r,data,elem) \
   if(0 == axutil_strcmp(adb_type_get_type(_object), BOOST_PP_TUPLE_ELEM(3,1,elem))) { \
       return BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_serialize_obj))( \
              (BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_t))*) _object, env, om_node, om_element, tag_closed, namespaces, next_ns_index); \
   }

#define ADB_SERIALIZE_DEFAULT_MACRO(r,data,elem) \
   if(0 == axutil_strcmp(default_type, BOOST_PP_TUPLE_ELEM(3,1,elem))) { \
       return BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_serialize_obj))( \
              (BOOST_PP_CAT(adb_,BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(3,2,elem),_t))*) _object, env, om_node, om_element, tag_closed, namespaces, next_ns_index); \
   }

        struct adb_type
        {
            axis2_char_t *property_Type;
        };

        /**
         * Auxiliary function to determine an ADB object type from its Axiom node.
         * @param env pointer to environment struct
         * @param node double pointer to the parent node to deserialize
         * @return type name on success, else NULL
         */
        axis2_char_t *AXIS2_CALL
        axis2_extension_mapper_type_from_node(
            const axutil_env_t *env,
            axiom_node_t** node)
        {
            axiom_node_t *parent = *node;
            axutil_qname_t *element_qname = NULL;
            axiom_element_t *element = NULL;

            axutil_hash_index_t *hi;
            void *val;
            axiom_attribute_t *type_attr;
            axutil_hash_t *ht;
            axis2_char_t *temp;
            axis2_char_t *type;

            while(parent && axiom_node_get_node_type(parent, env) != AXIOM_ELEMENT)
            {
                parent = axiom_node_get_next_sibling(parent, env);
            }

            if (NULL == parent)
            {
                /* This should be checked before everything */
                AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI,
                            "Failed in building adb object : "
                            "NULL elemenet can not be passed to deserialize");
                return AXIS2_FAILURE;
            }

            element = (axiom_element_t *)axiom_node_get_data_element(parent, env);

            ht = axiom_element_get_all_attributes(element, env);

            if (ht == NULL)
                return NULL;

            for (hi = axutil_hash_first(ht, env); hi; hi = axutil_hash_next(env, hi)) {
                axis2_char_t *localpart;
                axutil_hash_this(hi, NULL, NULL, &val);
                type_attr = (axiom_attribute_t *)val;
                localpart = axutil_qname_get_localpart(axiom_attribute_get_qname(type_attr, env), env);
                if (axutil_strcmp(localpart, "type") == 0) break;
            }

            type = axiom_attribute_get_value(type_attr, env);
            if (type != NULL && (temp = axutil_strchr(type, ':')) != NULL)
            {
                if (axutil_strchr(temp, ':') != NULL)
                    type = temp + 1; /* Pointer arithmetic */
            }

            return type;
        }

        axis2_char_t* AXIS2_CALL
        adb_type_get_type(const adb_type_t *object)
        {
            if (object != NULL)
              return object->property_Type;

            return NULL;
        }

        adb_type_t* AXIS2_CALL
        axis2_extension_mapper_create_from_node(
            const axutil_env_t *env,
            axiom_node_t** node,
            axis2_char_t *default_type)
        {
            axis2_char_t *type = axis2_extension_mapper_type_from_node(env, node);

            if (type != NULL)
            {
              // ここ
              BOOST_PP_SEQ_FOR_EACH(ADB_CREATE_MACRO, _, TYPE_LIST)
            }
            // ここ
            BOOST_PP_SEQ_FOR_EACH(ADB_CREATE_DEFAULT_MACRO, _, TYPE_LIST)

            return NULL;
        }

        axis2_status_t AXIS2_CALL
        axis2_extension_mapper_free(
            adb_type_t* _object,
            const axutil_env_t *env,
            axis2_char_t *default_type)
        {
            if (_object != NULL && adb_type_get_type(_object) != NULL)
            {
              // ここ
              BOOST_PP_SEQ_FOR_EACH(ADB_FREE_MACRO, _, TYPE_LIST)
            }
            // ここ
            BOOST_PP_SEQ_FOR_EACH(ADB_FREE_DEFAULT_MACRO, _, TYPE_LIST)

            return AXIS2_FAILURE;
        }

        axis2_status_t AXIS2_CALL
        axis2_extension_mapper_deserialize(
            adb_type_t* _object,
            const axutil_env_t *env,
            axiom_node_t** dp_parent,
            axis2_bool_t *dp_is_early_node_valid,
            axis2_bool_t dont_care_minoccurs,
            axis2_char_t *default_type)
        {
            if (_object != NULL && adb_type_get_type(_object) != NULL)
            {
                // ここ
                BOOST_PP_SEQ_FOR_EACH(ADB_DESERIALIZE_MACRO, _, TYPE_LIST)
            }
            // ここ
            BOOST_PP_SEQ_FOR_EACH(ADB_DESERIALIZE_DEFAULT_MACRO, _, TYPE_LIST)

            return AXIS2_FAILURE;
        }

        axiom_node_t* AXIS2_CALL
        axis2_extension_mapper_serialize(
            adb_type_t* _object,
            const axutil_env_t *env,
            axiom_node_t* om_node,
            axiom_element_t *om_element,
            int tag_closed,
            axutil_hash_t *namespaces,
            int *next_ns_index,
            axis2_char_t *default_type)
        {
            if (_object != NULL && adb_type_get_type(_object) != NULL)
            {
                // ここ
                BOOST_PP_SEQ_FOR_EACH(ADB_SERIALIZE_MACRO, _, TYPE_LIST) 
            }
            // ここ
            BOOST_PP_SEQ_FOR_EACH(ADB_SERIALIZE_DEFAULT_MACRO, _, TYPE_LIST) 

            return AXIS2_FAILURE;
        }
    

こういうのって、精神的に消耗しますね…

正常な前処理トークンとなりません

XML のスキーマ定義ファイルの要素名に日本語を使うやつがいて、そのおかげで、apache axis2 を使って、wsdlファイルからcソースを自動生成したのだが、ファイル名と変数名が日本語で出力されてしまった。ぬぉーーーっ、設計したやつ何考えとんじゃーと怒りながら、対策を考えた末、boost preprocessor で対処するのが一番だろうとテストしてみたが、一筋縄ではない。こういう設計した人に限って、別にXMLの仕様には反していませんよね？とか言いそうな気がして、ひとり、ぼやきまくっていた…。
　どこで詰まってるんやろ？と追試していると、どうやらマクロ展開する過程で、１回処理した直後に、規格通りかどうかのチェックが入っているからと推察する。

#include <boost/preprocessor/cat.hpp>
#include <boost/preprocessor/tuple/elem.hpp>
#include <boost/preprocessor/seq/for_each.hpp>
#include <boost/preprocessor/stringize.hpp>

#define TYPE_LIST \
((システム,1))\
((x,2))\
((y,4))\
((z,3))

#define MACRO(r, data, elem) BOOST_PP_STRINGIZE(BOOST_PP_CAT(BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(2,0,elem), _hoge_),BOOST_PP_TUPLE_ELEM(2,1,elem)))

BOOST_PP_SEQ_FOR_EACH(MACRO, _, TYPE_LIST)

x.cpp:14:1: エラー: "�" と "_hoge_" を貼付けましたが正常な前処理トークンとなりません

　こいつを避けるためには、日本語部分は最初から文字列リテラルとして記述しておく必要がありそうだ。幸い、日本語部分の表現は、１種類につき2通りしかないので、BOOST_PP_TUPLE_ELEM で対処しても、そんなにしんどくなさそうだ。
UTF-8 が標準ならば…と、ちょっと考えてしまう一幕でした。

いろいろ

　iTunes の環境を Windows から MacBook に変更しました。家での環境は、まじめに MacBook をメインにしようと思っています。Scansnap は、mac バージョンを間違って買ったのですが、心のどこかで確信的間違えたのではないか？と思うようになりました。

本日は、「大震災の後で人生について語るということ」と「日本の未来について話そう」の２冊を購入した。G＋の方で紹介してもらった「虐殺器官」も、ちょい前にゲットした。どうでもいい事ですが、Web+DB 本屋に置いてなくて、がっくし...

ギリシャの暴動を見ていると、「ないものねだり論者」というのは、世界的な潮流なのではないか？と、同意したくなってきました。違和感を感じている部分と、同意したい部分と２通りあります。日本の震災の放射能に関する考え方の分断では、２通りの人間がいるという事なのかもしれないです。他人を心配する事で、安全とする人たちへの態度を硬化させるグループと、単純に文句を言うだけのグループです。前者の中にも、好きになれない例外の人はいますけど...。隣人への愛という点では、前者のグループも、そこからスタートしているので、そこを見間違えてはいけないと思います。それだけです。
隣国の韓国も、なかなかのものです。韓国の現状を見ていると、グローバル競争の元に、やりたいようにやったらLG電子やサムスンなど、市場を制覇する事ができたが、気がつけば、制覇した分だけ未曾有の借金が残っていて、LG電子は赤字転落で、液晶パネルの競争は国家的なダンピングだったのではないか？とも思えてきます。円高やべぇと騒いでたけども、実は白川総裁の考え方が正しくて、世界中の皆が間違っていたのでは？とも思えてきます。経済は雲をつかむようで、ほんと難しいです。世界経済もDQNが牛耳っていた？？？

カダフィ大佐の死体の写真を見ていて、スマートフォンに取り囲まれている様子が象徴的だと感じました。皆さんは、いかがでしょうか？拡散するのは、いいけれど、せめて、ワンクッション置いた方がいいとも思います。

追記:ひとの弱みにつけ込んで、商売するような人は、カウントしていません。

XMLを処理するのに…

Windows で C++ にて XML を処理しようと思ったら、考えられそうな選択肢がいくつかあります。

• LibXML2
• Expat
• MSXML
• TinyXML
• XMLLite
• Xerces-C++

そこで、なるべくならプラットフォームを固定して書きたくないので、MSXML と XMLLite が候補から外れます。
LibXML2 でやろうとしたら、ICU か iconv あたりをなんとかしないといけません。正直 iconv はmsvc でコンパイルするのが困難です。libiconv for windows ありますが、vc で、すんなりコンパイルが通りません。じゃあ ICU だわさ？って、ICUを使おうとすると、icu.lib が無いとか変なリンクエラーが出て萎えてしまいます。ICU も大げさな感じがして、使うのをちょっと躊躇われるのという事情もあります。
おまえ、選り好みが激しすぎと怒られそうですが、Xerces-C++ も、なんか、あんまり好きじゃないんです。
TinyXML もいいんですけど、ちょっと考えてしまう…（こんな事ばかり書いてると、いい加減に袋叩きにあいそう）。

そうすると残されたのは、Expat って事になります。ところが、この Expat って、SJIS に対応していないんですよね…。APIで日本語対応するって事も可能なんですが、なんというか、どうもしっくり来ない。XMLの構文を解析するついでに、文字コード変換もやりましょうという思想なんで、1文字か2文字づつコード変換の処理をしなきゃならない。これ、文字コード変換ライブラリのメンテナンスも考えたら、結構大変です。SJIS に限って言えば、SJIS第一バイトの場合は２バイト処理します。なんつーか、もやもや～とするんですよねー。

で、結論は何かと言うと、そもそも wchar_t が嫌い。これに尽きるんですわ。UTF-8 は、ほんと良く出来てると思います。

結局、自分の好みでやってくと、「文字コード変換」と「expatで遊ぼ」を組み合わせて、こんな感じになってしまいました。ただ、encoding の指定が全然関係ないやん…って部分が気に入りません。

#include <iostream>
#include <string>
#include <vector>
#include <expat.h>
#include <boost/shared_ptr.hpp>
#include <boost/foreach.hpp>

#include "codepage.hpp"
#include "wconv.hpp"

class xml_node;

class xml_node {
public:
  xml_node( const XML_Char* name ) : node_name_(name) {}
public:
  std::basic_string<XML_Char>  node_name_;
  std::basic_string<XML_Char>  node_value_;
  std::vector< boost::shared_ptr<xml_node> > childs_;
};


class xml_holder {
public:
  std::vector< boost::shared_ptr<xml_node> >  stack_;
  boost::shared_ptr<xml_node>  current_;
};

void starter(void* userData, const XML_Char* name, const XML_Char* attrs[]) {
  xml_holder* holder = reinterpret_cast<xml_holder*>(userData);
  holder->stack_.push_back( holder->current_ );
  boost::shared_ptr<xml_node> element( new xml_node( name ) );
  holder->current_->childs_.push_back( element );
  holder->current_ = element;
}

void ender( void* userData, const XML_Char* name) {
  xml_holder* holder = reinterpret_cast<xml_holder*>(userData);
  holder->current_ = holder->stack_.back();
  holder->stack_.pop_back();
}

void data( void* userData, const XML_Char* s, int len ) {
  xml_holder* holder = reinterpret_cast<xml_holder*>(userData);
  holder->current_->node_value_.assign( s, s + len );
}

void trace( int depth, boost::shared_ptr<xml_node> elem ) {
  for( int i = 0; i < depth; ++i ) { std::cout << " "; }
  std::cout << elem->node_name_ << ":" << code_to_code<CP_ACP,CP_UTF8>(elem->node_value_) << std::endl;
  BOOST_FOREACH( boost::shared_ptr<xml_node> e, elem->childs_ ) {
    trace( depth+1, e );
  }
}

bool parse_xml( const std::string& xml ) {
  xml_holder holder;
  holder.current_ = boost::shared_ptr<xml_node>( new xml_node( "root" ) );
  XML_Parser  parser = XML_ParserCreate("UTF-8");
  if( !parser ) return false;
  XML_SetUserData( parser, &holder );
  XML_SetElementHandler( parser, starter, ender );
  XML_SetCharacterDataHandler( parser, data );
  int iseof = 0;
  XML_Parse( parser, xml.c_str(), xml.size(), iseof );
  XML_ParserFree( parser );
  trace( 0, holder.current_ );
  return !iseof;
}

#include <fstream>

int main(int argc, char* argv[] ) {
  if( argc != 2 ) return 1;
  std::ifstream ifs( argv[1] );
  std::string xml;
  std::string line;
  while( ifs.good() ) {
    std::getline( ifs, line );
    xml += line;
    //std::cout << line << std::endl;
  }
  //std::cout << std::endl;

  parse_xml( code_to_code<CP_UTF8,CP_ACP>(xml) );

  return 0;
}

spirit::qi raw 習作

#include <iostream>
#include <boost/spirit/include/qi.hpp>


int main() {
  std::string src = "123456789";
  int a, b, c;
  
  namespace qi = boost::spirit::qi;
  bool result = qi::phrase_parse( 
    src.begin(), src.end(), 
    qi::raw[ qi::repeat(2)[qi::digit] ]
    >> qi::raw[ qi::digit >> qi::digit ]
    >> qi::int_
    ,
    qi::ascii::space,
    a, b, c
  );

  if( result )  std::cout << a << "," << b << "," << c << std::endl;
  else std::cout << "fault" << std::endl;

  return 0;
}

boost::range 習作３ (reference)

#include <boost/assign.hpp>
#include <boost/bind.hpp>
#include <limits>
#include <iostream>
#include <vector>
#include <boost/range/algorithm/for_each.hpp>
#include <boost/foreach.hpp>
#include <boost/ref.hpp>

struct minmax {
private:
  int max_;
  int min_;
public:
  minmax() : min_(std::numeric_limits<int>::max()), max_(std::numeric_limits<int>::min()) {}
  void operator() (int val) {
    min_ = std::min( min_, val );
    max_ = std::max( max_, val );
  }

  int get_min() const { return min_; }
  int get_max() const { return max_; }

};

int main(int argc, const char* argv[]) {
  using namespace boost::assign;

  std::vector<int> input;
  input += 1,2,3,4,5,6,7,8,9;

  {
    minmax mm;

    std::cout << "range foreach with functor" << std::endl;
    boost::for_each( input, mm );
    std::cout << mm.get_min() << "," << mm.get_max() << std::endl;
  }
  {
    minmax mm;
    std::cout << "range foreach with bind" << std::endl;
    boost::for_each( input, boost::bind( &minmax::operator(), &mm, _1 ) );
    std::cout << mm.get_min() << "," << mm.get_max() << std::endl;
  }
  {
    minmax mm;
    std::cout << "macro base foreach" << std::endl;
    BOOST_FOREACH( int val, input ) {
      mm( val );
    }
    std::cout << mm.get_min() << "," << mm.get_max() << std::endl;
  }
  return 0;
}

追記：これは、1,9 の集合を返す関数に変形すべき？

mod_auth_kerb で統合認証

1.構成について

ドメイン名：foo.local
ドメイン・コントローラ：dom1.foo.local, dom2.foo.local
DNSサーバ：dom1.foo.local, dom2.foo.local
大文字ドメイン名:FOO
Windows Server は 2003 Server 以上を想定して書いている。
これに対し、CentOS で Apache環境を構築し、連帯する

2.必要モジュールのインストール

$ yum install mod_auth_kerb

3.Windows Domain Server 上での作業

ドメインのユーザとして、kerblinux1というアカウントを作成します。このアカウントは、統合認証のためだけに使用されるので、パスワードを入力する事がありません。よって、パスワードは長くして耐久性を持たせるようにします。

C:\>ktpass 
 –princ HTTP/linux1.foo.local@FOO.LOCAL 
 –mapuser kerblinux1@FOO.LOCAL
 -crypto RC4-HMAC-NT
 -ptype KRB5_NT_PRINCIPAL
 -pass nagai.nagai.password.wo.sextutei.suru
 -out e:\USBDISK\linux1.keytab

として、統合認証で必要なアカウントのkeytabファイルを作成します。

4.Kerberos設定

/etc/krb5.confを設定します。

[libdefaults]
 default_realm = FOO.LOCAL
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_life_time = 24h
 forwardable = yes

[domain_realm]
 foo.local = FOO.LOCAL
 .foo.local = FOO.LOCAL

[realms]
      # 実験した環境では、dom1.foo.local とURIをフル修飾すると
      # サーバを正しく認識しなかった。
 FOO.LOCAL = {
  kdc = dom1
  kdc = dom2
  admin_server = dom1
 }

手順 3. で作成した linux1.keytab ファイルを /etc/httpd/conf にコピーします。

$ cp /usbdisk/linux1.keytab /etc/httpd/conf/linux1.keytab
$ chown apache:apache /etc/httpd/conf/linux1.keytab
$ chmod 640 /etc/httpd/conf/linux1.keytab

実際にケルベロス認証が通るかチェックを行います。valid_user は、実際の有効なアカウントに置き換えて試します。

$ kinit valid_user@FOO.LOCAL

5.Active DirectoryでのSSPI認証

認証すべきディレクトリに、以下の設定を施します。ここでは、”.htaccess”というファイルを作成し、そこに制約を加える事にします。この他に、httpd.conf のディレクティブとして記述する方法もありますが、基本は変わりません。

AuthType           Kerberos
AuthName           "Kerberos Login"
KrbAuthRealms      FOO.LOCAL
KrbServiceName     HTTP/linux1.foo.local
KrbMethodNegotiate On
KrbMethodK5Passwd  Off
Krb5KeyTab         /etc/httpd/conf/linux1.keytab
Require            valid-user

これで、「統合Windows認証を使用する」設定になっている(IEデフォルトのようです)Internet Explorerからアクセスすると統合認証でアクセスされるようになります。尚、ゾーンがイントラゾーンかどうかの判定には、URL に「.」が含まれているかどうか？が基準となっているようです。よって、本例では、「http://linux1.foo.local/」ではなく「http://linux1/」でアクセスしないとシングルサインオンになりません。

6．認証後のアクセス制限に関して

　mod_auth_kerbによる統合認証では、認証が通っても、あくまでActiveDirectoryに認証してもらった正規のユーザ名の情報がセットされるのみです。ウェブ上のシステムでは、このユーザ名をキーとして、権限の制約を別途管理する事になります。


参考文献
http://grolmsnet.de/kerbtut/
http://www.dokuwiki.org/auth:ad


追伸：Bloggerプレビューできねぇーぜ、どうやって確認すんねん？？？くっそー

もやもやっと

　なんとなくですが、「当事者性ｖｓないものねだり論者」の云わんとする事がわかった気がした。要するに、お客様感覚が抜けずに、ダダをこねるだけの人が多いのだ。実際に行動を起こさなければならないのだが、そこへの思慮が欠けている。今の時代、経営者感覚が求められる時代なのだが、想像力も無ければ思考も足りないのだ。知者ではあるけども、賢者ではない。まぁ、実際に問題を解決するためには、何か行動を起こさなければならないので、知者から愚者と批判されるかもしれんが・・・。
　焼却灰や下水道の高レベル放射能セシウム１３７＋１３４は、どこかに破棄しなければならない。原発事故を起こした「ふくいち」近辺にまとめるのが、客観的にみて最も妥当な方法であると思うのだが、福島県民は嫌だと大多数の人が反対しているという。半数はセシウム１３４だとして、半分の量は無視したとして、半減期３０年なので、＊万ベクレルの下水汚泥であれば、1/2~10 = 1/1024 すれば、だいたいの人に害が無いレベルまで落ちる。その間、同様に汚染されすぎた土地を除染するのは、並大抵の事ではないし、わざわざ汚染されていない土地に放射能を運ぶのは、経済的に見てもリスク的に見ても、全く非効率きわまる。誰かが、こういう事は、きちんと説明してやらなければならない。
　気に入らないという理由で絡んでくる人は、エネルギーを費やすベクトルが違っているのだ。

　こういう理解をした上で、あえて「当事者性ｖｓないものねだり論者」論は、３割ほど有害だと感じている。まず、みんなの言う事は、間違っているように見えて、案外正しいのである。内田樹先生の「陰謀史観」も、何の事を指して言っているのか、私にはサッパリわからない。これこそ話を単純化しすぎではないか？

もやっと

　ここんところ、ほとんど、独り言に近い、とりとめのない事ばっかり書いてます。こういうのって、後から読むと、あんまし面白くないんですが…（汗）

　今日は本屋に行って「Googleの脳みそ」と、「Unity入門」を買ってきました。「Googleの脳みそ」は、本屋で手に取った瞬間にピンときました。3.11以後、非常に残念な論調が多くてゲンナリしている所なので、感情論では無い視点から、今を読んでみたかったのでチョイスしました。「Unity入門」の方は、完全に趣味です。ゲームを開発しようとか、そんな事、全く考えていません。癒しのための写経本にするつもりです。時間無いかもしんないけど…。

　Google+ つながりが面白いけど、正直SNSは、自分には向いていないかもしれない(^^;。どうなんだろ…？実際のGoogle+の使われ方と、Googleが想定して設計した使われ方が違うような気がしています。

　Google では、同じ志向を持った人がサークルで繋がって、切り分けていく世界をデザインしたと思ってます。だから、基本は繋がる人は何らかの知人で、どの分野で繋がりたいかユーザは知っているという前提が成立しているはずです。
　ところが、実際に使っている人は twitter と似た感覚で、この人面白そうだからフォローしてみようという感覚が強いと感じてます。こちらからフォローをする前に、どのサークルに入れたら良いものか、もの凄く判断に悩みます。まさか、IT系の話で盛り上がりたい人に、バリバリのプログラミングの話題を投稿するのは気が引けるので、基本情報やストリームを見て判断してますが、わかんねぇです…。

　もひとつ迷うのが、どこに向けて投稿しようか？って事。基本はブログに書いていくつもりです。なので、Google+での発言のS/N比は、どうしても落ちちゃう。ここは、ブログをしている人と、していない人で発信能力に格差が出てくるのかなぁーと…。ブログにポストした事を転送するのも手ですが、それじゃーGoogle+をする意味が無い。

Symfony2勉強中

　訳あって、Symfony2を勉強してます。いろいろとフレームワークを見てきましたが、Symfony2は、なかなかよくできている感触を得てます。メタキャッシュの機構も優れている感じで、twigも書きやすいのかなぁと。

　今のところ使う予定は無いですが、mongodbにも対応しています。

　と、近況を書きましたが、本当は、ここからが本題だったりして・・・
放射能の問題は静観する事にしました。５年は結論が出ないだろうと考えてます。私は当事者では無いので、語る資格などないのでしょう。色々な意見を見ますが、読むにつけて、呆れると共に嫌な気分になります。せめてデータだけは、ちゃんと取って検証できるようにしてもらいたいものです。現代は、データ実証主義です。データなんか取っても無駄という思考ではなく、まずはデータを取ってみよう、そこから何がわかるか、検証してみよう・・・です。

いろいろ

　ちゃんと書こうと思うんですが、まとめるのもしんどいので・・・（って、こんな事言ってるようじゃいかんのですが）。
ま、ぼやきです。
　仕事たまってます・・・処理しきれません・・・。守備範囲広すぎ・・・。ビジネスのあり方が根本から変わってきていて、スピードが要求されます。で、いきなり、これ出来ないか？つか、出来ないと困るんだけど？やらないとダメだよね？つか、標準だよね？って事、多すぎです。スピード感を持って調べる、対応する・・・。自然と仕事が増えるわけです。サービス指向へ移行するために、現在、クラウドっぽい受託になってます・・・。
　
　Ｐマークの仕事（個人情報管理責任者）で、規定の見直しやらレビューやら・・・（重てぇ・・・）
　要求仕様を満たすための技術調査もの・・・環境を構築して動作検証まで・・・（かなり時間をとられるよ・・・）
　標準対応するための仕様書査読と技術対応のための調査・設計・コーディング・・・（細けぇ・・・）
　新しい案件に対する対応、構成や見積もりなど・・・（地味に来ます・・・）
　マネジメント・・・（正直、手が回らん・・・）
　次の製品プロダクト開発（設計・コーディング）・・・（重てぇ・・・）
　既存システムのサポート・・・（ものによっては数日飛ぶ事も・・・）
　技術者としての将来構想など・・・（遊びの部分・・・時間とれねぇ・・・）
　他雑用・・・

うーん・・・中小企業では普通なのかな・・・。

　最近、読んだ本など・・・。iPad 地球書店VoyagerBooksで安売りしてたので、河野太郎先生の「これからの日本の政治の話をしよう」べたなタイトルですが、食料自給率のトリックなど、隅々まで現在日本が抱えている政治的問題について、忌憚無く、よく書かれてあります。内容も読み易いので、お勧めしたいです。
　「ご機嫌な職場」読者購読の和を通じて知りました。実は、Free よりも、今の時代に即した重要な位置付けとも言える内容です。情報革命によりグローバル競争へと突入した今、どのような職場が必要とされているか？について、時代背景と共に説明されています。
　「人を活かす経営」マネジメントの時代、原点は、ここにあるという意味で読みました。リソースが足りないと、この辺が、おざなりになるので、考えないわけにはいきません。

opensoap-2.0.1 src patch

Opensoap を使おうと思って、ubuntu環境でコンパイルかけたら、コンパイルが通らなかったので、ソースにパッチを当てました。一応、公開しときます。リンク先ダメだった場合、私の SkyDrive の方から opensoap-2.0.1_ubuntu.diff をおとして下さい。

boost::range 習作２

#include <boost/range/algorithm/for_each.hpp>
#include <iostream>
//#include <boost/array.hpp>
#include <boost/bind.hpp>

void disp2( int a, int b, int c ) {
  if( b == 3 ) throw 1;
  std::cout << a << ":" << b << ":" << c << ",";
}


int main() {
  //boost::array<int,5> arr = {{ 1, 2, 3, 4, 5 }};

  int arr[] = { 1, 2, 3, 4, 5 };

  try {
    boost::for_each( arr, boost::bind( disp2, 3, _1, 4) );
  } catch( int err ) {
    std::cout << "ERR: " << err << std::endl;
  }

  return 0;
}

レガシーAPI、ほとんど制覇できるかも・・・強烈だな・・・

胸熱で眠れねーよ

　腐ってる。何もかも腐ってる。建設的な意見など通じないだろうと思うぐらい腐っている。
　脆弱な政治家失脚システム。偽名を使って外国人から献金を受けた程度で、説明責任を追及されたりする。
　未だに東電から２００億円とも言われる広告費で買収されているマスゴミも、ここぞとばかりに、官僚が気に入らない政治家潰しに加担している。
ＮＨＫいわく、「放射性物質がうつった」
朝日いわく、「放射能をつけちゃうぞ」
読売いわく、「ほら、放射能」
産経いわく、「放射能をうつしてやる」 「放射能をなすりつける」　どっちやねん
毎日いわく、「放射能をつけたぞ」
日経いわく、「放射能をつけてやろうか」
４７ニュースいわく、「放射能をうつす」
時事いわく、「放射能を付けたぞ」

　デマッターソースでは、こういう話の流れだったらしい。
　これのどこに落ち度があんの？？？あーーっ？？？これをぶち切れ声で追求するマスゴミ。東電の会見には猫なで声で、礼儀をわきまえろとかほざくくせに、何だけれーーーーーーーーーーっ。
　野田総理も総理だ。こんな辞任、いちいち認めるなよ。何考えてんだ？
　そして、反原発デモでの出来事だが、警察と右翼が結託して、右翼が暴力をふるい、それに反発したデモ参加者を警察が寄ってたかって取り押さえ、暴力をふるった側には見向きもせずに、逮捕者が10人以上出てるというじゃないか？なんじゃこれ？
　相変わらずＮＨＫと日本国民総白痴化テレビ（株式の比率まんまでいいから消えてくれ）は、大規模デモに対してダンマリ。
　こんな糞みたいな事が、堂々とまかり通ってると思うと、眠れねーよ。

boost::range 習作

ポイント： map の代わりに Loki::AssocVector でも大丈夫か試してみた。 foreach は２種類使ってみた。 0x は、お預け 最初 vv 指定すべきところを、input 指定してコンパイルエラーになるという初歩的ミスを犯してしまった。

#include <boost/range/adaptor/map.hpp>
#include <boost/range/adaptor/filtered.hpp>
#include <boost/assign.hpp>
#include <iostream>
#include <vector>
#include <Loki/AssocVector.h>
#include <boost/foreach.hpp>
#include <boost/range/algorithm/for_each.hpp>

struct is_even {
  bool operator()( int x ) const { return x % 2 == 0; }
};

struct is_bigger {
  int val_;
  is_bigger(int val) : val_(val) {}
  bool operator()( int x ) const { return x > val_; }
};

void disp( int x ) {
  std::cout << x << ",";
}

int main(int argc, const char* argv[])
{
    using namespace boost::assign;
    using namespace boost::adaptors;

    std::vector<int> input;
    input += 1,2,3,4,5,6,7,8,9;

  BOOST_FOREACH( int n, input | filtered(is_even()) ) {
    std::cout << n << ",";
  }
  std::cout << std::endl;

  Loki::AssocVector<int,int> vv;
  for( int i = 1; i < 10; ++i ) {
    vv[i] = i * 10 + i;
  }

  boost::for_each( vv | map_values | filtered(is_even()), disp );
  std::cout << std::endl;
  is_bigger ib( 50 );
  boost::for_each( vv | map_values | filtered(ib), disp );
  std::cout << std::endl;
  is_bigger ib2( 80 );
  boost::for_each( vv | map_values | filtered(ib2), disp );
}

「当事者性vsないものねだり論者」という新しい対立軸について思う

「当事者性vsないものねだり論者」という新しい対立軸というのをGoogle+のサークルで教えてもらった。

私も３．１１以後、政府の対応を強烈に批判している立場なので、耳が痛いところだ。この対立軸で自分を分析すると、当事者、兼、モンスターピープルという事になるのだろうか？

まず、vs だけで単純に括れるのか？という所、少し違うような気がしています。対立軸が成立しているのは、あくまでネットの中で程度の差はあれ、アクティブに情報に接している層だけに当てはまっているのではないか？と思います。震災地以外でネットをしない人にとっては原発問題なんて、どこふく風。少なくとも私の父に関しては、深刻さがニュースとして伝わっていませんでした。

ひとくちに批判といいますが、批判のムーブメントを起こしているのは、利権を死守せんとする組織がダーティにリークして流しているものが根底にあります。それは、国税局の税務調査など権力機構が知りえたウィークポイントであったり、権威付けされた間接的な情報であったりします。こういうものに対しては、ちゃんと批判をすべきであると考えます。対立軸を打ち立てるような報道や教育が成されている。ここは強烈に問題です。

批判だけでは、何も解決しません。それも事実。だから建設的に考えていきましょうというのも理解できます。理解できるとした上で、相容れない価値観を持った者同士が、どうやって折り合いを付けていくのか？スルー力という表現がされていますが、この1億総共同体社会の圧力は、いかんともし難いものを感じてます。じゃあ、そこで、どうやって圏域を作るのか？ここ、正直、想像がつきません。ひとつ感じるのは、Twitterをしてなくて良かったなって事です。Twitterを通じて鬼退治なんてされた日にゃー、ムカムカきて眠れないだろうし、ストレスで病気になるでしょう。

ま、モンスターピープルと言われようとも、ブログには好きな事を書きたいです。必要なのはスルー力というか、多様な価値観を許容できる力なんでしょうか？しかし、、価値観を許容して、死んだら元も子もありません。冗談抜きで、今は戦時体制なのかもしれません。だから逃げるという選択子だってある。逃げれない当事者にとっては、深刻です。

いろいろ

  SNSは、あまり突っ込むつもりは無かったんだけども、ここんところ、Facebook と Google+ と、アカウント始動しました。正直、Facebook は性に合わない感じですが、Google+ の方は、そこそこ楽しいです。サークルの方は、Ｃ＋＋キーワードで和を広げたいんですが、私の方が技術交流をしていないので、こいつ面白いと思ったら、勝手にサークルに加えてやってください。

  Google Reader で、チェックしたアイテムとか、最初は非公開にしてたんですが、途中で共有するようにしたら、いつの間にか読者登録の和が形成されて、続いてます。でも、３．１１以後は、私がそれまで全くチェックの対象外だった政治・経済・原発関係のフィードが多くなってしまって、技術系メインで考えて読者購読を考えていたとすると、申し訳ない感じもしてます。日本の現状が、あまりに酷いのでスイッチが入ったまま戻らないです。気が付けば、原発関係のエントリの多さに我ながら愕然としてます。

ブログの方だって、ほんとは、もっと尖がった記事でも書きたいんですが、技術的な記事を書く余裕がありません。思いっきり、マネジメント方面の仕事に引っ張られてます。

土曜日には、家族3人で小樽築港まで自転車ツーリングしました。片道２０ｋｍで、朝里の手前の峠を越えれるかどうかが焦点だったんですが、坊ちゃん、頑張りました。片道、だいたい3時間ぐらいです。家に帰ってから、尻が痛いと坊ちゃんは訴えておりました。日曜日に、どっか自転車で行くか？と聞いたら、さすがに自転車はいいと言ってました。

Google Analytics 随分前に切ったのに、blogger に統計情報が統合されてて、なんだかなーです。ページビューも、以前と比べると上がってます。収益化も、一応、広告料が受け取れる程度には溜まった模様。ま、ブログ開始からの累計で、微々たるもんですが、テキスト広告よりは、画像広告の方が効果は高いようです（多分）。

日本の中小企業が生産拠点を海外に移す準備をしていると聞きます。円高なのに何もしない日本。最悪です。亀井さんの郵政に関する政策は同意できませんが、円をもっと発行して、海外資産を買いに出るという考えには賛成です。守銭奴財務省とその手下？の野田新総裁には、こんな事をする器が無いでしょう。海江田さんが、緩やかな脱原発を表明して、希望が持てるかも？と淡い期待を抱きましたが、完璧に砕かれてしまいました。ＮＨＫも馬渕さんが野田側に付いたと誤報道を流して援護射撃、なりふりかまわない労害国賊どもの振る舞い、感動的ですらあります。ＮＨＫ以外にも、未だに年間８００億円もかけた洗脳広告費にも感動してます。

国賊が牛耳っている日本中枢の関東は置いて、北海道では、苫小牧に日本の中小企業を誘致して、石狩新港・苫小牧港の整備と検査体制の整備を行い、千歳空港の使用料をアジア一にまで引き下げて、産業の活性化を行い、もっと広い視野で戦っていけば良いのではないか？と思うのですが、シュール・リアリストな知事には実行不可能かもしれないですね。

日米欧中と共同して同じ事やっても、外貨や国債の価値は目減りしてババ引くだけ、円高になるという事は、ある意味、まだ日本は健全な証拠。余力がある国は、円を発行して、資産を買って投資を行い、景気がゆり戻した段階で資産を売却して元に戻ればいいんです。

遅ればせながら・・・

ストラウスとラップのプログラミング入門の自炊の模様です。

いやー、めっちゃボリュームあって、読み応えあります。

この分厚さの割には、紙質が良くて軽いです。でも、問答無用で裁断です。

Amazon で速攻予約して写真も撮っていたんですが、今頃、自炊の模様をお届けしてみました。

盆休み（知床）

例年ならば、友達とキャンプをして緩やかな時間を過ごすのですが、今年は、震災もあり、家族だけで道内キャンプになりました。初日は、帯広の「とん田」で豚丼を・・・Ａｎｄｒｏｉｄがトラブって、ちょい口をつけた後の写真になってしまいました・・・うまいです。

その後、北見でホテルに一泊して、性懲りも無く、網走監獄博物館へ

あいにくの雨続きで、キャンプは辛そうという事で、バンガローを借りる事にしました。ひがしもこと芝桜公園キャンプ場です。お盆だというのに誰もキャンプしていなくて、不思議な感じです。道東から道北にかけての拠点としては、なかなか良い場所です。

 　このキャンプ場で、2日目の朝に電灯下に「オスのカブト虫」を見つけた坊ちゃんは、大興奮。2日目の晩にも電灯下を回って、「メスのカブト虫」と「メスの小クワガタ」を見つけました。
2日目は、随分昔に渋滞でたどり着けなかった「カムイワッカの滝」に行きました。川の水は、温泉というよりも温い感じ。川の水は、酸度が高くて、酸っぱかったです。

途中の道では、エゾシカやらキタキツネに遭いました。ま、別に珍しい事ではないのですが・・・

キャンプ場への帰り道の途中で、オシンコシンの滝を見て、マイナスイオンを浴び

神の子池へと寄りました。悠然とオショロコマが泳いでいるのが幻想的です。

とまぁ、こんな感じのテントを張らないキャンプでした。締めはメロン熊で・・・

夏休みの締めくくり（モエレ沼公園、海の噴水）

自転車だと一泊しないと、坊ちゃん連れて夜の噴水は見れないのですが、夏休み最後という事もあり、レンタカーでモエレ沼公園の噴水を見て締めくくりました。実物は、写真よりも幻想的で綺麗なんですが、蚊が多くて難儀しました。