タグ

ブックマーク / note.com/ruiu (7)

  • IPv6がなぜいまだに普及していないのか|Rui Ueyama

    現在のインターネットの基をなしているIPv4というプロトコルには、広く知られた大きな欠点がある。パケットのアドレスフィールドの幅が32ビットなので、ネットワークに接続可能なホスト数の上限が2³²(約43億)になってしまっているのだ。その欠点を修正するために、1990年代後半にIPv6という新たなプロトコルが設計されたのだけど、いまだにインターネットではIPv6は少数派で、主流ではいまだにIPv4が使われている。 1990年代当時は、IPv6は規格を策定すれば比較的すぐに普及するはずで、それによってインターネットが抱えているアドレス枯渇の問題が解決されるという雰囲気だったように思う。1998年にタイムトラベルして、20年たってもまだIPv4を置き換えることに成功していないと当時の人のIPv6推進者たちに教えたら、多分すごくびっくりされるだろう。一体どうしてこんなに普及が遅れてしまったのだろ

    IPv6がなぜいまだに普及していないのか|Rui Ueyama
  • オープンソース活動がフルタイムの仕事になる仕組みの話|Rui Ueyama|note

    僕の仕事をひとに説明するときに、「Google仕事をしているけどオープンソースなのでGoogleのプロダクトを作っているわけではないし、むしろアップルとかソニーの人と一緒に仕事している」と言うと、「???」という反応になることが多いので、僕はこういう仕事をしているんだよということをここでちょっと説明してみようと思います。 (2016年の僕のFacebookの投稿の転載です。) 僕のいるチームはLanguage Platform Teamというところで、プログラミング言語や開発ツールの開発をしています。LPTの中にもいろいろ細かいチームが分かれているのですが、僕がいるのはC++チームで、Googleで主要開発言語になっているC++言語の開発環境を担当しています。 C++で開発をするときには、C++ツールチェインと呼ばれる一連のツールを使います。ツールチェインの一番大きなコンポーネントは、人

    オープンソース活動がフルタイムの仕事になる仕組みの話|Rui Ueyama|note
  • Cコンパイラ制作の夏期集中コースが思っていた以上にうまくいった話|Rui Ueyama

    2018年の夏に僕はセキュリティキャンプ(以下「セキュキャン」)というイベントでCコンパイラ作成コースの授業を行いました。授業はとてもうまくいったといってよいと思います。参加者は6人だったのですが、6人全員プログラミング技術がかなり飛躍的に向上したようですし、そのうち3人は期間中にセルフホスト(自分の書いているコンパイラで自分のコンパイラ自身をコンパイルできること)まで漕ぎ着けることができました。 この文章では、その授業をどのように僕が教えたのかということと、生徒にできるだけ多くのことを学んでもらって自信をつけてもらうために僕が何を気をつけていたのかという2つの点について説明します。 セキュキャンとはセキュキャンは5日間の合宿イベントで、学生を対象としてコンピュータセキュリティやプログラミングについて教えるというものです。いくつものコースが用意されているのですが、僕が受け持ったのは「集中コ

    Cコンパイラ制作の夏期集中コースが思っていた以上にうまくいった話|Rui Ueyama
  • 「悪い方が良い」原則と僕の体験談|Rui Ueyama

    ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。

    「悪い方が良い」原則と僕の体験談|Rui Ueyama
  • 絵文字がある種のUnicodeバグを世界から一掃しつつある件について|Rui Ueyama

    UnicodeのUTF-16エンコーディングではほとんどの文字(コードポイント)は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語

    絵文字がある種のUnicodeバグを世界から一掃しつつある件について|Rui Ueyama
  • 「プログラミングの常識」を時々見直す必要性について|Rui Ueyama

    自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上のの開いているページを見るのと、そのAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの

    「プログラミングの常識」を時々見直す必要性について|Rui Ueyama
  • ソースコードって実際のところどういうふうに書いていますか?|Rui Ueyama

    私はプログラミングは結構自信があるんですが、他の人の作業をつぶさに観察したことがあるわけでもないので、自分で当たり前だと思っているコーディングの方法が他の人にとってはそうではないこともあると思ってます。上手い人がどういうふうにしてプログラムを書いているのか知りたいんですよね。 逆に私はどういうふうに書いているかちょっとまとめてみました。自分はこうしている、というのがあったらぜひ教えてください。 まず私の場合、ゼロからコードを書くよりも現在のプロジェクトのためのコードを書くことのほうが多いので、コードを書くというのは既存のコードに変更を加えることがほとんどです。既存のコードに手を加えるときは、新機能追加か、リファクタリング(動作は変えずにコードをきれいにすること)のどちらかになるわけですが、まず前者をどうしているかどうかをできるだけ説明してみます。 まず必要なのは考えることです。よく知ってい

    ソースコードって実際のところどういうふうに書いていますか?|Rui Ueyama
    abababababababa
    abababababababa 2016/07/16
    ブコメ、ためになる。
  • 1