TimeZoneを扱う - やさしいデスマーチ
国内で国内向けのアプリケーションを作っている限りは、タイムゾーンを意識することはほとんどありません。しかし、Google App Engine等を利用する場合、多国対応のアプリケーションを作るためにはタイムゾーンを正しく扱うことが必要不可欠です。というわけで、タイムゾーンをGAE/Slim3を使う場合に考慮すべき事をまとめました。 デフォルトのタイムゾーン Javaの場合、システムで持つデフォルトのタイムゾーンがあり、普段は暗黙的に利用されています。開発環境とプロダクション環境ではデフォルトのタイムゾーンが異なります。 開発環境 +0900 Asia/Tokyo プロダクション環境 +0000 UTC ※開発環境のタイムゾーンはシステムに依存します。 デフォルトのタイムゾーンを指定する GAE上を使うけどアプリケーションは国内向けであるのであれば、デフォルトのタイムゾーンを変更するのが簡単
77-偶然の仕様ではなく本物の仕様のためのテストを書く - やさしいデスマーチ
「プログラマが知るべき97のこと」の77個目のエピソードは、テストに関する話です。自分にとって、このエピソードはきのこ本の中で最も重要で、今後実践していく課題の１つです。テストは、ソフトウェア開発を進めていく中で、避けられない一番の問題です。そして、最も難しいものです。テストというものは、学べば学ぶほど難しいものであると感じます。 テストが難しい最大の理由は、テスト自体が目的によってたくさんの種類があり、それぞれの状況で適切に使い分ける必要がある、という事です。このエピソードで扱うテストは、主にユニットテストから結合テストあたりまでのプログラマが主導で行うテストですが、それ以外にも品質保証に関するテストなどもあります。ユニットテストに関しては、JUnitなどのテスト手法を使うことで品質があがると雑誌などで知り、開発に組み込んだ組織は多いでしょう。しかし、実際にユニットテストが効果的に作用し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
