弊社では Xamarin を用いてモバイルアプリも開発をしております。
Xamarin はC#で iOS/Android などのモバイルアプリが開発できる、
モバイルアプリ向けのクロスプラットフォーム開発環境です。

ただし例えばiOSアプリをWindowsで開発する場合でも必ずMacが必要で、
Mono、Xcode、Visual Studio(Mac)、Visual Studio(Win)、Xamarin などの、
使用するソフト間のバージョン関係がとてもシビアです。

先日 Visual Studio(Win) Ver16.6 にアップデートした際に、
ビルドができない状態となり、原因の特定に時間が掛かってしまいました。
結局は Visual Studio の問題で Ver16.6.1 で修正されたのですが、
これを機に Visual Studio(Mac) による専用の開発環境を整えて、
開発時のソフトウェアバージョンをある程度固定する事にしました。

Windows と Mac 間の通信が不要となり、
ビルド速度が向上し、デバッグも安定するようになりました。
普段は Visual Studio(Win) で開発を行っておりましたので、
Visual Studio(Mac) やショートカットに慣れていこうと思います。

現在、評価用の画像処理ソフトを作成しています。

社内用には画像処理ソフトがあり、これを使用すれば複雑な画像処理も作成できるのですが、開発者用の複雑なソフトになっています。

これとは別にお客様自身で画像検査システムのPoC(概念実証)が行えるようなソフトを作成しています。
画像処理システムで良く使用する機能だけを簡単に組み合わせできるようにします。
画像処理だけではなく、その前後の開始トリガと結果出力を別機器とやりとりできるソフトになり、そのまま設備に組み込んで画像センサーとして使用できるようになる予定です。

Infortec画像処理システムを表示

mgcです。

ご無沙汰しております。

さて、新しい事への挑戦。
仕事でもプライベートでも新しい事に常に挑戦したいと
最近よく心がけております。

仕事では、スカラロボット/変位センサ/多軸同期制御等の新しい事への挑戦。
プライベートでは読書をはじめ常に新鮮な気持ちで人生を生きていこうと思っております。
新しい事を始めるには勇気が必要です。
今まで通りの生き方をしていれば大きく躓くことはまずないでしょう。
しかし、新しい事に挑戦するという事は自分の知らない未知の世界に歩き出す訳で
この先何が待ち受けているかわかりません。

ただ、自分の好奇心が向かう方向へ歩かなければ
自分自身にうそをついていることになりかねないことに読んだ本から気づきました。
最近感銘を受けた本は[嫌われる勇気]です。
良ければ一度読んでみてください。

これからも新しい事への挑戦を恐れず仕事、プライベート共に充実した時間を送ろうと思います。

こんにちは mtjです

最近聞く事が少なくなったAI関連の話

出た当初から色々言われていますが　映画のターミネーターのように自律的に動くAIのようなものはまだまだ先でしょう

一般向けにはそういう風に動いてるように見せるAIもできるでしょうがお手本、もしくは正解がないものをAIで勝手に考えるというのは現状では難しいと思われます。

とあるG社の翻訳AIもそうですがあれもひな型となる言語の文章を読み込ませそれぞれの言語の特徴を覚えさせ反復させることで翻訳精度を上げています。
AIを持ってきてこれを翻訳してくれ　という感じでできるものでなく　専門家が考えたアルゴリズムに沿って勉強しその結果正しいであろう使い方を出力します（基本学習させた他の結果）

会話AIもそういったもので他の人との会話、もしくは学習させる文章等を記録し基本的に多の方で話すようにします。

学習させる専門家がいてAIは初めて成り立ちます
日本語の学習をさせているのに別の言語、もしくは多種多様な言語を学習させれば使い物にならない日本語会話AIができあがるでしょう。

囲碁のAlphaGoは深層強化学習といわれるもので　AIが自分で考えその結果を人間が評価（アルゴリズム等による採点か成否）するような方法で
す
報酬の決め方があいまいであればあるほど使い物にならなくなります。

画像処理等でよく使用されるものは教師有りの学習でOK,NGの物を事前に与えこれはOK、これはNG等を覚え現実の画像を判定していくものです。
OK、NGで与えるものがOKぽいNG、NGぽいOKだったりすればするほど使い物にならなくなります。

世の中のAIはまだまだ専門家のサポートツールとの立ち位置なので一般家庭にどのような形で降りてくるか楽しみではありますね

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接続できるようにしました。

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

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

こんにちはmtjです。

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

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

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

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

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

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

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

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

例えばバックグラウンドで読み込みを行っている時に、
「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日で作る人の方が多くなります。

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

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

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