【暗号通貨読書会#5】複数のブロックチェーンを連携させる仕組み に行ってきた
昨日行われたホワイトペーパーの読書会に参加してきました。
実際に読んだホワイトペーパーはこちら
https://blockstream.com/sidechains.pdf
読書会となっていますが、人数も多かったせいか、中村さん（今回講演してくれた方）がホワイトペーパーを画面に写しつつ、要約してくれるという、若干講義形式となっていました。
ホワイトペーパー上では
を導入として紹介した後
を紹介している論文となります。
sidechainが実現されると、altchain(bitcoinとは異なる技術のブロックチェーン)の開発コストが削減され、より技術が進んでいくでしょうという内容でした。
ただ、参加者の中からも話がありましたが、この論文だとまだ妄想の世界を書いてるにすぎないという印象です。 contest period(sidechainからbitcoinに戻すときに、validationにかける時間)をそれなりに長くするというのは、非常にアナログな考えで脆弱なイメージでした。 その中で、今回たまたまBlockStream社の方も参加されており、最新のsidechainの説明もしてくださいました。
- 来年にOSSが公開される
- 日本語のドキュメントも作成されるはず
- 実際に導入している企業も出てきている
ということで、来年からより活発化されるんじゃないかなとおもいました。
DigitalGarageの告知
最後にDigitalGarageさんから告知があったのですが、来年の2月にbitcoinのコントリビューターを日本にも増やすという目的で、 参加費据え置きで3日のエンジニア向け技術ハンズオンを行うらしいです。 まだ講演者に声をかけている状態とのことで、詳細がリリースされたら見てみようと思います。
golang.tokyo #2 に行ってきた
最近golang熱いな‐と思っていたところ、このようなイベントを発見。申し込みしようとしたときには101人目で人数オーバーしてた、大変人気のイベントでした。 見事抽選に当たったので、行ってきました。 本日の講演は @deeeetさんと@Songmuさんで、ふたりともみんなのGoを書いた方だったので、だいぶ推された感じありましたｗ でもだいぶ実践的な内容なのでおすすめです！
テストし易いGoコードのデザイン
まずは@deeeetさんの発表。
全部みてみたい。。https://t.co/6sxXZj1pMj の発表準備しててとにかく良い例を出すのが大切だと思ってやってたら1000行近くコードを書いていた
— Taichi Nakashima (@deeeet) December 11, 2016
兎に角いろんなパターンのテストしづらいケースを紹介し、それを防ぐ方法を紹介していました。 interfaceを定義し、抽象化することでDIを実現するというのが、主な感じですかね。 TableDrivenのアプローチと所謂副作用的なところは、mainに固めようというアプローチはなるべく心がけてみようと思いました。
MakerelでのGoの話
@Songmuさんの発表。
OSSの公開の理由が"公開しない理由がないから"というのは、男気あっていいなと思いました。 OSSとして公開するときにだれがメンテするのかという話において、持ち回りで当番をきめているという話でしたが、うまく行っていないとのこと。 まぁそもそも持ち回りで当番できるくらいみんなレベル高いんだろうなぁと。 CIまわりだったり、テスト関連で細かいTipsが聞けて面白かったです。
交流会
はてなさんスポンサーでピザとお酒が支給されました！ありがとうございます！ ピザは食べられませんでしたが、直前に重めのハンバーガー食べてたので満足です。
LT大会
Plain db import with Go
@timakinさん
speakerdeck.com gopliというOSSの紹介。 seedデータの注入は確かに開発段階で問題になるなぁと思いつつ、 個人情報まわりをちゃんと隠蔽しながらその辺だけFakeデータを引っ張ってこれると非常に面白いツールになりそうだなぁとおもいました。 DBのコネクション数とかパケット数の上限とか色々気にしないといけないんですね。
Go で始める JSON-RPC 入門
@osamingoさん
speakerdeck.com JSON RPCのツール他にイケてるの無いので作ったよっていう話。 JSONRPC自体は使っている技術が枯れているので、非常に敷居は低い感じしますが、そのJSON自体のバリデーションとかってどうやってるのかなぁと気になりますね。 osamingoさんも最後に言ってましたが、gRPCとかでちゃんと対応して行くというのが今後流行っていくんじゃないかなぁと個人的には感じています。
Continuation Deploymentの話
東郷さん
deliveryではなく、deploymentもやっちゃうという話。 dockerで本番運用しているとのことですが、まだちゃんと運用してうまくいっているという話を聞いたことがあんまり無いので、 非常にきになります。 Travis CIのdockerコンテナがubuntuだけど、作ったサービスはAlpine Linuxというところで環境依存が発生してしまったと言う話がありましたが、 Travisってwerckerみたいにコンテナ立ち上げるの前提っていうわけじゃないんですかね。Docker on Dockerをしたという話ですが、previleged = trueって安全性どうなんだろうってきになりました。
まとめ
今回2回目のgolang関連の勉強会に出席しましたが、言語縛りの発表は中身が濃くて面白いですね。 今後も時間が合えば参加したいと思います。
BuildersConに行ってきた
BuildersCon
BuildersConに行ってきました。
WindowsでGo
- mattnさん
- Windowsは開発に向いているか。
- 問題が起こっていたこと
- そこでGo
- 内部エンコードutf8
- ソケット初期化不要
- 洗練された標準ライブラリ
- deferはwindowsに優しい
- ハンドルを握っているとフォルダ削除出来ない→遅延処理で安全colse
- filepathの勝手な変換(/ だったり \ だったりする)
- ￥でのエスケープを回避できる
- マルチバイト問題は発生しづらい
- netパッケージでソケットのread/ writeができる
- Goではutf8で固めてしまったほうがいい(パッケージも一応あるけど)
標準パッケージでできないことは‥？
→ mattnパッチでかいけつできるよ！
- 標準入力かどうかのチェック
- go-isatty
- エスケープシーケンスで色
- go-colorable
- ログをローテーションしたい
- go-sizewriter
- ログファイルを移動できる
- Access/MDB
- go-adoab
- sixel
- go-sixel
- 端末上に画像が表示できる
- motion jpegで動画再生？
- go-mjpeg
Go優秀でmattnの存在異議‥
まとめ
windowsみんな避けがちだけど、golangで開発していきましょう
質問
- 開発におすすめのPC？
- dell uxp
- surface4
動け！Golang 〜圧倒的IoTツール開発へようこそ〜
- kazuphさん
- AkerunCTOやっている
IoTに必要なもの 開発の生産管理。工場の話をする。
- 工場で動くIoT
工場でやっていること
- 工程管理
- ファームウェアのID
- 作業の成功・失敗の把握
- 基盤や筐体に張るシールの発行
- 検査
- 基盤
- 部品
- 組み立て後
- 上記のうち
- IDの埋め込みを自動化した
- 検査も自動化した
最新のバージョンでは RasberryPI + Golang + Shell iPod + swift
- 書き込み
- 基盤、部品検査
- 優先シリアル通信等で各センサーの値を取得、基準値との判定
- 出荷モードor 出荷用ファームウェアを書き込み
- WebAPIで書き込み
- Slack通知
- 製品検査
- 部品筐体組み込み
- iPodで検査
それぞれのバージョン毎にやったこと
Ver1.0
忙しい時期だったので一日ガッツリ作った
Ver1.1 表側はmacだったが、裏側の検査はRubyを使いまわし
Ver2.0
ほとんどGolang
- 工程管理システム
- ラベル作成
- バージョンアップ方法
- 毎日ソースの更新チェックでautomaterを使っていた
- RasberryPIはsystemdを使っていた
- BLEは特性的にGolangは楽
- ごルーチンとチャンネルでシリアルでかける
- ほかはコールバック地獄回避のためRxXXを使う必要あり
- つづきはAkerunのAdventCalendarで！
Automatic Smile Camera を作った話 - 親バカハックノススメ -
Nodejs関連の事をいつもやっている
@yosuke_furukawa
赤ちゃんが笑ったら写真をとるアプリ IntelEdisonとwebcamを使った
問題
質問
直接GoogleVisionAPIに送らないのは？ 一日2000回までしかAPI無料じゃないから
人口知能でコードを有機化する
プログラムの人工知能化 ゲームのAIの作り方を紹介し、人工知能を創る方法を紹介する
- ゲームの人工知能の作り方
- 昔はScriptedAI、何かが発火したら何かするということをコードに埋め込む
- 最近はキャラクターそのものが知能を持つ
- 知識データと思考を準備する必要がある
- 最小の知能の単位
- 知識と思考のペア
- 一つの問題に対してペアを持つのがセオリ
- 中身を複雑にするには、ペアを維持しつつ階層をほっていく
意思決定
- ルールベースの意思決定
- if分にプライオリティをきめてどれを選ぶかを判断する
- ユーティリティーベースの意思決定
- 人格モデル(お腹すいたとか)が変動し、それぞれのパラメータによって重み付けをする
- それぞれのモデルに対して、重み付け関数がことなり、全てをかけ合わせた物が最大になるように調整する
制御
- サブサンプションアーキテクチャ
- 上の階層の処理は下の階層の処理を制御できる
- ルンバが掃除をしないパターンの実装(障害物がある< 電池が無い)
- エージェント・アーキテクチャ
- 循環的に情報が流れる。
- 世界/データ群→センサー→知能→エフェクター→世界/データ群→...
知識の部分
- ゲームのデータ
- 描画データ
- 衝突モデル
- 知識表現データ
- AIは世界を直接理解できないので、知識表現と言われるものでフィルターする必要がある(世界のパラメータ化。食べる事ができるものだという定義みたいなもの)
- 人工知能の大半は知識表現の準備となると言っても過言ではない
思考の部分
- ゲームで使われる例として、任意の場所までの最短移動経路検索
- A*法を使う。
- 長い距離の場合は、大きいクラスタで判定した後、自分の周辺のみ詳細で探索するということを行う
- 最近だと、対象となる点も自分で作成する
- 自分が動けないところは排除していって、点を絞った後、探索する
ゲームAIの歴史
- ゲームではAIの処理を分離し始めた
- メタAI
- ゲームに埋め込まれたAI
- プレイヤーの腕によってゲームレベルを調整するなど
- ゲームを面白くするために、敵の出現場所などを調整する
- キャラクターAI
- ナビゲーションAI
- メタAI
- 意思決定モデル
- ルールベース
- ステートベース
- ビヘイビアベース(よく使われる)
- 今できる行動のうち一番プライオリティの高いものを選ぶ
- 行動は階層化されているバトル→攻撃→剣を振る
- ゴールベース
- 最後に得たい結果から逆算して行動プールから検索してチェインさせる
- タスクベース
- 順序ありなしで作成
- すべてをつなげるとタスクネットワークができる。
- ユーティリティベース
- シミュレーションベース
- 実際に動的に動かしながら最適な物を見つけ出す
- 基本的にはコンポジットパターンになっている
- 思考に関してはリアルタイムで作成する流れになっている
まとめ
- AIの時代の流れ
- ScriptedAI
- 開発者がAIをコードで書く
- 自立型AI
- 知識と思考に分割する
- 生成的AI
- 上記の思考を自動で作成する
- ScriptedAI
質問
- ゲームで教科学習は使われるか？
- 基本的にゲームバランスがアンコントローラブルになるので使われない。
- ただしQAの人工知能化はできる。
Highly available and scalable Kubernetes on AWS
Kubernetesいいよ！っていう話とそれをAWSで運用するためのフレームワークの紹介
Kubernetesとは
- Kubernetesはコンテナ化されたアプリの自動化をしてくれる
- いろんなパターンのアプリがある
- long running / one shot
- stateful/ stateless
- 理想的な状態になるようなAPIを提供し、収束させる
- Kubernetesの特徴
- Kubernetes Models
なぜKubernetes AWS?
Kubernetesはどこでも動かせるから IaaSで動かすと作ろうとしているSaaSをPaaS作れば作れるようになるから
アプリの作成に集中したいから
Availability
今まではPodとNodeを管理しなければならなかった
- Podは2つ以上冗長化すればいい
- ReplicaSets
- Nodes
- AutoScaling Group
Scalability
- Pods
- Horizontal Pod Autoscalr
- kube-sqs-autoscaler メッセージキューの数でスケール数を決める
- Nodes
- cluster-autoscaler pendingのコンテナ(リソースが足りない)が多いときにノードを増やす
- AutoScaling 予めノードを増やしておく
kube-aws?
使い方
controller:最低2台 Kubernetsの操作 worker:最低2台 実際のアプリ etcd:最低3台 KVS
コントリビュート
go, glice, makeがあればインストールできる
E2Eテスト: Confirmance test 1テスト1時間かかるけど、実行するのはメンテナ
CSSを破綻させない
@kubosho GoodPatch
詳細度管理
- sass使って、下に向かうほど詳細になるようにする
- セレクターを書きすぎないようにする
ルールセットの分割粒度
色々あるので、チームではなしてどれか決める
- Flocss
- foundation
- layout
- object
- SMACSS
- base - reset.css
- layout - header footer
- module - button form
- state
- theme
- ECSS
- 各コンポネント(ページ)毎にスタイルを定義
命名規則
チーム内で決める
- MindBEMding
- .block__element--modifier
- .article__header
- .breadcrumbs__item--current
- .block__element--modifier
- ECSS
- .nsp-Component_ChildNode
- .top-Article_Header
- .bc-ItemCurrent
- .nsp-Component_ChildNode
- SMACSS
- base: body, a ...
- layout: layout-?, l-?
- module: item-?, form-?
- state: is-?
- theme: theme-?
同じ見た目
a要素でbutton要素と同じ見た目にしたいときとか
- ブラウザの規定のプロパティを把握する
- Bootstrapの指定を見てみる
- そのルールセットがどういうHtml要素で使われるか予想する
一番大事なこと
デザイナーとの認識合わせ
CSSの解析ツール
- 状態
- 詳細度の可視化
まとめ
- 設計方針決めよう
- チームで話し合おう
- ツールを使って解析しよう
Docker Swarm Mode
@ssig33
結論
- 今すぐDockerベースでHA環境を作らなければならない
- use Kubernetes
- ベンチャー企業でインフラのコストを低減させたい
- デプロイが趣味の人
- DockerSwarmModeを使う
- それ以外の人
- DockerSwarmModeにのんびり注目。すべてが変わる可能性がある
Kubernetesより優れているところ
- やりやすい。
- ノードの数は最初しか指定できない
- サービスがポートを公開すると、クラスタ全部ポート公開してくれる(はず)
問題点
- 負荷分散がうまく動いていない
- 前段にロードバランサー
- たまにノードが行方不明になる
- 死活監視入れとく
- 単発実行のタスクのデプロイが困難
- ジョブスケジューラもない
- Mysql置き場が難しい
- ファイルの永続化が困難
- glusterfsでパフォーマンスあんまり重視しないならOK
- ログ管理無い
- logspoutで実行している
- いろいろundocument
世の中の困り事はだいたいGoのコード自動生成で解決する
- コード生成は人間が書くコードをコンパクトにする
- 他のエコシステムと接続する SQL → go struct
- IDL
- Swagger
- Protocol Buffer
- sqlla
- コード生成に必要なもの
- コード生成のもととなるソース
- ソースのパーサー
- コード生成された後のExample
- sqllaではgo/parserを使っている
- text/templateを使う
早すぎて書ききれませんでした‥
個人的感想
エンジニアのためのマインドフルネスに参加してきた
最近イライラすることがあり、ここ数年で一番激昂してしまったので、これは自分の精神をコントロール出来ていないのだろうということで、Googleとかで採用されている「マインドフルネス」の本を買ったりして勉強していた。
ただ、自分でやるだけだと、どうしてもやり方がわからなかったので、実際に体験する形で習得したいなぁと思っていたところ、下記のイベントがあったので、行ってきた。
このイベントでは、ヨガの先生が講師となり
- マインドフルネスの実践
- マインドフルネスについての簡単な紹介
- マインドフルネス×ヨガの紹介
を体験。
マインドフルネスの実践
まずは体をリラックスさせるために準備運動。椅子に座った状態で肩のチカラを抜き、重力で腕が下がるようなイメージで座る。骨盤は立てて、背筋を伸ばす。ここでは椅子には寄りかからない。
こんな感じ
数十秒たったら、おろした腕を横からゆっくりと上に上げていき一番上で伸びをする感じで静止。一呼吸置いて腕を下げる。これを３回程度行う。
そうすると、予想以上にリラックスするので、自分が落ち着く体勢（マインドフルネスの本だと「隙きの無い状態」）で座る。
このときに意識することは自分の体に起こっていることに注意を向ける事。ただ、今まで無意識だったものに対して意識を向けるのは難しいので、自分の呼吸がどういうふうに流れているのか、吐く時間と吸う時間はどちらのほうが長いのか等注意を向ける対象を自分で意識するとやりやすいそう。
大体5〜10分程度行い、終了。難しいが慣れてくると普通にできるようになるらしい。
マインドフルネスの簡単な紹介
そもそもストレスって何ってところから、現代人におけるストレス回避の重要性、またその取組のなかで最近大手企業にも導入されているマインドフルネスの紹介をしていただいた。
youtu.be 講師の方いわくこれが非常に的確に表現しているとのこと。
今まではライオン等生命的危機に対応するためにストレス反応によって身を守っていたけれども、現代はそういう必要はなく、どちらかというと仕事や満員電車等恒常的なストレスが発生するため、ストレスから開放されるということが少なくなってきたのが大きな違いらしい。
その中でもマインドワンダリングと呼ばれる、過去や未来に対して不安におもったり考え事することが50％の割合を占めているので、今にフォーカスする時間を設けて今を感じようというのがマインドフルネスの取り組み
上記の図で言うと、左の人間はマインドワンダリングしている状態(mind full)で、右の犬は今のあるがままを認知している状態(mindful)。
よく言われるのが100分の基準というもので、合計時間が100分を超えたあたりから体に良い反応が生まれてくるとのこと。なので5分だと4週間、10分だと10日続けましょうとのこと。
マインドフルネス×ヨガの紹介
マインドフルネスは今にフォーカスを当てるということで、上記に述べたように難しいのでヨガのやっている事にマインドフルネスを取り入れるといいんじゃないかと提唱しているのが今回の先生。
内容書こうかと思ったけど、いろんなヨガをやったので覚えてませんｗ気になる方はヨガの先生に連絡とってみてくださいｗ
基本的に意識するところとしては、例えばストレッチしているときは体の伸びているところに呼吸を送り込むイメージでストレッチするというものらしい。
とまぁ色々書いてみたけど、やっぱり習慣化して実践していかないと効果ないなぁと実感したので、今後もやっていきたい。
イベント自体は非常に有意義で楽しかったです。ありがとうございました。
LeetCode始めてみました。
きっかけ
情報科学若手の会でLeetCodeをつかって就活したよーと言う話があったのですが、いまいちピンと来なかったので、試しにやってみたのが始まり。
なにそｒ
LeetCode OJ is a platform for preparing technical coding interviews. ということで、面接に使えるコーディングのプラットフォームというのが立ち位置らしいです。
専ら僕は海外での就職の予定は今のところ無いので、(もうちょい英語力‥)新しい言語とかに慣れるためにちょくちょく使っています。
通常問題としては
- Algorithm
- Database
- Shell
- Draft
というのがあり、基本的に新しい言語に触れるという目的から一番上のAlgorithmをやっています。
たまにコンテストがあったり、有料会員だとinterviewも出来たりするようです。(まだやってない)
どんな問題が出るの？
ま、これ見ろって感じですが、難易度が設定されていたり、回答するとこんな感じで実行スピードとその順位が出てきます。
面白い？
単純に問題を解くだけではなく、実行速度という概念が入ってくるので、言語仕様とか言語特有の書き方とかを意識するようになる(はず)なので、学習コンテンツとしては非常に面白いと思います。言語覚えるのは本読むだけじゃなく実際にコーディングして何か作った方が早いですからね。
今後
回答したらちょくちょくgithubにでもpushしていこうかと。
HTTP/2速習会に行ってきた
HTTP/2速習会
Wantedlyにて行われたHTTP/2の速習会に行ってきました。
HTTP1.1の問題
- ブロッキングが辛い
解決策
- ブラウザから6並列リクエスト
- TCPコネクションを増やす
- 7個以降はblock
- socketの浪費につながる
- HTTPパイプライン
- レスポンスを待たずにrequestを送る
- ただし、先に送ったrequestに対してresponseを返さないといけない
- HTTPrequest数を減らすためのハック
HTTP/2
多重化
- 一つのTCPコネクションで、複数のrequest/responseができるようになった
- ストリームを使って実現している
- 1request 1responseに対して1ストリーム
- データ送信はバイナリのフレーム単位
- フレームがごちゃごちゃで送られる
- どのフレームがどのストリームに属しているかを管理している
- フレームをデコードすると1.1と変わらない
ヘッダ圧縮
- HPACKで圧縮
- Huffman符号化
- 頻出ヘッダーは共有
- 送信ずみデータを再利用
- RFC7541参照
優先度制御
- 多重化されたresponseを優先度に応じて返す
- 重み付け(他の何倍の割合で送信)を依存関係
- HTML > CSS, JS > 画像
- ブラウザが指定する
サーバープッシュ
- 複数のレスポンスを返せる
- CSS,JS等どうせ必要なものはrequest来る前に先に送ってしまう
H2Oを動かしてみる
$ git clone https://github.com/south37/http2-sokusyukai $ cd http2-sokusyukai $ docker run -p "8080:80" -ti south37/h2o-http2-demo-server
そのた詳しくは‥ https://github.com/south37/http2-sokusyukai
多重化で優先度を明示的に付ける場合は
http2-reprioritize-blocking-assets: ON
という設定を行う https://github.com/south37/http2-sokusyukai/blob/master/2_multiplexing/h2o/h2o.conf
サーバープッシュ
ref=preloadというAttributeがimgタグにあれば勝手にやってくれる
response header に link:</images/photo180.jpg>; rel=preloadが出て来る
アプリケーションを書く人がいじるところ
http2-casper: ON
クライアントがすでにキャッシュしているものを送らない
キャッシュ情報はCookieで管理している
まとめ
- HTTPのセマンティックはかえずに多重化などを解決
- H2Oや最新のnginxであれば対応している
- インストールが簡単 https://h2o.examp1e.net/install.html brewとかyumとかdocker imageとか
