継続的ドキュメンテーション - コード知識共有への新たなアプローチSpring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
iPhone SDKを使ったアプリ開発の第一歩を無料のPDFで学ぼう：CloseBox & OpenPod：オルタナティブ・ブログ
iPhoneデベロッパー必携の書籍、木下誠さん著の「iPhone SDKプログラミング大全」は大人気のため、現在在庫切れだそうです。でも、とにかく開発を始めてみたい、そんな人に朗報が。 英語版ですが、hello, worldのプログラムをiPhoneで作れるところまで案内してくれる、無料のPDFが出ていました（MAKE: Blog経由）。 さっそくダウンロードしてみました。XcodeやInterface Builderの具体的な操作方法などが、図版付きで分かりやすく説明されています。全20ページなので、英語ではありますが、簡単に読み進められると思います。 ・Free eDoc on Getting Started with iPhone Development
満足せる豚。眠たげなポチ。:業務システム開発でドキュメントを作ることについて
職場でここ３〜４ヶ月の間、システム再構成のためのドキュメント化プロジェクトというのを進めてきた。その中で『ドキュメントを書く』ということに対する意識が随分自分の中で変化したので、メモしておく。 まずは経緯から。 そのシステムは、いわゆるレガシーなシステムで、十数年来の歴史を持つ。これまで基盤が多少変わることがあっても基本的にソフトウェアアーキテクチャ（どのような単位で機能をモジュール化するか、どのように機能を抽象化し変化に対して柔軟にするか）に変わりはなく、作った当初の設計にツギハギしてメンテナンスを続けていた。 元々は、一体何をすれば増員以外の手段で開発量を上げられるかということを議論していた。現行のアーキテクチャのままでは求められる開発期間とバージョンアップのサイクルに対して近い将来限界を迎えることが明白であったためだ。 今のアーキテクチャや設計に問題があり、メンテナンス性を大いに損ね
[Think IT] 第1回：開発ドキュメントって何ドキュか？ (1/3)
【楽々デブドックを書こう！】開発☆ドキュン 第1回：開発ドキュメントって何ドキュか？ 著者：シンクイット編集部 公開日：2008/02/01（金） 妖精さんと学ぶ開発ドキュメント システム開発も終盤に差し掛かってくると、疲れが溜まったり、睡眠時間が足りないといったために「ふっ」と意識が遠のくことがある。しかし、自分で入力した覚えがないのにコードが書かれていたり、知らないうちにバグがどこかに消えていた、ということはないだろうか。 実は開発者の作業能力が低下すると、C言語で開発しているのなら「C言語の妖精さん」、Java言語で開発しているなら「Java言語の妖精さん」が、どこからともなく現れて、あなたの代わりに作業を続けてくれているのだ。 古くから使われている言語であれば、妖精さんたちも高いスキルを誇っているのだが、最近になって登場したり、重要視されるようになった箇所の妖精さんは、まだまだ新人
満足せる豚。眠たげなポチ。:ドキュメントは重要ではない。なんて言わない。
「（相対的に）ドキュメントは重要ではない。」と考えていたけど、改宗する。「そのドキュメントが何を表現するかを考えずに、ドキュメントを作る」という行為が無駄なのであって、「設計を文書にして残す。それをレビューする。」という行為はけして無駄じゃない。やるべきなのは、「何をドキュメントにするか、何をドキュメントにしないかを判断すること」と、「レビューして、設計での一定レベルの合意を形成すること」だ。そして、その目的は「品質の高いインターフェースを持ったコードを共有し、スケールさせることができるようにする。」という点に尽きる。 ふつうのプログラマで成り立つプロジェクトだからこそ、上記を徹底しないといけない。詳細設計として程度の悪い擬似コードを日本語で書いたようなドキュメントを受け取る必要は当然なく、その分、たとえばビジネスルール単位で、それをどのように設計するのかを検討する必要がある。これをコード
システムの要求仕様書を適切に作成するためのガイドライン，JUASが公開
「ユーザー企業が必要としているのはどのようなシステムか」を定義した要求仕様書を，いかに適切に作成するか――IT業界における長年の懸案事項である。日本情報システム・ユーザー協会（JUAS）は7月5日，この課題の解決を狙った「要求仕様定義ガイドライン」を発表した。システム開発に必要な情報を盛り込んだ要求定義書をどのように書けばよいかを具体的に示すことを意図したもので，「要求仕様書をいかに作るかという“how”に踏み込んだガイドラインは初めてではないか」と，JUASの細川泰秀専務理事は話す。まだ未完成の部分もあるが，ユーザー企業やベンダーの参考資料として役立ちそうだ。 要求仕様定義ガイドラインでは，要求仕様書の構成要素を，(1)（狭義の）要求仕様書，(2)概念データモデル，(3)入出力の定義，の三つとする。中核となるのは(1)。まず，システムに対する要求を「上位の要求」「下位の要求」という二つの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Appcelerator Developer Center - API for (version 1.6.2)
単体テスト計画書 （1） ― 表紙・目次・第1部・第1章