※この投稿は米国時間 2022 年 12 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 オンラインで、組み立て式のテーブルを注文したとします。ところが、パッケージを開けてみると、組立説明書が入っていません。完成品がどんなものかはわかっていても、それぞれのパーツをどう組み立てればいいのか、まるでわかりません。設計が不十分な API を使うコンシューマ開発者も、同じような経験をしているといえます。適切に設計された API なら、容易に見つけ、検索してアクセスし、使用することができます。高品質の API は、コンシューマ開発者がアイデアをひらめき、新しいユースケースを作り上げる手助けになってさえくれます。 もちろん、API 設計を改善する方法はあります。たとえば、RESTful のプラクティスに従うなどです。しかし、お客様が知らず知らずのうちに、ちょっとした不便
こんにちは。CX事業本部MAD事業部のYui(@MayForBlue)です。 最近調べものをしている中で見つけたドキュメントが良かったのでご紹介したいと思います。 先にまとめ Microsoft の RESTful Web API の設計 のドキュメントが API 設計を考える上で勉強になった 関連する クラウド アプリケーションのベスト プラクティス のドキュメントもアプリケーションを設計する際の指標として良さそう RESTful Web API の設計 最近 API 設計やパス設計について考える機会があったのですが、これという正解がなかったり、人によって思想やこだわりが違ったりして結構難しいなと感じていました。 そんな中で下記のドキュメントを見つけてひとつの指標として良いなと思ったのでご紹介します。 内容（項目） REST とは何か リソースを中心とした API 設計の整理 HTTP
エレベータはシステムエンジニア思考を鍛えるよい乗り物です。 対象について注意深く観察し、エラーを起こさずスループットが最大化されるように設計・行動する力を付けましょう。 ボタンキャンセルの仕様を確認しておく メーカーによって異なります。 基本的にはダブルクリックでキャンセル可能ですが、扉が開いてないと有効にならないものがあるので注意が必要です。 混雑したエレベータで1Fから最後らへんに乗り込み扉付近に立ったとき 高速にエレベータ運用するためには、ここのポジションは重要です。 まず何階のボタンが押されているか確認します。 エレベータが各階に止まったとき、それが… 1F出発時点で押されていない階の場合、降りる人はいないはずですので、乗ってくる人のためにエレベータの内部方向に詰めます。 1F出発時点で押されている階の場合、降りる人がいるので、一度エレベータを降りて、出入り口のスペースを作ります。
GoFデザインパターンの一覧表と，活用のためのコメント，および入門者が独学するためのリンク集（サンプルコード付き）。 入門者の独学を支援するために，このページのURLを提示して熟読させ，各パターンを短時間で効率よく学んでもらう。 デザインパターンはプログラマの常識だ。 Java使いかどうかは問わない。 にも関わらず，入門書を買ったまま，途中で挫折する人が多い。 挫折の原因は，パターンの数が23もあって，多いからだろう。 全パターンをすんなり覚えてもらうためには，各パターンごとに 「要するにこういう目的のパターンなんだ。」 「10文字で表現すると，パターンの意味はこうなんだ。」 という要点・本質を，短いコメントで伝えれば助けになるだろう。 こういった学習を通して，Java言語の「設計思想」も併せて感じ取ってゆけるはず。 全パターンの一覧表（要約コメント付き） 全パターンについて，10文字以内
技術情報Wiki http://www.sangyo-rock.com/tech/index.php [ トップ ] [ 編集 | 凍結 | 差分 | 履歴 | 添付 | リロード ] [ 新規 | 一覧 | 検索 | 最終更新 | ヘルプ | ログイン ] [ Twitter ] 技術系の主要目次 技術分野別index 開発環境別index 開発に役立つデータ IT業界動向、ITビジネスなどの周辺記事 読み物類 技術系の主要目次† ↑技術分野別index† AIによる開発支援 GitHub Copilot 自然言語処理 大規模言語モデル Claude関連 Gemini関連 ChatGPT関連 LLMアプリ開発 AIエージェント開発 LLMのローカル知識対応 RAG関連 LLMライブラリ ノーコード系のAI活用 LangChain関連 Amazon Bedrock AI／機械学習 生成AI
JP1ジョブ管理（JP1/AJS3：JP1/Automatic Job Management System 3）を初めて使ったのは、もう何年も前になる*1。その時は、プロダクトのことを何も知らないうちに（けっこう複雑な）ジョブネットの設計をしなければならなくなって、、とにかくアーキテクチャの概要だけを手っ取り早く知りたかった。とはいっても、どこから手をつけてよいのやらわからず、マニュアルだってどこを読めばよいのやら。で、結局2日間だけ研修を受けさせてもらい、空き時間にプロダクトをいじり、講師に質問しまくってどうにかした*2。 その時に「こんな絵があったらなぁ」と思っていた（はずの）絵を描いてみようかと――同じ悩みを持っている人がいるかどうかはわからないが。なお、ジョブ管理ってのがどういうコトか、ジョブネットってのがどういうモノかは、ざっくりわかっているものとする。 1) マネージャ・エージ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
システムを構築する上で必須となるデータベースアクセスの機能、皆さんはどのように実装しているでしょうか？JDBCで記述/EJB Entity Bean(BMP/CMP)を利用/データアクセスフレームワークを利用、等様々な実装方法を選択されているかと思います。 この連載では、様々な観点からデータアクセスに関わる事項を取り上げ、皆ささんがデータベースアクセスについて、少し考えてみる場になればと思っています。まず今回のデータアクセスことはじめ（前編/後編）では、これから様々なデータベースアクセスに関する事項を扱っていく上でのベースとなる知識を取り上げます。 現在、Javaプログラミング言語を用いてエンタープライズシステムを開発する場合、要件変更への設計・実装の変更の容易性、JDBC、EJB Entity Beanなどのデータアクセス要素技術とのマッピングの容易性、等々の理由により、システム全体を論
～システム基盤における非機能要求の見える化ツール～ 2018年4月25日更新 2010年4月 独立行政法人情報処理推進機構 技術本部 ソフトウェア高信頼化センター 概要 情報システムの開発では、業務機能に関する要求以外のいわゆる「非機能要求」について、発注者と受注者との認識の行き違いや、互いの意図とは異なる理解をしたことに気づかないまま開発が進んでしまうことがあります。 「非機能要求グレード」は、このような状態を防止することを目的とし、重要な項目から段階的に詳細化しながら非機能要求の確認を行うツール群です。 「非機能要求グレード」は、「システム基盤の発注者要求を見える化する非機能要求グレード検討会（※）」から譲渡を受けたものです。 また、非機能要求グレードの具体的な利用方法が体得できる演習付きの教材非機能要求グレード研修教材」と解説書「非機能要求グレード利用ガイド[活用編]」も公開していま
ユーザが、知りたいことを知る方法は、大きく二つ。 Ａ．自分から、情報を取りに行く ( active ) Ｂ．通知を受け取る ( passive ) エンタープライズアプリケーションの多くの機能は、どちらかの方法で、「ユーザが情報を知る」ためのサービス。 情報を取りに行く アーキテクチャとしては、REST スタイルで、 URI を指定して、GET 要求をするパターンですね。 画面系のアプリケーション。 業務的には、残高照会とか、在庫照会とか、いわゆる「照会」系の機能。 検索機能とか、一覧機能も全部、これですね。 この場面での設計課題は基本的に二つ。 （１）ほしい情報の特定方法（識別方法） （２）ほしい情報の表現方法（表現形式） 銀行口座であれば、「口座番号」で特定する。 表現方法も、「残高」を「金額」として表現すればよい。 実際の業務でも、もちろん、もっと複雑な課題がいろいろあるけど、 ・識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く