  |
一応チキン用のスパイスだけは買ってあるんだけど、仕事が夜遅くなるからそこからチキン買ってスパイスまぶして揚げるところまで考えられない
コンビニで売ってたらそれを買うと思う
※知らない人向けというより知ってる人が検索で見る用。
序盤から相手のタイプが完全にファイタータイプだったので、斎藤くんは前蹴りで突き放しながらストレート系を軸にして戦うべきだった。
ところが斎藤くんは相手の距離で、しかも相手の得意なフック系を中心にして戦ってしまう。そこで相手のロングフックが面白いように"刺さり"、斎藤くんのぶんまわしフックは体が流れて全くヒットしない。はっきり言って相手選手もうまくはないんだけど、フックの軌道が横からではなく80度くらいの角度で飛んでくる鋭いフックだった。肩甲骨も押し込まれていたので結果的に身長差のある斎藤くんに面白いように決まってゆく。
斎藤くんの失敗はまだ他にもあり、左ミドルで距離を稼ごうとしたこと。
言うまでもなく全くストッピング能力がない。左がきれいに蹴れて威力が出てるから相手が嫌がる、という感じでもない。また、近距離では（おそらく膝なしルールのはずなので）ローとガード、クリンチを組み合わせて戦うべきだった。途中海の指示で左に回っていたように見受けられるが、セコンドの指示を聞くのも遅い。以前から斎藤くんは直進とバックステップの出入りが単調すぎるきらいにあったので、あの指示は全く正しい指示だと思う。ただ、回り方はあまり良くなかった。天心を見たらわかるが、相手のパンチの大ぶりを狙って引っ掛けながら回っている。しかし斎藤くんは相手を見ずに回ろうとしていた。当然相手の視線は回り込んだ先を見て追いかけてくるし、スタミナ消耗は動いている分激しくなる。ボクシングで無駄に動くな、と言われる悪い動きをそのままやってしまった。
上手い人なら左右ぶんぶん丸はカウンターの餌食なのだろうけど、流石に斎藤くんにカウンターパンチャーになれというのは無理なので、いっても仕方ないというか。
ディフェンスがかなり悪いのも気になる。テクニカルなダッキングやヘッドスリップしろとは言わない。ただ顎が上がらないように両腕ガードでしっかり頭を守るという昇侍選手が指導したことも出てこなかった。結果的に打たれるたびに顎が跳ね上がり、強打者相手にかなり危険な状態にあったと思う。一発目で顎が上がるので二発目も入り、自分の打撃の焦点も定まらなくなるという、いつもの斎藤くんだった。
価格よりも、チェーンがついたマジックテープの財布はもう使えない感じかなあ。
結果論なら株で当てたり、ネットでビジネスしてたり会社でなくても金を稼げばいいことだろう。
あれを一番簡単に実現するのはソース送信だけどそれは無しとして他の方法を模索してみる。ちなみに解は出てない。
※想定問答 Q「サーバサイドでやれ」 A「石油王連れてきて」
レコメンド対象にしたいキーワード辞書をアプリに同梱してマッチした単語だけ送る。
本文丸ごとでは無いんで多少は忌避感下がるけど、いつ・誰が・どのURLでそのキーワードをブラウザで見たかは伝わっちゃう。
パーソナライズ不要なら「誰が」も落とせるけどそれだと精度出なかったからあの仕組みにしたんだろうしねぇ…
あと本当に本文だけ使ったレコメンド目的ならURLも不要だけどwww.muji.com→オサレみたいな特徴を加えたかったのかな。
--
最近はiOS(CoreML)にもAndroid(NNAPI)にも機械学習機能あるようで、
ネイティブアプリなんだからその辺触れるんだしクライアント側で完結しちゃえば?という発想。
レコメンド先のコンテンツ丸ごとスマホに持つわけにはいかんから、
コンテンツID?カテゴリ?的なものを出すとこまでやって中身はサーバに取りに行くんで本当にクライアントだけで閉じるわけじゃ無い。
パーソナライズ観点で一人一人特注のモデル作って配るとかはしんどそうだけど、
ある程度セグメント切った層ごとに事前にモデル作るぐらいなら何とかなるんでは。
ああでもレコメンド対象が日々増えるWeb記事だとモデル頻繁に更新するからデプロイが辛いか。
スペックもりもりのサーバでやる推薦が現代のスマホでそもそも代替出来るのかはわからん。
エッジAIなる名目で各社頑張ってて目的の一つはセキュリティだから、今は無理でも将来に期待?
--
分類にしろ推薦にしろ元データそのものをダイレクトに結果に変換するんじゃ無くて一度単なる数値の配列（特徴ベクトル）に変換して、
そのあとモデルに突っ込んだら中でこねこねヘイお待ち!と出てくるんだよね?
その特徴ベクトルに変換のとこだけクライアントでやってそれ送れば?という発想。
スペック問題はあるけどレコメンド全部やるよりはマシだよねと淡い期待を抱いている。
特徴ベクトルから元のデータに戻せるとアウトだけど可能なのかね。
文字列を数値にしててかつ情報量が落ちて結果が1対1にならないから、完全な復元は無理だと思うけどどうだろう。
ありとあらゆるキーワードを事前に変換しといて結果から逆引きすれば変換元候補を出すくらいはできるんかな。
--
いろいろ考えたけどソースそのものじゃ無くてもそれに近い情報はどうやっても送るんだから、
コールセンターに電話すると自動音声で「サービス品質向上のために通話を録音します」的なアナウンス流れたりするのと同じで、
おすすめ機能ってこういう情報送ります的な説明をアプリ内ですべきでそれ無しにやっちゃダメだったんでしょう。
アプリの実物触る前に終わったので実際には説明してたんならごめんなさい。
--
https://toolbar.rakuten.co.jp/mobile/rule.html
利用者が本アプリを利用した場合、利用者は、第6項の定めに従い、これを停止しない限り、本アプリがデバイスにインストールされているブラウザの全てのウェブ閲覧履歴（http（https含む。以下本条において同じ。）で始まる閲覧ページURL、アクセス日時（分秒）、表示されたウェブページのHTMLソース、クッキー情報（Cookie）, ウェブサイトの閲覧履歴、リファラ, ユーザーが使用しているOSやアプリのバージョン、位置情報をいい、以下「ウェブ閲覧履歴取得情報取得情報」といいます。）が当社によって取得されることに同意するものとします。
当社が取得するウェブ閲覧履歴取得情報には、ウェブページのURLを含み、当該ウェブページのセキュリティ環境によってはURLにIDやパスワード等の非公開、又は機密性の高い情報が含まれることがあります。よって、機密性が高い情報、または機密性が高い可能性のある情報を閲覧する環境において本アプリを利用される場合には十分にご留意ください。
ソースどころか脆弱性無い限り聖域のクッキーまで取る豪快さを見習おう。
--
ちなみにフェアじゃないので一応書いておくと「楽天ウェブ検索 規約」でググると出てくるこっちのブラウザ拡張機能版は微妙に内容が違ってクッキーは入ってない。
上のアプリ版はアプリストアの説明にURLが書いてある。なんでアプリとブラウザ拡張機能で2種類あるのかは分からん。
拡張機能じゃ取れないから? でもサイトごとのクッキー編集する拡張とかあったような・・・
https://toolbar.rakuten.co.jp/intro/rule/
２． 利用者が本機能を利用した場合、利用者は、第6項の定めに従い、これを停止しない限り、本機能がインストールされたブラウザの全てのウェブ閲覧履歴（http（https含む。以下本条において同じ。）で始まる閲覧ページURL、アクセス日時（分秒）、表示されたウェブページのHTMLソースをいい、以下「ウェブ閲覧履歴」といいます。）が当社によって取得されることに同意するものとします。
３． 当社が取得するウェブ閲覧履歴には、ウェブページのURLを含み、当該ウェブページのセキュリティ環境によってはURLにIDやパスワード等の非公開、又は機密性の高い情報が含まれることがあります。よって、機密性が高い情報、または機密性が高い可能性のある情報を閲覧する環境において本機能を利用される場合には十分にご留意ください。
あとこの規約についても先日malaさんが突っ込んでいるので第一発見者ではないです。
https://twitter.com/bulkneets/status/1339435587015639041
--
ソースどころかクッキーまで取ってますと堂々と書いてるほうが燃えずに、
はっきりとは書かずに取ってたほうが燃えてるの、
やらないと思ってたやつがやる・やると思ってたやつがやる、どっちもやってるけど燃えるの大抵前の方なの、
