写真からもわかるように、本体はLightningコネクタとUSB 3.1 Gen1コネクタがあり、容量は32/64/128GBの三種類。iPhone側の初期設定は、Lightningコネクタへ刺すと、自動的にアプリが選択され、ダウンロード、起動するだけの簡単設計。アップルのMFi認証を取得してるので安心感もある。

初期設定1と2 / アプリ起動

アプリが起動すると、転送、キャプチャ、表示の3択となる（プラス設定）。転送は、本体内の写真/動画をストレージへ、キャプチャは写真/動画をストレージへダイレクトに保存（但し、標準のカメラアプリより機能は劣る）、表示はストレージ内にある写真/動画の再生だ。

設定 / Boltドライブを接続してください / 転送メニュー

USB側はそのままPCやMacに接続でき、ストレージへ転送したデータをコピーしたり、逆にPCやMac側にあるデータをストレージへコピーすることができる。USB 3.1 Gen1なので転送も速い。

さて変わった（？）使い方だが、普段、歩きながらとか、電車などでの移動中に音楽や動画を再生する習慣が無くストレージは写真ばかり。加えてiPhone Xにしたところなので、容量もそれほど減っていない。

付属のラバーケースを使えばキーホルダーにも付けられる

では何故？となるだろうが、それは年末年始、新幹線で帰省するから。流石に、品川/新大阪往復約5時間＋αは長いので、その間、動画を観たい（加えて実家での暇つぶし/笑）。とは言え、期間限定なので、本体側のストレージに入れたくない…的な用途にこれがピッタリ！PCに接続し、適当にフォルダを作って、そこへ大量の動画をコピー。表示メニューから再生すれば、そのまま観ることができる。

この時、少し不満点があるとすれば、動画はサムネイル一覧なので、多くのサムネイルは黒ばかり。これでは内容が分からない。できればファイル名一覧への切替も欲しいところ。

少し変わった使い方だが、年末年始結構楽しめ、新幹線で暇を持て余すことも無く、あっと言う間に到着。その内、本体のストレージがいっぱいになって、本来の用途でも使うだろうが、当面は、これで満足（笑）

もともと以前記事にしたSkylake搭載PCを4GB×2で動かしていた。ただ最近VMを使うので4GB×4で16GBにしたかったのだが、手持ちで余っていたオーバークロック物のDDR4×2を付けるとブートしなくなる。詳しい人に聴いたところ電源ON時の（瞬間的な）電圧が不安定では…と言うことだった。

単純に普通のメモリを購入すれば済む話だが、最近は高騰気味（当時の倍近い）。追加で4GB×2でも、まるまる置き換え8GB×2でも結構なお値段だ。そこで手持ちのメモリを生かすため、古くて使っていないCore2Quad搭載のPCへマザーボードを乗せ換えることにした（写真右。Windows 10のライセンス付きなのでもったいないが、もう1年近く電源すら入れていない）。

余った問題児（笑）

入れ替えて電源を入れたところやはりブートしない。犯人捜しで1枚づつ試したところ一方はOK（メモリの電圧を少し上げる手もあるが）。結局、4GB×3＝12GBで使っている。まぁ、デュアルチャネル作動しないことによるパフォーマンスダウンより、メモリが増えた方がVMにはいいので、とりあえずこれでOK（笑）あとは、メモリの価格が下がった頃に…。< 下がるのだろうか！？

スペック的には7mm厚の2.5インチ、4ch対応SSDコントローラ「88SS1074」、TLC NANDフラッシュ、SATA 6Gbps…といった感じで、1年ほど前に出たもの。スタンダードモデルの「SSDNow」とハイパフォーマンスモデルの「HyperX」の二種類あるが、価格も手頃で用途が用途なだけに前者を選択。

HDD vs SSDなので測定するまでもないのだが、入替前後のベンチマークテストを行ったところ…ご覧の通り。まるで別世界！vmの起動も快適だ。これで作業場に残っているHDDは、NASを除くと1台。64GBほどあればいいのだが、逆に少容量の方が割高だったりする（笑）

余談になるがこの画面キャプチャ、一見CrystalDiskMarkに見えるが、実はmacOS版のAmorphousDiskMark。前者の許諾を得てデザインを同じにしているとのこと。全く違和感もなくGood♪

もともと写真のスタンドには「ALR/JORDAN Entry Si」を置いていたが流石に迫力不足で欲求不満。で、手持ちの「JBL LE8T+EC30」にすると音はGoodなのだが、幅390×高さ590×奥行290mm+10cm角のウッドブロック。2つ置くと大き過ぎて部屋の圧迫感が凄まじい（笑）。

そこで「スタンドに乗る最大のものは」と考え中に何故かNS-10Mを思い出し、測ったらジャスト（＋ちょいα）。状態の良い中古があればその内に程度に思っていた。

ところが夏のある日、渋谷で昼食した後、ぶらぶらと楽器屋巡りをしていたところ、バッタリご対面。状態はまぁまぁ、価格もヤフオク＋α程度だったので、即決して、6Kg×2をハンドキャリー。ご覧のようにスタンドにバッチリ収まり、音も満足♪一時期「YAMAHA NS-1000M」は持っていたものの、それ以来のYAMAHA製だ（聴くのは当時通ったスタジオにあったので耳タコ状態）。

久々に聴いたNS-10Mの音は「これこれ！」的で違和感なくスッと入ってくる。ちょっと驚いたのは、左右はもちろん前後の定位もいいこと。Wadia 151 PowerDAC miniとの相性も問題ない。ただ古いのでネットワークのコンデンサが気になり調べたところ回路図は以下の通り。古典的な12db/octの構成となる。

流石にウーファー側の電解コンデンサ10uF(BP)/50vはもう駄目そうなので近々交換したいと思っている。オリジナルの思想（？）を活かすなら「ニチコンMUSE BP」となるだろうか。音質を取るなら大容量のフィルムコンとなる。コンデンサ2つの交換なので、簡単なのだが、現状でもいい音なので、どうするか悩み中…。

しかし考えてみると、ヘッドホンは「SONY MDR-CD900ST」、イヤホンは「SONY MDR-EX800ST」。昔「JBL 4311A」も持っていた。どうやらモニター系の音が好みらしい（笑）NS-10Mの歴史は、ここにまとまっているので興味のある方は是非♪

プレミアムサービス限定だが（お試し期間でもOK）、ご覧のように見事にSpotifyが作動する。16bit/320Kbpsなので音もなかなかGood♪逆にmoode audio playerは最新版が有料になってしまいちょっと残念…。

これが現在使用中のRaspberry Pi。上に乗っているのは昔作った「DVK-UDA01」。もともとWadia PowerDAC 151 miniにはUSB入力があるので、それに入れていたが、試しにとこのUSB DAC経由でCOAXへ接続したところ、こちらの方が音が良かったため二段重ねになった。記事にあるように「FOX924B」/高精度温度補償型水晶発振器へ改造しているのでその差が出たようだ。

しかし図ったかのようにアドオンになったのにはちょっと笑ってしまった（実は若干幅が狭いものの、スペーサーをうまく利用して固定している）。

話変わって最近、ALR/JORDAN Entry Siからスピーカーを替えたのだが、その話は後ほど（笑）

今回使ったテーマは「Envince」。管理画面、外観/テーマの検索で普通に見つかるものだ。Proバージョンは$69だが、こちらはフリーで使用可能。

選んだ理由として、前のテーマ「twentyseventeen」は、レスポンシブとは言えBootstrapではなく手を入れ辛かったので、今回はBootstrap対応のものを。次にこのTopページを見ればお分かりだと思うが、少し変わったレイアウト編集機能を持つものにした。この手の機能は有料テーマでは一般化しているものの、購入する前に（自作するコストより明らかに安い）少し試して見たかった…と言うのが本音だ。

これがTopページのレイアウト編集画面。固定ページを一枚作り、そこへご覧にWidgetを配置していく感じとなる。投稿一覧だけだと単に日付順に数枚並ぶだけだが、これならカテゴリやタグ、そしてBLOGには無いものさえも意図的に配置できる。少しMagazine風にしてみたが如何だろうか！？

テーマを変更するにあたって最大の問題は、functions.phpに直書きしたshare用のショートコード。metaタグを触る関係でheader.phpにも入っているのでたちが悪い（笑）小テーマのルールに基づき少し変更し無事移植完了。これでテーマの更新があっても上書きされる事もなく、他のテーマにも簡単に引越しできる。

このテーマ、結構気に入っているのだがBUGが一点。ソーシャルメニューをヘッダーもしくはフッターに配置すると、一定の幅以下になった時、右に余白が入る。cssが悪いようだが、直すのは面倒なので使わないことで回避（笑）

仕様として惜しいのは、Widget名の色。テーマ標準とカテゴリ毎でしか設定することができない。タグや別件などはそのままだと標準の色になってしまうのだ。これに関してはcssでダイレクトに色指定することで対応した。

手を入れ易くなったので、このテーマが何日持つかは不明…。そう言えば、複数WordPress一本化サイトも、4つの合体に加えデザインも少し触ったので興味があれば是非！

Buildの日付は2017年5月10日。まず設定パネルが他に合わせてご覧のように新しくなった。

これ自体は良いことなのだが、既存ユーザーは各項目、何が何処へ行ったのか慣れる必要がありそうだ。残念ながらAndroidは6系のまま。7系にはなっていない。

59系一番の売りはJavaScriptエンジンの仕組みを変更したこと。従来JITコンパイラ（Crankshaft）のみだったが、59系搭載のV8 JavaScript Engine: V8 Release 5.9は、インタプリタ（Ignition）とコンパイラ（Turbofan）の組み合わせとなっている。

理屈はここを参考にして欲しい。簡単（？）に言えば、「前段階で一度軽く正書/理解して、その後コンパイルした方が、メモリ効率などが良くなる」と言う話のようだ。

変な例えだが、新人が書いたコードをベテランが見直し、それを使った方が効率がいい…的な話だろうか（笑）CrankshaftはJITコンパイラなので、実行しつつ…となり、また意味合いが違う。

いずれにしても実際操作すると作動もメモリ効率も随分軽くなった印象を受ける（ASUS「Flip C100PA」/2GB）。本家Chromeの59系リリースに期待したいところ。

“マイクロソフトの開発者向けイベントBuild 2017より。マイクロソフトが、Windows 10で動作するLinuxシェルことWindows Subsystem for Linux (WSL)に、OpenSUSE および Fedora Linuxのサポートを追加することを発表しました。WSLではすでにUbuntuが対応していますが、対応ディストリビューションの拡大でユーザーは別のLinuxマシンや仮想マシン(VM)を用意する必要がなくなります。“

Build 2017では、次期Windowsアップデートの「Fall Creators Update」はもちろん、異なるデバイス間でコピペできる「Cloud-powerd Clipboard」、「Fluent Design System」、｢Visual Studio for Mac｣正式リリース、そしてストア版の「iTunes」が発表されたり…と、かなり盛沢山の内容だ。

Introducing the Microsoft Fluent Design System! Draw the right focus to the right thing at the right time. #MSBuild pic.twitter.com/tzHRAb4Pm0

— Windows Developer (@windowsdev) 2017年5月11日

iTunes is coming to the Windows Store by the end of this year. #MSBuild pic.twitter.com/WHM533S7Sv

— Windows (@Windows) 2017年5月11日

中でも「お！」っと思ったのは、WSL（Windows Subsystem for Linux ）に対応するLinuxが増えたこと。

DebiamベースのUbuntuに加え、SlackwareベースのOpenSUSE、Red HatベースのFedoraの名前があがった。これはなかなか嬉しい対応だ。あと一歩完成度があがればほとんどのケースでVMを使わずに済む。

ただRed HatベースはできればCentOSにして欲しかった。ライセンス的な問題だろうか！？

“米Microsoftは2日、Windows 10 Sを標準搭載した学生向けの薄型軽量ノートPC「Surface Laptop」を発表した。米国での予約は既に開始しており、出荷は6月15日。価格は999ドルより。“

まず、Windows 10 Sは、主に教育向けOSとしての位置付けで、アプリはストアからのみインストール可能。どうも仕掛け的に従来のWin32アプリも動くが（標準アプリが入っている）、そのインストーラーが作動せず、事実上ストアからのみ＝UWPアプリのみとなる。

考えようによっては、教育向けだけでなく、企業向けとしても良さそうだ（いらぬアプリを勝手にインストール出来ないという意味で）。必要な機能などをUSBへ入れ、同じ環境を簡単に構築できるのも魅力的だ。

またUWPアプリしか使わない場合、システムをいろいろなファイルで汚さないので、その分、起動も速く、妙なことにもならないメリットがある。

ただ問題は、WebブラウザがEdgeに限定（UWPアプリでフルのWebブラウザが無いため事実上）、更に検索プロバイダが固定でGoogleなどに設定できない。前者はまだしも、後者はやり過ぎと思うのだがいかがだろうか。加えて日本においては、IMEをATOKなどに変更できないデメリットもある。

Surface Laptopは、Surfaceの雰囲気をそのままラップトップにした感じだ。Core i5/4GB/128GBで$999。内容的に割高だがSurfaceシリーズはプレミアム感を醸し出したいのだろう。

OSはWindows 10 S。これだけの高性能マシンに機能限定は常識的にはありえない。10 Proへアップグレード可能（期間限定？）なので、ほとんど10 Proにするのではないだろうか。

Surface Laptopはともかくとして（学生向けで$999以上と言う点も含め）、Windows 10 Sは、Chromebook対抗のSKU。他社から$200前後の安い搭載モデルが登場するとのこと。価格的にAtom系でメモリ2GB、eMMC 32GB…という感じだろうか。

実際、Chromebookを持っているが、この構成だとすると、Chromebookの方がコストパフォーマンスが高い（正直WindowsでAtom/2GBは辛い）。せめて各社メモリ4GBならいいのだが…。

-世界が調和する-

ave;new feat.佐倉紗織、3rdアルバム「Lumina」より約2年半ぶりとなるオリジナルソロアルバム！

ave;newプロデューサーa.k.a.dRESSによる書き下ろし新曲「EDEN or HEAVEN」、佐倉紗織が自ら作詞作曲を手掛けた「everlasting CODE」などアルバム初収録曲を多数収録。
「生命・美・調和」を象徴する極彩色の4thアルバム！！

作品概要

• タイトル：ave;new feat.佐倉紗織 4thソロアルバム 「Tiphereth」（ティファレト）
• 先行販売：M3 2017春、2017年5月4日ライブ会場
• 一般発売：2017年6月2日(金)予定
• 型番：ANCD-1032
• 制作：avenew Co.,Ltd.
• 発売・販売：avenew Co.,Ltd.　

4/30「M3 2017春」にて先行リリース！ave;new feat.佐倉紗織4thソロアルバム「Tiphereth」！カッコイイCMムービーを神月社さんに創って頂きました！！

-世界が調和する-
ave;new feat.佐倉紗織
4thアルバム「Tiphereth」 pic.twitter.com/bZbXAG6qkA

— dRESS@4/30 M3シ-23ab (@dRESS_avenew) April 29, 2017

オフィシャルページはこちら。

レコ発ライブ新作グッズのご紹介その③！B2サイズの大きなポスターを作らせていただきました。ジャケットの写真と、ブックレットにも使用していないポスターだけの写真の2タイプです♪一枚ずつ心を込めてサインを入れましたっ(о´ω`о)お持ち帰りも安心な、箱つきだよー！ pic.twitter.com/BqVW3Ubq6J

— 佐倉紗織♡5/4レコ発ライブ東京♡ (@Saori_Sakura) May 2, 2017

状況からVM側の問題なのは明白。これに対応するParallels Desktop 12のUpdateが公開された。

Updateに関しては、何時も通り「更新をチェック」でインストールされる。またParallels Desktop 11のユーザーは、同様のUpdateが、今月中旬に公開の模様。

ただParallels Desktop 10は対応予定が無く、Parallels Desktop 12へアップグレードしなければならない。

現在、仕事場の環境は、macOS El CapitanとParallels Desktop 10だったが、そろそろどちらも更新の時期かも知れない…。しかしそのきっかけがWindow 10 Creators Updateになろうとは（笑）

ここで「今すぐアップデート」を選択

「Windows 10 アップグレードアシスタント」を実行すると、環境のチェックの後、[今すぐ更新]で更新がはじまる。

完了した割合が100%になると再起動

Bashは、Ubuntu 14系のままだったが、一旦CMD（管理者）からlxrun /uninstall /fullでアンインストールして、再度bashコマンドを実行すると、Ubuntu 16系となる。

Bashの再インストールでUbuntu 16系へ

これからはRS3のフェーズになるため、IPのレベルをしばらく下げて運用しないとシステムが不安定になる可能性があるので要注意！

追記1：Parallels Desktop 10 for Macは一回目の再起動でVMがエラーで停止。12へアップデートか…と思っていたところ、Parallels Desktop 12 for Macでもダメとのこと。10は古いので仕方ないとしても、12でも更新待ちとは（11は不明）。

追記2：Parallels Desktop 12の対応Update出ました！

Part1で使用したasyncモジュールは、いろいろな作動モードがあり、async.seriesで動かした。この場合、callbackが呼ばれるまでは次の処理に進まず、見かけ上、同期作動となる。

ただ考えてみれば、collectionのdrop、各APIの読み込みは非同期で作動しても問題無く、順番待ちをしている時間が無駄になる。従って流れとしては…。

1. 同期用のwp0にあるposts、categories、tagsのdropは非同期だが、全部終わるのを待つ
2. 各APIの読み込みは非同期だが、全部終わるのを待つ
3. 表示用のwpにあるposts、categories、tagsのdropは非同期だが、全部終わるのを待つ
4. 最後にwp0をwpへコピーする

以上の順番さえ守れば、DBの更新に影響なく、加えて、各パートは非同期なので、全てをasync.seriesで行うよりも処理時間が短くなる。このようなケースにはasync.parallelを使用する。

var mongoClient = require('mongodb').MongoClient;
var mongodb_org = 'mongodb://localhost:27017/wp0';
var mongodb_url = 'mongodb://localhost:27017/wp';

var assert = require('assert');
var async = require('async');

var POSTS = 'posts';
var CATEGORIES = 'categories';
var TAGS = 'tags';

var base_url = ['http://blog.iwh12.jp','http://techtalk.pcmatic.jp'];

dbReload();

function dbReload() {
    // drop all collection from wp0
    mongoClient.connect(mongodb_org, function(err, db) {
        assert.equal(null, err);
        async.parallel([
            function (callback) { db.collection(POSTS).drop(function(err) { callback(); }); },
            function (callback) { db.collection(TAGS).drop(function(err) { callback(); }); },
            function (callback) { db.collection(CATEGORIES).drop(function(err) { callback(); }); }
        ], function (err, results) {
            if (err) {
                throw err;
            }
            db.close();
            console.log('drop all collection from wp0.');
            step1();
        });
    });
}

上のvar群は関連するモジュールや変数の宣言で特に説明の必要は無いだろう。ポイントは、async.parallelの部分。wp0の各collectionのdropは非同期で作動し、全部終了した時に、function (err, results)を実行する。

// get all API
    function step1() {
        var api = { tags:'/wp-json/wp/v2/tags', categories:'/wp-json/wp/v2/categories', posts:'/wp-json/wp/v2/posts' };

        async.parallel([
            //site 1
            function (callback) { SetCollection(TAGS, base_url[0], api.tags, function() { callback(); }); },
            function (callback) { SetCollection(CATEGORIES, base_url[0], api.categories, function() { callback(); }); },
            function (callback) { SetCollection(POSTS, base_url[0], api.posts, function() { callback(); }); },
            //site 2
            function (callback) { SetCollection(CATEGORIES, base_url[1], api.categories, function() { callback(); }); },
            function (callback) { SetCollection(POSTS, base_url[1], api.posts, function() { callback(); }); }
        ], function (err, results) {
            if (err) {
                throw err;
            }
            console.log('get all API done.');
            step2();
        });
    }

step1()は、各APIで得たデータをmongoDBに保存する部分だ。前回は順番に行っていたが、今回は5つのAPIの読み込みが非同期作動となる。全て終了後、step2()を実行。

// drop all collection from wp
function step2() {
    mongoClient.connect(mongodb_url, function(err, db) {
        assert.equal(null, err);
        async.parallel([
            function (callback) { db.collection(POSTS).drop(function(err) { callback(); }); },
            function (callback) { db.collection(TAGS).drop(function(err) { callback(); }); },
            function (callback) { db.collection(CATEGORIES).drop(function(err) { callback(); }); }
        ], function (err, results) {
            if (err) {
                throw err;
            }
            db.close();
            console.log('drop all collection from wp.');
            step3();
        });
    });
}

step2()は、wp0をwpへコピーする時、コピー先にcollectionがあると失敗するので、先に3つのcollectionをdropする。dbReload()直後と全く同じで対象がwp0かwpかの違いだけだ。

// db.copyDatabase("wp0","wp")
function step3() {
    mongoClient.connect(mongodb_org, function(err, db) {
        if (err) {
            console.log(err);
        } else {
            var mongoCommand = { copydb: 1, fromhost: "localhost", fromdb: "wp0", todb: "wp" };
            var admin = db.admin();
            admin.command(mongoCommand, function(commandErr, data) {
                if (!commandErr) {
                    console.log(data);
                    console.log('DB Reloaded.');
                } else {
                    console.log(commandErr.errmsg);
                    console.log('DB Reloaded error!');
                }
                db.close();
            });
        }
    });
}

step3()はwp0からwpへDBをまるまるコピーする部分となる。これで一連の流れは完了する。

最後に、APIから得たデータをmongoDBへ保存する＝SetCollection()を掲載する。前回との違いは、フラグを使い中でcollectionをdropする部分を削除している（APIがhttpかhttpsかの判断も追加）。

と言うのも、非同期で作動する場合、記述した順に実行されるとは限らず、dropせずに追記してしまうケースが発生するからだ。今回はこれを避けるため、一番初めにwp0からdropしているのはご覧の通り。

// get data from API and set collection
function SetCollection(collection, base, url, callback) {
    var api_url = base + url + '?per_page=' + 10;
    var max = 0;
    var db;
    console.log('API url: ' + api_url);

    // connect to monogo server
    mongoClient.connect(mongodb_org, function(err, mongodb) {
        assert.equal(null, err);
        db = mongodb;
    });

    // get from API
    getFromAPI(0);

    // get JSON with paginate
    function getFromAPI(n) {
        if (api_url.slice(0,5) == 'https')
            var http = require('https');
        else
            var http = require('http');

        http.get(api_url + '&page=' + (n + 1), (json) => {
            var body = '';

            json.setEncoding('utf8');

            json.on('data', (chunk) => {
                body += chunk;
            });

            json.on('end', () => {
                if (max == 0)
                    max = json.rawHeaders[parseInt(json.rawHeaders.indexOf('X-WP-TotalPages')) + 1];
                var d = JSON.parse(body); 
                db.collection(collection).insertMany(d).then(function(err, r) {
                    console.log(collection, 'page: ' + (n + 1) + ' (' + base +')');
                    if (max == n + 1) {
                        db.close();
                        callback();
                        return;
                    }
                    getFromAPI(n + 1);
                });
            });

        });
    }
}

以前掲載した”WordPress REST APIで得たJSONをNode.jsとMongoDBを使い保存する”に関しても、今回のコードの方がよりロジカルなので、こちらを参考にして欲しい。単一サイトの場合は、step1()のsite 2が不要となる。

Part2で説明するExpress + EJSはmongoDBにwpさえあれば作動するので、今回の部分は別扱いにして、cronを使い一定間隔でDBへリロードするのがいいかも知れない。

実験サイトはこちら。

この時肝になるのが、”APIを使って複数サイトのデータをMongoDBへ保存する方法”と、”post、categories、tagsのIDが被る可能性があるので、それを回避する方法”だ。まずPart1では前者から説明したい。

サイトのソースは、自分のブログと、許可を得て、http://techtalk.pcmatic.jpのブログ、この2つを使っているが（画面キャプチャ上のタイトルがtechtalk.pcmatic.jp、下のタイトルがblog.iwh12.jp）、ロジック上はいくつでも対応可能となっている。

単一サイトからAPIを使いMongoDBにpost、categories、tagsのcollectionを保存するのはもう説明済だが、複数サイトを対象とした非同期での書き込みは、全て完全に終了したのを知るにはいろいろ面倒なことになる。

そこで今回はasync（npm install async）モジュールを使うことにした。使い方は以下の通り。

var async = require('async');
async.series([
    //site 1
    function (callback) {
        SetCollection(TAGS, base_url[0], '/wp-json/wp/v2/tags', true, function() { callback(null,null); });
    },
    function (callback) {
        SetCollection(CATEGORIES, base_url[0], '/wp-json/wp/v2/categories', true, function() { callback(null,null); });
    },
    function (callback) {
        SetCollection(POSTS, base_url[0], '/wp-json/wp/v2/posts', true, function() { callback(null,null); });
    },

    //site 2（tagsは無い）
    function (callback) {
        SetCollection(CATEGORIES, base_url[1], '/wp-json/wp/v2/categories', false, function() { callback(null,null); });
    },
    function (callback) {
        SetCollection(POSTS, base_url[1], '/wp-json/wp/v2/posts', false, function() { callback(null,null); });
    }

], function (err, results) {
    if (err) {
        throw err;
    }
    console.log('Series all done.');

    // response send
    res.send('DB Reloaded.');
});

上から順にAPIが実行され、callbackが呼ばれるまでは次の処理に進まず、見かけ上、同期で作動する。

SetCollectionの4番目の引数はcollectionをdropするかどうか。以前説明したように、DBは差分ではなく、全件保存しなおしているため、2つめ以降のサイトはdropしないようにする。

そしてAPIを処理する側は、http.getのend部分を一部書き換える。追加したのはcallback()。これで一つのAPI呼出しとDBへの保存が終わったことを先のcallbackで知らせ、次の処理へ進むことが出来る。

json.on('end', () => {
        if (max == 0)
            max = json.rawHeaders[parseInt(json.rawHeaders.indexOf('X-WP-TotalPages')) + 1];
        var d = JSON.parse(body); 
        db.collection(collection).insertMany(d).then(function(err, r) {
            if (max == n + 1) {
                db.close();
                callback(); // add
                return;
            }
            getFromAPI(n + 1);
        });
    });

以上で理論上はOKなのだが、実際はAPIを使ったデータの取得が（場合によっては）分単位になるため、DB書き換え中にサイトをアクセスすると、対象となるデータが不完全でエラーとなる。

これを回避するには、同じ構造の同期用DBと表示用DB、2つ持ち、APIでの同期が済み次第、表示用DBへ同期用DBをまるごとコピーするのが手っ取り早い。コードは以下の通り。

// db.copyDatabase("wp0","wp")
mongoClient.connect(mongodb_org, function(err, db) {
    if (err) {
        console.log(err);
    } else {
        var mongoCommand = { copydb: 1, fromhost: "localhost", fromdb: "wp0", todb: "wp" };
        var admin = db.admin();
        admin.command(mongoCommand, function(commandErr, data) {
            if (!commandErr) {
                console.log(data);
            } else {
                console.log(commandErr.errmsg);
            }
            db.close();
        });
    }
});

これはmongoコンソールで、db.copyDatabase(“wp0″,”wp”)とするのと同じ動きとなる。先のAPIでの読み込みをwp0へ行った後、console.log(‘Series all done.’);の後ろにあるこのプログラムでwpへまるまるコピーする。これなら瞬時なので、表示側に影響が出ることは（完全に無いとは言い切れないものの）無いだろう。

但し、表示側（ここではwp）のcollection 3つを先にdropしてからコピーする必要がある。

作動中のサイトはこちら。サイドバーのウィジェットは全てExpressでルーティングしたAPIを使って描画している（Part2で説明予定）。

“中国・北京超卓科技有限公司は3月23日(現地時間)、x86で動作するAndroid 7.1ベースのOS「Phoenix OS」のAlpha版を公開した。“

少し前からあったRemix OSに加え、先日発表されたSamsung DeX、そしてこのPhoenix OSと、ここのところAndroid互換のデスクトップ環境で賑わっている。

Samsung DeXは、Galaxy S8/S8+に搭載。ドックを使ってディスプレイやHIDデバイスを接続可能と、Windows 10 MobileのContinuumにそっくり。

Samsung Dex

Remix OSとPhoenix OSは結構前からあり、今回Phoenix OSはベースがAndroid 7.1となった。デスクトップ化したAndroid互換環境の使い易さはRemix OSで実証済み。しかも現時点で全てマルチウィンドウ対応だ。

Remix OS

対してWindows 10 MobileのContinuumは、RS3までマルチウィンドウはお預け（の予定）で、フルスクリーンのみだとUI的に見劣りする。

Windows 10 MobileのContinuum

いずれにしても圧倒的なAndroidアプリの数を考えると、もはやContinuumは厳しい状況。しかも現在OS自体が32bit版のみ（RS3で64bit版を予定）と、システム的にも出遅れだ。

iOSもmacOSがあるので出すか出さないかは別問題で、プロトタイプは既に作っていると思われる。

昨今PC離れ＝Windows離れと言われているが、これからはスマホからみのデスクトップ環境が面白そうだ。さて、一年後以降はどうなる！？