「デジタル」を含む日記 RSS

はてなキーワード: デジタルとは

2016-05-31

http://anond.hatelabo.jp/20160531005132

 指輪とかイヤリングのが分かりやすいんじゃね?

そんな事より俺さ、このごろ鼻が気になって仕方ないのよ。

 VR酔いがモニタ中央(右眼用と左眼用の中間部)にデジタルの鼻を表示すると軽減されたって記事読んだんだけどさ、鼻って見えるか? って思ったのな?

んで寄り目にして少し視線下げてみたら有るじゃん? だからうそれに気付いて以来コトある毎に鼻を見ちゃう

 鼻、鼻、…俺の鼻。あ、あった鼻。

右下を見ても左下を見ても鼻。ああ、なんでこんな視界に常にあるものが今まで気にならなかったんだろう。

 誰か助けてくれ。気になるんだよ、鼻が。

30・40代こそがデジタルネイティブ世代

デジタルと一緒に成長して、デジタルの成長を終焉とともに見送った世代としてそう思う。



id:kash06さん:それっす

2016-05-29

富士通退職した話」に言及とついでに自分の話でも。

自分も前に富士通に居て既に退職してます。後で詳しく書くけど、ソフトウェア開発職に居たです。

富士通を退職した話

彼のへの感想

富士通はクソでっかい会社なんだし、サイト見ればメインフレームやってるのだって判るんだから、開発職を希望したらメインフレーム関連の開発やる可能性あるのは当然予見出来るだろうし、それを想像してなかったのなら情弱とかブコメで言われてしまうよね。あと何も記述が無いか想像だけど、「それほど有能ではない」と判断された可能性もある。と言っても学生が思う「開発者として有能かどうか」ってのと会社でのそれってのは別物で、要するに学生自身自分が実績もあって優秀だと思っても、会社的にはそうでないのよね。そうなると(後述の富士通入社して10年が経った人の話にもあるのだけど)新人能力客観的判断材料って大学資格応用情報レベル以上)程度なのよね。資格に関しても基本情報なんてMARCHクラス以上の人間なら受けたら取れて当然だから、「有能かどうか」の判断材料にならない。就活の際に本気でIT業界に入りたいかどうかの判断材料にはなる程度。自分の同世代富士通本体に入ってソフトウェア開発関連に配属された人のプロフィールを見たけど、確か偏差値的には少なくとも神戸大学とか千葉大学あたりの修士しか居なかった覚えがある。あと確か2~3人がソフ開持ってた気がする。だから、この増田がどの程度だったのかなと。

ただ、20人月案件が具体的に何かは判らないのだけど、自分の在籍していた当時でも炎上巨大案件というのはあって、(自分が知ってるのは確かデジタルテレビがどうのこうのとか言ってた)、そういうのに入社して間もなく入ってしまうと自身勉強等が出来なかったり潰されたり最悪死んだりするんで、そういう意味でも逃げるのは正解の一つ。(自分炎上案件に放り込まれ新人が寮で死んでたとか話を聞いたことある

上司対応はまあこれだけ見ればクソだわな。


富士通を退職して思うこと

はあ、としか。この人がこう判断した際の判断材料にするであろう自己体験を具体的に書いてないので、意識高い系がフカしてるようにしか見えない。あと、たった3年しか居なくてあの巨大企業経営とか体制とか理解出来るんかね?と思わないでもない。自分とは部署が違うだろうから当然かもしれないけど、自分体験とは違うなーって感じ。自分は、外から見たら馬鹿みたいな事やってるように見えるかもしれないけど、経緯や目的巨大企業特有問題があってそうなってるんだなって思う事が多々あった。


富士通に入社して10年が経った - blog

近い時期に入社したと思われる。具体的な話が自分経験と一致してる。特に富士通ソフトウェア開発と言えばミドルウェアの開発が主だというのは、富士通内部じゃないとなかなか(特に学生なんかじゃ)判らないかなと。

それでこれらの話を見てどんな人が富士通(というか大企業)に向くのかなと考えたんだけど、「やりたいこと」そこまで明確じゃないけどコンピュータは嫌いじゃないって感じで、地頭がまあまあ良くて勉強に関しても要領よくやれる(要するにそこそこの大学に行って卒業した人)、それでそこそこ安定した職・収入目当てな人かなと。ってコレ書いててふわふわしてる人みたいであまり良い印象の人物像じゃないな。マッチングミスはどうしても起きると思うし、学生の頃に思う「やりたい事」って往々にして変わったり間違いだったりするし、そもそも学生の頃に明確な「やりたい事」がある人の方が少数派でしょ。だからこういうそこそこ優秀だけどふわふわしてる人の方が良いんじゃないかなとか。逆に、ちゃんと「やりたい事」が明確にあるけどまあ安定はしたいって人はどうしたらいいのかって言うと、自分みたく大企業の子会社を狙うと良いんじゃないかなと。子会社ならその会社がやってる事が理解やすいし、入った後の配属の希望も大きく違ったものにはなりにくいし。まあ子会社子会社で色々アルかもしれないけど。

で、自分入社から退社までの話。

入社10年ぐらい前。入ったのは富士通の子会社で主にミドルウェアの開発をやっている所でした。入社して1~2年したら子会社の統廃合とのことで富士通本体連携してる部署自分がそうだった)は富士通本体になりますとのことで富士通本体の方に移ったという経緯ですね。別に待遇とか元々本体と同じだったから変わらず、事務関連が小回りきかなくなったぐらい。入社してから退職までは5年ぐらいでした。辞めた理由実家事業を継ぐ事にしたため。

入社して数ヶ月の時にある温泉地にある某所でその手の開発をやってる子会社沢山と

富士通本体ソフト開発配属の人達研修をやったのだけど、その際に富士通本体人達と知り合った。(この際に全員のプロフィール冊子が配られた)そのときは流石子会社に入る人達本体とじゃレベルが違うな~と思いましたね。(ちなみに自分MARCHより下の院卒。)

自分が配属されたのは某製品部署API部分チーム。その製品C言語Java言語からも使えるように出入り口を用意する部分。中でやってる事は指定されたIPポートプロトコルに沿ってデータ投げるだけなんだけどね。ちなみに配属希望の際は「そこそこの忙しさの所がイイ」と言っていました。「バリバリに働きたい」と言ってた同期は多忙ヤバい所に配属されてました。他にもチームがいくつかあったけど、それらのうちの一つは例の「山奥の工場」でしたね。自分が配属された当時はC言語APIリニューアルするって開発してたのだけど、設計担当Javaしかやったことない人で色々とC言語流儀に反してて後々のメンテが大変でした。まあそれでもリニューアル前よりは遙かに良くて、以前はユーザに見せてる関数名が ○○search1 ○○search2 ○○search3 とかでしたね(ちなみに機能はそれサーチか?思うのもあった)。もっと酷かったのが初期製品Javaの公開メソッドで、マニュアルには「このメソッド引数○○を□□を指定した場合戻り値Objectを△△にキャストしてください。××を指定場合は…」という「これ製品にして売ってたんだ…」と思うレベル。もちろんコレがダメだったってのは開発側も認識していて当時は既にリニューアル済みだったけど。リニューアル済みでも少し微妙だったけどね。

これは、ミドルウェアの開発をやってる人達って基本的C言語が主でJavaとかをやってる人がほぼ居なかったからだと思う。上司もそういうのは良くないってのは認識してた。対象OSWindowsLinuxSolarisだったけど、そんなにたいした事やってなかったからほぼ同じコードだったような。ソケットの一部だけ違ってたっけかな。

それでそのバージョンの開発が終わったあたりで、.NET Frameworkが出始めてきたので次バージョンでは.NET FrameworkAPIを作る事になりまして、自分が少し勉強していたのでそれの設計から担当する事に。当時は.NET Framework 1.1で今思えば少し時期が早かったと思う。2.0Genericが出てからやった方が良かったと思うんだけど、そういうの政治的判断だし結果論だしなー。それまでにRubyとかオブジェクト指向言語に触れてその辺の勉強もしていたので、.NET用のAPIに関しては設計実装結構良い感じに出来たと思う。ああ、そういえばRuby用のAPI効率化の開発ツールとかの名目仕事中に勝手に作ってたなあ。他にもC言語APIも内部実装がクソすぎ!とキレてユーザ公開関数インターフェースだけ同じで中身をフルスクラッチした事も。もちろん絶対LDしてるんで完全に趣味なんだけどな。これでAPIC言語Java.NETになった訳だけど、現場案件で使われたのってほぼ全てJavaだったと思う。(開発中のサーバテストアプリC言語だけど)。要するに自分が数年関わったコードが世の中ではほぼ使われてない訳でして、取りそろえとして必要だったとはいえ世の中の役に立ってないってのは嬉しくは無かったですね。まあ、大企業仕事なんてそういうもんです。.NETに関してはそのバージョンが出る頃はその製品があまり売れてなかったんだか使われたって話は聞かなかったですね。ほほほ。大企業に勤めるのならこういう覚悟必要かもね。

で、.NETAPIが出来たあたりに開発ネタがなくなって保守気味になってきたので、人員整理作業整理との事でインストーラと切りたいけど一度やったからには切れない補助製品担当が増える事に。インストーラWindowsがInstallShieldというクソみたいな言語上で作られたものLinuxSolarisシェルスクリプトのもので、InsallShieldの方のコードはあまりにクソなのでリファクタリングさせてもらった。この辺の開発は少なかったのだけど新OS対応(Vistaとか)とか保守作業が大変だった覚えある。

んで、これらの作業が終わったあたりでこの製品でやることが無くなってきたのと同時に、この製品派生製品の話が出てきてて、それは1機能1exeで提供されてて、それらを纏めるバッチ処理機能部分を担当することに。バッチ処理の内容・順番を記述するのにXMLを使う事になったのでXMLのパーサが必要なのだけど、色々調べたら富士通内部でパーサ作ってたのでそれをもらって使う事に。そのパーサはC++からじゃないと使えなかったのだけど、趣味C++勉強してたので何とかなった。あと、結構OSの知識(プロセスとか)が必要WindowsLinuxSolarisで動くコードを書く必要があってまあまあ大変でした(と言ってもifdefで切り分けるだけなんだけど)。けど、これらの開発は自分が一から設計してコードを書いていたので楽しかったですね。それでこれが完成するかしないかあたりで、このバッチ処理機能が他の開発中の製品バッチ処理に使えないかとか話が出てきたあたりで自分退職する事に。(退職の話は1年ぐらい前に話し合って決定済み)引き継ぎをして退職ということになりました。最後は溜まった有給を使う予定でまだ在籍中だけど部屋を引き払って実家に帰ってたのだけど、打ち合わせに来て欲しいって言われてしま実家から何日か通ったのは良い想い出。というかまさか実家から朝8時に間に合うとは思って無かった。

振り返ってみて残業時間は月40~60時間が多かったかな。100時間超えた時は上司に怒られた。あと退職前の1年ぐらいはうちの事業本部(だったかな?)単位残業禁止になってホント残業0時間になった時期があった。他の部署の人の話で、どう考えても狂ってる上司の話とかを聞いてると上司とかの運は良かったと思う。あと、やっぱり仕事でみっちりプログラミングが出来たのは運が良かったと思う。富士通ソフト開発で C C++ C# Java シェルスクリプト InstallShieldとか(そんなに深くはないけど)色々やれた人間はそうそう居ないんじゃないかな。同期とかの仕事は年上の人の派遣の人に指示出したり取り仕切ったりする仕事とか、保守サポートみたいな開発じゃない仕事の話も良く聞いていたので、ソフト開発のキモ体験出来たのは良かったです(こなみ)。

2016-05-23

政界ふしぎ発見

舛添都知事政治資金規正法関連問題では、

資金使途を記載した帳簿の画像がよく目に触れます

この帳簿には、支出した年月日、相手先、内容や目的が、

知事言葉を借りれば「膨大な数」記載されているのですが。。。。



さて、ここでクエスチョン

この帳簿、よく見るとぜんぶ手書きですね。

経理デジタル化されて久しいのに、これらの帳簿が手書きされているのは、なぜでしょうか?



政治資金規正法はじめ諸制度で、手書き要求されてる。

経理担当者または氏がパソコンに疎く、デジタル処理できない

③後刻改竄可能にするため



正解はブクマのなかで!

2016-05-16

メタルおじさんにこそ聞いてほしいBABYMETAL

メタルじゃないからなんだかんだと皆さん仰るけど、まあだまされたと思って一度ライブに着てほしい。9月東京ドームかあるから、是非




一見さんの多いフェスFC限定小箱ライブを除く大規模会場国内公演でのBABYMETALの客層は大きく分けて三つ

メタラー特にアイドル偏見はないが、ドルオタではない)

ドルオタメタルは知らない)

ミーハー女子コスプレじみた格好をしている




③はリピート率が低いし、スタンディングエリアには殆どいないから除外するとして、

一見似たような風貌をしている①と②の差は「ケチャ」等に代表されるオタ芸が滑らかにできるかどうか、それから開演前なにをしているかでだいたいわかる。





BABYMETALの開演前SEはザ・王道メタルばかりで、メタルを少しでもかじっていれば非常に楽しく開場~開演までを過ごすことができる。

例えばマスターオブパペッツが流れればフロア全体が拳をあげて「マスターマスター!」と叫んだりする。勿論まだメンバーバックバンドも出てきてない。客はSEを聞いて好き勝手エアギターしたりリズムに乗ったりして勝手に準備運動をしておくことができる。





BABYMETALの開演前SE大御所メタル詰め合わせプレイリストだったのはかなり初期からだけれど、客がみんなでシンガロングしたりするようになってきたのはここ二、三年のことだ。つまりメタルがわかる客が増えてきているということ。

これは単にメタラーの流入だけではなく、元々②側のお客さんにメタル布教することによって元々アイドルオタクだった層をメタルに取り込む、つまりアイドルCDを買ってたお金BABYMETALだけでなく他のメタルバンド還元することが出来ているんではないかなと思う。

なぜって客の絶対数はそんなに増えてないからだ(さいたまスーパーアリーナ幕張メッセを埋めた後のライブ横浜アリーナというキャパティ小さめの会場であることからも明らか)





BABYMETALMCの代わりに、ナレーションコメント的なもの映像を放映するのだが、必ず一番最初に「アイドルによってメタルをはじめとした音楽日本音楽業界から駆逐されつつあった。その現状を憂い、"狐様(=プロデューサーと思われる)"は三人の少女を遣わしたのである」みたいなことを流す。言い回し記憶ベースなので適当です。

まりそもそもBABYMETALアイドル一強の音楽シーンに一石を投じたいという意図があり、その道具としてアイドルを使うという皮肉じみた戦略を取っている。

から本来もともとメタルが好きであるメタルおじさんたちはBABYMETALターゲット層ではない。





しかしこれまた皮肉なことだが、BABYMETALライブを一番楽しむことが出来る客はメタラーなのだ。わかる人にしかからない故に面白いのがオマージュからだ。

こと細分化されたジャンル同士でモメがちなメタラー諸兄も共通言語としての王道はおさえているはずだし、BABYMETALオマージュ元ネタはそれを外さない。(バカにされがちなジャパメタに対してはわりと突っ込んだネタまで持ってくるが)

前述のナレーションライブツアータイトル曲名歌詞ギターリフ様々なところでオマージュは見受けられる。

引用されるのは例えば、

・Metal JusticeMETALLICA

・TRILOGY(イングウェイマルムスティーン

・NEMESIS(ArcEnemy)の歌詞の一部

・THE END OF THE CENTURY聖飢魔II)の歌詞の一部

等々。

それとライブ終わりの「We are BABYMETAL!」のコールアンドレスポンスを何度も繰り返すくだりはXのライブと同じ流れ。

これは前提知識の有無で気付けるかどうかが分かれるので、自分が気付いていないところもたくさんあると思う。もし他にもあれば教えてほしいです。


まあ要するにCDだけではもったいないなんてことはメタラーのぼくたちが一番よくわかっているわけだから、一度ライブに来て、自分たちは歓迎されている、そして縮小の一途を辿るメタル市場じわじわとこんな形で伸びてきていることに対して喜びを感じて欲しいなと思っている。




曲はドメタルなのと全然違うのとで両極端だが、この点は上田剛士氏の起用に関する話なので割愛する(出来ればどこかで上田氏およびTHE MAD CAPSULE MARKET'Sとその後の邦ロックシーンについても文章に起こしておきたい)

曲が一番大事じゃねーか!というご意見はごもっとも…。CD音源だとデジタル要素が強い曲もライブ生演奏だとかなり音作りがメタル寄りになっていてそんなに違和感はない。

ANVILの映画を見るくらいのテンション東京ドームに着てくれたら良いなと思って書きました。

2016-05-15

http://anond.hatelabo.jp/20160513095233

アスペの使う○○「~~」ほど哀れなものはねえな。

元増田は3Dモデル基準でって意味でいってるのにアナログ作画デジタル作画に着眼してるって控えめにいってアスペだろ。

こうやって面白かった定型もつまんないやつが多用していくことで価値と信頼を消失していくんだな。これがインターネットってやつだ。

2016-05-14

ライター矢作晃」問題について

今日1日を素敵な思いで過ごしたい人は、もっと後になってから読んでください。

土曜日大事な時間、なんでこんな不毛なこと…と思いながら…

時間ほどかけて友達リストをつくりました。

お察しかもしれませんが、この投稿が共有されている人は「矢作晃」とある程度、交流がある方々です。

この投稿は、(余計なお世話かもしれませんが)特に 石野 純也 さんと 星川 哲視 さん、あたりに読んで欲しくて書いています。

【1.どう接するべきか(林案)】

子供を育てたことがある人ならわかると思いますが、ダダをこねる赤ん坊にいい顔をしてしまうと、子供のダダはひどくなるばかりです。おそらく最良の方法は無視する、あるいはちゃんと向き合って接する場合には「気をそらす」だと思います。

心をわずらっている彼が、最近、再び暴れているという知らせを何人かから受けて、彼のツイートやらFacebookの投稿、そこでのコメントのやりとりなどを観察しました(ブロックしているけれど、ブラウザプライベートモードを使うとパブリックな投稿は読めるようです。まあ、そりゃ当然か...)。

自分の不幸のアピールは彼の天賦の才能なので、それを見て「かわいそう」、「何か言ってあげなきゃ」と思う同情心の気持ちはわかります。

でも、彼のことをこれから先、一生面倒をみる覚悟がないなら、そして本当に彼を思いやるなら、そこで突き放すことも大事だと思います。

人間は誰しも「人に認められたい」願望があります。彼は特にそれが強いと思います。

さらに自己肯定力はやたらと強いので、誰かがちょっとでも同調をしてしまうと「やはり、俺は正しいんだ」と、この24時間ほどの爆発を生んでしまうというのが私の見立てです。

同情のコメントがなくても、おそらく愚痴ツイートは続いていたでしょう。

でも、ここまで増長することはなかったと思います。

「それでも彼のことが心配だ。何かしたい」という人はいるでしょう。

そういう人への私のオススメは、他の関連のない話題に彼を誘導することです

赤ちゃんあやし方と一緒です)

彼が好きなアニメマンガが好きで、そこいら辺の話が得意な人は、その話で盛り上がるのもいいでしょう。

(この記事の末尾に参考になりそうなうつ病対策のページのリンクを貼っておきました)

「彼の原稿が好き」と本心で思っているのなら、それを書くことについて、私がとやかく言う権利はありません。

 ただ、彼のことを本当に思うなら、もう少し経ってから、過去形で「好きだった」と書いた方がいいのではないかと思います。

【2.なぜ「過去形」なのか?】

彼が言っている通り、彼のIT関係の執筆の仕事は終わりだと思っています。

ただ、今終わったのではなく、とっくの昔に終わっていたと、私は見ています。

 私は彼とは付き合いが古く、同情心や心配さからMacPeopleに彼の連載を提案していたこともありました。「とりあえずお試しで」と特集記事を振った結果、彼は逃亡し、音信不通になり、結局、連絡こずで、私とその編集者で全部を丸かぶりして死ぬ思いをしたこともあります。

 その後も、何度か彼に仕事を与えようと、面白い製品発表の声かけを彼にも回したり、自分企画した重要イベントに彼を呼んだこともあれば、面白いネタを持っている広報会社の人を紹介したこともそれこそ何度もあります。ムーンライトウェーブの望月さんなどもその一人ですよね。

 望月さんなどは本当に彼によくしてくれていると思います。でも、おそらく、彼が呼ばれたイベントを記事にしたことはほとんどないと思います(と、ここは私もまったく人のことは言えないのですが…苦笑)

 編集者などにつなごうと呼んだパーティーも隅で昔からの知り合いと話をするばかりで(性格的に無理か、と途中から諦めました)。

 ここで聞きたいのですが、そもそも、この中で、誰か彼がここ1〜2年で書いた記事を読んだ人、いらっしゃいますか?

 もしかしたら、よく検索すればインプレスかどこかで見つかるのかもしれませんが、彼の最近のPublicへの露出で私が知っているのは有名な彼のツイッターと、あとは Kohichi Aoki と 松尾 公也さんのPodcastくらいです(他に本当にあるのでしょうか?)

 彼は同情心集めが得意で、昔から付き合いがあるインプレス系の方々のスネをかじり続けているのは知っています。インプレスの方々が、他の若い方々にあげられたはずのチャンスの一部を彼に与え続けていたことも。それによって彼は自分が「まだまだライターとしてやっていける」という誤解を長く持ち続けてきてしまったこともわかっています(が、その担当が誰だかわからないし、おそらく友達になっていないので、この投稿をシェアできずに残念です。ご存知の方、ぜひ、この投稿をコピペしてシェアしてください)。

 しかし、そのインプレスも、昨年、彼が海外で暴力沙汰を起こしてからは彼のことを干している、と人に聞きました(被害に遭われた方は散々でしたね)。

 つまり、彼はもうほとんど仕事をしていないんじゃないかと思っています。

 もしかしたら、週刊アスキーが、獲物のいない猟場、食料のない餌場に、ノラ猫の餌をまいているのかもしれません(が最近、読んでないのでわかりません)。

 実は彼のITジャーナリスト業だか、ライター業はとっくに終わっていたんじゃないでしょうか(彼が認めたくないだけで)。

 そこにまんまとアップルさんが、まるでアップルのせいで廃業したかのように見せたと愚痴る口実を与えてしまったのが今回の事件の全貌だと思います。

 

 インプレスに干されてからなのかは、彼の記事は検索しても出てこないくらいに発見が難しいです。ツイッターでもフォロワーは、そこらの大学生以下くらいですよね。 マスメディアならぬ、ナノメディアに近いのですが、地上波テレビでも取れない席が自分に与えられなかったと言って彼は愚痴ります。

 それくらいに存在感のない記事、読者も求めていない記事、編集者もお情けで仕事を与えて手間が増えただけでもしかしたら迷惑かもしれない記事。

 それでも「かわいそうだから何か仕事を与えなきゃ」という不健全な負の連鎖、いつまでもつづけられるわけがないですよね?

 特に今はどこのメディア不況だと聞きます。

 そもそも、あの見苦しいツイートの主の記事を載せるなんてメディアブランド戦略としてもどうなんでしょう。

彼がこの先も「ITジャーナリズム最先端をつっ走って」まだまだこれからかなり遠い先までどんどん走り続けられると本気で信じている人は、ここにいらっしゃいますか?

 このあと、書きますが、彼は自己肯定力だけは強いので、走らせる距離が長いほど、崖の高いところにまで登っていきます。

 今、ここで彼に同情して、もっと先にいけるよ的な声をかけてもっと高いところから堕ちさせるのは、本当に彼にとって良いことでしょうか?

 だから、無責任に彼に自信を与えるのはやめてほしいと、私は思っています。

 自分人生大事な時間を彼のために割くのは、時間と脳の無駄遣いなので、私は今回の件を本当に最後にしたいです。

【3.自己肯定力

私は、何気に彼との付き合いが古いです。

私がアメリカ学生で、彼がバイトで編集の仕事を始めたあたりから知っています。

その後は、海外の取材先で同じ部屋に泊まることもありました。部屋に戻ると、彼が半裸で鼻をほじりながらずっと2ちゃんねるを見ているおぞましい光景を何度か見てきました。消し去りたい私の心の傷の1つです。

そんな私が見るに彼の最大の特徴は:

異常なくらいまでに「自己肯定力が強い」ことです。

彼は、まるで「ポジティブであることが悪いことであるかのように、人のことを「ポジティブ野郎」などと呼んでいるようです。

ただ、自分のことをポジティブに分析する能力では、私は彼の足下にも及びません(いつも、自分ダメだと思って苦しんでいる側なので)。

彼のツイートを昔から見ていると、彼の周りではやたらと物が壊れるんです。

しょっちゅうフォーマットや再インストールをしている印象です。

あきらかに異常な頻度で物が壊れます。

(彼にとっては)もちろん、壊れるものが悪いわけです。

メーカー愚痴を書き始めます。

自分の記事が読まれないのは読者が悪いし、

他の人の記事が読まれるのも読者が悪い、そんな記事を読む読者は地獄におちろ、みたいなノリで罵ります。

自分の媒体力とか自分の記事がどれだけ求められているか、といった部分に関係なく、イベントに呼ばれないと招待しない人を罵ります

昔からやっているから俺を呼べ、みたいな考え方です

自分以外の考え方は一切、認めません。

私が何を取材するか、どう書くか、どう考えるかまでいちいち批判してきます。

ITジャーナリストたるもの、スペックシートを接続詞でつなげたような、無味無臭な記事でないと客観性が足りなくてダメみたいな古い自分だけの考えを振りかざして、それに従わない人間を批判します。

ちょっとだけ自分の考えを言うと「私は客観的な記事は存在しない」、実は存在していると思っている人ほど実は危ないという考えの持ち主です。

実はどのニュースピックアップするかでも主観は入ってくるし、

「褒め 大さじ 3杯/悪いところを見つけ出して批判/スペック 小さじ2杯/個人的感想 一振り」みたいなレシピ客観性と考えるのも間違いだと思っているし、長年、レビュー記事にはシリアスだったMACPOWERで「そのレビューは本当に正しいのか」という自己批判企画をずっとやろうとしていた私的に言うと

ベンチマークテストですら客観ではないと思っています

作る側は世の中にどんなベンチマークテストがあるかを知っているから、そこに向けて性能などをoptimizeしているのは、日本語入力プログラムだけでないことはみなさんもご存知でしょう

でも、日本では「報道客観的でないと」という考えがあまりにも広く根付いている。

だから、「あえて最初から主観」を強く出すのが私のスタイルです。

この話をすると長くなるので(すでに長いですが)、私は文字によるコミュニケーションを信じていません。

そういう人もいれば、無味無臭な書き方をする人もいる、そういうバランスがあり、どの記事からどの記事へも1クリックでいけるのが現代人のバランス感覚だと思います。

それをITジャーナリズムかくあるべきの同じレシピJIS規格された矢作色の世の中になったら、記事は1本読んだら他は読む必要がなくなってしまいます。

ここでちょっと脱線。

みなさんの中で言葉の仕事をしている人は、自分がこう書けば相手に伝わる、と思っている人もまだいるかもしれませんが、25年、執筆の仕事をしていて強く思うのは、読者は自分の知識の範囲やその時の感情フィルターで、自分で読みものを想像創造しています。

いいことを書いたつもりの記事でも、それを批判と捉える人もいるし、私の記事とか感想の振れ幅がめちゃくちゃ大きくてすごく面白いです(ただポエムとか言ってる中身も読んでいない、バカの壁養老孟司読んでください]の人は別としてちゃんと読んでいる人の感想です)

脱線しちゃいましたが、彼は自己固定が強いあまり

業界で起きている時流の変化にも順応しようとしなければ(変わる時流が間違っている)

自分の記事がどんなに読まれなくても、それは読まない読者が悪いので書き方に工夫をする必要もないのです

ある意味脳内では幸せな人ではあるけれど、脳の中と外とのギャップが、いよいよ、大きくなりすぎて破綻し始めたのが今起きていることです

【4.言われの無い矢作犠牲者たち】

ここで、誰も見ていないツイッターとはいえ、2ちゃんねらーがRTし始めて、私とかに絡む人も出てきて、

それでも相手にしちゃうと、調子にのるから、表では静観を続けている私ですが、あまりにもな言われ放題みたいなので、いくつか自己肯定をさせてください。

というか、神尾さんも被害にあっているので、彼のことから擁護すると

私は神尾さんのこともよく知っているので、ここで断言しますが、

彼は神尾さんがSさんと交際があるような書き方をしていますが、

よく知っている人間として断言しますが、神尾さんが好きな人やら何やらについて深いコメントは避けますが(いや、いいお父さんです wink絵文字

Sさんとの交際だけはないことはよく知っています。

証拠を示せと言われると難しいのですが、

1つは神尾さんは交際相手に関して、好みのタイプがかなりしっかりしていて(というか狭い!)、Sさんは良くも悪くもそこから外れるからです。

2つめは、証拠というよりは、矢作デタラメな主張を崩す内容ですが、彼はジャーナリストを唱いながらもろくな事実確認も無しに神尾さんがアップルスペシャルイベント愛人Sさんのことらしい)を連れてきたと書いていますが、実はこれ、神尾さんにとっても私にとってもとSさんは初対面でした。

音楽の男女デュオが実は別々に結婚相手がいても「実はつきあっているんじゃないか」と噂が立つのと同じで、交際とかの経験が少ない人ってやたらとそういうの勘ぐって噂たてたがりますよね。

まさにソレです。

神尾さんがSさんが近しいのは、今、神尾さんがやっている未発表の?プロジェクト関係あります。

彼は、いつも「IT業界の中にいる人」や「ガジェット好きな人」からは真実は見えてこない、とスマートフォンサービスもっと一般の人目線で評価させることの重要性を主張していました。

で、若い女の子とつきあわないまでも、おしゃべりするのは好きなので、よく女子高生女子大生ヒアリングをして探るのが神尾さんのスタイルです(もともと、ドコモの時からそういう仕事をしていましたみたいで、奥様との出会いも...)

実は幅広い年齢層の女性にヒアリングをしていますが、Sさんもそうしたサンプルの中だったのが、色々、話をするうちに本気でライターになりたいという思いを知ったみたく、面倒見よく、いろいろな人に紹介しては、「あの人からは〜〜を学べ」と教育しているようです。私もSさんデザインについての講義を請われました。

ウェアラブルを筆頭に、今やデジタル製品はどんどん生活領域に入ってきているのに、ファッション誌ではデジタルに詳しい人がまだ少ない。

そんな中、生活者目線で記事がかけるライターを増やす必要がある、というのは神尾さんの強い信念で、近々、発表あると思いますが(って書いちゃっていいのかな?)実は神尾さんは最近、そっち方面での活動に本腰を入れています。

 Sさんは、ある意味、その活動の実験台というか第1弾。

 一緒に仕事しているし、(うらやましいことに仕事を振っているので)一緒にいる時間も長いかもしれないけれど、彼とSさんの噂がたつのをみていると

「ん〜、(彼のツボは)そこじゃない」(笑)と心の中でツッコミを入れたくなってしまいます。

 まあ、仮に神尾さんは打たれ強いし、いいとしたとしましょう。

 それにしても本当に根も葉も無いのに、変な噂を立てられて、好奇の目でみられているSさんの立場はどうなるのでしょう?

 彼は精神を病んでいるから、ここは狂犬に噛まれたと思って我慢しろ、というのでしょうか?

 九州にいて、なんとかライター業でやっていきたいと思っていた彼女のやる気を見て、神尾さんがライターの顔ぶれの若返り(平均年齢下げることも考えて)東京仕事できる環境作って、呼び寄せたところで、わめけばいいと思っている見苦しい老害(病害)のために若い才能の1人を犠牲にするのは本当に正しいことでしょうか?

神尾さんが元ドコモコンサル仕事をして、という批判もしているようですが、だからこそ、矢作なんかには書けない、会社の裏事情などの視点が書けるのだと思うし、それを是とするか非とするかは読者次第だと思います。

 もしかしたら、NDAなどがないものは、disclosureとして記事で関係性を明らかにしたら良いかもしれません。

 私もコンサルをしている、ということで彼の批判を受けていますが、一時期、そうでないことがあったのは私の失敗でした(1年半くらい)。でも、そこでも自分なりに中で線引きはしてきたつもりです。

 また、それ以後は、実はコンサルティング契約を結ぶときに、コンサルティングをすることになったからには、ソーシャルメディアでは応援するけれど、マスメディアなどでの記事ではとりあげない、ということを約束していますし、そもそも自分が記事を頼まれる業界とは別の業界コンサルティングが多いです。

 どうしても、コンサルティング先のことを記事で書く必要が生じたときは、去年のfashionsnapの記事や毎日新聞日経産業がそうでしたがdisclosureとして、株を持っているかいないか関係なく、関係性に関する注意文を示してきました。ここら辺はもしかしたらメディア側でガイドラインを作ってくれた方が良いかもしれませんね。別に神尾さんもそこは否定しないと思います。

ちなみに書いている記事が製品のレビューなどが中心だと、少ないかもしれませんが、トレンドの分析などを記事にする人は、その洞察に価値を感じた相手から講演などの依頼を受けるのは、かなり自然で海外でもよくあることだと思います。私自身は書きたいが、心底のモチベーションではなく「世の中を変えたい」がモチベーションなので、企業の中に入って現状をよくするために手を動かす機会の方が圧倒的に増えています。全部明かせないのが残念ですが、一部は今月26日に発表になります。

【5.私の自己肯定

つづいて私の方の自己肯定

彼は自分が正しいと信じていないとやっていけない人間です。

なので、ツイッター喧嘩でも、やたらと関係のない人にいきなりメンションを送って巻き込んで、その人たちが自分の味方であるかのように見せる演出をします。

私は彼にとっての仮想敵なので、批判される側だけれど、彼がそうやって私の周囲の人間にメンションし始めるのは正直迷惑でした。

ある日、携帯おサイフ系の発表会の実況をしていた時に、たまたま彼の病気が強めに出ていた(私がソフトバンクワールドで講演したことへのジェラシーかもしれません)のだと思いますが、こちらはツイッター実況で言葉もらさないように忙しいのに、彼がやたらとつっかかってきて「お財布いらない?レシートはどうする?」とか言ってきたので、そこで喧嘩になりました。

(ちなみにレシートは、皆さんがアップルストアで日々そうしているようにメールで送ってもらえばいい話ですよね?そういうところ、相手を批判するためなら事実を都合よく忘れるところが多いのも彼の特徴です)

今と同じようにツイッターで暴れ出して、そこを周りの人がなだめて、ほめて、彼が「やった見てくれている人がいる、これは甘えなきゃ」と「自殺してやる」と叫びだして(本当に絶望した人は、言わずにひっそりやっていると思います。彼は構って欲しいだけなんです。かまう方法によってプラスなこともあるけれど、同じ壺の中でいくら上に持ち上げても落ちる距離が長くなるだけ、別の壺に移し替えて気分転換されることが大事)、警察に保護されて、その後は親が迎えに来ておさまったようです。

 そこで、私も「もう付き合ってられないや」と思い。

でも、彼のフォローをやめて、そのことに彼が気がついたら大騒ぎするだろうと、わざわざ彼の行動をツイッターでチェックして、彼が海外に行っていてメールとかも増えて気がつかないだろうというタイミングを見計らって(嫌いな奴のために、俺、なんでこんなに気を使ってやっているんだろう。と自分を責めながら)TwitterFacebookInstagramなどすべてのソーシャルネットワークで彼をブロックしました。

 自分を不快にするものが視界に入らない方が、彼も健全に生きられるだろうという配慮だったのですが、私も誰かをブロックするのは初めての経験でわからなかったのですが、私が彼をブロックしていても、彼がフォローしている誰かが私のツイートをRTすると彼に見えてしまうようです。

 もちろん、自己肯定感が強い彼は、私のツイートがRTされてくると、その人をアンフォローして自分の方から改善の道を選ぶのではなく、RTする人たちを「そんなのRTするな」と批判し始めます。

 私がティム・クックに遭遇したのが、やらせとか言っているようですが、実はそうではないと証明できるつづきの写真がいくつかあります(あれは実はWWDCの一般開発者ランチ場所で撮影しました。私が話していたら、すぐに開発者たちがよってきて、大騒ぎになったのでその写真があります)。

 彼が書いている批判の多くは、彼が勝手思い込みで書いているだけの事実無根が多く、証拠がそろっているものもいくつかありますが、相手にするのもバカバカしいので、無視しているだけ。

 良識のあるみなさんの中にもつきあい長い人多いので、真に受けていない人多いだろうけれど、つきあい新しい方は要注意です。

 そんな中、今回、彼が(これまでなんで招待されていたのか不明だけれど、記事は書いていたんだろうか?)今年、地上波テレビでも取れない取材枠を得られなかったことで、「世界一詳しい俺が呼ばれない」と大騒ぎしたようですが、実際のところは既に終わっていた自分仕事の失敗をアップルになすりつけるためだけの見苦しい行為。

 まあ、それも病気ゆえ(実際に通院して薬で治療しているようです)なのでしょうが、病気だからといって周りがどこまで好き勝手に批判されるのを耐えなければならないのか、非常に強く疑問に思ったのが今回の事件であり、無責任な同情コメントが彼を増長させているという事実を知ってもらい、そういうことを同意していただけるならやめて欲しいと思って、この長い記事を書きました。

私は、最近はかなりちゃんとした方々とのお付き合いが多いので、

IT/モバイル業界のあまりにも見苦しい醜態話、およそFacebookパブリックには投稿できませんでしたが、隠す内容ではないのでコピペしてアングラ掲示板で広めてもらったりする分には構いません(というか私は読まないので、感知しようがない)。

また、彼に親しいインプレスの編集の方や、あまり存じ上げないのですが、 山口 健太さん 中山 智さん といった彼と親しい面々は私自身があまりお付き合いがないので、タグ付けしてみたけれど、この投稿がシェアできていない可能性があるので、どなたかが回してもらえればと思います(もっとも近しい方なら、彼がどういう精神状態で、どう対処したら良いかもよくご存知かもしれませんね)。

 近しい方々は、どこかでは彼の問題や、接し方も詳しいと思うので、その辺りの情報共有やアソバイスもいただければ嬉しいです。

 また、 narumiさんは、週刊誌的なノリでこの話題をとりあげないか心配で、あえてシェア対象から外しています。

正直、時期がきたら本人にも読んでもらいたいですが、今はまだ暴れだしたら困るのでやめておきましょう。

なお、矢作さんと、それでもお付き合いを続ける方のために、いくつかどう接したらいいかの参考になりそうなサイトを見つけてきたので、以下にまとめておきます(自己肯定力ネガティブな影響については一番最初の記事が詳しいです):

http://www.utsubyou.co/entry/2015/10/20/#more3

http://oshiete.goo.ne.jp/qa/2130663.html

http://mojostyle.net/sigoto-16/

tag: 海老原 昭、 法林 岳之

この記事は、私がつくった「IT系」(何人追加したのかの確認する方法がわかりません)というリストの人にシェアしています。Facebookでつながっていないのでリストに入れられなかった人は、タグ付けしてみました。ウォールに表示されてしまった人は、投稿右上のメニューから「タイムラインに表示しない」を選べばタイムラインへの表示を消せます。もし、タグ付けされている人も読めるようならシェアされていない人は、あとでタグ付けします。

自分は普段、こういう押し付けはしないほうだと思いますが、この投稿が見れている人たちにとって「矢作問題」はそろそろ一段落をつける頃だろうと思い、あえて押し付けてしましました。

土曜日の大切なひとときにスミマセン。

2016-05-07

予備校いける富裕層の子とガスが止まって水風呂に入る貧困層の子

子育て一つとっても、なんか最近貧富の差がひそかにニュースになってて暗澹たる気持ちになる。

 

ここ10年で地方でも予備校増えて、教育に力いれてる子と、生活が苦しい子の差が浮き彫りになって

戦後みたいに皆が貧しいみたいな貧しさじゃなくて、モノはあふれてるのにお金がなくて買えないみたいな貧富の差

さいこからパソコンタブレットYouTubeに触れてる層がいる反面、そういうデジタルものから阻害されてる層がいる。

 

世の中って機会が均等じゃないって理不尽を感じてなんか辛くなる

2016-05-05

http://anond.hatelabo.jp/20160505221504

検査病院なら再診扱いで初診料かからない+電話で予約できる

しかし別病院だと初診料かかるし予約も一度病院行かないといけない……

初診料今5000円

あとデジタルシステム(予約システムみたいなの)導入してる病院かどうかって

口コミとか病院サイト見てもわからんのよね

2016-05-02

ポータブルCDプレーヤー市場復活してくれ

まずはAmazonポータブルCDプレーヤーカテゴリを見てくれ。

https://www.amazon.co.jp/b/ref=s9_acss_bw_ct_cepetile_ct5_a4?_encoding=UTF8&node=3481221&pf_rd_m=AN1VRQENFRJN5&pf_rd_s=merchandised-search-4&pf_rd_r=FQNJSVADJK842K35B9XT&pf_rd_t=101&pf_rd_p=312030149&pf_rd_i=3371411

完全に市場が死んでる。

大手オーディオメーカーは何年も前に撤退して、残ってるのは所謂安物製品だけだ。


今こそ手軽に高音質で聴けるポータブルCDプレーヤー必要だと思うんだが、いかがだろうか。

CDなんて時代遅れかいうけど、CDというメディア現在もっとも手軽に高音質が楽しめるメディアだと思うんだけども。

PCオーディオ環境を整えたり、ハイレゾ対応ウォークマンやらを買ってハイレゾを購入するなんてことをするよりも、ちょっと良いCDプレーヤーヘッドホンイヤホン聴く方がかえって良いのではないか。

10年前に売ってたソニーCDウォークマンの音質面でのコストパフォーマンスに敵うデジタルオーディオプレーヤーなんてほとんどない。

2万円かそこらであんな高音質を楽しめたんだよ。


現在の状況はなんだ。

最速で新曲聴くためにCDフラゲするものの、結局CD聴くことはせずわざわざスマホウォークマンに取り込んでから聴く

レンタルが開始されるまで待って借りて取り込んで聴く

レンタルじゃメジャーな物しか置いてないのでマイナーものダウンロードするかCDを買うか。

あるいはYouTubeストリーミングサービスで楽しむか。

良い音質で楽しみたいからちょっと高いウォークマンやらプレーヤー買って高い金払ってハイレゾ聴く(これもマイナーもの配信されない)。

PCオーディオをがっちり整えて、CDから取り込んだデータ再生する。


そんなんするよりそのままCD聴けば一番高音質なんじゃないか?

今の状況ってすごいヘン。

CD聴く」という文化は死んでるのに、CDがないと始まらないような環境音楽を聴いてる人ばかり。

CDってまだまだ身近にあるよね。ブックオフとかで安く手に入るし。


から一周回って最近普通にCD買ってCD聴くようになった。

10年前のソニーCDウォークマンで。

店頭コンサート会場で買ったのに家に帰って取り込むまで聴けないなんてこともないし。

家で聴くのもCDで聴いた方が良いし。

意外とポータブルCDプレーヤーって便利よ。


(追記:ちなみに今の技術ならCDケース並みのサイズプレーヤーを作ることは普通に可能らしい。あとCDハイレゾ両方再生可能なタイプとか欲しい。)

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」OAuth代替

適切な OAuth ベース設計とはどのようなもの

ここまでで「普通実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステム一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

はいえ、このように設計されている OAuth ベースシステムはごくごく希少で、しか一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0概念や追加機能すべてを加えて再構築され、セキュリティユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワーク必要というわけではありません。現状、OAuth とはどのようなものかについての意見サービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータ改竄を防ぐため変数署名する方法だけであり、この点に関して、ほとんどの OAuth ベース実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中企業サービス提供する一流プロバイダで、合計 30% 以上という途方もない市場シェア他者を圧倒していますAmazonアプローチは、自分アプリ認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者提供することです。この認証情報で、どの Amazon サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイルURL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれ説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティアプリあるいはサービスに貼り付けますユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者おかし負担を強いることなく、すべてのアカウントAPI サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービスから提供してもらう必要が本当にあるのは、適切な役職 (管理者アカウント所有者など) を持つユーザ自分に割り当てられた権限や (望むなら) 期限を持つ認証情報API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報ネットに通す必要のない暗号学的テクノロジー活用した認証プログラムに基づくものなら何でも使えます特に HMAC は、承認認証実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数フレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャワンタッチで装着できるようなモジュール化の実装が可能です。ユーザアプリ認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムOAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザ認証情報要求したり他に弱点があったりするような一部の劣悪な設計システムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初存在していなかった問題まで生じさせています宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています

これからサービス設計をして API アクセス提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。

OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。

おことわり

前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。

言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたお気に入りOAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。

また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法OAuth を使っているサービス利用者であっても、また自ら OAuth ベースサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。

記事の構成

この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。

この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。

この前書きのあとは、まず OAuthセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。

その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。

最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。

責任ある情報公開

いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーOAuth ベースサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースシステムの主要なセキュリティ欠陥は非常に蔓延しています。

筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。

というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。

ここで言及されている情報やリンクされている情報は今のところ既存のサービス悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のもの破壊するのではなく改善することを目指してください。この記事は、自社サービス不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。

想定する利用形態

この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。

まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。

ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッショングループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。

ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。

ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的営業部門メンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。

問題点

セキュリティ関連
認証情報の盗難 / アクセス権の詐称

トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティアプリサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

  • 必要以上のアクセス権をサードパーティに与えることになる。
  • 認証情報を格納する場所が増えるということは、盗まれる危険が増える。
  • パスワード等を変更したときに API 利用者側でも更新が必要になる。
  • ひとつアプリだけでアクセス権を破棄することが難しく、全アプリで破棄することになりやすい。
  • 特別な認証要素を使っていると、制限が多すぎる。

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、OAuthセキュリティガイドラインは、OAuth を利用する開発者ユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。

私の知る主要な OAuth ベースサービスはほぼすべて、ここに概説した手法で攻撃可能です。

OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください! 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者管理者に「OAuthもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。

OAuth サービスに偽装

OAuth ベースサービス設計でよく見かける間違いは、ブラウザ用に、パラメータひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリサービスユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローOAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。

「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。

EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebookユーザは全員 GMail に対して Facebookのもののふりをすることができてしまうということです。

この問題は、OAuth エンドポイントユーザウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。

ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)

Citrix もこんな間違いをしています:

(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)

Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースサービス開発者でさえも似たような状況で潜在的ヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。

サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービス一般的にいって独自の「SDK」を提供しており、サードパーティ開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。

この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアント機密情報を取得する脅威」に分類されています。しかしサーバウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームOAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。GoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、Permalink | トラックバック(3) | 12:44

2016-04-23

ブロックチェーンを使ったトラックバックのような仕組み

  1. どこかのニュースサイトなり、個人のブログなり、Twitterなりの文章画像データからコピーしたときに、文字データ画像データの裏にブロックチェーンが埋め込まれる。どこに引用されたかについて、アセット管理ソフトで追跡が出来る。
  2. 引用なのか盗作なのかも、コピー先を追跡することで判別する
  3. デジタルデータコピーされて使いまわされてなんぼで、コンテンツ発信元利益還元されさえすればいいかと思われる。
  4. DRMのようなコピー禁止ではなく、もっと積極的コピーしてくださいという方向
  5. 1万コピーされたとしても、そのほとんどが利益生み出さないとしても、数%%が利益を上げたとする。利益取引の中にコンテンツ取引も入れてやり、大元還元してやれないか。

2016-04-19

回答してみる:「テレビ局地震報道の後進性 どうしてアナクロな…

https://note.mu/enkykliospaideia/n/nc971ac77b96c

この話ね。まず、

1 技術が活かされてないと感じる

テレビというメディアは単純な受身型のメディアという面がありますが、最近地上波デジタル放送によって双方向対応したり、サブチャンネルによって各局複数情報を同時放送できるようになってます。でも、そういったことが災害報道では全く活かされないのはどうしてなんでしょう?

なっているのは規格だけ。双方向で送れるのは5つのボタンを押したかどうかだけだし、その情報インターネットがつながってないと送れない。停電しているところに「無事ですか?」ってアンケート送ってそれに対する返事があったりなかったりすることが災害報道で活かせるかというと、ないよりましな程度。

地上波デジタル放送になって、テレビチャンネル複数放送できるようになっているのに、それを活用しないのはどうしてなんでしょう?

複数放送できる規格になっている」だけ。

サブチャンネルは、リアルタイム動画エンコーダ複数持っていないと放送できない。MX複数チャンネル活用しているね。あとは、関東地区キー局関西地区準キー局、あとはプロ野球ホームチームが強いところだと複数エンコーダをもってる可能性があるけど、熊本微妙。使うかどうかわからないSD動画エンコーダを入れるってかなりの経営判断になるし、これを書いた人は2006年位に佐々木俊尚が「2011年新聞テレビ消滅」とまで煽っていたことを忘れているんじゃないかな。実際5年間の移行期間の出費とデジタルTVの普及率次第ではそうなる可能性もあってどこもなるべく安く導入しようと必死だったから。たぶん、双方向データ放送制作設備なんか、もってるところのほうが少ないと思う。

資料をその場でハンディカメラとかで写してくれてもいいんじゃないかと思うのです。

そのアイデア面白いHD化しているのでもしかしたら映るかもしれない。ただし、筆者はたぶんお役所が出している資料がどれだけ読みにくいもの認識の外にあるんじゃないかとも思う。資料PDF役所webサイトに公開されているし、それを再生紙印刷したら、手持ちのカメラを使って録画して見てみるといい。

ちなみに、「どのチャンネルも同じ絵を映している!もったいない」はたぶん担当者も同じことを思っていて、記者会見なんかは余裕のない地方局を中心に代表カメラを出してあとはそれを分配、なんてこともしているけど、これその代表者撮影に失敗しても泣かない、ということとトレードオフなので重要なところほど他に任せられなくなるという問題がある。


2 センセーショナリズムから抜け出していない

被災地悲惨な状況や、困窮、資源の不足を取材したのなら、そこにうまくそれを助けるために私たちが何ができるか、義援金のお願いや救援物資の送り先といったもの情報をうまくセットにして常に伝えるといった工夫が足らない

義援金のお願いは普通にしている。ニュースの〆に流れているカンガルー災害募金(今は別の名前になっているけど)とか、ドラえもん募金とか聞いたことないとは思わないけれど、それがセットになって伝わっていないとなるとちょっと厳しいかもしれない。

救援物資の送り先は基本的には流さない。なぜかというと、救援物資が足りない、と言われてから個人に用意されてもどうにもならないから。そもそも、困窮とか資源の不足の話、今回の熊本地震では、東日本大震災の時の教訓もあってかなり抑制的になっているというか「(届けてくれるところはあるけれど)それが来るまでの数日が足りない」っていう話とセットになっていたはずで、本当にこの人、災害報道見ているのかちょっと怪しいと思った。

3 リソースの配分がおかしいのではないか

延々テレビ局スタジオから放送しているのに、出てくるのは切迫した雰囲気で伝えるアナウンサーと、わずかな地震学者や地質学者系の専門家だけという感じなこと

バラエティ番組情報番組であれほどコメンテーターやら、何やら評論家やらをたくさんテレビ局に呼んで並べているくせに、こういう長時間放送の時にこの人の少なさはなんなんでしょう?

もっと役に立つ人がいるなら呼ぶから、こういうのはその役に立つ人の名前を出してほしい。ちなみに、エコノミークラス症候群とか、避難所がそもそも危ない場合もあるとか、そういう話については専門家を呼んで話してもらうまでもなく共有されている情報だったので、キャスターから直接語りかけられていたよ。

4 正確性が疎かになっていること

テレビはその速報性やリアル感といった部分での競争意識するあまりネットで流れる情報をあまり確認せずにテレビでも取り上げるという愚を犯すようになり、自ら信頼性を下げているのは嘆かわしいことといえるでしょう。

これ、具体的にはイオンモール火災の話だと思う(マンションの接合部はそこがもともと計算した上での設計であろうと今回の地震で壊れたことに変わりはないし、熊本城の瓦は加藤清正設計じゃないよね?)けど、そこは確かにどうにかしないといけない。

はいえ遠隔中継できるカメラを持っている人が山ほどいる時代にそれを使わないのは流石に微妙なので、誰を信用するか、みたいな部分で担保するしかないのだろう。

正直、正確性と速報性はどちらも求められることで、そのバランスは難しい。新聞テレビと比べると、テレビは若干速報性にバランスを振っているし、新聞は正確性にバランスを振っている面はあるので、そこは新聞と併用してほしいとも思う。

カセットテープを大量にデジタル化した時のメモ

色々あって大量のカセットテープデジタル化した時のメモ

なお音質は特段こだわりはなく、数を取り込んだ話です。

再生機器や録音機器

再生機器NR付きの方が後々楽(後述)。

録音形式はある程度の音質で取り込んでしまえば後で加工してしまえばいいのであまり考えない。

音質云々は割愛

後処理

曲分割

ある意味一番時間がかかるのがここ。

NR付きの再生機器ならテープ録音状態によっては機械的に分割処理かけてしまえば簡単に綺麗に分けられる。

ただこれが使えないテープ場合手動で分けることになるがこの場合大変。

このとき必要なのは時間だが、古いと曲名だけで時間は意外と載ってなかったりする。

最近Google先生が気を利かしてくれて、そこそこ有名だとアルバム名で検索すると曲時間が簡単に出てきたりする。

この情報経由で動画等を検索できる便利な情報だが、この表示されている時間情報動画時間から自動生成されているらしく偶に変な情報があったりする。

タグ付け

これが面倒かというとそこそこ有名な曲ならば簡単だったりする。

対象の大半がCD化もされているような音源だったので(ならデジタル化する必要は?とは言わないで)Gracenoteのデータベースを引っ張ってくれば簡単。

今は既存音源からでも検索がかけられるので、適当アルバム単位検索すれば大抵引っかかる。

自分場合この作業にはMedia Goを使っているが、そのままだと引っかからない場合でもアーティスト名やアルバム名のタグ情報を入れて再検索をすればまず存在する。

言語で出ている作品場合、別言語タグ情報に書き換えて検索すると引っかかったりもする。

またGoogle Play Music場合、あちらでデータがない曲で一度間違ったタグ情報で上げると記録されるのでタグ情報を書き換えてアップロードしてもそのままでは反映されないので注意。


ノーマライズ

後でバッチで一度に処理すれば良いという考えで保存用に関しては特にこの処理はしない。

保存等

現代HDDBDなら、FLAC可逆圧縮でもかけておけば一本辺り200MB~500MB程度と大した容量にならないので普段用と別に保存してても大して逼迫しない。

これが今デジタル化しようとしたきっかけの一つ。

保護にはBDならMultiPar等でパリティを付けて保存、ディスクの保管はBD対応した不繊布でもいいが数百本取り込んでも数枚程度なので転写が嫌ならハードケースで保存してもスペースには問題ない。

BDは今のベアディスクタイプですら10年近く経った規格でそれなりに成熟していると考えられるのと、かなり減ってきたがまだ地方だと相次いだメーカー撤退による投げ売りが偶にあるのでネットで買うより処分品狙いで買ったほうが安かったりする。(狙い目はDVDレンタル店)



流れ作業で行う場合

データとともにカセットテープのケースやインデックスカード画像データを保管しておくとアルバム名等を確認する際に現物をいちいち確認する手間がなくなるので捗る

またミスで再取り込みになった時も画像を手掛かりに現物ピックアップできる。

カセットテープ本体はCISスキャナしかない場合取り込みは困難なのでインデックスカードだけでも取り込んでおくだけでもいいが、その場合音声データを取り込む前に本体のラベルインデックスカードが正しい組になっているか確認したほうがいい。

ただ単純なインデックスカード場合スキャナドライバの性能によるがそこまで面倒ではないものの、特別意匠をこらされている場合この作業は凄まじく面倒になる。


結論

自分のような勿体ない症のような人以外は特別もの以外はカセットテープデジタル化は止めておいたほうがいい。

2016-04-16

技術書の訂正がめんどい

プログラミング技術書に誤りがあったか出版社HP行ったら、正誤表はあるけど肝心の訂正を受け付けるフォーム的なものがなかった。

一応出版社の問い合わせフォームはあるんだけど何故か所属組織やら電話番号やらの個人情報要求される。

元々善意で訂正しようと思ってこれだから当然訂正はやめておいたので、5刷りもしてるこの本は当分技術的な誤りを抱えたまま8000円で売られ続けるんだと思う。

何が辛かったって、コードバグが有るとかじゃなくて数式の式変形が間違ってたってこと。

数学得意な奴は問題なく気づけるんだろうけど、得意じゃないから勉強しようとこういう本を読んでるわけで、問題自分じゃなくて本にあったって気づいた時は泣きたくなった。

一応訂正内容を書いておく。誰かの役に立てば嬉しい。

ボーンデジタルの『ゲームプログラミングのためのリアルタイム衝突判定』のp47の重心座標を求める線形方程式

v(V0 . V1) + w(V1 . V0) = V2 . V0

v(V0 . V1) + w(V1 . V0) = V2 . V1

になってるところが、

v(V0 . V0) + w(V1 . V0) = V2 . V0

v(V0 . V1) + w(V1 . V1) = V2 . V1

にならないとおかしい。

訳本だけど、原著でもミスってるのかはわからない。少なくとも原著のErattaには訂正が書かれてなかった。

2016-04-14

アナログデジタルフィジカル

http://jaykogami.com/2016/04/13029.html


インターネットによる音楽配信が始まる前、「アナログ」のレコードに対して、CDは「デジタル」という言葉で捉えられていたように記憶している。


記事では、インターネットによるダウンロードストリーミング音楽配信のことを「デジタル」、CDなどのことを「フィジカル」と呼んでいるようだ。意味が通じないことはないけれど、フィジカル対義語デジタルと言われると少し気持ちが悪い。


何か良い呼び方はないものか。