Data Engineering & Data Analysis #8でのTalk資料
https://techplay.jp/event/740541
Developers Summit 2019 Summer での発表資料です。
ソフトウェアエンジニアリングを支える組織のように職人の集まった組織には、無意識に持っている「好き嫌い」の性向がある。 これをハビトゥスという。 これは「好き嫌い」であるので、思ったまま口にすると独善的に聞こえ、幼稚な印象を与えてしまう。 このような「好き嫌い」という性向に基づいて、習慣的な行動がうまれ、それが同じような性向を持った人々を引き寄せるようになる。 この習慣的行動は、当初から合理的に説明可能なものばかりではない。 そうであるがゆえに、「当たり前」だと感じるものしか、取り入れられない。 そのため、当たり前の距離、常識の距離が遠くなればなるほど、 文化資本を組織に身につけにくい。 一方で、当たり前の距離を縮めることに成功した企業は、 徐々にエンジニアが事業部門に溶けていくことになる。 当然、衝突もあるが、融和も果たす。 これは水と油が溶け合っていく現象 「エマルション」に似ている。
Software Engineering at Google 31 Jan 2017 Fergus Henderson <fergus@google.com> (work) or <fergus.henderson@gmail.com> (personal) Abstract We catalog and describe Google’s key software engineering practices. Biography Fergus Henderson has been a software engineer at Google for over 10 years. He started programming as a kid in 1979, and went on to academic research in programming language desi
こんにちは。SREの @kazeburo です。8月17日に株式会社ハートビーツ様が主催する「hbstudy#75」において、メルカリSREの取り組みについての発表をしてきましたので、資料を公開します。 hbstudyでは、SRE大全というテーマで、#74において先日発売となりました「SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム」の翻訳者の発表があり、また#76にてXFLAG スタジオのSREによる発表が予定されています。 発表内容 トークの時間が2時間ありましたので、前半、後半にわけて資料を作成しました。内容も多く盛り込んでおります。 メルカリがSREを採用した理由 メルカリSREチームの紹介 OnCall/運用当番について 先日のCDN変更での個人情報漏洩について PHPアプリケーションの最適化 セキュリティの取り組み(パスワード
“Aren’t you done with every interesting challenge already?” I get this question in various forms a lot. During interviews. At conferences, after we present on some of our technologies and practices. At meetups and social events. You have fully migrated to the Cloud, you must be done… You created multi-regional resiliency framework, you must be done… You launched globally, you must be done… You dep
SRE視点で見るマイクロサービス FiNC SRE担当の鈴木です。 今回は、以前社内のマイクロサービス勉強会で話した「SREの視点からみたマイクロサービスの運用」に関して紹介していきたいと思います。 いつもは、マイクロサービス万歳みたい… 上記ブログでは2016年1月時点で16個のサービスから構成されていると書かれていますが、2017年5月時点で30個近くまで増えています。増える理由はいくつかありますが大別すれば新機能開発か、既存機能の切り分けという事になります。そんな中でここ1年で取り組んで来た事を紹介していきたいと思います。 Docker/ECSの導入大きな変化の一つは本格的にDockerを本番環境で導入し始めた事です。DockerのマネージメントツールとしてAWSのECSを利用しています。Dockerを利用する事の利点は今更ここで紹介するまでもないですが、新規サービスの立ち上げや既存
インフラエンジニアのいない会社で働いて 1 年半 が経った。 iOS で動く POS レジアプリとその管理インターフェイスの Web アプリケーションを作ってます。 iOS 側のことはほとんど分からなくて、データ同期用 API と Web アプリをずっと作っている。 ところで、 「NoOps」の時代がこない理由という記事が前にあったのですが、この点ぼくが働いている会社は NoOps です。アプリケーションは Heroku に乗っていて、 RDBMS が Amazon RDS で一部分析系に Google BigQuery を使っていること以外は全て Heroku 系の何かで動いています。 CI は Travis と circleCI を使っていて、 circleCI については来年初頭にも利用をやめて Travis に一本化する予定、というかんじ。 本当に自分達でなにもサーバーを管理してい
As a developer, you may inherit projects built on existing codebases with design patterns, usage assumptions, infrastructure, and tooling from another time and another team. Fortunately, there are ways to breathe new life into legacy projects so you can maintain, improve, and scale them without fighting their limitations. Re-Engineering Legacy Software is an experience-driven guide to revitalizing
先日、ブログ記事を読んでいて autodoc というツールを見つけた。 Rails の Request Spec から自動的に API ドキュメントを生成するというもの。コードとドキュメントが食い違ってしまう問題を解決できるかも、と思って試しに Quipper 社内で紹介してみた。 当初は「良さそうだね、でも今使っている API サーバー用フレームワークでは使えないようだし、こまごまと不満もあるので、いずれ Rails に乗せかえるときにでも再検討しよう」なんていう反応を予想していた。自分の担当箇所でちょっと使うくらいが関の山だろうなと。しかしその予測は見事に外れた。 紹介した当日、我々が API サーバーを書くのに使っている grape という gem で autodoc を利用するのは骨が折れそうだということがわかる。にもかかわらず翌日、 API サーバーを Rails にマイグレーシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く