新しもの好きプログラマの耳より情報ブログ

仕事でもあるプログラミングについて役に立ちそうな情報を発信していこうというブログです。役に立たなそうな情報はfacebookで。

VisualStudioの完全なアンインストール方法を教わった

VisualStudioのインストール状態がおかしくなってアンインストールもできなくなり、MSサポートに相談した。

完全にアンインストールする手段があると教わったので、メモもかねてブログに残しておこうと思う。

次のツールがあり、これを使うと完全に削除できるそうだ。

%programfiles(x86)%\Microsoft Visual Studio\Installer\resources\app\layout\InstallCleanup.exe

このファイルがない場合は、一度VisualStudioをインストールし直せば作られるので、そこから実行すれば良いとのこと。


※以下は古い情報なので、使用しないように

VS2015の頃は「すべてのレジストリを手動で削除してくれ」と案内されてこんなツールを作ったこともあった。

https://github.com/suusanex/visualstudio_reg_all_delete

しかし今は上記のツールを使えば良いようだ。便利になって良かった。

C#のReSharperで、DI等のメンバ変数代入が楽になってストレスが減った

ReSharperで日々のコーディングが便利になっているが、実に多機能でまだ使い切れていない。

使っていて「お、これはいいな」と思ったものを1つ紹介しよう。

コンストラクタに引数を受け取り、それをメンバ変数に代入して保持しておく。DIも含めて、そういうコードを書く機会は多いと思う。

しかしよく書く割には、手順が多くて面倒である。

  1. 引数を書く
  2. 引数と似た名前のメンバ変数を書く
  3. メンバ変数へ引数を代入するコードを書く

という3ステップ。この2と3をResharperがやってくれることに気づいた。

Introduce Fieldというリファクタリングメニューを使う。

コンストラクタの引数を書き、引数を選択してRefactor thisメニューからこれを選ぶ。すると上記2と3のコードをパッと生成してくれる。こんな感じ。

contruct(int input){
}

int _input;
contruct(int input){
    _input = input;
}

オプション指定できるダイアログが開くので、ここで「_inputじゃなくてm_inputにしたい」といったローカルルールにも対応可能。

とても地味だが、この機能1つで大分ストレスが減って少しコーディング速度が上がると思う。ResharperにもVisual Studioにもまだまだこういう便利機能がありそうなので、いろいろ試していこうと思う。

C++/CLIも含めた.NET CoreやStandardの呼び出し状況(現時点)

.NET CoreやStandardがどんどんバージョンアップしているが、既存のコードの保守で組み込むには.NET Frameworkとの共存がどうなっているかがポイントになる。

C#に加えて、C++/CLIとの組み合わせでどうなるかを調べてみた。

https://www.slideshare.net/keitasudo1/net-frameworkstandardcore-ccli

C#は今の.NET Core 2.1で組み込めそうだが、C++/CLIは3.0Previewですらまだ動かないようだ。C++混在のコードの保守をしている人は、.NET Core 3.0正式版のリリースに期待しよう。

ところで、そんなちょっとしたネタや仕事上身についた知識を、自社で開いている勉強会で発表している。次は12/6に品川でやるので、興味が沸いた人はぜひどうぞ。

アプリからドライバまで 現役エンジニアの濃い話 #2 自社製品のCI導入取り組みと、デバイスドライバ開発の基礎 https://sciencepark.connpass.com/event/109262/

Git for WindowsでAzure DevOpsへアクセスする時、Azure ADの認証画面が出ない問題の解決方法

Web上でも事例が見つからない問題で悩み、一応解決方法を見つけたのでブログに書いておく。

Git for WindowsでAzure DevOps(旧VSTS)のgitリポジトリへアクセスした場合に、Azure ADの認証ダイアログが出ずに二要素認証ができないという問題が起きた。一部の環境でだけ起きていて、原因は分からないままだが解決方法は見つかった。

通常、そのケースでは二要素認証にも対応したAzure ADの認証ダイアログが、自動で表示される。 こんな画面。 f:id:suusanex:20181116231045p:plain

これはGit Credential Manager for Windowsが自動で「Azure AD認証が必要だ」と判断して出しているらしい。

しかし、たまにAzure ADの認証ダイアログが出ず、単に「 enter your credentials for "https://~」というシンプルなダイアログが出てしまう環境がある。こんな画面。 f:id:suusanex:20181116231254p:plain

この場合、二要素認証が使えなくて困ってしまう。

結論としては、gitの認証設定でデフォルトではAuto(自動で判断)となっている部分を、URL指定で強制的にAzure AD認証に設定することで解決できた。 具体的には、次のように設定を追加する。

git config --global credential.dev.azure.com.authority AAD

これにより、Azure DevOpsのURL(dev.azure.com)については強制的にAzure AD認証が使われるようになり、ちゃんと二要素認証ができるようになった。

解決はできたが、そもそもなぜ失敗する環境があるのかはわからないまま。もしかしたら、そのうちgitのバージョンアップで解決するかもしれない。 とりあえず今は、同じ問題で悩んでいる人がいたら、この解決方法を試してみると良いと思う。

AIがプログラマの新技術習得まで助けてくれる時代になったようだ

VisualStudioを使ってる人ならおなじみIntellisenseについて、AIで推奨を出してくれる機能を追加するとBuildで発表されていた。Intellicodeという名前で、まだプレビューだがすでに使えるようだ。

どんなものかお手並み拝見と思っていたが、次の記事を見て驚いた。試しに使ってみると、確かにこの通り動いた。 https://qiita.com/yossy6954/items/f4c8b5f5f8f4c7a843c6

なぜ驚いたかというと、Intellicodeが推奨を出している「IsSuccessStatusCodeを見よう」といった内容が、初めてWebAPIを呼ぶコードを書いた時に定型的な作法が分からずに調べながら苦戦した部分だったから。この機能があるなら、定型をすぐに知ることができる。AIの実現方式までは知らないが、ディープラーニングなら世のプログラマの多くがやっている処理、ルールベースならMS推奨の処理になるはずで、どちらもWebで適当に検索するよりは有力だろう。

5/10 12:06追記:発表記事を見るとどうやらディープラーニングのようなので、「世のOSSプログラマの多くがやっている処理」のようだ。

つまり、AIが初学者のアドバイザーになってくれるので、新技術に挑戦するハードルがさらに下がるという事だ。 こういうところはAIに助けてもらって、プログラマは新しい価値の実現に集中できるようになる。ポジティブな意味で、AIに仕事を奪われて新しい仕事に集中できるようになるわけだ。こういう技術はどんどん使っていきたい。

ただし注意点が1つ。私はReSharperというC#のコーディングを便利にするサードパーティのライブラリを使っているが、これは「VisualStudioとReSharperのIntellisenseのどちらを使うか」を選択する仕様なので、ReSharperを選んでしまうとIntellicodeは使えないようだ。排他なのは残念だが、便利な方を使っていくしかなさそうだ。

std::threadとラムダ式を使ってみたら、ネイティブC++がいつの間にかだいぶ便利になってることに今更気づいた

いまさら感があるが、std::threadの便利さに恐れ入ったので記事を書く。感覚的には、C#のSystem.Threading.Thread+ラムダ式と同じくらいの感じで高速に書けそう。使ってる人にとっては常識的な話なので、そういう人はスルーしてください。

ごく簡単な処理を別スレッドで実行するためにスレッドを立てたい。そのスレッドの管理は不要。というケースは割とある。

C#のTaskやらThreadやらを使ってラムダ式でスレッドを立てるのに慣れてしまうと、ネイティブC++(VC++)でこれを書くのが面倒で仕方ない。

C#ならラムダ式の変数のキャプチャがあるので、こんな感じで書いたとする。

var event = new 何かイベント();
Task.Run(()=>{

    event.WaitOne();
    何かアクション();
});

従来の(かなり古い?)VC++で書こうとすると、APIの選択はともかくだいたいこんな感じだろうか。

void threadFunc(void* pParam){
    auto pEvent = reinterpret_cast<何かイベント*>(pParam);
    Wait系処理(*pEvent);
    何かアクション();
    delete pEvent;
}

auto event = new 何かイベント();
_beginthread(threadFunc, 0, &event)

まず別の関数を書くのが面倒・・・だし、newしたポインタをvoid*で渡し、渡した先で正しい方にキャストしてdeleteされることを期待するというのも、どうにも怖い感じだ。

これをstd::threadで書くと、こうなる。

auto event = new 何かイベント();
std::thread th([event]{
    Wait系処理(event);
    何かアクション();
});
th.detach();

なんと、ほぼTaskと同じノリで書ける。ラムダ式と変数のキャプチャという機能はここまで強力だったか・・・。

5年くらい前にこういった面倒さからネイティブC++はできるだけ避けるようになっていて、昔のコードの保守をするときもすぐにC++/CLIを使って.NETのコードを呼ぶように書くのが常だった。

しかし、ここまで便利になっているのなら、ちょっとした処理はネイティブC++のままで書いてもぜんぜん問題なさそうだ。C++を見直してみようと思う。

外部設計の品質の測り方について、良い視点をもらった

プロジェクト管理の勉強会で印象に残った話。

外部設計の品質の測り方

  • 要件ごとに、粒度と網羅度で採点する
  • 粒度は、FP算出できる程度まで細かくなっているかどうか
  • 網羅度は、その粒度において要件の内容を網羅するだけの記述があるかどうか
  • これらの観点を要件一つごとに、要件から設計まで一気通貫で見る
  • これで、設計がゆるすぎて作れない、といった低品質の外部設計を検出できる

これはピンと来た。確かに言われてみれば、自分がレビューして設計漏れの指摘を入れる時は、そのような見方をしていると思う。

社内で検討しても、ページ数やらレビュー指摘数やらいまいちピンと来ない指標しか出てこなかったが、外で話を聞いて解決が見えたわけだ。

外に出て情報交換するのはやはり大事。