「ストリーム」を含む日記 RSS

はてなキーワード: ストリームとは

2017-10-25

アニラジ配信サイトFlash依存

ブラウザゲーが脱Flashできるのかって言われているけど、アニラジ配信サイトはどうなんでしょうね。

そう思って調べてみたら、ほとんどがニコニコチャンネル配信してるからFlashニコニコにお任せ状態

Flash製の電子ブック経由でmp3配信していたラジ関も、11月からニコニコチャンネルでの配信になる。

他は最初からFlash使ってないランティス(未だにWindows Media形式ストリーム配信とか逆にすごい)とか、最近HTML5に移行したアニメイトタイムズとか。

ここら辺はあと2年経っても聞けるんだなって安心してる。

しかし自前で配信プラットフォーム持ってる超!A&G+音泉・響は未だにFlash依存してるけど止めるつもりあるのかな。

2年経ってFlashが死んだら一緒に死んでスマホアプリ限定になるのかな。ラジオクラウドみたいに。ラジオクラウドみたいに!

ああ、どうせみんなニコニコに上がったのを聞いてるからどうでもいいのか。花江くんとちゃん里菜の啓発CM効果ねえな。

この辺の事情を伊福部文化放送タブリエとブシの偉い人を呼んで「どうなってんだオイ」って聞いてほしい。

そのための番組でしょラジオラジオって。え、違うの?

2017-10-13

黒塗りのベンツ、高そうな外車、車高が高くてタイヤがごつい、刺青の腕をチラ見せ、音漏れが激しい車

この辺の車はDQNだと俺でもわかるけど、実際は関わってみないとDQNだってことが分からないパティーンが多くないか

ドラレコ動画をわりとよくyoutubeで見てるから言えるけどDQNであることは車種からは分からないことが多いと思う。

DQNじゃない人が専用で乗る乗用車とか明確にあるもんかね。

ホンダストリームからDQNかどうか見分けつかないでしょ普通

2017-07-25

ポケモンGOシカゴイベントに行ってきた。その日に起こった事。

結論から言うと、災難だった。

その日に起こったことを順番に書く。

1. 開場1時間である9時に入れる特典を提携ホテル宿泊でゲット、8:30に並んで結局入れたのは11:00時近く。すんごい列だった。最後尾までたどり着くのに30分くらい歩いたもん。入り口一つしかなかったし、ディズニーランドみたいな持ち物検査セキュリティーチェックあったし。列が長くなるのはしょうがなかった。

2. 会場に入れても、アプリが落ちまくってゲームができない。会場でゲットしたポケモンゼロレイド?なにそれ状態ポケストップは2つくらいスピンできた。

3. インフォメーションセンターテントに長蛇の列。ログインできない、繋がらない、もしくはイベント専用QRコードが読み込めないなどの苦情専用窓口となってた。(フードのテントガラガラだったから、食に困ることはなかった)

4. ゲーム開発会社CEO、メインステージに登場。ブーイングを受ける。このゲームなんとかしろ、みたいなチャントが。健気にハイテンションで進める司会の女性ペットボトルが飛んで行った。当たらなかったけど、これはいけない。

5. 入場して1時間くらいで諦めて会場を出た。近くのデリみたいなところでWifiをゲット、それでもアプリは落ちまくる。それでも会場にいる時よりはマシだった。

6. 午後2時くらい?、ホテルに戻って、Youtubeで会場のライブストリームを見ていた。運営元のスタッフが出てきて、チケット金プラ100ドル分のポケコイン参加者全員に配るとアナウンス。観衆から喜びのイエーイみたいなどよめきが。全然嬉しくないわ。

7. ホテルの部屋になんとアンノーンが湧いた。ヘラクロスも。イベント会場でしかゲットできないレアポケモンが会場半径2マイルまで解放されたことを知る。

8. 午後4時以降、会場から離れたところであれば、なんとかプレイできるような状態にはなってた。街中を歩きまわっていくつかアンノーンヘラクロスゲット。

9. 19時、会場でイベント終了。ミステリーチャレンジキャンセルされたみたい。ただそんなのはもうどうでもよくなってた。

10. 会場から半径2マイル内であれば、シカゴイベント終了後(終わってから48時間?どのくらい続いたのかは知らない)も会場と同等の特典(アンノーンヘラクロススペシャル2玉)が続いた。

11. 伝説ポケモンレイド始まる。ジムにすごい人だかり。アプリクラッシュに苦しみながらも、なんとかフリーザーゲット。イベント参加者は、100%捕獲率。緑の輪っかで一発でゲット。

色々端折ったところ、書き損じてるところが多いと思うけど、こんな感じでした。

一言で言えば、災難。初めからフェンスで囲われた公園なんかでイベントやんないで、街全体でやればよかったのになぁと。

今までいろんな野外イベントフェスに参加したけど、こんなことに遭遇したのは初めてでした。

これって、ホテル代くらいは請求できのかな? いい勉強にはなったけど、授業料高すぎ。

この方のエントリも参考に。。ほとんど同じ内容で吹いた。

https://anond.hatelabo.jp/20170725085751

2017-05-27

ラジオ局営業独り言

ラジオ営業マンにも当然色んなタイプ人間がいるのですが、

優秀な(売上げが多い)営業マンに非常に多いのはニコポン営業と言われるタイプ

「この2017年に⁉︎」という感じですが、そうなんです。

別にラジオに限らず営業職では、コミュ力重要な要素ですが、ラジオ場合は最たるものだと思います

というのもラジオ媒体効果効率定量的に出すのが難しいメディアでして。

webはもちろん細かい費用対効果を測れますし、TV毎日発表される視聴率リーチなどはこまめに取れます

対してラジオはと言うと、

首都圏ですら、

2ヶ月に1度、日記式で行われるビデオリサーチ調査のみ。

(radikoストリーム数を諸々制約があり勝手に出せないのです)

私自身、「ラジオ広告効果がない」とは全く思いませんが、効果検証がしにくいメディアであることは確かです。

web広告がこれほど普及したなかクライアントとしても、効果評価しづらいメディアクライアント社内で承認を得るのも一苦労で、よっぽど刺さる企画じゃないと実施は難しいわけです。

それを何とか企画性やら新規性話題性なんか組み込んだ提案に仕立てて売ってるのですが、相手も人である以上、最後に効くのはやっぱり人と人との関係性みたいで。

しょっちゅう会合やったり、ゴルフやったり、プライベート趣味に付き合ったりで関係性作って、細かいフォローで最終的には「困ってるので助けてください」で決めてくるまでに仕上げるんですよね。

ちなみに会合なんかは高級店とかじゃなく、わりと普通のお店ですね。お金ないんで。

その代わり優秀営業気遣いはすごいです。支払いやらタクシー手配やらはもちろん客が気づきもしない手際ですし、お土産なんかも、客1人1人の趣味、趣向、家族構成出身地諸々を雑談から拾っといて全部頭に入れたチョイスしてきます

とまあ、長々書いてますが、どれも基本的だったりよく言われることですね。

だけど、それを全て完璧にやれるかと言われると、少なくとも私にはできないです。

そしてニコポンが多いのもう1つの理由が社内環境にもあります

基本的放送局は編成サイドが営業サイドより力関係は強く、基本ディレクターがNOと言ったらNOです。

(それが「番組に合わない気がするから」という感覚論で、子ども言い訳みたいでも)

編成が強いのは、公共電波を預かるものとして「まず第1はリスナー利益に」という点で正しいと思います

(よく編成と営業の力関係は51:49が理想と言われます)

しかし、民放として収益を上げるということを全く理解していない外部制作会社の雇われディレクター感覚論でも全てがNOにされることもあるので営業としては堪ったもんじゃありません。

そこでニコポンのコミュ力が発揮されるわけです。

ディレクターはじめ社内各所と良い関係性を築き、私がデータや論拠を示しながらも拒否された企画を「ひとつよろしく頼むよ!」で通してくるんですよね。

要はできる営業マンは社内外問わずコミュニケーションが潤滑って当たり前のことなんですが、

これだけ「主観的な」環境にあるラジオだと際立っているというお話でした。

最後に私がそんな営業になりたいかと聞かれればNOだけお伝えしてお別れ致します。

乱文ご清覧いただきありがとうございました。

2017-05-22

バッチファイル拡張子だけ変更する方法:%%~ni

FFMPEGループを組み合わせて音声ストリームをすべてのファイルから抜き出す

ようにしたいけど、音声ストリームファイル拡張子

m2ts.mp3のようになってしまうのが不満であった

%%i の参照方法として、

%%~ni

のように、~n を挿入すれば、ファイル名だけ(拡張子省ける)にできます

他にどんなことができるかは、コマンドプロンプトで call /? とすればわかります

http://pgkiss.web.fc2.com/windows/batch-file.html

2017-05-21

コンサート中継ものとかディスクに焼いたら二度と見ないことに

コンサート中継ものとかディスクに焼いたら二度と見ないことに

なりがちであることを

考えると、MakeMkeで音楽ストリームだけ

抽出ってのは良い手ではあるなぁ

そんでもってiPodにぶち込む。

今日のTafelmusicは(スペル正解しとんか)

この前の中継にしやうとか( ^ω^)・・・

そういった芸当が叶姉妹

2017-04-22

字幕ファイル

DOループ回して、動画ストリームだけ収めたMPEG

VOBと一対一変換し あとでConcatenateしやう。

面倒だが頭は混乱せんわな

拡張子MPEGでええねやろ?Mp4やないとあかんか。

VOBファイル制限あるからあかんねん。

音声もなんかトラブル誘発しがちなので一旦Decode

好きなチャンネルだけピックや。

あとでConcatenate。

字幕はOpensub

( ^ω^)・・・からDLしやう。

DVDスタイラーってどのコンテナを受け付けるんだ?

MP4受け付けるみたいよ

Stylerで合わせてバーン適当に再エンコードしよるやらう

2017-04-14

2年位使ってきたgoogle+のいいところ

そこそこ人が居ない(メリット

文字数制限がゆるい(無い?)

リンク先のサムネがあって見やす

なんだかんだコレクションは便利(主に自分管理する時)

youtubeが見やすくて貼り付けやすい。ライブ配信の視聴、共有周りはわりと良かった。コメント周りは知らん

駄目なところ

複数画像を貼り付けると表示順を変えられない(最近は幾つかの方法で変えられるようになったけど、とういつされていないっぽいのでよくわからない)

画像は本文の後にしか表示されない(本文中に挿入できない)

コミュニティストリーム矛盾しているのでいらない(性質上メインになるべきではない閉じたものなのにメインコンテンツのように推されてた)

公式クライアントしか無い

マストドンでいいかな?

最近映画でええやつってない?

最近映画でええやつってない?

邦画が望ましいですが

洋物でもいいです。ソロモン偽証とか宮部原作は や☆め☆て

terumae romaeもいいです。あれは飛行機でみた

百円の恋もみた

しかしあれはうまくいったな。音声ストリーム再生できた。よかった

2017-04-08

Ubuntu Code of Conduct v2.0を適当日本語訳してみた

訳注

Ubuntu Code of Conduct(行動規範v2.0

コミュニティ

Ubuntu」とは、「他者への思いやり」のことです。この単語自体が、人間としての精神体現しています

我々は、生産的で、幸福で、複雑な領域における新しい発想を歓迎できる柔軟性を持ち、また、あらゆるプロセスを常に改善し、さらに、各々が全く異なる要求や関心、能力を持つグループの間の協力を促進するコミュニティ希求します。

我々は、メンバー多様性によってコミュニティを強靱なものにするために、多様な参加者を活発に探します。このUbuntu行動規範は、多様なグループがお互いの利益と喜びのために協調することを確実にするために存在しています。我々は、誰であっても、プロジェクトへの参加に障害がないよう努力します。

行動規範一般的に、公的であれ私的であれ、我々がどのように振る舞うべきかを統率します。我々は、プロジェクト代表者公式非公式を問わず)、関係者、そして直接の参加者が、このUbuntu行動規範尊重することを望みます

我々は、下記に真剣に努めなければなりません。

思いやりを持つ

我々の成果物他者によって使われるでしょうし、また逆に他者成果物にも依存していますいかなる決定であっても、利用者関係者に影響を与えることを頭に置いて、決定をするときにはそのことを考慮する必要があります

他者尊重する

意見に相違があるからといって、無礼な振る舞いをとってはいけません。衝突を解決するために協働し、他者善意で行動していると仮定し、親身になるよう努力しなければなりません。苛立ちが個人攻撃に発展することがあってはなりません。不快感を覚えたり脅威を感じるコミュニティは、生産的ではありません。

発言と行動に責任を持つ

間違いを犯すことは誰にでもあります。そのときには、責任を取らなければなりません。もし誰かが傷つけられたり攻撃されたときには、注意深く、そして思いやりを持って意見を聞き、間違いを正すよう行動しなければなりません。

協力的である

我々が作り上げようとしているものは複雑で、それぞれに想いが込められたたくさんのパーツでできています。各々が違ったゴールとビジョンを持つチームの間での協調は不可欠です。ただのパーツの組み合わせ以上の成果物を作り上げるには、各々のパーツが全体を理解するよう努力しなければなりません。

協調して取り組むことで、冗長作業を減らし、品質の向上につなげることができますプロジェクトの内外を問わず協調することは大切です。可能な限り、アップストリームプロジェクトと共同で作業し、フリーソフトウェアコミュニティ協調することが必要です。透明性を確保し、その作業に関心を持つ人とはなるべく早期から協働するのが良いでしょう。

明白さ、透明性 (clarity) 、合意を重視する

社会的な、あるいは技術的な意見の不一致はよくあることです。しかし、意見をまとめずそのままにしたり、何を合意したのかを不明確なままにして他の人を悩ませることがあってはなりません。

プロジェクト参加者は、意見の不一致を建設的に解決することが期待されています。もしも合意に至らなければ、あらかじめ決められたリーダー仲裁を依頼し、透明性 (clarity) と指示を求めます

からないことがあれば手伝ってもらう

誰であっても、完璧であることを求められてはいません。誰かに質問することは、後で発生するであろう問題回避できるので推奨されます。ただし、適切な場所質問してください。質問を受けた人はすぐに反応し、手助けしてあげてください。

役目を降りるときには丁寧に

プロジェクトを離れるときには、与える混乱を最小限にするよう動くことが求められますプロジェクトから離れることを他の人たちに伝えて、離れる人が作業を中断した地点からほかの人たちが再開できるようにしてください。

リーダーシップ権威責任

我々は、実例議論と行動によって動かされます。新しく参加した人は、もしプロジェクト改善につながる新しい考えがあれば、ぜひ人々を率いて、行動を起こしてください。リーダーシップは、行動を起こすことだけで誰でも実践できます。その機会があれば、誰かの許可を待つ必要はありません。

トップから権限委任

プロジェクトに関する責任は「慈悲深い独裁者」を頂点として、そこから特定範囲について責任権限委任されたコミュニティカウンシル、その下にいるチームや委員会 (councils) 、個人委任されていきますコミュニティカウンシルまたはその代表者が、争いごとの解決を行います

我々は実力主義に基づいて、意思決定や統率、リーダーシップを、長く参加している人から能力があって関心の高い候補者委任していきます

権限委任は支持に基づくか評価されている

評議会 (boards) や委員会 (councils) への任命は、コミュニティカウンシルが決定権を持ちます。ただし、事前にコミュニティに対してインプットを求めるものします。

リーダーシップは、表彰権利肩書きではありません。リーダーシップ権限であり、そこには責任が生まれますリーダーシップコミュニティから委任されたものです。リーダー権限は、委任するコミュニティから支持されている間だけ得られるものです。

議論データと決定を尊重する

我々は何かものごとを決める前に、意見データ関係者から意見表明を集めますリーダー役割として、チームが決定を遅滞なく行う手伝いをし、ガイダンスを与え、合意に至らなかったときに決定をし、決定の実施責任を持つことが期待されています

何かを決めないことには、先に進めません。明確な指示には価値がありますときには、データが足りなかったり、合意が得られがたいこともあるでしょう。それでも、何らかの決定を下さなければなりません。いつでも完璧な決定を下せる保証などないのです。決定を先延ばしにするより、失敗して、失敗に学び、将来の役に立てることが大切です。

我々は、問題をより把握しているチームを信頼して決定を下してもらうことで、プロジェクトはよりよいものになると認識しています。もし決定に不満があれば、それを下したチームと調整します。調整が付かなければ、その決定についてレビューする統治機構 (governance structure) があります。つまるところ、責任を持つ人が決定を下し、それがプロジェクト統治 (project governance) に支持されていれば、その決定は有効であるします。我々はある決定について納得しないこともあるかもしれませんが、それでもプロジェクトを信用し、たとえ内心では違うほうがよいと思っていたとしても、プロジェクトとしてその決定が実施されることを支援します。

開かれた実力主義

誰であっても、どの組織所属していようとも、どのようにプロジェクトに関わろうとも、我々は参加を歓迎します。コミュニティは開かれたものであり、能力や適性を持っていることを示せれば、職責を負うことができます

チームワーク

リーダーが目指す最も重要なゴールは、チームの成功です。

「名演奏家はその演奏によって評価され、リーダーはチームの行動で評価される」リーダーは、行動すべき・身を引くべきときを知っています。チームは、リーダー権限を渡したりそれを取り戻すべきときを知っています

称賛

良きリーダースポットライトを浴びようとせず、他のメンバー活躍をたたえますリーダーはチームメンバーの中で目立つ存在しょうが、良きリーダーはその注目を他のメンバーの優れた活動に対してスポットを当てるために使います

度胸と考慮深さ

リーダーときに、理解されず、合意に基づかず、一般的ではない冒険的な決断を下す必要があります。我々は、完全な合意を得るよりも物事を進めることを優先し、勇敢にもそのような決定を下すことを評価します。とはいえ、冒険的な決断には十分な検討必要です。ある人にとっては頭の痛いことになるかもしれないことを肝に銘じ、影響を抑えるようにしなければなりません。変更について、その理由を明確にして、そして早めにコミュニケーションをとることは、その変更を実施するのと同じくらい重要です。

利益相反

もしもリーダー自身雇用関係や他のプロジェクトとの関わりによって利益相反状態になっている場合には、それに気がつくことが期待されています。そして、私利私欲のためとみなされることのないよう、棄権したり決定を誰かにゆだねたりすることが期待されていますリーダーに限らず全てのプロジェクトメンバーにも、私利私欲のためではなく、ユーザー暮らしをよりよくするために決定を下すことが期待されています

もしも利益相反が疑われる場合には、誰かにセカンドオピニオンを求めてください。利益相反状態にあることを明らかにすることが、解決への道筋にとって重要です。リーダーは、たとえ一般的ではない、あるいは特定グループに有利・不利となるように思われるものであっても、決定が信用できるものとなるよう行動すべきです。

このUbuntu行動規範は、網羅的でも、完全なものでもありません。ルールブックでもありません。協調的で共用の環境 (a collaborative, shared environment) とゴールに関する、我々にとっての共通理解を引き出すためのものです。

このUbuntu行動規範は、クリエイティブ・コモンズ 表示 - 継承 3.0 非移植ライセンスのもと配布されますあなた自身プロジェクトにこれを再利用することができます。また、好きなように改変することもできますが、あなたの改変を他の人が利用することも許可し、Ubuntuプロジェクト著作権表示を付けるようにしてください。

2017-03-27

動画を焼き付けるまで

動画をいったん動画ストリームと音声ストリームに分離しないといけない。

理由不明

音声ストリームはResampleしたいがどうやればいいのかいまいちわからなかったので

DecodeしてPcmにした。

そのあとまたまた音声はAc3でエンコードした。Muxするときコマンドに気を遣わされる。

なんかどうも細かい約束事があるようで、英語ブログと相当時間格闘した。

幸い動画部分のアスペクト比モダンだったのでよかった。4対3とかくそくらえや。

理由不明だが、使ってたREディスク部分的に損傷してるらしく決まったところで

動画が止まった。原辰から捨てたった。

BDでもVOBオーサリングできればいいだけのことやのに( ^ω^)・・・

なんでVOBやとあかんねん?

NB


レンタルビデオ営業時間結構おそくまでやってるんね

2017-03-07

smart rendering

smart rendering

エンコード無しにH264ストリームBDバーンするのは

結構障壁が高そうだ

http://bbs.kakaku.com/bbs/K0000348123/SortID=15138527/

どうせ再エンコードしなきゃいけないのなら別に

巨大ファイルoriginal H264 source)でもないし、

DVDディスクも余りまくって困ってるし、

mpeg2videoでええよな。

諦めよう

2016-12-10

トヨタ姿勢問題化してほしい

キュレーションの件でDeNACA炎上してるけど、似たような話でトヨタ自動車も相当に酷いと前々から思っている。

一昔前、ホンダが「ストリーム」というミニバンを出してヒットさせたことがあったが、トヨタはそのストリームとなんと全長全幅全高が全く同じ「ウィッシュ」というミニバンを出してストリームを見事に潰してしまった。そして今年、今度はスズキの「ソリオ」というコンパクトカーサイズ感やコンセプトをほぼ丸ごと真似て「ルーミー」「タンク」という車を出してきた。トヨタには圧倒的な販売力があるので、サクッと他社の後追い車種を出すだけであっさりとライバル駆逐できてしまう。

資本力を背景にしたモラルのない商いのやり方って、まんま今回のDeNACAの話と同じなのではないかと思う。トヨタ世界最大級自動車会社だし、ハイブリッドカー世界で初めて実用化して普及させたことなど本当にすごいなと思うポイントも沢山ある。でも、だからこそ「他社の売れてる車種を訴えられない程度に真似して、国内で小銭稼ぎしちゃおう」というDeNAパレットのようなズルい商売のやり方はいい加減やめてほしいと思うのだ。世界を引っ張る自動車会社なのだから、誇りを持って車を作ってほしい。

2016-12-02

この土日、格ゲー世界大会ネットで観戦する。

カプコンカップ(CC)2016が12月3日(土)、12月4日(日)の2日間開催される。

1年間を通して、世界中を飛び回って大会ポイントを稼いできた選手たちのうち上位32人の集大成

山あり谷ありだったけど、いよいよ年間王者が決まる・・・

開催地アメリカ カリフォルニア州

種目:ストリートファイターV

ストリーム配信https://www.twitch.tv/capcomfighters

日本時間 12月3日(土)03:00~ | 32人から8人まで絞り込むトーナメント開始

日本時間 12月4日(日)11:30~ | Top8でのトーナメント開始

トーナメント方式:3試合先取 ダブルエリミネーション

参加予定者[国 / メイン使用キャラ]

INFILTRATION:[韓国 / ナッシュ] 累積ポイント1位。EVO2016優勝、他プレミア2大会優勝。シーズン初期から無類の強さ。も、シーズン後半から追い上げられ気味。

Humanbomb:[香港 / 春麗] アジアランキング大会で安定した成績を残す。

Luffy:[フランス / ミカ] 2つの欧州ランキング大会を制す。EVO2014優勝者

マゴ:[日本 / かりん] アジア地区優勝スト4オンラインポイント最多。スト5では強豪集まるアジア大会での優勝が印象的。

MOV:[日本 / 春麗] アジア地区2位。ランキング大会優勝4つ。現時点の春麗では最強か。

Brolynho:[ブラジル / ネカリ] 南米ランキング大会で2度の優勝。

ウメハラ:[日本 / リュウ] ストリートファイター3rdの連続ブロッキング動画世界的に有名。今シーズンは後半の伸びが目覚ましい。が、対ガイル戦に不安が残る。

K-Brad:[アメリカ / キャミィ] 南米地区決勝大会で準優勝。他大会でも安定した成績を残す。

NuckleDu:[アメリカ / ガイル] 若手の注目株。プレミア2つ優勝。さほど警戒されていなかったガイルへの対策研究が、この選手存在の脅威により巷で促進される。

XsKSamurai:[アメリカ / リュウ] 印象として少ない北米リュウ使い、の強豪。

Xian:[シンガポール / ファン] 初期はなかばネタ扱いだったファンというキャラ開拓した、現状最強のファン使い。

ChrisTatarian:[アメリカ / ケン] 若手ケン使い。2つのランキング大会で優勝。

Xiaohai:[中国 / キャミィ] ノッてる時は誰にも止められない最強キャミィ使い。2つのプレミア大会を制す。ESL優勝者

ProblemX:[イギリス / アレックス] 欧州ランキング大会で上位成績残す。CC唯一のアレックス使い。

ももち:[日本 / ケン] EVO2015CC2014優勝者。最強ケン。耐えるケンプレミア優勝者。他プレミア大会でも上位成績残す。ESL準優勝。

MisterCrimson:[フランス / ララ] 欧州強豪。ランキング大会で上位成績。CC唯一のララ使い。

ときど:[日本 / リュウ] 現時点リュウでは最強との呼び声。北米地区決勝でNuckleDuのガイルに敗れ2位。プレミア大会で常に3位以上という驚異的成績。

DRRay:[ドミニカ / バルログ] 南米地区決勝で優勝。CC唯一のバルログ使い。

えいた:[日本 / ケン] ももち選手とはスタイル対照的とも言われる、暴れ型のケン使い。法律事務所ほか3社からスポンサードを受けCCに挑む。

GO1:[日本 / 春麗] 過去ストリートファイターシリーズ以外の格闘ゲームで結果を残してきたプレイヤースト5でも今シーズン大会で上位成績残す。

GamerBee:[台湾 / ネカリ] 現状最強ネカリか?シーズン後半から頭角を現し、プレミア大会を立て続けに制す。

RickiOrtiz:[アメリカ / 春麗] アメリカ強豪春麗北米ランキング大会で安定した成績残す。

JulioFuentes:[アメリカ / ケン] 強豪ケン北米ランキング2つ優勝。

ゆかどん:[日本 / ナッシュ] EVO3位の強豪ナッシュアジアランキング大会でも上位成績。

JustinWong:[アメリカ / かりん] ウメハラ背水の逆転劇の相手だった選手。スト5でプレミア優勝はないものの、7つのランキング大会で優勝している実力派。

sako:[日本 / 春麗] シーズン後半からついに覚醒か。EVO2016でINFILTRATIONに完敗も、後の大会で見事に雪辱を果たす。コンボの鬼。

ハイタニ:[日本 / ネカリ] アジア地区決勝3位。プレミア優勝逃すも常に上位成績。

FilipinoChamp:[アメリカ / ダルシム] 唯一ダルシム。2つのランキングで優勝。北米南米で上位成績残す。

ふ~ど:[日本 / ミカ] 最強ミカ使い。不利な状況でも、一瞬のチャンスを与えられれば一気に戦況をひっくり返す実力を持つ。EVO2016準優勝。

RyanHart:[イギリス / ケン] ストリートファイター関連ギネス記録を複数持つ。スト5ではシーズン大会優勝は逃すも安定成績。

Phenom:[ノルウェー / ネカリ] シーズン初期にプレミア優勝。欧州決勝準優勝。プレミア大会カナダカップでも3位、と上位で安定した結果を残す。

かずのこ:[日本 / キャミィ] CC2015優勝者今シーズンアジアランキング大会で上位成績残す。

以上32名で鎬を削る

種目:2016年からストリートファイター5。前年はストリートファイター4。新作に伴い種目が変更になっている。

大会:年間70大会以上。世界各地で開催された。ランキング大会プレミア大会がある。順位に従ってポイントが加算される。

ポイントグローバルポイントリージョナルポイントがある。累積ポイントカプコンカップ(CC)と地区決勝大会への出場権に直結。

EVO:シーズン半ばにある中間決算的な大会。長い歴史が有る。巨大オープントーナメントで、数日を掛けて戦う。EVO2016のスト5部門では5000人が参加。

プレミア特別指定された一部の大会では、優勝すると累積ポイント関係なくカプコンカップへの出場権を直接獲得できる。優勝は通常のランキング大会より厳しい。

地区決勝大会:各プレミア大会の一つ。地区決勝大会への出場にはリージョナルポイント必要

もう誰が優勝してもおかしくない状況。

1日目が日本時間午前3:00からなので最初から見ることは出来ないけれど、

2日目は11:30~14:30なのでガッツリ観たい。

2016-10-17

How the Textsecure Protocol (Signal, WhatsApp, Facebook, Allo) Works

http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か?主語が全部theyという支離滅裂英語なんだが。

----

TextSecureの目標は「経路末端までのセキュリティ否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。

以下にSignal Protocolの批評分析を羅列してある。実装構造研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているか評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。

用語

TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コード文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。

ただ実際には数々の異なるものが含まれている:

構造

TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話ハンドシェイク必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイク遂行しなければならないというのであれば、ユーザ体験はひどいことになる。

そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。

暗号

TextSecureは暗号学の基礎のほんの一部を使うものである公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である

ダブルラチェット:

TextSecureの暗号化エンジン中心部はAxolotlダブルラチェットアルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。

受信ラチェットメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化メッセージ認証に使う対称鍵の生成に用いられる。

送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。

ここで注目すべきは、メッセージ送信するために送信者が待つ必要は一切ないということだ。いつでも送信第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイスのものであっても、過去送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)

プロトコル

フェーズ1: TextSecure登録

登録は、クライアントに言って、連絡用の電話番号サーバに教えてもらうことから始まる。また同時に、トークン通話SMSどちらで受け取りたいか希望登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報登録できるようにしてくれる。

クライアントメッセージ認証暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。

また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。

他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。

クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントSMSを受け取りたいかデータだけにしたいか情報も含まれる。

フェーズ2: 鍵の比較

TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリント比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。

フェーズ3.1: 最初メッセージ送信

送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報ルート鍵と呼ぶ。

このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化MACの鍵を生成するのに使われる。

最後AESカウンター初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターメッセージ送信ごとに増える一方で、pctrカウンターは、最後既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。

これらを使って相手メッセージ暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイク完了できるだけの必要情報が含められている。

SignalサーバGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージ送信元を知らずにいることが保障される。

フェーズ3.2: メッセージ受信

信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイク完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。

フェーズ4: 追伸メッセージ送信

相手が返信する前に、もとの送信から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。

フェーズ5: 返信の送信

信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化認証の鍵を得る。これを使ってメッセージ暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。

既知の問題

鍵の提出

TextSecureは、サーバクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロード認証する。これは送信メッセージ認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージ送信も鍵アップもそのユーザなりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップデバイスSDカードに置かれていたので、他のアプリから読むことができたのだ。

この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティ問題ではなく、現実問題であり、それに対する後ろ向きな対策なのである

未知の鍵共有 (UKS) 攻撃

この攻撃は偽配送一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃から別の人(標的)へのメッセージとして送信される。

これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分公開鍵を、標的の公開鍵に変えればいい。これは自分電話番号を再登録すればできる。送信者はQRコードを使って、相手フィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである

それから、今度は送信者のアカウントを再登録して、その検証SMS確認通話送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージ送信できるようになる。

この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。

できることがあるとすれば、送信者と受信者の双方がメッセージ暗号化された本文内で言及されるようにすることなどだ。

目標達成率

TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破限定的時間範囲しか有効でないとする。新しいラチェットのそれぞれに公開鍵必要であることから、これは達成されている。

完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイスにのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットステート対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェット使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージ暴露である

否認性(アリバイ)はさらあやふやだ。ある特定メッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバ認証メッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。

Sources

Analysis Whitepaper:

http://ieeexplore.ieee.org/document/7467371/

Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/

Posted by Alexander Kyte at 11:47 PM

2016-10-03

かつてHTTP自体疎結合だった

HTTP最初、 「GET /file.html」の形式しかない疎結合だった。そのため誰でも簡単実装することができた。

HTTP/1.0、HTTP/1.1 となるにつれ、メドッドが増え、関連技術も増えていった。

HTTP/2 にいたってはパイプラインリソース結合、ストリーム多重化、フロー制御といったすげー複雑な仕様が増えた。

こんだけ複雑になったのは何かの陰謀だと思う。

2016-05-25

http://anond.hatelabo.jp/20160525213232

バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ?

第一に、それは、ストリームFRPの値の定義)の問題であって、ユニットテストすれば良い。もしくは単にFRPログを取れば良い。

グローバル変数ではそういうことはできない。FRPでは、岡部氏のFRPライブラリ特にそうだけど、基本的ミュータブルな値同士が関数リアクティブ連携されて常に整合性を保っているのだからグローバル変数の、各所で更新されたそれぞれの値によって全体の整合性が損なわれないように気を配らなければいけないという(テスト自体困難な)問題は発生しない。それがFRPの唯一とも言えるメリットだとも言える。

使用する関数問題じゃないし、「印」として引数に加えても別に構わないと思うが、君のいうグローバル変数問題と一緒というのはまったく違う。

岡部氏との争いって「OCamlGUIアプリ純粋関数型(状態渡し)で簡潔に書けるか」ってところじゃないよね?

いや、それがそもそもの発端であるブログの経緯には書かれている。説明されている方式GUIアプリまで書けるのか?と疑念が呈されたことがきっかけ。

岡部氏はFRP状態関数の外部に持ってても純粋関数型だ、と言ってて、そこで争ってるんだよね?

この論点は聞いたことがない。岡部氏がこだわっているのは非手続き型の宣言型で、純粋がどうとか議論はされてないように思う。

あと、OCamlGUI状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね?

原理的に可能かという議論ではなく、実用的な範疇か?という議論。反対派ブログで出てきたコードは、本人が認めるように普通のやり方ではなく、実用的なコードだとは思えない。あと、FRP状態渡しは同じ複雑さだという主張も崩されている。そこが重要

Haskellで書けて、OCaml冗長になっても、書けるなら「書ける」、「可能」だよね?

段階を踏んだ上で、非FRPHaskellのIOモナドコードを誰かが書いたらいんじゃない?当面、最初OCamlの話だったのに、いきなりHaskellやElmのコードで書いて、そういうのがごちゃまぜに、何がどの言語でできるのかできないのか、誤魔化しがあると見做されたか制限されたんでしょ。実際には、OCaml関数型では冗長しか書けないと実証されたけど、そういうのがバレないように、別の言語を利用していたと看破されて当然の状況だと俺は思うね。

俺の書き込み他人といきなり結び付けられたから、電波だな、と思ったの。

俺1人か、とか、らくだや住井が含まれてない根拠とか、関係無いよね。

関係ある。君ひとりは、そうじゃない、と君ひとりが言ってもそれが本当だとは確認のしようがないし、

書き込みをみれば、君以外の書き込みもすべて、その一派ではない、とでも言いたそうだ。

http://anond.hatelabo.jp/20160525202812

否。ストリームに限らず、定数は引数で与えなくても純粋関数である、という見解はごく普通

定数って、プログラム中で更新不可能で、いつ読みだしても同じ値が出てくるからグローバルでも問題無いんだよ。

ストリームは定数だ、って言ってみたところで、プログラム全体から更新可能なんじゃ、グローバル変数と同じでしょ?

バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ?

なんで伝わらないんだろ。

複数人プログラム開発したり、他人プログラムデバッグしたり、したこと無いんだろうか。

まりGUIになればもはや関数型では書けない、というのが推奨スタイルだ、って言ってるようなもの

純粋関数型」とは何か、という話と、とOCamlでそれが推奨スタイルか、って別の話だよね?

岡部氏との争いって「OCamlGUIアプリ純粋関数型(状態渡し)で簡潔に書けるか」ってところじゃないよね?

純粋関数型とは何かといった時にHaskellのように、IOも含めて引数戻り値表現する、関数のふるまいが関数の外の状態依存しない、関数副作用が伴わないとかの性質をいうと思うんだけど、岡部氏はFRP状態関数の外部に持ってても純粋関数型だ、と言ってて、そこで争ってるんだよね?

あと、OCamlGUI状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね?

Haskellで書けて、OCaml冗長になっても、書けるなら「書ける」、「可能」だよね?

その発言事実か確かめる術はないし、ここで岡部攻撃しているのは君ひとりなのか?他の人間まで一連の誹謗中傷集団ではない、す駱駝、住井が含まれていないみたいに断言する根拠は何か?

俺の書き込み他人といきなり結び付けられたから、電波だな、と思ったの。

俺1人か、とか、らくだや住井が含まれてない根拠とか、関係無いよね。

http://anond.hatelabo.jp/20160525104221

ストリーム関数の外部に持つFRP純粋関数型っていうのは少数派でしょ。

否。ストリームに限らず、定数は引数で与えなくても純粋関数である、という見解はごく普通

http://stackoverflow.com/questions/37405262/is-this-pure-functional-using-a-value-in-the-nested-closure-like-function/37405374

OCamlの元々の推奨スタイルならもっと短く書けるんでしょ?

まりGUIになればもはや関数型では書けない、というのが推奨スタイルだ、って言ってるようなもので、OCamlベースいくら関数型の講義やっても、最終的にはその関数型でまともなGUIアプリすら書けない、という批判でしょ。その批判岡部からされたら、あたか関数型で書ける、という強弁からまれたのが「状態渡し」理論。それが無理筋だ、ということが今回実証された。

だって駱駝でも住井でもない面識も無い俺の書き込みが住井扱いされるんだもの

その発言事実か確かめる術はないし、ここで岡部攻撃しているのは君ひとりなのか?他の人間まで一連の誹謗中傷集団ではない、す駱駝、住井が含まれていないみたいに断言する根拠は何か?

いやだからグローバル変数使ってるプログラム欠点をそのまま持ってるじゃん

あのね、グローバル変数欠点とは、それが「変数」だからなの。

何度も言うけど、「定数」ならグローバルだろうがなんであろうが、そんな欠点なんてないの。

http://anond.hatelabo.jp/20160524164501

関数型という枠組みの中にミュータブルな時間要素が純粋に収まるようにしているのがFRPだろ。

ストリーム関数の外部に持つFRP純粋関数型っていうのは少数派でしょ。

関数の結果が引数以外で決まるわけだからさ。

多分、純粋とかの定義もまた違うんだろうね。

関数型の拡張」で全部丸く収まると思うんだけど。

いやそもそも岡部氏が複雑なアプリになるとFRP必要

これはGUIアプリ(対話的なアプリ)ってことでいいのかな。

コンパイラだとかをFRPで書かないでしょ。

ユーザから入力リアルタイムに処理するプログラムにはFRP有効だよね。

事実、「駱駝」は「状態渡しはむしろ異常」って書いた上に、

OCamlでは」じゃないの?

全部純粋関数型(引数戻り値に収める、状態渡し)にするのを良しとするHaskellと違って、OCaml副作用部分的に使うのが普通で、IOモナドみたいな入出力までも純粋に書くための道具立てが揃ってない、それでちょっと冗長になる、ってことでしょ?

OCamlの元々の推奨スタイルならもっと短く書けるんでしょ?

俺はそう読んだけど。

それっぽい書き込みほどそうやって、事実誤認だ、と強調するから、なんで当事者でもないのに、そんなことが断言できて、電波だということになるんだ?

だって駱駝でも住井でもない面識も無い俺の書き込みが住井扱いされるんだもの

いやだから、どの関数で読み書きされようと、誰が書き換えようとも、時間にたいしてイミュータブルな定数なんだから、定数は定数なのよ。

いやだからグローバル変数使ってるプログラム欠点をそのまま持ってるじゃん

グローバル変数使ってるプログラム欠点説明する必要ある?

2016-05-24

http://anond.hatelabo.jp/20160524161137

拡張なら「関数型的じゃない」っていわれたら「関数型を拡張してるから」って答えればいいだけの話

関数型という枠組みを拡張しているのではなく、関数型という枠組みの中にミュータブルな時間要素が純粋に収まるようにしているのがFRPだろ。「関数型を拡張してるから」というのは、また独自拡張だ、という批判を許すし、FRP関数型の拡張だというのは誤解を招くし、語弊もある。

FRPの効力を否定なんて誰もしてない(よね)

いやそもそも岡部氏が複雑なアプリになるとFRP必要だ、と批判すると状態渡しで充分だ、という反発があった。それが誤魔化しだとして、今に至るし、否定されているから一連のブログでの徹底的なまでの反撃がなされている。

「これが正しい関数型でお前らの状態渡しは間違ってる」みたいに言うから荒れる

事実、「駱駝」は「状態渡しはむしろ異常」って書いた上に、岡部氏のコードの倍の分量の複雑なコードしか示せなかった。あの無理して書いたのが第三者にもまるわかりの状態渡しの実装って間違ってるんじゃないの?

個人的電波だと思うのはこういう匿名書き込みを住井だ駱駝だ言い出すところ

これまでのアンチ岡部のやり方を眺めていると、被害者岡部氏の分析には一定の信ぴょう性が認められるよね?

しかも、それっぽい書き込みほどそうやって、事実誤認だ、と強調するから、なんで当事者でもないのに、そんなことが断言できて、電波だということになるんだ?という素朴な疑問がある。当事者から否定してるんだろ、と誰が見てもおもうだろ。

ストリームから定数とか、過去の値保存してるから定数とか言ってみたところで、プログラム内の色んな関数から読み書きされる可能性があって誰が書き換えたか中身読まないとわからないんじゃ、グローバル変数使ってるプログラム欠点をそのまま持ってるじゃん

いやだから、どの関数で読み書きされようと、誰が書き換えようとも、時間にたいしてイミュータブルな定数なんだから、定数は定数なのよ。

グローバル変数ってのはFRP関係ないだろ?

http://anond.hatelabo.jp/20160524151555

FRPライブラリサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか?

拡張なら「関数型的じゃない」っていわれたら「関数型を拡張してるから」って答えればいいだけの話

すでに出たサンプルからFRPの効力がまざまざと見せつけられている。

FRPの効力を否定なんて誰もしてない(よね)

「これが正しい関数型でお前らの状態渡しは間違ってる」みたいに言うから荒れる

間違っている電波

個人的電波だと思うのはこういう匿名書き込みを住井だ駱駝だ言い出すところ

いやだから、定数なんだから書き換わらないんだよ、FRPストリームconst 定数なんだから

ストリームから定数とか、過去の値保存してるから定数とか言ってみたところで、プログラム内の色んな関数から読み書きされる可能性があって誰が書き換えたか中身読まないとわからないんじゃ、グローバル変数使ってるプログラム欠点をそのまま持ってるじゃん

http://anond.hatelabo.jp/20160524145224

よーわからんw 岡部氏は、自作ライブラリHPで、

FRP純粋理想とする関数型+時間で変化するストリームを値にマップして扱うリアクティブプログラミングの組み合わせ

まり関数型の拡張っていうなら誰も反対無いと思うんだけど。

FRPライブラリサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか?

https://www.npmjs.com/package/timeengine

HaskellのIOモナドみたいな別の抽象化DISりつつ、FRPこそ正しい関数型みたいに言うから荒れるんじゃないの?

IOモナドDisってるのかどうかまでは知らない。しかし、すでに出たサンプルからFRPの効力がまざまざと見せつけられている。

荒れるのは自由だけど、両方正しいとかそういうのじゃなくて、間違っている電波だみたいな叩きしかなくて、要するに感情論で反対派は反発しているだけでOK?

あるよ。

関数がどのパラメータ依存して、何を結果として返すのか明確になる。

グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。

短いプログラムならそれでもいいけどね。

別の誰かが書いてたように、上位スコープ内に定義されてるDOMでも、数学ライブラリでもなんでも、引数関数に渡すのか?

グローバルな値を参照したり書き換えたりして

いやだから、定数なんだから書き換わらないんだよ、FRPストリームconst 定数なんだから

関数型のわかりやす説明であって、住井派に反対してるとか、岡部路線とかじゃないよね、と。

オブジェクト指向と対比して考え方をまず学ぶって岡部路線、住井グループはそれを目の敵にしていて集団的攻撃している様をみたプログラミングコミュニティは逃げ、その後、不毛な大地のみが残った。

http://anond.hatelabo.jp/20160524142313

FRP純粋理想とする関数型+時間で変化するストリームを値にマップして扱うリアクティブプログラミングの組み合わせっていうなら、別に誰も反論しないと思うけど。

まり関数型の拡張っていうなら誰も反対無いと思うんだけど。

HaskellのIOモナドみたいな別の抽象化DISりつつ、FRPこそ正しい関数型みたいに言うから荒れるんじゃないの?

全部の時間依存関数にそういうことをする意味はない

あるよ。

関数がどのパラメータ依存して、何を結果として返すのか明確になる。

グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。

短いプログラムならそれでもいいけどね。

初心者からFRPのことまで考えてないんだろう。

関数型のわかりやす説明であって、住井派に反対してるとか、岡部路線とかじゃないよね、と。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん