«前の日(06-11) 最新 次の日(06-13)» 追記

Matzにっき


2003年06月12日

_ [Linux] mozilla-firebird

今までMozillaを使っていましたが、今日からMozilla Firebirdに置き換えてみました。 たしかにちょっとだけ機敏に動くかな。 どうせメールリーダなどには使ってなかったので機能的にはこれで十分。

数日使って様子を見よう。

_ [OSS] 「オープンソース」の秘密

あ、そうか。別に俺定義を駆逐する必要はないんだ(どうせ無理だから)。 気負い過ぎていたかもしれない。

こういうのはどうだろう。

「オープンソース」でうまくやりたいなら、 オープンソースに隠されている「秘密」を知らないといけないんです。

ってのは。で、「うまくやりたい人」がその「秘密」を聞いてきたら、

うふふ、秘密です。

「オープンソースの定義」その解説を研究したら分かるかも。

と返すのだ。自分で学んで得た知識は役に立つぞ、きっと。

口をあけて教えてもらえるのを待っている人は成功できない、と。 成功したいなら甘えてちゃいけないよね。

やりすぎ? 不親切すぎるかなあ。

じゃあ、「本当に知りたいなら教えてあげます」は?

_ [OSS] エンドユーザへのスタンス

ユーザに対するスタンスですか。 前にも書いたように、 純粋なエンドユーザは「オープンソース」とは直接関係ないんです。

ですから、正直なところ私は純然たる「エンドユーザ」に対して どのようなスタンスを持つべきかということについて 結論を持っていないのです。

ちょっと考えてみよう。

まず「エンドユーザ」という言葉が指すものは「オープンソース」以上に広くて、 人によってとらえ方も違いそうで、そもそも「有意義なスタンス」が存在できるかということさえ疑問だ。

仮に「エンドユーザ」が単なるソフトウェアのユーザであった場合、彼らになにを伝えるべきか。

「ソフトウェアの自由」は現時点での彼らには意味がない。 彼らにとってソースコードはあってもなくても同じだ。 重要なのは「無料かどうか」しかない。 そのような彼らは「オープンソース」だろうが「フリーソフトウェア」だろうが、 無料ソフトウェアとしか捕らえないだろう。

しかし、そういう彼らもある時プログラミングに関心を持ち、 開発者の一員になるかもしれない。だから、彼らに今伝えるべきメッセージは、

「オープンソース」っていう今までにないやり方があって、 そのおかげでこのソフトが無料で手に入るんだよ。

でも、無料ってだけじゃなくて、 そのやり方でプログラムを作ると開発がすっごく「楽しい」んだって

ではないだろうか。ここで「楽しい」の部分は適宜「成功できる」とか良さそうな言葉に置き換えるとして。 要するに、将来に開発者になった時にじゃまにならない程度のメッセージを伝えれば良いということだ。

しかし、上のはかなり方便な説明だな。

  • 「今までにない」はほんとじゃない
  • ここで行ってるのは厳密には「オープンソース」ではなく、「バザール開発」ではないか

いかん。もうちょっとマシな説明を考えていく必要があるな。

_ [会社]新人歓迎会

中途入社の歓迎会。おなか一杯。服が煙草臭い。勘弁してほしい。

_ [OSS]オープンソースとバザール開発

たくさんのコメントありがとうございます。私にとっても刺激になります。

オープンソースはバザール的な要素を含むかということですが、 これは微妙です。というのも

  • 少なくとも「オープンソースの定義」にはバザール開発を含まない
  • その背景も「ソフトウェアの自由」であってバザール開発は含まない
  • 全てのオープンソースソフトウェアの開発がバザール的とは限らない

という事実があり、また一方では

  • 「オープンソース」のポジティブなイメージはバザール開発と不可分
  • 「オープンソース」の楽しさにもバザール開発は不可欠

というも事実だからです。

_ [TV]スペイン語講座

ふと思い立ってNHK教育のスペイン語講座を眺める。 なんか理由は分かるような気がするけど。

...だめだ、やっぱり新しい言語は覚えられない。プログラミング言語ならまだ大丈夫だと思うんだけど。 でも、Haskellとか身についてないよなあ。

_ [OSS]エンドユーザに対するスタンス(その2)

ああ、エンドユーザとひとくちに言ってもレベルがそれぞれという罠。

  1. 単なるユーザ。フィードバックのつもりもない
  2. バグレポートなどフィードバックするつもりはあるユーザ
  3. プログラムの改善に協力する(意見を言うなど)とか、もう少し積極的なユーザ
  4. パッチを作るなど開発にかかわるユーザ(もう開発者か)
  5. 開発者

で、(1)のレベルのユーザについては 前述のような「将来じゃまにならないようなメッセージ」が必要なんだろうなと思うんです。 あ、hsakaさんがおっしゃるようなrespectの気持ちはぜひ持ってほしいなと思います。 XPでもオープンソースでも日常生活でもrespectの気持ちは重要ですよね。

で、Tmbさんの意見である宣伝・広報活動については微妙*1な気持ちを持ってます。純粋に開発だけを考えるとユーザはそんなにたくさん必要ないんですよね。 むしろ、広がりすぎたコミュニティやいろんなタイプのユーザに振り回される危険性まであります。 船頭多くしてってやつですね。だから、開発者としての私は「そんなに要らない」と思ったり。 むやみに(1)から(2)への移行を勧めるのも考えものです。

しかし一方、ビジネスとして成立したり、有効な支援を受けたりするためには知名度や普及度が大いに関係します。 だから、オープンソースエバンジェリスト(自称)としての私は「ぜひ必要」と思ったりするんです。 かなり矛盾してます。まあ、開発者と中間層の立場をひとりで兼ねようとするから起きる矛盾なんですが。

ユーザ数についての暫定的な結論:

  • 開発者はたくさんのユーザを必要としていない
  • 中間層はたくさんのユーザを必要としている
  • たくさんのユーザは中間層を通じて開発者に対する間接的なメリットになる

*1  なんか「微妙」ばかりだけど


2004年06月12日

_ Tシャツプレゼント応募者募集中

まだ応募がそんなに多くないので、当たる確率は高いですね。

「XLじゃ大きすぎっ」という話をちらほら聞くようですが、 確かに大きいです。でも、まあ、私くらいの体格の人でも着れないことはないくらいのサイズですね。 タグにはXL(46-48)って書いてあります。この数字はなんの意味だろう。

あと、「私の負担が...」なんて書いたので心配した方もいらっしゃるようですが、 結局(LL Weekendで直渡しを希望する人以外には)普通郵便で送ることにしました。着払いとか高いし。 その辺は遠慮なくどうぞ。

_ [morg]メールオーガナイザー

なぜだか今ごろになって、5月18日のエントリへのコメントが。

WinFS を先取りするような、ハードディスク・オルガナイザー のほうがメール単体のものより開発の流行では? デジタル家電の コンテンツ検索とかもホットです。

[MMXさん]

いや、分かるんですけど、やっぱ、必要は発明の母というかなんというか。

なぜ今ごろ「メール」オーガナイザーかというと、実は 私はメール以外のローカルファイル検索を今以上に必要としていないんです。

私のマシンにあるファイルのほとんどは、メールを除くと

  • OSのバイナリパッケージに所属するもの
  • オープンソースソフトウェアのソースコード
  • プレゼン資料や原稿
  • メモや電子化した聖書などの雑多なデータ

で、これらはlocateとgrepで十分検索可能なのです。 適切な名前のディレクトリに適当なファイル名でしまっておけば、 絞り込みも簡単ですぐに見つかります。 量的にも質的にも全然困ってない。

ところがメールに関しては、Spamを除いても相当な量で、 しかも構造化の手段がフォルダとか日付とかのような不十分な手段しかないので、 すごく困っているのです。データ量が増えるとクライアントが遅くなるし。

また、メールってのは見つけた後、読んだり書いたりするために適切なインタフェースを要求するので、 専用クライアントの方が良さそうに思います。

Bloomba - http://www.statalabs.com/ Chika Watanabeさんの日記 - http://blog.neoteny.com/chika/archives/006905.html 「メールがやってくると、逐次index化」、「検索結果をViewと呼ばれるカタマリで見せてくれる。」だそうです。

[やまさきさん]

参考にさせていただきます。Bloombaは存在は知っていたのですが、今回初めてデモを見ました。 なんかWorld's Firstとか言ってるけど、そんなに革新的な印象はないですねえ。

で、バックエンドの設計はあらかた終わりました。検索エンジンはQDBMを使うつもりです。

フロントエンドは、自分用に(cmailを改造して)Emacsクライアントを用意するつもりです。 Webクライアントを作るというのも面白いかもしれません。 私自身は文章をブラウザのTextareaで入力する気にはならないので(たとえmozexを使っても)、 Web版は使わないでしょうけどね。

あ、もうひとつ検索に困ってるデータがあった。取り溜めたデジカメの画像。 でもこれをどうやって検索しよう。「娘のピアノ発表会」とかでは絶対検索できなそうだよなあ。

_ Hermes

電車男氏とエルメス嬢のエピソードを女性の視点から記述した小説。「電車男」にはまった経験のある私としては、えらく面白い。性格づけもうまいし、文章も軽妙だ。「電車男」を知らない人が読んだらどう思うのかな。今度、妻に読ませてみよう。

仕事が忙しくなってきたので、第5話はもうしばらくかかりそう」ということだが、続きが楽しみだ*1。今のままの、ふんわりした雰囲気のまま続いてほしいものだ。

あんまり注目されるとプレッシャーだろうから静かに見守っていよう、 なんて、思ってたら「デイリーやじうま」で取り上げられてしまった。今ごろすごいアクセス数になってるんではないかと。Rubyで書かれたというCMS(なのかな?)「ccweb 0.1b (for ruby 1.8)」が元気に動作し続けることを祈るものだ。こんなところでRubyに会うなんて。

ところで、全っ然関係ないですが、スティーブくん(仮名)たちは私の友人の後輩です。 もう時効だとは思いますが、困った牧師さんだ。

*1  今見たら第5話が出てるじゃん。お疲れさま

_ 「禁ずる」

庭に撒く野菜の種を買おうと、種苗コーナーを眺めていると、以下のような文が書いてある種があった。

この種を、再生産、研究・分析のために用いることは禁じられています。

要するに「毎年、種を買え」、「(同業者は)分析するな」という種苗メーカーの望みを表現しているものだとは思うのだが、「しないでください」ではなく、「禁じられています」とはどういうことだろうか。

他人の自由を制限するには根拠が必要ではないか。 この「禁じている」のはなにを根拠に禁じているのか。

特許法? しかし、少なくとも日本ではユーザーは特許に縛られない。 件の種は(特許でユーザーを制限できる)アメリカからのものらしいから、その辺が関連しているかもしれない。 しかし、特許は属地主義だし。

契約? しかし、袋入りの種を買う行為を種苗メーカーとの契約であると考えることができる判例は存在しなさそう。 シュリンクラップ契約? 「この袋を開けることによって以下の条件に同意したこととします」とか。

著作権法? ご冗談でしょう?

ちょうど、共謀罪について読んだところだったので、しばらく考え込んでしまった。

人間の自由は限られた場合にしか制限できない

近代憲法のもとでは、人は生まれながらに基本的人権を享有します。国家権力がある人の自由を制限できるのは、ある人が自由にふるまうことが、他の人の自由と矛盾・抵触するため、それらを調整する必要があるときに限られます。これを刑罰についていうと、国家が刑罰権を発動しうるのは、その人が社会に対して害悪をもたらす行為をした場合に限られる、ということです。

これは2つの内容をもっています。1つは、処罰の対象はあくまで「行為」に限られることです。単にある考えや思いをもっているという、「行為」としてあらわれていない段階では、国家が人を処罰することは許されていません。もう1つは、その「行為」が社会に対して「害悪をもたらす」ことが必要だということです。そうでない限り、人はどのような「行為」をしようとも自由であり、そのことに国家刑罰権が干渉すべきいわれはないのです。

安易に自由を手放してはいけない。安易に人の自由を制限してはいけない。

結局、そういう文言のあるのは避けて違う種を種を買ってきたのだった。 おいしいトウモロコシができるかな。

その後、子供たちとF1(一代交配)について話し合ったのだった。

私: この野菜の種をまいて、花が咲いたらまた種が取れるよね。
子: うん。
私: その種を蒔いても同じように良い野菜はできないんだよ
子: えー、なんで?
私: F1と言ってね。
子: 車のレースでしょ。
私: ちがう、ちがう。(...以下説明略)
子: そんなのずるいじゃん。
私: いや、自然の法則だしねえ。種屋さんに都合がいいのは確かだけど。

この調子では、子供が「知財戦略」を理解できる日は遠そうだ。


2005年06月12日

_ [教会] 松江

もう、毎週松江に出席するのは明らかなんだから、わざわざ松江と書くのも意味ないんだが。

朝、電話がかかってきて、「日曜学校の教師が来れなくなったので代わりに教えて」という依頼が。 まあ、なんとかなるでしょう、きっと。

教会へ。聖餐会の話者の割り当てもあるのだった。テーマは「赦し」。 私はあんまり他の人を赦さなくてもいけない思いになったことはないのだが、 赦してもらわなくてはいけないことはたくさんある。 しかも、そういうことに限って忘れてしまいがちだ。 痛みを与えた方はすぐに忘れても、与えられた方はなかなか忘れられない。 安易な「忘却」によって罪のあるまま「忘れてしまう」ことのないように気を付けたい、 とかいうような話。実際に忘れてそうなことがたくさんあるなあ。

日曜学校は「知恵の言葉」について。もちろん、準備はまったくできなかったわけだが、 参加者が助けてくださったおかげで大変有意義な時間となった。 っていうか、私のやったことってみなさんが自分の考えを述べるのを助ける司会役だけ? ま、そういうものかもしれない。

集会終了後、来週結婚するカップルの「ご結婚おめでとうパーティ」がささやかに開かれる。 5年越しの恋が実ったのだそうだ。 ...そういえば、うちも出会ってから結婚までには5年かかってるなあ。

皆にからかわれつつも、幸せそうであった。 末永くお幸せに。


2006年06月12日

_ [原稿] 原稿の苦しみ

終わらない。やはりソケットであれば、Cの例題を出して、 システムコールについてもざっと解説して、とか思うと悩ましい。 で、久しぶりにCでネットワークプログラミングしたら、はまる、はまる。

struct sockaddr_inのsin_portを設定するときにhtons()を忘れて 30分以上は悩んでしまった。これに比べたらRubyのソケットプログラミングは天国のようだ。 ということが、伝えたかったのだが、ページの関係もあって伝わったかどうか自信が無い。

_ スライド準備

そんなこんなで時間が取られて、深夜になってやっと、 明日の東大の講演のためのスライドを用意しはじめる。

先週の岡山大での講演ではLispがわかるおじさんにはウケたが、 学生の多くはポカーンとしていたような印象があるのだが、 その辺をちょっと反省して、書き直してみる。

でも、東大情報ならそんなこと気にすることはないのかなあ。

_ [Ruby] 「趣味の言語からビジネスの言語へ」---日本初のRuby大規模イベント開催

ITPro、高橋さんによるレポート。

タイトルがすべてを言い表しているような気がする。

で、私にとってはいつまでも趣味だが、 仕事に使う人にとってはそれでは困る、というミスマッチが 生じはじめる頃なのかもしれない。

で、私は1.9で趣味を謳歌し、ビジネスパーソンは1.8で儲けてもらうというのはどうだろうか。


2007年06月12日

_ [Ruby] エンタープライズ

某社の人たちと打ち合わせ。松江までご足労いただいた。

内容は明かせないが、その中で、

「エンタープライズ」って「規模のエンタープライズ」と「複雑さのエンタープライズ」がありますよね。

データ量・アクセス数などが増大する規模のエンタープライズについては ハードウェアの進歩もあってRubyやRailsでサポートできる領域が増えてきているが ロジックやデータ構造の複雑さに関しては、Railsも特に助けてくれない、という話。

具体的にRails(特にActiveRecord)では難しい事例つき。 そうか、こんなことしたいニーズもあるのか。 JavaなORマッパーはこういうのもサポートしてるのかな。

が、80:20則に従った割り切りがRailsの力の源でもあるので さまざまな状況が考えられる「複雑さ」を一概に支援するのも難しい話だ。

今、思ったのだが、「規模のエンタープライズ」と「複雑さのエンタープライズ」以外にも 「重要さのエンタープライズ」ってのもあるな。 大規模でも複雑でもないけど、止まったり誤動作したりすると大きな迷惑がかかるようなの。

_ [Ruby] [ThinkIT] オープンドリーム、RubyおよびRuby on Rails研修を開始

オープンドリームは以前アジア向け技術者研修で講師を出したところ。 あの時は基本的講習内容はうち(NaCl)で準備したのだが、 自前で講習を用意できるようになったらしい。

うちの約半額というのが素晴らしい。 うちも各種割引があるので実質の差はもうちょっと小さいだろうけど。

他にもうちのお客さんで講習を始めたところがあるんだが、 やっぱ、教育って魅力的に見えるのかな。

うちの実績だと(相当高額なのに)講習会単体では なんとか赤字にならない程度で推移しているくらいなのだが。 もっとも、講習会の売り上げ以外でのコネクションや成果もあり、 それはそれで馬鹿にならないのだが。

_ [Ruby] ドリコム、ウェブアプリコンテスト「Drecom Award on Rails」を今年も開催 - CNET Venture View

今年もやります、だそうだ。

昨年とはいくつか違いもあって、

  • Railsオンリー(昨年はRails以外も対象)
  • 合宿を開く

のだそうだ。今年も審査委員を引き受けた。 入賞者には私からの記念品が授与される(昨年は私のサイン入り「Hacking Guide」)。

_ [言語] John Lam on Software: Getting Started with the DLR: ToyScript

IronRubyの中の人、John Lamからのエントリ。 DLR (Dynamic Language Runtime) を使った動的言語実装例。

手元にDLRがないので試してないけど、 .NET+DLRならこんなに簡単、ということなら、 言語実装の楽しみを実感できる人(ホビー言語設計者)が増えるかも。


2013年06月12日 「ちょっと待った!小中学校でのプログラミング教育」

先日、Webronza というところに寄稿したのだが、有料登録しないと後半が読めなくなっていた。で、交渉して公開許可を頂いたので、ここで全文掲載。

「ちょっと待った!小中学校でのプログラミング教育」

現代社会はもはやコンピュータがなければ成り立ちません。そして、コンピュータは誰かが作ってソフトウェアがなければ、まったく役に立ちません。コンピュータは自発的に仕事をしてくれないどころか、誰か人間がソフトウェアという形でどのように仕事をすれば良いのか教えてやらなければ、なんの働きもできないのです。コンピュータが社会に役に立っているのは、ソフトウェアがあるからです。

どんなに賢いように感じられるコンピュータでも、自らソフトウェアを開発することはできません。コンピュータは単純な計算をものすごく速く行うことができますし、それを積み重ねることで人間を越える能力を備えていますが、その一方で、なにか新しいことを創りだすなどの創造的な活動は苦手です。はっきりいうとまったくダメだと言ってもいいでしょう。当面の間は人間がソフトウェアを作って、コンピュータに仕事を教えてやるしかないのです。

社会におけるコンピュータの重要性は明らかで、そのコンピュータがソフトウェアがなければ役に立たず、そのソフトウェアは人間にしか作れないとなれば、ソフトウェアを開発する人間こそが真に重要だということになります。しかし、現状、誰でもがソフトウェアを開発することができない以上、ソフトウェアを開発する人、プログラマを養成することは急務です。とは言うものの、どのような教育を行えば、優秀なプログラマを育成できるのかについて誰でもが合意できる方法はまだ見つかっていないようです。

最近、注目されているのが若い人たち、特に小学生や中学生へのプログラミング教育です。確かに優秀なプログラマは若い頃からその才能を発揮している人が多いようです。また、プログラミング能力はあまり年齢に関係ないようで、天才と呼ばれる小学生プログラマがいると思えば、70歳をはるかに超えて現役で活躍する方もいらっしゃいます。

そこで、若いプログラマを育てるために、小学校や中学校での情報処理の教育やプログラミング教育に力を入れようという動きもあるようです。しかし、自分自身のプログラマとしての経験から考えると、これにはなかなか困難がつきまとうように思えます。第一の課題は「誰が教えるか」という点です。学校をプログラミング教育の現場にするためには、当然のことながらプログラミングを教える教師が必要です。しかし、現在の小学校・中学校の教員でプログラミングの能力を持つ人はごく少数でしょう。もちろん、教科書通りに教えることができる人は短期間で用意できるかもしれませんが、それでは子供たちにプログラミングに前向きな気持ちを伝えることは困難でしょう。中学生時代にプログラミングをはじめた私自身も含めて、若い頃からプログラミングに「はまった」人たちは、結局、コンピュータを使いこなすのが楽しいからこの道に進んだようなもので、教科書に書いてあるから、あるいは学校の授業だからという理由でプログラミングをはじめた人など見たことがありません。プログラミングを教えるというのであれば、少なくとも教える人はプログラミングの楽しさを自覚している人でなければ成果をあげられないと思いますし、そのような人をそれぞれの学校に配備するのは大変な困難ではないかと思います。

第二の課題は「どのように評価するか」ということです。学校の授業であるということは、なんらかの評価をする必要があるわけですが、これがまた困難です。まず、プログラミングの能力は、創造性をともなうという点である種芸術に似ています。そういう点では美術の授業に似ているのですが、問題はプログラミングの場合、人によっては非常に短期間で上達するため、小学生であってもプロを越える作品を完成させることがたびたびあることです。人によって出来栄えが10倍、100倍あるいは1000倍も違うようなものを学校の成績としてどのように評価したらよいのか途方にくれます。

第三の課題は「なにを教えるか」ですが、この点は最初のふたつの課題に比べればなきに等しいものです。

では、学校教育はプログラマ養成にふさわしくないのであれば、いったいどうすれば未来を担うプログラマを養成することができるでしょうか。

正しい答えは私自身も持っていないのですが、私の知っている優秀なプログラマのほとんどが自学自習でプログラミング能力を身につけている現実を考えると、あるいはプログラマとは、養成されるものではなく、発見されるものなのかもしれません。

ある調査によれば、大学におけるプログラミング教育の受講者の内6割程度はプログラミングの基本的な部分の理解に困難を感じ、それは他の学科の成績に必ずしも相関しなかったのだそうです。だとすると、世の中にはプログラミングに向いた性格の人がいて、成績その他では区別することができないことを意味します。であるならば、少しでもたくさんに人にプログラミングに触れる機会を与え、そしてそれに興味を持てた人、才能の片鱗を見せた人にはより豊かな機会を与えるようなプロジェクトを総合的に設計することで、未来のプログラマを「発掘」できるのかもしれません。そして、そのような才能あふれる人たちに適切な待遇を与えることが、このIT社会の競争力を強める最大の方策なのかもしれません。


«前の日(06-11) 最新 次の日(06-13)» 追記