Firefox拡張機能開発チュートリアル - outsider reflex
Firefox拡張機能開発チュートリアル XULの基礎からXPCOMの利用方法まで徹底解説！ 2008/4/12 2008/9/25 2009/3/12 Software Design誌2007年4月号第2特集「Firefox拡張機能開発チュートリアル」をFirefox Developers Conference Summer 2007でテキストとして頒布するために再録したものです。また、付録として知って役立つOSSのライセンスも収録させていただいています。 ダウンロード 目次 奥付 ライセンス 関連文書 Home Back to List 目次 1章：Firefox拡張機能ことはじめ（江村 秀之（level）） はじめに 拡張機能普及の背景 拡張機能でできること 拡張機能を作ってみよう！ 2章：拡張機能開発で使う技術（下田 洋志） 拡張機能開発に利用する技術 それぞれの技術の役割 最低限
満足せる豚。眠たげなポチ。:業務システム開発でドキュメントを作ることについて
職場でここ３〜４ヶ月の間、システム再構成のためのドキュメント化プロジェクトというのを進めてきた。その中で『ドキュメントを書く』ということに対する意識が随分自分の中で変化したので、メモしておく。 まずは経緯から。 そのシステムは、いわゆるレガシーなシステムで、十数年来の歴史を持つ。これまで基盤が多少変わることがあっても基本的にソフトウェアアーキテクチャ（どのような単位で機能をモジュール化するか、どのように機能を抽象化し変化に対して柔軟にするか）に変わりはなく、作った当初の設計にツギハギしてメンテナンスを続けていた。 元々は、一体何をすれば増員以外の手段で開発量を上げられるかということを議論していた。現行のアーキテクチャのままでは求められる開発期間とバージョンアップのサイクルに対して近い将来限界を迎えることが明白であったためだ。 今のアーキテクチャや設計に問題があり、メンテナンス性を大いに損ね
ウノウラボ Unoh Labs: ドキュメントを楽しく楽に書くために
yukiです。 今回は主にアジャイル開発におけるコード以外のドキュメントについてお話しようと思います。 「包括的なドキュメントよりも、動作するソフトウェア」という言葉がありますが、最近これを「ドキュメントはいらない」もしくは「極力書くべきではない」と誤解され、ドキュメントが軽視されがちだと感じます。 確かに、ドキュメントは面倒です。コードを書いている方が何万倍も楽しいですし。私も出来れば面倒なドキュメントは書きたくはありません。 「コード見ればわかるでしょ」とか「コードがドキュメントだ」と言い切るのは簡単ですし、事実そういった事もあるでしょう。というより、むしろその方が多いかもしれません。ですがコードをドキュメントとして扱うには、必要十分となるようなものでなくてはなりません。 そうではない(見てもわからんような)コードが多いのも事実ですし、それにドキュメントはまったく必要ないかといえばそ
ウノウラボ Unoh Labs: ブラウザから使用できる仕様書を書くツールまとめ
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き -
Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合 → fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく
デスマーチ撲滅への「飛躍」なるか--大手SI事業者、外部設計書の記述を標準化
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます デスマーチはデスマッチになりやすい――。SI業界でよく言われることだ。しかし、そのデスマーチを撲滅するための即効薬は、いまだ存在しない。そうしたなかで、デスマーチを撲滅するための「小さな一歩だが、大きな飛躍」と関係者から期待されている文書類が公開された。 NTTデータなど大手SI事業者6社が2006年4月から共同で立ち上げた「実践的アプローチに基づく要求仕様の発注者ビュー検討会」（発注者ビュー検討会）の第1弾の成果物がこのほどウェブで公開されたのである。同検討会には、NTTデータのほか、富士通、NEC、日立製作所、構造計画研究所、東芝ソリューションの計6社が参加している。 発注者ビュー検討会は、情報システムの仕様について、ユーザー企業に
仕様書をExcelで書くんじゃねぇ:アルファルファモザイク
>>3 ていうかエクセルで印刷するのはキツイ。txtのほうがまし。 平均１０ページ×３０シート×５０ファイルなんて泣きたくなるぞ。 そのうえ印刷するとあちこちのセルが欠けるもんだから、徹夜で直したことがある。 個人の資料ぐらいならいいけど、人に渡すつもりならホント止めてほしい。
MOONGIFT: » Railsを見える化「RailRoad」:オープンソースを毎日紹介
Ruby on Railsの素晴らしい点の一つに、テーブル間の関係をプログラム中で定義することで、データを自在に取り出せるようになるという事が挙げられる。 E-R図などでリレーションを定義しても、それが適切にプログラムされているかどうかは分からない。だが、プログラム中で定義し、制御できるRailsであれば適切に処理されるようになる。足りないのはマネージャ向けのE-R図の存在だろう。 今回紹介するオープンソース・ソフトウェアはRailRoad、Rails向けのダイアログジェネレータだ。 RailRoadを使うと、モデルやコントローラーの関係から、Graphviz向けのdotファイルを生成できる。後はSVGやPNGといった形式への変換が可能だ。 モデルであればE-R図が生成され、テーブル間の関係も表現される。コントローラーであれば、メソッドが表示される。どちらも複数人での開発時や、規模が大きく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Twitter API 仕様書 日本語訳