#asken_dev「設計の考え方とやり方」勉強会 https://asken.connpass.com/event/254709/ ・良い設計は悪い設計より変更が楽で安全である ・ドメインモデル方式のクラス設計 ・イミュータブル方式のテーブル設計 ・設計スキルの身につけかた ・設計のためのモデリング
設計の考え方とやり方
#asken_dev「設計の考え方とやり方」勉強会 https://asken.connpass.com/event/254709/ ・良い設計は悪い設計より変更が楽で安全である ・ドメインモデル方式のクラス設計 ・イミュータブル方式のテーブル設計 ・設計スキルの身につけかた ・設計のためのモデリング
GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita
概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは？ Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する人が作成するドキュメントです。 => ソフトウェア設計における仕様書や設計書とは別物と捉えた方がよいです。 仕様書、設計書は作成した上でのDesign Docsの作成となるようです。 このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられて
【メモ】良いDesign Docs(Software Design Document)を書くためのリソース集
自分が良い Design Docs(Software Design Document)を書くために、読んだ/参考になったリソース集 一覧 Design Docs とは Design Docs at Google デザインドック(Design Doc)について デザインドックで学ぶデザインドック 残業も減らせる!? 上級エンジニアになるための Design Doc 超入門 「Design Doc」って何なのか？ What Is A Design Doc In Software Engineering? (full example) What is a Design Doc: Software Engineering Best Practice #1 https://github.com/kaiinui/note/blob/master/Design--Designdoc.md Googleの
Web API 設計のベスト プラクティス - Azure Architecture Center
ほとんどの最新の Web アプリケーションでは、クライアントがアプリケーションと対話する際に使用できる API を公開しています。 適切に設計された Web API には、次をサポートする目的があります。 プラットフォームの独立。 API の内部的な実装方法に関係なく、すべてのクライアントが API を呼び出すことができる必要があります。 そのためには、標準プロトコルを使用し、クライアントと Web サービスが交換するデータの形式に同意できるメカニズムを備えている必要があります。 サービスの進化。 Web API はクライアント アプリケーションから独立して進化し、機能を追加できる必要があります。 API の進化に伴い、既存のクライアント アプリケーションが変更なしに引き続き機能する必要があります。 クライアント アプリケーションが機能を十分に使用できるように、すべての機能が検出可能である
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
データビジュアライゼーションの基礎
情報を正しく伝え、美しくかつ明確な図やグラフを作成するための基本を解説します。「ビジュアライゼーションで大切なことは、本質を正しく伝えること」との信念に基づき、見栄えの悪い図、不適切な図、誤った図を避け、情報を正確にかつ効果的に伝えるために最適な要素、かたち、色の選択をするための指針をまとめています。著者は統合生物学の分野で著名な研究者であるだけでなく、cowplot、ggridgesをはじめ、数多くのRのデータ可視化関連パッケージの開発者であり、著者の豊富な経験から蓄積された知見の集大成と言える本書からは、優れたグラフを作成するための原則、哲学、美学を学ぶことができます。本書収録のグラフを作成したRコードはGitHubから利用可能。 訳者まえがき まえがき 1章 はじめに 1.1 見栄えの悪い図、不適切な図、誤った図 第Ⅰ部 データからビジュアライゼーションへ 2章 データを可視化する：
これだけは押さえよう！住所フォームの作り方 - ケンオールブログ
まとめ 住所フォームの作り方 住所フォームを作るときには以下の4つを押さえましょう。 オートコンプリート機能に最適化する 郵便番号フィールドは1フィールドにしてハイフン有無どちらも対応する モバイルUX優先なら郵便番号が入力されたら即座に補完。精度優先なら郵便番号補完ボタンを設置 住所フィールドは「都道府県」「市区町村」「町名以下」の3フィールドが基本。「建物」フィールドはオプション 本文 地域SNSのユーザー登録、ECサイトの配送先入力、資料請求、自治体サイトでの電子申請など、ウェブサービスを活用する上で住所入力は欠かすことができません。 住所入力をシンプルかつ正確に行えるような入力インタフェース（住所フォーム）は、離脱率を減らし、コンバージョン率を向上させる上で重要です。 郵便番号を入力すると対応する住所を自動入力する機能（郵便番号による住所補完）は、住所フォームの改善方法として最も効
アイコン・外観写真ダウンロード
ヤマハネットワーク/UC製品のアイコン/外観写真を用途を問わず、ご自由にダウンロードできます。 印刷用データとしてご利用の方は、SVG/EPSデータをご使用ください。 切り抜いて使用したい方は、PNGをご使用ください。 ネットワーク構成図 作成用アイコン
アプリケーションの設計にEIPの知識が役に立つよ！
非同期メッセージングを使ったインテグレーションパターン (EIP)は、クラス設計にも参考になるものが多い。 すぐに非同期メッセージングを使わないとしても、EIPは設計の参考情報として知っておきたい。
ソフトウェアの複雑さに立ち向かう1つの哲学 :『A Philosophy of Software Design』 を読んだ - こまぶろ
あけましておめでとうございます、になるはずだったのですが、後から読んだ『Googleのソフトウェアエンジニアリング』の方を先に記事にしたので新年2本目の更新です。 ky-yk-d.hatenablog.com さて、本題。最近のお気に入りポッドキャストであるe34.fmで激賞されていた『A Philosophy of Software Design』を読みました。初版は2018年に出ていて、今回は2021年に出た第2版を読みました。 スパゲッティコードを想起させる装丁 A Philosophy of Software Design, 2nd Edition (English Edition) 作者:Ousterhout, John K. Amazon scrapbox.io どんな本？ 書籍のテーマはソフトウェアの複雑さです。複雑さとは、システムを理解したり変更したりするのを困難にさせるも
設計を歪める認知バイアス - Qiita
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、5日目の記事です。 これはなに？ ソフトウェア開発において、設計をないがしろにすると、低凝集密結合な構造に陥り、変更容易性が低下してしまいます。 設計スキルを高め、あるべき構造を設計する……これで解決できるに越したことはありません。 しかし、認知バイアスと呼ばれる心理効果により判断を誤り、良くない設計をしてしまうことが往々にしてあります。 本記事は、設計を歪めてしまう認知バイアスを理解し、設計判断の精度向上を促すことを目的とします。 この記事のゴール 人間の判断を歪めてしまう心理効果「認知バイアス」の存在を知ること。 ソフトウェア設計も、認知バイアスの悪影響を受けてしまうこと。 認知バイアスに振り回されない設計アプローチを身につけること。 認知バイアスとは 先入観や思い込み、偏
ミルクボーイがUIとUXの違いを説明したら｜広野 萌
挨拶内海「どうもお願いします。ありがとうございます。今、NFTアートをいただきましたけどもね。ありがとうございます。こんなんなんぼあってもいいですからね」 駒場「いきなりなんですけどね、うちのおかんがね、好きなIT用語があるらしいんやけど」 内海「そうなんや」 駒場「その名前を忘れたらしいねん」 内海「IT用語の名前忘れてまうってどうなってんねん。あれやろ、IT用語ゆうたらどうせ、デザイン思考か、アジャイル開発か、リーンスタートアップやろ！」 駒場「俺もそう思ったんやけどちゃうらしくてな、いろいろ聞くんやけど、全然わからへんねん」 内海「そうなん？」 駒場「うん」 内海「ほんだら俺がね、おかんの好きなIT用語、一緒に考えてあげるから、どんな特徴言うてたかとか教えてみてよ」 定義駒場「おかんが言うには、製品やサービスとの関わりを通じて利用者が得る体験及びその印象の総体やって言うてた」 内海「
API design guide | Cloud API Design Guide | Google Cloud
Send feedback API design guide Stay organized with collections Save and categorize content based on your preferences. Changelog Introduction This is a general design guide for networked APIs. It has been used inside Google since 2014 and is the guide that Google follows when designing Cloud APIs and other Google APIs. This design guide is shared here to inform outside developers and to make it eas
出渕裕ロングインタビュー1 出渕裕とブチメカと富野由悠季と（一時工事中）
ここには『出渕裕ロングインタビュー』1回目が掲載されておりましたが、サイト主の不手際も重なり、原稿の直し決定稿と差し替えることになりました。 全ての責任はサイト主の市川大河にありますが、楽しみに訪れて下さった皆様には大変申し訳なく思っております。 第5回以降は既に直した原稿との差し替えは済んでおりますので、そちらからまずはお楽しみください。
ボンカレーの箱からガンダムを作ってみた！ パッケージのデザインを生かしながら「ボンカレーガンダム」が完成！
投稿者のpocariroboさんがボンカレーゴールドの箱でガンダムを作ります。 まずはガンダムのデザインを調べて試作を繰り返し、図面を作りました。 図面を元に箱を切り分けます。色や文章など、箱のデザインに合わせカットされているのがよくわかりますね。 カットした紙を折り曲げてまず作ったのは足先です。 同様に各パーツを組み立てていきます。 腰部や胸部など、とてもガンダムらしいフォルムです。 国産の文字がくっきりと見えるのはランドセル。 曲げられた指の作りも細やかな手のパーツ。 ボンカレーガンダムの頭部もできました。顔はファースト寄りにしたそうです。 シールドには大きくボンカレーの文字が。 裏面には余った材料を貼りディテールアップ。 全てのパーツが揃いました。 ボンカレーガンダム 甘口タイプの完成です！ 中辛、辛口も作りました。 ダークな色合いの大辛タイプまであります。 並んだボンカレーガンダム
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
api-guidelines/Guidelines.md at vNext · microsoft/api-guidelines
デザインのしたじき
予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
ドット絵ダウンロードサイト DOTOWN|無料の素材サイト
