タグ

2017年1月15日のブックマーク (5件)

  • nullが生まれた背景と現在のnullの問題点 ― null参照問題(前編)

    Cの系譜を継ぐC#ではnullが長らく使い続けられてきたが、最近ではその存在が大きな問題だと認識されている。前後編でこの問題を取り上げ、今回(前編)はnullを取り巻く事情について考察する。 ← 前回 連載 INDEX 次回 → 近年、nullの存在は、billion dollar mistake(10億ドル規模の損失をもたらす過ち)と呼ばれるくらい忌避されるものになっている。 nullは、低コストでそこそこ安全に参照を扱えるという意味で悪くない妥協ではあるが、技術が進歩した現在ではもう少し賢い参照の扱い方があるはずである。C#のように、これまでnullを認めてしまっているプログラミング言語で、今からそれを完全になくすというのは現実的ではないが、nullに起因する問題を少しでも避ける手段はこれからでも追加していけるだろう。 今回は、nullが生まれるに至った背景から始め、nullが抱える問

  • Dockerのネットワーク構成 - 映画は中劇

    Dockerのネットワーク構成について整理する。 図1: Dockerネットワーク全体図 物理NICが1個ついたDockerホストに2つのコンテナを立てると、図1のようになる。コンテナは172.17.X.Xのネットワーク内にいて、ホスト側には172.17.0.1のIPアドレスが付く。この構成自体は、VirtualBoxで言うところのホストオンリーネットワークと同じようなもの。異なる点として、Dockerネットワークは、ハードウェア仮想化ではなく、Linuxカーネルの機能であるvethペアとブリッジを組み合わせて実現される。 図2: vethペア veth (virtual Ethernet) は、図2のように、仮想NICのペアと、それをつなぐ仮想ケーブルを作る機能。ふたつの仮想NICはイーサネットで直接通信できる。 図3: ブリッジ ブリッジとは、LinuxマシンがL2スイッチ(スイッチン

    Dockerのネットワーク構成 - 映画は中劇
  • 旦那が〇年間作り続けたゲームをプレイした同人嫁の雑記

    01/13 17/01/13 追記 SNS等にて当ブログをご紹介下さり、まことにありがとうございます。 勘違いされている方が居らっしゃるようなので明言させて頂きますが、 私の夫は当該ゲーム開発チームの一スタッフにすぎません。 また、当記事は文中にネタバレを含みますのでご留意下さい。 01/12 序) 「自殺するならこういう時なのかもしれない」 「自殺するならこういう時なのかもしれない」 長年とあるゲームの開発に従事した旦那が、晴れてタイトルリリースを迎えたその日、突然そう言った。 ひとつの仕事を成し遂げ、尊敬できる仲間や愛すべき家族がおり、今の自分には何の不安も恐れもない。 燃え尽き症候群じゃないけれど、心が小気味よく凪いでいて、自殺するとしたら、こんな時なのかもしれない。 自分にはこれしかないと身一つで業界に飛び込んだ、単なるゲームバカ。 「俺は死ぬまでエンタテイナーでありたい」と、空

    旦那が〇年間作り続けたゲームをプレイした同人嫁の雑記
    toritori0318
    toritori0318 2017/01/15
    よかった
  • Re:golang の http.Client を速くする

    先日mattnさんの記事を読みました。 golang の http.Client を速くする nettというパッケージを使って 名前解決の結果をキャッシュすることで、http.Clientを早くするというものです。 この記事に関して、ちょっと疑問に思ったことがあったので、検証してみました。 疑問 疑問に思ったのは以下の点です。 名前解決遅すぎでは? ベンチマークの結果を見ると5億ns(=500ms)ほど速度が改善しています。 3つのURLに対してリクエストを投げているので、初回を除く2回DNSのキャッシュがヒットし、 名前解決2回分の速度改善になるはずです。 と、いうことは、名前解決1回あたり250msかかっている計算になります。 googleのsearchは302でリダイレクトがかかるので、Client.Getの呼び出し1回あたり2回リクエストが飛ぶ、 ということを計算に入れても100m

  • Big Sky :: golang の http.Client を速くする

    « Windows からも ssh でリモートコマンド実行したい、それ golang で出来るよ | Main | Re: Go でシングルバイナリな Web アプリを開発しているときに webpack --watch をうまいところやる » この記事には幾らか正しくない部分がありました。後で訂正していきますが、ひとまず shogo82148 さんの解説記事も確認下さい。 http.Client はリクエスト毎に名前を引くので連続したアクセスはあまり速くない。 Goのhttp.Clientで名前解決結果cacheする楽な方法ないかな — fujiwara (@fujiwara) December 7, 2016 Go 1.8 からは Resolver が提供されるので、自前で簡単に名前引きのキャッシュを実装出来る。 Go 1.9 だった様です。 Go 1.8 Release Notes -

    Big Sky :: golang の http.Client を速くする