こんにちは。運営スタッフの@nari です。 いよいよSRE NEXT 2020の一般販売チケット&個人スポンサーチケット販売がスタートしました!! 購入方法に関しましては、先行販売チケット購入ガイドでご説明したものと 基本的には変わりませんので、今回は各種チケットのご紹介と先行販売チケットの購入方法と異なる部分についてご説明します。 チケット種別のご紹介 各種チケット購入方法 一般チケット(懇親会無)、一般チケット(懇親会付き) 個人スポンサーチケット(懇親会付き) スピーカーチケット スポンサーチケット スタッフチケット 振替チケット(先行販売チケット -> 個人スポンサーチケット(懇親会付き)) 最後に 2019/12/26追記: 一般チケットは全て完売致しました！ その他チケット発行はこちらから！！ チケット種別のご紹介 チケットには以下の種類がございます： 先行販売チケット(懇親

技術部 SRE グループの mozamimy です。 クックパッドでは、 SRE が中心となって、サービスを動かす基盤の大部分である AWS のコスト最適化を組織的に取り組んでいるため、今回はそれについてご紹介します。 前半では、そもそもの話として「なぜコスト最適化が重要なのか」「何が難しいのか」「何をすべきなのか」といったことを述べます。これは、当たり前すぎて逆に陽に語られることが少ない (とわたしは感じています) トピックで、一度しっかり言語化しておいてもいいかなと考えたからです。内容のほとんどはわたしの脳内ダンプで、クックパッドという会社のコンテキストや組織としてのステージが前提になっているため、大多数の組織について当てはまる内容とは限りません。 後半では、コスト最適化の一例として、リザーブドインスタンス (以下 RI と略記) を維持管理するためのフローと、それを支えるモニタリング

今回はソフトウェアエンジニアじゃない人や学生にも、ソフトウェアエンジニアという職業には夢があるかもしれないと思ってもらうために書いています。そのため既に詳しい方からすると回りくどい説明も多いと思いますがご容赦下さい。 基本的に記事とかには技術的なことしか書かないスタンスでやってきましたが、今回の件はさすがに誰かに伝えておくべきだろうということで長々と垂れ流しました。 概要 GW中に趣味で開発したソフトウェアを無料で公開したところAqua Securityという海外企業（アメリカとイスラエルが本社）から買収の申し出を受け、最終的に譲渡したという話です。さらに譲渡するだけでなく、Aqua Securityの社員として雇われて自分のソフトウェア開発を続けることになっています。つまり趣味でやっていたことを仕事として続けるということになります。 少なくとも自分の知る限り一個人で開発していたソフトウェ

AよりB、CよりD 今後の方向性を決める判断の中で「Aという技術ではなくBを採用する方がが良さそうです」とか「既存システムのCは良くないからやめてDを使うようにしましょう」とか。最近、何人か全然別の人からそういう話を聞く機会があった。 AよりBが良さそう？ 「僕はAの方が良いと思うんですけど、Bの方が良さそうだと思う理由を知りたいです」って聞くと「Aはこういう部分に問題があると思います」って言われて話が噛み合わなくて、しばらく話をして気づいた。 この人、Aを触らずに想像だけで喋ってるんだ。ってことに。なので、実際に動かして見せてあげると「あぁ、それならAの方が良いですね」ってなった。 「興味があるだけなんですけど、僕も知らない技術だったので少しドキュメントを読んで実際に触ってみて機能を確認してからAの方が良いなと思ったのですが、どうして触らずに想像だけでAは問題があるって断言したんですか？

「15年」 あなたは15年と聞いて何を思い浮かべるだろうか。 例えば人が生まれて15年。 その人は今頃中学校を卒業し高校生になる頃だろう。 例えば15年戦争。 1931年の満州事変から始まった一連の戦争が1945年に終結するまでにかかった年月。 例えば私が2chのソフトドリンク板に「とあるスレッド」を立てそのスレッドが1000レスに達するまでの年月。 と言うわけではじめまして。 2ch（現在は5chですが、この記事では2chと記載します）ではいつも所謂「名無しさん」ではありますが、ここではamino774mlと名乗らせて頂きます。 よろしくお願いします。 さてこの度何故このようなブログを開設したのか。 それを語るにはまずはこの2chのスレッドを見ていただく必要があると思います。 アミノバリューってどうよ？ これは2003年9月19日にソフトドリンク板に立てられたスレッドの一つです。 何を隠

技術評論社 WEB+DB Press vol.111 の連載 Perl Hackers Hub に、「AWS X-Rayによる分散トレーシング……マイクロサービスのボトルネック，障害箇所の特定」という記事を書きました。 WEB+DB PRESS Vol.111 作者: 松田明,y-yagi,佐藤建太,夜道,村田賢太,伊藤英明,見川孝太,新井剛,関陽介,海老原圭吾,長田洸明,大原壯太,藤原俊一郎,松本宏太,末永恭正,久保田祐史,牧大輔,笹田耕一,竹馬光太郎,池田拓司,はまちや2,竹原出版社/メーカー: 技術評論社発売日: 2019/06/24メディア: 単行本この商品を含むブログを見る 内容は1月にあった YAPC::Tokyo の発表をベースにしたものです。 sfujiwara.hatenablog.com YAPC での発表をしたときの印象で、どうも分散トレーシングはそこまでメジャーじゃ

データベースのスキーマを変更するということはデータをいじる行為であり、最悪の場合データが消えます。 最悪の事態にはならなくとも、思わぬ場所に影響が起きたり、データの不整合が発生する恐怖と戦う必要が有ります。 テストや切り戻しを含めて計画し、大きな変更の場合にはダウンタイムまで考慮する必要があります。 そこで、RDBを対象にデータベースの変更を行う方法について書いていきます。 スキーマ変更 まずは、スキーマ変更について、 カラムを追加する 一番簡単で、影響も少ない変更です。 気をつけるのは、 ソースコードの変更よりも前にスキーマ変更を完了させる (長時間)ロックがかからない方法を選ぶ といったところでしょうか。 大抵の場合は、スキーマの変更とソースコードの変更の順番にさえ気をつければ問題は発生しません。 カラム名を変更する 「ALTER」でさくっと変えたくなりますが、ソースコードの変更が同時

SRE Session とは？ イベントレポート SRE Session のスタイル 事前アンケート グループ分け テーマごとのサイクル Welcome talk Discussion Sharing 懇親会 感想 時間の長さ グループ分け 議論のまとめ方 参加者の総数 SRE Lounge の Slack ワークスペースへのお誘い SRE Session とは？ SRE Lounge のスピンオフで、SRE Session という勉強会の第1回が4月10日に開催されました。 sre-lounge.connpass.com SRE Session は少人数かつ全員参加型で議論するタイプの勉強会です。当日は議論が盛り上がり、参加者の反応も良かったので、おそらく SRE Session #2 が6月頃に開催されそうです。そこで、だいぶ遅れましたけど（3週間近く経ってる……）軽く感想をメモしてお

今更ですが技術書典6、おつかれさまでした。ありがたいことに『Pragmatic Terraform on AWS』も物理本200部が完売しました。また、BOOTHでは10日ほどで、電子版を370名以上の方にご購入いただきました。本当にありがとうございます。 kosmos.booth.pm 本記事では、『Pragmatic Terraform on AWS』の執筆の裏側を紹介します。技術と書いてますが、ぶっちゃけタイトル詐欺です。だいたい根性でなんとかしました。 前提 執筆にはRe:VIEWを使用しました。書籍執筆が初だったのもあったので、TechBoosterさんが公開しているReVIEW-Templateをほぼそのまま使いました。先人の知恵が凝縮されており、執筆初心者でもちゃんとした本の体裁が整う素晴らしいソフトウェアです。 ReVIEW-Templateは今でこそRe:VIEW 3.1

概要 ダブリンの node.js meetup でゲストとして、登壇してきました。 スライド + ノート 内容は、今後の Node.js の ESM 実装に関する話です。 以下の記事に文字を書き起こししてありますので、興味あったら見てください。 Introduce ECMAScript Modules of Node.js I talked about ECMAScript Modules at Dubin Node.js meetup. I made comments to deepen your understand... 経緯 We had a look at some of your previous talks and our group would definitely love to hear from you! Let me know if you are interest

日次でも月次でも、まず殆どのシステムで何かしらのバッチジョブというものを動かしていると思いますが、 そのバッチが確かに実行された ことを保証・監視することは結構難しいです。ジョブが起動しましたのタイミングでログを書き、終わってもログを書くとすれば、ジョブが成功したか失敗したかはわかりますが、そもそもジョブが着火すらしかなったはわかりません。*1 例えば、「このジョブが終わるとここにファイルが出ているはずだ！このDBのレコードが更新されているはずだ！」などと、そのジョブ固有の結果を観測して判定することはできますが、汎用的な手法ではありません。 私は詳しくはないですが、商用のジョブ管理ツールはそれぐらいは見てくれるのかもしれませんが、もっと簡単にこれを実現できます、しかも今風に。 Healthcheckesとは ググりにくく、ネーミングセンスとしては最悪ですが、上記に挙げたような機能を実現する

タイトルどおり、TerraformとAWSについて書いた本を出す予定です。いま絶賛執筆中で、ちょこちょこ変わるかもしれませんが、だいたい構成が固まってきたので目次案を公開しておきます。 4/8追記 確定版の目次や無料サンプルを公開しているので、ぜひこちらもチェックしてください。 nekopunch.hatenablog.com nekopunch.hatenablog.com 概要 『Pragmatic Terraform on AWS』では、Terraformを使ってAWS上にシステムを構築するノウハウを、100以上のサンプルコードとともに紹介します。ECS Fargateなどのマネージドサービスを中心にアーキテクチャ設計を行い、Terraformで実装していきます。Terraformは入門的な内容からスタートし、コードの構造化やベストプラクティス、モジュール設計まで踏み込みます。 目次

「お前やってることは法律に引っかかってんだよ！」――自身のサイトに「Coinhive（コインハイブ）」を設置したとして検挙されたWebデザイナーを、神奈川県警の捜査員がどう喝している取り調べ音声データを入手。当事者とその弁護士に検挙の問題点を聞きました。 神奈川県警港南警察署による「コインハイブ事件」の取り調べ音声 事件のあらまし サイト訪問者のPCを使ってWebブラウザ上で仮想通貨をマイニング（採掘）させる「Coinhive（コインハイブ）」を設置したことを巡り、複数の検挙者が出ている問題（通称：Coinhive事件）。ねとらぼでは1月30日に「なぜコインハイブ『だけ』が標的に　警察の強引な捜査、受験前に検挙された少年が語る法の未整備への不満」との記事を公開し、検挙者の1人である少年を取材しました。 今回は前述の記事内でも紹介し、現在刑事処分に対して異議を申し立てる裁判を行っているWeb

2月末日付けで退職しました。退職エントリ書くつもりは無かったんですが、周囲から「公益性が高そうなので書け」というお言葉をいただいたのと、あと海外在住プログラマのキラキラ記事っておおいに生存バイアスかかってる気がするし、死にゆく者の事例も大事かな、と。 はじめに つらみは有りましたが、うらみは有りません。当初3年ぐらいかなと思ってたけど、この1年間の経験には大変満足しています。また、同僚各位にも深く感謝しております。Vielen Dank. I love you ;) 日本に帰る理由も、ドイツがつらいってのはだいたい3割ぐらいで、じつは2年前からゲノム解析のウェブサービス化とか生物学周辺のソフトウェア受託などの個人事業をやってて、そろそろそっちに集中すっかー、というのがマジな理由です。 tl;dr 自分を守るのは会社でも制度でもなく、自分。Noと言えなければ死ぬしかない。 自分に落ち度が無い

OSI参照モデルとTCP/IPモデル なぜいまでもOSI参照モデルによる説明が多いか QUICは、TCP/IPモデルのトランスポートとはいえるが、OSI参照モデルのレイヤ4とはいいにくい HTTP/QUICモデル QUICをどう解説するか OSI参照モデルとTCP/IPモデル かつてぼくたちは、7つのレイヤに分かれたOSI参照モデルという姿でコンピュータネットワークを学び、その7層のモデルにそって各種のプロトコルを理解しようとしていました。 だから、「SONET/SDH上のATM回線でIPパケットをやり取りする」という構想をきけば、「つまり、SONET/SDHがレイヤ1で、ATMがレイヤ2で、IPがレイヤ3なのだな」という枠組みを頭に描いていました。 と同時に、OSIのレイヤとはいったい……、というアンビバレントな想いにさいなまれることもよくありました。 「SONET/SDHがレイヤ1って

Kubernetesと本番運用の話 日本マイクロソフトのKubernetesを本番運用する際のレポートが@ITで紹介されています。有用な記事ですので共有します。 www.atmarkit.co.jp 日本マイクロソフトは2018年11月5～7日に「Microsoft Tech Summit 2018」を開催した。本稿では、Microsoft Cloud Developer Advocateの寺田佳央氏の講演「Javaを活用したマイクロサービスのためのKubernetes活用」の内容を要約してお伝えする。 本番運用する際の注意点 安易にKubernetesを選択すると、予想以上に大変な思いをする 私も何度かこの話を書いていますし、もはや真実なんだと思います。 数年後はもっとstableなものになっていると思うのですが、現状は地雷がたくさん残っています。 ただし、いいところもたくさんあるKub

----- 2019/08/18 追記：GitHub Actions が新バージョンで大きく変わったため、新しい記事を書きました。こちらの記事は古い内容なので、新しい記事を参照してください。 www.kaizenprogrammer.com ----- developer.github.com 現在パブリックベータの GitHub Actions が自分も使えるようになったので、いろいろ調べたり動かしてみたりした内容をまとめます。 目次 注意事項 GitHub Actions とは 簡単な例 (Hello, World) ワークフローの設定 workflow ブロック action ブロック needs を使ったフロー制御 uses における Dockerfile の指定方法 ワークフローがサポートしているイベント 秘密情報の設定 GITHUB_TOKEN ビジュアルエディタ ワークフロー

Vivaldiのブックマーク出力ってどこからできるの？ Vivaldiというブラウザのブックマーク機能について。 ちょっと個人的に分かりにくかったのでメモ書きします。

QuipperデザイナーのMatsumotoです。 今回はQuipperのデザイナーが、普段どんなチーム構成で働きどんなワークフローで動いているのか、簡単に紹介していきます。 また、様々な職能を持つメンバーが集うチームで求められるデザイナーの役割、日々の気づき、今後の抱負など軽くまとめてみました。 デザイナーの「何かの気づき」になれば嬉しいし、エンジニアやPMの方が、デザイナーと一緒に「デザインについて考える」きっかけとなれば幸いです。 はじめに 事業会社で働く面白さ どんなチームで働いている？ プロダクト単位のチーム チーム内訳 職業単位のデザインチーム プロダクト単位のチームによるワークフロー 良い点 改善したい点 UI/UXはデザイナーだけで作るもの？ どんなフィードバックがいいの？ 終わりに はじめに 前提として自分の経歴を簡単に書いておきます。 2017年11月にQuipperに

出しわけたいユースケース 例えば、GCPの2つのprojectからCloud SQLの複数のDatabaseのmetricsが送られてくる場合。 project Aの場合は、こっちのチャンネルに通知、project Bの場合は、そっちのチャンネルに通知したいみたいなときに有効です。 metricsの設定方法 まずは、出しわけたいグループごとに、 avg by 部分に設定していく。 こうすると、project_idごと、database_idにmetricsが分かれて表示されて、個別にalertしてくれるようになる。 メッセージ部分の設定方法 template部分で、#is_matchを使うと、if文みたいなことが書けます。 これとタグの値を組み合わせれば出し分けたりができるわけですが、 このときに注意が必要なのが、グルーピングに利用したタグの値しか利用できませんでした。 利用できる変数は{