Microsoft の「クラウドアプリケーションのベストプラクティス」が良かったので紹介したい | DevelopersIO
こんにちは。CX事業本部MAD事業部のYui(@MayForBlue)です。 最近調べものをしている中で見つけたドキュメントが良かったのでご紹介したいと思います。 先にまとめ Microsoft の RESTful Web API の設計 のドキュメントが API 設計を考える上で勉強になった 関連する クラウド アプリケーションのベスト プラクティス のドキュメントもアプリケーションを設計する際の指標として良さそう RESTful Web API の設計 最近 API 設計やパス設計について考える機会があったのですが、これという正解がなかったり、人によって思想やこだわりが違ったりして結構難しいなと感じていました。 そんな中で下記のドキュメントを見つけてひとつの指標として良いなと思ったのでご紹介します。 内容（項目） REST とは何か リソースを中心とした API 設計の整理 HTTP
システムエンジニアのエレベータの乗り方 - Qiita
エレベータはシステムエンジニア思考を鍛えるよい乗り物です。 対象について注意深く観察し、エラーを起こさずスループットが最大化されるように設計・行動する力を付けましょう。 ボタンキャンセルの仕様を確認しておく メーカーによって異なります。 基本的にはダブルクリックでキャンセル可能ですが、扉が開いてないと有効にならないものがあるので注意が必要です。 混雑したエレベータで1Fから最後らへんに乗り込み扉付近に立ったとき 高速にエレベータ運用するためには、ここのポジションは重要です。 まず何階のボタンが押されているか確認します。 エレベータが各階に止まったとき、それが… 1F出発時点で押されていない階の場合、降りる人はいないはずですので、乗ってくる人のためにエレベータの内部方向に詰めます。 1F出発時点で押されている階の場合、降りる人がいるので、一度エレベータを降りて、出入り口のスペースを作ります。
GoFの23のデザインパターンを，Javaで活用するための一覧表 （パターンごとの要約コメント付き） - 主に言語とシステム開発に関して
GoFデザインパターンの一覧表と，活用のためのコメント，および入門者が独学するためのリンク集（サンプルコード付き）。 入門者の独学を支援するために，このページのURLを提示して熟読させ，各パターンを短時間で効率よく学んでもらう。 デザインパターンはプログラマの常識だ。 Java使いかどうかは問わない。 にも関わらず，入門書を買ったまま，途中で挫折する人が多い。 挫折の原因は，パターンの数が23もあって，多いからだろう。 全パターンをすんなり覚えてもらうためには，各パターンごとに 「要するにこういう目的のパターンなんだ。」 「10文字で表現すると，パターンの意味はこうなんだ。」 という要点・本質を，短いコメントで伝えれば助けになるだろう。 こういった学習を通して，Java言語の「設計思想」も併せて感じ取ってゆけるはず。 全パターンの一覧表（要約コメント付き） 全パターンについて，10文字以内
なんでCSSすぐ死んでしまうん
The document discusses schema design patterns for MongoDB databases. It introduces common patterns like attributes, subset, computed, and approximation. Attributes store optional fields as field-value pairs to index them easily. Subset duplicates a small subset of dependent documents to reduce working set size. Computed pre-calculates values to avoid repeated computations. Approximation uses fewer
技術情報Wiki - 技術情報Wiki
2024-06-16 AI／機械学習 AI一般 数学（関数／級数／解析） LLMアプリ開発 Amazon Bedrock 顧客対応 2024-06-15 システム運用 IT業界の待遇／福利厚生 AIによる開発支援 大規模言語モデル TypeScript関連 Unicode 2024-06-14 アルゴリズム GitHub関連 GitHub Copilot AWS データ処理系サービス 自然言語処理 ハイパーバイザー型仮想化 数学（統計学） スキルアップ関連 IT業の経営・戦略など デジタルトランスフォーメーション クラウド一般 2024-06-13 リスクマネジメント Transformer Spring Boot関連 WebAPI関連 REST関連 AWS その他のサービス LLMライブラリ MySQL関連 スクラム 英会話・ビジネス英語・技術英語 データベース関連 2024-06-12
2枚の絵でわかるJP1ジョブ管理の仕組み - あしのあしあと
JP1ジョブ管理（JP1/AJS3：JP1/Automatic Job Management System 3）を初めて使ったのは、もう何年も前になる*1。その時は、プロダクトのことを何も知らないうちに（けっこう複雑な）ジョブネットの設計をしなければならなくなって、、とにかくアーキテクチャの概要だけを手っ取り早く知りたかった。とはいっても、どこから手をつけてよいのやらわからず、マニュアルだってどこを読めばよいのやら。で、結局2日間だけ研修を受けさせてもらい、空き時間にプロダクトをいじり、講師に質問しまくってどうにかした*2。 その時に「こんな絵があったらなぁ」と思っていた（はずの）絵を描いてみようかと――同じ悩みを持っている人がいるかどうかはわからないが。なお、ジョブ管理ってのがどういうコトか、ジョブネットってのがどういうモノかは、ざっくりわかっているものとする。 1) マネージャ・エージ
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
OTN Japan - 今だからデータ・アクセスを真剣に考える！ 第1回
システムを構築する上で必須となるデータベースアクセスの機能、皆さんはどのように実装しているでしょうか？JDBCで記述/EJB Entity Bean(BMP/CMP)を利用/データアクセスフレームワークを利用、等様々な実装方法を選択されているかと思います。 この連載では、様々な観点からデータアクセスに関わる事項を取り上げ、皆ささんがデータベースアクセスについて、少し考えてみる場になればと思っています。まず今回のデータアクセスことはじめ（前編/後編）では、これから様々なデータベースアクセスに関する事項を扱っていく上でのベースとなる知識を取り上げます。 現在、Javaプログラミング言語を用いてエンタープライズシステムを開発する場合、要件変更への設計・実装の変更の容易性、JDBC、EJB Entity Beanなどのデータアクセス要素技術とのマッピングの容易性、等々の理由により、システム全体を論
情報処理推進機構：ソフトウェアエンジニアリング：報告書：非機能要求グレードの公開
～システム基盤における非機能要求の見える化ツール～ 2018年4月25日更新 2010年4月 独立行政法人情報処理推進機構 技術本部 ソフトウェア高信頼化センター 概要 情報システムの開発では、業務機能に関する要求以外のいわゆる「非機能要求」について、発注者と受注者との認識の行き違いや、互いの意図とは異なる理解をしたことに気づかないまま開発が進んでしまうことがあります。 「非機能要求グレード」は、このような状態を防止することを目的とし、重要な項目から段階的に詳細化しながら非機能要求の確認を行うツール群です。 「非機能要求グレード」は、「システム基盤の発注者要求を見える化する非機能要求グレード検討会（※）」から譲渡を受けたものです。 また、非機能要求グレードの具体的な利用方法が体得できる演習付きの教材非機能要求グレード研修教材」と解説書「非機能要求グレード利用ガイド[活用編]」も公開していま
イベント駆動のアーキテクチャ 【これから重要になるパターン】 | システム設計日記
ユーザが、知りたいことを知る方法は、大きく二つ。 Ａ．自分から、情報を取りに行く ( active ) Ｂ．通知を受け取る ( passive ) エンタープライズアプリケーションの多くの機能は、どちらかの方法で、「ユーザが情報を知る」ためのサービス。 情報を取りに行く アーキテクチャとしては、REST スタイルで、 URI を指定して、GET 要求をするパターンですね。 画面系のアプリケーション。 業務的には、残高照会とか、在庫照会とか、いわゆる「照会」系の機能。 検索機能とか、一覧機能も全部、これですね。 この場面での設計課題は基本的に二つ。 （１）ほしい情報の特定方法（識別方法） （２）ほしい情報の表現方法（表現形式） 銀行口座であれば、「口座番号」で特定する。 表現方法も、「残高」を「金額」として表現すればよい。 実際の業務でも、もちろん、もっと複雑な課題がいろいろあるけど、 ・識
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
