前回、購入を決めたところまで書いたが、今回は家ができて内覧するところまで。 ローン本審査と団信 前回通ったのは仮審査なので、次は売買契約と住宅ローンの本審査となる。 住宅ローンには団信(団体信用生命保険)というやつが含まれている。これは、本人が死んだり、障害を抱えるなどして返済能力が無くなったときにローンの残債がチャラになるという強力な保険だ。それだけの優遇があるので、その分、ある程度健康であることが求められる。審査申込時に健康状態の記入項目がある。 それまでは比較的健康には自信があり、実際その前年までは健康診断で引っかかったことはなかった。しかし、前年から外的要因の変化が色々あり、体重増加等が気になってはいたのだ。 果たして、その年の健康診断は初めての再検査となった。LDLコレステロール値が正常値範囲外になっていたのだ。焦ってすぐに再検査を申し込み、再検査までの1ヶ月の間、酒を断ちジム通

Nature社は今年の頭にはスタッフが20人を超え(内ハードウェアエンジニア2人、ソフトウェアエンジニア8人)、いよいよ組織らしくなってきました。そして、この4月の期替わりから組織体制が見直され、各専門領域にVPを置くことになりました。目的としては、社内のリーダーシップの強化による組織の成長や、権限を明確化することにより、それぞれのチームが自律的に速度を落とさず動けることなどが挙げられます。 それにより、僕もCTOからVPoE (VP of Engineering) という立場になりました。テック関連のVPは以下の3つに役割分担することにしたのです。ソフトウェア開発とハードウェア開発でも分かれているところがIoT企業ならではとも言えるでしょう。 VP of Engineering VP of Software Development VP of Hardware Development 僕

tl;dr 驚くべきハックにより旧Androidも引き続き証明書エラーなくサイトを閲覧できそうです いよいよ5/4に標準の証明書チェーンが切り替わります 前回までのおさらい Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる Let's Encryptの証明書切替周りその後 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしています。現在は、IdenTrustのルート証明書(DST Root CA X3)が使われています。 正確に言うと、ISRGは新しい認証局なのでそのルート証明書の普及率も当然低く、中間証明書はIdenTrustのルート証明書でクロスサインされており、それが標準で使われています。標準がDSTになっているだけで、ISRGのルート証明書のチェーンの証明書も指定すれば今で

家を買うつもりはあまりなかったが、ライフステージの変更に伴い買った、という良くある話です。2016年までの昔話です。 一応今の住所はあまり積極的にはネット上では公開していません。ただ、分かる人にはどのあたりか分かってしまいそうなので、その場合はそっとしてもらえると嬉しいです。 二子新地時代の購入未遂事件 結婚当初は僕は持ち家志向は強くなく、妻の方が比較的強かった。ただ、当時住んでいた二子新地が非常に気に入っていたこともあり、一度、近くの不動産屋に行ったことがあった。2011年頃の話。 確か二子玉の再開発絡みで周辺にマンションや建売住宅が建ちはじめていて、その中で当時の近所に建設中の分譲住宅が悪くない金額で売りに出されていたことがあった。それをふらっと内見させてもらい、それが良かったため、興奮した妻に連れられて不動産屋にまでも行くことになった。 「あーこれは買わされる流れかもな」と思っていた

tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 本題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,

アプリケーションが発行するSQLにコメントが埋め込めると便利です。例えば、 /* path/to/logic.go:334 */ SELECT ... のようにSQLに発行元の情報をコメントとして埋め込んでからExecすれば、DB側のログ(general log等)にも記録されるため、SREやDREサイドからも、負荷の高いSQLがアプリケーションのどこから発行されているかが分かりやすくなります。 Goには github.com/shogo82148/go-sql-proxy という、SQL実行をトレースし、フック処理を差し込める便利なライブラリがありますが、今回それにpull requestを送って、SQL実行前にクエリの書き換えができるようにしました。 https://github.com/shogo82148/go-sql-proxy/pull/61 https://github.co

tl;dr Goのdatabase/sqlのDSN内のsql_modeやLocation等、固定したほうが良いパラメータ設定は、設定値に持たせるのではなく、アプリケーション内部で決め打ちしたほうが安全です。 本論 社内でMySQLを使っているので、それを例にとって書きます。 いわゆる、DSN(dataSourceName)呼ばれる、sql.Open に渡すDB接続文字列があります。これは、環境変数 DATABASE_URL 等に入れてアプリケーション内で読み出してDBに接続するでしょう。 DSNにはホスト名、ユーザー名、パスワードなどの接続先情報の他に、様々なオプションパラメータを記述することができます。以下にDSNの例を出しますが、この中の?以降がオプションパラメータです。 user:pass@tcp(myhost:3306)/dbname?collation=utf8mb4_unico

シェルスクリプトのシグナルハンドラ内で受け取ったシグナルが何なのか知りたいことあると思います。しかし、単純に trap cleanup INT TERM ERR EXIT PIPE とするだけでは、cleanup関数内で受け取ったシグナルの種類を知ることができません。そこで、以下のようにすればシグナルの種類を知ることができます。 #!/bin/bash set -Eeuo pipefail cleanup() { echo "Trapped signal: $1" # script cleanup here } trap_sig() { for sig ; do trap "cleanup $sig" "$sig" done } trap_sig INT TERM ERR EXIT PIPE # your script below ループを回してtrapしたいシグナル毎にtrapを呼び出し

この記事は、Go 4 Advent Calendar 2020の16日目の記事です。 さて、ある日、Goで書かれたHTTP APIサーバーのdeployをしたところ、急に500エラーの発生率が上がったことがありました。しかし幸いにもユーザー影響は出ていません。どうしたのでしょうか？ ALBログの調査 このシステムはAWSのApplication Load Balancer(ALB)からプロキシされていますが、エラーリクエストに対応するALBのログを調べるとステータスコード460が記録されていました。460を調べると以下のように書いてあります。 The load balancer received a request from a client, but the client closed the connection with the load balancer before the id

その名もecschedule。だいぶ前から作っていたのだが、この度実戦投入した。 https://github.com/Songmu/ecschedule Nature社では、ECS上でGoのサービスを動かしており、バッチ系の定期実行タスクもECS Scheduled Taskを利用している。 最近バッチの本数が増えてきて管理したくなり、このツールを導入しました。 便利だとは思うが、かなり社内事情にべったりであるため、フィードバック歓迎です。具体的には以下の制約を前提としています。 Rule名がユニークであること RuleにはTargetが1つだけ紐付いており、TaskのContainer Overridesでタスクを実行している ecspressoにかなり影響を受けており、ECS Scheduled Task用のecspressoのような作りになっています。 インストール % brew

https://github.com/Songmu/gotesplit gotesplitというかなり便利なツールを書いた。Goのテストをいい感じのサブセットに分割して、それを実行するものです。このアプローチで、社内のテストを15分から3分くらいまでに短縮しました。 これを使えばCI環境での高速なテストの並列実行を簡単に実現できます。 実例 CircleCIやGitHub Actions上で簡単に導入できます。 CircleCIの場合 parallelism: 5 docker: - image: golang:1.15.3 steps: - checkout - run: command: | curl -sfL raw.githubusercontent.com/Songmu/gotesplit/main/install.sh | sh -s bin/gotesplit ./... -

「Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる」の続き。 色々動きがあって猶予もできて助かった形だけど、来年9月29日以降の対応をどうするか考えないといけない状況なのは当然変わっていません。先にまとめると以下。 何もせずとも来年の1月11日までは猶予が伸びた 証明書を発行する側の場合、各クライアントで --preferred-chain "DST Root CA X3" のようにオプション設定することで、来年の9/29まで先延ばしが可能 独自ドメインに対して自動でSSL証明書を発行してくれるサービスを利用している場合はサービスが声明を出していないか調べ、出してない場合は問い合わせると良いでしょう 前回以降の動き go-acme/legoに--preferred-chainオプションのpull requestを取り込んでもらいました デフォルトRoot証

プロの中には、道具、特に自分の体が触れるインターフェース部分に神経質な程にこだわり、そして結果を出している人がいる、という話を何回かに分けて書こうと思う。一つのエントリにしようと思っていたが、脱線しまくったのでそれを残しつつ分けることにした。 ランス・アームストロング ランス・アームストロングという伝説的な元プロ自転車ロードレーサーがいる。2000年頃、ロードレーサー乗りにとっては、圧倒的なヒーローであり、僕にとってもそうだった。 ロードレースはヨーロッパが本場ではあるが、当時はやや慣習的で閉鎖的になっているとも感じられる部分があった。そこに、ランスはアメリカから乗り込んだ。彼の所属したUSポスタルはそれまでの常識を覆すような科学的な手法やトレーニングメソッドを取り入れた。「たかが」自転車のために風洞実験まで実施した。そして、圧倒的な強さを誇った。痛快だった。 だからこそやっかまれた。ドー

追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST

https://github.com/Songmu/deglacer KibelaのリンクをSlackに貼り付けたら展開して欲しいという気持ちがあり、公式に対応してほしいなーと思っていたのだが、なかなか対応されないのでSlack Appを習作する意味でも作ってみた。 とは言っても、以下のhigebuさんのサイトにめっちゃ詳しく書いてあって、それをそのまま参考にさせてもらいました。 Kibela のリンクを Slack に貼ったときに展開されるようにした 何故か僕が勘違いしていて、これのソースコードがhttps://github.com/otofune/slack-unfurl-kibelaだと思っていて、これがRuby製なのでそれをGoに移植した。しかし本当は上記のエントリ上のソースはhttps://github.com/higebu/slack-app-unfurl-kibelaで、これ

6月5日が誕生日なのでもうひと月以上経っている。同じ日に娘が5歳になった。 40歳は社会人の折返しとも言えるし、人生の折返しとも言えるなかなかおもしろい年齢だ。20年前が20歳だったので、それを踏まえて20年後の60歳がどうなっているかなんとなく見通しが立つ気がする。気がするだけだとは思う。 40代の挑戦を考えた時に、新型コロナで世の中が大きく動き、逆に次の動きが読めない中、僕自身は去年から既にNature社での新しい挑戦を始められていて、40代もそれでスタートを切れるというのは幸いに思う。 前職の元CTOで僕の元上司である @stanaka さんが、はてなを辞めるタイミングで「10年スパンでキャリアを考えている」みたいなことを言っていて、そのときは「そんなもんかね」と思っていたが、なんだかんだで影響を受けている。 やっと大人になった気もしてくる。自分の10代と親が40代だったころがちょう

ボツネタかつ、golintが非推奨になりそうなので、急いで書きます。 golintを守ってれば、最低限Effective Goぽいコードを書くことができるので、初心者取っ掛かりのlintとしては良いよなーと個人的には思っており、非推奨には寂しい気持ちもあります。とはいえ、Goが言語自体も変化をしていく中で妥当な判断だと思います。しかし、他言語でも見られる光景ですが、lintをメンテナンスする難しさというものを感じてしまいますね…。 本題 さて、プロジェクトに途中からgolintを導入しようとすると(もはや導入すべきなのかどうか分かりませんが)、やたら警告が出てきて心が折れてしまうことで知られています。特に、 "exported $hoge should have comment or be unexported" と言うメッセージは量も多く、対応も大変なので困りものです。 これは「publ

前のエントリでDatadogについて書いたが、実際にGoのアプリケーションがOpenMetricsを吐くようにするのはどうのようすれば良いかをもう少し解説します。 OpenMetricsとは？ 元々[Prometheus]が利用しているフォーマット。Prometheusは"Promethues exporter"と呼ばれる監視対象からメトリクスを集約する作りになっている。 Prometheus exporterは実は「単なるHTTPのエンドポイント」であり、そのレスポンスが独自のテキストフォーマットになっている。このフォーマットを標準化しようとして提唱されているのがOpenMetrics。 https://openmetrics.io/ 実際問題としては、Prometheusのドキュメントの方がまだまだ充実している。 DatadogにはOpenMetricsのインテグレーションがあり、自前

追記: GoのアプリケーションをOpenMetricsを使ってObservableにする方法については別エントリを書きました。 → https://songmu.jp/riji/entry/2020-05-18-go-openmetrics.html ECSとGoで運用しているシステムに対するDatadogの日本語知見があまり無さそうだったので書いてみる。ちなみに以下の環境です。 ECS on EC2 (not Fargate) アプリケーションコンテナのネットワークモードはbridgeモード 動的ポートマッピングも利用 背景として3月にNature Remoのインフラアーキテクチャ改善をしていて、その前にもうちょっと監視を整えたほうが良いな、ということでDatadogを導入したのがある。テストがないとリファクタリングできないように、監視がないとアーキテクチャのアップデートもやりづらいとい