ふつうのユニットテストのための７つのルール - ブログなんだよもん
最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記： テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記： もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定
Meteorが見せるIsomorphicなDBとリアクティブな開発モデル - ブログなんだよもん
最近、Meteorを試して見てます。これはちょっとスゴイ。正直、当時Railsに受けたのと同じ興奮がある。 Meteorの説明は「リアルタイムWebアプリケーションフレームワークMeteorについて」あたりが分かりやすいので、こちら参照。 実は、2012年の公開時から存在は知ってたんだけど、チュートリアル見たくらいで特に興味はありませんでした。 しかし、今は違います。それは主にスマホアプリの開発にかなりの威力を発揮しそうだと気づいたからです。 まず、なんで公開時にあまり興味がなかったかですが、そもそもRailsなど同レイヤーのWebアプリケーションの開発FWとして考えていました。 その場合 SPA リアクティブな開発モデル クライアントとサーバを同一コード(JS)で書ける サーバサイドのDBをクライアントから透過的に呼び出せる(IsomorphicなDBモデル) という特徴はせいぜいリアク
OAuth2.0のclient_secretって本当に秘密鍵ですか？ - ブログなんだよもん
OAuthをしているサービスをAndroid + PhoneGap経由で使いたくて調べて見ました。 そして、色々調べたり考えたりした結果、 client_secret ってそもそも秘密鍵にする必要なくね？ という天啓を得たので、つらつらと書いてみます。secretって名前なのに秘密である必要がないなんて、わけがわからないよ。 間違ってる気がしてならないので、誰か指摘をしてください。マジで。 とりあえず、前提として自分のサービスの認証替わりに使いたいわけじゃなくて、純粋にそのサービスを使うのが目的。OAuthなサービスはサーバサイドで使ったことは何度かあるんだけど、クライアントサイドで使うという事で、扱いが困るのがclient_secret。名前の通り、秘密鍵として扱う必要があると思ってたんだけど、正直安全にクライアント側で管理する方法が無い。 公開している通常のソースからは外してビルド時に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
