外部APIに問い合わせる場合はできるだけ「0分」を外しておくのをオススメします。11分とか13分とか17分とか19分、23分とかだといいですね
/bin/bash -c '/usr/bin/sleep $(( ( $RANDOM %10 ) + 5 ))m' && /do/some/task
; D50こんな感じ。
%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_0003
%CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_0003&MI_01
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として転送する。これでフォントはモトヤのフォントになる。
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
某所で「CoffeeScript は是か否か」論争が巻き起こっているが、もっと低い次元で話をすると、やっぱりJavaScriptは
・Java しか知らない人にはプロトタイプの考え方がわかめ
・名前空間制御やクラス表現のしかたがたくさんありすぎて、慣れてもどうすべきか迷う
なー。
今は即値関数内でクラスをグローバルオブジェクトにぶら下げるやりかたしてるけど、Node.JSのrequireみたいに好きな名前でimportしたいときのこと考えると、どうしたらいいか悩む。
ここは、やっぱりきちんと標準化してほしいな。それとも自由度の高さを重視するか。JavaScriptはブラウザにおけるCだねえ。
JavaScriptのテンプレートエンジンというと、今までは「とりあえず%%VARIABLE%%とか書いておいて、ハッシュの対応表と置換させる」か、ちょっと要件が大きくなると「Ajax Pages」を使っていた。Ajax Pagesは素のJavaScriptをテンプレート中に書けるのでなんでもできて、自分だけの開発用には便利なのだ。
しかし、もうすこしテンプレートとロジックを切り離したくなった。当然のニーズだけど。かといってDOMベースで記述するとかコンパイルが必要とかいうのは敷居が高すぎるのでパス。論理記述はSmartyくらい、フィルタがあって、JSONのオブジェクトをかんたんに受け渡せるもの希望。あと、ヘルパーメソッドをプログラマ側で柔軟に追加できるものが好ましい。
ということで見つけたのが「Jarty」。これ、極端にイイというわけではないけれど、ちょうどしっくりくる感じ。Smarty構文はほぼほぼ再現されている。オブジェクトは個別にassignしなくてもまとめて受け渡せる。そして、フットプリントがてごろでフィルタおよび関数の拡張方法が明記されているため、ちょっとコード読むだけで必要なものを追加できてしまう。
おかげでずいぶん見通しのいいコードになった。
おまけでついてるパーサデバッガがおもしろかった。おいら、ここらへんの構文解析部分、まじめに実装したことないからなー。ちゃんとやらなきゃ！
てゆーか、そもそも単純置換で済ませるのが手抜き過ぎだな。そこから習慣を変えましょう。
ニンテンドーDSi用のBASIC環境「プチコン」と言えば超有名だが、3月中旬にニューバージョンの「mkII」が出たのだ。しかも、それがあの「TALK」命令対応！ パピコン世代なら買わずにいられるわけがない。
さっそくスクリーンエディット画面からTALK命令を実行！ あれ？ 動かない…。引数の前に空白がないから？ そういうわけじゃないみたい。えー。プログラムとして実行しなきゃダメなのかなあ？ えーん、それもちがうー！
ひとしきり悩んだあと「もしや発音可能な記号以外は受け付けないのか？」と読点を抜いたら、みごとシャベルパソコン（by 武田鉄也）成功！
「コンニチワマイコン」
って、いかにも機械っぽい声で喋るのを聞くとひときわ感慨深く、初音ミクも何をかはせむと思ってしまうのだった…。
JetBrainsのWeb向けIDE「WebStorm」のライセンス、買っちゃった。ドル建て約5,000円也。
HTMLとJavaScriptが同じファイルに混在しているような汚いソースコードを書く機会が多くて困っていたのだ。本当ならそんなもん書きたくないのだが、世間がそれを許さない。EclipseとかAptanaだと、こういうコンテキスト混在のコードには弱い。というか、どうしてもJava書いたりAndroidアプリ作るときでもないと、あの重さは耐えがたいし…。
きょう秀丸で簡易コードスニペット（コピペコーディングとも言う。お察しください）みたいな作業してて、あまりの非効率さに発狂。ちょい前から試用中のWebStormをついにレジストレーションしてしまった。
…いや、快適すぎる。作業効率が段違いだ。なにかコピーしても思ったとおり整形してくれるし、コメント・アンコメントも一発。秀丸じゃムリなリファクタリングももちろんOK。そんなIDEとしての最低条件はおいても、即値関数内で定義したオブジェクトのプロパティも補完してくれるのには思わず涙した。そのうえEclipseより速い！ …ま、メモリ食いなのでウイルスバスターみたいな怨霊が憑り付いてる環境では重いけどね（あとメモリ2GBだとスワップ要求される）。
いや、もう、今後はWebStormを積極的に使っていく所存です。この子がPerlにも対応してくれてたらなあ。なんでJetBrainsのサイトにはPerlのパの字もないんだ。オワコン扱いか。
スマートフォンサイトエミュレータ代わりに使ってる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くらいじゃスワップしまくり。実際に動かすマシンはリソース問題にならなさそうだけどね。とにかく情報を確保しないと誰も保守できなくなっちゃう。収集中。
やっぱ、ここらへんの議論をできる相手が必要だなー。いないけど。自分がマージナルなのって、キツイね。マジで。