日付け [雑談]
Boolean [雑談]
if (AnyFunction() == TRUE) {
// 成功した場合の処理
}なんて記述してしまうと面倒なことになりかねない。論理値を扱えるならこんなことはない（false でなければ true しかない）のだけれど、昔のイヤな経験がトラウマになっているのか、今ひとつしっくりこない感じがある。
※ FALSE を「ファルス」と発音するエンジニアは、それだけで信用したくない。
VB.NET [雑談]
.NET Framework に関わる作業を生業としていると、Visual Basic (VB.NET) の評価の低さが気になることが多い。
Visual BASIC という名前の通り、初心者にでも扱える言語ではあるけれど、.NET Framework の環境で動作するものはオブジェクト指向を実践するための能力を備えていると思える。ただし、過去のバージョンのしがらみのせいか、いくつかの抜け道が用意されており、純粋なオブジェクト指向に徹しきれていないところが避けられてしまう要因なのではないかと思う。
逆に、C# は扱いやすくなった Java として認知されていることが、多くの .NET ファンが公開するコードの多くは C# で記述されていることからも感じられる。
Visual Basic と C# は、.NET Framework のバージョンアップに追従するフラグシップ的な存在している。そのため、どちらか一方だけに提供されている機能というのは（皆無ではないが）多くはない。C# のほうが最適化されたコードを吐くということを聞いたことがあるけれど、どの程度の違いが出るのか私自身は検証したことがない。
C# にあって Visual Basic にない機能と言えば、最初に思いつくのが unsafe。C/C++ のような、割とコアな作業をすることを得意とする言語から派生しているだけに、アセンブラ言語の優位性を求めるプログラマーのために盛り込んだような仕様。Java がポインターという概念を捨ててしまったのとは対照的に、C# では、それを使いたいと思うユーザーに機能を提供している。
Visual Basic には、元々ポインターなどという概念は存在しないために unsafe のような機能も存在しない。
逆に、Visual Basic にあって C# にない機能を言えば、、、XML リテラル、、、これは、私がそう思っているだけで反対意見をもつ人も多いかもしれない。ただ、その実装を見たときに「苦労して Basic にまったく関係ないものを取り込んでしまうなんて、おまえらバカだろう」と思ったことも確かではある。使い込んでいくいうちに、「バカ」というのは（プログラマーにとっての）最大の褒め言葉なんじゃないこともも思えてきた。
もうひとつは C# でいうところの dynamic 型。最近になって C# で遅延バインディングを（簡単に）実践するための機能として追加された機能ではあるけど、Visual Basic では標準機能としてずっと存在している機能。型が不明確になってしまうというデメリットはあるものの、新しい仕様として C# に取り込まれたということは、遅延バインディングのメリットが認知された結果なのではないだろうか。
Visual Basic という言語は C# ほど記号を多用しない。そのため、コードサイズが膨れ上がる傾向がある。その上、自由構文ではないために、行末に無意味に見える継続行のマークが散乱し、その意味を知らない人たちにとってはゴミにしか見えないコードになってしまうことも少なくないようだ。
Visual Basic では（この点を考慮してかどうかは知らないけど）、コードの自動生成機能が多く用意されている。スニペットのように、その存在を知っていて利用するものではなく、インテリセンスと自動補完によって提供される機能は、Visual Basic 特有のものではなく C# でも利用できるのだけれど、元々のコーディング量が多くなりがちな Visual Basic では、より効果が見えやすくなっているように思う。
C# に比べると Visual Basic の癖は結構強いものがあるとは思う。それでも、好き嫌いせずにてを出してみたら、意外にはまってしまうところがおおいと考えますが、いかがでしょう。
ちなみに、私は VB.NET より前の Visual Basic については殆ど触れたことがありません。
単位 [雑談]
TByte、GByte、MByte、KByte... これは情報量を表す単位。1 Byte = 8 bit というのが一般的だということで使われるようになった単位ではあるけど、実はこの前提が「絶対」ではない世界も存在する。なので、本来であれば bit を使った呼び方をした方が正確ではあるのだろうけど、ネットワークの転送速度以外にはあまり使われることもない。
単位換算という事を小学校の低学年あたりで習うようになり、結構イヤな思いをした経験があるのだけれど、生業としてコンピューターと付き合うようになり昔の悪夢を思い出すことがしばしば。
小学校の授業では、長さの単位としてのメートル (m)、重さの単位としてのグラム (g)くらいはまだいい、時間の単位としての秒 (sec)、分 (min)、時間 (hour)が出てきて、更には面積や体積が出てくるあたりでパニックになる。さすがに今ではパニックってことはないのだけれど単位換算というのトラウマになっている人も多いみたい。
プログラマが日常的に遭遇する単位といえば、情報量を表すビット (bit) あるいはバイト (Byte)、時間を表す秒 (sec)、そしていきなり畑違いの感のある周波数 (Hz)ではないだろうか。
情報量というのもなかなか馴染みのない表現だとは思うけど、意外にそれに戸惑う人は多くはない感じ。全く異なる概念である長さや重さと同一視しているような感じだけど、話が通じなくなるようなこともないので、技術の話をするとき以外には違和感を無視することで対処できる。
時間の単位。普段、生活をしているときに感じられる時間の単位と言えば、オリンピック中継の中で出てくるような 1/100 秒がせいぜい。それより細かい単位なんて気にする必要は全くないと言っても過言じゃないだろう。そして、自分の感覚では認識できないような単位で物事を考えなければならない人種、プログラマーは 1/1000 秒、1/1000000 秒という単位を相手にする（事もある!!決して常にじゃない!!）。ミリ秒とかマイクロ秒といった単位でヒトにはなかなか認識できない時間ではあるのだけれど、パソコンレベルのコンピューターであってもそれはほぼ永遠と思えるような長さの時間だったりする。
周波数。パソコンに載っているプロセッサによって若干の違いはあるのだけれど、動作クロックが 3GHz 程度なら普通に入手可能なレベル。周波数というのは 1 秒間の振幅の数といいったところだけど、最近のプロセッサは、この振幅 1 回の時間で簡単な演算であればできてしまう。光の速度というのを覚えているだろうか？光は 1 秒間で地球を 7 周半回れる。およそ300,000 km/ｓec とすると計算がしやすい。先ほどの 3GHz と合わせて 1 クロック（振幅 1 回分）で光がどの程度進める時間なのか計算してみると面白い。
距離 = 300,000 km / 3G
= 300,000,000 m / 3,000,000,000
= 0.1m
これは、一般家庭にあるようなパソコンでも、光が 10 cm 進む時間で計算ができてしまうという事を言っている。それこそアッという間...というか声にもならないような時間。多少余裕をみても相当な計算力（ただし整数の、加算、減算、乗算に限る）と考えることができる。実際にはプロセッサの動作を阻害する要因が多いためこのような結果は「理論値」ということになってしまうのだけど、阻害要因さえなくなれば実現が可能かと思うとちょっとワクワクする。
ここ数日、マイコンを弄っているのだけど、それ（ちょっと古めのプロセッサ）はパソコンとは比べ物にならないほど性能は低い。それでも、ヒトの認識できるレベルからすると超高速と思える演算性能を発揮してくれる。
パソコンがこんなに高クロックで動作する割りに、モッサリ感がぬぐえないのは...。
コメント [雑談]
前回に引き続きコメントのお話。
私は基本的にコードにコメントを付けない人。コーディング規約等で 「メソッドには XML ドキュメントを付ける」という縛りがなければ、きっと一言も書かないんじゃないかと思う。
逆に、ステートメントごとにコメントつける主義の人もいないことはない。「自分とは話が合わなそうだなぁ」とコードを見るたび（レビュー等で見せられることがあるから）に思う。
割りと多いのが、（if とか、for とかの）ブロックごとにコメントを付けていくタイプ。
Readable Code ではないけど、コードを読むより正確に処理（考え方？）を記述しているコメントであれば良いけど、、、コメントに目を奪われないようにしなけりゃならないこともある。
コードレビュー。
コードレビューでコメント信じてしまうと、殆どレビューにならない。コメントがメンテナンスされていないなんて言うのは普通にあるし、理想的なコメントを書いている割にコードがグダグダなんてのも山ほど出てくる。
私はレビューが始まるとすぐに（ホワイトボードの）マーカー借りて、印刷されたコードのコメントを塗りつぶすことから始めるようにしている。大量のコメントに埋もれたほんのわずかなコードがバグだらけだったりすると、レビューするほうの集中力も一気に霧散してしまうと思うのは私だけ？
これだ！！ というような、コメントの付け方っていうのは無いのだろうか。今のところ「どんなコメント書いても実行コードには影響しない」という考えは揺らいでいない。
Readable Code ? [雑談]
今から遡ること 3 年ほど前、Readable Code という書籍が出版され話題になったことがある。プログラムのロジックではなく、表現力を向上させるためのノウハウのような、この分野ではちょっと変わった内容の書籍。要は、読みやすいコードを書くことに注力していくことで、コードを共有することが容易になり、しいては、他人にコードの内容を説明するという、ある意味無駄な作業を回避するための手法のあれこれ。
当時は、主にコードを書く人たちに取り上げられ、話題になって行ったようだけど、今では、会社ぐるみで（強制ではないけど）実践を促すようなところも出てきているようだ。それ自体は悪いことではないと思うし、読みやすいコードを書いてくれるなら、そりゃ、ありがたいとは思うんだけど...。
コードに埋め込まれるコメントについては、いろいろなところで議論されてきている。コメントは多ければいいというわけではないし、全くないからと言ってそれで出荷停止になるようなものでもない。必要なところに必要なだけ埋め込むのが最良ではあるけど、その閾値には個人差が（相当）あるみたい。
左記の Readable Code にも、コメントを埋める際の指針のようなものが示されているのだけど、実践となるとなかなか上手くいかないのが現状らしい。さらに厄介なのが、書に例として挙げられてるコメントをそのまま埋める輩が出てきた。
// このメソッドは重い。繰り返し呼び出されると、パフォーマンスに影響が出る可能性がある
このコメントを免罪符のように扱うようになると、コード品質は地に落ちるのではないかと危惧する。アルゴリズムの改善を検討する前に、逃げ口上を用意しているようなものだし。
その後、このコメントが添えられたメソッドは、識者の手によってパフォーマンスを気にしなくても問題のないレベルに書き換えられた。所要時間、30 分ほどだったとか。
そして、オリジナルのコードは全てコメントアウトされた上に、、、一言、「晒されたくなかったら、真似するな」
PSR [雑談]
Windows 7 以降、ステップ記録ツール（環境によって表記が異なるようです）というスクリーンショットを撮るためのツールがインストールされるようになっている。
以前は [PrintScrn] キーで撮ったイメージをいちいちファイルに落とす作業が必要だったけど、このツールを起動しておけば画面操作を自動でファイル化してくれる。もともとは問題を再現するための手順を記録するためのものだったようだけど（英名は Problem Steps Recorder）、それ以外の用途でも結構使える。
ただ、Windows 7 でこの機能を使おうとすると、ひとつだけ難点がある。どこに登録されているかわからない...。一応はコントロールパネルから辿ることはできるのだけど、道程が長いので実用的じゃない。
多分、一番簡単なのは、[Windows] キー + [R] を押下して [ファイル名を指定して実行] ウィンドウを表示させ、[名前] に psr と入力して [Enter] キー押下。この方法は Windows 8 にも適用可能。
PSR という名前がなかなか出てこないこともあるのだけど、そんな時に備えて（以前、話題になった） GodMode のショートカットを作っておくのも便利かもしてない。GodMode の一覧には [トラブルシューティング] の項目があり、[問題を再現する手順の記録] から起動できる。
愛安穏 さん
-
nice! 4
記事 91
テーマ パソコン・インターネット
プロフィール
ブログを紹介する
