仕事を説明するときに「Googleで仕事をしているけどオープンソースなのでGoogleのプロダクトを作っているわけではないし、むしろアップルとかソニーの人と一緒に仕事している」というと、???という反応になることが多いので、こういう仕事をしているんだよということをちょっと説明してみます。...
(7/7追記)僕は斜め読みだったんですが、もっときちんと読んだ上で解釈を書いてくれている方がいます。僕も時間をとって全文を読みたいとは思っていますが、まだ時間がかかりますし、yudaiさんの会社の方が妥当性は高いと思いますので、そちらをご参照ください↓ 朝っぱらから色々衝撃が走った第一四半期の最終日ですが、OracleとGoogleの裁判について、どのあたりが問題だったとされるのか気になるので判決文等を読んでみました。 経緯 2010年8月、OracleはGoogleを訴える。当初の争点は特許侵害 (publicKey1) 2012年4月、サンフランシスコ連邦地裁の法廷開始 2012年5月、Googleの特許侵害はないとの陪審評決。ただし、フェアユースは意見が別れる。 2012年6月: Oracle対GoogleのJava/Android訴訟、損害賠償金ゼロで合意。今回議論された37件のJ
The InfoQ Trends Reports 2023 eMag The InfoQ trends reports provide a snapshot of emerging software technology and ideas. We create the reports and accompanying graphs to aid software engineers and architects in evaluating what trends may help them design and build better software. Our editorial teams also use them to help focus our content on innovator and early adopter trends.
Google、大規模データをリアルタイムに分析できるクラウドサービス「Google Cloud Dataflow」を発表。「1年前からMapReduceは使っていない」。Google I/O 2014 大規模分散処理のフレームワークとしてGoogleが開発し、Hadoopに採用されて広く使われているMapReduce。しかしGoogleはもうMapReduceを使わず、より優れた処理系の「Google Cloud Dataflow」を使っていることが、Google I/O 2014の基調講演で明らかにされました。 GoogleのシニアバイスプレジデントUrs Hölzle氏は、「エクサバイトのスケールまで扱え、パイプライン処理を記述しやすく最適化もしてくれる。それにバッチもリアルタイム分析も同じコードで記述できる」と、Cloud Dataflowの特長を説明します。 Google I/Oの
「BigQueryは120億行を5秒でフルスキャン可能」は本当か? 先日、kaheiさんがGoogle BigQuery(Googleクラウドの大規模クエリサービス)について、こんなエントリを書いていた。 とにかくパフォーマンスがすごい。(Fluentd Meetupでの)プレゼン中のデモで、ディスクに収められた5億件のデータをSQLでフルスキャンするのに3秒しかかからない。9億件のデータを正規表現を含んだSQLでスキャンしても、7秒で終わる(これ、記憶がちょっとあいまい。もう少しかかったかも)。これには驚いた。佐藤さんがGoogleに入社して一番驚いた技術が、一般公開される前のBigQueryだったと言っていたが、その気持ちはわかる。 From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluent
GoogleのSVP、Urs Hoelzleが「いま世界でもっとも人気のあるスマートフォンアプリ」と評し、Facebookによる3000億円の買収提案をスルーしたとされるSnapchat。その共同設立者でCTOのBobby Murphyが、3/25に開催されたGoogle Cloud Platform Liveに登場し、“Snapchatを支える技術”としてのGoogle Cloud Platform (GCP)の使い所や開発体制をかなり具体的に説明していたので、補足と解説を交えながらざっと意訳してみた。 SnapchatのCTO, Bobby Murphyと、GoogleのSVP, Urs Hoelzle From Google Cloud Platform Live SnapchatがGoogle App Engineを選んだ理由 "それまでいくつかの小さなプロジェクトでGoogle
Google では、オンライン ユーザーの利便性向上のために、さまざまな取り組みを行っています。近年、パソコン ユーザーの権利がますます軽視される傾向にあることに、深い懸念を感じています。スパイウェア、ポップアップ広告、アクセスしたサイトから異なるサイトへの強制誘導などを行うアプリケーションなどに関する問題が日々報告されています。 このような傾向は衰える気配を見せません。それどころか、悪化の一途をたどっています。インターネットのユーザー、広告主様、サイト運営者様にサービスと収益実現を提供する企業として、Google はこの問題に率先して取り組む責任を感じています。Google は、業界全体で取り入れるべきと考える一連の原則を掲げています。Google 自身も、配布するアプリケーションの開発にあたってはこのガイドラインに従うよう努めています。Google は、この原則が業界と世界中のユーザー
Google’s Compute Engine Hits General Availability, Drops Instance Prices 10%, Adds 16-Core Instances & Docker Support Google today announced the general availability of the Google Compute Engine, the cloud computing platform it launched in the summer of 2012. As part of the GA launch, Google also announced expanded support for new operating systems, a 10 percent drop in pricing for standard instan
An Indian court has dismissed Twitter’s lawsuit against the Indian government that sought to challenge New Delhi’s block orders on tweets and accounts. The Karnataka High Court dismissed t Seoul-based e-commerce company Levit, an operator of the shopping app Alwayz, wants to make the shopping experience more entertaining and affordable. The two-year-old startup has recently raised $46 m
グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。 そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。 そのバグ予測アルゴリズムとはどんなものなのか。Google Engineering Toolsブログに投稿されたエントリ「Bug Prediction at Google」(グーグルにおけるバグ予測)で説明されています。 ソースコードの修正履歴を基に予測 コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。これはコードを静的に分析して、
Play framework with Scala を使ってみようシリーズです。 その1 その2 その3 その4 その5 先日、Play! 1.1.1 がリリースされました。 今回のリリースはバグフィックスとのことですので、大きな機能追加はないようです。 開発者MLによると、3月に1.2のリリースを予定しているという話がありました。 さて、今回はPlay! on GAE with ScalaでMemcacheを使ってみます。 Play!には標準でキャッシュのためのAPIが備わっていますが、GAEモジュールを利用することでGAEのmemcacheにデータをキャッシュすることができます。 今回のサンプルのソースは https://github.com/ueshin/play-hello/tree/play-hello-0.0.4 でブラウズできます。 Play!本体とsienaモジュールをアッ
AppEngineは、アクセスがあったときにアプリケーションを起動し、しばらくアクセスが無ければアプリケーションを終了させ、また次のリクエストで再起動するという仕組みを導入しています。 そのため、アプリケーションを起動(spin-up)する時間がとても重要になってきます。このspin-upの時間はpython(webapp)で60cpu_ms以下。(cpu_msはcpuが使う仮想的な時間ですがmsと同じ感じで捉えてもらってもとりあえずは大丈夫です)JavaのServletだと600cpu_msくらいです。PythonでもDjangoような大きなフレームワークだと1000cpu_msくらい(アプリによる)かかりますが、許容範囲内。JavaだとSlim3で1300cpu_ms、Springだと早くて7000cpu_msという感じで、Slim3がギリギリ許容範囲内でしょうか。ほんとうは、1000
AppEngineは、万能なプラットフォームではありません。むしろ、かなり使い道は限定されていると言ってもいいでしょう。 向いていないアプリで使うとかなりはまって、アプリが完成しないリスクがあります。 一方、向いているアプリで使うとこれまでよりかなり費用を節約できたりとか、儲けにつなげることができます。 AppEngineにどのようなアプリが向いているかというと、AppEngineがGoogleの既存のインフラをそのまま利用していることをまず知っておく必要があります。 Googleのインフラは、(極端に単純化すると)大量のデータを多くの人に同時に見せるために最適化されています。 AppEngineも同様で、大量のデータに大量にアクセスがあっても大丈夫なように、BigtableというKVSを使っています。また、自動でスケールアウトするWebのFront Endも既存のインフラをそのまま使って
「EXILEはクラウド!」 ではなく、appengine ja night #6 Beer Talk : ATNDで発表した内容です。 Slim3をScalaで動かすためのブランクプロジェクトと、ScalaのController/Serviceを生成するSlim3-gen-scalaを作りました。 yuroyoro/slim3-scala-blank · GitHub yuroyoro/slim3-gen-scala · GitHub slim3をscalaで動かしてみたView more presentations from guest16d8e4. 特徴 ScalaでSlim3が動きます。 ScalaのController/Serviceを生成できます。 EntityはJavaで作成しますが、Scalaから問題なく使えます。 テストはSpecsで書けます。( specs - a BDD
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く