"血をもって書け。そうすればあなたは、血が精神だということを経験するだろう。"

北極海航路の話

先週、面白そうなセミナーを教えてもらったので聞いてきた。

概要

温暖化で北極の氷が溶けて新しい航路(NSR,Northern Sea Route)が開けるので活用できないか、というテーマで各方面の議論がなされている。 ゴルバチョフNSR開放以降、船舶種類(アイスクラス)に関するロシアの規制緩和もあり、活用が増す見込みである。 トランジット(横断輸送)が主だが、クルーズや研究船の需要もある。

これだけ書くと温暖化で喜ぶ人たち、という印象になってしまい批判もある。 フェアになるように書くと、NSRの活用で燃料資源の消費が減り、資源輸送のための陸上パイプラインの開発に比べても環境影響が小さいとのこと。

インド洋航路が海賊問題をかかえる一方、NSRの優位性は(燃料価格の影響もさることながら)ロシア情勢に大きく依存し、短期的には逆風もある。

日本の立場

日本は地政学的にNSR発展の影響を受けやすく、また実は北極海探査の歴史もある。 内閣も日本初の北極政策を発表したばかりである。

覇権史における北極海の意味づけについてはより専門的な記事*1に譲るとして、かなり多岐にわたるトピックがあったので、実際の航行に際してどういう問題を解く必要があるのかを外野からどうにかこうにかサマリする。 資料もそのうち出揃うはず。 (誤った理解があればごめんなさい)

氷況観測

氷海船舶には耐氷船と、海氷を排除・砕氷して耐氷船をエスコートする砕氷船がある。 氷が減ると、NSRが開けたぶん航行船舶は増えるので、トータルでの航行リスクは上がる*2。 ということでまず氷をどうにかする、とくに現在の氷の分布を把握し予測する技術の発展が望まれる。 氷の量(海氷密接度)のほか厚さや種類は重要な情報で、既存ではさまざまな測定方法がある。

  • 目視
  • 漂流ブイ
  • 海氷船舶の横にセンサーを吊るして航行しながら測定
  • マイクロ波放射を衛星(AMSR)で捕捉

氷況予測

様々なデータから、大きく3つのスパンで今後の氷況を予測する。

短期

航海中船舶の航路決定に必要な、2日間程度の天気予報情報。

予測のメッシュを数km程度の解像度にすることでアイス・アルベド・フィードバックや中規模の渦構造の再現精度が上がる。 氷海流出油のハザードマップを作るというような応用もある。

サービス界隈で身近なところだと、ウェザーニューズ社が既にこの領域に入っていて、NSR航海の実体験の報告が行われた。 北西ロシアのムルマンスクから天津まで23日程度の航行。 現場では他船からの電話連絡を受けてから1時間(!)程度で結氷する。 運がよいとオーロラが見えたりホッキョクグマを観察できたりもする。

中期

配船計画に必要な航行可能時期の予測を4月頃に出す。年間では9月中旬が最も氷が少なくなる。 航路が開けるかどうかは氷面積だけでなく氷の厚さにもよる。 氷の厚さの直接観測はまだ精度が十分でないので、冬の氷の移動状況から氷の厚さを推定する。 ずっと存在する氷よりも、氷が移動してできた隙間にできたばかりの氷はまだ薄くて夏に溶けやすいはず、ということである。 Sea Ice Outlookという予測発表があって日本の研究チームは好成績を出している。

長期

30-50年程度のスパンの投資・造船計画に影響する情報の分析を行う。 氷況に加え、ヤマル地域のLNG*3など沿岸の経済活動との相互影響もありそうだ。

着氷

航行中に上げたしぶきが船体に着氷してしまう(昔は着氷の重みによる転覆もあったらしい)。 酸化チタンのような塗料での予防は現在難しい。 着氷傾向は気象・氷況からの経験式があるものの、船体形状や航行速度にも依存する。 着氷の成分や構造、着氷過程を知ったりそれを排除する必要がある。 観測には飛砂や吹雪の粒子観測機器を転用したりする。 船体形状から気流の観測を行う必要もあるが、CADデータが公開されていることは少ない。 最近は複数角の写真からモデリングが行えるのでそれで十分なことも多い。

波浪

海氷のダイナミクスにおいては波浪も重要である。 氷海では分散関係や風との相互作用が通常の海洋と異なり波浪の物理も変わる。 また氷海と通常の海洋の境界は年次、年間で大きく変わるという点も従来の波浪学にない側面である。 既存モデルに対して、スペクトル領域と時間領域をつなぎ、さらに数値計算に適した新しい物理モデルが模索されている。

その他の気象学・気候学的情報

海氷予測だけでなく中緯度帯の気象とも密接にリンクしているという意味で、極地の気象観測の重要度が増しており、諸プロジェクトも稼働している*4。 例えば極低気圧は発生・消滅サイクルが24hと短く、既存の時空間解像度では捉えきれない。 着船する港では潮位の情報を必要とするが、これに関しては北極海は衛星がカバーしない海域で、まだ予測誤差(潮位・ピーク時間)が大きい。

氷中航行

相手は氷なので衝突の衝撃や曲げによる荷重は馬鹿にできない。 衝突時のエネルギー変換から船舶にかかる荷重を求める経験モデルで計算したり、氷に見立てたプラスチック片と船舶模型の衝突実験を行ったりする。

砕氷船のエスコートのオペレーションも複雑で、

  • 迅速に砕氷しないと航路が渋滞してしまう。
  • 耐氷船のサイズに合わせて砕氷船を並進させる場合もある。
  • 状況によっては海氷中で砕氷しながら旋回したりバックしたりもする。

海氷を排除するか砕氷するかの判断は船と氷のサイズ比較で経験的に行う。 一方耐氷船は耐氷船で、砕氷船による排除の後に流れてくる氷を手動操縦で避けて通らないといけない。

航路選択

船舶が目標とすべきマイルストーンのネットワークとして氷海をモデリングしたり、ダイクストラ法やA*アルゴリズムで航路を決定する。 海氷分布の実データは船舶搭載のレーダの画像解析により動的更新される。 航行速度のデータは海運会社から公開されていないが、氷況記録や航行実績から推定する。実際の航行時間には砕氷船のエスコート待ちも含まれるのでより複雑である。 また極を通る航路が選択される時もあるが、沿岸から離れすぎるのはそれはそれでリスクなので何かしらの調整を入れる*5。 最適航路や航行時間の変化の長期予測も視野に入る。

感想

情報学や工学に似て、寄ってたかって集められた様々な知見を垣間見た一方、環境影響や生態学、安全保障のような海洋の周辺の各論が網羅されているわけではなさそうで、現段階の予算的にはエネルギー開発と海運がなんとしても重要という印象を受けた。

全く個人的だが北極海と聞いてふと思い出すのは、あるとき見たロシア映画 How I Ended This Summer だ。 孤立した極北の気象観測所で働く老人とインターンの青年の、致命的にこじれていく(それも放射性物質の周りでくるくると)関係を描くこの一作は、観ていていかにも心が寒々としてくるのだが、半世紀後のテクノロジーに囲まれた北極海の風景はまたがらりと変わっているのだろうか。

#Deeplearning4J のMeetupを手伝った話

先週になるが、ディープラーニングのフレームワークDeeplearning4Jの開発メンバーが来日されていたのでMeetupを手伝っていた。 YAPC::Asia(手伝ってないけど)に続き、合宿のような濃い一週間だった。

もちろん事前の準備もいろいろあったが、連日会社が終わってから馳せ参じたので疲れが意外にたまっていたらしく、終わった翌日は結構寝てしまった。結局昼から飲んでたけど。

こういう縁は(自分が好きなのもあるが)たまにあって、6年前にMarrisa Mayer氏がGoogleの新卒を連れて京大に来たのでゲリラ的なツアーを組ませてもらったときもお手伝いできて楽しかった。今回は自分でも実際にフレームワークScala,Spark,IntelliJ IDEAついでにAtomに触ったり、処理系やJVM,GCにも興味が出るきっかけになってなおよかった。 一方で、ディープラーニングの全体像は未だに飲み込めていない。分散処理屋さん、人工知能屋さん、脳科学屋さん、と立場によって捉え方が少しずつ違うのも理解しておきたい。

開発コアのAdam氏はO'Reillyからの出版予定がある。

Deep Learning: Dl4j and Beyond

Deep Learning: Dl4j and Beyond

彼はディープラーニングを民主化すると言っている。

ディープラーニングは自分の中ではハードルを設定してしまってつかめていない領域なので、とりあえず手を動かして少しずつでも理解を深めていく原体験は大事だと思う。 気づかぬうちに人が学ぶ妨げとなることがないように、自分も気をつけたい。

yakst.com

ぼくのさんかしたさいしょでさいごのYAPC::Asia Tokyo

YAPC::Asia Tokyo 2015 に参加した。

f:id:satzz:20150824224323j:plain

  • Perlに近い環境にいながら最初で最後の参加になってしまったが、行ってよかった。
  • H2Oやio.js,Electronのトークも是非聞きたかった
  • 941さんはエンジニアだと思っていた
  • 懇親会チケットが必要なことには気づいた頃に完売してて悔やまれた
  • antipopさんの動画のインパク
  • hitode909さんベストトークおめでとうございます!
  • スタッフの皆様、10年間おつかれさまでした!

f:id:satzz:20150824224309j:plain

資料・動画も公開されると思うので、以降はメモ以上のものではありません(不正確な記述があればごめんなさい)

8/20(前夜祭)

『言語開発の現場』

  • @hsbtさん
    • GMO
    • Rubyコミッター
    • 社内でRubyを使っているので、Rubyの問題があるとRubyを直してリリースされるのを待つ
    • ビルド、配布、RubyGems、Rakeのマージ
  • Ruby
  • いろいろな実装 どこまでがRubyなのか問題
  • 開発に関わる人の種類
    • comitter(Ruby Core Team)
    • branch maintainer
    • platform maintainer : 好意でプラットフォームごとのサポートをする
  • 権限
    • 権限をもらったらどこへもcommitできる
    • 一度直すことになったら最後まで自分で直す覚悟
  • github : proprietaryなのでつかわない
  • OSS開発も普通の開発とおなじ
    • write code
    • take care of development resources
    • focus use case
    • release management
  • developer meeting : 英語圏developerとの距離の解消
  • releaseが大変
    • 2hですむはずが4h(?)かかっている
    • 自動化できてない

はてなブックマークのトピックページの裏側』

  • @5kozawaさん
  • はてブにおける過去の試み
  • トピック生成
    • トピック=キーワードの集合
    • ElasticSearch の Significant Terms Aggregation 機能
    • Amazon ElastiCacheのノードが6台
    • JLH score
      • 出現割合を加味したスコアリング
      • 絶対割合変化 x 相対割合変化
    • トピック生成は時間がかかる。2hおきにつくっている
    • 新語が多いので辞書作成が追いつかない
  • トピックタイトル生成
    • 要約技術の一種
    • キーワードを羅列すればよいわけではないので並び替える
    • 一つ一つの記事のタイトルはちゃんとしているので、どれかの記事のタイトルを使えばよい
    • 係り受け関係に基づく文圧縮
    • アプリだと短いタイトルのほうがよい。10文字以内が目標
  • 毎年のYAPC::Asiaのトピックの抽出には成功している

『技術ブログを書くことについて語るときに僕の語ること』

  • @y_uuk1 さん
    • はてな, Mackerel
    • ネットワークの研究室に入ったが、カーネルがやりたくなった
  • ブクマを稼ぐ技術
    • タイトルが9割
    • (笑ってて詳細メモるの忘れた)
  • 哲学
    • 知識と感動 : どちらを伝えたいのか?
    • ブログ=自己表現 : ポートフォリオとして、キャリアとして見直す
    • 寝かせる
      • 調べる、分からない、を3年くらい繰り返すことも(Webサーバーアーキテクチャなど)
      • なぜ我慢できるのか
        • 金曜の夜に投稿してもブクマされないことは経験でわかっている
        • ブクマ数で評価されて特上寿司が食べられる
    • 普段の仕事もアウトプットベースで考えるようになる : どうすれば技術的に面白く見せられるかを考える
    • 神は細部に宿る
    • 時間をかける : かけてはいけないと誰も言ってない
  • QA
    • モチベーション
      • ブクマ数
      • 特定のエンジニアにブクマされるかどうか
      • 会社として書く vs 個人として書く : 自分のブログのほうがモチベーションはあがる
    • 古い記事の修正 : あまりやらない。むしろ新しく書き直すこともある。
    • タイトルしか読まれてなさそうなもの : 傾向まではつかめていないが、内容が丁寧だと読んでもらえる気がする

8/21

『メリークリスマス!』

  • PerlのパパLarry Wall
  • Perl5(Hobbit)とPerl6(Lord of the Ring)は実は同じ物語
  • Perl5
    • Hobbitにおいてはすべてがgreedy
    • 正規表現
    • UNIX文化とうまく融合したことで成功した
    • 多すぎるglobal
  • Perl6
    • 3つの大きな改善
      • NFG(Normal Form Grapheme)
      • NSA(Native Shaped Arrays)
      • GLR(Great List Refactor)
    • type system
    • 正規表現依存を弱める? : ほかの言語は正規表現に移行してきている
    • don't overspecify
    • Supply
    • operators
  • お知らせ : 2015年のクリスマスにはリリース予定(ただしバスにはねられたりしたらどうなるかわからない)

『Effective ES6』

  • @teppeisさん
  • Web+DBのES6はmust buy
  • ES5
    • 落とし穴の例 : newをわすれるとグローバルがかきかえられる
    • ベストプラクティス、どちらかといえばワークアラウンド
  • ES6
    • modern syntax
    • 大規模アプリケーション開発も容易に
    • 後方互換
    • ベストプラクティス・AltJSの一部機能が不要になる
  • ES6はいま使えるのか
    • compat table : IE11は対応しない
    • ES6を始める方法
      • とりあえずBabel : Babel REPLで試せる
      • transpiler
        • ES5の機能だけを使うコードに書き換える
        • Babelならブラウザごとにtranspileをやめるタイミングなどもきめられる
      • polyfill : ES6ビルトインクラスを提供する
      • ESLint
  • new syntax
    • arrow function:Array.filterにかますときべんり
    • (ES5)assign this to selfのreplace (ES6)スコープ外のthisがarrow func内から呼べる
    • (ES5)プロトタイプベース => (ES6)クラス、継承ベース
    • (ES5)グローバル依存のモジュール、commonjs依存(exports,browserify) => (ES6)export, 静的解析しやすくなる
    • use strictが不要になる
    • (ES5)function scopeしかなかった、巻き上げ(hoisting)が発生していた => (ES6)block scopeができた
    • (ES5)var => (ES6)let,construction
    • default parameters
    • rest parameters
    • destructuring(分割代入)
    • template literal
    • Generator
  • new built-in classes
    • Promise : エラー制御改善、非同期の明示
    • (ES5)objectをdictionaryとして使う (ES6)Mapクラス
  • 既存クラス拡張
  • AltJSは不要になるのか
    • CoffeeScriptは、インデントの書き味以外の優位性は残らない?
    • TypeScriptの型をとりいれるかどうかは議論中

TBD

  • Matzさん
    • 言語デザイナー
  • Rubyの反省点
    • Perlの影響 : 特殊変数
    • LISPの影響
      • intのサイズの問題
      • シンボルとストリングの区別
        • Rubyの思想
          • 使い分けを避けたかった
          • RubyにもProcとlambdaの区別
  • アーキテクチャの変化
    • マルチコア
    • スレッドセーフ
      • 人類には早過ぎる
      • immutableをもつ関数型言語が評価されてきた
      • スレッドセーフでない外部のCライブラリから守るためにGILを導入した
  • Rubyの今後
  • Rubyと違う判断
    • 高レベル抽象(DSL)
    • 技術トレンドのバランスは振り子
  • Streem
    • パイプラインベースの言語
      1. パイプラインの組み立て
      2. パイプラインをデータが流れるイベントループ
    • ピタゴラスイッチプログラミング
    • イミュータブルデー
    • エラー処理
      • 明示的チェックC,Go
      • 例外処理 Java,Ruby
      • Optional Swift,OCaml
      • デフォルト無視 Streem
    • より少ないデータ構造(<-> 大クラス主義) : 数値, 文字列,配列(ハッシュ、オブジェクトを含む)
    • OSSの新しい知見
      • 言語をつくる連載(日経)でコンセプトだけのプロトタイプを作ったらHacker Newsのトレンドに上がった
      • mattnさんによるGo実装
    • 応用
      • 実用には遠い : Goのような複雑なチャンネルのネットワークなどは難しい
      • 教育的な効果
      • データ分析
      • シンプルなwebサービス
      • Reactive Programmingっぽいもの
  • まとめ : 言語デザインは楽しい
  • QA
      • 短いスクリプトを書くという理想に反する
      • 「絶対に型を書きたくないでござる」
    • 言語デザインのインスピレーション
      • 既存言語の成功例をとりいれる
      • 既存言語の問題点を改善する
      • 日頃のアイデアを形にする
    • 楽しい瞬間 : 作っている言語でHello Worldが表示された瞬間
    • この業界、コンパイラに対する共感能力高い人が多すぎる

Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜』

  • @hitode909 さん
  • イケてるサービス
    • 役立つ、楽しい、早い、かっこいい、イメージが良い
    • 開発を継続する : 一貫した指針などが必要
  • 社内フレームワーク
    • Ridge, MoCo : 継承前提, 使うために結構読まないといけない
    • 後方互換性のためのモンキーパッチ
  • はてなブログのスクラッチ
    • cho45さん,2011
    • 薄いフレームワーク
    • 読むコードが最小
    • ORM使わない
    • 継承しない
    • 3回コピペするまでは共通化しない(DRY3)
  • Service
    • MVCの間で3回コピペされたコードをServiceのname spaceに移す
    • テーブルと1v1にしない
    • 外からみるとオブジェクトどうしの呼び合いにみえる
    • クラスメソッドで済ませる
    • インスタンス化は最低限におさえる
    • 状態が必要ないものに状態を与えない
  • オブジェクト指向設計入門
    • 契約による設計 : 事前条件、事後条件
    • 責任外のことをチェックしない
    • 設計としてはよいが、言語的な支援がない
  • リファクタリングのためにPerl静的解析
    • YAPC::Asia 2014
    • 特定トークンの置換
  • DDD
    • コアドメインに集中する : ソフトウェアにとってもっとも重要な部分
    • レイヤ化アーキテクチャ
      • エンティティは状態をもつので値オブジェクトに寄せたほうがよい
      • 状態をもたないサービスを独立させる
    • 実践DDD
    • 名前
      • 用語集をつくってgitに突っ込む
      • 企画にもコードを見せるが意外に読める
      • コードは変えられるが、ストレージに変更を行うのは難しい

『PietでLISP処理系を書くのは難しい』

  • @hnagaminさん
    • KMC
  • (Pietでビジュアル化されたソースコードがひたすらでてきて楽しかったがメモるの忘れた)

esa.io - 趣味から育てたWebサービスで生きていく』

  • @fukayatsuさん
  • 大事なこと : いろいろ試して失敗する, 公開する
  • 事業化まで
    • esaの原型はQiita:Teamの試用期間が切れて、開発合宿でできた
    • 開発合宿後も毎日がハッカソン
    • ドッグフーディング
    • 知人の会社でつかってもらった
  • 反省 : チーム申請を待たせすぎた
  • 楽しく開発したい
    • 自分が楽しく開発することで最終的にユーザーに価値を届けられる
    • 楽しさ、モチベーションは複雑で直接コントロールできない
    • 制御可能なものを見極める
  • 開発のリズムをつくる : botに毎日bundle updateをさせてpull reqをつくらせる
  • bugfixを競技感覚でできるだけ速く本番反映する
  • フィードバック駆動開発
    • 5分以内にメール返信
    • 直せるならすぐデプロイする
    • 自分がされて嬉しい事をする
  • リリースノート駆動開発 : 自分自身がユーザー
  • 週7日間プロダクトに触れる
  • ユーザーサポートをやっている人が意思決定してデプロイする
  • スケジュールを決めない。要望が多いものから対応する

8/22

『Mackerel開発におけるScalaとGo、そしてPerl

NASA主催の世界最大級ハッカソンSpaceAppsを運営した話』

  • @yumu19さん
  • 昨今のハッカソンのテーマはいろいろ : 「家」「オフィス」「100円ショップで買えるもの」
  • International Space Apps Challenge : NASA, 世界142都市(日本5都市)同時開催
  • 東京
    • 150名程度の参加
    • DMM.make
    • ワークショップも並列開催 : ハッカソン以外の方法でも宇宙・データ・科学などに親しんでほしい
    • Bostonとのコラボしてるチームも
    • H-IIA寿司
  • これまでの成果
  • 事務局 : 全員ボランティア
  • 準備
    • 重要なのは場所決め : キャパ,WiFi,LAN,利用料,物販可否,夜間利用可否などを考慮
    • 収入はスポンサーと物販のみ
      • 物販売上は不確定 : 入金はイベント当日
      • スポンサー
        • 趣旨に賛同してもらう
        • リターンの提供 広告宣伝
        • 訪問、請求書、スポンサー間のロゴのバランス調整など
    • 無断キャンセル対策
      • DoorKeeper
      • 前払いにする(SpaceAppsはできない)
      • 「無断欠席の場合は今後の参加をお断りします」と明記
    • 本部・各拠点との情報共有
      • タイムゾーンバラバラなので、同じオンラインミーティングを月1で3回やる
      • 運営は各地域に移譲
  • 重要なこと
  • QA
    • 運営で得られるもの : 仲間ができる、居場所ができる、段取り力を養える、達成感を味わえる
    • 苦労したところ : スタッフのうち自分だけ石川に移ったことで遠隔でやるのが意外に大変だった
    • イデアソンをうまくやる方法 : ブレストやる前に1v1でアイデアをブラッシュアップする
    • NASAや宇宙開発への寄与 : テーマが具体化してきたので、NASAの本気度も上がってきたと感じる

『データ分析基盤を支える技術』

  • @repeatedlyさん
    • TreasureData
  • (追い切れなかった・・)
  • Data Analytics Flow: collect, store, process, visualize, report, monitor
  • RDBMS
    • single server
    • popular, huge ecosystem
    • ETL(extract,transform,load)
    • online transaction
  • parallel RDBMS
    • optimized for OLAP workload
    • Netteza,Teradata,Vertica,Greenplum
  • columnar storage
  • compute nodeにstorageがくっついているのでwriteが待たされる
  • distkey, sortkey : 設計ミスるとノード間通信が発生してしまう
  • schema management
  • superstition
    • "SPOF"
    • "cannot build from a scratch"
  • tools
    • ingestion tools : bulk load / streaming load
    • bulk load tools : Embulk, Sqoop
    • streaming load tools : Fluentd, Flume
  • MPP query engines
    • Schema on Read
    • "SQL on Hadoop"
    • Impala
    • Presto
      • backends:Cassandra,MySQL,..
  • Apache Storm : low latency, micro batch
  • Norikra
  • Apache Kafka : distibuted messaging, pull(stream control)
  • Amazon Redshift, Kinesis
  • Google BigQuery, Dataflow
  • Treasure Data (Data Lake)
  • Resouce Model trade-off
    • Fully guaranteed: non boost mechanism
    • Guranteed with multi-tenanted
    • Fully multi-tenanted
  • use service/build a platform
  • Tableau (visualization)

『Parallelism, Concurrency, and Asynchrony in Perl 6』

  • Jonathan Worthington
  • Supply is the dual of seq
  • react : scalaのreactと同じ?違う?

『HTTP2 時代の Web』

  • @Jxck_ さん
  • 国内のHTTP2界隈のプレゼンス
  • HTTP2は策定フェーズから使うフェーズへ
  • webのパフォーマンス
    • 現状
      • コンテンツサイズ 100 reqs, 2MB/page
      • 帯域増加よりレイテンシの削減の効果が大きい
    • アプローチ
      • Round Trip Timeを減らす : 物理的に近づける
      • Round Trip を減らす : アクセスを減らす、キャッシュする
  • HTTP1
    • header : テキストベース、重複が多い(UA)、圧縮不可
    • TCPを毎回確立
      • head of line blocking: 1つ詰まると後続が詰まる
      • ブラウザはドメインごとに6本同時に接続
    • 高速化のためのノウハウがあったがbad hackだった
    • TCPのhackになるとkernel levelで、手を入れられない
  • HTTP2
    • バイナリフレーム : パースしやすい、分割可能
    • GETなどのsemanticsは後方互換
    • HPACK
      • Huffman圧縮
      • 頻出ヘッダを共有
      • 送信済みデータを再利用
      • 圧縮率は実装次第 http2studyでは8割圧縮
    • コンテンツ優先度制御 : 画像よりCSSが先に届く、など
    • head of line blockingの解決 : コネクションを使い切る
    • Server Push
      • JSなどの依存コンテンツをブラウザにキャッシュさせる
      • cache control :実際にはbrowserのcache領域の奪い合い(48hで78%の人が使い切る)
      • Service Worker
        • 実装はまだないが議論中
        • HTTP2 Pushを受け取れる予定
        • フロントエンドのプロキシとしてjsを動かす
      • HTTPがPushのセマンティクスをカバーする
  • 検討事項
    • HTTPS
    • performance
      • そのサービスのボトルネックは本当にHTTPなのか?
      • response timeだけでperformanceを測れる時代は終わった
      • バックエンドの最適化をフロントエンドが台無しにすることがある
      • 数値化しにくい
    • 実装・インフラはどうなのか?
      • ブラウザによる
      • HTTPS終端問題
    • HTTPS対応はどうなのか?
      • 暗号化の機運が高まる
        • NSAのPervasive Surveillance(広域盗聴)問題の告発(スノーデン)
        • 証明書取得の敷居を下げる動き
      • HTTPS化前提とするブラウザ仕様も : HTTPであっても暗号化する、など
    • HTTP1と戦っているのはhyper giantだけなのでは? : hyper giantでなくても複雑なアプリはある
    • 導入の敷居は高いのか? : セマンティックス互換なので入れて抜くことも可能
  • 今後のHTTP2の動き
    • TCPの置換
      • TCPの限界:パケットロスで再送
      • QUIC(over UDP) : 既に使っている可能性もある
    • Nginx 2015末にHTTP2対応予定
    • IETF in Yokohama

徒然 2015/08/09

8/9

  • Simulating Social Complexity 勉強会: Chapter11(Combining Mathematical and Simulation Approaches to Understand the Dynamics of Computer Models)
    • 擬似乱数の代用としての物理乱数(例:ガイガーカウンター)(再現性の理由で採用されないケースも)
    • minority game とdeep learningのどちらが株価のようなパターンを本質的に生成できるか?
    • スパ帝によるゲームAIの強さの話。攻略する余地をのこす。
    • タスマニアにおける文化後退の話。社会がどのようなfinal stateへ移行するかの分水嶺を考えたときに人口がファクターとなるかどうか。
    • circumstance description theory
      • ポリネシアの食生活 タロイモが支えられる人口をシミュレーションされた人口が上回ると国家ができる
    • Markov Chain(本章のメイン)
      • 遷移行列が陽にわからなくても、数回の試行での結果から論じることができる
      • MCとプッシュダウン・オートマトンの関係
      • MCとRNNの関係は?
    • 効率的市場仮説
    • 株式会社が永続化できたのはなぜか?東インド会社がきっかけ?
    • 江戸時代に先物取引はあったか?
    • その他の話題についてはこちらも。【勉強会】SSC輪読会 Vol.5を開催しました! - 歩いたら休め

8/8

  • deep learning関連のmeetup。手動かせてない。
    • DeepLearningと全然関係ないが、ウィーナーのサイバネティクスの話になり、昔読書会やりたいと思ってたの思い出した。

8/7

  • asanaのカレンダービューが結構いい感じであることに気づいた。やることをほぼ一元管理できて、slack integrationもあるのであとからログを追える(ただし、ログはこのままだと流れるので注意)
  • 下痢・発熱(38.5度)・頭痛で3日間ダウンする。かなり久しぶり。

8/6

  • Goodpatch土屋さんとご飯食べる。2011年のシリコンバレーツアー以来で懐かしくなる。ベルリンの話など聞く。 f:id:satzz:20150806115801j:plain
  • 魚がしでうなぎの炙りを食べる。 f:id:satzz:20150813203427j:plain
  • Terminator Genisys見る。

8/4

  • TypeScript, Dartをしらべる
  • output用のSlackをつくる。input用のSlackは前からあるのだけど無償だとログがすぐ流れてしまうので、情報の重要度的に分けたほうがいい気がする。

8/3

  • 実践DDD読みはじめる。
  • Electronでアプリを作るメリットはなにかについてかんがえる。ブラウザやアドオンのショートカットキーを排除した状態で自由にキーバインド定義できることか。
  • co-chanの実装を読む。goのチャンネルにインターフェース合わせてるだけでJSの特殊な機能を使っているわけではない(使ってるのはfunctionとかarrayとかだけ)ので気合で実装されている。むしろgoのチャンネルのほうがいったい何者なのか、とか、各言語のgeneratorや軽量スレッドは何なのか、とかいろいろ気になる。
  • LabCafeもくもく会

研究をネタに集まる

Co-Labという研究者および自分のような研究に興味のある人のコミュニティがあって、本郷(LabCafe)・恵比寿(Geek Office Ebisu)でquarterlyくらいで集まっている(昨日は恵比寿)。 (もしあれば)自分のプロジェクトの進捗を報告したり議論したりする。 今のところ人工知能・脳科学・バイオロジーの話題が多く、BMI明晰夢の話で盛り上がった。 今後も続けていきたいと思っているので、そのようなコミュニケーションに興味がある方は気軽にご連絡いただければ嬉しいです。

f:id:satzz:20150613201546j:plain

3/5 機械学習勉強会メモ

全脳アーキテクチャ若手の会の勉強会と懇親会に参加。今回のテーマは時系列処理。

ドワンゴ初めて行った。

関心

ちょうどセンサデータを扱っているのでタイムリーだった。 学部で物性の実験をやっていたときはまず時間自己相関をみる、だったが、生物・制御・経済・社会情報になると古典的情報理論をはじめとしていろいろな時系列アプローチがある気がする。 機械学習では、RNNが定番かと思っていた(tanichuさんもRNNを組み合わせてピアジェのシェマの実装をされていた)。

が、それ以外にもいろいろあるようだ。

話題

時系列処理

複数の情報(たとえば視覚)の間に時間的相関を発見し、さらに未来を予測する処理、と理解。

主要なモデルの導入

  • Recurrent NN
    • Elman networks: 中間層の出力を次の入力に使う。文法学習に適する。
    • Jordan networks: 出力層の出力を次の入力に使う。運動学習に適する。
  • Echo State Network
    • 学習が速い。
    • 合成波・正弦波・決定論的カオス波の識別が可能。乱数波や、声の波形もおそらく識別可能。
  • Time Delay Neural Network

後で調べる

  • Long Short Term Memory
  • Reservoir Computing
  • Convolutional NN

脳の情報処理との関連

時系列処理を担う機構が海馬にあると思われるのはいいとして、大脳新皮質にもあるかどうか、という話。

昔話

SVMとNNの勢力交代について。たしかに一時に比べるとSVMってあまり聞かなくなった。

感想

どのモデルがどういう問題に適するのかの理解のためには実装が一番速そう。 若い人(学部生)が多いが議論のレベルが高く刺激になる。

12/22 評価経済勉強会メモ

@Geek Office Ebisu
初参加。自分の言い換えや妄想も入れてなぐり書き。

  • 岡田斗司夫氏の贈与経済論と斉藤賢爾氏の貨幣論をヒントとする
  • 伝搬投資貨幣PICSYに似た評価経済システムの実験場としての勉強会
  • 交換、贈与、純粋贈与
    • バタイユらしい。読んでないので実際何を言ったのかは知らない
    • 地球の経済系に与えられるエネルギーが正の純粋贈与だとすれば、地球外に散逸する負の純粋贈与も考えられる気がする
    • 砂漠の民の歓待・贈与の文化
      • 全く知らない人があっても盛大におもてなしをする。 *1
  • 交換経済から贈与経済への揺り返しについて
    • 生産コストの減少、サービスのフラット化
      • Makersムーブメント
      • AirbnbのクーポンやUberのpromotion codeのような、貨幣以外での取引の増加
    • 分業の終焉
    • 生産コストが低くなった財・サービスについては交換自体が無意味になる?
  • 財の稀少性の問題
    • 絶対量の問題というよりむしろ文化や認識の問題でもある。他国の金の地位を日本では銀が占めた。
  • 貨幣の現在
    • 貨幣の蓄積性、匿名性などが優位に働くならば貨幣が成立する?
    • 貨幣の氷山モデル
      • 他者への信頼が担保できないときに貨幣経済が出現する
      • 逆に、信頼関係が構築されるとシステムのオーバーヘッドが目立ち、邪魔になる
        • 地域通貨が消滅するのは、むしろ地域社会の再興という目的を達したからである可能性もある
    • ゲゼルの自由貨幣
  • なめらかな社会
  • 家族論
    • as-isの社会システムは核家族などの血縁システムをベースとしている。
      • 社会保障しかり、ソフトウェアのファミリーパックしかり。*4
    • シェアハウスなどの普及によって血縁が本質でない家族が当たり前になると、意味をなさなくなる可能性はある
  • マネーゲームはどこから切り崩されうるか
  • 岡田斗司夫氏について
    • クラウドシティ
    • FREEex
    • いずれにしても魑魅魍魎が住まっているということはわかった。。

*1:このへんを連想するので読み込みたいかも。まれびとの歴史

*2:はてな社内で一時期採用された人事評価システムとも関連があった記憶が

*3:万物理論 (創元SF文庫)の小道具である7値のジェンダーを連想するが、そもそもアナログ、ファジーなジェンダーというものも想像できるかもしれない

*4:血縁社会とポスト血縁社会という観点で、ムハンマド以前/以降のアラブ社会を比べてみても面白いかもしれない