嫉妬と向き合う

最近「嫉妬なんかダサい、自分を高める努力をしろ」的な言説をよく見ます。個人的には大筋賛成なのですが、モヤっとすることもあるのでもう少し細かく言語化しようと思いました。

まず、先ほどの主張はざっくりすぎるので、以下の3つに分解しました。

  1. 嫉妬感情は醜い

  2. 嫉妬で他人の足を引っ張ってもお前の人生は豊かにならない

  3. そういうのを止めて自分を高める努力をすべき

嫉妬感情は醜い

自分の考え:そうでもない。

感情そのものを否定する考えは自分にはないです。なくすことも難しいんじゃないかなとも。感情が出てくるのはしょうがないですが、その後の行動をどうするかの方が大事だと思います。

嫉妬で他人の足を引っ張ってもお前の人生は豊かにならない

自分の考え:決めつけはよくないと思います。

相対評価を気にする人の場合、自分より上にいる人を叩き落せば、幸せになると思います。他のパターンでいうと、正義感を持って見知らぬ人をぶっ叩くと幸せになると聞いたことがあります。

あまり表に出しませんが、僕も他人の不幸話は嫌いではありません。とはいえ、周りにそこまでしたい人もいないし、よく知らない人を叩くのは悪いことだと思っているので上記のような行動を起こしていません。

そういうのを止めて自分を高める努力をすべき

自分の考え:上から目線が気に食わないが、内容は同意

自分もそう思う主張なので特に追加したいコメントはありません。

まとめ

そういうわけで、冒頭にある主張をして来る人にモヤッとした場合は、「この人は簡単そうに言っているけど実は嫉妬感情に打ち勝って今があるのかもしれない」と思うことにしました*1

それはそれとして、他人の足を引っ張って喜ぶ人は普通に悪人なのであまりそういった人に関わらないような人生にしたいです。

*1:レアケースでそういった感情が本当にない変人

『Java本格入門』で、Javaの知見を体系的に濃縮する

Javaのプログラムを書いているとき、「これはベストな書き方なのか?」という疑問は常にあると思います。ネットで調べる、レビューを受けるといった、確認方法はいくつかあると思いますが、その一つが本書になると思います。

Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

表紙の情報量が非常に多いのが特徴です。

対象読者層

「はじめに」に書いてあるのでほぼ合っていると思います。

オススメな人

  • Javaをある程度お仕事で書いてきた

  • 体系的に学びなおしたい

お仕事で書いてきたというのは、実際に稼働するコードを書いた。また、他人の書いたコードを読んだり直したりしたことがある、という意味です。

向かない人

プログラミング経験がほとんどない人

特徴

トピックは多岐にわたりますが、全般的にめちゃくちゃ絞り込んであります。「本格入門」であって入門書ではないので、ある程度文法を分かっている前提で進みます。

また、筆者のこれまでの経験を生かして、「結局どうすればいいか」が書いてあります。

例えば、インタフェースのデフォルト実装をとりあげます。

抽象クラスとどのように使い分けるのかという疑問について、「インタフェースのデフォルト実装は基本的に使わなくてよい」と簡潔に答えています。

理由としては、

デフォルト実装は、Javaの「過去のバージョンとの互換性*1」のために生まれた

という、Javaの歴史を感じるものになっています。納得感のある説明になっていると思います。

デザインパターン

GoFデザインパターンは23種類もあって身に着けるのが大変ですが、本書では9つに絞って紹介しています。

結城『デザインパターン入門』に比べると、書中ですべてのコードを載せているわけではありませんが、実際に使いそうな例になっています。

Abstract Factoryパターンでの呼び出し側のコードは以下の通りです。

public class SampleMain {
    public static void main(String... args) {
        String env = "PostgreSQL";
       
        Factory factory = createFactory(env);
        Connection connection = factory.getConnection();
        Configuration configuration = factory.getConfiguration();
    }

    private static Factory createFactory(String env) {
        switch(env) {
            case "PostgreSQL":
                return new PostgreSQLFactory();
            case "MySQL":
                return new MySQLFactory();
            default:
                throw new IllegalArgumentException(env);
        }
    }
}

ただ、個別のパターンの解説の詳しさは、結城本のほうが上回っています。例えば、このパターンでは「工場」を増やすのは簡単です。OracleFactoryは既存の実装に影響を与えずに追加できます。一方、新しい「部品」、HogeSettingsを追加しようとすると、すべての既存の「工場」に影響が出てしまうので大変です。そのような説明が結城本に記載されています。

本書でも記載はありますが、個人的には結城本を読んで初めてちゃんと理解できた印象です。「わかっている人にはこれくらいの説明で十分」という感覚ですかね。

記載のないもの

後半で、デザインパターンや各種ライブラリの説明がありますが、基本的には各クラス内で、どのように書くべきかという説明が中心になっています。設計的な話はあまりないのかな*2という印象です。

まとめ

ブログタイトルに「濃縮する」と書いた通り、コンパクトに必要な記載を詰め込んでいるのが本書の良いところだと思います。

余談ですが、私は6年くらい前に筆者たちが所属するアクロクエストテクノロジー株式会社に1日インターンに行ったことがあります。当時は1ミリもプログラムを書いたことがなかったはずなのになんで行ったのか全く覚えていませんが、こういった形でまた巡り合うことになるとは、不思議な縁を感じます。

*1:具体的には7と8

*2:一定レベル以上のクラス設計は本書の対象外という記載もある

楽しいリモートワーク

リモートワーク(テレワーク)*1を1週間連続で実施したので体験まとめ記事です。

なお、前提として私は一人暮らしです。

背景

リモートワークを推奨する期間があり、それにのっかりました。

また、その期間では同僚たちが会社からいなくなるので、自分も出勤してもしょうがないかなという雰囲気でした。

事前準備・リモートワーク環境構築

やると決めたら色々必要な準備をこなしました。

各種設定が必要でしたが、申請とかで待たされることは特になく、スムーズに進みました。

最終的にPCを家に持って帰って準備万端です。

やったこと

基本的には家で一人でコーディングしていました。入社して間もないので、分からないことができたらslackのオープンなチャンネルでメンション飛ばして聞いていました。

また、slackでの電話会議もありましたが、特につつがなくできており*2、その点で特に効率の低下を感じることはありませんでした。

これまで「困ったらslackで聞く」ということをしたことがなかったので、今回それが結構有効だと気づけたのが収穫です。

また、洗濯を初めとした家事がはかどりました。

感想

入社したばかりで出来ることが少ない自覚があったので、「仕事が全く進まなくなったらどうしよう…」という懸念がありました。しかし、周りのサポートもあり何とかなりました。

具体的には、次やることを決めるにあたっての的確なサポート、タスクの遂行時に「誰に聞いたらいいか」がハッキリしていたことです。

あまり聞きすぎて邪魔になってはいけないと思いますが、適当なタイミングで聞けていたと思います。

ちなみにタイミングに関しては、相手の状況がまるでわからないので、対面で尋ねるような機を伺う*3ことをせず、素直にメンションを飛ばしていたような気がします。

何より通勤時間がゼロになったので、その分寝る時間が増えたのが良かったです。

今後も頃合いを見てリモートワークをしたいと思います。

*1:違いはないものと思っています。現職ではテレワークと言われていますがリモートワークの方が広まっている印象なのでそうします。

*2:画面共有も問題なし

*3:席に戻ってきたら聞こう、など

レビュー『データは騙る』

読書レビューです。

データは騙る: 改竄・捏造・不正を見抜く統計学

データは騙る: 改竄・捏造・不正を見抜く統計学

邦題のイメージからは、統計学を使って不正を見抜くんや!みたいな印象を持ちますが、実際はデータの間違った使い方を指摘する側面のほうが強いです。

ちなみに原題は『Standard Deviations*1』です。邦題の『データは騙る』の方が少し上回っているかと思います。

最近の懸念

最近、成功者が「成功した人は○○している」と言うたびに「はいはい生存バイアス」と返される流れをよく見る気がします。なんとなく、思考停止の感じが出てきて嫌だなと思ったので、妥当な指摘かどうか確認したく、本書を手に取りました。

読後に冒頭の問いを振り返ると、「まあ妥当な指摘なんじゃないですかね」という結論になりました。

以下、学びになったことを記載します。

最も難解な「自己選択バイアス」

私の言葉で自己選択バイアスを説明すると、Aという選択をした人としなかった人とを比較して何かしらの差異を述べようとしたとき、実際は別の要素がその違いに影響を及ぼしているという誤解のことを指します。

本書中の例を以下に引用します。

「大学を卒業した人間は、退学した者に比べて平均で五四パーセント多く稼いでいる。したがって、卒業証書には経済的な意味がある」ここにも自己選択バイアスが見られる。大学に行くことを選択し、卒業できるように一生懸命に勉強した学生は、途中で大学を辞めた人とはさまざまな面で違ってくるのではないだろうか。

私が、なぜ難解としたかというと、実際に自己選択バイアスを見抜き、その裏側にある真因を指摘するのは難しいと思ったためです。特に、自分にとって違和感のない主張に対してはすんなりと受け入れてしまうためにさらに難しくなると思います。

自己選択バイアスに敏感になれればいいのですが、それが難しい場合にも他者の指摘を受け入れて自分の固定観念を見直せればいいなと思いました。

(参考:自己選択の説明)

自己選択バイアス(じこせんたくばいあす)とは | アンケートQ

平均への回帰

スポーツのような実力に対して、結果がばらつく場合、ある年度でトップの成績を収めた人は、その前後の年度ではそこまで優れた成績でないことが多いとのこと。

この場合、平均への回帰は、「真の実力への収束」といってもいいと思います。

読者の想定レベルが低い?

本書では、時折常識的な指摘すぎてアホかと思ってしまうことがあります。例えば、グラフについての章を取り上げます。

ここでは、「縦軸や横軸の目盛りは省略してはならない」と大真面目に書いていました。

意外とデータに対する世間のリテラシーが上がっているのか、もしくは自分の周囲だけなのか、どちらにしてもだいぶ簡単な内容だなと思いました。

常識の力、厄介さ

本文中で、常識的に考えればおかしいような主張が論文として世に出ていた事例が紹介されています。例えば、「超能力が存在する」「特定のアルファベットから始まる人は早死にする」など。

そして、筆者はそれらの主張のもととなる論文・データがおかしい理由を丁寧に*2説明しています。代表的な理由としては、自分の主張を支持するデータを抜き出したためです。

筆者は、自分の持つ常識を大事にしようと述べています。

一方で、気をつけるべきこととして、今回読んでいて正しかったのは自分の常識ですが、これが間違っていると突きつけられるときがかならず来るということがあります。

そのとき、自らの考えに固執せず、柔軟に変えられるかどうかが大事だと思います。

お役立ちの19章

本書は全19章とボリューム盛りだくさんですが、最後の19章はこれまでの振り返りになっています。自己選択バイアスや、誤ったパターン化など、重要だけど難しい概念を思い出せます。

まとめ

爆発的に増大しているデータや分析に対して、どう判断したらいいかわからなくなっている人にはいいと思います。当レビューで取り上げた以外にも、役立つ概念がたくさんあります。

*1:標準偏差

*2:若干くどいレベル

目標設定、好きなこと、得意なこと、なりたい姿について

今日はふわっとしたことについて考えます。タイトルにある4点です。

目標設定

会社員をやっていると目標設定を課せられることがよくありますが、私はこれが好きではなく、苦手です。

なぜなのか考えてみると、いくつか理由を思いつきました。

  • どれだけの達成可能性があるかわからないまま目標を立てがちだから (目標を立てた段階で、それがどれくらい難しいことなのか判断つかない)

  • 目標に対して、達成したかどうかの判断基準がイマイチだから

    • 計測可能でない
    • 目標に関係ない
  • 評価に関わってくるから

しかし、こうも考えています。これが得意になれば、好きになるのでは?と。

評価についてはそんなに気にしなくていいし、定量的な目標は、うまく考えれば立てられるような気がしています。

好きなこと

自分の好きなことはなんだろう、と考えると、

  • 1日10時間寝ること
  • 散歩すること
  • カフェ読書

と、仕事に関係ないものが並びます。今自分が100億円持っていたら上記のような生活を送ります。

残念ながらそんなお金はないので仕事をしています。

仕事に限定して好きなことを考えると、現段階だとやや曖昧だなと感じています。

そこで、以下の手法をとってよりクリアにしていこうと思います。

  1. 好きなこと(と思われるものも含む)を書き出す。
  2. しばらく色々なことに取り組み、実際に好きだったか記録する。その際、今まで取り組んでいないことにもチャレンジすることと、すぐに諦めずにしばらく続けることを意識する。
  3. 振り返って1.の作業をもう一度やる。以降繰り返し。

2.を補足すると、仕事において成長していくためにはチャレンジして継続していく姿勢が不可欠と思いますが、自分の場合それが結構エネルギーを要するもので、意識的にやっていかないとできないと思っています。

得意なこと

「好きなことより得意なことを仕事にしたほうがいい」という言説を聞きます。

得意なことも、好きなこととほぼ同じ手順で発見できると思っています。

ただ、一つ追加してやっておきたいことがあります。

それは他人の得意な事柄を見つけることです。他人の得意不得意について考えることで、自分のそれについても考えやすくなると思われます。

なりたい姿

仕事に限定すると、「スタンダードなサーバーサイドエンジニア」が今のなんとなくのイメージです。どうすればなれるのかというと、

コードが書ける、アーキテクチャフレームワークが理解できる、設計ができる、チームワークができる、アプリケーションを作るにあたって重要な概念を理解している*1、そんなところでしょうか。

まとめ

これら4つについて、定期的に考えていくと良さそうです。無から構築するわけではなく、最近あった出来事について、自分は何をしたか、何を思ったかを記録してそこから考えると、より正しい答えが見えてくるような気がします。

*1:パフォーマンス、セキュリティ、ネットワークとか

Kotlin公式エクササイズKoansやってみた

仕事でKotlinを勉強する必要が生じたので、色々教材を探してみました。

とりあえず公式を抑えようということで、以下のKotlin Koansを試してみました。

play.kotlinlang.org

特色として、Web上で完結することがあります。

IntelliJ IDEA上でも実施できるらしいですが、自分はスムーズに行かなかったので諦めました。

対象は以下で述べられているように、Javaの経験者を想定しています。

Kotlin Koans is one of the most popular and most effective ways to get into Kotlin for people who already know Java.

いくつか学んだこと

  • Smart Castの基本的な活用法について
    • If文等で、その型であることが明らかな場合には、以降はその型であると暗黙的にみなされている。(以下は例)
fun demo(x: Any) {
    if (x is String) {
        print(x.length) // x is automatically cast to String
    }
}
  • Collection操作に関するあれこれ Javaでfilterとかmapを使う際はとりあえずstream()を挟むイメージだったのですが、Kotlinにはそういうのはないです。確かに無いほうが書きやすいような気がします。

使える関数についてはQiita記事で恐縮ですがこれがいいかと。具体例が載っているので分かりやすいです。

Kotlin のコレクション使い方メモ - Qiita

公式だとこれです。

Collection - Kotlin Programming Language

よくわかんないこと

まとめ

意外と難しいですね。というよりそもそもの概念を理解しないと書き方だけ真似しても意味ないような気がします。

Introductionのセクション以降はどのトピックを次にやってもいいでしょう。

ABC130(しゃくとり法)

直近のABC131には不参加でしたが、その前のABC130に参加したので振り返りです。

atcoder.jp

AとBは省略します。

C問題

「長方形を半分に分割する直線は、すべて対角線の交点を通る」ということを知っていたので、楽に実装できました。

https://atcoder.jp/contests/abc130/submissions/5964250

D問題

単純にループを回していると、O(N2)になって間に合わなさそうだと分かりました。

Kが大きい場合と小さい場合について、どちらも計算量が減るように実装してみました。

具体的には、Kが大きい場合には左端はそこまで大きくできないので、それに備えて限界値を算出しました。

さらに、ある範囲でKを上回れば、それより右端が右に行っても条件を満たすので、その時点でループを打ち切って該当個数を算出するようにしました。

以下が実装です。地味にDはコンテストで初ACです*1

https://atcoder.jp/contests/abc130/submissions/5976819

自分は1.9秒というギリギリでクリアしましたが、他の人は0.5秒くらいでクリアしています。

解説等を見ると、しゃくとり法という方法を使うといいことが分かりました。

qiita.com

自分が考えた不完全なアルゴリズムを蹴散らす華麗な手法でした。

しゃくとり法を用いて書き直したのが以下になります。

https://atcoder.jp/contests/abc130/submissions/6107964

無事、所要時間が0.5秒になりました。

まとめ

Dが解けたのでうれしかったです。

  • パフォーマンス:1213相当
  • レーティング:636→733 (+97)

またがんばります。あと、もう少し早く振り返りを書きます。

*1:コンテスト以外では解説読みながら2,3問しか解いたことがない