Amazon CloudWatch アラームの大規模なクリーンアップを自動化する | Amazon Web Services
Amazon Web Services ブログ Amazon CloudWatch アラームの大規模なクリーンアップを自動化する AWS リージョン全体で数千の Amazon CloudWatch アラーム がある中で、リージョンを跨いで価値の低いアラームや誤設定のアラームをすばやく特定したいとお考えですか？ 数日間「ALARM」または「IN_SUFFICIENT」状態になっていて、再検討が必要なアラームを特定する方法をお探しですか？ 価値の低いアラームをリージョン全体で確認し、定期的に削除してアラームコストを最適化するクリーンアップメカニズムが必要ですか？ このブログでは、CloudWatch で価値の低いアラームのクリーンアップメカニズムを AWS アカウントのリージョン全体に大規模にデプロイする方法を探り、さまざまな種類の設定ミスや価値の低いアラームを特定することによって、お客様が
非エンジニアサイドに技術的負債や設計を説明するノウハウ - Qiita
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2022 、10日目の記事です。 これはなに？ ろくに設計せずにシステム開発を進めると技術的負債が蓄積し、変更が難しくなってしまいます。 しかし設計を推進しようにも、周囲が設計is何を知らないと、なかなか理解を得られません。特にビジネス側や経営側はプログラムの内部構造を知らないわけですから、輪をかけて説得が困難です。 この記事は、ビジネス側や経営側など、非エンジニアサイドに対して技術的負債や設計を分かりやすく説明するための例えや手法をまとめたものです。 私が非エンジニアサイドへ説明するとき実際に活用しているもので、聞き手からも「分かりやすい」と好評を得ております。 この記事のゴール 以下を知ることがこの記事のゴールです。 技術的負債や設計について、非エンジニアサイドに理解を促すノウハウ ユ
リファクタリングはエンジニアの福利厚生であり管理指標への影響はほとんどないんでは - きしだのHatena
おそらくリファクタリングの工数を確保する説得力のある材料がほしくて、リファクタリングの効果をどう示すか悩んでる人がいたのですが、リファクタリングって非開発者に示せるような数字だすのは難しいよねという結論になったので、そのまとめ。 工数としてはコード管理費みたいな感じで乗せるのがよさそう。 まず、リファクタリングはそれ自体では価値を示せません。人工衛星に搭載するプログラムで、動きだしたらメンテナンスできないようなコードを最後にリファクタリングしたとして、どのような価値を示せるかと考えると想像できるのではないかと思います。 なのでリファクタリングの価値というのは、その後で新しいコードを追加したり既存のコードを変更したりといった作業がどれだけ作業時間短く品質高くなったかという間接的な指標で測ることになります。 ここでまず、最初のコードを書いた人とリファクタリングする人が同じなら、そこまで保守性か
読書感想文「リファクタリング第2版」 | フューチャー技術ブログ
最初の例は一度ざっと流し読みして雰囲気をつかむと、この後を読むのが楽になると思います。この時代の本にはこの手のロールプレイが良くついていた気がします。2版になってカラーになって見やすさが段違いに上がっています。また、このあとの章やカタログの章まで全部読んだあとに再度戻ってくると、自分の理解の補強や確認に役立つでしょう。 「リファクタリングの理論とエッセンスをつかむ」のであれば、2章を読むだけで十分です。ここは本気で読むと良いです。読書会をするとか、ちょっとできる人に教えてもらえる環境を作ってもいいと思います。28ページしかないので、すぐに読めると思います。 個人的には3章もお気に入りの章です。文法を学んで、なんとか動くものを作るぞ、という段階の人にはまだ良いコード、悪いコードというイメージがつきにくいかもしれませんが、この章を読むことでコードを見た時の選球眼を鍛えるきっかけになると思います
10年もののシステムをPHP・Twig・jQuery・BootstrapからNext.jsにリプレイスするときにやったこと - ハイパーマッスルエンジニア
Twig, jQuery, Bootstrap で構成されていたシステムをNext.jsでリプレイスしたときにやったことを書く。 前提 IE対応必須 ディレクトリ設計 github.com を参考にした。 ユニットテスト用の__test__は基本的に作らず、format.tsとformat.test.tsは同じ階層に配置するようにした。テストが存在するのかの確認コストと、書くときのハードルを極力下げるようにするため。 コンポーネント分割については、アトミックデザインを採用しようとも思ったが、結果やめて下記のような分割単位とした。 components ├── button ├── label │ ├── H1.tsx │ └── Title.tsx └── icon アトミックデザインでいうところのatoms(原子)とmolecules(分子)までを最大として、それ以降の大きな単位はfea
Code Smell とリファクタリング技法について調べてみた - Qiita
Code Smellとは？ 以前（2019年8月頃）、CSD (Certified Scrum Developer) 研修を受講しました。非常にためになる研修で、その研修の中でCode Smellというものについて学びました。 Code Smellとは、ソースコードにリファクタリングすべき問題が存在することを示す何らかの兆候のことです。 CSD研修ではペアプロでTDDで開発を行い、開発したコードからCode Smellを嗅ぎ取ったらリファクタリングして取り除く。という開発の流れを教わりました。 研修受講後、このCode Smellについてもっと知りたいと思ってググったりしたのですが、日本語で解説しているサイトが少ないのが現状です。 以下のサイトが、Code Smellとリファクタリングの技法について体系的にまとめていると思いました。 Code Smells (SourceMaking) こ
【Swift】MVC(マシマシViewController)をMVPにリファクタリングしながら設計パターンを学んでみた | DevelopersIO
今まで個人ではあまり設計パターンというものに触れることなく、いわゆるMVC的な設計ばかりを行なっていましたが、他の設計パターンも試してみたいと思い今回MVPアーキテクチャを学習してみることにしました。 MVC MVCはよくジョークでMassive View Controlllerと言われたりしますが、これはViewControllerクラスが大規模(Massive)になっていく問題のことを指しています。 この問題は単純にコード量が多いことだけが問題ではなく、様々なロジックがViewControllerに増し増しで乗っかってしまい、抱える責務が多くなってしまっているところにあります。 抱える責務が多くなることで、他のロジックとの依存関係が深くなり、テストがしづらかったり、問題箇所の発見に時間が掛かったり、保守のしにくさに繋がります。 ひとつの器(ViewController)にロジックが増し
シェルスクリプト リファクタリング ～遅いシェルスクリプトが供養されてたので蘇生して256倍に高速化させました～ - Qiita
はじめに ことの始まりは「シェルスクリプトでツールを作ったけど速度が遅くて使い物にならなかったので供養」というツイートを見たからです。コードを見てみると、実例をあまり見ないシェルスクリプトのリファクタリング例として丁度良い内容と分量だったため記事にいたしました。記事を書くにあたりコードの利用を快く承諾していただいた @Hayao0819 様にはこの場を借りて御礼を申し上げます。 内容は章立てで構成しており、序章で事前調査をし、第一章で一般的なリファクタリング、第二章でパフォーマンスを重視したリファクタリング、終章で少し余談をして締めくくっています。最初はパイプは並列処理されるから速くなるというのは神話（そうとは限らない）についても書いていたのですが流石に長いので分けました。それでも書きたいことを色々書いていたらめちゃくちゃ長くなってしまいましたので読み物として私がどんなことを考えながらリフ
Symfony2のblogチュートリアルをリファクタリングしてみた(repositoryクラス)
前回は、blogチュートリアルを 10 章まで進め、Fixtureを導入してテストコードを書く準備を整えました。 今回は、チュートリアルを 11 章まで写経した後に、私が独自にリファクタリングをした内容を紹介します。 リファクタリングでは下記の内容を試してみました。 GETリクエストとPOSTリクエストのアクションを分離Repositoryクラスの導入Repositoryクラスのテストコードを記述Formクラスのテストコードを記述 動作確認環境 Symfony 2.0.11PHP 5.3.10PHPUnit 3.6.10 目次 11 章まで進める GETリクエストとPOSTリクエストのアクションを分離 Repositoryクラス 次回は form と repository にテストコードを追加してみます 11 章まで進める まずは blogチュートリアル(11) まとめと応用 まで終わらせ
Symfony2のblogチュートリアルをリファクタリングしてみた(repositoryとformのテスト)
前回は、blogチュートリアルを 10 章まで進め、Fixtureを導入してテストコードを書く準備を整えました。 今回は ... 引き続き、repository と form のテストを書いてみたので紹介します。 動作確認環境 Symfony 2.0.11PHP 5.3.10PHPUnit 3.6.10 目次 動作確認環境 Repositoryクラスのテストコード Formクラスのテストコード コントローラのテストコードのリファクタリング おわりに Repositoryクラスのテストコード Repositoryクラスのテストは、データベースを正しく操作できているか確認しています。 src/My/BlogBundle/Tests/Repository/PostRepositoryTest.php <?php namespace My\BlogBundle\Tests\Repository;
クリアなコードの作り方: 縦長・横長なメソッドを短くする - 2012-02-07 - ククログ
最近読んだRubyのコードではYARDのコードがキレイでした。 さて、長いメソッドは不吉なにおいがするからメソッドを分割するなどして短くしましょうとはよく言われることですが、ここでいう「長い」とは「縦に長い」ことを指していることがほとんどです。長いのが問題なのは縦に長いときだけではなく横に長いときもです。 縦に長いメソッド まず、どうして縦に長いメソッドが問題かについてです。縦に長いメソッドには「処理を把握しづらい」という問題がある可能性が高いです。 どうして処理を把握しづらいか 処理を把握しづらい原因はいくつかあります。例えば、抽象度が低いのが原因です。 メソッドが縦に長くなっているときは、多くの処理が行われていることがほとんどです。これらの処理はメソッドになっていないため名前がついていません。処理に名前がついていない場合は実装を読まないとなにをしているかがわかりません。 せっかくなので
ビフォアーアフター(CSV出力機能編) | Webシステム開発／教育ソリューションのタイムインターメディア
あらすじ あなたはとある業務用アプリケーションの開発・保守を任されています。 このアプリケーションはASP.NET / C#で作成されており、 多数の一般社員が作成したデータが積み上げられ、 溜まったデータを集計・出力したものを上層部が眺める、 といったことが日夜行われています。 様々な角度からデータを確認する必要があるため、 データ出力機能はアプリケーション内に山ほどあります。 出力形式は様々ですが、とりわけCSVで出力されているデータが多くなっています。 さて、その数ある出力機能の中でも、 特定の条件を満たす社員の一覧をCSVで出力する機能があるのですが、 クライアントからの要望で出力されるCSVのカラムの並びの変更や追加を行うことになりました。 出力機能の改修は今回が初めてなのですが、 既にあるものに少し手を加えるだけなので、 大した仕事にはならないはずです。 ちゃっちゃと片付けてし
CakePHPアプリケーションの基本的な設計指針 (3) - カスタムfindタイプ - - ２４時間CakePHP
イントロダクション 標準のfindの種類（first, all, count, threaded, neighbor, list）だけでは、ビジネスロジックに対応できないことがあります。 これに対するひとつのプラクティスとしては、カスタムfindタイプを定義することです。 この記事では、実際の開発を想定したリファクタリングの過程を通してカスタムfindタイプの定義の仕方と活用方法、その意義をご紹介します。 「次」の記事 例えば、カレントのレコードの「次*1」のレコードを取得したい場合、それに纏わる複雑な処理は、単純なqueryの発行だけでは済まないことがあります。 この「次」のレコードを探索するロジックを例に、ボブ*2がこれを実装していくお話をしましょう。 要件の定義 ボブの上司のサム*3は、クライアントの会社のサイトにブログモジュールを追加するプロジェクトの打ち合わせで、次の要件を定義し
Refactoring Javascript with kratko.js — Perfection Kills
Understanding the concept of code refactoring is one of the best things you can do to become a better programmer [1]. It all started a couple of weeks ago when I — once again — looked at the growing, stinky mess that my code has become. It’s a few thousand LOC app with various interactive widgets and controls all on one page. Even though a lot of functionality was encapsulated in these separately-
美しいプログラムを書く(リスト処理ライブラリ編) | Webシステム開発／教育ソリューションのタイムインターメディア
問題 美しいプログラムを書く(脱添字職人編) では添字が多用され読み難くなっているソースコードのリファクタリングを通して 美しいプログラムを書くためのポイントをいくつか紹介しました。 そこでは 「何をするか」を基準にプログラムを書きましょう。 「どうやるか」が前面に出たプログラムは意図を把握し難くなります。添字や明示的なループの使用は避けましょう。「どうやるか」が前面に出てきてしまいます。 今時のプログラミング言語ならば便利な構文やライブラリ関数があるので、 添字やループを使わずとも「何をするか」を基準にプログラムが書き易くなっています。 ということを述べました。 確かにごもっともな主張ではありますが、経験値の少ない人からすれば 「そんなことを言われてもどんなライブラリ関数があってどういう場面で使えるのかリファレンスを読んでもよく分からないし……」 ということはよくあります。 という訳で、
美しいプログラムを書く(脱添字職人編) | Webシステム開発／教育ソリューションのタイムインターメディア
あらすじ あなたはとある業務用アプリケーションの開発・保守を任されています。 このアプリケーションはC#で記述されており、 とある企業におけるプロジェクト(Project)の管理を主目的としています。 プロジェクトには何名かの社員がアサインされており(AssignedStaffs)、 プロジェクト内には必ずマネージャーが1名存在します(ManagerStaffId)。 大まかなイメージとしては以下のようなコードになっています: public class Staff { public String Id {get; set;} public String Name {get; set;} ... } public class Project { public ArrayList AssignedStaffs {get; set;} public String ManagerStaffId {
CakePHPを使ったMVC設計のベストプラクティス - Sooey
CakePHPを使ったMVC設計のベストプラクティス 個人的にはCakePHPはあまり好きではないのですが、CakePHP開発メンバーによるMVCデザインの記事 (CakePHP のおいしい食べ方)で紹介されていたBest Practices in MVC Design with CakePHP (php|architect’s C7Y)はMVCフレームワーク利用者にとってとても有用な情報だったので、訳してみました(php|architectの方には翻訳許可を頂いています)。 この記事を読んでドメインモデルに興味を持った方は、エンタープライズ アプリケーションアーキテクチャパターン(PoEAA)やDomain-Driven Design: Tackling Complexity in the Heart of Softwareに手を出してみるのもいいかも。他に、InfoQにユーザー登録すれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
