デザインガイドライン | e-Govポータル
デザインガイドライン e-Govでは、「デジタル・ガバメント実行計画」（2019年12月20日 改定（閣議決定））に基づき、国民・企業等の利用者の方に対して質の高い行政サービスを提供するため、サービスデザイン思考を導入し、利用者、ソフトウェアベンダー等との共創によって、e-Govの提供サービス及びデザインについて段階的な見直しに取り組んでいます。 この一貫として、今般、e-Govが提供する情報・サービスに関する見つけやすさの向上を目的として、一部コンテンツについて情報アーキテクチャ及びサイトデザインの見直しを行いました。このガイドラインは、その結果をサイトデザインにおけるベストプラクティスの一つとして、「情報設計」「UIデザイン」「UIデザインパターン」の観点から整理したものです。 今後、e-Govにおける継続的なサービス改善の実施と並行して、このガイドラインについても改訂を図っていくこと
Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基本的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ
[システム間連携]接続方向を逆転させるとうまくいく - Qiita
システムAの更新内容を、別のサーバにあるシステムBにも反映させるためにデータ送る、というケースを考えます。 主流はWeb APIかMOMを使う方法かと思います。(俯瞰的な話は、20日目のこざけさんが書いてくれる、はず) しかし、A,B間で同時に一貫性を保たなくても良いケースは、企業間システム連携ではよくあります。 CAP定理でいうところの可用性＋分断耐性をとりにいくパターンです。が、最大数秒程度で結果整合性は保ちにいきます。 システム間の接続 非同期ながら、ほぼリアルタイムでデータを反映していくので、応答性の高い接続手段が求められます。だが中間経路をHTTPでないプロトコルを通すハードルが高かったり、ファイヤーウォールなどで長時間接続を切られたりする問題があるので、私はよくWebSocketを使います。 だいたいの構成は以下のようになります。同期エージェント間をWebSocketでつなぎ、
![[システム間連携]接続方向を逆転させるとうまくいく - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/210d0d9e41b5a24e69550d7a3adb349654aaef15/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-f625e957b80c4bd8dd47b724be996090.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUUzJTgyJUI3JUUzJTgyJUI5JUUzJTgzJTg2JUUzJTgzJUEwJUU5JTk2JTkzJUU5JTgwJUEzJUU2JTkwJUJBJTVEJUU2JThFJUE1JUU3JUI2JTlBJUU2JTk2JUI5JUU1JTkwJTkxJUUzJTgyJTkyJUU5JTgwJTg2JUU4JUJCJUEyJUUzJTgxJTk1JUUzJTgxJTlCJUUzJTgyJThCJUUzJTgxJUE4JUUzJTgxJTg2JUUzJTgxJUJFJUUzJTgxJThGJUUzJTgxJTg0JUUzJTgxJThGJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkNtaWRkbGUmcz1lZTM4MGE4MTkyM2QxZTQ2OGUzZGM0OTY2MTRmOGQzMQ%26mark-x%3D142%26mark-y%3D151%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwa2F3YXNpbWEmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWNmZDVlMmM2OWUwOGQzNzQwZWVjMDFlMTljNjcyOWZh%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D809db66be0c6bcd29e6ce587a566e564)
「論理設計」にこだわる利点 - 設計者の発言
業務システムのあり方を構想する際には、論理設計と物理設計とをフェーズ分けしたほうがいい。システム要件を仕様化しやすくなるだけでなく、スキル育成や効率改善の基礎となるからだ。それはソフトウエアの特性にもとづくプレゼントのようなもので、ありがたく活用したい。 そもそも「論理設計」とは何か。「受注情報だけを管理する」という単純なシステム要件があったとしよう。その際、たとえば以下のような「論理定義」がまとめられることになる。 １．業務構成 受注登録業務、受注保守業務、受注照会業務 ２．データ構成 受注見出しテーブル、受注明細テーブル ３．機能構成 受注一覧機能、受注登録機能、受注保守機能、受注照会機能 ここでは定義要素の字面だけが示されているが、それぞれ独特な形式の詳細情報を伴う。たとえば「業務構成」は「いつ誰がどのようにこのシステムを利用するか」についての定義のまとまりなのだが、それぞれ「いつ(
間違い1「利用者視点しかない」
「セキュリティ対策は大事だ」。そう分かっていても、どこかで「メインはシステム本体の開発、セキュリティは二の次」「セキュリティ対策は後から考えればよい」といった意識を持っていないだろうか。そんな意識が、セキュリティ設計に思わぬ間違いを生み、システムの脆弱性を作り込む。 悪人になって攻撃 一つ目の間違いは、システムの機能を利用者視点でしか考えないというものだ。要件定義において、利用者に提供する機能はきちんと洗い出したとしても、その機能が悪用されたらどうなるかを逐一チェックしているだろうか。セキュリティ設計は本来、悪意を持った者がシステムを利用しようとするのを防ぐ対策を考えること。業務要件をまとめるための正規利用者の視点でシステムを見ている限り、起こり得るリスクは洗い出しきれない。 正規利用者に提供する機能を洗い出すには「ユースケース図」がよく用いられる。ユーザーや外部システムを表す「アクター」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自律制御しながら動的平衡状態の系を作るWebシステムとその未来 / a Future of Dimensionless Autonomous System
