Visual Studio Code が ついに 1.0 に!! しかし、とんでもローカライズでおかしなことに

Visual Studio Code が、ついに 1.0 になった。

Visual Studio Code は、 Microsoft が提供する クロスプラットフォームでオープンソース な IDE 環境だ。
昨年の Build 2015 で電撃発表されたあと、プレビュー版とベータ版が毎月リリースされてきた。

今回の 1.0 では、 一旦カーソル設置後 に Shift+Alt+終了箇所クリック することで 矩形選択 (Column Selection) ができるようになったり、インテリセンスの操作が改善されたりと、エディターとしてもなかなか洗練されてきた。

そして正式版となったのにあわせて、 Microsoft らしく 主要な言語へのローカライズが実施された。

しかし、そのローカライズのせいで、ものすごく操作がしにくくなっている…

メモ: この ローカライズの不具合は、 1.1 で無事修正されている。 記事の内容は言語設定を変更する方法として有用なので、記事自体は残しておく。

続きを読む

Yeoman の yo コマンドの開始が遅いyo!

私が使用しているいくつかの node.js 環境 (すべて Windows) の中で、 ほぼ同じ構成の npm パッケージにしているはずであるにもかかわらず、 yo コマンドを実行してからインターフェースが表示されるまでの時間に、大きく開きがあった。 その差、 ほぼ瞬時~数十秒。
正直、 yo コマンド実行する度に数十秒待たされるのは非常にストレスがたまる。

何が問題なのか調べてみた。

遅い原因は ユーザ名取得部分

デバッガを使って、どの部分の実行に時間がかかっているのか調べてみたところ、 fullname モジュール でユーザ名を取得している部分に時間がかかっていることがわかった。

しかもこのユーザ取得部分、 yo コマンド の引数に ジェネレータ 指定して ユーザ名を表示しないようにしても、 ユーザ名取得は必ず実行されるらしい。

では、この fullname モジュール、いったいどうやってユーザ名を取得しているのだろうか…?

ユーザ名取得の方法

続きを読む

PowerShell の組織の中で使えそうで使えないニッチな Tips

この記事は、 PowerShell Advent Calendar 2015 の 18日目 の記事だ。
私はこれまでずっとネットヒッキーだったので、ネット上でほかの人とのかかわりを持ったことがほとんどなかったが、今回意を決して参加させてもらうことになった。

バリバリの 情シス や プログラマ ではなくても、日常のちょっとした業務で PowerShell を使っている人もいるだろう。
そういったひとびと(主に私)が、組織の中で使えそうだと思ったニッチな話題を書こうと思う。

  • PowerShell Tools for Visual Studio を商用利用する環境は、無料でできる
  • コンソールウィンドウを極力表示せずにスクリプトを実行
  • ネットワーク共有上の DLL を読み込む

続きを読む

TypeScript の async/await を Electron で使ってみる

TypeScript とは、 いわゆる altJS のひとつで、 ECMAScript (JavaScript) に静的型付けを加えたスーパーセットとなるプログラミング言語だ。
この TypeScript には、 ES6 (ECMAScript 6, Harmony) 相当のコードから ES5, ES3 にコンパイル (トランスパイル) する機能のほか、 ES7 で予定されている一部の機能を先取りし ES6 にコンパイルして使用することもできる。

そんな時代を先取りした機能の一つが "async/await" だ。

"async/await" とは 2012年に C# 5.0 とともに登場した記述方法で、 これを使うと、 非同期な処理を コールバック地獄にならず、 あたかも同期的な処理のように書くことができる。
同様の記述が、最近 Python 3.5 でもサポートされ、これからの非同期処理のスタンダードとなるだろう。

しかし、 TypeScript で async/await を使うには コンパイル後の ECMAScript の実行環境が ES6 をサポートしていなくてはならない。
現行のブラウザのシェアを考えると、 ES6 をサポートしないブラウザ (主に IE, Safari だが) を切り捨てる選択肢はちょっと厳しい。

一方でサーバサイド JavaScript として有名な node.js では、最近になって組織の変更のおかげで開発が活発化し、 ES6 のサポートが入ってきている。
しかし、 node.js はサーバサイドの技術。 クライアントアプリで使えた方がいろいろな用途で使えて夢が広がる気がする。

そこで Electron ですよ。

Electron (旧 Atom-Shell) とは、 Chromium の HTML5 と node.js の技術を使って、クロスプラットフォームのデスクトップアプリを作れるアプリケーションエンジンだ。

JavaScript エンジンごと中に内包しているため、 OS や インストールされたブラウザのバージョンを一切気にせずに HTML5 アプリケーションが作れるという、 IE に苦しめられている諸兄には夢のような技術 (?) だ。
Slack のデスクトップクライアントや、Visual Studio Code なんかも、 Electron を使って作られている。

そしてこの Electron は node.js の技術を使っていると述べたとおり、 ES6 がつかえるではないか!

…ということで、 Electron + TypeScript で async/await を使ってみようと思う。

続きを読む

Redmine + SQLite を Windows で ササっと 0 からインストール する 6つ のステップ

自分でローカルで動かして プロジェクト管理 したり、開発環境としていろいろ試してみるために、 Windows に Redmine を極力簡単に 0 からインストールする方法を紹介する。

Ruby と DevKit と Redmine を落とす

まずは Ruby が無くては始まらないので、 RubyInstaller つかって Ruby を入れる。
Redmine が使っている Rails を、 gam を使ってインストールするには、 Cコンパイル環境がないといけない。しかし、標準の Windows の環境では残念ながらCコンパイルできない。 このため、 RubyInstaller で公開されている Devkit も入れておく必要ある。 (「はじめてのRuby on Rails3」サポートページ「DevKitの使い方」 のページが詳しい) 続きを読む

SQLite の フィールド数 によるパフォーマンス

対策:SQLite データベースのパフォーマンスの最適化 - Data Storage - 開発ガイド - BlackBerry Java SDK - 6.0 に、「行のサイズを最小限にする: 幅の広い列がある場合、個別のテーブルにすることを検討します。」 なんて改定あるので、実際のところ行サイズはどれぐらいパフォーマンスに影響するのか気になってきた。

せっかくなので、レコードのデータをすべてフィールドにしてしまった場合と、すべて別テーブルにしてしまっている場合と、どちらがよいパフォーマンスを示すのかについて、 RAM メモリ, SSD, HDD でそれぞれ読み書き速度を比較してみた。

あくまで、私の環境においてなので、参考ぐらいにしておいていただければ幸いだ。

検証コード

一応、以下の様な配置で、bundle 版 System.Data.SQLite.dll を配置していることが前提。

続きを読む

PowerShell で 配列をシャッフルする

コード

PowerShell で 極力簡単に配列をシャッフル (ランダムにソート) する方法。
速度や制度などはガン無視して、簡単に書けることを重視。

$shuffled = $array | sort -prop @{Exp={[Guid]::NewGuid()}}

ハイ終わり。

検証

ホントに実用的なシャッフルになっているか心配なので、実際に 0~19 のシャッフルを 2000 回行って、先頭に来た数字と、10 が来たインデックスを集計してみる。

$r = 0..1999
$r | %{ $r[$_] = 0..19 | sort -prop @{Exp={[Guid]::NewGuid()}}; }
$r | %{ $_[0] } | group | Format-Table -AutoSize
$r | %{ $_.IndexOf(10) } | group | Format-Table -AutoSize
Count Name Group
----- ---- -----
  104 16   {16, 16, 16, 16...}
   91 19   {19, 19, 19, 19...}
  111 8    {8, 8, 8, 8...}
  102 7    {7, 7, 7, 7...}
   95 18   {18, 18, 18, 18...}
  105 3    {3, 3, 3, 3...}
   95 12   {12, 12, 12, 12...}
   83 15   {15, 15, 15, 15...}
  100 17   {17, 17, 17, 17...}
   89 5    {5, 5, 5, 5...}
  103 13   {13, 13, 13, 13...}
  103 11   {11, 11, 11, 11...}
  101 10   {10, 10, 10, 10...}
  110 4    {4, 4, 4, 4...}
  100 6    {6, 6, 6, 6...}
   88 2    {2, 2, 2, 2...}
  123 9    {9, 9, 9, 9...}
   92 1    {1, 1, 1, 1...}
  107 0    {0, 0, 0, 0...}
   98 14   {14, 14, 14, 14...}

Count Name Group
----- ---- -----
  102 17   {17, 17, 17, 17...}
   93 15   {15, 15, 15, 15...}
  100 9    {9, 9, 9, 9...}
  109 18   {18, 18, 18, 18...}
   91 4    {4, 4, 4, 4...}
  104 5    {5, 5, 5, 5...}
  111 3    {3, 3, 3, 3...}
  107 7    {7, 7, 7, 7...}
   83 1    {1, 1, 1, 1...}
  106 10   {10, 10, 10, 10...}
  101 13   {13, 13, 13, 13...}
   93 8    {8, 8, 8, 8...}
  111 16   {16, 16, 16, 16...}
  101 0    {0, 0, 0, 0...}
   83 2    {2, 2, 2, 2...}
  104 14   {14, 14, 14, 14...}
  103 12   {12, 12, 12, 12...}
   98 11   {11, 11, 11, 11...}
   81 19   {19, 19, 19, 19...}
  119 6    {6, 6, 6, 6...}

だいたい 100 に収束しているし、問題ないんじゃない?

とはいえ、 Guid クラスは、一意性はある程度期待できると書かれているものの、ランダム性は特に言及されていない。
出現にパターンがある可能性もあるし、厳密にランダムである必要がある場合は、使わない方がいいかもしれない。

続きを読む

スクリプト言語などから、共有フォルダにある .NET アセンブリを完全信頼で読み込む

PowerShell や IronPython などで ネットワーク共有フォルダに置かれている .NET アセンブリを読み込むと、このアセンブリのパスが実行ファイルの起動パスと異なるため、部分信頼での実行となってしまい、ファイルの読み書きなどの多くのコードが実行できない。
参考: MSDN | イントラネット アプリケーションの完全信頼での実行

一旦バイナリファイルをメモリに読み込んでから、アセンブリとしてロードするなどと言う方法もあるが、アセンブリからの相対パスなどが利用できなくなったりと、若干使い勝手が悪くなってしまう。

その回避方法として、Vista 以降限定ながら、アセンブリのフォルダをローカルにシンボリックリンクを貼って、そのシンボリックリンクを経由してアセンブリにアクセスすれば、完全信頼として実行することができる。

例えば、複数の PC で同じスクリプトを実行する様な場合、バージョンアップするときに全部の PC をもれなく更新するなど環境をそろえるが面倒だ。
このようなとき、イントラネットの共有ディレクトリにスクリプト置いて、ローカルからシンボリックリンクを通して実行すれば、更新するときはネットワーク共有のスクリプトを書き換えるだけで済み、コードも完全信頼で実行されるので、なかなか便利になる。

サンプルコード

実際に nasne の共有ディレクトリに、ファイルの読み込みを行えるコードを持ったアセンブリを作成して、読み込んでみよう。

続きを読む

Award BIOS で loading operating system から先に進まない

自作 PC でのおはなし。

容量アップもかねて、バックアップを取りながら データドライブに使っている HDD を取り替えたところ、なぜか

loading operating system...

と表示されたまま止まってしまい、OS が起動しなくなってしまった

いろいろ試しているうちに、ブートメニュー (ワタシの M/B だと、起動時に F12 キー押し) からブートするシステムドライブを選択すると、問題なく起動することに気づいた。
そして問題の症状は、ブートドライブ選択時にデータドライブを選んだときと同じ状態。
これは… ブートドライブの選択が間違えられているみたい…

ということで、自動的に本来のシステムドライブをブートドライブとして自動的に選択してくれれば解決なのだが、Award BIOS の設定を探しても、HDD の中でどれを優先してブートするか の設定が見つからない。

少し悩んだ結果行き着いた解決策は、「一旦システムドライブだけ接続してブートさせる」
システムドライブだけ接続すれば、ブートドライブを間違う余地もなく、正常に起動してくれる。
そして一旦自動で選択されたブートドライブは、覚えられるのかなんなのか、次回ブート時に優先して選択されるらしい。
(ブートメニューから手動で選択した場合はダメっぽい)

そもそも、システムの入っていないデータドライブをブーとしようとして止まってしまうこと自体、なんかおかしいのだが、ちゃんと動くようになったので、とりあえずこれで良しとしよう。

※BIOS のメーカやバージョンによって、上記のかなり変わってくると考えられるので、参考にしようと考えている方は注意。

相対パスを指定して、UAC が働く「管理者として」、バッチを起動するショートカットを作る

相対パスを指定して、コマンドやアプリケーションを管理者権限で実行するような、ショートカットを作成したい。

管理者としてでなければ、ショートカットのプロパティで「作業フォルダ」を空白にしておくと、エクスプローラからショートカットを起動したときに、ショートカットの場所がカレントディレクトリ(作業フォルダ)になることを利用して、

"%ComSpec%" /C START "" "<相対パス>" [引数...]

としたショートカットを作成することで実現できる。
(一瞬コマンドプロンプトが立ち上がる問題は、「実行時の大きさ」を最小化にしておくことである程度回避可能)

ところが、ショートカットの詳細設定から「管理者として実行」を選んでしまうと、カレントディレクトリが %SystemRoot%\system32 へ勝手に変更されてしまう。
こうなると、上記のショートカットでは %SystemRoot%\system32 からの相対パスを開こうとするため、意図した動作にならない。

このため、 UAC を起動させる ものと、カレントディレクトリの情報を渡す ものの 2つのショートカットを作成することで実現させる。

START コマンドを使うので、内容を理解する場合はこのコマンドのヘルプをよく読み込んでおくと良いかも知れない。

START ["タイトル"] [/D パス] (中略) [コマンド/プログラム] [パラメーター]

    "タイトル"  ウィンドウのタイトル バーに表示するタイトル。
    パス        開始するディレクトリ。

    コマンド/プログラム
                内部コマンドまたはバッチ ファイルの場合、コマンド プロセッサ
                は cmd.exe の /K オプションを使用して実行されます。
                これは コマンドの後でもウィンドウが残ることを意味
                します。

                内部コマンドまたはバッチ ファイルではない場合、そのプログラム
                はウィンドウ モードのアプリケーションまたはコンソール
                アプリケーションとして動作します。

   パラメーター
               コマンド/プログラムに渡すパラメーターです。

UAC を起動させるショートカット

まずは、指定した プログラム/コマンド を パラメータ付きで 管理者として実行するショートカットを作成する。

以下の様にプロパティを設定したショートカットを作成しよう。

続きを読む