Category Archives: オブジェクト指向・システム開発

Visual Studio 2019 16.1

情報源: Visual Studio 2019 Release Notes | Microsoft Docs

出ております。IntelicodeがGAとなりました。.NET Core 3.0 PreviewでXAMLデザイナが使用可能になったようです。Git Clone時にSSHのURIが指定可能になりました。など。詳細は上リリースノートにてご確認ください。10:28現在日本語の方は更新されていません(English(United Statesに変えて見てね)。

Windows 10 May 2019 Update GA

In early April, we announced enhancements to the Windows update process to improve the user experience with more control, transparency, and the initial availability of the Windows 10 May 2019 Update through the Windows Insider Program’s Release Preview ring to focus on and improve quality. Based on positive data and the feedback we’ve seen from […]

情報源: How to get the Windows 10 May 2019 Update | Windows Experience Blog

GAしました。基本的にはWindows Updateにより更新します。

そろそろRPA:Robotic Process Automationについて一言言っておくか

RPAは専門外だが、自動制御ってところで25年飯を食ってきたので一言書いておきたい。ポエムだよ。あとTwしたものをまとめている。

RPAの第一歩はまず、業務内容の言語化。日本語でまず業務内容を「細かく」記述できるかどうかがまず第1の関門。ここで躓くようなら、業務内容か組織に自動化に対する問題がありすぎて作業の自動化は無理なので、素直に諦める。まず初めにそっちをどうにかしないといけない。

次の関門は、記述できた業務内容をフローチャート化出来るものと、フローチャート化出来ないもの、フローチャート化はナントカできるが複雑すぎるもの3種類に分ける。1番目はそのまま完全にRPA化が可能。2番目のフローチャート化出来ないものは、人がやった方が早いのでRPA化しない。実は3番目もやらない。現状のRPAのソリューションで3番目を片付けるのはやっかいなので、まずここをどうシンプルにするか業務改善を考えた方が良い。システム化はそのあと。そして、皆さん何故かRPAが2番目と3番目の項目に適応できると考えていらっしゃる。はっきり言ってムリ。現状RPAはつまらないルーチンワークを見つけ出して、そこを効率化することで、社員を本来しなければならない業務に集中させるツールとして考えないと失敗する。PRAもAI技術も銀の弾丸じゃないので夢を見すぎてはいけない。しかし、何故か皆さん主要業務が自動化できると考えている。

結局業務内容見直しとその改善のと言う点で、かつてもてはやされたBPRとRPAは本質的に何も変わらないよ。これらの本質は業務改善であって、RPAを入れることが目的化したらそれは手段の目的化に過ぎないし、そうであれば100%失敗することを保証する。まず、業務内容を言語化して文書化する。そしてそれを見なおす。そこからはじめる。RPAは道具。適材適所がある。

F#の方向性の話

TL;DR We’ve moved the F# GitHub repository from microsoft/visualfsharp to dotnet/fsharp, as specified in the corresponding RFC. F# has a somewhat strange history in its name and brand. If we roll back the clocks to the year 2015, F# sort of had two identities.

情報源: The F# development home on GitHub is now dotnet/fsharp | .NET Blog

微妙な二系統の開発は止め、.NET Coreベースのオープンソースプロジェクトへの集約という事らしいです。

ReSharper Ultimate 2018.3.5とRider 2018.3.5リリース

Even after we roll out a new major version, older releases may still benefit from bugfix updates. This is why today we’re making available ReSharper Ultimate 2018.3.5 and Rider 2018.3.5. ReSharper Ultimate 2018.3.5 fixes a high memory usage issue on … Continue reading →

情報源: ReSharper Ultimate 2018.3.5 and Rider 2018.3.5 Are Released! – .NET Tools Blog.NET Tools Blog

バグ修正です。詳細は情報源へ。

PRP: Parallel Redundancy Protocol

メモ。

Parallel Redundancy Protocol – Wikipedia

PRP – The Wireshark Wiki

https://web.archive.org/web/20150924073019/https://www.zhaw.ch/storage/engineering/institute-zentren/ines/forschung-und-entwicklung/time-synchronisation/tutorial-on-prp.pdf

PRPはイーサネット冗長化のネットワークプロトコル。PRPはHSRと共にIEC 62439-3:2016により標準化されている。また、IEC 61850の枠組みで変電所の自動化に採用されている。

PRPは高可用性と従来のRSTPの切り替え時間では必要十分ではない短い切り替え時間を必要とするアプリケーションに適している。

PRPは専用のハードウェア(FPGAなどで作られる)が必要となるHSPと違い、すべてソフトウェアで実現される。実際には、カーネルモードもしくはユーザーモードで動作するネットワークドライバーとして動作し、アプリケーションからは単一のネットワークインターフェースに見える(WindowsではNDISドライバーとして実装されることが多い)。プリンタなどの単一接続点しか持たない機器については、二重接続ノードのように動作するRedBoxを使用して接続することができる。

また、古いIEC 62439:2010規格は、一部の制御システムではまだ使用されているためPRP-0と呼ばれ、PRP 2012は “PRP”と呼ばれている。

Create Interactive .NET Documentation with Try .NET

Try .NET is an interactive documentation generator for .NET Core. Use the Try .NET global tool to create interactive markdown experiences.

情報源: Create Interactive .NET Documentation with Try .NET | .NET Blog

Memo.

Exploring new frontiers for Git push performance 

In previous posts I’ve talked about performance improvements that our team contributed to the Git community. At Microsoft, we’ve been pushing Git to its limits with the largest and busiest Git repositories on the planet, improving core Git as we go and sending these improvements back upstream.

情報源: Exploring new frontiers for Git push performance | Azure DevOps Blog

Memo.

C# 8のinterfaceのデフォルト実装

Default implementations in interfaces With last week’s posts Announcing .NET Core 3.0 Preview 5 and Visual Studio 2019 version 16.1 Preview 3, the last major feature of C# 8.0 is now available in preview. A big impediment to software evolution has been the fact that you couldn’t add new members to a public interface.

情報源: Default implementations in interfaces | .NET Blog

C# 8から導入されるinterfaceのデフォルト実装についての記事。

以下はテキトー訳

インタフェースに、そのメンバーの実装を記述できるようになります。実装したクラスもしくは構造体がそのメンバの実装を提供しなくてもエラーにはならず、interfaceで記述されたそのメンバのコードが実行されます。公開済みライブラリのインタフェースにメンバを追加する必要が出てきたときに、既存のそのインタフェースを実装した型に影響を与えることなく、追加することができます。

次のようなインタフェースがあるとします。

interface ILogger
{
    void Log(LogLevel level, string message);
}

既存のクラスは、恐らく所有者が異なる別のコードベースにあり、次のようにILoggerを実装しています。

class ConsoleLogger : ILogger
{
    public void Log(LogLevel level, string message) { ... }
}

次のようにILoggerインタフェースにLogメソッドのオーバーロードを追加したいと思います。デフォルトの実装、つまりメソッド本体を提供することで、既存の実装を壊すことなく実行できます。

interface ILogger
{
    void Log(LogLevel level, string message);
    void Log(Exception ex) => Log(LogLevel.Error, ex.ToString());
}

これは、ConsoleLoggerが必要とするインタフェース規約を満たしています。そのインスタンスが、インタフェースに変換されて、新しいLogのオーバーロードが呼ばれた場合には、インタフェースで記述したデフォルト実装が呼び出されます。

public static void LogException(ConsoleLogger logger, Exception ex)
{
    ILogger ilogger = logger; // Converting to interface
    ilogger.Log(ex);          // Calling new Log overload
}

もちろん、新しいメンバーについて知っている実装クラスは、デフォルト実装が存在するインタフェースメンバーに対しても、独自の方法でそれを実装する事ができます。

以下にチュートリアルが用意されています。

Safely update interfaces using default interface members in C# | Microsoft Docs