読者です 読者をやめる 読者になる 読者になる

Logicoolのイケてるプレゼンツール「Spotlight」

久しぶりのブログ更新はまたもNon-Techな感じで。

 

先日発表されて話題を呼んでいるLogicoolの新しいプレゼンツール「Spotlight」が3/22に一般販売が開始されました。

www.logicool.co.jp

 

Amazonだとちょっとだけ安く買えるけどApple Store限定のシルバーは購入できない。 

自分の周りではAppleStore限定カラーのシルバーが多く、たまにブラックって感じだったので自分はゴールドを選択。早速届いたので簡単にご紹介。

開封の儀

外箱

f:id:Keisuke69:20170325103105j:image

開けるとこんな感じで収まってる。Appleに通じる高級感のある感じだ。

f:id:Keisuke69:20170325103114j:image

本体の下には充電用のUSBケーブルと更にその下には収納用ポーチが。

f:id:Keisuke69:20170325103127j:image

充電用USBケーブル

f:id:Keisuke69:20170325103135j:image

よくあるMicroUSBではなくType-Cである。自分にとっては初のType-C採用デバイスなので持ち歩くケーブルがまた一本増えてしまうなー
しかし、このSpotlightは充電周りも優れもの。1分の充電で3時間使え、60分のフル充電を行えば3ヶ月持つのだ。なのでケーブルを持ち歩かなくてもいいかも知れない。まあ短いから持ち歩くだろうけど。

f:id:Keisuke69:20170325103155j:image

 

こちらが本体を取り出したところ。f:id:Keisuke69:20170325103200j:image

本体下部に収まっている白いパーツはUSBのレシーバになってて簡単に外せる。

f:id:Keisuke69:20170325103207j:image

 

外した後の本体側の奥には充電用のType-Cのポートが。f:id:Keisuke69:20170325103213j:image

 

こちらがUSBのレシーバ。しかし、今回はBluetoothで接続する。

f:id:Keisuke69:20170325103219j:image

 

充電ケーブル取り付けたらこんな感じ。f:id:Keisuke69:20170325103224j:image

 

充電中はこんな感じで上部が白くゆっくり点滅する。f:id:Keisuke69:20170325103232j:image

 

セットアップ

このプレゼンツールはPCにソフトウェアをインストールして利用する。また、ボタンの設定を変更することも可能だ。
ソフトウェア自体はここからダウンロードする。

http://support.logicool.co.jp/ja_jp/product/spotlight-presentation-remote

 

ダウンロードしたインストーラをダブルクリックしたらセットアップ開始。

f:id:Keisuke69:20170325105328p:plain

f:id:Keisuke69:20170325105338p:plain

インストールをクリックするとインストールが開始されるんだけど、進捗がライトグリーンの円で表示されていて、進行するにつれ大きくなる。

f:id:Keisuke69:20170325105350p:plain

インストール完了。続いて充電だ。f:id:Keisuke69:20170325105359p:plain

まずは充電だ。付属の充電用USBケーブルをPCなりに接続して充電する。

f:id:Keisuke69:20170325105404p:plain

f:id:Keisuke69:20170325105409p:plain

f:id:Keisuke69:20170325105414p:plain

f:id:Keisuke69:20170325105419p:plain

これも進捗がライトグリーンの円の大きさで表現される。

f:id:Keisuke69:20170325105428p:plain

f:id:Keisuke69:20170325105441p:plain

f:id:Keisuke69:20170325105449p:plain

f:id:Keisuke69:20170325105512p:plain

続いてPCとの接続。画面上ではUSBのレシーバを使って接続する手順が表示されているが、今回はBluetoothで接続するので、画面左下に表示されている"Or click here to connect via Bluetooth"をクリックする。下図の赤枠で囲ったところだ。

f:id:Keisuke69:20170325111002p:plain

そうするとBluetoothでの接続手順が表示される。上下のボタンを同時に2秒押すと勝手につながる。

f:id:Keisuke69:20170325105544p:plain

こんな感じで接続される。

f:id:Keisuke69:20170325105550p:plain

ここからはSpotlightの実際の使い方のガイドが始まる。

f:id:Keisuke69:20170325105559p:plain

真ん中の大きなボタンはNEXTボタン。押すと次のページへ。

f:id:Keisuke69:20170325105635p:plain

下のボタンはBACKボタンでスライドを一枚戻れる。

f:id:Keisuke69:20170325105652p:plain

そして上のボタンが、Spotlightの最大の特徴であるハイライト機能のボタン。押しっぱなしにするとハイライトしたい箇所「以外」が薄くグレーアウトする。ここでも実際に試せる。

f:id:Keisuke69:20170325105659p:plain

これはタイマー機能。

f:id:Keisuke69:20170325105710p:plain

設定した時間が残り5分になると本体が振動する。

f:id:Keisuke69:20170325105716p:plain

残り0分、つまり終了時間になるとまた振動する。

f:id:Keisuke69:20170325105722p:plain

終了。"EXPLORE THE APP"をクリックすると設定画面が開く。

f:id:Keisuke69:20170325105743p:plain

 ポインターのモードなどが変更できる。あとは真ん中の「NEXT」ボタンや下部の「BACK」ボタンを押しっぱなしにしたときの動作などが設定できる。長押しで画面をブラックアウトさせたり、任意のショートカットを登録できたりする。自分はひとまずNEXTボタンに画面のブラックアウトだけ設定した。

f:id:Keisuke69:20170325105749p:plain

 

試してみる

実際のスライドを使って試してみた。ハイライトするとこんな感じで自分がハイライトしている箇所以外はグレーアウトされる。

f:id:Keisuke69:20170325113400p:plain

もちろんハイライトボタンを押しっぱなしにして画面上で動かすことも可能だ。
ていうか、普段黒背景のスライドを作ることが多いんだけどこれだと見にくいかもなー。ハイライトする円の大きさやグレーアウトする部分の透明度の設定が変更できるといいんだけど。と思ったら円の大きさは設定で変更できるようだ。

f:id:Keisuke69:20170325113405p:plain

やはり背景が白いスライドのほうがハイライトがわかりやすい。これは今後のスライド作りを考えないとだな。

f:id:Keisuke69:20170325115230p:plain

 

というわけで

総じていい感じだけど、Bluetoothだからなのかソフトウェア処理だからなのかハイライトしたときのカーソルへの追従が若干もたつく感じもしたので時間のあるときにレシーバでの接続も試してみたい。もたつくとはいえ、ごくわずかなものなのでそれほど大きな問題ではないかな。あとは先の通り透明度の設定とかができるとなおいい。

次のプレゼンの機会から使っていこうと思うんだけど、そういえばしばらく登壇予定がないな…
ということで登壇依頼もよろしくお願いしますmm

追記

今回、自分はBluetoothで接続してるんだけど本体には電源スイッチ的なものがなく切断と再接続をどうすればいいのか少しだけ悩んでしまった。ドキュメント(といっても大したものはないんだけど)にも特に言及がない。
切断はメニューバーのBluetoothの箇所から切断を選べばいいけど再接続をどうしたものかと。結論から言うと本体のいずれかのボタンを押して少しすると振動とともに自動的につながる。これはこれでカバンの中とかで勝手に接続されてしまったりしないか若干不安なところ。

 

追記その2

せっかくなのでポインターモードの変更を試してみた。

まず、これが通常のハイライト。

f:id:Keisuke69:20170325115230p:plain

次にハイライト箇所をズームできる"Magnify"をONにした状態。これはハイライトボタンをダブルクリックすることで有効になる。ハイライトしている箇所が拡大されているのがおわかりだろうか。

f:id:Keisuke69:20170325122057p:plain

 そしてこれが"Circle"を有効にした状態。これは画面上に円を表示するだけ。同じくハイライトボタンのダブルクリックで表示されるのだけどほどなく消える。これは逆に白背景のスライドだとわかりにくい上に、利用シーンがパッとは思いつかなかった。

f:id:Keisuke69:20170325122251p:plain

というわけで自分はMagnifyだけ有効にすることに。あまり使わなさそうだけど。

テレビを白くペイントしてみた

久しぶりの更新です。

今日は技術的な話でもなんでもなく、最近引っ越しをしたのでそれを機にテレビを白く塗ってみたということでその経過を。

ちなみにDIYとかそういうのは初めてです。

ではなぜ、こんなことをしたのかというと、9月に引っ越しをしたのですが新居がナチュラル系かつ白ベースでいろんなものを揃えています。

しかし、テレビとテレビボードは前の家から持ってきたものをそのまま使っているのでテレビがグレーというかシルバーというかそんな感じの色でテレビボードは黒です。

そんなときロンハーマンの店でテレビを雑に白く塗っているのを見かけて、これいいじゃん!と。というわけでどうせ近々買い換える予定だし、試しに塗ってみることにしました。

今回はテレビに加えてテレビ用のバースピーカーも一緒に塗ります。テレビボードはまた今度にしました。

塗るにあたり用意したのは以下。

  • オールドビレッジのホワイト
  • サンドペーパー
  • プラスチック用プライマー
  • 刷毛とマスキングテープ

オールドビレッジのペンキは東急ハンズでたまたま見つけたものなんだけど、アーリーアメリカンな風合いのいい感じに仕上がるというもの。色合いが柔らかい感じで仕上がりもマットになる。

 プラスチック用プライマーはテレビのガワってプラスチック勢なのでそのままだとペンキが乗りにくい。そのためペンキを塗る前に下地としてこいつを塗布する。

 

アサヒペン プラスチック用プライマー 300ML クリヤ
 

 全体的な流れは以下の通り。

  1. テレビ、スピーカーを分解する
  2. サンドペーパーでヤスリがけ
  3. プライマーを塗布して乾燥させる
  4. ペンキを塗り、乾燥させる(1回目)
  5. 2度塗り
  6. 組み立て

分解をしたのは液晶パネルの部分とか細かいマスキングをするより、はずしてしまってガーッとやったほうが楽だと思ったから。なお、ヤスリがけはプライマーを使う場合は要らないって話もあったけど一応やっておいた。ちなみに今回はサンダーとかそういうのもっていなかったため、手作業でやったので全行程でこれが一番疲れた。次は絶対サンダー買おう。

では実際の流れは当日のツイートを。

 

 

まずは試しに台座部分だけ塗ってみた。

 

残りの部分を一気に。

ネジは最終的に8本ほど余ったんだけど、気にしない。とりあえず今のところ何の問題もなく映っている。

実はこの塗り直しがすごく大変だった。正確には塗り直すためにメッシュ部分を洗い落とすのが大変。水性ペンキだし簡単に落ちるかと思いきや意外と落ちず、メッシュの目に詰まってしまっており、それを一つずつ取り除くのに軽く2時間はかかった。

 

というわけで無事に完成。サイドにある電源などのスイッチ類のパネルが分解した際に本体基盤側にくっついたままだったので塗らなかったんだけどやはり塗っておけば良かったと少し公開している。

あと、リモコンの受光部もお構いなしに塗ったのでリモコンの反応が少し鈍くなった。

 

InnovationEGG第7回「クラウドネイティブ化する世界」に登壇してきました(とその感想)

@Keisuke69です。

3月の19日(土)に大阪で開催された、InnovationEGG第7回「クラウドネイティブ化する世界」でお話をしてきました。

今回の話の内容としてはデブサミで話した内容をベースにスケーラブルなアプリケーションをクラウド上でどう作るか、といった観点でお話をしてきました。まあTwelve Factor AppとかMicroservicesとかの文脈ですね。

資料はこちらです。

イベントの内容とか他の登壇者の話の概要やスライドは同じくこのイベントに登壇・参加されたハンズラボさんのブログでまとめられているのでこちらをどうぞ。

www.hands-lab.com

 

今回のイベント、プラットフォームとしてどこか特定サービスに限定しているわけではなかったので各登壇者の話の幅も広く興味深かったです。また、イベントタイトルにもなっている「クラウドネイティブ」というキーワードについてみなさん最初に定義付けをしたあと話をしている辺り、やはりこのキーワードを取り回す難しさがあるのかなーと感じたり。

加えて、全体的にイベント前に想定していたよりもプラットフォーム側の話が多く、あまりそういった話をする予定のなかった自分としては時間が進むにつれてドキドキしていました。ふと思ったのですがクラウドネイティブというキーワードのイベントにおける参加者のエンジニア属性がどういったものなのかは非常に興味のあるところです。個人的な感覚ではインフラエンジニアのうほうが多いかなとは思ってるんですが実際のところはどうなんでしょう。本来的にはクラウドネイティブって特定サービスの使い方の話ではなくアプリケーションアーキテクチャの話だと思うのですが将来的に逆転したりするんでしょうか?それともやはり「クラウドネイティブ(を支えるプラットフォーム)」的な感じでやはりプラットフォーム側の人のほうがこの界隈では中心になるのかといったところも興味深いです。

 

さて、個人的に印象に残ったこととしては、クラウドネイティブというよりはサーバレスアーキテクチャの話になるのですが、ハンズラボ加藤さんの発表で言及されていた

  • 運用コストを下げたくてサーバレスアーキテクチャにしたものの開発はLAMPの3倍かかった
  • ただし、そのほとんどは学習コストであり2回目以降は爆速開発できそう

というのがどうしてもコンセプトが先行しているところのあるサーバレスアーキテクチャに対する実体験からの貴重な意見ということで参考になりました。このシステム自体は大人の事情でお蔵入りになったとのことで非常に残念ですが、リリースしてしばらく運用してみた上でのサーバレスアーキテクチャに関する評価というのもお聞きしてみたかったところです。そういった話はあと1年もすればもっと聞けるようになるかと思っています。その上でやはりむやみに高まった期待感を裏切られることによる揺り戻しというのも発生しつつ一つの潮流になっていくのではないかと考えています。

 

というわけでお話の機会を頂きありがとうございました。

しばらくパブリックな場での登壇予定はないのでのんびり過ごします。

クラウドネイティブとサーバレスアーキテクチャ

こんにちは、@Keisuke69 です。

ポエムです。

クラウドネイティブとサーバレスアーキテクチャと言うものに関してなんとなく整理がてら書きたいなーと思って。

ま、この2つを一緒に話すのはどうなんだって気もするがポエムなので気にしない。あと文章長い割りに大して中身はない。

クラウドネイティブ

そもそもクラウドネイティブとはなんなのか。クラウドネイティブって言葉が先行していて実際のところなんなのか分からない人も多いはず。何かきちんとした単語の定義があるかっていうともちろんそんなのあるわけない。人それぞれモヤっとしたイメージがきっとあってそれを一言で表現するのにクラウドネイティブってキーワードが使われてるのかなと。ラベリング重要。
 
とはいえ、クラウドネイティブというお題で僕が話をするときに毎回最初に定義をしていて、その定義は以下の通りだ。
  • クラウドで提供されるサービス利用を前提に構築するシステムおよびアプリケーション
  • クラウドの特性を踏まえ、利点を最大限に活かす形で構築されたアプリケーション
  • クラウドで提供されるサービスを利用して効率的にアプリケーションを実装
こうやって見ると1つ目はクラウドネイティブというよりも、この用語が出てくるちょっと前に使われていた(今も使われている?)クラウドファーストの定義に近いかも知れない。うん、これは今後は外そう。で、一番大事なのは2番めのやつだと思っている。
 
まず、最近誤解されている気がするのであえて言っておくとクラウドネイティブそのものはAWSネイティヴとは違う。混同されがちだし、あえて同じコンテキストで話がされていることもあるが本来はそもそものコンテキストが違うのだ。そんなのわかってるよって人は読み飛ばしてくれて構わない。
AWSネイティブはその言葉通りAWSの各サービスをフル活用してアプリケーション開発することでスピードとスケールを手に入れようという話である。一方クラウドネイティブはサービスとして提供されている機能群を有効活用するのというのもあるが、根本的にはクラウドだからこそのスケーラビリティや俊敏性を活かして分散的にシステム構築することでレジリエンシ高くスケーラビリティの高いシステムを作ろうということだと思っている*1*2
広義のクラウドネイティブにはAWSネイティブも含まれるかも知れないが先述のとおり本来はコンテキストレベルの違う話だと思っている。したがってAPI GatewayとLambdaを使ってサーバレスアーキテクチャにすることがクラウドネイティブなのではない。クラウドネイティブの本質はレジリエンシとスケーラビリティをいかに高めるかだと思っていて、そのためのシステムおよびアプリケーションのアーキテクチャの話なのだ。このシステム、アーキテクチャ面での考え方自体はクラウド以前からあったと思うし、考え方そのものはサーバが物理だろうが仮想だろうが関係ない。ましてやそこにサーバがあるかないかなんて大事な話ではない。ただ、それがクラウドの登場により実現に現実味が増したと言えるということだ。ようやく誰でも実現可能になったと言ってもいい。従って旧世代のシステムをそのままの構成で単にクラウド上にマイグレーションすることはクラウドネイティブとは呼びがたい*3
 
加えて、クラウドネイティブなシステム作りをドライブするためには(開発における)ユーザ体験も非常に大事だと思っている。クラウドネイティブだかなんだか知らないけど開発する上ではやっぱり楽なほうがいいよね、と。ローカルで開発してクラウド上にアップするというのが今の多くのスタイルだと思う。もちろん実際にはCI/CDなりのプロセスや自動化なんかが間にはあって、各個人が直接ローカルから都度アップロードしているわけではないと思うが、そういった自動化だとかがアプリ開発者に意識させずに使えるようになると真のクラウドネイティブな気がするな。あとはレジリエンシを高めるためにはモニタリング必須になってくるのでその辺りとかも組み込まれてるといいね。そういう意味ではアプリケーションフレームワークとの密接な関連性、透過的なクラウド利用なんかが求められてくるのかも知れない(適当

サーバレスアーキテクチャ

この言葉自体はそれまでにもあったとは思うけど僕がこのキーワードを使いだしたのはそう、あれはAPI Gatewayがローンチされてからだ。それまで僕は2 Tier Architectureというものをいろんなところで語っていた。2 Tier Architecture自体はここでは触れないが、それ自体はいいと思っているが採用できる局面は限定的と言える。なぜなら2 Tier Architectureを採用した場合、ロジックをクライアント側に持ってくる必要があるからだ。クライアント側にロジックを持ってくると何が問題か。問題の1つとしてマルチプラットフォーム対応があげられる。これが面倒なのだ。各プラットフォームごとにUIに関する部分以外のロジックを実装しなくてはならなくなる。同じ内容を違う言語で、だ。当然、テストコードもそれぞれ必要になるからそれがどれだけ大変なことかは想像に難くない。そこでロジックはサーバサイドに持って行って共通化しよう、そしてその処理はアプリからAPI経由で呼び出そう、となる。そうすると今度はサーバサイドのロジックを書くだけでなくAPIとして公開するためのインフラの構築・運用が必要になってくる。そんなわけでこの辺りから2 Tier Architectureじゃなくなる、というか限界が見えてくる。採用できる局面が限定的としたのはこういう理由からである。ハマれば絶大的な効果があると思うが、そうでない場合は従来どおり3 Tier*4なシステムを、と言っていた。
 
この時点で元来チームにフロントエンド系のエンジニアしかいない場合には絶望的だ。そもそもクライアントにロジックを持っていく判断をしたチームにインフラエンジニアがいるとも思えない。そこで出てくるのがサーバレスアーキテクチャである。AWSで言うと、Amazon API GatewayAWS LambdaおよびDynamoDBとかを組み合わせたものをよく例として挙げているがこれはサーバレスアーキテクチャの一例に過ぎない。別にLambdaを使うからサーバレスだとは思わない。平たく言うとマネージドサービスを使うことで(ある一定範囲までは)楽をするモデルなのだ。これまで自分で構築して運用してきたサーバ群の代わりにサービスとして提供されるマネージドサービスを必要に応じて、必要な分だけ、必要なときに使うのがサーバレスアーキテクチャだと考えている。従ってフルサーバレスなアーキテクチャにできる場合もあれば一部がサーバレスな場合もあるかも知れない(というかそのほうが多いだろう)。あちこちでサーバレスアーキテクチャの考察的なものも見受けられるが、そんな大層なものではなくってぶっちゃけた話、ユーザの視点から見てユーザが自分でお守りをしなければいけないサーバ(インフラ)があるかないかってだけじゃないかな。少なくとも僕はそう思って話をしている。だからインフラの構築・運用にかかるコスト(これには当然それらを担当するエンジニアを抱えるコストも含まれる)や仕様面を比較した上で任せられるなら任せてしまえばいい。マネージドサービスを有効活用することはとてもいいことだと思うがそれに縛られるのは本末顛倒だ。本来あなたがやりたいことは何なのか思い出して欲しい。とはいえ、サーバレスアーキテクチャとはそうではないと思う人がいたらぜひディスカッションしたいです。
 
最後にクラウドネイティブとサーバレスアーキテクチャってタイトルなので両者の関係について言うと、サーバレスアーキテクチャを実現するクラウド側のサービス群はクラウドネイティブに作られてるだろうけどユーザが作るクラウドネイティブなシステム=サーバレスアーキテクチャではないかなっと。
 
あ、一応免責つけておこうw
本ブログは個人としての意見であり所属する企業や団体を代表するものでも見解を示すものでもありません。

*1:従ってLambdaを単に使うことがクラウドネイティブなのではない。Docker使うことがMicroserviceじゃないってのと一緒だ。

*2:以前は「マネージドサービスを上手く使って〜」みたいな話もしていたがそれが故にクラウドネイティブとAWSネイティヴを混同させてしまったのならばそこは謝りたい。

*3:単純移行そのものを否定しているわけではない。クラウド活用のファーストステップとしては現実的な選択肢だ

*4:従来型のWeb/アプリケーションサーバとDBサーバからなるやつ

JAWS DAYS 2016で登壇してきました

3/12(土)に開催されたJAWS DAYS 2016でAWS Lambda / Amazon API Gatewayについて話をしてきました。

JAWS DAYSは6月に開催されるAWS Summitとは異なり、AWSのユーザグループであるJAWS(Japan AWS User Group)が主体となって年に一度開催されるイベントなんだけど、参加者の数が1000名を越えるというすごいイベントなんです。今年は1100名超えでかつ参加者も初参加の人が多かったという話を聞いていて改めて関係者の皆さんすごいなーと頭がさがるばかりです。

 

この日、自分は先のエントリでも報告したABC2016からの連投だったんだけど、ABC2016とは異なり担当している2つのサービスをより掘り下げる感じの内容で話をしました。

資料はこちら。

 
今回は時間も25分程度と限られていたので概要とか基本的な部分を一切省いて、実装上のアレコレについて掘り下げるような感じにしています。中でもスライドのP22、P23にあるイベントソースごとの実行タイプやリトライの違いのまとめや同時実行数に関する考え方はドキュメントを読んでもわかりにくいことも多いので参考になるのでは?
特に同時実行数に関してAmazon KinesisおよびAmazon DynamoDBをイベントソースにしている場合の挙動を正しく理解されていない方が多いなーと最近感じていたのでこういう場でお伝えできたのは良かったかと。なお、これに関しては改めて別途Qiitaか何かで解説したいと考えている。
とはいえこういった話をまとめたには少しだけ理由があって、日本でもLambdaの利用が増えてはいるんだけど、いざLambdaを使ってシステムを作ろうとしたときにそのコンセプトや性質からうまく使い切れていないケースとかハマってしまうケースを最近よく目にしていて。
なのでその辺りに躓くことなくビジネスをドライブする手助けになれば、と思ったのとそろそろLambdaのできることを紹介するだけのフェーズから実際に利用するにあたってのノウハウを伝えていくフェーズになりつつあることを感じているため今回はこういう話にしました。
それはともかく、内容的にもかなりてんこ盛りにしたので25分という短時間で伝えきるために結構早口でまくし立てる感じになったので、あらかじめそのつもりだったとは言えそこは少し残念なところなので機会があればどっか別のところで再度やりたい。オファー待ってます
 
※余談だけど、もともと時間の短さからタイトルにあるDeepDiveは難しいと思っていて、せいぜい浅瀬でバチャバチャやる程度かなと思って皮肉った結果がこのスライドの表紙というのは内緒
 
あとはQ&Aの時間も取れず、イベント自体にも連投の関係で自分のセッション時間からしかいなかったためMeet the SAのコーナーにもいれず全く参加者の方とお話できなかったのは反省だし、他の方のセッションもほとんど聞けずじまいだったのも残念。ABC2016もそっちはそっちで人のセッション聞けずこっちも全然だったので疲労感の割に自分自身が得たものはあまりないという…
 
というわけでまた機会があればお話をしたいと思うのでご連絡ください。
あと、制限緩和の際もぜひ事前にご相談をmm(ってなんか宣伝みたくなってしまったな)

ABC 2016 Springで登壇してきました

3/12(土)に特定非営利活動法人である日本Androidの会が主催するABC 2016 Springで講演の機会を頂いたので登壇してきました。

abc.android-group.jp

 

今回は「AndroidとIoT」というテーマでオファー頂いたのでいつもとは違った話をしてきました。

内容的には

  • AmazonにおけるIoTの取り組み
  • AndroidをIoTに活用する際の利用パターンの説明
  • AWSのモバイルサービス紹介
  • IoTにおけるデータ収集パターンの説明、使いどころの説明
  • 各パターンにおけるキーとなるAWSのサービスを紹介

という感じの話を。

当日の資料はこちら。

 

なお、AmazonにおけるIoTって部分でAWSのSimple Beer Serviceっていうサービスを紹介。これはオフィスとかSan FranciscoやNew YorkにあるPopup Loft(主にスタートアップ向けの常設スペースで、コワーキングスペース的なものや自分と同じロールであるSolutions Architectが常駐してていつでも技術相談が可能、しかも無料)においてあるビールサーバでビールを注いだ量がリアルタイムでモニタリングできるっていうバカバカしいものなんだけど、これも立派なIoTってことで紹介しておいた。
ちなみに興味のある方はこちらのブログに概要とかアーキテクチャ(ソフトウェア面、ハードウェア面の両方)とかについて詳しく書いてあるので是非見てみるといい。
また、こちらのサイトでは実際のリアルタイム状況が誰でも見れるようになっている。

Simple Beer Service | Beer = Good, Streaming Beer = Better

これを書いている今もVirginia Officeのビール流量がそこそこあるので誰かしらがビールを飲んでいるんだと思われる(でも向こうって今は日曜日の午前なんじゃないかな?)。

ちなみにこれが実際に昨年夏にSanFranciscoのPopup Loftに行ったときに設置されていたものを写真に撮ってきたもの。

f:id:Keisuke69:20150806173001j:plain

あとは自分で作るようにってことでソースコードオープンソース化されていたりするのでこちらも興味あればぜひ。日本で作ったらぜひ連絡ください。
 
さて、そんな話はともかく今回のイベントでは100名くらいが参加してくれたのがとても嬉しかったかな。ぶっちゃけアウェイだと思っていたので。
あとは当たり前と言えば当たり前なんだが挙手によるアンケートを取ったところモバイルのデベロッパーの人が多くてそのあたりも良かった。
というのも普段、モバイル開発やアーキテクチャの話をすることが多いんだけどやはりAWSというイメージからか話を聞きに来る人がインフラエンジニアのほうが多いことも多々ある。だから何か問題かって言うとそんなことは全くなくて、それはそれでいいことなんだけどやはり自分の担当領域的にももっとソフトウェア開発者、主にWeb系・モバイル系の人に話を伝えたいってのがあるのですよ。なので今回こういう機会を頂けたのは非常に有りがたかったです。
 
ちなみに今後は登壇の機会を頂いた際にはもっとGeneralな話を増やしていこうかなって思ってて、それが今の自分的なテーマ。基本的にはソフトウェアアーキテクチャの話にはなると思うんだけど、それに(AWSに限らない)クラウド的なテーマを絡めていけたらな、と。もちろん聞きに来る人達がどういう話を期待しているかってのは考慮した上でにはなるけど。AWSのサービスに関して紹介する場でそんな話ばっかしても、「お前の話を聞きにきたんじゃねーよ、サービスについて知りたくて来たんだよ」ってなるので。
 
話はそれたけど、イベントの話に戻ると実は資料の作成に直前までかかっていて午前中の他の方のセッションも聞けなかったし、自分のセッションの後は同日に行われたJAWS DAYSでの出番があったのですぐに会場を出なければいけなくって全然セッションを聞いたりできなかったのがとても残念だし悔やまれる。自分で行くものってバイアスがかかった状態でアンテナに引っかかったイベントに行く形になるのでこういう場では自分の守備範囲外の話が聞けておもしろかったりするものなのだ。
なので講演者の資料のまとめとかあると嬉しいです(事務局の方ぜひお願いします)。
 
とにもかくにも登壇の機会を頂きありがとうございました。

RESTful#とは勉強会で公開レビューしてきました

2/22にヴァル研究所さんのオフィスで開催された「RESTful#とは勉強会13回」に公開レビュー企画のゲストとしてお呼ばれしてきましたー。

この勉強会自体は今回で13回目とそこそこ回を重ねた勉強会で、RESTful APIについてみんなで学び考える会となっているそうで。すみません、こういう勉強会があることは知ってたけど参加は初めてでした。
 
で、公開レビューとは何かというとヴァル研究所さんと言えば「駅すぱあと」なわけですがこの駅すぱあとのWeb版である「駅すぱあとWeb」の公開APIをRESTの観点でみんなの前でレビューするというチャレンジングな企画でした。
 
RESTful APIが何かについては以前に発表に使ったこのスライドを参照してもらえれば。

 
さて、今回のそもそものキッカケは、この勉強会の運営にヴァル研究所の総務(!)の方が関わっているんですが、以前とある勉強会のスピーカーとして喋った際、話の中で自分がRESTおじさんだと言う話をしたところ、
「RESTの勉強会やってるんでそっちにも来てくださいよー」
「ただ行くだけじゃつまらないので公開レビューとかしますか(適当」
「じゃ駅すぱあとAPIでやっちゃいましょー(悪ノリ」
という経緯です。
 
それをまさにそのAPIを作ってる部隊のマネージャーであるヴァル研究所の見川さんに快諾頂けたので実現した感じです。
 
当日は、前半がワークショップ形式で参加者が複数のテーブルに分かれた上で、駅すぱあとのWebAPIを実際にみんなで叩きつつAPIデザインとしていいと思うところ、改善したほうがいいと思うところをディスカッション。後半が公開レビューという形。
 
実際のレビューについては、思っていたより(失礼)綺麗にAPIが設計されていたのと、サービスの性質上ほぼリソースの取得(CRUDのR)のみだったこともありそれほど言うことがなかったのが正直なところ。
というわけで一般的なRESTfulなAPIデザインにおけるベストプラクティス的なものを駅すぱあとAPIの改善点として紹介する形にした。一例として、
  • リソースの相関がURIパスとして表現されるのが良い
  • URIパスとして表現されるリソースはコレクションになるのでリソース名は複数形を使うことが多い
  • バージョンの指定方法について(パス/クエリ/ヘッダのどれを使うか)
  • 似たようなリソース名があってわかりにくい、もしくは分かれている必要がない

など。

駅すぱあとAPIをお題にこういう話をしていたんだけど、素晴らしいなと思ったのはどうしてこういうデザインになっているのですか?と聞くと見川さんからその全てに対して回答が返ってくること。パッと見ではおかしいのでは?良くないのでは?と思うようなデザインのものに対してもなぜ、どういう経緯でこの形になっているのかがちゃんと説明されるのである。これはただただ感心すると同時に見川さんのこのサービスに対する愛のようなものを感じたw と同時に駅すぱあとの裏側みたいなものも垣間見えてそれはそれで単純に面白かったと言える。

 

とまあ、それなりにいい感じで終了したんだけど、当日参加者からもあがったRESTfulである必要性や、RESTの一般的なルールをどこまで守る必要があるかについて個人的な見解を述べておく。これには異論もあると思うが。

 

まず、RESTfulであることの必要性について。RESTfulでなければいけない必要性は全くないと考えている。RESTなんてのは所詮実装指針アーキテクチャのスタイルであり原則にしか過ぎない。一方でメリットとしても語られることが多いがRESTfulなAPIはリソース指向であるが故にWebの世界と親和性が高く、URIによってリソースを特定するという概念そのものは非常にわかりやすいと言える。例えば/booksにGETリクエストをすると本のリストが返ってきて、その中の特定のアイテム、例えばbookidが1のものを取得する場合は/books/1にGETリクエストをするというのは非常にわかりやすくないか?こういったリソース名によるURIとそれに対するCRUD操作をHTTPメソッドで表現すること、そしてリクエストの応答となるステータスコードに意味があるということがRESTの最大の特徴であると同時にそういったシンプルな分かりやすさがRESTfulなAPIの最大のメリットである。単に404が返ってくるというのはページが存在しないという意味ではなく、URIで指定されたリソースが存在しないということなのである。そういう綺麗さがRESTの魅力ではあるものの、別にRESTfulでなくてもURIとして表現されるものが何らかの一定のルールに則って利用者に分かりやすければそれはそれでいいのではないかと思う。ただし、いわゆるRESTfulなAPIでないものをRESTful APIと呼んで公開されているのは個人的にはdisりの対象である。

 

そして、次にいわゆるRESTfulであるAPIとしてのルールについてだが、先にも言ったとおりRESTなんてものは標準仕様でもなんでもなく実装指針アーキテクチャスタイルでしかない。数ある解説において、共通する基本的なルールはあるものの細かいところは正直なところ人によって主義主張が違うと言っていい。例えば先のバージョンの表現方法もそうだ。/v1/booksと/v2/booksという形の場合、v1のリソースセットとv2のリソースセットは別物であるという考えからだ。一方であくまでもリソースはリソースとして同一のものでありバージョンは属性情報の一つという考え方の場合、/books?version=2といったクエリによる指定になる。加えて、リソース名の設計指針としてよく言われるリソース名は複数形で表現すべき、や複数の単語で構成されるリソース名は"-"で区切るべき、とか小文字が望ましいとかそういったのは瑣末なことであり別にどうでもいいと思ってる。勉強会での川村さんの発言にもあったが「全体で揃っていればいい」と思う。もちろん新たに設計する場合、基本的にそういったルールには則る形にはするが。

 とまあ、何が言いたいかというとRESTは綺麗なAPIデザインをする上ではとてもいい考え方だがそれに引っ張られすぎるのは本末転倒であるなのでそこそこにしてもっと本質的なことに時間割こうよ、ということである。
 
そうは言っても僕はRESTオジサンだし、REST原理主義者とも言えるのでREST的に美しくないAPIデザインは認めないんだがw 矛盾していると言われてもいい。
 
とにもかくにも関係者の皆様、こういう機会を頂きありがとうございました。
 
* 当初、実装指針と言った部分が誤解を生む表現だったので修正しました
 
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

 

 

RESTful Webサービス

RESTful Webサービス

 

 

RESTful Web APIs

RESTful Web APIs