Ikuto.Y

1ハゼは「予測」できるか？——複雑系物理学とAIで挑む焙煎の臨界点

Fri, 20 Mar 2026 03:00:00 +0000

ここ数年、手網焙煎にはじまり去年から家におけるコンパクトな焙煎機Aillio（Aillio Bullet R1 V2）を購入して珈琲豆を焙煎している。本記事の検証で紹介するデータもすべて、この Aillio Bullet R1 V2 の焙煎ログを使用している。

Aillioには専用の焙煎ログアプリのRoasTimeがあるが、自由の幅の多いArtisanに乗り換えてからWebsocketでリアルタイムに焙煎ログを飛ばせることを知る。とてもおもしろそうなので、Websocketで飛ばしたログをリアルタイムに表示する焙煎実況アプリを作ってみることにした。

AI真っ盛り、焙煎ログをリアルタイムで可視化するだけでは面白くないので、AIで1ハゼの予兆を検知できないか、検証機能も実装した。

カオス理論と焙煎の出会い：CSD（臨界減速）理論

コーヒーの焙煎において、豆の組織が破壊され水分が気化する「1ハゼ」は、急激な熱変化を伴う暴れ馬のような現象。1ハゼ周辺の温度管理が重要であることを理解し始めたので、そのタイミングを予測できないかと考えた。

そこでGeminiに聞くと、気象学や生態系などの複雑系科学で用いられる臨界減速（Critical Slowing Down: CSD）理論がサジェストされた、おもしろそう。

CSD理論では、「システムが急激な変化（相転移）を起こす直前には、元の状態に戻ろうとする回復の遅れが生じる」とされている。これを焙煎プロセスにおける1ハゼへの相転移と重ね合わせる。

予兆を捉える：自己相関と分散

この「回復の遅れ」を数値化するため、システム内部では主に以下の2つの指標をリアルタイムで監視する。

AR(1) 自己相関: 状態の回復が遅くなり、直前の状態を引きずる度合いの上昇。
分散（Variance）のローリング計算: システム全体の「揺らぎ」が大きくなる現象の検知。

これらの指標が一定の閾値を超えた瞬間、アラートを発し焙煎の臨界点が近いことを知らせる。

検証データ：過去ログによるバックテスト

過去に蓄積した数十回の焙煎ログ（.alog 等）を用いたバックテストの結果、このCSDアルゴリズムは、実際の1ハゼ発生の30〜120秒前（リードタイム）に、悪くない精度で検知できていることが見えた、データからも解析も一瞬でClaudeやってくれる、便利すぎる。

豆の水分量や投入量によってリードタイムに幅はあるが、「もうすぐハゼる」という準備を整えるには十分な時間的猶予だ。

現在のステータス：まだまだはじまったばかり

バックテストでの良さそうな結果は見えたものの、まだまだ実験段階。引き続き焙煎を続けて良さそうな塩梅を見つけていきたい。

焙煎実況アプリはこちらからご覧いただけます： ☕️ ARIGATO COFFEE ROASTERY

Can First Crack Be Predicted? —— Challenging the Tipping Point of Roasting with Complex Systems Physics and AI

Fri, 20 Mar 2026 03:00:00 +0000

Over the past few years, having started with a hand roaster, I purchased a compact home roaster, Aillio (Aillio Bullet R1 V2), last year and have been roasting coffee beans. All the data and logs used for the verification in this article are derived from this Aillio Bullet R1 V2.

While Aillio has its own dedicated roasting log app, RoasTime, I switched to the more customizable Artisan and discovered that I could stream roasting logs in real-time via Websocket. This seemed very interesting, so I decided to build a live roasting app that visualizes the logs sent via Websocket in real-time.

With AI being so prevalent, simply visualizing roasting logs in real-time isn’t quite enough. So, I also implemented an experimental feature to see if AI could detect the underlying signs of the first crack.

Chaos Theory Meets Roasting: CSD (Critical Slowing Down) Theory

In coffee roasting, the “first crack,” where the cellular structure of the bean breaks down and moisture vaporizes, is a phenomenon as volatile as an untamed horse, accompanied by rapid thermal changes. As I began to understand the importance of temperature management around the first crack, I wondered if its timing could be predicted.

When I asked Gemini about it, it suggested the CSD (Critical Slowing Down) theory, a concept used in complex systems science such as meteorology and ecology. It sounded fascinating.

According to CSD theory, “just before a system undergoes a sudden change (phase transition), a delay in recovery, where the system struggles to return to its original state, occurs.” I can overlay this concept onto the phase transition leading up to the first crack in the roasting process.

Catching the Signs: Autocorrelation and Variance

To quantify this “delay in recovery,” our system primarily monitors the following two indicators in real-time:

AR(1) Autocorrelation: The slowing down of state recovery, marked by an increase in the degree to which the immediate past state is carried over.
Rolling Variance Calculation: Detecting the phenomenon where the “fluctuations” of the entire system become larger.

The moment these indicators exceed a certain threshold, an alert is triggered, signaling that the roasting tipping point is near.

Verification Data: Backtesting with Past Logs

As a result of backtesting using dozens of accumulated past roasting logs (.alog, etc.), I’ve seen that this CSD algorithm can detect a clear sign with decent accuracy, 30 to 120 seconds before the actual first crack occurs (lead time). Also, Claude analyzes the data instantly, which is incredibly convenient.

Although the lead time varies depending on the bean’s moisture content and batch size, it provides a sufficient time buffer to prepare yourself that “it’s going to crack soon.”

Current Status: Still Just the Beginning

While the backtesting showed promising results, I am still very much in the experimental stage. I want to continue roasting to find the perfect balance.

You can view the live roasting app here: ☕️ ARIGATO COFFEE ROASTERY

チームでボールを投げあうに至った話

Mon, 06 Dec 2021 00:00:00 +0000

この記事は SmartHR AdventCalendar の6日目です。

従業員が数百人いてかつリモートワークで日々仕事していると普段関わりのない同僚はほんとうに関わらないまま時間は過ぎて少しさみしいなと思っていたところにTwitterに流れてきたtweetがこれ。

We built an internal game at Shopify to make virtual hangouts more fun. It’s called Shopify Party, and I’d love to tell you all about it 👇🏻
[1/6] pic.twitter.com/DwzxwWty3V
— Daniel Beauchamp (@pushmatrix) September 28, 2021

Shopify Partyとはなんぞ？Mario Partyから文字ってるものだと思っていて、Shopify社内でインターナルに公開してるゲームで同僚と一緒になっていろんなミニゲームができるものですと、ちょっとしたアイスブレイクに、スタンドアップの合間に遊びつつ、とっても楽しそうに映りました。

(やってみたい！公開してくれないのかShopifyー。)

これこれこれこれこういうのがあるとリモートでもコミュニケーションパスが増えてよさそう！と思ったので詳しくみていきました。

使われている技術はUnityとマルチプレイヤーを容易に実装できるサービスnormcore.ioを使っていて、WebGL buildでブラウザ上で遊べてしまうと。お手軽！(WebGLはPrivateプランでのみ有効でした)

ということで、ここでは実際にnormcore.ioを使ってものすごく簡単にマルチプレイヤー実現できちゃうんじゃんと驚いたことを記していきます。

まずはSign upから、free planが用意されているので気軽に試すことができました。

チュートリアルがあったので最初にこれを写経して雰囲気を掴みました。プレイヤーの移動ロジックやカメラ移動の実装はあとでごっそり参考にしました。

このチュートリアルにはなかったんですが、normcore.ioはボイスチャットにも対応していて話したい欲求が強くなってきました。会社にはカシュと呼ばれるカルチャーがあって、業後にフリースペースにおのおのそれぞれまばらに集まってフリードリンクを嗜むというものでコロナ前の頃ではよかったんですがいまや家から働くのが普通になってしまったので参加することができず…. これをバーチャルの世界で実現できたら楽しそう！をモチベーションに進めていきました。ゲームの中で自由に歩き回って人の輪を作れておのおのグループになってわいわいできたらいいなを目標にして。

便利なものでUnity Asset Storeにはなんでも揃っているんですね！フィールドにはオフィスを、プレイヤーにはヒトを再現したくていろいろあさったところ

いい感じのオフィスのアセット：https://assetstore.unity.com/packages/3d/environments/urban/hq-archviz-loft-office-modular-186002

歩くなどのアニメーションも付いているタイツマン：https://assetstore.unity.com/packages/3d/characters/stickman-character-prototype-182000

などなどよさそうに思ったので課金しました。

アセットを落としてきてそこからせっせかせっせとそれらしき空間に整えて、チュートリアルにもあったようにEmpty objectにPlayerManagerと名付けてRealtimeコンポーネントを追加しました。ここでApp Keyをnormcore.ioから生成して持ってくる必要がありました。

プレイヤーとしたいタイツマンprefabにはRealtime View/Realtime Transform、それからボイスチャットを可能にするためRealtime Avatar Voiceコンポーネントを追加しました。追加するだけマルチプレイヤーになってしまうすごい。。

だいたい動くことがみれたので、実際に試したい欲が高まり休日に遊んで書いていたものだったんですがチームの雑談時間を利用してチームメンバーに入ってもらって雑談をこの中でできないかテストをお願いしました。

一度目、、惨敗。。。会話ができない。。ヒトの声が聞こえる距離を見誤りめっちゃ至近距離でないと声が聞こえませんでした。あと、タイツマン誰が誰だかわかんない問題。みんなにZoomに入りもらい直して反省会をさせてもらったりしました。感謝

Realtime Avatar Voiceは内部でUnityのAudioSourceを参照してるので明示的に宣言することで自由に設定が変えられ、声が聞こえる範囲を自分のフィールドに合わせて調節しました。

それに加え、名前を表示したり申し訳程度に遊べる機能を追加してまたテストをお願い。

二度目、、聞こえる！喋れる！！

牛になれるオプションを用意したり、

ボールを投げる機能をいれたところ話すより投げるほうで盛り上がり結果雑談をまったくせずひたすらボールを投げては当てて終わりました。

(実際に投げ合う画を撮り忘れたのでそれらしいものを添付)

プレイヤーの位置情報はRealtimeコンポーネントを追加することで勝手にしてくれますが、アニメーションの状態の同期やニックネームの同期は数ステップで必要で、RealtimeModelスクリプトを差し込んでこれを実現できました。

ここまでで、簡単にマルチプレイヤーでボイスチャットができるアプリを作れることが見れました。Zoomなどと違って同じ空間に複数グループを無作為に作って会話ができるのがいいのかなと。話すだけでなくShopifyのようにいろんなミニゲームを仕込んでいくのもよし(大変そう)、metaverseの波に乗ってVRにするのもよし(もはやそれはVRchatかな)、なにがしの形になるように引き続き進めていきます！

さっそくAWS LambdaをRubyで触ってみる

Fri, 14 Dec 2018 00:00:00 +0000

こちらはFrog Advent Calendar 2018の14日目の記事となります。

先月にAWS LambdaがRubyでかけるようになるとAmazonからアナウンスがあり、界隈で話題になっていたので早速手を動かしてみようということで。仕事でもすこーしだけLambdaで実装している部分があって、それはJavascriptで書いています。メインはAWS EC2で複数インスタンスを立ててその中でMicroservicesの形を取って複数のDockerインスタンスが各々Railsアプリを動かしています。で各サービス間はRESTでやりとりしたり、AWS SQS/SNSでサブスクリプションし合う形を取っています。その脇役として小さな処理をLambdaに任せている、ざっくり仕事のバックエンド環境はこのようになります。とりあえずバックエンドのみの説明だけ、backend developerとして働いているので。

さて、Lambdaとは何か、Amazonの公式サイトでは、

Run code without thinking about servers. Pay only for the compute time you consume.

とありますが、少し前にサーバーレスという言葉が流行ってた気がするのだけれど(最近そんな聞かない)、Lambdaはサーバーレスで、小さなアクション単位に作ることができる。RailsとかMVCなアーキテクチャーのフレームワークで例えると、コントローラーの中の１アクションをひとつのLambdaで表現できるイメージで僕はいます。

便利なものでLambdaの発動条件(トリガー)も様々から選べて、RESTで受けるAWS Gatewayから始まり、AWS S3に噛ませればファイルの更新をトリガーに走らせることでもできて、CloudWatach Eventでcronタスクでスケジューラーとしても走らせることができ、考えられることはなんでもできるといったところでしょうか。

それでは実際に触っていくのですが、すごーい簡単なもので何かないか、どうせ作るのなら何か欲しいものをと、考えていたら最近おしゃれなTattooを描くアーティストを見つけたことを思い出し、バンクーバーbasedの人なんですがInstagramのアカウントをちょくちょく見ていて、

View this post on Instagram

A post shared by Yi Stropky (@chinatown_stropky) on Jun 6, 2018 at 12:04pm PDT

こんなおしゃれならちょっとTattoo気になるぞということで、プロフィールの所にBooks reopen soonとあったので、この予約不可から可に変わる時をいち早く知りたいなと、プロフィール欄を逐一確認するのは嫌だよねということでこのBooks reopen soonが変わったことをお知らせしてくれる機能をLambdaでちょこっと作っていきます。

インスタグラムのプロフィールページにアクセスしてBooks reopen soonの有無を確認(予約可になった時にこの文言が消えることを信じてw)
もしも予約可になっていたらSlack上でBotから自分宛にメッセージを送る
これを定期的に繰り返す

というのをコードにすると、こうなりました。飾り気も何もない！

  require 'net/http'
  require 'json'

  INSTA_URL = 'https://www.instagram.com/chinatown_stropky/'.freeze
  SLACK_URL = 'https://slack.com/api/chat.postMessage'.freeze

  def is_ready_to_book(event:, context:)
    insta_uri = URI.parse(INSTA_URL)
    insta_uri.query = URI.encode_www_form({ hl: 'en' })
    https = Net::HTTP.new(insta_uri.host, insta_uri.port)
    https.use_ssl = true
    request = Net::HTTP::Get.new(insta_uri.request_uri)
    response = https.request(request)

    return true if response.body.include?('Books reopen soon')

    slack_uri = URI.parse(SLACK_URL)
    https = Net::HTTP.new(slack_uri.host, slack_uri.port)
    https.use_ssl = true
    header = {
      'Content-Type' => 'application/json; charset=iso-8859-1',
      'Authorization' => "Bearer #{ENV['SLACK_TOKEN']}"
    }
    request = Net::HTTP::Post.new(slack_uri.path, header)
    request.body = {
      channel: ENV['SLACK_CHANNEL'],
      as_user: true,
      text: "The status has changed! Go to #{INSTA_URL}"
    }.to_json
    https.request(request)

    true
  end

これをデプロイしていくわけですが、AWS CLIとAWS SAMを使っていきます。SAMは初めてだったんですが、いいですね、バージョンコントロールができて。仕事ではいまだにLambdaのちゃんとしたデプロイフローが確立できていないのがまずいところで、Lambda以外ではしっかりとあって、Terraformでベースを定義して、独自に作ったコマンドで日々のデプロイをしています。これらのツールはPythonが入ってれば普通にターミナルからコマンド叩いて導入できますね(以前に複数versionのPython入れようとしてなんやかんやしていたせいでSAMが動くようなるまで時間がかかりましたが)。AWS CLIは使う前にconfig設定してあげると使えるようなりますね。

流すコマンドは以下二つ、

  sam package --template-file template.yml --s3-bucket bucket_name --output-template-file packaged.yaml
  sam deploy --template-file ./packaged.yaml --stack-name stack_name --capabilities CAPABILITY_IAM --region us-east-1

ひとつ目がS3 bucketにコードをアップロードして、ふたつ目でLambdaにデプロイするコマンドですね。S3 bucketは事前に作っておく。デプロイが完了したらAWS consoleで確認できるようなりました！

これで走らせるコードは用意できたので、次にトリガーを設定します。ここではCloudWatch Eventを使って10分ごとにコードが走るように設定していきます。

CloudWatchでcronタスクを設定するとこのように確認できました。


  cron(0/10 * ? * * *)

これを作ったLambdaに設定してあげると完成ですね。

あとは寝て待つのみ、、

朝がきて、夜がきて、、

また朝がきて、時は経ち、、

キターー！！！のは来たんですが、実はご丁寧にもInstagramのstoryで告知してたのを先に見てしまっていたのでいつ変わるかを事前に知っていたという。。。

早足で駆け抜けましたが以上が初めてのLambda with Rubyでした。気がつけばバンクーバーに移り住んで３年になるようで、一瞬で時間が過ぎていきました。来年は節目、30歳になる年なのでしっかりNew Year’s resolutionを考えなければなと。。。いやでも本当真剣に。

良いお年を！

codeはここから

It describes Blockchain with minimum line.

Tue, 19 Dec 2017 19:19:00 +0000

What is Blockchain? Bitcoin? I couldn’t understand it lately but there was a cool repository which is naivechain(https://github.com/lhartikk/naivechain), so now I’d love to code and understand it! This repo represents what basic knowledge of Blockchain is with a small amount of codes in Javascript. It’s not fun to just copy the code so I’m going to code this in Ruby here. It seems a lot of people are doing the same thing, so I’m not going to be shy and just do it for me!

ELEMENTS

Node –> Cutting board; everything happens on here
Mining –> Knife; Cut, cut, cut, cut, and cut
P2P –> Cooking chopsticks; This lets you move ingredients to a cutting board from other cutting boards
Block –> Ingredient; sausage
Blockchain –> Sausages; Sausages connect
Hash –> Spice; Secret spice

As you can see, it’s not complex; there’s only a few elements here.

1, PREPARATION

Let’s put the cutting board first. Let’s assume there are multiple cutting boards so that we need to communicate port between them to be able to share the sausages smoothly. It is used by TCPSocket also known as cooking chopsticks to build it. I couldn’t understand the relation between TCPSocket and TCPServer at first, but TCPServer waits for TCPSocket. It waits, waits and waits for coming TCPSocket and if TCPSocket comes at last, then TCPServer waits for another TCPSocket. This is grabbing sausages.

  class Node
    def initialize(port, other_node_ports = [])
      @clients = []
      other_node_ports.each do |other_node_port|
        client = TCPSocket.open('localhost', other_node_port)
        Thread.start do
          listen_message(client)
        end

        @clients << client
      end

      @server = TCPServer.open('localhost', port)
      init_connection
    end
  end

initialize is gonna be like this. It tries to connect to the existing TCPSocket and prepare to wait for other TCPSocket.

2, HANDLING A KNIFE

Everything is on the stage - the cutting board - so then let’s cut the ingredients! This logic shows you one of the important keywords of Blockchain which is mining. We do mining to make the secret spice, and the secret spice is used to make sausage. The more time you take to make the secret spice, the more tasty your sausages will be. That’s a fact, isn’t it? In my understanding, taking much time guarantees the correctness of Blockchain. But I cannot take much time here so I’m gonna use chemical seasoning. It’s called Ajinomoto.

  def mine_with_loop
    Thread.start do
      loop { mine; sleep(Random.rand(10)) }
    end
  end

  def mine
    @blockchain << generate_next_block(@blockchain.last)
    broadcast
  end

This code does mining endlessly. Simplified, it cuts every 0 to 10 seconds. One cut makes one sausage.

  def generate_next_block(block_data)
    previous_block = @blockchain.last
    next_index = previous_block["index"] + 1
    next_timestamp = Time.now.to_i
    next_data = "Smart contract" + next_index.to_s
    next_hash = calculate_hash(
      next_index,
      previous_block["hash"],
      next_timestamp,
      next_data
    )

    {
      "index" => next_index,
      "previous_hash" => previous_block["hash"],
      "timestamp" => next_timestamp,
      "data" => next_data,
      "hash" => next_hash
    }
  end

block includes

index –> which index of block
previous_hash –> previous hash key
timestamp –> created at
data –> data
hash –> proof key

3, FINISH

Finally, you’re going to toss your sausages to people to show them how good your sausages are! You use cooking chopsticks for this part. People who receive your sausages evaluate how your sausages’ tastiness. If they’re delicious and the length of sausages is longer than the person’s own, then the person is going to keep yours but if it’s not, he is gonna throw it away. And then the person will start to cut again.

  def verify(blockchain)
    replace_chain(blockchain) if is_valid_chain(blockchain)
  end

  def is_valid_chain(blockchain)
    if blockchain[0] != get_genesis_block
      return false
    end
    temp_blocks = [blockchain[0]]
    blockchain[1..-1].each_with_index do |block, index|
      if is_valid_new_block(block, temp_blocks[index])
        temp_blocks << block
      else
        return false
      end
    end

    true
  end

  def is_valid_new_block(new_block, previous_block)
    if previous_block["index"] + 1 != new_block["index"]
      return false
    elsif previous_block["hash"] != new_block["previous_hash"]
      return false
    elsif calculate_hash_for_block(new_block) != new_block["hash"]
      return false
    end

    true
  end

4, HOW TO MAKE THE SECRET SPICE

This comes from a secret formula so that it inherits old sausages and adds a new generation. Here we use base64digest to calculate the string. It’s supposed to be an unchanging calculation in order to confirm correctness every time. How to generate hash for real is more difficult than this. I’ll study it another time - here we use simple way:

  def calculate_hash_for_block(block)
    calculate_hash(block["index"], block["previous_hash"], block["timestamp"], block["data"])
  end

  def calculate_hash(index, previous_hash, timestamp, data)
    Digest::SHA256.base64digest(index.to_s + previous_hash.to_s + timestamp.to_s + data.to_s).to_s
  end

END

As we repeat these process Blockchain is getting bigger and bigger. As a starting point here, I’m going to understand:

the algorithm of generating hash
how data exists and how the data exists differently between altcoins (I believe this is why there are many types of altcoins)

etc….. I still have a ton of questions for Blockchain, so I’d love to figure them out one by one.

Here is the source code https://github.com/ikuto0608/naivechain

Dappプログラマへの最初の一歩

Mon, 18 Dec 2017 01:06:00 +0000

こちらはFrog Advent Calendar 2017 (https://adventar.org/calendars/2350)の19日目に載っています。

はじめに

ここ一年のCryptocurrencyの盛り上がり具合は目を見張るものがあります。惜しくもこの波に乗ることはできずミリオネアになることは叶わなかったのですが、Teck業界に従事するものとして知識としてこれらの技術を学ぶのは大切なのではないかなと、まだ遅くはないことを祈ってぐぐっていきたいと思います。

Dappって?

Dappとは decentralized app の略でBlockchainをベースとする、かつ従来の、データベースをひとつのところで管理しないアプリケーションを指すところが広義の意味だと思うのですが実際にはEthereumをプラットフォームとする派生のアプリケーションをDappと言っているように思います。代表的なところでは

Storj –> Cloud storage
Gnosis –> Prediction market platform
Decentraland –> A virtual world owned by creators, powered by economic opportunity
Golem –> Distributed computation

などが挙げられます。上記のアプリケーションはhttps://www.stateofthedapps.com/の一覧で見られ、かつhttps://coinmarketcap.com/で上位に位置するものをピックアップしました。あとはつい最近話題に上がったcryptokitties、こちらもEthereumを使ったDappですね、あまりにもTransactionに負荷をかけたことから話題を呼んでいましたねhttps://cryptovest.com/news/ethereum-loses-to-cryptokitties-network-remains-slow/。こちらは嬉しいことにバンクーバーを拠点とする企業が作ったもので親近感がいっそう湧きましたaxiomzen。(就活中にこの企業に応募しましたが返事は返って来ず。残念)

なんでEthereumなのか

decentralizedなアプリケーションを一から作るのは敷居が高いのですが、この敷居を下げてくれたのがEthereum。イメージとしてはすでにもう存在するEthereumネットワークを間借りする形でそれぞれDappを開発できる。それぞれの Contract が Ethereum の Transaction に積まれていく、ただし個々の Contract はそれぞれアプリで固有なので呼ばれた先で振る舞いがそれぞれ違う。そんな形でいろんなDappがEthereumネットワークを共有している、というのがふわっとした私の理解です。

どうやってDapp作るの？

このチュートリアルブログ(https://medium.com/@mvmurthy/full-stack-hello-world-voting-ethereum-dapp-tutorial-part-1-40d2d0d807c2)を参考に投票アプリをプログラミングしていきます。開発する上でキーとなるライブラリ/アプリケーションはこちら

geth –> ローカルにEthereumのNodeを立ち上げるsoftware
truffle –> 自分で作ったcontractをコンパイル/デプロイするフレームワーク
web3js –> クライアントでEthereumと交信するためのライブラリ

これらを使いこなすことがDappプログラマの条件なんじゃないかなと。とはいえ、実際のところ私はまだこのチュートリアル Part2で止まっているのですが、、なぜか？

環境構築って大事

どこで今つまづいているか、Dappを作る上で欠かせないのはEthereumですね。Ethereumには二つのパプリックネットワークが存在していて Mainnet (通称 Homestead )と Testnet (通称 Ropsten)があります。本番用のネットワークとテスト用のネットワークですね。なので開発途中は Ropsten に接続して実際に動作をチェックできるようになっているのですね、便利!で私は今 Ropsten に接続するところで詰まっていまして、、初めてネットワークに接続する場合には、存在するBlockchainをまず全てローカルに落とさなきゃいけないのですがそれが終わらない、数GBあるものなので時間がかかることは明記されているんですが、P2Pが全然繋がらず、繋がってもFailedする始末、困ったなと。

およ、といいつつももう少し待っていたら

  truffle(development)> web3.eth.syncing
  { currentBlock: 151872,
    highestBlock: 2287008,
    knownStates: 1,
    pulledStates: 0,
    startingBlock: 77312 }

となり最新のブロック情報 (https://ropsten.etherscan.io/block/2287104)と比べると値が近いのでこれはやっとスタート地点のたったのではないかなと。いやまだでした

  truffle(development)> web3.eth.getBlock("latest").number
  0

あれれ、最新の値が取れない、syncが正常にできていないのか。それが証拠に

  truffle(development)> web3.eth.getBalance('0x2bd86de9be88fedffccd5fe6f6777dfe51bc00d2')
  { [String: '0'] s: 1, e: 0, c: [ 0 ] }

自分のアドレスに正しい Ether の値が表示されない。本来なら所持している 5 Ether (https://ropsten.etherscan.io/address/0x2bd86de9be88fedffccd5fe6f6777dfe51bc00d2)表示されるはずなんですが。ちなみにこれは自分で mine したわけではなく、redditで自分のアドレスを投稿すると誰かが送ってくれます。 5 Ether は今の相場ではUS$1,400-くらいですね、テスト用なんで無価値ですが。

終わりに

全然終わっていないのですが、諸事情により本日はここまでとさせていただきます。次回にはチュートリアル完結版をあげれるように励みます。

救いの一手をお持ちの方はご一報いただけると。 「聞くはいっときの恥、知らぬは一生の恥」 祖母が口すっぱく言う言葉より

最小コードでBlockchainを表現する

Thu, 07 Dec 2017 19:19:00 +0000

ブロックチェーンて？Bitcoinて？具体的にはどんなものかというのが複雑でいまいち把握できずにいたところ、このnaivechain(https://github.com/lhartikk/naivechain)というrepositoryに出会ったので写経しつつ理解しようと思いました。ここでは最小限の機能を持ったブロックチェーンを最小行のソースコードで表現しているのでブロックチェーンの基本的な考えをやさしく理解できるのではないかなと思います。同じようにnaivechainを参考に書き換えているrepositoryがGithubでたくさん見られたので負けじと僕もやっていこうかなと。Javascriptて書かれたものなのですがこれをRubyでかき換えつつ噛み砕いでいった過程を記します。

登場人物

Node –> まな板ですね、全ての作業はここで行われる
Mining –> 包丁ですね、絶えずシャキンシャキン動いています
P2P –> 菜箸ですね、まな板から他のまな板へ材料を移動させる感じ
Block –> 素材です、ウインナーです
Blockchain –> 腸詰です、ウインナーが連なってます
Hash –> 秘密のスパイスです

といったようにあまり数が多くないので本当にシンプルに事は進みます。

1, 仕込み

まな板を準備します、複数まな板があることを前提として、腸詰を上手にシェアするために port を教えあいます。菜箸こと TCPSocket を使ってP2Pを実現します。 TCPSocket と TCPServer の関係が正直なところ最初 ？ だったんですが、 TCPServer はひたすら TCPSocket が来るのを待つんですよね、待って待ってついに TCPSocket がきたら他の TCPSocket をあてがってあげて、また新たな TCPSocket が来るのを待つんです。待つんです。掴んでいるのは腸詰です。

  class Node
    def initialize(port, other_node_ports = [])
      @clients = []
      other_node_ports.each do |other_node_port|
        client = TCPSocket.open('localhost', other_node_port)
        Thread.start do
          listen_message(client)
        end

        @clients << client
      end

      @server = TCPServer.open('localhost', port)
      init_connection
    end
  end

こんな感じに initialize はなりまして、すでに存在する TCPSocket のportに通信を試みる役割と、あとで TCPSocket が通信して来る時の備えの役割が主ですね。

2, 包丁さばき

舞台はまな板の上で整ったので具材を切っていきしょう。ブロックチェーンで重要なキーワード mining と呼ばれる処理がここになりますね。 mining を行って秘密のスパイスを生成します、これを加えたものがウインナーになります。秘密のスパイスを作るのに時間をかけるとその分ウインナーが美味しくなるのは自明ですね、その時間をかける工程によってBitcoinは信頼性を保っていると理解しています。ここではあまり時間をかけられないので化学調味料で代替します。味の素です。

  def mine_with_loop
    Thread.start do
      loop { mine; sleep(Random.rand(10)) }
    end
  end

  def mine
    @blockchain << generate_next_block(@blockchain.last)
    broadcast
  end

mining をエンドレスに行います、行いますが容易に変化がみれるように1シャキンあたり0〜10秒待ってシャキンシャキンします。一振りで一つのウインナーが作られます。

  def generate_next_block(block_data)
    previous_block = @blockchain.last
    next_index = previous_block["index"] + 1
    next_timestamp = Time.now.to_i
    next_data = "Smart contract" + next_index.to_s
    next_hash = calculate_hash(
      next_index,
      previous_block["hash"],
      next_timestamp,
      next_data
    )

    {
      "index" => next_index,
      "previous_hash" => previous_block["hash"],
      "timestamp" => next_timestamp,
      "data" => next_data,
      "hash" => next_hash
    }
  end

block に含まれているのは

index –> 何番目のブロックか
previous_hash –> 一つ前の鍵
timestamp –> 作れた時刻
data –> データ
hash –> 正しさを示す鍵となるもの

から構成されています。

3, 仕上げ

ここで作ったウインナーを腸詰に繋げてみんなに自慢するために他のまな板へ投げつけます、使うのは菜箸です。これを受けとった他のまな板は、この腸詰の完成度をひとつひとつ入念に調べます。完成度が満足していてかつ腸詰の長さ(ウインナーの数)がおおきければ自分が作っていた腸詰は捨てこれを採用します。出来が今一つの場合、これを投げ捨てます。どちらにせよそこからまた包丁をシャキンシャキンしていきます。

  def verify(blockchain)
    replace_chain(blockchain) if is_valid_chain(blockchain)
  end

  def is_valid_chain(blockchain)
    if blockchain[0] != get_genesis_block
      return false
    end
    temp_blocks = [blockchain[0]]
    blockchain[1..-1].each_with_index do |block, index|
      if is_valid_new_block(block, temp_blocks[index])
        temp_blocks << block
      else
        return false
      end
    end

    true
  end

  def is_valid_new_block(new_block, previous_block)
    if previous_block["index"] + 1 != new_block["index"]
      return false
    elsif previous_block["hash"] != new_block["previous_hash"]
      return false
    elsif calculate_hash_for_block(new_block) != new_block["hash"]
      return false
    end

    true
  end

4, 秘密のスパイスの作り方

秘伝の業でなされるものなので、過去のウインナーを参考にしつつ新しい血を加え、特定のアルゴリズム(ここではbase64digest)を用いて文字列に変えます。この値の確かさをのちに確かめる必要があるのでこの変換結果は普遍でないといけないですね。ここのhashの生成方法過程が実用されているコインではきっと面白難しいはずなので追々もっと深掘りしていこうと思います。ここでは簡易的に味の素を使用します。

  def calculate_hash_for_block(block)
    calculate_hash(block["index"], block["previous_hash"], block["timestamp"], block["data"])
  end

  def calculate_hash(index, previous_hash, timestamp, data)
    Digest::SHA256.base64digest(index.to_s + previous_hash.to_s + timestamp.to_s + data.to_s).to_s
  end

終わりに

といった風に以上の工程を繰り返し繰り返し行い、ブロックチェーンは巨大化していくのですね。これをはじめとして

hash生成のアルゴリズム
dataの存在の仕方の詳細、各々コインでどんなdataが入っているのか、多分そこが色々あるコインの特徴となるところなんじゃないの？
本当に各Nodeがすべてのブロックチェーンを保持しているの？それってものすごく長くない？

などなど疑問は山積みなのでひとつひとつ神砕ければなと思います。

コードはここに https://github.com/ikuto0608/naivechain

ここ1年ちょっとを振り返ってみる

Tue, 22 Aug 2017 22:36:00 +0000

カナダはバンクーバーに来たのは2015年の終わり、クリスマスの数日後のこと。それからかれこれ1年と8ヶ月が過ぎたことになる。最初の3ヶ月をESLのクラスで勉強、そこから1年間、プログラミングのクラスを受講した。ITDという私立のカレッジに通ったのだけれど、安い授業料のうえ、Co-op付きなので1年間の座学、そしてそのあとに1年間のインターンシップができる。授業の内容は置いといて、総じていいんじゃないかなと思う。それはまぁ仕事が無事決まったので言えることだけれど。

安い授業料といえど相対的な話で大きな金額であることは変わりがなかったり。

この1年間をひとまず振り返ってみるとして、ほとんど毎日授業があり、ただ午前か午後のどちらかだけだったので空いた時間のほとんどは図書館で過ごしていたんじゃないかなと思う。たまにカフェに行って雰囲気を変えて勉強してみたりした。英語の勉強というよりは大部分をプログラミングに時間を費やしていたと思う。英語は今でも本当にまだまだだな感じていてどうしたものかな。。

最初の方はよく英会話のミートアップに参加していた。大抵はカフェで行われてテーブルについてグループではじめましてから話し出す感じ。それから徐々に話すことに慣れて行って今度はIT系のミートアップに参加しはじめた。多くはプログラミングブートキャンプが開催するDemo dayに参加した、そこでは学生たちが作ったアプリを発表する場になっていてなんとピザとビールがお客さんに振舞われるのでよく行ったな。あとはRubyミートアップに定期的に行ってTipsをプレゼンしてくれるので知見を広げられた。

そんな感じで数ヶ月を過ごしたあと、お金がそろそろ怪しくなって来たので何か細かくできる仕事はないかなぁとJPCanadaを眺めていたら公文式から採点要員の募集があったので応募、採用、働きだした。そう、公文式はグローバル展開されていることをそのとき知った。こっちでは算数と英語、それに国語が学べて、日本と変わらないかなと。算数と国語の採点要員として働きだした、算数とか結構忘れていたので問題をちらほら解いてみたり、新鮮だった。国語はこっちにいる日本人の子達が生徒だった。算数は8割ネイティブで2割日本人くらいだったかな。英語で算数を教える、これ大変だった。英語もそうだけどまず高校レベルの数学まで行くとちょっとつまるとこがあって恥ずかしさを感じた。ともして可もなく不可もなく働き続けていたら学校の授業が重なるようになって辞めざるを得なくなった。今ならもう少し上手に教えることが出来かもしれない、気のせいかもしれない。

と、ここまできて座学の期間が終わりに近づいて来たので就活準備に時間を割くようになって来た。やったことといえば主に書いたソースをみてもらえるように単語テストをまるまる作ってGithubに置いた。これが採用に効いたのかは定かでない、聞いてないし聞かれてもいない。多分みられてすらないのかな。それはないかな。レジュメを用意してポートフォリオを用意して、最初に作ったポートフォリオをエージェントに見せたらなんかねぇぇって感じだったので自分のGithub.ioのaboutページをポートフォリオとした。

実際に企業にアプローチをかけはじめたのが確か2017年の2月ころ、レジュメを送ったのは20社程度、電話面接をしたのが1社、実際に面接したのは今働いているところだけ。運がよかったの一言に尽きる。

それで3月の半ばから働きだして、3月はまだ授業があったので半分仕事半分学校という暮らしをして晴れて4月からフルタイムで働いて今に至る。まだ幸い首にはなっていない。仕事はバックエンドをRailsで書いている。まだまだ小さいチームなので開発フローとかミーティングの仕方とか探り探り、やっていっている。自社製品を作る系の会社である。卓球台がある。一日に最低は一回はマネージャーと対戦する。キッチンがある。アボガドとバナナが常時ある。プロテインバーもある。コーヒーメーカーもある。居心地がいい。日本で正社員で働いた会社と比べると、うん、居心地がいい。そうそう、金曜日は冷蔵庫にビールが補充され、3時くらいから飲み始める。居心地がいい。

ざっとこれでここ1年とちょっとを振り返れたのかなと。

順調に事は進んでいるのではないかなと、日々の行いがよかったからということにさせていただいて、不満とかないわけではないけれどうちにも外にも。身にしみてわかったことと言えば、1年とちょっとで問題なく英語が話せるようにはならないということ。それでも机に向かって勉強と意識もなかなか働かない。いやそれでもしなきゃなと。

働きはじめてまだ5ヶ月、やりがいもあるのでもうちょっと英語がスムーズに話せるともっとこうなんかうまくと行くよなぁ、という思いで毎日を過ごしていると。会社のソフトボールチームに参加しはじめたのでもっと人との距離を縮めてみようと思う。

来年度に向けてワーホリの申請も進めている、とは言えまだ今年も半分以上残っていて来年の事までどうなっているのかは謎です。バンクーバーの夏は暑すぎなく過ごしやすくていいけれど、冬がね、長いしほぼ雨だしと。そろそろ京都も恋しくなって来ているし、どこかで日本に帰れればなと。

ぐだぐだと日々がただ過ぎていかないようにやりたい事&やらなきゃいけない事をこんな感じに、

アメリカを車で横断する
Docker, Terraform, AWSに触れる
旅行+SNSでアプリ作る
スイミングに通う+村上春樹の英語オーディオを聴きながら(英語の向上)

まとめて、さぁ頑張りましょう！

How I met Kyoto, part 2

Mon, 12 Jun 2017 22:16:00 +0000

Tarocafe is my favourite youth hostel in Kyoto. I met a lot of people who were interesting in there.

First time I went there, it was when I was a university student. I finished the term of second grade at the time. I took exams and that were really bad scores then I almost couldn’t upgrade my grade by the way. The trip was for forgetting about my university.haha

There was a so mysterious man who stayed Tarocafe alone for long time, few weeks already. He said his job is film directer in U.S, he is Japanese. He took long off, then he came back to Japan. I was curious about his background so much. He seemed not go around for sightseeing in Kyoto and he was also looking for soccer game in Europe to watch in there. I totally can not understand him, so I was attract in him.

One of the stuff in Tarocafe was an art student. She is a painter. I remember she believe that ghost is actually soul. But I don’t remember why we reached to talk about that. Anyway, I had the opportunity to see her paints at her atelier. The owner of Tarocafe had another building for his bar and third floor of the building was her atelier. We went up the stairwell to her atelier. Those paints were so unique, I don’t remember much but my taste is like Man Ray’s art. I feel like same taste with her art.

I still clearly remember the owner who runs Tarocafe, named Taro-san and another girl who stayed there and I went rotated sushi shop for lunch when I stayed Tarocafe first time. Taro-san taught us, coke is the best drink after you eat sushi. Since I heard the story I follow the way and yeah, that’s matched with sushi for sure. I currently lives in Vancouver, Canada. I cannot go to the rotated sushi shop. But fortunately there are a lot of sushi place in Vancouver and some of them are really delicious but still I so miss rotated sushi shop. There is no rotated one here.

I wanna introduce cafes where You should go in Kyoto.

Sun, 11 Jun 2017 16:32:00 +0000

Since I went to Kyoto when I was a university student, I often went back Kyoto. I always used Tarocafe to stay. But I’m not like that person who likes sightseeing temples and shrines so that Kyoto even has a lot of those beautiful places, I didn’t go there after I’ve gone Kyoto first or second time.

Why I go to Kyoto is I like people who I met, but not only that also there are many interesting places for me, for example cafes, Kyoto also has developing cafe culture, called “Kissa Bunka”. So a lot of cafe are in Kyoto. I’ve gone to there to go around cafes. I’m wanna show you my favourites cafes here. You already might know them because those are famous cafes I believe!

Moan - 茂庵

This cafe is on the mountain called “Mt. Yoshida (吉田山)” near Kyoto university, so you should climb to go there but don’t worry, it’s really tiny mountain you’ll think it’s not mountain but hill.

The building is a very old Japanese style house. And it has quite a beautiful viewing. It’s a nice place to hike and take a rest.

Elephant Factory Coffee

I often go to this cafe, called Elephant Factory Coffee. I like this coffee, it tastes better. Funny thing is it’s hard to go there first time because there is it at the innermost place on the load and second floor of the building.

So I feel here is my secret place, but actually this cafe is so popular and many people there.

And it’s at centre of Kyoto, near Kiyamachi st(木屋町通). You can use here to wait your friends, or spend your time till having dinner.

It was in the cafe but ohhh I didn’t drink coffee.lol

Chieria

This cafe is so homely place, you can stay with “Kotatsu” in winter which is a traditional Japanese table with an electric heater underneath and cozzy blanket. And nice to have lunch, it has healthy and asian taste lunch.

Mizuiro club - みず色クラブ

This is the coolest secret neon cafe. You never get there by chance. It’s in residential area of north and east side from centre Kyoto. It’s actually cafe-bar so you’ll have fun both of time.

There are more interesting cafes in Kyoto, and let me know if you have your favourite one!