この U1 and U2 are identical types （=U1とU2が一致する）という定義が重要で、このU1とU2にそれぞれ等価判定をしたいXとYを代入して、かつ他の条件を必ず満たすようにすれば、型の等価判定が実現できる。 ではなぜ<T>() => (T extends X ? 1 : 2)のような定義になってるかというと、これは「遅延評価のため」と述べられている。 Equal<X,Y> の実装に必要なのは Conditional Types 同士の比較なのだが、通常 Conditional Types は簡約されるため、Conditional Types 同士の比較になることは少ない。 T extends X ? 1 : 2 の評価をする際、Tは必ず未定である（この定義ではどの段階においてもTが具体的に決まることはない）。コンパイラは Conditional Types (T

スターフェスティバル株式会社 の バックエンドエンジニアの @ikkitang です。 上記の自己紹介にもありますが、私はプライベートで日本PostgreSQLユーザー会の理事をやっていて、その活動の一貫として先日の 2022-10-01（土)に行われたOpen Source Conference 2022 Online/Hiroshimaで最新バージョンのPostgreSQL15の最新機能について発表してきました。 スライドは公開しておりますので、以下を見て頂く事で全てを完全に理解していただけるかもしれませんが、解説しながらまとめたいと思います。 PostgreSQLのリリースサイクル PostgreSQLはPostgreSQL開発コミュニティというユーザーグループ主導で開発されています。 毎年9~10月にメジャーバージョンをリリースしておりまして、今年はPostgreSQL15のリリー

これは、とある僕のチームが運用しているWebアプリケーション　(Go製) の、ヘルスチェック用エンドポイントの (リクエストハンドラーの) コードです。リクエストがきたら200 OKを返すだけの、シンプルな実装です。 func health(w http.ResponseWriter, _ *http.Request) { w.WriteHeader(http.StatusOK) } ところが、たったこれだけの処理しかしていないエンドポイントのレイテンシが、ある時からピーク時に著しく劣化するようになり、ひどい時には最大3.4秒もかかるようになってしまったのです。 なぜこのようなことになってしまっていたのか、またそれをどのように調査し、解決したのかについて解説します。 システム概要 今回問題となったWebアプリケーションはGoで書かれています。実行環境は Kubernetes (GKE) で

はじめに 普段はスタートアップでBtoB SaaSの開発をしているtaroと申します。 今回は、Reactのmemo化について考えている中で抱いた 「なんでReactは標準でComponentをmemo化していないんだろう？」 という疑問を解消するために、色々と調べたり考えたりした内容をまとめました！ 途中でrenderのタイミングや、memo化で再renderが抑えられる理由などの前提知識の復習も含めていて、memo化について詳しくない方もmemo化の勉強にもなると思うので、ぜひぜひ読んでみてくださいー！ なぜこんな疑問を抱いたのか？ まずはそもそも僕がタイトルにあるような疑問を抱いた背景です。 疑問を抱くまでの思考プロセスはこんな感じです。 「再renderが余分に走ってて画面が重いから最適化したいなー」 →「React.memo()を使ってComponentをmemo化しよう！」 →

追記: 2024-07-20 Testcontainers を使いましょう。 概要 dockertest は go でテストを書く際に docker 経由で指定したコンテナを起動してくれてテストが終わったらコンテナを削除してくれる便利ライブラリです。 モチベーション 時雨堂では TimescaleDB という PostgreSQL に TSDB 拡張を追加した少し変わった RDBMS を利用しています。 TimescaleDB 専用の関数があったりするため、モックなどを使わずにテストを書くのが現実的です。 dockertest ory/dockertest: Write better integration tests! Dockertest helps you boot up ephermal docker images for your Go tests with minimal wo

はじめまして、おおさき（@massa_potato）と言います。 僕は北海道で畑作農家をやっています。楽しく農業を続けるため、2019年頃からノーコード開発ツールやプログラミングをゼロから学んで身の回りのデジタル化やアプリ制作を行い、現場作業の効率化・経営の見える化を進めています。 本記事では、僕が実際の農業現場でどんな技術でどんなモノを作り、どんなふうにIT活用しているのかを簡単にまとめてみました。 制作物 技術としては主に、データベース代わりにGoogleスプレッドシートを使いつつ、ノーコードツール「Glide」やプログラミング言語「GAS(GoogleAppsScript)」を利用しています。全体的にあまり難しい技術を使わず、必要に応じて小さなモノを作って運用しながら改良していく、というのが好き。 Glide GAS(GoogleAppsScript) 農場の情報管理アプリ Glid

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

どうもnote株式会社のSREのみーにです！ 私の素性を知らない方は先に自己紹介ページや入社エントリなどを参照ください… :pray: 最初に結論(作ったもの)SchemaSpyをGithub Actionsから定期実行できるworkflowを作成しました！ 指定したデータベースのドキュメントを日次で自動生成&更新することができる仕組みです。 以下リポジトリからどなたでも利用できます！ この記事では、noteでSchemaSpyをGithub Actionsから定期実行できるworkflowが必要になった背景をお話ししていきます！ なぜやったか: 前提noteのアーキテクチャ(とても簡略化しています)noteでは、データベースを以下のような形で運用しています。 AWS Auroraでデータベースを運用中 Rails(Active Record)のmigration機能でテーブル定義を変更し