毎度の事ながら、我々ラダーマンの現地立上げ調整は時間との闘いです。
メカ設計の遅れ、電気設計の遅れ、部材納期の遅れ、メカ組立の遅れ、メカ配管配線の遅れ、メカ調整の遅れ・・・。遅れという遅れがラダーマンの持ち時間を減らします。
ここでぶつけたら一巻の終わり。立会に間に合わなくなる。
追い詰められて普段以上の能力を発揮する人。または、押し潰されてしまう人。
ラダーマンはゴキブリのような人間でないと務まりません。

こんにちはmtjです。

昔からPCを使用していると何度もPCパーツの進化に振れることがあります。

例えばHDDなんかも今や１TBは当たり前、さらには高速のSSDまである状態です。
CPUも今は8コアは当たり前（自分はAMDCPUを主に使用します）

さらにはヒートシンクなども無しで運用可能な低TDPな物も多く出ています。
チップ内蔵グラフィックスも進化していて今やタブレットでもかなりのゲーム、
動画などが視聴可能です。

自分はタブレットよりはデスクトップPCをよく使用します、主に用途はゲームなのですが
動画処理ソフトも使用し、動画処理ソフトはCUDAに対応しているのでGPUにも左右されています。
最近はゲームの方の進化よりもパーツの進化が早いので、20万でも出せばしばらく運用できて
ストレス無く稼働可能な環境が手に入ります。
数年前なら20万でノートPCが手に入る状態です。

用途がゲーム、動画編集しかないので重要なのは基本的にGPUです、なのでCPUはAMDでも
何も問題ありません、処理スコアなどを測定しない限りは気にならない物だと思います。

以前も書いた通り、現在のパーツは低電力、高性能に向っているような気がします。
CPUのコアも倍々に増えているわけでなく落ち着いてきたような感じです。
デスクトップで低消費が進めば、タブレットも高性能になっていき、SSDも安くなれば
ますますタブレットが使いやすくなると思います。

Surface pro3の時も思いましたが、あの小ささでストレス無く動くのには驚きました
発熱量が多いので持っていると熱いですけど。

この先のデスクトップの販売戦略がどうなっていくのかは少し期待している所です。

保守のために自分が10年前に作成したソースコードを読んだのですが、非常に読みづらい。
.NET Frameworkは出始めのバージョン1.1です。

.NET Frameworkの機能も貧弱だったので仕方が無い所もあるものの、名前の付け方や実装の方法が.NETの作法から外れていたり古くさかったり、残念なソースコードになっていました。

10年の間に.NETも自分も成長したのだと、ポジティブに考えることにします。

C#7の新機能の話です。

言語レベルでタプルに対応するそうです。なお、System.Tupleとは関係がありません。
ざっくり言うと、メソッドの引数や戻り値、プロパティの型などに匿名型が使える様になります。

System.Tupleを使った場合も汎用の型として同様のことが行えますが、System.TupleはメンバへのアクセスがItem1やItem2のようにメンバの意味が分かる名称で無いため、可読性が悪くあまり使いたい機能では無かったです。

タプルを使用した戻り値は以下のようなコードになります。

public (int sum, int count) Tally(IEnumerable values) { … }

var t = Tally(myValues);
Console.WriteLine($”Sum: {t.sum}, count: {t.count}”);

Tallyメソッドの戻り値がsumとcountの2つになっています。
引数と同じように括弧で囲って複数記載できるようになっています。

Tallyメソッドの呼び出し側は、戻り値を変数tに代入しています。
tは、sumとcountメンバを持つ匿名メソッドのようになっています。

この機能追加によって、out引数を使用したり、戻り値専用に一時格納用クラスを定義する必要がなくなり、シンプルで可読性の高い実装になりそうです。

こんにちはMTJです。

現在装置に依存しているソフトを作成しています。
装置のライブラリを使い装置のデータを取得するというものです、
タイトルにも書きましたがこれの危険なところは装置が本当にどういう動作をするかわからないところ

戻ってくるデータは仮想的に作れますが、装置の動きは予想して作れません、
こういう事もありました。
・装置がある動作をしたときに装置の状態を調べる関数をPCから送る。
上記の動作をさせた時に装置が操作不能になることがありました。

装置のメーカーに問い合わせたところその関数は装置内部に問い合わせを行っており
操作が被ることで操作不能になるかもしれないとのことでした。

この問題が何で発生しているか特定するのも大変でしたが、問題はどちらもエラーも発生せずに
動いていることでさらに特定が難しくなっていました。

装置依存のソフトを作成する場合は、この関数は装置の内部に何か操作を要求しそうか
など考えながら作成したほうが時間を取られずに済むのかと思いました。