こんにちは。プロダクト開発チームの松田(id:a-matsuda)です。 今回は、プロダクト開発チームで行っているスクラムMTGに【Lean Coffee (リーンコーヒー)】を導入している様子をレポートします!! スクラムMTGとは プロダクト横断で、プロダクトマネージャー(以下PM)とスクラムマスター(以下SM)が集まり、スクラムの課題や悩みをシェアしながら解を見つけていく、私たちオリジナルのミーティングで、PMやSMの心の拠り所にもなっているイベントです。 Lean Coffee (リーンコーヒー)とは 皆さん、聞いたことはありますでしょうか?コーヒーの飲み方(ウィンナコーヒー的な)と思ったそこのあなたと私、そうではありませんよ!笑 ミーティングというと、実施前にがっつり準備をし、実施後には議事録を作成して配布、そんな習慣がある方も多いのではないでしょうか。 対して、Lean Cof
メルカリで写真検索とEdge AIチームに所属している澁井(しぶい)です。機械学習のモデルを本番サービスに組み込むための設計やワークフローをパターンにして公開しました。 GithubでOSSとして公開しているので、興味ある方はぜひご笑覧ください! PRやIssueも受け付けています。私の作ったパターン以外にも、有用なパターンやアンチパターンがあれば共有してみてください! GitHub:https://github.com/mercari/ml-system-design-pattern GitHub Pages:https://mercari.github.io/ml-system-design-pattern/README_ja.html なぜ機械学習システムのデザインパターンが必要なのか 機械学習モデルが価値を発揮するためには本番サービスや社内システムで利用される必要があります。そのた
米Googleは4月20日(現地時間)、新型コロナウイルス感染症対策で企業が従業員のリモートワーク化を進める中、リモートからイントラネット内のWebアプリに安全にアクセスするためのシステム「BeyondCorp Remote Access」のGoogle Cloudユーザーへの提供を開始したと発表した。 Google Cloudのコンテキストアウェア アクセス ソリューションを使用すると、ほぼすべての組織で有効にできる。 BeyondCorp Remote Accessは、VPNを使わずに従業員が「信頼できないネットワーク」を通じて働けるようにするGoogle社内のイニシアチブとして約10年前に始まった、ゼロトラストアプローチに基づくクラウドソリューション。現在ほとんどのGoogle従業員が日常的に使っている。 ユーザーのIDとコンテキスト(アクセスしようとしている端末のセキュリティステー
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
This is the place to be if you're trying to participate in a live poll
Yusaku Watanabe has worked in software engineering roles since 2006, primarily focusing on reactive systems. He was a product manager at CyberAgent Singapore from 2006 to 2017, where he helped build out several demand-side platforms and supply-side platforms. Watanabe advocates an approach called "Reactive Management" which emphasizes responsiveness, resilience, and elasticity through practices li
米Appleと米Googleは4月10日(現地時間)、新型コロナウイルス感染症(COVID-19)の感染拡大を防止するため、Bluetoothを活用して感染者と濃厚接触した可能性を検出する技術の開発で協力すると発表した。 まずはiOSとAndroidとの間で、感染者の移動経路などに関するデータを相互にやりとりできるAPIを5月にリリースする。各国の公衆衛生当局が公式アプリ(iOS/Android)に組み込むことで、濃厚接触の可能性を検出する機能を提供できるようになる。 Googleが公開した技術資料によれば、アプリの使い方はこうだ。COVID-19の検査で陽性反応が出たユーザーは自身で感染したことをアプリに入力する。すると過去数日間に接近したユーザーに通知が届く。感染した人の名前や接触した場所は他のユーザーに知らされず、AppleやGoogleにも特定できない仕組み。 数カ月以内には、2社
Google Cloudの主要サービスが10時間ものあいだ障害発生。原因は分散アクセスコントロールへの大量の変更要求が引き起こしたメモリ不足 Google Cloudは、米国太平洋時間の3月26日木曜日16時50分(日本時間27日金曜日 午前8時50分)頃から約10時間ほどのあいだ、Google Compute EngineやCloud Storage、Cloud SQLなどをはじめとする主要なサービスで障害を起こしていました。 受けた影響はリージョンごとに異なりますが、ほぼすべてのリージョンで何らかの影響を受けたようです。 Googleはその原因についての調査結果を発表。原因はGoogle Cloud内部でアクセスコントロールを司る部分に障害が発生したことだったと説明しました。 アイデンティティマネジメントへの大量の更新要求がキャッシュサーバの障害に クラウド内部では、APIへのアクセス
※この投稿は米国時間 2020 年 3 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。 データは常に、公衆衛生上の緊急事態に対する調査や研究、取り組みにおいて重要な役割を果たしますが、世界的な危機の発生時にこそ、その真価が発揮されるといえるのではないでしょうか。研究プロセスにとって、データセットへのアクセスやそのデータをクラウド規模で分析できるツールは、切り離すことのできない重要なものですが、とりわけ COVID-19(新型コロナウイルス感染症)への対応にあたっては、その必要性がグローバル規模で高まっています。 Google Cloud では、研究者、データ サイエンティスト、アナリストが COVID-19 に対抗するための取り組みを支援するために、Johns Hopkins Center for Systems Science and Engineeri
既報のように、こないだから、ここ十年来のプロジェクトであるJenkinsを離れて、新しい事業Launchableを起こしています。ソフトウェア開発者の生産性を上げたい、もっとデータと機械学習を使って、開発者の外骨格である自動化されたプロセス達が効率よく、頭良く実行されるようにしたい、そういう思いを持って取り組んでいます。おかげで、お金もちゃんと集まったし、全米各地の優秀な人達を集めたチームを作ることが出来たし、お客さんも開拓されつつあるし、t_wadaさんにも「強いシンパシーを感じる」とまで言ってもらって、心を強くしています。 デブサミ登壇後は控室で @kohsukekawa さんとずっと議論していた。川口さんの新しいプロダクトに役立つかもしれないアイデアをいろいろと話せてとても充実した時間だった。技術カンファレンスは廊下や控室での対話にも大きな価値がある。 #devsumi — Taku
分散コンピューティング技術を使った医療研究プロジェクト「Folding@home」はこのほど、新型コロナウイルス感染症(COVID-19)の解析に対応したと発表した。専用ソフトをPCにインストールして起動すると、CPUやGPUの処理能力を使って解析に参加できる。 Folding@homeは米スタンフォード大学を中心としたタンパク質構造解析のための分散コンピューティングプロジェクト。ネット接続された世界中のコンピュータの処理能力を集めて巨大なスーパーコンピュータを形成し、アルツハイマー病、がん、パーキンソン病などの治療に関する解析やシミュレーションに活用している。専用ソフトの対応OSはWindows、macOS、Linuxなど。
インテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 今回は レッドハットのシニアアーキテクトである Eric Murphy さんによる「マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ(CDC)」の翻訳記事です。この記事では、イベントソーシング、CDC、CDC + Outboxパターン、CQRSをそれぞれ簡単に説明しながら、それらの特性の違いを比較します。また、イベントソーシングとCQRSの簡易な説明がなされている他、あまり明確に語られることが少ないもののソフトウェアの設計に大きな影響をおよぼすドメインイベントとチェンジイベントの違いにも触れられています。 [原文] Distributed Data for Microservices — Event Sourcing vs. Change Data Captur
a definition of this new architectural term The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated depl
こんにちは。Synergy! 開発チームの松本です。 以前の記事でも少し触れたのですが、当社シナジーマーケティングのプロダクトである Synergy! は、2015 年以前に作られたモノリスと、それ以降に作られたマイクロサービスのハイブリッド型として稼働しています。 この数年、マイクロサービスを実践してきてつくづく感じているのは、全てのチームがマイクロサービスアーキテクチャスタイルの本質を理解した上で開発や運用を行うということの難しさです。「分散されたモノリス」なんていう話も聞きますが、これもやはり、本質を理解しないままマイクロサービスを実践した例です。 2014 年に書かれた martinfowler.com の記事 "Microservices" は、マイクロサービスアーキテクチャを 9 つの特性に分解してその本質を述べた素晴らしいドキュメントです。これをチームの教育に使うことで前述の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く