# 紛らわしい・似たような用語 ## removeとdelete * remove: 取り除く * delete: 削除する ## 設定 * Properties（プロパティ）は一つのコンポーネントまたはオブジェクトの特性を表すもの * Options（オプション）はグローバルな振る舞いを変えるもの。 無効にできるというニュアンス * Settings（設定）とPreferences（ユーザー設定）は複数の選択肢があり、無効化するものではないというニュアンス * Configuration（構成）はユーザー向けにカスタマイズするもの（ユーザーでなくアプリケーション提供者が予め設定しておくということか？） アプリケーション提供者が決めるものはconfiguration（構成）、ユーザーが決めるものはsettings（設定）という感じかな。 ## 作成と生成 作成はcreate 生成はgenerate 印象としては勝手にできる系は生成、すごくコアなところから作り出すのは生成な気がする ## rpmのdevelとsrcの違い * devel developmentの略 主に開発に関連したものが入っているパッケージ 開発用のツールだったり、コンポーネントだったり。 動的な仕組み（機能がモジュール化されているもの）を使うソフトウェアの場合は、通常の使用でも必要になることもある ライブラリオブジェクトやヘッダファイル（lib***.soや***.h）が含まれている * src すべてのソースコードが入っている イメージとしては、開発できるもののみを切り出したのがdevelでsrcは全ソースコード ## 完成の定義 ストーリー、スプリント、リリースなど、さまざまなレベルでの「完成」の定義について 「完成」という言葉は「完了したこと（complete）」を意味するのによく使われます。開発チームが「このストーリーは完成した」と言うときはこの意味です。また「受け入れたこと（acceptance）」を示すのにも使われます。プロダクトオーナーが「このストーリーは完成だ」と言うときはこの意味です。私が人に教えたり、コーチするときには、こう言っています。「完成（done）」と言ってはいけません。代わりにもっと状態を具体的に表すよう「完了した（complete）」「受け入れた（accepted）」という言葉を使いましょう。 ## mntとmedia mnt:一時的なマウントポイント。mediaとの違いは、一時的なファイルシステム（fstabなど）のマウントに使う点。 media:リムーバブルメディアのマウントポイント。（floppy、CD、DVDなど） ## コミッターとコントリビューター 本来は、 コミッター：開発やメンテナンスにおいて，プログラムを書き換える権限を持つ人 コントリビューター：バグ報告やパッチ配布を実施する人 だが、 GitHubではあまり違いがなくなってきている。 元来コミッターのほうが上位。 使うときはどっちでもいいんじゃね？ ## 財務・会計・経理 「経理」は「仕訳を切るための知識体系」という感じで、 「財務会計」を行うためのテクニックの一つ、というニュアンスです。 「会計」は、「財務会計」と「管理会計」を合わせた、範囲の広い、割と漠然とした言葉です。 「財務」は、「会計」とはちょっと毛色が違います。 基本的には、「資金調達をする仕事」です。 で、ちょっと乱暴ですが、会社内の部門に当てはめると。 「経理」と「財務会計」をやるのは経理部です。 仕訳を切ります。 「管理会計」をやるのは経営企画部です。 どの製品が儲かっていてどの製品が儲かっていないのか、を明らかにする帳票を作り、経営者に示します。 「財務」をやるのは財務部です。 経理部や経営者と連携を取りながら、資金計画を練り、銀行の人と交渉してお金を借りたり返したりします。 ## ConfigurationとSettings 構成 >>> 設定 構成の中の小さい範囲に設定があります。 Configurationは、大きな設定のときに使う。 Settingsは、個別要素の設定のときに使う ## 保存と保管の違い 保管(中期〜長期、使用頻度低い、より整理・管理された状態) 保存(短期〜中期、使用頻度高い) ## プロセスとプログラム | 用語 | 意味 | | -------- | -------------------------------------------------------------------------------------------------------- | | プロセス | プログラムが実行している状態。Linuxのpsで見れるもの。 | | プロセス | プログラムが実行している状態。Linuxのpsで見れるもの。 | | プログラム | コンピュータが行うべき処理を順序立てて記述したもの。C言語でできたオブジェクトファイル、ライブラリ、シェルスクリプトなど | | モジュール | 機能群。クラスのようにオブジェクト化できないもの | | アプリケーション | アプリケーションソフトウェア、つまり応用ソフトウェア。特定の目的を達するために記述され，実行可能な状態になったプログラムの総称。大分類としてはプログラムに内包される。 | | ソフトウェア | プログラムのこと。主にハードウェアと対比する際、大きくくくる場合（システムソフトウェア、アプリケーションソフトウェアなど）に使用する。 | | コンポーネント | クラスやモジュールの集まり。プログラムとして動くまでにはいかない。 | | ライブラリ | 特定の機能を持ったプログラムを、他のプログラムから利用できるように部品化し、複数のプログラム部品を一つのファイルにまとめたもの。ライブラリ自体は単独で実行することはできず、他のプログラムの一部として動作する。 | | 実行ファイル | プログラムの内クリックやプログラム名称をコールするだけで起動するもの。 | | タスク | 実行時間を指定されたプロセス | | ジョブ | Windows:プロセスの集合体。Linux:現端末で起動しているプロセス | ## プログラミングとコーディング | 用語 | 意味 | | ------- | ---------------------------------------------------------------------------------------------------- | | プログラミング | プログラムを作成することにより、人間の意図した処理を行うようにコンピュータに指示を与える行為。若干仕様が曖昧な部分がありそれを考えながら作業を行うときに使う。 | | プログラミング | プログラムを作成することにより、人間の意図した処理を行うようにコンピュータに指示を与える行為。若干仕様が曖昧な部分がありそれを考えながら作業を行うときに使う。 | | コーディング | コードを書くこと。仕様が明確に決定されておりそれをコードにする作業。仕様をコードに翻訳する作業。 | | 製造 | システム開発において、詳細設計のあと単体試験の前の工程のこと。工程を指す場合に使うのが一般的である。場合によって詳細設計を含むこともある。「設計と製造」という具合に設計と対比するときなどにも使用する。 | | 実装 | 製造と同義。ソフトウェア業界では主に製造の方を使用するほうが多い | | 作成 | 製造と同義。ソフトウェア業界では主に製造の方を使用するほうが多い | | 制作 | 製造と同義。ソフトウェア業界では主に製造の方を使用するほうが多い | | 開発 | 設計とか製造とかを含んだザックリとした言い方 | 製造は、小規模PJやアジャイルではプログラミングであるべきで、大規模PJや仕様が確定しているPJではコーディングであるべき。 ## 正常、異常 | 用語 | 意味 | | --------- | -- | | 正常 | | | 正常 | | | 異常 | | | 不正 | | | 例外 | | | Normal | | | Error | | | valid | | | invalid | | | true | | | failure | | | success | | | positive | | | negative | | | correct | | | Incorrect | | ## システム構成とネットワーク構成の違い システム構成とネットワーク構成は大体同じような図になるが、システム構成の方は人や外部装置まで含んで書くことがある。その代わりシステム構成は、ネットワーク情報を詳細に書くことはない。 ## ファイル名でのconf,config,iniの違い | 用語 | 意味 | | ------ | -------------------------- | | conf | 拡張子のときに使用する。httpd.confなど | | conf | 拡張子のときに使用する。httpd.confなど | | config | ファイル名のときに使用する。config.xmlなど | | ini | iniファイル形式の設定ファイル | ## テレメトリ・コマンド関係の紛らわしい言葉たち | 用語 | 意味 | | --------------------- | ---------------------------------------------------------- | | テレメトリ | 地上と衛星で通信する際の下り側（地上受信側）データ。ダウンリンクデータのこと。主にCCSDSパケットで送られてくる。 | | テレメトリ | 地上と衛星で通信する際の下り側（地上受信側）データ。ダウンリンクデータのこと。主にCCSDSパケットで送られてくる。 | | ダウンリンクデータ | テレメトリのこと。 | | HKテレメトリ（バス系テレメトリ） | HKのデータのこと | | ミッションデータ（ミッション系テレメトリ） | ミッションのデータのこと | | S-tlm | 主にHKデータのことを指すことが多い。が、本来の意味はSバンドのダウンリンクデータ | | X-tlm | 主にミッションデータのことを指すことが多い。が、本来の意味はXバンドのダウンリンクデータ | | リアルテレメトリ | 探査機から直接送信される | | リプロテレメトリ | データレコーダに記録された後、再生されて送信されるテレメトリ | | ストアードテレメトリ | リプロテレメトリと同様だと思われる | | 観測データ | 低速データの対義語。リアルテレメトリと同様だと思われる | | 低速データ | リプロと同様だと思われる | | コマンド | 地上と衛星で通信する際の上り側（地上送信側）データ。アップリンクデータのこと。 | | アップリンクデータ | コマンドのこと。 | | リアルタイムコマンド | 衛星に到達後、直ちに実行されるコマンド | | タイムライン（ストアード）コマンド | 衛星に到達後、格納され指定された時間に実行されるコマンド | ## 要求と要件 「要求」は単に求めていることであり、「要件」は形式化した要求条件である ## 仕様書と設計書と要件定義書と要求仕様書と設計仕様書の違い * 仕様書とは「WHAT？何がしたいのか？」について書かれたもの。設計の前に書くもので、そのシステムが実現すべき機能や動作上の制約などを定義する。仕様書は確実にユーザに公開されるべき。 * 設計書とは「HOW？どのように作るのか？」について書かれたもの。仕様書をもとに、具体的にどうやってシステムを開発・構築していくかを記す。設計書はユーザに公開されなくてもよい。 * 要件定義書の目的は、まずシステム開発のゴールを定めること。利用者がそのシステムなどで何がしたいのかを元に、それを実現するために実装しなければならない機能や、達成しなければならない性能などを開発者が検討して明確にしていき、まとめた文書。RFPの業務要求とほぼ同じ。 * 要求仕様書は要件定義書と同様のようなもの。アジャイル開発やプロトタイプ開発などは、これらの各工程の境目が曖昧で、「目に見えるモノを作りながら仕様を固めていく」というスタイルの場合に使われることが多い模様。要件定義書の前段階として、今回の依頼に何を期待しているのか目的を整理し、付随する要求も含め関係者が矛盾なく認識できるよう『仕様化』したものとして使われる場合もある。が、結果的に要件定義書のようなものになるはず。 * 設計仕様書は、よくわからない。使わないほうが無難。まず設計書なのか？仕様書なのか？両方なのか？個人的には、設計の仕様書のことだと思っている。 シンプルに時系列で整理すると、 要求分析を行い->要件定義書作成->仕様書作成->設計書作成となるはず。 要件定義がしっかりしている場合、仕様書は必要なくなるはず。 何らかの設計作業の入力となる「作るべきものの指定」が「仕様」、それを記述した文書が「仕様書」であり、設計作業の結果を記述した文書が「設計書」であるという考え方が多くの方に違和感なく受け入れられそう。 誤解しやすい用語の解説集 ## 検証と妥当性確認 ・ 検証（verification） 『正しく構築した』ことを確実なものにすること ・ 妥当性確認(validation) 『正しいものを構築した』ことを確実なものにすること ## テスト、評価、検査 テスト：対象が、正しく動作するかどうか確認する作業のこと。 評価：対象が、要件に対してどのレベルにあるかを測る作業。測るためには、テスト結果や、他の測定結果、バグの発生状況、収束状況など、多くの情報を使用する。 検査：対象に欠陥がないかどうかを確認する作業。（工業製品の場合、個々に検査を行うまたは、抜き取り検査を行う。） ## 会議と打ち合わせの違い 会議は、全員参加で、議題があり、終了後に決定がある場 打ち合わせは、調整したり、ブレストしたり、問題解決したりする場 ## 前提条件と制約条件（事項） * 前提 ドキュメント土台。ドキュメントを読む上で共有しておかなくてはいけない認識等を書く。始める前に合意していた条件。とりあえず、システムが正常に動く状態までが前提となる。設計書では、設計するにあたり合意した条件となる。取扱説明書では、設計書の前提条件+製造過程で合意した条件となる。 * 制約 ソフトウェアの説明書などに使われている言葉。「できない事」の意。前提をおいた上で取り除けなかった禁止事項。システムが正常に動いた上で例外が発生したりする状態を記述する。設計書では、前提で絞りきれなかった（前提だけで普通はうまく動くが、特定の状態を禁止しておく必要がある条件）条件となる。取扱説明書では、製造時にどうしても取り除けなくなった禁止事項と前提だけで普通はうまく動くが、特定の状態を禁止しておく必要がある条件となる。 最終的には、禁止事項=前提+制約となる。個人的には前提はあってよいが、制約はない方がいいソフトウェアだと思う。 ## Bean,DTO,DAOとか実体を表す系の違い * Bean ・Sun Microsystems社のJavaBeans仕様に準拠した再使用可能なソフトウェア・コンポーネント。 ・最低限、クラスにはプロパティが必要。 ・プロパティはメソッドを使用する他のJavaクラスに公開される。 ・ただし、アクセス修飾子はprivateとし、次のメソッドをコールする必要がある。 set PropertyName get PropertyName ※PropertyNameは、プロパティの名前。 プロパティはBeanクラスに格納され、メソッドを介してこれらの属性を取り出し、設定する。 * DAO DB(永続ストア)にアクセスするためのクラス。 たいてい、VOを引数に受け取って、INSERT、UPDATEを行ったり、SELECTしてVOやVOのリストを返したりする。 * DTO 総称はData Transfer Object。データを転送するオブジェクト。 データは最終的にはDB処理に利用されることが前提とされている。 MVC間でやりとりされるオブジェクトは、DTOといったほうがいいらしい * Entity（エンティティ） 総称はそのままEntity。訳すなら実体。永続化可能なJavaオブジェクト。 データストレージの単位の実体。 つまり、DBのテーブル単位として扱われることが多い。 DBのテーブル単位でEntityを利用する場合、必ず主キーを所有している必要がある。 Entityの１インスタンスがDBのレコードの1行に相当する、というイメージで良いと思う。 * VO 総称はValueObject。 アジャイル開発宣言とかXP（エクストリームプログラミング）で有名なマーティン・ファウラー によると「お金」や「幅」といった小さなオブジェクトを指すらしい。 オブジェクトとしての塊というより、プロパティを基準にしたクラスとのこと。 ・値の設定はコンストラクタ（インスタンスの生成時）のみ ・セッターメソッドは実装しない ・値は不変とする * Form 総称はそのままForm。StrutsやSpringなどで多くのクラス存在する。 起源はやっぱりStrutsだろうな。 画面の入力フォームという意味合いが強い。 Beanの中にDTO,Entity,Formが含まれ、それにアクセスするのがDAOなイメージ。 ## 基準、規程、規約 基準：指針（あくまで、判断基準、目安、行動基準などのようなもの） 規定：基準をもとに手順、処理が書かれている。規約が進化したもの（規定の中で、基準を引用する） 規程：規定を具体化してより集めたもの 規約：みんなでこうしようと決めたもの ### 参考 社内では 規則 ⇒ 基本的規則（従業員が守らなければならないこと） 規定 ⇒ 個別規則の一般的なルール 規程 ⇒ 計算等の基準を含む具体的なルール みたい 大辞林では以下の定義 > 基準 > > 1. 物事を比較・判断するよりどころとなる一定の標準 \> > 規定 > > 1. 物事のありさまややり方を決まった形に定めること。また，その定め。 「 －に従う」 「概念を－する」 > 2. 法令の条文として定めること。また，その条文。 → 規程1 \> > 規程 > > 1. 特定の目的のために定められた一連の条項の全体をひとまとまりとして呼ぶ語。 \> > 規約 > > 1. 人々の協議によって決めた規則。 「 －に違反する」 > 2. 団体の内部組織に関する規定。 ## 括弧の使い分け 括弧には（「\[『〈【の種類がある * ｢｣ 短い引用 論文などのタイトル 強調 ウェブ ページ内の見出し、話題、情報 ウェブ ページを一部抜粋 * 『』 かぎ括弧の中のかぎ括弧を使う場合 強調 書籍、映画、絵画など作品の表題、題名 ウェブ ページ タイトル * （） 補足 著作物の刊行年 注記 読み仮名 文章を読みやすくしたいとき * ［］ 手順を説明する時 メールなどの件名 * 【】 見出し文囲い すごく目立たせたいときのメールの件名 * <> 注意文 強調 (タグとかぶるのであまり使わない方がよいかも) * "" 引用や強調をする * '' ""の中で入れ子になるセリフなどで使う。他は使わない。