マンションのネットが遅すぎるのでサポートに電話したらタワマンの闇だった→引っ越すしかないな…

2023/08/14 211 users タワマン マンション open-source サポート ネット

Rui Ueyama @rui314 Googleソフトウェアエンジニア / スタンフォード大学院コンピュータサイエンス→投資生活→スタートアップ創業 Open-source dev. ex-@Google. MS/CS at Stanford. Creator of the mold and lld linkers. 帰国して婚活予定 github.com/rui314 Rui Ueyama @rui314 マンションのネットが遅すぎるのでサポ... 続きを読む

オープンソースビジネスの挑戦と現実｜Rui Ueyama

2023/06/07 625 users 現実 挑戦

いい感じのオープンソース・ソフトウェアを書いて、それを元に起業することを考えてみたことがある人は結構いるようだ。実際に僕はここ1年半ほど、自作のオープンソース・ソフトウェアを元にビジネスを立ち上げようと試行錯誤してきた。その経験についてここでシェアしてみようと思う。 あらすじ薄々予期していたことで... 続きを読む

スタンフォード大学で「ここまでそれ分かってなくて聞いてたの？」という質問をする生徒がかなりいた→質問しやすい環境が学びやすさに繋がっている - Togetter

2021/08/15 389 users スタンフォード Togetter rui314 授業 どちら側

Rui Ueyama @rui314 スタンフォードの授業で「え、ここまでそれわかってなくて聞いてたの？」という質問をしてる生徒はかなりいたし、教える方は驚くこともなく普通にそういう基本的な質問に答えていたので、ああいうのは見習いたい（どちら側も）。 2021-08-14 21:55:14 Rui Ueyama @rui314 こういうの、難しい問題とか... 続きを読む

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

2019/11/04 865 users プロトコル Note パケット 欠点 IPv6

現在のインターネットの基本をなしているIPv4というプロトコルには、広く知られた大きな欠点がある。パケットのアドレスフィールドの幅が32ビットなので、ネットワークに接続可能なホスト数の上限が2³²（約43億）になってしまっているのだ。その欠点を修正するために、1990年代後半にIPv6という新たなプロトコルが設計さ... 続きを読む

オープンソース活動がフルタイムの仕事になる仕組みの話｜Rui Ueyama｜note

2018/11/01 606 users アップル ソニー プロダクト Note 反応

僕の仕事をひとに説明するときに、「Googleで仕事をしているけどオープンソースなのでGoogleのプロダクトを作っているわけではないし、むしろアップルとかソニーの人と一緒に仕事している」と言うと、「？？？」という反応になることが多いので、僕はこういう仕事をしているんだよということをここでちょっと説明してみ... 続きを読む

Cコンパイラ制作の夏期集中コースが思っていた以上にうまくいった話｜Rui Ueyama｜note

2018/09/01 404 users Note

2018年の夏に僕はセキュリティキャンプ（以下「セキュキャン」）というイベントでCコンパイラ作成コースの授業を行いました。授業はとてもうまくいったといってよいと思います。参加者は6人だったのですが、6人全員プログラミング技術がかなり飛躍的に向上したようですし、そのうち3人は期間中にセルフホスト（自分の書... 続きを読む

音の良いポッドキャストを録音するために ― Turing Complete FMの収録テクニック｜Rui Ueyama｜note

2018/04/24 119 users 音質 ポッドキャスト Note ノウハウ 収録

僕は最近 Turing Complete FM というポッドキャストを運営しているのですが、その収録のためにポッドキャスト録音テクニックを結構研究しました。ここではそのノウハウをシェアしようと思います。音がよくて聞きやすいポッドキャストの収録に役立ててもらえると幸いです。 はじめに ポッドキャストでは音質は死活的に重要です。音質の大切さは強調してしすぎることはないと思うのですが、初心者はこの点を甘... 続きを読む

「悪い方が良い」原則と僕の体験談｜Rui Ueyama｜note

2018/04/06 999 users Note 原則 リンカ lld コンパイラ

ソフトウェアの世界には 「悪い方が良い」原則 という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカのオリジナルの作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイ... 続きを読む

コンピュータセキュリティと様々なサイドチャネル攻撃｜Rui Ueyama｜note

2018/01/19 123 users コンピュータセキュリティ VMware セキュア Note

コンピュータセキュリティというのは微妙なもので、正面からの攻撃には安全でも、攻撃対象とは思われていなかった部分を突くとあっさり情報が盗めるパターンがある。そういう攻撃手法をサイドチャネル攻撃という。ここではサイドチャネル攻撃についていくつか見てみよう。 たとえば社外秘の文書をセキュアにブラウズしたいとしよう。VMwareなどを使って仮想マシンにOSを2つインストールして、通常利用環境とセキュア環境... 続きを読む

意図的にプログラムの動きをランダムにしてバグを早期発見するテクニックについて｜Rui Ueyama｜note

2017/12/13 275 users ドッカンバトル 順序 Note ガチャ パク

プログラムを書いていると、素直に実装した結果として毎回特定の条件が満たされているけど、本来はそれは誰に保証されていないという場面に出くわすことがよくある。保証されていない偶然の動作に依存することで生じるバグというのはかなり多い。 例えば最近では、ドッカンバトルというゲームで、2回SQL文を実行した結果が同じ順序で並んでいるという誤った期待をしているコードがあったせいで、ガチャの確率がめちゃくちゃに... 続きを読む

ソビエトロシアの3進コンピュータ｜Rui Ueyama｜note

2017/12/11 103 users Note

ロシア人の同僚に、ロシアには3進コンピュータがあったらしいよね、という話をしたら、僕の大学の教授がそのコンピュータの発明者と一緒に仕事してたよ、と言われたことがあった。ソビエト連邦には3進数のコンピュータが実際にあったのだ。その奇妙な機械についてちょっと書いてみよう。 普通の2進コンピュータでは、数の1桁を1ビットといって、1ビットで2つのパターンを表すことができる。同じように、3進コンピュータで... 続きを読む

コンパイラに仕込まれた細工とシステムのセキュリティの話｜Rui Ueyama｜note

2017/12/11 105 users コンパイラ バイナリ スクラッチ 代々 Cコンパイラ

コンパイラのソースには書いていないのにバイナリだけで代々伝わっていく情報というのがあって、それはコンピュータのセキュリティに大きく関わっている。ここではそれについて書いてみよう。 僕は 8cc というCコンパイラをスクラッチから書いたことがあるのだけど、8ccには文字列を読む部分で、"\"の後に"n"がきたら"\n"という文字（改行文字）を読んだことにするという 箇所 がある。これはよく考えてみれ... 続きを読む

高頻度アルゴリズム取引業者の終わりなきスピード競争｜Rui Ueyama｜note

2017/12/05 307 users Note レイテンシ スピード競争 死活問題 マイクロ秒単位

誰にとっても通信速度は遅いより速い方がいいけど、情報の速さで利益を出している高頻度アルゴリズム取引業者にとっては、通信速度は死活問題だ。そういった業者のために、証券取引所間のレイテンシをマイクロ秒単位で減らすネットワークが、数百億～数千億円というお金を使って構築されている。ここではそういうネットワークについて書いてみよう。 いつの時代でも、証券取引の参加者にとって、他の証券取引所の状況をいち早く知... 続きを読む

もしコンパイラを全世界で同時にうっかり削除してしまったら、元の状態に復旧できるのだろうか？｜Rui Ueyama｜note

2017/12/03 471 users コンパイラ インタープリタ Note 人類 結論

思考実験として、全世界の人が同時に、自分の持っているコンパイラやインタープリタなどの実行ファイルをうっかり全部消してしまったとしよう。そうするとそれ以降、ソースコードが残っていても、コンパイラ自身も含めてどのようなプログラムもコンパイルできなくなってしまう。この状況から人類は元のコンピュータ文明を復旧することができるのだろうか？ 僕は結論としては、かなり簡単に復旧できると思う。ここではその手順につ... 続きを読む

システム障害なしにうるう秒を乗り切る技術の発達について｜Rui Ueyama｜note

2017/11/30 134 users Note ベストプラクティス 発達 う秒 自転速度

数年に一度、1秒だけ1日が長くなることがある。そのたびにどこかでシステム障害が起こるのだが、何回もうるう秒を経験するごとに次第にベストプラクティスも確立されつつある。ここではうるう秒問題と人々がそれにどう対応してきたかについて説明しよう。 うるう秒というのは地球の自転速度のわずかな揺らぎに対して時計を調整するために数年に一回調整される1秒のことだ。うるう秒で1秒短くなる日は23:59:59からの1... 続きを読む

十分大きな乱数をユニークな識別子として使うのがなぜ安全なのか｜Rui Ueyama｜note

2017/11/29 274 users Note 識別子 UUID 乱数 Git

いろいろなソフトウェアで、大きいランダムな値をユニークな値とみなすということが行われている。例えばユニークな識別子としてよく使われる UUID はただの128ビットの乱数だ。gitも SHA-1 ハッシュ値が160ビットの乱数のように扱えることを期待して、それをユニークな識別子として使っていた。実際にはランダムな2つの値が同じになる確率はゼロではないのに、なぜこれが安全なやり方だと言えるのだろうか... 続きを読む

エレベータに見るアルゴリズムの性能と公平性のバランス｜Rui Ueyama｜note

2017/11/23 446 users エレベータ アルゴリズム HDD Note コンピュータ

現実世界でもコンピュータの中でも、何らかの性能指標だけを追求すると参加者にとって極端に不公平になってしまうことがある。例えばエレベータとHDDは共通点がありそうに思えないが、この2つは性能特性的にとてもよく似ていて、リーズナブルな性能と公平性を両立させるために同じ制御方法が使われている。これについてちょっと説明してみよう。 1基しかない場合のエレベータの動き方は単純だ。一度上に動き出すと、上で待っ... 続きを読む

乱数生成器とゲームと諜報活動の話｜Rui Ueyama｜note

2017/11/22 466 users Note https 諜報活動 乱数生成器 WiFi

ゲームなどを作っているとランダムさが必要になることがあるけど、コンピュータは基本的に毎回全く同じように動くので、乱数を作り出すのはそう簡単な話ではない。WiFiやHTTPSなどの暗号は乱数のランダムさに本質的に依存しているので、高品質な乱数生成は社会的にも重要な話題である。ここでは乱数生成について話をしてみよう。 ゲームではイベントがプレイヤーに予測不可能であればよいだけなので、真の乱数列ではなく... 続きを読む

メモリのエラーとセキュリティの話｜Rui Ueyama｜note

2017/11/20 680 users Note メモリ エラー セキュリティ メモリエラー

ハードウェアのエラーでメモリの内容が化けてしまうことがごく稀にある。大抵のDRAMエラーはプログラムがクラッシュする結果になるだけだが、稀にデータ破壊になることもあるし、悪意のある使い方をすればセキュリティ破りに使うこともできてしまう。ここではメモリエラーとセキュリティの話をしようと思う。 メモリのエラー率は意外なほど高い。データセンターで大規模なマシン群を対象に 実際に観測 したところ、1年間に... 続きを読む

オーバーフローが引き起こした面白いバグの話｜Rui Ueyama｜note

2017/11/17 541 users 空中 Note パク ロケット 数値

一度聞いたら忘れられないような印象深いバグというものがある。僕は数値のオーバーフローと聞くと必ずこの2つのバグを思い出してしまう。どちらも面白いエピソードなのでちょっと紹介してみよう。 一つ目は、Ariane 5ロケットの初回テスト打ち上げ時に発覚したバグである。この事例では、ロケット打ち上げ数十秒後に制御プログラムが停止してロケットが進行方向に対して横を向いてしまい、空中分解して、400億円近く... 続きを読む

ソフトウェアの互換性と僕らの"User-Agent"文字列問題｜Rui Ueyama｜note

2017/11/15 690 users User-Agent リンカ アドホック lld Note

いろいろな環境で動くプログラムでは互換性のためにアドホックなことをしないといけないことがよくあるけど、歴史が積み重なってくると、アドホックな技の上にアドホックな技が積み上がる喜劇的な状態になることがある。こういう問題は認識するのは簡単だが直すことは誰にもできない。まさに僕がそのような体験をしたのでちょっと説明したい。 僕は仕事としてオープンソースのlldというリンカを書いている。リンカというのはコ... 続きを読む

絵文字がある種のUnicodeバグを世界から一掃しつつある件について｜Rui Ueyama｜note

2017/11/13 1446 users Note unicode UTF 絵文字 プログラム

UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて... 続きを読む

「プログラミングの常識」を時々見直す必要性について｜Rui Ueyama｜note

2017/11/02 1011 users Note プログラミング 常識 血道 window

自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindow... 続きを読む

スタンフォードのコンピュータサイエンスの授業の感想｜Rui Ueyama｜note

2017/04/06 564 users スタンフォード Note Itanium レジスタ コンパイラ

いまのところ25単位分（マスター修了に必要な単位数の約半分）の授業を取ったので感想を時系列でちょっとまとめたい。昔のやつは記憶が曖昧になっているけど。 CS 243 プログラムの解析と最適化 要するにコンパイラの最適化の授業。前半はデータフロー解析とかでかなり実用的な感じがしたが、後半は行列計算の命令の依存関係を抽出してベクトル最適化とか、ItaniumみたいにレジスタのたくさんあるCPUでループ... 続きを読む

ソフトウェアエンジニアならもっと気軽にアメリカ移住を考えたほうがいいよ｜Rui Ueyama｜note

2016/12/26 490 users Note ソフトウェアエンジニア アメリカ移住

なんか数年に一回くらいシリコンバレー移住は割りに合うのかという話が上がってくる気がする。前の 地獄のシリコンバレー はトンチンカンで噴飯ものだったけど、今回の 海外移住？アメリカは止めた方がいいよ はまあまあまともな意見な気がする。でも、なんか違うよなーと思った。 まず第一にやっぱりアメリカの方が待遇がずっとよくて、物価差を考慮に入れてもやっぱり全然違うと思う。やや大げさかもしれないけど、日本のプ... 続きを読む