EvernoteのノートブックはGTDの「状態」で作成すれば全てがうまくいく

全てはうまくいかないかもしれませんが。

Evernoteは全盛期だった2010年頃にアカウントを取得して使用していたんですが、一度挫折していました。とりあえず見た記事を片っ端から取り込んでみたりライフログを貯めてみたり、ノートブックを「買うもの」「仕事」「リスト」等々、使いこなそうと頑張ってみたものの、使いこなす手間が多くなりすぎて諦めてしまいました。そもそもライフログなんて貯めても見返す必要なんてないし。

そのあとはvim+Dropboxで長いことメモ環境は運用していたんですが、やっぱり画像を取り扱ったりテキストの登録を自動化したり、iPhoneからもテキスト入力をしたくなったためEvernoteに戻ってきました。そして前回の挫折を踏まえてノートブックの括りを「状態」と捉えて構築してみました。それがこちら

基本方針としては

  • 自分の作業場所という概念で使用
  • GTDのフローを採用
  • 00_inboxになんでも入れて、あとから整理
  • 状態をノートブックに
    • GTDの「整理」の段階でカテゴライズする以下のものを噛み砕いたもの
      • 次のアクション
      • プロジェクト
      • 連絡待ち
      • いつかやる
      • カレンダー
    • 「プロジェクト」は曖昧な概念になるので「作業」と定義、複数のやる事のまとまりがあって時間がかかる事
    • 「次のアクション」は「流しでやる」、片手間にできて頭使わないでする事
    • GTDの「処理」の段階の「資料」も必要なので使用
  • やる、やらないの状態でノートブックのスタックを作成
    • 「やる」に入っていたノートを「やった」ら資料に入れるかゴミ箱に入れるか、どちらかが基本。
  • 種類をタグに
    • タグは思いつくものを何でも入れる
    • 「買う」「映画」「見たい」「仕事」「行きたい」「ブログ」「vim」等々
  • 絵文字を入れると見やすくなるので入れる
  • 頻繁に見る必要があるものは検索を登録してショートカットに入れる
    • 「仕事をやる🚀」のショートカットは「stack:”1_やる🚀” tag:”仕事”」の検索ワード
    • ノートの中にTODOリスト未完了があるものも検索できる
  • 不要なもの、終わったものはゴミ箱に
  • 終わったけど後で見返すかも?のものは資料のノートブックに移動
  • ゴミ箱は検索できなくなるので注意
  • 検索して必要ない物が出ないように大体のものは削除している
  • 記事のクリップは基本しない
  • 読みたい記事も追加するけど、基本読み終わったら削除している

作業をする場所、と決めているのと「何すればいいんだっけ」の時に最初に見ればわかる状態にしています。

Gmailのフィルタで転送したメールを登録したり、思いついた事をMacならクイックノートで登録、iPhoneならFasteverで登録してとりあえず書いて登録すれば未来の自分がなんとなく整理してやっといてくれる。

結構続いてるのでなかなか良かったですね。

読書メモ: 「GIVE & TAKE「与える人」こそ成功する時代」

つらつらと印象に残った部分を書き写す。文脈を再構築したり解説をする気は無く、自分のためのメモ書きなので悪しからず。

  • 3つのタイプ
    • ギバー(人に惜しみなく与える人)
    • テイカー(真っ先に自分の利益を優先させる人)
    • マッチャー(損得のバランスを考える人)
  • と分けていてギバーになりましょうって本。
  • 仕事とは人のためにすること、という本質をわかっているかの違いでもある
  • 自分のためにやることは趣味
  • ギバーは一番生産的になる結果があるが、一番非生産的になる結果もある
  • テイカーは自分中心で自信があって、躍動的
  • マッチャーはギブアンドテイク、与えたら求めるビジネスマンタイプ
  • ギバーにも成功するタイプがある
  • 失敗するギバー
    • 自己犠牲
    • 自分を犠牲にして人に尽くす
    • 自分の仕事が終わらない
    • 疲弊して燃え尽きる
  • 成功するギバー
    • 他者志向
    • 受け取るより多くを与えても自分の利益は見失わない
    • 「いつ、どこで、どのように、誰に与えるか」を自分で決める
  • ギバーが燃え尽きるパターン
    • 与えたことでもたらされた影響を前向きに認めてもらえない事
    • 与えた時間やエネルギーが多いせいでは無い
    • 困っている人をうまく助けてやれないときに燃え尽きる
  • 燃え尽き後の対処法
    • 文字を書き続ける実験
    • ヘトヘトになるまで書いて「一文字さえ腕を上げて書くことはできない」
    • その後なんの苦もなく腕を上げて髪を整えた
    • 状況が変われば気力が回復する
  • 他者志向の戦略
    • 自分を削るのではなく他者を中心にして考える
    • 求められるまま与えるのではない
    • 1週間のこの日は他者の事だけやるとか
    • 1日1回与えるのを5日より1日5回与える方が幸福度は高い結果が出ている
  • 燃え尽き防止
    • 人に助けを求め、やる気や気力を維持するのに必要なアドバイスや協力を仰ぐ
    • 周囲からサポートを受ける
    • ちゃんと助けを求める
  • テイカーの対処
    • 求めてばかり居る人に付きっ切りになると疲弊する
    • テイカーを理解して適切な距離を取る
    • 時にはマッチャーになることで犠牲にならない戦略を立てる
    • 人はみな善人だという信念から出発するが、同時に、周囲の状況を注意深く観察して潜在的なテイカーを割り出す
  • テイカーと決めつけは間違い
    • 人はあるグループに参加するとどのように振る舞うのがふさわしいか、その手がかりを探す
    • 人は人生の多くの領域で、ほかの人がどう行動しているか知らないばかりに、受けとることに終始している
  • 他人はギバーでないと思い込み、相手に与える気をなくさせたりするような行動や言動をとるようになる
    • 助けを求めない
    • 人に負担をかけたく無い、恥ずかしい、仕事ができない人間に見られたく無い
    • うまくいっているように見せなければならないというプレッシャーを絶えず感じている
  • テイカーをギバーに変える
    • そういう状況を作ればいい
    • いい人に見られて自分にメリットがある事が解ればテイカーはやる
    • 与えることを人目にさらす
    • 真似してくれる
    • 行動が先行して考え方も変わる

もうちょっと長くて印象に残った箇所はあれど、まとめてみるとこんなもんですね。身になった。
テイカーの事をボロクソに言っていたり、「与える」とだいぶ上から目線なのが気になるけど、自分の視点を変えてくれたしこれをベースに考えて行動すれば絶対に良くなると思えた。いい本だったな。

https://amzn.to/2NGUP6v

radikoタイムフリーのダウンロードアプリ「inco」を公開しました

soramugi/inco: radikoタイムフリーのダウンロードアプリケーション
https://github.com/soramugi/inco

## 概要

パソコンやスマホでラジオが聴けるサービスのradiko。そのradikoの過去1週間以内に放送された番組が聴けるタイムフリー機能で聴取できる番組をダウンロードするパソコン向けアプリケーションが「inco」です。

## incoアプリケーションのダウンロード方法

githubのreleases機能を使用。

このURLから https://github.com/soramugi/inco/releases

– Macなら`dmg`ファイル

– Windowsなら `exe`ファイル

をダウンロードとインストールをしてください。

## 使用方法

「inco」のアプリケーションを起動するとradikoタイムフリーの画面が表示されます。 「inco」上で表示されるradikoタイムフリーの聴取を始めるとダウンロードが始まります。

ダウンロードが完了すると`~/Download`ディレクトリにmp4ファイルがダウンロードされます。

https://github.com/soramugi/inco

MacとWindows両対応。
仕組み的にはradikoのサイトを閲覧して特定のURLにアクセスした場合のヘッダー値を取得、ffmpegのコマンドを構築してダウンロードの実行と進捗表示

作った動機

electronを触る機会がありまして、思いの外簡単にMacとWindowsの両対応アプリケーションが作成できることがわかったので試しに何か作成してみたい。が動機です。重い処理でもユーザーのPCで実行させればある程度は許容されるかなと。

作ってどうだった?

UIの構築が面倒だったので、通信の流れだけチェックして必要なトークンが取得できれば裏でffmpeg実行するようにしてみたんですが、なかなか便利ですね。進捗表示をしてみたけどpush通知されれば別に必要がない気もします。electronのメインプロセスからレンダープロセスに情報渡す手順の確認ができたのはよかったな。

ffmpegのパッケージング、実行は簡単にできたのですが、最初ffmpegを実行するfluent-ffmpegライブラリを使用して試作するもオプションの指定方法が謎すぎてchild_processの実行に方針転換。Windowsで動くか若干不安だったけれど問題なし。

足りないなと思う機能に、自動アップデート、ブラウザサイズの調整、ダウンロードの中断、ブラウザバック、スケジュール実行、ダウンロードパスの変更、ダウンロードフォーマットの変更、等々、もう少し調整の余地はあるけど一旦置いておきます。electronで作成するの楽しかったので他のアプリでも作ろうかなと。

「アイデア病」アイデアが出ただけで終わった気になる

未来は音楽が連れてくる、の後編を読んでいたときに

「アイデア病」の存在を知りました。スティーブ・ジョブズがiPod開発時にアイデア病を警戒して最後まで付きっ切りでプロジェクトに参加して完成までこぎつけたと。

「アイデア病」とは複数の問題を一気に解決してくれる素晴らしいアイデアを考え出して、チームメンバーに伝えるだけで自分の仕事は終わり、想像したアイデア通りに事が進んで全てが解決されると思い込む事。実際はそのアイデアを実現するためのボトルネックを見落としていたり、そもそもそのアイデアを実現するためのリソースが不足していて不可能だと言う事が起きる。

本の中では「アイデア病」の存在を知っていたスティーブ・ジョブズは最後まで付きっきりになってプロジェクトを遂行した、と書かれていました。

この話、伊集院のラジオでも同じことを言っていて、テニスの全米オープン、ブラジルで開幕して真夏の暑い時期にやっているので途中休憩を挟みながら試合を進めている、というニュースを聞いて

「そんな事するんなら真夏じゃない時期とか休憩する必要が無い地域でやれば良いのにね、ハハハハ!」「と構成の渡辺くんと喋っていたけど、そうしない理由って絶対あるはず、わかってるんですよそんな事」と笑い話にしつつも、その「アイデア」が通用しない理由が絶対あるし、そんなことは考えられているがそれをやらない理由もなんとなくありそうだなと解っているけど、自分たちはそれを無視して馬鹿話してたんですよ、と話をしていた。なんだか文字にするとこの空気感が伝わってるのか不安になるな。

要は「アイデア」が出ただけで終わりになるときちんと進まないし、その「アイデア」をやらない理由を知っている人から、馬鹿にされるだろう事を理解していて、予防線をきちんと張っていた、という話になるのかな。「アイデア」の向こう側をきちんと見ている人たち。

「アイデア」だけで終わりにしないように着実に進めていきたいなと思いつつ、確かに「アイデア」が出ただけで気分が良くなって終わった気になるのもわかる。行動して終わった気になって全てが解決した気分になるので、これだけに注力することができれば割と気分がいい。この気分が良い部分だけを抜き出したwebサービスが作れないものか。

「アイデア」が出ただけでは終わりでは無いけども、「アイデア」が出たことによる気分の高揚だけを目的とすればその「アイデア」は重要で大切で意味があるものになる。

じゃあその「アイデア」はなんなの?と考えるもまだそこまでは出し切っていない現状…

怒られたい欲求

怒られたい気持ちがある。

本当は怒られたくなくて、常に褒められて生きていきたいんだけれど、ある程度の責任が伴う状況で自分自身が考え出した答えが正しいかもわからず、結果を教えてもらえず只々過ぎてしまい、改善することも変更することもできない状況。

結果が解らないし教えてもらえない。相手は結果を考えていないし、考えていたとしてもわざわざ伝えることはしないのが「大人の対応」なので間違いがあれば離れていくだけで次が無いだけ。

そういった状況に常にさらされていると怒られたい欲求が出てくる。別に性癖の問題ではなくて、怒られるというのは相手が離れたり諦める方法は取らないで、良くしようと努力して自分に伝えてくれている。莫大なエネルギーが必要になる行為なので真摯に受け止めて自分自身を良くするために重要な課題とすることができる。

重要な課題、と捉えると100%相手が正しいことしか言われない前提になってしまうのでそれは正しくなくて、付け加えると相手の「これ俺がムカつきますね」「ただただ面倒臭い」等のライン引きが解るだけでも相手の人間味が解って安心し、「あの人が喜ぶこの事がしたい」と思えるので、「怒られる」と言うことは自分にとってすごい大事な要素になっている。

というか、大雑把に反応がもらえるのはとても良いことですね。反応が貰えれば受け手である自分の中で都合の良いように解釈する事ができる。

怒られたいですね。ほどほどに。

テキストの整形を効率的に終わらせるvimの小技

ちょっとした覚書やslackへの投稿前の下書き、調査時のログを仮置きしていたメモ環境としてはvimを使用していたのですが、最近はEvernoteに置き換えてしまって、iPhoneからでも編集しやすく、検索しやすいメモ環境を構築しています。

プレーンテキストで保存できれば充分なのですが、変なフォーマットが付いたり思い通りの表示になってくれなかったりと不満な点がありつつもメール送信でノート(メモ)が作成されるので自動化が容易なのと、自分が必要と思っていなかった機能やショートカットを覚えられる機会が得られるので新しい発見があり何かと楽しいです。

ですが、テキストのまとまりを必要な形式に変換する作業、テキスト整形をするためのツールではないので、そういった作業をするときにはgvimを立ち上げたり、コーディング中のvimエディタのタブを新規で立ち上げて整形しています。「この作業をするにはvimじゃないと」と思える小技が溜まってきたのでまとめておきます。

紹介するvimの小技としては以下になります

  • 文字の置換、削除
  • マーク機能で行削除
  • 矩形選択でまとめて行操作
  • マクロで繰り返し操作

文字の置換、削除

エディタツールとして基本的な機能。少ないタイプ数で柔軟性が高く、GUI操作ではないのでUIが変わらず一度覚えたらずっと使えます。使用方法は

  • /<置換したい文字列>
    • 検索
  • :%s//<任意の文字列>/
    • 置換

/<置換したい文字列> で検索した後だと :%s/<置換したい文字列>/<任意の文字列>/ に置き換えられます。 なお、置換したい文字列は正規表現で設定できるので一通り覚えておくと後々楽です、が、jsやrubyなどの正規表現とは少し違う設定方法(のはず)なのが分かりづらいのがたまに傷。

ちなみに <任意の文字列> は指定無しにすると削除されます。削除する用途で使うことが多いですね。

  • :%s///
    • 一括で削除
    • ただし行毎の先頭一致のみ
  • :%s///g
    • 一括で削除
    • 行毎の一致全て
  • :%s///c
    • 置換時に毎回確認
  • :%s//^M/
    • ^Mは改行コード
    • Ctrl+vの後にEnterで改行コードの挿入
    • タブもCtrl+vの後に指定可能

マーク機能で行削除

  • ma
    • マークの開始
  • jjj
    • 3行下に移動
    • 好きな位置まで移動
  • d'a
    • マーク位置から現在行まで削除

vimはノーマルモード中に5ddで5行削除できますが、行数なんて毎回数えるのは面倒なので「ここから、ここまで移動して、削除」と頭の流れをそのままコマンドとして打ち込めるのでマーク機能は楽です。
ちなみにvim使いはShiftキーと矢印キーを使うのを嫌います。

マーク機能はAlignプラグインで列の位置揃えをする場合によく使います。
http://nanasi.jp/articles/vim/align/align_vim.html
後述する矩形選択を実行する際にはマーク機能+Alignで揃えておくと楽に変更することができます。

矩形選択でまとめて行操作

複数行の行頭、行末に文字入力やペーストします。Ctrl+vで矩形選択中に

  • i huge Esc でhugeが全ての選択行に挿入
  • $で行末まで選択、Shift+a huge Esc で全ての行末にhugeが挿入
  • p で全ての選択範囲にペースト

pで行頭にペーストするときにはあらかじめ行頭に空白文字列を入力しておかないと、行頭1文字がペースト文字列に書き換わります。少々面倒ですね。

マクロで繰り返し操作

  • qa<連続して実行したい操作を入力(マクロ)>q
    • aキーにマクロの保存
  • 10@a
    • aキーに保存されたマクロを10回実行

例えばマクロを o Enter Esc j で記録、10@aで実行すれば10回連続した行の間に改行コードが挿入されます。

まとめ

以上が普段から使っているちょっとした小技です。コーディング中だとプラグインとして配布されいてる機能を使用しているばかりで、vim単体の機能を使いこなす場面は大文字コロンや大文字黒丸、全角数字などが入り混じる他人が書いたテキストを整形する際に鍛えられるなと。そんな機会あんまりないんですけどね。

electron-builderで自動アップデートに対応

前回の記事「electron-builderを使ってvueアプリケーションのパッケージを作成」の続きです。前回はvue+electronとしての構築方法でしたが今回は

  • コード著名(Mac)
  • AutoUpdate指定
  • Publish指定

の解説です。electron単体の自動アップデートの設定として独立している記事になっています。

はじめに、electron-packagerの頃はMac用の自動アップデート対応にはパッケージ配布用のサーバーが必要でした。パッケージを置く用途+バージョン情報から最新のパッケージ情報をjsonで返却するサーバーが。

そのため最善手としてはLambdaを使用してs3のダウンロードURLを返却する設定が必要だったのですが、electron-builder(正確にはelectron-updaterの機能)ならそれは不要になります。ビルド時に作成されるymlファイルを読み取ってアップロードの可否を判定するので、静的ファイルのホスティングさえできれば良いのでs3やgithubのリリース機能のみでelectronの自動アップデートに対応することができます。

面倒なサーバーセッティングが必要なく、自動アップデートに対応出来るようになるのでぜひ使っていきましょう。

コード著名(Mac)

Mac用アプリケーションではコード著名をしないと自動アップデートがされません。コード著名をするにはApple Developer Programに登録してxcodeでmacOS用の「Developer ID Application」を作成しておけばビルド時に自動で著名してくれます。ちなみにMac環境でのビルドが必須&自動アップデート対応をするとMacAppストアで配布はできません。

公式ドキュメントページ: https://www.electron.build/code-signing

AutoUpdate指定

electronの自動アップデートさせる設定を追加します。まずは必要パッケージのインストール

npm i --save electron-updater
npm i --save electron-log

公式サンプルプロジェクトの対象コードだけ別ファイルに分けて保存

# src/auto-update.js

import { app } from 'electron';
import log from 'electron-log';
import { autoUpdater } from 'electron-updater';

autoUpdater.logger = log;
autoUpdater.logger.transports.file.level = 'info';
log.info('App starting...');

function sendStatusToWindow(text) {
  log.info(text);
}

autoUpdater.on('checking-for-update', () => {
  sendStatusToWindow('Checking for update...');
})
autoUpdater.on('update-available', (info) => {
  sendStatusToWindow('Update available.');
})
autoUpdater.on('update-not-available', (info) => {
  sendStatusToWindow('Update not available.');
})
autoUpdater.on('error', (err) => {
  sendStatusToWindow('Error in auto-updater. ' + err);
})
autoUpdater.on('download-progress', (progressObj) => {
  let log_message = "Download speed: " + progressObj.bytesPerSecond;
  log_message = log_message + ' - Downloaded ' + progressObj.percent + '%';
  log_message = log_message + ' (' + progressObj.transferred + "/" + progressObj.total + ')';
  sendStatusToWindow(log_message);
})
autoUpdater.on('update-downloaded', (info) => {
  sendStatusToWindow('Update downloaded');
});


app.on('ready', async () => {
  autoUpdater.checkForUpdatesAndNotify();
})

electronのmainファイルで上記のファイルをimportすれば完了です。

import './auto-update';

自動アップデート対象のパッケージダウンロードURLは後述するPublish設定を行えば不要です。アップロード処理のログ出しは以下のパスに出力されます。

* on Linux: ~/.config/<app name>/log.log
* on OS X: ~/Library/Logs/<app name>/log.log
* on Windows: %USERPROFILE%\AppData\Roaming\<app name>\log.log

上記のサンプルプロジェクトの挙動だと

  • 起動時にアップデート出来るかチェック
  • アップデート出来るのであれば通知&ダウンロード
  • ダウンロード終了
  • 次回起動時に適応される

という流れになります。実際に通知される内容はこちら

ダウンロード等のハンドリングをしたいのであれば公式のドキュメントページに記載されているAPIを使い分けましょう。

公式ドキュメントページ: https://www.electron.build/auto-update

Publish指定

公開指定です。公開先はproviderとして何種類かありますが試したのは以下の3種類

  • generare
    • 専用サーバー等、ホスティング先を独自に設定する場合に指定。
    • アップロードはビルド完了後に自分で行う。
  • s3
    • awsの静的ファイルホスティングサービス。
    • 自動でアップロードしてくれる
    • バケットの作成&バケットポリシーの変更があらかじめ必要
  • github
    • githubのリリース機能に自動でアップロードしてくれる。

generateが汎用的に使用できるが、アップロードはしてくれない。s3やgithubで要件が満たせるのであれば使用した方が得です。

ビルド時のコマンドラインオプションに

--publish always

等を追加することでpublishオプション指定でアップロードなりが実行されます。ちなみに上記の設定は常にビルド成果物をアップロードします。

s3の設定例としては以下をオプション指定した場合

publish: {
  provider: 's3',
  bucket: 'example-vue-electron',
  region: 'ap-northeast-1',
},

バケットexample-vue-electronを作成後、パブリックアクセス設定を以下に設定を行う

アップロード時に公開設定がされるので事前準備は以上で終了。
ビルド時に
AWS_ACCESS_KEY_ID 
AWS_SECRET_ACCESS_KEY
のenv指定を行えば対象のバケットにアップロードされます。

githubの設定例はオプション設定がこの場合

publish: {
  provider: 'github'
}

アップロード用のトークンをこのページでrepoの欄にチェックして取得 https://github.com/settings/tokens/new

GH_TOKEN
のenvを指定、ビルドすればアップロードされます。

公式ドキュメントページ: https://www.electron.build/configuration/publish

まとめ

前回同様試作したプロジェクトはgithubに上がっています https://github.com/soramugi/example-vue-electron

travisの設定も試してみたのですがp12ファイルの設定がうまく出来ていないのでMac版の自動アップデートが失敗する状態になっています。 https://travis-ci.org/soramugi/example-vue-electron そのうち設定できるようにしたいところですが、自分の要件だとtravisまでは設定しなくても良いかなと。下準備ばかりではなく動くアプリケーション作りたい欲求が出てきました。

electron-builderは便利です。複雑化していたelectronのビルド環境を簡素にしてくれる救世主です。ですがネット上にはelectron-packagerの情報ばかりで非常にもったいない。みなさん使っていきましょう。