感情が流れる河川がある。感情の水量の変化は非常に大きいので、ただ流しておくだけだと、とても危険だ。

だから心には一定まではどんな感情でも溜めておけるダムが設置されている。ダムの大きさは心の広さ、ダムの余力は心の余裕ということができる。

しかし連続して感情が流れこみ続けると、ダムが決壊する恐れがでてくる。なので、決壊しそうになったら、それなりの大きさの放流を行って決壊することを防ぐ必要がでてくる。

ダムの決壊というのは絶対に避けるべきことであり、それが起きないために多少下流で氾濫してでも、なんらかの方法で放流する必要がある。

この自分の日記に氾濫原と名付けたのは、いくつか理由があるが一つは感情が溢れてどうしようもなくなったとき、感情が流れる河川が氾濫するのをイメージしているからだ。

もう一つは氾濫原というのは植物にとって豊かな土地になることが多いという良いイメージからだ。クソみたいな感情の氾濫の後に、そういうことがあったからこそ、なんらかの成果がでると信じたい気持ちがある。

ネットにネガティブなことを書くなみたいなバカげたことを言うゴミみたいなやつがいるが、そういうやつらには心から死んでほしいと思っている。できるだけ苦しんで、何もなさず後悔と孤独の内に死んでいただきたい。他人の心を理解するということは不可能だが、放っておいてほしい人を放っておかないでバカにするようなゴミクズには、それ相応の報いをうけてほしい。

案外表記が統一されていない。系統的には N・m (ニュートン・メートル) と kgf・m (キログラムフォース・メートル / 重量キログラム・メートル) がある。kgf は 国際単位系ではない。

なので、

  1. トップ
  2. tech
  3. トルクの単位

ちょっと前まで日記の補足として動画を用いてきて、YouTube にあげるにせよ音もなにもなくスクリーンキャストだけというのが多かったけど、動画だけである程度完結してトピックの内容が纏まっていたほうが一石二鳥だろうというのと、いくつかの理由で、ちゃんと動画を作ることに挑戦している。

  • 上記の通り動画だけを見ても内容がわかるように
  • 作ったものをちゃんと説明することを心掛けるように
  • 文字だと伝えにくいニュアンスを説明するため
  • 最近は勉強会とかで話す機会がほとんどないため

作ったものをちゃんと説明することを心掛ける

日記で文字で説明するときは割と適当というか「わかる人だけわかれば良い」というスタンスで書いてしまう。

雑誌記事みたいなノリで書けばいいと思うけど、そういうスタンスで毎回書くのは結構大変で辛いし、細かいことをいちいち説明していると読者をバカにしている感がでるので避けたい。

動画、というか音声だと声色のニュアンスで細かい配慮を省略しやすく感じる。

文字だと伝えにくいニュアンスを説明する

文字で書くとすこしカタくなるというか、偉そうな感じになるケースが多々ある。これは根本的には書き手側の文章による表現力の問題なのだとはいえ、一方で受け取る側のリテラシにも関わるので限界がある。

音声の場合、受け取る側も文章を読むということよりも経験が長い (1歳ぐらいから音声を使ってコミュニケーションしている) はずなので、書き手の表現力による齟齬が生じにくくなる。

あと、文字で書くと「読み飛ばす」ことに慣れていない人には負担になってしまう。音声の場合勝手にすすむので、わからないなら勝手にすすむ。人によってはこのほうがいい人もいそう。(個人的には読み飛ばすほうが楽だけど)

最近は勉強会とかで話す機会がほとんどない

そもそも情弱になってきていて、おもしろそうだなと思ったイベントを当日に知るレベル。

ここ数年YAPCでだけ声出してる感じがする。

平日の勉強会だと仕事のあとあまりに疲れきっていることが多いのでさっさと帰りたいと思ってしまう。

ということで何らかの形で声出しておきたい。

続くか

わからない。どれだけ楽をして作れるかにかかってる。

今のところ

  • だいたいのストーリーを考えて台本をつくる
  • スクリーンキャストを撮りつつ同時に喋る
  • 編集していらないところカットする

は最低限必要そうという感じ。

適当に喋ってるように聞こえるが、一応台本を書いてから喋ってる。プレゼンのスライドよりは情報量が多いが、プレゼンよりは雑に書いた感じの台本がある。

一発録りで出すのはかなり厳しい。失敗できないという気持ちでやると気が滅入る。なので、後編集はある程度は必要と考える。編集で切ればいいやと考えられれば、そのほうが気が楽だし、クオリティがあがる (と思う)。

台本を書かずにとりとめもなく喋ると編集が大変だし、たぶん撮りなおしが頻発することが目に見えているし、どうせ話の流れは考えなければならないので、先に考えるのが一番良い。なお少しでも酔っぱらってると呂律がまわらないうえ、話題が飛んだりして完全にダメ。

ということで、たぶんこれ以上は作業を削れない。

スクリーンキャスト以外で動画を撮る必要がある場合はもっと面倒だけど、自分が作ったものを自分で説明するという限りでは、あまりその必要性は多くはなさそう。動画を撮る場合カメラと音声のセットアップがとても面倒くさい。

そして作業の全体の面倒くささは収録時間が長くなるほど増える。なので、だいたい5〜10分ぐらいを目安にしている。一度録ったものは最低でも編集で数度と通しで数度は見ることになるから、短かければ短いほど良い。

ということで僕のチャンネルです。視聴者ファンディング (投げ銭) も有効にしてますよ!!!!

  1. トップ
  2. tech
  3. ユーチューバー活動

検索してもいまいち出てこなくて、いつも「前見たのどこだったかな」となるので自分で書いた……

  1. トップ
  2. tech
  3. WebAudio の BiquadFilterNode の周波数特性をグラフにするやつ

ペーストボードにコピーが行われたときに、JavaScript で何かするというツールを書いた。

競合するソフトウェアがいくつかあると思うけど (dot-clipboard とか)、すぐできそうだし Swift で書かれたのはなさそうということで書いてみた。

ユースケースとしては

  • Slack のチャット画面を適当にコピーしたのを、自動でフォーマットしてペーストしやすくする
  • リッチテキストとしてコピーされるのがウザいので、プレーンテキストにしてしまう
  • 画像を自動でグリッチする

というのがあります。

つかいかた

起動するとアクセシビリティを有効にしろといわれるのでする

有効にしたらもう一度起動する。

コピーのイベントをキーイベントの Cmd+C を見ることで実現している (設定で変更可能)

あとフォーカスされているアプリとかウィンドウの名前を取得するためにアクセシビリティの機能を使っている

~/.copyhook.js を書く

function onCopied () {
	// console.log(pb.types());

	var bundleId = utils.focusedApplicationBundleId();
	console.log('onCopied: ' + bundleId);
	if (bundleId === "com.apple.Terminal") {
		// clear data without "public.utf8-plain-text"
		pb.copy(pb.string());
	}
}

こんな感じのを書く。これだと Terminal.app で Cmd+C を押した場合、プレーンテキストだけにして他のデータ型を削除するようになる。(Google Keep とかにペーストするとき意味不明な改行が入りまくったりするのを回避できる)

または、レポジトリにあるファイルをとりあえず使ってみるなら

git clone https://github.com/cho45/CopyHook.git
cd CopyHook
ln -s dotcopyhook.js ~/.copyhook.js
ln -s dotcopyhook ~/.copyhook

これだと Slack のアプリででコピーしたときいい感じにフォーマットするようになる。

JS をカスタマイズする

require() で ~/.copyhook 以下から外部ファイルを読みこんだりできるようになっている。

console.log() は OS X のシステムログに書きこむことができる。Console.app を起動すれば確認可能。

utils.focusedApplicationBundleId() でフォーカスされているアプリの bundle id を取得できたり、utils.focusedWindowName() でフォーカスされているウィンドウのタイトルを取得できたりする。これにより、処理を場合わけできる。

CopyHook の JS は直接ファイルの読み書きなどができるようになっていないが、utils.system() によって外部プログラムを呼びだせるようにしてある。

なお、書きかえた JS ファイルは次回コピー実行時に自動でリロードされる。

実装について

コピーイベント

ペーストボードに「コピーが行われた」という Notification (OS X でイベントコールバックしてくれる仕組み) はないので、別の方法でやる必要がある。

  • NSPasteboard の changeCount をポーリングする
    • 殆どのペーストボード監視アプリはこれでやっているはず
    • ポーリングなので常に余計にCPU負荷がかかる
  • Cmd+C 監視
    • 右クリックからコピーなどに対応できない
    • アクセシビリティ設定が必要

ポーリングで常に監視するのがとりあえず嫌だったので Cmd+C をデフォルトにしている。

設定でポーリングにも変更可能。

JavaScriptCore

JS の実行には JavaScriptCore.framework を使っている。OS X 10.9 から使えるようになった framework で、JS の実行環境とネイティブ実行環境をブリッジして使えるようにしてくれる。

JS で書けるようにしておくと、テキストフィルタするようなのを書く場合、とりあえず node で書いてテストして、それをそのまま CopyHook でも使うということができて便利。

  1. トップ
  2. tech
  3. CopyHook というペーストボードの中身をいじるツールを作った