はてなブログに引越しました

引越し先は
創 continuation
です。こちらにもしばらくはエントリのリンクだけ追加していこうと思います。

Chrome Extensionで社内メールを「いいね〜」したい（第1回）

chrome extension

社員ブログの方に書きました。 http://goo.gl/n3ofn

my.cnfではslow_query_log=1と書く

mysql

my.cnf で slow_query_log を有効にしたい場合、

slow_query_log=ON

と書いても駄目（OFFの状態で起動してしまう）。特にmysqldのログにエラーが出る訳でも無いのでしばらく気づかなかった…。

slow_query_log=1

と書けば起動時にONになる。なんでやねん。

※MySQL 5.1.52で確認

社員ブログに投稿しました → 『できるプログラマの一形態』

今月から技術・デザイン系社員で持ち回りブログを始めたのですが、その2番手として以下の記事を投稿しました。
私の出会った、できるプログラマ | モンスター・ラボTech/Designブログ

宜しければご覧下さい。

DigiNotar事件の影響について（社内へのメールを転載）

セキュリティ

DigiNotar事件について、社内に流したメールを一部改変して転載します。

メール内容

影響無い可能性もありますが、Web技術者としては知っておいた方が良いので簡単に説明します。

■事件の内容
http://www.itmedia.co.jp/news/articles/1108/31/news017.html
簡単に言うと、DigiNotarという認証局が、本来のドメインの所有者ではない者にSSL証明書を発行してしまった（正確には発行「させられ」てしまった）という事件です。

■事件の危険性
この認証局の証明書は、後述の通り現在は無効化されていますが、その対応が為されるまでは「正しい」証明書として機能していたので、ユーザから見ると正しいサイトにアクセスしているのに、実は不正なサイトにアクセスしているという問題が起こる状態でした*1。

■事件への対応による、一般的な影響
上記の不正発行が判明した為、MicrosoftやMozilla、Google等はそれぞれOS、ブラウザで、同社発行の証明書を信頼できないものという扱いに変えました。
http://www.itmedia.co.jp/news/articles/1109/07/news017.html

これによって、DigiNotar社発行の証明書は、「正規に発行されたものを含めて」全て無効となりました。同社発行の証明書を使っているサイトは、ブラウザでアクセスすると、開発時などに自己証明書（所謂オレオレ証明書）を使うと出てくるようなセキュリティの警告が表示される筈です。

■事件への対応による、自分達への影響
ここまでは他山の石な話ですが、先程我々がよく利用するSSL認証局からメールが来ました。
内容は、クラッカーが「他にも幾つかの認証局を攻撃した」として挙げている中にその認証局も含まれているので、社内で調査が終わるまで証明書発行業務を停止するというものです。
発行業務を停止しても既存の証明書は関係無いので、現時点では期限が来て更新する時困る（別の認証局にする必要がある）くらいの影響ですが、万が一この認証局がDigiNotar社と同様に、不正に発行しており、かつ影響範囲が広汎もしくは特定しきれない状態だった場合、最悪同じように正規の（我々が使っているものを含めた）証明書が全て無効化される可能性があります。

人間によるブラウジングで警告が出るのも問題ではありますが、クライアントアプリ（AIR等）や各種スマホアプリの場合、プログラムからネットワークアクセスが出来なくなる事になるので、サービスの障害に直結します。

という事で、今後の動きによっては早急な対応が求められる可能性もあるという事を覚えておいて下さい。
そうなる危険性が高まった場合は、影響度に応じて先手を打って別の認証局から証明書を取得して差し替える可能性もありますが、その場合は認証局から無効化実施に先立って報告があると思うので、現時点では継続して情報を注視するという対応に留めます。

*1:実際にそれが起こるには不正な証明書以外にも条件がありますが今回は省略

androidの実装で「インタフェースを使うと2倍遅くなる」は間違い

android

インタフェースの代わりに実装クラスを書いた場合の差は6%〜無し

"android パフォーマンス"等で検索すると、以下のサイトが上位に出てきます。
Android開発でのパフォーマンス設計のBest Practice - dann's blog - #
http://labs.techfirm.co.jp/android/cho/1283
どちらもandroidの公式ドキュメント
Performance tips  |  Android Developers
のパフォーマンスに関する部分を元にしているのですが、この中で現在は訂正（に近い扱い）をされている内容があります。この内容は個人的に特にギョッとしていた部分なので、訂正内容を書いておきます。
なお、当初のドキュメントでは確かにお二方のブログのように書いてあったので、お二方が間違っていたのではなく、ドキュメントが良くなかったという事です*1。

間違ったパフォーマンスTips

インターフェースは使わない

Map myMap1 = new HashMap();  
HashMap myMap2 = new HashMap();

オブジェクト指向になぞらえば、上記のようなケースでは多様性の恩恵を受けるために、Mapインターフェースを使った実装が好まれるが、Androidの実装ではパフォーマンス的にNG。インターフェースを使う場合、使わない時と比べて2倍近く遅くなることがあります。

http://labs.techfirm.co.jp/android/cho/1283Android Techfirm Labさんのブログより引用
訂正内容

On devices without a JIT, it is true that invoking methods via a variable with an exact type rather than an interface is slightly more efficient. (So, for example, it was cheaper to invoke methods on a HashMap map than a Map map, even though in both cases the map was a HashMap.) It was not the case that this was 2x slower; the actual difference was more like 6% slower. Furthermore, the JIT makes the two effectively indistinguishable.

公式ドキュメントより引用

適当に訳すと、

  • JIT無しの場合、インタフェース(Map)ではなく実装クラス(HashMap)を書いた方が少しは速い。
  • 但しその差は、2倍ではなく6%くらい
  • JIT有りの場合（2.2以降ですね）、差は無い

との事です。

インタフェースではなく実装クラスを書くのは相当違和感があったし、androidから入ったJavaプログラマに変な癖がつくと良くないのでホッとしました。

ついでに、フィールドをローカル変数にキャッシュする件

こちらは、

  • JIT無しの場合、キャッシュした方が20%速い
  • JIT有りの場合、差はない

そうです。こちらも今後はやめた方が良いルールのようですね。

On devices without a JIT, caching field accesses is about 20% faster than repeatedly accesssing the field. With a JIT, field access costs about the same as local access,

*1:ドキュメントにも、"Previous versions of this document made various misleading claims. We address some of them here."とあります