Linus Torvalds、HFS+に激怒
CVE-2014-9390 aka "Git on case-insensitive filesystems" I did not give the… gitが影響を受けた、HFS+で、一部の文字を区別しなかったり無視したりする問題に対して、Linusが吠えている。 マジで、HFS+はたぶん最悪のファイルシステムだな。クソすぎるぜ。NTFSもutf8の正規化で似たような問題（/の非正規化された表現を使用）があったが、まあ、今は修正されたんだろうよ。OS Xの問題は根本的すぎる。 そりゃ、古いさ。そりゃ、データ保護がクソすぎるってのはあるさ。だが、そういうのは、単に「すげーファイルシステムじゃない」って問題だ。「自分のケツすら拭けないマヌケによって設計された信じがたいクソ」ってわけじゃない。 HFS+の恐ろしさは、すげーファイルシステムではない、ということではない。いいアイディアがあると信じ
Every Declaration Just Onceの例
同じ定義は書かないCSSの簡単な例とその書き方に対する覚え書きを残しておく。同じ定義を書かないようにしていくと、CSSプリプロセッサーはおろか、セレクターのネストもなくて良いのかと感じてくる。もしかするとCSSの着地点はここなのかと洗脳されつつある。もはや第三者の目で見ることができなくなったので、他の人の意見も聞いてみたい。 .foo { border: 1px solid red; margin: 0 auto; width: 40rem; } .bar { border: 1px solid green; margin: 0 auto; width: 40rem; } .baz { border: 1px solid blue; margin: 0 auto; width: 40rem; } このような共通する定義を持つセレクターは以下のように書かれる。 .foo, .bar, .ba
新しいリリースプロセスをデプロイした - fujimuradaisuke's blog
今やっているサービス、ちょっと障害が増えてきたので、リリースプロセスを変えました。 ざっくり言うと、今までmasterを全部デプロイしていたのを、金曜日以外の毎日一回、手動の確認をしてリリースするようにした。実際のドキュメント(Wikiです)を日本語にしてダイジェストで紹介してみようと思います。 ちなみにこのサービスは複数のアプリケーションがあって、今回対象にしたのはそのうちの主要な3つのみです。 ブランチ戦略 developを本流として、そこにトピックブランチからプルリクエストを出す。masterは常に本番環境に自動的にリリースされる*1 急ぐときはHotfixとしてmasterに直接プルリクエストを出してもOK*2。 リリース手順 HipChatで「リリースするよ」ってアナウンスする developからmasterにプルリクエストを出す HipChatでHubotに頼むと、Jenkin
Amazonクラウドが「Amazon EC2 Auto Recovery」開始。システム障害を検知するとインスタンスを自動的に別システムへ移動、復旧
Amazon EC2 Auto Recoveryは、インスタンスが稼働しているサーバのシステム障害が検知されると、そのインスタンスを自動的に別のサーバへ移動、再起動し、システム障害から復旧させる機能。 移動したインスタンスは、IDやIPアドレス、コンフィグレーションなども含めて移動前のインスタンスと同じものになります。 これにより利用者は、クラウド上でいままで以上に可用性を高めることが容易になります。 AWS Cloud Watchで検知し、自動復旧 Auto Recoveryを機能させるには、AWS CloudWatchのアラームを作成し、メトリクスの「EC2 Status Check Failed (System)」のアクション「Recover this instance」を選択します。検知されるシステム障害の例は、ネットワークの切断、システム電源断、物理ホストのソフトウェア障害あるい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Just Delete Me | A directory of direct links to delete your account from web services.
