tool

The Web engineer's online toolboxというまとめ記事が便利そうだったので、実際に試しつつ抄訳してみました。(一部のコメントと体裁は変えています。)

目次

一覧

RequestBin

httpリクエストを保存するエンドポイントを作ってくれる。

Create a RequestBin のボタンをクリックするとURLが表示されるので、そこをHTTPクライアントからたたくとRequestBin側にリクエスト内容が記録される。 ソースも公開されてるのでローカルで立ちあげることもできる。

githubのwebhookのhelpも参考にどうぞ。

Hurl

httpリクエストを実行してくれる。パーマリンクも作ってくれるので、POSTリクエストもコピペで他の人と共有できる。

• 類似サービス: REST test test , Apigee console

httpbin

HTTPリクエスト側でレスポンスのHTTP status codeやレスポンスやリダイレクト、cookieなどを制御できる。HTTPクライアントのテストに便利。

• 類似サービス: UrlEcho

REDbot

HTTPのリソースをチェックしてくれる。問題を検出したら改善案のサジェストもしてくれる。

• 類似サービス: HTTP lint

WebGun

webhookを簡単に作るためのAPIを提供している。現在はまだベータっぽい。

Apify

ウェブページをスクレイピングしてJSON API化してくれる。 CSSセレクタかxpathに名前をつけて設定するだけでよしなにやってくれる。

試しに元記事をAPI化してみた

Unicorn

前述のREDbotはHTTPをチェックしてくれるけど、こちらはHTMLドキュメントがW3Cに準拠してるかをバリデートしてくれる。

• 類似サービス: HTML lint

Feed validator

こちらはRSSとATOMフィードをバリデートしてくれる。

Link checker

リンクを再帰的にたどって、重複やリンク切れをチェックしてくれる。

Host tracker

ウェブサイトのモニタリングサービス。定期的にpingして、問題があった場合はメール通知してくれる。

• 類似サービス: Down for everyone or just me, Pimgdom ping service

Pingdom Full page test

ウェブページのロード時間を計測、解析してくれる。リクエストを実行するサーバは米国しかないので国内だとちょっと使いづらい。 類似サービスのWeb page testならTokyoが選べる。

HAR viewer

HTTP tracking toolsで生成されたHTTP Archive (HAR)形式のログをビジュアライズしてくれる。

CORS proxy

クロスドメインでjsを実行できるようにヘッダを追加してレスポンスしてくれるプロキシ。

Browserling

ブラウザ上で動くインタラクティブなクロスブラウザ。メジャーなブラウザは大体サポートされている。 動作は重いけど表示確認くらいになら無料のままでも使えそう。

WebSocket Echo Test

WebSocketをテストできるエコーサーバ。

YQL

ウェブサービスからとってきたデータをSQLっぽい言語で整形できる。

Yahoo Pipes

ウェブサービスをGUIでマッシュアップできる。

Apiary

良い感じのREST APIドキュメントをインタラクティブなインスペクタをつかってジェネレートできる。まだベータ。

• 類似サービス: Swagger

おわりに

• いくつかのツールはサーバに負荷をかけてしまう可能性があるので注意してつかってください。
• 他にもなにかあれば教えてもらえるとうれしいです。

shader

最近はUnityを使う機会を得たのでゲーム関連技術についていろいろ調べてました。

Shadow Algorithms for Real-time Rendering

シェーダーを扱った講義資料らしい。この講義を元にした本がでていて日本語翻訳もあるみたいです。 モデリングは絵心がないとちょっと難しそうだけど、こういうのであれば自分で書いてみたいです。

black-tie

ノイズ生成アルゴリズムというものに興味がわきました。残念ながらこのライブラリはあまりメンテはされてない。

物理演算系ライブラリ

2次元剛体のシュミレーションならChipmunkとかBox2Dあたりで気軽にできそうですが、3次元のやわらかいもの表現するにはちょっとハードルがあがるようです。

• BULLET
• SOFA
• opencloth

物理演算を駆使した3次元リアルぷよぷよがやってみたいです。

mixamo

こういう素材がもっと増えるといいですね。

lisp

先週くらいに読んだWEB+DB PRESS Vol.42 に載っていたFront Coding という圧縮アルゴリズムを実装してみました。

http://d.hatena.ne.jp/naoya/20080914/1221382329 のパクりです。

ソースはhttps://github.com/taksatou/cl-frontcodingです。

学習目的でつくったので実用的なライブラリではないですが、CLOSやマクロを使いつつパッケージ作成〜テストまで一通りやりました。

CLOSもマクロも基本的な使い方をするだけなら意外と簡単でした。

CLOSとかマクロは本を読んでもいまいちよくわからない上に、深淵なイメージが膨らんで心理的ハードルがあがってしまうだけなので、よくわからないなりになにか作ってみると理解が進んでいいと思います。

lisp

Common Lispのdeclareについて調べた。 変数の型や式に関することをコンパイラに伝えてやるために使うものらしい。

例えば、

(defun add (x y) (+ x y))

は

(defun add (x y)
 (declare (fixnum x y))
 (the fixnum (+ x y)))

とすれば、引数と戻り値の型を指定できる。

さらに、

(defun add (x y)
 (declare (optimize (speed 3) (safety 0)))
 (declare (fixnum x y))
 (the fixnum (+ x y)))

とすればさらに最適化される。ここまですると、Cで実装した場合と遜色ないくらいになるらしい。

ためしにdisassembleしてみた。処理系はsbcl 1.0.55.0。

最初のバージョンは以下のようになった。すでにある程度最適化されてる? LEA(load effective address)命令は、srcオペランドのアドレスを計算し、そのアドレスをdestオペランドにロードするというものらしい。(参考)

CL-USER> (defun add (x y) (+ x y))
CL-USER> (disassemble #'add)
; disassembly for ADD
; 03C43D5D: 488B55F8 MOV RDX, [RBP-8] ; no-arg-parsing entry point
; 61: 488B7DF0 MOV RDI, [RBP-16]
; 65: 4C8D1C25E0010020 LEA R11, [#x200001E0] ; GENERIC-+
; 6D: 41FFD3 CALL R11
; 70: 480F42E3 CMOVB RSP, RBX
; 74: 488BE5 MOV RSP, RBP
; 77: F8 CLC
; 78: 5D POP RBP
; 79: C3 RET
; 7A: CC0A BREAK 10 ; error trap
; 7C: 02 BYTE #X02
; 7D: 18 BYTE #X18 ; INVALID-ARG-COUNT-ERROR
; 7E: 54 BYTE #X54 ; RCX

2番目の、型だけを宣言したものは以下のようになった。うーむ、確かに型チェックっぽいコードは増えてるが速くなってるわけではなさそうな感じ。あとで調べる。

CL-USER> (defun add (x y)
 (declare (fixnum x y))
 (the fixnum (+ x y)))
CL-USER> (disassemble #'add)
; disassembly for ADD
; 039D3B73: 488BD1 MOV RDX, RCX ; no-arg-parsing entry point
; 76: 48D1FA SAR RDX, 1
; 79: 488BC7 MOV RAX, RDI
; 7C: 48D1F8 SAR RAX, 1
; 7F: 4801C2 ADD RDX, RAX
; 82: 48B80000000000000040 MOV RAX, 4611686018427387904
; 8C: 4801D0 ADD RAX, RDX
; 8F: 48C1E83F SHR RAX, 63
; 93: 7509 JNE L0
; 95: 48D1E2 SHL RDX, 1
; 98: 488BE5 MOV RSP, RBP
; 9B: F8 CLC
; 9C: 5D POP RBP
; 9D: C3 RET
; 9E: L0: 486BC202 IMUL RAX, RDX, 2
; A2: 710E JNO L1
; A4: 488BC2 MOV RAX, RDX
; A7: 4C8D1C25B0050020 LEA R11, [#x200005B0] ; ALLOC-SIGNED-BIGNUM-IN-RAX
; AF: 41FFD3 CALL R11
; B2: L1: 488B1557FFFFFF MOV RDX, [RIP-169] ; 'FIXNUM
; B9: CC0A BREAK 10 ; error trap
; BB: 03 BYTE #X03
; BC: 1F BYTE #X1F ; OBJECT-NOT-TYPE-ERROR
; BD: 15 BYTE #X15 ; RAX
; BE: 95 BYTE #X95 ; RDX
; BF: CC0A BREAK 10 ; error trap
; C1: 02 BYTE #X02
; C2: 18 BYTE #X18 ; INVALID-ARG-COUNT-ERROR
; C3: 54 BYTE #X54 ; RCX
; C4: CC0A BREAK 10 ; error trap
; C6: 02 BYTE #X02
; C7: 08 BYTE #X08 ; OBJECT-NOT-FIXNUM-ERROR
; C8: 95 BYTE #X95 ; RDX
; C9: CC0A BREAK 10 ; error trap
; CB: 04 BYTE #X04
; CC: 08 BYTE #X08 ; OBJECT-NOT-FIXNUM-ERROR
; CD: FED501 BYTE #XFE, #XD5, #X01 ; RDI

最後の最適化の宣言をつけたものは以下のようになった。たしかに速そうにはなった。

CL-USER> (defun add (x y)
 (declare (optimize (speed 3) (safety 0)))
 (declare (fixnum x y))
 (the fixnum (+ x y)))
CL-USER> (disassemble #'add)
; disassembly for ADD
; 034DD10F: 4801FA ADD RDX, RDI ; no-arg-parsing entry point
; 12: 488BE5 MOV RSP, RBP
; 15: F8 CLC
; 16: 5D POP RBP
; 17: C3 RET

ついでにCで書いた以下の関数もdisassebleしてみた。

int add(int x, int y) {
 return x + y;
}

cc -c a.c && objdump -d a.o とすると、

a.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <add>:
 0: 55 push %rbp
 1: 48 89 e5 mov %rsp,%rbp
 4: 89 7d fc mov %edi,-0x4(%rbp)
 7: 89 75 f8 mov %esi,-0x8(%rbp)
 a: 8b 45 f8 mov -0x8(%rbp),%eax
 d: 8b 55 fc mov -0x4(%rbp),%edx
 10: 01 d0 add %edx,%eax
 12: 5d pop %rbp
 13: c3 retq

cc -O3 -c a.c && objdump -d a.o なら、

a.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <add>:
 0: 8d 04 37 lea (%rdi,%rsi,1),%eax
 3: c3 retq

まあとりあえず単純に命令数だけでいうと、 素のSBCL > 素のGCC > 最適化したSBCL > 最適化したGCC という感じにはなったので、CよりLispのほうが速い(場合もある)というふれこみは嘘ではなさそうですね。

android

これまでandroidアプリを開発しててはまったことがたまってきたのでまとめておきます。順不同です。 その2はまたねたがたまってきたらたぶんそのうち。

目次

onAnimationEndでviewの階層を操作するとNullPointerExceptionでおちる

Viewをフェードアウトして親Viewからremoveする、というような動作をしたい場合に、普通にonAnimationEndの中でremoveViewとかするとNullPointerExceptionでおちます。onAnimationEndの中でViewの階層構造を操作するような処理をしてはだめらしいです。回避するには、Handlerをつかってタイミングをずらしてやるとよいです。

• 参考: http://stackoverflow.com/questions/5569267/nullpointerexception-that-doesnt-point-to-any-line-in-my-code

Animationが動かない

AnimationさせるViewには親Viewが存在している必要があります。WindowManagerはViewではないので、WindowManagerにaddViewしたViewをアニメーションさせたい場合は空のRelativeLayoutとかにaddViewしてから、RelativeLayoutのほうをWindowManagerにaddViewしてやる必要があります。

WindowManagerにaddViewしたときの挙動

WindowManagerにもaddViewできますが、通常のViewとは挙動が違います。

• 背景透過はWindowManager.LayoutParam.format に TRANSLUCENT をセットすればよいです。
• dimでフェードインできますが、その際のdurationを変更する方法は分かりませんでした。
• BACKボタンはきかなくなります。自分でKeyEventを処理してやる必要があります。android.widget.PopupWindowのdispathKeyEventのソースが参考になります。

Activityが横向きでスタートした場合と縦向きでスタートしたときで表示倍率が違う

• 参考:http://d.hatena.ne.jp/acidgraphix/20110126/1296018143

onCreateが何回もよばれる

回転やキーボード表示のタイミングでもonCreateがよばれます。AndroidManifest.xmlでconfigChangesを設定することで回避できます。

• 参考: http://stackoverflow.com/questions/2606470/unexpected-resume-of-package-name-while-already-resumed-in-package-name-err

popupWindowのサイズが変わらない

popupWindowのsetWidth, setHeightは次回以降の表示サイズしか変えられません。既に表示しているポップアップウィンドウのサイズはそのままです。invalidateしても無駄です。

HttpURLConnectionが 0byteのresponseを返す

コネクションプールとkeepaliveがらみで問題が発生する場合があるみたいです。SDKのバージョンとウェブサーバ側の設定も影響します。 System.setProperty("http.keepAlive", "false") で回避はできるようです。これに遭遇したときは、org.apache.http.impl.client.DefaultHttpClientの方を使うことにしたので詳細は追ってません。

• 参考: http://stackoverflow.com/questions/1440957/httpurlconnection-getresponsecode-returns-1-on-second-invocation

org.apache.http.impl.client.DefaultHttpClientがすごく遅い

httpsでリクエストを投げると、ウェブサーバ側の負荷が高いわけでもネットワークが細いわけでもないのに、返ってくるまでなぜか数秒かかる場合があります。こちらもkeepaliveがらみの問題っぽいです。これもウェブサーバ側の設定が影響します。 試した限りでは以下のような状況でした。

• setHeader("Connection", "close") しても効果なし
• setKeepAliveStrategyでdurationを 0とか1にしても効果なし
• Connection closeしないウェブサーバならすぐレスポンスが返ってくる
• httpならすぐレスポンスが返ってくる

ここ( http://hc.apache.org/httpclient-3.x/sslguide.html ) のKnown limitations and problemsをみるとそれっぽい既知の問題があるようですが、根が深そうだったので詳細は追ってません。

eclipseのAndroid pluginが動かなくなった

なぜかeclipseでAndroid pluginが動かなくなるときがありました。詳細をメモるのを忘れてしまいましたが、以下の手順で直ったような気がします。

1. Android Support Libraryをアンインストール
2. eclipse再起動
3. 新しいAndroidプロジェクトを作るとダイアログでライブラリのインストールを促されるのでそれに従う
4. android プラグインをアップデート

WebViewで表示されるコンテンツが小さすぎる

通常ビューのスケールとWebViewのスケールは別です。setScaleで調整する必要があります。 これはたぶんiOSでも同様かと。

java.lang.RuntimeException: Stub!

android.jar内のコードはdalvikvmの外で実行することはできません。問答無用でタイトルの例外が飛びます。 エラーメッセージはもうちょいなんとかならなかったのか。

参考

• http://stackoverflow.com/questions/7247502/using-android-jar-in-java-project-runtimeexception-stub
• http://www.slideshare.net/miyatay/abc2011w

jarとして配布するandroidライブラリ内にリソースを埋め込むことはできない

リソースIDを列挙しているRパッケージはjarにそのまま入れることはできますが、そのリソースIDは不正なものとなります。 ライブラリにリソースを含めたい場合は、ソースも含めたプロジェクトをまるごと配布するしかないようです。

ごく小さなアイコン画像だけとかであればバイナリデータをソース中に埋め込んでしまう、というのも手です。 iOSならBundleという仕組みがあります。

android-maven-plugin から mvn eclipse:eclipse でeclipse用にエクスポートすることはできない

androidでもmavenは使えますが、androidのmavenプロジェクトは通常の方法(mvn eclipse:eclipse)ではeclipseにインポートできません。 以下のファイルを手動でつくってみたらとりあえずいけました。

• .classpath

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
 <classpathentry kind="src" path="src/main/java"/>
 <classpathentry kind="src" path="gen"/>
 <classpathentry kind="con" path="com.android.ide.eclipse.adt.ANDROID_FRAMEWORK"/>
 <classpathentry kind="con" path="com.android.ide.eclipse.adt.LIBRARIES"/>
 <classpathentry kind="output" path="bin/classes"/>
</classpath>

• .project

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
 <name>project-name</name>
 <comment></comment>
 <projects>
 </projects>
 <buildSpec>
 <buildCommand>
 <name>com.android.ide.eclipse.adt.ResourceManagerBuilder</name>
 <arguments>
 </arguments>
 </buildCommand>
 <buildCommand>
 <name>com.android.ide.eclipse.adt.PreCompilerBuilder</name>
 <arguments>
 </arguments>
 </buildCommand>
 <buildCommand>
 <name>org.eclipse.jdt.core.javabuilder</name>
 <arguments>
 </arguments>
 </buildCommand>
 <buildCommand>
 <name>com.android.ide.eclipse.adt.ApkBuilder</name>
 <arguments>
 </arguments>
 </buildCommand>
 </buildSpec>
 <natures>
 <nature>com.android.ide.eclipse.adt.AndroidNature</nature>
 <nature>org.eclipse.jdt.core.javanature</nature>
 </natures>
</projectDescription>

• project.properties

# Project target.
target=android-10
# if it is a library
# android.library=true

まあ、なんというか、Androidはいろいろ残念ですね。

iOSはこういう仕様なのかバグなのかよくわからないようなものが少ないし、OSバージョンの入れ換わりが早くて対応バージョンも少なくて済む分、個人的な体感ではandroidアプリの工数はiOSの3割増しという感じ。