Archive for 1月 2013
オクトキャットはオープンソースではない
昨今のオープンソースを推進する象徴であり、開発者の大好きなGitHubとそのキャラクターであるオクトキャット(octocat)。皆さんもステッカーやTシャツ、フーディーの入手に努めていると思いますが、そのライセンスについてはあまり知られていないのではないでしょうか？
さまざまなオクトキャットのバリエーションを展示しているoctodexのFAQページにはそのライセンスについての記載があります。原文はサイトを参照して頂くとして、下記のような内容です。(強調は訳者)
Q: オクトキャットを私のウェブサイトで使えますか?
どのように使おうとしているかによりますが、多分使えます。もし”GitHub上で見る”というGitHubへのリンクのようにGitHubを参照する為に使う場合は全く問題ありません。しかしGitHubではないプロダクトを参照する際にオクトキャットを使うのはフェアユースではありません。 これは全ての利用状況に適用され、アプリケーションや印刷物、ウェブサイトに限りません。
Q: オクトキャットを私のアプリのロゴやアイコンに使えますか?
オクトキャットはGitHubの登録商標です。オクトキャットをあなたのロゴやアイコンとして使うのは認められません。
Q: オクトキャットを私のアバターにできますか?
オクトキャットを個人のアバターとしては使えます。しかし会社やあなたが開発中のプロダクトの為には使えません。あなたのGitHubへの愛を示すのは歓迎ですが、あなたイコールGitHubのように見せるのは歓迎されません。
Q: 私自身でオクトキャットを作れますか?
個人的な楽しみの為に作っていれば、オクトキャットを作って見せる事は歓迎です。もし自分のオクトキャットを配布する場合はクリエイティブ・コモンズなどの変更と配布を許すライセンスでの配布はできません。
Q: 私もオクトキャットをOctodexに投稿できますか?
GitHubではかなりの数のオクトキャットを作っています。 内部で数名に見られるだけではなければとの事から、オクトキャットを世界に見せる為にOctodexを開設しました。このリスト上のものは全て公式なGitHubのアートワークであり、GitHubの商標ライセンス下にあります。よって我々はGitHubに関連する人からの投稿だけを受付ます。
Q: オクトキャットを含む製品を作れますか?
GitHubが作ったオクトキャット、自分で作ったオクトキャットであれプロダクトや商品をGitHubの許可無く作成できません。これはTシャツや玩具、ステッカーだけに限りません。
Q: 全てのオクトキャットには使用目的がありますか?
全てではありません。元々のリストは決まった使用目的のあったオクトキャットでしたが、その後リストにはよくわからないものが増えていきました。 ミームが独り歩きする頃にはリストを実用的なものにしておくのは無理だと悟りました。
Q: オクトキャットをサジェスト又はリクエストできますか?
リクエストを @cameronmcefee か @jsncostello にツイートしてください。何も約束はできませんが、なにをToDoリストに加えるべきか私達にはわかりません。おもしろい話をしてくれれば、あなたのお気に入りが見れるかもしれません。
オクトキャットはあくまでGitHubのマークであり、かわいいだけのキャラクターではないという事に留意した上で正しく利用していく必要がありますね。A-Listersの執筆陣の中でも議論があったのですが、GitHubがディズニーのように厳しくオクトキャットの使用を取り締まるとまでは考えられません。しかしクリエイティブ・コモンズで配布されているというような事ではないので、ステッカーがなかなか手に入らないからといって勝手に印刷して頒布するといった早まった行動をしてしまわないようにしないといけませんね。
ただまぁそのわりにスパイダーマンっぽいのとかゼルダっぽいのとかマリオっぽいのとか居るあたりはご愛嬌という事でしょうか。
via:http://octodex.github.com/faq.html
Facebookが開発したPHPを超高速で実行する仮想マシン HipHop VM
FacebookがPHPをさらに高速に実行する技術について2012年11月に公開した記事が話題になっています。Facebookはサービスを高速に実行する為にPHPで書かれたスクリプトをC++に変換して実行する技術、HipHop(HPHPc)を開発して利用してきました。CPUの使用量を半分程度に抑えることができるこの技術は大きな注目を集めていました。
一方でHipHopはPHPのソースコードをコンパイルして実行するというステップが必要な事から開発から実行までの手順が増えてしまうという面もありました。この欠点を補うべく、実行時に変換を行なって実行するアプローチを模索していたのがHipHop VM(HHVM)です。この記事によると、このHHVMがついにHPHPcを上回るパフォーマンスを達成したとのことです。
sandboxと呼ばれる開発環境ではインタプリタとして実行可能なHipHop (HPHPi) が使われて来ましたがこれはオリジナルのPHPのZend Engineよりも実効性能が低かったようです。しかし動的コンパイルを採用したHHVMはこの問題を解消し開発環境でも利用されるようになったとのことです。実際にFacebookの開発者ブログもHHVMで実行されているWordPressで再スタートしたとの事で性能と利便性を両立しているようです。
ブログ記事では実際にWordPressを実行するまでの手順も紹介されており、PHPで極限の実効性能を達成したい人にとっては有益な情報と言えそうです。
参考：
Facebookが公開したPHP仮想マシン「HipHop VM」とは – builder
via:Speeding up PHP-based development with HipHop VM
API設計に関する10のワーストプラクティス
過半数の開発者が平均で3つ以上のAPIのインテグレーションを実装していると言われている昨今、「使い辛い設計のAPI」を実装するのは開発者にとっては頭の痛い問題ではないでしょうか？ Programable Web上に投稿されたAPIのワーストプラクティスに関する記事が国内外の開発者の目に止まったようです。この記事によると悪いAPIに見られるプラクティスは下記のようなものだそうです。
- 貧弱なエラーハンドリング
- HTTPのルールを無視したREST API
- 裏に潜んだ生のデータモデルの露出
- セキュリティの複雑さ
- ドキュメント化されていない予期せぬリリース
- 貧弱なデベロッパエクスペリエンス
- MVCフレームワークが良いAPIにしてくれるという思い込み
- 開発すれば使ってもらえると見なすこと
- 不十分なサポート
- 貧弱なドキュメンテーション
APIを利用するだけでなく、APIを提供する場合に上記のようなポイントを気に留めておくと役に立ちそうです。
via:http://blog.programmableweb.com/2012/08/03/top-10-api-worst-practices/
ターミナルからHacker Newsが見れるGem
日本でも引き続き認知の高まっているHacker Newsをコマンドラインから閲覧できるGemが話題になっていました。導入はとても簡単です。
gem install hacker_term hacker_term
最近のGemはウェブサービスのクライアントやHTMLやCSSのコーディングに使うツールなどもはやRubyにとどまらない汎用ツール化してきていますねぇ。
via:https://github.com/ciaranarcher/hacker_term
Netflixでクリスマスイブに発生した障害の詳細なレポート
2012年12月24日、Amazon Web Serviceのロードバランサーサービス、Elastic Load Balancer (ELB) で発生した障害はアメリカの多くのネットサービスに影響しました。その中でも特に大きな影響を受けたのがAmazon Web Serviceの大型ユーザである動画配信サイト、Netflixです。Netflixで発生した障害についてはメディアの記事にもなっていますが、Netflixの技術ブログに詳細なレポートが投稿され話題になっていました。
太平洋時間午後12時30分から発生した障害はテレビに接続するデバイスへの再生の北米、ラテンアメリカ向けのサービスに影響を及ぼしました。それ以外の地域、イギリスや北欧諸国では影響は無かったとの事です。このような形で影響範囲が分かれた背景にあるアーキテクチャを記事では解説しています。
Netflixは何百ものELBを使っています。それぞれのELBが別個のサービスや異なるバージョンのサービスをサポートしブラウザやデバイスからの呼び出しに応じてネットワークアドレスを提供します。Netflixのストリーミングはここ数年で千以上の異なる種類のデバイスに実装され、似通ったデバイスはしばしば同一のELBに依存します。デバイスはELBを通じてNetflixの大部分のアプリケーションを実行しているサーバーにリクエストを行います。Netflixが使っている何百ものELBの障害はバックエンドのサーバーへリクエストを通過させる事ができなくなる厄介な問題です。その他のNetflixのアプリケーションには問題はありませんでした。我々のアプリケーションは何らかの形でリクエストが通った場合は通常どおり応答していました。
この解説から見えてくるのは大量のデバイスごとのゲートウェイと実際の配信部分やWebサイトの機能などを分離して実装しているという構造です。幸いクリスマスイブは家族とストリーミングを見る以外の方法で過ごす人が多いのでトラフィックは必ずしも多い日ではなかったようです。またゲーム機などのコンソールは影響を受けましたが、PC向けなど影響が無かったサービスがあったという現象は上記の構造からと推測できます。
エントリは今後も障害の影響を受けない構造を目指して改善を続けていく事と求人の案内をした上で締めくくられていました。
via:http://techblog.netflix.com/2012/12/a-closer-look-at-christmas-eve-outage.html
A-Listers 