DDD

DDD(Domain-Driven Design) を勉強しています。
解決すべき問題をドメインとして捉え、
それをドメイン固有のルールなどと共にプログラムに表現していく手法です。

DDDではEntityやValue Objectなどの概念が出てきます。
C#でValue Objectを表現しようとした場合、classかstructか悩みました。
結局classで表現することに決めたのですが、
structはデフォルトコンストラクタを定義できない事が最大の理由です。
例えば正の整数を保証する為に、以下のような事ができれば、
structの利用の幅が広がるのですが実際にはできません。

struct MyStruct {
private readonly int _value;
MyStruct() { //このコンストラクタは定義できない。
throw new Exception();
}
MyStruct(int value) {
if (value <= 0) throw new ArgumentException("0以下の値は設定できません。");
_value = value;
}
…(略)…
}

Value Objectをclassで表現した場合、
中身の値は保証できても、使う側はオブジェクト自体のnullチェックが必要となります。
structの使いどころって、なかなかな無いものです。

VPN接続

先月から常にテレワークになったので、社内プライベートネットワークにVPN接続できるようにしました。

今までは必要なときだけ社内PCにTeamViewerでつないでいましたが、VPNのほうが何でもできて便利ですね。

今までVPNをよく分かっていなかったのでVPN接続出来るようにしてなかったのですが、もっと早くから使っておけば良かったと思ったのと、自分のよく分かっていない技術について知ろうとしなかったことを技術者として情けなく思いました。

プログラムの勉強

こんにちはmtjです。

今までいろんな人を見てきてプログラムの勉強について思う事があったので書きます。

よくいるパターンがネット、本等で用語等を読み 実際に開発環境を作って何も作ったことが無い人。
一度でもプログラムを作ったことがある人ならば別の言語の本を読み経験で別の言語を書く事は可能でしょう。

しかし、初心者は一度プログラムを打ってみてほしい、自分で考えて本で読んだ知識を使いながら作ってみてほしい

なぜならプログラムは道具だからです、何かを作るために使う物で本はただそれを上手に使える方法を書いてあるだけです。
何もしないのに工具箱を買ってこないのと一緒で何かをするためにプログラムは存在するのでまず手を付けて欲しいです。

またプログラムには答えがありません、結果が同じになるコードは1つではありません。
結果が同じであれど実行速度が速いコード、読みやすいコード、容量が小さいコード等様々なコードがあります

経験、知識が浅い間はかなりの確率で汚いコードしか書けません、そういうものです。
書いた後になんとか綺麗にするための知識を補完するのが本です。

まずはプログラムは書いて覚えましょう。

柔軟な発想

ある機能をプログラムで実現する為に、
少し視点を変えて、別の方法を思いつくと、
意外と簡単に実装ができてしまう事があります。

例えばバックグラウンドで読み込みを行っている時に、
「Loading…」と表示される画面はよくあります。
ユーザーから見れば「Loading…」の画面が、
新たに作られて、表示されたように見えますね。
そのままコードにするとこんな感じでしょうか。
(クラスやメソッドなどは仮のものです。)

LoadingView loadingView = new LoadingView();
loadingView.Show();
// バックグラウンドで行う処理
loadingView.Close();

これでも問題ありませんが、
複数のバックグラウンド処理が重なった場合などは、
さらに処理を考える必要があったり、
表示の部分がシーケンス的であったり、少し複雑です。

視点を変えて、
「Loading…」画面の可視性が切り変わると考えた場合はこうなります。

loadingView.Visible = true;
// バックグラウンドで行う処理
loadingView.Visible = false;

「Loading…」の画面が表示されていない場合でも、
見えていないだけでずっと画面内に存在しているイメージですね。

実際には loadingView.Visible の部分は、
LoadingView の可視性を表すプロパティなどにしておきます。
こうすると、シーケンス的だった表示がステート(状態)となり、
制御しやすくなります。

難しい問題には頭を柔らかくして、
様々な視点から柔軟な発想ができると、
もっと単純に解決できるかもしれませんね。

コレクションのループ処理で、要素とインデックスを使用したい場合の書き方

C#のお話です。

以下のようなコレクションitemsの各要素にたいして処理を行なう際に、処理内でインデックスが必要な場合はどのようなコードにするのが良いかについて。


var items = new[] { "a", "b", "c" };

 
レガシーな書き方だと以下です。
いまどきfor文でループしたくないですよね。


for(int index = 0; index < items.Length; index++) {
    var item = items[index];
    //indexとitemを使用する処理
}

 
foreachだと以下です。
forよりはマシですが、itemsからインデクサを使用して要素を取得するところが残念です。


foreach(var index in Enumerable.Range(0, items.Length)) {
    var item = items[index];
    //indexとitemを使用する処理
}

インフォテックの社内ライブラリを使用する場合、IListの拡張メソッドForEachが実装してあるので、以下のように実装できます。


items.ForEach((index, item) => {
    //indexとitemを使用する処理
});

上記の方法でだいたいは問題ないのですが、処理をラムダ式で実装出来なかったり、出来ても複雑になってしまう場合、インフォテックの社内ライブラリにIListの拡張メソッドAndIndexが実装してあるので、以下のように実装できます。


foreach (var (item, index) in items.AndIndex()) {
    //indexとitemを使用する処理
}

追加した拡張メソッドはとても単純な実装内容ですが、たったそれだけでコードが非常に分かりやすくなっていると思います。

プログラマーの金額の難しさ

mtjです

ここまで様々なソフトの金額を計算してきましたがいつ計算しても難しいと感じます。

例えばAの物を1日と3日で作れる人がいる場合 そのままの日数で考えると売上は3日で作る人の方が多くなります。

時間給の人の場合早く頑張って作る人より 知識のない時間のかかる人のほうが売り上げは多くなってしまいます。
雇う側が相手の技術力がわからない場合何かを指標に金額を決めるでしょう。
資格数、年齢、経歴等

基本は年齢で決まっているので頑張らない年齢が上の人より 勉強等頑張っている年齢下の人のほうが金額が低くなり
技術系は割に合わないと感じる事が多いのではないかと思います。

現在はオンラインプログラムテスト等あるのでそういったものを元に交渉したりし正当技術が評価されるといいのではないかと思います

特化した強みの必要性

mgcです。

最近良く”自分にしか作れないプログラム”という言葉を耳にします。
正直こういう言葉を使う制御屋さんは自分の価値を上げたいのだと思いますが
自分にしか作れないプログラムなど存在しないと思います。

誰でも勉強をすれば時間はかかれどいずれそのプログラムを書くことが出来るからです。
100人の制御屋さんに同じ装置の設計を依頼すると
全く同じラダーは1つもできませんが
100人全員同じ動作をさせることができるでしょう。

自分にしか作れないプログラムではなく
それ以外の何か他の制御屋さんにはできない突出した部分
実装スピード、正確性、等を磨けばよりいい制御屋さんになれるのではないでしょうか。

クロスプラットフォーム

弊社ではモバイルアプリ開発にXamarinを利用しています。
得意とするC#で開発を行えることが強みです。
クロスプラットフォームの開発環境は、
ここ最近新しいものも登場し、多数あります。

・Xamarin (Microsoft)
・Flutter (Google)
・React Native (Facebook)
・Titanium (Appcelerator)
・Uno Platform (nventive) などなど。

ただしOSのバージョンで既存の動作が変更となったり、
画面形状がこれまでとは異なる、
新しいデバイスへの対応が必要となったり、
iOSでは開発環境に SwiftUI が登場したりなど、
native 周りの知識や動向の把握は常に必要です。

気軽にマルチプラットフォームのアプリが制作できると楽しいですが、
ソフトのメンテナンスにはそれなりの知識と労力が必要です。

WEBアプリ

今、弊社では珍しくWEBアプリを作成しています。

いつもはWindowsデスクトップアプリがほとんどですので、WEBアプリ作成に関するノウハウや社内ライブラリが少なく、悪戦苦闘中です。
ですが、新しいことを学習するのはとても楽しく、時間を忘れて没頭してしまいます。

フレームワークは、ASP.NET Core Blazorを使用したかったのですが、既存のDLLの兼ね合いで.net coreでは困難なため、.net frameworkが使用できるASP.NET Core MVCを使用しました。

WEBデザインを行っている兄に質問しまくって何とか形になってきました。

スクリプトテキスト

mgcです。

近頃案件でよくスクリプトを使用します。
制御屋さんは基本的にラダーを使用するので
STのようなプログラムは苦手な人が多く感じます。

STを使用すると複雑な演算処理が簡単に記述出来たり
参照先を間接的に指定することで品種参照等の改造効率がすごくよくなります。

ただ、一般的にこの業界でSTだけですべてを制御してしまうのは
あまり宜しくない気がします。
動的な部分をすべてSTで組んでいるソフトを解析する機会がありましたが
やはり追いにくい…
ラダーのように直感的にデバイスの検索ができなく解析にとても時間がかかります。
慣れていないというのもあるのでしょうが..
それ以上にSTを触れる制御屋さんが少なすぎるので
何か追加改造があればソフトを作った本人でしかできないという状況も出てきてしまいます。

STはSTなりの良さがあるので適切なところで使用するのであればとてもいいと思います。