Gitの認証がうまくいかなくなった時の対処法

Macを使っていてGitのリポジトリへpushしようとしたら認証エラーが発生しました。
その対処方法のメモです。

remote: HTTP Basic: Access denied
remote: You have 2FA enabled, please use a personal access token for Git over HTTP.
fatal: Authentication failed for 'https://example.com/repo/sample.git/'

パスワードも合っているのに何故…？と思っていたけど、Mac OSX キーチェーンに保存されている認証情報が変な状態になっていることが原因でした。

Gitの設定情報を確認すると、デフォルトで credential.helper が登録されていました。

$ git config --list
credential.helper=osxkeychain
...

GitHubのドキュメントを見ると、以下の条件があるとのこと。確かに当てはまる。

• osxkeychain 認証情報ヘルパーを利用するには、Git 1.7.10 以降が必要です。
• Homebrew を使って Git をインストールした場合、osxkeychain helper はインストール済みです。
• Mac OS X 10.7 以降を実行しており、Apple の Xcode コマンドラインツールで Git をインストールした場合、osxkeychain helper は インストールした Git に含まれています。

Git に GitHub の認証情報をキャッシュする - GitHub Docs

私は特定のリポジトリでこのcredential.helper を上書きしており、そこの設定が osxkeychain に保存されていることで問題が発生していたようでした。

$ git config --list
...
credential.usehttppath=true
credential.helper=!aws codecommit credential-helper $@ 
...

解決方法

解決方法としては、キーチェーンに保存されている情報を削除すれば認証情報が更新されてアクセス可能になりました。
参考 : OSX キーチェーンから認証情報を更新する - GitHub Docs

コマンドラインで削除する方法もありますが、今回はGUIの操作を紹介します。（どちらの方法も上記のGitHubドキュメント見ればわかります。）

まずはキーチェーンアクセスを開きます。Spotlight検索からすぐに開きます。

右上の検索ボックスで git と検索すると対象のデータが表示されます。

右クリックして「情報を見る」を選択します。

「アクセス制御」をクリックし、対象の git-credential-osxkeychain を選択したら下の「ー」をクリックすれば削除が完了します。

これで再びGitリポジトリへアクセスしたら事象が解決しました。👏

特定のディレクトリ配下のリポジトリに別のGitの設定を適用する

Gitの設定（コミット時に利用する user.name や user.email など）は基本的に git config コマンドを利用して設定をしていきます。
git config にはいくつかのオプションがあり、基本的には --global を使ってPCのユーザーとしての設定をし、個別に設定を変更したいリポジトリについては --local を利用して設定してきました。
しかし、この方法だと毎回設定の手間がかかったり、設定するのを忘れてしまって私用のユーザー名やメールアドレスで会社のリポジトリにコミットしてしまったりと、課題がでてきます。

git config --global コマンドを実行すると ~/.gitconfig に設定が保存されていきますが、Gitにはディレクトリ配下に対して別の config ファイルを適用できます。
今回はそれの備忘MEMOです。

例として、以下のようなディレクトリ構成とします。ここでは ~/dev/project ディレクトリに会社のユーザーを利用したいと想定します。

~/dev
├── study
├── github
└── project
           ├── projectA
           ├── projectB
           └── projectC

まず、 ~/.gitconfig に以下のような設定を追加します。

[user]
    name = syobochim
    email = syobochim@email.com
+ [includeIf "gitdir:~/dev/project/"]
+         path = ~/.gitconfig-project

includeIf に、設定を変更したいディレクトリのパスを書き、 path に適用させたい設定ファイルのパスを書きます。
~/.gitconfig-project は会社用の設定として以下のように記載をします。
ここではuser設定のみ追加していますが、 認証情報の保存をする credential.helper などを追記する場合も多いかと思います。

[user]
    name = syobochim-office
    email = syobochim-office@email.com

そうすると、 ~/dev/project ディレクトリ配下でgitリポジトリを作成したときに、~/.gitconfig-project の設定が適用されます。
git config --list コマンドにて設定を確認してみると、 ~/dev/project ディレクトリ配下のGitリポジトリでは以下のように出力されました。
user.name=syobochim-office と user.email=syobochim-office@email.com にて設定が反映されているのがわかります。

$ git config --list
credential.helper=osxkeychain
user.name=syobochim
user.email=syobochim@email.com
includeif.gitdir:~/dev/project/.path=~/.gitconfig-project
user.name=syobochim-office
user.email=syobochim-office@email.com
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.precomposeunicode=true

実際にコミットしてみても、会社用のユーザーでコミットされていますね。

$ git log
commit 634ab266a2beee348c1de123569f29c78aff7fde
Author: syobochim-office <syobochim-office@email.com>
Date:   Tue Aug 25 09:09:44 2020 +0900

    test commit

しかし、~/dev/project ディレクトリ以外のGitリポジトリを作成して設定やコミットを実行しても、以下の通り設定は反映されませんでした。

$ git config --list
credential.helper=osxkeychain
user.name=syobochim
user.email=syobochim@email.com
includeif.gitdir:~/dev/project/.path=~/.gitconfig-project
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.precomposeunicode=true

$ git log
commit a7bbb75e5fabd46afb362401d1ab8ace7393f2ae
Author: syobochim <syobochim@email.com>
Date:   Tue Aug 25 09:13:06 2020 +0900

    test commit

ということで、 [includeIf "gitdir:<<path>>"] を ~/.gitconfig に記載すれば、特定のディレクトリ配下のGit設定を一括で変更できました。

参考
Git - git-config Documentation

Chrome拡張でユーザーからの入力値を利用する

Chrome拡張作りにハマっています。
syobochim.hatenablog.com

Chrome拡張でユーザーからのInputを利用したくなりました。そこで調べたらオプションページを作って入力させられるとのことでした。
オプションページはmanifest.jsonにoptions_uiのプロパティを設定して作っていきます。
"open_in_tab": falseで、オプションページをタブではなくポップアップで作成できる。調べてみると、ポップアップが推奨っぽい。
設定した値はストレージに保存したかったので、permissionsにstorageも追加しました。

{
...
  "permissions": [
    "activeTab",
    "storage"
  ],
  "options_ui": {
    "page": "option/options.html",
    "open_in_tab": false
  }
}

最初はoptionsページもVue.jsで作ろうと思っていましたが、Chrome拡張のセキュリティポリシーでInline JavaScriptが利用できないらしく、v-modelや@clickなどを書いていたら警告が出てしまいました。
Content Security Policy (CSP) - Google Chrome

Vue.jsを利用する場合はこういうリポジトリもあったけど、なんとなくbuildしたくなかったので、結果としてプレーンなJavaScriptでファイルを作成することにしました。
GitHub - Kocal/vue-web-extension: 🛠️ A boilerplate for quickly starting a web extension with Vue, webpack 4, ESLint and more!

optionページはこんな感じ。認証情報をユーザーの入力から取得する。
Chrome拡張のセキュリティポリシーによって、scriptはファイルとして外出ししなければならない。

<!DOCTYPE html>
<html lang="ja">

<head>
    <meta charset="UTF-8">
    <title>Resources List - Options</title>
</head>

<body>
    api key : <input type="text" id="api_key"><br />
    secret key : <input type="text" id="secret_key"><br />
    <button id="save">Save</button>
    <div id="status"></div>
    <script src="options.js"></script>
</body>
</html>

options.jsの中はこんな感じ。Inilne JavaScriptが使えないからHTMLタグの方にonclickを設定することもできず、addEventListenerを利用している。
データの保存はlocalとsyncがある。どちらが安全なのかは今後調べる予定。

function save_options() {
    chrome.storage.sync.set({
        api_key: document.getElementById('api_key').value,
        secret_key: document.getElementById('secret_key').value
    }, function () {
        var status = document.getElementById('status');
        status.textContent = 'Saved.';
        setTimeout(function () {
            status.textContent = '';
        }, 750);
    })
}

function restore_options() {
    chrome.storage.sync.get({
        api_key: 'input here',
        secret_key: 'input here'

    }, function (items) {
        document.getElementById('api_key').value = items.api_key;
        document.getElementById('secret_key').value = items.secret_key;
    });
}

document.addEventListener('DOMContentLoaded', restore_options);
document.getElementById('save').addEventListener('click', save_options);

設定した値は、メインの方のJavaScriptにてこのように利用可能。設定値を別のプロパティに詰め替えてfunctionの外で利用しようと思っていたけれど、なぜかundefinedになってしまったので制限されているのかな。
なので、メインの方の処理はこのfunctionの中に移動した。

    chrome.storage.sync.get(["api_key", "secret_key"], function (input) {
        input.api_key;
        input.secret_key;
    });

はじめてのGoogle Chrome拡張（とVue.js）

社内サイトのちょっと手の届かないところを触りたくてGoogle Chrome拡張をはじめて作ってみたので、備忘メモ。
ツール自体はかなりサクッと作れました。はじめてのChrome拡張とはじめてのVue.jsだったけど、雑務しつつも2時間くらいで完成できました。
Selectボックスの中の要素を取ってきて、インクリメンタルサーチして、選択したらその値をSelectボックスに設定するという、それだけのツール。

構成ファイル

作ったファイルとフォルダ構成はこんな感じ。
manifest.jsonで読み込むJSファイル（vue.jsとmain.js）を指定しています。

.
├── README.md
└── src
    ├── js
    │   ├── main.js
    │   └── vue.js
    └── manifest.json

{
  "manifest_version": 2,
  "name": "tool name",
  "version": "0.0.1",
  "run_at": "document_end",
  "content_scripts": [
    {
      "matches": [
        "https://example.com/roles/*",
        "https://example.com/users/*"
      ],
      "js": [
        "js/vue.js",
        "js/main.js"
      ]
    }
  ],
  "permissions": [
    "activeTab"
  ]
}

Vue.jsはcurlコマンドで格納。これでVue.jsが使える。

$ curl https://cdn.jsdelivr.net/npm/vue/dist/vue.js -o src/js/vue.js

めっちゃ雑なコード。かなりサクッと動かせてよかった。あと、わざわざ別でhtmlファイルを作らなくても画面にフォームなどをお手軽に挿入できて、Chrome拡張のためのVue.jsかと錯覚した。
画面が動的に読み込まれるので、最初に8秒待ったりしている。
拡張を挿入する画面側がjQueryでchangeイベントからHTTPリクエスト投げたりしているんだけど、Elementのvalue変えただけではchangeイベントが発火してくれなかったのでdispatchEvent(new Event("change"));で無理矢理発火させたりしてる。
拡張を更新して試さないとエラー出ないとか辛い…。コンパイルしたい…。

(function () {
    'use strict';
    setTimeout(
        function () {
            var comboboxList = document.querySelectorAll(".combobox")
            var index = 0;

            comboboxList.forEach(
                function (combobox) {
                    combobox.insertAdjacentHTML(
                        "beforebegin",
                        `
                        <style>
                        .selecting-item:hover {
                            background: #e0dfff;
                        }
                        </style>

                        <div id="vue-app-${index}">
                            Policy Filter
                            <input type="text" v-model="policyName">
                            <ul style="list-style-type: none;">
                                <li v-for="item, index in policyList" v-if="policyName && item.text.indexOf(policyName) > -1" 
                                :value="item.value" @click="selectPolicy(item, ${index})" class="selecting-item">
                                    {{ item.text }}
                                </li>
                            </ul>
                        </div>
                        `
                    );

                    var box_options = combobox.options;

                    let vue = new Vue({
                        el: "#vue-app-" + index,
                        data: {
                            policyList: box_options,
                            policyName: ""
                        },
                        methods: {
                            selectPolicy: function (item, index) {
                                combobox.value = item.value;
                                combobox.dispatchEvent(new Event("change"));
                            }
                        }
                    });

                    index++;
                }
            )
        }, 8000)
})();

読み込み方法

公開はしたくなかったので、ローカルのフォルダを読み込ませて動かしました。

1. Google Chromeの「設定」から「拡張機能」をクリック
2. 画面左上の「パッケージ化されていない拡張機能を読み込む」をクリック
3. 「src」フォルダを指定

参考リンク

Chrome 拡張機能のマニフェストファイルの書き方 - Qiita
What are extensions? - Google Chrome

スキーマの変更をデプロイする方法

【翻訳記事】デプロイ戦略の定義のブログでアプリケーションをデプロイする方法のパターンについて書きました。その記事のはてブにコメントをいただいた（ありがとうございます！）のですが、データベースの変更をした際のデプロイ方法についても気になるというコメントがありました。
そこで、翻訳記事の元になったブログとは違いますが、今読んでいる書籍「進化的アーキテクチャ」にデータベースの変更をデプロイするパターンについて記載されていたので、それを抜粋してブログにまとめます。
と言っても、データベースの変更はアプリケーションほどデプロイ種類があるわけではありません。データはあるか、統合点（後ほど説明します）はあるかという観点で3つのパターンにまとめられています。
そして、【翻訳記事】デプロイ戦略の定義で書いたそれぞれのデプロイ戦略をとる場合、どのケースに当てはめると良さそうなのかも考えました。諸々、私の考えが反映されているので、そうではないプレーンな情報を見たい方は書籍の「5章 進化的データ」をご参照ください。

進化的アーキテクチャ ―絶え間ない変化を支える

そもそも、今回紹介するスキーマ変更のパターンは、書籍「データベース・リファクタリング」にて説明されているexpand/contractパターンと呼ばれる一般的に利用されているリファクタリングパターンとのことです。

データベース・リファクタリング

マイクロサービスではどんな単位でサービスを分割すればいいか

最近、マイクロサービスアーキテクチャについて耳にすることが増えていますが、サーバレスのコンテンツと共に語られているケースもあり、「そのサービス単位では分割しすぎなのでは？」とたまに思います。
もちろん、何が正しいかはその現場のコンテキストによるとは思いますが、書籍「マイクロサービスアーキテクチャ」の第3章にサービスの分割についての考え方が記載されており、しっくりくるとても良い内容だったので、それをまとめてみました。
サービス単位を適度に適切に分割することでマイクロサービスの利点をより享受できるようになると思います。まずは、サービス分割のために重要になる概念を説明し、その後、サービス単位をどのように定めるのか記載していきます。

マイクロサービスアーキテクチャ

2つの重要な概念

マイクロサービスで優れたサービスを作っていくためには、「疎結合」と「高凝集性」という2つの概念を意識する必要があります。この二つの概念によって関連する振る舞いは一箇所にまとめ、他のサービスとの境界は通信ができる限り「疎」になるよう適切にサービスを分割していきます。「疎結合」ばかりに注目し、「高凝集性」を蔑ろにすると、必要以上にバラバラになったサービス群ができてしまって変化に対するスピードが遅くなってしまうのではと思います。

疎結合

マイクロサービスでは、あるサービスを変更しても他のサービスに影響や変更がなくデプロイできることが重要になります。
サービスはお互いが疎結合であることが求められます。疎結合のサービスは、連携する他のサービスに関して必要最低限のことだけしか把握しません。

高凝集性

機能を変更する際、その変更をできるだけ早くリリースするために、関連する振る舞いは一緒にまとめておく必要があります。
機能変更のために様々な箇所で修正が必要になると、その分多くのサービスをリリースする必要が出てくるのでリスクや変更にかかる時間が大きくなってしまいます。

サービス分割の考え方

例えば経理部門と倉庫を管理している部門があったときに、それぞれの仕事内容は全く異なります。経理部門に所属する人は倉庫の内部作業の知識は必要ありませんし、逆もまた然りです。
他の部署とのやりとりは、在庫報告書や給与明細など、決まったインターフェースを持ちます。

経理部門は倉庫の詳細な内部作業の知識は必要ありませんが、例えば下の図のように在庫状況を把握して企業評価の帳簿を最新に保つという業務があったときは「在庫品目」の情報が必要になります。
この「在庫品目」が経理部門と倉庫の2つのコンテキスト間の共有モデルになります。ここで注意が必要なのが、他の不要な項目は公開する必要はないということです。内部の情報を共有しないことで、結合が密になるのを防ぎます。

マイクロサービスでは、「倉庫」と「経理部門」のような、それぞれのコンテキストが分割される箇所と一致するようにサービスを分割していきます。（境界づけられたコンテキスト。）初めは粒度の荒いサービスになるでしょう。そして、そのうち、倉庫のサービスの中を、注文、在庫管理、入荷などの機能に分解できることに気づくと思います。
マイクロサービスの境界を検討する際には、まず大きく粒度の荒いコンテキストの観点で考えて、それからさらに分割する利点を考えていきます。時期尚早にサービス分割してしまうと、サービスリリースの際に多くのサービスの変更が必要になってしまい、結果として変更に関するコストが上がるので注意してください。

機能ごとにサービスを分割した方が効果的であると判断した場合は、それぞれのサービスを他の連携先のマイクロサービスから隠し、入れ子の状態にしておくと、結合も密になりにくく、テストもしやすくなるので効果的です。
ただ、サービスを入れ子にしておくのとトップレベルに切り出すか、入れ子にするかの選択に厳格な規則はありません。
判断する上で優先する事項として、組織構造に合わせてサービスを分割した方が管理がしやすいです。「倉庫」の仕組みを1チームで管理している場合は入れ子に、それぞれのサービス単位でチームがある場合はトップレベルに切り出しましょう。

最後に、「入れ子の方がテストもしやすくなる」を少しだけ深堀りします。
サービスを入れ子にしておくと、テストのときに各サービスをスタブ化する必要がなくなります。他のサービスと連携するような粗い粒度のAPIだけをスタブ化しておけば十分になるので、テストが簡単になります。
例えば「在庫管理」のサービスをテストしたい場合、データ連携しているサービスが多いと、以下のようにスタブ化しなければならない範囲が増えてしまいます。

まとめ

もちろん組織やサービスの状況などによって、どのようにサービスを分割するかという選択は様々だと思います。
ただ、「疎結合」ばかりに着目するのではなく、「疎結合」と「高凝集性」という2つの概念をバランスよく考え、組織構造と連携させるようにサービス分割するのが変更速度の高い状態を維持できるマイクロサービスになるのではと思います。
最初に記載しましたが、この内容は書籍「マイクロサービスアーキテクチャ」の第3章により詳細が載っています。マイクロサービスの利点や考慮すべきことが書籍を通して書かれており、とても面白い本なのでオススメです！

マイクロサービスアーキテクチャ

初心者から達人までの道を学ぶ「リファクタリング・ウェットウェア 〜達人プログラマーの思考法と学習法〜」を読んだ

人の学びの過程や効果の高い学習方法が知りたくて「リファクタリング・ウェットウェア」を読みました。
この本では、ドレイファスモデルによって技能の習得レベルを5段階にわけ、その最上位である達人になるための道のりを示してくれています。達人までの道のりは遠い（本によると、最低10年は努力する覚悟が必要！）ですが、明日から始められる一歩から書かれています。人の思考方法など、「なるほど、確かに。」と思うような内容もあり、読んでいて面白かったです。

リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法

📖 目次

• 1章　初心者から達人への道
• 2章　脳の構造
• 3章　Rモードへの転換
• 4章　アタマをデバッグ
• 5章　意識的な学び
• 6章　経験の積み重ね
• 7章　集中のコントロール
• 8章　達人になってから

1.2 ドレイファスモデルの5段階

ドレイファスモデルでは技能ごとに習得レベルを5段階評価に分類しています。ほとんどの人は中級者に位置しています。この本ではこのモデルの達人に向けて進んでいく方法が記載されています。

初心者はルールに基づいて自分たちのパフォーマンスを改善できました。ところが、達人に自らが作ったルールに従わせて見たところ、パフォーマンスは著しく低下してしまいます。初心者はルールに、達人は直感にしたがって行動するのが、パフォーマンスが最も出る方法です。

• 初心者
  • 従うべきルールが与えられれば、ある程度効果的に仕事を遂行できる。
  • うまくやり遂げる能力が自分にあるかどうかを気にしている。指標になる経験がほぼないので、自分の行動の全てに関してうまくいくかの検討がつかない。
• 中級者
  • 決まったルールから少しだけ離れられるようになる。独力で仕事ができるが、問題解決にはまだ手こずる。
  • 全体的な理解はしておらず、理解したいとも思っていない。
• 上級者
  • 独力で問題に対処でき、それまで直面したことのない新しい問題の解決方法を考え出せるようになる。
  • 指導力があり、臨機応変な対応ができる。チームの指導者的役割を担う傾向にある。
• 熟練者
  • 技能を取り巻くさらに大きな概念の枠組みを探索し、理解しようとする。単純化しすぎた情報には苛立ちを覚える。
  • 経験と判断力があり、適切にコンテキストにレシピを当てはめることができる。
  • 他人の経験からも学ぶことができる。ケーススタディや失敗したプロジェクトの噂話を聞いたりするだけで、そこから効果的に学べる。
• 達人
  • 絶えず物事を行うより良い方法を模索している。膨大な経験があり、それを上手に引き出してぴったりの状況で応用できる。
  • 「理由があってそうする」のではなく、「直感」に従って何かをする。直感的に振る舞うので、他のものからは魔法使いのように見える。
  • 全人口の1%〜5%

5.3 プラグマティック投資計画の作成

自分のなりたい目標を決めたら、その目標を達成するための計画を立てていきます。計画を立てるにあたって重要な点は以下の通り。

• 具体的な計画を立てる
  • 時間軸に沿って様々な段階の目的を考えだす
    • 現在（すぐにでもできること）
    • 翌年の目標
    • 5年後の目標
• 多様性を持たせる
  • プログラミング言語や環境、技術、業界、非技術系の分野などをうまく組み合わせる
• 受け身にならず、積極的に投資する
  • 「フィードバック」が重要
  • 常に現在に照らして計画の良し悪しを見極め、進行状況を現実的に評価する
  • 以前は考えなかった新しい要素を追加したり、良い結果の出ていない計画を取りやめにしたりする時期かもと定期的に見直しをする
• 定期的に投資する
  • 最低限の時間を定期的に投資すると決める。

6.3 失敗を活かす

達人になる上で大切なのが経験を積むことです。経験を積むには失敗を恐れず学びに活かす必要がありますが、あるアイデアを探求し、発明し、応用すると言っても、それが自分自身、自分の所属するチームや組織にとって安全でなければ試せません。
何かを試行するには以下に挙げた条件を満たす必要があります。

• 自由に試行できる
  • 最適な解決方法が複数ある場合にはやっぱり両方試したい。時間的に余裕がないなら、両方のプロトタイプだけでも作って試してみよう。見積もりの際にはこのような過程を必要な時間として確保する必要がある。また、この試行がチームメンバーに悪影響にならないよう取り計らわなければいけない。
• 安全な状態に戻れる
  • 実験がうまくいかなかった時に安定した状態に戻れて、そこからもう一度トライできる。目指すのは最終的にうまくいくこと。
• 以前のあらゆる状態を再現できる
  • 今までの開発工程中の任意の段階のプログラムを再稼働しなければならない。去年動作していたバージョン、または先月動作していたバージョンを今稼働させることができる？
• 進展していることを証明できる
  • フィードバックなくして前進はありえない。試行は代替案よりもうまく動作した？どうしてそう言える？プロジェクトは進展している？先週よりも今週のほうが多く昨日が稼働している？

ソフトウェア開発であれば、上記の条件を満たす環境はバージョンコントロール、ユニットテスト、プロジェクト自動化で実現できます。

8.1 効果的な変化

個人も組織も変える（変わる）ことはとても大変で複雑なことです。本当に効果の上がる変化を実現する上で役立つことを紹介します。

• 計画を立ててから始める
  • 一定期間のおおまかな計画を立て、その実現を目指して努力する。どれだけ実行できたかを記録し、努力が足りないのではと思ったら記録を見て検討する。意外に成果は上がっているかも。
• 敵は過ちではなく無為無策
  • 失敗は恐れなくていい。
  • 無為無策が危険。
• 習慣づけには時間が必要
  • 新しい習慣を定着させるには最低でも3週間は必要。
• 信じれば実現する
  • 我々の思考が脳内の配線を物理的にかえ、脳内の化学物質の作用を変える。変化は可能だと信じる必要がある。
• 次の一歩は小さく踏み出す
  • 実行できそうなちょっとした目標を掲げ、達成できたら自分にご褒美をあげよう。そしてそれを繰り返す。

💬 まとめ

一部抜粋してご紹介しましたが、この他に集中をコントロールする方法や効果的な読書方法など、様々な達人までの道のりが書かれていました。
私も、まずは書籍の内容のうち、以下を試してみようと思いモレスキンのノートを買ってみました。モレスキンのノートは2年前くらいまで使っていたのですが、最近のメモは全てEvernoteにとっていました。Evernoteは全文検索できてとても便利ですが、改めてノートを見返してみるとノートを使っていた時の方が雑多な内容も気軽に書いていて、書籍の内容をやってみるのにちょうど良いと思いました。

• アイデアを書き留める
  • いつもノート(できれば無地のもの)を持ち歩き、これを使って気ままにいたずら書きやマインドマップ作成、メモなどをする。
• モーニングページ
  • 直感、問題解決、創造性を司る脳の機能を活かせるようになるため、朝一番に思いつくままノートに3ページ書く。
• ToDoリストの作成
  • コンテキストスイッチを無駄に切り替えないために、頭の中のリストを動的に更新するのをやめる。
• プラグマティック投資計画を作成する

これから自分がどういうスキルを習得したいのか、そのためにどうやって一歩一歩進んで行けば良いのかをきちんと考えてみようと思います！

モレスキン ノート クラシック ハード 無地 ラージ QP062 黒

リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法