よくアニメの特典映像なんかであるあれ、やってみた。
カテゴリー: ソフトウェア
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を購入したのでいろいろと。
まずはそれぞれのツールに関していろいろと書いてみる。
Rider
まずいちばん使っているのがこのRider。C#のIDEです。現段階で使っているのは.NET Core 2.0の機能を使いたいので、EAP版です。
ちなみにRiderはUnityと組み合わせ使うことも可能です。Linux版のUnity Editorと組み合わせて使用する場合に便利です。
機能面ではVisual StudioとResharperを組み合わせたものに近いです。（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 UltimateはJavaのIDEです。（正確にはJVMな言語は多くが対応しています。KotlinもJetBrainsが開発していますし、もちろん対応しています。）
尚、IntelliJ IDEA Ultimateにはオープンソース版のIntelliJ IDEA Communityも存在します。これ一本でJavaのアプリ、Androidのアプリなどを開発したりできます。プラグインを通してGoやPythonなどの他の言語も開発することができるようですが、挙動など言語特化のIDEがより言語に特化した動作をするようになっているようです。
個人的にはJavaはあまり使わないので、XSLTの編集などに使ったりする場合が多いです。
PyCharm Professional
PyCharm ProfessionalはPythonのIDEです。。こちらもPyCharm Communityというオープンソース版の他、PyCharm Eduという教育目的に特化した特別版も存在します。
PhpStorm
PhpStormはPHPのIDEです。あまり新規にPHPは少なくとも自分で書くことは少ないのですが、レガシーなコードはあるのでその保守に使用しています。
CLion
CLionはC/C++のIDEです。Linux上で時々C/C++を扱ったりするので、その場合に活用しているツールです。
RubyMine
RubyMineはRubyのIDE。Rubyのコードは現在PHPよりも少ないのであまり出番はないですが……。
MPS
イマイチ使い方がよくわかっていないのが、このMPS。IDEというよりはメタ言語みたいなのですが……。
JetBrainsのAll Products Packは開発機材として個人的に買う場合は、そこまでは高くはないのですが（ビジネスとして買う場合はそれなりに高くなりますが……）それなりの額にはなりますが、今のところはその値打ちはあるように感じています。特に複数の言語を使う必要がある場合同じ使用感で複数の言語を扱えますので。
以前、これまで、LINEのE2EE実装「Letter Sealing」初見、LINEのLetter Sealingに関するフォローアップと2回に渡り、LINEのE2EE実装である、Letter Sealing機能に関して取り上げてきたわけですが、以前にも増してメッセンジャーにおけるE2EEが一般的になってきました。以前はE2EEを実装したメッセンジャーアプリはSignalやTelegramぐらいしかなかったのですが、今では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のユーザーは特にユーザー層が広く、技術的リテラシーにばらつきがあり、こちらは更新を促す施策を是非考えて欲しいところです。
Linuxのブートローダー、Grub2にバックスペースを28回押すとレスキューシェルに入れてしまうバグがあるということがこの数日報道されています。
脆弱性があるということ自体に問題があるということを否定するわけではありませんが、まず、Grub2を含む、ブートローダーの認証を過信するのが問題です。実質的にブートローダーの起動パスワードが入力できる状態であるということは即ちハード自体へのアクセスがあることを意味します。ハード自体へのアクセスが行えるのであれば、ブートローダーをUSBドライブ経由などから読み込ませて起動すれば、レスキューシェルなど、簡単に実行できてしまいます。ハードのアクセスが物理的に行える以上、この脆弱性が存在しようがしまいが、本質的にはセキュリティには全く影響しないのです。
そのため、セキュリティ問題としてこの問題を解消するには次のような施策が必要になってきます。
- ハードへの物理的なアクセスを制限する。
- パーティションを暗号化する。
尚、Grub2の認証機能自体、そもそも幻想のセキュリティを提供する形になってしまっていますので、本来はこんな機能自体削除しまったほうがいいぐらいです。(カジュアルな運用でレスキューシェルへ簡単にアクセスできてしまうこと自体が問題になるのであれば、ブートローダーからレスキューシェルは取り外して、必要に応じてそれを有効にしたブートローダーを外部メディア経由で起動するほうが余程マシな運用です。)
OnionShareを使用することにより、簡単にファイルを共有することができます。
OnionShareはTor秘匿サービスの仕組みを使用しています。秘匿サービスを使用することにより、検閲システム等に影響を受けにくく、また、点から点を暗号化された接続で結ぶことにより、第三者にファイルを預けることなく、Torのネットワークを介して、データを転送することができるようになっています。
OnionShareを使用するのに必要なものは次の二点です。
- OnionShare(送信者のみ)
- Tor Browser
上記をダウンロードし、インストールした後は、まずはTor Browserを起動します。
Tor Browserが正常に起動したのを確認した後、OnionShareを立ち上げます。
OnionShareでファイルを選択します。
Start Sharingボタンを押します。(●表示が黄色になります。)
●が緑色になったら表示されている.onionアドレスを読み、受信者に伝えます。(そのままコピーすることもできます。)
受け取り側はTor Browserを開いて提供された.onionアドレスを開きます。
ダウンロードのボタンを押すとダウンロードが開始されます。尚、受信者側で次のような警告が表示されることがあります。(既定で表示される。)
これはファイルが持つ潜在的な危険性(例えば、実行ファイルなど)を警告するものです。ZIPファイルにはそのようなファイルが入っている可能性があるため、この警告が表示されるようになっています。ダウンロードするだけでは危険はありませんが、内容物に含まれるファイルが匿名性を損なわせる可能性があることを警告している文言です。
既定では受信者がダウンロードを完了すると、自動的に公開は停止されます。Stop sharing automaticallyのチェックを外すと自動的に停止されないので、複数の人にダウンロードしてもらう場合は、このチェックを外す必要があります。(ファイルの公開が停止された後に、再公開すると別のアドレスが生成されます。)重要なのは相手がダウンロードを完了するまで、OnionShareの共有は有効にしておく必要があります。
このようにファイルを手軽に転送できますが、特徴として以下が挙げられます。
- 点から点への暗号化接続
- Torに接続できている限り、ポート転送などの設定は必要なし
- サイズの制限なし(システム上のファイルサイズの制限などに依存します。転送速度は遅めになります。)
- Hidden Serviceが備える高い匿名性(ただし、その匿名性は当然.onionアドレスを知らせる手段により変化します。)
恒久的に、特に不特定多数にファイルを提供する場合、Webサーバを使用したHidden Serviceサイトを構築する方がいいですが、手軽にファイルを特定の相手に転送するのには便利かと思います。
9月1日にLINEのE2EE実装「Letter Sealing」初見という記事を書いて、そこに
（公式情報が投稿され次第、加筆などはする予定です。）
と書きましたが、本日、メッセージの安全性新時代：Letter Sealingという記事が公式ブログのLINE Engineers’ Blogで公開されてますので、公約通り、加筆します。
基本的、公式サイトで解説されているのはLetter Sealingはごく一般的な公開鍵暗号方式が使用されているということです。鍵交換方式はECDH、暗号化はAES-CBC-256、HMACと、方式的にはOpenPGPなどで使われている機構とそう変わりません。(ECDHはちなみにGnuPG 2.1で対応しています。)
ここで気になってくるのはECDHを使っているという表記。もし、これを額面通りに受け取るのであればLINEの実装はPerfect Forward Secrecyを実装していない、ということになります。(もし実装しているんであれば、DHEなり、ECDHE使ってますって書くよね？)
PFSは最近のメッセンジャーの暗号化の実装では一般的なもので、セキュリティを高めるのに非常に重要な要素なので、この実装はぜひ検討していただきたいものです。
また、前回の記事でも指摘したように、メッセージが暗号化されているかどうかがわからないのがこのシステムの致命的なところですが、それに関しては修正が検討されているようなのでよかった。
なお、この手の情報を一般向けに取っ付き易く説明するのは非常に骨の折れる話です。LINEのエンジニアのブログではそのあたり、結構丁寧に解説しているので、この点は非常に賞賛できると思います。
（2016年2月22日更新）この問題を修正する変更が開発者により行われ、すでにソースコードに取り込まれています。この変更が実際のリリースに適応されるのにはしばらく時間がかかりますが、近いうちに修正が入るものと思われます。
最近のGoogle Chromeに、すでに何件か報告されている問題で最近原因が解明されたものがあり、その問題と取り敢えずの対処法に関してまとめます。
どういう問題なのか
Google Chromeのアドレスバー（Omnibox）の入力レスポンスがものすごく遅くなります。スペックにもよりますが、具体的には一文字入れるとそれが出てくるまでに数秒を要する、といった具合です。極端な場合には多大な遅延のせいで、入力される文字の順番が入れ替わってしまう場合もあります。（例えば、google.comと入力したつもりがgogole.cmoとなるなど）
また、インターフェース自体の再描画も全体的にもっさりとするため、メニューを開くのに遅延が出るなどの問題が発生し、全体的にGoogle Chromeメインプロセスが消費するCPUが高くなる傾向にあります。
原因は？
バグが報告されていたものの最近までその原因は特定はされていませんでした。1月6日にChromiumプロジェクトのKochi氏がこの問題がフォントのキャッシュがフォントのフォントファミリー名による参照によりキャッシュされていないとみなされ、再キャッシュプロセスが発生してしまうのが原因で発生しているということが報告されました。
つまり、まとめると以下のようになります。（Kochi氏が指摘する源ノ角ゴシック JPを使用した場合）
- Google Chromeが源ノ角ゴシック JPを使用してフォントをレンダリングしようとする
- Google Chromeが源ノ角ゴシック JPを使用しようと、そのフォントファミリー名のSource Han Sans JPで参照しようとするが、キャッシュされていないと見做し、キャッシュ動作（非常に重い）が発生する
というようなプロセスが発生し、これが一文字入力されるごとに発生していた、という問題のようです。
尚、上記に併せ、同氏によりコードの修正レビューが提出されていますが、すでにこの修正を含む、書き換え自体が予定されていることもあるようで、パッチとしての適応はされないようです。そのため、根本的な解決にはしばらく時間を要すると予想されます。
回避策
根本的な解決はコードに対処が入るまで行わられないものの、取り敢えず回避することは可能です。基本的にフォントのファミリー名が問題にならないフォントを使用すればいいわけです。尚、こちらで実験したところ、IPAフォントとその亜種ではこの問題が発生してしまうようです。（日本語環境ではこれらが指定されていることも多いでしょうから、この問題にあたってしまう人も多いかもしれません。）
回避方法
前述のように、この問題の影響の受けないフォントに置きかえてやるのが回避する方法になります。Gnomeを使用している場合、gnome-tweak-toolを使用し、UIが使用するフォントを問題のないものに置きかえる必要があります。gnome-tweak-toolは標準ではインストールされていないので別途インストールが必要です。
KDEの場合kde-config-gtk-styleをインストールした上で、外観設定の中のGTK設定のフォントを変えることで対応できます。
フォント設定を例えば、Noto Sans CJK JPなどに置き換えることで対応可能です。
この変更を行い、右下の適応ボタンを押すことで変更が保存されます。尚、Google Chromeに対し、この変更を有効にするためには変更した後に、Google Chromeを再起動する必要があります。
この記事はBlender Advent Calendar向けに作成しました。本稿は元々Analyzing NDVI Imagery Using Blenderとして投稿していたものに加筆修正を加えたものです。
Blenderの本領である3D作成とは違った趣向ですが、レンダリングノードがどのくらい汎用性があるか、ということに関して示すことができましたら嬉しいです。
先ずはNDVIに関して軽く解説。NDVIはNormalized Difference Vegetation Indexの略で、正規化植生指標という植物の量や活力を表す値です。具体的には赤の可視光と近赤外線を測定することにより得る値となります。
国土環境モニタリングのページにその計算方法などが掲載されています。
どのようにして撮影するのか
一般的なカメラの素子は赤外線を捉えることができますが内部にそれを遮断するフィルタが入っており、そのまま撮影しても必要な光成分はほとんど撮影されません。Public Labはそれを分光するためのフィルタを販売しており、それを使用し、カメラを改造するか、改造済みのカメラを入手することができます。このカメラでは赤外線成分を赤チャンネル、可視光線を青チャンネルに記録します。
基本的原理は同じなので、衛星などの元データなどのデータも流用可能かとは思いますが、データ構成により調整を行う必要があるかもしれません。
Blenderを使用しての処理
ここで使用する画像はInfragramカメラに付属のサンプル画像を使用します。このカメラで撮影すると、以下のような画像が撮影できます。
NDVI画像を抽出するのにはノードでNDVI変換を定義しました。
このノードグループからは以下のような出力が得られます。この画像をColor Rampなどと合成することにより擬似色画像を構成することができます。
以下はColor Rampを当てはめた例です。活性度に応じて白や緑に表示されています。
Public Labでは撮影した画像を処理するサービスがありますが、Blenderで処理することにより同様の画像をローカルに処理することができます。
Blenderではノードを設定し、組み合わせることで、目的に応じた映像を出力することができます。
例えば以下は白黒の可視光線画像にNDVI画像を合成した画像です。
この画像では植物が活発と思われる部分がはっきりとハイライトされるため、存在する植物などを表示することができます。
以下、使用したBLENDファイルです。
infragram-2014082702.blend.zip
BlenderでNDVI処理する利点
- 柔軟性のある加工を施すことができる。
- Packすることにより、共同作業者などと単一のファイルをやりとりすることができる。
- NDVI動画画像も静止画と同じぐらい簡単に加工可能。（タイムラプス映像や気球映像などの加工も容易）ただし動画を使用した場合現状Packされないことにご留意下さい。
- 非破壊的に処理を加えることができるため、処理の切り替えができるほか、またどのようにして最終画像に至ったかということがファイルに含まれるため、いわば自己ドキュメンティングなファイルを配布することができる。
応用
同様のプロセスを使用して、その他の分野の加工でも、光成分に関する加工を行うことができます。カラーランプは色を一定の色のスケールに割り当てることができるため、例えば犬から見た景色、などもシミュレートしてみることが可能です。
明日はnecoganeさんのテクスチャ作成方法（自己流）について、ということです。