なんも分からないのでしらべた

なんもわからん!…ので、できる範囲で調べる。

Vue.js(vue-cli)にて外部jsライブラリを読み込みたかった…(雑記)

Vue.jsにて非exportsの外部jsライブラリ(functionべた書き)を読み込んで、vue.jsのcomponentsにて利用したかったのだが、検索しても良く分からず。

exports化された外部jsライブラリ(module)ならimport文でいけそう。
しかし、読み込むjsライブラリがベタfunctionの場合どうやってvue側で呼び出せばよいか分からず、かなり悩んだ。

苦心の結果何となく動いたのでメモする。
あまり良くない方法だと思うのであとでTeratailで質問を出す。

詳細

外部ライブラリをindex.htmlで読み込む

  • index.html
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <!-- 読み込む -->
    <script src="static/lib/myaction.js" defer></script>
    <title>help2</title>
  </head>
  <body>
    <div id="app"></div>
    <!-- built files will be auto injected -->
  </body>
</html>
  • myaction.js
//ベタfunction 
function myFunc(){
  alert("test test myaction");
}

vueファイルにてwindowオブジェクト経由で呼び出し

  • App.vue
<template>
  <div id="app">
    <b-button @click="myactionFunc()">myaction</b-button>
  </div>
</template>

<script>
export default {
  name: 'app',
  components: {
  },
  methods: {
    myactionFunc: function () {
      // scriptエリアならwindowオブジェクトが取れる
      window.myFunc()
    }
  }
}
</script>

動作

f:id:kbn1053:20180421001959p:plain

🎉動作OK🎉

Chrome extensionのoptionページをVue.js(vue-cli)で構築する際のメモ

何度も忘れるのでメモ。
chrome側のポリシー設定とvue-clieのビルドコンフィグをいじる。

詳細

manifest.json

chrome extensionのmanifest.jsonにてcontent_security_policyにてevalを許可する

f:id:kbn1053:20180420123912p:plain

vue-cli構成のconfig/index.js

buildするとdist/index.htmlとdist/staticのpathが合わなくなる。buildconfigで相対参照に変更する。
具体的にはassetsPublicPathをコメントアウトする。
(4/21: 追記) コメントアウトだとwebpackの動作がおかしくなるのでブランクを設定する。

assetsPublicPath : '',

f:id:kbn1053:20180421051941p:plain

参考
  • Vue.js入門記事

qiita.com

デバッグ実行

npm run buildしてdist以下のファイルをchrome用のプロジェクトフォルダに入れる。
manifest.jsonのoptions参照先にindex.htmlを指定する。

f:id:kbn1053:20180420125144p:plain


f:id:kbn1053:20180420125315p:plain

🎉動作確認完了🎉

その他

時間無いので雑なメモ。
時間できたら参考ソースをGitHubに上げてノウハウをQiitaに書く。

SmartHacks スマートスピーカーオフ会#3行ってきた(雑記)

SmartHacks山本さん主催のスマートスピーカーオフ会行ってきた。
f:id:kbn1053:20180418010020j:plain

しかし、参加者が山本さんと自分だけというガチ会になってしまった…。

詳細

山本さん(以下、敬称略)
自分

  • 山本:須磨スマボスの中の人技術者でわりとすごい人ですよ。経歴もすごい。
    • 自分:若干怪しめの職業youtuberの人かと思ってましたw
    • 山本:唯のyoutuberではないw ご本人も人あたりの良い方ですよ~😊
  • 山本:スマートスピーカーのLED表示方式はechoが優れてると思います。GoogleHomeは後ろ向きに置いた場合、LED表示見えなくなっちゃうんですが、echoだとそんなことない。高い所に置いても見えます。
    • 自分:確かに。まぁ据え置きしちゃうとLED表示ほとんど気にしませんが…
    • 山本:それはそうですwあとは話者方向をLEDの光で示してるって小ネタもあります。
  • 自分:スマートスピーカーの基本言語は英語だけど、そこから日本語に対応にさせるのって固有問題も多いしコストが高いですよね。いつかスマートスピーカーの日本市場が見捨てられないか怖いっす。
    • 山本:各社の感触ですが、片手間でやるレベルではない力の入れ具合を感じます。真の意味でのIoT、音声入力機器が遍在するようになるまで継続してやってくれると思いますよ。
    • 自分:日本技術ベースのスマートスピーカーが出ないのは残念ですね…。海外に丸投げしてて大丈夫かよという感じも。
    • 山本:一応Lineさんは日本で音声入力やってると言えるのではないでしょうか?
  • 自分:音声入力技術で先行してるメーカー(cortana,shiri)あったのに、amazonが米国で優勢になったのはどうしてなんでしょう?
    • 山本:機能の切り取り方が良かったのでは?何でもできる機械(スマフォ)に新機能(音声入力)が追加されても全然感動が無いです。そこを音声入力機能を専用ハードとして取り出したことが革命だったのではないでしょうか。ユーザーに"音声入力便利ですよ"と改めて意識させるという。
    • 自分:なるほど。 実際、既存の音声入力機能って過去からの蓄積で全然役立たずのイメージがあって、一切使う気になれなかったですね。そこをうまく脱却したと。
    • 山本:そうですね。そして、スマートスピーカーで音声入力が見直された後に、「それandroidでも使えますよ」と音声入力に慣れたユーザーを逆輸入するルートがあるのはGoogleさんの強みです。
  • 山本:echo spot良いっすよー。音声操作のフィードバックで映像と文字表示させると便利。米国で一番売れてるらしいです。
    • 自分:音声のみでアプリ作るのと段違いの情報量出せますね。 多数のサジェスト出したとしても苦痛にならない。音声のみだと3個が限界。というか2個の判断がすでに苦痛です。
    • 山本:spot用のスキル作成も、音声のみとほぼ変わらないようです。デバイスに画面がある場合のみ文字表示するなどのオプション処理書けばOKのようです。
  • 自分:最近のアプリ/スキル数の増加どうです?もう廃れてない?
    • 山本:そんなことないです。バリバリ増えてるけど、GoogleHomeのアプリ増加量はちょっと落ちたかも…?Alexaはものすごい増えてる。
  • 自分:その差はなぜでしょう?
    • 山本:ハンズオン等の説明レベルが違うのかもしれません。とりあえず丁寧なチュートリアル資料があり、見よう見まねでアプリ申請出せるところまでガイドするのがdeveloperを増やすのに大事と感じます。
    • 自分:Dialogflowのコンソールも、初めて見ると「ヤベェ」ってなりますね…。これに限らず、なんでも新しい技術初めて入門するとき、滅茶苦茶壁があるじゃないですか。超えるのにやる気がものすごい必要。でもチュートリアルを実際に始めると思ったより大したことないという…いざ始める時の気合部分がすごい壁。
    • 山本:分かり味あります。とにかく用語とか分からずとも入門通りやって、動くものができるのが大事ではないでしょうか。
  • 山本:個人所有でスマートスピーカー一番持ってるのは筋トレ君(?正確なアプリ名失念)の人ですね。8個持ってるそうです。
    • 自分:持ちすぎる!そんなにいる?
    • 山本:スマートスピーカーラブゆえに、だそうですwプログラミングもアプリ開発でほとんど初めてやったとのこと。良い話ですよね🤗
  • 自分:clovaは他社に比べてちょっと劣勢では?
    • 山本:Lineと連携できるという強力な強みあるのでそんなことないですよ。IFTTTでの発話も唯一対応してるのも。今のところ各社それぞれ強みがあるので、業界的には面白い状態です。切磋琢磨されて良いと思います。
  • 自分:米国の20%(4000万人)所持に比べて、日本の普及具合はまだまだこれからという感じだけど、ブレイクするタイミングいつだろうか?
    • 山本:iphoneの爆発的普及した過去を考えると、何らかのキラーコンテンツ(アプリ)の登場で一気に普及するというルートがあり得ると思います。
    • 自分:自分はちょまどさんが言ってた「スマートスピーカーは老人と子供にこそ必要」説を押したいです。老人への必要性を十分説明できれば、行政が(防災無線代わりに)実験的に各家に配布しだしたりするとか…
  • 自分:個人開発のアプリだと工数的に会話をリッチにできない、いわゆるchatbotレベル止まりであんま高度にできないんじゃないですかね?
    • 山本:そもそもスマフォで「文字ポチポチ入力しなくてよい」だけで音声入力にする意味がありますよ。画面見なくて良いし、いちいち漢字変換したりしなくていいってのはそれだけで素晴らしい進化です。
  • 自分:これからのスマートスピーカー利用イメージは?
    • 山本:大手企業では仮想と現実の融合、境目をなくすような目標持ってますね。スマートスピーカーでも、会社では音声入力して、電車内ではスマフォ操作して、家に帰るともう一度音声入力に戻るようなシームレスな体験ができます。
    • 山本:スマートスピーカーの入力機器・筐体がどうこうではなく、もはやどんな状況でも音声入力できるのが当たり前になる、という風になると考えています。

メモ取らなかったので大体の内容です。読みやすいように補完してます。
ヤバイ内容はヤバイのでカットしてます。ヤバ味が必要な人はOFF会へGO!

その他

2時間ぶっ続けでしゃべってたと思うんですが、短期記憶がやばいので書き起こしはこんなもんです。
良い話が非常に多いかったので次回、許可あれば録音したいですね😎
あとは全体的に聞いてばっかりになってしまい、山本さんには感謝しかない。

Build Actions for GDG Tokyoに行ってきた(雑記)

2018/4/16にBuild Actions for GDG Tokyoに行ってきたので内容をメモ。
f:id:kbn1053:20180417165013j:plain

GDCとGDG混同する…。
GDGとはGoogle Developers Groupの略らしい。

公式

gdg-tokyo.connpass.com

当日のスライドは基本的に公式にまとまっている。

各種リンク

tgetterまとめ
togetter.com

ハッシュタグ*1 #buildactions
twitter.com

まとめ

  • GoogleHome IoTの最大の特徴は、電気がついているか、鍵が開いているか等の機器の状態を取れること
    • developerはIFTTT構成を超えたものを作っていこう
  • 人と人とが会話するときには言葉に現れない隠れた前提条件が存在する。
    • VUIでは(多くの場合)前提がない状態から始まる。それを意識してVUIを組み立てる。相手をおもてなしする。
  • AWS でも(lambdaで?)ライブラリ読み込めば普通にapp.tellとかできるので楽っすよー(田中みそさん)
  • 開発者向けslackチャンネルがあるよ!


詳細

ノベルティ

トートバックとスポンサー企業のチラシ(アマゾンギフト券2000円クーポンコード)
f:id:kbn1053:20180418002859j:plain

Actions on Google概要・開発フロー byあんどうやすしさん

  • AoGのうれしみ:難しい自然言語処理やってるくれる
  • GoogleAssistantの強みは他社より対応デバイスが多いこと
  • 会話(VUI)が効果的なものを意識しよう
    • 一発何かやってよ
    • 簡単なアクション・処理
    • 手を使わないもの
    • 理想的には上記に縛られないようにな処理も便利に受付できるべきだが…
  • 逆に効果的でないアクションもある
    • あれやってこれやってそれやって。複雑すぎるもの
    • 命令する人も大変
  • ユーザーはVUI対象に勝手に人格を認める
    • 作り手はペルソナを用意して作ること。(口調、態度など)
  • 会話フロー組み立てはまずはうまくいくパターンから作ろう
    • ハッピーパスという
    • その後、ダメなパターンを復帰させる会話(会話の修復シナリオ)などを継ぎ足していく
メモ
  • Dialogflow利用しつつUGCやる構成作れる?
  • GoogleHome以外のデバイスに特化したアシスタントアプリどんなイメージ?

VUI Design概要 by 田中洋一郎さん

  • 人間対人間の会話が成立する前提
    • 人の話は内容を予想しながら聞く、つまり隠れた前提を持っている
    • 長年連れ添った夫婦のツーカー
  • 人間対機械
    • コンテキストの質を高くする
    • 人間の失敗を前提にする
    • よくばってあれこれ言わない
    • おもてなしの心
  • 書き文字vs話言葉
    • 話言葉はロジックではなくユーザーを信頼した組み立て方をするとよい。
      • 「ヒントと言うと、いつでも聞くことができます」より「ヒントを聞きたいですか?」
    • いつでも終われるようにしておく
    • 前提として会話は短く単刀直入にする。
  • アプリの第一印象はwelcomメッセージ
メモ
  • chatbotとの差別化ポイントどこだろう。会話ボリュームの設計・実装量を考えると個人開発では差別化できない?
  • 人間同士の隠れた前提を、ソフトウェアの実装に置き換えて考える。前提とはアプリ内に蓄積されたユーザーのパーソナルデータの蓄積具合ではないか。
    • 単純にはユーザーデータ取りまくって次回以降の会話にフィードバックする。「また今日も残業ですか…?」
  • アプリの調査方針の指針。welcomeメッセージの質をスコアリング。
  • おもてなし実装はコスト高い。安くおもてなししたいがアイデア?chatbotのノウハウあるかな?
  • おもてなし実装具合でアプリの質がばらける?GoogleHomeのメイン音声との切り分けはブランド的には正しい。

VUI設計後の実装からリリースまでのポイントby 田中洋一郎さん

  • spreadsheetいいよ~。背景色交互に色も付けられるよー。
    • UMLもいいよ~。
  • VUIの設計ツールは国内(日本語)対応したもの無い
    • 海外はあるけど日本語文字入れるとだめだった。
  • spreadsheetで台本作る->会話の変化ポイントを見つける->UMLに起こす->インテントを作る
    • インテントはユーザー目線で作る
    • UMLのフローによって実装時のfuifilmentが一意に決定される

LT (1) VUI with IoT by大橋啓介さん

  • HomeIoTアプリ作ろう
    • IFTTTとかでやってる人はにわか(意訳)*2
  • メリット
    • ウェイクワード後のアプリ名が不要になる
    • 部屋の指定ができる
    • バイスの状態が取れる。強力。
  • 前回のハンズオン資料見てね

docs.google.com


(以下もくもく会にて質疑)

  • 家のデバイス情報はHomeGraphで管理
    • HomeGraph自体は非公開データです(Google社山口さん)
  • バイスの基本操作はある程度限られている
    • テレビだと音量操作とかできるよ
    • 海外だとサーモスタット操作とかあるよ
メモ
  • 風呂大好き日本人的にはオート風呂したい。風呂ハードメーカーさん早く。

LT (2) SSMLで出来ること by 里山南人さん

  • audioタグで音声再生は楽しい
  • サウンドライブラリ結構いいよ
    • youtubeのサウンドライブラリも見てみて。ただstrageとかに置きなおす必要はあるけど…

LT (3) Dialogflowのオススメな使い方 by津田恭平さん

  • JSON見たらparseしたくなる病はやめよう
    • ライブラリのapi使えばできちんとデータ取れるからそれを使おう
  • dialogflowはzipダウンロードしてGit管理する

もくもくタイム

  • 割と時間押してて30分ぐらい

スポンサーセッション by株式会社grooves (Forkwell) 様

  • エンジニアのキャリアアップやってます
    • スパム送りまくるエージェント会社とは違うぜ
  • 会社との交渉力をつけるべき
    • それには個人のスキルセットが大事だ
  • 今キャンペーン中で登録するとアマゾンギフト券あげるのでよろしければどうぞ!

懇親会

  • ピザとコーラorアサヒビールorウーロン茶
  • twitterに生息している人が参加してて面白かった
    • 個人名刺にはtwitterアイコンつけたほうが認識されやすい…
  • 本名や姿は不明だが開発したアプリ名言うと「あーあのアプリの人!」ってなるのは開発に熱気がある界隈感あって良いなあ
  • いらすとやにお世話になってない開発者はいない
その他

当初connpassにて、160番で補欠だった。
規模が大きいイベントは大体当日までにキャンセル者多数出るので経験上参加可能になることが多い。
狙ったイベントは補欠でも諦めずに入れとくと良いかも。

あとは、発表内容が先月ののVUI meetingと結構かぶってた…*3

*1:海外のタグと共用?

*2:developerを煽っていくスタイル

*3:一カ月だとそりゃそうだよな…😓

GoogleHomeアプリ「東京都府中市のゴミカレンダー」をリリースしました。

GoogleHomeアプリ「東京都府中市のゴミカレンダー」をリリースしました。

www.youtube.com

公式リンク

assistant.google.com

経緯・工数など

東京都府中市でゴミカレンダーが一部不配だったようです。
www.asahi.com

記事は4/4の問題になっていますが、自分が知ったのが4/5の夕方のTVでした。
なんやかんややって4/6の19:30に完成してGoogle社に申請。
土日は承認システム休みで、今日の10:30に承認OKが出てました*1

ベースとなるソースはあったのですが、差分対応部分がDB構造へ影響出てしまって、トータルの作業時間およそ15.5h。思ったよりかかりました…。

その他(きっかけ)

丁度はてなで話題となっていた「国税庁のURL変換器」について、作られたハッカーのnote.読んだのですが、
以下の内容がカッコイーと思いました。

エンジニアの業界では,「ハック」という言葉があり,「ハッカー」と言うとなんかコンピュータを使って何かすげー事をする人みたいなイメージがあるんですが,
元は「雑だけどうまく役に立つものを作る」みたいな意味らしいです.

自分も今回作れる材料が丁度揃っていたので、いっちょ対応してみようかと思い立った感じです。


いいよね。ハッカー
憧れる。

*1:多分朝1で承認処理やってくれた風。感謝…

javascriptで優先度付きqueue(priority queue)のライブラリ(メモ)

npmでpriority queueを検索するとかなりの数のライブラリがある。
どれが良いとか悪いとかは、メンテナンス具合とdownload数等で判断するようだ。
しかし正直どれが良いか判断できない。
差し当たり早そうなfastpriorityqueueを利用することにした。

動作サンプル

サンプルコードがpriority key のみを使ったもので、素人には実践でどう使うのか分かりづらい。
別なサンプルを書いて動作をみる。

var FastPriorityQueue = require("fastpriorityqueue");

class MyClass {
  constructor(priority, data) {
    this.priority = priority;
    this.data = data;
  }
}

const a = new MyClass(10, "test");
const b = new MyClass(20, "test test");
const c = new MyClass(30, "test test test");
const d = new MyClass(40, "test test test test");

var x = new FastPriorityQueue(function (a, b) { return a.priority > b.priority }); // 昇順降順を切り替えられる
x.add(a);
x.add(b);
x.add(c);
x.add(d);

while (!x.isEmpty()) {
  console.log(x.poll());
// will print
// MyClass { priority: 40, data: 'test test test test' }
// MyClass { priority: 30, data: 'test test test' }
// MyClass { priority: 20, data: 'test test' }
// MyClass { priority: 10, data: 'test' }
}

その他

.min化されてないのでクライアントブラウザ動作させるなどの場合は最適化が必要かも。

javascriptの入門書のメモ

開発中のChrome Extensionのコードの規模が割と膨れ上がった。
ちょっとしたロジック変更するにも、手を入れるところが多すぎてタスク消化のvelocityが激落ちしている。
そのため、リファクタリングをやろうと思う。
しかし、javascriptはそもそもQiitaでつまみ食いしてばかりの半端知識だ。
いい機会なのでES6の説明に対応した入門書をざっくり読むことにした。

TwitterのTLにて読んでる人何人かいたので、気になってた本。
立ち読みして悪くなさそうだったので購入。

メモ

  • nullとundefined
    • 代入していないなどの未定義undefined
    • 検索した結果見つからなかった場合などnull
      • getElementByIdは検索系なので、見つからない場合null
  • 関数リテラルで定義した関数は巻き上げされない
    • 関数宣言で定義した関数は巻き上げられる。区別して使う。
  • 配列.lengthの値を書き換えるとindex以上の要素は削除される
  • クロージャを使った関数ファクトリ内の変数は、生成されたプロダクト関数が有効な限りGC対象にならない
    • p191
  • 関数にプロパティを持たせる。関数のメモ化で関数の処理結果をキャッシュするメモ化という応用。
    • 感動。シンプルに定義できるし、早い。
    • プロパティのキーを文字列にするとコスト高いので注意。
  • 高階関数。簡単なイディオムとしてmap,filter,reduceを利用する例。
    • 脳がついていかん。写経が必要そう。
  • アロー関数のメリット。thisの決定が関数定義時にされる。
  • Arrayもiteratorオブジェクト。
    • その他String TypedArray Map Set
  • 関数の戻り値を2個以上取る方法。分割代入を利用すると便利。
    • var [a,b] = (x => [x*2,x*3])(1); // a=2 , b=3
      • アロー演算子に慣れてないと全然読めない。
  • scriptの呼び出しタイミング。async/deferを指定。
    • bodyの最後で読みだすとか、onloadで読み出すとか余計なことしなくてよさそう。
  • 書籍と参考リンクありがたい