 |
「BUS STOP 降車場 オオイタバス（OITA BUS）」という看板があるが、ここは「大分（パルコ前）」というバス停で、古宮バス停から乗ったバスの終点だった。 |
| （撮影：11時16分） | |
 |
バスが大分駅の目の前まで行ってくれなかったのは残念だが、大分駅は、ここから歩いて3分程度だと思うので、特に問題はないだろう。 |
| （撮影：11時16分） |
 |
大分バスのバス停「大分（パルコ前）」から歩道を1分も歩かないうちに「大分駅前地下道」の入口が現れた。 ここを通って大分駅に行くことにする。 |
| （撮影：11時18分） | |
 |
「大分駅前地下道」から大分駅に至る階段には、大分県のマスコットキャラクター「めじろん」が描かれていた。 今から大分駅で列車に乗って旅立つ人々に向けて「行ってらっしゃーい」と手を振っているように見える。 私は大分駅に向かうため、この階段を上った。 |
 | |
| （撮影：11時19分） | |
 |
「大分駅前地下道」から地上に出ると、大分駅（北口）が目の前にある。 これから、大分駅構内まで歩く。 |
| （撮影：11時21分） |
 |
大分駅（北口）に「カレーヤ 駅前店」というカレー屋さんを見つけた。 ここでお昼御飯を食べることにした。 |
| （撮影：11時35分） | |
 |
ビーフカレー（450円）を食べた。 |
| （撮影：11時37分） |
 |
大分駅構内の改札口前。 |
| （撮影：11時49分） | |
 |
大分駅3番ホーム。 |
| （撮影：11時51分） | |
 |
切符は、駅のみどりの窓口で購入した。
特急券は途中出場できません |
| （撮影：11時52分） | |
 |
「九州横断特急 185DC」が3番ホームに入ってきた。 |
| （撮影：11時53分） | |
 |
「九州横断特急 185DC」は全身が真っ赤で綺麗な車体だ。 私は今からこの列車に乗って熊本に向かうことになる。 |
| （撮影：11時54分） | |
 |
「九州横断特急 185DC」の車内。 客車への入口のドアや周囲の壁はオシャレな紫色。 |
| （撮影：11時55分） | |
 |
客車内の床、椅子の肘掛、窓のサッシなどは明るい木目調。全体的に明るい感じで気持ちが良い。 |
| （撮影：11時55分） | |
 |
途中の駅で、大分行きの「220DC」（同じく赤い車体）とすれ違う。車体に「DIESEL CAR」と書いてあるので、ディーゼル車か・・・ということに今頃気づく。 |
| （撮影：12時02分） | |
 |
窓のサッシには、ペットボトル等の飲み物を置けるコースターのような丸い窪みがついていて、便利だった。 |
| （撮影：12時17分） |
root権限でLinuxにログインしてコンソールで作業をしていると、以下のようなメッセージが表示されることがある。
You have mail in /var/spool/mail/root
現在ログイン中のLinuxのcronで実行しているプログラムにエラーがある時などにroot宛にメールが届く仕組みがあるのだが、そのメールが「/var/spool/mail/root」に届いたよ、と知らせてくれているのが上記のメッセージ。
メールは、
vi /var/spool/mail/root
のようにviエディタでテキストファイルとして閲覧することもできるし、
mail
のようにmailコマンドで閲覧することができる。
このroot宛に届くメールは、トラブル発生有無、トラブル状況確認などに使えるが、Linuxをインストールした初期状態ではLinuxにログインしないとメールを閲覧することができない。これでは、トラブルにすぐに気づきたい場合には不便だ。
そこで、外部のメールアドレス宛にメールを転送する設定を行えば、Linuxサーバにログインしなくてもroot宛のメールを気軽に確認できるようになるので便利。メールソフトを常に起動しておき、1分間隔でメールを受信するような設定にでもしていれば、1分以内に異常に気づく。24時間監視とか、外出先でもすぐにでも異常に気づきたい、という場合は、携帯メールアドレス宛にメールが届くようにすればよいと思う（苦笑）。
以下は、root宛に届くメールをプロバイダ等の外部のメールアドレス宛に転送する設定メモ。
(1)Linuxにログインし、/etcディレクトリに移動する。
cd /etc
(2)/etc/aliasesが存在することを確認
ls -ahl | grep aliases
-rw-r--r-- 1 root root 1.5K 4月 26 2005 aliases
-rw-r----- 1 root smmsp 12K 5月 01 05:01 aliases.db
(3)/etc/aliasesを修正する。
vi aliases
/etc/aliasesの中身（例）
-----------------------------------------------------------------------
## Aliases in this file will NOT be expanded in the header from
# Mail, but WILL be visible over networks or from /bin/mail.
## >>>>>>>>>> The program "newaliases" must be run after
# >> NOTE >> this file is updated for any changes to
# >>>>>>>>>> show through to sendmail.
## Basic system aliases -- these MUST be present.
mailer-daemon: postmaster
postmaster: root
# General redirections for pseudo accounts.
bin: root
daemon: root
adm: root
lp: root
sync: root
shutdown: root
halt: root
mail: root
news: root
uucp: root
operator: root
games: root
gopher: root
ftp: root
nobody: root
radiusd: root
nut: root
dbus: root
vcsa: root
canna: root
wnn: root
rpm: root
nscd: root
pcap: root
apache: root
webalizer: root
dovecot: root
fax: root
quagga: root
radvd: root
pvm: root
amanda: root
privoxy: root
ident: root
named: root
xfs: root
gdm: root
mailnull: root
postgres: root
sshd: root
smmsp: root
postfix: root
netdump: root
ldap: root
squid: root
ntp: root
mysql: root
desktop: root
rpcuser: root
rpc: root
nfsnobody: root
ingres: root
system: root
toor: root
manager: root
dumper: root
abuse: root
newsadm: news
newsadmin: news
usenet: news
ftpadm: ftp
ftpadmin: ftp
ftp-adm: ftp
ftp-admin: ftp
www: webmaster
webmaster: root
noc: root
security: root
hostmaster: root
info: postmaster
marketing: postmaster
sales: postmaster
support: postmaster
# trap decode to catch security attacks
decode: root
# Person who should get root's mail
#root: marc
-----------------------------------------------------------------------
※以下のように最後の1行を変更する
＜修正前＞
# Person who should get root's mail
#root: marc
＜修正後＞
# Person who should get root's mail
#root: marc
root: 転送先のメールアドレス
※例えば、r_nobu@h8.dion.ne.jpにメールを転送する設定をしたいのであれば、
root: r_nobu@h8.dion.ne.jp
となる。
なお、root宛以外のメールを転送することも可能。
もし、nekoというユーザがいるのであれば、
neko: r_nobu@h8.dion.ne.jp
とすることで、neko宛に届くメールをr_nobu@h8.dion.ne.jp宛に転送することができる。
(4)設定を反映する。
「/etc/aliases」をviエディタで修正して上書き保存が終了したら、以下を実行して設定を反映する。
newaliases
(5)転送先のメールアドレス宛にメールが届くようになったことを確認。
以上。
タイムスタンプ型のカラムをlikeでパターン検索する時にPostgreSQL 7.4とか8.1とか8.2では適当なSQL文にしていても動作していたのだが、8.3だとSQL文を厳密にしないと動作しなくなった。
例えば、以下のようなSQLを実行したとする。
select * from nobuneko_table where nobuneko_time like '%-%-%';
※この例では、「nobuneko_time」がタイムスタンプ型のカラムで、このカラムには例えば「2010-05-02」といったような値が入る。
8.3よりも前のバージョンだとこの書き方でも結果が返っていたのだが、8.3だと以下のようなエラーになってしまう。
operator does not exist: timestamp without time zone ~~ unknown
likeは文字列検索なのにタイムスタンプ型のカラム「nobuneko_time」で検索しようとしているため、型の不一致で上記のようなエラーが発生している。8.3より前のバージョンだとPostgreSQL側が自動的に型を変換（キャスト）してくれていたのだが、8.3では自動的にキャストしてくれなくなったようだ。従って、PostgreSQL 8.3では、自分で明示的にキャストするようなSQL文を書く必要がある。
まとめると、以下のようになる。
＜PostgreSQL 7.4とか8.1とか8.2＞
select * from nobuneko_table where nobuneko_time like '%-%-%';
タイムスタンプ型の「nobuneko_time」がテキスト型に自動的にキャストされるため、このSQLでも結果が返る。
＜PostgreSQL 8.3＞
select * from nobuneko_table where nobuneko_time like '%-%-%';
タイムスタンプ型の「nobuneko_time」がテキスト型に自動的にキャストされないため、このSQLでは以下のようなエラーとなる。
operator does not exist: timestamp without time zone ~~ unknown
※8.3よりも前のバージョンのように自動的にキャストされないのであれば、SQL文のタイムスタンプ型のカラムの直後に手動で「::text」を追記して明示的にキャストすればよい。
※今回の例では、以下のようにすればエラーが出なくなる。
select * from nobuneko_table where nobuneko_time::text like '%-%-%';
また、上記と同様にto_timestampを使用する時もキャストする必要がある。
例えば、8.3よりも前のバージョンだと問題なかったのだが、
to_timestamp(current_date, 'YYYY/MM')
とすると、8.3では
function to_timestamp(date, unknown) does not exist
とか
operator does not exist: text >= date
といったエラーになる。
そこで、
to_timestamp(current_date::text, 'YYYY/MM')
といったように明示的にテキスト型にキャストする必要がある。
以上。
PHPのエラーメッセージをエラーログ（テキストファイル）として出力したい場合は、php.iniファイルのerror_logでエラーログの出力場所（出力先）を設定すればよい。
（1）php.iniの現状設定を確認する。
（php.iniの保存先が分からない場合は、phpinfoで確認すること。）
php.iniファイルの一部（Windows版PHP5.2.0例）-----------------------
; - Show all errors, except coding standards warnings
;
error_reporting = E_ALL
《略》
; Log errors to specified file.
;error_log = filename
; Log errors to syslog (Event Log on NT, not valid in Windows 95).
;error_log = syslog
------------------------------------------------------------------
※「error_reporting」でエラーが表示される設定になっていることを確認する。
※「error_log」の設定が有効でない場合はログが出力されていない。この設定の時、phpinfoで確認するとerror_logはno valueとなっている。
（2）php.iniの設定を変更する。
例えば、「;error_log = syslog」の記述の直後あたりに
error_log = "D:\phplog\error.log"
と追記し、Apacheを再起動すれば、Dドライブのphplogフォルダにログが出力されるようになる。
※phpinfoで確認してerror_logが指定したフォルダ名（例ではphplog）となっていることを確認する。
※「D:\phplog\error.log」の「phplog」というフォルダ、「error.log」というファイル名は私が適当に作成したでフォルダ名、ファイル名は任意に指定可能。
Apacheを使用することが前提だが、PHPのinclude_pathをphp.iniではなく、.htaccessファイルで指定することも可能。
.htaccess内に「php_value include_path」を記述すればよい。
《例》
php_value include_path ".:/var/www/nobuneko/httpdocs/abc/php/include"
※上記例の場合、「/var/www/nobuneko/httpdocs/abc/php/include」内にインクルードさせたいファイルを設置する。
Linuxのコンソール、Windowsのコマンドプロンプト等でコマンドラインでPHPを実行するには、以下のようにする。
＜Linux＞
/usr/bin/php -r '実行したいPHPのプログラムコード'
＜Windows＞
php -r "実行したいPHPのプログラムコード"
※Windowsの場合、Linuxのように「実行したいPHPのプログラムコード」を'（シングルクォーテーション）で囲んで実行すると、
Parse error: parse error, unexpected $end in Command line code on line 1
といったエラーになってしまうので、"（ダブルクォーテーション）にする。
《例》
＜Linux＞
/usr/bin/php -r 'echo date("Y-m-d H:i:s");'
＜Windows＞
php -r "echo date('Y-m-d H:i:s');"
《結果》
コンソールまたはコマンドプロンプトの画面に上記コードの実行結果（例えば「2010-05-04 17:53:39」）が表示される。
また、上記例のように実行するPHPのプログラムコードが画面に文字等を出力するものであれば、「>」（大なり記号）を使用することで、任意の場所に出力結果をテキストファイルとして出力することもできる。
＜Linux＞
/usr/bin/php -r '実行したいPHPのプログラムコード' > 出力場所
＜Windows＞
php -r "実行したいPHPのプログラムコード" > 出力場所
《例》
＜Linux＞
/usr/bin/php -r 'echo date("Y-m-d H:i:s");' > /var/www/nobuneko/httpdocs/testdate.txt
＜Windows＞
php -r "echo date('Y-m-d H:i:s');" > D:/testdate.txt
《結果》
指定したディレクトリ（上記例ではLinuxなら「/var/www/nobuneko/httpdocs/」、WindowsならDドライブ直下）に上記コードの実行結果（例えば「2010-05-04 17:53:39」）を記述したテキストファイルtestdate.txtが出力される。
PostgreSQLでpg_dumpをしようとすると、以下のようなエラーが起きることがある。
pg_dump: dumpClasses(): SQL command failed
pg_dump: Error message from server: ERROR: invalid memory alloc request size 4294967293
pg_dump: The command was: FETCH 100 FROM _pg_dump_cursor
このエラーが起きた時に「invalid memory alloc request size 4294967293」というメッセージを見て「PostgreSQLの共有メモリなどメモリ関連の設定がおかしいのかなぁ？メモリが不足しているということ？PostgreSQLが使えるメモリの割り当てを増やせばいいのかなぁ」などと思ってメモリの設定値を色々変えてみたりしたのだが、全く効果がなかった。
そこで、検索サイトで「invalid memory alloc request size 4294967293」で検索すると、以下の記事が見つかった。
BUG #2534: ERROR: invalid memory alloc request size 4294967293
http://archives.postgresql.org/pgsql-bugs/2006-07/msg00072.php
《略》
While executing pg_dump command, I am getting the following errors. Plz
help me to solve the problem.
pg_dump -O magellan >
magellan_154_db_postgres_10july2006_1149amist.sql
pg_dump: ERROR: invalid memory alloc request size 4294967293
pg_dump: SQL command to dump the contents of table "ctblankcall" failed:
PQendcopy() failed.
《略》
おー、まさに同じようなエラー。
しかし、この質問にはレスが付いていないので、これだと原因は分からない。
結局、このエラーが起きる根本的な原因は分からなかったのだが、とにかくpg_dumpしたかったので、以下の方法で無理やり解決した。
（1）pg_dumpに失敗するデータベースが持つ各テーブルを個別にpg_dumpし、pg_dumpに失敗するテーブルを特定する。
（2）pg_dumpに失敗するテーブルが特定できたら、さらに「select * from テーブル名 where 絞込条件」で検索に失敗するレコードを特定する。
（3）検索に失敗するレコードを特定できたら、さらに「select カラム名1 from テーブル名 where 絞込条件」のように検索に失敗するカラムを特定する。
※「select カラム名1 from テーブル名 where 絞込条件」で検索に成功したら「カラム名1」は問題なし、同じwhere句で「select カラム名2 from テーブル名」とした時に検索に失敗したら、「カラム名2」に問題あり、と特定できる。
（4）問題が生じているカラムを適当な値でupdateする。
全ての不適切なカラムの値を適切な値でupdateすることでpg_dumpできるようになる。
※（3）〜（4）あたりは、以前書いた以下の記事とほぼ同じ。
《参考》
PostgreSQLのエラー「timestamp out of range」と「FETCH 100 FROM _pg_dump_cursor」の原因と解消方法について
この記事の時は、ある1つのテーブルの1つのカラムに不適切な値が入ってしまったことがほぼ確実で、PostgreSQLデータベースに値を渡すPHPプログラム側のバグの可能性が高い、と推測できた。そのため、PHPプログラムのバグ記述も修正したので今後再発する可能性は低いと思って安心している。
一方、掲題の件のエラーは、調査の結果、複数のテーブルで不適切なカラムが数箇所見つかったことにより、プログラムの不具合の可能性はゼロではないにしろ、考えにくいと思った。その他に考えられそうな原因は、Linuxのsyslogにハードディスクのエラーが出ていたので、ひょっとしたら、PostgreSQLデータベースを構成するファイルの一部が欠損してしまったのかなぁ、というPostgreSQLとは直接は関係のない世界での原因。推測の域を出ないが、ハードディスクエラーが出ている時点で全部それが原因に思えてきたので、これ以上の調査は無駄に思えたのでやめた（もう検索サイトではあらかた調べつくして他に考えられうる原因がなかったこともあるが・・・）。今度、同じエラーが出た時にハードディスクエラーが出ていなければ、その時はその時で調査・・・。
先週からの肩こりがひどくなってきて木曜日の朝出勤する時には痛みが内太股にまで及んでいた。出勤はしたのだけれど、午前中、痛みのため仕事にほとんど集中できず。まさか肩こりがこんなにひどくなるとは・・・と思いながら、昼休みまで頑張ってみた。
昼休みになると家にいったん帰宅。
頭痛がひどくなっていたので、これはひょっとして熱でもあるのか？と思って体温計で熱を測ってみると38.5度あった。肩こりは先週からひどかったので、いつから熱が出ていたのかは定かではないが、熱が出ていることにも気づかないまま出勤してしまうとは・・・。いつひいたのか分からない風邪で熱を出したのか、肩こりがひどくなって熱が出たのかがよく分からないが、とにかく熱があるようで、びっくりした。
その時、一番気になっていたことは、その日の午後に予定を入れていた健康診断。この健康診断は本当は昨月に行う予定だったのだが、急な出張など仕事の都合で2回もキャンセルしていて、今日キャンセルすると3回目。キャンセルしたくないなぁ、と思って健康診断の注意事項を読んで見ると、「発熱のある人はダメ」みたいなことは記載がなかったので、ひょっとして発熱していてもOKなのだろうか？と思って健康診断を受けてみようかと、思った。
妻に相談してみると、普通は熱があったらダメなんじゃない？と言われ、そうかもなぁ、と思って病院に電話してみると、電話に出た看護師さんに困った声で「発熱がある場合は血液検査等の結果が正しく出ないかもしれないので、発熱がない時に来てください」と言われた。そこで仕方なく、健康診断をキャンセル。
健康診断のために朝は軽食、飲み物は水のみ、昼は絶食という食事制限にしていたのだが、その食事制限が何の意味もなかった。もう家で御飯を食べる時間が残っていなかったため、会社に戻る道すがら、コンビニに寄って元気の出そうな紙パックの飲み物とこれなら食べられそうと思った普段なら絶対買わないサイズのミニ手巻き寿司を買って食べた。
その後、定時までが異常に時間が長く感じられた。いつもなら電話がガンガン鳴って対応に追われたり、トラブルのために時間がどんどん過ぎ去るのだが、その日に限ってこの1年以上もの間でありえないぐらいの平穏な一日。いや、もちろん、平穏な一日の方が良くて、いつも平穏な一日になることを願っているし、トラブルだったら、体調不良という理由でも定時きっかりに帰るのが後ろめたくなるし・・・。とにかく、平穏な一日のおかげで時間が経つのが異常に遅くてつらかったが、逆に定時きっかりで会社を出て速攻で帰宅して休むことができた。
それからは晩御飯も食べずポカリスウェットだけ飲んで寝ていると翌朝の午前4時には37.3度ぐらいまで熱が下がり、朝7時半には36.4度になっていた。
肩こりもマシになっていて、内太股の痛みは消えていたので、金曜日は休まず仕事をしてみた。その日も定時に帰るつもりだったが、何故か昨日と比べて体が楽になったせいか結局20時までは仕事してしまった・・・。
土曜日の今日、日曜日の明日は仕事は休み。丸2日とも自宅で静養していようと思う。肩こりを治さないとなぁ・・・。
さて、次はいつ健康診断の日程を入れようかと悩み中・・・。
PHPの関数str_repeat()は、第1引数に文字列、第2引数に0以上の数値を指定して、第1引数の文字列を第2引数で指定した回数分繰り返すことができる。
《書式》
str_repeat(文字列,繰り返し数)
《例》
$str = "*";
echo str_repeat($str,"5");
とすれば、「******」が表示される。
ここで、誤って第2引数を指定せず、str_repeat($str)とすると、以下のエラーが表示される。
Warning: Wrong parameter count for str_repeat()
（r_nobu適当訳）str_repeat()に渡している引数の数に誤りがあります。
このエラーは、第2引数をきちんと指定してやると表示されなくなる。しかし、指定する値は0以上の値でないと別のエラーが表示される。例えば、試しに-1を指定すると以下のエラーが表示された。
Warning: str_repeat() [function.str-repeat]: Second argument has to be greater than or equal to 0.
（r_nobu適当訳）関数str-repeatの第2引数は0以上の値にする必要があります。
psqlでSQLファイルを指定して実行した際に、「invalid byte sequence for encoding "EUC_JP"」といったエラーが出る時がある。
《例》
psql:test.sql:2001: ERROR: invalid byte sequence for encoding "EUC_JP": 0x93ab
この例の場合、psqlでtest.sqlというファイルを指定して実行したところ、EUC_JPの文字エンコーディングでは無効なバイト列「0x93ab」がtest.sqlの2001行目で見つかった、というエラーのようだ。
このような場合の多くが、psqlで読み込もうとしたファイルの中で記述している文字のコードに誤りがある。例えば、ファイルの中身の文字列全てをEUC_JPの文字コードにしておくべきところを、SHIFT_JIS（シフトJIS）など別の文字コードを混在させてしまった場合だ。多くの場合、問題となるのはSHIFT_JISの機種依存文字だと思う。
今回の例のように、EUC_JPファイルの中にSHIFT_JISが混在してしまった文字化けファイルを修正する場合、以下の手順で修正できる可能性がある。
1 テキストエディタ（秀丸エディタ等）でEUC_JPとしてファイルを開き、PostgreSQLのエラーメッセージで指摘されている行で文字化けが発生していることを確認する。この時、文字化けしているのは1文字だけではなく、前後の複数の文字も巻き添えにして文字化けしていることを確認する。
2 テキストエディタ（秀丸エディタ等）でシフトJISとしてファイルを開く
※EUC_JPの文字コードで書かれている部分は文字化けしてしまうが、慌てないこと。
3 「invalid byte sequence for encoding "EUC_JP"」で指摘された文字コードに相当する文字列をエディタの検索機能で検索し、文字化けと無縁そうなシングルバイトの文字列に置換する。
※今回の例では、文字コード「0x93ab」に相当するSHIFT_JISの文字コード「騰」を検索し、「mojibake」という文字列に書き換える。
4 ファイルをシフトSHIFT_JISのまま保存する。
※秀丸エディタでしか試していないが、この場合でもEUC_JPの文字コードで保存できている。
5 ファイルを再度開くと、文字化けしていた部分が「mojibake」になり、さらに「mojibake」の前後の文字列の文字化けも解消されていることを確認する。「mojibake」の部分は、本来の文字列が分かり次第、適宜修正。
※以下に、文字コード、SHIFT_JISで見える文字列、本来の文字（機種依存文字）の組み合わせの例を示す。
機種依存文字は当ページを閲覧しているOSやブラウザ等の環境の相違により、正常に表示されていないかもしれないので、「代替表現」の部分を見て、何を記述しているかを推測して頂ければと思う（本当は画像で掲載すればよいのだが、面倒だったので省略）。
| 文字コード | SHIFT_JISで見える文字列 | 本来の文字（機種依存文字） | 代替表現 |
|---|---|---|---|
| 0x93ab | 騰 | �� | I |
| 0x93ac | 闘 | �� | II |
| 0x93ad | 働 | �� | III |
| 0x93ae | 動 | �� | IV |
| 0x93af | 同 | �� | V |
| 0x93b0 | 堂 | �� | VI |
| 0x93b9 | 道 | �� | (株) |
| 0x93bb | 峠 | �� | Tel |
| 0x94bc | 半 | �� | 徳 |
| 0x96fe | 厄ｹ | �� | 高 |
※文字コードが0x96feのものは、シフトJISに該当コードがなさそうに見えた。「厄ｹ」という「厄」と「ｹ」の組み合わせが機種依存文字「�癲廖並綢愽集宗峭癲廖砲乏催�しているように見えたが、間違っているような気もする。
上記のような例は他にもいっぱいあると思うが、私個人でまとめられたのはここまで。今後、新たに同様の問題に遭遇すれば追記するかも（気力があれば・・・）。
個人的な思いとしては、「invalid byte sequence for encoding "EUC_JP"」というエラーへの一番の対処策は、まずはpsqlでファイル読み込みを実行する前に、ファイルをテキストエディタで開いてみて文字化けするかどうかをチェックし、文字化けしていたら文字化けしないように修正をした上でpsqlを実行する、ということだと思う。しかし、文字化け箇所が大量にあると、上記のような置換作業は大変労力がかかるし、時間の無駄だと思うので、極力避けるようにしたい。そう、本来は、何故ファイルが文字化けしているかの原因と改善策を考えなくてはいけないのだろうなぁ・・・。
先週、2週間ぶりに休みを取れて、フジグラン重信店に行った時に、15年前（1995年）に流行したMY LITTLE LOVERの「Hello, Again 〜昔からある場所〜」が店内ミュージックとして流れていた。歌っている人は、MY LITTLE LOVER本人ではなかったので、カヴァーされたのだなあぁ、と 思った。
この曲がよっぽど心に響いていたのだと思う。その日の夜、懐かしい思いがこみあげてきたので、「Hello, Again 〜昔からある場所〜」が収録されているMY LITTLE LOVERのアルバム「evergreen」を久しぶりに聴いてしまった。1週間経過した今も聴いている。
ふと、フジグラン重信店で聞いたカヴァーしている人は誰なんだろう、と思って調べてみると、JUJUという人だった。JUJUの歌い方が、また懐かしさを呼び起こすゆったりとした歌い方なのでよいと思う。JUJUによるカヴァー「Hello, Again 〜昔からある場所〜」のCDは、まだ発売されておらず、発売予定日は2010年7月28日みたいだった。覚えておこう。
JUJUによるカヴァー「Hello, Again 〜昔からある場所〜」は、2010年6月から放送されているSONYのデジカメ「α-NEXシリーズ」のCMソングとして使われたようだ。6月からまだ1ヶ月ほどしか経っていないから、もうしばらくは、街中で流れてくれるかな。
ところで、SONYのNEX-3というデジカメは、「ミラーレス」のデジタル一眼カメラのようだ。「ミラーレス」というのは、鏡を使わない一眼レフカメラということで、長年一眼レフに親しんできた人にはびっくりする機能かもしれない。さらに、5万円ちょっとという価格なので、価格としても安いから、目新しさと価格の安さで買ってしまう人が多いかも！？しかし、私が一番気になったのは、このカメラのミラーレスとか価格ではなく、CMで北川景子さんがパノラマ撮影をしているシーンだった。カメラを横に振りながらパシャパシャパシャと高速連射でシャッターを切り、綺麗なパノラマ写真ができている映像を見て、「パノラマ写真いいなぁ〜、欲しいなぁ」と思ってしまった。わざわざそういうシーンを入れているので、パノラマ機能もこのカメラのアピールポイントなのだろうなぁ。今度、家電量販店にでも行った時にデジカメコーナーでパノラマ機能が付いているカメラを色々と見てしまいそうだ（笑）。
最近のコメント