![Rails 4でHeroku Pushまでの詳細手順 [haml/bootstrap 3.0/postgresql or MySQL]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2ea7e72d0d7f3ba6c237909f321e67ffbdaa24e/height=288;version=1;width=512/https%3A%2F%2Fmorizyun.github.io%2Fimg%2Fog_image.png)
Ajaxを使用する場合、submitを使用することは少ないと思います。 button type="button"を使用することが多いのではないでしょうか。 submit時にAjaxを使用するサンプルソース<form data-abide id="form1"> <input type="text" id="text1"> <button type="submit" id="submit-button">submit</button> </form> <script> $('#form1').submit(function(event) { // ここでsubmitをキャンセルします。 event.preventDefault(); // Ajax処理 $.ajax({ url: 'http://localhost:8080/test', type:'GET', dataType: 'jso
不慣れな環境を不意にいじった時にあるあるネタ。 とりあえずー とか言って勢いで書いたsetupスクリプトを実行してみたら意外と時間かかって、 ちょっと目を離した隙にsshの接続が切れちゃいました! 。。。ありますよね。ほんとよくありますよね。 そうなる予感はあったんだ なんて後の祭りです。ふとした油断から、screenもnohupすらも使わずにやってしまって、こんなことに。 shellがHUPしなかったからプロセスは生きてるものの、ログが見れないから進行状況がわからない。 うまく行ってるのかどうかモヤモヤした気持ちのまま、プロセスが終わるのをじっと待つ。。。 まぁ実に切ないです。 こんな時、いつも思うこと。 このプロセスの出力、もっかいstdoutに繋げられたらいいのに。。。 はい。というわけでつなげましょう。 長い前座ですみません。 切り離したプロセスを用意 #!/bin/bash wh
« DBIx::Printf と LIKE 式 | メイン | メッセージキュー事始め in Perl - コマンドラインクライアントを作ってみた » 2007年10月11日 MySQL のウォームアップ (InnoDB編) サーバの起動直後はデータがメモリ上にないためデータベースの応答速度が遅い、というのは良く知られた話かと思います。MySQL の場合、使っているエンジンが MyISAM であれば、各データファイルをあらかじめ cat ... > /dev/null するなりしてバッファキャッシュに載せておけばいいのですが、InnoDB は独自のキャッシュを持っているのでそういうわけにもいかないように思います。 具体的には、パフォーマンスを最大限発揮するためには OS のキャッシュにではなく、InnoDB のバッファプールにデータをロードすべきであるという点。それに、たとえ OS のキャ
Rails 3のgemの管理に使用されるbundlerの使い方を復習します。 Bundlerの現時点の最新安定版のversion 1.2.3を対象とします。Bundlerを使うと何が嬉しいのか? あるgemが開発環境にはインストールされているが、production環境にはインストールされていない、といった問題が無くなる。 プロジェクトに必要なgemをはっきりさせることができる。 Bundlerのインストール %~ gem install bundler システム標準のrubyを使用している場合はsudoが必要な場合があります。rbenvやrvmを使用している場合はgem install bundlerのみでインストールできます。 bundle checkでインストール必要なgemをチェック Gemfileの中に記載されているgemのうち、これからどれをインストールしなければならないか
nginx研究。client_body_*関連のパラメータを調整すると、メモリ内でのHTTP Request Bodyの扱い方を調整できるようだ。たとえば、以下のようにclient_body_in_file_onlyとclient_body_temp_pathを両方とも設定すると、POST(やPUT)でコンテンツがポストされた時に、client_body_temp_pathで指定したディレクトリに内容がファイルに書き込まれる。 http { client_body_in_file_only on; client_body_temp_path /tmp/nginx; } 中身を見てみると、こんな感じ。 # less /tmp/nginx/0000000004 content=aaaaaa&submit=%8F%91%82%AB%8D%9E%82%DE client_body_in_file_
はじめに 最終回にあたり、iptablesを便利に使うTipsを紹介します。iptablesを1つ1つコマンドラインで実行するのは大変面倒です。そうした煩わしさを軽減できる設定や、実際の運用の手助けになるような工夫を紹介します。 関連リンク: →Linuxで作るファイアウォール[パケットフィルタリング設定編]http://www.atmarkit.co.jp/flinux/rensai/security05/security05a.html →連載記事 「習うより慣れろ! iptablesテンプレート集」http://www.atmarkit.co.jp/flinux/index/indexfiles/iptablesindex.html →連載記事 「習うより慣れろ! iptablesテンプレート集 改訂版」http://www.atmarkit.co.jp/flinux/index/i
WordPressには記事を参考にしましたというピンバック機能があり、自サイト内でもその機能が有効になっています。先日、ふと自分のピンバックURLをクリックすると「400 Bad Request」と表示されました。いくつかのURLをクリックしてみましたが「400 Bad Request」です。 このブログはパーマリンクを日本語利用しているため、URLが長くなっています。この記事のパーマリンクの長さは238バイトで、WordPressのURL制限が200バイトとなっているため、データベースには200バイトまで登録され、38バイトは切り取られてしまいます。 本当のURL http://takahitokikuchi.poitan.net/2012/10/02/wodrpress%E3%81%AE%E3%83%94%E3%83%B3%E3%83%90%E3%83%83%E3%82%AFurl%E
locationディレクティブはパスの条件が評価されて選ばれたものが適応されます。この条件はパスの文字列の前方一致あるいは正規表現による評価です。この評価の順番は以下のようになります。 前方一致("=", "^~", プレフィックスなし)の条件の評価を実施 最も一致する条件を選ぶ。 選ばれた条件が、完全一致で、プレフィックスが"="であれば、そこで評価を終了し、そのlocationディレクティブを適応する。 選ばれた条件のプレフィックスが"^~"であれば、そこで評価を終了して、そのlocationディレクティブを適応する。 正規表現("~", "~*")の条件の評価を実施 正規表現の条件を設定ファイルに定義した順番に評価する。一致したら、そこで評価を終了して、そのlocationディレクティブを適応する。 前方一致の評価で選ばれた条件のlocationディレクティブを適応する。 ここで注意
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く