はじめに データ分析基盤の資料を力尽きるまで追記していきます。 構成図にあるアイコンや記事の内容から技術要素を調べて記載していますが、不明分は未記載にしています。修正のコメント頂ければ助かります。 あと、この記事追加してっていう要望も歓迎いたします。 テンプレート 記事公開日 : 会社名（サービス名） データソース : データ処理 : アウトプット : 画像 URL 2025年 2024/03/14 : 株式会社エス・エム・エス（カイポケ） データソース : Amazon Aurora データ処理 : Datastream、BigQuery、dbt アウトプット : Looker Studio 2024/03/12 : 株式会社マイナビ データソース : SQL Server、Amazon S3 データ処理 : Embulk、Amazon MWAA、Apache Airflow、Snowf

"Think globally, act locally" Run your GitHub Actions locally! Why would you want to do this? Two reasons: Fast Feedback - Rather than having to commit/push every time you want to test out the changes you are making to your .github/workflows/ files (or for any changes to embedded GitHub actions), you can use act to run the actions locally. The environment variables and filesystem are all configure

はじめに この記事タイトルに興味をもって読み始めていただいている方の多くは、ソフトウェアエンジニアとしてチームで開発をしていたり、エンジニアリングマネージャーとしてチームビルディングやマネジメントをされている方なのではないかと思います。 実際、この記事を書いている加藤も、リクルートライフスタイルのデータプラットフォームグループ (以前は CETチーム と呼ばれていました) に所属するデータエンジニアとして、データ活用のための基盤開発・運用を行っている一人です。また、担当している社内データプロダクトのプロダクトマネージャーも兼任しています。 本記事では、自分の所属している DevOps チームを「イケてる DevOps チーム」にするために取り組んだ内容や気づいた点をお伝えしたいと思っています。 目次 はじめに 「イケてる」DevOps チームってなに？ Four Keys とは なぜ Fo

この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと

こんにちは、タイミー開発プラットフォームチームで業務委託として働いている宮城です。 タイミーはリリースから4年が経過したプロダクトで、2022年の前半から一部領域でGraphQLを利用し始め現在導入を進めています。 本記事では、GraphQLをプロダクトに導入する上で判断に迷った箇所や課題に対して、タイミーでの意思決定とその理由を紹介します。参考にしていただければ幸いです。 GraphQLの選定理由についてはこの記事では触れませんが、CTOの@kameike が以下のイベントで詳しく紹介する予定です。まだ参加申し込みは可能ですので、興味がある方はぜひ合わせてご覧ください。 timeedev.connpass.com なお、本記事のタイトルはソウゾウさんの以下の記事にインスパイアされています。 engineering.mercari.com GraphQLの「Getting Startedの

「理系だから文章は苦手」。そんな呪文に踊らされてはいけない。分かりやすい文章の執筆で最も重要なのは、数学や理科に通じる論理性だからだ。本コラムを通じて「理系だから文章は得意」へと、考えを改めてくれる人を増やしたい。 体言止めが招く意味不明 体言止め。中学校の国語で習う技法だ。文法として習うのは中学生になってからだとしても、読書などをしていれば、幼少期から慣れ親しんだ表現だろう。言うまでもなく、文章に余韻やリズムを持たせる効果がある。 2022.08.31 形容詞と副詞の甘い誘惑に負けない 技術やビジネスの世界で価値を判断する重要な基準は、数字や具体的な事実だ。ぼんやりとしたイメージしかない情報は、大抵の場合、価値が低い。この原則は、技術やビジネスに関連する文章でも変わらない。具体性のある情報が詰まっている文章ほど、価値は高まる。 2022.08.22

※ 参考記事「PlantUML を VSCode で利用したいけど、プレビューが表示されずエラーが出る」 参考（PlantUML 導入後の編集中画面） 2-2. ER図 今回作成したER図 Qiita記事でも、コードブロック内でPlantUMLの構文がそのまま使えます。（このER図は、Qiitaのコードブロックで表示させています） 今回作成したER図のPlantUMLの表記 @startuml yonde ' hide the spot hide circle ' avoid problems with angled crows feet skinparam linetype ortho entity "families" as families { id -- name nickname introduction created_at updated_at } entity "users

仕事を進めるチームには、さまざまな問題やトラブルが発生するものです。そのため、リーダーはもちろん、チームメンバーも、いろいろな悩みを抱えてしまうもの。仕事上の悩みを抱える皆さんに、事例を基に分かりやすく解決のヒントを提供します。デンソー出身の著者が、実務経験をベースに示唆に富んだ内容をお伝えします。 中小企業診断士、キャリアコンサルタント。1958年奈良県生まれ。1982年大阪市立大学商学部卒業、オーストラリア・ボンド大学大学院経営学修士課程修了（MBA）。1982年日本電装（現デンソー）に入社し、企画、営業部門を経て、数々の製品開発プロジェクトを手掛ける。能力開発トレーニングやマーケティング指導にも当たる。実践的なコミュニケーション・トレーニングやコーチング、ロジカルシンキング、プロジェクトマネジメントの指導には定評がある。著書に『仕事が早い人は何をしているのか？ビジネスフレームワーク活

2022/06/30開催の、こちらのオンラインイベントで用いた登壇資料です。 BPStudy#178〜成長し続け、変更を楽に安全にできるソフトウェア設計とは https://bpstudy.connpass.com/event/250694/

こんにちは、臼田です。 みなさん、AWSのセキュリティチェックやってますか？(挨拶 やったーついにｷﾀ━━━━(ﾟ∀ﾟ)━━━━!! AWS Security Hubのセキュリティ基準が全リージョンまとめて一括でチェック出来るようになりました！こんな感じ！ 右上のリージョンはAll Linked Regionsとなっていて、セキュリティスコアのコントロール単位のパーセンテージと項目単位の失敗割合も全リージョンから集まってきた値になりました！ AWSのWhat's Newは以下です。 AWS Security Hub launches cross-Region security scores and compliance statuses もう少し背景から詳しく説明していきます。 背景 AWS Security HubはAWS上で最強のセキュリティチェックができるサービスです。「セキュリティ

Reactを取り巻く状態管理の潮流を学ぼう。HooksやServer Componentsなどの登場で何が変わるか Reactを取り巻く状態管理のアプローチは変化を続けていますが、いま知っておくべき手法とはどのようなものでしょうか。小林 徹（@koba04）さんに、現在、そしてこの先の状態管理について執筆いただきました。 こんにちは、小林（@koba04）です。 2019年5月に『SPAにおける状態管理:関数型のアプローチも取り入れるフロントエンド系アーキテクチャの変遷』という記事を書きましたが、そこから2年以上が経過し、Reactを用いた状態管理は大きく変わりました。本記事ではReactを取り巻く状態管理の変遷について解説します。 広がるReduxの採用 Hooksの登場 コンポーネントツリーから独立した状態管理 Concurrent Featuresによる新しいユーザー体験 状態とキャ

Randen Pederson 大規模なシステムであれば使っているであろうリバースプロキシ。 セキュリティや稼働率の観点からみて利用することは非常にメリットは高いです。 ただ、社内や周りであまり知見がなく、 「動くからいいや」という理由でApacheをそのままWebサービスの一次受けとして利用されている方も多いと思います。 動くという目的からすれば確かにその通りですが、ただ一枚リバースプロキシを入れるだけで ぐっと運用効率、稼働率も拡張性も上がります。 1. ルーティング処理の簡略化 例えばRESTfulな一般的なAPI構成を作りたいと思った時に以下のようなURL構成になると思います。 http://api.something.com/search/v1/item/list.json?cid=xxxx&gid=xxxxx もしアプリケーション側のルーティングしか知らなければframewor

Chatworkの10年の歴史を語るアジェンダ 春日重俊氏（以下、春日氏）：みなさん、こんにちは。Chatworkの今現在CTOをしております春日です。では約40分という時間をもちまして、Chatworkというプロダクトが、10年を迎えるにあたって、どんな歴史を繰り広げたのかについて、簡単ですが、みなさんが追体験できるようなかたちでお話しできたらと思っています。 では本日のアジェンダですが、3つあります。まず、Chatworkのプロダクトの今の現在の状況について紹介します。2つ目が、そのプロダクトの10年という歴史のあるプロダクトのフェーズと、テクノロジー面でどういうふうに流れていったのかについて説明します。 そのフェーズごとで、やはりいろいろな挑戦がありました。今回は一つひとつの壁みたいなかたちのイメージをして、どういうふうに乗り越えていったかを中心にお話しできたらと思っています。 セッ

React v18 には多くの改善や新機能が盛り込まれる予定だが、そのなかでも特に注目を集めると思われるのが、Concurrent Features と呼ばれる一連の機能。 これらの機能を使うことで、コンポーネントのレンダリングについてより柔軟な設定が可能になり、上手く使えばパフォーマンスや UX の向上を実現できる。 この記事では Concurrent Features のひとつであるstartTransitionと、それを使いこなす上で重要な概念である「トランジション」について説明する。 この記事ではコンセプトの説明や具体例の提示のみを行う。詳細を知りたい場合は以下を参照。 一年前の記事であるため古くなっている部分もあるが、根幹は大きく変わっていないと認識している。 なお、上記の記事には「Concurrent Mode」という用語がタイトルに入っているが、これは今後は使われなくなってい

はじめに ※この記事はEngineering Manager Advent Calendar の22日目の記事になります。前日はmtx2sさんの技術的負債に対するマネジメントの記事でした。個人的には「負債上限」「負債ベースライン」の考え方良かったです。 こんにちは。モノタロウでエンジニア組織のマネージャーをしております普川(@taipuka0)です。 自分は前職から通算10年以上してエンジニアリングマネージャーを続けた後、現在モノタロウでは8人のEMのみなさんと日々ソフトウェア・エンジニアリングの現場でマネージャーとして課題解決に向き合っています。これまで色々な壁にあたり、試行錯誤を繰り返して来ました。EMの難しさを痛感したことも多々ありました。 なぜEMが難しいのか？その一つとして、エンジニアからEMにジョブチェンジした際のギャップというのがあると思います。同じチーム、現場にいたとしても

ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad

原文(投稿日：2021/11/25)へのリンク ゼロバグポリシ(zero bug policy)を採用すると、バグの優先順位付けが容易になり、チームの可視性とバグへの対応性を向上することができる。ただし、過激な変革なので、意思決定とバグの修正時間に関して、自分自身の状況に合わせることが必要だ。 DashlaneのシニアQAマネージャであるSimone Colosimo氏は、Agile Testing Days 2021で、ゼロバグポリシを採用した自身の経験について講演した。 氏らのバグ処理戦略が目指したのは、次のような目標だ。 当時の私たちは、外部からも内部的にも認められるような品質低下に直面していたため、バグへの対処方法を変えなくてはならないと考えていました。そこでパラダイムを変えて、品質とカスタマをプロダクトの中核に置き直し、バグのバックログに対するコントロールを取り戻すため、バグを処

この記事はリンクアンドモチベーションAdvent Calendar 2021 の18日目の記事です。 はじめに 障害って本当に寿命縮みますよね。 私は現在、障害が起こると一番に動くチームに所属しているので寿命が1ヶ月くらい縮んだ気分です。 新卒3年目のペーペーでもあり、様々な障害対応の場面で石につまづき落とし穴に落ちてきました。 しかも障害対応は日々命がけです。育成なんか悠長なことは言ってくれません。 そこで、これより障害対応の避難訓練を行います！！！ ある日… slackの通知音、見たことのないエラー表示に気づいたあなた。 やばい、障害です。 この時あなたが取るべき行動は？ ①エラーの原因を調べる ②slackの@ channelを投下する 正解は… ②です。 正直②をやった後で①をやっても30秒くらいしか変わりません。 障害かも？と思ったらまずいろんな人に知らせましょう。 ※組織によっ