ReSharperが指摘してくれるコードスタイルのあれこれ

ReSharper(と同様のエンジンを内蔵しているRider)が指摘してくれるものにはいろいろな種類のものがあるのですがそのいくつかに関する考察。

Collection Initializerへの置き換え

次のようなコードがあったとします。

var list = new List();
list.Add(new Something() {unit = "One", value = 5});
list.Add(new Something() {unit = "Two", value = 6});

ReShaperは次のような置き換えを提案してきます。

var list = new List
{
    new Something() {unit = "One", value = 5},
    new Something() {unit = "Two", value = 6}
};

これは確かに冗長になりがちなのでシンプルな書き換えにするのにはいい方法。

Foreach文のLINQ式への置き換え

時々出てくるパターンとしてリストの中を辿りつつ内容に対して処理を行うパターン。foreachで辿るようなパターン、例えば次のようなパターンがあったとします。

foreach (var item in list)
{
     if (item.unit == "Two")
        result += item.value;
}

これは以下のように置き換えることを提案してきます。

var result = list.Where(item => item.unit == "Two").Sum(item => item.value);

処理が複雑になると可読性が失われたり、デバッグが複雑になったりすることがあるのでその点は注意です。

メソッドのstatic化

次のようなクラスがあったとします。

internal class Hoge
{
    private int _value;

    public int Foo(int v)
    {
        _value += v;
        return _value;
    }

    public int Bar(int v)
    {
        v -= 1;
        return v;
    }
}

ReSharperはこのうち、public int Bar(int v)をstatic化するように提案してきます。

internal class Hoge
{
    private int _value;

    public int Foo(int v)
    {
        _value += v;
        return _value;
    }

    public static int Bar(int v)
    {
        v -= 1;
        return v;
    }
}

これはインスタンス化を行うとその分、要求されるメモリが増えるので、必要がないものにおいてはVM内で共有したほうがいい、ということですね。

ただ、staticメソッドのインスタンス化はそのメンバを呼び出したタイミングで行われたり、ガーベジコレクションの挙動が普通とは異なってくるはず(というか、スコープから外れない場合は残存し続けるので、長期的に残り続ける挙動を示すはずです)のでその部分では注意が必要です。

JetBrains All Products Pack

最近JetBrainsのAll Products Packを購入したのでいろいろと。

まずはそれぞれのツールに関していろいろと書いてみる。

Rider

まずいちばん使っているのがこのRider。C#のIDEです。現段階で使っているのは.NET Core 2.0の機能を使いたいので、EAP版です。

ちなみにRiderはUnityと組み合わせ使うことも可能です。Linux版のUnity Editorと組み合わせて使用する場合に便利です。

機能面ではVisual StudioResharperを組み合わせたものに近いです。(Windows Formなどのビジュアルエディターはありませんが……。)

尚、Reshaperに関しても上位版であるResharper Ultimateが、All Products Packに含まれています。

プライベートではマルチプラットフォーム開発なので、あまり使う機会はなかったりしますが。(ただし、使う場合Visual Studio Communityでもちゃんと動作します。)

DataGrip

次によく使うのがDataGripです。DataGripはデータベース用のIDEです。

いろいろなデータベースをサポートしていて、SQL文を発行したり、内容を調べたりすることができます。

Gogland

GoglandはGoogleにより開発されている、Go用のIDEです。現在EAPで無料で使用できます。正式版では名前が変わるかも知れないようです。

IntelliJ IDEA Ultimate

IntelliJ IDEA UltimateJavaのIDEです。(正確にはJVMな言語は多くが対応しています。KotlinもJetBrainsが開発していますし、もちろん対応しています。)

尚、IntelliJ IDEA Ultimateにはオープンソース版のIntelliJ IDEA Communityも存在します。これ一本でJavaのアプリ、Androidのアプリなどを開発したりできます。プラグインを通してGoやPythonなどの他の言語も開発することができるようですが、挙動など言語特化のIDEがより言語に特化した動作をするようになっているようです。

個人的にはJavaはあまり使わないので、XSLTの編集などに使ったりする場合が多いです。

PyCharm Professional

PyCharm ProfessionalPythonのIDEです。。こちらもPyCharm Communityというオープンソース版の他、PyCharm Eduという教育目的に特化した特別版も存在します。

PhpStorm

PhpStormPHPのIDEです。あまり新規にPHPは少なくとも自分で書くことは少ないのですが、レガシーなコードはあるのでその保守に使用しています。

CLion

CLionはC/C++のIDEです。Linux上で時々C/C++を扱ったりするので、その場合に活用しているツールです。

RubyMine

RubyMineRubyのIDE。Rubyのコードは現在PHPよりも少ないのであまり出番はないですが……。

MPS

イマイチ使い方がよくわかっていないのが、このMPS。IDEというよりはメタ言語みたいなのですが……。

JetBrainsのAll Products Packは開発機材として個人的に買う場合は、そこまでは高くはないのですが(ビジネスとして買う場合はそれなりに高くなりますが……)それなりの額にはなりますが、今のところはその値打ちはあるように感じています。特に複数の言語を使う必要がある場合同じ使用感で複数の言語を扱えますので。

LINEのLetter Sealingその後

以前、これまで、LINEのE2EE実装「Letter Sealing」初見LINEのLetter Sealingに関するフォローアップと2回に渡り、LINEのE2EE実装である、Letter Sealing機能に関して取り上げてきたわけですが、以前にも増してメッセンジャーにおけるE2EEが一般的になってきました。以前はE2EEを実装したメッセンジャーアプリはSignalTelegramぐらいしかなかったのですが、今ではFacebook傘下のWhatsappにもSignalと同じ方式のものが実装されましたし、また、Facebook MessengerもまもなくE2EEが実装されるようです。他にもGoogleもビデオチャットアプリであるDuoはE2EEを使用している他、また今後リリース予定のメッセンジャーAlloにもE2EEの実装が予定されているようです。

さて、最近、LINEのEnginners’ Blogにおいてメッセージの安全性のさらなる強化:Letter Sealingの適用拡大という記事が公開されました。内容的にはLetter Sealing機能が更新され、デフォルトでE2EEが有効となり、また、音声やビデオ通話、及びグループチャットにE2EEが使用できるようになった、ということです。

今回の更新で、以前、指摘した、暗号化されているかどうかがわかりにくい、という問題が解決したと思われます。ただ、今回の更新で、暗号化されているのがわかるようになったのですが、以前の記事で「現時点では、Letter Sealingはテキストメッセージと位置情報に対してのみ適用されます。」となっていますが、これが現在どのような実装になっているのかが気になるところです。(今回の記事でこちらの件に関しての言及はなかった。)もし、引き続き、Letter Sealingが「テキストメッセージと位置情報の対してのみ」行われているのであれば、こちらは錯誤を招く表示になってしまいますので、こちらは「何が暗号化されるのか」の詳細を知らせて欲しいところです。

次に、せっかくE2EEを実装しているのだから、もっとアピールしてもらいたいところです。現在、定点観測できるいくつかのトークグループがありますが、半分程度、この機能が有効になっていないグループがあり、そのほとんどが恐らくアプリの更新を怠っているのが原因であると考えます。LINEのユーザーは特にユーザー層が広く、技術的リテラシーにばらつきがあり、こちらは更新を促す施策を是非考えて欲しいところです。

なぜGrub2の認証脆弱性は大きな問題ではないか

Linuxのブートローダー、Grub2にバックスペースを28回押すとレスキューシェルに入れてしまうバグがあるということがこの数日報道されています。

脆弱性があるということ自体に問題があるということを否定するわけではありませんが、まず、Grub2を含む、ブートローダーの認証を過信するのが問題です。実質的にブートローダーの起動パスワードが入力できる状態であるということは即ちハード自体へのアクセスがあることを意味します。ハード自体へのアクセスが行えるのであれば、ブートローダーをUSBドライブ経由などから読み込ませて起動すれば、レスキューシェルなど、簡単に実行できてしまいます。ハードのアクセスが物理的に行える以上、この脆弱性が存在しようがしまいが、本質的にはセキュリティには全く影響しないのです。

そのため、セキュリティ問題としてこの問題を解消するには次のような施策が必要になってきます。

  • ハードへの物理的なアクセスを制限する。
  • パーティションを暗号化する。

尚、Grub2の認証機能自体、そもそも幻想のセキュリティを提供する形になってしまっていますので、本来はこんな機能自体削除しまったほうがいいぐらいです。(カジュアルな運用でレスキューシェルへ簡単にアクセスできてしまうこと自体が問題になるのであれば、ブートローダーからレスキューシェルは取り外して、必要に応じてそれを有効にしたブートローダーを外部メディア経由で起動するほうが余程マシな運用です。)

OnionShareを使用した安全なファイル共有

OnionShareを使用することにより、簡単にファイルを共有することができます。

OnionShareはTor秘匿サービスの仕組みを使用しています。秘匿サービスを使用することにより、検閲システム等に影響を受けにくく、また、点から点を暗号化された接続で結ぶことにより、第三者にファイルを預けることなく、Torのネットワークを介して、データを転送することができるようになっています。

OnionShareを使用するのに必要なものは次の二点です。

上記をダウンロードし、インストールした後は、まずはTor Browserを起動します。

TorBrowser

Tor Browserが正常に起動したのを確認した後、OnionShareを立ち上げます。

OnionShare起動後

OnionShareでファイルを選択します。

OnionShareファイル追加後

Start Sharingボタンを押します。(●表示が黄色になります。)

OnionShareファイル公開準備中

●が緑色になったら表示されている.onionアドレスを読み、受信者に伝えます。(そのままコピーすることもできます。)

OnionShareファイル公開

受け取り側はTor Browserを開いて提供された.onionアドレスを開きます。

TorBrowserで表示したOnionShare

ダウンロードのボタンを押すとダウンロードが開始されます。尚、受信者側で次のような警告が表示されることがあります。(既定で表示される。)

TorBrowserダウンロード警告

これはファイルが持つ潜在的な危険性(例えば、実行ファイルなど)を警告するものです。ZIPファイルにはそのようなファイルが入っている可能性があるため、この警告が表示されるようになっています。ダウンロードするだけでは危険はありませんが、内容物に含まれるファイルが匿名性を損なわせる可能性があることを警告している文言です。

OnionShareダウンロード完了

既定では受信者がダウンロードを完了すると、自動的に公開は停止されます。Stop sharing automaticallyのチェックを外すと自動的に停止されないので、複数の人にダウンロードしてもらう場合は、このチェックを外す必要があります。(ファイルの公開が停止された後に、再公開すると別のアドレスが生成されます。)重要なのは相手がダウンロードを完了するまで、OnionShareの共有は有効にしておく必要があります。

このようにファイルを手軽に転送できますが、特徴として以下が挙げられます。

  • 点から点への暗号化接続
  • Torに接続できている限り、ポート転送などの設定は必要なし
  • サイズの制限なし(システム上のファイルサイズの制限などに依存します。転送速度は遅めになります。)
  • Hidden Serviceが備える高い匿名性(ただし、その匿名性は当然.onionアドレスを知らせる手段により変化します。)

恒久的に、特に不特定多数にファイルを提供する場合、Webサーバを使用したHidden Serviceサイトを構築する方がいいですが、手軽にファイルを特定の相手に転送するのには便利かと思います。