まだ必要ないんだけど、作りたいベースで作ってみた。

上の写真は今日の状態のものだが、実はひとつ前のバージョンがある。

布団カバーを作る際にあまった布をフタに使ったのだが、あまりにも本体と色があっていなくてダサかった… 作る途中に気付けよという感じだが、とりあえず仕上げたかったのと、全部おわったら意外と納まるんじゃないかと思ったけど、やっぱダメだった。

なのでやはり別途布を購入しなおしてフタだけ切替なしで作りなおし、元のフタをはずしてつけた。

とりあえず本は必要。本については後述

作業について

裁断でデキの70%が決まる

伸縮性のある布を正確に裁断するのは、それだけでも大変難しい…

オルファ(OLFA) セーフティロータリカッター ゴム L型 156B - オルファ(OLFA)

オルファ(OLFA)

5.0 / 5.0


オルファ(OLFA) カッターマットA2 (450x620x2mm) 159B - オルファ(OLFA)

オルファ(OLFA)

5.0 / 5.0

基本的に裁断バサミよりロータリーカッターが良い。なぜなら布を持ちあげずに裁断できるため。型紙が動きようがない状態で裁断できると正確に切りやすくて精神的に良い。

カッティングマットはA2ぐらいがちょうどいいと思う。A1だとテーブルに乗らなかったりして扱いにくいし、A3だと小さすぎる。A2 でも結構マットを動かす必要はあります。


「水通し」「地なおし」などのキーワードを知っているかいないかでだいぶ変わる。

洗濯するものは裁断前に「水通し」をして予めある程度縮ませてから裁断するか、厳密にあわせる必要がないものは3%〜10%程度大きく裁断する。

水通しは工場で縮める処理をしているものならやる必要がないみたいな話もあるが、売られているもののうちどれがそれなのか判断することができないので、水通しをするほうが安全。ただし一度綺麗に広げて干す必要があるので矮小住宅環境ではクソ面倒。

(今のところの個人的見解では身につける衣類でなければ水通しをせずに5%大きめに作るのが良い気がしている。身につけるものは作る予定がないので水通しやらずに押しきりたい)

「縫い代」は正確にとる

「縫い代」は縫ってひっくり返すと見えなくなるので適当に切ってもええやろと思ってしまうが、これは大きな間違い。

ミシンをかけるときは常に裁ち切り線を基準に縫い代分をオフセットして縫うことになるので、裁ち切りが正確であることと同様に縫い代も正確にとれていないと、当然ミシンの縫い目(=仕上り線)も直線にならない、ということになる。

また、適当に切ってしまうと、複数枚重ねて縫うときに位置をあわせることができなくなる。がんばって仕上がり線を書いても重ねるときにそれであわせることは難しい。マチ針駆使したらできるだろうけど…

裁縫用語

微妙に特殊な「言いまわし」があって混乱することがあった。主観で重要な順に並べた。

かがり

→ 裁断した部分のほつれ防止。基本はジグザグ縫い。「端にジグザグ縫いまたはロックミシンをかける」と書いてある場合すなわちかがるということ。ロックミシンはかがり専用のミシンのことで素人には関係ない。

返し縫い

→ ミシンの文脈では縫いはじめと縫いおわりで逆方向に少し縫うこと。普通は返し縫い機能があるので簡単にできる。手縫いの場合は「縫いかた」の種類でミシンの返し縫いとは関係がない。

返し縫いは縫いはじめに針を置いて、少し普通にすすめて、戻って、もう一度すすむ。つまり返し縫い部分は3回針が刺さる。

表あわせ

→ 布の表同士をあわせること。最後にひっくり返すので裏面を見ながらミシンをかけることが多い。

ステッチ

→ 2つの布を縫いあわせる機能がない縫い目のことっぽい? 飾り・強度のためにかけるミシンのよう。「ミシンをかける」は逆に縫いあわせるという意味を含むようだ。使いわけてる人がいるけど、正確に使いわけてない場合があってややこしい。「なんとなく縫う」ぐらいのニュアンスがある。

仕上がり線

→ 縫う線。この線に縫い代を加えると裁ち切り線になる。つまり普通はこの線で裁断しない。

縫い代

→ 縫うためにつける 1cm ぐらいの領域。

縫い代を割る

→ 縫ったあと、2枚の布の縫い代がくっついているが、これをそれぞれの布の方向に開いて固定すること(アイロンをかけたりする)

裁ち切り

型紙に「裁ち切り」と書いてある場合、縫い代をつけないという。仕上がり線がすなわち裁ち切り線になる。

切替

→ 途中で別の布 (または同じ布) を繋ぐこと。途中で柄を変えたいときにやる。

パターン

→ 型紙のこと

レシピ

→ 型紙も含めた製作の手順のこと

コード (Cord)

→ 紐のこと。

地直し

→ 買ってきた布が歪んでいることがあるので (そのまま作ると洗濯したときに歪みが表面化する) それを直すこと。最近の布の品質ならやる必要ないという話もある

バイアステープ

→ 斜めに裁断されたテープ状の生地のことをバイアステープというらしい。少し伸縮性があり縁取りとかに使う

返し口

→ ひっくり返すために縫い残す部分のこと。これがないとひっくり返せない。最後は手縫いで返し口を閉じるか、周囲にステッチをかけて強制的に閉じる。

目が落ちる

→ ミシンの針が布地以外のところに落ちて空振りすること。特殊なことではなく、特に布端をジグザグ縫いでかがるときは片側はほぼ目が落ちる位置になる。

パイピング

→ 布端をバイアステープ処理すること

イセる

→ 寄せ集める。縮める。英語で gather の意味

布の種類

名前は編みかたの分類なので、実際は使用される糸の太さによって厚さは変わる

ブロード

よくあるプリントされたりしていて表面がつるつるしている、比較的薄い生地。

私見:薄いので使いどころ次第でちょっと安っぽくなる

オックス

少し厚手で編み目が明確なやつ。丈夫。キャンバスよりは薄い。(10番オックスというのがよく使われるらしい)

私見:適度な光沢があって高級感があり、汎用性が高く感じる。手触りも布!って感じで良い。

シーチング

本来シーツ用の生地でちょっとざらざらとした厚手の生地。

私見:オックスの下位互換みたいな感じがする。ちょっと安っぽいというか、荒っぽい風合いがある。

キャンバス (帆布)

厚手でかたくかなり丈夫。カバンとかに良く使われる。(11番が一番薄いが、典型的なオックスと比べるとこれでもかなり厚い生地)

キルティング

2枚の布の中に綿が入っていて斜めに縫ってあるやつ。やわらかいが丈夫。ブロードのキルティング・オックスのキルティングとかデニムのキルティングとか、いろいろある。2枚生地を使ってる分高価だけど、手軽に作れるので便利。高価といっても2枚生地を買うよりはだいぶ安い。

私見:手軽で便利だけど、できあがりがまさに小学生とかが持ってそう!という感じになる。良く言うと手作り感がでる。

きれいに縫うための基礎の基礎 - 水野 佳子

水野 佳子

5.0 / 5.0

かなり細かく「縫いかた」について書いてある。服を作らない場合必要ない技術もあるけど一通り丁寧に書いてあってよかった。

いちばんよくわかる かんたんかわいい通園通学グッズ -

5.0 / 5.0

簡単な作例がたくさん載ってて参考になった。作りかたほぼいっしょだけどサイズだけ違うみたいなケースが結構あるなという発見がある。

  1. トップ
  2. tech
  3. 本気でなくとも裁縫するなら絶対に知る必要があること

デカ文字A4ジェネレータというのを書いた。

https://github.com/cho45/dekaimoji-a4

原寸印刷について

いくつか方法があるがピンヘッダのレイアウトを実寸で印刷するツールを書くときに検討した通り、PDF をつくるのが現状では確実と思われる。

その上で、プレビューとの兼ね合いを考えるとさらにいくつか方法がある。

canvas で作った画像を PDF に貼る

「画像で作ってPDFに貼りつける」という方法は JS に限らず安定して確実な出力ができる。

JS の場合でもスムーズにプレビューできるし出力も簡単。ただし出力サイズが大きい場合、メモリが足りなくなることがある。

また、テキストの選択はできなくなる。

PDF オンリー PDF プレビュー

PDF オンリーの場合、ブラウザーがPDFのインライン表示に対応していれば、iframe でプレビューができる。昨今、だいたいのブラウザーで実はpdfが組み込み表示可能なので案外いける。ただしスマフォでは未対応。

2D Context の API にあわせる

jsPDF の場合、単純な図形化なら、2D Context と APIをあわせることができるので、canvasプレビュー、pdf出力がスムーズにできそう。ただしこれはテキストレンダリングしたくなった時点で確実に破綻すると思われる。

  1. トップ
  2. tech
  3. デカい文字をA4で分割して印刷するツールをJSで書いた

404 Not Found を参考につくった。まちがえてキルティングが表裏逆になってしまった。

作ってみたけどキルティングは 14x36 ぐらいでもいいかな

[tech] デカい文字をA4で分割して印刷するツールをJSで書いた | Sat, Mar 7. 2015 - 氾濫原 では、実寸サイズを扱うので、多くの場所で mm や cm やら pt などの単位で数値を書きたくなる。

いろんな方法

mm を係数にして毎回乗算する方法

var mm = dpi / 25.4;

10*mm

mm を係数にして毎回除算する方法

var mm = 25.4 / dpi;

10/mm

乗算の逆。

変換を関数にする方法

function mm (num) { ... }

mm(10)

Number のプロトタイプ拡張

Number.prototype.mm = function () { ... };

10..mm()


しかし JSLint とかは 10..mm みたいな呼びかたをすると怒る。

Number のアクセサディスクリプタ

単純なプロトタイプ拡張と比べ、括弧がいらない。

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);
	}
};

文字列化した関数を置換する。みためクロージャなのにクロージャになってないので変数アクセスで混乱する。つくれない。

結論

普通に係数使うのが一番シンプル。除算のほうがかっこいい気がする。ただし演算子の優先順位に気をつかわないとハマる。

  1. トップ
  2. tech
  3. JS 数値リテラルに単位をつけたい

前回のもの、写真だとわかりにくいがいろいろと失敗点があって実用は可能だが満足いくデキとは言えなかった。実はお義母さんからの要望に基いて作っているものなので、あまりひどいデキのものだと申し分けない。

ということで作りなおした。前回の経験を生かし型紙を起こしなおし少し長くつくってる。

また、各所でまち針を慎重に使うようにしたり、もう少し丁寧にやることを心がけたつもり。

全体的にはよくなったが、一部まだ気になるところはある。難しい。

よくわからないけど src/test/java ができなくてであとから作る場合

  1. src/test/java のディレクトリをプロジェクトツリーから New → Directory して作成
  2. java ディレクトリを右クリックして Mark Directory As → Test Sources Root に設定する
  3. java ディレクトリを右クリックして New → Package して使う名前空間のディレクトリを掘っておく

までやると、Refactor の destination に該当ソースパスのパッケージが出てきて移動できるようになるっぽい……

3番目の手順をやらないと destination に出てこなくて???ってなる

  1. トップ
  2. tech
  3. IntelliJ IDEA で src/test/java がないところに新規でつくる方法

(写っていないが手前に EOS がある。RasPi が写っているウィンドウは Quick Time Player の録画ウィンドウで、リアルタイムに表示している)

前にデジタル一眼レフ (EOS) をウェブカメラ的にとして使うという記事を書いたが、あくまで「ウェブカメラ的」であって OS 的に「ウェブカメラデバイス」として認識させられるわけではなかった。

しかし、500 Can't connect to blog.oldershaw.org:80 というページをふとした拍子に見つけてしまった。自分が試した方法を手順だけ簡単に要約する

インストール

要は Camera Live がキモ。

  1. Camera Live を入れる https://github.com/v002/v002-Camera-Live
    • EOS カメラを Syphon というアプリケーション間で映像データをやりとりする形に変換する
  2. CamTwist 3.0 BETA をいれる
    • 内蔵で Syphon サポートがあるので 3.0 を使うのが早い

使用方法

  1. Camera Live を起動し、カメラをUSBで繋いで電源を入れる。
  2. Camera Live のリストにカメラ名がでるので選択すると Active になる
  3. CamTwist を起動する
  4. Syphon を video source に選び、Setting の Syphon Server を Camera Live にする

これで準備完了なので、これ以降は任意のビデオアプリケーションを使う。以下は例

  1. Quick Timer Player を起動し、録画元に CamTwist を選ぶと表示がでる。
    • CamTwist が候補にでない場合、Quick Time Player を再起動する。
  2. オーディオも適切に設定すれば同時録画可能 (ただし多少遅延あり)

Tips

カメラを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出していたことを初めて知ったよ… しかし日本のサイトにはない… どういうこと

Canon デジタル一眼レフカメラ EOS 5D MarkII ボディ - キヤノン

キヤノン

5.0 / 5.0

  1. トップ
  2. tech
  3. キヤノン EOS をウェブカメラとして使う。

伊勢参りしてきた。

熱田神宮

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


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

外宮

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



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

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

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

以下は土宮

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

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

内宮

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

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

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

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

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

月讀宮

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

月夜見宮

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

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

まとめ

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

神明造

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

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

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

ペーストボードにコピーが行われたときに、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 というペーストボードの中身をいじるツールを作った

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

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

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

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

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

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

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

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

なので、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

続くか

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

今のところ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一方で欠点は

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

自作の利点と欠点

利点

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

欠点

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

つまり

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

それでも自作するか

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

  1. トップ
  2. tech
  3. ブログシステムは自作すべきか? ブログサービス VS 自作システム

IQ信号からは、ベクトルの絶対値をとることで振幅が得られ、角度を求めることで atan(Q/I) 位相を得られる

その上で得られた位相を微分することで、周波数を求められる。

  1. トップ
  2. tech
  3. I/Q phase (直交信号) から周波数を求める

JavaScript だと、デコーダだけ、エンコーダだけ、というのはあったり、GF(2^8) オンリーなものはあったりするんだけど、汎用的なのがなくて悲しかった。

Zxing (バーコード読めるアプリ) の実装を見てみたら、読みやすい上で汎用的な実装だったのでリードソロモン部分だけ Java → JavaScript の移植を行った。

https://github.com/cho45/reedsolomon.js

他の目的があって移植してたけど、目的がなかなか達成できないのでとりあえずこれだけ npm にあげた。

久し振りに単純な移植作業をやった。特殊な依存が特になくほぼ計算なので

  • 型宣言を全部 var に
  • インスタンス変数の参照に this. をつける
  • System.arraycopy() を TypedArray#set() に置き換える

ぐらいを何も考えずに機械的に行なったい、テストもまるごと Zxing のものをパクって移植した。

覚書

(2が底なら?) 任意のガロア域を使えるようになっており、いろんな用途に使えそう。

new GenericGF(primitive, size, b) で作れるが、primitive polynomial (原始多項式) はビットで表現されている。

x^8 + x^5 + x^3 + x^2 + 1 という多項式なら、8 5 3 2 0 bit が立ち 100101101 となる。0ビット目は +1 を表現してる。これは一般的な表現方法らしく、このように表わされた状態を数字として 301 としたり 0x12d としたりするみたいだ。

http://octave-online.net/ で primpoly(6, 'all') とかやれば原始多項式を全部求められる。

あと、JT65 (6bit) は AZTEC_DATA_6 と同じっぽい。

  1. トップ
  2. tech
  3. JavaScript で書かれたリードソロモン符号のエンコーダ・デコーダ