S-JIS[2008-02-17/2019-12-08] 変更履歴

コンピューター用語

よく使われる用語というものがありますが、実はそれが何を指しているのか、人によってイメージしているものは往々にして違います。
ここでは「自分がこう思っている」というのを書いてみます。


用語はけっこう曖昧に使われる(同じ言葉でも意味しているイメージが人によって違う)ので、仕事(会社間)で言葉を使う場合は どの用語をどういう意味で使うかの用語集は必須だと思う。
「うちの会社はこういう用語をこういう意味で使います」という一覧をパッと提示できると便利だと思うが、そんなの用意している会社なんて聞いたことない。


言語使い

COBOLを使う人(COBOLでプログラムを書ける人・COBOLが好きな人)を「コボラー」と呼ぶ。[2009-01-19]
たぶんそこから派生して、Javaを使う人のことを「じゃばらー」と言う。

でもC言語C++を使う人を何と呼ぶのかは聞いた事が無い。
「しーらー」とか「しーぷらぷらー」とか言うのだろうか(爆)
しーげんがー


高級言語と低級言語

高級・低級と言うと「優れている」「劣っている」というイメージが付きまとうので、高水準言語・低水準言語と呼ぶ方が好み。

低水準言語は、マシン語(機械語)に近いコンピューター言語。
高水準言語は、コンピューターの都合をある程度隠蔽して人間に分かり易くしたコンピューター言語。

低水準言語の代表はアセンブリ言語。CPUが理解できる命令をほぼ1:1でニーモニックとして表している。
高水準言語は、BASICとかC言語とかオブジェクト指向言語とか。
C言語は高水準言語の中でも低水準な事が出来ることで有名。

高水準とは言っても、現代の技術レベルではまだまだ未熟。
コンピューター言語の究極の目標は、人間が自然言語で命令すればその意図通りに動くことかな。それもう“コンピューター言語”じゃないけど^^;
これが出来るようになれば、コーダーという仕事が無くなったように、プログラマーという仕事も無くなるだろう(仕様書だけ書けばコンピューターが働くということだから)。プログラミング好きとしては寂しい話だが、僕が生きている間には実現はしないだろうから、別にいいか(笑)


プログラミングとコーディング

自分の使い分けは、プログラミング=コーディング+単体テスト
コーディング完了とは、ソースファイルを一通り書き終わること。これならプログラムが動くはず、という状態。
プログラミング完了とは、単体テストも終わって、動作確認が終了した状態。

プログラマー(programmer)はプログラミングが出来る人。
コーダー(coder)はコーディングだけする人。
テスター(tester)はテスト(試験)をする人。

単体テストを専門に行う人はあまり聞いた事が無いけど、結合テスト以降でテストだけする人はテスターと呼ぶよね (というか、テスト担当者がテスターか)。

コーダーについては。
どこかで聞いた話では、昔(汎用機の黎明期)はコンピューター機器が非常に高価だった為、端末自体の数も少ないしコンパイルするのにも時間がかかるというので、今の様にちょっと書いてちょっとコンパイルする、というような気軽な使い方は出来なかった。
そこでプログラマーが紙にプログラムを書き、机上デバッグを念入りに行い、それをコンピューターに入力する専門の人が実際に入力した。この人がコーダー。
あるいはパンチャーとも呼ばれたようだが、これは、汎用機にプログラムを伝えるのに紙のテープに穴を開けてそれを読み込ませていた為。紙テープに穴を開ける装置は別にあったんだろうね。穴を開ける=パンチする (パンチング)という訳で、それをする人がパンチャー。
すごい人は、紙テープの穴の位置を見るだけでどういう命令が書かれているのか分かったと云う。(マシン語の数値の羅列を見てプログラムが分かる人と同義)
ちなみにカセットテープにプログラムを保存していた頃(フロッピーディスクの普及前…FDすら今ではもう廃れているが)に、カセットテープの音(プログラムを保存しているとピーガーガーという音がした)を聞いただけでバグを発見するというジョークがあった(笑)

最近ちょっと思うのは、上級プログラマーにコーディングだけやらせてテストは他人に任せる方が効率よくプログラムが作れるのではないか(大量のプログラムを一定期間内に作る)ということ。
初級プログラマーは定石や必要なライブラリーを知らなかったりするから、上級プログラマーが作る方が根本的に品質が良いはず。
(つまり「出来るプログラマー(プログラミング好き)」をシステムエンジニアにしてプログラムを作らせないのは資産(人材)の無駄じゃないか、という思い。そりゃSEも足りないんだろうけどさ)
とは言え、テストもちゃんと出来ないと品質が良いとは言えないから、ど素人にテストを任せる訳にはいかないよなぁ。
それに実際にプログラムを書かないと成長できないし。ということは、やはりペアプログラミングがいいのかなぁ。


プログラムとモジュール

分からん(爆)

「プログラム」は概ねソース単位(ソースファイル1つとまでは言わないが)だと思うけど。

特に「モジュール」っていうのはいい加減。「プログラム」もそうだけど…。
1つのプログラムを分割した個々のものを指す場合もあるし、複数のプログラムをまとめた一機能のことをモジュールと呼ぶ場合もある。
モジュールという言葉を使って会話するなら、どういう意図で使うのかちゃんと決めておかないと。

モジュールの例
CVS モジュール単位でチェックインやチェックアウトを行う。1モジュールの中で複数のファイルを管理する。 2008-03-20
ExcelのVBA 1つのブック(xlsファイル)の中に、複数のモジュール(マクロを書くシート)を入れることが出来る。 2008-03-20

フェーズ

システム開発をいくつかのフェーズ(開発工程)に分けて行う。
ウォーターフォールモデルとかスパイラルモデルとか、情報工学の中では昔から考えられている分野だけど。 日本の実際の開発現場でどれだけ意識されているだろうか。(「ウォーターフォールもどき」は浸透している気はするけど)

要件定義→基本設計→詳細設計→製造(プログラミング)→結合試験→総合試験

基本設計・詳細設計は外部設計・内部設計とも言うかも。なんか違う気もするが…

「製造フェーズ完了」と言ったら、単体試験まで終わっていることを指す(単体試験フェーズというのは聞いたことが無い)。[2010-03-10]
しかし「製造」という言葉をコーディングの意味で使う人もいる。M/UT(make+単体試験(UNIT TEST))の「make」を「製造」と訳すならば、コーディングのことを製造と呼ぶのも理解できるが。

試験(テスト)のフェーズは、これ以外の言葉・分類が使われることが非常に多い。外部結合試験とか連結試験とか。
ある部分だけ別会社に委任したりすると、その会社内で「製造→内部結合試験」、それを検証する「受け入れ試験」とか。

試験の略称も、単体試験がUT(UNIT TEST)なのはどこでも同じだと思うけど、結合試験だと何になるかなぁ?
ITとかSIとかST(SOUGOU TEST?)とかPTとかRTとか、一般に使われる略語なんだろうか。


試験の後、導入(移行・教育)→運用(保守)といったフェーズに進む。[2010-01-17]


いつも気になるのは、製造資料の事後整理を行うタイミング(フェーズ)が無いこと。[2010-01-17]

製造フェーズに入ってから設計の不備や考慮漏れが見つかることはままあるが、その際に実装に合わせてきちんと設計書を直さないといけない。
設計書を都度修正していない場合、後からでも修正しないと、いきなり設計書が陳腐化して(ソースと不整合になって)しまう。

そうでなくても、設計時や製造時に自明だった(と思われた)ので記述されなかった事、あるいは暗黙のルール(製造用の運用ルールとかノウハウとか)が作られて文書に残らない事もある。
こういった事柄は、メンテナンスを行う人と製造を行った人とが違うことも多々あるので、説明(引き継ぎ)が必要になる。
そして これら「必要な事」は、口頭で引き継ぐのではなく、文書化しておくべき。
新しいメンバーは仕様や仕組みに慣れていないので、引き継ぎ直後に理解できるとは思えない。後から前任者を呼ばなくても済むようにする為には、説明資料の文書化が必須。 (同じ人が担当しても、忘れる事があるし)
保守のコスト

こういった設計書でない文書(説明資料)は事前の設計フェーズで作ることは出来ず、作るとすれば、どうしても製造フェーズより後になる。
しかしこれが考慮されていない案件は多いのではないだろうか?

(作りっぱなしでなく)運用・保守を行っていくのであれば、少なくとも運用フェーズの最初の時期にこういった説明資料を作るべきだ。
(説明資料を作る工数を見込むべきだ)

実務的には、こういった説明資料は納品物に含めない方がやりやすい。[2010-03-10]
納品物に含めてしまうとレビューやら検収やらの対象になるし、ひとつでも間違った言葉を使えないという感じで神経質になるし、修正も承認が必要になって容易でなくなる。
(後から「もっと別の表現を使った方が分かりやすい」「説明を追加したほうがよい」と思った時や何かの変更があった際に簡単に修正できないと、分かりづらい不便なままの資料(あるいは現実と合っていない陳腐化した資料)になってしまう)
…とは言え、納品物でないものにお客さんが費用を払ってくれるかというと、それは疑問だよな(苦笑)

実際のところ、こういう納品物でないノウハウ的な資料って、誰かが作って引き継がれていると思う。
けど納品物ではない(すなわち正式な資料ではない)のでメンテナンスの義務は無い。すると、ずぼらな人が引き継ぐとメンテされなくて陳腐化しちゃう…。
という事は、修正に承認の必要が無い納品物(正式ドキュメント)とするのが理想?(爆) そんなのあるのかなぁ?^^;


設計書

フェーズ毎にアウトプット(作るもの・成果物)があって、設計段階ではストレートなので分かり易い。曰く
要件定義→要件定義書
基本設計→基本設計書
詳細設計→詳細設計書
他にプログラム設計書(仕様書)とかいう言葉もあるかも。

自分のイメージでは、各設計書の位置づけは以下のような感じ。

設計書 書くべき内容 対応する試験 更新日
要件定義書 そのシステムでやりたい事(実現したい事)、クリアすべき条件(例えば「通信完了8秒以内」とか)を書く。
実現方法「どうやって実現するか」「何を使うか」については書かない。もちろん、それがクリアすべき条件に入っているなら書くべきだが。(例えばOSの種類とか)
総合試験  
基本設計書 要件定義に書かれた要求を実現する方法を書く。
特にどういうプログラムがどういう風に連携するかといった、全体協調的な視点が必要。
(画面遷移やジョブフロー・データフロー)
結合試験 2010-03-10
詳細設計書 基本設計で挙がった個々のプログラムが具体的にどういう処理をするのかを書く。
(入力と出力と加工方法。それを具体的にどう実現するかまでは書かなくてもいいと思う
が、PG設計書を書かない昨今では、補足的に実現方法を書くのもありだと思う)
単体試験(ブラックボックス) 2008-03-20
プログラム設計書 詳細設計に対し具体的にどうコーディングするか(コーディング内容)を書く。
これはコーダーがコーディングする為のもの。したがって、今はこれは書かない事が多い。
(そもそもエディターが発達した為、紙に考えながら書くよりも直接プログラミングする方が確実)
単体試験(ホワイトボックス)  
補足:詳細設計書において「実現方法を書かない」という意味 [2009-11-07]
詳細設計書に「具体的な実現方法を書かない」というのは、「SQL文そのもの」や「ここはHashMapクラスを使う」とかいうレベルのことは書かない、という事。
DBアクセスなら、取得条件や取得項目(や更新条件・更新項目)が書かれているのが詳細設計書で、SQL文そのものはプログラム設計書でしょう。
Mapを使うのも、キーワードで保持しておいて値を取得したいからのはずで、詳細設計書にはそのことを書く。プログラム設計レベルでどのアルゴリズム(オブジェクト)を使うのが効率よいのか考える。

試験は、設計書に書かれている内容が実現されているかを確認する為に行う。
だから「試験項目は設計書から起こす」と言われる。


設計書にはデータの取得方法やら加工方法(計算方法)やらを当然具体的に書かなければならないが、なぜそれが必要なのか・なぜそういう計算式なのか、その理由や目的も書くべき[2008-03-20]

「データ」や「加工」に関しては、それが書かれていないと それを実現する(コーディングする)ことが出来ないのだから、当たり前。

「理由」が必要なのは、将来その処理を見たときに、何をしたいのか分からなくなることが非常に多い為。
例えば何か障害が起きたとき。
どういう処理をしているのかは、ソースを見れば分かる(見ても分からないようなソースというのは、別の問題)。
設計書にソースの計算式と同じことしか書いていなければ、ソースが設計書通りに作られていることは分かっても、その仕様が正しいのかどうかまでは分からない。
その処理が正しいのかどうかを判断する為には、「理由」や「目的」が書かれていないと。

ソースを将来修正する際にも、「理由」や「目的」が分かる方がやりやすい。
理由や目的の内容が変わることによって「不要な処理になったので廃止」できたり、逆に「やはり変更できない」と判断できたりする。
これが分からないと、お約束(盲目)的に「なんでか分からないけど同じように書いておけばいいや」になってしまう。こうしてメンテできないシステムになってゆく。

ちなみに、これらの「理由」の中には、別の文書を参照すれば済む、というものも多い。
そういったときにはその文書名(や章番号)を書いておけばよい。が、それを見たいときに探し出すのはちょっと面倒。HTMLのようにリンクを張れると便利だよね。
という訳で、設計書は(WordやExcelを使うのをやめて)HTMLで書いてしまうのがいいと思う
この文章だってHTMLエディターで書いてて不便は無いし、みんなネットサーフィンしているから見るのも慣れていると思う。
ローカルネットワーク上にウェブサーバー立てて置いておけば使い易いと思うんだけどなー。
でも、そんな主張は自分以外聞いたことない(爆)
Excelは表として正しく使えば、HTMLより当然便利だけど。


DB設計(テーブルレイアウト・ER図)を基本設計と詳細設計のどちらで書くのか、いつも悩む。
理屈から言えば基本設計で論理ER、詳細設計で物理ERじゃないかと思うんだけど。
ER図を描くツールなんかだと、論理ERは日本語で項目を書き、物理ERはそれに属性とか入れるだけじゃん。物理名の決定なんかは後でもいいんだけど、必要な項目の有無ってのはいつ考える?詳細までいかないと分からないと思うんだけど。
設計書は各フェーズで完了するのが建前なので、論理ERを基本設計で完了したら、詳細設計で論理ERを修正するのはおかしいんだよね。
基本設計書で連携方法を書くということは、テーブルをどう使うかも基本設計で決めるということか?でも個々の値の使い方まで考えないような…。
DBでなくファイルであれば、具体的なレイアウト決定は詳細設計だよな。ということは、DBで変にツールなんか使おうとするから間違いなのかも?(爆)
あぁでも、外部インターフェースなら早めに具体化しないといけないし…。どうも条件が錯綜して整理しきれない。

個々のプログラムに関するプログラム設計書は書かない(実際にプログラミングしながら試行錯誤する方が簡単確実)が、具体的なクラス名・関数名の一覧とかは必要かな。
(特に、後から「設計書のこのプログラムは具体的にはどのソースファイル?」というのを調べる為に。
 長年そのシステムを担当してきた人ならともかく、新しく来た人がプログラムを具体的に知る為に必要不可欠)


エラーとバグと障害

本来の処理目的(提供すべきサービス)が正常処理だとすると、それが出来ない状態が「異常」。
エラーは、発生することが予測される異常。この異常が起きたときにどう処理するかは設計書に「エラー処理」として明記する
バグは、予測できない異常(想定外の異常)。したがって「バグ処理」という言葉は無く、設計書にその処理を書くことは出来ない。(書けるのなら、それはバグではなくエラーでしょ)

例えば通信を行うプログラムであれば、当然通信が途中で遮断されることが予想される。そうなったらどうするか、というのがエラー処理(「3回は再試行して、ダメだったらプログラムを終了させる」とか)。

したがってエラー処理も正当なプログラムの一部。
なので試験対象にエラー処理も含まれるし、エラー処理の中にバグが潜んでいる可能性もある。

試験はバグ(bug)を取り除くのが目的で、だから「デバッグ」(de-bug)と言う。
完成したプログラムには バグは無い(はずである)が、エラー処理は当然残っている。

ちなみにエラーのことを異常と呼ぶこともある。
試験項目は「正常系」と「異常系」に分類したりするし。

障害(トラブル)は、正常処理が出来なくなる事が実際に起きた状態。あくまで起きた“事象”を指すのであり、“原因”を指すのではない。
エラーメッセージが出たりプログラムが異常終了したりすると、エラー処理が行われたと分かる(←分かり易い障害)。
それとは別に意図した結果が得られない場合は原因としてバグが疑われる(エラーの発生した原因がバグかもしれない)。

なお、プログラムとしては設計書どおりの動作であっても、ユーザー(使う人)から見て変な動作は「仕様バグ」と呼ぶ。 (というか、仕様が間違っているという意味)
「それは仕様です」という言い訳は、プログラマーから設計者に対して「あんたが設計したんだろ。こっちは設計書(仕様)通りに作ったんだ」と言えても、設計者がユーザーに対して強く言えることじゃない。あ、自分の耳に痛い(爆)


保守(メンテナンス)

保守(メンテナンス)とは、作ったプログラムを修正(改良改善、あるいは仕様変更)していくこと。[2008-03-20]
そして保守という観点にこそ、趣味と仕事のプログラムの違いがある。

よく「動けばいい」と言う人がいるが、それでいいのは趣味のプログラム
仕事(業務)のプログラムは、「動くのは当たり前」(動かないものが納品できるかっつーの。「しかし開発時間が足りなくて」云々…というのは、別の話題)
保守し易いように(ソースを理解し易いように)作るのが仕事のプログラムというもの。(趣味が高じている人は、理解し易い美しいソースを書くだろうけどね(笑))

プログラム(ソース)は、基本的に(ユーザーからは)見えないもの。
そこをどれだけ美しく作るかこだわるのがプロ。(というかマニア?(爆))
仕事のプログラムでは、技巧を凝らして技術力の高さをアピールするなんてのに意味は無い。(それに意味があるのは技術力コンテストくらい?)

仕事のプログラムで一番重視しなければならないのは、メンテナンスする必要がある、ということ
そのメンテをするのは未来の自分かもしれないし、別の担当者かもしれない。
自分が作ったプログラムでも時間が経ってから見れば訳分からん、まして他人のプログラムなんてさっぱり分からん、てな事になりがち。
(他人に任せて逃げる…っていうのは楽かもしれないけど(笑)、責任感のある人間のすることじゃないよな。逆に、自分が任される側だったら…!)
そうならない為にコーディング規約等が定められている。それが守られていれば、誰が作っても同じルールに則っているので例外が無く、(統一感があり、)理解し易い。(理屈上は、ね^^;)
(だから自分のスタイルに合わないからといって、勝手なコーディングをしてはいけない)
(そして変な規約であっても、規約である以上、それを守るという事には上述の様にそれなりの意味がある。まぁ規約を直せと言いたいが

また、多少の実行効率アップを目指して複雑なロジックを作るよりも、多少実行効率が落ちても誰が見ても分かり易いロジックの方が確実に重要。
ロジックが理解できないのでは、メンテすることなんて出来ないのだから。

「新しい技術を知らしめるべく、他の人が使わないようなロジックを組む」という人もいるが…一理あるよなぁ。
でも珍しい関数を使う程度ならともかく、複雑なロジックは、やはり避けるべきだと思う。それを書くなら、ロジックの解説書(あるいはプログラム設計書への記述)が必要だな。

ちなみに世間には、ソースに自分の名前を署名するのが好きな人と嫌いな人の二種類がいる模様。
プログラミングの自信の差かなぁ?


コスト

コストは、直訳だと「費用」?[2009-03-03]

プログラミングにおいては「労力」と言った方がしっくりくるかも。
あるいは設計者・製造者の人数・稼動時間。これは工数、正に費用(お金)。

実行時ではリソースの使用量の多さを指す。

「コストが高い」とは
フェーズ 内容 備考
設計 仕様が複雑・膨大。
仕様変更の影響範囲が広い・深い。
労力 仕様が分かりにくくなる事により、製造のコストが増える。
また、仕様変更時や保守のコストが増える。
設計に時間がかかる。 費用
製造
プログラミング
製造量(ステップ数)が多い。
ロジックが複雑・意味不明。
テスト量が多い。
労力 ロジックが複雑になるほど、信頼性の確保が難しくなってくる。
(信頼性を担保する為にテストするわけだが、それが大変になる)
製造に時間がかかる。 費用
実行時 メモリー使用量・ディスク使用量が多い。
リソース(CPU・ディスクアクセス・ネットワーク帯域(転送量))の使用率・占有率・負荷が高い。
実行速度が遅い。
 
保守 ドキュメント不足で仕様が理解不能。
コメント不足でソースが解読不能。
ソース(ロジック)が難解・複雑怪奇・スパゲッティー。
理解できない仕様・ロジックはバグの元となり、
バグはコスト(修正費用の増加・信頼度の低下)となって跳ね返ってくる。

設計やプログラミングにおいては、その時に「自明」と思っている事項は書かれない(ドキュメント化されない・省略されてしまう)ことが多い。
しかしそういう事柄が後々分からなくなってくる(後任者に伝わらない、あるいは自分でも忘れる)。
こうして保守のコストが高くなっていく。 (何か変更しようとする度に現状がどうなっているのか調査し直したり理解し直したりしないといけなくなり、挙句に勘違いして間違ったりする)

後に残しておくようなドキュメントを作る作業というのは、けっこう労力(コスト)がかかる。
Javadocコメントのようなソースの説明書を作ろうとしたら、それだけでも結構な時間が必要)
作業時間が足りなくなってくると、往々にしてこの部分が削られる。(「動けばいい」という考えに陥りがち)
納品には間に合っても、後の保守コストは高くなる。

保守のコストを下げる為には、理解している内に説明ドキュメントを作るのが良い。
設計書・ソースに事前に盛り込めれば一番良いが、作ってみなければ分からない事というのも有る。
こういったドキュメントを作成するコストを盛り込むかどうかで、保守のコストが変わってくる。
目先のコストしか見ないと、このコストは無駄に見えるかもしれないが、同じ内容でも後から調べる方がコストが高い(仕様や経緯を知っている人がいないかもしれないし、調べて分かるかどうか・勘違いしないかどうかも怪しくなってくる)。


ヌルとナル

自分はnullを「ヌル」と読む。[2008-02-19]
なぜなら、そう教わった(書いてあった)から。三つ子の魂百まで!

英語の発音としては「ナル」の方が近いらしい。
でも現在の日本では「ヌル」と呼ぶ人の方が多いと思うので、僕は「nullの日本語訳はヌル」でいいと思う。
英語圏の人と会話するときは、日本語の「ヌル」でなく英語の「null」を使ってくれ。

もし周りの人間がみんな「ナル」と言うようになって「ヌル」で通じなくなったら、僕も「ナル」と呼ぶようになるだろう。

基本的には英語(原語)の発音に合わせる(近づける)べきだと思うが、違う読み方でも(単語をローマ字風に読めばそう読めてしまうのだし)広まってしまったものは「日本語訳」として受け入れればいいと思う。
結局、所詮は自然言語なので、コンピューター言語のように奇麗に統一することは無理。

英単語 ひしだま流 原語に近い? その他読み 備考 更新日
null ヌル ナル      
halt ハルト ホールト     2010-01-31
warning ワーニング ウォーニング   warningは「wa」を「わ」と読んだが
falseは「fa」なのに「ふぉ」だなぁ。
 
false フォールス     2010-01-27
comma カンマ カマ、コマ コンマ カンマとコンマは同じイメージだけど
コラムは新聞や雑誌の欄のような。
2010-03-10
column カラム カラム、コラム   2010-03-10
comparator コンペアレーター コンパレイター     2010-03-14
char キャラ   キャラクター
チャー
  2010-01-17
int イントゥ(伸ばさない)
イント
  インテジャー   2010-01-17
signature シグニチャー シグナチャー
シグナチャ
シグネチャー
シグネーチャー
しぐねーちゃん
  2010-01-17
URI ユーアールアイ   ウリィィィ!   2010-02-01

メモリーとメモリ

memoryを日本語で記述する場合に「メモリー」と書くか「メモリ」と書くか。(長音符号の有無)
errorやfreeの場合は「エラー」「フリー」を「エラ」「フリ」とは書かないので、日本語で3文字以上になるときに伸ばすかどうかのルールだと思われる。

自分は基本的に「メモリー」派。
工学系の教科書(というか書物)では「メモリ」、理学系は「メモリー」だと聞いた事がある(真偽は知らない)が、自分は工学系だけど違うなぁ^^;

英語の発音が[memri]なら「メモリ」と書くのがいいと思う。[memri:]なら「メモリー」。と思って辞書を引いてみたら、[memri(:)]だと!?(爆)
でも例えばpragmaは「プラグマ」であって「プラグマー」じゃないよね。
もしpragmerなんて単語があったら、それは「プラグマ」じゃなくて「プラグマー」だと思う。

逆の見方をすると、長音符号を付けない場合、日本語から元の単語が類推できない。
(pragmaを知らない人が「プラグマ」という語を見たとき、英単語の綴りをどう思うだろうか?まぁ英単語に戻すにはLとRの問題や語尾のer・ar・orの問題等もあって、なかなか難しいけど
また、intの発音を日本語で「イントゥ」と表記したら、長音記号省略派の人にはintoの発音「イントゥー」と間違われそう。
ちなみに僕は「~」をずっと「ティルダー」(むしろ「ティルダ〜」!?)だと思ってた(汗)んだけど、実は「tilde」なので「ティルド」が正しいようだ。 「ティルダ」と書かれているのを見て、「(長音記号が省略されていて)伸ばすものだ」と思ってしまったのが敗因か。
日本の平仮名や片仮名が表音文字なのが混乱の元なのか? 英語なら、単語と発音は(少々)無関係だもんなー。
というかやっぱり、片仮名が音も表しているのに、その一部である「ー」を省略するからいけないんだよ。

また、「メモリー」と発音すれば他に誤解する単語は無いと思うけど、「メモリ」だと「目盛」と区別がつかない。
メモリーの話をしている最中に「目盛が」と聞こえたら、分かっていてもすごく違和感がある(苦笑)

さらに、「ー」を入れないと妙な漢字変換になってしまう単語も多い。
(入れなくてもちゃんと変換される単語も多い。最近の辞書は優秀ね(笑)

とか言いつつ、僕もどちらも使うけど(爆) 特に文字数が長い時は長音記号を付けない傾向があるかな。
でも設計書とかの正式文書を書くときは、どちらでもいいから統一すべきでしょうね。

ひしだま主観 英単語 長音表記 省略 同音異義語 備考 更新日
長音を使う memory メモリー メモリ 目盛    
member メンバー メンバ 面罵   2008-09-13
center センター センタ      
user ユーザー ユーザ      
server サーバー サーバ      
header ヘッダー ヘッダ      
footer フッター フッタ 振った    
master マスター マスタ     2008-11-15
technology テクノロジー テクノロジ テクノロ時    
operator オペレーター オペレータ      
iterator イテレーター イテレータ      
converter コンバーター コンバータ      
creator クリエイター クリエイタ     2009-11-07
driver ドライバー ドライバ      
party パーティー パーティ      
editor エディター エディタ     2008-05-17
filter フィルター フィルタ     2008-11-15
短いと変でしょ? floppy フロッピー フロッピ      
energy エネルギー エネルギ     2013-09-26
partner パートナー パートナ     2012-04-23
player プレイヤー プレイヤ プレイ屋・プレ嫌    
preview プレビュー プレビュ     2009-11-07
vector ベクター ベクタ      
policy ポリシー ポリシ ポリ氏    
super スーパー スーパ      
reader リーダー リーダ      
writer ライター ライタ 雷太    
setter セッター セッタ 競った・雪駄    
getter ゲッター ゲッタ      
over オーバー オーバ 大場・大庭    
answer アンサー アンサ 餡さ   2009-09-24
water ウォーター ウォータ   FFの呪文じゃねーか  
  コーヒー コーヒ     2019-12-08
  サッカー サッカ     2019-12-08
runner ランナー ランナ     2014-02-09
  ルーラー ルーラ   ドラクエの呪文  
  ローラー ローラ   人名?  
状況(気分)によって
どっちも使う^^;
adapter アダプター アダプタ      
assembler アセンブラー アセンブラ      
binary バイナリー バイナリ   「バイナリファイル」なら伸ばさない  
browser ブラウザー ブラウザ     2010-01-17
constructor コンストラクター コンストラクタ コンストラク田    
compiler コンパイラー コンパイラ      
computer コンピューター コンピュータ コンピュー太    
debugger デバッガー デバッガ      
destructor デストラクター デストラクタ デストラク田    
directory ディレクトリー ディレクトリ ディレク取り 「国盗り」みたいなもの?(違)  
entity エンティティー エンティティ      
finalizer ファイナライザー ファイナライザ Φなら いざ ←んな訳ねー(爆)  
folder フォルダー フォルダ フォル打    
generater ジェネレーター ジェネレータ      
interpreter インタープリター インタープリタ インタープリ太    
library ライブラリー ライブラリ      
manager マネージャー マネージャ 真似じゃ    
parameter パラメーター パラメータ      
printer プリンター プリンタ プリン太    
procedure プロシージャー プロシージャ      
processer プロセッサー プロセッサ      
programmer プログラマー プログラマ プログラ魔    
proxy プロキシー プロキシ プロ棋士    
security セキュリティー セキュリティ      
単独なら長音
複合なら省略
primary プライマリー プライマリ プライ鞠 プライマリキー  
省略する
(伸ばさない)
buffer バッファー バッファ   bufと略して書くことも多いし  
clear クリアー クリア     2009-09-26
container コンテナー コンテナ     2008-10-25
data データー データ   伸ばすのは誤り 2008-05-17
engineer エンジニアー エンジニア      
pragma   プラグマ     2008-12-07
secure セキュアー セキュア      
semaphore セマフォー セマフォ      

どちらを使うかは、文章中の使われ方と、結局は慣れ・習慣(どちらをよく見かけるか)の問題か。

しかし今後同様のパターンで新しい単語が出てきた場合、なるべく元の発音に近づける=伸ばすべきだと思うんだよな〜。
英語の発音に近い音を表す記号があれば問題にならないのに。例えば「△」を使って「メモリ△」とか(爆)
しかし長音記号を省略することによって「文字数が減る」という利点を見い出す人にとっては無意味か。

いずれにしても、法則性を見出してそれに則って整然としたプログラムを作りたいと思うのがプログラマーやエンジニアの性というもの。
でも「どっちの方が規則的・合理的か」という感覚は人それぞれだから収拾がつかないんだよね^^;
(ルール化した場合の例外が少ない/曖昧さを回避できるのは、長音記号を付ける方だと思うが)


デバッグとデバック

たまにデバッグの事を「デバック」と書く人がいて、非常に気になる。

何でそんな間違いするんだろう?バグ(bug:虫)をバクと呼んでるわけじゃあるまいに。バグ取り→debug
「デバック」するような人にはプログラムを書かせたくないなぁ。きっと(つづりを間違うから)「デバッグレベルのログ出力」が書けないし、変数名の命名とか変だよね。…これは他人のこと言えないけど(爆)

英単語 日本語 日本誤 備考 更新日
debug デバッグ デバック    
batch バッチ バッジ バッチ処理、バッチファイル  
dead lock デッドロック デットロック   2009-01-19
data データ データー 「データー」は誤り(発音記号から見ると「ダータ」はアリのようだけど…許せる?) 2008-05-17
simulation シミュレーション シュミレーション シュミレーション→趣味RATION→趣味の糧食  
exec エグゼク
エグゼグ
アクセス autoexecを「オートアクセス」なんて読んでいたのは、きっと自分だけ(爆)
中学時代はまだ英語なんてほとんど知らなかったし…(言い訳)
2008-02-24
locale ロカール ロケール つい「ロケール」って読んじゃうけど、違うらしいんだよなー。
「locate」は「ロケート」(英語に近いのは「ロウケイト」)のくせに。

最近では公式サイトでも「ロケール」と書いている例が増えてきたが。[2013-09-27]
2008-02-24
method メソッド メッソド これはローマ字変換の誤りだと思われる。
メソッド「mesoddo」、メッソド「messodo」。
急ぐと二重にすべき文字を間違えそう。
(もしくは、発音は「メ」の方が強いということを強調しているのだろうか)
2008-04-30
big ビッグ ビック “ビックカメラ”の様に、固有名詞では「ビック」も有り得るけれども。 2009-02-19
bed ベッド ベット bet…賭け 2009-11-07
  すみません すいません 吸いません 2009-03-24

こんだけ偉そうに言っておいて、実は「デバック」という単語に別の意味があったりしたら大恥だ(汗)
あるいは「g」と書いて[k]と読むことも有り得るからなぁ。(辞書によれば、debugの発音は[k]じゃないみたいだけど)

Googleで「デバック」や「バッジファイル」で検索すると「デバッグ」「バッチファイル」が出てくるってことは、「“間違ってる”と思っている人が 他にも居る」ってことだよね。


ひきすうといんすう

すみません、最初(中学生の頃)は「引数」を「いんすう」と読んでました。[2008-02-21]
でも「ひきすう」より「いんすう」の方が格好いいような気が…今では慣れたから「ひきすう」で/が良いけど。

英単語 漢字 読み 誤読 備考 更新日
argument 引数 ひきすう いんすう    
  添字 そえじ てんじ    
function 関数 かんすう せきすう ←嘘です。ネタでも「せきすう」なんて読み方聞いた事ない(爆)  
  凡例 はんれい ぼんれい    
  既出 きしゅつ がいしゅつ   2013-09-29
true しん 真偽値(しんぎち)/boolean(ブーリアン)の値。 2010-01-27
false にせ 2010-01-27

暗号と復号

普通に読める文章を平文(ひらぶん)、他の人に読めなくした文章を暗号文(暗号)と呼ぶ。[2013-09-27]
平文を暗号文に変換することを暗号化、逆に暗号文を平文に戻すことを復号と呼ぶ。

いわば「暗号」は名詞であり、「復号」は動詞である。
言葉としての対応付けは、平文⇔暗号、暗号化⇔復号(暗号化する⇔復号する)となる。

つまり、「復号化」という言葉は誤りである。

誤りではあるのだが、自分はついつい復号化という言葉を使ってしまう^^;
やはり「暗号化」に対して「復号」より「復号化」の方が文字数とか見た目が似ていて対応がとれる気がするし。
JavaのAES暗号について書いた頃はまだ「復号化が誤り」とは知らなかった気がするが、知った後も「復号化」という言葉を使っているのは、そういう理由。

ただ、「複合化」は誤りだと声高に言うぞw


単位B・b、接頭辞K・k

コンピューターで使われる単位について。[2008-04-13]

コンピューターで一番最小のデータ量を表す単位がビット(bit。単位を一文字で表す場合は小文字の「b」が使われる。
(量子コンピューターでもbitと言うらしいが、意味するデータはだいぶ異なる模様)

また、何ビットかをまとめたバイト(byteという単位がよく使われる。単位を一文字で表す場合は大文字の「B」が使われる。
現在では1バイトと言えば8ビットだと思って間違いないが、歴史的には機種によって7ビットとか9ビットとかの様々なビット数を1バイトと呼んでいたらしい。
厳密に8ビットを表すのがオクテット(octet。今でも通信系ではオクテットという単位をよく見かける。
ついでに4ビットのことはニブル(nibbleと言うらしい。

ワード(wordという単位も使われることがある。Windowsなら、間違いなく2バイトが1ワード。
ダブルワード(DWORD)は4バイト。

「bps」と言ったら「ビットパーセコンド」、もうちょっと日本風に言うと「ビット毎秒(まいびょう)」、要するに「1秒間当たりのビット数」。
大文字でBと書くとバイトと受け取られてもしょうがないと思うのだが、あまり意識せずに大文字で書いている例も見受けられる。
(時速○kmの場合、単位は「km/h(キロメートル毎時(まいじ))」と書く(つまり「/(スラッシュ)」を使う)のだが、bpsの場合は何故かスラッシュを使わずに「p」を書く)


国際単位系(SI)では、単位の前に付ける接頭語(SI接頭辞)を定義している。国際度量衡総会にて1960年に定められたのだそうだ。
キロ(k)が1000倍(103)、メガ(M)が100万倍(106)、というやつ。
この場合、キロを表す「k」は必ず小文字、メガを表す「M」は必ず大文字決められている
1kB(1キロバイト)=1000B(1000バイト)

一方、コンピューターでは二進数との親和性から、1024倍(210)に置き換えて使うことも多い。
この場合はキロでも慣例的に「K」と大文字で書く。(国際単位系では 大文字のKは絶対温度を表す単位「ケルビン」であり、接頭辞になることはありえない)
1KB(1キロバイト)=1024B(1024バイト)

このkとKの使い分けもしていない人が多い(商売上の詐欺的表記として、あえてしていないと思われる例もある)。

で、この曖昧な状況を改めるべく(?)、IEC(国際電気標準会議)規格として二進接頭辞というものが比較的新しい1998年に定められたらしい。
SI接頭辞で使われる文字を大文字にして後ろに小文字の「i」を付加したもの。読み方もちょっと変わる。
すなわちキビ(Ki:1024・210)、メビ(Mi:220)といった具合。
1KiB(1キビバイト)=1024B(1024バイト)

ルールははっきりしているので覚え易いが…これを使っている人 見たこと無い(爆)


エンディアン

ビッグエンディアンとリトルエンディアンの二種類あることは知っているが、どっちがどっちだかすぐ忘れる(爆)[2008-12-07]
複数バイトにまたがる整数データをメモリー上に格納する際に、「エンド」が大きい側(ビッグ)にあるか小さい側(リトル)にあるかの違いなのだが。

  ビッグエンディアン リトルエンディアン
CPU MC68000 Z80 x86
エンディアン 最下位ビット(エンド)が最上位アドレス(ビッグ) 最下位ビット(エンド)が最下位アドレス(リトル)
  最下位アドレス←→最上位アドレス
00 01 02 03
最下位アドレス←→最上位アドレス
00 01 02 03
0x12345678 12 34 56 78 78 56 34 12
0xabcd ab cd cd ab
0x0000abcd 00 00 ab cd cd ab 00 00
データの並び順 人間が見て分かり易い順に並ぶ。 コンピューターが計算しやすい順に並ぶ。
先頭アドレス 同一データを2バイト整数/4バイト整数として扱う場合は
先頭アドレスが異なる。
同一データを2バイト整数/4バイト整数として扱う場合でも
先頭アドレスは同じ。
通信 TCP/IPの標準。  

例えば2バイト(16ビット)の0x1234(十六進数)を二進数で表すと0001_0010_0011_0100となる。
このとき、各ビットをbit0〜bit15で番号付けるのだが、一番左をbit0とするのか一番右をbit0とするのかが、エンディアンによって異なる。

0x1234  0001_0010_0011_0100
ビッグエンディアン  0       7 8       15
リトルエンディアン 15       8 7       0

CPU(アセンブリ言語)のビットテスト(あるいはセット)命令のニーモニックでは、エンディアンに応じたビット番号を指定するはず。
しかし高水準言語においてはそんな命令は無いので、ビット演算子を使うだろう。
C言語(C++・Java・C#)で「ビットn」を操作する場合、リトルエンディアン方式の番号付けなら以下のようにコーディングできる。

data |= 1 << n;
data &= ~(1 << n);
if ((data & (1 << n)) != 0) {
	// フラグが立っている
}

ビッグエンディアン方式の数え方だと、データ全体のビット数を把握した上で、変換する必要がある。

int m = (16 - 1) - n;	//全体が16ビットの場合
data |= 1 << m;

プログラム言語比較へ戻る / 技術メモへ戻る
メールの送信先:ひしだま