前提知識 - このお題を説明する上で必要な前提知識 組織の臭い - 解決が必要な対象の症状、問題点 プログラムにおける「コードの臭い」を想定しているものです 組織課題の解決テクニック / 臭いの解決方法
資料公開 Ops JAWS Meetup#21 に「システム運用アンチパターン のすすめ」というタイトルで登壇しました #OpsJAWS こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 2022年6月21日開催 Ops JAWS Meetup#21 に「システム運用アンチパターン のすすめ」というタイトルで登壇しました。 その際に投影した資料を公開します。 資料 サマリー CAMS Culture (文化) Automation (自動化) Metrics (メトリクス) Share (共有) 承認の自動化 ゲートキーパーとの摩擦を避け、承認を本来の目的に戻すためには自動化が有効です。 承認の自動化をするとしても承認自体の目的は果たすようにしましょう。 運用の自動化 自動化による改善を行いましょう 自動
[レポート] AWS Data Exchange:クラウドでサードパーティのデータを簡単に見つけて購読する #ANT238 #reinvent | DevelopersIO (classmethod.jp)
デザインパターン (design pattern) とは、過去のデザイナーたちが見つけた経験則的な型に対して名前をつけ、型の再利用性を高めやすくしたものです。ソフトウェアデザインの世界(特に、プログラミングの領域)においてはプログラム構造の設計パターンのことをまさに “デザインパターン” を呼び、これを共通の知識として積極的に取り入れています。 これに対しアンチパターン (anti-pattern) とは、必然的に否定的な結果に至る型を指します。アンチパターンもデザインパターンの一種と捉えこれを知識に蓄えておけば、設計の過程でどのような結果に至るのかを事前に予測することができるし、失敗を未然に防ぐことも可能となります。 今回は、アプリケーションデザインにおける典型的なアンチパターンをいくつか紹介します。 アプリケーションデザインの定義 ここでの「アプリケーションデザイン」の言葉は、以下の意
最近、というより昔からの定番ネタですが、GoFのデザインパターンは時代遅れで陳腐化したという話題をSNSで度々見ます。今回はそのパターンの陳腐化について書きます。 GoFのデザインパターンの陳腐化 GoFのデザインパターンの複数は今も価値があるものの、複数は陳腐化しており、特に一部(≒Singleton)は有害なものになっているという指摘には異論ありません。 GoFが実装例の対象としていたC++に限っても、言語仕様の改善でいくつかのパターンの必要性が低くなりました。また継承の弊害が知られたり、ジェネリクスやムーブセマンティクスの普及が進んだりと、GoF本執筆当時と今では状況が変わっています。 これは言うなれば、時代が変容し、GoFのデザインパターンのコンテキストやフォースが、開発の状況と乖離するようになったと言えます。 パターンおよびパターンベースアプローチの陳腐化 一方、「デザインパター
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja) お世話になっている人も多い Martin Fowler's Blikiの日本語翻訳サイト 、いつも運営&翻訳ありがとうございます。 パターン言語は関連が重要な役割を担っています。そして関連はダイアグラムにすると捗ります。ダイアグラムがついている書籍もよくみます。 なので、ダイアグラムがないときや書籍と違う雰囲気のダイアグラムが欲しくなった場合、自分で描きながら読んでたりします。こんな感じで。 紙に手書きすることも多いのですが、インターネットで公開されているものはURLが付けやすいのでSVGで作るのが最近のマイブーム。SVGはサイズが大きくなっても拡大すれば読めるのでいいです。 上の画像はPNGをアップロードしたものなのでGistに上げました。 GistのSVGへのリンクを置いておきます。Gistの
Azure App Service (Web Apps) がリリースされて 6 年、情報のアップデートを行いつつ気になった情報は適当にブログに書くという日々ですが、Regional VNET Integration や Service Endpoins が使えるようになって設計に大きな変化が出るようになったのでまとめます。 最近は Microsoft で HackFest を行うことも多いのですが、App Service をこれから使い始めたいという場合に、失敗しない構成を共有したい、知ってほしいという意図もあります。多いですが中身は単純です。 基本設定 64bit Worker は必要な場合のみ利用する FTP / Web Deploy をオフにする Always on を有効化する ARR affinity をオフにする HTTP/2 の有効化を検討する Health Checks の
はじめに この記事はGo2アドベントカレンダー14日目の記事です。 GoのErrorハンドリングについては、これまでにも様々なパターンが発表されてきました。 今回は独自定義のエラーについて、これまでのパターンをまとめた上で、その実現をeasyにするgenerrというツールを作ったので、その紹介をします。 github.com Goのカスタムエラー Goのエラーハンドリングの中で、カスタムなerror型を用いるパターンは比較的広く知られているかと思います。 その中からいくつかのパターンを紹介します。 sentinel errorsパターン Goのerrorはinterfaceとして定義されており、Error() stringのメソッドを実装さえしていれば、errorとして扱うことができます。 標準パッケージで提供されているerrorsやfmt.Errorfを用いて簡単にエラーを表現することが
Brendan Burns, David Oppenheimerらの論文「Design patterns for container-based distributed systems」を読んで、コンテナを活用したシステム設計や開発に、とても有用と感じたので、図を中心にした要約にしてみた。 要約内容に誤りや理解不足な部分もあると思うので、原文も参照していただきたい。また、自身の理解のために、論文中に無い図を加えた点、独自の注釈も加えている。 背景 コンテナ化されたソフトウェアコンポーネントから構築されたマイクロサービスアーキテクチャの人気が高まり、分散システム開発においても同様の革命が起っている。 コンテナの境界の壁は、分散システムの基本的なオブジェクトの境界に適している。そこで、コンテナを活用して、コードの低レベルの詳細を抽象化し、アプリケーションやアルゴリズムに共通する高レベルのパター
どういうこと?作業の期日が厳しいときには、「最大タスクの完了日」と「厳しいデリバリーの期日」との間に、「ゆとり」を設けるようにします。どうして?プロジェクトは、自分たちの進捗を可視化する義務があります。その際、「究極の危険信号」となるものは、「期日までのゆとり」がない状態です。どうすれば?各ワークゲループについて、最も時間のかかる作業の最短の完了日を、デリバリーが求められる厳しい期日と比較します。その差が「完了までのゆとり」です。どんなグループにも、自分たちの労力を可視化する義務があります。その際には、究極の危険信号となるものを用いなければなりません。それが「期日までのゆとりがない状態」です。ゆとりが消えるのは、開発という活動が、基準となる作業と突きあわせるのに失敗したときです。「ゆとり」は、最初から算出しておき、傾向を見るため、少なくとも週に一度は再計算します。「ゆとり」は毎週、±二〜三
パターンによるソフトウェア構成管理を大学の図書館で見つけて読んでみたところ意外に良書だったので紹介する。 16個のパターンを紹介している。 Pattern Name Summary Mainline マージを最小化する。メインラインで開発することによってアクティブなコードラインの数を管理可能な集合にする。 Active Development Line Active Development Lineを作ることによって急激に成長するコードラインを安定化する Private Workspace Private Workspaceによって、統合の問題で集中できない状況から守る、また自分の変更が他の人に影響を及ぼさないようにする Repository 必要なものを全て持っているRepositoryを設定する Private System Build Repositoryにコミットする前にPriva
よいソフトウェアを作るのは、プロセスではなくヒトですが、それにしても作戦は必要です。作戦は、ヒトや(その集合体である)チームを、どのように生かしていくかという作戦であり、かつ、最終成果物の方に焦点を当てている作戦です。と、いうわけで、書籍「組織パターン」をまとめます。What ?組織パターンとは「なに」なのか、用語も含め、まとめておきます。What:パターンとパターン言語What:組織パターンとは?What:組織パターン言語の理由What:組織パターン言語の種類Why ?組織パターンが「なぜ」必要なのか、その意義をまとめておきます。Why:プロセスの問題点Why:プロセスを超えてWhy:構造や価値へWhy:ヒトのつながりがソフトウェアを生み出すHow ?組織パターンの本丸、パターンをすべてまとめます。カテゴリパターン言語紹介章パターン組織デザインプロジェクトマネジメント4.1.1信頼で結ば
パターンに機能と型を取り戻す アジャイルにおいてアーキテクチャを表現する DCI James O. Coplien (著) 和智 右桂 Growth xPartners Inc. (翻訳) Copyright c 2010 Gertrud & Cope. All rights reserved. はじめに 本稿は James O. Coplien 氏の論文「Restoring Function and Form to Patterns」(http: //www.software-architect.co.uk/slides/sa10-JimCoplien Patterns.pdf)の全文を、氏 の許可を得て翻訳したものです。 要約 15 年以上前、我々はソフトウェア・パターンの規範のための基盤を築いた。—この規範は後に長 いこと、ソフトウェア・アーキテクチャにとっての中心になったものであ
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方(パターンは名前重要) など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
記事内に広告を含む場合があります。記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。 対象読者 「すでにiOSプログラミングの基礎を理解している人」が、iOS開発におけるパターンによるオートマティズムの想定読者です。 Objective-Cの基本的な文法を理解している チュートリアルやサンプルをベースとした、簡単なアプリケーションを作成したことがある NSString・NSArray・UIViewControllerなどのクラスの基本的な使い方を知っている こういった方が、この本の想定読者になります。 ですので、Objective-Cの文法の説明や、Xcodeの使い方などは、この本では説明されていません。 「iOS開発におけるパターンによるオートマティズム」が提供するもの iOS開発におけるパターンによるオートマティズムでは、アプリ開発の入門が終わっ
当サイトでもテクスチャやパターンなどを素材として紹介しますが、ダウンロードして満足するだけでなく、どのように使うかが大切です。 テクスチャやパターンを効果的に使った実例を見ながら、その使い方を紹介します。 The What, Why and How of Textures in Web Design 下記は各ポイントを意訳したものです。 1. ノイズのテクスチャ 2. リアルにするためのテクスチャ 3. ビジュアル効果を与えるテクスチャ 4. トーンや印象を明確にするテクスチャ 5. シンプルなピクセルパターンの繰り返し 6. 大きなインパクトを与えるパターン 1. ノイズのテクスチャ ノイズのテクスチャは最近のウェブデザインでとても人気があります。これは背景からボタンまで、あらゆるデザインほとんどのエレメントにマッチします。 ノイズの使い方は使う場所に依存しますが、良いノイズというのはぱ
クラウドを使ったシステム開発では、従来のアーキテクチャー設計の常識は通用しない。性能・信頼性・セキュリティを高め、コストを下げる。クラウドとオンプレミスでシステムを連携させる――。こうした課題を解決するアーキテクチャーの工夫がある。そんな「勝ちパターン」を紹介する。 目次
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く