Oracle Solaris 11.1 ご使用にあたって 『Oracle Solaris 11.1 ご使用にあたって』では、Oracle Solaris 11.1 オペレーティングシステム (OS) をインストールまたは実行する前に考慮する必要がある重要なインストールの問題、更新の問題、および実行時の問題について説明します。 Oracle Solaris 11.1 Release Notes (English) The Oracle Solaris 11.1 Release Notes describes the important installation issues, update issues, and runtime issues that you might need to consider before installing or running the Oracle
日時 2011年11月30日 16:00～18:30 会場 富士ソフト アキバプラザ プログラム紹介ページ (敬称略) タイトル 講演者 配布資料 (PDF)
オフィス文書形式が要求されるようなドキュメントではなくて、自分が開発したライブラリのドキュメント（リファレンスマニュアルやチュートリアルなどライブラリのユーザーが読むためのドキュメント）の話です。以下の「ドキュメント」もそのような意味で使っています。 使いやすいライブラリを開発したかったらプログラムだけではなくドキュメントも書くべきです。 なぜドキュメントを書くか ドキュメントを書く習慣があるかどうかは開発者によってあったりなかったりです。使っているプログラミング言語に相関がある気もしますし、リリースするかどうかに相関がある気もします。理由はいろいろあるでしょうが、ドキュメントを書く習慣のない開発者の方が多いでしょう。 書かない理由はこんな感じでしょうか。 面倒。 自分しか使わないからいらない。 どのように書けばよいかわからない。（どのツールを使えばよいかわからない。） 一方、書く理由はこ
■ [ruby] ruremaコマンド(gem install myrurema)が少し便利になりました Rubyの新しいリファレンスマニュアルであるるりまプロジェクトのリファレンスを コマンドラインから引くツール、myruremaをアップデートしました。 候補が複数あったときに、以下のようにどれを表示するか聞いてくるようになりました。 /Users/yhara/proj/myrurema % rurema each_w (1)Enumerable#each_with_index (2)Enumerable#each_with_object (3)Matrix#each_with_index (4)Prime::PseudoPrimeGenerator#each_with_index which one? > エディタから呼び出す場合などキーボード入力したくない場合は、--no-askを付
リファレンスマニュアルの記述方法を検討し、埋め込み方式のドキュメントツールを採用したとします。Rubyで埋め込み方式のドキュメントツールを使うとしたらRDocかYARDになります1。 RDocからYARDへの移行方法につなげたいのでYARDを使う方向で話を進めたいわけですが、その前にRDocとYARDの背景や機能の違いを確認しておきましょう。 RDocの背景 RDocはRuby 1.8.1からRuby本体に標準添付されています。Ruby1.8.1は2003年のクリスマスにリリースされているので、もう7年くらい前になります。Ruby本体や標準添付されているライブラリもRDoc用にドキュメントが書かれていますし、Rubyで標準的なドキュメントツールといえばRDocという存在です。 RDocは2004年くらいまではRuby本体のリポジトリ上で活発に開発されていましたが、それから数年は開発が停滞し
Rubyではライブラリのリファレンスマニュアル作成のドキュメントツールとしてRDocが標準となっています。これは、古くからあるという理由とRuby本体に標準添付されているという理由からです。しかし、RDocはそれほど活発に開発されていないため、最近のドキュメントツールとして機能不足と言わざるをえません1。どのような機能が足りないのかについては別の機会にします。 数年前からYARD（Yey! A Ruby Documentation Tool）というドキュメントツールが開発されています。YARDはRDocとの互換性を残したまま機能を拡張しているため、RDocからの移行も容易です。実は、YARDは第2回フクオカRuby大賞（SSLの証明書の期限が切れているので警告がでます）に「Improving Documentation in the Ruby Community」というタイトルで応募してい
昔から「Rubyはドキュメントが弱い」と言われてきました。「PythonやPHPはあんなにドキュメントが揃っているのに、それに比べてRubyは。。。」というわけです。でも、待ってください。ドキュメントは記述が充実しているだけで十分ですか？簡単に目的のドキュメントにたどりつけますか？ GoogleやBingなどの検索エンジンや、Amazonを筆頭とするECサイトは「探しものを見つけやすくする」ことにどんどん磨きをかけています。なぜ、ドキュメントの検索機能はそれほど進歩しないのでしょうか？ ドキュメントの検索機能が、検索エンジンやECサイトでも使われているような最新の検索パターンを取り入れ、もっとリッチになればプログラミングがもっと楽しくなるはずです。それをRubyのドキュメントで実現しようとしているのがるりまサーチです。 最近、るりまサーチがよりパワーアップしたので、どう変わったかを紹介しま
■ [ruby] ローカルのgemのドキュメントを見る簡単な方法(2010秋) The 3 Step Guide to Slick Local Documentation for all your Ruby Gems 1. $ gem install yard 2. $ yard server --gems 3. http://localhost:8808/ を開く これは便利。特に、普段--no-rdocしててrdocがない場合でも、動的にrdocを生成してくれるところが。 165 http://d.hatena.ne.jp/willnet/20111006/1317877272 49 http://reader.livedoor.com/reader/ 27 http://blog.willnet.in/entry/20111006/1317877272 14 https://www.
(この記事はRuby Advent Calendar jp: 2009の8日目の記事です．前の方はすがまさおさんで，後の方は@Sixeightさんです．) YARD プログラミング言語では，コメントから自動的にドキュメントを生成するツールが大抵用意されていて，RubyにもRDやRDocがあります．RDocは広く使われているので，Rubyistであれば使ったことがあるんじゃないかと思います．そんな中でDataMapperやHamlなど，最近使われるようになってきているのがYARDです．gemが用意されているので $ gem install yardでyardocやyriなどが使えるようになります． yardoc RDocみたいなもので，ソースからドキュメントを生成してくれます．書式は以下のような感じです(スタートガイドから引用)． # Converts the object into tex
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 第5回「ドキュメントの質を確実に上げる6つの文章作法」に続き、顧客に伝わる文章を記述するためのポイントを紹介します。今回は、修辞句や用語など、「より具体的な表現方法」について説明します。なお、前回同様に、まず「分かりにくい例文」を取り上げてどこが分かりにくいのかを解説し、その後に分かりやすい文章へと修正していきます。 「修飾語を適切に使う」ことが、読みやすい文章を作るコツ 分かりやすい文章を書きたいなら、「修飾語」に着目しましょう。修飾語を使うときは、以下のような点に注意します。 長い修飾語は前に、短い修飾語は後に置く 文章を書く際は、句や文節を使った長い修飾語を前に、
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章：拡張機能開発で使う技術（下田 洋志） 拡張機能開発に利用する技術 それぞれの技術の役割 最低限
You are here: Home → 原稿・資料 → Software Design 2008年2月号 「Emacsマスターへの道」 原稿
職場でここ３〜４ヶ月の間、システム再構成のためのドキュメント化プロジェクトというのを進めてきた。その中で『ドキュメントを書く』ということに対する意識が随分自分の中で変化したので、メモしておく。 まずは経緯から。 そのシステムは、いわゆるレガシーなシステムで、十数年来の歴史を持つ。これまで基盤が多少変わることがあっても基本的にソフトウェアアーキテクチャ（どのような単位で機能をモジュール化するか、どのように機能を抽象化し変化に対して柔軟にするか）に変わりはなく、作った当初の設計にツギハギしてメンテナンスを続けていた。 元々は、一体何をすれば増員以外の手段で開発量を上げられるかということを議論していた。現行のアーキテクチャのままでは求められる開発期間とバージョンアップのサイクルに対して近い将来限界を迎えることが明白であったためだ。 今のアーキテクチャや設計に問題があり、メンテナンス性を大いに損ね
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く