r-westのブックマーク - はてなブックマーク

2013年2月13日　オブソリートなOSだって?!… Google ChromeはなぜRHEL 6のサポートをやめたのか | gihyo.jp

Linux Daily Topics 2013年2月13日オブソリートなOSだって?!… Google ChromeはなぜRHEL 6のサポートをやめたのか利用しているOSが最新バージョンだからといって、すべてが最新の環境とは限らない。とりわけエンタープライズOSの場合は、中身を見るとオブソリート（obsolete：時代遅れのIT 技術を指すときによく使われる形容詞）な技術の集合体であることも少なくない。とはいえ、オープンソースへのコミットを会社の理念として掲げているRed Hatが、その看板ディストロをオブソリート扱いされるのは、やはり気持ちのよいものではないようだ。まずはRed HatのエバンジェリストであるJan Wildeboer氏が2月11日に投稿したGoogle+のポストを見てほしい。 Why does Google put users of (at least) Red H

r-west 2013/02/13

逆にいうと、それだけ時間を掛けて枯れさせないとエンプラでは使えないって事なのかな。

リンク

第11回　ログでアプリケーションの改善プロセスを回す（1） | gihyo.jp

本連載では第一線のPerl ハッカーが回替わりで執筆していきます。今回のハッカーはkazeburoさんこと長野雅広さんで、テーマは「ログでアプリケーションの改善プロセスを回す」です。オペレーションエンジニアの仕事小林篤さんから連載のバトンを受け取りました、長野雅広です。普段はNHN Japan（⁠株⁠）にてオペレーションエンジニアとして働いています。livedoor blogやポータルサービスなど自社Webサービスの運用に携わっており、cloudforecast（Perlで作られたリソース監視ツール）を使ったメトリクス収集をはじめ、アプリケーション設計のアドバイス、ミドルウェアの設定、障害対応のフォローなど、Webアプリケーションエンジニアにかかる運用の負担を減らすことが主な業務です。ログはDevとOpsのコミュニケーション手段監視サーバからのアラートメールが届いたり、リソース監視ツ

r-west 2012/02/07

後で読む

リンク

第1章　現代的プロトタイピングのすすめ～古くて新しい可視化手法（ブルックスからアジャイルまで） | gihyo.jp

r-west 2011/02/17

後で読む

リンク

第8回　インフラエンジニアの「修羅場」事件簿 | gihyo.jp

今回は、前回予告した通り、筆者が経験したことのある修羅場について書いてみます。なかなか微妙な内容で、セミナーとかパネルディスカッションとか（飲みの席とか）では話したことはあるのですが、字にするのはたぶん初めてです。普通修羅場というと、技術的なトラブルに関するものだと思うのですが、ある程度の経験値を積むと、対処できない技術的なトラブルというのはなくなるものです。もし対処できない技術的なトラブルがあるとすると、もうそれは誰にもどうにもできないので諦めるしかないとかになります。ここであえて「技術的な」と書いたのは、意味があります。筆者が経験した修羅場は技術的なものではなく、法的というか金銭的なものでした。［Case1］ネットワーク機器差し押さえでルータ13台→4台にまず1つめは、あるデータセンターの運用をサポートというか代行していたときのことです。そのデータセンターは実は購入しているネット

r-west 2010/06/29

後で読む

リンク

第1回　みなさんの飛躍のきっかけとなった本は？ | gihyo.jp

はじめに IT業界というと、3Kだとか、帰れないとか、泥のようにだとか、昔からいろいろ言われてきています。しかも、Mっ気のある人が多いせいか、言われても反論したり怒ったりせずに、そのままネタにして楽しんでいたりするから余計にたちが悪かったりします。とは言ってもその実、業務外でも頼まれてもいないのに積極的に勉強会に行って同業他社の人と交流したり、土日までつぶしてイベントを開催したり、大量の本を買って家の中がいっぱいになったり…家も会社も関係なく、全力でIT 技術者という職業を楽しんでいる人が数多くいます。中には、海外のカンファレンスまで出かけてしまう人もいるぐらいです。まだ、勉強会という場を知らないために、出てこない人もいますが、一度楽しさを知ってしまった人は定期的に色々な勉強会に顔を出して新しい情報を取り入れたり、人に教えて感謝されたり、自信が付いたり、多くの恩恵に授かっています。さて、そ

r-west 2010/01/10

リンク

第2回　潜在するバグに対処するための　エラー処理の考え方 | gihyo.jp

ユーザとのインタフェースが原因で発生するエラーは、プログラム内でエラー対処ができないので、ユーザに誤りを知らせ、正しい方法で操作をやりなおすことを促します。プログラム内のバグが原因で発生するエラーは、ユーザには対処できません。プログラム外部の異常が原因で発生するエラーは、ユーザが正しく操作し、プログラムにバグがありません。エラーの対処ユーザとのインタフェースが原因のエラーに対しては、ユーザに誤った入力・操作を取り消し、正しい入力・操作をやりなおしてもらうことが対処になります。そこで、ユーザに対して何が間違ったのかを指摘して、正しい入力・操作を示す必要があります。通常は、エラーが発生した直後にユーザインタフェース（画面）を用いて知らせます。たとえば、「⁠日付の指定が間違っています。予約日は本日から30日以内で指定してください」のように示します。よく見かける、「⁠不正な操作です」「⁠内

r-west 2009/09/05

後で読む

リンク

redMine｜Ruby on Railsで作られたプロジェクト管理ツールredMineを使ってみよう!:第1回プロジェクト管理ツールの必要性/Tracとの違い/redMineがオススメな理由|gihyo.jp

プロジェクト管理ツールの必要性みなさんのプロジェクトは上手に運営できていますか？プロジェクトメンバーのタスクの進捗管理はできていますか？問題・課題管理はスムーズに行えていますか？　ExcelやWord、紙資料を用いた管理で、作業が煩雑になっていませんか？進捗報告ミーティング用の会議資料作成やチームメンバとの情報共有のために、大きく時間を取られていませんか？ファイルサーバには必要かどうか判断できない無駄な資料があふれかえっていませんか？ソースコードはきちんと管理されていますか？リリース用のソースコードに、どんな機能が盛り込まれ、どんな不具合が解決したのか、ちゃんと把握できてますか？プロジェクトが混沌としてくると、ドキュメントやソースコードの構成管理がぼろぼろになり、プロジェクトメンバの作業の進捗具合をリーダが見通せなくなります。その結果、上記のような問いかけに対して「できてい