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

Fingerprints

Over 30のITエンジニアが学習したことをまとめるブログ

HTML5 Conference 2016感想

9/3(土)にHTML5 Conference 2016に参加してきたので簡単に所感とメモをまとめます。
資料と動画はほとんど↓にあがってます。

qiita.com

参加セッション

  1. Reactの最新動向とベストプラクティス
  2. HTMLスナップショット2016
  3. Material Design を使ったマルチデバイスに対応するデザインの作り方
  4. Progressive Web Apps の次の一歩 〜 アイデンティティとペイメント
  5. Progressive Web Apps の導入基礎

1. Reactの最新動向とベストプラクティス

所感

むずかしい…
全体的にReact.jsの知識がある方向けという感じでした。
また、サンプルコードがアロー関数だったことがムズカシさの拍車をかけた印象(意識低くてすみません…)

メモ

2. HTMLスナップショット2016

所感

HTML Standardのマニュアルの各種翻訳者による、ここ最近のHTML界隈の動向。 いろいろな意味でガチ、って感じ。

3. Material Design を使ったマルチデバイスに対応するデザインの作り方

所感

大盛況(Googleブランドかなー)
Googleのマニュアルを見れば早い、という意見もありますが、
やはりこうした場で生でデモを見るとテンション上がるので意味があると思います。

メモ

  • マテリアルデザインは「紙」が持つ情報伝達による柔軟性や効率性をお手本にしたデザイン(古くて新しい気がする)
  • Googleが提供するMaterial Design Liteを使えば、フレームワークによらず簡単にマテリアルデザインが試せる
  • アニメーションを利用することで、現実の時間軸をアプリに取り入れ、よりユーザが馴染みやすいUIになる(→コミュニケーションコストの低下)
  • エラー画面に力を入れているサイトはよいサイト

4. Progressive Web Apps の次の一歩 〜 アイデンティティとペイメント

所感

一言で言えばChromeに記録されたIDやクレジットカード情報を利用して、
Webアプリでもよりログインや決済を簡素化しようとするもの。
スピーカーいわく「セキュリティが不安でしょうが、むしろ普通よりも安全」
ということでしたが、やはりセキュリティは不安に感じました。
早く実装してみたい。

メモ

  • クレジットカード決済処理はサーバ側で実装する必要がある

5. Progressive Web Apps の導入基礎

所感

プレゼン上手。 また、実際のSUUMOサイトを例に説明されていたので非常にわかりやすかった。

メモ

  • push通信のフローをおさえることが重要
  • SUUMOではpush通信後に、ひそかにデータを再取得してLocal Storageにキャッシュする、そうするとユーザがアクセスした時にネイティブアプリ並みに早く起動できる
  • The Offline cookbook というオフライン処理のわかりやすいパターン集がネットにあるとのこと

Qiita「ES6でクラス定数を使う」を理解する

たまたまJavascriptでプログラムでクラス変数使いたいなぁ、と思っていたら、素晴らしい記事がありました。

qiita.com

さて、ここに書かれていることを理解するには以下の前提が必要なので備忘録として記載します。
※上記記事が一発で理解できる人は読む必要ありません。

  1. ES6ではstaticキーワードはメソッドにしか使えない。staticメソッドは定義できるがstatic変数はできない(ES7で検討中らしい)
  2. Javascriptではgetter/setterが使える(ES6以前から)

getter

get 構文は、オブジェクトのプロパティを、プロパティが参照された時に関数が呼び出されるように結びつけます。

developer.mozilla.org

説明は難しいですが以下のサンプルコードを読むと分かりやすいですね。

var man = {
  firstName: 'Bill',
  lastName: 'Evans',
  get fullName() {
    return this.firstName + ' ' + this.lastName;
  },
};
man.fullName
=> Bill Evans

クラス変数の理解

以下のようにまずstaticメソッドを定義すると、Constant.EXCLUSION_NOTES_FOR_FLAT_KEYS()が呼び出せます。
さらに、getをつかうことでConstant.EXCLUSION_NOTES_FOR_FLAT_KEYS()が、Constant.EXCLUSION_NOTES_FOR_FLAT_KEYSと呼べます。

と書いていて気づいたのですが、これは表面的には()を書かなくてすむだけかしらん…

class Constant {
  static get EXCLUSION_NOTES_FOR_FLAT_KEYS(){
    return ['c', 'f', '_b', '_e', '_a', '_g', '_d'];
  }
}

console.log(Constant.EXCLUSION_NOTES_FOR_FLAT_KEYS)
=> ['c', 'f', '_b', '_e', '_a', '_g', '_d'];

A-FRAMEのentity-component-system patternをざくっと理解する

A-FRAMEとはmozilla製のhtmlタグやわずかなjavascriptだけで3Dプログラミングができるという魔法のようなjavascriptライブラリです。
A-FRAMEはentity-component-system patternというパターンを基礎にしています。 今日はざくっと公式HPの文章を意訳しつつ整理してゆきます。

aframe.io

エンティティ、コンポーネント、システムのまとめ

  • エンティティはいろいろな用途に使われるオブジェクトで、本質的には何も描画しない
  • コンポーネントは外観や動作(かつ/または)機能を提供するために、エンティティに差し込まれる再利用可能なモジュール。
  • システムはグローバルスコープ、サービス、コンポーネントのクラス群のマネージメントを行う

エンティティとコンポーネントの関係をさらに具体化する

例えば、「車」をエンティティに例えると、コンポーネントは以下のイメージ

これらのコンポーネントは他の乗り物(飛行機とかバイクとかボートとか)にも適用できるかも(タイヤは除く)

配置(サンプルコード)

例えば、トマト色の球をエンティティに配置する場合、「形状(geometry)」や「外観(material)」のようなコンポーネントをアタッチする。 これらのコンポーネントたちは複数の属性を持ち、それらは以下のようにインラインで定義可能。

<a-entity geometry="primitive: sphere; radius: 1.5" material="color: tomato; metalness: 0.7"></a-entity>

あれこれ欲しい外観や動作や機能を加えるために、もっともっとコンポーネントを追加できる。
光らせるために「ライト(light)」コンポーネントを追加したり、あるいは音を鳴らすために「サウンド(sound)」コンポーネントを追加したり、あるいはまた重力や衝突検知時に作用できるように「物理(physics)」コンポーネントを追加したり、というように。
他の人やサードパーティ製のコンポーネントも追加できる(中略)。

肝心のA-FRAMEとは何かとか、entity-component-system patternのスゴさとかは別に書くかもです♪

Firebase試してみた(Javascriptでデータベースを読み込みしてみた、編)

f:id:norihiko-saito-1219:20160811210928j:plain

Web Music ハッカソン#6で多くのチームがFirebaseのデータベースを使っており気になったため少し調べてみました。
Firebaseの"ファ"の字も知らなかった我々はすでに負けていたのだ。という感慨を抱きつつ(しつこい)、
サンプルチャットアプリのコードを元にコメントをつけたので公開します。
今回はデータ読み込み編です(書き込み編は後日公開予定)(Javascript)

サンプルコード

Firebase: Build a Real Time Web Chat App

Firebaseのデータベースの特徴

  • NoSQL(json形式)
  • オフラインでRead/Write可能(オフライン時にはローカルに書き込みされ、NW復帰後反映される)

サンプルコード解説

  • firebaseのデータベースを取得
    ※コンソール上で事前に用意されたDB接続用のKeyなどをjavascriptに貼り付ける必要あり
this.database = firebase.database();
  • messages のデータベースパスへのリファレンスを取得
this.messagesRef = this.database.ref('messages');
  • messagesのデータベースはこんな感じ
  • consoleからimport/exportできます
friendlychat-12345/
    messages/
        -K2ib4H77rj0LYewF7dP/
            text: "Hello"
            name: "anonymous"
        -K2ib5JHRbbL0NrztUfO/
            text: "How are you"
            name: "anonymous"
        -K2ib62mjHh34CAUbide/
            text: "I am fine"
            name: "anonymous"
  • レコードの最後の12件を取得して内容をWeb画面に表示するサンプルコード
// limitToLast(n)で最後の12件を参照(データが多すぎたときに全部読み込まないように)

// child_addedやchild_changedはデータに変化があったとき用のイベント
// child_addedはデータが追加された場合、child_changedはデータが変更された場合
// 他にはchild_removed, child_moved, value(→とにかく何らかの変化があったとき用)
// イベントリスナにはdataを引数にしたコールバック関数を指定する
this.messagesRef.limitToLast(12).on('child_added'), setMessage);
this.messagesRef.limitToLast(12).on('child_changed'), setMessage);

// data.keyでキー、data.valでバリュー、val.xxxで任意のプロパティにアクセスできる。
var setMessage = function(data) {
  var val = data.val;
  this.displayMessage(data.key, val.name, val.text, val.photoUrl, val.imageUrl);
}.bind(this);

リファレンス

Retrieve Data on the Web  |  Firebase

最後に

(今さらかもしれませんが)Firebaseすげー!
時間があるときにきちんとまとめようと思います。

表参道.rb #14 ビアガーデン風編さっくりまとめ&感想

表参道.rb #14の参加も2回目です。今回はビアガーデン風編ということでSansan社によりタダでビールや美味しいお料理が振舞われました。

f:id:norihiko-saito-1219:20160807094713j:plain

お酒に絶望的に弱いため一部発表の記憶が飛んでしまったため、かろうじて記憶に残っているLTのさっくりまとめ&感想です。

omotesandorb.connpass.com

安心してフレームワークをのりかえたい

Fuel PHPを利用していたWebサイトをRuby on Railsにのりかえる話

  1. Kageというシャドウプロキシサーバのgemを利用して本番のトラフィックを複製し開発用サーバに流してテストした
  2. Kageでは本番のトラフィックの複製の他に複製するトラフィックのメソッドの限定(GETのみ流すとか)や本番/テストサーバのレスポンスの比較などができるとのこと

github.com

タイトル不明(Rails5のAction Cableをためしてみた話)

  1. 普通のソケット通信をテニスに、Action Cableを銃撃戦にたとえていたのがわかりやすかった
  2. 発表者は新卒入社3年目だった、若いなぁ!

おれおれPHPフレームワークRuby on Railsにのりかえる話

  1. 開発者なら誰でも通る道、おれおれフレームワーク
  2. 自分が使っていたおれおれフレームワークにはおれおれテンプレートエンジンやおれおれDBアダプタから構成されていました(涙)
  3. 「おれが今この瞬間飛び降りたら誰も仕様がわからないSPOF状態」というセリフには笑った

DigDag@表参道.rb #14

DigDagとはバッチ処理など処理の実行順序やエラー制御などをやってくれるワークフローエンジンのgem(Treasure Data製)

github.com

  1. Treasure Data製だからといってBigQueryやビックデータ処理に限らず広く利用可能とのこと
  2. Treasure Dataは汎用的なソフトウェア開発現場の課題をすくい取ってOSS化するのが本当にうまい印象
  3. Ruby APIもある
  4. バッチ処理では出世しない」という格言を聞いた

全体的に

  1. imgcatというコマンドを初めて知った(初めて知ったことが多い)
  2. php => Rails乗り換え発表率が高かった(流行?)
  3. 新卒入社3年目の方発表率も高かった。ワタシ、オッサン、マケテル、ガンバラネバ

懇親会

「いやー太っ腹ですねSansanさん!」

_人人人人人人人人_
> さんさんさん! <
さわやか三組! <
 ̄YYYYYYYYYYYY ̄

今回結果的にタダ飯してしまったため、次回はLT参加を考えたいと思います…

Web Music ハッカソン #5参戦記【前篇】

7/29(土)、会社の@massie_gさんと先輩のUさんの3人でWeb Music ハッカソン#5に参加してきました。
人生初ハッカソン、でいろいろと勉強になることも多かったのでその感想とまとめたいと思います。まずは前篇の準備編です。

Web Music ハッカソンとは?

Web Audio APIやWeb Midi APIを使ってアプリをつくるハッカソン

http://googledevjp.blogspot.jp/2016/06/web-music-5.html

作戦会議

まずは3人で当日何を作るか作戦会議をしました(→お昼に集まって会社のフリースペース的な所で開催)。
結局当日形になったものもほぼほぼ作戦会議通りのものでした。

f:id:norihiko-saito-1219:20160802221423j:plain

機能

  • ひとことでいえば
    • スマホのコントローラからWebSocket経由で音声(Web Audio API)/動画(openFrameworks)が一元管理できるアプリ。
  • コントロール対象はBPM、ピッチ、エフェクトなど
    • → エフェクトはメッセージだけ定義しておいてどんなエフェクトをかけるかは音声/動画を実装する人が決めてね、的なスタイル。
  • 一部機能はスマフォのセンサー(加速度センサー)からもコントロール可能
    • → 詳しくは後編で触れますが、これらの機能はハッカソン観点からは全然新しくなかった(最大の敗因)。
  • 疎結合アーキテクチャ
    • → 機能拡張しやすい/チームメンバーがそれぞれ勝手に開発できる、という点で良かったと思います。

事前MeetUp

f:id:norihiko-saito-1219:20160802221435j:plain

7/26(火)、先輩と2人でハッカソン事前Meetup@いいオフィス(上野)に参加しました。
雨、上野、原宿では滅多にお目にかかれない呼び込みのお姉さん、とその谷間。
まぶしい世界、上野駅前の「じゅらく」も健在でした。
会社の本社が上野にあるため、「上野なんて庭ですよはははは」と先輩に豪語し反対方向に誘導してしまいました。結果15分はロスしましたよごめんなさい。

Meetupでは参加者のLTに加え当日のチームビルディングがあったのが印象的でした。
他のハッカソンをあまり知らないのですが、この事前Meetup(チームビルディング)→ハッカソンという流れはとても良いと感じました。 作りたいものを作る、そしてクオリティが高いものを作るためにこのように事前で似たアイディアの人とチームを組むのは効果的と思えるからです。

LT、チームビルディング中の意見交換で印象に残った意見を残します。

  • 著作権の関係でDJイベントはソフト化されづらい、という課題のために曲ではなくDJの「プレイ」のみをコードとして取り出しGitHub管理する。というアイディア
    • → DJだけではなくそのビジネスや環境全体を意識した上で課題を抽出し解決するにはどうすればよいか、という観点が斬新に思えました。
  • DJ機器なら作らなくてもいっぱいある。Web Audio APIでそれを作っても仕方がない、むしろ、「Web Audio API」もっといえば「Web」でしかできないアイディアを考えるべき
    • → この時点で上の作戦会議で考えたような「漠然とした」アイディアしかなかったため「ドキッ」としたのを覚えています。
  • スマホのセンサー(加速度や傾きやGPS)は精度が悪く、正確な演奏に反映するのはむずかしい。まぁ、おかずくらいには使えるかも
    • → いろいろなアプリを見てきたg200kgさんの意見なので説得力がありました。ただ、逆に不正確さやレイテンシーを逆手にとってアプリの面白さとして活かせないか、なんてことも考えたり。
  • フレーズに対してフレーズを自動生成して返してくれる機能が欲しい。技術的に難しければ、こちらが入力した別のテンションが足されるとか
    • → これは楽器演奏者の意見でしたが、自分も演奏者としてとても惹かれるアイディアでした。もし次回があればこの軸で考えたいところ。
  • お客さんが操作できるアプリがよいかも。DJのトラックに対してエフェクトやもっといえば妨害が掛けられるアプリが面白そう
    • → やはり、Webということで専用機器を持たないお客さんが利用するアプリのアイディアは多そうです。「妨害」という発想も面白い。

そして当日へ

事前Meetupでの話からかなりの不安を抱えながらも軌道修正する余裕もなく、結果そのままハッカソン当日を迎えてしまいました…
結果はどうだったでしょうか。
当日の模様と「総括」は後編に続けます。

ハッカソンを通して見えてきた良いアプリの条件とは? Web Music ハッカソン #5参戦記【後編】

当日の様子はこのYouTubeを見ていただけるとわかりやすいと思います、特にラストの優勝作品は圧巻っす。

www.youtube.com

f:id:norihiko-saito-1219:20160802222829j:plain f:id:norihiko-saito-1219:20160802222837j:plain ※当日はGoogle@六本木ヒルズ開催でした。

結果

「惨敗」

でした。

5位以内(全17チーム)に入れず、ローランド&Googleからの特別賞も入れず。ただしこれはハッカソン参加直後から予測できたことです。
なぜならハッカソン直前に発表された採点基準が、

  1. Web性
  2. 新規性
  3. 実用性

というもので、我々のアプリは「Web性」は多少あっても「新規性」や「実用性」はほとんどなかったから…

ハッカソンを通して見えてきた良いアプリ

前後編通して一番書きたかったパートです。
全作品を見ているとWeb Musicだけではなく様々なハッカソンに通じる「良い」アプリとはなにかがなんとなく見えてきたからです。
1. アイディア、2. デザイン、3. プレゼンの視点から列挙してみます。

1. アイディア

イノベーション > 問題解決 > 漠然としたアイディア

アイディアはなんらかの「問題解決」になっていると伝わりやすいです(今回でいえばDJが抱えている問題の解決)。ただ、さらに「おーっ! 」となるのは「技術によるイノベーション」を成し遂げたアプリ。優勝作品はお客さんのPCやスマフォがそのままDJがコントロールできる音源になるというアイディアで、まったく新しいDJプレイの定義であり、まさにイノベーションというべきものでした。

2. デザイン

デザインレス > かっこいいデザイン > エンジニアとしてできる限り頑張ってみました、デザイン

デザイナーがいない場合、エンジニアだけで「見栄えが良い」アプリをどう作るか、これもハッカソンの大課題の一つかと思います。
まず大事なことは機能数を絞ること(できれば単機能)です。多機能になるといろいろなボタンやフォームのデザインに加えそれらのレイアウトまで考えなければならずますますデザインの負担が増えてしまうからです。実際当日は単機能で原色を活かした派手なアプリが注目を集めていました。
さらにビジュアル以外のUIとして技術を駆使するのも一手です。当日は加速度センサーやマイクで拾った音声、カメラの画像をインプットにしているアプリも多かったのですが、こちらも技術を駆使したUIの面白さのほかに、デザインの負担を減らす狙いもあったのかなと推測(邪推?)。

f:id:norihiko-saito-1219:20160803121324p:plain ※上記の例として入賞をかっさらったmohayonaoさんのアプリの構成図です。
機能を絞ったシンプルなUI(透明なUI)がかっこいい!

3. プレゼン

アプリのデモ自体がプレゼン > 素敵なプレゼン資料 > 行き当たりばったり

今回短い時間の中、素敵なプレゼン資料(Keynoteなど)を作成していたチームが多くて驚きました。
ただし、聴いている側からすると一番すとんと落ちるのは「アプリのデモがプレゼン」になっているプレゼンでした。
つまり、それらのアプリはプレゼン資料がいらないように「見せ方」や「インパクト」をも十分考慮して作られているはず(すげー)。

さいごに

なにはともあれすごく楽しい時間でした!
みなさん素敵でしたし、あとWeb Music界のラスボスたちを生で見、お話しすることができて参加してとても良かったと思います。
打上げさいこー!
Web Music ハッカソンさいこー!
蟹、貝、海老、北京鴨、たらふく頂きました!

f:id:norihiko-saito-1219:20160802222918j:plain

I will win next time. Next is my turn to beat you...