タグ

2011年10月21日のブックマーク (5件)

  • nginx & Perl : Talks | トーク - YAPC::Asia Tokyo 2010

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • ヘルプバッファや補完バッファをポップアップで表示してくれるpopwin.elをリリースしました - Functional Emacser

    ヘルプバッファや補完バッファをポップアップで表示してくれるpopwin.elをリリースしました。popwin.elはEmacsにポップアップウィンドウという概念を導入することにより、バッファを表示する(display-buffer)際のEmacsのトチ狂った仕様を矯正します。この「トチ狂った仕様」とは例えば、 M-x describe-functionしたらウィンドウが勝手に分割された あるいはウィンドウのバッファを勝手に切り替えられた ヘルプバッファ(*Help*)とか補完バッファ(*Completions*)がどのウィンドウに出現するか予測できない しかも作業後にそれらのバッファが表示されたままになったりする のようなものを指します。Emacsを触ったことがある人なら上記のいずれかは不満に思ったことがあるはずです。ちなみに僕は全てを不満に思っています。 余談になりますが、Wikiped

    ヘルプバッファや補完バッファをポップアップで表示してくれるpopwin.elをリリースしました - Functional Emacser
  • Don't use base.pm, use parent.pm instead! - Islands in the byte stream (legacy)

    「使っちゃいけない標準モジュール」*1の反響を見ていると、baseが非奨励ということに驚かれた方が少なくありませんでした。そこで、baseについて補足します。 まずbase.pmのドキュメントの最初の文は以下のようになっています。 Unless you are using the fields pragma, consider this module discouraged in favor of the lighter-weight parent. (拙訳: fieldsプラグマを使用しているのでないかぎり、このモジュールは勧められない。かわりに軽量なparent.pmを使う方がよい。) fieldsプラグマは、ハッシュリファレンスのキーを固定したオブジェクトを作成するための機能ですが、あまり一般的ではないためここでは解説しません。特に理由がない限り、ここは素直に忠告に従った方がいいでし

    Don't use base.pm, use parent.pm instead! - Islands in the byte stream (legacy)
    amari3
    amari3 2011/10/21
    use base が非奨励って今更知った
  • YAPC::Asia 2011で運用を振り返ることができた « ボーダーレスライフ

    YAPC::Asia 2011でのDeNAのriywoさんのセッションは、運用に寄ったお話が多く、とても興味深かったです。 怪盗ロワイヤルで行ったイベントによって、既存のクエリが対象とするデータが増え、それが激しく重いクエリに変化してしまった。結果、システム障害を発生させてしまったが、運用担当に内容の周知がされていたら防げていたのに、、というお話が紹介されていました。 おそらく、開発担当、企画担当からすると、ほんの少しのプログラム変更により動作するため、運用担当に周知するまでもないと考えたのだと思います。 確かに大規模システムの場合、障害の間接的な原因は、開発フローやリリースフローの不備である事がよくありますね。。 2004年~2006年くらいのヤフオクの急成長期には私も同じ経験をしてきました。 当時、私はリリース内容を把握し障害を防ぐ確実な手段は、リリースされるもののコード全てを運用担当

    amari3
    amari3 2011/10/21
    これは激しく同意