わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
こんにちは丸山@h13i32maruです。システム全体を簡単な図とテキストでまとめる「ARCHITECTURE.md」というものを最近知りました。これは良さそうと思い、JasperのARCHITECTURE.mdを書いてみました。 jasperapp/jasper/ARCHITECTURE.md ARCHITECTURE.md自体の目的は「プロジェクトへの新規参加者が全体像の把握を効率的に行えるようにする」という感じです。書き方の指針や注意点などは考案者による記事を見てもらうのがよさそうです。また良いサンプルとしてrust-analyzerというOSSのARCHITECTURE.mdが紹介されています。 https://matklad.github.io//2021/02/06/ARCHITECTURE.md.html https://github.com/rust-analyzer/ru
イラストレーションの練習を100日やりました．知らないことばかりだったので勉強していてとても楽しかったです！ いいタグがあったので記念として初日に描いたものと並べておきます#進化してたらRT見た人もする#画力変化ビフォーアフター pic.twitter.com/WKhBvyZSoi — 都路 燕禅 (@enzen3852) November 29, 2020 イラストの練習を始めてトータル100日を突破しました．一旦立ち止まって初日のイラストと今のイラストを比べてみると，見違えるほど上達できたかなと思っています． そこで今回はこの記事で，私が100日でどんな練習を行い，どんな変化を遂げていったかを振り返ってみようと思います． (追記: 60日目と70日目のイラストの削除について。着物や扇子などの模様は、自分の手元や実家にある実物の写真・インターネットの写真などを複数参考にして、いずれのデザ
One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-of
著名 OSS にあって自作 OSS に無いものの一つにロゴがあります。 OSS において README の出来不出来はユーザへのリーチを高める重要な要素であり、詳細な Description や GIF によるデモはもちろん、ロゴがあればより魅力的な README になるでしょう。 また、SNS でシェアされる際もロゴがあればより良いでしょう。 はじめにソフトウェアエンジニアの多くはデザイナーではないためロゴを作るコストは低くなく、テキストだけ作るのであればまだ簡単ですが、自作アイコンを作ることはかなりの労力を要することでしょう。 僕も同様で、デザイナーではないため、結論として非デザイナーでも出来る戦略を考えることになりました。 今回は、micnncim 流の、出来るだけ低コストで低くないクオリティの OSS のためのロゴの作成方法について解説します。 慣れれば上の画像のようなロゴが 5
アプリケーションを実装していくと、「大規模なUI改修」に遭遇することがある。 あちこちで見聞きした結果、以下のようなパターンがあるように感じたのでまとめてみた。 （UI改修なので基本的にフロントエンドからみた内容） これは一般的に「技術的負債」と呼ばれることが多いが、デザインの負債（UIを置く場所が無くなったり無くなったり、同じ概念のUIが分散したり）である場合も多い。 （ちなみに、デザインの負債は「ダイアログを多用する」とか、「最小画面サイズが大きくなる」とかの形で現れやすい） そして、デザイン負債に対応するために実装の困難なUIが増えるため、技術的負債も高くなる傾向がある。 （サーバサイドの技術的負債がDBの負債に起因する場合が多いことと似ているかもしれない）
こんにちは、NewsPicksのデザイナーのよっしーです。 NewsPicks Adventカレンダー16日目を担当させていただくことになりました。とても緊張します...。 9月に入社し現在NewsPicksのアプリの機能改善やブランドの共通言語になるデザインシステム構築、広告バナーやイベント周りのデザイン、採用にも関わらせていただいています。つい一昨日にありがたいことに開発チームの新人賞をいただきました。 そんな私は2年前、デザインを全く知らない人間でした。4年間非デザイン職について、いまでは会員数300万人・有料会員数8万人のNewsPicksのプロダクトデザイナーとしてやらせていただいています。独学でwebやUIデザインを学んできた私にとって、本は師匠です。そこで今回「デザインの基礎」「美大卒アートディレクターから学ぶブランドデザインの思考」「ユーザー体験設計」の3つ分けてその一部を
AWSにおける形式手法の記事（https://lamport.azurewebsites.net/tla/formal-methods-amazon.pdf）を読んだ。特に重要だと思われる示唆を3つあげると以下の通り。 産業界では長年形式手法は多大な工数をかけて比較的容易なコードの断片を検証するというイメージがあったが、これはまったくの誤り。現実の問題に適用可能である アマゾンでは10の現実のシステムに適用して、すべてで効果が得られた。難解なバグの発見したり、正当性を犠牲にすることなく確信を持って最適化を施せた 7つのチームでTLA+を使用。エンジニアは2−3週間で学習することができる 以下は、読んでいる途中で書きだした要点。 AWSでは2011年以降形式仕様とモデル検査を使用している 複雑な分散システムを検証するにあたって、従来の手法 ― 設計レビュー、コードレビュー、静的解析、ストレス
One of the most common arguments in favor of FeatureBranch is that it provides a mechanism for pending features that take longer than a single release cycle. Imagine you are releasing into production every two weeks, but need to build a feature that's going to take three months to complete. How do you use Continuous Integration to keep everyone working on the mainline without revealing a half-impl
About 20年以上愛されている、デザインの定番書です。デザインはデザイナーだけに必要な要素ではありません。いまやエクセルやワード、パワーポイントを使って資料を作る際にも重要となります。読みやすいデザイン、伝わるプレゼン資料、わかりやすいレイアウトを作りたい方におすすめの一冊です。ロングセラーの本書を活用し、ステップアップを目指しましょう！ Feature １．デザインの「4つの基本原則」がわかる 近接、整列、反復、コントラスト……4つの基本原則だけで、デザインはぐっとずっと、よくなります。良い例、悪い例をそれぞれ挙げて、具体的に解説します。 ２．作例を多数解説 「4つの基本原則」を活用しながら、名刺、チラシ、パンフレット、広告などをデザインする際のテクニックを丁寧に解説します。 ３．活字を用いたデザインを解説 文字および活字は、デザインにおいて大きな役割を担っています。タイポグラフィの
class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.active? hogehoge.histories.last.update(state: :cancel) return error_message end case hogehoge.kind when "type_a" # ... when "type_b" # ... end ActiveRecord::Base.transaction do history.save! history.create_foobars end end end 何が酷いって、機能が何なのか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
