成功体験を積み重ねていくことは物凄く重要

仕事

目標設定・プロセスの細分化・プロセスの実行・達成

成功体験は以下の要素により構成されます。

  • 目標設定
  • プロセスの細分化
  • プロセスの実行
  • 達成

成功体験はこれらがセットになって初めて生まれるため、例えば漫然と8時間毎日勉強して合格に近い大学を受け合格するのと、志望校を設定して受かるためにプロセスを細分化して勉強して合格してきた人を比べた場合、後者の方が圧倒的に成功体験の質や数も多くなります。

この成功体験が足りないと、すぐ諦めてしまったり、投げ出したりしてしまい、これが更に成功体験を得る機会を奪っていきます。つまりスパイラルに陥るということです。

自信がある状態

自信がある状態とは過去の経験から以下のことを達成できると思っている状態のことです。

  • 達成までのプロセスを明確化出来ている
  • プロセスの途中で多少失敗があってもリカバリー出来る

いずれも成功体験が必要ですが、目標設定と至るまでのプロセスと達成が無いと成功体験にはなりえません。

その為、自信を得るとは、目標設定と目標を実現するためのプロセスを実行し、達成することに他なりません。

目標設定〜達成までのセットをいかに効率的に増やしていくかが重要になります。

競技性が高く、定量評価の出来る分野で期間を設定して、目標設定をする

成功体験を増やすということは、何かしらのゲームにおいてゴールを設定し、そのゴールまでの攻略法を見つけ、達成するということです。

ゲームのゴールは、例えばノーベル賞を受賞する、TOEC900点を取得するなどがあると思いますが、成功体験の少ない人ほど細かい粒度で、

  • 競技性が高く(つまりルールが明確化されている）
  • 定量評価ができ(勝敗やレーティング、スコアなど）
  • 期間を設定出来る(大会に向けて、１年間の間に、など）

もののほうが良いです。

理由は以下のとおりです

  • ルールが明確化されていないものはそれだけゲームが複雑なものが多く、攻略法を考えにくい
  • 定量評価しにくいものは、上達を実感しにくい(例えば絵の上達は定量評価がしにくいため、自分が上達しているかしていないかわからない期間が長いため、モチベーションを維持しにくい)
  • 期間が設定されないと、モチベーションコントロールがしにくい(１年間頑張る前提といつ終わるかわからないという前提で頑張るのとでは、前者のほうがモチベーションをコントロールしやすく、集中し易い）

まとめ

  • 以下の目標〜達成までのセットが重要
    • 目標設定
    • プロセスの細分化
    • プロセスの実行
    • 達成
  • これの質と量をどれだけ積み重ねていくかが即ち自信

Splatoon2練習メニュー

splatoon2

平日

  1. スシコラ動画を観る(10分)
    • 自分ならどう動くか、ということを意識して観る
    • 漫然と考えなしに観てはならない
    • 動画を観つつ、状況を声で言ったり、コメントを書くのが効果的
  2. 試し打ちでのメイン練習
    • メインはとにかく初弾を当てる
    • 外れた場合は「ダメ」など声を発する(体験に対して、成功/失敗のラベル付けを行うために必要)
  3. 試し打ちでのサブエイム練習 (5分)
    • サブは狙った位置に落とすことを常に意識して、反射なども時折考えて投げる
    • 外れた場合は「ダメ」など声を発する(体験に対して、成功/失敗のラベル付けを行うために必要)
  4. 試し打ちでのジェッパ練習(10分)
    • スペシャルアップガン積み
    • 一発撃ったら、塗りリセットしてを繰り返す
    • とにかく初段当てることを意識する
  5. スシコラ動画を観る(10分)
    • 自分ならどう動くか、ということを意識して観る
    • 漫然と考えなしに観てはならない
  6. 散歩(5分)
    • 頭のなかで敵を動かしつつ、撃つ
  7. イメージトレーニング(10分)
    • コントローラーだけ持って、他は何も水に頭のなかでゲーム
  8. ナワバリ(1時間)
    • 相手のブキを観て、以下を確認
      • 相手のスペシャル
      • 自分と相手の塗り総量の比較
    • かならず、現在の状況、反省点を口に出してプレイする
      • 漫然とプレイすることを防止するため
      • PDCAを回すためのログとするため
  9. 録画確認(10分)
    • ウィークポイントをメモしておく

スプラシューターコラボでのスクリュースロッシャー対策

splatoon2

スクリュースロッシャー対策

スシコラで対スクリュースロッシャー戦でのデスが多いので、自分なりに考えた対策方法について述べます

サイドまたはバックから狙う

正面からスクリュースロッシャーと打ち合うとかなりの確率でデスします。

キル速自体はスシコラの方が強く、射程もほんの少しだけスシコラの方が長いのですが、 スシコラ側のエイムがブレると、スクスロの方がダメージ範囲が大きいため、デスする確率が高くなってしまいます。

サイド・バックから狙うことで、キル速・塗り性能の差、相手がこちらに反応するまでの遅延時間によって、こちらが一方的にキルを取りやすくなります。

サイド・バックから狙う際に、相手が翻して返り討ちに合うことがたまにあります。 もし相手がこちらの攻撃に気が付いて相手が回避行動と反撃をしてきたら、潜伏しつつ相手のミスショットを誘ってから攻撃することで、デスが少なくなります。

塗り勝って距離を詰める

中距離では撃ち負ける確率が高いですが、近距離ではスシコラのほうがキル速が早く有利です。

塗り性能もスシコラのほうが良いため、塗り勝ってから距離を詰めてのメイン射撃で、キル出来る確率が高くなります。

スペシャル使用中を狙う

スクリュースロッシャーのスペシャルはハイパープレッサーですが、敵陣に切り込んで使うメインと後方で狙撃するタイプのスペシャルとでは相性はいまいちよくありません。

ハイパープレッサーはメインブキへの切替えも出来ないため、スペシャル発動中のスクリュースロッシャーは格好の的です。

相手もそれを見越してあまり敵前でハイパプレッサーを撃つことはないと思いますが、もし偶然見かけた際は忘れずキルを取っておきましょう。

背の低い障害物の後ろに対比しない(相手がこちらの位置をある程度把握している場合 )

背の低い障害物の後ろは一方的にスクスロが有利となるので、スクスロ射程範囲内で、背の低い障害物の背に隠れない。

まとめ

本来、スシコラはスクスロに対して一方的に弱いということは無いのですが、個人的に対スクスロ戦でデスが多くなることが多かったので、対策方法について考えてみました。

もっと良い対策方法などあれば募集中ですので、お気軽にコメント下さい。

tmux/screen上でのnvimのescapeレスポンスを早くする

プログラミング

概要

tmux/screen 上で nvim を使用した際に、 escape/Ctrl-[ 入力に対するレスポンスが遅いため、これを解決する方法について記述します。

tmux/screen 上で nvim のescapeレスポンスを早くする

$HOME/.tmux.conf 上で 以下の設定を追記する

set -s escape-time 10

screen の場合は、以下の設定を $HOME/.screenrc に追記します。

maptimeout 10

vimなどで、 escape-time を 0 にしている例をよくみかけますが、nvimの場合0だとうまくいかず、 10程度のdelayを必要とします。

なぜこのような挙動になるのか

tmuxではEscape入力があった際に、500msec のディレイの後にバックグラウンドのターミナルにコマンドを送信している。

上記の設定ではこのディレイを極端に早くすることで、キー入力の直後にバックグラウンドのターミナルにEscapeコマンドを送信している。

参考文献

github.com

エンジニアが意識するべきこと

プログラミング 仕事

エンジニアが意識するべきこと

エンジニアが意識するべきことを列挙する

楽しむ

純粋に楽しめる分野について目標設定を行う。

苦行にならないように、飽きが来ないように問題を設定する。

不安にならない

技術領域は多岐にわたるため、自分が知らない技術があるからといって、不安になって学習計画を変えたりしない。

必要な知識なら、その後の学習計画に加えればよいだけだし、不必要な知識なら学習しなくても良い。

仮に基礎的なコンピュータサイエンスの知識と現在流行りの技術があり、どちらかを選択する場合には、基礎的な知識の学習を優先する。

執筆活動やコミュニティ活動を重要視しない

記事の執筆やコミュニティ活動それ自体はエンジニアリングとは関係がない。

あくまでエンジニアリングの副次的なものとして考え、それが目的にならないようにする。

設計してコードを書く

設計をせずに行き当たりばったりのコードを書いていても、コーディングスピードや設計能力は向上しない。

思考とコーディングは個別に考え、同時には行わない。

テストを書く

ユニットテストがない状態では、デバッグのコストはプログラムの規模が大きくなるほど指数的に大きくなる。

ユニットテストを書くことで、デバッグのコストの増大を線形に抑えることが出来る。

デバッガーを使う

使いやすいデバッギングツールを使うことで、デバッグの速度を早くすることが出来る。

ウォーニングやエラー出力について敏感になる

ちゃんとウォーニングやエラー出力を読んでから行動する。 読まないまま行動しない。

ツールに頼りすぎない

上記とは逆説的であるが、ツールに頼りすぎない。 すぐに解決できない問題は、あえてツールに頼らず、ロジックを追うことも重要。

一次ドキュメントを正確に参照する

何か調査事項があった場合に、一次ソースを明確にする。

出来ればQiitaやStack Overflowは使わないほうが良いが、使う場合も、一次ソースまで追った上で参照する

よく読んでよく書く

ドキュメントを読む時間と書く時間がどちらかに偏りすぎないようにする。

Rustでファイルの変更を検知して自動でコンパイルやテストを行う

プログラミング Rust

はじめに

Rust では GitHub - passcod/cargo-watch: 🔭🚢 Watches over your Cargo project's source. を使うことで、簡単にファイルの変更を検知して、自動でコンパイルやテストを実行することが出来ます

インストール

Macの場合、以下のコマンドで完了します

brew install rust
cargo install cargo-watch

ビルド

cargo watch

ビルド & テスト

cargo watch -x test

Scala 2.12.3 がリリース

scala プログラミング

Scala 2.12.3

Release Scala 2.12.3 · scala/scala · GitHub

Scala 2.12.3 がリリースされました。

変更点

  • コンパイル速度の高速化
  • インラインクラスを制御するコンパイル最適化 オプション -opt:l:inline の追加
    • それに伴い、 -opt:l:classpath と -opt:l:project が非推奨になりました
  • https://github.com/milessabin/shapeless:title での Implicit マクロの改善
    • これでメソッドのコード補完がより効きやすくなる

ワーキングメモリ容量の少ない人が採るべき学習戦略

仕事

はじめに

私はワーキングメモリ容量が少ない自覚を持っていますが、だからといって学習を怠るわけにはいきません。

ワーキングメモリ容量が少ないということは学習においてハンデとなることが多いですが、だからこそ学習戦略が重要となります。

ここではワーキングメモリの容量が少ない人が採るべき学習戦略について、コンピュータをモデルとして考えていきます。

ワーキングメモリ容量が少ない人が採るべき学習戦略

まずはワーキングメモリ容量が少ないことをコンピュータに置き換えてモデル化します（そもそも、ワーキングメモリという言葉自体、コンピュータから借用してきた言葉と聞いています)。

ワーキングメモリ容量が少ないということは、コンピュータで言うとメインメモリ容量が少ないことに相当します。

他のモデル候補として、CPUの一次キャッシュ・２次キャッシュなどもあるとは思いますが、一旦メインメモリとしてモデル化します。

ワーキングメモリ容量が少ない人でも、長期記憶は問題ないことが多いと言われていますが、このことからもワーキングメモリと長期記憶はモデルとして独立していると考えられます。

長期記憶は以下の特徴を備えています。

  • 記録に反復や時間が必要
  • 長期間使っていないと記憶が飛ぶ

以上のことから、長期記憶はネットワーク越しのSSDのデータベースとします。

また長期記憶から情報を取り出す作業も、よく使う情報については早く取り出され、よく使わない情報については思い出すのに時間がかかることから、長期記憶から記憶を取り出す際は、長期記憶専用のキャッシュ領域に情報がキャッシュされるとします。これは キャッシュサーバーとモデル化します。

これらをまとめると、以下のようになります。

  • 長期記憶 → ネットワーク越しのSSD
  • ワーキングメモリ → 実行中アプリケーションのメインメモリ
  • 長期記憶キャッシュ → キャッシュサーバー

以上の構成でパフォーマンスを発揮するためには、以下の点が重要となります。

  • こまめにメインメモリの内容を整理して、DBに挿入
  • キャッシュサーバのウォーミング
  • メモリリークを起こさない

これはそれぞれ以下のように実生活に置き換えることが出来ます

  • こまめに情報をノートなどにまとめる
    • これは、実生活に当てはめると、メモをこまめに採る、メモをこまめにまとめることに相当します。
  • まとめた情報を何回も反復する
    • これは実生活で言うと、付箋にメモをしてこまめにチェック、暗唱することなどに相当します。情報を暗誦するのも効果的です。
    • 長期記憶に保存するためには、時間がかかりますが、ワーキングメモリが少ない人にとって出来るだけワーキングメモリを節約することが重要であるため、ちょっとした情報なども出来るだけ長期記憶に保存するコストを払ったほうが良いと思います。
  • 今やっている作業以外のことは考えない
    • ワーキングメモリ容量が少ない人こそありがちなのが、今やっている作業以外のことを色々考えてしまうこと。メモリリークを起こさないように意識しましょう。

まとめ

ワーキングメモリが少ない人が採るべき学習戦略についてまとめてみました。

コンピュータとしてモデル化してまとめてみると、結局ADHDの仕事術やワーキングメモリに関する書籍と同じような結論になりました。 それほど、人間とコンピュータはモデルとして近いということでしょう。

JavaScriptのガベージコレクション

javascript プログラミング

JavaScriptのGCアルゴリズム

昔は参照カウント方式でガベージコレクションを行っていたが、参照カウント方式では例えば以下のようなサンプルコードでメモリリークが発生してしまう。

var div;
window.onload = function(){
  div = document.getElementById("myDivElement");
  div.circularReference = div;
  div.lotsOfData = new Array(10000).join("*");
};

この問題を回避するために、最近のJavaScript実装では マーク·アンド·スイープアルゴリズム を用いていることが多い。

マーク・アンドスイープアルゴリズムについては、

Java Memory Managementを読んだ - 真面目に、強く、上品に

でも述べたことがあるが、Javaでも同様のガベージコレクションアルゴリズムが使われている。

参考

https://www.amazon.co.jp/dp/4798134201

メモリ管理 - JavaScript | MDN

Java Memory Managementを読んだ

プログラミング Java

概要

Java memory management | Dynatrace を読んだのでまとめました。

Java Memory Management

How Garbage Collection Really Works

  • ガベージコレクションという言葉から、ゴミ集めをする実装だと思いがちだが実はそうではないよ
  • ガベージコレクタが管理しているのは、GCルートから参照されているオブジェクトで、参照されていないオブジェクトをゴミとみなすということだよ。イメージされるゴミ集めの実装を反対にした感じ。
  • OSでのグローバルな同期が必要ないから、個々のオブジェクトの作成は速いよ
    • JVMが確保したヒープのメモリアレイのオフセット変えるだけだし、次のメモリ確保もオフセットをずらすだけでよいからね
  • JVMは一旦確保したメモリを削除したもしないし、OSから確保したリソースをOSに返したりもしないよ

Garbage-Collection Roots—The Source of All Object Trees

  • JVMにはGarbage-Collection Rootsというものがあるよ
  • 普通のJavaアプリケーションは以下の３つの種類のGCルートがあるよ
    • メインスレッドのローカル変数
    • メインスレッド
    • メインクラスのスタティック変数
  • JNI参照も GCルートの一種としてあるんだけど、JVMはネイティブコードからJNI参照がどのように参照されているかわからないし、ちょっと特殊な形式のGCルートになっているんだよね
    • 詳しくは、Problem Patterns セクションにあるよ

Marking and Sweeping Away Garbage

  • JavaVMのガベージコレクションには、mark-and-sweep algorithm が使われているよ
  • これはどういうアルゴリズムかというと、下記の通りだよ
    1. GCルートから参照されているオブジェクトを巡回して、マークしていく
    2. ヒープにマークされていないオブジェクトがあれば使われていないものとみなされるよ

感想

英語のドキュメントは割りと読む方ですが、読んだ知識をアウトプットしていなかったので、今回試しにやってみました。

他の人に読んでもらうためというよりも、自分の理解を深めるため・記憶として定着させるためという意図のほうが大きいため、あまり気取らない形で、今後も続けていきたいです。

良い人生とは何か

仕事

はじめに

出来るだけポエムを書かないように、普段は不必要な情報を削ぎ落とした文章を書くことを心がけています。

しかし、たまにはポエムっぽいことが書きたくなるもので、今回はちょっとポエムっぽいことを書いてみます。

テーマは「良い人生とは何か」です。

良い人生とは何か

良い人生とは何か、と問うた場合、人によって定義が変わるとは思います。

僕の場合、よい人生とは一言で言うと、「満足な人生」です。

「満足な」という形容詞もいささか抽象的すぎるし、人によって捉え方も違う言葉ではありますが、 自分で自分を「十分頑張った」と評価できることと私は定義しています。

では、十分頑張ったという実感を得るためには何が必要でしょうか。

それは、その時々でベストを尽くす、これに尽きると思うのです。

ベストを尽くすためには、やりたくないことでもやらなければならない時もありますし、一筋縄ではいかないこともあるでしょう。

ベストを尽くさない行動はより楽な行動ではありますが、十分頑張ったという自己評価を得ることが出来ません。

ここで勘違いしてほしくないのは、例えばしんどいから体を休める、鬱になったので休職をするといったことがベストを尽くさないということではないということです。

ベストを尽くすとは言葉の通り、その時々で目標を設定し、目標達成のために最適な行動を取り続けるということです。

例えばこれ以上働くと自分が鬱になってしまう、という自体になった人間が取るべき「十分頑張った」行動は、まず休息を取ることです。

ベストを尽くす、といった場合に目先の目標にとらわれてしまい、大局的な目標の達成から離れてしまうということはよくあることだと思います。

自分のリソースを適切に配分し、目標達成のためにどうやって行動するか、それを考え続ける必要があります。

ただそれさえ出来れば本人が良くない人生を送ってしまったと思うところは無く、あるのは「結果はベストを尽くしたけど、ダメだった。ただ悔いはない」という満足感だけでしょう。

実は私は今まであまり「十分頑張った」という実感を得たことは多くないのですが、そもそもの話として「十分頑張った」という実感を得るのは相当なハードルなのかもしれません。

何かしら障害がある人間は特にハードルが高く、「周りが普通に飛び越えている障害をなぜ私は飛び越えることが出来ないのだろう」という自意識を持ちがちで、それこそがハードルを押し上げています。

ただ、そういうハードルがあっても、目標達成を目指し続ける、それこそが人生における本質的な価値なのではないか、最近私はそう思います。

ちなみにですが、本人がベストを尽くしたと実感しているけど全く成果が伴っていない、という人を私はあまり見たことがなく、 なんだかんだベストを尽くすということは成果に直結するし、基本的に例外はないのではないかと考えています。

今後も私の人生で色々な困難が待ち受けているとは思いますが、その時々で「十分頑張った」行動をし続けることを意識していこうと思います。

「プログラマのためのDocker教科書」を読んだ

プログラミング

概要

プログラマのためのDocker教科書」を読んだため、章毎の感想とまとめについて記述する。

対象読者

導入編でインフラ・ミドルウェアの基礎的な知識について解説があるため、非プラグラマでも基本的なUNIXコマンドが使用できるならば読み進めていける。

導入編

インフラ・ミドルウエアの基礎知識、コンテナ仮想化技術とDockerについての解説が主だった内容。

前半について、既にソフトウェアエンジニア・インフラエンジニアであるならば、この辺りの内容は既に把握していることが多いと思われるので、場合によっては飛ばして良いと思う。

ちなみに私は確認のために一応読んだが、忘れているところもあったので、読んでよかったように思う。

後半はコンテナ仮想化技術とDockerについて。

Dockerの概要についてわかりやすくまとめられている。

とりあえず、VirtualBoxなどのホスト型仮想化、XenServerなどのハイパーバイザー型仮想化はOS以上のレイヤーについて仮想化を行うのに対して、Dockerの仮想化はKernel以上のレイヤーについての仮想化を行う、ということさえ覚えておけば問題がない。

基本編

Dockerのコマンドの解説が中心。

分かり易いがこの辺りはDockerのチュートリアルのほうが、陳腐化しないという点で良いかもしれない。

Dockerを使いこなす上で結構大変なのが、コマンドの階層が深い・コマンドが多いことにより、操作に慣れるまで時間がかかるということ。

コマンド操作をぱっと出来るようにしておくためにも、helpや公式サイトなど、自分が参照し易いドキュメントを用意しておくのが重要であると感じた。

応用編

Docker Composeを使ったリソース管理や、マルチホスト環境でのDocker運用、クラウドでの適用方法など、より実践的な内容が記述されている。

ただしDockerという進化の早いミドルウェアの性質上、ドキュメントも陳腐化しやすいことは留意しておく必要がある。

まとめ

進化の早いDockerではあるが、ここまで体系立ててDockerの解説をしている書籍は珍しいのではないかと思う。

この本でさっとDockerの内容を把握して、以降は公式ドキュメントを追っていくのがベターであると感じた。

プログラマのためのDocker教科書 インフラの基礎知識＆コードによる環境構築の自動化

プログラマのためのDocker教科書 インフラの基礎知識＆コードによる環境構築の自動化

「自衛隊メンタル教官が教える心の疲れを取る技術」を読んだ

仕事

概要

「自衛隊メンタル教官が教える心の疲れを取る技術」を読んだため、章ごとの感想とまとめについて記述する。

ムリを無くす

ムリの段階には三段階あり、段階が進む毎に心身への負担は大きくなり回復しにくくなる。

そのため出来るだけ初期段階で休息を取ることが、ムリを無くすことに不可欠である。

以上の筆者の主張は当然ではあるが、非常に納得のいくものであった。

ムリをすると休息をしなければならないという当然のことさえ、意識を向けることが難しくなってくる。

常に自分が疲れているかどうか、疲れているならどの段階であるか、ということを常に意識することが重要である。

ムダを無くす

現代人は本質的な生命の危機に脅かされころが少なくなり、対人関係など生命の危機には直接関係ないところで感情疲労をする機会が多くなった。

またインターネットやそれに付随するSNSの発展で個人の受け取る情報が過多になり、必要以上に感情の無駄遣いをする機会が増えたというのが筆者の主張。

この主張に対しても大いに同調できる。

そもそも情報の取捨選択が難しい場合には、SNSを断つなども効果的であるように思う。

ムラを無くす

ムラが発生する主要因は以下の２つというのが筆者の主張。

  • 過去の失敗経験
  • エネルギー不足

この章で説明のあった、「満足7:不満3」での現状評価は是非試してみたい。

これはどういうものかというと、あるタームごとの自己評価を必ず「満足7:不満3」の割合にするというものだ。

もし失敗続きで不満の割合が大きいときは、本当に些細なことでも「満足」の項目に入れることで、「満足7:不満3」にする。

この割合にもちゃんとした理由があり、満足が大きすぎると改善するモチベーションが減退し、逆に満足が少なすぎると自信が喪失してしまう。

自分に自信をもちつつ改善活動も出来るちょうどよい比率が「満足7:不満3」というわけだ。

そしてこの評価を続けることで、過去の失敗経験も記憶から相対的に少なくなり、自信が定着し、ムラが減る。

このロジックは大変素晴らしいと感じたため、個人の習慣としていきたい。

まとめ

心の疲れを取る技術とはすなわち以下のことを習慣づけるということである。

  • ムリを無くす
  • ムダを無くす
  • ムラを無くす

精神論には頼らずにシステムでどのように心の疲れを取るかということが実践的な内容で記述されており、納得の出来る内容だった。