一般的に郵便物を送付する際、普通郵便の場合は82円、速達の場合は362円の料金が掛かります。
ではこの料金の差はどこにあると思った事はないでしょうか？
私の場合ですが、速達の場合は普通郵便より早くつくからその手間賃なんだろうと漠然と考えていました。ですが、普通郵便でも速達と同じ速度で届くことがあるのです。
普通郵便と速達郵便の集配システムの違い
集配システムは基本的に以下の順序で各家庭に届けられます。
- ポスト⇒ポストを設置している地域の集配局⇒その地域の集配局⇒輸送⇒配達先の集配局⇒各家庭
この流れで大きく分けて1日3回（朝、昼、夕）の3回集配されます。
- 普通郵便の場合
普通郵便の場合は朝回収された郵便物はその日の内に郵送ルートに乗りますが、昼以降回収された郵便物は翌日以降の郵送ルートへ回されます。
- 速達郵便の場合
速達郵便の場合は朝、昼、夕に回収された郵便物はそれぞれ朝の郵送ルート、昼の郵送ルート、夕の郵送ルートに乗って郵送されます。
この違いから昼以降の郵送に関しては速達の方が早く各家庭に届けられるので、その手間賃分の料金が掛かっています。
ということで朝郵便物をポストへ投函すれば高い料金を払わなくても速達と同じ速度で届くこともあるようです。
Web開発では帳票をExcelで出力する際に「Apache POI」がよく使用されています。
ただ「Apache POI」を使用する場合、システム的な制限やリソースなど事前に注意しておくべき点があるのでメモしておきます。
Apache POIの問題点
- 「xlsx」形式のファイルの場合、リソースを大量に消費する
POIを使用する場合、出力帳票のテンプレートファイルを用意して帳票を出力するケースが多いと思われます。このテンプレートファイルの拡張子がEXCEL2007以降の形式「xlsx」で用意されている場合、POIでは一旦そのファイルを全てメモリに読み込ませる為により多くのリソース（メモリ）を消費する事になります。
- セル結合処理は非常に遅い
POIでEXCEL操作する場合、セル結合処理は非常に処理速度が遅くなるので帳票のフォーマットを決める場合はセル結合しないフォーマットで設計しておいた方が懸命です。
エディタなどで文字コードを指定する際「BOM有り」と「BOM無し」という選択肢があります。この「BOM」とは何かをまとめておきます。
BOMとは？
まずBOMとは「バイトオーダーマーク (byte order mark) 」の略語となります。
バイトオーダーマークとはUnicode形式のデータを「ビッグエンディアン」、「リトルエンディアン」のどちらで保存しているのかという情報をデータの先頭に付与する情報のことです。
UTF-8の場合、先頭に3バイトのバイナリデータ「0xEF 0xBB 0xBF」が付与されたものが「BOM有り」の状態。付与されていない場合が「BOM無し」の状態となります。
どういう場合に「BOM有り」、「BOM無し」を使い分けるか？
- Unicodeの規格ではBOMは推奨していません。
- Web制作などでHTMLやPHPなどをエディタで編集する際はBOM無しを選択した方が一般的には問題は起こりにくいので無難です。但し、必ずしもBOM無しが正解というわけではないのは認識しておきましょう。
- 「Microsoft Office Excel」などはBOMがないとUTF-8だと認識できず、種々の問題が起こる。
- 基本的にはアプリケーション側でBOM有りが推奨されているケース以外ではBOM無しをデフォルト設定しておけば良いかと思われます。
JUnitでテストする時にprivateメソッドをテストする方法をご紹介します。
privateメソッドをテストするにはリフレクション「java.lang.reflect.Method」を使用することで実行可能となります。
Javaソース
JUnitサンプル
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
@Test public void testSampleMethod() { // 準備 SampleClass1 sampleClass1 = new SampleClass1(); String result = ""; // 期待値 String expected = "hogetest"; // 実行 try { Method sampleMethod = SampleClass1.class.getDeclaredMethod("sampleMethod", String.class); // privateメソッドにアクセス可能とする sampleMethod.setAccessible(true); result = (String)sampleMethod.invoke(sampleClass1, "hoge"); } catch (SecurityException e) { // 普通のプログラムでは発生しない、ほとんど無視していい fail(e.getMessage()); } catch (NoSuchMethodException e) { // メソッド名・引数の型が一致しない場合に発生 fail(e.getMessage()); } catch (IllegalArgumentException e) { // 実行対象の引数の型/引数の数があってれば発生しない。NoSuchMethodExceptionの場合と同じく、１度でも通れば基本的に例外処理はいらない fail(e.getMessage()); } catch (IllegalAccessException e) { // 対象メソッドのアクセス制限(private/default package/protected)によりアクセス不可の場合に発生 fail(e.getMessage()); } catch (InvocationTargetException e) { // 対象のメソッドの処理中に発生した例外。e.getCause()で実際にメソッド内で発生した例外を取得できる。 fail(e.getMessage()); } // 検証 assertEquals("戻り値が一致していません", expected, result); } |
JUnitでテストする時にprivateなメンバ変数を取得・更新したい場合の方法をご紹介します。
今回はAPI「JMockit」の「Deencapsulation」クラスを使用してカプセル化された変数を参照・更新する方法です。
JMokitのダウンロード
以下サイトへアクセスしてダウンロードした「jmockit.jar」ファイルをクラスパスへ追加します。
クラスパスへ追加する際、JUnitより先に読み込む必要があるのでJUnitより上位へ配置します。
JMokitのダウンロード
JMokitのJavadoc
Javaソース
JUnitサンプル
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
import static org.junit.Assert.*; import mockit.Deencapsulation; import org.junit.Test; public class SampleClass1Test { @Test public void testSampleField1() { // 準備 SampleClass1 sampleClass1 = new SampleClass1(); // 期待値 String result = "hoge"; // 実行（privateインスタンス変数の値を取得） String expected = Deencapsulation.getField(sampleClass1, "field"); // 検証 assertEquals("サンプルフィールドの値が一致していません", expected, result); } @Test public void testSampleField2() { // 準備 SampleClass1 sampleClass1 = new SampleClass1(); // 期待値 String result = "hogehoge"; // 実行（privateインスタンス変数の値を変更） Deencapsulation.setField(sampleClass1, "field", result); // 検証 String expected = Deencapsulation.getField(sampleClass1, "field"); assertEquals("サンプルフィールドの値が一致していません", expected, result); } } |
「駑馬十駕」 IT系情報を中心に調べた事をコツコツ綴っています。
