Posted by & filed under いろいろ.


深町さんが既に書いていますが、WEB+DB PRESS vol61の特集記事「Scala & ClojureではじめるJVM言語」をアリエルで書きました。

WEB+DB PRESS Vol.61

JVM言語ネタでまさかのGroovy外し。と、まるでGroovyに喧嘩を売っているような記事です。しかしGroovyファンの方は怒らないでください。Groovyは特別なJVM言語です。今やJava EE界の帝国(井上の私見)、SpringSourceに愛されているからです。いずれ、Spring Framework、Groovy/Grails、Rooの3点セット(VMforceも合わせて4点セットかも)で別の特集記事をやればいい、ということにして今回の記事からGroovyが外れました。

言うまでもありませんが、ぼくはWEB+DB PRESSの中の人ではないので、こういう記事が本当に書かれるかは保証しません。伝えたいことは、Groovyが嫌いだから今回の記事にないなどのつまらない理由でないことです。

深町さんは流石に記憶力が良くて4ヶ月前のことをよく覚えています。ぼくはあまり記憶力が良くないのですが、Scalaの記事を書いてくれた岩永さんとの会話を再現してみます。

ぼくと岩永さんは普段だいたい英語で会話するので以下英語のままです。カッコでS式、ではなく日本語訳を書いておきます。

井上「Iwanaga-san, do you have time? (岩永さん、ちょっといいですか)」
岩永「Yes. (はい)」
井上「I’m thinking about an article on WEB+DB PRESS. (WEB+DB PRESSの記事についてですが)」
岩永「I see. (えぇ)」
井上「It would be about JVM language and it would contain a Scala part. (JVM言語の記事の予定でScalaのことも書きたいと思っています)」
岩永「Sounds good. (それはいいですね)」
井上「I heard you are a Scala programmer. Do you know someone who could do it? (岩永さんはScalaプログラマらしいですが、誰か書けそうな人を知っていますか?)」
岩永「Let me think… I know one person. (そうですね、ひとり知っています)」
井上「Who? (誰ですか)」
岩永「Me. I believe I am the best person except… (自分です。自分より適した人はいないと思います。ただし…)」
井上「Except? (ただし?)」
岩永「Except Martin Odersky. (Martin Oderskyは除きますが)」

記憶違いがあれば、岩永さんが訂正します。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under 開発.


 Common Lispはこの世に存在する言語の中でストレスなくプログラムできる唯一の言語であるというのは周知の事実です(ですよね?)。にも関わらず、実際に使われる機会はそれほど多くはありません。僕自身、仕事で使うのは難しいと考えています。

 たとえばこんなことを言われたとします。

「やあ深町くん。実は大急ぎでTwitterみたいなサービスをつくってほしいんだ。できれば1週間でね」

 そうすれば僕はこう言うでしょう。仕方ない。Perlだ。少しの間Common Lispと別れを告げ、ひたすらCPANを検索しつづける日々を迎えます。(もしくは転職先を探しているでしょう)

 なぜCommon Lispではないのか。違いは決定的なライブラリの数と質の差です。CPANには考えうる限りのライブラリがあり、しかも多くにおいて複数の選択肢が存在します。

 一方のCommon Lispはライブラリがあればラッキーです。そこから、パッチを当てることなく自分の処理系でビルドでき(はい、LOCAL-TIMEはアウト)、日本語まで扱えて(Drakmaがアウト)、よくメンテナンスされたドキュメントが揃っていて(Weblocksもアウト)、さらにわかりやすいAPIがあるなんて(CL-PPCREアウト)信じがたいことです。特にWebプログラミングで使えるものはひどいです。

 周りを見渡してみると、Perlに限らず、ここ10年人気を得てきた言語はWebプログラミングを容易にする努力を惜しみません。Perl、Python、RubyはWeb業界を中心にコミュニティが動いているようにすら見えます。

 僕は今、このLispを取り巻く環境を心底変えたいと思っています。古い慣習(シンボルを大文字で書くなんて!)を打ち捨てて、市民権を勝ち得てきた言語から多くを学ぶべきです。そして、現実的な問題として、たとえばCommon LispでWebアプリケーションを書けるように、といった努力をすべきでしょう。

 この意見に同意してくれる人は、きっとこのエントリを気に入ってくれると思います。そして協力してほしい。僕が作った”Clack“はCommon LispにWeb時代をもたらすものです。

Clackとは

 Clackを一言で説明するならば、「それぞれのWebサーバが持つ差異を吸収し、統一的なAPIを提供するためのWebアプリケーション環境」です。PythonのWSGI、RubyのRackからインスパイアされて実装しました。特に実装はPerlのPlackを参考にしています。

 たとえばClackをロードしたあと、以下のようなコードを実行します。

 ここでhttp://localhost:5000/にアクセスすると、「Hello, Clack!」と表示されるはずです。

Clackの利点

Webサーバを抽象化すること

 Rackの素晴らしい点は、よくこう説明されます。「WebサーバとHTTPリクエスト、レスポンスを抽象化することでWebアプリケーションをポータブルにする」。

 しかし、これだけであればClackを実装するメリットはほとんどありませんでした。Common LispにはHunchentootというLispで書かれた(しかも高速な)Webサーバが存在し、Webサーバ自身が高レベルなAPIを提供しているからです。

 あまり声に出して語られることはありませんが、Rackには素晴らしい点がもう一点あります。それはMiddlewareです。

Middlewareこそが今Lispに必要なもの

 Hunchentootが提供するAPIの上に何かをつくろうと思ったとき、アプリケーションを段階的に組み立てる仕組みがありません。Hunchentootのハンドラをマクロでラップして、ラップして、ラップして。出来上がるのはWeblocksのようなどこから手をつけていいのかわからないフレームワークになるでしょう。

 Common Lispのプロダクトはこういった設計で作られていることが多いです。竹内先生はこれを「泥団子」と表現しました。これはLispの強すぎる力によるものでしょう。他の言語では肩に力を入れて書くようなものが、マクロにマクロを重ねて簡単に作れてしまうがゆえです。

 しかし、これをどのレイヤーでも行うならば、再利用性がとても低いアプリケーションになってしまいます。部分的な利用、変更ができないカスタマイズ性の低いものになってしまいます。

 Hunchentootは必要以上に大きすぎます。URLディスパッチャだけでなく、セッション管理やログ機構まで備えています。もはや泥団子というより”そびえ立つクソ”とでも表現したほうがよさそうです。

 ClackではMiddlewareを使って、コアから切り離された処理を書くことができます。

 Middlewareはアプリケーションに直接手を加えることなくアプリケーションを拡張するための機構です。これを使えばアプリケーションに渡る前にHTTPリクエストをいじったり、返ってきたHTTPレスポンスを変更することができます。

 この設計のメリットはプロダクトを疎結合な小さな部品で構築することができる点です。

Clackが拓く未来

 Clackが既存のCLプロダクトに対して新しい点を明確にするためには、Clack上でフレームワークを作ることを考えるとわかりやすいのでもう少しClackの紹介を続けますね。

 Clackには標準でClack.App.Routeというアプリケーションをバンドルしました。これはTomohiro Matsuyamaが書いた、最小のフレームワークです。

 URLベースのディスパッチをRubyのSinatraのように記述できます。

 defrouteはマクロであり、単純なdefunに展開されます。

 また、それぞれのディスパッチ先の処理は関数として渡せるため、Clackアプリケーションを渡すことも可能です。

 Middlewareはどうでしょう。Hunchentootではセッションを保持する機能もありますが、保存する先がメモリかDBに限定されています。一方ClackではセッションがMiddlewareとして実装されており、以下のように呼び出せば有効になります。

 もし出力先を変えたければ、Clack.Session.Storeを継承するクラスを書くだけでFileやMemcachedにも対応することができます(僕には余力がなかった。誰か作って欲しい)。

 Clackの利点は疎結合による無限の拡張性です。本当はこの上にWebフレームワークでも書いて「ほらね?」とでも言ってあげれればいいのでしょうが、まだそこまでの余力はありません(誰か作って欲しい)。

 「Lispはどこまでも抽象化の層を重ねることができる」と言う人もいます。それは正しいのです。ドメイン特化の部分まで抽象化できるのは明らかなLispの力です。しかし、それは乱用すると再利用性のない巨大な泥団子になります。再利用できる部分は共通化する仕組みをつくるべきです。

 プログラムの世界は移り変わりが激しいです。技術を柔軟に組み合わせを変えられなければついていくのが難しくなるでしょう。5年後もHunchentootが使える世の中とは限りませんからね。

インストール

 Clackはcl-annotというライブラリに依存しているため、これを先にインストールする必要があります。cl-annotはTomohiro Matsuyamaが開発した、とてもクールなライブラリなのでいずれにしても導入することをおすすめします(この紹介記事はいずれ彼が書くでしょう)。

 残念なことにClackもcl-annotもまだQuicklispのリポジトリに入っていません(申請中)。使うにはそれぞれGitHubからダウンロードする必要があります。

 まずASDFの設定をします。ここでは~/lisp/systems/にライブラリを放り込むように設定しています。

 そして~/.config/common-lisp/source-registry.conf.d/01-add-local-lisp.confに以下のように記述します。

 これで~/lisp/systems/以下に置いたライブラリはすべてql:quickloadできるようになります。

 次にgit cloneします。

 あとはQuicklispでロードすれば依存パッケージもダウンロードされ、使える状態になるはずです。

まとめ

 Clackは何人かの友人のフィードバックを得ながら開発されました。Tomohiro Matsuyamaは実際にClackを使い、疎結合による開発のメリットを深く理解してくれました。

 Emacs Lispで有名なKenji ImakadoはClackからCommon Lispに興味を持ち、その上にフレームワークを作り、実際に使いたいとすら言ってくれました。

 現在考えうる限りで、Clackは間違いなくCommon LispでWeb開発するために最適な環境です。ぜひ使ってほしいです。

元記事 : Common LispがWeb業界を駆逐するとき – Revenge of Lisp in Web


関連文書:

Posted by & filed under 開発.


Common Lispプログラミングにおいて、lambdaは欠かすことのできない重要なパーツの一つですが、このlambdaにはいくつか知っておくべき慣習や決まり事があります。この記事では、lambdaに関する簡単な背景をふまえた上で、知っておきべき知識を簡潔にまとめようと思います。

ラムダ式

以下の形式のフォームをラムダ式と呼びます。ラムダ計算においては厳密にはラムダ抽象と呼ばれるのですが、Common Lispではラムダ式と呼びます。

プログラム内で、そのまま(lambda (...) ...)と書くと、コンパイラによって別物(後述)に変換されるので、通常はquoteを使ってラムダ式を表現します。

ご覧の通り、ラムダ式は普通のリストと何ら変わりがありません。

ラムダ式のfuncall

せっかくラムダ式を定義したのですから、ラムダ計算の最も重要な操作であるβ簡約(ここではfuncall)を定義しましょう。

Common Lispに詳しくない人のために簡単に説明しますと、このmy-funcall関数は、ラムダ式の引数リストと、my-funcallに渡された引数とのリストで、let束縛を持つフォームを生成し、そのフォームをevalすることでβ簡約(funcall)をエミュレートしています。例えば次の式を考えてみます。

この時、my-funcall

というフォームを生成してevalします。その結果、funcallと同じような効果が得られるわけです。

第一級オブジェクトとfunarg問題

ところで、他の関数にラムダ式を渡したり、関数の返り値としてラムダ式を返せたら便利だと思いませんか?あるプログラミング言語がこのような性質を備えているとき、ラムダ式は第一級オブジェクトと呼ばれます。また、ラムダ式を受け取ったり返したりする関数を高階関数と呼びます。当然ながらCommon Lispもこの重要な性質を備えています。

ラムダ式を第一級オブジェクトとして扱うにあたって考えなければならないのが、ラムダ式の自由変数を誰が補足するか、という問題です。例えば次の例を考えてみます。

make-adderは整数を受け取って、その整数に別の整数を足す関数を返します。二つ目の式はx1に束縛した後、2を足すadder生成し、そのadder3を渡しています。この式は実行可能な正しい式ではありませんが、重要なのは、(my-funcall adder 3)の時にどのxが参照されるべきか、という点です。make-adderxを無視するなら、評価結果は4になりますし、(let ((x 1))xを無視するなら、評価結果は5になります。このように、ラムダ式をデータとして表現したときに発生する、自由変数の補足(環境)の曖昧さの問題を、funarg問題と呼びます。

functionスペシャルフォーム

funarg問題を適切に解決するためには、評価時にラムダ式を関数クロージャ(または単にクロージャ)に変換する必要があります。関数クロージャには、関数クロージャが生成されたときの環境が記録されているため、上記したfunargの問題が発生しません。その変わり、ラムダ式を関数クロージャに変換する特別な構文規則が必要になります。Common Lispでは、functionスペシャルフォームがその役割を持っています。functionスペシャルフォームは、与えられたラムダ式を、現在の環境を閉じこめた関数クロージャに変換します。

上記したfunarg問題の例をfunctionスペシャルフォームを使って書き直してみましょう。

評価結果は5になります。funarg問題はちゃんと解決されているようです。

#'lambdaマクロ

ラムダ式をいちいちfunctionスペシャルフォームで囲わないといけないのは面倒ですよね。そこでもっと簡潔に書くために#'リーダーマクロが導入されました。例えば

に展開されます。

ただ、#'を書くのも面倒ですし、#'を忘れてしまうとエラーになってしまいます。そこでlambdaマクロが導入されました。例えば

に、つまり

に展開されます。仕様書には次のように記載されています。

最初のlambdalambdaマクロを持つフォームであって、ラムダ式ではないことに気をつけてください。後ろの二つはどちらもラムダ式です。

実際の歴史が上記したストーリーを経ているかは、僕は確たる証拠を持っていません。Webで見つけた情報を適当に編纂しただけですので、間違いがあったら教えてください。

#'(lambda (...) ...)

ところで、仕様書にlambdaマクロが含まれているのにも関わらず、多くのライブラリのソースコードで

と記述されているのを目にします。本質的には、この#'は必要ないはずなのですが。

噂では、lambdaマクロを持っていない古い処理系に対応するためらしいですが、それならlambdaマクロを別途定義しちゃえばいいじゃん、と思ってしまいます。また、ポール・グレアムは上記の記法を推奨しているという話も耳にはさみました。ソースが分からないので、その理由はまだ確認していません。とにかく、僕には今のところ、この#'を書くべき理由が見つかりません。

シンボルに#'をつけるべきか

Common Lispのややこしいところは、#'を付けなくてもfuncallできたりするところです。

どちらも3を返しますが、この両者に確たる違いはあるのでしょうか。実はこの二つでは、シンボルの関数セルから関数を取り出すタイミングが異なります。'+のほうはfuncall+から関数を取り出しますが、#'+のほうはfunctionスペシャルフォームが+から関数を取り出します。そのため、以下のように高階関数に関数を渡すときは#'を付けるほうが、一般的にルックアップのコストが低くなります。

また、#'を付けておけば構文的にその評価結果が関数であることが分かるので、コンパイラによる最適化が望めます。つまるところ、シンボルを関数として利用する場合は、基本的に#'をつけておくべき、というのが結論になります。

ラムダ式の特別ルール

予備知識として知っておいて欲しいのですが、ラムダフォームと呼ばれる次の形式

は、構文的に次の関数フォームと同じです

つまり、関数フォームの関数部分にラムダ式が指定されている場合のみ、特別にfuncallが補われるということになります。これはマクロを書くときに重宝するので是非覚えておいてください。

まとめ

今回はCommon Lispのlambdaにまつわる話題を提供しました。記事では触れられていない話題もあると思いますので、もし詳しい方がいらっしゃればコメントで教えていただければ幸いです。なおこの記事は、同僚の深町さんと一緒に、一週間ごとに交代で書くことになったCommon Lispシリーズの記念すべき初エントリーです。深町さんは文筆家なので、僕などボコボコにされるのがオチだと思いますが、楽しみにしていただければと思います。


関連文書:

Posted by & filed under いろいろ.


あまり知られていませんが、アリエルは2012年向け新卒採用活動をしています。嘘をつく意味もないので嘘のはずもないですが、証拠のエン・ジャパンのページです。

少し前に開発志望の新卒向け会社説明会を行いました。その時に使ったプレゼン資料を公開します。今後、何度か説明会を行い、その度に少しずつ改訂しますが、骨子はそんなに変わりません。

アリエルはこんなに素晴らしい会社だと力説はしていません。慎み深い日本人だから、これもひとつの理由ですが、そもそもアリエルが良い会社かどうかは人によるだろうと思うからです。合う人もいれば合わない人もいます。説明会の話を聞いてアリエルが自分に合いそうだと思えば採用に応募してくれればいいですし、そう思わなければ無理に応募する必要はないと思います。この原則は新卒も中途も同じです。

言葉にすると、来たい人だけ来ればいいと高飛車な印象になるのが微妙ですが。

説明の後半、アリエル固有の話より、ソフトウェア開発を仕事にすることの話をしました。ソフトウェア開発を仕事にすることの適性があるかどうかの方が、この業界でどの会社に入るかよりも重要だと思うからです。適性があれば、万が一、最初に入社した会社がブラックでも辞めて他の会社に転職すればいいだけです。今ならインターネットや勉強会で会社の情報を得たり、中の人と直接会う機会を得られます。いつか自分に合う会社にたどりつけるはずです。一方、ソフトウェア開発を仕事にする適性がなかったら、どんな会社に入っても苦しむだけです。客観的には恵まれた会社であっても辞めることになり、どんどん条件の悪い会社に移り転々とすることになります。

ソフトウェア開発を仕事にすることの適性についての自分の意見をひとことで言うと、無理は続かない、です。

面接でプログラミングを頑張ります、と言われてしまうと、頑張らなくてもいい、というのがこちらの反応です。誤解される可能性が高いので面と向かっては言いませんが、世の中のほとんどの人にとってプログラミングという行為は人生をかけて頑張るほどの価値はない、と思っているからです(人生をかけるだけの価値をプログラミングに感じられる人はそれだけで幸せなので、その幸運を逃さないようにしてください)。

コードを書いたりコードを読んだり、あるいはソフトウェアをいじるのを、本を読んだり映画を観るように楽しめないと、結局、ソフトウェア開発を仕事にしていくのは苦しいと思います。

これを聞いて、プログラマの世界は才能で決まる世界で、努力を軽視していると思われたならそれは誤解です。

ぼくはプログラミングに特別な天賦の才が必要とは思っていません。自分の職業をそう思わないと自我を維持できないほど若くもありません。また、あまり認めたくない事実ですが、はっきり言って、この業界は世代のエリートがこぞって目指すほどの業界でもありません(少なくとも現時点の日本では)。一部には天賦の才のあるプログラマもいますが極少数です。大多数のプログラマは普通の人です。だから少し努力すれば業界で平均以上のスキルの人材になれると思います。でも、やはり無理な頑張りは続きません。まわりが全員頑張る人ならそういうものかと思えるかもしれませんが、現実は、遊びと仕事の境界がないかのようにプログラミングをしている人がまわりにいます。そんな中で頑張り続けるのは、何か人類にとって素晴らしい価値のある仕事をしているか、あるいはそう思い込みでもしない限り続きません。

好きでないと続かないと思っていますが、一方で、プログラミングが大好きです、と興奮気味に語る人もあまり信用していません。嘘をついているという意味ではなく、ある種の熱狂状態は長く続かないと思っているからです。

熱狂的にプログラミングにはまる時期は誰にでもあります。そういう時期は貴重です。ただソフトウェア開発を仕事にした時、何十年も熱狂状態は続きません。熱狂状態を過ぎた後に残る、醒めた距離感の方を信用します。プログラミングが好きですかと質問されて、元気よく「はい」と答えて熱くその理由を語る人よりも、好きですかと聞かれて「たぶん」や「まあ」と答えるぐらいの軽さを信用します。無理せずだらだらやる、そしてそれが苦にならない、ぐらいがちょうど良いと思っています。

頑張りを否定してばかりいますが、唯一ありだと思っているのは、頑張る自分に陶酔できるタイプの人です。このタイプは貴重な人材です。いたら是非会いたいので、興味があればアリエルに応募してください。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under いろいろ.


WordPressのテンプレートをせっせとカスタマイズしていたのに、何者かによって、変更がすべて消えてしまいました。文字の大きさが無意味に小さかったり、ヘッダーが無意味にでかかったり、角はとがっているし、サイドバーのリストは「・」マークが付いているし、preタグは横幅がノビノビでかっこわるくて、最悪です。phpは怖いです。システムをよく分かっていない人が、変に触ると危険です。まあ、バックアップとっていなかった僕がわるいのです。

でも、セキュリティフィックスすらあてないで、テンプレートをデフォルトに戻すって・・・。

もう、デザインを変更しても消されてしまうかもしれないので、僕はこのサイトのデザインをいじりません。

追記

やっぱり復活した。Chrome偉い。


関連文書:

Posted by & filed under いろいろ.


「アリエルのネットワークに侵入される恐れがあります」

本人の名誉のためにMさんとしますが、Mさんからこんな報告がありました。いつも言うことが大げさなので話半分で話を聞きます。

「どういうことですか?」
「iPhoneをなくしました」

なるほど、少しは深刻な事態かもしれません。

「なくしたiPhoneの番号に電話してみればどうですか」
「誰も出ません」
「利用停止できないのですか」
「しました」
「なら大丈夫でしょう」
「停止するまで10時間ぐらいありました。それだけの時間があれば何でもできます」

拾った誰のものとも分からないiPhoneを使って10時間で何でもできるのはあなたぐらいだと思いながら、厭味を込めて聞きます。

「iPhoneにパスワードをかけていなかったんですか」
「かけていますが…」

なんだかけていたのか、ますます大丈夫じゃないかと思っていたら、

「4桁なので簡単に破れます」

4桁のパスワードをないに等しいと言えるのはMさんぐらいであって、普通の人は違います。とは言え、数回試して当たる可能性は否定できません。なので、一応聞いてみました。

「パスワードが破られたとして、それからどうやってアリエルのネットワークに侵入できるのですか?」

そこからMさんの解説が始まりました。途中から訳がわからなくなるほど、複雑な手順と偶然と高度な推論が必要な作業です。一例を挙げると、Mさんの過去のメールの2007年だか2008年の1通のメールが侵入のためのひとつのキーになります。Mさんは大量にメールを受ける人です。少なく見積もって1日100通です。何年分のメールがあるか知りませんが、5年あれば15万通から20万通ぐらいのメールです。この中から、そもそもそんなメールが存在することを知らない第三者がどうやってそのメールにたどり着くと言うのでしょう。Mさんは本気で心配しているのでしょうか。嘘みたいですが、Mさんは常に本気です。

「サーバに怪しいログがないかをすべて確認しました」

どうせ止めてもMさんはやるのです。これでMさんの気が済むなら安いものです。

「それから…」

まだ続くようです。

「なくしたiPhoneのMACアドレスを社内ネットワークで検知したら通知が来るように設定しました」

嘘みたいですが、Mさんは常に本気です。

「それから、社内のパスワードをすべて変更しようかと思うのですが…」

これは全力で止めました。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under .


献本された本の悪口を書けるほど大物ではないので、原則、献本されてしまうと悪いことは書けません。おまけに出版社から接待も受けました。ますます悪いことは書けません。

昔、企業から金をもらいながら、あたかも第三者のふりをしてブログ記事を書く人が非難されていました。ぼくは利益供与を明かした上で書評を書きます。

立て続けに4冊もらいましたが読んでいる時間がありません。一冊だけ読んだので、読んだ本以外は目次と中身チラ見の感想です。


実践 F# 関数型プログラミング入門

まだ読んでいませんが、ぱらぱら見た感じで用語の使い方の雰囲気に本物感があります。いずれ読みます。

F#はもっとうまくマーケティングすればいいのにと思います。OCamlを前面に出すマーケティングとか。ビル・ゲイツがいなくなった後のマイクロソフトは本当にアピール下手になった気がします。


Javaルールブック ~読みやすく効率的なコードの原則

目次をざっと見ました。たくさんのルールが並んでいます。半分以上、ルールの理由を即答できないようなら買う価値があると思います。このページ数でこの量のルールがあると、流石に個々の説明はあまり詳しくありません。細かい根拠などを知りたい場合は「パーフェクトJava」で勉強してください。


パーフェクトJava (PERFECT SERIES) (PERFECT SERIES 2)


JavaScript本格入門 ~モダンスタイルによる基礎からAjax・jQueryまで

入門本です。JavaScriptを入門から始めなさいというお告げのようです。


プロセッサを支える技術  --果てしなくスピードを追求する世界 (WEB+DB PRESS plus)

献本4冊のうち、唯一、既に読んだ本です。

本の中でこんな箇所があります。

doubleが8バイトの時、配列aとbのサイズは16Kバイトです。CPUのキャッシュラインのサイズが16Kバイトの時、forループ内でキャッシュラインを奪い合うスラッシングが起きると言います。それを防ぐために次のようにダミー変数を書く技法です。

この手の話を聞いたことがないと言うと嘘になりますが、コンパイラが最適化でダミー変数を消しそうな気がして、今や都市伝説に近いのではないかと思っていました。ダミー変数はバッドノウハウですし、(ダミー変数がないコードで)コンパイラに頑張ってもらいたいです。


関連文書:

  • 関連文書は見つからんがな

Posted by & filed under 開発.


昨日はurlgrabberだと言っておきながら、最新版はpycurlに依存しているし、urllibにこだわるほど思い入れもないし、やっぱり、pycurlだぜ、と言うことで。

[続きはこちら]


関連文書:

Posted by & filed under 開発.


別にurllib2じゃなくてもよかったんです。Pythonでkeep-aliveでhttpクライアントさえ動いてくれれば、何でもいいのです。pythonでkeep-aliveでhttpクライアントをちょめちょめしたいとgoogleに聞くと、最近はやりのSではじまるサイトをお告げで示してくれました。Pythonでurllib2でkeep-aliveを使うには、urlgrabber使いなよ、と言っています。仕方なく、この人と心中することにしました。後でもうちょっと読むと、pycurlと言う人もいます。urlgrabberはpure pythonなので、pureな自分に最適なんだと言い聞かせています。

[続きはこちら]


関連文書:

Posted by & filed under いろいろ.


今日、(たぶん)はじめてQuoraをGoogleの検索結果で見ました。Google Megastoreで検索したら検索結果の8番目にQuoraの文書が現れました。これがどれほどの邂逅かは知りません。随分前から普通に検索結果に出ていて、何を今更、という話かもしれません。気にせずに書きます。

ちなみにまだ読んでいませんがMegastoreの論文は以下にあるので興味がある人はどうぞ。難しそうです。

Google Megastoreの論文

今回検索結果に引っかかったQuoraの回答はそれほどでもありませんでした。現状、技術的な回答はSで始まるサイトの方が質が高そうです。この質問に本人降臨でもしていたら、Quora凄い、と感動するのですが残念です。

普段、技術用語で検索することが多い人は、ある時から検索結果にSで始まるサイトが大量に出没する現象に出くわしていると思います。Sの前はWで始まるサイトがそんな位置づけでした。Quoraがこれに続いて、大量出没サイトになるのでしょうか。

quora.jpのドメインはきっちり抑えてありました。Sで始まるサイトは.jp無視のようです。


関連文書:

  • 関連文書は見つからんがな