  |
はてなキーワード: サードパーティとは
後なんかweb系の企業がgolang採用多いので、ある程度詳しくなっておけば就職困らなそうという予防線。
今のところが成功しなかったらeurekaとかmercariとか雇ってくれませんか！
どっちもユーザーです！（ペアーズでは3名ぐらい逢った、メルカリではバイクとMacbook Air売ったなー。）
ポケモンGoとかやんねーし、地味に自分がよく使っているアプリやサービスから成功パターンを得るのがいいのかなぁ
なんか、人との接点がうまくできているCtoCサービスがうまくいっているような感じが（CtoCなんだから当たり前か、何いってんだ）
人とコンバージョンしたいです。
はてなのゲーマー様や自称ゲーム市場事情通の皆さんってこういう木を見て森を見ない議論好きだよね。
海外はサードパーティがきちんと自分たちでゲーマーじゃないユーザーをCS機に呼び込んで囲い込み、
その囲い込んだ非ゲーマーをゲーマーに調教する仕組みを整えてる。
だから市場が拡大するし、拡大した市場でニッチゲームからAAAタイトルまでの売れる絶対数が増える。
自分たちできちんと自分たちの商売の土壌をメンテナンスしてる。
じゃあ、国内はどうだろう？ゲーマーではないユーザーを囲い込むために非ゲーマーにゲーム会社が目を向けると
「こんな企業は終わりだ（俺を大事にしない企業など終わって欲しい）」だの、
「ゲーマーを大事にしないから日本市場は駄目なんだ（俺を大事にしろ）」だの、
自分だけを見てないとヒステリー起こしてわめき散らすゴミカスの巣窟だろ？
海外だってそういうゴミカスはそれなりの数居るんだけど、ゲーム会社はそいつらの奴隷にはなってない。
なぜ日本だけそれが問題になって、海外ではそうならないのかの根本の原因は少子化。
一番時間の価値が低くて大量に浪費可能な子供の絶対数が減ってるんだから、ゲーム専用機市場の新規ユーザーは減る。
ゲームだけで育ってきてゲームに嫌われたら人生終わりな老害も年をとるごとにゲームばかりやってられなくなって
自然減少してはいるんだけど、それ以上に少子化で新規ユーザーの絶対数が減ってるから、老害の割合はむしろ増えてしまってる。
だから、割合の増えた老害のヒステリーを国内メインで活動するゲーム会社は無視しづらい。今の日本の政治状況と同じだね。
ゲーム会社だけではどうにもならない問題だけど、ゲーム会社とその客がお互い足引っ張り合って
全員が不幸になる道をたどってるのが国内ゲーム専用機市場の唯一にして最大の問題。
そこを何とかしないとどうにもならんよ。
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for Businessは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 サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの 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
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
前掲のセキュリティ文書は、アプリの認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げます。さらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。
トークンベースの認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなものを設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分のプラットフォームも自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースのフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。
トークンベースのシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的なスクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。
もし生成されるトークンが予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまいます。筆者は、fortune 500 クラスの大企業による OAuth ベースなサービスが一種の単調増加 ID (おそらくデータベースのフィールド？) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在のトークン ID を見て、その後の ID を予測すれば、続く任意のユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。
このクラスの攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意の OAuth ベースなサービスが外部レビューでセキュリティを証明してもらえる可能性はあまり高くありません。
本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースのサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通の OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通の実装における」OAuth がよくやる使い方ではサーバの信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。
一方、一部の OAuth ベースの実装は乱数の必要性をクライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者な利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者は脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険を回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。
本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクをユーザが貼れる、掲示板やメッセージングソフトのようなサイト自体からでもスタート可能なのです。
色々な手法で CSRF に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。
CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。
また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。
転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。
OAuth は CSRF 攻撃を防ぐ CSRF トークンを指定するようにと、オプショナルな state パラメータを定義しています。しかしながら、OAuth ベースのサービスは一般的に state の長さや文字種を制限し、要求どおりそのままで返さないことがあるようです。そこで、おかしな互換性問題が起こるため、多くの OAuth ベースサービス利用者はリダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されています。state パラメータの別の懸念は、EVS 側で state にアクセスのある人はだれでも、リクエストを改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。
OAuth ベース API の利用者は、自分のアプリやサービスを登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的に危険の伴うアイディアで姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースなサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効でパラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険なものを state パラメータに詰めこもうとし始めたり、浅薄なシステムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザを不適切なページに誘導する危険性が出てきます。これは「10.15. オープン・リダイレクト」に分類されます。
こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体が悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザに大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報で認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法や改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通の実装における」OAuth の低品質な設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベースの利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています。
ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります。
セキュリティに関して言えば、「普通の実装における」OAuth の仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースなサービスの中には、種々の攻撃に対して無防備でいることを利用者に公然と要求するものがあります。サービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要なセキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質なプログラミング習慣を招いています。OAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティを提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。
この記事についていえば、個人的に蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所で OAuth に使っているのを見たまま開発者がコピーした結果というものもあります。
OAuth ベースのサービス開発者もその利用者側の開発者も、OAuth ベースのプラットフォームを実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラスの攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装の仕様書やセキュリティ・ガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルのセキュリティを実現することはできません。
真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます。
(略: ふつうの実装では、サービス側がプラグを引き抜くようにして自由に利用者を出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)
(略: サービス側からは API 利用者という大きすぎる単位でしか見えないので、たとえばビデオカメラのアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位。対策としてユーザに開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)
(略: ふつうの実装は SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリが cURL 的なもので API を叩こうとしても、JavaScript が必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新がメタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのはセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトやデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバをlocalhostで立てるとかアホか。)
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (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 のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。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 に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の 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 がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
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 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
炬燵のヒーター部分が壊れた。メーカー保証はとっくの昔に切れてる年数。
なのでヒーター部分だけ交換しようと思ったが、その前にコタツ丸ごと新品だと値段どのくらいなんだろ？
と試しに調べてみたら
http://kakaku.com/kaden/kotatsu/
並んでるのは「YAMAZEN」とか「コイズミ」とか「東谷」とか馴染みのないメーカーばかり。
大手家電メーカーは揃ってコタツから撤退してたのね。知らんかった。
厳密に言えばパナソニックは住宅設備扱いの掘りごたつは作ってるけど。
石油ファンヒーターから大手家電メーカーが一斉に撤退したのは、ナショナルのFF式ストーブでの死亡事故を受け
購入顧客を把握できない、定期点検も義務付けられてない、なのに永久に安全を保証しろ、ではやってられん
でそうなったのは知ってたけど、コタツ業界もこんなことになってたとは。
まあ考えてみれば日本でしか売れないガラパゴス商品だし(イランには「コルシ(Korsi)」と呼ばれる同様な暖房器具が
あるそうだが←wikipediaで知った）、電化製品としての機能はこれ以上あまり発展なさそうで差異化が難しいし
いざヒーター部分が壊れたにしても、ヒーター部分の交換だけで済ませちゃって買い替え需要もあまり望めないから
撤退も宜なるかなって感じだわ。
ヒーター部分を探す。こちらもなかなか寡占化が進んでる。「こたつユニット」と呼ぶのか。
http://www.amazon.co.jp/b/ref=amb_link_69775869_35?ie=UTF8&node=85240051&pf_rd_i=3895761=289254069
山善 (YAMAZEN) はメトロ電気工業からのOEMらしい。
すぐ使いたいと家人から要望があったので家電量販店にてメトロ電気工業の品を購入。
こたつユニットの取り付けネジの位置とコタツの机部分のネジの位置が異なるのでボルトオンとはいかず。
昔は取り付けネジの位置をあえて各社変えることで交換用こたつユニットのサードパーティを排除してたのか知らんが
こたつ及び補給部品の供給から撤退するなら、残存メーカーにボルトオン取り付けできる製品の生産を依頼するとか
変換キット用意するとかしてほしいと思った。
Twitterの表示が来週から変わるらしい。日本のTwitter文化は割と全ツイート読みな気がする。一部ユーザーをテスト的に新しい仕様にしてるみたいだけど評判はイマイチ。SNSに割く時間が減っている？なんて思ったが前述したように全ツイート読む日本人には不向きすぎる。今や多くの企業がTwitterで情報を発信している。フィード配信より速いかつ、個人的には見やすいため重宝している。これからは「リスト」で管理しなければいけない時代がやってきそう。そもそもサードパーティのアプリも潰れてしまうのか？パターンを選択できるようにできないのか？
広告ブロックアプリを作っているのはAppleとは関係のない個人または法人。
何の広告をブロックするかしないかの選択基準はサードパーティーアプリを作っている個人または法人によって異なる。
Google Analyticsで解析可能にするしないの選択も当然サードパーティアプリ制作側次第と思われる。
どの広告ブロックアプリを選択するかはユーザー次第であり、もちろん広告ブロックアプリを使用しないという選択肢もユーザーにある。
今までPCからだと普通に出来ることが、スマホだとなぜかできないことこそが異常事態だった。
しかしながら、今現在も多くのユーザーはPCブラウザのABPなどの拡張機能の存在も知らないし利用していない。
常に一定数のユーザーだけが広告をブロック機能を利用するし、しないユーザーは永遠にしない。
http://anond.hatelabo.jp/20150211212201
App Storeのレビューが極端に低く、最初サードパーティ製アプリかと疑いました。低評価の大部分は管理（質問が消されたなど）やユーザーに対するもので、アプリの品質に関してのものは少ないようです
アプリはLINEと同じようにシンプルで良いデザインですが、かなりGoogle+のアプリに似ているなと思いました。購読したジャンル（購読情報はプロフィールで公開されます）に寄せられた質問がタイムライン形式で流れます
んで中身ですが、まあ小中学生ならこんなものかなあと言う印象です。特に酷いとは感じません。小中学生が皆マトモなら少年法なんていりませんしね、色々馬鹿なことをやって成長していくもんです
自身、年に数回やっている事なのでメモとして残しておく。 ただし Win 8 以降に関しては当てはまらない事も有るかも知れない。
１． 下記をあらかじめダウンロードしておき、CD-RW や USB メモリに書き込んでおく。
ａ．最新の Windows サービスパック（Windows インストールメディアが最新サービスパックを含んでいればもちろん不要）
ｂ．チップセットドライバ（Intel の場合は インテル・チップセット・ソフトウェア・インストール・ユーティリティー http://www.intel.com/p/ja_JP/support/highlights/sftwr-prod/inf ）
ｃ．SCSI or AHCI ドライバ（Win Vista 以降は標準で AHCI に対応したので不要）
ｄ．対応する最新の DirectX http://support.microsoft.com/kb/179113/ja （なお AMD 製ビデオデバイスの場合は不適合でブルースクリーンとなる事がある）
ｅ．各種デバイスドライバ（特にビデオと有線ネットワークは必須）
２． BIOS 設定を確認する。 AHCI が使えるなら、AHCI にしておく。 ブート順序（どのディスク／デバイスから起動するか）も設定する。
この際、起動デバイスをどのようにパーティショニング（分割）するかを考え、起動用パーティションを確保する。 既存のパーティションをそのまま使う人もいるが、面倒であってもいったんパーティションを削除して新たに確保し直す事を推奨する。
これは Windows サービスパックや他ドライバよりも先にインストールする事が推奨される。
http://www.intel.com/jp/support/chipsets/inf/sb/CS-009270.htm
他に何かをインストールしていると、それが要因となってサービスパックのインストールに失敗する事例があるため、チップセットドライバの次に優先的にインストールする事を推奨する。
Win XP の頃まではビデオ・オーディオドライバよりも先にインストールする事が推奨されていたが、Vista 以降はマザーボードの事情により左右されるようになったので、この時点でインストールしなければならないとは言い切れない。 DirectX の最適なインストール時点は、個々の事情に合わせて調査する必要がある。
ちなみに現在、DirectX は Web インストーラ http://www.microsoft.com/ja-jp/download/details.aspx?id=35 が主流であるため、８．項以降にインストールしても問題は無いのだろうと推察される。
７． ビデオデバイスがあれば装着し、そのドライバをインストールする。 場合によっては適宜設定を行う。
Windows はもともと標準ビデオドライバを内蔵しているが、（たとえオンボードビデオであっても）より適合したドライバでそれを上書きする事を推奨する。
８． オンボードデバイス（オーディオ、有線ネットワークなど）のドライバをインストールする。 また、後のトラブルを避けるために、ネットワーク名を半角英数字だけに変更する事を推奨する（※１）。
９． その他のデバイスを装着し、ドライバをインストールする。
要するに、ハードウェア・デバイスのインストール順序は、より「内蔵」度の高いものから、低いものへと行うのが原則である。
Windows の状態によっては、Windows アップデート自体がすぐに使えない事がある。 そのような場合、Windows アップデートを行おうとすると、Windows から指示が出されるので、それに従う。
ここで失敗する場合、インターネット接続に問題がある可能性が考えられる。 ネットワーク設定を確認する。
メーカー製 PC におけるプリインストール Windows の場合は不要。
http://windows.microsoft.com/ja-jp/windows/genuine たとえメーカー製 PC であっても、中古品の場合は検証を推奨する。
１３． Windows アップデートで、まず Internet Explorer のバージョンを上げておく。
先にこれをやっておく事で、古い IE の余計なアップデートパッチを適用しなくて済む。
１５． この時点で、システムのバックアップを作っておく事を推奨する。
以上
※１
実際に起きた問題例として、サードパーティ製のファイアウォール・ソフトが、日本語を含むネットワーク・アダプタ名を認識出来なかった、という事があった。
これに限らず、海外製のソフトを使う事が多い場合、フォルダ名やファイル名などは、極力、半角英数字だけを使うようにした方がトラブルを避けられる。 本来、そうであってはならない事ではあるが。
全体に何を言ってるかよくわからんかったが、WWW::Mechanizeだけ使ったことがあって心当たりがあったので調べてみた。
出典は↓のサイト
http://d.hatena.ne.jp/kitamomonga/20110628/ruby_mechanize_2_0
このサイトによれば、
「2011年6月27日に、Ruby のスクレイピングライブラリ Mechanize のバージョン 2.0 が公開されました。」
「1.0.0 以前から警告されていましたが、WWW モジュールが実際に削除されました。Mechanize 2.0 では WWW::Mechanize という記述は単にエラーが出ます。」
らしい。
つまり、WWW::Mechanizeの名前で使えたのは3年前。それ以前から警告が出ていたようだから、元増田がWWW::Mechanizeを警告なしで使っていたとすれば、少なくともそれ以上前のコードなわけだ。
Perlと違い、RubyではMechanizeは標準ライブラリではなく、単なるサードパーティのライブラリだ。それが3年以上無変更で動かないからといってRubyという言語自体を否定するのは、ちょっと飛躍が過ぎるんじゃないか。
Perlが3年以上一切互換性を破壊する変更をしていならそれは結構だけど、結局それは、（よく言えば）枯れた言語だからという理由もあるだろう。単にPerlが死につつあるのを、Rubyをダシにして抵抗したいだけに見える。
ベクター: http://www.vector.co.jp/
言わずと知れた老舗ソフトウェアダウンロードサイト。毎日更新されるコンテンツは「新着ソフトレビュー」くらいなのに毎月7800万PVの高○○を誇る。（巷で人気のはてなは全サービスで2億PV/月らしい！ワーオ！）ベクターの広告掲載料はPVあたり0.05円だとか。今は…、…といった企業の広告が掲載されている。
世間に高い印度象を与えた遠隔操作ウイルスバスター事件に対するHIT-BITの印象はどうだったろうか。スーパーハッカーが自己満足のために起こした事件とか？
スーパーハカーといえばやはり遠隔操作。遠隔操作でCDトレイがガコンガコンだろうか。そう考えるとEjectコマンドユーザー会なんか完全にブラックハット集団だろ……何人いるのか知らないけど
この騒動の中で耳慣れないソフトウェアが複数登場した。例えばこういうものだ。
我々が普段ホッテントリで目にするアプリとは何か違う。例えばサーバ→鯖→ﾏｶﾚﾙのような発想と同じ匂いを感じずにはいられない。それに「パケット警察」よりも"SoftEther社のパケット監視ツール"と言われたほうがピンと来る。
ベクターにはこういったゆるキャラ的名称を持つアプリケーションが数多く登録されているのである。
私は空気読みができる人間だ。つまり何が言いたいかを改めて申し上げると、エバーノート活用法と聞けば、自分の時間を犠牲にしてでもライフハックMethod収集に勤しむ意識高い系ライフハッカーや、Markdown対応と言われればナンでもカンでも有り難がる技術系アーリーアダプターの方々や、はてブなどのソーシャルメディアに居を構える人たちと、ベクターユーザはどこか違うということを思わせる印象操作である。
増田一族の皆さんは日本で一番使われているWebブラウザをご存知だろうか？ ……その通り、IE9である。ところがだ・私は１０年以上、隔週一度の頻度ではてなブックマークを利用してきたが、いまだにIE9のハック記事がホッテントリ入りしたのを知らない。ちなみにOperaもない。
ベクターで人気のアプリケーションで「めもりーくりーなー」をご存知だろうか。不要になったメモリ領域を回収するシステムメンテナンス系ツールなのだが、実態は大量にメモリ確保をするものだ。Windowsはメモリが不足すると使用頻度の低いメモリ領域をシステムディスク上のスワップ領域（仮想メモリ）に追いやり、物理メモリを確保する。それが空きメモリ復活のからくりである。
遠い昔、メモリ最適化ツールとして「ただ数を足したり引いたりするだけのプログラム」が持て囃されたことがあったが、めもりーくりーなーのコア部分はメモリ確保のAPIコールをするだけで済んでしまうので、足したり引いたりほども難しくはないのである。
そんなツールが人気のベクタソフトウェアライブラリというと誤謬（ごびゅう）があるかもだが、そんなベクターが月あたり7800万PVである。ワオ。「そんな」とか言えない。そんなベクターからは毎日収録ソフトのアップデート通知が来るが、再インストールとほぼ同じ手間をそうそう小まめに行う人間がいかほどいるだろうか。注目ソフトウェアを取り上げる「ベクターソフトウェアニュース」ははてブと違って1日1回の更新だし、メールマガジン「ベックル」だって手作業での編集だ。それでもはてな2億PVに対してベクター7800万PVなのである。それを620万のUUが支えているので、1人あたり12PV余り稼いでいる計算になる。今のはてなは2億PVに対し4000万UU(U'ｪ'U)→1人あたり5PV。情報の更新量で言えば個人ブログのスターダム層とあまり変わらないのではないだろうか。MLBに例えるならブログ界の野茂英雄とも言える旧イケハヤ書店さんが今年3月に100万PV/50万UU達成を記念して焚き付けを行なっていたが、同程度の情報更新量とするとイケハヤ100万パワーとベクター7800万パワーの差は一体何なのか。火事場のクソ力vs平時のキン肉マン並みの差である。（ちなみに超人界の神々が1億パワーであることもご考慮いただきたい）これは何か常連にしか見えない㊙コンテンツがあるとしか思えない数値である。
（そういえばはてなダイアリーからニコニコのブロマガにもらわれて行ったベックルハリー先生は、映像でもお見かけする機会が増えて、以前より増してご活躍のようですね。ニコニコ静画のコンテストで新作の絵師さんを決めたそうで気になります）
注: 「めもりーくりーなー」はCodeZine「マンガで分かるプログラミング用語辞典」やマンガでわかるJavaScript / Javaプログラミング、最近ではnoteでも連載中のクロノス・クラウン 柳井 政和さんの著作です。実際にはメモリー最適化のためのニーズに合わせたUIを備えているため、前述した原理だけのアプリケーションではありません。
ベクターはおかげさまで25周年！今年が平成26年、つまり平成も25周年を過ぎたところ。ベクターは日本の年号が「平成」に変わったのと同時期に創業した会社なのであります。平成の始まりは1988年2月。その頃あなたは何をしていましたか？ まだ生まれていませんか？それとも友達が続々とファミコンを手に入れていく中、1人だけMSXを買ってもらってデータレコーダーで5分かけてロードした後、ただひたすらゴジラと戦う3DダンジョンRPGや、アスキーや徳間書店の雑誌に載っているプログラムリストを打ち込んで、F5を押しては"Syntax error"を出すという流れ作業の話をして「ふーん」と言われるだけの交友関係に何かコレジャナイ感を感じていた頃でしょうか？もしかしたらアイドルから一転してラ・ムーを結成した菊池桃子さんとHelloみかんに衝撃を受け、自称親衛隊を辞めようかどうしようか、辞めるとしたら世間的に許されるのかどうかと迷っていた頃……という方もいらっしゃるのではないでしょうか？ そのころベクターはもう走り出していたんですね！！！！！！！！！！！！！<3
199x年から始まったソフトウェア・ライブラリサイト「Vector」の累計ダウンロード数は、1999年に1億DLを達成した後、毎年1億（ときたま2億）ずつ堅調に増加して今年19億DL達成。
本業がオンラインゲーム事業になってしまったベクターだが（「創星紀アステルゲート」大好評サービス中）、ソフトウェアライブラリは依然として健在だ。7800万PVを支える620万UUに7800万のベクター体験を提供している。（わーお）
ベクター体験と言えば、最近では「XPフォーエバー」が人気だった。XPが意味するユーザー・エクスペリエンス(UX)が後発OS(というかiOS)に受け継がれた現在においても、WindowsXPは走り続けているらしい。そして走り続けなければならない。定年退職と同じだ。ゴールが年々遠のいていくんだ。プログラマー定年説だって昔は30歳だった。それがいつの間にか35歳定年説になっている。40歳になる日もそう遠くはないだろう。30歳が若くない？そんな言い分が通用するのはアイドルとスポーツ選手とプログラマーくらいのものではないのか。政治家なら40歳で若手。そもそも一日中イスに座りっぱなしで政治家ほども動かず、身のこなしと言えば手を動かすくらい、チェリーの黒軸キーより重いものは打つことがない仕事がなぜ「体力勝負」と言われるのか。「プログラマーやってたんで体力には自身があります！(*°∀°)=3」とか引越し業の面接で言えんの？1日じゅう立ち仕事で刃物を扱ってる床屋の主人を差し置いて体力自慢できんの？
私は空気読みができる人間だ。落ちのない小話がそう何度も通用するとは思わない。本題に戻ろう。
さて、増田一族の皆さんはベクターのご当地ゆるキャラをご存知だろうか。その名も「べく太」である。心優しき少年ではあるが学校での成績がずば抜けて悪く、テストでは全問不正解の上、自分の名前を「べく犬」と書いてマイナス点をもらう奇才ぶり。友達はそこそこいるが、成績の悪さや自身のずっこけエピソードにより、知らない人にも名前を知られている有名人気質。得意科目は射撃とあやとり。手に座布団を持ったスタンディングポジションから就寝までの速さを競う競技昼寝の速さにおいて世界クラスの実力を持つ。いつも((ﾐﾟoﾟﾐ))の影にいるため主人公とは思われない彼だが、劇場版長編「のび太の結婚前夜」ではアレをナニされても決してああはしないという彼の秘められた人間性が描かれている。
そんなのび太が最も輝いていたのがシステムメンテナンス系ツールの紹介記事であった。
他とは比べ物にならないほど豊富にあるハードウェアの性能を引き出すため、Windowsの世界ではさまざまなチューンナップ技術が磨かれてきた。メモリ最適化、レジストリクリーニング、ディスクキャッシュの最大化、RAMディスクの利活用、ビジュアルテーマ/アニメーションの無効化、IEの常駐、スタートアッププログラムの削減、サービス系プログラムの無効化、ＥＸＥの圧縮、RARの活用、標準ツールよりも高度なサードパーティ製ディスクデフラグ＆メモリデフラグ……、やることはいっぱいだ！でもこんなに手間をかけられるWindowsはかわいいなあ！そうやってPCチューンの腕を日々/.J で研鑚しあうマイルドハッカー達は磨き抜いたファイルコピーのスピードに一喜一憂したものである。
特にベクターには日本人により日本語で説明された扱いやすいメンテ系ツールが数多く登録されていた。使い方を誤れば手塩にかけて育ててきたWindowsに打撃を与えかねない分野であるため、「日本人にとっての分かりやすさ」は重要視される要素だ。そんな分かりやすいツールをさらに親しみやすく紹介する子供だましが紹介記事におけるべく太の役目である。
今ではべく太も良く読まれた記事のランキングでしかお目にかかれなくなってしまった。今や世間は萌え擬人化を通り越してゆるキャラブームである。いやブームさえ通り越して文化である。べく太はゆるいというよりマイルドなためかこのブームに乗っかろうという動きはまだ見せていない。これは残念なことである。（はてなもゆるキャラ路線をやめてしまうのだろうか）
ところどころかいつまんで述べたため、いくぶん主題がぶれた印象はあるが、
そんなベクターのユーザにリーチすることを考えないで、一足飛びに海外にロンする発想はちょっとチョンボしすぎなんじゃないの。その前にIEのセキュリティ問題で右往左往する人たちを相手にするのが先でしょ。そのあとは日本人口のメイン層である前期高齢者な。
情報社会を牽引する立場のソフトウェア開発者とは言っても、テストコード書いてこまめにリファクタリングしていくらでもデプロイしては動作確認できる人たちばかりじゃないの。一次請けから渡された画面設計書をメンバーに一人一枚ずつ手渡してアサイン完了、がんすけで開発スケジュールを引きつつ「これでどうだ？」とメンバー一人一人と納期交渉をするＳＥもいるの。ソースコードとほぼ同じ内容なので、スケジュールには含まれ得ない詳細設計書を「まぁ気持ちは分からんでもないが本来はそういうもの」という理由で実装前提出させたりするの。すべてが決まって検討課題がメンバーのメンタル面だけになった時点でキックオフ・ミーティングを始めるのが開発フローになっていたりするの。
これに対して事あるごとに穏やかな語り口で「私は雑用ですから」とつぶやくＳＥもいて、彼の場合は画面設計書をメンバーひとりひとりに渡して顔を伏せつつ実に申し訳なさそうな口調で「これぐらいでお願いできませんか」と納期交渉をしつつがんすけ２でスケジュールを引く人でした。
そんながんすけをダウンロードできるのもベクターソフトウェアライブラリなのである。がんすけ / がんすけ2 / （窓の杜にもあるよ） / （公式です）
話がそれたので本題に戻そう。
タイプは違うが、両者とも大差なくマッチョメンであった。ＳＥなのに。ここから少し余談を挟むが、その後面接をしたとある派遣会社の派遣プロマネもマッチョマンであったが、マッチョメンに出会ったのはそれくらいなので特に私の人生がマッチョメンで占められているという話でなはい。
私も筋トレすれば強くてたくましいＳＥになれるのかな、、、
いやスケジュールが押したからって突然開催されるようになった朝会に、シドニアの騎士のOPを歌いながら入ってくるようなＳＥは私の目指すところではないな。戦いの場への入場曲はもういいので設計をして下さい、設計を。適切な設計で工数を減らすのは、あなた方の役目でしょ。あなたの敵はここにはいません。何も打ち砕かなくていいのです。そんなことよりぴょんぴょんしましょう。ぴょんぴょんのほうがメンタル的に優しくていいです。ぴょんぴょんですよぴょんぴょん。
このままで、果たして定年までぴょんぴょん続けられるのかな……。定年……って何歳だっけ……。
元々は55歳か。それが20年で60歳になって……さらに20年経って65歳が当たり前になったのね。じゃあ、あと20年したら70歳が定年かぁ……今働き盛りの人たちは70歳から年金受給者だね☆ 平均寿命が延びたぶん定年がずれていくということは「人は働くために生まれる」というのがこの国の常識なんだろうね。（だって政治家は自分を選んでくれた選挙区の空気を読んで法律に反映させる役職でしょ？） そんでもって現在の定年が65歳、日本人の平均寿命は80代前半。最高齢が110代なので医療福祉諸々の発展で平均寿命と定年があと30年延びる可能性も？95歳で定年！？いやいやいや……そのころには日本人の人生観も変わってるだろうから……いやいやいや……変わってるかなあ。
だったらプログラマーは何歳定年説になっているんだろう。IE9をシェアNo.1に押し上げるような職場に勤めていれば何も心配ないのかな……また大きなパラダイムシフト──という言葉がもうずいぶん久しぶりだけど──が起きてプログラマー定年が上がるのかな……パラダイムシフトじゃ上がらないかな……ライブラリとツールのほうが大事かな……（大体、オブジェクト指向だって末端のアプリケーションエンジニアにとっては「例にならえばいいだけのもの」だったし）……何かを速く便利に自動化するツールよりも、テストコードを書けばそれに合うライブラリを探してきてくれるエージェント指向システムが実現されないかな。今のところ再利用可能なコードを探す手段はドキュメントを検索するのと、ソーシャルふにゃふにゃで誰かに教わることくらいしか無いし。そんなパラダイムシフトが早いとこ起きないかなー起きればいいなー「お前が起こすんだよ」とか言う奴ぜったいいるだろうけどおれはおこせないしなー。
結局、定年って定まってないんだよね。不定年だよ。定年は不定年。同じ境遇の人間が多数いればその都度社会が対策とってくれるだろうし、先のことを気にしても仕方が無いよね。──ってことでハラオチ。
そんな私のベクター体験を元に、ベクターユーザからも訴求されそうなはてなブックマークUIを考案するのが本稿の主題である。
(Dan the full stuck engineer.)
Shared by iNotes - Sync Note with iOS
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
国内クラウド最大手のIIJ GIOが驚くほどクソっていう話を書きます。
クラウドならIIJ GIO（ジオ）- IIJの高品質クラウドサービス にあるように、クラウド上にいろんなサービスを乗せてくれるヤツです。
まぁAWSでいいじゃんって話が出ると思うので、AWSとの違いをまとめてくれた方がいましたので紹介します。IIJ GIO にあって AWS にない（なさそうに見える）10のサービス - yoshidashingoの日記 なお、このエントリー以降にAWSも進化していて、中国リージョンの開設やVDIサービスの提供がアナウンスされています。
一つには国内ベンダーっていう安心感ですかね。どこに登記されてるとも知れないAWSに任せると、いきなり「今度このへんのラックメンテするからEC2のインスタンス落ちるよ」みたいのがあったりしますしね。
あとは、運用監視サービスをやってます。AWSだとCloudWatchみたいな簡易なやつしかないですが、GIOだとアプリのログとかポート監視もやってくれます。まぁAWSでもサードパーティで運用をやってくれる会社はありますが。
残念ながら、上記の「選ぶ理由」はどれも裏切られます。
不定期メンテは普通にありますし、ろくに通知もないです（電話1本とか）。内容も、ネットが切れるとかサーバを落としてくれとか割りとデカめです。国内ベンダーだからちゃんとしてるだろうというファジーな期待は裏切られます。
運用監視サービス、これがまたゴミです。監視のカスタマイズなんかお願いしようものなら「これが仕様なんで…」と突っぱねられます。ポーリング間隔ですらカスタマイズできません。あと運用。「このアラートは即電話ね」と決めていても、24/365対応している現場の人間は適当なバイトなので、ろくに伝わっていなくて見逃される、みたいのもザラです。
そりゃはてなのサービスも好きだけど、TwitterとFacebookは特に好きで周りの人がたくさんインターネットにいて、いろんな情報が入ってきて楽しい。
なかでも「ふぁぼ」とか「いいね」とかは結構敏感になっていて、もらえるとやっぱり嬉しいし、好きな子の好きだなーと思ったポストにはひたすらにリアクションする。はてなスターみたいに好きだと思ったら連打できればいいのにね。
ちょっとプログラミングをかじっていて、TwitterとFacebookのAPIなら簡単に叩ける。何が始まるかって言うと、サードパーティのクライアントがよく出来ている・Webのインターフェースが良さげって言っても知りたい情報を得る為にずっと画面に張り付くなんていくら時間があっても無駄だ「自動化だ！Push通知だ！」という結論。
TwitterはStreamingAPIとかが整備されててめっちゃリアルタイムにいろんなことがわかる。Facebookはクロールさせなきゃいけない、面倒だ、何もしてない。
まず手始めに好きな子がツイートしたら、それをPushでスマートフォンに通知するようなアプリを書いた。iPhone使ってるからBoxcarとかを駆使すればすぐできる。
次に隠れているAPIを使って、好きな子が「ふぁぼ」を送ったら、それをPush通知するアプリを書いた。
とりあえず、そんなところ。他にも、いろいろ通知させてるアプリあるけれど、エゴサとかプロフィールの更新とか、どうでもいい。
今のところ、その好きな子は鍵垢でも何でも無いし、ツイートとかふぁぼとか、その子に関する全てをDBに叩き込んでる。アイコンの変更とかBioの更新、フォローのステータスとか、その子の全部。ポストが日に50前後だからそんなにTwitterやってるわけではないけれど、Facebookもそんなにしてるわけではないし、インターネットで知りうる情報って自分からその子にしてみればTwitterくらいなものだから。
で、今晩、クリスマスイヴ、ちょっとその子の関係を顧みて自分のやってることを考えた。
「アレ、俺のやってることってストーカーじゃね？」
もうすぐモンハン4発売
http://www1.capcom.co.jp/monsterhunter/4/
ということで、弓使いの自分としてはいわゆる「モンハン持ち」をしてやりこみたい。
