ZoneId を PowerShell を使って一括削除 [v3 以上]

Windows では、リモートからダウンロードしたファイルに、 "ZoneId" という物が付加される。
このID が付加されたファイルは、 exe として 実行する際にセキュリティ警告が表示されたり、 .NET アセンブリ dll として PowerShell に読み込む際に、

Add-Type : ファイルまたはアセンブリ 'file:///*.dll'、またはその依存関係の 1 つが読み込めませんでした。操作はサポートされません。 (HRESULT からの例外: 0x80131515)
発生場所 行:1 文字:1
+ Add-Type -Path 'C:\*.dll'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Add-Type], FileLoadException
    + FullyQualifiedErrorId : System.IO.FileLoadException,Microsoft.PowerShell.Commands.AddTypeCommand

などとエラーになってしまう。
160925_1

ファイルが一つだけなのであれば、ファイルのプロパティから『ブロックの解除』をチェックすれば、簡単に ZoneId を削除することができる。
160925_2
しかし、複数個のファイルの ZoneId を一回の操作で同じように削除することができないため、 ZoneId を削除したいファイルが大量にある場合はなかなかウザい。

PowerShell v3 以上を使えば、この ZoneId 削除をいとも簡単に行うことができるので、紹介しよう。

続きを読む

PowerShell バージョンごとのスクリプティング機能の新機能概略

PowerShell v3 以降のそれぞれのバージョン毎のスクリプティングを中心とした新機能のうち、私の独断で選んだ主な機能を列挙してみた。
(PowerShell の本来の役割のはずの) コンピュータ管理機能などはばっさり省いている。

意外と、そういう情報まとまっているのを見たことなかったので。。。

続きを読む

Python の類似画像ライブラリ ImageHash を Windows で使う

sha1 や md5 等で知られるファイルハッシュは、ファイルの1ビットでも異なると、全く別のダイジェスト値を返すように作られている。

一方で、 画像の情報をハッシュ化する際に、 画像の大きさや微妙な違いには目を瞑って同じような画像は同じダイジェスト値、似たような画像は似たようなダイジェスト値を得たい場合もある。
例えば、大きさの違う画像や、 jpeg, png の形式が異なる画像を 同じ画像として扱うようにしたい場合だ。

そのようなハッシュ関数はいくつか知られている。

  • average hashing (aHash)
  • perception hashing (pHash)
  • difference hashing (dHash)
  • wavelet hashing (wHash)

そのうち、上記の 4つ の計算を行えるのが、 Python の ImageHash ライブラリだ。

このライブラリ自体は ピュアな Python ライブラリなのだが、 依存しているパッケージが総じて C言語拡張モジュールなので Windows で動作させるにはすこし手間がかかる。

そこで、 cygwin 上の python にインストールする場合と、 Windows 上の CPython にインストールする方法をそれぞれ紹介しよう。

以下は virtualenv を使って仮想環境上にインストールする手順とするが、 直接 Python のシステム環境に入れてしまっても問題はない。

メモ: 2017年現在、 pypi でプリコンパイル済みの依存モジュールがダウンロードできるので、以下の方法を使わなくても pippipenv コマンドだけでインストールが完了するはずだ。

cygwin を使う場合

続きを読む

Photon 2 を BungBungame のオンラインショップで買おうとしたら、罠がいっぱいあった

BungBungame Photon 2 という、 台湾企業の日本法人が販売している、Windows タブレットPC がある。
160701_1

これが、

  • Atom Z3775 より強力らしい、 AMD製 64bit CPU (APU)
  • 4GB RAM
  • 1920 x 1200 視野角 178° IPS液晶
  • N-Trig らしい 筆圧 1024レベルスタイラスペン
  • Wi-Fi 802.11a/b/n/ac 対応
  • それでいて、お値段送料込で 23,056円!! (税込み 24,900円)

という、値段の割には夢のような構成なので、なかなか興味深い。 低価格液タブとして考えても破格のお値段。
もともと2014年登場予定で、2015年に発売開始されたものなので、少し古めの機種ではあるが、ぼちぼち使える性能ではあるだろう。 なにより、格安タブレットなのに 64bit マシンで メモリが 4GB 載っているのは頼もしい。

某匿名掲示板で購入者の感想を見てみても、評判はなかなか上々。
(一応、「値段の割に」と注釈がいるが)

我が家の母艦PCが、家族によってペンタブお絵かきマシンとして占領されているうえ、液タブ(Cintiq みたいな高いヤツじゃなくていいから)ほしいとか言い始めたので、こいつに使わせて母艦を奪還するのにもってこいだ。

どうやら OS は Win 8.1 で届くらしいので、 Win 10 無償アップグレード 期間中に手に入れておこうと思い、購入を決意した。

つい先日まで、Photon 2 の購入は、メールでの手続き ・ UFJ銀行 への振込での支払い という、このご時世なかなか珍しい方法だったらしいが、 どうやら最近オンラインショップ機能と、クレジット決済に対応したようだ。
早速これらを使って購入手続きをしてみたのだが… とにかく途中で購入を躊躇する罠がいくつもあった
そんな解説を付け加えながら、方法を紹介してみる。

この記事を読んで、自分も買ってみようと思う方は、自己責任でお願いしたい。

会員仮登録する

続きを読む

git-flow で 「リリースを完了」 「ホットフィックスを完了」 させようとすると、 master にマージされずに失敗する

Git における、有名なブランチの運用モデルのひとつに、 "A successful Git branching model" (日本語訳) というものが存在する。

内容については、「サルでもわかる Git 入門」さんの、以下の解説がわかりやすい。

上記のブランチの運用モデルを簡単に行うための git-flow 拡張が存在し、 Git for Windows 2.5.3 以降に標準で同梱されている。
また、 Git GUI クライアントの SourceTree では、 上記の git-flow が使いやすい UI にまとめられている。

そんな便利な git-flow だが、あるときふと気づいたら、私の手元の環境でうまく動かなくなってしまっていた。

具体的には、
リリースブランチ を完了させた場合、
160625_1
本来であれば、以下のように release/* の内容が masterdevelop ブランチにマージされて タグが作成されるはずが、
160625_2
なぜか master ブランチにマージされずに、 変な場所に タグ が作成されてしまう。
160625_3

リリースを完了させた時だけではなく、ホットフィックスを完了させた場合も同様になる。

不便きわまりない!

原因は 身に覚えのない git config の設定

続きを読む

System.Data.SQLite の NuGet パッケージ のうち どれをインストールするべきか

この記事は、(この記事が初公開された日を基準にして) 4年前に投稿された

の記事のフォロー記事だ。

Visual Studio 2012 に標準で含まれて以降、 NuGet を使ってライブラリパッケージをインストールすることが標準的になった。
しかし、 System.Data.SQLite に於いては、 NuGet パッケージの方も相変わらず多くのパッケージが公開されているので、 これらについてもどれをインストールすべきか解説してみようと思う。 160620_1

Entity Framework Core について書いたひとつ前の記事の

とは異なり、 こちらの記事は Full .NET で SQLite を使う場合で、 特に Entity Framework 6.x と組み合わせる際に有用な内容となっている。
(残念ながら、 System.Data.SQLite は .NET Core では使えないのだ。)

公開されている NuGet パッケージ

続きを読む

DI っぽく EF Core 1.0 + SQLite を Full .NET と .NET Core のコンソールアプリケーションで使ってみる [Entity Framework Core]

しばやん御大の Entity Framework Core についての以下の記事を読んで、


コンソールアプリでも、 ソースコードに 接続文字列 や ログの設定を書かずに、設定ファイルから Dependency Injection (依存性の注入: 以下DI) するにはどうしたらよいのかな? と思ったので、 ASP.NET Core の流儀を参考にしながら やってみようと思う。

データベースは、扱いが簡単な SQLite にする。

記事の最後に、 Visual Studio 2015 ですぐに使えるサンプルプロジェクトを用意しているので、 手っ取り早く結果を見たければ、 そのサンプルプロジェクトを見てみてほしい。

実現すること

まずは、何を実現させるのかをハッキリさせておこう。

  1. 接続文字列と ログ表示の設定を、外のファイルから指定すること
  2. マイグレーションなどを行うため、 EF Tools からも、上記設定が利用されるようにすること

ここで言う EF Tools とは、Entity Framework Core の コマンドラインツール のことだ。
このツールを使うと、 パッケージマネージャーコンソールから Add-Migration とか Update-Database と実行したり、 dotnet.exe から dotnet ef コマンドを 実行することで、 コード生成やマイグレーションなど を利用することができる。

EF Tools でデータベースを取り扱う際、その接続文字列は DbContext に設定されたものが使用される。
コード内に接続文字列を書いてしまうと、マイグレーションするためのデータベースファイルが決め打ちになってしまい、変更ができなくなる。
このため、 EF Tools を実行した際も、依存性の注入が行えるようにしたい。

前準備

続きを読む

PDF のページを好きなサイズの png 画像に変換する たった1つのステップ

document.location = document.getElementById('page1').toDataURL();

Firefox で PDF 開いて任意のサイズで表示し、 開発者コンソール (F12キー) で上記のコード実行すれば、png 画像になって表示される。
あとはその画像を「名前をつけて保存」すればいい。

続きを読む

npm config -g でプロキシの設定をしているのに electron-quick-start や electron-prebuilt でコケる

プロキシ環境下で、 electron-quick-start レポジトリを npm install しようとしたり、 npm で electron-prebuilt モジュールをインストールしようとすると、 npm config set https-proxy "http://proxy.example.com:8080/" とプロキシを設定しているのにもかかわらず、

Error: connect ECONNREFUSED 192.30.252.128:443
    at Object.exports._errnoException (util.js:949:11)
    at exports._exceptionWithHostPort (util.js:972:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1080:14)

などとエラーが出てしまうことがある
特定の通信に、 npm のプロキシの設定が使われていないのだ。

などでは、 netsh winhttp import proxy source=ie のコマンドを実行するといった解決方法が紹介されているが、 これは WinHTTP を使った通信全体に、 IE の proxy の設定をコピーするものであって、今回の問題の本質ではない。

あくまで、 npm config の https-proxy や proxy で設定したプロキシで、エラーとなっている通信を実行させたい場合の解決方法について述べよう。

解決方法

結論を先に言うと、 npm config --global https-proxy ではなく、 npm config https-proxy を使って プロキシを設定する のだ。

続きを読む

VS Express で .NET Core の xUnit.net を使ったテストのデバッグを行う

.NET で 単体テストと言えば、いまや xUnit.net が事実上の標準となっている。
ASP.NET Core や .NET Core のドキュメントでも、単体テストは xUnit.net を使うように案内されている。

ところが Visual Studio の Express Edition 系列 の テストエクスプローラは、 xUnit.net に対応していない。
それでも Full .NET Framework や dnx では、そのままテストプロジェクトを「実行」してしまえば、とりあえずデバッグ実行はできていた。
しかし、 .NET Core + dotnet-test-xunit では、それすらもできなくなってしまい、 dotnet test コマンドの出力を確認するしかなくなってしまった。

デバッグ実行ができないのは流石に不便… ということで、デバッグ実行を行うハックを紹介しよう。

# ライセンス的に Visual Studio Community 使えるのなら、そちらを使うべき。
# ただ、たとえ Express ではなくても、 この方法を使うと xUnit.net の出力が文字化けする問題も防げるぞ。

エントリーポイントを作成し、コンソールプロジェクトにする

続きを読む