Jenkins:「WindowsサービスとしてこのWindowsスレーブを制御」がうまくいかんときの解決法

Jenkinsで分散ビルドです。

まず、管理するPC(マスター)にJenkinsを入れておけばよく、実際にビルドを行う他のマシン(スレーブ?スレーヴ?)にはJenkinsは勿論特別なソフトは入れなくて良い。


上記「WindowsサービスとしてこのWindowsスレーブを制御」をマスター側でノードに設定すると、自動的に「slave agent」をスレーブに設定してくれるんですって。まじ便利。


さて。


ただマスターに設定しただけでは、やはり動きませんでした。
でもちゃんとログに「このサイト見ろ」と丁寧に書いてあったので、飛ぶ。
まあ親切に1つずつ丁寧に説明しています。
それがこれ。
Windows slaves fail to start via DCOM - 日本語 - Jenkins Wiki


だけれども、これじゃあ、自分のwindows 7 64bit環境では動きませんでした。


さらにググり続けて解決方法を調べると。。ありましたよ。同じ説明の英語版に。
http://wiki.hudson-ci.org/display/HUDSON/Windows+slaves+fail+to+start+via+DCOM#comment-thread-5432945


二回連続なので、これが解決方法の定石かと思うことにする。


ちなみに、差分はこれです。これを追加でやったら通信できるようになりました。

  1. Launch 'regedit.exe' as 'Administrator'
  2. Find the following registry key: 'HKEY_CLASSES_ROOT\CLSID{76A64158-CB41-11D1-8B02-00600806D9B6}'
  3. Right click and select 'Permissions'
  4. Change owner to administrators group.
  5. Change permissions for administrators group. Grant Full Control.
  6. Change owner back to TrustedInstaller (user is "NT Service\TrustedInstaller")
  7. Restart Remote Registry Service


日本語だとこんな感じ

  1. 管理者権限でregedit.exe(レジストリエディタ)を開く
  2. 以下のレジストリキーを探す。”HKEY_CLASSES_ROOT\CLSID{76A64158-CB41-11D1-8B02-00600806D9B6}”
  3. 右クリックで”アクセス許可”を洗濯
  4. 詳細設定の所有者タブに行って、所有者を”管理者”に変更
  5. Jenkinsで設定しているユーザを”フルコントロール”の許可を与える
  6. 元のTrustedInstallerに所有者を戻しておく。 (これやっとらん。治さないと)
  7. さいきどう リモート レジストリ サービス (これやっとらん。けど動いた)

英語版のJenkinsヘルプ?だと、説明を読んで失敗した人が、そのままそこで議論してるから、かなりわかりやすい。

誤ってJenkinsにログインできなかったり、404エラーが起きたりの対処法

Jenkinsでユーザの権限を設定したときに、なんか知らんがエラーを吐きおる。


ページ更新してみると404エラー。。
Jenkinsを再起動、再度ログインしようとしても404エラー。。
自分のアカウントに権限を与えてない状態になってしまった様子。
やってしまった。。。これからどうやってアクセスすればいいのだ。。。



こんなときのため、Jenkinsさんのページを見ると、ちゃんと対処法が書いてありました。
Disable security - 日本語 - Jenkins Wiki
※これじゃ治りません。

(注)↑に記載されている $HUDSON_HOME は $JENKINS_HOME となります。
こちらの環境では、
/etc/sysconfig/jenkins内で、
JENKINS_HOME=/var/lib/jenkins

となっておりました。


んで言われたとおりuseSecurityをfalseにしても、まだ認証求めてきます。
見てるファイル違うんかと色々試行錯誤しましたが、こちらに答えがありました。
Disable security - Jenkins - Jenkins Wiki
先ほどのサイトの英語版です。

英語版の方に、

Actually, in current versions, you should replace whatever you have in your config.xml with the following:

true

と書いてあるじゃないですか。
これでOK。
無事設定に戻れました。


日本語の情報が充実してるだけに、英語の方のサイトを無意識に回避していて時間がかかりました。。。

Jenkinsのhelpの英語版では色々な議論がなされているようで、日本語よりも情報が豊富です。
なので、自分は英語版を読むようにしています。

CEDEC2011 二日目

「ムーンショット」 デザイン幸福論

イタリア人以外でフェラーリをはじめてデザインした人。
プロとアマチュアの違いについてプロはシステムの中で働くらしいことを言っていました。初めて、プロアマ論で納得できる言葉をもらいました。たしかにそうだ。根性とかそういうものじゃない。

また、日本人は実は個人力だと言っていた。超優秀な人でも5人集めると何も決まらない。イタリアはちゃんと議論してまとめることができる。これはなんか、会社にいてことごとく感じることなんだけど、自分も日本人だから難しいんだろうな。



そんなツールで大丈夫か? インハウスツール開発の思想と理想

スクエニで、今までどんな内製ツールを作ってきたか?を歴史を追って説目。
基本的に大事なのは”即編集、即実機反映”コンバートなんて考えちゃダメ。
ツールは手段。

目的と手段を間違えない。
目的を考えて、買うのか?作るのか?を見極める。ソリューションを与える

Unityなどが出ても、やはりトップスタジオの人達はコダワリたい。それに対応させるためにも、柔軟なツールは欲しい。


物理エンジンを利用したクリーチャーのプロシージャルアニメーション

6本足などの多足動物を物理制御でアニメーション。
内容は実は全くの物理シミュレーション。逆振り子問題などを丁寧に解説して頂きました。

ただ、プロシージャルアニメーションの一番の問題は、挙動の動的変化と、それを作る制御のしやすさのバランスだと思う。なので、これはプロシージャルなアニメーションではあるけど、実用面では物理シミュレーションな話だったなと思います。


セルアニメスタイルのCG制作

サンライズのガンダムを作ってる方の講演。
アート的な話ではなくテクニカル&運営的な話をしていました。

Mental Rayのシェーダをオリジナルでカスタマイズしているとのことですが、オフラインのToonはPencil+が圧倒的クオリティを放っているので、そことの兼ね合いは聞きたかったです。

アニメの昔からの書式であるタイムシートを、自動でMayaやAEに変換してリマップデータにするなど。IT化が進むのが遅いであろう現場での効率化への努力が見られました。


ARMORED CORE Vの対戦AIにおける階層型ゴール指向プランニングと機体制御

注意点:これACVのAIじゃなくて、ACVのアセット借りたAI検証でした。本編と関係ありません。
注意点:説明したAIの実際のデモがない。

と初めに苦言しましたが、ゴール指向プランニングをわかり易く説明してくれて楽しめました。

  1. ゲーム本来の主目的
  2. 次にどこを目指すかなどの戦略
  3. 近くに飛んできた弾を避ける、敵を撃つ

この3段階の目的を常に満たすために、上から階層的にプランニングしていくというもの。
発想はこれは当たり前とは思うのですが、まだ世の中に使われていないということは、何が難しいんだろう?
処理負荷のようなことは言っていました。

しかし、AIはそもそも”プレイヤーが生きてると思えばいい”という目的があり、そこのギャップを埋めるために、遷移関数などの細かいチューニングが不可欠なはず。

そこのテクニックが気になる。デモ見たかったです。

AIへの興味は増すばかり。

CEDEC2011  一日目

今年も行ってきました。CEDEC
簡単なメモ。

心に残ったもの。

一日目に良かったのはこの2つ。

はやぶさは、エンジニアリングで未知の領域へ飛び出す力。純粋な理系男子の気持ちをくすぶる良い講演でした。達成毎のオリジナルステッカはいいなw

何かを成し遂げるには、はったりも必要

だそうです。

一方エンジンは、海外での傾向を統計的に知れてよかった。

エンジニアの8割は、ゲームエンジンなんて使いたくない

これは日本だけだと思ってたら海外もそうなんだと。面白いね。

メモ

『アニメのエフェクト、ゲームのエフェクト』 〜前篇〜

http://cedec.cesa.or.jp/2011/program/VA/C11_I0006.html

30分以上たってもはじまっても始まらないという、しょっぱなから悪夢。
憤りを感じてNaturalMotion社へ。


プロシージャルアニメーションの未来と使い方

http://cedec.cesa.or.jp/2011/program/VA/C11_PR0013.html
NaturalMotion社のプロシージャルアニメーション制作用ツールの説明。
リターゲティング、リギングなどをGUIで簡単に作成編集できますよ。また、物理との挙動をモーションデータと合わせて表現できるEuphoriaというシステム。これによって、手で押されるとよろめいたりといった挙動を作成できる。
ここで一番売りにしていたのは、これらをすべてプログラムではなくGUIベースでできるということ。


プロシージャルアニメーションに対しての専門知識がないので、これがどれくらい画期的なものかわからなかった。
うーん。他のDCCツールとかとのインタラクション例がないと、うまくいくサンプルを見せられてるきがしてしまいました。馬のボーンに人間のモーションをリターゲティングしてたけど・・・そんなにうまくいくんですかねぇ。

ショートセッション: AI に命を吹き込むには

http://cedec.cesa.or.jp/2011/program/GD/C11_PK0007.html

ぽかぽかアイルー村における、アフォーダンス指向のAI事例。AIに多様な振る舞いをさせる手法

多彩なキャラクタの個性を表現しようとしたら組合せ爆発を起こす。なので、Simsと同じAI手法を使うよというもの。環境によってキャラクタのパラメータを変異させ、挙動を変える。


確かこれってかなり基礎的なAIじゃなかったか・・・。
とか思いながら、AIの知識は皆無なので、うまいねー!っと思いました。



ARMORED CORE Vのパス検索

ARMORED CORE Vはロボットが空飛ぶ。だから、パス検索の範囲が2次元平面に収まらない。
よって、3次元でのパス検索を考える。
概略すると

  1. AABBで行ける場所を空間分割
  2. AABBをノード、隣接をエッジと思えば、グラフ構造にできる。
  3. グラフにしちまえばA*アルゴリズムで普通にパス検索できるよ。

グラフの論理に落としちまえってのは、単純でわかりやすかった。
AABBとか馴染み深い言葉がでてくると、3次元でのAI制御に関して自分もの知識が役に立つ。
AIへの興味は増すばかり。


西洋におけるゲームエンジンとミドルウェア

http://cedec.cesa.or.jp/2011/program/OS/C11_I0057.html

  • アメリカのゲームマーケット

パッケージ販売だけ見るとゲームが売れなくなってきている用に見えるが、ダウンロード販売に遷移しているだけで、ほんとは殆ど変わらないよ。(でもグラフは少し下降してるように見えた。)

iPhoneFacebookのソーシャル、カジュアルの流れによってf2p(free to play)が当たり前になっている。
ゲームは2007年から

  • どこでも使用可能
  • 入手可能
  • 簡単にプレイ

が前提に。

どうやって60ドルもゲームに払ってもらうか?
このリスクを最小にするために、マルチプラットフォーム、アウトソーシング、ゲームエンジンとミドルウェアの利用が当たり前になっている。

エンジンもミドルウェアも混乱の時代。
どれがどうなるかわかるかはまだわからないけど。
売り切りがたから、365日常に運営していくサービスに切り替わっている。これは事実。

小規模なニッチ名ミドルウェアが増えてくるだろう。
AAAタイトルエンジンがスマフォに流れていっている。


「ドラゴンズ ドグマ」のグラフィックス表現の技術解説

http://cedec.cesa.or.jp/2011/program/PG/C11_P0178.html
オープンフィールドで24時間全天候対応のため、ライトマップなどのベイク処理が使えない。
だから、動的ライトとシャドウだけでライティングする。
ディファードを採用。
 
細かいチューニング的話が多くて面白かった。こういうところは、結構細かなところで陽を浴びづらいところだとは思う。

FXAA採用のようで、大人気すね。

テクニカルアーティストラウンドテーブル2011: プログラマー編

http://cedec.cesa.or.jp/2011/program/PG/C11_P0082.html

TA=テクニカルアーティストの人達が、社内でのそれぞれのTAの扱い、教育、資料作成などそれぞれのトピックについて議論する。
職としての認知がまだ浅いため、どこからどこまでがTAなのかという定義を定着&認知させるためのもの。
だったんだろうな。

そこで出てた言葉で、TAはアーティスト、プログラマーそれぞれの経験がないと成り立たない。下手にやると中途半端で使えない人になる可能性がある。というものがあり、それはそうだなと納得。だからこそ、今回のラウンドテーブルがアーティスト編とプログラマー編の2つに別れていたんだろうなと思う。

twitterで流れてきてたんだけど、海外では"Pipeline Engineer"なんて言葉があるらしい。
個人的には、こっちの言葉の方がわかりやすいと感じます。

CEDEC2011 三日目

情報化社会、インターネット、デジタルアート、日本文化

僕は吉永小百合でオナニーできます!

チームラボの方の講演。西洋のパースペクティブと東洋のレイヤー構造のお話。
語りつくされていることではあるけど、視点が面白い。

ゲームキャラに自分が成り切ったとき、見える視界はどうなっているか?


海外のパースペクティブ指向だと、キャラクタの目線になるだろう。だから海外ではfpsが人気。
だけど、レイヤ構造の絵の中で、キャラクタは僕らと同じ目線で見ている。だからマリオやドラクエができる。

後者の話ははて・・・?という感じだけど、なんとなくわかる気がします。

今年は基調講演がすべてあたりという素晴らしい年。

Tegra 技術概要および Tegra ゲーム開発について

Tegraアーキテクチャの説明かとおもいきや、30分間Androidでのアプリ開発の指針とNDKの使い方を述べられたので退出。

『時代を超えるキャラクターと世界を創る』 〜ボトムズからのメッセージ〜

凄く良い話が聞けた。あとでちゃんと書きたいと思う。

人生至る処に青山あり

CEDEC AWARDS / 公募傾向 / CESA 開発技術ロードマップ検討会 (VA編)

数年先のVA技術のロードマップ

アーティストとプログラマ共同になって検証しないといけない。

メモをあんまりとれなかった。
→ハイエンドへ突き進む。
→ツールの拡充、大規模アセット管理などの具体的ソリューション
→他のシェーディングの可能性
→それだけじゃない、カジュアル、ソーシャルに適したグラフィクスアプローチ

こういったものが必要。
ハイエンド系の技術は、シェーダ系やキャプチャ系、プロシージャルなどなどそうだよなというものばかりでした。

そして一番最初に、エンジンや小さなミドルウェアを常に観測し続けろとのこと。
らじゃー!


情報処理学会グラフィクスとCAD研究会・発足30周年記念 〜 CGリサーチフォーラム:経年変化のモデリング技術

写真に写る壁などを”濡らしたり””錆びさせたり”する研究ツールの紹介。
プロのデザイナの道具としてできるかは疑問。

ゲーム開発効率化/品質向上ツール ラウンドテーブル

面白かったです!
これは別途まとめたい。


パネル討論:原点回帰! 〜 CG研究が見過ごしてきた技と感性とは?

SCE水谷さん: 「UVめんどい、スキニングめんどい」
五十嵐教授:  「10年以上前から論文沢山でてるけどなんでダメなんですか?」

これにつきる。これが聞きたかった。
やはり、必要だと思う。
ポリゴンは出力データであって、編集データであってはいけない。
ZBrushからそうなってきてはいるものの、まだまだ必要。

でも、ゲームはデータもプログラムも全てにおいて最適化するから・・・ね。
ここは、その柔軟性を与えることが必要。

やはり、道具としてまじめに研究しないといけない。

SCE水谷さん: 「そういう便利な道具つくってくださいよ。」
五十嵐さん: 「大学での研究目的は、新規性。道具としての調整よりも、さらに新しいものへ走ってしまう。なので製品とのモチベーションが違う。問題としては認識している。」

良い会話だなと思いました。
もう、海外のオフラインCGでは、この間を取り払わられている。はず。

うん。考える事が多い。

プログラミング現場の単体テスト

経験ゼロでもできるプログラミング現場の単体テスト

経験ゼロでもできるプログラミング現場の単体テスト


ぶっちゃけ読みきってませんが。

単体テストの必要性とやり方を丁寧に説明してくれてると思います。とりあえず、全くの初心者の自分でも「なるほど」と思いながら読めます。


ただ・・・・


どうしても、単体テスト系の話はEclipse+JUnitばかりでなんだかな。
自分みたいなC++で数学ゴリゴリていうかシェーダ書いたりGPU駆使するグラフィック屋として、どういうテストを効率的に行うべきかとかわからないっす。
こういう本からエッセンスを学ぼうと思ってはおりますが。
この書籍はJavaでデータベースを云々の話です。自分には畑違いすぎて、「ほうほう」とか思えないのが痛いな。それも自分の経験や視野が狭いのに起因しているとは思うけど。


とりあえず、JUnitの使い方は知ってるから、これを軸にデータベースとのやりとりとかもこそこそ学んで行こうかと思います。


たぶん、良書。

知識ゼロから学ぶ ソフトウェアテスト

知識ゼロから学ぶ ソフトウェアテスト

知識ゼロから学ぶ ソフトウェアテスト

単体テストの知識(というか書き方?)しか知らない自分でも、読めた!
ソフトウェアテストの様々な方法を超簡単な例を通じて俯瞰で見ていきます。演習とかあるわけじゃないのですぐに実践できるわけじゃないけど、大まかに、以下の2点がを理解できました。

  • テストの考え方
  • このテストはこういう意図のもと、こんな場合に使う。


んで、この本はコンセプトがステキです。

  • 日本人が日本語で書く (翻訳ではなく)
  • 日本人の開発現場を基準に (国際的標準に追いつけてない場所で)
  • ソフトウェアテストの知見がない人のため (ずぶの素人)

に書かれた本。
というわけで、本当に読みやすく一晩で読めちゃいましたさ。


ただ、本当に素人の自分では”これが正しいのか?””全体の範囲のどこまでを網羅しているのか?”はわからないので、あんまり評価できません。
ただ、ソフトウェアテストの入り口には立たせて頂いた気がします!
ありがとうございます!

  • バグは完璧に取れるもんじゃない。
  • 完璧なテストなんてない

こういう心構えだけでも持てたのはうれしいです。

トピック

  1. バグとは何か?
  2. ホワイトボックステスト
  3. ブラックボックステスト
  4. システムテスト
  5. セキュリティテスト
  6. 回帰テスト
  7. ソフトウェアテスト運用の基本
  8. ソフトウェア品質管理の基本
  9. なぜ自動化は失敗するのか?

苦言

ただ、最後に苦言も。


読みやすかったんだけど、ちょっと体系だって話されてないんだよなぁ。
章の構成的にも、話の流れ的にも。


例えば回帰テストのところとか、

回帰テストとは唯一計画なしに行うテストです。

と書かれてるけど、じゃあどんなテストなんだよ!!その後にも明示されてないじゃないか!
とかね。

色々なテストがあるからこそ、マトリクス作ったり、各章の構成を同じにして比較したりされたらもっとクリアに入ってきただろうに。色々な現場の話をしてくれるから、読み物としては面白いんだけどね。