よくGoogleAnalytics等のダッシュボード表示系コンテンツをディスプレイとかで表示することがあると思うんですが、そういうときに役立つプラグインをご紹介
このツール自体は「GoogleChromeで複数タブを開いているときに一定秒数でタブを切り替えていく」 というものなのですがそこに「タブが変わる度にリロードをする」という機能がついているので「1タブだけ開いていれば指定ページを定期的にリロードする」ということを実現できる
クリックすると有効化して、一定期間でリロードが走るようになる。
緑色の状態がリロード有効状態
赤色だとされない
時間の間隔などはオプションから設定できる
ここをチェック入れてセーブすれば、タブ読み込みごとにリロードする
一体どういう意図でつくったのかわからないが見つけたのでメモがてら。打ち消しの記述なんて危険しか孕んでないから、おそらくコレは見かけたら駆除したほうがいい系のメソッドだとは思っている。
rails (5.2.0)
例えば普通にorderすると以下のようにクエリが吐き出される
User.order(:id) # User Load (0.6ms) SELECT `users`.* FROM `users` ORDER BY `users`.`id` ASC
複数指定すると以下のように重ねてORDER BYをかける
User.order(:id).order(:updated_at) # User Load (5.2ms) SELECT `users`.* FROM `users` ORDER BY `users`.`id` ASC, `users`.`updated_at` ASC
ここをreorderに返ると以下のようになり打ち消される
User.order(:id).reorder(:updated_at) # User Load (2.7ms) SELECT `users`.* FROM `users` ORDER BY `users`.`updated_at` ASC
reorderは重ねて使っても最後しか採用されない
User.order(:id).reorder(:updated_at).reorder(:created_at) # User Load (0.7ms) SELECT `users`.* FROM `users` ORDER BY `users`.`created_at` ASC
画像変換系SaaSを使うか否か、を考えたときのただの雑記です。
『ユーザーが任意でアップロードした画像を保存したい』
という要件があるとする。
=> をハッシュロケットと呼ばれることを知り調べてみた系トリビア。
ここで紹介する記号達の名称はオフィシャル系では見かけたことがないのであくまでもネットを漂う情報のひとつ。
JuanitoFatas/what-do-you-call-this-in-ruby: Solving the second hard problem in Computer Science.
日本語圏ではハッシュロケットやロケットハッシュと呼ばれる事が多い、JavaScriptの文脈を受け継いでかファットアローと呼ばれることもある様子
ダッシュロケットと呼ばれることが多そう、ラムダリテラルなんて呼び方もあった。
宇宙船演算子、スペースシップ演算子、UFO演算子と呼ばれる。まぁ確かに見える。
Gemのバージョン比較の文脈から「pessimistic (comparison) operator (悲観的バージョン演算子)」と呼ばれる事が多い様子
PV、Session、UU。どれもサイトに訪れた数を表す指標であり、大概のツールは実装されている。しかしながらいざ自分で作ると考えたときにどういう違いがあるのかがあまりまとまってないのでまとめてみた系雑記です。
どれも期間に対してどれくらいの数があったかの指標となっており、「一週間のUU数」というような使われ方をする。
そもそもの基本概念は下記サイトにわかりやすくまとまっている
UU、PV、セッションの違いを解説！ | Growth Hack Journal
こちらのサイトの表現になぞらえて書くと
というような形になる。
PVは閲覧されたページ数なので、単純なサイトの場合は「ページを表示した数」で表現することができる。
ページを表示した数を指標を取る方法はいろいろある。参考例としては以下のようなやり方がある。
自明な話ではあるが、GoogleAnalyticsなどはJavaScriptを使う形でPVを計測している。
SPA（Single Page Application)の場合は従来のページアクセスと異なり、JS内でページが遷移してしまうので、上記であげたAやBのやり方だとユーザがページを切り替えているにもかかわらず1PVとなってしまう。
その場合、Cの手法を使い、SPAとしてページが移動した場合は異なるPVとしてカウントするという考えのもと計測する必要がある。
こちらに関しては扱うWebサイトによって考え方が変わるのでサービス関係者で定義をしっかりと行う必要がある。
スマホでのリスト表示のコンテンツの場合、追加で読み込むことがままある（Infinit Scrollと呼称している事が多い）
これもSPAと同様に同一のページではあるが、従来のページネーションが存在するページで考えた場合、2ページ目、3ページ目動くものではあるので、その分をPVとしてカウントするほうがページネーションがあるサイトと比べたときに自然になるケースがある。
これもサービスの性質やポリシーによって分かれる部分なので、これらもしっかりと定義を行う必要がある。
ユーザが一定時間そのサービスに連続して触れていた時間をセッションと考える。引用となるが以下の1文が説明としてシンプル
アクセス解析において、セッションとはWebサイトにアクセスして行う一連の行動を示す。「訪問」「ビジット」と同義。 - セッション とは 意味/解説/説明 【session】 | Web担当者Forum
PVよりもより大きな塊で考えるのでこの考え方になる。
では「一連の行動」をどうやって定義するかが結構考えたによってはまちまちになる。一番有名なのはGoogleAnalyticsの例で同一サービス内のページから30分以上の経過、もしくは日をまたぐ、もしくはキャンペーンという異なるコンテキストに行ったときにセッションが途切れる
概ねWebサイトだとこの考え方を主軸にしていることが多く、同一のドメインで回遊し続けている間は何をしても1セッションとするが、サイト閲覧を離れて30分後にまた回遊を開始したら別のセッションとなる。
ステートフルなページを実現する際に昔から用いられているのはCookieである。そのため、同一の人が同じページを回遊しているというチェックもCookieでやるのが技術的には一般的だと思われる。
近年だとLocalStorageやログインのやり方などもあるのでいろいろなアプローチの方法があるが、どのブラウザでもあるのはCookieなので、Cookieを使い、同一Cookieを持つ人がどういう時間の流れで動いているかで計測するのが一般的かと思われる
Session数は1セッションをどう考えるかによって大きく数値に乖離がでる。たとえば1時間回遊ごとに1セッションなどの概念を持ち出したらカウント数がかなり変わる。
デファクトスタンダードとしてGoogleAnalyticsの考え方があるのでそこに則る形が多いが、独自でやる場合はその点を明確に示さないと、多くの人に示す数値としては比較しづらく、使いづらいのではないかと思う。
UUは文字通りに設定された期間内に訪れたユニークユーザの数なので、ユニークな数をカウントすればいいのだが、何を持ってユニークとするかがサイトの作りによって異なる。
一番単純なのはログインを必ず求められるサイトなどが簡単で、ユーザごとに一意となるユニークなキー（IDやメールアドレスなど）を持っているのでログインを行ったユーザのID数をカウントすればそれがUUとして考えることができる。
そのため、RDBにログインした時間を記録したり、ログイン処理をしたIDとログイン時間を記録しておけば、週間や月間のUU数を出すことができる。
ログイン機構を持たない場合はどう考えるか、ここでもCookieを使う。
新しくページを訪問した人に重複しないユニークなCookie文字列を与えて、アクセスログとしてその文字列をロギングすれば、ある程度のユニークなアクセス数は検証することができる。
ユーザーIDなどがわかれば、その期間に動いたIDの数をカウントすればいいし、実際の人間の数と剥離なく言葉通り、UniqueなUserとしてカウントすることができる（複数アカウント持てるサービスだと別ですが…）
ただしCookieのカウントの場合、ちょっと話がかわる。
一昔前はWindowsでIEしかない、かつCookieを気軽に消すことがない時代だったので、1ブラウザ=1人という考え方もできたが、最近はブラウザも複数、一人の人がスマホとパソコンという時代になってきたので、それも言いづらくなってきたので、この手法を取る場合はUUではなくUB（UniqueBrowser）という考えかたをする場合もある。
Rejectcon 2018（builderscon tokyo 2018 番外編)］に行ってきたのでメモ
※資料スライドは見つけたら貼ります。
資料公開しました!!! https://t.co/v7tXL449nL #rejectcon2018
— パピックスポィントライト (@__papix__) September 29, 2018
これからRejectconで話す資料です！タイトル長すぎて、「デザインシステムを支える技術」とかにすればよかった。。https://t.co/LzDv9Cfy4v#rejectcon2018
— KentoMoriwaki (@kento_trans_lu) September 29, 2018
スライドリンクは見つけたら貼ります。
エンジニア向けイベントで、コード1行はおろか、サーバーどうしてるとかも一切言わないトークをしてまいりました pic.twitter.com/JfSHyYIoHz
— ながの (@7gano) September 29, 2018
※多分スライドリンクなし
スライドリンクは公開されたら貼ります
先程の発表の資料です！「フロントエンドエンジニアが考えることはたくさんある」https://t.co/LkHiJ1tDmF #rejectcon2018
— るきるき (@rukiadia) September 29, 2018
多分スライド公開されない
Rejectconでの発表資料アップしました！ https://t.co/jirSfWhmgu #rejectcon2018
— Takamichi Yoshikawa (@adorechic) September 29, 2018
今日のRejectconの発表資料です！ #rejectcon2018https://t.co/Mhcaxj3Zme
— south37/Nao Minami (@south37777) September 29, 2018
あるエンジニアが「Kibela」というサービスを考え、リリースするまでのフローを全部教える では語られなかった裏話
話す前にあげてたのにURLを貼るのをすっかり忘れてた、本日のスライド https://t.co/F8tfCkE6bW #rejectcon2018
— Daisuke Maki (anovaさん） (@lestrrat) September 29, 2018
普段遣いしているとわかるけど、そうではないとわからない系のメモ
リンクを押すとGooglePlayに遷移する！みたいな奴
https://play.google.com/store/apps/details?id={{アプリのパッケージ名}}
で指定できる、ダンジョンメーカーの場合は com.GameCoaster.DungeonMaker がパッケージ名なので以下のようになる。
https://play.google.com/store/apps/details?id=com.GameCoaster.DungeonMaker
このURIの場合はブラウザで閲覧できる半面、Intentの性質上ストアアプリを開くか通常のブラウザを開くかを聞かれてしまうことがある
完全にPlayのアプリを開いて欲しい場合はこちらを指定すると良い
market://details?id={{パッケージ名}}
またダンジョンメーカーを例に出すと以下。
market://details?id=com.GameCoaster.DungeonMaker
こちらにすると、Playストアのアプリで開くURIになるので、ブラウザの選択を確認されることがない。ただし、iOSなどAndroid以外のものでこのリンクが作られてしまうと遷移されないので注意。
広く多くの人が見る画面のリンクであれは https:// はじまりのもの、Android専用ページのリンクであれば market:// のものがよいかと思います。
