Saying farewell to Pixate. When we launched Pixate, our mission was to change the way mobile apps were prototyped. We joined Google just over a year ago to continue our mission, and to pursue a broader vision of changing the way products were designed and built. While a lot of the ideas we’ve been developing could work inside the Pixate framework, we believe we can have a larger impact if we move
今年で3度目の参加となるAWS re:Invent。 忘れない内に記録を残しておきます。 Day 0 Game Day Unicornを貸し出すサービスを展開する仮想のスタートアップ企業にDevOpsチームとして最近入社したという設定。前任者が退職しており、資料が少ない中でサービスオープンに立ち会いつつ、様々な困難に直面するというフルデイ・イベント。 今までのGame Dayと違って面白いのはパフォーマンス・チューニングをしつつも、コストも意識しながらチーム間でスコアを競争するところ。アプリは触れないので、ISUCONよりは昔やったチューニンガソンに近い感じ。 スコアは累積の損益。アーキテクチャによっては利益が出たり損失が出たりする。例えば、多くのリクエストが処理できると利益は増すが、AWSのリソースが多いと費用が掛かって損失になりうる。 当然最初は各チームは赤字から始まり、時間とともに積
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。データセンターのサーバを管理しています宮本です。 今回はOpen Compute Project(以下、OCP)の概要とヤフーがOCP仕様のサーバ(以下、OCPサーバ)を導入するまでに至った経緯をお話したいと思います。 オープンソースとハードウェア オープンソースという言葉はよく耳にしますが、この「みんなで作り上げていく」という考え方はハードウェアの世界にも浸透してきています。 ソフトウェアでオープンというとソースコードの共有にあたりますが、ハードウェアのオープンソースは物理的な仕様の設計書を共有することを意味します。 Facebookが2011年にデータセンターやサーバのオープンソース化を目的としてOpen Comp
2015年10月21日に行われたエンタープライズアジャイル勉強会2015年10月セミナーでの講演『エンタープライズアジャイルと全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~』のレポートです。資料は以下。 講演の後の懇親会で「計画的なアジャイルと、柔軟なウォーターフォールは見分けがつかない。ていうか、名前だけの問題だ」という話になりました。 資料でも書いているとおりエンタープライズ案件はリリース日について厳密なコントロールを求められます。一方で、多くのプロジェクトではリスク管理が重要であることは間違いなく、だからこそ、アジャイルでもウォーターフォールでも(まともなプロジェクトであれば)実質的なオペレーションは似通ったものになるというのです。 確かに、僕の経験から言っても、一度アジャイルを経験してしまうと「ウォーターフォールかどうか」というのは希薄になって「計画すべきはど
Alpaca CTOの原田(@umitanuki, github)です。 世界を破壊しうる小さなアイデアで働くのは、スタートアップをやる中で一番楽しい部分でもあります。世界中の他のスタートアップが創りだす小さなアイデアが世界を変えていくのを見るのもまた楽しいものです。アルパカのメンバーは皆大企業で働いた経験が何年もありますが、一般的常識の働き方を踏まえて、どうやってもっと良い方法があるかを常に探しています。もちろんそれはウチに限ったことではなく、多くの小さなスタートアップではその通りなのでしょうが、詳細についてはどこも同じではないと思います。ので、今日はAlpacaではどういうツールを使ってどうやって働いているかを少しご紹介しようと思いました。 Slack slack.com Slackが急速に普及しているのはもはや疑いの余地がありません。Slackのいいところはたくさんあるのですが、特に
世の中マイクロサービス・マイクロサービスうるさいのでちょっとこれ読んでおけという資料をまとめておきます。 はっきり言ってマイクロサービス化しようとすると、組織構造の話、エンジニアの責務の話など技術的な課題以外の領域にもいろんなチャレンジがあるので、普通のプロジェクトでも苦労する組織が取り組むとか、設計だけして開発を委託しているけどDB一極化がやばいので取り組むとかは止めておいた方がよいと思います。 概念Twelve Factor Appマイクロサービスの話ではないが、モダンなアプリケーションを作りたければ開発チーム全員に叩き込んでおくべき内容MicroservicesMartin Fowlerによるマイクロサービスの解説。2014年5月に公開Martin Fowlerのブログは翻訳が可能で、日本語訳を公開してくれている人がいる。こちら単純に言えば、「マイクロサービスとは単一のアプリケーショ
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの・・・い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く