すごい広島#15 CEDEC2013まとめ – セッション-

すごい広島#15

すごい広島#15つづき。今回は頑張る。

基本的にCG系プログラマなので、CGのプログラミング関連を回ってました。あとARも。

モデリング関連

RenderMan完全互換なレンダリングエンジンOpenSubdivについてのお話。GitHubでも公開されている。

これからのモデルはローポリで作って、複雑なリグでモデルを表示するべきだ!っていうのが一番のポイント。

細かい部分はZBrushとか使ってDisplacementMappingでやるべきだっていうお話。

キーワードとしてはFeature Adaptive Representationとか?

モデリングツール対応としてはMayaやBlenderではまだ対応してないけど来年あたりには対応するんじゃないかってことと、OpenGLのGL_EXTに組み込まれるように申請する鴨って言う話も出てました。

SCE関連

みんな大好きSCEのセッション。SCEはAR研究をずっと昔から続けており、独自のARエンジンSmartARを持っていることでも有名ですね。

今回は六本木メトロハットで行われた初音ミクのARライブの裏側とPS4のPlayRoomについて触れられてました。

大概のことは記事にあるので、HATSUNE MIKU AR STAGEの仕組みについてここでは触れようと思います。

基本的にはマーカーレス型のAR。しかし、今回はマーカーの形状が円柱の曲面なのでマーカーを3つ用意し、3方向から認識出来るようにしたとのこと。屋根の上から初音ミクが飛び出してくるシーンなど、初音ミクの足元が屋根によってうまく隠されているシーンがある。この隠蔽の仕組み(普通の人は気がつかないかもしれないけど結構実装が難しい)はビルのオーナーから図面をもらって正確なモデルを作成し、マスクバッファを作成したとのこと。今回建物のオーナー側の協力が必須なのはこの一面も大きい。ああいうARはいつかやってみたいよなぁ。

PS4のPlayRoomには実際のプレイ画面が出てなかったのが気になるなぁ…。

Android関連

前半はトライエース様のセッションで、自社のレンダリングエンジンをiOSとAndroidに移植したって言う話でした。

このセッション、メモしたノートに”Androidはクソ!!”の連発だったよ…。

実測値とOSの返す値が違う、OpenGLES2.0の仕様に準拠してない、NDKでまともなデバッガがない

Androidの仕様は別として実装が謎仕様とバグでクソってのが伝わってきた。あとまともなデバッガがないのがやっぱり開発環境として致命的だと思う。ああ、Unity、オメーもだよ?

後者のセッションはGoogleの方がセッションしてたんだけど、もしかしてどこも記事にしてない…?

この人は非常に面白い方で、なおかつまめ知識がマジでTipsの宝庫でした。このセッションこそ本当に記事にするべき。

Androidまめ知識

  • NDKは生産性が低いってのは押さえておくべき。
  • Androidアプリのチューニング項目にバッテリー消費対策を忘れない。
  • APK.ZipAlignを忘れない
  • OpenGLES3.0にはGeometry Shaderはありません。
  • OpenGLES3.0ではfloat textureやHDR textureは仕様に入るよ
  • GPUの描画方法がTiled RenderingなのかTiled Based Differed Rendering、Immidiate Renderingなのかで最適化の手法が違う(トライエースの人が言ってたGPUの違いが多分これ)
  • GPUについてはベンダーのサポートサイトが一番詳しいのでみておくべき。
  • NativeHeapが足りないときはLargeHeapっていうのがある
  • メモリ確保にはmallocでもnewでもなくvmapを使うのが最も安全。(mallocとnewの危険性はまぁ、知っておくべきよね)
  • コンパイラはClang/LLVMを使うといいよ。切り替えはNDK_TOOLCHAIN=clangで。(ただしバギーだけど)
  • onPauseでGLのコンテキストは軒並み殺されるのでsetPreserveEGLContextOnPauseで保護する
  • EGLコンテキスト保護のためにもスクリーン回転は自前で実装すべき。
  • 基本的にNativeActivityを継承しなさい。
  • サウンドはレイテンシ対策としてOpenSLのコールバックスレッドでやれ
  • ↑PrioriryはSCHED_FIFOという最優先が割り当てられるのでリアルタイム処理ができるよ
  • ↑でも、待ち状態が発生するような処理すると優先度が落ちるので気をつけろよ
  • WebViewはインスタンスを削除してもNativeHeapを残し続けるので別プロセスにした方がいいよ。
  • ↑ただし、別プロセスにすると5Mくらい多くメモリを使うようになるから注意な
  • Android、テスト端末の機種選びに困ったらNexus4,7,10を買っとけ間違いないから。

もうEffective Andoridを書いてくださいお願いします(:D)TL

(既に出ているという突っ込みが入ってました(:DTL)

他にもいくつかセッションみたけど気が向いたら追加します。

すごい広島#15 CEDEC2013まとめ – 基調講演-

すごい広島#15

すごい広島すごい久しぶり!!

夏休みを利用してCEDEC2013に行ってきたので、関連する記事をまとめてみたり。

大抵は4Gamerさんのところで”CEDEC”と検索して調べてます。

というか記者やプレス関係者以外は撮影・録音・録画できなかったんだから、
記者はきりきり記事を書くべきだと思うのよね。

その中で自分が参加した物や参加したかった物だけを引っ張りだします。
そのうちCEDILでもセッション資料が公開されるので、そっちを待つのもありだと思います。

あと発表者、ガリレオや半沢直樹ネタ出し過ぎぃ。
そしてGoogleの方はすごい参考になりましたが、ネタの方向性が危険すぎぃ。
地獄の業火ネタとか…。

4Gamers CEDEC2013総合

CEDEC関連の記事はここから探すと良さそうです。

1日目 クリエイターと社会のつなぎ方~アイディアをリアルに

初日は移動の関係で基調講演がみられませんでした、残念。
AR3兄弟はもう3兄弟じゃなくなったけど頑張ってほしいです。

2日目 開発讃歌

みんな大好きガンホー森下社長のセッション。第五話は居眠りしてて見逃したと思ったけどやっぱなかった。
なお、ROについて一言も触れられませんでした。ただ、セッション内の発言では過去に対する不満、教訓めいたのが伝わってきました。

なお、資料は直前に出来た模様。

3日目 アンドロイド・ロボット開発を通した存在感の研究

今回一番衝撃を受けたセッション。講演者はジェミノイドで有名な石黒浩教授。
ていうか、このひと大阪人やったんやな…。

ロボットについての未来を想像させるセッションでした。関連する書籍として
人とロボットの秘密とか読んでおくといいかもね。

このセッションのビデオがあったら絶対にみた方がよいと思います。

Togetterまとめ等もみておくといいかもです。

すごい広島#10 git_rebase_-iについてまとめる

すごい広島#10

マージコミットを整理するためのgit rebase -iについて。

背景

gitを使って作業をしていると、細かくコミットしすぎて、後からコミットをまとめたくなるときがあります。

また、可読性を高めるためにコミットログの順番を入替えたい場合もあります。

そんなときに役に立つのがgit rebase -i <REVISION>コマンドです。

状況設定

git rebaseをお手軽に試すために、状況を再現するためのスクリプトを作りました。

GitHubにアクセスして、空のディレクトリを作り、そこで git_rebase_training.sh を実行してください。

masterとtest_commitの2つのブランチのあるgitリポジトリが生成されます。

そのままmergeすると下記のようなコミットログが作られます。

% ./git_rebase_training.sh
% git merge –no-ff test_commit
% git log –graph –oneline
* c8aa931 Merge branch ‘test_commit’
|\
| * 827bae1 git rebase 練習用 test_commit 5th_commit
| * eb5bdf8 git rebase 練習用 test_commit 4th_commit
| * 6de33d1 git rebase 練習用 test_commit 3rd_commit
| * 03e2a0a git rebase 練習用 test_commit 2nd_commit
|/
* ab85207 git rebase 練習用 master 1st_commit

今回はtest_commitブランチで作成した複数のコミットを1つにまとめることを目標にします。

状況開始

test_commit内の2nd_commit (03e2a0a)から5th_commit(827bae1)までをまとめます。

スクリプトを実行した直後はmasterブランチなので、test_commitブランチに移動します。

%git checkout test_commit

git rebase -iコマンドでコミットの書き換えを実施します。revisionの指定は、

まとめたいコミットの一つ前を指定します。

%git rebase -i ab85207

もしくはまとめたいコミットの数から

git rebase -i HEAD~4

を入力します。2つのコマンドは等価です。

(後者は^ハットではなく~チルダであることに注意)

するとエディタが起動し、次のような編集画面になります。

pick 03e2a0a git rebase 練習用 test_commit 2nd_commit
pick 6de33d1 git rebase 練習用 test_commit 3rd_commit
pick eb5bdf8 git rebase 練習用 test_commit 4th_commit
pick 827bae1 git rebase 練習用 test_commit 5th_commit

# Rebase ab85207..827bae1 onto ab85207
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like “squash”, but discard this commit’s log message
# x, exec = run command (the rest of the line) using shell
— 略 —

画面の見方ですが、行の先頭から

rebaseのコマンド、リビジョン、コミットログ

という並びになっています。

ここで大事なのはコマンドと行の順番です。rebaseは上から順番に処理されていきます。

コマンドの意味は英語そのままですが…

  • pick … コミットをそのまま使う
  • reword … コミットを使うが、その際にコミットログの修正を行う (amend同様にエディタが起動します。)
  • edit … コミットを使うが、rebaseをいったん止めてamendを行う。コミットそのものを修正出来る
  • squash … コミットの内容を直前(一つ上)のコミットとまとめる。まとめるときにエディタが起動してコミットログを修正出来る
  • fixup … コミットの内容を直前(一つ上)のコミットとまとめる。コミットログはそのまま使用する
  • exec … コミットを捨てる。rebaseをいったん止めて、該当コミットを打ち消した状態で再開し、新たにコミットを作り直せる。

という感じです。なお、rebaseを止めたときgit rebase –continueで続きの作業ができます。

途中で強制終了する場合はgit rebase –abortで終わらせることができます。

今回は2nd_commitに残りのコミットをすべてまとめるので下記のように修正します。

pick 03e2a0a git rebase 練習用 test_commit 2nd_commit
f 6de33d1 git rebase 練習用 test_commit 3rd_commit
f eb5bdf8 git rebase 練習用 test_commit 4th_commit
f 827bae1 git rebase 練習用 test_commit 5th_commit

結果

エディタの修正を終わると、rebaseが実行されログがまとめられます。

% git rebase -i HEAD~4
[detached HEAD afe2d6d] git rebase 練習用 test_commit 2nd_commit
4 files changed, 4 insertions(+)
create mode 100644 2nd_commit
create mode 100644 3rd_commit
create mode 100644 4th_commit
create mode 100644 5th_commit
Successfully rebased and updated refs/heads/test_commit.

コミットがまとめられ、新しいコミットになっていることに注目してください。

% git merge –no-ff test_commit
% git log –graph –oneline
* 605c226 Merge branch ‘test_commit’
|\
| * afe2d6d git rebase 練習用 test_commit 2nd_commit
|/
* ab85207 git rebase 練習用 master 1st_commit

以上でgit rebase -i の説明は終了です。

次回はreflogでも紹介しようかな。

追記

すごい広島#10へのリンク漏れ修正。

あと、コミットのrebaseは行を入れ替えることでコミットの順番を入れ替えることも出来たりしますん。

すごい広島#7 シンタックスハイライトを試す

すごい広島#7

今後ソースコードを書くときに等にシンタックスハイライトしたいのでやり方を調べた。

基本的にwordpressで不明な点はSupportのwriting&editingの所をみれば、だいたいのことがわかるそうな。

その中のcode->posting-source-codeを見てみるとシンタックスハイライトについて記述されている。

それによると、ポイントは

  • codeというタグを使うことで出来る。
  • タグは[tag名]で囲んでやることで有効になる。シンタックスハイライトを終わるときは[/tag名]で終わる。
  • パラメータは[tag名 parameter=argment]で指定できる
  • language,もしくはlangで言語を指定できる(Cの場合は”cpp”)。
  • titleでタイトルを指定できる(英字は大文字にキャピタライズされる)。
  • gutter=falseで行を消せる(コマンド紹介の時にはいいかも)。

ということらしい。

実際にやってみる


#include <stdio.h>

int main(int argc, char **argv)

{

    printf("hello world!\n");

    return 0;

}

できたかな?

wordpress.comでも割と自由に書けそうな気がしてきました。

git-flowのfeatureのマージコミットを残したい すごい広島#5

すごい広島#5

記事が遅れ気味(:D)TL

前回のあらすじ

すごい広島#4でgit-flowを勉強しましたが、git flow feature finish時に–no-ffなマージができないという問題点が残りました。

その後、前回の記事のpull requestにて@yukilaboさんから本家git-flowで同じことを指摘して、pull request出している人がいるよという指摘を受けました。

しかし、本家git-flowはもう半年以上更新されてないみたい。

じゃあ、自分で取り込むしかないでしょ!ってことで取り込んでみた。

git-flowのfork

GitHubの文化自体よくわかってないのですが、他人の成果物を引き継いで開発するときにforkするみたいな表現を聞いたことがあった。多分今回みたいなケースが該当するのだろうねということで本家に行ってforkボタンをぽちぽち。これで自分のアカウントにgitflowがforkされる

pull requestのマージ

今回マージしたいと思ったのは本家pull requestの#290conf氏が改変したもの。

なわけで、

git clone https://github.com/hanapage/gitflow.git

で自分のリポジトリから持ってきて

git pull https://github.com/conf/gitflow.git feature/custom-merge-message-on-feature-finish

でconf氏の変更を引っ張ってくる。

…なんか、developにそのまま追加してしまった気がするけど気にしない。(ちゃんとfeature/branchを作るべきだった)

そのままテストして問題なかったのでpushしてGitHubに反映

自分用のgit-flow完成する。ヤッター!

反省点

  • これconf氏のリポジトリからforkすればよかったんじゃ…
  • developブランチで直接pullしちゃった…
  • readme内のcontributeみてちゃんとしたお作法に従うべきだったかもね

GitHubでforkするのは初めてだったけどあまりにも杜撰だったかもしれない。

課題

  • forkして、さらに他の開発者様の変更を取り込むときの正しそうな作法を調べておく

その他git-flowの感想

git flowのfeatureにマージコミットつくようになったのはいいけど、release,hotfixなどのサブブランチのfinish時にもmergeコミットが残らないことが判明。ただ、本当にmergeコミットを残すべきなのかどうかはちょっと迷う。

実際にgit-flowを使いながらプログラムを一本作ってみた。で、リポジトリをサーバにあげてredmineでコミットグラフを見てみた。redmineでは各ブランチごとの履歴をみることが出来るけど、developブランチの細かい変更が邪魔に思えた。masterはブランチではversionのみのコミットだけがみたいなと思った。

たぶん、git-flow作者も同じようなことを感じてmerge commitを残さない仕様にしたのかもしれないと思った6月の日の事でした。

追記

@eielhさんから

という電波を受信したらすっきりマージする方法がわかった気がする。

  1. git remote add conf https://github.com/conf/gitflow.git
  2. git fetch conf
  3. git merge conf/feature/custom-merge-message-on-feature-finish

でマージ完了。指摘ありがとうございました。

git-flowについて勉強 すごい広島#4

すごい広島#4

本当は第1回広島Gitの日にやるべき内容だったけれども、その後に用事があったりして最後まで参加できなかった。

その後も、WPFの勉強やら、今作ってるプロダクトに関する作業とかでごたごたしてたので結局今週まで引き伸ばしてました。いろいろな意味でごめんなさい。

さて、git-flowについては前々から興味があって、広島Gitの参加コメントにもgit-flowガーとかずっと言ってたけど結局実践はできてない。

git-flowとは

大まかな説明は原著に譲ります。

大雑把に言えば、gitで開発する上で、どのようにbranchを使っていけば良いかという方針です。

また、git-flowを実践するためのpluginも開発されています。

git-flowの思想

git-flowではbranchを下記の2つのメインブランチに分けて使っています。

  • master
  • develop

masterはプログラムの完成済みの各バージョンのみをコミットする。developは開発の起点となるbranchで新バージョン開発時はmasterからdevelopに分岐し、新機能を開発していく。

また、メインブランチをサポートするために下記のサポートブランチを使います。

  • feature
  • release
  • hotfix

featureは派生開発を行うときにdevelopから分岐するbranchで各機能ごとに作成する。
releaseは次のバージョンのための機能がある程度出そろったときにdevelopから派生するbranchであり、テストを経て本当にリリースしてよい状態になったらmasterと合流する。hotfixは突発的に発生した出荷済み製品のバグに対応するbranch。developとは独立に作業できる。fixしたらdevelopとmasterにmergeする。

git-flowのいいところ

  • masterが常に出荷可能な状態に保たれている
  • 新機能開発はすべてdevelopで行われるため、各featureで不具合が発生したときに戻りやすい
  • releaseは常にテスト可能な状態に保たれている
  • gitのbranchの使い方がわからない場合のいいお手本になる。
  • 同時にプロジェクトのすすめ方のいいお手本になる。

既にいくつものプロジェクトを回していて、独自のプロセスフローや、やり方を持っている場合は、git-flowから得るものはあまりないのではないかと思う。git-flowが必要なのは新人のプロジェクトマネージャーやgit初心者だと思います。

git-flowの問題点

一方でgit-flowの悪い点として、厳格すぎるんじゃないかという意見もあり、もっと楽に実践出来るGitHub-Flowを考えた方もいらっしゃいます。上記のリンクにあげられているように、毎日デプロイするような非常に短いスパンでプロジェクトを回す方にとっては、GitHub-Flowの方が合っているのではないかと思います。すごい広島も主催者の影の企みで気がついたらGitHub-Flowで運用されてました。ひむひむマジひむひむ。

あとgit-flowプラグインに対応しているGUIクライアントが少なそうなので、そこも悪い点の一つかもしれません。

git-flowプラグインを使ってみよう

git-flowプラグインを使うと各ブランチを自動的に作ったり、統合してくれたりするのでわりかし便利です。実際は手作業も結構入りそうですが。

  1. git flow init  : git flowを使う準備ができる。このときbranchは自動的にdevelopに切り替わります。
  2. git flow feature start a-feature : a-feature機能の開発開始。自動的に”feature/a-feature” branchが作られます。
  3. a-feature機能の開発をしてcommitする
  4. git flow feature finish -r a-feature : a-feature機能をdevelopにmergeする。このとき”feature/a-feature” branchは自動的に削除される。なお、-rオプションはrebaseした上でno-ffなマージをするの意。-kオプションをつけると”feature/a-feature” branchは消されずにそのまま残る
  5. git flow release start version-no : リリースブランチの生成
  6. その後もいくつかのfeatureを開発してリリース準備完了
  7. git flow release finish version-no : リリースブランチをmasterにmergeする。このときmasterにはtag(version-no)が打たれる

以上で一連の開発が行われる。

わからなかったこと

  • git flow feature finish a-feature のときにfeature/a-featureとdevelopのマージコミットを残す方法がわからなかったので適当に調べる

まとめ

  • A successful Git branching modelはgitを使ったプロジェクトを円滑に運営するためのお手本である
  • その運営を補助するためにgit-flowというツールが用意されている
  • 細かくサイクルを回すときはGitHub-Flowという考え方もある

次の仕事で採用してみようかな。

参考サイト

同じように既にまとめられていたサイトを見かけたのでいくつかリンクを。