  |
はてなキーワード: ウェブページとは
マスクつけるのが当たり前の世の中になったけど、2歳以下の乳幼児のマスク着用は窒息とかのリスクがあるってのは世の中に浸透してないのねって思った。
https://www.jpeds.or.jp/modules/guidelines/index.php?content_id=117
9ヶ月の子連れでスーパーに行ったら中年の男性が私に向かってなんか言ってて、その後レジの店員さんとレジ中の女性に向かって「マスクをつけないなんておかしい。この世の中なのにコロナが怖い」というようなことを言っていた。
多分うちの子がマスクをつけてなかったから言い出したんだと思う。
レジ中の女性に向かって言ってたのは多分うちの子に向かって「かわいいねー」と話しかけてくれたので、絡まれてしまったのだと思う。（お前が注意しろよ的な雰囲気に見えた）
怖かったのでささっと出てきてしまったけど、私じゃなくて他の人に絡み出したのが申し訳なかった。
男性も出口に向かってたから多分あれだけで済んでたと思うけど。
落ち着いたらなんか最近感染予防のCM流れてるし、尺がないかもだけど「乳幼児はマスク勘弁したって」って流してくれないか投書してみようかな。
まともに実装してもスクロールやブラウザのヒストリーに問題があった上に、まともに実装していない多くのサイトでは表示崩れを誘発した。その上、オリジナルの記事にすぐにアクセスすることもできない。劣化版ページを強制させられているようなもの。
URLを共有するときにAMP版のURLを貼る人が続出。Googleから移動しないためか表示はさらに崩れ、わざわざ記事タイトルをググってオリジナルの記事を探すはめに。URLでのパブサも分断されてしまう。そしてもちろんはてなブックマーク的にも不便だった。
なぜ、Googleごときが「あるべきウェブページの姿」を定義できるのか？ なぜ、それを「検索結果での優遇」という形でごり押すのか？ 表示の速さを求めているのはGoogleの都合であって、ユーザーにとっては速かろうが遅かろうがどうでもいい。表示が速いといって質の高い記事が読めるわけでもない。よっぽど遅ければブラバするだけ。そもそもAMPの未熟な仕様のために強いられた不便によるロスのほうがよほど大きいだろう。
これだけのデメリットを押しつけておいてユーザーにメリットはゼロ。Googleは腹を切って地獄に落ちるべきだし、それに乗っかってAMPを推進したウェブエンジニアらも猛省すべきであろう。君たちは、君たちがあれほど憎んだIEにも並ぶ邪悪なレガシーを、君たちの手で生み出したのだ。
脳が老化すると前頭葉の働きが衰えて、理性的でなくなり、怒りを抑えられなくなるってのを聞いたことがある。
つい最近、自分もそうなりつつあるんじゃないかと思って不安になったので、ここで吐き出しておく。
今まで利用したことのない某サービスを利用してみようとウェブサイトから申し込みを行なった。
いくつも店舗があるのだが、自宅から行きやすそうな店舗を選んで初回予約の申し込みをしたところ、
（主な利用客は女性なので）男性にサービスを提供している店舗は限定されているようで、当該店舗では取り扱ってないとのことだった。
「取り扱いしている店舗に問い合わせてください」という回答で、店舗一覧ページのURLを案内されたのだが、
その店舗一覧ページを見ても、自分がサービスを受けられる店舗がどれなのかは掲載されてない。
この時点でちょっと腹が立った。
サイト内を回遊して、何とか男性の取り扱い店舗一覧を見つけて、別の店舗に申し込んだところ、そこでも取り扱っていなかった。
どうやら名称の似た別の店舗と間違えてしまったようだ。（「東急渋谷店」は「渋谷店」とは別物だったみたいな感じ）
そしてまた、「取り扱いしている店舗に問い合わせてください」という回答で、またウェブページを案内された。
今度は、必要な情報の載ってない店舗一覧ページではなく、男性の取り扱い店舗一覧ページだった（さっき自分が見てたページ）
たらい回しにされた感じがして、また腹が立ってきた。
店舗名を見間違えていたのは私のミスなので仕方ないのだが（それでも誤認しやすい店舗名の付け方に問題はあると思うが）、
なぜ他の店舗に問い合わせよと言う回答に、「○○店や◆◆店であれば取り扱っています」などと近隣で取り扱いしている店舗を具体的に案内してくれないのだろう。
多店舗展開している事業者だから、実際に受付対応しているのはアルバイトの人なのかなと思うと、そこまで気の利いた対応を求めるのは違うとは思う。
それでも求める情報が掲載されてないページを案内するだけで済ませるのは仕事が適当すぎる。
苛立ちが収まらないので、お問い合わせフォームで苦情を入れた。
上述の経緯、対応している店舗がどれなのかサイト上で探しにくいこと、店舗名が紛らわしいこと、ウェブページを案内するだけでなく近隣で利用できる他店舗を具体的に示して案内してほしかったこと。
怒りを感じながらだが、きちんと丁寧語で書いた。業務の改善には役立つ情報になるだろうとも思いつつ。
自分は、手厚く待遇されることで満足感を覚えるタイプの人ではないと自認している。
人を持ち上げたり人から持ち上げられたりするのは好きじゃない（ので、フリーランスで上司も部下もいない仕事に満足している）し、買い物するときには用があるまで絶対に話しかけてほしくない。
それなのに、ぞんざいな扱いを受けたような気がして腹が立ってしまったことにちょっとした衝撃を覚えている。
今回の先方の対応は、通り一遍のシステマチックな対応だったというだけであって、特段失礼と言えないものだったのに。
メールだけのやりとりなので、相手に対して声を荒げたりあからさまに高圧的な態度を取るということは起こらなかったけど、対面だったら穏やかに振る舞えただろうか。
safari真っ白になって
アプリの設定が進まないと思ったら
で、やっぱり
VPN解除して
280block
外したけどかわらない
開けすぎてる
タブも全部閉じた
だめじゃん＞＜
で、ひょっとしてと思って
設定のほうの
280block
がONのままでした💦
解除したら
フツーに表示。
ホワイトリストに入れとかなきゃですか。
safariも使ってんだよ……。
Safariでウェブページが真っ白になり読み込めない場合ですが、
その都度Safariをマルチタスク画面で完全終了させ、ホーム画面からSafariを再起動することで一時的に改善するみたいです。
あくまで一時的なので、しばらくしたらまた症状が発生することがあります。
というのがぐーぐるさまで最初に出てくるんだけど、
もちろん治りませんでしたｗ
真っ白になったのが
クレジットカードの関連作業するために開いたサイト（広告はないでしょ）
だったのだけど、不思議。
いくつかの政党の重点政策をウェブページで確認し、バラモン左翼度を判定してみました。バラモン左翼政策の定義は、「正社員、非正規、中小企業、高齢者、子供、農家、大企業のどれにも目に見える利益が4年以内にない政策（外交を除く）」としています。環境、多様性、行政改革が典型的なバラモン政策です。
立憲民主は明らかにバラモン度が高いです。立憲民主は、最初の3つの政策がほぼバラモンですが、自民党のバラモン政策は最後に一つ、国民民主にはバラモン政策はなく、共産党ですら最初の2つの政策はバラモンではありません。自民党が憲法改正を最後に置いているのは、押し出したい執行部と選挙に勝ちたい宣伝部隊の綱引きの結果じゃないかと思うんだよね。立憲民主には国民の関心によって重点政策を柔軟に変えられるような体制は整ってないんだろうか。トップページにジェンダー平等を置いて経済も福祉も置かないのセンスない。それとも過半数とかあきらめてバラモン極振りのニッチ政党になるつもりなんだろうか・・・。
| 立憲主義に基づく⺠主政治 | バラモン |
| 人権を尊重した自由な社会 | バラモン |
| 多様性を認め合い互いに支え合う共生社会 | おおむねバラモン |
| 人を大切にした幸福を実感できる経済 | バラモンでない |
| 持続可能で安心できる社会保障 | バラモンでない |
| 危機に強く信頼できる政府 | おおむねバラモンでない |
| 世界の平和と繁栄への貢献 | バラモンでない |
| 外交 | バラモンでない |
| 経済 | バラモンでない |
| 地方 | バラモンでない |
| 福祉 | バラモンでない |
| 防災 | バラモンでない |
| 憲法改正 | バラモン |
| 福祉 | バラモンでない |
| 教育 | バラモンでない |
| 地方 | バラモンでない |
| 外交 | バラモンでない |
| 消費税 | バラモンでない |
| 外交 | バラモンでない |
| 原発ゼロ | バラモン |
| 米軍基地 | バラモンでない |
| 社会保障 | バラモンでない |
| 日米FTA | バラモンでない |
| 農業 | バラモンでない |
| 防災 | バラモンでない |
| 差別撤廃 | バラモン |
ウェブオンリーの話ってあるからネップリのコード自体ウェブオンリー会場に来た限られた人しか見られないんじゃない？
そのコード広める人は同人誌もウェブページも広めるレベルの人だと思うし
女性向けでTwitterは鍵付き、なんか作ったもんあげるときはピクブラなジャンル。
最近ちょこちょこウェブオンリーが開かれてるんだが、そのときによくわからないルールがある。
小説書くなり漫画書くなりイラスト書くなりした人がPDF化してコンビニのネップリに登録して、欲しい人はコンビニに自分で行って印刷してねってアレ。
あれ禁止されてるんだけどよくわかんないんだよね。
下手に人に訊いたらこいつジャンルのことわかってないやつって思われそうだから安易に聞けない。ごちゃんで訊こうものならその程度のこともわからないの？釣り？わかんないならこのジャンルやらないでと言われそう。ていうかそんなレスがついてるの見た。でも誰も明確に教えてくれないんだからわからないんだよ。
金銭が発生するというなら同人誌の印刷だってそうだ。印刷所に発生するし、赤ブーなんかのイベントに参加するなら赤ブーとの金銭関係ができる。
ネップリだから番号を晒されるかもしれないレベルのだったら、ピクブラみたいなオンラインにあげてるのはどうなんだ？って話になるんだよ。アドレスとパスを晒されたら同じだろ。
印刷したものを晒されるかもレベルの話ならもう同人誌作るのもウェブに作ったものあげるのもやめろよ。ウェブページって、もしかして知らないかもしれないが実は印刷できるんだよ。
ああ言えばこういうとかなんだとか文句つけられるかもしれないけど禁止な理由が全くわからん。でも誰になら訊いても大丈夫かもわからん。主催に捨て垢から質問したときは、このジャンルは配慮が必要なジャンルなのでこの程度のことがわからない人は～だったし、どうやって知ったらいいんだよ。
これ「ソーシャルブックマーク」じゃなくて「どこでもオンライン掲示板」と「みんなで作ろう！今日のネットニュース」では
検索エンジンってとても便利ですよね。
今は何かわからないことがあったときにGoogleとかで検索すればすぐに答えが出てきます。（とはいえ、正確性は担保されるわけではないので注意が必要。）
ここまで便利になってくると昔はどうやって疑問点の解消をしていたのか不思議になってくるレベルですね。
例えば、転職をしようと思っても転職ってそもそもどうやってやればいいのかわからないだろうし、他の人の体験談もわからない。
そういったことで、新しいチャレンジへのハードルが上がっていたのかもしれませんね。
ちょっと話がずれましたが、検索エンジンってGoogle以外にもいろいろありますよね。
日本ではGoogle検索やYahoo検索のシェアが高いですが、Yahoo検索の中身はGoogleらしいので、実質的には日本の検索エンジンはGoogleが寡占状態なわけですね。
今はいろいろな情報がネットで調べられるようになったので、信憑性がどうあれ、ネット検索をしたときに上位表示される記事に書いてある内容がかなり大きな力を持っています。
検索結果の1P目に表示されないウェブページはもはや存在しないに等しいレベルですね。
とすると、検索エンジンがどういったページを上位表示するかは、大衆を動かすレベルで重要なことになってきます。
だけども、そこは日本においては結局Googleが握ってしまっているところにときどき恐怖を感じたりします。
Google検索と、duckduckgoとかの検索エンジンが良い感じにシェアを2分していれば、どちらの検索エンジンがいいウェブページを表示するかで、競争原理が働きますよね。それが今はGoogle一択になってしまってなかなか難しい。
先日はトランプ前大統領もTwitterアカウント凍結されました。もはやIT大手の力は国家のレベルにも近いのではないでしょうか。
実はauとか、docomoなんかも検索エンジンを持っているようですが、中身はなんなんでしょうね。やっぱりGoogleなのでしょうか。
https://search.smt.docomo.ne.jp/result?MT=%E5%90%8C%E6%A3%B2%E3%80%80%E5%8F%A3%E5%BA%A7&SID=000
あれを一番簡単に実現するのはソース送信だけどそれは無しとして他の方法を模索してみる。ちなみに解は出てない。
※想定問答 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
--
ソースどころかクッキーまで取ってますと堂々と書いてるほうが燃えずに、
はっきりとは書かずに取ってたほうが燃えてるの、
やらないと思ってたやつがやる・やると思ってたやつがやる、どっちもやってるけど燃えるの大抵前の方なの、
この冬に予定されている院試受験者と、来年度以降の受験者のために内容をメモしておく。
前提として私の背景は下記となる
研究科のページから教員一覧に目を通して、やりたい研究に近い研究室で学生ウェルカム感のあるウェブページをもつ先生に連絡した。
そのあとオープンキャンパスに出席し、そこでの座談会で事前に連絡させてもらった先生と話したが、どうも研究テーマが研究室とミスマッチ感がでていたので、その先生に他の先生を紹介してもらった。最終的には、紹介してもらった先生を第一希望で受験申し込みをおこなった。
４つの項目について２ページ以内で書かないといけない。
いわゆる"研究計画書"・"論文"みたいな仰々しいフォーマットではなく、見出しはフォント大きく、太字にして、必要なところはリスト形式にして、と、口頭試問前提の読みやすさ重視のフォーマットにした。
例えるならGitHubのREADMEのようなフォーマットで書いた。といっても下記については一般的なレポート記法に従った
半ページ強を使った。内容としてはざっくり下記の３点を記載した。
半ページ弱使った。卒業研究はどうも書きづらかったので、幸い長いこと取り組んでいるプロジェクト（研究ではない）があり、そのプロジェクトについて、研究ぽいとこだけ抽出して概略を書いた。
２行程度書いた。博士後期課程行きたいけど、そのときの金銭事情にもよるから未定ということを書いた。
２枚目丸々１ページを使った。
背景・方法・成果で1/4ずつ、加えて残りの1/4に研究テーマの概略図（パワポ１枚みたいな）を載せた。
下手なこと書いて口頭試問で痛い目に合わないことを意識して、とにかく専門用語・具体的なアルゴリズム名は避けるようにした。
統計・機械学習なら、平均・分散までしか使わない。SVM・ディープラーニングなんて言葉は避ける。可能な限り高校生でも知っていそうな言葉だけ使うようにした。そうすると参考文献を書く必要もなくなり全体的にスッキリした体裁になった。といいつつ専門用語まったくないのも薄っぺらい気がしたので、確実に解説できる１語だけを記載して、その１語には参考文献の番号振って、ページ末端に小さいフォントで参考文献を記載した。
あと、提案手法の評価方法だけはすごい意識した。このあたりは"研究計画書の書き方"で、グーグル検索してもらったほうが詳しい。
会場は大きめのホールで受験生は３０名ほど。多くの受験生はスーツだったが、Tシャツジーンズの受験生もいた。試験当日の座席配置と合格発表の番号を見るに私服の受験生も受かっていた。
問題は２問でた。
必答１問 A4 1枚
"研究科で何を学んで何に活かすか"みたいなテーマだった。私は具体的な志望業界があるので、データ分析に関する研究をして、その業界の研究職でこういう仕事がしたいということを書いた。
選択１問 A4 1枚
私は２を選んだ。具体的なシチュエーションを想定したうえで、下記のような観点で、ストーリーを作った。AIビジネス/ビッグデータビジネスの事例の本で読んだことを項目にあてはめて回答した。
待合室として教室に移動させられる。１人３０分で、口頭試問は３会場あって１人ずつ呼ばれる。試験時間は当日に案内があった。一番遅い人は４時間待ちだと思う。待合室は比較的出入り自由。待合室にスタッフがいるわけでもない。自分の試験時間に待合室にいればよいと案内あったが、途中、試験時間の時間変更があった。受験生は各々スマホいじったり、トイレにたったり、おそらく外出もしていた。すごい暇なのでスマホの充電は十分にしていったほうがいいと思う。
試験会場は少し狭めの教室。希望をだした先生+3~4名の先生方が長机に並んでいて、その前にパイプ椅子がおかれているような形式。先生方はおそらくコース混合だったと思う。
希望の先生から、研究計画書に書いた統計用語から発展した内容の用語について説明できるかという質問があり、教室の黒板を使って説明した。たまたま口頭試問対策でヤマはってた質問だったが、対策していなければ答えられない用語だった。必修講義の統計基礎レベルではでてこない用語で、統計応用レベルの教科書でこんなこと書いてたなという内容を説明した。といっても決して"専門書"レベルの範囲ではないので、私が勉強不足なだけかもしれない。分からないことは分からないで通して、しどろもどろになりつつ自己採点100点満点中40点ぐらいの説明になった
そのあと他の先生方も含めて、いろいろ質問を浴びせられた、なぜこの研究科を選んだのかとか、なぜこのテーマをやるのか、どうやるのかとか面接に近い感じ、研究計画書に書いた、これまでの研究・希望進路についてはとくに聞かれなかった。終始、なごやかな雰囲気ではあった。
こんな雑多なメモだが、役に立つと嬉しい。
4台のPCに一つずつ稼働させることにした。
【よかったこと】
・IISというWindowsのサーバー建てるフレームワークみたいのを使って初めてWindowsでサーバーを建てる経験を得られた。
Windowsでサーバーを立てるのは規約違反だった気がしたが最近はWindowsに元々サーバーを建てる機能が付属してるし別にいいのだろう。
・Windows10のドライバ認識能力のすごさを知ることができた。
Linuxだとファンが回らない、何も映らないけどWindowsだと普通に動くなどした。
・Windowsでサーバーを建てるのはムズイという知見を得た。
・信じられないくらい遅い
CPU使用率が低いままで全く変わらず、にもかかわらず簡単なウェブページの表示に10秒とか待たされて使い物にならなかった。Xubuntuに変えたら1秒以内に表示された。
httpsにリダイレクトされるのをやめさせようとしたり、SSL証明書を設定しようとしたがどうやってもできなくてWindowsを使うこと自体を辞めた。
・家に余ってたHDDを全部繋げて1.5TBのクラウドサーバーを作ることができた。
複数のHDDを一つのHDDとして扱う技術（LVM）の設定をする体験ができた。1.5TBの使い道はない。不用品の処分をするのが目的。
・XubuntuならMacbookPro(2007年製)にUSBメモリからインストールできることを知った。ただしインストール画面がたまにしか表示されない。
【デメリット】
・今までは仮想マシンで動かしていたので扱いやすかったのだがそれができなくなった。
失敗しても5分前の状態に戻すとかできないし、仮想イメージのエクスポートとかできない。
・電気代を4倍食うようになった。
