福岡出張にいっていたら、ちょうど福岡にいらしていた@kazeburoさん経由でご恵贈いただきました。ありがとうございます。 nginx実践入門 (WEB+DB PRESS plus) 作者: 久保達彦,道井俊介出版社/メーカー: 技術評論社発売日: 2016/01/16メディア: 単行本(ソフトカバー)この商品を含むブログ (1件) を見る 本書は、nginx関連で多数のプロダクトを作っている@cubicdaiyaさんと、pixivのインフラを支える@harukasanさんによる共著とあってみれば自然と期待が高まるわけですが、nginxのアーキテクチャについての簡潔な説明から、基本的な設定や大規模なコンテンツをさばくためのスケールアウトの方法、さらにはngx_luaによる拡張まで、Webサービスにおけるnginxの実践的活用に必要な内容が、わかりやすく述べられています。 「秒間50kリクエ
ネットワークにおけるOSI参照モデルや、アプリケーション実行環境におけるハードウェア→OS→ミドルウェア→アプリケーション→UI(ブラウザ・モバイル)というレイヤ(こういうのに名前あるのかな。「フルスタックエンジニア」という言葉があることからして「技術スタック」とでもいうのだろうか)のように、ある技術的まとまりを、フラットにではなく階層をなすものとして考える習慣が存在する。それぞれのレイヤの独立性・簡潔性を担保するためだ。 今日、いろんなひとと話をしていて、こういう風にも考えられるよなと思ったことがあったので、以下にメモしておく。 それぞれについての贅言は必要なかろう(念のため、「デザイン」はいわゆる設計のこと)。また、抽象度が高低に、なにかしら技術的な優劣があるというわけでももちろんない。単に、階層を成しているものとして捉えると整理がつくだろうというだけのこと。ただし、上述の例とは異なり
本稿では、"Immutable Infrastructure"時代におけるconfiguration management tool(以下、CMT)の要件およびそれを満たすツールについて議論する。 背景の整理 "Immutable Infrastructure"とは、2013年6月、Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components - Chad Fowlerにより提唱された概念だ。ある種のプログラミング言語における不変性がプログラムにおける厄介な問題を解決するように、サーバの状態を不変な(正確には、状態を変更しない)ものとすることで、成長し続けるソフトウェアにとって避けられない、時間の経過によりもたらされる種々の問題が、解決可能であるとする。 そもそもどのような
去る11月23日、あるイベントが開催された。「秋のエンジニアぶつかり稽古 2013」という。何を目的にしたイベントなのか誰も(主催者側ですらも)わからないまま始まったこのイベントは、しかし、最後までその目的が明らかにならないままに、なぜか大成功の余韻だけはしっかり残して終わった、異常な「事件」と呼ぶ他ないものとなった。 事の発端 そもそもの始まりからして意味不明だったのである。発端はこれだ。 @__kan こんにちは、ペパボです。YAPC::ASIA参加者スペシャル特典にご応募いただき、ありがとうございます ! @kentaro とのぶつかりげいこをぜひ開催したく思います。ご都合のよろしい日をいくつかご連絡下さい! pic.twitter.com/uoj2uExHBU— ペパボ(paperboy&co.) (@pepabo) October 2, 2013 2ヶ月ほど前、YAPC::Asi
I'm curious about how scale out WebSocket-based implementation of, for example, chat-like service. Can it be easily scaled out to multiple app servers? I think Server-Sent Events and Redis can easily solve the problem. The biggest difference between WebSocket and SSE is bi-directional or not. Posting messages can be done via usual XHR. So, the problem just sits on how server can sent message chunk
サーバ管理ツールTriglavのAPIクライアントを、RubyとPerlで書きました。現状、APIは参照しかないのでとても単純なものですが、早いうちにちゃんとライブラリ書いてラップしておいた方が、いろいろやりやすいかなと思ってのことです。 Ruby: http://rubygems.org/gems/triglav-client Perl: https://metacpan.org/module/Triglav::Client 順番としては、Ruby版を作ってから、Perl版にそのまま移植したという感じです。すっかりRSpec厨になってしまったので、今回は、id:tokuhiromさんの作成したTest::StubやTest::Shouldを用いて、できるだけRuby版に近い書き方をしてみました。けっこう、文字列置き換え + アルファぐらいで書けるようになって、tokuhirom++って感
同僚の@kyanny, @tnmtと3人で、チーム「つねさま with 刺身あんちぽ」として#isucon2に参加してきました。そんなに悪い結果ではなかったようではあるとはいえ、スコアという形で明白な差をつけられると、技術者としての実力がまだまだ全然足りないと思い知らされて、これはなかなか悔しいことだなあと思いました。 我々がやったことや、考えたことなどの詳細は@kyannyメンバーが詳しく書いてくれているので、是非ご覧ください(僕が他に書く余地がないw)。当日のコミュニケーションはIRCや口頭で行っていましたが、後日のまとめのためにわりと詳細にGitHubのWikiにリアルタイムにまとめてあって、役立ちます。 #isucon2 に参加しました - 刺身☆ブーメランのブログ / @kyanny's blog 上記に加えて、いくつか。 役割分担をして効率的に作業した方がよかろうというわけで、
先日(10/9)、riywoさんさんの呼びかけにより、サーバ管理をどうやったらいい感じなるかを話し合う会がもたれました。僕は、直接サーバ管理をやっているわけではないのですが、社内でそういうの欲しいという話をしていて、ツールを作りたいといっていたので、参考になればというわけで、お誘いいただいて参加してきたのでした。 riywoさんから、叩き台としてホストのキーを元にした統合的なAPIの構想を図式化したスライドを提示していただいた後、管理システムの主なユースケースや、各社の実際の管理手法などをいろいろお話をうかがいました。僕など、インフラ的な知識に乏しいもので、これはなかなか大変なことだなあというのがあらためてわかりました。 組織体制や経理ルールの複雑性が各社でだいぶ違う サーバの情報として必要な属性が各社でだいぶ違う そもそもサーバの情報が複雑 既にあるなんらかの管理の仕組みとの整合性を取る
ここのところやっている業務のひとつに「リーン・キャンバス」の作成支援があります。それがどういうものであるかは「「開発者のためのリーン・スタートアップ」「リーン・キャンバス入門」の資料を公開します」をご覧いただきたいのですが、このフレームワークは、新規・既存とを問わず広く使えるものであると、複数のチーム、サービスでの実践を通して、確信しつつあるところです。 ところで、この数日、ある新サービス開発に先立ってキャンバスをみんなで作ってみたところ、理屈として筋は通っているように見えるし、大きく間違えているところもないように思えるのだけれども、どうもメンバーが納得できないということがありました。 今日、リーンキャンバスをみんなで作っていて、みんな「うーん」と納得してない感じだったので「悩み相談する女の子に対して、理路整然と正論を述べて、それが解決になってると思ってる男みたいなキャンバスですね」といっ
新プロジェクトで、それなりに自由にいろいろやれる感じの状況になったので、好きにやろうと思って、いままで実務では使っていなかったツールをあれこれ試しています。 2012-02-17追記: エントリを書いた後、状況がだいぶ変わったので、実際にはずいぶん違う感じになりました。 WAFをどうしようかなーと思った時に、ドメインスペシフィックなぼくがかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーくを作成するということも考えたのですが、そんなにスペシフィックな用途でもないし、WAF自体はPlackを薄くラップしたぐらいのものでよいと思うので、自分でがんばって作る必要もないと考え、信頼と実績のAmon2を試用してみることにしました。 いくつか、こうだったらいいのになという点を反映して、こんな感じでやってみています。試しながらやってるとこなので、全然「さいきょう」でもないし、不十分なところはいろい
こんにちは。私はantipopです。あなたの名前は? ここ数年、技術者界隈でAdvent Calendarというものが流行っていて、毎年12月になると一定のお題に沿った日記バトンみたいな、その意味ではわりと昔懐かしい感じのするイベントが行われていて、技術的なことに関しては僕もどっかで書こうと思っているのですが、Advent Calendar自体は別に技術的なことに限る必要もないじゃんってんでHatena::Staff Advent Calendar 2011つって社内の参加者を募ったところ、めでたく開催の運びと相成ったのでこうして書き始めてみたものの、完全に勢いだけで言い出しただけで書くことを決めていなくて困ったりしたので、酒を飲みながら自由奔放に筆を滑らせていきたいと思います。 というわけでこんばんは!!1 みなさん日記書いてますか。僕は日記を書くのが大好きで、ウェブがなかった頃からノー
にわかに Perl の学習コストについて優れた Perler のみなさんがあれこれ述べておられるので、大変勉強になります。 Unknown::Programming - 新人教育 SQLAlchemy Database Engines 日記。 (TokuLog) - Perl は学習コストが高すぎる naoyaグループ - naoyaの日記 - Perl の学習コスト SQLAlchemy Database Engines 日記。 (TokuLog) - Perlの学習コストとライブラリ naoyaグループ - naoyaの日記 - アンテナ張りまくらないとの件 subtechグループ - Bulknews::Subtech - Perl、アンテナの話 Charsbar::Note - Perlの学習コスト 上記にリンクしたエントリをまとめると、オールドファッションな書き方であれば Per
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く