「BASIC」を含む日記 RSS

はてなキーワード: BASICとは

2017-11-29

タイムスリップして無双するとして

ビートルズ時代タイムスリップして、ビートルズより先に曲を発表してしま漫画があるらしい。

100年前にタイムスリップして、アインシュタインより早く相対性理論を発表するとかムリだし、300年前のニュートン力学絶対むりだな。

1970年代タイムスリップしてビルゲイツより早くBASICを作るのは可能だけど、一流大学とかでてるわけじゃないしコネがないからどのみちムリか。

80年代ファミコンゲームボーイのヒットゲームを作るのは可能かな?

90年代以降のゲームが大規模になっていく時代タイムスリプしても無双はムリか。

2017-10-30

久しぶりにゲームを作りたいんだがオススメツール教えてくれ

今までの履歴ゲーム作った時期:ツールゲーム内容:備考)

小学生RPGツクール:身内ネタRPG製作時間ー10時間 プレイ時間ー5分:スクラップ・アンド・ビルドしてるうちに身内ギャグまみれのクソRPGに。一通り友達と笑って5分で飽きた。

中学生BASICピンポン・陣取りゲーム等:製作時間ー合計30時間 プレイ時間ー各2分:プログラムの基本を学んでいる間に飽きた。PRINT "Hello, world!"が一番楽しかった

大学生HSP(ホットスーププロセッサー):STG製作時間ー30時間 プレイ時間3分ゲームの作り方は一通り頭に入ったけどHSPというツール限界を感じたので別の言語を探そうとしているうちに何かが面倒くさくなって二度とプログラムとかやらねーと誓った。

最近インディーズゲームってよく出来ているのが多いじゃないですか。

から面白いのは多かったけどここ数年は特にいい波が来てると言いますか。

それでそれらをやっていたら自分も久しぶりにゲーム作りたくなったんだけど、なるたけ楽して開発の楽しみが味わえるツール言語って何かないのかな。

WOLFエディターで適当アクションRPGでも作ってろとか吉里吉里はいいぞとかでも別にいから何か知ってたら教えてくれ。

HSPみたいな入りやすいけど途中で限界を感じるような言語でも別にいいや。

30時間限界が見えたとか調子こいてんじゃねえぞって言いたいのは分かる。

すまんかった。

最近HSPでちゃんとしたフリーゲーム出てきて俺が間違ってたと思い知ったよ。

入りやすさこそが正義っすね。


こう言っておいて自分そもそも何を作りたいのかよく分からんのだけどね。

不思議の城のヘレンや魔壊屋姉妹みたいなオリジナル戦闘システムRPGかいいなーと思う反面バランス調整でゲロ吐けるなと思ったり。

まあ目標高めすぎてるからまずはピンポンレベルからやり直して、自分がやった行動に対してレスポンスが帰ってくるのを楽しもうかなと。

お前がやりたいのはモノ作りごっこなんだからマイクラカルネージハートでもやっていた方が幸せになれるぞって返答もウェルカムですよ。

ヤフー知恵遅れでやれと言いたくなる人もいるだろうけど、マルチポストはしない主義なのでこっちに絞るわ。

あっちは何かニワカが多いんだよね。

追記:

unityが人気だな。

でもガチガチプログラミングを久しぶりにやったらゲーム作る前に挫折しそうだ。

それこそキャラ絵取り込んで歩かせたら満足しそう。

とりあえずは前から気になってたScratch感覚取り戻す事にするか。

だいたい方針決まったありがとな。

2017-10-25

anond:20171025161328

イギリス新聞。2017/3/10記事

http://www.express.co.uk/news/uk/777147/Women-still-responsible-for-household-chores

Google翻訳

Research shows women are still responsible for the majority of domestic chores and keeping households running smoothly.

In fact, when it comes to basic tasks like washing and cleaning men are nowhere to be seen.

調査によると、家事の大半は女性が依然として責任を負っており、

実際、洗濯や清掃のような基本的作業については、男性はどこにも見えません。

Men might take out the rubbish or put up a shelf but are shirkers when it comes to washing up or ironing, a new survey reveals.

男性ゴミを取り除いたり、棚を上げたりするかもしれないが、洗濯アイロンをかけるときはシャッカーだという新しい調査が明らかになった。

A paltry 10 per cent of men are capable of sewing a button on to an item of clothing, eight per cent will fold and put clothes away while just six per cent will empty laundry baskets and put the washing on.

男性10%は、衣服ボタンを縫うことができ、8%が衣服を脇に置き、6%が洗濯バスケットを空にして洗濯物を置く。

2017-10-19

BASIC!のプログラミング教育適応性について

題:BASIC!のプログラミング教育適応性について

副題:Androidで動くBASIC!でプログラミング教育を行うメリットデメリット

少し考えてみたのでまとめとして投稿します。

01.はじめに

この文章は、Androidで動くBASIC!でプログラミング教育を行うメリットデメリット

ついて記載しています

02.BASICとは

BASICプログラム初心者向け言語として1960年代に発表された古い言語です。

極めて簡単文法インタープリターによる即時実行や1970~80年代パソコン

無償で搭載されていたこから沢山の人に利用されていました。

しかし、簡単ゆえの機能の少なさと即時実行方式のための性能の低さやその後の

優れたプログラム言語発表によりBASICの利用は著しく低下しています

03.BASIC!とは

BASIC!はアンドロイドタブレットスマートフォン上で動くアプリです。

Google playからインストール可能無料で利用できます

BASIC!

https://play.google.com/store/apps/details?id=com.rfo.basic&hl=ja

BASIC文法踏襲していますが、Android向けに大幅に命令拡張されており、

GPS等の各種センサー情報取得やSQLiteデータベース機能WEBVIEWを利用

したHTMLCSSJS表示・実行など約500程度の命令群で構成されています

無料広告なしのアプリインストールするだけでこれらの機能が利用可能

インタープリターなのですぐに実行することもできます

04.BASIC!でプログラミング教育を行うメリット

メリットについては以下があげられます

a.BASICプログラミング知識を持つ人は以外と多い

 過去の栄光というかBASIC自体は広く利用された時期が過去存在パソコン

 だけでなくポケコンゲーム機等でも利用できました。

 BASIC!は基本はBASIC拡張であり文法変数の取り扱いにおおきな違いは

 ありません。

 その当時、少しであってもBASICを触った人は多いのでメンターとしての

 再教育は容易だと考えます

b.HTML,JS,CSS勉強継続してできる

 BASIC!は手続き型と呼ばれる非オブジェクト指向言語であり最新の言語

 とは異なっています

 BASIC!のネイティブ命令群だけだと他の言語へのスムーズな移行は難しい

 かもしれません。

 しかし、BASIC!にはHTML5アプリのようにBASIC!自体webViewでHTML,JS,CSS

 を動かすことができます。(HTMLモード

 HTML,JS,CSS現在Webの標準であり、進化を続けています

 特にjavascriptオブジェクト指向言語進化採用される領域フロント

 エンドからバックエンドまで広がっています

 

 BASIC!自体webViewは他のAndroidアプリ同様、chromiumベースAndroid

 システムWebviewの更新により常に最新化されています

 HTMLモードではjQuery,Angular,ReactなどのJSライブラリも利用できます

 最初BASIC!ネイティブプログラムHTMLモードJSを利用したプログラム

 とSTEPを踏んだ学習可能だと思います

c.インストール環境設定が容易

 前述の通りアプリインストールするだけで利用できます

 追加の課金プラグインなどは不要です。

 またAndroid2.3以降でインストール可能です。

 但しAndroid5.0あたりからAndroidシステムWebviewが導入されているので

 Android5.0以降の端末を選択する方が無難です。

 インストール後、環境設定をする必要もありません。

 端末のルート化も不要です。

d.Androidデバイス等が安価

 安いタブレットであれば1万円程度で新品が買えます中古スマホであれば

 更に安価です。

 またプログラムを作るのでキーボードもあった方がいいと思います

 キーボードも2~3千円程度で安価です。

 もちろんソフトウェアキーボードフリック入力など)でもプログラム

 作れます

 パソコンよりもはるか安価プログラミング教育が実現可能です。

e.子供Androidデバイスに慣れている

 iPhoneの登場以来現在の子供たちはタッチパネルAndroidデバイス

 慣れています

 通常のノートパソコンに比べ違和感は少ないと思います

 また教える大人側も日頃パソコンよりスマホを触る人は多いと思います

 教える側の負担も小さいのではないかと考えています

f.可搬性が高い

 ここで述べる可搬性とは別のデバイスで同じプログラムを動かす場合

 容易さの事です。

 BASIC!はインタープリタなのでソースファイルのみを別のデバイス

 SDカード経由等でコピーすれば基本的には動作します。

 仮にHTMLモード場合は併せてHTML,JS,CSSコピーするだけです。

 別のデバイスにはBASIC!さえインストールされていれば動きます

 BASIC!独自プラグイン拡張モジュールなどは特にありません。

05.BASIC!でプログラミング教育を行うデメリット

メリットだけでなくデメリットもあります。以下の通りです。 

a.性能上の問題

 BASIC!の実体Javaで出来ています。すなわちJavaよりは性能は悪い

 ことになります

 実際、大量の繰り返しや大量の文字列を扱うプログラムは性能が出ないので

 処理に時間がかかります

 Androidスマホタブレット自体パソコン演算能力には劣ります

 大量の実験データ演算するような教育には向いていません。

 但し、プログラミング教育には大きな障害にならないと思います

b.BASIC!自体の仕組みの問題

 BASIC!はプログラムを作るアプリである以上当然文法エラーを実行時に

 表示する仕組みになっています

 ただ一部エラーチェックが甘い部分もあり本来エラーとすべきところを

 そのまま実行する場合もあり想定外の結果となる可能性もあります

 次にエディタは単なるテキストエディタと同等の機能しかなく最近

 エディタにあるようなシンタクスハイライト入力補完といった機能

 ありません。

 ただ比較シンプルプログラムを作る教育では大きな影響は無いと

 考えています

c.一部機能に制約がある

 前述の通りHTMLモードではJSが動かせます。ただし制約があります

 JSローカルモードで実行されるという事です。

 非同期通信などを行おうする場合JSが実行時エラーになる可能性が

 あります

 またデータベース機能であるSQLiteへの操作についても文字型項目しか

 利用できない制約があります

 JSローカルモードのみなのは教育の事を考えると少し残念ですが

 それでも多くのフロントエンドJSは実行可能なので教育には

 使えるという理解でいます

d.参考となる文献がほぼない

 教育には教科書またはそれに準ずる書籍必要だと思います

 該当する書籍がないのが実情です。

 ただ1冊だけ日本語で書かれた電子書籍存在します。

 ■BASIC! ~ 分かりやすい教本で一から学べるコンピュータ言語 - AndroidSQUARE

 http://blog.livedoor.jp/an_square/archives/51887786.html

 BASIC!の文法自体は極めて簡単なのでどうにかなると思います

06.結論

上記の通り、メリット/デメリットを列挙してきました。

デメリットもあるものメリットの方が大きい印象です。

とくに教える側の負担が少ない点がメリットだと思います。 

 

2017-10-12

意識高い系や古強者ぶったIT技術者が多い増田を見てて一番の疑問は

今、俺みたいな20代とか、あとはせいぜい30代とかが勘違いしてweb系の安月給で恰好だけ付けて糞みたいなコード書いてイキってるとかその一昔前は横浜組み込み技術者携帯電話開発の殺人レベル拷問労働で安月給のまま殺されまくったり廃人にされまくったり見たいなイメージしか知らないから、知らないのは仕方がないにしてもさ

マイコンBASICだのベーマガ世代の思い出を情感たっぷりに語れるくらいのオッサンで、80年代末期から90年代後半にはもうIT技術者として働いてた奴等は

何で「当時の勤務体系や仕事内容、そして給料いくらから」を誰も言わないんだ?90年代後半までプログラマーSEといえば超スーパーウルトラ実入りがいい職業だったし、残業なんて言うほど大してなかったうえに、20代でマンションローンで買って30代で返済できるくらい稼げてた職業だったろ?

何でそこらへんの時代のことを言う奴が、せいぜい2ちゃんビジネスnewsPG関連のスレくらいしかいないの?

そういうブログHPを立ち上げて情報発信したら、政府のI〇Aとか人売り派〇会社に雇われた小林源文漫画オメガセブン小隊みたいな自衛隊員とか警察特殊部隊構成された殺し屋チームでも送り込まれて口封じされるから言えないとか?

それが不思議で仕方がないんだよな

あ、なんで俺がそんなこと知ってるかって俺の親父がその時代SEだったからだよ

2017-07-15

自分なりのささやか復讐

おじさん、独り部署20年近く少しだけ特殊仕事してんのね。

若い頃は他部門の先輩に無茶で本来自分範疇外の仕事押し付けられて、

顎で使われて、そりゃ偉そうにされたもんだよ。

その人達は僕の都合や段取りなんかに聞く耳を持ってくれないんだよね。

おめーの都合なんか知らねーからとっととやれよ!もう夜の10時なんだけど。みたいな感じで。

そんなこんなで、無茶を聞いて頭を使って仕事効率化をはかって必死こいて頑張った結果、

偉そうにしていた先輩達よりも立場上は偉くなれたのね。

そこに到るまでの間に精神を病んだり体を壊したりもしたけど。

でだよ、こうなるとある程度は無茶な仕事拒否できる訳だ。

今まで聞かされてきた要求脳筋ならではの、「細かい事はどうでもいいから、俺の意を汲んで気合でやれ!」といった

内容だったから言うことを聞く必要は無いんだよね。そもそもその人達の部下じゃないし。

他人物事を頼むとき相手がどういった立場であれ、発注元は細かい情報を正確に伝える責任が生じる訳で、

その責任放棄して丸投げしてくるような人間の言うことなんて、こっちは知ったこっちゃないのよ。

すると不満が湧いてくるんだけど、それは僕に直接言ってくる訳じゃなくて、

もっと偉いひとから間接的に聞こえてくるのね。こんな風にあいつら不満を言ってるぞと。

かい不満の内容を聞くと、立場が変わってから偉そうになっただの、

僕だけ使っているソフトで楽をしているだの、ソフトがあれば俺でもできるのにだの。

いや、君らエクセルすらまともに使えないじゃない。

からね、おじさん、働き方改革を実行すべく、小学生の頃にN88-BASICしかやったことないのに、

仕事の合間にコツコツとプログラムWEB勉強をして社内にローカルサーバーを立ててシステムを組んだの。

WEBベースでアホでも理解できるUI、誰でも簡単保守管理できるやつ。

おじさん、普段からエクセル方眼紙を社内・社外から送りつけられてて、

エクセルのことが死ぬ程嫌いだからPHPで作った。

これがすごく便利で、自分が今まで投げられてきた仕事が誰でもワンアクション

終わらせるようになったんだ。当然システムの出力に応じたパソコン外での

作業は生じてくる訳だけど、それは誰でもできることだから、テメーら自分でやってね。

凄く便利になってよかったね。ざまあみやがれ。

これで時間に余裕ができたので、本来担当案件に集中して取り組むことができるし、

自分の退勤時間はほぼ定時になったし、有給もどんどん使ってやろうかと思うよ。

おじさん、娘が高校生になって手がかからなくなったから、

子育て期間に封印してた大好きなゲームを気の済むまで遊びたいんだ。

とりあえずSplatoon2ゼルダはやるし、ゲーミングPCをGTX1080で組んだから

STEAMで色々と買い漁るよ。

2017-06-20

BASICって、今でも初心者向け言語として優れてるのかな?

これ、すげー懐かしい、N88とかMSXのような雰囲気

http://gigazine.net/news/20170620-nintendo-switch-fuze-code-studio/

しかし、このご時世にBASIC

行番号とLOCATE, PRINT, CLSとかでゲームつくんの?

しんどくね?

それとも、プログラミングを知らない人には、こういうののほうが今でも分かり易いのかな?

2017-06-07

anond:20170513175715

残酷だが「職業訓練プログラミング」という人たちはこの業界はあきらめた方があなたのためにとって良い。

そのような人の上司になったことが何度もあるが成功した人を見たことがない。

はいものの、私も35歳から異業種転職にてアプリ屋になったが、転職直前の段階でC/C++/Pascal(Delphi)/html/js/SQL が書けた。

10代前半から8bitCPU(特に名を伏せる)のマシン語(ハンドアセンブル、つまり16進数直書き)でプログラムした経験がある。(もちろんBASICもある)

8bit時代ならメモリー増設設計実装(ハードウエア)ができた。

一応そのような状況ではあってもプロに知り合いもなく心配だったので、

(当時)第二種情報処理技術者試験に3週間の勉強(1.0/日程度)で

一発合格しなければ転職しないというような目標もたててクリアした。

技術的には 0 スタートではかったからこそ転職にも成功できたと思っている。

おっさん技術知識経験ほぼ 0 スタートはきついでしょ。

おっさんなんだからこそ無駄時間を使わないでほしい。

自分も一流でもなんでもないくせに上から目線で自慢話みたいのしてごめんなさい。

あなたに向いた仕事はきっと他にある。がんばれおっさん

2017-06-04

秘密URLパスワード違い

一般公開ってなんだろう

パスワードはわからないと中身が見えない秘密文字

URLもわからないと中身が見えない文字

自分サーバ誰も知らないURLファイル置いておいたらそれはパスワードかけてるのと一緒じゃないの?と思った

法律的なことは知らないか感覚的な話しだけど

映画音楽とか外出先でみるために自分サーバにおいておくときパスワードかかってるとOKで掛かってないと違法アップロードになる気がする

でも URL 自体一種パスワードじゃないの?

パスワード暗号化されてるイメージがあってURLはそのまま送られてる印象がある

からURL簡単にバレてパスワードといえないのかもしれない

でも単純な basic 認証だとパスワードユーザ名は簡単に複合できる形式になってる

セキュリティ的に弱いといいつつも一つの認証として企業でもわりと使われてたりするからパスワードかけてました、で通るんだろう

あとは秘密のものという認識があるかどうか

例えば Skype で送ったURLマイクロソフトからアクセスがあるという話が昔話題になってたとおもう

Chrome だと Google からもあるんだっけ?

私も話題になった頃試してみて実際にアクセスがあったので嘘のニュースではない

こんな感じで URL秘密のものって認識がないか普通に保存されてアクセスされたりする

でもこれはそういった情報収集されるツールを使うからであって、使わなければ自分しかからないはず

URLパスワードと考えるなら、自分からパスワードばらまいてるようなものになる

そういうことをしなかったら自分しか知らないURL一般公開してないものって思えるけど、法律的なことで一般公開してるかどうかになったらどうなるんだろう

2017-06-02

Webプログラミング言語進歩が後退した

Webプログラミング流行る前は、basicでさえ型宣言するのがいいという流れになっていたのに、WebプログラミングPerl流行って、その流れてPHPRubyなどの動的型の言語流行って大きく後退。

動的型の言語洗脳されたプログラマ大量発生

現在は、Python, PHPも型チェックを導入。

Rubyも将来型チェックを取り入れると表明。

Javascriptも、TypescriptFlowが登場。

やっと停滞した20年を取り戻しつつある。

歴史にifはないけど、あのとき流行ったのがPerlでなかったら、世界は違っていた。

2017-05-13

無職だけどプログラミング覚えたい

ハロワ行くと職業訓練プログラミングもあるんだけど

どの言語就職につながりやすいだろうか

おすすめを教えてほしい

こないだ見てたらJavaとかCとかPHPとかあった

こちらのスキルとしては

プログラミングに関しては子供の頃ベーマガ見ながらBASICやったくらいの記憶しかない

すなわちおっさん

あとプログラミング言語じゃないけどHTMLCSS自分ホームページつくったりするくらいにはできる

2017-04-15

http://anond.hatelabo.jp/20170415115330

結論から言うと型を欲するのは成長できた言語のみに許された特権である

どんな言語最初から厳密な型チェックをアピールしてしまうと開発を阻害するばかりで流行らない。

増田理屈だと最初から全部C++Javaで作ればいいじゃんとなるが、

現状を見るにそうはなってない。

web黎明期フロントエンドを支えたのは紛れもなく型チェックのゆるい言語だ。

パソコン黎明期一般向け主力言語BASIC(あるいはアセンブラ)だったわけだが、

時代が進むにつれて型チェックの厳しい言語を求めるようになるのは理由がある。

それはプログラムの規模だ。

言語が出た当初はライブラリも少なく、できることも少なかった。

時間が経過してライブラリノウハウが蓄積し、マシン性能向上も相まってできることが増えてくると

プログラムの規模も増えてくる。

すると、厳密な型チェックを取り入れないと全体を統制できなくなるのだ。

故に厳密な型チェックを取り入れるというのは、その言語(及び開発者)の成長と発展の証と言える。

2017-03-06

ハングルプログラミング言語"Aheul"というのを見かけたが

Hacker Newsの上の方にAheui(아희) https://aheui.github.io/specification.en というのが上がってきていて(ろくにコメントがついてないが)、どうも世界初ハングルを使ったプログラミング言語であるらしい。

どんな言語なのかとググってみたらが日本語情報はなく、2014年2015年に同プロジェクトのページをはてブしている人がいた程度だった。

This code printsHello, world!”

밤밣따빠밣밟따뿌

빠맣파빨받밤뚜뭏

돋밬탕빠맣붏두붇

볻뫃박발뚷투뭏붖

뫃도뫃희멓뭏뭏붘

뫃봌토범더벌뿌뚜

뽑뽀멓멓더벓뻐뚠

뽀덩벐멓뻐덕더벅

これがその言語で書いたHello,World!なのだそうだが、短縮しまくったPerlより読める気がしない。本気で使おうとは思っていないのかもしれない。

ハングル文字の中に方向を示すキャラクタがたくさんあり、カーソルを動かすイメージがつかみやすいという売りはあるようだ。

Wikipedia: Non-English-based programming languages

https://en.wikipedia.org/wiki/Non-English-based_programming_languages

これ見ると英語以外で記述できるプログラミング言語は多い。中国BASICPythonC++中国語化したものかあるらしい。C++中国語版は丙正正。名称がそのまんまといえばそのまんま。BASICを見ると一つ一つのコマンド漢字1文字が割り振られているだけのような感じだ。インドヒンディー語もそんな感じ。その程度のレベルならプログラミング言語母国語に置き換えるメリットはないか

日本にもひまわりやMindなど日本語単語を使えるプログラミング言語があるけど、あれらをマスターしてる人は見かけないな。

2017-02-14

http://anond.hatelabo.jp/20170214062759

何の問題もない。

俺は BASIC 言語の Left$、Right$ の機能を使えるようになってから

左が left 右が right を覚えた。35年もこの状態

2017-01-18

プログラミングって「得体がしれない」よな

プログラミングって、これから始めてみようっていうとき、なんだか「得体のしれない行為」っていう感覚がありませんか?

ぼく自身は、プログラムを書いてる側の人間で、いまでこそ少しはプログラミング本質的な難しさをわかってる気になってます。でもつい数年前までは、プログラミングは難しくはないけど得体がわからない、という感じでした。

そのへんのコードを組み合わせて動くものはできるけど、何がどうなっているのかは知らんし、ググって分からないものはできない、という方向で、「プログラミングは難しい」と思ってました。

最近になって、プログラミング義務教育必修化の話題とか、コピペプログラマー話題とかを目にするたびに、かつて自分プログラミングに対して抱いていた「得体のしれない行為」という感覚が思い出されてしまい、少しざわざわした気持ちになったので、ちょっとここに書きなぐらせてください。

だいたいが個人的な話なので、そういうのがうっとうしい人は無視してください。

ぼくが世の中にパソコンという道具があることを知ったのは、たぶん中学生ときです。30年くらい前。当時、電気屋の売り場ではけっこうな床面積を使ってワープロ文章入力する専用マシン)が陳列されてました。文章を書くのは好きだったけど、字を書くのが死ぬほどめんどくさかった自分は、ワープロさえあれば自分小説とか書くのになあと思いながら指をくわえて電気屋の店内をうろうろしてました。しかし、ファミコンすら買ってもらえなかった家計ではワープロなんぞ買ってもらえるわけもありません。そのうち巡回してた電気からワープロが消え、それに代わってパソコンのコーナーが広がっていきました。このパソコンというのは、よくわからないけどワープロとして使えるっぽいし、どうやらファミコンを持っていない僕にもゲームができるらしい、おれに必要なのはこれだ、というわけで、中学生だった自分パソコンという存在に興味を抱くようになったのでした。

はいえ、だからといってパソコンを買ってもらえるような家計ではなかったわけなので、カタログを熱心に眺めるだけの毎日が続きました。その当時の自分にとって、パソコンが欲しいといったら、それはNECを買うかエプソンを買うかという選択でした。冨士通からパソコンが出ていることは知りませんでした。マッキントッシュっていうやつもあって、このPerformaっていうやつはなぜか安いとか、よくわからないけどシャープとかソニー独自パソコンを作っているぞとか、そういう情報パソコンに対する認識のすべてでした。当時の自分にとってのパソコンは、電気メーカーから発売されている商品一種であり、ラジカセとかテレビと同列の存在でした。

なんでこんな話がプログラミングにつながるかというと、ひょっとして自分プログラミングにずっと感じていた「得体のしれなさ」の源泉の一つは、こんなふうにパソコン電化製品として見ていた当時の感覚の延長だったのかもなあと思ってるからです。

ラジカセなら、CDだのテープだのを入れて再生タンを押せば、そのハードウェア機能物理的に体感できます。それに対してパソコンは、プログラミングちょっとやってみても、その行為と、そのハードウェアとが、感覚的に結びつきません。もちろん、プログラミングというのは、物理的なデバイスに結びつけて考えなければできない行為ではありません。しかし、パソコンを「カタログ商品」として見るところから入ってるばかりに、そこでやるプログラミングという行為ハードウェアとの結びつきが見えにくい状態に、なんとなく居心地の悪さを感じていたように思うのです。

もし自分スタート地点が、パソコンを使って文筆やゲームをするところだったら、パソコンは文筆やゲームのための箱だったでしょう。その後でプログラミングを始めていたなら、プログラミングという行為を、文筆やゲームに関連した創造的な活動として学べたかもしれません。

ところが実際には、自分はつい数年前まで、パソコンという電化製品に対する漠然とした行為としてプログラミングを捉えてた気がします。

プログラミングを始めたのは、高校生になって誰も使わないFM77が部室に置いてあったので立ち上げてみたらF-BASICインタプリタが起動したからでした。とくに何をプログラミングすればいいかもわからなかったので、教科書雑誌コードを転記したり、ループで線画を書いたりして遊んでいました。大学に入ってからも、授業でFORTRANとかLispをやらされたけど、基本的自分目的をもってプログラミングするのは数値計算くらいのものでした。そのころになると、本で情報を探して(まだインターネット検索は使い物にならなかった)適当コードをつなぎ合わせるのがプログラミングだと思ってました。そんなん面白くないなあ、とも思ってました。

この感覚、完全に、いま揶揄されているコピペプログラマーのそれだったと思いますちょっと話はそれますが、ブロック遊びとか砂場遊びって、ほとんどの人はわりとコピペプログラミングと似たような感覚でやってるんじゃないでしょうか。パーツを勘で組み合わせたり、とにかく砂を盛っていったりすれば、家みたいなのができるよね、という感覚プログラミングは、自分にとってそれに近い作業でした。学生のころは、内心、自分にもパソコンサンプルコードさえあれば何かすごいものを作れるかもなあ、くらいに思っていたふしもあります

自分バカでした。パソコンがあるとかないとか、関係ないのです。パソコンさえあれば、なんて思う者に、本当のプログラミングがわかるはずがありません。

そんなこんなで、自分はまともにプログラミング経験しないまま社会人になったわけですが、幸いにもプログラミングに対するこの感覚は、仕事パソコンを日々使うようになってから徐々に変わっていきました。

具体的には、パソコンが、自分の中で「カタログ商品から武器」へと変わりました。それと同時に、プログラミングという行為が、武器開発という位置づけになりました。

武器というのは言い過ぎだとしても、ちょっとしたプログラミングは確かに業務上課題を打開しました。それなりに計算機科学教科書を読んで勉強をしたこともあって、いつのまにかプログラミングに対する「得体のしれなさ」も解消してました。

結局のところ、自分にとっては、プログラミングという行為の「得体のしれなさ」から解放されるまでにずいぶん長い時間必要だったことになります自分がそうだったからといって他人もそうだとは限らないですが、たとえば小学校で形だけプログラミングを教わっても、分かるとかわからないとか、好きとか嫌いとか以前に、なんかモヤモヤした気持ちになるだけの子もも少なくないんだろうなあ。それは不憫だなあ。

かといって、自分がいまプログラミングで少しは戦えてるのは、そのむかしパソコンに憧れがあって、得体がしれないなりにプログラミングをする機会が若いときたまたまあったからでもあるので、そういう機会になるなら小学校で形だけでも教えるほうがいいのかなあとも思います

オチがないので、このへんで。

2016-12-15

Paizaで募集してる技術者の想定年収

恐らく小学生時代でも出来ていたと思われる(小学校時代BASICだったけどなー)Cランク問題、Bランク問題適当に回答してたら、あっという間に想定年収700万台後半に。

いやさ。そもそもプログラマに700万以上出すって無いでしょ。あるの?そんな会社。無いでしょ。

そもそもあん簡単問題業務じゃ「出来て当たり前」レベルで、アレが出来ない人間職場にいるとしたらゾッとする。

2016-11-20

WiMax IP電話 grandstream

VoIPアダプタ「Grandstream Handy Tone-701」のIPアドレス確認

管理画面にアクセスIPアドレス確認

受話器、「***」で発信し、「02」をプッシュ。

DHCPで割り当てられたIPアドレスが読み上げられる。

VoIPアダプタ「Grandstream Handy Tone-701」のファームウェアアップデート

アップデートなしでは、うまく動作しませんでした。

事前にファームウェア(1.0.7.3:2015/02/14時点の最新版)をGrandstream Networks社のホームページから

ダウンロード

確認したIPアドレス管理画面にブラウザアクセスし、管理者用の初期パスワードadmin)でログインし、

ファームウェアアップデート

管理画面に管理者用の初期パスワードadmin)でログインし、以下の設定の確認と変更を行います

<「BASIC SETTINGS」の設定>

# Time Zone

GMT+9:00 (Japan,Korea, Yakutsk)

# IP Address

statically configure as : IP Address / Subnet Mask / DNS Server

DHCPIPアドレスが変わるのが気になったので固定のIPアドレスを設定します。

DNS Serverは、WiMAXルータIPアドレスを設定します。

<「ADVANCED SETTINGS」の設定>

# NTP Server

ntp.jst.mfeed.ad.jp

<「FXS PORT」の設定>

# Account Active

Yes

# Primary SIP Server

smart.0038.net

# NAT Traversal

Keep-Alive

# SIP User ID

通知のあったユーザIDを設定します。

# Authenticate Password

パスワードを設定します。

# Preferred DTMF method

RFC2833

SIP INFO

In-audio

デフォルトから変更しないで使用しました。

# Preferred Vocoder

choice 1 : PCMU

choice 2 : PCMA

choice 3-6 : PCMU

※iLBCが入っていると、音声がおかしくなる・・・

# SLIC Setting

JAPAN CO

VoIPアダプタ「Grandstream Handy Tone-701」の設定確認

・4個のLEDランプがすべて点灯していること。

管理画面(STATUS画面)でHook : On Hook / Registration : Registered / DND : No

VoIPアダプタ「Grandstream Handy Tone-701」の設定作業時の注意点

設定変更は、「Update」ボタンを押したのち「Apply」ボタンを押しますが、着信ができなくなったりしたことがあったため、テスト前には「Rebootボタンを押して再起動することをお勧めします。

2016-08-11

ぼうび6

PDFsam Basicの分割機能で、実行ボタンを押した後に偶発的なエラーが出る事がある。

この場合対象ファイルディレクトリを別の所に変えると上手く行く。

2016-07-25

gitにおけるコミットログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくま単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのであるググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログから転載である。当然ながら各コミットログ著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユース範囲なら許してくれるだろうと考え名前プロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリGitHubSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した(あわせて前処理として、コミットログ冒頭のタグ情報は消去した)。

結果として対象としたリポジトリは以下の通り。

atomのみ5400件抽出していたため、計25400件のコミットログベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションフラグメニューを追加した
ファイルを追加した
メソッド機能を追加した
実装を別のものへ切り替えた
  • Use args.resourcePath instead of args.devResourcePath
  • Use arrays instead of while loops
  • Use auto instead of repeating explicit class names
  • Use weak pointer instead of manual bookkeeping
  • Change all uses of 'CInt' to 'Int32' in the SDK overlay
  • Change Integer#year to return a Fixnum instead of a Float to improve consistency
新しく何かに対応した/機能上の制約を取り払った
何かを使うようにした
より好ましい実装に改良した
何かを出来ない/しないようにした
  • Don't bail reading a metadata instance if swift_isaMask isn't available
  • Don't exit until the parent asks for an instance
  • Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
  • Don't use MatchesExtension for matching filters
  • Don't use ES6 class for AutoUpdater windows class
  • Don't use MatchesExtension for matching filters
  • Avoid `distinct` if a subquery has already materialized
  • Avoid infinite recursion when bad values are passed to tz aware fields
オブジェクトの内容や挙動確認やすくした
Assertを追加した
不要コードを除去した
コードを移動した
名前修正した
さなバグタイポ修正した, 警告を潰した
バグや好ましくない挙動修正した
テストコメントドキュメントを追加した
テストを削除した
テストコメント修正した
ドキュメント修正した

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

Add1149
Fix1014
Update584
Remove566
Use382
Don't260
Make228
Move178
Change103
Rename85
Improve76
Avoid68
Allow65
Implement60
Handle58

コミットログの基本形はもちろん動詞 + 名詞である名詞固有名詞複数形、不可算名詞が多いが、単数形場合冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテストドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typocrash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合Make sure が使われる(こちらはthat節が取れる)。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う(Ensure はさらに重い表現っぽい)。

また、Fixtypo 以外でのドキュメント修正に対して使われることは稀である。対して 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以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

2016-05-21

http://anond.hatelabo.jp/20160521172848

Haskell.org https://wiki.haskell.org/Functional_Reactive_Programming を見ても

The basic idea is that a time-varying value can be represented as a function of time:

newtype Behavior a =
    Behavior {
      at :: Time -> a
    }

もろに「関数」で書かれていて、岡部自称FRPのような「代入」は影も形も無いな。

2016-05-07

小学校プログラミング必修化について思うこと

僕は小学4年男児もつプログラマ

僕の場合ワープロからはじまり、物置に眠っていたBASIC機をいじり倒し、叔父から譲り受けたDOS機をいじり倒し、小学高学年の頃にはプログラマになることを決めていた。

そんな僕も今や一児の父だ。定時で帰れる日は息子に勉強を教えている。彼の理解力や興味に合わせた手書きドリルを作って、学校の授業ではわからなかったところをサポートしている。今では満点をもらえることも増えてきた。同僚に技術指導をする機会が多いが、当然ながら息子に教えるほうがはるか簡単だ。

そんな僕が思うこと。

プログラミングを必修化したところで成果は得られない。

プログラミングに入門させるくらいならエクセル教室でもやったほうがいいだろう。どんな業界でも表計算必須と言えるし、興味があれば思うままに使って遊んで覚えてくれる。子供に教えられる家族も、それなりにいる(期待はできないが)。

ちなみに、表計算は、プログラミングエッセンス必要とする。変数、条件分岐、繰り返し、関数、これらはどのようなプログラミング言語の基礎となる概念だ。

さておき、プログラミングを教えるとして、どんな言語だろうが、"Hello World" がはじめの一歩だろう。その次は変数変数を教えるのは難しい。「箱に入れる」という比喩理解できる子とできない子に分かれるだろう。四則演算と同様に、ここでつまづくと先はない。それからも、条件分岐、繰り返し、配列関数、ここまで来れるのだろうか。

プログラミング言語は覚えたとしても、論理の組み立てができなければ、モノはつくれない。言語を覚えることと論理を組み立てることは、必要とする能力が違う。単語を覚えたところで、ネイティブと話すことはできない。人間ならば、単語だけでも曖昧さを補完して理解してくれるが、プログラミング言語は書いた通りにしか動かない。おそらくプログラミングに苦手意識を持つ子供が増えるだけだろう。

プログラミングより先に、外国語教育を充実させたほうがいい。

そして、基礎的なIT教育をするのなら、表計算のほうがいい。

2016-04-26

anond:20160426145507 の続き

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

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

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

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

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

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

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

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

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

他の選択肢

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

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

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

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

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

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

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

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

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

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

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

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

2016 年 4月 Insane Coder

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

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

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

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

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

OAuth とは

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

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

おことわり

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

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

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

記事の構成

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

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

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

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

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

責任ある情報公開

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

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

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

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

想定する利用形態

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

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

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

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

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

問題点

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

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

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

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

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

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

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

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

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

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

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

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

さらに

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

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

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

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

OAuth サービスに偽装

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

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

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

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

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

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

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

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

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

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

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

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

前掲のセキュリティ文書は、 このエントリーをはてなブックマークに追加ツイートシェア

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん