JavaScriptこんにちは!冬が苦手なディレクターの神吉です。2019の20日目の記事です。v2がリリースされていました。Frameworkのことで、LINEが提供するウェブアプリのプラットフォームです。JavaScriptを書いて開発する感じです。v2になって主に下記ができるようになりました。外部ブラウザでLIFFアプリが動作する。v1はLINE内ブラウザでのみ動作していました。ユーザーのプロフィール情報とメールアドレスを取得できる。LINEログインでできる仕組みに近い仕組みなのかなと思います。QRコードを読み取れる。新機能ですね!LIFFアプリの動作環境を細かく取得できる。外部ブラウザで動作するようになって細かい情報を取得する必要がでてきたのかと思います。v1もちゃんと触っていなかったのですがこの機会にv2を触ってみたいと思います。LIFFでQRコードを読み取りをやってみます。APIチャネルではないほうが良いです。URL対応サーバこちらを事前に準備してください。「LIFFアプリを追加」より必要事項を入力してLIFFアプリの追加をしてください。QRの設定はONにしてください。LIFFサーバーAPIでもLIFFアプリを追加することができます。URLが発行され、LIFFを開くことができるようになります。LIFFアプリの開発ここからは実際の開発手順です。読み込み後に追加してください。}});liff.scanCode()はLINEのQRコードリーダーを起動し、読み取った文字列を取得するメソッドです。QRコードをスキャンすると#qr_textにQRコードで読み取ったテキストが挿入されます。注意点iOS版LINEバージョン9.19.0以降では、liff.scanCode()の提供を一時停止しています。(2019/12/18時点)liff.scanCode()は、外部ブラウザでは利用できません。活用する?手軽にQRコードリーダーを使えるのは良いです。QRの読み取りも速いです。LIFFはLINEのuserIdと紐づけてイベントログを取得でき、データ活用できます。いったところ活かしオンラインとオフラインをつなぐような施策使えればと思います。(今のところBUYMAでの具体的な活用案が浮かばずすみません。)感想かなり簡単に試すことができました!LIFFを使用する上で実行環境による挙動の違いはしっかり把握しないといけないなと感じました。今後もLINEの開発者情報はこまめにチェックして、新機能は早めに試してみたいと思います。2019インフラチームの山口です。ゼロ年代後半ゆるふわ情報系学生でしたが紆余曲折の末にインフラエンジニア1年目となりました。今回は編集距離を使用してSQLのクエリをクラスタリングしてみたので記事にまとめてみます。伊藤直也さんのブログで編集距離の記事が公開されたのが2009年だったのですが、時の流れの速さを感じてしまいます。1.背景DBのCPU負荷のスパイク時に、DBのクエリのログを取得・人手で集計して、CPU負荷が高いクエリを改善するという運用を実施することがあります。ログ(クエリ)の量が少ない場合は良いのですが、大きくなるにつれ、人手での集計に伴い以下のような問題が発生しています。異なっているだけといったクエリをうまく拾えないことが予想されます。Distance)を使用して、スクリプトでの結果の集計を試みます。「編集距離を使用してクエリ同士の距離を測ればなんかうまくいきそうな気がする」というワンアイディアで調べもせずスクリプトの作成をしてしまったのですが既存の参考文献を調べてみます。検索してみるといくつか事例が見つかります。詳しい書誌情報は割愛でタイトルとざっと読んでどんな事やっているかだけ記載します。クエリのクラスタリングというタスクの論文は書かれているようです。論文書かれているということは、おそらく他のエンジニアも同じ問題にあたった人もいるはず。(手でクエリのログ分類して大変な思いしてるのは私だけではなさそう......。2018.先行研究で提案された特徴量がまとめられている。著者らの提案手法については、理解する時間がなかったが、クエリのクラスタリングのタスク自体の概要を知るには良さそう。文献で引用されていたもの。クエリのTF-IDFを特徴量にしてSOMでクラスタリング、可視化をしている。編集距離とは(Wikipedia参照)編集距離については既存で参考になる記事が複数存在するため、本記事では特に説明せず、Wikipediaからガッツリ引用します。端的には2つの文字列の間の距離の尺度です。distance)は、二つの文字列がどの程度異なっているかを示す距離の一種である。distance)とも呼ばれる。distance)は2つの文字列がどの程度異なっているかを示す距離の一種。変更する場合は、最低でも3回の手順が必要とされるので2単語間の編集距離は3となる。以下の要件を満たす、なんちゃってクラスタリングを実行するスクリプトを作成しました。クラスタリング結果が一意に決まらない方法は避けたい手元のマシンですぐに結果がみたい(時間がかかる方法は避けたい)今回の方法を説明します。クラスタの代表と以下で記載していますが、実際はレコード中で一番はじめに出てきたものをそのクラスタの代表にしているだけで、特に重心などをとっているわけではないです。今回は、クエリの先頭からN単語分を抜き出して使用します。これは、「人間が比較する際もクエリの先頭から末尾まで見ておらず、先頭N文字で判断しているだろうという仮定」と、「試しにクエリ全体で計算してみると思いの外時間がかかった」ためです。閾値以下の距離のクラスタがない場合は新しいクラスタを作成するまた、編集距離を取得する際に、一旦クエリをスペースで分割して、単語単位での編集距離を取得します。日本語だと形態素解析が必要ですが、雑に半角スペースで単語に分割します。データセットにはアノテーションされたラベルが付与されています。sci.'クラスタリングの結果と所感クラスタリング結果を以下に示します。PurityとF値を使用します。F値は0から1の間で1に近づくほど良い値です。purityが0.75とやや大きいですが、これはクラスタのメンバー数1のクラスタが多数あるためです。参照にした資料でも説明がありますが、1クラスタ1レコードにクラスタリングされた場合purityは1になります。今回の結果では、218クラスタ中でクラスタのメンバー数が1のクラスタは156個ありました。結果を定性的に確認してうまくできていそうな箇所を無理やり見つけます。クラスタ108の結果を見ると意図したとおりにクラスタリングできているように見えます。)を同じクラスタにまとめられています。完全文字列一致でやっても、事前に空白除去しておけば拾える箇所なので、編集距離を使った良さとは強く言えなそうです。今回使用したデータセットはとりあえず、クエリにアノテーションされているものを見つけたので、きちんとした理由もなく使っているのですが、そもそも私がクラスタリングしたい目的とデータセット作成時の目的があっているのかなども確認する必要がありそうです。クエリのクラスタリングがうまくできると、嬉しいものの、社内でアノテーションするメンバーを複数人集めて、ラベル付きデータ作って評価するほどのものでも無いような気もするしなという気持ちもあります。まとめ編集距離を使用しクエリのクラスタリングを試みました。クラスタリング方法や、パラメータ、テストに使用したデータセットなど、全体的にエイヤな部分が多いですが、定性的に結果をみると類似したクエリをなんとなくまとめることができたようにも思います。実業務でクエリのログのクラスタリングに使えるかはかなり怪しいのと、DatadogなどのSaaSでもログのクラスタリングはできるようなので、ローカルであえてスクリプト準備してクラスタリングする機会はないのかなとも感じます。散漫な記事となってしまったので無理やりまとめますが、新しい仕組みがどんどん出てくるなかで、昔からのやり方と新しいやり方適材適所でうまく扱えるようになっていきたいなと思います。あと、もっと楽に精度良くやれる方法を教えてくれる人がいれば教えてほしいです(かなり切実)。RSpecサービスエンジニアリング本部の山本です。的なことにも手を出しています。