サービス終了してしまった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世紀に入ってもう長いのだから、概念も方式も実装も、もっとシンプルにして欲しいものだと、切に願う。

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

(続きを読む)

サブルーチンを作っていて、
呼び出し元に処理を返すのではなく、その場でプログラムを終わらせたい時、
どうすればいいのか？ どういう処理が選択できるか？
という質問のスレッド。

なぜかVBではそういう質問をすると怒られたり、Exit Sub 使えとか言われたりするようです。
しかし、当然 Exit Sub では呼び出し元に処理が戻ります。

で、たとえば強制終了するには

End '強制終了

というコードがあります。
なぜか MS Access VBA の質問スレッドでこれを答えた人は誰もいませんでした。

もちろん、他の処理でも別にいいと思いますが、
Err.Raise を使うとか(Resume したら意味ないですが…)

やれ、「処理の内容を見ないと…」とか、「Exit Sub です…」とか、
はては 「goto を使うのは邪道」というのまで出てきて、
きっと初心者であろう質問者の本質に答えられる人は、そこにはいなかったように思われます。

いつも思うのですが、QAスレッドで「マニュアル読め」とか、「FAQを読み返せ」とか、「出直して来い」とか言う人々、
きっと技術力無いんじゃないかと思うのです。
そんな風に敵意を出すぐらいなら、黙ってる方がまともだと思います。
人間として、社会人として、技術者として、どれも3流か4流、あるいはそれ以下だと思います。

もちろん、質問者の意図を汲み取ってすばらしい回答を答えている立派な人もいますが、どうも少数派に思えます。

幸いな事に、昔の私は良い先輩に恵まれて本当に丁寧に色々教えてもらいました。
調べ方すら知らなかった私に「そんな事ぐらい勉強してから質問したら…」みたいな事を言う人は居なかった。
どこをどう調べるのか、調べ方から教えてくれた事に、本当に感謝しています。

自分の質問が見当はずれなのがどうかもわからなかったり、どう質問したらいいのかわからない人もいます。
どこを調べればいいのかもわからない、なんてことは、プログラマならきっと経験した事があるはずです。

そういう人をいじめて、優越感に浸るような人間にだけは、なりたくないな。

グチも文句も多い私が言うのもなんですが、そういう風に思います。