Thought about system by Hiroyasu Ishikawa

We are uncovering better ways of developing system.

goroutineを試してみた

Go言語のgoroutineを試してみたのでメモ。

なぜ試したか

Go言語の筆頭の特徴っぽいので。

どう試したか

Windows環境にGo言語の環境をインストールして、以下のように実装、コンパイルして実行。

func say(s string) {
	for i := 0; i < 4; i++ {
		time.Sleep(1000 * time.Millisecond)
		fmt.Println(s)
	}
}

func main() {
	go say("world")
	say("hello")
}

回数とスリープ時間を変更して試していたらworld出力される前に終了しているケースがあった。
f:id:hiro211:20180401231254p:plain

ポートで動いているプログラムを確認する

Linuxのポートで動いているプログラムを確認する。lsofはインストールされていないとする。

デーモンがポートをLISTENしているかを確認したかった。
しかも、lsofがインストールされていない環境で、むやみにインストールはできない。

netstat の-pオプションを使った。
なお、管理者権限(sudoするなど)でないと出力されないものがほとんど。

SHIROBAKOに添えて、アニメーションを作ること

SHIROBAKOは言わずもがな、アニメーションを作ることをテーマとしたアニメーションだ。そこから、自分のお仕事や夢などに重ね合わせて語られることも多い。しかしながら、ここはやはりSHIROBAKOの内容に沿い、私がアニメーションを作ることについて感じていたことを書いてみようと思う。

時々、疑問に思うことがある。アニメーションは、どういう産業なのだろうか、と。モノを作るから工業なのだろうか。
作る人の構成から見てみると、アニメーションを作る現場を描いたSHIROBAKO、登場人物に字幕をあてるほどに関係者が多い。
f:id:hiro211:20171214215152p:plain
それは、エンディングに流れるスタッフロールを見ても明らかだ。広報や総務のような間接的にかかわる人を抜いても、テレビ作品1つに対してだって10人や20人ではない。 2人集まればチーム、なんて話を聞いたことがあるが、これだけの人数がいると間違いなくチームとなる。だからこそそれをまとめる制作が必要となる。
そして、作業を見てみると、それぞれのセクションで分業化が進む。
第9話「何を伝えたかったんだと思う」では、監督のスランプと並行して、美沙の3D業務が語られる。クルマの部品の3Dをひたすら作るのだ。特に、美沙は日々タイヤと格闘している。
f:id:hiro211:20171214215223p:plain
そして、同僚に問う。「明日も明後日も、1年後も2年後も車ですよね」
同じようなものを日々作っている、と言いたかったのかもしれない。

ここまで見ると、確かに工業に近い要素を持つ気がする。しかし、それは機械のような工業と違う側面を持つ。例えば、芸能に近い側面を強く持つと感じる。
例えば、原画。絵コンテという上位の指示はあるものの、キャラクターを動かすのは原画マンだ。 それは俳優が脚本や監督の指示に従って、アクションするのと非常によく似ていると思うのだ。
アニメーターがキャラクターの動作を考え、キャラクターを絵の上で演じさせる。自分自身の体を動かすか絵の上の体を動かすかという御する対象の違いはあれど本当によく似ている。
第7話「ネコでリテイク」では、アニメーターの絵麻がネコを描くのに苦悩する。
f:id:hiro211:20171214215336p:plain
これを、俳優基準で考えると、自分がネコになり、ネコの動作をするということに近い。アニメーターは時として人間以外も演じるのだ。
表題とは全く関係ないことだが、絵麻かわいいよ、絵麻。

この工業的な側面と芸能的な側面がアニメーションを作り続けることの難しさにつながっているように感じる。
例えば、近年、アニメーションは業務時間や収入面で良くない話題が多い。SHIROBAKOの中でも深夜に及ぶ作業が幾度となく描かれている。収入面も問題が赤裸々に描かれていないものの、一流のアニメーターといってよい瀬川さんでさえ小さいアパート住まいである。
f:id:hiro211:20171214215359p:plain
これが頭脳労働者、ホワイトカラー、ビジネスマンのような視点で見ると、業務時間がおかしい、収入が釣り合わない、となるのだろう。しかし例えば、芸人、役者の視点で見てみるとどうなのだろう、とも思うのだ。売れていない芸人が前座をたくさん努めたから、その時間単位の給料をもらってはいないし、それに対して批判する人は少ない気がする。

実は、私はソフトウェア開発を生業としているが、近い場所にアニメーション制作がある。最近少し遠くなったが、制作の現場は変わっていっているのだと感じる。アニメーション関係なく、組織はそう簡単には変わらないのが常であるが、アニメーション制作は変わっていっているように感じるのだ。時折、アニメーションを作ることはソフトウェア開発と似ているように感じることがある。妻とその類似性について話したことがあるが、またどこかで話すことができたらと思う。
f:id:hiro211:20171214215510p:plain
SHIROBAKOにエンタメとして描かれたことは、今後どう変わっていくのだろうか。今後アニメーションはどう作られていくのだろうか。
エンタメに昇華させた方々に拍手を送りながら、未来を期待してSHIROBAKOを今夜は見ている。

ICONIXプロセスのロバストネス分析をastah*でやってみたお話

これはなに

ICONIXプロセスはユースケースから駆動する開発手法で以下の本が詳しい。
www.shoeisha.co.jp
この開発手法で、ユースケース(分析)と設計の狭間にロバストネス図を使ったプロセスが存在する。
これをUMLツール(astah*)でやってみた。

なぜやるの

分析の過程でシステムを意識しすぎると、設計の幅を狭めてしまう。
そのために、システムを意識せずに分析したとする。
ここで、アーキテクチャ設計をしようとすると分析と設計の間に溝ができてしまう。
分析とアーキテクチャ設計の間にもう1つ設計(名称はロバストネス「分析」だが)を挟む。

どうやるか

ロバストネス図専用のダイアグラムはないので、コミュニケーション図で書く。
書籍と少し異なるが、目的は達成できる。また、見た目もあまり変わらない。

f:id:hiro211:20171201122050p:plain

さらに、UIやActorをパッケージでまとめるとこんな感じで構造ができる。
f:id:hiro211:20171201122131p:plain

UIとそこで実行可能な機能になっている。このまま機能仕様書の章立てになりそう。

テストライブラリ Friendly を触ってみた

UIテスト*1のライブラリを触ってみた。

GitHub - Codeer-Software/Friendly.Windows

背景

業務でUIテストを手動でやっていて、少し辛い。"Be Lazy."の言葉に従って自動化のF/Wやライブラリを触ってみている。
Google検索で見つけてひょっとしたら良いカモ、と思ったので。

準備・実装

NuGetでダウンロードして、テストコードを書く。

[TestMethod]
public void TestMethod1()
{
	var app = new WindowsAppFriend(Process.Start("UITestSample.exe"));
	var process = Process.GetProcessById(app.ProcessId);

	dynamic form = app.Type<Control>().FromHandle(process.MainWindowHandle);
	form.SetTextBoxText("HELLO");
	string text = form.GetTextBoxText();

	Assert.AreEqual("HELLO", text);

	process.CloseMainWindow();
	app.Dispose();
}

所管

UIにメッセージ送って動作させる物ではないのでUIテストっぽくない。
プロセスに対して操作するので、結合テスト用には使えるかも。

*1:実際は結合テスト

DevOpsに関するセッションのメモ

要求開発アライアンスさんの7月定例会のメモ。
DevOpsに関するセッションがあるということで参加してきた。
2017年7月定例会 - connpass

"DevOpsを国内外の事例を活用し取り入れる (Adapting Foreign DevOps Idead in Your Organization)"というタイトル。

内容

心に引っかかった箇所を以下にメモ。
※ 引用で記載していますが、まんまではありません。*1

言葉、会社(仲間、同僚)、文化が異なる。Different languages, companies, culture.
ビジネスの領域が異なる。Different business.

同じ日本であっても、会社が異なれば、ビジネスの領域が異なる。
それは、海外から来たものと同様に、「外部の物」であって、そのままではなじまない。

チームのエンジニアの技量によっても手法を取り入れられるかどうかは変わる。
Don't become "Tom" *2

であれば、海外の似たビジネスの領域から来たDevOpsを参照したほうが良い。

Dev, Ops, QA*3の重なる中心に。

共感 Empathyについて

米国であればOut Going、スポーツやBBQのような。
日本だと飲み会。飲み会は、共感を目的としたイベント。文化。

The Culture of Blame と The Culture of Shame

米国、Blame(責め、非難)の文化、sorry(謝ること)は即ち過ちを認めること。メールやチャットのような記録が残る物が流行る背景ともなっているかも。
日本、Shame(恥)の文化。

文化を変えるのは容易ではない。(変わるかも知れないが)
文化に合ったDevOpsを。
inspirationを取り入れる。やるのはあなた(自分)達。

所感

感じたことをメモ。

恥の文化、"Culture of Shame"、は新しいことへの挑戦や改善に対して、時に障害となりうるのではないか。
恥の文化を認め、これが障害とならないような手法での取り入れ(DevOpsに限らず)が良さげ。
言葉が一色で、ハイコンテクストな日本の会社の文化で、皆感じているのに、課題は明確になる機会が少ないのではないか。
課題は明確になった時点で解決に向かう力が発生すると思う。明確にならない、明文化されないような状況はなるべく避けたい。
カンバン、朝会は馴染む。話しても恥ずかしさがない状況がそこにあると思う。
Agileもそうだが、DevOpsも人の心が大きく関わってくる、ツールや手法のみに目を捕らわれないように気をつけたい。

謝辞

セッション登壇頂いた Alex Papadimoulisさん、Sei Matsumoto はじめ要求開発アライアンス運営の皆さんに感謝です。

*1:そもそもセッションはEnglish

*2:Tom、とはそのまま外部のDevOpsを取り入れようとした人

*3:Quality Assurance