以下のプレゼンテーションは、私がPapers We Love Madridの初会議で発表したものです。講演のテーマは、Donald Knuthの論文「Structured Programming with Go To Statements」（goto文を用いた構造化プログラミング）でした。 我々が人間として抱える最大の問題は、信念と現実を混同することである。 – Alan Kay それ（goto）を禁止するか、それとも使わない方向へ教育するかが問題だ。 – Donald Knuth この記事では、神話についてお話ししたいと思います。Googleで 神話（myth） の定義を検索してみると「広く信じられているが誤った信念や観念」とあり、dictionary.comを見ると「立証されていないか誤った共通的信念であり、社会制度を正当化するために用いられる」と説明されています。ここで問いたいのは、

こんなことを想像してみてください。 あなたは大企業で働いています。仕事はかなり退屈です。端的に言えば、あなたの顔も見たくないという経理担当の3人しか使わないようなアプリケーションのために定型的なコードを書いて、才能を無駄にしているという状況です。 あなたが本当に情熱を注げるのはセキュリティです。毎日、 r/netsec を読み、仕事の後にはバグ報奨金プログラムに参加しています。ここ3カ月間は手の込んだ株式取引ゲームをプレイし、報奨金を得ています。ヒープベースのバッファオーバーフローを発見し、優良株を選ぶ手助けとなるAVRシェルコードをいくつか書いたからです。 あなたが取り組んできたビデオゲームが、実は巧妙な偽装のリクルートツールであったと判明し、全てが変わります。世界最高のセキュリティコンサルタント会社、Mont Piperが人材を募集していて、あなたは面接に行くことになったのです！ 飛行

(訳注：2016/9/28、頂きましたフィードバックを元に記事を修正いたしました。) ことの始まりは、あるスパムキャンペーンでした。画像1は、スパム向けに仕掛けた罠に最近引っかかった、疑わしいドキュメントファイルが添付されたメールです。文面の英語がとても稚拙なことに気付くかと思いますが、この稚拙さがメール受信者への警告サインとなります。 画像1：スパムサンプル 添付のファイルは、”.doc”のファイル拡張子を使っていますが、実際はRTF（リッチテキストファイル）ファイル形式で、特別に細工されたRTFファイルによるスタックオーバーフローの脆弱性が含まれています。この脆弱性は、CVE-2010-3333で文書化されており、”pFragments”の形をしたプロパティを扱う際にMicrosoft Word RFTパーサを攻撃するものです。これに対する修正モジュールは5年以上前にパッチされています

この記事はTCPの 全て を理解する、あるいは 『TCP/IP Illustrated』 （訳注：日本語版: 『詳解TCP/IP〈Vol.1〉プロトコル』 ）を読破しようとか、そういうことではありません。ほんの少しのTCPの知識がどれほど欠かせないものなのかについてお話します。まずはその理由をお話しましょう。 私が Recurse Center で働いているとき、PythonでTCPスタックを書きました（ またPythonでTCPスタックを書いたらどうなるかについても書きました ）。それはとても楽しく、ためになる経験でした。またそれでいいと思っていたんです。 そこから1年ぐらい経って、仕事で、誰かが「NSQへメッセージを送ったんだが、毎回40ミリ秒かかる」とSlackに投稿しているのを見つけました。私はこの問題についてすでに1週間ほど考え込んでいましたが、さっぱり答えがでませんでした。 こ

(訳注：7/24、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注2：8/4、いただいた翻訳フィードバックを元に記事を再修正いたしました。) この2010年代にLinuxシステムの管理者をしていれば、systemdに関して何かしら思うところがあるでしょう。そして私は管理者たちの意見が両極端に分かれていることに驚きました。ほとんどの人（少なくとも意見を表明している人達）はsystemdが「大好き」か「大嫌い」かのどちらかのようです。私の場合、systemdをきっかけに昨年OpenBSDを使うことになったのですが、これを話したことで私がsystemdを「大嫌い」だと思われたようです。でも、それは違います。 本当は、systemd自体は私がOpenBSDに移った理由のほんの一部にすぎません。しかし、この経験によって2つの重要な点に気付きました。まず、最近のLinuxの設計の問

この10年間で、3つのメジャーなプログラミング言語が、それぞれPerl 6、Python 3、PHP 6へと大幅なバージョンアップに乗り出しました。ところが、Unicodeのサポート問題などの表面的な類似点があるにも関わらず、根本的に異なった展開を見せています。 今年Perl 6.0.0が公式にリリースされるのに伴い、いま一度振り返って、リリース後の展開について考えてみるのに、今はちょうどいいタイミングでしょう。 これを書いていることが自分でも信じられないのですが、PHPから学ぶべきことがあるかどうか見ていきましょう。Zend TechnologiesのCEOであるAndi Gutmans氏は2008年2月の インタビュー でこう答えています。 我々はPHP 6に対し長いサイクルでのロールアウトを予想している。Perlプロジェクトに対しては、プロジェクトのコントリビューターがいまだPerl

多くの言語は冗長性を有していますが、これらの機能を省いていくことも言語設計の進歩につながります。 巷には数多くのプログラミング言語があり、新しい言語も継続的に紹介されています。でも新しいものが古いものより優れているかというと、そうとは言えません。なぜなら、何が“優れているか”を判断する明確な尺度は存在しないからです。 それでも過去からの流れを見ていくと、優れた言語を作る1つの方向性は、言語にある冗長性を特定し、それらを持たない新たな言語をデザインすることにあるように思えます。 「完璧とは、それ以上足せない時ではなく、それ以上引けない時に達成される」 – Antoine de Saint Exupéry この投稿では、現在までに知られている言語の冗長的機能を見ていくと共に、恐らく冗長性を有しているだろうと思われる機能についても触れていきます。 自ら墓穴を掘るあらゆる可能性 初めてコンピュータ

(注記：4/16、いただいた翻訳フィードバックを元に記事を修正いたしました。) （訳注:文中のすべてのグラフ画像は 原文のページ で拡大・縮小しながらご覧いただけます） 20万ユーザの8400万コメントをネットワーク図で解析 誰しも関心事があります。つまり理解したいと思ったり話し合ったりしたいと思うような個々人の好みに近いトピックのことですね。でも、例えば初めてデートした時のぎこちなさが証明するように、人によって興味の対象は違うもので、すれ違うことだってままあります。ある人にとっては面白い内容でも、他の人にとっては涙が出るくらい退屈だったりすることもあるのです。そんなわけで、この投稿では人々の関心事やその相互の関連性について、もう少しつっこんで考えてみたいなと思っています。 特定の関心事の間には自明で自然な関連性があるという認識は、恐らく多くの人が持っているのではないでしょうか。関心事の分

これは Defrag 2014 の講演内容です。 テクノロジに長く従事することの（数少ない）利点の1つは、いくつもの技術サイクルの始めから終わりまでを見ることができるということです。いかにしてブレークスルーが実際に広まるかを見られるのです。サイクルの曲線の一部分しか見なければ、全体を正確に測り知るのは難しいでしょう。短期間で起きた進歩を見過ごしてしまうか、長期間で起こる進歩を見届けられないかのどちらかです。驚くべきことは世の中の事象がいかに速く変化するかではなく、その変化に呼応するエンジニアリングの変革がいかに遅いかということです。画像は、1891年に発明された、電話回線を自動で接続するストロージャー式自動交換機です。 1951年、デジタル交換機の最先端において、典型的な中央電話交換局はビクトリア期の特大サイズでした。ストロージャー式自動交換機は、通信中の全ての電話の信号を扱っていました。

2014年10月22日水曜日 崩壊などと大げさに騒がれているものの、実際はほとんどのテクノロジ系の大手企業、特にプラットフォームプロバイダは、その座を追われたわけではなく、影が薄くなっただけです。例えばIBMは50年もメインフレームの販売とサービスの提供を順調に続けています（ただしIBMは現在 深刻なトラブルに陥っています （ メンバーのみ ））。とは言え、PCの時代にIBMはMicrosoftの陰に隠れてしまいました。 メインフレームは今も存続可能なビジネスです。ただ、PCよりも規模がずっと小さいだけです。 同じことがMicrosoftにも起こりました。WindowsはいまだにPCを支配しており ^(1) 、おそらく、しばらくはこの状態が続くでしょう（ただし、その土台には確実にIBMと同じようなひび割れが生じていますが）。会社は安泰です。しかしPCはスマートフォンの台頭により陰りが生じ、

『銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項』 を書いたFred Brooksはその論文の中で、 偶有的な複雑性と本質的な複雑性 について重要な区別をしています。 本質的な複雑性 とは、問題特有の領域から生じる複雑性のことを指します。例えば、SMTPクライアントを作成しているディベロッパは、 RFC 5321 の核心の細かいところ全てに取り組む必要がありますが、これはSMTPクライアントの作業をする上で避けては通れないものです。これに対して 偶有的な複雑性 とは、私たちが自ら作り上げた問題から生じる複雑性のことを指します。 技術者としては、自らの選択で生じる偶有的な複雑性によって、余計な負担が増えないようにとても注意しなければなりませんよね。その意味では、言語の選択は偶有的な複雑性を軽減できる完璧な例と言えます。Webアプリケーションを書くのにアセンブリ言語を選びます

PGPに何が起こったのか？　 画像元: @bcrypt 先週木曜日（2014年8月7日）、YahooはGoogleのChrome拡張機能「End-to-End」を利用したエンドツーエンドの電子メール暗号化をサポートする意 […]PGPに何が起こったのか？　 画像元: @bcrypt 先週木曜日（2014年8月7日）、YahooはGoogleのChrome拡張機能「End-to-End」を利用したエンドツーエンドの電子メール暗号化をサポートする意向であることを発表しました。これは一大事です。GoogleやYahooのようなプロバイダの参戦で、電子メール暗号化はスゴイことになります。これはまさしく電子メールが必要としていたものです。 GoogleとYahooによる偉業があまりにも素晴らしいので、このあとの不満がひどく残念なものに聞こえるでしょう。私はそれを分かっていますし、最悪の気持ちです。

この記事はジェット推進研究所(JPL)におけるLispの盛衰について、私の（しかもかなり偏った）個人的見地から書きました。JPLの所員としての立場で書いているのではなく、JPLの公的な立場を代弁するものでもないことをお断りしておきます(これについては読み進めていただければ分かります)。 1988-1991 ロボット工学の時代 私は1988年にJPLに入所し、自律移動ロボットの人工知能（AI）グループに配属されました。当時は今と違って政府の財源から資金が潤沢に流入していました。「ＡＩの冬」が始まりかけていましたが、まだJPLには到達していませんでした。研究所の技術動向は最先端から数年遅れになる傾向があるようです。 当時のJPLはマーズ・ローバー・サンプル・リターン（MRSR）と呼ばれるマーズ・ローバー・ミッションの初期計画段階にありました。あの時代、宇宙ミッションはあらゆる意味で巨大でした。

今ちょうど、 科学者の手によるコードは質が低い という投稿を読み終えたところです。科学者の書いたコードは”ソフトウェア・エンジニア”が関与したコードと比べて質が劣るという内容でした。 私は10年以上同じ職場に勤めていますが、同僚の多くは数学や物理学が専門で、”ソフトウェア・エンジニアリング”の知識はほとんど持っていません。 そこでは、大惨事は必ずと言っていいほど、自分のことをいっぱしのプログラマだと思っている少数派によって引き起こされます。かくいう私も、少なくとも数件、いまだ解決を見ていない大きな不具合の原因を作ったことがあります。他にも大きめのバグをいくつか出しましたが、幸いその時のコードはお蔵入りしたため、私に無駄な給料を払わされた雇い主が被害をうけたくらいで、同僚の生産性を大きく損なうことはありませんでした。 その度（少なくともほとんどの場合）私は反省し、それまでにも増して退屈なくら

私は中級レベルのプログラマです。 基本を理解するのは得意です。過去の失敗をきちんと分析できるくらい経験を重ねていますし、もっと知るべきことは山ほどあることも分かっています。 特筆すべきは、自分で身につけるべきことを知ったうえで、それを吸収しようと積極的かつ精力的に取り組んでいる点でしょう。 プログラマとしての能力は平均的なものに過ぎないと、心から納得するまで時間がかかりました。今では、よく理解できないままに誰かの意見を受け売りする必要など感じていません。知らないことがあっても、それを他人に悟られるのは怖くありません。 でも以前は違いました。信じられないかもしれませんが、私はかつてプログラミングの達人だったのです。 自分の能力を誤って評価していたのは、比較的孤独な環境でスキルを学んだためでしょう。当時はコンピュータを持っていることさえ、ちょっと特別なことでした。使い方を知っているとなれば、な