認証と認可 - logiqboard
OpenIDだのOAuthだのFacebookコネクトだの認証だの認可だの白だの黒だの！ たまに混同しそうになるので認証と認可についてまとめておく。 認証 英語でAuthentication -> 辞書的な意味*1 目的 アクセスしてきたユーザーが誰なのかを特定すること。 一般的な認証 ID/password 端末固有IDとか OAuthとかOpenIDとか*2 認可 英語でAuthorization -> 辞書的な意味*3 目的 認証されたユーザーが、サービスのデータや機能のうちどれを利用できるのかを決めること 一般的な認可 ふつうのwebサイトにおいては、認証された時点で全ての機能が使えるようになっているが、これは認証された時点でそのユーザーに対して全ての機能の利用が認可されているとみなす。 TwitterAPIとかは、APIを利用する各サービスについて認可される内容が決まっている。ユ
案件ふりかえりそのに - logiqboard
またも清水川大明神先生様に「それブログで」って言われたので、もうすこしまとめてみた。まだまだである。 お客さんとプログラマー プログラマー（SE?）の仕事はお客さんが持ってるもやもやとしたアイデアを最終的に動くプログラムというカタチに変換してあげることだ。 しかしプログラムは思ったとおりには動かず、書いたとおりに動くものなので、まず仕様に落としてやらないといけない。 で、これが大変辛い。開発の苦労の半分ぐらいは、いわゆるクソ仕様と呼ばれるものから発生する。 だれが決める？ 弊社だとこれを大体実装者と同じ人間がやるので、実装負荷と仕様策定の負荷が重なってたいへん辛い。 さらに他にメンバーが居ると厄介で、実装負荷を持ってもらう代わりに仕様を余す所なく伝えるという作業まで発生するのでもう泣きそうになる。 ここで伝え漏れ、認識の齟齬があるとコレジャナイロボを作るハメになり、さらに苦行が続く。 仕様
案件ふりかえり - logiqboard
とある案件が終わった。相変わらずきっつい納期だったうえに、全メンバー片手間の情況でよくやれたなと自画自賛していいと思う。 ふりかえりをツイートしたら清水川大明神先生様に「それブログで」って言われたので、すこし整理してみた。 テスト テストを書く習慣が付いたのはつい数ヶ月前のことなのだが、この案件ではテストが非常に役立った。 もともとFlashゲームのバックエンドAPIサーバーを作る仕事だったのでサーバー側のテストがしやすいというのもあったが、初期からテストのしやすさを意識して書いた。 マイルストーン期日が押していても１機能に対して最低ひとつ、想定通りの値で想定通りの結果が返ることを確認するテストを書いた。 それだけでも下らないバグは十分に防げた。 目標設定 テストの数が50を越えた頃から、100テストを目標にしていた。 カバレッジとかは一切計算していないし、100という数字にも何の根拠もな
デコレータを外す - logiqboard
おはこんばんちわ。情弱王子feizです。 最近とある方の影響で自動テストに凝っておりまして、それはもうセルフプレジャーを覚えた猿のようにテストを書いてるとかいないとかな毎日です。 さて Pythonでテストをかいてると、たまにデコレータが邪魔になることがあります。 例えばjsonを返すAPIのビューをdjangoでこんなふうにかきました。 class Api(object): @require_GET @json_response @error_handle @validate(MyViewForm) def myview(self, request, params): return { "azuma": params["feiz"], "okano": params["tokibito"], } require_GET リクエストメソッドをチェック json_response 辞書をjs
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
