  |
はてなキーワード: GOOGlEとは
Googleの場合、自社で抱えている大量のデータの活用方法するという目的がある。
データを集めたはいいが、それが使えなければ保存にお金がかかってしまう。
もう1つの目的は、膨大な計算機リソースを多くの人が必要と信じさせる必要がある。
Googleとしては、より多くのデータと計算リソースをかければ精度が上がる、と信じてもらえば稼ぐ機会が得られる。
どれだけ計算機リソースをかけたかで性能勝負がつくゲームの中にいる間はGoogleの地位は予想しやすい。
世界のどこかでGoogleを脅かすような大量の計算機を容易しようとすると察知することができる。
数人の天才がGoogle社外にいたとしても、ワークステーションレベルで結果が出ない、という状況が続く方がGoogleにとって都合がいい。
Googleとしては、世間が機械学習に注目してくれている限り、本当にハイインパクトな自社でやっているPJから目をそむけることができる。
今の機械学習の状況は、色んなデータセットが出てきているがベンチマークで競争しているところから産業に結び付けられてない。
多くのプロジェクトだと機械学習だけで予算を食ってしまうような状況だろう。
日本などは国家レベルの意思決定でも振り回されてしまっている。
より性能が良い新しいのが出来てすぐ陳腐化してしまうし、ソフトで常にアップデートできるというが、その更新費用が馬鹿にならない。
そして何より産業応用先がないのだ。
分類しようにもコンビニや100円均一にある商品全て認識して分類できるわけでもなく、もっと大雑把な分類しかできてない。
分類できる数を増やそうという研究もあるが、そもそも1円でもコストを下げようという分野には全然向いていない。
自動運転車くらい価格が高く、何十万か上乗せでもやっていける商品か、金融くらいしかない。
AIで多くの人が想像するようなことは機械学習の延長上にはない。
ブーム初期ならそれでも良かっただろうが、もう数年経っている。
人件費を抑えたい、自動化したいなど、ビジネス要求は色々あるだろうが、目的にあってないのに、なぜか乗り遅れないようにと多くの人が思わされる。
海外から来るのは選手のみだと15000くらい。関係者含めて約10万人だっけ？なんて考えてたら以下の記事を見かけたのでそれをもとに考察してみたい。考察を行うにいくつかの記事を眺めリンクで示したが、素人の概算なので正確性はなにも担保しない。自分で考えて。
https://news.tv-asahi.co.jp/news_society/articles/000216513.html
ちなみに筆者の結論を先に書くと、下記の最低賠償額1600億円を払うくらいなら条件付きで開催すれば良いという結論になりました。
https://news.yahoo.co.jp/articles/b9077c3316e38166d8ae9127cbc6756e43dc972a
選手のみで考えると、選手村を設置する晴海フラッグから感染が広がっても地理的に隔離されているし、バブル方式に嫌気が差して脱走して飲みに出かける選手がいるとしても、入国時には6割がなんらかのワクチンを接種済みらしいので大事にはならないだろう。行動制限も厳しい。
医療の逼迫を懸念するほどでもなく、誤差程度のリスクに落ち着きそうだ。開催してもよいと感じる。
以下の記事によるとIOC関係者は上等なホテルを貸し切るみたいだが、収容人数を考えると6000から7000人程度だろうか。
https://news.yahoo.co.jp/articles/7dedcc43442d7dcdae859627838a167bc68e2a9d
IOC関係者も選手と同様にどうせワクチンを摂取しているだろう。選手より接種率が高くても驚かない。
こちらももともとオリンピックに反対している人を除いて、無観客での開催なら賛成が多そうな誤差程度のリスクに落ち着きそうだ。
https://news.tv-asahi.co.jp/news_society/articles/000216513.html
他の属性に比べ最もワクチンの接種率が低そうだし倫理観が低そう（偏見）。
人に会うことが仕事なところがあるので、選手向けだけではなくより厳しい行動制限を科してほしい。
スポンサーはIOC関係者なのか別枠なのか。もし別枠としても、世界中のいわゆる上級国民なのでワクチン接種率は高そう。
また、50000人の内訳としてそれぞれの代表団のサポートチームがメインと考えると、こちらも選手と同じ接種率は6割か、それより少し落ちる程度だろうか。
競技に伴う移動はあれど、業務的に選手に準じた行動をすると思われるので受け入れリスクは低いだろう。
この記事を書いている 5/23 時点で人口10万前後で接種率が4-6割前後の地域を調べてみた。
必要回数のワクチン接種が完了した割合は41.1%（5/23確認時点）
もともと感染者数が増えていなかったのもあり、おおよそ鎮圧に成功している。ここ最近の感染者数は1人/日。
https://www.gov.je/Health/Coronavirus/Pages/CoronavirusCases.aspx
ワクチン接種率の上昇に伴い、おおよそコロナを鎮圧しつつある。ここ最近の感染者数は9人/日。
必要回数のワクチン接種が完了した割合は38.2%（5/23確認時点）
フランスから運ばれたワクチンらしく、 google によると biontech と Pfizer 製ということなのでいわゆるファイザー製 mRNA ワクチンみたい。
https://www.afklcargo.com/JP/ja/local/news/aruba_vaccines.jsp
https://graphics.reuters.com/world-coronavirus-tracker-and-maps/ja/countries-and-territories/aruba/
人口約13万人。アフリカにあってアストラゼネカ製のワクチンを使用している。ここ最近の感染者数は178人/日。
必要回数のワクチン接種が完了した割合は63%（5/23確認時点）
接種後に増えたというニュースがあった。
https://www.bloomberg.co.jp/news/articles/2021-05-10/QSWCFGDWRGG101
上記の感染数が急増したピーク時から一週間で44%まで新規感染者数が低下したようだ。今後の推移がどうなるか。
変異株どうこうよりちゃんと免疫がつく前にはしゃいじゃったんだろうか。
数字だけ聞くとまじかよ……ってなるけど、通勤で隣県から東京に流入する人口は一日あたり270万人くらい。通勤やばい。
東京の人口1400万人との比率から、感染拡大がひどかった今年1月の2400人/日を基準に考えると最悪で一日170人の上積みが予想される。
上記は最悪の事態を想定したが、とはいえボランティアは人口比率的にもほとんど東京近郊からの参加に思われる。
その場合はトレンドが変わることはなさそうなので、ボランティア参加者が積極的に連日飲み会に繰り出さないと感染者数の上積みはほぼ無いだろう。
開催にあったってコロナ対策の追加費用がいくら掛かるかといった点も気に掛かる人が多いと思うが、請け負うのは基本国内企業なのだからお金が消えるわけでもなく、公共事業としてばらまけばいいのではと思っている。
ただでさえ経済が縮小している中で、個人給付よりよっぽど関連企業で働く人達への慈雨になるだろう。
国よりも民間のほうがお金を持っているし、お金は動かさなければ意味がないのだ。
観客入れても大丈夫なんじゃね？って検討はバブル方式なりで選手の移動を制限することと、世界的なワクチン接種率の向上を見越したやり取りなんだろう。
もし観客を入れるにしても流石にワクチンパスポート必須になるだろうし。
個人的にはマスコミ除く 70000 人は中止の損害賠償にかかるという最低1600億円と比べると十分にリスクが低そうに見える。
ワクチン摂取必須ならともかく、入国を許可するならもっと行動制限を行うべきだ。選手たちよりもゆるいとか何やねん。ロイターの場合、記者は感染発覚後にクビにしたから関係ないとか言ってるから信用はない。外電買えばいいじゃん。
ボランティアと観客として国内でワクチン二回接種済みの高齢者なりがいくらか参加するとしても、ボランティアと観客を足して、そのグループにおける会場でのワクチン接種者の比率が7割あれば集団免疫を獲得しているのとあまり変わらないのではないか。しらんけど。
今年は長梅雨になりそうだから緊急事態宣言と併せて開催時までに感染者数は落ち着いているだろう。
具体的に言うとステージ1なら観客OKにして大金を使ってほしい。3以上なら国内からは無観客。
開催までにはいくつかコロナ清浄国が誕生していそうだからそこからならいいんじゃない？ワクチン接種は必須で。
梅雨入りが早かったことで開催に携わる人達はだいぶ希望的観測を持ってあれこれ観測気球をあげてそうだが、開催方法に何段階かあるにしても現状では開かない理由は無いだろう。
梅雨のおかげで人手が減り、延長した緊急事態宣言もあいまって感染者数もかなり減ることが期待されるし、おそらく一ヶ月後には国民感情もポジティブな方にだいぶ変化があらわれているんじゃないだろうか。
世界中に開催国リスクをまざまざと見せつけたIOCが近代オリンピックにトドメを差すであろう場所が東京になるとは夢にも思わなかったが、30年もすれば「その昔、世界中の国々が集まっていろんなスポーツで勝負を決める大会があったんだよ…」とオリンピックを知らない世代に語ったりできるように生き延びたいと思う。
皆様もご安全に。
Googleで「ネトウヨ○○(○○には職業が入る)」を検索し、表示される結果1ページ目に該当人物のプロフィールが分かるページ(公式サイト、Wikipediaなど)が表示される人、
つまりは「○○界を代表するネトウヨ」と呼ぶべき人物がどれくらいいるか知りたい。
https://www.google.com/search?q=%E3%83%8D%E3%83%88%E3%82%A6%E3%83%A8%E4%BD%9C%E6%9B%B2%E5%AE%B6
https://www.google.com/search?q=%E3%83%8D%E3%83%88%E3%82%A6%E3%83%A8%E9%AD%9A%E5%B1%8B
匿名だから表示するべきプロフィールがないだけで、該当する方に入れてもいいかもしれない。
こちらも同様。
Webを閲覧する、YoutubeやNetfrixを楽しむ、電子書籍を読む、ちょっとしたゲームをプレイする、SNSでコミュニケーションを取る程度のライトユースなら十全に使えると言って良いです
メモリを大幅に消費する4K動画編集をする、リアルタイムに重量級エフェクトを掛けて楽器を演奏したい、iPad並にイラストレーションがしたいというクリエイティブユースになってくると少々厳しいです
ただしクリエイティブユースであれAndroidでは代表的なシンセサイザーアプリの「Caustic」や「Zenbeats」「FL Studio Mobile」で作曲する程度なら普通にいけます。MIDIキーボードも認識しますしね
厳しいのはバンドパフォーマンス並みのリアルタイム演奏ってことになります
同様の理由で膨大なレイヤーがなければイラストレーションもいけますし、フルHD程度なら動画編集もいけます
そしてリアルタイムの描画演算能力を問われる3Dゲームや、タイミングがシビアなリズムゲームも苦手な部類です
リアルタイム性が問われてしまうとどうしてもARMアーキテクチャー向けに生成されたアプリはx86_64アーキテクチャーデバイスではツライものがありますね
Googleも各アーキテクチャデバイスへ向けてアプリを生成すべしと宣伝してますので、x86_64デバイスでのAndroidアプリパフォーマンスはChrome OSデバイスが注目を浴びていることもあり徐々に改善していくものと思われます
当エントリはある程度の情報技術リテラシーが必須であり、一部の情報はPC初心者および初級者に推奨できるものではない。
しかしPC初心者および初級者はシステムを壊す、大事なデータを失うなどの手痛い失敗をして成長するのもまた事実であり、もしもプログラミングなどに興味のあるPC初心者および初級者がこの情報を活用する場合はシステムを壊す、大事なデータを失うことを覚悟して実行するように。
チュートリアルに指示通りに進めれば大きな問題はほぼ発生しません。
Chrome OSは初期状態のデフォルトで「ノーマルモード」と呼ばれる一般ユーザーモードですが開発者向けに「デベロッパーモード」が用意されています。
ノーマルモードはChrome OSの様々な制限があり、デベロッパーモードによって制限の解除が可能です。
しかしノーマルモードからデベロッパーモードへ移行するとPowerwash(初期化)されてしまい、システムやユーザー領域へ追加された情報はすべて削除されます。
もしデベロッパーモードが必要な場合はデベロッパーモードの詳細を調べ、現在の情報は削除されてしまうことを念頭に実行しましょう。
ちなみにProject CrostiniのLinuxレイヤーへDebianリポジトリからパッケージを導入するなどにはデベロッパーモードは必要ありませんので多くの場合はノーマルモードのままの運用で十分でしょう。
Android OSアプリやChrome OSアプリを開発したい場合は最初からデベロッパーモードにしたほうが後悔が少ないです。
Chrome OSでは一部のキーがほかのOSでは見慣れないものが並んでいます。
迷いがちなので一番最初に覚えるべきキーボードショートカットは「Ctrl+Alt+?」です。
「Ctrl+Alt+?」でいつでもキーボードショートカットを確認できることだけは覚えておきましょう。
多くのChrome OSデバイスはGoogle Play Storeへ対応しており、Google Play Store経由でAndroid OSアプリ導入が可能です。
しかしながらGoogle Play Storeへ公開されているAndroid OSアプリが必ずしもChrome OSへ最適化しているのか？と言えばそうではなく、Android OSアプリの開発環境であるAndroid StudioがデフォルトでChrome OSでの実行を許可していることもあり開発者が意図せずChrome OSへインストールできてしまうことが大半です。
したがってChrome OSへ導入するAndoirdアプリの動作へ何らかの不具合があったとしても脊髄反射で酷評せず、やんわりと丁寧に博愛精神をもってChrome OSではこうだとアプリ開発者へ情報共有することをオススメします。
多くのAndroidスマートフォンやタブレットはARMアーキテクチャーと呼ばれるものを採用していますが、現在のChrome OSデバイスは高性能な製品になるほどx86(x86_64)アーキテクチャーを採用している傾向があります。
本来コンピューターアプリケーションというものはアーキテクチャーが異なると実行起動動作が不可能ですが、Android OSアプリは異なるアーキテクチャー間でもアプリの実行起動動作が極力可能となるように互換性をだいたい確保しています。
しかしながら例えばARMアーキテクチャー向けのAndoird OSアプリをx86アーキテクチャーなデバイスで実行するとアプリ動作のパフォーマンスが著しく落ることが多いです。
これは高度なグラフィックス機能を必要とするゲームなどで顕著に現れる傾向にあり、Chrome OSでは期待したほどAndroid OSアプリが軽快に動かない可能性を理解しておく必要があるのです。
コロナ禍によって多くのChrome OSデバイスを販売することが出来ましたが、それによってChrome OSデバイス間の性能差が問題視される機会も増えました。
具体的には「インターネット上でChrome OSでの動作報告がなされているAndroidアプリが自身のChrome OSデバイスではインストールできない」といった報告です。
これは一部のAndroidアプリ開発者がデバイス性能によってインストールの許可不許可を決めているために起こることで解決方法は基本的にありませんので諦めましょう。
これから導入するAndroidアプリのためにChrome OSを購入する際は価格につられて低性能すぎるデバイスを購入してしまうと失敗する確率が高まりますので注意が必要です。
ただし、Googleが提供するアプリなどは基本的にそのようなことは無いようです。
設定から「Linux（ベータ版）」で「オンにする」とLinuxのインストールが開始されます。
現在のChrome OS v90ではLinuxレイヤーを実現するProject CrostiniではデフォルトでGPUによる支援機能を実行できません。
Chrome Webブラウザを起動し、URL欄へ「chrome:flags」と入力しアクセスして「Crostini GPU Support」を「Enabled」とし再起動してください。
この変更で動作に不具合を確認した際は設定を元に戻してください。
LinuxにもGoogle Play Storeのような簡単にLinuxアプリを導入できる環境が存在します。
GUIパッケージマネージャーを導入する場合は「ターミナル」を起動し下記を実行してください。
sudo apt install synaptic gnome-software
Chrome OSとLinuxレイヤーではパッケージの導入先がデフォルトで海外のサーバーになっており少々遅いです。
日本国内のサーバーへ変更することで速度を改善できる可能性があります。その際は「ターミナル」を起動し下記を実行してください。
現在のChrome OS v90ではChrome OSとLinuxレイヤーを実現するProject Crostiniで日本語入力を共有できず、キーボード入力しても英字しか印字されません。
日本語入力をするには別途に日本語インプットメソッドと日本語フォントが必要です。
日本語インプットメソッドと日本語フォントを導入する場合は「ターミナル」を起動し下記を実行してください。
Linuxへ詳しい方はfcitx5のほうが何かと問題が少ないでしょう。
しかし一部のfcitx5向けパッケージがDebian公式リポジトリに存在しない可能性があるのでご注意ください。
KVMやLXC、Dockerなどの仮想環境を幾度か試しましたが、仮想環境を構築したProject CrostiniのLinuxレイヤーを再起動するなどによってProject CrostiniのLinuxレイヤーシステムへ致命的な破壊が起きることがあるのを何度か確認しています。
Project CrostiniのLinuxレイヤー自体が仮想環境のため、Chrome OSのシステムが破壊されるわけではないですが業務利用時にLinuxレイヤーシステムの破壊が起きてしまうと困ってしまうので仮想環境構築は推奨できません。
仮想環境によって開発環境の統一を計っている現場では開発デバイスとしてChrome OSデバイスは利用しないほうが良いでしょう。
ただし、Chrome OSデバイスは実質的にAndroid OSデバイス、タッチスクリーンデバイス、キーボード付きデバイス、タブレットデバイス、ノートPCデバイス、コンバーチブルデバイス(いわゆる2in1)、マルチタスクデバイス、ウィンドウ可変デバイス、タッチスタイラスペン付きデバイスとして機能する可能性を秘めていますので実機デバッグ用デバイスとしては非常に価値があります。
昨今はアスペクト比が16:9でないどころかリアルタイムに可変してしまうデバイスが物凄く増えていますのでスマートデバイス向けアプリを開発する現場ではデバッグ用として1台持っていても全く損しないデバイスかと思われます。
さらに言えばティーン層はGIGAスクール構想によりChrome OSでプログラミング学習をしているわけですからティーン層取り込みのためのUI開発にも使えるのではないかと考えます。
良い言語だと思うが、不満がある。
という愚痴がある。他人の書いたものを読む分には良い言語だと思うよ。
型ヒントはコンパイル時のエラーにならないじゃん。だったら、いらなくね？タプルは複数の値を返すときに使うのね。Go みたいだね。または Ruby の Struct みたいな。
あれ嫌いな人おるのか。俺も好きじゃないが。純粋に Haskell と同じ文法だったら良かったのにね。
アレはキモいね。素直に ?! で良いと思う。というか、Python は英語圏の人も納得はできないだろ、っていう文法が多くないか？
というのは同意する。ただ、書くときにそうは思わない。例えば、with 構文は Ruby の方がブロックを抜けたらクローズするという方針のが良いと思う。
ぶっちゃけVRARはGoogleが一番最初にGoogle glassという理想系を発表したせいで、他のデバイスがクソダサなクソデカヘッドギアにしか見えなくなったのが敗因だと思う
Linuxフリークでもそうでも無い人でもLinuxへ多少の知見があればエントリのタイトルが目に入った時の声はたった1つだろう。
「は？」
これは良くも悪くもLinuxのデスクトップOSとしての評価を如実に表している声だ。
不便・不安定・不親切、おおよその一般ユーザには全く推奨できず、不具合の解消はLinuxユーザ自身の問題解決力が問われる。
しかしそんなLinuxは不気味なほど一部のパワーユーザからは絶大な支持を得る。
Chrome OS上のLinuxはProject Crostiniと呼ばれるプロジェクトの成果によりChrome OS上でLinuxの動作が可能となってきたが、これまでBeta版扱いだった。
正直に言って誰しもがChrome OS上で動作するLinuxは永遠にBeta版であろうと考えていたと思う。
結局は好きものなLinuxフリークのために用意してくれていたお遊びであって、GoogleとしてはProject Crostiniを本気で活用する気なんて無いのだと知った気になっていた。
なに、そもそもChrome OSもAndroidもLinuxベースOSだ。Linuxの上でLinuxを動かしているに過ぎないし、Googleはすでに我々へLinuxデバイスを多くリリースしてくれているではないか。高望みはいけないのだと諦めていた。
しかし違った！違ったのだ！GoogleはProject Crostiniへ本気だった！
ついに、ついに、ついに！家電量販店でLinuxデバイスがいつ行っても買える時代がやってきた！
Androidのように自身がLinuxディストリビューションであることを一般ユーザのために隠しているOSとは意味合いが全く違う。
むしろAndroid StudioをインストールしてAndroidアプリを開発するOSだ。足りないパッケージをAPTからインストールするLinuxディストリビューションとしてのOSなのだ。
あぁ何とでも言えば良い！
Chrome OSのLinuxレイヤーはChrome OS側のIMと連携できなくてLinuxレイヤーは独自にFcitxなどのIMを導入する必要があるって？
んなもん知っとるわ！それがどうしたぁ！！！
仮想環境であるLinuxレイヤーへKVMなどを導入しLinuxレイヤーを重ねて構築すると不安定になり全てのLinuxレイヤーが致命的に壊れることがあるって？
もうそんなことは何度も繰り返してんだよ！壊す前提で実験しとるわい！！！
バカにされたって罵られたってChrome OSのLinuxが正式版になったんだよ！！！
ありがとうLinuxフリーク！ありがとうお前ら！ありがとうGoogle！ありがとうドザー！ありがとうマカー！
flip coinと入れるとバーチャルのコインが出てきてフリップすることができる。
ありそうだなと思って試していま初めて知った
おやつはダブルチーズバーガーに決まったぞい。
自衛隊東京ワクチン接種web予約でGoogle Analytics使われてるけどプライバシー ポリシーも同意もない。
規約違反では？
（ただ、GDPRに違反してるだけで国内向けにはよいのかもしれない）
お客様はプライバシー ポリシーを公開し、そのプライバシー ポリシーで Cookie の使用、モバイル デバイスの識別情報（Android の広告識別子、iOS の広告識別子など）、またはデータの収集に使われる類似の技術について必ず通知するものとします。また、Google アナリティクスを使用していること、および Google アナリティクスでデータが収集、処理される仕組みについても開示する必要があります。
https://marketingplatform.google.com/about/analytics/terms/jp/
防衛省の案内にもない。
https://www.mod.go.jp/j/approach/defense/saigai/2020/covid/center.html
ここでも一時期叩かれてたけど、あれはブームだからそうしてただけでコインハイブもブラクラも許された？
兵庫県警ホームページ、利用者に告知なく導入していたGoogleアナリティクスを撤去
https://internet.watch.impress.co.jp/docs/yajiuma/1173873.html
いや「超短納期だから仕方ないだろ」とかはその通りで悪いのは発注側だと思うんだけどさ、「これでOKだろ」という擁護をする人のことね。
意味分かんない、これなんか問題なの? 俺も超短期でこういうシステム作るなら Google Forms でも使って似たようなシステム作ると思う。有効な番号だけ抽出して予約を有効にすればいいだけのことでしょ
https://b.hatena.ne.jp/entry/4702760208090559394/comment/KoshianX
え、システム側で勝手に予約を取り消すの？予約できましたってアナウンスしておいて？
接種券番号や生年月日を間違えて入力してしまった正当な予約を誰かが勝手に判断して取り消すわけ？
どうせ間違えた奴が悪いとか言うんだろうが、ITリテラシーの低い人が使うシステムでその言い訳は通らないよ。
リテラシー高くたって目が悪くて数字を見間違える人も高齢者には少なくない。明らかにおかしい予約以外は取り消せないことくらい想像できるだろ。
バリデーション処理を何でやるのかって、こういう事態を招かないためだろうが。
これ、そもそも仕様として厳密性が求められて無いのではというか、米国式の「細かいことは気にせずどんどか射つ。余りが出たら優先リストから呼び出してどんどか射つ」設計なんでは感がある。
https://b.hatena.ne.jp/entry/4702758110534634082/comment/ka-ka_xyz
クソ設計だけどな！
明らかに65歳以下の人が来てもどんどか打ってくれるんだよね？年齢なんて細かいことは気にしないよな！「接種券無くしました」もOKだよな！
テロの方法を指南する広報機関にでもなったのか？日本を潰すなら手段を選ばないって事なのか？これは全国民に周知しなければならないニュースなのか？報道するなら対策を待ってからでも良くないか？
https://b.hatena.ne.jp/entry/4702760208090559394/comment/Snail
昔のネットDE真実な人の主張って「マスコミは真実を報道しろ！」だったけど、最近は「マスコミは真実を報道するな！」も増えてきたよね。
