nginxを使った簡単快速reverse proxyサーバ構築法 - Masatomo Nakano Blog
ここのブログは、nginx(proxyサーバ)が外からのアクセスを受け、それを thin + sinatra (アプリケーションサーバ) と mongoDB (データベースサーバ)で処理する、というWebシステム定番の三層構造で構成している。 ただ、見てわかるようにほぼ静的なコンテンツのサイトなので、アクセス毎にアプリケーションサーバを走らせる意味がない。また、このVPSの一番安いコースにおいているので、あまり贅沢に資源を使いたくない。と言ったことから生成したhtmlをキャッシュして2度目のアクセスからはアプリケーションサーバやデータベースにアクセスしないようにしている。 Webシステムによっては、アプリケーションサーバで静的なhtmlファイルを作成し負荷の軽減をしたりするが、キャッシュファイルを自前で扱うのはvalidation等色々だるいので、このブログシステムではnginxに任せてい
「Perl One-Liners」 を読んだ - Shohei Yoshida's Diary
http://shop.oreilly.com/product/9781593275204.do 来月 Oreillyから出るのかと思ってググって見たら, 電子書籍として 4年前に出たものの紙バージョンでした. 紙で読むのもあれなので, 電子書籍版を読みました. $10なんで安いと思います. 電子書籍版 http://www.catonmat.net/blog/introduction-to-perl-one-liners/ 内容 言うなれば, One linerクックブックです. ファイルの内容の加工, 計算, 文字列生成, 文字列変換, 置換, テキストマッチング等の 内容です. それぞれ 10-20弱のレシピがあります. 事細かな説明があるわけではないので、全くの初心者には向かないと 思います。One Linerのスイッチの意味ぐらいは知っているという人 向けでしょうか. そんな複雑
Devel::NYTProf で Starlet/Starman (Plack) でうごくウェブアプリケーションのプロファイリングをおこなう方法まとめ - tokuhirom's blog
Devel::NYTProf は Perl5 の世界でもっとも人気があるプロファイラである。表示が美麗であるし、ステップごとの処理速度が簡単にわかるのでとても便利だ。 そんな Devel::NYTProf であるが、Starlet/Starman のようなプリフォーク式のサーバーでうごくウェブアプリケーションとくみあわせる場合の方法論として、わかりやすい資料がみあたらなかったのでここに記すものである。 環境変数 NYTPROF を設定する Devel::NYTProf は環境変数で挙動を変えられる。 plack とくみあわせる場合には、以下のようにするとよい。 NYTPROF=sigexit=int:savesrc=0:start=no sigexit=int 通常、Devel::NYTProf は END { } ブロックでデータのファイナライズ処理をおこなうのだが、SIGNAL によっ
gitで管理しているファイルを大文字から小文字へ一括変換 - Qiita
#!/bin/bash # 実行方法： sh henkan.sh <dirname> # こんな感じで拡張子の指定などもできるでしょうね # FILES=`find $1 -type f -name "*.gif"` FILES=`find $1 -type f` echo "$FILES" read -p "こいつら変換する？ [y/N]" -n 1 -r echo if [[ $REPLY =~ ^[Yy]$ ]]; then echo "やるよー" for FILE in $FILES; do LOWER=`echo $FILE | tr A-Z a-z`; if [ $FILE != $LOWER ]; then git mv -f $FILE $LOWER fi; done; echo "だん！" else echo "やんない" fi Register as a new use
Chefを最速で使いこなすためのいくつかのポイント - Masatomo Nakano Blog
前回書いた さようならPuppet、こんにちはChef が、それなりに反響あったので調子に乗ってもうちょっと書いてみる。 前回、ChefはPuppetに比べて簡単！とか書いたが、実際には慣れるまでそれなりに戸惑うところがあった。 ドキュメント を読み、実際に触っただけでは一発で理解できなかった部分を、自分のメモを元に晒しておく。これだけ読んでもいまいちだと思うので、関連するドキュメントへのリンクも張っておくので合わせて読んでみると高速でChefを理解できるかも！ client vs node Chef Client Nodes ドキュメントを読んだりChefを触っていると client と node という二つのワードが出てくる。この二つは似ているけど別物。 client は文字通り Chef server の相手になるもの。 Chef server にアクセスするものはすべて clien
さようならPuppet、こんにちはChef - Masatomo Nakano Blog
ここ最近、サーバの設定ファイルの管理で Chef を使い始めている。まだ全然詳しくないけど、今感じている「Chefの楽しさ」を誰かに伝えておきたかったので、ファーストインプレッションを簡単に。 Puppetを今までそこそこ使っていたので、どうしてもそことの比較な感じになっちゃいます。Puppetも良いのだけど、Chefは後発ということでさらに良くなっている感じ。 基本的な仕組 これは、Puppetとほぼ同じ。クライアント-サーバ型のシステム。設定を書き、それをサーバに置いておく。クライアントはサーバと接続し、自分自身の設定を書き換えたり、必要なソフトウェアをインストールしたりする。 rubyな設定ファイル Puppetは基本的に独自DSLで設定ファイルを記述すので「覚えるのがめんどくさい」「細かいこと、ちょっと無茶なことをしようとすると大変」。Chefの設定ファイルはrubyそのものなので
Node.jsをサーバサイドのUIレイヤに限定するのか？ - ワザノバ | wazanova.jp
http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/ Nicholas ZakasはYahoo出身で現在Boxに勤めるフロントエンジニアで、JavaScriptに関する複数のオライリー本の著者でもあります。彼が自身のブログで、Node.jsをサーバサイドUIレイヤのみで活用することを提言してます。 JavaScriptエンジニアはフロントエンドのコントロールはできるが、サーバサイドのUIレイヤはバックエンドエンジニアの領域で、それがフロント（JavaScript）エンジニアとバックエンドエンジニア双方のストレスであった。（参照図１） Node.jsの登場で、サーバサイドのUIレイヤをサーバサイドのビジネスロジックから分離し、フロントエンジニアはブラウザ & サーバのUIレイヤ、バックエンドエン
EditTextのカーソル位置に文字列を挿入
EditTextに文字列を追加する場合、append()というメソッドを使うが、これは常に編集テキストの末尾に文字列が追加されてしまう。 EditTextの末尾ではなく、カーソル位置に文字列を挿入したい場合にはこうする。 自前でなんとかする EditTextには、カーソル位置に文字列を挿入するというメソッドはないので、自前でなんとかするしかない。 考え方はこうだ。EditTextからテキストを取り出し、単なる文字列処理で文字列の挿入をおこなう。 getSelectionStart()とgetSelectionEnd()で選択範囲の先頭と末尾の位置を得る。テキストが選択されていない場合にはstart = endとなり、カーソル位置をあらわす。 Editable#replace()メソッドを使って文字列置換。 選択範囲を置換できるように、start != endの場合も考慮する。選択の仕方によ
何故プログラミングに効果音は必要なのか、あるいはVimで爆発する方法 | 遥か彼方の彼方から
この記事はVim Advent Calendar 2012の312 日目の記事です。昨日はid:cohamaさんの「‘set relativenumber’ で Vim のカーソルの縦移動とかを改善する」でした。 効果音は素晴しいみなさんはゲームの効果音は好きですか？ 僕は大好きです。 自分の操作に合わせて音が鳴る。適切なタイミングで鳴る適切な効果音は、単にコントローラを操作する以上の、ゲームへの没入感を生みます。 もちろん、効果音がなくてもゲームは成り立ちます。iPhoneなどでプレイするときは音を消してプレイすることもよくあるでしょう。それでも一度音を流してプレイすれば、効果音の良さに感動します。 さて、プログラムです。エディタです。Vimです。 プログラミングもまた、効果音があるといいとは思いませんか？ 思いますよね？ ということで、プログラムの際に効果音を鳴らす方法をまとめました！
いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ
色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。 もちろん、全部が書けるとも思ってないので、自分が不安なところとか、変更が多く入りそうなところとかを中心に書くようにしてる。一種の精神安定剤みたいなもん。 あるとき、一緒に働いてるエンジニアさん(ここではAさんとしておこう)に「ここ難しそうだから、テスト書いたほうがいいですよ」って話をしたら、「じゃぁ、工数かかっちゃいますね」って言われて結局書いてなかったな。 そうだよ。ユニットテスト書いたら工数かかるよ。それは純然たる事実。でも、再利用できないチェックシートを作ってやるよりもいいと思うんだけどね。しかもこの前に見せてもらったこのチェックシートも運用レベル
#isucon 3 予選総合3位でした | へぼい日記
毎年でているISUCONに今年も山形組として参加しております。 今年からオンライン予選があり、10/5の一日目に参加し結果は現在のところ暫定で3位で予選通過の予定です。 暫定なのは使ったサーバの運営側による検査が残っているためです。 で、今年は何をやったか、というとあいも変わらず去年と同じことをしておりました。去年と同じ方式でかくと やったこと アプリ全書き換え 1fileなPSGI https://gist.github.com/nihen/6852251 feersum(1プロセスマルチスレッド) データはすべてオンメモリ スレッド間でシェア 永続化はテキストファイルへjsonで追記 html renderのキャッシュ(といってもmarkdownぐらいか) リバースプロキシをnginxにして静的ファイルもそこでserve やれなかったこと benchmark –workloadの試行
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
お知らせ 残響アプリhibikuのiOS7対応状況について | Katsuhiro Chiba
PaaSの作り方 Sqaleの場合