Apple原理主義者の大坪です。 さて、GoogleI/O2014参加レポート第２弾。Google I/Oがカバーしている内容は、Googleの事業領域を反映しサーバーサイドからクライアントのデザインから、はてまたロボットにいたるまで非常に幅広い。今日はその中から標題のセッション＋別のセッション内容を元に書きます。 ーーー スピーカーはGoogleのシニア User Experience Researcher, Tomer Sharon 氏。まずMITとStanfordのComputer Science卒業生が作った「メモ作成アプリ」を開発したスタートアップ(仮想のものか実在のものかわかりません。少なくとも創業者の写真は別の人がモデルをしていました）がなぜ失敗したかについてその理由を挙げて行きます。 1 They did not fall in love with problem ：問題をよく考えていなかった 彼らは自分たちがメモをとるのに苦労しているところから、サービスを考え始めました。実際に他の人も同じ問題を抱えているか確かめるために、サービスのweb siteだけつくってe-mailアドレスをあつめ、そのことにより「なるほど他の人も電子メールのアドレスを登録するくらいには、問題をかかえているんだ」と考えました。しかしそれ以上自分たちが対象としている問題について掘り下げなかった。 2. learned from friends：友達から意見を聞いた 自分たちの問題認識が正しいか、作ったアプリが売れるか確かめるために７人の友達や家族に意見を聞いたとのこと。しかし聞いた相手が友達であるが故にバイアスがかかっていることに気がつかなかった。 3 listened to users：ユーザの言うことに耳を傾けた ニーズ調査で一番大事なのは「ユーザの言うことを聞かない」こと。そのかわりにユーザを観察するべきだと氏は主張します。 社会心理学の分野では１００年も前から「人間は自分の行動を予測するのが下手だ」と知られている。しかしユーザ調査をする時にはこの事実があまりにも頻繁に忘れられます。氏があげた例は以下の二つ。 1937年に行われた実験。まず学生達に「君たちは試験でカンニングするか？」と聞く。それに対して学生達は回答をする。 その後で、実際にカンニングが簡単にできる環境で試験を受けさせる。すると「カンニングするか」という問いに対する答えと、実際の行動の相関はほぼ０に近かったとのこと。つまり全く関係がなかったわけです。 次に挙げた例は2012年に行われた調査。公衆トイレから出てきた人に「手を洗いましたか？」と尋ねる。すると９９％の人がYesと答える。 しかし実際にはトイレにカメラがしかけられており、行動が記録されていた。実際には男性：３２％/女性：６４％の人しか手を洗っていなかった。 彼らは自分たちが作ろうとしているアプリに関して「これを使いたいですか」「いくらまでなら払ってもいいですか」と質問しました。質問する相手が間違っているという事実に加え、そもそも人間は「自分がこう行動するだろう」と予測するのが下手。だからこういう質問には全く意味がない。 4　Didn't test riskiest assumption；一番重要な仮説を検証しなかった プロジェクトはいくつか仮説を立てて行われるわけですが、その中でも「もしこの仮説がこけると全て駄目になる」というものがあります。それを検証せずにただ製品とかサービスだけ作ってもその仮説が正しくないとわかった瞬間全て駄目になってしまう。 ここで挙げられている例では「スマートフォンの所有者は、メモを取りづらいことが大きな問題であると認識している」というのが最重要な仮説だったわけです。では彼らはそれを検証する努力をしたか？ 5 Bob the Builder mentality：自分が得意なことをとにかくやる 彼らは二人ともComputer Science学科を卒業した人間でしたから、とくかくコードを書いてアプリを作るのが得意だった。それゆえ自分たちが何を作ろうとしているのか、あるいはそれが正しい物なのかを検証するより先にとにかくアプリをリリースしてしまった。彼らにとって「創業」とはコード書きの練習だったのです。 6 Perfectly executing the wrong plan：間違った計画を完璧に実行してしまった 彼らは以下の検証を行うべきでした。 Problem:彼らが想定している問題が世の中に存在しているか Marketing:実際に企業をなりたたせるほど多くの人がその問題を抱えているか Product:その製品（もしくはサービス）は想定した問題を解決できるか 氏は実際にスタートアップ及びベンチャーキャピタル１５０社にインタビューをしたそうです。彼らはこうした検証を行う為に何を聞くべきかを「知って」はいたのですが、そのやり方には問題が多かった。 ・12%の会社は "user experience"の定義を知らなかった ・86%のスタートアップはは創業者が個人的に感じている「苦痛」からスタートしていた。ちなみにユーザスタディから最初に解くべき問題を見つけていたのは2%. ・そもそも「解くべき問題は何か」というところからスタートした人はほとんどいなかった ーーー ではどうすれば良かったか？ここで氏は"Lean User Research"を提案し、具体的に三つの手法を取り上げます。 手法その１：experience sampling 1950年代に開発されたPager Study:ポケベル調査が元とのこと。被験者にPagerを配り一日に何回も同じ質問をしてリアルタイムに回答を集める。その回答結果を利用して被験者の行動を理解する。実際に公演中に出された質問は "What was the reason you recently used a piece of paper to write something down?" 最近紙に何かを書いた時に、なぜそうしたか理由を教えてください というものでした。もし１００人の被験者に対して一日に５回、５日間この質問をしたちすれば、2500の回答が集まることになります。 この際重要なのは質問の仕方で ・はい/いいえで答えられる質問は駄目 ・数を聞くのは駄目。その結果を平均しても意味は無い ・「意見」を聞くのではなく、実際の行動を聞く ・一分以内に答えられる質問にする 具体的に良い質問の例は 最近webサイトをアップデートした理由はなんですか？ 駄目な質問の例： 過去一時間に何通メールを受け取りましたか？ GoogleではこのExperience Samplingのために PACO を使っているそうです。 これによってユーザのニーズ、特徴、苦痛に思っていること、うれしいこと等を知ることができる。 手法その２：observation　観察 ここでは観察の手法がいくつか語られましたが、面白いと思ったところだけ。 「問題」というと例えばタスクを邪魔する物とかうっとうしいと思っているものに関して観察すると思いがちですが、氏はDelight：何を楽しいと感じるかを観察することも重要だと強調していました。 またもう一つおもしろいと思ったのが transitions:具体的には、会議が終わった後、次の会議室に行く間にその人は何をしているか？スマホを開いて何をしているか？こうしたTransitionの最中に何をしているかを観察することは、その人のニーズを知るのにとても有効だと言います。 手法その３；fake doors あちこちで講演を聴いていると、Webサービスの場合、本サービスができていなくても予告ページだけ作るのは結構よく行われているようです。先ほどのスタートアップでも実際に予告ページを作り「メールアドレスを集める」ことでニーズを推し量ろうとしました。 しかしそうではなく「＄５払えば、アプリができたとき真っ先に入手できます」とやるべきであったと。メールアドレスを渡すというのもある程度の「覚悟」を示すものではありますが、それよりは実際に＄５払うだけニーズを感じているか調査したほうが遥かに良い、と。 ＾＾＾ 講演の最後に 「映画にでてくるヘリコプターがどうなるか」 という円グラフが表示されました。100%の確率で爆発する。ほとんどのスタートアップは「ユーザニーズを調査している時間はない」といいますが、間違った計画を立ててしまえば、プロジェクトの運命は映画の中のヘリコプータと同じだ。正しい計画を実行しよう、と強調して講演が終わりました。 この講演の内容を文字にしてみると「興味深い」と思う自分と「それだけでは足りない」と思う自分の両方が存在していることに気がつきます。例えばFake Doorを作って「実際に＄５払うことでユーザニーズを確認する」ことはできるかもしれません。 じゃあ例えばiPhoneの宣伝文句だけ書いて「この製品が欲しい人は＄１００振り込んで」とやってニーズの確認ができただろうか？私のようなApple原理主義者でさえも実物のiPhoneを観る事無しに＄１００振り込むことはしなかったと思います。そもそもAppleはユーザ調査に時間も金をかけない（らしい）会社ですがその製品は実際に登場すると人々が「こんなのが欲しかったんだ」と思えるものになる（ええ、私は自分の偏見をある程度自覚していますよ） 大ヒットする製品というのは、ユーザが自覚しておらず、「あたりまえ」と諦めている不満を解消する製品ではないか、と最近考えています。はたしてそうした製品のニーズを製品なしに確認することが可能でしょうか？ などとApple原理主義者がAppleを例にとって考えても公平性を欠く。では、 Weebly の成功物語にこの講演の内容はどう適用できるだろうか。とかなんとか考えるネタはつきないわけです。と放り出したところで今回はおしまい。 Lean User Researchのサイトは http://www.leanresearch.co 本講演のビデオ（半分）は

こんにちは、リッテルラボラトリーの清田です。 現在、巨大なWebログデータを活用して、ユーザーの潜在的なニーズを解析するという取り組みが盛んにおこなわれています。ネクストでも、HOME'Sのログデータを主な対象として、住まい探しのユーザーのニーズをとらえてサイト改善や情報レコメンデーションに活用するための取り組みが進められています。 「Webログデータ活用の最前線にはいないけれども、巨大なWebログデータがどういうものかを知りたい」「巨大なWebログデータを実際に触って分析してみたい」と思っている方もおそらく多いのではと思います。Webで検索すると、HadoopやAmazon Elastic MapReduce（EMR）によるログデータ解析を企業内で活用している事例はたくさん見つかります。しかし、大規模なWeb情報サービスを展開している企業に在籍していない方にとって、そのようなデータはなかなか手に入らないというのが現状ではないでしょうか。 Webを研究対象としている大学の研究室でも、「どうやって巨大なWebログデータにアクセスするか」は大きな問題になっています。 WSDM というWebデータ活用に関する国際会議での 発表論文 を調べてみると、大学の研究者と企業の研究者による共同研究が多いことがわかります。ほとんどの場合、大学と企業の共同研究では、大学と企業が何らかの秘密保持契約を結んだ上でデータの提供が行われています。日本でも、たとえば国立情報学研究所（NII）を通じて提供されている データセット があり、Yahoo!、楽天、ドワンゴなどの企業が研究者向けにデータを提供しています。 ただ、「まずは触って試してみたい」というニーズでは、契約手続きなどはちょっとハードルが高いかもしれません。そこで今回は、「巨大なWebログデータのうち、だれでも手続き不要で自由に利用できるものがないかどうか」というテーマを扱います。 巨大データの公開の取り組み 「ソフトウェアを誰でも自由に利用できるようにする」というオープンソースの概念はすでにおなじみかと思います。近年は、オープンソースの概念は 文章・画像などの創作物 や ハードウェア 、そして データ にも広がってきています。とくに、政府や地方自治体がもつ統計情報（人口・経済など）や、科学研究に利用されるデータ（気候予測・ヒトゲノム情報など）の公開・利用はずいぶん進んできました。 Amazon AWS でも、誰でも自由にアクセスできるさまざまなデータをホストする仕組みとして、 Public Data Sets が提供されています。AWS Pubic Data Setsの リスト にアクセスすると、宇宙科学、生命科学、化学、気候学、経済学などの分野でさまざまなデータが公開されていることがわかります。 しかし、AWS Public Data Setsには「Webログデータ」に相当するデータはほとんど見当たりません。そもそも、世の中に「自由に使える巨大なWebログデータ」というものはほとんど存在しないようです。いったいなぜでしょうか？ Webログデータを公開するリスク Webログデータを研究用途などに利用できるようにしようという取り組みは過去にいくつかありました。代表的な例が、AOLが2006年に公開した AOL Search Query Logs です。AOLは、非商用の研究利用に用途を限定して、50万ユーザーの3ヶ月間（2006年3月〜5月）の検索ログデータをWeb上で公開しました。 しかし、AOLはこの件でたくさんの抗議を受けてしまい、 すぐにこのデータを取り下げてしまいました 。検索ログデータ中にユーザーのプライバシーに関わる情報が含まれているというのがその理由でした。（AOLはすぐにデータを取り下げたものの、多くのコピーがいまも出回っているようです） AOLが公開したログデータには、ユーザーを直接特定できる情報（ユーザーIDやIPアドレスなど）は含まれていませんでした。しかし、検索クエリーの中にはユーザーを間接的に特定しうる情報が含まれていることが問題になってしまいました。たとえば、「自分の名前」で検索したユーザーがいた場合、特定できてしまう可能性があります。この事件の顛末を知りたい方は、 英語版Wikipediaの記事 などをチェックしてみてください。 AOLの件に限らず、プライバシー情報を含む可能性のあるログデータを共有する際には、細心の注意が求められます。プライバシー情報を含むデータを、個人のプライバシーを侵害せずに共有・活用するにはどうしたらよいかは、プライバシー保護データマイニング（Privacy-Preserving Data Mining, PPDM）という分野で盛んに研究されています（PPDMについては、また別の機会に紹介したいと思います）。 Wikipediaアクセス統計の最新データをElastic MapReduceで使えないか？ 残念ながら「手軽に利用できる巨大なWebログデータ」というものはなかなか手に入らないのが現状のようです。しかしながら、Webログデータそのものでなくても、「巨大」かつ「最新」で、「世の中の動きを反映」して、「Elastic MapReduceなどで簡単に使える」ようなデータがあれば、巨大なログデータを触る面白さは体験できそうです。 Wikipediaのアクセス統計データ は、そのような条件をある程度満たすかもしれません。前述のAWS Public Data Setsにも 同じデータ が含まれています。ただ、S3ではなくEBSスナップショットでの公開なので、Elastic MapReduceではちょっと使いにくそうです。また、できれば最新のデータで試したいところですが、あいにく2010年現在のデータであり、更新されていないようです。 もしWikipediaのアクセス統計データの最新版がAWS S3上にあれば、そのような条件をある程度満たせるのではないかと思っています。たとえば、「直近で話題になったキーワード」や「特定の話題（たとえばW杯）の言語圏別での盛り上がり方の違い」などがEMRで解析できれば、いろいろと面白い結果が得られそうです。 現在、Wikipediaのアクセス統計データのS3上での公開の準備を進めています。次回以降の記事で、データの利用方法や、実際に解析してみた結果などを紹介していきたいと思います。ご期待ください！

Apple原理主義者の大坪です。 先日Google I/Oに参加するチャンスを得ました。Apple主催のWWDC2014ではなくGoogle I/Oです。何故Apple原ry)が？と問うのであれば、抽選の神様に聞いてくださいとしか答えようが無い。いくら私がAppleを愛していようが、さいころの目が「否」とでればWWDCに参加することはできない。何かの気まぐれでGoogleがふったサイコロが「正」と出ればそちらに参加する権利が得られる。細かいことは抜きにしてとにかく行くのです。そして行ったのです。ああ、世の中にこれほどGoogle Glassの装着率が高い場所が他にあるだろうか。（下の写真の黄色矢印は全てGoogle Glass) さて、今回はエンジニアリングにもデザインにも全く関係ない話を書きます。初日のキーノートで何が起こったのか。 ーーー Google I/Oの公式サイト に行くと、初日のスケジュールはこんな感じになっています。 Breakfast: AM7-AM9 Keynote: AM9-AM11 Lunch/Code Labs/Sandbox: AM11- 今回Google I/O初参加の私は 「そっかー。初日でも朝ごはんがあるんだ。貧乏人にはありがたい。では早めに行き、朝ごはんを食べてKeynoteに臨もう」 などと考えておりました。 さて、会場が近づいてきたけどまだ午前６時４５分。少し早くついちゃったかな、と思いながら会場についてみれば長蛇の列が。ああ、やはりKeynoteとはこういうものなのね。 後から知ったのですが朝食用の列は別にあったとのこと。当時の私はそんなことなどつゆ知らず目に入った入場用の列にひたすら並ぶ。前で話している人たちは英語であれこれ、後ろにいる一団は中国語でしゃべっています。暇だからネットで何か見ようかとも思うわけですがあまりに電池を使って肝心な時に電池切れになっても困る。ヒマだ。 などと思っているといろいろな人達が巡ってきます。まず背中にタンクを背負った 「コーヒーいかがっすかー（意訳）」 の人たち。長い間列に立っていると、体がだんだん冷えてくる。熱いコーヒーが欲しくなるところですが、トイレに行きたくなっても困る。一人だし。というわけでコーヒーは我慢。無料だけど。 次に巡ってくるのが、 「ドーナッツいかがっすかー（意訳）」 の人たち。彼女たちが押すワゴンには色とりどりのドーナッツが乗っている。いくつか手に取ります。無料だから。朝から何も食べていないので、ありがたいのですが米国特有（と私が思っている） 「甘さは正義」 のドーナッツは、あまり個数を食べることができません。 時計は８時をまわりましたがまだ列が動く気配がない。 一歩引いてこの状況を考えなおしてみましょう。ここにいるのは、時間と金を使ってまでSan Fransiscoに来よう、という気合いのはいったNerdとDesigner達。それが何千人もひとつところにとどまって暇を持て余している。これほど費用がかからず、たくさんのNerdに接触できる機会はない。というわけでいろんな会社のリクルート関係の人も回ってくる。 会社の名刺を配って何やら話している人たちもいるのですが、今回一番ありがたかったのはTarget(米国のディスカウント百貨店チェーン）の人達。なんでも 「テクノロジーチームで採用中」 とのことで、リクルート担当の名刺＋チョコレートバー＋モバイル用のバッテリーを無料で配ってくれる気前の良さ。名刺を渡すとさらにShero2.0が当たるチャンスが！ということなのですが、Targetが東京にオフィス持っているわけないので名刺を渡すのは思いとどまりました。下の写真はもらった物一式。 ここまでで１時間半以上寒い屋外に立っていることになります。最初は半袖姿だったまわりの人たちも上着を取り出して着込んでいます。 時計をみれば８時半を過ぎ、列はようやく少しずつ動きだす。そのころには列は長く、長くなりMoscone Centerを２重に取り囲んでいる。これだけの人数がたったあと３０分で入場できるものだろうか？そんなことを考えていると、隣の駐車場にこんなバナーを掲げる一団が。 ううむ。Don't be evilというのは何かと話題になるGoogleのスローガン。こうしてわざわざバナーを掲げる人が出てくるところはやはりアメリカだよなあと思ったりもします。日本だとハンドマイクもってビラ配るイメージですか。 さて、そのあと列はどどとっと動く。おそらく朝食を食べたのであろう人たちが一階にいますが、そのままキーノート会場に行けるわけではないらしい。その人達が会場横の出口からでてきて、列に混ざる。これがいいことかどうかわからないのですが、セキュリティの人たちが止めにはいる。 一旦会場に入ると、そのままエスカレーターでキーノート会場まで一直線。椅子に座るとほっと一息。そのうち「もうすぐキーノートが始まります」とアナウンスがありますが、まだ空いた椅子がいっぱいあり、次から次へと人が入ってくる。 そのうち舞台上で巨大「ピタゴラ装置」が動き出しキーノートが始まる。しかし人はまだまだ入ってきます。結局入場する人の列が止まったのは９時４０分頃だったように記憶しています。 ーーーー プレゼンテーションが始まってしばらくたったところ、何か妙な声が聞こえる。こういう時最初は何が何やらわからないものですね。どうやら誰かが何かを叫んでいる。会場のセキュリティ関係者がわらわら移動していくとやがて静かになり、やれ落ち着いたと思っていたらもう一人でてきたのには驚きました。後で調べれば Protester だったとのこと。 そうしたハプニングもありながらもキーノートは様々なトピックをカバーする。それは日頃Androidに触れることの少ない私にも興味深い内容なのですが、ちょっと長すぎるのではないか。時計を見れば１１時を過ぎているのですが終わる気配がない。ぼつぼつ席を立つ人も目立ち始めました。もし１１時からのイベントに参加したければ抜けなくてはならない。理解はできるのですが、キーノートといえばWWDCのそれしか体験したことがない私にとって、途中退席する人がいるのは驚きでした。 最後から２番めに登壇した人が"Next"という度に絶望感が深まる。そろそろお開きにしていただけませんかねえ、と思ったところでみんなお待ちかね、おみやげの発表です。最初はCardBoard。なんだそれは？ 「これはGoogleのEngineerが20%枠でつくったものだが」 とか説明はいいのですが、正直なんのことかわからない。次にアナウンスされたのがAndroid Wear のプレゼント。キーノートで３種類のWatchが発表された時の会場の反応は、私の主観ではこんな感じでした。 ・LGは今日から→パチパチ ・サムソンも今日から→ちょっと微妙な反応 ・Motorolaの丸いのは今年の夏から→えーっ（落胆の声多数）。 でもってLG or サムソンを今回渡し＋Motorolaは発売になり次第「可能な国に対して」プレゼント。ををこれはすごい。 と参加者のテンションが上ったところでキーノートはお開き。会場を出たところではCardBoardを配っている。見たところAmazonの箱のようなダンボール。それを組み立てた時に何ができるか理解できたのはかなりたってからでした。 ーーー こうしたカンファレンスのキーノートをどのように行うかは、企業によって様々だなと実感しました。私が面白いと思った記事を以下に引用します。 Now imagine if Apple held a WWDC keynote like this, and the shit storm that would ensue. The reactions would be apoplectic. There’d be pundits calling for Tim Cook to be fired. 引用元： Daring Fireball: Mike Wehner on Today's Google I/O Keynote てきとうな訳：もしAppleがWWDCでこんなキーノートをやったらどんな反応になるか想像してみよう。恐ろしいことになるに違いない。Tim Cookを首にしろ、という声が巻き起こるだろう。 さて、その後には興味深いセッションが続いたわけですがその内容については以下次号（ちゃんと次号はでるのか）

こんにちは、上津原です。 前回はHTTP通信をしましたが、今回は同時によく使うであろうJsonのパースです。 Jsonのパースも、実はBluePrintで実装することができず、C++で実装する必要がありました。 なので再びAnswerHubを漁り、なんとか動いたので記事にしておきます。 今回はローカルにあるJsonファイル 前回HTTP通信をしましたが、今回はローカルです。なのでローカルからデータを読み出すコードも合わせて公開します。 gist435e728d81e751b66df0 読み込んでいるJsonファイルは以下です。 gist60688c55ae7be685325b ちょっとした解説 Jsonはパースという名前ではなくて、シリアライズ、デシリアライズという名前で管理されています。 シリアライズ：JsonObjectからテキストへ デシリアライズ：テキストからJsonObjectへ という感じです。今回はテキストからJsonObjectへ変換するのでデシリアイズを行っています。 まだ不明なポイントとしては、 TArray<TSharedPtr > objArray = JsonObject->GetArrayField(TEXT("Entries")); の部分です。 Arrayのオブジェクトを取得するのに無名のArrayを利用しようとしたのですが、いまいちやり方がわからず連想配列で名前を付けてやると取得ができました。 注意点 パッケージ化したときにSavedディレクトリ内には、置いておいたJsonファイルはなくなってしまってました。きちんと永続化したい場合は別の手段をとった方がよさそうです。今回はその必要がなかったのでそこまで調べていませ。 HTTP通信と組み合わせれば、API取得・パースができる！ 前回のHTTP通信と組み合わせればよくあるAPI問い合わせができるようになると思います。 ここからBluePrintに利用したければ、Arrayに入れて、UPROPERTYしてやれば活用ができます。

Origami原理主義者の大坪です。IDEOがAvocadoを発表したぞーと 書いた のはいいのですが肝心な「どうやって使うか」が書かれていないではないか。またまた言いっぱなしでいいのだろうか、いやよくない。 というわけで、SimpleExampleの精神に則り「簡単なことは実用性よりも重要である」というポリシーの元（いつそんなポリシーができたのだ）とにかく簡単にAvocadoを使ってみます。 今回の完成形はこれです。 いや、こんな一覧と詳細画面の移動だったらOrigamiでもできるではないか、とは言わないでほしい。確かにできるのですが、Avocadoを使えばさらに簡単に、、、、、（ゴニョゴニョ） 語尾が曖昧になっているのが気になりますが、気にせず説明を始めます。 というわけで、 第一回目の記事 を参考にして、下の図までつくりましょう。 今までとどこが違うかわかりますか？Phoneが(Avocado）になっている。何がどう違うのかわかっていませんが、とりあえずこうしておきます。Render in Imageの下のほうをダブルクリックして中にはいりましょう。 Patch Libraryを開き"Master Detail"を探してEditorに追加 Githubからファイル をダウンロードして、assetsフォルダにある２つの画像ファイルをEditorに追加。Layerが接続された状態で追加されますが、今回このLayerは削除します。 masterのイメージを"Master Detail"パッチのMaster Imageに、detailのイメージを"Detail Image"に接続する。 この段階で、Editorはこんな風になっているはずです。 ここでViewerを見ると、masterかdetailかどちらかが表示されている。いくらその上でクリックしても動きません（何も作ってないのであたりまえです）。Master Detailパッチを選んだ状態でPatch Inspectorを開き、Switch to DetailとSwitch to Masterのチェックボックをつけたり外したりしましょう。するとViewerの中で画像がMasterになったりDetailになったりします。 というわけでここからやるとは「画面の特定の部分をクリックしたら、これらの入力をonにしたりoffにしたりする」ことです。いつまでもPatch Inspectorでチェックボックスをつついていたい気持ちをぐっと抑えて（誰もそんなこと考えませんか？）次の手順に進みましょう。 というわけで次にやることは、「お決まりのパターン」の追加です。Button, Interaction2そしてSwitchを追加し以下のように接続します。 Buttonの左上をInteraction2の右上に Interaction2のClickをSwitchのFlipに SwitchのOn/OffをMaster DetailのBack to Masterに この状態では、画面の真ん中に「どん」とButtonが存在し、それをクリックすると画面がDetailからMasterに変わります。しかしそれっきりで反対方向には移動しません。 というわけでさらに一工夫します。 Logicパッチを追加。 追加したLogicパッチを選択、Patch Inspectorを開き、Operationを"NOT"にします SwitchのFlipからLogicパッチの右側（上でも下でもいいです）に接続 Logicパッチの左側からMaster DetailのSwitch to detailに接続 ここまでやるとEditorはこんなになります。 これで画面の真ん中のButtonを押せばそのたびにmasterとdeitalが切り替わる。あー長い道のりでした。はい、おしまい。 などと暴論を吐くのでいい加減なエンジニアは困ります。（”エンジニアがいい加減”なのではありません。私が”エンジニアの中でも特にいい加減な人"なのです）というわけでButtonをちゃんと配置しましょう。Buttonパッチを選びPatch Inspectorを開いて、、 Anchor PointをTop Centerにします。 Widthを640,Heightを120 Corner Radiusを0 Titleをブランク ここまでやると、ボタンが白い四角になっています。この位置でいいと思ったら最後に Background Colorを選び、Opacityを0%にする 最後の手順でボタンが透明になります。今度こそおしまい。そりゃMasterから移動する際に一番上を押した時しか反応しないのってどうなのよとかいろいろいいことはあるかもしれませんが、 「細かい事を気にしない」 というのはとても大事なことです（何をえらそうに） というわけで簡単に移動ができたのですが、たとえば来る時と戻る時で反応する領域を変えようと思ったら、話はとたんにややこしくなります。となるともう一階層を作って、、というわけでAvocadoのExamplesにあるMessaging app.qtzと同じようなことになるわけです。 あと画面遷移の時間を変えるのってどうやるんだろう、、とか考え始めると「簡単にできます！」という文章の語尾が ゴニョゴニョ になってしまう。毎度のことながら 「素材はフレキシブルだけどそこから作るの大変だよね」 と 「大分組みあがった部品は使い道がぴったりだと便利だけど、柔軟さに欠けるよね」 のバランスを取るのは難しい。しかし今は選択肢が増えたことを喜びましょう。と優等生的に前向きな言葉でまとめたところで今回はおしまいです。

こんにちは。菊地と申します。 今回は AndroidStudio で導入された Build Variants という仕組みについてです。 AndroidStudio がリリースされてだいぶ経ちますので、今更な感じはしなくもないですが、意外と知らない人も多いかな？と思ったのでまとめてみました。 はじめに AndroidStudio では既存のビルドシステムである Ant に代わって、 Gradle が採用されています。ビルドの設定は build.gradle というファイルに記述していきます。 build.gradle に記述できる内容は多岐に渡り、様々なことが可能となっています。 例えば debug ビルドと release ビルドで APK を区別したい！ AndroidManifext.xml に記述する permission を release ビルドには記述したくない！ Google Maps Android API v2 の API Key を debug と release で切り替えたい！ 同じソースコードから広告あり版と広告なしのアプリをビルドしたい！ こんなことができたらいいと思ったことはありませんか これらは Build Variant を使うことで解決することができます。 Build Variants とは？ 公式によると Build Type + Product Flavor = Build Variant Build Type と Product Flavor ってなに？？？となりますよね。 そこで、 Build Variants を理解するために必要な Build Type と Product Flavor についても理解する必要があるため、簡単な例とともに説明します。 Build Types Build Types はビルドの種類のことです。 ビルドの種類毎にプロパティを設定することで、個別に設定を反映することができます。 デフォルトでは自動的に debug と release という2つのバージョンをビルドします。 (今回は説明のために debug と release を記述しています) android { ... defaultConfig { ... } buildTypes { debug { ... packageNameSuffix ".debug" } release { ... } } } buildTypes の中に debug と release の2種類が書かれています。 debug に対して packageNameSuffix ".debug" を設定しました。 packageNameSuffix は packageName の末尾に指定文字列を追記するものになります。 こうすることで、 debug ビルドの場合に packageName の末尾に .debug が付与されるため、一つの端末上で debug ビルドと release ビルドの APK が共存可能になります。 ちなみに、設定可能な property は以下のようなものがあります。 詳細については今回は割愛させていただきます。 Property name Default values for debug Default values for release / other debuggable true false jniDebugBuild false false renderscriptDebugBuild false false renderscriptOptimLevel 3 3 packageNameSuffix null null versionNameSuffix null null signingConfig android.signingConfins.debug null zipAlign false true runProguard false false proguardFile N/A(set only) N/A(set only) produardFiles N/A(set only) N/A(set only) Sourcesets デフォルトではビルド対象となるソースコードは src/main になりますが、 buildTypes 毎にビルド対象となるソースコードを分けることもできます。 buildType が debug のとき src/debug が存在する場合は配下にあるソースコードもビルド対象 buildType が release のとき src/release が存在する場合は配下にあるソースコードもビルド対象 Dependencies デフォルトでは Compile , Provided , APK , TestCompile の4種類が指定可能ですが Build Type を設定したことにより Build Type 毎に Complie を指定できるようになります。 android { ... } dependencies { compile '' provided '' apk '' androidTestCompile // debug build だけの依存関係 debugComplie '' // release build だけの依存関係 releaseComplie '' } Product Flavors Product Flavors はアプリケーションのビルドをカスタマイズしたものを作るための仕組みになります。 有料版と無料版のビルドを１つのプロジェクトから行ったりといったことが可能になります。 android { ... defaultConfig { ... } productFlavors { development { ... packageName "jp.co.next.development" } production { ... packageName "jp.co.next.production" } } } Source デフォルトではビルド対象となるソースコードは src/main になりますが、 buildTypes と同じ様に productFlavors 毎にビルド対象となるソースコードを分けることもできます。 productFlavor が development のとき src/development が存在する場合は配下にあるソースコードもビルド対象 productFlavor が production のとき src/production が存在する場合は配下にあるソースコードもビルド対象 Build Variants BuildTypes と ProductFlavors について、どういったものかがわかったところで、本題である Build Variants についてもみてみます。 Build Type + Product Flavor = Build Variant Build Variant 　は Build Type と Product Flavor の組み合わせ毎にビルドを行うものになります。 Build Variant 毎の タスク名 および ソースディレクトリ名 は以下のようになります。 Build Types Product Flavors タスク名 debug assembleDebug release assembleRelease debug development assembleDevelopmentDebug release development assembleDevelopmentRelease debug production assembleProductionDebug release production assembleProductionRelease Build Types Product Flavors ディレクトリ名 debug src/main + src/debug release src/main + src/release development src/main + src/development production src/main + src/production debug development src/main + src/developmentDebug release development src/main + src/developmentRelease debug production src/main + src/productionDebug release production src/main + src/productionRelease ※ AndroidManifest.xml が複数存在する場合は内容がマージされます src/main/AndroicManifest.xml には Activity などを共通的なものを記述し debug ビルドでのみ必要となる permission などを src/debug/AndroidManfest.xml に書くといったこともできます <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="jp.co.next" > ... <application android:allowBackup="true" android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme" > <activity /> </application> </manifest> <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="jp.co.next" > <uses-permission android:name="android.permission.ACCESS_MOCK_LOCATION"/> </manifest> Google Maps Android API v2 の API Key などを src/debug/AndroidManifest.xml と src/release/AndroidManifest.xml でかき分けておくと便利！ <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="jp.co.next" > ... <application android:allowBackup="true" android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme" > <meta-data android:name="com.google.android.maps.v2.API_KEY" android:value="debug用のAPIキー"/> <uses-library android:name="com.google.android.maps" /> </application> </manifest> <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="jp.co.next" > ... <application android:allowBackup="true" android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme" > <meta-data android:name="com.google.android.maps.v2.API_KEY" android:value="release用のAPIキー"/> <uses-library android:name="com.google.android.maps" /> </application> </manifest> まとめ 今回は、簡単にですが Build Variants ってなに？どんなことができるの？という点についてまとめてみました。 さて、冒頭で例にあげたこと。もうやり方はわかっているとは思いますが、まとめておきます。 debug ビルドと release ビルドで APK を区別したい！ Build Type 毎に packageNameSuffix を設定する Product Flavor 毎に packageName を設定する AndroidManifext.xml に記述する permission を release ビルドには記述したくない！ Build Type を使って src/debug/AndroidManifest.xml にだけ permission を追記する Google Maps Android API v2 の API Key を debug と release で切り替えたい！ Build Type を使って src/debug/AndroidManifest.xml に debug key , src/release/AndroidManifest.xml に release key を設定する 同じソースコードから広告あり版と広告なしのアプリをビルドしたい！ Product Flavor を使って ソースコードをわけたりライブラリの依存関係を設定する おまけ Google Play Developer Console に APK をアップロードする際にデバッグ可能な APK をアップロードしました。」と言われた！ Build Variants の値が Debug になっていないかを確認してください。 Build Variants ってどこでみれるの？ AndroidStudio の View > Tool Windows > Build Variants からみれます。 Module Build Variant next debug

こんにちは。新卒で今年からiOS開発グループに配属された石田です。 はじめに 　私はiPhoneアプリ開発経験がなく、これからObjective-Cを勉強していこうと思っていた矢先に、WWDC2014にて新言語Swiftの発表がありました。そんな新卒の視点から、先日弊社で開催されたSwift勉強会の模様をお伝えします。 開催までのいきさつ 　Swiftの発表にはiOS開発グループの先輩も驚いたようですが、さすがエンジニア。いち早くSwiftを習得しようと、まだ情報が少ない中、開催予定の勉強会に参加しようと盛り上がっていました。さまざまな勉強会の情報を見ていくうちに、「自分たちで勉強会を開催してLTも行えばより勉強になるのでは？」、という話になり開催が決定しました。発表された直後でホットな話題ということもあり、「やるなら早いほうがいいよね」ということで発表から1週間後の6月11日にSwift勉強会を行うことになりました。 開催概要 　第1回Swift勉強会@ネクスト 　イベント告知: http://connpass.com/event/6780/ 18:30 - 19:00 受付 19:00 - 19:10 はじめに 19:10 - 20:00 LT 20:00 - 21:30 情報交換会 LT1本目 「複数人でSwift開発をするときに気を付けるべきと"個人的に"思ったこと」（ネクスト枠　藤原さん） 　iOSでの開発の経験が浅い人向けに、複数人でSwift開発するときに気を付けるべきことをまとめたLTでした。発表者の藤原さんは、PHP等を用いた開発を長年やってきた経験をもとに、Swift開発で楽になりそうなところ、それゆえにプロジェクトで開発するときに困りそうなことを述べてくれました。classとstruct、varとletの使い分け、依存関係の分かりやすいクラス設計など、これから意識していく必要性を強く感じました。 LT2本目 TitaniumユーザーがSwiftを触ってみたら（外部枠　宮下さん） 　Titaniumという、JavaScriptでiPhoneアプリやAndroidアプリが作れてしまう開発環境があるそうです。私はこのLTで初めて知りました。かつてはiPhoneアプリを作るならObjective-C, AndroidアプリならJavaと選択肢が限られていたのですが、TitaniumやSwiftといった別の選択肢が出てきており、開発環境の幅が広がってきているようです。これらの代替ツールの利点と欠点を分かりやすく発表していただきました。お忙しい中、本当にありがとうございました。 LT3本目　 Optionalの使い方（ネクスト枠　成田さん） 　Swiftで追加されたOptionalという機能についての技術的なLTでした。"Optionals are an example of the fact that Swift is a a type safe language"(訳：OptionalはSwiftが型安全な言語である事実の一例だ)という公式ドキュメントの文から始まりました。　Swiftでは通常の型にnilは入れられないのですが、Optionalを指定するとnilの代入が可能になるというものです。デフォルトでは型は厳格に設計されており、宣言の際に「?」をつけるとOptionalに、「!」をOptional型に付けると解除されるようで、この表現は直感的で分かりやすいと思いました。イメージでいうと、「nil入れてもいいの？」「nil入れちゃダメ！」という感じです。 LT4本目　Genericsについて（ネクスト枠　小屋敷さん） 　ジェネリクスの機能についてのLTでした。関数やクラスで用いる引数や返り値は、あらかじめ型指定する必要があります。しかしジェネリクスを用いて型を指定することで、型だけ違って処理の内容が同じものを作ることができる、というものです。私はC++を使っていたのですがそのときにコードに、CArray型にインスタンスをいれるときの宣言に、<>で型指定しないといけないけどなんのことだろうと思って使っていました。とても勉強になりました。 LT5本目　Swiftにおけるオブジェクト指向（飛び入り枠　ネクスト寒川さん） 　このLTは勉強会運営側も予定していなかったのですが、Androidチームの先輩が急遽プレゼン資料を用意して参加してくれました。Swiftを使って新入社員にオブジェクト指向を教えるためには、というテーマでスタートしたLTですが、途中からSwift→Sushift→寿司ft、という流れで、今回皆さんに衝撃をもたらしたマルチバイト文字を使った変数を利用し、寿司の絵文字でオブジェクト指向の継承を説明するというネタに走ったLTでした。親クラスをごはん、子クラスを寿司の絵文字で説明され、シュールな見た目に会場は笑いに包まれました。裏話ですが、継承関係にある絵文字を探すのに、発表者の寒川さんはとても苦労されたようです。 LT全体として 　バックグラウンドが異なる技術者がそれぞれSwiftを触った意見を聞くことができ、興味深かったです。言語的には読みやすい、いままで使ってきた何かしらの言語に似ているといった意見が多かったと思います。また開発環境的には、まだ改善すべき点がある、区別し辛い点があるといった意見が見受けられました。また終了後にご回答いただいたアンケートでは、新しく導入された概念がよく分かった、他の技術者がどういう観点でSwiftを捉えているのか見られてよかった、という感想をいただきました。 なお今回のLTで使用した資料の一部は、発表者の方が提供してくださいましたので、記事の下のリンクから閲覧することができます。ぜひご覧ください。 情報交換会 　情報交換会では、ピザやお酒を交えて自由に情報交換を行いました。寿司ftの裏側やSwiftの技術的な話、業界の話などで盛り上がりました。 最後に 　今回の勉強会にお越しいただいた皆様、LTをしていただいた皆様、本当にありがとうございました。まだまだ情報量が少なく開発事例も限られていますが、Swiftの情報を発信していくために、第二回Swift勉強会も企画しています。今回お越しいただいた方も、残念ながら来られなかった方も是非お待ちしております。次は私もLTをさせていただく予定ですので、よろしくお願いします。 複数人でSwift開発をするときに気を付けるべきと"個人的に"思ったこと http://www.slideshare.net/fujipara/swift-35749636 TitaniumユーザーがSwiftを触ってみたら http://www.slideshare.net/ryugoo/titanium-swift Optionalの使い方 http://www.slideshare.net/motokinarita7/optional-35774931 Genericsについて http://qiita.com/mo_to_44/items/f9b2678d22ad06599308

こんにちは、上津原です。 先日の 朝日住まいづくりフェア で予約をとり、先週の日曜日にダイワハウスのトライエラボに行ってきました！ トライエラボは水道橋からちょっと歩いたところにダイワハウスの東京本社があり、その横に建っていました。 トライエ エコロジー 中に入ってみると、広々とした空間が広がっていて、ここでは住まいエコロジーに関するクイズに回答しながら、エコロジーについて考えを深めることができます。 手元にはこのような回答ボタンが置かれて3択で答えていく感じなんですが、テレビ番組みたいな気分で楽しく、知識を深められました。 クイズの内容はネタバレになってしまうので言えませんが「へー！」「知らなかった！」と感じるようなものばかりでとても楽しめました。 トライエ シミュレーター トライエシミュレーターでは、指定した地域で今後起こりうる地震を体験したり、過去に起きた地震を追体験することができました。 驚いたのはただ単に震度だけを体感するのではなく、その住所で起きるであろう地震を計算して割り出されてくることでした。 揺れ体感中 すごいぞトライエシミュレーター！ トライエ テクノロジー ここでは、ダイワハウスの断熱や防水の技術などを体感することができます。 一人暮らしのアパート暮らしの身としては「断熱とか、ビフォーアフターで見た事あるけど」くらいでしたが、その効果にはびっくりしました。 あるのとないのとでは結露の有り無しが顕著に見え、一気に「うおー！断熱スゲー！断熱サイコー！」と一気に断熱信者になるほどでした。 トライエ ストラクチャー このコーナーの写真は撮り忘れました…。すみません。 ここでは施設内になんと2階建ての家が建っています。すごいなこのマトリョーシカ形式。 今まで見てきた建材などをはじめ、様々な工法などを見て、触って体感することができます。 いつもバーチャルで家ばかりを見ている身としては「いやー、本物っていいですねー」と感じる次第でした。 トライエ バーチャル そしてこのために来たといっても過言ではない「バーチャル」！ 最後のコンテンツということで期待していたのですが…。 なんと「家を建てる相談をしている人限定」のコンテンツだったので体験はできませんでした…。残念…。 資料館のような楽しさ バーチャルを体感できなかったのは残念でしたが、家ってこういう風にできているのか～。様々な工夫が組み込まれているんだなあとすごくためになる場所でした。 一人暮らしのアパート暮らしで、家を建てることを考えていない私でも、興奮しながら「スゲースゲー」と楽しめるつくりなので、ちょっと遊びに行くくらいでもいいのかなーと感じました。 最後に、もしバーチャルを体験された方がいたらぜひ感想を教えてください。

こんにちは、リッテルラボラトリーの清田です。 以前執筆したこちらの記事 では、情報検索システムの評価の歴史を簡単に振り返るとともに、情報検索システムの評価を考える際には「ユーザー」の存在を抜きにしては考えられなくなったこと、工学的アプローチから科学的アプローチに脱皮していく流れがあることを紹介しました。もともとは工学的システム（＝入力と出力をもつブラックボックス）として評価が行われてきたものの、Webベースの情報検索システムが普及することで、さまざまなレベルのユーザーが存在することを前提に評価することが必要とされてきたという経緯を説明しました。今回は、評価の対象となるユーザーを選ぶ上で、何に気をつける必要があるのかについて紹介します。 評価対象のユーザーを絞り込む 例えば、私たちがHOME'Sの新しい物件検索のユーザー インターフェース（UI）を開発したとします。この新しいUIを現行のUIと置き換えるときには、現行のUIと比較して「どのくらい良くなったのか」を明らかにしなくてはなりません（もし以前より「悪くなった」のであれば、UIの置き換えをすることはできません）。 しかし、「どのようなUIが良いのか」は自明ではありません。「物件の写真を大きく表示してほしい」というユーザーだけではなく、「駅からの距離や築年数などの詳細な情報も表示してほしい」「とにかく画面中に多数の物件を一覧表示してほしい」というユーザーもいます。 そこで、「大部分のユーザーにとっての満足度が高い」ことを、「良いUIである」とみなすことにしましょう。 「大部分のユーザーの満足度」を知るためのベストな方法は、HOME'Sを使う可能性のあるすべての人々に新しいUIと現行UIの両方を試してもらい、それぞれのUIの満足度を調査することです。HOME'Sを使う可能性のあるすべての人々のうち、「新しいUIの方が良い」と答えたユーザーの割合が大きければ（例えば70％であれば）、新しいUIは「良いUIである」と判断してよいでしょう。 しかし、「HOME'Sを使う可能性のあるすべての人々」に試してもらうことは不可能です。「HOME'Sを使う可能性のあるすべての人々」について考えるということは、少なくとも「インターネットを日常的に利用しており、日本国内に居住していて、将来引っ越しを経験する可能性のあるすべての人々」について考えるということです。この調査を実現するのは、以下の理由で不可能です。 「インターネットを日常的に利用している」「日本国内に居住している」「将来引っ越しを経験する可能性のある」という条件を満たす人々の数は、少なくとも千万人単位に上るでしょう。それだけの大規模な調査を実施するには、国勢調査に匹敵する費用がかかることを覚悟しなくてはいけません。 仮にそのような調査が実施したとしても、すべての人々から調査への協力を得ることはできません。忙しいなどの理由で協力を断られる場合も多いでしょう。 「評価の対象としたいすべてのもの」を調べることができないという問題は、ユーザーの満足度調査にかぎった話ではありません。出荷前の缶詰の品質（不良品の割合）を調べるためのベストな方法は、すべての缶詰を開けてみることですが、すべての缶詰を開けてしまうと、売り物がなくなってしまいます。 そこで、「評価の対象としたいすべてのもの」の一部だけを抽出して調査を行うという方法が必要になります。統計学の用語では、「評価の対象としたいすべてのもの」のことを母集団といい、母集団から一部だけを抽出することをサンプリング、サンプリングされたもの（ユーザーや缶詰）のことをサンプル（あるいは標本、試料）と呼びます。サンプル（ランダムに選ばれたユーザーや缶詰）を対象とした評価結果を、母集団を対象とした評価結果とみなそうということになります。 ここで、「サンプルが母集団の性質をどのくらい忠実に表しているか」ということが問題になります。確率的サンプリングという統計ツールが、母集団の性質をできるだけ保存してサンプリングするために大いに役立ちます。たとえば、Excelシートで母集団（たとえばA大学の全学生1万人）のリストをつくり、「1から100までの整数」から一つランダムに選んだのが「65」だったときに、「65行目、165行目、265行目、…、9965行目」の100名を対象として調査を行えば、その評価結果は、「A大学の全学生」の性質をそこそこ表しているとみなしてよいでしょう（この方法を単純無作為サンプリング法と呼んでいます）。 偏りなく評価対象ユーザーを絞り込むことは可能か？ 確率的サンプリングを適用するためには、評価を行う人が母集団のすべての要素について知っていなければなりません。しかし、HOME’Sのような不特定多数のユーザーを対象としたサービスでは、そもそもすべてのユーザーについて知ることはできません。確率的サンプリングが適用できないので、UIに関する評価を行うには、やむを得ず他の方法に頼る必要があります。 よく利用されるのは、以下のような方法です。 ユーザーテスト 募集した実験参加者にUIを触ってもらい、観察やインタビューを通してUIを評価する方法です。調査会社を通じて募集することもあれば、社内で募集することもあります。 ネット調査会社を通じたサーベイ 調査会社が抱えているモニターを対象に、ネット上でUIについてのアンケートをとる方法です。 A/Bテスト サービス上で複数のパターンのUIをランダムに出し分けて、ログデータを通してユーザーの行動の違いを分析する方法です。 しかし、これらの方法では、いずれも選ばれる評価対象ユーザーに偏りが出ることは避けられません。調査会社が接点をもっているユーザーの集合が、「HOME'Sを使う可能性のあるすべての人々」の性質をよく表しているという保証はありません。ネット上での調査の場合は、インターネットの利用頻度の高いユーザーに偏ってしまう傾向があります。社内で実験参加者を募集する場合は、さらに偏ってしまうことは避けられません。A/Bテストの結果は、「HOME’Sを現に利用しているユーザー」の性質はよく表しているといえますが、「新しいUIによって掘り起こされるかもしれない潜在ユーザー」の存在は無視されてしまいます。 結局のところ、UIの評価では、対象となるユーザーをまったく偏りなく絞り込むことは困難であり、評価結果には必然的にある程度の偏りが入ってしまうことは避けられません。よって、得られた評価結果を利用するときは、その限界を理解しておくことが重要です。また、評価結果を研究成果を公表する場合にも、どのように対象ユーザーを選んだかを明示することが求められます。 前回の記事で紹介したKelly博士の著書「Methods for Evaluating Interactive Information Retrieval Systems with Users」では、評価対象ユーザーを選ぶための方法が体系的にまとめられています。昨年、本書の邦訳「インタラクティブ情報検索システムの評価: ユーザの視点を取り入れる手法」が出版されました（私も一部の翻訳を担当しました）。興味をお持ちの方は、ぜひチェックしてみてください。 インタラクティブ情報検索システムの評価: ユーザの視点を取り入れる手法 作者: 上保秀夫,神門典子,阿部明典,加藤恒昭 出版社/メーカー: 丸善出版 発売日: 2013/04/18 メディア: 単行本 この商品を含むブログを見る Methods for Evaluating Interactive Information Retrieval Systems and Users (Foundations and Trends(r) in Information Retrieval) 作者: Diane Kelly 出版社/メーカー: Now Publishers 発売日: 2009/04/30 メディア: ペーパーバック 購入 : 1人 クリック : 6回 この商品を含むブログを見る 過去の記事のリスト ユーザー向け情報サービスの「評価」を考える (第1回) - 株式会社ネクスト エンジニアBlog ユーザー向け情報サービスの「評価」を考える (第2回) - 株式会社ネクスト エンジニアBlog

こんにちは。クリエイターの日運営委員の松尾です。 今回は「クリエイターの日（ http://creators.next-group.jp/ ）」について紹介します。 「クリエイターの日」に関する投稿は今回で3度目になります。 改めて活動の趣旨をおさらいすると 「既存サービス・技術の枠組みを飛び越えた自由な発想からイノベーションの創造」 「各メンバーの興味あるサービス・技術へのチャレンジを通しての個人の成長とネクストの創出力向上」 この2つを目的として、最大7日間の研究・開発を行っています。 今期からは、開催時期と業務が重なって参加できない状況を打開するために、 「四半期内のまとまった7日間ならいつ実施してもよい」 というかたちで運営を行っています。 その結果、第1四半期（1Q）は11チーム（約30名）が活動を予定しています。 今回は、1Q前半に活動している5チームを紹介します。 サービスのローンチに向け、今期も集中して開発に取り組んでいます。 プロフェッショナルな雰囲気… 今期から参加のプロジェクト。 一からWebサイトを作っているようです。 「クリエイターの日」常連のNode.jsチーム。 今回から新メンバーも参加し、完成度は高まってきているようです。 こちらも常連のチーム。 楽しそうなMTGの風景が「クリエイターの日」らしいです。 業務で書いたソースコードの リファクタリングをテーマとして参加してくれています。 サービスのクオリティにこだわる姿勢が素敵です。 今期はどんなプロダクトが生まれるんでしょうか。 後半の6チームについては後日改めて紹介します。

こんにちは、上津原です。 今回はこのブログでもお伝えし続けてきたRoom VRの全体的な概要をお伝えしようと思います。 背景 物件を購入するときに、どうしても物件そのものを確認できず購入をせざるを得ない状況が生まれる。この不便な状況を何とか打開できないだろうか？という考えから開始しました。 目的 上記のような、不便さを解決すること。また、それ以外の価値を見出すことを目的としています。 概要 3Dで作成した物件に、バーチャルリアリティを利用して内覧をし、今まで確認することのできなかった建設前の物件の確認やシミュレーションを行うものです。ヘッドマウントディスプレイであるOculus Riftを装着し、ゲームコントローラを使って自由にバーチャルな物件内を移動、確認することができます。 建設前のもののみならず、遠方の物件の確認や、来店できないユーザーが物件を確認する場合などにも利用できるのではと考えています。 機能概要 3Dで出来た物件をウォークスルーする 時間変更による日照の確認 プレイヤーの身長変更 物件の階数変更 家具の搬入・レイアウト確認 室内電気のON/OFF スクリーンショット ※画面は開発中のものです。 部屋のデータはEpic提供のRealistic Renderingのアセットを利用しています。 スタート画面 物の持ち上げが可能です 身長の変更も可能です。 時間帯により、空の色や光の入り方が変わります。 技術概要 Windows7 Unreal Engine4 Oculus Rift DK1 XBox360コントローラ もともとはUnityでの開発を進めていましたが、レンダリングの美しさからUnreal Engine4に機能を移植し開発をしています。 RoomVR 掲載記事 弊社記事 Unreal Engine 4 関連 OculusRift関連記事 他社記事 ASCII.jp：新築マンションをOculus Riftで内覧！ 未来の物件検索「ROOM VR」を体験してきた (1/2)

サムです。 日本最大級の不動産・住宅情報サイト「HOME'S」のiPhoneアプリ にiOS 7からの新機能である iBeacon を使った試験サービスを開始しました。 『HOME'S』、近距離無線通信技術「iBeacon」を使った不動産O2Oマーケティングの実験開始 本記事では、iBeaconの導入方法や、サービスに導入された試験サービスについて書きます。 iBeaconとは まずiBeaconとは、ご存知のとおり iOS 7以上から提供された新機能の１つで、緯度と経度から取得するGPSとは異なり、Bluetooth Low Energy（以下、BLE）を活用してiOSデバイスの位置情報を読み取るものです。 iBeaconはAppleの商標で、Androidにも同様の技術は存在します。 なので、iBeaconはAppleが提供している機能のことであって「BLE自体のことではない」ということを認識しておくことが大切です。 iBeaconでできること まずiBeaconはiOS 7から提供された新技術であり、iOS 6などの古いOSでは使うことができません。 また、BLEに対応したデバイスでなくてはならないため、iPhone 4S以降が対象になります。 iBeaconでできることは単純で、 リージョン監視：ビーコンの射程から出たり入ったりを観測 相対距離を観測：４パターンによる距離観測 になります。 iBeaconを実装する前に iBeaconは CoreLocation.framework を使います。 そのため、CoreLocation をimportする必要があります。 iBeaconはiOS 7以上の機能になります。 さらにデバイスがBLEに対応しているか確認することも必要になります。 UIDeviceクラスを使い、アプリケーションが動作しているOSの確認をしています。 CLLocationManager isMonitoringAvailableForClass: で Beacon によるリージョン観測が可能であるかチェックします。 ビーコンの測定を開始する ビーコンの計測を行う前に、CLBeaconRegionクラスのインスタンスを生成する必要があります。 6行目：計測したいビーコンのproximity UUID 10行目：計測したいビーコンのmajor 設定したら対象のビーコンのみ計測 11行目：計測したいビーコンのminor 設定したら対象のビーコンのみ計測 ビーコンの測定を開始すると、一定時間ごとにイベントが発生します。 リージョンの監視 ビーコンが出たり入ったりするリージョンの監視は CoreLocation.framework の CLLocationManagerDelegate にある locationManager:didEnterRegion: および locationManager:didExitRegion: を実装します。 相対距離を観測 ビーコンとの相対距離を測定するには CoreLocation.framework の CLLocationManagerDelegate にある locationManager:didRangeBeacons:inRegion: を実装します。 HOME'S アプリにおけるiBeacon 住まい探し専用iPhoneアプリ『HOME'S』 でもiBeaconをつかっています。 使用しているBeaconはAplix社製で、これを不動産会社の店頭に設置しております。 HOME'Sアプリでは、ビーコン対象のユーザに向けて、不動産店舗訪問後にPUSH通知でアンケートを送ることに使っています。 ユーザはPUSH通知からHOME'Sアプリを起動するとアンケート画面が開きます。 ユーザがアンケートに入力することで、不動産店舗はユーザの率直な接客の感想を受け取ることができます。 iBeaconを開発してみて 上記のように、iBeaconの開発はとても単純です。 また、少し前に問題になっていたビーコンの成り代わりも、暗号化や証明書などを使ってセキュリティを担保する仕組みも出来上がってきました。 iBeaconを使う上で気すべきことは次のとおりだと思います。 Bluetoothを ON にするユーザが日本にはまだ少ない WEBリテラシーの低いユーザへの配慮 「Bluetoothを ON にすると電池を消耗する」という会話が行き交う中で、いかにiBeaconのメリットが話題を上回れるかを考えることが一番の課題でした。

突然ですがOrigami原理主義者狂喜乱舞のニュースがあったので取り急ぎ報告です。 IDEO 有名ですよね。「デザインといえばIDEO」とは言いすぎでしょうか。しかしそれくらい頻繁に引用されるのも事実です。 先日そのIDEOが彼らが「開発」したインタラクションデザインツール Avocado を公開しました。 Does your brain hurt looking at this? Mine did, too. Building the iOS Keyboard patch kept me up all night, requiring me to jump back and forth between Quartz Composer and Xcode. via: Neat Effects, No Code Required | IDEO Labs 画面をみて「あれ？これQuartz Composerじゃないか？」と思った方。あなたは鋭い。このAvocadoというのは彼らの言葉を借りれば AvocadoはOrigamiの上で動き、さらにいくつか便利なパッチを追加したものだ ということになります。FAQによれば、AvocadoはOrigamiを含んでいるので、AvocadoをインストールすればOrigamiも自動的にインストールされる。 じゃあ何が新たに可能になったか、ですが一番わかり易いのがCarousel 写真を並べて、スワイプで一枚ずつ送る。良く使いますよね。もちろんOrigamiをつかってがんばれば可能なのですが、Carouselパッチを使えばこんだけです。 いや素晴らしい。素晴らしいですよね？ね？（うざry) ーーー というわけで、Avocadoを試すやり方です。ちょっとわかりづらいと感じたのは私だけなのだろうか。。 １）まず このページ を参照して、Quartz Composerのインストールまで行う。OrigamiはAvocadoをインストールすると自動的に入る（らしい）のでここでインストールしなくてもいいです。 ２）iii. Download and install Avocado 　←のリンクをクリック。するとAvocadoのパッケージがダウンロードされる。 自動的にzipが解凍されてできたAvocado.mpkgをダブルクリックするとインストーラーが立ち上がり、Avocadoがインストールされます。 ３）とりあえずExampleを動かしたいですよね？ね？（ウry) このページ のDownload Zipをクリックしてまるごとダウンロードしましょう。でもってその中のExamplesフォルダを見るとあれこれ入っています。先ほどのCarouselやものすごい力作の「キーボード」がはいってます。 ーーー というわけで、これを使えばいろいろなことがもっと簡単になるのかな、、と思いつつあれこれ触っている今日この頃。私が何をそんなに喜んでいるかといえば、デザイン分野で確固たる地位を築いているIDEOがQuartz Composerを（少なくとも選択肢の一つとして）選択し、ソフトウェアを公開してきたこと。Quartz Composer自体いつサポートされなくなってもおかしくないような状況だったわけですが、これで少しは安心して使えるかな、、とか言っているそばからOS X Yosemiteでサポートされなくなったら発狂するわけですが。

Apple原理主義者の大坪です。例によって先日見つけた文章を和訳しつつあれこれ書きたいと思います。題名は" Design is About Intent "-「デザインとは意図のことである」 この文章中の主張についてはおそらく様々な意見があると思いますが、私は読んでいる最中に３度は大笑いしたことを申し添えておきます。 -　-　-　-　-　-　- 有名で敬意を払われている企業にはそれぞれのコア・バリューがあります。この文章によればToyotaのそれは生産システムであり、GEはシックス・シグマで有名です。ではAppleのコア・バリューは何かと問われれば Apple is about  design . via: Rampant Innovation | John R. Moran on strategy and innovation Appleはデザインの会社だ。 「デザイン」。昨今デザイン思考とかd.SchoolとかIDEOとかが語られ、ともすれば With the worthy aim of making design accessible to the rest of us, they’ve broken down “design thinking” into  step-by-step frameworks , which generally involve empathetic understanding, creative ideation, and experimental prototyping. via: Rampant Innovation | John R. Moran on strategy and innovation だいぶ意訳：デザインを普通の人にも使えるようにするため、デザイン思考はステップ・バイ・ステップのフレームワークとして定義された。多くの場合ユーザの感情の理解、創造的なアイディア出し、それにプロトタイピングが含まれる。 個人的な意見ですが、こうした「デザインプロセス」について読む度、何かが決定的に欠けている、と思うことが多い。この文章も次にそうした点について述べます。 But I fear that “design” has moved too quickly to the tools and techniques stage - the “how,” instead of the “what.” via: Rampant Innovation | John R. Moran on strategy and innovation デザインがあまりにも早くツールやテクニックになってしまっているのではないかと危惧している。「What:何を」ではなく「How:どうやって」になっていないか。 ではこの文章の著者が考える「デザイン」とは何なのか？それは Intent:意図 であると主張します。なんだそんなことは当たり前ではないか、と言うことは簡単ですが難しいのはその意図を細部にまで徹底させること。Appleがその点で徹底していることを示すエピソードが２つ挙げられていて、ひとつはDesign担当のVP Jonathan Iveについて “he’s known to use ‘arbitrary’ as a term of abuse.” 彼にとって「任意の」という言葉は悪態と同じだ もう一つは故Steve Jobsのもので彼の妻によれば “We spent a lot of time asking ourselves, ‘What is the purpose of a sofa?’” via: Rampant Innovation | John R. Moran on strategy and innovation 私達は「ソファーはなぜ必要なんだろう？」と長い間議論したものです 別の言葉で言えば、「なぜ製品のこの部分はこうなっているのか？」と聞かれた時に「なんとなく」という言葉はありえず、「それはこういう理由からです」と即座に返答ができなければならない。 こういう文章を読むと日々「なーんでもいいんじゃなーい」と言っている私などは果たしてApple原理主義者と名乗る資格があるのか不安になってくるわけですが気にせず先に進みます。 この文章では次に「３つのデザイン上でのごまかし」が取り上げられます。それはなんなのか。 The first evasion: Preserving：現状維持 「デザイン」する上での判断を避けるもっとも良い方法は、そもそも疑問を持たないこと。「車輪の再発明をするな」というのは多くの場合有効な言葉ですが、新しい物を殺すという点でも有効。この文章では「Microsoft Surfaceや新しいBlackberryに物理的キーボードが付いている」ことがその例として挙げられていますが、これに関しては異論を述べたい人も多いでしょう。 この文章の主張を私なりに解釈すれば、 「タブレットには絶対キーボードが必要なんだ」 ではなく 「今のPCにはキーボードがあるから、タブレットにもキーボードをつけよう」 と考えるのがよくない、ということなのかなと。非常に微妙な線ではありますが。 さて２番めは The second evasion: Copying：コピー この点に関しては、最近サムソンがやり玉にあげられることが多い。こんな サイト まであるほどです。私のような年代の人間だと 「そうだよなあ。コピーばかりで独創性がない、って言葉は一昔前に日本企業に向けられていたけど、最近はもう非難すらしてもらえないのか」 と寂しくなりますが、それはそれ。 Appleも時としてコピーすることが知られていますし、そもそもMacintoshのGUIだってXeroxのPalo Alto研究所から、と言いたい人もいるでしょう。それに対するこの文章の答えは The difference is that Apple seems biased to design based on its own intent first, and copy second; its rivals tend to copy first. via: Rampant Innovation | John R. Moran on strategy and innovation Appleが他の企業と異なるのは、自らの意図に従ってデザインすることが第一で、コピーが２番目になっていること。競合企業はコピーすることを第一にしている。 Apple原理主義者の意見ですが、Appleはコピーした特徴であってもApple製品の一部として消化して出してくる、と思っています。 さて３番めは The third evasion: Delegating：他人まかせ Delegateという言葉は「権限移譲」とかいう意味。なんだそれはと思われるかもしれませんが、具体例を挙げたほうがわかりやすい。この文章では３つのカテゴリーに分けられており A) Offering a wide range of product choice：幅広い製品バリエーション サムソンが非常に多くの種類のスマホ、タブレットを作っていることは時々揶揄の対象になります。この文章の言葉で言えば"spray and pray" - 撒き散らしてあたるように祈る-とでもいいましょうか。 もちろんそれを意図的にやる、という方針もあるのでしょうが設計上の判断を避ける良い方法とも言えます。 もう一つ例として挙げられているのが再びMicrosoftのSurface。Windows RT+ARM CPUを搭載したSurfaceとWindows+Intel CPUを搭載したSurface Pro。どちらが当たるかわからない時は「幅広いユーザニーズに応えるため」両方の選択肢を提供する、というのもひとつの理屈でしょう。しかしコンシューマーからみれば「で何が違うの？」と混乱するだけ。 挙げられている例えが面白いので訳します。 As an analogy, giving someone birthday money instead of taking the time to choose a gift seems eminently logical - why limit the recipient’s choices? But the gifts we remember most fondly are seldom checks. via: Rampant Innovation | John R. Moran on strategy and innovation たとえだが、誕生日プレゼントに時間をかけて何かを選ぶのではなく、お金をあげるのは論理的な方法だ。なぜ受け取る側の選択肢を狭めてしまうのか？しかしお金（原文：チェック-小切手）が「印象に残ったプレゼント」であることは滅多にない B) Trying to offer an omni-functional product：なんでもできる製品 特定の用途を念頭に、それをすばらしく上手に行える製品を作るのではなく、「誰が何をするときも役に立つ」製品をつくること。挙げられている例のうちわかりやすいのが、（三度目ですが）Microsoft Surface。 ラップトップPCでもある。Tabletとしても使える。どちらのユーザにも対応できる製品であり、文字面で聞くと非常によく思える。 Surface Pro3の発表 でもその点をしきりに強調していました。96%のiPad所有者はラップトップも買っている。なぜ２つ必要なんだ？Surfaceなら一つでOK。自分が何を買いたいか迷った時も、Surfaceを買えば間違いない。 私の左脳は「これは実に見事なロジックだ」と理解している。誰もがなんでもできる製品、という言葉にこれほどふさわしいものはない。 しかし現実を見ましょう。彼らはまだ市場で成功しているとは言えない。（未来のことはわかりませんが）なぜ売れないのか？ 我々の頭のなかには「機能が増えることはいいことだ」という固定概念が存在しています。"Less is more"と字面でわかったような気になってもなかなか勇気をもって削ることはできない。あれもできる、これもできる。それと引き換えにシステムは複雑になり、どちらの用途にも中途半端になる。 勇気を持って「それを削り、こちらにフォーカスしよう」という決断こそが「デザイン」のコアである「意図」。 これは私見ですが、タブレット用の全画面UIと、従来のPC用のデスクトップ画面を「妥協無く共存」させたWindows8のUIもこうした観点から見ることもできるかもしれません。 さて、おそらくもっとも議論を呼ぶであろう３点目。 C) Deciding based on user testing：ユーザテストで判断する この点においては、IT業界の巨人達とAppleは極端な違いを見せています。A/BテストはWebサービスにおいて広く用いられており、有用だ、とこの文章は述べます。しかし 「それはデザインではない」 とも。 この文章によればGoogle/Facebook/Amazon　３社ともが「主観ではなくデータ、ユーザテストの結果で判断する」と述べているとのこと。しかしながら特にGoogleとAppleの間で顕著ですが、NexusのデザインがiPhone/iPadのデザインより優れている、という意見はあまり聞いたことがない。 それであれば、「ユーザテストを元に決断する」という方法が「他人まかせ」の一つの形態になってはいないか、という議論もなりたつのではないか。 この点を考える時いつも私の頭に浮かぶのは、ある雑誌でみた４コマ漫画です。年配の教授が「長期にわたるテストと解析の結果、A案のほうがB案より優位に良いことが判明した」と研究成果を述べている。それに対して学生が次のように質問する。 「えーっとどうやって言えばいいかな。もし両方共ゴミだったとしたら？」 A案とB案を比較することはデータで議論できる。しかしそもそも「優れた案」はデータから産む事ができるものでしょうか？ -　-　-　-　-　-　- この文章は「Appleの製品はデザインが優れている」という観点で書かれています。しかしながらサーバーサイド主体のサービスになると、私のような狂信的Apple原理主義者でも首を傾げざるをえないことが多い。iCloudはそもそもどうやって使う物なのか。Googleのような有用なサービスをなぜAppleは「デザイン」することができないのか。 しかし「手に取って触る製品」になるとそうした関係は逆転します。この「差異」については未だに結論が得られません。 ユーザがインターネットに触る場所がPCからモバイルに移るにつれ、「手に取って触る製品」のインタフェースの重要性が増してきている。それではサーバーを活用したサービス＋手に取る製品のデザインはどのような形で行うべきなのか。この答えはまだでていないように思います。

Origami原理主義者の大坪です。Origamiの存在を知り、取り乱した挙句サンプルなど公開し始めたけど誰も見てくれないんだろうなあ、と思っていたのですが。 ちゃんと読んでくれる人がいたどころかリクエストまでいただき嬉しい限りなわけです。というわけで今回はそのリクエストを原型にした「ボタンを押すと横からメニューがでてきて、背景画像がすりガラスになる」をやります。 今回の完成形はこれです。 右下にわざとらしく存在している"Side Menu"というボタンを押すと横からメニューが出てくる。それとともに背景画像が「すりガラス」を通したようになる。 ここで背景画像をタップするとメニューが消え、すりガラス効果がなくなる。 しかしなんですね。こうやってオリジナルの「課題」を作ると自分にかっこいい画面を作る能力がないことに悲しくなります。しかしこれはあくまでも"Simple Example"。重要なのはOrigamiでどう動きを構築するかであって、画面のデザインじゃない。だから誰も気にしませんよね？ね？ね？（ウザい） というわけで、 第一回目の記事 を参考にして、下の図までつくりましょう。ここからRender in Imageパッチの中身を作っていきます。Render in Imageの下のほうをダブルクリックして中にはいりましょう。 まずあれこれ配置 Github からファイルをダウンロードし、assetsというフォルダの中を見る。background.jpg,sideMenu.pngという２つのファイルがはいっています。これを１つずつEditorの画面にドラッグ＆ドロップします。ImageパッチとそれにつながったLayerパッチがそれぞれ追加されるはずです。ついでにPatch LibraryからClearを追加します。Clearパッチの右上の数字を１に、backgroundにつながったLayerパッチの右上の数字を２，sideMenuにつながったLayerパッチの右上の数字を３にしましょう。するとこんな感じになります。 なんとなく表示されていますが、サイドからでてくるはずのメニューの位置が絶望的にずれています。まずこれを直しましょう。 sideMenuがつながったLayerパッチを選択し、Patch Inspectorを開きます。ここで先日フェンリル株式会社で行われた Origamiの講習 で教わった技を使ってみます。Anchor PointというメニューがCenterになっていると思いますが、これをTop Leftにする。するとSideMenuの左上が、iPhone画面の左上になります。これは楽ですね。 というわけで、背景画像の上にメニューが表示された状態になりました。例によって「ここまで長い道のりだった」と感慨にふけることは可能ですが、まだ何も動いていないことを思い出しましょう。先は長いのです。 メニューを出したり引っ込めたり というわけでまずボタンを配置しましょう。Patch LibraryからButtonを探してEditorに追加します。Patch Inspectorを使ってあれこれパラメータを設定してください。多分誰がやっても私ほどひどいデザインにはならないと思うので、大丈夫です。（何が） Anchor PointをBottom Rightに設定すると、細かい数字をいじらなくても画面右下に配置されるのが便利です。 さて、ここから動かすための仕組みを作っていきます。これから書くのはひとつの「パターン」になっていて、今までもでてきたしこれからも出てくるので「パターン」を意識しながらつないでください。 Interaction2パッチを追加して、右上の◯からButtonという文字の左にある◯につなぐ Switchパッチを追加し、Interaction2のClickからSwitchのTurn Onにつなぐ（ボタンを押した時は、メニューがでるだけなので、こうします） Classic Animationsパッチを追加し、SwitchパッチのOn/OffからNumberにつなぐ Transitionパッチを追加し、Classic AnimationsパッチのProgressからTransitionのProgressにつなぐ TransitionパッチのValueをsideMenuがつながっているLayerのX Positionにつなぐ。 ここで 青いパッチ（Layer,Buttonなど）→Interaction2→Switch→Animation(ClassicだったりBouncyだったり）→Transition というのがここで言うパターンで、「何かを押すと、何かが変わる」という汎用的な動作を実現するのに使えます。 次にパラメータを設定します。 TransitionパッチのStart Valueを-362に、End Valueを0に設定する。 今回使うメニュー画像の幅が362なので、初期状態では画面の外にでておいてもらって、End Valueになったところで中にはいってもらえればよいわけです。 この段階でボタンを押すとメニューがにゅいっとでてきます。わーいと思いますが次の瞬間何をしても引っ込まないことに気がつくでしょう。なぜかといえば、ボタンにつながったInteraction2パッチの出力は、SwitchのTurn Onだけにつながっており、Offにできない。というわけで、もうひと息がんばり「背景画像を押したらメニューが引っ込む処理」を作りましょう。 Interaction2パッチをもう一つ追加し、右上の丸から背景画像がつながったLayerパッチの左上の丸につなぐ 新しく追加したInteraction2パッチのClickからSwitchパッチのTurn Offにつなぐ ここまでやるとこんな風になるはずです。 というわけでViewerを開き、ボタンを押しましょう。メニューがにゅいっとでる。背景画像を押すとメニューが引っ込む。何度かやっているとじわっと喜びがこみ上げてきますよね？ね？ね？（ウザry) すりガラスにしたり戻したり というわけで残った処理「すりガラスにしたり戻したり」を作りましょう。まず「とにかくすりガラス」処理を作ります。 Patch Libraryから"Gaussian Blur"というパッチを追加します 追加したGaussian BlurパッチをBackgroundイメージとLayerの間に入れます。Bacground ImageのimageをGaussian Blurの左側のimageに、Gaussian Blurの右側のimageからLayerのimageにつなぎます こんな感じになります。 Viewerをみてみると、背景画像がすりガラスのようになっていることがわかります。Gaussian Blurパッチを選んだ状態でPatch Inspectorを開き、Radiusを変化させてみましょう。０の時には元の画像が表示され、Radiusを増やすにつれボケが強くなっていくことがわかると思います。 というわけでやることはSide menuがでているときはこのRadiusの値をたとえば10にして、引っ込んでいる時は0にする、ということになります。ということは、Side menuがでるでない、とトリガーは同じで、値の範囲を変えるところだけ別にすればよい、ということになります。 というわけで Transitionパッチをもう一つ追加 Classic AnimationのProgressを追加したTransitionパッチのProgressにつなぐ TransitionパッチのValueをGaussian BlurのRadiusにつなぐ TransitionパッチのStart Valueを0に、End Valueを30にする（この値は適当） これが今回の完成形です。 Viewerを開いて、ボタンを押したり背景画像をおしたりしてみましょう。私の環境だと多少処理がひっかかりますが、背景画像がぼやけたりメニューが動いたりします。ここまで来ればあなたの頭からはSide menuの画像が「いかがなものか」という出来である事実などは抜け落ちているはずです。 というわけでOrigamiの例その３でした。ここからFacebook paperのプロトを作るまでの道のりははるか遠く思わず気を失いそうになりますが、それは考えないことにします。 今回のファイルは Github に置きました。

紹介 株式会社ネクスト 金融グループでシステムエンジニアとして勤務している金成奉です。 近年多くの企業が、POI (Point of Interest、位置情報) やGIS関連データ（区画ポリゴン、道路のラインなど）を扱うようになりました。 GIS関連データを扱う際、システムエンジニアが最初に接するのが、空間データベースです。 何年か前からGIS関連オープンソースは、UbuntuOSに最適化され、世界の開発者達もUbuntuOSを利用する傾向が強くなり、日本の企業で一番多く使われているCentOSでは、コンパイル構築すら難しくなりました。 そのため、CentOSでオープンソースを利用して空間データベースを構築する方法を簡単に紹介致します。 最新バージョンのCentOS及びオープンソースを利用して、PostGIS及びpgRouting（ルート検索機能）を構築します。 構築概要 CentOSがインストールされているVPSまた実機での構築となります。 用途としては空間データベース専用マシーンを前提としています。 コンパイルの設定オプションは、「--prefix=/usr」としているため、「/usr/local」などのディレクトリにインストールする際は、オプションを適宜変更してください。 Linuxバージョン確認 #Linuxバージョン確認 cat /proc/version Linux version 2.6.32-431.3.1.el6.x86_64 (mockbuild@c6b10.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Fri Jan 3 21:39:27 UTC 2014 OSバージョンの確認 #OSバージョン確認 cat /etc/redhat-release CentOS release 6.5 (Final) ユーザー確認 cat /etc/passwd useradd potgres OpenSSLバージョン（HeartBleedセキュリティ確認） openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 以下のバージョンであれば、安全（最後が5.7以上） openssl.x86_64 1.0.1e-16.el6_5.7 基本アップデート実行 #アップデートを行い、OSを最新の状態にする。 yum install yum-fastestmirror #アップデートパッケージをチェックする #すべてアップデートするか、チェックしたリストを選んで個別にアップデートする。 yum check-update #構わずアップデートを行う。 yum update コンパイル環境構築 #基本コンパイル環境インストール yum -y install autoconf yum -y install automake yum -y install libtool.x86_64 yum -y install flex.x86_64 yum -y install bison.x86_64 yum -y install gcc.x86_64 yum -y install gcc-c++.x86_64 yum -y install make.x86_64 yum -y install kernel-headers.x86_64 yum -y install kernel-devel.x86_64 #最新GISサポートPostgreSQL-9.3.4コンパイル環境構築 yum -y install subversion.x86_64 yum -y install libxml2-devel.x86_64 yum -y install json-c-devel.x86_64 yum -y install openssl-devel.x86_64 yum -y install readline-devel.x86_64 yum -y install zlib-devel.x86_64 yum -y install expat-devel.x86_64 yum -y install libcurl-devel.x86_64 yum -y install xerces-c-devel.x86_64 yum -y install unixODBC-devel.x86_64 yum -y install sqlite-devel.x86_64 yum -y install libspatialite-devel.x86_64 yum -y install libspatialite.x86_64 yum -y install openjpeg-devel.x86_64 yum -y install openjpeg-libs.x86_64 yum -y install pcre-devel.x86_64 yum -y install ocaml-csv-devel.x86_64 yum -y install geos-devel.x86_64 yum -y install pam-devel.x86_64 yum -y install uuid-devel.x86_64 yum -y install python-devel.x86_64 yum -y install perl-devel.x86_64 yum -y install tcl.x86_64 yum -y install tcl-devel.x86_64 yum -y install cmake yum -y install cmake28.x86_64 yum -y install CUnit-devel.x86_64 yum -y install libtiff-devel.x86_64 yum -y install libjpeg-turbo-devel.x86_64 yum -y install hdf-devel.x86_64 yum -y install hdf5-devel.x86_64 yum -y install netcdf-devel.x86_64 yum -y install jasper-devel.x86_64 yum -y install nas-devel.x86_64 yum -y install gsl-devel.x86_64 yum -y install libdap.x86_64 yum -y install proj.x86_64 yum -y install proj-devel.x86_64 yum -y install proj-epsg.x86_64 yum -y install proj-nad.x86_64 yum -y install proj-static.x86_64 yum -y install ogdi-devel.x86_64 yum -y install boost.x86_64 yum -y install boost-math.x86_64 yum -y install boost-devel.x86_64 yum -y install gmp-devel.x86_64 yum -y install mpfr-devel.x86_64 yum -y install qt-devel.x86_64 yum -y install qt3-devel.x86_64 yum -y install gtk+-devel.x86_64 コンパイルインストール #PostgreSQL-9.3.4コンパイル・インストール #PostgreSQLはroot権限で実行できないため、以下のユーザーを追加する #make時はオプション「-j6」を指定して並列でコンパイルする。 #重要：PostgreSQLのバックエンドやファンクションの多くがC++言語で書かれているため、 # 安定運用のためにはstdc++ラブラリーをリンクして原因不明のトラブルを回避する。 wget http://ftp.postgresql.org/pub/source/v9.3.4/postgresql-9.3.4.tar.gz tar zxvf postgresql-9.3.4.tar.gz cd postgresql-9.3.4 LDFLAGS=-lstdc++ ./configure --prefix=/usr --libdir='${prefix}/lib64' make -j8 world make install-world cd .. #libgeotiff コンパイルインストール wget http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.4.0.tar.gz tar xvfz libgeotiff-1.4.0.tar.gz cd libgeotiff-1.4.0 ./configure --prefix=/usr --libdir='${prefix}/lib64' --with-zlib=/usr --with-jpeg=/usr --enable-incode-epsg make -j8 make install cd .. #計算幾何(Computational Geometry Algorithms Library)ライブラリー #CGALのコンパイル・インストール wget https://gforge.inria.fr/frs/download.php/33525/CGAL-4.4.tar.gz tar zxvf CGAL-4.4.tar.gz cd CGAL-4.4 #★★以下修正注意★★ #ヘッダー修正ファイル：include/CGAL/Mpzf.h #57行目に以下の定義を追加して保存する。 vi include/CGAL/Mpzf.h #ifndef mpn_sqr #define mpn_sqr(dest,a,n) mpn_mul_n(dest,a,a,n) #endif #インストールライブラリーのディレクトリを変更してからcmakeを実行する #ライブラリーのインストール先の「/usr/lib」から「/usr/lib64」に変更する。 #cmake28バージョンを使う場合もあるため注意する。 sed -i -e "s|CGAL_INSTALL_LIB_DIR \"lib\"|CGAL_INSTALL_LIB_DIR \"lib64\"|g" CMakeLists.txt cmake -DBOOST_ROOT=/usr \ -DCMAKE_BUILD_TYPE=Release -DBOOST_LIBRARYDIR=/usr/lib64 \ -DWITH_GMP=y -DGMP_INCLUDE_DIR=/usr/include -DGMP_LIBRARIES_DIR=/usr/lib64 \ -DMPFR_INCLUDE_DIR=/usr/include -DMPFR_LIBRARIES_DIR=/usr/lib64 \ -DCMAKE_INSTALL_PREFIX=/usr . make -j8 make install cd .. #遺伝的アルゴリズム（genetic algorithm） #GAUL コンパイル・インストール wget http://sourceforge.net/projects/gaul/files/gaul-devel/0.1850-0/gaul-devel-0.1850-0.tar.gz tar zxvf gaul-devel-0.1850-0.tar.gz cd gaul-devel-0.1850-0 ./configure --prefix=/usr --libdir='${prefix}/lib64' --enable-slang=no make -j8 make install cd .. #GoogleのKMLサーポートライブラリーコンパイル・インストール #--disable-swigに設定して他言語のライブラリーを無効にする。必要な場合は、JDKなどを先にインストールする。 svn checkout http://libkml.googlecode.com/svn/trunk/ libkml-1.3.0 cd libkml-1.3.0 ./autogen.sh ./configure --prefix=/usr --libdir='${prefix}/lib64' --disable-swig make -j8 make install cd .. #GDAL(Geospatial Data Abstraction Library) のコンパイル・インストール wget http://download.osgeo.org/gdal/1.10.1/gdal-1.10.1.tar.gz tar zxvf gdal-1.10.1.tar.gz cd gdal-1.10.1 ./configure --prefix=/usr --libdir='${prefix}/lib64' make -j8 make install cd .. #CGALラッパー（SFCGAL）インストール（PostGIS） #バックグラウンドで3Dデータをハンドリングする際に使われるが、必要ソフトが #CentOS-6.5にはインストールされているGCCやBOOSTバージョンとは合わないため、 #コンパイルができない。自力でGCCとBOOSTをコンパイル・インストールする場合、 #以下の方法でコンパイルし、ライブラリーをPostGISに組み込む。 #wget https://github.com/Oslandia/SFCGAL/archive/v1.0.4.tar.gz #mv v1.0.4.tar.gz SFCGAL-1.0.4.tar.gz #tar xvf SFCGAL-v1.0.4.tar.gz #cmake28 -DCMAKE_INSTALL_PREFIX=/usr . # #cmake28 -DBOOST_ROOT=/usr \ # -DCMAKE_BUILD_TYPE=Release -DBOOST_LIBRARYDIR=/usr/lib64 \ # -DWITH_GMP=y -DGMP_INCLUDE_DIR=/usr/include -DGMP_LIBRARIES_DIR=/usr/lib64 \ # -DMPFR_INCLUDE_DIR=/usr/include -DMPFR_LIBRARIES_DIR=/usr/lib64 \ # -DCMAKE_INSTALL_PREFIX=/usr . #PostGIS2コンパイルインストール wget http://download.osgeo.org/postgis/source/postgis-2.1.2.tar.gz tar zxvf postgis-2.1.2.tar.gz cd postgis-2.1.2 ./configure --prefix=/usr --libdir='${prefix}/lib64' make -j8 make install cd ../ #pgRoutin-2.0.0コンパイルインストール wget https://github.com/pgRouting/pgrouting/archive/v2.0.0.tar.gz mv v2.0.0.tar.gz pgrouting-2.0.0.tar.gz tar zxvf pgrouting-2.0.0.tar.gz cd pgrouting-2.0.0 mkdir build cd build cmake28 -DWITH_DD=ON -DBoost_NO_BOOST_CMAKE=ON .. make -j8 make install cd ../../ DB設定 #postgresユーザがなければ追加する useradd postgres mkdir -p /var/pgsql/data chown -R postgres:postgres /var/pgsql/ #DBの初期化 #--encoding：DBのデフォルト文字エンコーディング設定オプション。UTF-8指定 #--no-locale：--no-localeは--locale=Cと同じ意味。Cロケール以外の設定では性能に影響が出る場合がある。 su postgres -c'/usr/bin/initdb --encoding=UTF-8 --no-locale -D /var/pgsql/data' #サービスに追加し、サービスとして運用する。 cp postgresql-9.3.4/contrib/start-scripts/linux /etc/init.d/postgres #ファイルを開きディレクトリに合わせて修正 vi /etc/init.d/postgres prefix=/usr PGDATA="/var/pgsql/data" #実行権限設定 chmod 700 /etc/init.d/postgres #サービスに登録 chkconfig postgres on #DB起動 #/etc/init.d/postgres start #サービス起動 service postgres start GIS テンプレート作成 #PostGISテンプレートDB作成（PostgreSQL-9.3.4での「postgis/pgrouting」サポート） su postgres createdb -U postgres -T template0 -E UTF-8 template_gis psql -d template_gis -c "CREATE EXTENSION postgis;" psql -d template_gis -c "CREATE EXTENSION postgis_topology;" psql -d template_gis -c "CREATE EXTENSION fuzzystrmatch;" psql -d template_gis -c "CREATE EXTENSION postgis_tiger_geocoder;" psql -d template_gis -c "CREATE EXTENSION pgrouting;" #GISサーポートデータベース作成 createdb -U postgres -T template_gis -E UTF-8 testgis pgbench（DBベンチマーク） #以下のオプションで初期化し一般性能を確認する。 #チューニングを行わない状態で確認後、調整しする。 #スケーリングファクター[-s]単位：10万件 #100万件のデータ[-s 10]検証 #10万件当たり15MBディスク容量 pgbench -i -s 10 testgis #条件を指定してベンチマーク #検索処理のみ実行する #同時に接続するクライアント数は10 #1クライアントあたりのトランザクション数は100 #読み込みのみのオプションでテスト pgbench -S -c 10 -t 100 testgis #結果サンプル starting vacuum...end. transaction type: SELECT only scaling factor: 10 query mode: simple number of clients: 10 number of threads: 1 number of transactions per client: 100 number of transactions actually processed: 1000/1000 tps = 13445.739717 (including connections establishing) tps = 19127.041812 (excluding connections establishing) PostgreSQLの自動チューニング設定スクリプト #注意：以下のスクリプトは、上記の方法でインストールした場合のみです。 #他で使用する場合は適宜変更してご使用ください。 #読み込みが圧倒的に多い場合は、「web」オプションを選択すると性能が向上します。 sh pgsql_autoconf.sh web vi pgsql_autoconf.sh #!/bin/sh # pgsql_autoconf.sh: # # This script automatically detects system RAM and other resources # and modifies $PG_DATA_DIR/postgresql.conf to configure the server # for one of three uses: web, oltp, or data warehousing. # # Author: rocket357@users.sourceforge.net # License: BSD # # このスクリプトは以下のスライド発表の際に使われたようです： # http://www.slideshare.net/oscon2007/performance-whack-a-mole # # 以下の内容は上のURLを参考に作成されました。 # "What Color Is My Application" の部分です。 # # web = web application backend # 1) DB smaller than RAM # 2) 90% or more simple read queries # oltp = online transaction processing # 1) db slightly larger than RAM, up to 1 TB # 2) 20-40% small data write queries # 3) some long transactions # dw = data warehousing # 1) large to huge databases (100 GB to 100 TB) # 2) large complex report queries # 3) large bulk loads of data # 4) also called "Decision Support" or "Business Intelligence" # CHANGELOG # v0.1 - Initial post to LQ.org set -e # bomb out if something goes wrong... if [ ! `whoami` = 'root' ]; then echo "This script needs to run as root because" echo "it alters shm{max,mni,all}" exit fi if [ -z "$1" ]; then echo "Usage: ./pgsql_autoconf.sh [template]" echo "Where [template] is one of:" echo " 'web' (web backend server)" echo " 'oltp' (online transaction processing)" echo " 'dw' (data warehouse)" echo "See http://www.slideshare.net/oscon2007/performance-whack-a-mole" echo "for further explanation." exit fi echo -n "Will this machine be dedicated (i.e. PostgreSQL is the only active service)? (y/n) " read dedicated ################################### ### USER CONFIGURABLE VARIABLES ### ################################### # 構築環境によって下の設定内容は異なりますので、適宜変更してください。 PGHOMEDIR=/var/pgsql PGDATADIR=$PGHOMEDIR/data CONFIG_FILE=/var/pgsql/data/postgresql.conf TEMP_FILE=${CONFIG_FILE}.TMP # performance-whack-a-mole (上記リンク参照) SHARED_BUFFER_RATIO=0.25 EFFECTIVE_CACHE_RATIO=0.67 if [ "$1" = "web" ]; then # web backend server NUM_CONN=400 WORK_MEM=512 # kB CHECKPOINT_SEG=8 MAINT_WORK_MEM=128MB elif [ "$1" = "oltp" ]; then # online transaction processing if [ $dedicated = 'y' ]; then NUM_CONN=50 WORK_MEM=8192 # kB else NUM_CONN=200 WORK_MEM=2048 # kB fi CHECKPOINT_SEG=16 MAINT_WORK_MEM=128MB elif [ "$1" = "dw" ]; then # data warehousing NUM_CONN=100 WORK_MEM=131072 # kB CHECKPOINT_SEG=64 MAINT_WORK_MEM=1024MB fi ####################################### ### END USER CONFIGURABLE VARIABLES ### ####################################### # first let's locate the configuration file... if [ -e $CONFIG_FILE ]; then echo "Backing up original config file to $CONFIG_FILE.BACKUP" cp $CONFIG_FILE $CONFIG_FILE.BACKUP echo "Backing up /etc/sysctl.conf to $PGHOMEDIR/sysctl.conf.BACKUP" cp /etc/sysctl.conf $PGHOMEDIR/sysctl.conf.BACKUP fi OS_TYPE=`uname -s` ### LINUX if [ "$OS_TYPE" = "Linux" -o "$OS_TYPE" = "GNU/Linux" ]; then SYSCTL_KERNEL_NAME="kernel" MAX_MEM=`grep MemTotal /proc/meminfo | sed -e 's/^[^0-9]*//' | cut -d' ' -f1` OS_PAGE_SIZE=`getconf PAGE_SIZE` ### OPENBSD elif [ "$OS_TYPE" = "OpenBSD" ]; then SYSCTL_KERNEL_NAME="kern.shminfo" MAX_MEM=$(echo "scale=0; `dmesg | grep \"real mem\" | cut -d\"=\" -f2 | cut -d\"(\" -f1`/1024" | bc -l ) # convert to kB OS_PAGE_SIZE=`sysctl hw.pagesize | cut -d'=' -f2` ### UNKNOWN else echo "$OS_TYPE isn't supported! Please send an e-mail to rocket357@users.sourceforge.net to have this OS added!" exit fi echo "Done!" # make sure work_mem isn't greater than total memory divided by number of connections... WORK_MEM_KB=$(echo "scale=0; $MAX_MEM/$NUM_CONN" | bc -l) if [ $WORK_MEM_KB -gt $WORK_MEM ]; then while [ $WORK_MEM -lt $WORK_MEM_KB ]; do WORK_MEM_TEMP=$(echo "scale=0; $WORK_MEM*2" | bc -l) if [ $WORK_MEM_TEMP -lt $WORK_MEM_KB ]; then WORK_MEM=$(echo "scale=0; $WORK_MEM*2" | bc -l) else WORK_MEM_KB=0 fi done WORK_MEM_KB=$WORK_MEM; fi WORK_MEM=$(echo "scale=0; $WORK_MEM_KB/1024" | bc -l)MB # OS settings HOSTNAME=`hostname` # shm{mni,all,max} are critical to PostgreSQL starting. # They must be high enough for these settings: # max_connections # max_prepared_transactions # shared_buffers # wal_buffers # max_fsm_relations # max_fsm_pages echo -n "Checking the current kernel's shared memory settings..." # SHMMAX # # (BLOCK_SIZE + 208) * ((MAX_MEM * 1024) / PAGE_SIZE) * $SHARED_BUFFER_RATIO) SHMMAX=`sysctl $SYSCTL_KERNEL_NAME.shmmax | cut -d'=' -f2` OPTIMAL_SHMMAX=`echo "scale=0; (8192 + 208) * (($MAX_MEM * 1024) / $OS_PAGE_SIZE) * $SHARED_BUFFER_RATIO" | bc -l | cut -d'.' -f1`0 if [ $SHMMAX -lt $OPTIMAL_SHMMAX ]; then sysctl $SYSCTL_KERNEL_NAME.shmmax=$OPTIMAL_SHMMAX echo "$SYSCTL_KERNEL_NAME.shmmax=$OPTIMAL_SHMMAX" >> /etc/sysctl.conf fi # SHMMNI # # 4096 - 8192 SHMMNI=`sysctl $SYSCTL_KERNEL_NAME.shmmni | cut -d'=' -f2` OPTIMAL_SHMMNI=32768 # systems with large amounts of RAM, drop if you don't have 128GB or so... if [ $SHMMNI -lt $OPTIMAL_SHMMNI ]; then sysctl $SYSCTL_KERNEL_NAME.shmmni=$OPTIMAL_SHMMNI echo "$SYSCTL_KERNEL_NAME.shmmni=$OPTIMAL_SHMMNI" >> /etc/sysctl.conf fi # SHMALL # # SHMMAX / PAGE_SIZE SHMALL=`sysctl $SYSCTL_KERNEL_NAME.shmall | cut -d'=' -f2` OPTIMAL_SHMALL=`echo "scale=0; $OPTIMAL_SHMMAX / $OS_PAGE_SIZE" | bc -l | cut -d'.' -f1` if [ $SHMALL -lt $OPTIMAL_SHMALL ]; then sysctl $SYSCTL_KERNEL_NAME.shmall=$OPTIMAL_SHMALL echo "$SYSCTL_KERNEL_NAME.shmall=$OPTIMAL_SHMALL" >> /etc/sysctl.conf fi # convert MAX_MEM to MB MAX_MEM=$(echo "scale=0; $MAX_MEM/1024" | bc -l) SHARED_BUFFERS=$(echo "scale=0; $MAX_MEM * $SHARED_BUFFER_RATIO" | bc -l | cut -d'.' -f1) # There has been debate on this value on the postgresql mailing lists. # You might not get any performance gain over 8 GB. Please test! if [ $SHARED_BUFFERS -gt 12000 ]; then SHARED_BUFFERS=12000MB; else SHARED_BUFFERS="$SHARED_BUFFERS"MB fi if [ "$OS_TYPE" = "Linux" -o "$OS_TYPE" = "GNU/Linux" ]; then echo "Setting virtual memory sysctls" sysctl vm.swappiness=0 echo "vm.swappiness=0" >>/etc/sysctl.conf sysctl vm.overcommit_memory=2 echo "vm.overcommit_memory=2" >>/etc/sysctl.conf # >8GB RAM? Don't let dirty data build up...this can cause latency issues! # These settings taken from "PostgreSQL 9.0 High Performance" by Gregory Smith if [ $MAX_MEM -gt 8192 ]; then echo 2 > /proc/sys/vm/dirty_ratio echo 1 > /proc/sys/vm/dirty_background_ratio else echo 10 > /proc/sys/vm/dirty_ratio echo 5 > /proc/sys/vm/dirty_background_ratio fi fi WAL_BUFFERS="16MB" EFFECTIVE_CACHE_SIZE=$(echo "scale=0; $MAX_MEM * $EFFECTIVE_CACHE_RATIO" | bc -l | cut -d'.' -f1)MB ### NOW THE FUN STUFF!! echo "Applying system configuration settings to the server..." echo "This system appears to have $MAX_MEM MB maximum memory..." if [ -e $CONFIG_FILE ]; then echo "Setting data_directory to: $PGDATADIR" echo "Setting listen_addresses to: '*'" echo "Setting port to: 5432" echo "Setting max_connections to: $NUM_CONN" echo "Setting shared_buffers to: $SHARED_BUFFERS" echo "Setting work_mem to: $WORK_MEM" echo "Setting effective_cache_size to: $EFFECTIVE_CACHE_SIZE" echo "Setting checkpoint_segments to: $CHECKPOINT_SEG" echo "Setting maintenance_work_mem to: $MAINT_WORK_MEM" echo "Setting wal_buffers to: $WAL_BUFFERS" sed \ -e "s@[#]*data_directory = .*@data_directory = \'$PGDATADIR\'@" \ -e "s/[#]*listen_addresses = .*/listen_addresses = \'\*\'/" \ -e "s/[#]*port = .*/port = 5432/" \ -e "s/[#]*max_connections = .*/max_connections = $NUM_CONN/" \ -e "s/[#]*ssl = .*/ssl = false/" \ -e "s/[#]*shared_buffers = .*/shared_buffers = $SHARED_BUFFERS/" \ -e "s/[#]*work_mem = .*/work_mem = $WORK_MEM/" \ -e "s/[#]*effective_cache_size = .*/effective_cache_size = $EFFECTIVE_CACHE_SIZE/" \ -e "s/[#]*checkpoint_segments = .*/checkpoint_segments = $CHECKPOINT_SEG/" \ -e "s/[#]*maintenance_work_mem = .*/maintenance_work_mem = $MAINT_WORK_MEM/" \ -e "s/[#]*wal_buffers = .*/wal_buffers = $WAL_BUFFERS/" \ -e "s/[#]*cpu_tuple_cost = .*/cpu_tuple_cost = 0.002/" \ -e "s/[#]*cpu_index_tuple_cost = .*/cpu_index_tuple_cost = 0.0002/" \ -e "s/[#]*cpu_operator_cost = .*/cpu_operator_cost = 0.0005/" \ $CONFIG_FILE > $TEMP_FILE mv $TEMP_FILE $CONFIG_FILE else echo "Unable to locate the PostgreSQL config file! Can't continue!" exit 1 fi echo "Done!" 確認と設定反映 sysctl -p service postgres restart

こんにちは。藤原と申します。 新社会人の皆さんや、この4月に環境が変わった皆さんは、そろそろ慣れてきた頃でしょうか？ 日々の業務の中で面白さを感じることもあれば、焦りや戸惑いを感じたり、 もしかしたらマンネリを感じたりすることもあるかもしれません。 そんな時には、自分の会社の外から刺激を受けるということを試してほしいと思っています。 エンジニアには「勉強会」という絶好の機会があります。 せっかくの勉強会を楽しんでもらうために、試してほしいことをいくつか書きたいと思います。 まずは探して申し込んでみましょう。 普段やっていることはもちろん、やっていないことでも興味があるキーワードがあれば是非参加してみましょう。 もしくはこの人に会ってお話を伺ってみたい！というのも立派な理由だと思いますし、Facebookやtwitterなどで勧めてもらったから行くというのも良いと思います。 「ATND」「connpass」「doorkeeper」「こくちーず」などのイベント告知サイトに、 たくさんの勉強会がありますので、その中から探してみてください。 また「IT勉強会カレンダー」「upmeetup.info」などの、勉強会の予定をカレンダーでまとめているサービスもありますので、こちらも利用してみる良いと思います。 ただし、申し込んだあとに、仕事の都合やその他の理由でいけなくなった場合は、すぐにキャンセルをしましょう。 人気のある勉強会はキャンセル待ちをしている人がいるケースが多いので、参加できないことがわかった時点で、枠を必ず譲りましょう。 また、勉強会を開催してくれる方々にも迷惑がかかりますので、ドタキャンは絶対しないようにしましょう。 勉強会を開催する側からしても、参加してくれる人が多いのは本当に嬉しい悲鳴なんですが、ドタキャンが少なからずいて、キャンセル待ちをしていた人が参加できなくなって申し訳ない思いをさせてしまったりとか、心苦しいこともあります。 名刺を持って行きましょう。 自分の身分を明かした上で勉強会に参加する、ということは勇気がいるかもしれません。 ただ、名刺があることによって、話しかけるきっかけを作ることが出来たり、その1枚の名刺から思わぬ話が広がることもあります。 勉強会によっては名刺交換タイムを取っているケースも有ります。 社外に知り合いを作り、刺激を受ける良い機会ですので、できれば名刺を持参しましょう。 また主催した方と名刺交換しておくと、次の勉強会の案内をいただけたりするメリットも有ります。 できれば懇親会に参加してみましょう。 勉強会終了後にはおおよその場合、懇親会もしくはビアバッシュという形で飲み会が行われます。 勉強会の中で質問できなかったことや、他にも聞いてみたい事がある人は、この懇親会が一番のチャンスです。 講師の方や他の参加者により突っ込んだ話を伺うことが出来たり、社外に自分と同じような立場の知り合いを作ることが出来る絶好の機会です。 「どうしても話しかけにくい」「なかなか思い切って聞くことが出来ない」なんていうこともあるかもしれません。 その際は運営スタッフの方に声をかけてみましょう。 きっと間を取り持ってくれるはずですし、いろいろ聞いてくれると思います。 終わったらブログを書いてみましょう。 折角勉強会に参加したのですから、その内容や感想をまとめる意味でブログを書いてみましょう。 自分の知識の整理にもなりますし、もしかしたら思わぬフィードバックがもらえるかもしれません。 また、勉強会によっては、ブログを書くことで特典をつけてくれるものもあります。 自分自身、運営スタッフとしてブログを読ませてもらうこともありますが、率直な感想や、貴重なご意見をもらうことが出来て大変嬉しいですし、また厳しい意見などは、今後の勉強会運営を改善するための貴重なご意見として、活用させて頂いてます。 最後に もし勉強会に参加することに面白さを感じたら、その応用編として「小規模な勉強会」「勉強会のスタッフになってみる」というのも大変おもしろいと思います。 今まで自分が参加していた勉強会のスタッフになると、いろんな裏側が分かったり、講師の方とお近づきになる機会が増えたりと、いろんなメリットがあります。 もちろん大変なことも多いですが、それ以上に充実感が得られると思います。 また、もし良ければ弊社のスマートデバイスアプリエンジニア2名が6/3にレバレジーズ株式会社様にて講演をさせていただきますので、ぜひご参加いただければと思います。 【ヒカ☆ラボ】「HOME'S」の開発スタッフが語るスマートデバイスアプリ開発秘話( http://connpass.com/event/6204/ ) この記事を読んでいただいた一人でも多くの方が、勉強会に興味を持っていただき、参加してみようかな？と思っていただければ、大変嬉しく思います。

こんにちは、鈴木です。仕事でMacを使う機会が多くなりました。 ある程度のツールはWindowsでもMacでも同じように使えるのですが、 MacのExcelはWindowsのコマンドと結構違うのです。 WindowsのOfficeにずいぶん長く慣れてきたので、 MacのExcelコマンドにいまさら慣れる気もないなあ。 キーも多いし。。。 これは不便！なんとか便利にしたい！ というわけで、自分なりの解決方法を紹介します。 [免責事項] 本記載と紹介したソフトウェアについては自己の責任に基づいてご利用ください 今回紹介したソフトウェアと株式会社ネクストは関係がありません 実現したいこと F2でセルの編集を始めたい！ デフォルトショートカットコマンド：[control] + [U] ↓ 再現したいショートカットコマンド：[F2] セル内の改行を使いやすくしたい！ デフォルトショートカットコマンド：[alt] + [option] + [enter] 　↓ 再現したいショートカットコマンド：[fn] + [enter] やること KeyRemap4MacBookをインストール 　 https://pqrs.org/macosx/keyremap4macbook/index.html.ja KeyRemap4MacBookを設定 　基本的にこのソフトは起動中ずっとキーの役割を入れ替えることができるアプリなのですが、今回はMac用のExcelが起動しているときだけ有効になる設定を用います。 KeyRemap4Macbookのprivate.xmlを編集 [Misc & Uninstall] > [Open private.xml] private.xmlが格納してあるディレクトリが開くので、 好きなテキストエディタで下記のように 以下の 項目を記載してください。 もともと他の設定が入っている場合は追記するようにしてください。 下記部分的に抜粋 <list> <item> <name>[Excel] Fn & Return to ReturnInCell</name> <identifier>private.app_excel_Fn&Return</identifier> <only>EXCEL</only> <autogen> --KeyToKey-- KeyCode::RETURN, ModifierFlag::FN, KeyCode::RETURN, ModifierFlag::OPTION_L | ModifierFlag::COMMAND_L </autogen> </item> <item> <name>[Excel] F2 to EditCell</name> <identifier>private.app_excel_f2</identifier> <only>EXCEL</only> <autogen> --KeyToKey-- KeyCode::F2, KeyCode::U, ModifierFlag::CONTROL_L </autogen> </item> </list> 編集後の例 [ChangeKey]タブでReloadXMLを押すと、 さっきの項目が表示されるので、チェックします。 これで、Windowsと同じように、F2でセルの編集を開始、 fnとリターンキー同時押しでセル内改行、ができるようになりました！ 日々の仕事も改善して効率的に楽しくしたいですね。 もう少し詳しく知りたい方へ 利用できるKeyCode/ModiferFlag一覧 List of KeyCode https://github.com/tekezo/KeyRemap4MacBook/blob/version_9.3.0/src/bridge/generator/keycode/data/KeyCode.data/ List of ModifierFlag https://github.com/tekezo/KeyRemap4MacBook/blob/version_9.3.0/src/bridge/generator/keycode/data/ModifierFlag.data/ List of ConsumerKeyCode (Brightness Control, Audio Volume Control, Music Control, etc) https://github.com/tekezo/KeyRemap4MacBook/blob/version_9.3.0/src/bridge/generator/keycode/data/ConsumerKeyCode.data/ List of PointingButton https://github.com/tekezo/KeyRemap4MacBook/blob/version_9.3.0/src/bridge/generator/keycode/data/PointingButton.data/ 構文例 KeyをKeyに変えるとき 　Spaceを押ししたときに、Tabにする <autogen> KeyToKey KeyCode::SPACE, KeyCode::TAB</autogen> 　一つ目のKeyCodeが変更前、二つ目のKeyCodeが変更後。それをカンマで区切る KeyとModifierをKeyに変えるとき 　Space,Control_Lを同時押ししたときに、Tabにする <autogen> KeyToKey KeyCode::SPACE, ModifierFlag::CONTROL_L, KeyCode::TAB </autogen> 　一つ目のKeyCodeから二つ目のKeyCodeまでが変更前、それ以降が変更後 KeyとModifierをKeyとModifierに変えるとき 　Space,Control_Lを同時押ししたときに、Tab,Control_L同時押しにする <autogen> KeyToKey KeyCode::SPACE, ModifierFlag::CONTROL_L, KeyCode::TAB, ModifierFlag::CONTROL_L </autogen> 　 　一つ目のKeyCodeから二つ目のKeyCodeまでが変更前、それ以降が変更後 　 Keyと複数のModifierをKeyに変えるとき 　Space,Control_L,Fnを同時押ししたときに、Tabにする <autogen> KeyToKey KeyCode::SPACE, ModifierFlag::CONTROL_L | ModifierFlag::FN, KeyCode::TAB </autogen> 一つ目のKeyCodeから二つ目のKeyCodeまでが変更前、それ以降が変更後 かつ一つ目の修飾子と二つ目の修飾子の間はカンマではなくパイプで区切る KeyとModifierをKeyとModifierに変えるとき 　Space,Control_Lを同時押ししたときに、Tab,Control_Lにする <autogen> KeyToKey KeyCode::SPACE, ModifierFlag::CONTROL_L, KeyCode::TAB, ModifierFlag::CONTROL_L </autogen> 　一つ目のKeyCodeから二つ目のKeyCodeまでが変更前、それ以降が変更後、特定のKeyとModiferの組み合わせのみ反応するようにする 　Space,Fnを同時押ししたときに、Tabにして、Space,Fn,<任意のキー>で反応しないようにする <autogen> KeyToKey KeyCode::SPACE, ModifierFlag::FN | ModifierFlag::NONE, KeyCode::TAB </autogen> 　明示的に　| ModifierFlag::NONE　を加えればいいみたいです 参考URL KeyRemap4MacBook - マニュアル https://pqrs.org/macosx/keyremap4macbook/document.html.ja KeyRemap4MacBook - private.xml Reference Manual https://pqrs.org/macosx/keyremap4macbook/xml.html.ja 動作を確認した環境 MacOS ver. 10.8.4 Microsoft Excel for Mac 2011 ver. 14.1.0 KeyRemap4MacBook ver. 8.4.0 CotEditor ver.1.4.1

最近「Apple原理主義者」と合わせ「Origami原理主義者」と名乗ろうかと考えている大坪です。 先日行われたFacebookの f8 デベロパーカンファレンス での Origami のデモを紹介します。 まずこのビデオ。新しくなったFacebook Messengerアプリに関するプレゼンですが.. この「Facebook Messengerアプリ」のように見えるものは、一行のコードも含まず、デザイナーが「空いた時間を使って一週間で作った」とのこと。 このプレゼン中で述べられているOrigami(Quartz Composer）の特徴は Visual: not like Javascript Real time : not like After Effects Non-Linear: not like Flash Photoshopで静的なイメージを作るより、少しデザインにかかる時間は増える。しかし開発全体で観れば大きな時間の節約になる。 他にも例えばメッセージ一覧画面のデザインを決めるまでにどれだけのパターンを試したのか、アイコンを何種類試し最終的なデザインに落ち着いたのか、サウンドは、など見所が満載のプレゼンテーションです。 もう一つは本家Paperのプレゼンテーション中のデモ。（画面左上のOrigamiアイコンに注意してください） このビデオを見ると、Paperが実際のコードで動く前に、Origamiで非常に詳細に「デザイン」されていたことが見て取れます。 このプレゼンをしているのはPaperのEngineeringチームのマネージャなのですが、 「このプロトをみているうちに、心配になってきた」 と言っています。そりゃそうだろう。Origami上で見事に動いても、同じことが実コードで再現できるとは限りません。このプロトのように「誰も観た事がない」ようなインタラクションが実現されていればなおさらのことです。 どうしたらこのような動きが実現できるのか？「普通に実装」するとこんなぎこちない動きになってしまいます。 ああ、、そうだよ。普通に作るとこうなっちゃうんだよ（体験談） ではここからPaperチームはどのような方法をとったか、についてはまた別の機会に（とか書いちゃっていいのか） このプレゼンの最後の方にこういう文字がでてきます。 "Accept the challenge of ambitious design" 野心的なデザインのチャレンジを受けて立つ Paperのデザインチームは 「今使うことができる画面部品」 からスタートしたのではなく 「モバイルアプリのUIはどうあるべきか」 からスタートし、Origamiでプロトを作り上げました。エンジニアチームはそれを 「信じられないくらいスルスル動く」 実際のアプリに結実させた。 マウスとキーボードで、離れた場所にある大画面を操作するデスクトップアプリのUIと、手のひらの中にあるディスプレイをタッチで操作するモバイルアプリのUIは根本的に違うものであるべきではないか。こうして文字にすると当たり前のようですが、我々はまだこの「違い」に気が付き始めたところなのかもしれません。 とかなんとか取り乱しているのは私だけですか？そうですか。

はじめまして、株式会社ネクスト　リッテルラボラトリーの清田です。 もともと、私は大学の研究者だったころに創業メンバーとして関わった大学発ベンチャー「リッテル」にて、図書館などの膨大な情報をさがしやすくするシステムなどの研究開発にたずさわっていました。 2011年にネクストにジョイン してからは、 HOME'S の膨大なログデータの裏にかくれた潜在的なニーズの発見など、情報レコメンデーション技術の研究開発に日々取り組んでいます。 今回、これまでの研究成果のひとつとして、 スマートフォンアプリ「ホームズくんのこれからシアター」をリリース しました。 （ iOS と Android 、両方に対応しています） ホームズくん や劇場のなかにいる動物たちからの質問にタッチ操作で答えていくだけで、理想の住まいへホームズくんが案内してくれるというコンセプトのアプリです。 アプリの制作にあたっては、 面白法人カヤック さんに多大なご協力をいただきました。 インストールはこちらから iOS（iPhone、iPod、iPad） Android この記事では、「ホームズくんのこれからシアター」の裏側にあるコンセプトをいくつかお伝えしたいと思います。 「理想の住まい」にどうやって案内するか？ 家探しをしたことがある方はご存知のとおり、最初から思い描いていた条件（場所、値段、間取り、築年数、楽器可や南向きなどのこだわり条件、その他もろもろ）がすべて一致する物件にいきなり出会えることは、まずありません。 家探しをする人は、さまざまな制約（収入、家族構成、勤務先・通学先、引越しの時期など）がある中で、現実に存在する物件をみながら、「どの条件を優先するか」「どの条件を妥協するか」という決断を迫られます。 より満足できる住まいはどれかと悩みながらも、物件検索サイトでの検索や物件の見学、身近な人への相談などの行動を続けることで、決断に近づいていきます。 最終的に契約を決めた物件が、最初に思い描いていた条件からだいぶかけ離れていることも少なくありません。 家探しにかぎらず、何かを「探す」というプロセスでは、人間がもっている知識が、情報に出会うことで変化しつづけることが知られています。 イギリスの情報学者ブルックスは、情報に出会うことで知識がどう変化するかを、以下の式（ブルックスの方程式）で端的に表現しています *1 *2 。 K[S] + ΔI = K[S + ΔS] K[S]: 情報を得る前のSに対する知識 ΔI: 獲得した情報 K[S+ΔS]: 情報を得た後の知識 この式は、人間の知識は出会った情報が単純に足し算されるわけではなく、情報と出会うことで知識の構造自体がダイナミックに変化しつづけることを表しています。 ブルックスの方程式を、家探しをしている人にあてはめてみましょう。 「出会った物件や物件情報が住まい探しの条件をそのまま左右する」という理解は、正しくないことがわかります。 「物件や物件情報との出会いをきっかけとして、自分が本当は何を次の住まいに求めているのかをじっくり考えることによって、理想の住まいにより近づくために、自分の知識を変化させていく」というのが、本来の住まい探しのあり方だということが言えるのではないでしょうか。 「理想の住まい」に案内するために、ユーザーに質問を投げかけるという「ホームズくんのこれからシアター」のコンセプトは、「ユーザーがじっくり考えるきっかけをつくることが、結局は理想の住まいにたどりつく近道である」という考え方からきています。 「理想の住まい」へのヒントをどうやって提案するか？ 「ホームズくんのこれからシアター」では、2〜3個の質問回答を数回繰り返した後、ユーザーが住まいに対して求めていると思われる条件を、ホームズくんがヒントとしていくつか提案してくれます。 「質問でユーザーが選んだ選択肢」と、「ホームズくんが提案してくれるヒント」をどのように結びつけるかについては、現時点では明確な正解はありません。 ただ、「理想の住まいかどうかを決めるのはけっきょく本人の主観」であり、「理想の住まいに対する知識は変化しつづける」というブルックスの方程式の考え方を前提とすると、 ベイズ確率 の概念は非常に参考になります。 「これからシアター」の裏側では、ベイズ確率の概念を利用して、質問でユーザーが選んだ選択肢によって、ユーザーに提案するヒント（の確率）を更新していくという仕組みが動いています。 以下の図にあるように、たとえば「将来不安に思っていることは？」という質問で選んだ選択肢によって、ユーザーが「ファミリー向け物件」にどれくらい関心をもっているかを表す数値（確率）を更新していくことで、どのヒントを提案するかを決めています。 住まい探しをするユーザーのニーズはどのように変化するか？ 住まい探しをするユーザーの本当のニーズを知るのは、簡単ではありません。 住まい探しをつづけるユーザーは、情報を受け取りながら「理想の住まい」へ近づくために、住まいへのニーズを変化させていきます。 どのように自分のニーズを変化させているかは、ユーザー自身でさえうまく説明できないものです。 ユーザーの行動（物件情報の検索、閲覧、物件の見学、契約など）の裏にかくれた本当のニーズを探るため、ネクストではログデータの分析やアンケートなど、さまざまな取り組みをつづけています。 ここでは、自然言語処理の分野でよく利用されているLatent Dirichlet Allocation（LDA、潜在的トピックモデルの一種）によるログデータ分析の取り組みを紹介します。 HOME'Sなどの物件検索サイトを使って住まい探しをするユーザーは、一度のサイト訪問だけで住まい探しを完結させることはむしろまれで、数日間〜数週間にわたって物件情報を探しつづけるのがふつうです。 場合によっては、不動産会社に足を運んだあともサイトで検索したりもします。 そこで、一度のサイト訪問（セッション）を「文書」、サイト訪問内でのユーザー行動（検索操作、検索条件、物件情報閲覧など）を「文書中に出現するキーワード」になぞらえて、LDAによる分析を試みました。 上の図は、（おもに賃貸物件を探している）ユーザーのニーズが、時間の経過とともにどのように変化していくかを可視化したものです。 はじめはただ漠然と物件リストを眺めていたユーザーが、訪問回数を重ねるにつれてより具体的な行動（物件情報の閲覧、お気に入りへの登録、物件検索条件の変更、不動産会社への問い合わせ）に移っていく様子がわかります。 また、「 地図での検索 しか使わないユーザーが一定割合いること」「不動産会社への問い合わせから数日後、物件名などをサーチエンジンで検索してHOME'Sを再訪するユーザーがいること」なども読み取れます。 上の図は、 住まい探しに役立つコンテンツ の閲覧ログを対象に、同様の分析を試みたものです。 住まい探しをはじめるユーザーの興味はすべて同じではなく、「住まい自体」「次の住まい」「ライフプラン」など、いくつかの異なる興味をきっかけに住まい探しをはじめていること 漠然とした興味をもっているユーザーは、「住み替えニーズ」や「住まいのイメージ」を扱ったコンテンツの閲覧をへて、具体的な住まい探しの行動を起こせるように自らの住まいへのニーズを明確にしていっていること などが読み取れます。 おわりに 「これからシアター」では、「住まい探しのイメージを具体化させるのに役立つ質問は何か」「ユーザーの真のニーズを把握するには、どんなユーザー行動の分析が有用か」といった研究課題に、アプリの運用をつうじて取り組んでいく予定です。 アプリの運用から得られた知見についても、エンジニアブログなどを通じて発信していきます。 ぜひ実際にアプリをさわっていただき、多くのフィードバックをいただけるとうれしいです！ 参考文献 *1 : B. C. Brookes. 1980. The foundation of information science. Part I. Philosophical aspects. Journal of Information Science, 2, 125-133. PDF *2 : 三輪眞紀子. 2003. 情報検索のスキル −未知の問題をどう解くか. 中公新書, 1714, 中央公論新社. Amazon