以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

Gavin Andresen「MITでフルタイムでbitoinプロジェクト続行できるようになった件」

以下斜め読んだ内容

  • Digital Currency Initiativeに参加することにした

  • 自分がやってるbitcoin関連のプロジェクトはここで続ける

  • Wladimir van der LaanとCory Fieldsも一緒に参加
    • WladimirとCoryはBitcoinのコア開発者
    • 二人ともMITが開発継続にとって良い場所だと感じてる
  • MITがbitcoin開発の総本山になったってこと?
    • No
    • オープンソースだし、プロジェクトへの参加の仕方や立場は色々あるしできる
  • 開発者へのサポートが色んな所からある状況はいいこと
    • 例えばプロジェクトをサポートしてくれつどこか会社なり組織なりが潰れた、とする。
      • そうなっても、プロジェクト自体が即死亡することが回避できる
  • bitcoin財団の経営破綻が公になってから、色んな人が声をかけてくれた
    • 自分(Gary)、Wladimir、Coryが開発継続に必要な資金が得られなくなっていた
    • 声をかけてくれたみんなに感謝したい
    • Joi Ito(Meia Lab所長)と、Brian Forde(Digital Currency Initiative責任者)にも感謝したい
      • 二人が色々動いてくれた
      • bitcoinコミュニティーへのサポートするために凄い力注いでくれてる
      • 興味があれば、brianにコンタクトとるといいと思う

Daniel Stenberg「2015年春時点でのHTTP/2普及の現状と今後」

  • daniel.haxx.se 2015.3.31のブログエントリ
  • http/2が今どれくらい普及してるのか、年末にどうなる、サーバーとかプロキシーとかCDNとかのサポートはどんなんなのか、等々
    • 手際よくまとまってて勉強になる
  • エントリの締めの円グラフは「2015年末にhttp/2普及度合は?」アンケートをまとめたもの
    • 「fb/g+/twitterの中の人として働く人の実感ではこうだ」というのがわかって面白い

以下斜め読んだ内容

  • HTTP/2プロトコル
  • 2015年2月のデータだと全トラフィックの5%でhttp/2利用してる
    • 2015.2.15にエントリ書いてる
    • daniel.haxx.se » HTTP/2 is at 5%
      • (補足)ざっくり斜め読み
        • http/2をデフォルトで有効にしてるブラウザ
          • Firefox35(2015.1.13リリース)
          • Chrome40
        • 2015.1.28発表のgoogleのデータだと5%のトラフィックはhttp/2
        • mozillaのデータ
          • Firefox35ユーザから利用してるhttpプロトコルの情報を収集
            • 総数3400億のhttpレスポンス
            • そのうち9%がhttp/2でした
    • 実際にもっと多いんじゃ?
  • 俺予想
    • 2015年末には10%越え
      • 20-30%くらいいけるんじゃ
      • ビッグプレイヤーの一挙一動の影響がある程度あるが
      • facebookinstagramtumblryahoo!、などなど
    • 2016年には大半のhttpリクエストはhttp/2利用するはず
      • 最低でもブラウザではそうなるはず
  • 5%とか10%とか20%、等々の数字の出し方
    • httpリクエストの数についての比率
      • データ転送量ではない
      • ブラウザの数でもない
    • 2014年12月時点では5%とか20-30%とかの数字はどうだったのか?
      • 計測方法の是非について議論は可能
      • ただこの手の議論の行き着く先は決まってる
        • 曰く「めいめいが正しいと思う方法で計測すべし」
  • 「俺予想」とか言ってるお前は誰なの?
    • プロコトル、http/2にとても関心持っている人
    • httpワーキンググループも何年も参加してる
    • http/2実装のいくつかに参加してる
    • 所属とか勤務先とかの立ち位置をこのエントリに読み取ろうとするのはご自由に
      • ただあくまで個人ブログで書いてること
  • 現時点でhttp/2実装は36ある

ブラウザ

  • chrome,firfoxは前からサポートしてる
  • IEは未サポート
    • tech preview触った感じだとちゃんとhttp/2実装されてそう
    • 今後出るパブリックリリースで搭載では
  • safari
    • http/2サポートする気配ゼロ
  • 俺予想
    • 2015年末にはブラウザ全体で50%以上はhttp/2サポート

サーバ

  • apache httpd
    • mod_h2があるが進捗はアルファレベル
    • icing/mod_h2
    • 正座して待て or 開発助けよう(金でも人手でもok)
  • nginx

  • h2o

    • h2o/h2o
    • 新顔で。高速なことがウリ
    • ずいぶん前からhttp/2サポートしてる
  • nghttp2
    • Nghttp2: HTTP/2 C Library - nghttp2.org
    • リバースプロキシ提供
      • http/2からhttp/1.1にダウングレード
      • 運用中のhttp/1.1しか話さないサーバのフロントとかに置ける
    • サポートしてる機能は他にもいろいろ
  • apache traffic server
  • nettyとか、jettyとかもサポートしてる
  • 俺予想
    • 2015年末時点でhttp/2喋るサーバーのシェア80%越え

プロキシー

サービス

  • google(傘下のサービス。youtubeとか)、twitter
    • 数ヶ月前からhttp/2有効にしてる
  • spdyサポートしてるwebサービス多い
    • chromeが2016年にspdyサポートを切るとアナウンスしてる
    • この時期をめどにspdyからhttp/2に切り替えていく気ではないか(と想像)
  • 俺予想
    • 2015年末時点
      • 大規模サービスだとhttp/2サポートになってるか、準備中か、のどっちか

CDN

httpクライアント(ブラウザ以外)

  • curl、libcurl
    • 数ヶ月前からhttp/2サポート
  • プログラミング言語ごとに使えるhttp/2対応クライアント
  • 割とhttp/2に切り替えしやすい状況では

他には?

  • あるかも。思い出したら補足する

http/1.1の寿命

  • 俺予想
    • 今後何年も使われるし
    • インターネット全体でhttp/1.1だけサポートしてるサイトの数は二桁をキープし続けるはず
    • なんで全体が移行していかないかは色々ですね

まとめ

f:id:vwxyz:20150421105935p:plain

  • twittergooglefacebookにいる友達に聞いてみた
    • 2015年末時点でhttp/2の普及の度合
    • 答えやすいように、5%ごとに区切った選択肢作って選んでもらった
    • 50%まで5%刻み。それと50%以上
    • 回答集めて、円グラフにしていた
    • もちろん統計的な厳密さはないけど、参考程度に
    • 自分は15-20%くらいを選ぶ
    • 中央値とると10%くらいか

Kenton Varda「OSXのカーネルバグを使ってChromeとNode.jsを無限ループに嵌らせる」

sandstorm.ioの2015.4.8のブログエントリ

  • Sandstorm News: Remotely send Chrome and Node.js into infinite loops via this one weird OSX kernel bug
  • osx/iosの非同期i/oを捌くkqueueのバグを見つけた件について
  • 見つけた経緯、振舞いの詳細、バグを使ってできる攻撃、影響を受けるアプリ、書いた理由(アップリのdescriptionは素っ気なさすぎ)、学んだこと、各所パッチ出したからこのネタ解禁できる、等々
  • kqueueを使ってるos/software全てが影響受けるわけでないこと(Darwinのみ、nginxはセーフとか)もさらっと書かれてて勉強になる

以下斜め読んだ内容

  • 数ヶ月前に発見したDarwin kernelのバグ
  • セキュリティバグ
  • Dawrin kernel自体はほぼ全てのappleプロダクトで使われる
  • このバグを攻撃者が利用すると。。。
    • DoSアタックができる
    • ターゲットはnetwork serviceやアプリ
    • リモートから、しかも手軽にできる
  • このブログ書いてる日にappleからパッチがでた

  • 最初に断っておく

    • バグをみつけた自分(Kenton)
      • Adam Langley先生(ImperialVioletの人)レベルの人間じゃない
    • 見つけたバグ
      • HeartbleedとかShellshock級の深刻なバグとかではない
      • 攻撃者がこのバグを突いてできることはしれてる
        • 一時的なサービス利用停止くらい
  • 全てのセキュリティバグはそれぞれ全容を書かれるべき
    • というのが持論
    • それぞれのバグから自分らが学べるように
    • 今回のバグについてのappleの記述は素っ気ない代物
      • ここからは何かを学ぶのは無理
  • それとは別の今回のバグの話なネタとしていい線いってる

  • eventドリブンなI/Oを利用するためのインターフェース

    • OSによって特色がある
    • この辺りをリサーチしてるときに発見した
      • このインターフェースを例えるならこんな感じ
    • 「これとこれと・・・がいま自分が開いてるコネクションです。こいつらからメッセージが飛んできたら起こしてくれ。それまで寝る」
  • これに対するOSの反応はさまざまで、5タイプくらいある
    • LenuxはepollBSDkqueue、winは、・・・(略)
    • メカニズムが違うだけでなく、それぞれがカバーしてるユースケースの範囲も違う。
  • ユーザは特定のメカニズムを選ばないといけない
  • 自分ら開発してるCap’n Protoのために、このosごとの違いを抽象化する仕組みを作ろうとしてた
    • Cap’n Proto
    • これ作るために各osのインターフェースの特色をきちんと理解しようと色々やってた
  • man読み比べて気づいたこと

    • OOB(Out of Band)データの扱い
    • 別名緊急データ(urgent data)
    • このデータのハンドリングについて記述は有るものもないものある、という感じ
    • tcp接続では頻度小ながら使われる機能
      • tcp接続ではデータはキューに入って順番に送られる
      • この順番待ちをスキップして送ることのできるデータ
    • OOBのことは知らなくて当然
      • telnet使うとき以外だと、はユーザは利用する機会のない機能
      • 接続先のアプリが入力を処理してないときに"ctrl+C"押すみたいなことを通知する方法が必要だから
  • ほぼ全てのevent通知APIでは、通常データとOOBデータは違うイベントを発火する

    • poll()と後継のepollの場合
      • 通常データはPOLLINイベント
      • OOBデータはPOLLPRIイベント
  • アプリがOOBデータ受信を想定していない場合

    • アプリはOOBデータのイベント通知について問い合わせをしない
    • kernelはOOBデータのイベントをスルーするか、通常データストリームに含めるかのいずれか
  • 各os別のkqueue

    • BSD
      • OOBデータハンドリングについて曖昧
    • FreeBSD`
      • kqueue(2)
      • OOBデータハンドリングについて記載ゼロ
      • 調べた限りだと、OOBデータイベントがサポートされてない
    • DragonflyBSD
      • OOBデータイベントEVFILT_EXCEPTが定義されてる
    • DragonFly On-Line Manual Pages : kqueue(2)
    • Darwin(OSX/iOS)
      • ドキュメントにはOOBデータのことが書いてないが実装されてる機能あり
      • EVFILT_READイベント
        • 通常の(つまりin-band)データ受信で発火
        • どうやらOOBデータ受信した時もEVFILT_READイベントを発火してる
          • ただフラグ( EV_OOBAND)をつけてイベントを発火してる
      • 通常の流れ
        • 通常データ受信
        • recv()コールして受信データ読み込み
        • それでおしまい
        • 再びイベントループへ戻る
      • level-triggeredモードでkqueue使ってる場合
        • 簡単なのでたいていの人が使うモード
        • osは読み取りした後も、OOBデータが残る読み取り前データとして残る
          • ずっと受信してるかのように振る舞う
          • 同じイベントを繰り返して発火する
        • こうして無限ループに入り込む
  • 緊急データをtcpパケットで受けとっただけでほぼ全てのイベントドリブンなネットワークアプリが無限ループに嵌るという話?
    • んなアホな?と思ってた
    • 試してみた
    • ホンマやった
      • chrome、node、nginx調べた
    • chrome
    • node
    • nginx
      • セーフ。無限ループにならなかった
      • 新しいデータを受信したときだけ意図してないイベントを受け取るように動く
      • 何度も利用できるデータがあったとしてもイベントを何度も受け取らない
        • edge-triggeredモードでkqueueが使われてるおかげ
    • nginxは無事だったが、chorme, nodeでは無限ループを生んだ
      • chromeもnodeといった有名どころが影響受けてる
  • 今回のバグはAPI設計レベルの問題
    • kernelにバグがあるわけでない
    • インターフェースが混乱気味
      • さらにちゃんとドキュメントに載っていないせいでもある
      • インターフェースのまずさのせいで複数アプリで同じバグが再現する羽目に
  • このバグを直すやり方は二手にわかれる
    • このバグの影響の出るアプリ全てを直す
      • 今後出るだろうアプリも含めて
    • APIそのものを変えて、このAPIの挙動に依存したアプリは無視
      • つまりクラッシュさせる変更をする(数は相当少ないだろうが)
  • 自分からみて正しいと思うやり方でappleはこのバグに対応してる
    • appleはインターフェース修正した
      • TCPでOOBデータ受信したときにEVFILT_READが発火しないようにした
    • appleのこの件の記述が全くようわからん
      • なんでこの問題が"state inconsistency issue"と表現できるのか
    • パッチ適用後のmacで自分でもOOBデータ送信テストしたがバグは消えた
      • OOBデータはスルーされるようになった
  • このバグの教訓
    • 混乱気味のAPIはセキュリティ問題になる
    • もしあなたのAPIを利用する多くのユーザがセキュリティバグを生むようなやり方をしてるなら、それは彼らのコードにバグがあるのではなく、APIにバグがある

Daniel Cawrey「Bitcoinのコア開発者による定点観測と予測」

がわかって面白い

  • 追記2015.4.23
      -  Gavin AndresenのDigital Currency Initiative参加の件を追記
    

以下斜め読んだ内容

  • Peter Toddさん(30歳)

  • Toddと話す機会あったので色々聞いてみた

  • bitcoinの今後(長いスパンで)とか

時の権力者の脳内は「bitcoin=変わるべき』一択

  • bitcoin業界への政府の介入は不可避とtoddはみてる
  • 危惧というレベルではない
  • todd自身が役人と、bitcoinへの規制をめぐって議論してきたことから得た結論
  • todd曰く
    • 政府がbitcoinに実際に口を挟むことはどんどん起こる
    • プロトコルの仕様とか根幹の部分も標的になる
    • 役人とカンファレンスずっと話をしてる
  • 役人たちの 脳内はシンプル

bitcoinネタで資金調達はある意味大変

  • bitcoinで何か、的なスタートアップへの投資はどんどん増えてる
  • 投資家がcryptocurrency系スタートアップに期待してること
    • これが問題だとtoddは考えてる
    • アーリーステージなのに、すぐに収益を上げろと圧力
    • こういう圧力のある環境だと真っ当な資金調達が難しい
  • todd曰く
    • 早期にマネタイズできるビジネスモデルがないと資金調達できない
    • これはcryptocurrency業界の大きな問題
    • 最近のRipple Labの900万ドル調達がいい例
    • Ripple Labs | CrunchBase
    • rippleのXCPトークン
      - (補足)rippleの貨幣はxrpなので、typoでは?
      
    • 本来アーキテクチャにとって必要のない代物
    • これはセキュリティの点でもシステムの安定性の点でもひどい妥協
    • XCPトークン導入によって中央管理型のシステムに成り下がった

マイニングへの最大の脅威は政府

  • マイニングが分散型であることが重要だと考えてる人たちは多い
  • bitcoinマイナーの手足を封じたいと政府が考えれば、そのたの冴えたやり方を政府はきっと思いつく、とtoddはみてる
  • todd曰く
    • 政府はASICの製造自体を規制すればいい
    • ハードウェアに強制停止ボタンを埋め込んでメーカーが遠隔で停止できるようにする、とか
    • マイナー(ASIC利用者)を許可制にする、とか
  • 政府にとってASICを作れるだけの技術力を持ったメーカーに圧力をかけるのは簡単
  • todd曰く
    • パフォーマンスとコスト双方で売り物になるレベルのASICを作れるメーカーは数えるほどしかない。
    • つまり、Intel、ASMC、GlobalFoundries

bitcoinのライバルは全然面白いのがない

  • 金融系テック企業は高収益なので、多くのスタートアップあり
  • todd曰く
    • ErisもHyperledgerもとても良いテクノロジー
    • ただ超ツマラン
    • 既存のものよりも優れた会計ソフトを作ってるだけ
    • 会計の整合性を確保するために暗号技術を使ってるだけ
    • Eris Industries
    • Hyperledger
  • こうしたbitcoinオルナティブのやってることがうまくいっても、bitcoinにとっては全然良い材料にならないのが問題
  • todd曰く
    • ? "The worry for Bitcoin is that when it does catch on you’ll have alternatives that for law abiding companies are at least every bit as good as Bitcoin; probably better."

bitcoinは魔法の送金手段ではない

  • bitcoinで送金はハードなビジネス
    • 多くのプロジェクトが突き進んでる
  • toddはbitcoin送金は人々が考えるほど手軽にはならない、と考えてる
  • todd曰く
    • 送金において、bitcoinは規制されてる既存の組織と競えるのか?
    • 消費者が既存組織に値下げするように仕向けれるなら、競える
    • uberが規制の穴をついて利益得てる話みたいなこと

bitcoin founcationは不祥事多すぎ

  • 2011年設立のbitcoin foundation
    • この団体の目的はcryptocurrencyの認知拡大
    • その必要自体はtoddも同意
    • 内部にたくさん問題抱えてる
    • bitcoinエコシステムで重要な役割果たせるような所までいけてない
  • todd曰く
    • 政治的な圧力団体してうまく行く可能性もっていた
    • 政権や制度に入り込んでいくのは重要
    • foundationは抜けた
      • 政治よりも開発にpivotしてしまったから
    • 役員のスキャンダルのせいで悪名高くなり、存在価値自体低くなってしまった

bitcoinがスケールするのか?まだよく分からない

  • bitcoinプロトコルに技術的な変更を入れること
    • toddは強く反対してる
  • todd曰く
  • foundationチーフサイエンティストのGavin Andresenのスケーラビリティについての仕事
    • これを特にtoddは問題視してる。
    • アカデミックレベルの厳密さが欠けてる
  • todd曰く
    • Gavinはbitcoinのスケーラビリティについてどの研究機関のリサーチにも参加してない

    • Gavinのスケーラビリティ論はリサーチに基づいてない

    • 実際にGavinがやってることも本来必要される厳密さが欠けてる
    • (補足)この懸念は解消されそう

二重支払はbitcoin会社へのペナルティと化す

  • bitcoinの取引では10分かかる承認
  • 承認完了するまで二重支払いのリスクあり
  • todd曰く
    • 二重支払いのせいでお金を失う人はその事態を認めることがまずない(認めるためのモチベーションがない)
  • 詐欺師が同じ額のbitcoinを二回以上つかえてしまうことを意味する
    • bitcoin会社にとっては結構でかい問題とtoddはみてる
  • todd曰く
    • Coinbaseなんかは承認数が0の支払いを契約によって受け取らないといけない
    • Coinbaseは自分らのビジネスをうまく回すためにそういう風にしてるんだろうが

Ethereumは学生レベルのプロジェクト

  • Ethereum
    • bitcoinをより良いものしようというプロジェクト
    • bitcoinの歴史でもかなり早い時点でスタートしたプロジェクト
    • todd自身はEthereumに色々問題があるとみてる
  • todd曰く
    • Ethereumの中の人はみんなスマート
    • 集中してやってないし真剣さがたりない
    • 学生のリサーチプロジェクトっぽい
    • 消費者が今抱えてる問題を実際に解決するような代物じゃない
  • Ethereumの志は良い
  • Ethereumをより優れた、ちゃんとマネタイズできるスタートアップが出てくるとtoddや多くの開発者は予想してる
  • todd曰く
    • Ethereumは今後よいアイディアを何個か出してくるはず
      • 最終的にはEthereum発のよいアイディアを取り込んだよりシンプルなシステムにEthereumは負ける

I expect to see them produce some good ideas, but ultimately be out competed by simpler systems incorporating those ideas.

承認時間の短縮は不可能

  • 10分
  • bitcoinのブロック承認の所要時間
  • transactionの確定のせいでもっと時間かかることも
  • コード改良しても承認時間短縮は実現できない、とtoddは感がてる
  • todd曰く
    • 承認時間はセキュリティパラメータ
    • 時間短縮はシステムの根本的な安全性を下げることになる
    • 理由は色々あげることができる
    • 例えば、巨大で中央管理されたプールを有利にしてしまう
  • bitcoinのような分散型システム
  • サードパーティへの信頼を不要にする
  • 中央管理型モデルと比べると速度はたいてい遅くなる
  • 高速化実現が意味すること
    • 大衆への普及の代償としてbitcoinテクノロジーの放棄
  • todd曰く
    • 承認時間1〜2秒の実現
      • これが中央管理型システムと互角になるレベル
      • ECで実用できるレベル
      • このレベルへの到達は不可能
    • bitcoinのシステムの1つ上のレイアーでそういう実用レベルのシステムを構築する方が見込みがある

bitcoinから派生したものがとても多い

  • 2008年の経済危機の只中でbitcoinは大衆へプッシュされていった経緯がある
  • すぐ忘れられやすい話

  • toddも今後のためにその点を強調してる

  • todd曰く

  • そもそもbitcoinとは。。。。
  • クレバーな経済と政治があってこそうまく機能するようなシステム
  • 政治的な狙いを持ってる

  • Proof of workというアイディア

  • 中央管理型システムや政府への関心があってこそ生まれた
  • 自分たちで銀行を回す
  • そうルーツがあるとしても、可能な解決方法の候補ではなさそうだが
  • todd曰く
  • 政治的な動機がないなら、proof-of-workみたいなややこしい仕組みを使う必要性はないはず
  • 信頼できる少数精鋭のサーバーで回した方が、シンプルだしずっと効率的

Maroon5の新作PV "Sugar"はヤラセ有りと調べ上げられた件


Maroon 5 - Sugar - YouTube

  • 週末に偶然見つけて以来お気に入りPVと化していた
  • ひとしきり再生した後に、ググる
  • さらにググる
    • 仕込み無しはあり得ないのでは?
    • という当然の疑問が現地で噴き出してることを確認。
    • さらに画面に写り込んでる人たちをプロファイリングしていく作業が進行していた
  • 調査現状の結果わかったこと
    • 写り込んでる人たちに俳優・女優が複数いること
    • うっかり、舞台裏をポロっと喋った人がいること
  • 作った側からのこれら諸点についての説明は今のとこなさそ
  • そしてさらに調べた進む目処はなさそう
    • 取材申し込んでも当事者はノーコメントで足並み揃えてる
    • 探す側がこのネタに飽きた模様。捜索熱が消え去った感じ

以下斜め読んで分かった内容

  • PVに登場するカップルは6組
  • Aメロ〜サビのに登場する白人カップルの挙式
  • Bメロ〜サビに登場するチャイニーズ系の花嫁花婿の挙式
  • 後半のサビの繰り返しに4組短く登場
    • ラテン系カップル
    • 白人系新郎新婦の二次会?ぽい会場
    • 屋外の式場で黒人カップル
    • 白人とチャイニーズ系のカップル

1組目

f:id:vwxyz:20150202155615p:plain

  • 新郎
    • 俳優のNico Evers-Swindellさん
      • huluでも配信されてるドラマのGrimmにも出演してる(がシーズン4でゲスト出演)
    • Nico Evers-Swindell - IMDb
    • 2011年に女優のMegan Fergusonと結婚してる
      • f:id:vwxyz:20150202160255p:plain

      • PVの花嫁とMeganは別人

      • 再婚したのでしょうか。。。

f:id:vwxyz:20150202160731p:plain

2組目

f:id:vwxyz:20150202163730p:plain

3組目

f:id:vwxyz:20150202165421p:plain

4組目

  • instagramに新婦が写真をup。しかし現在鍵付きになってる
  • marooo5のステージに近寄らないようにセキュリティの人が仕事されてるのが写ってる

PVに同行したカメラマンがUSA Todayにインタビューされてる

リソース

進捗

年始に書いたこと

  • リモート勤務
    • 転職?
  • 移住
    • ハワイ、or 英語使える都市
      • 年中暖かいとこ
      • 子連れ、ペット連れに寛容な都市
  • 会社つくってみる
  • 副業はじめる
  • 語学用の俺用アプリ作る
    • 多読用
    • 今や語彙も文法も怪しくなってるフランス語の記事を読む補助に

今年の目標 - 以下斜め読んだ内容)

以下略記

リモート勤務

  • 最近始めた(というかリモートでも働けるようになった)
    • 今のとこはオフィスに通ってる
      • 日本人自分だけ
      • ってことでオール英語のコミュニケーションに不安が消えるまでは通う
    • 午前はリモート、飯食ったらオフィスへ、とかはたまにやる

移住

  • 未達成
    • リモートできるようになったので、残るはVISAをなんとかする
    • 来年中に移住する

会社設立

  • 未達成
    • 来年勉強しながら作る

副業

  • 始めた。続ける

俺用アプリ

  • 未達成
  • 進めては放置を1年繰り返した
    • 誰かが作ってくれる気配なさそう
    • rubymotionとapple dev. programの更新が近い

色々

  • flow startして、気が付いたらメモリ2GB消費してしまう
    • これをなんとかしたい
    • Air買わなくてPro 16GBにして本当によかった
  • eslintのjsx対応がもっと早く進んで欲しい
  • bitcoin、altcoinのweb walletはjsつかってることが多い
    • この辺の理由をサクッとまとめた資料読みたい

清潔な盗賊「ラーザ・ビ」

  • 追記2014.2.28
    • あれよあれよと4週連続1位キープしてた
    • 新人でこんだけキープしたのはone direction以来な気が
    • 今(2014.2.24付)ukチャートで1位money on my mindもいい曲
    • 歌詞斜め読みした

f:id:vwxyz:20140207132107j:plain

f:id:vwxyz:20140207131900p:plain

Music Video


  • 冒頭はヘンテコ日本語だが以降はLost in Translation風の、割とリアルな日本になってる
  • センター街とか山手線とか魚市場?とか、居酒屋とか、全編にわたって色々でてきて面白い
  • 市場の映像は築地?かと思ったがBメロのところで"Kyoto to the Bay"とかいってるから舞鶴かもしれない
  • メイキングもみたがやっぱり築地。映像と歌詞の世界観は連動してない
  • f:id:vwxyz:20140207132145j:plain

  • f:id:vwxyz:20140207132342j:plain

  • f:id:vwxyz:20140207132350j:plain

  • f:id:vwxyz:20140207132359p:plain

  • オリエンタリズム視線の日本が延々映像化していくという既定路線ではなかった

Clean Bandit??

f:id:vwxyz:20140207131926j:plain

  • ストリングス+エレクトロ、という変わった構成
  • zeddみたいに曲ごとにボーカリストが参加するスタイル
  • Clean Banditもロシア語のフレーズ由来
    • 意味的には"complete bastard"と訳すようなフレーズをgoogle翻訳風にclean banditとしてる、らしい
    • 清潔な盗賊とかラーザ・ビとか何なの?、と日本の音楽メディアにはツッコミを必ず入れて欲しい
  • Cambridge大学出身なひとたち
    • 音楽専攻ってわけでなく、ロシア語、イタリア語、建築、etc..と色々かつダブル専攻な人たち
    • Q&A: CLEAN BANDIT | djmag.com

邦題

  • music videoにアーティスト名の日本語表記はこれだ!、Rather Beの邦題はこれだ!と指定してきてる
  • 万が一、清潔な盗賊「ラーザ・ビー」になったらちょっと楽しい

ライブ動画


Clean Bandit 'Rather Be' at Sub-Sonic Live - YouTube

歌詞

  • the bayとかsceneとかswitch off batteryとか含意?な箇所は散見
    • 自分が同じ空気を吸っていえれば分かったであろう部分

以下大体の訳

  • 腰を下ろす、という状態からはほど遠い状態にある私達
  • 世界を股にかけて旅してきた私達
  • 私の側に貴方がいるなら、ここ以外に望む場所はない
  • ずっと待つことだってできたし、観てきたものにとても満足してる
  • 私の側に貴方がいれば、私の心臓は動き続ける
  • 私達の歩みの1つ1つ、京都からどっかの港へとか
  • 行く宛もなくフラフラしてきた
  • 私達は全然違うようで同じ。貴方は違う名前だった
  • バッテリを取り出しましょう

  • 貴方がもう一度チャンスをくれれば、そのチャンスを活かしたい

  • 暗闇の中の一瞬の光のようなもので、私はそれを生み出したい
  • 私の側に貴方がいるなら、ここ以外に望む場所はない
  • 他にいたい場所はない
  • 私達は心の平和をみつけるというミッションに身を捧げた
  • このミッションは期限がないから完全なミッションコンプリート
  • 貴方の側にいることはすごく楽で、神々しいくらいシンプル
  • 一緒にいるなら、ここ以外に望む場所はない