  |
はてなキーワード: コンポーネントとは
React.js界隈の人に聞きたい
http://anond.hatelabo.jp/20160521163144
最近某所で、React使うとjQueryは不要だ的なタイトルの記事を書いちゃた気がするので一応反応しときます。長文ごめんね。
えーととりあえず、あのタイトルは実際のところ省略しすぎであり、もちろん本来は「場合によってはjQueryは不要」「jQueryは要らないこともある」と長く書いた方が正確です（本文ではちゃんとReactが万能ではない説明をしてる）。でも多少釣りっぽいタイトルの方が読まれるようなので反省はしていない。
そもそも世の中にそんなにSPAがあるのか
世の中の絶対数は知りませんが、自分の脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、＜input type="hidden"＞とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。
というか、ちゃんと書かれたSPAは使っていてSPAであることにそもそも気づかないので、「SPAだから使いづらい」という主張はよく分かりません。GitHubやTwitterサイトがSPA的なことをしている故に使いづらいでしょうか。偶然タブを開いてたので調べたらそうだったから紹介しますが、例えばWebpackのドキュメントサイトは（Reactではないけど）SPAで、ブラウザでMarkdownをレンダリングしています（ http://webpack.github.io/docs/ )。サーバサイドで動くスクリプトもタスクもゼロ。個人的にはこういう使い方で十分嬉しいです。
何にせよReactのメリットが真に活きるのはある程度の規模以上だと思うので、小規模で導入してjQueryより短くならないことは普通にあります。自分中の閾値としてはJSコードが数百行超えるならもうReact使う。
JSXを使うことに抵抗ないんですか？
んー、要するに「別物であるDartやCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか？ 正直その主張を聞いたのは初めてです。歴史的にJSXとES6は完全に独立して発明されました。最近になってBabelが両方同時に扱えるようになりましたし、Babelはまさにそういう拡張性を重視しているツールです。それは「ああ便利になったね」というだけの話であり、なぜ「ES6とJSXは混ぜるな危険」となるのかよく分かりません。現にこれが最も標準的で人気の組み合わせです。
「JSXを使うことへの抵抗」ということなら、とにかく見た目にコレがキモいと感じる人が非常に多いのは事実です。現に、JSXより見た目がキモくないことを売りにしている仮想DOM実装が一定の人気を博していたりします。でもそういうライブラリは「キモさ」軽減のために結局新たな構文やら独自コンパイラやらを編み出して柔軟性を犠牲にしています。JSXは「関数呼び出しのシンタックスシュガーをJavaScriptに1個導入するだけで問題を概ね解決する」というシンプルかつ一番表現力の高い解決方法だと思います。仮想DOMの思想に逆らわない最も素直なやり方であり、将来長持ちする気がしています。
とはいえ所詮JSXはシンタックスシュガーなので、使いたくないなら使わず、本来の関数スタイルで仮想DOMを書いてReactを使ってもいいです。タイプ量が増えて若干見づらくなるだけなんで。
それと、JSXじゃなくてテンプレートでいいじゃん的に思っているようですが、テンプレートは仮想DOMでもなければJavaScriptでもないので、速度や機能の面でReactがやっていることに遠く及ばないと思います。
Reactはもう登場して3年経過して未だに勢いが増していますし、日常で困らないレベルのコンポーネント集も揃っています。React-Bootstrapはいいぞ、心が豊かになる。そろそろ採用してもアーリーアダプターとも言えんでしょう。むしろ真に先端を見るのが好きな人に言わせりゃ、2015年なんて「Reactが淡々と成熟していくのを見ているだけの、つまらない年だった」みたいな感じらしいですし。
Reactは現時点で既に3年に1回レベルのビッグウェーブであることは疑いようがなく、「これが10年に1回、つまりjQuery以来のビッグウェーブなのかどうか」については、そう信じている人と懐疑的な人がいる、という状況です。私はAngularもCoffeeScriptも「3年に1回」レベルに感じたのでスルーしましたが、Reactには「10年に1回」の方になりうる素質を感じています（個人の感想です）。将来もっと凄いものが出るとしたって、それは「ベターjQuery」ではなくて「ベターReact」でしょう。通常は「3年に1回」レベルでも試したり仕事に使ったりして構わないと思いますが、10年に1回の技術でなければ使わない主義の方は、あと2～3年待てばよいと思います。
保守性に関して言うと、Reactは典型的な「ひとつの事だけをとても上手くやる」系のライブラリです。考え方のコツさえ掴めば、記憶すべき要素はjQueryやAngularと比べても圧倒的に少なく、むしろそこらのテンプレートエンジンを覚える方が面倒なくらいです。10年後に見ても何をやっていたのか30分で思い出したいというのであれば、むしろAngularとかよりReactを採用すべきだと思います。
http://anond.hatelabo.jp/20160521163144
内容から誰が書いてるかわかるかもしれんけど、まぁスルーよろしく。
jQueryもそんなにガッツリ使ってるわけでもないし、Reactはまだリリース前の調査兼下地作りの段階だけど
正直言ってjQueryに戻るつもりは毛頭ないぐらいReact便利だと思ってる。
でもjQueryを捨て去れるかというとそれも無理だと思ってる。
その辺のことを適当に書いてみる。
社内サポート的なことやってて、サポートのテンプレート対応を省力化するために
Webでツール作って人が対応するコストを減らすために使ってる。
jQueryで一つツール作ってリリースしてそこそこ人的コスト削れたのはよかったと思ってる。
最大にして一番の理由がこれ。
そんなに大規模なアプリケーション作ってるわけでもないし、関係者も俺一人だけど正直DOMツリーを脳内でくみ上げるのに疲れた。
500行もいかないようなショボいコードでも脳内DOMツリーと格闘するのしんどい。
DOMツリー触るほうが楽ってみんなどの程度のコードでそんなこと言ってんの？
そんなスーパーハカー揃いなの？信じられないんだけど。
オリジナルのbootstrapはどうしても頭に入ってこなかったし、手を付ける気にもならなかったけど
React-Bootstrapはマジで楽だし、スッと理解できる。マジ最高。
Bootstrapってこっちを本筋にすべきじゃね？と割とマジで思ってる。
まだ触って3日も経ってないけど。
これはちゃんとしたWeb界隈の人は利点と思わないのかもしれないけど
一人でいろいろ賄わざるを得ない俺みたいな人間にとってはマジで楽。
ベースのHTMLにはベースのdiv一個載せとくだけで後は全部js。
レイアウトを大元のコンポーネントでReact-Bootstrapで組んで、あとは各コンポーネントを
個別に作っていけばいい。
HTML見て、CSS見て、JS見て、っていちいち記述方式の違うコードを見る必要がないのは
少なくとも俺にとっては一番楽。
やっぱまだReactはコンポーネントがそんなに揃ってないんだよね。
だからjQueryも使わざるを得ないけど、それも一つのコンポーネントに閉じ込められるから
管理が楽。
極力なくす方向で行くつもりだけど、今はまだ両方使ってる。
あの気持ち悪いコード考えた人はマジでいい意味でも悪い意味でも頭イカレてると思う。
気持ち悪くて仕方ない。いまだに大嫌い。
どんなに気持ち悪くても、結果が伴う以上使う。
5年後も自分がこの仕事やってるかどうかもわからんからそんなこと気にしたことない。
今ある仕事をなるべく早く簡潔に実行するために最適だと思ってるツールを使ってるだけ。
それがかつてはjQueryだったし、今も一部jQueryだし、大半がReactになろうとしてるだけ。
将来まだこの仕事やってて、もっと有用なツールがあればそっち使う。
俺みたいな一人前にすら届いてない奴の意見なんぞ必要ないだろうけど、
自分の今の考えを書いておくと後で見返せるかなと思って適当に書いてみた。
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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
あこがれの英字キーボードを手に入れたから早速会社のパソコンに接続してみた。会社のパソコンは Windows 7。解像度もメモリも CPU も悲劇的な支給パソコンをなんとか使えるレベルで動かしてくれる頼もしいやつ。
「カシュカシュカシュ」
う〜ん、シングルクォーテーションとダブルクォーテーションがうちやすい！ あとアットマークをシフトを押しながら入力するのは新鮮かな。
「コトコトコト」
スペースキーが広い！ 打ちやすい！ ついつい連打しちゃう。キー配列になれるのは時間がかかりそうだけどハッカーみたいでかっこいい。だけどちょっと、ううん、かなりストレスフルなことが一点あって、日本語を入力しようとしたらキー配列がJIS配列になっちゃうんだ。いちおう英字配列にはキーコンビネーションで切り替えられるんだけど、キートップの印字とちがうじゃない。ほら '*' が '(' だったりさ。
今思えば英語入力にわりきって使えば良かったって思うよ。でも往々にしてわりきるのって無理でしょ。
こまったときのグーグル頼み。グーグルさんに日本語キーボードのパソコンで外付け英字キーボードを上手く使う方法はないのって聞いてみた。そうしたらいろいろおすすめしてくれたから、まあ、このくらいの苦労はしないと英字キーボードを買った意味はないよねって、というかこっちから苦労を買ってやろうって、ふふんと思いながらいろんなページを確認したの。業務中だったけど。
それで、レジストリを書き換えてやればいいって書いてあるページを見つけた(http://blog.heiichi.com/?eid=792239)。書き換えるのは
パス : HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/i8042prt/Parameters キー : LayerDriver JPN, OverrideKeyboardIdentifier, OverrideKeyboardSubtype
か。でもレジストリエディタってなんか使いづらいし、怖いなあ。おっとそういえば業務のデファクトスタンダードアプリ Excel で、拡張コンテキストメニューから「読み込み専用で開く」ためにレジストリを書き換える PowerShell スクリプトを作ったんだっけ。マイクロソフトオフィスがアップデートするたびにレジストリ書き換えられるもんだから、あたまにきて作ったんだっけ……。
New-ItemProperty -Force -Path 'Registry::HKEY_CLASSES_ROOT/Excel.Sheet.12/shell/OpenAsReadOnly' -Name ddeexec -PropertyType String -Value "[open("%1",,1,,,,,,,,,,,,1,,1)]"
よっし、エンジニアならコンポーネントの再利用だな、ってスクリプトをコピーしてぺたぺた(スクリプトは超危険なので割愛！)。パスをかえて、値はこれで、そうそう現在の設定を確認して英字配列と日本語配列を自動で切り替えるようにしたいな、むふふ、なんてつなげたばかりの英字キーボードですくりぷとすくりぷと書いていたの。
そんで実行。エラーか。ふむふむああええおお、パスまちがえちゃった。
こんどこそ実行。エラーなく終わって、ちゃんとキーの名前と値が入っている。さてさてそれでは再起動しましょう。
「ブイーン」
これ面倒なんだよなー。ハードディスクの暗号化解除っと。あれ、起動画面に移らないなあ。メモリチェックが走っているのか。ふーん。
……おわらないんだけど………………………………………………。おそるおそる画面をみたら、
「Windowsが起動できませんでした。システム管理者に連絡してください。」
うっわーーー。ブルースクリーンだーーー。はじめて見たーーー。本当にブルースクリーンででるんだなあ。
正直このときはラピュタをみつけたパズーの気分だったかも。ぼくの場合はこの先にはわくわくなんてなかったけどさ。だんだん、やべー、これやべー、これやべーや、これすごくやばいよね、って正気にもどった。そんで隣のお仲間にバレる前に強制終了。ふう。多分再起動中だっておもってくれたよね。
だいじょうぶだ Windows は軍用にも使われる堅牢性の高い OS だ。これくらいのエラーは普通再起動したらいつもと同じように退屈な起動プロンプトがでるはず。そうやって自分をまず信じる。それが一番大事。
まずは軽い深呼吸。そして電源オン。
「ブイーン」
ハードディスクの暗号化解除は BIOS レベルだから変わらないのか。Windows は予期されない終了をしたって？ そのとおり！ 気にせずに君はいつものように平常心で起動してくれたまえ。
あかんわ。これ完全にあかんわ。二回起動して二回だめって、これなんかいやってもダメなパターンはいったよね。エンジニアのはしっくれだけどそれくらいはわかる。
とりあえず電源を落として、気持ちを落ち着かせるために散歩しよう。ああ、今日は雲がきれいだなあ。風もふいていてはるだなあ。どうしよ。ぼくも答えはわかっていたんだけどね。管理部にごめなさいしてリカバリ DVD をかりてくればいいんだよね。でもさ、ただの箱になったパソコンはお客様のものっていう派遣の立場だしさ、絶対に原因追求でレジストリいじったことを告白させられるしさ、ああなんか春と秋ってにてるよね。
あとさブルースクリーンになった原因もわかったの。ふいにあああれだなって思い浮かんだんだけどさ、スクリプトつかいまわしちゃったせいで OverrideKeyboardSubtype キーの型を DWORD じゃなくて String にしてたのよ。ぜったいにこれで起動シーケンスで致命的エラーはいてんだろうなって。
そんな風に思いながら、自席に戻って、もう一回電源起動。もう一回よく画面を確認する。……むむ自動修復だと。よかろう最後の望みだ。かなえてやろうじゃないか。へー最後に記録した正常状態にシステムを復元するのか。なんか説明書きに「最近インストールしたプログラムとか消えるかもね。ハハッ。」て書いてあるけど、しばらくインストールなんてしていないし、初期状態に戻んなかったらまあいいよって感じ。ポチッとな。
そんでもって三十分から一時間経ったかなあ。あまりにも時間がかかるからトイレの個室で頭をかかえてたの。自席に戻るとパソコンの電源が落ちているわけ。さてとこれはラストチャンスだ。なんのチャンスかわかんないけどラストであることはあきらかだよね。そして電源をいれた。
この時ばかりは神様に祈ったね。だって計算機はプログラムしたようにしか動かないから、お祈りなんてしても意味ないもんね。だから神様にお祈りしたの、どうかおねがいします、今後はこれにこりてレジストリなんてぜったいにいじりませんので、この計算機が正しく動くことを祈ってくださいって。
結局、無事復旧できた。なにひとつ異常なく Windows 7 は立ち上がって来て、みなれた壁紙がでてきた。おそるおそるレジストリを確認したら、ちゃんとぼくがいじくるまえにもどっていた。ありがとう Windows！ ありがとう自動修復機能！ いちおうありがとう神様！
それでも外付け英字キーボードで日本語入力したいんだーて人はここらへんを見たら幸せになれるよ。
ＵＳＢ英語キーボード付けた。（英語、日本語キーボードの共存、KeyboardTypeOverride） 202122 (http://202122.iku4.com/%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3/%EF%BD%95%EF%BD%93%EF%BD%82%E8%8B%B1%E8%AA%9E%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89%E4%BB%98%E3%81%91%E3%81%9F%E3%80%82%EF%BC%88%E8%8B%B1%E8%AA%9E%E3%80%81%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89)
USBポートに対しての設定だからブートで失敗することはないと思うよ(ブルースクリーンを発生させたもののことば)。
いちおうこれを書くにあたって、自宅のパソコン Windows Vista で再現できないかためしてみた。検証内容は以下の二つ。
結論としては両方とも大成功！ ちゃんとレジストリエディタから編集したら、英字キーボードで日本語入力が快適にできるようになったし、 DWORD を String に変更したらブルースクリーンがでるようになったし！ Vista だと会社の Windows 7 ではできた自動修復ができないし！ なんかブートセクションとデータセクションが分けられるようになったのって Windows 7 かららしいし！
だけどここは会社じゃなくて自宅だから、メイン OS の Ubuntu で Windows 領域をマウントして華麗に chntpw を叩いてレジストリを修復できる。そう Linux ならね。
正しいHTML
block__element__elementは使用しない
GoogleChromeなら変換時に右側に△マーク〜
このテキストは予算20～30万ぐらい出せる人を対象としてます。
シマノコンポーネントの完成車をターゲットにしています。理由は私がカンパ/sram使ったことないから。
最近はカーボンフレームにフル105で20万以下も多いので、この辺から考え始めると良いでしょう。このテキストはこのあたりを検討している人に向けられたものです。ボリュームゾーンなのでお得なモデルが多いし、後々ステップアップする場合でも不満が出にくいです。
注意が必要なのは、一部105ではないパーツが付いている完成車。
よくあるのが、ブレーキが某メーカーの低グレード品や、クランク/チェンリングが某メーカーの低グレード品など。これらの完成車はあまりおススメしません。特にブレーキは重要で、105以上のグレードを強く推奨します。安いブレーキは雨にぬれると全力でブレーキレバーを握っても止まりません。あなたが握力の少ない女性なら死にます。基本的にロードバイクは雨の日に乗るものではありませんが、突然の雨に襲われる可能性は否定できません。
あなたが若くて体力が有り余っているスポーツ経験者であればフレーム素材はなんでも良いでしょう。そうでなければ柔らか目のカーボンフレームをターゲットにしましょう。細かな振動に長時間突き上げられていると想像以上に消耗します。高額なレース向けカーボンフレームはアルミ並に固いモノもあります。傾向として安いカーボンフレームは柔らかい味付けになっていることが多いです。
スチールは非常に魅力的なフレーム素材ですが、うるさ型のフリークが多いのでここでは触れません。
ある程度自分で調べたうえで、ちゃんとしたショップで相談しましょう。20万円はロードバイクとしては安物の部類ですが、多くの人にとって安い金ではないはずです。1件のショップの見立てだけでは不安なら2件以上回りましょう。
2サイズ選択可能なら小さいほうを選ぶことをおすすめします。サイズの調整はサドル位置、シートポスト交換、ステム交換、ハンドル交換で行うことになります。大きいフレームを小さくしようとすると弊害が多いです。ポジショニングの自由度が下がり、理想とされるペダリングが可能なポジションを取りにくくなります。
また、クランク長がオーバーサイズだとペダリングがスムーズに行えないうえに膝を痛める可能性もあります。チェンリングはコンパクトがおすすめです。初心者向け完成車はほとんどコンパクトだと思いますが。クランク長とチェンリングについては十分に調べてから購入されることを推奨します。
あなたが1年を通して走ろうと考えるなら、ウェア類に10万ぐらいかかります。
なので、始めるのは春～夏が良いでしょう。必要なウェアが少ないからです。
レーパン/ジャージ/ヘルメット/シューズ/グローブ/サングラス
これでまあ5万円だとちょっと足りないかなという感じでしょうか。レーパンは安物を選ぶと後悔します。メジャーなメーカーからちゃんと試着して選びましょう。めんどくさがって試着せずに購入すると後悔します。
冬用のウェア類はけちると死にます。
わかります。変わり者店主の個人ショップは多いです。大きなショップは知識/経験が少ないバイトが多く不安になります。大きいところ小さいところ、いくつか回ってみるしかありません。気長に波長があうショップを探すことです。信頼できる顔見知りショップが近くにあると、メンテナンスに関する不安が格段に減ります。
自分で調整やパーツ交換をやるのは悪いことではないのですが、信頼できるプロに調整してもらうと乗り味が変わります。また、初心者(に限りませんが)は誤ったメンテナンスを行う可能性を否定できません。
とはいえ、あまり神経質になる必要もありません。死なない程度にメンテナンスされていれば良しとするのであれば、行きつけのショップなどなくても困りません。ロードバイクを扱っている全国チェーン系ならロードバイクの調整はしてくれます。
最低これらは必要です。夜走るならライトも。後は金です。前後輪外せば普通のタクシーで家に帰ってこれます。まずは"トラブった時に家に帰ってこれるか？"という視点で携帯品を選択しましょう。
完成車購入後、サドルやステム、ハンドルは交換する可能性が高いです。スタイルが固まらないうちに気に入らないからと言って次々変えるのもどうかと思いますが、いろいろ試してみることも重要です。また、完成車はペダルが付いていないので、ペダルは買うことになります。105完成車ならペダルも105で良いでしょう。
ケツ痛に悩んでサドルを次々に購入する人がいますが、まずは自分のスタイル/ポジションを疑いましょう。レーパンの中にパッド付パンツをはくという手もあります(パッドが厚くなれば痛みがなくなるとは限りませんが)。サドルは柔らかい/固いよりも幅の広さと盛り上がり方が重要になります。
チェーンは頻繁にクリーニングすることになります。チェーンカッターは必要です。またはチェーンにコネックスリンクをはさみます。車体につけたままのクリーニングは大して綺麗になりません。外してディグリーザーで洗います。チェーンルブはいろいろありますが、高いものではないので試してみて好みのものを見つけましょう。ワイヤー類は伸びるのでブレーキやディレイラーは調整が必要になります。この辺は自分でできるようにならないと何かと面倒です。最初はショップで教えてもらうと良いでしょう。
そのうち、プーリーのグリスアップなんかも必要になりますが、それはだいぶ先なのでその時。
バイクは綺麗に保ちましょう。ロードバイクのかっこよさは、値段の高い安いではなく、クリーニングされているか否かで決まります。
自転車ではありません。あなたです。あなたが30歳以上のデスクワーカーであれば、膝の故障には十分気を付けてください。
具体的には、クランク長が適切か？サドルは高すぎ/低すぎないか？サドルは前/後すぎないか？ハンドルは遠/近すぎないか？
そして、走り出してしばらく(5-10分ぐらい)は重たいギアを踏まないように！
春に走り出すことを考えると、春に検討したら遅いです。そろそろ考え始めましょう。そして取り扱いメーカーの多いショップにちょくちょく見に行きましょう。全メーカーが一斉に出そろうわけではなく、バラバラに店頭に並びます。そしてあっという間に売れて、やたら大きいかやたら小さいフレームが残ります。なんとなく気に入って、サイズ的に無理が無ければその場で決断することも重要です。そのバイクが自分に合うか否かなんて初心者にはわかりません。2台目以降で考えましょう。
http://www.atmarkit.co.jp/fdotnet/dotnettips/1064combycs/combycs.html
足りないぞ。
[System.Runtime.InteropServices.ClassInterface(System.Runtime.InteropServices.ClassInterfaceType.AutoDual)]
をつけないと、メソッドが公開されない。
大御所でも、未検証のコードを載せるんだな。。それとも俺がちゃんと従っていないのか？
もしくはバージョンや環境設定によるのか？こちとら、Visual Studio 2013 で C# 使っているんだけどね。
レビューって「指導」じゃないだろ。本人が見落としてるところを他人の目でチェックするとか、本人があまり詳しくないコンポーネントと相互作用する可能性があるからそのコンポーネントの方が分かってる人にチェックしてもらうとか、そういうのじゃないの? そういう目的がはっきりしてるなら手段は何だっていいんじゃね? レビューを普通にやってた職場ではgitのコミットにweb上でコメントつけられるようになってたけど、便宜上紙と赤ペンでやっても本質は変わらんでしょ (仕事でやるなら効率悪いけど、その時だけの代替手段というなら)。
コードを読む力の判定にはある程度使えると思うな。実務では他人のコード読んで手を入れないとならないことは多いわけだし。それに面接で使うなら、それは「レビューの正解」を求めてるんじゃなくて、コラボレートしてコードを書いてゆくことにどう臨むかってのを見るわけだから、悪くない方法だと俺は思った。
もうPC向けWebブラウザは、進化する余地がないのか、停滞しているように思えてしょうがない。
IEはともかく、FirefoxはデザインをChromeにしちゃったし(あれのどこがいいのやら)、Chromeに至っては、停滞どころか悪化しているとさえ感じる。
IE8になってようやくWeb標準に従うようになって、IE9でJavaScriptが劇的に速くなり、IE11でかなりWeb標準の準拠度が改善された。
また、Windows XPのサポート終了により、IE6というWebデザイナーの多数を地獄送りにしたブラウザから完全に脱走できるようになった。
しかも、サポートポリシーが変わって、2016年1月以降は各OSで最新のバージョンしかサポートしないと決まったため、思ったよりも早くWebデザイナーの苦痛が取れるようだ。IE6で懲りたんだろうか。
しかし、IEコンポーネントブラウザの互換性を軽視する傾向にある。
IE10では、Windows7の必須アップデートのせいで画面描画が乱れる場合があったり、特定のWebサイトでIEコンポーネントブラウザをフリーズさせるという必殺技を披露した。
IE11では、一部環境でDOMストレージが原因でブラウザコンポーネントを十数個開くとフリーズする新必殺技を披露した。(現在、バグ修正済)
次のIEでは、どんな技を披露してくれるのだろうか。
Chromeをパクってと同様、高速リリースサイクルになって3年目。
アドオンの互換性に悩み、自ら失敗といいつつも、高速リリースサイクルを何とかやっていけてるようだ。
シングルプロセス/マルチスレッドながら省メモリとJavaScriptの速度チューニングを着実に行っている。
つい先日、australisというChromeのパクリに非常によく似たUIを強制適用し、一部ユーザーから顰蹙を買う。
高速リリースサイクル、強制アップデートを流行らせた元凶。
Chromeは初期設計のポリシーがよく、HTML5の準拠度とブラウジングスピードは今でもよい。
登場からあっという間にシェアを獲得し、主要ブラウザと呼べるほど有名に。
しかし、バージョンが上がるたびに肥大化し、メモリ消費量がますます増え続け、低スペックマシンでは重くなる一方である。
レンダリングエンジンがWebKitから独立してBlinkになったが、さらに迷走していく。
ユーザーが阿鼻叫喚した、ウィンドウシステム共通化プロジェクト。
理想は、各種コントロール(スクロールバーやボタン、エディットボックスといったもの)を全プラットフォームで共通化した上で、GPUによる描画で高速化する・・・ということだった。
Windows版ではバージョン32から適用された。しかし、安定版になってもスクロールバーの矢印が消えた、汎用マウスジェスチャが使えない、
縦/横スクロールがまともに動かない、Webフォントが描画されないなどなど、多数のバグが残存していた。
今でも、バージョンが上がるにつれて改善されたものもあれば、一度改善していたのに不具合が再発するなど、安定版といいつつ安定しない日々が続いている。
いったい、「安定版」とは何なのだろうか。
最近、ChromeはGoogleのものであることをユーザーにしらしめる努力ばかりやっているのではないか。
Google Nowなど、自社のサービスを便利に使うために機能追加するのは別にかまわないが、新しいタブページの異常にでかいGoogleロゴはどうだろう。
よく開くページのサムネイルを小さくし、下に追いやってまでGoogleロゴを目立たせる必要はあったのだろうか。
今年中にNPAPI廃止を目論んでいるが、それは現実的なのだろうか。
Chrome独自に持っているPPAPIは、セキュリティが厳格なゆえにNPAPIの代替手段には決してなりえない。少なくとも、PPAPI上で動くFlashがNPAPIのそれと同等の速度で動かない限り、廃止はありえないと思う。
Firefoxが高速リリースサイクルを採用した初期の時のように、高速リリースサイクルを優先するあまり、品質を犠牲にしているケースが目立っている。
最近出た37では、DirectWrite周りの実装がお粗末で、安定版が最初に出たころはズームイン/ズームアウトするだけで文字が表示されなかった(翌日に修正)。今でも、ビットマップフォントの表示品質がGDIよりも悪い。
高速リリースサイクルの弊害が現れているのではないだろうか。このことに、Chromiumの中の人たちは、気づいているのだろうか。
なんか最近「オブジェクト指向」関係の記事や書籍紹介を目にするような気がするのは、新学期が始まったせいなのかな。
オブジェクト指向がよくわかんない、という人は、いったんオブジェクト指向を忘れて、「システム」とはなんぞやという基本の基本を確認することをおすすめする。
Wikipediaのシステムの項（https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0）の図（https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:System_boundary.svg）を見てほしい。
外部環境（Surroundings)において境界（Boundary)が定義されるその内部がシステム（System)なのである。
境界こそがシステムを具現化するものであり、要するにシステムの内部はおいといて、境界を通じてシステムの内部と外部でどのような入出力（インターフェース）があるかのを定義するのがシステム定義なのである。
これが決まってはじめて内部をどのように構築するのか、サブシステム（コンポーネント）間の連携をどうするのか、という話になる。
英語版のページにはしっかりとこう記載されている。
We scope a system by defining its boundary; this means choosing which entities are inside the system and which are outside – part of the environment.
日本語版の項にはなぜか訳されてないが、これが本質的な定義であり、システムときいたら即「境界」と思い浮かべるべきである。
そんなの当たり前じゃんと思われるかもしれないが、たぶんシステム関係に携わっている多くの人が、「システムって何？」ときかれたら、
「システムはいくつかの要素によって構成されるもので、その全ての要素は、他の要素に影響を与え・・」
と、いきなりシステム内部の機能的な説明を始めると思う。まず境界やインターフェースの話から始める人はむしろ少数だろう。
そうでなければ、世の中に数多あるシステムの「要件定義」「システム設計」「機能仕様書」などトップレベルでの記述はもっと明確かつトップダウンになってなければおかしい・・・
話をオブジェクト指向に戻すと、
最近話題になっている記事などは、なるほどよく噛み砕いているなあ、とは思うんだけれども、言語・実装・モデルといったものにひきずられてしまって、本来は広い分野や局面における「システム構築の手段」の広い概念であるはずのオブジェクト指向、実装例や用語から再度説明するという堂々巡りをしているという感じがする。
システムの本来の意味が身についたら、オブジェクト指向で説明されているあれやこれやが、このシステムを実現するため手段にすぎず、効率的にシステムを構築し、サブシステムの再利用を容易にするための仕組みや方法論をあるていどまとめて総称したものであることが自然に理解できると思う。
なんか最近「オブジェクト指向」関係の記事や書籍紹介を目にするような気がするのは、新学期が始まったせいなのかな。
オブジェクト指向がよくわかんない、という人は、いったんオブジェクト指向を忘れて、「システム」とはなんぞやという基本の基本を確認することをおすすめする。
Wikipediaのシステムの項（https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0）の図（https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:System_boundary.svg）を見てほしい。
外部環境（Surroundings)において境界（Boundary)が定義されるその内部がシステム（System)なのである。
境界こそがシステムを具現化するものであり、要するにシステムの内部はおいといて、境界を通じてシステムの内部と外部でどのような入出力（インターフェース）があるかのを定義するのがシステム定義なのである。
これが決まってはじめて内部をどのように構築するのか、サブシステム（コンポーネント）間の連携をどうするのか、という話になる。
英語版のページにはしっかりとこう記載されている。
We scope a system by defining its boundary; this means choosing which entities are inside the system and which are outside – part of the environment.
日本語版の項にはなぜか訳されてないが、これが本質的な定義であり、システムときいたら即「境界」と思い浮かべるの
そんなの当たり前じゃんと思われるかもしれないが、たぶんシステム関係に携わっている多くの人が、「システムって何？」ときかれたら、
「システムはいくつかの要素によって構成されるもので、その全ての要素は、他の要素に影響を与え・・」
と、いきなりシステム内部の機能的な説明を始めると思う。まず境界やインターフェースの話から始める人はむしろ少数だろう。
世の中に数多ある、システムの「要件定義」「システム設計」「機能仕様書」などで、トップレベルでの記述でまず境界と外部とのインターフェース明確にして、
Wikipediaのシステムの項（https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0）にもそう書いている。
それそれで正しいんだけど、それ以前に重要なのは「境界」であり、
話題になっている記事は、なるほどよく噛み砕いているなあ、とは思うんだけれども、言語・実装・モデルといったものにひきずられてしまって、本来は広い分野や局面における「システム構築の手段」の広い概念であるはずのオブジェクト指向、実装例や用語から説明するという堂々巡りをしているという感じがする。
乱暴に言いきってしまうと、「システム」の本来の意味を理解すればオブジェクト指向にまつわるあれやこれやは自然にわかってくるはずだ。
私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールなシリコンバレーの会社でも働いたことがある。私は１２種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造化プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。
（ 注：ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供していないという意味だ。ほとんどのソフトウェア開発手法はプログラミングに工学風のプロセスを提供してくれる。しかし、上記の理由でそれだけでは不十分だ ）
チーム生産性・幸福度・メンバーのつながり・１日あたりのコード量・人月・コードの品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手くいってるか、いってないかを図るものはあるのだろうか？
もちろんどんな手法論だって、それに合わせた正しい指標を使えば上手くいってるか・いってないかが計測できる。しかし一番肝心の問題 ーー予算と期限内で要求を満たす事ーー について定常的に結果を図れる開発手法を見たことがない。
上記は私の経験則だけど、僕の知ってる殆どのプログラマは同じような事を経験している。それらの話から言えるのは「ソフトウェア開発手法について厳密な研究は存在しない。なぜならソフトウェア開発上のすべての要素をコントロール事が出来ないからだ」
こんな思考実験をしてみよう、
２つのプログラマのチームがある。どちらも要求・期間・予算はしっかり確定していて、同じ開発環境・プログラミング言語・開発ツールを使うとする。一つのチームはウォーターフォール/BDUFをつかう。もう一つのチームはアジャイルテクニックを使う。
この思考実験にはもちろん意味がない。メンバー一人ひとりのスキルや性格、お互いにどんなコミュニケーションを取るか、そういったことの方が開発手法よりも大きな影響を与えるのは明らかだ。
アリスター・コッバーンが２００３年に"People and methodologies in software development" (http://alistair.cockburn.us/People+and+methodologies+in+software+development) という記事でまとめている。
" 人と人の間で、更には刻々と経過する時間の中で変化するメンバーのキャラクターこそがチームの振る舞い、結果に影響する最初の要因だ。 "
私がプログラミングを始めた1970年当時、開発体制はプロジェクトマネージャー・ビジネスアナリスト・シニアプログラマと言った階層構造でガッチリと管理されていた。開発言語やツールを選ぶことは許されていなかった。私はいくつかの大きく複雑なプロジェクトに関わっていたが大体上記の様な働き方だった。成功したプロジェクトもあれば上手くいかないものもあった。
今は開発言語やツールに合わせて、開発手法・働き方をプログラマが選ぶのが当たり前になっている。アナリストやらがプログラマを監査することは殆どなくなった。プロジェクトマネージャーは"リーダー"・"スクラムマスター"という形で矮小化され、管理職の権限は無力化され「チームの意見をまとめる事」以外は何も出来なくなっている。
ガントチャート・スケジュール・ドキュメントを使った「厳格なマネジメント」は"ユーザー"や"ステークホルダー"の関与を省かせて、"ユーザーストーリー"を要約していた。今や私の周りではまともな大人が監督してるとは思えないプロジェクトばかりだ。プログラマのカウボーイスタイルのコーディングを放っておいてるのに、彼らは自分好きな手法を適用するか作るかさせて、１９８０年代以上に決め事・儀式だらけだ。
実際、今のプログラマは１９７０年代のCOBOLの現場以上に手法論について厳格で、盲信している。実際私が最近関わるプロジェクトは、大体の場合何も価値を生み出さないのに一人か二人のメンバーが開発したプロセスや"ベストプラクティス"を背負わされてるものばかりだ。
プログラミングチームが手法論を採用する（多くの場合チームの数名か、一人のいじめっ子が決めるのだが）と、やがて厳格に従うように要求を始め、やがてそれは宗教になる。そうなることではじまる無自覚な攻撃が、手法論やテクノロジーが生産性を高めるより早く、チームの生産性を下げてしまう。
私の経験から言わせると、アリスター・コッバーンの論文やフレデリック・ブロックスの「銀の弾丸はない」http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html で述べられているように、プロジェクトを成功させるにはチームメンバーが共通のビジョンを共有する事（その本では「コンセプトの統合」と呼ばれている）が必要だ。特に何かの手法論を指しているのではなく、これと言ったプロセスがない場合でも同じだ。私はプロジェクト管理ツールの「完了」ボタンをクリックするだけのチームで働いことがあるが、何故か分からないがBDUFやアナリストの監査の元で働いていた昔よりも気分が悪いものだった。
私はプログラマは様式やツールにこだわるより、同僚の話にもっと耳を傾け、もっと一緒に働くことに注力したほうが良いとおもう。そしてプログラマは手法論やプロセスについてもっと疑って掛かった方が良いと思う。そうすればみんな魔法の様に生産性が上がる、間違いない。多分プログラマが社交的なスキルを高めるのは他の職業より大変な事だと思う。（私は必ずしもそうだと思っていないが。）でもそういったスキルを鍛える事は、手法論を試すより事よりはるかに元が取れる、間違いない。
これの翻訳です。
http://typicalprogrammer.com/why-dont-software-development-methodologies-work/
注1 '14/02/11 まだ半分しか翻訳してません。（明日完成予定）
nginxはキャッシュつかってませんし、php-fpmはインストール後のデフォルト状態、
Mysqlはインデックス適当でQueryCacheもOFFの状態…
前半で書いたとおり、サイトのスピードは現状adsenseの表示スピードに
引っ張られているので、このまま。
->aboutとかその辺
いろんなソシャゲのページを作りたかったので、
１．ヘッダー
２．サイドバー
３．メインコンテンツ
３,５．ページャー
４．フッター
またそれぞれ、総合ページからしか見られないコンポーネントと、
それぞれのコンポーネントをユーザ関数ではなく、ファイルをincludeする形で
最終的なinclude用のファイルが18個…
このあたりphpのプロの方はどうやって対処してるんでしょう…
ファイル+functionで分けてるんでしょうか…
また、総合ページとゲームカテゴリページのトップページのSQLの内容がぜんぜん違うため、
abbench（前半参照には情報だしてます）では秒間の処理可能数が倍（総合ページ100req/sec ゲームカテゴリ250req/sec）となっています。
細かく見ると、総合ページではカテゴリー一覧をselectした後に、記事リストをカテゴリーリスト別にselectしてますが、
各ゲームカテゴリページでは１回のselectで終わっています。
現在はゲームカテゴリは３つしか作っていませんが、将来的にはもちろん増やす予定ですので、
今後どんどん重たくなっていく見込み・・・
RSSフィードを取得するCronにあわせて総合ページのメインコンテンツ部分を静的HTMLにしていくのもありかなと。
そうすると負荷がかかるのは作成時の１回のみになるとおもいますので、ユーザさんから見たら早いページ表示になるかと。
ただし、総合ページってどれくらいの人がみられるんですかね…
巷のアンテナサイトさんは、ハテブのブックマーク数やtweet数などのSNSの評価数や、あとで読む機能、
特定のサイトを非表示にする機能など、結構いろいろな機能が付いてます。
今回は夏休み終了に間に合わせるために、というのもあって、ばっさり機能を落としましたが、
こういう機能って必要なんですかね・・・？ 個人的に使ったことがないもので・・・
そういうニーズがあればつけてもいいとおもっているのですが、現状遅いサイトをさらに遅くはしたくないので、
adsenseを１個にして機能をつけるくらいなんでしょうかねー。
adsenseまったくなしだと、鯖代の維持がもったいなくてサイト閉めちゃう方向に動きたくなっちゃいますし。
プログラムのリファクタリングとデザインの変更は必須だなとおもっています。
とくにデザインは早いうちにどうにかしないといけないんですが、
これだけは自分のスキルにないので、そのうちLancersのお仕事一覧にのっちゃうかも…
もちょっといろいろなサイトを見て回って、構想を深めたいのですが、
個人レベルでの大規模サイトって、なかなかノウハウないんですよねー。
ある程度たまったら、こうしてみたらいいじゃない？ってのをまたここに書ければいいなぁとおもっています。
以上、長々とサラリーマンの日記を見てくださってありがとうございました。
（なんか規約違反で通報されたので、サイトURLと前半の日記へのリンクはなしでお願いします。
というより、ここまで書いててなんだけど、増田って書くの初めてだから正直どういうルールかわかんね
「レーザー核融合反応の実験に成功、クリーンエネルギー実現か＝米国」という表題の記事がひどい。という話。
http://news.searchina.ne.jp/disp.cgi?y=2012&d=0720&f=it_0720_001.shtml
大元の記事だと思われるアメリカのローレンスリバモア国立研究所のプレスリリースが下記。題は「National Ignition Facility makes history with record 500 terawatt shot」
https://www.llnl.gov/news/newsreleases/2012/Jul/NR-12-07-01.html
この元記事の題名を見るだけでも大まかにわかるとおり、LLNLの発表した内容は核融合反応に関するものではなく、レーザーに関わるもの。おおざっぱに言うと「安全保障（要は水爆関連）や基礎研究、核融合発電などの研究に用いる大強度レーザー装置の増強、整備によってついに500TWのピークパワーを持ったレーザー発振に成功した」という内容。ちなみに「地下核実験を不要にする唯一の施設」なんて書かれてたりして、実は核融合エネルギーについては大して書かれていない。
そんなわけでサーチナの記事とその元になったチャイナネットの記事はなぜかこれを「核融合に成功して500TWを出力」という記事に書き換えていているという意味で間違っている。が、間違いはそれだけではない。レーザー核融合は「レーザーを燃料球に当てて爆縮し、核融合反応を起こす」ものであるにもかかわらず「「衝撃点火」方式による人類史上もっとも威力のあるレーザー光線の放射」と表現していて、あたかも核融合反応によってレーザーが放出されたかのように書かれているので因果が真逆になっている。ちなみに「衝撃点火」という言葉は元のプレスリリースには含まれておらず、チャイナネットの記者が勝手に付け加えたもの。衝撃点火は阪大のレーザー研が概念として提案している核融合反応の点火手法の一つで、未だ実験は行われていないしLLNLは中心点火なのでこれまたおかしい。
あとついでにNIFの話
LLNLのNIFは核融合研究のための世界最大のレーザー発振施設な訳だけど、実際は水爆のシミュレーション施設としての機能が強い（というか予算は安全保障メイン）。NIFの実験は間接照射の中心点火といって、「金の円筒内部にレーザーを照射、発生したX線で燃料球を加熱、爆縮して核融合を起こすシステム」だが、これは水爆の「原爆の起爆によって発生したX線などによって燃料球を爆縮、起爆する」に近いプロセスで、こういう実験によって水爆関連の研究を行っていることがNIFを「地下核実験を不要とする施設」だと評価する理由であり、NIFが高速点火（阪大などがより核融合発電向きであるとして提唱する点火手法）を採用しない要因になっていると考えられている。(高速点火には主加熱源よりも短パルスな加熱が必要だが、核弾頭にそんなものは組み込めない)
一方で日本の阪大や光産業創成大学なんかがやっている高速点火は「発電炉」に特化した研究が行われている。たとえば「大出力・高繰り返しの半導体レーザードライバーの開発」「発電炉に必要な1秒に10回程度の核融合反応」「1秒に10個使われる燃料球をリアルタイムに生産するシステムの開発」などである。
阪大も光産業創成大もレーザー出力はNIFに数段、もしくは数桁劣るものの、「核融合発電」研究の最先端は日本であると言って過言ではない。
ちなみに、もう一つの核融合発電コンセプトであるところの磁場閉じ込め核融合は現在フランスに国際協力下でITERと呼ばれる実験炉(発電可能レベルのプラズマの数分の保持やより長時間の保持、商用発電炉で用いるコンポーネントの実証が目的)を建設中であり、未だ実験炉の設計すら始まっていないレーザー核融合に比べると数歩は先を行っているのが現状である。
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
http://anond.hatelabo.jp/20110908093243を可能な限り段落を再現してエキサイト先生に翻訳して頂きました！
長い間、私は暗箱にいます。
私が箱の外部で聞いた誰かのコメントによれば、劇薬を含んでいる小さなボトルは、この箱に位置します。ボトルは完全に密閉されますが、ハンマーはボトルの近くに配置します。また、彼らは、ハンマーがある時に倒れるだろうと言いました。
いつになるかは「ある時間」です?私は知りません。このまさに瞬間に?あるいは遠い将来?恐らく、それは既に来ました(私はそれに関して考えたくありません)。誰もハンマーに影響することができません。独立事象として、それは、見込みで50%倒れるでしょう。見込みはちょうど50%です。ひょっとしたら、ボトルは壊されるかもしれないしあるいはだろう。自分に関して、死者、あるいは、生きている。
私は言わなければなりません、状況はどれくらい恐ろしいですか。
私は、猛烈な憤慨を持たないようにはすることができません。私の人生(私のための最も重要な問題)は、私から完全に離れており、単純な図、FIFTY PERCENTに単独で依存します!あまりに恐ろしい。
さらに、私は、それは完全に不合理であると思います(そして)。私は、ちょうど50%で見込みを維持する多くの方法で束縛されます。
視覚。箱は、任意の光から完全に保護されます。それは、ボトルと装置を見つけるおよび破壊することから私を回避するためにあります。完全な暗さ。私は完全な暗さにいます。したがって、今、私は、自分のアウトラインさえ見ることができません。恐らく、それは奇妙に思えます。暗さは私に私の体自体の存在について疑問を抱かせます。
聴覚の知覚。恐らく、私が上に言及した理由から、完全な遮音は使用されます。私は、私自身の音声さえ聞くことができません。私はメカニズムを知りません。まず第1に、私は、何も見ることができないとともに、どのようにそれを調査することができますか。したがって、これは恐らく推測だけです、私の鼓膜はこの箱の中の包囲の前に破損されました、あるいは、ある特別の資料は箱の壁に使用されます。
とにかく、光と音の保護であまりによい暗箱では、ちょうど用語が示すように、私の視覚的・聴覚の知覚は死んでいます。
あたかも一層の確認が必要かのように、私を極度に圧迫する巨大な疲労は私のための別の拘束物です。それらは努力から私を回避するために私にある種類の筋弛緩剤を与えたように見えます。私が同じ姿勢から変わることができないとともに、私の触覚はほとんど麻痺しています。
光はありません。音はありません。匂いと味は信頼性が低い。触覚は不調にあります。私は操り人形に似ています。すべての五感は私のコントロールが不足しています。あまりに残酷です。完全な拘束物。それらが睡眠薬を与えていた場合、私は望みます。私は、外傷のない苦悩にいると思います。私の生活(私の存在(自体))は完全に無視されます。そのような屈辱は私の正気を維持します。そのような屈辱だけができます。
自分の生および死をコントロールする権利は完全に奪われます。私はそのような状況を嫌います。私の生活の連続性の中核決定要素は完全に依存します、で、単独で、で、純粋な見込み。誰からでも完全に遠方に、意志があります。私は再びそれを嫌います。私はそれを嫌います!
なぜ私は、そのような箱で囲まれなければなりませんか。そのような途方もない箱では、なぜ私は、そのような完全な拘束物を備えた、生命不安および死にいなければなりませんか。
私は孤独です。私は、中身がなく、水平に感じていますか。すすり泣かないようにすることが困難です?番号私の孤独ははるかに深い。私は空間の海でいます。私は一人です。完全に孤独です。孤児として、私はこの無限の暗さに向けられました。私は絶対零度の中で震動しています。
この箱に展望はありません。暗さだけがここにあります。私はボトルとハンマーを感じることができません。私は壁、底および天井をまた感じることができません。それらはそこにあるに違いありません。しかし、私の五感がすべて奪われます。何もないように、私は感じます。それらのものがいくつかの意味を持っている一方。
正直に話して、私は、箱にいるかどうかそれほど分かりません。私は、私の姿が存在すると確信します。私は考えています。私は空想しています。それは証拠である、私の独自性を示すこと、呼ばれる、自我あるいは意識、あるいは心、固体です。しかし、独自性はありますか、本当に箱で囲まれる?それが別のスペースで浮かんでいることはありえますか。私はそのような疑問を除去することができません。
恐らく、私がここでであるものは、宇宙に結局浮かんでいるか、あるいはマリアナ海溝の底に横になっています。あるいは恐らくキラウエア火山の穴から下降して行くこと。
私には、箱(私を囲んで)がどのようにか知る方法がありません。私の感覚はすべて死んでいます。私は、ここに、箱の内部があるかどうか判断することができません。
私は、本当に生きているように、それに加えて、確かではありません。私には、そんな単純なものを確認する方法がありません。恐らく、50%の見込みは私を越えて既に通過しました。恐らく、私は既に死んでいます。私はまだ、恐らく生きています。浅くて、筋弛緩剤を注入された、呼吸する、弱い心臓の鼓動。あるいはそれらのすべての停止(単に去る肉大型丸薬)。
私は私自身の身体をコントロールする任意の能力を奪われます。誰が私の心が重大な活動を継続する身体に存在すると言うことができますか。五感は完全な暗さで毒されました。それらは感覚器として機能することができません。私は、真実を知る見込みがありません。恐らく、どんな推測も一人で作り上げられます。私を包む状況および自分の独自性は恐らくプログラムされた回転プレーのコンポーネントです。
私の存在に関して、私は振る舞いを決定することができません。私は、それを認めることを嫌います。しかし、私は変動の最中です。
私は、誰かが私を見つけることができたらと思います。私は、誰かが箱を開くことができ私がいかがか言うことができた、らと思い、私がどういう人か決めることができました。私の内側にそうするのに十分な力はありません。私ができるのは孤独の中で震動し続けることです。
もし神ならば、私は言うことができるでしょう「そこにさせる、軽い。」私は、それが不可能なことを知っています。しかし、私は、私がそのように言うことができたならばどれくらい素晴らしいだろうか思わざるをえません。
私自身の自由意志!それは、自分を取り巻くすべての変動を固定することができました!
同時に、切望は影を生産します。箱が開かれるなら、私は見つかり観察されましょう。その結果、私の姿は決定されるでしょう。実を言えば、私は決定を心配しているという事実から視線をそらすことができません。
一人で生きているか死んでいるかどうか判断することができませんが、私は死を恐れています。残念ながら、私は死者として決定します。私は受理することができません。まだ、私は感じることができません。私は特定の現象として死を想像することができません。恐らく、そのため、私は死を恐れています。
いいえ、それは私に制限されるべきではありません。高潔なキング。致命的な殺害者。規則的な人々。すべての同じ。恐らく、悪い疾病の年上の人々あるいは患者は、十分に真実の死に近いある想像を持つことができました。しかし、それでも、死の特定の経験を知ることができません。
結局、死は圧倒する重要性を備えた最終仕向地です。時間と意識は絶対的な不可逆性を持っています。死にはさらに変更することができない完全無欠さがあります。それが儀式の通過点あるいは顕著な印象的な出来事でも。
私自身、ここの私の心はそうです、そのときは消えられるだろう、どれ、私がいかがかが決定されます。それらが生ぬるい水(私はその中で温度を感じることができない)から奪う場合、私は、大気に身をさらさないようにはすることができません。
私はそのような不可逆変化を恐れています。それは死の決定に制限されていません。さらに、非常に心配しているので、私は生きていて決定されます。
自分の現在の存在は、無限のポイント上に立っている小さく小さな幻覚に似ています。それほど大きくない。それほど小さくない。それほど長くない。それほど短くない。拡張はありません。収縮はありません。ユニークな単一のポイントで立っていること。それは数学上正確です。私は、自分の同一性に関する混乱があるそのようなポイントでとどまるゴーストのようなものです。
ポイントは同時(ある位置で既存でない)に座標の飛行機ですべての位置で存在します。ある出来事が生じれば、その瞬間においては、それは、すべての地空(あたかも私の招待がバスから降りるかのように、出来事がその中で生じた)中の単一のポイントに私を集中させるでしょう。関係なしで。ポイントと私がものだったとしても。
幻覚(それはそのようなポイントでとどまった)は、等しい程度に対して、実際で霧のように消されているの可能性を持っています。
さて、私はすべての配当通過時間の中で既存です。そして、私はすべての自然を持っています。同時に、私は孤独からそれを受けています、私はすべての自然から離れています。私は、誰かが私を見つけることができることを望みます。同時に、私は非常に心配しています、私はどこにいてそれ、私はその瞬間にいかがでしょうか。
