福井県の国道8号線で大雪による3日間の立ち往生が発生しました。
こんな時に電気自動車はどうなるでしょうか？
急速充電さえ可能ならば一酸化炭素中毒の危険性が減って安全なのですが。
ドイツは2040年までに内燃機関のクルマを無くす計画です。
あと22年の間に夢のような電池が開発されることを期待します。

mgcです。

最近の医療の進歩にはとても驚かされます。
手術を終えた患者に対し、痛みを和らげるよう24時間遠隔で監視され
痛み止めが切れる前になると自動で一定量の痛み止めを注射するようになっているようです。
これは手術後の痛みを和らげる為だけではなく
リハビリへの移行を早める為としても良いのだそうです。

手術後のリハビリはかなりの痛みを伴うものと聞いたことがあります。
ただ上記の方法をとっているとその後のリハビリへの移行が患者にとって苦痛にはなりにくいようです。
痛みをコントロールすることで早期回復が望める、、
医療の進歩は本当にすごいです。

こんにちはmtjです。

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

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

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

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

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

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

以前にブログに記載しました、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));
}

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

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

mgcです。

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

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

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

mtjです。

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

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

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

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

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

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

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

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

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

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

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

mgcです。

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

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

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

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

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