へぇボタンで理解するオブジェクト指向の利点（Go版）

へぇボタンで理解するオブジェクト指向の利点

ruby版はこちら

ソシャゲのガチャを擁護する

まずは以下の記事を読んでほしい。結論から言うと「ガチャは賭博だ、規制が必要だ」という記事であり、その理由がつらつらと書いてある。私も概ね同意する。

togetter.com

ただ、私はカードゲーム、特に遊戯王のようなトレーディングカードゲーム(以下、TGC)にはやはりランダム性が必要だと思う。おそらくソーシャルゲームにも同じ理由でランダム性は必要だと思う。その理由をこの記事では述べる。

飽きが発生しにくいようにする

そもそも、ゲームにおけるランダム性というのは基本的にプレイ内容の多様性を実現するための装置だ。例えば、1パック10枚で販売されるTGCであれば、3パック(30枚)買ったA君と同様のB君では持っているカードに違いが出る。運良く１枚もかぶらなければ、２人併せて60種類のカードになるだろう。 そこでA君とB君が対戦をする。そうすれば、お互い持っているカードが違うので当然全く違う戦い方をするようになる。この、『一人ひとりが違う戦い方をすることを強制される』というのがTGCの面白いところだ。飽きが発生しにくいようになる。色んな人と対戦すれば、ずっと楽しいし、もし世界に２人しかいなくてもカードの交換などをすれば長く楽しめるだろう。

組み合わせを見つける

次に、カードを組み合わせる楽しさがある。カードには単純な優劣があるわけではなく、いろんな種類が存在する。攻撃力は低いがコストが低いカードや、特定の属性にだけ機能が発動するカードなどだ。であれば、１枚では弱いが他のカードと組み合わせることで強力な効果を発揮することもある。そういった組み合わせを探すのもカードゲームの良さであり、各々のプレイヤーが違うカードを持っていた方がそういった組み合わせを発見する機会が増える。（他プレイヤーと交流するきっかけにもなる）

カードを交換する

次に、カードを交換する楽しさがある。自分のカードと相手のカードで強力な組み合わせを作れるならそこでカードを交換することになるだろう。そういった交流もTCGの醍醐味である。だからこそ トレーディング なのだ。 突っ込まれると思うので書いておくと、殆どのソーシャルゲームではアイテムのトレードは禁止されている。これはリアルマネートレードに関連する問題によって運営としてそうせざるを得なくなったのだろうと邪推している。

まとめ

まとめると、カードゲームには入手するカードをランダムにした方がよい理由はちゃんとある。私は現在のガチャを巡る状況は、運営が想定するよりもプレイヤーが愚かであったことに起因しており、そこから『儲かる』という絶対的な正しさから各ゲームメーカーが便乗しはじめたと思っている。最後に自分のツイートを貼っておく。

何度でもいうけどガチャのあるゲームというのは、ガチャで出てきたアイテムに合わせてデッキを組んだり戦い方を変えるのを楽しむゲームであって、特定のアイテムを求めてガチャを回すのは単に遊び方を間違えてると言わざるをえない。

— kazasiki (@kazasiki) 2017年12月8日

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