TeraTerm用のマクロファイル「**.ttl」ファイルを実行すると「無効なホスト」と表示された場合の対処方法についてメモしておきます。
ttlファイル用の実行ファイルを「ttpmacro.exe」へ変更します。
TeraTermが日本語表示されない場合の対処方法についてメモしておきます。
|
1 2 3 |
; User interface language file that includes message strings. ; Tera Term uses built-in English message when the file or message is not found. UILanguageFile= |
|
1 2 3 |
; User interface language file that includes message strings. ; Tera Term uses built-in English message when the file or message is not found. UILanguageFile=lang\Japanese.lng |
JUnitで使用可能なアノテーションの種類についてまとめておきます。
| アノテーション | 用途 |
|---|---|
| @Before | メソッド単位で事前実行する |
| @BeforeClass | テストクラスで一回だけ事前実行 |
| @After | メソッド単位で事後実行する |
| @AfterClass | テストクラスで一回だけ事後実行 |
| @Rule | テスト時における一時的なルールの作成 |
| @ClassRule | 複数のテストを通じてのルール設定 |
| @Test | テストメソッドの指定 |
| @Ignore | 一時的にテスト対象外メソッドを指定 |
SQLでテーブルのレコード数を取得する方法をご紹介します。
SQLは
「SELECT COUNT(*) FROM [テーブル名];」形式で記述します。
|
1 |
SELECT COUNT(*) FROM goods; |
重複データを除いて取得する場合、SQLは
「SELECT COUNT(DISTINCT [列名]) FROM [テーブル名];」形式で記述します。
|
1 |
SELECT COUNT(DISTINCT type_code) FROM goods; |
業務でSQLを使用する場合、必ず使用する事になると言って良いのがテーブルの結合処理です。WEB系システムの場合、そのほとんどはRDBMSを使用してますのでテーブルが一つだけなどという事はまずありえません。複数のテーブルからその時々に応じて必要なデータを取得し使用するのが常です。その際に重要になるポイントの一つが内部結合と外部結合です。
|
1 2 3 4 |
SELECT goods.type_code, goods.name, type_code.code_name FROM goods INNER JOIN type_code ON goods.type_code = type_code.code; |
|
1 2 3 4 |
SELECT goods.type_code, goods.name, type_code.code_name FROM goods LEFT OUTER JOIN type_code ON goods.type_code = type_code.code; |
このサイトにも記事を書く際に画像を添付する事が多いのですが、「画像の形式ってjpgとpngどっちがいいんだろう・・・」と思いながらも適当に使っていたのでその辺を整理しておこうと思います。他にはgifなどもありますが今はあまり使用される事は少ないでしょうからjpgとpngについてのみまとめておきます。
SQLを理解する上で記載する各句の実行順序を理解している事はとても重要な事です。この辺の知識がおろそかになっていると複雑なSQLを書く場合や作成したSQLのパファーマンスに問題が発生した場合、他人か作成したSQLの修正などの対応に苦慮する事になるからです（はい私の事です）。逆に各句の実行順序を正しく理解していれば複雑なSQLもスラスラ書けるようになっていきます。
では今回は「SELECT文の各句の実行順番について」まとめておきます。
Web系の開発していると画面表示確認する際に、「cssやjsは変更したのに画面を表示してみると反映されていない」という事を経験した方は少なくないと思います。
こういう場合はまず、F5もしくはctrl+F5を押下して画面を再表示（リロード）確認すると思いますが、そもそも「F5単独」押下と「ctrl+F5同時」押下では何が違うんだろう？という事についてメモしておきます。
 |
 |
|
上記で説明している「更新ボタン」ですが、以下の様にブラウザのアドレスバー付近に表示されている以下のような赤枠内のボタンのことを「更新ボタン」と記載しております。
サーバー側制御（キャッシュ制御ヘッダー）との関係
ブラウザの「F5」や「Ctrl＋F5」によるリロードは、あくまでクライアント（ユーザー側ブラウザ）での操作です。ですが、本番環境ではサーバー側・ホスティング側で HTTP ヘッダー（例：Cache-Control、Expires、ETag）を設定して「ブラウザにいつまでキャッシュを使わせるか」「変更時には必ず再取得させるか」といった制御が行われています。
→ たとえば、Cache-Control: no-cache, no-store や Pragma: no-cache を設定しておくと、ユーザー側が「F5」だけでも常に最新取得がされるよう促せる場合があります。
→ 逆に、長めにキャッシュを許す設定がされていると「Ctrl＋F5」などをしない限り古いリソースを参照し続ける可能性があります。
開発／ステージング vs 本番環境の使い分け
開発中は「Ctrl＋F5（または Shift＋更新ボタン等）」を日常的に使って「確実にサーバー最新版を取得」するのが安心です。記事にも大まかに触れられています。
本番環境では、むしろキャッシュを上手に活用することでページ表示を高速化できますが、更新後に旧リソースが残って「見た目が変わらない」「古いCSS／JSが適用されている」というトラブルも起こりやすいです。
→ そこで「バージョニング（例：style.css?v=1.2.3）」や「ハッシュ付きファイル名（例：style.abc123.css）」などを併用すると、ユーザーにキャッシュクリアを意識させずとも確実に更新を反映させられます。
→ また、CDN（コンテンツ配信ネットワーク）を使っている場合、CDN側キャッシュのクリアやパージ（purge）が必要なケースもあります。
モバイル・タブレット・複数ブラウザでの挙動差
記事では主要なブラウザ（Chrome, Edge, Firefox, Safari, Opera）での「スーパーリロード」のキー操作をリストしています。ただし、モバイル環境（スマホ／タブレット）やブラウザ拡張機能、企業内のカスタムブラウザでは、キー操作が異なる／押してもキャッシュが残る／そもそも更新ボタンしか無いというケースもあります。
→ 例えば iOS の Safari では「更新ボタン長押し→再読み込み／キャッシュの消去」など特殊な操作になることがあります。
→ また、企業／学校環境でプロキシサーバーや内部キャッシュ（例：Squid／キャッシュサーバー）が間に入っていると、ブラウザ側で「Ctrl＋F5」しても完全に最新が来ないことがあります。こういった場合は、プロキシキャッシュクリアが必要／あるいはバージョニング戦略を必ず採るべきです。
リロード頻度とユーザー体験のバランス
頻繁に「Ctrl＋F5」を強制する設計（例：ボタンを押させる／ユーザーに再読み込みを案内する）をしてしまうと、ユーザー体験が損なわれる可能性があります。回線が遅い環境やモバイル回線では、「ページが一瞬消えて、再読み込みになった」印象を与えてしまうことも。
→ よって、可能であれば「差分更新」の設計（新旧CSS/JSの両方互換）や「ローディング中のUI／スピナー表示」でユーザーに待機時間を意識させない工夫も有効です。
→ また、キャッシュ切れをユーザーに知らせるインターフェイスは、必要以上に派手に表示しないことで「更新作業中なのかな…」という不安を軽減できます。
ブラウザ開発者ツールの活用
Web開発時、キー操作以外にも、ブラウザの開発者ツール（DevTools）を使って「キャッシュ無しで再読み込み」を行うことも可能です。例えば、Chrome では「デベロッパーツールを開いた状態で右クリック→再読み込み→キャッシュを無視してハード再読み込み」を選択できます。
→ これにより、ユーザー側のキー操作に頼らず「確実に最新リソースで表示をチェック」できます。
→ また、ネットワークタブで → Disable cache（キャッシュ無効化）をチェックしておくことで、開発中は毎回最新を取得させる設定にできます（ただし、タブを閉じると元に戻ります）。
結論としての注意点
結局、「F5」はキャッシュを使ってリロード、「Ctrl＋F5（または他のスーパーリロード操作）」はキャッシュを無視して最新を取得という違いがあります。しかし、現実には「キャッシュをどう制御しているか（ヘッダー／CDN／プロキシ）」「ユーザーの環境（モバイル／社内ネットワーク）」「開発運用の体制（バージョニング／キャッシュクリア運用）」という“周辺条件”が非常に重要です。これら全体を俯瞰して設計・運用することで、ユーザーにとって快適で信頼できる表示体験が実現できます。
junitでexceptionが発生した事の確認テストはどのようにすれば良いかメモしておきます。
exceptionの発生確認は@Test内に「(expected = [確認したいExceptionクラス])」を指定する事で簡単に確認する事が出来ます。
|
1 2 3 4 5 6 7 8 9 |
@Test(expected = IndexOutOfBoundsException.class) public void testIndexOutOfBoundsException() { // 準備 List<String> test = new ArrayList<String>(); test.add("abc"); // 実行 test.get(1); } |
ちょっとdjUnitで「addReturnValue」を使用しても全く効いてない？という事象に少しハマっていたので原因についてメモしておきます。
addReturnValueが効かない原因として上げられるのが概ね以下の3つになるかと思います。1と2については少し見なおせばすぐ発見出来そうですが、今回ハマった原因が3でした。。。
では「指定したメソッドが複数回実行されている」というのはどういう事かというとについて説明します。
根本的な話として以下の2つのコードは全く同じ意味という事を理解しておく必要があります。
|
1 2 |
addReturnValue(UtilClass1.class, "getStr", expected1); setReturnValueAt(UtilClass1.class, "getStr", 0, expected1); |
これだけで気づく方はハッと思うかもしれませんが、ここで重要なのはaddReturnValueでは「1回目に実行」されたメソッドのみしかaddReturnValueで指定した値が返ってこないという事です。つまり「setReturnValueAt」で1回目を指定した場合と同様の動きしかしてくれないのです。
今回私がハマったのは指定したメソッドが想定した箇所よりも手前で事前に実行されていた為、想定したいたメソッドは2回目の実行になっていたために2回目の方にはaddReturnValueが効いていなかったという事象でした。
addReturnValueをしてクラス名やメソッド名は正しいのにどうも効いていないように見える時は一度「getCallCount」でメソッドの実行回数を調査して見ると良いかもしれません。
