タグ

設計に関するpep299のブックマーク (16)

  • あなたの悩みを解決するかもしれないAWS Answersのご紹介 | DevelopersIO

    こんにちは、森です。 皆さんの中にはバリバリAWSを使っている、これから使おうとしているなど様々な方がいらっしゃるかと思います。 アーキテクチャの設計を行う場合、同じようなソリューションの構成を参考にしたり、この設計がベストプラクティスにそっているのか?、AWSを使うのが初めてでどうにもこうにも。。。 などを考えますよね? 今回は、そういった悩みに役立つ AWS Answers を紹介しようと思います。 AWS Answersとは AWS Answers は、AWS ソリューションアーキテクトが開発したドキュメントやソリューションのリポジトリで、AWS クラウドを構築して拡大するのに役立つ方法を説明しています。 これらの答えでは、規範的なアーキテクチャのガイダンスが提供されると同時に、AWS アカウントに数分でデプロイ可能な自動化されたソリューションも用意されています。名前順に参照して、必

    あなたの悩みを解決するかもしれないAWS Answersのご紹介 | DevelopersIO
  • CtoCフリマアプリの作り方 (バックエンド編) 〜6カ月間のPayPayフリマ開発を支えた設計〜

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、PayPayフリマバックエンド開発の三宅です。 今回、YJTC2019-shibuyaにてPayPayフリマのバックエンド設計について話して来ましたので内容を紹介したいと思います。 記事ではセッション前半のバックエンド部分をメインに紹介させていただきます。よろしくおねがいします。 PayPayフリマとは PayPayフリマはフリマに特化したサービスとして10月7日にiOS版をリリースしました。PayPayの名前がつく通り、PayPayを利用してフリマの商品をかんたんに購入でき、買い手から価格の相談をできる機能などが特長です。 また、ヤフオク!とも連携し、ヤフオク!に出品されている固定価格商品の一部もユーザー体験に変わ

    CtoCフリマアプリの作り方 (バックエンド編) 〜6カ月間のPayPayフリマ開発を支えた設計〜
  • shiodaifuku.io

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

    shiodaifuku.io
  • Clean Architectureは全てのプログラマにお奨めしたい良著|erukiti

    Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだので、まとめてみます。コメントやツッコミなどのフィードバックがあればうれしいです。 続編としてクリーンアーキテクチャを読むためのポイントという記事を書きました。併せてご覧ください。 なぜ良著?著者のロバート・C・マーチン(著書読んだことあるかも?)は、50年前から現代に至るまで、様々なアーキテクチャを見て、第一線級として開発し続けてきた経験を元に、どのアーキテクチャでもクリーンにしようとするなら、基部分は変わらないと言ってて、それらが美味くまとまっただからです。 いってみればコンピュータ工学について抑えるべきポイントを解説したであり、The Clean Architectureそのものについてはほとんど割かれていません。それくらい、基として知るべき事が書かれたなのです。 最近のアーキテクチャを追いか

    Clean Architectureは全てのプログラマにお奨めしたい良著|erukiti
  • はじめてのUIデザインを読んで実践したら多くの変化があった|Funakoshi Kiyomi

    「さあ、デザインするぞ!」 そう思ってmacに向かい、デザイナーなりたてホヤホヤの1年前の私はいきなり画面のビジュアルからつくり始めました。情報設計せず、最初からワイヤー書いて、色をつけていく…。今思い返すと失神しそうです😇 デザイナーになりたての方、もしくはデザイナーになろうとしている方のなかには「デザイナーはイケてるデザインを作るのが仕事」と思っている方も一定数いるのではないでしょうか。(決して間違ってはないけどね!) でも私は今こう思っています 「良いインターフェースは見た目から始まるわけではない」と。 今回は「はじめてのUIデザイン」を参考に自分が歩んだプロセスをしっかりと文字にして残しておきたい&私の経験が誰かの役に立てたら、と思いこの記事を書いています。 さ!前置きはこれくらいにして始めよう💨 [目次] 1.「はじめてのUIデザイン」について 2.私がデザインを担当したプロ

    はじめてのUIデザインを読んで実践したら多くの変化があった|Funakoshi Kiyomi
  • プライベートメソッドのテストは書かないもの? - t-wadaのブログ

    この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA@IT で回答したものです。残念ながらQA@IT のサービス終了(2020/02/28)と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY(クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0) で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回

    プライベートメソッドのテストは書かないもの? - t-wadaのブログ
  • スキーマファースト開発のためのOpenAPI(Swagger)設計規約 | フューチャー技術ブログ

    はじめまして。TIG DXユニット 1の亀井です。 はじめに みなさん、Swagger使ってますか? Swaggerや周辺ツールについては 某先輩の記事 にて丁寧に解説されていますので、 記事では実際にSwaggerのスキーマ定義を設計していく上で取り決めた規約について書いてみたいと思います。 前提私が在籍しているプロジェクトでは、REST APIgolangフロントエンドVue.js + TypeScript で構築しています。 短期間・高品質での構築を実現するためにSwaggerを設計ドキュメントとしてだけではなく、コード自動生成やモックサーバーに活用させることで徹底したスキーマファーストな開発を行ってきました。 というわけで、今回は下記のツールを利用することを前提として規約を作成しています。 go-swagger: Goアプリケーションのハンドラ、リクエスト/レスポンス

    スキーマファースト開発のためのOpenAPI(Swagger)設計規約 | フューチャー技術ブログ
  • 続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん

    バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。 自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。 そして、新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。 で、いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。 基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシがえるんじゃないですかね。— 太一 (@ryushi) 2016, 2月 18 読んでいると 「俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。 なのに、

    続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
  • Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん

    バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ

    Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
  • バッチ処理の採用と設計を考えてみよう | メルカリエンジニアリング

    こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する

    バッチ処理の採用と設計を考えてみよう | メルカリエンジニアリング
  • AWS-CloudDesignPattern CDP2.0候補

    AWSクラウドデザインパターンとは? AWSクラウドデザインパターン (AWS Cloud Design Pattern, 略してCDPと呼ぶ)とは、AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したものである。 これまで多くのクラウドアーキテクト達が発見してきた、もしくは編み出しきた設計・運用のノウハウのうち、クラウド上で利用が可能なものをクラウドデザインのパターンという形式で一覧化し、暗黙知から形式知に変換したものであるといえる。 パターンの中には、クラウドでなくても実現できるもの、今まででも実現されていたものも含まれているが、クラウド上でも今まで通りのアーキテクチャが実現でき、かつクラウドを利用する事で、より安価にそしてより容易に実現できるものは、CDPとして収

  • UIデザインにおけるインターフェイスアーキテクトの役割|Goodpatch Blog グッドパッチブログ

    アーキテクチャ(Architecture)とは一般には建築や建築学を指しますが、コンピューターの世界ではあるシステムの概念や設計思想を「アーキテクチャ」という言葉で分類することがあります。中でもソフトウェアの領域では実装モデルの設計指針や分類、コンポーネントの相互関係、ソフトウェアの構築方法などを定めた一連の構造をそう呼ぶことがあります。 アーキテクト(Architect)とは建築家や(建築)設計士、技術者といった職種を指しますが、コンピューターの世界では「アーキテクト(仕組士): システムのアーキテクチャを設計する責任がある、人、チーム、あるいは組織」(IEEE 1471)と規定されます。要するに、システムの構造設計に関して責任を持つ役割です。「構造設計の指針を示し、実行する人」と言った方がわかりやすいでしょうか。 このような、構造設計やそれを担う設計士の役割は、当然のようにUIデザイン

    UIデザインにおけるインターフェイスアーキテクトの役割|Goodpatch Blog グッドパッチブログ
  • うちのチームにおけるTypeScriptの付き合い方

    MVPは最低限の機能しか作らないので、ブラッシュアップするのが前提にある。 なので変更しやすい方がいい

    うちのチームにおけるTypeScriptの付き合い方
  • 依存関係逆転の原則の重要性について

    こんにちは!eurekaのAPIチームでエンジニアをやっているrikiiです。 最近ついにAPIチームでモブプロを始めました。前は設計や実装について一人で悩んでたりした部分が、すぐ議論できたりホワイトボードに図で書いて理解を深めたりして、問題が素早く解決できてすごくいい感じで進んでいます。 さて、今回も前回の続きでSOLID原則の1つのDIP(依存関係逆転の原則)について書こうと思います。 eurekaではgo言語を使っているので、goを使ったコード例とともに説明していきたいと思います。 ちなみに依存関係逆転の原則とはSOLID原則と呼ばれるオブジェクト指向設計原則のうちのひとつです。 SOLID原則とは?下記5つの原則の頭文字を取ってまとめた、オブジェクト指向設計原則のことです。 ・S : The Single Responsibility Principle(単一責任の原則) ・O :

    依存関係逆転の原則の重要性について
  • 非エンジニアの方に「DDDって何なの?」と聞かれたときの説明[ドメイン駆動設計] - little hands' lab

    この記事はドメイン駆動設計 #2 Advent Calendar 2018の16日目の記事です。 DDD(ドメイン駆動設計)とは何なのか そもそもDDDってなんなの?ということをちょくちょく聞かれます。 一言で言うと、「開発手法の一種です」ですが、それだと「ふ〜ん」で終わってしまうので、もう少し興味を持ってもらえる回答を考えます。 まず、開発してて何に困るのかがわからないと思うので、そこから説明をします。 非エンジニア向けの説明 開発手法にも色々あり、行き当たりばったりに作ると以下のような問題に突き当たる、ということがよくあります。 実際の業務をきちんと理解しないで作ったら、 リリースしてもあんまり使われなかったり不評なものができる きちんと整理されてないプログラムを書いたら、 あとから修正するのがどんどん大変になる DDDは、このの2個とも解決しよう、ということで生まれた設計・開発手法な

    非エンジニアの方に「DDDって何なの?」と聞かれたときの説明[ドメイン駆動設計] - little hands' lab
  • ボトムアップドメイン駆動設計

    はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は

    ボトムアップドメイン駆動設計
  • 1