2015年 03月 27日

git で今すぐ成果を倍にできる方法

#!/bin/sh

if [ "x$COMMMMMMIT" = "x" ]; then
	COMMMMMMIT=1 git commit --allow-empty -m "仕事したぞ!!!"
fi

このファイルを .git/hooks/post-commit として保存します。

gitで今すぐ成果を3倍にする方法

#!/bin/sh

if [ "x$COMMMMMMIT" = "x" ]; then
	COMMMMMMIT=1 git revert HEAD
	COMMMMMMIT=1 git revert HEAD
fi

このファイルを .git/hooks/post-commit として保存します。

2015年 03月 24日

ブログシステムは自作すべきか? ブログサービス VS 自作システム

結論:自作するメリットはほぼない (金銭的にもない)

ブログサービスの利点と欠点

先にブログサービス(ASP、すなわち自分でインストールしたりホストしたりしない)の利点を列挙する

  • 大抵基本無料である
  • 大抵既に機能が豊富である
  • 運営会社の日々のサービス開発によって自動的に機能が増える
  • 欲しい機能がないときは要望フォームに書けばよい
  • それで実装されなきゃ文句いってれば良いので気楽
  • サービス停止がまずない
  • 勝手に閲覧者が増える仕組みが備わっていることが多い
  • 良いデザインのテンプレートが用意されていることが多い

一方で欠点は

  • 一部有料であることが多い
  • 広告がでる・自分で広告を貼れないことが多い
  • 機能が実装されなくても文句しかいいようがない
  • ニッチなニーズには答えてくれない

自作の利点と欠点

利点

  • 自由に欲しいものが作れる
  • プログラミングの勉強になる

欠点

  • 自力でホスティングするため金がかかる
  • 自分で実装しなければ機能は永遠に増えない

つまり

自作するメリットはほとんどない。ホスティングに金を払うよりブログサービスに金を払ったほうが気楽である。

それでも自作するか

もしウェブプログラマなら自作すべきであると常に主張したい。

2015年 03月 20日

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

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

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

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

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

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

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

トルクの単位

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

なので、

ユーチューバー活動

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

続くか

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

今のところ

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

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

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

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

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

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

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

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

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

WebAudio の BiquadFilterNode の周波数特性をグラフにするやつ

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

2015年 03月 18日

CopyHook というペーストボードの中身をいじるツールを作った

ペーストボードにコピーが行われたときに、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 でも使うということができて便利。

2015年 03月 16日

関連エントリー (画像)

2015年 03月 13日

神宮参り

伊勢参りしてきた。

熱田神宮

伊勢にいく前に名古屋の熱田神宮へ。熱田神宮の御神体は草薙剣 (天叢雲剣)とされていて、これはヤマタノオロチの尻尾から出てきたという、いわゆる三種の神器のひとつである。三種の神器は天孫降臨の際に天照大神がニニギに手渡したといわれるものなので、伊勢神宮内宮の御神体とされる、同じく三種の神器の一つである八咫の鏡と関係が深い。


結構敷地は広かった。また拝殿から本殿はかなり遠く、殆ど近づけない。さすがにかなり立派な神社だった。

外宮

名古屋から特急で一気に伊勢市へ。外宮から参拝するのが習わしということで、先に外宮から。



実は伊勢には京都に住んでいたころ日帰りで一度きており、外宮には参拝したことがあるが、それは遷宮前。

当然だけど遷宮して間もない (といっても既に3年目) ので社殿その他が綺麗だった。

正宮はとっくに遷宮が終わっているが、境内の他の神社などはまだ遷宮中のものもあって面白かった。以下は建築中で2つ並んでいる別宮風宮。

以下は土宮

また、外宮には「せんぐう館」というミュージアムができていて、これが思いのほか面白かった。特に、外宮の (内宮もだけど) 正宮は普通に参拝してもかなり遠くて屋根の一部しか見えないのだが、せんぐう館の中に実物大の模型として一部が作ってあって、とても良かった。

ほかに建築方法とか、宮大工の技みたいなのもあって良かった。大変おすすめ。

内宮

内宮は一泊後、早朝に参拝した (朝早くでないと人が多くなるから)。宿は神宮会館に泊まり、神宮会館は宿泊者向けに早朝参拝のガイドをしてくれるので、これに参加させてもらった。神宮会館は「伊勢神宮崇敬会」という財団法人が運営しており、なんとなくこわいかと思ったが全くそんなことはなかった…… ガイドの人は地元の人のようで、大変わかりやすい解説をしてくださった。結構ライトな説明でそれほど宗教色のある解説ではなかった。

前回の内宮と外宮の柱の一部が宇治橋の鳥居になるとか、御稲御倉 (稲の倉庫だが、主祭神が設定されており、御稲御倉神=宇迦之御魂神=稲荷神) が正宮のほぼ5分の1のサイズの唯一神明造りになっているとか、やっぱりその場で説明してもらえると楽しい。

荒祭宮ももちろん参拝した。

内宮は前回伊勢に来たときは人が多すぎて参拝しなかった (それほど参拝にこだわりがないので)。今回は早朝だったのでスムーズだった。5時から参拝できるみたい。

あと石段を登るとぱっと見、遷宮用の敷地がどこにあるのかよくわからないけど、石段ごともう一つ奥に敷地があるようだった。つまり前回見た石段は奥の石段だったわけだけど、奥には入れないのでそちらの敷地は見ることができない。

月讀宮

内宮の別宮。4つ社殿が並んでいて壮観。遷宮が終わっており全部ピカピカだった。メインの月讀宮が少し大きい。

月夜見宮

外宮の別宮。月讀宮と同じく月夜見尊が主祭神。

なんとなく神話上で殆ど出番のない月夜見尊が好きなので行ってみたかった。(出番がないので祭っている神社も非常に少ない)

まとめ

とりあえず当初行きたかったところは一通り行けてよかった。

神明造

神社建築だと神明造がやはりかっこいいと思っていて、パーツとしては特に千木 (斜めに飛びだしている棒の部分) と鰹木 (上にのっている丸太のようなもの) のところが好きである。

全体的なフォルムが直線的で古風かつ力強いところとか、教科書に乗っている「高床式倉庫」ほとんどそのまんまな感じも良い。

そういえば、普通の神社だと金物がだいたい銅製そのままなので、緑色になっているのだけれど、神宮周辺の神社は全て金メッキ(金箔を貼ったり、水銀を使ったり)になっており、豪華だった。