フレームワークに見る Web セキュリティ対策 - Qiita
セキュキャン 2015 高レイヤートラック(Jxck) 本資料は、セキュキャン 2015 高レイヤートラックの講義資料です。 セキュキャン参加者であるセキュリティエンジニアの卵を対象に、 Web のセキュリティの知見が、実際どのように Web アプリ開発に反映されているか、もしくはどう反映すべきかを、フレームワークの視点から解説することを目的としています。 将来、 Web のセキュリティに興味を持ったエンジニアが、その知見を多くの開発者に啓蒙する手段として、フレームワークに反映するというのは非常に有効な方法です。 ここではその実例として Rails を例にとり、 Rails がこれまでに積み上げてきたセキュリティに関する知見を振り返るとともに、フレームワークとしてそれをどう取り入れているかを解説します。 Intro Web アプリケーションを開発する場合、 Web アプリケーションフレーム
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
小さく始める JavaScript のテスト - Qiita
書かないと怒られるし、書きたいとは思っているが、書くまでの敷居がやたらと高くなってしまった気がしている人へ。 最小のテスト 本質的にテストを書くのにフレームワークはいらない。 assertion だけあればいい。 isomorphic にしたいなら、 node の assert モジュールすら使わず console.assert だけで書ける。 // assert function assert(actual, expected) { console.log('.'); console.assert(actual === expected, '\nact: ' + actual + '\nexp: ' + expected); } function TestSum() { assert(1+2, 3); } // exec TestSum(); あとは普通にこのスクリプトを node/io
小さく始める isomorphic module pattern - Qiita
せっかく window や node/io の標準モジュールに依存していないロジックであれば、 ブラウザでも node/io で動くようにしておくと色々嬉しい。が軽視されている感がある。 俗に isomorphic な JavaScript と呼ばれている。 それを npm と bower で公開するのであれば、問題はモジュールシステムだ。 最小の isomorphic module pattern 一番シンプルで負荷の少ない方法。 まず、ライブラリを以下のように書く。 // lib.js function Lib() { // 変数は外に出さない } Lib.prototype.foo = function(){ return "foo"; }; this.Lib = Lib; // point
IE10 以下を切る場合の JavaScript チェックリスト - Qiita
この投稿は、 JavaScript Advent Calendar 18日目の記事です。 更新履歴 こちら をご覧下さい JavaScript の書き方をアップデートする JavaScript Good Parts で書かれているような JS の書き方は、古くなりつつある部分も多いです。 正直なところ、自分はあの本が「今でも」良書だとは思っていません。 初学者に勧めることもしません。まんべんなさと普遍性と客観性から「パーフェクト JavaScript」 を勧めています。 その頃と比べると、 JavaScript をとりまく環境は変わりました JavaScript の進化に合わせて書き方もアップデートしていくべきなので、今回は分かりやすいしきい値として 「IE10 以下を切れるとしたら」 という前提で、列挙してみます。 たとえば XHR2 や File API に依存したサービスをやる場合な
npm で依存もタスクも一元化する - Qiita
タスク管理 package.json にはパッケージの依存を書いて npm install するのが基本だけど、 タスクの管理をどうするかというのは、別途また考えないといけない。 自分は gulp が良いと思っているが、 grunt や jake や make を使う人もいる。 また、たくさんオプションをつければほぼ一つのタスクが実行できてしまう browserify, jsh/eslint, mocha などのコマンドを提供するツールもある。 そして、 npm にも一部それらをサポートする npm run 機能があるので、そこに Unix ワンライナーを書くこともできる。 今回は、「どのタスクツールが最良か」みたいな話ではなく、それらをどうやって実行するか、または npm との棲み分けとか構成の流儀について、最近良いと思っているやり方について書いておく。 各方針で問題点を書いていくが、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
