Write your scripts in a modern type-safe and runtime-safe programming language that handles many bugs and mistakes during compilation process.
Write your scripts in a modern type-safe and runtime-safe programming language that handles many bugs and mistakes during compilation process.
◆ モチベーション ◆ 方法 ◆ 補足 ◆ YAML の解説 ∘ GitHub Actions を動作させる条件 ∘ 全体的な動き ◆ さいごに ◆ 参考 モチベーションGitHub と なんらかの CI を組み合わせて、マージ前にテストを通すことがよくあると思います。 ただ「CI が通るのを待ってマージするのはめんどくさいです!!!!」 ひたすらCIが通るのを待ってる人GitHub には マージ条件がすべてクリアされていれば勝手にマージしてくれる Auto-Merge という機能があります。(楽ちん) しかしこれには 落とし穴 がありました。 リポジトリの構成にもよりますが、ドキュメントやコードなど様々なファイルがリポジトリに存在していると思います。 ファイルによってチェック観点が様々なため、ファイルによって走らせる CI を変更するのが一般的でしょう。 とある Pull Request
以前にデータベースを自作しようとして、SQLiteのアーキテクチャを見てみたらVMだったことに疑問を感じ、それをツイートしたところ作者からリプをもらいました。 作者いわく、次のような背景があったとのことでした。 SQLiteを作った当初はデータベースエンジンのことをよく知らないがコンパイラのことをよく知っていた SQLデータベース・エンジンを書くという問題をコンパイラ構築の問題として扱うのは自然なことだった データベースエンジンのコアの部分をVMにするという発想がまったくなかったので、どんなメリットがあるのか?と気になっていました。 それを作者に聞いたら、詳細な説明ページを作ってくれました。 個人的にVMにしたことで、評価&実行のパフォーマンスは多少良くなると思うが、データベースエンジンのパフォーマンスにそれほど寄与していないんじゃないかな?って思ったりしました。 本記事はそのページについ
今回はバックエンドAPIでページネーションをどうやるかについての話なので、よくある無限スクロールUIのようなフロントエンド側の実装に関する話はしない。あくまでもAPI、もっと言えばRESTfulなAPIのリクエスト・レスポンスにおけるページネーションの話。 本気で深く考えるというよりざっくり検討したときの話です。 はじめに REST APIを実装するにあたってリスト系のAPIを提供する場合に必須といっても過言ではないのがページネーション。大量のリソースをレスポンスする場合にそれらを一気に返してしまうことは応答速度、転送量、クライアントサイドでの扱いづらさなどなどに繋がるので必須と言える。 最近、新たなAPIを開発するにあたってページネーションをする必要があったこともあり、今回はこのページネーションをどうやって提供するか整理して改めて検討してみた。 前提 TypeScript Nest.js
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く