『How to build a High Performance PSGI/Plack Server』のその後と ISUCON3を受けての話題『How to build a High Performance PSGI/Plack Server』のその後と ISUCON3を受けての話題
私はこうやって進学先の研究室を決めました - yanbe.log
なぜこの文章を書こうと思ったか 最近大学院入試の出願を控えて進路について迷ってる人をWebのいろんなところで見かける割に、Webでこういう問題について扱っているページをあまり見ないからです。 5月〜6月というのは翌年4月に大学院に進学したい人が志望先を決めるシーズンであり、昔自分も迷った経験があるので、こうして書くことでだれかの参考になればいいと思いました。 結論 私が実際に大学院に進学して4年ほど経ち、自分でいろいろ体験したり見聞きしたりした上での現段階での結論は、 進学先を選ぶにあたって、どこで最先端の研究をやっているかを知るには、自分が関心がある研究分野に実際に携わっている研究者に聞くのが一番いい ということです。研究者は、自分が取り組んでいる研究分野の最近のトピックがどの研究コミュニティによって取り組まれてきたかを、大体は調査し把握しているはずだからです。 もし幸運にも自分の人脈の
より高速なテスト環境を実現するために - Route54
テストを書くことは良い事です。どんどん書いて品質を上げたいところではありますが、テストの数が数万〜数十万に及ぶようなプロジェクトでは、フルテストに要する時間が無視できない程膨れ上がってしまいます。 今回は、そんな増えすぎたテストコードの影響でフルテストに時間がかかっているプロジェクトのために、テスト高速化を実現するためのモジュールとその使い方について紹介したいと思います。 モジュールは、App::Ikarosというもので、現在version 0.02がリリースされています。 使い方等はここにまとめてあるので(随時更新する予定)、この記事ではどのようなことができるモジュールなのかをざっと説明しようと思います。 まず、ざっくりとですがApp::Ikarosが提供する機能には以下の様なものがあります。 多数のノードによる分散テスト実行 forkproveによるテスト実行の高速化 Devel::C
大学院の修了に失敗し、新卒入社にも失敗しました - ゆううきブログ
※本エントリは中退を煽るものでは決してありません。 先月、大学院を中退しました。 コンテンツになりたいがために中退したととってもらってもよいですし、何か深遠な理由があって中退したととってもらってもよいです。 中退するにあたり、相談に乗ってくださった方々にはとても感謝しています。 相談に乗っていただいた方のだれひとりにも中退を勧められることはありませんでしたが、それでも気持ちは変わらなかったので中退することにしました。 中退の理由は、単位が足りないとか研究に嫌気がさした（最終的には嫌気がさしました）というのではなくて、学費の対価としての大学院や研究室のサービス内容に不満しかなかったからです。 まずいラーメン屋には行かないのと本質的には同じ理由だと思います。 まずい程度ならまだいいですが、まず過ぎて気分が悪くなるのに食べ続けないといけない感じでした。 最初は確かにあったはずの研究するモチベーシ
Webフロントエンドパフォーマンスチューニング
Webフロントエンドのパフォーマンスチューニングについて全体的な話。javascript、Chrome DevToolsの紹介、ボトルネック、ポイントなど。
肥大化したActiveRecordモデルをリファクタリングする7つの方法（翻訳）
更新情報: 2013/11/19: 初版公開 2021/01/08: 訳文見直し、追記 こんにちは、hachi8833です。今回は、自分が知りたかった、Active Recordモデルのリファクタリングに関する記事を翻訳いたしました。1年前の記事なのでRails 3が前提ですが、Rails 4以降でも基本的には変わらないと思います。リンクは可能なものについては日本語のものに置き換えています。 なお、ここでご紹介したオブジェクトは、app以下にそれぞれ以下のようにフォルダを追加してそこに配置します。 注記: 以下は使われそうなフォルダを列挙しただけであり、実際にはこの一部しか使いません。 Value Object Service Object Form Object Query Object View Object Policy Object Decorator ⚓ 肥大化したActive
DevOps実践に有用なZabbixの機能～自動化機能で運用負荷削減
DevOps実践に有用なZabbixの機能～自動化機能で運用負荷削減：クラウド＆DevOps時代の運用をZabbixで（3）（1/2 ページ） ますますクラウド化が進む環境において、システムにはより迅速な対応が求められるようになっています。変化の早いシステムを適切に運用していくためにはどうすればいいのでしょうか？ この記事では、クラウドやDevOpsを前提としたITシステムの「運用」に求められることを整理し、そういった運用に対して、オープンソースの統合監視ツール「Zabbix」がどのように有効活用できるかを紹介します。 前回の記事「DevOps実践に有用なZabbixの機能～開発と運用を近づける監視」では、DevOpsを実践するに当たって、開発者と運用者をZabbixを通じてより近づける方法について紹介しました。第3回目の本記事では、運用面にフォーカスを絞り、Zabbixの自動化機能を活用
『redisをsentinelとAliasIPを利用して冗長化』
どうも初めまして2012年度入社の社内ニート予備軍editnukiです。 普段は引きこもって WebSocketで監視もリアルタイムに を書いた社内ニートさんの下でコミュニティサービスのインフラをやっております。 運用面以外ではrpmパッケージ作ったりしています。 さて、本題ですがコミュニティサービスでもredisを利用したいという声が最近多くなりいくつかのサービスではredisを導入しているのですがマスターとなるredisが死ぬと更新系が一切できなくなるため、マスターが死んだ時はアプリの向き先をスレーブに変更しなければなりません。 今までのredisの構成としては下図の様な構成でした。 redisの2.6系がリリースされた時に「sentinel」というフェイルオーバーの機能が追加されました。 詳細は公式ドキュメントをご参照ください。 フェイルオーバーしたとしてもアプリ側にマスターが切り替
systemd の情報を集め始めよう
斎藤です。こんにちは。 RedHat Enterprise Linux 7(RHEL7)リリースの足音が聞こえる今日この頃ですが、皆様いかがでしょうか。予習として、Fedora 19を利用されている方もいらっしゃるかと思います。 その中で、大きな変化の1つとして、 systemd(※1) の採用があります。systemdは、SysVinitやUpstartに変わる、プロセス管理の仕組みです。そうです、起動スクリプトの書き方や、プロセスの確認方法が大きく変わる事になるのです！そうなれば、構築や運用に関わる知識や手順を覚え直す必要が出てきます。 しかし、systemdに関する資料は、それほど多くありません。そこで、簡単ですが記事執筆時点(2013-10-24)での情報源をまとめてみました。検証の際の情報収集時、お役に立てば幸いです。 ※私が社内Wikiにまとめた情報をBlog用に整理し、公開し
Githubの組織が成長する過程で変えたことと変えなかったこと - ワザノバ | wazanova
GithubのZach Holmanが語るGithubの組織戦略です。まず最初に、 Step #1: ロックスターエンジニアを雇う Step #2: ものすごく透明性のある経営をする Step #3: ブログ/ソーシャルメディアなどでテクノノロジーについて発信する Step #4: カンファレンスで会社について話す Step #5: カネに余裕ができる Step #6: 社員を大勢雇う Step #7: 会社のことを話さなくなる Step #8: コミュニティを無視する Step #9: 創業者が株を売って儲ける Step #10: 別の会社をはじめる という事例を挙げて、Githubは組織が成長する中で、このようなパターンに陥らないように、コミュニケーション及び仕事の進め方をどのように進化させてきたかについて紹介してます。 Dunbar's numberとしてよく知られるとおり、人間が良
Sensu and Graphite – joemiller.me
Joe Miller Ops/Engineering. Continuous DevOping at Webscale Twitter Github Updated December 7, 2013 : I no longer recommend using the approach described in this post. Please read Sensu and Graphite, Part 2 instead. Updated October 16, 2012 : Removed “passive”:”true” from the graphite amqp handler definition in Sensu. This is too brittle. Sensu will fail to start unless graphite has started first a
AMQPによるメッセージング | GREE Engineering
こんにちは。GREEのプラットフォーム開発部でインフラ系の仕事をしているmdoi(@m_doi)と申します。よろしくお願いします。今回は、AMQPについて簡単に紹介したいと思います。 はじめに GREEで稼働中のサーバは、日々サーバの異常ログ、自己監視結果、メール等々、大量のメッセージをやり取りしています。しかしながら、共通のメッセージングインフラが存在しないため、それぞれが独立に色々なメッセージ送信を行っています。 サーバ台数の増大に伴って、メッセージ配送の負荷が無視できないレベルになって来ると、それらのメッセージングシステムについて、個別に負荷対策を施すなど運用上様々な問題が課題が出てきます。また、メッセージの種類によっては、その配送の仕組がスケーラビリティに欠けるものとが存在し、規模の増大に対応できなくなる恐れもあります。そのため、こういうった用途に使えるスケーラブルなメッセージング
GitHub と homesick を使って複数 Mac 間で dotfiles を同期する | DevelopersIO
複数 Mac 間で、.vimrc や .zshrc などの設定ファイル（dotfiles）の同期って面倒くさいですよね。 dotfiles の管理には、GitHub とシェルで管理したり、Dropbox を使ったりあるようですが、 最近 homesick という gem を教えてもらい、簡単に管理することができたので、私はコレを使っています。 用意するもの GitHub のアカウント Mac *1 homesick のインストール homesick は gem install で簡単にインストールできます。 $ gem install homesick rbenv を使ってる場合は、rehash しておきましょう。 $ rbenv rehash GitHub に dotfiles リポジトリを作成 GitHub にリポジトリを作成します。 先ずは、ローカルに dotfiles ディレクトリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - BrightcoveOS/Diamond
Hosted Graphite
Collection Agents — Librato Knowledge Base
Sensu and Graphite - DZone DevOps