裁判の傍聴に行ってきた

２年前くらいに下記のマンガを読んで以来ぼんやりと傍聴に行ってみたいなーと思っていたが、ようやく行ってきた。

裁判長!ここは懲役4年でどうすか 1 (BUNCH COMICS)

今日行ってきたのは東京地方裁判所。事前の調査によると地裁＆刑事事件、ってのが一番分かりやすくておすすめだよー、ってことで東京地裁に決めた。（以下、写真はすべて参考写真）

場所は霞が関の駅すぐ。玄関に入るといきなり空港のようなセキュリティゲートがある。ここでカバンの中身チェックが行われる。

無事ゲートを通過すると、次はロビーにある開廷予定表を確認。テーブルが並べてあって、その上にバインダーで閉じられた予定表があるので、それを見る。

予定表には

• 部屋番号
• 開始終了時間
• 罪状
• 被告人氏名
• 審理予定（新件、審理、判決）

などが書かれているのでよく確認する。時間はだいたい13:00-14:00とか１時間刻みくらい。たまーに10:00-17:00とかもあったりする。ちなみに簡易裁判だと5分で終わったりもするらしい。一番注目すべき点はたぶん罪状。今回見た感じだと、

• 暴行
• 詐欺
• 窃盗
• 覚せい剤
• 業務上横領
• 強姦致傷、わいせつ行為

あたりが多い印象。１件だけ殺人があって、それを傍聴するには傍聴券という整理券みたいなものが必要。傍聴券は朝早く並んでゲットするんだろうな。今回は無理っぽかったので諦めた。

ざっくりスケジュールを決めたらエレベータに乗って法廷に向かう。ちなみに予定表は１Fにしか無いので、メモっておくと良い。今回は筆記用具持ってきていなかったのでiPhoneのメモアプリを使うしかなく面倒だった。予定表自体をカメラで撮影するのも気が引けたので・・。 ということで今回は以下の三件を傍聴することにした。

詐欺未遂、強盗、交通法違反

詐欺で金を取ろうとして失敗したので、隙をついて現金を盗んで車で逃げた、という事件。被告人は、詐欺で取った金を輸送する役割の男。茶髪でジャージ姿、ワルっぽい若者という感じで、手に刺青あり。特に荒れることもなく検察が淡々と事実関係を確認していた。

事件の当日は相方と共に被害者宅最寄りの駅に行き、相方が被害者宅に出向き詐欺を試みるも失敗、指示役に報告したところ今回は諦めて解散、という流れになったが、別の現場リーダーが俺がもう一度行ってみる、ということで再チャレンジしたけどやっぱり詐欺じゃ難しかったので、隙をついて現金を奪って逃走。駅のトイレで現金を確認した後、車で別の駅まで輸送し、やっぱりその駅のトイレの個室で別の担当者と合流し、現金を受け渡した、というのが被告人が関連した当日の行動。

被告人としては、自分はあくまで詐欺グループの運び屋であって、まさか強盗に加担することになるとは思っても見なかった、という感じの主張をしたいらしい。それによって罪をいくらか軽くしようという考えかもしれない。裁判官もそのへんを割と突っ込んで聞いていた。弁護人からはたいした発言はなし。

ここでタイムオーバー。次回は４月末らしい。それまで勾留されるのか〜。

全体の印象としては、詐欺窃盗ってわりと段取りや役割がしっかりできてて、ふつうの会社員の仕事内容を聞いているような感じだった。あと、駅のトイレの個室ではいろいろ危険なことが行われているんだなぁ、、、と。

強姦致傷

事件の内容は、学校帰りの女子高生にぶつかり因縁をつけ、土下座しろなどと脅した上で公園の公衆便所に連れていき、個室に鍵をかけ拘束し、強姦致傷に至った、という事件。判決が下る回だったためか、傍聴人は５０人くらいいた。

犯人は至って普通の「新卒サラリーマン、２３歳」といったこざっぱりとした男。特にくたびれてもいないスーツを着ていたので、さらに新卒さが増していた。見た目も普通なんだが、ちょっと表情や目が怖かった。

で、判決は懲役８年。「懲役８年」という言葉を聞いたときは結構衝撃的だった。最長でシャバに出てくるのが３１歳なんで、貴重な２０代を刑務所で過ごすのかと思うとゲッソリする。

判決に対する不服も特になく５分で閉廷。短かったけど印象深かった。

暴行

強盗致傷が５分で終わったので途中から入室。被告人は老人。途中からだったので全体が見えなかったけど、たぶん病院の看護婦かだれかを殴ったとか騒いだとか、そんな感じ。

この被告人のジーサンがなかなか面倒くさいキャラで、裁判官がなんかしゃべっているのに割り込んで発言して、何度も注意を受けていた。被告人いわくそもそもこの裁判が開かれる前の２ヶ月間の勾留されたことに対して不服があるらしく、「俺は警察と検察と、裁判官にまで、みんなグルになって罠はめられている！」と主張していた。私設弁護人をつけたいけど、空白期間ができちゃうので、一時的に自分自身を弁護人として認めてくれ、とか結構いろいろ注文を付けていた。

本題になかなか入れず、じゃあ勾留について次回もう一度やりましょう、ってことで閉廷。

感想

初裁判傍聴だったが、だいたい期待していた通りの内容だった。傍聴中は携帯オフにしなきゃいけないし、あんまり咳とかくしゃみとかで音も立てれないし、だらしない格好もできないので、割と疲れた。

なんとなくまだ行ったことないし、工場見学的なノリで意外とカジュアルに行けるし、ってことで行ってみたが、いろいろ勉強できました。また行ってみたい 。

わかったこと

公衆便所の個室には危険がいっぱい

iOSアプリ開発でCI環境整えるための簡易メモ

前提

ghunitとかでテスト書いておく

jenkinsサーバを適当に立てる

make testでビルド＆ghunitテスト実行できるようにする

http://gabriel.github.com/gh-unit/docs/appledoc_include/guide_command_line.html

macにslave.jar落としてきててエージェント起動

http://textt.net/take_cheeze/20110626042525/57

スレーブにmacを登録

http://unicus.jp/skmk/archives/153

カバレッジをとる

http://www.tokoro.me/2012/09/02/ghunit-jenkins-coverage/

Clang scan-build bug trend

TODO

こんだけあれば十分かな？

git mergeのbug？

XCodeのプロジェクトをgitで管理している際に、mergeでいろいろと問題が起きたのでメモっておく。

XCodeのプロジェクトを作ると、プロジェクトのファイル・グループ構造を管理するxxx.pbxprojというファイルがXCodeによって自動生成される。内容はjsonっぽい形式（property list）のテキストファイルだが、XCodeがプロジェクトの構成を管理するために簡易データベース的に使っているファイルなので、基本的には人間がいじっちゃいけないファイルである。

プロジェクトにファイルを追加するとpbxprojの内容が書き換わるので、gitなどでチーム開発するとどうしても頻繁に更新が入り、pbxprojがコンフリクトしてしまう。コンフリクトするたびに、本来人間が編集すべきでないpbxprojをテキストエディタで開き、<<<とか>>>でgrepして手作業で修正、とかチマチマやる必要がある。だるい。

ということで、このへんのダルさを解決するための方法が以下のページで紹介されていた。

http://robots.thoughtbot.com/post/33796217972/xcode-and-git-bridging-the-gap

.gitattributesというファイルにpbxprojはバイナリファイルであることを指定することで、テキストデータではなくバイナリファイルとしてマージさせる、というもの。こうすることでコンフリクトが発生したときにgitがupstreamのファイルを優先で自動でマージしてくれる、という話。

確かにこの方法であれば、コンフリクトせず良い感じにマージしている「ように見える」のだが、たまに構造的に誤ったマージをしてしまうことがある。しかし、git mergeコマンド自体は成功してしたことになっているの、上手く言ったように見えて実はpbxprojがぶっ壊れてる、という状態になってしまうことがある。

例

例えば、こんな感じのXCodeのpbxproj形式のファイルがmasterにあったとする

ここでfooというブランチを切って、このpbxprojを以下のように修正してコミットする。

一方で、masterブランチのほうにも以下のような修正を加えてコミットする（fooブランチと似たような場所・内容の修正）。

で、.gitattributesの設定をした上で、fooの修正をmasterにマージする。 すると以下のように意図しない、誤ったマージをしてしまう（git mergeコマンドは成功したことになっている）。

ちなみに、.gitattributeを設定しなければ、以下のようにコンフリクトが発生する。ということでテキストエディタでマージ解消するんだが、よくみるとこちらの差分もやっぱりちょっとおかしい感じになってしまっている。

結論

.gitattributeを設定して楽しようとするとすると思わぬマージ結果になっちゃうことがあるので、ちゃんとコミット前に目視で確認するか、そもそも.gitattribute指定しないほうがいい。

なんか他に良い解決方法があれば教えて下さい。

人生初のコミックマーケット(C83)に参加

会社の同僚が何人か出展するとのことで、生まれて初めてコミケに一人で行ってみることにしました。 

会場の様子

こちらが会場となる国際展示場。到着したのは14:30くらい。ぎゅうぎゅう、というわけではないけど、やっぱりかなり人が多かったです。

どこへいったらいいかも分からないでの、とりあえず同僚のCさんが売り子をしている場所まで向かうことに。Cさんのツイッターをみると「＠土曜東W12a」（記号は適当）みたいなことを書いてあったので、それを頼りに探す。

会場は「東」「西」の二つのエリアに分かれている様子。目的地は東っぽいのでそちらに向かう。西にはいったい何があったんだろう。

東エリアに到着。

エスカレーターを下ると広いホールを発見。壁に大きく「A」とか「Z」とか「あ」とか巨大な張り紙がしてある。これを頼りに目的地を探せばいいわけね。

最初に入ったホールとは別にもう一つ大きいホールがあって、そちらに目的地を発見。全部で２ホールなのかな？

各売り場は「サークル」単位で長机が割り当てられていて、そこに例の「薄い本」が並べられていた。サークルっていうくらいだから何人かでわいわいやっているのかなーと思ったけどCさんは一人でぽつねんとパイプイスに座っておられた。ちなみに他の同僚はみんな３日目の出展のようだ。残念。

残念ながらCさん作の薄い本は僕の趣向には合わなかったため購入は見送らせていただいた。少し雑談したあと、会場内を散策へ。

ホール内には長机がこれでもかというほど並べられており、全てのサークルを回ることは無理そうな感じだった。通常は事前にカタログを購入してお目当てのサークルを探してから計画的に回るものらしいが、今回はひたすら歩いてみて回ることにした。 

感想

コミケというと「二次創作のオタクっぽい同人マンガが売り買いされている場所」というイメージがあった。実際に小一時間会場を見て回った印象はこんな感じ。

• 美少女二次創作マンガ、的な本がやはり多い
• 大体会場の1/3くらいは、売り手も書い手も女子。本の内容はまあ腐女子系というのだろうか、ボーイズラブ的な、少女漫画的な、そんな感じ
• もう1/3は、オタク男子のための萌え系っぽい、いかにもって感じの本。売り手買い手もそんな感じ
• のこり1/3は、マンガや萌えではなく、たとえば旅行記、写真集、評論、模型、とか、わりと一般趣味書籍っぽい感じ
• ゲームとか、ワンピースのようなメジャーコンテンツの二次創作はあまり見られなかった。もしかして３日間でジャンル分けがされているんだろうか。
• 過激なエロとか暴力とかそういうのもあんまりなく、いたって平和的なコンテンツが多かったような印象

また会場自体に関しては以下の点が気になった。

• 各サークルは列ごとにジャンル分けされている。島ではなく列ごとに分けられているっぽい。このおかげで、左右をきょろきょろしながら真ん中の通路をあるけば、大体この列はこんなジャンルの列なのね、ってことが探しやすくなっている。
• ボランティア？っぽい人たちが大量にいて、会場の見回りをしたり、本部っぽいところで案内をしたりしている。ボランティなのかな？お金貰っているのかな？
• コスプレイヤーはどこに！？
• 16:00に終了。会場内全員で謎の三本締め。ほんわかした。

戦利品

そういうわけで、誰の案内もなく、一人でコミケに潜入して、よく分からないところも多々ありつつも、２時間くらい滞在した。買ったものは以下。

大阪と東京の高層ビルの写真とひとことが書かれた本。装丁がかなりしっかりしている。僕も結構高層ビルはすきなので楽しめた。東京の「環状２号線プロジェクト」と「大阪東京海上日動ビル」が気になったのでいつか確認しにいこう。あと、やっぱり六本木ヒルズの森タワーは好きだ。

発行：超高層ビルを愛でる会。¥400くらい。

ミニ四駆の（再）入門書。かなりボリュームのある一冊。小学校の遠足のしおりのような、手作り感あふれる装丁。最近のミニ四駆シャーシの動向から、作り方・チューンナップのコツ、そして公式大会に出場するまでの流れまでがぎっしり書かれている。小学校３，４年くらいのときに２度ほど公式大会にでたことがあるけど、公式大会ならではの巨大なコースはわくわくしますね。機会と気力があればミニ四駆、久しぶりに触ってみたい。

発行：犬神研究所。¥400くらい

工場から、官公庁、酒造、東京証券取引所、皇居、など関東のさまざまなスポットに関するレポートがまとめられたもの。いかにも面白そうな内容だったので1,2巻まとめて買った。さらにコカコーラ工場見学の経験をもとに書かれた「MMRコカコーラの陰謀」というマンガも購入。

発行：とこしえ工房。¥200〜¥300くらい。

以上、３サークルで買い物しました。まずどれも非常に安くて、¥200〜¥700くらいで、ちょっと普通の本屋にはおいてないようなマニアックな本が買えて、なかなか楽しかったです。2,3日目は行かないんだけど、プログラミング技術系の本とか、古いTVゲームに関するエッセイとか、あとはロックとか音楽系の本とか、そういうものがあれば欲しいかなーと思いました。今度は夏？かな。また行こうかな。

さいごに

ついでにと言ってはなんですが、2012年もいろいろお世話になりました。2012年統括的なブログを別途書くかどうかは未定。

2013年は、とりあえずアレをアレしなきゃなー。関係各所のみなさま、いろいろとお世話になりそうですが、どうかよろしくお願いします。

窓ぎわのトットちゃん

以前品川区の大崎というところに住んでいたんだが、自宅のとなりに「トット文化館」という障害者のための施設があった。「トット」ってなんだろうと妻に聞いたところ、黒柳徹子さんのあだ名であることがわかった。ふむーと思いつつ４年くらい大崎に住んで、いまは別のところに住んでます。

それでたまたま誰かのブログで「窓ぎわのトットちゃん」という本の話がでてて、そういえばまだ読んでないなーと思い、妻にたのんで図書館で借りてきてもらって読みました。

話の舞台となるトモエ学園、校長先生、そしてトットちゃん含め生徒全員がとても自然で優しくていい感じでした。

うちの娘もぜひこんな感じに育ってくれるといいな〜と。

窓ぎわのトットちゃん (講談社文庫)

解いてみた/ザッカーバーグの面接試験２：アクティビティ・インディケーター

ザッカーバーグの面接試験２：アクティビティ・インディケーター
http://satoshi.blogs.com/life/2012/08/zack2.html

こんな感じかな？

#import "NetworkActivityManager.h"

@implementation NetworkActivityManager

+ (id) sharedInstance {
    static NetworkActivityManager* manager;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        manager = [[NetworkActivityManager alloc] init];
    });
    return manager;
}

- (id)retain {
    [super retain];
    if ([self retainCount] > 1) {
        [UIApplication sharedApplication].networkActivityIndicatorVisible = YES;
    }
    return self;
}

- (oneway void)release {
    [super release];
    if ([self retainCount] <= 1) {
        [UIApplication sharedApplication].networkActivityIndicatorVisible = NO;
    }
}

また、このケースで、シングルトンへのstrong referenceを使う利点と欠点を述べてください。

・利点：Reference countがインジケータのON/OFFスイッチの代わりにつかえてシンプルに書ける
・欠点：うーん、とくに思いつかない。関係ないところでは、上のコードはARC対象外になっちゃうので微妙ってくらいかなぁ。。

GCDとpthraedのコード比較

Grand Central Dispathでで並列プログラミングする場合に、条件変数(Condition Variable)を使いたい時はどうすればいいのかみたいな話を同僚としてたので調べてみた。結論としてはpthread_cond_xxxを使えばOK。

ところで私はpthreadもGCDもそんなに詳しくないので、学習がてら小さいコードを書いて両者を比較してみることにした。

pthreadで並列プログラミング

まずはGCDを使わずに、pthreadを使ってマルチスレッドなコードを実装。適当にpthreadでぐぐったら、codezineに良い感じの記事とサンプルコードがあったので、これをベースにする（一部いじってある）

引用元：CodeZine「pthreadについて（条件変数・モデル）」
http://codezine.jp/article/detail/1894

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>
#define THREAD_MAX 256

void* tmp_func(void* arg);

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t ready_mutex = PTHREAD_MUTEX_INITIALIZER;

pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
pthread_cond_t ready_cond = PTHREAD_COND_INITIALIZER;

int start_flg = 0; //(2)pthread_cond_broadcast受け取り漏れ対策

int main(int argc, char** argv) {
    pthread_t pt[THREAD_MAX];
    int thr_count = 10;
    
    pthread_mutex_lock(&ready_mutex);
    for (int i = 0; i < thr_count; i++) {
        pthread_create(&pt[i], 0, tmp_func, &i);  //(1)indexの受け渡し対策
        pthread_cond_wait(&ready_cond, &ready_mutex);
    }
    pthread_mutex_unlock(&ready_mutex);
    
    sleep(1);
    
    start_flg = 1;
    fprintf(stdout, "pthread_cond_broadcast\n");
    pthread_cond_broadcast(&cond);
    for (i = 0; i < thr_count; i++) {
        pthread_join(pt[i], 0);
    }
    return 0;
}

void* tmp_func(void* arg) {
    pthread_mutex_lock(&ready_mutex); //(3)signal発行前に呼び出し元でwaitしていることを担保
    int index = *(int*)arg;
    pthread_cond_signal(&ready_cond);
    pthread_mutex_unlock(&ready_mutex);
    
    fprintf(stdout, "start thread index:[%d]\n", index);
    pthread_mutex_lock(&mutex);
    
    while (start_flg == 0) {
        pthread_cond_wait(&cond, &mutex);
    }

    pthread_mutex_unlock(&mutex);
    fprintf(stdout, "end thread index:[%d]\n", index);
    return 0;
}

このコードは以下の様なことをやっている。

• 10個のスレッドを起動する
• 各スレッドには起動時にindexが与えられる
• 各スレッドは条件変数により待機状態になる
• 全てのスレッドが起動しきったところで、待機しているスレッドを起こす
• 全てのスレッドの実行が完了したらプログラム終了

これだけだが、そのままだといくつか問題があるので以下のように対処している。

• (1)でスレッド側でiのポインタを渡す際に、呼び出し元でiの値を書き変えてしまわないように、条件変数ready_condを使ってガード
• 最後に生成されるスレッドがwaitする前に、pthread_cond_broadcastされると、broadcastを受け取ることなくwaitしつづけるので、(2)のstart_flg変数でwaitするしないを制御
• スレッド側で変数iを受けとってpthread_cond_signalを発行する際に、呼び出し元でwaitしていることを担保するために(3)でready_mutexをロック

ややこしいですねぇ。

GCDで並列プログラミング

上記プログラムを、GCDを使って書き換えた結果がこちら。

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>
#include <dispatch/dispatch.h>

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t  cond = PTHREAD_COND_INITIALIZER;

int start_flg = 0; //(c)

int main( int argc, char ** argv ) {
    int thr_count = 10;
    
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
    dispatch_group_t group = dispatch_group_create();
    
    for (int i = 0; i < thr_count; i ++ ) {
        dispatch_group_async(group, queue, ^{
            int  index = i; //(b)
            fprintf( stdout, "start thread index:[%d] input!!\n", index );
            pthread_mutex_lock( &mutex );
            while (start_flg == 0) {
                pthread_cond_wait( &cond, &mutex );  //(d)
            }
            pthread_mutex_unlock( &mutex ) ;
            fprintf( stdout, "end thread index:[%d] output!!\n", index );
        });
    }
    sleep( 1 );

    start_flg = 1;
    pthread_cond_broadcast( &cond );
    dispatch_group_wait(group, DISPATCH_TIME_FOREVER); //(a)
    dispatch_release(group);
    return 0;
}

なんかだいぶスッキリした気がします。

ポイントは以下。

• まずはblocksで無名関数がかけるのでスッキリ
• joinのかわりにdispath_group_waitを使って、待ち合わせ処理がスッキリ (a)
• 変数iの値は(b)の時点でblocksによってキャプチャされるので、iの受け渡しのために条件変数と同期変数を使う必要がなくなってスッキリ
• start_flgが必要なのはかわらず(c)
• GCDを使っていてもpthread_condやmutexは問題なく使用可能(d)

GCDとblocksによってかなりスッキリして良い感じです。GCDによってスレッドの制御も最適化されて性能的にも良さげです。

このへんの話は以下の資料、書籍も参考になります。

並列プログラミングガイド
https://developer.apple.com/jp/devcenter/ios/library/documentation/ConcurrencyProgrammingGuide.pdf

エキスパートObjective-Cプログラミング ― iOS/OS Xのメモリ管理とマルチスレッド
http://tatsu-zine.com/books/objc

怪しい点があればご指摘ください。

2012/07/01 21:01追記

• start_flgやめてdispatch_semaphoreをカウントダウンラッチ的に使えばいいね