本の引用やコメントをデライトに書いておくと、後で必要になったときに浮き出てくるので便利そう
Twitterに書くよりも、情報の再利用性が高い
物理的な本を持ち続けるのは難しいため、積極的にやっていきたい
Scrapboxのほうにも転記して、冗長化しておきたい
→転記スクリプトを作った：デライトからScrapboxへ転記するスクリプトのジェネレータ
本を読み終わったら、デライトで概念を座標化するとよさそう。これをするだけでも、けっこう頭が整理されるのではないか。また、上位階層の概念などが思いつかなかったりすると、再読のきっかけにもなる。（なお、下位階層が思いつくことは、端から期待していない。）
🟩使い方のgifアニメを追加
🟩生成されたスクリプトをクリックしたら、スクリプト全体が選択状態になるようにする
🟩スクリプトをコピーするボタンを追加
🟩この輪郭へのリンクを、Githubのレポジトリ（https://github.com/t-wataru/Delite-to-Scrapbox-script-Generator）のREADMEに張る
🟩github.ioのページへのリンクを、Githubのレポジトリ（https://github.com/t-wataru/Delite-to-Scrapbox-script-Generator）のREADMEに張る
✅入力されたScrapboxのURLの末尾に/がなくても動くようにする
🚫引き入れた輪郭、引き入れられる輪郭をタグにする
→中止。引き入れた輪郭と引き入れられる輪郭を取得するAPIが作られるまで待つ。
✅生成したブックマークレットのリンクを表示する。ドラッグアンドドロップでブックマークレットを登録できるようにする
✅from:～～が消えている【バグ】
✅輪符はScrapbox記法のリンクに変換
✅知番なし：hoge→[hoge]
✅知番あり：hoge→[hoge]
✅輪符の変換後の形式を検討する。読みやすさとデータ表現の両立を目指す。輪符に知番を含めると読みにくい
+https://i.gyazo.com/1aea20d729a89311cd8d277a6a7d1d57.png
→編集時に長い
→読むときに見た目が長い
→編集時の長さの変化は小さい
→同じタイトルの輪郭に対応できない
→一つのページに別の輪郭の説明を入れてしまう？
Scrapbox的で良さそう
もしページを分けたいときは、Wikipediaのように分岐させるためのページを作る
結局最初の方式に落ち着いた
✅画像対応
✅ページのタイトルに知番を追加する。知番がなければ同名の輪郭の区別がつかなくなる。タグ機能を追加するにはこれが欲しい
→削除した
🚫検索ページ（リンク：?kw=）でもブックマークレットを使えるようにする
→中止。検索ページではどの輪郭を転送したいのかを同定できない
✅from:～～をページ下部に移動する。カード表示の時に内容を優先的に表示させたい
🚫スクリプトのテンプレートを外部ファイル読み込みに切り替え。記号をエスケープするのが大変
✅quoteblock対応
quoteblockテスト用テキスト
テストテストテスト{}
使う分には困らないところまで開発できた
必要な機能は大体ある
あとはGoogleAnalyticsでも入れておこうかな
半ば趣味で
GoogleAnalyticsを入れると、利用者に通知しないといけなくなってしまう
あれ作るのめんどくさそう
Alertで出せばいいかな
だめだ、自分がそれをされたらいやだ
操作の邪魔にならないようにしたい
どうせPCからしかアクセスなさそう
理想的な見せ方
ネットで調べるのがいいんだろうな
よく見るのは下の方に出てくるタイプの通知
あれが一番ましかな。自分が知ってる中では
ライブラリとかありそう
入れるだけでいい感じに通知を出してくれるライブラリ
デライトからScrapboxへ転記するスクリプトのジェネレータ
ジェネレータのページ：https://t-wataru.github.io/Delite-to-Scrapbox-script-Generator/
使い方：
転送先のScrapboxのプロジェクトへのURLを、「Input scrapbox project url」へ入力
「Bookmarklet for forwarding Delite's 輪郭 to Scrapbox's page:」に、JavaScriptスクリプトが生成される
生成されたスクリプトを、転送したい輪郭の上で実行する
転送元の輪郭
Scrapboxに転送されて生成されたページ
■2020年7月19日
いったん目を通した
現時点で気になるところは抜き書きしてコメントしておいたので、気になったら調べられる
全体の20%ぐらいしか読んでない。興味がない箇所は斜め読みで飛ばしていった
多くの人々は、説明責任を負うことで、愚弄や叱責の対象になることに対して二の足を踏みます。しかし、優れたマネージャになろうと思うのであれば、全く逆の態度をとるべきです。つまり、チームやプロジェクトに関することについての職責を追求、行使することで、チームやプロジェクトに導こうとするべきなのです。また、非難されることに対するエンジニアやテスターの恐れを取り除くことで、解決策が優れたものになったり、迅速に実現されるというのであれば、進んでそうするべきでしょう。
『アート・オブ・プロジェクトマネジメント マイクロソフトで培われた実践手法』
マネージャやリーダが積極的に外部からの非難を引き受けることが、チームの生産性を上げる。非難の対象とされないことで、チームのメンバーは安心して働くことができる。
もし非難を引き受ける人がいなければ、チームは身動きが取れなくなる。メンバーの自発性が失われる。非難されることを避けるために、命令がなければ動かなくなる。
自分も読書の手控えに使ってみようかしら。
正直なところ，普段は読書の手控えなんてことしてないのだが（計算機どころか紙にも書かない）……。
何はともかく，試しにやってみよう。
『軍事とロジスティクス』がすごく良かったので、江畑謙介さんのほかの本も欲しいなと思って調べたらめっちゃ高値になってる
https://www.amazon.co.jp/gp/product/4822241165/
