何してるのか?

最近プライベートだと仕事とは別の言語使っていることが多い。それはまあ別のことがやりたかったり、読みたいプロダクトが別の言語だったり色んな理由があるんだけど、とてもしんどい。自分の好きな言語で好きなことしてるのになんでこんなにしんどいのか、おそらくは目的に到達するためにもっと早い自分を知っていてその比較から多分いらついていてそれで苦しんでいる。どうにかならないかなぁと考えていたら、そもそも僕は言語を通して何をしていたのかということふと思い至ってそれですごく楽になった。

わかりやすい発表とはどんなものなのか?

つい先日カンファレンスにいって何件か発表を見てきました。どもれ素晴らしい発表でしたが、私の不勉強と認識の問題が大きいかと思いますが、分かりやすいプレゼンとわかりづらいプレゼンがあってなんでだろうな?と考えてしまったのでちょっとメモしておきます。 分かりやすいプレゼンに絞って言うと、これから何を話すかという目的、概念、抽象化されたものが先に来ます。そこからトップダウンで下がっていって具象、詳細に至ります。これは日常の現象に対する認識と逆で、通常の場合現実に起きている具体的な現象を認識してそこから「何が起きているのか?」ということを考えたり、相談したりして結論を得ます。つまり、具象から入ると言うことは見ている人にワンテンポ考えさせてしまうということです。これはこれで使いようによってはいい発表になるときもありますが、難しいことを喋っている、発表している、若しくは分野が広域に広がっているときには逆に混乱してしまいます。なので、何を話すんだよというのを大きく先に提示した上で、つまり結論を先に言った上で詳細を解説するという流れが分かりやすいのではないのかなぁとぼんやり考えてたりしました。あとは、具体例にたいしてしつこく何が起きているのかを述べているのも分かりやすかった気がします。「具体例」-> 「突然のエラー」-> 「つらい」みたい感じかな。見てる人に旨い感じに脳味噌を使わせると言うことが重要じゃないかとも考えました。

正しくレビューをするということが難しいのはなぜだろうか

システム開発をしていると、大体において開発した物に対して識者からレビューという物が発生します。非常にわかりやすく言うと、できあがった物が適正かどうかを判断してもらうわけですね。ところがこのレビューという物、適切に行うのは非常に難しいのです。

  • レビューする側が問題領域をきちんと理解してる必要があり。
  • さらにそこに使われている技術等が適切かどうかの判断。
  • データ量などが将来にわたってどうなるか等を判断

などをしなければいけません。物事の論理に従って理性的に、良い意味で機械的に正しくあるべき姿を提示できるのが理想的かなと思っています。現状自分がいるところはある意味適切という意味で希少な例のところにいるかなとはおもっていますが、ただ、大抵の場合そうはなりません。レビューという名の誰の益にもならない個人たたきになる場合が非常に多かった気がします。上記の3つをきちんと満たすことはもちろんのこと、適切じゃ無いレビューをすることがレビューをする人にも、受ける人にも、会社にも、誰の得にもならないと言うことを理解してなければならないと思います。その上で、将来のために、相手のために、自分自身のために行うことが必要じゃ無いかなとは思います。悪い例を挙げていくと、

  • 重箱の隅つつき
  • レビュー段階ならないと発覚し得ない情報がある(暗にこめたんですよねとか)
  • レビュー者の気分で技術方針がコロコロ変わる
  • レビュー者の趣味の押しつけ

などがあげられます。もちろん大抵の人間は神じゃないので完璧じゃ無いのでこれを毎回100%満たすことは無理だと思います。こういうことが起きうる要因って何だろうかと考えたときに、以下のレビューアーが内包するメタデータに起因するのでは無いかと思っています。

  • そもそもどうやってレビューするのか不明
  • 本人の性格
  • 技術レベル
  • 体調の良し悪し
  • 技術的指向性が開発者と同じ方向性をむいているか
  • 交友関係の障害等
  • 現在担当している仕事の量
  • 開発者が好きか嫌いか
  • 社内政治

本人の性格や技術レベル、社内政治や交友関係等は解消しづらい問題では無いかなとは思いますが、対人問題であれば双方にとって気持ちよく終わって問題を起こさないようにするぐらいしか指針が出せませんが(問題領域に詳しくおすすめの書籍等詳しい方は教えて頂きたいです)、こちらが根が深く根本的に解消しづらいところもあるので困難さの一員では無いかと思います。単純にレビューという技術であればぱっとアマゾンやググって見た感じ何件かでてきたので並べておきます。何かおすすめのサイトなり書籍があれば知りたいです。

ソフトウェア・レビュー技術―基礎から実践までのノウハウ

ソフトウェア・レビュー技術―基礎から実践までのノウハウ

なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー

なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー

ピアレビュー

ピアレビュー

多岐にわたった知識を総動員し、それぞれに対してかなり詳しく使いこなしているする必要があり、そういった理由から難しい技術なんじゃ無いかなぁと言う気はしてます。関係する領域においてなるべく勉強はしておきたいです。(自戒の念を込めて)

openされたファイルとunlinkについて

tmpfileの挙動でオープンしたと同時にunlinkが発行されて後始末をしなくていいという話だったんですが具体的にどういう挙動なんだということが気になりまして調べてみたら、unlinkはファイルシステム上の名前の削除で、さらにどのプロセスもファイルをオープンしていなければファイルが削除されるという(see man 2 unlink)ことになっていて、tmpfileの挙動はこれを利用した物になっているようです。従って受け取ったファイルディスクリプタをcloseしてしまうとプロセスが起動中でもそのファイルは削除されてしまうようです。

tmpfileについて調べたこと

Linuxにおいて大体何かを組んでいると一時的に何かに保存したいとかメモリ食べたくないとか様々な理由で一時的なファイルを作成すると思います。一時的なファイルを作成すること自体はそこまで難しくなく/tmp/以下に好きな前をつけて扱えばいいと思うのですが、好きに/tmp以下にファイルを作るのは複数プロセスが立ち上がった場合に同一ファイルを意図せず見てしまう、他のプログラムが同一の名前を意図せず使用してしまう、セキュリティホールなどになってしまう(see man tempnam)などの危険性があります。頑張ればこれらの問題はファイルオープン時におけるオプションのO_EXCL(see man open)とファイル名生成の工夫で大体は解決つくはずですが、これを頑張らなくてやってくれる仕組みがtmpfileです。読み書き用で開いてO_EXCLで他のプロセスが同じ名前で開くことを防ぎます。おまけにオープン直後にunlink実行してて削除してくれるので後始末も安心です。(/tmp以下は大体の場合はtmpwatchというcronによって良きに削除されていくのでそこまで問題にはならないですが)各言語にもtmpfile相当のものが実装されていて似たような挙動をするはず。

例を取ってPerlだとFile::Tempというモジュールがありまして。

tempfileの実行テスト

use strict;
use warnings;
use File::Temp qw/ tempfile /;

my ($fh,$filename) = tempfile( UNLINK => 1);

print $filename . "\n";

実行結果

/tmp/T4Yk7WE06m

確認すると削除されています。

デフォルトの挙動でファイルが残るので
UNLINK => 1 をtempfileのオプションとして残すと削除されました。

同様な処理として一時的なディレクトリを作成する処理としてtempdirというものがあるのですが、LinuxProgrammingInterfaceにはこの用語出てこないです。代わりにmkdtempというCライブラリの話が出てくるのでこちらがあたるのでしょうね。

なんていうか

会社とかで長く生き続けるメンテしづらくてパフォーマンスでないコードのことだと思うけど、くそコード連呼されるのをみてて思うのは、死ぬ気でその集団を守ってきた老兵にその集団で生かされてきた若造が唾はいているようなものにみえて、おまえがそこまで生きてこれたのその老兵のお陰なんよ。とか頭の中よぎってしまう。自分が頑張るんでもう良いんですよぐらいの気持ちでいたい。

3年たったのでかいてみる

正直、震災を忘れたい人もいるだろうからこの日のメディア震災一色はどうにかして欲しい気がする。被害地にいたわけでもないし間接的に関わっただけでも割としばらくの間は精神的にしんどかった。当事者の方々はどう思ってんのかは計り知れないし、どこに直接的な被害者がいるのかわからないからうかつに話題にはだせない。海外のTVドラマで911が深刻な話として直接間接いまでもふと話題に上がるのは似たような心情なんだろうなとおもう。震災の復興自体は今でも継続した話だし追悼などの話がいまでも上がるのは忘れっぽいこの国にしては、というよりはこの国だから忘れないようにしてるのか。悪いことでは無いが忘れたい人もいるんじゃ無いかとおもって時折考えてしまう。