仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話｜田辺めぐみ
よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を
Web のセマンティクスにおける Push と Pull | blog.jxck.io
Intro 筆者は、 Web のセマンティクスに対する実装の方針として、大きく Push 型の実装 と Pull 型の実装 があると考えている。 もっと言えば、それは実装方法という具体的な話よりも、開発者のセマンティクスに対する態度を表現することができる。 この話は「Push よりも Pull が良い」などと簡単に切り分けられる話ではない。 「自分は今 Push で実装しているのか、 Pull で実装しているのか」この観点を意識するかしないかによって、セマンティクスに対する視野が広くなり、その応用として、たとえば今自分が行っている実装が、将来の Web においてどのような互換性の問題を生じるかなどを想像できるようになるだろう。最近問題になる Ossification を、こうした視点の欠如の結果とみることもできる。 (本エントリでの Ossification は、一般に言われている Pro
0.0.0.0/8のIPアドレスなどを利用可能にする提案仕様 - ASnoKaze blog
IPv4アドレスの枯渇すると言われ続けております。 「The IPv4 unicast extensions project」では、予約されているIPアドレスなどをユニキャストアドレスとして利用可能にし、4億1900万ものIPアドレスを追加することを謳っています。 実際、IETFで予約済みアドレスをユニキャストアドレスとして使用できるようにする提案を提出しています。 240.0.0.0/4 を利用可能にする提案 (draft-schoen-intarea-unicast-240) 0.0.0.0/8を利用可能にする提案 (0.0.0.0は除く) (draft-schoen-intarea-unicast-0) 127.1.0.0 ~ 127.255.255.255を利用可能にする提案 (draft-schoen-intarea-unicast-127) IPアドレスのホスト部が0のものを利
ID連携の標準化仕様紹介とセキュアな実装のためのアプローチ ~ 2021 - r-weblife
おはようございます ritou です。 久々に「解説付きスライド全公開」的なやつをやります。 先月、チーム内でID連携のための標準化仕様に関する勉強会(私が一方的に話す会)を行いました。 が、実際はだいぶグダグダになってしまい、これはその後色々付け足してるうちに別物になってしまった資料です。 内容としては、ID連携のための標準化仕様にどのようなものがあるかを知ってもらうための「入門編」のような立ち位置で作りました。 OpenID Connect(やSAMLのような) ID連携のための標準化仕様を紹介しようと思うと、ついつい個別にシーケンスやリクエスト/レスポンスの説明を始めがちですが、初学者が気になるのはそんな細けぇことではないでしょう。 まずは「この仕様で何ができるようになるのだろう」「この仕様では何を実現したいんだろう」と言うところから理解していくのが良いのではないでしょうか。 そこで
スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
WebAssemblyがW3Cの勧告に到達。「WebAssembly Core Specification 」「WebAssembly Web API」「WebAssembly JavaScript Interface 」の3つ
W3Cの WebAssembly Working Groupは、Webブラウザ上でネイティブコードに近い実行速度で高速に実行できるバイナリフォーマット「WebAssembly」の仕様が勧告に到達したことを発表しました。 今回勧告になったのは、WebAssemblyに関連する3つの仕様です。 1つ目はWebAssemblyのバイナリファイルを実行する仮想マシンの仕様を定義した「WebAssembly Core Specification」。これは一般的なマイクロプロセッサの動作を模倣するような作りにすることで、WebAssemblyのバイナリファイルでプロセッサのネイティブコードに近い実行速度を実現するようになっています。 2つ目の「WebAssembly Web API」は、さまざまなプラットフォームでWebAssemblyを利用可能にするため、WebAssemblyバイナリファイルのシリ
Webの健全性を守る主役は果たして誰なのか - WebStudio
もずはっく日記(2018年11月) 2018年11月19日 Webの健全性を守る主役は果たして誰なのか 初回投稿日時: 2018年11月19日04時09分19秒 最終更新日時: 2018年11月19日21時49分43秒 カテゴリ: 雑談 SNS: Tweet (list) 前々から書かなきゃと思っていたことを書こうと思います。なんでこんな大仰な記事のタイトルなのか。中二病? そうかもしれません。でも多分当事者の方々はおそらく自分達の持っている社会的な重要性を自覚されていない、そう思っているので書くことにしました。 ブラウザ界隈を長く観察している人ならご存知かと思いますが、Mozillaが非営利(実際には私含め、スタッフのために金を稼いではいますが、それはさておき)でブラウザを開発し続けているのはWebのユーザのためです。ですが、そういった錦の御旗を掲げているMozillaも含め、私は特
Microsoft、「.doc」「.xls」などのOfficeバイナリファイル仕様を公開
米Microsoftは15日、Office 97以降で使われているバイナリファイル形式の文書仕様を公開した。「Microsoft Open Specification Promise」（OSP）プログラムの下で使用できる。 公開されたのは拡張子が「.doc」「.xls」「.ppt」となるOffice製品のバイナリファイル仕様。これらのバイナリファイルはOffice 97より採用され、Office 2003まで基本的な保存形式となっている。最新版のOffice 2007からはデフォルト保存形式が「Office Open XML」（.docx、.xlsx、.pptx）となっているが、バイナリ形式での保存もできるようになっている。 MicrosoftのWebサイトでは「Word 97-2007バイナリファイルフォーマット」（.doc）、「Excel 97-2007バイナリファイルフォーマット」（
RFC2616: ハイパーテキスト転送プロトコル -- HTTP/1.1
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
ISMS制度に関する概要・基準・ガイド等
ISMS認証基準(JIS Q 27001:2014)の要求事項について一定の範囲でその意味するところを説明しているガイドです。 主な読者は、ISMS認証取得を検討もしくは着手している組織において、実際にISMSの構築に携わっている方及び責任者を想定しています。 ※参考文献の最新版は、こちらからダウンロードできます。(Pdf：550kB)（2015.08.07更新）
OpenID & OAuth 仕様書を日本語に翻訳しました - 京の路
昨年末にOpenIDファウンデーション・ジャパン参加企業の有志数名で翻訳・教育 Working Groupというのを立ち上げて、現在は主にドキュメントの翻訳を行っています。 現在4本のドキュメントの日本語版を翻訳・教育 Working Group のサイトで公開しています。（この記事の末尾にリンクあり） 翻訳後のドキュメント以外に、githubレポジトリも公開しています。forkもpull requestも大歓迎！原文との比較がしやすいように、各翻訳版のXMLファイルにはコメントアウトの形で原文も残されています。 翻訳版ドキュメントへのコメント・質問は翻訳・教育 Working Group のサイトのコメント欄にどうぞ。 OpenID Authentication 2.0 OpenID Attribute Exchange 1.0 OpenID Simple Registration Ex
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
