このエントリははてなエンジニア Advent Calender の15日目です（遅刻）。
昨日？前日？は 
id:ma2saka さんのAWSコストエクスプローラーAPIと気軽につきあう(2020) with Next.js でした。
このエントリでは、 Apple M1 搭載の Mac で Go を動かすという話をします。
続きを読むISUCON10に参加して予選敗退しました
しました。
我々のチーム "できの悪いウォーターフォール開発" は予選敗退となりました。最終スコア（かつベストスコア）は1320点くらいです。
リポジトリはこちらです:
敗退はめちゃめちゃ悔しいし無念な思いですが、非常にやり応えがあって良い意味で ISUCON らしい素敵な問題でした！！！！多分文末にも改めて記しますが、これだけの大規模となった今回の ISUCON 予選を運営されたスタッフの皆様には本当に感謝しています。ありがとうございました。
以下は問題のネタバレを含むので、もし問題に関してノータッチでいたい方はここでお戻りください。
また、疲れていてかつお酒を飲んだ状態で書いているので支離滅裂だったり不正確な可能性もあります。後で素面に戻ってから追記したり修正するかもしれません。
AWS CloudFormation に AWS::ECS::CapacityProvider が来はじめた
Amazon ECS Capacity Provider と Fargate Spot と ECS Cluster Auto Scaling を整理する
ラスベガス帰りの 
id:astj です。
今年も re:Invent ではたくさんのサービスリリース/アップデートがあって目が回るような思いでした。現地にいたからキャッチアップできた中身もあれば、しれっとリリースされていて現地でセッションを聞いてるだけだと気づきそびれた中身もあって物量に圧倒されております。
さて、本稿では2019年の re:Invent で発表された ECS 関連のリリースのうち、以下の3つを中心に整理してみようと思います。
遅くなりましたが（ダブルミーニング）、このエントリは はてなエンジニア Advent Calendar 2019 の12/9分のエントリです。ラスベガス時間ではまだ 12/9 ではないでしょうか。そういう話題ではない。
前日は 
id:kouki_dan さんによる "SlackでクイズができるSlack Appsを作った" でした。
AWS re:Invent 2019 に行ってきます
ラスベガスです。初参加です。帰ってきたらまたどこかにレポート的な物が上がると思います。
NoOps Meetup Tokyo #8 で Observability と Mackerel の話をしました
タイトルの通りです。 9/17 にあった NoOps Meetup Tokyo #8 にて、"Observability: Mackerel による観測と Mackerel の観測"というタイトルで発表してきました。
当日のスライドはこちらです。
NoOps という名前は刺激的ですが、 NoOps Japanコミュニティでは以下のように No Uncomfortable Ops という形で表現されています。
NoOps = No "Uncomfortable" Ops
NoOps Japanでは 「システム運用保守の"嬉しくないこと"をなくそう！」 をテーマに、 NoOpsを実現するための技術・設計手法・開発運用保守サイクル・ツールや考え方・事例などを共有していきたいと考えています。
NoOps Meetup Tokyo #8 - connpass
今回で1周年を迎えた（おめでとうございます！）この NoOps Japan コミュニティの Meetup で、 Observability と広く言われる概念のうち Metrics を主戦場とする Mackerel の位置づけや実際の Mackerel の利用、そして最後には Mackerel チーム自身が Mackerel をどう "観測" しているか、という中身でお話しさせていただきました。
自分たちのシステムと向き合うという意味でも、自分たちのサービスと向き合うという意味でも沢山刺激と学びを得ることができました。また Meetup に足を運べればいいな、と思っています。
おまけ
発表中でチラ見せした時系列データベースの話はこのあたりからどうぞ！
blog.yuuk.io
itchyny.hatenablog.com
astj.hatenablog.com
開発チームでプロダクトを新しく保っていくぞ、という話をしてきた
6/15 に Developers Boost KANSAI という U30 向けの技術カンファレンスがあったのだけど、ぎりぎりまだU30やで、ということもあり発表機会をいただいて、ここ半年〜1年くらい Mackerel チームで取り組んでることの話をしてきました。
発表スライドはこちらです。例によってスライドだけではあんまり伝わらない気がしますが、雰囲気を味わうのにどうぞ。
初期開発のあと何年も継続開発なり保守運用なりを続けていくと、何も手を打たなければソフトウェア基盤 / インフラ基盤はだんだん古びていくことになります。古びていくことで徐々に身動きが取りづらくなることを避けようという側面と、そもそもソフトウェアは新しい方が良いのだからちゃんと新陳代謝させて新しくしていこうよ、というメッセージをもとに、実際にチームで継続的に更新していくために行ってる取り組みの話をしました。
ひとつは開発チーム全体のタスク管理に持ち込む前段階としてエンジニア内でタスクの整理をする試みで、もう一つは依存ライブラリの更新を安定して行うためのライブラリアップデート当番という試みです。
勿論この取り組みが全ての状況でフィットするとは限らず、チームやプロダクトの状況に応じて色々なアプローチがあると思っていますが、一つの実例紹介として受け取っていただけたなら幸いです。
