weinre最新版(2.0.0)を使いたいのでnode.jsからなにやらインストールした
windowsで使っていたweinreは1.6のjava版を使っていた。 久しぶりにweinre気になったのでみてみたら2.0.0が出てるので、インストールしようとしたらnode.jsで動くようになっていた。
windowsでなにかするの大変そうな気がしたので、いつも起動してvmware(centos)から動かすことにした。
node.jsのインストール
http://nodejs.org/dist/
から最新版をwgetして解凍
./configure make make install
いつもの感じでインストール出来るんだけど、コンパイル時間かなりかかった
npmもインストールされるので cofee-scriptをインストール
npm install -g coffee-script
weinreの最新版を取得
http://people.apache.org/~pmuellr/weinre/builds/2.0.0-pre-H41DGW8S-incubating/
中にあるweinreを起動すればＯＫ
./weinre --boundHost 192.168.1.22 --httpPort 5111
起動するとウェブからweinreにアクセスできる。
jquery mobileでアップロード後ページが変わっちゃうとか
jquery mobileでは
<div data-role="page" id="hoge">
ajax enable（デフォルト）の場合data-role="page"の中身が変わる、なのでidが重複してしまう場合にページが移動してしまうなんかの動作になる。 けっこうはまるポイントではあるんだけど、何も考えずにidを書いていくとはまる事がある。
勘違いかもしれないけどidが重複していないのに、ajaxでファイルをアップロードしたりとかのあと、ページが飛んでしまうことがある。 で、原因がよくわからなかったんだけど、
$(document).delegate('#datarole_smart_post', 'pageshow', function(){
...ここにいれちゃえ
}data-role="page" にidを指定して pageshowつまりページ表示時に発火するようにjavascriptなんかを書き込んでみたところ、問題なく動作するようになった。
jquery mobileの場合複雑な動作をさせようとすると意図しない動作になってしまう事があって、これはjquery mobileの動作をよく理解しないからなんだろうなと考えるようになった。 jquery mobileではdata-role=page以外の部分は共有されているのがはまるポイントなんだろうと思います。 jquery mobileやphonegapのせいにしてしまう時は、よくよくドキュメントを読んでみたり、信頼できるブログなどを見るすることをお勧めします。
結構jquery mobileはお手軽に動くだけに、jquery mobile関連のブログ記事は見つかるけど、逆にありふれてて本当に信頼できる情報なのかどうかわからない場合もあるような気がします。
サーバ屋さんのバックアップはサービスか義務か？
ファーストサーバの件で顧客データがウェブ、メール、ＤＢも全部消えた。
利用者は阿鼻叫喚。 ファーストサーバも真っ青な状態ですが、バックアップは義務なのか、サービスなのか？であります。
利用者側としては何か問題があったとき（つまりデータが消えたとき）、バックアップもとってないのか！ありえねーとか書いています。 「バックアップは義務」は利用者側の考え。
それに対してバックアップは規約にも書いてあるように、利用者側でやってもらうスタンスを取っているところがほとんどではないかと思います。 またバックアップをサービス（売りとして）として提供している所もあるわけですよね。 もちろんバックアップは大量のディスクが必要なのでかなりのコストがかかります。
逆にバックアップちゃんととってまっせーっていうサービスを売りにしている所は逆に損する感じになる。
うちはバックアップちゃんとしてるのに・・・（´･ω･`）
利用者側の希望 バックアップぐらい普通してるだろ！
業者側では うちではバックアップはしてませんよ。 規約にも利用者側でやってね！
すさまじいコスト競争の中、バックアップにお金かけるなら、売りにしたいよね的なサービスと、利用者側の期待で普通どんなサーバ屋さんでもバックアップしてるだろっていう希望のずれ こういうのは利用者側もちゃんと見てわかっておかないと駄目なんじゃないかなーと思うわけです。
レンタルサーバデータ消滅事件判決
http://support.fsv.jp/info/nw20120625_01.html
の件に関係すると思うけど、以下のようなレンタルサーバデータ消滅事件判決ってのが過去にあった。
１ 乙事件被告（甲事件原告）は，乙事件原告（甲事件被告）に対し，２２６３万５０００円及びこれに対する平成１２年９月１９日から支払済みまで年６分の割合による金員を支払え。
http://www.law.co.jp/cases/lh.htm
これは、約款に問題があった系？で、最近のサーバ屋さん側では対策済みって事なんでしょうか。たぶん。
大規模障害の概要と原因について（中間報告） ファーストサーバ サポートWEB
http://support.fsv.jp/info/nw20120625_01.html
ファーストサーバの出来事でバックアップと予備は別だ！系のお話が結構出てますね。
いやその通りかもだけど、問題はバックアップ分のコストかけたくない、かけれないって事じゃないかなと。 価格競争の中、安いサーバには安いわけがあること。 そしてリスクを外部に投げたい企業と、ウェブ屋さんにも問題があるのかなと。
被害にあった企業さんの中でもダメージを最小に出来た所と、リスクを考えていなかったところと大きく分かれているようです。 自分たちでちゃんとデータを持っていたところは復旧が速かったようです。
それと、サーバの選定はおそらくウェブ屋さんも多少関わってると思うわけで、ウェブ屋さんにもある意味責任はあるような気もする。 いつも使っててなれてるから、いつもの所を使おうって事になりがちだし。 たぶんウェブ屋さんも、何かあったときにサーバ屋さんのせいに出来る訳なので、自分ではサーバを持ちたくない。 コストの事だけじゃなく、自分たちでやりたくない部分は結構ありそう。 結果自分達でコントロールできる部分を捨ててしまって、何かあったときに自分たちでは何も出来ない状態になってる。
利益を得る大事なウェブだったりサーバにお金をかけなかったことは自分の責任で、企業側もこれからどんなサーバを選ぶべきか、予備としてデータのバックアップはもちろん、実際に動作する予備のサーバもちゃんと考えなければならない事に気が付いたんじゃないかなと。
リスク回避と、自分たちのコントロール出来ない部分を少しでも減らすためにも、本番環境のサーバと、予備サーバは別のサーバ（業者）にするべきだよね。
ケガしたから誰々のせいだ！とか言っていいのは小学生までだよね的な
cronメールはgmailで処理すればいいんじゃね
http://d.hatena.ne.jp/sfujiwara/20120613/1339547638
cron で > /dev/null して椅子を投げられないための3つの方法を見た。
たしかにcronで実行された結果が誰も見たくない情報を「大量」に送られてくるのはいろいろ大変。
でも後から何かあったとき調べたいときにデータが無いのもつらい。
とはいえ、実行頻度が多かったり出力が大量だったりすると、メールが届きすぎ → フィルタで既読 or ゴミ箱直行 になってしまって、結局読まれない運命になります。
んいちいち読む必要なくて、必要なとき見られればいいだけじゃないかなと
うちの場合は単純にcronでmailtoでgmailに投げている。 gmailだと検索も出来るし、目立たない。これで良いんじゃないかなと思う。 ものすごい古い奴は消してしまえば良いだけだし、そもそも消す必要もないし。
うちらは大手じゃないし、中小やＳＯＨＯクラスならこれでいいんじゃね的な感じが。
Nginx 変数メモ
$arg_PARAMETER
この変数が存在する場合、クエリ文字列でGET要求変数パラメータの値を含む
This variable contains the value of the GET request variable PARAMETER if present in the query string
$args
この変数は、例えば、要求行でGETパラメータです。 FOO =123＆バー= blahblah、この変数は変更される場合があります。
This variable is the GET parameters in request line, e.g. foo=123&bar=blahblah; This variable could be changed.
$binary_remote_addr
バイナリ形式でクライアントのアドレス;
The address of the client in binary form;
$body_bytes_sent
レスポンスのボディの一部として送信されたバイトの量です。接続が中止または中断された場合であっても正確です。
The amount of bytes sent as part of the body of the response. Is accurate even when connections are aborted or interrupted.
$content_length
headerのContent-Length
This variable is equal to line Content-Length in the header of request;
$content_type
headerのContent-Type
This variable is equal to line Content-Type in the header of request;
$document_root
ディレクティブのルート値
This variable is equal to the value of directive root for the current request;
$host
この変数はこのような場合には$ HTTP_HOST異なる値があります：ホスト入力ヘッダーが存在しない値または空値を持つ場合）
1、$hostは、server_nameディレクティブの値に等しい
2）$hostの値は、ポート番号が含まれている場合、 $hostがそのポート番号が含まれていません。
$hostの値はバージョン0.8.17以降小文字
This variable is equal to line Host in the header of request or name of the server processing the request if the Host header is not available.
This variable may have a different value from $http_host in such cases: 1) when the Host input header is absent or has an empty value, $host equals to the value of server_name directive; 2)when the value of Host contains port number, $host doesn't include that port number. $host's value is always lowercase since 0.8.17.
$hostname
gethostnameによってに設定
Set to the machine's hostname as returned by gethostname
$http_HEADER
The value of the HTTP request header HEADER when converted to lowercase and with 'dashes' converted to 'underscores', e.g. $http_user_agent, $http_referer...;
$sent_http_HEADER
The value of the HTTP response header HEADER when converted to lowercase and with 'dashes' converted to 'underscores', e.g. $sent_http_cache_control, $sent_http_content_type...;
$is_args
Evaluates to "?" if $args is set, "" otherwise.
$limit_rate
この変数は、接続速度を制限することができます。
This variable allows limiting the connection rate.
$nginx_version
現在実行されているnginxのバージョン
The version of Nginx that the server is currently running;
$query_string
この変数は読み取り専用であることを除けば、$argsと同じ
The same as $args except that this variable is readonly.
$remote_addr
クライアントのIPアドレス
The address of the client.
$remote_port
クライアントのポート番号
The port of the client;
$remote_user
この変数は、BASIC認証によって認証されたユーザーの名前
This variable is equal to the name of user, authenticated by the Auth Basic Module;
$request_filename
この変数は、ディレクティブのルートまたは別名とURI要求から形成され、ファイルパスに等しい
This variable is equal to path to the file for the current request, formed from directives root or alias and URI request;
$request_body
バージョン0.7.58以降
request body
This variable(0.7.58+) contains the body of the request. The significance of this variable appears in locations with directives proxy_pass or fastcgi_pass.
$request_body_file
request bodyの一時的なファイル名
Client request body temporary filename;
$request_completion
要求が正常に完了した場合は、"OK"に
Set to "OK" if request was completed successfully. Empty if request was not completed or if request was not the last part of a series of range requests.
$request_method
request method 通常はGETまたはPOST
This variable is equal to the method of request, usually GET or POST.
This variable always evaluates to the method name of the main request, not the current request, when the current request is a subrequest.
$request_uri
request uri 変更することはできません。
This variable is equal to the *original* request URI as received from the client including the args. It cannot be modified. Look at $uri for the post-rewrite/altered URI. Does not include host name. Example: "/foo/bar.php?arg=baz"
$scheme
HTTP方式（すなわちHTTP、HTTPS）
The HTTP scheme (i.e. http, https). Evaluated only on demand, for example:
rewrite ^ $scheme://example.com$uri redirect; $server_addr
サーバのアドレス。一般的にnginxのは、システムがこの値を取得するために呼び出すことができます。効率を改善し、このシステムコールを避けるために、ディレクティブを聞いて、バインド·パラメータを使用するとアドレスを指定します。
The server address. Generally nginx makes a system call to obtain this value. To improve efficiency and avoid this system call, specify an address with the listen directive and to use the bind parameter.
$server_name
サーバ名
The name of the server.
$server_port
サーバポート
This variable is equal to the port of the server, to which the request arrived;
$server_protocol
この変数は、リクエストのプロトコルです。一般的な例は、HTTP/1.0またはHTTP/1.1
This variable is the protocol of the request. Common examples are: HTTP/1.0 or HTTP/1.1
$uri
この変数は、任意の引数（それらのために引数$を参照）することなく、現在のリクエストURIです。この変数は内部リダイレクトやインデックス·モジュールによって、これまでに行われた変更が反映されます。このように$ REQUEST_URIは、もともとそのような変更する前にブラウザによって送信されたもので、REQUEST_URI$とは異なる場合があります注意してください。プロトコルやホスト名が含まれていません。例：/ foo /というbar.html
This variable is the current request URI, without any arguments (see $args for those). This variable will reflect any modifications done so far by internal redirects or the index module. Note this may be different from $request_uri, as $request_uri is what was originally sent by the browser before any such modifications. Does not include the protocol or host name. Example: /foo/bar.html
