だいぶ予定が遅れたようだが、 .NET Core 1.0 の RC2 が5月中旬にリリースされた。
2000年に初めて .NET がリリースされてから、 mono が登場したりといったことはあったものの、 16年越しでついに クロスプラットフォームのアプリケーションを作成できる環境が、マイクロソフト公式から提供された。
ということで、さっそく .NET から VS2015 DotNetCore Tools Preview 1 をインストールして、 Hello World を書いてみよう。
using System;
using System.Text;
namespace netcore_console_test_01 {
public class Program {
public static void Main(string[] args) {
Console.WriteLine("はろー わ～るど！");
}
}
}
…文字化けするぞ!!?
Visual Studio Code 1.1.1 がリリースされた。
先日の 「Visual Studio Code が ついに 1.0 に!! しかし、とんでもローカライズでおかしなことに」 の記事で紹介した不具合が修正されたり、 日本語フォントがだいぶマシになったり、 Markdown のプレビューを横に表示させるコマンドが増えたり、いろいろな変更点が入っている。
その中でも特に私が気に入った変更点は、ユーザ設定で以下のようにウィンドウ幅での折り返し設定にしたときなどが特にわかりやすいのだが、
{
+ "editor.wrappingColumn": 0,
}中日韓の文字が スペースで区切られた部分以外でも、ちゃんと折り返すようになったこと。
文字の幅によっては、少し隙間が空いてしまうことがあるが、それでもかなり見やすくなった。
おかげで、テキストエディタとしてだいぶ優秀になった。
Visual Studio Code 1.0.0
Visual Studio Code 1.1.1
atom エディタなどはこれができなくて、 ところどころ半角スペースの混じった日本語を書いた時の表示が微妙なのよね。
さて、このように複数のバージョンが公開されていくと、古いバージョンを取得したり、その古いバージョンをインストールせずに使用したりしたくなる。
Visual Studio Code は GitHub にて オープンソース で公開されているので、そこから自分でビルドすることもできるが、それはめんどくさい。
過去バージョンについては公式では案内されていないものの、 Win32用 zip アーカイブ版 (いわゆる Portable版 のようなもの) を取得する方法があるようなので、それを紹介しよう。
このたびの熊本地震により、被災された皆さまに心よりお見舞いを申し上げる。
一日も早い復旧、復興を重ねて心よりお祈り申し上げる。
さて、ただお祈りするだけではなく、実際に行動を起こしてこそナンボのモンだ。
そこで、手軽にできて、そして効果の高い ふるさと納税の制度を使った義援金による寄付を行う方法 をステップバイステップで紹介してみようと思う。
「これくらい簡単にできるなら私も…」 と感じて、義援金を送るきっかけにしてもらえれば幸いだ。
先に断っておくが、 「ふるさとチョイス」 というサービスを使って、 「クレジットカード決済」で行う手順を紹介している。
「直接振り込んだ方が、中抜きされず全額義援金として使われて良いのではないか？」という話も一理あるだろう。
しかし、手軽にできることによって寄付してくれる人が増えるのであれば、わずかな手数料が サービス提供会社やクレジットカード会社にいってしまうことなど、 さして問題にする必要はないと考えている。
上記サービスのまわし者ではないことを、宣言しておく。
来たる 7月29日 に Windows 10 の 無料アップグレードが終了してしまうので、 後回しにしていた 自作のデスクトップPC を Windows 7 から Windows 10 にアップグレードしてみた。
実はこの デスクトップPC は、一度 Windows 8 に更新したあと、使いにくかったのと、当時載せていたグラボとの相性が悪かったのもあって、 Windows 7 に戻した経緯がある。
その後、 グラボは新しいモノに取り替えていたので、 Windows 8.x と互換性がよい Windows 10 なら、なんの問題も発生しないだろうと考えていた。
アップグレード前の互換性チェックも問題なく、更新をダウンロードして長いこと待てば問題なく更新される… はずだった。
ところが、Windows 10 へのアップグレードが完了したあと、OS にサインアップしたら、ネットワークに繋がらないではないか!
起動後のアクションセンターの通知で、ご丁寧にも 「Realtek の ネットワークアダプター が Win 10 に対応していないから、機能を無効にした」 などと通知をしてくれていた。
お節介な奴め。
このネットワークアダプターは、 GIGABYTE の マザーボード GA-P55-UD3R のオンボードのものだ。
GA-P55-UD3R は 7年前の M/B なので、当然サポートはとっくに切れており、 Windows 10 はおろか Windows 8 のドライバすら提供されていない。
ただ、それは GIGABYTE サポートサイト上での話だ。
GIGABYTE のサポートサイトによると、 GA-P55-UD3R は Realtek RTL8111D のチップセットを載せている。
幸い、 Realtek のサポートサイトには、このチップセットの Windows 10 用のドライバーが提供されているので、それを USB メモリか何かを経由して、インストールすれば良いのだ。
2016/05/15 現在、 Realtek のサポートサイト上の、 RTL8111D を含めた Network Interface Controllers チップセットのドライバーのダウンロードページはこちら↓
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=4&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false
ドライバーのインストールが完了しても、すぐにネットワークが繋がるわけではない。
Windows 10 アップグレード時に 無効にされたネットワークアダプタは、 ドライバーを更新しても自動で有効にならないからだ。
ご丁寧に、ネットワークアダプタの各項目一つ一つの項目が無効になっているので、必要な機能を有効にしよう。
これで、ネットワークが有効になったはずだ。
しかし… このデスクトップPCは、 7年間使い続けていることになるのか。
SSD を交換したり、 メモリを積みましたり、 グラフィックボード、 Blu-ray ライターをを交換したりはしているものの、それ以外はそのままだ。
Core i5-750, メモリ 6GB, SSD 128GB (+HDD) の構成だが、現状性能に全く不足を感じず、極めてサクサク動いてくれる。（PC上で、リッチなグラフィックのゲームをしないってのもあるが）
2～3年ごとくらいに H/W を刷新しないと 動作がもたついて使い物にならなかった、 2000年代中盤までは考えられなかったことだ。
Visual Studio Code が、ついに 1.0 になった。
Visual Studio Code は、 Microsoft が提供する クロスプラットフォームでオープンソース な IDE 環境だ。
昨年の Build 2015 で電撃発表されたあと、プレビュー版とベータ版が毎月リリースされてきた。
今回の 1.0 では、 一旦カーソル設置後 に Shift+Alt+終了箇所クリック することで 矩形選択 (Column Selection) ができるようになったり、インテリセンスの操作が改善されたりと、エディターとしてもなかなか洗練されてきた。
そして正式版となったのにあわせて、 Microsoft らしく 主要な言語へのローカライズが実施された。
しかし、そのローカライズのせいで、ものすごく操作がしにくくなっている…
| メモ: | この ローカライズの不具合は、 1.1 で無事修正されている。 記事の内容は言語設定を変更する方法として有用なので、記事自体は残しておく。 |
私が使用しているいくつかの node.js 環境 (すべて Windows) の中で、 ほぼ同じ構成の npm パッケージにしているはずであるにもかかわらず、 yo コマンドを実行してからインターフェースが表示されるまでの時間に、大きく開きがあった。 その差、 ほぼ瞬時～数十秒。
正直、 yo コマンド実行する度に数十秒待たされるのは非常にストレスがたまる。
何が問題なのか調べてみた。
デバッガを使って、どの部分の実行に時間がかかっているのか調べてみたところ、 fullname モジュール でユーザ名を取得している部分に時間がかかっていることがわかった。
しかもこのユーザ取得部分、 yo コマンド の引数に ジェネレータ 指定して ユーザ名を表示しないようにしても、 ユーザ名取得は必ず実行されるらしい。
では、この fullname モジュール、いったいどうやってユーザ名を取得しているのだろうか…？
この記事は、 PowerShell Advent Calendar 2015 の 18日目 の記事だ。
私はこれまでずっとネットヒッキーだったので、ネット上でほかの人とのかかわりを持ったことがほとんどなかったが、今回意を決して参加させてもらうことになった。
バリバリの 情シス や プログラマ ではなくても、日常のちょっとした業務で PowerShell を使っている人もいるだろう。
そういったひとびと（主に私）が、組織の中で使えそうだと思ったニッチな話題を書こうと思う。
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 を使ってみようと思う。
自分でローカルで動かして プロジェクト管理 したり、開発環境としていろいろ試してみるために、 Windows に Redmine を極力簡単に 0 からインストールする方法を紹介する。
まずは Ruby が無くては始まらないので、 RubyInstaller つかって Ruby を入れる。
Redmine が使っている Rails を、 gam を使ってインストールするには、 Cコンパイル環境がないといけない。しかし、標準の Windows の環境では残念ながらCコンパイルできない。 このため、 RubyInstaller で公開されている Devkit も入れておく必要ある。 (「はじめてのRuby on Rails3」サポートページ「DevKitの使い方」 のページが詳しい) 続きを読む
対策：SQLite データベースのパフォーマンスの最適化 - Data Storage - 開発ガイド - BlackBerry Java SDK - 6.0 に、「行のサイズを最小限にする： 幅の広い列がある場合、個別のテーブルにすることを検討します。」 なんて改定あるので、実際のところ行サイズはどれぐらいパフォーマンスに影響するのか気になってきた。
せっかくなので、レコードのデータをすべてフィールドにしてしまった場合と、すべて別テーブルにしてしまっている場合と、どちらがよいパフォーマンスを示すのかについて、 RAM メモリ, SSD, HDD でそれぞれ読み書き速度を比較してみた。
あくまで、私の環境においてなので、参考ぐらいにしておいていただければ幸いだ。
一応、以下の様な配置で、bundle 版 System.Data.SQLite.dll を配置していることが前提。