JavaScriptのvoidは演算子だから(0)を取るのね…

まあね。常識なんだろうけどね…。

ときどき間違えるたびに「？」状態に陥るから調べてみたら、
JavaScriptのvoidは組み込み関数ではなくて「演算子」
なんだよね…。MDNにも書いてあるわ…。

だから、下のようになる。

• void()だと演算するexpressionがないのでエラー
  
• void(0)はexpressionがあるので動作する
  
• 演算子なので void 0 という書き方でもOK
  

jsdo.itで試した。

Google+からRSSフィードを取得する「googleplus2rss」

Google+からRSSフィードを取得するPerl CGIスクリプト「googleplus2rss」。

といってもGoogle+ API使って、各モジュールで変換してるだけ。添付メディアがある場合、最初の画像だけをattachmentとして登録してくれる不親切使用。

おなじディレクトリにgoogleplus2rss.confを置いて、Google+ APIのAPI KeyおよびGoogle+のユーザーIDを記述する必要があるので注意。

中華Pad「D50」を買ってやった最初の設定

Galaxy Tab 7.0 Plus のAndroid 4.0へのアップデートが7月にズレ込みそうなので、もうドコモには期待しないでIce Cream Sandwich搭載の端末を入手することにした。しかし、Galaxy Nexusは価格暴落転売祭りとLTE端末へのスイッチ方針でとうに在庫が払底。都内のどこを歩いても一台もない。しかたないので「おもしろそうだし」ということで中華PadのICOO「D50」を購入した。

ICOO「D50」
http://www.aoicoo.com/CN/info.asp?id=419&t=1&l=1

 秋葉原の東映無線ラジオデパート店で買ったら、はじめからAndroidは4.0.3、日本語化・公式マーケット（Google Play）導入済みだった。とはいえ、それだけで簡単に使えるというわけではない。いろいろ不便だったので最初にやった設定をまとめておく。

最初は日本語入力ソフトの導入。最初はBaiduの中国語インプットメソッドしかないので死にます。マーケットで「OpenWnnフリック対応版」を入れた。
https://play.google.com/store/apps/details?id=com.pm9.flickwnn&hl=ja

あと、ちょっと無線LANが不安定な気がするので旧Galaxy Tab時代にお世話になった「WiFi Fixer」を導入。
https://play.google.com/store/apps/details?id=org.wahtod.wififixer

ここまではジャブ。
フォントがCJK統合フォントではかっこつかないので、これをちゃんとした日本語向けフォントに入れ替えなければならない。「USBドライバをPCにインストールしてD50とつなぐ」→「日本語フォントを拾ってくる」→「adbでpush」という手順になる。

先にD50のUSBデバイスインスタンス値を調べておかないといけない。D50をWindowsにUSB接続したあと、Windowsの「システム」→「デバイス」で「不明なデバイス」になっている「Android」を選択し、「詳細」タブから「デバイスインスタンスパス」を選択する。これで、
　USB\VID_18D1&PID_0003&MI_01
あたりまでメモ。

USBドライバは、GoogleのAndroid SDKから入手する。
http://developer.android.com/sdk/index.html
で、android-sdk_r17-windows.zipをダウンロードして解凍。SDK Manager.exe を起動して「Extras」→「Google USB Driver」を選択して、これだけ追加インストールする。

次は、このデバイスドライバをWindowsが認識できるようにinfファイルを書き換えてやる。
extras\google\usb_drivers\androis_winusb.inf
を開く。

ファイル中のGoogle.NTx86セクションとGoogle.NTamd64セクションに、先ほどのUSBデバイスインスタンスに合わせた文字列を書き込む。

; D50
%SingleAdbInterface%        = USB_Install, USB\VID_18D1&PID_0003
%CompositeAdbInterface%     = USB_Install, USB\VID_18D1&PID_0003&MI_01

 こんな感じ。

これで、Windowsのデバイスドライバとして認識されるようになるので、「不明」になっているデバイスのドライバから直接指定してインストールしてやればいい（ディレクトリを指定するだけではデバイスを認識しないので注意。リストから選択させること）。

これでD50がWindowsのadbコマンドで操作できるようになった。

次に日本語フォントを入手。これはモトヤがオープンソースとしてAndroidに提供したものが
https://github.com/OESF/OHA-Android-4.0.3_r1.0/tree/master/frameworks/base/data/fonts
に「MTLc3m.ttf」として置いてあるのでダウンロード。「DroidSansJapanese.ttf」と改名して使用する。
で、

c:\> adb push DroidSansJapanese.ttf /system/fonts/DroidSansJapanese.ttf

として端末に転送。また、使用フォント設定ファイルも書き換える必要があるので、

c:\> adb pull /system/etc/fallback_fonts.xml fallback_fonts.xml

し、

    <family>
        <fileset>
            <file>DroidSansFallback.ttf</file> 

よりも前の行に

     <family>
        <fileset>
            <file>DroidSansJapanese.ttf</file>
        </fileset>
    </family>

を追加。

c:\> adb push fallback_fonts.xml /system/etc/fallback_fonts.xml

として転送する。これでフォントはモトヤのフォントになる。

いっぽう、これだけだとまだ不具合がある。外部SDカードが一般アプリケーションから読み書きできないままなのだ。そこで、

c:\> adb pull /system/etc/permissions/platform.xml platform.xml

とし、platform.xml の

    <permission name="android.permission.WRITE_EXTERNAL_STORAGE" >
        <group gid="sdcard_rw" />
    </permission> 

を

    <permission name="android.permission.WRITE_EXTERNAL_STORAGE" >
        <group gid="sdcard_rw" />
        <group gid="media_rw" />
    </permission>

と書き換えて、

c:\> adb push platform.xml /system/etc/permissions/platform.xml

とする。

最後に

adb shell reboot

しておしまい。

D50は、今のところちょっとパネルの感度が悪い気がするのを除けばまあまあ快適だ。

 

 

 

 

JavaScriptはやっぱりクラス表現で迷うなあ

某所で「CoffeeScript は是か否か」論争が巻き起こっているが、もっと低い次元で話をすると、やっぱりJavaScriptは

・Java しか知らない人にはプロトタイプの考え方がわかめ
・名前空間制御やクラス表現のしかたがたくさんありすぎて、慣れてもどうすべきか迷う

なー。

今は即値関数内でクラスをグローバルオブジェクトにぶら下げるやりかたしてるけど、Node.JSのrequireみたいに好きな名前でimportしたいときのこと考えると、どうしたらいいか悩む。

ここは、やっぱりきちんと標準化してほしいな。それとも自由度の高さを重視するか。JavaScriptはブラウザにおけるCだねえ。

まともなJavaScriptテンプレートエンジンを使うの巻

JavaScriptのテンプレートエンジンというと、今までは「とりあえず%%VARIABLE%%とか書いておいて、ハッシュの対応表と置換させる」か、ちょっと要件が大きくなると「Ajax Pages」を使っていた。Ajax Pagesは素のJavaScriptをテンプレート中に書けるのでなんでもできて、自分だけの開発用には便利なのだ。

しかし、もうすこしテンプレートとロジックを切り離したくなった。当然のニーズだけど。かといってDOMベースで記述するとかコンパイルが必要とかいうのは敷居が高すぎるのでパス。論理記述はSmartyくらい、フィルタがあって、JSONのオブジェクトをかんたんに受け渡せるもの希望。あと、ヘルパーメソッドをプログラマ側で柔軟に追加できるものが好ましい。

ということで見つけたのが「Jarty」。これ、極端にイイというわけではないけれど、ちょうどしっくりくる感じ。Smarty構文はほぼほぼ再現されている。オブジェクトは個別にassignしなくてもまとめて受け渡せる。そして、フットプリントがてごろでフィルタおよび関数の拡張方法が明記されているため、ちょっとコード読むだけで必要なものを追加できてしまう。

おかげでずいぶん見通しのいいコードになった。

おまけでついてるパーサデバッガがおもしろかった。おいら、ここらへんの構文解析部分、まじめに実装したことないからなー。ちゃんとやらなきゃ！

てゆーか、そもそも単純置換で済ませるのが手抜き過ぎだな。そこから習慣を変えましょう。

「プチコンmkII」が強力なオッサンホイホイな件

ニンテンドーDSi用のBASIC環境「プチコン」と言えば超有名だが、3月中旬にニューバージョンの「mkII」が出たのだ。しかも、それがあの「TALK」命令対応！  パピコン世代なら買わずにいられるわけがない。

さっそくスクリーンエディット画面からTALK命令を実行！  あれ？  動かない…。引数の前に空白がないから？  そういうわけじゃないみたい。えー。プログラムとして実行しなきゃダメなのかなあ？  えーん、それもちがうー！

ひとしきり悩んだあと「もしや発音可能な記号以外は受け付けないのか？」と読点を抜いたら、みごとシャベルパソコン（by 武田鉄也）成功！

「コンニチワマイコン」

って、いかにも機械っぽい声で喋るのを聞くとひときわ感慨深く、初音ミクも何をかはせむと思ってしまうのだった…。

JavaScript用にWebStormライセンス買っちゃった

JetBrainsのWeb向けIDE「WebStorm」のライセンス、買っちゃった。ドル建て約5,000円也。

HTMLとJavaScriptが同じファイルに混在しているような汚いソースコードを書く機会が多くて困っていたのだ。本当ならそんなもん書きたくないのだが、世間がそれを許さない。EclipseとかAptanaだと、こういうコンテキスト混在のコードには弱い。というか、どうしてもJava書いたりAndroidアプリ作るときでもないと、あの重さは耐えがたいし…。

きょう秀丸で簡易コードスニペット（コピペコーディングとも言う。お察しください）みたいな作業してて、あまりの非効率さに発狂。ちょい前から試用中のWebStormをついにレジストレーションしてしまった。

…いや、快適すぎる。作業効率が段違いだ。なにかコピーしても思ったとおり整形してくれるし、コメント・アンコメントも一発。秀丸じゃムリなリファクタリングももちろんOK。そんなIDEとしての最低条件はおいても、即値関数内で定義したオブジェクトのプロパティも補完してくれるのには思わず涙した。そのうえEclipseより速い！ …ま、メモリ食いなのでウイルスバスターみたいな怨霊が憑り付いてる環境では重いけどね（あとメモリ2GBだとスワップ要求される）。

いや、もう、今後はWebStormを積極的に使っていく所存です。この子がPerlにも対応してくれてたらなあ。なんでJetBrainsのサイトにはPerlのパの字もないんだ。オワコン扱いか。

Windows版Safariが死にまくる件について

スマートフォンサイトエミュレータ代わりに使ってるWindows版Safariが、jQuery Mobile使うページにアクセスすると必ず死ぬようになった。

どうやらWebkit2に移行してから安定しない事象がちらほら報告されているらしい。落ちるのがWebkit2ライブラリ部分だから、まさにそれに該当する。本当にありがとうございました。

AppleのWindowsプロダクトはホントに信用ならん。QuickTimeもiTunesも重いわ落ちるわ勝手に変なアップデータやソフトインストールするわで、使う必要がないなら今すぐコンクリートの重りをつけてワニとサメだらけのマイアミの海に沈めたあと、すぐには死なせんじわりじわりと苦痛を味わせるために延命治療をほどこしてやりたいくらいだ。

…で、エミュレータに何使えばいいんじゃ。

性本能と水爆戦とワークフローと社内ポータルとＴシャツと私

組織内情報共有体制がよろしくないので、いろいろとシステムを検討している。Redmineは活用しているのだけれど、本来の意味のワークフローとして活用しようとするとフォームの機能とデータ出力まわりが弱すぎて、かなり大規模なプラグインを開発しなくちゃならないのだ。

とりあえず最小TCOで活用できるのはマイクロソフトの「Infopath」だ。自由度の高いフォームをメールで配信するだけで、データをCSVで収集できる。しかし、Infopathの知名度が低すぎるのとクライアントすべてにInfopath Fillerのインストールが必要になるのが面倒だ（エンタープライズ向けのサイトライセンスにはだいたいついてくるので購入コストは発生しない）。

Outlookのフォーム機能を使うのは都度開発コストがかかりすぎる。Acrobatのフォーム機能はわかりづらすぎる。デザイン時に文面を別のソフトで作らなきゃいけないし、フォーム作成機能自体は有償。

正直、ネイティブアプリケーションではいいものがない。そもそもここまで、スタンドアローンでワークフローに対応しているのはAcrobatだけで、それも純正ツールを使ったときだけの話である。そこでこんどはWebベースのツールに目を向けてみた。ちなみにASPは不可。オンプレミス前提。

ちょっと因縁のある「intra-mart」はきっちりワークフローがあるのだけれど、これは設計にかなり工数がかかる。正直エンドユーザーコンピューティング向けじゃない。さらにごそごそ調べていたら「Liferay」というのを見つけた。

Liferayは、もともとは一時期盛り上がった社内ポータル構築システムなのだが、昨年ごろからワークフローシステムをバンドルしているという。ポートレットなんて死語だと思ってたが、これならポータルサイトも作れて一挙両得じゃん。LDAP対応なのも確認すみ。

だが、実際にインストールしてみるとこれがけっこう使いづらい…。そもそもドキュメントが少なすぎてなんだかわからないのだ。投票フォームくらいはすぐ作れたけれど、そこからはさっぱり。おまけにJ2EEはダテじゃないので、かなり重い。サーバ側は2GBくらいじゃスワップしまくり。実際に動かすマシンはリソース問題にならなさそうだけどね。とにかく情報を確保しないと誰も保守できなくなっちゃう。収集中。

やっぱ、ここらへんの議論をできる相手が必要だなー。いないけど。自分がマージナルなのって、キツイね。マジで。