processing png

2012-02-02: processing.js へのリンクが切れて画像が生成されなかった問題を修正

web や iOS app の開発をしているときにボタンとかに使うチマチマした画像が必要なことがあります。いままでは Seashore でドットを打ったりしてましたが、 Processing.js を使うとプログラムで簡単に絵を描くことができるので、プログラマとしては色やサイズの微調整とかの応用がしやすいですね。

以下は iframe に展開したデモです。 m とか s の値を変えて update すると更新されるのがわかるかと思います。


基本的には Processing.js Web IDEの簡易版ですが、 canvas の内容を img タグに画像としてコピーしているので、その画像をファイルとして保存すれば素材として使えます。

現状、ワークフロー的にはローカルリポジトリのファイルとブラウザ上の textarea, img との手作業のコピペが何度も発生するので洗練されてませんが、工夫すればもうちょっとマシになるかもしれません。

ソースのhtmlは gist にあります (raw を iframe の src に指定すると text/plain になっちゃってダメなので dropbox のファイルを参照)

goo.gl Automator service

Mac で選択したテキストのURL短縮できると便利だと思って、調べてみると bit.ly の API を使って Apple Script で実装されたやつは見つかったんですけど、 API key が必要なのは面倒だし Apple Script はいやなので goo.gl を利用するサービスを shell と ruby で書いてみました。



このサービスは選択したテキスト(URL)を短縮して置換します。元のURLは念のためにクリップボードに保存します。
テキストを置換するので、編集可能なテキストしかダメなので、逆に短縮 URL をクリップボードに保存したい人は改造してください。

Automator で作ったサービスは裏で "/System/Library/CoreServices/Automator Runnder.app" を起動して実行するんですけど、コイツの起動が遅いのでメニューバーに常駐する app がサービスを提供する感じにしたほうが速くなると思うのでそのうちに...。

goo.gl の API は ApiKey 無しではあんまり頻繁に実行するとダメかもしれないので、ヘビーに使う人は goo.gl API の詳細: Getting Started - Google URL Shortener API - Google Code を見て自分の ApiKey を設定してみたりしてください。

ちなみにこの記事のコード部分には gist を使ってるんですけど、gist への投稿もサービスでできたら(たぶん使わないけど)便利だと思いましたが、 gist を作成する API は Coming soon だそうです (2011-04-19 現在)。

alias_method_chain for Objective-C

Objective-C の runtime でも ruby のようにメソッドの入れ替えなどを動的に実行できるんですけどいろいろと面倒なので、 alias_method_chain の Objective-C 版を書いてみました。

Iodine-131 in tap water in tokyo

ついに東京の水道水にもヨウ素131が混入するようになったそうなので怖くなってリスクをざっくりと計算してみた。

水道水の放射能測定結果について / 第17報 / 平成23年3月23日 / 東京都水道局
金町浄水場: 2011/3/22 9時 I-131 210 Bq/kg
緊急時における食品の放射能測定マニュアル / 平成14年3月 / 厚生労働省医薬局食品保健部監視安全課
I-131(ヨウ化メチル以外の化合物) を幼児が経口摂取した場合の実効線量係数 0.000075 mSv/Bq

ベクレルをシーベルトに換算すると
210Bq/kg * 0.000075mSv/Bq = 0.01575mSv/kg

シーベルト - Wikipedia
これ以上はヤバイかなという値を 100mSv とすると
100mSv / 0.01575mSv/kg = 6,349.2kg (およそ 6t)

一日1L(1kg)水道水を飲んだりすると
6349.2kg / 365日 = 17.39年 で 100mSv に到達

まあ、とりあえずはドキドキしながら暮らすとして、
今後数ヶ月にわたって改善されないと引っ越したくなりますね。

免責条項
- 浄水場から蛇口までの話はわかりません。
- ヨウ素の半減期8日についても考慮してません。
- セシウム134やセシウム137についてはどうなんでしょう。
- 当然ですが、計算間違いの可能性、または仮定の間違いなどあるかと思うので、気になる人は検算してください。

use transactional_fixtures with capybara akephalos driver

You may turn on transactional fixtures with Capybara akephalos driver (it may work with selenium driver too) having the monkey-patch below in spec_helper.rb or somewhere else.

akephalos driver を使っている場合でも以下のコードを spec_helper.rb にでも書いておくと transactional_fixtures を有効にできそうです。 (たぶん selenium などでも同様)

ActiveRecord::ConnectionAdapters::ConnectionPool.class_eval do
  def current_connection_id
    # Thread.current.object_id
    Thread.main.object_id
  end
end

かなり無茶苦茶な変更なので ActiveRecord を非同期に使うコードがあるとアウトなので要注意。

以下は簡単な説明です。

Capybara はデフォルトではサーバーも仮想ブラウザもテストを実行している ruby のプロセス内で同期的に処理するので ActiveRecord の connection をテストとサーバーで共有でき、 transactional_fixtures が使えます。

しかし、 Selenium driver の場合ブラウザは本物、 Akephalos は HtmlUnit という Java の仮想ブラウザを別プロセスで実行しています。
そのため、テストのサーバーも実際の http リクエストを処理する必要があるので、 Capybara は thin や webrick を別スレッドで実行することにより対処しています。

一方、 ActiveRecord の ConnectionPool は connection のレースコンデションを避けるためにスレッド毎に異なる connection を返すため、 fixtures ロードを含むテストとサーバーは同一トランザクションにはなりません。

そこで、無理矢理に異なるスレッドでも ConnectionPool が同じ connection を返すように変更。真面目にこの問題に対応するためには、別スレッドでサーバーを起動せずにリクエストをブロックして rack-test で処理すればできそうな気も。

smart pointers for Core Foundation style references

iOS や mac のアプリケーションを書くときに Objective-C を使うときでも、 Core Graphics などの C の API を使うときは CGImageRef などのリファレンスの開放とか面倒です。特に関数の途中で return したり、C++ のライブラリを使用するときの例外処理を考えるとウンザリです。メモリリークのリスクも高まるし。

void doSomething(void) {
  CGImageRef image = CGImageCreate(......);
  
  // do something...
  
  if (some condition...)
    CGImageRelease(image);
    return;
  }
  
  try {
    CPlusPlusClass::aFunction()
  } catch (...) {
    CGImageRelease(image);
    return;
  }
  
  // use image...
  
  CGImageRelease(image);
}

Objective-C のオブジェクトなら最初に autorelease しておけばいいんですけどね(iOS でなければガベージコレクションも使えるし)。

そんなときは C++ のテンプレートで smart pointer 的なリファレンスのラッパーを書けば、ことあるごとに XXXXRelease(ref) しなくて済みます。


これで、こんなふうに書けるようになります。

#include "AutoRef.h"

void AutoRefRelease(CGImageRef ref) { CGImageRelease(ref); }

void doSomething(void) {
  AutoRef image = CGImageCreate(......);
  
  // do something...
  
  if (some condition...)
    return;
  }
  
  try {
    CPlusPlusClass::aFunction()
  } catch (...) {
    return;
  }
  
  // use image...
}

Objective-C のコードで C++ のコード使う場合(Objective-C++)は、拡張子を .mm に変えるを忘れずに。

a Lifehack for the redirection problem of lifehacker.com

If you can't understand Japanese, please go to English part of this post.

2011-02-24: mac の場合 「プロキシ構成ファイル」として gist の "view raw" リンク の URLを指定すればOKなことに気がついた
2011-02-24: gizmodo もダメだったので追加
2011-02-24: pacファイルを gist に

最近、僕の自宅から lifehacker.com にアクセスすると lifehacker.jp にリダイレクトされるようになってしまっていました。

調べてみると、みんなが見たい USサイトは us.lifehacker.com で、グローバルな lifehacker.com へのアクセスは親切なことになんらかの情報(アクセス元のIPアドレス?)をもとに各国の lifehacker にリダイレクトしているようです。

で、何が問題かと言うと、最悪なことに
USサイトのフィードの記事、たとえば、
"Disable or Restrict Plug-Ins in Chrome to Prevent Malware Installs [Security]" のリンク先、
http://feeds.gawker.com/~r/lifehacker/full/~3/zLgSu5CwbAM/
のリダイレクト先は
http://lifehacker.com/#!5757551/disable-or-restrict-plug+ins-in-chrome-to-prevent-malware-installs
なので、lifehacker.jp にリダイレクトされてしまって、該当の記事が読めないという具合。

本題の、この問題を回避するライフハックは、以下の javascript コードを lifehacker.pac みたいな名前で保存して、プロキシ構成 (.pac) ファイルとして設定することによりリダイレクトを回避します (Mac OS X の場合です。 Windows とかはよくわかりませんが、たぶん同じような設定がどっかにあります。)


最後に、こんなすばらしいライフハックを思いつくきっかけを与えてくれた lifehacker のリダイレクト仕様に感謝します。というか、早く直してください。お願いです。

LifeHacker の運営母体? Gawker Media Tech のサポートサイトでも、Stop redirecting to Japanese site!! 同じような問題が放置されてしまっているようですね。

以下、日本人以外のひと用。

If you are annoyed with the lifehacker redirect problem like this, Stop redirecting to Japanese site!!, this may be a help.

SET FOLLOWING SNIPPET AS A PAC FILE:

Or just use URL to "view raw" link above as "Proxy configuration File" URL.

If you don't have any clue about "pac file", try Proxy auto-config - Wikipedia, or if you use mac, see Apple's support page about pac file.

That's it.