Cloudflare PagesにそれなりにちゃんとBasic認証をかける | おそらくはそれさえも平凡な日々
前回の、社内プライベートポッドキャスト実現方法で、ポッドキャストサイトを静的配信しつつBasic認証をかけるというアイデアを書いた。しかし、Basic認証などなかなか使わなくなり、ネイティブでサポートしている静的ホスティングサービスも少ない。今回はCloudflare PagesのFunctions機能でリクエストをラップするミドルウェアを書けば実現できることが分かり、その方式を採用することにした。多少実装必要になるのと、認証周りを自前で書くのはあまりやりたくはないが、廉価に比較的省力で実現できるので受け入れる。 ネット上にいくつかサンプルは見つかるが、今回実装するにあたっては以下の点を留意した。 コード内に認証情報を載せない 複数ユーザーのIDとパスワードを管理できるようにする パスワードは定数時間比較してタイミング攻撃を防ぐ これらを以下のように解決することとした。 認証情報は環境変数
ヘンリーに入社しました | おそらくはそれさえも平凡な日々
1月から株式会社ヘンリーに入社しました。ヘンリーは「社会課題を解決し続け、より良いセカイを創る」というミッションを掲げ、現在はHenryというレセコン一体型クラウド電子カルテサービスを主力として医療DXに取り組んでいるスタートアップです。 https://corp.henry-app.jp/ ヘンリーのことはあまり知らなかったのですが、ずっと一緒に働きたいと思っていたエンジニアの一人である縣さんが所属しており、今回私が転職活動を始めたのを彼が早々に察知して誘ってくれたのがきっかけです。 彼と話したところ、開発に色々課題は抱えつつも前向きに、楽しそうに働いていると感じたのが印象的でした。ナイスガイな彼がそれくらい魅力を感じているのであれば、良いチームで面白い社会課題を解いているだろうなと。 その後、2週間で様々なポジションの7名とお話しました。どの方もモチベーション高く、顧客や事業やプロダク
退職 | おそらくはそれさえも平凡な日々
12月末でLaunchableを退職します。実際には11月30日が業務最終日で12月は求職活動をしていました。幸い12月中に転職先を決めることができ、1月から次の会社で働きます。次の会社は年明けにお知らせします。 求職活動中は多くの方や会社から連絡をいただき本当にありがたかったです。全てにお返事をすることができず申し訳ありませんが、直接お知らせできなかった方にはこちらでお知らせとなることをご了承ください。 以上でお知らせは終わりで、以降は単なる中年男性のしょうもない独白です。 退職は非常に残念で、Launchableでまだまだやりたいことはあり、これからというところでもあったのですが、言ってしまえば西海岸外資の洗礼を受けたということです。 今回の僕の挑戦はあっけなく終りを迎え、ほろ苦い体験となりました。とはいえ間違いなく良い経験にはなりました。Launchableの事業は引き続き応援してい
git-pr-releaseとGitHub Actionsでワンクリックデプロイを実現する | おそらくはそれさえも平凡な日々
突然ですが、git-pr-releaseのなんちゃってコラボレーターである私が僭越ながら、その王道の使い方を皆様に伝授していきます。何番煎じかの記事ではありますが、現代の、特にGitHub Actions出現以降の使い方をまとめたいというのが動機です。 https://github.com/x-motemen/git-pr-release https://rubygems.org/gems/git-pr-release git-pr-releaseはGitHubを業務開発で利用している場合に便利なツールで、デフォルトブランチにマージされたpull requestをリリース項目として一覧し、それをpull request化してくれるものです。これにより以下のことが実現できます。 リリース項目が一覧されることによるリリース内容の明確化 マージボタンによる明快なワンクリックデプロイの実現 pul
GoのWebアプリケーションでステータスコード499を記録する | おそらくはそれさえも平凡な日々
この記事は、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
Let's Encryptの証明書切替周りその後 | おそらくはそれさえも平凡な日々
「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証
Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる | おそらくはそれさえも平凡な日々
追記: その後の動きについて書きました → 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
ghqで仕事用と趣味用でディレクトリ分けしてリポジトリ管理しやすくなりました | おそらくはそれさえも平凡な日々
2020年1月5日追記: v1リリースしました https://songmu.jp/riji/entry/2020-01-05-ghq-v1.html https://github.com/motemen/ghq 最近のghqの状況と、v1リリースに向けた非互換変更などのアナウンスです。現状の最新のv0.17.4を前提に書きます。 ghq.<url>.root 設定により細やかにclone先を設定可能に 例えば、gitconfig上に以下のように設定すれば、デフォルトでは"~/src/hobby" に、仕事用は"~/src/work"にcloneされます。 [ghq] root = ~/src/hobby [ghq "https://github.com/myorg"] root = ~/src/work [ghq "https://myvcs.example.com"] root = ~
GitHub Actionsを使ってGoプロジェクトのCI/CD及びカバレッジ計測をおこなう | おそらくはそれさえも平凡な日々
GitHub Actionsを遅まきながら使ってみて、自分のアクティブなGitHub上のGoのOSSプロジェクトで知見がたまったので、共有するものである。 GitHub Actionsについて 非常に良い。VCSとCI/CDの統合は体験が良い。各種イベントをハンドリングできるが、そのイベントが元々Webhookで提供されていたものなので、Webhookを弄っていた身からすると非常に親しみやすかった。コードpush以外のイベントもハンドリングしてプログラマブルに扱えるので夢が広がる。 使い勝手とか具体的に良くなった点 リポジトリ直下の.github/workflows配下に既定のYAMLをpushすると、その設定にしたがって自動でアクションが動いてくれる。ブラウザ操作必要ないのは快適。 GitHub上でいろいろ完結できる Windowsのテストもできる! GITHUB_TOKEN 管理もうま
GitHubのprivate repositoryを含んだ場合のGo Modules管理 | おそらくはそれさえも平凡な日々
tl;dr CI/CD環境から複数のGitHubのprivate repositoryにアクセスさせたい場合にはmachine account(machine user)を使うと良い SSH KeyでもAPI tokenでもどちらでも良いけどSSH方式がGo公式repoでも紹介されている CircleCIだとSSH Keyの設定(User Key)が簡単でその他の設定がほとんど不要 本題 Goに限った話ではありませんが、プロジェクトで使っているprivate repositoryからまた別のprivate repositoryを参照している場合、CI/CDなどの外部環境からどのようにそれらにアクセスさせるか困ることがあります。 例えば、git submoduleを使っている場合や、Goの場合ですとGo Modulesで指定しているパッケージがprivate repositoryである場合な
お知らせ | おそらくはそれさえも平凡な日々
日頃お世話になっている皆様へのお知らせです。なるべく多くの方に直接お伝えしたかったのですが、この場でのお伝えになってしまった方には申し訳ありません。 はてなを退職します。4/17(水)が最終出社でした。所属は5/31(金)までです。 ずっとはてなで働きたいと思っていましたし、この絶好のタイミングで辞めてしまうのは勿体無いという気持ちもあります。ただ、次の挑戦に関して時間的な制約もあったため退職させてもらうことになりました。この詳細はまた別途お知らせできればと思っています。 2014年に現在のはてな東京オフィスの一人目のエンジニアとして入社し、その後、チーフエンジニアと、Mackerelのプロダクトオーナー(マネージャー)を兼務してきました。 チーフエンジニアとして組織に、Mackerelではプロダクトとビジネスに関わりました。入社当時、私一人だけだった東京オフィスのエンジニアも今では二桁に
ghqを使っていても(使っていなくても)goimportsを爆速にする | おそらくはそれさえも平凡な日々
「ghqを使ったローカルリポジトリの統一的・効率的な管理について」というエントリで書かれているように、 ghq.root と $GOPATH/src を一緒にする運用で長年やってきて、goimports が遅いことに少し困っていたのだが、以下でめちゃくちゃ快適になった。 .goimportsignore を使う goimports-update-ignore で自動生成をする 最新の dragon-imports を使う どれくらい快適になったかというと、エディタの保存時に goimports を気兼ねなく実行させられるようになったくらい。以下解説。 .goimportsignoreを使う 最近の goimports には $GOPATH/src/.goimportsignore という除外リスト機能がある。ここにインポート対象外にしたいディレクトリを $GOPATH/src 以下の相対パ
Goツールのリリースエンジニアリング | おそらくはそれさえも平凡な日々
前回: Goツールのリリースにおけるバージョニングについて 前回挙げた以下のリリース5段階の中で、バージョニングだけで1エントリになりましたが、今回は、2,3について。 versionをbumpする CHANGELOGを更新する 1,2での変更をgitに反映してタグを打つ ビルドする ビルドをアップロードする 具体的には、リリースに纏わるファイル更新をgitに反映さえてタグを打つところまで。ビルドする直前までとも言えます。 CHANGELOG.mdを自動更新する CHANGELOGは ghch で自動生成させている。規定の CHANGELOG.md をリポジトリに配置して、 % ghch -w -N $next_tag とすれば、魔法のように CHANGELOG.md を更新してくれる。生成された CHANGELOG.md はこんな感じ。 https://github.com/Songmu
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
レコードがなかったらINSERTして返すみたいなのを確実にやる | おそらくはそれさえも平凡な日々
find_or_create的なやつは大体どんなORMでも レコードを探す 無かったらINSERT みたいに実装することになると思う。ただこれだと、1と2の間でレースコンディションでエラー起きることがある。他のプロセスがINSERTしてしまうとかそういうやつ。 それを防ぎたい場合に、1の時点でFOR UPDATEするのはすごくダメで、空行にFOR UPDATEしたりするとMySQLだと盛大に乙るのは有名な話。 エラーを起こさないで、確実にレコードを取りたい場合にはどうすればよいかというと、以下のようにするのが良いと思っている。UNIQUEキー制約なりがちゃんと付いている前提。サンプルコードはTengの場合。 sub find_or_create_surely { my ($self, $table, $where, $opt) = @_; my $row; my $txn = $self-
おそらくはそれさえも平凡な日々: Akamaiが想像以上に物凄かった件 in Akamai勉強会
続きというか、お詫びを書きました。 文章を多少修正しました。技術的な点は色々誤りがあると思いますので、あまり信用しないでください。詳しくはgeekpageさんがじきに書いてくださるはずです。 入口にあった、Akamaiサーバーがリアルタイムに捌いているトラフィックを可視化した地球儀が映ったモニター。アメリカが早朝なのでトラフィックは850Gbpsと少な目(笑) それでもアメリカのバーの長さは凄い やすゆきさんという方が、Blogでひっそりと告知していたのが、IT勉強会カレンダーに載っていて、それを目ざとく見つけて行ってきた次第。募集枠5人とかだったので、焦って申し込んだら、実際そんなに募集は来なかったみたいで意外。僕なんか「Akamai」って書いてあっただけで飛びついたのに。内輪に近いノリだったてのもあると思うけど、案外「Akamai」には訴求力が無いのかね。まあ、インターネットの裏の支配
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
