まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:windows

Windows 10 で kubernates の開発環境を構築する際の方法の1つとして、以下のケースで構築する場合のメモです:
・Kubernetes 本体は minikube を使って Windows 10 に導入
・kubectl は WSL から利用


Kubernetes 本体はローカルで動く minikube を使ってシングルノード環境を構築します。この部分は正しく導入できていさえすれば Windows だろうが、Linux だろうが、Mac だろうが、システム環境の違いを意識することはあまりないと思っています。 ただ実際に利用する段になって kubectl コマンドを実行する環境としては Windows よりもより実践に近い Linux を使いたくなります。というわけで、Windows 10 の WSL (今回は Ubuntu を想定)から利用できるようにしました。

なお、この環境構築をする場合のマシンスペックとして、メモリ 8GB だと構築して minikube start した時点でほぼメモリを使い尽くしてしまいます。動作確認するだけならいいのですが、本格的に開発して動作確認してテストして・・・という段階まで考えるとやはり 16GB くらいはほしいところです。


【前提条件】
- Windows 10
- WSL(Ubuntu 18.0.4) 導入済み


【VirtualBox のインストール】
Windows 10 で minikube を動かす場合、仮想環境のハイパーバイザーが必要です。今回は VirtualBoxを使います。VirtualBox 自体のインストールはごく普通に公式ページから Windows 版をダウンロードし、デフォルト設定のままインストールすればOKです。


【Windows 版 minikube のインストール】
minikube の Github ページから、Windows/amd64 版の minikube 単体をダウンロードします:
2019090801


ダウンロードしたファイルは minikube-windows-amd64.exe というファイル名になっていますが、これを minikube.exe とリネームしてファイルシステムの適当なフォルダに保存します(以下は C:\MyApps\minikube\ というフォルダを作成して、その中に C:\MyApps\minikube\minikube.exe という名前で保存しているものと仮定して以下を続けます)。

このフォルダに PATH を通します。Windows + S キーを押して検索ボックスに「システムの詳細設定」と入力すると「システムの詳細設定の表示」が見つかるので、これを選択します:
2019090802


システムのプロパティウィンドウが表示されたら、「詳細設定」タブを選択し、「環境変数」ボタンをクリック:
2019090803


ユーザー環境変数の Path を選択してから「編集」ボタンをクリック:
2019090804


そして「新規」に minikube.exe が保存されたフォルダ名を追加して、最後に OK ボタンをクリック。これで minikube.exe に PATH が通りました:
2019090805


念の為、動作確認してみます。コマンドプロンプトを起動して、 "minikube version" と入力して実行します。minikube のバージョン番号が表示されれば、ここまでの手順は OK です:
2019090801


【minikube の起動】
コマンドプロンプトから "minikube start" と入力して、minikube を起動します。自動的に必要な VM イメージを見つけて(初回はダウンロードして)自動構築します。通常は minikube が kubectl を見つけてくれるのですが、この方法だと(Windows 版 kubectl を使わない&インストールしていないので)見つからない、という警告が表示されますが、今回は WSL 側に kubectl を用意するので無視します:
2019090802


【WSL に kubectl をインストール】
WSL を起動し、以下のコマンドを入力して kubectl を(/usr/local/bin/ 以下に)導入します:
$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl

$ chmod 755 kubectl

$ sudo mv kubectl /usr/local/bin

最後に "kubectl version" を実行して動作確認します(初回は Client Version が表示されれば OK です):
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:13:54Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

【minikube のエンドポイント情報の取得】
コマンドプロンプトに戻って、"minikube status" を実行し、minikube のエンドポイント情報を確認します。以下の例では 192.168.99.100 というアドレスが表示されていますが、これにポート番号 8443 を加えたもの(192.168.99.100:8443)がエンドポイントとなり、以下で利用することになります:
2019090803


【kubectl の設定】
上記で取得したエンドポイント情報を使って kubectl の設定を行います。WSL から以下のコマンドを順次実行します。なお以下で <コマンドプロンプト実行時のユーザー名> と表示されている部分にはコマンドプロンプト実行時のユーザー名がフォルダ名の一部になっているのでそれをそのまま指定します(上記の画像例の場合であれば、ここには KEIKIMURA が入ります)、また 192.168.99.100:8443 部分は上記で取得したエンドポイント情報です:
$ kubectl config set-credentials minikube --client-certificate=/mnt/c/Users/<コマンドプロンプト実行時のユーザー名>/.minikube/client.crt --client-key=/mnt/c/Users/<コマンドプロンプト実行時のユーザー名>/.minikube/client.key

$ kubectl config set-cluster minikube --server=https://192.168.99.100:8443 --certificate-authority=/mnt/c/Users/<コマンドプロンプト実行時のユーザー名>/.minikube/ca.crt

$ kubectl config set-context minikube --user=minikube --cluster=minikube

$ kubectl config use-context minikube

最後に WSL で "kubectl cluster-info" コマンドを実行して動作を確認し、エンドポイントで正しくクラスタ状態が取得できれば kubectl の設定完了です。シングルノードの kubernetes (kubectl) がローカルの WSL から使えるようになりました:
$ kubectl cluster-info

Kubernetes master is running at https://192.168.99.100:8443
KubeDNS is running at https://192.168.99.100:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.



(参考)
https://dokupe.hatenablog.com/entry/20180408/1523116886

むかーし、むかし、ダイアルアップ接続という仕組みがありました。。
hqdefault


現在ではスマートフォンが直接インターネットに接続され、スマートフォンだけでインターネットサービスを利用することができるようになりました。PC もインターネットに常時接続している職場や自宅から有線/無線 LAN を経由してインターネットに接続できる環境が整っています。

ただ(特に自宅で)このようなインターネットへの常時接続環境が整ったのは ADSL が普及しはじめた 2000 年代前半からでした。一方で、その前からインターネットは多くのユーザーによって利用されていました。特に「インターネット接続機能が標準搭載された」 Windows 95 (1995)の発表からインターネットの利用者が増えたのではないかと思っています。ではスマホや常時接続環境がまだ存在してなかったこの頃、どうやって自宅からインターネットを利用していたのでしょうか?

その答が冒頭のダイアルアップ接続でした。簡単にいうと電話線(携帯電話回線ではなく、自宅のアナログ回線)を通じてプロバイダと呼ばれる業者に電話をかけて接続し、電話回線を使ってデータを送受信する、という仕組みを使っていたのでした。今から 20 年ほど前、個人がインターネットを利用するにはほぼこの方法を使っていました。ダイアルアップ接続をするには(通信そのものは電話の音声回線を使うため)モデムと呼ばれる音声通信データとインターネット通信データとを変換する機器が必要になります。当初はモデムは PC 本体とは別に購入・接続する必要があったのですが、後にモデムは PC に内蔵されることが大半となる時期もありました。また公衆電話にもインターネット通信を行う前提で PC(モデム)との接続インターフェースを持つものが多く設置されていました:
20190620


さてノスタルジックな話はここまで。ここからが本ブログエントリの本番です。

このダイアルアップ接続は現在ではほぼ使われていないと理解していますが、仕組みとしては 2019 年の現在も残っています。モデムは(以前のシリアル接続ではなく USB 接続のものばかりですが)新品が入手できます。また以前ほど多くはありませんが、現在もダイアルアップ接続を提供するプロバイダーは存在しています。自宅に固定電話回線を持っていない人が増えているかもしれませんが、上述のモデム接続インターフェースを持つ公衆電話も(わずかですが・・)残っています。

というわけで 2019 年の今、あえてダイアルアップ接続がどこまで使えるのかを試してみました。一部ネタバレを先に言ってしまいますが、想像以上に出費があったので好奇心だけで真似するのはあまりオススメしません(笑)。以下、準備段階も含めたその記録です。


【PC】
これはほぼ「なんでも可」だと思います。条件を付けるとすれば「後述のモデムが接続できるもの」です。昔のモデムは RS-232C ポートを使ってシリアル接続するものが多かったのですが、最近のモデムは「ほぼ USB 接続」です。シリアル接続のモデムを使う場合のみ、シリアルポート付き PC を用意してください。ちなみに今回は Windows 10 Pro が導入されている GPD MicroPC を使いました(最近では珍しいシリアルポート付きラップトップ PC ですが、今回は USB 接続のモデムを使っています):


【モデム】
モデムの入手に苦労することを想像していたのですが、あっけないほどアマゾンで見つかります。「持ち運び時に邪魔にならない小さいのがいいな」程度の理由で、自分が購入したのは AGPtek の USB 2.0 FAX モデムです:




電話機とモデムとを物理的に接続する線(6極2芯ケーブル)も付属しているので、PC とこの箱ごと持っていれば公衆電話でもダイアルアップ接続できます。またドライバ用の CD が付属していましたが、PC の USB に接続した所、特別な作業もなく(標準ドライバで)正しく認識できました。ドライバ CD は使っていません。

なお通信の最高速度は 56kbps です。「ま、今もたまにマイネオの低速通信(200kbps)を使ってツイッターやってるし、この位でなんとかなるんじゃね?」と軽く考えていました。が、後にここが最大の苦難になるとは・・・


【プロバイダ】
ダイアルアップ接続をするには、ダイアルアップ接続に対応したインターネット・サービス・プロバイダ(ISP 、以下「プロバイダ」)と契約する必要があります。常時接続と異なり、接続中は通話料金が発生するので、昔は同一市内にアクセスポイント(=電話先)を持っているプロバイダを選んで契約するのが一般的でした。

2019 年6月時点でダイアルアップ接続サービスを提供しているプロバイダを検索するといくつかありました。自分はその中から @nifty を選びました。@nifty でのダイアルアップ接続やセットアップの方法はこちらに公開されています(Windows 10 が対象に含まれていないようでしたが、結論としては問題なく接続できました)。なお公衆電話から接続する場合は公衆電話専用番号が用意されているようで、こちらの番号でないと接続できないようでした。また @nifty でダイアルアップ接続する場合のアクセスポイントの電話番号や料金は全国共通のようです。契約さえしておけば、どこからでも同一料金で利用することができる、ということになると思います。

ちなみに @nifty のアカウントを作るのは NIFTY Serve 時代も含めると3度めです。困った時の @nifty 様!



【ISDN 公衆電話】
自宅電話や公衆電話そのものを使ったことがない人がちらほら存在しているのではないかと思いつつ、、、今回は公衆電話からプロバイダへのダイアルアップ接続を行います。公衆電話そのものが以前ほど見かけなくなっている印象ですが、ダイアルアップ接続を行うには「グレー電話」とも呼ばれている、専用の公衆電話を利用する必要があります:
upload_0001_20141009
(↑左のタイプではなく、右のタイプの公衆電話を使う必要があります)


この「アナログ」という口に6極2芯の電話ケーブルを挿してPCと繋げて・・・
2019061901



このグレー電話を探すのが意外と大変でした。記憶の中に「そういえばあそこに公衆電話があった。あそこにもあった」と、公衆電話自体は存在場所をいくつか把握していたのですが、そのほとんどがグレー電話ではない、緑の公衆電話でした。数少ない公衆電話の中から更に珍しいグレー電話を探す必要があり、これが想定以上に手間取ってしまいました。

自分はJR津田沼駅北口のこの辺り↓で、2台存在する公衆電話のうちの1台がグレー電話であることを発見しました(ストリートビューはこちら):
2019061801


【テレホンカード】
公衆電話といえば「テレホンカード」です。知らない人のために書いておくと、公衆電話に必要な料金は10円単位で支払う必要があり、10円玉か100円玉を用意する必要がありました(これ以外の硬貨や紙幣は使えません)。またお釣りは出ません、つまり100円硬貨を入れて仮に20円ぶんしか通話しなくても80円のお釣りが出てくるわけではないのです。この点については現代でも変わっていません。

そんな不便な中、長時間通話をする人の多くはテレホンカードを使っていました。これはプリペイド式の公衆電話用カードです。通話で使ったぶんだけが度数として引かれます。今もコンビニなどで売られていますが、僕が購入したお店では105度数(1000円で1050円ぶん使える)のカードしか取り扱っていませんでした。本当は50度数(500円で500円ぶん使える)カードでよかったのですが、仕方なくこれを購入しました:
2019061801


【コントロールパネル】
残された準備はソフトウェア的な設定でダイアルアップ接続ができるようにするだけです。Windows 10 どころか XP あたりからダイアルアップ接続を使った記憶がないんだけど。。

今回の例では Windows 10 で @nifty にダイアルアップ接続するための設定を作成します。といっても、手順はほぼこちらで紹介されている通りです(Windows 7 用ですが、10 でもほぼ一緒):
https://support.nifty.com/support/manual/internet/dialup/setup/win7.htm


注意点として、上述しましたが @nifty の場合は公衆電話回線用の専用電話番号が用意されている、という点です。今回のようにグレーの公衆電話を使ってアクセスする場合は公衆電話用アクセスナンバー(0570-054-300)を指定する必要がある点に注意が必要です。


【いざ接続!】
事前に必要な準備は全て整いました。PC にモデムを接続し、グレー電話とケーブルで接続:
2019061902


いざダイアルアップ接続!・・・・



遅っ! 接続完了まで40秒もかかるの!?

ともあれ 10数年ぶりのダイアルアップ接続に成功しました。全然使ってなかったから知らなかったのですが、ダイアルアップ接続状態で画面右下のネットワークプロパティをこんな感じの電話アイコンが見えるようです:
2019061903


緊急事態を想定して、自宅のマンホールマップサーバーへ公衆電話から SSH でログイン! これもできました!!
2019061904

↑脳ごとノスタルジックになってしまったのか、なぜかスクリーンショットではなく PC 画面を撮影してました(笑)


【感想】
とりあえず当初の目的は達成できました。これでこのモデムを持ち歩いてさえいれば(苦笑)スマホがぶっ壊れても出先からネットを使う、ということはできそうだという安心感が得られました。

それにしても・・・一番の想定外だったのは通信の遅さでした。ツイッター程度はもう少し楽に使えると思っていたのですが、1分待っても2分待ってもトップ画面が開かずにテレホンカードのクレジットだけがどんどん減って行って・・・ 最後は諦めたという (^^;

上記の SSH ログインも実はかなり苦戦しています。top コマンドを実行したかったのですが、"top" と入力したつもりだったのに画面には "t" しか出てこず、エコーバックが追いついていないようでした。で "op" と押し足すと今度は "topop" って表示されて、BackSpace でもなかなか消えてくれなくて・・・といった感じでした。56kbps を甘く見てました。。

今回の挑戦当初の目的であった「2019 年の今、あえてダイアルアップ接続がどこまで使えるのか」の答としては
 繋がるけどほぼ使えない (^^;
ということだったと思います。


あと、モデム特有の「ピーー、が~~~」音を聞くことを期待していたのですが、公衆電話からオンフックでかけると音ってしないんですね。 (^^;



 

Windows 10 でサポートされるようになった WSL(Windows Subsystem for Linux) 、しばらくメイン機が Windows 7 のままだったので、あまり使うこともなかったのですが、業務用のマシンも5月に Win10 に置き換えられることになったことと、プライベートで購入した GPD Pocket 2 を開発機として活用する目的もあって、これまで以上に気合を入れて使ってみることにしました:
windows-vs-ubuntu



【これまでの開発スタイル】
WSL の話の前に、これまでの自分の開発スタイルを簡単に紹介しておきます。基本 Linux 上でソースコードを書いて、同 Linux 上で動かしてテストしていました。最大の理由は「本番で動かす際のサーバーはほぼ Linux 」かつ「自分は vi エディタ派」だからでした。一方、業務で支給されているマシンはメイン機が Windows (7) ノートPCで、サブ機が macOS デスクトップ(iMac)、個人で所有する中に Ubuntu デスクトップ機が1台存在する、という状態でした。つまりコーディングする時は
  • Windows に Linux の仮想マシンを入れて、そちらにログインしてコーディング
  • Windows から別環境の Linux(クラウドとかラズパイとか)にリモートログインしてコーディング
  • macOS 上のターミナルからエディタを起動してコーディング
  • Ubuntu デスクトップをインストールしたノート PC からコーディング
するような感じでした。

なお Windows 上でコーディングして Windows 上で動作テスト、というスタイルは本番サーバーが Windows とわかっていればやるかもしれませんが、色々挙動の違いが気になってしまい、あまりやっていません。

上記4つのうち、上2つは面倒なんですが、本番環境に近い Linux 上での動作確認までできるという点が魅力です。また開発以外の資料作成時にデスクトップアプリ(パワポ、エクセル、ノーツ、画像リタッチ、あと ATOM みたいな IDE 環境、etc・・・)を利用する際においては使いやすい Windows 版が使える点が魅力でした(ぶっちゃけ、macOS 版のエクセルや日本語変換の完成度って・・・(^^; )。一方で実質的には開発用に(仮想的な)別環境を1つ作る必要があるため、ディスク利用効率もよくないし、その点においては資料作成含めてすべて1台の macOS 内で完結できる3つ目の開発スタイルも、これはこれで優れていると感じていました。 4つ目の Ubuntu デスクトップ機を使うのも3つ目と同じで悪くはないのですが、やはり開発作業以外のデスクトップ作業では Windows に一日の長があるように感じます(Micorsoft Office も Linux 版は提供されてないし)。Ubuntu でプレゼン資料作るのはまだちと厳しいと感じる現実があります。


【WSL を併用した開発スタイル】
今回 WSL を使って開発環境を構築するにあたり、このような責任分担を行いました:
サーバー部分: WSL
開発・デスクトップ作業: Windows


つまり、ソースコードを置いたり、アプリケーションサーバーを起動したり、そのアプリケーションサーバーから開発したアプリケーションを起動したりする部分は WSL を使います。 一方、ソースコードを編集したり、ソースコード以外の資料ファイル作成など(ウェブでググるのも含める)といった GUI のデスクトップ作業は Windows を使うことにします。それぞれの得意分野を活かせるような分担にしたつもりです:
2019040800



この環境で開発作業を行うために2点ほど環境設定を行いました:

(1) ソースコード共有
サーバーが WSL で、クライアントおよびデスクトップ作業は Windows 。と、キレイに分けているように見えるかもしれませんが、ソースコードだけは共有する必要があります。つまり Windows(クライアント)側でソースコードを編集し、その編集されたソースコードが WSL 上で実行される必要があるのでした。

このため以下の手順を実行して、Windows / WSL 両方の環境から1つのソースコードが参照できるようにしました。まず Windows のコマンドプロンプトを起動し、ホームディレクトリに src/ という名前のフォルダを作成しました。ソースコードはこのフォルダ内に作ります:
> cd \Users\(Windows のユーザー名)

> mkdir src


次に WSL のシェルを起動して、上記で作成した src フォルダをホームディレクトリにシンボリックリンクします。WSL からは Windows の C ドライブが /mnt/c/ フォルダにマウントされています。この情報から上記で作成したフォルダは /mnt/c/Users/(Windows のユーザー名)/src に作られていることになるので、WSL のシェル上で以下のように実行します:
$ cd

$ ln -s /mnt/c/Users/(Windows のユーザー名)/src

これで Windows のホームディレクトリ以下に作成した src フォルダが、WSL では ~/src フォルダとして存在するようになりました。これで Windows で編集したファイルを WSL からも参照できるようになったので、そのまま WSL のアプリケーションサーバー上で動かすことができるようになりました。


(2) ATOM エディタの vim 化
次に Windows 向けのテキストエディタのカスタマイズです。個人的に vi/vim 派なので、テキストエディタでもこのキーバインドを使いたいのでした。

例えば Windows 向けの vim を導入する、というのも1つの案だと思いますが、自分は ATOM エディタに vim 用プラグインを導入して vim っぽく(?)使えるようにカスタマイズしました。

具体的には(ググればわかると思いますが)ATOM エディタに vim-mode-plus プラグインを導入して、ATOM を vi/vim キーバインドで使えるようにしています。


これら2つのカスタマイズによって、
①アプリ開発時に、まず Windows で WSL と ATOM を起動し、
②ATOM でソースコードを編集し、
③WSL 側で編集したソースコードをアプリケーションサーバーで起動してテスト、
④Git へのコミットや本番サーバーへのデプロイは WSL から行い、
⑤ドキュメントや資料は Windows の Office やデスクトップツールで作成
という、かなり使い勝手のよい作業分担環境を作ることができました。

一方でこの環境を使う場合の注意点もあります。最大の問題は「文字コードの違い」を意識する必要があることです。Windows 側で編集するソースコードの文字コードは原則 UTF-8 にする点に注意しましょう。

WSL はまだ動かないツールがあったり、デーモンは手動起動が必要になるなどの制限事項もありますが、ウェブアプリケーションの開発環境として使う限りにおいてはあまり苦にならないと思いました。


Java のアプリ開発をしていて、こんな実行時エラーに遭遇することがあります:
java.lang.UnsatisfiedLinkError: C:\IBM\Notes\nlsxbe.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform


最近は Windows といえば 64bit 版が普通になってきました(よね?)。自分の開発環境も 64bit 版 Windows で、Java 開発環境も(JDK も JRE も Eclipse も)64bit 版を使っています。ここまでは珍しくないと思っています。

しかし開発するアプリケーションによっては外部ライブラリ(JAR ファイル)を指定する必要があり、その JAR ファイルが 32bit のネイティブライブラリを使っていたりするなど、64bit の JDK で 32bit 前提のコードを実行しなければならなくなった場合に上記のようなエラーが発生するのでした。

典型例としては、IBM Notes の Java API を使ったアプリケーション開発が挙げられます。2017/Oct/01 現在、Windows 版の IBM Notes は 32bit 版しか存在していません。Java で IBM Notes の API を実行するには IBM Notes 同梱の Notes.jar 他をインポートして使う必要がありますが、この Notes.jar は 32bit の DLL を参照するため、64bit Java から実行すると上記のエラーが発生します。


エラーの原因が分かったところで、どのように回避すればいいでしょうか? これも解決策としてはシンプルで 32bit Java(JRE) から実行すればよいことになります。32bit JRE をダウンロードして実行してもいいですが、上記のような IBM Notes の JAR を使った場合であれば、IBM Notes が使っている Java をそのまま指定して実行すればよいことになります。

ちとややこしいのが Eclipse のような IDE を使っている場合の指定方法です。まず Java - Installed JREs の中に Standard VM として Notes Java を追加しておく必要があります。Notes Java は(ノーツをインストールしたディレクトリ)/jvm にあるので、このディレクトリを指定して追加します:
2017100101


そして Eclipse の Java プロジェクトの中で JRE System Library として、上記で設定した Notes Java を指定します。これでこのプロジェクト内で作成したアプリを実行する際には Notes Java 内の java.exe が利用されるようになるので、上記のエラーが回避できるようになります:
2017100102



 

久しぶりの LotusScript ネタです。LotusScript は IBM ノーツ/ドミノのカスタマイズに使えるマクロ言語です。内容そのものはノーツじゃなくても(VBA でエクセルなどにも)応用できると思いますが、Windows 前提です。

Windows OS に標準搭載されている ServerXMLHTTP オブジェクトをノーツの LotusScript から使って、LotusScript で WEB API っぽいことを実現してみました。

まず ServerXMLHTTP オブジェクトについて。MSDN によるとこんなものです:
https://msdn.microsoft.com/ja-jp/library/ms762278(v=vs.85).aspx

簡単に言えば「HTTP クライアントライブラリとして使える ActiveX オブジェクト」です。このオブジェクトをインスタンス化すれば、比較的簡単に HTTP クライアントプログラムが作れます。特にノーツのマクロ言語である LotusScript はソケット通信とかネットワークプログラミングに若干弱いところがあるので、このオブジェクトを外部利用して WEB API を使ってみよう、という試みです。

例えばこんな感じ。開発環境であるドミノデザイナーを使ってノーツデータベースのエージェントを LotusScript で作り、Initialize サブルーチンに以下のような内容を記載します(エージェント名は ServerXMLHTTP としました):
Sub Initialize
  Dim obj As Variant

  Set obj = CreateObject( "Msxml2.ServerXMLHTTP.6.0" )
  Call obj.open( "GET", "http://ibm.com/", False )
  Call obj.send()
  MsgBox obj.responseText
End Sub

内容がシンプルなのでなんとなく理解できると思いますが、簡単に解説すると CreateObject を使って ServerXMLHTTP オブジェクトインタンスを生成し、"http://ibm.com/" を HTTP GET して、その内容をメッセージボックスで表示する、というものです。要するに http://ibm.com/ の HTML ソースコードを画面に表示する、というものです。

またエージェントのプロパティとして、実行時のトリガーは「イベント」で「アクションメニューの選択」、対象は「データベースの全ての文書」に設定しておきます。もちろん実行内容によってはここを変更する必要がでてきますが、今回の例ではこの設定でメニューから選択して実行できるようにしました:
2017081001


改めてこのデータベースをノーツで開くと、メニューから作成したエージェント(図では "ServerXMLHTTP")が選択できるようになっているはずです。これを選択して実行すると・・・
2017081002


こんな感じのダイアログボックスが表示され、中に http://ibm.com/ の HTML ソースコードが表示されているはずです:
2017081003


いかがでしょう。上記例では HTTP GET の例を紹介しましたが、この ServerXMLHTTP オブジェクトを使うと、POST など他のメソッドを指定することもできるし、もちろん送信データを指定することもできます。その辺りの詳しい話は公式ドキュメントを参照ください:
https://msdn.microsoft.com/ja-jp/library/ms762278(v=vs.85).aspx


HTTP クライアントがここまで簡単に使えると、各種 Web API が使えるようになるので、IBM Bluemix のワトソン API をノーツクライアントから(それもフロントエンドから)直接実行する、なんてことも可能になると思っています(余談ですが以前に Java を使って、ノーツのバックエンドからワトソン API を使う、という内容を紹介したことがあります。その記事はこちら)。


ノーツデータを広く応用・活用する際に使えそうなライブラリです。

このページのトップヘ