Eclipseでのjarファイルの作成方法についてメモしておきます。
業務では結合試験以降などはサーバーに資材を配置して試験を実施するのが一般的です。その際、javaソースはjarファイルにして配置することになります。
環境
- Eclipse 4.2
- Windows7 professional 64bit版
Eclipseでのjarファイルの作成方法についてメモしておきます。
業務では結合試験以降などはサーバーに資材を配置して試験を実施するのが一般的です。その際、javaソースはjarファイルにして配置することになります。
使用しているWinMergeのバージョンによってはUTF-8のファイルを比較する場合は基本的にS-JISで表示するため、日本語の箇所が文字化けして表示される場合があります。
そういう場合はデフォルトの文字コードを変更する事で解消する事が出来ます。
今回はデフォルトコードページをUTF-8に変更する手順をご紹介します。
| 文字コード番号 | 文字コード |
|---|---|
| 932 | SHIFT-JIS |
| 20932 | EUC-JP |
| 65001 | UTF-8 |
UTF-8のBOM有無
UTF-8には「BOMあり/なし」の2種類があり、環境やソフトによってはBOM付きファイルで文字化けや差分検出の誤認が発生する場合があります。必要に応じて保存形式を確認してください。
改行コードの違い
Windows(CRLF)、Linux(LF)、古いMac(CR)などで改行コードが異なるため、WinMerge上では不要な差分として表示されることがあります。設定で「改行コードの違いを無視」を有効にすると便利です。
フォントの問題
日本語環境でもフォントによってはUnicodeの一部が表示できず「□」に化ける場合があります。異体字や特殊記号が含まれる場合は注意してください。
文字コードの見極め
比較対象のファイルが本当にUTF-8かSJISかなどを確認することが重要です。エディタ(VS Codeや秀丸など)で文字コードを明示的に確認すると確実です。
バージョン差異
WinMergeのバージョンによって設定画面やコードページ指定方法が異なることがあります。環境に合わせた確認をおすすめします。
代替ツールの活用
WinMergeで対応が難しい場合、Beyond Compare、Meld、kdiff3など他の比較ツールを利用するのも有効です。特に大規模な差分確認やUnicode依存の環境では効果的です。
WinMerge は基本的に文字コードを自動判定しますが、以下のようなケースでは誤判定が起きやすいので注意が必要です。
UTF-8 with BOM と UTF-8 without BOM の区別
Shift-JIS と EUC-JP の曖昧さ
絵文字や合成文字を含む場合
文字化けが発生した場合は、手動で文字コードを選び直すと解消することがあります。
文字コードの設定を変更しても反映されない場合は、以下を確認してください。
管理者権限で WinMerge を起動しているか
古い設定ファイル(WinMerge.ini)が残っていないか
比較対象のファイルがキャッシュされていないか
一度設定をリセットしてから再設定すると改善することがあります。
ここではhttpとhttpsの違いについてメモしておきます。
この2つを理解しやすくするには「http」と「https」の正式名称を思い浮かべるとイメージし易いでしょう。
httpsの「s」とは「セキュア」つまり「安全なhttp」という事です。
httpのホームページでは住所、氏名といった個人情報をそのままサーバへ送信してしまいます。一方httpsでは情報を暗号化してサーバへ送信します。
ブログなどのように相手に読ませるためだけのページであればhttpでも大きな問題にはなりにくいですが、ログイン画面や決済時にクレジットカードなどの個人情報を入力するような画面では「https」になっている事が大前提と言えます。逆に個人情報を入力するのに「http://~」となっているようなサイトであれば、セキュリティに対する認識が甘い企業と見られてしまうでしょう。
データベース製品のライセンス一覧です。
| 製品名 | オープンソース/商用 | ライセンス | データ モデル | 料金 |
|---|---|---|---|---|
| DB2 | 商用 | IBM | ORDBMS | 1プロセッサ ・461万7000円 2年目から5年目の保守料 ・88万700円/年 1プロセッサで5年間運用した場合のコスト ・813万9800円 |
| HiRDB | 商用 | 日立製作所 | RDBMS | 同時接続数ライセンス ・120,000円 1プロセッサ ・1,800,000円 |
| MySQL | オープンソース | GPL or 商用 | RDBMS | 1-4 ソケットサーバー 1台/年(税抜) ・Standard Edition:240,000 ・Enterprise Edition:600,000 ・Cluster Carrier Grade Edition:1,200,000 5+ ソケット・サーバー/年(税抜) ・Standard Edition:480,000 ・Enterprise Edition:1,200,000 ・Cluster Carrier Grade Edition:2,400,000 |
| Oracle Database | 商用 | オラクル | RDBMS | |
| PostgreSQL | オープンソース | BSD | ORDBMS | 無料 |
SQLで前方一致・後方一致・部分一致等のあいまい検索の方法についてご紹介します。
SQLであいまい検索を行う場合はワイルドカード文字として「%」を使用します。
以下の商品テーブル「goods」を元に説明します。
|
1 |
SELECT * FROM goods WHERE name LIKE '商品%'; |
以下の様に前方に「商品」と入力されているデータのみ出力されます。
|
1 |
SELECT * FROM goods WHERE name LIKE '%A'; |
以下の様に後方に「A」と入力されているデータのみ出力されます。
|
1 |
SELECT * FROM goods WHERE name LIKE '%ボード%'; |
以下の様に文字列に「ボード」が含まれているデータが出力されます。
LIKE 演算子を使ったあいまい検索は、通常のインデックスが利かないケースが多く、パフォーマンス低下の原因になります。
前方一致('文字列%')であれば B-Tree インデックスが使われることもありますが、後方一致('%文字列')や部分一致('%文字列%')では使われないことが多いです。
大量データを扱う場合は、全文検索エンジン(たとえば PostgreSQL の pg_trgm 拡張、Elasticsearch、MySQL の全文検索機能など)の導入を検討したほうがよいでしょう。
データベースによっては、LIKE は大文字・小文字を区別するかどうかが異なります。
MySQL(latin1 や utf8_general_ci など)では大文字・小文字を区別しないことが多い
PostgreSQL では ILIKE を使うことで大文字・小文字を無視したマッチングが可能
必要であれば、LOWER() を併用して検索キーとカラムを小文字化して比較する方法もあります。
検索文字列中にワイルドカード文字(% や _)を含めたい場合は、適切にエスケープを行わないと意図しないマッチングをしてしまいます。SQL では ESCAPE 句を使ったり、特殊文字をエスケープ文字で前置したりする必要があります。
この例では「50%」という文字列を検索対象に含めたい場合の書き方です。
あいまい検索と他の条件(数値比較、日付範囲、結合など)を組み合わせる際は、WHERE 句の書き方、実行計画、インデックス設計に注意が必要です。
たとえば、部分一致検索を先にするとスキャンが広くなり、結合条件や他の絞り込み条件を後に書いても性能が出にくくなる場合があります。
そのため、可能な限り絞り込み条件(等価比較や範囲条件など)を先に適用する、あるいはサブクエリ・CTE を使って事前に対象を絞るなど工夫するとよいでしょう。
| アプローチ | 用途・メリット | 注意点 |
|---|---|---|
| 正規表現検索(REGEXP、~ など) | より複雑なパターンマッチングが可能になる | パフォーマンスに注意、サポート状況に依存 |
| トークン分割・前処理 | 検索対象をあらかじめトークン化して部分一致を高速化 | 実装が複雑、追加のメンテナンスコストあり |
| 専用全文検索エンジン | 高速な全文検索、スコア付け、複合検索 | データ同期や運用コストを考慮 |
| n-gram / trigram 検索 | 部分一致の高速化を狙える技術 | インデックス設計やメモリ・ストレージ消費に注意 |
業務でデータベースの操作をする場合、データが大量に登録されているテーブルへアクセスする場合に索引(INDEX)を作成するとSQLクエリの実行が劇的に早くなるケースが多々あります。この索引(INDEX)についてどういう場合に作成すれば良いのか、メリット、デメリット等についてまとめておきます。
EclipseでJUnitやDjUnitを実行すると「junit java.lang.OutOfMemoryError: Java heap space」とメモリエラーが表示された場合は「デフォルトのVM引数」を設定する事でこの事象を回避する事が出来るのでその設定方法をご紹介します。
Excelで文字列置換する場合「SUBSTITUTE」関数か「REPLACE」関数のどちらかを使用します。但し、EXCELのREPLACE関数はJa「この指定文字列をまとめてこの文字列へ置換」というような事は出来ません。EXCELで文字列置換する場合は通常「SUBSTITUTE」関数を使用します。
Excelで重複データを削除する方法をご紹介します。
重複データを削除するだけならExcelの標準機能で簡単に削除する事が可能です。
重複の削除は一度実行すると元に戻せない場合があります。操作前に次の点をチェックしておくと安心です。
元データをコピーしてバックアップを取る
どの列(または複数列の組み合わせ)で重複を判断するかを明確にしておく
空白セルや大文字・小文字の扱いを統一しておく(例:「Apple」と「apple」を同一とみなすか)
削除前にフィルターや条件付き書式で重複箇所を目視確認しておく
また、Excel 365 以降を利用している場合は、UNIQUE 関数を使って重複を除いたリストを生成する方法も便利です。
たとえば次のように入力すると、列 A から重複なしの一覧を自動で作成できます。
このように、作業前に条件を整理しておくことで、意図しないデータ削除を防ぎ、より安全にデータをクリーンアップできます。
通常JUnitでは1クラスに対して1クラス分のテストケースクラスを作成してテストを実施します。何らかの業務でプロジェクト全体での規模になってくるとその数は何十、何百、時には何千となる事も珍しいことではありません。
こういったプロジェクトでソースに何らかの修正が入り、テストを実施するという場合に1つずつJUnitで確認していたのでは実行するだけで無駄に時間が掛かってしまいます。
こういう場合には「テスト・スイートクラス」を作成して、まとめて実行して確認するのが一般的な手法となります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
import org.junit.runner.RunWith; import org.junit.runners.Suite; import org.junit.runners.Suite.SuiteClasses; @RunWith(Suite.class) @SuiteClasses({ OverLoadSampleTest.class, OverRideSampleTest.class, SampleClass1Test.class, UtilClassDjUnitTest.class, UtilSample1Test.class, UtilSample1TestDjunit.class }) /** * <p>[概 要] コンストラクタ</p> * <p>[詳 細] テスト・スイートクラスのコンストラクタ。</p> * <p>[備 考] </p> */ public class AllTests { } |