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

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

タグ:developer

(このブログエントリは自作DBMS Advent Calendar 2020 の 12/3 にエントリーしています)


偉そうなブログタイトルになってしまいました、申し訳ない。


業務でも個人サービスでもブロックチェーンを使う機会があります。業務で携わることで世の中のお客様がどういった用途でどのようにブロックチェーンを使おうとしているのか、という貴重な情報を得ることができると同時に、企業内利用ゆえの様々な制約に直面することもあります。また個人サービスでもブロックチェーンを使うことで業務での必要十分な範囲にとらわれない(自分が挑戦してみたい)実装にチャレンジすることもできています。いろいろ恵まれた立場であることを実感しています。

一方で、この2つの立場でブロックチェーンを活用していると、「自分が理解してるブロックチェーン」と「実際のブロックチェーンプラットフォーム」との間に存在しているギャップが気になることもあります。このギャップは自分のブロックチェーンに対する理解がまだまだ足りないことに起因している可能性が大きいこともわかっていますが、それはつまり「ブロックチェーンは難しいもの」という先入観にも原因があるのかもしれません。

何を言いたいのかと言うと、自分のようなアプリケーション開発者の視点から考えるブロックチェーンはこういうものであってほしい(こういうものであってくれると使いやすいし、管理しやすい)んだけど、現実はそうではない、ということに何度か直面するのでした。具体的にいくつか挙げるとこのようなことです:


0 「ブロックチェーン」としての定義を満たしている

これは要件というよりも、後述する「ブロックチェーン」という用語への共通理解のための項目です。例えば日本では一般社団法人日本ブロックチェーン協会このような定義をしています。この中の「広義のブロックチェーン」で考えられるものが(広い意味での)ブロックチェーンであり、ここに定義された条件を満たしていれば、仮にサーバーノードを管理する権限を持っているような立場の人であっても、その中身を改ざんすることは困難になる、というものです。この「改ざんが困難」な特徴によって(法律などでルールを作らなくても、技術的に)記録内容の正当性を保証できるようになるもの、それがブロックチェーンだと理解しています。

で、特に開発者の視点ではブロックチェーンがここから下の要件を満たすものであってもらえるといろいろ嬉しいなあ、、と思っていまして、それを3つほど列挙させていただきます。


1 可能な限りブロックチェーンを意識せずにアプリケーション開発ができる

上述したようにブロックチェーンに関する最小限の知識はアプリケーション開発者が理解しているべきであると思いますが、一方でアプリケーション開発者がブロックチェーンを意識して開発すべきであるとは思いません。極端な言い方ですが、ブロックチェーンの存在すら知ることなく「開発者がデータベースを使ってアプリケーションを開発したら、データベースへのトランザクションは全て自動的にブロックチェーンに記録されて、改ざんが困難になったり、改ざんされてもすぐバレる」ようにできると理想的だと考えています。 要はブロックチェーンというインフラ部分をアプリケーション開発者の責任範囲から可能な限り分離したい、という意見です。


2 プライベートネットワークからもブロックチェーンに参加できる

ブロックチェーンネットワーク内に存在するノード間では台帳情報を分散管理します。したがって全てのノードがパブリックなネットワークに存在していて自由に同期をとることができることが理想ではあります。

一方、実際に企業のサービスがブロックチェーンネットワークに参加する場合、パブリックネットワークでの運用を前提とする時点で懸念が生じることがあります。比較対象として相応しいかどうかわかりませんが、例えば企業内で使っているデータベースをパブリッククラウド上に移行することですら問題になるのが現実で、そんな中で台帳情報を共有するブロックチェーンはパブリックでもオッケー、となるわけがありません。わがままにも聞こえますが「ネットワークはパブリックで構築してもいいが、うちが用意するノードはプライベートな状態で運用したい」のが本音となっているケースも散見します。

このわがままにも聞こえる懸念に対して「ブロックチェーンだからパブリックネットワークでないといけないのか?」という観点で考えるとどうでしょう? ある程度中身まで理解しているブロックチェーン技術者にとっては当然のようにパブリックネットワーク運用前提で考えてしまうかもしれませんが、ブロックチェーンを活用したいと考えている経営者からは厄介な制約に感じられてしまうものかもしれませんし、上述の「1 可能な限りブロックチェーンを意識せずにアプリケーション開発ができる」ようになると、アプリケーション開発者としてもネットワーク・トポロジーの制約を意識せずに開発できるようになるのが理想と考えています。 開発者と経営者、どちらもブロックチェーンを活用したいという想いは同じなのに、協力しあえないのはあまりに不幸な話と思えるため、それならなんらかの制約(※)が加わるにせよ、開発者側から歩み寄る形でプライベートネットワーク内からもブロックチェーンネットワークに参加して同期を取る方法を(技術的に不可能でないのだとしたら)検討する価値はあるのではないか、と考えています。そしてブロックチェーンそのものにそういった機能がはじめから付与されていれば歩み寄りも最小限で済むため理想的ではないかと思っています。

※具体的にはブロックチェーンをプライベート型やコンソーシアム型にせざるを得なくなる、といった制約です。


3 ブロックチェーンに全てのトランザクションが記録されるのであれば、例えばノードの引っ越し時やデータ破損時などにブロックチェーンからリストアできるはず

実は僕がブロックチェーンの存在や概要を知って、真っ先に思いついたブロックチェーンのメリットがこれでした。そもそも開発するサービス全体のうち、ブロックチェーンには何を(どの部分の情報を)記録するのかという問題があることは理解しています。例えばユーザー情報はブロックチェーンには記録せずに運用するけど、お金の動きに関わる部分だけはブロックチェーンに記録する、という考え方です。その意味ではサービス全体の情報がブロックチェーンに格納されるわけではないことは理解しておく必要があります。

でもブロックチェーンに記録されている情報に関してはそこに全トランザクションが記録されているわけだから、仮にデータ部分が破損したケースであっても、ブロックチェーンを最初からたどることで理論上は元通りに戻せるはず(つまりブロックチェーンからリストアできるはず)、だと思ったのでした。これができると運用者は楽だし、運用者が困っている面倒な部分の開発も楽になります。

ところが実際にそのようなリストア機能をもったブロックチェーンは自分の知る限りでは存在していません。もちろん実際のデータベースとの紐付け情報が必要だったり、どのサービスで使うデータに関するトランザクションなのか、といった情報も含めてブロックチェーンに記録されていないと実現できないことは理解できます。ブロックチェーン側のデータフォーマット仕様にも関わる話になってしまうと後からの変更や対応は難しいかもしれないなあ、といった事情もあるのでしょう。

この「ブロックチェーンからリストア」の実現について、色々面倒な制約があってできないのか、それともあまり重要視されていないのかわかりません。ただ自分のような開発者・運用者の視点からはこれがブロックチェーン側の機能の一部として実現できたらバックアップへの不安という心理的な負担を軽くことのできる開発プラットフォームが実現できて、それは開発にブロックチェーンを採用するメリットにもなり得るのではないか、、、と感じていたのでした。



そして、実はいま上述した3点を含む「開発者視点で考えた、使いやすいブロックチェーン」を実装中です。「開発者視点」と言いつつ、あくまで「自分の視点」ではありますけど(笑)。簡単に特徴を列挙するとこのような感じ:
  • 名前は HATOYA 、デフォルトの実行ポート番号は 4126
  • 表向きは REST API でデータベースやデータベース内のドキュメントを CRUD(Create/Read/Update/Delete 加えて Search も) 可能な JSON データベースシステム
  • データベースやドキュメントへの変更トランザクションは全て内蔵ブロックチェーンに自動記録
  • 複数ノードでブロックチェーンネットワークを作ると、参加するノードのブロックチェーン情報は1つにマージされる。つまりブロックチェーンネットワークで1つのブロックチェーンを共有管理する(データベース情報は共有しない)
  • ブロックチェーンネットワークにはプライベートネットワークからも参加可能(ただしその場合は push 型の同期処理となる)
  • サーバー引っ越し時や、データ破損時などにブロックチェーンからデータベースをリストアすることができる

なおスケーラビリティやアベイラビリティ、セキュリティといった非機能要件はまだ不十分な上、機能実装も現時点ではあくまで予定としているものではあるのですが、上述3点については実現にも目処が立っています:
20200724



現在は複数ノード環境での動作テストやデバッグ、このブロックチェーンを使ったツールやサンプルアプリなどを開発するのが中心の段階に至っています(つまり上述の3点の特徴含めてある程度は動く状態になっています):
2020072400


近い将来になんらかの形で公開予定です。本来アプリケーション開発とは利用者の観点を重要視するべきで、そこを開発者観点で作ることに異論を唱える人が存在するであろうことも理解しています。ただブロックチェーンってそもそもエンドユーザーが意識するべきものではないし、「ブロックチェーンの利用者」が誰なのかを考えると、それは「開発者」であるという視点があってもいいのかな、と。そう考えた時の答の1つになれればいいと思っています。あと深く勉強しなくてもすぐに実装が開始できるので、PoC 的な用途には向いているんじゃないかなあ、とも。

まだ動くものを公開していないので感想を持ちにくいということも理解していますが、こういった考え方で作られるブロックチェーンへの賛同や反論などありましたら、傷が浅いうちに(笑)ぜひ聞いておきたいです。コメント等でご意見いただければと。


(追記 公開しました)
HATOYA の Docker イメージを公開
HATOYA をマルチノード運用して、ブロックチェーン情報を分散管理する

日本時間の 2016 年 4 月 1 日に、レッドハット社から驚きの発表がありました:
No-Cost RHEL Developer Subscription now available

2016040101



開発(者)向け、という条件は付きますが、RHEL(RedHat Enterprise Linux) を含む Devloper Suite が無料でダウンロード可能になった、というものです。マジか!?これはタチの悪いエイプリルフールだろ?と思ったのですが、このニュースは米国時間の 3 月 31 日にリリースされており、エイプリルフールではなさそうです。。

自分はこれまで RHEL のコミュニティ版ともいえる CentOS ばかり使っていましたが、ついにこの領域にレッドハット社が脚を踏み入れることになるとは。。 色々な事情や背景も考えられますが、なにはともあれ使えるものなら使ってみたいわけです(笑)。試してみました。


まずは RHEL のダウンロードサイトへ行ってみると、既にこの発表を反映した内容になっています:
http://developers.redhat.com/products/rhel/download/

2016040102


このサイトから RHEL 7 がダウンロードできるようになっている模様です。リンクをクリックすると、アカウントログインが求められます。RedHat Developer アカウントを持っている場合は入力、持っていない場合は新規に作成してログインします。各種SNSの情報に紐付けたサインインもできるようです:
2016040103


そしてアカウントプロファイル作成後にログインすると、その場から RHEL サーバーの ISO イメージのダウンロードが開始されました(バージョン 7.2 の 64bit 版でした。そういや 7.x って 32bit 版ないんだっけ)。インストールなど、ダウンロード後の作業手順についてもここから参照できるようです:
2016040104


といっても特別な手順が必要なわけではなく、普通に ISO(DVD) からブートできます:
2016040105


インストーラーも普通でした。最初に日本語選んでおけばインストール作業から日本語GUIで行えます:
2016040106


インストールが完了してリブートした直後の画面がこちらです。"LICENSE INFORMATION" に警告マークがついているので、ここをクリックします:
2016040107


ライセンス条項を読み、確認して、同意にチェックを入れ、左上の「完了」ボタンで戻ります:
2016040108


画面が戻ると先程の警告マークが消えているはずです。右下のボタンで設定を完了します:
2016040109


「ようこそ」画面が出るので更に進めていきます。すると・・・:
2016040110


じゃーん!
2016040101


個人的には見る機会の少ない RedHat Enterprise Linux のデスクトップ画面が表示されました。7.x になってからは本当に初めてかもしれない。。 ともあれ、無料のアカウント登録だけで本当に使えてしまいました。

動いてしまえば、後は慣れた CentOS の感覚(?)で使えるようになります:
2014040101






個人では、ヤフーデベロッパー API を活用しています。個人での話です、あくまで(苦笑):

http://developer.yahoo.co.jp/


自分が個人運用しているサービスの中では、例えば「ねっぴ」では Yahoo! ショッピングの商品情報(価格など)を取得するためにショッピング Web API を使わせていただいています:
http://developer.yahoo.co.jp/webapi/shopping/

また「ツイートマッパー」では、隠しページではありますが、マップの API として Google MAP ではなく、YOLP(Yahoo! Open Local Platform) を使ったバージョンがあったりします。こちらは気象情報 API で天気図レイヤを重ね、天気図と一緒にツイートマッパーを表示することもできます。ゲリラ豪雨の情報が天気図でもツイートでもわかる、といった感じで使えます:
http://tweetsmapper.juge.me/yolp_index.jsp

2015081801


・・と、個人デベロッパーとしては実は色々な所でヤフーデベロッパーから提供されている API を使っているのですが、最近になって、「テキスト解析」という気になる API を見つけました:
http://developer.yahoo.co.jp/webapi/jlp/

日本語の「係り受け解析」「ルビ(よみがな)振り」なども面白そうですが、特に気になったのは「日本語形態素解析」 API です:
http://developer.yahoo.co.jp/webapi/jlp/ma/v1/parse.html


この API はインプットデータとして
 「ここのラーメンは絶品で美味しい」
のような日本語テキストを与えて実行すると、その実行結果アウトプットに、以下の様な単語単位に区切ったデータを返してくれる、というものです(実際には表ではなく XML 形式で返されます):
単語読み品詞
ここここ名詞
副詞
ラーメンらーめん名詞
副詞
絶品ぜっぴん名詞
副詞
美味しいおいしい形容詞

形態素解析 API の具体的な使い方はこんな感じです。まずヤフーデベロッパー API を使う上で必要になる「アプリケーションID」を登録します(実際にはこの手順でアプリケーションIDとアプリケーションシークレットを取得しますが、日本語形態素解析APIでは後者は使わないようです)。詳しくはこちら:
http://www.yahoo-help.jp/app/answers/detail/p/537/a_id/43397

アプリケーション ID が取得できたら、その文字列を使って以下の様なクエリーを発行します:
http://jlp.yahooapis.jp/MAService/V1/parse?appid=(アプリケーションID)&sentence=(解析したい文章をUTF-8エンコードしたもの)

ウェブブラウザで実行すると日本語のエンコードは自動で行ってくれるのでそのまま指定できます。例えばウェブブラウザのアドレス欄に以下の文字列を指定して実行してみます:
http://developer.yahoo.co.jp/webapi/jlp/ma/v1/parse.html?appid=(アプリケーションID)&sentence=ここのラーメンは絶品で美味しい

実行結果はこのような感じになるはずです。与えた「ここのラーメンは絶品で美味しい」というテキストを形態素解析した結果が XML フォーマットで取得できています:
2015081901


この XML を詳しくみるとこんな内容になっています。なんとなく上記の表に対応した結果になっていることがわかります:

<ResultSet xsi:schemaLocation="urn:yahoo:jp:jlp http://jlp.yahooapis.jp/MAService/V1/parseResponse.xsd">
 <ma_result>
  <total_count>7</total_count>
  <filtered_count>7</filtered_count>
  <word_list>
   <word>
    <surface>ここ</surface>
    <reading>ここ</reading>
    <pos>名詞</pos>
   </word>
   <word>
    <surface>の</surface>
    <reading>の</reading>
    <pos>助詞</pos>
   </word>
   <word>
    <surface>ラーメン</surface>
    <reading>らーめん</reading>
    <pos>名詞</pos>
   </word>
   <word>
      :
   </word>
  </word_list>
 </ma_result>
</ResultSet>


この API に、例えばこちらで提供されているような「単語感情極性対応表」のデータを合わせて使うことを考えてみます:
http://www.lr.pi.titech.ac.jp/~takamura/pndic_ja.html 

つまり単語ごとに「ポジティブ度合い」や「ネガティブ度合い」がデータとして与えられることになります。上記の形態素解析でテキストを単語ごとに分解して、分解した単語ごとにポジティブ/ネガティブ度合いを調べて加算すれば、テキスト全体のポジティブ/ネガティブ度合いが計算できるのではないか? という仮説を思いつきました。つまりこんな感じ:
単語読み品詞ポジ/ネガ
ここここ名詞-0.629
副詞 
ラーメンらーめん名詞 
副詞 
絶品ぜっぴん名詞+0.980
副詞 
美味しいおいしい形容詞+0.991
合計+1.342

これで、元の文章「ここのラーメンは絶品で美味しい」という文章は、単語のポジ/ネガのプラスマイナスの結果が +1.342 なので、文章全体としてもポジティブになるのではないか? という仮説です(まあ、現実はこんなに単純ではないとわかった上での仮説ですが・・・)


とまあ、こんなサービスの基本となる形態素分析が無料の API で提供されているわけです。これは便利!使わにゃ損だ!!

実際にこのサービスを作ったら、公開するつもりです。


 

「iPhone でゲームボーイアドバンスのゲームがプレイできる」というフレコミの GBA4iOS というアプリのバージョン 2.0 がリリースされた、というニュースがありました。

いわゆる「エミュレータ」というやつで、ここでその是非についてコメントするつもりはありません。脱獄した iPhone 向けには以前から提供されていたもので、その意味では特別目新しいニュースでもありません。

が、今回ちょっと気になったのは、「脱獄不要である」という点です。脱獄不要ということは、そのアプリは App Store からダウンロードするということ? アップルがそんなアプリの審査通すの? と。

といった好奇心から、自分でもこのアプリをインストールしてみました。結論としては確かに iPhone にネイティブアプリとしてインストールできているようです。
2014022102


でも導入時に App Store は経由してません
。当たり前だよな、Apple がこんなの許可するわけがない。また(この機種に限ってはw)脱獄もしてません。 アプリ開発者が App Store を経由せずにテストアプリを導入する方法はあるんですが、その場合は電話番号とか iPhone の UDID とかを入力する面倒な手間があります。今回はそういうのも聞かれてないので、ちと違う気がする。 一体どういうこと?? どこからどんな仕組みでこのアプリはインストールされたんだ??


で、他の作業で VPN の設定とかをしていてふと気付いたのが、設定 - 一般 - プロファイル の中に「プロビジョニングプロファイル」として GBA4iOS という、そのまんまの名前のプロファイルが追加されていました。これは??
2014022101


・・・プロビジョニングプロファイルか、ああ、なるほど。分かった気がする。おそらく、以前にちょっと話題になった「iOS デベロッパーエンタープライズプログラムに抜け穴があった」という件に関係してるんだろう。

要は、自社とか特定の企業向けにアプリケーションを提供したい、という企業に対して、Apple はその企業専用のミニ App Store もどきを用意できるようにして、そこから特定ユーザーだけにアプリケーションをインストールさせる、というのが iOS デベロッパーエンタープライズプログラムです(詳しくはこちら)。そこにセキュリティホールというか抜け道があった、というものでした。それを応用(?)して制約なしに誰もがそのミニ App Store もどきを使えるようにしたんだろうな。 
念のため補足すると、このデベロッパーエンタープライズプログラムは契約時に利用条項に同意する必要があり、その中で不特定多数に向けてアプリを提供することは禁止されているので、Apple にすれば「契約違反」ということになるんでしょう。ただその抜け道の存在は想定外だったのだろうな、と。

その後もイタチごっこのような状況が続いていますが、今回の GBA4iOS 2.0 がリリースされた所をみると完全に防ぐのが難しい、ということなのかもしれません。



 

このページのトップヘ