参加費用999ユーロ(約10万円)、2泊3日、日時以外の詳細は一切不明のイベントのチケットをあなたなら買いますか？このFunConfは今年で3回目を迎える異色のカンファレンスです。割り切った作りのサイトは実際に見てもらうのが一番として、このカンファレンスの特徴は会場がユニークな事です。第一回は走行中の貸切バス、第二回は城とかなりぶっ飛んでいます。このカンファレンスのクチコミはなかなか温度が高く、筆者も海外のゲストからこのカンファレンスをお勧めされた事が3回ほどあります。

Just bought a @funconf ticket on a complete speculation that I can actually go. The stories have been that legendary. /cc @jperras—
Andrei Zmievski (@a) May 22, 2012

たとえばこのAndrei Zmievski氏はDiggやYahooといったサービスのエンジニアだった事があり、なおかつPHPのテンプレートエンジン、Smartyの元作者であり、お蔵入りになったPHP6の中心人物でした。(しかもTwitterのアカウントが”a”の一文字)また運営しているPaul & EamoのEamon氏はPHPのPaaSサービスのOrchestra.ioのファウンダーでCoderDojoの発起人のJames Whelton氏の友人です。

他の参加者やスピーカーも豪華な顔ぶれである事が予想されますが、真相は参加しないとわからないようです。。。気になりますね。

追記
あまりに謎が多いとの反響があったので画像を検索してみるとやはりすごいです。

2010年のFunConf (バスの車内で開催)

2011年のFunConf (城とデロリアン)

Workspace

今や、いいエンジニアを雇うのに環境や待遇が重要なのは言うまでもないことで、「希望するマシンが支給される」とか「椅子はすべてアーロンチェア」といったフレーズは魅力的です。しかし、そんな華やかなフレーズの裏側に見え隠れする「社内のカルチャー」という本質を理解しないと、本当に素晴らしいエンジニアを惹き寄せることは難しいもの。

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

このインタビューはスタートアップ向けレクチャーイベント ZURBsoapbox シリーズのひとつ。昨年11月に、「サンフランシスコでの投資とギークな日々の20年間」といったタイトルで 500 Startups 代表のエンジェル投資家デイブ・マクルーア氏が語ったものです。

Dave McClure by technotheory, on Flickr

「チームのメンバーに求める特徴は？」という客席からの質問のデザイナーの部分について、彼はこのように答えていました。

一緒に働くのが辛いデザイナーもいた。自分はなんでも知ってる、みたいなデザイナーと働くのにはほんとに苦労した。デザイナーと口論したいわけじゃないんだ。俺が見たいのは数字とお客さんの利用例。そして何がうまくいっているのかを突き止めたい。あんたがありえないほどキレイだ！とか思ってても、何の役に立つ？

eBay ではデザインがヒドいほうが実際はコンバージョン率が良いっていう場合がたくさんあったのはすごくはっきりしてたと思う。多分 eBay の世界のお客さんは節約するためにあのサイトに行ってて、見た目がキレイすぎると値段が高いんじゃないかと思ったのかもね。

社内での一論として、ちょっとくらいとっ散らかってたほうがお買い得に感じられるんじゃないか、っていうのがあった。少なくとも俺の直感はそういうことだった。

これに続けて彼は、「ただのデザイナーではなく、ユーザビリティとコンバージョンに注力できて、プロダクトとプログラマーとうまくつきあっていきながらこういうコンセプトをひねり出してくれるような人材」が必要だ、と言っています。

過去の資産や Web 上の既存 UI に慣れているユーザーを多数抱えている eBay がモバイル対応の舵取りに悩んでいる状況については先日取り上げましたが、そういった状況が存在する以上、マクルーア氏の思い描く理想のデザイナーが増えてきたとしても「2003年で止まっている」ようなサイトはきっとすぐには変わらないでしょう。ただそのことがビジネスに利益をもたらしているのなら、彼の言う「ただのデザイナー」が美しいと感じないビジュアルデザインも投資家にとってはもちろん正しい回答であると言えます。

マクルーア氏も「プリマドンナ（みたいにお高くとまった）デザイナーはいらない」と言っていましたが、自己表現のエゴではなくサイトやサービスの目的に心から共感し、「このサイトが最高にうまく機能するためのデザインをしたい！」という姿勢がデザイナーに求められていくのかもしれませんね。

via Dave McClure’s ZURBsoapbox

追記

1. お察しいただけた方も多かったゆえに反響を頂いていると思うのですがあえて明確にしておくと、ここで「ヒドいデザイン（原文では “shitty design”）」と書いているのは「ビジュアルデザインがキレイではないダサいもの」というような意味です。
2. かっこいいWEBは物が売れるのか | More Access,More Fun! からもリンクして頂きましたがあわせてどうぞ。

iOSとAndroidのクロスプラットフォームなアプリケーションをする際に使われるTitanium MobileとPhone GapをTitaniumの開発元、Appceleratorの開発者Kevin Whinnery氏が比較した記事が話題になっていました。

Kevin氏は「上空1万フィートから見ればTitaniumとPhone Gapは似ているように見える。どちらもクロスプラットフォームでJavaScriptとWebの技術を要求し、オープンソースライセンスを採用している。しかし似ている所はそれぐらいしかない。どちらも思想や問題を達成する為のアプローチは異なっている」という書き出しで二つのプラットフォームがかなり異なっている事を強調した上でいくつかのポイントを比較しています。

Phone Gapについて

• 実現する事
  HTMLベースのWebアプリケーションをネイティブアプリとして配布、インストールできるようにする。
• ワークフロー
  HTML,CSS,JavaScriptを静的なサイトのようにローカルで編集する。ネイティブのツールセットは不要。
• 動作原理
  各プラットフォームのWebブラウザコンポーネント(Web View)などを立ち上げ、作成されたHTMLを読み込んで表示する。
• 拡張方法
  JavaScriptから呼び出されるインタフェースを作成し、そこから呼び出されるネイティブコードを作成して登録する。(How to Create a PhoneGap Plugin for iOS)
• 強み
  Web Viewをサポートしていればどんな環境でも動作する。プラグインによる拡張がシンプル。
• 弱み
  UIのクオリティがWeb Viewのクオリティに依存する。特にAndroidでは制限がある。ネイティブのUIを使った拡張ができない。

Titaniumについて

• 実現する事
  クロスプラットフォームなJavaScriptランタイムとモバイル向けのAPIを提供する。
• ワークフロー
  各プラットフォームのツールをセットアップした後にTitaniumのツールのみ使う。このツールをIDEから利用する事もできる。
• 動作原理
  ネイティブコード上でJavaScriptの実行環境（iOSではJavaScriptCore、AndroidではデフォルトのV8またはRhino）が動作し、JavaScriptのソースコードを実行時に解釈して動作する。
• 拡張方法
  UIを含む視覚的なコンポーネントも拡張できる。ネイティブ側、JavaScript側の双方から呼び出し可能なプロキシオブジェクトを実装し、ブリッジとして利用できる。
• 強み
  高レベルなAPIが提供されていて、さまざまなネイティブの機能を利用できる。
• 弱み
  新たな環境に対応させるのが難しく、iOS、Android、Webにしか対応していない。

元の記事はかなりの長文ですが、Phone Gapが本来はWebブラウザから利用できない機能（カメラやセンサーなど）を使えるようにするという機能はWebブラウザの機能そのものが強化されると意味がないものになる可能性があるなど、若干Titanium寄りに見える部分があります。また双方のプラットフォームの思想的な違いやビジネスモデルについても言及している部分がある点もユニークな内容です。
それぞれのプラットフォームの動作原理の解説は興味深い内容ですので読んでみて頂ければと思います。

さてみなさんはどちらのプラットフォームを使いますか？

訂正
Kevin氏を元開発者と表記しておりましたが、現在もAppceleratorの開発者であるとのご指摘を頂きました。訂正させて頂きます。誤訳により誤解を招いてしまい申し訳ありませんでした。

via:http://kevinwhinnery.com/post/22764624253/comparing-titanium-and-phonegap

A-Listers的にはかなりプッシュしているCoding Horrorに”Will Apps Kill Websites?”と題されたスマートフォン・タブレットのアプリとWebサイトの今後について考察した記事が投稿されていました。記事はeBayが多くに人に使われていて、筆者にとっても有用でさまざまな出来事が起きている事を前置きした上で、「eBayのWebサイトが常に使いづらく閲覧しづらいままだった」事は不変であると述べています。その上でアプリ版eBayとWebサイト版のeBayの比較を行なっています。

タブレット版eBay

筆者によると「eBayのアプリには良くない点もたくさんあるが、Webサイトはさらに最悪」と補足した上でeBayの超熟練ユーザでない限りはWebサイト版を避けるべきであると評しています。教訓として「制約を受け入れる事(embrace constraints)」を挙げています。限定されたUIや限られたスクリーンサイズはMacやPCがパワフルになって失われた強みであるとしています。eBayはWebによくある風土病(endemic on the web)として1999年から機能が増大しつづけ、Webブラウザ上でほとんどなんでもできるようになった結果、ユーザにとっては使いづらいものになってしまっています。
筆者はスケールアップできるシンプルなデザインをせよ、スケールダウンが必要な複雑なものは避けろとしてモバイルファーストのアプローチを取り、どのデバイスでも一貫性を保つように考慮することでシンプルであり続ける事にフォーカスできると説いています。

その上で優れたタブレットなどが存在する今、それでもWebサイトがまだ必要なのかどうかという事を考えるべく、アプリとWebサイトそれぞれが優れている点をリストにして列挙しています。

アプリがWebサイトよりも優れている理由

• より高速
  HTMLやCSSといったオーバーヘッドが無く、ユーザの操作に応じてネイティブUIを高速に表示できる
• シンプルなネイティブUIを使っている
• 画面を有効に使っている
  画面のサイズのバリエーションがPCよりも少ない為、デザインはそれに合わせるさせすれば良い。
• 外出先やオフラインでも使える

Webサイトがアプリより優れている理由

• どのようなデバイスでもブラウザがあれば動く
• インストールの必要が無い
  アプリを探してインストールしたとしても大量のアプリをポケモンのように管理しなければならない。
• アップデートの必要が無い
  Webサイトは常に最新
• 共通のエクスペリエンスを提供できる
  さまざまな種類のUIがあればユーザも提供者側にも負担になる。

筆者はどちらが明確な勝者とは言えず、アプリは常にWebサイトに依存している点に触れた上でアプリに殺されてしまうWebサイトはよほどひどいWebサイトに限られるだろうと結んでいます。元の記事ではここで取り上げていないような点にも触れており、外部記事へのリンクなどもあって気になる方は一読をおすすめします。

via:http://www.codinghorror.com/blog/2012/04/will-apps-kill-websites.html

日本の雑誌などで英語／フランス語などを使ったアルファベットの名前が氾濫しているように、アメリカでも日本語が唐突に使われている事はよくあります。たまにおバカな入れ墨、とか meme 画像で見たことがあるんではないでしょうか。

英語圏のインターネットはその始まりから、日本語を使ってきました。Yahoo の最初のサーバー群は日本の相撲取りから名付けられました。zen とか ninja などはもう完全に英語に定着したと言えるでしょう。求人情報で『急募: JavaScript 忍者』とかは普通にあります。今よく考えてみたら、おかしな話ですね。

というわけで、変な日本語シリーズを初めてみたいと思います。記念すべき第一回は Ruby on Rails アプリのクラウドデプロイ/マーケットプレイスを目指す cloudfuji.com。あんまり情報が web に載ってませんが、価格のページを見る感じだと購読ベースの手堅いビジネスモデルでしょうか。

会社の名前が武士道で、ドメインが雲富士。最初の看板アプリが歓談。非常に気になる存在です。サンフランシスコがベースで、Meetup Group を主催しているようなので、次回 SF に行く際は是非立ち寄ってみたいと思います。

via: Bushi.do is now Cloudfuji.com

• こどもたちにプログラミングを教える CoderDojo Tokyo #1 を開催しました – 僕は発展途上技術者
• 白熱コーダー道場！with James Whelton – エコシステムについて考えるブログ
• CoderDojo Tokyo #1 James Whelton in Tokyo - Togetter

CoderDojo バージョンの Octocat、DojoCat と CoderDojo Tokyo ロゴ。

また、その翌日には下北沢オープンソース Cafe にて CoderDojo 創始者の一人であるジェームズ・ウェルトン（@jwhelton）氏がプロジェクトについての説明や質疑応答を行いました。Ustream での録画もありますが、以下、日本語でご紹介します。

CoderDojo Tokyo 開催までの経緯

• 以前から息子さんと Scratch などでのゲーム開発をやっていた石原さん（@jishiha）と、当サイトに載っていた記事を見て興味を持った OSSCafe の河村さん（@cognitom）が「東京でもやりましょう！」ということになり、#0 と #0.5 を企画・開催。
• 東洋美術学校の中込さん（@daisukenakagome）が同じタイミングでジェームズに連絡をしていたことも重なり、東京で3回目の「道場」として日曜日のイベントを開催。13人の子供に加え、サポートや保護者・見学者として大人も多数参加し、創始者のジェームズもアイルランドから来日。
• CoderDojo Tokyo #1 では Scratch、HTML、Squeak Smalltalk の3ストリーム体制。Codecademy の JavaScript HTML レッスンも使われた。

「CoderDojo おとなの部」でのジェームズと石原さん。

CoderDojo の起源と成長

（一部、CoderDojo のサイトからの説明も加えています）

• もともとプログラミングを独学で勉強していたジェームズが iPod Nano で動画やゲームが使えるようにしたハックで注目を得たのがきっかけで、当時通っていた PBC コーク高校の友人などにコーディングを教え始めた。これが、2011年の初めごろ。
• その後、起業家・慈善事業家であるビル・リャオに出会い、2011年6月、初の「CoderDojo」をアイルランド、コークのナショナル・ソフトウェア・センターにて開催。大きな成功を収める。
• 全世界には70以上、アイルランドの首都ダブリンだけでもすでに23の道場があり、毎週のように各地でイベントが開かれている。すでに200人の子供が空席待ち中とか。
• 今後はコミュニティサイトその他のインフラを整え、Dojo を開きたい人が楽によりよいリソースを手に入れられるようにするための活動にも力を入れていきたいとのこと。

ジェームズのビジョンと姿勢

「高校生の時は勉強もスポーツもできなかったし、ギターもうまく弾けない、でもコーディングが好きだった」というジェームズは若干19歳。学校ではコンピューターのクラスもなかったし、自分で試行錯誤しながら学んできたので、教えてほしいという若者がいたら手を貸してあげたいと思ったとのこと。

生徒のリピート率は全体で7−8割という高い数値だそうですが「また来たい、と自ら思わない子はそれでもいい。学校でパソコンのクラスがあれば落第しない程度の貢献ができたかもしれないし」とも言っていました。そんな彼だからこそ、押し付けがましくなく子供たちの興味をうまく伸ばしてあげる CoderDojo のスタイルができあがったのだろうと納得させられました。運営方法のコツなどは、@yasulab さんの「僕が見聞きしたCoderDojoの運営ノウハウ」という記事にまとめられています。他人に何かを教えてそれをさらに広範囲に共有していくための大事なポイントが要約されているので、IT系勉強会に限らず役に立つ内容ですね。

関連リンクなど

次回は5月13日に「CoderDojo Tokyoのメンターが集まって、これからの作戦会議をしようというイベント」が下北沢にて予定されているようです。他の地域でやってみたい！という方の相談も受け付けているそうですので、興味がある方は Facebook ページからメッセージを送ってみてはいかがでしょうか？

• 「CoderDojo おとなの部」Ustream 録画: その1、その2、その3、その4
• @CoderDojoTokyo Twitter アカウント
• Tokyo CoderDojo Facebook ページ

GitHubの特に重要な機能である「プルリクエスト」の活用方法についてGitHub社内でのノウハウが公式ブログの記事になっていました。GitHubが今回更新をしたAboutページの開発でも2ヶ月の間に10人のメンバーが130のコミットと91のコメントのやりとりがブランチ上で行われていました。
GitHubberによる講演などでもプリリクエストが重要な機能であると強調されているようです。

記事によるとプルリクエストは新しいアイデアについてのディスカッションを生み、協力してくれる人を見つける為のとても良い方法との事で活用するコツとして以下の3つの点を紹介しています。

• プルリクエストはなるべく早く起こす
  プルリクエストは機能についての意見交換をする良いきっかけになります。コードの修正が終わっていなくてもなるべく早くプルリクエストをする事で、最後にまとめてフィードバックをするのではなく発展的にコメントする事ができます。
• プルリクエストはブランチからブランチで
  GitHubでは誰もgithub/githubのフォークを持っていません。同じレポジトリのブランチ同士でプルリクエストを行なっています。
• プルリクエストはマージされなくてもよい
  プルリクエストは簡単に起こして、フィードバックを得たりブランチ上の進捗を追跡できる手段です。もしアイデアの中に良くない部分があればマージせずにプルリクエストを閉じればよいです。GitHubでもいつもそうしています。

GitHubを仕事に活用し、業務の中でプルリクエストを活用する人も増えてきていると思いますが「フォークを作らない事」や「コード修正が終わる前のプルリクエスト」などは目新しいアイデアと言えるかもしれません。ブランチの管理などはみなさんも試行錯誤していると思いますが覚えておいて損はないTIPSと言えそうです。

記事中でも言及されているようにGitHubのメンバーが講演した際のスライドにもコードレビューをプルリクエストで行う方法について解説がありますのであわせてどうぞ。
How GitHub Uses GitHub to Build GitHub // Speaker Deck

via:https://github.com/blog/1124-how-we-use-pull-requests-to-build-github

見出しと画像のとおりですが、我々のfacebookのパスワードは実は3つ存在しているという記事がHackerNewsで話題になっていました。実際に試してみるとfacebookのパスワードはいくつかのバリエーションを正しいパスワードとして受け付けています。

• 自分が決めたままのパスワード
• 自分が決めたパスワードの大文字を小文字に、小文字を大文字に入れ替えたパスワード
• パスワードの1文字目が小文字だった場合はそれを大文字にしたパスワード

理由はみなさんも推測のとおり、CAPSロックが意図せずに入ってしまっているケースやスマートフォンなどで最初の1文字目が自動的に大文字になって入力される場合を許容する為の挙動だと思われます。このような仕様については2011年9月のZDNetの記事でも言及されており、知っている人にとっては既知の情報かもしれません。

皆さんのサービスではこういったパスワード入力間違いを許容するような仕様を実は持っていますか？また他にもこういった挙動をするサービスをご存知であればコメントやツイートでお知らせください。

via:Your Facebook Account has Three Passwords

インターネットユーザやハッカーの為のチャットツールとして長年親しまれてきたIRCのユーザ数が減少してきているという記事がRoyal Pingdomに掲載されていました。2003年と比較して実に60%も指標が減少し、多くのユーザは他のさまざまなソーシャルメディアなどに流入していると考えられます。

記事ではIRCの作者であるフィンランド人で現在はグーグルに努めているJarkko Oikarinen氏へのインタビューも行われています。彼は企業がユーザーのプロフィールなどを自身のサービスの内側に留めるようになった流れなどについて指摘した上でこの状況を変えるような開発者の出現を期待する旨のコメントをしています。

“It does not necessarily require a large team to make significant progress. Just one person can make a huge difference,” Oikarinen says.
“大きな進歩を生むのは大きなチームとは限らない。たった1人の個人でも大きな変化を起こすことが出来る”

3Dバーチャルワールドやマルチメディアなどのなんらかの大きな変化をIRCにもたらす開発者の出現を彼は期待しているようです。

世界最初のIRCサーバ

IRCの利用のシーン自体は小さくなっていますが、IRCがすぐに無くなってしまうとは考えれない(there’s no reason to think that IRC will disappear anytime soon)ともあり、全体が減少している中で順調にユーザが増えているfreenodeの状況なども示されています。元記事にはIRCノードの運営者の意見(DOS攻撃の問題やwarez文化、ソーシャルメディア)が挙げられています。今後、IRCがどういう技術になっていくのかを考えてみるのも面白いかもしれません。

via:http://royal.pingdom.com/2012/04/24/irc-is-dead-long-live-irc/