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

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

タグ:github

「ウェブ魚拓」というサービスをご存知でしょうか?ネット上のウェブサイト(URL)を独自にキャッシュして保存するサービスのことです。ネット上のウェブサイトがなくなってしまったり、内容が変わったりしても、その保存したタイミングでのウェブサイトを後からでも参照できるように残す、というサービスです。

このウェブ魚拓もどきのサービスを Node.js 向けに作って、ソースコードを公開しました:
https://github.com/dotnsf/urlrec

2019020801


まず、この公開したサービスではあらゆる全てのサイトでキャッシュを残せるわけではありません(いわゆる「対策済みサイト」に対しては、この機能は無効です)。残せるサイトの場合は独自フォーマット(本当は MHTML にしたかったんですが、色々難しそうだったので、画像だけインライン展開するフォーマットで HTML と画像を記録できるようにしました)でキャッシュを記録します。つまり取得時点でのテキスト内容と画像をキャッシュして記録します。

また記録先として IBM CloudIBM Cloudant サービスが必要です。必要に応じて IBM Cloud のアカウントを作成し、IBM Cloudant サービスインスタンスを作成しておいてください:
2019020802


ソースコードを入手する前に、IBM Cloudant インスタンスを利用するための接続情報を確認しておきます。作成したサービスインスタンスの「サービス資格情報」メニューから「資格情報の表示」を選択(見当たらない場合は1つ新規に作成してから選択)すると JSON フォーマットの接続情報が表示されます。この中の username と password の値を後で使うことになるので、このページを開いたままにしておくなどしてコピー&ペーストできるようにしておきます:
2019020803


では改めてソースコードを入手します。https://github.com/dotnsf/urlrec から git clone するか、下図のように zip をダウンロード&展開してソースコードを手元にコピーします:
2019020804


ソースコードが入手できたら、settings.js ファイルをテキストエディタで開きます。そして exports.db_username の値を先程確認した IBM Cloudant の接続情報の username の値に、exports.db_password の値を同じく password の値に、それぞれ(コピー&ペースト等で)書き直して保存します:
exports.db_username = '(username の値)';
exports.db_password = '(password の値)';
exports.db_name = 'urlrec';
: :

Node.js が導入されていればローカル環境で動かすことも可能です。その場合は以下のコマンドを実行します:
$ npm install  (依存ライブラリを導入)

$ node app  (実行)

server stating on XXXX ...

成功すると上記のように "server starting on XXXX ..." と表示されます。この XXXX は数字になっているはずで、ウェブ魚拓サービスはこのポート番号で待ち受けている、ということを示しています。


では実際に使ってみましょう。先程確認した XXXX を使って、ウェブブラウザから http://(サーバー名 または IP アドレス):XXXX/ にアクセスします。以下のような画面が表示されれば成功です:
2019020805


画面上部の "URL" にキャッシュしたいページの URL を入力して "CHECK" ボタンを押すとプレビューが表示されます(このプレビューが表示されないページは非対応だと思ってください)。下の例では試しに自分のブログの1ページを指定してみました:
2019020801


そしてプレビュー画面で(必要に応じてテキストコメントを入力した上で) "Record" をクリックするとキャッシュがシステムに保存され、先程の画面内に一覧表示されます:
2019020802


この画面で一覧内の一番左の列(赤枠部分)をクリックすると、別ウィンドウが開いてキャッシュされた内容を確認することができる、というものです(元の URL の記事が削除されていても見れるようになります):
2019020803


UI的にもまだまだシンプルすぎる所があったり、元のページのスタイルの再現性など、まだまだ改良の余地はあると思っていますが、基本機能は実装できていると思ってます。MIT でソースコードを公開しているので、役に立つ場があればご自由に使っていただきたいです。

そろそろプロ野球のシーズン開幕前順位予想とかが始まるので、それらを片っ端から記録しておこうかなあ、と邪な考えを持っていたりします。 σ(^^;


個人的な野望としてはこれを元に更に改良してブロックチェーンと組み合わせて真偽証明付きにして・・・って感じかなあ。

テキスト中心のシンプルなプレゼンテーションを作って公開する場合の選択肢の1つとして GitPitch がいいかなあ、と最近思うようになりました:
2018071700


GitPitch は以下の特徴を持った、プレゼンテーション公開の仕組みです:
- マークダウン記法を使って記述・作成する
- Github.com のアカウントを持っていれば、簡単に公開できる(GitLab なども対応しているらしいが未確認)

具体的には Github のリポジトリ内の特定ファイルに特定ルール(ほぼマークダウン)でプレゼン内容を記述するだけ、です。その内容を Github を通してプレゼンテーション化して公開します。

具体的には、公開したいプレゼンテーションを PITCHME.md というファイル名で、マークダウン記法で記述します。スライドとスライドの間には以下のどちらかのページセパレータを挿入します:
(1) --- (現在のスライドの右に新しいスライドを作成する場合)
(2) +++ (現在のスライドの下に新しいスライドを作成する場合)

試しにこんな内容の PITCHME.md を作ってみました:
I love you.

+++

愛してます。

---

Je t'aime.

+++

我爱你。

---

사랑해.

+++

أحبك.

この PITCHME.md ファイルが含まれるリポジトリを Github で公開します:
https://github.com/dotnsf/gitpitch


準備はこれだけ、後は https://gitpitch.com/(ユーザー名)/(リポジトリ名) にアクセスすると、スライド化された PITCHME.md の内容が参照できます:
https://gitpitch.com/dotnsf/gitpitch


(最初のスライドページ)
2018071701

(↓を選ぶと、2番目のスライドページ)
2018071702

(→を選ぶか、または最初のスライドページで→を選ぶと3番目のスライドページ)
2018071703


なお、このプレゼンテーション参照中に、矢印キー以外に以下のショートカットキーを利用することができます:
キー効果
HOME最初のスライド
END最後のスライド
N次のスライド
スペースNと同じ
H左矢印と同じ
J下矢印と同じ
K上矢印と同じ
L右矢印と同じ
Mメニュー
Fフルスクリーン
ESCフルスクリーン解除
Oスライド一覧
B画面ブラックアウトの ON/OFF トグル
Sスピーカーノート
?ショートカットキーのヘルプ



パワーポイントのように、図やチャートに凝ったプレゼンを作るには向いてませんが、逆にテキスト中心の内容であればマークダウンで簡単に装飾テキストも作れるし、Github アカウントさえあれば普通にリポジトリを公開するだけでプレゼンテーションを公開できるという点が便利だと思っています。


GitHub で作成してしばらく使っていたリポジトリが、当初の想定以上に盛り上がったりすると、最初に適当に付けたリポジトリ名からちゃんとした正式名称のリポジトリに変更したくなる(というか、した)、という経験をしました。その時の作業手順メモです。

まず最初の注意点として、GitHub リポジトリのリネームは GitHub サーバー側と、そのクローンを保持するローカル側の両方で行う必要があります。クローンを保持するローカルが複数ある場合は、その全てのローカル側で対応が必要になります。

今回は
 https://github.com/dotnsf/old_app.git

 https://github.com/dotnsf/new_app.git
にリネームする想定で以下を説明します。

【GitHub サーバー側】
サーバー側の変更は GitHub のリポジトリ画面内から行います。まずブラウザでリポジトリページを開き、"Settings" メニューを選択します:
2018061401


"Settings" メニューのすぐ下に "Repository name" フィールドがあり、ここに変更前のリポジトリ名(今回であれば "old_app")が入力されています:
2018061402


ここを新しいリポジトリ名称(今回であれば "new_app")に変更し、"Rename" ボタンをクリックして確定させます:
2018061403


サーバー側の変更はこれだけです。この時点で名称変更前の URL にアクセスしても自動的に新しい URL にフォワードされて、新しい名前のリポジトリが表示されます:
2018061404



【ローカル側】
クローンしたローカルリポジトリ内の .git/config ファイルを編集します:
  :
  :

[remote "origin"]
        url = https://github.com/dotnsf/new_app
        fetch = +refs/heads/*:refs/remotes/origin/*

  :
  :

[remote "origin"] 項目内の url の値を新しいリポジトリの URL に変更して保存します。ローカル側の変更もこれだけですが、複数のマシンにローカルリポジトリが存在する場合は全てのローカルリポジトリを変更します。



ここまでの作業でサーバー側&リモート側ともリポジトリのリネーム作業が完了しました。当然ですが、中身は変わってない(リネーム前のまま)ので、改めてリネーム後に変更が必要なファイル(README.md とか)を更新してください:
2018061405


 

今月(2018年5月)から GitHub ページがカスタムドメインでも HTTPS 対応された、という発表がありました:
Custom domains on GitHub Pages gain support for HTTPS

2018051001


というわけで、自分が取得しているドメインを使って試してみました。以下、GitHub ページの紹介と、その手順を含めた報告です。


GitHub ページとは?

GitHub ページとは GitHub の仕組みを使った静的ウェブサイトのホスティングサービスです。GitHub アカウントを持っていれば、誰でも簡単にウェブサイトを作って公開することができるので、非常に便利です。


GitHub ページの作り方

index.html 一枚だけの非常にシンプルな例で紹介します。まずは普通に Github でリポジトリを作成し、GitHub ページ(ウェブサイト)に含めたい HTML ファイルその他をまとめてプッシュし、公開します:
2018051002


この時点で、同リポジトリが GitHub で普通に公開されている状態になりました:
https://github.com/dotnsf/githubpagessample


(今回、公開する index.html ファイルの中身)
https://raw.githubusercontent.com/dotnsf/githubpagessample/master/index.html


次にこのリポジトリを GitHub ページとして公開します。リポジトリのページから "Settings" メニューを選択します:
2018051003


少しスクロールして GitHub Pages の設定欄を表示し、Source が None になっている所を "master branch" に変更して "Save" します。これでこのリポジトリのマスターブランチが Github Pages として公開されることになります:
2018051004


"Save" が成功すると画面内に GitHub Pages として参照する場合の URL が表示されます。一般的にはここは https://(ログイン名).github.io/(リポジトリ名)/ となります:
2018051005


この URL にアクセスしてみると、先程のリポジトリのマスターブランチが HTTP サーバーのドキュメントルートとして扱われる感じになり、index.html ファイルが表示されます。またこの画面からもわかるように、このページは HTTPS 対応しています:
2018051102


以上、ここまでが GitHub ページの説明です。


カスタムドメインで GitHub ページを使ってみる

今回の更新で、上記の GitHub ページがカスタムドメインでも HTTPS 対応されるようになりました。この点を確認したいので、まずは GitHub ページをカスタムドメイン対応してみます。

そのためには GoDaddyお名前.comなどのドメイン業者でドメインを取得しておく必要があります。ここはどうしても無料というわけにはいかず、ドメインの種類にもよりますが、1年間 $10 程度かかってしまうことを理解した上で取得してください。ちなみに自分は(B'z ファンでもないのに) welove.bz というドメインを GoDaddy で取得しているので、このドメインを使って GitHub ページをカスタムドメイン対応する手順を以下に紹介します。

最初に、対象ドメインの DNS 設定を変更する必要があります。このページの "Configuring A records with your DNS provider" という項目によると、ホスト名の A レコードの IP アドレスを以下のように設定する必要があるようです:
2018051103


A レコードの IP アドレスを複数設定できる場合はこの4つの IP アドレスを設定します。僕が使っている GoDaddy では1つしか設定できないようだったので、一番上のアドレスに指定しました:
2018051104


この部分は同様の作業をドメイン業者の用意したツールを使って設定してください。 なおこの作業について、詳しくは GitHub のドキュメントも参照ください:
https://help.github.com/articles/setting-up-an-apex-domain/


この作業の後で、GitHub の該当リポジトリに CNAME という名前のファイルを1つ追加します。CNAME ファイルの中身にはカスタムドメイン名だけを記載します:
2018051105


このファイルをリポジトリに add して commit して push します:
2018051106

2018051107


最後に再びリポジトリの settings 画面を確認して、GitHub ページのカスタムドメインが設定されている(されていない場合は、ドメイン名を入力して "Save")ことを確認します。これで GitHub ページのカスタムドメイン設定ができました:
2018051108


この状態で http://(カスタムドメイン名) にアクセスすると、先程まで ***.github.io ドメインで動いていた GitHub ページが表示されます:
2018051101


これで GitHub ページのカスタムドメイン化が完了しました。



カスタムドメイン GitHub ページの HTTPS 対応

やっと本題です(苦笑)。ここまでの作業で GitHub ページがカスタムドメインで利用できるようになりました。今回の目的は「このページを HTTPS 対応にする」ことです。

そのための設定はリポジトリの settings で、カスタムドメインを指定した下に "Enforce HTTPS" というフィールドがあるので、ここにチェックを入れるだけ・・・
2018051101



・・・なのですが、まだ証明書が有効になっていないようです(チェックできない)。こうなると作業としてできることはないので、ひたすら待つ必要があります。

ちなみに、この状態で無理やり HTTPS を指定して https://(カスタムドメイン名)/ にアクセスすると「安全な接続ではない」と言われます。ここから例外を承認して・・・ということもできないわけではないですが、せっかくなのでしばらく待ちましょう:
2018051102


しばらく待つとこの部分のメッセージが変わり、"Enforce HTTPS" がチェック可能になります:
2018051103


チェックするとこのような画面になり、このリポジトリの GitHub ページは強制的に(HTTP でリクエストしても)HTTPS でアクセスされるようになります:
2018051104


実際にアクセスしてみました。ちゃんと HTTPS に転送されています:
スクリーンショット 2018-05-11 15.38.40


HTTPS のインフォメーションを確認しても(オレオレ証明書とかではなく)"Secure Connection" になっていることが確認できます:
スクリーンショット 2018-05-11 15.39.12



(おまけ)
ではこの証明書は誰がどうやって発行しているのだろう? と疑問に思ったのですが、"Verified by: Let's Encrypt" だそうです。なるほどね・・・:
スクリーンショット 2018-05-11 15.38.58


めでたし、めでたし。
ところでこの welove.bz ドメイン、なんかいい使いみちないかな? (^^;


最近、ボット関連の API や SDK をよく見るわりに、自分では使う機会が少なかったので、今更ながら1つ作ってみました。

今回作ってみたのは「シェルボット」です。名前の通り、ボットでシェルっぽいインターフェースを実現しました。何言ってるかよくわからない人はこちらの画面を参照ください:
2017060901



ボットっぽい対話型インターフェースを使って、対話しているかのようにシェルコマンドを実行します。今回はインターフェースに独自の HTML ページを用意しましたが、ぶっちゃけ LINE などでも(Messaging API を使うなどすれば)応用できると思っています。

#「チャットボット」とは違うけど「ボット」ですっ!


ソースコードを github で公開しておきました。セキュリティ的な面はまだまだ改良の余地があると思っています(rm コマンド他は実行不可にしていますが、本当は他にも実行を制御するコマンドを考慮したほうがいいと思う):
https://github.com/dotnsf/shellbot


↑このソースコードはビジュアルフローエディタである Node-RED で使う前提のものです。(IBM Bluemix などを使って)Node-RED 環境を用意し、func-exec ノードを追加した上でキャンバスに shellbot_nodes.txt の内容をインポートして、ブラウザで /shell にアクセスするだけです(詳しくは README.md 参照)。

#あー、あと今のところ Linux/Unix 系 OS に導入する前提です。


実際に Node-RED 環境上にインポートした様子のスクリーンショットがこちらです。2本のシンプルな HTTP リクエスト処理が定義されているだけのもの(うち1つは HTML 画面定義)ですが、本当にこれだけでこのシェルボットが動きます:
2017060902


実は今まで「ボット」=「チャットボット」=「コンシェルジュ」的なイメージを持っていてハードルが高かったのですが、今回のアプリを作った結果、難しく考えずに「既存アプリケーションのインターフェースを対話型にする」という実装もアリかな、と思うようになりました。


このページのトップヘ