ショパンのしらべ
先輩のお誘いでプロのピアニストのピアノリサイタルを見に表参道へ。
ポーランド在住の日本人で、ショパンとシマノフスキー（どちらもポーランドの作曲家）の演奏を10曲ほど。
表参道のカワイなんて初めていきましたよ。。。
「せっかく来てもらったのに、思い通りのショパンが弾けなくてごめんなさい」と涙ぐみ、「いつか思いとおりのショパンを弾くことができるようにがんばっているが、なかなかたどり着けない」。
プロというより芸術家。
何十年も前の楽曲の背景と作曲家の意図を理解（しようと努力）し、楽譜を再現する音楽家。
絵画とはまた違う難しさがあるのですね。自分のイメージをキャンバスに再現できた（る）かどうかを悩む画家、一方の音楽家は他人のイメージを楽譜を通じて理解し、再現しようとする。
音楽は演らないのでわからないけど、絵画とはまったく異なるアプローチの仕方をしなけりゃならないんだなと思いました。
ポーランド在住の日本人で、ショパンとシマノフスキー（どちらもポーランドの作曲家）の演奏を10曲ほど。
表参道のカワイなんて初めていきましたよ。。。
「せっかく来てもらったのに、思い通りのショパンが弾けなくてごめんなさい」と涙ぐみ、「いつか思いとおりのショパンを弾くことができるようにがんばっているが、なかなかたどり着けない」。
プロというより芸術家。
何十年も前の楽曲の背景と作曲家の意図を理解（しようと努力）し、楽譜を再現する音楽家。
絵画とはまた違う難しさがあるのですね。自分のイメージをキャンバスに再現できた（る）かどうかを悩む画家、一方の音楽家は他人のイメージを楽譜を通じて理解し、再現しようとする。
音楽は演らないのでわからないけど、絵画とはまったく異なるアプローチの仕方をしなけりゃならないんだなと思いました。
Docomoからのメールを受信できない問題 【解決】
http://cramoty.blog83.fc2.com/blog-entry-57.html
の問題の件、解決しました。
2007/11にDocomoが導入した迷惑メール対策が原因かと推測されます。
送信ドメイン認証（Sender ID／SPF）
http://www.nttdocomo.co.jp/service/mail/imode_mail/sender_id/
BINDにSPFレコードを記述してしばらく（1時間くらい）してから、サクサクと受信できるようになりました。
送信ドメイン認証（Sender ID／SPF）は、Docomoへのメール送信の場合に効果があると認識していましたが、どうもそうとは言い切れないのかもしれません。
が、
先ほどは、
○Docomoから会社のアドレスに連続送信した場合はOK（受信できるときとできないときがある）
×Docomoから当該メールサーバに連続送信した場合はNG（100％OK）
だったところ、当該メールサーバにSPFレコードを記述してOKになったのですが、会社のメールサーバでもってSPFレコードの有無をチェックしてみたところ、そんな記述はなかったのです。SPFレコードは関係ないのかな・・・・。
同時並行してDocomoに問合せしていたので、何か対策してくれたとか・・・こっちの方がありえないような気がします。
現状、期待通りに動作している（Docomoからのメールを受信できている）のは良いとして、因果関係が良くわからないと気持ち悪い・・・。
とりあえず今日のところはあがります。お疲れ様でした。
の問題の件、解決しました。
2007/11にDocomoが導入した迷惑メール対策が原因かと推測されます。
送信ドメイン認証（Sender ID／SPF）
http://www.nttdocomo.co.jp/service/mail/imode_mail/sender_id/
BINDにSPFレコードを記述してしばらく（1時間くらい）してから、サクサクと受信できるようになりました。
送信ドメイン認証（Sender ID／SPF）は、Docomoへのメール送信の場合に効果があると認識していましたが、どうもそうとは言い切れないのかもしれません。
が、
先ほどは、
○Docomoから会社のアドレスに連続送信した場合はOK（受信できるときとできないときがある）
×Docomoから当該メールサーバに連続送信した場合はNG（100％OK）
だったところ、当該メールサーバにSPFレコードを記述してOKになったのですが、会社のメールサーバでもってSPFレコードの有無をチェックしてみたところ、そんな記述はなかったのです。SPFレコードは関係ないのかな・・・・。
同時並行してDocomoに問合せしていたので、何か対策してくれたとか・・・こっちの方がありえないような気がします。
現状、期待通りに動作している（Docomoからのメールを受信できている）のは良いとして、因果関係が良くわからないと気持ち悪い・・・。
とりあえず今日のところはあがります。お疲れ様でした。
Docomoからのメールを受信できない
先日オープンさせた某起業キャンペーンサイト構築での話。Docomoのメール受信処理ではまっています。
空メールを受信してメールアドレスを登録する処理を実装しているのですが、PCからのメール受信及びDocomo以外のキャリアからのメールは、メールサーバ側で受信できるのですが、Docomoのiモードセンターを経由したメールだけが受信できない、正確にいうと、受信できるときもあれば、できないときもある。
受信できないときは、しばらくたってから再送すると、今度は受信できたりする。
受信でいない場合には、その後、しばらくたってからDocomoのiモードセンタから「相手先メールサーバの都合で送信できませんでした」というエラーメッセージが届く。
まったく受信できないのであれば、当方のDNS,メールサーバあたりの設定を疑うのですが、このような状態なので、「何が良くて、何が悪いのか」切り分けに難航しています。
＜仮定＞
受信できるメール（キャリア）はあるので、もしかしたらDocomoで迷惑メール対策（連続して同じアカウントから同じ宛先に送付する場合に制限をかけている？）をしているのかもと思い、以下の実験を行ってみました。
１）送信先アドレスを短いアカウント（x@xxx.jp）にしていたのがいけないのか？→長いアカウントに変えても変化なし。
２）送信メールの題名、本文が「空」だからいけないのか？→題名、本文を加えても変化なし。
３）題名＋本文が毎回同じだからいけないのか？→題名、本文を変えてみても状況に変化なし。
４）試しに、会社のメールサーバに対して同様に送信を行ってみましたが、この場合は全て正常に受信できています。
受信（送信）できなかった場合のiモードセンタからのエラーメールと、４）の結果を総合的に考えると、やはり当方のメールサーバの設定なのかもしれません。
＜メールサーバの設定＞
当該サーバでは、同一ホストにてQMAILをMTAとして動作させ、virtualdomainsにて処理させています。
今回構築したサイトは、virtual-domainB.jpとして動作させ、メールサーバにはAAA.comを使います。
BINDの設定では、
AAA.com
virtual-domainA.com
virtual-domainB.jp
に対応するzoneファイルが記述されています。元々はAAA.comとして構築したサーバに、virtual-domainA.com、virtual-domainB.jpを追加している格好になります。
AAA.comのMXレコードはAAA.comを指すように設定してあります。
今回追加したvirtual-domainB.jpのMXレコードもAAA.comを指すように設定しました。
これまでに追加して動作しているvirtual-domainA.comと同じ設定です。
もしかしてこれがいけないのかもしれません。現状の状態だと、virtual-domainB.jpのMXレコードを参照した場合、
----------------------------------------------------------------
> set type=MX
> virtual-domainB.jp
virtual-domainB.jp MX preference=10. mail exchanger = AAA.com
----------------------------------------------------------------
と返ってくることになります。MXレコードで返ってきたレコードのドメインが違うから？と思って変更してみました。
----------------------------------------------------------------
> set type=MX
> virtual-domainB.jp
virtual-domainB.jp MX preference=10. mail exchanger = virtual-domainB.jp
virtual-domainB.jp internet address = (AAA.comのIPアドレス)
----------------------------------------------------------------
が、今のところ上手くいません・・・。良く考えたらこんな設定（MXレコードのドメイン名が異なる）なんて良くある話のような気がします。
Googleで検索しても出てくるのは「サーバ側からDocomo携帯へのメール配信」に関する、Docomo側の制限の話をどう回避するか？」
という話ばかりで、このケース（Docomoからの受信）についての情報はまったく出てきません・・・
＃ちなみに「サーバ側からDocomo携帯へのメール配信」に関する、Docomo側の制限の話をどう回避するか？」については、ISPのSMTPサーバを経由してDocomoにメールを送るようにすれば、Docomoの制約を回避できるというものでした。
空メールを受信してメールアドレスを登録する処理を実装しているのですが、PCからのメール受信及びDocomo以外のキャリアからのメールは、メールサーバ側で受信できるのですが、Docomoのiモードセンターを経由したメールだけが受信できない、正確にいうと、受信できるときもあれば、できないときもある。
受信できないときは、しばらくたってから再送すると、今度は受信できたりする。
受信でいない場合には、その後、しばらくたってからDocomoのiモードセンタから「相手先メールサーバの都合で送信できませんでした」というエラーメッセージが届く。
まったく受信できないのであれば、当方のDNS,メールサーバあたりの設定を疑うのですが、このような状態なので、「何が良くて、何が悪いのか」切り分けに難航しています。
＜仮定＞
受信できるメール（キャリア）はあるので、もしかしたらDocomoで迷惑メール対策（連続して同じアカウントから同じ宛先に送付する場合に制限をかけている？）をしているのかもと思い、以下の実験を行ってみました。
１）送信先アドレスを短いアカウント（x@xxx.jp）にしていたのがいけないのか？→長いアカウントに変えても変化なし。
２）送信メールの題名、本文が「空」だからいけないのか？→題名、本文を加えても変化なし。
３）題名＋本文が毎回同じだからいけないのか？→題名、本文を変えてみても状況に変化なし。
４）試しに、会社のメールサーバに対して同様に送信を行ってみましたが、この場合は全て正常に受信できています。
受信（送信）できなかった場合のiモードセンタからのエラーメールと、４）の結果を総合的に考えると、やはり当方のメールサーバの設定なのかもしれません。
＜メールサーバの設定＞
当該サーバでは、同一ホストにてQMAILをMTAとして動作させ、virtualdomainsにて処理させています。
今回構築したサイトは、virtual-domainB.jpとして動作させ、メールサーバにはAAA.comを使います。
BINDの設定では、
AAA.com
virtual-domainA.com
virtual-domainB.jp
に対応するzoneファイルが記述されています。元々はAAA.comとして構築したサーバに、virtual-domainA.com、virtual-domainB.jpを追加している格好になります。
AAA.comのMXレコードはAAA.comを指すように設定してあります。
今回追加したvirtual-domainB.jpのMXレコードもAAA.comを指すように設定しました。
これまでに追加して動作しているvirtual-domainA.comと同じ設定です。
もしかしてこれがいけないのかもしれません。現状の状態だと、virtual-domainB.jpのMXレコードを参照した場合、
----------------------------------------------------------------
> set type=MX
> virtual-domainB.jp
virtual-domainB.jp MX preference=10. mail exchanger = AAA.com
----------------------------------------------------------------
と返ってくることになります。MXレコードで返ってきたレコードのドメインが違うから？と思って変更してみました。
----------------------------------------------------------------
> set type=MX
> virtual-domainB.jp
virtual-domainB.jp MX preference=10. mail exchanger = virtual-domainB.jp
virtual-domainB.jp internet address = (AAA.comのIPアドレス)
----------------------------------------------------------------
が、今のところ上手くいません・・・。良く考えたらこんな設定（MXレコードのドメイン名が異なる）なんて良くある話のような気がします。
Googleで検索しても出てくるのは「サーバ側からDocomo携帯へのメール配信」に関する、Docomo側の制限の話をどう回避するか？」
という話ばかりで、このケース（Docomoからの受信）についての情報はまったく出てきません・・・
＃ちなみに「サーバ側からDocomo携帯へのメール配信」に関する、Docomo側の制限の話をどう回避するか？」については、ISPのSMTPサーバを経由してDocomoにメールを送るようにすれば、Docomoの制約を回避できるというものでした。
GLOBEペダル交換＆ステム逆付け
クロスバイクのペダルがママチャリみたいで気に入らなかったので交換しようと思ってたのですが、とうとうリフレクタ（反射板）も取れてしまったので、意を決して交換。
Wellgo M-21。軽量のMTB用ペダルです。
ペダルを外すにはレンチで良さそうなものですが、専用のレンチがあるということなので、合わせて購入。
どうも専用レンチじゃないと外れにくいみたいなのですな。
自転車のペダルネジは「踏めば踏むほど締め込まれる」ようになっています。
左側ペダルのネジが「逆ネジ」になっています。
いずれにせよこれが固い固い。片方外すのに１５分くらい格闘して急に「かくん」と外れてくれました。
ペダル交換が上手くいったので、かねてよりの懸念事項であった、ステム（ハンドル）の逆付けに挑戦。
まずは１枚目の写真が変更前（Before）の状態です。スポーツバイクというよりママチャリ。
ステムを固定しているネジを外し、ハンドルもいったん外します。
その後、ステムを真逆につげると、あらステキ。（２枚目）
一気にステアリングポジションが低くなりました。
Before-Afterの写真を重ねてみると、結構な変化があることがわかります（３枚目）。
これで前傾姿勢が作れます、スポーツバイクっぽくなってきました。
「ママチャリみたい」と言われてしまったGLOBEですが、改造してあげることで愛着が湧いてきました。
次回はグリップを取り替えて、エンドバーを装着してみたいと思います。
あと、ステムもカーボンに取り替えて、ハンドルバーも取り替えて・・・。
Wellgo M-21。軽量のMTB用ペダルです。
ペダルを外すにはレンチで良さそうなものですが、専用のレンチがあるということなので、合わせて購入。
どうも専用レンチじゃないと外れにくいみたいなのですな。
自転車のペダルネジは「踏めば踏むほど締め込まれる」ようになっています。
左側ペダルのネジが「逆ネジ」になっています。
いずれにせよこれが固い固い。片方外すのに１５分くらい格闘して急に「かくん」と外れてくれました。
ペダル交換が上手くいったので、かねてよりの懸念事項であった、ステム（ハンドル）の逆付けに挑戦。
まずは１枚目の写真が変更前（Before）の状態です。スポーツバイクというよりママチャリ。
ステムを固定しているネジを外し、ハンドルもいったん外します。
その後、ステムを真逆につげると、あらステキ。（２枚目）
一気にステアリングポジションが低くなりました。
Before-Afterの写真を重ねてみると、結構な変化があることがわかります（３枚目）。
これで前傾姿勢が作れます、スポーツバイクっぽくなってきました。
「ママチャリみたい」と言われてしまったGLOBEですが、改造してあげることで愛着が湧いてきました。
次回はグリップを取り替えて、エンドバーを装着してみたいと思います。
あと、ステムもカーボンに取り替えて、ハンドルバーも取り替えて・・・。
