ようこそ。管理人の fcp です。ここは fcp の趣味のウェブサイトです。今のところ内容は、プログラミングとウェブサイト運営に関する文章が多く、科学、法、言葉等に関する文章と、他の人の文章や創作の紹介や感想や評論が少しあります。ときどき意図的あるいは結果的に偽情報が入っているので、いかなる盲信も危険です。このサイトと僕に関して詳しいことは「このサイトと管理人について」をご覧ください。
僕が当サイト以外でおこなった発言のリストを公開しています。「fcp の発言のリスト」をご覧ください。
舌が回らず言葉の発音を間違えることを「噛む」 (「言葉を噛む」「台詞を噛む」とも) と表現する場合があります。僕の勝手な印象ではテレビのバラエティー番組で台詞を言い間違えた人に対して別の出演者が「おいおい、台詞噛むなよ!」と言って笑う、というのが典型的な用法です。この意味の「噛む」は基本的にはお笑いの社会だかテレビの社会だか、一部の社会でだけ通じる業界用語だと思っていたのですが、最近は少なくともウェブでよく見かけます。僕が知らないだけで、じつは普通の表現なのかもしれませんが、よくわからないので僕は一般の文章で使うのを躊躇してしまいます。
関連: 人力検索はてなでは、「噛む」のこの用法は舞台用語に由来すると書かれています。
1 月 16 日、 Google が iGoogle の外観をカスタマイズする機能「iGoogle Themes API」を発表しました。名前の「API」という部分が気になりました。 API とは application programming interface の略であって、下位層である基本ソフトやライブラリーなどを上位層であるアプリケーションから操作する方法の取り決めのことです。 iGoogle Themes API はテーマを記述した XML ファイルの仕様を定めているだけであって、主にアプリケーションから利用されるわけではありません。テーマを記述した XML ファイルをアプリケーションと捉えれば、 API と呼ぶことは妥当かもしれませんが、現時点では色や画像を現在時刻に基づいて変えることができるというだけの機能しかないわけで、これをアプリケーションと呼ぶのは背伸びだと思います。ただ、今後 Google は iGoogle Themes API を拡張していって、アプリケーションと呼ぶに値するものをテーマという形で作れるようにするつもりなのかもしれません。 (なお、今後誰かがテーマを作るためのアプリケーションを書くとして、そのアプリケーションから iGoogle を操作するための API なのだという説明は成り立たないと思います。 iGoogle はそのアプリケーションに部品を提供するわけではなく、下位層と上位層という関係にならないので。)
ただ、 Google には技術的に妥当でない名前を使った「前科」があることを思い出さずにはいられません。検索エンジンの中で「キャッシュ」機能を最初に提供したのは、僕が知る限りでは Google が最初で、後から他の検索エンジンも追随しました。しかし、高木浩光さんは「技術用語『cache』が政治的な言葉として拡大利用される」 (高木浩光@自宅の日記) において、 Google 等の検索エンジンがこの機能を「キャッシュ」と呼ぶのは不誠実ではないかと指摘しました。この機能は一時的なミラーであって、「キャッシュ」と呼ぶのは技術的には正しくなく、正しくない呼び方をしている理由はこの機能が著作権侵害であるとの批判を避けるためではないか、という議論です。僕は高木さんの指摘を読むまで検索エンジンの「キャッシュ」という名称に疑問を持っていませんでしたが、言われてみれば、極端な話、「無断ミラー」と書いてあったら Google を使うのすら躊躇してしまいそうです。呼び方が違うだけで同じサービスが良いことに見えたり悪いことに見えたりするなんて、言葉は怖いものです。
べつに Google が iGoogle Themes API に API という名前を使うことに何か裏があると思うわけではありません。ただ、 Google に限らない一般論として、言葉の正しさを気にしないのが当然という世の中にはしたくないと思います。少なくとも僕は言葉を誠実に使うようにしたいです。
「はてなブックマーク等で勝手に批判するのは良くない」とか「IPv4 なんて見切りを付けて IPv6 に移行するべきだ」とかという意見は、現状ではその意見が通っていないので、否定したくなることがあります。でも、現状と違うことを提案する意見だからというだけの理由で安易に考えを否定するのは慎みたいと思っています。現状維持を主張する人と変化を主張する人の言い争いは、現状維持を主張する人の立場の方が強くて公平でないように感じることが多いです。
まがりなりにも公開できる版を作った文章の一覧です。まだ公開できる版のないもののタイトルと要旨が、書きたいものに並んでいます。
最終更新日の新しいものから順に並んでいます。
let を使うと、クロージャーを作るときにありがちなまどろっこしいコードを簡潔に書くことができます。
確認ダイアログボックスのインフレを防げ (2007 年 1 月 27 日公開) ユーザーインターフェース ソフトウェアstrtoul 関数は入力文字列がマイナスで始まっていてもエラーになりません。例えば "-500" という文字列を渡すと ULONG_MAX-499
が返ってきます。これはライブラリのバグではなく仕様に従った動作のようです。仕様の意図がわかりません。