Archive for the ‘Uncategorized’ Category
16の言語と57のフレームワークを比較したベンチマークが凄い
いつの時代もより高速に動作するフレームワークや言語に対する関心は高いものですが、そんな疑問に答えるWeb Framework Benchmarksの最新版が公開されています。こちらのベンチマークはテスト用のコードや環境がオープンソースになっており16の言語(C C# Clojure D Erlang Go Groovy Haskell Java JavaScript Lua Perl PHP Python Ruby Scala)と57のフレームワークについて最適な実装が集められてテストされているという点で一般性があります。また実行環境もEC2と実マシンの2種類をそれぞれ実行している点も興味深いです。
気になるテスト結果のうち特に複雑度の高いデータベースから複数件のデータを取得してHTMLページとして出力した場合の結果は下記のとおりです。
堂々のトップに輝いているのはServletで最大で1秒間あたり7,344レスポンスの凄まじい結果を叩きだしています。また2位に入っているgeminiはこのベンチマークを実行しているTechEmpower社の社内フレームワークとの事です。PHP(秒間あたり最大2,262レスポンス)やRails(秒間あたり最大461レスポンス)などスクリプト言語が下位に甘んじていますが、1台のEC2インスタンスが稼ぐ性能としてはそれでも充分なような気がします。1秒間に7,344レスポンスということは1日あたり6億以上のレスポンスをたった1台のサーバで返すわけです。逆に秒間100レスポンスであっても1日あたり864万レスポンスですよね。
その他テスト結果を見ていると気がついた点をいくつか挙げておきます。その他の結果も膨大ですので是非元の記事も併せてご覧になってください。
- gemini servlet go などは安定して上位入り
- Symfony Cake Fuel Sinatraなどが下位集団に居る事が多い(それでも秒間200〜1000レスポンスを処理しています)
- 只のphpは常にフレームワークよりも高速
RailsはSinatraよりも高速Railsの方がSinatraよりも高速な場合もある- Node.jsはServletに対して30%〜80%程度の性能
ベンチマークというと「〜〜はこんなに遅くない」的な意見が良く出がちですが、最下位であっても秒間数百レスポンスを処理しているので通常の利用では低速とは言えないでしょう。（もし気になる点があればGitHub上でテストコードにプルリクエストを送りましょう）
一方でフルスタック系のフレームワークや軽量フレームワークなどの速度が大きいケースや逆にrailsとsinatraの用に逆転しているケース、仮想環境と実マシンで結果に開きがあるケースなどがある点が興味深いのではないでしょうか。ご覧になった皆さんも気づいた点があれば是非ツイートやコメントでお寄せください。
via:http://www.techempower.com/benchmarks/#section=data-r4
良い仕事は仕事を愛することから始まる
Engine YardのアプリケーションエンジニアのKevin Hollerさんが自身のブログに投稿した記事がHacker Newsで話題になっていました。記事では彼が14歳の時に始めた地元のパブでのアルバイトを通じて学んだ仕事への姿勢について触れています。バイトを始めた当初は平凡な作業の繰り返しの仕事を稼いだお金で何を買うかを考えたり、時計に注意してシフトが終わったらすぐに帰るという姿勢で乗り切っていたようです。一年後には仕事も覚え、仕事に行く事が一番大変という状況だったようです。そんな中で彼が昼休みに見かけたバーテンダーの仕事ぶりが彼の意識を変えます。
ある日曜の午後、店は殆ど空っぽで私はランチを食べながらバーテンダー達と話していた。バーテンダのうちの1人はバーを整頓するのに忙しそうで、他のバーテンダーは普通の作業をしたりすることが無さそうだった。私は何故彼が整頓に忙しいのかを尋ねると彼はこう答えた。「このドリンクは今年は人気なので前に並べないといけないんだ。」このバーテンダーの他のバーテンダーとの違いは店を良くしようとしている事だ。そしてそれが同時にこのバーを彼が楽しんで働ける場所にしている。他のバーテンダー達は言われた事だけやって他の事はしない。もちろん彼だって私と同じくお金の為に働いている。
この日以降、Kevinさんは仕事への姿勢を変えて平凡な仕事を楽しいものにするべくプライドを持って取り組むようになったそうです。大学に入りプログラマーとしての仕事を始めるまで続けていたアルバイトを通じて彼は立派なバーテンダーになりこの経験を下記のようにまとめています。
私は雇用主の為に働いているというよりも、自分自身の為に働いていた。その姿勢が自分自身をより幸福な人間に変え、それが雇用主の為にも良い事だった。
この投稿に対してはHacker Newsの住民も多いに反応しており同様の記事を書いたことがある方もいたようです。否定的な意見では「1000ユーロ以上稼げる仕事をしているからそんなことが言えるんだ」というような者もあり英語の議論ですが内容が追いやすいですね。
この春から新しい生活になり戸惑っている方や仕事が退屈だと感じている方にとって何かヒントになるかもしれません。あなたは現在の自分の仕事を愛せていますか？
via:http://www.kevinholler.com/love-what-you-do-not-what-you-earn/
GitHubのTシャツに新しいバリエーションが追加
ご覧の通り、新しいTシャツが追加されていますね。Contribution Graphと銘打っているのは最近新しくなったプロフィールページのコントリビューショングラフをモチーフにしているからですね。
実物を見てみたいので、是非どなたか購入してみてください 😀
via:http://shop.github.com/products/contribution-graph-shirt
CIAがAWSを使ったプライベートクラウドを構築するらしい
アメリカ大統領選挙でも一役買った事が知られたAmazon Web Serviceですが、なんとCIAもAWSを使ったプライベートクラウドを構築するらしいというニュースが報じられました。
第一報が報じられたのはFederal Computer Weekという媒体でこれによると、CIAがアマゾンとの10年以上で総額6億ドルにも及ぶクラウドコンピューティング契約に合意したとの事です。とはいえCIAは具体的な契約の内容や金額、契約先については公表しないとの事で公式発表ではありません。
“As a general rule, the CIA does not publicly disclose details of our contracts, the identities of our contractors, the contract values, or the scope of work,” a CIA spokesperson told
この記事を元にしたNetwork Worldの記事では「政府の主要な団体がCloud StackやVMWareではなくAWSを選択した」としつつもAWSがプライベートクラウドの分野にどのように進出するのかについてVPCなどを例に挙げて解説しています。
とはいえやっぱり公式には何も公表されていないので真実は闇の中ですが、話としては面白いですね。
via:http://www.networkworld.com/news/2013/031913-amazon-cia-267881.html
GitHubが女性向けテックイベントをスタート
Rails Girlsや各種の女子部など日本でもテック系の職業についている女性の為のイベントはいくつかありますが、GitHubからも「女子部」的な活動が聞こえて来ました。その名も「Passion Project」。
公式サイトやブログの記事によるとPassion Proiectとは下記のようなものだそうです。
Passion ProjectはGitHubの社内で女性向けのエンジニアリングカルチャーを作ることについての会話から生まれました。女性が働きたい会社の女性エンジニアを招いたプレゼンテーションシリーズを行います。これをコミュニティにシェアする方が良いのでそうする事にしました。
第一回は3/14にGitHubの本社で開催されゲストはアパレルサイトのModCloth所属でRails Bridgeというコミュニティで女子向けの開発講座などのオープンソース活動に熱心なRachel Myersさんとのことです。その他のゲストエンジニア女子についても公式サイトでリストアップされています。
GitHubが関連したイベントでいうとRails GirlsやCoder Dojoなどが日本でも既に開催されており、Passion Projectも日本で(誰かが立ち上がれば)も行われる可能性がありそうです。とはいえイベントの枠組み自体は日本の「女子部」に近いようにも見えますのであるいは日本が先を行っていたという可能性もあるのかもしれません。
via:https://github.com/blog/1433-introducing-passion-projects
EmberJSに混乱している人が話題
EmberJSを頑張って理解しようとしたけど無理だったという苦労話のブログ投稿が話題になっていました。このブログ投稿を書いたのはハイクオリティなスクリーンキャストを集めているTekPubを運営しているRob Conery氏で、RubyやJavaScriptを中心に幅広い活動をしているようです。
彼は自分自身の努力が足りなかったか、飲み込むまでの時間に達していなかったという謙虚さを示しつつもTekPubにEmberのタイトルを掲載する為に努力をしていたようです。彼がEmberで理解できなったという点として下記のような点を挙げています。
- MVCだというけれど、なんか違う
- Controllerが結局、Viewをコントロールしてる
- ModelがController的である
- ルーティングとオブジェクトが複雑
- 命名規則が複雑（ネーミングガイドとケーシングガイドがある）
元記事ではコードの引用も多くされていますが、MVCの分離のアプローチとメリットに納得がいかないという様子です。Emberに触ったことの無い方も多いと思うのですが、一読してみると参考になるかもしれません。
via:http://wekeroad.com/2013/03/06/ember-confuses-me
恐るべきネタ系カンファレンス LessConf
ネタ系カンファレンスとしてはバスや島を会場にするFun Confを以前紹介しましたが、似たような系統のカンファレンスがアメリカにも存在していました。それがLessConfです。とはいえカンファレンスの過去の登壇者は37SignalsやGitHub、Grouponなどの創業者が勢揃いしておりとても豪華です。公式サイトには下記のような記述があります。
LessConfはあなたが知っている他のイベントとは違います。もちろん講演者と懇親会、ラップトップを持った人々があります。しかしLessConfは「スタートアップの為のサマーキャンプ」「人生最高の時」などと呼ばれています。あるいは「世界最悪のカンファレンス」とも。
いかにもドンチャン騒ぎをしそうな触れ込みです。主催者側の過去の動画にはかなりクレイジーな催しが記録されています。
iPad争奪 丸刈り選手権
か、髪が！眉が！ そしてスポンサーがｗｗ
GitHub生涯無料権争奪 激辛選手権
うわーうわー！ スポンサーがまたしても無駄に豪華ｗｗ
Apple TV争奪 顔面洗濯バサミ選手権
むしろ序の口？
日本でもテクノロジー系のイベントが発展していますが、そろそろ体を張った出し物が流行ったりするんでしょうか。できれば流行らないで欲しい気もします。
via:http://lessfilms.tumblr.com/post/36811402916/your-conference-needs-more-videos
オクトキャットはオープンソースではない
昨今のオープンソースを推進する象徴であり、開発者の大好きな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/
A-Listers 