Google の企業向けソリューションに関する公式な情報やユーザーの事例などを、いち早く皆さんにお届けします。
![G Suite のご紹介 All together now.](https://cdn-ak-scissors.b.st-hatena.com/image/square/6571391198fcb45e4d7c5cab7d90e5ca2fbf4605/height=288;version=1;width=512/http%3A%2F%2F2.bp.blogspot.com%2F-7bZ5EziliZQ%2FVynIS9F7OAI%2FAAAAAAAASQ0%2FBJFntXCAntstZe6hQuo5KTrhi5Dyz9yHgCK4B%2Fs1600%2Fgooglelogo_color_200x200.png)
Google の企業向けソリューションに関する公式な情報やユーザーの事例などを、いち早く皆さんにお届けします。
QUIC(Quick UDP Internet Connections)プロトコルは、TCPではなくUDPをベースとして開発された、全く新しいWeb向けのプロトコルです。 (冗談で) TCP/2 と呼ぶ人までいます。 私がQUICについて知ったのは数週間前のことです。 SysCast Podcastのcurlとlibcurlについてのエピソード を聞いていた時でした。 QUICプロトコルの本当に面白い点は、UDPへの移行というところだと思います。 現在、Webの伝送プロトコルは、信頼性を確保するため、TCP上に構築されています。このTCP接続を開始するためには、 3wayハンドシェイク が行われています。つまりこれは、接続を開始するたびにラウンドトリップ (ネットワークパケットの往復) が追加されるということであり、新たな接続先に対し大幅な遅延を生じさせているのです。 (出典: UDPを介
Googleさんが発表したモバイル端末での表示高速化のAMP HTMLに対応してみたよ、という話です。 Introducing the Accelerated Mobile Pages Project, for a faster, open mobile web 概要などは上記見てもらえれば感じはつかめると思いますし、日本語で紹介してる記事だとKenichi Suzukiさんの紹介記事を見ると分かるかと思います。 なぜやってみようかと思ったかというと、「javascriptが無い静的なHTMLとCSSのページは爆速で表示したるで!」というGoogleさんの粋な計らいかと勘違いし、ほとんどが静的なページであるこのブログもサクーっと対応できたりするんじゃね、と思ったからですが、ちょっと苦労しました。 なおブログを完全に対応させたのではなく、記事ページのみ別にAMP HTML用の記事を出力してい
Googleが、太古のディストリビューションであるRed Hat 7.1から、10年新しいDebianベースのディストリビューションへ、ライブアップグレードした話を紹介する。 そのあと、自分の身の回りの環境と比較し、参考にすべきポイントを考察する。 原文は USENIX LISA の投稿論文だ。しかし、中身は論文体というよりは、事例の紹介といった適切かもしれない。 MERLIN, M. Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One. In Proceedings of the 27th conference on Large Installation System Administration (LISA) (2013),
Google Compute Engine、全世界のリージョンが同時に外部とのネットワーク接続を失うという深刻な障害が発生。ネットワーク管理ソフトウェアにバグ クラウドのどこかで障害や災害が発生したとしても、その影響はアベイラビリティゾーンを超えることはなく、そのために複数のアベイラビリティゾーン(Google Compute Engineでは「ゾーン」)にシステムを分散して配置することで、クラウドの障害の影響を受けない高い可用性を備えたシステム構築ができる。これはクラウド(IaaS)に対応したシステム構築におけるもっとも基本的な考え方です。 しかし先週、2016年4月11日にGoogle Compute Engineで発生した通信障害は、アベイラビリティゾーンどころかリージョンの境界も越え、世界中にあるすべてのリージョンのインスタンスが同時に外部とのネットワーク接続を18分間に渡って失う
最終更新日:2018/3/6 こんにちは、小西です。 これまで紹介してきたGoogle App Engine(GAE)ですが、無料枠が大きいとはいえ、ちょっと重い処理があるときにリクエストが立て続けに来ると、すぐに2台以上インスタンス起動してしまいます。 インスタンス時間の無料枠は28時間なので、この範囲内で抑えることが重要です。 先月、月間50万PVほどあるサイトをGAEに移行し、1ヶ月ほど無料で運用することができたので、その際にやったことをお伝えします。 PHPで試したものですが、基本的にはPython, Go, Javaの場合も同じはずです。*1 GAEってなんじゃ?という方はまずはこちらをどうぞ: さくっとPHPでサイト作るならGoogle App Engineが最高 - koni blog Node.jsの方は無料で使えないみたいです。詳しくは一番下。 何に課金されるのか 完全無
前編(「ビッグデータは“リアルタイム”でこそ価値がある」)では、リアルタイムなビッグデータ解析プロジェクト「CET(Capture EveryThing)」が始まったきっかけから、いまのチームまで組織に焦点を当てました。 後編では、いよいよビッグデータ解析のシステムについて深掘りしていきます。 Amazonのクラウドサービスを活用して作り上げた現状のシステムを捨て、Googleで作る構成に変えようとしているそう。その意図とは。 クラウドサービスのコストパフォーマンスなど、エンジニアやアーキテクトには気になる情報が満載です。 「CET」で基盤構築や分析・集計アプリケーションの開発を行っている、吉田啓二さんに聞きました。 聞き手/構成/編集/写真:小川楓太(NEWPEACE Inc.) AWSで本格的に運用するのは厳しいかなという印象です —— 今回構築された基盤の具体的なシステム構成はどのよ
某ストアで総計8万本ほどの有料アプリを販売していたアプリ作者です。 (4年ほど掛けて、5本ほどの有料アプリで、総計8万ダウンロードして頂いた、という意味です) 他のアプリクリエイターの皆様の危機回避の為にも、事の仔細を記します。 皆様はどうか同じ轍を踏まず、私の屍を踏み台にして下さい。 本文章には、主観や推測も含みます(先方から的確な原因を明示されない為) 特定の誰かを貶めたりする事が目的ではなく、皆様への情報提供(注意喚起)を目的としています。 考え違いや、筆者の読解力・文章力によってミスがあるかもしれませんが、ノンフクションです。 間違いや問題のある個所は、順次修正致します。 ある朝、デベロッパーアカウントが死にました。 早朝4時の5通立て続けのメール。 4つのアプリの規約違反とアカウント停止を告げるメールでした。 [1通目]『AnimationPuzzle』に露骨な性的表現 [2通目
Bootstrapの見慣れた感というか、モック感から脱却しようとFoundationとかに手を出しかけてたのですが、Googleがだしてきたマテリアルデザインキットがすごく良かったので紹介します。 たとえば管理画面風のデザインはこれ ほかにもBootstrap風の上部メニューのデザイン(Android)もあったり コンポーネントと呼ばれる部品も充実しています。これ見るだけで色々できそうな気がしますね! Blog風など幾つか提供されています。いまとあるサイドプロジェクトで簡易的な管理画面をつくろうとしてたのですが、早速活用していい感じに仕上げることが出来ました。 ダウンロードすると全テンプレートが含まれているので、コピペで組み合わせるだけでも結構いい感じに出来ます。Bootstrapに飽きてきたら、ぜひ使ってみてください。 www.getmdl.io
Googleが、ローカルベースのプロトタイピングツールPixateを買収した模様。以後、Pixateアプリは無料となり引き続き開発が続けられるようです。 2013年頃、Pixateに$600払ってた俺は泣いた。おめでとうございます。 Invisionを主流に百花繚乱の分断化で割と困っていたプロトタイピング業界。Googleがこの分野に手を出したことで変動は起きるのだろうか。 これがプロトタイピングツールの決定版になるとよいですね。高性能だし無料だし。クラウド版も$5だし。 日本でプロトタイピングサービスばパッとしない究極の問題は、サービスがオンラインのことなんですよね。SI系の人たちは「セキュリティ的な事情でオンラインの共有サービスを使えない」という事情がありました。Pixateはローカルアプリなので、その辺の心配をする必要がないのがポイントですね。そのうち大手SIとかでもこういうツールが
最近業務でgoogle docsやExcelで管理されたシートの内容を集計したいことがあって、基本google docsのスプレッドシートでゴニョゴニョすることがあるのですが、例えば の様なものがあって、上の例だと各ユーザのポイントの合計を集計したいなと考えた時にExcelに慣れている方だとExcelの関数が浮かんで集計できるのかと思うのですが自分だとSQL文のイメージが先に出るのでよしなにできないかなと思っていたら、Google docsだと QUERY という関数を使うことで実現できることを知ったのでメモエントリです。 上の例だと D1 のセルに以下の様な内容を記述します。 =query(A2:B9, "select A, sum(B) group by A") 1番目の引数にデータの範囲を指定し、2番目にそのデータ範囲でのクエリを記述します。 SQLを触ったことがある方ならなんとなく
異動してみた。Chrome と関係ない Android アプリのチームへ。 モバイルに詳しくなろうと余暇にちまちまコードを書いてみたもののまったく捗らない。いっそ仕事にしてみようという次第。座席の引越しから数日、よろよろしながらもやっと初コミットできた。めでたい。 Work Rules という本がある。 Googleの人事(People Ops)のボスによる Google の本で、人事制度を中心に企業文化やシステムを紹介している。 いまいち時代背景が不透明な How Google Works と違い大企業としての Google をうまく描いている。興味深く読んだ。 中でも三つの論点が印象に残った。透明性、自由、そして管理職の権威を削ぐこと。異動の支度をしながら読むと説得力がある。一例として様子を書いてみたい。 Google のエンジニアリング部門は、たまの異動を薦めている。いろいろ経験して
Google、1GB当たり1セントながら3秒以内にデータ取得できるニアラインストレージ「Cloud Storage Nearline」提供開始 一般にITのシステムおいてストレージはシステム全体の性能を左右する重要なコンポーネントであるため、高性能なSASドライブやSANストレージ、最近ではフラッシュストレージなどが多く用いられます。 こうした性能重視のストレージは一般にオンラインストレージ、あるいはプライマリストレージなどと呼ばれますが、これに対してバックアップ用途や、容量あたりのコストなどを重視したストレージを「ニアラインストレージ」と呼びます。低価格なSATAハードディスクなどを用いたストレージなどがこれに相当します。 長期保存やアーカイブが主目的となり、光学ディスクや磁気テープのように読み出し時にメディアを交換したりマウントするようなストレージのことを「オフラインストレージ」と呼び
何やら Google が経路を切り替えた様子。 リアルタイムで traceroute を楽しく叩いてたコンソールが残っていたので、晒し上げておきます。(誰も困らないし) 以下 2コマンドを叩いた時間差は数十秒程度ですが正確には不明。オフィスは gate02 を引いています。 事の発端 まず NTT の海底ファイバーから KDDI の海底ファイバーに切り替わった。 KDDI のときに ^C 叩いてしまったのが若干残念。 halfrack@halfrack>traceroute www.google.co.jp ~ traceroute: Warning: www.google.co.jp has multiple addresses; using 74.125.153.103 traceroute to www.l.google.com (74.125.153.103), 64 hops m
そもそもGoogle Compute Engineのロードバランサー、GCE LBは、1インスタンス・1グローバルIP・ウォームアップなしでいきなり100万リクエスト/秒を捌けてしまう謎性能を備えていて、既存の他社クラウドのLBだけこれで置き換えたい! という声もちらほら聞かれるほどの強力LBサービスであった。 From Compute Engine Load Balancing hits 1 million requests per second! そして今回、正式公開ではないLimited Preview版ではあるものの、GCE LBの新機能としてHTTP Load Balancingが発表された。その性能と機能の破壊力があり過ぎるので、GCPブログ記事のリンクをシェアするだけではあまりにもったいない! と思い、要点を訳してみた。 DNSに頼らない、1グローバルIPによるUS、EU、A
[対象: 全員] Googleは数年間から、状況に応じて、HTMLのtitleタグの記述ではないタイトルを検索結果に表示するようになりました。 どのように書き換えるかはアルゴリズムによって完全に自動化されています。 タイトル修正が発生しやすい状況をGoogleは説明していますが、アルゴリズムはその後も絶えず改善されています。 現状はどのようになっているのでしょうか? GoogleのMatt Cutts(マット・カッツ)氏が説明しました。 検索結果のタイトルをGoogleはどのように選んでいるのか 基本的に、タイトルを選んだり検索結果にどのタイトルを表示しようか決めたりしようとするときは、検索クエリに関連性があって簡潔な記述かどうかも常に見ている。 僕らが見ている基準はいくつかある。 比較的短いかどうか そのページのことをよく説明できているかどうか。そのページがあるサイトのことも説明できてい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く