Web標準化の関係者たちが語る、Web標準化の現実と前進のための処方箋(後編)。Publickey×Web標準化の関係者たちが語る、Web標準化の現実と前進のための処方箋(後編)。20132013年12月9日ふだん私たちが接しているWeb技術は、W3CやIETFといった国際的な標準化団体でさまざまな議論が行われた上で決定された仕様に基づいています。その標準化団体とはどういうもので、標準化作業に伴う苦労はどのようなものなのか。2013」で行われました。Web技術の標準化に貢献したい、と思ったときに、どんな方法があるのか。それから、標準化に貢献するとこんないいことがあるよ、ということをこの会場にいる人を説得するとしたらどう説明できるでしょうか。スペックを書くことや実装をすることはコントリビュートだと思いますが、ここにいるほとんどの方の開発者目線でいうと、その仕様自体にリクワイヤメントがあるというのを示すのも僕はコントリビュートなんじゃないかなと思います。新しめのAPIが出たときにデモやサンプルを作るとか、「これは面白いな」と思ってブログで紹介するとか。それによってその仕様に対する要望や、実際にこう使うといったことやここが問題だと書くことが、コントリビュートでありフィードバックだと思います。考えると、コントリュビュートしたことのある人は(この会場にも)結構いるのではないかと思います。仕様にささいなエラー、タイポでもいいですし、アルゴリズムを読んでちょっとこれはおかしいのではと思うところをつついたり、例えばHTMLにRubyという(ルビを振るための)要素がありますが、その例を見たときに日本語がおかしいとか、それをレンダリングしたときにあんまりよくないと思ったら指摘するとか。そこに明るくないエディターもいるので感謝されたりします。バグをファイルして採用されると、仕様のAcknowledgements(謝辞)に載りますよね。僕もHTML5仕様のAcknowledgementsに乗ってるんですけど、それはタイポを指摘しただけです。新しいAPIを紹介するブログやデモサイトを作るのは、スペックを書いている人にはめちゃめちゃありがたいことで、そういうのがあると、実はスペックを書いていて自分でもよく分からないところがあったりするので、実際に使ってもらうと、ああ間違ってたんだなとか、こういう使い方があるんだなと分かる。デモサイトは言語を越えてシェアされることがあるので、あっという間に広がってエディターの耳にも入ります。Webで「おかしいな」と思うことがあったら自分たちでよくすることに携われるので、ぜひやってほしいです。ネイティブは当たり前のことって理由を知らないんですよね。「すごく使われてるよ、当たり前だよ」と、それで納得してもらえることもありますが、理由を掘り下げてちゃんと説明しなければいけないこともあります。英語圏でも(仕様に対して)1000のリクエストがきて、そのうち30を採用しようとか、どこかで足きりをしているんです。日本語でこれが使われている(から仕様で採用してよ)というのも、それは足きりの上にあるのかどうかを説明しないといけない。英語圏のこれに該当するんだとか、相手が重要度を判断できるようにしてあげるのが大事だと思います。仕様策定のスピード感についての質問も来ています。スピードが遅いというのは実はあまり感じていないですね。いうのも、レコメンデーション(勧告)になるのは遅くても、使えるようになるのはそんなに遅くないんです。AjaxのXMLHttpRequstって、あれまだレコメンデーションになってませんからね。レコメンデーションになるのが重要だとは思ってなくて、むしろちゃんと使われるようになることの方が重要で、そういう意味ではラストコール前のレベルになるのが開発者目線では重要だと思います。スピードに関してはテストが非常に大事だと思っていて、いま縦書きがWebKitとIE11で実装されていて、W3Cには縦書きのテストが2つくらい、WebKitに10個くらい。縦書きという仕様に対してテストがこれしかないんです。ブラウザの開発者がコードを書いていても、これで正しいのかどうかテストできないし。さきほどラストコールまで行ってくれれば、という話がありましたが、W3Cのレコメンデーションになるには、テストがあって、2つ以上の実装が全部のテストをパスすることという条件があります。ラストコール状態では、普及した後でIEとWebKitで動きが違うよ、ということになるリスクを抱えているわけです。そのリスクがなくなるまでW3Cはレコメンデーションにしない、というルールを定めているので、みなさんがテストに貢献する、あるいは仕様の問題にフィードバックするだけで、スピードをあげることができると思います。NTTコミュニケーションズの宮川と申します。僕は今日最後のセッションでIP屋さんとWeb屋さんの話というセッションをもたせていただくのですが、ちょうど2年後の2015年11月に、IETFの会議が横浜にやってきます。村井先生が宣言をしていてIETFのアジェンダリストにも載ってるんですね。それに合わせて、W3Cも慶應大学がホストしていることもあって、TPAC(W3Cの会議。Committee)をその前の週に誘致しようと。これは最近、Webの世界とIPの世界をいろいろマッシュアップしないと行けないことが見えてきました。聞きたいのは2年後にWebとIPの世界が日本で盛り上がっているところを世界に見せたいと思っていて、それについてどう思うか。それからこういう活動はどうしても英語の壁みたいなのがあるので、それをみなさんどうやって解決しているのかについて。2つお伺いしたいと思います。実はこの人は僕の上司なんですが(笑)。英語を乗り越えるのは勇気を出すしかないと思います。下手な英語でもどんどん発言していくしかないと思います。みんな優しいので、こんな英語でごめんねと思っても、丁寧に聞いてくれるし話もしてくれるし。そこで経験を積むしかないかなと思います。WebとIPを盛り上げるのは、ぜひコミュニティのイベントを大きくやっていきたいですね。英語の問題はがんばれば乗り越えられると思います(笑)。スペッックで使う英語はだいたい決まり切っているので、「こうあるべき」と思ったら「must」って書けばいいし(笑)。そんな感じで乗り越えられると思います。英語を読むのは単語力だと思います。仕様で使われる単語は少ないですし、半分くらいはカタカナで聞いてると思いますし、ちょっと辞書でよく使われる単語を調べればすぐ読めるようになるのではないかと思います。私は英語で仕事をするのは困りませんが、雑談になると単語がまったく分からないのでほぼ英語が分からなくなります。英語をしゃべるほうは気合いですね。外国人がきて片言の日本語を話しても意味は分かりますよね、それと一緒で、だいたい単語さえ並べれば通じます。困るのは日本人が3人いてとなりの人の英語が分からないということはありますけど(笑)。相手は分かってくれるので、全然問題ないです。私は海外に住んでいたことはありますのでそのアドバンテージはありますが、自分がなにを考えているのかを説明するのに、僕は日本語でも英語でも不自由さを感じているので、自分が思っていることをを伝えるのは難しいことで、それができるのであれば、言語はそれほど関係ないのではないかと思います。盛り上げることに関しては、僕は得意ではないのですが、日本も海外も関係なく盛り上がればいいなと思います。時間となってしまいました。標準活動に参加したいと思う人!(会場から手が上がる)。ありがとうございます。スペックを書いている人にとっては、日本語でも構わないのでそれについて反応してくれるだけでも貢献になります。いうところからでも参加してみてください。ありがとうございました。W3CPublickey広告.NET帳票ツール。デザイナはExcel。クラウド/サーバー環境対応。.NET5/6/8に対応。デザイナはExcelのため、エンドユーザーも編集可能。ノーコードでCSVファイルから帳票を出力する、CSVReportも新収録。Dataが新サービス発表。≪前の記事Web標準化の関係者たちが語る、標準化の現実と前進のための処方箋(前編)。Niino(jniino)IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。Copilotが複数ファイルにわたるコード変更や生成に対応。CopilotがAppleのXcodeに対応。Xcode」パブリックプレビューOrbがデジタル通貨決済システムの基盤にNewSQLのTiDBを採用。ETLをなくし、トランザクション処理とデータ分析を統合可能に[PR]日本人プログラマ向け、プログラミングに適した「フォント」まとめ。2024年版GitHubで最も使われている言語、PythonがJavaScriptを抜いて1位に。生成AI関連プロジェクト急増で。Sonnetが選択可能に。100」の仮想マシンを正式提供開始JetBrains、JavaScript/TypeScriptのためのIDE「WebStorm」と.NETのためのIDE「Rider」、非商用利用ならば無償で利用可能に。