タグ

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

  • 要件定義とはそもそも何か

    BPStudy#188〜要件定義を学ぼう。ChatGPTを添えて( https://bpstudy.connpass.com/event/281289/ ) の登壇資料です。 2023年4月28日(金)に開催。

    要件定義とはそもそも何か
  • Web API 設計のベスト プラクティス - Azure Architecture Center

    ほとんどの最新の Web アプリケーションでは、クライアントがアプリケーションと対話する際に使用できる API を公開しています。 適切に設計された Web API には、次をサポートする目的があります。 プラットフォームの独立。 API の内部的な実装方法に関係なく、すべてのクライアントが API を呼び出すことができる必要があります。 そのためには、標準プロトコルを使用し、クライアントと Web サービスが交換するデータの形式に同意できるメカニズムを備えている必要があります。 サービスの進化。 Web API はクライアント アプリケーションから独立して進化し、機能を追加できる必要があります。 API の進化に伴い、既存のクライアント アプリケーションが変更なしに引き続き機能する必要があります。 クライアント アプリケーションが機能を十分に使用できるように、すべての機能が検出可能である

    Web API 設計のベスト プラクティス - Azure Architecture Center
  • 外部パートナーとのAPI連携時に気をつけるポイント - 10X Product Blog

    はじめに こんにちは!yamakazu (@yamarkz) です。 近所の行きつけスーパーがサミットストアになったのですが、品揃えがとても良く、お店の雰囲気も明るくて、仕事終わりの買い物が最近の楽しみになってます 🥳 🛒🥗 さて今回は、開発方面のナレッジとして外部API連携の話を紹介します。非常にニッチな領域の話題ですが、わかる人にはわかるような内容です。 興味のある方はぜひ最後まで読んでみてください。 動機 新しく外部API連携の開発に着手するメンバーの助けになりたい、より良い外部API連携を実現したいという思いから、これまで開発を経験してきた中で理解した勘所を紹介します。 元々は社内向けに書き溜めておいたナレッジメモの内容ですが、特別社内に留めておく必要性もないので、せっかくならブログにしてしまおうと思い、ここで筆を取りました。 これは社内の同僚に向けた内容でありながら、似た境

    外部パートナーとのAPI連携時に気をつけるポイント - 10X Product Blog
  • 技術文書の書き方

    howto-tech-docs.md 技術文書の書き方 このメモは、私(@ymmt2005)が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。

    技術文書の書き方
  • モデリングはキラキラ技術より地味だが役に立つ / modeling-over-shiny-tech

    # Event データモデリングとデータ基盤の構築・運用 (第14回ちゅらコラボ)CARTA HOLDINGS x ちゅらデータ 合同イベント https://churadata.connpass.com/event/254417/ ぼくのかんがえる最高のレポーティング基盤 https://speakerdeck.com/pei0804/hokufalsekankaeruzui-gao-falserehoteinkuji-pan-at-awsdeshi-jian-analytics-modernization ディメンションモデリングモデリング https://zenn.dev/pei0804/articles/dimensional-modeling スタースキーマ https://zenn.dev/pei0804/articles/star-schema-design コンフォ

    モデリングはキラキラ技術より地味だが役に立つ / modeling-over-shiny-tech
  • メルカリを退職してロンドンのMetaに転職します 〜 外資Big Tech転職活動体験記|松岡玲音|note

    この度、3年半に渡って勤めたメルカリを2022年5月に退職し、この夏からロンドンのMetaにSenior Machine Learning Engineerとして転職することが決まりました!わいわい✌('ω')。その過程で、東京およびロンドンのBig Tech合計5社を数ヶ月かけて対策をし面接に臨んだので、そこで得たノウハウをここで共有できたらと思います。面接を受ける際にNDA(Non Disclosure Agreement)にサインするので具体的な面接の詳細には触れられませんが、伝えられる範囲でできる限り記述しています。 また、Metaから最終的に提示されたオファー条件を最後に記載してあります。なにぶん日においては給与の話は燃えやすいということもあり、その部分だけ某日の有名エンジニアに倣って有料にしてあるのですが、ご興味のある方は是非ご購入いただければと思います(1コイン分の金額で

    メルカリを退職してロンドンのMetaに転職します 〜 外資Big Tech転職活動体験記|松岡玲音|note
  • RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料

    はじめに タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。 P.S. なんと記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。 当にありがとうございます。 前提 RDBを採用するのは事実を無駄なく正しく記録するため 正規化、トランザクション、制約とデータ整合性 基的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計) 制約を最大限利用する cf: ↑P91〜 ↑P.29,41 ↑P56〜 ↑5章 ↑P347~ 情報とデータ データ:単なる事実の値→これを永続化して蓄えるものがRDB 情報:データから生み出される意味や目的のあるもの→RDB

    RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料
  • アルパカ証券 技術ノート|アルパカ証券の裏側 - はじめに

    こんにちは。shirou(@r_rudi) と申します。アーキテクトという名の雑用係をしています。 Alpaca Japanでは、2021年8月に「アルパカ証券」という証券サービスをはじめました。 この一連の文章は、アルパカ証券の裏側のシステムやその開発体制などについて述べたものです。なるべく証券分野に限らず説明していく予定ですので、証券サービスを立ち上げようとしている人たちにはもちろん、それ以外の方にも参考にしていただけるような文章を目指したいと思っています。 アルパカ証券とはアルパカ証券の詳細はホームページをご覧ください。また、第一種金融商品取引業者登録完了時のプレスリリースにも、「アルパカ証券」サービスの特徴が記載されています。 全体設計方針まず最初に、アルパカ証券を構成するシステムの全体設計方針について説明します。 マイクロサービス vs モノリシック設計は2018年中頃ぐらいから

    アルパカ証券 技術ノート|アルパカ証券の裏側 - はじめに
  • 「DIは必ずしも善ではない」| Dependency injection is not a virtue by DHH

    DHHの Dependency injection is not a virtue(2013) という記事は有名ですが、ちゃんとした日語訳が意外とないようなので、書き出してみて思ったことを要約してみた。[1] Rubyエンジニアの中には、何も考えずに他のモデルのnewを書いてる人の割合が多いという(コードレビュー時のヒアリングによる)体感があり、また8年前の記事なので経験の浅い人は読んだことがない人もいると思う。該当する方は是非読んでほしい。 全部読む時間が無い人は要約へ. 原文と訳文 In languages less open than Ruby, hard-coded class references can make testing tough. If your Java code has Date date = new Date(); buried in its guts,

    「DIは必ずしも善ではない」| Dependency injection is not a virtue by DHH
  • モダンなソフトウェア設計の書籍 - kawasima

    型駆動設計から始まるフォーマルなアプローチもカバーしているが、フォーマルな方法の簡単な紹介も含まれているもの。

    モダンなソフトウェア設計の書籍 - kawasima
  • shiodaifuku.io

    Webエンジニアのブログです。

    shiodaifuku.io
  • 歴史から学ぼう!! 設計失敗学-ハイアットリージェンシー空中通路落下事故- | しぶちょー技術研究所

    失敗から学べることは多くあります。例えそれが自分の失敗でなくても、失敗を考察することで教訓を得ることができます。そこで今回は有名な設計失敗事例を紹介し、その失敗を考察していきたいと思います。 ドイツ政治家オットー・ビスマルク氏は「愚者は経験に学び、賢者は歴史に学ぶ」というの言葉を残しています。それほどの過去の失敗というものは財産なんです。記事で、過去の歴史的な失敗事例から教訓を学び、あなたの設計ノウハウとして活かしましょう!! 今回紹介する失敗事例は ハイアットリージェンシーホテルで起きた空中通路落下事故です。 設計変更に潜むリスクを考えてみよう 事例説明の前に、まずは問題です。考えてみましょう。 上図の通路は、柱とワッシャ、ナットで支えられています。当初は”設計A案”で進めていましたが、柱が長すぎることや施工もやりづらいことから、柱を分割した”設計B案”に変更しました。これで、材料の

    歴史から学ぼう!! 設計失敗学-ハイアットリージェンシー空中通路落下事故- | しぶちょー技術研究所
    susue
    susue 2020/04/19
  • サービス終了のお知らせ

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

  • 綺麗なAPI速習会 - Qiita

    Wantedly Engineer blogに速習会資料を閲覧向けに再編しました! ぜひご覧いただけると幸いです! 記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可

    綺麗なAPI速習会 - Qiita
  • 1