DMMプラットフォームはエンジニアが120名以上所属する開発組織であり、4年前からプラットフォームエンジニアリングに取り組んでいます。 4年間の成功体験とその裏に佇む課題についてお話ししました。 Platform Engineering Kaigi 2024 で使用したスライドです。 ht…
![Platform Engineeringの功罪 in DMM](https://cdn-ak-scissors.b.st-hatena.com/image/square/ff0c9f22f3269322fe39169729d5dc130be3ce1c/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Ffa6a36b5185c43a7b05d2b8973557abf%2Fslide_0.jpg%3F30949839)
公開日 2024/06/18更新日 2024/06/18身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 多くのIT企業では、ユーザーに対してより高品質で安定した体験を提供するために、システムアーキテクチャを進化させ続けています。 本特集では、日常生活の中で多くのユーザーに利用されているサービスのアーキテクチャ設計に携わるエンジニアの方々から、技術選定の背景や意図、そして現在のアーキテクチャの課題から未来への展望まで、詳しく伺いました。この記事を通じて、各企業のエンジニアたちがどのように技術的な課題を克服し、システムの柔軟性と効率を高めているのか、知見を得ていただければ幸いです。 ※ご紹介は企業名のアルファベット順となっております アソビュー株式会社 アソビュー株式会社では「遊び」という領域に対し、マーケットプレイス型EC「アソビュー!」やD2C型SaaS
こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab
期限の制約なく無料で提供される「Free Tier」クラウドサービスまとめ、DBaaS/BaaS/その他編(2024年版) いくつかのクラウドサービスでは、新規ユーザーに対する1年程度の無料トライアルや一定額のクーポンなどの提供だけでなく、期限の制約なくずっと無料で提供される、いわゆる「Free Tier」や「Always Free」と呼ばれるサービスが提供されています。 こうしたサービスは評価や一時的なテスト環境、あるいはホビー用途などに適しています。 本記事では期限の制約なく無料で提供されている主なクラウドサービスを、2024年版としてまとめました。(有料サービスの追加機能として無料で提供されているものは除外しています)。 ただしこれらの無料のサービスは、提供側の都合により一時的に申し込みや利用が制限されたり、提供が終了することがあります。提供側の都合に留意しつつ、良心的な範囲でご利用
上のチャートには、2024年の1月と2月の支出が記録されていて、このチャートをゴールドシュタイン氏は毎朝確認する。 まず、ゴールドシュタイン氏は支出を「固定費(Fixed)」と「変動費(Variable)」の2項目に大別する。その下に食費、家族、娯楽、罪悪感のある楽しみなどといったカテゴリーを設けている。 それぞれのカテゴリーに対して、年初からその日までの支出合計額、予算に占める割合、予算の残りなどを詳細に追跡する。 右のチャートには、支出の内訳が別のビジュアルで示されている。四角形が大きければ大きいほど、支出が多いということだ。「罪悪感のある楽しみ(Guilty Pleasures)」や「アパートメント(Apartment)」という名の支出が予算において大きな比重を占めている一方で、「友人と社会(Friends / Social)」と「教育(Education)」は小さい、つまり予算に占
最近「ああ、これ前職でも前々職でもやったことあるなぁ」という仕事があった。データエンジニア(やその関連職種)として働き始めて約5年、3社でフルタイムとして働いてきて「このスキルは業界や組織規模が変わってもデータエンジニアとしてスキルを求められることが多いな」と感じたものをまとめてみることにした。棚卸し的な意味はあるが、特に転職用などではないです。 前提 どこでも必要とされたスキル データマネジメントに関する概要レベルの知識と実行力 セキュリティや法令に関する知識 事業ドメインに関する興味関心 他職種とのコミュニケーション能力 コスト管理 / コスト削減のスキル ソフトウェアエンジニアとしてのスキル DataOpsやアラートのハンドリング能力 分析用のSQLを書く力 古いテーブルやデータパイプラインを置き換えていくスキルや胆力 あるとやりやすいスキル 関連部署の動きを何となく把握しておく力
3/30 に X で Terraform がトレンド入りしていて何事かと思ったら Terraform が公式ドキュメントとしてスタイルガイドを出したようです。 Terraform Style Guide いままで Terraform のスタイルに関して信頼できるドキュメントといえば Google Cloud の Terraform を使用するためのベスト プラクティス ぐらいしか知らなかったのですが、 Terraform 公式がようやく出してくれてありがたい限りです。 これでわざわざ社内の Terraform 規約を設けずとも「公式ドキュメントに従いましょう。」の一言で済みます。 ということで一通り読んだのでまとめました。 原文だと構文の簡単な使い方なども書いてありますが以下の要約ではだいたい省略しています。 詳細は原文を読んで確認してください。 要約 スタイルガイドについて コードのスタ
はじめに データ分析基盤の資料を力尽きるまで追記していきます。 構成図にあるアイコンや記事の内容から技術要素を調べて記載していますが、不明分は未記載にしています。修正のコメント頂ければ助かります。 あと、この記事追加してっていう要望も歓迎いたします。 テンプレート 記事公開日 : 会社名(サービス名) データソース : データ処理 : アウトプット : 画像 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
セキュリティチームでリーダーを務めている藤田です。普段はプロダクトセキュリティの施策を中心に担当しています。 この投稿は、現在進行中の案件に関するものですが、世間で DMARC への対応が話題になっているにも関わらず、業務分担が進んでいる組織や複数のサービスで会社共通のドメインを用いてメールを送信しているような場合になぜ対応が進まないのか、それに対し私たちがどのようにアプローチしているかを示すものです。まだ完璧とはいえる状況ではありませんが、ある程度目処が見えてきたため、ノウハウを共有します。 タイトルの通り技術的なトピックも取り扱いますが、社内での調整や進め方を中心に解説しています。 ステークホルダーが多く、調整に苦労している方や、DMARC 対応を始めたもののレポートの分析に着手できていない方が一歩を踏み出すための助力となれば幸いです。 結論 外部の分析サービスに頼ることなく、AWS
はじめに 最近、Next.js、TypeScript、Tailwind CSSを使って技術ブログを立ち上げました。(まだあまり更新は進んでいませんが…) このプロジェクトを通じて構築した開発環境がわりと快適だったので、誰かの参考になるかもしれないと記事を書いてみることにしました。 できる限りわかりやすく詳細な説明を心がけましたが、その結果、記事のボリュームが大きくなってしまいました。長文ですが、興味のある方はぜひ読んでみてください🙏 また、この記事内で紹介した内容をセットアップしたリポジトリを公開しています。 Next.jsのボイラープレートとして活用可能ですので、興味のある方はぜひ覗いてみてください。
本記事は 【Advent Calendar 2023】 15日目の記事です。 🎄 14日目 ▶▶ 本記事 ▶▶ 16日目 🎅 はじめに 想定している読者 一覧 まとめてみて 参考 はじめに クラウド事業推進部の小野内です。昨年5月にキャリア入社してから早1年半以上が経ちました。 入社以降、AWS、Google Cloud のデータ分析基盤の開発・運用に関わっておりますが、現在はGoogle Cloud メインでやってます。 試行錯誤の毎日ですが、Google Cloud案件をどんどん盛り上げていきたい所存です。 1年ほど前の投稿記事では、 Google Cloudの学び方について触れましたが、本記事ではGoogle Cloud案件を1年半程度経験してみて、 AWSと比較しながら、Google Cloudの主要なサービスについて、違いを整理しました。 想定している読者 AWS案件に半年以
最近、ときめいてますか? 起伏のない日常が輝くひとさじのスパイス。それが「間接的なコミュニケーション」です。 手紙やチャットアプリを介して会話しながら 「この人、もしかして私のこと……?」 と悶々とする時間には、月餅を凌ぐ栄養価があります。 しかし、そう簡単にときめく機会など訪れないのが世の常。 だったら…… のではないでしょうか。 つまりこういうことです。 「架空の社員」を創造して仕事中にチャットとかでやりとりしたらめちゃくちゃ楽しいんじゃないの!? ということで今回は を開催いたします。 この記事はSKYN®の提供でお送りいたします。 今回、社内チャットで競い合うのはこの3人! 原宿:株式会社バーグハンバーグバーグの社員でオモコロ編集長。アイドルと妄想で会話するファンサイトを運営していたことがある。 恐山:株式会社バーグハンバーグバーグの社員。小学生のとき、ノートに架空の住民票を書いて
この記事は 株式会社ログラス Productチーム Advent Calendar 2023 13日目の記事です。 はじめに 〇〇を削除できるかどうかのビジネス処理、皆さんはどう実装していますか? 同僚の話題になった記事でも削除の認可処理をどこに記述すべきか?は難しいと説明されています。今回はお題は認可っぽいもので書きますが広範に「削除ができるかどうか?」のビジネスロジックをドメイン層にどう閉じ込めるかの便利な実装パターンを紹介します。 削除処理のビジネスロジックの取り扱いは難しい 削除処理のビジネスロジックの実装はシンプルだけど更新処理や作成処理と比べて意外と難しいです。 それはなぜかというとドメインオブジェクト内の実装に削除処理を書くことができないからです。 例えば権限に管理者と一般ユーザーの二つの権限があるとします。
大変多く読んでいただいた「プログラミングというより物事が出来る思考法」というポストや、世界一流エンジニアの思考法の書籍で紹介した内容がある。 私の職場でも、ものすごく出来る人が「実践」しているところを何回も目撃しているので「実践編」として皆さんにシェアしようと思って今回のポストを書いてみた。 タイトルにもある通り、私はエンジニアだが、ビジネス書である書籍と書かれた多くの思考法と同じく、あまりエンジニアリングというものに関係ない要素であると感じている。 上記のポストや書籍でシェアした内容を端的に言うと「理解には時間がかかるがかける価値が十分あり、それによって自分が物事をコントロールしている感覚を身につけることが出来る」という自分の小さな発見だ。私がこのことを最初に発見したのは、新卒の出来る人々との出来事がきっかけだが、今回その小さな自分なりの発見を後押しするような出来事がいくつかあった。それ
ダイヤモンド社と共同で行なっていた「海外投資の歩き方」のサイトが終了し、過去記事が読めなくなったので、閲覧数の多いものや、時世に適ったものを随時、このブログで再掲載していくことにします。 今回は2020年3月26日公開の「「間接的攻撃」を多用する裏攻撃による「女の子のいじめ」の研究」です(一部改変)。 ****************************************************************************************** #MeToo運動で頻繁に登場したのが、“toxic masculinity”という言葉だ。これは日本語で、「毒々しい男らしさ」と訳されている。「男はマッチョであるべき」というマチズモのことだが、そこにtoxic(毒性の)というネガティブな形容詞をつけたことで、「セクハラやドメスティックス・バイオレンス、レイプなど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く