日本語組版処理の要件（日本語版）
1.1 このドキュメントの目的 書記システムは，言語，文字と並び，文化を構成する重要な要素である．それぞれの文化集団には独自の言語，文字，書記システムがある．個々の書記システムをサイバースペースに移転することは，文化的資産の継承という意味で，情報通信技術にとって非常に重要な責務といえよう． この責務を実現するための基礎的な作業として，このドキュメントでは，日本語という書記システムにおける組版上の問題点をまとめた．具体的な解決策を提示することではなく要望事項の説明をすることにした．それは，実装レベルの問題を考える前提条件をまず明確にすることが重要であると考えたからある． 1.2 このドキュメントの作成方法 このドキュメントの作成は，W3C Japanese Layout Task Forceが行った．このタスクフォースは，次のようなメンバーで構成され，ユーザーコミュニティーからの要望と専
W3C - W3Cの仕様書等の文書の日本語訳集
注意 日本語翻訳集は w3c-translators@w3.org メーリングリスト上で報告された日本語翻訳文書へのリンクを集めたものです． リンクされた翻訳はボランティアによって行われたものです． またこれらの翻訳には誤りが含まれる可能性もあります． 正式なものはあくまでも英語版ですので， この点をご理解頂いた上でご利用下さい． またコピーライトに関する情報を含め，W3Cの文書の翻訳に関しての一般的な情報や， 翻訳の際のヘルプは， http://www.w3.org/Consortium/Translation/にあるW3C翻訳ページ(英語版) をご覧下さい． TR集 勧告 ・ 勧告案 ・ 勧告候補 ・ 草案 ・ 技術ノート その他の文書等 FAQ集 ・ その他 TR集 勧告 HTML 4 (勧告) http://www.asahi-net.or.jp/~bd9y-ktu/html4re
はてな システム開発で使用する仕様書、スケジュール管理用のスケジュール表のサンプルを探しています。できればフリーでワード、エクセルのデータ形式のもの・・
システム開発で使用する仕様書、スケジュール管理用のスケジュール表のサンプルを探しています。できればフリーでワード、エクセルのデータ形式のものが良いです。
ECMAScript Language Specification - ECMA-262 Edition 5.1
Standard ECMA-262 5.1 Edition / June 2011 ECMAScript® Language Specification This is the HTML rendering of Ecma-262 Edition 5.1, The ECMAScript Language Specification. The PDF rendering of this document is located at http://www.ecma-international.org/ecma-262/5.1/ECMA-262.pdf. The PDF version is the definitive specification. Any discrepancies between this HTML version and the PDF version are unint
The SWF file format delivers vector graphics, text, video, and sound over the Internet and is supported by Adobe Flash Player and Adobe AIR software. Flash Player already reaches over 98% of Internet-enabled desktops and more than 800 million handsets and mobile devices. The SWF file format is designed to be an efficient binary delivery format, not a format for exchanging graphics between graphics
電書ちゃん ろすちゃん、ろすちゃん見て見て。 EPUB3の仕様の一つが日本語訳されて公開されているみたいよ。 EPUB Publications 3.0 日本語訳 ｜ IMAGEDRIVE EPUB Publications 3.0（日本語訳版） ろす おおっ、@IMAGEDRIVEさんの翻訳ついに完成したんだ。しかも@fumi1さんのレビュー付き。 おめでとうございますアーンドありがとうございます！ 電書ちゃん なあに？ あんた知ってたの？ ろす いやいや、以前ちょろっとご本人から立ち話で聞いただけっすわ。 EPUBの本質であるPublicationsから手を付ける辺りがニクイよねえ。 僕なんかメタデータについては疎い方なんで、その方面の専門知識のあるお二人が翻訳を手掛けたのは仕様にとっても幸福なことだと思うよ。 電書ちゃん あんたも読んで勉強させて貰いなさい。 ろす はーい。 ところで
自分なりにまとめたシステム仕様書の書き方を書いておきます。 表紙 表紙は1枚でまとめる。 ・システム名 ・版数 1.00からスタート。改訂するごとに1.10、1.20と増えていく。細かい修正などは1.01などとする。 ・仕様書の枚数 変更履歴 変更履歴は新規作成時、変更毎に記入する。1枚でまとめる。 ・システム名 ・版数 ・変更区分（新規 or 更新） ・変更したページ番号 ・変更内容 ・作成者＆作成日 ・承認者＆承認日（押印等） はじめに この仕様書の意味を記述する。この仕様書が、誰に対して、何を実現するシステムの、何に関して記述しているのかを記述する。必要であれば、お客様のどの要望を、どのように解決するのかも記述する。またシステム固有の専門用語が出てくる場合はその説明も付け加える。1枚程度でまとめる。 目次 番号体系が3層になるように記述する。以下に例を示す。 1 業務要件・・・・・・
Real-Time Messaging Protocol (RTMP) specification | Adobe Developer Connection
The Real-Time Messaging Protocol (RTMP) was designed for high-performance transmission of audio, video, and data between Adobe Flash Platform technologies, including Adobe Flash Player and Adobe AIR. RTMP is now available as an open specification to create products and technology that enable delivery of video, audio, and data in the open AMF, SWF, FLV, and F4V formats compatible with Adobe Flash P
- UML超入門
UML，みなさん実際に使ってますか？私たちは現場の開発において， ここ４年間UMLを利用してきました． その経験をふまえて，この記事ではUMLの概略をざっと説明した後， 実例を交えてUMLを使ったシステムの開発を紹介して行こうと思います。 1章では，なぜUMLを使うのかというお話からはじめて， UMLの意味と歴史 をおさらいします． また，実際の開発プロセスでの一般的なUMLの利用法についても外観します． 2章で，簡単な業務システムを例にしてUMLの記法をひと通り詳しく解説して行きます． なるべく分かりやすく具体的な例として，社員の出退勤の管理を行う，勤怠管理システムを選びました． 3章では，組み込み分野に近いちょっと面白い例として， LEGOMINDSTORMS(TM)(*)を使ったロボット制御を例題にして，実際の開発の流れを追ってみたいと思います． 4章では，UMLの拡張例をいくつかご
WEBディレクションの極意 文＝島元大輔 大阪のWeb制作会社でWebディレクターとして活躍後、（株）キノトロープに入社。数多くの企業Webサイト構築プロジェクトにかかわる。その後、 （株）ライブドアに入社、現在は（株）セシールに在籍。著書として「だから、Webディレクターはやめられない」（ソシム刊）。 url.blog-project.cecile.co.jp/ 第9回 Webマスターと社内の関係 企業のWebサイトを構築するとき、制作から運用までさまざまな人物がかかわる。その中で、企業側のネット担当者をWebマスターという。ここではWebマスターの立場からWebディレクションに焦点を当てて、Webプロジェクトをスムーズに進めるための方法論を解説していこう。制作会社という受注側の立場も経験し、現在はWebマスターという立場で業務を行っている筆者ならではの見解を述べていく。 ■Webマスタ
要求仕様戦争（その3）
■仕様書をどうこうする――「要求」の見える化 「要求を仕様化する技術・表現する技術」がオススメ。「要求とは」「仕様とは」からはじめて、仕様戦争までの経緯、回避するための具体的施策までが分かる。「Excel を用いた仕様書」はなかなか興味深い。 著者は「要求」と「仕様」の関係をロジックツリーに見立てる。こんなカンジ。仕様1～n を実装すれば要求Ａが実現する、という仕掛けだ。 ┌───┐ │要求Ａ │ └┬──┘ ├─仕様1（スペック1-1,1-2,1-3...） ├─仕様2（スペック2-1,2-2,2-3...） ├─ … └─仕様n（スペックn-1,n-2,n-3...） まぁ、こんなにキレイにならないだろうが、「このスペック（群）で"やりたいこと"は実現していると言えるのだろうか?」という視線が、どのフェーズでも配れるという点は素晴らしいと思う（実際に目配りするかどうかは別として）。 本
弊社サービスをご利用頂き、誠に有り難うございます。 ドキュメントのダウンロード件数が2007年5月の開設以来300000件を突破しました！ 今度ともご愛顧の程よろしくお願いいたします。 PocketDOC(ポケットドック)とはシステム開発に必要な設計書や仕様書などのドキュメントやテンプレートはもちろんのこと、 議事録、納品・検収書、近年話題になっている個人情報に関しての取扱管理表などの ドキュメントやテンプレートも提供しています。 実際に弊社のプロジェクトで使用されているため精度も高く、カスタマイズなしでも利用可能なほどです。 上流工程から下流工程まで広い範囲をサポートしているので、 必要なテンプレートだけをダウンロードして利用することも可能です。 ドキュメントやテンプレートのファイル形式はWord(doc形式)やExcel(xls形式)です。 ダウンロード後、すぐにお使いいただけるように
仕様書の書き方 - Qiita
仕様書を書く上で必要かなと思うことをまとめてみた。 対象者は、まだ仕様書なんて書いたことないよとか、何書くかいつも悩む、という方。 ここでいう仕様書とは、開発前の設計書というよりは、運用フェーズに引き渡す前に用意しておいたほうがよいドキュメント、という位置づけ。 仕様書の目的 仕様書を書く目的は、新しい人がチームに来た時に、スムーズに業務に取り組めること。 また、「人は時間が経つと必ず忘れる」ので、将来の自分のためでもある。 大事なこと 仕様書の目的を明確にする。 あれもこれも、と情報をたくさんのせても混乱する。 「仕様書にもメンテナンスコストがかかる」ことに注意する。 仕様書は正しい日本語で書く。 主語をきちんと入れることが大事(〜のつもりで書いた、というのは知らない人には伝わらない)。 情報は多すぎず、少なすぎず。 条件について場合分けして整理したり、図を用いたりすると良い。 前提と制
基本設計は、顧客の要件を実現するための機能を具体化する工程だ。 基本設計工程では、画面・帳票・テーブルなどの設計した後に「基本設計書」としてまとめるが、どのような資料を作るのか不安を感じるエンジニアも多いと思う。 そこで...
[設計編]ユースケースに詳細を書いてはいけない
機能要求を「ユースケース」（利用者＝アクターから見たシステムの利用場面）としてまとめ，それを基に分析設計することが一般化してきた。ところが「ビジネス・ルールを入れ込んだり，if～thenレベルのロジックまで書き込んだりと，誤った書き方をしている人が結構多い」と，日本を代表するITアーキテクトの1人，榊原彰氏（日本IBM 東京基礎研究所 IBMディスティングイッシュト・エンジニア）は指摘する。どんどん詳細化し，必要ない情報まで盛り込んでしまうのだ。 「詳細化しないと気が済まないのだろう。『分析麻痺（Analysis Paralysis）』と言える」と同氏。オブジェクト指向分析設計とプロジェクトの「見える化」を実践・推進するチェンジビジョンの平鍋健児氏（代表取締役）も同意見。「画面レイアウトなど情報量が多過ぎることが結構ある。ユースケースはシステムの目的なのに，ユースケース＝機能と考えるからそ
![[設計編]ユースケースに詳細を書いてはいけない](https://cdn-ak-scissors.b.st-hatena.com/image/square/bed39b5962a5d552c95b6d796db8f55e72d32943/height=288;version=1;width=512/https%3A%2F%2Fxtech.nikkei.com%2Fimages%2Fn%2Fxtech%2F2020%2Fogp_nikkeixtech_hexagon.jpg%3F20220512)
話題沸騰ポット 要求仕様書
■ 話題沸騰ポット GOMA-1015型 要求仕様書 電子ポットを題材にした組込みシステム分析・設計のための要求仕様書です。この要求仕様書をもとに電子ポットシステムを分析・設計してみることで組込みソフトウェア技術者の実践的教育を行うことができます。 話題沸騰ポット要求仕様は、SESSAMEが開催するセミナーで使用する資料です。本要求仕様書は、版によって想定している用途が異なります。 【第１版～第６版】 現実の開発現場でよく見受けられる曖昧さを含んだ仕様書として作成しました。曖昧部分に気づき、要求仕様書はどこまで詳細に分析し、明確に表現すべきかを考えていただくための教材です。 【第７版】 できる限り曖昧さをなくした仕様書の例として作成しました。なお、SESSAMEでは要求分析の最終段階ではこの記述のレベルまで仕様を明確にすることを期待しています。 本要求仕様書は雑誌『Software Peo
機能要件設計書だけで20種類
意図が伝わる設計書を作るには，前提として「それぞれの設計書がどういう役割を担うか」「それぞれの設計書が相互にどういう関係にあるか」を正しく理解しておくことが重要である。豊富なサンプルとともに，設計書の役割と関係，さらには書き方のコツを解説する。 石川貞裕 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 担当本部長 向坂太郎 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 「基本設計書」と聞いて，どんなものをイメージするだろうか。業務フロー図や画面レイアウト，E-R図など様々だろう。大規模，高品質のシステムを開発するなら，図1に示すような多くの設計書を作成することになる。 中心となる機能要件設計だけでも20種類。それぞれの役割や関係をきちんと理解し，過不足なく設計情報を盛り込むことが求められる。 難しいのは，設計書の読み手が開発者だけではないことだ
要求仕様（要求工学：第3回）
概 要 今回はIEEE830[１]に基づいてソフトウェアに関する要求仕様の標準的な構成例を紹介しよう。立命館大学の大西教授と山梨大学の郷助教授による「要求工学」[２]の第４章でもIEEE830が解説されている。 IEEE830では表1に示すように要求仕様を、目次、はじめに、要求仕様の一般的な説明、要求仕様の具体的な説明、付録、索引から、構成することを推奨している。 IEEE830 では、ソフトウェアをシステムの一部であるとしており、システムの要求仕様とソフトウェアの要求仕様を区別するためソフトウェア要求仕様（ Software Requirements Specification）を略してSRSと記述する。これに対してシステム要求仕様をSyRSと略記する[３]。本稿ではSRSについて解説する。 表1 IEEE 830 による要求仕様の構成 SRS 第1章「はじめに」 「はじめに」ではSRS
いつも、この「極言暴論」でイチャモンをつけているSIerのビジネスだが、彼らにも世界一と自慢できるものがある。それは開発を請け負ったソフトウエアの品質だ。「えっ、嘘でしょ！」と言う読者もいると思うが、これはどうやら事実のようだ。確かに、インドのITベンダーなどが作るものに比べて、バグなどが少ない高品質なソフトウエアを生み出している。 読者は「あれ、木村さん、SIerを褒めるなんて変節したの？」といぶかっているだろうが、ご安心いただきたい。私はSIerのプロジェクト管理や品質管理が素晴らしいと言うつもりもないし、SIerをはじめとする日本のITベンダーの技術者のスキルがとりわけ高いと主張するつもりもない。そんなことを言えば、それは悪い冗談である。むしろ、逆だと思っている。 今ではそんな騒ぎも少なくなったが、少し前までインドなどでのオフショア開発は失敗の連続だった。現地のITベンダーへ発注した
Press release 9 April 2009 - Ecma International finalises major revision of ECMAScript
Essential cookies are strictly necessary for the proper operation of our site. In particular, they govern the principles of navigation and memorize some of your choices between pages. If you refuse them, your browsing experience may be affected. Analysis cookies collect statistical and anonymous information on the traffic recorded on our site. They help us to improve our pages, in order to better
CSS Flexible Box Layout Module Level 1 (W3C Last Call Working Draft, 25 March 2014)
CSS Flexible Box Layout Module Level 1 W3C Candidate Recommendation, 19 November 2018 This version: https://www.w3.org/TR/2018/CR-css-flexbox-1-20181119/ Latest published version: https://www.w3.org/TR/css-flexbox-1/ Editor's Draft: https://drafts.csswg.org/css-flexbox-1/ Previous Versions: https://www.w3.org/TR/2018/CR-css-flexbox-1-20181108/ https://www.w3.org/TR/2017/CR-css-flexbox-1-20171019/
W3Cの勧告候補平成13年11月13日 この版: http://www.w3.org/TR/2001/CR-css3-selectors-20011113 最新の版: http://www.w3.org/TR/css3-selectors 前の版: http://www.w3.org/TR/2001/WD-css3-selectors-20010126 編者: Daniel Glazman (Netscape/AOL) Tantek Çelik (Microsoft Corporation) Ian Hickson Peter Linss (former editor, formerly of Netscape/AOL) John Williams (former editor, Quark, Inc.) 摘要 CSS(段階スタイルシート)は、HTML及びXMLの文書の、画面上、紙面上、音
技術情報Wiki - 技術情報Wiki
2024-02-28 GitHub Copilot スクラム 2024-02-27 AIによる開発支援 2024-02-26 コンテナオーケストレーション 周辺機器 パソコン Python関連 IoT/スマートホーム 2024-02-25 スキルアップ一般 読み物 PDF関連 PythonによるWebアプリ開発 職業としてのエンジニア 英会話・ビジネス英語・技術英語 アジャイル ノート・モバイル・携帯etc 2024-02-24 C/C++言語 AIと社会／人類 Microsoft Azure 音声認識・音声合成 IPv6まとめ IT業界の動向など IPv6アドレス OpenAIのAPI JavaScriptのTips Office関連メモ 2024-02-23 SSL/TSL/HTTPS関連 確率・統計 GitHub関連 2024-02-22 Gitコマンド 大規模言語モデル LLMのロ
ウォーターフォール型の開発では、要件定義、設計、プログラミング、テスト、運用といった作業工程が時系列に進んでいく。開発当初に作成される要件定義や基本設計のドキュメントは、そのプロジェクトに関わる人たち全員が目にするため、そのドキュメントにあいまいな点や複雑な点などがあれば、後々の行程で問題が発生し、品質と生産性に影響する。この課題を解消するのが、株式会社シーイーシー PROVEQサービス事業部の開発した日本語文のあいまい度診断ツール『ClearDoc』だ。 ウォーターフォール型の開発では、要件定義、設計、プログラミング、テスト、運用といった作業工程が時系列に進んでいく。開発当初に作成される要件定義や基本設計のドキュメントは、そのプロジェクトに関わる人たち全員が目にするため、そのドキュメントにあいまいな点や複雑な点などがあれば、後々の工程で問題が発生し、品質と生産性に影響する。この課題を解消
ソフトウェア個人開発プロセス手順書
●ソフトウェア個人開発プロセス手順書 version 0.4 目次 目的 プロセスの順番について、サンプルについて 開発手順 文章管理 開発管理帳 （開発体制表、 スケジュール表、 作業スタック、 要求履歴、 作業履歴、 数値データ） 基本仕様書の記述項目 試験仕様書兼報告書の記述項目 試験報告書の記述項目 評価報告書 分析 ～ 現状の理解と目的と対応の分析 見積もり作成 基本仕様作成 仕様変更 設計 ～ 各担当による機能実現の手段 入出力設計 イベント設計 詳細仕様作成（プログラミング） 試験仕様作成、試験方針 テストプログラム作成 状況欄 出荷モード 予防 デバッグ レビュー コーディング・レビュー レビュー記録 進捗報告 ISO-9001 の要求事項との対応 ◆ 目的 本書は、ソフトウェア開発の実際の作業に則しながら 品質を保証する手順のテンプレートです。 本書は、筆者の開発手順をモ
文書の構造を示すことを目的とする。見た目の装飾に関わることを記述しない。 宣言 特に事情がない場合は，文字コードをUFT-8にして，XML宣言を省略する。 DOCTYPEは原則的にXHTML 1.0 Strict 。 ただし，更新スタッフの事情に合わせてXHTML 1.0 Transitional，HTML 4.01 Strict，HTML 4.01 Transitionalにする場合もある。 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> head ページの性質を示し，UAに読ませることを目的とする。 最初に <meta http-equiv="Content-Type" content="text/html; ch
開発プロセス 吉田誠一のホームページ
ソフトウェア開発のプロジェクトは、なかなか一筋縄ではいかない。予定通りに進まなかった原因、作業の遅れをもたらした問題点など、実際のプロジェクトから得られる教訓は大きい。 得られた教訓を活かし、次のソフトウェア開発をより良く進めるためには、プロジェクトを総括・反省する、プロジェクトレビューが重要となる。効果的なレビューを実践するには、プロジェクトを客観的に解析できるような具体的な資料を用意して臨む必要がある。そのためには、プロジェクトの実績を数値として算出することが大切だ。 ................ 続きを読む
2021/02/04 非暗号化ポート（http://api.calil.jp/）の仕様は削除しました。引き続きご利用いただけますが、新規の利用は推奨しません。 2013/05/17 すべてのAPIでSSLによる暗号化通信に対応しました 概要 カーリル図書館APIでは、全国のOPAC対応図書館のほぼすべてを網羅するリアルタイム蔵書検索機能を提供します。 また、全国の図書館の名称、住所、経緯度情報などをまとめた図書館データベースへのアクセスを提供します。 図書館APIの使用 蔵書検索は、書籍の「ISBN」と、図書館の「システムID」をキーにして検索を行います。 ISBNは、10ケタと13ケタ、ハイフンの有無などいくつかの形式がありますが、図書館APIではどの形式にも対応しています。 システムIDは、各図書館が導入している蔵書管理システムの固有の識別子で「Kanagawa_Fujisawa」のよ
プログラマが結婚する方法:アルファルファモザイク
なんか俺わくわくしてきた。 俺と結婚するやつなんているのかな。 いるんだろうなｗ 自然とそうなるんだろうな。 なんというか、 幸せにしたいけど。 式には安倍さんとかブッシュ、コキントウ、プー賃とかにも招待状冷やかしで出してみようかな。 来たりして。
スタートアップにおけるソフトウェア開発では今や当たり前となったGitHub。ですが、開発以外の用途にも活用できる可能性があることをご存知でしょうか？ SELECKを運営するリレーションズ株式会社では、ソースコードの管理だけではなく、次のような用途にもGitHubを活用しています。 SELECKの記事の品質を上げるための自動校正ツール 誰でも編集でき、どこでも閲覧できる仕様書作成ツール 今回はこの2つの事例を紹介します。 ▼Githubの使い方についてはGithub入門の連載記事をご覧ください。 チーム開発を変える「GitHub」とは？導入方法・使い方を徹底解説！【第1回】【導入編】 GitHubはソースコード管理の枠を越えて活用されている SELECKでは今まで、数々の企業にGitHubの活用方法を取材しました。 GitHub本来の使い方であるソースコード管理に主軸を置いたサイバーエージェ
Joel on Software - やさしい機能仕様 - パート 2: 仕様書とはどんなものか?
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/3 (パート1はもう読んだ? 読んでなければ、ここにある。) このアーティクル･シリーズで扱っているのは機能仕様であって、技術仕様ではない。人々はこの2つを混同している。標準的な用語があるのかどうか知らないが、私がこれらの用語を使うときに意味しているのは以下のことだ。 機能仕様書は、ユーザの観点から製品がどのように動くか記述する。それはどのように実装されるかは問題にしない。それは機能を話題としており、画面とか、メニューとか、ダイアログとかいったものの仕様を定める。 技術仕様書は、プログラムの内部の実装について記述する。それはデータ構造、関係データベースモデル、プログラミング言語や開発ツールの選択、アルゴリズムといったものを話題としている。 あなたが製品を隅から隅までデザインするとき、最
「仕様書をSubversionとTracで管理する」に続いて、今回は仕様書をTracのWikiで作成する話。 Tracの登場以前に、仕様をPukiwikiで書き始めたのがそもそも発端だけど、Wikiを使うメリットとして下記が挙げられると思う。 仕様同士のリンク 経験的に言って、仕様書は一つだけでは収まらないことが多い。関連する仕様として、仕方なくたくさんのファイルを作っていく事になるのだけど、数が増えると相互参照が大変な作業になる。この点、WikiならWebのリンクを辿るだけなので、情報へのアクセスが容易だ。 仕様の一意性確保 （社内サーバにて）一意のURLと仕様が紐づけられるので、仕様として意味するところを明確に指定できる。ファイルだとファイル名に整理用の数字を入れたり、最新版の資料の置き場所を常に意識しておく必要があった。 ファイルよりも更新が簡単 気分的なものが大きいかも知れないけど
The JSR-133 Cookbook
Where: Normal Loads are getfield, getstatic, array load of non-volatile fields Normal Stores are putfield, putstatic, array store of non-volatile fields Volatile Loads are getfield, getstatic of volatile fields that are accessible by multiple threads Volatile Stores are putfield, putstatic of volatile fields that are accessible by multiple threads MonitorEnters (including entry to synchronized met
現在では、PEARのAPIドキュメントなどはphpDocumentorが使われるようになっています。 仮に、あるプロジェクトで作成したクラスを他のプロジェクトでの使いたい場合、「ソースを追ってAPIを調べてね」なんてやってると余計な工数がかかってしまいますし、いつの間にか自分自身も忘れてるってことあります。そこで、何らかのAPIドキュメントがあると非常に楽ですよね。 Javaにはjavadocという強力なツールが用意されていますが、PHPでそれに相当するのが、PHPDocです。 PHPDocは、PHPDoc本家、あるいは、PHP本家のcvsリポジトリから入手することができます。 PHPDoc - Home http://www.phpdoc.de/doc/ PHP本家のCVS http://cvs.php.net/cvs.php/pear PHPDoc本家から入手したzipは、ブラウザから
[JavaScript] typeof arg == 'undefined' っていらないんじゃね？ / LiosK-free Blog
2008-09-24 カテゴリ: Client Side タグ: Tips JavaScript 以前にも JavaScript の null と undefined に関する記事を書いたことがあったが、またしても性懲りもなく null と undefined の挙動につまずいて、 ECMAScript 3 の仕様書まで調べ直したので、メモ代わりにエントリー化。 Abstract このエントリーの内容をざっくりとまとめると、 something == null がどういう値を返すのかが気になって、ECMAScript 3 の仕様書までさかのぼって調べてみると、 null == null undefined == undefined null == undefined undefined == null のパターンでのみ true を返すということがわかった、という話。細かい経緯は続きで。
法務・知財
情報サービス取引 同業者間取引 知的財産権法 経営資源管理 サイバーセキュリティ 法務・知的財産関連政策 法務研修テキスト 報告書 JISAブックレッツ14「デジタル時代のIT法務と契約実務」2022年11月1日新発売！ 今日必要とされる法務・契約上の知識を多角的視点から編纂しています。 ◆内閣官房・公正取引委員会 「労務費の適切な転嫁のための価格交渉に関する指針」の公表について ～労務費の転嫁に係る価格交渉について、発注者及び受注者がそれぞれ採るべき行動/求められる行動を「12の行動指針」としてまとめたものです。 ◆公正取引委員会 「労務費の適切な転嫁のための価格交渉に関する指針」と「取引適正化・価格転嫁促進に向けた取組」についての説明動画 ～YouTubeで配信中です。 情報サービス取引 システム開発・運用取引 JISA報告書「JISAソフトウェア開発委託基本モデル契約書2020」 報
メディアクエリー
この文書は「Media Queries (W3C Recommendation 19 June 2012)」の日本語訳である。日本語訳は参考情報であり、公式な文書ではない。また、翻訳に誤りがある可能性にも注意されたい。 原文の最新版 は、この日本語訳が参照した版から更新された可能性がある。他の仕様の訳については Web 標準仕様 日本語訳一覧 を参照されたい。 公開日: 2012-06-29 翻訳者: 矢倉 眞隆 <yakura-masataka@mitsue.co.jp> メディアクエリー 2012 年 6 月 19 日付 W3C 勧告 (Recommendation) この版: http://www.w3.org/TR/2012/REC-css3-mediaqueries-20120619/ 最新版: http://www.w3.org/TR/css3-mediaqueries/ 最新
仕様書と通信方法が違うから、1銭も払いません！――全ベンダーが泣いた民法改正案を解説しよう その2：「訴えてやる！」の前に読む IT訴訟 徹底解説（32）（1/4 ページ） IT紛争解決の専門家 細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。民法改正がIT業界にもたらす影響の解説、第2回は「成果物」についての変更点を取り上げる。
Geolocation API
Geolocation API W3C Recommendation 01 September 2022 More details about this document This version: https://www.w3.org/TR/2022/REC-geolocation-20220901/ Latest published version: https://www.w3.org/TR/geolocation/ Latest editor's draft:https://w3c.github.io/geolocation-api/ History: https://www.w3.org/standards/history/geolocation Commit history Test suite:https://wpt.live/geolocation-API/ Impleme
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SWF and AMF Technology Center | Adobe Developer Connection
EPUB3の仕様が日本語で読めるよ - 電書ちゃんねるBlog
Flash Video (FLV) Open Source Flash
システム仕様書の書き方 - shingotadaの日記
第9回 Webマスターと社内の関係 - MdN Design Interactive
設計書仕様書テンプレート PocketDOC | 株式会社イーイノベーション
基本設計における成果物一覧と書き方（基本設計書サンプルあり） | 若手エンジニアの羅針盤
「日本のソフトウエア品質は世界一」という事実と、その非常識
選択子
あなたの仕様書は大丈夫？ 日本語文のあいまい度診断ツール『ClearDoc』でドキュメントをチェック
XHTML・CSSコーディングガイドライン | d-spica | ホームページ制作・ウェブサイト制作・Webデザイン
図書館API仕様書 | カーリル
開発以外でも使える！GitHubの一歩先ゆく活用術【文書校正・仕様書作成】 | SELECK
仕様書をTracのWikiに記載する - rabbit2goのブログ
PHPDoc - APIドキュメントの自動生成 - Do You PHP?
仕様書と通信方法が違うから、1銭も払いません！――全ベンダーが泣いた民法改正案を解説しよう その2