こんにちは。藤原です。 スキルアップのために本をガッツリ読んだり、やりたいことの整理をしたいけど、なかなか普段は時間がとれなくて・・・、という方も多いと思います。また、それを家でやろうとすると、誘惑が多くてなかなか手を付けられないとか、環境を作ることが出来なくて自宅だと進まない！という方もいらっしゃるかと思います(私です)。 やりたい、やらなきゃいけないと思っていたことを積みに積んでいた中で、スケジュールがポッと空いてしまい、かつ残っている有給を有意義に消化したい、でも旅行に行く計画も急すぎて難しい・・・というところで試してみたのが「 一人合宿 」です。 で、その「一人合宿」をやるにあたって、自分が行った事前準備と、実際やってみてどうだったか、ということを書いてみたいと思います。 一人合宿の事前準備 目的とやりたいこと(タスク)の整理 何をどこまでやればゴールとするのか、ということを事前に決めて計画を立てておきましょう。 ターゲットを絞っておきましょう。 あれもこれもと手を出すと全部中途半端になるのと、途中で嫌になって何も進まなくなってしまう可能性があります。 スケジュール 出来れば2泊3日以上のスケジュールを組みましょう。 1泊だとすぐに終わってしまい、なかなか成果を出しにくいと思います。 また、睡眠時間をけずってやっても良いinput/outputが出にくいと思うので、あまり無理な予定を立てないことが大切かと思います。 初日にある程度軽いタスクを計画すると良いです。 これで行けるというペースを把握し、2日目以降に腰を据えてやるタスクを計画するとよいでしょう。 場所の選び方 個人の好みによりますが、和室よりも洋室を選んだほうが良いかと思います。 畳で寝転がってやったほうが進む！という方の場合は別ですが、いつでも机に向かえる、いつでもベットで休める環境の方が、メリハリは付けられやすいかな、と思います。 机が広い場所を選びましょう。 ノートPCを広げたら一杯になってしまい、本やノートを広げることが出来ないとちょっと厳しいです。 照明が明るいところを探しましょう。 ビジネスホテルは割合照明が暗いところのほうが多いです。 できれば加湿器が設置してあると良いです。 空調によって室内が乾燥することが多く、体調を崩すこともあります。 （濡らしたタオルを干しておくことでも乾燥を防ぐことが出来ます） ある程度交通の便が良い場所をおすすめします。 それなりに機材を持ち込むとなると荷物も自然と大きくなります。 荷物の持ち運びなどを考えた場合、駅から近いほうが楽かと思います。 （自分の場合は、ターミナル駅から徒歩2,3分程度の場所で試しました。） 近くにコンビニ等があるところを見つけましょう。 あまり観光地すぎるところに行くと、徒歩圏内にコンビニがないことがあって、ちょっとした買い出しなどに困ることもあるかもしれません・・・。 機材持ち込み インターネット回線(wi-fi) ホテルのLANは有線・無線ともにつながらないとか、速度が出ないことがありがちです。 またホテルから、無線LANとしてFree Wi-fiが提供されていることがありますが、気分的にもあまりよろしくないかなーという感じがします（あくまでも個人的な感想ですが）。 なお、持ち込む回線のキャリアが、サービス提供エリアであるかを忘れずに確認しておきましょう。 （地方だとサービスエリア外ということがあり得ます・・・） ヘッドフォン/イヤホン 音楽を聞きながら作業をする方はぜひイヤホン・ヘッドフォンを持ち込んでください。 集中するためというのもありますが、周囲に迷惑を掛けないという理由もあります。 ブックスタンド 本を開きながらPCに向かうのであれば必要かと思います。 amazonで1000円前後で売っているので、そのくらいで十分かと思います。 （荷物もあまり大きくならないほうがいいでしょうから） その他準備したもの 個人的に準備したものとして、軽くつまめるお菓子類や、水やお茶を事前に買って持ち込んだり、 作業着としてリラックスできる普段着を持参しました。（ホテルの浴衣だと作業しづらいですし・・・) やってみた感想 当初の見積もりよりも、「タスクごと」の進捗が出やすいです。普段の業務効率で計算すると、差し込みがない分集中度合いが増し、結果として予定より早く終えられたりしました。 ただし疲労もいつも以上にでます。2日目の夕方以降は姿勢が悪かったせいか、肩こりなどで体調を若干崩してしまい、その後の進捗を出すことが出来ませんでした・・・。 手を動かせば進捗が明らかなもののほうが良さそうです。 ドハマりしそうなタスクは避けたほうが良いです。 アプリでいろいろ試そうとしたものの、やり方が分からず調査に時間をかけたら、半日過ぎてしまったということがありました。お金かけたのに成果でなくて何やってんだろう・・・って感じを避けることも必要かと思います（苦笑）。 結果的には最低限やりたいことは一通り着手でき、形にも残すことが出来たので、良い「一人合宿」を過ごすことが出来たかと思いました。 ちなみに具体的な成果として「既存のアプリのデザイン改修案作成」「プレゼン資料の下書き」「ブログの下書き」というタスクはおおよそ予定通り出来たのですが、「アプリのモックを作る」のがまさにドハマりタスクで、進捗があまり進められず・・・。「読めなかった本に手を付ける」ことがおざなりになってしまいましたが、優先順位が高いものは何とか出来た！という感じでした。 普段時間が無い人にこそ、オススメな方法かと思いますので、良ければぜひ試してもらえれば、と思います。

こんにちは、上津原です。 タイトル通りですが、Unity5が出たので早速移植をしてみました。 機能実装はしてないんですが、見た目がどれくらい変わるのか気になったのです。 ビフォー Unity4で作ったときのが以下です。 いやー、恥ずかしい！当時全力で作ったのですが、今の自分から見ると「あ～ららｗ」という感じにしか見えません。まあでも今もそれほど腕は進化してないんですけどね…。 さて、これらのモデルをまるっとUnity5に持ってきて、デフォルトマテリアルにちょっと色を付けた程度のもので作ってみたのが… アフター じゃーん！こちらです。 かなり柔らかな光表現になっています。シェーダーは一切使っていません。 Unity5になって大きく変わった点は、光の反射表現がとっても手軽になっていたので、天井の日当たりが自然になったというのが感動的でした。同じモデルなのに、光の表現だけで結構それなりに見えてくるのが不思議です。 これらには、ノーマルマップもないしシェーダーも使ってないので、きちんと揃えてゆけばもっと幅広くて素敵な映像表現ができそうですね。 これがまさか無料になるとは UE4が先日無料になったので「あー、これはUE4一択だわー」みたいに思っていたのですが、まさかUnity Freeに全機能が入ってくるとは思ってもみませんでした。 個人的に比較してみると、手軽にリアルな映像表現という点ではUE4に軍配が上がりますが、汎用性や軽さという点ではUnityに軍配が上がります。 モバイルので利用は圧倒的にUnityなんだろうな、ノウハウもあるし。 UE4とUnity、それぞれこれからの展開が楽しみですね。

こんにちは、上津原です。 まだ寒いですが、こたつを片付けてしまいました。後悔しています。 さて、今回もまたpepperの話題です。 題名の通り、他のアプリケーションをコントロールする方法です。 あるビヘイビアを実行中に、別のビヘイビアのあの機能が使いたいのに！という時ありますよね。だけどそれってどうすれば？という時に、ALMemory使えばいけるんじゃないか？ってことで試してみたら動いたのでご紹介します。 RunBehaviorして、ALMemoryのraiseEventしてやればOK はい、上記のとおりです。開発環境があればChoregrapheで並列実行してやればいいですが、スタンドアロンで動いて貰う場合そうは行かないので、さくっと実装してやります。 ChoregrapheでRunBehaviorをやると並列してビヘイビアが実行されるので、ALMemoryを利用した連携が可能になる 、ということになります。 では実際に見てみましょう。 それぞれの構成はこんなかんじ。 メインビヘイビア サブビヘイビア この時点ではメモリイベントは抜いてあります。 メインビヘイビアが実行されたら、ちょっと喋ってサブビヘイビアが立ち上がるようになっています。 それをここからメモリイベントを追加していきます。 サブビヘイビアにメモリイベントを作成 サブビヘイビアのここにある「＋」を押して、メモリイベントの一覧を出します。 そして、下の方にある「新しいキーの追加」を押して独自キーを作成します。 今回は「subBehavior/event1」としました。 そうしたら、左隅に「〜」みたいなマークが出来ます。 これがメモリイベントのスタートポイントになります。 とりあえずSayをくっつけて「メモリイベントだよ」と喋るようにしておきました。 メインビヘイビアにRaiseEventを作成 呼び出されるイベントの作成は完了したので、後はそれを実行するだけです。メインビヘイビアに実行部分を作っていきます。 とりあえず今回はお手軽な「Tactile Head」を使いました。pepperの頭のタッチセンサーですね。 シミュレータの人は動かないと思うのでSpeechRecoなど、インプットがこちらから任意に出来るものを利用すればいいと思います。 そしてRaiseEventノードをつないで、先ほど設定した「subBehavior/event1」を入力します。 コレで出来上がりです！簡単ですね！ メインビヘイビアを実行 メインビヘイビアを実行すると、サブビヘイビアが立ち上がり、その後頭を触ると先ほど設定した「メモリイベントだよ」を喋ってくれます。 RaiseEventは、インプットタイプが「ダイナミック」に設定してあります。つまり、ここにイベントに渡したい情報（文字列、数字など）を渡してやれば、 変数の受け渡しも可能になります。 わ～ベンリ！ まとめ Choregparheを利用してロジックを組む場合、クラスやインスタンスを呼び出したりという行為が出来ないっぽいので、ALMemoryを利用したテクニックは必須になると思います。 そして一旦使い方がわかると一気に可能性の幅が広がります。前回紹介したQiMessaging.jsもALMemoryにアクセスできるので、JSでペッパーと相互でデータのやり取りも可能になったりもします。 今回のプロジェクトもGithubにアップしておきますので、もし良かったら自由に使ってください（とっても簡単なものですけど…） kuetsuhara/pepper_almemory_heiretsu kuetsuhara/pepper_almemory_heiretsu · GitHub それでは。

こんばんは、Androidグループの中村です。 先日、テスト自動化のセミナーに参加してきました。 自動化する時の観点について、 テスト自動化研究会 のコミッターとしても活躍されている浦山さつきさんから、興味深い話があったので共有したいと思います。 自動化対象選びのポイント「手順が決まっていて実行頻度の高いもの」 繰り返し行われること 面倒くさいと思っていること ミスが起こりやすいところ 手順が決まっているところ 変更が少ないところ 以上が自動化対象選びのポイントとのことです。 面倒くさいと思っているから作業者の集中力が切れてミスする、見誤ってミスする、これってせっかく作業しているのに本末転倒… でも意外とこういうことってありますよね。 あと、プロセスを見直すことで手順を定め、自動化も可能になるかもしれないということは 通常業務の見直しもでき、お得感がありますね。 またまた、変更が少ない箇所を自動化するっていうのは私がこれまで行ってきた業務からもそうだなと感じます。 頻繁に変更されている画面のテストなどを自動化してしまうと、メンテナンスのコストがかかってしょうがないです。 自動化だけが策ではない! 手順が決まっていないと自動化できない 一見すると、自動化に向いた作業でも実はやらなくてもいい作業かもしれない 情報伝達ができていないだけであれば自動化することはない 役に立たないテストや作業を自動化しても意味がない この観点は、仕事の中で忘れがちではないかなと思います! なんでもかんでも自動化すればよいのではなく、対象をきちんと選別し、効果のある作業を自動化する! これでよりいっそうの仕事効率化がはかれますね。 自動化導入時の3ステップ 「計画 -> 試す -> 広める」 自動化を新たに導入するときには、3ステップ踏むとよいとのことです。 【計画】 関係者を決める 「推進役」「変革の請負人」「組織上層部の支援者」 道具を選ぶ 身近にあるツールや技術を使う、関係者の知見経験を使う 試算する 一時的な生産性の低下は避けられない、どこで巻き返せるのか試算する 試算する要素としては道具にかかるコスト、自動化にかかる時間とコスト、失敗したテストを確認するコスト(なにが原因なのか解析する時間) メンテナンスにかかるコスト、教育にかかるコスト、期待できる効果等があるとのことです。 【試す】 パイロットプロジェクトを立ち上げる 自動化した仕組みがうまく適用できるか検証する 実現可能か見極める ここでの数値が広める時の根拠になる パイロットプロジェクトの効果を見ることで、既存プロセスへの影響を再確認ができ、新しいツールや手順について学習ができるとというメリットがあるとのことです。 【広める】 共有する 成功の根拠を提示して同意をえる 内部からの反発に注意 支援する 最初はパイロットプロジェクトを実行した人が一緒にやる 他の人への教育も行う 見守る 効果を監視する フィードバックをもらい、計画の見直しを行う ここで注意しないといけないのが「内部からの反発」とのこと… プロジェクトの目的、役割を考えさせたり、そして…組織上層部の支援者からのトップダウンも効果的とのことです。 Androidグループ ちなみに、私たちのグループでは Jenkinsを導入しています。 ユニットテストを一定間隔で実行したり、 ビルドを自動化し、 デプロイゲート というツールをつかって 企画、制作、開発メンバーがapkをWebからダウンロードし、テストをみんなで行える環境を構築する等を行っています。 まだまだ自動化して効率化できる箇所もあると思います。 浦山さんの話にもあったようにプロセスの見直しをはかり、開発効率をあげて、よりよりアプリを提供していきたいと思っています。 おわり

はろーはろー！チバと申します。 2014年9月にジョインしたばかりの新参者でして、当ブログへの投稿も初めてとなります。 今回は弊社を会場にしてTech系イベントを開催したので、そのときのレポートをお送りします！ 「タスク管理ツールNight!」とは 実際に組織・個人で使用しているタスク管理ツールの使い心地、使い方の工夫を熱く語ってもらうイベント です。 今回は6ツールにフューチャーして、それぞれを使用しているユーザーの方々に登壇していただきました！ 「ツールの導入検討をしている方」 、 「ツールをうまく活用できていない気がする」 などを課題としている方をターゲットに告知し、開催へ至りました。 弊社内でも最近Atlassian社のJIRAを導入した部署があります。 しかし、「よく出来たツールだと思う！使いやすい！でも、もっと活用できるのではないか」と疑問を抱いていたため、 タスク駆動を考えなおす機会 として主催に踏み切りました。 紹介されたツール Trello Chatwork Github Issue JIRA Pivotal Traker esa 募集をかけた際に驚いたのですが、かつて一世を風靡していたRedmine http://redmine.jp/ やBacklog http://www.backlog.jp/ などが出てこないんですね…！ もう彼らは過去のモノなのか、はたまた今回集まった人たちには刺さらないニーズなのか… 当日の様子 イベントはスピーカー6人を中心に、 LT（Lightning Tark）と座談会の二部制 でお送りしました。 LT…ツールの概要や導入経緯、目的の話をしてもらう。 座談会…設けた2つのテーマに沿ってフリートークしてもらう。 1. LT 1. slackとtrelloで幸せになる　張ヶ谷 拓実さん タスクカンバンツールのTrelloと、チャットツールslackを使って、情報をうまくフロー型とストック型に分けて運用している よ、というお話です。 Trelloのいいところ、としてUIとFilterを挙げられており、確かに「 ツールを使う気にさせる」の設計 にはTrelloは非常に優れているなあ、と感じました。 ステータスも随時サクサクっとアップデートできるため、現場感高めなチームにはとても向いてると思います。 2. 仕事がデキる障害者は皆使っている？ITが苦手な方にこそオススメしたいタスク管理ツール　白井 祥剛さん 初期の営業成果が実り、今では誰もが知ってるツールになったChatwork！そんなChatworkを用いて、遠隔コミュニケーションに支障が出ないようにこんなタスクの運用ルールを設けているよ、ってお話です。 プロジェクトごとにグループを作成し、 乱雑にグループが作られないようにルール化 し、 完了基準を明確 にしてタスクとするなど、チームに最適化された使い方でとても羨ましいと思えました。 3. お金の無いプロジェクトでgithub issueで円滑に開発を進める方法 (仮)　joker1007さん タスク発行時の入力項目が多いと、タスクを捌くことがおざなりになってしまった ことから使い始めたってお話です。 外部サービスであることから メンテナンス要員が必要なく 、さらに コードとも連携できる ため、タスクに基づいた開発ができるいい感じの運用をされています。 Githubの弱点を補なうサービスとして紹介されていたWaffle https://waffle.io/ がよさ気なので、試してみたいなぁと思いました。 ★スライド公開されてます。 4. 経営者が唸る！JIRAによるタスク稼働管理 　佐藤 卓也さん 経営と開発と事業をつなぐことが可能であるため、JIRAをチョイスしたよ、というお話です。 個人的に、タスクは未来を作るものだと思っていまして、 Doneしたデータが予算決めや経営会議の材料として活用されている ってのはめちゃくちゃ熱かったです。 また、 月初までにEpicやStoryを用意して、月に入ったと同時にタスクが動き始めるルール はとてもいいなあと思いました。 ★スライド公開されてます。 タスク管理Night　JIRA推し from Takuya Sato 5. PivotalのWorkspaceを有効活用する方法　小島 泰洋さん もともと紙付箋で管理していたが、デジタルにして 優先度順にタスクを俯瞰できるように したよってお話。 タスクのVelocityをちゃんと見積もれて いて、且つ それの精度が開発期間と＝にして活用しきれている のが素晴らしいですね。 物理カンバンでの限界を感じたときには、まずPivotal Trackerに手を出してみるといいのかもと思いました。 ★スライド公開されてます。 PivotalTrackerでシンプルなタスク管理のススメ from Taiyo Kojima 6. ポエムで支える月間38億PVメディア開発(仮) こしば としあきさん 今回はタスク管理の“それ以前”、「終わった」、「終わっていない」を管理する前である 「タスク管理になにを載せるかを見つけるため」 に使っているツールのお話。 「タスク」に成り得る前である定義されていない「これやってみたいんだよね」などを共有するには、ポエムを推奨したいとのことでした。 誰かが思いつきで言った一言を、皆で育ててタスクへ昇華させるようなフローで運用 されており、ブレストっぽさを感じました。 近々、esaのMeetUpがあるとのことです。（キャンセル待ち！） (\\( ⁰⊖⁰)/)会 - esa | Doorkeeper 2. 座談会 1. タスク管理ツール利用遍歴 タスクを残す奴は許せない論 が出ました。 期限切れ放置タスクの問題、そもそもは「とりあえずタスクにしておこう」が動機であることが多いため、 まずは「タスク」にすることの定義など、明確な運用ルールを設ける必要がある よね、と落ち着きました。 それと、今回はタスク管理ツール × チャットツールのお話も多めだったことから、会話の流れにタスクを関わらせることの話にも触れられていたかと思います。 通知としてチャットツールを活用したり と、 なにかと併用することでの利便性向上 の未来が見えました！ 2. タスク管理で尊重する流儀 運用上でのルールのお話がところどころであったことから、触れておきたいなと思ったテーマです。 「これは譲れない」、「これは守るべきものだと思う」なルールについて 話していただきました。 そこで出たのが「なるはやで！」の文化ｗ 優先度をすべて高にしてしまうことの無いように、 明確に緊急度を設けておく必要性 を説いてもらいました。 また、現在は 「ToDo」として定義されるタスクが「やりたいこと」、「やるべきこと」が分かれていないから乱雑になる ！との指摘も。 この「やりたいこと」、「やるべきこと」をわけることで、運用改善の兆しが見える気がしました。 最後に、 それぞれのチームやプロジェクト（案件）によってツールを使い分けるのも手じゃないか という話。 メンバーや状況が変わるのであれば、勿論その都度の「最適」も変わるはず。 必ず同じ手法やモノでうまくいくとは限らない のでは、と話してもらいました。 RedmineやBacklogの話題が薄れたように、 今回紹介されたツールもいずれ消えていくかもしれません 。 それは、開発手法やプロジェクトの特徴が時代と共に変化していくことからしようがないことだと思っています。 そのためには 今後の未来を見据えた柔軟さ（選定基準となる明確な目的、エクスポート可否の確認）が必要 なのかもしれません。 ドラ娘 タイムキーパー兼ドラ娘を、弊社のpepperくんが務めてくれました！ この大役を強引な進行っぷりで進めてくれて、おかげでロスタイムなくイベントが進行されました。ありがと〜〜 受付嬢も兼ねてくれました。優秀だ！きっと私より仕事してる！！ 事後アンケート ご来場くださった皆さんのおかげで、なんと 脅威の回答率91％ ！ありがとうございます！ やはり開催時間短かったですよね…、申し訳ない…。いつか拡大版として、リベンジを狙います！ 改善すべき課題が見つかった、素敵な回答でした。この結果は、今後のイベント開催・運営に役立てていきたいと思います。 まとめ 今回は6名のスピーカーの皆さんにお話していただきましたが、LT・座談会を通すと会場にも熱気がこもってきて、 「この会場のどこかに、今、マイクを持ちたいと思っている人がいる…！」 と確信できましたｗ アンケートにも「質疑応答時間が欲しかった」といくつもご意見いただいていたので、ビアバッシュのような機会で会場まるごとディスカッションできたらいいなぁ、と考えたりしました。 また、私事なのですが、今回のイベントで久しぶりに主催者ができました。 いつもと勝手の違った会場でしたが、周りの方のサポートがありなんとか開催まで至りました！本当にありがとうございます。 言い出しっぺの日から1ヶ月ちょっとでの開催、成功と言える結果となれて嬉しいです。 またいつか、今回のように制作現場を取り巻く環境を良くしたい！な目的路線でイベントを主催したいと思います。 すべてのものづくりに関わる人が幸せになれる環境模索をしていきたいですね！ イベントが紹介されているブログ、まとめメディア タスク管理ツールNight! #TaskToolNight - Togetter タスク管理ツールNight! タスク管理ツールの宴 リンク集 #TaskToolNight - Qiita タスク管理ツールNight! に参加してきた - kakakakakku blog 「タスク管理ツールNight」頼む、お前の推しツールを教えてくれ！に登壇してチャットワークについて語りました - gorian91@電子書籍セレクト タスク管理ツールNight行ってきた #tasktoolnight - 帰ってきたHolyGrailとHoryGrailの区別がつかない日記 タスク管理ツールNight!に参加した - reizist's blog

こんにちは、上津原です。 前回はpepperくんをソケット通信を利用して遠隔で動かしました。今回はQimessaging.jsを利用して、ブラウザから動かせるようにしてみました。 Qimessaging.jsの最新版は こちら で入手する事ができます。 作るにあたって、 こちらのQiita記事 を参考にさせてもらいつつ、個人的に欲しいなって思っていた、オートノマスモードのON/OFFや、スリープのON/OFF、ビヘイビアの実行などを実装してみました。 作ったものは以下です。初めてBootstrapとか触ったので、すごくごちゃごちゃしてますが、ちゃんと動きます。 ペッパーコントロール： http://kuetsuhara.github.io/pepperConnect.html pepperと同じLANにつなぎ、pepperのIPアドレスを入力して「接続」を押せば動くはずです。 ※「ハイタッチ」ボタンは、うちのペッパーの独自ビヘイビアなので他の人のペッパーでは動きません。 qimessaging.jsってなんじゃ？ qimessaging.jsは、平たく言えばJavaScriptからNaoqiのAPIを操作することが出来るものです。 なのでコレを使えば、pepperを歩かせたり喋らせたり動かしたりと好き勝手できちゃうわけですね。 pythonでももちろんNaoqiにアクセスすることが出来ますが、ブラウザから動かせるということは、ウェブサービスとのつながりなども想定に入れられたり、スマホから操作ができたりと色々と夢の広がる感じになります。 qimessaging.jsを使えばUI作成が楽！ 動作に多少のラグがありますが、手軽にコントロール画面が作れるのは魅力的です。 pythonで作ろうもんなら、実装して〜、Qtいれて〜、その後exeにして〜とか考えてるとうざったくてしょうがないです。 そこをささっと「取りあえず動く状態」を作ることが出来るというのは大きな魅力だと思います。 最初はとりあえずってことでベタのHTMLで書いてましたが、途中からBootstrapを入れて多少見た目を作りつつスマホ対応をしつつ〜と、だんだんUIこだわっていけるのも魅力的なところですね。 JavaScript使いの人も「JSでロボット操作ができる」と聞けばとりあえずはワクワクっとするのではないでしょうか。 結構手軽にpepper乗っ取りできちゃうよねコレ JSだからなのか、複数人同時におなじpepperにつないだり、同時に操作ができたりします。 例えば、ある人が喋らせてる時に、他の人が動き回らせたりできちゃうわけです。 そして、IPアドレスとネットワークさえわかってしまえばとってもお手軽にpepperに接続できちゃうわけなんですね。 ということは、pepperが複数いるところのネットワークにつなぎ、そのpepperのIPを掴んでしまえばpepperを横から操作できてしまう、ということにもつながります。 なので、もしpepperを使ったイベントなどでWifiネットワークをゲストに提供することなどがあるならば、pepperとゲスト用のWifiは別々にしておくのが良いと思います。 知ってる人がいれば、さくっと乗っ取られちゃう可能性があるわけですからね。うーん怖い。 ソースコードご自由にどうぞ んで、この作ったコードですが、どうぞご自由に使ってもらえればと思います。 数年ぶりにhtmlやJSを書いているので汚なかったり、なんかルール無視してるのはご了承ください。 kuetsuhara/kuetsuhara.github.io kuetsuhara/kuetsuhara.github.io · GitHub

こんにちは、ネクスト　リッテルラボラトリーの清田です。 最近、pepperくんにコンシェルジュ的なことをやらせてみたい、と思って触り始めています。 ただ、pepperくんにデフォルトで搭載されている音声認識エンジンですが、 まだまだ精度がいまいち といったところで、pepper開発者の皆さんも苦労されているかと思います。 もちろん、Speech Reco.ボックスで認識させたいことばをすべて登録しておけば精度は出せますが、やはり地名や駅名なども認識させたいところです。 そこで、今回は rospeex というライブラリを使って、クラウド音声認識サービスを使う方法を試してみました。 ROS (Robot Operating System) を利用しています。 詳しい利用方法についてはQiitaに書いていますので、そちらをご覧ください。 Qiita: pepperでクラウド音声認識サービスを使う (ROS Indigo, rospeex) クラウド音声認識サービスとは？ 認識したい音声を含む信号データをAPI経由でサーバーに送ると、認識結果をテキストで返してくれるサービスです。 SiriやAndroidの音声認識機能でも、認識処理はサーバー側で行われているようです。 Google Web Speech API Demonstration のページでは、Google Speech APIによる音声認識を試してみることができます。 とくに固有名詞（地名や会社名など）の認識精度には驚く方も多いのではないでしょうか？ 噂では、 深層学習 (Deep Learning) が使われているのではないかといわれています。 また、 情報通信研究機構 (NICT) も、rospeexを通して利用できる音声認識サービスを公開しています。 こちらは、日本語・英語・中国語・韓国語の4カ国語に対応しています。 pepperくんのマイク信号をネットワーク経由でキャプチャする NAOqiのライブラリに入っている ALAudioDevice を使うと、ネットワーク経由でpepperくんのマイク信号を取得したり、pepperくんのスピーカーに出力したりできます。 APIドキュメント によれば、マイク信号には「front, rear, left, right」の4チャンネルが含まれていて、サンプリング周波数はそれぞれ16000Hzになっているようです。 今回は、ROSのパッケージ naoqi_sensors に含まれているmicrophone.py を利用してマイク信号をドライブします。 「話しているところ」だけをどうやって抽出するか？ マイクで取得した音声信号をすべてクラウド側に送ってしまうと、あっという間に接続制限を食らってしまいます。 そこで、音声信号の中から「話しているところだけ」を抽出する処理が必要になります。 今回は、とりあえずマイク信号の 二乗平均平方根 をとって、エネルギー値が閾値を上回る箇所を抽出する方法を利用しました。 Python SpeechRecognitionモジュール の処理を参考にして、 audioopモジュール を用いています。 Pythonのソースコードはこちら どれくらいの精度で認識できるか？ きちんと実験できているわけではありませんが、認識エンジンにGoogleのものを使うと、Androidの音声認識機能とほぼ同じ結果が得られるようです。 NICTのエンジンについても、pepperくん搭載のエンジンよりはかなりよい結果を得られる感じです。 TODO というわけで、クラウド音声認識サービスで「pepperくんの耳を良くする」方法を紹介しました。 ただ、実用的に使うにはまだいくつかの課題があります。 APIの利用制限 Google Speech APIは非常に良い精度で認識してくれるのですが、利用回数の制限（公式には1日50回まで）が設けられているため、実験用途以外の利用は厳しそうです。ビジネス向けの有償サービスの開始を期待しましょう。 NICTのAPIは、利用回数の制限こそないものの、無償利用は 学術研究目的 に限定されています。有償ライセンスを購入すると、商用利用が可能です。 「話しているところ」の抽出にもう一工夫が必要 今回は、とりあえずの実装として二乗平均平方根によるエネルギー値の計算を使いましたが、人間の声以外の物音も拾ってしまうため、うるさい場所では無駄なAPIコールが多数発生してしまいます。 人間の声だけを抽出するためには、 Voice activity detection なども試した方がよさそうです。 話しおわってから認識結果を得るまでに時間がかかる 今回の実装では、話しおわった箇所を検出し、音声信号のデータを全部作成してからAPIに送っているため、認識結果を得るまでに数秒のタイムラグが発生しています。 話しはじめたことを検出した時点からサーバーに音声信号データを送り始めることで、認識結果を得るまでの時間を短縮できると思います。

こんにちは。Android衛藤です。 2月6日にGoogle Japanで行われた"Google Design Sprint #2"に参加してきました。 ネクストからはデザイナー・エンジニア含めて3名での参加となります。 今回、初めての参加でしたが、非常に面白い内容でしたので、そちらの参加レポートとして紹介したいと思います。 Design Sprintについて Design Sprintの概要 以下、 Google Design Sprint のサイトからの引用です。 The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Developed at Google Ventures, it’s a “greatest hits” of business strategy, innovation, behavior science, design thinking, and more — packaged into a battle-tested process that any team can use. http://www.gv.com/sprint/ Google VenturesというGoogleのベンチャー向け投資部門で開発されたもので、アイデアの設計からプロトタイプまでの落とし込みを、短期間で仕上げるためのワークショップのことです。 通常、Idea → Build → Launch → Learnと開発サイクルが回っていくところ、Design SprintではIdea → Leanと、ショートカットする事で超短期間でプロトタイプまでの落とし込みが可能になります。 今年、日本に上陸したBlue Bottle CoffeeのWebサイトもDesign Sprintによって生み出されたそうで、詳しくは こちら にありますが、この内容と同じようなことを今回行いました。 Design Sprintの手法とプロセス 対象となるユーザ像(ペルソナ)を一人に決め、そのユーザが求めているサービスについてひたすらアイデア出し→絞り込み、というSprintを繰り返していきます。 プロセスは大きく3つに分かれ、それに沿って作業を行っていくことでプロトタイプを完成させていきます。 Desing Sprintの3つのプロセス 1）理解と定義（Understand/Define）: 対象ユーザー（ペルソナ）を理解し、求められているサービスを考える 、「ユーザー分析」を行います。 2）発散と決定（Diverge/Decide）: ユーザー分析を元にサービスに必要な機能を洗い出し、そのうちユーザーに最も必要とされている機能を選択する「意思決定」を行います。 3）プロトタイプの作成と検証（Prototype/Validate）: ユーザーに見せることができる UI のペーパーモックアップの「作成と検証」を行います。 http://googledevjp.blogspot.jp/2014/11/design-sprint-for-android-wear.html 活動内容 通常は上述の通り5日間で仕上げるようなのですが(2日間というのもある)、今回はさらに短く3時間で全てのサイクルを回し、最終的にペーパーモックまで作成するというものを行いました。 対象のサービスとしては、Android Wearアプリです。 3−40人ほどのエンジニア・デザイナーが各社から集まっていましたが、最初にチームビルディングを行い5人でグループになったところで、実際にワークショップがスタートします。(エンジニア・デザイナー混在) 以下、実際の作業内容となりますが、個人ワーク→グループワークの繰り返しという流れになっています。各自間は個人ワークが5分程度、グループワークが10分程度、最終的なPrototypingが30分など、明確に時間を区切って進めていきます。出来る限り時間の延長は行わず、決められた時間内で終わらせることが大事です。 Understand(理解) / Define(定義) 架空のユーザー(ペルソナ)が記載されたシートが10枚程度配られ、まずはどんなユーザがいるかを理解します。 それぞれのシートには、下記のような情報が記されておりますが、かなりラフな情報しか記載されていません。 User Photo ゴルフをしていたり、キャンプをしていたり様々なシーンで撮影されている Name, Age Story 何の仕事を行っているか 趣味は何なのか Next adventure 次に予定していること。どこに旅をする予定、とか そして、最後がこのようになっています。 Biggest needs (define as a team) : [Name] needs a way to xxxxxxxxxxxxxxxxxx & wants the experience to be xxxxxxxxxxxxxxxxxx because they value xxxxxxxxxxxxxxxxxx. →この部分が一番重要で、そのユーザーが 何を求め 、 どんな体験がしたいか 、 その理由として、どんな価値が見いだせるから という部分をチームで決めます。 まずは、ペルソナを一人に絞り、Biggest needsを考えるところからスタートします。 この考える部分ですが、かなり想像力を働かせる必要があります。というのも、限られた情報しかないため、自分なりにそのペルソナがどんな人なのかを勝手に仮定して人物像を作り出していかないとなかなかアイデアが出てきません。 Diverge(発散) / Decide(決定) ユーザーとそのユーザーが求めているものが決まったら、今度は個人作業でアイデアを出します。出せるだけひたすら、時間内でポスト・イットに書いていきます。(1アイデア、1ポスト・イット) 最初のうちは結構出るのですが、時間が経つにつれペンが止まっていきます。しかし、この部分は「質より量」が大切。どんな些細なことでもよいので思いつく限りを記載するのが鉄則だそうです。 制限時間ギリギリまでアイデアを出した後は、チームでの作業に切り替わります。 出てきたアイデア、一つ一つ吟味しホワイトボードに貼付けていきます。 その時に、下記のように技術的に難しいか、ユーザにとっての価値は高いか、によって貼付ける場所を選んでいきます。 当日の様子↓ 作業が完了した段階で、絞り込みに入ります。 ここでの絞り込みの方法は、投票を行うというもので、1人2案やりたいものに投票を行い、投票結果の上位2案で決選投票。最終的に1つの案に絞り込みます。 Prototype(プロトタイプ) / Validate(検証) 8つのシーンを想像する どの機能を作るかが決定されれば、また個人作業に移ります。 やることは、 8個のシーンを考える ということです。 今回は、A4の白紙を8等分に折り、それぞれの1スペースにユーザーがどんなシーンでその機能を使っているかを書いていきます。 ここでは、文字ではなく実際にイラストで想像したシーンを書きました。 シーンを1つに絞る 個人作業が完了すると、チームでの作業に変わるのですが、ここでも一つに絞り込みます。チームが5人の場合、1人8シーン × 5人分 = 40シーンが作り出されるのですが、その中から、本当に実現したい 1シーンのみ に絞ります。 ペーパーモック：個人作業 シーンが決定すると、次は個人で実際にペーパーモックを作成します。 今回の場合はAndroid Wearが対象なので、Wearの画面に見立てた四角い枠に、どのような画面遷移になるかをこれもイラストで描いていきます。 Android Wearで大事な事は、 必要最低限な情報 シンプルなアクション(0 ～ 1アクションが理想) 自動起動(ユーザーが自ら起動するのではない) 入力インターフェースは音声かタップのみ といったようなことを重視してUIを作成します。 ペーパーモック：チーム作業 個人でのペーパーモックが出そろったら、そうです、 どれか一つの案 に絞ります。 その案に対して、チームで再討論しUIモックを清書して完了となります。 これまでの一連の流れを追っていくと分かりますが、アイデアの選択と集中を繰り返し、最終的に1つに絞っていくということが重要そうです。(ついでだからこの案も・・・というのは基本的にはありません) 1分間プレゼン 最後に、1チーム1分間で出来上がったモックを発表していきます。 通常の5日間のときは、ここで検証が入るようなのですが今回はプレゼンのみ。 数時間の作業でしたが、どのチームも洗練された機能ばかり出ていました。 終わりに 振り返って 3時間という極めて少ない時間の中、内容は非常に濃いものでした。 何かサービスを考える際、長時間終わらないブレストをやって、最初の目的とズレた結論が出る、ということは往々にしてありますが、Design Sprintを使うと短時間で結果が出せるということが、この体験をもって分かりました。 スタートアップ向きのワークショップとはいえ、一般的な企業でも役に立つ手法だと思います。ちなみに、人数はやはり5人(奇数)がいいらしく、それ以上増える場合はチーム分割を行うのがよいとのこと。 今回は数時間なのでペーパーモックまででしたが、5日間のSprintでは、Photoshop等を使って本格的なプロトタイプまで仕上げるようです。機会があれば5日間フルで参加してみたいと感じました。 一緒に参加したエンジニア・デザイナーの気づき 最後に、私と一緒に参加したエンジニアとデザイナーの感想もこちらで紹介させて頂きます。 デザイナーの気づき 【アイデアの出し方】 アイデアソンの手法として、自分の中で「できるできない」のフィルターを掛けるのはNGで、沢山アイデアをだして、そこから実現性を考慮して削ぎとっていったほうが効率的であり、その段階で他人のアイデアとぶつけあったりくっついたりして良いアイデアに昇華、新しいアイデアが生まれるので大事。 【意思共有に向いてる】 「誰のための何のサービスなのか」を常に意識しながら、頭から抜ける前に短時間で考えてアウトプット（ペーパープロト）まで持っていくので意思共有にも有効な手法かもしれない。 エンジニアの気づき 【質より量】 いいものを作るために短時間で様々な意見を出し合い、選びうる選択肢を増やせるだけ増やしていたのが意外だった。もちろんデザインスプリントの趣旨である１つにしぼる。利用イメージ（１シーン）にあうものを選ぶという制約があるからだろうなと思った。 【使い方をイメージさせる】 Wearのような細かいインターフェースで、色々なことをやってもユーザには伝わらない。であれば、あえてそれを押し出さずWearがあるとどういった時に便利になるよといったイメージをユーザに持たせる方が大事。さらに、そこで簡単な操作で色々できるのが理想。 【カテゴリに応じて答えが違う】 アプリのカテゴリに応じて、最適なインターフェース、利用シーンといったものが違うので、これぞ Wear というのはないのではないかと思った。Wearable である意味というのは日常の１シーンにあるといいことがあるよ、といったものなのかもしれない。 【Googleさんも悩んでいる】 Googleの中でもDesign Sprintなどで試行錯誤して開発を行っている。Google Glassなどもこういった中で作られていったようです。

こんにちは。サービス開発U 技術Gの島村と申します。 今回はクリエイターの日の制度を利用して、Raspberry Piを利用したピタゴラスイッチ的装置の開発を行いましたので、その概要を紹介させていただきます。 クリエイターの日の制度に関して気になる方は下記をご覧ください。 http://nextdeveloper.hatenablog.com/entry/2015/01/28/125100 Raspberry Piについて まず、Raspberry Piに関しては改めて説明するまでもなく、すでに様々なドキュメントがWeb上にも存在しますが、ざっくりいうとちっちゃいパソコンでした。 今回はModel B+を購入し、RapbianというDebian系のLinux OSを入れて使いました。 主にsshで接続し、ターミナル経由で開発を行いましたが、Raspberry Pi特有の何かに悩まされることはほとんどありませんでした。 ちょっと配線を間違えただけでショートして壊れてしまうのでは、、と心配もしていたのですが、全くそんなことはありませんでした。 さて、今回そのRaspberry Piを利用して開発したものですが、自部署で運営しているあるキャンペーンのKPI達成状況を、わかりやすくピラゴラスイッチ的装置で表現しようという試みになります。 キャンペーンについて そのキャンペーンに関して、ちょっと宣伝させてください。 今HOME'Sを使ってお部屋探しをすると、楽天スーパーポイントがもらえるキャンペーンを実施中です。 対象の店舗・モデルルームにチェックインするだけでポイントがもらえるので、住まい探し中の方は是非チェックしてみてください。 キャンペーンの詳細はこちら 開発した装置 で、早速今回開発した装置ですが、こちらになります！ ・・・。 まさにデジタルとアナログの融合、といった感じの風貌になりました。割り箸と輪ゴムでピタゴラ作ろうとしたのが正直甘かった。 システムの概要をざっくりと説明します。 まず、今回のキャンペーンKPI達成状況を社内の開発サーバーで定常監視し、それを別のフラグ管理サーバーに通知し、フラグを立てます。 Raspberry Pi側はそのフラグ管理サーバーを監視し、KPIの達成が確認できたら、ピタゴラ装置を作動させます。 今回はRaspberry Piをネットワーク的に開発サーバーとやりとりさせるのが難しかったため、このような冗長な構成をとりました。 それでは、装置が実際に動作する様子をごらんください。 今回は２人のエンジニアで開発に取り組みましたが、KPIの達成状況に対し、１人は音楽の再生、１人はサーボモーターの制御に取り組みました。 あまり格好のいい装置にはなりませんでしたが、一通りのシステムとして組み上げるところまではいけました。 このシステムに関する詳細や開発におけるTips等はまた別のエントリに書きたいと思います。

こんにちは、上津原です。 今度はUnity x Arduinoの話です。 Unityは様々な開発プラットフォームとして活用されますが、なんとArduinoとつながります。 Arduino と言うのは、いわゆるマイコンボードで、いろんなセンサーとかモーターとかを動かすことが出来るやつです。 そしてこれとUnityをつなぐ、「 Uniduino 」というUnityアセットがあります。コレは名前のとおりですがUnityでArduinoを動かすためのものです。 コレを使えば、Oculusのヘッドトラッキング情報を取得して、そのとおりに物を動かすことが出来るのでは！？となりました。 以前にちょっとUniduinoを触っていたこともあり、再びArduino熱が上がってきて、弊社のクリエイターの日を利用してそれを作ってみることにしました。 どうやってヘッド情報を取得するか？ コレはとても簡単でした。 OculusのOVRCameraRigのCenterEyeAnchorのRotationから取得することが出来ました。 さて、これらのデータをどのようにしてArduinoに伝えるか？というところでUniduinoの出番です。 Uniduinoの動かし方は、 こちらから見てもらえればOKです。 これのSERVOモードを利用すれば、角度情報をサーボモーターに与えてモーターを動かすことが出来ます！ サーボモーターとUnityの角度の回転が逆！ 結構さくっと動くので、順調だなーと思ってた矢先に問題が。Oculusで右を向くとサーボモーターは左を向く。 上を向くと下を向く、といったかんじであまのじゃくな動きに。 角度を調べてみるとこんな感じになっていました。 ０の起点がそもそも違うし、角度の増加方向も逆向き。 悲しい。 ということでコレの角度の補正ロジックを書くことにしました。 法則性を見つけて一つの公式を導き出して〜という方がかっこいいですが、面倒臭かったので360度を4つに区切って、それぞれの角度領域で角度補正をすることにしました。 // jouge // Seigen Kakudo int jougeSeigen = 35; if (270 < jouge && jouge <= 360) { // left servoJouge = 180 - (jouge - 270); } else if(0 <= jouge && jouge <= 90) { // right //// Kakudo Seigen//// if(jouge > jougeSeigen){ jouge = jougeSeigen; } ////////////////////// servoJouge = 90 - jouge; } else if (91 <= jouge && jouge <= 180) { // right over servoJouge = 0; } else { // left over servoJouge = 180; } うわー地味。 でも動くんだから気にしない。 サーボモータは180度のものを利用しているので、0度、180度を超えたものは0，180度以上に行かないようにしています。 コレを書いておかないとサーボモータが逆方向に動き始めて大変なことになります。 とりあえずコレを使うことでサーボの向きとOculusの向きを一緒にすることが出来るようになりました。 サーボを360度のものを使ったらさらなる罠が待っていた 首を左右に動かすのは360度のサーボのほうがいいのでは？という話題が出てきて、そうしてみた。 なんの考えもなしに180の値を渡すとなんと 2回転もするじゃないですか。 おいまて、誰が2回も回れといった。 360度角だから、Unityの値をまんま渡してやれば余裕っしょとか思ってた自分が馬鹿だった。 コレも動かしながら確かめてみると、どうやらサーボに90の値を渡すと1週するようになっているようだった。 それでいて0の起点ももちろん違う。また絵に書くとこんな感じ。 というわけで、Oculusの向きをサーボのものに変換してかつ、4で割ることで360度角を90度角にして利用することにした。 // sayuu // Sayuu Seigen int sayuuSeigen = 3; // Front left if (270 < sayuu && sayuu < 360) { // left servoSayuu = 270 - (sayuu - 270); } // Front right else if(0 <= sayuu && sayuu <= 90) { // right servoSayuu = 180 - sayuu; } // Back right else if (90 < sayuu && sayuu <= 180) { // right over servoSayuu = 90 - (sayuu - 90); // Seigen if(servoSayuu < 10){ servoSayuu = 10; } } else { // left over servoSayuu = 360 - (sayuu - 180); // Seigen if (servoSayuu > 350){ servoSayuu = 350; } } int Servo360Sayuu = (int)servoSayuu; Servo360Sayuu = (Servo360Sayuu / 4); とりあえずコレで360度回るようになった。 そしてなんやかんや接着して動かしてみたのがこちら OculusとArduinoをUniduinoで連携させてみた。 - YouTube キャタピラがついてますがそれはまた別の話で。 とりあえずはOculusとサーボを連携させることに成功しました！ 最終的にはサーボの先端にカメラを付けて、遠隔の位置に視点を持っていく、と言うものにしてみました。 電子工作楽しい ソフトウェアばっかりやってましたが、こんなふうに動くものを作れるっていうのはコレまた楽しいものです。 コレをきっかけに作って見たいものが出来たので、またなにか作ってみようと思います。

こんにちは、上津原です。 缶コーヒーのテレビCMでもPepperくんを見るようになって、なんだかPepperくん変なタレントみたいな立ち位置になってきてますね。 というわけでまたPepperの話題です。 遠隔で色々喋らせたい Pepperの開発をやっていると、インストールしておいたものしか動かせないのにやきもきしてきます。 なので、PepperとMacをつないで、こっちからテキストをを送ればそれを喋るようにしてみました。 pythonで書きます。 基本は普通のソケット通信のコードと同じです。サーバーサイドとクライアントサイドのスクリプトを書きます。 今回はMacをサーバーとして、Pepperをクライアントとして作りました。 サーバーサイド import os import sys import socket HOST = '' PORT = 50008 def main (): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1 ) s.bind((HOST, PORT)) print 'waiting for client...' s.listen( 1 ) (conn, addr) = s.accept() print 'Connected by' , addr pid = os.fork() if pid == 0 : print "child process" while 1 : msg = raw_input ( ">> " ) conn.send( '%s' % msg ) if msg == "quit" : break ; sys.exit() else : print "parent process" while 1 : data = conn.recv( 1024 ) if not data: print 'End' break elif data == "" : print "Client is closed" os.kill(pid, 9 ) break print "pepper: " , data conn.close() sys.exit() if __name__ == '__main__' : main() クライアントサイド（Pepper） import os import sys from socket import * HOST = '192.168.XXX.XXX' #ここは設定に合わせて PORT = 50008 class MyClass (GeneratedClass): def __init__ (self): GeneratedClass.__init__(self) def onLoad (self): #put initialization code here pass def onUnload (self): #put clean-up code here pass def onInput_onStart (self): # ソケット接続 try : #接続処理 self.s = socket(AF_INET, SOCK_STREAM) self.s.connect((HOST, PORT)) except : #接続失敗したらソケットを閉じて終了へ self.s.close() self.onStopped() return # 子プロセスの作成 try : pid = os.fork() except : return # つながったらテキストの送受信を行う self.log( "pid :" + str (pid)) # 子プロセスの場合の処理 if pid == 0 : # 一旦未使用 pass # 親プロセスの場合 else : while 1 : self.log( "pid else" ) data = self.s.recv( 1024 ) if not data: break elif data == "quit" : os.kill(pid, 9 ) break self.log(data) # Stopの何かがないか確認 stop = self.stopVerification(data) if stop == False : self.outputStringFromServer(data) self.s.close() self.onStopped() pass def onInput_inputString (self, p): # PCからインプットされたテキストをmsgに入れて、喋らせる self.log( "Recieve String " + p) # Stopの何かがないか確認 stop = self.stopVerification(p) # Stopではなかったらメッセージをサーバに送る if stop == False : self.s.send(p) def onInput_onStop (self): self.onUnload() #it is recommended to reuse the clean-up as the box is stopped self.onStopped() #activate the output of the box def stopVerification (self,inputString): if inputString == "ストップ" : self.log( "stop!!" ) self.outputStopBehavior() return True else : return False 補足説明 outputStringFromServer()部分がサーバーから受け付けたテキストをノードからアウトプットするものになってます。 ここから先にAnimatedSayなどをつなげればそのとおりに喋ってくれます。 stopVerification()というのも作っていますが、これは「ストップ」という単語が届いたらアプリケーションを停止する挙動なども取り入れています。特定のテキストを送ればこの挙動をする、とかそういった物を簡単に設定することが出来るようになります。 forkを使って、好き勝手やりとりできるように作っているので、pepperのSpeechRecoを使って特定の言葉をサーバ側に送ったりもできます。onInput_inputString()はSpeechRecoから受け付けた単語を得てうごかしてます。 とりあえずコレを使えば、人力でPepperくんと人の会話ができるようになります！ 人力でやってどーする！と思うかもしれませんが、人力でもそれはそれで楽しいのでやってみてください。

こんにちは。iOS開発Gの石田です。 最近家電を操作して、自分の部屋をスマートハウス化しようといろいろやっているのですが、そこで考えたことをまとめてみました。 我が家の現状 我が家で最も活躍しているのは、ネットワーク対応学習型リモコンのIRKitです。家電が規格に対応していなくても赤外線リモコンさえあれば操作できるので、自作アプリに組み込んで赤外線対応家電を操作しています。 以前の記事 で紹介したとおり、Siriで音声認識を実現しています。 最近は、「帰ったよ」というアプリを作り、起動するとテレビ、エアコン、照明、BDプレイヤーが起動して、セットしておいたお気に入りのBDが流れるようにしています。 【ネクスト】iPhoneの「Siri」で家電を操作 - YouTube またスマホなどから操作できる電球であるPhilipsのHueや、室内・室外環境を計測するウェザーステーションのNetatmoを、カスタム条件トリガーを作れるIFTTTで制御し、湿度が低くなったりCO2濃度が高くなったときに部屋の色を変えたり、自宅から半径500mを出入りするたびに 照明が付いたり消えたりするようにしています。 こちらが簡単に自宅の制御系を表したものです。 IFTTTとは、If This Then Thatの略で、これをしたらあれをする、というWebサービスの組み合わせを自分で作ることができるサービスです。 最近はWebサービス感覚で使用できる家電が出されてきており、IFTTTに対応している家電であれば、トリガーと動作を設定するだけで制御できてしまうので非常に便利です。 トリガーとしても用いることができるものとしては、電話がかかってくる、メールが来る、Facebookの通知、GPSで指定の領域に入る、などがあります。 課題 しかしながら、IFTTTを用いて制御していると不満なことがでてきます。それはトリガーの条件が１つしか登録できないことです。 例えば、「IF 指定さえた領域に入る　Then 照明をつける」、という命令を設定しているのですが、時間の指定ができないので昼間でも電気がついてしまいます。 時間の範囲指定ができればよいのですが、シンプル故に使いやすいIFTTTでは設定することができません。 本来私が設定したい命令は、 『 暗い時間に家に帰ったら 』 であり、よりセンサ等が分かるようにより具体的に書くと 『 「現時刻」が「本日の日の入りの時刻」を過ぎているかつ、「スマートフォンの位置情報」が自宅の半径500mよりも外の位置から中の位置に変化した 』 となります。 このように、より快適に家電を制御するためには、複数の一次情報を組み合わせて、人の行動に合致した二次情報を作り、トリガーとする必要があります。 二次情報への加工 たとえば、「家に帰る20分前にエアコンをつける」ことを考えます。頭の中では「帰る」と思うだけですが、コンピュータはそれが分からないので工夫する必要があります。 仕事では基本的に外出がなく、いつも同じ駅から通勤・帰宅する私にとっては、「夜に品川駅に着く」ことが「家に帰る20分前」とほぼ同義です。よって 『　「現時刻」が19時から24時かつ、「スマートフォンの位置情報」が品川駅の半径200mよりも外の位置から中の位置に変化した　』 というトリガーを設定すればよいわけです。※1 しかしこのトリガーは私専用であり、同じ勤務地、最寄駅でも営業職の人では当てはまりません。同じ品川勤務でも営業の人は外出することが多く、直帰することもあるでしょう。そうすると、品川駅を通らずに自宅に帰る可能性もあり、私と同じ条件を設定したところでこのトリガーが引かれず、エアコンのついていない寒い部屋に帰る羽目になります。 このように同じ「家に帰る20分前」でも、人によってトリガーの条件が異なります。故に自分の行動パターンを把握したうえで各自トリガー設定する必要があります。 しかしこのような複雑なトリガーの設定を世間一般の人が皆やりたいわけではありません。（私は楽しいですが） 初めに複雑な設定が必要であるならば、スマートハウスはなかなか普及しないでしょう。 ユーザーが何もしなくても、気の利いた制御をしてくれるためには、ユーザーの行動を学習して適切なトリガーを自動で設定してくれることが必要になってきます。 これに近いことを既にやっているのが、GoogleNowです。 GoogleNowのレコメンド機能 GoogleNowは、膨大な個人情報を提供する代わりに、適切なタイミングでユーザーが興味のある情報を「カード」という形で提供してくれるアプリです。※2 行動を分析して、Android端末およびAndroid Wearにカードとして情報を表示するものなのですが、Googleは少し前からスマートハウスにも応用を始めました。 昨年人工知能が付いたサーモスタットであるNestを作っている企業を買収し、NestをGoogleNowと連携させるサービスが始まっています。 Google NowとNestの連係で音声命令や“帰宅時間を予測して室温設定”が可能に Nestは、家の温度をまとめて調整してくれる装置の一種で、もともと人工知能が入っており、帰宅時間を予測して勝手に室温を適切に保ってくれるようです。これ自体でスマートハウスのハブとしての役割を担う可能性があるのですが、GogoleNowと連携することによって、位置情報によるより正確な帰宅時間の予測と、「OK,Google」による音声認識による操作が可能になったようです。 グーグルが買収したNestって何がすごいの？ そもそもサーモスタットって？ : ギズモード・ジャパン GoogleNowとスマートハウスの連携はとても強力で、他の規格から一歩抜き出ていると思います。 そのうちAppleのHomeKitのようなスマートハウス規格を発表して、家電メーカーがそれを組み込み、スマホがスマートハウスのハブを担うことになるでしょう。 使っているスマホがiPhoneかAndroidかによって、家を決める時代が来るかもしれません。 最後に 個人が趣味でスマートハウス化している段階から、一般人が普及するスマートハウスを便利に利用する段階の間にあるのは、難しい設定や操作無しで快適な動作ができる人工知能ができるかどうかだと思います。 ですがスマートハウスの現状はまだ規格が出始めた段階で、家電自体がスマートハウスの規格に対応しないうちはまだまだ普及の段階ではありません。さらにスマート家電と呼ばれるものは最上位機種の付加機能として導入されると思われるので、価格が高いうちはなかなか普及しないでしょう。 よってしばらくは、自分の家の家電を自由に操作し、自分の行動パターンから適切なトリガーを設定して、一足先にスマートライフ生活を楽しんでいこうと思います。 自分が設定したとおりに家電が動くのはとても楽しいことです。 ※1 正確には、私が仕事終わりでどこか別のところに遊びにいこうとするときは、必ず品川駅を使う必要があるので、この条件だと「家に帰る」のか「遊びに行く」のか分かりません。確実に「家に帰る」方向に行ったと判断するためには、品川駅から出て通勤路線上の次の駅の範囲に入るという条件を足す必要があります。さらに家に帰る方向に行ったとしても、最寄駅を過ぎて別のところに行く可能性もあります。すると最寄駅を過ぎて次の駅に行った時点で「家に帰らない」という判断をして命令を取り消す必要があります。自分の行動パターンを元にプログラミングをしているようですね。 ※2 私は１年ほど前からNexus5でGoogleNowを使用し続けているのですが、既存のECサイト等にあるようなレコメンドの質とは大きく異なり、かなり私個人にあった情報をおススメしてきてくれます。 例としては、最寄駅についたら通勤に使える電車の時刻を教えてくれる、PCでGoogleMapを使っていきたい場所を調べると、行き方がカードで表示されている、普段行かないところに遊びに行くと周囲の情報を教えてくれる、興味のある分野の記事のおススメ、よくチェックしているページが更新されたら通知してくれる、1か月で歩いた距離を教えてくれるなどがあります。噂によると、設定しなくても1週間GoogleNowを使うだけで勤務地が設定されるらしいです。 それもそのはず、GoogleNowには、検索履歴、メールの中身、位置情報、GoogleMapの使用履歴など、かなり濃い個人情報を提供しています。これらをもとにビッグデータ分析や学習アルゴリズムを駆使して、私たちの興味のある情報を分析しています。

Apple原理主義者ですが、今日書く内容にその事実は関係ない大坪です。 「新しいアイディアを出そう！」（意訳） というときにブレーンストーミング-略称ブレストってよくやりますよね。真面目な誰かが「質より量」とか「他人の意見を批判しない」とか「ブレストの原則」を述べ出すと「そんなのもう聞いたよ」感が会議室に満ち溢れるくらい世の中に普及しているわけです。 個人的にこの「ブレスト」というのはよほど注意しないと有意義な結果を残せないといつも注意しています。私はバラエティ番組にでている能年某嬢くらい考えるテンポが遅いので、元気良い人が多いブレストでは発言できない。いや、それはお前がそもそも新しいアイディアを持っていないからだろう、という真っ当な指摘は無視してじゃあブレストで「すごいアイディア」がでてきたことがあるかというとあまりそういう記憶もない。 自分では「なぜそう考えるのか」説明できなかったのですが、最近見つけた記事がその理由になるかもしれない、と考え始めました。そもそもの問題意識から Meetings want to suck. Two of their favorite suckiness tactics are group brainstorming and group negotiation. 引用元： Note and vote: how to avoid groupthink in meetings | Google Ventures いいかげんな訳：会議は退屈さを欲している。会議が大好きな「退屈にする方法」はグループでのブレストとブループでの交渉だ なるほど。では彼らはどのような方法を提案しているのか？前述のページから少しはしょって引用すると (以下引用＆要約しつつ和訳) 1.Note ５分か１０分で個々人がアイディアを書き出す。その後２分かけて１個か２個の「これがいい」というアイディアを選ぶ。 2.Share and Capture 順番に自分がよいと思ったアイディアを発表する。「売り込み」はなし。それをホワイトボードに書き出す。 3.Vote ５分で、書き出されたアイディアのうちどれがよいと思うが決め、ノートに書く。そのあと順番に自分がよいと思ったものを発表する。（ノートに書いた内容を変えてはダメ）ホワイトボード上にどのアイディアが何票得たかを書いていく。 4.Decide 責任者がどのアイディアでいくか決定する。その際投票結果を尊重しても、尊重しなくてもよい。仮に投票結果と違う結果になっても「すべての人間の意見をちゃんと聞いた」ことになる。 以下この方法がうまく行く理由について述べられています。 個人に静かに考える時間が与えられる すべての人が並行して考えているので、「一度に一人しか発言できない」通常のブレストに比べて時間の効率がよい 投票する際に、他人の意見を聞く前に自分の意見を書き出している。つまり「他の人の意見に安易に同調する」ことがない。 最後の項目は「集合知がうまく働くための条件」とも合致している。すなわち集団での決断が「衆愚」に陥らないためには、他人に影響されない独立性を持っていないければならない、といわれています。ここで自分の判断を頭の中にだけ止めておくと 「Bがいいと思ってたけど、あの人がAと言ったからA」 的な判断に堕してしまう。あらかじめ自分の判断を書いておくことでそうした事態が防げるわけです。 また4.Decideを読んで「マキャベリ語録」のある一節を思い出しました。 あなたは、すべての事柄について質問しなければならない。そうしておいて彼らの自由率直な意見を求めるのだ。そしてそのあとで、あなた自身の判断で決定を下す マキアヴェッリ語録 P98　塩野七生著　新潮文庫　 グループの各員は自由に自分の意見を表明できなくてはならない。責任者は自らの責任において決断を下さなくてはならない。一見両立が難しいように思えるこの二つの命題は実はそれほど離れていないのかもしれません。 さて このNote & Voteが提起しているもう一つの問いは 「優れたアイディアは一人の頭での深い思考からしか生まれないのではないか」 という点。こちらのページ The Design Sprint — Google Ventures The Design Sprint — Google Ventures では、彼らが実行している一週間のデザインスプリントについて述べられています。このプロセスでは、火曜日（つまり二日目）がSKETCHに当てられており、 During Sketch day, your team will work individually to draw detailed solutions on paper. As you sketch, everyone works separately to ensure maximum detail and depth with minimum groupthink. 引用元： The Design Sprint — Google Ventures 訳：Sketchの日に、チームメンバーは個々に詳細な解決案を紙に書く。個人ごとに作業するのは、グループでの思考を最小限にし、かつ（アイディアの）詳しさと深さを最大にするためだ。 ここで提案されている方法も伝統的なブレストとは異なったものです。 ここでもう一つ引用します。先日紫綬褒章を受賞した佐藤雅彦氏のインタビューで、私の世代だと佐藤氏はすごいCMを作る人、というイメージなのですが最近では「ピタゴラスイッチ生みの親」と認識されているかもしれません。 でもジャンプっていうのは非常に難しくて、どこで見つけるかっていう質問だったんですけど、それはすごく難しくて、いろんなところに隠れているんですよ。 僕は「うまく待つ」って言っているんですけど、そういうものを見出す自分でいるように、うまく待っている。見過ごさないように。当たり前だと思っていることが実は当たり前じゃない、ということがとってもあるんですよね。 それと、これは鍛錬なのかもしれないですけど、いろんな場合の数、無数の場合の数を頭の中でやる訓練というか。全部「この場合、この場合、この場合……」全部「つまんない、つまんない、つまんない……」って頭の中でガシガシやっているうちに、セレンディピティというんですかね、たまたま何かのものが見えたりしたときに、それがガーンと来るジャンプの映像だったりしますね。 だからやっぱり「うまく待つ」ということと、「ものすごく追求する」ということだと思いますね。 引用元： 新しいものは"つくり方"から生まれる--「ピタゴラスイッチ」生みの親・佐藤雅彦氏インタビュー | ログミー[o_O] ここで佐藤氏が強調している「うまく待つ」と「ものすごく追求する」は「質より量」といったブレーンストーミングの原則とは相反している。会議室で決められた時間内にアイディアを出し合うのではなく、個人の頭の中で膨大な組み合わせ、評価サイクルを回すことを会議中でなくても延々と続ける。そうしていると思わぬときにアイディアがやってくる。会社から帰ろうと電車に乗ろうとした瞬間「おわっ」とアイディアが閃いた経験を持つのは私だけではないと信じたい。 あるいは私は「新しいアイディアといってもいろいろ程度がある」事実を無視した意見を書いているのかもしれません。仮にそうだとしても 「アイディア出し会議をしよう！さあ、ブレストだ」 と直結してしまうのは見直すべきではないかと最近考え始めています。

こんにちは、上津原です。 最近はpepperを触っています。少しずつpepperのアプリケーションを開発するにあたって気づいた点などを紹介していこうと思います。 pepperとは？ pepperは、ソフトバンクロボティクスから出ているロボットです。TVCMなどで見たことがある人も多いと思います。 pepperはChoregraphという統合環境を使ってアプリケーションの開発ができます。Choregraph内ではpythonを使ってより詳細なロジックの作成ができます。 pepperにおけるDialogとは？ Dialogと言うのは、pepperとの会話のやりとりを作成する部分です。 「こんにちは」と声をかけられたらpepperは何と返すか？などを記述するものです。 詳しいやり方は こちらのページ を見てもらうとわかりやすいと思います。 注意するべき点って？ コレは自分がハマったことなのですが Dialogが一番下まで完了すれば勝手に次の処理に進むと思っていたが、そうではないということ。 例えば、「はい」「いいえ」でそれぞれ違う回答をさせたい場合は u:(はい) そうですよね〜 u:(いいえ) まじですか というふうに書くわけですが、コレでは この受け答えをループしてしまうだけ になってしまいます。 これらを次のアクションへ繋げたい場合は、後ろにoutputの名前を記述し、1を代入します。 (ex:onStoppedを動かしたい場合） u:(はい) そうですよね〜 $onStopped=1 u:(いいえ) まじですか $onStopped=1 こうすることで、次の処理へつなぐことが出来ます。 任意でoutputを作成した場合は、同じようにその名前を書いてやればOKです。 ここでもう一つ注意なのですが、onStoppedを使わなかった場合、Dialogの聞き取りモードが継続して動き続けてしまう状態に陥ります。 そうなると、他の処理中に音声を拾ってしまい動作がおかしくなってしまうので、そういった場合は聞き取り後にonStopにもラインをつなげておくと安心です。 こんなかんじ pepperは意外と自分でいろんなことをしてくれない。 ロボットなんだから結構気が利いて、色々といい感じにやってくれるんだろうな〜とか最初思ってたんですが、全くそんなことはなく、きっちりこっちがロジックを書いてあげないと訳の分からない動きをしたりします。 ロボットだということで妙な期待を寄せていると、ロジック周りでいろんな落とし穴があるので色々と気をつけていきたいですね。

こんにちは。クリエイターの日運営委員の松尾です。第3四半期に実施してから年も明けてしまいましたが、今回も『 クリエイターの日 』について紹介します。 クリエイターの日制度 改めておさらいすると、ネクストでは「既存サービス・技術の枠組みを飛び越えた自由な発想からイノベーションの創造」と「各メンバーの興味あるサービス・技術へのチャレンジを通しての個人の成長とネクストの創出力向上」を目的として、四半期の最大7日間を研究・開発にあてることができます。 毎四半期の最後には各チームの成果報告会を行いますが、今回は趣向を変えて「デモセッション with ビアバッシュ」というかたちで実施しました。 デモセッションの風景 デモセッションでは、決められた時間の中で各チームが同時にシステムのデモンストレーションを行います。今回はクリエイターの日に活動した5チームと、有志として参加した1チームの計6チームが参加しました。 特に注目度が高かったのは、AndroidWearのデモを行っていたチーム。実装方法やデザインのこだわりなど、多くの質問が飛び交っていました。 HOMES(ホームズ)-住まい探し-賃貸・不動産賃貸検索 - Google Play の Android アプリ 参考： スマートウォッチで内覧時のチェックポイントを確認 こちらはSwiftで実装したアプリで社内システムの改善を目指すチーム。クリエイターの日を利用して勉強、実装をしたそうです。 参考： 手元のスマホで来客の受付ができるアプリ ソフトだけではなく、ハードを扱うチームもいます。こちらでは脳波を入力として、PCなどの操作をしてました。 こちらはSiriとIRKitを利用して家電の遠隔操作を実現したもの。しゃべるだけで家電が操作できます。 発表者だけではなく、聴講者としても多くの社員が参加しました。職種を問わず、最新技術に興味を示す社員が多数です。 ビアバッシュも兼ねているので、飲食物も準備。 今回は以前までの報告会とは違い、発表者と聴講者が話しやすい雰囲気を作ることに注力しました。発表と質疑応答のような形式に比べて、建設的な議論が盛り上がっていたようです。 結果発表 聴講者による投票で決定した優勝チームは「泡（Android Wear Appの頭文字らしい）」チーム。 本家Android Appのウェアラブルデバイス対応を業界初を目指して提案、実装したアプリです。まだまだこれからのデバイスですので、今後の発展も期待されます。 また、弊社役員からの特別賞には、有志として参加した新卒1年目の社員を選出。 IoTをテーマに出展していた彼には、その感性をさらに磨くべく、新しいガジェットが贈られたようです。 今後もネクストのものづくりを活性化し、発信して参ります。次回の記事にもご期待ください。

池田です。 今回は、iPhoneアプリの視覚障がい者向けユーザビリティ、アプリを使いやすくする3つのポイントについて書きたいと思います。 ユーザビリティのお話をする前に、視覚障がい者がどうやってiPhoneを使われているか、について少し触れます。 視覚障がい者の多くは、iOS付属のスクリーンリーダー「VoiceOver」を活用し、iPhoneの利用をされています。 初めて「スクリーンリーダー」という言葉を耳にした方もおられるかもしれませんので、少し解説しますと、スクリーンリーダーは、画面上の内容を、音声にして読み上げてくれるソフトウェアです。 画面上の項目にカーソルが当たり、そのカーソルが当たっている項目の内容を音声で読み上げてくれます。 カーソルが当たってるのがテキストなら、そのテキストの内容を。 リンクなら、リンクの文言と、それが「リンク」であるという情報を読み上げます。 視覚障がい者の多くはこのスクリーンリーダー、iPhoneではVoiceOverを活用して、音声で画面の情報を把握し、使われています。 それでは、VoiceOver利用時のユーザビリティ、アプリが使いやすくなる大切なポイントについて、書いていきたいと思います。 「HOME'Sアクセシビリティ対応版」で気をつけている大切なポイントは、大きく分けて3つです。 VoiceOverに合わせた操作性の考慮 画面操作時の迷いをできるだけ軽減する 必要な情報を漏れなく音声で伝える この3つについて、解説していきます。 VoiceOverに合わせた操作性の考慮 VoiceOverが有効の環境下では、無効の場合と大きく操作が異なってきます。 VoiceOver有効時には基本的な操作として、カーソルの移動と、項目の選択があります。 カーソルの移動は、画面上を上下左右にスワイプする、または、画面上の項目をタッチすることで行います。 項目の選択は、画面上をダブルタップすることで行います。 この操作性を考慮し、画面上の項目の配置、項目の読み上げ設定などをすることが大切です。 「HOME'Sアクセシビリティ対応版」の画面画像を示しながら、ご説明していきたいと思います。 VoiceOver利用環境下では、画像上の番号で示すように、まず画面の左上の要素が選択、そこから左から右、右端まで行ったら一つ下の行の左端の要素が選択。 のような動きで、カーソルを移動していきます。 つまり、左上から順々に一つ一つの要素の内容を音声で聞き、理解しながら画面操作を進めていきます。 こういった操作を考慮し、この画面では、画面の機能として配置されている「検索トップに戻る」ボタンの配置を画面上部にしています。 なぜ上部かと言いますと、画面上部にボタンを配置することで、画面の内容に入る前にボタンにカーソルが合うため、画面内にどんな機能があるか、事前に把握することができるためです。 また、画面上部にある方が、VoiceOver環境下の特殊な操作(二本指で上にスワイプすると最初の項目にフォーカスが合う)を用いることでアクセスしやすくなるという利点もあります。 画面操作時の迷いをできるだけ軽減する VoiceOver利用時の操作は、画面上を触ることにより触った位置にある項目が選択されることもあり、画面上の操作をしている際、ちょっと触れた位置にカーソルが行ってしまうなど、意図しない動作が起こる場合があります。 意図しない動作が起こると、画面上の理解に迷いが生じます。 そこで、迷いが生じないように、また、生じた場合の迷いの軽減をすることが大切です。 こちらの画面では、画面右上に画面の使い方を調べるボタンを設置しています。 こういったボタンを設置することで、今何をする画面にいるんだ？どんな操作をすればいいんだ？ といった迷いが生じた際、ここを見ることで少しでも迷いを軽減できるようになります。 必要な情報を漏れなく音声で伝える VoiceOver利用時には、画面上の音声読み上げが重要となってきます。 まずは画面上の各要素をテキスト情報で伝える必要がありますが、それだけではなく、「画面上の状態」を伝えることも大切です。 この画面は、データを取得中の読み込み画面です。 開かれたタイミングで読み込みが行われ、その後、読み込みが完了すると内容が表示されます。 画面の状態の変化は、ユーザの操作によって行われる訳ではなく、自動で行われます。 こうした自動的な画面の変化を音声で伝えていくことも大切です。 「HOME'Sアクセシビリティ対応版」では読み込みが開始したタイミング、読み込みが完了したタイミングで、音声で「読み込み中」「読み込み完了」と状況を伝えるようにしています。 このように、VoiceOverの操作性、ユーザの迷いの軽減、適切な音声フィードバックを行っていくとアプリは視覚障がいを持たれた方にとってとても使いやすいものとなります。 VoiceOverは視覚障がい者をサポートする素晴らしい機能ですし、VoiceOver利用を考慮したアプリが増えていくことで、視覚障がいを持たれた方の生活もどんどん便利になっていくと思います。 今回は、VoiceOverの詳細、実際の開発など、詳しい部分をお伝えできていませんが、今後より詳しい部分についてもお伝えしていこうと思います。

こんにちは、上津原です。 先日Pepperの購入者、または購入予定者が参加できるというPepper Pioneer Club Meetupに参加してきました。 会場は、FreakOutさんのイベントスペースでした。 私はエンジニアというところで、エンジニア目線での今回のイベントで感じたことをお伝えしたいと思います。 乾杯は主役のPepperが まず最初に、恒例らしい（？）Pepperによる乾杯の音頭で始まりました。ちなみに前回はPepperによる乾杯は失敗したとのことで、今回はうまくいき、乾杯の後に拍手がわきあがりました。乾杯ができただけで拍手を受けられるPepper。しかし妙に新鮮でした。 展示されていたPepperや話を聞いて感じた事 Pepperの基本としてはもちろん「会話」が中心になります。なので、会話をしながら記念撮影をしたり、ラジコンのように操縦するスマホアプリが展示されていたり、関西弁でしゃべるPepperなどがありました。 全体を眺めながら感じた点は、まだ柔軟な会話に対応できるPepperアプリケーションを作るノウハウはそりゃあるわけないよねー、という感じでした。「はい」「いいえ」を基本にした会話だったり、数字を選ばせたり、胸元のタブレットで操作したりというかんじで。 いわゆるソフトバンクの発表会で見たようなスムーズな会話を成り立たせるというよりは、Pepper側から選択肢を人間に用意をしてあげて、思った通りのフローを踏ませるといったものが基本だし、ロジックを作る以上はそうなってしまうのはしょうがないのかなと感じます。 CMなどのおかげで、Pepper君は話しかければ大体なんか返事してくれると思っている人が大多数なので、結構その辺で開発者とユーザの間でギャップが起きたりするのでその辺をどう埋めるかというのも課題になりそうです。 まあ、Pepperくんはかわいいので、できなくても大概許してもらえちゃうんですけどね笑 次は開発者イベントがあるといいなあ 今回は「こんな風に使ってます」「作ってみました」というものが多かったので、次開催あたりではもっと開発側に突っ込んだものなどの話があるとうれしいですね。 ロボットを喋らせて、人と会話をするというのは今までソフトウェア開発をしてきてやることはなかった身としては、どうしても普通のソフトウェアに考えが偏りがちで「どうやったら話したくなるか？」「スムーズに会話が進むか？」「違和感のない生きてる感を出せるか？」などいろんなところでつまづく場面があるので、その辺をみんなで共有しあえればもっといいPepper開発につながるんじゃないかなーと思います。 しかし、MeetUpはご飯もおいしく、会場も広く非常に楽しめました。 今後の展開が楽しみです。

こんにちはAndroid開発グループ橋本です。 今回はAndroidStudioで使うlintについて調査する機会があったので内容を記事にします。(lint自体の解説は省略します。) まずは実行をしてみる。 Androidのlintの実行について調べてみると、Android/sdk/tools/の下にあるlintが使用できるようです。 参考： http://developer.android.com/intl/ja/tools/help/lint.html この方法だといちからlintのオプション設定を行わなければいけないため、とても手軽に使えるとは言い難いものです。ではどうしたらいいのか？そもそも開発はAndroid Studioを使う事を前提としていたのでそちらで実行したいところです。 Android Studioから実行 AndroidStudioから実行する場合、実はとても簡単で、メニューからAnalyze→Inspection Scopeで実行できました。 gradleをコマンドラインから実行 Android Studioで作成したprojectフォルダの下にあるgradlewを使用して、以下のコマンドでlintを実行できます。 ./gradlew (モジュール名):lint こちらの方法で実行した場合デフォルトではhtmlとxmlで出力され、実行後に成功していれば出力パスが表示されます。 lintの設定をする。 設定と実行方法はAndroid StudioのGUIに任せるか、手動で行うかのパターンがありますが。GUI上からの設定方法は他文献でいくつかあるようなので、ここでは手動設定の方法を記述します。 build.gradleの設定 作成したprojectファイルにあるbuild.gradleにlintOptionsを追記し必要な項目のオプションを必要に応じて追加する形です。 以下公式から抜粋。 android { lintOptions { // set to true to turn off analysis progress reporting by lint quiet true // if true, stop the gradle build if errors are found abortOnError false // if true, only report errors ignoreWarnings true // if true, emit full/absolute paths to files with errors (true by default) //absolutePaths true // if true, check all issues, including those that are off by default checkAllWarnings true // if true, treat all warnings as errors warningsAsErrors true // turn off checking the given issue id's disable 'TypographyFractions','TypographyQuotes' // turn on the given issue id's enable 'RtlHardcoded','RtlCompat', 'RtlEnabled' // check *only* the given issue id's check 'NewApi', 'InlinedApi' // if true, don't include source code lines in the error output noLines true // if true, show all locations for an error, do not truncate lists, etc. showAll true // Fallback lint configuration (default severities, etc.) lintConfig file("default-lint.xml") // if true, generate a text report of issues (false by default) textReport true // location to write the output; can be a file or 'stdout' textOutput 'stdout' // if true, generate an XML report for use by for example Jenkins xmlReport false // file to write report to (if not specified, defaults to lint-results.xml) xmlOutput file("lint-report.xml") // if true, generate an HTML report (with issue explanations, sourcecode, etc) htmlReport true // optional path to report (default will be lint-results.html in the builddir) htmlOutput file("lint-report.html") // set to true to have all release builds run lint on issues with severity=fatal // and abort the build (controlled by abortOnError above) if fatal issues are found checkReleaseBuilds true // Set the severity of the given issues to fatal (which means they will be // checked during release builds (even if the lint target is not included) fatal 'NewApi', 'InlineApi' // Set the severity of the given issues to error error 'Wakelock', 'TextViewEdits' // Set the severity of the given issues to warning warning 'ResourceAsColor' // Set the severity of the given issues to ignore (same as disabling the check) ignore 'TypographyQuotes' } } 一部よく使うであろうオプションについて解説します。 abortOnError falseを設定することで、build中にlintのエラーが出てもbuild自体に影響を及ぼさない(途中で停止しない)設定に出来ます。コンパイルが通るはずのソースコードをbuild中に止められてしまう可能性があるのでfalseにする事が殆どになると思います。 disable issue IDを設定することで、設定したissue IDを無視できます。実行するモジュールによってはlintが過度の検出をしてしまう為、明示的に設定しlintの検知から除外します。 lintConfig lintの設定ファイルを指定できます。パス設定はgradlewのあるフォルダと同じところからみた相対パスになります。 lintの設定ファイルの記述 基本的には.gradleで設定できる内容と同じ内容が設定できますが、lintConfigで設定したフィアルでは詳細な設定も記述できます。 参考： http://tools.android.com/tips/lint/suppressing-lint-warnings 記述方法:ファイルの個別除外とフォルダ以下全て除外の例です。 <?xml version="1.0" encoding="UTF-8"?> <lint> <issue id="all">　① <ignore path="src/test/androidtest.java" />　② <ignore path="src/test/**/*" />　③ </issue> </lint> issue idを設定します。"all"を設定することで全issue idを対象に出来ます。 ignoreで除外とし、optionのpathで対象ファイルの条件を記述します。（絶対パスの記述例） 2.の相対パスの記述例 調査してみて 今回lintの調査をしてみて、まだまだ調べ切れていない感じがします。 実際に調べ設定してみて設定方法もGUIからがいいのか手動設定がいいのかの判断まではついていませんが、lintの設定だけ考えると個人的には手動がわかりやすかった印象です。 ただ、実際に運用するにあたっては、lintに検知と対応する事を考えるとAndroid StudioのGUI上から設定し修正・運用する方が良さそうでした。 おまけ Android/sdk/toolsのlintコマンドで、オプションに--listをつけ実行する事で検知できるissue idが全て見れます。予想はしていましたが種類が多いのでlint実行時に検知されたissue idの内容を調べ随時対応していくのが効率的だと思いました。

こんにちは。Android 衛藤です。 12/21(日)に Android Bazaar and Conference 2014 Winter に参加してきましたので、今回はその報告を書かせて頂きます。 私が見た講演は下記の通りです。 [開会宣言] Android Link to Next Generation! ～次なる世界を目指して～ [基調講演] 「Project Araと新しいものづくりエコシステム」 [招待講演] Android 5.0とAndroid Wearで広がる最新アプリ開発技法 [招待講演] Microsoft <3 Android [招待講演] ウェアラブルコンピューティングとAndroidの未来 loT時代における開発手法の提案～スマホの次を見据えて～ Material Designの勘所 日本から海外、そして海外から日本、アプリビジネスの海外展開の今後。 歴史は繰り返す+トレンド 裏読みで2015年のモバイルを予測する これらの中で、いくつかピックアップして内容を記したいと思います。 講演内容 Android 5.0とAndroid Wearで広がる最新アプリ開発技法 マテリアルデザイン マテリアルデザインとは異なるデバイス間で一貫した表現をするためのデザイン思想 elevation / ripple / interpolator等の効果により自然に見せる ToolBarを使用する(ActionBarよりも柔軟なカスタマイズが可能) Android Wear 新しくなったNotification。通知をスタックできたりする Watch Face API が公開された Wearアプリを公開する際はGoogle Playのアプリの [価格と販売 / 配布地域] ページで、Google Play の Android Wear コレクションに追加されるように設定することができる Notificationを出しすぎるとアンインストールされるので、本当に必要なときにのみ出すようにする これからアプリを開発するにあたって オレオレUIではなくAndroidらしいものを作る(NavigationDrawerとかActionBar/ToolBarなど) Webのコピーのようなアプリは必要ない サクサク動き、見た目が美しく、電池持ちが良いアプリを作る Android5.0についてなので、当然ながらマテリアルデザインやWearについての話題でした。 この後のマテリアルデザイン講演で詳しく聞いてきたので、詳細はそちらで記載したいと思います。 AndroidらしいUIというところも重要で、やろうと思えばいくらでもUIはカスタマイズ出来ますが、 凝りすぎると返って使いづらいものになる場合もあるので、ユーザが使い慣れたUIがよいですね。 Microsoft <3 Android タイトルの"<3"ですが、ハートを表しているようです。 内容としては Microsoftでは常に1〜3年先のものを開発している(エンジニアの部門) Researchの部門で3年以上先に出るようなものを開発している 開発体制の変更 いままではWindowsを3年単位で開発・リリースしてきたが、アジャイル開発に変えて日〜月単位での開発・リリースをするようにした Visual Studio Communityを発表。C#/C++でAndroid開発をすることができる エミュレータで加速度をエミュレート、バッテリー残量を意図的に減らしたりする事が可能 エミュレータで加速度やバッテリーをいじったりするのはgenymotionのプレミアム会員で出来るみたいですが、 無料で使えるのは魅力的かと思います。 ウェアラブルコンピューティングとAndroidの未来 神戸大学大学院 塚本昌彦教授による講演で、非常に興味深かったです。 Singularity(シンギュラリティ)についての話が冒頭に出てきており、このSingularityは日本語に訳すと特異点というらしいです。 宇宙に関する話でよく出てくるようですがICTの分野だと「技術的特異点」などと訳されます。 Singularityはすぐ近くに来る、と言われていますが、具体的には2045年問題とも呼ばれているようですね。 人工知能が人間の知能を超える時がくる・・・SFの世界のような話で少し怖いですがどうなるのでしょう。 ウェアラブルの未来はというと、 ウェアラブルは単なるバズワードでは終わらない。特に春以降大きく変化していくと思われる SmartWatch3ではWifiもハード的に搭載している スマホが大きくなりすぎたため、スマホに変わる常時身に付けているデバイスになり、単独利用が増える 企業のウェアラブル参入が増加 マルチウォッチ対応してほしい(そもそも二つもWearつける人がいるのか分からない・・・) 最初はどうしても使いづらいのが特徴だが、実世界サービスやビジネス用としてのポテンシャルを膨大に持っている 今のところは通知連携やスマホの補助的ツールとしての使い方がメインかと思いますが、 今後はWear単独での利用が予想されたり、便利なツールが出てきそうですね。 これからどの程度成長してくるかは分かりませんが、HOME'Sでいち早くWear対応出来たのは良かったかな、と思っています。 Material Designの勘所 先ほど少し触れましたが、マテリアルデザインについても聞いてみました。 マテリアルデザインは、ガイドラインというよりは異なるデバイス間でも統一した体験が出来るためのデザイン思想のことです。 少しまとめると Visual Language(視覚的言語)である 紙とインクをコンピュータの世界へ当てはめる あらゆる物体がLayer構造で表現される(Shadowなど) タッチ、ジェスチャーにおいても自然な表現を(Ripple効果など) 要するに、活版印刷の時代に築き上げられた古き良きものをデジタルの世界にも導入しようという思想のようです。 マテリアルデザインを導入するにあたっての3つの原則 1. メタファー 実際の素材のメタファーである 素材との関係を考える 紙やボタンが重なった時の影など 2. Bold, Graphic&Intentional 大胆に活き活きと、意図的に 大きめのボタン等にすることで、ユーザアクションを強調する 3. Motionで意味を提供 モーションに意味を持たせることで、ユーザ体験の継続性を持たせる また、マテリアルデザインを考える上での3つのキーワードは 1. 環境 Z軸を考える フラットデザインが主流になっているが、配置が分かりづらい そのため、光源や環境光などを取り入れ、情報同士の関係性、分かりやすさを強調する 2. 素材の属性 物質としての高さを考える 紙であれば実質的にフラットに見えるが物質として高さが0のものは存在しない 3. 3D空間でのObject配置 http://www.google.com/design/spec/what-is-material/objects-in-3d-space.html 高さが2dpの物体があり、その上に高さ6dpの物体があるなら全体で8dpの高さとなる ActionBar / Floating Action Button / Card UI全てに3D空間として配置する ここに記載したことは、全て Googleのデザインガイドライン に入っています。 とりあえず全部読んだ方が良さそうですね。(私もこれからですが・・・) 最近マテリアルデザインを導入したアプリが増えているようなので、HOME'Sでも導入してみたいです。 歴史は繰り返す+トレンド 裏読みで2015年のモバイルを予測する 携帯コレクター小暮さん＆アスキーの遠藤さんによるトークセッション。 タイトル通り、これまでの変遷をもとに今後のトレンドを予測する話でした。 歴史は繰り返す これまでを見る限り、5〜10年サイクルで課金体系が変わってきている 1989年：モバイルインターネットの試行錯誤の時期 ダイヤルQ2による課金が主流 1999年：iモードの出現により課金体系がほぼ確率 2008年：iPhone, Androidの出現によりアプリ内課金が主流に これからはIoTの時代になり、いろんなモノがつながるようになってくる スマホは安定期に入ったのか？ これまでもいろんな異形な端末(セッションでは変態端末と言われてました・・・)が出てはすぐに消えていった スマホも実は異形な端末の部類だが、爆発的に普及した異例かもしれない ウェアラブルの今後 ウェアラブル端末にsimが差せ、それだけで通話できるようになる。となるとガラケーの再来では？ 心拍数などの身体計測系の機能はこれから欠かせなくなる。ヘルスケア機能が充実し、医療に役立つようになる。 テレビについてはどうなるのか？ 現状と変わらず？ または最近出てきているスマートテレビにシフト？ それともただ表示するだけのモニターとなり、テレビそのものが衰退？ テレビなど家電系の今後は気になりますね。 韓国でAndroid冷蔵庫が前に出たらしいですが、1年でなくなったらしいです。結構便利そうですが・・・ 話を聞いていると確かに歴史が繰り返されていると言える部分があると感じました。 これからどうなるのかは誰にも分かりませんが、このような視点での予測も面白いですね。 バザール バザールにも多数出店されていました。 サーバサイドのサービス紹介やMicrosoftのVisual Studioの紹介、Googleの秘密本配布など多数ありましたが、 その中で一点気になったのが、スマホアプリ開発技術検定試験というものがありました。 https://spkentei.jp 受講費用無料でiOS, Android, html5 CSS3などに対応しているとのことです。 学校等でも採用されているらしく、力試し受けてみてもいいかもしれません。 また会社の開発チームで受けることで技術力計測/向上にも使えそうです。 全体的に 初めてABCに参加したのですが、インターネットでの最新ニュースだけでは仕入れられないような話も聞けて、参加した価値があったと思います。 今回は、Android5.0およびAndroid Wearが発表された後に開催されただけあって、 内容もそれに関することが多かったようですね。 Android HOME'Sでも先日 Android Wear対応版 をリリースしましたが、 ウェアラブルが盛り上がって行っているようで、安心しています。 今後も最先端の技術を取り入れつつ、使い勝手の良いアプリを作っていければと思います。 また、最後の懇談会では多数の方とお名刺交換させて頂き、ありがとうございました。 じゃんけん大会でもみごと景品ゲットできたので、大満足です。 次回のABCは、2015/7/20(月・祝) 川崎振興会館にて開催とのことなので、 これからも参加していきたいと思います。

Apple原理主義者であり、Paper原理主義者でもある大坪です。 FacebookのPaperを起動してまず気がつくのがトップ画面のアニメーションでしょう。↓のビデオで親指を下から上に動かすとそれに合わせて、長方形型の写真やら文章がが「ぶわっ」と大きくなるところです。 このように特徴的なUIをもったアプリの発表から、それを再現するコードの公開までの速さには驚かされます。CocoaControlsには同じアニメーションを再現しようとしているプログラムが二つ公開されています。 HAPaperViewController MMPaper 両方とも希望をあたえてくれると共に、Facebook Paperまでの距離の遠さを思い知らされることにもなる。なぜそう考えるのか、そして私の試みがどの程度進んだのかについて書きます。 最近発表されたMMPaperの方を実際に動かしてみましょう。Facebook paperに比べていくつかの部分が気になります。 ズームするときの動きがスムーズではない（To doにもあげられていますが） 指を離した後、自動的にズームしている間、およびそのあと少しの間はジェスチャを受け付けない。つまりジェスチャが時々空振りする。 （他にもありますが、ひとまずここまで） これらの問題を できるだけ 解消することを目指しました。 ーーー コードは GitHub に置きました。実行する前に"Podfile"のあるディレクトリで"pods install"とするのを忘れないでください。 アプリを起動するとこんな風に動きます 起動すると二つボタンが並んだ画面がでてきます。"Responsive"が今回あれこれ工夫した つもり のバージョン、"Standard"が「普通に」実装したバージョンです。"Responsive"のほうが何かとスムーズに動きますよね。ね？ね？（血走った目で懇願） このデモを見てもなお読み続けてくれる心の広い方がいると信じて細かい説明をします。 ーーー Paperトップ画面の動きをみると 「これはUICollectionViewを使ったCustom Transitionだ」 と思う。さて、どのような方式で実装するか？方法は私が思いつくところでは二つあり Layout-to-layout transition(例： taktamur/PAMTransitionSample ） UICollectionViewController-to-UICollectionViewController transition(例： timarnold/UICollectionView-Transition-Demo ） ちなみに先ほど挙げたMMPaperは後者の方式で実装されています。厳密に比較したわけではないのですが、普通に実装すると UICollectionViewController-to-UICollectionViewControllerのほうがスムーズに動くようです。 私も最初UICollectionViewController-to-UICollectionViewControllerで実装したのですが、後述する理由によりLayout-to-layout を使っています。とはいえ普通に実装したのでは"Standard"を選択した時のような動きにしかならない。ではどうするか。 デモプログラムの"Standard"と"Responsive"の違いは二つで "Standard"ではイメージ表示にUIImageViewを、"Responsive"ではASImageNode（in AsyncDisplayKit ）を使っている。 UIPanGestureRecognizerがUIGestureRecognizerState.Endedを返してきた後(つまりユーザがスワイプジェスチャを終了した後)"Standard"ではfinishInteractiveTransition()を呼んでいる。"Responsive"ではFacebook Popを使って終了位置までのアニメーションを制御し、その間に新たにタッチが始まった場合にはアニメーションを中断するようにしている。 他の処理は全て同一。ではどのような狙いでこのような「変更」を加えたか。 一点目、レスポンスをあげるため、ジェスチャに対応したセルの変形処理が少しでも軽くなるように、ASImageNodeを用いました。しかし正直に言えば今回のような使い方でどれだけ効果があるのかは今ひとつわかりません。触っていると、確かに少しレスポンスが良いような気がしますが、製作者の贔屓目からもしれません。 ASyncDisplayKitのページ に単にUIImageViewをASImageNodeに置き換えただけでも一部の処理がバックグラウンドで処理されるため効果がある、と記載されていますが... 二点目。"Standard"ではUIPanGestureRecognizerのコールバック関数で、UIGestureRecognizerのstateがUIGestureRecognizerState.Endedだった時にこんな処理を行っています。 if success { 　self.collectionView?.finishInteractiveTransition() 　self.toBeExpandedFlag = !self.toBeExpandedFlag } else{ 　self.collectionView?.cancelInteractiveTransition() } 遷移を完了させたければfinishInteractiveTransition()を呼び、キャンセルならばcancelInteractiveTransition()を呼ぶ。コードは簡単明瞭ですがここに問題がある。前掲のサンプルを解説しているページから引用します。 ここで注意するのは、ジェスチャーの終了からアニメーションの完了までに隙間時間(A)がある事です。progressが0.6等の半端な場合にfinishInteractiveTransitionやcancelInteractiveTransitionを呼び出すと、progress1.0になるまでアニメーションして（体感1秒程度かかるときがある）、その後にcompletionブロックが呼び出されます。 この隙間時間に次のtransitionを開始しようとするとクラッシュします。 引用元： UICollectionViewをジェスチャーで拡大縮小したい(iOS7〜) - Qiita このサンプルに習い、クラッシュを避けるため"Standard"ではジェスチャーの終了後UIGestureRecognizerを停止しています。こうすると確かにクラッシュしないのですが、その間ユーザの操作を受け付けることができない。そして時としてこのfinishInteractiveTransition()を呼んだことによるアニメーションは見かけより長くかかる。反応しない画面上をひたすらスワイプするのはどう考えても楽しくない。 というわけで"Responsive"では、ジェスチャーを終了した後のアニメーションを自前で実装しています。（参考にしたのは このサイト ） UIKitDynamicsを使っても いいとは思うのですが、ここは同じくFacebookから公開されているPopを使いました。 *1 今のプログラムは指を離してから拡大または縮小が確定するまでのわずかな時間に再度スワイプを始めた場合、進行中のアニメーションをキャンセルし、ユーザのタッチに反応します。 （わずかな例外を除いて） 正直に書きますが、まだ「不感帯」が残っておりswipeが空振りになることがある。しかし"Standard"より「マシ」になっている、というのはある程度の自信を持って言えます。いや、素直にUICollectionViewController-to-UICollectionViewControllerで実装したの(例えばMMPaper)に比べてどうなんだ、と問われると下を向いてしまいますが.. ーーー Facebook paperチームのエンジニアはプレゼンでこう述べています。 最初にiPhoneに触った時、まるで魔法のように感じた。Appleは表示するコンテンツとユーザの間にあるバリアを取り除き、ユーザが直接コンテンツを操作することを可能にしたからだ。しかしユーザのジェスチャが認識されなかったり、アニメーションが滑らかでないとそうした魔法は消え去ってしまう。 そうして作られたPaperではすべての動きが軽く、そして連続的に動く。それは初めてIPhoneの慣性スクロールに触った時と同じ驚きを与えてくれる。 今回の試みには「不感帯」の他にも大きな問題が存在しています。Paperでは縦方向の拡大ジェスチャと横方向のスクロールジェスチャを両方同時に行うことができる。今のところこれを実現させる方法がわかりません。未だ撲滅できない「不感帯」があることも考えると、ゴールははるか彼方に霞んでいるとしか思えない。 そもそもFacebookが公開したライブラリを使いながら、依然として存在しているこの距離は一体どういうことか、という根源的な問題からは目をそらし、もう少ししつこく 「魔法」 の再現に努力したいと思っています。 *1 : ちなみにUICollectionViewController-to-UICollectionViewControllerで実装すると、指を離した後のアニメーション時にUIGestureRecognizerがそもそも反応してくれません。クラッシュしないのはいいのですが、工夫のしようもない。というわけでLayout-to-layout を使っています。