ラベル 翻訳 の投稿を表示しています。 すべての投稿を表示
ラベル 翻訳 の投稿を表示しています。 すべての投稿を表示

2012年5月8日

GeoJSON の日本語訳

GeoJSON の仕様書 を日本語に翻訳しました。 GeoJSON は JavaScript Object Notation (JSON) を基にした地理空間データ交換フォーマットです。

仕様は2008年6月に発行されており新しいものではありませんが、 適当な日本語がありませんでしたので自分で作成しておきました。

続きを読む »
2 件のコメント: ラベル: , , ,

2011年11月15日

OData のための効率的なフォーマット

OData のブログに気になるエントリがありましたので、 ちょっと日本語に訳しておきます。

続きを読む »
0 件のコメント: ラベル: ,

2011年8月25日

JavaScriptMVC - 概要

JavaScriptMVC は Jupiter が開発/提供している JavaScript フレームワークです。 jQuery を中心に据えて、クライアントサイドの開発を助けてくれます。 JavaScriptMVC のメリットはこの辺でも触れています。

使い方をまとめて記事にしようとしたら大変だったので、 ５回に分けて書く予定にします。

  1. 概要 (この記事)
  2. プロジェクトの作成
  3. テストと実装
  4. ドキュメンテーション
  5. パッケージング

Update: 一連の記事を書き終えたのでリンクにした。

続きを読む »
0 件のコメント: ラベル: , ,

2011年4月23日

Twisted 入門の日本語訳

Twisted Introduction というブログの連載を日本語に翻訳しました。

http://skitazaki.appspot.com/translation/twisted-intro-ja/index.html
続きを読む »
0 件のコメント: ラベル: , ,

2011年1月13日

JavaScriptMVC と一覧表示の性能

JavaScriptMVC and List Performance (jupiterjs.com) の日本語訳です。 よくある話ですが「一覧表示のパフォーマンスに気をつける」ことについて適度な粒度でまとまっていましたので、メモがてら日本語にしておきます。

続きを読む »
0 件のコメント: ラベル: , ,

2010年12月27日

Wave の保存をファイルシステムへ

Google Groups における投稿 で、 Wave の保存先を MongoDB からファイルに変更した経緯のメモ。

質問:

By the way, why the current persistence approach is File system based and not say DB based? Is it easier? I am just curious.
日本語:
ところで、今の方法ではなんでファイルシステムにデータを保存するようにしてるんだっけ？ たとえばデータベースとかではなく。 ファイルシステムに置いた方が簡単だから？ 単に興味本位で気になっただけなんだけどさ。

日本語訳

コミュニティの情熱に影響されて、最初は MongoDB で実装してみた。 もう少し詳しく調査してみたら、サーバ単体での構成には MongoDB は不向きだと分かった。 サーバ単体構成は、Wave in a Box での基本的な場合となる。 Mongo では適切な永続性 (durability) を保証できない。

ファイルシステムに保存することは、概念的にも非常にシンプル (追記のみ) で、 wave を保存するには要件にピッタリなので、純粋なファイルシステムでの実装にすると決めた。 このための抽象レイヤーはない。 シンプルな wave/account/certificate のためだけであることに注意して欲しい。 来るべきインデクス (訳注:検索で使う) のような、もっと複雑な構造をディスク上に直接保存するような実装には有用ではないと思っている。

その他

詳しい仕様は Wave store design for Wave in a Box を参照。

将来的な検索の仕様は Search wave design proposal が詳しい。

0 件のコメント: ラベル: , ,

2010年12月26日

Google Buzz で使われているドラフト標準

James Clark の A tour of the open standards used by Google Buzz (2010-02-12, James Clark's Random Thoughts) の日本語訳です。 XRD, WebFinger 辺りの概略が分かりそうだったので日本語にしました。

日本語訳

Google Buzz について最も魅力的だと思ったのが、彼らが オープンな標準に準拠する と宣言したことです。

ソーシャル Web は従来の Web (シンプルでオープンな標準によってつながっている多くのサイト) のように機能すると一番うまくいく、と私たちは信じています。

ということで、関係する標準技術をひと巡りする時間をちょっととりました。 ここでは、私にとって目新しいものに焦点を当てるようにします。

Google Buzz における設計上の重要な決定のひとつは、ソーシャル Web における個人は E メールアドレス (もしくは少なくとも似たような文字列) によって識別されるべきだ、ということです。 どちらかと言うと、私はこれに賛成です。 純粋な Web アーキテクチャという観点からは URI を使う方が望ましいかもしれませんが、ユーザーインターフェイスの観点からは E メールアドレスの方がはるかにうまくいくと考えています。

このため、Google Buzz はディスカバリの問題に対処するいくつかの標準を持ちます。 ディスカバリの問題とは、E メールアドレスのように見えるものとメタデータをどのようにして関係付けるか、ということです。 次のふたつがキーとなる標準です。

XRD:XRD は OASIS XRI TC によって作られたシンプルな XML フォーマットです。 汎用的な方法でリソースに関するメタデータを表現するためのものです。 とても妥当な感じで、不正な XRI とは関係ないのは嬉しいですね。 RDDL にとても似ています。
WebFinger:WebFinger は E メールアドレスから XRD ファイルを取得する仕組みを提供します。 HTTP に基づくふたつのステップから成ります。 まず始めに、E メールアドレスのドメイン部分を使って構築された、よく知られた URI から XRD ファイルを HTTP で取得します (よく知られた URL は "the Defining Well-Known URIs" と "host-meta" というインターネット標準に準拠します)。 このドメイン単位の XRD ファイルはいくつかの機能を提供してくれますが、とりわけ強調したいのは、 そのドメインにおける E メールアドレスのための URI 構築方法を教えてくれる URI テンプレートを提供してくれることです。 この URI が違うことにより、ある E メールアドレスに関連するメタデータの XRD 表現が分かります。 JSON シリアライゼーションに関することが雑音に感じられるかもしれませんが、これは意味があります。JSON はこの問題にとてもうまく合いそうなのです。

ディスカバリーメカニズムなどと組み合わせられるたくさんの興味深いことのひとつとして、公開鍵と個人を関連付けることがあります。 これを定義する Magic Signatures という仕様があります。 Magic Signatures は全ての普通の X.509 製品 を正しく避けてくれます。 ここでは完全に必要ないことです。簡単な RSA 公開鍵さえあれば良いのです。 ひとつの粗探しになってしまいますが、すでに完璧に良い標準フォーマットがあるにも関わらず、公開鍵のために独自フォーマットを発明していることが気になります。 たとえば OpenSSL で使われているように、RSAPublicKey ASN.1 構造 (RFC 3477/PKCS#1 で定義されています) の DER エンコーディングのことです。

WebFinger は XRD ファイルを安全な方法で取得する必要があり、このことは、SSL を使うか XML-DSig を使って XRD ファイルに署名するかを意味します。 これを安全な状態にするためには気をつけましょう。 どちらの方法でも、既存の X.509 基盤を活用します。 ここでキーとなるアーキテクチャ上の決定は、ドメインレベルで証明書を発行するために X.509 基盤を使うことです。 そしてドメインから個人まで信頼の連鎖 (chain of trust) を拡げるために Web の技術を使います。 配備の観点からは、私は Gmail や Facebook がやっているように、あるドメインに大勢のユーザーがいるような場所ではうまくいくと考えています。 課題となるのは、あなたのドメイン用に Google Apps などでもうまく動かすことです。 そこではドメイン当たりのユーザー数はわずかです。 今のところ Google Apps はドメイン管理者にいくつかの DNS レコードの設定だけを要求します。 DNS が安全ではないことが問題なのです (少なくとも DNSSEC が広く普及するまでは)。 とはいえ、ひとつの解決方法があります。 ユーザーのドメイン (たとえば jclark.com) はプロバイダーのドメイン (たとえば foo.google.com) におけるホストを示す SRV レコードを持つでしょう。 XRD は HTTP を使って取得されますが、ユーザーのドメインのために XML-DSig と X.509 証明書を使って署名されています。 WebFinger のサービスプロバイダー (たとえば Google) は、おそらく WebFinger への利用を制限するフラグを持たせるなどして、 これらの証明書を発行することに気をつけてくれるでしょう (Google はすでに Google Apps の設定作業の一部としてドメイン制御を検証しています)。 ここでの信頼されたルートはブラウザーベンダーが決めた HTTPS のルートとは違うかもしれません。

Magic Signatures のもうひとつの部分は、XML-DSig より簡単で JSON でも動作するような代替方法だと宣伝されています。 ここでのキーアイデアは、XML における情報のアイテムにまで署名するというコンセプト全体を避けて、それゆえに正規化の必要性を避けることです。 その代わり、バイト列に署名します。このバイト列は XML 要素の中身 (もしくは JSON 文字列) として base64 でエンコードされます。 私は、コンテンツを base64 でエンコードしたものがいつも署名されているようにする、という考えには賛成していません。 テキスト形式の利点の多くを必要もなく投げ捨てているかにみえるからです。 そうではなく、署名したバイト列が Unicode 文字列を表しているなら、XML や JSON の組み込みクォート機構 (XML なら文字参照や CDATA セクション) を使って、 XML 要素の中身または JSON 文字列として Unicode 文字列を直接表現できるのです。 XML や JSON を解析した結果のユニコード文字列は、標準の署名アルゴリズムが適用される前に UTF-8 でエンコードされるでしょう。 Magic Signatures を使う上でもっと根本的な問題は、XML-DSig の重要な特性 (中でも enveloped 署名) を損なってしまうことです。 重要な特性とは、単に署名を無視することによって、署名について知らないか気をつけないアプリケーションでも署名されたデータを理解できることです。 私も、XML-DSig の複雑さを避けたい、という点については全くもって同意します。しかし、Magic Signatures がそのための正しい方法だとは納得していません。 XRD は XML-DSig に依存していることに注意しましょう。 とはいえ、XML-DSig の非常に限定的なプロファイルしか指定していませんので、XML-DSig を処理する複雑さを劇的に小さくしてくれます。 JSON が。(訳注：原文は For JSON, I think i となっている。何かの間違いか慣用表現？)

Atom を拡張する標準もあります。 もっとも簡単なものは、content を拡張することです。

Atom Activity Extensions:
Atom Activity Extensions はソーシャルネットワーク上の活動 (何かにリンクしたことや何かを投稿したことなどです) のための意味的なマークアップを提供します。 これは分かりやすくて良いですね。
Media RSS Module:
Media RSS Module はマルチメディアコンテンツを扱う拡張を提供します。 元々は Yahoo によって RSS のために設計されました。 マルチメディア (content/@src, link) のための既存の Atom/AtomPub の機構とこれらがどうやって共存するのかをまだ理解していません。

プロトコルを拡張したものもあります。

PubSubHubbub:PubSubHubbub は Atom フィードからほぼリアルタイムに更新を取得するスケーラブルな方法を提供します。 Atom フィードは "hub" へのリンクを含むようにします。 アグリゲータは、フィードが更新されたときに通知してもらうように、hub に登録できます。 パブリッシャーがフィードを更新すると、hub に通知 (ping) し、hub は自分に登録されている全てのアグリゲータを更新します。 hub がアグリゲータに知らせるためには HTTP POST を使いますので、サーバベースのアグリゲータを意図しています。
Salmon:Salmon はフィードアグリゲーションを双方向にします。 ユーザ A はソーシャルネットワーキングサイト X だけを使っていて、ユーザ B はソーシャルネットワーキングサイト Y だけを使っていると仮定してください。 ユーザ A がユーザ B とつながりたい場合、典型的には A が Y に参加するか B が X に参加しなければなりません。 この方法は、世の中がひとつの支配的なソーシャルネットワーク (Facebook など) を持つ方向に進めます。 長期的に考えるとこれが良いことだとは思えません。 Salmon 拡張はこの問題の一部を解決します。 X は A のために Atom フィードにリンクするプロフィールを外からも見えるようにでき、Y は A に関する情報を B に提供するためにそれを使えます。 しかし問題があります。 B が A のエントリーのひとつにコメントしたいとしたらどうでしょう。 B のコメントを X に戻し、それを A が見えるようにすることを Y はどうやって保証できるでしょうか？ もうひとつのソーシャルネットワーキングサイト Z には、A のエントリーに対する B のコメントを見たがっているユーザ C がいるかもしれません。 基本的な考え方は単純です。 X によって外から見えるようになっている A の Atom フィードを、コメントが投稿される URI にリンクするのです。 Salmon の大きな進展は Magic Signatures によって成されます。 Atom エントリーに署名することは、サイトがコメントを受け付けるかどうかを決めるキーとなります。

Google はこれらの標準のいくつかのために Open Web Foundation を使うようにも見えます。 OWF のメンバー一覧には私が知っていて尊敬できる人たちの名前がたくさんありますが、正直なところ OWF の必然性を理解できません。 IETF と非常によく似ています。 IETF には不足だと感じて OWF を形成する動機は何だったのでしょうか？

XML か他の表現か

ということでざっくりと日本語にしてみました。 しかし、ここに出てきたことが絶対に XML でなければならないのか言うと、たぶんそんなことはありません。 個別の設計や組み合わせは XML で定式化した方が良いかもしれません (XML Schema などは嫌われている感じがありますが...) が、 実際に利用する場合は、通信データ量とプログラムでの扱い方などの関係により JSON のような表現形式の方が歓迎されるかもしれませんね。

その関係で... かどうかは分かりませんが、最近では XML と JSON に関して色々あるなーと思うのでした。

あと、URL をユーザの識別として使うことに関してはこの辺りもメモ。

  • URL as UI (Jakob Nielsen's Alertbox, March 21, 1999)
0 件のコメント: ラベル: ,

2010年12月5日

年にひとつは新しいプログラミング言語を

diaspora-dev において、Diaspora を PHP で再実装しないの？ (Diaspora PHP Fork) というスレッドにおける、とある発言です。前後の文脈もありますのでこれだけで完全な意味を成すものでもありませんが、他の言語やプロジェクトにも当てはまることが多々ありそうです。

日本語訳

以前に抱いた残念な感じを思い出さなくてはなりません。 Diaspora に興味はあるけど PHP のコードしか使えないのなら、既存の PHP プロジェクト (例えば appleseed[1] やその他の Federated Social Web プロジェクト) との互換性を確保するべきです。 今の段階で Disapora を移植することは馬鹿げています。 なんと言うか... まぁいいでしょう。 私としても言い争いは聖戦[2] 以上に好ましくありませんが、ちょっと書いておきます。

ここからは批判的な文体になりますよ。無視してくださっても。

ともあれ、Diaspora が私にとってもっとも魅力的なことは、Ruby と JavaScript で記述されていることです。 私個人としては、いくつかの理由によって PHP が悪いコードになりがちであると信じています。 PHP が悪いコーダーを惹きつけるのか、PHP 自体が悲惨な設計の言語だからなのかもしれません。 しかし、何より言いたいのは、プロジェクトに興味があるならそこで使われている言語を学べ、ということです。

プログラマーだったら毎年ひとつは新しい言語を学ぶべきです。 Ruby はここ20年でもっとも魅力的とも言える動的な言語です。 Ruby を学んでそれでも嫌いだったらそれはそれで構いません。他のプロジェクトで頑張ってください。 けれど、新しい言語を学ぶのが面倒だから、という理由だけでプロジェクトをフォーク (他の言語に置き換えるのは forking ではなく porting ですが、ここではもはや何でも良いとしておきましょう) しても、何も前進しません。 みんなの努力が散り散りになってしまい、コードは重複するばかりです。 DRY (Don't Repeat Yourself) の真逆だとお分かりですか？

それだったら自分で PHP のプロジェクトを始めて、Diaspora のフォークを気取るのではなく"ScatteredSeeds" (意味はギリシャ語を) とでもした方が良いのではないでしょうか。 うまくいけばあなたの頑張りを利用するような PHP FSW (Federated Social Web) プロジェクトがありますし、もしくは Diaspora (現実のものです) があなたの努力を取り込むかもしれません。 しかし、同じことを別々に頑張るなんて大人気ないと思いませんか。 40年に渡るソフトウェア開発で得られた知見とは正反対なのです。

馬鹿げた発言を申し訳ありません。 でも、コードを書くのは私の生活の一部ですし、必要もないのに重複する作業を頑張ることほどイライラすることもありません。全てのひとの生活をいつも台無しにしてしまいます。それがうまくいったことなんかちっともありません。一度もです！

読んでくれてありがとう。

原文

I have to echo the sentiments earlier, the thing to do if you're excited about diaspora but only code PHP, is to work on interoperability with an existing PHP project, like http://opensource.appleseedproject.org/ or one of the many other Federated Social Web projects. Forking Diaspora at this early stage is just absurd. I also have to say... OK, the LAST thing I want is to start anything resembling a flame war, much less a Holy War <http://www.ist.rit.edu/~jxs/jargon/html/H/holy-wars.html>.
<semi-flame mode>
But one of the most exciting things about Diaspora for me is the fact that it's all Ruby and javascript. I really believe PHP tends to lead to bad code for some reason. Maybe PHP attracts bad coders, or maybe it's just because PHP is a horribly designed language, but seriously, if you're excited about a project, LEARN THE LANGUAGE. Every programmer should learn a new language a year. Ruby is possibly the most exciting dynamic language to come along in the past 20 years. If you learn Ruby, and hate it, fine. Work on another project. But 'forking' a project (ok, recoding in another lang is NOT forking, it's porting, but whatev's) just because you're to lazy to learn the language it's coded in is NOT how things progress. It's how effort gets divided, code gets duplicated, it's the opposite of DRY. It would make more sense to start your own PHP project and call it 'ScatteredSeeds' (learn Greek) instead of pretending it's a 'fork' of Diaspora. Srsly, there are existing PHP FSW projects that could use your efforts, or Diaspora (the real one) could use your efforts... but duplicating effort is RETARDED. It's the OPPOSITE of everything we've figured out about the right way to develop software over the last four decades.
</semi-flame mode>
I apologize if I come across as a dick, but I write code for a living, and nothing irritates me more than duplication of effort without necessity. It makes life worse for everyone, everytime. Nothing good ever comes of it. EVER. Thanks,
0 件のコメント: ラベル: ,

2010年11月15日

Wave Summit Development Practices

先週は Wave Protocol Summit が開催されたそうです。 いくつかの アナウンス と プレゼンテーション がありました。 Wave のアーキテクチャやプロトコル、リアルタイム向けのエディタに関する説明がスライドおよびビデオで見られます。

その中に開発プロセス一般に適用できそうなスライドがありましたので、ちょっと日本語に訳してみます。 Lennard de Rijk による Development Practices From Idea to Patch です。

開発の進め方 - アイデアを形にするまで

議論すべきは「変えようとする気持ち」です。 これが正しいと言うわけではなく、私たちが実際にやっていることです。

目次

  • 大きな変更の際にはドキュメントを書く
  • Eclipse に取り込む
  • ソースコードのスタイル
  • 不可分で過不足のない、小さな単位のコミット
  • コミットする前にコードレビュー
  • 継続的なビルドおよびテスト
  • 依存関係に取り組む

設計ドキュメント

いつ？:

大きな変更や新機能を考えるとき
なぜ？:
  • コミュニティの他の人たちと何をどうやって進めるか話し合うため
  • 大量のコードを書き上げる前に、方針ついて合意するため
  • 後でドキュメントが古くなってしまうことは気にしない
どうやって？:
  • 対象となること
  • 要求
  • 設計
  • 対案

Eclipse に取り込む

デモビデオ

  • チェックアウト
  • Eclipse で「新規プロジェクト」
  • Eclipse のプロジェクト設定
  • Eclipse で Ant
  • Eclipse で起動
  • Hosted mode?

コーディングスタイル

  • クラスをまたいでも読みやすいように
  • レビューしやすいように
  • パッチがより詳細なものになるように (全てが同じスタイルで記述されているとき)
  • メンテナンスしやすいように
  • Eclipse のフォーマッタがある

小さな量でのコミット

  • それぞれのリビジョンが意味のあるものにする
  • 間違えを分離しやすく
  • レビュアーにやさしく
    • レビュアーがコミットを分割するようにお願いするかもしれません
  • 早いうちに、そして頻繁にコミットする

コードレビュー

  • コードの品質を向上
    • メンテナンスしやすく、変更しやすくする
  • レビュアーはコードの妥当性を確認する
    • 正しい問題を解決しているか
    • 以前に書かれているものでないか
    • 自然な表現であるか
    • そしてある意味で、コーディングスタイルに忠実であるか
  • ソースコードのそれぞれの行が、ふたりの目に触れる
    • コードに内在する知識が共有される
  • http://codereview.waveprotocol.org

継続的なビルドとテスト

  • 最近の破損箇所を分離するため

  • ここで動作

    http://google2.osuosl.org:9090/

  • 壊れている場合はそれ以上コミットしない。修正のみ。

依存性に取り組む

  • オープンソースを扱う。サードパーティのもの。
    • 車輪の再発明をしない
  • WiaB は Apache 2.0 ライセンス。 (訳注: WiaB は Wave in a Box の略)
    • ライセンスを表示してくれさえすれば、どこで使おうと自由
  • 新しい依存性が必要になったら
  • 可能であれば適切なリリースを使う
  • バージョンとソースおよび使い方を表明するために README ファイルを取り込む
  • ソースファイルを含めるようにする

感想

個人的にはこのセンテンスが印象的でした。

Don't worry about the doc becoming out of date afterwards

スライド本文ではなく発表者用のノートに書いてある "Not telling you it is right, just what we are doing." を表しているんじゃないかな、と思います。

「素早く開発するために仕様書を書かない」という会社もあるみたいですが、基本的には規模の問題なので、いろいろですね。

0 件のコメント: ラベル: ,

2010年9月5日

Google のデモシステム

Google’s Ultimate Demo System の日本語訳です。
---

Google の研究部門のディレクターである Peter Norvig が Slate のインタビューに答えてくれました。

質問：Google は人気のある製品を作ることにおいて大きな成功を手にしてきました。どうやって新しいアイデアを生み出す文化をつくったのでしょうか？

そうですね、我が社には素晴らしい人たちがいます。これはとても大事なことです。しかし、たくさんのアイデアをまずは試してみることが大事だと私は考えています。私たちは社内でデモを作るための素晴らしいシステムを構築しました。もしも創業間もない会社がアイデアを持っていても、まぁよくあることですが、次のようになりますね。「自分のアイデアを動かすためには Web のコピーが必要だ。何千というコンピュータが必要だ。そうするためにお金を工面しなくては。」このため、彼らは数ヶ月あるいは数年をお金を用意したりインフラを構築することに費やすでしょう。

一方で、我々はそうしたことの全てを持ち合わせています。新しく入った人は入社初日にその使い方を学び、こう言うでしょう。「分かりました。アイデアはあります。必要なものもここに既にあります。それらを一緒につなげて、ちゃんと動くかを確認するだけです。」たとえその日に動作しなくても次の週にはもうひとつのアイデアがあるはずです。ひとつの方法に固執して数ヶ月を無駄になどしません。何でもできるおもちゃのようなもので遊んでいる感覚です。あなたがそれらを一緒につなげて何かを試して「これは良い」と思ったら、そのまま続ければよいのです。もしそうでなければ、それらを投げ出してしまい、何か新しいことを始めれば良いのです。


---

アプリケーション開発では当たり前のことを当たり前に、という話ではあるけれども、会社としてそこに力を入れられる、という点が社風につながっていくんだろうなぁ、と思います。なんとなく。

0 件のコメント: ラベル:
登録: 投稿 (Atom)