サーバラックにも見た目のかっこ良さにこだわったものから質実剛健なものまで様々です。

世の中の会社の多くは何らかの情報システムを取り入れていますので、勤務している社員の方はどこかの会社のサーバを利用していることと思います。しかしながらほとんどの方が、大きな会社ではおそらく99%くらいの方は自分が接続しているサーバまたはサーバラックを見たことが無いのではないでしょうか。

全社員が1フロアに集まって仕事ができるような規模であればオフィスの片隅にサーバが設置してあるかもしれません。しかし排熱・騒音・電力の問題もあってあまりお薦めできない環境である事が多いように思います。となるとサーバ室に置く事になり、関係者以外の目に触れないという残念な事になります。

色々な会社をサーバおよびサーバラックを見ることがありますが、自己主張の強いデザインのものもあれば存在感のないものもありますね。何か異常がある時にひっそりとLEDで知らせてくれるだけのサーバもあれば、何も無くても自社のロゴをバックライトで煌々と照らし上げる愛社精神にあふれたサーバもあります。

誰にも見られないまま役目を終えるのはもったいないほどかっこいいサーバやサーバラックがたくさんあるのでサーバ室の見学にもっとたくさんの人が参加すると良いのではないかと思います。受け入れ側からしたらセキュリティ関連の手続が大変なのでありがたくない話ですが。

個人的に一番かっこよいと思うのはSun Microsystemsのラックです。これまでにいくつかのラックを見ましたが、ヤンキーがスプレーで落書きしたのかと思うほど大きくはっきりロゴがプリントされています。大変印象的でした。ブルー系しか見たことがありませんが他の色もあるのでしょうか。

 sun

IBMのラックは黒です。手触りはシンクパッドのようなざらざら感です。汎用のラックは真四角で装飾らしい装飾がありません。ただし通気の関係でメッシュ構造になっているドアの部分については、他社が円形のパンチングメタルが中心なのに対してIBMだと六角形の穴になっていたりします。そういうところがまたかっこいいですね。zSeriesとなるとこれはもはや芸術品の域に達しているというか、これを見るためにSEになりたかったのではないだろうか、というとそれは言い過ぎか。

ibm

HPというとラッキングしてきれいにケーブルも整理してそのまま出荷してくれる、というサービスが有名です。サーバラック自体はあまり特徴がないという印象です。IBMやHPというともっとガツンとロゴが出てくるイメージがあるのですが。IBM同様、シンプルな中にも全面のメッシュ構造に遊び心があります。HPでは縦線のアクセントが入っていてプチおしゃれになっています。

hp

他、外国のラックで見た記憶があるのはDellとEMCくらいです。どちらもやや派手目なのですが、少し華美な感があります。秋葉で売ってるグラボの箱のデザインを見て「濃いなー」と思う感情に似ているかもしれません。

dell

日本勢では日立が好みです。シルバーのラックを見たことがあり、ぐっと来ました。

　日立

富士通のラックは好き嫌いがありそうです。メカメカしたのが好きな人にはたまらないでしょう。自分としてはzSeriesのメカメカさはすきなのですが富士通のラックのメカメカさは少し行き過ぎの感があります。

富士通

NECのラックはというと可もなく不可もない感じでして、割愛したいくらいなのですがそれはさすがに知り合いに怒られそうなので何かコメントを入れたいと思います。えっと、汎用京速計算機はラックのデザインにもこだわってください。

　NEC（地球シミュレータ）

ちなみにこのサーバラックというのは高額です。耐震試験など施す関係でコストが高くなってしまうのでしょう。どこのメーカーとは言いませんが、バリ取りが不十分でスパッと手を切ることも少なくありません。しかも運送屋さんがサーバ搬送用の特殊なサスペンションがついたトラックでサーバと一緒に慎重に運んできたにも関わらず噛み合いが悪くて組み立てに苦労したりとなかなかの困ったちゃんぶりを発揮する事もあります。

アイリスオーヤマかイナバ物置あたりから財布にも運用担当者にも優しい42Uラックが1台1万円くらいで発売されないでしょうかね。

4月になると新入社員が入社してきますが、なかなか難しいのが「お作法」のことです。

大規模なシステム開発ではお互いの意思疎通ができていないと作業が進みません。部品と部品とがつながらない、ですとか予想外のデータが渡されてしまう、という根源的な問題はきちんと設計書を作っておけば回避できる問題です。しかしながら現実には設計書だけでは回避できない問題もあります。

例えばメンバーの入れ替わりが激しく、何人かで1本のプログラムを作るということがあります。極端な例で言うとまずAさんが基本的な機能を作成し、動作するようになるまでBさんが修正し、単体テストレベルの厳密なエラー処理をCさんが行い、結合テスト段階での不具合をDさんが修正する、というような場合です。

お互い開発のプロとしてそれなりの技量を持っていますが、他人が作ったプログラムを引き受けるのはやはりやりづらい作業です。こういう場合、変数の使い方のルールなどを「コーディング規約」として掲げておくと便利です。例えば変数では一文字変数を禁止する（i,j,kなど）、名前を英語または日本語で統一する（intSum,intGoukeiなど）、接頭語を統一する（int,Lngなど）などを行えば変数が意味する内容を理解しやすくなります。（自分が作ったプログラムすら再読できないのは問題外ですが。）

ところがあまりにも膨大なコーディング規約を作成すると、誰もその全容を理解できなくなってしまいます。せめて「これは規約でルールが決まっていた気がする」というくらいの印象が残る量で無ければ、それぞれの条項を遵守する事も現実的ではなくなってしまいます。となるとあまりにも基本的なことはコーディング規約に掲載されなくなり、「普通こうするだろ」という暗黙の了解は「お作法」という名前の不文律と化します。

その組織がどこまでをコーディング規約に載せるかによってお作法と化すかどうかは変わります。誰もが「これはお作法だろ」と思うものは想像し難いのですが、こういった感じで伝わりますでしょうか。（私の思いつきです。弊社の規約とは関係ありません）

• Const定数は各プログラムに分散させないで記述場所はまとめる
• 引数が4個以上になるならクラスを作って1個の引数とする
• If文の条件でNotを使わずにElseで表現する　←　私の好みです。
  if A=B then
       '　何もしない
  Else
       hoge()
  End IF

プログラムの実行場所となるハードウェアは最近ますます性能がよくなっています。一般的な企業向けの情報システムを開発する現場では「メモリの1バイトは血の一滴と思え」と言われる機会などほとんどないのではないでしょうか。そう言ったところではメモリの節約のために技巧的なプログラムを書くよりも後々のメンテナンス性を考えたシンプルでわかりやすいプログラムが好まれるでしょう。もちろんメモリリークを起こすようなプログラムを書かれては困るのですが、近年の親切な言語ではメモリリークを低減してくれる機能があるものもあります。

むしろそういう言語からプログラミングの習得を学び始めた世代からしたら「1バイトが血の一滴ってSDRAMのバイト単価いくらだと思ってんだ」とか「自分で解放するよりも実行基盤に任せたほうが正確で早い」とか先輩の常識を否定するような発言が飛び出るかもしれません。大切な事は伝えなくてはなりませんが、時代の変化を無視して自分の常識を「お作法だ」と押し付けないようにしたいものです。

# そういう自分は趣味プログラマの出身で1人コーディングの期間が長かったためにソースの読みやすさには自信がありません。悪い見本とならないよう精進したいと思います。