ソフトの価格と出来

こんにちはmtjです。

ソフトでは内部のソースまではわかりません

普通に動いていれば何も問題ないのでソースが汚かろうが、綺麗だろうがお客さんには関係ありません。
ではどんな時にソースの汚さで問題になるかというと基本は異常時と変更時です。

異常時の場合はソースが複雑な方が修正が長引き修正による不具合も起きやすくなります。
変更時は変更箇所が多くなったり多い分テスト、手戻りも多くなり費用が必要になります。

では汚いソースで行う利点は何かというと考える時間がいらない分速度が速い=安いということです。
もちろん上手く行けばの話ですが設計、共通化の検討等もしないため手戻りがなければかなり早くなると思います。

もちろんですが上記は小さいソフトならばの話です、大きくなればなるほど共通化による同じようなコードがなくなっていくので基本は設計もコードも綺麗なほうがはやくなります。

只お客さんから見ると金額と仕様書のみなのでそういった後々の部分については頼む側からすれば全くわからないのが現状です。
頼むときの指標にするためにソフト開発のレベルを測るための指標が何かあるといいのかもしれません。

C#のZip拡張メソッド

以前にブログに記載しました、C#7で追加された分解の機能に関係するお話。

この分解が増えたことで、LINQのZip拡張メソッドをもっと使いやすくできるのではなかろうかと思い、新しいZip拡張メソッドを作成してみました。

まず、いままでのZip拡張メソッドの例。


var xArray = new[] { 1.1, 2.2, 3.3 };
var yArray = new[] { 4.4, 5.5, 6.6 };
foreach (var item in xArray.Zip(yArray, (x, y) => new { x, y })) {
    Console.WriteLine($"X={item.x} , Y={item.y}");
}

xArrayとyArrayをマージして新しい匿名クラスを作成しています。
匿名クラスを作成するラムダ式を指定するのが面倒ですね。

で、新しく追加したZip拡張メソッドを使用すると以下のようになります。


var xArray = new[] { 1.1, 2.2, 3.3 };
var yArray = new[] { 4.4, 5.5, 6.6 };
foreach (var (x, y) in xArray.Zip(yArray)) {
    Console.WriteLine($"X={x} , Y={y}");
}

匿名クラスを使用せず、Tupleクラスのインスタンスを返すようにしました。
C#7で増えたタプルではなく、昔からあるTupleクラスなので、通常ならば値にアクセスする場合、item.Item1やitem.Item2などのようにxやyの名称がなくなり可視性が悪いですが、分解のお陰で、xとyの名称そのままで値にアクセスできるようになりました。

ちなみに、新しく作成したZip拡張メソッドの実装は以下となります。


public static IEnumerable<Tuple<T1, T2>> Zip<T1, T2>(this IEnumerable<T1> items1, IEnumerable<T2> items2) {
    return items1.Zip(items2, (item1, item2) => Tuple.Create(item1, item2));
}

同じようにして、3つのシーケンスをマージするメソッド、4つのシーケンスをマージするメソッドと、いくつか作成しておくと便利です。

100年人生

人生100年という時代が訪れます。
還暦(60歳)になったとき、あと40年生きなければなりません。
朝昼晩、死ぬまでに4万3千800回の食事をします。
(60歳の時点ですでに6万5千700回の食事をしている!!)
おそらく勤めていた会社の寿命のほうが短くなるのでは?
ハローワークが老人で溢れます。

機種変更

mgcです。

以前ブログでお話ししていたのですが
この間現場に出ているときにIphone6がフリーズし、
1日スマホが使用できなくなる現象が発生しました。
もちろん再起動もできませんでした。

電源が切れるのをひたすら待ち、やっと再起動を行い再度使用できることが出来ました。。
が!
さすがにこのスマートフォンと長くお付き合いすることは出来ないと思い
ようやく機種変更を行いました。

結局IphoneXに変更しましたが慣れてしまえば操作性も気にならないですね。
新しい機能と言ってもこれと言って便利だったりするわけでもなく、
少し残念な気がしますが、これから2年間ほどお世話になろうと思います。

別の人を使うという事。

mtjです。

自分はSEなので人を使ったり使われたりする立場ではあります。

人を使って色々する場合はもちろん効率が重視されます。
プログラム業務での効率はほぼ役割分担です、難易度の高い部分(外部システムとつなぐだったり、WindowsForm的に難しい
スレッド間操作で気にすることが多い、全体のシステム構成を知らないと結合等できないようなとこ)
簡単な部分を割り振っていきます、基本は自分が全体の構造の設計、テストを行う事になります。

上記の事をしていると基本的には他人のソースをチェックして作りが問題ないか、テストが問題なく作られているか等の確認作業が主なので難しい部分ばかりが自分にきてしまいます。

これらを行っていると物が完成した時の達成感が薄くなってしまいます。
一人で行っていた場合は設計し、設計通り動き、テスト等で度々上手くできたとの実感がわきます、これが最近は人を使う事が多いので少なくなっている気がします。

上記で思う事はシステム開発で上の管理する側の人間はあまり開発者としての達成感という物がないのではないかと思います。
もちろん作る部分によってはつまらない部分もありますが全て自分一人で作っていた方がやりがいがあった気がします。
小規模のシステムでもこのように感じるとういう事は、大規模のシステムを作っている総まとめ(プロマネ等)はどのような気持ちで行っているか気になるとこではあります。
毎日何十もの機能の確認、テスト等を行い完成まで持ち込むのはかなり根気がいる作業だと思います。

そういう管理することが好きな人もいるので案外達成感があるのかもしれませんね。
自分はわからないことがあったら調べて自分で作って解決していくほうが好きなのであまり向いていない気がしました。

Windowsのネットワーク接続の設定

1ヶ月位前からWindowsタブレットのバッテリ消費が早いので何かおかしいと思っていたが原因が判明。

以下のネットワーク接続の設定が「なし」になっているのを「常時」に変更することで改善。
間違って変えてしまったのかWindowsアップデートで変わったのか分からないですが、一安心です。

それにしても、「なし」と「常時」の意味がわかりにくい。
なし:スリープ時のネットワーク切断を行わない。
常時:スリープ時のネットワーク切断を常に行う。
もうひとつ「Windowsで管理」という項目もあり、Windowsがなんかうまく制御してくれるものと思われます。

2017から2018へ

みなさま、あけましておめでとうございます。
(私はとうとう5回目の年男になってしまいました)

昨年は110日の出張があり、その内48日が海外でした。
初めての国で初めてのダウン(発熱)もありました。
その時は国内外のスタッフの方々に親切にしていただいて
とても感激しました。
そして言ってくれました。「あなたは最重要人物だから」
私は思いました。「死んでもやったる!」
「制御」という仕事であっても我々は「人と仕事をしてい
るんだ」という思いが溢れました。
今年はそんな思いを大切にしながら「制御」という仕事で
人と繋がっていけたら思います。

年末

mgcです。

気づけば残り3日ほどで1年が終わりますが
大掃除等はお済でしょうか?

毎年この時期には家のエアコンをすべて掃除するのですが
さすがに一年間使用していたエアコンの中は埃とカビだらけで
エアコンの掃除だけで1日かかってしまいますが
この掃除をしないと1年が終わった気がしないのです。

皆様にも何かしないと
1年が終わった気がしないということがありますでしょうか?
今年中にしておきたいことを済ませて
良い年越しにしていただきたいと思います。

それでは次回は2018年になっておりますが
2018年も宜しくお願い致します。

良いお年をお過ごしください。

トラックボール

こんにちはmtjです。

現在トラックボールを使っています。

マウスはマウス本体を動かすことでポインタを動かします
トラックボールは本体にボールがついておりそれを転がすことでカーソルを動かします。

最初は慣れが必要ですが慣れてくるとかなり使いやすいと思います。
自分はマウスでは画面全体をマウスを浮かすことなく移動できるようにしているのであまり気にはしませんが
何回もマウスを上げてマウスパッドの真ん中に戻してをするより指を何回か転がすだけで移動できるトラックボールのほうが
良いのではないかと思います。

特にマウスパッド等が必要ないのが利点で狭い場所でも操作しやすいのが利点ですね
手首の負担が少ないは聞きますが自分は上記で記載した通りそもそも手首に負荷のかかる感度ではないので
個人的にはボールを転がしている感覚が好きなので使っている感じです。

また親指でボールを動かすタイプより中指等で転がすタイプがおすすめです。

C#のタプルと分解

C#7で追加されたタプルのフィールドを分解する構文について、タプル専用の機能ではなくユーザ定義の型でも分解が行えると知ったので試してみました。

タプルのフィールドを分解する構文は以下のようになります。


var t = (Value1: 2, Value2: 3D);
var(v1, v2) = t;

1行目で2つのフィールドを保持するタプル変数tを作成し、
2行目で変数tのフィールドをv1とv2に分解しています。

これだけでは意味が無いですが、メソッドの戻り値はタプルで返し、
メソッド実行側はすぐに分解して使用したい場合などに役立ちます。

上記の分解と同様のことを行うには、クラスや構造体にDeconstructメソッドを実装します。拡張メソッドでもOKです。
KeyValuePair構造体のDeconstruct拡張メソッド実装例は以下のようになります。


public static void Deconstruct<TKey, TValue>(this KeyValuePair<TKey, TValue> pair, out TKey key, out TValue value) {
    key = pair.Key;
    value = pair.Value;
}

例えば、Dictionaryの各要素をforeachで処理する場合、今まであれば以下のようになります。


var dic = new Dictionary<string, int>();
foreach (var pair in dic) {
    Console.WriteLine(pair.Key + "=" + pair.Value);
}

Deconstruct拡張メソッドを実装して分解が行えるようになると、以下のような実装が可能になります。


var dic = new Dictionary<string, int>();
foreach (var (name, score) in dic) {
    Console.WriteLine(name + "=" + score);
}

変数pairを使用する必要がなくなり、pair.Keyとpair.Valueではなく、本来のフィールドの意味を表す変数名を名付けて利用できるようになりました。