• Issue 10004 - android - Web Worker isn't worked on Froyo, but it is worked on Eclair - Android - An Open Handset Alliance Project - Google Project Hosting
• javascript - Why was HTML5 Web Workers support removed from the Android browser in versions 2.2 and up? - Stack Overflow

Disable workers

This is because V8 on Android does not have the required locking.
Also disables channel messaging, which is used only with workers.

2.1以前では使えたけど、実装に問題が有ったので無効化したよ!ってかんじかな(あまり詳しく追いかけていない)。When can I use Web Workers?に拠ると、4.0でも対応してないようだ。

マジかー。使おうと思ってたんだけどなー……

• HerokuとGitHubの両方にプッシュする時の秘密にしたい値の扱い - アインシュタインの電話番号?
• HerokuでWebアプリ開発を始めるなら知っておきたいこと (5)環境変数ENV - アインシュタインの電話番号?

HerokuとGitHubの両方にプッシュできるようになったのはいいけど、例えばTwitterのOAuth認証用のトークンとか、何かのAPIを利用するためのAPIキーとか、あるいはもっと大事な何かのパスワードなど、秘密にしておきたい情報は、GitHubにプッシュしてしまうと全世界に公開されるので非常にマズい。

かといって書いておかないと、Herokuにプッシュしたときに情報が足らなくてアプリが正常に動かない。

どうするん？毎回消したり書いたりするの？

config varというのは、上記のようにHerokuとGitHubの両方にプッシュする時の秘密にしたい値の扱い - アインシュタインの電話番号?に記されているような要求をこなす時に使うheroku config:addで追加する値の事ね。
ENVでアクセス出来るし、正体はただの環境変数だと思うが、heroku help configにはconfig varsと表記されてるのでそっちの表記を採用。

さて、このconfig vars、ruedapさんも言及してるように、Herokuの環境下でしか利用出来ない値で、ローカル環境での開発時にはENVに無い。彼も言っているような、ローカル環境かどうか判定して、同一内容をENVに突っ込むスクリプトをrequire、そのファイルは間違ってHeroku側のリポジトリにcommitしないように.gitignoreに書いておく……というのがサッと思いつく対処法か。だが、値の追加/編集時に、heroku configとそのスクリプト、両方を同一内容になるように保持するというのは流石にめんどくさい。

そんな馬鹿な。
おかしい。
あり得ない。
ぜんっぜんprogrammableじゃない。
そもそも、herokuコマンドはgemで導入する物だし、もしかしてライブラリとして利用する方法があるんじゃないの?

という訳で、herokuコマンドのソースを斜め読んでみると、次のようにしてRubyのスクリプトから取得出来る事が分かった。

#!/usr/bin/ruby
require 'rubygems'
require 'heroku'
require 'pp'

EMAIL       = '(Herokuに登録した時に使ったメールアドレス)'
PASSWORD    = '(Herokuのパスワード)'
APPLICATION = '(アプリケーション名)'
KEY         = '(値を取得したいconfig varのKEY)'

heroku = Heroku::Client.new(EMAIL, PASSWORD)

# APPLICATIONの全config varを取得
vars   = heroku.config_vars(APPLICATION)
pp vars	# heroku.config_varsの戻り値はただのHash

# 特定のconfig varを取得
var    = vars[KEY]
p val

……コード中にメールアドレスだのパスワードだの埋め込むのは美しくない。何の為にconfig vars使おうとしてるのやら。

もうちょっとherokuのコードを読み進めてみると、既にheroku loginしているならば、Heroku::Client.newの替わりにHeroku::Auth::clientでも良さそう。

という事は、実際に使う時は次のような感じだろうか。

# 既にheroku loginしている事前提
require 'rubygems'

# ...snip...

if !ENV.key?('VAR1')	# config varのどれか一つでも存在しない場合
	require 'heroku'

	config_vars = Heroku::Auth.client.config_vars(APPLICATION)

	# PATHやLANGといったheroku config:addで登録した物以外も出てくるので、愚直に代入処理をしている
	ENV['VAR1'] = config_vars['VAR1']
	ENV['VAR2'] = config_vars['VAR2']
	# ...以下全てのconfig varについて同様に
end

#...snip...

うーん、ローカルかリモート(Heroku上)かの判定をENV.key?で行うのは何か変だな……もっとスマートな方法が在りそうな気がするが……

送出式

throw expression

送出式が実行されると例外を送出する。送出式はvoid型である。

以上、送出式 - 標準C++辞典 - livedoor Wiki（ウィキ）より。

えっ、送出式って事は、これ式だったのか?

という事は……

#include <iostream>
using namespace std;

int main() {
	try {
		true ? throw 1 : throw 2;
	} catch(int i) {
		cout << "throw : " << i << endl;
	}
}

……というコードを書いて実行してみると……

throw : 1

本当だ……条件演算内にthrow書いても問題ない。

これは知らなかった。しかしどういう時に役に立つんだろうこれ?

忍者バリアーは「荒らし」、スパムなどからのアクセスを簡単に拒否、制限できるサービスです。

『許可したドメインのJavaScriptのみ実行を許可する』アドオンのNoScriptを導入したFirefoxで、忍者バリアーを導入しているwebページを閲覧しようとすると……

問答無用で閲覧がブロックされる。

閲覧出来なかったページのソースコードを覗いてみる。

<script type="text/javascript" src="http://bar1.shinobi.jp/hash.js"></script>
<script type="text/javascript" src="http://bar1.shinobi.jp/s/40/00381.js"></script>
<noscript><a href="http://www.ninja.co.jp/barrier/" target="_blank">アクセス制御</a></noscript>
<noscript><meta http-equiv="refresh" content="0;URL=http://bar1.shinobi.jp/hoge/NoScript?0038140" />
<div style="background-color: #000000;text-align: center;vertical-align: middle;width:100%;height: 100%;margin: -10px;padding: 0px;z-index: 10;position: absolute;">
<div style="color: #ffffff;margin: 0px;padding: 0px;position: absolute;top:50%;left:47%;"><a href="http://www.ninja.co.jp/">NINJA TOOLS</a></div></div></noscript>

スクリプトを実行出来ない環境下で適用する内容を記述するnoscript要素の下で、<meta http-equiv="refresh" 〜 />を使い、忍者バリアーが用意したページにリダイレクトしている。

強制的に忍者バリアーの用意したページに移動してしまうので、元のサイトのスクリプト実行を許可する暇もない。

つまり、NoScript(或いは類似機能を導入したwebブラウザ)では、忍者バリアーを導入したページは閲覧出来ない。荒らしやスパマーか否かに拘わらず。

『荒らしやスパマーか否かに拘わらず』。
はい、大事な事なので2回言いました。

そもそも、

このホームページはJavaScriptを使っています。
ブラウザの設定でJavaScriptを有効に設定してから
アクセスしてください。

とか言っているが、JavaScriptが必要なのは忍者バリアー自身じゃないか。

また、世の中にはJavaScript使えないwebブラウザだって存在するのだ。そういったブラウザの利用者はどうしろと?

大体、忍者バリアーなんて簡単に通過できてしまうのだ。忍者バリアーで本当に防ぎたい荒らしやスパマーは、これくらいの対策はしてくるだろう。バリアー（）

結局、
忍者バリアーは、荒らしやスパマーに対しての効果が殆ど程めず、且つ、悪意の無い閲覧者にとってはページ閲覧の邪魔になりかねないという、全くのクソッタレなのだ。

敢えて言おう。
忍者バリアーは役立たずであると!

備忘録ともいう。

CygwinのパスをWindowsのパスに

cygpath -w filepath

CygwinのパスをWindowsのパス(ショートファイルネーム)に

cygpath -d filepath

WindowsのパスをCygwinのパスに

cygpath -u filepath

-uがデフォの挙動のようで、省略しても動作する。

他に、Windowsの各種特殊フォルダ(デスクトップとかSystemフォルダとか)を出力させる事も出来たり、結構多機能。

Try `cygpath --help' for more information.

この記事は……

Boost Advent Calendar 2011の一環として書かれた。ボレロ村上さんから引き継いだ、10日目である。

Advent Calendarとは何か? については、例えば師走を楽しもう。技術系アドベントカレンダーの魅力とは - ＠ITを参照の事。

参加者を見回すと、STAR WARSに出てくるシスの暗黒卿ばりに黒のローブを引きずったC++闇の軍団ばっかりで非常に恐ろしい。しかし、話を振られてしまったら、参加するしかないじゃない! あなたも、私も……!

なお、当記事中で言及するBoostのバージョンは、記事執筆時点での最新バージョンであるVersion 1.48.0を前提としている。

BOOST_CHECK_EQUAL_COLLECTIONS()マクロ

Boost.Testにおいて、コンテナに格納されている値を検証するにはBOOST_CHECK_EQUAL_COLLECTIONS()マクロを利用する。他のマクロと同様、BOOST_WARN_EQUAL_COLLECTIONS(), BOOST_REQUIRE_EQUAL_COLLECTIONS()という、異なるlevelのマクロも存在する。この記事では便宜上、これら3つをひっくるめてBOOST_CHECK_EQUAL_COLLECTIONSと呼ぶ事にする。

詳細な使用法は、The UTF testing tools referenceのBOOST_<level>_EQUAL_COLLECTION項を参照。

BOOST_TEST_DONT_PRINT_LOG_VALUE()マクロ

BOOST_TEST_DONT_PRINT_LOG_VALUE()マクロは、BOOST_CHECK_EQUAL()等で検証した値をログに出力しない事を指定する物だ。BOOST_CHECK_EQUAL()等で検証するオブジェクトは出力ストリームへのoperator<<をサポートしている必要が有る。が、全ての型がそれをサポートしているという事はあり得ない。例えばstd::pairがそれに当たる。そういった型をこのマクロで指定すると、テスト結果のログに、その型のオブジェクトの値は出力されなくなる。

詳細はTest log outputを参照。

BOOST_TEST_DONT_PRINT_LOG_VALUE()対応BOOST_CHECK_EQUAL_COLLECTIONS

さて、BOOST_TEST_DONT_PRINT_LOG_VALUE()マクロだが、困った事にBOOST_CHECK_EQUAL_COLLECTIONS()マクロでのログ出力においては適応されない。これは困る。

という訳で、BOOST_TEST_DONT_PRINT_LOG_VALUE()に対応したBOOST_CHECK_EQUAL_COLLECTIONS()を作ってみる。

此処で出てくる"Visual C++ 2010"は正確には"Visual C++ 2010 Express SP1"の事ですはい。

以下やった事箇条書き。

1. Qt のダウンロード ? Qt - A cross-platform application and UI frameworkからQt SDK version 1.1.3のオンラインインストーラーをダウンロード。
2. インストーラー起動。デフォルト設定でインストールを行おうとするも、あまりのダウンロード所要時間に音を上げ中止。
3. 再びインストーラー起動。適当に必要不必要そうなモジュールのチェックを付けたり外したり。この時、VC++のサポート対象が2008だと知って少々不安になるも、インストール成功。
4. スタートメニューからQt 4.7.4 for Desktop (MSVC 2008)を起動。VC++2010のvcvarsall.batを起動。
5. Qt 4.7: Getting Started Programming with Qt のHello Notepadサンプルと同じコードを入力し、qmake -project & qmake & nmake。成功。

実行すると……

D:\Documents and Settings\AmaiSaeta\qttest.vc>debug\qttest.exe
指定されたプログラムは実行できません。

ｱﾙｪｰ?
まぁVC++2010でVC++2008用のバイナリを使ったわけだから、変な事になるのも致し方なし……

仕方無いので、Qtをソースからビルド。

1. Qt のダウンロード ? Qt - A cross-platform application and UI frameworkからqt-everywhere-opensource-src-4.7.4.tar.gzをダウンロード、適当な場所に展開。
2. Qt 4.6: General Qt Requirements及びQt 4.6: Qt for Windows Requirementsに有る通り、DirectX SDKとWindows Platform SDK、OpenSSLを導入する。
   今回はそれぞれ、現時点で最新と思われる以下の物を採用。
   • Download Details - Microsoft Download Center - DirectX SDK - (June 2010)
   • Download Details - Microsoft Download Center - Microsoft Windows SDK 7.1
   • Shining Light Productions - Win32 OpenSSLのWin32 OpenSSL v1.0.0e
3. Qt 4.7: Installing Qt for Windowsを参考にQtをbuild。configureのオプションはconfigure -helpを見つつ適当に決めた。

   "%VS100COMNTOOLS%\..\..\VC\vcvarsall.bat"
   PATH C:\OpenSSL-Win32\bin\;%PATH%
   SET INCLUDE=C:\OpenSSL-Win32\include;%INCLUDE%
   SET LIB=C:\OpenSSL-Win32\lib;%LIB%
   PATH (Qtソース展開先)\bin;%PATH%
   CD (Qtソース展開先)
   configure -debug-and-release -opensource -shared -static -no-qt3support -platform win32-msvc2010 
   nmake

   当方の環境で2時間半というウンザリするような時間かけてbuild完了。
4. バイナリ版導入と同じくQt 4.7: Getting Started Programming with QtのHello Notepadを作ってみる。今度は正常に動作。
5. 続いてAdding a Quit Buttonを作ってみる。buildは成功するが、Quitボタンを押すと……
   

ｱﾙｪｰ?
assertion failedしたf:\dd\vctools\ctr_bld\self_x86\crt\dbgdel.cppというファイルはこちらの環境には存在しない。というかf:ドライブなんて無い。という事は、Qtのbuildで使った(C++標準含む)ライブラリの何れかで発生していると思われるが、それを調査する気力は既に残っていないのであった……

JavaScriptでスタイルシートを操作するには?

JavaScriptで既存HTMLページにCSSを追加する必要が出て来たのでちょっと調べた。
基本的に、document.styleSheetsでlink要素やstyle要素で読み込まれるスタイルシートが配列風(実際は配列ではない)に参照出来、insertRuleで新規にルールを追加出来るようだ(ただし例によってInternet Explorer以外。IE死ね!)。

const styleSheets = document.styleSheets;
// これで、
//  styleSheets[0] = 1つ目のlink或いはstyleで導入されているスタイルシート
//  styleSheets[1] = 2つ目のlink或いはstyleで導入されているスタイルシート
// ……といった感じでアクセス出来る。
const styleSheetsNum = styleSheets.length;	// スタイルシートの数

styleSheets[0].insertRule(	// ルールの追加;一番最初のスタイルシートに……
	"a { font-weight: bold; }",	 // ←のルールを……
	0);	// 0番目(対象スタイルシート先頭)に挿入。
const ruleNum = styleSheets[0].cssRules.length;	// ルールの数
styleSheets[0].insertRule("h1 { color: #000; }", ruleNum);	// ←で、スタイルシートの最後にルールを追加出来る。

で、こういった事を解説している、

• [暴満館] JavaScriptによるCSSの操作
• JavaScript for CSS(3)
• DOMによるスタイルの変更（その２）

なんかでは、document.styleSheetsの一番最後にルールを追加するようなコードを載せてる。

でもこれっておかしくない?

var elem = document.getElementById('checkbox_element');

みたいな感じで変数elemが操作対象のチェックボックス要素指してるとして、

• elem.setAttribute()やelem.removeAttribute()で操作 ←まちがい
• elem.checkedで操作 ←せいかい!

以下テストコード。

詳細はXHTMLソース自体を見て欲しいが、"change"ボタンを押す毎にその直前のチェックボックスのON/OFFを切り替える(事を意図している)。

Firefox 6.0、Opera 11.11、Chrome 13.0.782.112mで確認。例によってInternet Explorerはまともに動作しない。IE死ね!

なんか納得いかねぇ!