#!/bin/sh
if [ "x$COMMMMMMIT" = "x" ]; then
COMMMMMMIT=1 git commit --allow-empty -m "仕事したぞ!!!"
fi このファイルを .git/hooks/post-commit として保存します。
#!/bin/sh
if [ "x$COMMMMMMIT" = "x" ]; then
COMMMMMMIT=1 git commit --allow-empty -m "仕事したぞ!!!"
fi このファイルを .git/hooks/post-commit として保存します。
#!/bin/sh
if [ "x$COMMMMMMIT" = "x" ]; then
COMMMMMMIT=1 git revert HEAD
COMMMMMMIT=1 git revert HEAD
fi
このファイルを .git/hooks/post-commit として保存します。
結論:自作するメリットはほぼない (金銭的にもない)
先にブログサービス(ASP、すなわち自分でインストールしたりホストしたりしない)の利点を列挙する
一方で欠点は
利点
欠点
自作するメリットはほとんどない。ホスティングに金を払うよりブログサービスに金を払ったほうが気楽である。
もしウェブプログラマなら自作すべきであると常に主張したい。
感情が流れる河川がある。感情の水量の変化は非常に大きいので、ただ流しておくだけだと、とても危険だ。
だから心には一定まではどんな感情でも溜めておけるダムが設置されている。ダムの大きさは心の広さ、ダムの余力は心の余裕ということができる。
しかし連続して感情が流れこみ続けると、ダムが決壊する恐れがでてくる。なので、決壊しそうになったら、それなりの大きさの放流を行って決壊することを防ぐ必要がでてくる。
ダムの決壊というのは絶対に避けるべきことであり、それが起きないために多少下流で氾濫してでも、なんらかの方法で放流する必要がある。
この自分の日記に氾濫原と名付けたのは、いくつか理由があるが一つは感情が溢れてどうしようもなくなったとき、感情が流れる河川が氾濫するのをイメージしているからだ。
もう一つは氾濫原というのは植物にとって豊かな土地になることが多いという良いイメージからだ。クソみたいな感情の氾濫の後に、そういうことがあったからこそ、なんらかの成果がでると信じたい気持ちがある。
ネットにネガティブなことを書くなみたいなバカげたことを言うゴミみたいなやつがいるが、そういうやつらには心から死んでほしいと思っている。できるだけ苦しんで、何もなさず後悔と孤独の内に死んでいただきたい。他人の心を理解するということは不可能だが、放っておいてほしい人を放っておかないでバカにするようなゴミクズには、それ相応の報いをうけてほしい。
ちょっと前まで日記の補足として動画を用いてきて、YouTube にあげるにせよ音もなにもなくスクリーンキャストだけというのが多かったけど、動画だけである程度完結してトピックの内容が纏まっていたほうが一石二鳥だろうというのと、いくつかの理由で、ちゃんと動画を作ることに挑戦している。
日記で文字で説明するときは割と適当というか「わかる人だけわかれば良い」というスタンスで書いてしまう。
雑誌記事みたいなノリで書けばいいと思うけど、そういうスタンスで毎回書くのは結構大変で辛いし、細かいことをいちいち説明していると読者をバカにしている感がでるので避けたい。
動画、というか音声だと声色のニュアンスで細かい配慮を省略しやすく感じる。
文字で書くとすこしカタくなるというか、偉そうな感じになるケースが多々ある。これは根本的には書き手側の文章による表現力の問題なのだとはいえ、一方で受け取る側のリテラシにも関わるので限界がある。
音声の場合、受け取る側も文章を読むということよりも経験が長い (1歳ぐらいから音声を使ってコミュニケーションしている) はずなので、書き手の表現力による齟齬が生じにくくなる。
あと、文字で書くと「読み飛ばす」ことに慣れていない人には負担になってしまう。音声の場合勝手にすすむので、わからないなら勝手にすすむ。人によってはこのほうがいい人もいそう。(個人的には読み飛ばすほうが楽だけど)
そもそも情弱になってきていて、おもしろそうだなと思ったイベントを当日に知るレベル。
ここ数年YAPCでだけ声出してる感じがする。
平日の勉強会だと仕事のあとあまりに疲れきっていることが多いのでさっさと帰りたいと思ってしまう。
ということで何らかの形で声出しておきたい。
わからない。どれだけ楽をして作れるかにかかってる。
今のところ
は最低限必要そうという感じ。
適当に喋ってるように聞こえるが、一応台本を書いてから喋ってる。プレゼンのスライドよりは情報量が多いが、プレゼンよりは雑に書いた感じの台本がある。
一発録りで出すのはかなり厳しい。失敗できないという気持ちでやると気が滅入る。なので、後編集はある程度は必要と考える。編集で切ればいいやと考えられれば、そのほうが気が楽だし、クオリティがあがる (と思う)。
台本を書かずにとりとめもなく喋ると編集が大変だし、たぶん撮りなおしが頻発することが目に見えているし、どうせ話の流れは考えなければならないので、先に考えるのが一番良い。なお少しでも酔っぱらってると呂律がまわらないうえ、話題が飛んだりして完全にダメ。
ということで、たぶんこれ以上は作業を削れない。
スクリーンキャスト以外で動画を撮る必要がある場合はもっと面倒だけど、自分が作ったものを自分で説明するという限りでは、あまりその必要性は多くはなさそう。動画を撮る場合カメラと音声のセットアップがとても面倒くさい。
そして作業の全体の面倒くささは収録時間が長くなるほど増える。なので、だいたい5〜10分ぐらいを目安にしている。一度録ったものは最低でも編集で数度と通しで数度は見ることになるから、短かければ短いほど良い。
ということで僕のチャンネルです。視聴者ファンディング (投げ銭) も有効にしてますよ!!!!
検索してもいまいち出てこなくて、いつも「前見たのどこだったかな」となるので自分で書いた……
ペーストボードにコピーが行われたときに、JavaScript で何かするというツールを書いた。
競合するソフトウェアがいくつかあると思うけど (dot-clipboard とか)、すぐできそうだし Swift で書かれたのはなさそうということで書いてみた。
ユースケースとしては
というのがあります。
有効にしたらもう一度起動する。
コピーのイベントをキーイベントの Cmd+C を見ることで実現している (設定で変更可能)
あとフォーカスされているアプリとかウィンドウの名前を取得するためにアクセシビリティの機能を使っている
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 のアプリででコピーしたときいい感じにフォーマットするようになる。
require() で ~/.copyhook 以下から外部ファイルを読みこんだりできるようになっている。
console.log() は OS X のシステムログに書きこむことができる。Console.app を起動すれば確認可能。
utils.focusedApplicationBundleId() でフォーカスされているアプリの bundle id を取得できたり、utils.focusedWindowName() でフォーカスされているウィンドウのタイトルを取得できたりする。これにより、処理を場合わけできる。
CopyHook の JS は直接ファイルの読み書きなどができるようになっていないが、utils.system() によって外部プログラムを呼びだせるようにしてある。
なお、書きかえた JS ファイルは次回コピー実行時に自動でリロードされる。
ペーストボードに「コピーが行われた」という Notification (OS X でイベントコールバックしてくれる仕組み) はないので、別の方法でやる必要がある。
ポーリングで常に監視するのがとりあえず嫌だったので Cmd+C をデフォルトにしている。
設定でポーリングにも変更可能。
JS の実行には JavaScriptCore.framework を使っている。OS X 10.9 から使えるようになった framework で、JS の実行環境とネイティブ実行環境をブリッジして使えるようにしてくれる。
JS で書けるようにしておくと、テキストフィルタするようなのを書く場合、とりあえず node で書いてテストして、それをそのまま CopyHook でも使うということができて便利。
伊勢参りしてきた。
伊勢にいく前に名古屋の熱田神宮へ。熱田神宮の御神体は草薙剣 (天叢雲剣)とされていて、これはヤマタノオロチの尻尾から出てきたという、いわゆる三種の神器のひとつである。三種の神器は天孫降臨の際に天照大神がニニギに手渡したといわれるものなので、伊勢神宮内宮の御神体とされる、同じく三種の神器の一つである八咫の鏡と関係が深い。
結構敷地は広かった。また拝殿から本殿はかなり遠く、殆ど近づけない。さすがにかなり立派な神社だった。
名古屋から特急で一気に伊勢市へ。外宮から参拝するのが習わしということで、先に外宮から。
実は伊勢には京都に住んでいたころ日帰りで一度きており、外宮には参拝したことがあるが、それは遷宮前。
当然だけど遷宮して間もない (といっても既に3年目) ので社殿その他が綺麗だった。
正宮はとっくに遷宮が終わっているが、境内の他の神社などはまだ遷宮中のものもあって面白かった。以下は建築中で2つ並んでいる別宮風宮。
また、外宮には「せんぐう館」というミュージアムができていて、これが思いのほか面白かった。特に、外宮の (内宮もだけど) 正宮は普通に参拝してもかなり遠くて屋根の一部しか見えないのだが、せんぐう館の中に実物大の模型として一部が作ってあって、とても良かった。
ほかに建築方法とか、宮大工の技みたいなのもあって良かった。大変おすすめ。
内宮は一泊後、早朝に参拝した (朝早くでないと人が多くなるから)。宿は神宮会館に泊まり、神宮会館は宿泊者向けに早朝参拝のガイドをしてくれるので、これに参加させてもらった。神宮会館は「伊勢神宮崇敬会」という財団法人が運営しており、なんとなくこわいかと思ったが全くそんなことはなかった…… ガイドの人は地元の人のようで、大変わかりやすい解説をしてくださった。結構ライトな説明でそれほど宗教色のある解説ではなかった。
前回の内宮と外宮の柱の一部が宇治橋の鳥居になるとか、御稲御倉 (稲の倉庫だが、主祭神が設定されており、御稲御倉神=宇迦之御魂神=稲荷神) が正宮のほぼ5分の1のサイズの唯一神明造りになっているとか、やっぱりその場で説明してもらえると楽しい。
荒祭宮ももちろん参拝した。
内宮は前回伊勢に来たときは人が多すぎて参拝しなかった (それほど参拝にこだわりがないので)。今回は早朝だったのでスムーズだった。5時から参拝できるみたい。
あと石段を登るとぱっと見、遷宮用の敷地がどこにあるのかよくわからないけど、石段ごともう一つ奥に敷地があるようだった。つまり前回見た石段は奥の石段だったわけだけど、奥には入れないのでそちらの敷地は見ることができない。
内宮の別宮。4つ社殿が並んでいて壮観。遷宮が終わっており全部ピカピカだった。メインの月讀宮が少し大きい。
外宮の別宮。月讀宮と同じく月夜見尊が主祭神。
なんとなく神話上で殆ど出番のない月夜見尊が好きなので行ってみたかった。(出番がないので祭っている神社も非常に少ない)
とりあえず当初行きたかったところは一通り行けてよかった。
神社建築だと神明造がやはりかっこいいと思っていて、パーツとしては特に千木 (斜めに飛びだしている棒の部分) と鰹木 (上にのっている丸太のようなもの) のところが好きである。
全体的なフォルムが直線的で古風かつ力強いところとか、教科書に乗っている「高床式倉庫」ほとんどそのまんまな感じも良い。
そういえば、普通の神社だと金物がだいたい銅製そのままなので、緑色になっているのだけれど、神宮周辺の神社は全て金メッキ(金箔を貼ったり、水銀を使ったり)になっており、豪華だった。
(写っていないが手前に EOS がある。RasPi が写っているウィンドウは Quick Time Player の録画ウィンドウで、リアルタイムに表示している)
前にデジタル一眼レフ (EOS) をウェブカメラ的にとして使うという記事を書いたが、あくまで「ウェブカメラ的」であって OS 的に「ウェブカメラデバイス」として認識させられるわけではなかった。
しかし、500 Can't connect to blog.oldershaw.org:80 というページをふとした拍子に見つけてしまった。自分が試した方法を手順だけ簡単に要約する
要は Camera Live がキモ。
これで準備完了なので、これ以降は任意のビデオアプリケーションを使う。以下は例
カメラをUSBに繋いでいると、カメラ側では露出の変更が一切できなくなる。どうするか? というと、この状態でEOS Utilityを起動して、カメラの遠隔撮影モードの画面を出せば良い。他のアプリケーションが動いていても絞りを変えたりとかは普通にできるようだ。
ちなみに フォーカス調整はフォーカスリングを回せば良いので、USB を繋いでいても可能。
Camera Live は名前が攻めてるが、Canon EDSDK を使っており EOS にしか対応していない。
ただ、試したところ EOS の中でも EOS M では Camera Live のリストには出るものの、Camera Error とでて接続できなかった。EDSDK の Release Note に「In the case of EOS M, remote shooting function is not supported.」と書いてあるので仕様っぽい。
今回上手くいったのは EOS 5D Mark II
解像度については、機種によって異なるようだ。Live View の機能を使ってるので、基本的に HD よりも低い。
なので、1080p で録りたい場合はやはりカメラ側で録画する必要がある。
これにより映像を録画しつつ、かつ音声を Audio Units で処理しながら同時録音が可能となる。
しかも、録画データは直接コンピュータ上にできるので、いちいちカメラからコピーしてくる必要がない。
また、普通のウェブカメラデバイスとして使えるので、ビデオ通話とかにも使える (自分はやらないけど)
というか、キヤノンがオフィシャルにSDK出していたことを初めて知ったよ… しかし日本のサイトにはない… どういうこと
よくわからないけど src/test/java ができなくてであとから作る場合
までやると、Refactor の destination に該当ソースパスのパッケージが出てきて移動できるようになるっぽい……
3番目の手順をやらないと destination に出てこなくて???ってなる
前回のもの、写真だとわかりにくいがいろいろと失敗点があって実用は可能だが満足いくデキとは言えなかった。実はお義母さんからの要望に基いて作っているものなので、あまりひどいデキのものだと申し分けない。
ということで作りなおした。前回の経験を生かし型紙を起こしなおし少し長くつくってる。
また、各所でまち針を慎重に使うようにしたり、もう少し丁寧にやることを心がけたつもり。
全体的にはよくなったが、一部まだ気になるところはある。難しい。
デカ文字A4ジェネレータというのを書いた。
https://github.com/cho45/dekaimoji-a4
いくつか方法があるがピンヘッダのレイアウトを実寸で印刷するツールを書くときに検討した通り、PDF をつくるのが現状では確実と思われる。
その上で、プレビューとの兼ね合いを考えるとさらにいくつか方法がある。
「画像で作ってPDFに貼りつける」という方法は JS に限らず安定して確実な出力ができる。
JS の場合でもスムーズにプレビューできるし出力も簡単。ただし出力サイズが大きい場合、メモリが足りなくなることがある。
また、テキストの選択はできなくなる。
PDF オンリーの場合、ブラウザーがPDFのインライン表示に対応していれば、iframe でプレビューができる。昨今、だいたいのブラウザーで実はpdfが組み込み表示可能なので案外いける。ただしスマフォでは未対応。
jsPDF の場合、単純な図形化なら、2D Context と APIをあわせることができるので、canvasプレビュー、pdf出力がスムーズにできそう。ただしこれはテキストレンダリングしたくなった時点で確実に破綻すると思われる。
[tech] デカい文字をA4で分割して印刷するツールをJSで書いた | Sat, Mar 7. 2015 - 氾濫原 では、実寸サイズを扱うので、多くの場所で mm や cm やら pt などの単位で数値を書きたくなる。
var mm = dpi / 25.4; 10*mm
var mm = 25.4 / dpi; 10/mm
乗算の逆。
function mm (num) { ... }
mm(10) Number.prototype.mm = function () { ... };
10..mm()
しかし JSLint とかは 10..mm みたいな呼びかたをすると怒る。
単純なプロトタイプ拡張と比べ、括弧がいらない。
10..mm
function setDPI (dpi) {
var dpmm = dpi / 25.4;
var pt = dpi / 72;
var units = {
'in' : dpi,
'pt' : pt,
'mm' : dpmm,
'cm' : dpmm * 10,
'm' : dpmm * 1000
};
for (var unit in units) if (units.hasOwnProperty(unit)) (function (factor) {
Object.defineProperty(Number.prototype, unit, {
get: function () {
return this.valueOf() * factor;
}
});
})(units[unit]);
}
setDPI(150);
console.log(10..mm);
console.log(10..cm); しかし JSLint とかは 10..mm みたいな呼びかたをすると怒る。
'10 mm'
とかを数値に変換する形
var UnitConverter = function () { this.init.apply(this, arguments) };
UnitConverter.prototype = {
init : function (opts) {
if (!opts) opts = {};
this.setDPI(opts.dpi || 96);
},
setDPI : function (dpi) {
this.dpi = dpi;
var dpmm = dpi / 25.4;
var pt = dpi / 72;
this.units = {
'in' : dpi,
'pt' : pt,
'mm' : dpmm,
'cm' : dpmm * 10,
'm' : dpmm * 1000
};
var unitNames = [];
for (var key in this.units) if (this.units.hasOwnProperty(key)) {
unitNames.push(key);
}
this.re = new RegExp('([0-9.]+) (' + unitNames.join('|') + ')');
},
unit : function (string) {
if (string.match(new RegExp('^' + this.re.source + '$'))) {
return +RegExp.$1 * this.units[RegExp.$2];
} else {
return null;
}
},
context : function (fun) {
var self = this;
var args = Array.prototype.slice.call(arguments, 1);
fun = eval('(' + fun.toString().replace(new RegExp("'(" + this.re.source + ")'", 'g'), function (_, s) {
return self.unit(s);
}) + ')');
fun.apply(null ,args);
}
}; 文字列化した関数を置換する。みためクロージャなのにクロージャになってないので変数アクセスで混乱する。つくれない。
普通に係数使うのが一番シンプル。除算のほうがかっこいい気がする。ただし演算子の優先順位に気をつかわないとハマる。