タグ

設計に関するt_itaのブックマーク (14)

  • GitHub - alan2207/bulletproof-react: 🛡️ ⚛️ A simple, scalable, and powerful architecture for building production ready React applications.

    React is an excellent tool for building front-end applications. It has a diverse ecosystem with hundreds of great libraries for literally anything you might need. However, being forced to make so many choices can be overwhelming. It is also very flexible, you can write React applications in any way you like, but that flexibility comes with a cost. Since there is no pre-defined architecture that de

    GitHub - alan2207/bulletproof-react: 🛡️ ⚛️ A simple, scalable, and powerful architecture for building production ready React applications.
    t_ita
    t_ita 2023/05/17
    React のプラクティス。ディレクトリ構成とか状態管理どうするとか、いつも頭を悩ませていることについて言及されていて参考になる
  • アプリケーションにおける権限設計の課題 - kenfdev’s blog

    日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR(長すぎて読みたくない) 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能

    アプリケーションにおける権限設計の課題 - kenfdev’s blog
    t_ita
    t_ita 2021/05/18
    権限設計で苦しんでるところで出会って助かった。苦しんでることには変わりないけど割り切るきっかけとして。
  • AWS Solutions Architect ブログ: Exponential Backoff And Jitter

    こんにちは。ソリューションアーキテクトの今井です。今日はAWSのPrincipal Software EngineerであるMarc BrookerのExponential Backoff And Jitterというブログポストを翻訳しました。リクエスト密度の高いシステムのクライアントを設計するうえでExponential Backoffは非常に重要な概念です。とても参考になる内容なので、ぜひお読み下さい!

    t_ita
    t_ita 2019/12/09
    リトライ間隔について。指数的バックオフにばらつきを加える、と。なるほど。
  • Shopifyはいかにしてモジュラモノリスへ移行したか

    原文(投稿日:2019/07/29)へのリンク ShopifyのシニアエンジニアであるKirsten Westeinde氏がShopify Unite 2019で、Shopifyにおけるモジュラモノリス(modular monolith)への展開について論じた。変更をいつ行うか、どのように達成するか、といった判断にデザインペイオフラインを使用したこと、ターゲットアーキテクチャからマイクロサービスを除外した理由、などがその内容だ。 重要な点は、モノリスは必ずしも悪いアーキテクチャではなく、単一のテストおよび展開パイプラインなど多くのメリットがある、ということだ。新たな機能を短期間で提供する必要のあるプロジェクトを立ち上げるには、これは非常に有用だ。アーキテクチャの改善に着手すべきなのは、"設計のペイオフライン"を越えた時、すなわち設計の悪さが機能開発を妨げるポイントにおいてのみである。Sho

    Shopifyはいかにしてモジュラモノリスへ移行したか
    t_ita
    t_ita 2019/11/19
    「モジュラモノリス」
  • Design It!

    書は、設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを作り上げていく方法を包括的に解説します。書を読むことで、適切なステークホルダーを特定してニーズを理解する方法、アーキテクチャ上重要な要求に基づいて技術やアーキテクチャを適切に選択する方法、アーキテクチャを軽量かつ効果的に評価する方法、チームのアーキテクト力を高める方法などを学べます。モダンなアーキテクチャ設計のための実践的な手法が詰まった書は、より良いプログラマー技術リーダー、そしてソフトウェアアーキテクトになるために必携の一冊です。平鍋健児氏による「日語版序文」を収録。 目次 書への推薦の言葉 日語版序文 序文 はじめに 第Ⅰ部 ソフトウェアアーキテクチャ入門 1章

    Design It!
  • API 設計ガイド  |  Cloud APIs  |  Google Cloud

    フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR

    API 設計ガイド  |  Cloud APIs  |  Google Cloud
    t_ita
    t_ita 2018/04/05
    “これは、ネットワーク API の一般的な設計ガイドです”Google が使ってる設計ガイドらしい
  • 工場の裏庭で見たドイツの工作機械の秘密 日本と異なる設計の根本思想 | JBpress (ジェイビープレス)

    ドイツの首都ベルリンは、東西合併後、大変容を遂げた。かって「壁」で隔てられ、通行不能であっブランデンブルク門も、今では旧東側からも旧西側からも自由にアプローチできるようになっている。2010年末に訪れた私は大いに感激した。門の旧東側広場に立てられた巨大なクリスマスツリーが印象的だった。 私が西ドイツのデュッセルドルフに赴任(1978~1981年)していた頃は冷戦体制が全欧州を圧しており、東西の壁が崩壊することなど、想像もできなかった。私は「俺の目の黒いうちは統一なんて無理だろうな」と思っていた。事実は小説よりも奇なりだ。 柵の向こう側は一見ゴルフ場のようだが 当時、来独したお客様を案内する「とっておきのメニュー」の1つが、東ドイツとの国境の見学であった。日には陸の国境がないから、誰もが興味を持ってくれた。 西ドイツの丘から国境を見ると、高い鉄条網の柵(高圧電流が流れているという)が果てし

    工場の裏庭で見たドイツの工作機械の秘密 日本と異なる設計の根本思想 | JBpress (ジェイビープレス)
    t_ita
    t_ita 2011/02/24
    おもしろい。「「どうあるべきか」を追求するドイツ、ユーザーニーズに応える日本」ってのは、ソフトウェアの文化(パッケージか、カスタマイズか)に通ずる物がある
  • Javaプログラマが知るべき9のこと - @katzchang.contexts

    はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下: 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ

    Javaプログラマが知るべき9のこと - @katzchang.contexts
    t_ita
    t_ita 2011/02/08
    とりあえず新人さんに読んで欲しい記事。さらっと読むにはいいと思う。突っ込んだことは書いてないけど #yam
  • 言語の設計判断

    Domain Driven Design with the F# type System -- F#unctional Londoners 2014Scott Wlaschin

    言語の設計判断
    t_ita
    t_ita 2010/08/27
    これはおもしろい。言語がそうなった歴史・経緯を知るのは確かに大切だと思う
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • TDD談義への反応に対する雑感(テスト駆動開発を取り巻く誤解等) - 千里霧中

    先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基的にKent Beckや和田さんが使われているQAテストの定義によるもの(http://gihyo.jp/dev/serial/01/tdd/0003)。 この定義で「品質保証のための単体テスト

    TDD談義への反応に対する雑感(テスト駆動開発を取り巻く誤解等) - 千里霧中
  • Google App Engine上のベスト・プラクティス、その1: Datastore

    Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと(=頭を使うべきところ)は、データベースの設計である。特にリレーショナル・データベース(RDB)上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En

  • 「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る:CodeZine

    CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

    「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る:CodeZine
  • DB設計の神ツール「ERMaster」なら、ここまでできる

    DB設計の神ツール「ERMaster」なら、ここまでできる:ユカイ、ツーカイ、カイハツ環境!(11)(1/3 ページ) 無料のEclipseプラグイン「ERMaster」とは データベースのテーブル設計を行うときに皆さんは、どのようにしているでしょうか? いくつかの無料で利用できるツールが提供されているので、筆者はそれらを利用していましたが、最近「ERMaster」と呼ばれるEclipseプラグインの存在を知りました。 ERMasterは、ほかのツールに比べ、直感的で分かりやすいUI(ユーザーインターフェイス)に、カスタマイズ可能な、Excelで出力できるテーブル定義書、辞書機能など痒いところに手が届くERモデリングのツールです。稿では、このERMasterについてご紹介します。 ERMasterの主な特徴、8つ ERMasterには、主に次のような特徴があります。 【1】直感的で使いや

    DB設計の神ツール「ERMaster」なら、ここまでできる
  • 1