はじめに SQLFluffは、SQLコードの静的解析およびフォーマッティングが可能なOSSツールです。 今回は夏休みの自由研究として、これをdataformに適用することを考えます。 モチベーション dataformではcompileやdry-runの機能がありますが、チーム開発でSQLをより安全に管理したい場合、それらの機能だけでは若干役不足感が否めず、SQLコードであれ一定の規約の元に秩序を作り安全にコードの反映を繰り返せる体制を作りたいというモチベがあります。というか、ほぼこのスレッドの質問主の方と同じモチベです。そして、これを単純にやろうとした際に回答者の方の内容にあるように、dataform独自に拡張されたsqlx構文の影響で簡単にはsqlfluffの恩恵を受けることが現時点ではできません。具体的にはconfigブロックやjs記述で怒られてしまいます。sqlfluffがsqlxの

はじめに アプリケーション開発やテストにおいて、テストデータを作成することは避けて通れない道です。しかし、実データに近いダミーデータを大量に用意するのは時間も手間もかかる面倒な作業です。個人情報保護の観点から実データをそのまま使うわけにもいきません。 今回、実データがある程度貯まっていることを前提として、実データから全てのフィールドを匿名化しつつ、統計的な特徴を維持してダミーデータを作る方法を考えてみました。 以下では、PythonとFakerライブラリを使用して、決定論的な匿名化を行うことでファクトとディメンションの（外部キー的な）結合を維持したままダミーデータを作成していきます。また数値のフィールドに関しては、統計的な特徴を保持しつつランダムな値を生成する[1]ことで、比較的実データに近いダミーデータを作成することを目指します。 注意事項 この記事は、リアルデータに基づいたダミーデータ

はじめに nest.jsをバックエンドとして開発したが、api docは人間の目で確認しながら、作成しました。悲しいと感じながら、人間ミスも多発でした。その現象を解決ために、コードからapi docを生成し、api docからフロントエンド用のschemaを生成するまでに自動化するのは本記事の目的です。 nest.jsとは Nest.jsは、Node.jsのための強力なフレームワークで、効率的なサーバーサイドアプリケーションを構築することを目的としています。TypeScriptをベースになっています。DIコンテナもサポートしております。 環境構築 nest.jsとvite.jsで環境構築してください。 サンプルコードはこちらもダウンロードできます。 ファイル構成 . ├── README.md ├── client // viteで作られたfrontend service │ ├── sr

はじめに クラウドインフラの構築・管理において、冪等性の担保や効率性の向上のために、TerraformやGitHub Actionsなどがよく利用されます。Terraformによるインフラのコード化は、手作業によるミスを減らし、設定変更のたびに発生する手間を削減します。さらに、GitHub Actionsとの連携により、コードの変更をトリガーとした自動テストやデプロイが可能になり、インフラ管理のライフサイクル全体を効率化できます。 本記事では、TerraformとGitHub Actionsを利用して、Google CloudインフラのCI/CDパイプラインを構築する具体的な手順を解説します。1時間程度でサクッと完了できるように具体的な手順を記載します。 なお、GitHubからGoogle Cloudへのアクセス許可には、Workload Identity連携を採用します。Workload

今までなんとなくEmacsは起動が遅いと思って使っていたのですが、正直もう何年もEmacsの起動時間チューニングなんてしていなかったので、この機会に自身の知識と設定まわりのアップデートを図ろうと思い立ちました。起動速度向上としてどんな対応方法があるのか調査し、それぞれどれくらい効果があるのか検証してみようと思います。 前提 高速化の手法については私がいろいろ調べてまとめるまでもなく、Emacsのプロフェッショナルの方々がまとめてくださっています。本記事は体験記でしかないので、より網羅的に学びたい方はこれらをおすすめします。 改善前 以降では M-x emacs-init-time を使って起動時間を測定します。私の環境ではマイクロ秒単位で表示されましたが、以下ではわかりやすく四捨五入してミリ秒で記載していきます。 一旦現状では以下の通りです。 まだ始まる前ですが、意外と速いなと思いました。

本稿の内容は、「コンテナは実行環境に合うようにビルドが必要。Cloud Runはx86_64アーキテクチャであり、このアーキテクチャ向けのビルドが必要」に尽きます。 発生した問題 M1チップ搭載のMacマシンでビルドした、FastAPIアプリケーションのDockerイメージをArtifact Registryにプッシュし、Cloud Runにデプロイした際に以下のエラーが発生し、サービスが起動しませんでした。 Error waiting to create Service: Error waiting for Creating Service: Error code 13, message: Revision 'hello-api-service-00001-555' is not ready and cannot serve traffic. The user-provided cont

経緯 なぜダウンタイム無し目指すのか 一つ大事な要因として、toBのアプリケーションなので、停止リリースするにはお客様の利用時間を避ける必要があり、それは通常深夜または早朝になりがちです。さらにお客様が増えると、この深夜早朝に仮に利用するお客様がいると、リリースするタイミングすら見つからなくなる恐れがあります。 アプリケーションのリリースからまださほど経っていないので、早いうちでダウンタイム無しでリリースを達成しないと、今後の開発サイクルに大きな支障が出るかねません。バックエンドのアプリケーションのリリースは、以前紹介した CloudRun Service + Jobsのコンビネーション で達成できていますが、今回はフロントエンドのアプリケーションをダウンタイムなしにリリースするのが目的です。 現象 SPAでユーザー影響ないリリース、いわばゼロダウンタイムのリリース（厳密には100%一致す

ちょっとしたスニペットの紹介です。結構雑なやつです PRのdiff行数に応じてラベルを貼るワークフローの書き方の紹介です。完成図は以下のようになります このようなラベルが、PRを作成した際に自動的に作られるようになります。PRが更新されればラベルも貼り直しされます。 スニペット .github/workflows/label-pr-diff-line-count.yml などのような名前で（ファイル名は何でもいいです）以下のような内容のワークフローを作成します。 name: PRの差分行数カウント on: pull_request: types: [opened, synchronize] env: # 差分行数を表すラベルのprefix DIFF_LABEL_PREFIX: diff/ # 差分行数を表すラベルの色 DIFF_LABEL_COLOR: '63D2D0' jobs: lab

ミドルフェーズスタートアップにおける開発組織の課題への向き合い方 というイベントで発表した資料です。 先に資料を作り始めていたので主題に若干かすっている程度で申し訳ないのですが、チーム開発をするうえでtRPCという選択は非常に大きな役割を果たしていると感じています。 上記のスライドでコンテンツは終わりなのですが、軽く思ったことなどを書きます。(実際の発表時の資料から一部編集しております。) TypeScriptの完全な理解に向かうためには、リリースノートをよく読み、TypeScriptをよく触ることだろうな、と思いました。 tRPCはきっと失っているものもいくらかありますが、適切でミニマルな抽象を提供し、スタートアップの大変さ（時間、予算）の中で確実に威力を発揮するとは思います。 現に実際に契約いただいたうえでお客様がすでに、日々利用しています。それだけでも十分にtRPCの価値は認められる

初めに こんにちは。福岡からOPTIMINDという名古屋のスタートアップで働いている津守と申します。 2024年2月に、Google Cloudの全認定資格（計11種）を取得しました。2年前には、Associate Cloud Engineer（ACE）、Professional Cloud Architect（PCA）、そしてProfessional Data Engineer（PDE）の資格を取得しています。PCAとPDEの更新時期が来たのを機に、全認定資格の取得を目指すことにしました。2023年12月24日から2024年2月12日の約2ヶ月間で、有効期限内のACEを除く残りの10の認定試験を全て初回で合格しました。Google Cloudに関する実務経験は約3年です。 全認定の取得を通じて得た知見を共有したいと思います。これには、各認定合格のための学習資源や学習方法、本資格が有用なシ

この記事はOptimind Advent Calendar 2023の25日目の記事となります。 経緯 本来別の記事を書く予定でしたが、直近プロダクトのインシデントがあったため、自分が直接責任者でもあり、その振り返りをこの機に書きたいと思いました。 今のプロダクトはユーザーの利用時間避けるために、暫定毎週の月曜にリリースしています。すると翌日の9時あたりに、ユーザーが利用したエラー記録がスラックのチャンネルに流れてきました。 その内容をチェックしたら、なんと、column reference "xxx" is ambiguousでした。 いやいやいやいや、まずいぞこれ、って第一印象です。次の瞬間に、ジョインしている時にテーブル名指定してないのでは？と答えも出ています。 が、こんなシンプルなものではありませんでした。 直接原因 曖昧なカラム名、これはSQLの経験者なら、必ずというほど経験され