コミュニティ

なんだか面白い武雄市

はなおかじった — Wed, 13 Mar 2013 22:24:00 GMT

元ネタ:「やはり欠陥だった武雄市の個人情報保護条例」経由、「高木浩光先生、やっぱり間違っています。もっと勉強してください。」

高木氏の所には、こう書いてある。

やはり欠陥だった武雄市の個人情報保護条例（高木浩光＠自宅の日記）より：

ところが、先週公表された、7月10日の武雄市教育委員会臨時会の会議録によると、Tポイントカードの会員番号*1が個人情報に該当しないと、武雄市の職員によって説明されている。

そらみろ、条例でちゃんと明文化しないからこういうことになる。

ここで「ちゃんと明文化しないから」とは、「「個人情報」定義の弊害、とうとう地方公共団体にまで」に、次のように書かれている部分である。

「個人情報」定義の弊害、とうとう地方公共団体にまで（高木浩光＠自宅の日記）より：

しかし、日本の個人情報保護法上は、端末ID等は、「他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるもの」に該当しないとされており、「個人情報」ではないことになってしまう。（総務省の「第二次提言」は単なる提言にすぎない。）

つまり、「他の情報と容易に照合することができ、それにより特定の個人を識別することができる」情報を「個人情報」とするかどうかは、識別情報を提供する組織が決めなければならないよ、と。日本の個人情報保護法では、「個人情報」ではない。が、扱う者が「個人情報に準じる情報」として扱うことはできる。そして、武雄市の場合は、明文化されていない。

それに対して武雄市長は、この様に述べていらっしゃる。

高木浩光先生、間違ってます。（武雄市長物語）より：

括弧書きがない場合も、括弧書きの対象である「他の情報と照合することができ、それにより特定の個人を識別することができることとなるものが機械的に除かれるわけではなく、「「民間向けの「個人情報」定義よりもさらに狭い」と断ずることはできない。これもまた、法制の世界では当たり前のこと。

「断ずることはできない」と。

はい、それは良いです。「断ずる」、つまり「はっきりと判断を下す」ことはできない、と。では、断ずることはできないが、武雄市ではどう扱うのかについては、書かれていない。民間向けの個人情報の定義よりも、広いとも狭いとも判断できない。で、広いの？狭いの？それが、この「高木浩光先生、間違ってます。」の中では広い、つまり「個人情報に紐付く情報も個人情報だ」とおっしゃるわけですね。

そして、7月10日の会議録では「個人が特定できる情報ではなくて、Tカードを使うと会員番号と何月何日何ポイント付いたという情報がCCCのポイントシステムにいく」と、記録されている。この発言をした人にとって、個人情報に紐付いている T カードの会員番号は、「個人が特定出来る情報ではな（い）」と。

高木氏が問題にされているのは、この認識のズレ、ですよね。

高木氏の主張は、「括弧書きがない場合も、括弧書きの対象である「他の情報と照合することができ、それにより特定の個人を識別することができることとなるものが機械的に除かれるわけではな（い）」」が、書かれていないために「他の情報と照合することができ、それにより特定の個人を識別することができることとなるもの」を除いて理解してしまっている人がいる。これは、問題ではないのか。ということ。それに対する武雄市市長の返答は、「書いてないからといって範囲が違うわけではない」の繰り返し。おかしいやん。武雄市市長さん、やっぱり間違っています。もっと国語の勉強をして下さい :p

高木浩光先生、やっぱり間違っています。もっと勉強してください。（武雄市長物語）より：

どういう論理展開であるか不明だが、以前に指摘したとおり、括弧書きがない場合も、括弧書きの対象である「他の情報と照合することができ、それにより特定の個人を識別することができることとなるものが機械的に除かれるわけではなく、「民間向けの「個人情報」定義よりもさらに狭い」わけではない。

狭いわけではないが、では、武雄市の個人情報は、どの範囲なんだ？その説明がないのは、なぜ？「それ違う」とは言っているが、なぜ違うのかという説明はない。なぜ説明しないの？ああ、「国の範囲と一緒」なのか。国の範囲は、「個人情報に紐付いていて、参照可能な情報も個人情報」ですよね。なぜ、それと異なる解釈が展開されているんだろう？

本文の中には「私以外にもこの御仁のおかしさについては縷々指摘してあって」と書かれているが、このエントリ（「高木浩光先生、やっぱり間違っています。もっと勉強してください。」）のコメントには、このエントリの著者に対するおかしさの指摘が目立つのは何でだろう？

ところで、この「武雄市長物語」の URL "hiwa1118" ですが、「卑猥（hiwa1）で良いや（118）」に見えるのは私だけ？

面白いんだけど・・・

はなおかじった — Wed, 13 Mar 2013 22:20:00 GMT

ネタ元：「[プログラミング]「型」があるのは福音だよ？」から「変数に型がないということの利点について考える」

うん、面白い。

どのような型の値でも代入できる

　まず基本的なこととして変数に型がなければどのような型の値でも代入できるということです。つまり、受け取るときに、どのような型の値を受け取るのかを意識する必要がありません。
my $str = 'Hello';
my $num = 1;
my $nums = [1, 2, 3];
my $person = {age => 2, name => 'taro'};
my $ua = LWP::UserAgent->new;

「どのような型の値でも代入できる」ということですが、C/C++ でも、ポインターに限定すれば、void とアスタリスクで宣言することで、どのような型のポインターでも代入できますよ。Java や C# なら、Object で宣言すれば、何でも入れられるんじゃないかなぁ？でも、それをやる人は、まず、いない。おおよそ、構造体や関数の型を定義して、それを使う。なぜか。型を明示することにメリットがあるから。そのメリットについては、明示的には書かない。

そして、これは、次と一緒と考えて良いのかな？

変数に型がないと変更に強い

　変数に型がないとソースコードの変更に強くなります。たとえば右辺の返す型に変更があったとしても、受け取る側のソースコードを変更する必要はありません。
# clinetはClientA型でもClientB型でもよい
my $ua = $c->client;

「どのような型でも代入できる」では、初期値の代入しかしていません。しかし、「変数に型がないと変更に強い」では、コーの変更のことにまで言及してあるので、例えば次のようなコードも許される、ということかな？

my $variable = 1;
my $variable = 'abc';

で、「変更に強い」というのを、この様に、「コードを変えなくてもよい」のようにはいわないと思うのですが、どうなんだろう？私がイメージする「変更に強いコード」とは、仕様に変更があったとき、「どの範囲に影響があり、どこを修正すれば良いかがわかりやすいコード」なのですが。ここで言われているのは、「どのような型でも代入可能なので、型が変わったということがわからず、変更しなければならない箇所がわかりにくい」でしかないと思うのです。ああ、「変更しなくていい」だから、変更しなければならない箇所はわからなくて良いのか。でも、変更しなければならない箇所がわかりにくいということは、変更が有効になっていることをテストするコードを書きにくい、ってことじゃないかな？そうすると、コメント欄で、「テストすればわかる」と書かれていることと矛盾します。確かに、テストコードを“書いて”、テストすればわかるでしょう。しかし、テストコードを“書く”のなら、次の所とも矛盾します。

記述量がとても短くなる

　変数の型がないことによって記述量がとても短くなります。

え～～！！テストコードの方が、記述量が短いですって？そんなこと無いでしょう？

ちょっとふざけてみました。いや、かなりまじめ。型を書くという事を「記述量が多い」といいながら、静的型付け言語では不要な「型チェックのためのテストコード」を書くことは、記述量に入らない？テストコードを書く時間は、開発時間に入らない？生産性として勘定しない？そんなバカな。。。

あと、ここも気になった。

複数の型を受け取りたいときに、インターフェースを実装する必要がない

　Javaで大きなの労力といえば、インターフェースの仕組みを覚えて、実装することでしょう。複数の型を受け取りたい変数を作成したい場合は、まずインターフェースを実装することになります。

関数のオーバーロードが不要になる

　変数の型を持つ言語は、型が異なるのだが、処理としては同一の処理を行いたい場合には、オーバーロードという機能を使う必要があります。変数の型がなければ、オーバーロードの機能は必要ではなく、ただ単にif文で分岐すればよいだけなのでとても楽です。

おそらく、「オブジェクト志向設計」を誤解しています。それはおそらく、「オブジェクト指向設計」という字を使うから。oriented は「志向」であって、「指向」ではないのです。明鏡国語辞典には、こう書かれています。

志向:［名・他サ変］意識や思考がある対象に向かうこと。「平和国家の建設を━する」「アウトドア［本物・上昇］━」「指向」とも書かれるが、本来的な用法ではない。「指向」は単に物理的な方向をいう。

指向：［名・他サ変］ある一定の方向をめざして進むこと。また、その方向へ向かわせること。「市場を東南アジア全域に━する」「━性アンテナ」

オブジェクトに指向しかしていないから、オブジェクトを使う事を考える。オブジェクトに志向するなら、そもそも「オブジェクトとは何か」について考えます。そうすると、「処理としては同一の処理を行いたい」など、処理に志向した考え方はしなくなります。オブジェクトに志向していれば、「このオブジェクトとあのオブジェクトで、同一の処理が適用できる」の様になるでしょう。

もちろん、書いてあることもおかしくて、Java, C++, C# では、次のように書くだけです。

void sub()
{
    // 「hoge().DoSomething();」とも書ける。
    IInterface arg = hoge();
    arg.DoSomething();
}

あ、「変数に型がないと変更に強い」に、次のように書いてありましたっけ。「たとえば右辺の返す型に変更があったとしても、受け取る側のソースコードを変更する必要はありません。」と。じゃぁ、同じように書きましょう。「型に追加があっても、実行するところのコードを変更、if - else if を連ねる必要は有りません。勝手に、追加された型の DoSomething メソッドが実行されます。」と。記述量も少ないし、いいよね。

で、わかっていただけないのが、この arg 引数の型が IInterface 以外に変更になったとき、静的型付き言語ではコンパイルすることで検出できるのですが、「動的型付け言語…といって良いのかな？…では、実行“しなければ”わからない」のうち、「しなければ」が「すれば」なのか、どっちだ？！という点。同じように、「テストすればわかる」なのか、「テストしなければわからない」なのか、という問題もある。コメントをされている方々は「しなければ」なのですが、著者さんは「すれば」なんですね。

で、これについては、思うのです。「経験のないものはわからない」と。

もし、著者さんが、小規模の開発、小規模物件の追加改造しかされた経験がないなら、「すれば」でしょう。しかし、大規模から巨大規模の開発しか経験されていない方なら、「しなければ」でしょう。

この間、必要に駆られて SQLite3 を触ったのですが、これって、型の宣言って、無視しやがるのね。INTEGER と宣言したのに、文字列も実数も格納できてしまうorz 私としては「怖い」のですが、アプリケーションの設定を簡易的に保存する手段としては、まぁ、良いかもしれませんね。でも、基幹業務に使いたいとは思わないなぁ。

そういうことで、小手先の技でチョイチョイとつくって、全体を見渡せる範囲に収まっているなら、動的型付け言語って、便利だと思います。一人で全体を見渡せないなら、静的型付き言語の方が便利です。

IPv6 Ready?

はなおかじった — Wed, 25 Jan 2012 22:40:00 GMT

IPv4 のアドレスは、日本では枯渇しました。で、IPv6 なのですが。。。ところで、IPv4 は、32ビット、429,4967,296種類を表せます（実際に使用可能なアドレスはそれ以下）。IPv6 は、これを128ビット、3.4028236692093846346337460743177e+38種類にした、と。

それはいいとして、IP 層の下に、Mac アドレスってありませんでしたっけ？Mac アドレスって、枯渇しないんですかねぇ？
え？48ビット、281,474,976,710,656種類あるので、IPv4ほど差し迫ってはいない、ですって？でも、業者に割り当てられるのは、24ビットで16,777,216種類ですよね？千六百七十七万、と。ミリオンヒットを16回飛ばせるのか。しかも、機器に結びついているので、機器の破棄に伴って回収も可能、と（実際に出来るかどうかはともかく）。じゃぁ、大丈夫か。。。

そういえば、Mac アドレスって、固定じゃなく、変更出来る機器もありますよね？そして、「Wi-FiのMACアドレスはもはや住所と考えるしかない」なんて記事を見かけたのですが、これって、適当な Mac アドレスを入れると住所が出る、すなわち使われているアドレスかどうかがわかる、って事ですよね？で、その、Mac アドレスを変更出来る機器を、「存在することがわかったアドレス」に変更をすると、どうなるんでしょう？IP でのフィルターがされるから、他の所にデータが行っちゃうって事はない？他の所にもコピーされたデータが届くって事はないよね？

IPv6 とはまったく関係ないのですが、この辺のサービス提供者のやり方が気になる、というのがメインのエントリ。

ストリートビューもそうですが、「公共の場から集められるデータだから良い」のでしょうか。例えば、通りを歩いているのは、「公共の場から集められるデータ」です。でも、ある日時にある場所にいることを知られる事がイヤな場合があります。ストリートビューでは、そういう場合を、いつでも、どこからでも、誰にでも、検索して見える状態にする、という性質があります（マスキングはされますけど）。問題なのは、「公共の場で集めることができるデータを集める」事ではなく、それを「いつでも、どこからでも、誰にでも、検索して見ることが出来る状態にしている」ということ、それが「オプトインではなくオプトアウトとして提供されている」こと、「収集して公開されているということが周知されていない」ということ、ではないでしょうか。

そして、Wi-Fi による位置情報サービス。HTML5 の GeoLocation API で使用するサービスのひとつですが、ある地点で観測できた Mac アドレス（Google の場合は複数）を引き渡すと、その場所の位置情報（緯度、経度）が返ってきます。「ある地点で観測できた」という所が焦点です。無線 LAN の親機は、SSID と Mac アドレスを放送しています（ここで「放送」という用語を用いるのは正しくないが）。GPS 機能の付いた機器を用いて公道でこれを収集し、問い合わされた Mac アドレスから位置情報を逆引きして返すわけです。公道で収集できるデータだから集めて良い、ってものなんですか？私が最初に無線 LAN を導入したとき、SSID にファミリーネームを設定しちゃいましたよ。でも、鉄筋コンクリート製の建物だったせいか、電波がまったく通らないので、すぐに有線に切り替えちゃいましたけどね。引っ越しをして、今度は大丈夫だろうと思ったけど、鉄骨製だからか、扉を閉めると通らない。「ブースター付き」とかいう機械を買ってきたのに。まぁ、子機もブースター付きってのを使えば何とか受信できるのと、引き回しの関係で有線に出来ないので、不便に思いながら使っているけど。で、新しい方の SSID は、デフォルトのまま使っていますが、Mac アドレスです。自分のもの以外の観測できる SSID は、メーカー名や機器名が SSID になっています。ほう？ということは、近所の人が同じメーカーや同じ機器を買ったら、SSID がかぶっちゃうわけですね。私が買ったものは、「Mac アドレスならかぶらないだろう」ということで Mac アドレスになっているのかな。で、こいつを、公道に放送したいとは思っていません。でも、漏れて行ってしまっていると思います。止める方法があるなら教えて欲しい。「家を金属板で覆え」って？そろそろ外壁を直さなきゃいけないので、その時、本気で考えようかしら？？？

なんてことを書いていたら、こんな記事も発見しましたよ→「WiFiのアクセスポイントが街中で増えることの功罪」。公衆 Wi-Fi が増えすぎると、かえって困った事態が発生すると。Ｒさん、喜ばしいことだけではないみたいですよ。（トラックバック：「自販機 Wi-Fi」）

MS-MVP

はなおかじった — Wed, 05 Oct 2011 22:07:00 GMT

今年は、表彰されませんでした。

ん～、何もしなかったからねぇ。

それでも、22日はお呼ばれしているので行きます。と、思っていたら、20日に東京出張が入ったorz え～？20日に日帰りで、22日にまたですか？21日休んじゃえって？ん～～～。スカイツリーに行ってみよう。

メソッドを切り出さない？

はなおかじった — Sun, 02 Oct 2011 21:20:00 GMT

元ネタ→[その他プログラミング][雑感]メソッドに切り出さないほうが好みなのかも

.NET Framework 4 で。


static public class CommandClass
{
    static public bool Execute(params Func<bool>[] methods)
    {
        for (int i = 0; i < methods.Length; ++i)
        {
            if (methods[i]() == false) { return false; }
        }
        return true;
    }
}

使用
public bool SomeMethod()
{
    return CommandClass.Execute(
        () => {
            ここでしかしない処理１
            return true;
        },
        () => {
            ここでしかしない処理２
            return 結果 ? true : false;
        },
        複数で使う処理(),
        以下略
        );
}

こんなコードを使っていますが、何か、、、落ち着かん！ラムダ式わかんねorz わからんというか、どう解釈すればいいのか、腑に落ちない。

例えば、「=> 演算子 (C# リファレンス)」には、「=> 演算子は「～に入力」と読みます。直前の例の式は、「Min w を w.Length に入力」と読みます。（The => operator is read as "goes to." In the previous example, the expression is read as "Min w goes to w dot length."）」と書かれている。「Min w」を、「w.Length」に入力するの？う～ん？？？ちょっと、コードもコピー。


string[] words = { "cherry", "apple", "blueberry" };
int shortestWordLength = words.Min(w => w.Length);
Console.WriteLine(shortestWordLength);
// Output: 5

ここで、words は Enumerable なので、Enumerable のメソッドである、最小値を返す Min メソッドを使用しようとしている。このケースでは、words の内容がひとつひとつ w に当てはめられ、w.Length のコレクションが Min メソッドに引き渡される。で、何で、「Min w」“を”入力なんだ？words の内容が w に入力されて、右辺である w.Length が実行されるんじゃないのか？

と、ここの解釈が腑に落ちないので、理解が進みません。誰か助けて。

元ネタに戻る。

「カレー用のタマネギの切り方とか、チャツネにする用の炒め方」は、別に参照にせんで、ここに書いていただいてもよいのではないかなぁ、と。

う～ん、どうなんだろう？私は串切りにして楽しみたいのだけれど、ここに「串切りにする」と書いてあってもいいと思う。でも、「串切りの切り方は、こう」という説明までは要らないんじゃないだろうか。うん、「タマネギを切ります」としか書いていないから「別に参照にせんでも」と思うけど、「タマネギを串切りにします」と書かれていれば、「串切りの仕方は参照で良いよね」と思うのではないだろうか。どうせ、「タマネギをどう切るのか」には興味はあるが、「その切り方は、どうのように包丁を入れるのか」には、興味ないでしょ？

[Win8] Windows 8 に Windows Live ID でサインインする

はなおかじった — Tue, 27 Sep 2011 21:05:00 GMT

元ネタSigning in to Windows 8 with a Windows Live ID

Windows は、それを許可した人から送られてくる使用状況のレポートを分析して、次のバージョンが作られます。今度の Windows 8 は、「1台のコンピュータに複数のユーザーアカウントが作成される」という状況と、一人が複数のコンピュータを使用しているという状況に対して、「Windows Live にアカウントの状態を保存する」という方法が採られるようです。

ブログによると、メトロスタイルのアプリケーションは、状態を Windows Live に保存することになるようです。Windows へのログオンアカウントと、Windows Live ID を関連付けることで、1度のサインインで複数の Windows Live ID が必要なサービスを、2度目のサインインなしに使用することができます。

従来のローカルアカウントも選択でき、この時は、後から Windows Live ID と紐づけると同時に、何を同期させるか、選ぶことが出来ます。同期させることが出来る項目は、次の通り。

パーソナライズ　（おそらく、デスクトップを右クリックして出てくる「個人設定」）
テーマ
コンピュータの簡単操作
言語環境
Apps
ウェブブラウザー
他のもの
若干のパスワード

なお、壁紙については、2MB 以下のものはそのまま、2MB を超えるものは1920x1200に切り取られた上、圧縮されて保存されるようです。

ドメイン環境では、ドメイン管理者によって、これらの同期が制限されることもあり得るようです。

さて、こういったものがクラウドに保存されるとなると、当然、セキュリティへ関心が向きます。Windows 8 アカウントに Windows Live ID を紐づけるには、強いパスワードが絶対必要になります。そして、「秘密の質問」が必要になってきます。また、Windows Live ID のアカウントが奪われた場合に、奪われたことを検出する何かがあるようです。ブログには、検出する方法については書かれていません。例えば、PC が盗難にあうと、Windows Live ID も“盗まれる”わけですが、この様な状態の時、盗まれた PC については窃盗者に完全な制御が移りますが、Windows Live ID については“危うくされた状態”に移行し、「秘密の質問」によってアカウントを回復するワークフローを完了するまで、オンラインサービスを使うことは出来ません。

ん～、なんだか、管理者にとっても開発者にとっても、大変なことになっているような気がする。

お～っと、日本語もあった→Building Windows 8

Bing で検索「単語の順序を指定して検索」

はなおかじった — Fri, 03 Dec 2010 22:00:00 GMT

Visual Studio 2003 の頃の Document Explorer は、検索ボックスに指定した単語の順序に検索をしていました。「管理ツール」と検索したときに、「ツールバーにある検索ボックスに指定します。ツールバーを追加するには、管理者として実行をします。」という文章は、ヒットしないのです。これがどういうときに便利かというと、「コピー」という単語と、他の何かの単語を含むページを検索したいとき、検索キーワードを「コピーなんとか」とすると、ページの最後にある「コピーライト：だれそれ」によって、不要なページがヒットしない、ということです。

この、「順序通りに現れた場合にヒットとする」は、Visual Studio 2005 の頃になくなりました。Visual Studio 2010 になって、この辺りの中の人に尋ねると、「2010 からウェブ検索だからねえ」といわれてしまいました。

先日、「新人 MVP をいぢる会」もとい、Open Days が開催されたとき、Bing の中の人と話す機会がありましたので、「こういう検索が出来る演算子が欲しいんだけど」と要望すると、「ダブルクォーテーションを試していただけますか」との返答。なんですと？！早速、Bing のヘルプページにアクセスします（もしかすると、live へのサインインが必要です）。検索演算子は、「すばやく検索結果を得るには、以下のキーワードや記号を使用して検索キーワードや検索条件を変更します。」というページにあります。

さて、ダブルクォーテーション（で囲む）の説明を見ます。語句と完全に一致する語句を検索します。となっています。検索エンジンには「ストップワード」という語が設定されています。英単語では、"for", "is", "has", "have" などがストップワードとなっており、これらを検索ボックスに指定しても、検索の対象となりません。しかし、ダブルクォーテーションで囲むと、検索の対象となります。また、日本語では、文章を入力した場合、例えば、「自然言語検索とは何か」と入力すると、「自然」「言語」「検索」「何か」に単語が分けられ、これらの単語を含む文書がヒットします。しかし、この文書をダブルクォーテーションで囲むと、この文章そのものがひとつの単語の様に扱われます。

この様に、「語句と完全に一致する」ものだということは知っていました。スペースを含むと、スペースも検索語句の一部とみなされると。

ところが、スペースは任意の語句に一致するということになります。Bing のオンラインヘルプ検索で試してみましょう。「管理ツール」を検索します→検索結果。検索結果は2つです。ふたつとも、「ツール」「管理」の順で使用されています。では、「"管理ツール"」で検索します→検索結果。ヒットする文書はありません。

というわけで、「単語がこの順番に現る場合」を検索したいとき。つまり、文章そのものを覚えているので、その文章を含むページを見つけ出したいときに使えます。

[OpenMP]分身！

はなおかじった — Sun, 24 Oct 2010 14:14:00 GMT

分身というのは、違う気がする。

parallel ディレクティブがあるだけだと、複数のスレッドがそこを実行する。


//#include "stdafx.h"
#define _WIN32_WINNT 0x0500
#include <stdio.h>
#include <locale.h>
#include <tchar.h>
#include <omp.h>
#include <strsafe.h>
int _tmain(int argc, _TCHAR* argv[])
{
    HANDLE hStdout = GetStdHandle(STD_OUTPUT_HANDLE);
    TCHAR msgBuf[BUF_SIZE];
    size_t cchStringSize;
    DWORD dwChars;
    _tsetlocale(LC_ALL, _T("Japanese_Japan"));
    #pragma omp parallel shared(hStdout) \
        private(msgBuf, cchStringSize, dwChars)
    {
        StringCchPrintf(msgBuf, BUF_SIZE,
            TEXT("スレッド%dで実行\n"), omp_get_thread_num());
        StringCchLength(msgBuf, BUF_SIZE, &cchStringSize);
        WriteConsole(hStdout, msgBuf, cchStringSize, &dwChars, NULL);
    }
    return 0;
}

スレッド0で実行
スレッド1で実行

1つのスレッドに1つの実行範囲を割り当てるのが、・・・そういう範囲がありますよという宣言をするのが sections ディレクティブで、実際に範囲を指定するのが section ディレクティブ。


//#include "stdafx.h"
#define _WIN32_WINNT 0x0500
#include <stdio.h>
#include <locale.h>
#include <tchar.h>
#include <omp.h>
#include <strsafe.h>
int _tmain(int argc, _TCHAR* argv[])
{
    HANDLE hStdout = GetStdHandle(STD_OUTPUT_HANDLE);;
    TCHAR msgBuf[BUF_SIZE];
    size_t cchStringSize;
    DWORD dwChars;
    _tsetlocale(LC_ALL, _T("Japanese_Japan"));
    #pragma omp parallel shared(hStdout) \
        private(msgBuf, cchStringSize, dwChars)
    {
        #pragma omp sections
        {
            #pragma omp section
            {
                StringCchPrintf(msgBuf, BUF_SIZE,
                    TEXT("セクション1は、%dで1度だけ実行される。\n"),
                    omp_get_thread_num());
                StringCchLength(msgBuf, BUF_SIZE, &cchStringSize);
                WriteConsole(hStdout, msgBuf, cchStringSize, &dwChars, NULL);
            }
            #pragma omp section
            {
                StringCchPrintf(msgBuf, BUF_SIZE,
                    TEXT("このセクションの実行は、%dで1度だけ。\n"),
                    omp_get_thread_num());
                StringCchLength(msgBuf, BUF_SIZE, &cchStringSize);
                WriteConsole(hStdout, msgBuf, cchStringSize, &dwChars, NULL);
            }
        }
 }
    return 0;
}

セクション1は、0で1度だけ実行される。
このセクションの実行は、1で1度だけ。

当然の疑問。「セクションの数とスレッドの数が違うと、どうなるの？」やって見る。


//#include "stdafx.h"
#define _WIN32_WINNT 0x0500
#include <stdio.h>
#include <locale.h>
#include <tchar.h>
#include <omp.h>
void threadPrint(int num)
{
    HANDLE hStdout = GetStdHandle(STD_OUTPUT_HANDLE);
    TCHAR msgBuf[BUF_SIZE];
    size_t cchStringSize;
    DWORD dwChars;
    if (hStdout == INVALID_HANDLE_VALUE) {
        return;
    }
    #pragma omp parallel sections num_threads(num) \
        shared(hStdout) private(msgBuf, cchStringSize, dwChars)
    {
        #pragma omp section
        {
            StringCchPrintf(msgBuf, BUF_SIZE, TEXT("セクション1[%d]\n"),
                omp_get_thread_num());
            StringCchLength(msgBuf, BUF_SIZE, &cchStringSize);
            WriteConsole(hStdout, msgBuf, cchStringSize, &dwChars, NULL);
        }
        #pragma omp section
        {
            StringCchPrintf(msgBuf, BUF_SIZE, TEXT("セクション2[%d]\n"),
                omp_get_thread_num());
            StringCchLength(msgBuf, BUF_SIZE, &cchStringSize);
            WriteConsole(hStdout, msgBuf, cchStringSize, &dwChars, NULL);
        }
        #pragma omp section
        {
            StringCchPrintf(msgBuf, BUF_SIZE, TEXT("セクション3[%d]\n"),
                omp_get_thread_num());
            StringCchLength(msgBuf, BUF_SIZE, &cchStringSize);
            WriteConsole(hStdout, msgBuf, cchStringSize, &dwChars, NULL);
        }
        #pragma omp section
        {
            StringCchPrintf(msgBuf, BUF_SIZE, TEXT("セクション4[%d]\n"),
                omp_get_thread_num());
            StringCchLength(msgBuf, BUF_SIZE, &cchStringSize);
            WriteConsole(hStdout, msgBuf, cchStringSize, &dwChars, NULL);
        }
    }
}
int _tmain(int argc, _TCHAR* argv[])
{
    _tsetlocale(LC_ALL, _T("Japanese_Japan"));
    for (int i = 1; i <= 6; ++i) {
        _tprintf(_T("%d個で呼び出し--------------------\n"), i);
        threadPrint(i);
    }
    return 0;
}

1個で呼び出し--------------------
セクション1[0]
セクション2[0]
セクション3[0]
セクション4[0]
2個で呼び出し--------------------
セクション2[1]
セクション1[0]
セクション4[0]
セクション3[1]
3個で呼び出し--------------------
セクション1[0]
セクション3[2]
セクション2[1]
セクション4[0]
4個で呼び出し--------------------
セクション1[0]
セクション2[1]
セクション3[3]
セクション4[2]
5個で呼び出し--------------------
セクション1[0]
セクション2[1]
セクション3[2]
セクション4[4]
6個で呼び出し--------------------
セクション2[2]
セクション3[4]
セクション1[1]
セクション4[0]

sections ディレクティブを指定すると、コードは section ディレクティブの中に書かれなければならない。ただし、最初の section ディレクティブは、省略が可能。

何回か実行して、スレッドが比較的ばらけた結果を載せた。スレッド数を3個以上にしても、1つのスレッドが全てのセクションを実行することもある。これは、空いているスレッドを使うようなことが行われているためと思われる。なんにしても、どのセクションを何番目に実行させるかは、制御不能。

とっちゃんに質問。PPL では、WriteConsole 関数ではなく、_tprintf 関数が使えると書かれていますね。しかし、実は OpenMP でも、_tprintf 関数は使えます。「スレッドセーフ」という話であれば、POSIX が「全ての関数がスレッドセーフであること」を要求しているので、POSIX に準拠している VC++ は、標準入出力関数はスレッドセーフですから、使っても問題はありません。

そういえば、CRT はソースが付いているので、デバッガーでステップインをすれば追いかけられるな。では、追いかけてみよう。

まず、cout。「[VC をインストールしたディレクトリ]\ctr\src\ostream」の737行目辺りに入ってくる。ここの、748行目あたりの const typename _Myos::sentry _Ok(Ostr); でステップイン。90行目あたりの、sentry クラスのコンストラクターに入ってくる。ベースクラスのコンストラクターにステップイン。70行目あたりの、_Sentry_base クラスのコンストラクターに来る。ここに、「lock the stream buffer, if there」というコメントがある。「_Myostr.rbuf()->_Lock();」にステップイン×２をすると、ファイルが「streambuf」に変わって、171行目辺りにある _Lock メソッドに入る。このメソッドをさらにステップインすると、ファイルが「xmutex.cpp」に変わって、ミューテックスによるロックを使っていることがわかる。

次、wprintf（UNICODE が define されているので）。同じようにステップインをしていくと、ファイル「_file.c」の260行目あたりから定義されている、_lock_file2 関数から EnterCriticalSection 関数を呼び出していることがわかる。

この様に VC++ の CRT は、ロックによってスレッドセーフにしていることがわかる。それなのに、なぜ元にしたコード（このページ）では、WriteConsole 関数を使っているのか、というのが問題です。なお、WriteConsole 関数に潜り込むことは出来ませんでした。threadPrint 関数を次のように修正して、実行してください。


void threadPrint(int num)
{
    #pragma omp parallel num_threads(4)
    {
        _tprintf(TEXT("セクション0[%d]\n"), omp_get_thread_num());
        #pragma omp sections
        {
            #pragma omp section
            _tprintf(TEXT("セクション1[%d]\n"), omp_get_thread_num());
            #pragma omp section
            _tprintf(TEXT("セクション2[%d]\n"), omp_get_thread_num());
            #pragma omp section
            _tprintf(TEXT("セクション3[%d]\n"), omp_get_thread_num());
            #pragma omp section
            _tprintf(TEXT("セクション4[%d]\n"), omp_get_thread_num());
        }
    }
}

「セクション0」は、全てのスレッドで実行されます。次の1～4のセクションを実行するスレッドが問題です。OpenMP では、全てのセクションを単一のスレッドで実行する場合が多くなります。そして、WriteConsole 関数を使うと、各セクションが別々のスレッドで実行される場合が多くなります。PPL では、どうでしょうか。

あっと、WriteConsole 関数のリファレンスに「WriteFile 関数に似た動作をします」と書いてある WriteFile 関数のリファレンスには、「この関数は、同期と非同期両方の操作を想定して設計されています。」と、書かれています。出力をバッファリングして、対象のストリームへ非同期に処理するようです。ということは、「スレッドセーフな関数を使って表示する。 Print the parameter values using thread-safe functions.」というコメントが、ヘン？この「using thread-safe functions.」というのは、「非同期処理」の意かと思われます。

オブジェクトを指向してみる／そもそも「オブジェクト」って、何？

はなおかじった — Sat, 19 Jun 2010 22:29:00 GMT

「オブジェクトを指向してみる／何故インスタンスを作るの？」の続き、ってことで。

元ネタのみながわさんのコラムでは、次のように書かれています。これを考察してみましょう。

実はオブジェクト指向ってしっくりこないんです！（システムエンジニア生き残りの極意）より：

オブジェクト指向は、結局のところホントにモノ（オブジェクト）に使われている記法、例えばGUI コンポーネント、データベース、ファイルなどであって、プログラムのアルゴリズムとは無関係のものである。

ふむ。確かに、「オブジェクト」って、なんでしょう？

引用したところには、「例えば GUI コンポーネント、データベース、ファイルなどであって、プログラムのアルゴリズムとは無関係」と書かれています。これ、「プログラムのアルゴリズムとは無関係」に、強く、興味を持ちました。はたして、無関係なのでしょうか。

とりあえず、この時点では、無関係ではないと思います。

では、“アルゴリズム”って、なんでしょうか。ここから始めましょう。「アルゴリズム：プログラムを作るときに用いる、問題を解決するための手順・計算方法。◇アラビアの数学者アル＝フワリズミにちなむ。もと、算用数字を用いた筆算の意。（明鏡国語辞典）」だそうです。さて、オブジェクト志向は「プログラムの手順」とは関係がないのでしょうか。関係がないとすると、どの様に関係がないのでしょう。

その為にはまず、「オブジェクト志向言語」において、「オブジェクト」とされる物は、いったいなんでしょうか。

私は、「データと、それを扱うための手続きを組み合わせたもの」だと思います。

我々は、現実に発生している問題を解決するために、コンピューターの中に問題を投影し、プログラミング言語等を用いて問題を解決する方法を組み立てます。つまり、「会員名簿の管理」であったり、「勤怠情報の管理」であったり、「写真に写っている人を判別する」であったり、「宇宙船の姿勢を制御する」であったりという問題を解決するためにコンピューターを使います。そこには、「処理するべき情報」が存在しています。そしてその情報には、「処理されるべき手順」が存在しています。この、「処理すべき情報」に対して「処理すべき手順」を見つけ出し、ひとまとまり（パッケージ）にして扱うことが、「オブジェクト指向処理」（勝手用語）だと考えます。

「オブジェクト志向プログラミング」と、「プロセス志向プログラミング」の違いは、何に志向するか、意識や思考を向ける対象にあるのではないでしょうか。プロセス志向では、「為すべきこと」を為す手順に志向します。オブジェクト志向では、「為すべきこと」に関係するオブジェクトに志向します。従って、プロセスに志向しながら、オブジェクトを使うことはできないのではないでしょうか。ただし、オブジェクト志向では、「情報と、その操作手順」がオブジェクトですから、最終的には、プロセスにも志向しなければなりません。

では、なぜ、オブジェクトに志向する、すなわち、情報と、その操作手順をパッケージするのでしょうか。

私が最初にオブジェクト志向言語に触れたのは、当時在籍していた課でオブジェクト志向言語を扱う最初、または2番目の事案でした。そして課長が、こう尋ねました。「オブジェクト志向って、どんなもん？」。まだ触って間もないので、「どう？」と聞かれて困ったのですが、こう返答しました。「メンテナンスがし易いようにするためのものだと思います。最初に時間をかけて設計して、後のメンテナンスが楽になるようにするものだと思います」。この感想は、今でも変わっていません。オブジェクト志向が、情報と情報を扱う手順をパッケージするのは、プログラム（あるいはシステム）のメンテナンスをし易くするためと考えます。

プログラム（あるいはシステム）の「メンテナンス期間」とは、なんでしょうか。ここでは、「最初のリリースが終わってから、プログラム（あるいはシステム）が破棄されるまで」とします。あるいは、「最初のビルドが終わってから…」でも良いかもしれません。

つまり、オブジェクト志向ナントカとは、一度動くようになってから後の仕様変更に対して、如何に対応し易くするかを考えたナントカである、と考えます。

では、どうして、パッケージ化すると、仕様変更に対して対応しやすくなるのでしょうか。

たいていの場合、仕様変更は、扱う情報の変更を伴います。オブジェクト志向分析がなされ、オブジェクト志向設計がなされているなら、変更が起こった情報を特定しやすくなります。また、その情報を扱う方法は、他の情報からは独立しているはずですから、情報処理手順の変更による影響を、他の情報へ伝播させにくくなります。他の情報や、情報処理方法が、他の情報を変更したことによる影響を受けないのなら、修正の範囲は小さくなり、テストの範囲も小さくて済みます。これらの範囲が小さいと言うことは、工数の減少にも繋がります。

実際に、このような設計を行うには、かなりの経験が必要だと思います。しかし、特に Java や .NET Framework では、用意されているフレームワークにあるクラスが、高度に抽象化されています。これによって、使う人がオブジェクトに志向しなくても、オブジェクト志向言語を使ったプログラミングができてしまいます。

「オブジェクト志向言語を使ったプロセス志向プログラミング」と、「オブジェクト志向プログラミング」。この二つは、混同してはいけないと思います。

オブジェクトを指向してみる／何故インスタンスを作るの？

はなおかじった — Fri, 28 May 2010 22:20:00 GMT

実はオブジェクト指向ってしっくりこないんです！（システムエンジニア生き残りの極意）より：

　「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。

　staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。

向こうでコメントしようかと思ったけど、もったいないのでエントリーにする。

さて、コメントに、コラム著者のサイトSE WORLD システムエンジニアの世界 IT技術というサイトへのリンクがありました。そしてそこには、「ASP.NET ASP.NETのサンプルコードです。典型的なコードパターンを列挙してみました」というのがあるので、ここを見ます。…だって、MVP for ASP.NET なんだもん、一応。その中で、これを取り上げてみる。

ファイルアップロードコントロール（SE WORLD システムエンジニアの世界 IT技術）より：
using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
public partial class _Default : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
    }
    protected void Button1_Click(object sender, EventArgs e)
    {
        if (FileUpload1.HasFile) {
            //string strSaveAs = "C:/test/" + FileUpload1.FileName;
            string strSaveAs = "//マシン名/フォルダ名/" + FileUpload1.FileName;
            FileUpload1.SaveAs(strSaveAs);
        }
    }
}
　リモートマシンにも保存できるが、アクセス権がeveryone 書き込みになってないと難しい。ちなみにIIS6.0のASP.NETのプログラムアカウントのデフォルト値はNetwork Serviceです。

センタリングされていて見にくいので、見やすいように修正しました。

さて、この中で、FileUpload1 というのが、FileUpload クラスのインスタンスです。そして、HasFile とか、SaveAs というのは、FileUpload クラスのメンバーです。では、いちいちインスタンス宣言しているので笑ってしまうということなので、インスタンス宣言しなくてもいいように（インスタンスを作らなくてもいいように）、FileUpload クラスのメンバーが全て pubulic static宣言されていると仮定します。つまり、「pubulic static宣言だと、こんなに使いにくいぞ」ということを示すことで、なぜインスタンスを作るのかを理解してみよう、という試みです。

FileUpload クラスのメンバーが全て静的なので、1ページからは1度に1つのファイルしか、アップロードできなくなります。複数のファイルをアップロードしようとすると、FileUpload クラスから導出して、FileUpload1 クラス、FileUpload2 クラス、FileUpload3...と、インスタンスの代わりにクラスを複数作らなければなりません。これは、「コードを書く手間」を考えると、とても不便ではないでしょうか。また、それぞれでクラスが違うのですから、最初に配列を宣言して、インスタンスを作るというわけにもいきません。これも、不便ではないでしょうか。


// 配列を宣言して、インスタンスを生成する
FileUpload[] fileUp = new FileUpload[10];
foreach (FileUpload f in fileUp) {
    f = new FileUpload();
}
// メンバーを静的にすると、上記のように出来ず、
// クラスを10個作らなければならない
class FileUpload01 : FileUpload {};
class FileUpload02 : FileUpload {};
class FileUpload03 : FileUpload {};
...
// その後、配列に登録する。
FileUpload[] fileUp = new FileUpload[10];
fileUp[0] = FileUpload01; おおっと、クラスは登録できないや！！

これで、「static にせずにインスタンスを作るのはなぜ？」の答（のひとつ）になるかな？

それでは、反論も考えてみましょう。

2010年4月28日 (水) 08:53

むしろC言語の構造体はいやになるほど書いたから、逆にビジネスロジックのクラスの優位性についてピンとこないのです。

なるほど。

FileUpload は、データだけを持つ構造体であるとすると、どうなるでしょうか。例えば、こんな定義がどこかにあって、それを使って保存することになります。


public class StaticFunctions {
    private StaticFunctions() {};
    public static void SaveAs(const FileUpload fu, const string saveFileName) {
        // 処理は省略
    }
    public static void SaveAs(const FileStream fs, const string saveFileName) {
        // 処理は省略
    }
    public static void SaveAs(const MyStructure ms, const string saveFileName) {
        // 処理は・・・おおっと、オーバーロードさせてよかった？
    }
}

私は、似て非なる構造体を多数書いたので、クラスの方がいい、と思いましたね。

様々なコメントが付いていますが、このコメントがもっとも秀逸だと思います。

2010年4月27日 (火) 16:14

OOPは理解できないから使わない、と主張されるのは結構だと思います。

しかし、自分が理解できないからといって「知ったかぶってOOPするヤツら笑っちゃう」というような論調で話を進められるのは宜しくないですね。

変数が隠蔽できるか否かはOOPの本質ではないんです。そもそも言語仕様としてクラスやプロパティがあるかどうかも本質ではないのです。言語仕様はよりOOPしやすくするための道具にすぎません。

極意を示すコラムなのですから、OOPを理解したうえで「俺はOOPしない！」と主張する生え抜きのロートルエンジニア（＜良い意味で言っています）が、その経験と技術でもってOOP全盛時代を生き残る方法論を論じる、くらいのレベルの高さがあって欲しいですね。

こんな風に、簡単にまとめられる技量が欲しいです。。。