AWSを捨てて復活、ドロップボックスが上場へ
オンラインストレージサービスの米ドロップボックス（Dropbox）が新規株式公開（IPO）を申請できたのは、「Amazon Web Services（AWS）」をやめて自社環境へ移行したからだった。同社はITストラクチャーの見直しで売上原価率を34ポイントも改善していた。 ドロップボックスは長らく「行き詰まったユニコーン（未上場ながら推定評価額が10億ドルを超えるスタートアップ）」の代表格だった。同社が最後に資金調達したのは2014年1月。当時の推定評価額は100億ドル（約1兆円）にも達したが、その後は失速。2015年10月には米大手投資会社のフィデリティ・インベストメンツ（Fidelity Investments）が推定評価額を20％引き下げるなど、投資家から厳しい目を向けられ、IPOも新規の資金調達もできずにいた。 そんなドロップボックスが鮮やかな復活を成し遂げた。同社は2018年2月
How Do Facebook And Google Manage Software Releases Without Causing Major Problems?
Facebook evolved from the beginning with the idea of zero down time. In my 4.5 years there, I can only remember a handful of experiences (one caused by me) where there was a widespread site disruption[2]. Pushing multiple releases daily without causing downtime affected much of what we did within engineering for the web app. Pushing in multiple phases. We broke pushing new code into several "phase
MergeCat: CIがgreenになったらPull-Requestをマージ
GitHubを使ってPull-Request駆動で開発していると、CIに待たされることがよくあります。 レビューは一瞬で通る軽微な変更をPull-Requestにした時マージする前にrebaseしてコミットを整理した時リリースの為にdevelopからmasterへのPull-Requestをした時このようなケースでは、CIが通り次第Pull-Requestをマージしたいでしょう。そんな時に人間がCIが通るのを待つのは時間の無駄です。5分、10分かかるテストをただ待っていても何も良いことはありません。 かと言ってPull-Requestを放置していると、そのPull-Requestの存在を人間は忘れてしまいます。運が良ければ1時間後にそのPull-Requestの存在を思い出して、マージできるかもしれません。運が悪いとPull-Requestが他の変更とコンフリクトして、もう一度CIを待つハ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
