Kazuho's Weblog: The JSON SQL Injection Vulnerability について。元記事をはっちゃめっちゃに要約すると

  • SQL::Maker にユーザから受けとったデコード済み JSON をそのまま突っ込むと SQL インジェクションになる場合がある
  • SQL::Maker 側でそういったことが起こらないように strict オプションをつけたから、できればそっち使え
  • 別に SQL::Maker に限らないから気をつけろ

という話っぽい。本来であればユーザ入力をタイプチェックをすべきだけど、クエリビルダレベルでも、脆弱性にならないようにもうちょっと考慮してもいいよねという趣旨かな…

strict モードは非互換なので、既存のコードが動かなくなる可能性があるようです。

Teng での対応

Teng を使っているとデフォルトで SQL::Maker がクエリビルダとして使われるので、同じように危険な場合があります。Teng 0.24 から、クエリビルダのコンストラクタにオプションを渡せるようになったので、以下のように書くと strict モードになります。

my $teng = My::DB->new({
    ...
    sql_builder_args => { strict => 1 }
});

Teng 0.23 以前の場合、このオプションがないので、以下のように自分で sql_builder に SQL::Maker のインスタンスを作って渡す必要があります。

my $teng = My::DB->new({
    ...
    sql_builder => SQL::Maker->new(driver => 'SQLite', strict => 1);
});
既に使っている場合

strict モードつきにしてみて問題なく動くならそのほうがいいですね。非常に単純なクエリは strict モードにしても変わりませんから、

$teng->search('foo', { id => $id })

みたいなクエリしか書いたことねーぞ! って場合、何も考えず strict を有効にして試してみると今後比較的穏かな気分でコードを書けることになります。

そうではない場合でも、あまりに大量にクエリビルダで複雑なことをしているというわけではない限り、 strict を有効にしてコードを書きかえ、検証しなおすべきでしょう。

さらに、どうせコード書きかえるなら根本的に入力のタイプチェックを行うのも考えたほうがいいと思います。


どうしても strict モードを有効にしたくないぐらい複雑にクエリビルダを使いこなしている場合かつ、脆弱性になりそうなコードを書いた覚えがあってヤバいぞという場合、ユーザから受けとる JSON などの構造化データを復号化するところで、一括して再帰的に全ての HashRef, ArrayRef, ScalarRef などを適当に bless することで、ある種の「汚染された」フラグとし、少なくとも SQL インジェクションについては防ぐことができると期待できます。

これは、SQL::Maker が strict オプションが入っていなくても、元から bless された構造化データについては文字列化が走るような挙動になっているためです。

ただ、これはこれでやはり全体的に影響する変更になるので、検証がstrict を入れる場合と同じように大変であり、コードを書きかえる手間の問題ないし、SQL インジェクションのリスクとほかのところで問題がでるリスクを比べた場合に、どうしてもとる1つの手段であって、基本は strict を有効にするように頑張ったほうが生産的かつ安全だと考えられます。

ユーザが構造化データを作れること

ウェブアプリケーション開発者は、普通のHTMLフォームが文字列しか送信できないという、歴史的経緯により無意識に、危険なデータは文字列でしかこないとなんとなく思っている。なのでユーザーが構造化データをつくって送れること自体がうっかり脅威になりえることがある。この手の問題は Perl に限らず Rails でも発生してる。

昨今では JSON をリクエストボディーにしたり、クエリ文字列にルールを与えて (例えば foo[bar]=1&foo[baz]=2 みたいな) 構造化データを受けとれるようにしたりといったことが行われる。これにより、信頼できない構造化データというのが生まれている。

単純なデータ構造でクエリを組み立てるというのは、それ自体が危険なAPI設計といえ、また、入力のタイプチェックをすれば防げる問題なので、それを強制するフレームワークになっているほうが良い、という学びを得られた。

  1. トップ
  2. tech
  3. ユーザ由来の構造化データによるSQLインジェクション

そういえば最近8年前に作って放置していたヘッドフォンアンプを修理して使いはじめた。ネットで回路図が公開されていた SAITAMA なんちゃらみたいな名前がついたオペアンプ+ダイヤモンドバッファのスタンダードな回路のもので、いつのまにか片方聞こえなくなって使わなくなった、みたいな感じだったと思う。(当時の日記のエントリにリンクをはろうと思ったが読んでみたらキモ恥ずかしすぎるのでやめた…)

ちゃんと調べた感じ、単に入力の接触不良っぽかったので、とりあえずそれだけ直したら動いたんだけど、当時の自分のスキルレベルが異常に低くく (今も低いけど、今以上に)、アースまわりのワイヤリングに明らかにまずい部分があり、ちょっと試行錯誤して多少マシにした。

電源トランスを内蔵する仕様的に、当時はハムノイズが完全に消えなかったんだけど、アースまわりを常識的に直したら普通に皆無になった。8年経過の間に特にアナログ電子回路についてスキル上げした覚えがないけど、なんとなくベースレベルで解決した感じだった。

「ヘッドフォンアンプとか昔なんとなく作ったけど、意味あったのかなあ」と思って改めて使ってみたけど、音量あげたときの歪みっぽいものがなくなって気持ち良い感じにはなったので意味あるかもしれない。音量小さいなら意味ないしやっぱ意味ないのかもしれない。

しばしば、ただのサイン波を適当な周波数で出したくなると思いますが、ググってもいまいち一発で自分の欲しいものがでてこないので作りました。

  • サイン波
  • 矩形波
  • ノコギリ波
  • 三角波
  • ホワイトノイズ
  • ピンクノイズ
  • ブラウンノイズ

あたりを自由に組合せて出せます。(当然スマフォでも動く)

github https://github.com/cho45/WebAudio-Signal-Generator

  1. トップ
  2. tech
  3. WebAudio シグナルジェネレーター

500 Can't connect to stackoverflow.com:443 (certificate verify failed) の回答であったやつだけど、String.fromCharCode が複数文字を引数にできることを知った。String.fromCharCode、なぜか1文字しか渡せないと思いこんでいたので、なんとなくびっくりした。

console.log(String.fromCharCode.apply(null, [97, 98, 99]));
//=> "abc"

つまりこれは ArrayBuffer とかを String に変換するときにとても簡単に書ける。以下の例は 8bit のビューを作っているが、元記事のように必要に応じて 16bit のビューを作って渡すこともできる。

var buffer = new ArrayBuffer(10);
for (var i = 0; i < buffer.byteLength; i++) {
	buffer[i] = 97 + i;
}
console.log(String.fromCharCode.apply(null, new Uint8Array(buffer)));
//=> "abcdefghij"
  1. トップ
  2. tech
  3. JavaScript ArrayBuffer -> String 変換

あんまり日本語の文書だと見ない気がするけど、英語圏由来の文書だとしばしばみるような気がする Voltage Balun, Current Balun ってなんなのだろうと思って調べたけど、つまり以下のような話だった

  • 電圧バラン (Voltage Balun)
    • トランスとして働く (同時にインピーダンス変換が可能)
    • 強制バラン
  • 電流バラン (Current Balun)
    • コモンモードチョークフィルタとして働く (電圧は変更しない)
    • フロートバラン・ソーターバランとも呼ばれる

基本、電流バランで十分なら電流バランのほうが効率が良く、インピーダンスマッチも同時にしたいなら電圧バランを使う、でいいのかな。

  1. トップ
  2. tech
  3. 電圧バラン・電流バラン
  1. トップ
  2. ham
  3. 電圧バラン・電流バラン

買ってから1年とちょっと経過したが、U04 という乾燥フィルター掃除エラーが頻発し、フィルター周辺が結露するようになった。当然洗濯物がなかなか乾かない、というかエラーで止まるので乾燥がやりなおしになる。うちには物干し竿も洗濯バサミも存在していないので、死活問題

一通り念入りに、排水フィルタまでもを掃除してみたが改善されず、乾燥フィルタの奥が固定なので洗えないなーと思いつつ、ググってみると、メーカー修理すると脱着式になることがあるらしい。よくくるクレームっぽい。

ということですぐに修理を依頼して、来てもらったら、脱着式になった。丁寧にカラー両面の説明書までついている。乾燥時の騒音が増える?っぽいけど、乾かないことには仕方ないし、掃除しやすくなったので良かったと思う。とりあえず様子を見る。


ちなみに1年経過でメーカー保証切れだったけど、購入店 (ケーズデンキ) では価格に5年分の延長保証が含まれているので、支払いはしてない。事前に乾燥まわりで故障するであろうことが予測できたので、延長保証があるところを選んでたのは正解だった。

ケーズデンキを一度通してからの修理だったけど、今回かなりスムーズにいった。ケーズデンキの修理電話にかけると、購入時の電話番号を訊かれるので、それに答えれば購入履歴から保証情報もとってくれるみたいで、保証書は見せる必要がなく、その後はメーカー(パナソニック)から、日曜だったが当日中にコールバックがあった (とはいえ、電話をとれなかった)。特に待ちとかもなく、スムーズに終わってよかった。欲を言えば電話だと面倒なのでメールにしてほしい。


あと、メーカー修理の人曰く、洗濯漕クリーナーは、半分ずつ頻度をあげてやったほうがいいらしい。洗濯機が自動判定して余分な洗濯漕クリーナーを排水してしまうことがあるとのことだった。

あと、洗濯機入口の2mm〜4mm程度の狭い隙間から乾燥の風がでているらしく、そこも詰まらないように金属のクシとかで1年を目安に掃除したほうがいいらしい。

 -

4.0 / 5.0

Chrome App という、Chrome Extension の延長上にあるスタンドアロンアプリを作れる仕組みがある。これは、しばしば出てくる HTML + JavaScript でスタンドアロンアプリを作れるやつの Chrome 版にあたる。

結構いろいろとAPIが整備されていて面白いんだけど、いまいちテストを書く方法がわからなくていろいろ試した。Chrome の API を使っている場合、どうしても Chrome のコンテキストで実行する必要があり、なかなか面倒くさい。

protractor (webdriver-js ラッパ) を使う

protractor は Angular.JS 用のエンドトゥーエンドテストフレームワークで、いろいろ環境を一発でつくるのが便利なので使ってる。Angular.JS も使ってるから丁度いい。

コマンドラインから Chrome App を起動すると、まず1つ普通のChromeのウィンドウが開き、次にアプリケーションのウィンドウが開くという挙動をする。なので、アプリケーションのウィンドウが起動するのを待って、そっちにスイッチする必要がある。

403 Forbidden このあたりに書いてあるのをなおして、以下のようなのを書いた。

function switchToAppWindow (nth) {
	function _switchToAppWindow (n) {
		if (n <= 0) throw "failed to switch to app window";

		browser.driver.getAllWindowHandles().then(function (handles) {
			if (handles.length <= nth) {
				_switchToAppWindow(n--);
			} else {
				browser.driver.switchTo().window(handles[nth]);
			}
		});
	}
	_switchToAppWindow(1000);
}

switchToAppWindow(1) で2番目に生成されたウィンドウにスイッチできる。

これで、Angular.JS レベルでの E2E テストは書けるようになる

Unit テストを書く

しかし、E2E テストだと Chrome 向けに Chrome 専用の API を使ったライブラリのテストが書きにくいので、普通の Unit Test みたいなのも書きたくなる。

いろいろ試したけど、結局以下のようにした。

  • テスト用の .html を用意する
  • E2E テスト用のスクリプトから、executeScript でテスト用の .html を開き、テストを実行する

Jasmine を読みこませてテストを実行させ、自力でテスト結果を取得して表示してる。

ただ、罠があって、Jasmine が eval を使っててそのままだと Content Security Policy にひっかかって実行できない。これはmanifest.json に sandbox 指定することでも解決するけど、これだと本来の目的の API がたぶん使えないので、jasmine を書きかえて治す必要がある。global オブジェクトを取得しようとして eval を使っているので (なんで?) そこだけ自分で変えたら動く (Edge バージョンだと eval するコードがないので普通に動きそう)。

スケルトンプロジェクト

をつくった

  1. トップ
  2. tech
  3. Chrome App をテストする

Chrome App は、chrome.usb という API を通じて低レベルなUSBデバイスドライバをJavaScriptで書くことが可能になっている。chrome.usb は libusb 相当の API を提供している。

つまり、自分で作った USB デバイスと通信して、ブラウザ(といっても App だけど)からそれのI/Oを操作でき、LED を HTML+CSS+JS で UI を作って操作したり、ミサイルも JavaScript で飛ばせる。

そこで、AVR (200円ぐらいのワンチップマイコン) とその上で動くソフトウェアUSB実装である V-USB でカスタムデバイスを作成し、Chrome App から呼んでみた。

デバイス側

だいぶ前に実験した結果、Mac OS においては HID デバイスとしてUSBデバイスを作ると OS の管理下におかれ、libusb などからアクセスする手段が殆どなくなってしまうことがわかっていた。libhid 的なものがあればいいのだけれど、すくなくともまともにメンテされているのは当時見当らなかったので諦めた。

今回は教訓をいかして最初からHIDではないカスタムクラスのUSBデバイスにすることとした。

デバイス側の実装及び V-USB の設定ファイルは以下の通り

AVR ATmega168、16MHz で動かして試している。

HID にしなくともデバイス側の実装はあまり大差ない。

USB_CFG_DEVICE_CLASS と USB_CFG_INTERFACE_CLASS を 0xff (vendor) にしておかないと claim_interface に失敗したので忘れずに変えておく必要がありそう。

ホスト側

ホスト側では、まず libusb + ruby における実装を書いて試した。

interrupt_transfer はブロックをとれるみたいなのだが、うまく呼ばれなかったので深追いせず普通に呼んでいる。

libusb を使うにしても USB のプロトコルの知識が必要になるのが面倒


そして Chrome App の実装も書いた。主な実装箇所は以下

最初どうしても openDevice が成功せず途方にくれていたが、Chrome 自体を再起動することで成功するようになった。諦めなくてよかった。

ちなみに公式?にある usb のサンプルは API が最新に追従していないので参考にしないほうがいい。

USB プロトコルまわり

知っておかなければいけないこと

  • USB は基本的に片方向の通信
    • CONTROL 転送は1度のトランザクションが双方向で Stop-and-wait ARQ みたいな感じになってる
    • 必ずホストから先に通信が始まる (つまりデバイス側からデータを push することはできない)
  • USB には転送方法がいくつかある・それぞれ再送があったりなかったりするので必要に応じて使う
    • CONTROL 転送
    • ISOCHRONOUS 転送
    • BULK 転送
    • INTERRUPT 転送


参照

  1. トップ
  2. tech
  3. Chrome App で USB デバイス (AVR V-USB) にアクセスする

直近の Mac OS X Mavericks アップデートの直後あたりから (これが直接の原因かはわからないけど)、例え HID デバイスではなくても chrome.usb を単体で動かすことができなくなった。

今まではデバイス接続後に Chrome 全体を再起動することで openDevice が成功するという挙動だったのだが、今ではデバイス接続後に他の libusb を使ったプログラムを走らせて一旦 device を OS に認識させ、そのプログラムを終了し Chrome を起動する、という手順が必要になった。

つまり単体で再起動を繰替えしたりしてなんとか動かすということが不可能になり外部プログラムへ依存が必要になった。Chrome はどのようなコンテキストでも外部プログラムを実行することはできないので、打つ手はなくなった。

chromium のイシュートラッカーを usb 関係で検索してみると


あたりが関係していそう。 Canary を入れたくないので 35.0.1916.153 でしか試してない。stable で動かないものは「ない」と同じ。


このほか以下のようなバグがありそう

  • コントロール転送で8バイト未満をデバイスから返すと、データが化ける (こちらから送ったリクエストのバイナリ列になってしまう。謎)
  • インタラプト転送でずっとレスポンスしないでいると、デバイスにアクセスできなくなる。定期的に必ずなにか返答しないとだめ。

それとバグではないが、コントロール転送を out する場合、何も data を送りたくなくても、data : new ArrayBuffer(0) を渡さないと実行されない。罠。

前までできなかったと思うんだけど、比較的簡単にできるようになっていた。

QuickTime Player に「ファイル」→「新規画面収録」というのがあり、これを使うと音声入力を含めてスクリーンキャストを録画できる。

外部カメラも同時にとる場合は「ファイル」→「新規ムービー収録」を選択するとカメラの状態が画面にでるようになる。この状態でも「新規画面収録」を行うことができ、カメラとスクリーンを同時に録画可能になっている。

収録しおわったら「編集」→「トリム」で不要な前後も簡単に削除できるので、あせって録画する必要はない。

試しに録画したもの


一つ欠点があって、できるあがるファイルが .mov なので、どっかにアップロードするなら

ffmpeg -i input.mov output.mp4

とか適当にしたほうがいいっぽい。

  1. トップ
  2. tech
  3. Mac で外部カメラとスクリーン録画を同時にやる (カメラ+スクリーンキャスト)

去年AVR で USB 接続の PC キーヤーを作るということをやったのだけど、結局ちゃんと形にはせず放置してしまっていた。最近なんとなく自分の中で PC キーイングの機運が高まってきたので、まじめに安定したものを作ろうと頑張って、ある程度成果がでてきた。

当然似たようなデバイスは既にあるので、改めて作る必要はないんだけど、自分で作れそうなものは、一回ぐらい自分で作りたいものですね。

ハードウェア

安定して動くように試行錯誤した結果、USB のデータラインに 100pF のパスコン (ノイズ対策)、リセットピンを外部プルアップ (USB のデータラインに電流が多く流れて、リセットされやすくなるので)、USB ラインのツェナーダイオードをちゃんと計ってから使う、18MHz の水晶 (CRCチェック用) とかになった。あとはもともとと同じだと思う。

ファームウェア

USB まわりを割と丁寧に実装しなおした。UI との整合性をとるため、機能をちょいちょい足している。usbFunctionWrite で -1 を返すと STALL の意味になるとか、V-USB のドキュメントをよく読んだほうがいい。

ソフトウェア

ドライバをカーネルレベルで書くのはデバッグが大変で嫌なので、最初から libusb 関係のものを使うことしか考えてなかった。最初は Chrome App から直接 chrome.usb で扱おうとしたのだが、いろいろあってやめて、ruby + libusb + em-websocket で WebSocket サーバを書いて中継している。

libusb の同期的インターフェイスは、実際のところ非同期インターフェイスのラッパーになっており、マルチスレッド環境で使うとレースコンディションが発生することがある。libusb のドキュメントにいろいろ書いてあるが、面倒なので ruby 側で mutex のロックをかけるようにしたら解決したので深く追ってない。

また、ホットプラグ対応もなんか刺さったりしてつらいのでやめて、デバイスが接続されていないときは定期的にポーリングするというクソっぽいけど正確に動く実装にした。

インターフェイス

そして WebSocket で通信するページをペライチで作って試してている。全部込みで動画にしてみた。

今後

まずは無闇にストールしたり、刺さったりしないという基本的な部分で安定することを目指して頑張った。「もう無理では……」と思ったこともあったけど、いつのまにか結構安定した。ただ、実際の運用まで行ってないので、インターフェアにどれぐらい耐性があるかはわかってない。試験電波を出してオシロで信号ラインを見た感じだと大丈夫そうだけど、よくわからない。

手持ちのユニバーサル基板に組んだので、作ってみたらケースを含めちょっと大きくなってしまった。内容的にはたいしたことがないので、フリスクケースに収まるような基板を作ってみたい。

あとは、ログツールとの連携をしたいと思っているけど、ログツールを作りなおしているので、まだまだ先になりそう。

  1. トップ
  2. tech
  3. 自作 USB CW キーイングデバイスを作る
  1. トップ
  2. ham
  3. 自作 USB CW キーイングデバイスを作る

ただ聴くだけのモールス練習に若干飽きてきて、MorseRunner というのを試してみたら、おもしろかった。Mac でも homebrew の wine で普通に動いてくれる。

コンテストを想定した練習ソフトみたいな感じになっていて、F1 で CQ を出して、呼んでくる局のコールサインを聴きとって入力し、RET を押すと、自動的に相手局にコンテストナンバーが送られ、相手局が返してくるコンテストナンバーを聴きとって入力したら1局終わり。

聴きとれないときは F7 押したりするともう一度打ってくれたりする。結構実際に交信しているみたいで楽しい。

以下の画像は HST モードで1時間やってみたもの。ぶっちゃけ15分ぐらいから辛くて早く終わってほしい感じになる。普段は 10分のシングルコールかパイルアップで遊んでる。シングルコールはあんまり頭使わないので、だんだん眠くなるけど、聴きとれるというのが楽しい。パイルアップは、とにかく2文字とって訊き返すというのが大事でおもしろい。

シングルコールがただ聴くだけだから一番局数は稼げる?と思うけど、自分の場合 30wpm でやると、だいたい10分で30局超えたらいいみたいな感じだった。しかし S と H の区別がはっきりつけられないので厳しい気持ちになることがある。

  1. トップ
  2. tech
  3. MorseRunner
  1. トップ
  2. ham
  3. MorseRunner

スクリーンキャストとカメラの同時録画 の動画を撮ったときは Mac 内蔵のカメラを使ったので、自由にカメラを動かせず難儀した。ウェブカメラが欲しいなーと思ったけど、よく考えたら優秀なカメラが既にあるので、利用できないかと考えた。

結論からいうと、直接ウェブカメラとして使うことは簡単にはできない。なので、

  • EOS Utility でライブビュー撮影モードにする (PC にカメラの画像がリアルタイムに反映される)
  • それをスクリーンキャスト用のツールでカメラデバイスにする

という方法をとる必要がある。


スクリーンキャストとカメラの同時録画をしたいというだけなら、単に EOS Utility のウィンドウを直接録画したらいいので、簡単。ただ、どうしてもちょっと映像が遅れるので、それを許容できる場合にだけ使える。

  1. トップ
  2. tech
  3. デジタル一眼レフ (EOS) をウェブカメラ的にとして使う

ハルロック(1) (モーニング KC) - 西餅

西餅

5.0 / 5.0

うっかりウェブに公開されているやつを読んでしまったら面白かったので買ってしまった。最近電子工作にハマってるのでタイムリーだった。

題材が電子工作で、そこらかしこに流行りワードがちらばっているけど、そういうのよりは主人公の女子大生が狂ってるのを楽しむ感じで、ゲラゲラ笑える。


なんともいえないのは、最初おじさん先生から PIC が出てくるんだけど、卒業すると登場するのが Arduino やら Raspberry Pi やら AVR になっていくので愉快な感じ。

自分も主人公ほどではないにせよ、小さいときに分解魔だったので (分解したからといって原理がわかるわけではない) そのへんも共感できた。

name (flash/sram) cost

USB 対応

  • ATmega32u2 (32k/1k) 400円
  • AT90USB162 (16k/0.5k) 300円
  • 最大16MHz
  • USB ホストにもなれる
  • 12Mbps 対応
  • 外付け部品が少し簡単
  • 表面実装品しかない

V-USB

  • ATmega328p (32k/2k) 250円
  • ATmega168p (16k/1k) 200円
  • ATTiny2313 (2k/128) 150円
  • 最大20MHz (5V動作時)
  • USBスレーブにしかなれない
  • ファームウェアコードにいくらか制限あり (割込み頻度とか)
  • ドライバが GPL
  • DIPあり

感想

  • V-USB はファームウェアを GPL にするか、ライセンス購入する必要があるが、個人の趣味レベルではどうでもいい
  • 価格の絶対差はそれほどでもないが、同じ金額で1個買えるか、2個買えるかと考えるとだいぶ違いを感じる
  • よりスマートなのは USB 対応のを使うことだと思うが、見た目的にはどっちもワンチップで完結する
  • USB 対応品は、USB 周辺については 3.3V で動いておりレギュレータを内蔵している。V-USB は高いクロックで動かそうとするとVCCを5Vにせざるを得なくて、そこらへん泥臭くなってしまう

AngularJS には $qっていう promise の枠組みがあるので、使っておくといいこと (ビューが自動的に更新されるだけだけど) がある。フレームワーク組込みの仕組みがあるのに別途 Deferred の仕組み、しかも thenable(笑) じゃない(笑) JSDeferred を読むのもバカにされると思うので、以下のように JSDeferred から Angular $q へ置き換える方法を記す。

基本

JSDeferred における global な next() 関数を $q.when().then() に置き換え、Deferred#next を then() に置き換えればだいたい動く

next(function () {
    alert(1);
    return next(function () {
        alert(2);
    }).
    next(function () {
        alert(3);
    });
}).
next(function () {
    alert(4);
});

こういうのを、こう

$q.when().then(function () {
    alert(1);
    return $q.when().then(function () {
        alert(2);
    }).
    then(function () {
        alert(3);
    });
}).
then(function () {
    alert(4);
});

parallel() は?

$q.all() を使え

loop() は?

頑張って書く。いろいろやりかたはあると思うけど、例えばこう

$q.when().then(function () {
	var list = [1, 2, 3], sum = 0;
	return $q.when().then(function loop () {
		if (list.length) {
			return $q.when(list.shift()).then(function(item) {
				console.log('item', item);
				sum += item;
			}).then(loop);
		} else {
			return sum;
		}
	});
}).
then(function (result) {
	console.log(result);
});

wait() は?

setiTimeout で頑張って書く

  1. トップ
  2. tech
  3. JSDeferred -> Angular $q 置き換え方法

いまいちイメージがしにくくて理解したとはいいきれてない部分の覚書

平衡経路は差動信号、すなわち位相が反転した信号を2線に乗せ、接地せずに伝送する。

対して不平衡経路はシングルエンド、すなわり片方を接地させて信号を伝送する。

信号伝送の形式が違うので、当然直接接続してはいけない。直接接続した場合、不平衡側は GND を基準としているので、GND の変動はすなわち信号線にもGNDが変動しただけの変動が発生するということであり。これはコモンモードのノイズということになる。

バランによって平衡・不平衡を接続することができる。

電圧バラン(トランス)の場合、差動信号の入力は出力からすると単に信号がおおきくなったようにみえる。GND は絶縁されており、コモンモードは発生しない。

Uマッチというバランの場合、片方の伝送路を1/2λ遅延させることによって位相を反転させて逆相を得て平衡信号を作りだす

電流バランの場合、GND変動によって発生するコモンモード電流を遮断する形で機能する。性質上完全に遮断しにくいが、ロスも少ない。

  1. トップ
  2. tech
  3. バランの役目・平衡とは何なのか