A-Listers

140字に収まらない海外テックネタヘッドライン

Archive for 7月 2012

一番笑えるパイチャートを頼む

leave a comment »

QA サイトの Quora で、笑えるネタ質問があったので紹介します。

What are the most hilarious pie charts?

同性愛結婚その後:

  • 同性愛者が結婚する
  • ロシアが攻めてくる
  • 最後の審判が始まる
  • 家族崩壊
  • 氷床崩壊

カトリック的な家族感が一部で根強く残るアメリカでは同性愛結婚に関しては大きな議論の対象でした。オバマ大統領が同性愛結婚支持に回った事にまつわる世論の大騒ぎをネタにしたパイチャートが堂々の一位です。

Rick Astley は絶対:

  • 君をあきらめない
  • 君を失望させない
  • 君を裏切らない
  • 君を泣かせない
  • 君と別れない
  • 君に嘘をついて傷つけない

Rickroll で一斉を風靡した Rick Astley の歌詞をネタにしたものですね。状態遷移図でも見たことがある気がするんですが、これは歌詞の出現率も表しているんでしょう(適当)。

Meat Loaf が愛のためにする事:

  • なんでも
  • アレ

これも歌がネタですね。Meat Loaf の大ヒットシングル I’d Do Anything for Love (But I Won’t Do That)愛にアレはいらないのです。Wikipedia には『アレ』とは何かに関する議論があります(棒読み)。邦題は『愛に全てを捧ぐ』。

日本:

  • 日本

ほとんど意味が分かりませんが、日本国旗はパイチャートで書けるよ!という事でしょうか。バングラディシュもかけそうだな、と思ったら、ちゃんと登場しています(おそらくコメントに関して down vote を受けているのででデフォルトでは見えません)。正確に日本国旗を描く時は、朱の色指定だけでなく、白地のアスペクト比、円の比率に関して規定があるので、これは日本国旗としては正しくないですね。日本人としてはコメント欄に突撃すべきところでしょうか。

  • パイの食べた部分
  • パイの食べてない部分

おいしそうですね。

パックマンに似てる百分率

  • パックマンに似てる
  • パックマンに似てない

パックマンの口は動くので、これは正確じゃないですね。

Quora は、ネタ質問だけでなく、シリアスな質問にも回答の質の高さで評判があります。巡回先の一つにどうぞ。

Written by beatak

2012/07/26 at 10:14

カテゴリー: Uncategorized

Tagged with , ,

Stack Overflow発 プログラミングの隠語(ジャーゴン)30選

with 3 comments

お馴染みの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(バクラヴァコード)

Baklava - Turkish special, 80-ply.JPEG

トルコのミルフィールのような菓子。レイヤーが多すぎる事。

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

via:Coding Horror: New Programming Jargon

Written by yandod

2012/07/25 at 11:42

カテゴリー: Uncategorized

Tagged with ,

IT業界とニューヨーク市

leave a comment »

Made in NY Logo

A-Listers では New York の話題を繰り返し書いてきていますが、New York 市で一番の産業と言えば、おそらく金融で、その次がメディアでしょう。五月の第三週、インターネット関連のメディアが一同に会する Internet Week NY というお祭りがありました。最終日の 21日は Webby Award の授賞式もありました。ソーシャルメディアが全盛のこの頃では、お祭りごとの相対的な存在感がやや薄らいで来たような気もしますが、ドッグイヤーなインターネットでは 16年も続けば大御所ですね。

ファッションショーや映画など Made in NY キャンペーンを見た事はありませんか?New York 市が街の魅力の紹介と産業の育成の両方を業界と一緒になって取り組んでいるものです。最近ではそのインターネット版とでも言えるようなキャンペーンもやっていて、Digital Jobs なんてのはインターネットを仕事とする我々には嬉しいサイトですね。最新の成果として eBay も New York 市に新しいオフィスを作るようです。

そんな中、New York ローカルな startup に在籍した Jeff Atwood 氏(stackoverflow で有名な Fog Creek の co-founder)が、以前の記事でチラッとお伝えした New York 市長 Mike Bloomberg 氏の2012年の抱負: プログラミングを学ぶことに関して賛否両論なブログ記事を書いてやや炎上していました。

New York 市のテックコミュニティへのリップサービスであろうとはしつつも、もし市長の仕事をこなすために、JavaScript を書かなきゃいけないとしたら何かが根本的に間違ってる、という主張を、自身の過去のエントリを引きつつ高らかに語っています。政治家にはもっと他にすることがある、ある朝起きてたら凄腕 Java プログラマーになっていた Mike Bloomberg が市長職をよりよく出来る理由なんてない!と。

Bloomberg 市長の抱負は、その tweet 自体にも含まれていますが明らかに http://codeyear.com/ のキャンペーンの一環です。女性の IT 業界への参加を促す活動を始め、産業人口の増加は産業自体の強化につながる訳ですから、いいことなんじゃないでしょうかね?

Written by beatak

2012/07/23 at 10:32

変な日本語 in the web: 鉄棒.org

leave a comment »

変な日本語シリーズ第二回は、Motorola Mobility(Google 傘下)がお送りする、JavaScript Tech Community 鉄棒.org です。

明後日の方向を向いたブランド名もさることながら、ど真ん中のプロダクト名: Ninja ですよ!しかも内容は昔の Flash の雰囲気をモダンなフロントエンド(HTML5 / JavaScript / CSS3)で実現し、Google Chrome App として実装

Ninja とそれを実現している JavaScript フレームワークの Montage を中心にした、open-source community を立ち上げたいみたいですね。サイトの構造やドキュメントにはまだちぐはぐな部分があったりしますが、Github 上でかなり活発に開発は行われています。

このサイトが人気になったら、今後は job requirement に tetsubo experience とか書かれるようになるんでしょうか?日本体操協会は今から英語で FAQ ページを作るか、ドメイン紛争の準備すべきではないでしょうか。何れにしても目が離せません!

Written by beatak

2012/07/19 at 13:52

カテゴリー: Uncategorized

Tagged with , ,

New York 市は公衆電話を公衆 Wifi へ。

leave a comment »

New York 市は公衆電話を無料の公衆 Wifi スポットにしていく、パイロットプログラムを開始すると発表しました。まずは Manhattan に 7ヶ所、Brooklyn に 2ヶ所、Queens に 1ヶ所、合計 10ヶ所から。徐々に拡大していく計画だそうです。正確な場所は Press release を参照してください。

NYC GOV – The City today announced a pilot program to add…

アメリカではしばらく前から Starbucks や McDonald’s で無料の Wifi が提供されていました。Grand Central 駅近くの Bryant Park では長らく Google が無料の公衆 Wifi をやっていましたし、市内に無数にある独立系の Cafe でも最近 Wifi は普通に無料で使えています。旅行者にとっても、New Yorker にしても、無料のネットワークは非常に助かります。

New York 市のデジタル関連の市報は Tumblr にあるんですね…

via NYC is turning payphones into free WiFi hotspots: 10 kiosks launch today

Written by beatak

2012/07/16 at 03:51

カテゴリー: Uncategorized

Tagged with ,

Google I/O 2012発 JavaScript高速化Tips集の日本語訳

leave a comment »

既に「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/

Written by yandod

2012/07/13 at 15:33

カテゴリー: Uncategorized

Tagged with

Apple というブランドと顔

leave a comment »

Apple の成長は目覚ましいものがあります。アナリストの Horace Dediu は Apple の販売員増加について数字と販売戦略を絡めて語っています。

The face and the brand

iPhone が発売されてこの5年間で、直営店の数は 172 から 361 に増え、35,852 もの販売員を雇いました。2007年の第一四半期には平均 37人だった各店舗の従業員数も、5 年後の 2012 年の第一四半期には、177 人に増えています。多くの数字がこのエントリには登場しますが、面白いのは、販売員の増加割合は、アップルストアの訪問客の増加割合より多く、また各販売員が顧客と話す時間は増加している、という事です。

私の知る限り、これはテック系としては非常に珍しい。ほとんどのテック企業では、全く正反対の事を模索してきた:煩雑な販売手順とサポートの手間を手順化して、「付加価値付け」を、(自社ではなく)他人である販売業者に任せる、ということ。
This is, as far as I know, a unique relationship for a technology company. If anything, most technology companies have sought the exact opposite: to put others’ faces in front of customers–to break the messy process of sales and support down into pieces to be outsourced to “value adding” resellers.

私は Harvard Business Review に転載されていたエントリ: Why is Apple Hiring So Many Retail Employees?(タイトルがやや釣り気味)を最初に読んで結論がないと思いましたが、ブランド、という観点に注目すると、非常に面白いと思います。販売員も Apple というブランドを構成する一部なんですね。コメント欄で給料の話なども出ています。

via Why is Apple Hiring So Many Retail Employees? via The face and the brand

Written by beatak

2012/07/11 at 10:05

カテゴリー: Uncategorized

Tagged with

<span>%d</span>人のブロガーが「いいね」をつけました。