kazasiki's blog

プログラミングとかVRゲームとか

賛成と協力は違うし、反対と妨害は違う

尖ったことをしようとすると大体の場合身近な誰かに反対されるわけですが、個人的にはあんまり気になりません。単に私の神経が図太いと言うだけの話でもあるんですが、基本的には「反対されても実際に妨害されないなら無視する」のが信条なのです。

他人に賛成されるか反対されるかを気にする人は世の中を

  • 賛成
  • 反対

に二分してしまいがちです。

ただ、実際には行動に出る人と出ない人がいます。賛成の行動は協力で、反対の行動が妨害とすると、

  • 賛成でかつ、協力する
  • 賛成だが、協力しない
  • 反対だが、妨害しない
  • 反対でかつ、妨害する

といった感じになります。

何か行動する上で重要なのは、「賛成でかつ、協力する」を増やして、「反対でかつ、妨害する」を減らすことです。特に協力を求めていないのであれば、「反対でかつ、妨害する」だけ気にしてればよいでしょう。基本的にこの数は、単なる賛成と反対の比率とは全く比例しません。

どんな感情を持たれていようが実際に行動に示してこない限りは大して気にする必要はない、という原則を自分の中に持てばわりと自然に図太い人になれます。

変数名に型を含むのは避けた方が良い

変数名に型を含むのは避けた方が良い。異論は認める。まず、つい最近リファクタリング(?)で大変苦労した話をさせてください。

例えば、Userクラスがあったとして、きっとみなさんはコードの何処かにこう書くでしょう。

user = User.new(name: 'hoge', age: 12)
print user.name

Ruby on Railsを使ってるときもModel層にUserクラスがあれば、きっと上のようなコードを書くでしょう(だってRuby on Railsチュートリアルでもそうなってるし!)。

ここで何かしらの理由があってUserテーブルをCustomerテーブルに変更するとしましょう。ほら、サービス自体が有料会員制に変更になったのでUserよりもCustomerの方が正しい気がします(?)。そして、これは恐らくみなさんが思っているよりもとても辛い作業になります。

テーブル名の変更などはさておき、クラス名の置換は問題なく行えます。IDEなどの機能を使えば数分の作業でしょう。ただし、この後に変数名の置き換えの作業があります。例えば、先ほどのコードのuserという変数はどうやって見つけましょう?Userクラスを探せばその近くにいますし、userという文字列でgrepしたらだいたい見つかるんですが、一斉置換するのが難しい作業であることは明らかです。tmp_userなどちょっと変形した変数名もありえます。usrのようなtypoなのか省略なのかよくわからないものもあるでしょう。

以上の話から導かれる私の結論は、変数名に型を含むのはリファクタリングを難しくするということです。

とはいえ、動的型の言語で変数名に型を含めないのは難しいです。特にメソッドの引数については名前だけが性質を読み取る情報源です。引数xが呼べるメソッドをどうやって予測すればよいでしょう?インスタンス変数やクラス変数も同様でしょう。

ただ、メソッド内で宣言する変数(ローカル変数)は型を含めないことが出来るのではないでしょうか。変数のスコープを十分に短くすればよいのです。逆にこういったルールはどうでしょう? ローカル変数は、宣言とスコープの終わりが必ず画面内に収まるようにする というルールです。

私のコーディング環境ではディスプレイは大体40行くらいのコードを表示しています。1行の文字数はまぁ120文字くらいでしょう。この中で変数のスコープを切る。具体的に言えば、そのためにメソッドを分けたりブロックを区切ったりするのは可能ではないでしょうか?そうして変数にはもっとシンプルで型を含まない名前をつけましょう。 tmp とか a b とか x y とか id とか obj new_obj old_obj とか。そうすれば、テーブル名やクラス名の変更の際に、変数の修正に手間取らずに済むのです。

とここまで書いたものの、実際やるとなんだかんだ読みにくくなりそうだし何だかなぁという気持ちです。ここまで読んで頂きありがとうございました。

追記 2017/06/23 15:07

書き終わってから思ったけど、上記の苦労は設計における変更可能性の考慮が抜けてたからな気がしてきた。変更可能性の考慮というのは、例えば、Ruby on Railsでアプリケーションを構築するのではあれば、ActiveRecordという名前は(多分)変わらないが、自分が定義したクラスは変わる可能性が高いという話です。基本的に、使用するgemのコードや抽象化されたコードのほうが変更されにくく、業務に直接関連するコードの方が変更されやすくなります。

これを踏まえれば、例えば、user は変数名としてやはり良くないですが、 recordrc はめったことでは変更されません。抽象的だが変更に強い変数名になります。そんな感じにしてかつ、スコープを短く保てればあんまり読みにくくならない気がします。変更可能性の高い型を変数名に入れるとよくないって話ですかね。。。

安いケーブルは大事に使おう

1本数百円程度のケーブルだから雑に扱ってもいいという理屈は間違っている。

そのケーブルの断線によってなんらかのトラブルに見舞われた場合、それに対処する時間のコストは数百円を遥かに上回る。しかも、昨今の電子機器事情を考えれば常に複数の機器を繋いで使用しているのが普通で、不具合から原因を特定するのに要する時間は日々増え続けている。

例えばLANケーブルが断線した場合、あなたのPCはまずWebサイトが開けなくなる。ネットワーク設定画面を見たり、(役に立つのか微妙な)全自動トラブルシューティングを動かしたりしていればあっという間に30分や1時間はすぎるだろう。不具合の原因はルータかも知れないし、インタネットサービスプロバイダかも知れない。
更にいえば、LANケーブルの断線から事態を復旧するためには基本的に新しいLANケーブルが必要になり、もしあなたのすぐ近くに新しいLANケーブルが無ければ、それを調達する間はネットワークに接続することもできない。もちろんAmazonでLANケーブルを買うことも出来ない。 重要なメールを受信or送信することが出来ず、大きな商談を逃すかもしれない。

安いものであっても、ものは大事に扱おう。

どのようにしてプログラマは明らかなバグを見逃すのか

プラットフォーム(Web、スマホ、ゲーム機など)に関係なく、プログラムを書いていればバグを作ることはあります。 その中でも今回は「製品のローンチ後に、ユーザが低くない頻度で使う機能で、普通に操作したのにバグる」というあまり想像したくないケースについてそれが何故起こるのかを説明します。例えば、ローンチ直後のサービスでそもそもユーザログインが突破できない、みたいなやつです。

先にいうと、この問題にはまだ明確な解決策はありません。ただ、この記事ではその原因について解説を試みています。あなたの助けになれば幸いです。

唐突ですが、例えば、あなたがコップを作って売る商売をしているとします。仮に、コップを作る工程を大きく2つに分けて、形を作る工程と、絵を塗る工程としましょう。
あなたは先ずコップの形を作ります。コップに水漏れがあってはいけないので、工程の最後に必ず水を注いで水漏れがないかを確認します。あなたは水を注いで水漏れが無いことを確認できたら次の工程に進みます。
次に、あなたはコップに絵を塗ります。絵は綺麗に塗れました。しかし、あなたは絵を塗っている途中で何処かにコップをぶつけたらしく、コップに小さなヒビが入ったようです。しかも、あなたはそれに気づいていないようです。
かくして、ユーザにはヒビが入ったコップが届き、あなたは「なんでこんな明らかな欠陥を見逃すんだ!?」とクレームをうけることになります。

さて、この話から考えられることはいくつかあります。
まず、なぜ絵を塗った後にヒビ割れを確認しなかったのでしょうか?答えは簡単で、絵を塗る工程でコップにヒビが入ると思わなかったからです。逆に言えば、形を作る工程ではヒビが入る可能性があると思っていたということです。これは一般的な感覚から外れていないと思います。ですが、結果としては誤りでした。では、どうすればいいでしょうか?これも答えは簡単で、絵を塗った後にヒビ割れをもう一度確認すればよいのです。ですが、それは無視できない作業コストを生みます。

さて、ここまではずっとコップの話をしてきました。そろそろプログラムの話に戻りましょう。

この再確認のコストに対処するために私たちプログラマは様々な工夫を考えてきました。
一つ目は、総合的な動作チェックをローンチの直前にまとめて行うことです。この手法は「そもそも総合的な動作チェックは開発が一通り終わったあとにしか出来ない」という合理性からよく用いられています。しかし、その手の業界の方はよくご存知かと思いますが、プログラムの変更を要求する多方面からのプレッシャーは凄まじいものです。大抵の場合はそれに負けて動作チェック後に変更を加えてしまい、もう一度コストをかけてチェックをするか、バグがある製品を世に出すかの2択を迫られることになります。
二つ目は、動作チェックをプログラムによって自動化することです。素人感覚で見れば「その動作チェックをするプログラムにバグがあったらどうするのか。しかも自動化するコストは掛かるのでは」と思うかもしれません。これついて詳しく書くとまた文章が長くなってしまうため割愛します。しかし、何はともあれ私たちは積極的にこの手法に取り組んでいます。

こういった話に興味がある方は「人月の神話」を読んでみてください。プログラマの方でもそうでない方でも(多分)読める歴史的名著です。

人月の神話【新装版】

人月の神話【新装版】

私のWebからデザインが消えた日

大仰なタイトルにしましたが結論だけ言うと、SafariのReader表示を自動で有効に出来るSafari拡張を見つけた、という話です。

finbarrbrady.com

SafariのReader表示を知らない人に掻い摘んで説明すると、Webの文章をデザインとか全部省いた表示で見れる機能です。

私は基本的に常にReader表示を使ってWebを見ています。MacではSafariのReader表示、iPad miniでもSafariのReader表示、スマホ(Android)でもFirefoxのReader表示です。(対応していないサイトも勿論ありますが、そこは我慢して見てます。)
今まではなんだかんだ言ってReader表示に自動で切り替わってくれなかったので、一旦デザインが適応された画面を見る必要があったのですが、今後はサイトがReader表示に対応していれば自動でReader表示に切り替わります。やったー。

さて、ここまでが前置きです。

私の記憶が正しければ、Reader表示ははじめてブラウザが公式にコンテンツの改変に着手した機能だと思います。StylishのようなCSSの改変や、AdBlockerのような要素の削除はあくまでサードパーティー製のツールとして作られるだけでした。

これはサーバがHTML/CSS/javascriptを生成し、ブラウザはそれらを読み取って表示するというWebの技術設計的に避けられないことです。結局のところ、コンテンツがどのように表示されるかについてコンテンツ提供者は完全にコントロールすることは出来ません。気に入らないデザインは消されるし、邪魔な広告は削除されます。

私はそれはユーザの正当な権利だと思います。なぜなら、ネットワークは有料で有限で、その費用は基本的にユーザも負担してます。スマホがこれだけ普及した今となっては、容量制限があるプランで通信事業所と契約してる人はとても多いはずです。たとえ無制限だったとしても、それは高額な定額料金としてユーザに降り掛かっています。

この画像に1MBの通信費の価値が本当にあるのかなぁとかそういうことをよく思います。

【緩募】十万円くらいで私が喜びそうなもの

たまにTwitterFacebookで呟いていたですが、私は500円玉貯金をしています。最近はレジで500円玉がお釣りになるようにお金を払うのにも慣れました。昨年の10月くらいからやっていてちょうど半年くらいですね。やってみると意外に続くものです。

無印で買ったペンケースに500円玉を入れて行く形でやっていて、初期の見積もりだと一杯になった時に十万円くらいになる予定でした。この間数えたら7割くらい埋まったかなという見た目で本当に七万円ちょいだったので、一杯になったらほぼ予定通りの金額になりそうです。

特になんの想いもなく始めた500円玉貯金でしたが、これが一杯になったらその金額でちょっとした贅沢をしようと思っていました。 10万円くらいだからHTC Viveが買えるかなと思ってたのですが、要求スペックが高くてまずはデスクトップPCの方を買い替える必要がありそうです。 じゃあVRが遊べるスペックのPCを買うかとも考えました。私が今使ってるPCはもう6年も使っていてそろそろどこが壊れても不思議ではありません。買い替えるにはいい時期でしょう。ただ、VRをまともに動かそうとすると十五万から二十万くらいの予算が必要なようです。

ということで、今私は買うもの困っている訳です。十万円位で買えて、私が喜びそうなものが思いついた方は私にご連絡下さい。何卒宜しくお願い致します。

あ、PlayStation4PSVRNintendo switchは買う気ないです。コンシューマ機を今更遊ぶつもりはあんまりないので。

長時間労働は"スポーツマンシップに反する"と思ってる

昨年は電通のいざこざもあったし、最近はこんな記事も上がってるので長時間労働について個人的に思ってることを書きます。

http://www.tokyo-np.co.jp/article/politics/list/201702/CK2017021502000124.htmlwww.tokyo-np.co.jp

まず、今の労基法は基本的に経営者から労働者を守る意味合いが強いルールです。なので、過労云々の話題も基本的に経営側に責任が追及されます。長時間労働云々の議論も基本的にこの観点で進められることが多いです。それはそれで妥当だと思います。

ただ、日本のような資本主義社会は個人レベルで見ても競争と金儲けの社会です。なので、出来るだけたくさん働いて競争に勝ちたい、多くの利益を得たい、社会的な評価を得たいという考えは個人レベルでも深く根付いています。単純に働くことを楽しいと感じる人もいるでしょう。別に経営者に命令されなくてもたくさん働きたい人というのはある程度は必ずいます。

じゃあ、そういう人たちが好き勝手に長時間働いていいかというとそういう訳にはいかないだろうと私は思っています。その人達が過労で死ぬ分にはその人達の勝手ですが、競争社会では、その人達の労働が長時間労働したくない人たちにも影響を及ぼします。利益を上げなければ食べていけない以上、競争相手にも同じだけかそれ以上の労働をする圧力が発生します。それは無視できないものです。

それはそれでいいじゃんということも出来るのですが、長時間労働健康被害が出やすいとされています。端的にいって人は過労で死にます。労働者に自由に働かせて競争させた結果として、過労で労働力が失われるのでは社会は成り立ちません。なので、競争には程よいルールが必要なのです。今のところ労基法にそういった意味合いはありませんが、そういう意味でも程よいルールだと思っています。(もっと厳しくてもいいくらい)

例えば、オリンピックやプロ野球の世界ではドーピングの問題がたびたび話題にされます。ドーピングとは薬物などを使用した身体機能の強化のことで、現在は禁止されています。理由は色々ありますが、最も大きいのは選手への健康被害です。たとえドーピングによってスポーツがよりエキサイティングになるとしても、健康被害があるのでは業界自体の持続性を損なう可能性が高いからです。選手に自由な競争を許しているとしても制限は必要です。たとえ個人の権利や選択肢を奪う形だったとしても。

自分が長時間労働に耐えれて、その分成果を出せて、それを楽しんでたとしても、やっぱりそれはスポーツマンシップに反するのでは?と私は思います。結局それは業界自体を壊す行為なのでは、と。

これまで書いたことは結局綺麗事で、なんだかんだ言って長時間労働することはあります。ただ、私はいちおう長時間労働で成果を上げている人たちに対して3つのポリシーを持ってます。1つめは尊敬しないこと。2つめは参考にしないこと。3つめは競わないことです。簡単に言えば、選手として認めないということです。簡単なルールですが、個人的にはこれだけ頭に入れておけばだいぶ気は楽になります。

極端な話、この社会には「業界とか知るか!あと10年間だけ死ぬ気で働けばその先遊んで暮らせる金が手に入るんだぜ!」とか言って死ぬ気で働いて本当に死んでいく人もいるのでしょう。みんな週40時間労働くらいでぼちぼちやっていきましょう。