MITがSICPを教えなくなった理由
Programming by poking: why MIT stopped teaching SICP | posterior science このNYC Lisp meetupの動画で、Gerry Sussmanに対する質問として、SussmanとAbelsonの古典、The Structure and Interpretation of Computer Programs(SICP)に基づく、伝説的な6.001講義をなぜMITはやめたのかと聞かれている。 Sussmanの回答としては、SussmanとHal Abelsonは1980年代から延々と教え続けるに嫌気が差し、1997年に、学部長の事務所に行って、「俺らはやめる。後どうするからは勝手に考えろ」と宣言した。より重要なこととしては、SICPのカリキュラムは、今日のエンジニアリングに求められるエンジニアを育てることができないからで
GoogleのエンジニアがAmazonで片っ端からType-C USBケーブルをレビューしている
Amazon.com: Profile for Benson Leung GoogleのChromebook PixelのエンジニアであるBenson Leungが、アマゾンで売られているType-C対応を謳っているUSBケーブルとアダプターを片っ端からレビューしている。 なぜそんなことをしているのか。Googleの製品であるChromebook PixelはUSB Type-Cによる充電ができるが、巷に出回っている自称USB Type-C対応の製品の多くが、USB規格に違反していたり、十分な性能がない欠陥品だったりするからだ。 そもそも、USB Type-C規格は、3A, 5V, 15Wの電力供給ができる。3Aの電力供給は、途中の経路がすべてUSB Type-C対応の製品である場合に限る。例えば、途中にUSB 2.0などのレガシーケーブルを挟む場合は、USB Type-C規格準拠のケーブ
Sarah Sharp、Linuxカーネルコミュニティの暴力性に嫌気がさして貢献をやめる
Closing a door | The Geekess ドアは閉められた この記事は一年もの間、下書きフォルダーに入れてた。いまこそ投稿すべき時。炎上は怖かったので、この問題について触れるのはなるべく避けてきたのだけれど、部屋の中の象を指摘しないのはもやもやする。そういうわけで、公開する。 つまりこういうこと。私はもうLinuxカーネル開発者じゃなくなった。2014年の5月にUSB 3.0ホストコントローラードライバーのメンテナーの座を明け渡したし、2015年の1月には女性向けFOSS推進計画(FOSS Outreach Program for Women)のLinuxカーネル部門とかその他の役職も降りたし、2014年12月6日には、最後のLinuxカーネル開発のプレゼンをした。2015年8月のシアトルでのLinux Plumbers Conferenceへの協力は断った。Linux財団
C++参考書、C＋＋11/14 コア言語を9月に出版予定
C++11/14のコア言語の参考書。「C++11/14コア言語」が出版社ドワンゴ、販売KADOKAWAとして、9月に出版される。内容は、以下を書籍にしたものだ。内容としてはすでにすべて読むことができる。 EzoeRyou/cpp-book EzoeRyou/cpp14-appendix アマゾンには情報が掲載されたようだ。 Amazon.co.jp： C＋＋11/14 コア言語: 江添 亮: 本 紙の本の他にも、KindleとepubとPDF版も現時点で出す予定だ。また、もちろん本のソースコードも公開される。 ソースコードは、Markdown形式だ。もともとこの本はXHTMLで手書きされたが、それでは扱いづらいため、これを一度Markdownに変換した上で修正し、pandoc経由でtexに変換してから各フォーマットを生成している。不自由なフォント以外のソースコードは公開できるだろう。 本の
Jacob Kaplan-MossのPyCon 2015における基調講演: プログラミングの才能という都市伝説
Keynote - Jacob Kaplan-Moss - Pycon 2015 - YouTube The programming talent myth [LWN.net] PyCon 2015で、Djangoの貢献者であるJacob Kaplan-Mossが興味深い基調講演をしているので紹介する。LWM.netでほぼ全面書き起こしに近いまとめがあったので助かった。 自己紹介 Kaplan-MossはDjangoの貢献者であり、Herokuのセキュリテイ部門の部長である。PyCon参加者としては歴史が長く、その他のカンファレンスでもよく発表している。Pythonコミュニティは「自分にとってこの業界におけるとても重要なもの」であり、PyConの基調講演を行うということは、「自分のキャリア上の絶頂」である。 自分の最初のPyConの発表は2005年のことで、PythonとAppleScri
最近のC言語の配列
N4188を読んでいて、C言語の規格を参照する必要が出てきたので、C言語の規格を読んだのだが、最近のC言語の配列は、面白いことになっている。 以下はすべて最新のC規格で合法なコードである。 void f( char a[ * ] ) ; void g( char a[ static 100 ] ) ; void h( char a[ const volatile restrict ] ) ; void wtf( char a[ static const volatile restrict 1 ] ) ; これは、関数のプロトタイプ宣言でのみ許されている。 [*]は、サイズを指定しない可変長配列型である。関数のプロトタイプ宣言スコープの中でしか使えない。[]との違いは、完全形であることだ。 [static n]は、関数を呼び出した際の実引数は、少なくともn個の要素を持たなければならない。 v
cpで大量のファイルをコピーした（4億3200万件、39TB）
GNUのcpを使って大量のファイルをコピーしたところ、cpの設計上の問題で、極めてコピーが遅かったというお話。 My experience with using cp to copy a lot of files (432 millions, 39 TB) よう。俺は最近、大量のファイルをコピーする必要があったんだが、UNIXは20年もやってきた俺の経験からも、cpの挙動には驚かされたし、俺の意見はコミュニティに共有されるべきだと思う。 環境：古いDellのサーバー（2コア、初期メモリ2GB、追加して10GB、Ubuntu Trusty）と、新しいDellのストレージ格納機(MD 1200)にある、12個の4TBディスクでRAID 6が設定してあって、全体で40TBの要領を持ち、二つのドライブが同時に失敗しても問題ない環境。サーバーは遠隔地バックアップに使われていて、ディスクへの書き込みし
fork()は失敗するんだぜ、覚えときな
fork() can fail: this is important あー、fork()のことね。プロセスがもっとプロセス作るためのやつな。いや、他にもプロセス作る方法はあるけどな。ま、面白い話がもうひとつあるから聞かせてやるよ。 forkは失敗するんだぜ。分かってるか？ マジで分かってるか？ マジだぜ。forkは失敗するもんだ。mallocと同じさ。失敗することもある。そんなに頻繁にってわけじゃないけどさ、でも失敗したら、無視できっこないぜ。ちっとは脳みそ働かせなきゃならん。 forkが0を返したら、そいつは子プロセスで、親なら正数を返すってことは、みんな知ってるよな。その値は子のpidだ。こいつを保存しといて、あとで使うってわけだ。 失敗を確認しない場合どうなるか知ってるか？ そうだよ。お前多分、"-1"（forkのエラー通知）をpidとして扱ってるんだろ。 さて、問題の始まりだ。本当
rebeccapurpleがCSS 4 colorに提案された経緯
Name #663399 "Becca Purple" in CSS4 Color? - Specifiction #663399を"Becca Purpule"としてCSS4 Colorに入れないか？ CSS colorに名前を追加する方法はわからないし、なにか目的に叶うものであるかどうかもわからないが、@meyerwebのCSSに対する貢献を明らかにするために、また標準化というのはそもそも社会的プロセスによって進められることを明らかにするために、#663399を"Becca Purple"と名付けないか？ これはいったいどういうことか。Beccaというのは、哀れにも六歳にして亡くなったEric Meyerの娘の名前なのだ。Eric MeyerはCSSの標準規格に尽力し、また、 Cascading Style Sheets: The Definitive Guideや、 Css Pock
プログラミングを学ぶ方法がわからない
最近、プログラミングをどうやって学べばいいのかわからなくなってしまった。 筆者はドワンゴに雇われている。ドワンゴに入社して早4ヶ月になろうとしている。ドワンゴに雇われている名目は、C++の啓蒙である。C++の啓蒙にはC++の教育も含まれる。したがって、筆者はそろそろC++の教育をしなければならない。 筆者は、プログラミングを教育する最良の方法は、参考書を執筆することだと考えている。直接対面して教えるのは非効率的だ。文章を書いておけば、大勢が学べる。では、どのような参考書を執筆すればいいのか。すでにC++11のコア言語の参考書は書いた。 EzoeRyou/cpp-book C++14対応も、正式なC++14規格制定後に行わなければならない。そしてライブラリは、もし他にやる人がいないのであれば、やらなければならないだろう。 しかし、これらの本は、C++をこれから学び始める人向けではない。C++
Python 2.7のサポート期間が2020年まで延長
peps: 76d43e52d978 Python 2.7のThe End Of Life時間(EOL、日没の時間)は5年間延長されて、2020年になった。この決定はPython 2.7の状態を明確にし、まだPython 3に移行出来ない利用者の懸念を取り除くものである。PEP 466も参照されたし。 この表明は、バグ修正リリースが頻繁に行われることを保証するものではないが、Python 2.7のバグ修正を行いたいボランティアの貢献を可能にし、また、今後もしばらくPython 2をサポートする必要のあるベンダーを満足させるものであろう。 Python 2.8はない。 いかにプログラミング言語にとって、下位互換性が重要化が分かる事例だ。Python 3は、下位互換性をぶち壊す変更をすべきではなかった。たとえどんなに汚かろうが、一度使われてしまった文法は、いまさら廃止することは出来ないのだ。
Multipath TCPについて
Multipath TCPとは、複数の経路を扱うためのTCP拡張である。実は、以前、本の虫: MultiPath TCPのLinuxカーネル実装という記事で、その実装デモを紹介している。 従来のTCPは、IPとの分離ができない。TCPヘッダーの中には、ひとつのIPアドレスとポートがある。経路ごとにIPアドレスが割り振られるので、経路を変えるには、別のTCPコネクションを貼り直さなければならない。 しかし、複数の通信経路を持つという環境は、もはや珍しいものでも何でもなくなっている。たとえば、多くのラップトップにはEthernetとWiFiの二つの経路があるし、スマートフォンにも、WiFiと3G/4Gという複数の経路がある。特にスマートフォンの場合、経路が使えるかどうかが頻繁に切り替わる。 過去に、TCPで複数のIPアドレスを扱う拡張はいくつも出されたが、いずれも、IPアドレスを隠すという点で
ドワンゴに入社した
そう。タイトル通りだ。筆者、江添亮はドワンゴに雇用された。一体、どのような経緯でドワンゴに入社するに至ったのか。また、どんな仕事をしているのか。それを説明するには、時系列を追って書いたほうがいいだろう。 2013年8月21日 ふとみると、以下のようなサブジェクトのメールが届いていた。 【ご相談】ドワンゴ主催の C++11, 14 に関する勉強会にスピーカーとしてご参加頂けないでしょうか C++11？ C++14？ なんと、日本にC++14などという単語を知っている企業があったのか。しかし・・・ドワンゴ？ SPAMだろうか。いや、こんなにピンポイントなSPAMがあるわけがない。 それにしても解せないメールだ。ドワンゴといえば、もちろん、あの有名なニコニコ動画の企業だ。ニコニコ動画と言えばWebサイトだ。ニコニコ動画やその関連サービスの開発にC++を使っているのだろうか。いやまて、たしか子会社
Blink、新機能に対して新たなベンダープレフィクスを追加しない決定
Blink and the end of vendor prefixes | NCZOnline Developer FAQ - The Chromium Projects Blink - The Chromium Projects Webkitからたもとを分かったBlinkは、Mozillaの方針に近い、新機能に対して新たなベンダープレフィクスを追加しない決定をした。これだけでもforkしたかいがあるというものだ。 ベンダープレフィクスとは、実験的実装のCSSプロパティを使うには、ブラウザーベンダー特有のプレフィクスの記述を要求することである。たとえば、border-radiusだ。 <p style="border : solid 1em red ; border-radius : 2em ; padding : 1em ;"> この文章は1emのサイズのボーダーで囲まれ、四隅は半径2
C++11参考書の公開：C++11の文法と機能
C++11の参考書をGitHubで公開する。 GitHub: EzoeRyou/cpp-book GitHubからzipでダウンロード GitHub Pagesでの閲覧：C++11の文法と機能 序 本書はC++11のコア言語の文法と機能を、標準規格書に従って解説したものである。正式なC++規格書として発行された後の、ひとつ後のドラフト規格、N3337 を参考にしている。ドラフト規格を参考にした理由は、正式なC++規格書は、個人での入手が煩わしいためである。読者に入手が困難な資料を元に記述された参考書は価値がない。そのため、読者が容易に入手できるドラフト規格のうち、正式なC++規格書とほとんどかわらないN3337を参考にした。 本書の対象読者は、C++を記述するものである。C++実装者ではない。そのため、サンプルコードを増やし、冗長な解説を増やし、C++コンパイラーを実装するための詳細な定義
Gentooを最速でブートせよ
Patrick's playground: October 2013 Archives KVM上のVMで、Gentooをひたすら短時間でブートして、haltさせる試み。 BOOTING FAST(ER) （より）高速に起動 本日、筆者は積年の疑問を解決すべく遊んだ。どのくらい速く、KVM上のVMでブートして、haltできるのか。 そこで、この実験のため、CPUの速度を最低の1.4GHzにした。そうでなければ面白くないだろう。目標は、KVMのVM上のGentoo/amd64を、十分に短い時間でブートして、haltすることだ。 rootファイルシステムはsquashfsにした。最初に行った1GBのext4ファイルシステム vs squashfsでは、fsck+mountというありがた迷惑のため、5秒の差がでたからだ。うへぇ。stage3を展開し、いくつか設定をして（デバッグのためにログインした
GNU Make 4.0にGNU Guileが組み込まれた
GNU Make 4.0 released GNU Make 4.0がリリースされた。 今回のリリースでは、GNU MakeはSchemeの実装であるGNU Guileを組み込んだ。これにより、Makefileの中でSchemeが書けるようになる。 その機能は、GNU Make ManualのGuile Functionの項目で説明されている。まだ、オンライン版のGNU Make Manualが2010年から更新されていないので、コミット時のドキュメントの差分のリンクする。 8.13 The `guile' Function 具体的な組み込み方法としては、make側にguileという関数が追加され、この引数に文字列を与えると、SchemeとしてGuileで処理されるようになる。おそらく、このように。 Hello.o : $(guile (string-append "hello" ".c"
なぜGCCのCプリプロセッサーはlinuxという名前のマクロ名を定義するのか
Why does the C preprocessor interpret the word "linux" as the constant "1"? - Stack Overflow Why does the C preprocessor interpret the word “linux” as the constant “1”? | Hacker News 以下のCコードをコンパイルしようとするとエラーになる。 $ cat test.c #include <stdio.h> int main(void) { int linux = 5; return 0; } $ gcc test.c test.c: In function ‘main’: test.c:4:9: error: expected identifier or ‘(’ before numeric constant なぜ
Shebangという謎な事実上業界標準について
Shebangとは、UNIXのシェルスクリプトの業界標準で、シェルスクリプトの一行目のコメントの、#!を意味する。sheが短母音か長母音か分からなかったので、英語ネイティブにたずねたところ、人によって意見が違う。短母音の方が多数派のようなので、一応シバンが近いものになるだろう。日本語版のWikipediaでも、シバンとしている。この機能には他にも多数の名前があるが、もっとも有名なのが、Shebangだそうだ。 その業界標準的な文法は、以下の通り（ただし、後述するように、この文字列の扱いについては違いがある） #! 文字列 [改行] 普通、実行権限のついたファイルは、標準のシェルで実行されるが、このShebangがある場合は、#!から改行までの間の文字列を、後述するバラバラな方法で解釈して、execで実行し、その際の引数には元のシェルスクリプトファイルへのパスが指定される。 問題は、このsh
GNUのAutotoolsについて学んでいる。
C++の参考書も書かなければならないのだが、今、GNUのAutotoolsについて学んでいる。そもそも、何故必要なのか（なぜ手でMakefileを書かないのか）というところから調べている。 GNU Autoconf, Automake and Libtool Autotools: a practitioner's guide to Autoconf, Automake and Libtool GNU coding standards - GNU Project - Free Software Foundation (FSF) 今のところの背景事情の理解としては、以下のようなものではないかと思う。 はじめに、makeがあった。makeをとりあえず使うのは簡単だが、すこし高度なことをしようとすると、とたんに難しくなる。そのため、既存のよく書かれたものがプロジェクトからプロジェクトへと流用されて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
