こんにちは、 @kz_morita です。 今回は、『The Engineering Leader』という本を読んだので感想を書いていきます。 書籍について 『The Engineering Leader』は、O’Reillyから発行されている、エンジニアがリーダーシップを身につけるための実践的な書籍です。 今回はこの AI翻訳版を読みました。(以降目次など和訳されたものになります) https://learning.oreilly.com/library/view/ji-shu-rida/9798341632585/ 全体の目次 序文・導入部分 第1節：キャリアの決断と自己成長 第1章：キャリアの決断と最適化 第2章：キャリア目標のセットと実行 第3章：成長を受け入れる 第4章：前進する 第2節：セルフマネジメント 第5章：自身のエネルギーを管理する 第6章：自分の役割を定義し、適応させる 第7章：リーダーシップの幅を広げる 第3節：チームを拡大する 第8章：目からウロコの採用 第9章：人々を成功に導く 第10章：ベンチを作る 第11章：使命と戦略 第12章：戦術と実行 第13章：改善を推進する 第14章：良いこととはどのようなものか 感想など 現在チームリーダーのような役割をになっていますが、リーダーとしてどうすれば良いかは常に付き纏うテーマなため読んでみました。 本書は3つの主要セクションに分かれており、それぞれ自分自身のキャリア、セルフマネジメント、そしてチーム構築に焦点を当てています。 第1節：キャリアの決断と自己成長 この節では、リーダーとしての成長の第一歩として、自分自身のキャリアについて意識的に考えることの重要性が説かれています。 特に印象的だったのは以下の点です： キャリアについての決断を「レンタル」と「バイイング」の視点から考えるフレームワーク 自分が何を望み、どうすればそれを手に入れられるかを批判的かつ計画的に考えることの重要性 フィードバックを受け入れることが成長への第一歩であり、その過程は必ずしも快適ではないこと 組織が機能不全に陥っているときの「対処法」が、実際は長期的なスキル向上につながらない可能性があること 著者は、「あなたのキャリアにとって何が正しいかは、あなた自身にしか分からない」という大前提から、自己認識の重要性を強調しています。自分の制約、リスク、変化への欲求、好き嫌いを理解することが、効果的なリーダーシップの土台となります。 第2節：セルフマネジメント リーダーとして成功するには、まず自分自身を効果的に管理する必要があります。この節では、セルフマネジメントの具体的な方法が解説されています。 重要なポイントは： 自己管理とは、チームにとって効果的なリーダーとなるために、自身の役割を自己調整し定義する作業 「重要だが緊急ではない」戦略的な仕事のための時間を確保することの重要性 短期的なプレッシャーと長期的なインパクトのバランスを取る方法 リーダーシップスタイルを状況に応じて適応させ、幅を広げることの必要性 特に「優れた戦略は、壮大な構想ではなく、現実的で、具体的で、近接したもの」という視点は実践的で、すぐに取り入れられるアドバイスだと感じました。 第3節：チームを拡大する 最後の節では、チーム全体の成長と効果的な運営に焦点が当てられています。 印象的だったのは： 採用プロセスを標準化し、感覚ではなくデータに基づいて決断を下すことの重要性 チームメンバーの「帰属意識」と「達成感」が互いに影響し合うこと ミッション、戦略、戦術の各レイヤーがチーム機能の異なる側面に対応していること チームの「ベンチ」（人材の深さ）を構築することの重要性 特に「戦略なしに戦術を追加すると、価値が見出せないプロセスの精巧なパフォーマンスになる危険性がある」という指摘は、多くの組織で見られる問題を的確に表現していると思いました。

こんにちは、 @kz_morita です。 以前の記事で、dbtモデルでURLからクエリパラメータを抽出する際に正規表現を使った処理が重くなり、materialized = tableで改善した話を書きました。今回は別のアプローチとして、dbt_utilsパッケージのget_url_parameterマクロを使ってURLパラメータを抽出する方法について紹介します。 dbt_utilsの導入 まず、dbt_utilsパッケージをプロジェクトに追加する必要があります。packages.ymlファイルをプロジェクトルートに作成し、以下の内容を記述します。 packages:- package:dbt-labs/dbt_utilsversion:1.1.1# 執筆時点での最新バージョン作成したら、以下のコマンドでパッケージをインストールします。 $ dbt deps これでdbt_utilsのマクロが使えるようになりました。 get_url_parameterマクロの基本的な使い方 get_url_parameterは、URLを含むカラムから特定のクエリパラメータを抽出するためのマクロです。使い方は非常にシンプルで、以下のような形式で呼び出します。 SELECTurl,{{dbt_utils.get_url_parameter(field='url',url_parameter='foo')}}ASfoo_value,{{dbt_utils.get_url_parameter(field='url',url_parameter='bar')}}ASbar_valueFROM{{ref('source_table')}}このクエリでは、urlカラムからfooとbarというパラメータの値を抽出し、新しいカラムとして取得します。 以前の正規表現処理との比較 以前の記事で紹介した正規表現を使った方法と比較してみましょう。以前のコードは以下のようなものでした： withraw_dataas(selectid,urlfrom{{ref('source_table')}})selectid,url,-- パラメータ foo の値を抽出するための正規表現 regexp_extract(url,'.*[?&]foo=([^&]+)',1)asfoo_value,-- パラメータ bar の値を抽出するための正規表現 regexp_extract(url,'.*[?&]bar=([^&]+)',1)asbar_valuefromraw_dataこれをdbt_utilsを使って書き直すと、以下のようになります： withraw_dataas(selectid,urlfrom{{ref('source_table')}})selectid,url,{{dbt_utils.get_url_parameter(field='url',url_parameter='foo')}}asfoo_value,{{dbt_utils.get_url_parameter(field='url',url_parameter='bar')}}asbar_valuefromraw_data複数パラメータを一度に抽出する実践例 実際のプロジェクトでは、多数のパラメータを抽出したい場合があります。例えば、マーケティングキャンペーンのUTMパラメータをすべて抽出する場合、以下のようなモデルが考えられます： {{config(materialized='table')}}withraw_dataas(selectevent_id,timestamp,page_urlfrom{{ref('web_events')}})selectevent_id,timestamp,page_url,{{dbt_utils.get_url_parameter(field='page_url',url_parameter='utm_source')}}asutm_source,{{dbt_utils.get_url_parameter(field='page_url',url_parameter='utm_medium')}}asutm_medium,{{dbt_utils.get_url_parameter(field='page_url',url_parameter='utm_campaign')}}asutm_campaign,{{dbt_utils.get_url_parameter(field='page_url',url_parameter='utm_content')}}asutm_content,{{dbt_utils.get_url_parameter(field='page_url',url_parameter='utm_term')}}asutm_termfromraw_dataその他のURL関連マクロ dbt_utilsにはget_url_parameter以外にも、URLを処理するための便利なマクロがあります： get_url_host: URLからホスト部分（ドメイン）を抽出 get_url_path: URLからパス部分を抽出 これらを組み合わせることで、URLの様々な部分を簡単に解析できます： selectpage_url,{{dbt_utils.get_url_host(field='page_url')}}asdomain,{{dbt_utils.get_url_path(field='page_url')}}aspath,{{dbt_utils.get_url_parameter(field='page_url',url_parameter='search_term')}}assearch_termfrom{{ref('web_events')}}まとめ dbt_utils.get_url_parameterを使うことで、URLからのパラメータ抽出が簡単かつ保守性の高いコードで実現できます。パフォーマンスを重視する場合は、前回紹介したmaterialized = tableとの組み合わせが効果的です。 また、dbt_utilsにはURLパラメータの抽出以外にも、多数の便利なマクロが用意されています。SQL生成、テスト、Jinjaヘルパーなど様々な用途に使えるマクロが揃っているので、ぜひ公式ドキュメントやGitHubリポジトリを参照してみてください。 dbtを使ったデータ変換をより効率的に行うために、このようなユーティリティを活用していきます。

こんにちは、 @kz_morita です。 Snowflake のリソース管理を Terraform で行っていますが、その際に発生したエラーについて対応方法をまとめます。 エラー内容 以下のようなエラーが発生しました。 │ Error: 001423 (22023): SQL compilation error: │ invalid property 'QUERY_ACCELERATION_MAX_SCALE_FACTOR'; feature 'Query Acceleration Service' not enabled │ │ with module.snowflake_warehouse.snowflake_warehouse.sample_warehouse, │ on ../../modules/snowflake_warehouse/main.tf line 431, in resource "snowflake_warehouse" "sample_warehouse": │ 431: resource "snowflake_warehouse" "sample_warehouse" { │ terraform のコード自体は以下のようになってました。 resource "snowflake_warehouse" "sample_warehouse" { name = "SAMPLE_WAREHOUSE" warehouse_size = "XSMALL" auto_resume = true enable_query_acceleration = "false" max_concurrency_level = 8 query_acceleration_max_scale_factor = 0 auto_suspend = 60 statement_queued_timeout_in_seconds = 3600 statement_timeout_in_seconds = 3600 warehouse_type = "STANDARD" } 解消方法 以下のような記述に変更しました。

こんにちは、 @kz_morita です。 O’Reilly から出版された『Prompt Engineering for LLMs』を読みました。 書籍について Prompt Engineering for LLMs という本で、こちらは、洋書ですが、5 月に翻訳本も出るそうです。 https://www.oreilly.co.jp/books/9784814401130/ 日本語訳された目次は以下の通りです。 Ⅰ部 基礎 1. プロンプトエンジニアリング入門 2. LLMを理解する 3. チャットに移動する 4. LLMアプリケーションの設計 Ⅱ部 コアテクニック 5. プロンプトの内容 6. プロンプトの組み立て 7. モデルを飼いならす Ⅲ部 技術のエキスパート 8. 会話型エージェント 9. LLMワークフロー 10. LLMアプリケーションの評価 11. 先を見据えて 感想 まず、おさらい的な意味でこれまでの LLM の発展について書かれているのがよかったです。 ネット上で最新の情報は手に入れやすいですが、これまでの流れが把握できるのは本ならではで良い部分かなと思いました。 また、単純にプロンプトエンジニアリングだけでなく、LLM を含めたアプリケーションの設計や評価についても触れられていて、プロンプトエンジニアリングを学ぶ上での全体像がつかめる内容になっていました。 たとえば、赤ずきん原則といって、訓練データや見慣れたドキュメントのフォーマットにそって設計すると安定するなどの Tips が書かれています。 プロンプトの Tips 集というだけではなく、LLMアプリケーションの設計全体を体系的にみれるのがよさそうでした。一度よんで理解しきれなった部分もあるので、何度か読み返してみたいと思います。

こんにちは、 @kz_morita です。 最近、プログラミングをする機会が減ってきました。 なにかものを作るのが好きで、大学時代からプログラミングをしてきましたが、最近はあまりコードを書いていません。 本業では以下のようなタスクがメインになってきました。 プロダクトのマイルストーンを立てる 実装&設計レビュー 技術的な方針を考える チームメンバーとの 1 on 1 Biz 側の方との調整や、顧客との MTG また、仕事以外でもコードを書く機会がかなり減ってきました。 これらの理由により、最近の LLM による Coding Assistant の機能も使ってはいるものの、いまいちキャッチアップしきれてないというような状況です。 本業の方は、いろんなことがあり仕方ないですがプライベートでコードを書く機会が減っているのはなんとかして改善したいです。 とくに、LLM が吐いたソースコードが正しいかどうかというのを判断する審美眼は自らがコードを書くことでしか得られないと思っています。 無理にでも時間を作って、コードを書く時間を増やしていきたいと思います。特に LLM の力を借りればコードを書く初期コストはかなり下がるので、まずは小さなものからでも作っていきたいです。

こんにちは、 @kz_morita です。 最近 AI が優秀なアシスタントとしてエンジニアリングの現場に登場しています。 AI 以前は実際に自分でわからないことを調査・検証して、その内容を同じことで困るであろう人に対してブログを書くことに非常に価値を感じていました。 しかし、AI (おもに Coding Assistant や ChatGPT などの LLMs) が登場して依頼、AIに聞けば良いよねという感じになり、そもそも自分も Web 検索することは少なくなりました。これは他の人が書いたブログを読み問題を解決する子行為も同様に減っているなと感じています。 こういった現状のなか、技術系のブログを書き続けることに対するモチベーションを一体どこから得るのかという点についてかなり悩んでいます。 Input のためのブログ 一つあるとすれば、自分の Input のまとめとしての Output というものはあると思います。Input を促進させるための Output という位置付けです。 定期的な Ouput が Input がちゃんとできているのかというペースメーカーの役割を果たしてくれますし、Input の内容を整理するための良い機会にもなります。 Input を継続的にしていくために、ブログは続けていこうと思います。 最近、ブログに対するモチベーションが下がっているなと感じていたのですが、あらためて整理してみると、Input のためのブログという位置付けであれば、モチベーションを維持できそうです。 引き続きコツコツ書いていこうと思います。

こんにちは、 @kz_morita です。 今回は、O’Reilly から出版されている、『AI-Assisted Programming』を読んだのでまとめます。 書籍について 『AI-Assisted Programming』 という本で O’Reilly から発売されています。 こちら洋書ですが、以前のブログ でも紹介した AI 翻訳機能を用いて読んでみました。 目次は以下のとおりです。 Foreword Preface 1. New World for Developers 2. How AI Coding Technology Works 3. Prompt Engineering 4. GitHub Copilot 5. Other AI-Assisted Programming Tools 6. ChatGPT and Other General-Purpose LLMs 7. Ideas, Planning, and Requirements 8. Coding 9. Debugging, Testing, and Deployment 10. Takeaways Index About the Author 感想など こちらの本ですが、出版が 2024 年 4 月の本になっており、約 1 年前の本になっています。 そのため、情報としてはそこまであたらしくないですが、AIを用いてプログラミングをすることに対するイメージがいまいち湧いていない方などにとっては読んでみると良いかなと思いました。

こんにちは、 @kz_morita です。 今回 genspark でブログ記事を書いて見たら非常に精度高くできたので、手順をメモします。 もはや人間がブログ書く意味とは、とか思ったりしましたが一旦忘れることにします。 genspark を使った執筆 genspark に、最近搭載された スーパーエージェントという機能を使ってブログを書きました。 実際に書いた記事は以下になります。 Python の Enum の使い方 プロンプトはめちゃくちゃシンプルです。 まずは以下のようなプロンプトでテックブログのフォーマットを生成してもらいました。 個人で書いているテックブログのおすすめのフォーマットを生成して。 これで以下のようなフォーマットを生成してくれました。 テックブログのおすすめフォーマット 1. タイトル部分 - メインタイトル: 簡潔で検索エンジンに最適化された、内容を的確に表すタイトル - サブタイトル: 必要に応じて、メインタイトルを補足する情報 - アイキャッチ画像: 記事内容を視覚的に表現する画像 - 投稿日・更新日: 記事の鮮度が分かるよう日付を明記 2. イントロダクション - 問題提起: 読者が直面している課題や疑問点を提示 - 記事の目的: この記事で何が学べるか、どんな問題が解決できるかを明確に - 対象読者: 「このような知識レベルの方に向けた記事です」という説明 - 目次: 長い記事の場合、セクションへのリンク付き目次があると便利 3. 本文構成 - 見出し階層: H2、H3などを適切に使い、論理的に構造化 - コード例: 実際に動作するコードサンプルとその説明 - スクリーンショット: 操作手順や結果を視覚的に示す画像 - 図表・ダイアグラム: 複雑な概念を視覚化するための図解 - ステップバイステップ解説: 順を追った説明（特にチュートリアル記事に効果的） 4. 技術的詳細 - 環境情報: 使用したOS、ソフトウェアバージョン、ライブラリなど - 前提条件: 読者がこの記事を実践するために必要な準備 - 注意点・落とし穴: 実装時によくある失敗パターンとその回避方法 - ベストプラクティス: 効率的な実装方法や推奨パターン 5.

こんにちは、 @kz_morita です。 今回は Python での Enum の使い方についてメモをします。 はじめに プログラミングにおいて、関連する定数をグループ化して扱いたいケースは頻繁に発生します。Python 3.4 から標準ライブラリに追加された Enum クラスは、こうした用途に最適なソリューションを提供します。この記事では、Python の Enum の基本から応用、さらには StrEnum や IntEnum などの派生クラスまで、実用的な例を交えて解説します。 目次 Enum とは 基本的な使い方 Enum のメソッドとプロパティ IntEnum - 整数との互換性 StrEnum - 文字列との互換性 Flag と IntFlag - ビット演算のサポート auto() 関数の活用 Enum のカスタマイズ 実践的なユースケース パフォーマンスと注意点 まとめ 1. Enum とは Enum（列挙型）は、名前付きの定数値のセットを定義するためのクラスです。Python における Enum は、関連する値のグループを表現し、タイプセーフな方法でそれらの値を扱うことができます。 from enum import Enum class Color(Enum): RED = 1 GREEN = 2 BLUE = 3 Enum を使用することの主な利点は：

こんにちは、 @kz_morita です。 O’Reilly のサブスクリプションページをひらいたら、AI 翻訳の書籍が大量に追加されていました。memo として残しておきます。 AI 翻訳機能の追加 O’Reilly のサブスクリプションに AI 翻訳機能が追加されたという件がポストされていました。 「オライリー学習プラットフォーム」からのお知らせです。 AIを利用した機械翻訳による日本語版書籍が93点追加されました！その中からハイライトをご紹介します。 まずは『第8版 viとVimエディターを学ぶ』。メガネザルが帰ってきた！https://t.co/Nr08W0YdDd — O'Reilly Japan (@oreilly_japan) March 5, 2025 実際にサイトにアクセスしてみると、AI 翻訳された本がかなり追加されていました。 AI 翻訳の書籍 上記は、Data というタグで絞りこんだときの検索結果です。 かなり面白そうな書籍も多くあります。今まで Chrome 拡張機能の翻訳昨日などを使っていましたがかなり捗りそうです。 ちなみに軽く読んでみた感じだとそこまで違和感を感じることなく読めます。AI の精度はどんどん上がるのでこれはかなり捗りそうだと思いました。 邦訳版が出版されていない書籍も読めるのはかなり情報源の幅が広がるので嬉しいです。 まとめ 今回は O’Reilly のサブスクリプションに AI 翻訳機能が追加されたという件をまとめました。 とても便利なので、興味がある方は ACM 会員経由などで O’Reilly のサブスクリプションを契約してみるといいかもしれません。

こんにちは、 @kz_morita です。 AI を活用して Techblog を書いてみたら思いの外良かったのでメモです。 AI による Techblog 執筆の流れ AI でこのブログ以外の場所で公開するようのブログを書きました。 自分のブログで、公開済みの複数の記事をまとめたような記事を書きたかったため以下のような手順で書きました。 uithub で自分の techblog の文体を学習させる 自分のブログの対象の記事２つを読み込ませる 実際に記事を書いてもらってレビュー& リライト まず、以下の記事を大いに参考にしました Clineに自分をエミュレートさせて技術記事を代筆させてみたらビビった まず最初にやったのが、自分の文体の学習でした。 今回は試しに、uithub を用いて、プロンプトに記事の内容をまず読み込ませました。 uithub は、Github の目的のリポジトリやファイルのリンクの g を u に変更するだけで、内容を開いたテキスト形式でダウンロードできるサイトです。 ただ、ここは、cline などでソースコードをclone してから文体を学習させたほうが良かったと思います。 学習させたら、対象の２つの記事を読み込ませてこの２つを合わせてまとめた記事を書いてくださいというようなプロンプトを書きました。 書かれたものに対して、何回かレビューで指摘して納得行くものができました。 大体 6000 ~ 7000 文字くらいの記事を 1時間経たないくらいで仕上げることができたので個人的にはかなり満足しました。 まとめ Techblog をAI を活用して書いてみて非常に効率が良いなと思いました。 公開するブログ用じゃなくても、自分の読みやすい文体に公開されているドキュメントなどに変換してキャッチアップの効率化するのも良さそうだなと思います。 次は、リポジトリをクローンして文体を学ばせる方法を試してみます。

こんにちは、 @kz_morita です。 Windsurf という AI Editor を 1 週間使ってみた感想を書きます。 Windsurf Windsurf は AI Editor の一つで、Agent 機能が組み込まれているIDE です。 https://codeium.com/windsurf 紹介については、以下の記事などが参考になります。 https://zenn.dev/aimasaou/articles/14c724056f2cd5 使い方 この１週間は基本的に、自分ではコードを書かずにすべて Windsurf 上で Agent に書かせました。 現在 Claude 3.7 Sonnect が利用できるので基本的にこちらを使いました。 使い方としては、以下のような感じです。 実装したい要件と、それについての資料を読み込ませる AI に概要設計とTODOリストの作成を依頼する 概要設計とTODOリストが満足行くなようになるまでレビューを行う TODO リストが完成したら上から順番に実装してもらう 動作確認やテスト いきなり実装に行くのではなく、最初に概要設計を書かせてそれを細かくレビューするとかなり満足行く内容で実装してくれました。 今は試しに対象の GitHub のリポジトリに gitignore した markdown 置き場を作ってそこに設計書を書いてもらってます。 mermaid 記法とか普通にかけるのでシーケンス図とかクラス図とかも書いてもらえるのでかなり便利です。 概要設計レベルで認識ズレを埋められればあとは基本的に実装は割とサクッとやってくれます。 また、動作確認やテストも実行できます。 感想など 使ってみての感想としては、感覚として人にタスクをお願いするときのメンタルモデルとあまり変わらないなという点です。 まだ 1 週間ほどしかまともに使用してないですが Claude 3.7 Sonnet では、正しくコンテキストさえ伝えれば、結構制度の高いソースコードを書いてくれるなという印象です。

こんにちは、 @kz_morita です。 普段 Snowflake を Terraform で管理していますが、2025 年 2 月の中旬ころから Terraform の Plan や Apply にエラーが発生して反映ができなくなる事象がおきたので調査のメモです。 発生した事象 Terraform を適用しようと、GitHub Actions の CI 上から Terraform Plan を実行していたのですが、その際にエラーが発生していました。 内容としては、以下のように、snowflake_managed_account に関するところでエラーになっていました。 Error: giving up after 5 attempts with module.test_shates.snowflake_managed_account.test on ../../modules/ex_test/main.tf line 13, in resource "snowflake_managed_account" "test": 13: resource "snowflake_managed_account" "test" { 原因 Snowflake の 2024_08 Bundle が 2 月にデフォルト enabled で適用されました。 https://docs.snowflake.com/en/release-notes/bcr-bundles/2024_08_bundle 上記の公式サイトにも以下のように記載されています。 Status changed in the 9.

こんにちは、 @kz_morita です。 dbt の Generic Test は非常に便利なためかなりヘビーに使ってますが test の量が増えてくるとどんどん test の実行時間が増えてきます。 test の実行時間が増えるとローカルで開発する際の生産性が下がるためできるだけ高速化したいです。 今回は Custom Generic Test を書くことで高速化することができたので紹介します。 対象の Generic Test dbt には default で Generic Test が用意されています。 例えば以下のように、各カラムに対して not_null のテストを行うことができます。 version:2models:- name:my_modeldescription:"サンプルデータセット。7つのカラムに対して not_null テストを実施します。"columns:- name:iddescription:"各レコードのユニークな識別子。常に値が存在する必要があります。"data_tests:- not_null- name:order_iddescription:"注文を識別するためのID。必ず値が存在する必要があります。"data_tests:- not_null- name:customer_iddescription:"顧客ID。各注文に紐づく顧客情報として必須です。"data_tests:- not_null- name:product_iddescription:"商品ID。注文に含まれる各商品の識別子です。"data_tests:- not_null- name:created_atdescription:"レコードが作成された日時。時間軸の整合性のために必須です。"data_tests:- not_null- name:updated_atdescription:"レコードが最後に更新された日時。必ず正しい値が必要です。"data_tests:- not_null- name:statusdescription:"レコードの状態を示すカラム。NULL 値が含まれないことが求められます。"data_tests:- not_nullyaml に追加することで、not_null を保証するテストが実行できるので非常に便利です。 実際に利用される macro は以下のようなものです。 https://github.com/dbt-labs/dbt-adapters/src/dbt/include/global_project/macros/generic_test_sql/not_null.sql そしてこの Generic Test を実行すると以下のような SQL が対象のカラム分実行されます。 {%macrodefault__test_not_null(model,column_name)%}{%setcolumn_list='*'ifshould_store_failures()elsecolumn_name%}select{{column_list}}from{{model}}where{{column_name}}isnull{%endmacro%}上記の yaml の設定だと 7 回 SQL が投げられます。

こんにちは、 @kz_morita です。 普段 dbt でデータ変換を実装しているのですが、データモデルで重い処理があると dbt run の実行時間が増えてきます。 重い処理 dbt でモデルを構築していたのですが、SQL で URL に含まれるクエリパラメータをパースするような処理が重かったです。 具体的には以下のような SQL です。 withraw_dataas(selectid,urlfrom{{ref('source_table')}})selectid,url,-- パラメータ foo の値を抽出するための正規表現 regexp_extract(url,'.*[?&]foo=([^&]+)',1)asfoo_value,-- パラメータ bar の値を抽出するための正規表現 regexp_extract(url,'.*[?&]bar=([^&]+)',1)asbar_valuefromraw_dataこのモデルが、後続の様々なモデルから参照されていたのですが処理が重く dbt run に 30 分位かかっていました。 正規表現を使うのは CPU ヘビーな処理になりやすくボトルネックになりやすいのでここを改善しようとしました。 materialized = table で高速化 問題は、dbt のデフォルトの materialize が view になっていることです。 後続のモデルから複数参照されるモデルのため、view 担っている場合参照されるたびに正規表現によるパース処理が走ります。 パースは一度で良かったので、materialize = table にすることで高速化を試みました。 やり方は簡単で、SQL の先頭に以下のような config を書くだけでよいです。 {{config(materialized='table')}}withraw_dataas(selectid,urlfrom{{ref('source_table')}})selectid,url,-- パラメータ foo の値を抽出するための正規表現 regexp_extract(url,'.*[?&]foo=([^&]+)',1)asfoo_value,-- パラメータ bar の値を抽出するための正規表現 regexp_extract(url,'.*[?&]bar=([^&]+)',1)asbar_valuefromraw_dataこのようにすると一度パースされたパラメータがテーブルに保持されるため正規表現の処理が複数回走らなくなりその結果として実行時間を大幅に減らすことができました。 具体的には、30 分かかっていたところが 3 分ほどになりました。 今回の様な計算コストが高い処理などを行う場合 materialization を table にすることで高速化が期待できます。ただし、データをリアルタイムで反映したいようなケースの場合テーブルだと dbt run が走ったタイミングでしか同期されないため注意が必要です。

こんにちは、 @kz_morita です。 ACM 会員経由の O’Reilly のサブスクリプションに入っていましたが、いつの間にか閲覧できなくなっていました。 ACM 経由で O’Reilly へアクセスしようとしましたが、本のページへリダイレクトされて見れなかったのですが、調べたらサブスクリプションが切れていました。 O’Reilly のサブスクリプション非常に活用してたので更新をしました。 ACM Skills Bundle Add-On のサブスクリプションの更新 O’Reilly のサブスクプションは、ACM の Skills Bundle Add-On というものに含まれています。 https://learning.acm.org/skills-bundle こちらを更新すれば読めるようになります。 価格は年間 $75 となり、2025年2月現在で、11500 円弱となります。 だいたい書籍一冊あたり 3000 円ほどと考えると年間で 4 冊読むともとが取れることになります。 また、1 年間サブスクリプションをした感想としては、知りたい知識に関する本の内容の１部分を気軽に読めるというのは非常にありがたいなと思います。 特に似たようなテーマの複数の本からつまみ食いのように知識を得るのは非常に気軽に学ぶことができます。 通常の書籍を買うとすべて読まないともったいない気持ちになりますが、気になるところをつまみ食いはサブスクリプションならではだと思います。 また、2025 年 2 月現在で、2024 年 12 月に出版された書籍が読めるようになっています。 『Tidy First?』 なども読めるようになっています。最新の本は無いのですが 2ヶ月おくれならかなり良いなと思っています。 まとめ 今回は、O’Reilly のサブスクリプションを更新したので記載しました。 ACM 会員でないと、年間 $499 かかるのでかなりお得に読み放題することができます。 ACM 会員なれる方であればかなりお得なのでおすすめです。

こんにちは、 @kz_morita です。 dbt と Snowflake を使って開発をしていますが、Snowflake の UDF を作成する際に以前は schemachage などで行ってましたが、dbt の on-run-start の hook を用いて管理する方法が良さそうだったのでメモします。 on-run-start の hook で UDF を作成する on-run-start は、dbt_project.yml ファイルで指定することができます。 on-run-start:- '{{ create_udf() }}'以下のようなmacro を用意すると dbt run などの実行前に UDF を作成できます。 {%macrocreate_udf()%}createorreplacefunctionencode_uri_component("STR"VARCHAR)RETURNSVARCHARLANGUAGEJAVASCRIPTAS$$returnencodeURIComponent(STR)$$;{%endmacro%}ちなみに、on-run-start は dbt build, dbt compile, dbt docs generate, dbt run, dbt seed, dbt snapshot, dbt test などの前に発火されるようです。 https://docs.getdbt.com/reference/project-configs/on-run-start-on-run-end まとめ 今回は dbt の hook を使って UDF などを作る方法について書きました。 dbt 管理便利そうなのでしばらく運用しようとしてみようと思います。

こんにちは、 @kz_morita です。 Snowflake の SQL を書いてる時に、調べて便利だった Tips をまとめます。 EQUAL_NULL Snowflake では、= 演算子で値を比較できますが値が null の場合は結果も null になります。 null どうしなどを比較したい場合は、EQUAL_NULL 関数が便利です。 select'hoge'='hoge','hoge'=null,null='hoge',null=null,equal_null('hoge','hoge'),equal_null('hoge',null),equal_null(null,'hoge'),equal_null(null,null)結果は以下のようになります。 ‘HOGE’ = ‘HOGE’ ‘HOGE’ = NULL NULL = ‘HOGE’ NULL = NULL EQUAL_NULL(‘HOGE’, ‘HOGE’) EQUAL_NULL(‘HOGE’, NULL) EQUAL_NULL(NULL, ‘HOGE’) EQUAL_NULL(NULL, NULL) TRUE null null null TRUE FALSE FALSE TRUE null どうしの比較などを行うことができます。 ARRAY_UNIQUE_AGG ARRAY_AGG 関数を使うと、グループ化した結果を配列で取得できますが、重複を取り除く ARRAY_UNIQUE_AGG 関数が便利です。 selectgroup_key,array_agg(value)asnon_unique_arr,array_distinct(array_agg(value))asunique_arr,arrray_unique_agg(value)asunique_arr2fromtable_namegroupby1今まで ARRAY_UNIQUE_AGG 関数は存在を知らなかったので、ARRAY_DISTINCT も使っていましたがこちらの方が便利です。

こんにちは、 @kz_morita です。 生成AI系のサービスがたくさん出てきましたが、genspark.ai が個人的に良さそうなので簡単に紹介します。 Genspark とは https://www.genspark.ai/ Genspark.aiは、AIエージェントを活用した検索エンジンです。 入力したクエリについてリアルタイムで検索が行われ、結果として Sparkpages というサマリーのページも生成してくれるので非常に便利です。 プランとしてPlus プランが存在し、いわゆる普通の Chat 機能や、画像生成などいろいろな機能が使えるようになります。 Plus プランは今なら友達招待で 1ヶ月間トライアルができるみたいなので、試してみました。 例えばチャット機能は 2025/01/19 現在で以下のモデルが使用できました。 GPT-4o GPT-4o Mini o1 Claude 3.5 Sonnet Claude 3.5 Haiku Gemini 1.5 Pro Gemini 1.5 Flash DeepSeek V3 また、これらのAIモデルを自動で組み合わせる Mixture-of-Agent という機能もあり便利です。 以下はチャット機能で試しに Genspark.ai で Genspark.ai の紹介記事を書いてもらおうとしたときに表示されたマインドマップです。 まとめ Genspark.ai について紹介しました。 Google 検索の代わりとしてまずは使っていこうと思ったのと、チャット機能があれば一般的な生成AIでやりたいことはできそうなので良さそうだなと思います。 とりあえず、１ヶ月間 Plus プランが使えるので使い倒してみようと思います。

こんにちは、 @kz_morita です。 スタッフエンジニアの道 ―優れた技術専門職になるためのガイド という本を読んだので感想などを書いていきます。 書籍について 『スタッフエンジニアの道 ―優れた技術専門職になるためのガイド』という本で、O’Reilly から発売されています。 https://www.oreilly.co.jp/books/9784814400867/ 以下のような目次になっています。 本書への推薦の言葉 序文 イントロダクション 第I部　大局的な思考 1章　では、具体的に君はここで何を？ 2章　3つの地図 3章　全体像を描く 第II部　実行 4章　限りある時間 5章　大規模プロジェクトをリードする 6章　なぜ止まってしまったか？ 第III部　レベルアップ 7章　今はあなたがロールモデル（お気の毒さまながら） 8章　良い影響力を広げる 9章　この先は？ 参考文献 訳者あとがき 索引 感想など この書籍は、スタッフエンジニアにどのような役割が求められているか、どのようになるべきなのかという点がかなり具体的に書かれていて非常に良かったです。 具体的には、全体像を描くことや、実際にプロジェクトを進めるうえでどのように振る舞うべきかなどが書かれています。 プロジェクトのリーダーとして進める際にどう進めるかや、同じチームの人に対してどのように支援していくかといった具体的な戦略が書かれています。 また、スタッフエンジニアになったあとにどう自身の時間を使うかや、キャリアをどのように構築していくかといったアドバイスも書かれていました。 同じスタッフエンジニアについて書かれた、 『スタッフエンジニア　マネジメントを超えるリーダーシップ』 との違いとしては、『スタッフエンジニア　マネジメントを超えるリーダーシップ』の本では、そもそもスタッフエンジニアとは何なのかという点が中心にかかれていました。 今回の書籍では、スタッフエンジニアになるためにどのような振る舞いをすべきなのかという点が多く書かれており、実践編という感じでした。 両方の本と合わせて読むとスタッフエンジニアについての理解が深まり良さそうです。 まとめ 今回は、書籍を読んだ感想をまとめした。かなり実践的で普段開発している中で意識していることや意識できてないけど大事だなと思うことが多く書かれていて非常に学びになりました。エンジニア人生のバイブルとなりそうな本なので何回も読み直そうと思います。

こんにちは、 @kz_morita です。 2025 年が始まったので今年の抱負などを書いていこうと思います。 やりたいこと 2025 年も引き続き学び続けてその結果をアウトプットしていきたいです。 具体的には、以下のようなことは引き続きやりたいです。 書籍 30 冊読む ブログは年 52 記事目標 プライベートでコードを書く 書籍 30 冊読む 書籍については、今年は月１冊ほどのペースで 12 冊でした。来年はもう少しペースを上げて 30 冊を目指したいです。 書籍数は別に重要な指標ではないですが、これくらいの頻度で Input を続けていくことは大事ですし、ちゃんと Input 習慣できれば自ずとこのくらいの冊数になるのかなと思っています。 ブログは年 52 記事目標 今年も週一の更新を続けて 52 記事を書いていこうと思います。今年は週一の更新に遅れがちだったのでもう少し余裕を持って更新していきたいです。 プライベートでコードを書く こちらは、去年あまり達成できなかったことです。 本業でも、徐々にコードを書く機会が減ってきておりコードをちゃんと書き続けることへのプライオリティを自分の中で高めなければと思ってます。 気になっている技術や仕事周りで使用するツールなど題材はたくさんあるはずなのでコードを書いていきます。 特に使っている OSS などに対してちゃんとコントリビュートするなどやっていきたいです。 まとめ 今年も、心身の健康は第一で引き続き学び続けていく年にしたいです。 去年は学びなどの時間を基本的に週末を使っていましたが、平日の時間をもう少し有効活用しないと達成が難しいなと感じています。 平日にもちゃんと時間を作って学べるようなリズムを作ることが今年の最初の課題です。 あとは、学習や思考の体力をつけるためにちゃんと運動もしていきます。 本年もよろしくお願いいたします。

こんにちは、 @kz_morita です。 気がつけば 2024 年も年の瀬ということで、毎年恒例の WordCloud でブログを通して今年を振り返ります。 今年の成果 まず今年は、ブログのを 52 本記事を書きました。今年もところどころ遅れるところはありましたが、週一でブログを書き続けることができました。 今年の WordCloud は以下のようになりました。 今年はチームリーダー的なポジションとして、開発チームを率いていく立場に就かせていただくことになったのですが、それが WordCloud にも如実にあらわれているのが面白いなと思いました。 本 や 書籍 というワードも多いですが、今年の書籍の感想系は以下の記事を書いていました。 『チームトポロジー』を読んだ 『Fundamentals of Data Observability』を読んだ 『GitLabに学ぶ 世界最先端のリモート組織のつくりかた』を読んだ 『エンジニアリング組織論への招待』を読んだ 『プログラマー脳』を読んだ 『達人プログラマー』を読んだ 『データエンジニアリングの基礎』を読んだ 『達人に学ぶDB設計 徹底指南書』を読んだ 『関数型ドメインモデリング』を読んだ 『A Philosophy of Software Design』を読んだ 『チーム・ジャーニー』を読んだ 『実践 DataOps』を読んだ 書籍は年間通して 12 冊読んでいて、月１冊ペースでは読めていそうでした。 チーム関連の書籍が増えているのも今年の特徴です。 自分がチームを率いていく立場に始めたなった不安感などから学ぼうとしていたのだと思います。 ブログ以外の活動としては、以下に取り組みました。 技術書典16 でボードゲーム頒布 技術書典 16 でボードゲームを頒布した話 技術書典17 で 書籍の共著 技術書典 17 で本を書きました 他社との合同勉強会での登壇 1本 ここには載せませんが、会社の TechBlog も 2本書いてました。

こんにちは、 @kz_morita です。 今回は、『 実践 DataOps 』という本を読んだので感想を書いていきます。 書籍について 『実践 DataOps』という書籍で、翔泳社から発売されています。 https://www.shoeisha.co.jp/book/detail/9784798179247 以下目次です。 ◆Part 1 DataOps序論 ・Chapter 1 データサイエンスの問題点 ・Chapter 2 データ戦略 ◆Part 2 DataOpsの実践に向けて ・Chapter 3 リーンシンキング ・Chapter 4 アジャイルなコラボレーション ・Chapter 5 効果測定とフィードバックの仕組み作り ◆Part 3 さらなるステップ ・Chapter 6 信頼の構築 ・Chapter 7 DataOpsへのDevOpsの適用 ・Chapter 8 DataOps実現のための組織作り ◆Part 4 セルフサービス型組織 ・Chapter 9 DataOpsで用いるテクノロジー ・Chapter 10 DataOpsの導入手順 感想など この書籍では、データを利用したプロダクトを開発する際にどのように DataOps を実現していけばよいかという点について網羅的にかかれていました。 たとえば、データプロダクトを作る際にどのようにデータを取り扱っていけばよいかについて書かれています。 既存のツールなども紹介されていましたが、それだけではなく、チーム間でどのようにコラボレーションしていけばよいかという観点やまず何から始めていけばよいかという点が書かれていたのが参考になりました。 書籍の中で、 DataOps マニフェストが紹介されています。 https://dataopsmanifesto.org/ja/ データサイエンス、データエンジニアリング、データ管理、ビッグデータ、ビジネスインテリジェンスなどと呼ばれるものを問わず、当社は分析において以下のようなことを重視するようになりました。

こんにちは、 @kz_morita です。 久しぶりに Python を触って日付周りの処理を調べたのでまとめます。 datetime datetime モジュールについて見ていきます。 import datetime 現在時刻の取得 >>> print(datetime.date.today()) 2024-12-22 >>> print(datetime.datetime.today()) 2024-12-22 23:31:49.193061 初期化 >>> print(datetime.date(2024,12,1)) 2024-12-01 >>> print(datetime.datetime(2024,12,1,12,0,0)) 2024-12-01 12:00:00 日付の加算 timedelta を使用すると加算などが行えます >>> today = datetime.date.today() >>> today datetime.date(2024, 12, 22) >>> today + datetime.timedelta(days=1) datetime.date(2024, 12, 23) >>> today - datetime.timedelta(weeks=1) datetime.date(2024, 12, 15) 文字列 <-> 日付 文字列 -> 日付 >>> print(datetime.datetime.strptime("2024/12/22", "%Y/%m/%d")) 2024-12-22 00:00:00 日付 -> 文字列 >>> today datetime.date(2024, 12, 22) >>> print(today.