今、世界中で大問題となっている原発のお話です。6日現在、新聞等では、低レベル汚染水を海中に放出した件が韓国で問題になっている件を報じていますが、オーストラリアのオーケストラが放射能汚染を警戒して韓国行きをキャンセルした話を伺いました。
韓国の人にとってはまさにとばっちりでしょうが、オーストリアにいらっしゃる現地提携会社にお勤めの
はっぱさんからの情報なのですが、
『こちらオーストリアでは、日本は既に放射能に侵されて、壊滅した国みたいで(笑)
ザルツブルクのモーツァルテウム・オーケストラは、世界地図を知らない人が多いらしく
韓国への演奏旅行をキャンセルしました。』（なかなか過激ですが原文まま）
とのことです。オーケストラの韓国公演がキャンセルになったのは事実のようで、
こちらのサイトでもその旨を報じています。
記事では、韓国側のトンヨン国際音楽祭（TIMF)のアナウンスとして
“While the Korean government officially announced that the radiation leakage in Japan will not affect Korea and more than 150 other artists plan to visit Tongyeong for the 2011 TIMF, the Salzburg Mozarteum Orchestra’s concert cancellation seems to have been affected by the Austrians’ traumatic memory of the 1986 Chernobyl nuclear disaster.”
『韓国政府は、日本の放射漏れの影響はない見通しで150組以上のアーティストがTIMF 2011の為にトンヨン市に訪れる予定との公式発表しました。それにもかかわらず、ザルツブルク モーツァルテウム・オーケストラはキャンセルしました。86年のチェルノブイリ事故の時のトラウマがあるのではないかと見られます。』
とのことで、放射能という目に見えない恐怖は、なかなかぬぐえないようです。
われわれは、風評に惑わされないで、冷静に行動したいものです。
地震でここしばらくブログの更新を自粛しておりましたが、自分でできることをやるのが一番ということで、ブログの更新を再開します。
ブログビューワーのリリースを行おうかとおもっとりましたが、その間にADPもアップデートがあったのと、その中で、久しぶりにC＋＋/STLネタができたので、今回はC++/STLネタを披露いたします。
ちなみに、このブログで一番アクセス数が多い記事は、
C++/STLでCSVファイルの読み込みで、一時期、
自作機向けWindows7のKernel-Power 41病対策のアクセス数が首位に躍り出たのですが、再びCSVが首位に返り咲きました。『おまえらどれだけCSVやねん』と突っ込みたくなるのですが、次の刺客ということで、日本語メール送信を送り込みます。
コードは長くなるので呼び出し部分のみ以下に示します。全ソースのダウンロードは、プラットホーム別に以下のとおりです(ソースの内容自体は同じでプラットフォームに合わせて日本語のエンコードを変えています)。
Windows版(Shift_JIS)
Linux版(utf-8)
int main(void)
{
#ifdef _WIN32
WSADATA wsaData;
WSAStartup( 0x0101, &wsaData);
string charset = "Shift_JIS ";
#else
string charset = "utf-8";
#endif
string smtpserver("mail");
string to("to_address@example.com");
string cc("");
string bcc("");
string from("from_address@example.com");
string subject("サブジェクト");
string text("メール本文");
cout << subject << ":" << text << endl;
if ( !sendmail( smtpserver, to, cc, bcc, from, subject, text, charset) ) {
cout << "Error Send Mail.";
return 1;
}
#ifdef _WIN32
WSACleanup();
#endif
return 0;
}
各パラメータに値をセットして、sendmail関数を呼び出します。あて先(to,cc等）が複数ある場合はコンマ , で区切ります。サブジェクト（件名）とメールの本文のみ日本語OKです。使用している文字コードをcharsetで指定します。
例では、WindowsがShift_JISで、それ以外がutf-8になっていますが、Windowsでutf-8を使うことも可能です。
（もちろんメールの件名や本文で使用する文字コードをutf-8にする必要があります）。
日本語の取り扱いについてですが、昔、日本語メールと言えば、JISコードに変換して送るという風にやっておったのですが、最近のメーラは適切に処理をすれば（文字コードを指定し、base64等で適切にエンコードする）文字コードを変換する必要がなくそのまま送信できるようです。このプログラムもそのまま送信しています。
ちなみに、このプログラムにはbase64のエンコード・デコードも入っています。詳しくはソースをご覧ください。
コンパイルに際して注意があります。char をunsigned charとしてコンパイルする必要があります。
gccでは、
g++ -funsigned-char sendmail.cpp
のように -funsigned-char オプションを使用してコンパイルします。
Visual Studio 2008の場合は、プロジェクトのプロパティ→構成プロパティ→C/C++→言語→char型を規定でunsigned を はい にします（または/Jオプションを指定します）。
このプログラムは、以下の環境で動作確認しました。
Linux：Centos 5.5
Windows: Visual Studio 2008 professional / Windows 7 ulitimate 64bit （32ビットモードでコンパイル）
3月11日の東北関東大震災、被災者の方には心からお見舞い申し上げます。一日も早い復旧を願っています。
こういうときはITエンジニアはあまり用がないかとも思っておったのですが、『
東電が電気使用状況データをCSVで公開 「アプリ作ったら知らせて」と経産省』という記事を読み、少しでもお役にたとうと
WEBアプリを私も作成してみました。
以下のようにiframeで差込ができようにシンプルに作りました。ご自由にご使用いただければと思います。
<iframe src="http://www.global-navigator.com/toden/consumption.awp"
width="640" height="25" marginheight="0" scrolling="no" frameborder="0" >
当面、データをアップデートします。毎時、5分、15分、25分、35分、45分、55分に
東電のサイト（電力の使用状況グラフ（当社サービスエリア内））にデータを取りにいきます。
簡単に説明しますと、取得できた最近の1時間毎の電力消費量(単位が万KW)で表示しています。括弧内の%は、ピーク供給力に対する電力消費量の割合（％）を表示しています。
色ですが、90%以上で赤字になります。80～90%がオレンジ、それ以下が緑色になります。
前日差は、前日の同時刻帯の電力消費量の差分を％で表示します。
表示の内容につきましては無保証です。自己責任でご使用下さい。
確定申告の時期ですが、今年は
e-Taxで申告しました。という訳で今回はそのレポート。
いきなり結論ですが、個人の確定申告の場合、e-Taxは便利かと思います。特に良いところは、いちいち手で書かなくてもよく、ほとんど自動で転記してくれるので手間がかかりません。また今年（？）まで、初めてe-Taxで申告する方は、５,０００円の税額の控除があります。いくつか準備が必要ですし、
こういう話もありますが、準備は１回ですみますし、それを補ってあまるぐらい便利でしたので、今からでも間に合いますのでよろしければご参考にしていただければと思います。
もっとも、今まで確定申告をご自身でやったことない方（税理士等にまかせっきりで内容を確認していないとか初めての確定申告とか）はちょっと厳しいかと思いますのでそのあたりは充分にご検討された方がよろしいかと思います。
※注意！ 私と当局の方とはまったく関係がございません。本ページの記載内容はあくまでも個人が試した結果であり、間違い等がありましても著者は一切責任を取りませんのであらかじめご了承ください。
■必要（使った）なもの
・ICカードリーダー（
私が使ったもの）
・住民基本台帳カード
・電子証明書（住民基本台帳カードにインストールする）
ICカードリーダーは３千円で購入しました。住民基本台帳カードと電子証明書は役所で入手できます。手数料は、それぞれ5百円（計千円）掛かりました。カードと証明書は、即日発行できるところや２週間程度かかるところ、住民基本台帳カードのみ取り扱うところとかありますので役所のホームページで確認した方がよろしいでしょう。今からでしたらぎりぎり間に合うかと思います。
■環境の構築（事前セットアップ）
詳しくは
e-Taxのページを読んで頂くことになりますが、事前にソフトウェアをインストールする必要があります。ちなみに私はWindows7 64bit ulitimateで環境を構築しましたが正常に動作しました。
■私がはまったところ
詳しい使い方は、
e-Taxのページを見ていただければと思いますが、数年間に渡りいろいろバージョンアップを重ねたようで個人の確定申告に関してはだいぶ使いやすくなったかと思います。通常の給与所得者の申告もできますし、青色申告にも対応しています。
一応私はソフトウェア関係のプロですし、確定申告も何回かやっているので要領はわかっているつもりですが、それでもいくつかはまりました。以下、私がはまった点を紹介します。
- 番号取得時（初回）のリンクと、作成再開のリンクが異なる － 当たり前かもしれませんが、初回のリンクと作成再開のリンクが異なります。この画面の大きなボタンの『作成開始』というのが初回にクリックするボタンで、『作成再開』が２回目以降にクリックするボタンです。ちなみに、２回目以降に使用するというのは入力処理を中断して再開する場合を指し、その際にデータを保存しておく必要があります。
- カードリーダー周りのトラブル － カードリーダー周りで２つ程、軽微なトラブルがありました。１つは事前セットアップ後に、プログラムグループの『公的個人認証サービス』から『ICカードリーダライタ設定』を実行しておく必要があるがその説明がFAQにしかないのでカード読み込み時にエラーになる点と、もう１つは、設定後でもカードリーダーが上手く読み込めないことがありその場合に一旦「戻る」をクリックし画面を戻し、もう一度進めると上手くいくことがありました。
- ヘルプデスクの担当者について － ２回程電話をしましてあくまでもその範囲内での意見ですが、ヘルプデスクの人に当り外れがあります。確定申告の規則がややこしいので全部を覚えきれないのでしょうが、いい加減と受け取れる回答をする方がいらっしゃいましたのでその場合は、１．『そんなはずはない』と言って上の人に調べてもらう（エスカレーションしてもうらう）か、２．かけ直して知っていそうな方に当たるまでがんばるか、しましょう。
- 間違えて申告した場合 － 一旦送付した後に間違いに気づいたのですが、ヘルプデスクに確認しましたところ電子申告自体は何度でもでき、最後に申告したものが有効になるとのことで、そのままもう一度申告しました（データを保存していたので修正して電子申告しました）。
とまぁ、こんなところで私と嫁の確定申告が２時間半で終わりました（去年は半日かけました）。
OpenBlocks600の記事で紹介しましたブログビューアーですが、その後、バグ修正やRSS関係の対応をしてから1週間経ち、apacheのエラーログにもエラーが出ていないので、そろそろリリースしようかなと思いソースを眺めていたのですが、あまり教示的なソースでなく『公開すべきか、せざるべきか・・・』と悩んでおったのですが、こういうときは他人はどうしているのかと、最近のWEBアプリの動向でも探ろうかとネットを検索しましたところ、面白い記事を見つけました。
http://satoshi.blogs.com/life/2009/10/rails_mvc.html Ruby on Railsの「えせMVC」の弊害
http://satoshi.blogs.com/life/2009/10/ormappingmvc.html O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
ブログ主（Satoshi Nakajimaさん）の主張ですが、要するにモデルとコントローラの役割はきちんと分けようねということで、『ビジネスロジックをコントローラに書くのはNG』とのことのようです。
ちなみに私ですが、ちょい書きのアプリだとまぁコントローラでビジネスロジックどころか、SQLを書いたりします。またブログビューアーの構造も思いっきりMVCモデルから逸脱しているので・・・という訳でブログビューアーを書き直そうかなとか思ったのですが、もう少し調べてみようということで、以下、Rubyの作者のまつもとさんの記事を見つけました。
http://itpro.nikkeibp.co.jp/article/COLUMN/20080610/307218/ まつもと直伝 プログラミングのオキテ 第20回 MVCとRuby on Rails
この記事の
7ページ目の表2にRailsのMVCということで従来のMVCとの比較がありますが、その表から2パラグラフ目の説明を引用しますと
一方，HTTPの性質によってUI部分の複雑さはWebブラウザに任せてしまっているWebアプリケーションでは，相対的にUI層が薄くなります。コントローラ相当はほぼ汎用品で十分ですし，モデルとビューのインタラクションも不要です。ですから，モデルをデータベース層とビジネス・ロジック層に分割して，下層をモデル，上層をコントローラと呼ぶようにしたのでしょう。
ということで、まつもとさんの説によるとビジネス・ロジック層はコントローラに記述することになるようです。
かの有名なRubyの作者のまつもとさんが、このように言っておられるのでこの勝負は『Railsでは、ビジネス・ロジック層はコントローラに記述する』で軍配が上がりそうですが、実は先のブログ主さん（Satoshi Nakajimaさん）も知る日とぞ知る方で、過去にマイクロソフト社に勤務されておりWindows95の開発では、Windows3.1との互換性を保つために尽力されたらしく、そのあたりの話は
こちらで参照できます。また先の主張は、実際に
Ruby on Railsを使ったプロジェクト通して行き着いたようでしてそれなりに説得力があります。
このように著名なエンジニアの見解が異なる場合、どのように解釈すればよいのか悩ましいところですが、実行速度についてとか明確に白黒つく場合のように客観的に測定できる事実が無い場合、
『どちらでも良い』
というのが私の経験から来る見解になります。
この手の議論はエンジニアを引き付けるものがあり、熱くなったりするのですが、議論してもみのりは少なかったりします。
私も過去にこの手の議論に巻き込まれたことがあるのですが、特に個々のエンジニアが持つバックグランドが異なる場合、あまり前向きな議論にならなかったです。
今はインターネットがあるので様々なエンジニアの見解を比較することができるので、このように『他の人はどう考えているか？』というのをわざわざ議論しなくても解るので改めていい時代になったと思います。
というわけで、まぁブログビューアーは作り直さずに公開したいと思います。