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

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

タグ: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


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


2016 年の年初に「マンホライザー」というサービスを作って動かしていました:
http://dotnsf.blog.jp/archives/1048853473.html

マンホライザーはわかりやすく言うと「マンホール顔ハメ画像作成サービス」です(わかりやすいか??)。先日のマンホールサミット 2017 埼玉に参加した際にも、こんなアナログな顔ハメ写真サービスを提供させていただいたのですが、意外と人気があったのでした。それをウェブ上からもできるようにしよう、というわけで生まれたサービスでした。IBM Watson の画像認識機能を使って実装しており、「テクノロジーの無駄使い」な点も自己採点ポイントが高いものになっています(笑):
2017020701


上記リンク先の、2016 年に公開した当初は PHP で実装していました。その時のソースコードはこちらです:
https://github.com/dotnsf/Manholizer


このコードはこれはこれで現在も動く(注 Visual Recognition API の古いものを使っているので、顔ハメはうまく動きません)ものですが、いくつかの課題もありました。その1つが「スマホからの利用を想定していなかった」という致命的な点です。見た目でのスマホのウェブブラウザ最適化という意味では実現したつもりでしたが、想定外だったのは「スマホのカメラで撮影した画像の解像度が予想以上に高かった&今後は更に高くなることが想定される」ということです。

ある程度詳しい人には常識かもしれませんが、iPhone をはじめとする最近のスマートフォンのカメラはかなり高い解像度の写真を撮影することができます(特に設定を変更しない場合は、高解像度撮影が標準機能になっていることが多いです)。撮影した写真を低解像度にしてメールで送る、といったことは可能ですが、内部的には高解像度のまま保存されていることになります。これは1枚の写真画像のファイルサイズが非常に大きいということを意味しています。これは2つの点で問題になります。

1つはアプリケーションサーバー側の制約を受ける可能性があるという点です。例えば PHP を普通にインストールしたアプリケーションサーバーの場合、アップロードサイズは 2MB に設定されることが多いです。もちろんこの設定を変更できればいい話ですが、最近は PaaS などでミドルウェア設定を変更できないケースもあるので、そうなるとこの制約を受けてしまいます。

もう1つは API 側の仕様上の制約を受ける可能性です。このマンホライザーでは画像から顔の位置を認識・特定する必要があるのですが、その部分に IBM Watson の Visual Recognition API を使っています。この API の制約として現在は「画像は 2MB まで」という制約があるのでした。つまり上記のアプリケーションサーバー側の制約を取り除いただけでは解決にならないことも出てきてしまうのです。

上記で紹介した、以前作った PHP 版のマンホライザーにはこれら2つの課題があり、スマホからの利用を想定すると期待通りに動かないケースが出てきてしまいました。というわけで、ミドルウェアや設計段階から見直したマンホライザーを作り直すことにしたのでした。


上記2点を解決するため、まず PHP のアップロードファイルサイズ制約をうけないよう、アプリケーションサーバーは Node.js を使うことにしました。PHP から Node.js への移植を行いました。これによって 2MB を超える画像もアップロードできるようにしました。

また API 側のサイズ制約については、アップロードした画像を一旦内部的にリサイズし、API が実行できるレベルにまでサイズを減らしてから実行する、というロジックに変更することで対処しました。細かい点ですが、画像を小さくしてから実行するため、API からのレスポンスは「小さくなった画像に対する顔の位置」になります。アプリケーション側ではアップロードした画像のプレビューが表示されており、その画像にマンホールの位置とサイズを調整して「ハメる」わけですが、元の画像サイズに対するレスポンスにはなっていないので、その辺りも考慮する必要が生じます。

そんなこんなの変更を加えてできあがったのがこちらです:
https://manholizer.mybluemix.net/

2017020701

↑ちとズレてるが・・・


使い方は PC またはスマホのウェブブラウザでアプリケーションサーバー(https://manholizer.mybluemix.net/ とか)にアクセスしてください。で、「参照」ボタンをクリック:
2017020702

 

手元のローカルファイルシステムまたはフォトライブラリ等から画像ファイルを選択します。今回は「フリー素材アイドル」の Mika x Rika さんの画像を使わせていただきました:
顔4


この画像を指定して、しばらく待つと・・・
2017020703


こんな感じになりました:
2017020704


合成用マンホールのデザインとして使っているのは(マンホーラーであればおなじみの)東京都マンホールです:
2017020706


(2つの)顔の位置を識別し、うまく顔ハメになるようマンホールの位置と大きさが調整されて合成されています。またマンホールの色がピンクなのは「女性」であると認識されている様子です(男性の場合は青いマンホール画像を合成します)。また2人の上部に "-17" と表示されていますが、これは推定年齢でふたりとも「17才以下」であると推測されている、ということを意味しています(お二人の年齢は存じ上げませんが、全体的に日本人の顔は若く判定される傾向があるようです):
2017020705



なお、このサービスのソースコードはこちらで公開しています。興味ある方はご自身の環境でもどうぞ:
https://github.com/dotnsf/manholizerDemo


自分の環境に導入して使いたい場合の方法は README.md にも記述していますが、IBM Bluemix の Node.js ランタイムで使う場合であれば、まず Bluemix にログインして、SDK for Node.js ランタイムを1つ作成します(この時の名前を後で使います)。また Visual Recognition サービスインスタンスを生成し、その API KEY を取得しておきます(この値も後で使います)。

次に上記サイトからソースコードをダウンロード&展開するか git clone して、以下の2ファイルを編集します。

1つ目は settings.js です。この中の exports.vr_apikey の値に、上記で取得した自分の Watson Visual Recognition サービスの API Key の値を設定します(以下は API Key が abcdabcdabcdabcdabcdabcd であった場合の例です):
(settings.js)

: exports.vr_apykey = 'abcdabcdabcdabcdabcdabcd'; :

もう1つは manifest.yml です。この中を実際に運用するランタイムの情報に設定します。例えば eu-gb リージョンを使って、my_manholizer という名前のランタイムで運用する場合は以下のようになります(ng リージョンの場合、domain は変更せずにそのままで構いません):
(manifest.yml)

: domain: eu-gb.mybluemix.net name: my_manholizer host: my_manholizer :

この状態で cf コマンドを使ってアプリケーションを push すると、作成した Node.js ランタイム上にマンホライザーがデプロイされます:
$ cf push

IBM Bluemix を使わずに運用する場合は・・・ まあ普通に Node.js をインストールして npm install して使ってください(適当)。


IBM Watson の画像認識 API である Visual Recognition を使った類似画像検索サービスを作り、そのソースコードを公開しました:
https://github.com/dotnsf/imageSearchDemo


コードは Node.js で作りました。プロジェクト自体に(著作権フリーな)サンプル画像もいくつか含まれていますが、サンプル画像を置き換えて使うことでご自身が所有している画像を使った類似画像検索サービスにすることも可能です。

また基本的に Watson API は使いやすいものばかりだと思ってますが、このサンプルアプリもその特徴を最大限に活かして、単純に「学習させたい画像を用意すれば動く」ようにしました。細かな実装内容はソースコードを参照ください。


上記 github 上のリポジトリの README.md の中に使い方も(英語で)記載していますが、このブログでは日本語での簡単な使い方とカスタマイズについて紹介します。前提としてログインできる CentOS/RHEL のインスタンスに git と Node.js がインストールされている環境をご用意ください。また最終的なウェブアプリケーションは IBM Bluemix 上で動かすことにします(この場合は cf コマンドもインストールしておいてください)。異なるプラットフォームでも動くと思いますが、適宜読み替えてください。


準備

何はともあれ、IBM Watson の API を利用するためには IBM Bluemix のアカウントが必要です。まだアカウントをお持ちでない場合はトップページの「フリーアカウントを作成」ボタンから 30 日間無料で使えるトライアルアカウントを作成できます:
2017012601


Bluemix のアカウントでログインし、カタログ内 "Watson" カテゴリの "Visual Recognition" を選択して、この API を追加してください:
2017012602


なお作成時に "Free" プランを選択すると1日に 250 API call まで無料で利用できるプランになります。本格的に利用する場合はその下の "Standard" プランを検討ください:
2017012603


Visual Recognition API を作成後に、ダッシュボードから作成した同サービスを選択して、サービス資格情報から資格情報を確認します(なければ追加します)。そして "api_key" の値(下図ではモザイクにしています)がこの後必要になるのでメモしておきます:
2017012604


改めて github からソースコードを用意します。いくつかの方法がありますが、git が使える場合は git clone してください(または zip をダウンロードして展開してください):
$ git clone https://github.com/dotnsf/imageSearchDemo
$ cd imageSearchDemo

ソースコードを展開したディレクトリの直下に settings.js というファイルがあります。この中の exports.vr_apikey の値を先程メモした Visual Recognition API の API Key の値に書き換えて保存してください:
2017012605


他はそのままでも動きます。なお、exports.limit の値(デフォルトだと 5)はウェブアプリケーションで類似画像を検索した結果として、上位いくつまでの結果を表示対象とするかの数値です。学習させる画像の数などにもよりますが、必要に応じて書き換えて使ってください。

最後に、この後の学習時に必要な Node.js のミドルウェア: watson-developer-cloud を npm でインストールしておきます:
$ npm install watson-developer-cloud

この結果、プロジェクトのホームディレクトリ(imageSearchDemo)に node_modules というフォルダが作られていれば watson-developer-cloud の導入に成功したことになり、学習処理が行えるようになります。


画像の学習

最終的には類似画像を検索する仕組みを作りますが、そのためにはあらかじめ検索結果となる画像を学習させておく必要があります(学習させた画像の中から類似画像を探します)。そして学習のためにはある程度の枚数の画像が必要です。

上記ソースコードの public/images/ の中にはサンプルとして著作権フリーな画像が含まれています。これらをそのまま使って学習させることもできますし、手元にある画像で類似画像検索システムを作りたい場合はそれらを使うこともできます(その場合は public/images/ 以下のサンプル画像を全て削除した上で、ご自身の画像をこのフォルダ内に格納してください):
2017012606


そして、以下のコマンドを実行すると public/images/ フォルダ以下にある画像を Watson に学習させます(上記の settings.js ファイルの編集を忘れずに行っておいてください):
$ node learnImages.js
imagelearn_xxxxxx

学習が正しく行われた結果、画面には imagelearn_xxxxxx という文字列が表示されます。これが collection_id と呼ばれるもので、後述の Watson API Explorer などでこの API を実行する際には必要になります。またこのコマンドの実行後に setting.js の最終行に以下のような1行が追加されているはずです:
exports.vr_collection_id = 'imagelearn_xxxxxx';


ウェブアプリケーションとして利用

では学習した内容を使った類似画像検索ウェブアプリケーションを作成します。今回は IBM Bluemix 上のランタイムとして作成するので、SDK for Node.js ランタイムを1インスタンス作成します:
2017012607


アプリケーション名は適当にユニークなものを指定します。この例では dotnsf-imagesearch という名前のランタイムを作っています:
2017012608



合わせてソースコードの manifest.yml ファイルを更新します。具体的には name と host 両方の値を、実際に作成するアプリケーション名と同じものにします:
2017012609


ここまで準備できたらアプリケーションをデプロイします。cf コマンドを使ってログインし、プッシュします:
$ cf login -a http://api.ng.bluemix.net/
   :
   :

$ cf push

しばらくするとアプリケーションの転送とステージングが完了して、ランタイムが起動した旨のメッセージが表示されます:
2017012601


この段階でアプリケーションにアクセス可能です。PCかスマホのブラウザでアプリケーションの URL (上記の例だと http://dotnsf-imagesearch.mybluemix.net/)を指定して開くと、このような画面が表示されます:
2017012601


「参照」ボタンをクリックして、類似画像の対象となる画像を選択します。今回は学習データの中に野球ボールがあったので、それが検索できるかどうかを調べる目的で、学習データとは異なる野球ボール画像を指定してみることにします:
野球ボール


画像を指定すると画面が暗転して、類似画像検索が行われます:
2017012602


しばらくすると結果が得られて画面の暗転が戻ります。画面を下にスクロールすると学習データの中の類似画像候補が指定数(デフォルトでは5)表示されます。一番左に野球ボールが検索できているのがわかります。まあこんな感じのウェブアプリケーションサンプルです:
2017012603


画像を学習する部分は learnImages.js で実装しています。学習時に与えるメタデータ(画像検索の結果と一緒に取得できるテキスト情報)の内容を変更する場合はこのファイルをカスタマイズしてください。またウェブアプリケーション部分は app.js で、そしてウェブアプリケーションの見栄え部分は public/ フォルダ内の index.html に依存しています。見栄えを含めたウェブアプリケーションの挙動の変更はこれらのファイルを自由にカスタマイズしてお使いください(ソースコードは MIT ライセンスで配布しています)。



なお、API Key や collection_id を利用して実際に Visual Recognition API を実行する場合は、こちらの Watson API Explorer をお使いいただくのが便利です。仮に作成した collection_id を一度削除するような場合はこの画面から DELETE を実行いただくことができます:
https://watson-api-explorer.mybluemix.net/apis/visual-recognition-v3

また、Watson Visual Recognition API の関数リファレンスはこちらを参照ください:
https://www.ibm.com/watson/developercloud/visual-recognition/api/v3/



このページのトップヘ