ぼくはAmazonのシアトル本社でセールの機能を開発している。Amazonでお買い物をしていると「30%引き」や「20%オフ」のようなディスカウントを発見して喜んでくださっている方もいると思うけれど、あのディスカウントを提供する仕組み自体が一つの大きなプロダクト（システムと言ってもいいかな）になっている。そしてそれを支えるためにシアトル、バンクーバー、ベルリン、バンガロールにまたがるグローバルなチームによって開発・管理している。 そんなわけでぼくはPM (プロダクト・マネージャー) として日々セール機能に関するプロジェクトを回している。たくさんの刺激的で興味深いプロジェクトに恵まれてきたわけだけど、その中で一つとても記憶に残るプロジェクトがあった。 それは「定期おトク便」に関するものだ。定期おトク便というのは、平たくいうと日頃からリピートして買う商品（例えば飲料水や洗剤のような日用品）につ

2023年か2024年か記憶が怪しいものもあるが自分の中で"最近乗り換えたもの"ぐらいのノリで書いていく。レイトマジョリティの自覚あり。 JetBrains系エディタ（RubyMine etc.） → Cursor (移行中) 一番大きい移行。2024年末〜2025年始に移行を試み、今も手探り中。 www.cursor.com きちんと評価するためにPro planを契約した。 Cursor Tabの体験が圧倒的に良い コード補完は古くはTabnine、2022年からGitHub Copilotを経験してきたが段違いに感じる シンプルに補完内容が優れているだけでなく 複数行の変更、変更後の次の変更の提案などが高速で賢く "ワカっている" 感がすごい Composer (normal mode. not agent) がかなりまともなコード出力や修正提案をしてくれる 年始に新しいツールを書き

オンライン勉強会「datatech-jp Casual Talks #6」の登壇資料です。 https://datatech-jp.connpass.com/event/337374/ ■ 採用・カジュアル面談 https://kazaneya.com/recruit ■ サービス提供 …

こんにちは。サイボウズ株式会社 生産性向上チームの平木場です。 僕たち生産性向上チームは毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催しています。 本記事はその時のネタをまとめたものです。 2023-01-25 号から、基本的に隔週で連載することとしました。たまに単独でも投稿するかもしれません。 今週は 2024-12-18 単独号です。 今回が第 172 回目です。過去の記事はこちら。 news 📺 Find and fix Actions workflows vulnerabilities with CodeQL (Public Preview) - GitHub Changelog GitHub Code scanning の CodeQL において、GitHub Actions のワー

MacBook Pro買いました プライベートで14インチのMacBook Pro(M4)買いました。25万円くらいしました。高いですね。 4年前に買ったMacbook Air(M1)も、ものすごい困るということもなかったのですが、使っていてもっさり具合が気になるようになってきたのと、登壇中にKeynoteが固まるということもあったので、思い切って買い替えることにしました。 セットアップの前提 PC買い替えたら、インストールソフトや設定を見直すよい機会と捉えて1からセットアップすることにしているので、セットアップのメモをここに残しておきます。 前提として、完全に自分の好みなのですが、デフォルト設定から大きくカスタマイズはしていません。インストールするソフトも、自分の必要最低限のソフトだけにしています。なんなら壁紙すらデフォルトから変えないです。 昔は結構カスタマイズしたりしていましたが、な

dbt Advent Calendar 2024 23日目の記事です。 dbtのincremental_strategyに新たにmicrobatchが導入され、大規模な時系列データの処理方法が革新的に変わろうとしています。 この記事では、microbatchと従来のincrementalを比較しながら、本番環境への導入に向けた重要なポイントを解説します。 前提: batch_size="hour" で動かすと壊れる @2024/12/23時点 当記事では筆者の実際の運用環境を想定し、batch_size="hour"での実装を前提に解説を進めます。 ただし、現在dbt-coreのバグにより、hourオプションは使用できない状態です。 hourでの運用を検討されている方は、以下のissueの解決をお待ちください。 microbatchの基本設定 {{ config( materialized

TL;DR BigQuery Emulator と fake-gcs-server を組み合わせることでbqコマンドでCSVファイルを読み込んでETLのインテグレーションテストができた。 はじめに こんにちは。先日こちらの記事を書いたCTO-Officeの藤本です。そこでは書ききれなかったETLについて書いておきたいと思います。 ビッグデータを扱うETLのテストを行いたい場合に、DBからExtractするEの部分など、ユニットテストやモックでは担保できないところが出てきます。 そのようなインテグレーションテストに、OSSのBigQuery Emulatorを活用できる場合があります。 背景 モノタロウでは、マイクロサービスで実装したGoのロジックをApache Beam Go SDKでラップして、Cloud Dataflowで定期実行することで商品の出荷目安のデータを生成して様々なチャネル

会社のAdvent Calendarもdatatech-jp Advent Calendar 2024も枠がめでたく埋まってしまったので、12月感は特にないエントリです。 仕事でdbtのリポジトリの初期設定をすることが時々あるけど、ほぼ同じようなことをやっているので、さっと引用できるようにまとめておきます。この辺をやっておくと、大体安心して仕事ができる、という感覚になります。なお、dbtに関連ないチーム開発で必要な要素も入ってます。 優先度: 高い リポジトリの権限設定 CODEOWNERの設定 Pull Requestテンプレートの導入 sqlfmt / sqlfluffの導入 優先度: 普通 READMEの記載 dbt CloudでのCI/CDの設定 レイヤリングのルールを決めておく レビュー依頼の通知設定 Devcontainerの設定 コストの監視 Renovateの設定を行ない、

こんにちは！ Magic Moment フロントエンドエンジニアの @morishin です。 この記事は、Magic Moment Advent Calendar 2024 4 日目の記事です。 はじめに 開発あるある 皆さん開発をしていて、コマンドの "待ち" が長いとき、こんな経験はありませんか。 「ビルドに時間がかかるなぁ」 (別の作業をする) 「もう終わったかな (ﾀｰﾐﾅﾙﾁﾗｰ」 「まだかー」 (以降無限ループ) 作業に集中できない！ 逆に 「このインストール時間かかるなぁ」 「終わるまでちょっと休憩しようかな (ｽﾔｧ」 〜3 時間後〜 「...あっ、いつの間にか終わってた！」 処理の完了に気付かずついつい休憩しすぎた！ ありませんか？ありますよね？ まあ休憩しすぎたっていうのはないにしても、実はエラーで処理が中断していたのに気付かなかった、というのはあるあるな気がします。

導入 この記事は ノバセル Advent Calendar 3 日目です。 こんにちは、ノバセル 24 年新卒の秦です。 テクノロジー開発部にて、データエンジニアをしています。 弊社では dbt を使っています。 dbt は v1.8 から unit_test が使えるようになりました。 今回はその unit_test の機能の 1 つである overrides について紹介したいと思います。 overrides はマクロや変数の出力を unit_test 時のみ上書きすることができる機能です。 overrides はこんな場面で使えますよ、私は overrides をこんな場面で使いましたというのを例を添えて紹介します。 紹介 例 1:dbt_utils.star を使用している時 dbt_utils.star は一部のカラムを除いた全カラムを取得できるマクロです。 色々便利なのですが、

スライド概要 『EEKANJI NO GAME GAKKAI '24』にて、ゲーム業界で働くエンジニア 湊 和久さまにご講演いただいた際のスライド資料になります。 【講座内容】 働き方改革を経て、日本のゲーム業界の労働環境は大きく改善されました。長時間労働も、圧強めの指導も、今や過去の遺物。 しかし裏を返せば、ホワイト化がもたらした自由時間と自由意志を、自ら「QoL向上」や「自己学習」に振り分ける必要のある、自己責任強めの時代が来たと言えるでしょう。 この「サボリには厳しい時代」のサバイバル術を、 サボリの講演者と一緒に考えてみませんか。

面白法人グループアドベントカレンダー2024 2日目の記事です。SREの藤原です。 2024年も暮れようとしていますね。ところで今から5年前のこと、builderscon tokyo 2019 というイベントで「レガシーサーバーを現代の技術で再構築する」というタイトルで発表しました。 speakerdeck.com この発表は、当時 Amazon EC2 のシングル構成で動作していたサーバー(SVN, Redmineほか、社内の開発支援ためのサービスが動作していました)を、Amazon ECS をはじめとしたコンテナや AWS のマネージドサービスを用いてリプレイスした、という内容です。 2019年末にはこの発表で予定していた移行作業は全て完了し、以下の画像のように EC2 が空っぽになりました。 あれから5年 さて、早いもので2019年から5年が経過しました。このシステムで動いていたサー

こんにちは。PharmaXの上野(@ueniki)です。 2024年10月31日、PharmaXはFindy Team+ Award 2024のSmall Divの部（エンジニア組織が50人未満）を受賞しました！ この賞は開発生産性向上に関して優れた取り組みを行った企業に贈られるものです。 この賞も今年で3年目を迎え、開発生産性という言葉が何となく日本のIT企業に受け入れられてきているように感じます。 特にスタートアップで、ソフトウェア開発に携わっている方は、一度は"開発生産性"という言葉を聞いたことがあるのではないでしょうか。 ですが、開発生産性という言葉自体は聞いたことがあるものの、よく分かっていないという言葉を聞くことも少なくはありません。 "開発生産性向上"というと、響きは素晴らしいものの、本当に意義のある活動なのでしょうか？ 「そもそも開発生産性とは何なのか？」 「開発生産性を向

G-gen の武井です。当記事では Google Cloud と GitHub Actions (Terraform) を連携する Workload Identity を作成する bash スクリプトを紹介します。 はじめに 概要 前提条件 免責事項 ソースコード スクリプトの使い方 認証 変数設定 実行 リソースの確認 Workload Identity プール・プロバイダー サービスアカウント IAM Policy デモ 構成 ソースコード (Terraform) Terraform ディレクトリ構成 ワークフロー (terraform.yaml) env/demo 配下 (呼び出し側) modules/apis 配下 (モジュール) プルリクエスト (terraform plan) マージ (terraform apply) はじめに 概要 当記事で紹介するのは、Google Clo

本記事のテーマはGitHub Actionsです。個人的に「もっと早く知りたかった！」と考えているグッドプラクティスを、厳選してお届けします。想定読者は次のとおりです。 普段GitHub Actionsを雰囲気で運用している人 GitHub Actionsをコピペや生成AIで乗り切っている人 他者が書いたコードの意味をより深く理解したい人 本記事でGitHub Actionsの基本は説明しません。グッドプラクティスを含めて基礎から学びたい人は、拙著『GitHub CI/CD実践ガイド』を読んでみてください。GitHub Actionsの基本構文から運用のコツまで、網羅的に解説しています。さて書籍紹介はこれぐらいにして、さっそく本題へ進みます。 GitHub Actionsの設計指針 GitHub ActionsはCI/CDや各種自動化で役立つ、汎用的なワークフローエンジンです。一般的に長期

2024年10月18日 日本SPIコンソーシアム（JASPIC） ソフトウェアプロセス改善カンファレンス2024

あなたは依頼されたものをそのまま作ってませんか？ 以前、登壇したときに、「依頼されたものをそのまま作るな」という話をしました。 これだけ聞くと、「うんうん、確かにね。それはそうだよね」という感じかもしれないですが、いざ実践するとなると結構難しい部分もあると思うので、詳しく書いてみようと思います。 依頼と課題を分けて考えよう依頼されたものをそのまま作らないためには、まず「依頼」と「課題」を分けて考えるクセをつけることが重要です。依頼というのは、依頼者が発した言葉そのものです。例えば、 「売上を見れるダッシュボードを作って」 と言われた場合、これが依頼になります。 しかし、これは「課題」ではありません。課題というのは、依頼の背後に存在していて、依頼者が依頼によって解決しようとしている問題のことです。 例えば、先ほどの例で言うと、「売上を見れるダッシュボードを作って」という依頼の背後には、 ・

3行まとめ データに対する期待値を定義するData Reliability Levelという活動を始めています Data Reliability Levelを設定するには「XXXの場合にはAAAの項目は入力が必須」といった条件分岐や項目数も多く、レビューが大変という課題がありました 最近のJSON Schemaは記述力が高いため、上述のような制約も記述することができました 3行まとめ 前提: データの出口に対する期待値を明示的に設定したい 課題感: 各Data Reliability Levelに対する設定が適切に設定されているかを確認するレビューが大変 解決方法: 各Data Reliability Levelに対する必須入力項目をJSON Schemaで機械的にvalidateする 見所 条件分岐を記述する $refと$defsで繰り返しの記述を避ける anyOfでより柔軟な制約を設定

こんにちは、CCCMKホールディングスのタロウです。 先日のSnowflake World Tour Tokyoでは弊社取締役の撫養がSMCCの白石執行役員と基調講演で企業間データシェアの事例を発表させていただきました。 さて、データシェアについては皆様も既にご利用進めているかと思いますが、 よりセキュアに、さらにプライバシーに配慮し、さらにビジネスに活用出来るために 事業に先駆けて準備をしておこうと個人的にクリーンルームを色々試しておりました。 そんな中、今年の5月にこのニュースが出たので、これは試さねばとSnowflakeの菅野さんに色々教わりながら実施したハンズオンを元に色々試しているとさらにアップデートのニュースが！ Samoohaの買収とネイティブ機能としての提供 9月26日の大型アップデート ・Branded clean room tiles（ロゴと企業名など設定できる！） ・