投稿者アーカイブ
「気難しいネコ」のTardちゃんがネットで人気
筆者のタイムラインにこの所海外からよく流れ込んでくるのがこのネコの写真です。これはGrumpy Cat(気難しいネコ)という名前でミームになっているTardちゃんで、飼い主はアリゾナのTabatha Bundesenさんです。この写真が有名になったのはReddit上に投稿された2012年9月23日以降です。そこからさまざまなキャプションや編集された写真が大拡散しているようです。
洋の東西を問わずインターネットではネコが人気コンテンツであるという点はいつもどおりですが、話題が拡散したのがReddit上であるという点は昨今のバイラルが発生するメカニズムの違いを表しているようで興味深いですね。外人に受けるスライドなどを仕込みたい人は引用してみるとよいかもしれません。
ちなみに動画もかわいい。
C言語より高速なJavaScriptによるバイナリ操作が話題
JavaScriptなどのスクリプト言語は動作が遅く、最適なパフォーマンスを得るにはC/C++で実装しなければならないという常識に挑んだ先進的な講演が話題になっています。この話題の発端は2012年10月7日から10月8日までベルリンで開催されたJSConf.euでFelix Geisendörfer氏が行った講演です。
彼の講演の題材はnode.jsからMySQLに接続する為のバインディングのパフォーマンスに着目しています。2010年当時、node.jsにはMySQLのバインディングが存在しておらず、増井さん作のnode-mysqlモジュールが開発中の状態でした。このモジュールはJavaScriptでバイナリを解析しておりJavaScriptのみで開発されていました。この状況を受けてFelix氏が新たにnode-mysqlモジュールを新規に開発を始めました。このモジュールもJavaScriptでMySQLのプロトコルを処理しています。
続いて発表されたのがOleg Efimov氏のmysql-libmysqlclientバインディングです。こちらの場合はその名の通りC言語で実装されたlibmysqlを利用しておりパフォーマンスが大きく向上しています。
この圧倒的な性能差はちょっとした最適化で埋まるものではなさそうです。これにはFelix氏も心が折れかけ、「マテ、V8 ってコードをアセンブラにするんだろ?それってめちゃめちゃ速いんじゃないか?それになんだかんだいっても Node ならどんな問題でも解決できるんじゃないの?なに騙されてたの?(But wait … wasn’t V8 supposed to turn my code into assembly? And was it not supposed to be insanely fast? And wasn’t node going to solve all of my problems anyway? Had I been lied to?)」弱気になりつつも、気合を入れ直します。そして才気溢れるFelix氏はNode.jsの底力を信じてパーサーの改良を努力し、なんとlibmysqlを越えるパフォーマンスを実現します。
素晴らしい改善です。しかしなんと更に彗星の如く現れたバインディングがさらに圧倒的なパフォーマンスを見せつけます。それがBrian White氏が公開したnode-mariasqlです。
この性能差にはFelix氏の心も折れかけ、「もうCのバインディングに勝つなんて無理だよ…( maybe it’s time to finally give up and accept that I cannot compete with a well engineered C binding.)」と弱音を吐きかけますが、彼の更なる努力がJavaScript実装でmariasqlを越えるパフォーマンスを引き出します。
彼のパーサーの再実装から得られた知見は元記事の後半部分に記載されています。V8の特性に配慮したJavaScriptを書くことでの極限のパフォーマンスを実践したい方にとっては参考になるのではないでしょうか。というか、彼スゴすぎますね。
via:https://github.com/felixge/faster-than-c
韓国はAndroid天国らしい
Nexus7の発売が話題になっており、引き続き活発なAndroidについて気になる統計がRoyal Pingdomに掲載されていました。記事によるとモバイルのウェブ閲覧の28.21%がAndroidによって行われ、これはiOSの24.48%を上回っています。
国ごとの数字でみるとなんと韓国ではモバイルウェブの87.2%がAndroidからの閲覧という事で圧倒的です。次いでミャンマーでは84.5%、台湾では70.6%ということで高いシェアを持っています。韓国がサムソンのお膝元であるから驚きには値しないとしつつも、驚異的であると記事では締めくくっています。
via:http://royal.pingdom.com/2012/09/06/south-korea-android-heaven/
新時代に突入したPHPのフレームワーク戦争
2012年9月、PHPのフレームワーク戦争は新たな局面に突入した事が明確になってきました。PHPフレームワーク、Symfonyプロジェクトの創始者であるFabien Potencier氏のブログ記事がPHPフレームワーク界で話題です。
オブジェクト指向を本格的にサポートしたPHP5とRailsが与えたインスピレーションから始まった2005年頃からはsymfonyやZend Framework、CakePHP、CodeIgnitierなどのフレームワークを生み出しました。その後、名前空間をサポートしたPHP5.3がリリースされるとコードの抜本的な構造などを見なおした次世代フレームワークが次々に登場します。冒頭のFabien氏の記事では2012年9月6日にZendFramework 2.0とSymfony2.1が奇しくも同日にリリースされました。Fabien氏はZendFrameworkのリリースを祝福した上で、「何故、他のXというフレームワークよりSymfonyを選ぶのか?」という質問の回答としてブログの記事を投稿しています。
記事によると下記のような点をSymfonyを選ぶ理由として挙げています。
- Symfonyはフレームワークではなく、プロジェクトであり用途に応じて様々なコンポーネントをそのままつかったり、Sliexとして使ったり、フルスタックなフレームワークとして使う事もできる。
- 大きな採用事例があること。(BBC NBC TEDなど)
- 大きなコミュニティがあり、昨年だけでも550人以上が貢献している。
- 車輪の再発明をしない事を推奨しておりさまざまなコンポーネントが開発、公開されている
この記事には非常に多くのコメントが寄せられ、このようなドキュメントを各フレームワークが記述したらいいのではなどという声も上がり始めました。そしてCakePHPの開発チームの一人であるJose Diaz-Gonzalez氏が正に返信の記事である「Why to Actually Choose CakePHP?(なぜ実際はCakePHPを選ぶのか?)」という記事を公開します。こちらの記事ではジョークを交えて下記のような点をCakePHPを選ぶ理由として挙げています。
- 熱心な開発者
- 継続的なリリース
- モデルレイヤー
配列がPHPでデータを扱う最良の方法であるから。Cake3からはモデルをオブジェクトとして扱う事もできるようになるが。- Symfonyじゃないこと
- パトリオットエールハウス
このバーで一緒にエールを一杯飲んだ相手しか信用しないので
また前後してZendFrameworkの開発チームのEvan氏は「Why ZendFramework」という記事を公開します。こちらの記事では直接Fabien氏の記事を引用しつつZendFrameworkを選ぶ理由として下記のような点を挙げています。
- ZendFrameworkはずっとコンポーネント志向だった
- ZendFrameworkも大企業につかれている。(BBC, Cisco, Discovery, Panasonic, Offers.com等 同様にオープンソースプロジェクトでも使われている。: Magento, TomatoCMS, pimcore, Centurion, Digitalus CMS, Webfolio, PHProjekt, Concrete5)
- コミュニティの活発さ、車輪の再発明をしない事などは同じようにZendFrameworkにも当てはまる
全てを読んでみると、説得力のあるSymfony,場外戦術を仕掛けるCakePHP、俺も俺もといった感じのZendFrameworkという感じです。いずれの主張もRails直後のような機能ではなく、汎用性やコミュニティの活発さなどに言及している点が印象的です。技術的にはPSR-0やPSR-1といったフレームワーク間で設計や規約が共有化され、コンポーネント化や相互の再利用がしやすくなっている点もあり、コミュニティこそがフレームワークの特性になってきているのかもしれません。
Googleが運営するロンドンのコワーキングスペース Campus
日本でも増えてきたコワーキングスペースやスタートアップ向けのシェアオフィスですが、ロンドンにはGoogleが運営するスタートアップ向けのシェアオフィス・コワーキングスペースがあります。それがCampusです。
こちらのスペースではNode.jsのミートアップのようなイベントが行われていたり、Seed CampやTech Hubなどのスペースが設けられています。TechHubの会費は年間で375ポンドとの事で1日1ポンドちょっとと考えるとジュース一本分くらいですね。(選考とかもありそうですけど)
サイト上で無料の登録をするだけで地下のカフェスペースは使うことができるので、今回ロンドンに滞在していたので利用してみました。
話をしてみてもやはりフリーランサーやスタートアップを運営している人が集まっているという事でTechな雰囲気の強いスペースですね。ほとんどの人がイヤホンをしていますが、打ち合わせをしながら作業をしている人もかなり居ました。
インテリアもオシャレですし、ロンドンに滞在する予定で作業環境が必要な人は覚えておくと良いでしょう。念のため補足するとあくまでワーキングスペースですので単純なネットカフェのようなものを期待している人ではなく、コワーキングスペースとしての利用が前提です。事前の登録をWebから行う事をお忘れなく。
「動く写真」が作れるiPadアプリ Echograph
以前、こちらの記事「3Dよりも断然すごいアニメーションGIF « A-Listers」でも紹介したような写真の用で一部分が動くアニメーションGIFが海外で流行っていますね。そういった動画を簡単につくれるサービスが無いかなと探してみるとEchographというアプリを見つけました。
例としては下記のような画像が作れます。
使用方法は下記の動画を見ればだいたい分かるかと思います。
スマートフォンで使うことができてInstagramのようなサービスになったら面白いなと思いますがどうでしょうか?
猛烈にオシャレなRails女子コミュニティ Rails Girlsのビデオ
フィンランド発祥のRails女子コミュニティ、Rails Girlsがすごくオシャレです。トップページのスケッチ風のイラストにはよく見るとオクトキャットらしきものがいたり、ロゴもかわいらしいです。そしてなによりびっくりしたのが4月にベルリンで開催されたイベントのレポート動画です。
Rails Girls Berlin 2012 from Alexander Lang on Vimeo.
冒頭のタイピングから参加者のインタビューとオシャレな雰囲気が漂いまくりです。また参加者の中にはプロダクトマネージャーや学生など、普段コードを書かない立場の人がRailsを学びに来ているというのも面白い点です。同様のコミュニティとしてPHPWomenというのもあるのですが、これは日本版をやるなら女子会といったところでしょうね。
Tumblrがミュージカルになった
タイトル以上に言うべき事はないのですが、Tumblrをネタにしたミュージカル動画がフィードから流れてきました。公開したのはvlogbrothersというチャンネルでかなり大量の動画をアップしているようです。多分必要ないと思いますが、今回作られた楽曲はiTunesでも99セントで購入できます。
動画を見て分かることとしては「猫の画像が多い」「オバマもTumblr」「GIFの発音はギフじゃなくてジフ」って事ですかね。なお同様の動画としてInstagramのミュージカル版もあるようです。こちらは転んだガールフレンドの写真を投稿する所から始まりなんでもかんでも投稿しながらフィルター名を連呼するといった、Instagramユーザーなら「あるよね〜」と感じる内容です。
日本でも歌ってみた文化がありますが、どうも海外は実写のビデオを作りこむ人が豊富な印象がありますね。
Stack Overflow発 プログラミングの隠語(ジャーゴン)30選
お馴染みのCoding Horrorでプログラミングの隠語(ジャーゴン)についての記事が話題です。
このエントリの元になったのはStack Overflow上で行われた「あなたが新しく作ったプログラミングのジャーゴンはなんですか?(New programming jargon you coined?)」という質問です。この質問にはなんと386もの回答が寄せられ、その中でStack Overflowのコミュニティの投票で上位になった30のジャーゴンをリストにして解説したのがCoding Horrorの「Coding Horror: New Programming Jargon」という記事です。
下記がコミュニティによって選ばれたジャーゴンのリストです。
1. Yoda Conditions(ヨーダ条件式)

変数とリテラルを比較する際にリテラルを左辺に置く記述。スターウォーズのヨーダが「The sky is blue」ではなく「if blue is the sky」と喋る事から。
2. Pokémon Exception Handling(ポケモン例外処理)
全ての例外を捕まえようとする事。
try {
}
catch (Exception ex) {
// Gotcha!
}
3. Egyptian Brackets(エジプト人ブレース)

行の最後でブレースを開くスタイル。エジプト人のイラストの手の位置から。
if (a == b) {
printf("hello");
}
4. Smug Report(ドヤ顔レポート)
自分自身では大した事はしていないのにでシステムデザイン事がわかっているつもりの人によって投稿されるレポート。見当違いの詳細や(間違った)解決策の提案などが添えらている。
関連語としてDrug Report(ラリってるレポート)、Shrug Report(エラーメッセージなどが無く動かないとだけ書かれている)などがある。
5. A Duck
理由もなく追加され、不要な影響を避ける為に結局取り除かれる機能。
あるアーティストがアニメーションの制作に参加した際に、他のアニメーションに影響を与えないようにカモのキャラクターを追加した。プロデューサーによるデビューの際、プロデューサーからのコメントは「良いね、ただカモだけは取り除いてくれ」
6. Refuctoring(リファクトリング)
良いデザインのコードにしようとしてあちこち弄り回した結果、誰にもメンテナンスできないコードになること。
7. Stringly Typed(謎の型付け)
強い型付け(strong typing)のもじり。適切な型のパラメータを取ればよいのに、わざわざ独自の文字列を使ったりするなど。
8. Heisenbug(ハイゼンバグ)
それを調査しようとすると変貌したり消えたりするバグである。この名前は不確定性原理を提唱したハイゼンベルクのもじり。
ex) この名前は不確定性原理を提唱したハイゼンベルクのもじり。
9. Doctype Decoration
DoctypeだけHTML5でマークアップは滅茶苦茶といったような様子。
10. Jimmy
標準的な新人プログラマの名前。「もしジミー君が属性の更新をしなかったらどうなるでしょう?」というような例えに使う。
11. Higgs-Bugson(ヒッグスバグ粒子)
ヒッグス粒子 – Wikipediaのもじり。非常に僅かなログなどで存在すると仮定されるが、存在は確認されていないバグ。
12. Nopping
アセンブラなどで使う何もしない命令、NOP – Wikipediaから。昼寝(Napping)に似ているが寝ている訳ではない。
13. Unicorny
かなり初期の計画段階の為、まるで空想の出来事のように説明がつかない機能。
14. Baklava Code(バクラヴァコード)
トルコのミルフィールのような菓子。レイヤーが多すぎる事。
15. Hindenbug(ヒンデンバグ)
ヒンデンブルグ号の爆発事故のように悲劇的なデータ消失を引き起こすバグ。
16. Fear Driven Development(恐怖駆動開発)
解雇、締め切りの前倒し、リソースの削減などのプレッシャーが管理者から加えられる事。
17. Hydra Code
不死身のヒドラのように直せないコード。1つバグを直すと新しく2つのバグが発生する。
18. Common Law Feature
間違っているのにも関わらず、仕様の一部になってしまったバグ。
19. Loch Ness Monster Bug(ネス湖の怪物バグ)
再現性がなく、目撃者が1人しかいないバグ。
20. Ninja Comments
見えないコメント、秘密のコメント、またはコメントが無い事。つまりコメントが無い。
21. Smurf Naming Convention
全てのクラスに同じプリフィクスがついていること。
例:ユーザがボタンをクリックするとSmurfAccountViewがSmurfAccountDTOをSmurfAccountControllerへ渡す。
22. Protoduction(プロトダクション)
プロトタイプのまま世に出たもの。
23. Rubber Ducking
問題を誰かに説明していると自然と解決策が見つかる事があるので、アヒルのおもちゃに語りかけてみること。
24. Banana Banana Banana
あとでドキュメントを書く所に埋めておくテキスト。IDEの警告を回避する為にとりあえず埋める。
/// <summary> /// banana banana banana /// </summary> public CustomerValidationResponse Validate()
25. Bicrement
変数に1を加算する(インクリメント)ではなく2を加算する。
26. Reality 101 Failure
意図したとおりに動いているが意味のないコード。
27. Mad Girlfriend Bug(怒ったガールフレンドバグ)
明らかに何かが起きているかが、ログやメッセージは「何でもない」というバグ。
28. Megamoth(モスラ)
MEGA MOnolithic meTHod(一体化した巨大なメソッド)。2画面以上に渡っていたりする。
29. Hooker Code
アプリケーションのダウンなどを度々引き起こすようなコード。
30. Jenga Code(ジェンガ)
1ブロックでも変更すれば全体が崩壊しそうなコード。
ちなみにこの記事の元になった質問はStack Overflowのポリシーに反しているので現在、サイトからは削除されています。人気を博した事でサイトで見られるように削除を取り消すかどうかも議論されています。
参考:
新しいプログラミングのジャーゴン – YAMDAS現更新履歴
Island Life – New programming jargon
Google I/O 2012発 JavaScript高速化Tips集の日本語訳
既に「Google I/O 2012で公開されたJavaScript高速化Tips集 | IDEA*IDEA」や「JavaScriptパフォーマンスを上げるシンプルな13の最適化 | Act as Professional – hiroki.jp by HIROCASTER」で紹介されて話題になっていたJavaScriptの高速化TIPSがhosikitiさんによって和訳されています。
リストでまとめられたリストを日本語で見たいという要望に見事に応えてくれていました!
1.コンストラクタ関数内ですべてのオブジェクトメンバを初期化する
2.常に同じ順番でオブジェクトメンバを初期化する
3.Numeric型(31bitで表現される符号付き整数)を出来るだけ使う
4.0から始まる連続した値を配列のキーとして使う
5.巨大な配列(64000個以上の要素を持つもの)は予め確保せず、必要になったら随時追加する
6.配列要素を削除しない(特に数値配列の場合)
7.初期化されていない、あるいは削除済の要素を読み込まない
8.小さな固定サイズの配列の初期化には配列リテラル[]を用いる
9.小さな配列は予めそのサイズ分領域を確保しておく
10.数値配列に数値以外の値(オブジェクト)を格納しない
11.関数の中の動きが単一になるようにする(ポリモーフィズムは避ける)
12.try {} catch {} ブロックは使用しない
13.関数作成後に構造を変えない(Chromeが実行時に作成するクラスが変わってしまう)
元記事ではもう少し詳しい説明と動画などへのリソースもまとまっています。是非hosikitiさんの記事にもブックマークやコメントをどうぞ!
via:http://www.jonefox.com/blog/2012/07/10/13-javascript-performance-tips/





















