メールを受け取らないドメイン名に
example.comゾーンには次の内容で登録されているものとします。 example.com. 86400 IN A 192.0.2.80 送信側メールサーバは次のような順番で処理を行います。 宛先メールアドレス"foo@example.com"のドメイン名"example.com"に対するMXレコードを問い合わせる。 "example.com"に対する回答として0個のMXレコードを受け取る。（MXレコードが登録されていないため。なお、"example.com"そのものは存在するため、回答のステータスとしては"NOERROR"である。） "example.com"に対するAレコードを問い合わせる。（MXレコードが存在しないときには、Aレコードにフォールバックするため） "example.com"に対する回答としてIPアドレス"192.0.2.80"を値とするAレコードを受け取る。 IPア
ムーアの法則が成立しなくなると、遅いソフトウェアは遅いままだ。ソフトウェア技術者はなにをすべきか～ポスト・ムーア法則時代のコンピューティング（後編）。QCon Tokyo 2016
ムーアの法則が成立しなくなると、遅いソフトウェアは遅いままだ。ソフトウェア技術者はなにをすべきか～ポスト・ムーア法則時代のコンピューティング（後編）。QCon Tokyo 2016 10月24日に都内で開催されたイベント「QCon Tokyo 2016」で、国立情報学研究所 アーキテクチャ科学研究系 教授 佐藤一郎氏による基調講演「ポスト・ムーア法則時代のコンピューティング」は、IT業界だけでなく社会的にも影響をもたらすと考えられるムーアの法則の限界とその先について、多くの示唆を与えるものとなりました。 （本記事は「いま起きているムーアの法則の限界は、微細化よりも電力と経済性の限界～ポスト・ムーア法則時代のコンピューティング（前編）。QCon Tokyo 2016」の続きです） ブロックチェーンもムーアの法則の限界に影響を受ける さて、この講演は実は主催者から「コンピュータサイエンスが生み
いま起きているムーアの法則の限界は、微細化よりも電力と経済性の限界～ポスト・ムーア法則時代のコンピューティング（前編）。QCon Tokyo 2016
今日のお話は、ムーアの法則が限界に来ているなかで、ソフトウェアの技術者の方々がなにをすべきか、ということを中心にしていこうと思います。 ムーアの法則は終焉するのか？ これまでに何度もムーアの法則限界説が流れていて、そのたびに半導体業界はそれをなんとか乗り越えてきたので、ここでまたムーアの法則が限界だという話をすると、オオカミ少年だと言われてしまうかもしれません。 ただ今回はかなり深刻な状況になっています。 その前にまず、ムーアの法則とは何かということを説明しておくと、インテルの共同創業者のゴードン・ムーアという人が50年前に、1つのチップ上の半導体の数、つまりトランジスタの数は毎年倍増すると予測したものです。倍増するペースはそのあと18か月から2年に修正されました。 トランジスタの数はたしかにこの通りに増えていったのですが、他方で半導体業界は総力を挙げてこのムーアの法則を満足させるために技
Docker 1.12の新機能、ヘルスチェック機能を使ってみる | さくらのナレッジ
Docker 1.12では新たにコンテナのヘルスチェック機能が実装されており、コンテナやコンテナ内のサービスが正しく動作しているかをDockerだけで監視することができる。現時点では用途が限られているものの、同じくDocker 1.12で導入されたSwarmモードではこれを使ってサービスの再起動が可能だ。本記事ではこの監視機能について紹介する。 Docker 1.12に実装されたヘルスチェック機能概要 Docker 1.12で実装されたヘルスチェック機能は、一定間隔で指定されたコマンドを実行し、その終了コードが1だった場合が一定回数継続したらコンテナに問題が発生したと判断するものだ（図1）。 図1 Dockerのヘルスチェック機能概要 ヘルスチェック機能を利用するよう設定したコンテナでは健康状態（health）というステータスが設定され、問題が発生したコンテナは「unhealthy」、問題
2016年のDevOps関連10の注目ニュースを振り返る
Christine Parizo （Special to ZDNET.com） 翻訳校正： 石橋啓一郎 2016-12-27 06:30 DevOpsは2016年を動かした力の1つになったと言える。開発者がものを作り、テストし、展開する環境としてのコンテナやツールに、将来を賭ける企業が増え始めたためだ。Dockerはエンタープライズ事業戦略に全力を尽くしているし、コンテナアプライアンスのアイデアを持ち込んだ企業もある。Hewlett Packard Enterprise（HPE）もDevOps戦略に力を入れており、「Kubernetes」も勢いを増している。この記事では2016年に起きたDevOps関連の重要な出来事を振り返ることにしたい。 Dockerがセキュリティ機能を持つライフサイクル管理製品をリリース Dockerは「Docker Datacenter」をリリースした。このサービス
Ansibleのインベントリとvarsの依存関係を可視化する - Qiita
ansible-inventory-grapherというツールを使って、Ansibleのもつインベントリとvarsの依存関係を可視化していきます。 可視化することで、例えば以下のようなイメージで、インベントリとvarsの依存関係を理解できるようになります。 可視化の重要性 みなさん、Ansibleを活用していますか？ Ansibleはインフラ構成管理にも有用なツールである反面、「お手軽に使う」ところから「本気で使う」ところでは、様々な見直しを迫られると思います。これまでは1つのPlaybookに直書きしていたものが、roleを分割して管理したり、インベントリも親子関係をもたせたり…などです。すると、これまでは簡単に把握できていたものが、いつの間にかカオスになっていき、依存関係を把握できなくなっていきます。 依存関係を簡単に把握するにはどうすればよいか？そう、可視化です。可視化することで、い
コードの半減期とテセウスの船 | POSTD
プロジェクトが発展する際は、単純に新しいコードが古いコードの上に追加されているのでしょうか。もしくは、時間をかけて徐々に古いコードが新しいコードに置き換えられているのでしょうか。これを解明するために、手ごわい GitPython プロジェクトの助けを借りて、Gitプロジェクトを分析する 簡単なプログラム を構築してみました。履歴を年ごとに振り返り、 git blame を実行してみようと思ったのです（この処理を多少でも速くすることは簡単ではないと分かりました。しかし、ファイルのキャッシングを便宜的に含ませることや、変更された点を履歴から見つけること、 git diff を使って変更したファイルを無効にすることなどの詳細を、いつかお伝えします）。 頭がさえている時に、 テセウスの船 をダサくもじって、 “テセウスのGit” と名付けました。私は父親になって、ひどいダジャレを作れるようになった
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
