2015年 04月 06日

✖

photo phone

関連エントリー (画像)

2015年 03月 31日

I/Q phase (直交信号) から周波数を求める

tech

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

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

関連エントリー

JavaScript で書かれたリードソロモン符号のエンコーダ・デコーダ

tech

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 と同じっぽい。

関連エントリー

2015年 03月 27日

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

tech 
#!/bin/sh

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

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

関連エントリー

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

tech 
#!/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 自作システム

tech

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

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

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

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

一方で欠点は

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

自作の利点と欠点

利点

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

欠点

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

つまり

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

それでも自作するか

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

関連エントリー

2015年 03月 20日

✖

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

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

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

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

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

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

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

関連エントリー

トルクの単位

tech

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

なので、

関連エントリー

ユーチューバー活動

tech

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

続くか

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

今のところ

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

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

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

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

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

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

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

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

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

関連エントリー

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

tech

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

関連エントリー