素人がプログラミングを勉強していたブログスマートフォン用の表示で見るスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。Mt.Fujiが成立するから名詞の同格になり名詞節でthatはただの接続詞。born.なので同格ではなく形容詞節か。dreamでSVCが成り立つってことか。dreamの関係は=。houseは=で結べない。私は起きるためにコーヒーを飲む私は起きるためのコーヒーを飲む私はコーヒーを飲む起きるためにjavascripterbecauseとかと同じで補足情報だから。issuesって形容詞句と副詞句で分かれるんじゃね。orderも形容詞句の意味を持つから明確な訳がない。明確にするとしたら節で繋ぐのがいいのかね。〜薬を飲むべきだった(飲まなかったので後悔している)風邪を治すための薬を飲むべきだった(薬は飲んだけれども違う薬を飲んで後悔していると考えられる)ってなんのかなjavascripterこれは曖昧性があるな、どちらともとれるな。役に立つかもしれないのでログを載せておく。fall.って同じ?javascripter同じ。20:08英文法の話、時勢と動詞のニュアンスについてなどlistTweet広告を非表示にするもっと読むコメントを書く2015-08-13一つのファイルでサーバーとHTMLファイルとコードを共有するやつちょっと説明がし難いがindex.htmlというファイルがあったとして、ファイルプロトコル経由でfile://path/index.htmlなどのように直接ブラウザで起動すると、プロトコルの関係でファイルが読み込めなかったり、エラーになったりすることがよくある。サーバーをたててlocalhostなどから読み込めばいいのだが、微妙にセットアップが面倒臭い。index.htmlとするだけでブラウザが立ち上がり、index.html自身をルートとしてそのディレクトリ以下のファイルを配信する簡易サーバーが立ち上がる。具体的には、http://localhost:port/index.htmlのような形でアクセスできるようになる。index.htmlは新規にサーバーを立ち上げずに、既存のlocalhost:port/index.htmlをブラウザで開く。特殊な魔法を使っているので、HTMLとしてもJSとしてもvalidで、ブラウザでもnodeでもコードの一部を共有している。18:51一つのファイルでサーバーとHTMLファイルとコードを共有するやつlistTweetもっと読むコメントを書く2015-06-03DBにおけるウェブシステムのアカウントの権限管理とセキュリティについてユーザーと管理者アカウントがあるウェブサイトで、管理者がユーザーのパスワードをリセットできたりといった風に、アカウントによって権限が違う場合のセキュリティについての考察である。emailとパスワードでuser/adminにアクセスできるとする。1);と書きたくなる(簡略のため生パスワードを使っているが、もちろん真似してはいけない)。これは、セキュリティの観点からは好ましくない。password=$password;になると思う。password=$password;が実行され、管理者権限のアカウントが乗っ取られてしまう。Injectionがあるとする。id=$idが実行されてしまい、ユーザーが管理者に昇格してしまう。Injectionがあったとしても特権昇格ができないようなDB設計が好ましい。具体的には、userとadminのテーブルを分けるのが好ましい。仕様上idとemailはuser/admin両方で一意であることを保証しなければならないので、完全に分けることは難しい。ここでは、id_tableを使った方法ともう一つの方法を考える(あまりSQLに詳しくないので、いい方法を知っている人がいたら教えてください)。userの順に試行する。上記ではidとemailのシステム内での一意性を保証するためにid_emailテーブルを定義したが、この方法もセキュリティ上よろしくない。id=$id;のようなコードを書くことになる。id=$id;となり、管理者権限のアカウントのemailを攻撃者のものに書き換えられる可能性がある。書き換えが成功した場合、パスワードリセット機能によって管理者権限を奪われてしまう。よって、id_emailを触るときには鬼のように気をつけるか、そもそもid_emailを使わないように定義するしかない。id_emailを使わない方法についてだが、emailをuser/admin内で定義したい場合、テーブルにまたがった制約は外部キーや複合キーなどではうまく表現できないので、トリガーを使う(いい方法を知ってる人がいたら教えてください)。システム内のidはaccountテーブルを使って一意性を保証しているが、アカウント作成時にidを取得する以外では使わないので特に問題はない。password=$password;で再試行する。Injectionができても管理者権限を奪うことはできない(ただし、テーブルのアクセス権限を正しく設定している場合)。パスワードの変更などについても同様である。このように、権限の異なるアカウントは特権昇格攻撃を未然に防ぐためテーブルごと完全に分けたほうがよい。言うと、そもそも1つのログイン画面で複数の権限のアカウントの管理をすること自体、実装が複雑になるのでセキュリティ上好ましくない。user_idなど関連性がないことが明らかになるように名前をつけadmin/user間のemailの重複は無視し、userとadminを完全に分けるのが、安全な設計だと思われる。Injectionは起きないので関係ないし、親クラスに相当するものがあるほうが自然だよ」という考え方もあるが、最近「権限の異なるアカウントのテーブルは必ず分けないといけない」と断言されたので、いい機会なので考えてみた次第である。断言口調で書いたものの、絶対そうでなければならないかと言われると、うーんという感じではある。おまけで一応書いておくが、生パスワードをDBに保存してはいけない。hash(hashed_password)}このようなニュアンスのものを使うべきである。ソルト」で検索してほしい。実はあまりSQLに詳しくないので、他にidとemailの一意性を保証する上手い方法があるような気がしてならないので、いい方法があったらコメントで教えてください。n)だとか、O(n2)だとか、そういった記号を目にすることはよくあると思う。n2の順に計算量が増加していくとかそういうことも知っていると思うが、計算量の増加とは何か説明しろと言われると、なかなか難しいと思う。この記事では高校数学レベルでわかるように考えていきたい。f(b)であるとき)。1に対して101を返すことに注意したい。言い換えると、関数の増加率の大きさと数字の大きさは違う。どのように比較すればいいかというと、nが十分に大きくなると、増加量が大きい関数(n)>増加量が小さい関数(n)になるという性質を利用する。∞)における大きさの違いを利用する。∞であることからわかるように、limによって導き出した∞は極限であって、大小の概念を含む一般の数値と違うことから、大小の比較には使えないということである。∞と∞の比較を避けることができれば、limを使っても、極値での大きさの比較はできる。h(n)というように、比較したい二つの関数を分数の形にして∞自体を直接比較しなくて済むように変換する。追記:コメント欄で指摘されたが、上記の定義だと、関数によっては振動して収束しない場合がある。limではなく、limsup/liminfを使って、上極限/下極限について考えると、これらも含めて定義できる。O(h(n))、など。O(g(n))と書いていたが、記号の使い方が不適切との指摘を受けたので訂正した。100)より大きいことがわかる。100)とO(n)が同一であることなどもわかる。いうライブラリを作ってみた。p3の順番に実行したい場合、reduceが使える。p3を並列に実行した上で、callbackの順序を保証したい場合。テスト用に、一定時間まってからvalueでresolveする関数resolveLaterを定義しておく。タスクそのものは並列に実行されるが、callbackは順番に実行される。p3自体を順番に実行したい場合、つまり、あるタイミングで同時に動いてるpromiseが1つである必要がある場合。Testingがおすすめで、jestを使うと、setTimeout系の関数自体を乗っ取って(実行順序を保証しながら)同期的に実行しながらsetTimeout.mock.callsに呼び出された時のmock関数の引数を記録していってくれるので、実際の非同期で不確実な動作に依存せずにテストしやすいコードを書ける。非同期のテストはどちらにしろ複雑になりがちで、ある程度のところで諦めてテストケースは書くがチェックは手動、という風にするのが現実的なのかもしれない。追記コメントでライブラリで解決していることを実現できていないと指摘されたので、その他の例について触れる。上記コードにはなかった、順番に実行したいpromiseがコード中で動的に追加される場合。0))).then(callback);このようにreduceを手動で展開することで動的に追加できるようになる。0)).then(callback);このようになる。Promiseの上にコントロールフローを実装するライブラリを使うより、このように直接promiseを組み合わせる手法を使ったほうがいいと思う理由は複数あって、まず、自由度の点。ここに載せたコードでは、全体の状態がPromiseとして表現されていて取り出すことができる(reduceを直接使った例では、reduceが返すPromiseがそれにあたる)ので、複数のパターンを組み合わせることができる。具体的には、最初のpromise数個をarrayとして入れておき、動的に実行したいものを後から追加したい場合。1000))).then(callback);このようにできる。reduce相当の処理をしていないコードのもう一つの問題は、エラー処理。動的にタスクを追加する例では全体のエラーという概念は薄いかもしれないが、例えば、記事中のコントロールフローライブラリでは、すべての実行が終わった状態というものをPromiseとして取り出せない。よって、全体のどこかでエラーがあった場合にそれらをcatchする関数、というものが書けない。});などを最後に追加することで、エラー処理が握りつぶされるわかりづらいエラーが防げる。17:28promiseを順番に実行するlistTweet広告を非表示にするもっと読むコメントを書く2015-02-23ES6のclassは巻き上げがされないちょっとハマったのでメモ。{}ができないのはなぜか。関数と違ってextendsはその場で評価しなければいけないことがある。Aで宣言されているものはhoistingされないのでclass宣言もその場で評価しないと、正常に継承することができない。=とおなじような順序で評価されるわけである。最近いろいろな環境でES6まわりの環境が整いはじめたので、使っていくために下調べしておこうと思う。tableにまとめが載っている。(nodeのfork)のES6実装状況。featuresが元から有効になってる。最新版をターゲットにするのであれば、上の機能は何も考えずにそのまま使うことができる。detectして実装されていない場合はmoduleを読み込むことで幅広いバージョンをサポートできる。node.jsは--harmonyを有効にしなければジェネレータが使えないなど、node.jsはio.jsとはES6まわりの実装事情が違う。nodeでネイティブに実装されていない機能を使いたい場合は、トランスパイラを使う。mapsのサポートもあり、React、JSX、Flowなども使用することができる。script.jsとするだけで使うことができるので、gulpなどでコンパイルするといい。