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

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

もう少しわかりやすく手を加えた上で、いずれちゃんと紹介する機会(BMXUG勉強会?)を作るつもりですが、オープンソースのブロックチェーン環境であるHyperledger Fabric を使ってユーザーと資産の管理、そして資産の譲渡といった最低限の機能を持ったアセット管理プラットフォームを作って、MIT ライセンスで公開しました。

「資産」=「仮想通貨」とみなせばいろいろ話題の仮想通貨プラットフォーム(の基礎)にもなると思います。仮想通貨でなく、普通の資産の管理や譲渡にも使えると思ってます(むしろそっちをイメージして作ってます)。またそこでの作成や譲渡といったトランザクションはブロックチェーン上に記録されるので改竄時のトラッキング機能を内包していることになります。

現時点では Hyperledger Fabric 環境が用意されていることが必須の上、管理プラットフォームとしてのUI未作成で、REST API のみ実装しているだけです。なので「使える人は使える」レベルのものだと思っています(改良予定あり)。 その代わり MIT ライセンスなのでかなり自由度高く改変・改良・再利用することを認めています。今のままでもブロックチェーン環境のデモ程度には使えると思ってます。


そんな、まだまだ普通に使えるレベルのものではないことは理解した上で、僕自身はこのタイミングあたりからフィードバックももらえたらいいなとか、共同開発に興味ある人がいたら・・・という目的もあって公開することにしました。コードはこちら:


導入方法などは README.md を参照・・・していただきたいのですが、Hyperledger Fabric 環境の用意を前提としているなど、まだ現時点ではハードル高いと思ってます。いずれ PaaS や SaaS でもっと気軽に使えるようになることを期待していますが。。


ちなみに、上記のコードはこの週末に GPD Pocket (Ubuntu 版)に Hyperledger Fabric と、Hyperledger Composer を導入したことでスタンドアロンなブロックチェーンアプリケーション開発環境ができ、嬉しくなって地元の津田沼を散歩しながら持ち歩いて、その休憩時に取り出して作りました。なので開発期間は実質週末の2日くらい。それほど凝ったものは作れておらず、ユーザーや資産の作成、ログイン、資産譲渡、といった API が用意されている程度です:
20180203
(↑開発中の様子)


逆に現時点ではまだ検索用の機能がほぼ手付かずだったり、管理用の UI すらなく、唯一 Swagger スタイルのインタラクティブな API Document が用意されている程度です。なのでまだ低レベルな部分もこれから作っていく必要があるもので、その点でも(良くも悪くも)プラットフォームとしての実装段階です。 そんなことを理解した上で「開発に関わってみたいなあ」とか「Hyperledger Fabric の勉強も兼ねて実装してみたいなあ」とか「ぶっちゃけブロックチェーン分からないけど、UI/UXだけでも関わりたいなあ」とか思っている人がいたら心強いっす。もちろん MIT ライセンスで公開している以上、「勝手に使わせてもらって改良する」でも全然オッケーです。個人的には Hyperledger Fabric が広まってほしいなあ、という思いを優先してます。


「国際化」に対応したウェブアプリケーションを Node.js で作る方法を調べたので、メモ替わりに残しておきます。

ここでの「国際化(internationalization, i18n)」はウェブブラウザで設定した言語によって自動的に英語表記にしたり、日本語にしたり、・・・という切り替えを行えるようなものです。自動翻訳とかそういうものではありません。またブラウザで設定した言語は HTTP リクエスト時に "Accept-Language" ヘッダで送信されることになるので、後述の動作確認は curl コマンドでこのヘッダを指定して行っています。

このような国際化対応アプリケーションを Node.js で、正確には Node.js + Express + EJS の環境で作ってみました。

Node.js で国際化対応アプリケーションを作る場合、i18n というパッケージを使うのが手っ取り早いです:
https://www.npmjs.com/package/i18n

ソースコード(app.js)はこんな感じにしました。余計な部分を削ぎ落として、最小限必要な部分だけを残しています(赤字部分が i18n 関連の箇所です):
//. app.js

var express = require( 'express' ),
    fs = require( 'fs' ),
    ejs = require( 'ejs' ),
    i18n = require( 'i18n' ),
    request = require( 'request' ),
    session = require( 'express-session' ),
    app = express();

var port = 3000;

app.set( 'views', __dirname + '/public' );
app.set( 'view engine', 'ejs' );

i18n.configure({
  locales: ['en', 'ja'],
  directory: __dirname + '/locales'
});
app.use( i18n.init );

app.get( '/', function( req, res ){
  res.render( 'index' );
});

app.listen( port );
console.log( "server starting on " + port + " ..." );

今回は英語(en)と日本語(ja)に対応したアプリケーションにしました。

また '/' にアクセスした時に ejs の index テンプレートを使った画面が表示されるような内容にしています。ちなみに index テンプレート(public/index.ejs)の内容は以下のようになっています:
<html>
<head>
<title><%= __('subject') %></title>
</head>
<body>
<h1><%= __('subject') %></h1>
<hr/>
<%= __('body') %>
</body>
</html>


テンプレート内で subject と body という2つの変数を使った表記を行っています。実際にはこれらの部分に言語設定に合わせた内容が表示されることになります。

そして言語ファイルを以下のように用意します:

(英語用: locales/en.json)
{
  "subject": "subject",
  "body": "body"
}


(日本語用: locales/ja.json)
{
  "subject": "サブジェクト",
  "body": "本文"
}

英語設定で利用した場合、上記の subject 変数部分は "subject", body 変数部分は "body" と表示されます。また日本語設定の場合、それぞれ "サブジェクト" と "本文" となります。


これで準備できました。 npm install して実行(node app)します:
$ npm install
$ node app

確認は別の端末から curl で行いました。まずは Accept-Language を en(英語)にしてアクセス:
$ curl http://localhost:3000/ -H 'Accept-Language: en'

<html>
<head>
<title>subject</title>
</head>
<body>
<h1>subject</h1>
<hr/>
body
</body>
</html>
>

次は日本語設定でアクセスした場合:
$ curl http://localhost:3000/ -H 'Accept-Language: ja'

<html>
<head>
<title>サブジェクト</title>
</head>
<body>
<h1>サブジェクト</h1>
<hr/>
本文
</body>
</html>


期待通りに動いています!


アプリケーションの国際化そのものはこれだけで出来ました。そして問題になるのは「どうやって色んな言語用の JSON リソースファイルを用意するか?」です。1つ1つ翻訳サービスなどを使いながら作る、という方法もありますが、そんな言語リソースファイルの翻訳作業は IBM Cloud の Globalization Pipeline サービスを使うと英語のリソースファイルから各言語に翻訳したリソースファイルをまとめて作ることができてとても便利です。このサービスについては以前のブログで使い方も含めて紹介しているので参照ください:
Globalization Pipeline サービスがリリースされました!


と、最後は宣伝でしたw

IBM Cloud(Bluemix) のアカウントを所有していると、マネージドサービスとして利用できる GitLab が使えるようになります。サーバーのインストールなどは不要で、プライベートリポジトリを作成することも可能です:
2018011701


使い勝手は GitLab そのものだと思ってください。Issues 管理の機能も使えますし、IBM Cloud の Continous Delivery サービスと連携した Delivery Pipeline による DevOps サービスの一部としても利用できるようになっています。アカウントをお持ちの方は、単にプライベートリポジトリが使える Git として考えるだけでも便利だと思うので、是非活用してください。


ところで、この IBM Cloud の Git を使って Java のアプリケーションコードを管理しようと、作成したリポジトリから Eclipse の Git 機能を使って clone を試みた際に、稀に以下のようなエラーメッセージに遭遇し、クローンに失敗することがあります:
  :
  :
!MESSAGE https://git.ng.bluemix.net/dotnsf/javatest.git: cannot open git-upload-pack
!STACK 0
org.eclipse.jgit.api.errors.TransportException: https://git.ng.bluemix.net/dotnsf/javatest.git: cannot open git-upload-pack
  at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:196)
  at org.eclipse.egit.core.op.ListRemoteOperation.run(ListRemoteOperation.java:99)
  at org.eclipse.egit.ui.internal.clone.SourceBranchPage$8.run(SourceBranchPage.java:324)
  at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Caused by: org.eclipse.jgit.errors.TransportException: https://git.ng.bluemix.net/dotnsf/javatest.git: cannot open git-upload-pack
  at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:499)
  at org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:308)
  at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:175)
  :
  :

「git-upload-pack がオープンできない」という耳慣れないエラーメッセージで、実はこのメッセージそのものからは原因の追求が難しいものでした。同じようなエラーに遭遇する人が現れた場合に備えて、自分の経験と回避策を紹介します。

エラーメッセージそのものからはわかりにくにのですが、実は直接の原因は暗号化方式の不一致による通信エラーでした。

まず上記で紹介した IBM Cloud の Git 機能を https 接続で使う場合の暗号化方式には TLS v1.2 を使う必要があります:
https://console.bluemix.net/docs/services/ContinuousDelivery/git_working.html#git_local


さて、Eclipse が使う Java のバージョンが 1.8 以上であれば、デフォルト設定のままで TLS v1.2 が使われます。したがってこの場合は何もしなくてもそのまま IBM Cloud の Git を利用することができます。

一方、Eclipse の Java バージョンが 1.7 以下だった場合、デフォルト設定で採用される通信方式は TLS v1.1 以下です。つまり条件を満たしていないことになります。そしてこの条件で Git に接続しようとすると上記のようなエラーメッセージが表示されてしまうのでした。


では、このエラーメッセージが出た場合の解決策はどうすればいいのでしょうか? 1つの方法としてJava のバージョンを 1.8 以上にするという簡単な方法があります。Java 1.8 以上であれば上記のように(デフォルトで) TLS v1.2 が使われるので、この条件を満たすことができるようになります。

ただ何らかの事情で Java 1.8 を導入するわけにはいかない場合もあると思っています。そのような場合は以下の1行を eclipse.ini に追加した上で Eclipse を起動する、という方法もあります:
  :
  :
-Dhttps.protocols=TLSv1.2

この記述により、Java が 1.7 以下であっても強制的に https 接続時の暗号化方式を TLS v1.2 に指定することができ、やはり上記のエラーを回避することができるようになります。


IBM Cloud 以外の Git でも、同様のエラーメッセージが出た場合にはこの対策が有効だと思っています。頭の片隅に入れながら、無料で便利な IBM Cloud の Git を是非使ってみてください。


このページのトップヘ