えー、C#と、英語しか情報がない AForge.NET （なんと読むのだ？アフォゲ ドット ネット？）というのを使って、画像キャプチャに挑戦してみた。

結論。超かんたん。

しかし、使いこなすには英語のドキュメントを読めるのが条件になりそう。
ちょっと凝った事をしようとすると、ちょっとしんどい。

とりあえず、USBカメラを使って得た映像からスナップショットを取ってbmpにして保存するのは、どこにでも転がっているサンプルだけで間に合う。

C#ならば、jpgに変換して保存というのも超かんたんだった。笑っちまうほど。

特定のUSBカメラを指定したり、サイズを指定したり、そういうのにはひとひねり必要なようです。
モニカー(Moniker)って、調べてもロクに出てきませんな。

この複雑怪奇な処理をC++とかでやっている人の事を、とても尊敬するなぁ。
MSの技術情報は、なぜか大抵あてにならない。そう思っているのは俺だけなんだろうか？？？

サービス終了してしまったMicrosoft のTechNet サブスクリプションですが、
残念だなぁ。

なんだかんだで、一番私のような中途半端プログラマには心地よいサービスだったのに。
MSDNなんか、中小企業どころか極小企業のうちのような会社では入れないよ。

アクションパック サブスクリプション は、… … … …

ちょっと使えない。

Ｗｉｎｄｏｗ8以降しかラインナップがないのは非常に不満。
過去のＯＳを切り捨てるＭＳの経営姿勢がよく見えます。

微妙にライセンスも変えられてるみたいで、ちょっと窮屈な感じです。嫌です。

なんだかんだ言って、ＯＳはＭＳ一択の時代が長かったし、資産的にもＭＳでという流れがあったけど、自ら過去の資産を切り捨てる戦略ならば、もうプラットフォームはLinuxでもアンドロイドでも、何でもいいよね。

個人的にはアップルという選択肢は無いと思ってるので、色々なソフトがＭＳ以外で動く/提供されるなら、そっちへ移行でいいんじゃないかと。

Visual Studio 無償化するなら、過去のＯＳも無償にするとか、ちょっとお金払ってもいいから研究開発用には残しておいて欲しいものだ。

大体、うちの場合は MS-Access （97）が現役という客先が多いので、アクションパックほんとつかえねー。
動いてるのもＸＰ上だったりするので、古いＯＳが使えないと開発（というか、メンテと改良）なんかできねーYo!

そりゃ、新ＯＳに移行してＯｆｆｉｃｅも新しいのにすればいいんだけど、同意してくれる客なんて、本当にいないのは、もう笑うしかない。

田舎なんてそんなもんだ。ちゃんと動いてるものになんでカネかけないとダメなの？　壊れたら直して使えばいいんだ。的な古きよき中小企業の正しい姿。

明治時代の機械が現役で動いてたりする会社を相手に、ＭＳの都合が通るはずもない。

顧客の立場にたつつもりが少しでもＭＳにあるのなら、こういう切捨て方は本当にやめて欲しいものです。

レガシー資産は無償公開するぐらいの度量は欲しいよね。ほんとに。

64bit化して久しいWindowsですが、
やっぱりというか、未だにとしうか、そりゃそうだな問題が出ています。

なぜかOffice製品は64bit環境でも、32bit版がデフォルトらしい。
コンパイル時に気をつけないと64bitプログラムでコンパイルされてしまい、接続できない

避けられないのでどうしようもないですが、なぜかMSはWOW64を推奨のご様子。

くわしくはこちらを。

なかなかめんどくさいですね。
ミドルウェアで吸収してくれたらいいのに。

ｃ＃での非同期処理について調べているが、なんというか、カオス。
c# というか　.net　では、様々な非同期処理があって、ただでさえ複雑な非同期処理の習得を、余計に難しくしていると感じる。
バージョンがあがる毎に、おそらくは、より便利な使い方を追求して、違う方法で非同期を処理する方法が考案・実装されていって、しかもそれがずっと残ったまま次の方法が追加されていくので、結局使う方がどれを選択したらいいのかわからなくなってしまうという感じ。

最新は　async/await という方法だが、これはその前に考案されたTaskクラスをラップ・発展させたような感じらしく、結局Taskの振る舞いとそのラップ構造を理解していないと使えないっぽい。というのが、これまでの感想。まださわりしか理解していないので、間違っているかもしれないが…

また、例にラムダ式が使われているのがなぜか多く、c#をあまり使っていない初心者としては、まずそこから理解できない。
デリゲートも、関数ポインタと言われると、まぁわからんでもないけど、これほど多用される理由がよくわからない。普通に関数で処理できる部分まで無理にデリゲートにせんでもええと思うけどなぁ。どうしてもデリゲートでないとならないなどと言う部分がそんなに多いとも思えない。ラムダ式も同様。
ポインタの悪の部分をなくすために存在しているはずなのに、デリゲートを理解するのにポインタの知識が必要などと言うところが、もはや悪いループに入り込んでいるように思えてならない。概念をよくわからずに使用するプログラマが多いのかと思うと、なんだか悲しい気持ちになる。こういうのをもてはやして”成果だ”として多用するのは、マイクロソフトの悪い癖だと思う。
「何でもできる は 何もできない と同じ」などという格言もある。無名関数ではダメなの？LINQから発展・拡張したという経緯を差し引いても(いや、そう思っているだけで違うかもしれないけれど)、C#の構文にいきなり毛色の違いすぎるラムダ式が登場する違和感について、誰も何も言わなかったのだろうか？本当にこれが登場したおかげで便利になったの？？簡単な説明だけで、いきなり

 Func < int ,bool > method = (year) =>
  year < 1994 ? year % 4 == 0 : year % 4 == 2;

なんて式を例に出されても、理解できないってーの。
うるう年を解くコードなのは理解できてますよ、念のため言っておくけど。
ていうか、このコード間違ってない？
100で割れる年と400で割れる年の処理抜けてるよね？？
まぁそれは、ここではどうでもいい。

コード量は少なくなったかもだけど、本当に便利になったとは思えないなぁ。特に他言語から来た場合、非常にとまどうと思う。
WPFがイマイチ普及しないのと同じ事を、ここでもやってしまっていると思うのは私だけだろうか？

やっぱり愚痴になってしまった。
勉強して、理解して、結局使うのはちょっとだけ…無駄な時間ばかり掛かって、実際のコードを組む時間に悪い影響が出るこのループ。
理解してまえば早いのかもしれないが、一度使ってまた次にｃ＃を使う事がそんなに多いとも思えない。私の場合。

いい加減、21世紀に入ってもう長いのだから、概念も方式も実装も、もっとシンプルにして欲しいものだと、切に願う。

仕事の関係で色々調べているのだが、カード専用プリンタというのが世の中には存在する。
クレジットカードサイズのカードに、写真とか名前とか会員番号とか、そういうのを印刷するプリンター。
業務用で、結構な値段がする。

(続きを読む)