ことさら−古都プログラマーの更級日記

京都でお寺を回りながら御朱印集めをしていたエンジニアのブログ。おもに技術的なはなしとか日常的なはなし。たまにカメラの話や競馬の話も書きます。

【開催中】2018 サロン・デュ・ショコラに行ってきた

www.salon-du-chocolat.jp

世界各国のパティシエが来てチョコを買えるイベントです。

今年は1/28(日)までの7日間開催しています。

気になったチョコとしては

銀座千疋屋。結局パンフレットのチョコは買わず別のチョコを買いました。現地に行くと、パンフレットにないチョコも結構売ってます。

f:id:yoshiki_utakata:20180123141235p:plain

明治ザチョコレート、今年の新作であるメキシコホワイトカカオミルクを買いました。まだ食べてはいません。フードコートのページにもありますが、カカオジュースが売っています。飲んだことない人はい一度飲んでみてもいいかも。

f:id:yoshiki_utakata:20180123141327p:plain

パティスリーコヤマはバームクーヘンなども気になりましたが、ザッハトルテを買いました。甘すぎず、中に入ったジュレがきいていて非常に美味しかったです。数日たつとまた味が変わったりするそうで楽しみです。

f:id:yoshiki_utakata:20180123141315p:plain

結局買っていないのですが非常に面白いチョコ。スプーンですくって食べるっぽい。

f:id:yoshiki_utakata:20180123141329p:plain

去年のサロンデュショコラでかったレザベイユのチョコ。チョコの中にはちみつがはいっていて非常においしいです。見た目もハニーポッドの形をしていてかわいいです。去年買ったので今年は買いませんでしたが、かむととろっと出てくるはちみつとチョコの相性が良くてオススメです。3個入りとかのちっちゃいサイズのもあります。

f:id:yoshiki_utakata:20180123141333p:plain

フードコート。どれも美味しそうですが、左ページ真ん中のミルフィーユを買いました。美味しかったです(こなみ)。パティスリーコヤマのバームクーヘンも買いたかったけど、ザッハトルテが買えたのでバームクーヘンは諦めました(なるべくいろんなお店のチョコを買いたい)。

f:id:yoshiki_utakata:20180123141351p:plain

一番右下のソフトクリームがめっちゃ気になっていましたが食べるの忘れてました...。右下のジャニスウォンの、カカオの形したやつもおいしそうでした。

f:id:yoshiki_utakata:20180123141354p:plain

明治のカカオジュースを飲みました。カカオジュースのそこにチョコレートが沈んでいる感じでしたが、そこまで甘くはなく、どちらかと言えば酸っぱい感じでした。去年のサロン・デュ・ショコラで右上のエリタージュのカカオジュースを飲んだのですが、個人的にはエリタージュのカカオジュースの方が好きでした。

f:id:yoshiki_utakata:20180123141359p:plain

いろいろ回ったので今回の記事では全部書ききれませんでした。他にも回ったり買ったりしたので、また続きを書くかもしれないです。

git rebase --continue しようとして No changes - did you forget to use 'git add'? と言われたらどうしたらいいのか

最初に結論

git rebase --skip すれば良い。

状況

git rebase しようとしたり、 git merge しようとしてconflictするとがあります。こういった時、大抵はコンフリクトを解消した後、git add して git rebase --continuegit merge --continue することになります。

しかし、コンフリクトを解消した結果、git add するものがなくなってしまった場合、git rebase --continue すると以下のエラーメッセージが出ます。

$ git rebase --continue
Applying: ほげほげを修正
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.

これは例えばこのような状況でおきます。

ブランチAをmasterにrebaseしようとしてコンフリクトします。

$ git checkout A
$ git rebase master

First, rewinding head to replay your work on top of it...
Applying: ほげほげを修正
Using index info to reconstruct a base tree...
M   hogehoge.php
Falling back to patching base and 3-way merge...
Auto-merging hogehoge.php
CONFLICT (content): Merge conflict in hogehoge.php
Failed to merge in the changes.
Patch failed at 0001 ほげほげを修正
The copy of the patch that failed is found in:
   /home/yoshiyuki_sakamoto/.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

でここで実は If you prefer to skip this patch, run "git rebase --skip" instead. って出てたんですよね...(気づかなかった)

  • コンフリクトを解消して続ける場合は git rebase --continue
  • このパッチを飛ばす場合は git rebase --skip
  • rebaseを諦める場合は git rebase --abort

としろと。

まあとりあえずコンフリクトを解消しようとします。 git statusgit diff を見てみます。

$ git status
rebase in progress; onto f8464df
You are currently rebasing branch 'batch-pdo' on 'f8464df'.
  (fix conflicts and then run "git rebase --continue")
  (use "git rebase --skip" to skip this patch)
  (use "git rebase --abort" to check out the original branch)

Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

    both modified:      hogehoge.php


$ git diff
diff --cc hogehoge.php
index 5e0d708,bd484f9..0000000
--- a/hogehoge.php
+++ b/hogehoge.php
@@@ -67,19 -67,11 +67,27 @@@ class Hogehoge

        public function get_hoge() {
++<<<<<<< HEAD
 +              $host_info = explode(':', $host_port);
 +              $host = $host_info[0];
 +              $port = isset($host_info[1]) ? $host_info[1] : null;
 +
 +              return 'mysql:host=' . $host . ';dbname=' . $this->get_db_name();
++=======
+               return 'mysql:host=' . $host_port . ';dbname=' . $this->get_db_name();
++>>>>>>> ほげほげを修正

まあ修正内容はなんでもいいのです。ここで、HEAD(つまりmasterの方)が正しそうなので、git checout HEAD hogehoge.phpgit checkout master hogehoge.php とかでもいい) します。すると、

$ git checkout HEAD hogehoge.php

$ git status
On branch deploy
nothing to commit, working tree clean

nothing to commit に、この状態で git rebase --continue しようとすると、No changes - did you forget to use 'git add'? と言われます。continue でいいじゃないか!って思うんですけどね...無をcommitすることは出来ないので git rebase --skip することになります。continueした時に差分が無い場合は勝手にskipして欲しいと思ったりもするんですが、誤解を避けるためか勝手にskipとかはされないようになっております。

--continue, --skip, --abort ちゃんと使いこなせるようになっておきたいですね。

参考記事

uozias.hatenablog.com

201801-16 もやもやブロックチェーンが理解できる!のメモその3: 活用事例など

先日以下のイベントに参加してきました。

connpass.com

今回は早川さんの「ブロックチェーンの活用形態と活用事例」と、その後のパネルディスカッションのメモです。今回は技術というよりはビジネス的な話になります。

ブロックチェーンの活用形態と活用事例

(図がないと説明しづらかったので、発表資料の公開を待ちます🙏)

ブロックチェーンのメリット

  • 中央機関や集中システムを必要としないことで低コスト・短期間で実現
  • ビジネスプロセスの簡素化、迅速化、自動化。可監査性やトレーサビリティの向上

ブロックチェーンに適した業務

  • 中央集権的な参加者が「集中システムでいいじゃん」と言い出さないか
  • 取り扱う情報(取引など)の公開条件が複雑すぎないか
  • トランザクションレスポンスの要件が厳しすぎないか(処理の速さ、件/秒)

また、現状中央集権的に成り立ってしまっているものを置き換えるのは非常に難しい。

パネルディスカッション

質問に対してパネラーの方が答えていくという形式で進んでいきました。

分散といっているが個々の負荷を下げるというわけではないという認識でしょうか

分散、というのは、オーナーシップの分散である。

中央集権がなくなってプラットフォーマーがいなくなるという話があるがそこはどうか

例えば、Uberが持っているデーターや決済というのは分散処理させることができる。

ただ、Uberが持っているビジネスモデル、例えばドライバを評価する仕組み、みたいなのはブロックチェーンでなんとかなるものではなく、Uberのビジネスモデルであるため、そこがプラットフォーマーの役割である。

Uberがデータを分散させることで、Uberがデータを不正に操作しているかとか、ドライバーの評価が不正に操作していないことは分かる。

ただ、ある意味中央集権的であることで、Uberが信頼できさえすればそのデータは信頼できるということになる。そのほうが信頼性が高いこともある。

また、既に中央期間がシステムを構築している状態からブロックチェーンに移すのはコストが高いのが問題点としてある。

ブロックチェーンは本当に必要なのか

新しいビジネスモデルを生み出してくれる有用なものではないかなと思っている。

もやもやブロックチェーンが理解できる!のメモその2: Hyperledger Fabric V1 最新情報の紹介

先日以下のイベントに参加してきました。

connpass.com

今回はIBM研究所の吉濱さんの発表「Hyperledger Fabric V1 最新情報の紹介」を聞きながら僕がとったメモを公開するだけのコーナーです。

以下メモの内容です。

Hyperledger というのはオープンソースコミュニティの名前。

Linux Foudation の中のプロジェクト。

Hyperledger Fabric はオープンソースブロックチェーン基盤。

ブロックチェーンの基本的機能

データ構造

「ブロック」と「ステート」がある。

ブロックは取引を幾つかまとめたもの。ブロックごとにハッシュを持っている。 つまり取引記録。

ステートは口座残高。実はBitCoinはステートを持っていないので、口座残高は、過去の取引の合算によって行われる。

トランザクション処理方式

ビットコインはUTXOという方法。コインの受けわたしなど、決められたいくつかの取引が可能。

スマートコントラクト。プログラマブルでもっと複雑な処置が可能。

コンセンサス方式

POW: 無駄な計算して特定の値を見つけた人がブロックを追加する、という方式でコンセンサスを取っている。 欠点もある。

  • 51%攻撃
  • 電力消費
  • ファイナリティの欠如

ファイナリティの欠如という問題もあり、不正なブロックチェーンは無効化されてしまうので、取引が無かったことになってしまう場合もある。

もっと安全で簡単なコンセンサス方式がいいのではないか。

分散コンセンサス形成アルゴリズム というものがある。低電力でファイナリティを保証しているようなアルゴリズムである。ただ、ノード数が増えるとパフォーマンスが落ちやすいという問題がある。

POWはパブリックだが、分散コンセンサスはPublicではない。

ブロックチェーンとして求められる性質

  • 障害耐性
  • 単一障害点がない
  • 単一信頼点がない

利用技術

Public/POW

  • UTXO: bitcoin
  • Smart Contract: ethereum

Permissioned 分散コンセンサス形成

  • UTXO: Quorum
  • UTXO: Hyperledger Fabric

今後のブロックチェーン

2016年に多くの金融機関が実証実験完了 金融機関以外でも展開

Hyperledger Public のリリース

  • Fabric v0.6
  • Fabric v1.0: 無停止でノードを追加出来なかったりなどの問題を解消
  • Fabric v1.1: 今年リリース予定。パフォーマンスの改善など

もやもやブロックチェーンが理解できる!のメモその1: ブロックチェーンとは

2017年1月15日、以下のイベントに参加してきました。

connpass.com

ブロックチェーン、勉強はしたいとは思いつつもなかなか機会に恵まれませんでしたが、いい機会でしたので参加してきました。そして結果としては非常にためになりました。

今回は、最初に発表されました、IBMの山下さんの発表を効きながら僕がとったメモをまとめておきます。

山下さんは「ブロックチェーンのビジネスバリュー」と題しまして、ブロックチェーンビットコインのお話をされました。このお話の最終目標としては

  1. ブロックチェーンは何なのかを理解する
  2. ビットコインの話をされた時に、これは「ブロックチェーン」の話なのか、「ビットコイン特有」の話なのかを理解できるようになる

ところかと思います。

メモ

何故ブロックチェーンが難しいと考えるか

実はビットコインの基礎技術は、非常に古い技術である。 そして説明するのがめんどくさい。 あまりかっこよくもない。 故に皆説明を省いたりする。

また、ブロックチェーンビットコインのイメージが強いが、実際そうではない。ビットコインみたいに「分散」していなきゃいけないイメージがある。

ビットコインは可能性に満ちているが、基礎技術や機能、非機能、特徴を理解してない人は何に使っていいのか分からない。

今回は基礎的な部分をやりたい。

「中央集権型」と「P2P分散管理型ブロックチェーン

扱うのは両方トランザクション

中央集権だと、そのサーバーが壊れたり会社が倒産したらなくなってしまう。

P2Pの方が、分散しているので全体が止まることが少ない。かつ不正会計もしづらい。

ではP2Pの方が良いように思えるが、どこが難しいのか。トランザクションまわりが複雑。

  • PCごとに時計が(秒とかミリ秒の単位で)違ったりする。NTPとか使っていても微妙にズレる。時間を完全に信用するとトランザクションの前後が入れ替わったりする。
  • ロックするデータも分散している。いったいどれをロックしたらいいのか。

口座残高と取引とかを考えると分かりやすい。

時間順序をまもって計算するというのが重要。

そこで登場してくるのがブロックチェーン

ブロックチェーンの基礎

「ある取引より前にあるべき取引」のハッシュ値を持つことで、取引をチェーンのようにつなげる。

A->B->C->D

と合った時に、BはAのハッシュを持つ CはA->Bの取引に対応するハッシュを持つ DはA->B->Cの取引に対応するハッシュを持つ

途中の取引とか偽装できない。Bを偽装したらCやDのハッシュ値がおかしくなる。これで順番を保証する。

どうやって分散させるか

あるサーバーが取引をある程度のまとまりでまとめる「アトミック」。そのブロックを全部のサーバーに伝える。伝わると全体が同じ状態になる。(ステートマシンレプリケーション)。 別のサーバーが新たなブロックを追加する。それを全体に伝える。

アトミシテイ(どこからどこまで処理をまとめたらいいのか)

「分散」だけど全てのサーバーが同じ状態を持っている。海外送金も簡単に。分散なのでマスターもない。

(分散というのは負荷の分散ではなく、所有者のぶんさん。データが中央集権的に管理されるのを防ぐための分散)

お金でなくても使える

トランザクション台帳をエンタープライズごとに分散したシステムで共有する トランザクションを扱っていれば、取引なんかを扱っていれば(ECサイトとか)、銀行とかビットコインとかでなくても応用可能。

取引のオープン化

中央集権型の場合、そのサーバーを持っている企業だけが取引が可能。分散型になるとそれがなくなる。

非中央集権型自立組織

トランザクションを書くこと、つまり契約書を書くことが、今保険会社だったり銀行だったりで発生しているが、そこがなくなるので、本来のコア業務に集中できる。

ではビットコイン

ビットコイン」の話をしているのか「ブロックチェーン」の話をしているのか。という話。

  1. トランザクションをデジタル署名
  2. ブロックチェーンをハッシュキャッシュ

ビットコインは安全性を保っている。この2つはビットコイン特有の話であってブロックチェーンの話ではない。

ビットコインは払うか貰うかの2つしかほぼ取引はないシンプルなトランザクション

通過の特性

ビットコインでは以下が必要

  • 本人以外は送金できない
  • 多重譲渡などはできない

マイニングとは

もともとはスパムメールをブロックするための技術。

ブロックのハッシュ値を見つける行為。ブロックチェーンではこんなことをする必要はない(つまりビットコインの特徴)。次のブロックをだれが作るか、というところでマイニングが始まる。ハッシュ値を見つけるとブロックが作れて、取引の手数料とかが貰える。 このハッシュ値を見つける計算はただの無駄な計算。とうことで電力の問題がある。

不正を行う人が不正なブロックを作らないようにしている。

ビザンチン将軍問題というものがある。ネットワークの半数以上が裏切るとネットワークが崩壊するという問題がある。

ビットコインブロックチェーンの一つの実装

ビットコインはほぼ2種類の取引しかない極めて単純な台帳なので、実装しやすく流行ったのではないか。 分散しているがある一定の時間で同期することが期待されるため、トランザクション負荷が分散しているとはいいがたい。

ビットコインの話をしているのかブロックチェーンの話をしているのかは見分けたい。

ブロックチェーンの流れ

Bitcoin(第一世代の仮想通貨) しかしビットコインは電力を無駄に食う問題がある。

第二世代 : スマートコントラクト Hyperledger Ethereum NEM ...

第三世代: より多用途に

ブロックチェーン、どこからはじめるか

ブロックチェーンは基盤技術

例えば、メールというのが開発された時。これは儲かるのかという話があったが、導入してみると非常に便利だった。

ブロックチェーンも似たようなものではないか。「ブロックチェーンは儲かるのか」と聞かれると、儲かるか儲からないかではない。ROI(対費用効果)の話からスタートしない。