eachメソッド（for文）は嫌い

eachメソッド(for文)は嫌いで、極力（Rubyで言うところの）mapやselectやreduceを使う。
理由は引数で与える集合と演算結果の関係性を不透明にしないためである。

文章を簡単にするため、引数の集合をxsで戻り値の集合をysとする。

mapの場合、ysはxsと同数の集合である。
ysの一要素はxsの一要素によって決定され、他の要素は関連しないことが期待される。
xsに順序がある場合、ysでもその順序が保持されることが期待される。

selectの場合、ysの１つ１つはxsのいずれかと同値であり、ysの要素数はxsと同じか、より少なくなる。
ysの一要素はxsの一要素によって決定され、他の要素は関連しないことが期待される。 （mapと同じように）
引数に順序がある場合、戻り値でもその順序が保持されることが期待される。

reduceの戻り値は１つの値である。
基本的にxsの順序に戻り値は依存する。演算が交換法則を満たす場合は、引数の順序に戻り値は依存しない。

for文やeach文は以上のことが明示的でない。よって嫌いである。
逆に言えば、特に戻り値が期待されない場合はfor文やeach文を使う。
集合を条件で絞りながら変換させたいなら、selectをしてからmapをするべきだ。

maxやsumはreduceの仲間である。findはselectにもreduceにも近い。

Google Homeで使える便利な音声コマンド7選！スマホで使えるコマンドも！

昨日のベストバイ記事で書き忘れてたのですが、実は先週くらいにGoogle Home miniを買いました。我が家のデュアルディスプレイの真ん中にちんまり陣取っています。chromecastとも連携できて非常にいい感じです。
とはいえ、結構使うのにコツが居るデバイスだと思っていて、使いにくいデバイス大好きな自分の努力の成果としてよく使う便利な音声コマンドをご紹介いたします！

Google Home編

「今日はどんな日？」

日付、曜日、今日の天気や気温を知りたい時に使うやつですね。朝は大体この一言から始まります。
洗濯するかとか傘持っていくかとかどれくらい厚着するかとかはこれで決めてます。

「自宅から職場までの電車での行き方」

最速経路を選んだ場合の、自宅の最寄り駅での発車時刻も教えてくれます。
また、職場への到着時刻も、自宅から職場までの移動に掛かる時間も教えてくれます。
「職場」の部分を適当な駅や場所にしても同様の機能が使えます。事前に自宅や職場の場所を登録しておく必要があります。

「テレビを一時停止して」

chromecastでyoutubeやdアニメの動画をみることが結構あるんですが、それを一時停止する時に使います。
以前はスマホからぽちぽちしてたのですが発声のほうがスムーズですね。
一時停止を解除したい場合は「テレビの一時停止を解除して」と言います。

youtubeやgoogle play music系のいろいろ

youtubeやgoogle play musicをだらだら流すのにはgoogle homeは最適ですね。
まず、「テレビで動画を見せて」でchromecastを繋いでるテレビからyoutubeのオススメが順番にながれます。
チャンネル登録などをこまめにやっていればお気に入りの投稿者の動画をいい感じに進めてくれます。
「テレビでお気に入りの曲を流して」とするとchromecastでgoogle play musicのお気に入りプレイリストに入れてる曲が流れます。事前に聞きたい曲をプレイリストにまとめる必要がありますが、普段から心がけていればそんなに大変ではないです。既にシャッフル再生用のプレイリストがある方も多いのでは？
気に入らなかったら「次の動画/曲」で飛ばせます。「シャッフル再生して」もできます。「音量を50%して」なども可能です。

「明日の○時に起こして」

所定の時刻にアラームを設定します。
結構、平日にゲームとか飲みとか勉強の予定を入れがちで、起きる時間や寝る時間がまちまちになりがちなので、一言でアラームが設定できるのは嬉しいです。

Android編

google homeはまだ予定の登録やreminderの登録には対応していません。なのでその辺は大体にスマホからok google(google asistant)でやります。

「◯日の◯時に○の予定を入れて」

予定の登録です。確認画面が出るのでOKを押せば登録されます。
確認画面回りのボイスUIが上手く行かないからgoogle homeにはこの機能がないのかもしれないですね。

「◯時に○を思い出させて」

リマインダーの登録です。
リマインダーは場所でも設定できて、「自宅についたら（帰ったら）○を思い出させて」とかも出来ます。 洗濯物の取り込みとかをリマインド設定するのに便利です。

2017年ベストバイ!!買って良かったもの7選

今週のお題「今年買ってよかったもの」

さてさて、今年も師走の季節になりました。 2017年ベストバイ行ってみましょう。

1. 革靴

自分の生誕1万日記念に革靴を買いました。次の1万日（27年）を一緒に過ごせるもので、今持ってない物がいいなと思って革靴を選べました。（もって１０年位かなとは思っていますが）
スーツを着て仕事してたときは毎日履いてましたが、カジュアルな服に合わせるものをあんまり持ってなかったので。パドローネの3万円くらいのやつと、オーダーメイド靴の3.5万円くらいのやつで2足買いました。

PADRONE パドローネ 短靴 ダービー プレーントゥシューズ ブラック キャメル 40 41 42 (40(25.0cm-25.5cm), キャメル)

2. ゲーミングパソコン

20万円くらいのパソコンを買いました。6年半世話になったデスクトップPCのマザボが壊れて、他のパーツもかなり年代物だったのでフルで買い替えました。ツクモで選びました。GTX1080、メモリ16GB、Corei7-7700、1TBSSDって感じです。

ゲームPC【G-GEAR】- TSUKUMOおすすめのBTOゲーミングPC

3. Oculus Rift

パソコンを買い替えてVRが十分動くスペックのマシンが手に入ったので買いました。まだしっかり遊ぶ時間を作れてませんが、ちょいちょい楽しんでいます。black fridayセールで税込み50,000円くらいでした。

Oculus Rift cv1 製品版 2016 オキュラス リフト (Oculus Rift cv1 製品版) [並行輸入品]

4. Bluetoothオーディオレシーバ

便利に使ってます。Bluetoothイヤホンでいいのではと思われるかもしれませんが、レシーバであればイヤホンは好きなものを使い続けられます。イヤホンにこだわりがあるならレシーバのほうが安全です。

エレコム マイク搭載Bluetooth4.1対応レシーバー(レッド)ELECOM LBT-PAR02AVRD

5. 親指ボールマウス

仕事中に使うマウスをApple純正のmagic mouseからトラックボールマウスに変えました。慣れるまでは苦労しましたが今は普通に使えてます。狭い場所で使えるので楽で良いです。キーボードを触らずに文書を読んでるだけのときとかは、膝の上や空中でも操作できます。

LOGICOOL ワイヤレストラックボール M570t

6. ルームシューズ

家でもスタンディング環境を整えたので、家の中でも履ける靴を買いました。裸足で立ってるのは辛い。

panda family(パンダファミリー) ムートン風 ルームシューズ スリッパ パープル Mサイズ(23.0?24.5cm)

7. プロテイン

春〜夏くらいから飲み始めました。今でも飲んでます。公式サイトで3kgまとめ買いのほうが安いです。

ビーレジェンド ホエイプロテイン ナチュラル 1Kg

以上、2017年ベストバイでした！

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

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

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

• 賛成
• 反対

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

人月の神話【新装版】