二人目が生まれたわぁ

つぶやき

無事に、二人目が生まれましたー
上の子はあと少しで3歳、トイレがまだ難しい感じ。
子育てが落ち着くまでまだ、数年かかりそうですねぇ。
ゲームが積まれていくわけですｗ


真かまいたちの夜、Wiiゼルダ、マリオカート7、ファイヤーエムブレム・・・
3DSはテレビを占有しないからできそうなもんですが、子供がいる前でやると、3DS自体を盗られる罠がｗ
結果的に子供が寝た後しかできないわけですがー


子供を寝かす＝電気消して隣で寝る＝自分も寝てる罠


子供が大きくなるのを待つしかないわけですね、ハイ。
あぁ、でも6月はカルドセプトがー
Diablo3は我慢したんだけど、カルドセプトは予約してあるから届くのね。
・・・Diablo3我慢ってのは、単にバージョンが落ち着くのを待っているだけかもしれないｗ


しかたがないので、某電卓プログラムの間違い探しで遊ぶわけですが、すぐ終わってしまうのが難点ですねｗｗｗ

IT系って凄いな

つぶやき

http://el.jibun.atmarkit.co.jp/ahf/2011/12/post-34b1.html#comments


ここのコメントでさらっとでてますがー


「1000万円ぐらいの小規模のシステム」


小規模なのか・・・しかも最低金額なのか・・・
人数や納期ってどれぐらいなんだろう？


中小企業だと、その金額は大きな仕事ですねぇ。
まぁ、会社規模によってピンキリでしょうが(^^;
前の会社だと、自分が担当した中で高かったのはライン制御とかでー300万前後かなぁ。
一人で作って２、３ヶ月ぐらいだから、そんなものかなぁ。


再就職するときに、応募したIT系の会社は毎日遅くまで明かりがついていました。
今の会社は定時で帰れてます。
同じソフト業界なのに、大分違うのが面白いですねぇ。

不思議な世界２

つぶやき

続きー
あっ、いや、本当に困るんだけど(^^;


>勝手に意見を変えられても困りますので書かさせて頂きます。


まぁ、それを言いたいのは周りのほうでして・・・私だけじゃないよね、そう思ってるの(^^;


>過去の資産やお客様を持っていない技術者なんて新人以外いません。


派遣が多い業界なら、お客もってない人も結構いるんじゃないの？
この場合のお客ってのはエンドユーザーなんだけど・・・


>前にも言いましたが、新OSが発売されるからと言って、無理やり全てのOSを新OSへ変更するようにも言うなんて事あり得ません。


誰も既存のシステムを入れ替えるなんて話はしていないんだが・・・
新しいPC買うとOSも新しくなってしまって困るって話、既存システムがそのPCだけ動かないとか、そういう例。
こー連想することが私にとっては、非現実的なんだよなぁ。


>>逆に営業的に競争相手を持たない技術者には、新しい標準に合わせる必要がな
>>い。
>>むしろ、新しい標準など生まれなければ、安定した供給ができると考える。
>>それでも進化しないわけじゃない、緩やかに進化していく。
>そんな技術者いないと思いますが・・・


進化するってのは新しい技術を緩やかに導入しているってことと等価だよ。
それにね、標準が頻繁にかわったら困るの、変わらなくてもいい標準もあるの、場合によっては必要悪ってのもある。
TABの話とかはそういう例。
むしろ、批判されるべき「新しいものを望んでいない」人の代表としてピックアップしたのだが・・・
これ、唯一最大の擁護だったんだけどなぁ(^^;


>Winduws8も表示を切り替えられます。


だから、Windows8の話はしてないってｗ
そして、そういう考慮も必要だっていう話であり、互換性の重要性を語っているんだって・・・


>いいえ。サーバー系ソフトウェアではかなり普及していると思います。


あっ、いや・・・クライアントOSの話をしているつもりだし、ソフトもクライアントの話だったんだが・・・
今サーバーってWindowsの普及率どれぐらいなんだろう？
まだ少ないと思っていたんだけど、結構かわってるのかな？


>人を子馬鹿にした口調は止めてほしいです。


えっ？


>IT業界の事を知らずに、勝手な決め付けで馬鹿にした言動をするのは頂けません。


えぇ？


>知りもしないで勝手に見下さないでください。


えぇぇぇぇｗ
そこのコメントを上からしたまでみて、誰が一番人を馬鹿にしているか見直してみてよｗ
そして、決め付けているのは誰かもｗ
こーたのむから客観的な視点というか、他人からみた自分を想像してくれ・・・


>IT業界の人間が読む＠ITがこういったコメントを許すのは非常に問題があると思います。


警告メールをもらってるのは、貴方。
私にはそのような警告は一切ない、おそらく他の人にもないと思う・・・
どちらが問題なのかは、誰にでも判断できること・・・だと思うんだが・・・
編集部にも誤解ですとかメールだしてるんだろうか(^^;
編集部が、警告メールを出した相手や出した事実を表に出さないのは、出される人を考慮してのことですよねぇ。
コラムニストであるAhfさんも、迷惑だと思ってるから一言だしたわけで・・・
個人的には、スルーしてくれというお願いだと思うし、周りの感情を鎮める目的も強かったと思う。
それに対し、


>「変化が怖い」と泣き叫ぶ子供に何を言っても無駄だと思いますので休みます。


台無しｗ
こういう余分な一言が、駄目。
追伸は、いれる気なかったんだけど・・・私から周りの人へのお願いを追加。
悪者は私一人でいいので・・・裏の状況も公開ね、もうそこまで配慮する必要を感じないからさ。


ところで・・・彼は私をどういう職業でどれぐらいの経歴があると思っているのだろうか？
私は、自分の仕事がIT系ではないと感覚的に思っているだけで、世間からみた職業分類は気にしていないだけなんだけど・・・
IT系ってさ、はじめはOA(Office automation)の一部しかなかったような気がするんだけど、今OAなんて言わなくなってますよね？
こーいまだとソフト産業全般をITといっているようなー
私にとってITって言葉は、後から言われるようになったもので、なじみがないんですよねぇ。

不思議な世界

つぶやき

http://el.jibun.atmarkit.co.jp/ahf/2011/09/post-f086.html

なんだろう、そんなに誤読させてしまうような文章だったとは思えないんだけど・・・
まぁ、いつものことですかね、書いてないことを元にむちゃくちゃ言われるのは(^^;;;;


少なくとも私は、「新しいものを望んでいない」とは言っていないし、主張もしてない。
ましてやマイクロソフトを批判などしてないｗ
「新しいものを望んでいない」は「こう考えるんじゃないの？」そして、「そう考えるのもしかたがないんじゃね？」と語ってるだけなんだが・・・
わかりやすい例としてあげた話がまったくといっていいほど通じなかったのが、わりと泣けた。
なにがいけないのかなぁ、長文だからちゃんと読んでもらえないの？ｗ


>誰もWindows8やマイクロソフトの批判などはしていない場所で、そう力説されても場違いのような気もしますが・・・

誰もしてないのよ、Windows8の話は、「「新しいものを望んでいない」という意見」がでたきっかけであって、本筋でないんだから・・・
新しいOSに興味がない人がいるって話の例でWindowsを使っているからといってマイクロソフトの批判なんかしてないのよ。


>>多くの人が、新OSが出る時に既存のセキュリティ問題が解決されている点を重視していないようですね。
>PCの準備まで行う会社は多いと思うので、そこは重視されないと思うのですが・・・

その時点までのアップデートなどはお客がしなくても、ソフトを販売する会社が準備段階で行うから初期段階の状態は、関係ないって主張です。
OSレベルのセキュリティ・・・なにをいいたいんだろう？
UACとかのことだろうか・・・いやでも、それセキュリティ問題っていうのかなぁ・・・
セキュリティ問題って聞くとセキュリティホールとか想像するんだけど(^^;
仮にUACのような新しい機能のことだったとしても、その内容についてその前にしているから、違う・・・よね？(^^;
「VB6ランタイムがセキュリティホールになる」という都市伝説のようなものが飛び出すぐらいだから、具体的になんのこといってるのか本当にわからない(^^;


・・・で、話戻すけど・・・PCの準備ってソフト会社でやることないのかな？＞IT系


>>互換性問題についてはHyper-Vを搭載する事により解決を狙っています。
>これも・・・先のセキュリティを重視することと矛盾しているような気もしますが・・・


これは、悪い冗談なのか、本気でそう考えてるのか、わからなかった。
Hyper-Vで互換性問題を解決するってことは、古いOSを入れるってことで・・・
新しいOSでセキュリティを重視して、古いOSを動かしていたら、意味がないですよね？
影響がでるのは仮想環境だけーってことなら、古いOSでも仮想環境作ればいいだけで(^^;


UACに関しても、望まれた機能のはずに不評だったという、もっともわかりやすい例としてあげたつもりなのに・・・
「なかったのがおかしいぐらい」とまで私がいってるのに(^^;
なぜWindowsを批判したことになってるのか、本気でわからん(^^;;;;


でもって、UACのおかげで動作しなくなるプログラムがあるのは当たり前ですよね？
だって、UACなんて機能がない時代のプログラムなんだから・・・
セキュリティについて、真面目に考えるもなにも、そんな機能が付くこともわからない時代のプログラムにいっても結果論でしかないわけで・・・
UACというものが発表され、仕様がわかった時点で対応するしかないですよねぇ。
前提が未来予想すぎて・・・


>>とはいえ、今時の業務システムでモバイル非対応の方が珍しいです。
>ほーそうなんですか。
>つまり、多くのIT系開発は既にモバイル対応しているということですね。


ここ、私の中では凄い単純な矛盾を感じたんですけど・・・
既にモバイル対応しているってことは、そういう開発環境が揃っているということですよね？


>>モバイル用OSと非モバイル用OSを両方維持するコストを考えると、統合するのは当たり前の経営判断です。
>あれ？じゃー今までのモバイル対応はどうするんですか？


新規でモバイル環境を揃える場合は、統合されているほうが良いということは理解できる。
でも、既に別の開発環境がある場合、それを捨てない限り、古い環境と新しい環境の２つを維持する必要がでる。
さらに言えば、Windows8対応のハードが登場しないと新しい環境で作られたソフトは使えない。
どう考えても、２つの環境が必要であり、コスト面のメリットはそこには存在しない。


つまり、モバイル開発を既におこなっているはずのIT系において、コスト面のメリットはまだ存在していないと思うのですよ。
Windows8搭載のモバイルハードがどれぐらい作られ、どれぐらい普及するかわからない時点で、その環境でしか動作しないとわかっている開発環境・・・ギャンブルだと思うんだけどなぁ。


そもそも、モバイル環境ってハード依存しないようにブラウザベースで動くようなものじゃないんですか？
それともそのモバイルハードのネイティブアプリを作ることのほうが多いの？
iアプリとか、iPhoneアプリとか、アンドロイドアプリが主流なの？


>最大のポイントであるARM対応はさすがに驚いた人も多いのではないかと(^^;


私は驚いたほうなんだけどなぁ。
Intelとの関係もあるし、ハード的な問題で、本当にWindowsが動くパワーがあるのかとか・・・
x86以外のWindowsで成功したもの・・・あったっけ？
Windows Phoneも決して成功してないですよね？
ARM対応って障害のほうが多いじゃないですかｗ
・・・あっ、「ARM？なにソレ？」ってな人のほうが多いと、驚くこともないのか(^^;


あぁ、あとAeroの話だけど・・・Vistaの時に「オーバーレイ」方式の動画再生ソフトって全滅しましたよね？
新しい機能のために動かないソフトの代表みたいなものだと思ってるんだけど・・・
こーフリップ 3Dのせいで、「そんな機能いらないから動画再生させろ」ってな意見は結構あったような・・・


・・・あっ、これも「Aero？なにソレ？」ってな人のほうが多いのか？ｗ

ＰＳ．
あぁ、トラックバックにでもすればいいなと思ってたけど、@ITに見当たらなかった・・・
コメントするのもアレだし・・・まぁ、いいか・・・

猿にはわからない論理演算と条件演算の話

技術

.NETになって、論理演算子とビット演算子の違いって意識されなくなってるのかなと(^^;
if文に使われるのは、論理演算子が主流だと思っていたのですが・・・ビット演算子を使う人もいるのね。
正直なとこ、if文などにビット演算子を使う利点がみえないのですよ。
Delphiをやってた人だと、もともと区別がないようなので、なんで２つに分かれているのかとか思うのかもしれませんがｗ
私の場合、Delphiを後からみたので、なんで１つで区別できているのか？とか思ったりしたのですがねｗ
よくよく考えると、区別は明確だったりしたので、C#も同じなのかと思ったのですが・・・
同じだったら２つに分かれているわけもなくｗ


まぁ、区別しなくても同じような感じで動作はするし・・・
.NETのif文はbool値しか許されていないので、なにが違うのかわからない人もいるのかなと・・・
C#だとーC言語でいうビット演算子が論理AND(&)、論理OR(|)という名称ですねぇ。
でもって、論理演算子が条件AND(&&)、条件OR(||)という名称ですか・・・
わかりやすいような、誤解を生みやすいような(^^;;;;


C#での論理演算と条件演算の違いは以下のようなプログラムではっきりわかります。

namespace ortest
{
    class Program
    {
        static void Main(string[] args)
        {
            if (RetTrue() | RetFalse())
            {
                Console.WriteLine("IFの中・・・");
            }
            else
            {
                Console.WriteLine("なんとか出られたな");
            }
        }
        static bool RetTrue()
        {
            Console.WriteLine("Trueだよ");
            return true;
        }
        static bool RetFalse()
        {
            Console.WriteLine("Falseだよ");
            return false;
        }
    }
}

これは論理演算の例です。
デバッグ実行で、if文の部分をステップして追いかけてみてください。
RetTrue()を実行した後にRetFalse()を実行しているはずです。
次に、「 if (RetTrue() | RetFalse())」を 「if (RetTrue() || RetFalse())」のように条件演算に変えて同じことをしてください。
今度は、RetTrue()を実行した後にif文の中に入ってしまいRetFalse()を実行しなかったはずです。


これが２つの明確な違いです。
論理演算は足し算や引き算のような計算なので、式全てを参照しなくてはいけません。
この場合、RetTrue()の結果とRetFalse()の結果を計算する必要があるので、両方が実行されるわけです。


それに対し、条件演算は演算ではあるのですが、答えが確定した時点で処理を打ち切ります。
この場合、RetTrue()の結果で式全体の値がtrueと確定するのでRetFalse()を実行しなくてもいいわけです。


これを応用するとー

if ((i==0) | (x/i==0))

論理演算だとiが0の場合、条件を満たしているのにもかかわらず、x/iを実行して０割り算が発生してしまう。
そのため別の方法を考えなくてはいけないのですがー地味に面倒ですねｗ
ところが、

if ((i==0) || (x/i==0))

条件演算ではi==0で式が確定するので、x/iを実行せずに０割り算が発生しないわけです。
先のサンプルプログラムのように、無駄な処理を行ってしまうこともあるわけでー
わりと特殊な条件でもない限り条件演算を使うほうが良い・・・
というかif文で論理演算使うのは、基本的には間違ってることのほうが多いんじゃね？と思うわけですｗ

イロイロあったわさ

つぶやき

いやーイロイロあったんですがーやっと落ち着いてきました。
ある程度の年齢になると転職って結構必死になりますね(^^;
わからないことも多かったので職安にいって相談しました。
職員さんは親切丁寧にイロイロ教えて下さいました、いまー真面目に助かりました。


田舎に住んでるので、再び、プログラム関係の仕事に就けるのは絶望的だと思ってました。
いや、派遣の仕事は結構あるみたいなんですが・・・
MFCメインでやってきて.NETやデータベースに触れていないロートルには厳しいですねぇ。
派遣以外、そして自分でもやれそうなとこ・・・絞られます(^^;
そして、年齢、これが自分にとっては一番の敵ｗ


不利な条件のほうが多いわけですが、それならいっそ全然違うジャンルでもいいのかと。
私の未体験なIT関係＋αみたいなとこと、私の好きそうなハードよりのとこ２つを候補に。
IT関係＋αなとこはドライバ開発とかもあったので、そこを狙ったんですが・・・
ドライバ開発は殆どやってないそうな(^^;
そのほか、応募にあるような内容で私が活躍できそうなものは、今はほとんどやっていないとｗ
うん、わかるよ、イロイロなことやってるってアピールするために、少しでも実績があるものは載せるよね(^^;


まぁ、面接では、「.NETの経験がないと駄目」とあっさり(^^;
その程度のことならすぐに対応できる自信はあるのですが、中途採用に求められるのはやはり経験なわけで、自己申告の自信はなんの説得力もありません。
また、年齢もネックになるのかなと、聞いてみたんですが・・・
戦力になるなら年齢は、よほど高齢ではない限り、大丈夫みたいでした。


もう１つの候補は、先のとことはまったく逆というか・・・
ほんの少ししか書いてなかった部分がメインで、それが今まで私のやってきた仕事に果てしなく近いものだったんですよｗ
先の件もあるので、自分から、.NETの開発経験が殆どないこと、チーム開発の経験がないこと、などを説明しました。
面接担当は、「あぁ、すぐに覚えれるでしょ？問題ないよ」と・・・。
あぁ、判ってくれる人がいた、凄くうれしかった。
結局こちらの会社は、私の経験を買ってくれ、採用していただけました。


まぁ、就職して即仕事があって、今も継続していますが・・・
.NETといえばC#だと思っていたし、実際にC#も使っていますが・・・
Delphiまでやるとは思わなかったｗ
やっぱり、構文を大まかに理解するのは、そんなに時間はかかりませんね。
覚えるのには時間がかかりますが、理解するのは１時間もかからないでしょう。
どちらかといえば、.NETはどこまでの機能があるのか？ってのを探るのに時間がかかるｗ
TIPSをまとめたページなどはありがたいですねぇ。
こーMFCやC++でのやり方はわかるんだけど、.NET流だとどういう風になるのか？ってのはマニュアルだけでは到達しにくいんですよねぇ。
そんなときに、ピンポイントのサンプルがあると、一気に理解が進むわけで(^^;


まぁ、逆に間違ったことが書かれていると、ものすごく混乱するという(^^;;;;;;

猿にはわからないcoutの話

技術

「coutがスレッドセーフでは無い」という主張がネット上に存在します。
これ、一人だけじゃなくて、複数なんですねぇ(^^;
@ITにもあるんだよなぁ・・・


C++の言語仕様の詳細は不明ですが、スレッドは実行環境依存です。
そのため、言語仕様としてスレッドに関することは決められていないのだと思います。
これ、決められるのは、実行環境までも仕様として決められている言語だけですよねぇ。


http://blogs.wankuma.com/jitta/archive/2010/03/12/187030.aspx


似たような話がJittaさんのとこにあったのを思い出しました。
ここで、aetosさんが確認していたことは、そういうことではないかと思います。
コメントの最後でなぜ？さんが説明していますね。


元記事はVC++ですから、coutがスレッドセーフなのは確定です。
いや・・・大抵の場合はスレッドセーフなライブラリが用意されているんだと思うんですが(^^;
理由は簡単、もしcoutがスレッドセーフじゃなかった場合、同時にcoutが呼ばれるようなコードはNGです。
にもかかわらず、coutが普通に使われているサンプルが多数あるってことは、暗黙の内に安全であることを前提にしているわけです。


じゃーなんで「coutはスレッドセーフでは無い」という誤解が生まれるのか？
私の想像でしかありませんが、coutが便利で自然に使いすぎた結果、coutが特別なものとして見えているのではないかと。
例えば２つのスレッドがあり、

//スレッド１の出力
cout << "AAAA" << "BBBB" << endl;

・・・・・・・

//スレッド２の出力
cout << "CCCC" << "DDDD" << endl;

だったとします。
おそらく、期待する表示は

AAAABBBB
CCCCDDDD

もしくは

CCCCDDDD
AAAABBBB

だと思いますが・・・そうは表示されない場合があるわけで・・・

AAAACCCCBBBBDDDD

だったり

AAAABBBBCCCC
DDDD

このような結果をみて「coutはスレッドセーフでは無い」と判断するのではないかと。
同時に呼ばれる場合でも、

//スレッド１の出力
cout << "AAAA";

・・・・・・・

//スレッド２の出力
cout << "BBBB";

このように改行もせずに１つだけ出力する場合は、期待通りの結果が表示されるはずです。
これはなぜか？
coutに対する「<<」が鍵を握っています。
私自身、coutはほとんどつかったことがなく、あまり気にしていなかったことでもあったのですがー
επιστημηさんがCodeZineのコメントで

>cout << a << b << c; 
>は
> print(a);
> print(b);
> print(c);
> とかやんのと同じこと。

と説明していただいたのを見た時には、C++のテンプレートかなにかの特殊書式なのかなーとか思ったりしてましたｗ
今回改めてそんな書式があるのか、確認してみましたがーまーないですねｗ
あるのは、「シフト演算子」だけですねぇ・・・って、ソレか！


そうか、これはただの「シフト演算子」だったのかとｗ
C++の「オーバーロード」により動作が変更されているだけだったのかと。
でもって、演算結果としてcoutになるなら、次々と処理されていくわけですねぇ。
通りでintやら文字列やらを区別なく処理できるわけだ、それぞれの型に合わせて用意されていればいいわけです。
なるほど、「<<」を複数使うとcoutを続けて呼んでいるということは納得できました。
この考えが正しければ、coutに対する操作として「<<」で一区切り付いていることになります。


ここで、coutの動作をもう一度見直して見ます。
coutが画面に表示するタイミングはいつでしょう？
まぁ、特には決まっていないのでしょうけど、少なくともなにか特定の処理をしない限り画面に表示しないという仕様ではないですね。
coutがバッファを持っていて、使用者の明確な指示無しでは画面に表示しないという仕様だったならー
複数回に分かれてcoutを操作したとしても、初めに期待した表示にならなければいけなかったでしょうねぇ。
スレッドごとにバッファを管理することで実現できたことでしょう。


ところが、実際のcoutはそのような特定の処理がなくても画面に表示してしまいます。
「coutはスレッドセーフでは無い」と考えている方々は、この動作の矛盾をどのように考えるのでしょうか？
coutは一度しか操作されていないと考えるのか、coutの仕様が違うと考えるのかのどちらかではないでしょうか？


個人的にスレッドセーフとは、同じ関数なり操作を同時に行っても、動作が保障されている状態だと考えています。
仮に最初の２つのスレッド例の結果で

ACACACACBDBDBDBD

のような結果が表示されたとしても、動作が保障されているのであればスレッドセーフだと思います。
ただ・・・実際に上記のような表示になったらcoutを使うのは難しいでしょうがｗ


結局、スレッドセーフなものでも使い方によっては期待した動作をしないわけで・・・
期待した動作をしないからスレッドセーフでは無いと言ってしまうのは違うのではないかと思うわけです。
例えば、自前のバッファ（stringstreamなどですかね？）に出力するデータをためておいてからcoutで出力すれば期待通りに動作するのではないでしょうか？


まぁ、ここまで書いておいてアレですがー
coutなんて出力先がシステムで共有されたものじゃないですか。
そのcoutがスレッドセーフじゃなかったら使い物にならないって考えるのが普通じゃないですかね？ｗ