Archive for the ‘Uncategorized’ Category
New York 市は公衆電話を公衆 Wifi へ。
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
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/
Apple というブランドと顔
Apple の成長は目覚ましいものがあります。アナリストの Horace Dediu は Apple の販売員増加について数字と販売戦略を絡めて語っています。
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
GitHub全体のサマリのレポートサイト – Octoboard
開発者にとって最重要なサービスになりつつあるGitHubの日々の状況を一覧できるサイトが登場しました。その名もOctoboard。日々のコミットやフォーク、プルリクエストの量が平均より多いかどうかなどをリポートしています。
これによると一日あたり10万以上のアクティビティがあり、5000近いリポジトリが作成され、3000以上のIDが登録されているようです。GitHubの規模感を説明する際などに便利な資料になりそうです。
喜びの多いプログラミング言語はObjective-CとPHPと判明
いやいやもっと楽しい言語あるでしょ?と思った方にとっても興味深い調査結果がExploring Expressions of Emotions in GitHub Commit Messages(GitHub上のコミットメッセージの感情表現の調査)として公開されていました。記事の作者はベルリンのRamiro Gómezさんで、自然言語とプログラミング言語の双方に関心のある彼はGitHubが公開した統計情報からさまざまな感情表現をコミットメッセージから探して分析するという調査を行いました。これによりanger(怒り), joy(喜び), amusement(楽しみ) surprise(驚き)の表現が多く使われているプログラミング言語のランキングを生成して公開しています。
怒りの言語はVimL、C、Shell

怒りのランキングではangry(腹を立てる)、annoying(いらいらする)、cranky(酷い)、hate(嫌い)といった単語を抽出し、結果的には2位にダブルスコア近い差をつけてVimLがトップに輝いています。次いでCやShellなどもインストーラーが全てのファイルを削除するといったクリティカルな問題に発展しそうな気配があり、そういうものなのかなという気がします。
しかし何故VimLの人たちが際立って怒っているのかは謎です。
喜びの言語はObjective-C、PHP、Perl

続いて喜びのランキングではyes、yay(やった)、bingo(それだ)、glad(うれしい)といった単語を抽出しObjective-CとPHPが際立って高い結果になっています。どちらもプログラミング言語としては理路整然という訳ではない部分もありそうですが、動く物を作るという行為には直結していそうなイメージがあり、ものづくりを楽しんでいる雰囲気が現れているのかもしれません。
本文では触れられていませんが、怒りの言語でトップであるVimLが最下位に入っている点も見逃せません。
楽しみの言語はRuby、C#、Java

楽しみのランキングでは、lol(笑)、rofl(爆笑)といった笑いのスラングを抽出したところ、RubyとC#が際立って高い結果になっています。また本文では触れられていませんが、怒りの言語の王様であるVimLが最下位にまたしても入っている点も見逃せません。
Rubyが上位に入っているのはコミュニティの発展がGitHub上で達成されているという事なのかもしれません。
驚きの言語はPerl、Objective-C、C

驚きのランキングではgosh(おやっ)、stumped(当惑)、surprised(驚いた)などの単語を抽出し、PerlとObjective-Cが高い結果になっています。またC++とPHPは下位に沈んでいます。
罵りが多い言語はVimL、Objective-C、C

所謂、Disり合いについても分析が行われ、ここではいわゆる罵倒表現達(wtf等)を抽出しています。堂々のトップに輝いているのはVimLです。また意外にもPHPは下位に沈んでいます。なお例として抽出されたコメントが例示されているのですがこの項目についてはとてもストレートな感じでわかりやすいです。
プログラミング言語の人気というのはなんとなく感じる部分はありますが、こういった分析は各言語の成熟度や使われるシチュエーションについて想像する助けになりそうです。この調査の為のコードもGitHubで公開されていますので、フォークして日本語のメッセージで分析したり別の観点のレポートを作ってみるのも面白いかもしれません。
またVimLユーザの怒りの理由についての情報もお待ちしております。
via:http://geeksta.net/geeklog/exploring-expressions-emotions-github-commit-messages/
温泉宿すぎる滞在型 Ruby イベントの会場 in ストックホルム
ブルガリア在住の同僚が6月15日から行われる Nordic Ruby というカンファレンスに行くというのを目にして何気なくリンクをクリックしたのですが、驚いたことに会場が半端なく和風でした。
スウェーデンのストックホルムにあるその施設の名称は、「やすらぎ(Yasuragi Hasseludden)」。Japanese Spa という説明文や写真から見ても、どうやらかなり温泉旅館な施設のようです。
カンファレンスが開かれる会議室の名前は「Fuji」。ディナーのメニューは日本食。イベントのブログには、「パートナーもご一緒にどうぞ」とか「マッサージトリートメントもいかが?」とかいうエントリーもあり、非常に楽しそうな雰囲気です。
Nordic Ruby は2010年から行われているようで、2日間の滞在型イベントとして毎年 Pivotal Labs や Engine Yard、Heroku、Github といったチームからスピーカーを招いています。来年は同じ会場ではないかもしれませんが、スケジュールもなかなか面白そうですし、チェックしてみてはいかがでしょうか?当サイトでも先日取り上げた Funconf といい、ヨーロッパの Tech 系イベントの優雅な方向性には今後も注目して行きたいところです。
過去のイベントの写真は Flickr 検索から見られます。今年は浴衣を着た Rubyists たちの写真が上がってくるのかもしれません。
ソ連の宇宙開発で使われていたプログラミング言語は?
stackexchange.com上のソビエトの宇宙開発でどんなプログラミング言語が使われているのか?という話題で興味深い議論が展開されています。
投稿者は「ソビエトの宇宙開発プログラムの宇宙船ブランでProLogが使われていたのを知りましたが、それ以前でどのようなプログラミング言語が使われていたのか誰か知りませんか?」という質問を投稿します。
それに対して「ソース出せ」というツッコミがつくと、投稿者は公開されたCIAの調査資料にProLogが使われていたと記載があったと返信します。
その後の回答で最も支持されているのはロシア語の書籍「 First computers for space applications (Герман Носкин, Первые БЦВМ космического применения)」を持っている方からの回答です。著者自身が宇宙開発に参加していたという事もありかなり貴重な情報が紹介されています。
- 70年代まではデジタルコンピュータは使われていなかった
- 最初に使われたコンピュータはSalut-4でソ連で利用されていたコンピュータと互換性がありPL-1とFortranが使えた
- またブランでは3つの言語が使われていたとの言及がウェブサイトにあり、オンボード機器には PROL2、地上のテストにはDipol 、Laks がモデリングに使われた。
- ブランプログラムが終わる頃、3つの言語はDrakonに統合された。
なんだか身近でない言葉がバンバン出てくるすごい話です。どうやら最終的に長く使われたDrakonも国際的に認知されておらず、情報がWikipediaにも無い状態との事です。インターネットが発達した現代でもアクセスできる情報はやはり英語のものがせいぜいで、それ以外の言語で書かれた知識は埋もれてしまっている事を考えさせれる出来事です。
GitHubがOctocatのアニメーションを制作中
少し前のGitHub公式ブログにTony Jaramillo氏がGitHubに加入したという興味深い記事を再発見しました。GitHubの公式ブログではメンバーの加入の際には記事が投稿されるのが恒例になっていますが、今回のTony氏はユニークです。なんと彼はアニメーターなんです。この記事でも彼の今後の活動についてはOctocatのアニメーションを制作するとだけ書かれています。そして元記事のリンクをクリックした人はお気づきかと思いますが、この元記事の最初にある画像もアニメーションGIFなんですよ!(動くOctocatは必見)
Tony氏のウェブサイトにもさまざまなアニメーション作品が掲載されています。GitHubのサイトではこれまでもマウス操作に合わせて動いていた部分もありましたが、今後はより可愛らしく動きまわるOctocatが見れるようになるのでしょうか。公開が楽しみですね。
via:https://github.com/blog/1131-tony-jaramillo-is-a-githubber
参加費10万円、説明は一切無しのイベントチケットが好評発売中
参加費用999ユーロ(約10万円)、2泊3日、日時以外の詳細は一切不明のイベントのチケットをあなたなら買いますか?このFunConfは今年で3回目を迎える異色のカンファレンスです。割り切った作りのサイトは実際に見てもらうのが一番として、このカンファレンスの特徴は会場がユニークな事です。第一回は走行中の貸切バス、第二回は城とかなりぶっ飛んでいます。このカンファレンスのクチコミはなかなか温度が高く、筆者も海外のゲストからこのカンファレンスをお勧めされた事が3回ほどあります。
たとえばこのAndrei Zmievski氏はDiggやYahooといったサービスのエンジニアだった事があり、なおかつPHPのテンプレートエンジン、Smartyの元作者であり、お蔵入りになったPHP6の中心人物でした。(しかもTwitterのアカウントが”a”の一文字)また運営しているPaul & EamoのEamon氏はPHPのPaaSサービスのOrchestra.ioのファウンダーでCoderDojoの発起人のJames Whelton氏の友人です。
他の参加者やスピーカーも豪華な顔ぶれである事が予想されますが、真相は参加しないとわからないようです。。。気になりますね。
追記
あまりに謎が多いとの反響があったので画像を検索してみるとやはりすごいです。
退職理由は「転職先のモニターのほうが大きい」から?
今や、いいエンジニアを雇うのに環境や待遇が重要なのは言うまでもないことで、「希望するマシンが支給される」とか「椅子はすべてアーロンチェア」といったフレーズは魅力的です。しかし、そんな華やかなフレーズの裏側に見え隠れする「社内のカルチャー」という本質を理解しないと、本当に素晴らしいエンジニアを惹き寄せることは難しいもの。
NingやVMware、Akamaiといった企業で働いた経験のあるJohn Josef “Sef” Kloningerさんは、Why Quit? Because They Have Bigger Monitorsというブログ記事で、自身の経験を以下のように紹介しています。
退職理由は「転職先のモニターのほうが大きい」から?
以前の職場での話。
私はエンジニアリングマネージャーで、人材確保に関して問題を抱えていた。チームのエンジニアが会社を辞めて、もっと小さい今風の会社に移ろうとしていたのだ。
以下は退職者面接での一幕。
私:なぜ辞めてしまうんだい?
彼:あっちにはもっと大きいモニターがあるんだ。
私:(疑わしそうに)冗談だろう?うちでも君にもっと大きいモニターを支給できるよ。
彼:僕だけじゃない。あっちでは全員が大きなモニターを使っているんだ。
私:それがそんなに重要なのかい?
彼:僕の作業時間というものを彼らがどれくらい重視しているかわかる。彼らにとっては、僕の網膜により多くのピクセルを詰め込むことは、余分な資金を費やすだけの価値があるってことさ。今となっては、これがまったく真実であると理解できる。このように従業員を評価する職場では、設備投資を節約することと従業員の生産性(そして喜び)を比較して考える。最高のエンジニアは、職務のために最高のツールを与えられる。
大きなモニターはそれをあらわすわかりやすいサインだ。
Kloningerさんは、優秀なエンジニアが惹かれる強いエンジニアリングカルチャーというものを「エンジニアが高く評価され、また重要とされている」ことと定義して、意味合いとしては以下のように説明しています。
- 決定までのプロセス − どんなものをいつ誰が作るのかということについて、技術畑の人たちが提案することで決定がなされる
- ソフトウェアを作り上げる技術に対するリスペクト − プロジェクトによっては期間の予測が難しいものもあるが、そういったものも受け入れられる必要がある
- インフラストラクチャーへの理解 − メッセージキューのスケーリングやビルドシステム、バージョンコントロールなどの機能面とは関係のない作業が必要な場合に、その正当性を上司が理解している
こういったカルチャーを面接の場で引き出す・聞き出すことは双方にとって難しく、それは前述のエピソードでもうかがえます。
記事にはもう1つエピソードがあって、こちらは人によってはそれほど気にしないかもしれませんが、社内文化をうかがい知るという部分ではとても興味深い観点だと思います。
自分のメールアドレスを選べる?
エンジニアでない人々は、メールアドレスがどれくらい重要なのかということを正しく理解していないことがある。メールアドレスはオンラインでのアイデンティティなのだ。
厳格な命名規則(ファーストネームとラストネームの1文字目とか、もっとひどいのはラストネームとファーストネームの1文字目)は、エンジニアのハッピーさよりも画一性に価値を置いた職場であることを暗に示している。
それどころか、従業員に自身のことを「クールな個人」ではない「歯車」や「人的資源」のように感じさせてしまう素晴らしい方法ですらある。
(余談:Human Resources(人的資源)という言葉はやめよう。とても不快だ)
私のファーストネームは風変わりなので、この問題は個人的にも重要だ。もしあなたが sef@company.com を使わせてくれないのならば、それは私にとって大きなマイナス点となる。
エイリアスや、メンバーが1人しかないメーリングリストといったダサいもので誤魔化したりもしてはいけない。シェルプロンプトでどのように見えるか、whoami コマンドが何を返すのかが重要なのだ。
ということで、悪いカルチャーから生まれる悪いポリシーによって、あなたの組織が優秀なエンジニアにとって魅力的ではないポジションに位置することになってしまう、というお話でした。
日本でも、エンジニアだからこそ転職時に気になる社内文化の問題っていろいろあるような気がします。オフィス設備だけでなく、そういった部分にもっとフォーカスをあてた採用活動も増えていくといいですね。
via Why Quit? Because They Have Bigger Monitors | sef.kloninger.com














