Golangでいい設計を実践するための6つのツール
概要 Golangを書くにあたり、いい設計のコードを書くための手助けとなるツールを調べたのでまとめます。 想定読者 Golangの使い方をある程度わかっている(チュートリアルはやった) いい設計をするための具体的なノウハウに興味がある 記事を書いたきっかけ 引用: https://www.amazon.co.jp/dp/B09Y1MWK9N 最近設計に関して勉強するために「良いコード／悪いコードで学ぶ設計入門」を読みました。 本の中では マジックナンバーを使うな 一つのメソッドの中で多くのことをやりすぎるな などの言われてみると基本的な注意点が書いてありました。 一方で以下のように、確かにそうなんだけど実際は守れていない注意点にも書かれていました。 単一責任の原則を守ってクラス設計しよう 高凝集なクラスを作ろう 本を読んでわかった気になって今までと同じように悪い設計のコードを書くままではい
How to avoid Security Group changes corruption in terraform by applying Open Policy Agents (OPA)? - Money Forward Developers Blog
Introduction Hi everyone, I'm @tnqv, a Platform SRE in the Service Infrastructure Division, developing the infrastructure for the entire company. Today, based on our experienced real-world use cases, I would like to share about how we are applying Open Policy Agents to the Platform in order to protect the SLA by avoiding Security Group changes's corruption in Terraform. What is Platform? From the
「便利になる」だけでは人は動かないし、「当事者意識をもってくれる人」はめちゃ貴重だという話
この記事で書きたいことは、大筋下記のようなことです。 ・「これは問題だ」「だから改善したい」と、自分ごととして真剣に考えてくれる人というのは極めて希少です ・ただ「便利になる」というだけでは誰も動かないし、どんなにいいものを作っても使ってもらえません ・当事者意識を「持ってもらう」ということは基本的に出来ません ・当事者意識を持っている人を別に探し出すことで、なんとか状況を打開出来る場合もあります ・だから、「この人は当事者意識を持ってくれている/くれていない」を嗅ぎ分ける能力はとても重要です よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 以前にも書いたことがありますが、私はかつて、システム開発の会社に勤めていました。 社員数は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという
SRE NEXT 2022 ONLINEに「一人から始めるプロダクトSRE」で登壇しました - VTRyo Blog
5月14・15日に開催されたSRE NEXT 2022 ONLINEの初日セッションで登壇させていただきました。 前回の2020年版では初めて大きな規模のカンファレンスに参加したという思い入れもあり、中々感慨深いものがあります。 blog.vtryo.me なお公募プロポーザルに出したのも今回が初めての経験で、それが通ったのでびっくりしました。期待に応えられていたら幸いです。 組織の一人目SREとしてプロダクトに参画したとき、どのようにアプローチしますか？ をテーマにお話しました。 「このチームの最初のSREとして、SRE組織を作ってくれないか」と言われたとき、あなたならどこからアプローチしますか？ SRE本に記載された多くのプラクティスのすべてをすぐに導入するのは容易くありません。なぜならSREの役割を果たせるのは現状あなたしかおらず、さらに通常、本に記載されている環境とは前提も異なるか
アプリケーションロジックを見直してマネーフォワードMEのとあるAPIを約50%高速化しました - Money Forward Developers Blog
マネーフォワード ME のサーバサイドエンジニアの taka.naoga です。 ME が提供するとある機能のアプリケーションロジックを見直すことで、エンドポイント単位でパフォーマンスを改善した話を紹介しようと思います。 改善した機能紹介 はじめに、改善の対象となった機能について概要をご紹介します。 画像赤枠で囲われているアプリホーム画面の「お知らせ」機能です。 ここに表示されているお知らせは、ユーザの属性ごとに任意のセグメントを設定することで、リクエストしたユーザに合わせたキャンペーンや関連サービスの紹介などをすることができます。 社内からアクセスできる管理用のwebアプリケーションを使ってマーケティングチームなどが設定、運営をしています。 設定できるユーザ属性には、年齢や性別といったプロフィール情報から、「証券口座を連携しているユーザ」のようにユーザの連携口座に基づいたものなど多岐にわ
[第8話]ぷにるはかわいいスライム - まえだくん | 週刊コロコロコミック
ぷにるはかわいいスライム まえだくん 【毎週木曜更新・週刊コロコロオリジナル作品】コロコロコミック史上初、異色のラブコメまんが！！主人公・コタローが作ったスライムが超絶美少女の姿に大変身！？ぷにるの自由気ままな言動に少年・コタローは振り回されっぱなし。毎日愉快なドキドキ生活だ!!
![[第8話]ぷにるはかわいいスライム - まえだくん | 週刊コロコロコミック](https://cdn-ak-scissors.b.st-hatena.com/image/square/505c68008012d350c829b8c343f5793dac0facb8/height=288;version=1;width=512/https%3A%2F%2Fcdn-img.www.corocoro.jp%2Fpublic%2Fseries-thumbnail%2F3269754496804959379-7d2738cf7084486e90abc31f1f9ea254%3F1712194673)
Openness について - satoshihirose.log
"不必要なコミュニケーションを制限する" チームトポロジーを読んでいる。 一環して、逆コンウェイの法則に従うように、つまり理想のシステムアーキテクチャに沿うように組織設計をしようと主張する本である。 チャプター2 で、不必要なコミュニケーションを制限する という節がある。 コンウェイの法則の示す重要な点は、すべてのコミュニケーションとコラボレーションがよいとは限らないということだ。したがって「チームインターフェイス」を定義し、どんな仕事には強力なコラボレーションが必要で、どんな仕事には必要ないのかという期待値を設定することが重要になる。多くの組織はいつでもコミュニケーションは多いほうがよいと考えるが、実際にはそうではない。 必要とされるのは、特定のチーム間における集中的なコミュニケーションだ。予期せぬコミュニケーションを探し、その原因に取り組むことが必要なのだ。 ソフトウェアエンジニアとし
バグを憎むのをやめて、バグから学ぶ
バグが出たときに一番やってはいけないことは、犯人を吊るし上げることだ。その犯人は開発者かもしれないし、設計者かもしれないし、運用担当者かもしれない。あるいは、バグを事前に見抜けなかったテスターやQAかもしれない。社内にいるかもしれないし、社外にいるかもしれない。とにかく、問題の原因を特定の個人にして吊るし上げたり、首をすげ替えてしまうと、組織自体は何も成長しない。 かといって、じゃあ単にバグを憎んで、バグを徹底的に洗い出して直せばそれでおしまい、というのは何か違う気がする。それは単に、誰か個人を責めるかわりに、誰かの仕事を責めているだけだ。実際には、そのバグの背景にはいろいろなことが起きている。複雑なロジックやレガシーコードかもしれないし、納期が切羽詰まっていたことかもしれない。あるいは、短い時間で機能を出すことによるインセンティブが、不具合によるロスを上回るのかもしれない。 おれ個人の話
酒店がディスコ!? よそ者がなぜか引き寄せられちゃう、角打ちを超えた角打ちを真鶴で発見 - イーアイデム「ジモコロ」
神奈川県の真鶴町にある「草柳商店」は、夜な夜な「角打ち」で人が集まる酒屋さん。地元の常連だけでなく、県外や海外からの観光客も集まり、お店きっかけで移住者も生まれる場所になっているそう。店主の草柳重成さんに話を聞きました。 ライターの友光だんごです。今日は神奈川の真鶴（まなづる）という小さな町に来ています。 見ての通りの漁港で、季節は真夏。カモメが鳴き、生ぬるい風とともにのどかな雰囲気が漂っています。 ぼんやり海を見ていたら、同行していた編集者のくいしんさんが口を開きました。 「ちょっと一軒行きたいところがあるんです」 「どこですか？」 「夜な夜なミラーボールの下に人が集まる、ディスコみたいな酒屋があるんですよ」 「酒屋にミラーボール……？」 「前にジモコロ編集長の柿次郎さんと行った時の動画を見てください」 漁港の酒屋なのに、おもてなしミラーボールが出てきた。すごい。自分の楽しい場所、パーテ
アジャイル開発の設計にロバストネス分析を活用する
アジャイル開発の浸透で、顧客やステークホルダーとの対話に応じて臨機応変な対応が可能になり、大きな手戻りは減ったかもしれません。それでも、なお、ソフトウェア開発の本質的な複雑さや不確実性は、分割されたと言えるものの、誰もが満足できる状態で解決された、とは言えなさそうです。それでもプロセス改善の探求を繰り返していくなかで、私たちは「ロバストネス分析」にたどり着きました。単なる懐古主義ではなく、実際に以下のような問題への解を見出すことができましたので、その事例を紹介します。 開発者の間で、プロダクトのイメージに齟齬があり、手戻りが発生してしまう 開発の途中で、想定外の作業が発生し、事前の見積もりを大幅に超過してしまう 開発者以外の人物がプロダクトの仕様を把握するとき、あるいは、開発者本人が時間のたったプロダクトの仕様を把握するとき、時間がかかってしまう ロバストネス分析を導入した経緯 私たちは、
Goのロギングライブラリ 2021年冬 - moriyoshiの日記
この記事はPySpa Advent Calendar 2021の14日目のエントリーとして書かれました。昨日のエントリーは冷凍食品でウキウキ引きこもり生活 でした。ちなみに私も70ℓの冷凍庫を購入しましたが本当にライフチェンジングでした。 総論: なぜログが必要か 可観測性 たとえ目的は自明でも、その動作までが自明なアプリケーションというものはほぼ存在しません。現実の世界のアプリケーションというものは、動作パラメータだったり実行環境だったり、起動時点でのさまざまな要因によって挙動を変えるものだからです。そして、そうしたアプリケーションにはライフサイクルというものがあります。ここでいうライフサイクルは、アプリケーションの処理が実行されるにつれ、アプリケーションの内外との情報のやりとりで生じる大局的な状態の変化のことです。アプリケーションが並行処理を行うようなものであれば、個々の並行処理の単位
What it takes for TDD to make Clean Code That Works? - やっとむでぽん
"Great books begin with great openings. 'Test-Driven Development' by Kent Beck (2003) begins with this sentence: Clean code that works, in Ron Jeffries' pithy phrase, is the goal of Test-Driven Development (TDD)." (Quoted from talks by Takuto Wada (和田卓人), or t_wada, the TDD evangelist actively working in Japan.) When I teach about TDD, I always try to stress that TDD is just a skill and that's Cle
大規模システムにおけるディレクトリ構成をRDBのカーディナリティを参考に考える - ぷらすのブログ
モノリシックなプロジェクトにおいて、トップレベルのディレクトリ構成が異なる 2 つのディレクトリ構成を考え、それらの違いは何で、どちらが優れているか？という問いについて考えた。そして、「複雑な概念をトップレベルのディレクトリ構成にした方が良いのでは？」という結論に落ち着いた話をする。 はじまり ちょっとしたシナリオを想像してみよう。 プロジェクト立ち上げ期 「最近のトレンドはレイヤードアーキテクチャだ！」 そう言って、プロジェクトはスタートした。 . ├── application │ ├── xxx_usecase.go │ ├── xxx_repository.go │ ├── yyy_usecase.go │ └── yyy_repository.go ├── domain │ ├── xxx.go │ └── yyy.go ├── infrastructure │ └── xxx_
マイクロサービスに失敗する7つの方法
次の問題は、CV駆動開発(CV-driven development)です。自分のCV(Curriculum Vitae、職務経歴書)を見ます。すると、"マイクロサービス"に関する部分が大きく空いていることに気付きます。これでは都合が悪いので、"自社のスタックを再構築して解決しよう"、と考えるのです — 読者の皆さんは、"Holly、それは皮肉が過ぎるよ"、と思うかも知れません。"自分の履歴書の都合でアーキテクチャを決めるやつがどこにいるんだ？" それが実は ... いるのです。 Red Hatは先日、コンテナベース開発を導入したおもな動機に関する調査を行いました。その結果、最も多かったものは"キャリアアップ"でした。"キャリアアップ"は、CV駆動開発の体のよい言い換えに過ぎません。 現在のマイクロサービスは"新正統派"と言ってもいいものですから、経歴書にマイクロサービスが欠けているのは大
成長し続けるインフラストラクチャとメルカリの挑戦/mercari infrastructure and software
2018/07/29 @ July Tech Festa 2018
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Config for Go web services | GO.into Development
Treating GraphQL directives as middleware - LogRocket Blog
主体性を失わせるアンチパターンをやってしまっていた話 | ドクセル
テーブル設計の考え方とやり方 [入門編]![テーブル設計の考え方とやり方 [入門編]](https://cdn-ak-scissors.b.st-hatena.com/image/square/fff34d6fcb76b27f602c88a8a78045329642f395/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F5416b70d025345fc95b30d1ec95701b6%2Fslide_0.jpg%3F20931325)
フルスタック開発者のためのBallerina: バックエンドAPI開発ガイド
