「ITエンジニア 生き残りの条件」について

今月のSoftware Designの特集である「ITエンジニア 生き残りの条件」を読んでの感想。
タイトルの割に内容は凡庸だな、と思いつつも、従事者(一応ね)としてはやっぱり意見しておきたい。
記事でも指摘している通り、ITゼネコンの重層構造は確かに崩壊しているのだろう。僕の周りでもそういう実感はある。
一方、記事中で、ITゼネコン(SIer)の凋落と、ネット関連企業を並べているのには違和感を感じた。後者は今まさに激しい勝負の真っ最中であって、勝者しか生き残らないような戦いをしている。そこに優秀なエンジニアが必要なのはもちろんだろうけど、少々次元の違う話だろう。
僕は、これまで、この産業でこれだけの人数を養えていたことが異常だったのではないかと思う。
ソフトウェア開発というのは高度に知的な作業だから(だよね?)、個人の能力によって生産性は激しく異なる。これは関係者なら誰でも同意するだろう。なので、今は「全体としてちゃんとした能力をもつ会社」が選別されていく過程にあるのだろうと理解している。
あと、記事中ではオフショアについても言及されていたけれど、僕はオフショア開発にはあまり肯定的ではない。
ソフトウェア開発の期間はビジネス上の要請でどんどん短くなっている。そして、それは実現可能になっている。僕は環境や要素技術などの進歩によって可能になっていると言いたいが、単に現場が無理をしているだけということもあるかもしれない。
そういう状況の中で「外国に出す」というオーバーヘッドは許容できないケースの方が多いだろう。なので、オフショア開発がどんどん増える、ということにはならないと思っている。
もちろん、大規模なシステム開発においてはこの限りではないだろう。
ただ、大規模なシステムもこれからは減っていくだろうと思っている。それは計算機の能力向上、銀行や自治体の統合、この国の人口の減少、など色々な理由があるから。
結果として、顧客企業の発注コストの低下は、単純にIT産業従事者全体の給与原資の低下につながるだけだろう。
産業の規模を縮小するか、給与減少を甘んじて受け入れるか。今、この産業が転換点にあることは間違いない。

新聞ダイジェスト

明日は「新聞ダイジェスト」の発売日。
普段はAmazonで買うけど、エコポイントで引き替えた図書券があるので、書店で買う予定。
新聞をとらなくなって久しいけど、何が起こっていたかを具合良くまとめてくれているので、この雑誌は重宝している。良くできたスクラップ集、という感じ。
たとえば新聞だと、社会を賑わす事件が起こったら、連日そのニュースが掲載されて、最後は結局身内の犯罪でした…なんてことに数日つき合わされるけど、ダイジェストだと、結果だけずばり切り抜いてくれてる。
新聞を読むのは時間の無駄だと思いつつも、ニュースをしっかり知っておきたいという人には本当にオススメです。

PHP5で日本語のメールを送る

PHP4からPHP5へ移行していて、send_mail()ではまったので、メモしておく。

まず、これまでのコードはこんな感じ。

send_mail(“宛先”, “件名”, $body, $name, $address);

  • 宛先はメールアドレス
  • 件名は普通に日本語(スクリプト自体はEUCなのでそれ)
  • $bodyはEUCのはず
  • $nameはEUCで、氏名
  • $address は、メールアドレス

第4、5引数は、こう書いておくとFromヘッダを適当に作ってくれていた。

今後は、以下みたいのをスクリプトの先頭付近に書く。

mb_language(“Japanese”);
mb_internal_encoding(“EUC-JP”);

php.iniに書けるらしいけど、個別に書く方が無難だろう。

僕はスクリプトをEUC-JPで書いていて、内部でも文字列をEUC-JPで扱っているのでこう書いたけど、今時書き始めるならUTF-8のがいいかも。

次に、メールの本文をISO-2022-JPに変換しないといけない様子。

$body = mb_convert_encoding($body, “ISO-2022-JP”);

そして、メールの送り方はこんな感じで。

mb_send_mail(“宛先”, “件名”, $body);

件名はよしなに扱ってくれているので、そのままで。

第4引数にオプションのヘッダ(Fromなど)を渡せるけど、ちゃんとした形で渡さないといけない様子。
今回のスクリプトは、そこまでの必要性は無かったので、ここは捨てちゃった。

# 間違いがあれば教えて下さい > 識者 

超・積ん読解消法

最近、「積ん読」の解消法を見つけたので書いておく。
  1. 目次などに目を通して、何度も読むべき本かどうか決める。
  2. 一読だけで良さそうな本なら、amazonマーケットプレイスに出品する。何しろ未読なので状態は良い。「一読しかしていませんので全体的に綺麗です」などと書いて、強気(わりと高値)で出品する。
  3. その本が売れたら、改めてざっと眺めて、読む気が起これば読む。読む気にならなければ、そのまま送ってしまう。それだけの縁だったのだと諦める。

値段の付け方は大切。あまり安くするとぽんぽん売れてしまって、全く読むことができない。そこそこ強気の値段にしておかないと、読む時間が確保できない。

そして、「読もうか」と思った本は値下げする。そうすると結構売れる。

売れてしまえば、すぐに読んでメール便で発送する。近くにヤマトの集荷所があれば、PM6くらいまでに読み切って送れば即日出荷できることになる。

これで「積ん読」も解消できると思ったが、以下の欠点もある。

  • 上記「1」で愛着を感じてしまい、手放す勇気が持てないケースが多い。
  • だいたい勤め人にそんなことが可能かどうか怪しい。
  • そもそも、読むかどうか分からない本を買うということ自体、止めるべきというのが普通の考え方なのだろう(笑

個人的にはいい感じで処理が進んでいるので、この方法をしばらく続けようかなと思う。

締め切り駆動タイプの人には、まさに締め切りが強制的に設定されるので、おすすめのやり方だと思う。書いていて支離滅裂だなあと思うけど、本当に実践していて、効果は確かです。

FDDからHDDの内容を消去する方法

HDDの内容を潰したいけど、FDDしか無い人に向けて。

まずはdban(Dark’s Boot and Nuke)をダウンロード。
ダウンロードするのは、dban-1.0.7_i386.exe

最近のバージョンはCD-ROM用のISOしか無いみたい(当たり前か)。1.0.7というのがFDDでも使える最後のバージョンの様子。

Windowsなら、ダウンロードしたexeをそのまま叩けばFDDの作成ができるようだ。ただしそれは試していない。

Linuxだと、以下のようにすればFDDが作成できる。

$ unzip dban-1.0.7_i386.exe
$ dd if=dban-1.0.7_i386.ima of=/dev/fd0 bs=1024
$ sync 

(デバイスとかは適当に読み替えて)

こうして作ったFDから起動して、Enterを押してしばらく待てば操作画面になる。消去方法と対象のパーティションを選択すれば、消去が始まる。

ちょっと面倒なことに、一度の操作がおわると、ログを保存して終了モード(電源切ってくれ)になってしまう。普通はそれで良いと思うけど、いくつかのパーティションを潰したい人は何回か起動しなおすのが手間かも。

デフォルトの消去方法はDoD-shortなので、まあこれくらいでいいんじゃないかな。

操作方法は、@ITの「ハードディスクの内容を安全に消去 – DBAN」が分かりやすい。

Linuxベースでちゃんと動くので、そこそこの速さで消去ができる。これはなかなか便利なツールだと思う。

最近のバージョンのISOなんか焼いて手元に置いておけば、HDD削除ツールとしてはなかなか良いものじゃあないかな。

最後に気がついたけど、PC/AT互換機のことしか考慮していないので、ご容赦を。

『「この人、痴漢!」と言われたら』

タイトルには「痴漢」とあるが、扱っている範囲はもっと広い。冤罪を生み出す暗部を告発するルポでもある。 文章は読みやすい。通信社の人だったそうだ。修練を積んだ人の文は良い。 裁判員制度に対しては、以下のように断じている。 『裁判員制度について「とにかくまずは市民参加を実施してみること。やっているうちに悪い点は改めていけばいい」などと平気で言う「有識者」がいるのには驚いてしまう。その間、司法の場で人生を左右される人のことをまじめに考えているのだろうか。』 この本は、冤罪について考える一助となった。

Rubyについての落書きなど

Ruby(1.8)についての雑感。というか落書き。
# 嘘を書いていたら、教えてください。

  • スクリプト言語で、かなり遅い(1.9で改善されたし、そもそも実行系が色々出てるので、もう触れなくていい問題かな)。
  • 制御構造は、ALGOL族の末裔なので、慣れてるはず。
  • クラスベースのオブジェクト指向なので、慣れてるはず。
  • ビルトインのライブラリが充実していて便利。
  • 破壊的なメソッドが区別されてて分かりやすい。
  • 全ての文法が互いによく考慮されており、非常に扱いが良い。

Rubyは非常に動的な言語。Objective-Cに近い感じ(実はSmalltalkに近いのだろうか)。

たとえば、いわゆる「ダックタイピング」。型構造でメソッド呼び出しを縛るC++/Javaなどとは違って、その名前のメソッドがあれば呼んでやれ、ということ。

これはC++/Javaなどから見ると静的チェックがしにくいともいえる。ただ、ちゃんとテストをすれば潰せる問題のはず。

あとはちょっと細かいけど、

  • includeでインスタンスに特定の操作を追加できる。
  • 「import Math」とかにちょっと感激。selfにメソッドを追加するんだ!!
  • 既存のクラスライブラリもHackし放題。まあ、ほどほどにしとかないと。
イテレータは強力。Javaのイテレータとはもちろん違う。ALGOL系言語の構文を利用して作っているけど、内容は高階プログラミング。関数型言語(LISPやML)などと同等のパワーを持つ。僕は頭が弱いので、うまく使えていないけど。

行末のセミコロンが必須じゃないのは良いかも。慣れてくると他の言語でセミコロンを打ち忘れそう。

# セミコロンに関しては、C/C++/JavaとPascalでもどうせ違うし

Perlとできることはそんなに変わらないかもしれないけど、よっぽど綺麗なコードが書けるんじゃないかな、と思う。

 
落書きついでに他の言語についてもちょこっと書いておくと、

C
今では、Cは普通のプログラミング言語では無いのかもしれない。OSとか制御とか特殊用途に使われる言語だ、とか書いてしまおう。

この頃はJavaとかRubyから入門する人も増えたと思う。とりあえず初学者がCをやって挫折、というパターンが減ってきたのは良いことと思う。

でも、一度は勉強しといた方が、いろいろな意味で理解が深まるとは思う。

C++
機能豊富、なんでもできるかわりに相互作用が悲惨で、素人には使わせられない。
# なんと適当な書き方だろう、一時期ずっと使っていたクセに。

Java
C++よりもランタイムで行なう部分が大きい(特にGC)し、プログラマの裁量も低いので、ずいぶん扱いやすい。もちろん見方によっては全く逆の意見になる。

単一継承/インタフェースを強要させられるため、どうにもコードがごてごてする。ただし、エンタプライズ開発では、これは悪いことばかりではない。

Perl
Rubyの1ヶ月前らしい。ネイティブPerl人が書いたコードはまさに暗号文で、一行解読するのに一日かかったりする。ちょっと言い過ぎか。

Ruby技術者認定試験合格

もうずいぶん前の話になるけど、Ruby技術者認定試験に合格したので、その話を書く。

僕は未だにRubyはあんまり使ってないけど、今後は使うことも増えてくるだろうし、会社のプッシュ(=報償金)もあったので受験した。ちなみに合格は 2009/6/13 だから、今とは変わっている所があるかもしれない。Gold試験は昔は無かったし。なので、たぶんSilver試験(Ruby Association Certified Ruby Programmer Silver)の話になる。

他の試験との一番大きな違いは、届く認定証が「出雲民芸紙」という手漉き和紙なこと(これ本気)。風合いが良いし、地元志向感がとっても良いなあと思った。

ruby

これが認定証の「紙の説明書」。うちの安物スキャナでは色合いがきれいに出なくて残念。こんな認定証は初めてなので、大切に保存しておこうという気持ちになる。

試験の内容に触れておくと、Rubyをバリバリ使っているぜ、という人が落ちるようなものじゃないと思う。短いコード片や基本的な文法、ライブラリなどについて問われる。

受験料がもったいないので、絶対に一度で合格したい!という人は、以下の本をやると良いと思う。

どんな感じで出題されるか、非常によく分かる。というか、出題者とこの本の作者は同じなんじゃないかな。これをぱぱっと解ける人なら、よほどミスらない限り合格すると思う。

Rubyをまったく知らない人は、まずRubyを軽く勉強した方が良いと思う。上記の本でも文法の説明など少しはあるけど、そういう種類の本じゃない。

要注意なのは、試験は(たぶん)Ruby 1.8について問われること。もう既にRuby 1.9がリリースされていて、文法面でも色々改善された点が多いけれど、試験対策にはRuby 1.8の本を買うように気をつけよう。

僕が読んだのはこの「たのしいRuby」第2版。すでに第3版が出ていて、そちらはRuby 1.9にも触れているみたいなので、実用には第3版の方がいいかもしれない。

 

この本はどちらかというと初級者向けの本。なので、他言語の経験者は少しまどろっこしく感じるかもしれない。僕はこの本を一通り読んで、気になる所は実際にコードを書いて試して、軽く流した。その後上記の公式ガイド本を読んで、受験したという感じ。

その後、以下の本も買ってしまった。

「初めての」とあるけど、これは初級者向けではない。他の言語をちゃんと経験した人が「初めて」Rubyに向かうための本。だから記述もあっさりしている。こちらの本の方が薄くてページは少ないけど、情報量は多い。ちなみにRuby1.8とRuby1.9と両方に触れている。

どちらの本も内容は良いと思う。どちらか一冊にしようとして悩む人は、amazonで目次を見比べてほしい。後者の本の目次をみて「こっちの方が良さそう」と感じる人には、そっちの方が良いと思う。

アリコの「知っておきたい保険のこと 10のポイント」を読んでみて

アリコの「知っておきたい保険のこと 10のポイント」を読んでみての感想。
はじめに断っておくけど、僕はアリコの回し者ではなくて、一人のFA(ファイナンシャル・アドバイザー)として、純粋に内容に興味があったから読んでみただけ。FAといっても知識はアップデートできてないし、本業でやっているわけでもないから、ほとんど素人に毛が生えた程度。なので間違いがあれば指摘してほしい。
まず、保険会社が配っている資料にしては良心的だな、と感じた。
とくに「自分に必要な補償を理解しましょう。」の節はまとも。
生涯同一の補償額が必要なはずはなく、それをちゃんと書いてあるのはえらい。「子供が産まれたら補償額をUP!」とか「住宅を買ったら補償額を減らせます。」とか、当たり前のことをきちんと書いてある。これだけでも評価できると思う。
つまり、子供が産まれるまでは、保険などは入りたければ最低限のものにしておき、子供、特に末子が産まれたときには最大の補償が得られるようにして、後は逓減していくような契約で充分だということ。掛け金は払えば払うほど保険会社が儲かる、ということは忘れない方がいい。
「公的補償の内容を良く理解しておきましょう。」の節はちょっと記述が甘い。
「もしも世帯主が亡くなってしまった場合は?」というのは「世帯主」=「男」という前提で書かれている。現行の年金制度は、世帯主の夫を亡くした主婦と、世帯主の妻を亡くした主夫では扱いが違う。気になる人は調べた方がいい。
労働に関しては男女雇用機会均等法などが一応整備されているけど、社会保険の分野では男女同権には全くなっていない。これは憲法の趣旨に反してるんじゃないか。ただ、今後変わっていくとしても、主夫に手厚く、というよりは主婦に手薄に、という感じに向かう可能性が高いんじゃないかな、と思う。
高額療養費制度については、最低限のことはかいてあるけど、健保組合によってはさらに上乗せがある場合もある。例えば僕が入っている健保組合であれば1ヶ月の個人負担の上限は2万円だ。もちろん差額ベッド代とかは別なのだけど。
ふつうの会社員なら、健康保険にはかなりの保険料を納めているハズなので、補償内容はしっかり把握しておこう。ちなみに、健康保険料は労使折半で払っているという建前だけど、労働者からは半額に見えるだけで、実際には倍額払っているのと同じこと。そうすると、結構すごい保険料では?
先進医療についても、例えば重粒子線治療では300万円かかる、などと書いてある。でも滅多にお世話になるものでもないし、例えばそれくらいの値段の車を買っちゃう人は結構いるんじゃないかな。それと同額くらいの金額をカバーするのに保険に入る(特約を付ける)必要があるのか、と個人的には思う。
話は違うけど、僕らよりも世代が上の人で、いわゆる「逆ザヤ」が発生するような契約を持っている人は、非常に得をすると思うので、もちろん継続した方がいい。
徐々に話がずれてしまったけど、保険のかけすぎはもったいないので、色々調べて節約するようにした方がいいですよ、ということで(笑)。

ファンの清掃には気をつけよう

奥様のノートPCのメモリを増設しようとして、本体を半分解体したので、ついでにホコリも取っておこうと掃除機をかけた。

冷却ファンにも掃除機をかけようとして、掃除機を近づけるとファンが勢いよく回り、いい感じにホコリが取れた。ところが、うっかり掃除機の一部を回転中のファンにぶつけてしまい、ファンの羽根をかなり折ってしまった。下はその証拠写真。

oldfan2

こんな状況でもいちおうファンは回るのだけど、音もおかしいし、たぶん良くないと思うので、仕方なくパーツを購入することにした。

こうやってパーツを買いやすいのがThinkpadの良いところだけど、純正品は納期に時間がかかりそうなので、通販で再生品(たぶん中古PCから抜き取ったやつ)を買った。

届いたパーツが以下の写真。見比べると、どれだけひどく折れてたか分かるのではないかと。

newfan

ファンの交換後は快適(というか普通に)に使えている。

それにしても、ばかな失敗だった。みなさんもこういう部品には掃除機を近づけたりせず、エアダスターで吹くくらいにしましょう。