bashでfindの結果をつかって処理をする

具体的には、大量にできあがっているキャッシュファイルを、再作成したいような時、

一気に消すとキャッシュ作成コストが一気に発生するので、1ファイルずつ定期的に消したい。

しかも全ファイル自動的に。

ということで、実現するコマンド
[shell]find . -xtype f | while read x ; do rm -rf $x; sleep 0.3 ; done[/shell]
となる。findで取得した一覧を元に、whileでリストを回す感じです。

簡単でしたね。

ADTでAndroidのエミュレータを高速化する(WIndows & Intel)

ADTでデバッグするときなどにAndroidのエミュレータを起動すると思いますが

もしかしたら、エミュレータが重すぎて実機を繋いでデバッグしてしまうかもしれません。

でも、エミュレータでやりたい場合もあったりするので

出来ればエミュレータが高速に動いてほしい。。

これがWindowsでIntelのCPUだと、高速化出来たりします。

Intelのページに

http://software.intel.com/en-us/android

Hardware Accelerated Execution Manager

というものが置いてあります。TOOLS % DOWNLOADの所ですね。

これをインストールします。

haxm1

これがインストール出来る環境であれば、Androidエミュレータが高速化されます。

インストール出来ない場合は、あきらめるか新しいPCを購入しましょう。

で、BIOS設定でもインストール出来ない場合があるので

Virtualization Technologyという項目がONになっていることを確認してください。

インストール出来たら、次はADT側ですが

Android SDK Managerを起動します。

デバッグで使いたいバージョンを選択して、

Intel x86 Atom System Imageというのをインストールします。

Android_SDK_Manager1

このイメージがない場合、そのバージョンでのデバッグは高速化されません。

続いてAVDで、デバイスを作成(編集)します。

AVD01

Targetには、先ほどIntel x86 Atom System Imageをインストールしたバージョンのものを設定します。

CPU/ABIに、Intel Atom(x86)を指定します。

Emulation OptionsでUse Host GPUを選択します。

これで、ADTの設定は完了です。

あとはエミュレータを起動すれば、超高速になっていると思います。

 

/tmpに出来る変なファイルを定期的に消したい

/tmpにはウェブサービスを公開してたりすると、アップロードされたファイルの残骸とかが残ったりします。

これを定期的に消したい。
[shell]find /tmp -maxdepth 1 -name "*-0" -atime 2 -exec rm {} \;[/shell]
今回の対象ファイルの条件は、ナンタラ-0という感じに、末尾に-0が付くようです。

これを条件に削除するコマンドです。

-maxdepthというのは、/tmpの中の第一階層の物だけをターゲットにします、という意味

/tmp/nan-0 とかはヒットして、/tmp/a/nan-0はヒットしない。

-nameは、名前の条件を指定します。
*-0にヒットします。

-atime 2は、最終アクセスから2日経過してるファイルがヒット

-exec rm {} \; は、ヒットしたファイルに対して処理を実行すると言う意味で、この場合はrmなのでファイルを削除します。{}という所にヒットしたファイル名が入ります。コマンドの終わりを;で終わらせるのですが、コマンドライン上なのでエスケープしてます。また、;の前には空白が必ず必要です。

ページで画像を延滞ロードさせる

画像が多いサイトなどで、ローディング時間が長くて困る、なんて言う時は

画像の延滞ロードです。

最近のAmazonとか、スクロールして画像が表示される時に一瞬ローディング画像が出たりしてるやつです。

http://www.appelsiini.net/projects/lazyload

このプラグインを使うと、簡単に実現出来ます。

必要な物は、jQuaryとこのプラグイン。

あとは、延滞ロードしたい画像のタグにclass=”lazy”を追加します。
[javascript]$(“img.lazy”).lazyload();[/javascript]
という処理をどこかに置きます。

以上です。

TeraTermProの背景を黒にするとANSI Colorが見にくい

TeraTermProで拝啓を黒に設定してANSI Colorの表示の時、

どうも青が見にくい感じになります。

TeraTermProのバージョンにもよるカモしれないのですが、色のためにバージョン戻したりとか嫌なので、設定ファイルをいじってみます。

TeraTermProの設定ファイルは

インストールフォルダの直下にあるTERATERM.INIです。

このファイルを開くと、TeraTermProの全部の設定が入っています。

この中からANSIColorという設定を探し出します。
[shell]ANSIColor=0,0,0,0, 1,255,0,0, 2,0,255,0, 3,255,255,0, 4,128,128,256, 5,255,0,255, 6,0,255,255, 7,255,255,255, 8,64,64,64, 9,192,0,0, 10,0,192,0, 11,192,192,0, 12,64,64,192, 13,192,0,192, 14,0,192,192, 15,192,192,192[/shell]
このような設定になっているかと思います。

この数列の意味ですが、4つで一つの色を表しています。

最初の数字はただのインデックスのようです。

続いて3つある数値がRGBに対応しています。

今回は青色ですが、インデックスで言うと12番が該当の設定なので、個々の数値を調整してみます。

自分は12,100,100,220に設定してみました。

変更前=>ansi_color1

変更後=>ansi_color2

少し白く飛んだ青になっていますが、背景が黒の時は割と見やすいので、まぁ良しとします。

ちなみに、コマンドラインで確認する方法ですが
[ruby]ruby -e ‘print "\e[34mhello\e[0m\n"'[/ruby]
というコードで表示してみました。

ImageMagickで、/tmpとかにmagick-ayu89r53とかいうサイズの大きいファイルが出来るのをなんとかしたい

ImageMagickを使って日々運用していると、時々ディスクフルアラートが出たりします。。

よく調べてみると、/tmpにmagick-ayu89r53とかよく分からないファイルが数十GB位のサイズになっていてびっくりします。。

別に定期的に出る訳では無く、たまに出たりするので、なんとも分からないのですが

ImageMagick本家のドキュメントを調べてみると

http://www.imagemagick.org/script/command-line-options.php
[text]-limit <em>type value</em>[/text]
というのが設定出来るようです。

このlimitの概要にはSet the pixel cache resource limit.となっていまして
具体的には
[text]<code>area</code>, <code>disk</code>, <code>file</code>, <code>map</code>, <code>memory</code>, <code>threads</code>, <code>time</code>[/text]
が指定出来るようです。

diskは、その名の通り、disk使用量。おそらく、この設定が/tmp/magick-ナンタラ

に影響しているのでは無いかと思ったりします。

これらの現在の設定値を確認出来るコマンドがあるので、叩いてみます。
[shell]identify -list resource[/shell]
このdiskの初期値が18.446744EBとか書いてあります。

EBって何ですか!?

と一瞬びっくりしますが、エクサバイトの事ですかね。

今の運用環境からするとほぼ無限なサイズがデフォルトに指定されています。

ここを変えるだけで、バカみたいにでかい/tmp/magick-ナンタラは出来なくなるかと思います。

まだ検証はしていません。

これから実験運用してみようかと思います。

ちなみに、このオプションの設定ですが

convertコマンドを叩く時はそのまま-limit disk 1GBと書けば良いです。

別アプリからライブラリを叩く場合は

ImageMagickの設定のディレクトリに入っているpolicy.xmlに、<policymap>があるので

このなかでname=”disk”のものを探して1GBに設定すれば良いはずです。

Play frameworkのpidファイル「RUNNING_PID」ファイルの場所を変える(v2.0.4以降)

Play frameworkを本番環境にデプロイする場合に、PIDファイルを別の場所に置きたいなと思ったりします。

デフォルトだとプロジェクトディレクトリの直下にRUNNING_PIDというファイルが作成されます。

このRUNNING_PIDファイルを作る所のコードを確認すると

play.core.server.NettyServer

の中にあるようです。

[scala]
def createServer(applicationPath: File): Option[NettyServer] = {
// Manage RUNNING_PID file
java.lang.management.ManagementFactory.getRuntimeMXBean.getName.split(‘@’).headOption.map { pid =>
val pidFile = Option(System.getProperty("pidfile.path")).map(new File(_)).getOrElse(new File(applicationPath.getAbsolutePath, "RUNNING_PID"))

// The Logger is not initialized yet, we print the Process ID on STDOUT
println("Play server process ID is " + pid)

if (pidFile.getAbsolutePath != "/dev/null") {
if (pidFile.exists) {
println("This application is already running (Or delete "+ pidFile.getAbsolutePath +" file).")
System.exit(-1)
}

new FileOutputStream(pidFile).write(pid.getBytes)
Runtime.getRuntime.addShutdownHook(new Thread {
override def run {
pidFile.delete()
}
})
}
}
}
[/scala]

PIDファイルの場所をカスタマイズするには、pidfile.pathというオプションにPIDファイルのパスを指定すれば良いようです。

ということで、プロジェクトの起動パラメータとして
[text]-Dpidfile.path=/tmp/hogeproj.pid[/text]
という感じに指定します。

Rubyで配列からハッシュを作成する

たまに、配列になっているデータをハッシュに変えてしまいたい時があったりします。

data = [[0, ‘データ1’], [1, ‘データ2’], [2, ‘データ3’], [3, ‘データ4’], [4, ‘データ5’]]

という感じのデータですね。

これをハッシュにするには、ゴリゴリやる場合

hash_data = {}
data.map{|c| hash_data[c[0]] = c[1]}

となりますが、別のやり方として

Hashの「self[*key_and_value] -> Hash」というメソッドを使ってみます。

Rubyのドキュメントにもあるのですが

Hashの[]メソッドとして定義されており

array_data = [a0, ‘データ1’]
Hash[*array_data]という感じにすると、
{0 => ‘データ1’}
というハッシュを作ってくれます。

所が、このメソッドは今回の例のdataの配列のような2重配列は対応していないので

ハッシュを作る際にhash_dataを平滑化する必要があります。

これを踏まえて最終的には

Hash[*data.flatten]

と書くと、良い感じにハッシュになります。

ちなみに、この時self[*key_and_value]に渡す配列ですが、偶数個でしか受け取りません。

奇数個の配列を渡すと例外が発生します。