  |
はてなキーワード: メタデータとは
大体の場合において「bashが欲しい」という人はbashだけではなくgrepやawkやその他諸々のgnu ツールもまとめて欲しているが、それらを合わせてもwindows上で使うPowershellには機能レベルで遠く及ばないし、windows上のbash単体はLinux上のPowershell単体にも劣る。
Powershellでは、「文字列しか通さない古いパイプを通して文字列を切り貼りして受け渡しながら処理をする」なんて面倒なことはない。
bash+gnuツールだと別コマンドで文字列切り貼りしなきゃ取得できないメタデータも、Powershellならパイプでオブジェクトを渡せるから始めからオブジェクトのプロパティとして付いてくる場合が殆どだ。
windows上なら.net経由でシステムの様々な部分へのアクセスも可能だし、COMObject経由でofficeソフトそのものを直接操作もできる。
サードパーティーのモジュールで無理矢理データを弄るんじゃなくて実際にofficeファイルを吐くプログラムそのものをPowershellから操作できる。
なので、Powershellの記事によく付く「こんなのよりbash(+gnuツール)使いたい」ってのは「LinuxでPowershell使いたい」って言ってるようなもんだって分かって欲しい。
windows上においてはbashはPowershellの肩代わりは出来ない。
少し前からLinux上でPowershell動くようになったけど、LinuxユーザがPowershell一から学ぶ価値あるかと言われると、はっきり言って「あんまり無いかな」とは思う。
azure関連のコマンドモジュールがPowershellしかないヤツもまだあるみたいだから、azure触るためだけにwindows用意しなきゃならない事態を防ぐ程度の意味合いしかないような気はする。
そういうモジュールがLinux上のPowershellに対応してんのか知らんけど。
WSLでLinuxが丸々windowsに取り込まれたおかげでカジュアルなwindows上のbash需要も殆どは満たせる時代になったのは良いことだ。
別にPowershellのことを詳しく調べろとは言わないが、bashじゃwindows上のPowershellの肩代わりは出来ないって事だけは覚えておいて欲しい。
ブコメが 5 つくらいついているがまだどれにもスターがついていないとき、最初につけるのを躊躇ってしまう。
人気コメントタブにひとつだけ表示され、他のコメントが見られにくくなる。じゃあいくつかつけるかとなるとそれは違うじゃん。
増田ブクマは待っていれば星がつくのでその後に来れば良いが、ブックマークとして使っている人が多いジャンルではそもそも星をつけ合う文化が無い。でもグッとくることはある
人気コメントがある程度の数になるまでは、一覧も一緒に出してくれないかなあ。いや、そもそもタブで分けるのなんでだ。人気コメント入りしたものに星が集中しがちなのを問題視していたのに。星が多いコメントをいくつか表示したすぐ下から一覧を表示すればいいのに。ページを短くして脱力クリック狙いたい広告見せたいという気持ちが出すぎて、健全なコミュニティーを仕組みで構築する気が無いのだろう。
脱線した。まああまり考えずにつけたいものだけにつけちゃう方が今後つけやすくなるだろうし、そうすべきなのだろう。結構長らく悩んでしまっているがために、ファーストスターのことを考えるたびに古い歌が浮かんでしまうのだ。
しがないソフトウェアエンジニアしてるけれども、今の会社含めて業界全体的でリモートワークが定着しそう。というか、今の賃貸がク○過ぎて、自宅作業が苦痛。引っ越しを考えるも、「新建築」に載るような集合住宅に住んだ時期を想起しても、この国の賃貸のクオリティーはあまり高くなさそうであり、人生で初めて不動産購入を検討中。
現在都内でも比較的小さな店が多い中央線沿いの街住みで、引越し先は賃貸ベースならば1年ぐらい前から中目黒を検討していたが、物件を買う=10年ぐらい住むとなるともっと自然が多い街に行きたいみたいなところ。
ひとまず中古マンションの購入を検討をしているが、驚くほど非効率な作業を強いられるので誰かにこの不満を共有したい。
マンションは内装部分はいくらでも変更可能なので、正直部屋の写真とかはどうでも良い。寧ろ、「マンションの躯体・構造」「管理組合」そして「街の将来性」に関する情報を知りたい。これらは相当程度データで表現出来ると思われるところ、suumoなりhomesなりを見ても絶望的にそれらの情報が記載されておらず、なんとなく良さそうな物件を見つけては不動産仲介業者との膨大でかつ不必要なコミニュケーションを強いられる。そのわりに不動産仲介業者が提供する新しい情報は殆ど皆無だったりする。
例えば、このようなデータを見たいが(意外と)標準的に容易に閲覧可能となっていない。
◎「管理組合」
↑ 一部のマンションではこれらの大部分の情報が [マンション管理ネット](https://www.mirainet.org/) で見られる
◎「街の将来性」
...
...
正直これぐらいのデータがあれば、今すでに標準的に表示されているデータと合わせ、知らない街の知らないマンションでも短時間で相当程度その価値を見極めることが出来ると思う。
とはいえ、なんだかんだ解体計画・管理組合電子化に関する情報・住民のnpsが分かれば良い気もしている。
・解体計画 → そもそもスクラップアンドビルドのノリで作っているのに解体計画が無いのが良く分からないが、これがあれば竣工時の情報・修繕の想定・リスクの想定などマンションの躯体・構造に係る必要な情報が組み込まれている可能性が高い。また、物件を評価するときに、解体計画に基づいて実質的な経過年数を評価出来る手法もあり得る。
・管理組合電子化に関する情報 → 結局知りたいのは管理組合のコミニュケーションのあり方。区分所有法に基づき総会議事録を電磁的記録で作成するのは難しそうだが、議決権行使は電磁的方法がOKだし、その他管理組合アプリみたいのも幾つかあるので、ある程度管理組合は電子化していて欲しい。ここが電子化されていないと、老人が多いか、コミニュケーションのコストが高そうなイメージを持ってしまう。 あと、国交省が言うような100年マンションがあったとして100年後に紙資料が保存されているのか、疑問がある。
・住民のnps → npsを細かく取ればその自治体についてある程度は分かりそう。特に、街の中長期的な発展には新陳代謝が重要そうなので、若い世代のnpsを知りたい。「住みたい街ランキング」とかどうでも良い。appstoreでアプリをダウンロードするときに知りたいのは、ダウンロードした人のレビューであって、これからダウンロードするかもみたいな人の意見ではない。
ただ、この3つが明示的に分かる場合は少ない。なので、結局仲介の人に連絡をし、実際に物件を見に行かなければならない。そしていろいろコミニュケーションするが、結局良く分からないままになりがち。契約交渉をすると分かることもあるらしいが、ただ情報を知りたいためだけに毎回契約交渉したくない。
一方で、これらの情報が今のマンション価格には組み込まれていない可能性もあり、知識と時間があれば良い物件を探せるような印象もある。今の日本のマンションの中長期的に支配的な価格決定条件=「駅近xx分」と「ブランド」に収斂しているように見受けられるので、諸外国マンションの価格決定を想像するに、多分価格に組み込まれていない情報は多いのだろう。不動産テックの人ってどんなことをしているのだろう。
その他雑感:
・鉄鋼の強度が上がったからか、最近の東京の新築マンションはファサードの曲線やコーナーサッシが大胆だったりしてカッコ良いの増えてきた。駅・商業施設直結系も良い。けど絶望的に手が届かない。イギリスではマンチェスターが再開発成功しているらしく、日本の地方都市にもこのような流れが普及することを期待したい。
・中古物件のデータがより可視化され、中古物件の売買が容易になることで、仲介業者の手数料収入は多くなる筈だが、何故日本の仲介業者はその方向性でロビイングをしないのだろうか。結局ここが分からないということは、まだ自分は不動産の闇を知らないのだと思う。
・築40~50年で誰が買うのだろう?みたいな物件でも管理費・修繕費が毎月数万円掛かる。これを誰も買わなかったらどうなるのだろう。ただ、同築年数で自分が手が届かないような金額帯の物件も案外ある。しかもデータがあるここ5年ぐらい価格が下落していないことが多い。ババ抜き怖い。
・新国立競技場建設時に立ち退きを迫られた築40~50年物件の住民を思い出す。確かに、良エリアなところには昔の人が何も考えずに建てた中途半端なマンションがありがち。そしてそのせいで街の流れが悪くなっているし機会損失が発生している可能性もある? 住民間の公平性の観点から、東京オリンピック関係なく、良エリアの中途半端なマンションの住民には躊躇なく立ち退きを迫るべき。
・つくづく新幹線は凄いと思う。初期の設計思想が優れているから、次の時代でも進化を遂げている。それに比べて日本のマンションはどうなのだろう。あと、新幹線は満州国での経験が色々生かされているらしいが、同様の経験が活かされているらしい〇〇ニュータウンは。。。
・結局税金で解体されるマンション増えてきそう。責任を次の世代にまわす日本人の思考回路を感じ始めている。もうこういうゲームは自分たちの世代で止めたい。
・幾つか物件を見たが、中古マンションをどんなにリノベしても数年後の販売価格はシビアになりそう。まして、金融機関の担保評価はリノベに掛けた費用など考慮しなさそう。数年後に残債以上の販売価格で買主と合意できても、買主にローンつかないこともありそう。欧米の金融機関の担保評価ってどんな感じなのだろう。
・都市計画を定めるときの地権者の意見の強すぎ。x年後にその土地で住む人、働く人は潜在的に皆利害関係者なのでは。x年後に地権者はそこに土地を持っているのだろうか。今すぐ土地を高く売りたい人による、今すぐ土地を高く売りたい人のための、今すぐ土地を高く売りたい人の都市計画で作りましたみたいな街が多すぎ。
・自分の生活は都心を思ったほど必要としていなかった。結局都心に毎日行っていたのは仕事の必要性が90%ぐらいだったようだ。ロンドンのハイドパークやリージェントパークみたいのが都心に無いのが残念。南池袋公園とかもっと頑張ってほしい。
・というか、リッチモンド公園みたいな公園が郊外にあって欲しかった。〇〇ニュータウンはそのような公園に出来る可能性はあったのでは。となりのトトロを見て何故か作成者の静かな怒りを感じた記憶がある。だからこそ、これまで〇〇ニュータウン出身者であることを恥じていたのだろうか。
・ミラノのBosco Verticaleみたいな建築家駆動のマンションプロジェクトってどうやって調べたらよいのだろう。日本のマンションは基本デベロッパー駆動なのだろうか。六甲の集合住宅とかは建築家駆動っぽいが。
・中古自動車の購入も検討しているが、ここまでババ抜き感は無い。というか、細かい性能やデータが分かるし、価格の妥当性・説得力がある。この違いは何?
・2軍の試合で良いので、車で球場に行ってみたい。何かアメリカ映画っぽい。あと、コストコが凄いらしい。一回も行ったことがないけれど。
・ひとまずこの苦難を乗り越え、沢山の知識をつけて、x年後に眺望の良いエリアに一人暮らし用の注文住宅を発注したい。
最近のアプリケーションのデザインは、「ユーザーが今、（詳細レベルで）何をしているのか」を隠蔽するようにできている。
たとえば、多くのスマートフォンアプリでは、端末内のデータを閲覧する際にディレクトリ構造をユーザーから隠蔽するように設計されている。
UNIX系システムに慣れ親しんだ者にとっては、こういったUIは非常に使いにくいと思う。たとえば、ディレクトリでカテゴリー分けをしている場合、ファイルの種別や作成日時等で勝手にまとめられると、分類に意味がなくなる。また、特定のアプリケーションで作成されたタグ等のメタデータは、他のアプリケーションでは意味を成さない。
これ以外にも、多くのアプリケーションでは、過剰なほどデフォルトの動作が定められており、手続きが原理的に決定できないような動きをする。喩えるなら、宛先を書かなくても手紙が届くようなものだ。最初の一人に出す時は問題ないが、少し進んだユーザーは、別の人に手紙を出す時にどう操作したら良いのか迷うことになる。
エンドユーザー向けのアプリケーションであればこれでも良いのかもしれないが、Windows10のネットワークとかデバイスの設定のような、そもそも詳細に設定したい時しか開かないようなものまで、簡易な設定画面が用意されている。非常に困ったことだと思う。
婚活を開始してある程度の期間が経過したので、情報をまとめておく。
ネット上で一方的に存じ上げているプログラマの方が「オミカレ」に転職した。それによって「婚活パーティ」というものが存在することを知った。
ttps://party-calendar.net/
その方がすごく楽しそうに仕事をしているのを見て、自分も婚活パーティに参加してみるか、と思うようになった。自分が諦めていた結婚というものも、まだ可能性があるかもしれないと考えた。
※こういったものに限らず、同業者の人が「面白い」と言っているものは自分にとっても面白いことが多いのである。その最たる例がゲームと漫画。
数々の下調べを踏まえた結果、婚活パーティに参加してみることにした。
事前の準備として、以下のことを実施した。
いざ意を決してパーティに申し込んだところ、前日の夜中に電話で「パーティはキャンセルになった」と言われた。明言はされなかったが、どうやら女性に比べて男性が多過ぎたのだろう。ここから得た学びは「直前に申し込むと、はみ出る」ということ。
前回の学びを生かして次に申し込んだパーティでは、実際に参加することができた。開催は土曜日の昼。8対8のパーティ。全ての女性と5分間程度会話できるものだった。普段の顧客折衝の仕事と同じ要領で話を聞き、こちらのことも喋ったりして手応えを感じたものの、誰ともマッチングせず。喋り方、容姿、学歴、収入、趣味、どれがダメなのかは不明。
自分の何がダメなのかわからないまま、2回目のパーティに参加することに。土日開催とは違う参加者層を期待して、平日の夜のパーティに参加してみた。6対6だった。ここではマッチングすることができて、とても嬉しかった。しかし、この方とは2回のお食事デートの後、3回目(年末年始)を前日キャンセルされてしまった。その後、次の回の日程調整を進めるものの2ヶ月間ほど全て無理と言われてしまったため、フラれたと判断。
次は土日開催のパーティに参加。8対8。ここで、2回目のパーティでマッチングしてフラれた方と再会して気まずい雰囲気に。
それはさておき、他の人ともマッチングすることは無くて、ここから「趣味が合うこと」が重要であることを推測し始めた。そう考えると、1回のパーティに参加して会うことのできる8人程度の女性の中から趣味の合う人と出会うのは相当に難しいのではないかと考えた。
もっと多くの候補者の中からお相手を見つけるのが良いだろうと考えた結果、結婚相談所を利用することを考え始めた。最初に行き着いたのは、これまでに参加した婚活パーティの一つの主催者でもある、恐らく最大手であろう「IBJ」が運営している「日本結構相談所連盟」だった。
この連盟に加盟している、近所の結婚相談所のWebページの様子を見に行ったのだが、ここで立ちはだかったのが、学歴の壁。
観測できる限りにおいて、IBJ加盟の全ての結婚相談所にて、会員登録するには短大・高専以上の卒業証明書が必須なのだ。おそらくIBJ本体の方針なのだろう。筆者はいくら入学試験の難しい大学に入ったとは言っても中退なので、このIBJの基準では高卒扱いなのだ。幸いにして、筆者は通信制の大学に編入して経営学を学び始め、2年後には卒業見込みであるため、2年後の時点でも結婚の目処が立っていないのならば結婚相談所のお世話になろうと考えた。
女性の立場になって考えれば、卒業証明書の提出を求めるような相談所じゃないと、高いお金を払いながら安心して婚活するのは無理だというのは筋の通った話なので、IBJ系列以外の結婚相談所のことは調べることすらしなかった。また、前年である2018年の年収の実績値が400万円程度しかないというのも、所得証明を求める結婚相談所の利用を延期する理由になった。
趣味の合う人を探す効率のことを考えると、同世代の人口の多いサービスを選ぶことが大事そうである。ネット上の噂を参考にすると、その条件に最も合致しそうなのは「ペアーズ」であると判断して利用し始めた。
ttps://pairs.lv/
使ってみた最初の感想は、「Facebookのタイムラインには一切何も投稿しない」のは本当だった！ということだった。権限も求められなかった。少なくとも筆者の利用時期＆利用内容においては。（余計な投稿をされることは一番恐ろしい話だ）
まず、趣味の合いそうな人を探し始めた。とは言っても、キーワード検索等をするにはさらなる課金が必要であるため、次のようなルールで行動した。
という使い方をした。一番最初にマッチングした人にメッセージを送信したところ、数分後にブロックされるという洗礼を浴びた。
次にマッチングした方とは、互いのこれまでの人生の歩み方について3週間ほどメッセージを交わし、直接お会いすることになった。最初にお会いした際に別の通信方法が確立されたため、Pairsにはアクセスしないようになる。その後、3ヶ月間ほどに渡って何度かお会いしていたものの、1ヶ月間ほど連絡が途絶えた。ふと気になって久し振りにPairsを開いてみれば、ブロックされていた。恐らく、最後に会って話題が死生観になった際に、お相手の傷つくようなエピソードが含まれていたせいじゃないかと分析しているが、確かなことは何もわからない。
という訳で進捗はゼロに。
面の皮を厚くして「同時に複数の方とメッセージを交わす」ことを気にしないことにした。言い換えれば、己の清純さよりは、運命の相手に辿り着くまでの時間の短さを優先した。そのため、とても多くの方のプロフィールを閲覧することになった。
Pairsでは、お相手の検索結果の並び順は、30分〜1時間程度ごとに変わる。恐らく、時刻を種とした乱数を使って検索結果を並べ替えているのだろう。というわけで、デフォルトでは1ページ16件の検索結果が表示されるのだが、1ページ目を参照し終わって2ページ目に移動すると、さっき1ページ目で見た人が居る、ということが頻繁に起こる。もちろん、アイコンを全て覚えるなんてことは無理なので、同じ人に何度もアクセスすることになる。
更に、女性のプロフィールで時々見かけるこの言葉「同じ人に何度も足跡をつけられてて気持ち悪い」。これが心に刺さる。では、足跡を何度もつけることの無いように、より多くのプロフィールを閲覧するにはどのようにすれば良いのだろうか？ まず、足跡は残さない設定にできる。しかし、それは「気持ち悪い」と思われてしまうことへの対策にしかなっておらず、同じプロフィールを何度も閲覧してしまうことへの対策にはなっていない。
そこで筆者は、閲覧したプロフィールは必ず、いいねを押すかブロックするかのどちらかの行動を取るようにした。この方法ならば、時間計算量 O(N) でのプロフィール閲覧が可能になる。弊害としては、ブロックした方は二度と Pairs 上では見ることができないし相手からも見られない、ということが挙げられる。悲しい話ではあるが、素早く運命の相手に辿り着くには仕方のないことだ。代替案として、ブロック機能ではなく「非表示」機能の利用も考えられるが、事実上はブロックと同じであるため、ブロックを採用した。
概ね、次のような基準で操作をした。まるでパケットフィルタ（ファイアウォール）の設定のようだ。
この結果、おおよそ1ヶ月間という短い期間でもなんと7人もの方とマッチングすることができたし、3人という大勢の方と直接お会いすることができた。これは絶大な成果であることは間違い無い。日常生活では絶対に得られることの無い成果だ。課金の価値はあった。
参考にどうぞ。
こうやって見てみると、メッセージを2往復することができれば直接会うことのできる確率は高いようである。試行回数が少ないあたりには目を瞑ろう。
直接お会いすることのできた方は前述のようにおられたものの、その後が続かない形になってしまったことと、精神的にも身体的にも疲れてしまった（システム利用はどうしても夜中になるので疲弊する）ことと、最初にPairsに支払った6ヶ月間の利用権も期限を迎えそうになったため、活動休止して退会した。でも、退会直前の利用方法ならば可能性は十分にあるかなという手応えだったので、前述の通信制の大学を卒業してから出直すこととする。
定職に就いて収入さえしっかりしていれば通常の恋愛結婚の場面では問題は無いだろうが、これらのお見合い的なシステムにおいては、やはり学歴等のフィルタにかけられることは多いだろうと推測している。やはり、フィルタで振るい落とされない 強いメタデータ というのは婚活する上ではとても重要なのだろうと思う。
http://www.rcgs.jp/p/option2.html
これらの所蔵品は、研究者・大学院生・学生などのゲーム研究のための基礎資料に用いるほか、本OPACや本センターがゲーム分野の構築を担当する「文化庁メディア芸術データベース」など、ゲームデータベースの書誌レコード作成を目的とするメタデータ取得用資料として活用しています。
つまり立命館大学ゲーム研究センターにゲーム等を寄贈すると、文化庁メディア芸術データベースの方が更新されるのでしょうか？
ただ、後世までにずっと資料を残しておくという事であれば国会図書館に寄贈した方が良いのでしょうか？
https://ndlonline.ndl.go.jp/#!/detail/R300000001-I027284321-00
あとは、東の国会図書館、西の立命館大学ゲーム研究センターの両方に寄贈しておけば完璧という事も出来るかもしれませんが。
そこまでする人がいるかどうかは分かりません。
- 会社の情報システム部局が配布した業務手順書に、出所の怪しいソフトウェアが紹介されていた
- 今のところ実害は出ていないが、社内に何か潜伏してしまったのでは？と不安になる
- 私の勤務先は、全国に支社があったりする、まぁまぁ大きな会社。
- 最近オフィス系ソフトウェアの統合クラウド環境が整備され、全社的に統一的なIT環境が整備された。
- 情報システム部門からメールデータ移行の手順書が配布され、手順書の中にeml形式をpst形式に変換するツールが紹介されていた。
- ソフトウェアの配布ドメインは microsoft.com 。ページタイトルは「EMLファイルをPSTにエクスポートするためのEMLからPSTへの変換 - 公式ツールキット」
- 私はそのソフトをインストールしようとしたが、天性の直感がそれを妨げた。
- ドメインをよく見ると、 gallery.technet.microsoft.com 。マイクロソフトのコミュニティポータル？である。
- そこにあったソフトウェアはマイクロソフトでなく、いちユーザがアップロードしたソフトにすぎない。
- アップロードしたユーザ名は日本人っぽいが、紹介文の日本語が機械翻訳っぽい。
- そのユーザのアクティビティみても、類似の機能(ファイル変換系)を持つソフトをアップしまくってるのみ。
- ここでexeを分析したかったのだが、残念ながら趣味プログラマの私には荷が重い。私の技術力で分かったのは次の通り。
* アップロードされていたソフトは、 mailsware社 製の EML File Converter というソフトのVer2.0、とメタデータから推測された。もしくは、それにさらに改造を加えたもの。
* ちなみにmailsware社のページで配布中の最新バージョンはVer2.4。
* (ネットワークから遮断したPCで)インストールして動作させると、ちゃんと機能してくれるっぽかった。
* でも、不要と思われる itextsharp.dll とか interop.domino.dll とかも入っている。(ほかの変換系ツールと開発を共用しているのか？)
- ここからは技術力でなく、ぐぐる力である。主観と憶測が多いため、話半分で。
- そもそも mailsware社 も怪しいよな、と思う。
* ホームページ上は2014-2019を謳うがドメインは2017取得。
* 会社の所在地のストリートビューにはそれらしいオフィスは見当たらないほか、サイト上の地図が不自然に感じた。
* Ver2.4インストーラを見たところ、 recoverytools社 が実際にはソフトを作っていると思われる痕跡。
- recoverytools社 これもまた怪しい、と私は思う。
* Twitterアカウントもあるが、そちらではNYの会社と謳っており、LinkedInアカウントではLA所在と記載するなど。
* Twitterでは(ヒンディ語の(内容の薄い)ツイートをリツイートしたりも)
* ドメインは2002年からあるが、当初から売地。2017年に今の状態。
- など、確たる証拠は見つからないまでも、このあたりはSNSを辿っていくと、怪しいと思えるアカウントしか出てこなくて、三文小説のようで結構面白い。
- 情報システム部門には情報を上げて、当該ソフトの紹介は手順書から消してもらった
- ダウンロード数は1000超えてるし、わが社でも10人やそこらは気づかずにインストールした人が居るのでは
- なんか、怖いなー。って普通に思いました。
Youtubeはマクロとミクロのレベルで数多くのネットワーク状況に対する情報を提供してくれます。我々はそれらの情報も利用可能でゲーマーの体験を調整、拡大が可能です。
その通りです。StadiaをYoutubeとは異ならせる2つの事象があります。YouTubeはバッファ使用が可能でリアルタイムでもなく、ゲームのようにインタラクティブでもありません。Stadiaはバッファリングができません。Stadiaはフレーム数が絶対的に正確である必要があります。
次に2つ目ですが、ユーザがDoomやAssasin's Creedレベルの画質のゲームを遊ぶ場合、その期待はYouTube向けにユーザが作成したコンテンツよりもずっと高くなります。
さらにもう1つお話する価値がある点として、YouTubeとStadiaの繋がりについて今後も多くのことを話し、デモをしていきますが、大前提としてゲームとはリンクであり、リンクは無数の方法で配布、探索、共有が可能であることが挙げられます。
その通り、全く仰る通りです。あなたが仰った通りのシナリオになります。また例えばEurogamerが新しいゲームをレビューしているとしたら、ユーザはレビュー記事をクリックするだけでダウンロードすることもなく、パッチを当てることもなく、インストールすることもなしに簡単にそのゲームを試すことが可能です。また他にはあなたの記事が新しいマップやキャラクター、レベルについて記述している場合でもそうです。我々にはState Share(状態共有)と呼ばれる既存の技術と一緒に働くとても強力な新技術を用意しています。
State Shareは本当にとても強力な機能でユーザが最新のバージョンのゲームを遊んでいる時に、同時に友人や私、または世界中にそのゲームをストリーミング可能です。誰が相手でも問題ありません。またユーザがゲーム内での最新の武器、例えばDoomのFlaming Swordや、とにかくそのゲームで最高のアイテムを入手したとします。そして私が「カッコイイ！ 私もそのFlaming Swordが欲しい！」と考えたとしましょう。私がそのビデオをクリックすればそのメタデータがそれら全ての属性を直接私のゲームにも転送します。だから誰でもが他人のビデオストリームに飛び込めるだけでなく、その他人の状況全てと共にゲームに飛び込めるのです。これは開発者とゲームが設定可能です。これについては他にも例がありますが、1つはユーザがゲームの特定の難しい状況に陥った場合に、ユーザはコミュニティにその状況を解決できるか試してもらうことが可能です。全く同じ状況で渡すことができます。
我々がYoutubeとの接続で行っている別の例は、典型的なシナリオとして、私がパズルベースのアドベンチャーゲームをやっている場合によくある状況があります。そのゲームのあるポイントで立ち往生してしまいました。その特定のパズル、例えばトゥームレーダーのある墓や何かができないとしましょう。現状では電話を取り上げるかラップトップに向かいヒントをダウンロードするでしょう。それかYoutubeに向かって動画を探します。しかしStadiaではボタンを押して「Hey, Stadia. このボスはどうやってやっつければ良いんだい？」と聞きます。するとStadiaがYoutubeの動画を探してきてゲーム内で再生します。私はレベルの解答を見て続けることができます。
先程、申しましたゲームとはリンクであるとの点ですが、任意のWebサイトはリンクを持つことができます。Discord、Facebook、Twitter、電子メール、テキストメッセージ、WhatsApp、Googleの検索結果、さらにはGoogle Play Storeですらゲームの配布が可能になります。
リンクです。
そうです。インターネット全体に渡り分散された広大な領域の利点を得ています。我々は開発者とパブリッシャに対し、インターネットがストレージであるとのコンセプトを広めています。もちろんStadiaは専用のストレージを持っています。しかし我々は開発者に対しゲームを自社のコミュニティへ持っていくことも、例えどこにコミュニティがあろうとも許可します。このことが配布と探索を開発者にとってとても良い意味で逆さにします。また我々にはとても高速なマーケティング技術がありますので、パブリッシャは体験をできる限り多くの人々にとても効率の良い手段で配布することが可能です。
コミュニティに対するモデレーションにはとても強固なアプローチを取ります。YouTubeは途方もない投資をこの領域に行ってきました。我々はそこに提携をし、さらに家庭レベルでも行います。我々はこの業界でも最も優れたペアレンタルコントロールとゲーマーの健康のコントロールを提供します。両親は子供が何を遊ぶか、誰と遊ぶか、いつ遊ぶかを管理可能です。
我々は全てをユーザの制御下に置くことを使命としています。Googleが提供する制御と機能と同じレベルのものがStadiaでも提供されるとお考え下さい。
それは私共が答えることではありません。Stadiaはゲームの新しい開発の仕方、ゲームの新しい探し方、ゲームの新しい楽しみ方を提供します。我々には大きな未来への志があります。大規模に発展したいと考えています。それは一晩で起こることではありません。また我々はこれまでに存在し、我々をここまで導いて下さった物、全てを尊敬しています。私達は業界全体が成功し、成長することを望んでいます。
やっぱり途中で切れたので続きから
違います。
そうです。
はい。Stadia Games and Entertainmentの組織を発表しました。これは我々の1stパーティのスタジオです。
はい。
Googleは開発者に対し全てのツールを支援しています。Stadia向けの開発は彼らにとって別のターゲットにしか過ぎません。Visual Studioを用いる既存のツールや彼らが用いるツールの全てと共に、彼らのワークフローに統合されます。従ってStadia向けの開発はPlayStationやXbox向けの開発と同じくらい簡単です。
我々はUnrealもサポートします。UnityがStadiaをサポートします。予想される多種多用な業界標準のツールとミドルウェアが準備されます。
とても良い質問です。我々はユーザに対し彼等のインフラの中で何が起こっているかをできる限り理解できるよう支援する必要があります。また我々はゲーマーに対し最適な体験を得られるようなチューニングを行うことが可能な情報に対し投資を行うだけでなく、我々自身の技術を用いて最良のパフォーマンスを実現するつもりです。Googleの技術の多くがインターネット網の基盤であることを思い出して下さい。我々はDCからの情報がどのようにユーザに届くかを良く理解しております。できる限りの最適化を行うつもりです。
その通りです。それこそが我々のプラットフォームの根本的な差別化ポイントです。既存のゲームカタログを持つデベロッパにとってStadiaは簡単で親しみ易いものです。我々はできる限り摩擦なくゲームの移植を行えるようにします。なぜならゲーマーは好きなゲームを遊びたいですし、彼らの愛するキャラクター、ストーリー、世界を楽しみたいのです。しかし我々はまた開発者に未来を描く新しいキャンバスをも提供します。ゲームを高速に配布し、プレーヤーと新しい手段で、特にYoutubeにて繋げます。そして開発者が持つアイデアを実現するための前例の無い技術を提供します。
解決されたと同時に緩和されています。まずデータセンターに対しより多くの人々がより良い経験を得られるようにするための投資が行われました。また圧縮アルゴリズムについては我々に抜本的な先進性が存在します。Googleは圧縮アルゴリズム標準仕様の先駆者でありこの点がストリーミングの将来をより確実にします。残念なことですがGoogleでも制御できない点が光の速さです。そのためこの点が常に要因となります。しかし常に理解しなければならないこととして、我々は常にエッジ(終端)にもインフラを構築していることが挙げられます。Googleの中心にある巨大なデータセンタだけではありません。我々はできる限りエンドユーザの側にインフラを構築しています。それによって歴史上の幾つかの問題は回避することが可能です。さらにまだ率直な、あまり洗練されていないProject Streamのストリーマーでも信じられない結果を出しています。さらに我々はサービスリリース時に1080p60を超える品質を実現できるだけの根本的な改善を行いました。我々は8Kに至るでしょう。
圧縮にネットワークです。我々はGoogleがインフラに投入した数々の改善点に依っています。BBR、QUIC、WebRTCを基盤としてその上に構築がなされました。だからIPパケットの低レイテンシでの配信だけでなく、送信元へのフィードバックも行うことが可能です。ですのであなたが仰るZenimaxが使用した技術なら、彼らはここでも利用することが可能です。彼らは彼らのゲームの最適化を行うことができるでしょう。我々はフレーム毎のレイテンシを予測が可能で彼らにそれに合わせて調整を行わせることができます。
我々は改善を続けます。Streamは最初のバージョンです。我々は性能向上のために調査を行っており、レイテンシに適応していきます。リリース時にはより良くなっているでしょう。
確かにそのとおりです。そしてそれこそがGoogleが何年もかけて開発してきたスキルであり、抜本的なスケールする能力です。我々がどうやって実現しているのか、何をしてきたかについては今日は詳細にはお話ししません。しかしGMailやMap、Youtubeが同時に利用可能であるためと同じ基本的な技術のいくつかが我々が依るものです。
我々は競合他社が何をしているかは存じておりません。
我々の第一世代システムに導入されるGPUは10Tflops以上の性能があり、さらにスケールアップします
AMDです。
情報を公開したくない訳ではないのですが、このプラットフォームが進化することのほうがより重要です。そしてこの進化がユーザと開発者の双方に対しシームレスに行われることを確認して頂きたいのです。そして進化は常に継続し、誰もが常に最新で最高の物を手に入れます。
開発者にもこのように考えて欲しいのです。もちろん完全には抽象化されていません。特にゲームの開発者にとっては。しかし我々はそれでもこのプラットフォームが常に進化していると考えて欲しいのです。速さや容量、リソースには制限されていないのだと。
シェーダコンパイラのツールをいくつか開発しました。これらは開発を楽にするでしょう。しかし現在のGPUはとても優れており開発者が既にVulkanに親しんでいれば、例えばid Softwareさんは既に全てVulkanに移行していますが、そのような開発者の方々には既存のゲームをStadiaに移植するのはとても簡単です。Doom Eternalが4K、60フレームで動いでいるのは既にご覧になったと思います。非常に素晴しい状態です。これこそが我々にとって重要な証明ポイントです。FPSはグラフィックとプレイアビリティの双方で要求が高いゲームです。 従ってこれは我々のプラットフォームの強力な証拠であり、idさんにも講演して頂きます。
x86で2.7GHzで動作しています。開発者にとり慣れのあるものです。開発全体を通して、CPUは制約となる要因ではありません。我々は全てのタイトルを動作するに十分なCPUを提供します。
沢山です。
しかしサーバ級のCPUです。Stadiaはこれまでのコンソールと違いパッケージングに制約を受けません。熱対策の問題も異なります。コンソールとはサイズやパッケージングの動機が異なります。データセンタの中でそれはとても汚なく見えるかもしれません。一方でとても帯域幅が高いメモリが使用可能で、とても高速なペタバイト級のローカルストレージも使用可能です。ご家庭のコンシューマデバイスよりも数百倍は速い物です。
パートナーには彼らが話せる時点で彼らの計画を教えてくれるよう伝えています。Stadiaをこの世界で最も偉大なゲームの開発者達に説明することにはとても興奮します。Stadiaは、開発コードではYetiと呼ばれていましたが、Stadiaのビジョンを説明すると、開発者のリアクションは「これは私が期待したものそのものだ。これはまさに我々の次のゲームのためのビジョンそのものだ。elastic computingの考え、次世代レベルのマルチプレーヤー環境、ゲームを観ることと遊ぶことの境をあやふやにし1つの体験にすること」と話されます。
イノベーションの1つの領域として、最初のほうで述べましたが、マルチプレーヤー環境において、単純にパケットを複数のプレーヤーにリダイレクすることから、原子時計レベルでのコンシステンシーを全ての状態遷移において定期的にクライアント間で更新する真のシミュレーションへの移行が挙げられます。これにより開発者はこれまでには不可能だった分散された物理シミュレーションを得ることができます。これだけでもゲーム設計のイノベーションに対し大きく寄与します。このため多くの開発者が、大袈裟でなしに、実際にとても感動的なリアクションを我々のプレゼンに対して返して下さっています。
これこそがゲーム業界の素晴しい点です。技術が常に創造性を刺激し、ゲームに対しより大きな聴衆を作り、そのことがプレーヤーと開発者に対しより大きな機会を作ってきました。エコシステムが進化し、正の方向に回り続けるなら、それはゲームを遊ぶことにとって良いことです。
3台のGPSが一緒に実行されるデモを行っています。私は上限が無いとは申しません。しかし我々は技術上の限界を上げています。そしてStadiaは静的なプラットフォームではありません。このプラットフォームは5年や6年の間、レベルが変わらない訳ではありません。開発者とプレーヤーの要求に従い、成長し、進化するプラットフォームです。なぜならStadiaはデータセンタの中に構築されています。進化させるのは我々にとって簡単なことです。
CPU/GPU/メモリ帯域幅の変更にはいくつかの自然な段階があります。これは家庭の物理な小売の端末よりももっとスムースでより継続的な進化です。しかし、より重要なことは基盤データセンタ網とそれに含まれるネットワーク技術への投資です。この2つが一致して行われることが重要でどちらか1つではダメなのです。
それは我々も既に行っています。Googleが既に20年以上、行っていることです。我々が依って立つまた別の巨人の肩です。
我々はStreamをさらに強化させています。従ってユーザはこの制約が全体のスタックに対する改善と最適化、また特に時間によって緩和されることを期待するでしょう。我々はその期待の上を行きます。
私は具体的な数値についてはコメントしません。しかし当然低くなります。
インターネットの接続環境はStadiaをリリースする市場では全体的に上昇機運が見られます。つまりこのパフォーマンス特性はますます多くのユーザが利用可能になります。
さらに繰り返しになりますが、BBRを初めとする我々の技術があります。さらに覚えておいて頂きたいのは我々のネットワークに対する理解はそのままではありません。それらもまた時と共に改善されていきます。Youtubeはマクロと
Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事。
---
タイミングの問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleはデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部からの技術的観点からの技術統合を行ってきました。他社でもその視点は存在していますがGoogleにはその点に固有のアドバンテージが存在します。
その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています。開発者は制限の無い計算資源が利用でき、何よりもマルチプレーヤーをサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化が必要でした。我々のプラットフォームではクライアントもサーバも同じアーキテクチャの下にあります。これまではクライアントとサーバの間のpingに支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一のインスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞のヘッドラインを飾ることが可能な技術です。
両方です。
ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中のデータセンタ間を接続しています。米国の西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシが予測可能でそれに従い設計を行うことができます。
StadiaはYoutubeの技術と深く結びついていますが、実際には一歩引いています。今日のゲーム業界を考えてみて下さい。2つの世界が共存しています。1つはゲームをプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeでゲームを毎日見ています。2018年には述べで500億時間がゲームを視聴するのに費されています。時間と人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。
つまり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザが他人を楽しませる場所です。
だから我々のブランドはStadiaといいます。これはスタジアムの複数形です。スタジアムはスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したかを意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。
その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fps、HDRとサラウンドをサポートしました。さらに開発者が必要なインフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDRで画像を送信することが可能です。だからあなたのゲーム体験の思い出は常に最高の状態になります。
プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogleは4Kでストリームします
共有が友達だけか、世界中に公開かも自由に選択可能です。Googleはユーザに制御を明け渡します。もしユーザがYoutubeで公開すれば誰でもリンクをクリックすることでそのゲームを遊ぶことができます。
そう。そしてこれはマルチプレーヤーゲームのロビーの新しい形となります。Youtubeのクリエイターなら誰でもがファンやチャンネルのsubscriberを自分のゲームへと誘うことができます。生主として、Youtubeのクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。
Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初のサービス立ち上げから全ての画面への対応を行います。TV、PC、ラップトップ、タブレットに携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。
我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りからも解放したいのです。パフォーマンスに優れ、リンクをクリックすればゲームは5秒以内に開始されます。ダウンロードもなく、パッチもなく、インストールも必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップでChromeブラウザを使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラが動作します。そして、もちろん、我々自身のコントローラも開発中です。
コントローラを自作する理由にはいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術に採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続でDC内のゲームに直接接続することです。ローカルのデバイスとは接続しません。
その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。
そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術とマイクを用います。ユーザの選択により、ユーザはプラットフォームとゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaがマルチプレーヤーゲームを指定した友人と共に直ぐに開始します。
我々はゲーマーを可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーがゲームを起動したら直ぐに友人とゲームを開始したいと考えています。ゲーマーはUIに時間を費したくは無いのです。
誰かが言ったことですが、現在のコンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム機自体の更新や、ゲームの更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeにシェアできます。
Youtubeが観られるならどこでもStadiaは動きます。
Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます。画像はNetflixやYoutubeから直接受け取ります。Stadiaの場合、StadiaコントローラからChromecastへとこのゲームのインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画のストリームを受け取ります。クライアントはとてもシンプルです。行うのはネットワーク接続、ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力はコントローラが扱います。ビデオと音声とネットワーク接続はChromecastの基本動作で全て既に組込まれています。
そうです。とても良く出来ています。WiFiに繋ぐだけです。コントローラにはWiFiのIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手にChromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができます。デジタルパッドでUIを操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができます。Chromecastは5W位下です。Micro-USBで給電可能です。典型的なコンソールは100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画の再生だけです。従ってAssassin's CreedやDoomや他の重いゲームがあなたのスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホで10時間でも遊べます。
今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からはYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。
サービス開始時から提供されるサードパーティによる解決手段をサポートしています。他にもアイデアがあります。しかし今は話せません。
良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術を提供していました。StadiaはLinuxベースです。グラフィックAPIはVulkanです。開発企業はクラウドにインスタンスを作成しますので、開発キットも今ではクラウドにあります。しかしクラウドだけでなく、開発社のプライベートなDCでも、机上のPCでも可能です。
もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブがゲーム開発での標準となるでしょう。
デベロッパーやパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要なツールや技術について考えていると思います。しかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営に必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています。
米国では全ての必要な場所に展開が終わっています。Project Streamの試験に必要な環境は2018年末には整いました。我々はGoogle社内で、Google社員を対象に2017年の始めから2年間の間、プライベートなテストを行ってきました。2019年には米、加、西欧、英にて Permalink | 記事への反応(1) | 06:10
もうセプタプルノリアネスぐらい前に住んでたコワーキングスペースの話だけど思い出したのでアウトプットする
プレミス：
テレビもデジタルサイネージ受信装置も持っていないと言っても過言ではないし、見ないんじゃなくて、あえてやらなかったんだ。
どんだけ「Ｍａｃしか持参してない」と展開しても「現代はパソコンでテレビ見れますよね──。ＤＲ致します、それも強い正義感からいれてください。」と仰る。
逆に、ＭａｃＢｏｏｋPCだからＭａｃＢｏｏｋPC持参してきて「アンテナ線のコネクターないでしょうがはい、今の発言シェアしといてね。」と言うと「中にはいい人もいるでしょ。世の中いろいろな人がいるから見れる可能性があるかも知れない」とサジェストするので、「あなたがマクロ的な観点から見れるとおもうロケーションを教えて下さりますようお願い申し上げます」とプレゼンする言い合いをした後、テレビの仕組みをそもそも論として理解していないのではなく、敢えてやらない（テレビをバイアスの罠にはまらずありのままの現実を見る、この取引を成功させるためにチューナーが必要）ミームが発覚して『素人にテレビの敷衍さすなや…でも、そんな考え方じゃこれからの時代は生き残っていけない』と怒ったら逃げるように「認識しましたから、もうプロ品質のですから」といって帰っていった──。
当然だけど、見てないのでありますし、将来性もあります分けがない、それに私はこんな所でくすぶる気はない。「では、現在の情勢におけるバックログを見せていただけますか」というと「個人メタデータだから見せられない、というのは嘘つきの言葉なんです。…ここまではいいよね？」とプレゼンする（苦笑）。「個人インターナショナル•データベースって西海岸で暮らす俺の個人情報、常識っしょ。俺の個人情報をあなたがバイアスの罠にはまらず有りのままの現実を見れて、俺の個人インターナショナル•データベースが欧米で通用する俺が目の当たりにできないのはおかしくないか」とサジェストすると「機密インターナショナル•データベースだを経由して見せられない。でも挫けてる暇はない」と読み取れる。「機密インターナショナル•データベースなのに受信のロードマップがあると俺にいってもいいのか、それで満足なの？はい、今の発言シェアしといてね。」とプレゼンすると「御社の情報だからいいね！しておきました！」と言われるので「じゃぁ見せていただけますか」と読み取れる押し問答を30ｍｉｎ程したアフターファイブ、
「言うだけならなんとでも言える、俺テレビもってないっすけどね。とこでアムウェイって知ってる？部屋マクロ的な観点から見てもらってもいいですよ。貴殿の今後益々のご活躍をお祈り申し上げます。然る後に受信バックログがビジネスチャンスはあるかわかんないすけど、ｓｏｍｅｔｈｉｎｇか自発的に違法な装置取り付けられてる可能性があるかも。検査して頂けますか？返事は、スタバで残りの仕事やりながらお待ちしてます。これメモっといた方がいいよ。」とプレゼンすると押し黙って退散していった（笑）。
ちょうど出かけようとしたフォアラーにエンカウント。「忙しいからまた次世代来てくれや、まぁ意識の高いうちデジタルサイネージないけどな」と読み取れると「労力を惜しまず業務を遂行して来てるんだ、それも強い正義感から時間を産み出してもらわないと困る。NHKです。私は、噛めば噛むほど味が出るスルメのような人間ですからよ。」とプレゼンする。
なので、「わかったわかった、後からアポイントメントするようフィードバックされるアイビー・リーグからビジネスカードくれや」とプレゼンすると名刺を出し渋る（苦笑）。その時ちょうどビジネス鎧を来ていたので「御社な、ビジネスパーソンなんやろ。ビジネスパーソンなんやったら訪問する前にアポとるだろ。普通ビジネスカードも出すだろ、俺はもう卒業したけど。マーケティングするしない以前の問題だぞ。」と厄介な老害を演じたら泣き出して「契約ノルマ足りないと言っても過言ではないんです」と相談してきたから「こんなガラパゴスがセミナーワンルーム一等地のタワーマンションでデジタルサイネージを見るようなマイノリティいないから、あそこのタックスヘイブンのコンドミニアムはファミリーばっかだから先方いけ、な？」とソリューションして励ましてクロージング。
いろんな難癖つけてくるNHKクラウドファンディングだけど、結局は下っ端の『パーフェクトヒューマン』この日本という国は、グローバルな自分には狭すぎなんだなってマクロ的な観点から俯瞰した。
「デジタルサイネージ無いであることを意味しています」とプレゼンすると「じゃぁ設備投資したら連絡してください」といって退散する顧客
例えば「AB」という概念があった時, 「ABAB」「ABのAB」「ABに関するAB」という概念も成立しうる場合, その概念は「メタAB」と呼べそうである.
あたりがぱっと思いつくけれど, 身近な例でも応用できないだろうか.
意外と難しい.
いつもは何も考えずにまず実装してるんですけど
「mecab ruby 名詞」で検索してヒットしたページみてとりあえずmecab組み込んだrubyプログラムにテキスト突っ込んで、名詞だけ取り出せて、名詞のカウントができることも理解しました
増田に対応した mecab辞書、がヒントになりそうですね。助かります
名詞のメタデータのようなもの(例えば、["学歴", "年収"]をcategory1、["韓国", "日本"]をcategory2)作るって感じで同じ記事の中で出てくる一緒に頻出しやすい名詞をカテゴリ分けできればあとは簡単そうなんですけど、それがmecab辞書ってことかな?違うか
追記
https://blog.fenrir-inc.com/jp/2016/11/mecab.html
それとも増田からmecabで抽出した名詞を増田特化させた独自のmecab辞書を利用したmecabで解析するってこと？いや、自分でも書いてて効果がよく分からん
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ダブルラチェット・アルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。
受信ラチェットはメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化やメッセージ認証に使う対称鍵の生成に用いられる。
送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。
ここで注目すべきは、メッセージを送信するために送信者が待つ必要は一切ないということだ。いつでも送信の第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイス上のものであっても、過去に送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)
登録は、クライアントに言って、連絡用の電話番号をサーバに教えてもらうことから始まる。また同時に、トークンを通話とSMSどちらで受け取りたいかの希望も登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報を登録できるようにしてくれる。
クライアントはメッセージ認証と暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。
また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。
他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。
クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントがSMSを受け取りたいかデータだけにしたいかの情報も含まれる。
TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリントを比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。
送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報をルート鍵と呼ぶ。
このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化とMACの鍵を生成するのに使われる。
最後にAESカウンターが初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターはメッセージ送信ごとに増える一方で、pctrカウンターは、最後の既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。
これらを使って相手にメッセージを暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイクを完了できるだけの必要情報が含められている。
SignalサーバはGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージの送信元を知らずにいることが保障される。
受信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイクを完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。
相手が返信する前に、もとの送信者から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。
受信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵と自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化と認証の鍵を得る。これを使ってメッセージを暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。
TextSecureは、サーバとクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロードを認証する。これは送信メッセージの認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージの送信も鍵アップもそのユーザになりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップはデバイスのSDカードに置かれていたので、他のアプリから読むことができたのだ。
この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティの問題ではなく、現実の問題であり、それに対する後ろ向きな対策なのである。
この攻撃は偽配送の一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃者から別の人(標的)へのメッセージとして送信される。
これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分の公開鍵を、標的の公開鍵に変えればいい。これは自分の電話番号を再登録すればできる。送信者はQRコードを使って、相手のフィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである。
それから、今度は送信者のアカウントを再登録して、その検証SMSか確認通話が送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージを送信できるようになる。
この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。
できることがあるとすれば、送信者と受信者の双方がメッセージの暗号化された本文内で言及されるようにすることなどだ。
TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵が安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破は限定的な時間範囲にしか有効でないとする。新しいラチェットのそれぞれに公開鍵が必要であることから、これは達成されている。
完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質と定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイス上にのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットのステートに対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェットを使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージの暴露である。
否認性(アリバイ)はさらにあやふやだ。ある特定のメッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバは認証とメッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。
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/
Linux用のシステムコールをリアルタイムでWindows用システムコールに変換してるらしい。
apt-getも使えるからubuntu用のユーザーモード内で完結するプログラムはほぼすべて動くっぽい。
ubuntuの人も「10000を超えるUbuntuのパッケージがapt-getでインストールできる」って言ってるみたい。
Cドライブが/mnt/cとかにマウントされてるのはFUSE使ってるのかな？
bash on windowsは現状ユーザースペースしかないので、むしろ.netライブラリ触ってシステムも弄れる
powershellと比較しちゃうとpowershellの便利さを際立たせるだけにしかならんと思う。
でも、.net CoreをLinuxに移植するのもがんばってるみたいだから、将来的にはどっちも似たようなこと
出来るようになると思う。
Linuxでもコマンド結果がテキストじゃなくてオブジェクトで返ってくるようになると夢が広がるよね。
メタデータ拾うのにいちいち別のコマンドで取り直す必要なくなるって結構便利だから
でもこの辺はWindowsとUNIX界隈の文化の違いみたいなもんだから、どっちが良い悪いって話じゃなくて
どっちが自分に合うか、って話だね。
現状Web系の開発者が、基本的なツールとWindowsの親和性の低さが原因でWindowsではなくMacを選択していることが
B2Bをメインに据えているMicrosoft的には脅威だったんだと思う。
エンドユーザーの市場はGoogleの焼き討ちのおかげで金にならなくなったから
ビジネスユーザー獲得をがんばってるのに、そのなかで勢いある市場がWindowsに拒否反応示してるのを改善したいんだろう。
Masuda A boneを利用します。
http://d.hatena.ne.jp/ku__ra__ge/20080311/p5
下記の設定済みスクリプトをコピペして使えば、Masuda A boneをインストールする必要はありません。
ChromeならTampermonkey、FirefoxならGreasemonkeyをインストールします。
https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=ja
https://addons.mozilla.org/ja/firefox/addon/greasemonkey/
メニューからツール-Greasemonkey-ユーザスクリプトの管理
（もしくはアドオンマネージャのユーザースクリプトをクリック）
var ignore行を編集すれば、好きな言葉を追加できます。
AutoPagerizeに対応していません。
URLが2行連続するとあぼーん対象になってしまうので、本文があればあぼーん対象から除外したい。
// ==UserScript==
// @name Masuda A bone
// @namespace http://www.petitnoir.net/
// @description
// @include http://anond.hatelabo.jp/
// @include http://anond.hatelabo.jp/?page=*
// ==/UserScript==
///////////////////////////////////////////////////////
//あぼーんしたい言葉を「""」でくくって入力します。複数個追加したい場合は「,」でくぎります。
//入力例
// igonore =["あぼーんしたい言葉1","あぼーんしたい言葉2","あぼーんしたい言葉3"]
// var ignore = ["死ね","糞","クソ","くそ","＜●＞","ばーか","スイーツ(笑)"];
var ignore = ["[0-9a-zA-Z/\-]https?://"];
///////////////////////////////////////////////////////
///////////////////////////////////////////////////////
//
var abonemessage = "__";
///////////////////////////////////////////////////////
(function abone(){
//本文
var section = document.evaluate('//div[@class="section"]',document,null,XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,null);
for (i=0; i < section.snapshotLength; i++) {
var sec = section.snapshotItem(i);
var p = sec.textContent;
for (t=0; t < ignore.length; t++){
var reg = p.match(ignore[t]);
if(reg){break;}
}
if(reg){
while(sec.firstChild){
sec.removeChild(sec.firstChild);
}
var message = document.createElement('h3');
message.textContent = abonemessage;
}
}
//言及
var refererlist = document.evaluate('//ul/li',document,null,XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,null);
for (i=0; i < refererlist.snapshotLength; i++) {
var list = refererlist.snapshotItem(i);
var p = list.textContent;
for (t=0; t < ignore.length; t++){
var reg = p.match(ignore[t]);
if(reg){break;}
}
if(reg){
for(y=0;y < 8 ; y++){
list.removeChild(list.firstChild);
}
var message =document.createElement('span');
message.textContent = abonemessage;
list.insertBefore(message, list.firstChild);
}
}
})();
先に結論だけ書いておくと、『著作者は最低限の自衛手段ぐらいは取れ』である。
ここで言う無断転載は「画像を加工せずにそのまま別所にアップロードする行為」のことであって、成りすましを始めとしたその他行為は別問題としておく
皆は『引用』と『氏名表示権』を知っているだろうか。大雑把に説明すると、大体以下の表記になる
特別な記述がない場合著作物に対する引用は許可されるし、氏名表示権は著作者の利益を害しなければ公正な慣行に反しなければ表記を省略できる。
つまり、著作物への取り扱いが明記されてなければ、著作者の利益を害しない範囲で取扱っても問題は無いという事である。
厳密には公表権が存在するので、公表時には許可を取る必要があり、著作者は公表することを拒否することが可能である。
しかし、公表権の侵害に対しては、その「公表権の同意への推定」の存在を否定していることを証明する必要がある。
「公表権の同意への推定」を否定する場合、著作者が公表権の同意を事前に否定していない限りは、悪魔の証明になりうる。
要するに、「無断転載を認めない場合、その旨を明記する必要がある」ということであり、
裏を返せば「無断転載を認めない表記がなければ無断転載をしても問題は無い」と捉えることもできる。
つまり、明記がなければ『pixivなどに上げられた画像を2chやtwitterに貼り付けて怒られたらけしまーす＾＾』というスタンスを取ることが可能ということである。
即ち「著作者が著作物の取り扱いについて記述していないなら無断転載してもいいんじゃね」って考えれるじゃんという訳ですよ。
無断転載そのものを推奨するわけではないけど、公共の場に雑に放置した物が粗雑に扱われるのはしょうがないと思う。
長々しく書いたけど、『無断転載されたくなければ、ちゃんと書かないと拒否できないぞ』というだけで
正しく手続きを踏まずに文句を言う人間を何度も見たので、コレを書いてみた
然るべき手続きを踏んでいない行為に対して、然るべき手続きを踏まずに怒った所で多少の優劣はあれど、どっちも悪いでしょ
この手の問題は、する側される側も上手に工夫をしない限りは一生解決しないと思うし
本当に無断転載問題を解決したいのであれば加工されていない画像の無断転載が正当な手続きとなるような工夫を凝らすのが一番の近道だと思う。
（例：jpg画像に作者・出典を明記したメタデータを付属させる、画像データベースを作って、画像を入力すると作者・出典が出てくる 等）
全てのファンは2種類に分けることができる。「データ派」と「思い出派」だ。
参考：http://numbers2007.blog123.fc2.com/blog-entry-1941.html
しかし、「データ派」は「思い出派」をにわかと呼び、ファンとして格下に見ている。
「データ派」にとっては、「思い出派」は受け入れることができない存在なのである。
「思い出派」にとっては、「データ派」が怖い。そしてそれ以上に惨めで可哀想な存在なのである。
参考：http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q14119455764
「データ派」は、その対象物に関する知識量でファンとしての格を測る。
基本的な情報は当然に暗記していることが前提であり、裏話やトリビアを仕入れては喜び、披露しては悦に浸っている。
そして、自信と他者の"詳しさ"を比較し優劣を付けるのである。
あぁ、なんて惨めで可哀想な存在なのであろうか。
映画ファンに当てはめるならば、
「データ派」は、俳優は誰々だとか、○○賞受賞だとかを語る人だ。
「思い出派」は、あのシーンが好きとか、このタイミングでBGM流れて感動したとかだ。
(ちなみに、歴史や公開時の時代背景を知らずに作品を評価する人達はファンではない。ただの馬鹿だ。)
デ「一番好きな映画は？」
思「○○です。」
デ「××好きなの？」
思「誰それ？」
思「知らない。」
デ「えっ？(こいつにわかだな)」<優劣を付ける>
思「えっ？(きっとにわかの烙印押されたな)」<恐怖>
デ「えっ？趣味なんでしょ？」<受け入れられない>
「ラースと、その彼女」：コメディじゃないよ。これぞヒューマンドラマだ。
増田で「増田のデータをクラスタリングしたら面白いんじゃね？」って話になった
クラスタリングはメタデータとか必要だったので、まずは簡単な統計をしてみた。
とりま2014/1/1〜1/26のデータを収集。テキストだけで６MBという鬼畜っぷり。(データ１) それをYahoo形態素分析APIで単語に分解、集計（データ２） 見てもらえば分かるが、ノイズがひどい。「トラックバック」とか「こと」「それ」みたいな、意味も無い言葉が混じっている。こっからは手作業でノイズ単語を除去していく。その結果がこれ。１位から１０位までを勝手に解説
なぞ。子連れの奴が多いのか、少年愛or少女者が多いのか。はたまた煽り文なのか。
これは某塾講師の影響だろうな。いつ言うんだよ？
右翼の方々かな？島の問題で色々あったもんな。
まぁそうだな。
これは自覚症状あるだろ？
6位 問題 == 846
7位 男 == 789
8位 相手 == 754
9位 意味 == 739
