「Web開発」カテゴリーアーカイブ

HULFT連携:Javaからユーティリティコマンドを呼び出す実装例

HULFTには「送受信ジョブを定義して使う方法」以外に、utlsendなどのユーティリティ系コマンドを直接呼び出してファイル転送や加工を行う手段があります。
これらは事前の送受信定義が不要で、コマンド実行時に条件を指定できるため、テスト送信・スポット利用・簡易処理に非常に便利です。

本記事では、JavaでHULFTコマンドを実行する例をご紹介します。

  • utlsend : ファイル送信

  • utlrecv : ファイル受信

  • utlconcat : ファイル連結

  • utlsplit : ファイル分割


Javaから外部コマンドを実行する基本

Javaでは ProcessBuilder を使うことで、外部のHULFTコマンドを呼び出せます。
エラー出力も標準出力にまとめる設定をすれば、ログ管理が容易になります。

共通の呼び出しテンプレートは以下の通りです。

以降の例では、この runCommand を利用して各ユーティリティコマンドを実行します。


1. ファイル送信(utlsend

事前の送信定義が不要で、対象ファイルと宛先ノードを直接指定できます。

  • -f : 送信するファイルパス

  • -n : 宛先ノード名(HULFTに登録済み)


2. ファイル受信(utlrecv

受信ジョブを登録せず、コマンドだけでファイルを取得できます。

  • -f : 保存先のファイル名

  • -n : 送信元ノード名


3. ファイル連結(utlconcat

複数のファイルを1つにまとめたいときに使います。

  • -o : 出力ファイル名

  • -f : 結合対象のファイル(複数指定可)


4. ファイル分割(utlsplit

大きなファイルを分割して処理したいときに使います。

  • -f : 分割対象ファイル

  • -l : 分割する行数(例:1000行ごと)


運用上の注意点

  1. PATHの設定
    Javaから呼び出す際は、utlsend.exe などのHULFTバイナリがPATHに通っている必要があります。
    通っていない場合はフルパス指定が必須です。

  2. 終了コードの確認

    • 0 : 正常終了

    • 0以外 : エラー(詳細はHULFTマニュアルのエラーコード参照)

  3. ログ管理
    実際の業務バッチでは process.getInputStream() の内容をファイル出力してログ管理することを推奨します。


まとめ

  • utlsend でファイルを即送信できる

  • utlrecv で即時受信が可能

  • utlconcat でファイルを連結

  • utlsplit でファイルを分解

これらをJavaから呼び出すことで、柔軟なファイル連携や加工処理が実現できます。

Git と SVN の違いを徹底比較!モダン開発と Git 移行メリットを解説

ソフトウェア開発では欠かせないバージョン管理システム(VCS)。
代表的なものに Subversion(SVN)Git がありますが、それぞれ仕組みや特徴に大きな違いがあります。
この記事では両者を比較し、どんな場面で使われるのかを整理していきます。


1. 管理方式の違い

  • SVN は中央サーバー型(集中管理型)。サーバーに履歴があり、各開発者は必要な部分をチェックアウトして作業します。

  • Git は分散型。各開発者の手元に完全な履歴がコピーされるので、オフラインでもコミットや履歴の参照が可能です。


2. ブランチの扱い

  • SVN:ブランチはディレクトリをコピーする仕組み。重いため頻繁に切り替える運用には向きません。

  • Git:ブランチはポインタのような軽量な仕組み。気軽に作成・切り替え・統合でき、アジャイル開発と相性が良いです。


3. 比較表

項目SVN(Subversion)Git
管理方式集中型(中央リポジトリ必須)分散型(ローカルに完全コピー)
履歴サーバーに依存・オフライン不可ローカルに全履歴あり・オフライン可能
ブランチディレクトリコピーで重い軽量で高速・並行開発に最適
操作速度サーバー通信が多く遅めローカル主体で非常に速い
権限管理ディレクトリ単位で詳細設定可リポジトリ単位(サービス連携で補完)
使われ方レガシー環境・金融/公共系で根強いオープンソース・モダン開発の標準
 

4. 企業で SVN が残る理由

  • レガシー資産が膨大:10年以上運用しているプロジェクトを変えるコストが大きい

  • 単純な運用ルール:常に「中央が正」でシンプル

  • アクセス制御が細かい:サーバーで一元管理しやすい

  • 情報漏洩リスクを嫌う:ローカルに履歴を残さないことで安心とされるケースもある


5. Git への移行メリット

  • 効率的な並行開発:ブランチが軽いので複数人開発でもストレスが少ない

  • オフライン作業可能:出張先やネットが不安定でも履歴参照やコミットができる

  • エコシステムが豊富:GitHub・GitLab・Bitbucket など連携サービスが充実

  • CI/CD と相性抜群:自動テスト・デプロイと組み合わせやすい


まとめ

  • SVN は「安定・単純・集中管理」が強みで、金融や公共系、レガシー環境で今も利用されています。

  • Git は「柔軟・高速・モダンツール連携」が強みで、オープンソースやアジャイル開発での標準です。

👉 新規プロジェクトであれば Git を選ぶのが一般的。
ただし既存の大規模システムでは「SVN を参照専用にして、新規は Git」で併用するケースもよくあります。

HULFTの転送速度はどのくらい?大容量ファイル送信を高速化するチューニング術

企業システム間のデータ連携で定番の HULFT(ハルフト)
日次バッチや帳票ファイルの受け渡しで使っていると、「転送が遅いのでは?」と感じることもあるでしょう。

この記事では、HULFTの転送速度の目安と、大容量ファイルを高速・安定的に送信するためのチューニング術をまとめます。
さらに、WinSCP や AWS CLI との比較も紹介します。


1. HULFTの転送速度の目安

HULFT自体は内部的に64bit整数でファイルを扱えるため、理論的な制限はほぼありません。
実際の速度は ネットワーク帯域 × HULFTの処理オーバーヘッド に左右されます。

📊 ファイルサイズ別の目安(1Gbps環境・実効70〜80%の場合)

ファイルサイズ転送時間の目安備考
100MB1〜2秒LAN環境なら一瞬
1GB10〜15秒WAN越しだと数分に延びることも
5GB1〜2分S3の1オブジェクト上限(5TB)には余裕あり

💡 100Mbpsの回線では、1GB送信に2分前後かかります。
つまり「回線帯域の影響が支配的」と言えます。


2. 回線速度ごとの目安

HULFTのオーバーヘッド込みで実効値を 70〜80% と仮定した場合の目安です。

回線速度理論値実効値(目安)1GB転送時間
1Gbps回線(LAN内)125MB/s90〜100MB/s約10〜12秒
100Mbps回線(VPN/クラウド接続)12.5MB/s8〜10MB/s約100〜120秒(2分程度)
50Mbps回線(遅めのVPN)6.25MB/s約5MB/s約200秒(3〜4分)
10Mbps回線(制限回線など)1.25MB/s約1MB/s約15〜20分
👉 このように、回線帯域がボトルネックになるケースが大半です。

チューニングで改善できるのは「オーバーヘッド部分」ですが、根本は回線速度に依存します。


3. HULFTと他の手段の速度比較

同じ回線での「体感スピード」の比較イメージです。

手段転送速度の傾向特徴
HULFT実効70〜80%(安定)商用の運用性・再送制御が強い。監査/ジョブ連携向き
WinSCP (SFTP/FTP)実効50〜70%GUIで扱いやすいが大容量の再送制御は弱め
AWS CLI (S3 cp/sync)実効80〜90%(並列化可)高速だがジョブ管理や監査は限定的
👉 HULFTは「最高速」ではなく「確実性と運用性を優先した転送」という位置づけです。

特に基幹システム間の「失敗できない転送」ではHULFTが選ばれる理由があります。


4. 転送速度に影響する要因

HULFTの転送性能は、次の要素で大きく変わります。

  • ネットワーク帯域:1Gbpsか100Mbpsかで10倍以上の差

  • HULFTのバッファサイズ:デフォルト64KB → 1MBに拡張すると効率UP

  • 再送制御:エラー時の挙動設定によって安定性と速度が変わる

  • ファイルシステムのI/O性能:HDDよりSSDの方が有利

  • 暗号化や圧縮の有無:CPU負荷が上がると転送速度が落ちる


5. 高速化のためのチューニング術

大容量ファイルを送る際に有効なチューニング方法を整理します。

(1) バッファサイズ調整

  • パラメータ SEND_BUFFER_SIZE1024KB(1MB)程度 に拡張

  • WAN越しでもスループットが改善

 
# 設定例 SEND_BUFFER_SIZE=1024

(2) マルチパートアップロード(S3利用時)

  • HULFT Storage Option では 並列転送 に対応

  • 1GBクラスなら1パートで十分だが、数GB以上なら 4〜8並列 に設定すると効果大

(3) 部分再送を有効化

  • 転送途中で中断しても 途中から再開 できる

  • WAN経由や夜間バッチでの安定性向上に必須

(4) 圧縮の利用

  • CSVやテキストは圧縮転送で大幅短縮

  • バイナリ(PDFやZIP)は圧縮効果が薄い

(5) ネットワーク調整

  • TCPウィンドウサイズやNIC送信バッファを拡張

  • Linux例:


6. 運用上の工夫

速度チューニングだけでなく、運用面でも工夫が必要です。

  • ピーク時間を避けてスケジューリング(夜間バッチに実行)

  • 再送回数を3回程度に設定し、エラー時のリカバリを自動化

  • ログ監視(HULFTの送受信ログ+S3側のCloudWatch)で転送成功を二重確認

  • 日付付きファイル名で履歴管理を容易に


まとめ

  • HULFT自体は大容量に強く、理論上は数TB〜EBまで対応可能

  • 実効速度は 回線帯域 × バッファ調整 × 再送設定 がカギ

  • 100MBなら数秒、1GBなら十数秒〜数分 が目安

  • HULFTは最高速よりも「確実性・運用性」を重視する製品

  • バッファ拡張・並列化・部分再送 で安定高速な運用が可能

HULFTで「完了コード250 エラー」が発生したときの対応手順

HULFT (UNIX/Linux 環境) でファイル配信を行った際、「完了コード250」が返されることがあります。公式ドキュメントではこのコードを “A server error” としており、集信側(受信側)で異常が発生したことを示しています。⇒ HULFT

本記事では、完了コード250の意味、原因、公式で推奨されている対処方法、実践的なチェックポイント、および再発防止策をまとめます。


完了コード250とは?

項目 内容
エラーコード 250
英語名称 A server error HULFT
意味 「集信側に異常が発生したと考えられます」 HULFT
詳細 完了コード250が設定された場合、さらに 詳細コード が設定されており、それが集信側の完了コードとなります。 HULFT

つまり、完了コード250は「送信側から配信は試みられたが、受信側で何かしら正常でない処理が起きて失敗した」ということを示す総称的なエラーで、原因の切り分けには “詳細コード” を見る必要があります。HULFT


主な原因(公式の可能性を含む)

ドキュメントに明記されている「完了コード250 → 集信側に異常が発生」の具体的な事例としては以下があげられます。これらは「詳細コード」によってどのような異常かが特定されます。HULFT

  • ディスク容量不足など、受信側で書き込みができない状態 HULFT

  • ファイルアクセス権限エラーやファイルロック状態 HULFT

  • テキスト転送で「1 レコードのデータ長が最大値を超えている」 HULFT

  • 配信途中でファイルの編集や移動・削除など、ファイルの整合性が保てなくなる操作が行われた場合 HULFT

  • フォーマットミスマッチ・バージョン不一致など、データ形式やコードセットに関する不整合 HULFT


対応手順(公式の指示+実践的対応)

以下は、公式ドキュメントの「対処(処置)」に加えて現場でよく使われるチェック項目を織り交ぜた手順です。


ステップ 1:ログ・詳細コードの確認

  • HULFT の hulogtrnlog もしくは配信ログを確認

  • 完了コードが 250 の行を探す

  • その行に 詳細コード(集信側の完了コード)が記録されているか確認 HULFT

  • 詳細コードに応じて原因の方向性を絞る


ステップ 2:受信側(集信側)の環境チェック

以下を重点的に確認します。

項目 チェック内容
ディスク容量 受信ディレクトリのあるファイルシステムの空き容量を確認
ファイルアクセス・ロック 該当ファイル名が他プロセスにより使用中でないか、書き込み権限があるか
ファイル操作 配信中に受信側でファイルを移動・削除・名前変更などしていないか
フォーマット・レコード長 テキスト転送時に1レコードの長さが制限(32768バイト)を超えていないかなど HULFT
バージョン・コードセット 転送や受信のフォーマット定義、文字コード変換などが正しく一致しているか

ステップ 3:通信経路・送受信設定の確認

  • ネットワーク切断、遅延、ファイアウォールによる通信遮断等の影響がないか

  • 送信側・受信側両方の HULFT 定義(配信パラメータ、フォーマットID、文字コードなど)が整合しているか

  • マウントされているネットワークファイルシステム(NFS等)を使っている場合、属性キャッシュやマウントオプションが影響していないか確認 HULFT


ステップ 4:修正・再実行

  • 問題箇所が見つかったら修正(空き容量確保、権限修正、ファイルの整合性維持、フォーマット修正など)

  • 修正後、再度配信ジョブを実行

  • 再送前に、テスト環境や限定ファイルで動作を確認できるならそれを行う


再発防止策

公式仕様と実践双方から以下が有効です:

  1. 監視体制の整備

    • ディスク容量の自動監視

    • ファイルシステムの状態/マウントオプションの監視

    • HULFT ジョブのステータス監視(完了コードを含む)

  2. 設定の標準化とレビュー

    • フォーマット定義・文字コード・レコード長などをドキュメント化

    • 新しいノードや定義を追加する際のチェックリストを整備

  3. テスト運用

    • 転送前に小さなデータでテスト送受信を行う

    • 大容量/長レコード/特殊文字を含むデータの事前検証

  4. エラー通知システムの活用

    • 完了コード250やその詳細コードをトリガーにアラートをあげるように設定

    • 関係者に通知が行くようにすることで早期対応


ケーススタディ(想定例)

例 1:テキストファイルの 1 レコードが長すぎる

  • ある送信ジョブで、伝票データを1行にまとめすぎてしまい、1 レコードの文字数が制限(32,768バイト)を超えていた → 詳細コードが 251 の可能性あり。HULFT

  • 対策:レコードを分割するか、フォーマットを見直す

例 2:受信側のディスクフル

  • 受信サーバ上のディスク容量がゼロ近く、書き込みができずにエラー

  • 対策:不要ファイルの削除、ディスク拡張、ログのローテーション設定など


まとめ

  • 完了コード 250 は「受信側での異常」を示し、詳細コードにより原因の絞り込みが可能

  • ログの確認 → 環境チェック → 設定見直し → 修正・再実行が基本の流れ

  • 再発防止のための監視・標準化・テストが重要

HULFTでCSVをバイナリ指定するとどうなる?使い方と注意点まとめ

はじめに

企業間やシステム間のデータ連携でよく利用されるファイル転送ソフトウェア「HULFT」。日常的にCSVやログファイルをやり取りしている方も多いと思います。
その際に必ず出てくるのが「ファイルモードの指定」。HULFTには 「テキスト指定(レコード指定)」「バイナリ指定」 の2種類があり、どちらを使うべきか迷うケースが少なくありません。

本記事では 「CSVをバイナリ指定で送った場合どうなるのか?」 を中心に、メリット・デメリットや注意点を整理します。


バイナリ指定とは?

HULFTにおける「バイナリ指定」とは、ファイル内容を1バイト単位のデータとしてそのまま送受信するモードを指します。
この場合、HULFTは以下のような変換や処理を一切行いません。

  • 改行コードの変換(CRLF⇔LFなど)

  • 文字コードの変換(Shift-JIS⇔UTF-8など)

  • レコード単位の制御(固定長・可変長)

つまり「HULFTが何も手を加えずにコピーする」のがバイナリ指定です。


バイナリ指定のメリット

  1. 内容がそのまま届く
    改行コードや文字コードが勝手に変換されないため、送信元のデータを完全に保持できます。

  2. ファイル形式を問わない
    CSVに限らず、Excel、PDF、ZIP、画像ファイルなども問題なく転送可能。
    → そのため「とりあえず壊れたくないファイルはバイナリ指定」で安全に扱えます。

  3. 異なるOS間でも安心
    WindowsからLinux、Linuxからホスト系など、環境差異を気にせず転送できます。


バイナリ指定のデメリット

  1. 文字コード変換がされない
    送信側がShift-JIS、受信側がUTF-8を前提としている場合、そのままでは文字化けします。

  2. 改行コードもそのまま
    WindowsのCSV(CRLF)をLinuxで処理すると、アプリ側がLFを期待していた場合に不具合の原因になります。

  3. レコード単位の扱いができない
    COBOLやホストシステム連携など「固定長レコード前提」のファイルを扱う場合は不向きです。


CSVをバイナリ指定で送るとどうなる?

結論から言うと、基本的に悪影響はありません
CSVは単なるテキストファイルですが、HULFT側で勝手に改行コードや文字コードを変換しないので、送信元と全く同じファイルが届きます。

ただし以下のケースでは注意が必要です。

  • 文字コードが異なる場合
    送信元がShift-JIS、受信先がUTF-8で解析 → 文字化けの可能性あり。

  • 改行コードが異なる場合
    Windowsで作成したCSVをLinuxで使うと、改行が意図通りに扱えないことがある。

そのため「受信側のシステムがどの文字コード・改行コードを想定しているか」を事前に確認しておくことが大切です。


まとめ

  • バイナリ指定は「ファイルをそのまま送りたいとき」に有効。

  • CSVを送る場合も基本的に問題はないが、受信側の文字コードや改行コードの前提条件によっては注意が必要。

  • 迷ったらまずは「バイナリ指定」で送り、必要に応じて受信側で変換処理を入れるのが無難です。


👉 実際の業務では「相手先がどんなシステムで受けるのか」を確認してから指定するのが鉄則です。
もし「文字コード変換が必要」や「固定長レコード前提」のような要件がある場合は、バイナリ指定ではなくテキスト指定を選ぶ方が安全です。

Windowsバッチで西暦8桁・月日2桁のゼロ埋め日付を出力する方法

バッチ処理を作成するときに、ログファイル名やバックアップファイル名に日付を付与するケースはよくあります。その際「20250913」のように 西暦8桁(YYYYMMDD形式) でゼロ埋めされた日付を出力したいことがあります。
この記事では、Windowsバッチでゼロ埋めした日付を取得する方法を紹介します。


基本的な考え方

Windowsバッチでは %date% 変数を使うことで、現在の日付を取得できます。ただし環境によって表示形式が異なり、例えば以下のようになります。

  • 日本語ロケール(Windows 10/11 既定)

    2025/09/13
  • 英語ロケール

    Sat 09/13/2025

このため、文字列の位置を指定して切り出す必要があります。


実用例:西暦8桁+月日2桁のゼロ埋め

以下のバッチスクリプトでは、YYYYMMDD 形式で日付を取得します。

実行結果(2025年9月13日の場合)

20250913

応用:時刻と組み合わせて使う

ファイル名などで「日付+時刻」を付けたい場合は、%time% も組み合わせられます。

実行例

20250913_083015

ロケールに依存しない方法

環境によって %date% のフォーマットが変わるとバッチが動作しなくなることがあります。
その場合、wmic を使うとロケール非依存で日付を取得できます。

実行結果

20250913

まとめ

  • %date% を切り出す方法は簡単だがロケール依存。

  • 確実性を求めるなら wmic を使うのがおすすめ。

  • 日付はログやバックアップのファイル名に利用すると便利。

バッチで日付をゼロ埋めして扱うと、ファイルの並び順も自然になり管理がしやすくなります。
ぜひ日常の運用バッチに取り入れてみてください。

HULFTで日付付きファイルを配信元ファイル名のまま受信する方法

HULFTを使ったファイル連携では、バッチ処理などで日付が付与されたファイル名を扱うケースが多くあります。
例えば、送信側で以下のように日付が付与されたファイルを生成する場合です。

sales_20250911.csv
sales_20250912.csv

受信側でもこのファイル名をそのまま維持して保存したい、という要件はよくあります。
本記事では、その場合に利用できる HULFTの動的パラメータ $SNDFILE を使った方法を解説します。

$SNDFILEとは?

HULFTには送受信時に利用できる動的パラメータが用意されています。
その中の一つが $SNDFILE で、これは 「送信元ファイル名」 を表します。

つまり $SNDFILE を指定することで、送信側が持つ実際のファイル名を受信側でそのまま利用することが可能です。


設定例

受信側(集信定義)の「受信ファイル名」に $SNDFILE を指定します。

C:\recv\$SNDFILE

この設定を行うと、送信されたファイル名のまま受信先に保存することが出来ます。

例:送信元のファイルが sales_20250911.csv の場合

  • 配信元: /data/sales_20250911.csv

  • 受信定義: C:\recv\$SNDFILE

  • 保存結果: C:\recv\sales_20250911.csv


利用上の注意点

  • 受信先でファイル名を固定して指定すると上書きされる
    例えば C:\recv\sales.csv のように固定名を指定した場合、複数ファイルを送信すると最後のファイルで上書きされてしまいます。
    $SNDFILE を使うことで、送信元ファイルごとに別々のファイルとして受信できます。

  • 動的パラメータが有効になっている必要がある
    $SNDFILE はHULFTの動的パラメータ機能を利用するため、システム環境設定で動的パラメータが有効化されていることを確認してください。

  • ディレクトリは固定、ファイル名だけ動的
    C:\recv\ 部分は固定ですが、ファイル名部分に $SNDFILE を置くことで柔軟に対応可能です。


まとめ

  • $SNDFILE を使うことで、送信元のファイル名をそのまま受信側に引き継げる。

  • 日付付きファイルや動的に生成されるファイル名を扱う場合に便利。

  • 受信定義に C:\recv\$SNDFILE のように設定するだけで利用可能。

HULFTの運用では「配信元のファイル名をそのまま使いたい」という要件は多いため、覚えておくと便利なテクニックです。

リモートデスクトップでの接続前に事前に接続済ユーザーの有無を確認する方法

複数人開発メンバーがいる状況などで共通で使用しているアカウントでリモートデスクトップ接続する可能性がある場合、リモートデスクトップでの接続は基本後勝ち方式になってしまうため、先に誰かがリモートデスクトップで接続していると後発ユーザーが権限奪ってしまい先に使用している人へ迷惑をかけてしまう可能性があります。

なのでリモートデスクトップで共通で使用しているアカウントでログインする場合は事前にアクティブ状況は最低限確認しておきましょうというお話。

事前に接続先サーバーへのログインユーザーのアクティブ状況を確認する方法

  1. コマンドプロンプトを起動して「qwinsta /server:[接続先のサーバー名]」を入力して実行します。
  2. 以下の様に状態へ「Active」と表示されていれば該当ユーザーでログイン中となっているのが確認出来るので、そのユーザーでリモートデスクトップ接続する前に周囲にいつまで使用予定なのかなどを確認してから使用すると不要な摩擦を生むのを回避出来ます。

補足:運用時の注意点

  • 管理者権限が必要
    接続中ユーザーを確認するには管理者権限が必要な場合があります。特に query user コマンドや qwinsta コマンドを利用する際は、一般ユーザー権限では表示されないことがあります。

  • 強制ログオフのリスク
    他ユーザーが接続中の状態で強制的にログオフさせると、未保存データが失われる恐れがあります。運用ルールとして、必ず事前に通知・了承を得てから切断するようにしましょう。

  • 複数ユーザー環境での考慮
    Windows Server 環境などでは複数ユーザーの同時接続が可能な場合もありますが、通常の Windows 10/11 Pro では基本的に 1 ユーザーのみのリモート接続が許可されます。環境ごとに仕様を確認しておきましょう。

  • 自動化の工夫
    バッチファイルや PowerShell スクリプトに query user を組み込むことで、接続前にワンクリックで確認できる仕組みを整えると便利です。例えば、以下のようにログイン状況を出力する簡易スクリプトを作成できます。

     

ワイヤレス トラックボールマウスが快適すぎた件

以前まではマウスにはそこまでこだわりがない方だったので光学式の安物を使用してましたが、リモートワークなどでPC操作時間が増えてくるとマウス操作で地味に手首に負担がくるのが気になってきたので意を決してトラックボールマウスを購入してみることにしました。

そこで半年位前に購入してみたのが

ロジクールの「トラックボールマウス ワイヤレス マウス windows mac iPad M575」です。

Amazonの「ロジクール ワイヤレスマウス トラックボール 無線 M575GR」ページへ

「トラックボールマウス ワイヤレス マウス windows mac iPad M575」の特徴

  • 発売日:2020/11/26
  • 参考希望小売価格:6,050円
  • 接続方式:無線アドバンス2.4GHz Unifying-USB、Bluetooth
  • メーカー:Logicool(ロジクール)
  • 対応機種:IPad, Windows, Mac
  • モデル番号:M575GR ※最新モデル(2021年12月購入時点)
  • 製品サイズ:10 x 13.4 x 4.8 cm
  • 重量:145 g
  • 「傾斜角度が付いたスクロールホイールで指をより自然で快適な位置にホールド/幅広い手の大きさにフィット」

 

トラックボールマウスの使用感

  • 購入後1ヶ月位は正直トラックボールでのマウスポインタ操作にかなり違和感がありました。
  • 購入後2,3ヶ月でだいぶ違和感がとれてきて、半年経った今では全く違和感なくなり以前のマウスは使う気がしなくなっちゃいましたw
  • 付属で「電池寿命最大24ケ月 グラファイト 国内正規品」も付いてきており未だに電池切れは起こしてないので2年持つというのも誇大広告ではなさそうです。
  • 1ヶ月位でトラックボールの滑りが悪くなってくるのでボールを外してほこりや垢を掃除すれば問題なく使えます。
  • 掃除の際にトラックボールにクリポリメイト(光沢剤)などを吹きかける事でさらに滑りがよくなります。

結論

  • 買って良かった!リモートワークがますます快適にw
  • まだトラックボールマウスを使用したことがなく、マウス操作で腱鞘炎などで手首が疲れてる自覚がある方には購入して損はないです。
  • 最初の違和感さえ克服すれば後は快適です♪
    Amazonの「ロジクール ワイヤレスマウス トラックボール 無線 M575GR」ページへ

「.com」ドメインは今後も毎年値上がりする可能性大!

本日、レンタルサーバー会社からドメイン料金改定(要はドメイン料金値上がり)のお知らせが届いてました。。

こんなところにも値上がりの波が!?

とメールを見てみるといきなり3割以上も値上がりしてます。。

ドメイン料金なので1年で2614円と考えれば大した金額でもないのですが、突然何故?と思っているとメール文中に「上位組織から提示されるドメイン料金の上昇」と記載されています。

上位組織?と思って調べてみたら

「.com」ドメインのレジストリ管理企業であるVerisignha社(ベリサイン社)は
2020年1月3日にICANNにより公開された「.comレジストリ契約の修正に関する発表」により、
2020年から2029年までの10年間、年間7%・最大70%値上げを行う権利を認められてるとの事。
上記に基づき、Verisign社は2021年9月1日から約7%の卸価格値上げを決定しています。

というのが背景となってました。

メール見てそのまま1年更新でいいかあ程度に考えてましたが、今後も毎年値上げが実施される可能性大というのも考慮すると今のうちに複数年契約した方が良いと判断して最大の5年契約に変更しました。

今後も「.com」ドメインを長期使用予定の方は契約年数を見直したほうがお得かも