今書いている原稿に対して編集者さんから、「できればで構わないのですが、章ごとにマージしたデータでいただけますと助かります…！」とのリクエストがありまたので、CodeBuildでまとめました。 執筆環境(PyCharm, CodeCommit, CodePipeline, S3, Lambda, 署名付きURL)の環境で執筆をしています。 PCだけでなく、iPhone、iPadからも執筆しますのでマークダウンファイルは細かくわかれているほうがやりやすかったりします。 今書いている原稿は節ごとに分けています。 ですが、この場合編集者さんは1ファイルづつの校正や作業が必要になるのでしょう。 とはいえ、私は執筆の原稿単位を変えたくありません。 ということでCodeBuildにまとめてもらうことにしました。 CodeBuildの設定 ビルドプロジェクトを作成しました。 任意のプロジェクト名を入力しま
SREチーム(新卒)の市川恭佑です。今回は、Tonamelという自社サービス(Web)において負荷試験を導入した事例を紹介します。 このエントリは「先送りされがちな負荷試験の導入について心理的なハードルを下げる」ことを目的としています。 そのため、事例紹介と銘打っていますが、列挙される事実の独立性よりも文脈性を優先しています。 表現が少し冗長に感じるかもしれませんが、負荷試験について距離感を感じている方は是非お付き合いください。 負荷試験を導入するに至った経緯 Tonamelは、本格的なリリースから5年以上という、比較的長い運用歴を持つサービスです。 まず、何故このタイミングで負荷試験を導入することになったのかについて、その経緯を説明します。 ポストモーテムによる気づき（文化的な土台） 今年の3月に公開されたエントリにもあるように、カヤックでは着実にポストモーテム文化が浸透しつつあります。
チームで仕事するってとても良いですよね。 色々なタイプの人たちが色々なスキルをもって集まることで個々人ではできない成果を出せる集まりになっていくのでぼくはともかくチームで仕事をすることが好きです。 ただ、人が集まると色々なことが単純ではなくなってしまう場合もあり、今日はそんな「ニンゲンはむつかしむつかしだね」という話を書きます。 人が増えることでチームや事業に致命的状況が発生するのはどんな時か 人が集まると色々なタイプと一緒に仕事をすることになります。 「前提条件や達成すべきKPIや期日は決まっているが、その範囲ならば方法は問わない」という裁量のある仕事でないと力が発揮できない人もいれば、逆に判断する幅のある仕事が苦手で具体的に決まった業務をバリバリやるのが得意な人がいたりします。 当たり前ですけど定型業務が得意なタイプに「やり方や作業内容を伝えず、方向性や達成してほしいKPIや期日だけを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
