タグ

2024年6月18日のブックマーク (14件)

  • Railsでクリーンアーキテクチャを考えてきた

    複雑なシステムの設計と開発におけるクリーンアーキテクチャ、レイヤードアーキテクチャ、ドメインモデリング、モジュラーモノリスの活用について詳細に解説します。 具体例として輸送管理システムCREWExpressを紹介し、 依存関係のルールや抽象度の高い設計をRailsに適用する方法を共有します。 特にMVCにユースケース層を追加し、システムの柔軟性を保つ工夫について詳述します。また、Railsの一般的な開発手法であるRailsWayだけでは対応しきれない複雑さに対して、どのようにクリーンアーキテクチャの考え方を取り入れているのかを実例を交えて説明します。 クリーンアーキテクチャの基概念や依存性逆転の原則をRails環境でどのように実現しているかについても触れています。

    Railsでクリーンアーキテクチャを考えてきた
  • Datadog でアラート通知の質を向上させるための取り組み

    この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" 44 週目の記事です!1 年間連続達成まで残り 9 週となりました! はじめに はじめまして、2024 年 4 月にログラスにジョインしたエンジニアの石畑です。 まだまだドメインやシステムについて学んでいる最中なのですが、その中でアラート監視・運用周りをより良くできそうだったので、試行錯誤したことをまとめたいと思います。 どんな課題があったのか? ログラスではフロントエンドからバックエンド、インフラに至る全てのログ・メトリクスが Datadog に集約され、横断的に分析・監視できる仕組みが整っています。アラートも Datadog でモニタリングを作成し、「Slack に通知 → ローテションのオンコール担当が対応」という体制が作れています。 しかし、歴史的に積み重なったモニタリングが過剰にアラー

    Datadog でアラート通知の質を向上させるための取り組み
  • 分散トレーシングを使ってパフォーマンス改善をやってみたら、レスポンスタイムを2割近く改善できたお話 - Tabelog Tech Blog

    目次 目次 はじめに そもそもシステム運用改善チームとは何か? なぜアプリAPIのパフォーマンス改善が必要になったのか? どうやって改善箇所を見つけるのか? 分散トレーシングを使って、店舗詳細APIを細かく分析する 計測結果の見方 計測結果から分かったこと 計測結果から見つけたポイントに改善を実施していく コースに紐づくクーポンの取得 口コミを取得する処理と公開画像数のカウント ユーザーごとの公開口コミ投稿数の合計数カウント 全体での改善効果はどうだったか? パフォーマンス改善の影響 ユーザー体験が向上した 今後のべログ成長に備えたシステム上の余裕ができた べログの分散トレーシングを使って改善を実施してみてよかったこと おわりに はじめに こんにちは。べログ開発部 ウェブ開発1部 システム運用改善チームの @4palace です。 今回は、私の所属するシステム運用改善チームがべロ

    分散トレーシングを使ってパフォーマンス改善をやってみたら、レスポンスタイムを2割近く改善できたお話 - Tabelog Tech Blog
  • dbt導入におけるデータモデリング環境整備 - pixiv inside

    はじめに 初めまして。プラットフォーム開発部にてデータ基盤の整備をしているazukiと申します。 今回はdbt(Data build tool)を導入した経緯と非中央集権的なdbtの使い方についてご紹介したいと思います。 今回は導入に関してまとめていますので、dbtの運用面の詳細は別記事で解説予定です。 データモデリングツール導入の背景 ピクシブではプロダクトの多さを理由に非中央集権データ組織を採用しています。 ドメインチームがメインでデータの取り組みやデータモデリングを行い、データ駆動推進室やデータ基盤チームはそのサポートや整備を担当しています。 その背景に関しては、【PIXIV MEETUP 2023】の方でお話していますのでぜひご覧下さい。 speakerdeck.com 今までBigQueryのデータ加工SQLは自社で開発したツールで管理していました。 pythonから変数埋め込み

    dbt導入におけるデータモデリング環境整備 - pixiv inside
  • イケてるダッシュボードを作りたい!アナリストが自分自身の仕事を分析してみた - MonotaRO Tech Blog

    こんにちは!MonotaROで3年ほどアナリストをしている杉田です。1年前にマーケティング部門マーケティングサイエンスグループに異動し、現在はマーケティング施策の効果検証手法や売上予測手法の改善に取り組んでいます。データサイエンス領域でのスキルアップを目指しており、アナリストとデータサイエンティストの間という(MonotaROの中では)少数派な道を歩もうとしている最中です。キャリア面での葛藤話もまたの機会にお話しできたらと思っていますが、若手メンバーのオンボーディングについて部署の皆さんと執筆をした記事がありますので興味があれば覗いてみてください。 note.com 今回は、アナリスト業務をする中で複数回ぶつかってきた「せっかくダッシュボードを作ったのに活用されない」という悩みについてじっくり考えてみたことをお話していこうと思います。 「せっかくダッシュボードを作ったのに活用されない」とい

    イケてるダッシュボードを作りたい!アナリストが自分自身の仕事を分析してみた - MonotaRO Tech Blog
  • サーバなんて触ったことないから分からない――クラウド世代のための「サーバ」超入門

    クラウドでサービスを利用したり、システムやWebアプリケーションを構築することが当たり前になった昨今、以前はハードウェアを触ることで物理的に理解することができたサーバやストレージの基礎知識について、意識することが難しくなっています。一方で、IaaS(Infrastructure as a Service)やPaaS(Platform as a Service)などクラウドを使いこなす上では、サーバやストレージについて基から分かっている必要があるにもかかわらず、あいまいなまま使っていて障害やセキュリティ事故につながっていることもあるのではないでしょうか。 連載「AWSで学ぶクラウド時代のサーバ&ストレージ基礎知識」では、これまで仮想マシンは使っていたけど物理的なサーバに触れてこなかったエンジニアやサーバ管理者、情シスなどを対象に、サーバとストレージの基礎知識を「Amazon Web Se

    サーバなんて触ったことないから分からない――クラウド世代のための「サーバ」超入門
  • 社内勉強会でオライリー本を3週間で読破する方法 - 爆速データエンジニアリングドメインディープダイブ

    こんにちは。Acompany 新卒のハルカです。 Acompany のプロダクトの 1 つに Data Clean Room があり、それらを利用するデータエンジニアとデータエンジニアリングに対する理解は非常に重要です。そこで、データエンジニアリングにドメインディープダイブするために社内勉強会を開催しました。 今回は、以下の 2 点に関して紹介します。 どのようにデータエンジニアリング勉強会を開催し、短期間でドメインディープダイブを行ったか どのような資料をデータエンジニアリングの勉強で使ったか 特に、エンジニアとして時間の確保が難しい中、限られた時間と期間(1 回 1 時間枠で 3 週間)で、私達がどのように勉強会を行ったかを重点的に紹介します。 データエンジニアリング勉強会の内容 今回の勉強会は以下の内容で行いました。 「データエンジニアリングの基礎」勉強会 「データマネジメント」勉強

    社内勉強会でオライリー本を3週間で読破する方法 - 爆速データエンジニアリングドメインディープダイブ
  • mattn氏が実践しているエンジニアリング最適なメモ術。アウトプットを継続するための方法論

    mattn氏が実践しているエンジニアリング最適なメモ術。アウトプットを継続するための方法論 2024年6月18日 mattn 大学卒業後、ソフトウェアハウスやSIerなどでソフトウェア開発に携わる。vi派生のテキストエディタVimの日語化やプラグイン、Go言語などでOSS(オープンソースソフトウェア)の開発・コミュニティ運営に参加し、2019年からGoogle Developers Expert。2021〜2023GitHub Stars。著書に『みんなのGo言語』(2016年、2019年に改訂2版、技術評論社、共著)、『Go 言語プログラミングエッセンス』(2023年、技術評論社、単著)がある。関西在住。 X:@mattn_jp GitHub 前回はアウトプットとは何か、何のためアウトプットするのか、についてお話しました。筆者はこれまで、アウトプットのやり方で悩んでいる方々に、どう

    mattn氏が実践しているエンジニアリング最適なメモ術。アウトプットを継続するための方法論
  • /usr は何の略か – ビットログ

    Unix系OSのルートディレクトリ直下にある “/usr” はなんの略なのか。 巷の意見はおおよそこんな感じです。 「もちろん “USeR” の略でしょ。」 「あまいな。 “User Services and Routines” の略だ。」 「その “User S*R*” の略だっていうソースはあるの?」 どうもはっきりしません。そこで調べ始めたら、思いのほか深入りしてしまったので、今回調べたことを書いておきます。 0. Unixユーザグループの機関誌に載っていた説 Unixユーザグループの機関誌に “User Services and Routines” の略だと書いてあったという情報が散見しますが、ここではそれをソースとして認めません。その記事に「XXXのドキュメントに書いてある」とか、「IEEE NNN.N で決まっている」とか書いてあれば一件落着なのですが、原典を見つけることはでき

  • ウォータフォールはやめて2024年の開発をやろう!|牛尾 剛

    今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。 最近になってまたウォータフォール vs アジャイルの議論を見かけることが多くなってきたので、私が勤務する米国の世界規模のクラウドプロバイダーでは2024年現在どんな開発をしているのかをご紹介したいと思います。私はこれが「正解」といいたいのではなく、何らかのポイントが皆さんの何らかの参考になったらいいなと思って筆をとりました。 ちなみに、2016年時点で私のウォータフォール開発に対する考え方は下記のブログの通りで今も変わっていません。ただ、2024年現在だからといってアジャイルをやるべきと思っているわけでもありません。 もし、今ウォータフォールをやっている人がいたら「そんなこと言ってもどうしたらええねん」となると思うので、自分なりの解決方法も考えてみました。 最初に自分的な結論を書いておくと「2024年の開発と

    ウォータフォールはやめて2024年の開発をやろう!|牛尾 剛
  • 脳に収まるコードの書き方を読んだ。面白かった。 - Mitsuyuki.Shiiba

    いただきましたー!わーい。脳に収めるぞー! @haradakiro @ryuzee pic.twitter.com/3Qd6EvPioU— SHIIBA Mitsuyuki (@bufferings) June 13, 2024 明日(2024年6月18日)発売! www.oreilly.co.jp どう書くのがいいんだろうなぁ? 複雑なコードと向き合うときは「あー、これはメモを取りながら読まないと迷子になるやつだ」ってなる。最初はわりとキレイに作られていたとしても、機能追加を重ねていくとだんだん読めなくなっていく。 だから「時間が経っても読みやすいコードってどう書くのがいいんだろうなぁ?何かヒントがあるかなぁ?」って思いながらこのを開いた。先に書いておくと、ヒントはあった。 アウトサイドインのTDD 全然予想してなかったから、おー!と思ったのが、説明をTDDで進めていくってところ。好き

    脳に収まるコードの書き方を読んだ。面白かった。 - Mitsuyuki.Shiiba
  • Webアプリケーションセキュリティの基礎とSpring Bootでの実装 #jjug_ccc #jjug_ccc_c | ドクセル

    スライド概要 JJUG CCC 2024 Springの発表資料です。 Webアプリケーションをクラッカーの攻撃から守るために様々な対策が求められます。例えばSQLインジェクション対策、CSRF対策、XSS対策、セッションID固定化対策などです。 このセッションでは、これらの対策について基礎から解説したあと、Spring Bootでどのように実装するかを解説します。

    Webアプリケーションセキュリティの基礎とSpring Bootでの実装 #jjug_ccc #jjug_ccc_c | ドクセル
  • EnvoyのYAMLの読み方 - Carpe Diem

    概要 Envoyyamlは非常に長大で初めて読む人からするととても分かりにくいです。 しかし実際は各要素の役割を理解するととてもシンプルに構成されていることが分かります。 そのための手助けとしてこちらで図を交えながら説明します。 環境 Envoy 1.22.0 要素の説明 まずは各要素を理解します。 downstreamとupstream 要素 説明 downstream Envoyからみたクライアント upstream Envoyがサービスに対するリクエストを転送する際に接続するエンドポイント(ネットワークノード) よくあるパターンで図示してみると以下です。 front proxyモデル sidecarで外部からリクエストを受ける sidecarでローカルアプリケーションからのリクエストを転送する このようにsidecarモデルのローカルアプリケーションは、downstreamにもup

    EnvoyのYAMLの読み方 - Carpe Diem
  • 日本企業でシステムトラブルが相次ぐ根本原因 SIerとユーザー企業の間にある「埋められない人材格差」 →ユーザー側に必要な能力がないとプロジェクトの成功確率は落ちる

    中野 仁 (AnityA) @Jin_AnityA ユーザー側とシステムを業にしているベンダー側で組織の能力差がでるし、結果的に情報の非対称性が拡大する 外部に発注するにもユーザー側に必要な能力というのはあるし、それがないとプロジェクトの成功確率は落ちる 日企業でシステムトラブルが相次ぐ根原因 SIerとユーザー企業の間にある「埋められない人材格差」 president.jp/articles/-/819… 2024-06-01 07:41:21 リンク PRESIDENT Online(プレジデントオンライン) 「プッチンプリン」の出荷停止に、ゆうちょ銀行の入金遅延…日企業でシステムトラブルが相次ぐ根原因 SIerとユーザー企業の間にある「埋められない人材格差」 江崎グリコのシステム障害によりプッチンプリンなど一部商品の出荷が停止している。4月にはゆうちょ銀行で入金遅延が起きた

    日本企業でシステムトラブルが相次ぐ根本原因 SIerとユーザー企業の間にある「埋められない人材格差」 →ユーザー側に必要な能力がないとプロジェクトの成功確率は落ちる