この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

もずはっく日記(2007年12月)

2007年12月3日

2007年12月4日

Bug 5845 下線がスクロール時に再描画されないことがある 初回投稿日時: 2007年12月04日01時34分29秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2007120400
リンク元: 0件
SNS: (list)

実に長いことかかりましたが修正終了しました。Googleの検索結果で下線が消えていたらこのバグです。

かなり大きなパッチになりました。かなり私にとってはブラックボックスだったGeckoの根幹に関わる部分の一部を理解できたので修正できたことよりもそちらの方が大きい収穫でした。ある意味、rubyの実装に一歩近づいた、という感じです。

CSS3のtext-decorationはこれでかなり簡単に実装できるようになりました。ただし、Gecko1.9での作業・実装予定はありません。今はそれよりもバグの修正の方が重要だからです。

Bug 5966 メニューのキャプションの途中に "..." や "…" が含まれると、アクセスキーが挿入される位置がおかしい 初回投稿日時: 2007年12月04日01時39分07秒
カテゴリ: Mozilla Core バグ報告
固定リンク: id=2007120402
リンク元: 0件
SNS: (list)

この辺のコードをメンテナンスしたことがあるので実は知っていました、このバグ。でも、本来、これらの文字列をメニューの末尾以外で使用してはいけないというデザインのガイドラインがあるので発生することは無いと放置していたのですが、特殊なケースがあったのですね。

簡単に修正できますし、そのコードの位置も上記バグで示していますのでどなたか修正してみませんか?

Bug 5961 contentEditable="true"のあるページでは常にIMEが有効 初回投稿日時: 2007年12月04日01時44分43秒
カテゴリ: Mozilla Core バグ報告 バグ検証中
固定リンク: id=2007120403
リンク元: 0件
SNS: (list)

contentEditableでdiv要素等を編集可能にすると、そのドキュメント全体でIMEが有効になってしまうというバグ。

私の管轄なのでバグっている場所は分かっているのですが、まだ解決策が分かりません。なんとかGecko1.9では修正しておきたいバグです。

2007年12月7日

Bug 5845 下線がスクロール時に再描画されないことがある #2 初回投稿日時: 2007年12月07日18時38分33秒
カテゴリ: Mozilla Core
固定リンク: id=2007120700
リンク元: 0件
SNS: (list)

二つのregressionが出たのでバックアウトされています。

二つのうち、ひとつはパッチがレビューも終わり、使える状態ですが、もう一方はgfxのバグで、パッチはかなり前に出しているんですが、レビューが停滞しています。

2007年12月13日

日本の技術者によるOSSの貢献が少ない理由 初回投稿日時: 2007年12月13日04時59分27秒
カテゴリ: 雑談
固定リンク: id=2007121300
リンク元: 8件
SNS: (list)

OSSは主に英語圏で発達し、イマイチ日本では開発が盛んになりきれていないように思います。以前、US側の関係者に何故日本人からの貢献がこうも少ないのか、と質問されたことがあります。が、Mozillaプロジェクトを見渡すと、和訳等、ドキュメント関係の貢献者はそれなりに数が居て、開発系(とくに実際にパッチを書ける人)が極端に少ないので、おそらく後者のことを指しているのだと思います。

この理由を考えてみると、やはり日本のソフトウェアエンジニアの労働の過酷さにあるのではないかと思います。もちろんここで言うソフトウェアエンジニアとは現場で汗をかく人たちのことで、一般的なニュースに出てくるような金融系でもうけている、いわゆるIT業界で有名な虚業に関わる人たちのことではありません。

私の前職(下請負での開発)からすると、就職前に考えていたよりは過酷ではないものの、十分に重労働な業界だと思います。徹夜はそれほどありませんでしたが、残業がとにかく多く、平日は起きて、仕事、帰ってきて寝るのみ、という感じでした。当時、Bugzilla-jpの活動時間は睡眠時間を削ることで捻出していましたので、テストはできてもパッチなど作る時間は全くない、という状況でした。(もっとも、当時はC++のパッチは書けませんでしたが。)

US側の似たような立場のソフトウェアエンジニアの労働環境は知りませんが、Mozilla関係者を見ていると仕事は仕事時間しかやらないと割り切って、日本人よりも遥に自分の時間を大切にしているように感じます(極端な話、早く帰る人すら見かけます)。もちろん、日本のように企業が労働者を解雇することが困難な社会ではないので、自分の仕事はやっつけているという条件はあると思います。が、日本のIT企業のように残業しないと終わらないようなノルマをMozillaは課していません。乱暴ですが、これが向こうの技術者の一般的なスタイルなのだと仮定するなら明らかに自由な時間の有無が違います。もしくは、いわゆる有名企業のエンジニアのみがこういう待遇なのかもしれませんが、その場合でも日本の有名企業にもそれなりの数の優秀なエンジニアが居るはずで、それらの人がもっと貢献してくれてもおかしくないと思うのです。

このような状況では、本業以外でOSSに関わりたいと考えても自然とやれることは変わってきてしまいます。また、仕事で丸一日コードを書かされていると、OSSのコードまで書きたいとは思わなくなるかも知れません。

私自身、USと日本のIT業界の労働状況についてのちゃんとした知識がある訳ではないので、以上のものは根拠の希薄な推測でしかありません。ですが、大きな理由のひとつではないかと考えています。もし事実なら、日本のソフトウェアのエンジニアは就職後にOSSというとても良い実装例を見て、色々なことを勉強するという機会がUSのエンジニアに比べて非常に少ないことになります。それはとても憂慮すべきことだと思います。なぜなら、Googleの20%ルールにあるように、エンジニアにとって会社から命じられたこと以外の開発作業というのは知識を広げたり、仕事では得られない経験を積むという点で非常に重要なことだからです。日本のソフトウェアエンジニアのうち、一体何%の人が自分の意志でコードを書いたことがあるのか、気になるところです。

Bug 5966 メニューのキャプションの途中に "..." や "…" が含まれると、アクセスキーが挿入される位置がおかしい #2 初回投稿日時: 2007年12月13日17時09分28秒
最終更新日時: 2007年12月13日17時10分26秒
カテゴリ: Bugzilla-org バグ修正
固定リンク: id=2007121302
リンク元: 0件
SNS: (list)

パッチを作成してくれた加藤さんや、コメントを付けてくれた貢献者の皆さんおかげで修正されました。感謝。

2007年12月26日

なかのひとの集計結果 初回投稿日時: 2007年12月26日19時47分37秒
最終更新日時: 2007年12月26日19時53分45秒
カテゴリ: WebStudio
固定リンク: id=2007122600
リンク元: 0件
SNS: (list)

以前導入したなかのひとの集計結果が一通り出揃ったので紹介しておきます。

まず男女比推計は、33:67(女性:男性)と出ました。実際はもっと男性の比率が高いと思いますが、大学とかWebデザイン系の会社からのアクセスが女性比を上げているのかもしれません。

年齢の推計は、20歳から32、3歳ぐらいまでが大半、という結果でした。10代がもっと居て欲しいな、と思いましたが、10代は学校からでもアクセスしない限りはカウントされることが無いでしょうから、少なくて当たり前なのかもしれません。35歳以降はほとんど数に入っていませんが、WWW自体の年齢を考えれば、そんなものでしょうか。

アクセスもとは、細かくは紹介しませんが、多かったのは家電やPCパーツのメーカーさんと、大学や研究機関。意外と少なかったのが、ソフトウェアの開発と思われる会社と、Webデザイン系と思われる会社です。

ちなみに、山形県、高知県、大分県、佐賀県の企業、大学等からは未だにアクセスがありません。

2007年12月30日

Netscapeの終焉 初回投稿日時: 2007年12月30日15時40分12秒
カテゴリ: News 雑談
固定リンク: id=2007123000
リンク元: 5件
SNS: (list)

各地で既報の通り、Netscapeがまた終焉を迎えるという記事が出てます。なんだかんだと言われてもブランドとしての価値は未だにそれなりにあるとは思うので、また変な復活をするのかもしれませんが、元Netscapeファンとしてはもうそっとしておいてあげて欲しいです。

Netscapeが急激に衰退したのは98年ごろです。これには二つの原因があると言われています。ひとつはWindowsへのIEのプリインストールによる強引なシェアの低下。もう一つは、当時の最新バージョンであるNetscape Navigator/Communicator 4.x自体のクオリティが低く、技術的にも負けた、というものです。

ですが、後者の評価は、今考えれば(つまり結果論では)CSSへの対応が酷すぎたことが最大の原因なのは明白なものの、正確な意見ではないと思います。確かに、IEと同等のクオリティがあればシェアを維持できたのかもしれません。しかし、それが可能だったのかどうか。それは次の時系列を見ると難しかったのではないかと思わされます。まさに、待った無しの激動の時代です。

  1. 1996年08月、Internet Explorer 3.0/Netscape Navigator 3.0リリース
  2. 1996年12月、CSS1.0勧告
  3. 1997年01月、HTML3.2勧告
  4. 1997年06月、Netscape Navigator/Communicator 4.0リリース [10ヶ月]
  5. 1997年10月、Internet Explorer 4.0リリース [14ヶ月]
  6. 1997年11月、Windows95 OSR2.5リリース(IE4.01バンドル)
  7. 1997年12月、HTML4.0勧告
  8. 1998年01月、Netscape Navigator/Communicatorの無償化
  9. 1998年02月、Netscape Navigator/Communicatorのオープンソース化
  10. 1998年05月、CSS2.0勧告
  11. 1998年07月、Windows98リリース
  12. 1998年10月、Netscape Communicator 4.5リリース [16ヶ月]
  13. 1999年03月、Internet Explorer 5.0リリース [17ヶ月]
  14. 1999年12月、HTML4.01勧告
  15. 2000年07月、Internet Explorer 5.5リリース [16ヶ月]
  16. 2000年11月、Netscape6リリース [25ヶ月]

Webブラウザ年表によるとこういう歴史になっています。ブラウザ戦争のまっただ中、勝敗を分けたバージョン4.0がリリースされているのは現行仕様のHTML4.01/CSS2(既にCSS2.1の方が主流ですが、実装上、2.0と2.1はあまり違いがありません)が固まったのはこれらのリリースなんです。この年表からすると(実際のユーザのウケは別にして)Netscapeの製品の戦略として4.0までは間違ってはいないのではないかと思います。

しかし、NC4.5へのマイナーバージョンアップに16ヶ月もかかり、更にはNC5が開発中止に追い込まれ、25ヶ月後のNetscape6も満足なデキではなかったという開発の異常な遅れがあります。

一般に4.xのデキが悪いと言われるのは、このような開発の遅れから、「使える」後継バージョンの不在によって、その現役の期間があまりにも長すぎたこと、また、IEは主にWin/Macでしか利用できないため、UNIX系OSのためにNetscape Navigatorが使われ続けたことが原因だと思います。

それに対してこの時期のInternet Explorerの進化は非常に速いことが分かります。Firefoxが有名になってから、そのバージョンアップの速さに愚痴をこぼすWebデザイナの方のコメントを見たことありますが、IE6以降のブラウザの進化が一時的に止まっていた期間の方が特殊な時期だったと考えるべきでしょう。

このような現在よりも遥に激しい開発競争中に大きな資金源を断たれたNetscapeは追い込まれ、更には使い物にならないNetscape6のリリースで、Netscapeブランドに自ら引導を渡してしまったと思います。

それでは、当時、Netscapeが生き残るにはどうすれば良かったのでしょうか?

前述のように、Navigator 4.xのクオリティは当時としては(最高ではないにしても)仕方のないクオリティではないかと思います。ですから、技術的には迅速に5.0を完成させられなかったこと、また、Netscape6のリリースタイミングの見誤りと、その開発の遅れと言って間違いないでしょう。

ですが、資金難等の経済的な理由がそこにあったとすれば、Microsoftのバンドル戦略よりも前から、無償配布でも成り立つビジネスモデルを構築してしまう必要があったことになります。しかし、それを当時の経営陣に注文することはできない、先進的なものだと思います。

こう考えると、Netscapeの衰退は、当時、仕方のないものだったのかもしれません(Microsoftのバンドル戦略が合法だったかどうかに依存しますが)。