ただつらつらと日記が書かれていくようです。

タグ: Google (1ページ目 (2ページ中))

Google Driveのショートカットが消せない。

誰かから共有してもらっているGoogle Drive上にあるショートカットが削除できない(そのフォルダに対しては編集権限があるはずなのに…)。んで、なんだかイライラして検索してたら、Reddit経由でGoogleのCommunityにたどり着いた。

Cannot remove shortcut from Shared With Me

なんだかよくわからんけれど、書いてあるとおりに、消せないショートカットをマイドライブに移動させて削除したら、あっさり消せた。うーむ、仕組みがよくわからんけど、とりあえず消せたからいいか。ただ、きっとまたいつか同じことで困るんだろうな。

というわけで、Geminiに聞いてみたら。

Googleドライブには、以下のような独自のルールがあります。
「他のユーザーが所有しているフォルダ内にある『ショートカット』は、そのフォルダのオーナー(所有者)しか削除できない」

とのこと。つまり、ショートカットをマイドライブに移した時点で、ショートカットのオーナーが私に変わるので、私が削除できるようになるという仕組みなんだろう。

ただ、編集権限があればファイルは消せるにも関わらず、ショートカットが削除できないというのは違和感がある。なんでと思ったら、こういう回答をもらった。

共有フォルダ内で他人の「実ファイル」を削除(ゴミ箱へ移動)した際、実はそのファイル自体は完全に消滅しているわけではありません。 システム上は「その共有フォルダから切り離された」だけで、ファイル自体は作成者のマイドライブ(一番上の階層)にひっそりと戻り、保管され続ける仕組みになっています。一方で「ショートカット」は、それ自体がそもそも「リンク(別の場所への橋渡し)」です。「実ファイルをフォルダから切り離す」ことはできても、「リンク(ショートカット)をフォルダから切り離す」という処理は、Googleドライブのデータベース上で『迷子のリンク』を生み出してしまい、エラーや矛盾を引き起こしやすい構造になっていました。そのため、システム側で一律に「他人のフォルダ内にあるショートカットの削除操作をブロックする」という乱暴な制限をかけていると考えられます。

しかも、Geminiによれば、共有ドライブ上では編集権限があればショートカットを削除できるらしく、昔からある共有フォルダ上のショートカットは消せないという…違和感しかない仕様になっているようだ。難しい。。。

いつの間にか、Googleがスピードテストを実装していた。

Googleで「スピードテスト」を検索したら、いつの間にかGoogleがネットワークの帯域幅を測定する機能を実装していたようで。GoogleとMeasurement Lab(M-Lab)の提携で実現しているようだ。40MB程度のようだけど、ある程度のサイズのデータをサーバーとやりとりして計測するのは、他の計測サービスと同じのようだ。ま、他のサービスだと、flashが必須だったりするけど、このGoogleのサービスはflash不要らしい。手軽に計れていいな、と。

GoogleBookmarksでリダイレクトの嵐

GoogleBookmarksにとあるサイトのURLを入れていて、アクセスしようとしたらリダイレクトの嵐…。うーむ、Googleにはログインしてあるのになんか変だなー。

めまぐるしく、くるくる変わるURLを眺めていると、sidというパラメータをどうにかしようとしているようで…。というわけで、ブラウザのCookieの管理画面を引っ張り出して、google.comのCookieの中で「SID」ってパラメータがあったので、それを削除。改めて、Google Bookmarksにアクセスすると無事にアクセスできた。なんとなーくバグっぽい動きをしているあたり、最近のGoogleでは珍しい気もするけど、とりあえず回避できたからいいや。

いつの間にか、GoogleのPublic NTPがstratum1になってた。

ちょっと前、GoogleがPublic DNSに加えて、Google Public NTPをリリースしていた。しばらくの間はtime1.google.com
などはstratum2のサーバとして動いていたと思うが、さっき確認したら、stratum1のサーバ群になってた。

日本国内のLinuxマシンから、time4.google.comを指定してntpdを動かした時の、ntpq -pの結果がこんな感じ。

remote refid st t when poll reach delay offset jitter
==============================================================================
time4.google.co .GOOG. 1 u 5 64 1 35.928 -0.607 0.000

ソースの「.GOOG.」ってなんだろうって感じではあるが、一応、stratum1らしい。ネットワークのdelay的には、台湾あたりのサーバっぽいなという感じだけど、はてさて。

GoogleMaps APIの課金が始まったか…

Googleからメールが来ていた。

On October 12, 2016 we will begin enforcing the Google Maps APIs Standard Plan policy updates that were announced in June. Starting October 12th, your website will generate charges if requesting more than 25,000 daily map loads for an API.

雑に訳すと、こんな感じだろうか。

2016年の10月12日から、Google Maps API Standard Planのポリシーの更新を強制します。この更新自体は6月にアナウンスしたものです。10月12日以降は、1日あたり25,000回を越えたリクエストについては課金されます。

というわけで、一日あたり25,000回を越えたAPIの呼び出しについては、1000回あたり$0.5の課金が行われるようですな。…というか、これを強制するってコトは、APIキーを付けていない呼び出しはブロックされるってことだろうなぁ。Googleが細かい制御をどこまでやるかはわからないけれど、APIの呼び出し回数は無料の範囲内で収まっていても、APIキーを貼ってなくて、GoogleMapが表示されないってことが普通に起こりそうな予感…(遠い目)

Gmailから、さくらインターネットのレンタルサーバ経由でメールが送れなくなった。

仕事でさくらインターネットのレンタルサーバを使っている。それも、メールサーバとして使っていて、POPでメールを取りに行くし、SMTPでメールを送っている。ただ、さくらインターネットのレンタルサーバのサービスとして用意されているWebメールは使い勝手がいまいちなので、Gmailと連携させて使っていて、特に、Gmailからメールを送る際には、借りているさくらインターネットのサーバを経由して送信する設定にしていた。

んで、昨日。社内から「Gmailからメールを送れない」という調査依頼がやってきた。昨日まで、普通にGmailからさくらインターネットのレンタルサーバ経由でメールを遅れていたのに、突然、メールが送れなくなったらしい。Gmailに帰って来たエラーメッセージはこんな感じ。

The error that the other server returned was:

550 5.7.1 <XXXX.XXXX.co.jp(送信先のメールアドレス)>… Command rejected

…Command rejectedって…。レンタルサーバのコントロールパネルから調べてみたら、「国外IPアドレスフィルタ」って設定項目が増えていて、それがOnになっていることに気がついた。要は、国外のIPアドレスをブロックする新機能が追加され、デフォルトでOnらしい。

で、「国外IPアドレスフィルタ」について調べてみたら、SMTPも対象になっているらしいので、とりあえず、Offにしたら、正常な状態に復旧した。

つまり、Gmailのサーバがどこにあるかはよくわからないとしても、国内にはない可能性が高く、この「国外IPアドレスフィルタ」に引っかかっていたようだ。

さくらインターネットが海外からのDDoSに悩まされている雰囲気はあって、ユーザーとして協力したい気もするけど、こういう形で影響が出るとなると、ユーザーとしてはOffにせざるを得ない…うーむ。

Google MapsのAPI v2が、ちょっと遅延して(?)終了した模様

Googleのdeveloper向けのページでは、ばっちりとサポート終了って書いてあったけど、日本時間の2013年11月18日には終わらなかったように見えた、GoogleMaps API v2だけど、11月20日になって思い出したように終了したっぽい。GoogleMaps API v2で書かれた地図をそのままにしてあったページで地図の部分が真っ白になっているのを確認できた。

一応、Googleとしては

この日以降は V2 を使っている地図は、下位互換機能を持たせた V3 の地図に自動的に切り替わる予定です。この下位互換機能により、大部分のシンプルな地図は機能すると考えますが、この日以前に V3 へ移行を完了することを強く推奨いたします

って書いてはあったけど、シンプルな地図ってどういうものか書かれていないので、妙な期待感を漂わせてしまったような気がする。んで、結果的には、今日になって地図部分が真っ白になっているサイトを増やしているんじゃないだろうか。…まぁ、Googleが責められる話ではないけれど。

タダでAPIを使えて、簡単に地図をWebサイトに貼り付けられるってことでGoogleMap APIを使ったWebサイトは数あれど、このv2のEOLに際して、ちゃんと改修できたサイトってどれくらいあるんだろう。

まぁ、Web系の会社がやるとしても、カットオーバーから何年も経ったサイトのGoogleMapのAPI移行なんて、ほいほいと受けるんだろうか。(さらには、その制作会社が存続しているんだろうかというシビアな話もあるだろうけど)おそらくは割増料金になってしまうんだろうし、顧客によっては今日、明日になって「あ、地図が出てない!」ってことに気がつくところから始まるところも少なくないだろうし。

いかに便利で手軽で無料であるとはいえ、Webサイトの構成要素の継続性をコントロールできないのであれば、それを前提にメンテナンス性を確保する仕組みを作っておくしかないという当たり前なことを、改めてGoogleMap API v2のEOLが気づかせてくれたような気がする。金を払う必要もなく、手もかからないような魔法みたいな仕組みは、あり得ないってことだろう。

Google Readerが終了とな。

Google Readerが7月でサービスを終了するらしい。最近、PulseをフロントエンドにしてGoogle Readerを使ってたのに、ここに来てのサービス終了は本当に残念な気がする。

そういえば、iGoogleもサービス終了だったなぁ。Google Readerよりも猶予期間が長いのは、iGoogleの方がユーザーが多いってことだろうか。

iGoogleにしても、Google Readerにしても、ユーザーは(グローバルで見ても)それなりにいるような印象だが、バッサリと切るのは、さすがGoogleという印象は少なからずあるような気がする。

いずれのサービスとも、それ単体でAdSenseを張り付けまくるという感じでもなかったことから、広告スペースの創出による利益と言うよりは、もっと儲けられる可能性のあるサービスをアシストするような、サポートサービスとしての印象の方が強い。

例えば、iGoogleはgmailと組み合わせて使うと便利だし、Google Readerは、blog黎明期にはPVを稼ぐことができただろうし、その後、SNSが流行った頃には初期のGoogle+において、コンテンツの投入元としての機能を期待されたかもしれない。

いずれにせよ、時代はスマートフォンだ。人々がgmailをチェックするのも、SNSにアクセスするのもスマートフォンから行うようになった。コンテンツ間の関係は、スマートフォンアプリの関係で代替され、確かに、上記のようなサポートコンテンツは役割を終えた感はある。

ただ、そんなGoogleの思惑とは別に、使う側は使う側の論理で動いている。

例えば、スマートフォン全盛期でも、bloggerは、相変わらず、blogを書いているわけだから、エントリーを効率よく読みたい人たちがいる。しかも、只でさえスマートフォンユーザーはバッテリーで悩む機会が少なくないわけだから、スマートフォン単体でRSSを定期的に取得するというのは賢明ではない。RSSを定期的に取得してAPIを公開してくれる、Google Readerには一定の価値がありそうだ。だからといって、例えば、Google Readerを有料化して採算ラインに乗るかどうかと、ユーザーの思いとは必ずしもマッチしないわけだから、なかなか悩ましい。

«過去の 投稿