  |
はてなキーワード: BASICとは
結論から言うと型を欲するのは成長できた言語のみに許された特権である。
どんな言語も最初から厳密な型チェックをアピールしてしまうと開発を阻害するばかりで流行らない。
増田の理屈だと最初から全部C++かJavaで作ればいいじゃんとなるが、
現状を見るにそうはなってない。
web黎明期のフロントエンドを支えたのは紛れもなく型チェックのゆるい言語だ。
パソコン黎明期の一般向け主力言語はBASIC（あるいはアセンブラ）だったわけだが、
時代が進むにつれて型チェックの厳しい言語を求めるようになるのは理由がある。
それはプログラムの規模だ。
言語が出た当初はライブラリも少なく、できることも少なかった。
時間が経過してライブラリやノウハウが蓄積し、マシン性能向上も相まってできることが増えてくると
プログラムの規模も増えてくる。
すると、厳密な型チェックを取り入れないと全体を統制できなくなるのだ。
Hacker Newsの上の方にAheui(아희) https://aheui.github.io/specification.en というのが上がってきていて(ろくにコメントがついてないが)、どうも世界初のハングルを使ったプログラミング言語であるらしい。
どんな言語なのかとググってみたらが日本語の情報はなく、2014年と2015年に同プロジェクトのページをはてブしている人がいた程度だった。
This code prints “Hello, world!”
밤밣따빠밣밟따뿌
빠맣파빨받밤뚜뭏
돋밬탕빠맣붏두붇
볻뫃박발뚷투뭏붖
뫃도뫃희멓뭏뭏붘
뫃봌토범더벌뿌뚜
뽑뽀멓멓더벓뻐뚠
뽀덩벐멓뻐덕더벅
これがその言語で書いたHello,World!なのだそうだが、短縮しまくったPerlより読める気がしない。本気で使おうとは思っていないのかもしれない。
ハングル文字の中に方向を示すキャラクタがたくさんあり、カーソルを動かすイメージがつかみやすいという売りはあるようだ。
Wikipedia: Non-English-based programming languages
https://en.wikipedia.org/wiki/Non-English-based_programming_languages
これ見ると英語以外で記述できるプログラミング言語は多い。中国はBASICやPython、C++を中国語化したものかあるらしい。C++中国語版は丙正正。名称がそのまんまといえばそのまんま。BASICを見ると一つ一つのコマンドに漢字1文字が割り振られているだけのような感じだ。インドのヒンディー語もそんな感じ。その程度のレベルならプログラミング言語を母国語に置き換えるメリットはないか。
日本にもひまわりやMindなど日本語の単語を使えるプログラミング言語があるけど、あれらをマスターしてる人は見かけないな。
プログラミングって、これから始めてみようっていうとき、なんだか「得体のしれない行為」っていう感覚がありませんか？
ぼく自身は、プログラムを書いてる側の人間で、いまでこそ少しはプログラミングの本質的な難しさをわかってる気になってます。でもつい数年前までは、プログラミングは難しくはないけど得体がわからない、という感じでした。
そのへんのコードを組み合わせて動くものはできるけど、何がどうなっているのかは知らんし、ググって分からないものはできない、という方向で、「プログラミングは難しい」と思ってました。
最近になって、プログラミングの義務教育必修化の話題とか、コピペプログラマーの話題とかを目にするたびに、かつて自分がプログラミングに対して抱いていた「得体のしれない行為」という感覚が思い出されてしまい、少しざわざわした気持ちになったので、ちょっとここに書きなぐらせてください。
だいたいが個人的な話なので、そういうのがうっとうしい人は無視してください。
ぼくが世の中にパソコンという道具があることを知ったのは、たぶん中学生のときです。30年くらい前。当時、電気屋の売り場ではけっこうな床面積を使ってワープロ（文章を入力する専用マシン）が陳列されてました。文章を書くのは好きだったけど、字を書くのが死ぬほどめんどくさかった自分は、ワープロさえあれば自分も小説とか書くのになあと思いながら指をくわえて電気屋の店内をうろうろしてました。しかし、ファミコンすら買ってもらえなかった家計ではワープロなんぞ買ってもらえるわけもありません。そのうち巡回してた電気屋からはワープロが消え、それに代わってパソコンのコーナーが広がっていきました。このパソコンというのは、よくわからないけどワープロとして使えるっぽいし、どうやらファミコンを持っていない僕にもゲームができるらしい、おれに必要なのはこれだ、というわけで、中学生だった自分はパソコンという存在に興味を抱くようになったのでした。
とはいえ、だからといってパソコンを買ってもらえるような家計ではなかったわけなので、カタログを熱心に眺めるだけの毎日が続きました。その当時の自分にとって、パソコンが欲しいといったら、それはNECを買うかエプソンを買うかという選択でした。冨士通からパソコンが出ていることは知りませんでした。マッキントッシュっていうやつもあって、このPerformaっていうやつはなぜか安いとか、よくわからないけどシャープとかソニーも独自にパソコンを作っているぞとか、そういう情報がパソコンに対する認識のすべてでした。当時の自分にとってのパソコンは、電気メーカーから発売されている商品の一種であり、ラジカセとかテレビと同列の存在でした。
なんでこんな話がプログラミングにつながるかというと、ひょっとして自分がプログラミングにずっと感じていた「得体のしれなさ」の源泉の一つは、こんなふうにパソコンを電化製品として見ていた当時の感覚の延長だったのかもなあと思ってるからです。
ラジカセなら、CDだのテープだのを入れて再生ポタンを押せば、そのハードウェアの機能を物理的に体感できます。それに対してパソコンは、プログラミングをちょっとやってみても、その行為と、そのハードウェアとが、感覚的に結びつきません。もちろん、プログラミングというのは、物理的なデバイスに結びつけて考えなければできない行為ではありません。しかし、パソコンを「カタログの商品」として見るところから入ってるばかりに、そこでやるプログラミングという行為とハードウェアとの結びつきが見えにくい状態に、なんとなく居心地の悪さを感じていたように思うのです。
もし自分のスタート地点が、パソコンを使って文筆やゲームをするところだったら、パソコンは文筆やゲームのための箱だったでしょう。その後でプログラミングを始めていたなら、プログラミングという行為を、文筆やゲームに関連した創造的な活動として学べたかもしれません。
ところが実際には、自分はつい数年前まで、パソコンという電化製品に対する漠然とした行為としてプログラミングを捉えてた気がします。
プログラミングを始めたのは、高校生になって誰も使わないFM77が部室に置いてあったので立ち上げてみたらF-BASICのインタプリタが起動したからでした。とくに何をプログラミングすればいいかもわからなかったので、教科書や雑誌のコードを転記したり、ループで線画を書いたりして遊んでいました。大学に入ってからも、授業でFORTRANとかLispをやらされたけど、基本的に自分で目的をもってプログラミングするのは数値計算くらいのものでした。そのころになると、本で情報を探して（まだインターネット検索は使い物にならなかった）適当にコードをつなぎ合わせるのがプログラミングだと思ってました。そんなん面白くないなあ、とも思ってました。
この感覚、完全に、いま揶揄されているコピペプログラマーのそれだったと思います。ちょっと話はそれますが、ブロック遊びとか砂場遊びって、ほとんどの人はわりとコピペプログラミングと似たような感覚でやってるんじゃないでしょうか。パーツを勘で組み合わせたり、とにかく砂を盛っていったりすれば、家みたいなのができるよね、という感覚。プログラミングは、自分にとってそれに近い作業でした。学生のころは、内心、自分にもパソコンとサンプルコードさえあれば何かすごいものを作れるかもなあ、くらいに思っていたふしもあります。
自分はバカでした。パソコンがあるとかないとか、関係ないのです。パソコンさえあれば、なんて思う者に、本当のプログラミングがわかるはずがありません。
そんなこんなで、自分はまともにプログラミングを経験しないまま社会人になったわけですが、幸いにもプログラミングに対するこの感覚は、仕事でパソコンを日々使うようになってから徐々に変わっていきました。
具体的には、パソコンが、自分の中で「カタログの商品」から「武器」へと変わりました。それと同時に、プログラミングという行為が、武器開発という位置づけになりました。
武器というのは言い過ぎだとしても、ちょっとしたプログラミングは確かに業務上の課題を打開しました。それなりに計算機科学の教科書を読んで勉強をしたこともあって、いつのまにかプログラミングに対する「得体のしれなさ」も解消してました。
結局のところ、自分にとっては、プログラミングという行為の「得体のしれなさ」から解放されるまでにずいぶん長い時間が必要だったことになります。自分がそうだったからといって他人もそうだとは限らないですが、たとえば小学校で形だけプログラミングを教わっても、分かるとかわからないとか、好きとか嫌いとか以前に、なんかモヤモヤした気持ちになるだけの子どもも少なくないんだろうなあ。それは不憫だなあ。
かといって、自分がいまプログラミングで少しは戦えてるのは、そのむかしパソコンに憧れがあって、得体がしれないなりにプログラミングをする機会が若いときにたまたまあったからでもあるので、そういう機会になるなら小学校で形だけでも教えるほうがいいのかなあとも思います。
オチがないので、このへんで。
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した（あわせて前処理として、コミットログ冒頭のタグ情報は消去した）。
atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。
こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。
ということで、以下用例を羅列していく。
以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。
| Add | 1149 |
| Fix | 1014 |
| Update | 584 |
| Remove | 566 |
| Use | 382 |
| Don't | 260 |
| Make | 228 |
| Move | 178 |
| Change | 103 |
| Rename | 85 |
| Improve | 76 |
| Avoid | 68 |
| Allow | 65 |
| Implement | 60 |
| Handle | 58 |
コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は a が使われるか、あるいは省略される。the はまず使われない。
何かを追加した、という表現では非常に広く Add が使われる。メソッドからテスト、ドキュメントに至るまで大概これでまかなえる。
一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typo や crash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である。
Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合は Make sure が使われる（こちらはthat節が取れる）。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う（Ensure はさらに重い表現っぽい）。
また、Fix は typo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメント、コメント、テストに使われ、本体のコードの修正に対しては使われない。本体コードの修正にあわせてテストも更新したなら Update が使われる。ただ、テスト機構それ自体のバグを修正したなら Fix である。
無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)から別のもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合は Don't use を使うことが多い。
何かをしないようにしたなら Don't を、内部実装の効率化なら Make A + 比較級/形容詞 か Improve が使われる。
中身の変更を伴わない単なる名前の変更なら Rename A to B、コードや機能の論理上の場所を移動させたなら Move A to B である。
この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。
コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である。
一方で、シンプルな単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的で平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。
8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体が効率のいい学習になるという話と同じだと思う。
このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。
僕の場合、ワープロからはじまり、物置に眠っていたBASIC機をいじり倒し、叔父から譲り受けたDOS機をいじり倒し、小学高学年の頃にはプログラマになることを決めていた。
そんな僕も今や一児の父だ。定時で帰れる日は息子に勉強を教えている。彼の理解力や興味に合わせた手書きのドリルを作って、学校の授業ではわからなかったところをサポートしている。今では満点をもらえることも増えてきた。同僚に技術指導をする機会が多いが、当然ながら息子に教えるほうがはるかに簡単だ。
そんな僕が思うこと。
プログラミングを必修化したところで成果は得られない。
プログラミングに入門させるくらいならエクセル教室でもやったほうがいいだろう。どんな業界でも表計算は必須と言えるし、興味があれば思うままに使って遊んで覚えてくれる。子供に教えられる家族も、それなりにいる（期待はできないが）。
ちなみに、表計算は、プログラミングのエッセンスを必要とする。変数、条件分岐、繰り返し、関数、これらはどのようなプログラミング言語の基礎となる概念だ。
さておき、プログラミングを教えるとして、どんな言語だろうが、"Hello World" がはじめの一歩だろう。その次は変数。変数を教えるのは難しい。「箱に入れる」という比喩が理解できる子とできない子に分かれるだろう。四則演算と同様に、ここでつまづくと先はない。それからも、条件分岐、繰り返し、配列、関数、ここまで来れるのだろうか。
プログラミング言語は覚えたとしても、論理の組み立てができなければ、モノはつくれない。言語を覚えることと論理を組み立てることは、必要とする能力が違う。単語を覚えたところで、ネイティブと話すことはできない。人間ならば、単語だけでも曖昧さを補完して理解してくれるが、プログラミング言語は書いた通りにしか動かない。おそらくプログラミングに苦手意識を持つ子供が増えるだけだろう。
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
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://www.mermaid-tavern.com/indexs.html
ちょっとバイナリデータのヘッダー解釈とデータ処理をExcelにやらせようとググっているときに引っかかり、中を見て驚愕した。
最初に見た一瞬はイラッとし、ちょっと読むとあまりに低レベルな煽りっぷりに笑い、しかしそれが数百ページもあって、常軌を逸したレベルの量の煽り文を書ける人間性にドン引きした。
人をバカにする文章を書きながら、「ごっこネタ」と言い逃れているあたりが滑稽であり、しかし笑えない。
検索で飛んでくる99%までがオバカなExcel屋とその同類のC#屋とAccess屋である。その実態は企業内低能パソコンユーザーである。ここではそれらを総称して「エクセルバカ」としている。これは ©Microsoft が作り出す産業廃棄物の粗大ゴミである。
このセクションはそのエクセルバカが大好きな「ごっこネタ」である。エクセルバカが能もないのにやりたがる「文字コードごっこ」「バイナリごっこ」「UTF-8ごっこ」「改行ごっこ」「エンディアンごっこ」「16進数ごっこ」「CSVごっこ」「暗号ごっこ」などを総称したものである1)。小学校程度のアタマしかない者が微分方程式を解こうとするのに似ている。なお、私はExcelやBASICなどには興味も関心もない。頭の体操のためにそれで遊んでいるだけである。
確かに不必要に余計なやり方をしている人は困るが、検索してたどり着く人の中には能があり本当にそれが必要だから調べている人がいるだろうに、ひっくるめて全員を罵倒しているのが悲しい。
能がある人は知識を持ってるからググらない？レファレンスを見るからググらない？近くの人に聞くからググらない？本当かな。
というか、文字コードなんてcgi(php,perlあたり)の初学者がWindowsとUnix系の違いを理解していないがために最初に躓く話じゃないの？今はそうでもないのかな？
Excel自体は万能ツールではないし、Excel方眼紙を使う人とか報告書を全部Excelで作れとかいう要求には俺も辟易としている。
けれど、そんなレベルじゃない。明らかに言い過ぎで拡大解釈である。
しかしこの全方位をバカにして煽っていくスタイルはいったいどういう精神構造をしていればできるのだろう。
このドメイン配下のページにリンクしている人、飛んできた人を全員バカ扱いしているようだ。
トップへのアクセスや変な階層に直リンで飛んできた輩は、別のドメインや別ページに飛ばしたうえでIPと検索ワードを取って晒し者にしているらしい。
バカにするだけのためにExcelやBASICを学んだとまで言う。すごい熱意だ。
それに加えて最高に面白いポイントは、ちょっとググっただけで本人らしき名前が簡単に出てくる程度のITリテラシーで、よくここまで言い切れるものだと思った。
実は偽名なのかは知らんが。
これが釣りなら素晴らしい釣りだと思うけど、徹底的に人をバカにする仕方と熱意の強さのせいで釣りに見えない。
そんな素晴らしい能力がある人には見えないけど、こんなことを公言している人がどれだけ仕事ができる人なのか見てみたいもんだ。
どんなオッサンなんだろう。
あれは小学校に入る1年前のこと。
という教材を母が持ってきた。
会話編と単語編があって、母は会話編を熱心に覚えさせようとしたが、僕は単語編しか興味を示さなかった。
文字列の並びに意味があること、つまりD,O,Gいう文字列が犬を表すこと、それには少し興味がもてた。
記号として、24文字があることには興味がもてて、大文字限定だが、アルファベットの読み方はマスターした。
当時としては時代遅れの機種だったと思う。
ファミコンよりもっと低レベルなゲームのROMも二本もらった。
紫色の表紙のMSXBASICの教本がついてきて、なぜかその本を読みはじめた。
さっき説明したように大文字だけは読めたので、小1か小2だったと思うが、読み進めることが出来た。
画面に線を引くとか、点を打つとか、文字を表示させるとか、その程度しか出来なかったが、ゲームをしてるようだった。
自分でも読めたが、読み聞かせをせがむ甘えん坊だったので、たまに母に読んでもらうと、母は自分がいつも
「アイエヌピーユーティー」と呼ぶ「INPUT」という文字列を
「インプット」と呼び、その度に「インプットってなに？アイエヌピーユーティーのこと？」
と間違いを訂正させた。
母親は僕がなんでこんな本を読み聞かせをせがむのか理解できなかったそうだ。
小2くらいだと、IF関数やループを理解できなくて、母に何度も質問した。
母もわからなくて困ったそうな。
私は座って聞くタイプではなく、自分は他の遊びをしながら母に朗読させるという非常に図々しい読み聞かせを要求する子供だった。
ただでさえ小2には難しく、自分で読むときはギリギリ理解できても、他の遊びをしながらだと、時々理解がぶっ飛んだ。
その瞬間によく転んだ。
よく母も付き合ってくれたものだ。
小3くらいだったか、巻末の50行くらいのブロックくずしのプログラムを入力した。
毎日コツコツと打ち込んで、データレコーダーに保存すること数日。
実行してはエラー。
画面のプログラムと本を舐めるように見比べて、間違いを探しの繰り返し。
始めて動いた時は感動した。
母や父に自慢したが、反応はイマイチだった。
小3だったら読み解くくらいは出来るようになったが、それが精一杯で、自分で作ったりは出来のが大きいかな。
同じプログラムを書いてはパラメーターを変えてみることの繰り返しをしたが、すぐ飽きた。
その頃、パソコンというものとロータス123があるといろいろ便利という噂を聞いて、パソコン雑誌1冊が我が家にきた。
あの頃のパソコン雑誌というものは、投稿プログラムのコーナーが紙面の1/3を占めていて、ロータス123とそれを使える機種以外興味がなかった両親はほとんど開かなかった。
我が家に新しくやってきたPC8801だか9801に僕が一本指タイプで写経する教材となり一か月に1つくらい写経した。
両親はロータス123を使いこなすことができず、(というよりMSDOSでつまづいたと言ってた気がする)
何十万もする高価な箱を自分が占有する形になったが、ゲームが買い与えられたわけでもなく、BASICだけだったらMSXでこと足りたので、楽しいマシンという記憶はない。
そんなこんなののち、1年くらいでBASICの熱は冷めた。
パソコンに自分から触れる機会はその後の人生でほとんどなかった。
卒論や、就職してからの業務でWordとパワポ、Excelの簡単な使い方を覚えたが、
ひょんなことでExcelでIF関数に再開し、懐かしさからいろいろとExcelの関数を使い倒してみた。
ついでにと、本屋でExcelマクロ作例集というものを買ってきて、家で読んでる。
家にパソコンがあれば昔のように写経するのだが、コードの解説を読んで脳内で動きを想像して楽しむことしか出来ない。
この程度なら自分でもすぐ書けそうという反面、仕事に役立てそうなことはあまりない。
あの頃多用したバブルソートを使ってみることはできたが、Excelの標準機能で並び替えを使ったほうが早いわけで。
好きに表記すればいいと思いつつも見ると内心もやもやしてしまう。
やっぱりJavaと表記してほしい。Java……かっこいいじゃん！
※ Javaだけだと馴染みのない人もいると思うので似たような例を挙げる。
× SKYPEアプリ ○ Skype × PHOTOSHOPソフト ○ Photoshop × YOUTUBEサービス ○ YouTube
大まかには次の二点だと思っている。
COBOL、LISP、ALGOL、FORTRAN、PL/I、APL、BASIC……
今はFORTRANも新しいFORTRANはFortranと名乗っているし、BASICもBASICの派生はVisual Basicなどと名乗っていたりする。
時代に逆行してJavaをJAVAと表記してしまうとJavaがあたかも古い言語であるかのような印象を与えることになる。
× JAVA ← 1960年代の言語ですか？ ○ Java ← 今時の言語っぽい！
「言語」という接尾辞をつけてしまうと二重敬語のようなまわりくどい印象を与えることになる。
Cのようにググラビリティが低いため止むを得ずC言語と表記するという場合もあるが、Javaならそういった問題は無い。
コンピュータ関係で他のJavaと衝突していないか？それは大丈夫だ。
https://ja.wikipedia.org/wiki/%e3%82%b8%e3%83%a3%e3%83%90
Scalaちゃんは今日も「余裕でした(´･_･`)ﾄﾞﾔｯ」とツイートするんだろうか。
ここ2,3年くらい、Vimが妙に流行っている。はてブやqiitaでもVim関連のページが出れば大量にブクマがつくし、「俺はVim派だから」みたいな発言を大学だったりtwitterだったりでもみる。
しかしその実、世間に出回る「vim tips」みたいなのをみると、cやr,はたまたw,$,0,..など超がつくほど基本的なものしか載っていない。
なんでこんな常識的なものにこんなにブクマつくの？？？っていっつも驚く。
昔はvimに憧れるワナビーがブクマをつけてるのではないかと思っていたが、どうやら今のネット界隈では「vim派」と言って通ぶることが一種のステータス？になっているのではないかと思うようになった。
ちょっと前に流行ったvim pluginブームにもびっくりした。vimはあくまでもIDEなんていらないスクリプトを書いたり、CUIでエディットしたい時に使うものだろう。
ものには使いみちというものがある。文章、少なくとも日本語はVimに向かないし、Javaの開発ならeclipseですらvimよりよっぽど生産性が高い。
vimにpluginなど入れて喜んでいる一部の人達をみると、やはりvimで通ぶっているだけではないかと思えてしまう。
.vimrcは長けりゃいいっていうものではない。それがemacsに対するvimの美徳のひとつではなかったのか。
そもそも、vim人口が見かけ上増えているにもかかわらずemacs人口が増えていないのがおかしい。どうも最近のvim派の人たちはemacsをあまりうまく使えていないようである。（俺のまわりだけかもしれないが）
昔のhackerはエディタ戦争なんて言いながらもお互い両方のエディタを使えたものだ。大体がshellでset -o viなんてしたら使いづらくて仕方がない。shellはctrl-aで先頭に戻るし、ctrl-rで履歴検索をするものである。
そもそもエディタ戦争なんて洒落にすぎないんじゃないかと個人的には思っている。viとEmacsは基本教養である。どちらかしかできないのは文盲のようなものである。
vimvim言ってブクマしてるみなさん、vimtutorは起動したことありますか？Vim関連の記事を100個ブクマするよりよっぽど有用です。
Do one thing and do it wellって知ってますか？一つのプログラムでなんでもしたいならwordかVSで十分です。無理してviを使う必要はないです。
俺はまだLinuxを使い始めて10年くらいだけれど、エディタはvi(m)一筋だった。
何がいけなかったのだろうか。
あとviとvimがうんぬんというブコメありましたが、逆に今日びviとvimを使い分けることがあるんでしょうか…？
（もちろんインストール直後のdebianとかだとvim.tinyしか入ってないけど）
普通/usr/bin/viってvim.basicを指してることが多いと思います。もしvim.tinyを指していたらごめんなさい。
てかaliasなりupdate-alternativesみたいなの使われたほうがいいのでは…？
id:akanehara （増田はじめてだからよくわかんないけどブコメに返すのこれでいいの？）
いやね、俺はNeoなんちゃらとかなんちゃら.vimとかのプラグインが流行りまくってるのどうかと思うんよ。
vi使いたくてあんなゴタゴタした画面分割するならtmuxかscreenで別タブにシェル開けばいいしそのほうが拡張性高いじゃん…っていう。
それかVSなりIntelliJで（ちなみに俺はeclipse使います。微妙にdisったけど）
あとはSIGSTOP（てかSIGTSTPか）で止めるのもよい使い方だと思う。
とにかくこれからviなりunixを使い始める人達がああいう害悪に影響されてほしくない。Neoほげほげよりtmuxとかctrl-zのほうがのちのちず～～～っと役に立つから。
viが流行ること自体はいいと重います。emacsももっとはやって欲しいです。nanoは即update-alternatives --config editorするんで知りません
と思ったらなんかみなさんいろいろ考察してくださっていますが、今やviクラスタ≠unixクラスタなのか…
なんてこったい
TeXは確実にGUIのほうが使いやすいよ。俺はTeXstudioだけど、シェアウェア買ってる人もいるね。特に仕事道具にしてる人は。
vimじゃあPDFからジャンプとかできないから校正の時とか使いづらいことこの上ない
一理ある
問題はvim scriptはelispに劣ってるところだと思う。
言語プラットフォームとしてみたときやっぱりemacsには一日の長があるよ
なのにpluginとか言って喜んでるのはなんか違うと思うなあ。
はてなブックマーク - 将棋の初心者がたった10ヶ月でアマチュア1級を取る方法 - コスパ最強！！一人暮らしの簡単節約料理レシピ に触発されて囲碁版を書いてみるテスト。といってもVIP囲碁部( おい。おまいら囲碁に興味ないか？@Wiki - トップページ)とか囲碁板の初心者スレッドに結構まとまってる情報の焼き直し。自分はまだ日本棋院の初段になるかならないか程度だけれど書いてみた。同じく5級は日本棋院レベルの意味です。
囲碁は面白いんだが、その魅力を解説できるほどのドラゴンボールマニアではないので、淡々と上達への参考情報を出すにとどめます。
囲碁のルールは複雑じゃない。とりあえずインタラクティブ囲碁入門を、44級(「２眼作ってしっかり生きる」)までを納得するまで繰り返す。44級が腹に落ちていれば、仮にいきなり実戦に出ても、即死することはなくなる。ここまでで1-3日くらい。
44級を理解したら、一通りインタラクティブ囲碁入門を終わらせておきたい。
iPhone(iOS)環境があり、やる気に満ち満ちていて、先行投資を惜しまない、と言う性格の人には、この時点でEasyGo on the App Storeを躊躇なく購入してしまうのをお勧めする。これは入門から高段までをカバーする神アプリ問題集だが、なぜか日本での知名度はそれほどでもない模様。インタラクティブ囲碁入門で覚えたルールや考え方を何度も繰り返すのに、ぜひ実際に石を置くことのできる環境でおさらいしたい。Easygoでは、こういった問題が"Basic"という問題群としてまとめられている。$12と少し高価だが、あとで紙の問題集にいろいろ手を出すことを考えれば安い買い物と思う。ここまでで1-2週間。
このあたりで徐々に実戦感覚を積んで行く。ここでいきなり19路(19x19)に向かうと広大すぎて何をしたらいいか分からないため、まずは小さい碁盤(9x9および13x13)から、CPU戦を中心に入っていくのが定石。ストIIでも、いきなり対人台に行くとボコられたでしょ。
Windows環境であれば、10年前からあるigowinという小さなアプリがお勧めで、今でもこれが有効なはず。Igowin Free Go Software Downloadより、igowin.exeをダウンロードする。最初はたくさんハンデ(置き石)をもらった状態からスタートするが、勝ち越して行くと徐々にハンデが追いついてくる。負け越すとまたハンデが戻される。これをとにかく2週間ほど繰り返す。手元にwindows環境がなく、どれくらいの強さだったか定かでないのだけど、15-10kを目標に頑張りたい。上記本家サイトによればアイフョーンアプリがあるみたいなので、それで練習してもいいのかも。
Windowsでない環境では、オンライン囲碁ゲーム COSUMI - 無料！を使って実戦経験を積む。これはインターネット接続が必要。右上の"Play"から始める。盤面の大きさを選ぶ必要があり、最初は5路から始めてもいいかも。だんだん盤面を広くしていき、同じく2週間ほど繰り返して、9路のレベル0を目標にしたい。
そろそろ19路デビューしたい。KGS Go Serverでアカウントを作成し、世界の荒波に飛び出してもいい頃合い。申告級を15k程度にし、プラマイ2k差ほどに設定してAuto matchingを有効にし、何戦か戦ってみるといい。序盤はさっぱり何をやったらいいか分からないが、中盤あたりで石が混んでくると、これまでigowin/cosumiで鍛えた石の取り方や切断、連絡といった技術が生かせる場面が多くなってくるはず。これで面白さを感じられるようなら、そのままkgsに居着くと良い。"hi gg (hi good gameの略)"だけ覚えておけば挨拶には困らない。
このまま順調に、毎晩とは言わないが週に数回でも打っていけば、1年経たずに日本棋院の5級、kgsだと一桁級が見えてくるはず。でも順調でないパティーンも多くあるだろうので、以下にいくつか対策を。
対人はいやだ、まだCPU戦で修行したい、というのであれば、19路のプログラムを使う。無料のものだと、山下さん謹製のAyaか、はてなー大好きGNU謹製のGNU Goあたりが定番。
AyaはYSSと彩のページより、「彩のダウンロード(Win98) aya634.zip 846KB」からダウンロードできる。Windows専用。
GNU Go自体は思考エンジンでフロントエンド(碁盤)がついてないので、Go GUIを一緒にインストールするのがよかったはず。囲碁ソフト Go GUI + GNU Goあたりを参考に。
納得して進みたい、理論を知りたい、実戦は訳が分からない、というのであれば、いくつか本を読むのがお勧め。http://info.2ch.net/?curid=2314の「頻出の名著、定番書（総合書）」にあるのはどれも名著。
盤面が広がるほど、一局あたりの所要時間が大きくなる。プロでなければ、9路は5分程度、13路は10-15分、19路だとおおむね30分-1時間が目安ではないか。で、19路を対局する時間がなかなか取れない、という場合にはGo Quest (9x9) - Play Free Online Game Of GoもしくはGo Quest (9x9) - Play Free Online Game Of Goをお勧めする。囲碁クエストは躍進目覚ましい対人アプリで、9路と13路限定だが、iPhone/Androidから対戦ができる相当熱い対戦場になっている。日本以外からの接続も多いようで、早朝以外、相手が見つからないといったことがあまりない。レート1000から始まり、1300あたりを目指したい。
将棋の元記事では、ごく初期の段階から原始棒銀を体に染み込ませる、という流れだった。しかし囲碁の場合、ルールを覚えてすぐに戦法を覚える必要はなく、始めてしばらくは戦法を気にせず、物理(手筋)で殴る、を覚え込ませることが上達の近道だったと思っている。
誰か強い人に、この先をどのように進めると面白いか、書いてほしい。
https://www.facebook.com/pages/Zaricor-Originals/109247355769680
The red sun slightly to the right or the east is self explanatory. While it serves as the sun and Japanese spirit it also symbolizes the flame in the Olympic torch.
Below is a great wave, dominated by the spirit of the sun. The wave is also in the shape of a T representing Tokyo and also symbolizing the torch itself. Both these 3 meanings in the torch and the sun also relate to the 3 marks of existence.
The font styles on TOKYO 2020 and the spacing of all elements as well as the size of the Olympic rings will be tweeked as I continue the larger finished painting.
Although the design will change slightly and become more refined as I continue this is the basic idea and all seeing may serve as witness.
I hope this serves as a testament of my respect for creativity, the Olympics and the wonderful people of Japan.
Thank you, Benn Zaricor
少し右、あるいは東（※the eastは英語だと東洋を指すことがある）にある赤い太陽は、それ自体が説明的だよね。太陽と大和魂として機能する一方、オリンピックの聖火の炎を象ってもいる。
下のはグレートウェーブ（※葛飾北斎の神奈川沖浪裏は英語だとThe Great Waveとして知られる）で、太陽の魂に気圧されている。波はTの形にもなっているけど、これはTokyoを表すのと同時に聖火のトーチ(torch)自体を象ってもいる。聖火と太陽の3つの意味は、三相（※仏教で無常、苦、無我のこと Wikipedia。ただし、これはタイなどで信仰される上座部仏教の話で、日本などの大乗仏教とはちょっと違う）とも関係があるんだ。
TOKYO 2020のフォントのスタイルや、全要素のスペース処理、五輪の大きさなんかは、もっと大きな完成版の絵の作業をしていくうちに修正されるよ。
作業をするうちにデザインは少しだけ変わって、もっと洗練されるはずだけど、これが基本的なアイディアで、見えるもの全てが証拠品となるだろう。
これが、創造性、オリンピック、日本の素晴らしい人々に対する、僕のリスペクトの証になることを願っている。
ありがとう。 Benn Zaricor
ちなみにロケットニュースによる訳
http://b.hatena.ne.jp/entry/rocketnews24.com/2015/08/17/621055/
「少し右側、すなわち東側に赤い太陽があるのは自明のことです。それは日の丸と日本人の精神を表すとともに、オリンピックの聖火の象徴でもあります。下には日の丸のスピリットに支配された大きな波が描かれています。この波はまた、Tの形をしています。東京のTであり、聖火（torch）の象徴でもあります」（Zaricor Originals Facebookより引用）
1. だいたいOK
2.
これが抜けている：
This military power is sustained and inspired by the determination of all the Allied Nations to prosecute the war against Japan until she ceases to resist.
『この（連合国の）軍事力は、日本国が抵抗を止めるまで攻撃を継続するという連合国の固い意思に鼓舞され、また支えられている」
3. だいたいOK
4. だいたいOK
5. だいたいOK
6. "for all time"は『永久に』の方が正確だと思う。（×「全ての時期における」）
7. "war making power"は「好戦勢力」ではちょっとしっくりこないので、長いけど「戦争を可能とする軍事力」とか？
"Convincing proof"は「明確な証拠」というより「信ずるに値する証拠」とか？
"secure the achievement of the basic objectives we are here setting forth."
8. だいたいOK
9. だいたいOK
10. "stern justice shall be meted out" 「正義を付与」って日本語ではあまり使わなさそう。普通に『罰を与える』『制裁を下』とか？
「強化しあるいは復活するにあたって」原文はandなので「復活および強化するにあたって」
11. 軍事を目的とした産業はダメというのが抜けているし、いろいろ直訳っぽい。『日本国がその経済を持続するため、および物資的賠償を可能にするための産業を維持することを許可する。ただし、新たな戦争に向けて軍事力を復活させる目的のものは許可されない』。原文の"permit the exaction of just reparations in kind"は正直なところ意味が曖昧だと思う。just reparations in kindということは「物資的な賠償」だと思うのだけど、これは誰に向けての賠償なのか？なぜ金銭的な賠償ではないのか？がちょっと不明。
あと『この目的を達成するために、原材料を入手することを許可するが、支配することは許されない。』
"Eventual"は『そのうち』『長期的』という意味だと思う。
12. だいたいOK
13. だいたいOK
